Università di Pisa. Laurea Specialistica in Ingegneria dell Automazione Progetto di Controllo dei Processi

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

ABSTRACT Partendo da una analisi approfondita sulle potenzialità che oggi offre Unified Modeling Language si mostra come questo linguaggio si ponga da tramite tra cliente e committente, per evitare inutili incomprensioni e per permettere la realizzazione di un modello completo e dettagliato di un sistema. Grazie ad UML è possibile realizzare simulazioni in ambiente Matlab percorrendo un processo di integrazione completo tra le due piattaforme di sviluppo 2

Indice 1. L UNIFIED MODELING LANGUAGE 1.1 UML: che cosa è p. 4 1.2 Perché utilizzare UML p. 6 1.3 La genesi p. 9 1.4 UML: come metamodello p. 11 1.5 Sintassi astratta p. 14 1.6 Gli strumenti di lavoro UML p. 17 1.7 Componenti UML p. 18 1.8 Il Class Diagram: approfondimenti p. 21 1.9 Use Case Diagrams: specifiche p. 34 1.10 State Diagrams p. 42 1.11 Sequence Diagrams p. 46 1.12 Deployment Diagrams p. 63 2 LE S-FUNTIONS 2.1 Introduzione alle S-Functions p. 69 2.2 Guida alla scrittura delle S-Functions p. 74 2.3 Panoramica sulle Routines p. 82 3 LO STATEFLOW MATLAB 3.1 Introduzione p. 94 3.1 Stato p. 96 3.2 Transizione p. 97 3.3 Giunzione p. 99 3.4 Eventi p. 101 3.5 Dati p. 101 4. DA UML A MATLAB: UN ESEMPIO 4.1 Introduzione p. 102 4.2 Scelta di componenti e attrezzature per l impianto p. 103 4.3 Il Class Diagram p. 118 3

4.4 State Diagram p. 120 4.5 Collaboration Diagram p. 123 4.6 Sequence Diagram p. 123 4.7 Stateflow: Statechart p. 124 4.8 Riepilogo delle Regole di traduzione p. 125 4.9 Sviluppi Futuri p. 127 4

1. L UNIFIED MODELING LANGUAGE 1.1 UML: che cosa è Lo Unified Modeling Language è un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, che di altri sistemi non strettamente software. UML rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella modellazione di vasti e complessi sistemi. Lo UML permette di visualizzare, per mezzo di un formalismo rigoroso, manufatti dell ingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni adottate. Tale linguaggio favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale non legato alle singole imprese. In teoria, un qualunque tecnico, di qualsivoglia nazionalità, dipendente della più ignota delle software house, con un minimo di conoscenza dell UML dovrebbe essere in grado di leggere il modello del progetto e di comprenderne ogni particolare senza troppa fatica e, soprattutto, senza le ambiguità tipiche del linguaggio naturale. Come al solito qualche problema può sempre emergere, ma si tratterebbe comunque di problemi di poca entità. Un conto è non comprendere qualche particolare, un altro è non comprendere assolutamente cosa voleva realizzare l autore. I vantaggi che derivano dal poter disporre di un modello del sistema sono notevoli e fin troppo evidenti. Basti pensare alla non indifferente semplificazione del processo di manutenzione che, da solo, tipicamente incide più del 50% nel ciclo di vita dei sistemi ben progettati; alla possibilità di allocare risorse aggiuntive in corso d opera, riducendo il rischio che ciò diventi controproducente. Disporre di un linguaggio per descrivere un sistema costringe il progettista stesso ad analizzare, con maggior minuzia, aspetti del sistema anche di un certo rilievo, i quali, viceversa, potrebbero incautamente venir trascurati da un analisi non molto rigorosa. Per ciò che concerne l utilizzo dello UML nello specificare, bisogna tener presente che in questo contesto l espressione si riferisce alla possibilità di realizzare modelli completi, precisi e non ambigui. Lo UML dispone di tutti i meccanismi necessari per la specifica di qualsiasi particolare ritenuto rilevante in ogni fase del ciclo di vita del progetto e quindi, in ultima analisi, per produrre modelli accurati. Lo UML, permette di realizzare modelli che si prestano ad essere implementati con diversi linguaggi di programmazione, sebbene risulti particolarmente efficace per la progettazione di 5

