5
1.1) Inquadramento del problema
Il nostro lavoro rientra pienamente in questo contesto e tratta in particolare la tematica
dell’analisi dei sistemi complessi o eterogenei, sistemi cioè composti da un numero elevato di
entità tra loro correlate e coordinate, ben individuabili e ciascuna con una determinata
funzionalità, dette componenti, che concorrono al raggiungimento dell’obiettivo per il quale
l’intero sistema è stato realizzato.
L’analisi di tali sistemi può avere innumerevoli finalità, tra le quali ricordiamo la valutazione
delle prestazioni, la verifica del comportamento funzionale, l’analisi dei guasti ecc., e può
essere effettuata con le tecniche e i metodi più disparati. Un possibile approccio, che
rappresenta l’ambito nel quale si è sviluppato il nostro lavoro, è costituito dall’utilizzo di
metodi formali, cioè linguaggi, tecniche e strumenti matematicamente fondati che si prestano
alla specifica e alla verifica dei sistemi ([2]).
Con il passare del tempo i sistemi in generale, e quelli informatici in particolare, hanno
mostrato la tendenza a diventare sempre più complessi, e si ritiene che tale aumento di
complessità non si arresterà, anzi diverrà sempre più forte ed evidente nel futuro.
Data la natura intrinseca dei sistemi, sia hardware che software, e riconosciuto questo trend, la
possibilità di occorrenza di errori o guasti difficili da prevedere non è trascurabile. Bisogna
inoltre sottolineare che, vista la sempre più diffusa tendenza ad adottare sistemi informatici o
automatici nelle applicazioni più disparate, e in particolare in quelle ad alta criticità, alcuni di
questi errori o guasti possono causare enormi perdite in termini di denaro, tempo o perfino di
vite umane.
Uno degli obiettivi principali dell’ingegneria informatica è quello di consentire ai progettisti
di costruire sistemi che funzionino in maniera corretta nonostante la complessità dei sistemi in
esame, e un modo per raggiungere tale obiettivo è l’utilizzo dei metodi formali. Ovviamente,
l’utilizzo di un metodo formale non garantisce a priori la correttezza del sistema studiato, ma
può aumentare in maniera significativa la nostra comprensione del sistema, rivelando
inconsistenze, ambiguità e incompletezze che viceversa resterebbero nascoste.
6
1.1.1) Modelli formali: pro e contro
Vale la pena di sottolineare, anche se dovrebbero essere chiari dalle considerazioni
precedenti, i motivi che spingono i progettisti all’uso dei metodi formali nell’analisi dei
sistemi complessi. Per sua stessa natura, un metodo formale permette la descrizione di un
sistema complesso eliminando le ambiguità che possono invece presentarsi in una descrizione
informale, e di conseguenza eliminando una possibile causa d’errore nella sintesi o
nell’analisi del sistema. L’utilizzo di un metodo formale consente di acquisire una
comprensione più profonda, precisa e dettagliata del sistema sotto esame, e inoltre rende più
semplice la possibilità della verifica e della dimostrazione rigorosa della correttezza di tale
sistema.
D’altra parte, c’è da dire che l’utilizzo dei metodi formali nella pratica è ancora fortemente
penalizzato da una serie di fattori: innanzitutto, è evidente che il prezzo da pagare per
l’introduzione di un metodo formalmente rigoroso è la necessità, da parte del modellista, di
avere solide conoscenze e capacità matematiche. I formalismi matematici, infatti, sono spesso
difficili da utilizzare e possono risultare ostici al neofita. Inoltre, le tecniche di soluzione
relative ad un determinato metodo formale diventano spesso difficili o addirittura impossibili
da utilizzare al crescere della complessità del sistema, di fatto vanificando la scelta
dell’utilizzo di tale metodo; a complicare le cose, può accadere che gli strumenti disponibili
non supportino alcune tecniche o siano troppo difficili da utilizzare. Infine, ed è questo il
problema che più ci interessa, data la complessità dei sistemi eterogenei, un singolo
formalismo non è, in genere, abbastanza espressivo per descrivere tutti gli aspetti desiderati
del sistema, e pertanto risulta difficile condurre delle analisi quantitative e qualitative
utilizzando un unico formalismo.
Per comprendere meglio alcuni dei concetti già presentati o che verranno presentati nel
seguito, appare conveniente introdurre come esempio un caso semplice di modello che ci
accompagnerà per tutta la trattazione
1
.
Il modello in questione rappresenta una ben nota politica di schedulazione, detta round robin,
attraverso la quale si assegna un generico carico di lavoro a dei serventi, in maniera alternata,
al fine di realizzarne una ripartizione adeguata.
1
Per un esempio più complesso e articolato, si rimanda al cap.6
7
In figura 1.1 vediamo una delle possibili rappresentazioni di tale politica, nel caso di due
serventi, attraverso il ben noto formalismo delle reti di Petri. Tale rete è composta dalle
transizioni “Arrival”, “ChooseServer1” e “ChooseServer2”, che rappresentano
rispettivamente gli eventi “arrivo di una richiesta di servizio”, “attribuzione del servizio al
servente 1” e “attribuzione del servizio al servente 2”. Sono inoltre presenti i posti
“WaitChoice”, “RRChoose1” e “RRChoose2” che rappresentano rispettivamente la presenza
o meno di una richiesta di servizio e la sua attribuzione ad uno dei due serventi, e i posti
“WaitServer1” e “WaitServer2” che rappresentano la presenza o meno di un servizio in atto
sul servente 1 o 2. Supponendo che la marcatura iniziale di tale rete preveda che il solo posto
“RRChoose1” possieda un token, allora allo scattare della transizione “Arrival” (innescata da
qualche altro evento non riportato nel modello) la richiesta di servizio sarà affidata a “Serv1”,
mentre un token andrà ad occupare il posto “RRChoose2”. In questo modo, alla prossima
richiesta di servizio, il servente che la accetterà sarà “Serv2”, e così via.
8
Figura 1.1 Politica round robin su due server, modellata con reti di Petri
Un modello di questo genere, magari arricchito di informazioni sulla frequenza di occorrenza
delle richieste di servizio, del tempo medio di servizio di ciascun servente, del tempo
necessario per far scattare una transizione, può risultare utile non solo a fini descrittivi e/o di
specifica, ma anche e soprattutto per la valutazione degli indici di performance del sistema.
Naturalmente, sarà cruciale la definizione di un modello adeguato per la descrizione dei due
serventi, che per ora sono rappresentati come delle black box.
9
1.2) Approcci emergenti nella modellazione formale
Viste le caratteristiche fondamentali, i pregi e i difetti dei metodi formali, è logico attendersi
lo sviluppo di tutta una serie di approcci e punti di vista differenti e/o alternativi rispetto a tali
metodi, dipendenti dal campo applicativo in cui si intende applicarli e dal tipo di problemi che
si vuole risolvere.
In particolare, presenteremo nel seguito due concetti che ricorreranno spesso nel nostro
lavoro, e che si sono rivelati molto promettenti rispetto alla necessità di superare alcuni limiti
dei metodi formali: nel paragrafo 1.3.1 verrà introdotto il concetto di multi-formalismo,
mentre nel paragrafo 1.3.2 verrà presentato l’approccio multi-soluzione. Cominciamo ad
anticipare che tali concetti, benché spesso ricorrenti in un’unica metodologia o strumento
orientato ai modelli formali, sono da considerarsi in un certo senso ortogonali.
1.2.1) Multi-formalismo
Abbiamo visto che l’analisi e la simulazione di sistemi complessi sono facilitate dalla
disponibilità di appropriati formalismi e strumenti di modellazione.
Strumenti come le reti di Petri (nelle varie versioni più o meno sofisticate), le catene di
Markov a tempo continuo e a tempo discreto, i Fault Trees, le reti di code e molti altri ancora
vengono utilizzati di continuo nelle più disparate realtà, da quelle più prettamente
informatiche all’ambito industriale e di processo, dal mondo delle telecomunicazioni a quello
della robotica.
Negli ultimi anni, tuttavia, si è venuto sempre più affacciando nel mondo scientifico il
concetto di multi-formalismo, dal momento che questo offre la possibilità di applicare il
metodo formale più adatto per modellare e analizzare diversi componenti o aspetti di un
sistema ([3]).
Abbiamo visto infatti che un sistema complesso solo raramente può essere modellato con un
unico formalismo, dal momento che spesso si rendono necessarie analisi relative ad aspetti
diversi del sistema in esame, e che inoltre diversi componenti possono essere modellati in
maniera più o meno adeguata da un certo formalismo.
10
Naturalmente, se l’adozione di un approccio che preveda la possibilità di utilizzare più
modelli formali distinti all’interno di un unico sistema da un lato risolve i problemi citati in
precedenza, dall’altro pone seri problemi circa la necessità di integrare in maniera sensata
elementi del modello che sono descritti in maniera completamente differente. In altre parole,
si pone il problema di definire una semantica per la composizione di sottomodelli descritti da
formalismi differenti, e di trovare dei meccanismi che consentano la soluzione del modello
complessivo.
Tornando all’esempio della politica di schedulazione round robin, immaginiamo che il
modello in questione debba essere utilizzato per la valutazione di alcuni indici di performance
relativi a ciascun servente.
Potrebbe pertanto risultare conveniente descrivere tali oggetti come delle reti di code costituiti
dalla cascata di due centri di servizio rappresentanti la CPU e il sistema dischi (fig.1.2), in
modo da valutare agevolmente delle grandezze come il throughput di ciascun servente, il
tempo medio di attesa in coda delle richieste di servizio, la dimensione media delle code ecc.
Si rende dunque necessario, pur mantenendo inalterata la struttura descritta dalla rete di Petri
per la descrizione della politica round robin, descrivere i due serventi attraverso un
formalismo differente come quello delle reti di code.
In un’altra situazione invece (fig.1.3) , potrebbe essere necessario valutare la probabilità di
occorrenza di un guasto nel sistema, e in tal caso risulterebbe più appropriato descrivere i due
serventi attraverso un altro formalismo, quello degli alberi di guasto o Fault Tree. In entrambi
i casi, o più in generale qualunque sia il formalismo utilizzato per descrivere i due serventi,
purché differente da quello delle reti di Petri, si rende necessaria la definizione di
un’opportuna semantica di integrazione che definisca il significato della connessione di
elementi appartenenti a formalismi diversi (come ad esempio un arco ed una coda).
11
Figura 1.2 Modello di server con formalismo QN
12
Figura 1.3 Un possibile albero di guasti per un server
13
1.2.2) Multi-soluzione
Mentre il multi-formalismo può essere visto come una risposta all’esigenza di scegliere il
metodo formale più adeguato per modellare parti diverse di un sistema, l’approccio multi-
soluzione viene incontro alla necessità di definire delle modalità e tecniche di soluzione
adeguate per un determinato sistema, a seconda delle particolari esigenze contingenti, delle
condizioni in cui si trova il modello del sistema durante una simulazione, del livello di
dettaglio e accuratezza richiesto, ecc..
Il concetto di multi-soluzione è stato introdotto per la prima volta da Sanders, il quale la
intendeva come la possibilità di definire più approcci diversi alla soluzione di un determinato
modello, tramite ad esempio la definizione di trasformazioni, decomposizioni, modifiche
successive del modello, prevedendo però generalmente l’utilizzo di un unico strumento
automatico, detto solver, per la soluzione del modello modificato.
Nel seguito noi estenderemo e amplieremo tale concetto, prevedendo la possibilità di
utilizzare anche più solver che cooperino in maniera orchestrata all’interno di un ambiente
integrato.
Nel nostro esempio, una possibile strategia potrebbe essere quella di trasformare,
possibilmente con strumenti automatici, i due sottomodelli che descrivono i serventi in reti di
Petri, ed utilizzare come solver del modello complessivo un tool orientato alla soluzione delle
reti di Petri. Un altro approccio possibile potrebbe essere la soluzione separata della rete di
Petri e dei due sottomodelli, che potrebbero essere a loro volta risolti con metodi diversi e
solver diversi, anche in dipendenza dei risultati parziali ottenuti.
14
1.3) Metodologie proposte
Nel campo della modellazione formale, e in particolare in quella rivolta a sistemi eterogenei,
esistono innumerevoli metodologie e strumenti che forniscono una propria risposta ai
problemi presentati, supportando in qualche misura il multi-formalismo e la multi-soluzione.
Ci limitiamo soltanto ad elencare, per il momento, ambienti e strumenti come SHARPE,
SMART, Möbius, AToM, DEDS e MoDeST, che verranno analizzati con maggior dettaglio
nel capitolo 2. Nel prossimo paragrafo invece, passeremo ad introdurre le caratteristiche
salienti del framework OsMoSys, nel quale si inserisce una parte del nostro lavoro, e che ha
costituito il punto di riferimento costante della nostra trattazione
1.3.1) OsMoSys
OsMoSys ([3], [4]) è una delle risposte alla necessità di specificare, analizzare e simulare un
sistema supportando il multi-formalismo e la multi-soluzione, e il principale obiettivo del suo
approccio alla modellazione è fornire all’utente uno strumento semplice e flessibile per
costruire modelli e librerie riutilizzabili di modelli. OsMoSys, a differenza di altri strumenti,
non dipende da nessun formalismo specifico, ma offre un’infrastruttura per l’integrazione e
l’interoperabilità che supporta la possibilità di definire nuovi formalismi e tecniche di
soluzione custom. L’approccio utilizzato nella modellazione è basato sul meta-modeling, che
permette di definire e integrare agevolmente differenti formalismi, e su alcuni concetti basilari
della metodologia object-oriented. Entrambe queste caratteristiche, che contraddistinguono
OsMoSys e lo rendono uno strumento interessante e originale per realizzare l’interoperabilità
tra modelli, sono descritte brevemente nei prossimi sottoparagrafi; una trattazione più
approfondita del framework OsMoSys è oggetto del capitolo 3 di questo lavoro.
1.3.1.1) Il meta-modeling in OsMoSys
Il meta-modeling è un approccio alla modellazione multi-formalismo che si è sviluppata
molto di recente, ed è basato su una struttura a tre livelli costituita da:
• Livello meta-metamodello
• Livello metamodello
15
• Livello modello
In sintesi, si può dire che al livello modello si descrive un’entità utilizzando uno specifico
formalismo, al livello metamodello vengono definiti i vari formalismi in modo che possano
descrivere i modelli del livello inferiore, mentre al livello meta-metamodello vengono definiti
dei linguaggi per descrivere i formalismi. In altre parole, l’idea è di definire un linguaggio che
possa descrivere molti diversi formalismi, che a loro volta possono essere usati per costruire
modelli di sistemi reali.
1.3.1.2) La metodologia ad oggetti in OsMoSys
L’altro aspetto chiave della metodologia OsMoSys è l’introduzione di una serie di concetti e il
supporto ad una serie di meccanismi tipici della metodologia Object-Oriented.
Con OsMoSys infatti è possibile definire delle classi di modelli, dette appunto Model Class,
che rappresentano ed incapsulano un insieme di modelli aventi la stessa struttura, ed è
possibile creare degli esemplari di tali classi di modelli, o Model Object, specificandone dei
parametri, esattamente come nella programmazione Object-Oriented è possibile definire delle
classi e istanziare degli oggetti appartenenti a questa classe.
Inoltre, così come nella metodologia ad oggetti classica, è possibile definire delle
aggregazioni e composizioni di modelli, anche a più livelli, favorendo il riuso di modelli già
presenti.
E’ definito inoltre il concetto di interfaccia, cioè un insieme di elementi e proprietà esposte da
un determinato modello e che ne specificano il comportamento esterno, senza entrare nei
dettagli della struttura interna.
E’ previsto infine il meccanismo dell’ereditarietà a livello di formalismo, cioè è possibile
definire dei formalismi derivati che ereditano gli elementi distintivi di formalismi base,
estendendoli a piacimento.
Se volessimo quindi descrivere il nostro sistema-esempio avvalendoci di OsMoSys,
costruiremmo il nostro modello nel formalismo PN (Petri Nets), già supportato allo stato
attuale e realizzato come metamodello ereditato da altri formalismi già definiti (cfr.
par.3.1.3.1 per i dettagli). Tale modello potrebbe essere incapsulato in una Model Class
(chiamata ad esempio “RoundRobin”) al fine di favorirne il riuso in tempi successivi, e
conterrebbe al suo interno dei Model Objects che descrivono la struttura interna dei
16
sottomodelli “Serv1” e “Serv2”. Supponendo di definire come interfaccia di questa Model
Class la transizione “Arrival” e come parametri il tempo associato alle transizioni
“ChooseServer1” e “ChooseServer2”, sarebbe possibile definire dei Model Object di tipo
“Round Robin” attribuendo dei valori a tali parametri, e collegare tale oggetto ad altri oggetti
in un modello più esteso tramite la transizione “Arrival”.
Figura 1.4 Definizione dell’interfaccia del modello RoundRobin
17
1.4) Il contributo di questo lavoro
Dopo aver introdotto brevemente il problema del quale ci stiamo occupando, le possibili
soluzioni e gli strumenti con cui risolverlo già esistenti allo stato attuale, nel presente
paragrafo illustreremo in maniera sintetica il contributo originale del nostro lavoro.
Nei prossimi sottoparagrafi vedremo come la necessità di aggiungere ulteriore potere
espressivo ai modelli formali ci porterà alla definizione e l’introduzione del concetto di
polimorfismo nei modelli, e mostreremo con un esempio pratico l’utilità di tale meccanismo.
Successivamente introdurremo il problema della creazione, a partire da un template generico
di modello di un sistema, di un esemplare concreto di tale template: si tratta in sostanza,
usando la terminologia di OsMoSys, del problema dell’istanziazione di un Model Object a
partire da una Model Class. Mostreremo inoltre in quali occasioni tale operazione si rende
necessaria e quali punti di contatto presenti con i concetti di binding e di polimorfismo.
1.4.1) Estendere l’espressività nei modelli: il polimorfismo
Nella programmazione tradizionale, ben presto si è riconosciuta l’esigenza di introdurre il
concetto di tipo di una variabile in un programma al fine di favorire la leggibilità, la
correttezza e l’ottimizzabilità del codice. Pertanto i linguaggi tradizionali, in maniera più o
meno rigida, prescrivevano, e prescrivono tuttora, la specificazione del tipo di una
determinata variabile o del valore restituito da una funzione. In un momento successivo, e in
misura maggiore con l’avvento della cosiddetta programmazione ad oggetti, si è presentato il
bisogno di una maggiore flessibilità del linguaggio rispetto alla specificazione del tipo, e in
particolare la necessità di poter definire delle funzioni che potessero essere definite
indipendentemente dal tipo di uno (o più) dei suoi argomenti. Nacque così il concetto di
funzione polimorfa e quindi di polimorfismo
2
.
Un’esigenza per molti versi simile è quella che si presenta nell’ambito della modellazione
formale, dove spesso un determinato modello presenta una struttura tipica, descrive un certo
2
In realtà il concetto di polimorfismo presenta molte differenti sfaccettature, ed è descritto in maniera più
dettagliata nel capitolo 4, e in particolare nel paragrafo 4.1
18
meccanismo hardware o software, o una certa funzionalità, indipendentemente dalla struttura
interna di uno o più suoi sottomodelli.
1.4.1.1) Necessità del polimorfismo nei modelli
Per quanto mostrato, e analogamente a quanto visto per la programmazione, può risultare
conveniente in molti casi disporre di strumenti di supporto che prevedano la possibilità di
definire, descrivere e simulare un modello polimorfo, cioè un modello in cui non viene
specificata in maniera statica la struttura interna dei sottomodelli, rispetto ai quali si vuol
mantenere un certo grado di flessibilità.
Le ragioni di tale esigenza sono molteplici: innanzitutto, con l’introduzione del polimorfismo
nei modelli si ha la possibilità di definire un modello anche quando i dettagli relativi
all’implementazione di un suo sottomodello per qualche motivo non sono ancora noti. Ciò
potrebbe avvenire perché l’implementazione concreta del sottomodello è dipendente da altri
fattori, come i risultati di una simulazione che saranno disponibili solo in un secondo
momento.
In secondo luogo, con la definizione di un modello polimorfo, si mette in luce in maniera
evidente quali sono le caratteristiche distintive del modello, e quali sono invece i dettagli
contingenti e in prima analisi trascurabili. Si pensi ad esempio ad un modello che definisce il
meccanismo di daisy chain: tale modello, se realizzato in maniera polimorfa, manterrà una
struttura di base costante che ne descrive l’essenza, indipendentemente da quali entità siano
effettivamente organizzate tramite questa particolare struttura.
Più in generale, con il polimorfismo nei modelli si offre un meccanismo col quale è possibile
offrire una maggiore flessibilità e possibilità di manovra al progettista, che già si trova a fare i
conti con innumerevoli altri vincoli di svariata natura.
Attraverso il meccanismo del polimorfismo dei modelli, sarà quindi possibile ad esempio
definire un modello “PolymorphicRoundRobin”, in tutto simile a quello visto prima per
quanto concerne la struttura, realizzata tramite una reti di Petri, che descrive il meccanismo
dell’alternanza dei job sui due serventi, ma con all’interno la presenza di pure interfacce che
specifichino solamente il comportamento esterno dei due server, senza alcun dettaglio sulla
struttura interna.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
