Da una descrizione UML ad un Modello di Simulazione completo

Transcript

Università di Pisa
Laurea Specialistica in
Ingegneria
dell’Automazione
Progetto di Controllo dei Processi
Da una descrizione UML ad un Modello di Simulazione
completo, realizzato in ambiente Matlab-Simulink
Studenti: Roberto Nicolino, Nicola Di Lecce
da una descrizione UML a un modello Matlab-Simulink
_________________________________________________________________________________________________________
ABSTRACT
Partendo da una analisi approfondita sulle potenzialità che oggi offre Unified Modeling
Language si mostra come questo linguaggio si ponga da tramite tra cliente e committente, per
evitare inutili incomprensioni e per permettere la realizzazione di un modello completo e
dettagliato di un sistema. Grazie ad UML è possibile realizzare simulazioni in ambiente Matlab
percorrendo un processo di integrazione completo tra le due piattaforme di sviluppo
2
_________________________________________________________________________________________________________
Indice
1. L’UNIFIED MODELING LANGUAGE
1.1 UML: che cosa è
p. 4
1.2 Perché utilizzare UML
p. 6
1.3 La genesi
p. 9
1.4 UML: come metamodello
p. 11
1.5 Sintassi astratta
p. 14
1.6 Gli strumenti di lavoro UML
p. 17
1.7 Componenti UML
p. 18
1.8 Il Class Diagram: approfondimenti
p. 21
1.9 Use Case Diagrams: specifiche
p. 34
1.10 State Diagrams
p. 42
1.11 Sequence Diagrams
p. 46
1.12 Deployment Diagrams
p. 63
2 LE S-FUNTIONS
2.1 Introduzione alle S-Functions
p. 69
2.2 Guida alla scrittura delle S-Functions
p. 74
2.3 Panoramica sulle Routines
p. 82
3 LO STATEFLOW MATLAB
3.1 Introduzione
p. 94
3.1 Stato
p. 96
3.2 Transizione
p. 97
3.3 Giunzione
p. 99
3.4 Eventi
p. 101
3.5 Dati
p. 101
4. DA UML A MATLAB: UN ESEMPIO
4.1 Introduzione
p. 102
4.2 Scelta di componenti e attrezzature per l’impianto
p. 103
4.3 Il Class Diagram
p. 118
3
_________________________________________________________________________________________________________
4.4 State Diagram
p. 120
4.5 Collaboration Diagram
p. 123
4.6 Sequence Diagram
p. 123
4.7 Stateflow: Statechart
p. 124
4.8 Riepilogo delle Regole di traduzione
p. 125
4.9 Sviluppi Futuri
p. 127
4
_________________________________________________________________________________________________________
1. L’UNIFIED MODELING LANGUAGE
1.1 UML: che cosa è
Lo Unified Modeling Language è un linguaggio per specificare, costruire, visualizzare e
documentare manufatti sia di sistemi software, che di altri sistemi non strettamente software.
UML rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella
modellazione di vasti e complessi sistemi. Lo UML permette di visualizzare, per mezzo di un
formalismo rigoroso, “manufatti” dell’ingegneria, consentendo di illustrare idee, decisioni
prese, e soluzioni adottate.
Tale linguaggio favorisce, inoltre, la divulgazione delle informazioni, in quanto standard
internazionale non legato alle singole imprese. In teoria, un qualunque tecnico, di qualsivoglia
nazionalità, dipendente della più ignota delle software house, con un minimo di conoscenza
dell’UML dovrebbe essere in grado di leggere il modello del progetto e di comprenderne ogni
particolare senza troppa fatica e, soprattutto, senza le ambiguità tipiche del linguaggio naturale.
Come al solito qualche problema può sempre emergere, ma si tratterebbe comunque di
problemi di poca entità. Un conto è non comprendere qualche particolare, un altro è non
comprendere assolutamente cosa voleva realizzare l’autore.
I vantaggi che derivano dal poter disporre di un modello del sistema sono notevoli e fin
troppo evidenti. Basti pensare alla non indifferente semplificazione del processo di
manutenzione che, da solo, tipicamente incide più del 50% nel ciclo di vita dei sistemi ben
progettati; alla possibilità di allocare risorse aggiuntive in corso d’opera, riducendo il rischio
che ciò diventi controproducente.
Disporre di un linguaggio per descrivere un sistema costringe il progettista stesso ad
analizzare, con maggior minuzia, aspetti del sistema anche di un certo rilievo, i quali,
viceversa, potrebbero incautamente venir trascurati da un’analisi non molto rigorosa.
Per ciò che concerne l’utilizzo dello UML nello “specificare”, bisogna tener presente che in
questo contesto l’espressione si riferisce alla possibilità di realizzare modelli completi, precisi e
non ambigui. Lo UML dispone di tutti i meccanismi necessari per la specifica di qualsiasi
particolare ritenuto rilevante in ogni fase del ciclo di vita del progetto e quindi, in ultima
analisi, per produrre modelli accurati.
Lo UML, permette di realizzare modelli che si prestano ad essere implementati con diversi
linguaggi di programmazione, sebbene risulti particolarmente efficace per la progettazione di
5
_________________________________________________________________________________________________________
sistemi Object Oriented. In effetti è possibile realizzare un mapping esplicito tra un modello
UML e un linguaggio di programmazione. Chiaramente, tale legame risulta più immediato per i
linguaggi fortemente basati sul paradigma Object Oriented, quali C++, Java, Small-Talk, Ada,
e così via.
Gli stadi evolutivi attraverso cui si sono sviluppate le metodologie per la realizzazione del
software orientato agli oggetti si basano su:
•
Utilizzo dei primi linguaggi di programmazione orientati agli oggetti;
•
Sviluppo di tecniche di analisi e progettazione orientate agli oggetti per aiutare la
modellazione dei sistemi commerciali, l’analisi dei requisiti e la progettazione di
sistemi software. Il numero di queste tecniche cresce rapidamente;
•
Nascita dell’UML, progettato per combinare tra loro i vantaggi delle numerose
notazioni e tecniche di analisi e progettazione, così da ottenere uno standard a
livello industriale.
Sul mercato sono presenti diversistrumenti, in grado di generare codice a partire dal relativo
modello, sia interattivamente durante la fase di disegno, sia su richiesta. L’esistenza di queste
funzionalità, sebbene ancora non del tutto mature, dovrebbe far capire che l’implementazione è
veramente un particolare del disegno, specie con linguaggi come Java.
La generazione automatica di una prima implementazione del sistema risulta
particolarmente utile quando il modello deve essere realizzato parallelamente (cioè sempre!),
poiché fornisce, ai diversi sviluppatori, lo scheletro — eventualmente con qualche metodo
implementato — delle classi fondamentali del sistema che dovrebbero presentare un’interfaccia
stabile e ben definita.
Sebbene alcuni strumenti tentino, in alcuni casi particolari, di realizzare determinati metodi
con il codice appropriato, è probabilmente ancora un po’ prematuro azzardarsi a utilizzare
appieno tale funzionalità, a meno che non si tratti di meri metodi get / set di proprietà.
Il mapping tra modello e linguaggio di programmazione permette anche la realizzazione di
funzioni di reverse engineering: fornendo a un opportuno tool i codici sorgenti o, talune volte
anche quelli compilati, questo è in grado di ricostruire a ritroso il modello fino, ovviamente,
alla fase di disegno. Purtroppo non si è ancora riusciti a realizzare un tool in grado di ricostruire
i requisiti del cliente.
Il processo diretto (engineering) e quello inverso (reverse engineering) determinano quello
che in gergo viene definito round-trip engineering. Nel mondo ideale, la funzione di reverse
6
_________________________________________________________________________________________________________
non dovrebbe mai venir utilizzata, in quello reale è invece molto apprezzata, e tutto dipende
dall’uso che se ne fa.
In fase di disegno, probabilmente non è opportuno descrivere tutto dettagliatamente;
verosimilmente è opportuno lasciare qualche margine ai programmatori (tutto in funzione delle
loro capacità). Sono ritenute assolutamente naturali e accettabili modifiche del modello in fase
di codifica, fintantoché queste non stravolgano il modello stesso. Durante la fase di codifica
può anche accadere di accorgersi che una data libreria non funziona come dovrebbe, o che c’è
qualche lacuna nel modello, o che risulta opportuno cambiare qualche strategia al fine di
ottenere un codice più efficiente. Tutto ciò è normalissimo. Tuttavia, nell’eventualità che le
modifiche
generino
uno
stravolgimento
del
modello,
piuttosto
che
procedere
nell’implementazione sarebbe forse necessario introdurre un’opportuna iterazione della fase di
disegno e successiva codifica.
Un progetto, per quanto ben congegnato, potrebbe perdere gran parte del suo fascino se
poco documentato, o addirittura potrebbe finire per non essere compreso e in futuro non venire
correttamente aggiornato.
Per terminare, lo UML fornisce sia dei meccanismi molto formali, sia del testo libero da
aggiungere, ogni qual volta lo si ritenga necessario, a parti ritenute poco chiare o
particolarmente complesse, al fine di aumentarne il livello di particolare.
1.2 Perché utilizzare UML
Ogni qualvolta, in una disciplina dell’ingegneria, vi sia la necessità di realizzare un
“manufatto”, indipendentemente dalla dimensione e dal settore di interesse (una casa, un
grattacielo, un particolare meccanismo, un ponte, un dipartimento di un’azienda, e così via) si
procede cercando di realizzarne un modello.
L’obiettivo è produrre, in tempi relativamente brevi e soprattutto a costi contenuti, una
versione razionalizzata e semplificata del sistema reale che, tuttavia, consenta di evidenziarne
l’aspetto finale e di studiarne prestazioni, affidabilità e comportamento.
I modelli, importantissimi in tutti i processi di sviluppo, trovano la loro più completa
legittimazione nell’ambito di sistemi di dimensioni medie e grandi. In tali circostanze la
complessità di questi sistemi nella loro interezza ne rende molto difficoltosa la comprensione. È
quindi maggiormente avvertita la necessità di avvalersi di modelli in grado di descrivere, in
maniera semplificata, sistemi comunque complessi.
7
_________________________________________________________________________________________________________
Si vedrà come lo UML, grazie alla sua organizzazione in “viste” (Views), risponda alla
logica necessità della mente umana di concentrarsi, in ogni istante, su un numero limitato di
aspetti del sistema ritenuti importanti per la particolare fase del processo di sviluppo,
rimandando a momenti successivi l’analisi degli aspetti rilevanti per le altre viste.
Figura 1.1: La vignetta dell’altalena
Oltre ai motivi già citati, i modelli sono basilari poiché, avvalendosi anche del feedback
fornito dai committenti, permettono di definire i requisiti del sistema in maniera chiara e, con la
cooperazione del proprio gruppo, di razionalizzarne il processo di sviluppo. I vantaggi che se
ne ricavano sono diversi: adeguate analisi dei tempi, migliori stime dei costi, piani più precisi
di allocazione delle risorse, distribuzioni più affidabili del carico di lavoro.
Si riesce quindi a risparmiare tempo e denaro, a ridurre i fattori di rischio presenti in ogni
progetto, a studiare la risposta del sistema a particolari sollecitazioni, e via di seguito.
Nonostante però il grande valore apportato all’ingegneria del software dall’utilizzo della
modellazione, troppo spesso in molte organizzazioni questa meravigliosa tecnica rimane
ancora una chimera.
8
_________________________________________________________________________________________________________
A nessuno appartenente al settore dell’ingegneria edile verrebbe in mente di costruire
interamente un grattacielo, per poi studiarne la risposta a sollecitazioni di carattere sismico. Il
buon senso, risorsa purtroppo sempre rara, suggerisce di procedere con la realizzazione di una
versione miniaturizzata sulla quale condurre tutti gli studi del caso.
Non necessariamente un processo di modellazione genera un oggetto tangibile: talvolta si
tenta di rappresentare un complesso reale per mezzo di eleganti sistemi di disequazioni e quindi
l’intero modello si risolve in una raffinata astrazione.
Tutto ciò che è fin troppo scontato in molte discipline dell’ingegneria non lo è nel settore
dell’Informatica o dell’Automazione, ad essa strettamente connessa. In molte organizzazioni la
produzione del software è ancora un’attività, per così dire, “artigianale” in cui il relativo
processo di sviluppo prevede tre fasi: analisi dei requisiti, implementazione e test..
Si provi a immaginare che cosa potrebbe accadere se si avviasse la progettazione di un
ponte a partire da specifiche sommarie, magari comunicate verbalmente o, peggio ancora, se si
partisse subito a costruirlo materialmente, magari affidandosi all’esperienza di qualche
costruttore (vedi figura 1.1). Inconcepibile! Tutto ciò, benché possa sembrare “fuori dal
mondo”, molto spesso è prassi comune nel mondo dell’ingegneria informatica. Malgrado siano
stati versati fiumi d’inchiostro sull’argomento, e svariati gruppi di ricerca lavorino a tempo
pieno per la definizione di nuovi standard di analisi, in molte organizzazioni, soprattutto
italiane, anche di “comprovato” prestigio, tale attività è ancora considerata prettamente
accademica, vezzo di giovani neolaureati perché, in ultima analisi, è di scarsa utilità nel
mondo reale, dove l’obiettivo è produrre codice e l’esperienza è in grado di sopperire a tutto.
L’inevitabile risultato è che spesso si procede cominciando paradossalmente da una delle
ultime fasi del processo di ingegnerizzazione, ossia dalla stesura del codice (paragonabile alla
costruzione del ponte di cui si parlava nell’esempio).
Si inizia concentrandosi prematuramente sul modo in cui redigere il codice ed,
eventualmente, alla fine si scrivono “due righe di analisi”, magari demandando il tedioso
incarico all’ultimo arrivato nel team.
In molte occasioni può accadere che, a progetto “ultimato e pronto per la consegna”, ci si
accorga dell’errata architettura. Non è da escludere, nel peggiore dei casi, che, per via di uno
sviluppo interamente incentrato sulla fase di codifica, e quindi privo della visione globale che
solo un buon processo di modellazione può apportare, sia praticamente impossibile integrare i
moduli prodotti in parallelo o che sia necessario costruire estemporanei moduli di interfaccia o,
ancora, che il sistema preveda percorsi così tortuosi da renderlo praticamente inutilizzabile.
9
_________________________________________________________________________________________________________
Per terminare, sintetizzando al massimo il concetto si può dire che si modella
essenzialmente per due motivi:
•
aumentare la propria comprensione sia di un problema sia di eventuali soluzioni
ipotizzate;
•
comunicare.
1.3 La genesi
Originariamente il lavoro fu iniziato da Grady Booch e James Rumbaugh, con l’intento di
produrre un nuovo metodo, detto “metodo unificato” che raccogliesse il meglio dei metodi
Booch e OMT-2, del quale Rumbaugh era stato uno dei principali promotori. Nel 1995 si unì a
loro Ivar Jacobson, fautore del metodo denominato OOSE (Object Oriented Software
Engineering): il terzetto si era così costituito. L’azienda che promuove il progetto è la Rational
Software Corporation che, dal canto suo, provvede anche ad assorbire la Objective Systems,
azienda svedese che aveva sviluppato e distribuito il software Objectory. A questo punto il
quadro era completo e lo standard in lavorazione fu ribattezzato Unified Modeling Language.
La prima versione, la celebre 1.0, fu disponibile nel gennaio 1997.
L’UML è uno strumento di analisi molto versatile, nato per risolvere le problematiche
connesse con la progettazione Object Oriented del software, ma che ben si adatta a essere
utilizzato negli ambienti più disparati. Esso è stato, per esempio, utilizzato alla Cadence per la
produzione di un dispositivo di compressione vocale operante a livello di porta fisica. Ancora,
una delle aziende fornitrici della US Navy ha utilizzato lo UML come linguaggio di
progettazione di un sistema d’arma di nuova generazione. Un’azienda sanitaria si è avvalsa
dello UML nella realizzazione di un modello per il trattamento dei pazienti, e così via.
Visto l’enorme successo riscosso nell’applicazione industriale e nel mondo accademico e
considerato il relativo riconoscimento a livello di standard (UML 1.0 è stato proposto
all’Object Managment Group nel gennaio 1997), gli stessi ideatori dichiararono ormai conclusa
la loro esperienza in questo ambito tanto da dedicarsi a nuove sfide. Allo stato attuale lo
sviluppo dell’UML è affidato a una task force appartenente all’OMG, la famosa RTF (Revision
Task Force), diretta da Chris Kobyrn. Obiettivo di tale gruppo è accogliere e analizzare
suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni (bugs) e colmare
eventuali lacune.
10
_________________________________________________________________________________________________________
Attualmente dovrebbe essere già disponibile le versione 2.0. L’evoluzione dello UML è
mostrata in fig. 1.2, attraverso il diagramma dei componenti, uno degli strumenti messi a
disposizione dal linguaggio.
11
_________________________________________________________________________________________________________
1.4 UML: come metamodello
Lo UML è un linguaggio che permette di costruire un modello di un sistema da analizzare o
da progettare, ovvero permette di realizzare una rappresentazione astratta di un sistema basata
su alcuni concetti fondamentali, come classi e associazioni.
I concetti base dello UML vengono usati anche per descrivere la semantica del linguaggio
stesso. Si ha quindi un modello per un linguaggio di modellazione, cioè un metamodello. Ad
esempio si possono consultare i diagrammi delle figure 1.3 – 1.4 che descrivono la struttura
principale del linguaggio UML, cioè la parte principale del suo metamodello.
Quindi nasce il problema di rendere standard la definizione di altri linguaggi di
modellazione, ognuno dei quali avrà il suo metamodello. Tra i metodologi si è ritenuto
opportuno definire un linguaggio comune denominato MOF (Meta Object Facility) [MOFS]
per descrivere diversi metamodelli attraverso dei meta-metamodelli (ad esempio XMI, che è il
formato standard di scambio di modelli tra applicazioni di diverse piattaforme, è definito
attraverso MOF).
Lo UML possiede una definizione rigorosa di metamodello, istanza del meta-metamodello
definito anch’esso attraverso il MOF. Si tratta di concetti molto eleganti e affascinanti, ad
elevato livello di astrazione. Il metamodello dello UML è descritto per mezzo dello UML
stesso. Si tratta indubbiamente di una scelta molto elegante, ma ha per inconveniente che ad
una prima lettura della specifica si può avere una certa confusione.
Un metamodello è un modello a sua volta istanza di un meta-metamodello, fruibile per
esprimere una istanza di modello: l’UML (metamodello) permette di realizzare diversi modelli
Object-Oriented (modelli definiti dall’utente). Il metamodello dello UML definisce la struttura
dei modelli UML. Un metamodello non fornisce alcuna regola su come esprimere concetti del
mondo Object-Oriented, quali ad esempio classi, interfacce, relazioni e così via, ma esso rende
possibile avere diverse notazioni che si conformano al metamodello stesso.
Così come avviene nella relazione che lega le classi agli oggetti, una volta definita una
classe si possono avere svariate istanze della stessa (oggetti), analogamente è possibile
progettare un numero infinito di varianti dello “UML” (istanze del metamodello).
Nelle sue prime apparizioni ufficiali lo UML era composto “semplicemente” da una
notazione grafica, fruibile per rappresentare modelli di sistemi Object-Oriented. Quando poi è
giunto il momento della presentazione allo OMG, per il conferimento del riconoscimento
ufficiale di standard (Gennaio 1997), si è reso necessario conferirgli una veste più formale.
12
_________________________________________________________________________________________________________
Così, a partire dalla versione 1.1, lo UML definisce rigorosamente un metamodello e la
notazione atta alla formulazione di modelli Object-Oriented conformi ad esso.
Riassumendo, un meta-metamodello è un modello che definisce un linguaggio per
esprimere un metamodello. La relazione tra il meta-metamodello ed il metamodello è
paragonabile a quella esistente tra il metamodello ed un modello.
Figura 1.3: Meta-metamodello, metamodello e modello UML
Lo UML è definito in termini del meta-metamodello denominato MOF: Meta Object
Facility [MOFS]. Nella figura 1.3 viene illustrato graficamente quanto emerso fino a questo
punto: relazioni esistenti tra il meta-metamodello, il metamodello ed il modello dell’utente.
Scorrendo il diagramma dall’alto verso il basso si assiste ad una graduale diminuzione del
livello di astrazione; se si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate
entità, istanze delle classi del modello dell’utente, cioè oggetti.
Se, per esempio, si realizzasse un prototipo di un sistema di commercio elettronico, a livello
del modello realizzato dall’architetto, si troverebbero classi (opportunamente relazionate tra
loro) del tipo: Categoria, SottoCategoria, Prodotto, Utente, Profilo, e così via. Se poi si volesse
13
_________________________________________________________________________________________________________
visualizzare il livello inferiore, l’istanza dello user model, bisognerebbe inserire oggetti, istanze
di tali classi, come per esempio il prodotto di codice X, avente prezzo Y, della categoria Z. Per
avere un’idea più chiara si consulti il diagramma riportato nella figura 1.4.
Figura 1.4: Esempio delle relazioni ai vari gradi di astrazione tra i modelli UML
Come si può notare, nel modello di analisi compare una classe denominata “Ordine”
appartenente al dominio del problema. La classe è un’istanza della metaclasse Class, presente
nel package UML metamodello, e contiene attributi ed operazioni che, a loro volta, sono
istanze rispettivamente delle metaclassi Attribute ed Operation. Se anche in questo caso si fosse
deciso di visualizzare un ulteriore livello si sarebbero trovate le istanze delle classe Ordine,
ossia oggetti del tipo ordine.
14
_________________________________________________________________________________________________________
Appare che il livello di meta-metamodello ha la stessa struttura del livello di metamodello:
questo fatto è causato dalla stretta relazione che c’è fra MOF e UML. Infatti, a quanto si legge
nella specifica ufficiale di OMG (“Meta Object Facility (MOF) Specification” [MOFS]), si
potrebbe avere in futuro una fusione tra i meta-metamodelli di MOF e il metamodello di UML:
nel frattempo rimangono due entità distinte.
In sintesi, lo UML è basato su un metamodello integrato, composto da numerosi elementi
collegati fra loro secondo regole precise. Utilizzando gli elementi del metamodello è possibile
creare i modelli per i sistemi da rappresentare e la maggior parte degli elementi stessi hanno
un’icona definita dalla notazione dello UML che li rappresenta graficamente. Gli elementi del
metamodello possono comparire in diagrammi di diverso tipo e le regole sintattiche permettono
di verificare la correttezza.
1.5 Sintassi astratta
La sintassi astratta viene definita utilizzando la notazione dei meta-modelli. Si tratta di un
sottoinsieme della notazione UML che utilizza il diagramma delle classi per definire gli
elementi dei modelli UML e le relazioni che intercorrono tra loro. La figura 1.5, di seguito
riportata, mostra un frammento del diagramma che definisce la sintassi astratta di UML.
UML specification permette la definizione di un metodo, dei sui attributi e delle sue
associazioni anche in linguaggio naturale. Questo diagramma mostra che Operazione e Metodo
sono meta-classi, entrambe sottoclassi della meta-classe astratta ProprietàComportamentale, e
che Operazione è una specifica di Metodo. Mentre un’Operazione possiede un attributo
specifica, un Metodo ha solo come attributo un corpo: la specifica nella meta-classe Operazione
è una stringa che definisce il prototipo (signature) dell’operazione (il suo valore di ritorno,
nome e parametri).
15
_________________________________________________________________________________________________________
ProprietàComportamentale
Query: boolean
Operazione
Metodo
Concorrenza: CallConcurrencyKind
Radice: boolean
Foglia: boolean
Astratto: boolean
Specifica: String
1
+specifica
*
Corpo: ProcedureExpression
Figura 1.5: Frammento della sintassi astratta di UML
Il corpo nella meta-classe Metodo è una procedura, probabilmente scritta in un linguaggio di
programmazione, che definisce come il metodo implementa l’operazione. Una determinata
istanza di un’operazione in una classe è un’istanza della meta-classe Operazione.
Metodo
Un metodo è l’implementazione di un’operazione, esso descrive l’algoritmo o la procedura
che genera i risultati di un’operazione. Nel meta-modello, un Metodo è una dichiarazione di un
comportamento ben specifico in un Classificatore e realizza una (quindi direttamente) o un
insieme (allora indirettamente) di Operazioni del Classificatore.
Attributi
Corpo – L’implementazione del Metodo come ProcedureExpression.
Associazioni
Specifica – Indica un’Operazione implementata dal Metodo. L’Operazione deve essere
contenuta nel Classificatore che possiede il Metodo o essere ereditata da esso. Le signature
dell’Operazione e del Metodo devono corrispondere.
Esiste un’analoga specifica per Operazione e per ogni altra meta-classe del meta-modello.
16
_________________________________________________________________________________________________________
Regole sintattiche
Le regole sintattiche che generano espressioni ben formate si applicano a istanze delle
meta-classi, ossia ad operazioni, metodi, classi e tutto ciò che si trova a livello del modello.
Esse forniscono le regole cui devono obbedire le istanze delle meta-classi, come un insieme di
invarianti. Gli invarianti sono vincoli che non possono essere spezzati: devono sempre risultare
veri perché il modello abbia significato. Sono descritti in Object Constraint Language (OCL).
Ad esempio, la specifica della meta-classe Class afferma che se la classe è concreta (non
astratta), allora ogni operazione dovrebbe avere un metodo che la realizza. Il vincolo seguente è
scritto in OCL.
Not
self.Astratto
implies
self.ogniOperazione
->
perOgni
(op
|
self.ogniMetodo -> esiste (m | m.specifica -> include (op)))
Questi vincoli sul meta-modello possono essere utilizzati per verificare che il modello si
attenga alle regole di UML e sia ben formato. Si noti che OCL viene utilizzato all’interno di
UML per esprimere vincoli interni al modello.
Per esempio, se una delle regola di un sistema per condividere i viaggi, prevede che ogni
viaggio legato da un contratto di condivisione deve essere svolto da un diverso Car Sharer
(persona che condivide la propria macchina), questo potrebbe essere espresso in OCL nel
seguente modo:
context ContrattoCondivisione inv:
self.Condiviso->forAll (i, j | (i.viaggia = j.viaggia)
implies i = j)
In italiano, questo significa che nel contesto della classe ContrattoCondivisione c'è una
regola invariante definita come segue: se si prende ogni possibile coppia di collegamenti tra
un'istanza di ContrattoCondivisione e istanze di Viaggio basate sull’associazione Condiviso, e
per ogni membro della coppia si segue il collegamento basato sull'associazione viaggia fino a
un'istanza della classe Car Sharer e se tali collegamenti sono gli stessi, anche i due viaggi sono
uguali. E dato che i due viaggi sono in realtà lo stesso viaggio, ne deriva che due diversi viaggi
appartenenti allo stesso Car Sharer non possono essere condivisi all'interno dello stesso
accordo di condivisione.
17
_________________________________________________________________________________________________________
Semantica
La semantica di UML è descritta in linguaggio naturale. Per esempio, quella che segue è la
descrizione della meta-classe Operazione (vedi figura 1.5).
“Un’Operazione è un costrutto concettuale, mentre il Metodo è il costrutto per
l’implementazione. Le loro caratteristiche comuni, come possedere una segnature, sono
espresse rispettivamente nella meta-classe ProprietàComportamentale e nella semantica
specifica dell’Operazione. I costrutti del Metodo sono definiti nella corrispondente sottoclasse
di ProprietàComportamentale”.
Tuttavia la maggior parte delle informazioni relative alle operazioni si trova nella
definizione di Classe. La comprensione completa della semantica richiederebbe la lettura
approfondita di tutta questa parte.
1.6 Gli strumenti di lavoro UML
Come ogni linguaggio che si rispetti anche l'UML necessita di tools appropriati che ne
agevolino l'utilizzo. Servirsi di carta e penna è sicuramente sempre valido ma non può
certamente garantire da solo un risultato apprezzabile. Ci sono sul mercato tanti tools che
trattano l'UML. Probabilmente, però, il più diffuso è lo strumento della Rational, Il Rose. Il
Rational Rose è stato disegnato per fornire ai team di sviluppo tutti gli strumenti necessari per il
modellamento di soluzioni robuste ed efficienti.
La Microsoft ha prodotto uno strumento che permette di definire un sottoinsieme dei
modelli che il Rational Rose mette a disposizione: il Microsoft Visual Modeler. Tale software
si può consigliare a chi si avvicina per la prima volta al mondo del Visual Modeling. Il
Microsoft Visual Modeler permette, tra l'altro, di:
•
Identificare e disegnare oggetti del business e mapparli in componenti software;
•
Descrivere come i componenti possono essere distribuiti su una rete;
•
Generare codice base Visual Basic direttamente dalla costruzione del modello;
•
Utilizzare il reverse engineering per creare i modelli da applicazioni già esistenti.
18
_________________________________________________________________________________________________________
Altro strumento da segnalare è UMLet, un software open source basato su Java che permette
la scrittura di diagrammi UML. Tra le opzioni, la possibilità di esportare i diagrammi in SVG,
JPG e PDF.
1.7 Componenti UML
Il linguaggio UML contiene svariati elementi grafici che vengono messi insieme durante la
creazione dei diagrammi. Dato che l'UML è un linguaggio, come tale utilizza delle regole per
combinare i componenti nella creazione dei diagrammi.
L'obiettivo dei diagrammi è quello di costruire molteplici viste di un sistema tutte correlate
tra di loro. L'insieme di tali viste costituirà quello che abbiamo definito Visual Modeling. Si
passano ora in rassegna, brevemente, tutti i diagrammi UML prima di analizzarli più
dettagliatamente in seguito.
La notazione UML include dieci tipi di diagrammi, divisi in cinque categorie. Si tenga
presente che è assolutamente possibile costruire e aggiungere dei diagrammi differenti dagli
standard (che vengono definiti ibridi) rispetto a quelli definiti dal linguaggio. La tabella 1.1
mostra le categorie e i diagrammi corrispondenti.
Tabella 1.1: Classificazione dei diagrammi UML
19
_________________________________________________________________________________________________________
Class Diagram
Per avere una idea immediata di cosa sia una classe è possibile usare come esempio il fatto
che tutti gli oggetti o esseri viventi, spesso, sono riconducibili a determinate categorie
(computers, automobili, piante, animali). Queste categorie costituiscono le classi. Una classe è
una categoria o un gruppo di oggetti (con questo termine si includono, per comodità anche gli
esseri viventi) che hanno attributi simili e comportamenti analoghi. I Class Diagrams
forniscono le rappresentazioni utilizzate dagli sviluppatori.
Object Diagram
Un oggetto è una istanza di una classe, ovvero una qualcosa di specifico che ha dei valori
determinati per i suoi attributi e dei comportamenti specifici.
Use Case Diagram
Uno Use Case (caso d'uso) è una descrizione di un comportamento particolare di un
sistema dal punto di vista dell'utente. Per gli sviluppatori, gli use case diagram rappresentano
uno strumento notevole: infatti tramite tali diagrammi, essi possono agevolmente ottenere una
idea chiara dei requisiti del sistema dal punto di vista utente e quindi scrivere il codice senza
timore di non aver recepito bene lo scopo finale. Nella rappresentazione grafica, viene
utilizzato un simbolo particolare per l'actor (l'utente o un altro sistema che interagisce) che si
vedrà in seguito.
L'actor è l'entità che interagisce con uno use case facendo partire la sequenza di azioni
descritte dallo use case stesso e, eventualmente, ricevendo delle precise risposte dal sistema.
Può essere una persona o anche un altro sistema.
State Diagram
Ad un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un
particolare stato. Gli State Diagrams rappresentano tali stati, ed i loro cambiamenti nel tempo.
Ogni state diagram inizia con un simbolo che identifica lo stato iniziale (Start State) e termina
con un altro simbolo che rappresenta lo stato finale (End State). Per esempio, ogni persona può
essere identificato dai seguenti stati: neonato, bambino, adolescente, adulto, anziano.
20
_________________________________________________________________________________________________________
Sequenze Diagram
I class diagrams e gli object diagrams rappresentano informazione statica. In un sistema
funzionante, tuttavia, gli oggetti interagiscono l'uno con l'altro, e queste interazioni avvengono
in relazione al trascorrere del tempo. Il sequence diagram mostra le dinamiche, basate sul
tempo, delle varie interazioni tra gli oggetti.
Activity Diagram
Le attività che si riscontrano all'interno di use case o all'interno del comportamento di un
oggetto accadono, tipicamente, in una sequenza ben definita. Tale sequenza si rappresentata
con gli activity diagrams.
Collaboration Diagram
Gli elementi di un sistema lavorano insieme per realizzare e soddisfare le necessità del
sistema. Un linguaggio di modellazione deve avere un modo per rappresentare tale
cooperazione. Il Collaboration Diagram nasce proprio per questa ragione.
Component Diagram
Oggi, nell'ingegneria del software si utilizza sempre più il modello di organizzazione
secondo il quale ognuno nel team di lavoro lavora su un componente differente. Il component
diagram descrive questa importante caratteristica.
Deployment Diagram
Il Deployment Diagram mostra l'architettura dal punto di vista fisico e logistico di un
sistema. Tale diagramma può descrivere i vari dispositivi presenti, mostrare le varie
connessioni che intercorrono tra di essi e, ancora, il software che è installato su ogni macchina.
Una domanda che ci si potrebbe porre a questo punto è la seguente: Ma è proprio
necessario sviluppare tutti i diagrammi che l'UML mette a disposizione ?
La risposta a questa domanda può variare in relazione alla complessità del Sistema che si
intende costruire ma, in linea di massima, tende ad essere affermativa. La ragione di ciò
consiste nel fatto che i diagrammi UML sono stati pensati per venire incontro all'esigenza di
rendere il Sistema comprensibile da differenti persone con differenti figure professionali.
Probabilmente, ad esempio, un commerciale non trarrà una particolare impressione leggendo
21
_________________________________________________________________________________________________________
un Class Diagram ma potrà, certamente, avere le idee più chiare analizzando uno Use Case
Diagram.
1.8 Il Class Diagram: approfondimenti
Si è detto precedentemente che gli oggetti possono essere suddivisi in categorie e, quindi, in
classi.
Il Class Diagram del linguaggio UML consiste di svariate classi connesse tra di loro
tramite delle relazioni. Prima di tutto, però, è importante definire graficamente una classe in
UML.
Una classe viene rappresentata da un rettangolo (fig. 1.7). Il nome della classe, per
convenzione, è una parola con l'iniziale maiuscola ed appare vicino alla sommità del rettangolo.
Se il nome della classe definita consiste di una parola composta a sua volta da più parole allora
viene utilizzata una notazione in cui tutte le iniziali di ogni parola sono scritte in maiuscolo.
Figura 1.6: La classe
Definizione generica di una classe
Un Attributo rappresenta una proprietà di una classe. Esso descrive un insieme di valori
che la proprietà può avere quando vengono istanziati oggetti di quella determinata classe. Una
classe può avere zero o più attributi.
Un attributo il cui nome è costituito da una sola parola viene scritto sempre in caratteri
minuscoli. Se, invece, il nome dell'attributo consiste di più parole (es: Informazioni-Cliente)
allora il nome dell'attributo si scriverà unendo tutte le parole che ne costituiscono il nome
stesso con la particolarità che la prima parola verrà scritta in minuscolo mentre le successive
avranno la loro prima lettera in maiuscolo. Nell'esempio visto l'attributo sarà identificato dal
termine: informazioniCliente. La lista degli attributi di una classe viene separata graficamente
dal nome della classe a cui appartiene tramite una linea orizzontale.
22
_________________________________________________________________________________________________________
Nell'icona della classe, come si vede nella figura precedente, è possibile specificare un tipo
in relazione ad ogni attributo (string, float, int, bool). E' anche possibile specificare un valore di
default che un attributo può avere (fig. 1.7).
Figura 1.7: Attributi
Un'Operazione è un'azione che gli oggetti di una certa classe possono compiere;
analogamente al nome degli attributi, il nome di un'operazione viene scritto con caratteri
minuscoli. Anche qui, se il nome dell'operazione consiste di più parole, allora tali parole si
uniscono tra di loro ed ognuna di esse, eccetto la prima, viene scritta con il primo carattere
maiuscolo. La lista delle operazioni (metodi) viene rappresentata graficamente sotto la lista
degli attributi e separata da questa tramite una linea orizzontale come da figura 1.8. Anche I
metodi possono avere delle informazioni addizionali. Nelle parentesi che seguono il nome di
un'operazione, infatti, è possibile mostrare gli eventuali parametri necessari al metodo insieme
al loro tipo. Infine, se il metodo rappresenta una funzione è necessario anche specificare il tipo
restituito.
Figura 1.8: Vista completa di una classe
Altre informazioni addizionali che possono essere unite agli attributi di una classe sono le
Constraints e le Note. Le Constraints sono delle caselle di testo racchiuse tra parentesi.
All'interno delle parentesi viene specificata una o più regole che la classe è tenuta a seguire
obbligatoriamente.
23
_________________________________________________________________________________________________________
Le Note solitamente sono associate con gli attributi e/o con i metodi. Esse forniscono una
informazione aggiuntiva ad una classe. Una nota può contenere sia elementi grafici che
elementi di testo. Come si può riuscire a discernere le classi da utilizzare dalla intervista con il
cliente ?
E' necessario, a tal fine, prestare particolare attenzione ai nomi che i clienti usano per
descrivere le entità del loro business. Tali nomi saranno ottimi candidati per diventare delle
classi nel modello UML. Si deve stare, altresì, attenti ai verbi che vengono pronunciati dai
clienti. Questi costituiranno, con molta probabilità, i metodi (le operazioni) nelle classi definite.
Gli attributi di una classe verranno stabiliti con le analoghe modalità utilizzate per i nomi delle
classi.
Associazioni
Quando più classi sono connesse l'una con l'altra da un punto di vista concettuale, tale
connessione
viene
denominata
Associazione.
Graficamente,
un'associazione
viene
rappresentata con una linea che connette due classi, con il nome dell'associazione appena sopra
la linea stessa come mostrato in fig.1.9.
Figura 1.9: Associazione
Quando una classe si associa con un'altra, ognuna di esse gioca un ruolo all'interno
dell'associazione. E' possibile mostrare questi ruoli sul diagramma, scrivendoli vicino la linea
orizzontale dalla parte della classe che svolge un determinato ruolo.
Un'associazione può essere più complessa del concetto di connettere una classe ad un'altra.
E' possibile,
infatti
che
più
classi
possano
connettersi
ad
una
singola
classe.
Qualche volta un'associazione tra due classi deve seguire una regola. Tale regola si indica
inserendo una constraint vicino la linea che rappresenta l'associazione.
24
_________________________________________________________________________________________________________
Figura 1.10: Classe associazione
Esattamente come una classe, un'associazione può avere attributi ed operazioni. In questo
caso si parla di una Classe Associazione (figura 1.10). Le classi associazione vengono
visualizzate allo stesso modo con cui si mostra una classe normale. Si utilizza una linea
tratteggiata per connettere una Classe Associazione alla linea di associazione. La molteplicità è
un tipo speciale di associazione in cui si mostra il numero di oggetti appartenenti ad una classe
che interagisce con il numero di oggetti della classe associata. Una classe, in generale, può
essere correlata ad una altra nei seguenti modi:
•
Uno ad uno
•
Uno a molti
•
Uno ad uno o più
•
Uno a zero o uno
•
Uno ad un intervallo limitato (es.: 1 a 2 - 20)
•
Uno ad un numero esatto n
•
Uno ad un insieme di scelte (es.: 1 a 5 o 8)
Il linguaggio UML utilizza un asterisco (*) per rappresentare le opzioni molti e più.
Qualche volta, una classe può trovarsi in associazione con se stessa. Ciò si verifica quando
una classe contiene oggetti che possono giocare svariati ruoli. Tali associazioni sono chiamate:
Associazioni Riflessive.
Figura 1.11: Associazione riflessiva
25
_________________________________________________________________________________________________________
Associazione Riflessiva
Senza le relazioni, un modello di classi sarebbe soltanto una lista di rettangoli che
rappresentano un "vocabolario" del sistema. Le relazioni mostrano come i termini del
vocabolario si connettono tra di loro per fornire un quadro della fetta di sistema che si sta
modellando. L'Associazione rappresenta, dunque, la connessione concettuale fondamentale tra
le classi in cui ogni classe, come detto, gioca un ruolo specifico.
Ereditarietà e Generalizzazione
Se si conosce qualcosa riguardo ad una categoria di cose, automaticamente si sa qualcosa
che è possibile trasferire ad altre categorie che, in qualche modo, discendono dalla categoria
stessa. Ad esempio, se si conosce qualcosa su un animale generico (si sa che un animale
mangia, dorme, è nato, si sposta da un luogo ad un altro, e così via), si può dire che tutte le
sottocategorie di animali (rettili, anfibi, mammiferi, ecc.) erediteranno le stesse caratteristiche.
Tale meccanismo, in Analisi Object Oriented, viene definito come: Ereditarietà (fig. 1.12).
Figura 1.12: Ereditarietà
Un esempio di ereditarietà
Una classe figlia (o sottoclasse) può ereditare gli attributi e le operazioni da un'altra classe
(che viene definita classe padre o super classe) che sarà sempre più generica della classe figlia.
Nella generalizzazione, una classe figlia può rappresentare un valido sostituto della classe
padre: in qualunque posto appaia la classe padre, sarebbe possibile far apparire la classe figlia.
Il viceversa non è, invece, vero.
26
_________________________________________________________________________________________________________
In UML l'ereditarietà viene rappresentata con una linea che connette la classe padre alla
classe discendente e dalla parte della classe padre si inserisce un triangolo (una freccia).
Se ragioniamo dal punto di vista dell'associazione, l'ereditarietà può essere vista come un tipo
di associazione. Come devono fare gli analisti per scoprire l'ereditarietà di una o più classi ?
L'analista deve far si che gli attributi e le operazioni per una classe siano generali e si
applichino a parecchie altre classi (le sottoclassi) che, a loro volta, potranno "specializzare" la
classe padre aggiungendo attributi e operazioni propri. Un'altra possibilità è che l'analista noti
che due o più classi hanno un numero di attributi ed operazioni in comune.
Le classi che non permettono di istanziare nessun tipo di oggetto sono dette classi astratte.
In
UML
una
classe
astratta
si
indica
scrivendo
il
suo
nome
in
corsivo.
Si può dunque dire che una classe può ereditare attributi ed operazioni da un'altra classe. La
classe che eredita è figlia della classe (padre) da cui prende gli attributi e le operazioni. Le
classi astratte sono utilizzate soltanto come classi base per l'ereditarietà e non forniscono alcun
oggetto implementabile.
Aggregazioni
Qualche volta una classe può rappresentare il risultato di un insieme di altre classi che la
compongono. Questo è un tipo speciale di relazione denominata aggregazione. Le classi che
costituiscono i componenti e la classe finale sono in una relazione particolare del tipo:
parte-intero (part-whole).
Un'aggregazione è rappresentata come una gerarchia in cui l'intero si trova in cima e i
componenti (parte) al di sotto. Una linea unisce l'intero ad un componente con un rombo
raffigurato sulla linea stessa vicino all'intero.
Un esempio di aggregazione
Si considerino le parti che costituiscono un Televisore. Ogni TV ha un involucro esterno
(Box), uno schermo, degli altoparlanti, delle resistenze, dei transistors, un circuito integrato e
un telecomando (oltre, naturalmente, ad altri tantissimi componenti!). Il telecomando può, a sua
volta, contenere le seguenti parti: resistenze, transitors, batterie, tastiera e luci remote.
Il Class Diagram che ne deriva sarà il seguente:
27
_________________________________________________________________________________________________________
Figura 1.13: Aggregazione
Qualche volta l'insieme di possibili componenti di un'aggregazione si identifica in una
relazione OR. Per modellare tale situazione (fig. 1.13), è necessario utilizzare una constraint
ossia la parola OR all'interno di parentesi graffe su una linea tratteggiata che connette le due
linee parte-intero.
Una composizione è una tipo più forte di aggregazione. Ogni componente in una
composizione può appartenere soltanto ad un intero. Il simbolo utilizzato per una composizione
è lo stesso utilizzato per un'aggregazione eccetto il fatto che il rombo è colorato di nero. Se, ad
esempio, si esamina l'aspetto esterno degli uomini, si evincerà che ogni persona ha (tra le altre
cose): una testa, un corpo, due braccia. e due gambe. Tale concetto viene rappresentato nel
seguente grafico:
Figura 1.14: Associazione composita
in tale associazione ogni componente appartiene esattamente ad un intero. Un'aggregazione
quindi, specifica un'associazione di tipo parte-intero in cui una classe che rappresenta l' intero è
costituita da più classi che la compongono.
28
_________________________________________________________________________________________________________
Una composizione è una forma più forte di aggregazione in cui un componente può
appartenere soltanto ad un intero. Le aggregazioni e le composizioni sono rappresentate come
linee che uniscono l'intero e il componente singolo tramite, rispettivamente, un rombo aperto e
un rombo riempito di nero, entrambi disegnati dalla parte dell'intero.
Interfacce e Realizzazioni
Finora si è detto che è importante definire le classi in base all'intervista fatta con il cliente, e
far sì che tali classi vengano messe nelle corrette relazioni tra di loro. Tuttavia, è possibile che
alcune classi non siano correlate ad una particolare classe padre e che il loro comportamento
possa includere alcune operazioni tutte recanti lo stesso nome. In tal caso esiste la possibilità di
definire tali operazioni per una classe e riutilizzarle per le altre: è proprio quello che avviene
tramite l'utilizzo delle interfacce.
Un'Interfaccia è un insieme di operazioni che specifica alcuni aspetti del comportamento di
una classe; in altre parole, si può dire che un'interfaccia rappresenta un insieme di operazioni
che una classe offre ad altre classi. Per modellare un'interfaccia si utilizza lo stesso modo
utilizzato per modellare una classe, con un rettangolo. La differenza consiste nel fatto che
un'interfaccia non ha attributi ma soltanto operazioni (metodi). Un altro modo utilizzato in
UML per rappresentare le interfacce è quello che utilizza un piccolo cerchio che si unisce
tramite una linea alle classi che implementano l'interfaccia stessa.
La tastiera del computer è un tipico esempio di interfaccia riutilizzabile. La pressione di un
tasto (KeyStroke) rappresenta un'operazione che è stata riutilizzata dalla macchina per scrivere.
La collocazione dei tasti è la stessa della macchina per scrivere, ma il punto cruciale è che la
pressione di un tasto è stata trasferita da un sistema (i due sistemi, come si evince facilmente,
nel nostro caso sono la macchina per scrivere ed il computer) ad un altro. D'altro canto, sulla
tastiera dei computer si trovano un insieme di operazioni che non si trovano sulla macchina per
scrivere (Ctrl, Alt, PageUp, PageDown, ecc.).
Figura 1.15: Interfaccia
29
_________________________________________________________________________________________________________
Una interfaccia è una collezione di operazioni che una classe esegue. Per distinguere le
interfacce dalle classi, dal punto di vista UML si utilizza la scrittura interface all'inizio del
nome di ogni interfaccia, come mostrato nella figura 1.15.
La relazione tra una classe ed un'interfaccia viene definita Realizzazione. Tale relazione è
visualizzata nel modello da una linea tratteggiata con un triangolo largo aperto costruito sul lato
dell'interfaccia.
Visibilità
La Visibilità si applica ad attributi o operazioni e specifica la possibilità che hanno le classi
di usare gli attributi e le operazioni di un'altra classe. Sono consentiti tre livelli di visibilità:
•
Livello pubblico: L'utilizzo viene esteso a tutte le classi;
•
Livello protetto: L'utilizzo è consentito soltanto alle classi che derivano dalla classe
originale;
•
Livello privato: Soltanto la classe originale può utilizzare gli attributi e le operazioni
definite come tali.
A livello grafico vengono utilizzati, generalmente, i seguenti simboli per distinguere i tre
livelli:
•
Livello pubblico: +
•
Livello protetto: #
•
Livello privato: -
Class Diagram - Un esempio pratico
Si prenda come esempio una applicazione classica: quella che permette di scrivere un
documento di testo. Si cerchi di descrivere i passi che costituiscono tale applicazione.
Si Supponga che si stia digitando un documento di testo, utilizzando qualche famoso editor di
testi, come Microsoft Word, ad esempio. L'utente ha due possibilità iniziali:
•
Cominciare a scrivere un nuovo documento;
•
Aprire un documento esistente.
30
_________________________________________________________________________________________________________
Il testo da scrivere, ovviamente, verrà digitato tramite l'utilizzo della tastiera.
Ogni documento è composto di svariate pagine, e ogni pagina, a sua volta, è composta da
una testata, dal corpo del documento e da un piè di pagina. Nella intestazione e nel piè di
pagina è possibile aggiungere la data, l'ora, il numero di pagina, la collocazione del file, e così
via. Il corpo del documento è formato da frasi. Le frasi, a loro volta, sono composte da parole e
segni di punteggiatura. Le parole sono formate da lettere, numeri e/o caratteri speciali. Inoltre,
vi è la possibilità di aggiungere delle immagini e delle tabelle nel documento. Le tabelle sono
costituite da righe e colonne ed ogni cella di una tabella può contenere del testo o delle
immagini. Dopo aver terminato il documento, l'utente può scegliere di salvarlo o stamparlo.
Si è in tal modo descritto, in maniera semplificata ma congruente, il processo di creazione di un
documento tramite Microsoft Word.
Si è ora in grado di estrarre la seguente lista di parole chiave: documento , editor di
documenti, Microsoft Word, testo , tastiera, intestazione, piè pagina, corpo del documento,
data, ora, numero di pagina, collocazione del file, pagina, frase, parola, segno di
punteggiatura, lettera, numero, carattere speciale, immagine, tabella, riga, colonna, cella,
utente.
Si potrà dire che le parole chiave evidenziate sono sicuramente candidate a diventare classi o
attributi per il modello da sviluppare. Come è possibile osservare, nell'esempio descritto,
l'oggetto attorno a cui ruota un po' tutto il discorso è il Documento.
Per tale ragione, sarà una buona idea identificare nel Documento la classe centrale del
nostro Class Diagram. Un documento, come detto, può avere svariate pagine e, quindi, si potrà
definire un attributo: numeroDiPagine che descrive tale caratteristica. Invece, per le operazioni,
sarà bene definire i metodi: Apri( ), Salva( ), Stampa( ),Nuovo( ). Si è detto, poi, che ogni
documento è composto di pagine. La Pagina sarà, dunque, un buon candidato per essere una
classe del nostro diagramma (fig. 1.16).
Figura 1.16: Esempio di classe
31
_________________________________________________________________________________________________________
La Classe Pagina conterrà un attributo : numeroDiPagina, che identificherà il numero della
pagina dell'oggetto, e le seguenti operazioni: nuovaPagina(), nascondiIntestazione() e
nascondiPièdiPagina() (fig.1.17).
Figura 1.17: La classe pagina
I metodi per la testata e il piè di pagina fanno intendere che è bene definire altre due classi:
Intestazione e PiePagina. Tali classi hanno i seguenti attributi in comune: data, ora,
numeroDiPagina e pathFile. Tali attributi sono opzionali per ogni intestazione o piè di pagina e
l'utente potrà configurarli a suo piacimento.
La somiglianza tra Intestazione e PiePagina spinge a definire ancora una nuova classe che
sia in comune alle due appena descritte. È qui che si utilizza il concetto di ereditarietà che è
stato definito in precedenza.
La classe padre sarà BottomUp (questo nome è scelto perché le intestazioni e i piè di pagina
appaiono, rispettivamente, nella parte alta e bassa di ogni pagina del documento) e conterrà gli
attributi che sono in comune alle classi Intestazione e PiePagina oltre alle operazioni (anch'esse
in comune) : visualizza(), modifica() e nascondi().
Le classi Intestazione e PiePagina (figlie di BottomUp) avranno la necessità, quindi, di
definire, rispettivamente, soltanto le operazioni: nuovaIntestazione() e nuovoPiePagina()
(fig.1.18).
Figura 1.18: Esempio di ereditarietà
32
_________________________________________________________________________________________________________
Prima di passare ad esaminare il corpo del documento o il testo, si ponga uno sguardo alla
definizione dei componenti di un testo. Come detto, il testo del documento è composto di frasi.
Le frasi, a loro volta, sono composte di parole e le parole sono formate da caratteri. Se le parole
sono, dunque, array di caratteri e le frasi sono identificabili come array di parole, allora una
frase è anche (per una sorta di proprietà transitiva) un array di caratteri. Quindi, il corpo di un
documento può essere descritto come un array di caratteri. Per tale ragione, per descrivere il
testo di un documento si farà uso della classe Carattere con alcune sottoclassi (fig. 1.19).
La classe Carattere avrà gli attributi: codiceASCII e tipo (il tipo informa sulla tipologia di
carattere, ovvero se esso è in formato normale, corsivo, grassetto o sottolineato) e definirà le
operazioni: Normale(), Corsivo(), Grassetto() e Sottolineato(). Come discendenti della classe
Carattere si definirà poi: Lettera, SegnoDiPunteggiatura, CarattereSpeciale e Numero.
Inoltre, nel corpo del documento possono comparire tabelle o immagini, entrambe costituiranno
altre due nuove classi nel nostro diagramma.
Figura 1.19: La classe carattere
La Classe Tabella (fig.1.20) contiene gli attributi numeroDiRighe e numeroDiColonne e
definisce le operazioni inserisciRiga( ) e inserisciColonna( ). Ogni tabella consiste di una o più
celle e in ogni cella è possibile che compaiano testo o immagini.
33
_________________________________________________________________________________________________________
Figura 1.20: La classe tabella
Utilizzando le associazioni tra le classi che si sono descritte si otterrà dunque il seguente
Class Diagram che descrive l’esempio:
Figura 1.21: Esempio di Class Diagram
È importante rendersi conto che il diagramma precedente non costituisce la massima
descrizione in particolare per un processo di scrittura di un documento di testo.
Il modello descritto potrà essere specializzato sempre di più e, quindi, crescere in modo
appropriato per poter consentire un appropriato lavoro di analisi e disegno.
34
_________________________________________________________________________________________________________
1.9 Use Case Diagrams: specifiche
I Class Diagrams forniscono una visione statica delle classi che intervengono nella
creazione di un Sistema. Il tipo di diagramma, di seguito considerato, presenterà invece una
visione dinamica e mostrerà come il sistema e le relative classi cambino con il passare del
tempo. La visione statica aiuta gli analisti nella comunicazione con il cliente, mentre la visione
dinamica del Sistema, fornisce agli analisti un valido mezzo per instaurare un dialogo chiaro
con il team degli sviluppatori ed aiuta gli sviluppatori stessi a creare i programmi.
Esattamente come il Class Diagram rappresenta un ottimo modo per stimolare il cliente a
parlare sul sistema dal suo punto di vista, lo Use Case Diagram rappresenta un eccellente
strumento per stimolare dei potenziali utenti a intervenire con le loro critiche ed opinioni sulla
funzionalità che il Sistema dovrà avere. Non è sempre facile per gli utenti riuscire a spiegare
tecnicamente come essi intendano costruire il sistema desiderato; infatti, accade sempre più
spesso che essi in realtà sappiano esprimersi meglio dal punto di vista pratico che non dal punto
di vista prettamente tecnico. Lo use case (Caso d'uso) è allora lo strumento ideale per aiutare a
"rompere il ghiaccio".
Le interviste con gli utenti iniziano facendo uso della terminologia del dominio, ma poi
deviano ed utilizzano la terminologia del cliente. I risultati iniziali delle interviste devono
portare alla definizione di Actors (attori) e use cases ad alto livello che descrivano i requisiti
funzionali in termini generali. Ne risulta che già questa informazione è in grado di fornire i
limiti e gli scopi del sistema che si intende sviluppare. Nelle interviste successive con gli utenti
si cercherà di approfondire maggiormente tali requisiti, portando così alla definizione di
modelli use case che soddisfino le relazioni di inclusione e estensione. In questa fase è
importante la comprensione del dominio, poiché se si hanno lacune in tal senso potrebbe
accadere che si sviluppino troppi use cases e che ciò possa provocare un rallentamento nel
processo di analisi.
Gli use case sono collezioni di scenari che riguardano l'utilizzo del sistema in cui ogni
scenario descrive una sequenza di eventi. La sequenza di eventi descritta da uno use case viene
iniziata da una persona, o da un altro sistema o da un pezzo di hardware o ancora dal passare
del tempo.
Le entità che iniziano la sequenza di eventi sono definiti Actors. Il risultato della sequenza
deve portare a qualcosa di utile all'actor che ha iniziato la sequenza o, anche, ad un differente
actor. È anche possibile riutilizzare gli use cases. Per far ciò si possono usare due modi:
35
_________________________________________________________________________________________________________
•
Inclusion: Questo modo permette di utilizzare i passi appartenenti ad una sequenza di
un use case e inglobarli in un altro use case;
•
Extension: Tramite questo metodo è possible creare un nuovo use case semplicemente
aggiungendo dei passi ad un use case esistente.
Si vedrà ora come rappresentare un modello use case e visualizzare le relazioni tra più use
cases.
Introduzione all' Use Case Model
Un actor inizia la sequenza di un particolare use case, ed un actor (possibilmente lo stesso
che ha iniziato, ma non necessariamente) riceve un ritorno dallo use case (fig. 1.22).
Figura 1.22: Use case
Graficamente, un ellisse rappresenta un use case ed un omino rappresenta un actor. L'actor
che inizia la sequenza di eventi di un use case viene sempre inserito alla sinistra dell'use case
mentre, al contrario, l'actor che riceve gli effetti causati dalla sequenza scatenata dall'use case
stesso, viene disegnato alla destra. Il nome dell'actor appare appena sotto la raffigurazione
dello stesso actor mentre il nome dell'Use Case appare o dentro l'ellisse o appena al di sotto di
esso.
Una linea di associazione, infine, connette un actor all'use case e rappresenta la
comunicazione tra l'actor e lo use case. La linea di associazione è una linea continua, simile a
quella che connette due classi in associazione tra loro. Ogni use case è una lista di scenari, ed
ogni scenario è una sequenza di passi. Per ciascun use case, ogni scenario avrà la sua propria
pagina rappresentata nel seguente modo:
•
Un actor che dà inizio alla sequenza dell'use case;
•
Le Pre condizioni per lo use case;
36
_________________________________________________________________________________________________________
•
I passi dello scenario vero e proprio;
•
Le Post Condizioni quando lo scenario è completo;
•
L'actor che beneficia dell'use case.
Gli Use Case Diagram danno del valore aggiunto alla raccolta di informazioni. Essi
visualizzano gli use case, facilitano la comunicazione tra gli analisti e gli utenti e tra gli analisti
ed il cliente.
Relazioni tra Use Cases
Quando si è iniziato a parlare di Use Case Diagrams, si è detto che è possibile il riutilizzo
di un Use Case e che ciò era fattibile utilizzando due modi: tramite l'inclusion e tramite
l'extension.
L'inclusion e la extension rappresentano una sorta di relazioni tra use case. In effetti,
esistono anche altri due tipi di relazioni applicabili agli use cases : le generalizzazione
(Generalization) e il raggruppamento (Grouping). Tali relazioni sono di seguito definite.
Inclusion
L'inclusion permette il riutilizzo di un use case all'interno di un altro use case. Per
rappresentare graficamente una inclusion, si utilizza il simbolo utilizzato per la dipendenza tra
classi, una linea tratteggiata che connette le classi con una freccia che punta sulla classe da cui
dipende l'altra classe. Appena sotto questa linea, si aggiunge uno stereotipo: la parola
<<include>> racchiusa, come si vede, tra doppie parentesi formate dai simboli "<<" e ">>".
Extension
L'extension permette di creare un nuovo use case aggiungendo dei passi in più ad un use
case già esistente. Anche qui una linea tratteggiata con una freccia finale viene utilizzata per
rappresentare l'extension, insieme con uno stereotipo che mostra la parola <<extends>> tra
parentesi. All'interno dell'use case base, il punto di extension appare sotto il nome dell'use case
stesso.
Generalization
Le classi, come si è visto, possono ereditare le caratteristiche di un'altra classe (classe
padre). Allo stesso modo, tale ragionamento è applicabile agli use case. Nella eredità tra use
37
_________________________________________________________________________________________________________
case, lo use case figlio eredita il comportamento ed il significato dal padre ed in più aggiunge
le sue caratteristiche specifiche. Anche in questo caso vale lo stesso ragionamento applicato nel
caso delle classi: e' possibile applicare lo use case figlio, laddove è possibile applicare il padre.
La generalization viene rappresentata allo stesso modo con cui viene rappresentata per le classi,
ovvero con una linea continua che ha un triangolo aperto che punta al padre. La relazione di
generalization può esistere anche tra actors.
Grouping
In alcuni use case diagrams, ci potrebbero essere molti use case e, magari, si desidererebbe
organizzare il diagramma in modo migliore. Una tale situazione si può verificare quando si sta
progettando un sistema che consiste di più sottosistemi. Il modo più semplice è di organizzare a
gruppi gli use case che in qualche modo siano correlati (qualcosa di simile ad un tabbed
folder).
Use Case Diagram - esempio
In questo esempio si cercherà di modellare, tramite gli use case diagrams, una macchina
self-service per alimenti e bevande. La principale funzione di una siffatta macchina è,
ovviamente, quella di permettere ad un utente di acquistare un prodotto alimentare (cioccolata,
succo di frutta, e cosi via). Ogni utente che interagisca con la macchina potrà, certamente, dire
che la principale funzione (e quindi il principale use case) della macchina stessa potrà essere
definita come : "Acquisto di un prodotto".
Si proverà pertanto ad esaminare ogni possibile scenario all'interno di questo use case. Gli
scenari che ne derivano saranno, naturalmente, scaturiti dalle conversazioni con l'utente.
Lo use case "Acquista un prodotto"
L'actor in questo use case è il cliente. Il cliente vuole comprare alcuni dei prodotti offerti
dalla macchina self-service. Per prima cosa egli dovrà inserire delle monete all'interno della
macchina, poi selezionare il tipo di prodotto (o più di uno, se la macchina lo consente) e quindi
ricevere dalla macchina la lista dei prodotti scelti prima di procedere all'acquisto vero e proprio.
Lo use case per tale tipo di scenario può essere il seguente (fig. 1.23):
38
_________________________________________________________________________________________________________
Figura 1.23: Esempio di use case
Se si pensa un attimo più approfonditamente è possibile che la macchina self-service non sia in
grado, ad un certo momento, di fornire uno o più prodotti oppure che la macchina non abbia a
disposizione l'esatto numero di monete per fornire il resto al cliente. Se è stato chiesto di gestire
questi tipi di scenari bisogna tornare un attimo indietro al momento in cui il cliente inserisce le
monete nella macchina ed effettua la selezione. Si Supponga che la macchina, a questo punto,
non sia in grado di soddisfare la richiesta del cliente. In tal caso sarà preferibile presentare un
messaggio al cliente che lo informi che la macchina non ha come disponibile il prodotto scelto
e che permetta al cliente stesso di effettuare una nuova scelta o richiedere la restituzione delle
monete.
Se, invece, si è verificato lo scenario in cui è stato fornito un errato ammontare di monete, si
suppone che la macchina restituirà l'importo originale di soldi al cliente. La precondizione, in
tal caso, è il cliente e la post condizione è il prodotto acquistato o la restituzione dei soldi.
Quanto descritto rappresenta lo scenario di un use case dal punto di vista di un utente (e
quindi di un actor). Ma potrebbero esserci anche altri tipi di actors. Per esempio, un fornitore
di prodotti deve essere in grado rifornire la macchina e il proprietario della macchina deve
poter recuperare le monete accumulate. Questo induce a creare almeno altri due use case ossia:
"Ricarica la Macchina" e "Ritira le Monete". Si considerino ora entrambi gli eventi, simulando
un' intervista con il fornitore e con il proprietario.
Lo use case "Ricarica la Macchina"
Le azioni che un fornitore dovrà compiere ad intervalli di tempo regolari sono:
•
Il fornitore disattiva la macchina;
•
Apre il contenitore dei prodotti;
•
Riempie ogni scompartimento fino alla massima capacità (Si potrebbe anche supporre
che il fornitore riempia la macchina tenendo conto delle maggiori preferenze dei
clienti);
•
Alla fine, il fornitore chiude il contenitore dei prodotti e riattiva la macchina.
39
_________________________________________________________________________________________________________
In questo caso, si potrà dire che la precondizione è rappresentata dal trascorrere
dell'intervallo di tempo tra una ricarica e l'altra e la post condizione è data dal fatto che il
fornitore ottiene un nuovo insieme di potenziali clienti. Lo use case diagram, in questo caso, è
rappresentato dalla seguente figura:
Figura 1.24: Lo use case “ricarica la macchina”
Lo use case "Ritira Le Monete"
Il responsabile per questo use case è il proprietario della macchina. In effetti, tuttavia, questi
potrebbe coincidere con il fornitore. I passi che il proprietario della macchina deve fare sono
uguali a quelli del fornitore. La differenza consiste nel fatto che il proprietario non ha a che fare
con i prodotti, ma con i soldi. Quando l'intervallo di tempo tra un ritiro e l'altro è trascorso, il
proprietario della macchina ritira l'ammontare di monete che si è depositato nella macchina. La
post condizione, in tal caso, è rappresentata dai soldi ritirati dal proprietario. Lo use case che
descrive tale scenario è, dunque, rappresentato in figura 1.25:
Figura 1.25: Lo use case ritira le monete
Molti dei passi necessari allo use case "Ritira le monete" (disattivare la macchina, aprire il
contenitore, ecc.) sono uguali a quelli visti per lo use case "Ricarica la macchina". Questo è un
buon motivo per avvalersi dell'utilizzo dell'inclusion. E’ possibile allora combinare i due passi
“Disattiva la macchina” e “apre il contenitore” in uno use case denominato: "Disattiva la
macchina". Alla stessa maniera si definisce un nuovo use case dal nome "Riattiva la
Macchina" che inglobi i passi di chiudere il contenitore e riattivare la macchina. Si Otterrà
quanto riportato in figura 1.26:
40
_________________________________________________________________________________________________________
Figura 1.26: Use case completo
Lo use case "Ricarica la macchina" potrebbe essere la base per un altro use case: "Ricarica
la macchina in base alle vendite". Qui, il fornitore può riempire gli scompartimenti non più in
modo uniforme per ogni prodotto ma in base alle vendite dei singoli prodotti. Questo
rappresenta un buon esempio di extension di un use case. Dopo l'inclusion e l'extension così
definiti, lo use case "Ricarica la macchina" può diventare pertanto (fig. 1.27):
Figura 1.27: Ricarica la macchina – una variante
41
_________________________________________________________________________________________________________
Si può anche utilizzare la generalizzazione guardando gli actors: fornitore e proprietario.
Sarà possibile definire un actor più generico (Agente del Fornitore) che inglobi molte delle
caratteristiche del Proprietario e del Fornitore. Tale generalizzazione è mostrata nella figura
1.28.
Figura 1.28: Esempio di generalizzazione di un actor
Figura 1.29: Diagramma finale
La figura 1.29 mostra il diagramma finale completo per la macchina self service.
42
_________________________________________________________________________________________________________
1.10 State Diagrams
Si descrivono adesso, elementi che non sono stati ancora esaminati. Tali elementi sono detti
elementi comportamentali e mostrano come varie parti di un diagramma UML possano
cambiare nel tempo.
Allo stesso modo in cui un sistema interagisce con gli utenti, e possibilmente con altri
sistemi, così gli oggetti che costituiscono il sistema stesso passano attraverso i necessari
cambiamenti che servono a favorire le interazioni.
Se si sta modellando un sistema, è necessario avere un meccanismo che gestisca le
modifiche all'interno del modello stesso. Tale meccanismo, in UML, è rappresentato dagli
State Diagrams.
Per esempio, quando si preme un interruttore, una lampada cambia il suo stato da spento ad
acceso (o viceversa). Oppure, ancora, quando si preme un tasto della tastiera o si muove il
mouse durante il funzionamento di uno screen saver sul computer, il computer abbandona la
modalità di screen saver e ritorna a funzionare regolarmente in modo attivo.
Gli State Diagrams visualizzano gli stati che un oggetto può attraversare e i passaggi
transitori che intercorrono tra questi stati. Inoltre gli State Diagrams mostrano il punto di
partenza e il punto di arrivo di una sequenza di cambi di stato. Uno State Diagram mostra gli
stati di un singolo oggetto.
Si consideri ora la rappresentazione grafica. Gli stati di uno State Diagram sono
rappresentati con un rettangolo con gli angoli arrotondati. Il simbolo che mostra la transizione
da uno stato ad un altro viene disegnato utilizzando una linea continua che termina con una
freccia.
Un cerchio nero pieno rappresenta il punto di partenza di una sequenza di stati mentre il
punto di arrivo viene rappresentato da due cerchi concentrici in cui il più interno è riempito di
nero (tale figura viene anche definita "occhio di bue").
Figura 1.30: State diagram
43
_________________________________________________________________________________________________________
Nella figura precedente si può vedere un esempio di quanto detto. Inoltre, come si può
notare, è possibile aggiungere maggiori dettagli alla figura stessa dividendo il rettangolo in tre
aree separate.
L'area in alto contiene il nome dello stato, l'area centrale contiene le variabili di stato
(timers, contatori, date, ecc.) e l'area in basso rappresenta le attività (cioè quello che accade
quando il sistema entra in un determinato stato e cosa, invece, succede quando il sistema
abbandona quello stato.
Dettagli di Stato e Transizioni
È possibile indicare sugli State Diagram un evento che causa il verificarsi di una transizione
(un evento trigger) e l'azione che viene eseguita che fa sì che il cambio di stato possa avvenire.
Per aggiungere graficamente eventi e azioni si scrive vicino la linea di transizione una
descrizione di essi, utilizzando una barra per separare un evento di trigger da un'azione.
Qualche volta può accadere che un evento causi una transizione senza azioni associate e,
qualche altra volta una transizione si verifica perchè uno stato completa un'attività (piuttosto
che a causa di un evento). Questo tipo di transizione viene chiamata transizione senza trigger
(triggerless transition).
È anche possibile inserire una condizione di controllo (guard condition). Quando la si
incontra, la transizione ha luogo. (Per esempio lo screen saver viene attivato quando l'intervallo
di tempo di x minuti viene raggiunto).
Gli State Diagrams consentono, inoltre, di definire degli stati all'interno di altri stati. In tal
caso, gli stati interni verranno definiti sotto-stati (substates) i quali, a loro volta, possono essere
disinti in sottostati sequenziali e sottostati concorrenti.
I primi, come si evince dal nome stesso, rappresentano una sequenza di stati che vengono
raggiunti uno susseguentemente all'altro. I sottostati concorrenti, invece, rappresentano due o
più sottostati sequenziali che si verificano allo stesso tempo. Tutto ciò viene rappresentato
graficamente con una linea tratteggiata tra gli stati concorrenti. Per comprendere meglio questi
concetti, comunque, si faccia riferimento all'esempio del paragrafo successivo.
L'UML fornisce un simbolo che mostra che uno stato composto ricorda i suoi attivi
sottostati quando l'oggetto effettua transizioni fuori dallo stato composto. Il simbolo usato è:
unito da una linea continua ai sottostati "ricordati", con una freccia che punta al sottostato
opportuno.
44
_________________________________________________________________________________________________________
Un messaggio che causa una transizione in un oggetto dello State Diagram (che riceve il
messaggio stesso) viene chiamato segnale (signal).
Nel mondo orientato agli oggetti, il mandare un segnale viene visto allo stesso modo come
la creazione di un oggetto Segnale e la trasmssione di questo ad un oggetto Ricevente.
L'oggetto Segnale può avere delle proprietà che saranno rappresentate da attributi.
Infine, poiché un segnale è un oggetto, è anche possibile creare gerarchie di ereditarietà di
segnali.
State Diagram - Un esempio pratico
Si supponga di voler creare un modello che descriva il funzionamento di un tostapane,
rivolgendo l’attenzione agli state diagram che un simile sistema può avere. Quali sono i passi
perchè un tostapane riesca a preparare un toast ?
Per prima cosa bisognerà accendere il tostapane, quindi mettere le fette di pan carrè
all'interno di esso ed attendere alcuni minuti perchè sia cotto il toast. Lo state diagram iniziale
sarà, dunque (fig. 1.31):
Figura 1.31: Esempio di state diagram
Ma quello rappresentato non è il diagramma finale. Per prevenire che il toast si bruci, la
resistenza del tostapane deve produrre calore che non superi determinati valori di temperatura.
Naturalmente, perchè il toast si cuocia a dovere è necessario anche che la temperatura non vada
al di sotto di un certo valore minimo.
Per tale ragione un termometro misura la temperatura prodotta dalla resistenza e quando il
limite massimo viene raggiunto la resistenza passa in uno stato di attesa e non emette altro
calore. Tale stato perdura finché la temperatura decresce fino ad arrivare al valore minimo. A
questo punto ritorna lo stato di "In Lavorazione". Con questi ulteriori dettagli, lo State Diagram
diverrà come riportato in figura 1.32:
45
_________________________________________________________________________________________________________
Figura 1.32: State diagram dettagliato
Ma per descrivere la transizione tra lo stato di "In Lavorazione" e lo stato "Inattivo" è
necessario aggiungere dei sottostati al diagramma, come mostrato nella prossima figura:
Figura 1.33: Descrizione della transizione
Si può notare che gli stati "In Lavorazione " e "Inattivo" sono molto simili. Entrambi
devono misurare e comparare gli stati ma si differenziano nel processo di confronto della
temperatura. Infatti, lo stato di "In Lavorazione" deve comparare la temperatura corrente con la
temperatura limite superiore (se viene raggiunta allora si passa allo stato "Inattivo") e lo stato
"Inattivo" confronta la temperatura corrente con la temperatura limite inferiore (lo stato
"Inattivo" viene rimpiazzato dallo stato di "In Lavorazione" quando accade che la temperatura
scende al di sotto del limite).
46
_________________________________________________________________________________________________________
È opportuno utilizzare gli State Diagrams perché essi aiutano gli analisti, i disegnatori e gli
sviluppatori a capire il comportamento degli oggetti in un sistema. Gli sviluppatori, in
particolare, devono conoscere come gli oggetti devono comportarsi in quanto è loro compito
tradurre tali comportamenti in software e quant’altro.
1.11 Sequence Diagrams
Gli State Diagrams, analizzati nel precedente paragrafo, focalizzano la loro attenzione sugli
stati di un oggetto. Ma è necessario, oltre alla definizione degli stati, instaurare una
comunicazione tra gli oggetti. L'UML, a tale proposito definisce il Sequence Diagram che,
appunto, permette di modellare la comunicazione tra un oggetto ed un altro in relazione al
trascorrere del tempo. Si capisce subito che in questo tipo di rappresentazione un ruolo cruciale
viene svolto dal tempo.
L'idea chiave qui è che le interazioni tra gli oggetti avvengano seguendo un ordine ben
preciso e che tale sequenza avvenga, nel tempo, dall'inizio alla fine.
Il Sequence diagram è costituito da oggetti rappresentati nel modo ormai usuale - come
rettangoli recanti un nome (con il nome sottolineato), messaggi rappresentati da linee continue
recanti una freccia alla loro fine e il tempo rappresentato come progressione verticale. Si
analizzino ora i componenti di un sequence diagram.
I componenti dei Sequence Diagrams
Oggetti
Gli oggetti sono disegnati vicino la sommità del diagramma e sono disposti in sequenza da
sinistra verso destra. Essi possono essere inseriti in un qualunque ordine che semplifichi la
comprensione del diagramma. Da ogni rettangolo parte una linea tratteggiata verso il basso,
denominata "linea della vita" (lifeline). Lungo la lifeline si trova un piccolo rettangolo chiamato
"attivazione" (activation). L'activation rappresenta l'esecuzione di un'operazione di cui
l'oggetto si fa carico. La lunghezza del rettangolo, invece, rappresenta la durata dell'activation.
Tutto questo è mostrato nella figura 1.34:
47
_________________________________________________________________________________________________________
Figura 1.34: Sequence diagram
Messaggi
Un messaggio che viaggia da un oggetto ad un altro, viene disegnato a partire dalla lifeline
dell'oggetto da cui parte il messaggio e arriva sulla lifeline dell'oggetto a cui il messaggio è
diretto.
Si può anche verificare il caso in cui un oggetto mandi un messaggio a se stesso, cioè un
messaggio che parte dalla sua lifeline e arriva alla stessa lifeline. Tale tipo di comportamento
viene definito Ricorsione.
Nella tabella 1.2 vengono identificati tutti i possibili messaggi definiti in UML per i
sequence diagrams, ognuno dei quali, come si vede, ha una rappresentazione grafica differente.
simple
Rappresenta il trasferimento del controllo da
un oggetto ad un altro.
Se un oggetto invia un messaggio sincrono,
synchronous
allora si attende che gli venga restituita una
risposta al messaggio stesso prima di poter
continuare con altre operazioni.
Diversamente dai messaggi sincroni, se un
asynchronous
oggetto invia un messaggio asincrono, non
attende che gli venga inviata alcuna risposta
prima di continuare con altre operazioni
Tabella 1.2: Messaggi per i sequence diagrams
48
_________________________________________________________________________________________________________
Il Tempo
Il sequence diagram rappresenta il trascorrere del tempo se visto in direzione verticale. Il
tempo, graficamente, viene fatto partire alla base di ogni oggetto e proseguire fino in basso. Ad
esempio, un messaggio che si trovi più vicino all'oggetto rispetto ad un altro (rispetto alla
direzione verticale), si verificherà prima nel tempo.
Figura 1.35: Il tempo
Nei sequence diagram viene utilizzato il simbolo dell'actor per rappresentare l'inizio della
sequenza, ma in realtà tale simbolo (come visto quando si è discusso degli Use Case diagrams)
non appartiene all'insieme dei simboli propri del sequence diagram.
Modi di creare le Sequenze
In maniera uguale agli use case diagrams in cui è possibile mostrare o un'istanza (uno
scenario) singola di uno use case o, più genericamente, un insieme degli scenari di un use case,
così i sequence diagrams possono essere definiti su una singola istanza oppure definire un
modello più generico.
49
_________________________________________________________________________________________________________
I sequence diagrams generici forniscono spesso la possibilità di rappresentare delle
istruzioni condizionali (if) e dei cicli while in cui ogni condizione descritta da un if (oppure da
un while) viene racchiusa tra parentesi quadrate (nel caso del while la parentesi quadrata
sinistra viene preceduta da un asterisco). Si consideri l'esempio di seguito riportato, per
maggiore chiarezza.
Esiste la possibilità, in un sequence diagram, di creare un oggetto. Quando ciò avviene,
l'oggetto creato viene rappresentato nel modo visto finora e cioè con un rettangolo all'interno
del quale viene descritto il nome dell'oggetto.
La differenza, in questo caso, consiste nel fatto che l'oggetto non viene posizionato alla
sommità del sequence diagram come si farebbe con gli altri oggetti ma, piuttosto, lungo la
dimensione verticale che indica il tempo in cui tale oggetto viene creato.
Può accadere, qualche volta, che un oggetto esegua un'operazione che invochi lo stesso
oggetto che l'ha provocata. In tal caso si parla di ricorsione. Ad esempio, si supponga che uno
degli oggetti del sistema sia un calcolatore e che una delle sue operazioni sia il calcolo degli
interessi. Al fine di permettere il calcolo per un lasso di tempo che racchiuda parecchi periodi,
l'operazione per calcolare gli interessi deve invocare se stessa diverse volte. Il sequence
diagram in figura 1.36, mostra tale caso:
Figura 1.36: La ricorsione nel sequence diagram
Sequence Diagram - Un esempio
Si consideri lo stesso esempio visto in precedenza, ovvero quello della macchina SelfService. Si definiscano i seguenti tre oggetti della Macchina Self-Service con cui verrà descritto
il diagramma:
•
La Parte Frontale. - L'interfaccia che la macchina presenta all'utente;
50
_________________________________________________________________________________________________________
•
La Cassetta delle monete - La parte in cui vengono accumulate le monete e che gestisce
i vari controlli della macchina;
•
Il Contenitore dei Prodotti - La parte che contiene gli alimenti che vengono acquistati
dal cliente.
Il Sequence Diagram farà uso della seguente serie di azioni:
•
Il cliente inserisce le monete nella macchina;
•
Il cliente esegue la selezione del prodotto desiderato;
•
Le monete arrivano nella Cassetta delle Monete;
•
Il dispositivo di controllo della Cassetta delle monete verifica se il prodotto desiderato
è presente nel Contenitore dei Prodotti;
•
La Cassetta delle Monete aggiorna la sua riserva di monete;
•
Il dispositivo di controllo della Cassetta delle Monete informa il Contenitore dei
Prodotti che può espellere il prodotto desiderato dalla Parte Frontale della macchina.
Figura 1.37: Esempio di sequence diagram
51
_________________________________________________________________________________________________________
Collaboration Diagrams
I collaboration diagrams rappresentano un tipo di diagramma molto simile a quello appena
visto nei sequence diagram. Infatti, essi mostrano come interagiscono gli oggetti tra di loro,
mettendo in risalto gli oggetti attraverso i quali viaggiano i messaggi che gli stessi oggetti si
scambiano tra di loro. Sorge allora spontanea la domanda: Ma se già i sequence diagrams
realizzano tali operazioni, perché l'UML ha bisogno di un altro diagramma dello stesso tipo ?
Non svolgono le stesse funzioni ?
In effetti, il sequence diagram e il collaboration diagram sono simili. In particolare, si può
dire che essi sono semanticamente equivalenti. Ovvero, i due diagrammi presentano la stessa
informazione ed è facile convertire un sequence diagram in un collaboration diagram e
viceversa. La principale distinzione tra i due diagrammi, è che il sequence diagram è costruito
seguendo come filo conduttore il tempo mentre il collaboration diagram si basa sullo spazio.
Un collaboration diagram è un'estensione di un diagramma di oggetti. In più, oltre alle
associazioni tra gli oggetti, esso consente di mostrare i messaggi che essi inviano per interagire
tra di loro.
I messaggi tra gli oggetti sono rappresentati con delle frecce che puntano all'oggetto che
riceve il messaggio stesso. Tali frecce sono posizionate vicino la linea di associazione tra gli
oggetti. Una label vicino la freccia indica la specifica di un messaggio. Un messaggio,
tipicamente, richiede all'oggetto ricevente di eseguire una delle sue operazioni. Una coppia di
parentesi terminano il messaggio; al loro interno si trovano gli eventuali parametri con cui le
operazioni lavorano.
Come detto, i collaboration diagrams possono essere convertiti in sequence diagrams e
viceversa. Per far ciò, però, si deve tenere presente che è necessario aggiungere un numero alla
label di un messaggio che corrisponda all'ordine in cui il messaggio appare nella sequenza. Il
segno dei due punti separa il numero dal messaggio.
Scrivere dei Collaboration Diagrams
È possibile mostrare, in un collaboration diagram, il cambio di stato di un oggetto. Si
possono mostrare, inoltre, le condizioni allo stesso modo in cui esse sono rappresentate
all'interno di un sequence diagram.
Nel rettangolo che rappresenta l'oggetto si indica lo stato dell'oggetto stesso. Al diagramma
si aggiunge un altro rettangolo che rappresenta l'oggetto e indica lo stato modificato. I due
rettangoli vengono quindi uniti con una linea recante un'etichetta con uno stereotipo. La
52
_________________________________________________________________________________________________________
condizione va inserita all'interno di una coppia di parentesi quadre considerato che tale
condizione deve precedere l'etichetta del messaggio.
La cosa importante è coordinare le condizioni con una numerazione (per maggiori
chiarimenti su tale costruzione si veda il paragrafo successivo).
I collaboration diagram permettono anche di modellare la creazione di oggetti; nel processo
di creazione di tali oggetti si inserisce uno stereotipo <<create>> al messaggio che si occupa
della creazione dell'oggetto stesso.
Ancora, nei collaboration diagrams si possono rappresentare oggetti multipli e visualizzare
i risultati restituiti.
La rappresentazione di oggetti multipli viene effettuata tramite uno stack (una pila) di
rettangoli disegnati in sequenza inversa (da destra a sinistra). Si aggiunge una condizione
(circondata da parentesi) e preceduta da un asterisco per indicare che il messaggio deve
giungere a tutti gli oggetti.
I risultati restituiti sono scritti come espressioni in cui il nome dell'espressione è preceduto
dal valore di ritorno e seguito dai segni “: = “. Quindi, si scrivono il nome dell'operazione ed
una lista di possibili attributi che l'operazione può accettare per produrre il risultato finale. La
parte destra dell'espressione appena descritta viene definita firma del messaggio (messagesignature).
Figura 1.38: Vista di un collaboration diagram
In alcune interazioni può accadere che uno specifico oggetto si occupi del controllo del
flusso. Questo oggetto attivo può mandare messaggi ad oggetti passivi ed interagire a sua volta
con altri oggetti attivi. Inoltre, si potrebbe verificare anche il caso di un oggetto che mandi
messaggi soltanto dopo che parecchi altri messaggi (possibilmente non consecutivi) siano stati
inviati. In altre parole, l'oggetto deve sincronizzare il suo messaggio con un insieme di altri
messaggi.
53
_________________________________________________________________________________________________________
Il collaboration diagram rappresenta un oggetto attivo allo stesso modo di come si è visto
finora con la differenza che i bordi del rettangolo sono spessi e in grassetto.
I messaggi sincroni sono preceduti da una lista di messaggi che devono essere completati
prima che il messaggio sincrono possa essere inviato. Una virgola separa un elemento della
lista dall'altro e la lista termina con una barra.
Vediamo ora di mettere insieme tutti i concetti di cui si è parlato e di definire un
collaboration diagram completo.
Collaboration Diagram - Un esempio
Ancora una volta verrà utilizzato l'esempio della macchina self-service. Nell'esempio sul
sequence diagram si è già costruito il diagramma per un sistema del genere. Adesso, si
mostrerà come convertire il sequence diagram in un collaboration diagram.
Lo scenario del caso migliore consiste di diversi passi:
Il cliente inserisce le monete nella macchina ed esegue le selezione di uno o più prodotti
presenti sulla macchina:
•
Quando il dispositivo di introduzione delle monete ottiene la somma dovuta (in questo
caso si suppone che il cliente inserisca il corretto numero di monete necessarie) e vi è
la disponibilità dei prodotti scelti, allora viene espulso dalla macchina il prodotto
scelto;
•
Il prodotto (o i prodotti) viene espulso dalla parte frontale della macchina in modo che
il cliente possa prelevarli.
Figura 1.39: Esempio di collaboration diagram
54
_________________________________________________________________________________________________________
Quando però si esamina in particolare questa macchina ed il lavoro che essa svolge, ci si rende
conto che sono possibili ulteriori scenari:
•
Introduzione di un numero errato di monete;
•
Mancata disponibilità di un prodotto selezionato.
È possibile utilizzare delle condizioni che aiuteranno a descrivere il lavoro della macchina.
Esse vengono visualizzate tra una coppia di parentesi quadre in modo tale che la condizione
preceda l'etichetta del messaggio. La cosa importante è tener presente che bisogna coordinare le
condizioni con la numerazione progressiva.
Nello scenario in cui la macchina non abbia a disposizione il prodotto scelto è necessario
che la macchina visualizzi un messaggio all'utente che gli permetta di selezionare un prodotto
alternativo e ripetere, quindi, il processo oppure di avere restituite le monete. È, naturalmente,
possibile descrivere un collaboration diagram anche per il caso in cui si sia inserito un numero
errato di monete. Il collaboration diagram seguente illustra entrambi i casi (fig. 1.40)
Figura 1.40: Collaboration diagram completo
Come è possibile vedere dallo schema, sono possibili fondamentalmente due scenari:
Alimento Non Presente e Alimento Presente. Se si assume che tale differenziazione avvenga
dopo il messaggio 2: InserimentoMonete(AlimentoSelezionato), il numero identificativo per
questi messaggi sarà 3 per lo scenario Alimento Presente e 5 per lo scenario Alimento non
Presente. Cosa avviene quando la macchina non ha a disposizione il resto corretto ?
55
_________________________________________________________________________________________________________
Essa deve visualizzare un messaggio, restituire le monete e chiedere al cliente di inserire la
quantità esatta di monete. A questo punto, la transazione è terminata. Quando la macchina ha la
giusta quantità di monete, restituisce il resto al cliente ed espelle il prodotto selezionato.
I due rami che sono prodotti dal processo annidato per il controllo del resto sono
contrassegnati con 3 e 4 come da figura 1.41.
Figura 1.41: Rami prodotti dal processo annidato
Activity Diagrams
Probabilmente, chi ha dimestichezza con la programmazione conoscerà i diagrammi di
flusso (flowchart). Il flowchart mostra una sequenza di passi, processi, punti decisionali e rami.
I programmatori alle prime armi sono spesso indotti ad utilizzare i diagrammi di flusso per
sviluppare una migliore logica di programmazione e ricavare delle soluzioni ai problemi
software.
L'activity diagram UML è molto simile ai flowchart. Infatti, esso mostra i passi (chiamati,
propriamente, attività), i punti decisionali e i rami che intervengono nel flusso di un
programma. È utile per mostrare cosa accade in un processo di business o in un'operazione ed è
considerato come parte integrante dell'analisi di sistema.
Un activity diagram viene disegnato per essere una vista semplificata di cosa accade durante
un'operazione o un processo. Si può affermare che esso altro non è che un'estensione dello state
diagram. Quest'ultimo mostra gli stati di un oggetto e rappresenta le attività come frecce che si
connettono agli stati. L'activity diagram mette in risalto le attività.
56
_________________________________________________________________________________________________________
Ogni attività è rappresentata da un rettangolo con gli angoli arrotondati - più stretto e più
ovale rispetto alla icona vista nello state diagram. L'elaborazione di un'attività porta al
completamento della stessa e poi avviene un'automatica trasmissione alla successiva attività.
Una freccia rappresenta la transizione da un'attività alla successiva. Anche l'activity diagram ha
un punto di partenza, rappresentato da un cerchio pieno, ed un punto di fine rappresentato da un
occhio di bue (fig. 1.42).
Figura 1.42: Activity diagram
Costruzione di un Activity Diagram
Si cercherà ora di esaminare le varie componenti in particolare: le modalità in cui vengono
rappresentate le decisioni, i path concorrenti, i segnali e le swimlanes.
Decisioni
Un punto di decisione può essere rappresentato in due modi. La scelta sulla modalità da
utilizzare è affidata interamente all'analista.
Il primo modo consiste nel mostrare i possibili cammini che derivano direttamente da
un'attività. L'altro modo, invece, consiste nel rappresentare la transizione di un'attività con un
piccolo rombo e far seguire dal rombo stesso tutti i possibili cammini di flusso. Un altro modo
ancora stabilisce di indicare la condizione con un'istruzione racchiusa tra parentesi graffe vicino
il path appropriato.
57
_________________________________________________________________________________________________________
Si immagini di doversi recare al lavoro. Le fasi che descrivono tale processo saranno: aprire
la macchina, inserire le chiavi nel cruscotto e quindi scegliere tra le seguenti due situazioni:
•
La macchina si avvia regolarmente;
•
La macchina non si avvia.
Questi due possibili casi produrranno due altre attività:
•
Guidare la macchina;
•
Recarsi alla fermata del autobus (oppure prendere un taxi, la bicicletta o andare a
piedi).
Tale tipo di scenario viene rappresentato nel seguente grafico (si presti attenzione ai due modi
di mostrare una decisione):
Figura 1.43: Grafico decisonale
Path Concorrenti
Quando si esegue il modellamento di attività, molto frequentemente si verificherà la
necessità di dover separare le transizioni in due cammini separati che vengano eseguiti allo
stesso tempo (concorrentemente).
58
_________________________________________________________________________________________________________
Una tale suddivisione viene rappresentata da una linea continua in grassetto, perpendicolare
alla transizione e che mostri i cammini che avvengono al di fuori dalla linea stessa. Per
rappresentare un "merge" successivo delle due attività, si fanno convergere i cammini verso
un'altra linea in grassetto (fig. 1.44).
Figura 1.44: Merge di attività
Segnali
Durante una sequenza di attività, è possible inviare un segnale. Quando viene ricevuto, il
segnale causa la creazione di un'attività.
Il simbolo per inviare un segnale è un pentagono convesso, mentre il simbolo per
rappresentare il segnale ricevuto è un poligono concavo.
Swimlanes
L'activity diagram definisce anche la possibilità visualizzare i ruoli. Per far ciò, si separa il
diagramma in segmenti paralleli, chiamati swimlanes (corsie di nuoto). Ogni swimlane mostra
59
_________________________________________________________________________________________________________
il nome di un determinato ruolo in cima e mostra le attività di quel ruolo. Le transizioni
possono anche coinvolgere due swimlane.
È possibile combinare l'activity diagram con i simboli di altri diagrammi e così produrre un
diagramma ibrido.
Interfacce e Componenti: un approfondimento
Si è visto, finora, come i diagrammi descritti abbiano a che fare, in generale, con entità
concettuali. Adesso si vedranno, invece, diagrammi UML che rappresentano entità del mondo
reale: i componenti software (software component).
Innanzitutto: cos'e' un software component ? Nient'altro che una parte fisica di un sistema.
Esso risiede in un computer e non nella mente di un analista. Come si possono relazionare un
componente ed una classe?
Basta pensare ad un componente come all'implementazione di una classe. La classe
rappresenterà un'astrazione di un insieme di attributi ed operazioni. Ed un componente può
essere visto come l'implementazione effettiva di una classe. È importante modellare i
componenti e le relazioni che intercorrono tra di essi, in quanto:
•
I clienti possono vedere la struttura del sistema terminato;
•
Gli sviluppatori hanno una struttura alla quale rifarsi e attorno alla quale incentrare il
loro lavoro;
•
Coloro che si occupano di scrivere la documentazione e i file di help si rendono conto
meglio della funzionalità del sistema e quindi riescono a creare dei documenti più
efficienti.
Quando si ha a che fare con i componenti, inevitabilmente si deve avere a che fare con le
loro interfacce. Un'interfaccia, come visto, rappresenta la "faccia" dell'oggetto verso il mondo
esterno in modo tale che altri oggetti possano chiedere all'oggetto che espone l'interfaccia di
eseguire le sue operazioni che sono nascoste dall'incapsulamento.
Per l'analista che si occupa di disegnare il modello questo si traduce nel fatto che il modo in
cui si rappresenta un'interfaccia per una classe è lo stesso del modo in cui si rappresenta
un'interfaccia per un componente. La relazione tra un'interfaccia e una classe (anche qui allo
stesso modo) viene detta realizzazione (si veda quanto detto nel paragrafo Interfacce e
Realizzazioni).
60
_________________________________________________________________________________________________________
È possibile rimpiazzare un componente con un altro se il nuovo componente è conforme alle
stesse interfacce del vecchio. Il riutilizzo di un componente di un altro sistema è possibile se il
nuovo sistema può accedere al componente stesso attraverso le sue interfacce.
Fondamentalmente, dal punto di vista della modellazione UML, ci sono tre tipi di
componenti:
•
Deployment components. Che rappresentano la base dei sistemi eseguibili (DLL,
eseguibili, Controlli Active X, Java Beans);
•
Work Product Components: dai quali vengono creati i deployment components (e
quindi: file di dati e file sorgenti);
•
Execution Components, creati come risultato del sistema in esecuzione.
Infine, è da notare che quando un componente accede ai servizi di un altro componente
utilizza un interfaccia di import. Viceversa, il componente che realizza l'interfaccia con dei
servizi fornisce una interfaccia di export.
Component Diagrams
La principale icona di un component diagram è un rettangolo che, a sua volta, comprende
due rettangoli più piccoli incastrati nel suo lato sinistro. Il nome del componente va inserito
all'interno del rettangolo principale. Se il componente è un elemento di un package, è
consigliabile far precedere il nome del componente dal nome del package.
Figura 1.45: Component diagram
Un componente e le interfacce che esso utilizza sono rappresentabili in due modi:
•
Mostrando l'interfaccia come un rettangolo che contiene l'informazione relativa
all'interfaccia. Il rettangolo è connesso al componente tramite una linea tratteggiata e
un rettangolo che visualizza la realizzazione dell'interfaccia;
61
_________________________________________________________________________________________________________
•
Utilizzando un piccolo cerchio connesso al componente tramite una linea continua che
rappresenta la relazione di realizzazione dell'interfaccia.
Figura 1.46: Rappresentare un’interfaccia – primo modo
Modo 1: Un'interfaccia può essere rappresentata come un rettangolo, connesso al componente
tramite una linea tratteggiata che termina con una freccia (fig. 1.46).
Figura 1.47: Rappresentare un’interfaccia – secondo modo
Modo 2: Un'interfaccia può essere rappresentata anche come un piccolo cerchio, connesso al
componente tramite una linea tratteggiata che termina con una freccia (fig. 1.47).
Component Diagram - Un esempio
Si supponga di voler costruire un software per ascoltare della musica registrata su un CDROM. Per la scrittura di un siffatto programma ci si potrebbe avvalere di un linguaggio di
programmazione visuale come il Visual C++ o il Visual Basic, per esempio. Se il linguaggio
utilizzato supporta dei controlli multimediali, allora si potranno usare direttamente od
eventualmente riprogrammarli se necessario. Un possibile disegno grafico per il CD-player
potrebbe essere (fig. 1.48):
Figura 1.48: Music player
62
_________________________________________________________________________________________________________
Come è possibile vedere il programma necessita dei seguente controlli:
•
play, stop, eject, pause
•
fast forward, rewind
•
power.
Tali controlli saranno realizzati con l'utilizzo di bottoni, appositamente utilizzati per
ciascuno di essi. Se si guarda ogni bottone come un componente separato, è possibile ricavarne
il seguente component diagram UML (fig. 1.49).
Figura 1.49: Esempio di componet diagram
Come si vede, tutti i componenti mostrati nel diagramma appartengono ad un unico
componente globale, il Bottone, anche se le azioni che essi eseguono sono differenti. Tali
azioni saranno ottenute programmandole una ad una.
63
_________________________________________________________________________________________________________
1.12 Deployment Diagrams
Nessun sistema software potrebbe mai funzionare correttamente se non si basasse su una
solida struttura hardware. Per tale motivo, il Deployment Diagram modella proprio questo
aspetto del sistema.
Riesaminando un attimino il cammino fatto si può notare come si sia partiti da elementi di
analisi, per poi passare ai componenti che vivono nei computer ed infine, all'hardware che vive
nel mondo reale.
Come detto, l'hardware è un elemento primario nella composizione di un sistema a
multicomponenti. L'UML fornisce dei simboli che hanno il compito di favorire la creazione di
un quadro chiaro di come il settaggio e la composizione finale dell'hardware dovrà essere.
L'elemento principale dell'hardware è costituito da un nodo (node), che costituisce un nome
generico per ogni tipo di risorsa hardware.
Sono definiti due tipi fondamentali di nodi:
•
Il processore, ovvero un nodo che può consentire l'esecuzione di un componente
•
Un device, un nodo che tipicamente si interfaccia con il mondo esterno, e che non può,
invece, eseguire alcun componente.
Si considerino ora gli elementi grafici UML del deployment diagram. Un cubo rappresenta un
nodo. Un nodo ha un suo nome ed è possibile anche usare uno stereotipo per indicare il tipo di
risorsa che esso rappresenta. Se un nodo (fig. 1.50) fa parte di un package, allora il nome del
package deve precedere il nome del nodo. Una linea che unisce due cubi rappresenta una
connessione tra i due nodi. È possibile usare anche uno stereotipo per fornire informazioni sulla
connessione.
Figura 1.50: rappresentazione di un nodo nel deployment diagram
Ogni nodo comprende alcuni dei componenti schierati nel sistema. Per indicare tali
componenti si inserisce una relazione di dipendenza tra essi e il nodo cui appartengono.
64
_________________________________________________________________________________________________________
Di seguito si vedrà, per esempio, di costruire un deployment diagram per un sistema
informatico domestico. Il computer consiste dei seguenti elementi hardware:
•
Una CPU
•
Un monitor
•
Una stampante
•
Un mouse
•
Una tastiera
Per quanto concerne il software si potrà avere, ad esempio:
•
Windows 98
•
Office 2000
•
Internet Explorer 5.0
•
Front Page
•
Dos,
•
Norton Commander
•
Visual C++
Figura 1.51: Esempio di deployment diagram
65
_________________________________________________________________________________________________________
Il nodo principale è rappresentato dalla CPU che, a sua volta, è composto di svariati
componenti software collegati tra di loro da opportune relazioni. Gli altri elementi hardware
sono i devices connessi all'unità centrale.
Si può estendere questo diagramma aggiungendo un modem ed una connessione ad Internet.
I deployment diagram si rivelano particolarmente utili nel disegno e nel modellamento di reti di
calcolatori.
Deployment Diagram - Un esempio
Se si ha familiarità con le reti di calcolatori questi concetti saranno banali. In caso contrario,
sarà utile soffermarsi per comprendere meglio l'esempio.
La thin Ethernet è una rete di calcolatori molto comune. Essa viene utilizzata in luoghi
circoscritti, come stanze o palazzi, dove la connessione dei cavi può essere facilmente
realizzata. Esistono alcuni calcoli matematici necessari per definire la lunghezza dei cavi di
tutta la rete e la lunghezza dei cavi che connettono due computer. Tali calcoli, comunque, non
sono importanti per la realizzazione del deployment diagram.
I Computer si connettono al cavo di rete tramite dei dispositivi di connessione chiamati Tconnectors. I T-connectors hanno tre punti di connessione e la loro forma (da cui deriva il
nome) è simile alla lettera T (figura 1.52).
Figura 1.52: T-connector
Il cavo di rete entra da un lato del connector ed esce dall'altro opposto mentre il terzo punto
di connessione va direttamente al computer. Poiché la lunghezza della rete è limitata, I punti
finali del cavo necessitano di particolari dispositivi denominati terminatori (Terminator). Una
rete locale può, a sua volta, essere connessa ad un'altre rete locale tramite un ripetitore, ovvero
di un dispositivo che amplifica il segnale per ridurre il rischio di perdita di segnale (vedi fig
1.53).
66
_________________________________________________________________________________________________________
Figura 1.53: Rete di calcolatori
Una volta definiti i capisaldi di una rete thin Ehernet è possibile disegnarne il relativo
Deployment Diagram:
Figura 1.54: Deployment diagram finale
67
_________________________________________________________________________________________________________
I simboli grafici UML
Vistà la quantità dei simboli grafici utilizzati nei diagrammi UML sarà, sicuramente, utile
fare un breve riepilogo.
Elementi Strutturali
Figura 1.55: Elementi strutturali
Elementi Comportamentali
Figura 1.56: Elementi comportamentali
Relazioni
Figura 1.57: Relazioni
Raggruppamento
Figura 1.58: Raggruppamento
68
_________________________________________________________________________________________________________
Estensioni
<<Stereotipo>>
{Constraint}
Annotazioni ed Actor
Figura 1.59: Annotazioni e actor
69
_________________________________________________________________________________________________________
2 LE S-FUNTIONS
2.1 Introduzione alle S-Functions
Che cos’è una S-Function
Una S-Function è una descrizione, di un sistema dinamico, realizzata attraverso un
linguaggio di programmazione, il cui codice può essere scritto utilizzando i linguaggi Matlab o
C. Le S-Function scritte con quest’ultimo linguaggio sono compilate come MEX-file (Memory
Executable) utilizzando il comando mex disponibile all'interno dell'ambiente Matlab.
Il codice generato è contenuto in una libreria dinamica o DLL (Dynamic Link Library), che
viene invocata dal Matlab in modo dinamico, ovvero Matlab, nel momento in cui Simulink ne
richiede l'uso, cerca la DLL nel path di lavoro e ci si collega utilizzando le funzioni che la DLL
esporta. Una volta effettuato, il collegamento diventa stabile (la DLL risulta in permanente
utilizzazione da parte del Matlab) per cui non è più cancellabile (da Explorer) o modificabile
(da un programma esterno a Matlab) finché dal Matlab stesso non viene eseguita l'istruzione
"clear mex" o viene ricompilata di nuovo tramite l'istruzione "mex".
La forma di una S-Function è molto generale e può descrivere sistemi continui, discreti e
ibridi. Quasi tutti i modelli Simulink possono essere, quindi, realizzati come S-Function.
Le S-Function vengono inglobate nei modelli Simulink utilizzando il blocco S-Function nella
sottolibreria Nonlinear Block (Matlab 5.x) o User-Defined Blocks (Matlab 6.x). Accedendo alla
finestra di dialogo del blocco è possibile specificare il nome della S-Function da utilizzare.
Si tenga presente che qualora esistano due S-Function, di cui una scritta come C MEX-file e
l’altra come M-file (Matlab file), sarà la prima ad essere utilizzata. Si possono utilizzare le
finestre di Simulink e le relative istruzioni per inserire documentazioni inerenti al blocco,
inserire parametri additivi e così via.
Quando utilizzare una S-Function
L’utilizzo più comune di una S-Function è come blocco utente di Simulink. E’ possibile
utilizzarle in svariate applicazioni, tra cui:
•
Aggiunta blocchi di utilità generale a Simulink;
•
Inserimento codice C già esistente in una simulazione;
70
_________________________________________________________________________________________________________
•
Descrizione un sistema come una sequenza di istruzioni;
•
Utilizzo animazioni grafiche;
•
Aumento della velocità di simulazione integrando codice C.
Una stessa S-function può essere utilizzata in più punti della stessa simulazione,
modificando solamente i parametri con cui la S-function viene invocata.
Ciascun blocco interno ad un modello Simulink possiede le seguenti caratteristiche generali:
un vettore degli ingressi u, un vettore delle uscite y, ed un vettore degli stati x, come mostrato
nella seguente figura:
Figura 2.1: Schema a blocchi di una s-funtion
Il vettore degli stati può contenere stati continui, discreti, o una combinazione di essi. Le
relazioni matematiche tra ingressi, uscite, e stati sono espresse dalle seguenti equazioni:
•
Uscite: y = f0(t,x ,u)
•
Derivata: dx/dt = fd(t,x,u)
•
Aggiornamento: xd(k+1) = fu (t, x, u) dove x = [xc , xd].
Il vettore degli stati viene quindi suddiviso in due parti: una contenete gli stati continui e
l’altra i discreti. Gli stati continui occupano la prima parte del vettore, e i discreti la seconda.
Per blocchi privi di stati x è un vettore vuoto. Nei MEX-file delle S-Function, ci sono due
vettori separati per gli stati continui e discreti.
Stadi di simulazione e routine di S-Function
Durante l’esecuzione di un modello, Simulink effettua chiamate successive ai singoli
blocchi, e quindi anche alle S-Function, per realizzare su di essi specifiche operazioni relative
allo stadio attuale in cui si trova la computazione, es. inizializzazione del blocco, definizione
dei parametri, calcolo delle uscite e così via. La successione di questi stadi può essere
visualizzata con il presente diagramma di flusso (fig. 2.2):
71
_________________________________________________________________________________________________________
Figura 2.2: Come Simulink esegue la simulazione
L’esecuzione di questi passi è realizzata mediante routine che eseguono il loro compito
durante ciascun passo. Queste azioni si possono classificare come:
•
Inizializzazione – Durante questo stadio Simulink:
1. Inizializza SimStruct, una struttura che contiene informazioni sulla S-Function;
2. Definisce numero e dimensione delle porte di ingresso e di uscita;
3. Definisce gli istanti di campionamento;
4. Predispone aree di memorizzazione e l’array size;
•
Calcolo del prossimo istante di campionamento
(se si sta utilizzando un passo
variabile si effettua il calcolo del successivo istante di campionamento);
72
_________________________________________________________________________________________________________
•
Calcolo dell’uscita nell’istante di campionamento principale (al completamento di
questa fase le uscite del blocco saranno disponibili nell’istante di tempo attuale);
•
Aggiornamento degli stati discreti nell’intervallo principale (ciascun blocco esegue
l’aggiornamento degli stati discreti per il prossimo istante);
•
Integrazione: questa si applica a modelli con stati continui e/o attraversamenti dello
zero non campionati. Se la S-Function lavora con stati continui il calcolo delle uscite e
delle derivate della S-Function avviene nell’istante di tempo secondario. Se la SFunction ha attraversamenti dello zero non campionati, Simulink calcola le uscite e gli
attraversamenti dello zero nell’istante secondario.
Stadi di simulazione e routine di S-Function
Le C-MEX S-Function sono realizzate come funzioni in linguaggio C. Esiste un set di
routine per S-Function che vengono chiamate direttamente da Simulink per eseguire il loro
compito e possono essere utilizzate nella scrittura delle S-Function.
Le routine C-MEX S-Function devono contenere le funzioni definite nella tabella 2.1. La
presenza di maschere predefinite (vedi sfuntmpl.c e sfuntmpl.doc, situate nella directory
simulink/src) forniscono un adeguato sostegno alla scrittura del codice. Se ne consiglia l’uso al
fine di limitare errori di scrittura.
Stadio della Simulazione
Inizializzazione
Calcolo istante camp. succ. (facoltativo)
Calcolo uscite
Aggiornamento stadi discreti
Calcolo derivate
Fine simulazione
Routine S-Function
mdlInitializeSizes
mdlGetTimeOfNextVarHit
mdlOutputs
mdlUpdate
mdlDerivatives
mdlTerminate
Tabella 2.1: Stadi di simulazione
Una piena comprensione dei seguenti concetti aiuterà ad una corretta scrittura delle SFunction:
•
Direct feedthrough;
•
Ampiezza ingresso impostata dinamicamente;
73
_________________________________________________________________________________________________________
•
Impostazione tempo di campionamento e offset;
Direct Feedthrough
Con questo termine si definisce la caratteristica dell’algoritmo di presentare un’influenza
diretta degli ingressi sulle uscite. Una S-Function ha questa caratteristica se:
•
La funzione di uscita (mdlOutputs) è una funzione dell’ingresso u. C’è quindi un direct
feedthrough quando le istruzioni interne a mdlOutputs utilizzano la variabile d’ingresso
u. Per uscite s’intendono anche quelle grafiche (Scope, XY Graph, ecc.);
•
La S-Function ha un passo di campionamento (chiamata a mdlGetTimeOfNextVarHit)
variabile dipendente da u.
Un esempio di algoritmo che non richiede direct feedthrough è il seguente:
•
Uscite: y = x
•
Derivata: dx/dt = u
dove x è lo stato, dx/dt è la derivata rispetto al tempo, u è l’ingresso e y l’uscita.
Impostazione dinamica dell’ampiezza dell’ingresso
Le S-Function possono essere realizzate in modo tale da prevedere un’impostazione
dinamica dell’ampiezza dell’ingresso, determinata cioè a tempo di esecuzione e stabilita
dall’ampiezza delle uscite dei blocchi collegati alla S-Function, essa può essere utilizzata per
definire il numero di stati continui, discreti e il numero di uscite.
Le C-MEX S-Function consentono, quindi, di definire porte di accesso e di uscita multiple
di forma vettoriale. Si analizzeranno in seguito esempi in tal senso.
Impostazione del tempo di campionamento e dell’ offset
Le C-MEX S-Function consentono un alto grado di flessibilità nello stabilire quando
avviene l’esecuzione fornendo il seguente insieme di scelte:
74
_________________________________________________________________________________________________________
•
Campionamento continuo: per S-Function che hanno stati continui e/o zeri non
campionati. In questo caso le uscite cambiano nell’istante di tempo secondario;
•
Tempo di campionamento continuo ma fisso nell’istante di tempo secondario: per SFunction che necessitano di esecuzione ad ogni passo di simulazione principale, ma
non cambia valore durante quello secondario;
•
Tempo di campionamento discreto: per S-Function il cui comportamento è funzione di
intervalli discreti, si può quindi definire un tempo in cui Simulink chiama il blocco ed
anche un ritardo (offset) nel campionamento, es.:
TimeHit = (n * period) + offset
Dove n è un intero, e il suo primo valore è sempre zero;
•
Tempo di campionamento variabile: tempo di campionamento la cui ampiezza viene
definita all’inizio di ciascun passo di campionamento e può variare da passo a passo;
•
Tempo di campionamento ereditato: quando l’S-Function non ha caratteristiche interne
particolari, stati continui, discreti ecc., è possibile far si che assuma il tempo di
campionamento dei blocchi che in qualche modo ne influenzano il comportamento, ad
es.:
1. Il blocco connesso all’ingresso
2. Il blocco di destinazione
3. Il tempo di campionamento più veloce nel sistema.
Si potranno definire questi parametri utilizzando le routine di S-Function appropriate.
Esempi di C-MEX S-Function si trovano nella directory simulink/src, tra questi se ne citano
alcuni: timestwo.c, csfunc.c, dsfunc.c, dlimint.c, vsfunc.c, mixed.c.
2.2 Guida alla scrittura delle S-Functions
Introduzione
La realizzazione di una S-Function mediante linguaggio C, come già detto in precedenza,
deve sottostare ad una serie di regole che hanno come scopo la realizzazione di un C MEX-file
(C Matlab Executable file) che interagisca con Simulink e con l’ODE solver per l’esecuzione
75
_________________________________________________________________________________________________________
dei singoli passi di calcolo che portano alla simulazione del modello (definizione delle
condizioni e delle caratteristiche iniziali del blocco, calcolo delle derivate, stati discreti e uscite
del blocco).
Un utile strumento per la compilazione del codice è fornito da sfuntmpl.c, un file di codice
C, e dal relativo file sfuntmpl.doc, entrambe presenti nella directory simulink/src.
Un semplice esempio di C-MEX S-Function è il seguente:
#define S_FUNCTION_NAME
your_sfunction_name_here
#define S_FUNCTION_LEVEL 2
#include “simstruct.h”
static void mdlInitializeSizes(SimStrusct *S)
{
}
<aggiunta routine/codice di S-Function >
static void mdlTerminate(SimStruct *S)
{
}
#ifdef MATLAB-MEX_FILE
/* Il file è stato compilato come MEX-file? */
#include “simulink.c”
/* Interfaccia tra Simulink e MEX-file */
#else
#include “cg_sfun.h”
/* Funzione per la registrazione della*/
/* generazione del codice */
#endif
La routine mdlInitializeSizes è solo una, la prima in genere ad essere chiamata quando
Simulink interagisce con la S-Function, delle tante routine del tipo mdl* che devono essere
utilizzate nella compilazione del codice. Il contenuto delle suddette routine è stabilito dal
programmatore e varia con il tipo di S_Function che viene implementata. L’ultima routine ad
essere chiamata da Simulink è mdlTerminate che termina l’esecuzione del blocco.
Le informazioni relative alla S_Function sono contenute in una struttura dati chiamata
SimStruct. L’inclusione nel codice, mediante l’istruzione #include, del file simstruc.h fornisce,
76
_________________________________________________________________________________________________________
oltre alla dichiarazione della struttura, anche un insieme di macro mediante le quali è possibile
accedere, copiare e leggere dati dalla struttura.
Scrittura delle C-Mex S-Functions
Si forniranno ora dei semplici esempi di S-Function, dove per “semplici” si intende:
contenenti quelle routine che devono essere sempre presenti anche se vuote, cioè prive di
codice. Uno di questi esempi è quello della S_Function timestwo che prende un ingresso e lo
moltiplica per due (vedi matlabroot/simulink/src/timestwo.c).
Il modello simulink che la rappresenta è il seguente (fig. 2.3):
Figura 2.3: Schema simulink
Il blocco S_Function è stato prelevato dalla libreria Simulink ed inoltre è stato modificato il
nome del blocco in timestwo accedendo alla finestra delle proprietà, non sono stati specificati
altri parametri. Il codice che è stato scritto per la S_Function rispetta il seguente schema (fig.
2.4):
Figura 2.4: Schema di funzionamento
77
_________________________________________________________________________________________________________
E’ necessario quindi che le suddette routine siano inserite nel codice della S_Function; in
questo caso sono state digitate all’interno di un file di nome timestwo.c.
La successiva esecuzione del comando:
mex timestwo.c
dal prompt di Matlab permette a quest’ultimo di eseguire la compilazione e il link di questo
programma, creando un file caricabile ed eseguibile da Simulink. Ciò che ne risulta è un file di
tipo MEX la cui estensione, se si lavora in ambiente Windows, è .dll. Il codice di
quest’esempio è dato dal seguente listato:
#define S_FUNCTION_NAME
timestwo
#define S_FUNCTION_LEVEL 2
#include "simstruc.h"
static void mdlInitializeSizes(SimStruct *S)
{
ssSetNumSFcnParams(S, 0);
if (ssGetNumSFcnParams(S) != ssGetSFcnParamsCount(S))
{
return; /* Parameter mismatch will be reported by Simulink */
}
if (!ssSetNumInputPorts(S, 1)) return;
ssSetInputPortWidth(S, 0, DYNAMICALLY_SIZED);
ssSetInputPortDirectFeedThrough(S, 0, 1);
if (!ssSetNumOutputPorts(S,1)) return;
ssSetOutputPortWidth(S, 0, DYNAMICALLY_SIZED);
ssSetNumSampleTimes(S, 1);
ssSetOptions(S, SS_OPTION_EXCEPTION_FREE_CODE);
}
static void mdlInitializeSampleTimes(SimStruct *S)
{
ssSetSampleTime(S, 0, INHERITED_SAMPLE_TIME);
ssSetOffsetTime(S, 0, 0.0);
78
_________________________________________________________________________________________________________
}
static void mdlOutputs(SimStruct *S, int_T tid)
{
int_T
i;
InputRealPtrsType
uPtrs
=
ssGetInputPortRealSignalPtrs(S,0);
real_T
*y
= ssGetOutputPortRealSignal(S,0);
int_T
width = ssGetOutputPortWidth(S,0);
for (i=0; i<width; i++) {
*y++ = 2.0 *(*uPtrs[i]);
}
}
static void mdlTerminate(SimStruct *S)
{
}
#ifdef
MATLAB_MEX_FILE
#include "simulink.c"
/* Is this file being compiled as a MEX-file? */
/* MEX-file interface mechanism */
#else
#include "cg_sfun.h"
/* Code generation registration function */
#endif
E’ utile a questo punto fornire ulteriori spiegazioni relative all’esempio fornito.
•
Istruzioni define ed include: queste due istruzioni vengono utilizzate per informare
Simulink che si intende realizzare una funzione di livello due (specificare sempre
quest’opzione) ed il nome di questa, oltre a fornirgli il riferimento (il file header
simstruct.h) in cui trovare la struttura dati SimStruct utilizzata dal modello;
•
mdlInitialize specifica i seguenti parametri:
1. Zero parametri: significa che il campo S-function parameters nella finestra di
dialogo della S_Function è vuota;
2. Una porta di ingresso e una di uscita: le ampiezze delle porte di ingresso e
uscita sono stabilite dinamicamente, Simulink moltiplicherà ciascuna linea
d’ingresso (nel caso in cui tale porta sia un vettore n-dimensionale) per due e
renderà tali valori disponibili in uscita;
79
_________________________________________________________________________________________________________
3. Singolo istante di campionamento. E’ necessario specificare il tempo di
campionamento nella routine mdlInitializeSampleTimes;
4. Il codice è exception free. Qualora il codice non preveda chiamate a funzioni
esterne che interrompono l’esecuzione di Simulink è opportuno specificare
questa opzione che contribuisce a rendere il codice più efficiente;
•
mdlInitializeSampleTimes: il tempo di campionamento è acquisito dal blocco che
precede la S_Function quindi funzionerà bene con qualsiasi blocco connesso in
ingresso;
•
mdlOutput: il calcolo numerico. mdlOutput dice a Simulink di moltiplicare il segnale
d’ingresso per 2.0 e mettere il risultato nel segnale d’uscita. Per accedere al segnale
d’ingresso si utilizza:
InputRealPtrsType uptrs=ssGetInputPortRealSignaluPtrs(S,0)
dove uPtrs è un vettore di puntatori e ai cui elementi si accede così:
Elementoi = *uPtrs[i]
Per accedere al segnale d’uscita si utilizza:
real_T *y = ssGetOutputPortRealSignal(S,0)
che fornisce un array contenente i valori in uscita;
•
mdlTerminate: in questo caso particolare non c’è bisogno di eseguire nessuna azione
conclusiva;
Istruzioni richieste all’inizio di una S-Function
Ogni programma che definisce una S_Function deve necessariamente cominciare con il
seguente blocco di istruzioni:
#define S_FUNCTION_NAME your_sfunction_name_here
#define S_FUNCTION_LAVEL 2
80
_________________________________________________________________________________________________________
#include “simstruct.h”
dove your_sfunction_name_here indica il nome della S_Function che ci si appresta a realizzare
e le altre istruzioni definiscono: la prima il tipo di livello della S_Function, la seconda dice a
Simulink dove trovare le macro mediante le quali accedere alla struttura dati simstruct.
Istruzioni richieste alla fine di una S-Function
Il codice seguente va invece incluso al termine del main della S_Function:
#ifdef MATLAB-MEX_FILE
/* Il file è stato compilato come MEX-file? */
#include “simulink.c”
/* Interfaccia tra Simulink e MEX-file */
#else
#include “cg_sfun.h”
/* Funzione per la registrazione della generazione del codice */
#endif
Queste istruzioni provvedono ad instradare la S_Function verso l’applicazione scelta, Simulink
o Real-Time Workshop.
Combinazione condizionata delle S-Functions
La compilazione delle S_Function può essere effettuata nei seguenti modi:
•
MATLAB_MEX_FILE : indica che la S_Function è stata realizzata come MEX-file
per essere utilizzata con Simulink;
•
RT: indica che la S_Function è stata costruita con codice generato da Real-Time
Workshop per applicazioni in tempo reale utilizzanti un solver a passo fisso;
•
NRT: indica che la S_Function è stata costruita mediante codice generato da Real-Time
Workshop per un’applicazione non in tempo reale che utilizza un solver a passo
variabile.
Gestione degli errori
Durante la realizzazione di S_Function può essere utile introdurre dei controlli che
determinino la correttezza degli eventi che si susseguono con il fine di interrompere
l’esecuzione e visualizzare un opportuno messaggio di errore. Nell’esempio della funzione
81
_________________________________________________________________________________________________________
timestwo non erano necessari molti controlli, si effettua solo un controllo sul numero di
parametri nella funzione mdlInitializeSizes, ma per altre funzioni potrebbe essere importante
prevedere maggiori controlli. Il procedimento da usare nel trattamento degli errori è di
utilizzare il seguente codice:
ssSetErrorStatus(S,”errore rilevato dovuto a ….”);
return;
Si noti che la stringa di caratteri contenente il messaggio di errore deve risiedere in un area
di memoria persistente. Pertanto una soluzione come quella che segue non può essere accettata:
mdlOutputs( )
{
char msg[256];
// ERRORE: specificare “static char msg[256];
sprintf(msg,”errore dovuto a %s , string );
ssSetErrorStatus(S,msg);
return;
}
L’approccio suggerito in questo paragrafo è alternativo all’utilizzo della funzione
mexErrMsgTxt la quale, in caso di errore, interrompe la S_Function e restituisce il controllo a
Simulink, in questo caso l’S_Function non sarebbe exception free con la conseguenza che il
codice non risulterà ottimizzato, come già accennato in precedenza. Si consiglia quindi di
evitare l’utilizzo di funzioni come mexErrMsgTxt o mxCalloc, una funzione per l’allocazione di
memoria, e di scrivere codice exception free utilizzando il seguente comando all’interno di
mdlInitializeSizes:
ssSetOptions(S,SS_OPTION_EXCEPTION_FREE_CODE);
Di questo ne beneficeranno le prestazione della S_Function. Le routine che non generano
interruzioni sono quelle che accedono ai puntatori e modificano i parametri, per esempio le
routine
mxGetPr,
mxGetData,
mxGetNumberOfDimensions,
mxGetM,
mxGetN,
e
mxGetNumberOfElements.
Ci sono routine chiamate durante l’esecuzione della S_Function che potrebbero contenere
interruzioni, tra cui:
82
_________________________________________________________________________________________________________
•
mdlGetTimeOfNextVarInt
•
mdlOutputs
•
mdlUpdate
•
mdlDerivatives
Se ne sono prive conviene specificare la nostra S_Function come exception free nel modo già
spiegato.
Se il codice è exception free ed è stato predisposto il trattamento degli errori
(ssSetErrorStatus) in caso di errore Simulink interromperà l’esecuzione e visualizzando il
messaggio. In caso di errore di gestione della memoria o altri errori critici, l'assenza
dell'opzione SS_OPTION_EXCEPTION_FREE_CODE può portare alla chiusura di Simulink o
ad un comportamento imprevedibile da parte del Matlab.
2.3 Panoramica sulle Routines
La sequenza in cui vengono chiamate le ruotine delle S_Function varia a seconda
dell'ambiente (Target) per cui viene costruito l'eseguibile.
Struttura di chiamata per Real Time Workshop
Se si sta utilizzando Real Time Workshop per produrre il codice della S_Function non è
necessario inserire nel programma tutta la struttura vista nel precedente paragrafo, ma basta
rispettare il seguente schema (vedi fig. 2.5 a pagina seguente):
83
_________________________________________________________________________________________________________
Figura 2.5: Sequenza di esecuzione per Real Time Workshop
Struttura di chiamata per modalità esterna
Anche quando si esegue Simulink in modalità esterna (external mode) la sequenza di
chiamata di routine è differente e rispetta lo schema in figura 2.6:
Figura 2.6: Sequenza di esecuzione in modalità esterna
84
_________________________________________________________________________________________________________
La chiamata alla routine mdlRTW viene effettuata una volta, quando si accede alla modalità
esterna, ed ogni volta che si seleziona Update Diagram dal menu Edit del blocco S_Function.
Trattamento dati nelle S-Functions
I blocchi S_Function sono provvisti di segnali di input e output, parametri, stati interni del
blocco, più aree di memoria riservate. La lettura e la scrittura dei segnali di input e output
avviene tramite gli altri blocchi del modello collegati alla S_Function, che generalmente hanno
ingressi e/o uscite vettoriali. Gli ingressi possono anche essere del tipo:
•
Ingressi esterni attraverso i blocchi import;
•
Sconnessi, se non è presente alcun segnale.
Anche le uscite possono essere collegate a blocchi di tipo outport. I segnali di ingresso e
uscita possono avere anche le seguenti caratteristiche:
•
Stati continui
•
Stati discreti
•
Aree dati di tipo reale, intero, o vettori di puntatori
Alcuni parametri possono essere forniti alla S_Function direttamente nella finestra di
dialogo del blocco, si vedrà in seguito come.
Le lunghezze dei vari segnali e vettori può essere configurate per mezzo della routine
mdlInitializeSizes. L’accesso alla struttura contenente i parametri del blocco può essere
effettuato mediante i seguenti comandi:
nputRealPtrs
uPtrs = ssGet InputPortRealSignalPtrs(S,indiceporta)
che fornisce in uPtrs un array di puntatori, dove indiceporta che è un valore intero compreso
tra 0 e n-1 (con n numero di porte di ingresso). Per il generico elemento della porta si userà:
*uPtrs[elem]
Questi azioni corrispondono al seguente schema:
85
_________________________________________________________________________________________________________
Figura 2.7: Schema ingresso
Per accedere all’ingresso 1 (vedi fig. 2.6):
InputRealPtrs
uPtrs0 = ssGetInputRealSignalPtrs(S;0)
Per accedere all’ingresso 2:
InputRealPtrs
uPtrs1 = ssGetInputRealSignalPtrs(S;1)
Figura 2.8: Modalità di ingresso
86
_________________________________________________________________________________________________________
Come si può notare l’array di puntatori non indirizza necessariamente aree di memoria
contigue. Per quanto riguarda il segnale d’uscita vi si può accedere nel modo seguente:
real_T
*y = ssGetOutputPortSignal(S,indiceportauscita);
dove indiceportauscita ha lo stesso significato di indiceporta visto in precedenza. Di seguito
viene fornito un esempio di come accedere ai dati della porta di ingresso, leggendoli e
successivamente copiandoli, senza alterazioni, nella porta di uscita, si noti che in tal caso è
presente un direct feedthrough che va quindi opportunamente specificato, come visto
precedentemente.
int_T element;
int_T portWidth = ssGetInputPortWidth(S,inputPortIndex) ;
inputRealPtrs uPtrs = ssGetInputPortRealSignalPtrs(S,inputPortIndex);
real_T
*y = ssGetOutputPortSignal(S,outputPortIdx);
for (element=0; element<portWidth; element++)
{
y[element] = *uPtrs[element];
}
Errori comuni sono quelli compiuti sui puntatori, spesso, infatti, si pensa di potervi accedere
ponendo :
real_T
*uPtrs;
nel campo delle dichiarazioni, e utilizzare il seguente codice per copiare i dati:
*y++ = *u++
tutto ciò non è corretto.
Controllo ed elaborazione dei parametri
Si è già discusso della possibilità di introdurre parametri in modo interattivo, si proceda ora
all’analisi di come ciò avviene utilizzando il campo S_Function Parameters nella finestra di
87
_________________________________________________________________________________________________________
dialogo del blocco: Occorre determinare l’ordine in cui i parametri vengono forniti nella
finestra.
Nella funzione mdlInitializeSizes si utilizzi la macro ssSetNumSFcnParams per comunicare
a Simulink il numero di parametri. Si specifichi S (è un puntatore a SimStrusct) come primo
argomento della macro ed il numero di parametri come secondo. L’accesso a questi parametri,
all’interno della S_Function, è consentito mediante la macro ssGetSFcnParam, specificando
sempre S come primo argomento ed il numero d’ordine del parametro come secondo.
Si consideri quindi l’esempio di seguito riportato. Si inseriscano i seguenti comandi nella
sezione delle definizioni:
#define BASE_ADDRESS_PRM(S)
ssGetSFcnParams(S,0)
#define GAIN_RANGE_PRM(S)
#define PROG_GAIN(S)
#define NUM_OF_CHANNELS_PRM(S)
Questo codice definisce l’ordine in cui i valori o i nomi dei parametri vanno inseriti nel
campo S_Function Parameters della finestra di dialogo del blocco. La presenza di parametri
forniti interattivamente deve essere specificata inserendo:
ssSetSFcnParams(S,4);
all’interno della funzione mdlInitializeSizes.
Cambiamento dei parametri
Le routine che consentono all’utente di controllare ed elaborare i parametri aggiornati
all’interno della S_Function sono: mdlCheckParameters, interna a mdlInitializeSizes, e
mdlProcessParameters e possono essere usate solo all’interno di S_Function C-MEX.
L’utilizzo di questa caratteristica assume una importanza rilevante quando si usa Real-Time
Workshop, in tal caso deve essere attivata la funzionalità External mode. Quest’ultima pone i
dati aggiornati direttamente nel codice eseguibile contenuto in memoria solo dopo che
Simulink ha chiamato le precedenti routine ed effettuato le azioni che esse richiedono.
88
_________________________________________________________________________________________________________
Mediante le routine mdlCheckParameters e mdlInitializeSizes è infatti possibile controllare,
con la prima, ed elaborare, con la seconda, i parametri aggiornati della S-Function. I relativi
codici risultano essere:
mdlCheckParameters
#define MDL_CHECK_PARAMETERS
#if defined
(MDL_CHECK_PARAMETERS)
static void mdlCheckParameters(SimStruct *S)
{
}
#endif
mdlProcessParameters
#define MDL_PROCESS_PARAMETERS
#if defined(MDL_PROCESS_PARAMETERS)
static void mdlProcessParameters(SimStruct *S)
{
}
#endif
All’interno delle routine andrà inserito il codice opportuno per la validazione o
l’elaborazione dei parametri aggiornati.
Definizione delle caratteristiche di un blocco
Il campo sizes del record SimStruct contiene delle informazioni importanti sulla S_Function
quali il numero di ingressi, uscite, stati ed altre caratteristiche del blocco.Tale struttura è
inizializzata nella funzione mdlInitializeSizes ed i suoi valori possono essere letti e scritti
mediante delle macro.
mdlInitializeSizes
Come visto è la prima routine chiamata da Simulink e serve per specificare le caratteristiche di
un blocco (numero di ingressi, uscite, stati ecc.). Una di queste è la influenza diretta degli
ingressi sulle uscite (direct feedthrough) che va specificata settando un opportuno flag in
mdlOutput mdlGrtTimeOfNextVarHit.
89
_________________________________________________________________________________________________________
Possono essere specificati in questa funzione anche parametri come: NumContStates,
NumDiscStates, NumInputs, NumOutputs, NumRWork, NumIWork, NumPWork, NumModes e
NumNonSampledZCs, dando loro valori interi non negativi che ne specificano l’ampiezza
oppure specificando l’opzione DYNAMICALLY_SIZED che fa in modo che le ampiezze siano
stabilite dai blocchi visti come ingressi dalla nostra S_Function. Ci sono macro che permettono
di controllare delle informazioni, come:
ssGetInputPortConnected(S), ssGetOutputPortConnected(S)
che determinano il numero di porte connesse, oppure :
ssSetSFcnParamNotTunable(S,idparam)
che stabilisce quali parametri non possono cambiare in corso di simulazione.
Se le uscite sono discrete (ed assumono ad es. solo i valori 1 e 2) è opportuno specificare il
valore SS_OPTION_DISCRETE_VALUED_OUTPUT. Nella funzione mdlInitializeSizes è
inoltre possibile specificare la frequenza di campionamento, si vedrà meglio più avanti come
ciò sia possibile..
Configurazione delle proprietà di I/O
Nella funzione mdlInitializeSizes si sono specificate le ampiezze delle porte come un intero
non negativo. Se si specifica SS_OPTION_ALLOW_INPUT_SCALAR_EXPANSION ed un
intero positivo non nullo N, per una porta d’ingresso, allora l’ampiezza della rispettiva porta
sarà o 1 o N.
La routine ssGetInputPortWidth determina l’ampiezza attuale della porta specificata. Se
specifichiamo l’opzione DYNAMICALLY_SIZED l’ampiezza della porta verrà determinata da
Simulink all’atto della propagazione dei segnali durante l’esecuzione del modello.
L’assegnazione delle ampiezze avviene mediante le routine mdlSetInputPortWidth e
mdlSetOutputPortWidth, se non specificate si avrà una configurazione di default (scalare). Si
prendano in esame ora alcune routine in modo più approfondito:
90
_________________________________________________________________________________________________________
mdlSetInputPortSampleTime
Chiamata una volta pervenuto il tempo di campionamento, nel caso in cui sia ereditato da
blocchi precedenti, deve stabilire se questo è accettabile, in tal caso si può andare avanti ed
acquisire tale tempo utilizzando ssSetInputPortSampleTime, oppure no, in tal caso occorre
inviare un opportuno messaggio di errore mediante ssSetErrorStatus.
mdlSetOutputPortSampleTime
E’ l’equivalente della precedente per le porte d’uscita. Ovviamente in questo caso si utilizzerà
ssSetOutpuPortSampleTime.
mdlSetInputPortWidth
Chiamata durante la propagazione delle ampiezze dei vettori per controllare la validità
dell’ampiezza proposta. Anch’essa deve prevedere un messaggio di errore opportuno qualora
l’ampiezza fornita non sia valida.
mdlSetOutputPortWidth
E’ l’equivalente della routine precedente per le porte d’uscita.
Impostazione dei tempi di campionamento
Simulink prevede blocchi che vengono eseguiti a frequenze di campionamento differenti. I
modi previsti per determinare tali frequenze sono due:
•
Tempi di campionamento basati sul blocco (block based);
•
Tempi di campionamento basati sulla porta (port based).
Nel primo caso la S_Function specifica tutte le frequenze di campionamento del blocco ed
elabora ingressi ed uscite alla frequenza più elevata fra quelle specificate se ciascun tempo di
campionamento è multiplo intero di quello più veloce. Nel secondo caso, invece, la S_Function
specifica il tempo di campionamento per la porta di ingresso e di uscita. Per capire meglio i due
metodi si consideri il caso di due tempi, rispettivamente 0.5 (input) e 0.25 (output) secondi:
•
Nel primo caso Simulink effettuerà i calcoli con un periodo di 0.25 secondi;
91
_________________________________________________________________________________________________________
•
Nel secondo caso l’esecuzione dell’ingresso avviene ad una frequenza di 2Hz, mentre
l’aggiornamento dell’uscita a 4Hz.
Se quindi una specifica applicazione prevede tempi di campionamento disuguali, e si vuole
evitare di dover eseguire tutti i blocchi alla frequenza più alta, è preferibile utilizzare
l’impostazione port based. Per le applicazioni di tipo più comune è comunque sufficiente
l’impostazione block based.
Tempi di campionamento Block based
Quando si opta per una soluzione block based è necessario specificare delle informazioni. Si
deve, infatti, configurare l’S_Function per lavorare con tempi di campionamento block based
inserendo nella funzione mdlInitializeSizes l’istruzione:
ssSetNumSampleTimes(S,numsampletimes);
dove numsampletimes è un numero positivo, onde specificare il numero di istanti di
campionamento.
Poiché all’interno di questa funzione Simulink chiama mdlInitializeSampleTimes occorre, in
essa, specificare le seguenti informazioni:
•
Tempo di campionamento ed offset;
•
Chiamate a funzioni.
Nel primo caso si ricorrerà alle seguenti istruzioni:
ssSetSampleTime(S, sampletimePairIndex, sample_time)
ssSetOffsetTime(S, offsetTimePairIndex, offset_time)
Si consulti il manuale per maggiori informazioni sulle coppie [ sample_time , offset_time ].
Nel secondo si specificheranno quali elementi di uscita eseguono chiamate a funzioni mediante
la macro ssSetCallSystemOutput.
92
_________________________________________________________________________________________________________
Tempi di campionamento Port based
Se si opta per questa soluzione occorre, invece, definire le proprietà della S_Function nelle
seguenti routine:
mdlInitializeSizes
mdlSetInputPortSampleTime
mdlSetOutputPortSampleTime
Nella prima routine si specificheranno:
ssSetNumSampleTime(S,PORT_BASED_SAMPLE_TIMES)
insieme a:
ssSetInputPortSampleTime(S,idx,period)
ssSetInputPortOffsetTime(S,idx,offset)
ssSetputputPortSampleTime(S,idx,period)
ssSetOutputPortOffsetTime(S,idx,offset)
La seconda e la terza routine vengono chiamate solo nel caso di tempi di campionamento di
tipo inherited, cioè acquisiti da altri blocchi connessi al nostro, e dovrà, quindi, prevedere
controlli sull’accettabilità o meno del tempo acquisito, e, se questo è adeguato, provvedere
all’impostazione utilizzando le stesse macro della prima routine.
E’ possibile anche realizzare blocchi S_Function che prevedano un funzionamento
multirate, per il quale si rimanda ai manuali.
Configurazione di work vectors
Se la S_Function prevede l’utilizzo di memoria persistente (cioè un area di memoria statica
accessibile solo dall’istanza attuale della S_Function) è possibile utilizzare i work vectors al
posto di variabili di tipo static o global, altrimenti accessibili da più istanze della S_Function,
qualora fossero presenti più blocchi facenti riferimento allo stesso file C-MEX.
Questa caratteristica di possedere un area di memoria privata viene detta re-entrancy. Queste
aree di memoria definibili possono contenere tipi di dati interi, reali, puntatori e dati di tipo
generale (es. numero di stati continui, discreti, di modi e così via.).
93
_________________________________________________________________________________________________________
Le lunghezze di tali vettori vanno specificate, come sempre, all’interno di mdlInitializeSizes
con l’ausilio delle macro di sistema, tra cui:
•
ssSetNumContStates
•
ssSetNumDiscStates
•
ssSetNumRWork
•
ssSettNumIWork
•
ssSetNumPWork
•
ssSetNumModes
•
ssSetNumnonSampledZCs
Nell’utilizzare tali macro occorre specificare:
•
Il valore 0 se il vettore non è utilizzato;
•
Un intero (>0) che ne indica la dimensione;
•
DYNAMICALLY_SIZED, qualora la sua dimensione dipenda da altri blocchi, in tal caso
per determinare le dimensioni dei vettori si utilizza la routine mdlSetWorkWidths.
L’accesso alle strutture così definite avviene per mezzo delle macro del tipo ssGet* (es.
ssGetRWork), e tramite esse si possono inizializzare i valori dei vettori, in mdlStart o in
mdlInitializeConditions. Un caso a parte è rappresentato dai vettori mode-work e da quello
degli attraversamenti (nonsampled zero crossing) utilizzato per determinare i passaggi per lo
zero.
Allocazione di memoria
In alcuni casi la memoria messa a disposizione dai work vector definiti nel precedente
paragrafo può non essere sufficiente. In tal caso l’allocazione dinamica di memoria non può
essere effettuata mediante le macro standard del MATLAB API (Application Program
Interface) perché realizzate per MEX-file utilizzati da Matlab, non da Simulink. Il modo
corretto per allocare memoria è, quindi, quello di utilizzare le macro calloc e free presenti nella
libreria stdlib.h.
Si può dunque allocare, usando calloc, ed inizializzare la memoria in mdlStart ponendo il
puntatore (ptr) a quest’area in un vettore pointer-work, come quelli visti prima, facendo:
94
_________________________________________________________________________________________________________
ssGetPWork(S)[i] = ptr;
o collegarlo come dato utente:
ssSetUserData(S, ptr);
Attenzione: l’area di memoria non va liberata in mdlTerminate mediante la macro free.
Inizializzazione delle S-Functions
Questa operazione può essere effettuata per mezzo delle routine mdlStart e
mdlInitializeConditions, per definire i work vector o i segnali d’uscita della S_Function. La
prima routine viene chiamata da Simulink una sola volta all’inizio dell’esecuzione del modello.
La seconda all’inizio della simulazione e ogni volta che viene richiesta, se permessa, la
revisione degli stati.
3 LO STATEFLOW MATLAB
3.1 Introduzione
Lo stateflow è uno strumento di sviluppo grafico per sistemi basati sulla teoria delle
macchine a stati finiti ossia sistemi di controllo logici (controllore on-off, scheduler), o sistemi
di supervisione (controllori ad alto livello, ecc).
Una macchina a stati finiti, dunque, non è altro che la rappresentazione di un sistema a
eventi discreti la cui evoluzione è regolata dal susseguirsi di condizioni vere o false.
Tradizionalmente gli ingegneri utilizzavano le tavole di verità per rappresentare le
connessioni tra ingressi, uscite e stati. Tali tavole descrivevano la logica necessaria a
controllare il comportamento del sistema preso in esame.
L’approccio utilizzato da Stateflow per descrivere un sistema a stati discreti è quello di
modellarne il comportamento, in termini di transizioni attraverso gli stati. Lo stato attivo è
determinato basandosi sul susseguirsi di eventi sotto determinate condizioni. Pertanto le
95
_________________________________________________________________________________________________________
transizioni e gli stati nel loro complesso non sono altro che delle rappresentazioni grafiche
basate su questo tipo di approccio.
Stateflow è completamente integrato con Matlab-Simulink ed ha come caratteristica
peculiare quella di consentire la valutazione e la modifica dei risultati e del comportamento del
sistema ad ogni stadio del progetto.
Le macchine a stati finiti che questo ambiente di sviluppo permette di descrivere, sono
caratterizzate da uno stato, un ingresso ed un’uscita e si connettono fra di loro mediante delle
transizioni. In particolare:
•
Stato: è la condizione (modo) di funzionamento della macchina;
•
Transizione: è la condizione di cambiamento dello stato della macchina;
•
Ingressi: sono informazioni provenienti dall’esterno (eventi, segnali);
•
Uscite: sono segnali verso l’esterno il cui valore può essere funzione degli stati o delle
transizioni.
Di seguito è raffigurato un esempio di controllo on-off di un forno (fig. 3.1) che evidenzia le
parti caratterizzanti di una macchina a stati:
Figura 3.1: Schema di un controllo on-off
La macchina Stateflow è dunque una collezione di blocchi all’interno di un modello
Simulink. Il modello simulink e la macchina stateflow lavorano insieme in perfetta armonia.
96
_________________________________________________________________________________________________________
Infatti, eseguendo una simulazione, le porzioni di modello rappresentata in simulink e in
stateflow vengono valutate ed eseguite automaticamente.
Come noto da letteratura un modello simulink può essere costituito da una combinazione di
blocchi semplici, di blocchi di tipo toolbox o di blocchi stateflow. E’ importante precisare però
che l’insieme di transizioni, note, eventi, stati si classificano a loro volta in oggetti grafici, linee
(ossia transizioni) e blocchi (ossia stati), e in oggetti non grafici come eventi e dati. Tutti, nel
loro complesso, rappresentano il cosiddetto chart (diagramma Stateflow).
3.1 Stato
Lo stato è rappresentato da un blocco contenente al suo interno l’appartenenza gerarchica,
un’etichetta e delle azioni da effettuare a seconda del verificarsi di opportune condizioni. La
gerarchia prevede che ad ogni stato sia associato un parente. In un diagramma stateflow che
contenga un solo stato, il parente di quello stato è rappresentato dal diagramma stateflow
stesso, chiamato Stateflow Diagram Rooot.
Questa è la tipica struttura grafica di uno stato stateflow:
Figura 3.2: Struttura di uno stato stateflow
97
_________________________________________________________________________________________________________
in cui è possibile identificare il campo gerarchia (padre, figlio), e le azioni da compiere in
entrata (entry), in uscita (exit), durante la permanenza all’interno dello stato stesso (during) e
al verificarsi di un determinato evento (on).
In stateflow esistono due tipi di stato a seconda della decomposizione scelta. La
decomposizione identifica infatti lo stato in base al tipo di stati figlio che esso può contenere al
suo interno. Se tale decomposizione è esclusiva gli stati figlio potranno essere eseguiti
singolarmente seguendo la legge booleana del OR. Se invece la decomposizione risulta essere
parallela gli stati figlio potranno essere eseguiti contemporaneamente seguendo la legge
booleana dell’AND. In tal caso lo stato padre verrà rappresentato graficamente con un riquadro
tratteggiato (vedi fig. 3.3):
Figura 3.3: Esempio di stati paralleli
3.2 Transizione
Una transizione è un oggetto grafico, utilizzato per legare un blocco all’altro. La transizione
è collegata da un lato all’oggetto sorgente, dall’altro all’oggetto destinatario. La sorgente è il
punto in cui la transizione ha origine, mentre la destinazione e il punto in cui termina.
La transizione prevede l’utilizzo di un’etichetta che indica le condizioni sotto cui il sistema
si muove da uno stato all’altro. Spesso è proprio il verificarsi di alcuni eventi che causa la
98
_________________________________________________________________________________________________________
transizione verso un nuovo stato. La figura 3.4 mostra una transizione in cui Clutch_engaged
rappresenta l’evento che deve verificarsi affinché il sistema passi dallo stato neutral a quello
engagered.
Figura 3.4: Esempio di transizione
L’etichetta nello specifico può essere costituita da (fig. 3.5):
•
Evento: indica quando una transizione diventa attiva (se non specificato, la transizione
è attiva ad ogni evento);
•
Condizione: viene valutata una volta che la condizione è attivata e, se vera, la
transizione viene effettuata. Nel caso in cui non fosse specificata, la condizione
verrebbe considerata sempre vera;
•
Azione condizionata: viene eseguita se la condizione è vera;
•
Azione della transizione: viene eseguita se la transizione è effettuata.
Figura 3.5: Come scrivere una transizione
Esiste inoltre un particolare tipo di transizione detta di default che specifica quale stato
attivare quando vi è una ambiguità tra due o più stati esclusivi (OR) allo stesso livello
gerarchico (fig. 3.6).
99
_________________________________________________________________________________________________________
Figura 3.6: Transizione di default
Graficamente la transizione di default è rappresentata mediante una freccia che ha come
origine un punto e come destinazione lo stato designato.
3.3 Giunzione
La giunzione permette di realizzare la struttura semantica if..then..else, ovviamente le regole
semantiche dei punti di giunzione si sovrappongono a quelle delle transizioni dunque se in un
ramo della selezione non è specificata la condizione allora si assume di default “vera” (questo
solo nel caso che le condizioni sulle restanti transizioni siano false). Come da figura 3.7 az_A
e compiuta solo se tutta la transizione è effettuata, mentre az_cond_A è compiuta solo se
occorre.
Figura 3.7: Esempio di giunzione
La giunzione è un oggetto grafico, rappresentato schematicamente con un tondino, che
serve a semplificare la rappresentazione sotto forma di diagrammi e permette di generare
100
_________________________________________________________________________________________________________
codice efficiente. Le transizioni connesse alle giunzioni prendono il nome di segmenti di
transizione (transition segment).
Di seguito (fig. 3.8 pagina successiva) è riportato un ulteriore esempio che pone in evidenza
nello specifico come sia possibile tradurre una condizione if..else in un diagramma stateflow.
Da una attenta analisi è possibile, inoltre, verificare come una transizione da stato a stato
corrisponda esattamente con un segmento di transizione una volta completato il percorso che
passa attraverso il punto di giunzione.
Figura 3.8: Ulteriore esempio di giunzione
Una variante della giunzione è la history junction ossia una giunzione che memorizza quale
sottostato sia rimasto più attivo rispetto agli altri. Se si verifica dunque una transizione ad un
determinato stato che sia dotato di history junction il sottostato selezionato, tra quelli
disponibili, sarà proprio quello che nel tempo di funzionamento della macchina è risultato
maggiormente attivo. Semplicemente quindi l’history junction consente di conservare lo stato
della sottomacchina quando il padre ridiventa attivo.
101
_________________________________________________________________________________________________________
Figura 3.9: History junction
3.4 Eventi
Gli eventi sono alla base di uno stateflow chart, ma non sono oggetti grafici e per questo
motivo non sono direttamente rappresentati in un chart. E’ necessario definire tutti gli eventi
che interessano un diagramma stateflow. Il verificarsi di un evento permette all’ambiente di
simulazione di selezionare uno stato e di valutarne il contenuto.
Gli eventi possono essere creati e modificati a ogni livello di gerarchia, usando l’Explorer
all’interno di Staflow. Gli eventi si classificano in:
•
locali
•
input da Simulink
•
output verso Simulink
•
impliciti (l’enter, l’exit o il change all’interno di uno stato)
3.5 Dati
Gli oggetti di tipo dati, comunemente denominati Data Objects sono utilizzati per
memorizzare un valore numerico e sono anch’essi oggetti non grafici. Anche in questo caso è
possibile modificare e creare tali oggetti all’interno dell’Explorer di Stateflow. Una breve
classificazione dei data object è la seguente:
•
locali
102
_________________________________________________________________________________________________________
•
input da Simulink
•
output da Simulink
•
costanti
•
temporanei
•
booleani, double, interi
•
impliciti (assumo il valore “vero” quando lo stato a cui appartengono è attivo)
Esistono inoltre, altri tipi di variabili numeriche come ad esempio la variabile tempo che
assume per valore l’istante tempo e può essere utilizzata come un clock interno impostato
dall’utente.
4. DA UML A MATLAB: UN ESEMPIO
4.1 Introduzione
Si vedrà ora quali procedure adottare per poter realizzare un modello di simulazione MatlabSimulink partendo da una descrizione UML di un sistema di tipo ibrido. Verrà considerato
come sistema una cella di lavoro da poter utilizzare in catene di montaggio industriali. Il
sistema, costituito da due bracci robotici, da una rastrelliera, da una attrezzatura su cui eseguire
la saldatura, da un nastro trasportatore, e da un pallet svolge ciclicamente le seguenti azioni:
•
Prelievo pezzo A con robot1 da rastrelliera;
•
Deposito pezzo A su attrezzatura di saldatura;
•
Prelievo pezzo B con robot1 da rastrelliera;
•
Deposito pezzo B su attrezzatura di saldatura;
•
Esecuzione saldatura a punti (Robot1);
•
Posizionamento dell’assieme su pallet (Robot2);
•
Ripetizione saldatura per un secondo pezzo;
•
Allontanamento del pallet con due pezzi saldati dalla cella.
Analizzando tale cella sarà possibile modellare la dinamica dei robots con uno schema
Simulink tempo continuo e il funzionamento di tutti gli altri componenti come una sequenza di
operazione discrete, ottenendo un sistema complessivamente Ibrido. Nella prima fase del
103
_________________________________________________________________________________________________________
progetto verrà elaborata una descrizione del sistema in UML, seguendo le procedure già
descritte ossia la realizzazione di:
•
Class Diagram
•
State Diagram
•
Collaboration Diagram
•
Sequence Diagram
In seguito, servendosi dello State Diagram, si rappresenteranno mediante precise regole di
traduzione le componenti discrete del sistema in ambente Stateflow. Si discuterà della
realizzazione di un blocco Simulink che descriva le componenti continue e del suo
interfacciamento con il blocco stateflow. Si analizzerà inoltre, la possibilità di effettuare il
passaggio UML-Matlab sfruttando direttamente le potenzialità offerte da S-Function.
Per concludere una breve discussione sul problema dell’Override di variabili e sulle
soluzioni, che strumenti analizzati (Matlab/UML), offrono per risolverlo.
4.2 Scelta di componenti e attrezzature per l’impianto
L’impianto di saldatura robotizzato richiede l’impiego di due distinti robot con mansioni
diverse. Mentre il primo, da qui in avanti denominato robot1, ha la funzione di movimentare i
pezzi, prima e dopo che questi siano sottoposti al processo tecnologico, il secondo, indicato
come robot2, esegue la saldatura vera e propria. Conviene dunque analizzare distintamente le
caratteristiche delle due macchine in funzione di una maggiore chiarezza.
Caratteristiche dei pezzi da movimentare
I pezzi A e B risultano del tutto simili dal punto di vista delle forme, differenziandosi nel
valore di una quota: sono delle lamiere di spessore 2mm di acciaio piegate ad L, di dimensioni
riportate in figura 4.6 a pagina 110. La massa dei componenti da saldare, in base alla geometria
illustrata, è 3.65 kg. L’ingombro massimo, definito come il minimo parallelepipedo circoscritto
all’oggetto da manipolare, si ha dopo la saldatura dei componenti A e B e risulta
IA+B = 350[mm] × 350[mm] × 170[mm].
104
_________________________________________________________________________________________________________
Ipotizzando che il gripper abbia una massa di 2 kg, dato che nelle condizioni più gravose il
robot1 deve movimentare un oggetto di massa di 3.65 kg, cautelativamente il robot1 deve avere
una capacità di carico statico di almeno 10 kg.
Robot1 per la movimentazione
Il robot1 deve effettuare l’asservimento del robot2, destinato alla saldatura a punti, il che
consiste nell’eseguire le seguenti operazioni ad ogni ciclo:
1. prelevare pezzo A da rastrelliera, che funge da magazzino, e depositarlo su attrezzatura
di saldatura;
2. prelevare pezzo B da rastrelliera e depositarlo su attrezzatura di saldatura;
3. posizionare l’assieme su pallet.
Tutto ciò deve avvenire rispettando le seguenti specifiche:
•
Struttura cinematica: robot articolato (RRR).
•
Spazio di lavoro: raggio max non inferiore a 1.3 m ed ampiezza non inferiore a 150°;
•
Gradi di libertà: 5 (o 6);
•
Tipo di azionamento: elettrico;
•
Capacità di carico statica: 10 kg;
•
Velocità massima di movimentazione: 250°/s;
•
Accelerazione massima di movimentazione 100°/s2;
•
Ripetibilità di posizionamento: almeno +/- 0.3mm.
Un esempio di robot rispondente alle caratteristiche elencate è l’ABB IRB 2400/10 di cui si
riporta una breve descrizione:
•
•
Capacità di carico:
o
Payload: 10 kg.
o
Supplementary load: 10 kg on the up-per arm; 35 kg on the base unit.
Dimensioni:
o
Manipulator bases: 723x600 mm
105
_________________________________________________________________________________________________________
o
Max. reach: 1500 mm.
•
Positional repeatability: +/- 0.6mm (average result from ISO test).
•
Number of axes: 6.
•
Prestazioni cinematiche (working range):
•
o
Axis 1, Rotation 360°
o
Axis 2, Arm 200°
o
Axis 3, Arm 125°
o
Axis 4, Wrist 400° (unlimited)
o
Axis 5, Bend 240°
o
Axis 6, Rotation 800° (unlimited)
Prestazioni dinamiche:
o
Max. speed:

