Implementazione di una Web App per la verifica dei requisiti progettuali del modello SysML

UNIVERSITÀ DEGLI STUDI DI
TRIESTE
Dipartimento di Ingegneria e Architettura
Laurea Magistrale in Ingegneria Elettronica ed
Informatica
Applicazioni Informatiche
Implementazione di una Web App per la
verifica dei requisiti progettuali del modello
SysML
12 maggio 2021
Laureando Relatore
Luca Dalle Vedove Prof. Lorenzo Castelli
Correlatore
Dott. Carlos Kavka
Anno Accademico 2019/2020

Ai miei genitori,
che mi hanno sempre sostenuto
anche nei momenti più duri.

Indice
Introduzione ii
1 Studio preliminare 1
1.1 Modelli UML/SysML . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Studio di MagicDraw® e creazione di un modello SysML . . 10
1.3 Studio sull’esportazione dei requisiti e scelte effettuate . . . . 15
2 Implementazione 18
2.1 Scelte tecnologiche, Angular e Soul . . . . . . . . . . . . . . . 18
2.2 Struttura del progetto . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.3 Dettagli . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Dimostrazione caso d’uso 23
3.1 Caricare i file . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Svolgere l’analisi . . . . . . . . . . . . . . . . . . . . . . . . . 24
Conclusioni 28
i

Introduzione
Il MBSE (Model-Based Systems Engineering) è un ramo dell’ingegneria dei
sistemi che utilizza dei modelli per supportare la progettazione di un sistema
nelle sue molteplici fasi di sviluppo, permettendo di definirne caratteristiche,
requisiti e funzionalità. Per poter descrivere questi modelli in maniera for-
male si ha la necessità di utilizzare un linguaggio standard e SysML è quello
che, nel corso degli anni, si è affermato, diventando quello più utilizzato.
Tra le varie fasi di sviluppo di un sistema, c’è quella che riguarda la
creazione e analisi delle possibili implementazioni. Questa è svolta molto
spesso da dei software di ottimizzazione che, in base a diversi parametri
configurabili e dipendenti dal progetto, elaborano il modello restituendo delle
possibili soluzioni.
Tuttavia la fase di modellazione e quella di ottimizzazione spesso non
sono collegate in maniera autonoma appartenendo a programmi disgiunti.
Per risolvere questa problematica si stanno facendo diverse attività di ricerca
e sviluppo, specialmente a livello aziendale.
Ci sono attualmente un paio di soluzioni proposte, limitate però a piat-
taforme, software e formati proprietari.
Per la verifica di realizzabilità dei risultati all’interno del modello Sy-
sML invece ci sono delle soluzioni basate su Cameo Simulation Toolkit™,
un’estensione di MagicDraw®, software usato anche in questa tesi per la
modellazione SysML, illustrate negli articoli [6] e [4]. Questo approccio, per
quanto immediato su progetti di piccola scala, diventa molto più difficile da
ii

INTRODUZIONE
realizzare con l’aumento della complessità del modello.
In questo progetto di tesi si propone come soluzione l’implementazione
di un’applicazione web che permetta la verifica la realizzabilità dei risulta-
ti ottenuti da un’attività di ottimizzazione, confrontandoli con i requisiti
progettuali specificati nel modello SysML.
L’obiettivo finale è quello di poter caricare nell’applicazione web il model-
lo SysML e i risultati dell’ottimizzazione, far selezionare poi all’utente quali
requisiti utilizzare per la verifica, ed infine mostrare, tra i risultati caricati,
quelli siano quelli realizzabili.
L’attività di tirocinio e tesi è stata svolta in ESTECO, azienda di svilup-
po software specializzata in ottimizzazione numerica e gestione dei dati di
simulazione, partendo dalla necessità di collegare il loro portale di ottimizza-
zione Volta alla progettazione SysML, ampliando quindi la loro conoscenza
nel mondo del MBSE.
Volta [2] è una piattaforma che ha come scopo principale la creazione di
design guidati dall’ottimizzazione e la gestione dei dati di simulazione. Il suo
punto di forza è la capacità di creare un ambiente dove gruppi di lavoro dif-
ferenti possono gestire ed elaborare i dati dello stesso progetto, permettendo
quindi un confronto in tempo reale dei risultati ottenuti e velocizzando la
fase di produzione.
Per la realizzazione di questo progetto si è partiti inizialmente dallo stu-
dio di UML e SysML, con particolare attenzione alle parti sui requisiti e
vincoli, per poi passare alla realizzazione del modello SysML con il software
MagicDraw® del caso d’uso. Si è successivamente studiato come esportare
il modello per poterlo caricare nella nostra applicazione.
Dopo aver scelto le tecnologie per sviluppare il software, si è iniziata
la sua progettazione e successiva implementazione. Si è partiti dal carica-
mento dei requisiti e dei risultati, per finire poi con l’analisi e successiva
visualizzazione.
iii

