Sei sulla pagina 1di 50

1

Sommario

Introduzione ...................................................................................................................................................... 3
Cenni storici ....................................................................................................................................................... 4
I vantaggi del UML ............................................................................................................................................. 5
Che cos’è il Visual Moding? ............................................................................................................................... 5
RAD – Rapid Application Development ............................................................................................................. 6
Raccolta delle informazioni ............................................................................................................................... 7
Analisi ................................................................................................................................................................ 7
Disegno .............................................................................................................................................................. 8
Sviluppo ............................................................................................................................................................. 9
Deployment ..................................................................................................................................................... 10
Gli strumenti di lavoro UML ............................................................................................................................ 10
Componenti UML ............................................................................................................................................ 11
Rappresentazione di una classe ...................................................................................................................... 12
Associazioni ..................................................................................................................................................... 14
Ereditarietà e Generalizzazione ....................................................................................................................... 15
Aggregazioni .................................................................................................................................................... 16
Interfacce e internalizzazioni ........................................................................................................................... 18
Visibilità ........................................................................................................................................................... 19
Class Diagrama – Esempio Pratico................................................................................................................... 20
Use Case Diagram ............................................................................................................................................ 23
Introduzione Use Case Model ......................................................................................................................... 24
Relazioni tra uses cases ................................................................................................................................... 25
Use Case Diagram ............................................................................................................................................ 26
State Diagram .................................................................................................................................................. 30
Dettagli di Stato e Transizioni .......................................................................................................................... 31
State Diagram - Esempio Pratico ..................................................................................................................... 31
Sequence Diagram ........................................................................................................................................... 33
I componenti del Sequence Diagram .............................................................................................................. 33
Modi di creare Sequenze ................................................................................................................................. 35
Collaboration Diagram..................................................................................................................................... 37
Scrivere Collaboration Diagram ....................................................................................................................... 38
Collaboration Diagram – Un esempio ............................................................................................................. 39
Activity Diagram .............................................................................................................................................. 40

2
Costruzione di un Activity Diagram ................................................................................................................. 41
Interfacce e Componenti: Approfondimento .................................................................................................. 43
Component Diagram ....................................................................................................................................... 44
Component Diagram: Un esempio .................................................................................................................. 45
Deployment Diagram....................................................................................................................................... 46
Deployment Diagram: Un esempio ................................................................................................................. 48
Simboli Grafici di UML ..................................................................................................................................... 50

Premessa
Questa guida ha come scopo primario quello di introdurre i concetti fondamentali del
linguaggio UML (Unified Modeling Language). Si rivolge a tutti coloro che desiderano
imparare a conoscere questo potente strumento di analisi e progettazione del software ormai
sempre piu’ diffuso ed utilizzato dalle aziende produttrici di software.

La guida ha come prerequisito una conoscenza di base dei concetti di analisi Object
Oriented. è sicuramente di aiuto, anche se non e’ un requisito indispensabile, avere una
buona esperienza pratica su un linguaggio di programmazione ad oggetti, come il C++ o
Java.
Un argomento complesso e articolato come il linguaggio UML non può, ovviamente, essere
limitato ad un semplice tutorial come questo; in ogni caso, la presente guida può essere
considerata un buon punto di partenza per iniziare a tuffarsi nello straordinario mondo
dell’analisi progettuale.

Introduzione
Nel mondo costantemente in fermento ed in evoluzione quale e’ quello dello sviluppo di
applicazioni Object Oriented, diviene sempre più difficile costruire e gestire applicazioni di
alta qualità in tempi brevi.
Come risultato di tale difficoltà e dalla esigenza di avere un linguaggio universale per
modellare gli oggetti che potesse essere utilizzato da ogni industria produttrice di software,
fu inventato il linguaggio UML, la cui sigla sta per Unified Modeling Language.
In termini pratici, potremmo dire che il linguaggio UML rappresenta, in qualche modo, una
cianografia, un progetto di ingegneria edile, riportato nel mondo dell’Information
Technology.
L’UML è, dunque, un metodo per descrivere l’architettura di un sistema in dettaglio. Come è
facile intuire, utilizzando una sorta di cianografia sarà molto più facile costruire o
manutenere un sistema e assicurarsi che il sistema stesso si presterà senza troppe
difficoltà a futuri cambiamenti dei requisiti.

3
La forza dell’Unified Modeling Language consiste nel fatto che il processo di disegno del
sistema può essere effettuata in modo tale che i clienti, gli analisti, i programmatori e
chiunque altro sia coinvolto nel sistema di sviluppo possa capire ed esaminare in modo
efficiente il sistema e prendere parte alla sua costruzione in modo attivo.
Si consideri il seguente esempio: Nessuno di noi acquisterebbe un appartamento dando
come requisito semplicemente il solo fatto che abbia 4 camere da letto, 3 bagni e che sia
grande circa 180 metri quadri. Tutti desidereremmo studiare a tavolino, magari con l’ausilio
dell’architetto, tutti i dettagli possibili (finestre, porte, ecc.) servendoci, a tale scopo, della
mappa della casa. In modo pressoché analogo si può pensare che funzioni la “macchina”
dello sviluppo di sistemi software. Invece di leggere la piantina della casa, in questo caso ci
si servirà dei diagrammi UML che non fanno altro che documentare in modo esauriente e a
tutti i livelli le caratteristiche tecniche che dovranno essere implementate.

Cenni storici
Durante gli anni ’90 furono introdotte nel mercato dell’Information Technology parecchie
metodologie per il disegno e la progettazione di sistemi software.
Vi era un problema, però: ognuna di queste tecnologie aveva il suo insieme proprio di
notazioni e simboli, che differiva, a volta in modo rilevante, dalle altre.
In particolare, eccellevano tre di queste metodologie:

 OMT (Rumbaugh)
 Booch 1991
 OOSE (Jacobson)
Ognuno di questi metodi aveva, naturalmente, i suoi punti di forza e i suoi punti deboli. Ad
esempio, l’OMT si rivelava ottimo in analisi e debole nel disegno. Booch 1991, al contrario,
eccelleva nel disegno e peccava in analisi. Jacobson aveva il suo punto di forza nell’analisi
dei requisiti e del comportamento di un sistema ma si rivelava debole in altre aree.
Successivamente, Booch scrisse il suo secondo libro che adottava i principi di analisi
utilizzati da Rumbaugh e Jacobson nelle loro rispettive metodologie. A sua volta,
Rumbaugh pubblicò una serie di articoli (conosciuti come OMT-2) che descrivevano
parecchie delle tecnologie di disegno di Booch.
In sostanza, i tre metodi stavano convergendo verso un’unica visione che incorporasse le
qualità migliori che ognuno di essi aveva mostrato. L’unico problema che restava era il fatto
che ogni metodo portava ancora con sè la propria notazione. Tale problema non era da
sottovalutare in quanto l’uso di simbologia differente portava facilmente a confusione sul
mercato a causa del fatto che un determinato simbolo poteva avere un significato differente
per analisti e disegnatori differenti.
Finalmente, dopo un periodo di tempo in cui andò avanti la cosidetta “guerra della
metodologia” (“method war”) ci si rese conto che era assolutamente necessario produrre
uno standard che unificasse anche la notazione utilizzata.
Fu così che, nell’Ottobre del 1995, nacque la prima bozza dell’UML, ovvero l’unificazione
delle notazioni e delle idee prodotte da Booch, Rumbaugh e Jacobson per modellare un
sistema software. La prima versione ufficiale, prodotta dall’OMG (Object Management
Group) fu rilasciata nel Luglio del 1997 e nel Novembre dello stesso anno l’UML venne
adottato come standard.

4
I vantaggi del UML
Elenchiamo, qui di seguito, alcuni dei benefici derivanti dall’utilizzo del linguaggio UML:

1. Un sistema software grazie al linguaggio UML viene disegnato professionalmente e


documentato ancor prima che ne venga scritto il relativo codice, da parte degli sviluppatori. Si
sarà così in grado di conoscere in anticipo il risultato finale del progetto su cui si sta lavorando.
2. Poichè, come detto, la fase di disegno del sistema precede la fase di scrittura del codice, ne
consegue che la scrittura del codice stessa è resa più agevole ed efficiente oltre al fatto
che in tal modo è più facile scrivere del codice riutilizzabile in futuro. I costi di sviluppo,
dunque, si abbassano notevolmente con l’utilizzo del linguaggio UML.
3. è più facile prevedere e anticipare eventuali “buchi” nel sistema. Il software che si scrive, si
comporterà esattamente come ci si aspetta senza spiacevoli sorprese finali.
4. L’utilizzo dei diagrammi UML permette di avere una chiara idea, a chiunque sia coinvolto
nello sviluppo, di tutto l’insieme che costituisce il sistema. In questo modo, si potranno
sfruttare al meglio anche le risorse hardware in termini di memoria ed efficienza, senza
sprechi inutili o, al contrario, rischi di sottostima dei requisiti di sistema.
5. Grazie alla documentazione del linguaggio UML diviene ancora più facile effettuare
eventuali modifiche future al codice. Questo, ancora, a tutto beneficio dei costi di
mantenimento del sistema.
La comunicazione e l’interazione tra tutte le risorse umane che prendono parte allo sviluppo
del sistema è molto più efficiente e diretta. Parlare la stessa “lingua” aiuta ad evitare rischi
di incomprensioni e quindi sprechi di tempo.

Che cos’e il Visual Moding?


Si è già accennato nell’introduzione circa la similitudine tra i diagrammi UML e una
cianografia. è, però, importante capire bene ed approfondire un attimo il concetto di “Visual
Modeling” prima di andare avanti.
Abbiamo già utilizzato, precedentemente, il termine Sistema. Ma, prima di tutto, cosa è
esattamente un Sistema (informatico)?
Un Sistema è una combinazione di componenti software e hardware che fornisce una
soluzione ad un’esigenza del mondo reale (business problem).
Per far sì che un Sistema sia efficiente, sarà necessario recepire bene le richieste del
cliente e fare in modo che esse vengano condivise e recepite come requisiti indispensabili
dall’intero team di lavoro. Successivamente, si useranno tali requisiti per generare il codice
necessario alla costruzione del Sistema assicurandosi, andando avanti nella scrittura del
codice, che non si perda di vista l’obiettivo finale. Tale procedimento prende il nome di
“Modeling” (o, se preferite, modellazione).

5
Il “veccho” metodo di modeling dei sistemi, conosciuto anche come “Metodo a Cascata”
(Waterfall Method), si basava sul fatto che i vari passi che costituivano il processo di
sviluppo di un sistema fossero sequenziali (l’inizio di uno avveniva soltanto dopo il termine
di un altro).
Quello che accadeva seguendo il waterfall method era che le persone del team si
trovavano a lavorare su task differenti e spesso, non avevano alcun modo di comunicare a
discapito di importanti questioni inerenti il Sistema stesso. Un altro punto debole del
waterfall method era il fatto che esso prevedeva che si concedesse la maggior parte del
tempo alla scrittura del codice, togliendolo, in tal modo, all’analisi ed al disegno che invece
rappresentano la base per un solido progetto.
Il Visual Modeling, che ha soppiantato ormai il waterfall method, altro non è che il
processo che prevede la visualizzazione grafica di un modello, utilizzando un insieme ben
definito di elementi grafici, che nel linguaggio UML sono rappresentati dai 9 Diagrammi di
base.
Il processo per la costruzione di un Sistema coinvolge molte persone: Prima di tutto
il cliente, ovvero la persona che desidera avere una risoluzione ad un problema o ad una
sua esigenza. Un analista ha il compito di documentare il problema del cliente e
trasmettere tali informazioni agli sviluppatori, i quali costituiscono la parte del team che si
occupa di implementare il codice, testarlo ( con il supporto di un team apposito per il test) e
installarlo sull’hardware dei computer.
Questo tipo di suddivisione dei compiti è necessario poiché al giorno d’oggi i sistemi sono
diventati davvero molto complessi e la conoscenza è divenuta molto più specializzata da
non poter essere gestita soltanto da una persona.
Il Visual Modeling prevede una continua interazione tra i vari membri del team di lavoro.
Analisti e disegnatori, per esempio, necessitano di un continuo scambio di vedute per
permettere che i programmatori possano basarsi su una solida informazione. A loro volta, i
programmatori devono interagire con gli analisti ed i disegnatori per condividere le loro
intuizioni, modificare i disegni e consolidare il codice.
Il vantaggio di tale tipo di approccio è che la conoscenza generale del team cresce
notevolmente, ognuno è in grado di capire a fondo il sistema e il risultato finale non può che
essere un sistema più solido (con il cliente più soddisfatto!).