Axis 1, Rotation 150°/s

Axis 2, Arm 150°/s

Axis 3, Arm 150°/s

Axis 4, Wrist 360°/s

Axis 5, Bend 360°/s

•
Weight: 380 kg.
•
Mounting position: floor.
Le figure 4.1 e 4.2 mostrano rispettivamente il diagramma di carico statico e l’area di
lavoro del robot1:
Figura 4.1: Diagramma di carico statico
106
_________________________________________________________________________________________________________
Figura 4.2: Area di lavoro (misure riportate in mm)
Robot2 per la saldatura a punti
Il robot2 deve effettuare la saldatura a punti dei pezzi A e B, il che consiste nell’eseguire le
seguenti operazioni ad ogni ciclo:
1. attendere che il robot1 abbia posizionato i pezzi A e B sulla tavola girevole;
2. effettuare la saldatura a punti dei pezzi A e B.
La caratteristica più importante dell’end effector è la massa. Le pinze di saldatura in
commercio, avendo caratteristiche variabili in un ampio range, hanno masse molto differenti,
tuttavia, essendo lo spessore da saldare di solo 4 mm, si sceglierà una pinza di piccola taglia e
comunque con mpinza ≤ 100 kg. Non si considerano pesi aggiuntivi dovuti ad accessori dell’end
effector perché il generatore di tensione che alimenta la pinza è non collocato a bordo del robot,
bensì a terra, e l’unico peso aggiuntivo è quindi dovuto ai cavi elettrici. Dato che i robot per la
saldatura a punti hanno payload elevato, possiamo trascurare nella scelta il peso di tali cavi e
considerare un opportuno coefficiente di sicu-rezza sulla massa della pinza.
Le specifiche da rispettare sono:
107
_________________________________________________________________________________________________________
•
Struttura cinematica: robot articolato (RRR);
•
Spazio di lavoro: raggio max non inferiore a 1.5 m ed ampiezza non inferiore a 100°;
•
Gradi di libertà: 5 (o 6);
•
Tipo di azionamento: elettrico;
•
Capacità di carico statica: 110 kg;
•
Velocità massima di movimentazione: almeno 80°/s;
•
Ripetibilità di posizionamento: almeno +/- 0.2mm.
Un robot rispondente a tali caratteristiche è il KUKA KR125/3 di cui se ne riporta una breve
descrizione:
•
•
Capacità di carico:
o
Payload: 125 kg.
o
Supplementary load: 120 kg on the upper arm, 245 total distributed load.
Dimensioni:
o
Manipulator bases: 810x810 mm
o
Max. reach: 2410 mm.
•
Positional repeatability: +/- 0.2mm (average result from ISO test).
•
Number of axes: 6.
•
Prestazioni cinematiche (working range):
•
o
o
Axis 2, Arm 133°
o
Axis 3, Arm 268°
o
Axis 4, Wrist 700° (unlimited)
o
Axis 5, Bend 240°
o
Prestazioni dinamiche:
o
Max. speed:

Axis 2, Arm 101°/s

Axis 3, Arm 101°/s

Axis 4, Wrist 157°/s

Axis 5, Bend 170°/s
108
_________________________________________________________________________________________________________

•
Weight: 970 kg.
•
Mounting position: floor.
In figura 4.4 è riportata la vista laterale e in pianta dell’area di lavoro.
Figura 4.3: KUKA KR125/3
Figura 4.4: Area di lavoro (misure riportate in mm)
109
_________________________________________________________________________________________________________
End Effector dei due robot
L’end effector montato sul robot1 deve permettere la corretta esecuzione delle operazioni di
prelievo e movimentazione dei pezzi A e B dalla rastrelliera sulla quale sono inizialmente
immagazzinati, nonché il deposito sulla tavola di saldatura e, al termine dell’esecuzione del
processo tecnologico ad opera del robot2, lo scarico dell’assieme e il suo posizionamento su di
un pallet. Il suo compito è quindi quello di asservire il robot di saldatura effettuando carico e
scarico dei componenti, si sceglie a tale scopo di adoperare un gripper a quattro ventose.
Per la scelta delle superfici di afferraggio dei pezzi A e B, si analizzerà uno soltanto di essi
in quanto simili. La superficie 1’ si configura tuttavia come la più idonea all’afferraggio (figura
4.5) per un duplice motivo:
1. su di essa non vengono eseguite operazioni tecnologiche, è perciò valida sia prima che
dopo la saldatura: ciò semplifica la programmazione del robot;
2. è parallela al piano di appoggio: in fase di rilascio dei pezzi questo è molto importante,
poiché le eventuali forze dovute al rilascio non tendono a ribaltare il pezzo in un
gripper a depressione.
Tutte le altre superfici non sono adatte o perché superfici di appoggio (sup. 1” e 2”), o
perchè di ampiezza limitata (sup. 3’ e 3”; sup. 4’ e 4”). Il posizionamento sulla tavola di
saldatura risulta piuttosto delicato a causa della necessità di porre in contatto e affacciate le
superfici 2” dei pezzi A e B: oltre ad un’ accurata programmazione, in questa fase, devono
dunque essere predisposti dei riferimenti per evitare che al contatto dei pezzi ci possa essere
spostamento di uno dei due con la successiva impossibilità di eseguire correttamente la
saldatura.
L’end effector montato sul polso del robot2 è una pinza di saldatura che deve eseguire 5
punti di saldatura su ciascun gruppo di pezzi A+B posizionati sulla tavola girevole dal robot1.
La saldatura avviene sulle superfici 2’ dei pezzi affacciati (figura 4.5), su una lamiera di
spessore complessivo 2+2 mm. I punti di saldatura sono disposti con regolarità secondo una
forma a C geometrico, con il lato lungo parallelo al piano di appoggio dell’assieme: sono in
numero di tre sul lato lungo, uno posto sulla mezzeria della lamiera ad una distanza di 25 mm
dall’estremità superiore, e gli altri due disposti simmetricamente a 150 mm da questo; mentre
gli ultimi due punti, uno rispettivamente per parte, sono posti a formare la C ad una distanza di
75 mm sulla verticale degli estremi del lato lungo.
110
_________________________________________________________________________________________________________
Durante il processo tecnologico di saldatura il robot2 deve posizionare la pinza,
eventualmente ruotando il polso qualora le dimensioni degli elettrodi non fossero sufficienti a
mantenere un unico orientamento spaziale, sui punti indicati realizzando la locale fusione del
materiale e garantendo quindi la continuità fisica dell’assieme.
Figura 4.5: Superfici di riferimento dei pezzi A e B
Trasportatore
In base ai dati del problema, il trasportatore ha la funzione di allontanare dalla cella di
lavoro i pallets su cui sono posizionati le coppie di pezzi saldati.
La definizione della geometria di ciascun pezzo saldato può essere fatta considerando l’unione
di un pezzo A e di un pezzo B, lungo le superfici verticali 2”, attraverso la saldatura a punti
sulle superfici 2’ (si rimanda alla figura 4.5). L’assieme assume quindi una forma a T
rovesciato e presenta le seguenti dimensioni:
•
lunghezza = 350 mm;
•
larghezza = 350 mm;
•
altezza = 170 mm;
•
spessore lamina saldata verticale = 4 mm;
•
spessore lamine orizzontali = 2 mm.
111
_________________________________________________________________________________________________________
Figura 4.6: Disegno schematico di un pezzo saldato
I pezzi saldati vengono prelevati dalla tavola girevole dal robot1 per mezzo del gripper a
depressione e posizionati sulla superficie superiore del pallet. Dal momento che il baricentro di
ogni pezzo saldato risulta prossimo al tratto verticale delle lamiere e spostato verso il pezzo A,
il gripper afferra ciascun pezzo saldato sulla superficie 1’ del pezzo A e lo posiziona sul pallet
appoggiandolo sulla superficie inferiore 1’’ di dimensioni 350x350mm, con il tratto verticale
delle lamiere disposto perpendicolarmente rispetto la direzione di avanzamento del
trasportatore.
Figura 4.7: Schema di disposizione di un pezzo saldato sul pallet
Il pallet deve essere realizzato in modo che entrambi i pezzi saldati trovino un opportuno
riferimento una volta appoggiati sopra di esso. Si pensa di realizzare ciò avvitando sopra il
112
_________________________________________________________________________________________________________
pallet una sottile lamiera di 3 mm con due fori quadrati di dimensioni 352x352 con uno smusso
1x45° sui bordi superiori per favorire l’ingresso del pezzo finale. Il trasportatore, considerando
che deve garantire l’entrata e l’uscita del pallet dalla cella di lavoro, deve avere le seguenti
dimensioni:
•
larghezza = 600 mm;
•
lunghezza = 9000 mm.
Si considera per comodità che il tratto di trasportatore, presente nella cella sia lineare. A tale
scopo si sceglie di utilizzare il modello GR/TR1 della F.lli Arnaboldi che sembra soddisfare
tutte le specifiche. Si riportano si seguito le caratteristiche principali:
•
Alimentazione 220/380V, 50Hz Trifase;
•
Struttura in profilato d'alluminio da ;
•
Trasporto con catena speciale da 3/8" tripla con rullo folle ad un passo di 19.5mm;
•
Centraggio pallet +/- 0.2mm;
•
Scorrimento catena su guide in Polizene;
•
Motoriduttore e tenditore posti alle 2 estremità del modulo;
•
Velocità di avanzamento di circa 12m/min;
•
Potenza installata 0.37kW;
•
Cavalletti di supporto in elettrosaldato ad int. di circa 2000mm.
Figura 4.8: GR/TR1
Considerando che il trasportatore sia facente parte di un sistema di movimentazione più
ampio, sul pallet si dovrà prevedere un chip magnetico per lo stato del complessivo e lungo la
linea del nastro trasportatore dovranno essere posizionati un codice-lettore e un codice-
113
_________________________________________________________________________________________________________
scrittore. Trascurando i dettagli geometrici meno importanti, si considera un pallet con forma e
dimensioni analoghe a quelle di figura 4.9, ove i 4 fori svasati costituiscono l’innesto per il
sistema di centraggio e di sollevamento del pallet quando questo si ferma di fronte al robot1.
Tale gruppo, se impiegato, consente di non fermare il trasportatore quando il pallet è fermo
davanti alla stazione di lavoro, senza tuttavia che la catena strusci sulla superficie inferiore del
pallet, con problemi di usura e di posizionamento instabile.
Figura 4.9: Disegno quotato di massima del pallet adottato
Tavola girevole
La tavola per la saldatura deve essere in grado di permettere un preciso riferimento dei pezzi
A e B e il bloccaggio di essi durante la saldatura per evitare eventuali spostamenti con i
conseguenti errori che renderebbero il pezzo da scartare. Per la definizione delle specifiche si
deve prevedere anche che la tavola sia in grado di permettere una rotazione di 90° (della
superficie su cui vengono posti gli oggetti da saldare) dopo che sia stato posizionato il pezzo A
e di 180° dopo che sia stato posizionato il pezzo B. Per non lavorare le superfici della tavola
girevole, si dovrà prevedere montato sopra di essa un supporto. Per tale tavola si deve cercare
inoltre di contenere gli ingombri, compatibilmente con la possibilità di poter essere di
riferimento al supporto che andrà fissato sopra di esso. Il supporto dovrà presentare un incasso
quadrato di dimensioni 352x352mm e profondo 3 mm con smusso 1x45° per consentire che i
pezzi possano essere appoggiati sulla loro superficie inferiore 1”.
In base alle specifiche discusse il modello RP2E-150N dell’ANDITAUTOMAZIONE sembra
essere quello più adatto (figura 4.10). Se ne riportano le caratteristiche principali:
114
_________________________________________________________________________________________________________
•
La tavola può essere ruotata su entrambi i lati di +/- 1350° ;
•
Massimo carico movimentabile: 150 kg;
•
Velocità di rotazione massima: 21 rad/min;
•
Velocità di inclinazione: 12 rad/min;
•
Momento torcente di rotazione: 147Nm ;
•
Momento torcente di inclinazione: 426Nm ;
•
Ripetibilità di posizionamento: +/- 0.2mm ;
•
Posizione di arresto: arbitraria.
Figura 4.10: RP2E-150N
Tale tavola è inoltre corredata di un supporto analogo a quello riportato in figura 4.11
realizzato in acciaio e dal peso di 30Kg.
Figura 4.11: Disegno 3D del supporto
Vanno tuttavia utilizzati opportuni sistemi per il riferimento dei pezzi: si utilizzano a tal
scopo 4 spine cilindriche di raggio 10 mm, di cui tre servono per il centraggio del pezzo A
(definendo due superfici) mentre il quarto per il pazzo B (che troverà come riferimento anche la
superficie 2’’ del pezzo A. Dopo che è stato posizionato il pezzo A due martinetti pneumatici si
abbassano fino a giungere in contatto con la superficie 1’; per il pezzo B si prevede invece che i
martinetti pneumati-ci ruotino attorno a un asse sulla superficie della tavola fino al contatto. Si
115
_________________________________________________________________________________________________________
vedano a tal scopo la Figura 4.12, in cui si mostrano le attrezzature di bloccaggio e quelle di
riferimento.
Figura 4.12: Tavola con elementi di riferimento e bloccaggio pezzo
Rastrelliera
I pezzi A e B sono inizialmente immagazzinati in una rastrelliera, che deve:
•
garantire un corretto e stabile posizionamento degli oggetti per permettere il prelievo
da parte del robot 1;
•
minimizzare gli ingombri;
•
avere una struttura tale da garantire l’alloggiamento di un numero elevato di pezzi
(almeno 10).
Vista la geometria dei pezzi A e B (l’assieme sarà invece depositato su un pallet), e il loro
spessore limitato, conviene impiegare una rastrelliera-magazzino a sviluppo verticale (in questo
modo si limitano notevolmente gli ingombri), in grado di contenere due pile separate di pezzi
posti uno sopra l’altro, una pila per ciascun tipo di oggetto.
Il problema del corretto posizionamento può essere risolto sfruttando la forma ad L dei
pezzi: inclinando le pile in modo che la superficie 1’ formi un angolo di almeno 15° rispetto al
pavimento, si riesce a garantire che gli oggetti non si spostino dalla posizione di presa a causa
di fenomeni di perturbazione (vibrazioni dovute, per es., ad una pressa, o altro).
116
_________________________________________________________________________________________________________
La forza di gravità è infatti sfruttata come fattore attivo per evitare movimenti non voluti.
Tre paratie, di cui due laterali alle pile e una centrale come elemento divisorio, impediscono poi
la traslazione laterale delle lamiere e assicurano errori di afferraggio limitati e recuperabili con i
riferimenti sulla tavola di saldatura (prevedendo infatti un gioco max lamiere-paratie
dell’ordine di 1 mm, i limiti di precisione del gripper a depressione vengono ampiamente
compensati). Il modello solido della rastrelliera scelta è riportato in figura 4.13.
Figura 4.13: Rastrelliera
Definizione del Layout
Si intende ora analizzare la disposizione dei componenti nella cella di lavoro. Innanzi tutto
bisogna considerare che il robot1 deve poter essere in grado di movimentare i pezzi A e B dalla
rastrelliera alla tavola girevole e, al termine dell’operazione di saldatura, il pezzo saldato sul
pallet. Per tale motivo, essendo il robot1 di tipo articolato e quindi dotato di moto rotoidale
attorno all’asse del joint 1, bisognerà disporre i componenti che esso dovrà raggiungere su di
una circonferenza concentrica all’asse rotoidale del robot di raggio opportuno: ciò è dovuto al
fatto che bisogna garantire la raggiungibilità dei punti da parte del gripper 1 durante il ciclo di
lavoro.
La soluzione adottata prevede che il robot2 sia posto rispetto alla tavola girevole dalla parte
opposta al robot1 (vedi fig. 4.14). Nella figura si indicano schematicamente con Ras la
rastrelliera, con R1 e R2 rispettivamente il robot1 e il robot2, con TG la tavola girevole, con P
il pallet e con Tr il trasportatore.
117
_________________________________________________________________________________________________________
Figura 4.14: Layout
Si è deciso di utilizzare questa soluzione, poiché in questo modo:
•
si evita la possibilità di collisioni tra il robot2 e la rastrelliera, che in un impiego
industriale, potrebbe svilupparsi anche ad altezze superiori a quelle del piano di lavoro;
•
si ha una riduzione del workspace necessario: anche se si ha un maggiore sviluppo
nella direzione di avanzamento del trasportatore, si ha un notevole guadagno nella
direzione ad esso perpendicolare, con una quantità minore di spazio inutilizzata;
•
si hanno rischi molto inferiori di un urto tra i due robot.
Si prevede inoltre di posizionare la porta di accesso alla cella prossima alla rastrelliera, al fine
di favorire il posizionamento dei pezzi sopra di essi, e l’unità di governo sempre lungo lo stesso
lato della cella. Si riporta nella figura 4.15 il disegno quotato del layout scelto per la cella di
saldatura.
118
_________________________________________________________________________________________________________
Figura 4.15: Disegno quotato del layout (misure in mm)
4.3 Il Class Diagram
Una volta scelti i componenti del sistema si procede con la realizzazione del Class Diagram
che servirà a specificare quali oggetti costituiscono il sistema, e a grandi linee, le relazioni
statiche che ci sono tra questi tipi di oggetti, ossia le operazioni che compiono.
Il diagramma contiene pertanto una classe generica Robot e due istanze di tale classe:
Saldatore e Movimentatore. Associate ad esse vi è una classe Pezzo, che è a sua volta associata,
con molteplicità 2, alla classe Assemblato (composizione dei pezzi A e B). La comunicazione
tra i vari elementi della cella è garantita da 3 segnali presenza_pezzo, finecorsa_nastro e
presenza assemblato, inviati ai due Robot dalle classi Rastrelliera, TavolaGirevole e
NastroTrasportatore. La Dinamica è trattata come una classe a se in cui andranno specificate
attraverso delle Note o delle Constraint le equazioni differenziali che regolano il
funzionamento del braccio Saldatore e del braccio Movimentatore. Nell’esempio preso in
119
_________________________________________________________________________________________________________
esame si è invece scelto di lasciare la dinamica come una classe vuota, realizzando in Simulink
una approssimazione dei Robots. Questo perché lo scopo principale dell’esempio è
semplicemente quello di mostrare le procedure da adottare per rappresentare in Matlab un
sistema ibrido generico descritto inizialmente con UML.
Con tale Diagramma si è cercato di porre in risalto le interazioni statiche che avvengono tra
i vari oggetti del sistema e il tipo di operazioni che essi possono compiere. Lo schema completo
è riportato in figura 4.16:
Figura 4.16: Class Diagram – cella di lavoro
120
_________________________________________________________________________________________________________
4.4 State Diagram
Nella realizzazione dello State Diagram si è tenuto conto che il sistema è costituito da due
elementi fondamentali che risultano essere i due Robots. Il funzionamento della cella di lavoro
nel suo complesso si basa infatti sulle azioni che i due Robots devono compiere per poter
effettuare la movimentazione dei pezzi e la saldatura. Le altre componenti ossia la Tavola
Girevole, la Rastrelliera e il Nastro Trasportatore sono visti come degli elementi passivi di cui i
Robots si servono per poter ricavare delle informazioni o per poter impartire dei comandi.
Si è scelto dunque di realizzare due State Diagram:
•
uno per il robot Movimentatore;
•
uno per il robot Saldatore.
Lo State Diagram del Movimentatore, il cui schema è riportato in figura 4.17, ha come punto di
partenza uno stato in cui il Robot si trova in una posizione di sicurezza. Una volta ricevuto il
segnale di presenza pezzi, dal sensore posto sulla rastrelliera, il robot effettua una rotazione di
90° per afferrare il pezzo A e successivamente una movimentazione del pezzo fino a
depositarlo sulla Tavola Girevole (rotazione di altri 90°). A questo punto dopo aver comandato
la rotazione della Tavola effettua lui stesso una ulteriore rotazione di 180° per poter tornare
indietro e afferrare il secondo pezzo da movimentare dalla rastrelliera. Terminata questa prima
fase il robot ritorna in posizione di sicurezza finchè non sia stata effettuata la saldatura che in
questo schema è vista come uno stato di attesa.
La seconda fase prevede la riesecuzione di tutte le operazioni fino al deposito sulla Tavola
Girevole di ulteriori due pezzi. A questo punto, prima di ritornare nuovamente in posizione di
sicurezza il Robot comanda l’allontanamento, del pallet sul quale risiedono i due assemblati,
inviando un segnale di accensione al Nastro Trasportatore. Questa sequenza di stati è
rappresentata in figura in modo rigoroso, per tale motivo si è reso necessario anche l’utilizzo di
variabili di appoggio per effettuare la comunicazione tra le varie componenti del sistema. Tali
variabili così come sarà più chiaro in seguito (vedi Appendice A: Descrizione dello Statechart)
sono essenzialmente di tre tipi:
•
di ingresso (esterne al diagramma)
•
di uscita (esterne al diagramma)
121
_________________________________________________________________________________________________________
•
locali (interne)
Figura 4.17: State Diagram Movimentatore – cella di lavoro
La stessa tecnica di realizzazione è stata adottata anche per lo State Diagram del Robot
Saldatore (fig. 4.18). E’ stato previsto come punto di partenza una posizione di sicurezza dalla
quale il robot esce per poter effettuare i 5 punti di saldatura sull’assemblato. Tale saldatura
avviene dunque in 5 momenti differenti e lo spostamento del robot segue quello di una “U”
capovolta. Terminata la saldatura è stato previsto uno stato per l’azzeramento della pinza
saldatrice e il ritorno in posizione di sicurezza prima dell’invio al Movimentatore del segnale di
fine saldatura.
122
_________________________________________________________________________________________________________
Figura 4.18: State Diagram Saldatore – cella di lavoro
123
_________________________________________________________________________________________________________
4.5 Collaboration Diagram
Il Collaboration Diagram visualizza lo scambio dei messaggi e segnali che avviene tra i vari
componenti del sistema. Mentre con il Class Diagram si ha una visione statica della cella di
lavoro, con questo grafico si ha la dinamica globale come visibile in figura:
Figura 4.19: Collaboration Diagram – cella di lavoro
4.6 Sequence Diagram
Il Sequence Diagram che, appunto, permette di modellare la comunicazione tra un oggetto
ed un altro in relazione al trascorrere del tempo. Si capisce subito che in questo tipo di
rappresentazione un ruolo cruciale viene svolto dal tempo.
L'idea chiave qui è che le interazioni tra gli oggetti avvengano seguendo un ordine ben
preciso e che tale sequenza avvenga, nel tempo, dall'inizio alla fine. La realizzazione risulta
abbastanza semplice, basta considerare la sequenza temporali delle interazioni che avvengono
durante il funzionamento del sistema e rappresentarle secondo la sintassi analizzata nel
paragrafo 1.11. In figura 4.20 è riportato lo schema finale.
124
_________________________________________________________________________________________________________
Figura 4.20: Sequence Diagram – cella di lavoro
4.7 Stateflow: Statechart
Una volta terminata la realizzazione dei diagrammi UML si passa alla traduzione del
sistema in un modello di simulazione all’interno di Matlab. Pertanto si procede con la
descrizione della componente continua attraverso dei blocchetti Simulink (fig. 4.21). La
dinamica del robot Movimentatore e del robot Saldatore è stata approssimata attraverso il
modello completo di un motore. La saldatura è stata pensata come l’unione di movimenti
lineari della pinza saldatrice in aggiunta a dei ritardi, che simulano il tempo necessario ad
effettuare i 5 punti di saldatura. Sono presenti anche dei ritardi che indicano il tempo necessario
125
_________________________________________________________________________________________________________
ai segnali di risposta dei sensori presenti nel sistema (sensore di posizione, di rilevamento
pezzo).
La componente discreta è stata realizzata, invece, utilizzando lo Stateflow. I risultati delle
operazioni compiute dal sistema sono stati rappresentati graficamente attraverso l’utilizzo di tre
blocchetti Scope, come visibile in figura:
Figura 4.21: Modello Simulink – cella di lavoro
La descrizione dettagliata della macchina a stati e i risultati della simulazione sono riportati
in Appendice.
4.8 Riepilogo delle regole di traduzione
Si riportano per completezza i passaggi che devono essere effettuati per poter trasformare la
descrizione UML di un sistema in un modello Matlab:
126
_________________________________________________________________________________________________________
1. Analisi dei componenti e delle specifiche di progetto
2. Descrizione dettagliata della dinamica del sistema
3. Realizzazione di opportuni controllori che consentano il rispetto delle specifiche
4. Scrittura del Class Diagram UML
5. Scrittura dello State Diagram
6. Scrittura del Collaboration Diagram e del Sequence Diagram
7. Realizzazione del modello Matlab (componenti continue con Simulink e discrete
con Stateflow)
8. Eventuale generazione di codice per la configurazione e la programmazione dei
componenti del sistema.
L’unicità di questa procedura è garantita anche grazie ai numerosi strumenti offerti da UML per
realizzare la descrizione di un sistema. Tra questi assume rilevante importanza il costrutto
constraint che permette di specificare ad esempio se bisogna svolgere delle operazioni prima di
altre o se bisogna adottare determinanti componenti anziché altri. La sua funzione è quella
dunque di fornire dei vincoli che garantiscano appunto le specifiche determinanti del sistema
stesso e evitare l’overflow delle variabili.
4.9 Sviluppi Futuri
UML, che di fatto oggi è uno standard, si pone grazie alla semplicità e alla facilità d’uso al
vertice tra gli strumenti che consentano di strutturare in differenti fasi un qualsiasi tipo di
progettazione. Pertanto si rivela estremamente utile nella produzione di software, o in altri
campi dell’ingegneria, tra questi anche quello dell’automazione industriale. Come visto nei
paragrafi precedenti, ambienti di simulazione quali Matlab offrono a programmatori esperti la
possibilità di descrivere mediante linguaggi proprietari (linguaggio Matlab) e non (es. C/C++,
Java), sistemi continui, discreti o ibridi sui quali effettuare le simulazioni necessarie nelle fasi
di progetto antecedenti la realizzazione vera e propria. Appare chiaro, quindi, che un ingegnere
o un team prima di poter creare e sviluppare dovranno avere a disposizione gli strumenti adatti
per poter comunicare tra di loro. Si è detto che questa comunicazione di fatto avviene spesso
sulla base dell’esperienza di coloro che sopraintendono il progetto, e che hanno quindi già
affrontato in passato problematiche dello stesso tipo. Se si utilizzasse UML come tramite, ossia
come punto di unione tra chi ha il compito di descrivere e progettare e chi ha invece il compito
di realizzare si potrebbero eliminare inutili e spiacevoli incomprensioni che spesso sono alla
127
_________________________________________________________________________________________________________
base del fallimento di un processo produttivo e di sviluppo. Nell’esempio si è visto come sia
possibile, attraverso l’uso di semplici regole, passare dalla descrizione di un sistema fatta
utilizzando UML ad un modello Matlab pronto per la simulazione. Uno sviluppo futuro
potrebbe essere quello di racchiudere le regole di traduzione da UML a Matlab in un software
che permetta di generare in modo univoco codice in formato S-Function inserendo i parametri
della dinamica e fornendo i file dei diagrammi UML del sistema. Questo permetterebbe in
prima istanza di descrivere un sistema attraverso un linguaggio universale che non risulti legato
a nessun tipo di programma (Matlab, Scilab e così via) ma che attraverso regole simili a quelle
utilizzate dalle S-function, permetta di sfruttare quella descrizione su qualsiasi piattaforma di
simulazione e con qualsiasi sistema operativo (Linux, Windows). Consentirebbe inoltre di
rendere leggibile tale descrizione a chiunque conosca questo linguaggio pur non essendo
necessariamente esperto di Informatica o di Matematica, basti pensare, ad esempio, a coloro
che hanno il compito di assemblare i componenti di una catena produttiva o di realizzare
semplicemente un rete di comunicazione tra di essi.
128
_________________________________________________________________________________________________________
Indice delle tabelle e delle figure
Figura 1.1: La vignetta dell’altalena
Figura 1.2: Evoluzione dell'uml
Figura 1.3: Meta-metamodello, metamodello e modello UML
Figura 1.4: Esempio delle relazioni ai vari gradi di astrazione tra i modelli UML
Figura 1.5: Frammento della sintassi astratta di UML
Tabella 1.1: Classificazione dei diagrammi UML
Figura 1.6: La classe
Figura 1.7: Attributi
Figura 1.8: Vista completa di una classe
Figura 1.9: Associazione
Figura 1.10: Classe associazione
Figura 1.11: Associazione riflessiva
Figura 1.12: Ereditarietà
Figura 1.13: Aggregazione
Figura 1.14: Associazione composita
Figura 1.15: Interfaccia
Figura 1.16: Esempio di classe
Figura 1.17: La classe pagina
Figura 1.18: Esempio di ereditarietà
Figura 1.19: La classe carattere
Figura 1.20: La classe tabella
Figura 1.21: Esempio di Class Diagram
Figura 1.22: Use case
Figura 1.23: Esempio di use case
Figura 1.24: Lo use case “ricarica la macchina”
Figura 1.25: Lo use case ritira le monete
Figura 1.26: Use case completo
Figura 1.27: Ricarica la macchina – una variante
Figura 1.28: Esempio di generalizzazione di un actor
Figura 1.29: Diagramma finale
Figura 1.30: State diagram
Figura 1.31: Esempio di state diagram
Figura 1.32: State diagram dettagliato
Figura 1.33: Descrizione della transizione
Figura 1.34: Sequence diagram
Tabella 1.2 : Messaggi per i sequence diagrams
Figura 1.35: Il tempo
Figura 1.36: La ricorsione nel sequence diagram
Figura 1.37: Esempio di sequence diagram
Figura 1.38: Vista di un collaboration diagram
Figura 1.39: Esempio di collaboration diagram
Figura 1.40: Collaboration diagram completo
Figura 1.41: Rami prodotti dal processo annidato
Figura 1.42: Activity diagram
p.5
p.8
p.10
p.11
p.13
p.16
p.19
p.20
p.20
p.21
p.22
p.22
p.23
p.25
p.25
p.26
p.28
p.29
p.29
p.30
p.31
p.31
p.33
p.35
p.37
p.37
p.38
p.38
p.39
p.39
p.40
p.42
p.43
p.43
p.44
p.45
p.46
p.47
p.48
p.50
p.51
p.52
p.53
p.54
129
_________________________________________________________________________________________________________
Figura 1.43: Grafico decisonale
Figura 1.44: Merge di attività
Figura 1.45: Component diagram
Figura 1.46: Rappresentare un’interfaccia – primo modo
Figura 1.47: Rappresentare un’interfaccia – secondo modo
Figura 1.48: Music player
Figura 1.49: Esempio di componet diagram
Figura 1.50: rappresentazione di un nodo nel deployment diagram
Figura 1.51: Esempio di deployment diagram
Figura 1.52: T-connector
Figura 1.53: Rete di calcolatori
Figura 1.54: Deployment diagram finale
Figura 1.55: Elementi strutturali
Figura 1.56: Elementi comportamentali
Figura 1.57: Relazioni
Figura 1.58: Raggruppamento
Figura 1.59: Annotazioni e actor
Figura 2.1: Schema a blocchi di una s-funtion
Figura 2.2: Come Simulink esegue la simulazione
Tabella 2.1: Stadi di simulazione
Figura 2.3: Schema simulink
Figura 2.4: Schema di funzionamento
Figura 2.5: Sequenza di esecuzione per Real Time Workshop
Figura 2.6: Sequenza di esecuzione in modalità esterna
Figura 2.7: Schema ingresso
Figura 2.8: Modalità di ingresso
Figura 3.1: Schema di un controllo on-off
Figura 3.2: Struttura di uno stato stateflow
Figura 3.3: Esempio di stati paralleli
Figura 3.4: Esempio di transizione
Figura 3.5: Come scrivere una transizione
Figura 3.6: Transizione di default
Figura 3.7: Esempio di giunzione
Figura 3.8: Ulteriore esempio di giunzione
Figura 3.9: History junction
Figura 4.1: Diagramma di carico statico
Figura 4.2: Area di lavoro
Figura 4.3: KUKA KR125/3
Figura 4.4: Area di lavoro
Figura 4.5: Superfici di riferimento dei pezzi A e B
Figura 4.6: Disegno schematico di un pezzo saldato
Figura 4.7: Schema di disposizione di un pezzo saldato sul pallet
Figura 4.8: GR/TR1
Figura 4.9: Disegno quotato di massima del pallet adottato
Figura 4.10: RP2E-150N
Figura 4.11: Disegno 3D del supporto
Figura 4.12: Tavola con elementi di riferimento e bloccaggio pezzo
Figura 4.13: Rastrelliera
Figura 4.14: Layout
Figura 4.15: Disegno quotato del layout
p.55
p.56
p.58
p.59
p.59
p.59
p.60
p.61
p.62
p.63
p.64
p.64
p.65
p.65
p.65
p.65
p.66
p.68
p.69
p.70
p.74
p.74
p.81
p.81
p.83
p.83
p.94
p.95
p.96
p.96
p.97
p.97
p.98
p.99
p.99
p.104
p.105
p.107
p.107
p.109
p.110
p.110
p.111
p.112
p.113
p.113
p.114
p.115
p.117
p.118
130
_________________________________________________________________________________________________________
Figura 4.16: Class Diagram – cella di lavoro
Figura 4.17: State Diagram Movimentatore – cella lavoro
Figura 4.18: State Diagram Saldatore – cella lavoro
Figura 4.19: Collabotation Diagram – cella lavoro
Figura 4.20: Sequence Diagram – cella lavoro
Figura 4.21: Modello Simulink – cella lavoro
p.119
p.121
p.122
p.123
p.124
p.125
131
_________________________________________________________________________________________________________
Bibliografia
Booch G., Rumbaugh J., Jacobson J., “Unified Modeling Language User Guide”. AddisonWesley, 1999.
Booch G., Rumbaugh J., Jacobson J., “Unified Modeling Language Reference Manual”.
Addison-Wesley, 1999.
Comai A., tutorial “Introduzione a UML”. http://www.analisidisegno.com/uml/uml.htm#UML
M. Fowler. “UML Distilled”. Addison-Wesley, 1998.
Vetti Tagliati Luca, “UML e ingegneria del software” nel sito http://www.mokabyte.it/
Vetti Tagliati Luca, “UML e ingegneria del software: dalla teoria alla pratica”. Hops, 2003.
Bennett S., Skelton J., Lunn K., “Introduzione a UML”, Mc Graw Hill, 2001.
Mathworks “Simulink: Simulation and Model Based Design” Guida a Matlab 6.
Barbarisi O., “Ovierview of S-Functions”, Tavole Power Point, 2001.
132