Elaborato francia francesco N46000294

Transcript

Linguaggio di Modellazione SysML
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Ingegneria del Software
Anno Accademico 2013/2014
Candidato:
FRANCIA FRANCESCO
matr. N46/000294
I
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
3.2.2
3.2.3
3.2.4
Block Definition Diagram................................................................................ 22
Internal Block Diagram................................................................................... 23
Parametric Diagram........................................................................................ 25
Package Diagram............................................................................................ 26
II
Indice
3.3
Diagrammi Comportamentali.............................................................................. 27
3.3.1
3.3.2
3.3.3
3.3.4
3.4
Activity Diagram.............................................................................................. 27
Sequence Diagram........................................................................................... 28
State Machine Diagram................................................................................... 29
Use Case Diagram........................................................................................... 30
Diagrammi Generici.............................................................................................. 31
3.4.1 Requirements Diagram.................................................................................... 31
CAPITOLO 4.
4.1
Modellazione sistema : INFOMOBILITA’......................... 34
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
III
Indice delle Figure
Figura 1.2: Ambiti del System Engineering
Figura 2.1: Struttura dei livelli UML (fonte: Systems Engineering with SysML/UML,
Feb 2008, Morgan Kaufmann)
Figura 2.2: UML 2.0 e SysML (fonte: http://www.omgsysml.org)
Figura 2.3: Diagrammi SysML (fonte: http://www.omgsysml.org)
Figura 3.1: Struttura dei livelli SysML (fonte: Systems Engineering with SysML/UML,
Feb 2008, Morgan Kaufmann)
Figura 3.2: Diagrammi SysML
Figura 3.3 : Block
Figura 3.4 : Block Definition Diagram
Figura 3.5 : Internal Block Diagram
Figura 3.6: Item Flows e Internal Block Diagram (fonte: Systems Engineering
with SysML/UML, Feb 2008, Kaufmann)
Figura 3.7: Newton’s World (fonte: Systems Engineering with SysML/UML,
Feb 2008, Kaufmann)
Figura 3.8: Constraint Block (fonte: Systems Engineering with SysML/UML,
Feb 2008, Kaufmann)
Figura 3.9: Activity Diagram
Figura 3.10: Sequence Diagram (fonte: Systems Engineering with SysML/UML,
Feb 2008, Kaufmann)
Figura 3.11: State Machine Diagram
Figura 3.12: Use Case Diagram
Figura 3.13: Requirement Diagram
Figura 4.1: Stakeholders table INFOMOBILITA’
Figura 4.2: Requirements Diagram INFOMOBILITA’
Figura 4.5: Requirements Derivation INFOMOBILITA’
Figura 4.6: Package Diagram INFOMOBILITA’
Figura 4.7: Parametric Diagram INFOMOBILITA’
Figura 4.8: Use Case Diagram INFOMOBILITA’
Figura 4.9: Activity Diagram INFOMOBILITA’ Verifica Badge
Figura 4.10: Sequence Diagram INFOMOBILITA’ Badge Reader Deposito
Figura 4.11: Sequence Diagram INFOMOBILITA’ Computer di Bordo Autista
Figura 4.12: Sequence Diagram INFOMOBILITA’ Computer di Bordo Controllore
8
12
14
15
19
20
21
22
23
24
25
26
28
29
30
31
32
38
39
41
42
42
43
44
45
46
46
Indice delle Tabelle
Tabella 1.1: Contesto System Engineering
Tabella 3.14: Requirement Table
Tabella 4.3: Tabella dei requisiti funzionali INFOMOBILITA’
Tabella 4.4: Tabella dei requisiti non-funzionali
7
33
40
41
IV
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.
5
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.
6
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-disistema, 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
CIVIL
ENGINEERING
……………
MATERIAL
ENGINEERING
MECHANICAL
ENGINEERING
ELECTRICAL
ENGINEERING
SYSTEM ENGINEERING
SOFTWARE
ENGINEERING
1.2
Con la definizione System Engineering si individuano le relazioni, le
7
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
8
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.
9
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
10
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.
11
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).
12
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.
13
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.
14
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.
15
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.
16
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)
17
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
18
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.
19
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.
20
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.
21
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.
22
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.
23
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.
24
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à.
25
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.
26
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.
27
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 reengineering 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 “usecases”.
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”.
28
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.
29
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.
30
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.
31
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.
32
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
33
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”.
34
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.
35
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.
36
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;
37
- 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.
38
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
39
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.
40
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’
41
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’
42
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.
43
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’
44
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
45
Figura 4.11 Sequence Diagram INFOMOBILITA’: Computer di Bordo verifica presenza
Autista
Figura 4.12 Sequence Diagram INFOMOBILITA’: Computer di Bordo verifica presenza
Controllore
46
Inserire il titolo della tesi di laurea come intestazione
Bibliografia
[1]
[2]
[3]
[4]
Systems Engineering with SysML/UML, Feb 2008, Morgan Kaufmann
“http://www.omgsysml.org”
SysML Designer (Eclipse 2013)
Papyrus (Eclipse 2013)
47

Elaborato francia francesco N46000294

Transcript

Documenti analoghi

sistemi informativi aziendali

ITIS Franchetti - Franchetti Salviani

Complementi di Ingegneria del Software

Circolare N. 80: Iscrizioni al corso di Modellazione 3D (3DS

UNIVERSIT`A “LA SAPIENZA” DI ROMA 1 Destinatari 2 Prerequisiti

clicca qui - Accademia Santa Giulia

3D Studio Max

Elementi di modellazione e animazione 3d - Forma-re-te