RAD – Rapid Application Development


Un progetto per lo sviluppo di un sistema non può basarsi sull’improvvisazione ma deve
seguire un iter tecnico-logico che consenta di arrivare in tempi brevi alla soluzione migliore.
Il RAD rappresenta proprio una sorta di “tracciato” del progetto che viene incontro a tale
esigenza.
Il RAD (Rapid Application Development), ovvero lo sviluppo rapido di applicazioni, consiste,
fondamentalmente, di cinque sezioni:

1. Raccolta delle informazioni


2. Analisi
3. Disegno

6
4. Sviluppo
5. Deployment

Raccolta delle informazioni


Questa azione consiste, a sua volta, di parecchie altre azioni. Esaminiamole una per una
tenendo presente sempre che è di fondamentale importanza capire bene i requisiti che il
cliente richiede. Soltanto così si otterranno dei sistemi stabili e robusti.
Processo di scoperta del Business.
In questa fase, gli analisti studiano i processi di business del cliente servendosi di colloqui
specifici con il cliente stesso e chiedendogli di analizzare a fondo i processi rilevanti, passo
per passo. Di solito, al termine di tale attività vengono abbozzati uno o più Activity
Diagrams.
Analisi del Dominio.
L’analista intervista il cliente con lo scopo di capire bene le entità principali del dominio del
cliente. Alla conversazione tra l’analista ed il cliente, prende parte anche un altro membro
del team il quale prende accuratamente nota di tutto. In particolare, si cerca di porre
particolare attenzione ai termini chiave del dominio che vengono appuntati come possibili
Classi. Al termine di tale analisi, alcuni termini dell’analisi diverranno attributi mentre
determinate azioni, che sono, anch’esse, ritenute di rilevante importanza, saranno
etichettate come operazionidelle classi. Al termine di tale sezione si produce un Class
Diagram ad alto livello ed una buona serie di appunti).
Identificazione della possibile correlazione tra sistemi.
All’inizio del processo di sviluppo, il team di sviluppo identifica esattamente le dipendenze
tra i vari sistemi, ovvero da quali eventuali sistemi esistenti il nuovo sistema dovrà
dipendere e, viceversa, quali sistemi dovranno dipendere dal nuovo. Il responsabile di tale
fase è, solitamente un System Engineer. Al termine di tale sezione si produrrà
un Deployment Diagram.
Identificazione dei requisiti di sistema.
Questa fase rappresenta la prima sessione di sviluppo misto (Joint Application
Development –JAD). Infatti, ad essa partecipano i responsabili dell’organizzazione del
cliente, i potenziali utenti e i membri del team di sviluppo. Può essere utile la presenza di un
supervisore che si pone come obiettivo quello di riuscire a carpire dai responsabili e dagli
utenti ciò che essi realmente desiderano dal sistema. Almeno due membri del team
dovrebbero prendere appunti e rifinire il Class Diagram disegnato nella precedente fase di
Analisi del Dominio.
Presentazione dei risultati al cliente.
Quando il team reputa concluse le operazioni di raccolta delle informazioni, il Project
Manager presenta i risultati di tale analisi al cliente.

Analisi
A questo punto, il team è pronto per andare a fondo sui risultati ottenuti dalla raccolta delle
informazioni e approfondire, dunque, la conoscenza del problema. Alcune delle azioni di

7
Analisi iniziano, in realtà, proprio durante la fase di raccolta delle informazioni quando viene
abbozzato uno “schizzo” del Class Diagram.
Comprensione dell’utilizzo del sistema.
In una sessione JAD (Joint Application Development) con i potenziali utenti, il team di
sviluppo lavora con gli utenti per definire gli actors (Con tale termine si può intendere sia
una persona che un sistema, ma ne parleremo in seguito) che interagiscono con ogni
singolo use case (caso d’uso) sia come beneficiari che come iniziatori dello stesso use
case. è questo il momento in cui vengono prodotti gli Use Case Diagrams.
Consolidare gli Use Cases.
è importante continuare a lavorare con gli utenti al fine di verificare ogni singolo use case in
base alla sequenza di azioni che ognuno di essi descrive. Durante tale fase, viene aggiunta
una descrizione testuale ai singoli passi di ogni use case diagram.
Rifinire i Class Diagrams.
La persona incaricata di modellare gli oggetti, durante la sessione JAD, dovrà porre la
massima attenzione alle discussioni e alle richieste dei clienti al fine di rifinire i vari
diagrammi delle classi. Tale operazione può consistere nel dare dei nomi appropriati alle
classi, alle associazioni, alle classi astratte, alle generalizzazion e alle aggregazioni (per la
comprensione di tali termini si veda la loro descrizione più avanti in questa guida). è questo
il momento in cui il Class Diagram diviene più dettagliato.
Analizzare i cambi di stato negli oggetti.
Durante la creazione dei modelli, sarà importante anche porre attenzione alla descrizione di
eventuali cambi di stato di un oggetto, dove questo si renda necessario. Vengono prodotti
in questa fase gli State Diagrams.
Definire le interazioni tra gli oggetti.
Fino ad ora il team di lavoro è arrivato a mettere giù un insieme di Use Cases e di Class
Diagrams più o meno rifiniti. è ora tempo di definire come gli oggetti descritti interagiranno
tra di loro. Il responsabile della descrizione dei modelli dovrà sviluppare un insieme di
diagrammi che includano i cambi di stato. è qui che vengono prodotti i Sequence
Diagrams e iCollaboration Diagrams.
Analizzare l’integrazione del sistema da sviluppare con gli altri sistemi preesistenti.
Il System Engineer, procedendo in parallelo con tutte le fasi descritte sin qui, scopre ed
analizza tutti i dettagli relativi alla integrazione del sistema che si intende sviluppare con
eventuali sistemi pre-esistenti o comunque sistemi con i quali sarà necessario cooperare.
Le domande che sarà opportuno porsi per tale operazione saranno qualcosa del tipo:
Quale tipo di comunicazione viene utilizzata? Come è fatta l’architettura della rete? Il
sistema dovrà interagire con un database? Se si, con quali tipi di database? In tale fase
verranno costruiti iDeployment Diagrams.

Disegno
Durante la fase di disegno, il team lavora in base ai risultati che sono stati forniti dall’analisi
al fine di disegnare la soluzione. Il Disegno e l’Analisi necessitano, a questo punto, di
essere aggiornati vicendevolmente fin quando non si reputa che la fase di disegno sia
completata.
Sviluppare e rifinire gli Object Diagrams.
I programmatori leggono il class diagram e generano tutti gli Object Diagrams necessari
anche in base all’esame di ogni operazione. Parallelamente si sviluppa un corrispondente

8
activity diagram. Tale Activity Diagram costituirà la base per la maggior parte della
scrittura del codice nella fase di sviluppo.
Sviluppare i Component Diagrams.
Durante tale fase i programmatori giocano un ruolo molto importante. Il lavoro principale, in
questo caso, consiste nel visualizzare i componenti che prenderanno parte nella fase
successiva e mostrare le dipendenze tra loro. è in questa fase che vengono prodotti
iComponent Diagrams.
Pianificare il Deployment del sistema.
Dopo aver costruito il Component Diagram il System Engineer inizia a pianificare il
deployment dell’intero sistema per gestire le varie interazioni con altri sistemi. I diagrammi
così creati mostreranno dove i componenti risiederanno.
Disegnare e creare un prototipo dell’interfaccia utente.
Tale fase richiede un’altra sessione JAD con gli utenti come continuazione della
precedente. Tale fase costitusce un punto intermedio tra Analisi e Disegno. Un analista GUI
(Graphical User Inteface) lavora con gli utenti per sviluppare prototipi su carta di come il
sistema si interfaccierà con l’utente finale. In questa fase vengono prodotto delle stampe
dei prototipi delle possibili interfacce utente.
Disegno dei Test.
Per sviluppare questa fase è consigliabile avvalersi di uno sviluppatore o di un tester
esperto che non appartenga però al team di sviluppo del sistema. Egli utilizzerà gli Uses
Cases diagrams per sviluppare dei casi di test (Test Cases) che siano, preferibilmente,
automatizzati.
Inizio della Documentazione.
Uno o più specialisti della documentazione lavorano con i disegnatori del sistema per
iniziare la documentazione ed arrivare man mano ad una struttura di alto livello per ogni
documento. Viene prodotta in questa fase una bozza di documentazione.

Sviluppo
Se le precedenti fasi di analisi e disegno sono state eseguite con accuratezza e scrupolo, la
fase dello sviluppo non potrà che scorrere velocemente e senza grossi intoppi.
Implementazione del Codice.
Con i Class Diagrams, gli Object Diagrams, gli Activity Diagrams e i Component Diagrams
a disposizione, i programmatori implementano il codice per il sistema.
Test del Codice.
Ogni nuova implementazione del codice sarà, necessariamente interfacciata con una
opportuna fase di test. Si può, praticamente, dire che le due fasi camminano di pari passo
fin quando il codice supera tutti i livelli di test sviluppati nella fase di disegno. Vengono
prodotti in questa fase i risultati del Test.
Costruzione della Interfaccia Utente e collegamento al codice.
Questa fase si può considerare come un legame tra Disegno e Sviluppo. Qui, uno
specialista GUI costruisce dei prototipi di interfaccia e che dovranno essere collegati al
codice. Naturalmente tale collegamento necessita di una opportuna fase di test e verifica. A
questo punto si dovrebbe avere a disposizione il Sistema funzionante completo con
l’interfaccia utente.

9
Completamento della documentazione.
Il completamento del sistema permette agli esperti della documentazione di terminare la
stesura di tutto il materiale necessario per descrivere il sistema.

Deployment
Quando la fase di sviluppo (development) è completata, il sistema viene installato
sull’hardware appropriato ed integrato con i sistemi con cui deve interagire. Questa fase
prende il nome di Deployment.
Pianificare un piano per il backup ed il recupero delle informazioni.
Questa fase, in realtà, può anche iniziare molto prima che lo sviluppo del sistema inizi. Il
System Engineer crea un piano che descriverà i passi da seguire nel caso in cui il sistema
dovesse andare in crash (Piano di Crash Recovery).
Installare il sistema completo sull’hardware appropriato.
Questo passo viene eseguito dal System Engineer con l’eventuale supporto necessario da
parte dei programmatori.
Testare il sistema installato.
Dopo aver installato il software sulle macchine appropriate, il team di sviluppo testa il
sistema. Le domande che sarà opportuno chiedersi in questa fase sono del tipo: Il sistema
si comporta come ci si aspettava? Il piano di backup e di recovery funzionano? A seconda
del risultato di tali test si deciderà se è opportuno un ulteriore raffinamento del sistema.
Festeggiare il risultato ottenuto.
Anche questa fase, che non ha certo delle caratteristiche tecniche, riveste una grande
importanza. Se tutto funziona a dovere è giusto andare a festeggiare il successo ottenuto
con l’intero team.

Gli strumenti di lavoro UML


Come ogni linguaggio che si rispetti anche l’UML necessita dell’utilizzo di tools appropriati
che ne agevolino l’utilizzo. L’utilizzo 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. Per maggiori informazioni su questo
tool si visiti la pagina http://www.rational.com.
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. Diciamo che tale
software può essere consigliato 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

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