Capitolo 1
Studio preliminare
1.1 Modelli UML/SysML
Quando si progetta un sistema, software o generico che sia, è fondamentale
avere dei modelli che possano rappresentalo, specificandone le varie parti,
nei funzionamenti e nelle caratteristiche [3]; è da questa necessità che sono
nati i linguaggi di modellazione e, in particolar modo, quelli orientati agli
oggetti.
L’iniziale presenza di molti linguaggi diversi portò alla necessità di un’u-
nificazione e quindi alla creazione di uno standard, proprio per questo motivo
è nato UML (Unified Modeling Language). Esso sfrutta diagrammi, elementi
grafici e testuali per semplificare la rappresentazione dei modelli e fornisce ai
suoi utilizzatori una semantica ben definita. Nel 1997 UML è entrato sotto
la supervisione della OMG (Object Management Group), un consorzio costi-
tuito dai più grandi attori nell’ambito informatico, che ha come obiettivo la
creazione e formalizzazione di standard, fondamentali per l’interoperabilità
tra aziende.
La struttura del linguaggio UML, visibile in figura 1.1, può essere spiegata
in maniera semplificata suddividendola in parti, ognuna con una funzionalità
specifica.
1

CAPITOLO 1. STUDIO PRELIMINARE
In primo luogo è possibile distinguere gli elementi UML in funzione a ciò
che descrivono; possono infatti riguardare la struttura del modello, come ad
esempio le classi o i componenti, oppure il comportamento, come ad esempio
le attività o i casi d’uso. Ci sono inoltre elementi che possono collegare
strutture e comportamenti.
Si può poi fare una distinzione tra modello e diagramma; il primo è una
descrizione dell’intero sistema mentre il secondo una rappresentazione di un
particolare aspetto dello stesso. Se ad esempio un modello descrive in tutti
i suoi aspetti un’automobile, un diagramma può concentrarsi in un aspetto
particolare, come la portiera oppure il sistema frenante.
Figura 1.1: Struttura di UML. In [9]
Questo linguaggio nasceva principalmente nell’ambito della progettazione
del software [9] ed è stato definito unificante perché aveva come obiettivo la
creazione di un sistema multidisciplinare; si poteva utilizzare per disegnare la
parte software del sistema ma anche per specificare quella fisica o economica.
Ciò è reso possibile dall’utilizzo di metodi di estensione, chiamati stereotipi
(stereotypes).
Essi permettono di creare una nuovo elemento del modello partendo da
un elemento UML di base, indicato con il tag «metaclass», tramite una
estensione. Nella figura 1.2 si può vedere la definizione di uno stereotipo
rappresentate un Requirement, estendendo la metaclasse Class.
2

Figura 1.2: Esempio dello stereotipo Requirement. In [9]
Con la versione 2.0 sono state inoltre aggiunte ulteriori funzionalità che
hanno permesso di estendere UML anche ad altre discipline quali l’ingegne-
ria dei sistemi e la modellazione dei processi aziendali. Nonostante queste
aggiunte e l’immensa mole delle specifiche del linguaggio, che lo rendono an-
che complesso da utilizzare, ci sono però delle limitazioni quando lo si vuole
utilizzare all’infuori dello sviluppo software [1]. Proprio per questo motivo
nell’ambito dell’ingegneria dei sistemi, con un’iniziativa dell’INCOSE (In-
ternational Council on Systems Engineering), è nata l’estensione di UML
chiamata SysML (Systems Modeling Language) [fig. 1.3].
Figura 1.3: UML e SysML
INCOSE è una organizzazione che si occupa di MBSE che, vedendo le li-
mitazioni di UML 2.0 nell’ambito dell’ingegneria dei sistemi, ha voluto crear-
ne un’estensione che permettesse la rappresentazione di modelli più complessi
3

