Linguaggio di Modellazione SysML FRANCIA N46000294 · Anno Accademico 2013/2014 Candidato: FRANCIA...

Linguaggio di Modellazione SysML

I

Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del Software

Linguaggio di Modellazione SysML Anno Accademico 2013/2014 Candidato: FRANCIA FRANCESCO matr. N46/000294


II

INDICE Introduzione ................................................................................................................................ 5 CAPITOLO 1. Ingegneria dei Sistemi..................................................................... 6

1.1 Sistema........................................................................................................................ 6

1.2 System Engineering................................................................................................. 7

CAPITOLO 2. SysML e UML.................................................................................. 11

2.1 Panoramica su UML 2.0....................................................................................... 11

2.2 Storia del linguaggio SysML............................................................................... 12

2.3 Standard SysML..................................................................................................... 13

2.4 SysML vs. UML 2.0.............................................................................................. 15

CAPITOLO 3. Struttura SysML............................................................................ 18

3.1 Concetti Introduttivi.............................................................................................. 18

3.2 Diagrammi Strutturali........................................................................................... 21

3.2.1 Block Definition Diagram................................................................................ 22 3.2.2 Internal Block Diagram................................................................................... 23 3.2.3 Parametric Diagram........................................................................................ 25 3.2.4 Package Diagram............................................................................................ 26


III

Indice

3.3 Diagrammi Comportamentali.............................................................................. 27

3.3.1 Activity Diagram.............................................................................................. 27 3.3.2 Sequence Diagram........................................................................................... 28 3.3.3 State Machine Diagram................................................................................... 29 3.3.4 Use Case Diagram........................................................................................... 30

3.4 Diagrammi Generici.............................................................................................. 31

3.4.1 Requirements Diagram.................................................................................... 31

CAPITOLO 4. Modellazione sistema : INFOMOBILITA’......................... 34

4.1 Documentazione...................................................................................................... 34

4.1.1 Descrizione del progetto.................................................................................. 35 4.1.2 Obiettivi del sistema........................................................................................ 35 4.1.3 Contesto del Progetto...................................................................................... 36 4.1.4 Identificazione degli Stakeholders................................................................... 37 4.1.5 Identificazione dei Requisiti............................................................................ 39 4.1.6 Package Diagram INFOMOBILITA’.............................................................. 42 4.1.7 Parametric Diagram INFOMOBILITA’.......................................................... 42 4.1.8 Use Case Diagram INFOMOBILITA’............................................................. 43 4.1.9 Activity Diagram INFOMOBILITA’................................................................ 44 4.1.10 Sequence Diagram INFOMOBILITA’........................................................... 45

Bibliografia................................................................................................................................. 47


IV