sistemi Object Oriented. In effetti è possibile realizzare un mapping esplicito tra un modello UML e un linguaggio di programmazione. Chiaramente, tale legame risulta più immediato per i linguaggi fortemente basati sul paradigma Object Oriented, quali C++, Java, Small-Talk, Ada, e così via. Gli stadi evolutivi attraverso cui si sono sviluppate le metodologie per la realizzazione del software orientato agli oggetti si basano su: Utilizzo dei primi linguaggi di programmazione orientati agli oggetti; Sviluppo di tecniche di analisi e progettazione orientate agli oggetti per aiutare la modellazione dei sistemi commerciali, l analisi dei requisiti e la progettazione di sistemi software. Il numero di queste tecniche cresce rapidamente; Nascita dell UML, progettato per combinare tra loro i vantaggi delle numerose notazioni e tecniche di analisi e progettazione, così da ottenere uno standard a livello industriale. Sul mercato sono presenti diversistrumenti, in grado di generare codice a partire dal relativo modello, sia interattivamente durante la fase di disegno, sia su richiesta. L esistenza di queste funzionalità, sebbene ancora non del tutto mature, dovrebbe far capire che l implementazione è veramente un particolare del disegno, specie con linguaggi come Java. La generazione automatica di una prima implementazione del sistema risulta particolarmente utile quando il modello deve essere realizzato parallelamente (cioè sempre!), poiché fornisce, ai diversi sviluppatori, lo scheletro eventualmente con qualche metodo implementato delle classi fondamentali del sistema che dovrebbero presentare un interfaccia stabile e ben definita. Sebbene alcuni strumenti tentino, in alcuni casi particolari, di realizzare determinati metodi con il codice appropriato, è probabilmente ancora un po prematuro azzardarsi a utilizzare appieno tale funzionalità, a meno che non si tratti di meri metodi get / set di proprietà. Il mapping tra modello e linguaggio di programmazione permette anche la realizzazione di funzioni di reverse engineering: fornendo a un opportuno tool i codici sorgenti o, talune volte anche quelli compilati, questo è in grado di ricostruire a ritroso il modello fino, ovviamente, alla fase di disegno. Purtroppo non si è ancora riusciti a realizzare un tool in grado di ricostruire i requisiti del cliente. Il processo diretto (engineering) e quello inverso (reverse engineering) determinano quello che in gergo viene definito round-trip engineering. Nel mondo ideale, la funzione di reverse 6

non dovrebbe mai venir utilizzata, in quello reale è invece molto apprezzata, e tutto dipende dall uso che se ne fa. In fase di disegno, probabilmente non è opportuno descrivere tutto dettagliatamente; verosimilmente è opportuno lasciare qualche margine ai programmatori (tutto in funzione delle loro capacità). Sono ritenute assolutamente naturali e accettabili modifiche del modello in fase di codifica, fintantoché queste non stravolgano il modello stesso. Durante la fase di codifica può anche accadere di accorgersi che una data libreria non funziona come dovrebbe, o che c è qualche lacuna nel modello, o che risulta opportuno cambiare qualche strategia al fine di ottenere un codice più efficiente. Tutto ciò è normalissimo. Tuttavia, nell eventualità che le modifiche generino uno stravolgimento del modello, piuttosto che procedere nell implementazione sarebbe forse necessario introdurre un opportuna iterazione della fase di disegno e successiva codifica. Un progetto, per quanto ben congegnato, potrebbe perdere gran parte del suo fascino se poco documentato, o addirittura potrebbe finire per non essere compreso e in futuro non venire correttamente aggiornato. Per terminare, lo UML fornisce sia dei meccanismi molto formali, sia del testo libero da aggiungere, ogni qual volta lo si ritenga necessario, a parti ritenute poco chiare o particolarmente complesse, al fine di aumentarne il livello di particolare. 1.2 Perché utilizzare UML Ogni qualvolta, in una disciplina dell ingegneria, vi sia la necessità di realizzare un manufatto, indipendentemente dalla dimensione e dal settore di interesse (una casa, un grattacielo, un particolare meccanismo, un ponte, un dipartimento di un azienda, e così via) si procede cercando di realizzarne un modello. L obiettivo è produrre, in tempi relativamente brevi e soprattutto a costi contenuti, una versione razionalizzata e semplificata del sistema reale che, tuttavia, consenta di evidenziarne l aspetto finale e di studiarne prestazioni, affidabilità e comportamento. I modelli, importantissimi in tutti i processi di sviluppo, trovano la loro più completa legittimazione nell ambito di sistemi di dimensioni medie e grandi. In tali circostanze la complessità di questi sistemi nella loro interezza ne rende molto difficoltosa la comprensione. È quindi maggiormente avvertita la necessità di avvalersi di modelli in grado di descrivere, in maniera semplificata, sistemi comunque complessi. 7