ed altamente multidisciplinari. Le due principali funzionalità di SysML che
sono state aggiunte a quelle UML sono i diagrammi dei requisiti e parame-
trici, come si vede nella figura 1.4, punti di partenza per questo lavoro di
tesi.
Figura 1.4: Tipi di diagrammi SysML1
1.1.1 Requisiti
In SysML un requisito è utilizzato per specificare delle funzionalità, dei li-
miti di performance o delle caratteristiche che il sistema, o una sua parte,
deve avere. Queste informazioni devo essere specificate in maniera chiara
e consistente, lasciando però anche una certa ambiguità che lasci spazio a
diverse possibili soluzioni, sia a livello tecnologico che a livello metodologico;
devono descrivere cosa il sistema deve fare e con quali caratteristiche, non
come deve farlo.
I requisiti si possono sostanzialmente dividere in due tipi [3]:
• Funzionali, descrivono cosa il sistema deve fare o cosa l’utente può
farci, ad esempio i servizi che deve offrire.
1
Immagine presa dal sito https://omgsysml.org/what-is-sysml.htm
4

• Non-funzionali, descrivono i limiti e i vincoli a cui il sistema deve
sottostare, as esempio i tempi di risposta di un servizio.
In UML non era previsto un metodo per descrivere i requisiti proget-
tuali, l’unica possibilità era quella di usare gli stereotipi associandoli ai dia-
grammi dei Casi d’Uso con una relazione «refine»; ciò permetteva solamente
la rappresentazione dei requisiti funzionali. Per rappresentare invece i re-
quisiti non-funzionali si è introdotto in SysML il diagramma dei requisiti,
utile punto di incontro tra chi ha progettato il sistema con chi poi lo deve
implementare.
Il diagramma dei requisiti utilizza delle relazioni per collegare i requisiti
ai relativi elementi del sistema; in SysML ci possono essere diversi tipi di
relazioni possibili, come si può vedere in figura 1.5, ognuna con caratteristiche
diverse:
• Containment, usando la notazione crosshair o qualified name string si
può indicare che un requisito è contenuto in un altro.
• Derive, «deriveReq», quando un requisito è derivato dall’altro.
• Refine, «refine», usata quando un requisito viene descritto in maniera
più dettagliata da un elemento del modello, generalmente un use case.
• Satisfy, «satisfy», utilizzata quando un requisito viene soddisfatto da
un qualsiasi elemento del design, generalmente un block.
• Verify, «verify», usata per collegare un requisito ad il test case che lo
soddisfa.
• Copy, «copy», relazione usata per indicare che un requisito è la copia
testuale dell’altro.
• Trace, una relazione di dipendenza generica tra un requisito ed un ele-
mento del modello che usa lo stereotype «trace», viene usata solamente
per la tracciabilità.
5

Figura 1.5: Esempio di diagramma dei requisiti. In [1]
1.1.2 Vincoli
Essendo i requisiti descritti solamente in forma testuale, per esprimere even-
tuali vincoli del sistema si deve far uso dei blocchi vincolo. In essi è possibile
specificare parametri ed equazioni in modo tale che, se verificate, vengano
soddisfatti i relativi requisiti.
Per illustrare meglio il funzionamento dei blocchi vincolo è stato creato
il modello di un semplice circuito elettrico con un generatore di tensione e
una resistenza, rappresentato nella figura 1.6.
6

Figura 1.6: Diagramma del circuito esempio.
Nella figura 1.7 si possono vedere i vincoli relativi alle varie componenti
del circuito, come ad esempio la relazione tra tensione, corrente e resistenza
o il valore di terra della tensione.
7

Figura 1.7: Esempio di blocchi vincolo
Per collegare i blocchi vincolo uno con l’altro viene utilizzato un dia-
gramma parametrico dove è possibile, oltre che collegare i parametri alle
equazioni all’interno del blocco, mettere in relazione i parametri dei diversi
blocchi, così da creare un sistema vincolato con tutte le parti del modello.
Nella figura 1.8 sono rappresentati i collegamenti tra il blocco vincolo, in
azzurro, con i parametri interni, in rosa, o con i parametri esterni, sul bordo.
8

