UML 2.

0
Danilo Bruno
danilob82@libero.it

Samuele Carpene
samuelecarpene@msn.com

Luca Montinari
luca.montinari@fastwebnet.it

ABSTRACT
Il documento ha come obiettivo una trattazione sintetica della specifica di UML 2.0, dando maggiore rilevanza alle nuove funzionalit ed innovazioni, e ai cambiamenti introdotti in questultima versione. In particolare, possibile cogliere modifiche e caratteristiche relative al metamodello (e metametamodello) , ai diagrammi gi esistenti nelle precedenti versioni ed a quelli di ultima generazione, al linguaggio di specifica dei vincoli (Object Constraint Language), ad XMI, standard per lo scambio di modelli tra differenti tool. Nellultima parte del documento vengono presentati 3 tool che supportano UML 2.0, elencando per ciascuno le caratteristiche che ne evidenziano le potenzialit offerte. In contrasto con labbozzo, UML come progetto rivolto innanzitutto alla completezza. Nel forward engineering, un progetto simile sar sviluppato da un ingegnere il cui lavoro proprio quello di fornire ai programmatori un modello dettagliato da implementare. Il modello dovrebbe essere sufficientemente completo da esprimere tutte le decisioni di progetto, cos che il programmatore possa seguirlo in modo abbastanza lineare, senza bisogno di interpretarne alcun aspetto. Questo aspetto ispirato alle branche dellingegneria classica in cui i professionisti creano disegni tecnici dettagliati che vengono poi passati alle compagnie per la produzione. Nel reverse engineering, questa tipologia dutilizzo utile nella documentazione di progetto, in sostanza la modellazione UML descrive ogni parte del sistema realizzato Il confine tra i progetti abbozzati e quelli dettagliati non perfettamente delineato: la distinzione, in ogni caso, sta nel fatto che i bozzetti sono deliberatamente incompleti e si concentrano solo sulle informazioni pi importanti, mentre lintento dei progetti quello di essere esaustivi, spesso con lo scopo di ridurre la programmazione a unattivit semplice e relativamente meccanica. Riassumendo, gli abbozzi sono rivolti allesplorazione di un problema, i progetti alla sua definizione. Lultimo modo di intendere UML come linguaggio di programmazione; qui viene utilizzato per compilare direttamente i diagrammi in formato eseguibile, in questo caso UML e codice sorgente coincidono e non c distinzione tra forward e reverse engineering. Lo scopo principale permettere agli sviluppatori di programmare in modo visuale, indipendentemente dalla piattaforma software adottata, per fare questo stato definita larchitettura MDA (Model Driver Architecture), seguendo questa architettura gli sviluppatori creano un PIM (Platform Independent Model), il PIM trasformato (semi-)automaticamente in un PLM (Platform Specific Model), poi il PLM viene trasformato automaticamente in codice specifico di una piattaforma. Esistono gi strumenti che permettono di creare direttamente del codice dai diagrammi UML, per sono ancora poco maturi. Dopo varie revisioni dello standard, si arrivati alla versione 2.0 che definisce in modo pi rigoroso e formale il meta-modello di UML ed aggiunge qualche nuovo diagramma.

1. INTRODUZIONE 1.1 Cos UML

Lo Unified Modeling Language (UML) una famiglia di notazioni grafiche, basate su un singolo meta-modello (che il modello di struttura base utilizzato da UML) e servono a supportare la descrizione e il progetto dei sistemi software, in particolare quelli costruiti seguendo il paradigma orientato agli oggetti. UML si pu utilizzare in tre modi: abbozzo (sketch), progetto dettagliato (blueprint) e linguaggio di programmazione. Nella maggior parte dei casi UML viene utilizzato come abbozzo, secondo questo criterio gil sviluppatori usano UML per aiutare a documentare alcuni aspetti del sistema sia prima (nel forward engineering) che il sistema sia sviluppato, che partendo da un sistema gi esistente (nel reverse engineering); lo scopo principale favorire la comprensione e la comunicazione nelle discussioni. Laspetto fondamentale della creazione di abbozzi la selettivit: quando si stende lo schizzo di un progetto in via di sviluppo, si identificano alcuni dei problemi nel codice che si dovr scrivere, e di solito se ne discute con il gruppo. In questo approccio qualsiasi informazione pu essere soppressa; dal momento che gli abbozzi non sono formali e cambiano rapidamente, vanno disegnati in poco tempo ed in modo collaborativo, per questo motivo si usa spesso una lavagna. Un ulteriore utilizzo dellabbozzo per creare documentazione relativa a una parte di interesse, in sostanza partendo da un sistema software esistente si usa labbozzo per descriverne una specifica parte.

2. IL META-MODELLO
Nella versione 2.0, la revisione dello standard UML stata affidata a 4 Revision Task Force (RTF): UML Infrastructure: come ne suggerisce il nome, obiettivo di questa RTF consiste nel curare miglioramenti relativi alla struttura base del metamodello UML, ossia, riguardanti il core (cuore di UML), i meccanismi di estensione, le facility del linguaggio ecc. In particolare i relativi obiettivi sono di allineare larchitettura dello UML agli altri standard gestisti dallOMG (quali per esempio il MOF, Meta Object Facility, Meta-data Interchange XMI), ristrutturare il linguaggio al fine

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Argomenti Avanzati di Ingegneria del Software 2005 Politecnico di Milano, ITALIA. Copyright 2005 ACM 7/06/2005$5.00.

di renderlo pi comprensibile ed estenderlo mantenendo per la semantica e notazione attuale. UML Superstructure: obiettivo di questa RTF elaborare proposte atte ad incorporare le best-pratices in aree particolarmente sensibili come lo sviluppo di sistemi basati sui componenti, i modelli architetturali, quelli eseguibili e dellarea business. In particolare necessario studiare ulteriormente le soluzioni per: o la gestione degli eventi nei diagrammi delle attivit. o migliorare lillustrazione dellincapsulamento con particolare riferimento ai diagrammi di stato e di sequenza; o ridefinire la semantica di relazioni generalizzazione, associazione, ecc. come la

Come detto sopra il metamodello organizzato a livelli, i primi tre livelli sono: Le specifiche del linguaggio, o il metamodello Le specifiche dellutente, o il modello (realizzate rispettando le regole definite nel metamodello) Gli oggetti del modello, usati dagli utenti come linguaggio. Gli utenti finali vedono le specifiche dellutente come metamodello e le specifiche del linguaggio come metametamodello

Questi tre strati possono essere iterati per creare nuovi metamodelli, il quarto livello linstanza a runtime degli oggetti del modello. Per chiarire meglio larchitettura di UML in figura 1 mostrato un esempio di come viene utilizzata la stratificazione in UML.

o il supporto dello sviluppo component-based di sistemi software. o il supporto per architetture a tempo di esecuzione, favorendone la descrizione del comportamento dinamico e leventuale rappresentazione gerarchica. Object Constraint Language: il nome di questa RTF evidenzia chiaramente quale sia la relativa area di competenza: lOCL. Gli obiettivi sono di presentare proposte atte ad aumentare il livello di specializzazione dellOCL per lutilizzo UML. Ci dovrebbe semplificare il lavoro degli utenti, favorendo laumento di formalit dei vari modelli prodotti. UML Diagram Interchange: obiettivo di questa RTF favorire lo scambio di modelli UML prodotto da tool diversi.

2.1 UML Infrastructure

Questo documento definisce il linguaggio dei costrutti fondamentali richiesti da UML 2.0, definito usando un approccio basato su un meta-modello. Il metamodello UML stato progettato per rispettare questi principi: Modularit: questo principio applicato ai costrutti allinterno dei package e consiste nel suddividere in moduli lintero sistema. Layering: applicato in due modi al metamodello. Primo, la struttura del package stratificata per separare i costrutti del core del metalinguaggio dai costrutti di alto livello che lo usano (implementano). Secondo, viene usata unarchitettura a 4 livelli per separare i vari livelli di astrazione. Partizionamento: usato per organizzare le aree concettuali dello stesso livello. Nel caso dellInfrastructureLibrary una partizione fine-grained usata per fornire la flessibilit richiesta dagli standard correnti e futuri. Estensibilit: UML pu essere esteso in due modi: un nuovo dialetto di UML pu essere definito usando il package Profiles (che implementa le librerie) per adattare il linguaggio a particolari piattaforme, oppure un nuovo linguaggio collegato ad UML pu essere specificato riusando parti dell InfrastructureLibrary (cio implementandole). Riuso. Figura 1: Esempio layering UML Nel documento definita la libreria InfrastructureLibrary che soddisfa i seguenti requisiti di design: definisce un metalinguaggio che pu essere riusato per definire una variet di metamodelli (UML, MOF) definisce un allineamento dellarchitettura UML, MOF e XMI per supportare il diagram interchange possibilit di personalizzare UML tramite profili e la creazione di nuovi linguaggi basati sullo stesso core.

La libreria composta da due Macro Package: Core e Profiles, che ora andremo ad analizzare un p pi approfonditamente. La figura 2 illustra come il package profiles dipenda dal package core, per semplicit si pu pensare che il package Core sia una classe astratta e il package Profiles ne sia unimplementazione. In altro modo potremo pensare che il Core stabilisca delle regole e Profiles realizzi qualcosa che le rispetta.

Basic rappresenta una serie di costrutti che sono usati come basi per la produzione di XMI per UML, MOF e altri metamodelli basati sullInfrastructureLibrary.

Il package Profiles contiene il meccanismo usato per creare i profili di uno specifico metamodello, in particolare di UML. Obiettivo della libreria allineare larchitettura UML con MOF per rendere i due metamodelli pi compatibili tra di loro, per fare questo lRFT ha definito un core comune e si assicurata che UML sia definito come un modello basato sulluso del metamodello MOF.

Figura 2: Composizione di InfrastructureLibrary Il package Core un metamodello completo progettato per la riusabilit, importabile da altri metamodelli allo stesso livello, come si vede dalla figura sottostante.

3. DIAGRAMMI
I diagrammi definiti in UML 2 sono 13 e possono essere divisi in due categorie: diagrammi strutturali e comportamentali. Ora elencheremo tutti i diagrammi e pi avanti li analizzeremo sottolineando le differenze con UML 1.x: Diagrammi strutturali (structure diagram) Diagramma delle classi (class diagram) Diagramma dei componenti (component diagram) Diagramma di struttura composita (composite structure diagram)

