Un approccio model-driven per lo sviluppo di simulazioni distribuite in ambito Systems Engineering

1 Introduzione 
 
1 
 
Introduzione 
 
 
L’ingegneria dei sistemi (Systems Engineering) definisce una serie di approcci per lo sviluppo di 
sistemi complessi attraverso la definizione di un processo che va dalla gestione dei requisiti fino al 
rilascio del sistema. Questo raccoglie tutti gli aspetti riguardanti le discipline ingegneristiche coinvolte 
nello sviluppo garantendo un alto grado di interazione.    
In ogni fase dello sviluppo di un sistema è possibile eseguire una serie di simulazioni per prevedere il 
comportamento di un sistema evidenziando eventuali problematiche che possono presentarsi sul 
prodotto una volta rilasciato. 
La simulazione distribuita definisce l’interazione tra più unità di elaborazione interconnesse tramite 
una rete di comunicazione ed è utile per definire il comportamento di un sistema interdisciplinare in 
fase di sviluppo.  
Obiettivo di questo lavoro è definire un approccio model-driven in ambito Systems Engineering 
basato sullo standard HLA (High Level Architecture) di simulazione distribuita. 
All’inizio sono introdotti i principi base della modellazione di sistema basata su modello MBSE 
(Model Based Systems Engineering) e il linguaggio per la modellazione di sistemi di sistemi UPDM 
(Universal Profile for DoDAF and MODAF).  
In seguito sono presentate le principali caratteristiche dello standard di modellazione SysML (System 
Modeling Language) ed è fornita una visuale generale dei principi MDA (Model Driven Architecture) 
descrivendo il linguaggio per le trasformazioni “model to model” (M2M)  QVT (Query View 
Transformation) e quello per le trasformazioni “model to text” (M2T) MOF2Text. 
Nel capitolo 3 è introdotto il tool per lo sviluppo nell’ambito dell’ingegneria dei sistemi Artisan Studio 
prendendo come riferimento le trasformazioni “model to model” (M2M).     
Nel capitolo 4 è introdotta l’architettura per la simulazione distribuita HLA (High Level Architecture) 
con la descrizione dei principi base per la definizione di una federazione (simulazione) e dei federati (i 
partecipanti).  
Nel capitolo 5 è definito un profilo per HLA che estende il metamodello UML (Unified Modeling 
Language) e racchiude le principali caratteristiche dell’architettura di simulazione distribuita 
fornendo gli elementi base per modellare la simulazione di un sistema complesso.  
Attraverso i principi definiti da MDA e QVT Operational Mappings sono elaborate le regole di 
mapping da modello SysML a modello UML con profilo HLA (capitolo 6).  
In seguito si esamina un caso di studio reale modellato con SysML su cui è applicata la trasformazione 
“model to model” (M2M) precedentemente definita. 
Viene poi considerata la soluzione per la specifica delle trasformazioni M2M (model to model) 
implementata nel tool per lo sviluppo di sistemi Artisan Studio. Questa soluzione proprietaria 
presenta un proprio linguaggio per definire trasformazioni M2M, denominato sdl (Specification and 
Description Language), con relativa notazione grafica basata su diagramma delle classi UML, e 
presenta delle analogie con QVT OM (Operational Mappings). Anche qui è considerato il caso di 
studio SysML applicato alla trasformazione definita con QVT Operational Mappings. 
Viene poi definito un confronto tra le due soluzioni per implementare una trasformazione “model to 
model” evidenziando le principali analogie nell’esprimere regole di mapping, basando la 
comparazione relativamente alle principali caratteristiche dei linguaggi per la definizione di 
trasformazioni M2M: definizione clausole, potere espressivo, ordine di esecuzione, principali 
costrutti, cardinalità di input/output, direzionalità e semplicità di utilizzo.
2 Introduzione 
 
2 
 
Il modello ottenuto subisce una fase di raffinamento con aggiunta di caratteristiche utili a fornire una 
visuale completa per la successiva generazione codice. Perciò si definisce una trasformazione “model 
to text” (M2T) che genera il codice di una simulazione distribuita per la piattaforma Portico 
(implementazione HLA RTI). 
Passo successivo è la generazione del codice per il modello in precedenza definito (caso di studio) e 
successivo raffinamento per l’esecuzione. 
Il codice ottenuto richiede un effort minimo per l’esecuzione di una simulazione distribuita poiché è 
necessario definire soltanto il flusso di esecuzione dei comportamenti forniti da ogni federato.
3 MBSE (Model Based Systems Engineering) 
 