Si vedrà come lo UML, grazie alla sua organizzazione in viste (Views), risponda alla logica necessità della mente umana di concentrarsi, in ogni istante, su un numero limitato di aspetti del sistema ritenuti importanti per la particolare fase del processo di sviluppo, rimandando a momenti successivi l analisi degli aspetti rilevanti per le altre viste. Figura 1.1: La vignetta dell altalena Oltre ai motivi già citati, i modelli sono basilari poiché, avvalendosi anche del feedback fornito dai committenti, permettono di definire i requisiti del sistema in maniera chiara e, con la cooperazione del proprio gruppo, di razionalizzarne il processo di sviluppo. I vantaggi che se ne ricavano sono diversi: adeguate analisi dei tempi, migliori stime dei costi, piani più precisi di allocazione delle risorse, distribuzioni più affidabili del carico di lavoro. Si riesce quindi a risparmiare tempo e denaro, a ridurre i fattori di rischio presenti in ogni progetto, a studiare la risposta del sistema a particolari sollecitazioni, e via di seguito. Nonostante però il grande valore apportato all ingegneria del software dall utilizzo della modellazione, troppo spesso in molte organizzazioni questa meravigliosa tecnica rimane ancora una chimera. 8

A nessuno appartenente al settore dell ingegneria edile verrebbe in mente di costruire interamente un grattacielo, per poi studiarne la risposta a sollecitazioni di carattere sismico. Il buon senso, risorsa purtroppo sempre rara, suggerisce di procedere con la realizzazione di una versione miniaturizzata sulla quale condurre tutti gli studi del caso. Non necessariamente un processo di modellazione genera un oggetto tangibile: talvolta si tenta di rappresentare un complesso reale per mezzo di eleganti sistemi di disequazioni e quindi l intero modello si risolve in una raffinata astrazione. Tutto ciò che è fin troppo scontato in molte discipline dell ingegneria non lo è nel settore dell Informatica o dell Automazione, ad essa strettamente connessa. In molte organizzazioni la produzione del software è ancora un attività, per così dire, artigianale in cui il relativo processo di sviluppo prevede tre fasi: analisi dei requisiti, implementazione e test.. Si provi a immaginare che cosa potrebbe accadere se si avviasse la progettazione di un ponte a partire da specifiche sommarie, magari comunicate verbalmente o, peggio ancora, se si partisse subito a costruirlo materialmente, magari affidandosi all esperienza di qualche costruttore (vedi figura 1.1). Inconcepibile! Tutto ciò, benché possa sembrare fuori dal mondo, molto spesso è prassi comune nel mondo dell ingegneria informatica. Malgrado siano stati versati fiumi d inchiostro sull argomento, e svariati gruppi di ricerca lavorino a tempo pieno per la definizione di nuovi standard di analisi, in molte organizzazioni, soprattutto italiane, anche di comprovato prestigio, tale attività è ancora considerata prettamente accademica, vezzo di giovani neolaureati perché, in ultima analisi, è di scarsa utilità nel mondo reale, dove l obiettivo è produrre codice e l esperienza è in grado di sopperire a tutto. L inevitabile risultato è che spesso si procede cominciando paradossalmente da una delle ultime fasi del processo di ingegnerizzazione, ossia dalla stesura del codice (paragonabile alla costruzione del ponte di cui si parlava nell esempio). Si inizia concentrandosi prematuramente sul modo in cui redigere il codice ed, eventualmente, alla fine si scrivono due righe di analisi, magari demandando il tedioso incarico all ultimo arrivato nel team. In molte occasioni può accadere che, a progetto ultimato e pronto per la consegna, ci si accorga dell errata architettura. Non è da escludere, nel peggiore dei casi, che, per via di uno sviluppo interamente incentrato sulla fase di codifica, e quindi privo della visione globale che solo un buon processo di modellazione può apportare, sia praticamente impossibile integrare i moduli prodotti in parallelo o che sia necessario costruire estemporanei moduli di interfaccia o, ancora, che il sistema preveda percorsi così tortuosi da renderlo praticamente inutilizzabile. 9

