Affidabilità di Sistemi Software Complessi

Modifiche di SysML rispetto a UML

SW, e modificato nel significato di 3 diagrammi (quelli in giallo), per adattare essi alle esigenze di SysML:

• Rispetto a UML, SysML toglie i diagrammi di comunicazione, di Timing, delle componenti, degli oggetti, e di deployment, perché vedono solo la parte di dettaglio del componente software, che ora diventa solo una parte del sistema (software + Hardware + Personale).
• SysML introduce il Requirement Diagram per specificare i requisiti, sia funzionali che non funzionali, ed il Parametric Diagram, in cui a parte specifica solo i requisiti non funzionali.
• SysML trasforma il concetto di “classe” in quello di “blocco”, quindi introduce un Block Definition Diagram in cui descrive il legame fra tutti i blocchi (sottoparti del sistema complesso), dove a sua volta ogni blocco è un sistema di grandi dimensioni che deve essere dettagliato a parte con un Internal Block Diagram. Anche l’Activity Diagram ora non si riferisce più alle classi.

ma ai blocchi.

1.2.1.1. SysML Requirement Diagram

Prima di poter affrontare la trattazione dei Requirements Diagrams, è importante ricordare cosasono i requisiti. Un requisito è una frase che descrive qualcosa che il sistema farà, o una proprietà o vincolo che si desidera per il sistema e che gli stakeholders ritengono necessario per la soluzione del problema. I requisiti si dividono in:

• Requisiti Funzionali: descrivono le funzionalità che il cliente desidera ottenere da un sistema.
• Requisiti Non Funzionali: caratteristiche di qualità e vincoli sul sistema, sull'ambiente, sul processo di sviluppo, sulle tecnologie etc.

Sebbene i requisiti funzionali possono essere modellati tramite il diagramma dei casi d'uso, non c'è elemento in UML per descrivere esplicitamente requisiti non funzionali. Con i Requirements Diagrams, SysML introduce dei mezzi per rappresentare i requisiti di progetto, come ad esempio tempi di reazione,

Il Requirements Diagram è un modo per rappresentare le dimensioni o le funzioni di un sistema attraverso un identificatore unico e delle proprietà testuali. Questo diagramma permette anche di collegare questi requisiti agli altri elementi del modello. Può essere presentato in diversi formati, come grafico, tabellare o come struttura ad albero. Ad esempio, un Parcheggio Auto avrà un Requirement Diagram SysML del tipo:

Lo stereotipo "requirement" rappresenta un requisito basato sul testo che include un ID (una semplice stringa), un testo descrittivo e, opzionalmente, proprietà definite dall'utente. Anche il testo è una stringa che include una descrizione del requisito stesso o un riferimento a una risorsa esterna. Inoltre, sono introdotte le seguenti relazioni tra requisiti:

• Derive: è una relazione di derivazione che permette di generare o dedurre un requisito da un altro requisito.

<<deriveReqt>> ed è permessa solo tra due requisiti. È una relazione di soddisfacimento, che permette che un requisito venga soddisfatto da un altro elemento del modello. Lo stereotipo è <<satisfy>>.

<<verify>> è una relazione di verifica, che permette di verificare tramite il test-case che i requisiti siano soddisfatti. Lo stereotipo è <<verify>>.

<<refine>> è una relazione di raffinamento, che specifica un elemento del modello che descrive in maggior dettaglio le proprietà di un requisito. Lo stereotipo è <<refine>>.

<<trace>> è una relazione tra un requisito e un elemento arbitrario del modello; descrive una relazione generale per ragioni di tracciabilità. Lo stereotipo è <<trace>>.

1.2.1.2. SysML 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:

• 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;
• permette di specificare la gerarchia del sistema e le sue possibili classificazioni.

Possibili esempi sono la rappresentazione di un'astrazione di un sistema e le sue componenti, oppure la descrizione delle interazioni tra entità che denotano relazioni fra i dati in un sistema.

I Blocks sono unità modulari, general purpose, che permettono di modellare in SysML le componenti strutturali di un sistema, ogni blocco ne definisce una collezione di funzionalità, che possono essere sia strutturali che comportamentali. Queste unità permettono di creare una struttura ad albero gerarchica fatta da tante componenti modulari, naturalmente la tipologia delle componenti, le connessioni e il modo in cui le componenti sono

Le componenti strutturali più importanti nel blocchi ci sono le Properties, utilizzate per descrivere:

