Embedded_56

69 / 84

69
CODING GUIDELINE | software
EMBEDDED 56 • maggio • 2015
accedere alle estensioni specifiche del compila-
tore per il linguaggio C, che dà luogo a una non-
conformità MISRA. Il safety case tipicamente
richiederà una attenta copertura della unità di
test.
Defensive Coding: data l’assenza in C di una
solida gestione delle eccezioni, la pratica della
codifica difensiva può implicare, per esempio,
protezioni programmatiche contro comporta-
menti imprevisti. Un tool di anali-
si, totalmente adeguato, rileva cor-
rettamente condizioni invarianti e
codice di conseguenza non esegui-
bile. Il safety case deve comportare
l’esecuzione del test di unità forza-
ta di questi percorsi o condizioni.
Funzionalità di linguaggio: esi-
stono valide ragioni relative alla
qualità del codice per utilizzare
costrutti linguistici ‘recenti’, per
esempio di tipo Booleani o ‘long
long’ o funzioni inline. Tuttavia,
questi possono richiedere deroghe
dalle vecchie versioni MISRA. La
safety issue è che persino dei co-
strutti C99 vecchi di 15 anni non
hanno la garanzia di essere supportati da tutti
i compilatori.
Strutture di deroga controllata
La categorizzazione delle differenti motivazioni
è il primo passo verso la creazione di una strut-
tura di deroghe opportunamente vincolate. Ciò
conduce naturalmente a una elaborazione di
tutti i casi specifici di deviazioni conosciuti, per
regola e per categoria. MISRA e JAMA stanno
entrambe documentando, con la partecipazione
delle aziende, un set di restrizioni di regole di
ambito, ognuna con dettagliate motivazioni e
safety case.
Persino al di fuori di un contesto Automotive,
queste iniziative sono importanti. Lo standard
di codifica MISRA era originariamente proget-
tato per il settore Automotive, ma fin dai suoi
primi anni ha trovato disponibilità all’adozione
in molti altri ambienti embedded, dai prodotti
consumer ai dispositivi medicali, dal controllo
industriale all’EDA. Allo stesso modo, l’istitu-
zione di una struttura di deviazione controlla-
ta è importante in qualsiasi settore industriale,
azienda o organizzazione che adotti uno stan-
dard di codifica.
Automated Tool Support
Uno standard di codifica senza unmezzo automa-
tizzato di imposizione, un ricco audit e funziona-
lità di reporting diventerà presto un ornamento
di libreria, raramente seguito o preso a riferi-
mento. Il punto di partenza per
uno strumento di analisi statica
automatizzata competente deve
essere l’accuratezza nel suo ou-
tput diagnostico, la chiarezza di
comprensione e spiegazione su
ogni questione sollevata e par-
ticolareggiati report verso ogni
versione del progetto software.
Ma anche un ambiente di appli-
cazione di strumenti automatici
ha bisogno di consapevolezza e
l’applicazione di una politica di
deroga approvato, soprattutto
perché questo rimuove un osta-
colo alla piena conformità. Sia
le regole di codifica sia la poli-
tica di deroga devono essere vantaggiose per gli
sviluppatori, considerati attendibili da leader e
responsabili e facilitare la reportistica dettaglia-
ta di QA. Un sistema base di deroghe accoppierà
ogni istanza di soppressione di regola alla sua
giustificazione di deviazione, e preserverà que-
sto accoppiamento attraverso tutto il ciclo di
vita del codice sorgente pertinente. I requisiti
sono più complessi quando si tratta di deviazioni
controllate. Qualsiasi soppressione delle pertinen-
ti norme di codificazione deve obbedire le restri-
zioni più severe in essere, e nessuna soppressio-
ne può avvenire di fuori di quel set controllato di
deroghe. Nello scegliere la specifica locazione del
codice dove una diagnostica rendicontata debba
essere soppressa, gli sviluppatori devono essere
costretti a effettuare l’esclusione solo utilizzando
l’intervallo consentito dalle deviazioni controllate.
Bibliografia
Ganssle, J. (2014, August 4). Retrieved from The
Ganssle Group
Gli standard
di codifica MISRA
contengono linee
guida largamente
rispettate dagli
sviluppatori
in C e C++