Per terminare, sintetizzando al massimo il concetto si può dire che si modella essenzialmente per due motivi: aumentare la propria comprensione sia di un problema sia di eventuali soluzioni ipotizzate; comunicare. 1.3 La genesi Originariamente il lavoro fu iniziato da Grady Booch e James Rumbaugh, con l intento di produrre un nuovo metodo, detto metodo unificato che raccogliesse il meglio dei metodi Booch e OMT-2, del quale Rumbaugh era stato uno dei principali promotori. Nel 1995 si unì a loro Ivar Jacobson, fautore del metodo denominato OOSE (Object Oriented Software Engineering): il terzetto si era così costituito. L azienda che promuove il progetto è la Rational Software Corporation che, dal canto suo, provvede anche ad assorbire la Objective Systems, azienda svedese che aveva sviluppato e distribuito il software Objectory. A questo punto il quadro era completo e lo standard in lavorazione fu ribattezzato Unified Modeling Language. La prima versione, la celebre 1.0, fu disponibile nel gennaio 1997. L UML è uno strumento di analisi molto versatile, nato per risolvere le problematiche connesse con la progettazione Object Oriented del software, ma che ben si adatta a essere utilizzato negli ambienti più disparati. Esso è stato, per esempio, utilizzato alla Cadence per la produzione di un dispositivo di compressione vocale operante a livello di porta fisica. Ancora, una delle aziende fornitrici della US Navy ha utilizzato lo UML come linguaggio di progettazione di un sistema d arma di nuova generazione. Un azienda sanitaria si è avvalsa dello UML nella realizzazione di un modello per il trattamento dei pazienti, e così via. Visto l enorme successo riscosso nell applicazione industriale e nel mondo accademico e considerato il relativo riconoscimento a livello di standard (UML 1.0 è stato proposto all Object Managment Group nel gennaio 1997), gli stessi ideatori dichiararono ormai conclusa la loro esperienza in questo ambito tanto da dedicarsi a nuove sfide. Allo stato attuale lo sviluppo dell UML è affidato a una task force appartenente all OMG, la famosa RTF (Revision Task Force), diretta da Chris Kobyrn. Obiettivo di tale gruppo è accogliere e analizzare suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni (bugs) e colmare eventuali lacune. 10

Attualmente dovrebbe essere già disponibile le versione 2.0. L evoluzione dello UML è mostrata in fig. 1.2, attraverso il diagramma dei componenti, uno degli strumenti messi a disposizione dal linguaggio. 11

1.4 UML: come metamodello Lo UML è un linguaggio che permette di costruire un modello di un sistema da analizzare o da progettare, ovvero permette di realizzare una rappresentazione astratta di un sistema basata su alcuni concetti fondamentali, come classi e associazioni. I concetti base dello UML vengono usati anche per descrivere la semantica del linguaggio stesso. Si ha quindi un modello per un linguaggio di modellazione, cioè un metamodello. Ad esempio si possono consultare i diagrammi delle figure 1.3 1.4 che descrivono la struttura principale del linguaggio UML, cioè la parte principale del suo metamodello. Quindi nasce il problema di rendere standard la definizione di altri linguaggi di modellazione, ognuno dei quali avrà il suo metamodello. Tra i metodologi si è ritenuto opportuno definire un linguaggio comune denominato MOF (Meta Object Facility) [MOFS] per descrivere diversi metamodelli attraverso dei meta-metamodelli (ad esempio XMI, che è il formato standard di scambio di modelli tra applicazioni di diverse piattaforme, è definito attraverso MOF). Lo UML possiede una definizione rigorosa di metamodello, istanza del meta-metamodello definito anch esso attraverso il MOF. Si tratta di concetti molto eleganti e affascinanti, ad elevato livello di astrazione. Il metamodello dello UML è descritto per mezzo dello UML stesso. Si tratta indubbiamente di una scelta molto elegante, ma ha per inconveniente che ad una prima lettura della specifica si può avere una certa confusione. Un metamodello è un modello a sua volta istanza di un meta-metamodello, fruibile per esprimere una istanza di modello: l UML (metamodello) permette di realizzare diversi modelli Object-Oriented (modelli definiti dall utente). Il metamodello dello UML definisce la struttura dei modelli UML. Un metamodello non fornisce alcuna regola su come esprimere concetti del mondo Object-Oriented, quali ad esempio classi, interfacce, relazioni e così via, ma esso rende possibile avere diverse notazioni che si conformano al metamodello stesso. Così come avviene nella relazione che lega le classi agli oggetti, una volta definita una classe si possono avere svariate istanze della stessa (oggetti), analogamente è possibile progettare un numero infinito di varianti dello UML (istanze del metamodello). Nelle sue prime apparizioni ufficiali lo UML era composto semplicemente da una notazione grafica, fruibile per rappresentare modelli di sistemi Object-Oriented. Quando poi è giunto il momento della presentazione allo OMG, per il conferimento del riconoscimento ufficiale di standard (Gennaio 1997), si è reso necessario conferirgli una veste più formale. 12

