Laurea Specialistica in Ingegneria dell’Automazione · 1.2 Perché utilizzare UML Ogni qualvolta,...

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 _________________________________________________________________________________________________________

2

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


3

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


4

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


5

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


6

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


7

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.


8

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.


9

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.


10

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.


11

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.


12

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.


13

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


14

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.


15

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).


16

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.

Concorrenza: CallConcurrencyKind Radice: boolean Foglia: boolean

Astratto: boolean Specifica: String

Operazione

Query: boolean

ProprietàComportamentale

Metodo Corpo: ProcedureExpression

1 *+specifica


17

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.


18

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.


19

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


20

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.


21

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


22

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.


23

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.


24

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.


25

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


26

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.


27

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:


28

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.


29

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


30

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.


31

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


32

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à


33

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.


34

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.


35

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:


36

• 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;


37

• 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


38

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):


39

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.


40

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:


41

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


42

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.


43

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


44

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.


45

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:


46

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).


47

È 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:


48

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.

synchronous

Se un oggetto invia un messaggio sincrono,

allora si attende che gli venga restituita una

risposta al messaggio stesso prima di poter

continuare con altre operazioni.

asynchronous

Diversamente dai messaggi sincroni, se un

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


49

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.


50

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 Self-

Service. 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;


51

• 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


52

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


53

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 (message-

signature).

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.


54

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


55

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 ?


56

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à.


57

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.


58

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).


59

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


60

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).


61

È 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;


62

• 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 CD-

ROM. 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


63

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.


64

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.


65

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


66

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 T-

connectors. 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).


67

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


68

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


69

Estensioni

<<Stereotipo>>

{Constraint}

Annotazioni ed Actor

Figura 1.59: Annotazioni e actor


70

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;


71

• 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):


72

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);


73

• 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 S-

Function 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 Routine S-Function Inizializzazione mdlInitializeSizes Calcolo istante camp. succ. (facoltativo) mdlGetTimeOfNextVarHit Calcolo uscite mdlOutputs Aggiornamento stadi discreti mdlUpdate Calcolo derivate mdlDerivatives Fine simulazione mdlTerminate

Tabella 2.1: Stadi di simulazione

Una piena comprensione dei seguenti concetti aiuterà ad una corretta scrittura delle S-

Function:

• Direct feedthrough;

• Ampiezza ingresso impostata dinamicamente;


74

• 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:


75

• 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 S-

Function 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


76

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,


77

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


78

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);


79

}

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 /* Is this file being compiled as a MEX-file? */

#include "simulink.c" /* 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;


80

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


81

#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


82

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:


83

• 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):


84

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


85

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:


86

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


87

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


88

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) ssGetSFcnParams(S,1)

#define PROG_GAIN(S) ssGetSFcnParams(S,2)

#define NUM_OF_CHANNELS_PRM(S) ssGetSFcnParams(S,3)

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.


89

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.


90

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:


91

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;


92

• 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.


93

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.).


94

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:


95

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


96

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.


97

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


98

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


99

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).


100

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


101

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.


102

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


103

• 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 Matlab-

Simulink 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


104

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].


105

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


106

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


107

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:


108

• 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 Axis 2, Arm 133°

o Axis 3, Arm 268°

o Axis 4, Wrist 700° (unlimited)

o Axis 5, Bend 240°


• 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


109


• 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)


110

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.


111

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.


112

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


113

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-


114

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:


115

• 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


116

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).


117

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.


118

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.


119

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


120

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


121

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)


122

• 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.


123

Figura 4.18: State Diagram Saldatore – cella di lavoro


124

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.


125

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


126

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:


127

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


128

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.


129

Indice delle tabelle e delle figure

Figura 1.1: La vignetta dell’altalena p.5 Figura 1.2: Evoluzione dell'uml p.8 Figura 1.3: Meta-metamodello, metamodello e modello UML p.10 Figura 1.4: Esempio delle relazioni ai vari gradi di astrazione tra i modelli UML p.11 Figura 1.5: Frammento della sintassi astratta di UML p.13 Tabella 1.1: Classificazione dei diagrammi UML p.16 Figura 1.6: La classe p.19 Figura 1.7: Attributi p.20 Figura 1.8: Vista completa di una classe p.20 Figura 1.9: Associazione p.21 Figura 1.10: Classe associazione p.22 Figura 1.11: Associazione riflessiva p.22 Figura 1.12: Ereditarietà p.23 Figura 1.13: Aggregazione p.25 Figura 1.14: Associazione composita p.25 Figura 1.15: Interfaccia p.26 Figura 1.16: Esempio di classe p.28 Figura 1.17: La classe pagina p.29 Figura 1.18: Esempio di ereditarietà p.29 Figura 1.19: La classe carattere p.30 Figura 1.20: La classe tabella p.31 Figura 1.21: Esempio di Class Diagram p.31 Figura 1.22: Use case p.33 Figura 1.23: Esempio di use case p.35 Figura 1.24: Lo use case “ricarica la macchina” p.37 Figura 1.25: Lo use case ritira le monete p.37 Figura 1.26: Use case completo p.38 Figura 1.27: Ricarica la macchina – una variante p.38 Figura 1.28: Esempio di generalizzazione di un actor p.39 Figura 1.29: Diagramma finale p.39 Figura 1.30: State diagram p.40 Figura 1.31: Esempio di state diagram p.42 Figura 1.32: State diagram dettagliato p.43 Figura 1.33: Descrizione della transizione p.43 Figura 1.34: Sequence diagram p.44 Tabella 1.2 : Messaggi per i sequence diagrams p.45 Figura 1.35: Il tempo p.46 Figura 1.36: La ricorsione nel sequence diagram p.47 Figura 1.37: Esempio di sequence diagram p.48 Figura 1.38: Vista di un collaboration diagram p.50 Figura 1.39: Esempio di collaboration diagram p.51 Figura 1.40: Collaboration diagram completo p.52 Figura 1.41: Rami prodotti dal processo annidato p.53 Figura 1.42: Activity diagram p.54