3 
 
 
1 MBSE (Model Based Systems Engineering) 
 
L’ingegneria dei sistemi (Systems Engineering) definisce un approccio interdisciplinare per la 
progettazione e gestione di progetti complessi costituiti da una serie di sottosistemi e componenti 
correlati che coinvolgono: software, hardware, dati e risorse umane. 
Come supporto per lo sviluppo viene  definito un processo in cui un sistema è visto come un tutt’uno 
rispetto ai vari tipi di discipline  ingegneristiche che possono essere applicate.  
Un processo di ingegneria dei sistemi  viene  suddiviso in due parti:  
 la gestione (management)  per organizzare l’effort con valutazione dei costi, schedulazione 
attività e valutazione delle prestazioni; 
 la parte tecnica (technical process) in cui vengono creati modelli per la specifica, la 
progettazione e la verifica. 
Nel processo ogni fase dello sviluppo è supportata da un modello che rappresenta il sistema, come 
viene definito nella MBSE (Model Based Systems Engineering) attraverso un processo di sviluppo 
model based (model driven) a supporto dell’ingegneria dei sistemi.  
Questo approccio consente l’integrazione di più domini nel ciclo di vita di un progetto e la gestione 
della complessità  producendo un miglioramento della qualità del prodotto finale e la riduzione dei 
rischi. 
Per quanto riguarda la complessità, la comunicazione svolge un ruolo fondamentale per una migliore 
gestione cercando prima di unificare i punti di vista degli stakeholder (coloro che vengono influenzati 
dal sistema) e successivamente andare a delinearli tramite una serie di viste. 
Altro aspetto fondamentale nell’ingegneria model based riguarda la consistenza che viene garantita 
dall’utilizzo di un repository comune contenente tutti i modelli di sistema.   
I principali standard in ambito MBSE per la modellazione sono: 
 UPDM (Universal Profile for DoDAF and MODAF) per la modellazione di architetture 
enterprise (EA-Enterprise Architecture) e di sistema (SA-System Architecture); 
 SysML (System Modeling Language) fornisce una visuale generale di tutti gli aspetti di un 
sistema complesso che include più discipline. 
Dal punto di vista delle discipline di processo si identificano le seguenti: 
 Specifica e Progettazione del sistema (S & P, System Specification and Design); 
 Progettazione, implementazione e testing dei componenti (C,I & T, Component Design, 
Implementation, and Test); 
 Integrazione e testing del sistema (I & T, System Integration and Test).
4 MBSE (Model Based Systems Engineering) 
 
4 
 
 
    Stakeholder needs System 
 
 
 
 
 
 
            feedback  
        
 
 
L’esecuzione del processo è accompagnata da un feedback completo che viene eseguito alla fine di 
ogni disciplina e alla conclusione dell’intero processo rispecchiando la verifica e convalida di sistema 
(V&V) come in un processo di ingegneria del software. 
Il principale ente internazionale per la gestione delle pratiche di sviluppo e educative riguardo 
all’ingegneria dei sistemi è INCOSE (International Council of Systems Engineering). 
1.1 UPDM (Universal Profile for DoDAF and  MODAF) 
 
UPDM nasce con lo scopo da parte dell’OMG (Object Management Group) di definire una specifica 
che raccolga sotto un unico standard i framework architetturali definiti dal dipartimento della difesa 
statunitense DoDAF (Department of Defense Archichetural Framework) e dal ministero della difesa 
del Regno Unito (UK) MODAF (Minister of Defence Archichetural Framework).  
Un framework architetturale è utilizzato per la gestione di progetti interdisciplinari e di grandi 
eventi, in ambito organizzativo e civile, per cui è necessario un alto grado di coordinazione tra le 
parti coinvolte. 
Questo framework è definito a partire dalle specifiche MDA (Model Driven Architecture) e prende 
come supporto per la definizione del proprio  metamodello (Domain MetaModel)  alcuni linguaggi 
definiti in ambito model driven come: 
 
 UML (Unified Modeling Language), usato per la modellazione software nelle varie fasi 
definite nel processo di sviluppo di un prodotto software; 
 SysML (System Modeling Language), linguaggio di modellazione a livello di ingegneria dei 
sistemi, usato per la modellazione di un sistema che comprende le varie discipline 
ingegneristiche dalle specifiche hardware fino alla progettazione a livello software (tramite 
UML). 
 