Così, a partire dalla versione 1.1, lo UML definisce rigorosamente un metamodello e la notazione atta alla formulazione di modelli Object-Oriented conformi ad esso. Riassumendo, un meta-metamodello è un modello che definisce un linguaggio per esprimere un metamodello. La relazione tra il meta-metamodello ed il metamodello è paragonabile a quella esistente tra il metamodello ed un modello. Figura 1.3: Meta-metamodello, metamodello e modello UML Lo UML è definito in termini del meta-metamodello denominato MOF: Meta Object Facility [MOFS]. Nella figura 1.3 viene illustrato graficamente quanto emerso fino a questo punto: relazioni esistenti tra il meta-metamodello, il metamodello ed il modello dell utente. Scorrendo il diagramma dall alto verso il basso si assiste ad una graduale diminuzione del livello di astrazione; se si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate entità, istanze delle classi del modello dell utente, cioè oggetti. Se, per esempio, si realizzasse un prototipo di un sistema di commercio elettronico, a livello del modello realizzato dall architetto, si troverebbero classi (opportunamente relazionate tra loro) del tipo: Categoria, SottoCategoria, Prodotto, Utente, Profilo, e così via. Se poi si volesse 13

visualizzare il livello inferiore, l istanza dello user model, bisognerebbe inserire oggetti, istanze di tali classi, come per esempio il prodotto di codice X, avente prezzo Y, della categoria Z. Per avere un idea più chiara si consulti il diagramma riportato nella figura 1.4. Figura 1.4: Esempio delle relazioni ai vari gradi di astrazione tra i modelli UML Come si può notare, nel modello di analisi compare una classe denominata Ordine appartenente al dominio del problema. La classe è un istanza della metaclasse Class, presente nel package UML metamodello, e contiene attributi ed operazioni che, a loro volta, sono istanze rispettivamente delle metaclassi Attribute ed Operation. Se anche in questo caso si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate le istanze delle classe Ordine, ossia oggetti del tipo ordine. 14

Appare che il livello di meta-metamodello ha la stessa struttura del livello di metamodello: questo fatto è causato dalla stretta relazione che c è fra MOF e UML. Infatti, a quanto si legge nella specifica ufficiale di OMG ( Meta Object Facility (MOF) Specification [MOFS]), si potrebbe avere in futuro una fusione tra i meta-metamodelli di MOF e il metamodello di UML: nel frattempo rimangono due entità distinte. In sintesi, lo UML è basato su un metamodello integrato, composto da numerosi elementi collegati fra loro secondo regole precise. Utilizzando gli elementi del metamodello è possibile creare i modelli per i sistemi da rappresentare e la maggior parte degli elementi stessi hanno un icona definita dalla notazione dello UML che li rappresenta graficamente. Gli elementi del metamodello possono comparire in diagrammi di diverso tipo e le regole sintattiche permettono di verificare la correttezza. 1.5 Sintassi astratta La sintassi astratta viene definita utilizzando la notazione dei meta-modelli. Si tratta di un sottoinsieme della notazione UML che utilizza il diagramma delle classi per definire gli elementi dei modelli UML e le relazioni che intercorrono tra loro. La figura 1.5, di seguito riportata, mostra un frammento del diagramma che definisce la sintassi astratta di UML. UML specification permette la definizione di un metodo, dei sui attributi e delle sue associazioni anche in linguaggio naturale. Questo diagramma mostra che Operazione e Metodo sono meta-classi, entrambe sottoclassi della meta-classe astratta ProprietàComportamentale, e che Operazione è una specifica di Metodo. Mentre un Operazione possiede un attributo specifica, un Metodo ha solo come attributo un corpo: la specifica nella meta-classe Operazione è una stringa che definisce il prototipo (signature) dell operazione (il suo valore di ritorno, nome e parametri). 15