Figura 1.8: Esempio diagramma parametrico
Requisiti e vincoli possono essere poi rappresentati insieme in un singolo
diagramma a blocco raffigurante l’intero modello, come in figura 1.9, o una
sua parte, così da poter capire in maniera semplice le caratteristiche che il
sistema dovrà avere.
Figura 1.9: Esempio di diagramma dei blocchi dell’intero modello
9

1.2 Studio di MagicDraw® e creazione di un mo-
dello SysML
Dato il successo riscontrato da UML e SysML, sono stati sviluppati nel
corso degli anni diversi programmi che ne rendessero più facile l’utilizzo,
fornendo strumenti ed interfacce grafiche per semplificare la creazione di
modelli. Per questo progetto di tesi si è scelto di utilizzare MagicDraw®,
software sviluppato da No Magic, Inc. Questa scelta è stata dettata dal fatto
che era possibile usare tutte le funzionalità disponibili gratuitamente per un
periodo di prova e dalla presenza di numerose guide ufficiali presenti sul loro
sito web.
Dopo un primo periodo di studio si è deciso di ricreare in MagicDraw®
l’analisi presentata nel paper [6] e illustrata nel dettaglio nel webinar “Auto-
mated Requirements Verification” tenuto dagli autori.
In esso veniva creato un modello di un sistema frenante, specificando i
suoi componenti e i relativi requisiti da soddisfare, e successivamente ve-
nivano proposte delle soluzioni utilizzando l’estensione Cameo Simulation
Toolkit™ di MagicDraw®.
Questa attività di studio del lavoro svolto nel paper, oltre a consolidare le
abilità pratiche di utilizzo di MagicDraw®, ha messo in luce la necessità
di creare un sistema parametrico di blocchi di vincolo per poter verificare i
requisiti e proporre delle soluzioni ammissibili.
In questo progetto di tesi si è scelto di usare come caso d’uso l’otti-
mizzazione di un modello rappresentante una trave rettangolare, visibile in
fig. 1.10. Essa è saldata ad una trave principale da un lato e ha una forza
applicata sull’altro.
10

L’obiettivo dell’ottimizzazione è quello di minimizzare il costo e la defor-
mazione della trave, variando i parametri:
• H: spessore della saldatura
• L: lunghezza saldatura
• T: spessore della trave
• B: larghezza della trave
Si hanno come parametri costanti:
• Young: modulo di elasticità del materiale
• WC: costo della saldatura
• MC: costo del materiale
• F: forza applicata
• S: lunghezza della trave
E in uscita:
• Disp: lo spostamento della punta della trave
• MaxT: massimo sforzo normale
• MaxS: massimo sforzo di taglio
• Mvol: volume del materiale
• Wvol: volume della saldatura
11

Figura 1.10: Struttura della trave
Nel modello SysML la trave è rappresentata da un unico blocco, conte-
nente i suddetti parametri, ai quali vengono associati i rispettivi requisiti.
Essi stabiliscono, per i parametri in uscita MaxT e MaxS, i valori massimi
di accettabilità, così come i valori minimi per i parametri variabili B e H. Al
fine di poter verificare questi requisiti, sono stati creati ed associati i relativi
blocchi di vincolo.
I paramtri di uscita sono calcolati con le seguenti formule:
• Disp = (F∗S3)
(4∗T3∗B∗Y oung)
• MaxT = 6 ∗ S ∗ F
(T2∗B)
12