Inoltre il metamodello usa altre specifiche per definire gli elementi per la modellazione che possono 
essere usati in fase di progettazione di un sistema. 
In generale UPDM definisce un framework architetturale (AF) per la definizione ad alto livello di un 
sistema di sistema, dove con questo termine s’intende un insieme di sistemi complessi (racchiudono 
più aspetti) che risultano correlati tra loro e interdipendenti. Qui si raccolgono tutti gli aspetti per 
una migliore gestione progettuale.  
S & P 
C,I & T  
I & T
5 MBSE (Model Based Systems Engineering) 
 
5 
 
Il comportamento di questo tipo di sistemi può emergere in fase di sviluppo, dove determinati 
aspetti conducono a una o più discipline comportando a volte l’emergere di una serie di conflitti 
interdisciplinari. Questo processo vuole essere gestito attraverso il framework racchiudendo i vari 
aspetti di un sistema complesso (più sistemi correlati) che possono riguardare risorse umane, la 
modellazione di componenti  hardware e il software. 
Il framework definisce una serie di viste del sistema che raccolgono i punti di vista di ogni 
stakeholder coinvolto nel processo, riguardanti: vista generale (All Views, AV), vista operazionale 
(Operational View, OV), vista strategica (Strategic View, StrV), vista di sistema (System View, SV), 
vista a supporto degli standard tecnici (Technical Standard View, TV), vista di acquisizione 
(Acquisition View, AcV) e vista orientata ai servizi (Service Oriented View, SoV). 
Tra le varie viste è possibile creare una serie di riferimenti per mantenere la tracciabilità del sistema 
che si sta sviluppando a supporto di una migliore gestione e pianificazione. Ciò aiuta nella fase 
successiva della modellazione di un sistema tramite SysML verso cui è possibile definire la 
tracciabilità del modello. 
Le viste e gli elementi di modellazione sono raggruppati in una serie di package e per quanto 
riguarda la definizione di un mapping tra gli elementi definiti nel metamodello DoDAF e quello 
MODAF viene definito un Core package per gli elementi in comune e due package specifici per quelli 
che non è stato possibile racchiudere nel Core package. 
Il DMM (Domain MetaModel) è definito a partire da un insieme di linguaggi di modeling che 
prendono come  riferimento UML, ciò consente di definire UPDM come un profilo dove vengono 
definiti una serie di stereotipi, tagged values e vincoli (constraints) che aggiungono ulteriori aspetti 
per fornire un maggiore livello di dettaglio a un elemento di modellazione. 
 
1.1.1 DoDAF (Department of Defense Architecture Framework) 
 