Figura 3: Dipendenze con il package core

Diagramma di deployment (deployment diagram) Diagramma degli oggetti (object diagram) Diagramma dei package (package diagram) Diagrammi comportamentali (behavior diagram) Diagramma delle attivit (activity diagram) Diagramma dei casi duso (use case diagram) Diagramma di macchina a stati (state machine diagram) Diagramma di interazione (interaction diagram) Diagramma di sequenza (sequence diagram) Diagramma diagram) di comunicazione (communication

Figura 4: Struttura Package Core Per facilitare il riuso della libreria, il package core suddiviso in sottopackage, come si vede in figura 4: PrimitiveTypes contiene semplicemente un numero di tipi predefiniti che sono comunemente usati nel metamodello quando si definisce la sintassi astratta, ed stato progettato per cercare di soddisfare le necessita di UML e MOF. Abstractions contiene le metaclassi astratte che dovrebbero essere specializzate e sono pensate per il riuso in altri metamodelli. Il package Constructs, contiene le metaclassi concrete che si prestano alla modellazione orientata agli oggetti, questo package in particolore riusato da MOF e UML, e rappresenta una parte significante del lavoro per allineare i due metamodelli.

Diagramma di interazione generale (interaction overview diagram) Diagramma di temporizzazione (timing diagram)

3.1 Diagramma Delle Classi

Il diagramma delle classi non solo il modello UML usato pi ampiamente, ma anche quello che si presta a descrivere il maggior numero dei concetti. Gli elementi base sono utilizzati da tutti, mentre i concetti pi avanzati sono di ostica comprensione: per questo motivo si pu dividere la trattazione in due parti, presentando gli aspetti fondamentali separati dagli argomenti avanzati.

3.1.1 Aspetti generali del diagramma delle classi

Un diagramma delle classi descrive il tipo degli oggetti facenti parte di un sistema e le varie tipologie di relazioni statiche tra di essi. I diagrammi delle classi mostrano anche le propriet e le operazioni di una classe e i vincoli che si applicano ai collegamenti tra gli oggetti. UML usa il termine caratteristica (feature) per

indicare generalmente sia le propriet che le operazioni di una classe.

visibilit nome: tipo molteplicit = default {stringa di propriet}.

Un esempio di attributo :
{readOnly}.

nome:

String

[1]

Pippo

Lunico elemento necessario il nome.

Visibilit:

attributo pubblico (+) o privato(-);

Nome: corrisponde al nome di un campo in un linguaggio di programmazione; Tipo:

vincolo sugli oggetti che possono rappresentare lattributo (tipo di dato); trattato pi avanti;

Molteplicit: Default:

valore dellattributo in un oggetto appena creato; caratteristiche aggiuntive.

stringa di propriet:

Associazioni Le associazioni sono un altro modo di rappresentare le propriet. Gran parte dellinformazione che pu essere associata a un attributo si applica anche alle associazioni. Le due figure mostrano le stesse propriet rappresentate nelle due diverse notazioni: Figura 5: Esempio di Diagramma delle Classi nel caso di Gestione degli Ordini. Nella figura 5 viene mostrato il diagramma usato per le classi (familiare a chiunque). Il box rappresenta la classe, ed eventualmente, diviso in tre sezioni che contengono rispettivamente il nome della classe (scritto in grassetto), i suoi attributi e le sue operazioni.

Figura 7: Le propriet di un ordine espresse come attributi.

Figura 8: Le propriet di un ordine espresse come associazioni. Unassociazione una linea continua che collega due classi, orientata dalla classe sorgente a quella destinazione. Il nome e la molteplicit vanno indicati vicino allestremit finale dellassociazione: la classe destinazione corrisponde al tipo della propriet. Bench gran parte delle stesse informazioni appaiano in entrambe le notazioni, alcuni aspetti sono diversi: in particolare, le associazioni possono indicare la molteplicit a entrambi i capi della linea. Con due notazioni che si possono usare come facciamo a scegliere quella giusta? In generale si usano gli attributi per le piccole cose (date, booleani,ecc. generalmente chiamati oggetti valore) e le associazioni per le classi pi significative. Molteplicit lindicazione di quanti oggetti possono entrare a far parte di una propriet. Le molteplicit pi comuni sono: 1 (indica la partecipazione allassociazione di un solo oggetto)

Figura 6: Rappresentazione di una classe. Propriet Le propriet rappresentano le caratteristiche strutturali di una classe. In prima approssimazione si pu pensare che le propriet corrispondano ai campi della classe. In realt il discorso molto pi complicato, come si vedr, ma questo un buon punto di partenza. Le propriet sono un unico concetto, rappresentato per con due notazioni molto diverse: attributi e associazioni. Bench il loro aspetto grafico sia molto differente, concettualmente sono la stessa cosa. Attributi La notazione degli attributi descrive una propriet con una riga di testo allinterno del box della classe. La forma completa :

0..1 (indica la partecipazione opzionale di un oggetto) * (indica la partecipazione di zero o pi oggetti)

nome : stringa lista parametri: lista parametri delloperazione tipo di ritorno: tipo di valore restituito dalloperazione, se

In modo pi generale, le molteplicit si possono definire indicando gi estremi inferiore e superiore di un intervallo (per esempio 2..4). Molti termini si riferiscono alla molteplicit degli attributi: Opzionale: indica un limite inferiore di 0 Obbligatorio: implica un limite inferiore di 1 o pi A un solo valore: implica un limite superiore di 1 A pi valori: implica che il limite superiore sia maggiore di 1, solitamente *

esiste
stringa di propriet: caratteristiche aggiuntive che si

applicano alloperazione Le operazioni possono essere di diverso tipo: Query: ottengono un valore da una classe senza effetti collaterali Modificatori: cambiano lo stato del sistema

UML 1 permetteva luso di molteplicit discontinue, come 2,5 per indicare le due possibilit distinte: questa ad esempio potrebbe essere la molteplicit dei posti su una macchina, 2 se sportiva, 5 nel caso normale. Le molteplicit discontinue venivano usate molto di rado, e UML 2 le ha eliminate. Associazioni bidirezionali Unaltra tipologia di associazione quella bidirezionale, costituita da una coppia di propriet collegate, delle quali una linversa dellaltra. Il collegamento inverso implica che, se seguite il valore di una propriet e poi il valore della propriet collegata, dovreste ritornare allinterno di un insieme che contiene il vostro punto di partenza.

Altri termini di uso comune per i metodi sono: get restituisce il valore di un campo set scrive un valore in un campo

Unoperazione viene invocata su un oggetto, e corrisponde alla dichiarazione di un procedura, mentre un metodo il corpo di tale procedura. Le due cose sono diverse in presenza di polimorfismo. Se avete un supertipo con tre sottotipi, e ognuno di questi tre ridefinisce con loverriding loperazione del supertipo, c una sola operazione e quattro metodi che la implementano. Generalizzazione Un esempio tipico di generalizzazione sono i clienti di unazienda che possono essere soggetti privati o altre aziende. I due casi sono diversi, ma hanno anche molti punti in comune che possono essere raccolti in una classe generale Cliente (il supertipo), di cui Cliente Privato e Azienda Cliente sarebbero i sottotipi. Da un punto di vista software, linterpretazione pi naturale implica il meccanismo dellereditariet: Azienda Cliente una sottoclasse di Cliente. Nei pi diffusi linguaggi orientati agli oggetti, una sottoclasse eredita tutte le caratteristiche della superclasse e pu ridefinire i suoi metodi con loverriding. Un principio basilare dovrebbe essere la sostituibilit. Dovrebbe essere sempre possibile sostituire unAzienda Cliente ogni volta che il codice richiede un Cliente, e tutto dovrebbe continuare a funzionare perfettamente. Essenzialmente, questo significa che se devo scrivere codice che richiede luso di un Cliente, posso sempre sostituire un suo qualsiasi sottotipo. Per quanto lereditariet sia un meccanismo potente, porta con s un grado di complessit che non sempre necessario per ottenere la sostituibilit (ad esempio una sottoclasse che eredita molti dati e comportamenti non desiderati). Si possono usare molti altri meccanismi per creare classi sostituibili. Per questo in molti casi si distingue la definizione di sottotipo da quella di sottoclasse: nel primo caso si ereditano solo le interfacce, nel secondo anche limplementazione. Una classe un sottotipo se sostituibile al suo supertipo, che questo sia dovuto o meno allereditariet. Molti meccanismi permettono di creare sottotipi senza usare lereditariet: ad esempio si pu ottenere un sottotipo implementando uninterfaccia o applicando diversi classici design pattern.

Figura 9: Associazione bidirezionale. Nella figura 9, la natura bidirezionale dellassociazione palesata dalle frecce di navigabilit aggiunte a entrambi i capi della linea. La prossima figura non ha frecce; UML permette luso di questa forma per indicare unassociazione bidirezionale, ma si pu usare anche quando non si vuole mostrare una navigabilit particolare.

Figura 10: Associazione bidirezionale senza navigabilit particolare. Quando laspetto della bidirezionalit importante opportuno usare la freccia doppia per maggior chiarezza. Operazioni Le operazioni sono le azioni che la classe sa eseguire, e in genere si fanno corrispondere direttamente ai metodi della classe. Le operazioni che manipolano le propriet della classe di solito si possono dedurre, per cui non sono incluse nel diagramma. La sintassi UML completa delle operazioni
visibilit nome (lista parametri) : tipo ritorno {stringa di propr}

visibilit : attributo pubblico (+) o privato(-)

Note e Commenti Le note rappresentano commenti aggiuntivi che possono apparire in qualsiasi tipo di diagramma UML. Possono essere disegnate da sole, oppure si possono collegare con una linea tratteggiata agli elementi a cui fanno riferimento. KEYWORD call create derive instantiate permit realize refine Figura 11: Una nota serve per commentare uno o pi elementi del diagramma. La linea tratteggiata pu talvolta essere scomoda, perch difficile identificare precisamente dove termina. Per questo motivo, una convenzione comune prevede di mettere un piccolo cerchietto vuoto alla sua estremit. Qualche volta pu anche essere utile aggiungere un commento direttamente allinterno di un elemento del diagramma; in tal caso potete scrivere il testo dopo due trattini:
--.

Tabella 1: Parole chiave di UML MEANING The source calls an operation in the target The source creates instances of the target The source is derived from the target The source is an instance of the target The target allows the source to access the targets private features The source is an implementation of a specification or interface defined by the target Refinement indicates a relationship between different semantic levels; for example, the source might be a design class and the target the corresponding analysis class The source is substitutable for the target Used to track such things as requirements to classes or how changes in one model link to change elsewhere The source requires the target fot irs implementation

substitute trace

use

Dipendenza Si ha una dipendenza tra due elementi di un diagramma se la modifica alla definizione delluno (chiamato fornitore, supplier) pu causare un cambiamento allaltro (il client). Nel caso delle classi, la dipendenza pu essere causata da molti fattori: un classe pu chiamare i metodi dellaltra, o usarla come tipo di un suo campo, o prevederla come tipo di parametro di qualche operazione. Se linterfaccia della classe cambia, qualsiasi messaggio inviato ad essa potrebbe non essere pi valido. UML permette di indicare dipendenze tra ogni sorta di elementi: questo rende possibile specificare tutti i punti in cui cambiare un elemento potrebbe coinvolgerne altri. La figura 12 mostra alcune dipendenze che si possono trovare in unapplicazione complessa.

Luso pi comune delle dipendenze legate alle classi per indicare una relazione temporanea, ad esempio quando un oggetto viene passato come parametro. In questi casi si possono usare indicazioni come parameter, local e global. Queste stesse parole chiave, che non fanno parte formalmente di UML 2, venivano usate in UML 1 per indicare la temporaneit dei collegamenti, non delle propriet.

3.1.2 Argomenti avanzati del diagramma delle classi

La tecnica dei diagrammi delle classi ha dato origine a dozzine di notazioni aggiuntive usate per rappresentare concetti avanzati. Ora le vedremo una per una, evidenziando alcune particolarit. Parole chiave Uno dei problemi connessi alluso di un linguaggio grafico sta nel fatto che bisogna ricordarsi il significato dei simboli. Se ce ne sono troppi, gli utenti fanno fatica a ricordarli: per questo motivo UML cerca spesso di ridurne il numero, usando al loro posto delle parole chiave. Se si ha la necessit di modellare qualcosa e il costrutto relativo non incluso in UML, per ce n uno simile, si pu usare la notazione esistente e marcarla con una parola chiave per indicare la presenza di una variazione. Solitamente le parole chiave sono racchiuse tra virgolette uncinate. In alternativa si possono usare delle icone speciali, ma questo richiede poi che tutti si ricordino correttamente il loro significato. Alcune parole chiave, come {abstract} sono invece racchiuse tra parentesi graffe. Non molto chiaro quando si debbano usare le virgolette e quando le parentesi; fortunatamente, solo i puristi di UML pi pignoli fanno caso alla differenza. In UML 1, le virgolette uncinate erano riservate principalmente agli stereotipi. In UML 2, questi ultimi sono definiti in modo molto formale. Infatti, stereotipo e parola chiave sono due cose diverse, anche se per motivi storici molte persone usano scorrettamente i due termini in modo intercambiabile. Gli stereotipi sono usati allinterno dei profili. Un profilo prende una parte di UML e la estende per mezzo di un gruppo coerente di stereotipi adattando cos il linguaggio a un particolare dominio, come la modellazione di business. possibile usare un profilo per

Figura 12: Alcuni esempi di dipendenze. La classe Finestra dei benefici (Benefits Window) fa parte dellinterfaccia utente: quelle che ne fanno parte vengono chiamate anche classi di presentazione. Ora, tale classe dipende da Impiegato (Employee); questultimo un oggetto del dominio che incapsula il comportamento fondamentale del sistema, in questo caso alcune regole di business. Ci significa che se linterfaccia della classe Impiegato cambia, potrebbe dover cambiare anche la Finestra dei Benefici. importante notare che la dipendenza va in un sola direzione, dalla classe di presentazione a quella del dominio. UML prevede molte tipologie di dipendenza, ognuna con una particolare semantica e diverse parole chiave, ne riportiamo unelenco nella tabella seguente.

un particolare scopo, ma per usarne uno non necessario conoscere i dettagli del suo rapporto col meta-modello (poich il profilo riguarda la progettazione di questultimo). Responsabilit Spesso utile indicare su un diagramma le responsabilit di una classe. Il modo migliore per farlo aggiungerle sotto forma di stringhe di commento in un apposito scomparto della classe, come si vede in figura. possibile dare un nome esplicito allo scomparto, ma normalmente non ce n bisogno, dato che raro fare confusione.

diagramma delle classi pu mostrare pi classi di potenziali possessori di oggetti componenti, ma ogni istanza di componente deve appartenere a un solo oggetto possessore.

Figura 16: Composizione La regola di non condivisione la chiave della composizione. Un altro aspetto importante che si considera implicitamente valido che la cancellazione del poligono dovrebbe automaticamente assicurare la cancellazione di tutti i punti che gli appartengono. La composizione un buon modo per indicare propriet che si riferiscono a oggetti valore, oppure che hanno un possesso forte e in qualche modo esclusivo di altri, specifici componenti. Propriet derivate Le propriet derivate sono quelle che possono essere calcolate partendo da altri valori. Da un punto di vista software, la derivazione pu essere interpretata in due modi diversi. Si pu usarla per indicare la differenza tra un valore calcolato al momento e uno memorizzato (vedi figura 17).

Figura 13: Mostrare le responsabilit su un diagramma delle classi Operazioni e attributi statici UML chiama static unoperazione o un attributo che si applicano a una classe anzich alle sue istanze. Questa definizione equivale a quella dei membri statici nei linguaggi basati su C. Le caratteristiche statiche vanno sottolineate sul diagramma.

Figura 17: Attributi derivati in un periodo di tempo. La derivazione pu anche essere applicata alle propriet, usando la notazione dellassociazione. In questo caso si pu semplicemente marcare il nome con una barra:/. Interfacce e classi astratte

Figura 14: Notazione per le operazioni e gli attributi statici. Aggregazione e composizione Una delle maggiori fonti di confusione in UML laggregazione. Spiegarla superficialmente facile: laggregazione la relazione parte-di. come dire che una macchina ha un motore e quattro ruote come sue parti. Questo sembra ragionevole: la cosa difficile capire la differenza tra aggregazione e associazione. Le differenze tra laggregazione e associazione erano spesso alquanto vaghe, cos UML ha incluso le aggregazioni nello standard, ma praticamente non ne ha definito la semantica (vedi figura 15).

Una classe astratta una classe che non pu essere direttamente istanziata: per farlo bisogna prima crearne una sottoclasse concreta. Tipicamente, una classe astratta ha una o pi operazioni astratte. Unoperazione astratta non ha implementazione; costituita dalla sola dichiarazione, resa pubblica affinch le classi client possano usufruirne. Il modo pi diffuso di indicare una classe o unoperazione astratta in UML scriverne il nome in corsivo. Si possono anche rendere astratte le propriet. Indicandole direttamente come tali o rendendo astratti i metodi daccesso. Uninterfaccia una classe priva di implementazione;. Le classi hanno due tipi di rapporti con le interfacce: le possono fornire o richiedere. Si dice che una classe fornisce uninterfaccia se sostituibile ad essa. Una classe richiede uninterfaccia se necessita di una sua istanza per funzionare. Essenzialmente, come dire che ha una dipendenza da essa. Il fatto che ArrayList implementa List e Collection indicato dalle icone a forma di pallina che escono dal box, spesso chiamate lecca-lecca (lollipops) per il loro aspetto peculiare. Il fatto che Ordine richiede linterfaccia List viene mostrato con unicona a forma di semicerchio (socket, letteralmente presa). La connessione tra la pallina e la relativa presa chiarissima e balza allocchio in modo naturale.

Figura 15: Aggregazione. Oltre allaggregazione UML include una propriet definita in modo pi preciso, la composizione. Nella figura 16, unistanza di Punto pu essere parte di un poligono oppure il centro di un cerchio, ma non entrambe le cose . La regola generale che bench una classe possa essere componente di molte altre classi, ogni sua istanza pu essere componente di un solo oggetto. Un

Figura 18: Notazione con pallina (lollipop) e semicerchio (socket). UML ha usato i lecca-lecca per molto tempo, ma i socket a forma di semicerchio sono una novit introdotta da UML 2. Nel vecchio stile nei diagrammi veniva usata una dipendenza al posto del semicerchio come nella figura.

originale. La ragione sta nel fatto che altrimenti, nel caso gli oggetti fossero condivisi, il cambiamento avrebbe ripercussioni imprevedibili sugli altri oggetti. Questo problema noto come aliasing. In passato, la differenza tra oggetti riferimento e oggetti valore era pi chiara: gli oggetti valore erano quelli predefiniti dal linguaggio. Ora si pu estendere il sistema dei tipi predefiniti con le proprie classi, e la questione richiede pi considerazione. UML usa il concetto di tipo di dato (data type), indicato sulla classe con unapposita parola chiave. Formalmente un tipo di dato non la stessa cosa di un oggetto valore, perch non ha identit. Gli oggetti valore invece sono dotati di identit, anche se non la usano per fare i test di uguaglianza. Un tipo valore si pu indicare anche con una parola chiave tra quelle usate comunemente, le pi diffuse sono forse value e struct. Associazioni qualificate Unassociazione qualificata lequivalente UML del concetto noto dei linguaggi di programmazione come array associativo, tabella di hash, mappa o dizionario. La figura mostra come si pu usare un qualificatore per rappresentare lassociazione tra classi Ordine e Linea dOrdine. Il qualificatore indica che per ogni istanza di Prodotto ci pu essere una sola Linea dOrdine collegata a un Ordine.

Figura 19: dipendenza in UML 1 I lecca-lecca sono utili anche su altri diagrammi, non solo quelli delle classi (ad esempio sono usati nei diagrammi di interazione per risolvere i problemi nel rappresentare il comportamento polimorfico). Read Only e Frozen La parola chiave {readOnly} usata per marcare una propriet che pu essere solo letta e non modificata dagli oggetti client. Una parola chiave simile ma sottilmente differente {frozen}, definita in UML 1. Una propriet si dice frozen (letteralmente congelata) se non pu cambiare per tutta la durata della vita di un oggetto; spesso in questo caso si dice anche che immutabile. La parola {frozen} stata ufficialmente eliminata in UML 2 ma vista la sua utilit potrebbe essere reintegrata nello standard. Oltre a marcare propriet, si pu anche applicare la parola chiave a unintera classe per indicare che tutte le propriet di tutte le sue istanze sono congelate. Oggetti riferimento e oggetti valore Gli oggetti riferimento sono entit come un Cliente. In questo caso lidentit importante, perch normalmente si desidera che un solo oggetto software rappresenti il Cliente del mondo reale. Ogni altro oggetto che fa riferimento a un Cliente deve farlo usando un puntatore o, appunto, un riferimento; quindi tutti gli oggetti che puntano a questo Cliente si riferiscono allo stesso oggetto software. In questo modo, ogni cambiamento apportato al Cliente si rifletter su tutti gli utenti che lo utilizzano. Se ci sono due diversi riferimenti a un oggetto Cliente e si vuole controllare se corrispondono allo stesso oggetto, solitamente si confronta la loro identit. Gli oggetti valore sono cose come una Data. Spesso ci sono multipli oggetti valore che rappresentano lo stesso oggetto del mondo reale: ad esempio, normale che ci siano centinaia di copie delloggetto che rappresenta l1 Gennaio 2005. Tutte queste sono intercambiabili, e nuove date vengono frequentemente create e distrutte. Gli oggetti valore dovrebbero essere immutabili, nel senso che se dovessimo cambiare il valore di un oggetto sarebbe opportuno crearne uno nuovo con tale valore e collegarlo alloggetto

Figura 20: Associazione qualificata. Spesso facile confondersi sulla molteplicit di unassociazione qualificata, infatti da considerare unicamente nel contesto del qualificatore. Nella modellazione concettuale si usa il costrutto del qualificatore solamente per rappresentare vincoli del tipo una sola Linea dOrdine per prodotto in un Ordine. Classificazione multipla e dinamica Il termine classificazione si riferisce alla relazione tra un oggetto e il suo tipo. I linguaggi di programmazione pi diffusi presumono che un oggetto possa appartenere a una sola classe, ma il discorso non si esaurisce qui. Con la classificazione singola un oggetto appartiene a un solo tipo, che pu eventualmente ereditare dai suoi tipi padre. Con la classificazione multipla un oggetto pu essere descritto da pi tipi, non necessariamente collegati dallereditariet. Si noti che la classificazione multipla una cosa ben diversa dallereditariet multipla. Questa afferma che un tipo pu avere pi supertipi, ma ogni oggetto deve sempre appartenere a un suo tipo ben definito. La classificazione multipla permette invece che un oggetto venga associato a pi tipi senza che per questo debba esserne appositamente definito un altro. Ad esempio, se consideriamo una classe Persona con sottotipi a seconda che sia uomo o donna, dottore o infermiere, paziente o no (vedi figura). La classificazione multipla permette di associare a tale oggetto una qualsiasi combinazione lecita dei suoi sottotipi, senza bisogno di definire appositamente un nuovo tipo per ognuna delle combinazioni.

Figura 23: Promuovere una classe di associazione in una classe vera e propria. Luso delle classi di associazione richiede di ricordare un formalismo supplementare: qual il vantaggio che controbilancia questaumento di complessit? Il fatto che la classe di associazione aggiunge implicitamente un vincolo extra; infatti ci pu essere solo unistanza della classe di associazione tra ogni coppia di oggetti associati. Classi parametriche (template) Il concetto di classe parametrica utile soprattutto per lavorare con le collezioni allinterno di linguaggi fortemente tipizzati. Ad esempio si pu definire il comportamento di un insieme generico definendo il template di classe Set (insieme) come si pu vedere dalla figura 24.

Figura 21: Classificazione multipla. Se si usa la classificazione multipla, ci si deve assicurare di rendere chiare le combinazioni legali. Per questo fatto, UML 2 pone ogni relazione di generalizzazione in un insieme di generalizzazione. Sul diagramma delle classi, la freccia che indica una generalizzazione va etichettata con il nome del rispettivo insieme, che in UML 1 era chiamato discriminante. La classificazione singola corrisponde alluso di un singolo anonimo insieme di generalizzazione. Gli insiemi di generalizzazione sono disgiunti per definizione: ogni istanza del supertipo pu essere istanza di uno dei sottotipi allinterno di quel sottoinsieme. Unaltra questione riguarda la possibilit che un oggetto cambi classe: ad esempio, quando un conto bancario va in rosso, il suo comportamento muta drasticamente. In particolare, vengono ridefinite alcune operazioni (tra cui preleva e chiudi). La classificazione dinamica permette agli oggetti di cambiare classe allinterno della struttura di tipi, cosa che la classificazione statica non consente. Usando la classificazione statica, i concetti di stato e di tipo vengono nettamente separati; la classificazione dinamica invece li combina. Classi di associazione Le classi di associazione permettono di aggiungere attributi, operazioni e altre caratteristiche alle associazioni, come indicato nella figura.

Figura 24: Un template di classe. Fatto questo si pu usare la definizione generale per creare classi che rappresentano insiemi di elementi specifici. Nel diagramma, la T serve da segnaposto per il parametro che indica il tipo (ce ne pu essere pi duno). Un uso particolare della classe parametrica, Set<Dipendente>, prende il nome di derivazione. come

Ci sono due modi di indicare una derivazione (vedi figure): il primo riprende la sintassi del C++ e il secondo esplicita il collegamento template.

Figura 22: Classe di Associazione. Dal diagramma si pu vedere che una Persona pu partecipare a pi riunioni. Potremo desiderare di tener conto del suo livello di attenzione; per far questo possiamo aggiungere allassociazione lattributo partecipazione. La prossima figura mostra un altro modo di rappresentare questinformazione: esprimere la Presenza a una riunione con una classe autonoma. Notate come si sono spostate le molteplicit.

Figura 25: Derivazione (versione 1).

Figura 26: Derivazione (versione 2).

Enumerazioni Le enumerazioni sono usate per mostrare un insieme di valori prefissati che non hanno altre propriet oltre al loro valore simbolico (vedi figura). Sono rappresentate con una classe marcata dalla parola chiave enumeration.

Figura 27: Una Enumerazione. Classi attive Ogni istanza di una classe attiva esegue e controlla il proprio thread. Le invocazioni dei metodi possono essere eseguite nel thread del client o in quello delloggetto attivo. Un buon esempio potrebbe essere un processore di comandi, che prende dallesterno degli oggetti comando e li esegue allinterno del proprio thread di controllo.

Figura 29: Notazione del diagramma dei componenti UML 2 ha rimosso tale icona, che per la si pu ancora usare allinterno di un box di classe per contraddistinguerlo. In alternativa, anche possibile usare la parola chiave component. Oltre alla suddetta icona, i componenti non introducono elementi nuovi: i loro collegamenti sono basati sulle interfacce implementate e richieste, per le quali si pu usare la solita notazione ball-and-socket proprio come si fa nei diagrammi delle classi. Per mostrare la composizione interna di un componente si pu usare un diagramma di struttura composita, che verr discusso in seguito.

Figura 28: Una classe attiva. La notazione delle classi attive cambiata passando da UML 1 a UML 2, come si pu vedere in figura. In UML 2, una classe attiva contraddistinta da righe verticali aggiuntive sui due lati; in UML 1 aveva un bordo pi spesso e veniva chiamata oggetto attivo. Visibilit La visibilit uno di quei concetti semplici in teoria, ma dalle implicazioni complesse. Gli elementi pubblici possono essere usati da unaltra classe, quelli privati invece sono riservati solo alluso interno della loro classe. In pratica, ogni linguaggio definisce le proprie regole di visibilit. Bench linguaggi differenti usino termini come public, private e protected, queste parole possono generare molta confusione, soprattutto per chi utilizza pi linguaggi. UML cerca di risolvere questo problema senza impantanarsi troppo. Essenzialmente, possibile etichettare ogni operazione o attributo con un identificatore di visibilit; si pu usare qualsiasi tipo di indicazione , e il significato preciso dipende dal linguaggio adottato. UML stesso fornisce comunque quattro abbreviazioni per indicare la visibilit: + (public), - (private), (package), # (protected). Questi quattro livelli sono definiti e usati allinterno del meta-modello di UML, ma le loro definizioni presentano piccole variazioni rispetto ai linguaggi di programmazione pi diffusi. Figura 30: Esempio diagramma componenti La figura 30 presenta un esempio di diagramma dei componenti. Come si vede, un agente di vendita (till) si pu collegare a un componente server usando uninterfaccia dedicata appunto ai messaggi di vendita. Dato che la rete inaffidabile, previsto anche un componente che implementa una coda di messaggi (message queue). In questo modo lagente pu parlare direttamente con il server quando la rete funziona, e con la coda in caso contrario: questultima si occuper poi di contattare il server quando la rete torner a essere disponibile. Di conseguenza, la coda di messaggi fornisce linterfaccia sales message per parlare con lagente e contemporaneamente la richiede per comunicare con il server. Questultimo suddiviso in due componenti principali: il transaction processor implementa linterfaccia dei messaggi di vendita, mentre un driver comunica con il sistema di contabilit. I componenti rappresentano pezzi di software che possono essere acquisiti e aggiornati in modo indipendente. Bisogna usare questi diagrammi quando si sta suddividendo il sistema in componenti e si vuole documentare le loro relazioni attraverso le interfacce, o quando si vuole mostrare la struttura interna dei singoli componenti a un livello di astrazione pi basso.

3.2 Diagramma dei componenti:

Mostra i componenti di un sistema e le loro connessioni. UML 1 prevedeva luso di un simbolo speciale per i componenti, mostrato nella figura 29.

3.3 Diagramma di struttura composita

una nuova caratteristica di UML2, stato introdotto per scomporre gerarchicamente una classe, mostrandone la struttura

interna. Questo permette al progettista di prendere un oggetto complesso e spezzarlo in parti pi piccole e semplici. La figura sottostante presenta una scomposizione interna di una classe in due parti, indicando anche quale delle due supporta e richiede ogni interfaccia. Il nome di ognuna delle parti ha la forma nome: classe. I due elementi che compongono il nome sono opzionali, ma non possono mancare entrambi. Le parti non sono istanze, per cui vanno scritte in grassetto e non sottolineate. anche possibile indicare il numero delle istanze delle parti, la figura dice che ogni TV Viewer ha un Generatore e una parte che si occupa dei controlli. Per mostrare che una parte implementa o richiede uninterfaccia si disegna tra di esse un connettore di delega. Anche le parti sono collegate tra di loro da connettori, e per questo si pu usare una semplice linea o la notazione socket e pallina.

sua posizione nel sistema durante lesecuzione. Per rappresentare gli elaborati si pu aggiungere unicona o la parola chiave artifact. anche possibile associare dei valori di etichetta ai nodi o agli elaborati per trasmettere informazioni aggiuntive di particolare interesse, come la marca, il sistema operativo, la posizione fisica o qualsiasi altra cosa da documentare. Spesso gli elaborati rappresentano limplementazione di un componente, se questo il caso e lo si vuole documentare si pu ancora una volta usare un valore di etichetta nel box dellelaborato. I path di comunicazione tra i nodi rappresentano il flusso delle comunicazioni. La figura mostra un esempio di diagramma di deployment.

Figura 32: Esempio diagramma di deployment Sono molto utili per mostrare la distribuzione fisica dei nodi, e se ne pu giovare qualsiasi sistema la cui messa in opera non sia estremamente semplice.

Figura 31: Esempio struttura composita Per capire bene la differenza tra i package e le strutture composite bisogna pensare che i primi rappresentano un raggruppamento al momento della compilazione, mentre le seconde fanno riferimento a quello che succede durante lesecuzione. Di conseguenza sono adatte a rappresentare i componenti e le loro parti, e sono usate spesso nei diagrammi dei componenti.

3.5 Diagramma degli oggetti

Il diagramma degli oggetti stato aggiunto in UML 2, in UML 1.X esisteva per non era ufficiale. Mostra una configurazione di istanze di classi e dei loro collegamenti in un certo istante di tempo. Si possono usare per rappresentare una configurazione esemplificativa di oggetti. La figura 33 mostra un insieme di oggetti che sono istanze di certe classi; i nomi degli oggetti sono sottolineati per distinguerli dai nomi delle classi, ogni nome ha la forma istanza: nome della classe. possibile, come si vede dalla figura, indicare i valori degli attributi e dei collegamenti fra gli oggetti.

3.4 Diagramma di deployment

I diagrammi di deployment documentano la distribuzione fisica di un sistema, mostrando i vari pezzi di software in esecuzione sulle macchine fisiche. Gli elementi principali del diagramma si chiamano nodi e sono collegati da path di comunicazione. Un nodo qualsiasi cosa possa mandare in esecuzione del software, e pu appartenere a due categorie: un dispositivo sempre hardware, e pu essere un computer completo o un componente hardware pi semplice collegato al sistema; o un ambiente di esecuzione che invece un pezzo di software che pu contenere ed eseguire altro software (tipo un sistema operativo). I nodi contengono elaborati (artifact), manifestazioni fisiche del software: tipicamente si tratta di file. Questi file possono essere eseguibili o anche file di dati, di configurazione, documenti HTML e cos via. Disegnare un elaborato allinterno di un nodo indica la

scritte tra parentesi quadre. Ogni volta che si raggiunge una decisione si deve intraprendere solo uno dei flussi uscenti, il che significa che le guardie devono essere tutte mutuamente esclusive. Si pu anche scrivere [else] come guardia, indicando cos il cammino da intraprendere quando nessuna delle altre guardie verificata. Un merge ha pi flussi in input e un solo output, e segnala la fine del comportamento condizionale iniziato con una decisione.

Figura 33: Esempio diagramma degli oggetti

3.6 Diagrammi dei package

Un package un costrutto che permette di prendere un numero arbitrario di elementi UML e raggrupparli insieme in unit di livello pi alto. In genere i package si usano per riunire classi, ma possono includere qualsiasi costrutto UML. Ogni package rappresenta un namespace, il che significa che ogni classe deve avere un nome distinto allinterno del package che la racchiude. Per indicare i nomi dei package UML usa un doppio segno di due punti (System::Data). Nei diagrammi i package si rappresentano con un box dotato di linguetta in alto a sinistra, come si vede in figura. Questi diagrammi esistevano gi in UML 1 ma non in modo ufficiale.

Figura 34: Notazione per i package

3.7 Diagramma delle attivit

I diagrammi delle attivit servono a descrivere logica procedurale, processi di business e workflow. Sono simili ai diagrammi di flusso, con la differenza che supportano la rappresentazione di elaborazione parallela. Esistevano gi in UML 1, ma sono cambiati molto nelle specifiche UML 2. Consideriamo lesempio in figura: lesecuzione comincia in corrispondenza del nodo iniziale, a cui fa seguito lazione receive order. Una volta che questa azione terminata si incontra un fork. Un fork ha un solo flusso di ingresso e pi flussi di uscita, che vengono eseguiti in modo concorrente. Il diagramma delle attivit permette al responsabile del processo di scegliere lordine di esecuzione delle azioni. In altre parole il diagramma si limita a specificare le regole essenziali di ordinamento, quelle che non possono essere violate. Il join usato per sincronizzare le varie azioni: il flusso di uscita pu essere seguito solo quando tutti i flussi in entrata hanno terminato lesecuzione. UML 1 prevedeva regole speciali di bilanciamento tra fork e join, perch i diagrammi di attivit erano un caso speciale dei diagrammi di stato; in UML 2 tutto ci non pi necessario. Il comportamento condizionale rappresentato da decisioni e giunzioni (merge). Una decisione ha un singolo flusso in ingresso e pi flussi in uscita; questi ultimi sono contraddistinti da guardie, ovvero da condizioni booleane Figura 35: Esempio diagramma attivit Partizioni: se si vuole indicare sul diagramma chi fa cosa, si pu dividerlo in partizioni, che mostrano le azioni intraprese da una singola organizzazione o classe. Nellesempio in figura 35 il diagramma ha un punto dinizio ben definito, che corrisponde allinvocazione di un programma o di una procedura. Le azioni possono rispondere anche a segnali diversi. Un segnale temporale si verifica al passaggio del tempo. Questi segnali possono indicare il passare di un mese allinterno di un periodo finanziario o di un microsecondo in un controllore elettronico in tempo reale. I segnali di accettazione corrispondono ad un evento proveniente da un processo esterno: questo significa che lattivit sempre in ascolto, ed il diagramma definisce la sua reazione al verificarsi degli eventi di interesse. Oltre ad accettare segnali esterni si possono anche generarli (send signal); questo

utile nei casi in cui dobbiamo inviare un messaggio e poi attendere la risposta prima di continuare.

Figura 36: Notazione grafica per i segnali

3.8 Diagramma dei casi duso

Mostra come gli utenti interagiscono con il sistema. Il diagramma raffigura gli attori, i casi duso e le loro relazioni. UML prevede anche altre relazioni tra i casi duso oltre alla semplice inclusione, come ad esempio lestensione, indicata dalla parola chiave extend. Non analizzeremo ulteriormente questo diagramma perch era gi presente in UML 1.x e non stato effettuato nessun cambiamento. I casi duso sono un documento prezioso per comprendere i requisiti funzionali di un sistema.

Figura 37: Elementi principali di una macchina a stati Oltre a questi elementi ci possono essere dei stati che rispondono agli eventi senza bisogno di seguire una transizione, usando attivit interne: per far questo si indicano levento, la guardia e lattivit allinterno dello stesso box dello stato. Unattivit interna simile a unauto-transizione: spesso chiamata anche auto-anello, questa una transizione che esce da uno stato e vi rientra. anche possibile definire stati in cui loggetto svolge una determinata attivit in modo continuato. Lattivit indicata con la dicitura /do (do-activity); questi stati prendono il nome di stati di attivit. La differenza tra attivit regolari e do-activity sta nel fatto che le prime avvengono istantaneamente e non sono influenzate dai normali eventi, mentre le do-activity prendono un tempo finito ed inoltre possono essere interrotte. Uml 1 usava il termine azione per le attivit normali, riservando la parola attivit solo per le doactivity. Nel caso in cui pi stati condividono alcune transizioni e attivit interne, possibile trasformarli in sottostati e raccoglierne il comportamento comune in un superstato, come mostrato in figura 38.

3.9 Diagramma delle macchine a stati

I diagrammi delle macchina a stati sono una tecnica molto nota per descrivere il comportamento di un sistema. Negli approcci objectoriented, ogni diagramma associato a una classe e mostra il comportamento di un singolo oggetto per tutta la durata del suo ciclo di vita. Il diagramma, come si vede dalla figura 37, inizia dallo stato in cui si trova il controllore al momento della creazione; per indicarlo si usa un simbolo chiamato pseudostato iniziale, che non un vero stato ma una freccia che punta allo stato iniziale. Il passaggio da uno stato ad un altro viene rappresentato come transazioni, ovvero linee che collegano gli stati. Ogni transazione contrassegnata da unetichetta divisa in tre parti: trigger/[guardia]/attivit, tutte opzionali. Il trigger normalmente un singolo evento che scatena un potenziale cambiamento di stato. La guardia una condizione booleana che deve essere verificata affinch la transizione abbia luogo. Lattivit unazione eseguita durante la transizione ed costituita da una qualsiasi espressione che rappresenti un determinato comportamento. Quando il sistema si trova in uno stato e avviene un evento, si pu verificare una sola transizione uscente da quello stato; di conseguenza, quando ci sono pi transizioni etichettate con lo stesso evento, le guardie devono essere mutuamente esclusive. Lo stato finale indica il completamento dellesecuzione della macchina a stati e quindi la cancellazione delloggetto software responsabile del suo controllo.

Figura 38: Esempio di superstato Gli stati possono essere suddivisi in pi diagrammi ortogonali in esecuzione concorrente (stati concorrenti). La separazione delle due aree di comportamento (come mostrato in figura 39) in diagrammi di stato separati rende tutto pi semplice e chiaro. La figura include anche uno pseudostato di storia, che memorizza lo stato del sistema al momento dello spegnimento, in modo da poter ripristinare il corretto stato alla prossima accensione.

Figura 39: Stato concorrente I diagrammi delle macchine a stati sono molto utili nel descrivere il comportamento di un oggetto in pi casi duso, mentre non funzionano bene quando bisogna rappresentare la collaborazione tra pi oggetti. Di conseguenza conviene combinarli con altre tecniche (es. diagrammi di interazione) per descrivere il comportamento di molti oggetti in un singolo caso duso. Figura 40: Esempio diagramma di sequenza Una novit introdotta da UML 2 sono i frame di interazione, sono una sorta di cornici che servono ad inquadrare ed evidenziare una parte del diagramma, esprimendo condizioni e cicli. Ogni frame ha un operatore, e ogni frammento pu avere una guardia; gli operatori che possono essere utilizzati nei frame sono elencati in tabella 2.

3.10 Diagrammi di sequenza

Documenta tipicamente il comportamento di un singolo scenario. Il diagramma include un certo numero di oggetti e di messaggi scambiati tra essi durante lesecuzione del caso duso. I partecipanti in UML 2 vanno indicati senza sottolineatura, a differenza di UML 1. Come si vede nellesempio in figura 40, ogni linea di vita ha una barra di attivazione che indica quando il partecipante attivo nellinterazione: si pu pensare che questo corrisponda alla presenza di uno dei suoi metodi sulla pila del processo. Il primo messaggio non scaturisce da un partecipante al diagramma, ma proviene da una fonte esterna indeterminata: per questo chiamato messaggio trovato. I diagrammi di sequenza prevedono una notazione particolare per indicare la creazione e distruzione dei partecipanti. Per la creazione si disegna la freccia del messaggio in modo che punti direttamente al box delloggetto creato. Il nome del messaggio opzionale se si usa il costruttore, ma di solito si indica new. La distruzione di un partecipante indicata da una grossa X, se la freccia di un messaggio termina nella X, significa che un partecipante ne sta cancellando un altro; una X posta da sola alla fine della linea di vita significa che il partecipante sta distruggendo se stesso.

Figura 41: Utilizzo dei frame

Tabella 2: Parole chiave di UML Operatore Alt opt par loop region neg ref Significato Frammenti multipli in alternativa, verr eseguito solo quello per cui verificata la condizione Opzionale, il frammento viene eseguito solo se la condizione specificata verificata Parallelo; ogni frammento viene eseguito in parallelo Ciclo; il frammento pu esere eseguito pi volte, la base delliterazione indicata dalla guardia Regione critica, il frammento pu essere eseguito da un solo thread alla volta Negativo; il frammento mostra uninterazione non valida Riferimento; si riferisce a uninterazione definita in un altro diagramma. Il frame devessere disegnato in modo da racchiudere le linee di vita coinvolte nellinterazione Sequenze diagram; usato per racchiudere un intero diagramma di sequenza

Figura 42: Diagramma di comunicazione a controllo centralizzato (non legale per la specifica 2.0) Lo stile di numerazione dei messaggi della figura 42 semplice ed quello comunemente usato; ma in effetti non strettamente legale; per essere del tutto aderenti alla specifica UML, si dovrebbe usare un sistema di numerazione decimale nidificato, come si vede dalla figura 43. Lo scopo di questa tecnica sta nel risolvere lambiguit nella sequenza delle chiamate in presenza di auto-collegamenti di un oggetto a se stessi.

sd

In UML 2 stata cambiata la distinzione tra messaggi sincroni ed asincroni, i primi vengono indicati con frecce piene, mentre i secondi da frecce composte da due segmenti sottili. I diagrammi di sequenza eccellono nel mostrare le collaborazioni tra gli oggetti, ma non sono altrettanto precisi quando si tratta di definire il loro comportamento.

3.11 Diagrammi di comunicazione

I diagrammi di comunicazione sono un tipo speciale di diagramma di interazione che enfatizza lo scambio di dati tra i partecipanti. Invece di indicare ogni partecipante con la sua linea di vita e rappresentare lordine dei messaggi in base alla posizione lungo lasse verticale, come fa il diagramma di sequenza, quello di comunicazione permette di disegnare i partecipanti, in qualsiasi posizione aggiungendo collegamenti per mostrare le connessioni. La sequenza temporale di questultime espressa tramite la numerazione dei messaggi. In UML 1.x, questi erano chiamati diagrammi di collaborazione. Come si vede in figura 42, il diagramma permette di mostrare i collegamenti tra i partecipanti. Oltre a quelli che rappresentano associazioni, possibile includere nel diagramma anche collegamenti temporanei, che esistono solo per la durata dellinterazione. In questo caso, il collegamento local da Ordine a Prodotto una variabile locale, altri tipi di collegamenti temporanei sono parameter e global. Queste parole chiave erano previste in UML 1 ma nella nuova versione non lo sono pi.

Figura 43: Diagramma di comunicazione con numerazione decimale nidificata Oltre ai numeri, i messaggi possono essere etichettati anche con delle lettere: questo significa che appartengono a diversi thread di controllo. I messaggi A5 e B2, quindi, appartengono a thread diversi; i messaggi 1a1 e 1b1 corrispondono a thread differenti in esecuzione parallela allinterno del messaggio 1. Le lettere dei thread si possono usare anche sui diagrammi di sequenza, bench questi non presentino visivamente la concorrenza. I diagrammi di comunicazione non definiscono una notazione precisa per esprimere la logica di controllo. possibile usare indicatori di iterazione e guardie, ma da soli questi elementi non sono sufficienti a specificare completamente la logica. Manca anche una notazione speciale per la creazione/distruzione di oggetti, ma per questo si usano comunemente le parole chiave create delete.

3.12 Diagrammi di interazione generale

I diagrammi di interazione generale (interaction overview) sono una specie di fusione dei diagrammi di attivit e di quelli di sequenza introdotti in UML 2. Si possono considerare alla stregua dei diagrammi delle attivit in cui ogni azione rimpiazzata da un piccolo diagramma di sequenza, o come diagrammi di sequenza spezzati con la notazione delle attivit in modo da mostrare il flusso di controllo.

La figura 44 presenta un semplice esempio; in questo diagramma si vuole produrre e formattare il prospetto riassuntivo di un ordine. Se il cliente esterno, estraiamo le informazioni necessarie da un file XML; se interno basta accedere al database. Piccoli diagrammi di sequenza (racchiusi in un frame etichettato con loperatore sd) rappresentano le due alternative. Una volta che abbiamo estratto i dati si pu formattare il prospetto; in questo caso non mostriamo il diagramma di sequenza ma si fa semplicemente riferimento con un frame speciale (etichettato con loperatore ref).

Figura 45: Diagramma di temporizzazione (stati rappresentati come linee)

Figura 44:esempio diagramma di interazione generale.

Figura 46: Diagramma di temporizzazione (stati rappresentati come aree) La differenza principale che nella figura 45 i cambiamenti di stato sono indicati dal movimento di una linea orizzontale da un livello ad un altro, mentre nella figura 46 vengono rappresentati da una croce che interrompe la continuit di linee pi spesse.

3.13 Diagrammi di temporizzazione

I diagrammi di temporizzazione sono stati introdotti in UML 2. Sono unaltra forma di diagrammi di interazione, dedicata specificatamente allespressione di vincoli temporali: si possono applicare a un oggetto singolo o, in modo pi utile, a un intero gruppo di oggetti. Consideriamo il semplice esempio della pompa e della resistenza termica di una caffetteria automatica allamericana. Supponiamo che una regola stabilisca che devono passare almeno 10 secondi tra laccensione della pompa e quella della resistenza. Quando il serbatoio dellacqua si svuota, la pompa si spegne, e a partire da quel momento la resistenza non pu rimanere accesa per pi di 15 minuti. Le figure rappresentano modi alternativi di mostrare questi vincoli temporali, tutti e due validi in UML 2.

4. INTRODUZIONE A OCL
OCL (Object Constraint Language) un linguaggio che permette di descrivere espressioni e vincoli sui modelli orientati agli oggetti. Unespressione unindicazione o specificazione di valore; un vincolo una restrizione su uno o pi valori del modello o del sistema. OCL uno standard query language per lanalisi e il design orientato agli oggetti approvato dallObject Management Group (OMG).

4.1 Tipi di espressioni

Per specificare il valore iniziale di un attributo o di unassociazione Per specificare la regola di derivazione di un attributo o di unassociazione Per specificare il corpo di unoperazione

 Per indicare unistanza in un diagramma dinamico Per indicare una condizione in un diagramma dinamico Per indicare i valori attuali di parametri in un diagramma dinamico

context Customer inv: age >= 18

4.5 Le invarianti sulle associazioni

possibile vincolare anche gli oggetti associati: supponendo che esista unassociazione, salesrep con molteplicit 1, tra la classe Customer e una classe SalesPerson con attributo knowledgelevel, la seguente regola restringe il valore di questultimo elemento dellistanza associata della classe salesperson: context Customer inv: salesrep.knowledgelevel >= 5

4.2 Tipi di vincoli

Esistono 4 tipi di vincoli: 1. uninvariante rappresenta una condizione che deve essere sempre soddisfatta da ogni istanza di classe, tipo, o interfaccia. 2. una precondizione su unoperazione una condizione che deve essere verificata nellistante in cui la relativa operazione sta per essere eseguita. 3. una postcondizione deve invece essere verificata al termine dellesecuzione delloperazione a cui si riferisce. 4. una guardia un vincolo che deve essere soddisfatto prima di una transazione di stato.

4.6 Pre e post condizioni

Le pre e post condizioni intervengono sui parametri delloperazione. Il linguaggio prevede la parola-chiave result che denota il valore di ritorno delloperazione. Ovviamente utilizzabile solo nelle post-conditions. Ad esempio, aggiungendo loperazione sell alla classe SalesPerson: context SalesPerson::sell(item: Thing): Real pre: self. sellableItems ->includes(item) post: not self.sellableItems->includes( item ) and result = item.price

4.3 Il contesto di unespressione OCL

La definizione del contesto, attraverso unespressione ocl, specifica lentit del modello per cui lespressione ocl definita. Solitamente, il contesto una classe, uninterfaccia, un tipo di dato o un componente a cui UML associa il nome di Classificatore, mentre lentit del modello unoperazione o un attributo, raramente unistanza. OCL un linguaggio tipato, in modo da poter definire un tipo per ogni espressione. Di conseguenza, una regola OCL, per essere ben formata, deve rispettare i vincoli di tipo. (es. non possibile confrontare un intero con una stringa). Per esempio, il contextual type di tutte le espressioni in figura la classe LoyaltyAccount. La precondizione (pre: i>0) ha come contesto loperazione earn. Il contesto del valore iniziale (init: 0) lattributo points.

4.7 Regole di derivazione

I modelli spesso definiscono attributi e associazioni derivate. Il valore di un elemento derivato deve sempre essere determinato da un altro valore (base) nel modello. Usando OCL possibile esprimere la derivazione attraverso una regola di derivazione. Nellesempio seguente, il valore dellelemento derivato usedServices definito come insieme di tutti i servizi che hanno generato transazioni sullaccount: context LoyaltyAccount::usedServices : Set(Services) derive: transactions.service->asSet()

4.8 Valori iniziali

Nelle informazioni del modello, il valore iniziale di unassociazione o di un attributo pu essere specificato da un'espressione OCL. Nei seguenti esempi, il valore iniziale dellattributo points 0, e dellassociazione di fine transazione un insieme vuoto: context LoyaltyAccount::points : Integer init: 0 context LoyaltyAccount::transactions : Set(Transaction) init: Set{} Si noti la differenza fra un valore iniziale e una regola di derivazione. Una regola di derivazione dichiara uninvariante: l'elemento derivato deve sempre avere lo stesso valore che la regola esprime. Un valore iniziale deve essere rispettato soltanto nel momento in cui listanza contestuale viene generata; successivamente l'attributo pu assumere un valore differente in qualsiasi momento.

Figura 47: esempio di rappresentazione di vincoli OCL

4.4 Le invarianti sugli attributi

Il vincolo pi semplice uninvariante su un attributo. Supponendo un modello contenente una classe Customer, la regola seguente restringe il valore dellattributo age:

4.9 Corpo delle interrogazioni (query)

Le operazioni di query sono operazioni passive (senza side effects) in quanto non alterano lo stato del sistema, ma si limitano, una

volta eseguite, a produrre un valore o un insieme di valori che soddisfano linterrogazione. Una body expression ununica espressione con cui in OCL possibile specificare dove prelevare i valori richiesti: nellesempio seguente, loperazione di getCustomerName produrr come risultato il nome (name) del proprietario (owner) della scheda (card) associato al LoyaltyAccount: context LoyaltyAccount::getCustomerName() : String body: Membership.card.owner.name

Nellesempio, il corretto modo per rappresentare la restrizione aggiungere al diagramma la seguente espressione OCL: context Flight inv: passengers->size() <= plane.numberOfSeats Le espressioni scritte in un linguaggio preciso e matematico come OCL offrono un gran numero di benefici nelluso di diagrammi per la specifica di sistemi. Queste espressioni non possono essere interpretate in modi differenti da diverse persone (analista e programmatore). Essendo non ambigue possibile definire modelli pi precisi e pi dettagliati. Inoltre queste espressioni possono essere verificate da tool automatici in modo da garantire correttezza e consistenza con gli elementi del modello. Tutto quanto descritto sopra rende la generazione del codice pi precisa e potente. utile notare che allinverso, descrivere un modello facendo uso di un linguaggio costituito solamente da espressioni, genera documenti che non sono facilmente comprensibili. Combinando UML ed OCL si ottiene la migliore soluzione per lo sviluppo di software. Un considerevole numero di differenti diagrammi possono essere usati, insieme ad espressioni OCL, per specificare modelli completi. Senza le espressioni OCL, come gi detto, si ottengono rappresentazione imprecise; senza i diagrammi UML, le espressioni OCL si riferiscono ad elementi inesistenti nel modello, dato che non possibile in OCL specificare classi ed associazioni.

4.10 Vincoli rotti

Si noti che valutando un vincolo non cambiano valori nel sistema. Un vincolo dichiara questo dovrebbe essere cos. Se per un certo oggetto il vincolo non valido, in altre parole, rotto, allora lunica conclusione possibile che loggetto non corretto, non conforme alla specifica. OCL non offre la possibilit di specificare cosa necessario fare per correggere tale situazione.

4.11 Principali modifiche introdotte in OCL 2

OCL un completo object query language; permette di definire qualsiasi tipo di query sui modelli ad oggetti. I tipi standard usati in OCL sono definiti allinterno dellOCL standard library package. Usando OCL, ogni modello importa implicitamente questo package. OCL prevede la possibilit di rappresentare linvio di un segnale o di una chiamata di un operazione; questo permette di specificare side-effects. Cambiamenti strutturali: precisa definizione della semantica di ogni espressione del linguaggio.

4.12.1 Il vantaggio di usare OCL, UN ESEMPIO:

4.12 Perch usare OCL come supporto ad UML?

Gran parte dei modelli sono composti da figure accompagnate da testo; linformazione fornita da questi modelli tendenzialmente incompleta, informale, imprecisa e a volte anche inconsistente. Molti dei difetti nel modello sono causati dalle limitazioni dei diagrammi utilizzati. Per esempio, nel diagramma UML sotto riportato, unassociazione tra la classe Volo e la classe Persona, indica che un certo gruppo di persone sono passeggeri di un certo volo; ovviamente, nella rappresentazione, la molteplicit sulla classe persona varia da zero ad infinito. Questo significa che il numero di passeggeri illimitato. In realt, il numero di passeggeri deve essere vincolato al numero di posti disponibili sul volo. impossibile esprime questa restrizione nel diagramma.

Figura 49: diagramma delle classi con ambiguit Per rendere maggiormente valido lo schema di figura 49 necessario aggiungere alcune regole: Una persona pu ottenere unipoteca su una casa solo se ne il proprietario La data di inizio ipoteca deve essere inferiore a quella di fine ipoteca Lidentificativo di ogni persona deve essere univoco (social security number) Una nuova ipoteca pu essere concessa solo quando il reddito del richiedente sufficiente

Figura 48: diagramma delle classi incompleto

Una nuova ipoteca pu essere concessa solo quando il valore di cassa della casa sufficiente

Sul diagramma non sono visibili queste informazioni, e non esistono possibili rappresentazioni che le possano esprimere utilizzando solo i diagrammi. Esprimere tali vincoli in un linguaggio ordinario (come sopra) non ancora sufficiente per eliminare ogni tipo di ambiguit e non chiarezza. Aggiungendo invece al modello alcune espressioni OCL possibile renderlo perfettamente leggibile ed interpretabile senza rischio derrore: context Mortgage inv: security.owner = borrower context Mortgage inv: startDate < endDate context Person inv: Person::allInstances()->isUnique(socSecNr) context Person::getMortgage(sum : Money, security : House) pre: self.mortgages.monthlyPayment->sum() <= self.salary * 0.30 context Person::getMortgage(sum : Money, security : House) pre: security.value >= security.mortgages.principal->sum() OCL assume ancora maggiore importanza quando il modello diviene un input per un sistema automatizzato. Esistono vari tool in grado di generare simulazioni, codice, test, traduzioni di modelli in altri linguaggi usando le trasformazioni Model Driven Architecture (MDA). Lautomazione di questi compiti possibile solo se il modello contiene tutte le informazioni necessarie; un tool computerizzato non pu interpretare regole in lingua italiana. I vincoli espressi mediante OCL includono tutte le informazioni necessarie per i tool MDA automatizzati. Questa modalit di implementazione pi veloce ed efficiente e garantisce maggiore consistenza tra UML ed OCL.

Per assicurare lo scambio tra i tool che non possiedono una notazione di modello di elementi, ma una di linee, testo e grafici, esiste un meccanismo di trasformazione da XMI a SVG. SVG un formato XML-based per vettori grafici adottato come una W3C Recommendation. Questo standard in grado di esprimere tutti i diagrammi dellUML, un formato di uso comune per una vasta variet di tool (grafici, desktop ) ed stato creato per adattarsi al web.

5.1 Processo di creazione

Nella figura 50 viene mostrata la panoramica di tutte le tecnologie impiegate nel processo di creazione del metamodello e del DTD.

Figura 50: processo di creazione del DTD Con un tool di modellazione viene creato un modello XMI[UML] attraverso le regole di produzione dellXMI; successivamente il tool procede nella traduzione del modello appena creato utilizzando le regole del profilo UML per MOF, si ottiene quindi il metamodello XMI[MOF]. Infine le regole di creazione DTD possono essere applicate alla precedente rappresentazione MOF ottenendo cos il documento DTD.

5. XMI
Lidea che sta alla base di questo meccanismo, rendere facile e trasparente la conversione di documenti, in accordo con lo standard UML, tra differenti software tool. Un meccanismo per lo scambio di modelli UML era gi stato specificato in UML 1.x usando XMI (XML Metadata Interchange), esso per non permetteva appieno di effettuare delle trasposizioni complete di modelli. Infatti era possibile solamente il trasporto delle informazioni riguardanti quali elementi fossero contenuti nel modello UML e non i dati relativi al modo in cui gli elementi fossero rappresentati nel diagramma. Questa limitazione non era dovuta da XMI in s, ma dal fatto che il metamodello di UML non definiva un metodo standard per rappresentare la definizione dei diagrammi. Il problema stato risolto con la definizione del nuovo metamodello di UML 2.0: un metamodello MOF-compatibile per le informazioni del diagramma fornito come estensione del metamodello UML, permettendo luso del DTD per XMI. LXMI risultante pu essere utilizzato per la conversione di modelli tra i vari tool, senza perdita di informazioni. Questultimo infatti definisce come creare un DTD o uno schema da un metamodello MOF e come questo pu essere applicato ad XMI.

6. TOOL
In conclusione, analizzeremo tre tool di supporto ad UML 2.0, evidenziandone le caratteristiche e le compatibilit con le nuove specifiche.

6.1 Poseidon
Poseidon un tool sviluppato, da Gentleware, interamente in Java, e tale caratteristica lo rende indipendente dalla piattaforma software e hardware su cui installato. Le caratteristiche fondamentali di questo tool sono: Diagrammi di stato conformi UML 2 Supporto per XMI come formato file standard Abilit di esportare diagrammi come GIF, PS, EPS, e SVG UMLdoc personalizzabile per HTML auto-layout dei diagrammi di reverse engineering copia/incolla/taglia di diagrammi e di elementi del modello semantico

Per quanto riguarda i diagrammi, Poseidon supporta UML 2, ma non include i diagrammi di Struttura Composita e di Temporizzazione citati nella sezione 3. Altri diagrammi sono derivabili da altri: I diagrammi di Comunicazione corrispondono ai diagrammi di collaborazione I diagrammi di Interazione Generale corrispondono ai diagrammi delle attivit I diagrammi di package sono automaticamente generati

Poseidon fornisce la possibilit di importare file java nel programma per il reverse engineering. Questo strumento presente in pi versioni: Community: per studenti, principianti e altri utilizzatori non commerciali. Edizione libera. Standard: Mirato agli analisti, quest'edizione rende il lavoro di design e documentazione dei modelli veloce e facile grazie a Java reverse engineering, UMLdoc, e i vari plug-in. Professional: gli Sviluppatori troveranno una suite piena di caratteristiche potenti come l'integrazione con Eclipse, Java roundtrip engineering, e la generazione di codice per molti altri linguaggi. Enterprise: le Squadre di sviluppatori possono usare le funzioni di collaborazione real-time ed il versioning che permettono con l'ingegneria di roundtrip di Java di sviluppare indipendentemente il software in una stanza o attraverso il globo. Embebbed Enterprise: gli sviluppatori di sistemi embedded possono usare le capacit di squadra dell' Enterprise Edition per la generazione di codice c e c++ specifico per tali sistemi.

Figura 51: ScreenShot di Poseidon Altre funzionalit grafiche sono quelle che compaiono al passaggio del mouse, in figura 52 si possono vedere le varie funzioni offerte per una classe.

Linterfaccia grafica di Poseidon comprende 4 finestre (o pannelli) che mostrano differenti aspetti del modello (vedi figura 51). Sono descritti come segue: 1. DiagrammiMostra una zona editabile associata agli elementi scelti nella finestra di navigazione - per esempio, un diagramma delle classi di uno specifico package Centric (navigazione)Mostra tutte le parti di un modello come package organizzati in strutture ad albero gerarchico DettagliMostra pannelli editabili in cui inserire le caratteristiche scelte (ad esempio, dettagli circa gli Stili, Javadoc, vincoli OCL, linguaggio di programmazione scelto, ecc.). BirdviewControlla continuamente se il modello ben formato secondo le regole generali di progetto del software (e se non lo , genera descrizioni sul da farsi nella finestra Dettagli)

Figura 52: Dettaglio Poseidon La versione corrente 3.1 stata realizzata e rilasciata dopo accurate fasi di test e valutazione da parte degli utenti. Sono stati risolti bug del software. Aggiunta di funzionalit. Aggiunte al Roundtrip. Risolti i problemi con Eclipse (con la versione 3.1 possibile lanciare Poseidon direttamente da Eclipse).

2.

3.

4.

6.2 Enterprise Architect 5

Enterprise Architect 5 un tool prodotto da Sparx System, la verisone 5 include il supporto completo a tutti e 13 i diagrammi dello standard UML 2.0. Le altre caratteristiche del software possono essere riassunte in questo elenco: - interfaccia utente intuitiva: o possibilit di navigazione a schede

Le quattro finestre si possono nascondere fino a visualizzarne 1 sola (utile nel caso lattenzione sia da portare a solo un aspetto dei 4)

o personalizzazione dei menu e delle toolbars - supporto alla trasformazione MDA o supporto allMDA per trasformare elementi semplici di un modello in obiettivi complessi o facilit di scrittura e modifica dei modelli o trasformazioni integrate per DDL, java, C#, EJB, XSD - Documentazione completa e flessibile o Generatore documentazione RTF guidato o Output flessibile con filtri e criteri di selezione - Forward e reverse code engineering o Supporto per C++, Java, C#, VB.Net, Visual Basic, Delphi, PHP - Modellazione di Database - Supporto allXML schema - Reverse engineer binary files da java e .NET o Supporto per importare file JAR e .NET assemblies - Supporto per il testing - Supporto per il project management - Interfaccia per lo scripting EA per scrivere plugin complessi - Plugin per integrare EA con .NET o Eclipse: o Stretta integrazione tra EA e lo strumento di sviluppo o Forward and Reverse Code Engineering o Navigazione semplice ed efficiente tra codice e modello o Build and run projects direttamente da Enterprise Architect o Possibilit di modifica del codice da EA o Opzioni per selezionare quali nellimportazione/esportazione. classi includere Figura 53: ScreenShot Enterprise Architect 5 In commercio esistono 3 diverse versioni di Enterprise Architect: - Corporate Edition: mirata a grandi team di sviluppo; supporta tutte le caratteristiche delle altre due versioni ed in pi la possibilit di connettersi a SQL Server, MySQL, Oracle9i, PostgreSQL, MSDE, Adaptive Server come repository condiviso. Supporta funzioni avanzate di sicurezza per gli utenti e di login. - Professional Edition: adatta a gruppi di lavoro e sviluppatori medio/piccoli. Supporta progetti condivisi con replicazione e file condivisi su rete. Questa versione ha anche un interfaccia ActiveX per interrogare i progetti Ea ed estrarre informazioni in formato XMI. Ha il completo supporto per il codice e per limportazione/esportazione di schemi di DB, ha la possibilit di sincronizzazione del modello con il codice sorgente.

La figura 53 mostra uno screenshot del tool ed evidenza in modo particolare la possibilit di utilizzare strumenti avanzati per lintegrazione del codice con il modello.

- Desktop Edition: questa versione adatta ad un singolo sviluppatore che produce analisi UML e design model. Include tutte le funzioni della versione professional escluso il code engeneering (importazione/esportazione di codice sorgente), linterfaccia ActiveX e la possibilit di condividere un modello tra molti utenti. - disponibile anche una versione di prova scaricabile dal sito http://www.sparxsystems.com.au/. 6.3 Together Designer
Together designer un valido strumento che riunisce in s tutte le caratteristiche di analisi e modellazione necessarie per: eliminare le ambiguit nella definizione dei requisiti software. per generare in modo semplice il codice, rispettando i requisiti stabiliti. Il software offre inoltre la possibilit di estrarre informazioni di design da unapplicazione esistente al fine di garantire una comprensione, visiva e comune, del modello architetturale. CARATTERISTICHE E VANTAGGI:

 Soluzioni di modellazione per analisti e sviluppatori Il software stato creato per soddisfare le esigenze modellanti specifiche di analisti e sviluppatori, permettendo loro di collaborare efficacemente per sviluppare applicazioni di alta qualit in meno tempo. Per un team di sviluppo, lavorare a nuove o gi esistenti applicazioni, migliorando la comunicazione circa il disegno ed il codice, riduce significativamente il rischio di guasto di progetto. Modellazione piattaforma indipendente Together offre una flessibilit tale da poter creare design di progetti indipendentemente dalla piattaforma utilizzata. Il supporto per un vasto numero di linguaggi di programmazione disponibile attraverso lintegrazione di ambienti IDE che permette agli sviluppatori di traformare il design creato in un modello di una specifica piattaforma. Supporto degli standard industriali Supporto allMDA per trasformare modelli generici in modelli complessi di specifiche piattaforme: o Unified Modeling Language (UML) o XML Metadata Interchange (XMI) o Object Constraint Language (OCL) Design patterns Fornisce lutilizzo degli standard patterns di design per creare applicazioni di alta qualit e promuovere la riutilizzazione dei modelli consolidati. Ci permette ai team di lavorare pi efficientemente riducendo la revisione del codice dovuta gli errori di design. Velocizzazione delle operazioni o Generazione automatica del documento o Riutilizzazione di modelli e di definizioni componenti o Propagazione veloce dei cambiamenti con refactoring o Tecnologia LiveSource che permette di mantenere i modelli ed il codice sempre sincronizzati TECNOLOGIE: Modellazione UML o Language-neutral UML 1.5 diagramming o Language-neutral UML 2.0 diagramming o UML modeling with LiveSource o Model differencing o Supporto Multilanguage Modellazione Avanzata o OCL o Refactoring attraverso model differencing o Profiles support (color modeling, business process, software development process) o Import ed export dei modelli

o Creazione di diagrammi personalizzati o Web Services, J2EE, visual XML modelling Generazione dei documenti o Creazione di portali HTML con: applet di navigazione, hyperlinked diagrams e Javadoc-style model/code report o Creazione di files da diagrammi, in formati multipli o Template per documentazioni personalizzate, layout dei diagrammi per la stampa Qualit ed efficienza o Design patterns, incluso il supporto Gang of Four pattern e pattern templates personalizzabili o Condivisione di diagrammi e modelli tra progetti con controllo di versione e funzionalit SCM o Supporto delle API VERSIONI: 1. Together Architect: soluzione per la modellazione multilinguaggio, adatta a software architects che progettano e sviluppano architetture informatiche lavorando in stretto contatto con gli stakeholders. 2. Together Designer: soluzione adatta ad analisti ed a coloro che lavorano in un ambiente in cui i modelli visuali possono ottimizzare la definizione dei requisiti di architetture e codice software. 3. Together Developer: soluzione adatta a sviluppatori di software per ridurre significativamente la complessit delle applicazioni attraverso luso, principalmente, di use-case e sequence diagrams. 4. Together Edition for Eclipse: soluzione sviluppata per lintegrazione dello standard UML in Eclipse; permette di progettare nuove applicazioni, o di estrarre informazioni da applicazioni esistenti. Sito di riferimento: http://www.borland.com/together

7. CONCLUSIONI
Questa versione di UML, interamente riscritta, ha lo scopo di esprimere in modo pi analitico e preciso l'insieme dei metodi in grado di rappresentare rigorosamente molti degli aspetti che si incontrano durante le fasi di analisi e specifica dei requisiti di un problema ed anche nel corso dello sviluppo vero e proprio di software. Essa offre appunto una vasta gamma di diagrammi che, unita all'utilizzo del linguaggio di specifica dei vincoli presentato, semplifica il lavoro che precede le fasi di sviluppo del progetto arrivando a produrre documenti di analisi estremamente chiari e non ambigui per tutti i componenti di un eventuale team. Anche se attualmente si decisamente lontani, l'obiettivo evolutivo di UML rimane la possibilit di divenire un linguaggio di programmazione a tutti gli effetti, che sia semplice e performante allo stesso tempo.

8. REFERENCES
1. 2. 3. 4. 5. 6. Martin Fowler, UML Distilled Third Edition. Addison Wesley. UML 2.0 Infrastructure Specification. OMG standard UML 2.0 Superstructure Specification. OMG standard UML 2.0 OCL Specification. OMG standard UML 2.0 Diagram Interchange Specification. OMG standard http://www.klasse.nl/english/uml/