• MaxS =
√︃
( (F∗(S+L/2)
(B∗L∗H∗
√
2)
)2 + ( F
(2∗L∗H∗
√
2)
)2
• Mvol = T ∗ B ∗ (S + L)
• Wvol = H2 ∗ L
Il diagramma dei blocchi in figura 1.11 rappresentanta il modello appena
descritto ed è utile per averne una visione complessiva. Si possono vedere le
relazioni «satisfy» tra il blocco trave e i requisiti e «refine» tra i requisiti e
i rispettivi vincoli.
Figura 1.11: Modello del sistema trave
Per associare i parametri del blocco trave ai rispettivi vincoli, sono stati
creati due diagrammi parametrici: nel primo, in figura 1.12, ci sono le asso-
ciazioni con i vincoli dei requisiti, mentre nel secondo, in figura 1.13, con i
vincoli rappresentanti le formule per il calcolo dei parametri in uscita.
13

Figura 1.12: Modello del sistema trave
14

Figura 1.13: Diagramma parametrico con le formule
1.3 Studio sull’esportazione dei requisiti e scelte
effettuate
Una volta creato il modello SysML, si è cominciato a studiare come poter
esportare i requisiti per caricarli nell’applicazione, così da procedere poi con
la verifica dei risultati.
Inizialmente si è preso in considerazione lo standard ReqIF [7], acronimo
di Requirements Interchange Format, gestito dalla OMG e sviluppato per
ovviare al problema dello scambio di requisiti tra programmi di gestione
diversi.
A partire dal 1999 nel settore automobilistico si è iniziato ad usare
15

dei software per la gestione dei requisiti; questa metodologia di lavoro si
è espansa successivamente anche ad altre realtà industriali e, essendoci di-
versi software sul mercato, si è reso necessario lo sviluppo di uno standard
per permettere un’agile e coerente comunicazione tra di essi.
Studiando le specifiche dello standard e facendo alcuni test, si è scoperto
però che non fosse perfettamente adatto ai nostri scopi. Esso, infatti, esporta
unicamente i requisiti che, come visto precedentemente, sono rappresentati
in SysML solamente in forma testuale. Per poter verificare i requisiti è
necessario poter esportare anche i vincoli associati ad essi.
Successivamente è stato analizzato il nuovo standard SysPhS [8] (SysML
Physical Interaction and Signal Flow Simulation), un’estensione di SysML
che aggiunge ulteriori funzionalità per facilitare la creazione di modelli con
interazioni fisiche o di flusso del segnale. L’intendo dello standard è quel-
lo di rendere più facile il passaggio tra il modello SysML e i software di
modellazione. Al momento attuale però ci sono specifiche solamente per
implementare il collegamento con i software Modelica, Simulink e Simsca-
pe, rendendolo quindi non funzionale al nostro obbiettivo. Nell’articolo [5]
viene proposta un’implementazione di questo standard, un programma che
converte il modello SysML in un modello eseguibile nel suddetti software.
I modelli SysML basano il loro salvataggio sul formato XML (eXtensible
Markup Language), si è quindi iniziato a valutare se si potesse ricavare gli
elementi di interesse direttamente da li.
Dopo aver analizzato attentamente il file XML generato e aver trovato le
informazioni cercate, ci si è assicurati che i requisiti e i vincoli non fossero
scritti all’interno di tags proprietari di MagicDraw®; in quel caso ci sareb-
bero potuti essere problemi di lettura nel caso il modello SysML provenisse
da un altro software di modellazione.
Il problema principale dell’esportazione sfruttando il formato XML è che,
come detto in precedenza, SysML è un linguaggio dove non è specificata la
16

tecnica di modellazione da utilizzare; ciò rende problematica la ricerca dei
requisiti e dei vincoli all’interno del file poichè ogni modellazione ha infatti
la sua struttura interna.
Figura 1.14: Struttura del modello
Nel caso d’uso di questa tesi, la struttura del modello è riportata nella fi-
gura 1.14. I requisiti si possono trovare nel packagedElement “Requirements”
mentre i vincoli nel packagedElement “Analysis”. Il collegamento tra di essi
è mantenuto sfruttando le relazioni viste nella figura 1.11, salvate anch’esse
in “Analysis” con il tipo "uml:Abstraction" e contenenti gli id del relativo
requisito e vincolo.
17

Capitolo 2
Implementazione
2.1 Scelte tecnologiche, Angular e Soul
Il primo passo per la realizzazione dell’applicazione web è stato quello della
scelta del linguaggio di programmazione e quindi della tecnologia da usare.
Considerando la necessità di sviluppare un’interfaccia grafica non eccessi-
vamente complessa ma nel contempo ordinata ed in linea con gli standard
aziendali, si è deciso di creare una applicazione web usando HTML e Ty-
pescript, fruttando la piattaforma di sviluppo Angular, più precisamente la
release 11.
Tra i vari vantaggi derivanti dall’utilizzo di Angular si hanno in particolar
modo:
• la struttura basata sui componenti, che ha permesso di creare un’ap-
plicazione a pagina singola, caricando dinamicamente i componenti
necessari a visualizzare il contenuto e le funzionalità correnti;
• la possibilità di utilizzare librerie appartenenti a nodejs essendo Type-
script un linguaggio basato su Javascript;
Proprio sfruttando questi punti di forza si è potuto risolvere la problema-
tica dell’interfaccia grafica dell’applicazione. L’azienda nel corso degli anni
18

CAPITOLO 2. IMPLEMENTAZIONE
ha sviluppato una propria libreria di stili e componenti grafici con lo scopo di
rimanere consistenti nei vari prodotti aziendali per quanto riguarda il design;
questa libreria si chiama Soul ed è stata utilizzata in questo progetto.
All’interno di Soul si possono trovare svariati componenti Angular che
possono essere importati ed utilizzati nella propria applicazione, con le do-
vute configurazioni.
Nella documentazione di Soul è data importanza anche ai colori da utiliz-
zare; sono specificati infatti i precisi codici HSL (Hue Saturation Lightness)
per ogni situazione, proprio per rendere consistente il loro significato tra le
varie applicazioni e quindi facilitando l’utente nell’utilizzo di esse.
2.2 Struttura del progetto
L’applicazione web è, come detto in precedenza, un’applicazione a singola
pagina, composta da diversi componenti caricati dinamicamente.
Considerando che i requisiti e i risultati dell’analisi sono dati utilizzati
da diversi componenti, si è optato per creare due service con lo scopo di
memorizzarli e quindi facilitarne l’utilizzo dove necessari. Per la lettura e il
successivo caricamento dei file esterni si è creato il componente "read-file",
che viene utilizzato sia per i requisiti che per i risultati, facendo un controllo
anche sull’estensione del file che l’utente ha selezionato. Esso inizialmente
controlla che l’estensione del file sia corretta e successivamente, in funzione
che si tratti di requisiti o risultati, lo elabora di conseguenza.
Nel caso sia un file contenente i requisiti, esso rappresenta un modello Sy-
sML e quindi l’elaborazione prevede l’estrazione delle informazioni necessarie
dalle varie parti del modello stesso.
Inizialmente si crea, per ogni requisito, un oggetto contenente l’id e il
nome, dati ricavabili dal packagedElement di tipo "uml:Package", con nome
"Requirements" e contenuto in [uml:Model]; successivamente viene inserito
il testo, ricavabile in [sysml:Requirement].
19

Le informazioni riguardo i vincoli associati vengono ricavate, come det-
to nel capitolo precedente, dal packagedElement con nome "Analysis" in
[uml:Model].
All’interno di questo pacchetto vengono, per prima cosa, recuperate le
informazioni riguardanti le relazioni tra i requisiti e i vincoli presenti nei
packagedElement di tipo "uml:Abstraction". Per ogni requisito si controlla
se ci sono vincoli associati al suo id e, nel caso positivo, vengono aggiunti
nell’oggetto precedentemente creato.
Successivamente, sempre nel pacchetto "Analysis", si recuperano le infor-
mazioni dei vincoli trovati cercandoli nei packagedElement di tipo "uml:Class",
in funzione del loro id. Nomi e valori dei vincoli viengono così aggiun-
ti all’oggetto che a questo punto è completo e quindi caricato nel relativo
service.
Per quanto riguarda invece i risultati il procedimento è più semplice,
essi infatti sono salvati in formato CSV (Comma-Separated Values) renden-
do possibile l’utilizzo di librerie di parsing standard e quindi permettendo-
ne l’immediato salvataggio nel relativo service. In questo progetto è stata
utilizzata la libreria "Papa Parse".
Si è successivamente divisa la pagina in tre parti: Requisiti, Risultati e
Dettagli, come rappresentato nella figura 2.1.
20

Figura 2.1: Struttura base dell’applicazione
2.2.1 Requisiti
Nella sezione dei requisiti inizialmente si ha solo la possibilità di caricare un
file, con estensione XML, contenente il progetto SysML; questa operazione
è gestita dal componente "read-file" illustrato precedentemente.
Una volta che i requisiti sono stati caricati, il componente "requirement"
ne mostra i nomi e li rende selezionabili per venerne i dettagli nell’apposita
sezione.
Viene inoltre caricato il componente "modal-select-req" che permette al-
l’utente di selezionare i requisiti che si vogliono verificare, colorandoli per
evidenziare la scelta corrente.
2.2.2 Risultati
Analogamente alla sezione Requisiti, anche qui inizialmente è caricato "read-
file".
21

In aggiunta, è presente il componente "modal-results" che permette di
scaricare tramite delle API REST (Application Programming Interface, Re-
presentational State Transfer) un file contenenti i risultati di una sessione
svolta sul portale Volta. L’utente può cercare una sessione scrivendo il nome
in una casella di testo e successivamente selezionare quella desiderata dalla
lista di quelle trovate.
Una volta caricati i risultati, viene mostrato un tasto per visualizzarli
nella sezione dettagli.
2.2.3 Dettagli
La sezione Dettagli è caricata dinamicamente in funzione alla selezione del-
l’utente sfruttando due componenti: "analysis-details" e "req-details".
Il primo mostra i risultati dell’analisi in forma tabellare, evidenziando
con il colore specifico le soluzione non ammissibili. Per determinare se una
soluzione è ammissibile o meno, vengono confrontati i valori della riga con i
vincoli dei requisiti selezionati, inoltre nel caso ci siano valori mancanti, la
soluzione è considerata automaticamente non ammissibile.
In questa fase dell’analisi viene anche verificata la corretta formulazione
dei vincoli, essi infatti potrebbero contenere una formula errata oppure delle
variabili non presenti nei risultati.
In entrambi i casi l’utente verrà avvisato del relativo problema e il nome
del requisito verrà colorato di rosso; ovviamente tutte le soluzioni saranno
non ammissibili finché l’utente non deselezionerà il requisito. Nel caso di
variabili non presenti verrà inoltre salvato il nome di essa e potrà essere
consultabile dei dettagli del relativo requisito.
Il componente "req-details" invece mostra i dettagli del requisito selezio-
nato, comprendenti il testo, i vincoli e le eventuali variabili non presenti nei
risultati.
22

Capitolo 3
Dimostrazione caso d’uso
3.1 Caricare i file
Come mostrato in figura 2.1, sia per i requisiti che per i risultati, c’è la
possibilità di caricare i relativi dati dai file salvati in locale. Per i risultati
c’è inoltre l’opzione per scaricarli direttamente dal portale Volta; utilizzan-
do una finestra modale si può cercare il nome del progetto e selezionare la
sessione desiderata. In figura 3.1 si può vedere il processo di caricamento dei
risultati sfruttando quest’ultima metodologia; è stata scritta nella casella di
testo la parola chiave "beam", utilizzata nel nome del progetto su Volta, e
successivamente si è selezionato la sessione di ottimizzazione desiderata su
cui eseguire la verifica.
23

CAPITOLO 3. DIMOSTRAZIONE CASO D’USO
Figura 3.1: Scaricare i risultati
3.2 Svolgere l’analisi
Come visualizzabile in figura 3.2, nella sezione dei requisiti in alto a sinistra
viene presentata la lista dei requisiti precedentemente caricati dal modello
SysML.
Cliccando su uno di essi è possibile visualizzarne i dettagli quali il nome,
il testo e i vincoli associati, mostrati poi sul lato destro nella sezioni dettagli.
24

Figura 3.2: Dettagli requisiti
Premendo sul pulsante "Seleziona i requisiti da verificare" verrà visua-
lizzata una finestra modale con una selezione, come mostrato in figura 3.3.
In questo esempio sono stati selezionati i due requisiti "LimitMaxNormal" e
"BeamWidthThickness", rispettivamente il limite massimo ammissibile del
parametro MaxT e le condizioni che garantiscono la dimensione minima della
trave.
Figura 3.3: Selezione dei requisiti
25

Infine premendo il pulsante "Visualizza i risultati", nella sezione Dettagli
verrà mostrata la tabella dei risultati, visibile in figura 3.4, mettendo in
evidenza con un colore giallo le righe che non soddisfano i requisiti selezionati.
In questo caso, per i risultati con ID 0, 5 e 17, non vengono superati i
controlli in quanto il loro valore di MaxT è superiore quello specificato nel
vincolo MaxT<14, associato al requisiti selezionato "LimitMaxNormal". Il
risultato con ID 10 invece non presenta alcun valore di MaxT e risulta quindi
non ammissibile.
Da notare che l’utente può vedere in qualsiasi momento quali requisiti
sta verificando perchè evidenziati da un colore verde.
Figura 3.4: Risultato analisi
Nel caso ci siano degli errori nei vincoli di un requisito selezionato, come
ad esempio un’errata formulazione o riferimenti a parametri non presenti nei
risultati caricati, esso avrà il testo in rosso. Di conseguenza, non potendolo
usare nella verifica, nei dettagli tutti i risultati non saranno ammissibili,
come si vede in figura 3.5. In questo particolare esempio nel vincolo del
requisito "LimitMaxNormal" è stata inserita una formula che riferiva ad un
parametro chiamato "test", non presente tra quelli dei risultati.
26

Figura 3.5: Errore analisi
27

Conclusioni
L’obiettivo di creare un’applicazione che, dati i risultati di un’ottimizzazione,
ne verifica la validità rispetto ai requisiti progettuali del modello SysML è
stato raggiunto. Sono stati fatti però alcuni compromessi che lasciano la
possiblità di miglioramenti per eventuali lavori futuri, tra questi:
• l’implementazione del caricamento dei requisiti in sistemi SysML svi-
luppati con una diversa tecnica di modellazione, e quindi una diversa
struttura nel rispettivo file XML;
• dare la possibilità all’utente di eseguire una nuova sessione di otti-
mizzazione direttamente all’interno dell’applicazione, senza limitarsi a
caricare sessioni già svolte;
• creare un modo per modificare alcune parti del modello SysML di-
rettamente dall’applicazione, così da poter correggere eventuali errori
presenti.
Il lavoro svolto è nell’ambito della ricerca e sviluppo ed è quindi un
prototipo iniziale di un eventuale prodotto aziendale; in quest’ottica quan-
to creato, nonostante necessiti di future aggiunte, da’ già una visione delle
potenzialità della soluzione.
Essendo l’MBSE un argomento poco conosciuto prima di questo progetto,
una parte sostanziale del lavoro è stata quella di studio del linguaggio Sy-
sML per averne una conoscenza abbastanza approfondita, specialmente per
28

CONCLUSIONI
quanto riguarda la modellazione dei requisiti e vincoli. Anche i software e le
tecnologie usate erano sconosciute all’inizio, è stato quindi necessario un pe-
riodo di formazione per poterle applicare, prima per la creazione del modello
SysML usato nel caso d’uso e poi per l’implementazione dell’applicazione
web.
Al di là dei risultati ottenuti e alla luce di quanto detto, si sottoli-
nea l’importanza delle conoscenze acquisite durante questa attività di tesi,
sicuramente utili per eventuali progetti futuri e nell’ambito lavorativo.
29

Bibliografia
[1] Lenny Delligatti. SysML Distilled: A Brief Guide to the Systems Mode-
ling Language. Addison-Wesley Professional, 2013.
[2] ESTECO. Volta. url: https://www.esteco.com/volta.
[3] Sanford Friedenthal, Alan Moore e Rick Steiner. A Practical Guide to
SysML,The Systems Modeling Language. Morgan Kaufmann, 2014.
[4] Robert Karban, Nerijus Jankevičius e Maged Elaasar. “ESEM: Auto-
mated Systems Analysis using Executable SysML Modeling Patterns”.
In: INCOSE International Symposium 26.1 (2016), pp. 1–24.
[5] Robert Karban, Nerijus Jankevičius e Maged Elaasar. “Translator from
Extended SysML to Physical Interaction and Signal Flow Simulation
Platforms”. In: Research of National Institute of Standards and Techno-
logy 124.124017 (2019).
[6] Aurelijus Morkevicius e Nerijus Jankevicius. An approach: SysML-based
automated requirements verification. IEEE, 2015.
[7] OMG. Requirements Interchange Format (ReqIF). 2016. url: https:
//www.omg.org/spec/ReqIF/About-ReqIF.
[8] OMG. SysML Extension for Physical Interaction and Signal Flow Si-
mulation. 2018. url: https://www.omg.org/spec/SysPhS/About-
SysPhS.
30

BIBLIOGRAFIA
[9] Tim Weilkiens. Systems Engineering with SysML/UML: modeling, ana-
lysis, design. Morgan Kaufmann, 2008.
31

Implementazione di una Web App per la verifica dei requisiti progettuali del modello SysML

Recommended

Recommended

More Related Content

Similar to Implementazione di una Web App per la verifica dei requisiti progettuali del modello SysML

Similar to Implementazione di una Web App per la verifica dei requisiti progettuali del modello SysML (20)

Recently uploaded

Recently uploaded (7)

Implementazione di una Web App per la verifica dei requisiti progettuali del modello SysML