PROGETTAZIONE MODEL-DRIVEN DI UN SISTEMA ......PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED...

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

IV

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

PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED CRITICO

5

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


6

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


7

Indice delle tabelle

Tabella 1: Software Requirements Specification TODMA…………………………………………61

Tabella 2:Vantaggi e Svantaggi……………………………………………………………………106


8

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 model-

driven, 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


9

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.


10

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. 2Model-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.

http://it.wikipedia.org/wiki/Object_Management_Group

http://it.wikipedia.org/wiki/Modello

http://it.wikipedia.org/wiki/Implementare


11

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


12

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 Metamodel

5 (CWM). Altre tecnologie

adottate che sono di interesse sono il profilo UML per Enterprise Distributed Computing

Object6 (EDOC), compresa la sua mappatura di EJB

7, e la CORBA Component Model

8

(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.


13

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


14

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.


15

• 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 .NET

10; 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.


16

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).


17

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 model-

based:

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.


18

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 15

in Java16

, o in un

linguaggio dinamico come Python17

o Tcl18

, o in un linguaggio di scripting di prova

dedicato.

15

JUnit è un framework di unit testing per il linguaggio di programmazione Java 16

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.


19

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 warehousing20

e 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


20

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


21

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

IDE23

comprendono 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.


22

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.


23

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.


24

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):


25

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


26

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.


27

• 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.


28

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 software-

centric 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:


29

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


30

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


31

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:


32

Figura 6: Esempio BDD Strutturato


33

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):


34

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


35

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


36

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 flow-

specification è 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.


37

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).


38

Figura 10: Esempio di instanza in un BDD

Figura 11: Esempio di composizione in un BDD


39

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).


40

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).


41

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).


42

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.


43

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.


44

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


45

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


46

• 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,


47

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


48

«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


49

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).


50

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à


51

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 plug-

in 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 29

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


52

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


53

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,


54

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.


55

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


56

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


57

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.


58

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.


59

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à.


60

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.


61

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 Gruppo di

appartenenza

HLR_GEN_001 Il modulo TODMA deve essere compilato e collegato

staticamente al modulo SW TOD control server che è

in esecuzione sul TOD.

Requisiti Generali

HLR_GEN_002 Il TOD control server deve interagire con il modulo

TODD della DBU, i Driver del TOD e l’HMI

attraverso esclusivamente il modulo TODMA

Requisiti Generali

HLR_GEN_003 Il TODMA riceve richieste dal modulo TODD del

server DBU e dal modulo HMI tramite URI

Requisiti Generali

HLR_SRV_001 All’avvio, Il TODMA non deve conoscere l’indirizzo

del server DBU

Servizi forniti dal

modulo TODMA

HLR_SRV_002 Il TODMA deve ricavare l’indirizzo del server DBU da

un’apposita richiesta

Servizi forniti dal

modulo TODMA

HLR_SRV_003 Il TODMA deve tenere una sessione con una sola DBU

fin tanto che questa è attiva.

Servizi forniti dal

modulo TODMA

HLR_SRV_004 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.

Servizi forniti dal

modulo TODMA

HLR_SRV_005 Il tempo lifetime è fornito dalla DBU quando contatta il

TODMA tramite un’apposita richiesta ed è espresso in

secondi

Servizi forniti dal

modulo TODMA

HLR_SRV_006 Il TODMA può avviare una nuova sessione con una

nuova DBU se la sessione precedente è stata terminata

Servizi forniti dal

modulo TODMA

HLR_SRV_007 Ad una richiesta effettuata dal modulo TODD della

DBU, il TODMA deve far emettere un beep al TOD

Servizi forniti dal

modulo TODMA


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

Servizi forniti dal

modulo TODMA


DBU, il TODMA deve fornire una diagnostica sullo

stato del servizio

Servizi forniti dal

modulo TODMA


DBU, il TODMA deve forzare l’HMI ad una

determinata URI

Servizi forniti dal

modulo TODMA

35

Software requirements specification (SRS) è una descrizione completa del comportamento di un sistema da

sviluppare.


62

HLR_SRV_0011 Quando richiesto dall’utente tramite interazione

manuale con l’HMI, il TODMA deve avviare un

processo di taratura del touch screen (TST architettura)

Servizi forniti dal

modulo TODMA

HLR_SRV_0012 Il TODMA può terminare e ripristinare l’esecuzione

dell’HMI in qualsiasi istante

Servizi forniti dal

modulo TODMA

HLR_SRV_0013 Il TODMA deve indicare una pagina statica locale

all’HMI (vedi HLR_EST_003)

Servizi forniti dal