Componenti UML
Il linguaggio UML contiene svariati elementi grafici che vengono messi insieme durante la
creazione dei diagrammi. Poiché l’UML è un linguaggio, esso utilizza delle regole per
combinare i componenti del linguaggio 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.
Passiamo ora in rassegna, brevemente, tutti i diagrammi UML, prima di analizzarli più
dettagliatamente in seguito.
Il linguaggio UML consiste di nove diagrammi di base, ma si tenga presente che è
assolutamente possibile costruire e aggiungere dei diagrammi differenti dagli standard (che
vengono definiti ibridi) rispetto a quelli definiti dal linguaggio.
Class Diagram
Per avere una idea immediata di cosa sia una classe possiamo usare come esempio il fatto
che tutti gli oggetti o esseri viventi, spesso, sono riconducibili a determinate categorie (ad
esempio: computers, automobili, piante, animali, ecc.). Queste categorie costituiscono le
classi.
Definizione:Una classe è una categoria o un gruppo di oggetti (con questo termine
includiamo, 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 vedremo in seguito.
Definizione: 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.. Puo’ 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, infante, bambino,
adolescente, adulto, anziano.

11
Sequence Diagram
I class diagrams e gli object diagrams rappresentano informazione statica. In un sistema
funzionante, tuttavia, gli oggetti interagiscono l’uno con l’altro, e queste interazioni
avvengono in relazione al trascorrere del tempo. Il sequence diagram mostra le dinamiche,
basate sul tempo, delle varie interazioni tra gli oggetti.
Activity Diagram
Le attività che si riscontrano all’interno di use case o all’interno del comportamento di un
oggetto accadono, tipicamente, in una sequenza ben definita. Tale sequenza viene
rappresentata con gli activity diagrams.
Collaboration Diagram
Gli elementi di un sistema lavorano insieme per realizzare e soddisfare le necessità del
sistema. Un linguaggio di modellazione deve avere un modo per rappresentare tale
cooperazione. Il Collaboration Diagram nasce proprio per questa ragione.
Component Diagram
Oggi, nell’ingegneria del software viene sempre più utilizzato il modello di organizzazione
secondo il quale ognuno nel team di lavoro si occupa di lavorare su un componente
differente. Il component diagram descrive questa importante caratteristica.
Deployment Diagram
Il Deployment Diagram mostra l’architettura dal punto di vista fisico e logistico di un
sistema. Tale diagramma può descrivere i computer e i vari dispositivi presenti, mostrare le
varie connessioni che intercorrono tra di essi e, ancora, il software che è installato su ogni
macchina.
Una domanda che ci si potrebbe porre a questo punto è la seguente: Ma è proprio
necessario sviluppare tutti e nove i diagrammi che l’UML mette a disposizione?
La risposta a questa domanda può variare in relazione alla complessità del Sistema che si
intende costruire ma, in linea di massima, tende ad essere affermativa. La ragione di ciò
consiste nel fatto che, come si è già detto, i diagrammi UML sono stati pensati per venire
incontro all’esigenza di rendere il Sistema comprensibile da differenti persone con differenti
figure professionali.
Probabilmente, ad esempio, un commerciale non trarrà una particolare impressione
leggendo un Class Diagram ma potrà, certamente, avere le idee più chiare analizzando uno
Use Case Diagram.

Rappresentazione di una classe


Si è detto precedentemente nella guida che gli oggetti possono essere suddivisi in
categorie e, quindi, in classi. Il Class Diagram del linguaggio UML consiste di svariate
classi connesse tra di loro tramite delle relazioni.
Prima di tutto, però, è importante definire graficamente una classe in UML:

Una classe viene rappresentata da un rettangolo. Il nome della classe, per convenzione, è
una parola con l’iniziale maiuscola ed appare vicino alla sommità del rettangolo. Se il nome
della classe definita consiste di una parola composta a sua volta da più parole allora viene
utilizzata la notazione in cui tutte le iniziali di ogni parola sono scritte in maiuscolo.

12
Definizione generica di una classe
Un attributo rappresenta una proprietà di una classe. Esso descrive un insieme di valori che
la proprietà può avere quando vengono istanziati oggetti di quella determinata classe. Una
classe può avere zero o più attributi.
Un Attributo il cui nome è costituito da una sola parola viene scritto sempre in caratteri
minuscoli. Se, invece, il nome dell’attributo consiste di più parole (es: Informazioni-Cliente)
allora il nome dell’attributo verrà scritto unendo tutte le parole che ne costituiscono il nome
stesso con la particolarità che la prima parola verrà scritta in minuscolo mentre le
successive avranno la loro prima lettera in maiuscolo. Nell’esempio appena visto l’attributo
sarà identificato dal termine: informazioniCliente.
La lista degli attributi di una classe viene separata graficamente dal nome della classe a cui
appartiene tramite una linea orizzontale.

Nell’icona della classe, come si vede nella figura precedente, è possibile specificare un tipo
in relazione ad ogni attributo (string, float, int, bool, ecc.). E’ anche possibile specificare un
valore di default che un attributo può avere.
Un’Operazione è un’azione che gli oggetti di una certa classe possono compiere.
Analogamente al nome degli attributi, il nome di un’operazione viene scritto con caratteri
minuscoli. Anche qui, se il nome dell’operazione consiste di più parole, allora tali parole
vengono unite tra di loro ed ognuna di esse, eccetto la prima, viene scritta con il primo
carattere maiuscolo. La lista delle operazioni (metodi) viene rappresentata graficamente
sotto la lista degli attributi e separata da questa tramite una linea orizzontale.

Anche I metodi possono avere delle informazioni addizionali. Nelle parentesi che seguono il
nome di un’operazione, infatti, è possibile mostrare gli eventuali parametri necessari al
metodo insieme al loro tipo. Infine, se il metodo rappresenta una funzione è necessario
anche specificare il tipo restituito.
Altre informazioni addizionali che possono essere unite agli attributi di una classe sono le
“Constraints” e le Note.
Le “Constraints” sono delle caselle di testo racchiuse tra parentesi. All’interno delle
parentesi viene specificata una o più regole che la classe è tenuta a seguire
obbligatoriamente.

13
Le Note solitamente sono associate con gli attributi e/o con i metodi. Esse forniscono una
informazione aggiuntiva ad una classe. Una nota può contenere sia elementi grafici che
elementi di testo.
Come si può riuscire a discernere le classi da utilizzare dalla intervista con il cliente?
E’ necessario, a tal fine, prestare particolare attenzione ad i nomi che i clienti usano per
descrivere le entità del loro business. Tali nomi saranno ottimi candidati per diventare delle
classi nel modello UML. Si deve prestare, altresì, attenzione ai verbi che vengono
pronunciati dai clienti. Questi costituiranno, con molta probabilità, i metodi (le operazioni)
nelle classi definite. Gli attributi di una classe verranno stabiliti con le analoghe modalità
utilizzate per i nomi delle classi.

Associazioni
Quando più classi sono connesse l’una con l’altra da un punto di vista concettuale, tale
connessione viene denominata associazione.
Graficamente, un’associazione viene rappresentata con una linea che connette due classi,
con il nome dell’associazione appena sopra la linea stessa.

Quando una classe si associa con un’altra, ognuna di esse gioca un ruolo all’interno
dell’associazione. E’ possibile mostrare questi ruoli sul diagramma, scrivendoli vicino la
linea orizzontale dalla parte della classe che svolge un determinato ruolo, come si vede
nella figura precedente.
Un’associazione può essere più complessa del concetto di connettere una classe ad
un’altra. E’ possibile, infatti che più classi possano connettersi ad una singola classe.
Qualche volta un’associazione tra due classi deve seguire una regola. Tale regola si indica
inserendo una “constraint” vicino la linea che rappresenta l’associazione.

Esattamente come una classe, un’associazione può avere attributi ed operazioni. In questo
caso si parla di una Classe Associazione (vedasi figura precedente).
Le classi associazione vengono visualizzate allo stesso modo con cui si mostra una classe
normale. Si utilizza una linea tratteggiata per connettere una Classe Associazione alla linea
di associazione.

14
La molteplicità è un tipo speciale di associazione in cui si mostra il numero di oggetti
appartenenti ad una classe che interagisce con il numero di oggetti della classe associata.
Una classe, in generale, può essere correlata ad una altra nei seguenti modi:

 Uno ad uno
 Uno a molti
 Uno ad uno o più
 Uno a zero o uno
 Uno ad un intervallo limitato (es.: 1 a 2 – 20)
 Uno ad un numero esatto n
 Uno ad un insieme di scelte (es.: 1 a 5 o 8)
Il linguaggio UML utilizza un asterisco (*) per rappresentare le opzioni “molti” e “più”.
Qualche volta, una classe può trovarsi in associazione con se stessa. Ciò si verifica quando
una classe contiene oggetti che possono giocare svariati ruoli. Tali associazioni sono
chiamate: “Associazioni Riflessive”.

Associazione Riflessiva
Senza le relazioni, un modello di classi sarebbe soltanto una lista di rettangoli che
rappresentano un “vocabolario” del sistema. Le relazioni mostrano come i termini del
vocabolario si connettono tra di loro per fornire un quadro della fetta di sistema che si sta
modellando. L’associazione rappresenta, dunque, la connessione concettuale
fondamentale tra le classi in cui ogni classe, come detto, gioca un ruolo specifico.

Ereditarieta e Generalizzazione
Se si conosce qualcosa riguardo ad una categoria di cose, automaticamente si conosce
qualcosa che è possibile trasferire ad altre categorie che, in qualche modo, discendono
dalla categoria che conosciamo. Chiariamo meglio questo concetto.
Ad esempio, se si conosce qualcosa su un animale generico (ad esempio si sa che un
animale mangia, dorme, é nato, si sposta da un luogo ad un altro, ecc.), potremo dire che
tutte le sottocategorie di animali (rettili, anfibi, mammiferi, ecc.) erediteranno le stesse
caratteristiche. Tale meccanismo, in Analisi Object Oriented, viene definito come:
Ereditarietà

15
Un esempio di ereditarietà
Una classe figlia (o sottoclasse) può ereditare gli attributi e le operazioni da un’altra classe
(che viene definita classe padre o super classe) che sarà sempre più generica della classe
figlia.
Nella generalizzazione, una classe figlia può rappresentare un valido sostituto della classe
padre. Cioè, in qualunque posto appaia la classe padre, sarebbe possibile far apparire la
classe figlia. Il viceversa non è, invece, vero.
In UML l’ereditarietà viene rappresentata con una linea che connette la classe padre alla
classe discendente e dalla parte della classe padre si inserisce un triangolo (una freccia).
Se ragioniamo dal punto di vista dell’associazione, l’ereditarietà può essere vista come un
tipo di associazione.
Come devono fare gli analisti per scoprire l’ereditarietà di una o più classi? L’analista deve
far si che gli attributi e le operazioni per una classe siano generali e si applichino a
parecchie altre classi (le sottoclassi) che, a loro volta, potranno “specializzare” la classe
padre aggiungendo attributi e operazioni propri. Un’altra possibilità è che l’analista noti che
due o più classi hanno un numero di attributi ed operazioni in comune.
Le classi che non permettono di istanziare nessun tipo di oggetto sono dette classi astratte.
In UML una classe astratta si indica scrivendo il suo nome in corsivo.
Riassumendo si può dire che una classe può ereditare attributi ed operazioni da un’altra
classe. La classe che eredita è figlia della classe (padre) da cui prende gli attributi e le
operazioni. Le classi astratte sono utilizzate soltanto come classi base per l’ereditarietà e
non forniscono alcun oggetto implementabile.

Aggregazioni
Qualche volta una classe può rappresentare il risultato di un insieme di altre classi che la
compongono. Questo è un tipo speciale di relazione denominata aggregazione. Le classi
che costituiscono i componenti e la classe finale sono in una relazione particolare del
tipo:parte – intero (part-whole)
Un’aggregazione è rappresentata come una gerarchia in cui l’ “intero” si trova in cima e i
componenti (“parte”) al di sotto. Una linea unisce “l’intero” ad un componente con un rombo
raffigurato sulla linea stessa vicino all’ “intero”.
Un esempio di aggregazione
Esaminiamo le “parti” che costituiscono un Televisore. Ogni TV ha un involucro esterno

16
(Box), uno schermo, degli altoparlanti, delle resistenze, dei transistors, un circuito integrato
e un telecomando (oltre, naturalmente, ad altri tantissimi componenti!). Il telecomando può,
a sua volta, contenere le seguenti parti: resistenze, transitors, batterie, tastiera e luci
remote.
Il Class Diagram che ne deriva sarà il seguente:

Qualche volta l’insieme di possibili componenti di un’aggregazione si identifica in una


relazione OR. Per modellare tale situazione, è necessario utilizzare una constraint – la
parola OR all’interno di parentesi graffe su una linea tratteggiata che connette le due linee
parte-intero.
Una composizione è una tipo più forte di aggregazione. Ogni componente in una
composizione può appartenere soltanto ad un “intero”. Il simbolo utilizzato per una
composizione è lo stesso utilizzato per un’aggregazione eccetto il fatto che il rombo è
colorato di nero.
Se, ad esempio, si esamina l’aspetto esterno degli uomini, si evincerà che ogni persona ha
(tra le altre cose): una testa, un corpo, due braccia. e due gambe. Tale concetto viene
rappresentato nel seguente grafico:

Una associazione composita. In tale associazione ogni componente appartiene


esattamente ad un intero
Riepilogando diciamo che un’aggregazione specifica un’associazione di tipo “parte –
intero” in cui una classe che rappresenta l’ “intero” è costituita da più classi che la
compongono.
Una composizione è una forma più forte di aggregazione in cui un componente può
appartenere soltanto ad un “intero”. Le aggregazioni e le composizioni sono rappresentate
come linee che uniscono l’ “intero” e il componente singolo tramite, rispettivamente, un
rombo aperto e un rombo riempito di nero, entrambi disegnati dalla parte dell’ “intero”.

17
Interfacce e internalizzazioni
Finora abbiamo detto che è importante definire le classi in base all’intervista fatta con il
cliente, e far sì che tali classi vengano messe nelle corrette relazioni tra di loro. Tuttavia, è
possibile che alcune classi non siano correlate ad una particolare classe padre e che il loro
comportamento possa includere alcune operazioni tutte recanti lo stesso nome. In tal caso
esiste la possibilità di definire tali operazioni per una classe e riutilizzarle per le altre: è
proprio quello che avviene tramite l’utilizzo delle interfacce.
Un’interfaccia è un insieme di operazioni che specifica alcuni aspetti del comportamento di
una classe; in altre parole, si può dire che un’interfaccia rappresenta un insieme di
operazioni che una classe offre ad altre classi.
Definizione: Un’interfaccia viene modellata allo stesso modo in cui viene modellato il
comportamento una classe e rappresenta un insieme di operazioni che una classe offre ad
altre classi.
Per modellare un’interfaccia si utilizza lo stesso modo utilizzato per modellare una classe,
con un rettangolo. La differenza consiste nel fatto che un’interfaccia non ha attributi ma
soltanto operazioni (metodi). Un altro modo utilizzato in UML per rappresentare le
interfacce è quello che utilizza un piccolo cerchio che si unisce tramite una linea alle classi
che implementano l’interfaccia stessa.
La tastiera del computer è un tipico esempio di interfaccia riutilizzabile. La pressione di un
tasto (KeyStroke) rappresenta un’operazione che è stata riutilizzata dalla macchina per
scrivere. La collocazione dei tasti è la stessa della macchina per scrivere, ma il punto
cruciale è che la pressione di un tasto è stata trasferita da un sistema (i due sistemi, come
si evince facilmente, nel nostro caso sono la macchina per scrivere ed il computer) ad un
altro. D’altro canto, sulla tastiera dei computer si trovano un insieme di operazioni che non
si trovano sulla macchina per scrivere (Ctrl, Alt, PageUp, PageDown, ecc.)

Una interfaccia è una collezione di operazioni che una classe esegue


Per distinguere le interfacce dalle classi, dal punto di vista UML si utilizza la
scrittura interface all’inizio del nome di ogni interfaccia, come mostrato nella figura
precendente.
La relazione tra una classe ed un’interfaccia viene definita realizzazione. Tale relazione è
visualizzata nel modello da una linea tratteggiata con un triangolo largo aperto costruito sul
lato dell’interfaccia.

18
Visibilita
La Visibilità si applica ad attributi o operazioni e specifica la possibilità che hanno le classi
di usare gli attributi e le operazioni di un’altra classe.
Sono consentiti tre livelli di visibilità:

 Livello pubblico: L’utilizzo viene esteso a tutte le classi


 Livello protetto: L’utilizzo è consentito soltanto alle classi che derivano dalla classe originale
 Livello privato: Soltanto la classe originale può utilizzare gli attributi e le operazioni definite
come tali.
A livello grafico vengono utilizzati, generalmente, i seguenti simboli per distinguere i tre
livelli:

 Livello pubblico: +
 Livello protetto: #
 Livello privato: -
Il Rational Rose, invece, utilizza i seguenti simboli, per le operazioni:

 Livello pubblico:
 Livello protetto:
 Livello privato:
E gli stessi, con il colore differente, per gli attributi:

 Livello pubblico:
 Livello protetto:
 Livello privato:

19
Class Diagrama – Esempio Pratico
Prendiamo come esempio una applicazione classica: quella che permette di scrivere un
documento di testo. Cerchiamo di descrivere i passi che costituiscono tale applicazione.
Supponiamo che si stia digitando un documento di testo, utilizzando qualche famoso editor
di testi, come Microsoft Word, ad esempio. L’utente ha due possibilità iniziali:

 Cominciare a scrivere un nuovo documento


 Aprire un documento esistente
Il testo da scrivere, ovviamente, verrà digitato tramite l’utilizzo della tastiera.
Ogni documento è composto di svariate pagine, e ogni pagina, a sua volta, è composta da
una testata, dal corpo del documento e da un piè di pagina. Nella intestazione e nel piè di
pagina è possibile aggiungere la data, l’ora, il numero di pagina, la collocazione del file,
ecc.
Il corpo del documento è formato da frasi. Le frasi, a loro volta, sono composte da parole e
segni di punteggiatura. Le parole sono formate da lettere, numeri e/o caratteri speciali.
Inoltre,. Vi è la possibilità di aggiungere delle immagini e delle tabelle nel documento. Le
tabelle sono costituite da righe e colonne ed ogni cella di una tabella può contenere del
testo o delle immagini.
Dopo aver terminato il documento, l’utente può scegliere di salvarlo o stamparlo.
Abbiamo in tal modo descritto, in maniera semplificata ma congruente, il processo di
creazione di un documento tramite Microsoft Word. Rifacendoci a quanto già detto nella
guida circa l’intervista con il cliente, siamo in grado, allora, di estrarre la seguente lista di
parole chiave:
documento , editor di documenti, Microsoft Word, testo , tastiera, intestazione, piè
pagina, corpo del documento, data, ora, numero di pagina, collocazione del file,
pagina, frase, parola, segno di punteggiatura, lettera, numero, carattere speciale,
immagine, tabella, riga, colonna, cella, utente.
Potremmo dire che le parole chiave evidenziate in blu sono sicuramente candidate a
diventare classi o attributi per il modello da sviluppare.
Come è possibile osservare, nell’esempio descritto l’oggetto attorno a cui ruoto un po’ tutto
il discorso è il Documento. Per tale ragione, sarà una buona idea identificare nel
Documento la classe centrale del nostro Class Diagram.
Un documento, come detto, può avere svariate pagine e, quindi, potremo definire un
attributo: numeroDiPagine che descrive tale caratteristica. Invece, per le operazioni, sarà
bene definire i metodi:
Apri( ), Salva( ), Stampa( ),Nuovo( ).

20
Si è detto, poi, che ogni documento è composto di pagine. La Pagina sarà, dunque, un
buon candidato per essere una classe del nostro diagramma.
La Classe Pagina conterrà un attributo : numeroDiPagina, che identificherà il numero della
pagina dell’oggetto, e le seguenti operazioni: nuovaPagina(), nascondiIntestazione() e
nascondiPièdiPagina().

I metodi per la testata e il piè di pagina ci fanno intendere che è bene definire altre due
classi:Intestazione e PiePagina.
Tali classi hanno i seguenti attributi in comune: data, ora, numeroDiPagina e pathFile. Tali
attributi sono opzionali per ogni intestazione o pie’ di pagina e l’utente potrà configurarli a
suo piacimento.
La somiglianza tra Intestazione e PièPagina ci spinge a definire ancora una nuova classe
che sia in comune alle due appena descritte. è qui che utilizziamo il concetto di ereditarietà
che abbiamo definito in precedenza.
La classe padre sarà BottomUp (questo nome è scelto perché le intestazioni e i piè di
pagina appaiono, rispettivamente, nella parte alta e bassa di ogni pagina del documento) e
conterrà gli attributi che sono in comune alle classi Intestazione e PiePagina oltre alle
operazioni (anch’esse in comune) : visualizza(), modifica() e nascondi().
Le classi Intestazione e PiePagina (figlie di BottomUp) avranno la necessità, quindi, di
definire, rispettivamente, soltanto le operazioni: nuovaIntestazione() e nuovoPiePagina().

Prima di passare ad esaminare il corpo del documento o il testo, diamo uno sguardo alla
definizione dei componenti di un testo. Come detto, il testo del documento è composto di
frasi. Le frasi, a loro volta, sono composte di parole e le parole sono formate da caratteri.

21
Se le parole sono, dunque, array di caratteri e le frasi sono identificabili come array di
parole, allora una frase è anche (per una sorta di proprietà transitiva) un array di caratteri.
Quindi, il corpo di un documento può essere descritto come un array di caratteri. Per tale
ragione, per descrivere il testo di un documento faremo uso della classe Carattere con
alcune sottoclassi.
La classe Carattere avrà gli attributi: codiceASCII e tipo (il tipo ci informa sulla tipologia di
carattere, ovvero se esso è in formato normale, corsivo, grassetto o sottolineato) e definirà
le operazioni: Normale(), Corsivo(), Grassetto() e Sottolineato().
Come discendenti della classe Carattere definiremo poi: Lettera, SegnoDiPunteggiatura,
CarattereSpeciale e Numero.
Inoltre, nel corpo del documento, come detto, possono comparire tabelle o immagini.
Entrambe costituiranno altre due nuove classi nel nostro diagramma.

La Classe Tabella contiene gli attributi numeroDiRighe e numeroDiColonne e definisce le


operazioni inserisciRiga( ) e inserisciColonna( ).
Ogni tabella consiste di una o più celle e, come già detto, in ogni cella è possibile che
compaiano testo o immagini.

Dovremmo essere ad un buon punto per iniziare a mettere insieme tutti i tasselli finora
definiti. Utilizzando le associazioni tra le classi che abbiamo descritto otterremo dunque il
seguente Class Diagram che descrive il nostro esempio:

22
è importante rendersi conto che il diagramma precedente non costituisce la massima
descrizione in dettaglio per un processo di scrittura di un documento di testo.
Il modello descritto potrà essere specializzato sempre di più e, quindi, crescere in modo
appropriato per poter consentire un appropriato lavoro di analisi e disegno.

Use Case Diagram


I Class Diagrams forniscono una visione statica delle classi che intervengono nella
creazione di un Sistema. Il tipo di diagramma che andiamo a vedere adesso presenterà,
invece, una visione dinamica e mostrerà come il sistema e le relative classi cambino con il
passare del tempo.
La visione statica aiuta gli analisti nella comunicazione con il cliente. La visione dinamica
del Sistema, d’altra parte, fornisce agli analisti un valido mezzo per instaurare un dialogo
chiaro con il team degli sviluppatori ed aiuta gli sviluppatori stessi a creare i programmi.
Esattamente come il Class Diagram rappresenta un ottimo modo per stimolare il cliente a
parlare sul sistema dal suo punto di vista, lo Use Case Diagram rappresenta un eccellente
strumento per stimolare dei potenziali utenti a intervenire con le loro critiche ed opinioni
sulla funzionalità che il Sistema dovrà avere.
Non è sempre facile per gli utenti riuscire a spiegare tecnicamente come essi intendano
costruire il sistema desiderato; infatti, accade sempre più spesso che essi in realtà
sappiano esprimersi meglio dal punto di vista pratico che non dal punto di vista prettamente
tecnico. LoUse Case (Caso d’uso) è allora lo strumento ideale per aitare a “rompere il
ghiaccio”.
Le interviste con gli utenti iniziano facendo uso della terminologia del dominio ma poi
deviano ed utilizzano la terminologia del cliente. I risultati iniziali delle interviste devono
portare alla definizione di Actors (attori) e use cases ad alto livello che descrivano i

23
requisiti funzionali in termini generali. Già questa informazione è in grado di fornire i limiti e
gli scopi del sistema che si intende sviluppare.
Nelle interviste successive con gli utenti si cercherà di approfondire maggiormente tali
requisiti, portando così alla definizione di modelli use case che soddisfino le relazioni di
inclusione e estensione.
In questa fase è importante la comprensione del dominio, poiché se si hanno lacune in tal
senso potrebbe accadere che si sviluppino troppi use cases e che ciò possa provocare un
rallentamento nel processo di analisi.
Gli Use Case sono collezioni di scenari che riguardano l’utilizzo del sistema in cui ogni
scenario descrive una sequenza di eventi.
La sequenza di eventi descritta da uno Use Case viene iniziata da una persona, o da un
altro sistema o da un pezzo di hardware o ancora dal passare del tempo. Le entità che
iniziano la sequenza di eventi sono definiti Actors. Il risultato della sequenza deve portare a
qualcosa di utile all’actor che ha iniziato la sequenza o, anche, ad un differente actor.
è anche possibile riutilizzare gli use cases. Per far ciò si possono usare due modi:

 Inclusion: Questo modo permette di utilizzare i passi appartenenti ad una sequenza di un use
case e inglobarli in un altro use case.
 Extension: tramite questo metodo è possible creare un nuovo use-case semplicemente
aggiungendo dei passi ad un use case esistente.
Vedremo ora come rappresentare un modello Use Case e visualizzare le relazioni tra più
use cases.

Introduzione Use Case Model


Un actor inizia la sequenza di un particolare use case, ed un actor (possibilmente lo stesso
che ha iniziato, ma non necessariamente) riceve un ritorno dallo use case.

Graficamente, un ellisse rappresenta un use case ed un omino rappresenta un actor.


L’actor che inizia la sequenza di eventi di un use-case viene sempre inserito alla sinistra
dell’use case mentre, al contrario, l’actor che riceve gli effetti causati dalla sequenza
scatenata dall’use case stesso, viene disegnato alla destra.
Il nome dell’actor appare appena sotto la raffigurazione dello stesso actor mentre il nome
dell’Use Case appare o dentro l’ellisse o appena al di sotto di esso. Una linea di
associazione, infine, connette un actor all’use case e rappresenta la comunicazione tra

24
l’actor e lo use case. La linea di associazione è una linea continua, simile a quella che
connette due classi in associazione tra loro.
Come detto, ogni use case è una lista di scenari, ed ogni scenario è una sequenza di passi.
Per ciascun use case, ogni scenario avrà la sua propria pagina rappresentata nel seguente
modo:

 Un actor che dà inizio alla sequenza dell’use case


 Le Pre condizioni per lo use case
 I passi dello scenario vero e proprio
 Le Post Condizioni quando lo scenario è completo
 L’actor che beneficia dell’use case
Gli Use Case Diagram danno del valore aggiunto alla raccolta di informazioni. Essi
visualizzano gli use case, facilitano la comunicazione tra gli analisti e gli utenti e tra gli
analisti ed il cliente.

Relazioni tra uses cases


Quando abbiamo iniziato a parlare di Use Case Diagrams, abbiamo detto che è possibile il
riutilizzo di un Use Case Diagram e si è detto che ciò era fattibile utilizzando due modi:
tramite l’inclusion e tramite l’extension.
L’inclusion e la extension rappresentano una sorta di relazioni tra use case. In effetti,
esistono anche altri due tipi di relazioni applicabili agli Use Cases :
le generalizzazione(Generalization) e il raggruppamento (Grouping).
Ma, proviamo a definire meglio tutte e quattro queste relazioni:
Inclusion
L’inclusion permette il riutilizzo di un use case all’interno di un altro use case. Per
rappresentare graficamente una inclusion, si utilizza il simbolo utilizzato per la dipendenza
tra classi – una linea tratteggiata che connette le classi con una freccia che punta sulla
classe da cui dipende l’altra classe. Appena sotto questa linea, si aggiunge uno stereotipo
– la parola <<include>> racchiusa, come si vede, tra doppie parentesi formate dai simboli
“<<” e “>>”
Extension
L’extension permette di creare un nuovo use case aggiungendo dei passi in più ad un use
case già esistente.
Anche qui una linea tratteggiata con una freccia finale viene utilizzata per rappresentare
l’extension, insieme con uno stereotipo che mostra la parola <<extends>> tra parentesi.
All’interno dell’use case base, il punto di extension appare sotto il nome dell’use case
stesso.
Generalization
Le classi, come abbiamo visto, possono ereditare le caratteristiche di un’altra classe
(classe padre). Allo stesso modo, tale ragionamento è applicabile agli use case. Nella
eredità tra use case, lo use case figlio eredita il comportamento ed il significato dal padre
ed in più aggiunge le sue caratteristiche specifiche. Anche in questo caso vale lo stesso
ragionamento applicato nel caso delle classi: e’ possibile applicare lo use case figlio,

25
laddove è possibile applicare il padre.
La Generalization viene rappresentata allo stesso modo con cui viene rappresentata per le
classi – ovvero con una linea continua che ha un triangolo aperto che punta al padre.
La relazione di Generalization può esistere anche tra actors.
Grouping
In alcuni use case diagrams, ci potrebbero essere molti use case e, magari, si
desidererebbe organizzare il diagramma in modo migliore. Una tale situazione si può
verificare quando si sta progettando un sistema che consiste di più sottosistemi.
Il modo più semplice è di organizzare a gruppi gli use case che in qualche modo siano
correlati (qualcosa di simile ad un tabbed folder).

Use Case Diagram


In questo esempio si cercherà di modellare, tramite gli use case diagrams, una macchina
self-service per alimenti e bevande. La principale funzione di una siffatta macchina è,
ovviamente, quella di permettere ad un utente di acquistare un prodotto alimentare
(cioccolata, succo di frutta, ecc.). Ogni utente che interagisca con la macchina potrà,
certamente, dire che la principale funzione (e quindi il principale use case) della macchina
stessa potrà essere definita come : “Acquisto di un prodotto”.
Proviamo ad esaminare ogni possibile scenario all’interno di questo use case. Gli scenari
che ne derivano saranno, naturalmente, scaturiti dalle conversazioni con l’utente.
Lo use case “Acquista un prodotto”
L’actor in questo use case è il cliente. Il cliente vuole comprare alcuni dei prodotti offerti
dalla macchina self-service. Per prima cosa egli dovrà inserire delle monete all’interno della
macchina, poi selezionare il tipo di prodotto (o più di uno, se la macchina lo consente) e
quindi ricevere dalla macchina la lista dei prodotti scelti prima di procedere all’acquisto vero
e proprio. Lo use case per tale tipo di scenario può essere il seguente:

Ma, se ci si pensa un attimo più approfonditamente, vengono alla mente altri tipi di scenari.
è possibile che la macchina self-service non sia in grado, ad un certo momento, di fornire
uno o più prodotti oppure che la macchina non abbia a disposizione l’esatto numero di
monete per fornire il resto al cliente.
Ci si deve chiedere: Ci è stato chiesto di gestire questi tipi di scenari?
Se la risposta è affermativa, torniamo un attimo indietro al momento in cui il cliente
inserisce le monete nella macchina ed effettua la selezione. Supponiamo allora che la
macchina, a questo punto, non sia in grado di soddisfare la richiesta del cliente. In tal caso
sarà preferibile presentare un messaggio al cliente che lo informi che la macchina non ha
come disponibile il prodotto scelto e che permetta al cliente stesso di effettuare una nuova
scelta o richiedere la restituzione delle monete.
Se, invece, si è verificato lo scenario in cui è stato fornito un errato ammontare di monete,
si suppone che la macchina restituirà l’importo originale di soldi al cliente. La
precondizione, in tal caso, è il cliente (affamato o assetato!) e la post condizione è il
prodotto acquistato o la restituzione dei soldi.

26
Quanto descritto rappresenta lo scenario di un use case dal punto di vista di un utente (e
quindi di un actor). Ma potrebbero esserci anche altri tipi di actors. Per esempio, un
fornitore di prodotti deve essere in grado rifornire la macchina e il proprietario della
macchina deve poter recuperare le monete accumulate. Questo ci induce a creare almeno
altri due use case che chiameremo: “Ricarica la Macchina” e “Ritira le Monete”. Andiamo
ad esaminarli entrambi simulando un’ intervista con il fornitore e con il proprietario.
Lo use case “Ricarica la Macchina”
Le azioni che un fornitore dovrà compiere ad intervalli di tempo regolari (diciamo una o due
settimane) sono:

 Il fornitore disattiva la macchina


 Apre il contenitore dei prodotti
 Riempie ogni scompartimento fino alla massima capacità (Si potrebbe anche supporre che il
fornitore riempia la macchina tenendo conto delle maggiori preferenze dei clienti)
 Alla fine, il fornitore chiude il contenitore dei prodotti e riattiva la macchina
In questo caso, potremmo dire che la precondizione è rappresentata dal trascorrere
dell’intervallo di tempo tra una ricarica e l’altra e la post condizione è data dal fatto che il
fornitore ottiene un nuovo insieme di potenziali clienti.
Lo use case diagram, in questo caso, è rappresentato dalla seguente figura:

Lo use case “Ritira Le Monete”


Il responsabile per questo Use Case è il proprietario della macchina. In effetti, tuttavia,
questi potrebbe coincidere con il fornitore. I passi che il proprietario della macchina deve
fare sono uguali a quelli del fornitore ma la differenza consiste nel fatto che il proprietario
non ha a che fare con i prodotti ma con i soldi.
Quando l’intervallo di tempo tra un ritiro e l’altro è trascorso, il proprietario della macchina
ritira l’ammontare di monete che si è depositato nella macchina
La post condizione, in tal caso, è rappresentata dai soldi ritirati dal proprietario.
Lo use case che descrive tale scenario è, dunque, rappresentato nella figura seguente:

Molti dei passi necessari allo Use Case “Ritira le monete” (disattivare la macchina, aprire il
contenitore, ecc.) sono uguali a quelli visti per lo use case “Ricarica la macchina”. Questo è
un buon motivo per avvalerci dell’utilizzo dell’inclusion. Combiniamo allora i due passi:
Disattiva la macchina e apre il contenitore in uno use case che denominiamo: “Disattiva la
macchina”. Alla stessa maniera definiamo un nuovo Use case che chiamiamo “Riattiva la
Macchina” che inglobi i passi di chiudere il contenitore e riattivare la macchina.
Otterremo:

27
Cerchiamo ora di raffinare ulteriormente i nostri use cases.
Lo use case “Ricarica la macchina” potrebbe essere la base per un altro use case:
“Ricarica la macchina in base alle vendite”. Qui, il fornitore può riempire gli scompartimenti
non più in modo uniforme per ogni prodotto ma in base alle vendite dei singoli prodotti.
Questo rappresenta un buon esempio di extension di un use case.Dopo l’inclusion e
l’extension così definiti, lo use case “Ricarica la macchina” può diventare:

28
Possiamo anche utilizzare la generalizzazione guardando gli actors: fornitore e proprietario.
Sarà possibile definire un Actor più generico (Agente del Fornitore) che inglobi molte delle
caratteristiche del Proprietario e del Fornitore.
Tale generalizzazione è mostrata nella figura che segue:

Un esempio di generalizzazione di un Actor

La figura sopra mostra il diagramma finale completo per la macchina self service.

29
State Diagram
Descriveremo, adesso, elementi che non abbiamo ancora mai esaminato. Tali elementi
sono detti elementi comportamentali e mostrano come varie parti di un diagramma UML
possano cambiare nel tempo.
Allo stesso modo in cui un sistema interagisce con gli utenti e, possibilmente, con altri
sistemi, così gli oggetti che costituiscono il sistema stesso passano attraverso i necessari
cambiamenti che servono a favorire le interazioni.
Se si sta modellando un sistema, è necessario avere un meccanismo che gestisca le
modifiche all’interno del modello stesso. Tale meccanismo, in UML, è rappresentato
dagliState Diagrams.
Per esempio, quando si preme un interruttore, una lampada cambia il suo stato da spento
ad acceso (o viceversa). Oppure, ancora, quando si preme un tasto della tastiera o si
muove il mouse durante il funzionamento di uno screen saver sul computer, il computer
abbandona la modalità di screen saver e ritorna a funzionare regolarmente in modo attivo.
Gli State Diagrams visualizzano gli stati che un oggetto può attraversare e i passaggi
transitori che intercorrono tra questi stati. Inoltre gli State Diagrams mostrano il punto di
partenza e il punto di arrivo di una sequenza di cambi di stato.
Definizione: Uno State Diagram mostra gli stati di un singolo oggetto.
Veniamo alla rappresentazione grafica. Gli stati di uno State Diagram sono rappresentati
con un rettangolo con gli angoli arrotondati. Il simbolo che mostra la transizione da uno
stato ad un altro viene disegnato utilizzando una linea continua che termina con una
freccia.
Un cerchio nero pieno rappresenta il punto di partenza di una sequenza di stati mentre il
punto di arrivo viene rappresentato da due cerchi concentrici in cui il più interno è riempito
di nero (tale figura viene anche definita “occhio di bue”).

Nella figura precedente si può vedere un esempio di quanto detto. Inoltre, come si può
notare, è possibile aggiungere maggiori dettagli alla figura stessa dividendo il rettangolo in
tre aree separate.
L’area in alto contiene il nome dello stato, l’area centrale contiene le variabili di stato
(timers, contatori, date, ecc.) e l’area in basso rappresenta le attività (cioè quello che
accade quando il sistema entra in un determinato stato e cosa, invece, succede quando il
sistema abbandona quello stato.

30
Dettagli di Stato e Transizioni
è possibile indicare sugli State Diagram un evento che causa il verificarsi di una transizione
(un evento trigger) e l’azione che viene eseguita che fa sì che il cambio di stato possa
avvenire.
Per aggiungere graficamente eventi e azioni si scrive vicino la linea di transizione una
descrizione di essi, utilizzando una barra per separare un evento di trigger da un’azione.
Qualche volta può accadere che un evento causi una transizione senza azioni associate e,
qualche altra volta una transizione si verifica perchè uno stato completa un’attività (piuttosto
che a causa di un evento). Questo tipo di transizione viene chiamata transizione senza
trigger (triggerless transition).
è anche possibile inserire una condizione di controllo (guard condition). Quando la si
incontra, la transizione ha luogo. (Per esempio lo screen saver viene attivato quando
l’intervallo di tempo di x minuti viene raggiunto).
Gli State Diagrams consentono, inoltre, di definire degli stati all’interno di altri stati. In tal
caso, gli stati interni verranno definiti sotto-stati (substates) i quali, a loro volta, possono
essere disinti in sottostati sequenziali e sottostati concorrenti
I primi, come si evince dal nome stesso, rappresentano una sequenza di stati che vengono
raggiunti uno susseguentemente all’altro. I sottostati concorrenti, invece, rappresentano
due o più sottostati sequenziali che si verificano allo stesso tempo. Tutto ciò viene
rappresentato graficamente con una linea tratteggiata tra gli stati concorrenti. Per
comprendere meglio questi concetti, comunque, si faccia riferimento all’esempio del
paragrafo successivo.
L’UML fornisce un simbolo che mostra che uno stato composto ricorda i suoi attivi sottostati
quando l’oggetto effettua transizioni fuori dallo stato composto. Il simbolo usato è:

unito da una linea continua ai sottostati “ricordati”, con una freccia che punta al sottostato
opportuno.
Un messaggio che causa una transizione in un oggetto dello State Diagram (che riceve il
messaggio stesso) viene chiamato segnale (signal).
Nel mondo orientato agli oggetti, il mandare un segnale viene visto allo stesso modo come
la creazione di un oggetto Segnale e la trasmissione di questo ad un oggetto Ricevente.
L’oggetto Segnale può avere delle proprietà che saranno rappresentate da attributi.
Infine, poiché un segnale è un oggetto, è anche possibile creare gerarchie di ereditarietà di
segnali

State Diagram - Esempio Pratico


Supponiamo di voler creare un modello che descriva il funzionamento di un tostapane.
Ovviamente, rivolgiamo la nostra attenzione agli state diagram che un simile sistema può
avere.
Quali sono i passi perchè un tostapane riesca a preparare un toast?

31
Per prima cosa bisognerà accendere il tostapane, quindi mettere le fette di pan carrè
all’interno di esso ed attendere alcuni minuti perchè sia cotto il toast. Lo state diagram
iniziale sarà, dunque:

Ma quello rappresentato non è il diagramma finale. Per prevenre che il toast si bruci, la
resistenza del tostapane deve produrre calore che non superi determinati valori di
temperatura. Naturalmente, perchè il toast si cuocia a dovere è necessario anche che la
temperatura non vada al di sotto di un certo valore minimo.
Per tale ragione un termometro misura la temperatura prodotta dalla resistenza e quando il
limite massimo viene raggiunto la resistenza passa in uno stato di attesa e non emette altro
calore. Tale stato perdura finché la temperatura decresce fino ad arrivare al valore minimo.
A questo punto ritorna lo stato di “In Lavorazione”. Con questi ulteriori dettagli, il nostro
State Diagram diverrà:

Ma per descrivere la transizione tra lo stato di “In Lavorazione” e lo stato “Inattivo” è


necessario aggiungere dei sottostati al diagramma, come mostrato nella prossima figura:

Si può notare che gli stati “In Lavorazione ” e “Inattivo” sono molto simili. Entrambi devono
misurare e comparare gli stati ma si differenziano nel processo di confronto della
temperatura. Infatti, lo stato di “In Lavorazione” deve comparare la temperatura corrente
con la temperatura limite superiore (se viene raggiunta allora si passa allo stato “Inattivo”) e
lo stato “Inattivo” confronta la temperatura corrente con la temperatura limite inferiore (lo
stato “Inattivo” viene rimpiazzato dallo stato di “In Lavorazione” quando accade che la
temperatura scende al di sotto del limite).
è utile utilizzare gli State Diagrams perché essi aiutano gli analisti, i disegnatori e gli
sviluppatori a capire il comportamento degli oggetti in un sistema. Gli sviluppatori, in

32
particolare, devono conoscere come gli oggetti devono comportarsi in quanto è loro
compito tradurre tali comportamenti in software.

Sequence Diagram
Gli State Diagrams, che abbiamo visto nel precedente paragrafo, focalizzano la loro
attenzione sugli stati di un oggetto. Ma è necessario, oltre alla definizione degli stati,
instaurare una comunicazione tra gli oggetti. L’UML, a tale proposito definisce il Sequence
Diagramche, appunto, permette di modellare la comunicazione tra un oggetto ed un altro in
relazione al trascorrere del tempo. Si capisce subito che in questo tipo di rappresentazione
un ruolo cruciale viene svolto dal tempo.
L’idea chiave qui è che le interazioni tra gli oggetti avvengano seguendo un ordine ben
preciso e che tale sequenza avvenga, nel tempo, dall’inizio alla fine.
Il Sequence diagram è costituito da oggetti rappresentati nel modo ormai usuale – come
rettangoli recanti un nome (con il nome sottolineato), messaggi rappresentati da linee
continue recanti una freccia alla loro fine e il tempo rappresentato come progressione
verticale.
Vediamo meglio in dettaglio di analizzare i componenti di un sequence diagram.

I componenti del Sequence Diagram


Oggetti
Gli oggetti sono disegnati vicino la sommità del diagramma e sono disposti in sequenza da
sinistra verso destra. Essi possono essere inseriti in un qualunque ordine che semplifichi la
comprensione del diagramma. Da ogni rettangolo si diparte una linea tratteggiata verso il
basso, denominata “linea della vita” (lifeline). Lungo la lifeline si trova un piccolo rettangolo
chiamato “attivazione” (activation). L’activation rappresenta l’esecuzione di un’operazione di
cui l’oggetto si fa carico. La lunghezza del rettangolo, invece, rappresenta la durata
dell’activation. Tutto questo è mostrato nella figura seguente:

Messaggi
Un messaggio che viaggia da un oggetto ad un altro, viene disegnato a partire dalla lifeline
dell’oggetto da cui parte il messaggio e arriva sulla lifeline dell’oggetto a cui il messaggio è
diretto.
Si può anche verificare il caso in cui un oggetto mandi un messaggio a se stesso, cioè un

33
messaggio che parte dalla sua lifeline e arriva alla stessa lifeline. Tale tipo di
comportamento viene definito Ricorsione.
Nella tabella seguente vengono identificati tutti i possibili messaggi definiti in UML per i
sequence diagrams, ognuno dei quali, come si vede, ha una rappresentazione grafica
differente.

simple Rappresenta il trasferimento del controllo da un


oggetto ad un altro.

synchronous Se un oggetto invia un messaggio sincrono,


allora si attende che gli venga restituita una
risposta al messaggio stesso prima di poter
continuare con altre operazioni.

asynchronous Diversamente dai messaggi sincroni, se un


oggetto invia un messaggio asincrono, non
attende che gli venga inviata alcuna risposta
prima di continuare con altre operazioni

Il Tempo
Il sequence diagram rappresenta il trascorrere del tempo se visto in direzione verticale. Il
tempo, graficamente, viene fatto partire alla base di ogni oggetto e proseguire fino in basso.
Ad esempio, un messaggio che si trovi più vicino all’oggetto rispetto ad un altro (rispetto
alla direzione verticale), si verificherà prima nel tempo.

34
Nei sequence diagram viene utilizzata il simbolo dell’actor per rappresentare l’inizio della
sequenza, ma in realtà tale simbolo (come abbiamo visto quando abbiamo parlato degli
Use Case diagrams) non appartiene all’insieme dei simboli propri del sequence diagram.

Modi di creare Sequenze


In maniera uguale agli use case diagrams in cui è possibile mostrare o un’istanza (uno
scenario) singola di uno use case o, più genericamente, un insieme degli scenari di un use
case, così i sequence diagrams possono essere definiti su una singola istanza oppure
definire un modello più generico.
I sequence diagrams generici forniscono spesso la possibilità di rappresentare delle
istruzioni condizionali (if) e dei cicli while in cui ogni condizione descritta da un if (oppure da
un while) viene racchiusa tra parentesi quadrate (nel caso del while la parentesi quadrata
sinistra viene preceduta da un asterisco). Si veda l’esempio più avanti per maggiore
chiarezza.
Esiste la possibilità, in un sequence diagram, di creare un oggetto. Quando ciò avviene,
l’oggetto creato viene rappresentato nel modo visto finora e cioè con un rettangolo
all’interno del quale viene descritto il nome dell’oggetto.
La differenza, in questo caso, consiste nel fatto che l’oggetto non viene posizionato alla
sommità del sequence diagram come si farebbe con gli altri oggetti ma, piuttosto, lungo la
dimensione verticale che indica il tempo in cui tale oggetto viene creato.
Può accadere, qualche volta, che un oggetto esegua un’operazione che invochi lo stesso
oggetto che l’ha provocata. In tal caso si parla di ricorsione. Ad esempio, si supponga che
uno degli oggetti del sistema sia un calcolatore e che una delle sue operazioni sia il calcolo

35
degli interessi. Al fine di permettere il calcolo per un lasso di tempo che racchiuda parecchi
periodi, l’operazione per calcolare gli interessi deve invocare se stessa diverse volte. Il
sequence diagram nella figura sottostante, mostra tale caso:

Sequence Diagram – Un esempio pratico

Useremo lo stesso esempio visto in precedenza, ovvero quello della macchina Self-
Service.
Definiamo i seguenti tre oggetti della Macchina Self-Service con cui descriveremo il nostro
diagramma:

 La Parte Frontale. – L’interfaccia che la macchina presenta all’utente


 La Cassetta delle monete – La parte in cui vengono accumulate le monete e che gestisce i
vari controlli della macchina
 Il Contenitore dei Prodotti – La parte che contiene gli alimenti che vengono acquistati dal
cliente
Il Sequence Diagram che modelleremo farà uso della seguente sequela di azioni:

 Il cliente inserisce le monete nella macchina


 Il cliente esegue la selezione del prodotto desiderato
 Le monete arrivano nella Cassetta delle Monete
 Il dispositivo di controllo della Cassetta delle monete verifica se il prodotto desiderato è
presente nel Contenitore dei Prodotti
 La Cassetta delle Monete aggiorna la sua riserva di monete
 Il dispositivo di controllo della Cassetta delle Monete informa il Contenitore dei Prodotti che
può espellere il prodotto desiderato dalla Parte Frontale della macchina

36
Si provi, per esercizio, a costruire il Sequence Diagram più complesso che descrive il caso
di situazioni particolari della macchina causati da una quantità di monete errate o dal
prodotto selezionato dall’utente non presente. Nel collaboration Diagram vedremo in
dettaglio anche questi casi.

Collaboration Diagram
I collaboration diagrams rappresentano un tipo di diagramma molto simile a quello
appena visto nei sequence diagram. Infatti, essi mostrano come interagiscono gli oggetti tra
di loro, mettendo in risalto gli oggetti attraverso i quali viaggiano i messaggi che gli stessi
oggetti si scambiano tra di loro. Sorge allora spontanea la domanda: Ma se già i sequence
diagrams realizzano tali operazioni, perché l’UML ha bisogno di un altro diagramma dello
stesso tipo? Non svolgono le stesse funzioni?
In effetti, il sequence diagram e il collaboration diagram sono simili. In particolare, si può
dire che essi sono semanticamente equivalenti. Ovvero, i due diagrammi presentano la
stessa informazione ed è facile convertire un sequence diagram in un collaboration diagram
e viceversa. La principale distinzione tra i due diagrammi, è che il sequence diagram è
costruito seguendo come filo conduttore il tempo mentre il collaboration diagram si basa
sullo spazio.
Un collaboration diagram è un’estensione di un diagramma di oggetti. In più, oltre alle
associazioni tra gli oggetti, esso consente di mostrare i messaggi che essi inviano per
interagire tra di loro.
I messaggi tra gli oggetti sono rappresentati con delle frecce che puntano all’oggetto che
riceve il messaggio stesso. Tali frecce sono posizionate vicino la linea di associazione tra
gli oggetti. Una label vicino la freccia indica la specifica di un messaggio. Un messaggio,
tipicamente, richiede all’oggetto ricevente di eseguire una delle sue operazioni. Una coppia
di parentesi terminano il messaggio; al loro interno si trovano gli eventuali parametri con cui
le operazioni lavorano.
Come detto, i collaboration diagrams possono essere convertiti in sequence diagrams e
viceversa. Per far ciò, però, si deve tenere presente che è necessario aggiungere un
numero alla label di un messaggio che corrisponda all’ordine in cui il messaggio appare
nella sequenza. Il segno dei due punti separa il numero dal messaggio.

37
Scrivere Collaboration Diagram
è possibile mostrare, in un collaboration diagram, il cambio di stato di un oggetto. Si
possono mostrare, inoltre, le condizioni allo stesso modo in cui esse sono rappresentate
all’interno di un sequence diagram.
Nel rettangolo che rappresenta l’oggetto si indica lo stato dell’oggetto stesso. Al
diagramma si aggiunge un altro rettangolo che rappresenta l’oggetto e indica lo stato
modificato. I due rettangoli vengono quindi uniti con una linea recante un’etichetta con uno
stereotipo. La condizione va inserita all’interno di una coppia di parentesi quadre
considerato che la condizione deve precedere l’etichetta del messaggio.
La cosa importante è coordinare le condizioni con una numerazione. Per maggiori
chiarimenti su tale costruzione si veda il paragrafo successivo.
I collaboration diagram permettono anche di modellare la creazione di oggetti; nel
processo di creazione di tali oggetti si inserisce uno stereotipo <<create>> al messaggio
che si occupa della creazione dell’oggetto.
Ancora, nei collaboration diagrams si possono rappresentare oggetti multipli e
visualizzare i risultati restituiti.
La rappresentazione di oggetti multipli viene effettuata tramite uno stack (una pila) di
rettangoli disegnati in sequenza inversa (da destra a sinistra). Si aggiunge una condizione
(circondata da parentesi) e preceduta da un asterisco per indicare che il messaggio deve
giungere a tutti gli oggetti.
I risultati restituiti sono scritti come espressioni in cui il nome dell’espressione è preceduto
dal valore di ritorno e seguito dai segni := . Quindi, si scrivono il nome dell’operazione ed
una lista di possibili attributi che l’operazione può accettare per produrre il risultato finale.
La parte destra dell’espressione appena descritta viene definita firma del messaggio
(message-signature).

In alcune interazioni può accadere che uno specifico oggetto si occupi del controlli del
flusso. Questo oggetto attivo può mandare messaggi ad oggetti passivi ed interagire a sua
volta con altri oggetti attivi. Inoltre, si potrebbe verificare anche il caso di un oggetto che
mandi messaggi soltanto dopo che parecchi altri messaggi (possibilmente non consecutivi)
siano stati inviati. In altre parole, l’oggetto deve sincronizzare il suo messaggio con un
insieme di altri messaggi.
Il collaboration diagram rappresenta un oggetto attivo allo stesso modo di come si è visto
finora con la differenza che i bordi del rettangolo sono spessi e in grassetto.

38
I messaggi sincroni sono preceduti da una lista di messaggi che devono essere completati
prima che il messaggio sincrono possa essere inviato. Una virgola separa un elemento
della lista dall’altro e la lista termina con una barra.
Vediamo ora di mettere insieme tutti i concetti di cui si è parlato e di definire un
collaboration diagram completo.

Collaboration Diagram – Un esempio


Ancora una volta utilizzeremo l’esempio della macchina self-service. Nell’esempio sul
sequence diagram si è già costruito il diagramma per un sistema del genere. Adesso,
proviamo a convertire il sequence diagram in un collaboration diagram.
Lo scenario del caso migliore consiste di diversi passi:

 Il cliente inserisce le monete nella macchina ed esegue le selezione di uno o più prodotti
presenti sulla macchina.
 Quando il dispositivo di introduzione delle monete ottiene la somma dovuta (in questo caso si
suppone che il cliente inserisca il corretto numero di monete necessarie) e vi è la disponibilità
dei prodotti scelti, allora viene espulso dalla macchina il prodotto scelto.
 Il prodotto (o i prodotti) viene espulso dalla parte frontale della macchina in modo che il cliente
possa prelevarli.

Ma, quando si esamina in dettaglio questa macchina ed il lavoro che essa svolge, ci si
rende conto che sono possibili ulteriori scenari:

 Introduzione di un numero errato di monete


 Mancata disponibilità di un prodotto selezionato.
è possibile utilizzare delle condizioni che aiuteranno a descrivere il lavoro della macchina.
Esse vengono visualizzate tra una coppia di parentesi quadre in modo tale che la
condizione preceda l’etichetta del messaggio. La cosa importante è tener presente che
bisogna coordinare le condizioni con la numerazione progressiva.
Nello scenario in cui la macchina non abbia a disposizione il prodotto scelto è necessario
che la macchina visualizzi un messaggio all’utente che gli permetta di selezionare un
prodotto alternativo e ripetere, quindi, il processo oppure di avere restituite le monete. è,

39
naturalmente, possibile descrivere un collaboration diagram anche per il caso in cui si sia
inserito un numero errato di monete.
Il collaboration diagram seguente illustra entrambi i casi
Clicca sull’immagine per ingrandire

Come è possibile vedere dallo schema, sono possibili fondamentalmente due scenari:
Alimento Non Presente e Alimento Presente. Se assumiamo che tale differenziazione
avvenga dopo il messaggio 2: InserimentoMonete(AlimentoSelezionato), il numero
identificativo per questi messaggi sarà 3 per lo scenario Alimento Presente e 5 per lo
scenario Alimento non Presente.
Cosa avviene quando la macchina non ha a disposizione il resto corretto? Essa deve
visualizzare un messaggio, restituire le monete e chiedere al cliente di inserire la quantità
esatta di monete. A questo punto, la transazione è terminata. Quando la macchina ha la
giusta quantità di monete, restituisce il resto al cliente ed espelle il prodotto selezionato.
I due rami che sono prodotti dal processo annidato per il controllo del resto sono
contrassegnati con 3 e 4.
Clicca sull’immagine per ingrandire

Activity Diagram
Probabilmente, molte persone che in passato abbiano preso parte a qualche corso
introduttivo di programmazione ricorderanno i diagrammi di flusso (flowchart). Il flowchart
mostra una sequenza di passi, processi, punti decisionali e rami. I programmatori alle prime
armi sono spesso indotti ad utilizzare i diagrammi di flusso per sviluppare una migliore
logica di programmazione e ricavare delle soluzioni ai problemi software.
L’activity diagram UML è molto simile ai flowchart. Infatti, esso mostra i passi (chiamati,
propriamente, attività), i punti decisionali e i rami che intervengono nel flusso di un
programma. è utile per mostrare cosa accade in un processo di business o in
un’operazione ed è considerato come parte integrante dell’analisi di sistema.

40
Un activity diagram viene disegnato per essere una vista semplificata di cosa accade
durante un’operazione o un processo. Potremmo dire che esso è un’estensione dello state
diagram. Quest’ultimo mostra gli stati di un oggetto e rappresenta le attività come frecce
che si connettono agli stati. L’activity diagram mette in risalto le attività.
Ogni attività è rappresentata da un rettangolo con gli angoli arrotondati – più stretto e più
ovale rispetto alla icona vista nello state diagram. L’elaborazione di un’attività porta al
completamento della stessa e poi avviene un’automatica trasmissione alla successiva
attività. Una freccia rappresenta la transizione da un’attività alla successiva. Anche l’activity
diagram ha un punto di partenza, rappresentato da un cerchio pieno, ed un punto di fine
rappresentato da un occhio di bue..

Costruzione di un Activity Diagram


Cerchiamo ora di capire le varie componenti in dettaglio: le modalità in cui vengono
rappresentate le decisioni, i path concorrenti, i segnali e le swimlanes.
Decisioni
Un punto di decisione può essere rappresentato in due modi. La scelta sulla modalità da
utilizzare è affidata interamente all’analista.
Il primo modo consiste nel mostrare i possibili cammini che derivano direttamente da
un’attività. L’altro modo, invece, consiste nel rappresentare la transizione di un’attività con
un piccolo rombo e far seguire dal rombo stesso tutti i possibili cammini di flusso. Un altro

41
modo ancora stabilisce di indicare la condizione con un’istruzione racchiusa tra parentesi
graffe vicino il path appropriato.
Si immagini di dover recarsi al lavoro. Le fasi che descrivono tale processo saranno: aprire
la macchina, inserire le chiavi nel cruscotto e quindi scegliere tra le seguenti due situazioni:

 La macchina si avvia regolarmente


 La macchina non si avvia
Questi due possibili casi produrranno due altre attività:

 Guidare la macchina
 Recarsi alla fermata del autobus (oppure prendere un taxi, la bicicletta o andare a piedi).
Tale tipo di scenario viene rappresentato nel seguente grafico (si presti attenzione ai due
modi di mostrare una decisione):

Path Concorrenti
Quando si esegue il modellamento di attività, molto frequentemente si verificherà la
necessità di dover separare le transizioni in due cammini separati che vengano eseguiti allo
stesso tempo (concorrentemente).
Una tale suddivisione viene rappresentata da una linea continua in grassetto,
perpendicolare alla transizione e che mostri i cammini che avvengono al di fuori dalla linea
stessa. Per rappresentare un “merge” successivo delle due attività, si fanno convergere i
cammini verso un’altra linea in grassetto.

42
Segnali
Durante una sequenza di attività, è possible inviare un segnale. Quando viene ricevuto, il
segnale causa la creazione di un’attività.
Il simbolo per inviare un segnale è un pentagono convesso, mentre il simbolo per
rappresentare il segnale ricevuto è un poligono concavo.
Swimlanes
L’activity diagram definisce anche la possibilità visualizzare i ruoli. Per far ciò, si separa il
diagramma in segmenti paralleli, chiamati swimlanes (corsie di nuoto). Ogni swimlane
mostra il nome di un determinato ruolo in cima e mostra le attività di quel ruolo. Le
transizioni possono anche coinvolgere due swimlane.
è possibile combinare l’activity diagram con i simboli di altri diagrammi e così produrre un
diagramma ibrido.

Interfacce e Componenti:
Approfondimento
Si è visto, finora, come i diagrammi descritti abbiano a che fare, in generale, con entità
concettuali. Adesso si vedranno, invece, diagrammi UML che rappresentano entità del
mondo reale: i componenti software (software component).
Innanzitutto: cos’e’ un software component? Nient’altro che una parte fisica di un sistema.
Esso risiede in un computer e non nella mente di un analista.
Come si possono relazionare un componente ed una classe?
Basta pensare ad un componente come all’implementazione di una classe. La classe

43
rappresenterà un’astrazione di un insieme di attributi ed operazioni. Ed un componente può
essere visto come l’implementazione effettiva di una classe.
è importante modellare i componenti e le relazioni che intercorrono tra di essi, in quanto :

 I clienti possono vedere la struttura del sistema terminato


 Gli sviluppatori hanno una struttura alla quale rifarsi e attorno alla quale incentrare il loro
lavoro
 Coloro che si occupano di scrivere la documentazione e i file di help si rendono conto meglio
della funzionalità del sistema e quindi riescono a creare dei documenti più efficienti.
Quando si ha a che fare con i componenti, inevitabilmente si deve avere a che fare con le
lorointerfacce. Un’interfaccia, come abbiamo visto, rappresenta la “faccia” dell’oggetto
verso il mondo esterno in modo tale che altri oggetti possano chiedere all’oggetto che
espone l’interfaccia di eseguire le sue operazioni che sono nascoste dall’incapsulamento.
Per l’analista che si occupa di disegnare il modello questo si traduce nel fatto che il modo in
cui si rappresenta un’interfaccia per una classe è lo stesso del modo in cui si rappresenta
un’interfaccia per un componente. La relazione tra un’interfaccia e una classe (anche qui
allo stesso modo) viene detta realizzazione (si veda quanto detto nel paragrafo Interfacce
e Realizzazioni).
è possibile rimpiazzare un componente con un altro se il nuovo componente è conforme
alle stesse interfacce del vecchio. Il riutilizzo di un componente di un altro sistema è
possibile se il nuovo sistema può accedere al componente stesso attraverso le sue
interfacce.
Fondamentalmente, dal punto di vista della modellazione UML, ci sono tre tipi di
componenti:

 Deployment components. Che rappresentano la base dei sistemi eseguibili (DLL, eseguibili,
Controlli Active X, Java Beans).
 Work Product Components: dai quali vengono creati i deployment components (e quindi: file
di dati e file sorgenti)
 Execution Components, creati come risultato del sistema in esecuzione
Infine, diciamo che quando un componente accede ai servizi di un altro componente utilizza
un interfaccia di import. Viceversa, il componente che realizza l’interfaccia con dei servizi
fornisce una interfaccia di export.

Component Diagram
La principale icona di un component diagram è un rettangolo che, a sua volta, comprende
due rettangoli più piccoli incastrati nel suo lato sinistro.Il nome del componente va inserito
all’interno del rettangolo principale. Se il componente è un elemento di un package, è
consigliabile far precedere il nome del componente dal nome del package.

44
Un componente e le interfacce che esso utilizza sono rappresentabili in due modi:

 Mostrando l’interfaccia come un rettangolo che contiene l’informazione relativa all’interfaccia. Il


rettangolo è connesso al componente tramite una linea tratteggiata e un rettangolo che
visualizza la realizzazione dell’interfaccia.
 Utilizzando un piccolo cerchio connesso al componente tramite una linea continua che
rappresenta la relazione di realizzazione dell’interfaccia.

Modo 1: Un’interfaccia può essere rappresentata come un rettangolo, connesso al


componente tramite una linea tratteggiata che termina con una freccia.

Modo 2: Un’interfaccia può essere rappresentata anche come un piccolo cerchio,


connesso al componente tramite una linea tratteggiata che termina con una freccia

Component Diagram: Un esempio


Si supponga di voler costruire un software per ascoltare della musica registrata su un CD-
ROM. Per la scrittura di un siffatto programma ci si potrebbe avvalere di un linguaggio di
programmazione visuale come il Visual C++ o il Visual Basic, per esempio. Se il linguaggio
utilizzato supporta dei controlli multimediali, allora potremo usarli direttamente od
eventualmente riprogrammarli se necessario. O, ancora, potremmo programmare dei nuovi
componenti.
Un possibile disegno grafico per il nostro CD-player potrebbe essere:

45
Come è possibile vedere il programma necessita dei seguente controlli:

 play
 stop
 eject
 pause
 fast forward
 rewind
 power
Tali controlli saranno realizzati con l’utilizzo di bottoni, appositamente utilizzati per ciascuno
di essi. Se si guarda ad ognuno dei bottoni come dei componenti separati, possiamo
ricavarne un component diagram UML.

Come si vede, tutti i componenti mostrati nel diagramma appartengono ad un unico


componente globale, il Bottone, anche se le azioni che essi eseguono sono differenti. Tali
azioni saranno ottenute programmandole una ad una.

Deployment Diagram
Nessun sistema software potrebbe mai funzionare correttamente se non si basasse su una
solida struttura hardware. Per tale motivo, il Deployment Diagram modella proprio questo
aspetto del sistema.
Riesaminando un attimino il cammino fatto si può notare come siamo partiti da elementi di
analisi, poi siamo passati ai componenti che vivono nei computer ed ora passiamo
all’hardware che vive nel mondo reale.
Come detto, l’hardware è un elemento primario nella composizione di un sistema a
multicomponenti. L’UML fornisce dei simboli che hanno il compito di favorire la creazione di
un quadro chiaro di come il settaggio e la composizione finale dell’hardware dovrà essere.

46
L’elemento principale dell’hardware è costituito da un nodo (node), che costituisce un
nome generico per ogni tipo di risorsa hardware.
Sono definiti due tipi fondamentali di nodi:

 Il processore, ovvero un nodo che può consentire l’esecuzione di un componente


 Un device, un nodo che tipicamente si interfaccia con il mondo esterno, e che non può,
invece, eseguire alcun componente.
Vediamo ora gli elementi grafici UML del deployment diagram.
Un cubo rappresenta un nodo. Un nodo ha un suo nome ed è possibile anche usare uno
stereotipo per indicare il tipo di risorsa che esso rappresenta. Se un nodo fa parte di un
package, allora il nome del package deve precedere il nome del nodo. Una linea che
unisce due cubi rappresenta una connessione tra i due nodi.
è possibile usare anche uno stereotipo anche per fornire informazioni sulla connessione.

(la rappresentazione di un nodo come avviene nel Deployment Diagram)


Ogni nodo comprende alcuni dei componenti schierati nel sistema. Per indicare tali
componenti si inserisce una relazione di dipendenza tra essi e il nodo cui appartengono.
Vediamo, per esempio, di costruire un deployment diagram per un sistema informatico
domestico. Il computer consiste dei seguenti elementi hardware:

 Una CPU
 Un monitor
 Una stampante
 Un mouse
 Una tastiera
Per quanto concerne il software potremo avere, ad esempio:

 Windows 98
 Office 2000
 Internet Explorer 5.0
 Front Page
 Dos,
 Norton Commander
 Visual C++

47
Il nodo principale è rappresentato dalla CPU che, a sua volta, è composto di svariati
componenti software collegati tra di loro da opportune relazioni. Gli altri elementi hardware
sono i devices connessi all’unità centrale.
Si può estendere questo diagramma aggiungendo un modem ed una connessione ad
Internet. Si provi, come esercizio a ridisegnare il diagramma con tale estensione.
I deployment diagram si rivelano particolarmente utili nel disegno e nel modellamento di reti
di calcolatori.

Deployment Diagram: Un esempio


Se si ha familiarità con le reti di calcolatori questi concetti saranno banali. In caso contrario,
sarà utile spendere qualche parola per comprendere meglio l’esempio.
La thin Ethernet è una rete di calcolatori molto comune. Essa viene utilizzata in luoghi
circoscritti, come stanze o palazzi, dove la connessione dei cavi può essere facilmente
realizzata. Ci sono alcuni calcoli matematici necessari per definire la lunghezza dei cavi di
tutta la rete e la lunghezza dei cavi che connettono due computer. Tali calcoli, comunque,
non sono importanti per la realizzazione del deployment diagram.

I Computer si connettono al cavo di rete tramite dei dispositivi di connessione chiamati T-


connectors. I T-connectors hanno tre punti di connessione e la loro forma (da cui deriva il
nome) è simile alla lettera T (vedi figura).

48
Il cavo di rete entra da un lato del connector ed esce dall’altro opposto mentre il terzo punto
di connessione va direttamente al computer.
Poiché la lunghezza della rete è limitata, I punti finali del cavo necessitano di particolari
dispositivi denominati terminatori (Terminator).
Una rete locale può, a sua volta, essere connessa ad un’altre rete locale tramite un
ripetitore, ovvero di un dispositivo che amplifica il segnale per ridurre il rischio di perdita di
segnale.

Ora che abbiamo definito I capisaldi di una rete thin Ehernet siamo in grado di disegnarne il
relativo Deployment Diagram:

49
Simboli Grafici di UML
Abbiamo incontrato parecchi simboli grafici nei diagrammi UML visti. Sarà, sicuramente,
utile fare un riepilogo di tutti questi simboli che costituiscono, oggi, uno standard sempre più
diffuso nell’analisi progettuale.
Elementi Strutturali

Elementi Comportamentali

Relazioni

Raggruppamento

Estensioni
<<Stereotipo>>
{Constraint}
Annotazioni ed Actor

50