• la composizione gerarchica di un blocco;
• le caratteristiche quantificabili, come il peso o la velocità;
• i range di valori corretti nei quali il blocco deve operare.

Le parti e le proprietà dei block sono collegate tra loro utilizzando particolari relazioni definite Connectors, che specificano sia funzioni strutturali che comportamentali del blocco, quindi sia come le parti di blocco sono connesse tra loro sia i tipi di comunicazione che si instaurano tra di loro. Viene mostrato come esempio il Block Definition Diagram di un Sistema di Videosorveglianza di un Parcheggio automatizzato:

1.2.1.3.

SysML 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. 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. Esso 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. Viene mostrato come esempio l'Internal Block Diagram di un Sistema di

Videosorveglianza di un Parcheggio automatizzato: 161.2.2.

Reti di Petri, UML e SysML sono modelli semiformali, che permettono di rappresentare in maniera grafica un sistema, ma non permettono di dire se ciò che si sta implementando è corretto, perché:

• o c'è troppo gap tra il codice ed il modello UML/SysML;
• o ci vuole troppo tempo per scrivere il codice per fare la dimostrazione.

Esistono modelli formali che permettono di "modellare" matematicamente il sistema, così da poterne dimostrare la correttezza, come ad esempio le Reti di Petri RP, che sono molto utilizzate per modellare le parti critiche di Sistemi Complessi. La limitazione di questi modelli è che quando il sistema è troppo complesso, si rischia di produrre un modello matematico computazionalmente troppo complesso perché se si astrae troppo si rischia di allontanarsi dalla realtà di interesse del sistema vero, e modellare qualcosa che non corrisponde.

più alla realtà. Per tale motivo, in generale si procede a modellare l'intero sistema con modelli semi-formali come SysML, mentre con modelli formali come le Reti di Petri si modellano le sottoparti più critiche del sistema, ovvero quelle in cui si devono gestire: - problemi di concorrenza; - problemi di gestione di risorse limitate; - problemi di mutua esclusione; Con le RP, è possibile fare analisi di prestazione e affidabilità dei nostri sistemi, facendo delle valutazioni qualitative (attraverso una rappresentazione grafica del sistema) e quantitative (attraverso un modello matematico del sistema). Una RP è un'estensione degli automi a stati finiti, con la differenza che: - i nodi non rappresentano più lo stato complessivo del sistema in un certo istante, ma lo stato è distribuito nei vari nodi del grafico, cioè nelle RP un nodo rappresenta solo uno stato parziale del sistema; - A differenza degli automi a stati finiti,

in cui può scattare una transazione per volta, nelle RP possono esistere più transazioni abilitate a scattare nello stesso istante.

Il formalismo grafico utilizzato è il seguente:

I nodi vengono chiamati POSTI e rappresentano gli stati parziali della rete, che sono "marcati" attraverso dei TOKEN, quindi lo stato complessivo del sistema in un certo momento è dato dalla marcatura dei token nei posti. Ad ogni arco può essere associato un peso, se non c'è nulla vuol dire di default che il peso vale 1. I rettangoli sono le TRANSAZIONI, cioè le modifiche che si possono apportare allo stato della rete.

Si definisce PRESET di una transazione l'insieme di nodi che hanno un arco in ingresso di una certa transazione (in genere si ha un preset per ogni transazione), mentre si definisce POSTSET di una transazione l'insieme di nodi che hanno un arco in uscita alla transazione.

Una transazione è abilitata a scattare, se nel

suo preset c'è un numero di token almeno pari al peso del suo arco. Quando scatta una transazione viene prodotta una nuova marcatura, che è tale per cui da ogni posto in ingresso alla transazione, viene rimosso un numero di token uguale al peso dell'arco che collega il posto alla transazione; in ogni posto in uscita alla transazione, saranno depositati tanti token quanto è il peso dell'arco che collega esso alla transazione. La rete evolve in modo non deterministico, cioè man mano i token si muoveranno, e ad un certo punto si potrà anche avere che più transazioni siano pronte a scattare; in tal caso solamente una a caso di esse sarà abilitata, e scatterà, cosa che comporterà un nuovo movimento di token, che potrebbe far sì che le transazioni che prima potevano scattare, ora non hanno più token a sufficienza per poterlo fare. Si dice che la RP è VIVA se esiste sempre una marcatura di partenza a

Partire dal quale, tutte le transazioni scattano almeno una volta. È possibile studiare il grado di vitalità.