Una guida per sviluppare sistemi elettronici (terza parte): La Progettazione software

LA PROGETTAZIONE SOFTWARE

Dr. Val Lynch, CEO bei AND Technology Research
Steve Norman, Manager, Global Ecosystems, Renesas Electronics Europe
Un buon codice è ovviamente un codice corretto. Questo mi veniva detto all’inizio della mia carriera ed è un mantra che io ho adottato e che posso raccomandare.
Se il codice è ovviamente corretto allora esso sarà semplice da leggere e semplice da testare.
Quindi, come viene creato un buon codice? Essenzialmente si parte da una buona progettazione. Questo articolo descrive alcuni degli elementi richiesti per ottenere un buon progetto.
Per descrivere la scena di questo documento ho fornito tre definizioni.
Architettura software: La definizione dell’organizzazione di un sistema software che sarà in grado di soddisfare le richieste e che permette, in modo semplice, di essere modificato e riutilizzato in futuro.
Oggetti ed altro: Blocchi di codice che eseguono funzioni specifiche all’interno della architettura software. Oggetti che possono essere combinati e che possono anche essere etichettati come funzioni, procedure o moduli. La nomenclatura di tali blocchi dipende spesso dal linguaggio software utilizzato.
Interfacce software: Specifiche che forniscono la definizione di come una parte dell’architettura software si collega ad un’altra. L’interfacciamento avviene a tutti i livelli all’interno dell’architettura, tra singoli blocchi di codice, tra questi blocchi e le funzioni ad alto livello e verso sistemi o utenti esterni.
La progettazione software può essere pensata come un processo scientifico ma racchiude anche un lato artistico. Le richieste di un sistema possono essere suddivise in funzioni logiche e ogni funzione può essere codificata, un approccio pragmatico. Comunque l’effetto combinatorio derivante dall’aggregazione di ogni set logico rende praticamente impossibile assicurare che ogni percorso sia stato codificato in modo che sia ovviamente corretto e questo è il punto in cui l’abilità, l’esperienza e l’apprezzamento per il valore estetico diventano cruciali.
Mai sottostimare le sfide da affrontare durante la progettazione del software. Ogni minimo dettaglio è importante a partire dal nome corretto di un oggetto fino al tempo impiegato da ogni singola istruzione per essere eseguita. La cura e l’ attenzione ai dettagli sono essenziali.
Forse la prima cosa da dire a proposito della progettazione software è che un approccio iniziale comune non è adatto a tutto ma raccogliendo tutti i dati più importanti, gli input e le richieste ed esaminando tutto insieme può emergere un modello che possiamo utilizzare come base di lavoro. Lo scopo è quello di assicurare che il modello scelto possa essere utilizzato per soddisfare le richieste per lo sviluppo. Esempi di modelli, incluse le strutture software identificate come le più utili in questi casi, sono disponibili in letteratura e forniscono un valido aiuto durante la progettazione dell’architettura.
Le strutture descrivono le caratteristiche comuni del codice. Macchine a stati, controllori model view ed osservatori sono degli esempi. Il codice scritto seguendo una particolare struttura sarà, in genere, più semplice da seguire e da testare, può inoltre essere utilizzato per definire come il codice degli oggetti codice può essere sviluppato. In ogni caso le strutture non dovrebbero essere seguite a meno che non siano appropriate al nostro scopo. In fin dei conti il progettista è il responsabile e deve assicurare che il codice sia ben organizzato, che sia chiaro e che sia definibile come ovviamente corretto e che sia posta la necessaria attenzione alle interfacce tra i vari oggetti.
La buona pratica ci impone di prendere sempre in considerazione lo scopo di ogni interfaccia e di come questa si inserisce all’interno dell’intera architettura. Le interfacce dovrebbero essere definite in modo chiaro nei documenti scritti che possono essere condivisi tra i progettisti. Entrambi i lati dell’interfaccia devono essere studiati prima di deciderne i dettagli e questo è particolarmente vero se i due lati devono essere sviluppati da progettisti diversi o addirittura all’interno di società diverse.
La documentazione è spesso la Cenerentola dello sviluppo software e qualcosa che intimidisce i progettisti, ma delle specifiche dell’interfaccia ben scritte senza dubbio consentiranno di risparmiar molte ore di lavoro. L’arte dello sviluppo dell’interfaccia si basa sul fatto di renderla il più generica possibile senza perdere robustezza e senza allontanarsi dallo scopo finale. Questo consentirà di potere apportare i cambiamenti necessari ad entrambi i lati dell’ interfaccia. Lo scopo è quello di assicurare che il codice segua sempre le specifiche dell’ interfaccia e che non accada l’opposto.
La progettazione del software per un microcontrollore quale Synergy richiede una particolare attenzione a causa delle interfacce hardware che saranno coinvolte. Ogni periferica a bordo del microcontrollore richiederà di essere inizializzata in modo da potere fornire i dati richiesti, in modo da essere utilizzata dal software in modo corretto ed in modo da assicurare che i pin non utilizzati vengano gestiti in modo corretto. La possibilità di approcciare ognuna di queste periferiche come oggetti all’interno del sistema consente di gestire le interfacce in modo efficiente.
Il linguaggio scelto per l’authoring del software avrà un impatto sulla progettazione del software stesso e, di conseguenza, le varie opzioni dovrebbero essere considerate come parte delle considerazioni architetturali piuttosto che una scelta guidata meramente dallo strumento al quale il progettista è abituato. Per le applicazioni web-based Java è la scelta più comune e per alcune applicazioni linguaggi script-based quali Python sono appropriati. La maggior parte delle applicazioni embedded, come quelle che dovrebbero “girare“ sulla piattaforma Synergy, tendono ad utilizzare linguaggi quali il linguaggio C o C++. Il linguaggio C++ fornisce la flessibilità utile per lavorare con architetture complesse mentre il linguaggio C consente di generare un codice più dedicato all’applicazione specifica, soprattutto quando l’efficienza è importante. Per le applicazioni più sfidanti quando la durata di ogni singola istruzione diventa importante l’opzione di potere scrivere il codice in assembler potrebbe essere importante.
A prescindere dall’architettura, dalla progettazione o dal linguaggio di programmazione scelto tutto può essere vano se si dimenticano le buone regole di programmazione. La programmazione è una disciplina differente dalla progettazione e dallo sviluppo dell’architettura e in molti casi vengono coinvolti diversi progettisti. Gli standard e le convenzioni di programmazione sono quindi di primaria importanza. La chiarezza del codice può essere migliorata prendendo in considerazione i nomi associati ai dati. Dati con nomi ben assegnati assieme ad una chiara descrizione del motivo per cui il progettista ha scritto il codice in un certo modo può far risparmiare successivamente ore uomo successivamente quando il codice dovrà essere testato e manutenuto. Assicurarsi che un numero sufficiente di punti di controllo e di verifica all’interno del codice è un altro eccellente modo salvare tempo dato che consente di gestire in modo accurato le differenti versioni del codice.
Una architettura di riferimento con una interfaccia robusta implementata su un codice testabile, consistente e controllato aiuterà i progettisti ad ottenere e a manutenere del software che sarà ovviamente corretto.

> Scopri come Renesas Synergy può supportare i progettisti software: https://www.renesas.com/en-eu/products/synergy/software.html

 
Guarda le puntate precedenti:

GUIDA ALLO SVILUPPO DI UN SISTEMA ELETTRONICO (PARTE PRIMA): SOFTWARE GARANTITO E VALORE AGGIUNTO

UNA GUIDA PER SVILUPPARE SISTEMI ELETTRONICI (SECONDA PARTE): IL PROGETTO HARDWARE

Redazione Fare Elettronica