ProprietàComportamentale Query: boolean Operazione Concorrenza: CallConcurrencyKind Radice: boolean Foglia: boolean Astratto: boolean Specifica: String 1 * +specifica Metodo Corpo: ProcedureExpression Figura 1.5: Frammento della sintassi astratta di UML Il corpo nella meta-classe Metodo è una procedura, probabilmente scritta in un linguaggio di programmazione, che definisce come il metodo implementa l operazione. Una determinata istanza di un operazione in una classe è un istanza della meta-classe Operazione. Metodo Un metodo è l implementazione di un operazione, esso descrive l algoritmo o la procedura che genera i risultati di un operazione. Nel meta-modello, un Metodo è una dichiarazione di un comportamento ben specifico in un Classificatore e realizza una (quindi direttamente) o un insieme (allora indirettamente) di Operazioni del Classificatore. Attributi Corpo L implementazione del Metodo come ProcedureExpression. Associazioni Specifica Indica un Operazione implementata dal Metodo. L Operazione deve essere contenuta nel Classificatore che possiede il Metodo o essere ereditata da esso. Le signature dell Operazione e del Metodo devono corrispondere. Esiste un analoga specifica per Operazione e per ogni altra meta-classe del meta-modello. 16

Regole sintattiche Le regole sintattiche che generano espressioni ben formate si applicano a istanze delle meta-classi, ossia ad operazioni, metodi, classi e tutto ciò che si trova a livello del modello. Esse forniscono le regole cui devono obbedire le istanze delle meta-classi, come un insieme di invarianti. Gli invarianti sono vincoli che non possono essere spezzati: devono sempre risultare veri perché il modello abbia significato. Sono descritti in Object Constraint Language (OCL). Ad esempio, la specifica della meta-classe Class afferma che se la classe è concreta (non astratta), allora ogni operazione dovrebbe avere un metodo che la realizza. Il vincolo seguente è scritto in OCL. Not self.astratto implies self.ognioperazione -> perogni (op self.ognimetodo -> esiste (m m.specifica -> include (op))) Questi vincoli sul meta-modello possono essere utilizzati per verificare che il modello si attenga alle regole di UML e sia ben formato. Si noti che OCL viene utilizzato all interno di UML per esprimere vincoli interni al modello. Per esempio, se una delle regola di un sistema per condividere i viaggi, prevede che ogni viaggio legato da un contratto di condivisione deve essere svolto da un diverso Car Sharer (persona che condivide la propria macchina), questo potrebbe essere espresso in OCL nel seguente modo: context ContrattoCondivisione inv: self.condiviso->forall (i, j (i.viaggia = j.viaggia) implies i = j) In italiano, questo significa che nel contesto della classe ContrattoCondivisione c'è una regola invariante definita come segue: se si prende ogni possibile coppia di collegamenti tra un'istanza di ContrattoCondivisione e istanze di Viaggio basate sull associazione Condiviso, e per ogni membro della coppia si segue il collegamento basato sull'associazione viaggia fino a un'istanza della classe Car Sharer e se tali collegamenti sono gli stessi, anche i due viaggi sono uguali. E dato che i due viaggi sono in realtà lo stesso viaggio, ne deriva che due diversi viaggi appartenenti allo stesso Car Sharer non possono essere condivisi all'interno dello stesso accordo di condivisione. 17