130

Figura 1.43: Grafico decisonale p.55 Figura 1.44: Merge di attività p.56 Figura 1.45: Component diagram p.58 Figura 1.46: Rappresentare un’interfaccia – primo modo p.59 Figura 1.47: Rappresentare un’interfaccia – secondo modo p.59 Figura 1.48: Music player p.59 Figura 1.49: Esempio di componet diagram p.60 Figura 1.50: rappresentazione di un nodo nel deployment diagram p.61 Figura 1.51: Esempio di deployment diagram p.62 Figura 1.52: T-connector p.63 Figura 1.53: Rete di calcolatori p.64 Figura 1.54: Deployment diagram finale p.64 Figura 1.55: Elementi strutturali p.65 Figura 1.56: Elementi comportamentali p.65 Figura 1.57: Relazioni p.65 Figura 1.58: Raggruppamento p.65 Figura 1.59: Annotazioni e actor p.66 Figura 2.1: Schema a blocchi di una s-funtion p.68 Figura 2.2: Come Simulink esegue la simulazione p.69 Tabella 2.1: Stadi di simulazione p.70 Figura 2.3: Schema simulink p.74 Figura 2.4: Schema di funzionamento p.74 Figura 2.5: Sequenza di esecuzione per Real Time Workshop p.81 Figura 2.6: Sequenza di esecuzione in modalità esterna p.81 Figura 2.7: Schema ingresso p.83 Figura 2.8: Modalità di ingresso p.83 Figura 3.1: Schema di un controllo on-off p.94 Figura 3.2: Struttura di uno stato stateflow p.95 Figura 3.3: Esempio di stati paralleli p.96 Figura 3.4: Esempio di transizione p.96 Figura 3.5: Come scrivere una transizione p.97 Figura 3.6: Transizione di default p.97 Figura 3.7: Esempio di giunzione p.98 Figura 3.8: Ulteriore esempio di giunzione p.99 Figura 3.9: History junction p.99 Figura 4.1: Diagramma di carico statico p.104 Figura 4.2: Area di lavoro p.105 Figura 4.3: KUKA KR125/3 p.107 Figura 4.4: Area di lavoro p.107 Figura 4.5: Superfici di riferimento dei pezzi A e B p.109 Figura 4.6: Disegno schematico di un pezzo saldato p.110 Figura 4.7: Schema di disposizione di un pezzo saldato sul pallet p.110 Figura 4.8: GR/TR1 p.111 Figura 4.9: Disegno quotato di massima del pallet adottato p.112 Figura 4.10: RP2E-150N p.113 Figura 4.11: Disegno 3D del supporto p.113

Figura 4.12: Tavola con elementi di riferimento e bloccaggio pezzo p.114 Figura 4.13: Rastrelliera p.115 Figura 4.14: Layout p.117 Figura 4.15: Disegno quotato del layout p.118


131

Figura 4.16: Class Diagram – cella di lavoro p.119 Figura 4.17: State Diagram Movimentatore – cella lavoro p.121 Figura 4.18: State Diagram Saldatore – cella lavoro p.122 Figura 4.19: Collabotation Diagram – cella lavoro p.123 Figura 4.20: Sequence Diagram – cella lavoro p.124 Figura 4.21: Modello Simulink – cella lavoro p.125


132

Bibliografia Booch G., Rumbaugh J., Jacobson J., “Unified Modeling Language User Guide”. Addison-Wesley, 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.

Laurea Specialistica in Ingegneria dell’Automazione · 1.2 Perché utilizzare UML Ogni qualvolta,...

Documents

Transcript of Laurea Specialistica in Ingegneria dell’Automazione · 1.2 Perché utilizzare UML Ogni qualvolta,...