modulo TODMA

HLR_SRV_0014 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

Servizi forniti dal

modulo TODMA

HLR_SRV_0015 IL TODMA deve far visualizzare al modulo HMI

l’ultima URI nel caso in cui venga ripristinata la

connessione

Servizi forniti dal

modulo TODMA

HLR_SRV_0016 IL TODMA deve segnalare la presenza di un operatore

alla DBU nel caso in cui lo schermo fosse spento

Servizi forniti dal

modulo TODMA

HLR_HMI_001 L’HMI è in esecuzione sul TOD e deve visualizzare

pagine HTML provenienti dal modulo TODD della

DBU

Funzionalità

dell’HMI

HLR_HMI_002 L’HMI visualizza pagine il cui l’indirizzo è fornito dal

modulo TODMA del TOD (comunicazione indiretta)

Funzionalità

dell’HMI

HLR_HMI_003 L’HMI è dotato di un’estensione browser che gestisce

la interazione tra l’HMI e il TODMA

Funzionalità

dell’HMI

HLR_HMI_004 L’HMI deve in qualsiasi momento visualizzare il logo

AB nel caso in cui venga richiesto dal modulo

TODMA

Funzionalità

dell’HMI

HLR_EST_001 L’estensione è un ADD-ON presente sul browser il

quale interagisce con il modulo TODMA richiedendo

ciclicamente la URI alla quale collegarsi

Estensione HMI

HLR_EST_002 All’avvio del browser verrà indicata dal TODMA una

pagina statica da caricare, presente in locale

Estensione HMI

HLR_EST_003 Se all’avvio il TODMA non fornisce alcuna URI verrà

visualizzata la pagina statica presente in locale

Estensione HMI

HLR_EST_004 L’estensione deve contattare ciclicamente il TODMA

per farsi fornire la URI alla quale collegarsi

Estensione HMI

HLR_DRV_001 L'emissione del beep di cui al requisito

HLR_SERV_001 deve essere effettuata tramite

funzioni di libreria specificate dal fornitore del TOD

Utilizzo dei

DRIVER

HLR_DRV_002 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

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 Model-


63

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 Model-

Driven 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


64

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:


65

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


66

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:


67

Figura 28: RD dei requisiti del gruppo EST

Anche questo come il precedente è molto strutturato ed infatti tutti i requisiti

HLR_EST compongono il gruppo dei requisiti dell’estensione e i requisiti

HLR_EST_001, HLR_EST_002 e HLR_EST_004 deriva no dal 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:


68

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 mentre il requisito

HLR_DRV_002 è derivato dal requisito HLR_SRV_008. 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


69

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:


70

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


71

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


72

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


73

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


74

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


75

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


(reqElaborationRedirectSetUri) il quale farà al suo interno le dovute elaborazioni.

7. Alla richiesta di redirect dell’HMI da parte dell’HMI (reqGetUriAction) proveniente


(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.


76

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


77

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 è


78

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


79

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-44-

45 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


80

Figura 42: Allocazione dei requisiti rispetto al blocco Tod Control Server

Figura 43: Allocazione dei requisiti rispetto al blocco HMI


81

Figura 44: Allocazione dei requisiti rispetto al blocco Add-On

Figura 45: Allocazione dei requisiti rispetto al blocco driver Tod


82

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


83

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:


84

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 si hanno 7 funzioni relative a

reqAndRespElaborationDiagnostic, reqAndRespElaborationRedirectGetUri,


85

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:


86

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


87

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, evReqGetUri.

evReqSetUri, evReqTouchScreenCalibrator, evReqBrightness. Tutti 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:


88

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


89

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.


90

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


91


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


92


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


93


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


94


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


95


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:


96

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:


97

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


98

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


99

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


100

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


101

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


102

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


103

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.


104

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


105

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.


106

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 Svantaggi

Migliore tracciabilità dei

requisiti

Codice generato

automaticamente potrebbe non

rispettare le Policy aziendali

Maggiore livello di

integrazione tra le varie fasi di

progettazione

Maggiore tempo di startup

iniziale per l’apprendimento di

nuove tecnologie

Early Verification in fase di

simulazione

Vincolati al tipo di prodotto

utilizzato

Migliore efficienza ed efficacia

totale

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


107

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


108

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.


109

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.

110

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.

111

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

112

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.

PROGETTAZIONE MODEL-DRIVEN DI UN SISTEMA ......PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED...

Documents

Transcript of PROGETTAZIONE MODEL-DRIVEN DI UN SISTEMA ......PROGETTAZIONE DEL SOFTWARE DI UN SISTEMA EMBEDDED...