Semantica La semantica di UML è descritta in linguaggio naturale. Per esempio, quella che segue è la descrizione della meta-classe Operazione (vedi figura 1.5). Un Operazione è un costrutto concettuale, mentre il Metodo è il costrutto per l implementazione. Le loro caratteristiche comuni, come possedere una segnature, sono espresse rispettivamente nella meta-classe ProprietàComportamentale e nella semantica specifica dell Operazione. I costrutti del Metodo sono definiti nella corrispondente sottoclasse di ProprietàComportamentale. Tuttavia la maggior parte delle informazioni relative alle operazioni si trova nella definizione di Classe. La comprensione completa della semantica richiederebbe la lettura approfondita di tutta questa parte. 1.6 Gli strumenti di lavoro UML Come ogni linguaggio che si rispetti anche l'uml necessita di tools appropriati che ne agevolino l'utilizzo. Servirsi di carta e penna è sicuramente sempre valido ma non può certamente garantire da solo un risultato apprezzabile. Ci sono sul mercato tanti tools che trattano l'uml. Probabilmente, però, il più diffuso è lo strumento della Rational, Il Rose. Il Rational Rose è stato disegnato per fornire ai team di sviluppo tutti gli strumenti necessari per il modellamento di soluzioni robuste ed efficienti. La Microsoft ha prodotto uno strumento che permette di definire un sottoinsieme dei modelli che il Rational Rose mette a disposizione: il Microsoft Visual Modeler. Tale software si può consigliare a chi si avvicina per la prima volta al mondo del Visual Modeling. Il Microsoft Visual Modeler permette, tra l'altro, di: Identificare e disegnare oggetti del business e mapparli in componenti software; Descrivere come i componenti possono essere distribuiti su una rete; Generare codice base Visual Basic direttamente dalla costruzione del modello; Utilizzare il reverse engineering per creare i modelli da applicazioni già esistenti. 18

Altro strumento da segnalare è UMLet, un software open source basato su Java che permette la scrittura di diagrammi UML. Tra le opzioni, la possibilità di esportare i diagrammi in SVG, JPG e PDF. 1.7 Componenti UML Il linguaggio UML contiene svariati elementi grafici che vengono messi insieme durante la creazione dei diagrammi. Dato che l'uml è un linguaggio, come tale utilizza delle regole per combinare i componenti nella creazione dei diagrammi. L'obiettivo dei diagrammi è quello di costruire molteplici viste di un sistema tutte correlate tra di loro. L'insieme di tali viste costituirà quello che abbiamo definito Visual Modeling. Si passano ora in rassegna, brevemente, tutti i diagrammi UML prima di analizzarli più dettagliatamente in seguito. La notazione UML include dieci tipi di diagrammi, divisi in cinque categorie. Si tenga presente che è assolutamente possibile costruire e aggiungere dei diagrammi differenti dagli standard (che vengono definiti ibridi) rispetto a quelli definiti dal linguaggio. La tabella 1.1 mostra le categorie e i diagrammi corrispondenti. Tabella 1.1: Classificazione dei diagrammi UML 19

Class Diagram Per avere una idea immediata di cosa sia una classe è possibile usare come esempio il fatto che tutti gli oggetti o esseri viventi, spesso, sono riconducibili a determinate categorie (computers, automobili, piante, animali). Queste categorie costituiscono le classi. Una classe è una categoria o un gruppo di oggetti (con questo termine si includono, per comodità anche gli esseri viventi) che hanno attributi simili e comportamenti analoghi. I Class Diagrams forniscono le rappresentazioni utilizzate dagli sviluppatori. Object Diagram Un oggetto è una istanza di una classe, ovvero una qualcosa di specifico che ha dei valori determinati per i suoi attributi e dei comportamenti specifici. Use Case Diagram Uno Use Case (caso d'uso) è una descrizione di un comportamento particolare di un sistema dal punto di vista dell'utente. Per gli sviluppatori, gli use case diagram rappresentano uno strumento notevole: infatti tramite tali diagrammi, essi possono agevolmente ottenere una idea chiara dei requisiti del sistema dal punto di vista utente e quindi scrivere il codice senza timore di non aver recepito bene lo scopo finale. Nella rappresentazione grafica, viene utilizzato un simbolo particolare per l'actor (l'utente o un altro sistema che interagisce) che si vedrà in seguito. L'actor è l'entità che interagisce con uno use case facendo partire la sequenza di azioni descritte dallo use case stesso e, eventualmente, ricevendo delle precise risposte dal sistema. Può essere una persona o anche un altro sistema. State Diagram Ad un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un particolare stato. Gli State Diagrams rappresentano tali stati, ed i loro cambiamenti nel tempo. Ogni state diagram inizia con un simbolo che identifica lo stato iniziale (Start State) e termina con un altro simbolo che rappresenta lo stato finale (End State). Per esempio, ogni persona può essere identificato dai seguenti stati: neonato, bambino, adolescente, adulto, anziano. 20