Scuola Politecnica e delle Scienze di Base
Corso di Laurea Magistrale in Ingegneria Informatica
Tesi di Laurea Magistrale in Ingegneria del Software
PROGETTAZIONE MODEL-DRIVEN DI UN SISTEMA
EMBEDDED INDUSTRIALE
Anno Accademico 2013/2014
Relatore
Ch.mo Prof Stefano Russo
correlatore
Ing. Domenico Di Leo
Ing. Bruno Busco
candidato
Francesco Pascale
Matr. M63000092
A mia Madre e a mio Padre,
i miei punti di riferimento.
L'ingegnere
Il Grigio del cielo annebbia i miei pensieri.
L'aria fredda mi avvolge in una bolgia di gelo.
Eppure sono lì, non mi muovo, non mollo
nonostante l'ardua fatica che mi aspetta
sono disposto a lottare fino all'ultimo.
Ce la farò! vincerò il buio dell'ignoto.
Francesco Pascale
Dal libro “Racconti di villana gioventù”
Edizioni “Il Saggio”
Castellamare - Dicembre 2013
Indice
Indice ..................................................................................................................................................IV
Indice delle figure ................................................................................................................................ 5
Indice delle tabelle ............................................................................................................................... 7
Introduzione ......................................................................................................................................... 8
Capitolo 1: Metodologie Model Driven ............................................................................................. 10
1.1 MDA.................................................................................................................................... 10
1.2 Development ....................................................................................................................... 13
1.3 Testing ................................................................................................................................. 17
1.4 Standard ............................................................................................................................... 19
1.4.1 CWM................................................................................................................................. 19
1.4.2 UML .................................................................................................................................. 20
1.4.3 MOF .................................................................................................................................. 21
1.4.4 XMI ................................................................................................................................... 23
Capitolo 2: Il linguaggio di modellazione SysML ............................................................................. 24
2.1 BDD ......................................................................................................................................... 31
2.2 IBD ........................................................................................................................................... 42
2.3 RD ............................................................................................................................................ 44
Capitolo 3: Strumenti di supporto ...................................................................................................... 50
3.1 Eclipse-Papyrus ........................................................................................................................ 50
3.2 IBM Rational Rhapsody Developer ......................................................................................... 52
Capitolo 4: Caso di studio .................................................................................................................. 58
4.1 Il sistema TOD ......................................................................................................................... 58
4.2 Requisiti ................................................................................................................................... 61
4.3 Scelta dei linguaggi e degli strumenti ...................................................................................... 62
4.4 Analisi: Modellazione SysML ................................................................................................. 63
4.4.1 Requirements Diagram ................................................................................................ 63
4.4.2 Definition Block Diagram e Internal Block Diagram .................................................. 68
4.4.3 Allocazione dei requisiti .............................................................................................. 78
4.5 Realizzazione con Rhapsody ................................................................................................... 83
4.5.1 Sviluppo con profilo FunctionalC ................................................................................ 83
4.5.2 Generazione del codice e simulazione della parte dinamica........................................ 95
4.5.3 Sviluppo con modello a Oggetti................................................................................... 99
Conclusioni ...................................................................................................................................... 106
Sviluppi Futuri ................................................................................................................................. 109
Bibliografia ...................................................................................................................................... 110
Ringraziamenti ................................................................................................................................. 111
IV
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Indice delle figure
Figura 1: Model Driven Architecture................................................................................................. 13
Figura 2: I livelli e le trasformazioni nell’MDA ................................................................................ 14
Figura 3: Storia del SysML ................................................................................................................ 25
Figura 4: Rappresentazione degli insiemi UML e SysML ................................................................ 26
Figura 5: Struttura a blocchi dell’UML e SysML .............................................................................. 29
Figura 6: Esempio BDD Strutturato................................................................................................... 32
Figura 7: Esempio notazione BDD .................................................................................................... 34
Figura 8: Vista di due interfacce con le rispettive operations e receptions in un BDD ..................... 36
Figura 9: Modello flow-port in un BDD ............................................................................................ 36
Figura 10: Esempio di instanza in un BDD ....................................................................................... 38
Figura 11: Esempio di composizione in un BDD .............................................................................. 38
Figura 12: Attori in un BDD .............................................................................................................. 39
Figura 13: Esempio di definizione di tipo in un BDD ....................................................................... 40
Figura 14: Esempio di constraint in un BDD ..................................................................................... 41
Figura 15: Esempio di commenti in un BDD .................................................................................... 42
Figura 16: Esempio di IBD ................................................................................................................ 44
Figura 17: Un esempio di Requirements Diagram............................................................................. 45
Figura 18: Layout Eclipse-Papyrus .................................................................................................... 52
Figura 19: Layout IBM Rational Rhapsody Developer per C ........................................................... 55
Figura 20: Comparazione tra Class Diagram e File Diagram ............................................................ 56
Figura 21: Comparazione tra Sequence Diagram e Message Diagram ............................................. 56
Figura 22: Comparazione tra Activity Diagram e Flow Chart Diagram ............................................ 57
Figura 23: Architettura del TOD ........................................................................................................ 58
Figura 24: RD dei gruppi di requisiti HLR ........................................................................................ 64
Figura 25: RD dei requisiti del gruppo GEN ..................................................................................... 65
Figura 26: RD dei requisiti del gruppo SVR...................................................................................... 65
Figura 27: RD dei requisiti del gruppo HMI...................................................................................... 66
Figura 28: RD dei requisiti del gruppo EST ...................................................................................... 67
Figura 29: RD dei requisiti del gruppo DRV ..................................................................................... 68
Figura 30: BDD piattaforma MDSETH ............................................................................................. 69
Figura 31: TOD Block ....................................................................................................................... 70
Figura 32: Componenti del TOD ....................................................................................................... 70
Figura 33: IBD TOD .......................................................................................................................... 71
Figura 34: BDD TODMA .................................................................................................................. 72
Figura 35: Composizione del TODMA ............................................................................................. 73
Figura 36: TODMA IBD.................................................................................................................... 74
Figura 37: HMI BDD ......................................................................................................................... 76
5
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 38: Composizione HMI .......................................................................................................... 76
Figura 39: HMI IBD .......................................................................................................................... 77
Figura 40: Tracciabilità dei requisiti negli artefatti ........................................................................... 78
Figura 41: Allocazione dei requisiti rispetto al blocco Tod Management Agent .............................. 79
Figura 42: Allocazione dei requisiti rispetto al blocco Tod Control Server ...................................... 80
Figura 43: Allocazione dei requisiti rispetto al blocco HMI ............................................................. 80
Figura 44: Allocazione dei requisiti rispetto al blocco Add-On ........................................................ 81
Figura 45: Allocazione dei requisiti rispetto al blocco driver Tod .................................................... 81
Figura 46: RD dei gruppi di requisiti con vista delle relazioni .......................................................... 82
Figura 47: RD dei requisiti del gruppo GEN con vista delle relazioni ............................................. 82
Figura 48: File Diagram TODMA ..................................................................................................... 84
Figura 49: State Chart todControlServer con FunctionalC ................................................................ 86
Figura 50: State Chart todManagementAgent con FunctionalC ........................................................ 86
Figura 51: Message Diagram Beep .................................................................................................... 88
Figura 52: Message Diagram LampOnOff ........................................................................................ 89
Figura 53: Message Diagram Diagnostic ........................................................................................... 90
Figura 54: Message Diagram Set Uri ................................................................................................. 91
Figura 55: Message Diagram Get Uri ................................................................................................ 92
Figura 56: Message Diagram Touch Screen Calibrator ..................................................................... 93
Figura 57: Message Diagram Brightness Regulation ........................................................................ 94
Figura 58: Esempio di simulazione dello State Chart con richiesta di beep ...................................... 96
Figura 59: Esempio di simulazione dello State Chart con richiesta di Touch Screen Calibrator ...... 97
Figura 60: Esempio di simulazione dello State Chart con richiesta di Lamp On/Off ....................... 97
Figura 61: Simulazione di situazione di errore in una richiesta ......................................................... 98
Figura 62: Simulazione di situazione di scadenza del lifetime di una richiesta ................................ 98
Figura 63: Class Diagramm del TODMA .......................................................................................... 99
Figura 64: Object Model Diagram del TODMA ............................................................................. 100
Figura 65: State Chart TodControlServer Object Based .................................................................. 101
Figura 66: State Chart TodManagementAgent Object Based .......................................................... 102
Figura 67: Test Architecture TODMA............................................................................................. 103
Figura 68: Automatic Test Generetor (ATG) .................................................................................. 104
6
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Indice delle tabelle
Tabella 1: Software Requirements Specification TODMA…………………………………………61
Tabella 2:Vantaggi e Svantaggi……………………………………………………………………106
7
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Introduzione
Questa tesi tratta la progettazione di sistemi software industriali di tipo embedded
con metodologie guidate dai modelli (model-driven). Le tecniche model-driven sono
metodologie di sviluppo e testing del software ormai sufficientemente mature per essere
introdotte ed utilizzate all'interno dei contesti industriali. Tali metodologie sono state
applicate con successo in numerosi campi dell’ingegnerizzazione del software. Pur
essendo molto promettenti in termini di riduzione di tempi e costi di sviluppo e di qualità e
manutenibilità dei prodotti software, in molti contesti industriali esse trovano difficoltà di
applicazione per via rischi che le aziende percepiscono come ancora connessi alla loro
adozione in luogo di metodologie più tradizionali. Tra i fattori di rischio vi sono i tempi e i
costi della formazione per dotare i progettisti dei necessari skill, l’esigenza di adottare
appositi strumenti software di supporto alla progettazione – dal costo spesso elevato e non
sempre disponibili in forma integrata.
Il lavoro di tesi analizza lo stato dell’arte nella modellazione e progettazione modeldriven, e lo stato della tecnologia relativamente agli strumenti software per gestire in
maniera integrata le varie fasi di un processo di sviluppo e testing guidato dai modelli. La
tesi si concentra poi sulla progettazione di un sistema software embedded, considerando
un caso di studio reale di interesse dell’azienda Ansaldo Breda, leader italiana per la
costruzione di treni e metropolitane ad uso civile.
Nel Capitolo 1 si analizza lo stato dell’arte della metodologie di sviluppo e testing
guidate dai modelli, con particolare riferimento ai linguaggi standard oggi maggiormente
in uso. Nel Capitolo 2 è descritto il linguaggio di modellazione SysML. Nel Capitolo 3
8
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
sono descritti i più diffusi tool di supporto, utilizzati anche nel caso di studio. Nel
Capitolo 4 è descritto il caso di studio e ne è mostrata la progettazione SysML e la
realizzazione con gli strumenti di supporto scelti. Infine sono discusse le conclusioni che il
caso di studio consente di trarre sull’introduzione di metodologie model-driven nel
contesto di interesse.
9
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Capitolo 1: Metodologie Model Driven
1.1 MDA
Model Driven Architecture (MDA) è una famiglia di standard correlati, gestiti
dallo Object Management Group1, e intesi a consentire un approccio integrato allo
sviluppo del software, in cui la realizzazione di modelli possa essere considerata parte del
processo di implementazione[1].
I modelli, la modellazione e la Model-Driven Architecture sono la base di una serie
di approcci di sviluppo noti come Model-Driven Development2 (MDD). I modelli sono
usati per ragionare sul dominio del problema e progettare una soluzione. Le relazioni tra
questi modelli forniscono una rete di dipendenze che registrano il processo con cui si crea
una soluzione, e aiutano a capirne le modifiche in qualsiasi punto del processo di sviluppo.
Oltre a creare questi modelli, si è in grado di definire le regole per automatizzare molti dei
passaggi necessari per convertire una rappresentazione del modello ad un altro, per il
tracciamento tra elementi del modello, e per analizzare le caratteristiche importanti dei
modelli. Questo stile di MDD è chiamato Model-Driven Architecture. L'approccio MDA è
ampiamente discusso nel processo di sviluppo software di oggi come un modo per
aumentare la qualità, l'efficienza e la predicibilità dello sviluppo del software su larga
scala.
1
L'Object Management Group (OMG) è un consorzio creato nel 1989 con 440 aziende quali Microsoft, HP, NCR,
SUN, con l'obiettivo di creare un sistema di gestione di un'architettura distribuita. Gli standard più importanti che sono
stati proposti riguardano l'architettura CORBA, il linguaggio di modellazione UML e lo standard XMI.
2
Model-Driven Development è una metodologia di sviluppo software che si focalizza sulla creazione di modelli o
astrazioni più vicina a particolari concetti di dominio piuttosto che a concetti di computazione o di algoritmica. La si
intende come incremento della produttività massimizzando la compatibilità tra i sistemi, semplificando il processo di
progettazione, e promuovendo la comunicazione tra individui e il lavoro di gruppo sul sistema.
10
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
I modelli forniscono astrazioni di un sistema fisico e permettono agli ingegneri di
ragionare sul sistema per concentrandosi su quelli rilevanti. Tutte le forme di ingegneria si
basano su modelli come base essenziale per capire i sistemi reali complessi.
I modelli sono utilizzati in molti modi: per prevedere le qualità del sistema, per ragionare
sulle proprietà specifiche quando si modificano gli aspetti del sistema, e per comunicare le
caratteristiche del sistema alle parti interessate. I modelli possono essere sviluppati come
un’anticipazione del sistema fisico che verrà poi implementato, o possono derivare da un
sistema esistente o di un sistema in fase di sviluppo come un aiuto per comprendere il suo
comportamento.
Ci sono molti aspetti interessanti; a seconda di quello che è considerato rilevante, i
vari concetti di modellazione e notazioni possono essere utilizzati evidenziando uno o più
particolari
prospettive o punti di vista di quel sistema. Può nascere l’esigenza di
trasformare i modelli in altre forme di rappresentazione oppure in altri modelli e il
modello trasformazioni può facilitare questo. In altri casi, una trasformazione converte i
modelli che offrono una prospettiva particolare tra i livelli di astrazione, di solito da una
più astratta di meno astratto vista aggiungendo ulteriori dettagli, fornite dalle regole di
trasformazione.
Le relazioni tra questi modelli forniscono una rete di dipendenze che realizzano il
processo mediante il quale una soluzione è stata creata, e aiuta a comprendere le
implicazioni dei cambiamenti in qualsiasi punto in questo processo. Se definiamo i tipi di
modelli che devono essere prodotti, e applichiamo con un certo rigore la semantica precisa
di questi modelli, siamo in grado di definire le regole per:
• Automatizzare molti passi necessari per convertire una rappresentazione modello
all'altro.
• Tracing tra elementi del modello.
• Analizzare le caratteristiche principali dei modelli.
Nel 2001 l'OMG ha adottato il Model Driven Architecture come un approccio per
11
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
l'utilizzo di modelli di sviluppo del software. I suoi tre obiettivi primari sono la portabilità,
interoperabilità e riusabilità attraverso la separazione dell’architettura dalla sua effettiva
realizzazione.
Un aspetto fondamentale della MDA è la sua capacità di affrontare il ciclo di
sviluppo completo, che copre l'analisi e la progettazione, la programmazione, il controllo,
l'assemblaggio dei componenti così come la realizzazione e la manutenzione. MDA non è
una nuova specifica OMG, ma piuttosto un approccio allo sviluppo del software che è
realizzato da specifiche OMG pre-esistenti quali l'Unified Modeling Language3 (UML),
MetaObject Facility4 (MOF) e Common Warehouse Metamodel5 (CWM). Altre tecnologie
adottate che sono di interesse sono il profilo UML per Enterprise Distributed Computing
Object6 (EDOC), compresa la sua mappatura di EJB7, e la CORBA Component Model8
(CCM).
Con le nuove piattaforme e tecnologie costantemente emergenti, il paradigma MDA
consente il rapido sviluppo di nuove specifiche che lo sfruttano e che ne semplifica il
processo di integrazione. In questo modo MDA fornisce una soluzione completa e
strutturata per l'interoperabilità delle applicazioni e la portabilità di queste. La
modellazione precisa nel dominio della soluzione UML fornisce il vantaggio di catturare
la sua proprietà intellettuale inerente alla specifica in modo tecnologicamente neutrale.
Come illustrato in Figura 1, l'OMG prevede MDA per comprendere una gamma completa
di servizi "pervasivi", che si trovano comunemente nelle applicazioni distribuite moderne
[2].
3
UML (Unified Modeling Language, "linguaggio di modellazione unificato") è un linguaggio di modellazione e
specifica basato sul paradigma object-oriented.
4
Il Meta-Object Facility (MOF) è uno standard per l'ingegneria guidata dal modello dell’OMG.
5
Common Warehouse Metamodel (CWM) definisce una specifica per la modellazione di metadati per i relazionali,
non-relazionali, multidimensionali, e la maggior parte di altri oggetti ritrovati in un ambiente di data warehousing..
6
Enterprise Distributed Object Computing (EDOC) è uno standard dell’OMG a supporto del calcolo distribuito che
utilizza l’MDA e Service-Oriented Architecture.
7
Enterprise JavaBean (EJB) sono i componenti software che implementano, lato server, la logica di business di
un'applicazione web all'interno dell'architettura/piattaforma Java EE espletando servizi a favore della parte di front-end
ovvero per la logica di presentazione di un'applicazione web.
8
CORBA Component Model (CCM) è una specifica per la creazione di un server-side scalabile, indipendente dalla
lingua, transazionale, multi-utente e per applicazioni aziendali sicure.
12
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 1: Model Driven Architecture
1.2 Development
Nel mondo dell’ingegneria del software, la modellazione ha una ricca tradizione. Le
innovazioni più recenti si sono concentrate sulle notazioni e sugli strumenti che
consentono agli utenti di esprimere le prospettive di un sistema, e di esprimere queste
prospettive in modi che possono essere facilmente mappati all’interno del codice in uno
specifico linguaggio di programmazione compilato per una particolare piattaforma di un
particolare sistema operativo. Lo stato attuale di questa pratica utilizza il linguaggio di
modellazione unificato (UML), come la notazione di modellazione primaria. L'UML
permette ai team di sviluppo di catturare una serie di caratteristiche importanti di un
sistema. Le trasformazioni tra questi modelli sono principalmente manuali, anche se alcuni
strumenti possono essere utilizzati per gestire i rapporti in riferimento alla tracciabilità e
alla dipendenza tra elementi del modello in base a delle linee guida [1].
Un modo utile per la caratterizzazione è quello di esaminare i diversi modi in cui i modelli
13
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
vengono trasformati in codice sorgente. Questo è illustrato nella Figura 2 che mostra lo
spettro di approcci di modellazione in uso oggi. Ogni categoria identifica un particolare
uso di modelli che aiuta gli sviluppatori a creare applicazioni in esecuzione (codice) per
una piattaforma specifica, e a gestire il rapporto tra i modelli usati ed il codice generato.
Figura 2: I livelli e le trasformazioni nell’MDA
Un aspetto fondamentale dell'approccio MDA è riconoscere che le trasformazioni possono
essere applicate alle descrizioni astratte di alcuni aspetti di un sistema per aggiungere
ulteriori dettagli a tale descrizione, perfezionare tale descrizione per essere più concreti, o
per la conversione tra rappresentazioni. Alcuni concetti importanti in riferimento
all’approccio MDA sono:
• Distinguere diversi tipi di modelli ci permette di pensare al software e allo sviluppo del
sistema come una serie di parametri tra rappresentazioni di modelli differenti. Questi
modelli e i loro parametri sono una parte critica della metodologia di sviluppo per le
situazioni che includono i parametri tra i modelli che rappresentano diversi aspetti del
sistema, aggiungendo ulteriori dettagli a un modello, o la conversione tra diversi tipi di
modelli.
14
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
• Un modo per prendere in considerazione i modelli è di classificarli in termini di come
esplicitamente rappresentano aspetti delle piattaforme in considerazione. In tutto il ciclo di
sviluppo del software ci sono importanti vincoli impliciti dovuti alla scelta del
linguaggio,dell’ hardware, della topologia di rete, dei protocolli di comunicazione e delle
infrastrutture, e così via. Ognuno di questi può essere considerato come elemento della
soluzione "piattaforma". Un approccio MDA ci aiuta a concentrarci su ciò che è essenziale
per
la
soluzione
in
fase
di
progettazione
separato
dai
dettagli
della
particolare"piattaforma".
• La nozione di ciò che è una "piattaforma" è piuttosto complessa, e fortemente dipendente
dal contesto. Ad esempio, in alcune situazioni la piattaforma può essere il sistema
operativo e le utilità associate; in altre situazioni, può essere una infrastruttura tecnologica
rappresentata da un modello di programmazione ben definito come J2EE 9o .NET10; in
altre situazioni è un caso particolare di una topologia hardware. Qualunque cosa noi
consideriamo la "piattaforma", è importante pensare più in termini di modelli a diversi
livelli di astrazione utilizzati per scopi diversi, piuttosto che essere troppo specifici così
definire che cosa significa una "piattaforma".
Le trasformazioni tra i diversi modelli assumono quindi un ruolo centrale nell’MDA in
quanto si richiede quasi sempre una grande quantità di lavoro nel definire queste
trasformazioni, che spesso richiedono conoscenze specialistiche del dominio aziendale, le
tecnologie utilizzate per l'attuazione, o entrambi. Efficienza e qualità dei sistemi possono
essere migliorate mediante l'acquisizione queste trasformazioni in modo esplicito e
riutilizzare in modo coerente le soluzioni. Dove i diversi modelli astratti sono ben definiti,
è possibile utilizzare le trasformazioni standard. Ad esempio, tra modelli di progettazione
espressi in UML e implementazioni in J2EE possiamo usare frequentemente i modelli di
9
In informatica la Java Platform, Enterprise Edition o Java EE (conosciuta, prima della versione 5, col nome di Java 2
Enterprise Edition o J2EE) è una piattaforma software di programmazione principalmente sviluppata in linguaggio di
programmazione Java e ampiamente utilizzata nella programmazione Web.
10
La suite di prodotti .NET (tutto in lettere maiuscole, pronunciato dotnet) è un progetto all'interno del quale Microsoft
ha creato una piattaforma di sviluppo software, .NET, che è una versatile tecnologia di programmazione ad oggetti.
15
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
trasformazione ben compresi da UML a J2EE che possono essere applicati in modo
coerente, convalidato e automatizzato.
Alla base di queste rappresentazioni del modello, e a sostegno delle trasformazioni, i
modelli sono descritti in una serie di metamodelli. La capacità di analizzare,
automatizzare, e trasformare i modelli richiede un chiaro, inequivocabile modo di
descrivere la semantica dei modelli. Quindi, i modelli intrinseci di un approccio di
modellazione
devono essere descritti in un modello, che noi chiamiamo un
metamodello11. Così, per esempio, la semantica e la notazione di UML viene descritta in
metamodelli. Produttori di strumenti si rivolgono ai metamodelli standard di UML quando
vogliono implementare UML in un modo standard. Ad esempio, il metamodello UML
descrive in dettaglio il significato preciso di una classe, il significato di un attributo, e il
significato delle relazioni tra questi due concetti.
L'OMG ha riconosciuto l'importanza dei metamodelli della semantica formale per la
modellazione essenziale per il loro uso pratico. Come risultato, l’OMG definito un insieme
di livelli metamodeling, e definito un linguaggio standard per esprimere metamodelli,
Facility Meta-Object (MOF). Un metamodello MOF si usa per definire formalmente la
sintassi astratta di un insieme di costrutti di modellazione.
I modelli e le trasformazioni tra di essi saranno specificati utilizzando standard aperti.
Attraverso standard come CORBA12, IIOP13, UML, e CWM l'industria del software sta
godendo di un livello di interoperabilità dei sistemi che in precedenza era impossibile,
inoltre,come strumento di interoperabilità è agevolato anche a seguito di strumenti di
interscambio, come MOF e XMI.
11
La Metamodellazione o Meta-modellazione (in inglese Metamodeling), in Ingegneria del Software e in Ingegneria dei
Sistemi è l'analisi, la costruzione e lo sviluppo di strutture, regole, vincoli, modelli e teorie applicabili e utili per la
modellazione di classi predefinite di problemi.
12
CORBA (Common Object Request Broker Architecture) è uno standard sviluppato da OMG per permettere la
comunicazione fra componenti indipendentemente dalla loro distribuzione sui diversi nodi della rete o dal linguaggio di
programmazione con cui siano stati sviluppati.
13
La specifica IIOP definisce un insieme di regole di formattazione dei dati, chiamato CDR (Common Data
Representation), che è su misura per i tipi di dati supportati nella Definition Language CORBA IDL (Interface).
16
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
1.3 Testing
Il Model Based Testing (MBT) è diventato un po 'una parola d'ordine in questi ultimi
anni, e questo termine viene usato per una vasta gamma di tecniche di generazione di
test[3]. Di seguito sono riportati i quattro approcci principali conosciuti come test modelbased:
1 Generazione dei dati di input di test da un modello nel dominio
2 Generazione di casi di test da un modello di ambiente
3 Generazione di casi di test con predittori di un modello di comportamento
4 Generazione di script di test di prove astratte
Quando l’MBT è usato per la generazione dei dati di input di test, il modello sono le
informazioni nel dominio dei valori di input e la generazione dei test prevede la selezione
e la combinazione di un sottoinsieme di questi valori per produrre dati di input di test.
Nel secondo caso l’MBT utilizza un diverso tipo di modello, che descrive l'ambiente
previsto della System Under Test (SUT)14.
Il terzo caso dell’MBT è la generazione di casi di test eseguibili che includono
informazioni di predizione, come ad esempio i valori di output attesi della SUT, o qualche
controllo automatico sui valori di uscita effettivi per vedere se queste sono corrette.
Il quarto caso dell’MBT è molto diverso: si presume che ci viene data una descrizione
astratta di un caso di test, come ad esempio un diagramma di sequenza UML o una
sequenza di chiamate di procedura ad alto livello, e si concentra sulla trasformazione che
astrae il test case in uno script di test di basso livello che è eseguibile.
Definiamo quindi l’MBT come l'automazione della progettazione di black-box test.
La differenza dal solito black-box test è quindi che piuttosto che scrivere manualmente i
test basati sulla documentazione, si crea un test basato su un modello del comportamento
14
I modelli possono essere utilizzati per rappresentare il comportamento desiderato di un sistema in prova (SUT), o per
rappresentare le strategie di sperimentazione e di un ambiente di test.
17
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
SUT atteso, che cattura alcuni dei requisiti. Quindi vengono utilizzati gli strumenti MBT
per generare automaticamente i test di quel modello specifico.
Possiamo quindi dire che il Model-Based Testing è l'automazione della progettazione di
black-box test.
Una volta che abbiamo un modello del sistema da testare, possiamo utilizzare uno degli
strumenti di MBT per generare automaticamente una suite di test. Ora ci sono alcuni
strumenti di test basati su modelli commerciali e accademici disponibili, sulla base di una
varietà di metodi e notazioni.
Molti degli strumenti consentono di guidare il processo di generazione del test per
controllare il numero di prove prodotte o per concentrare gli sforzi di test su alcune aree
del modello.
L'uscita del generatore del test case sarà un insieme di casi di test astratti, ciascuno
dei quali è una sequenza di operazioni con i valori di input associate a valori di uscita
previsti (predittore). Cioè, i casi di test generati saranno espressi in termini di operazioni
astratte e dei valori utilizzati dal modello.
Il passo successivo è quello di trasformare (concretizzare) i casi di test astratti in
script di test eseguibili. Questo può essere fatto dagli strumenti di model-based testing,
utilizzando alcuni modelli e tabelle di conversione fornite dal test engineer.
Le risultanti sono dei test eseguibili che possono essere prodotti direttamente in un
linguaggio specifico di programmazione, come ad esempio i test JUnit 15in Java16, o in un
linguaggio dinamico come Python17o Tcl18, o in un linguaggio di scripting di prova
dedicato.
15
JUnit è un framework di unit testing per il linguaggio di programmazione Java
Java è un linguaggio di programmazione orientato agli oggetti, specificatamente progettato per essere il più possibile
indipendente dalla piattaforma di esecuzione.
17
Python è un linguaggio di programmazione dinamico orientato agli oggetti utilizzabile per molti tipi di sviluppo
software
18
In informatica Tcl (acronimo di Tool Command Language), è un linguaggio di scripting creato da John Ousterhout
generalmente considerato di facile apprendimento (rispetto ai linguaggi della sua generazione), ma allo stesso tempo
potente.
16
18
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
1.4 Standard
Come detto in precedenza esistono vari standard che vengono usati nell’approccio Model
Driven Architecture. La chiave del successo dell'integrazione e dell'interoperabilità risiede
nell'uso intelligente e nella gestione dei metadati19 per tutte le applicazioni, piattaforme,
strumenti e banche dati. La gestione dei metadati e l'integrazione può essere realizzata
attraverso l'utilizzo di norme fondamentali MDA della OMG: CWM, MOF, XMI, UML e
SysML[4].
1.4.1 CWM
Il Common Warehouse Metamodel (CWM) definisce una rappresentazione di metadati sia
business che tecnici che spesso si trovano nel dominio del data warehousing20e del
business analysis21 [CWM]. È usato come base per l’interscambio di istanze di metadati
tra sistemi eterogenei e sistemi multi-vendor di software (cioè, per integrare le
informazioni di data warehousing e business analysis "supply chain").
CWM è in realtà composto da un certo numero di metamodelli costituenti che
rappresentano le risorse di dati, analisi, data warehousing, e le componenti fondamentali di
un tipico ambiente di data warehousing/business.
CWM rappresenta un approccio model-based per l'interscambio dei metadati tra i
sistemi software. I metadati condivisi tra i prodotti sono formulati in termini di modelli di
dati che sono coerenti con uno o più metamodelli CWM. Un prodotto di esportazione dei
metadati attraverso la formulazione di un modello delle sue strutture interne di metadati in
un formato stabilito dalla CWM.
La varietà di metamodelli forniti da CWM è abbastanza completa per modellare un
19
Un metadato (dal greco μετὰ "oltre, dopo" e dal latino datum "informazione" - plurale: data), letteralmente "(dato)
oltre un (altro) dato", è un'informazione che descrive un insieme di dati.
20
Un data warehouse (o DW, o DWH) (termine inglese traducibile con magazzino di dati) è un archivio informatico
contenente i dati di un'organizzazione, progettati per consentire di produrre facilmente analisi e relazioni utili a fini
decisionali-aziendali.
21
Business analysis è una disciplina di ricerca che identifica le esigenze aziendali e determina le soluzioni ai problemi
di business
19
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
intero data warehouse. L’utilizzo di strumenti CWM-aware, in un istanza di data
warehouse potrebbe essere generato direttamente da un warehouse model. Ognuno dei
strumenti utilizza quelle parti del modello di cui può farne uso. Ad esempio, un server di
database relazionale utilizzerà la parte relazionale del modello e lo userà per costruire il
suo catalogo. Allo stesso modo, un server OLAP22 cercherà il modello per i metadati
OLAP e lo userà per definire lo schema multidimensionale. I modelli CWM sono descritti
per essere molto generici, rappresentazioni esterne di metadati condivisi. I metadati che
non facilmente si adattano al formato CWM (ad esempio, i metadati altamente specifici)
vengono gestite sia attraverso meccanismi di estensione standard forniti da CWM,
attraverso le estensioni al nucleo metamodello CWM, o alltraverso l’uso di prodotti
specifici di default.
1.4.2 UML
UML è un linguaggio di modellazione e specifica basato sul paradigma object-oriented. Il
nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar
Jacobson (detti "i tre amigos") sotto l'egida dello Object Management Group, consorzio
che tuttora gestisce lo standard UML. Il linguaggio nacque con l'intento di unificare
approcci precedenti (dovuti ai tre padri di UML e altri), raccogliendo le migliori prassi nel
settore e definendo così uno standard industriale unificato.
L'UML svolge un'importantissima funzione di "lingua franca" nella comunità della
progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa UML
per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un
vasto pubblico.
L'ultima versione del linguaggio, la 2.0, è stata consolidata nel 2004 e ufficializzata da
OMG nel 2005. UML 2.0 riorganizza molti degli elementi della versione precedente (1.5)
22
OLAP, acronimo che sta per l'espressione On-Line Analytical Processing, designa un insieme di tecniche software
per l'analisi interattiva e veloce di grandi quantità di dati, che è possibile esaminare in modalità piuttosto complesse
20
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
in un quadro di riferimento ampliato e introduce molti nuovi strumenti, inclusi alcuni
nuovi tipi di diagrammi. Sebbene OMG indichi UML 2.0 come la versione "corrente" del
linguaggio, la transizione è di fatto ancora in corso; le stesse specifiche pubblicate da
OMG sono ancora non completamente aggiornate e il supporto dei tool a UML 2.0 è, nella
maggior parte dei casi, appena abbozzato.
La notazione UML è semi-grafica e semi-formale; un modello UML è costituito da una
collezione organizzata di diagrammi correlati, costruiti componendo elementi grafici (con
significato formalmente definito), elementi testuali formali, ed elementi di testo libero. Ha
una semantica molto precisa e un grande potere descrittivo.
Il linguaggio è stato progettato con l'obiettivo esplicito di facilitare il supporto software
alla costruzione di modelli e l'integrazione di questo supporto con gli ambienti integrati di
sviluppo. OMG, in particolare, gestisce una famiglia di standard correlata a UML, detta
Model Driven Architecture (MDA), che ha lo scopo di fornire le fondamenta concettuali e
semantiche per lo sviluppo di ambienti evoluti di round-trip engineering in cui la
modellazione UML, in qualche misura, possa sostituire di fatto la programmazione
tradizionale.
Sebbene
questo
obiettivo
sia
ancora
da
raggiungere,
molti
IDE23comprendono strumenti di modellazione in UML e forniscono meccanismi
automatici di traduzione parziale dei diagrammi UML in codice e viceversa. Viceversa,
molti ambienti software dedicati alla modellazione in UML consentono di generare codice
in diversi linguaggi.
1.4.3 MOF
Meta Object Facility (MOF) è uno standard OMG di definizione di un linguaggio astratto
comune per la specifica di metamodelli.
23
Integrated Development Environment ovvero IDE è un software che, in fase di programmazione, aiuta i
programmatori nello sviluppo del codice sorgente di un programma.
21
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
MOF è nettamente orientato agli oggetti. Esso definisce gli elementi essenziali, la sintassi
e la struttura di metamodelli che vengono utilizzati per costruire modelli object-oriented di
sistemi discreti. MOF serve da modello comune di entrambi i metamodelli CWM e UML.
In particolare, la specifica MOF prevede:
· Un modello astratto degli oggetti MOF generici e le loro associazioni.
· Un insieme di regole per mappare qualsiasi metamodello basato su MOF per le
interfacce indipendenti dalla lingua (definita in CORBA IDL). L'implementazione di
queste interfacce per un dato metamodello è utilizzato per accedere e modificare qualsiasi
modello sulla base di tale metamodello.
· Regole che definiscono il ciclo di vita, la composizione, e la semantica di chiusura degli
elementi di metamodelli basati su MOF.
· Una gerarchia di interfacce. Questi definiscono operazioni generiche per scoprire e
manipolare modelli basati su metamodelli MOF-compliant, ma le cui interfacce mappate
sono sconosciute.
Il potere di MOF è quello di consentire a metamodelli dissimili (che rappresentano diversi
domini) di poterli utilizzare in maniera interoperabile.
La semantica MOF generalmente definisce servizi di repository24 di metadati che
supportano la costruzione del modello, la sua evuluzione, e aggiornamento, in cui i
modelli si allocano con le istanze di qualche particolare metamodello. In particolare, il
sostegno del MOF per la semantica del ciclo di vita di un modello. Ad esempio,
metamodelli di nuova concezione possono essere persistenti nel repository MOF e
combinati con metamodelli esistenti secondo la semantica di composizione del ciclo di
vita MOF. Interfacce del modello e le implementazioni predefinite possono essere
generate e messe a disposizione per l'ambiente. Implementazioni predefinite sono
24
Un repository è un ambiente di un sistema informativo, in cui vengono gestiti i metadati, attraverso tabelle
relazionali; l'insieme di tabelle, regole e motori di calcolo tramite cui si gestiscono i metadati prende il nome di
metabase.
22
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
ulteriormente rafforzate con l'inserimento di ulteriore logica programmata, o scritti a mano
o generate da strumenti o tools.
1.4.4 XMI
XML Metadata Interchange (XMI) è uno standard OMG che associa il MOF al
W3C eXtensible Markup Language
25
(XML). XMI definisce le regole di come tag XML
vengono utilizzati per rappresentare serializzati modelli MOF-compatibili in XML.
Metamodelli basati su MOF sono convertiti in XML Document Type Definition26 (DTD) e
modelli sono tradotti in documenti XML che sono coerenti con le loro DTD
corrispondenti. XMI risolve molti dei problemi che si incontrano quando si cerca di
utilizzare un linguaggio basato su tag per rappresentare oggetti e le loro associazioni.
Inoltre, il fatto che XMI è basato su XML significa che entrambi i metadati (tag) e le
istanze che descrivono (contenuto dell'elemento) possono essere confezionati insieme
nello stesso documento, permettendo alle applicazioni di poter comprendere le istanze
tramite il loro metadati. La comunicazione tra i contenuti è selfdescribing27 e
intrinsecamente asincrona. Per questo motivo l’interscambio basato su XMI è così
importante, in ambienti eterogenei distribuiti.
25
XML (sigla di eXtensible Markup Language) è un linguaggio di markup, ovvero un linguaggio marcatore basato su
un meccanismo sintattico che consente di definire e controllare il significato degli elementi contenuti in un documento o
in un testo.
26
Il Document Type Definition (definizione del tipo di documento) è uno strumento utilizzato dai programmatori il cui
scopo è quello di definire le componenti ammesse nella costruzione di un documento XML.
27
In informatica self-document o self-describing denota un descrittore comune per il codice sorgente e le interfacce
utente che seguono alcune convenzioni definite per la denominazione e struttura.
23
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Capitolo 2: Il linguaggio di modellazione SysML
Con il termine Systems Modeling Language (SysML) si intende un’estensione UML
utilizzata per la modellazione di sistemi software e hardware. SysML Supporta la
definizione di specifiche, analisi, progettazione, validazione e verifica sia di sistemi e
sottosistemi, che possono includere software, hardware, processi.
Systems Modeling Language (SysML) è quindi un linguaggio per la modellazione visuale
per applicazioni di Ingegneria dei Sistemi.
SysML è un’estensione di UML 2, ed è definito come un profilo UML 2 ( per
Profilo si intende la personalizzazione UML che utilizza stereotipi, Tagged values, e
vincoli.). Nella figura seguente è mostrata la storia cronologica in ordine di tempo
dell’evoluzione del’espressioni semantiche (Figura 3):
24
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 3: Storia del SysML
La specifica SysML è stata creata dai SysML Partners, un gruppo di sviluppatori di tool
software e aziende leader nel settore, che nel 2003 si organizzarono per creare un dialetto
di UML per Ingegneria dei Sistemi chiamato SysML (Systems Modeling Language). I
SysML partner realizzarono SysML come specifica open source per soddisfare i requisiti
di "UML per Ingegneria dei Sistemi" della OMG RFP, e le loro specifiche includono una
licenza open source per la distribuzione e l'uso.
SysML è stato originariamente sviluppato come un progetto open source nel 2003, in
risposta a "UML per Ingegneria dei Sistemi" di OMG RFP(Request of Proposal). SysML
contiene nove tipi di diagrammi, sette dei quali condivide in comune con la sua lingua
madre, insieme con una notazione tabellare (tabelle di allocazione.) La specifica SysML è
disponibile per il download, e comprende una licenza open source per la distribuzione e
l'uso. La revisione più recente è SysML v 1.3 [11].
SysML è definito come un dialetto (profilo) di UML 2.x, il linguaggio di modellazione
standard nel settore per le applicazioni software-intensive. Il vantaggio di definire SysML
25
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
come un profilo UML è che si può riutilizzare la notazione relativamente matura e la
semantica di UML 2.x, che molti produttori di strumenti di modellazione hanno già
attuato. Lo svantaggio di specificare SysML come un profilo UML è che SysML eredita
molti dei problemi connessi con UML 2.x, come notazione la complessa, la semantica
imprecisa, e uno standard di interoperabilità di schema disfunzionale (XMI). In figura
(Figura 4) sono mostrati i due macroinsieme SysML e UML e la loro intersezione:
Figura 4: Rappresentazione degli insiemi UML e SysML
SysML offre ai sistemisti i seguenti vantaggi rispetto UML per impianti System-toSystem,
nello specifico:
• SysML esprime la semantica di Ingegneria dei sistemi (interpretazioni delle notazioni)
meglio di quanto non faccia UML. Si riduce la distorsione del software UML e aggiunge
due nuovi tipi di diagrammi per la gestione dei requisiti e analisi delle prestazioni:
rispettivamente, Diagrammi Requisito e Diagrammi parametrici.
• SysML è più piccolo e più facile da imparare rispetto UML. Il linguaggio globale è più
piccolo misurata in tipi di diagrammi (9 vs 13) e costrutti totali.
26
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
• Costrutti di gestione del modello SysML supportano la specifica di modelli, opinioni,
punti di vista e che sono architettonicamente allineati con IEEE-Std-1471-2000 (IEEE
Metodo raccomandato per la descrizione architettonica di Sistemi Software-Intensive).
Come detto in precedenza, SysML non è una lingua indipendente; si tratta di un profilo, o
estensione UML creato appositamente per l'ingegneria dei sistemi. UML è stato progettato
per essere un linguaggio di modellazione standard per il dominio del software. Nonostante
sia stato in gran parte utilizzato UML per la modellazione dei Sistemi, questo poneva dei
grandi limiti.
Ad esempio, i modelli UML possono contenere elementi di tipo dati. Gli Ingegneri
software possono utilizzare un tipo di dati (ad esempio, numero intero) in un modello
UML per specificare il tipo di un attributo all'interno di una classe, il tipo di un oggetto
che può fluire attraverso un'attività, e il tipo di un parametro all'interno di un'operazione.
I Sistemisti, tuttavia, si preoccupano di altri tipi che possono fluire all’interno di un
sistema. Il concetto di DataType semplicemente non era sufficiente. Pertanto, SysML
introduce un nuovo tipo di elemento del modello chiamato ValueType, che estende il
concetto di DataType per fornire un termine più neutro per una più ampia gamma di tipi
nel dominio dell’ingegneria dei sistemi. Un ValueType quindi può essere inteso come una
specifica “qualità” attribuita ad un elemento del mio modello. Questa qualità può essere
definita da tipi già stabiliti, come string e boolean per UML, oppure essere definita da zero
(es. enumerazione).
SysML Partners fu fondata e diretta da Kris Kobryn, che in precedenza aveva presieduto il
team di specifica della 1.x UML e UML 2.0. Kobryn ha coniato il nome della lingua
"SysML" (abbreviazione di "Systems Modeling Language"), ha progettato il logo
originale SysML, e ha organizzato il team di progettazione del linguaggio di base come un
progetto open source. Sandy Friedenthal, presidente del Ingegneria dei Sistemi Special
Interest Group OMG, è stato vice presidente durante l'inizio del progetto.
27
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Nel 2001, prima che SysML Partnes venne creato e mentre Kobryn era ancora leader
UML2 Partners, David W. Oliver (1932-2011), co-presidente del INCOSE Model Driven
Design Working Group si avvicinò a Kobryn circa l’idea dell’UML for Systems
Engineering. Impressionato dalla passione e competenza per modellazione visuale di
Dave, e riconobbe che le componenti software e componenti hardware di un sistema
potessero avere più in comune di quanto si potesse pensare. Kobryn successivamente ha
diretto il team UML2 Partners per cercare di ridurre gradualmente gli aspetti softwarecentric all’interno della bozza per la specifica UML 2.0. Senza questo noioso ma
indispensabile lavoro di ristrutturazione della specifica UML 2.0, sarebbe stato
impensabile che il progetto di specifica open source SysMl sarebbe stato completato in
così poco tempo.
Ci sono nove tipi di diagrammi SysML (5 dei quali condivisi con UML) [12]:
• Block definition diagram (BDD)
• Internal block diagram (IBD)
• Use case diagram
• Activity diagram
• Sequence diagram
• State machine diagram
• Parametric diagram
• Package diagram
• Requirements diagram
Nella figura seguente (Figura 5) è riportata la struttura di derivazione di ogni diagramma:
28
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 5: Struttura a blocchi dell’UML e SysML
I Diagrammi possono essere così brevemente descritti:
• Il block definition diagram (BDD) è usato per visualizzare elementi come blocchi e tipi
di valore (elementi che definiscono i le cose che possono esistere in un sistema operativo)
e le relazioni tra questi elementi. Usi comuni per un BDD includono la visualizzazione di
alberi di gerarchia di sistema e alberi di classificazione.
• L’ internal block diagram (IBD) viene utilizzato per specificare la struttura interna di
un unico blocco. Più precisamente, una IBD mostra le connessioni tra le parti interne di un
blocco e le interfacce tra di esse.
• Lo use case diagram è utilizzato per trasmettere i casi d'uso che un sistema esegue e gli
attori che interagiscono tra di loro. Un use case diagram è una vista in black-box dei
servizi che un sistema esegue in collaborazione con i suoi attori.
• L’ activity diagram viene utilizzato per specificare un comportamento, con un focus sul
flusso di controllo e la trasformazione di input in output attraverso una sequenza di
29
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
operazioni. Diagrammi di attività sono comunemente usati come strumento di analisi per
comprendere ed esprimere il comportamento desiderato di un sistema.
• Il sequence diagram viene utilizzato per specificare un comportamento, con un focus su
come le parti di un blocco interagiscono tra loro attraverso chiamate a funzioni e segnali
asincroni. sequence diagram sono comunemente utilizzati come strumento di
progettazione dettagliata per specificare precisamente un comportamento come input per il
ciclo di vita in fase di sviluppo. I sequence diagram sono anche un eccellente meccanismo
per specificare i casi di test.
• lo state machine diagram viene utilizzato per specificare un comportamento, con un
focus sul set di stati di un blocco e le possibili transizioni tra questi stati in risposta al
verificarsi degli eventi. Uno state machine diagram, come un sequence diagram, è una
indicazione precisa del comportamento di un blocco che può servire come input per la fase
di sviluppo del ciclo di vita.
• Un parametric diagram è usato per esprimere come con uno o più vincoli, equazioni e
disequazioni, sono legati alle proprietà di un sistema. Parametric diagram supporta
l’engineering analyses, comprese le prestazioni, l'affidabilità, la disponibilità, il potere, la
massa e il costo. Parametric diagram possono essere utilizzati anche per sostenere gli studi
commerciali di candidati architetture fisiche.
• Un package diagram viene utilizzato per visualizzare il modo in cui un modello è
organizzato sotto forma di una gerarchia di pacchetto. Un package diagram può anche
mostrare gli elementi del modello che i pacchetti contengono e le dipendenze tra i
pacchetti e gli elementi del modello contenuto.
• Un requirements diagram viene utilizzato per visualizzare i requisiti basati su testo, le
relazioni tra i requisiti (di contenimento, derivazione requisito, e copia), e le relazioni tra
requisiti e gli altri elementi del modello che soddisfano, verificano, e raffinano.
Di seguito andremo ad analizzare i diagrammi SysML, con particolare attenzione verso i
Block Definition Diagram, Internal Block Diagram e Requirements Diagram, rifacendoci
30
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
alle descrizioni e alle notazioni presentate negli esempi di Delligatti [12], il quale prende
ad esempio un sistema satellitare, per poi andare nello specifico della nostra applicazione.
2.1 BDD
Lo scopo di creare un BDD è quello di modellare un molteplice numero di elementi di un
sistema e di relazionarli tra di loro, che siano componenti Hardware o Software e vedere le
varie relazioni e interazioni tra di essi.
Gli
elementi
che
compongono
un
block
definition
diagram
sono:
-package
-model
-modelLibrary
-view
-block
-constraintBlock
L'elemento base di un BDD e il package il quale rappresenta il namespace del nostro
progetto. Come prima cosa definiamo il nostro package che rappresenterà l'ambito di
sviluppo e tutti i suoi componenti . Di seguito (Figura 6) viene riportato un semplice
BDD:
31
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 6: Esempio BDD Strutturato
32
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Un blocco è l'unità di base della struttura in SysML. È possibile utilizzare un blocco per
modellare qualsiasi tipo di entità all'interno del sistema di interesse o nell'ambiente esterno
del sistema.
Si noti la distinzione tra definizione e la creazione di istanze (che SysML riferisce
come "uso"). Questa distinzione è uno dei concetti fondamentali di progettazione di
sistema, ed è un modello che ricorre spesso in SysML. Alcuni tipi di elementi del modello
(ad esempio blocks, value types, constraint blocks) rappresentano definizioni di tipi; altri
tipi di elementi del modello (ad esempio, part properties, value properties, constraint
properties) rappresentano istanze di tali tipi. Per analogia, un progetto di una casa è una
definizione di un tipo di casa; ad ogni casa un costruttore , basandosi sul progetto,
costruirà una casa per ogni lotto di terreno, il quale sarà un'istanza distinta di quel tipo.
Un blocco rappresenta un tipo di entità, e non un caso. Ad esempio, è possibile
creare un blocco denominato DesktopWorkstation nel modello di sistema. Tale blocco
rappresenterebbe un tipo che definisce un insieme di proprietà come monitor, tastiera,
mouse, CPU, produttore, spazio su disco, costi che sono comuni a tutte le istanze.
Ogni workstation desktop che un azienda IT acquisterà per ogni ufficio sarà un'istanza
distinta di quel blocco DesktopWorkstation.
Si può facilmente capire la differenza tra elementi di definizione ed elementi di
utilizzo in un modello di sistema. Elementi di definizione hanno un nome solo (ad
esempio, DesktopWorkstation); elementi di utilizzo hanno un nome e un tipo, separati da
due punti (ad esempio, SDX1205LJD: DesktopWorkstation). La notazione di un blocco è
un rettangolo con lo stereotipo «blocco» che precede il nome nel vano nome (Figura 7):
33
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 7: Esempio notazione BDD
Vi sono due tipi di caratteristiche: caratteristiche strutturali (note anche come proprietà) e
le caratteristiche comportamentali.
Ecco i componenti facoltativi che è possibile
visualizzare in ogni blocco:
• Parts
• References
• Values
• Constraints
• Operations
• Receptions
• Standard ports (in SysML v1.2 and earlier)
• Flow ports (in SysML v1.2 and earlier)
• Full ports (in SysML v1.3)
• Proxy ports (in SysML v1.3)
• Flow properties (in SysML v1.3)
• Structure
Le caratteristiche strutturali servono a descrivere il nostro modello in base alle parti di cui
è composto. Ci sono cinque tipi di caratteristiche strutturali (conosciuto anche come
34
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
proprietà) che un blocco può possedere:
• Part properties
• Reference properties
• Value properties
• Constraint properties
• Ports
Part properties rappresentano una struttura che è interna ad un blocco. Un blocco è
composto dalle sue part properties. Questa relazione esprime la proprietà.
Una Reference properties rappresenta una struttura che è esterna ad un blocco.
Value properties può rappresentare un quantitativo (di un certo tipo), un valore booleano
o una stringa. Le Value properties sono particolarmente utili in combinazione con le
proprietà di vincolo per costruire un modello matematico del sistema.
Constraint properties rappresentano generalmente delle relazioni matematiche (equazioni
o disequazioni) che vengono impostate su un insieme di value properties.
Una Port è un tipo di proprietà che rappresenta un punto di interazione distinto al confine
di una struttura attraverso la quale entità esterne che possono interagire con struttura sia
per fornire o per richiedere un servizio o per scambiare materia, energia o dati. SysML
v1.2 (e precedenti) definisce due tipi di porte ovvero standard-port e flow-port, che è
possibile aggiungere a un blocco per specificare diversi aspetti della sua interfaccia. Una
standard-port consente di specificare un punto di interazione con un focus sui servizi che
un blocco fornisce o richiede; una flow-port consente di specificare un punto di
interazione con un focus sui tipi di materia, energia o dati che possono fluire dentro e fuori
35
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
di un blocco.
Il modello Standard-port definisce i servizi che un blocco fornisce o richiede a un
punto di interazione sul suo confine. Si divide in interfacce richieste e interfacce offerte.
Le interfacce richieste rappresentano le cose che vengono ricevute dal blocco, mentre le
interfacce offerte rappresentano le operazioni che possono essere effettuate dal blocco
(Figura 8).
Figura 8: Vista di due interfacce con le rispettive operations e receptions in un BDD
Il modello flow-port definisce le flow-specification. Come un blocco, una flowspecification è un elemento di definizione che definisce un insieme di proprietà di flusso
che può fluire dentro o fuori di flow-port (Figura 9).
Figura 9: Modello flow-port in un BDD
Nella maggior parte dei progetti di modellazion non è sufficiente specificare solo le parti, i
riferimenti, i vincoli, le proprietà, e le porte di un blocco. Sono importanti, ma che
trasmettono solo un aspetto del design.
36
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Un aspetto altrettanto importante è l'insieme di comportamenti che un blocco può avere. Si
trasmettere questo aspetto della progettazione con l'aggiunta di caratteristiche
comportamentali ad un blocco.
SysML offre due tipi di caratteristiche comportamentali: operations and receptions.
Un' operations rappresenta un comportamento che un blocco esegue quando un client
invoca un servizio. Un’operations viene richiamata quando si scatena un evento di tipo
chiamata. Un receptions rappresenta un comportamento che un blocco esegue quando un
client invia un segnale che lo attiva. Una receptions viene richiamata quando si scatena da
un evento di tipo segnale. La differenza sostanziale tra i due sta nel tipo di evento che
scatena l’azione, ovvero nel primo caso avrò una lista di operazioni che il mio blocco può
effettuare e che possono essere richiamate, mentre nel secondo caso avrò una lista di
segnali di ricezione i quali quando attivi scateneranno una serie di operazioni definite nel
blocco(Figura 7).
Un’altra parte importante nella modellazione dei sistemi sono le relazioni che si possono
modellare tra i vari blocchi.
Ci sono tre tipi principali di relazioni che possono esistere tra blocchi: associazioni,
generalizzazioni e le dipendenze. Le associazioni rappresentano dei legami tra 2 o più
entità, le generalizzazioni identifica la specializzazione di un particolare blocco, mentre le
dipendenze indicano una relazione nella quale un entità dipende da un’altra entità.
Vi sono poi 2 tipi di associazione: Reference Association e Composite Association.
Una Reference Association tra due blocchi significa che può esistere una connessione tra
istanze di tali blocchi in un sistema operativo e queste istanze possono accedersi a vicenda
per qualche scopo attraverso la connessione. Una Composite Association tra due blocchi
indica la decomposizione strutturale. Un'istanza del blocco è costituita da un certo numero
di istanze dei blocchi di cui è composto (Figura 10 e Figura 11).
37
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 10: Esempio di instanza in un BDD
Figura 11: Esempio di composizione in un BDD
38
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Vi sono poi altri oggetti di cui può essere composto un BDD, e sono: gli attori, i
ValueType e i commenti.
Un attore rappresenta qualcuno o qualcosa che ha una interfaccia esterna con il
sistema. Il nome di un attore trasmette un ruolo svolto da una persona, un'organizzazione o
un altro sistema quando interagisce con il sistema (Figura 12).
Figura 12: Attori in un BDD
Come un blocco, un valueType è un elemento di definizione che definisce generalmente
un tipo di quantità. È possibile utilizzare un valueType spesso in un modello. Il più delle
volte, esso appare come il tipo di una valueType, che è una sorta di caratteristica
strutturale dei blocchi (Figura 13).
39
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 13: Esempio di definizione di tipo in un BDD
Come un blocco, un Constraint Blocks è un elemento di definizione di uno che definisce
un'espressione di vincolo booleana (un'espressione che deve restituire true o false). Il più
delle volte, l'espressione di vincolo si definisce in un Constraint Blocks è un'equazione o
una disuguaglianza: una relazione matematica che consente di vincolare le proprietà del
valore di blocchi (Figura 14).
40
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 14: Esempio di constraint in un BDD
Un commento è un elemento del modello. È costituito da un singolo attributo: una stringa
di testo chiamato corpo. È possibile trasmettere tutte le informazioni necessarie al corpo di
un commento, ed è possibile allegare un commento ad altri elementi su un diagramma per
fornire ulteriori informazioni su di loro (Figura 15).
41
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 15: Esempio di commenti in un BDD
2.2 IBD
Lo schema a blocchi interno (IBD) ha una stretta relazione con il BDD. È possibile
visualizzare i vari elementi su una IBD per esprimere aspetti della struttura di un sistema
che integrano gli aspetti dei BDD (Figura 16).
L’IBD permette di avere una visione interna di ogni singolo blocco contenuto
all’interno dei BDD per definirne gli aspetti strutturali e comportamentali di ogni sua
singola parte.
42
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Gli elementi che compongono un IBD sono:
Part Properties
Reference Properties
Connectors
Item Flows
Una Part Properties IBD ha lo stesso significato di Part Properties di un blocco su un
BDD: Rappresenta una struttura che è interna al blocco e di cui il blocco è composto. La
notazione per una Part Propertiessu IBD è un rettangolo con un bordo continuo.
Una Reference Properties su IBD ha lo stesso significato di una Reference Properties di un
blocco su un BDD: Rappresenta una struttura che è esterno al blocco e che serve al blocco
per qualche scopo, sia per invocare comportamenti o scambiare materia, energia o dati.
Un Connectors tra due parti in un IBD associa l’idea di un collegamento fisico tra le due
entità le quale comunicheranno tra di loro in maniera opporutuna. È possibile specificare
un nome e tipo per un Connectors per trasmettere ulteriori informazioni sul mezzo che
collega queste due strutture.
Un Item Flows rappresenta un tipo di materia, energia, o dati che scorre tra due strutture
all'interno di un sistema. La notazione per un flusso oggetto su un IBD è compilato freccia
triangolare su un connettore che unisce due porte di flusso. Il tipo che il flusso voce
rappresenta compare nell’etichetta accanto alla freccia sul connettore; l'etichetta deve
contenere il nome di un blocco, tipo di valore, o il segnale che esiste da qualche parte nel
modello di sistema.
43
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 16: Esempio di IBD
2.3 RD
Un altro tipo di schema essenziale SysML è il diagramma requisiti.
I progettisti utilizzano in genere sei tipi di relazioni per stabilire la tracciabilità tra i
requisiti in materia di tracciabilità dai requisiti alle strutture e ai comportamenti del
modello di sistema. È possibile utilizzare diverse notazioni sui diagrammi dei requisiti di
esprimere queste relazioni, e ognuno ha punti di forza e di debolezza.
I requisiti di un sistema informano su ogni altro aspetto del suo design. Il
diagramma requisiti è il mezzo primario di SysML per il trasporto di questo genere di
44
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
informazioni.
Nella figura seguente (Figura 17) vi è riportato un esempio di un tipico Requirements
Diagram relativo ad un particolare sottoinsieme del nostro sistema:
Figura 17: Un esempio di Requirements Diagram
Li elementi base che compongono il nostro diagramma sono:
• package
• model
45
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
• modelLibrary
• view
• requirement
L'elemento del modello che è chiamato nell'intestazione del diagramma è il namespace
predefinito per gli elementi mostrati nell'area dei contenuti. Un namespace è
semplicemente un elemento del modello dove sono contenuti gli altri elementi del
modello. Ciò significa che un namespace può avere elementi nidificati all’interno di esso
nella gerarchia del modello. Un namespace è un concetto che ha senso solo all'interno del
modello del sistema e non nel caso specifico.
Soffermandoci sugli elementi di un RD, andiamo ad analizzare nel dettagli i package e i
requirement. I package come visto in precedenza sono dei contenitori di requisiti che
rappresentano una parte del nostro sistema in esame. Si può vedere nella Figura 17 che
ogni package è associato ad un namespace specifico. I requisiti invece rappresentano
l’unità principale del nostro diagramma. Rappresentano le specifiche fornite dal cliente le
quali poi verranno mappate all’interno del nostro sistema. Il Requirement block è un
blocco rettangolare che al suo interno conterrà il’ID e il Text entrambi di tipo string. L’ID
identifica in maniera univoca il requisito mentre il Text rappresenta il testo del requisito
associato. Nella pratica però un requisito non è formato solo da queste due proprietà: vi
sono tutta una serie di proprietà (ad esempio logica, prioritaria, metodo di verifica,
criticità) che potrebbero essere o no di interesse a seconda del particolare caso di
applicazione. Ad oggi SysML tratta solo le proprietà di ID e Text, ma mette a disposizione
lo strumento dei commenti per poter aggiungere in maniera opportuna ulteriori notizie ai
requisiti.
Un elemento importante e fondamentale nel RD sono le relazioni tra i requisiti: ci sono sei
tipi di relazioni tra i requisiti: contenimento, tracciabilità, derivazione di requisito,
46
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
raffinare, soddisfazione, e verifica. Queste relazioni stabiliscono la rintracciabilità
all'interno del modello, che è di solito un requisito processo nelle organizzazioni sistemi di
ingegneria.
Come detto in precedenza, una parte importante dei diagrammi dei requisiti, sono le
relazioni tra i requisiti e gli elementi del nostro sistema. Adesso andremo ad analizzare
uno per uno ogni tipo di relazione e andremo a capirne l’importanza e l’uso all’interno del
nostro diagramma.
Un package è una sorta di namespace; può contenere altri elementi denominati all'interno
della gerarchia del modello. Un requisito è anche una sorta di namespace; esso, inoltre,
può contenere altri elementi denominati all'interno della gerarchia del modello. Ma ha un
vincolo che un pacchetto non ha: Un requisito può contenere solo altri requisiti. Di qui il
concetto di relazione di contenimento, ovvero: è una relazione di contenimento nel senso
di raggruppare i requisiti per insiemi o gruppi di requisiti. Questa relazione server ad avere
sia una vista più chiara del nostro sistema (dividere i requisiti in gruppi ne facilita la
comprensione) sia perché in questo modo è più facile risalire, in un sistema complesso,
alle specifiche. Tale relazione viene mostrata all’interno del nostro diagramma da una
linea terminante con un cerchio al cui interno vi è il simbolo di somma (Figura 17).
Formalmente, la relazione di tracciabilità è una sorta di dipendenza. La notazione di una
relazione di trace è la stessa di quella di un-una dipendenza, ovvero linea tratteggiata con
una freccia aperta, a meno «trace» come stereotipo applicato ad esso (Figura 17).
Il rapporto trace, tuttavia, è un rapporto debole. Esso trasmette nient'altro che una
dipendenza base ovvero: Una modifica all'elemento fornitore (alla fine freccia) può
comportare la necessità di modificare l'elemento client (alla fine della coda).
Una relazione di derivazione di requisito è un altro tipo di dipendenza. La notazione di una
relazione di derive requirement è quindi uguale a quello per una dipendenza, ma ha il
47
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
«deriveReqt» come stereotipo applicato ad esso(Figura 17). Questo tipo i relazione indica
che un requisito è derivato da un altro, nella misura in cui i requisiti derivati (dal fornitore)
vengono aggiunti per meglio definire i requisito da cui viene derivato (fornito dal cliente).
Una relazione di refine è un altro tipo di dipendenza. La notazione di una relazione di
raffinazione è lo stesso di quello per una dipendenza, ma con «refine» come stereotipo
applicato ad esso(Figura 17). Questo tipo di relazione sta ad indicare un raffinamento della
specifica del cliente definita dal fornitore
SysML non impone vincoli sui tipi di elementi che possono comparire alle due estremità
in una relazione di refine. La convenzione comune, tuttavia, è quello di perfezionare un
testo, requisito funzionale utilizzando un caso d'uso. Un caso-uso più precisamente,
accompagnato dai suoi dettagli di specifica, cosa che il solo testo non può fare.
Una relazione di soddisfa è un altro tipo di dipendenza. La notazione di una relazione di
satisfy è la stessa di quella per una dipendenza, ma con
«satisfy» come stereotipo
applicato ad esso(Figura 17). Questa relazione deve avere un requisito all'estremità del
fornitore. SysML impone vincoli sul tipo di elemento che può apparire sul lato client. Per
convenzione, tuttavia, l'elemento client è sempre un blocco. Questa relazione sta ad
indicare come vengono allocati i requisiti rispetto ai blocchi componenti il nostro sistema.
Una relazione di verifica è un altro tipo di dipendenza. La notazione per una relazione di
verify è lo stesso di quello per una dipendenza, ma con «verify» come stereotipo applicato
ad esso(Figura 17). Come la relazione di satisfy, la relazione di verify deve avere un
requisito all'estremità del fornitore. SysML impone vincoli sul tipo di elemento che può
apparire sul lato client. Per convenzione, tuttavia, l'elemento client è sempre un test case.
Un test case è semplicemente un comportamento che si definisce da qualche parte nel
modello che si crea al fine di invocare la funzionalità di una particolare struttura per
verificare se si soddisfa uno o più dei requisiti ad esso assegnati. Un test case può essere
48
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
uno qualsiasi dei tre tipi di comportamenti: di attività, di interazione, o macchina a stati.
Tuttavia, un test case è spesso modellato come un'interazione (e visualizzato su un
diagramma di sequenza).
49
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Capitolo 3: Strumenti di supporto
Vi sono vari tipologie di software a nostra disposizione che si possono utilizzare per
realizzare un progetto simile. Infatti abbiamo tool che permettono la progettazione e la
realizzazione di un sistema fino alla generazione del codice, altri che arrivano alla
generazione dei test pattern, altri ancora che utilizzano standard open source quali XMI e
altri che presentano formati proprietari (es SCADE che rappresenta i dati in un proprio
formato) e altri che implementano il paradigma UML2. In questo lavoro di tesi sono stati
utilizzati i programmi Eclipse-Papyrus e IBM Rational Rhapsody Developer, questo
perché con il primo si è realizzata la progettazione del sistema tramite il paradigma
SysML mentre con il secondo a partire dal primo si è passati alla realizzazione del sistema
e alla generazione del codice ad esso annesso. Esaminiamo ora le caratteristiche dei
programmi e dei tool, ovvero Eclipse con il tool di sviluppo per SysML Papyrus e IBM
Rationa Rhapsody Developer.
3.1 Eclipse-Papyrus
Esistono vari programmi e tool Open Source i quali offrono all’utilizzatore la possibilità di
modellare un sistema utilizzando il paradigma SysML. Nel nostro caso è stato utilizzato
Eclipse Papyrus in quanto facile da usare sia come tempi di apprendimento sia per la
velocità di realizzazione di un semplice progetto. Eclipse è un ambiente di sviluppo
integrato multi-linguaggio e multipiattaforma. Ideato da un consorzio di grandi società
50
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
quali Ericsson, HP, IBM, Intel, MontaVista Software, QNX, SAP28 e Serena Software.
Eclipse può essere utilizzato per la produzione di software di vario genere, si passa
infatti da un completo IDE per il linguaggio Java (JDT, "Java Development Tools") a un
ambiente di sviluppo per il linguaggio C++ (CDT, "C/C++ Development Tools") e a plugin che permettono di gestire XML, Javascript, PHP29 e persino di progettare graficamente
una GUI30 per un'applicazione JAVA (Eclipse VE, "Visual Editor"), rendendo di fatto
Eclipse un ambiente RAD. Il programma è scritto in linguaggio Java, ma anziché basare la
sua GUI su Swing, il toolkit grafico di Sun Microsystems, si appoggia a SWT31, librerie di
nuova concezione che conferiscono ad Eclipse un'elevata reattività. La piattaforma di
sviluppo è incentrata sull'uso di plug-in, delle componenti software ideate per uno
specifico scopo, per esempio la generazione di diagrammi UML, ed in effetti tutta la
piattaforma è un insieme di plug-in32, versione base compresa, e chiunque può sviluppare
e modificare i vari plug-in. Tra i vari plug-in vi è anche Papyrus. Papyrus mira a fornire un
ambiente integrato e user-consumable per la modifica di ogni tipo di modello EMF e in
particolare per sostenere UML e linguaggi di modellazione correlati come SysML.
Papyrus fornisce editor di diagrammi per linguaggi di modellazione basati su EMF tra i
quali UML 2 e SysML e la possibilità di integrare questi editor (GMF-based o non) con
altri strumenti MBD e MDSD. Papyrus offre anche un supporto molto avanzato di profili
UML che consente agli utenti di definire editor per DSL33 basate sullo standard UML 2.
La caratteristica principale di Papyrus per quanto riguarda quest'ultimo punto è un
insieme di potenti meccanismi di personalizzazione che possono essere sfruttate per creare
prospettive Papyrus definiti dall'utente e dargli lo stesso aspetto grafico di un editor di
DSL puro[5]. La figura 18 mostra l’aspetto dell’ambiente Eclipse-Papyrus.
28
Società leader mondiali nel campo dell’informatica
Linguaggi di programmazione utilizzati soprattutto per lo sviluppo web
30
L'interfaccia grafica utente, nota anche come GUI (dall'inglese Graphical User Interface), comunemente abbreviata in
interfaccia grafica, è un tipo di interfaccia utente che consente all'utente di interagire con la macchina controllando
oggetti grafici convenzionali.
31
Un toolkit grafico è un insieme di strumenti software concepiti per facilitare e uniformare lo sviluppo di interfacce
grafiche (GUI)
32
E’ un programma non autonomo che interagisce con un altro programma per ampliarne le funzioni
33
Il Domain-specific language (in sigla DSL) o Linguaggio specifico di Dominio nello sviluppo software e
nell'ingegneria di dominio è un linguaggio di programmazione o un linguaggio di specifica dedicato a particolari
problemi di un dominio, a una particolare tecnica di rappresentazione e/o a una particolare soluzione tecnica
29
51
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 18: Layout Eclipse-Papyrus
Papyrus fornisce inoltre un supporto completo al SysML per consentire model-based
system engineering. Esso include un'implementazione del profilo statico SysML e gli
editor grafici specifici richiesti per SysML. Consente quindi di poter creare in maniera
immediata diagrammi quali: Block Definition Diagram, Internal Block Diagram,
Parametric Diagram e Requirements Diagram (definiti nel dettaglio nel capitolo 4).
3.2 IBM Rational Rhapsody Developer
Oltre ai programmi Open Source esistono quelli non Open Source, ovvero a pagamento
con licenza d’utilizzo. Nel nostro caso è stato utilizzato IBM Rational Rhapsody
Developer.
IBM Rational Rhapsody offre sviluppo e progettazione collaborativi per
Systems Engineers e sviluppatori software, creando software e sistemi integrati o in tempo
reale. Questa soluzione consente a sviluppatori e progettisti di analizzare e verificare i
requisiti, di progettare rapidamente i prototipi e di fornire applicazioni più coerenti
52
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
utilizzando Systems Modeling Language (SysML) e Unified Modeling Language (UML).
La famiglia di prodotti Rational Rhapsody include una serie di versioni incentrate sulle
esigenze dei progettisti dei sistemi e degli sviluppatori di software integrati[6]
Rational Rhapsody Developer fornisce[7]:
Generazione completa delle applicazioni integrate — genera il codice
comportamentale per i grafici di stato e le risorse di sviluppo per automatizzare la
creazione delle applicazioni.
Sviluppo grafico, test basati sui modelli e simulazione — consente di utilizzare
l'esecuzione per convalidare in anticipo i progetti.
Tracciabilità dei requisiti — memorizza i requisiti negli elementi di progettazione
e nei test case per fornire le informazioni di tracciabilità all'interno del modello.
Collaborazione dei team — consente ai team di collaborare per gestire la
complessità di sviluppo di progetti coerenti in ambienti diversi (operazione non prevista
con Eclipse-Papyrus).
Supporto dei ciclo di vita e di software aggiuntivi — si integra con gli altri
prodotti IBM Rational per lo sviluppo completo del ciclo di vita dei prodotti. Inoltre, è
possibile estendere le funzionalità di Rational Rhapsody Developer con software
aggiuntivi opzionali.
Come detto IBM Rational Rhapsody Developer per C ha al suo interno il profilo
FunctionalC. Rhapsody in C offre un ampio set di funzionalità per gli sviluppatori in
grado di impiegare tecnologie abilitanti fondamentali in un ambiente naturale, facile da
usare. Rhapsody è un ambiente unico ed efficiente per i sistemi, il software e la testabilità.
Esso consente di eseguire queste operazioni[8]:
Analisi: durante la quale è possibile definire, analizzare e validare i requisiti di
sistema.
Progettazione: durante il quale è possibile specificare e progettare l'architettura.
Implementazione di: durante il quale è possibile generare automaticamente il codice,
53
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
e poi costruire e gestire all'interno del prodotto Rhapsody.
Esecuzione dei modelli: durante le quali è possibile animare il modello sull'host34
locale o un obiettivo remoto per eseguire il debug a livello di progettazione all'interno di
viste animate.
Rhapsody è provvisto di un tool per la generazione automatica di una Test Architecture in
grado di testare il progetto in maniera automatica che, agendo sui diagrammi che ne
descrivono il comportamento dinamico del sistema definiti dall’utente, genera i casi di test
per effettuare valutazioni sulla coverage .
Nel nostro caso oltre al profilo standard OO (Object Oriented) è stato utilizzato il profilo
FunctionalC specifico per lo sviluppo di sistemi con codice imperativo come il C. Nello
specifico il profilo FunctionalC di Rhapsody in C per la codifica C quindi, permette
all'utente di modellare funzionalmente un'applicazione utilizzando costrutti familiari come
i file, le funzioni, chiamate grafici e diagrammi di flusso. Il profilo FunctionalC per lo
sviluppatore C fornendo i seguenti schemi:
Build Diagram per mostrare come il software deve essere costruito.
Call Graph Diagram grafico per mostrare la relazione delle chiamate di funzione
così come il rapporto dei dati.
File Diagram per mostrare come i file interagiscono uno con l'altro (in genere come
viene creata la struttura #include).
Flow Chart per mostrare una funzione o un'operazione di classe e per la generazione
di codice.
Message Diagram da visualizzare come la funzionalità dei file può interagire tramite
messaggistica (chiamate di funzione sincrona o di comunicazione asincrona).
Inoltre è anche possibile creare diagrammi di attività, diagrammi di stato, e usare i use
case diagram (gli stessi di UML) quando si utilizza il profilo FunctionalC[9]. Nella figura
34
Terminale collegato ad una rete o più in particolare ad Internet.
54
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
seguente (Figura 19) vediamo un tipico layout di Rhapsody Developer per C:
Figura 19: Layout IBM Rational Rhapsody Developer per C
All’interno del nostro progetto è possibile definire file, funzioni e variabili. Le funzioni
poi si dividono in 3 tipi in Rhapsody: Reception, Operation e Trigger Operation. Le
Operation sono azioni che svolgono delle operazioni e che vengono invocate tramite
chiamata a funzione all’interno del codice; le Trigger Operation sono funzioni che invece
vengono attivate da eventi e svolgono al loro interno delle operazioni; Le Reception sono
funzioni che servono a catturare gli eventi per poi registrarli e renderli disponibili ad altri.
Di notevole importanza è la possibilità comparare i diagrammi forniti dal profilo
FuctionalC con quelli UML. Infatti noteremo come tre dei precedenti diagrammi siano
simili a quelli definiti dai profili UML. Il File Diagramm non è altro che il Class
Diagramm UML per C, dove le classi diventano i file, i metodi diventano le funzioni, le
variabili restano tali e le associazioni tra le classi diventano le relazioni di inclusione tra i
file. Questa grossa similitudine è resa necessaria in quanto in un profilo FunctionalC
sarebbe impossibile creare un Class Diagramm in quanto in C si ragiona per file e non per
classi. In questo modo otteniamo un diagramma che possiamo facilmente ricondurre in
55
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
maniera concettuale ad un Class Diagram. In Figura 20 sono mostrati un Class Diagram
sulla sinistra e un File Diagram sulla destra:
Figura 20: Comparazione tra Class Diagram e File Diagram
Stesso discorso vale per il Message Diagram che altro non è che il Sequence Diagram. In
questo caso anche i nomi e le convenzioni sono del tutto uguali tra i due. Nella Figura 21
sono mostrati un Sequence Diagram sulla sinistra e un Message Diagram sulla destra:
Figura 21: Comparazione tra Sequence Diagram e Message Diagram
Il Flow-Chart serve per la descrizione comportamentale delle azioni che devono essere
eseguite da una funzione all’atto della sua invocazione. Questo diagramma produce in
56
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
output il codice della funzione. Questo diagramma è molto simile all’Activity Diagram
UML ed infatti da questo ne deriva la struttura. Nella Figura 22 vediamo un esempio di
comparazione tra un Activity Diagram a sinistra e un Flow Chart Diagram a destra:
Figura 22: Comparazione tra Activity Diagram e Flow Chart Diagram
Gli altri diagrammi servono per meglio definire il profilo FunctionalC in quanto il Build
Diagram serve per definire come le varie componenti di codice devono essere assemblate
per costruire l’eseguibile e che tipo di compilatore si deve usare mentre il Call Graph
Diagram serve per mostrare la relazione delle chiamate di funzione così come il rapporto
dei dati.
57
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Capitolo 4: Caso di studio
4.1 Il sistema TOD
Il nostro sistema in esame si basa su un caso di studio fornito dall’azienda AnsaldoBreda.
L’architettura di massima presente nel documento SRS[10] è presentata in Figura 23, dove
notiamo la presenza dei componenti principali del nostro sistema ovvero: Il Tod
Management Agent, la Human Interface Machine e la Diagnostic Base Unit.
Figura 23: Architettura del TOD
Il sistema in esame si sviluppa sulla piattaforma MDS-ETH (monitor and diagnostic
system – ethernet). Essa è responsabile del monitoraggio e della diagnostica di tutti i
dispositivi meccanici ed elettronici a bordo treno. Tutti i componenti HW e SW
interagiscono tra loro grazie ad una rete ethernet su base TCP/IP.
58
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
TOD – Train Operator Display è l’interfaccia uomo macchina del sistema e consente ai
vari utenti di interagire con il sistema diagnostico. E’ costituito da un PC-panel dotato di
touch screen ed interfaccia Ethernet. Nel TOD è integrato un sistema di controllo della
luminosità dello schermo che consente di adattarla automaticamente in funzione della luce
ambientale o in modalità manuale. Nel TOD è integrato un sistema sonoro che consente di
emettere beep. I TOD sono posizionati dove è necessario all’interno del veicolo. Le
posizioni tipiche sono sui banchi di manovra delle cabine di guida. Altri TOD possono
essere utilizzati nella postazione del capotreno o all’interno di armadi per l’uso da parte
del personale manutentore. I TOD possono essere di formato diverso, tipicamente da una
dimensione minima di 10” fino ad una dimensione di 19”. I TOD vengono riconosciuti ed
identificati dal server centrale di diagnostica unicamente in base all’indirizzo IP che viene
loro assegnato.
DBU – Diagnostic Base Unit costituisce l’unità server del sistema. E’ costituita da un PC
per uso ferroviario in formato rack 19” che può essere collocato in un armadio del veicolo.
La DBU è dotata di due connessioni Ethernet e di una connessione al bus di veicolo MVB.
La DBU raccoglie le informazioni diagnostiche da tutte le centraline dei sottosistemi
mediante i bus MVB ed Ethernet. E’ un browser web che presenta l’interfaccia all’utente.
Carica pagine HTML dal server ed esegue il codice javascript in esse contenuto.
Attraverso il codice javascript il browser interroga continuamente il server DBU per
l’aggiornamento dei dati sulla pagina.
TODMA – TOD Management Agent è un Applicazione Web server per l’accesso alle
funzioni specifiche del TOD. Consente di visualizzare una o più pagine HTML per le
seguenti funzioni:
1) Calibrazione touch screen.
2) Impostazione sistema di controllo automatico/manuale della luminosità.
59
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
TODMA implementa comandi che consentono alla DBU di eseguire operazioni sul TOD
come:
1) Diagnostica sullo stato del servizio
2) Forzamento accensione/spegnimento illuminazione del monitor
3) Esecuzione beep di sistema
4) Reindirizzamento dei contenuti visualizzati dall’HMI
Il TODMA comunica direttamente con la DBU, ossia riceve delle richieste http
direttamente dalla DBU. La comunicazione fra DBU e HMI, invece, avviene in maniera
indiretta ossia il TODMA reindirizza l’HMI verso la DBU (vedi Figura 23).
HMI – Human Machine Interface è l’interfaccia uomo macchina che presenta i dati di
diagnostica all’operatore. Richiede pagine HTML al server DBU ed esegue il codice
javascript in esse contenuto. Attraverso il codice javascript il browser interroga
continuamente il server DBU per l’aggiornamento dei dati sulla pagina.
TST – Touch Screen Tuning è una applicazione che consente di tarare il touch screen. Può
essere attivata da linea di comando all’interno del terminale del TOD o mediante una
chiamata CGI effettuata dal HMI sul TODMA. Quando viene attivata si apre a schermo
intero sovrapponendosi allo schermo della HMI che rimane in background. La taratura
avviene chiedendo all’utente di premere in vari punti dello schermo. I parametri della
taratura sono salvati sul file system del TOD. Alla fine dell’operazione l’applicazione
viene chiusa e ritorna visibile lo schermo della HMI.
TD – TOD Driver sono delle funzioni di libreria per permettono di utilizzare i driver del
TOD. Il TODMA chiama queste funzioni quando riceve un relativo comando dal server
DBU.
60
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
4.2 Requisiti
In Tabella 1 sono elencati i requisiti di alto livello riportati nel documento dei requisiti
ufficiale del modulo da noi sotto esame, definiti all’interno dell’SRS35 [10].
Tabella 1: Requisiti software del sistema TODMA
ID Requisito
Testo del requisito
HLR_GEN_001
Il modulo TODMA deve essere compilato e collegato
staticamente al modulo SW TOD control server che è
in esecuzione sul TOD.
Il TOD control server deve interagire con il modulo
TODD della DBU, i Driver del TOD e l’HMI
attraverso esclusivamente il modulo TODMA
Il TODMA riceve richieste dal modulo TODD del
server DBU e dal modulo HMI tramite URI
All’avvio, Il TODMA non deve conoscere l’indirizzo
del server DBU
Il TODMA deve ricavare l’indirizzo del server DBU da
un’apposita richiesta
Il TODMA deve tenere una sessione con una sola DBU
fin tanto che questa è attiva.
Il TODMA considera la DBU attiva se l’intervallo di
tempo che intercorre fra due richieste consecutive
ricevute dalla DBU è minore o uguale al tempo
lifetime. Superato il tempo lifetime la sessione si
considera terminata.
Il tempo lifetime è fornito dalla DBU quando contatta il
TODMA tramite un’apposita richiesta ed è espresso in
secondi
Il TODMA può avviare una nuova sessione con una
nuova DBU se la sessione precedente è stata terminata
Ad una richiesta effettuata dal modulo TODD della
DBU, il TODMA deve far emettere un beep al TOD
Ad una richiesta effettuata dal modulo TODD della
DBU, il TODMA deve far accendere e avviare l’ HMI
se non è già attiva oppure deve spegnere
l’illuminazione del monitor e terminare l’HMI
Ad una richiesta effettuata dal modulo TODD della
DBU, il TODMA deve fornire una diagnostica sullo
stato del servizio
Ad una richiesta effettuata dal modulo TODD della
DBU, il TODMA deve forzare l’HMI ad una
determinata URI
HLR_GEN_002
HLR_GEN_003
HLR_SRV_001
HLR_SRV_002
HLR_SRV_003
HLR_SRV_004
HLR_SRV_005
HLR_SRV_006
HLR_SRV_007
HLR_SRV_008
HLR_SRV_009
HLR_SRV_0010
35
Gruppo di
appartenenza
Requisiti Generali
Requisiti Generali
Requisiti Generali
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Software requirements specification (SRS) è una descrizione completa del comportamento di un sistema da
sviluppare.
61
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
HLR_SRV_0011
HLR_SRV_0012
HLR_SRV_0013
HLR_SRV_0014
HLR_SRV_0015
HLR_SRV_0016
HLR_HMI_001
HLR_HMI_002
HLR_HMI_003
HLR_HMI_004
HLR_EST_001
HLR_EST_002
HLR_EST_003
HLR_EST_004
HLR_DRV_001
HLR_DRV_002
Quando richiesto dall’utente tramite interazione
manuale con l’HMI, il TODMA deve avviare un
processo di taratura del touch screen (TST architettura)
Il TODMA può terminare e ripristinare l’esecuzione
dell’HMI in qualsiasi istante
Il TODMA deve indicare una pagina statica locale
all’HMI (vedi HLR_EST_003)
Nel caso in cui non vi sia una connessione attiva tra la
DBU e il TODMA, Il TODMA deve indicare al
modulo HMI una pagina statica locale, contenente il
logo AB, da visualizzare
IL TODMA deve far visualizzare al modulo HMI
l’ultima URI nel caso in cui venga ripristinata la
connessione
IL TODMA deve segnalare la presenza di un operatore
alla DBU nel caso in cui lo schermo fosse spento
L’HMI è in esecuzione sul TOD e deve visualizzare
pagine HTML provenienti dal modulo TODD della
DBU
L’HMI visualizza pagine il cui l’indirizzo è fornito dal
modulo TODMA del TOD (comunicazione indiretta)
L’HMI è dotato di un’estensione browser che gestisce
la interazione tra l’HMI e il TODMA
L’HMI deve in qualsiasi momento visualizzare il logo
AB nel caso in cui venga richiesto dal modulo
TODMA
L’estensione è un ADD-ON presente sul browser il
quale interagisce con il modulo TODMA richiedendo
ciclicamente la URI alla quale collegarsi
All’avvio del browser verrà indicata dal TODMA una
pagina statica da caricare, presente in locale
Se all’avvio il TODMA non fornisce alcuna URI verrà
visualizzata la pagina statica presente in locale
L’estensione deve contattare ciclicamente il TODMA
per farsi fornire la URI alla quale collegarsi
L'emissione del beep di cui al requisito
HLR_SERV_001 deve essere effettuata tramite
funzioni di libreria specificate dal fornitore del TOD
L’accensione o lo spegnimento del monitor di cui al
requisito HLR_SERV_002 deve essere effettuata
tramite funzioni di libreria specificate dal fornitore del
TOD
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Servizi forniti dal
modulo TODMA
Funzionalità
dell’HMI
Funzionalità
dell’HMI
Funzionalità
dell’HMI
Funzionalità
dell’HMI
Estensione HMI
Estensione HMI
Estensione HMI
Estensione HMI
Utilizzo dei
DRIVER
Utilizzo dei
DRIVER
4.3 Scelta dei linguaggi e degli strumenti
Per lo sviluppo del caso di studio si è scelto di procedere con una modellazione Model62
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Driven con SysML utilizzando Eclipse-Papyrus e IBM Rational Rhapsody Developer.
Questa scelta è dovuta principalmente a due motivi: Il primo concettuale, in quanto
dovendo realizzare un componente software fortemente legato ai componenti hardware
presenti nel sistema questo ha reso necessario una trattazione del problema di tipo ModelDriven con SysML; in secondo luogo perché ad oggi metodologie Model-Driven Based
sono ormai mature per essere utilizzate in ambito industriale. Tutto quanto visto in
precedenza quindi risulta essere adatto al nostro caso di studio.
Per quanto riguarda i programmi e tool utilizzati la scelta è stata fatta in quanto
Eclipse-Papyrus permette una migliore e più immediata realizzazione sugli aspetti di
modellazione SysML di un componente mentre IBM Rational Rhapsody Developer per C
è stato usato in quanto integra in se la generazione del codice C, requisito fondamentale
dato che nel nostro caso specifico dobbiamo arrivare alla generazione di un software
scritto in tale linguaggio. La scelta di dividere la parte di progettazione e modellazione con
un programma e quella di generazione del codice da un’altra è stata fatta in quanto si
voleva valutare la possibilità di importare/esportare modelli realizzati con Papyrus in
Rhapsody e viceversa. Ad oggi questa cosa non è ancora possibile in quanto i tool a
disposizione di Rhapsody per l’importazione di file di tipo XMI o UML2 non sono
funzionanti. Questo ovviamente non costituisce un problema in quanto è possibile
realizzare tutto con Rhapsody (modellazione SysML e generazione del codice) oppure
potremmo trovarci nel caso in cui si deve realizzare solo la modellazione di un sistema e
non per forza anche la generazione del codice.
4.4 Analisi: Modellazione SysML
4.4.1
Requirements Diagram
Partendo dai requisiti del sistema[10] come prima cosa si sono analizzati i requisiti e
le relazioni tra di essi. Il Requirements Diagram (RD) è un ottimo strumento che permette
di capire come i requisiti sono organizzati gerarchicamente e relazionati tra loro e come
sono allocati nei rispettivi blocchi definiti nel nostro sistema. In riferimento alla tabella 1
63
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
del Capitolo 4 il RD relativo ai gruppi di requisiti HLR (requisiti di alto livello) mostrato
in figura 24:
Figura 24: RD dei gruppi di requisiti HLR
Notiamo come i requisiti di alto livello siano stati tutti divisi in gruppi di requisiti
riguardanti cinque aree tematiche principali, ovvero quelli sulla parte generale, quelli sui
servizi offerti dal modulo TODMA, quelli riguardanti l’HMI, quelli riguardanti
l’Estensione (ADD-ON) ed infine quelli riguardanti i driver del TOD. Nel diagramma in
figura 24 vediamo come questi gruppi siano in relazione di decomposizione con quello
che può essere definito il macro gruppo dei requisiti di alto livello (relazione di
decomposizione definita nel paragrafo 2.3). Vediamo ora come sono in relazione tra di
essi i requisiti di ogni gruppo, partendo dai requisiti generali. In figura 25 vediamo il
diagramma relativo ai requisiti generali:
64
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 25: RD dei requisiti del gruppo GEN
Vediamo subito che dal
requisito HLR_GEN_001 deriva il requisito
HLR_GEN_002 dal quale deriva il requisito HLR_GEN_003. La relazione di derivazione
è definita anche’essa nel paragrafo 4.3 e ci sta ad indicare che un requisito è derivato da un
altro in modo tale definire con maggior dettaglio il requisito da cui da cui è derivato.
Proseguendo abbiamo in Figura 26 il diagramma dei requisiti dei servizi offerti dal
TODMA:
Figura 26: RD dei requisiti del gruppo SVR
65
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Come nel caso precedente vediamo che tutti i requisiti compongono il gruppo HLR_SRV
e sono tutti derivati dal requisito HLR_GEN_003. Questo sta ad indicarci che all’interno
del gruppo di requisiti HLR_SRV tutti i requisiti sono tutti di “pari livello” ovvero non ci
sono relazioni di derivazione o di decomposizione tra di essi. Vi è poi il diagramma dei
requisiti dell’HMI mostrato in Figura 27:
Figura 27: RD dei requisiti del gruppo HMI
A differenza del precedente diagramma, vediamo che questo è molto strutturato, in
quanto vi sono delle relazioni di derivazione con altri requisiti di gruppi diversi. Tutti i
requisiti HLR_HMI compongono il gruppo dei requisiti HMI e il requisito
HLR_HMI_001 deriva dal requisito HLR_SRV_005 (freccia tratteggiata), il requisito
HLR_HMI_002 e il requisito HLR_HMI_003 derivano dal requisito HLR_GEN_003 ed
infine il requisito HLR_HMI_004 deriva dal requisito HLR_SRV_014. Abbiamo poi il
diagramma dei requisiti dell’Estensione mostrato in Figura 28:
66
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 28: RD dei requisiti del gruppo EST
Anche questo come il precedente è molto strutturato ed infatti tutti i requisiti
HLR_EST
compongono il
HLR_EST_001,
gruppo
HLR_EST_002
e
dei
requisiti
HLR_EST_004
dell’estensione e i
deriva
no
dal
requisiti
requisito
HLR_HMI_003, mentre il requisito HLR_EST_003 deriva dal requisito HLR_SRV_013.
In ultimo vi è il diagramma dei requisiti dei driver del TOD mostrato in Figura 29:
67
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 29: RD dei requisiti del gruppo DRV
Anche in questo caso abbiamo un diagramma strutturato ed infatti tutti i requisiti
HLR_DRV compongono il gruppo dei requisiti dei driver del TOD e il requisito
HLR_DRV_001
è
derivato
dal
requisito
HLR_SRV_007
HLR_DRV_002 è derivato dal requisito HLR_SRV_008.
mentre
il
requisito
Come visto quindi ogni
requisito è in relazioni con gli altri e con essi compongono quelle che sono le specifiche di
alto livello del nostro sistema. Il Requirements Diagram è in grado oltre di farci modellare
i requisiti come visto in precedenza anche di farci modellare questi in relazione ad
componenti del nostro sistema, realizzati in precedenza.
4.4.2
Definition Block Diagram e Internal Block Diagram
A questo punto si definisce l’architettura di alto livello tramite i Block Definition Diagram
dove vengono definiti i blocchi del sistema, composto dal TOD e dai dispositivi con cui
interagisce (DBU – Diagnostic Based Unit, sensori, attuatori). Nella Figura 30 vediamo
68
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
come si modellano questi componenti usando gli stereotipi a nostra disposizione:
Figura 30: BDD piattaforma MDSETH
Come vediamo i due blocchi sono contenuti all’interno di un package che funge da
namespace del nostro progetto. All’interno dei blocchi poi notiamo le varie properties
nelle quali sono presenti le definizioni delle flow port in riferimento al flusso di
informazione che deve viaggiare tra un componente ed un altro. Infatti notiamo che dalla
DBU vi sono i tre flussi in uscite che corrisponderanno rispettivamente alle richieste di
emissione di un beep, di accensione o spegnimento della lampada del TOD e del
reindirizzamento della pagina attualmente visualizzata dal TOD. Sul TOD invece queste
risulteranno delle port in ingresso. Vi è poi il flusso che indica la richiesta di diagnostica, e
risulta essere in ingresso/uscita in quanto ad una richiesta vi è sempre una risposta e quindi
in entrambi i casi il flusso è in entrambe le direzioni. Vi è poi da notare la relazione di
associazione che lega i due blocchi la quale ci indica che ad un DBU possono essere
collegati uno o più TOD e questo collegamento avviene su bus (o rete) Ethernet. Andando
poi ad analizzare nel dettaglio il blocco del TOD vediamo nella Figura 31 un
ingrandimento del blocco e la rappresentazione su di esso dei porti:
69
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 31: TOD Block
Da questa vista notiamo una delle proprietà di SysML: si riesce a cogliere, grazie alle
porte e al tipo di dato che le attraversa, il senso di flusso di esecuzione e del tipo di
informazione che passa attraverso i vari moduli. Procedendo nell’analisi andiamo a vedere
come è strutturato il blocco TOD. Esso è composto da una serie di elementi i quali
cooperano per svolgere le azioni che il TOD deve compiere. Nella Figura 32 vediamo la
composizione del TOD:
Figura 32: Componenti del TOD
70
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Notiamo che ogni componente è associato al TOD tramite una relazione di composizione
uno a uno che sta ad indicare che il TOD è composto da un elemento denominato
PcSpeaker (componente hardware) un elemento denominato LampScreen(componente
Hardware) un elemento denominato TODMA (componente Software) un elemento
denominato
HMI
(componente
Software)
e
un
elemento
denominato
TouchScreenController (componente Software). Come possiamo notare i blocchi di cui è
composto il TOD possono essere sia hardware sia software. La descrizione tramite flow
port dei suoi componenti è descritta nell’IBD del TOD mostrato nella seguente
immagine(Figura 33):
Figura 33: IBD TOD
In questa vista vediamo come interagiscono tra di loro i vari componenti del TOD. In
questo modo è possibile stabilire in che modo e quali azioni vengono generate e quali sono
le parti in gioco che cooperano per il raggiungimento dell’obiettivo. Alle quattro azioni
viste in precedenza, provenienti dall’esterno si notano ora altre tre azioni interne
provenienti dall’HMI che sono: La regolazione della luminosità, la richiesta del
programma di Touch Screen Calibrator e la richiesta con risposta del reindirizzamento,
tutte, comprese quelle esterne, che sono servite dal modulo TODMA il quale costituisce il
core del nostro sistema. Il blocco TODMA è quindi responsabile dell’elaborazione delle
71
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
richieste e quindi delle azioni da compiere ed infine delle risposte da fornire qual’ora siano
richieste. Vediamo che le richieste di regolazione della luminosità e di accensione o
spegnimento della lampada del TOD vanno a confluire nel modulo hardware LampScreen
che altro non è che la scheda video del TOD; la richiesta di emissione del beep va a
confluire nel modulo hardware PcSpeaker che altro non è che lo speaker presente sulla
scheda madre ed infine la richiesta di touch screen calibrator va a confluire nel modulo
hardware Touch Screen Controller che altro non è che il monitor del TOD. Oltre a queste
richieste il TODMA soddisfa anche le richieste di redirect da parte della DBU la quale non
fa altro che indicare una nuova pagina alla quale l’HMI dovrà visualizzare, la richiesta di
redirect da parte dell’HMI che altro non è che la richiesta al TODMA, se presente, della
pagina fornita in precedenza dalla DBU con risposta affermativa se presente negativa in
caso contrario ed infine la richiesta con risposta della diagnostica da parte della DBU al
TOD. In questo modo abbiamo definito il comportamento degli elementi interni del TOD.
Notiamo da subito che i flussi di informazione provenienti dall’esterno e dall’HMI verso
il TODMA sono tutti di tipo string, mentre quelli uscenti dal TODMA ed entranti nei
dispositivi hardware sono di tipo bitstring. Questo perché nel primo caso abbiamo segnali
di tipo stringhe mentre nel secondo abbiamo segnali di tipo bit che si traducono in
comandi hardware. Andiamo ora a vedere la composizione del blocco TODMA
rappresentato in Figura 34:
Figura 34: BDD TODMA
Vediamo come le porte di ingresso e di uscita presenti all’interno del diagramma
72
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
precedente vengono riportate ugualmente ai bordi esterni del blocco TODMA. Andiamo
ora a vedere la composizione del blocco TODMA rappresentato in Figura 35:
Figura 35: Composizione del TODMA
Come si può vedere dalla figura, il bloco TODMA è composto da tre elementi che sono:
DriveTod, TodManagementAgent e il TodControlServer. Il blocco DriveTod altro non è
che la libreria con cui i componenti hardware vengono controllati, il blocco
TodControlServer è un server il quale riceve richieste provenienti dall’esterno del modulo
TODMA e la smista alla relativa funzione del modulo TodManagementAgent che ne
realizza la logica di funzionamento richiesta. Questi blocchi costituiscono insieme il
nostro sistema software e realizzano tutte le operazioni richieste al bloccoTODMA, ed in
particolare il modulo TodManagementAgent risulta essere il core vero e proprio del nostro
sistema. Come vediamo in Figura 36 l’associazione che unisce il blocco TODMA agli altri
è di composizione con cardinalità 1 a 1 e quindi si capisce subito che ogni blocco di cui è
composto è istanziato una sola volta. Andiamo ora a visualizzare l’IBD del TODMA e
73
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
quindi come i flussi di informazione viaggiano tra i moduli per realizzare le operazioni
mostrato in figura 30:
Figura 36: TODMA IBD
Come si può vedere da questo diagramma tutte le richieste che giungono dall’esterno vengono
gestite dal modulo TodControlServer (TCS) il quale a seconda della specifica richiesta invoca
una corrispettiva funzione del modulo TodManagementAgent(TMA) e se necessario questo
invoca una corrispettiva funzione del modulo DriverTod(DT). Vediamo ora passo dopo passo
ogni singola azione richiesta e il suo flusso all’interno del nostro modulo TODMA:
1. Alla richiesta di emissione di un beep (reqBeepAction) proveniente dall’esterno il modulo
TCS invoca la corrispettiva funzione di elaborazione del modulo TMA (reqElaborationBeep) il
quale fatte le dovute operazioni invocherà a sua volta la corrispettiva funzione del modulo DT
(reqCommandBeep) il quale eseguirà il comando che andrà esternamente al modulo TODMA
verso il blocco PcSpeaker che provvederà all’emissione del beep ad una data frequenza e di una
determinata durata.
2. Alla richiesta di accensione o spegnimento del monitor del TOD (reqLampOnOffAction)
proveniente dall’esterno il modulo TCS invoca la corrispettiva funzione di elaborazione del
modulo TMA (reqElaborationLampOnOff) il quale fatte le dovute operazioni invocherà a sua
volta la corrispettiva funzione del modulo DT (reqCommandLampOnOff) il quale poi fatte le
dovute operazione eseguirà il comando che andrà esternamente al modulo TODMA verso il
74
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
blocco LampScreen per lo spegnimento o l’accensione del monitor del TOD.
3. Alla
richiesta
di
regolazione
della
luminosità
del
monitor
del
TOD
(reqBrightnessRegulationAction) proveniente dall’esterno il modulo TCS invoca la
corrispettiva funzione di elaborazione del modulo TMA (reqElaborationBrightnessRegulation)
il quale fatte le dovute operazioni invocherà a sua volta la corrispettiva funzione del modulo
DT (reqCommandBrightnessRegulation) il quale poi fatte le dovute operazione eseguirà il
comando che andrà esternamente al modulo TODMA verso il blocco LampScreen per la
regolazione della luminosità del monitor del TOD.
4. Alla
richiesta
di
regolazione
del
Touch
Screen
del
monitor
(reqTouchScreenCalibratorAction) proveniente dall’esterno il modulo TCS invoca la
corrispettiva
funzione
di
elaborazione
del
modulo
TMA
(reqElaborationTouchScreenCalibrator) il quale fatte le dovute operazioni eseguirà il comando
che andrà esternamente al modulo TODMA verso il blocco TouchScreenController per la
regolazione del Touch Screen del monitor.
5. Alla richiesta di diagnostica del stato del TOD (reqDiagnosticAction) proveniente
dall’esterno il modulo TCS invoca la corrispettiva funzione di elaborazione del modulo TMA
(reqElaborationDiagnostic) il quale fatte le dovute operazioni restituirà al chiamante le
informazioni di diagnostica corrente sullo stato del TOD.
6. Alla richiesta di redirect dell’HMI da parte della DBU (reqSetUriAction) proveniente
dall’esterno il modulo TCS invoca la corrispettiva funzione di elaborazione del modulo TMA
(reqElaborationRedirectSetUri) il quale farà al suo interno le dovute elaborazioni.
7. Alla richiesta di redirect dell’HMI da parte dell’HMI (reqGetUriAction) proveniente
dall’esterno il modulo TCS invoca la corrispettiva funzione di elaborazione del modulo TMA
(reqElaborationRedirectGetUri) il quale fatte le dovute operazioni restituirà al chiamante la
risposta con la pagina alla quale collegarsi, se presente.
Si esamina nel seguito il modulo HMI e quali sono le operazioni che svolge nell’interazione
con il modulo TODMA. La Figura 37 mostra il blocco HMI.
75
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 37: HMI BDD
Le porte di ingresso e di uscita sono le stesse che sono state definite nel IBD del TOD e
che corrispondono ad altrettante porte di ingresso e di uscita nel blocco TODMA. Di
particolare interesse è il diagramma di composizione dell’HMI che ci fa capire meglio la
sua struttura interna a livello di componenti (Figura 38):
Figura 38: Composizione HMI
76
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Dalla Figura 38 vediamo che il blocco HMI è composto da due blocchi: Add-on e
ConfigurationPage. L’Add-On non è altro che un componente software presente
all’interno dell’HMI il quale è responsabile di effettuare la richiesta di redirect al TODMA
e di elaborare la sua risposta mentre il blocco ConfigurationPage è la pagina dalla quale si
può richiedere la calibrazione del Touch Screen e la regolazione della luminosità. Notiamo
nel diagramma che vi è anche la presenza di un altro elemento, ovvero l’operatore, che nel
nostro diagramma è stato modellato come un attore che ha una relazione di tipo uso con il
blocco ConfigurationPage. Come visto anche in precedenza, anche il questo caso sia il
blocco Add-On che il blocco ConfigurationPage sono in relazione di composizione con il
blocco HMI e hanno cardinalità 1. Andiamo a visualizzare ora il IBD del HMI mostrato in
Figura 39:
Figura 39: HMI IBD
Vediamo come avviene all’interno del blocco HMI il flusso di informazione che
dall’interno va verso l’esterno e viceversa. Notiamo che il blocco ConfigurationPage è
responsabile di inoltrare le richieste di Calibrazione del Touch Screen e di regolazione
della Luminosità del monitor del TOD al blocco TODMA mentre il blocco Add-On è
77
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
responsabile dell’inoltro della richiesta di redirect della pagina corrente dell’HMI e di
elaborare la risposta proveniente dal blocco TODMA.
4.4.3
Allocazione dei requisiti
Vediamo ora come dalla modellazione RD si sia passati all’allocazione dei requisiti e alla
loro tracciabilità in relazione ad particolare blocco del nostro sistema che soddisfa li
soddisfa. In Figura 40 vediamo come ogni gruppo di requisiti sia in relazione al particolare
blocco che ne realizza le funzionalità:
Figura 40: Tracciabilità dei requisiti negli artefatti
Vediamo infatti come sostanzialmente i blocchi da noi considerati siano cinque ovvero:
l’ADD-ON, l’HMI, il drivertod, il todmanagementagent e il todcontrolserver. Questi
blocchi definiti in precedenza realizzano tutti i requisiti richiesti e in particolare il blocco
ADD-ON soddisfa il gruppo di requisiti HLR_EST, HLR_GEN e HLR_SRV; il blocco
78
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
HMI soddisfa il gruppo di requisiti HLR_EST, HLR_HMI, HLR_GEN e HLR_SRV; il
blocco drivertod soddisfa il gruppo di requisiti HLR_DRV, HLR_GEN e HLR_SRV; il
blocco todmanagementagent soddisfa il gruppo di requisiti HLR_EST, HLR_HMI,
HLR_GEN e HLR_SRV; il blocco todcontrolserver soddisfa il gruppo di requisiti
HLR_EST, HLR_HMI, HLR_GEN e HLR_SRV. Vista così la cosa appare ancora molto
confusa in quanto non vi è la possibilità di dire un blocco quale requisito soddisfa rispetto
allo specifico requisito e non al gruppo di requisiti. Infatti si è proceduto a realizzare altri
cinque diagrammi, ognuno per ogni modulo in questione i quali mostrassero la reale
relazione tra un blocco e un requisito. Questo passaggio è necessario e fondamentale per il
tracciamento dei requisiti all’interno del nostro sistema in quanto solo in questo modo
possiamo capire quale requisito ogni modulo deve realizzare e come questo poi viene
mappato all’interno del nostro codice che andremo a generare. Nelle Figure 41-42-43-4445 sono mostrati i RD relativi ai blocchi todmanagementagent, todcontrolserver, hmi ,
add-on e drivetod e i requisiti che stanno in relazione con loro tramite l’associazione di
satisfy:
Figura 41: Allocazione dei requisiti rispetto al blocco Tod Management Agent
79
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 42: Allocazione dei requisiti rispetto al blocco Tod Control Server
Figura 43: Allocazione dei requisiti rispetto al blocco HMI
80
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 44: Allocazione dei requisiti rispetto al blocco Add-On
Figura 45: Allocazione dei requisiti rispetto al blocco driver Tod
81
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Oltre a questo tipo di vista sarebbe stato anche possibile creare un altro tipo di diagramma
questa volta sfruttando i diagrammi già elaborati in precedenza, aggiungendo
manualmente i link relativi alle relazioni che ogni requisito ha con i blocchi e con gli altri
requisiti. Come vediamo nelle Figure 46 e 47 relativi ai diagrammi mostrati in precedenza
nelle Figure 24e 25 questa può essere realizzata in maniera più rapida e immediata:
Figura 46: RD dei gruppi di requisiti con vista delle relazioni
Figura 47: RD dei requisiti del gruppo GEN con vista delle relazioni
82
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Ovviamente questo secondo modo di procedere notiamo subito che è molto più indicato se
vogliamo osservare un diagramma composto da pochi requisiti. Già ad esempio un
diagramma composto da 16 requisiti come quello in figura 36 poco si presta a
rappresentazioni di questo tipo.
4.5 Realizzazione con Rhapsody
4.5.1
Sviluppo con profilo FunctionalC
Una volta definito il modello e le parti di cui è composto si passa alla realizzazione con il
programma IBM Rational Rhapsody Developer per C con il functionalC (descritto nel
paragrafo 3.2) e tramite esso abbiamo definito da prima definito il suo file diagram per la
parte statica, successivamente gli state chart per la parte dinamica ed infine abbiamo
generato il codice, poi abbiamo visto i vari flussi di esecuzione tramite i message diagram
ed infine con il tool di animazione abbiamo simulato diversi casi reali di funzionamento.
Come prima cosa andiamo a vedere come è stato modellato il File Diagram all’interno del
nostro ambiente e quali sono le varie relazioni tra i file che lo compongono. In Figura 48 è
mostrato il File Diagram del TODMA:
83
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 48: File Diagram TODMA
Nel diagramma precedente vediamo come ogni blocco interno del nostro TODMA
descritto precedentemente (paragrafo 4.4.2) nel nostro sistema corrisponda ad un file .c il
quale avrà un suo corrispettivo file .h (non mostrato nel File Diagram). Quindi il
TodManagementAgent, il TodControlServer e todLib (precedentemente chiamato
driverTod) sono a tutti gli effetti dei file con al loro interno delle funzioni e delle variabili.
Notiamo come vengono mappati i flussi di informazione (flow port di ogni blocco definiti
nel paragrafo 4.4.2) con le corrispettive funzioni che li realizzano. Notiamo che all’interno
di ogni file sono presenti vari elementi: Le funzioni, le variabili e gli eventi. Le funzione
sono collegate ai porti di ingresso di ogni blocco definito nella Figura 30, infatti abbiamo
che per il TodControlServer si hanno 7 funzioni relative a reqBeepAction,
reqBrightnessRegulationAction, reqDiagnosticAction, reqGetUriAction, reqSetUriAction,
reqTouchScreenCalibratorAction e reqLampOnOffAction e che hanno lo stesso nome,
così
come
per
il
TodManagementAgent
reqAndRespElaborationDiagnostic,
si
hanno
7
funzioni
relative
a
reqAndRespElaborationRedirectGetUri,
84
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
reqElaborationRedirectSetUri,
reqElaborationBeep,
reqElaborationLampOnOff,
reqElaborationTouchScreenCalibrator e che hanno lo stesso nome ed infine per il TodLib
si hanno 3 funzioni relative a reqCommandBeep, reqCommandLampOnOff e
reqCommandBrightnessRegulation che hanno lo stesso nome, in questo modo verranno
mappate le funzioni in relazione alle flow port presenti nei diagrammi DBB e IBD e ad
ogni funzione poi verrà associato il requisito o i requisiti che esso soddisfa presenti nei
diagrammi RD. Tutto questo serve a mostrare che vi è una diretta corrispondenza tra
quanto modellato con SysML e quanto poi realizzato a valle. Vi è la presenza di un altro
tipo di elementi: gli eventi. Questi non sono costrutti specifici del nostro modulo ma ci
servono per descrivere la parte dinamica del nostro modello, ovvero rappresentano tutto
l’insieme dei possibili eventi esterni che possono avvenire e che ai quali sono associate
delle azioni da compiere. Come definito nel paragrafo 3.2 sappiamo che vi sono vari tipi
di funzione: nel nostro caso le funzioni del todControlServer sono di tipo operazionale
mentre quelle del todManagementAgent di tipo trigger operation, questo
perché
sul
todControlServer agiranno degli eventi (esterni) i quali richiameranno le operazioni del
file che a loro volta faranno scattare le trigger operation relative al modulo
todManagementAgent che poi eseguiranno le azioni vere e proprie. Tutto questo server a
rendere l’idea che il modulo todControlServer fa da server del nostro sistema e quindi
riceve ed elabora le richieste che gli arrivano mentre il todManagementAgent fa da
manager del sistema in quanto una volta elaborate le richieste attivano le corrispettive
funzioni che poi realizzeranno l’elaborazione vera e propria e se richiesto una chiamata a
funzione esterna al modulo.
Altra cosa che notiamo sono le relazioni di inclusione tra i file nel quale si evince che il
todManagementAgent include i file H del todLib e del todControlServer in questo modo
riusciamo a descrivere a pieno il nostro sistema.
Una volta modellata la parte statica del nostro sistema andiamo a realizzare la parte
dinamica. Come detto in precedenza le due parti attive all’interno del nostro sistema sono:
85
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
il todControlServer e il todManagementAgent. Per ognuno di questi file quindi si è
provveduto a realizzare uno state chart che ne descrivesse il comportamento dinamico
(Figura 49 e figura 50):
Figura 49: State Chart todControlServer con FunctionalC
Figura 50: State Chart todManagementAgent con FunctionalC
Nei due diagrammi in figura precedente vediamo una certa somiglianza: questo è dovuto
al fatto che entrambi i moduli considerati sono stati progettati con quasi le stesse
caratteristiche a livello di porte (Figura 30) e questo ci viene riportato pari anche nel
86
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
modello dinamico. Quindi il numero degli stati è lo stesso e anche il numero delle
transizioni a meno di un ciclo di loop presente sullo stato work in Figura 50 che
spiegheremo a breve.
Il
nostro
sistema
così
modellato
parte
con
un
evento
evStrart
sul
todManagementAgent che richiamerà la funzione di init del modulo e scatenerà il trigged
operation startTodControlServer sul todControlServer che farà avviare anche questo
modulo. I moduli si troveranno nello stato di wait(todControlServer) e nello stato di
work(todManagementAgent)
fin
quando
uno
degli
eventi
esterni
agirà
sul
todControlServer, oppure l’evento interno evWorkEnd agirà sul todManagementAgent
terminando il modulo e scatenando la trigger operation sul modulotodControlServer la
quale anche essa terminerà il modulo. Gli eventi esterni che possono agire sul nostro
sistema
sono:
evReqBeep,
evReqLampOnOff,
evReqDiagnostic,
evReqSetUri, evReqTouchScreenCalibrator, evReqBrightness. Tutti
evReqGetUri.
questi
eventi
agiscono direttamente sul modulo todControlServer. Vi è poi un timer associato alla
transizione che genera un ciclo di loop sullo stato work del todManagementAgent: questo
è stato inserito per rispecchiare i requisito HLR_SRV_003 presente nella tabella 1 che ci
dice che soltanto un agente esterno (in questo caso la DBU) alla volta può interagire con il
nostro sistema. Questo viene fatto attraverso un parametro identificativo che viene passato
dagli eventi che vengono generati sul sistema che caratterizza in maniera univoca
l’interlocutore.
Una volta memorizzato questo parametro qualsiasi richiesta proveniente dall’esterno
del TOD, se proveniente da un altro interlocutore viene rifiutata altrimenti viene accettata.
Detto ciò il nostro ciclo di loop, tramite un timer, libera la variabile nel caso in cui
dal’ultima richiesta sia passato un tempo limite definito come lifetime (tabella 1).
Per meglio definire il flusso di esecuzione e i vari componenti in gioco, all’interno
del nostro sistema si definiscono i message diagram relativi ad ogni evento esterno
possibile sul sistema. Mostriamo in figura 51 il message diagram dell’evento evReqBeep:
87
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 51: Message Diagram Beep
Notiamo come Rhapsody prima di evolvere tra i vari stati istanzi i tre oggetti (file) da noi
modellati. Notiamo come una volta istanziati gli oggetti gli state chart di entrambi abbiano
una transizione di defalut che li porterà nello stato di ready. Il flusso di esecuzione sparte
con
l’evento
interno
evStart(descritto
in
precedenza)
che
avvia
i
moduli
todControlServer(TCS) e todManagementAgent(TMA). L’evento esterno evReqBeep con
i parametri di tempo frequenza e ip(identificativo dell’interlocutore) vengono mandati al
88
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
TCS il quale elaborerà la richiesta e la invierà alla rispettiva funzione del TMA. A questo
punto il TMA invocherà la funzione di libreria che ci permetterà poi di pilotare l’hardware
per l’emissione del beep con i parametri di tempo e frequenza. Una volta finito il flusso di
esecuzione il TCS ritornerà nello stato di wait mentre il TMA nello stato di work.
In Figura 52 è presente il message diagram dell’evento evReqLampOnOff:
Figura 52: Message Diagram LampOnOff
Il flusso di esecuzione parte con l’evento interno evStart che avvia i moduli TCS e TMA.
89
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
L’evento esterno evReqLampOnOff con i parametri di lamp(monitor acceso spento) e
ip(identificativo dell’interlocutore) vengono mandati al TCS il quale elaborerà la richiesta
e la invierà alla rispettiva funzione del TMA. A questo punto il TMA invocherà la
funzione di libreria che ci permetterà poi di pilotare l’hardware del monitor per accendere
o spegnere lo schermo. Una volta finito il flusso di esecuzione il TCS ritornerà nello stato
di wait mentre il TMA nello stato di work.
In figura 53 è presente il message diagram dell’evento evReqDiagnostic:
Figura 53: Message Diagram Diagnostic
90
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Il flusso di esecuzione parte con l’evento interno evStart che avvia i moduli TCS e TMA.
L’evento esterno evReqDiagnostic con il parametro ip(identificativo dell’interlocutore)
vengono mandati al TCS il quale elaborerà la richiesta e la invierà alla rispettiva funzione
del TMA. A questo punto il TMA elaborerà la richiesta e fornirà in uscita la diagnostica
sullo stato delle variabili locali. Una volta finito il flusso di esecuzione il TCS ritornerà
nello stato di wait mentre il TMA nello stato di work.
In figura 54 è presente il message diagram dell’evento evReqSetUri:
Figura 54: Message Diagram Set Uri
91
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Il flusso di esecuzione parte con l’evento interno evStart che avvia i moduli TCS e TMA.
L’evento esterno evReqSetUri con i parametri uri(valore della uri da impostare) e
ip(identificativo dell’interlocutore) vengono mandati al TCS il quale elaborerà la richiesta
e la invierà alla rispettiva funzione del TMA. A questo punto il TMA elaborerà la richiesta
e imposterà la variabile lasturisetValue al valore contenuto in uri . Una volta finito il
flusso di esecuzione il TCS ritornerà nello stato di wait mentre il TMA nello stato di work.
In figura 55 è presente il message diagram dell’evento evReqGetUri:
Figura 55: Message Diagram Get Uri
92
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Il flusso di esecuzione parte con l’evento interno evStart che avvia i moduli TCS e TMA.
L’evento esterno evReqGetUri viene mandato al TCS il quale elaborerà la richiesta e la
invierà alla rispettiva funzione del TMA. A questo punto il TMA elaborerà la richiesta e
fornirà in uscita il contenuto della variabile lasturisetValue . Una volta finito il flusso di
esecuzione il TCS ritornerà nello stato di wait mentre il TMA nello stato di work.
In figura 56 è presente il message diagram dell’evento evReqTouchScreenCalibrator:
Figura 56: Message Diagram Touch Screen Calibrator
93
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Il flusso di esecuzione parte con l’evento interno evStart che avvia i moduli TCS e TMA.
L’evento esterno evReqTouchScreenCalibrator viene mandato al TCS il quale elaborerà
la richiesta e la invierà alla rispettiva funzione del TMA. A questo punto il TMA elaborerà
la richiesta e avvierà il relativo programma di Touch Screen Tunning . Una volta finito il
flusso di esecuzione il TCS ritornerà nello stato di wait mentre il TMA nello stato di work.
In figura 57 è presente il message diagram dell’evento evReqBrightnessRegulation:
Figura 57: Message Diagram Brightness Regulation
94
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Il flusso di esecuzione parte con l’evento interno evStart che avvia i moduli TCS e TMA.
L’evento esterno evReqBrightnessRegulation con il parametro lum(luminosità) vengono
mandati al TCS il quale elaborerà la richiesta e la invierà alla rispettiva funzione del TMA.
A questo punto il TMA invocherà la funzione di libreria che ci permetterà poi di pilotare
l’hardware del monitor per la regolazione della luminosità della lampada dello schermo.
Una volta finito il flusso di esecuzione il TCS ritornerà nello stato di wait mentre il TMA
nello stato di work.
Nella realtà dei fatti i diagrammi di stato visti singolarmente danno luogo ad un unico
flusso di esecuzione in cui c’è un solo “start” dei modulo (es. TMA).
4.5.2
Generazione del codice e simulazione della parte dinamica
Per la generazione del codice, una volta settato il build file in maniera appropriata, con il
tasto generate and make, si genera il codice e si costruisce l’eseguibile. Valutando il
codice generato, vediamo che sono stati prodotti 20 file nella cartella di cui 5 sono i
sorgenti con i rispettivi file .C .H e .obj, un makefile, un file di configurazione d’ambiente
di Rhapsody, un Incremental Linker File, un Program File Database e l’applicativo finale.
Le righe di codice C generate in totale sono 2304.
Una volta generato il codice è possibile arrivare la simulazione modello mettendo in
esecuzione l’eseguibile creato dal make. Grazie ai tool di animazione di Rhapsody
possiamo effettuare una simulazione guidata generando una serie di eventi e vedendo il
loro output finale a video. Nell’esempio mostrato in figura 58 vediamo come sia stato
possibile simulare la richiesta e la successiva risposta a video di emissione di un beep di
una certa durata ad una certa frequenza:
95
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 58: Esempio di simulazione dello State Chart con richiesta di beep
Notiamo nella figura seguente che sono state stampate a video le scritte contenenti i valori
impostati per la simulazione. Questo è stato possibile in quanto Rhapsody ci da la
possibilità di definire manualmente il codice all’interno delle funzioni. Ovviamente
essendo questo un prototipo, la nostra simulazione si ferma con la realizzazione di una
stampa a video della risposta alla richiesta, ma volendo industrializzare il software
basterebbe riempire le funzioni al loro interno con i costrutti necessari affinché si possano
eseguire realmente le dovute operazioni. Nel nostro caso però, utilizzando la funzione di
sistema Beep(frequenza,tempo), siamo riusciti realmente a simulare l’emissione di un
beep. In altri casi come ad esempio la richiesta di calibrazione del touch screen o lo
spegnimento o accensione dello schermo, questo si è tradotto solamente in una stampa a
video come mostrato in figura 59 e figura 60:
96
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 59: Esempio di simulazione dello State Chart con richiesta di Touch Screen Calibrator
Figura 60: Esempio di simulazione dello State Chart con richiesta di Lamp On/Off
Notiamo infine nelle simulazioni che vengono rispettati sia i criteri per garantire un’unica
connessione tra il TODMA e l’esterno sia che dopo un tempo lifetime questa connessione
in assenza di richieste venga rilasciata. Nella figura 61 e figura 62 vediamo le simulazioni
97
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
di questi stati di errore:
Figura 61: Simulazione di situazione di errore in una richiesta
Figura 62: Simulazione di situazione di scadenza del lifetime di una richiesta
98
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Il profilo FunctionalC di Rhapsody ci permette si una buona descrizione del nostro
progetto generando codice C ma non ci permette di definire in maniera automatica una
Test Architecture per effettuare i test sul nostro componente, a meno che non si voglia
definire l’architettura manualmente, cosa che richiederebbe troppo tempo. Si vede quindi
che oltre alla limitazione dei diagrammi che si possono utilizzare vi è anche quest’altra
limitazione che ne fa del profilo FunctionalC non il miglior metodo per approcciarci a
questo tipo di progettazione. Ovviamente, com’è in questo caso, se dobbiamo produrre
codice C impostato con uno stile di programmazione imperativa, ad oggi utilizzando
Rhapsody è l’unico modo, ma svincolandoci da questo requisito esistono altri modi per
poter realizzare questo applicativo.
4.5.3
Sviluppo con modello a Oggetti
Un’alternativa all’approccio visto fin’ora è quello di modellare il nostro sistema non
utilizzando il profilo FunctionalC ma un profilo Object-based così da generare codice C a
oggetti. Questa soluzione ci viene comoda rispetto alla precedente in quanto potendo
sfruttare tutte le caratteristiche dell’UML a differenza del FunctionalC che è molto
limitato, questo ci permette di poter meglio descrivere il nostro sistema e sfruttare a pieno
le funzionalità offerte da Rhapsody. In questa versione vediamo il Class Diagram relativo
al nostro sistema (Figura 63):
Figura 63: Class Diagramm del TODMA
99
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Vediamo come a differenza del file diagram in Figura 48 qui sia possibile modellare le
interfacce offerte e le interfacce richieste per ogni classe. All’interno di ogni iterfaccia poi
abbiamo definito le operazioni che vengono offerte o che sono richieste dall’esterno.
Questo ci rende molto di più l’idea di port in ingresso e port in uscita presenti nel
diagramma IBD in Figura 30. Le relazioni poi tra le classi sono delle semplici associazioni
e notiamo anche la presenza delle interfacce nel nostro diagramma. Questo ci consente di
capire meglio intuitivamente cosa stiamo andando a fare e dove soprattutto. Il TODMA è
modellato come una classe al cui interno vi sono le istanze delle classi
TodManagementAgent,
TodControlServer
e
TodLib.
All’interno
delle
classi
TODControlServer, TODMannagmentAgent e TodLib abbiamo poi gli stessi state chart
presenti in Figure 49 e 50 con le stesse funzionalità. Vediamo poi la presenza in questo
diagramma degli attori esteri: infatti in questo modo possiamo descrivere con quali oggetti
le nostre interfacce parlano e nel nostro caso quindi abbiamo la DBU, il programma di
Calibrazione del Touch Screen e le periferiche Hardware del PcSpeaker e del Monitor.
Il nostro progetto diventa quindi più leggibile e più comprensibile e in Figura 64
vediamo l’Object Model Diagram con gli oggetti istanziati. Si nota come il componente
TODMA parli attraverso le interfacce con le istanze degli attori esterni Peripherals, DBU e
TouchScreen.
Figura 64: Object Model Diagram del TODMA
Come detto le funzioni sono le stesse ed anche il flusso di esecuzione, per ovvi motivi,
deve essere lo stesso. In Figure 65 e 66 vediamo gli State Chart del TodControlServer e
100
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
TodManagementAgent che ne descrivono il comportamento dinamico. Sono del tutto
identici agli State Chart in Figure 59 e 60 tranne che per quanto riguarda lo State Chart del
TodControlServer che a differenza del precedente non è stato modellato con gli stati ma
con i messaggi. Questo perché invece di andare a definire le operazioni da compiere
all’interno delle transizioni del nostro grafico si è utilizzato l’oggetto “send action”
all’interno di Rhapsody che rappresenta in corrispondenza di un evento l’invio di un
messaggio “evento” ad un altro State Chart con la possibilità di inviare dei paramentri.
Questo rende meglio l’idea handler associata al concetto di server che dato un evento
esterno smista l’elaborazione della richiesta ad un apposito gestore.
Figura 65: State Chart TodControlServer Object Based
101
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 66: State Chart TodManagementAgent Object Based
A questo punto una volta definita la descrizione completa del nostro componente e
definite la parti sviluppate manualmente dal programmatore che in questo caso risultano
avere gli stessi costrutti del caso precedente sviluppato in FunctionalC passiamo alla
simulazione dei nostri State Chart e alla verifica del corretto funzionamento.
Vediamo che rispetto al caso precedente, sono stati prodotti ben 73 file nella cartella di cui
66 sono i sorgenti con i rispettivi file .C .H e .obj che rappresentano tutti gli oggetti, le
classi, le interfacce e le istanze del nostro progetto, un makefile, un file di configurazione
d’ambiente di Rhapsody, un Incremental Linker File, un Program File Database e
l’applicativo finale. Le righe di codice C generate in totale sono all’incirca 8000. Risulta
evidente che nel modellare meglio il nostro progetto ne paghiamo in termini di quantità di
file e linee di codice prodotte.
Ultimo passo dovrebbe poi essere quello di realizzare grazie ai tool di Rhapsody una Test
Architecture per la generazione automatica di casi di test (tramite l’ATG di Rhapsody) per
valutarne la coverage. Purtroppo con un modello C Object Based non è possibile
realizzare questa operazione automaticamente con l’ATG. Si è reso quindi necessari ala
traduzione del nostro progetto in C++. Questa operazione può essere realizzata
102
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
automaticamente dal tool di traduzione di Rhapsody. Ovviamente non tutto il codice viene
tradotto automaticamente: quello definito dall’utente deve essere modificato manualmente.
Ad esempio al puntatore "mesi sostituisce il puntatore implicito "this", all'underscore per
separare i namespace si sostituisce l'operatore di risoluzione (es.: TodLib_function =>
TodLib::function). Una volta tradotto il progetto e trasformato in C++ è possibile generare
la Test Architecture automaticamente direttamente sul nostro componente TODMA come
vediamo in Figura 67
Figura 67: Test Architecture TODMA
Come vediamo dalla figura si ha all’interno del nostro TestContext il SUT il quale tramite
gli interlocutori con il sistema che sono la DBU, le Periphericals e il TouchScreen
effettuerà tramite l’Automatic Test Generator (ATG) il test di coverage degli elementi di
cui si vuole effettuare la verifica. Una volta poi definisti i diagrammi di sequenza (uguali
ai message diagram visti nel sottoparagrafo precedente) che ne descrivono il
comportamento e i messaggi da scambiare tra i vari componenti si può passare alla
simulazione tramite l’ATG. In Figura 68 è mostrato un esempio di simulazione.
103
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Figura 68: Automatic Test Generetor (ATG)
Vediamo che rispetto al caso precedente, sono stati prodotti 70 file nella cartella di cui 63
sono i sorgenti con i rispettivi file .C .H e .obj che rappresentano tutti gli oggetti, le classi,
le interfacce e le istanze del nostro progetto, un makefile, un file di configurazione
d’ambiente di Rhapsody, un Incremental Linker File, un Program File Database e
l’applicativo finale. Le righe di codice C generate in totale sono all’incirca 8000. Vediamo
che nel modello C++ vi è poca differenza rispetto al modello OO in quanto a file prodotti
e a linee di codice generate. Questo risulta essere in accordo a quanto ci si aspetta in
quanto restano 2 stili di programmazione simili e quindi il prodotto finale ci si aspetta sia
simile in qualche modo alla metrica da noi considerata.
In questo modo molto semplice ed immediato si può definire un componente utilizzando
un approccio Object Based e sfruttando a pieno le potenzialità dello strumento Rhapsody.
Come vantaggio oltre ad avere la possibilità di utilizzare l’UML vi è anche la possibilità
rispetto al profilo FunctionalC di poter creare un test Architetture del componente che ci
da la possibilità di testare in maniera automatica il componente e validarlo senza grosso
dispendio di energia e risorse mentre per contro abbiamo che se voglio sviluppare in C in
104
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
maniera classica devo usare per forza il profilo FuncitionalC. Questa è un alternativa alla
progettazione vista prima. Ce ne potrebbero essere molte altre che sfruttano la
programmazione ad oggetti che sicuramente hanno un livello di astrazione ancora più
ampio.
105
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Conclusioni
In questo lavoro di tesi sono stati trattati gli argomenti di Model Driven Architecture con
particolare attenzione allo standard SysML. Abbiamo visto qual è lo stato dell’arte di
queste metodologie e quali sono oggi gli strumenti a supporto. Abbiamo poi applicato ad
un caso reale le tematiche trattate e si è visto come sia possibile sviluppare e modellare in
un contest aziendale tali tecniche. Si è giunti quindi alla realizzazione dei diagrammi del
nostro sistema e quindi alla fase finale di generazione del codice. Di seguito viene
riportata una tabella riepilogativa che elenca i vantaggi e gli svantaggi di questo tipo di
approccio.
Tabella 2: Vantaggi e Svantaggi
Vantaggi
Migliore tracciabilità dei
requisiti
Maggiore livello di
integrazione tra le varie fasi di
progettazione
Early Verification in fase di
simulazione
Migliore efficienza ed efficacia
totale
Svantaggi
Codice generato
automaticamente potrebbe non
rispettare le Policy aziendali
Maggiore tempo di startup
iniziale per l’apprendimento di
nuove tecnologie
Vincolati al tipo di prodotto
utilizzato
Licenze non open source
costose
Come possiamo notare in questa tabella sono elencati tutta una serie di pro e contro i quali
sono stati valutati. Andando a vedere i vantaggi notiamo che sicuramente vi è una migliore
tracciabilità dei requisiti in quanto adottando lo standard SysML e generando poi I relative
106
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
codice partendo dai diagrammi, riusciamo a mantenere traccia di ogni singolo requisite
dalla sua scrittura fino alla sua implementazione come funzione di un file c o come
metodo di una classe; vi è poi un maggiore livello di integrazione tra le varie fasi questo
deriva dalla definizione stessa di Model Driven ovvero ogni fasi di progettazione e
realizzazione e collegata alla precedente e alla successive e questo facilita sicuramente la
cooperazione tra gli sviluppatori ma sopratutto riesce a facilitare il lavoro di tracciabilità di
tutto il ciclo di sviluppo del software; vi è poi una migliore e più rapida verifica di quanto
sviluppato attraverso le simulazioni del progetto, infatti potendo testare rapidamente il
comportamento ci si rende subito conto se vi sono errori di modellazione e/o progettazione
oppure no; infine si una maggiore efficienza ed efficacia totale è dovuta alla maggiore
consapevolezza che ogni sviluppatore in questo senso ha del progetto ed ad una maggiore
chiarezza di intervento nel caso in cui di debba andare ad operare ad un livello specifico di
sviluppo e dato che utilizzando questo modo di procedure si è quasi costretti ad intervenire
sui diagrammi e no sul codice si ha anche una minore probabilità di errore.
Oltre ai vantaggi andiamo a considerare quelli che sono gli svantaggi di tale approccio: Un
problema che potrebbe sorgere è quello di avere la necessità di individuare punto per
punto tutte le linee di codice prodotto dal programma di sviluppo: questo può creare
qualche difficoltà, in base al tipo di prodotto utilizzato, in quanto il codice generato
automaticamente potrebbe non corrispondere alle specifiche di Policy di scrittura del
codice d’azienda che lo utilizza; altro punto dolente è sicuramente la fase di
apprendimento da parte degli sviluppatori di nuovi tool o tecnologie la quale richiederà da
parte di un azienda un costo iniziali in termini di denaro e di tempo maggiore; altro punto
dolente è il vincolo di utilizzare un software specifico per lo sviluppo, infatti sappiamo che
l’utilizzo di un programma piuttosto che un altro in quanto a seconda del programma
utilizzato vi possono essere delle limitazioni in termini di servizi offerti (vedi ad esempio
l’importazione di file XMI in Rhapsody cap 4.4.3) oppure potrebbero avere dei costrutti
interni che non possono essere utilizzati (vedi ad esempio il flow chart in Rhapsody cap
107
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
4.4.3); infine c’è da tener conto dei costi delle licenze per I programmi non open source
che sicuramente vanno ad incidere molto sulla valutazione finale da parte di un azienda.
108
PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO
Sviluppi Futuri
I Possibili sviluppi futuri a questo lavoro di tesi sono qui elencati:
Valutare lo svolgimento di un progetto simile utilizzando ambienti di sviluppo differenti
come ad esempio Matlab.
Valutare lo svolgimento dello stesso progetto da parte di due sviluppatori con lo stesso
background conoscitivo, uno che utilizza l’approccio visto in questa tesi, un altro che utilizza
un approccio classico, ovvero programmando “a mano”, per capire quali possono essere i
vantaggi in termini di tempo e risorse di questo approccio.
Ampliare l’analisi effettuata inserendo maggiori dettagli sull’implementazione fisica del
componente, come ad esempio definire nello specifico le reali funzioni che l’applicativo deve
effettuare linkando tutte le librerie che servono, integrandolo all’interno del contesto in cui
dovrà poi essere utilizzato ed infine testarlo accuratamente, così da fornire non un prototipo ma
un prodotto finito.
Proporre uno sviluppo di tipo Object Based piuttosto che imperativo come impostazione di
progetto per sfruttare a pieno tutte le potenzialità UML e avere la possibilità di costruire un Test
Architecture per il test automatico del componente.
109
Bibliografia
[1]
Alan W. Brown, Jim Conallen, and Dave Tropeano, Introduction: Models,
Modeling, and Model-Driven Architecture (MDA), Springen, 2005.
[2]
Frank Truyen, The Fast Guide to Model Driven Architecture, The Basics of
Model Driven Architecture (MDA), Cephas Consulting Corp, January 2006.
[3]
Mark Utting and Bruno Legeard, Pratical Model-Based Testing (MBT) a
tools approach, Elsevier, 2007.
[4]
John D. Poole, Model-Driven Architecture: Vision, Standards And
Emerging Technologies, Position Paper Submitted to ECOOP 2001 - Workshop on
Metamodeling and Adaptive Object Models, Hyperion Solutions Corporation, Aprile
2001.
[5]
eclipse.org, http://www.eclipse.org/papyrus, acceduto il 14 settembre 2014.
[6]
ibm.com,
http://www-03.ibm.com/software/products/it/ratirhapfami/,
acceduto il 14 settembre 2014.
[7]
ibm.com, http://www-03.ibm.com/software/products/it/ratirhap, acceduto il
14 settembre 2014.
[8]
IBM, Rhapsody Tutorial C, Telelogic, 2008.
[9]
IBM, Rhapsody User Guide, Telelogic, 2008.
[10]
Francesco Pascale, Domenico Di Leo, Stefano Russo, Specifica dei Requisiti
Software del modulo TODMA, Critiware s.r.l. per AnsaldboBreda s.p.a. , 2014.
[11]
http://www.sysmlforum.com,
http://www.sysmlforum.com/sysml-faq,
acceduto il 3 Settembre 2014.
[12]
Lenny Delligatti, SysML Distilled, Addison-Wesley, November 2013.
110
Ringraziamenti
I Miei più vivi ringraziamenti vanno al Chiarissimo professore Stefano Russo al
quale devo il merito di avermi portato a conseguire questo mio secondo importante
traguardo.
Ringrazio altresì l’Ingegnere Domenico Di Leo e l’Ingegnere Bruno Busco i quali si
sono dimostrati sempre molto disponibili e professionali durante tutto il periodo della tesi.
Un ringraziamento va anche a tutti i Docenti, i Ricercatori, i Collaboratori e i Tesisti
del Laboratorio MOBILAB del Dipartimento di Ingegneria Elettrica e Tecnologie
dell’Informazione dell’Università degli Studi di Napoli “Federico II” che mi hanno
ospitato durante il periodo del mio lavoro. In particolare vorrei ringraziare l’Ingegnere
Fabio Scippacercola, il quale mi ha dato una grossa mano in un momento critico del mio
percorso di tesi.
Vorrei ringraziare la mia famiglia che mi è sempre stata vicina in questi anni
universitari. Ai miei genitori non posso fare altro che dedicare tutto ciò che ho fatto,
perché solo grazie a loro che oggi mi trovo qui. A mia sorella Maria Grazia va tutto il mio
entusiasmo e la mia determinazione affinché riesca anche lei a raggiungere i suoi obiettivi.
A mia sorella Valeria, ad Amilcare ed al piccolo Luca, a mia Nonna, a mia Zia Pia, a mio
Zio Cosimo e a Lucia vanno tutti i miei più sentiti ringraziamenti per avermi supportato e
sopportato. A mio Cugino Marco, a mia Zia Anna e alle mie cugine ed a tutti i miei zii e
111
cugini, grazie, siete la mia famiglia.
Alla mia ragazza, Enrica, ringraziarti solamente sarebbe poco. Mi hai aiutato forse
nel momento peggiore di questo mio percorso, ed oggi se mi ritrovo qui è anche grazie a
te. Grazie di cuore.
Ringrazio i miei amici di corso, Emanuele, Mario e Claudio, con i quali ho
condiviso gioie e dolori.
Ringrazio l’Associazione ASSI (Associazione degli Studenti d’Ingegneria)
dell’Università degli Studi di Napoli “Federico II” per gli splendidi anni passati insieme.
Infine vorrei ringraziare tutte quelle persone, amici e conoscenti, i quali pur non
avendo influito direttamente nel mio percorso di studi, sono stati per me di grande aiuto e
fonte di ispirazione. Ringrazio il Dottor Gennaro Fiore e il Cavaliere Giuseppe Barra per
quanto mi hanno dato. Ringrazio i miei amici di sempre, Vincenzo (Taty), Marco Antonio,
Emanuele, Luigi, Cosimo, Gennaro, Vincenzo Masillo, Antonio Fiume, Nello, Dario,
Emanuele (Zeta), Matteone. Ringrazio gli amici dell’AGA, Carmine, Luca, Francesco,
Walter, Antonello, Daniele, Gianfranco, Alessandro, Pietro, Angelo, Mimmo e Pasquale.
Anche se il lavoro ci porta a stare lontani, resteremo sempre l’AGA. Ringrazio tutti gli
amici di Eboli, dell’Università di Salerno, dell’Università di Napoli, quelli d’Italia e quelli
del resto del mondo.
A tutte le persone che mi vogliono bene e anche a tutti quelli che oggi non sono
potuti essere qui, vi ringrazio.
112