Framework architetturale progettato dal Dipartimento della difesa USA (Stati Uniti d'America) è visto 
come modello di riferimento per lo sviluppo di architetture enerprise (EA-Enterprise Architecture) e 
architetture di sistema (SA-System Architecture). Definisce lo scopo e la complessità dello sviluppo 
architetturale in cui vengono definiti una serie di componenti (business entity) con relative relazioni 
che vanno a delineare la struttura di un sistema. 
In principio è stato applicato in ambito militare per pianificare strategie di difesa, ma in seguito anche 
in quello civile. Per catturare i vari aspetti di un sistema è suddiviso in più viste complementari e 
consistenti tra loro: AV (All Views), SV (System Views), OV (Operational Views) e TV (Technical 
Standard Views). 
  
1.1.2 MODAF (Ministry of Defence Architecture Framework) 
 
Framework architetturale sviluppato dal Ministero della difesa UK (United Kingdom) prendendo 
come riferimento DoDAF rispetto al quale fornisce delle nuove viste di sistema (template): SoV 
(Service Oriented View), StV (Strategic View) e AcV (Acquisiton View). Fornisce un processo standard 
per la specifica di un’architettura enterprise (EA) in cui vengono catturate informazioni riguardo ai 
processi di business coinvolti e le risorse strategiche.
6 MBSE (Model Based Systems Engineering) 
 
6 
 
Come DoDAF è nato come supporto in ambito della difesa poi utilizzato come supporto 
nell’ingegneria dei sistemi focalizzandosi su NEC (Network Enabled Capabiltiy). 
Infine viene definito un metamodello (approccio model driven) denominato M3 (MOD Architecture 
Framework (MODAF) Meta Model) che definisce la struttura architetturale usata a livello di modello 
per rappresentare le viste (view)[1].   
1.1.3 Domain Meta Model (DMM) 
 
Nell’ambito della model driven engineering (MDE) e nello specifico di MDA è fornito un metamodello 
come modello di riferimento per definire un’istanza in fase di progettazione, in cui ogni elemento del 
modello è associato con un elemento del corrispettivo metamodello. Allo stesso modo si definiscono 
gli elementi di progettazione in UPDM, dove viene definito un metamodello che definisce la 
semantica degli elementi. Questo è denominato DMM (Domain Meta Model), suddiviso in una serie 
di viste che rappresentano i vari punti di vista di un progetto di sistema in base ai diversi interessi a 
livello progettuale degli stakeholder  coinvolti nel processo di sviluppo. Le viste risultano tra loro 
correlate dato che è possibile creare dei riferimenti tra queste per una migliore cooperazione tra le 
discipline e una migliore analisi degli aspetti coinvolti. Nel metamodello le viste sono rappresentate 
attraverso i package che raccolgono i diagrammi e gli elementi di modellazione. 
 
 
 
 
Ogni vista rappresenta una visuale che cattura determinati aspetti che vanno a specializzarsi secondo 
una determinata disciplina ingegneristica nelle successive fasi dello sviluppo di sistema. 
Le viste definite sono: 
Figura 1- Views [3]
7 MBSE (Model Based Systems Engineering) 
 
7 
 
 
 All views (AV) 
 Acquistion view (AcV) 
 Operational view (OV) 
 System view (SV) 
 Strategic view (StrV) 
 Technical Standard view (TC) 
 Service Oriented view (SoV) 
 
 
A livello di package (Figura 2) è definita la seguente rappresentazione del metamodello in cui gli 
elementi comuni tra DoDAF e MODAF sono raggruppati nel Core package, mentre per gli altri viene 
definito un apposito package. Qui è definito il primo livello di specifica (point of view) chiamato L0 
che contiene i package: Core, DoDAF e MODAF. Questo livello fa uso principalmente di UML 2.x e 
sfrutta per definire aspetti relativi ai servizi SoaML (Serivce Oriented Modeling Language) per la 
modellazione in ambito SOA (Service Oriented Architecture).  
Viene poi definito il livello L1 che racchiude tutti gli aspetti definiti in L0 e importa (<<import>>) il 
profilo SySML che viene utilizzato per definire tutte le visuali di sistema a livello architetturale.    
 
 
 
 
Figura 2 –DMM (Domain Meta Model) [3]
8 MBSE (Model Based Systems Engineering) 
 
8 
 
1.1.4 Views (Viste) 
 
All views 
 
In questa visuale sono raccolti tutti gli aspetti generali riguardo all’architettura tra cui lo scopo, 
l’appartenenza progettuale, frame temporali, ecc. 
Queste viste sono definite come un input per la gestione a livello architetturale di tutto il sistema, 
dove sono registrate tutte le modifiche che si presentano durante il processo di sviluppo. Sviluppi 
futuri le prendono come punto di avvio per estendere un progetto. 
Inoltre è definito un dizionario completo dei vocaboli specifici presenti a livello progettuale come 
supporto per le persone coinvolte nello sviluppo. 
AV-1  
In questo punto è fornita una panoramica generale del sistema con la pianificazione dello sviluppo 
del sistema e relativo sommario. 
 
 
Figura 3 - Metamodello AV-1 [3] 
 
A livello di metamodello sono definite le fasi dello sviluppo (EnterprisePhase) con relativa descrizione 
architetturale (ArchitecturalDescription) composta da una serie di viste (View) a cui possono essere 
associati uno o più punti di vista(Viewpoint). Gli elementi appartenenti al Core package sono definiti 
tramite apposito stereotipo (<<core>>), gli altri assumono un altro stereotipo in base al profilo di 
appartenenza. 
L’intero processo di sviluppo è definito come WholeLifeEnterprise, che definisce l’intero ciclo di vita 
a livello architetturale. 
Ogni fase enterprise mostra una serie di missioni (Mission) e un insieme di capacità (Capability).
9 MBSE (Model Based Systems Engineering) 
 
9 
 
AV-2 
In questa visuale sono definiti i termini specifici con relativa definizione che vanno a delineare il 
dizionario di progetto. Qui si definisce il tipo di un elemento e le persone coinvolte nel progetto viste 
come attori. Viene sfruttato il concetto di elemento UPDM (UPDMElement), visto a livello astratto 
come punto di estensione per la creazione di elementi con maggior livello di dettaglio . 
 
Figura 4 –UDPMElement ed elementi relazionati [3] 
AV-3 
Questa vista definisce le proprietà misurabili dei componenti (elementi fisici) definiti nel processo 
tramite il framework architetturale. 
 
Figura 5 – Metamodello AV-3  [3] 
 
Acquisition view 
 
La vista di acquisizione serve a descrivere gli elementi relativi ai dettagli progettuali con le specifiche 
dipendenze tra più parti che costituiscono il progetto nel suo complesso e le capacità integrative. 
AcV-1 
Definisce una prospettiva organizzazionale con riferimento ai dettagli progettuali e relative 
dipendenze garantendo un livello di integrità.  
AcV-2 
Prospettiva progettuale che attraverso l’utilizzo di timeline traccia l’esecuzione di ogni attività 
all’interno del progetto. Le attività sono viste come milestone, cioè fasi che producono un manufatto 
alla fine del ciclo di vita.
10 MBSE (Model Based Systems Engineering) 
 
10 
 
Operational view 
 
La vista operazionale definisce le attività svolte dai vari partecipanti al sistema che vanno dalle 
persone alle macchine e quali benefici producono a chi viene coinvolto nella loro esecuzione. 
OV-1 
Questa vista fornisce una descrizione ad alto livello di cosa l’architettura dovrà fare e come dovrà 
farlo[2]. Può essere definita come modello visuale delle informazioni definite nella vista AV-1. 
Viene introdotto il concetto di missione (Mission o Scenario) e vengono descritti i concetti a livello 
operazionale relativi a una o più missioni (HighLevelOperationalConcept). I modelli dell’architettura 
operazionale vengono suddivisi in gruppi  sulla base di un determinato scenario. 
 
Figura 6 - Metamodello OV-1 [3] 
Questa vista può essere uno degli ultimi modelli definiti con l’intento di definire un sommario 
dell’intera descrizione architetturale. 
OV-2 
Definisce i requisiti di una capacità in un contesto operazionale e definisce i suoi confini[2].  
In questa vista viene rappresentata la distribuzione geografica di un sistema con la specifica di 
piattaforme e locazioni geografiche per localizzare i nodi operazionali. Attraverso l’ausilio di Needline 
è definito il flusso scambiato tra i nodi delineando: le informazioni scambiate, lo spostamento di 
persone e piani per la gestione delle risorse(materiali o energia).  
OV-3 
In questo punto si specifica lo scambio di informazioni  e risorse tra i nodi e le attività come flusso 
relazionato con il modello rappresentato in OV-2.   
OV-4 
Questa vista è suddivisa in due sotto viste: Tipica e Attuale. 
La tipica definisce la struttura organizzazionale e le interazioni tra organizzazioni di tipo civile o 
militare. Le relazioni sono estese a livello di risorsa. 
Mentre l’attuale definisce la struttura e le relazioni che intercorrono tra gli attori visti come: ruoli 
umani e organizzazioni.
11 MBSE (Model Based Systems Engineering) 
 
11 
 
OV-5 
Vengono qui mostrate le attività operazionali compiute tramite apposito modello dai nodi coinvolti 
nell’interazione. Le operazioni (o processi) vanno a definire una missione o uno scopo a livello di 
business.  
OV-6 
Viene qui definito il comportamento dinamico delle attività operazionali attraverso tre modelli: 
specifica delle regole operazionali e di business (OV6-a, Operational Rules Model), specifica delle 
transizioni di stato da parte di un’attività operazionale (OV-6b, Operational State Transition Model) e 
specifica del flusso delle risorse attraverso un tracciamento in ordine temporale (OV-6c, Operational 
Event-Trace Description). 
OV-7 
Questa vista definisce i tipi di entità, i suoi attributi usati nella descrizione della struttura 
architetturale del dominio di sistema e le relazioni che intercorrono tra queste. 
 
Figura 7 - Metamodello OV-7 [3] 
System view 
 
Questa visuale ci permette di esprimere il sistema in termini di capacità operazionali attraverso 
Operational Viewpoint e requisiti utente. In questo modello vengono definite le risorse di sistema 
che supportano le attività operazionali e facilitano lo scambio di informazioni[2]. 
SV-1 
Definisce i sistemi che rappresentano l’architettura, le interconnessioni tra sistemi e le risorse di 
sistema[2]. 
SV-2 
Definisce la comunicazione all’interno del sistema intesa come percorsi che collegano gli elementi del 
sistema tra loro e la comunicazione di rete tramite la specifica di appositi protocolli.