Indice delle Figure Figura 1.2: Ambiti del System Engineering 8 Figura 2.1: Struttura dei livelli UML (fonte: Systems Engineering with SysML/UML, Feb 2008, Morgan Kaufmann) 12 Figura 2.2: UML 2.0 e SysML (fonte: http://www.omgsysml.org) 14 Figura 2.3: Diagrammi SysML (fonte: http://www.omgsysml.org) 15 Figura 3.1: Struttura dei livelli SysML (fonte: Systems Engineering with SysML/UML, Feb 2008, Morgan Kaufmann) 19 Figura 3.2: Diagrammi SysML 20 Figura 3.3 : Block 21 Figura 3.4 : Block Definition Diagram 22 Figura 3.5 : Internal Block Diagram 23 Figura 3.6: Item Flows e Internal Block Diagram (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) 24 25 25 Figura 3.7: Newton’s World (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) 25 Figura 3.8: Constraint Block (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) 26 Figura 3.9: Activity Diagram 28 Figura 3.10: Sequence Diagram (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) 29 Figura 3.11: State Machine Diagram 30 Figura 3.12: Use Case Diagram 31 Figura 3.13: Requirement Diagram 32 Figura 4.1: Stakeholders table INFOMOBILITA’ 38 Figura 4.2: Requirements Diagram INFOMOBILITA’ 39 Figura 4.5: Requirements Derivation INFOMOBILITA’ 41 Figura 4.6: Package Diagram INFOMOBILITA’ 42 Figura 4.7: Parametric Diagram INFOMOBILITA’ 42 Figura 4.8: Use Case Diagram INFOMOBILITA’ 43 Figura 4.9: Activity Diagram INFOMOBILITA’ Verifica Badge 44 Figura 4.10: Sequence Diagram INFOMOBILITA’ Badge Reader Deposito 45 Figura 4.11: Sequence Diagram INFOMOBILITA’ Computer di Bordo Autista 46 Figura 4.12: Sequence Diagram INFOMOBILITA’ Computer di Bordo Controllore 46 Indice delle Tabelle Tabella 1.1: Contesto System Engineering 7 Tabella 3.14: Requirement Table 33 Tabella 4.3: Tabella dei requisiti funzionali INFOMOBILITA’ 40 Tabella 4.4: Tabella dei requisiti non-funzionali 41


5

Introduzione

Questo elaborato tratta il “LINGUAGGIO DI MODELLAZIONE SysML, System Modeling Language” e si inquadra nell’ambito dell’Ingegneria dei Sistemi, System Engineering (SE). Il percorso intrapreso per descrivere tutti gli aspetti fondamentali dell’argomento in questione, è:

- L’introduzione al System Engineering (SE).

- La trattazione approfondita del linguaggio standard di modellazione System

Modeling Language (SysML), ripercorrendo la sua evoluzione, dalla

creazione allo stato attuale e gli ambiti di utilizzo.

- La descrizione dettagliata della struttura del linguaggio.

- Un breve confronto con Unified Modeling Language (UML), riguardante i

pro e i contro della convenienza dell’utilizzo di un linguaggio piuttosto che

l’altro.

- Lo sviluppo di un esempio pratico di modellazione di un sistema attraverso

il Sytems Modeling Language.


6

CAPITOLO 1 Ingegneria dei Sistemi

1.1 Sistema Un Sistema è un aggregato di unità ed elementi, più o meno articolato, creato

al fine di ottenere un preciso obiettivo.

La complessità del sistema deriva dalle relazioni strutturali e dinamiche tra le

entità che lo compongono, e la dimensione di questo non implica l’aumento

della sua complessità.

Un sistema consiste in componenti o blocchi che, nella loro interazione,

concorrono al perseguimento di un obiettivo commune.

La caratteristica principale di un sistema è che i blocchi e le componenti,

mediante questa interazione, hanno significato se sono parte integrante del

sistema, per cui, se presi singolarmente, possono non adempiere all’obiettivo

oppure perdere di significato.


7

1.2 System Engineering La definizione di System Engineering data dell’International Council of System Engineering (INCOSE) è: “Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems”. L’Ingegneria dei Sistemi riguarda:

- la definizione e la documentazione dei requisiti del sistema nella fase di analisi progettuale;

- la fase di sviluppo in cui comincia a prendere forma il progetto; - il testing del sistema.

L’Ingegneria dei Sistemi si occupa dell’intero processo di sviluppo del progetto, dall’idea alla creazione, passando per la progettazione, realizzazione e testing, e comprende sia aspetti tecnici che economici. E’ importante definire i Sistemi di Sistemi (SoS) che sono aggregati di sistemi, tra loro eterogenei, ma coordinati e interagenti al fine di raggiungere determinati scopi comuni; i sistemi aggregati, che compongono il sistema-di-sistema, vengono chiamati sotto-sistemi. Il sistema globale, quindi, sarà un insieme di sotto-sistemi, sviluppati per ottenere uno o più obiettivi. Tabella 1.1: Contesto System Engineering

SYSTEM ENGINEERING

SOFT

WA

RE

ENG

INEE

RIN

G

ELEC

TRIC

AL

ENG

INEE

RIN

G

MEC

HA

NIC

AL

ENG

INEE

RIN

G

MA

TER

IAL

ENG

INEE

RIN

G

CIV

IL

ENG

INEE

RIN

G

……

……

…

Con la definizione System Engineering si individuano le relazioni, le


8

dipendenze e le dinamiche tra le differenti componenti di un sistema. All’interno del System Engineering si identificano dei termini convenzionali in base al loro utilizzo ormai diffuso. Si tratta di System, Element, Subsystem, Assembly, Subassembly, Component, Part. Questa terminologia, non a caso, serve ad intensificare la complessità di un sistema in maniera sempre più dettagliata, dal generale al particolare. Il System Engineering è una disciplina che non ha un linguaggio di modellazione unico e deve svincolarsi completamente dalle specifiche materie, che, in aggregato, creano il sistema. Il concetto fondamentale, così come la difficoltà primaria, è quella di raggiungere l’obiettivo finale, di indirizzare tutti i blocchi componenti verso un unico scopo, rendendo coerente e armonizzata l’aggregazione delle parti. Quest’obiettivo lo si raggiunge attraverso l’utilizzo di un insieme di strumenti e operazioni a disposizione. Sia in fase di Analisi dei Requisiti che in fase di Sintesi del progetto, questi strumenti e queste operazioni sono le fondamenta per la progettazione, lo sviluppo, la verifica, il testing, la validazione, l’integrazione fra sistemi, la documentazione, l’analisi dei rischi e la possibilità di evoluzione futura di un processo di sviluppo strutturato.

Figura 1.2: Ambiti del System Engineering


9

Tramite gli specifici requisiti richiesti, a partire dal concetto astratto, passando per la fase operativa, si arriva al prodotto finale. E’ importante notare che questo tipo di approccio, oltre a valutare l’aspetto tecnico, è coinvolto anche in ruoli di coordinamento e, nell’analisi della fattibilità del progetto, valuta soprattutto l’aspetto economico. Quando si sviluppa un sistema, i punti sintetizzati dall’International Council of System Engineering (INCOSE) per racchiudere l’essenza delle attività di System Engineering, iniziano con la pianificazione totale del lavoro e inquadrano il problema che il sistema deve risolvere. I concetti fondamentali da sviluppare sono i seguenti:

- Comprensione del problema, si analizzano quali sono eventualmente i

problemi che un sistema crea o potrebbe creare.

- Specifica dei requisiti, nell’ambito della quale si concordano e si gestiscono

i requisiti.

- Valutazione di possibili soluzioni alternative.

- Definizione delle interfacce e possibilità di gestione.

- Preparazione degli appositi test per valutare la robustezza del sistema.

- Creazione di una documentazione per il supporto di sistema.

- Scelta dell’ambiente e delle tempistiche di utilizzo del sistema e valutazione

della possibilità di rimpiazzarlo.

L’analisi di un problema si concretizza attraverso questi punti, che possono essere affrontati in maniera lineare o trasversale (Problem-solving cycle):

- si descrive la situazione corrente e si formulano gli obiettivi da raggiungere;

- si lavora alle possibili soluzioni;

- si sceglie la soluzione migliore.


10

Il System Engineering Processes utilizza un approccio detto S.I.M.I.L.A.R. :

- State of the problem

- Investigate alternatives (SysML)

- Model System (SysML)

- Integrate

- Launch the System

- Assess Performance

- Re-Evaluate


11

CAPITOLO 2 SysML e UML 2.0

2.1 Panoramica su UML 2.0

Unified Modeling Language (UML) è nato come strumento di sviluppo di

modelli per i sistemi software e si è evoluto nel settore come standard globale;

esso può essere utilizzato in ambiti differenti, grazie alla grande capacità di

adattamento, mediante l’uso di meccanismi di estensione standard: gli

stereotipi.

Nell’evoluzione ad Unified Modeling Language 2.0 (UML 2.0) il suo utilizzo

è stato ampliato anche ad altri ambiti, compreso il Systems Engineering, con

degli ovvi limiti dovuti al fatto che il suo specifico utilizzo è nato ed orientato

verso lo sviluppo software.

UML consta di due distinti livelli, Model e Diagram, ed è caratterizzato in

maniera modulare, per cui si può lavorare con una parte del linguaggio

piuttosto che con un’altra, senza compromettere la completezza della

modellazione del sistema.


12

Il livello Model contiene la descrizione completa del sistema, mentre il livello Diagram è composto da porzioni che sviluppano ed analizzano solo certi aspetti del modello. Osserviamo la figura riassuntiva:

Figura 2.1: Struttura dei livelli UML (fonte: Systems Engineering with SysML/UML, Feb 2008, Morgan Kaufmann)

UML è estendibile a più settori, motivo per cui è definito “unified”; in più contiene modelli ed elementi utilizzabili nei particolari ambiti sebbene sia carente nel descrivere montaggi e configurazioni profondamente annidate.

2.2 Storia del linguaggio di modellazione SysML Il Linguaggio di Modellazione grafico per i sistemi, OMG SysML, Object Management Group Sytems Modeling Language, è stato il frutto di una lunga evoluzione. La versione attuale di OMG SysML, aggiornata al 2012 e approvata dall’ Object Management Group, è la 1.3. Le sue radici affondano in UML 2.0, Unified Modeling Language 2.0, quando, nel 2001, fu eletto dall’ International Council of System Engineering (INCOSE), insieme all’Object Management Group (OMG), come linguaggio standard per il System Engineering, dopo aver fondato il System Engineering Domain Special Interest Group (SE DISG).


13

Questo adattamento di UML 2.0, orientato al soddisfacimento dei sistemi ingegneristici, è quello che in futuro verrà delineato ed uniformato prendendo il nome di SysML, Sytems Modeling Language. Nel 2003 figura in maniera ufficiale il nome di SysML, nato come un gruppo di lavoro unico, SysML Partners, e poi diviso, nel 2005, in SysML Partners e SysML Submission Team. I gruppi di lavoro erano formati da varie figure rappresentative dell’industria informatica, autorità governative, produttori di software, ed altre cooperative, con l’obiettivo di uniformare l’estensione del linguaggio di modellazione per i sistemi complessi. Il lavoro si concretizza nel 2006 quando, i due gruppi di lavoro, dopo una serie di evoluzioni, fondano insieme il SysML Merge Team; infatti, proprio nell’aprile del 2006, l’OMG SysML è stato accettato come standard da OMG, INCOSE e ISO AP-233 (Standard internazionale di rappresentazione di dati per i sistemi ingegneristici). La prima versione di SysML (1.0) è stata pubblicata dall’OMG come standard ufficiale nel 2007; attualmente un gruppo di lavoro chiamato SysML Revision Task Force continua a lavorare per raffinare e sviluppare al meglio il progetto.

2.3 Standard SysML Nell’aprile del 2006 SysML, Sytems Modeling Language, è stato accettato come standard, ma in realtà questo processo di standardizzazione e uniformazione del linguaggio, è stato protratto per circa un anno fino alla pubblicazione da parte di OMG, Object Management Group, della versione 1.0 nel settembre del 2007. SysML è un linguaggio di modellazione grafica, che estende le funzionalità di UML 2.0, Unified Modeling Language 2.0, con lo scopo principale di permettere la descrizione, l’analisi, la progettazione, la verifica e il testing dei sistemi complessi sotto più punti di vista, che vanno dall’hardware al software, dalla gestione dati alla gestione del personale passando anche per l’ambito business (commerciale) ed economico.


14

Figura 2.2: UML 2.0 e SysML (fonte: http://www.omgsysml.org)

Il punto di forza di SysML è che riutilizza ed estende, perfezionando alcuni concetti ed elementi di UML 2.0 ed aggiunge nuovi schemi funzionali. Tutto ciò è volto alla modellazione dei sistemi; riutilizzando le funzioni proprie di UML, i progetti persistenti e sviluppati attraverso esso, possono essere riutilizzati e plasmati in funzione delle proprie necessità, senza dover elaborare tutto ex-novo con SysML. Per fare questo è stato definito un sotto insieme di UML 2.0, chiamato UML4SysML, al fine di eliminare ciò che è superfluo e che appesantisce il progetto, in modo da adattarlo completamente alla nuova funzione. Utilizzando ancora questo tool, come meta-modello, si ricostruisce un profilo proprio di SysML.


15

Nell’organizzazione dei diagrammi di SysML è possibile riutilizzare molti diagrammi UML 2.0; alcuni vengono rinominati ed estesi, e solo due sono completamente nuovi: Requirement Diagram e Parametric Diagram.

Figura 2.3: Diagrammi SysML (fonte: http://www.omgsysml.org) Nel capitolo seguente sarà illustrata in maniera adeguata la strutturazione di SysML.

2.4 SysML vs. UML 2.0 La conoscenza approfondita di UML, Unified Modeling Language, è importante ma non sufficiente per conoscere completamente SysML, Sytems Modeling Language. Questo nuovo Linguaggio di Modellazione grafica, in parte riutilizza UML, che resta invariato, ed in parte lo riutilizza e lo estende; di conseguenza un utente che utilizza UML non è la stessa tipologia di utente che utilizza SysML. Si può affermare che SysML non è solo ed esattamente un’estensione di UML, poiché ci sono aree in cui le notazioni sono significativamente differenti, l’utilizzo previsto e il processo di pianificazione, sono completamente diverse. E’ opportuno interrogarsi sull’effettiva necessità di un altro linguaggio di modellazione, oltre ad UML.


16

UML è un ottimo e potente linguaggio di modellazione, che può essere definito “software-centrico”, ma che ha qualche piccolo difetto in relazione al System Engineering, per la mancanza di alcuni aspetti propri fondamentali dello sviluppo dei sistemi. La caratteristica principale di UML, quindi, è la sua specializzazione nell’ambito software; esso è fortemente caratterizzato dall’attività orientata agli oggetti, ragion per cui è in parte incompatibile con il System Engineering, poiché quest’ultimo percorre in maniera trasversale tutte le discipline. UML è un linguaggio consolidato, è possibile conoscerlo ed approfondirlo attraverso una grande quantità di materiale, cartaceo e multimediale ed esiste un costante feedback da parte degli utenti. Il linguaggio SysML, invece, è relativamente recente perciò non ancora abbastanza diffuso. Il vero punto di forza di SysML è che, nella progettazione e modellazione dei sistemi complessi, permette di aggregare sistemi eterogenei senza inficiare sul risultato finale, cioè senza mascherare quelle che sono le sfaccettature e complessità globali del sistema. Per il Linguaggio di Modellazione SysML abbiamo due livelli:

- livello di Modello;

- livello di Diagramma.

Ci sono poi tre sezioni :

- sezione Strutturale;

- sezione Comportamentale;

- sezione Generica.

SysML, quindi, migliora UML per la modellazione dei sistemi; di conseguenza è considerato il linguaggio deputato alla modellazione dei Systems Engineering. Come affermato precedentemente SysML, oltre a contenere una porzione di elementi di UML, ne omette una buona parte e ne introduce di nuovi. SysML introduce:

- estensioni relative a stereotipi, che possono essere ancora definiti attraverso un qualsiasi tool UML;

- estensioni relative ad una serie di nuovi diagrammi, che necessitano invece

di un particolare supporto.


17

In generale, per il livello di modellazione, non c’è uno standard preciso da seguire, poiché gli elementi di UML che non sono presenti in SysML permangono nei tool di modellazione, ed in base al particolare tool che si utilizza, possiamo avere un mix tra modello UML e modello SysML. “SysML is also much more than just a software modelling technology because

it supports modelling of multiple engineering disciplines including hw, sw,

information, processes, personnel, and facilities”. (INCOSE OMGSysML

tutorial 2009)

L’utilizzo combinato di SysML per i Systems Engineering e di UML 2.0 per i Softwares Engineering, hanno permesso lo sviluppo di sistemi complessi e il miglioramento della comunicazione tra i vari interessati (stakeholders), che partecipano al processo di sviluppo del sistema. Questa combinazione promuove anche l’interoperabilità tra i tools di modellazione. Definizione ufficiale INCOSE OMGSysML :

“SysML is a standard modelling language for system engineering to analyse,

specify, design and verify complex systems.

This language is intended to enhance system quality, improve the ability to

exchange systems engineering information among tools, and help bridge the

semantic gap between systems, software, and other engineering disciplines”.

(INCOSE OMGSysML tutorial 2009)


18

CAPITOLO 3 Struttura SysML

3.1 Concetti Introduttivi

SysML è il Linguaggio di Modellazione grafico che supporta la descrizione, l’analisi, lo sviluppo, la verifica e il test di un ampio range di sistemi e di Sistemi-di-Sistemi (SoS), cercando di mettere in luce i dettagli fondamentali e i relativi campi di applicazione. Le fondamenta su cui si basa SysML sono principalmente quattro:

- Structure: System hierarchies, Interconnections (block diagram, internal block diagram)

- Behaviour: Function-Based Behaviours, State-Based Behaviours (use case,

interaction, activity, state diagrams)

- Requirements: Requirements Hierarchies, Traceability

- Proprieties: Parametric Models, Time Variabile Attributes


19

SysML, nello specifico, include nove tipi di diagrammi, in particolare quattro tipi di Diagrammi Strutturali, quattro tipi di Diagrammi Comportamentali e un Diagramma dei Requisiti, come possiamo osservare dalla figura sotto :

Figura 3.1: Struttura dei livelli SysML (fonte: Systems Engineering with SysML/UML, Feb

2008, Morgan Kaufmann) Parte dei packages di UML non vengono riutilizzati poiché non sono considerati essenziali per i System Engineering; altri vengono ereditati e riutilizzati ed altri ancora vengono estesi. SysML introduce due nuovi tipi di diagrammi: quello dei requisiti, Requirement Diagram e quello parametrico, Parametric Diagram. In aggiunta modifica tre tipi di diagrammi di UML: il Block Definition Diagram dal Class Diagram di UML, l’Internal Block Diagram dal Composite Structure Diagram di UML e l’Activity Diagram, che viene esteso. Gli ultimi quattro diagrammi (Use Case Diagram, Package Diagram, Sequence Diagram, State Machine Diagram) sono ereditati da UML e riutilizzati senza l’aggiunta di estensioni.


20

Osserviamo la figura esemplificativa:

Figura 3.2: Diagrammi SysML Prima di entrare nel dettaglio della descrizone dei diagrammi di ogni sezione della struttura di SysML, dobbiamo distinguere due concetti fondamentali e dare, quindi, due definizioni di costrutti:

- i Costrutti Statici, ovvero quelli strutturali, usati negli structure diagrams di SysML, che servono a modellare gli aspetti statici di un sistema;

- i Costrutti Dinamici, ovvero quelli comportamentali, utilizzati nei

behavioural diagrams di SysML, utili per modellare gli aspetti dinamici di un sistema.

Possiamo adesso passare all’analisi nel dettaglio di questi diagrammi in maniera da avere un quadro generale e completo di questo Linguaggio di Modellazione.


21

3.2 Diagrammi Strutturali SysML utilizza i Diagrammi Strutturali per descrivere il sistema e tutte le sue componenti statiche. L’elemento di base dei costrutti strutturali nel linguaggio SysML è il “blocco”, Block, che riutilizza la struttura classe dalle strutture composite di UML 2.0.

<<block>> Block 1

constraints Constraints

operation Operation1(p1:Type1):Type2

parts Property1: block2

references

Property2:Block3[0..*]{ordered} values

Property3:Integer=0 {read only} Figura 3.3 : Block

Il “Blocco” è un’unità modulare che descrive la struttura di un sistema o di un elemento; esso descrive, a qualsiasi livello della gerarchia di sistema, gli elementi logici o fisici che sono oggetto di interesse; questi possono essere elementi strutturali o comportamentali, come proprietà ed operazioni, che rappresentano lo stato ed il comportamento di un sistema; un esempio possono essere le persone, i dati, l’hardware o il software. Il “Blocco” definisce una collezione di “features” che descrivono un sistema o altri elementi di interesse. I diagrammi strutturali sono quattro: Block Definition Diagram, Internal Definition Diagram, Parametric Diagram e Package Diagram.


22

3.2.1 Block Definition Diagram Il Block Definition Diagram rinomina ed estende il class diagram di UML. Questo diagramma può essere utilizzato per rappresentare molteplici aspetti di un sistema e attraverso esso si individuano elementi concettuali che delineano un concetto operativo. Questa tipologia di diagrammi definisce i blocchi, individuando oggetti di interesse e assegnando loro attributi e operazioni; descrive le relazioni esistenti fra questi blocchi, come per esempio le dipendenze, le associazioni e le generalizzazioni; in più permette di specificare la gerarchia del sistema e le sue possibli classificazioni.

Figura 3.4 : Block Definition Diagram Possibili esempi sono la rappresentazione di un’astrazione di un sistema e le sue componenti, oppure ancora è utile per specificare le interazioni tra le entità che descrivono relazioni fra i dati in un sistema.


23

I Block Definition Diagrams aggiungono una tipologia di blocchi chiamata “Constraint Block”. Questi blocchi permettono l’analisi ingegneristica integrata consentendo di mettere in relazione modelli di “performance” e “reliability” con altri modelli del linguaggio SysML. Un “Constraint Block” permette di includere i vincoli e i parametri di questi utilizzandoli in più contesti.

3.2.2 Internal Block Diagram

L’Internal Block Diagram rinomina ed estende il Composite Structure diagram di UML. Questa tipologia di diagramma descrive le strutture interne dei blocchi attraverso l’utilizzo delle proprietà e delle connessioni fra questi; si occupa, quindi, della modellazione del sistema in maniera più specifica.

Figura 3.5 : Internal Block Diagram

L’Internal Block Diagram rappresenta il sistema come una collezione di parti, che assumono uno specifico ruolo all’interno del sistema globale; esso, poi, permette di specificare le interconnessioni tra le parti e permette di modellare il sistema come un albero di elementi modulari. L’Internal Block Diagram descrive la strutturazione delle componenti in “Parti” e “Porte”. In particolare, le “porte” servono per indicare che le “parti” possono essere connesse con l’esterno e quindi inserirsi in un contesto più ampio.


24

Di seguito un esempio di “porte” e flusso di oggetti, attraverso queste, fra gli elementi:

Figura 3.6: Item Flows e Internal Block Diagram (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) Ogni “parte” può essere definita da una classe con le sue parti, porte e struttura interna, in modo che un insieme uniforme di elementi possa essere applicato su più livelli di una gerarchia di sistema; ciò permette che ogni tipo specifico di componenti, di connessioni, di combinazioni fra gli elementi, sia

volto a raggiungere l’obiettivo del particolare modello di sistema.


25

3.2.3 Parametric Diagram

Il Parametric Diagram è un nuovo diagramma introdotto da SysML che fornisce la possiblità di esprimere “vincoli” fra le proprietà e permette l’integrazione di analisi ingegneristiche come performance e affidabilità con i modelli di progettazione di SysML. Esso permette di legare alcuni blocchi a proprietà e valori di altri blocchi. Questo legame avviene proprio vincolando dei parametri ad uno specifico valore attuale di un blocco. I “vincoli parametrici” forniscono meccanismi per l’analisi ingegneristica integrata. Vediamo l’esempio:

Figura 3.7: Newton’s World (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann)

Un “vincolo parametrico” può essere utilizzato per esprimere le relazioni tra le proprietà, che sono individuate in un modello strutturale di un sistema. Essi sono utilizzati per modellare le proprietà e le loro relazioni, ed in genere sono inseriti come modelli nell’analisi del progetto per favorire il riscontro e il controllo, la performance, e l’affidabilità.


26

Questi particolari vincoli rappresentano una rete di legami tra le proprietà del sistema, e possono essere: espressioni matematiche, espressioni fisiche, etc, che mettono in relazione le proprietà di un sistema fisico.

Figura 3.8: Constraint Block (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) Altri “vincoli”, invece, possono essere utilizzati per identificare i parametri critici e le relazioni fra questi ed altri parametri. Si tratta, quindi, di modelli di analisi che definiscono un set di proprietà del sistema e le relazioni parametriche fra queste. Lo stato di una relazione parametrica può influenzare o cambiare il valore di altre proprietà. Queste relazioni possono essere costruite attraverso il riutilizzo di molte relazioni parametriche primitive, come ad esempio gli operatori matematici di base.

3.2.4 Package Diagram Il quarto ed ultimo diagramma strutturale SysML, ereditato senza cambiamenti da UML, è l’UML Package Diagram e viene utilizzato per organizzare il modello in base alle caratteristiche dei proprio elementi. Un “Packages” è quindi un contenitore di elementi del modello utilizzato per gestire sistemi strutturati.


27

3.3 Diagrammi Comportamentali

L’unità base dei costrutti comportamentali nel linguaggio SysML è “l’attività”, Activity. Le “Activities” di SysML sono un’estensione delle “Activities” di UML 2.0 e rapresentano l’unità base di un comportamento. L’attività è un insieme di azioni che spesso richiamano altre attività, ed è utilizzata in tutti i diagrammi comportamentali. Modellare le attività serve ad evidenziare gli inputs, gli outputs, le sequenze e le condizioni per il coordinamento fra questi ed altri comportamenti del sistema. I Costrutti Comportamentali contengono informazioni su Attività, Interazioni, Stati del Sistema e Casi d’Uso. I diagrammi di tipo “Behavioral” sono Quattro: Activity Diagram, Sequence Diagrams, State Machine Diagrams, Use case Diagram.

3.3.1 Activity Diagram Il primo diagramma, l’Activity Diagram, è uno dei diagrammi ereditati da UML. SysML aggiunge a questa tipologia di diagrammi alcune estensioni, come l’inclusione di mezzi per supportare ciò che è noto sotto il nome di "modellazione del flusso continuo", estensioni per le probabilità e per il controllo all’interno degli stessi diagrammi. L'Activity Diagram, ha il compito specifico di rappresentare il flusso di inputs ed outputs e il flusso di controllo fra le azioni prese in considerazione; in più questo diagramma comprende le sequenze e le condizioni utili per il coordinamento delle azioni. L’Activity Diagram può essere utilizzato per la modellazione di una grande varietà di situazioni; ha un ampio raggio di applicazione, dalla rappresentazione di business process ad alto livello, alla descrizione dettagliata di attività multi-tasking.


28

Un diagramma di questa tipologia permette di mostrare normalmente le sequenze di azioni suddivise in percorsi definiti, dove ogni percorso può essere utilizzato per rappresentare una specifica entità, come un sottosistema, un flusso di controllo specifico, oppure un gruppo organizzativo.

Figura 3.9 : Activity Diagram L'Activity Diagram viene utilizzato per documentare i processi esistenti, per l’analisi concettuale di nuovi processi, per effettuare operazioni di re-engineering delle possibilità. Esso è molto utilizzato anche per mostrare il comportamento in parallelo tra i vari eventi e le attività; infatti permette di visualizzare molte interazioni “use-cases”.

3.3.2 Sequence Diagram Il Sequence Diagram è incluso negli Interactions Diagrams di SysML, insieme al Timing Diagram, ed entrambi vengono ereditati da UML 2.0 senza particolari cambiamenti, se non relativi a miglioramenti nelle notazioni nel Timing Diagrams. Il Sequence Diagram specifica una serie di interazioni in termini di flusso di controllo definito attraverso lo scambio di messaggi; questi messaggi combinano controllo e flusso di dati fra le “lifelines”.


29

Un esempio pratico:

Figura 3.10: Sequence Diagram (fonte: Systems Engineering with SysML/UML, Feb 2008, Kaufmann) La ricezione dei messaggi consente il passaggio di inputs e il loro ordine temporale è associato alla posizione verticale di questi nel diagramma. I messaggi permettono l'inclusione di attività come i metodi di operazioni al suo interno. Possono essere utilizzate condizioni logiche per rappresentare alternative, flussi sequenziali e loops. Esistono, poi, delle “porte” che vengono considerate come punti per l’interazione con lifelines esterne.

3.3.3 State Machine Diagram Lo State Machine Diagram è inserito nello State Mode Package. Questo definisce un set di concetti che possono essere utilizzati per modellare comportamenti discreti, attraverso un numero finito di stati, "state-transition". Questo diagramma rappresenta comportamenti come la cronologia dello stato di un oggetto, riguardo le sue transizioni e i suoi stati.


30

Esempio didattico:

Figura 3.11: State Machine Diagram Esso include attività che sono richiamate durante le transizioni fra stati, riguardo l'ingresso o l'uscita da uno stato, o finchè si trova in uno stato. Le attività richieste durante le transizioni di ingresso e uscita da uno stato, sono specificate insieme agli eventi e alle condizioni di protezione associati.

3.3.4 Use Case Diagram

Lo Use Case Diagram, ereditato da UML 2.0, descrive il soggetto del sistema e il suo l’utilizzo. Il sistema agisce tramite attori che interagiscono con esso per raggiungere l'obiettivo. E’ un servizio fornito dal sistema agli attori. Questo diagramma può anche essere visto come la funzionalità e/o la capacità che si realizza attraverso l’interazione fra il soggetto ed i suoi attori. I diagrammi Use Case includono i casi d’uso, gli attori e le comunicazioni tra loro. In particolare gli attori rappresentano ruoli classificati, che sono esterni al sistema e che possono corrispondere a utenti, a sistemi, o ad altre entità. Possono interagire in modo diretto o indiretto con il sistema.


31

Figura 3.12: Use Case Diagram

In genere gli attori sono specializzati nel rappresentare la tassonomia di una tipologia di utente o di sistema esterno. L’associazione tra gli attori e i casi d’uso rappresenta le comunicazioni che si verificano tra attori e soggetti, per compiere la funzionalità particolari associate a quel caso d’uso.

3.4 Diagrammi Generici SysML ha introdotto dei mezzi per rappresentare i requisiti di progetto sotto forma di testo, in particolare attraverso un identificatore unico e delle proprietà testuali; ha introdotto, soprattutto, la possibilità di collegare questi requisiti agli altri elementi del modello.

3.4.1 Requirement Diagram Il Requirements Diagram può avere differenti formati, quali quello grafico, tabulare oppure come struttura ad albero. In generale i requisiti possono anche essere parte di altri diagrammi, in maniera da evidenziare relazioni con altri costrutti del modello; quindi i costrutti di SysML per i requisiti hanno lo scopo di integrare meglio i requisiti di sistema con altre parti del modello.


32

Figura 3.13: Requirement Diagram La specifica SysML fornisce diverse relazioni tra i requisiti, quali:

- le gerarchie dei requisiti;

- le dipendenze tra i requisiti sorgente-derivato;

- il soddisfacimento delle relazioni fra requisiti e modello;

- la verifica delle dipendenze per il test-cases.

Un requisito deve essere obbligatoriamente soddisfatto dal sistema che si sta progettando; un requisito può specificare una particolare funzione che un sistema deve svolgere oppure una particolare condizione che il sistema deve soddisfare. SysML utilizza un construtto di modellazione per rappresentare i requisiti e fare in modo che questi interagiscano con altri elementi del modello. E’ utile osservare che un requisito può essere composto di sotto requisiti e più requisiti possono essere organizzati come un albero composto. Abbiamo già specificato che i requisiti possono interagire fra di loro, ma è ancora più importante sottolineare che possono relazionarsi agli elementi dell’analisi, della progettazione, dell’attuazione e del testing. Un requisito può definire le sue proprietà fornendo così un valore stimabile da accompagnare alla descrizione testuale dello stesso. Alle proprietà dei requisiti possono essere assegnati valori iniziali che vengono poi ereditati dai requisiti specializzati. Uno strumento fondamentale è la relazione di derivazione, “derive”, che permette di generare o dedurre un requisito da un altro requisito. Un’altra relazione è quella di soddisfacimento, “satisfy”, la quale permette che un requisito venga soddisfatto da un altro elemento del modello. Un’altra relazione è quella di verifica, “verify”, che permette di verificare tramite il test-case che i requisiti siano soddisfatti. Tutte queste relazioni sono specializzazioni delle relazioni “trace” di UML, le quali sono utilizzate per tracciare i requisiti e i relativi cambiamenti attraverso i modelli.


33

La tassonomia dei requisiti può essere modificata a proprio piacimento grazie alla definizione di sottotipi addizionali dello stereotipo requisiti di SysML. Di seguito un esempio didattico di tabella dei requisiti : Tabella 3.14: Requirement Table


34

CAPITOLO 4 Esempio Modellazione Sistema: INFOMOBILITA’

4.1 DOCUMENTAZIONE Il documento che è stato redatto di seguito ha lo scopo di illustrare gli ambiti di utilizzo di SysML, linguaggio di modellazione grafico dei sistemi, che supporta le specifiche, l’analisi e la progettazione di questi. I Diagrammi selezionati, in questo contesto di sistema, fra tutti quelli che SysML mette a disposizione, sono utilizzati per rappresentare acluni aspetti peculiari del modello che si rappresenterà di seguito, al fine di esprimerne il funzionamento e le interazioni. Nell’ambito del System Engineering l’ordine di utilizzo dei diagrammi varia da processo a processo; quella di seguito è la metodologia che si è ritenuta opportuna per lo sviluppo del progetto di “INFOMOBILITA’ ”. Una sezione è dedicata alla descrizione degli ambiti di utilizzo del sistema , l’aspetto strutturale di questo, i “Block Definition Diagram” e il “Package Diagram” di alto livello. Un’altra parte mostra come SysML può essere utilizzato per l’analisi dell’aspetto comportamentale del sistema ad alto livello, mediante i “Sequence Diagram”, lo “State Machine Diagrams”, “Activity Diagram” e “Use Case Diagram”.


35

4.1.1 Descrizione del progetto “INFOMOBILITA’ ” è il progetto di un sistema per il controllo distribuito di un’azienda di trasporti su gomma e su rotaia. Il sistema è composto di un’unita centrale di raccolta dati situata nella sede centrale dell’azienda, che comunica con tutti i dispositivi associati ad esso; I dispositivi si trovano:

- nelle strutture, sotto forma di lettori di scheda, Badge Card Reader; - sugli automezzi, sotto forma di Computer di Bordo; - alle fermate, sotto forma di Palina Informativa.

I controlli che l’azienda vuole effettuare sono sul proprio personale, sulle proprie strutture, infrastrutture e servizi, sui propri mezzi e in ultimo dei propri utenti. Il fine del controllo è quello della raccolta dati per:

- migliorare i servizi offerti all’utente; - migliorare la gestione del personale.

4.1.2 Obiettivi del sistema “INFOMOBILITA’ ”, attraverso una serie di meccanismi di gestione computerizzata, si propone di gestire, organizzare, controllare e raccogliere informazioni riguardo : - il personale: Autisti e Controllori che identifichiamo con il nome di

Personale Attivo; Amministrativi, Dirigenti, Funzionari che identifichiamo con il nome di Personale Amministrativo.

- gli automezzi: Autobus, Filobus, Tram, Auto; - le strutture: Direzione Centrale, Depositi, Autofficine, Stazionamenti,

Parcheggi, Paline informative, Linee ordinarie Urbane ed Extraurbane, Linee occasionali;

- gli utenti.


36

4.1.3 Contesto del Progetto Il meccanismo che viene descritto nel particolare è quello relativo al Progetto di Controllo del personale addetto al trasporto , il Personale Attivo, quindi Autisti e Controllori. Autisti e Controllori sono muniti di una Badge Card personale, quindi non cedibile o prestabile, e di un proprio Codice associato, PIN. Gli Automezzi possiedono un Computer di Bordo, un dispositivo dotato di un tastierino e di un display che ha molteplici funzioni, tra le quali quella di inserimento e lettura della Card e digitazione del PIN. Il Computer di Bordo è collegato al Sistema di INFOMOBILITA’ centrale e tiene traccia degli spostamenti dell’automezzo, conoscendone costantemente la posizione rispetto all’effettivo percorso e il suo stato di manutenzione; esso permette la comunicazione immediata con l’Autista e la possibilità di inviare comunicazioni agli utenti nell’Automezzo. La Card serve a gestire gli ingressi e le uscite relativamente al turno di lavoro associato al dipendente ed è utilizzata per l’accesso autorizzato/ristretto alle aree delle strutture di lavoro. Essa permette di verificare la presenza del Personale Attivo sull’automezzo in tempo reale, poiché ogni Autista e Controllore dovranno inserirla nel momento in cui si trovano sull’automezzo. La Card, è utilizzata:

- da tutto il Personale, per l’accesso alla struttura di lavoro;

- dall’Autista, per registrare l’accesso all’automezzo che gli è stato associato per il turno di lavoro, sia in deposito che in stazionamento, se il turno comincia fuori dal deposito di appartenenza;

- dal Controllore, per registrare la propria presenza sul mezzo nei tratti di sua

competenza. La Card e il Computer di Bordo sono utilizzate dal Sistema di INFOMOBILITA’, che tiene traccia dei ritardi, assenze e permessi del personale; in più tiene traccia dell’orario effettivo di partenza e di arrivo dell’automezzo e dell’orario effettivo di passaggio ad ogni fermata del particolare percorso. Sull’Automezzo, oltre al Computer di Bordo, è presente l’Obliteratrice, che attraverso il sistema raccoglie dati sull’utilizzo del biglietto e dell’abbonamento, che l’utente finale deve possedere quando usufruisce dei servizi messi a disposizione dall’Azienda.


37

Ogni fermata e stazionamento sono dotati di Palina Informativa. La Palina Informativa ha come funzione principale quella di mostrare a display il nome della fermata, mostrare i vari automezzi, con orari e nomi, che transitano per quella specifica fermata, in più mostra altre informazioni utili agli utenti del servizio (cambio di tratta, sciopero, soppressione corsa, orari generici festivi, feriali e occasionali). Questo dispositivo permette all’utente di scegliere la destinazione e altre opzioni (particolare percorso, pullman, etc.). In base alla fermata in cui si trova la Palina Informativa, viene calcolato il minor tempo per raggiungere la destinazione ed eventuali possibili ritardi, in base alla viabilità in quel preciso orario. La Palina Informativa è un dispositivo interattivo, che ha tra le sue funzionalità anche la possibilità di connessione e sincronizzazione con l’Automezzo, all’atto del passaggio di questo ad una fermata, mediante dispositivi radio. I dati raccolti dalla Palina Informativa in relazione ai dati del Computer di Bordo, permettono di calcolare tramite il Sistema di INFOMOBILITA’ i ritardi e gli anticipi di orario. In più attraverso la Palina Informativa è possibile inviare comunicazioni e informazioni alle fermate, in tempo reale, utili all’utente. Anche il Computer di Bordo permette di visualizzare gli stessi dati sul display in modo che anche l’Autista sia a conoscenza degli orari effettivi e dei ritardi accumulati. Uno sviluppo futuro del progetto si sta evolvendo verso un’applicazione interattiva tramite cellulare, per l’invio di informazioni utili riguardo ai percorsi di interesse e alle stesse informazioni visualizzate sul display della Palina Informativa o tramite internet direttamente sul cellulare.

4.1.4 Identificazione Stakeholders Con il termine Stakeholders vengono identificati coloro che sono interessati al sistema e/o all’utilizzo di questo. L’Azienda di Trasporto ha interesse nel conoscere una serie di informazioni che sono utili come feedback dei propri servizi. Alcuni componenti dell’azienda, come Amministratori, Funzionari e Dirigenti, il Personale Amministrativo, hanno interesse a conoscere l’andamento del servizio per poter :

- lavorare sul perfezionamento e sulla formazione del personale attivo;

- controllare l’effettivo svolgimento delle mansioni del personale attivo;


38

- raccogliere dati percorrenze, orari effettivi, ritardi, anticipi; - controllare il funzionamento delle linee, dei percorsi e delle tratte;

- raccogliere dati per elaborazioni statistiche;

- tenere traccia degli automezzi;

- controllare gli accessi alle aree riservate. Il Personale Attivo, quale Autisti e Controllori, ha interesse a controllare o richiedere informazioni attraverso il sistema riguardo:

- il proprio turno di lavoro;

- le ore di servizio effettuate nel mese corrente;

- i permessi, le assenze, i ritardi nel mese corrente;

- la possibilità di richiedere assistenza; Gli Utenti del servizio hanno bisogno di avere informazioni riguardo:

- orari, percorsi;

- tempi di percorrenza.

Figura 4.1 Stakeholders Table Gli Stakeholders principali sono gli Amministrativi dell’azienda, che sono anche i richiedenti e i responsabili dell’andamento del “ Sistema di INFOMOBILITA’ ”; mentre, il resto del personale, ha un ruolo di interazione con il Sistema nel momento in cui è ultimato e deve essere testato.


39

Il Personale Attivo (Autisti e Controllori) è quello che restituisce un feedback utile per il miglioramento dell’efficacia e dell’efficienza ed il rinnovamento del Sistema. I richiedenti sono stati interrogati in maniera da fornire un quadro generale del contesto e delle basi fondamentali del progetto. Sono stati effettuati incontri “brainstorming” per il confronto tra le diverse visoni degli interessati. L’utente finale interagisce con il Sistema, tramite internet o mediante la Palina Informativa. L’utente finale del servizio è stato reso parte integrante dello sviluppo del progetto, attraverso l’individuazione di fasce di interesse a campione, per lo più studenti e lavoratori; a queste fasce di interesse sono stati somministrati nel tempo questionari di Customer Satisfaction, per ottenere un riscontro e per apportare miglioramenti al servizio. Il sistema tiene conto, attraverso le Obliteratrici, dei dati sui biglietti e sul numero di abbonamenti utilizzati per le singole tratte.

4.1.5 Identificazione dei Requisiti Individuati gli Stakeholders si definiscono in base ad essi i Requisiti del sistema. I requisiti determinano cosa offre un sistema e sono le basi dello sviluppo del progetto. Essi vengono determinati attraverso un’attenta analisi delle richieste degli interessati, vengono documentati e messi in un’apposita struttura. La raccolta dei requisiti è stata il frutto di una lunga ricerca che ha interessato il coinvolgimento, diretto ed indiretto, di tutti gli Stakeholders. Osserviamo la figura relative alla specifica dei requisiti:

Figura 4.2 Requirements Diagram: INFOMOBILITA’ Specification


40

I Requisiti funzionali indicano tipicamente funzionalità e proprietà, delle quali si deve dotare il Sistema. I Requisiti Funzionali sono relativi a:

- identificazione personale;

- abilitazione automezzo;

- inserimento turni;

- visualizzazione orari/percorrenze.

Osserviamo la relativa tabella: Tabella 4.3 Tabella dei requisiti Funzionali

I Requisiti Non-Funzionali indicano invece delle proprietà “desiderate”, che devono essere soddisfatte dal sistema e che in un certo modo e in una certa percentuale influsicono sui requisit funzionali. I Requisiti Non-Funzionali sono relativi a:

- sistema sempre attivo;

- semplicità di utilizzo.


41

Osserviamo la relativa tabella: Tabella 4.4 Tabella dei requisiti Non-Funzionali

Osservando i Requisiti se ne possono dedurre ulteriori, che vengono chiamati Requisiti derivati, ed inseriti in un apposito diagramma, osserviamo la figura:

Figura 4.5 Requirements Derivation INFOMOBILITA’


42

4.1.6 Package Diagram Il Package Diagram mostra la struttura del modello usato per analizzare il problema. Questo Package contiene gli elementi del modello, le relazioni fra essi e le relazioni con altri Packages.

Figura 4.6 Package Diagram INFOMOBILITA’

4.1.7 Parametric Diagram Il “Parametric Diagram”, nuovo diagramma introdotto da SysML, permette l’integrazione di analisi ingegneristiche e la possibilità di vincolare alcuni blocchi fra loro in base a leggi matematiche o fisiche. In particolare, è stato sviluppato un semplice esempio di calcolo dell’orario di passaggio di un automezzo ad una generica fermata.

Figura 4.7 Parametric Diagram INFOMOBILITA’


43

4.1.8 Use Case Diagram Lo “Use Case Diagram” descrive i soggetti e l’utilizzo del Sistema “INFOMOBILITA’ ”. Gli Attori sono:

- il Personale Attivo, che comprende Controllori ed Autisti; - il Personale Amministrativo, che comprende Impiegati, Funzionari e

Dirigenti; - l’Utente del servizio.

Osserviamo la figura di seguito:

Figura 4.8 Use Case Diagram INFOMOBILITA’: Sistema * Se il turno inizia dal deposito, la presenza viene registrata tramite il Badge Reader; altrimenti se comincia in stazionamento o ad una qualisasi fermata, il Computer di Bordo registra la presenza direttamente sull’automezzo. ** Il sistema raccoglie ed organizza, mentre gli Amministrativi elaborano i dati per un preciso scopo.


44

4.1.9 Activity Diagram

L’ “Activity Diagram” in questo contesto dell’ “INFOMOBILITA’ ” è stato utilizzato per generalizzare e descrivere l’operazione di registrazione con Badge Card, tramite Badge Reader o Computer di Bordo, da parte del Personale. Osserviamo la figura di seguito:

Figura 4.9 Activity Diagram: Verfica Badge Card INFOMOBILITA’


45

4.1.10 Sequence Diagram I “Sequence Diagram” per il Sistema di “INFOMOBILITA’ ” sono relativi alle due specifice interazioni di registrazione presenza in deposito, tramite Badge Reader e sull’automezzo, tramite Computer di Bordo:

Figura 4.10 Sequence Diagram INFOMOBILITA’: Badge Reader Deposito verifica presenza personale


46

Figura 4.11 Sequence Diagram INFOMOBILITA’: Computer di Bordo verifica presenza Autista

Figura 4.12 Sequence Diagram INFOMOBILITA’: Computer di Bordo verifica presenza Controllore

Inserire il titolo della tesi di laurea come intestazione

47

Bibliografia [1] Systems Engineering with SysML/UML, Feb 2008, Morgan Kaufmann [2] “http://www.omgsysml.org” [3] SysML Designer (Eclipse 2013) [4] Papyrus (Eclipse 2013)

Linguaggio di Modellazione SysML FRANCIA N46000294 · Anno Accademico 2013/2014 Candidato: FRANCIA...

Documents

Transcript of Linguaggio di Modellazione SysML FRANCIA N46000294 · Anno Accademico 2013/2014 Candidato: FRANCIA...