UML Ita

Introduzione a UML
Angelo Di Iorio
(dal materiale di Gian Piero Favini e Sara Zuppiroli)
A.A. 2010-2011
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 1 / 42
Modellare
Un modello è un’astrazione che cattura le proprietà salienti

della realtà che si desidera rappresentare.
Idealizza una realtà complessa, individuandone i tratti
importanti e separandoli dai dettagli, facilitandone la
comprensione.
La mente umana compie un’attività continua di
modellazione, producendo schemi per comprendere e
spiegare quello che viene percepito dai sensi.
La realtà è un’istanza del modello.

Perché Modellare
Per comprendere il soggetto in analisi.

Per conoscere il soggetto in analisi (fissando ciò che si è
compreso).
Per comunicare la conoscenza del soggetto.
I progetti software sono complessi

Il tipico progetto software raramente coinvolge un solo
sviluppatore, e può coinvolgerne anche centinaia:
� separare compiti e responsabilità
� raggruppare le informazioni a diversi livelli di granularità
Il tipico progetto software subisce un ricambio di personale
nel corso della sua storia:
� il progetto perde conoscenza
� nuovi sviluppatori devono acquisirla
Le caratteristiche del progetto spesso mutano col tempo:
� necessità di comunicare con il cliente in termini chiari
� prevedere ed adattarsi ai cambiamenti
� stimarne l’impatto su costi, tempi e risorse di sviluppo
Come si può ragionare su questo se non si sa su cosa si sta
ragionando?
I linguaggi di modellazione
Un linguaggio di modellazione fornisce le primitive a cui

ricondurre la realtà in esame.
Permette di esprimere le entità che compongono un
sistema complesso, le loro caratteristiche e le relazioni
che le collegano.
Nell’ambito di un progetto, il linguaggio di modellazione è
normalmente distinto dal processo di sviluppo:
� il linguaggio descrive cosa deve essere ottenuto;
� il processo descrive i passi da intraprendere per ottenerlo;
� insieme, linguaggio e processo definiscono un metodo di
sviluppo.
Che cos’è UML (1)

UML, Unified Modeling Language, è un linguaggio
semiformale e grafico (basato su diagrammi) per
specificare, visualizzare, costruire e documentare gli
artefatti di un sistema software.
Permette di:
� modellare un dominio
� scrivere i requisiti di un sistema software
� descrivere l’architettura del sistema
� descrivere struttura e comportamento di un sistema
� documentare un’applicazione
� generare automaticamente un’implementazione
Gli stessi modelli UML sono quindi artefatti usati per
sviluppare il sistema e comunicare con il cliente (ma anche
con progettisti/sviluppatori/etc.)

Che cos’è UML (2)
Si tratta di un linguaggio di modellazione usato per capire e

descrivere le caratteristiche di un nuovo sistema o di uno
esistente.
Indipendente dall’ambito del progetto.
Indipendente dal processo di sviluppo.
Indipendente dal linguaggio di programmazione (progettato
per essere abbinato alla maggior parte dei linguaggi
object-oriented).
Fa parte di un metodo di sviluppo, non è esso stesso il
metodo.
L come Linguaggio
Si tratta di un vero e proprio linguaggio, non di una

semplice notazione grafica.
Un modello UML è costituito da un insieme di elementi che
hanno anche una rappresentazione grafica.
Il linguaggio è semiformale perché descritto in linguaggio
naturale e con l’uso di diagrammi, cercando di ridurre al
minimo le ambiguità.
Ha regole sintattiche (come produrre modelli legali) e regole
semantiche (come produrre modelli con un significato).

Sintassi e semantica: esempio
Chiedi prestito
Cliente Banca
Usiamo un semplice diagramma dei Casi d’Uso come

esempio.
Regola sintattica: una relazione tra un attore e un caso
d’uso può opzionalmente includere una freccia.
Regola semantica: la freccia significa che la prima
interazione si svolge nel senso indicato dalla freccia.
U come Unificato
UML rappresenta la sintesi di vari approcci metodologici

fusi in un’unica entità.
L’intento era di prendere il meglio da ciascuno dei diversi
linguaggi esistenti e integrarli. Per questo motivo, UML è un
linguaggio molto vasto.
Questa è una delle critiche principali mosse a UML ("vuole
fare troppe cose").

Breve storia (1)
Agli inizi degli anni ’90 vi era una proliferazione di linguaggi
e approcci alla modellazione object-oriented. Mancava uno
standard accettato universalmente per la creazione di
modelli software.
C’era la sensazione che la quantità di differenti soluzioni
ostacolasse la diffusione dello stesso metodo
object-oriented.
Nel 1994 due esperti di modellazione della Rational
Software Corporation, Grady Booch e James Rumbaugh,
unificarono i propri metodi, Booch e OMT (Object
Management Technique).
Nel 1995 si unisce anche Ivar Jacobson con il suo OOSE
(Object Oriented Software Engineering), dopo l’acquisizione
della sua compagnia Objectory da parte di Rational.
Breve storia (2)

Nel 1996, Booch, Rumbaugh e Jacobson, noti come i Three
Amigos, sono incaricati da Rational di dirigere la creazione
dell’Unified Modeling Language.
Nel 1997, la specifica UML 1.0 viene presentata all’OMG
(Object Management Group), un consorzio di grandi
aziende interessate allo sviluppo di standard e tecnologie
basate su oggetti.
Nel novembre dello stesso anno, una versione arricchita,
UML 1.1, viene approvata dall’OMG.
Seguono aggiornamenti: 1.2 (1998), 1.3 (1999), 1.4 (2001),
1.5 (2003), e la major revision 2.0 (2005).
L’ultima versione è la 2.3 rilasciata a maggio 2010.

Object-oriented
UML non è solo un linguaggio per la modellazione, ma un

linguaggio per la modellazione orientata agli oggetti.
Questo include sia l’analisi che la progettazione orientata
agli oggetti (OOA e OOD, rispettivamente):
� analisi: capire cosa deve fare il sistema, senza occuparsi
dei dettagli implementativi
� progettazione: capire come il sistema raggiunge il suo
scopo, come viene implementato
UML offre strumenti di modellazione OO in entrambi gli
ambiti; frammenti differenti di UML sono impiegati in diverse
fasi del processo di sviluppo (anche se UML stesso non
fornisce indicazioni sul suo utilizzo).
Object-oriented
OO: un paradigma che sposta l’enfasi della

programmazione dal codice verso le entità su cui esso
opera, gli oggetti.
Una rivoluzione copernicana cominciata dagli anni ’60 e
proseguita, lentamente, fino ad affermarsi negli anni ’90.
I principi cardine furono proposti separatamente e solo
successivamente integrati in unico paradigma.
Principi OO comunemente accettati sono: Abstraction,
Encapsulation, Inheritance, Polymorphism.

Principi OO
Abstraction : usare classi per astrarre la natura e le

caratteristiche di un oggetto, che è un’istanza della propria
classe di appartenenza.
Encapsulation : nascondere al mondo esterno i dettagli
del funzionamento di un oggetto; gli oggetti hanno accesso
solo ai dati di cui hanno bisogno.
Inheritance : classi possono specializzare altre classi
ereditando da esse e implementando solo la porzione di
comportamento che differisce.
Polymorphism : invocare comportamento diverso in
reazione allo stesso messaggio, a seconda di quale oggetto
lo riceve.
Meta-Object Facility
Si può dire che in UML tutto è un oggetto.

La relazione classe/istanza costituisce le fondamenta
stessa del linguaggio.
UML stesso, il linguaggio, è un’istanza!
UML fa parte di un’architettura standardizzata per la
modellazione di OMG chiamata MOF (Meta-Object Facility).
Si può vedere MOF come un linguaggio per creare
linguaggi, uno dei quali è UML.

Il metamodello UML
MOF ha 4 livelli: M0, M1, M2 e M3. Ogni livello è un’istanza

di un elemento del livello superiore.
� un elemento di M0 è la realtà da modellare
� un elemento di M1 è un modello che descrive la realtà
� un elemento di M2 è un modello che descrive modelli
(metamodello); UML è qui
� un elemento di M3 è un modello che descrive metamodelli
(meta-metamodello); MOF è qui
OMG usa MOF per definire altri linguaggi oltre a UML.
Tutti i linguaggi basati su MOF e i modelli con essi prodotti
possono essere serializzati e scambiati tramite lo standard
XMI (XML Metadata Interchange).
Semplificando...
Si può dire che UML è definito tramite un modello UML (o

piuttosto, usando un modello M3 che usa primitive comuni a
UML).
In qualunque momento, un oggetto al livello Mx è un’istanza
di uno del livello superiore.
Il meta-metamodello di livello M3 è progettato per essere
istanza di se stesso, quindi non esiste M4.
Chi usa UML crea modelli di livello M1; tuttavia, è bene
sapere che esistono anche i livelli superiori.

example, consider Figure 7.6, where the metaclasses Association and Class are both defined
metamodel. These are instantiated in a user model in such a way that the classes Person and
metaclass Class, and the association Person.car between the classes is an instance of the me
semantics of UML defines what happens when the user defined model elements are instanti
instance of Person, an instance of Car, and a link (i.e., an instance of the association) betwe
metamodel Class Association
«instanceOf» «instanceOf»
model *
Person Car
car
M1 eFigure
M2 a7.6confronto
- An example of metamodeling; note that not all instance-of relationships are sh
(usando un diagramma UML).
The instances, which are sometimes referred to as “run-time” instances, that are created at M0
should not be confused with instances of the metaclass InstanceSpecification that are also def
metamodel. An instance of an InstanceSpecification is defined in a model at the same level as
illustrates, as is depicted in Figure 7.7, where the instance specification Mike is an illustration
instance of class Person.
UML Infrastructure
metamodel Specification,
Class v2.0 InstanceSpecification
«instanceOf» «instanceOf»
model Person Mike: Person
age: Integer age = 11
Figure 7.7 - Giving an illustration of a class using an instance specification

Altro esempio con M1 (modello utente) e M2 (metamodello
UML)7.12 An Example of the Four-level Metamodel Hierarchy
An illustration of how these meta-layers relate to each other is shown in Figure 7.8. It should
means restricted to only these four meta-layers, and it would be possible to define additional o
layers are usually numbered from M0 and upwards, depending on how many meta-layers are u
the numbering goes up to M3, which corresponds to MOF.
I diagrammi e le viste
Un diagramma è la rappresentazione grafica di una
parte del modello.
Fornisce una vista di un sistema o una sua parte, cioè ne
mette in risalto diverse proprietà.
4+1 viste (Kruchten, 1995):
� Logical: mette in risalto la scomposizione logica del sistema
tramite classi, oggetti e loro relazioni
� Development: mostra l’organizzazione del sistema in
blocchi strutturali (package, sottosistemi, librerie, ...)
� Process: mostra i processi (o thread) del sistema in
funzione, e le loro interazioni
� Physical: mostra come il sistema viene installato ed
eseguito fisicamente
� Use case: (+1) la vista che agisce da ’collante’ per le altre;
spiega il funzionamento desiderato del sistema
UML 2 definisce 13 diagrammi (contro i 9 di UML 1.x), divisi

in due categorie:
� Structure diagrams: come è fatto il sistema; forniscono le
viste Logical, Development e Physical
� Behavior diagrams: come funziona il sistema; forniscono
le viste Process e Use case
Structure Behavior
Class diagram Use Case diagram
Object diagram Activity diagram
Package diagram* State Machine diagram
Composite Structure diagram* Sequence diagram
Component diagram Communication diagram
Deployment diagram Interaction Overview diagram*
Timing diagram*
* : non esiste in UML 1.x

Tassonomia dei 13 diagrammi di UML 2
Diagram
Structure Behavior
Diagram Diagram
Com ponent Object Activity Use Case State M achine

Class Diagram
Diagram Diagram Diagram Diagram Diagram
Com posite
Deploym ent Package Interaction
Structure
Diagram Diagram Diagram
Diagram
Interaction
Sequence
Overview
Diagram
Diagram
Com m unication Tim ing

Diagram Diagram
Figure A.5 - The taxonomy of structure and behavior diagram
Structure diagrams show the static structure of the objects in a system. That is, they depict those elements in a
specification that are irrespective of time. The elements in a structure diagram represent the meaningful concepts of an
application, and may include abstract, real-world and implementation concepts. For example, a structure diagram for an
airline reservation system might include classifiers that represent seat assignment algorithms, tickets, and a credit
Ingegneria delservice.
authorization Software ()
Structure Introduzione
diagrams do not show the detailsaofUML A.A. 2010-2011
dynamic behavior, which are illustrated by behavioral 23 / 42
diagrams. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Behavior diagrams show the dynamic behavior of the objects in a system, including their methods, collaborations,
activities, and state histories. The dynamic behavior of a system can be described as a series of changes to the system over
Entità UML
time. Behavior diagrams can be further classified into several other kinds as illustrated in Figure A.5.
Please note that this taxonomy provides a logical organization for the various major kinds of diagrams. However, it does
not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.
The constructs contained in each of the thirteen UML diagrams is described in the Superstructure chapters as indicated
below.
UML prevede diversi tipi di entità che possono essere

• Activity Diagram - “Activities” on page 307
• Class Diagram - “Classes” on page 21
organizzati in quattro
• Communication Diagram categorie:
- “Interactions” on page 477
� Strutturali
• Component Diagram - “Components” on page 147
• Composite Structure Diagram - “Composite Structures” on page 167
• � Comportamentali
Deployment diagram - “Deployments” on page 201
� Informative
714 UML Superstructure Specification, v2.1
� Raggruppamento e contenimento
Segue una panoramica delle entità principali ma andremo

in dettaglio quando analizzeremo i diversi diagrammi

UML: entità strutturali
Definiscono le "cose" (classificatori, things) del modello
Alcuni esempi: classi, classi attive, use-case,
collaborazioni, interfacce
Person
-age : int
TaskRunner Visualizza ordine
+getAge() : int
Transaction
<<interface>>
Thermometer
buyer seller
+readTemperature() : double
Person Person
UML: entità di raggruppamento e

contenimento
I package raggruppano altri elementi e forniscono loro un
namespace (che permette poi di identificare ogni elemento
con il suo nome).
In UML, moltissimi elementi possono contenere altri
elementi al loro interno, formando una struttura gerarchica,
rappresentabile graficamente in vari modi.
utility.conversion utility.conversion
CelsiusFahrenheit
OS
Java VM CelsiusFahrenheit

UML: entità comportamentali
Descrivono il "behavior": interazioni, collaborazioni

(communication), scambi di messaggi, transizioni di stato,
etc.
1: saluta
: Person : Person
2: rispondi
Mattino Pomeriggio Sera
Entità informative
Uno degli scopi principali della modellazione è la leggibilità:
un diagramma non leggibile e informativo serve a poco...
Le note UML non hanno effetti sul modello ma migliorano la
leggibilità.
Le!note!possono!essere!ancorate!a
qualunque!elemento!in!qualunque!
diagramma.
Person
-age : int
+getAge() : int
Questa!è!una!classe,!un!insieme!di!oggetti.!Le!classi
sono!classificatori.!In!UML,!la!maggior!parte!dei
classificatori!possono!essere!rappresentati!tramite
rettangoli!(deriva!da!OMT).

Relazioni
Gli elementi del modello possono essere collegati da

relazioni.
Rappresentate graficamente tramite linee.
Possono avere un nome.
Quattro sottotipi fondamentali:
� Association
� Generalization
� Dependency
� Realization
Association e generalization
Un’associazione descrive l’esistenza di un nesso tra le
istanze di classificatori (things) e ha varie caratteristiche,
alcune opzionali.
Company Employee
1 *
La generalizzazione è una relazione tassonomica da un

elemento specializzato verso un altro, più generale, dello
stesso tipo.
� Il figlio è sostituibile al genitore dovunque appaia, e ne
condivide struttura e comportamento.
Mammal Vertebrate

Dipendenze e realizzazioni
Una dipendenza è una relazione semantica: indica che il
client dipende, semanticamente o strutturalmente, dal
supplier (variazioni alla specifica del supplier possono
cambiare quella del client).
graphics
Renderer
Anche la realizzazione è una relazione semantica: il

supplier fornisce una specifica, il client la realizza (es:
implementazione di interfacce, templates, etc.)
<<interface>>
Apple Edible
+eat()
Le frecce in UML
Un metodo mnemonico per ricordarsi il verso di tutte le

frecce in UML è il seguente:
In UML, tutte le frecce vanno da chi sa verso chi non sa
(dell’esistenza dell’altro).
In una generalizzazione, il figlio sa di estendere il genitore,
ma il genitore non sa di essere esteso.
In una dipendenza, chi dipende sa da chi dipende, ma non
vice-versa.
In una realizzazione, chi implementa conosce la specifica,
ma non il contrario.

Stereotipi
Un’altra primitiva di UML comune ad ogni diagramma.

Rende un diagramma più informativo arricchendo la
semantica dei costrutti UML.
Uno stereotipo è una parola chiave tra virgolette e abbinata
ad un elemento del modello.
Es. «import», «utility», «interface».
Stereotipi in un diagramma delle classi
Questa!dipendenza!tra!Vector!e!Math!ha!lo!stereotipo
«call»;!significa!che!operazioni!di!Vector!invocano
operazioni!di!Math.
Vector <<utility>>
Math
<<call>>
Lo!stereotipo!«utility»!indica!che!questa!è!una!classe
utility,!cioè!una!collezione!di!variabili!globali!e
operazioni!statiche!usate!da!altre!parti!del!sistema.

Stereotipi come estensioni di UML
Gli stereotipi forniscono significato aggiuntivo ai costrutti

UML.
Possono essere usati per adattare UML a particolari ambiti
e piattaforme di sviluppo.
Stereotipi, vincoli e regole aggiuntivi vengono raccolti in
profili, che costituiscono uno dei principali meccanismi di
estensione di UML.
OCL (1)
Object Constraint Language (OCL) è un linguaggio,

approvato e standardizzato da OMG, per la specifica di
vincoli. Si usa assieme ad UML e a tutti i linguaggi
dell’architettura MOF.
Non è obbligatorio, ma aggiunge rigore formale al modello.
Specifica condizioni che devono essere soddisfatte dalle
istanze di una classe: i vincoli sono espressioni booleane
considerate true.
Un tool UML può usare OCL
� per validare il modello
� per generare codice

OCL (2)
Un vincolo OCL opera in un determinato contesto,

specificando proprietà soddisfatte da tutte le istanze di quel
contesto.
Il contesto può essere una classe, un suo attributo o una
sua operazione.
I vincoli hanno un tipo che descrive l’ambito della loro
validità.
context Car inv:
fuel>=0
Questo vincolo si applica alla classe Car ed è un invariante
(sempre valido).
Tipi di vincoli in OCL
inv: Invariante, sempre valido nel contesto.

pre: Nel contesto di un’operazione, una precondizione per
la sua esecuzione.
post: Nel contesto di un’operazione, una postcondizione
vera dopo l’esecuzione.
body: Definisce una query nel contesto.
init: Definisce il valore iniziale nel contesto.
derive: Definisce un attributo derivato del contesto.

OCL nei diagrammi (1)
OCL nei diagrammi (2)

inv:!self.age>=0
Person
-age : int
+birthdayHappens()
post: age=age@pre+1
(In una postcondizione, ’@pre’ permette di accedere al valore

precedente di un attributo.)
Conclusioni
Modellare è indispensabile in qualunque progetto non

banale.
UML è un linguaggio general-purpose per la modellazione.
Non è perfetto, ma è potente e costituisce uno standard
diffuso ed accettato.
Costruire un buon modello è difficile.
Alcuni tool
ArgoUML: http://argouml.tigris.org/
Papyrus: http://eclipse.org/papyrus
Umbrello: http://uml.sourceforge.net/
Eclipse: www.eclipse.org/uml2/
...

Il diagramma dei casi d’uso
Angelo Di Iorio
(dal materiale del Prof. Ciancarini, Dott. Favini e Dott.ssa Zuppiroli)
A.A. 2010-2011
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 1 / 51
Il diagramma dei casi d’uso
Si tratta di un diagramma che esprime un comportamento,

desiderato o offerto.
L’oggetto esaminato è solitamente un sistema o una sua
parte
Individua:
� chi o che cosa ha a che fare con il sistema (attore)
� che cosa l’attore può fare (caso d’uso).
Tipicamente è il primo tipo di diagramma ad essere creato
in un processo o ciclo di sviluppo, nell’ambito dell’analisi dei
requisiti.

Un esempio: conto in banca
I casi d’uso
I casi d’uso esistono da prima dei diagrammi UML!

Proposti da Ivar Jacobson nel 1992 per il metodo Objectory
In realtà la tecnica era già consolidata: studio degli scenari
di operatività degli utilizzatori di un sistema
In altre parole:
� i modi in cui il sistema può essere utilizzato
� le funzionalità che il sistema mette a disposizione dei suoi
utilizzatori

Casi d’uso e requisiti funzionali
I requisiti funzionali specificano cosa deve essere fatto.

Sono indipendenti dalla tecnologia, dall’architettura, dalla
piattaforma, dal linguaggio di programmazione.
I requisiti non-funzionali specificano vincoli aggiuntivi, ad
esempio:
� performance
� scalabilità
� tolleranza ai guasti
� dimensione degli eseguibili
I casi d’uso modellano i requisiti funzionali.
Caso d’uso
Specifica cosa ci si aspetta da un sistema

Nasconde come il sistema lo implementa
E’ una sequenza di azioni (con varianti) che producono un
risultato osservabile da un attore
Si usa per
� Descrivere i requisiti (analisi iniziale)
� Convalidare l’architettura e verificare il sistema

Un passo indietro: i desiderata
I desiderata sono ciò che il cliente desidera.

Formalizzare i desiderata in requisiti è una delle più
importanti sfide aperte dell’ingegneria del software.
La specifica errata o incompleta delle richieste del cliente è
una delle cause principali del fallimento dei progetti
software.
Il diagramma e la modellazione dei casi d’uso aiutano
l’interazione con il cliente e migliorano l’estrazione dei
requisiti (funzionali).
Esempio di desiderata: vanno bene?
Cliente:
vorrei vendere i manufatti che realizzo...
non vorrei solo un mercato locale...
mi piacerebbe che gli acquirenti potessero visionare un
catalogo da cui scegliere...
vorrei gestire gli ordini da qualunque posto perché viaggio
molto...
Che cosa viene fatto? Da chi?

Riformulati meglio...
Cliente:
vorrei avere la possibilità di creare un catalogo dei miei
manufatti...
vorrei un catalogo liberamente consultabile da chiunque...
vorrei organizzare i manufatti raccogliendoli in categorie...
vorrei che gli interessati all’acquisto potessero inviarmi un
ordine, che io provvederò ad evadere previa una qualche
forma di registrazione...
Estrarre i requisiti
Chi interagisce con il sistema (attori)?

Clienti
Amministratori del negozio online
Reparto ordini
Cosa fanno (casi d’uso)?
Il cliente si registra, consulta il catalogo ed effettua acquisti
L’amministratore organizza il catalogo, che è diviso in
categorie
Il reparto ordini riceve ordini da evadere
Il cliente sceglie il tipo di pagamento

Attori
Cliente Admin Resp. Ordini
Un attore specifica un ruolo assunto da un utente o altra

entità che interagisce col sistema nell’ambito di un’unità di
funzionamento (caso d’uso).
Un attore è esterno al sistema.
Non è necessariamente umano: oggetto fisico, agente
software, condizioni ambientali, etc.
Gli attori eseguono casi d’uso: prima si cercano gli attori,
poi i loro casi d’uso!
Come individuare gli attori
Per individuare un attore è necessario individuare chi/cosa

interagisce col sistema e con quale ruolo.
Domande utili:
� Chi/cosa usa il sistema?
� Che ruolo ha chi/cosa interagisce col sistema?
� In quale parte dell’organizzazione è utilizzato il sistema?
� Chi/cosa avvia il sistema?
� Chi supporterà e manterrà il sistema?
� Altri sistemi interagiscono col sistema?
� Ci sono funzioni attivate periodicamente? es. backup
� Chi/cosa ottiene o fornisce informazioni dal sistema?
� Un attore ha diversi ruoli? Lo stesso ruolo è assegnato a più
attori?

Specializzazione degli attori
Gli attori possono essere specializzati e connessi ad altri

attori tramite relazioni di generalization
Attori specializzati usano le stesse funzionalità degli attori
che generalizzano ed eventualmente alcune funzionalità
specifiche.
Caso d’uso UML (1)
Consulta catalogo
La specifica di una sequenza di azioni, incluse eventuali

sequenze alternative e/o di errore che un sistema (o
sottosistema) può eseguire interagendo con attori esterni.
È qualcosa che un attore vuole il sistema faccia:
� È descritto dal punto di vista dell’attore
� È causato da un’azione di un attore
Il nome (etichetta) dovrebbe essere basato su un verbo o
su un sostantivo che esprime un avvenimento.

Caso d’uso UML (2)
Un caso d’uso è sempre iniziato da un attore: in UML, un

evento è sempre legato all’entità che lo ha generato.
L’attore che inizia un caso d’uso è detto primario, gli altri
attori che interagiscono nell’ambito di quel caso d’uso sono
secondari.
Un caso d’uso è un classificatore dotato di comportamento:
può essere specificato da diagrammi di stato, interazione,
sequenza, avere pre- e post-condizioni, ...
Può ammettere al suo interno varianti al comportamento
principale.
Come individuare un caso d’uso
Individuare i casi d’uso è un’operazione iterativa.

Per individuare i casi d’uso possono essere utili le seguenti
domande:
� Ciascun attore che funzioni si aspetta?
� Il sistema gestisce (archivia/fornisce) informazioni? Se sì
quali sono gli attori che provocano questo comportamento?
� Alcuni attori vengono informati quando il sistema cambia
stato?
� Gli attori devono informare il sistema di cambiamenti
improvvisi?
� Alcuni eventi esterni producono effetti sul sistema?
� Quali casi d’uso manutengono il sistema?
� I requisiti funzionali sono tutti coperti dai casi d’uso?

Come recuperare informazioni su un caso
d’uso
Interviste con gli esperti del dominio (desiderata ben

strutturati)
Bibliografia del dominio del sistema
Sistemi già esistenti
Conoscenza personale del dominio
Come descrivere un caso d’uso
Descrivere in modo generico e sequenziale il flusso di

eventi di un caso d’uso
� Descrivere la precondizione (stato iniziale del sistema)
� Elencare la sequenza di passi
Descrivere le interazioni con gli attori e i messaggi
scambiati
Aggiungere eventuali punti di estensione
Descrivere in modo chiaro, preciso e breve
[ci torneremo più avanti]

Elementi del diagramma: sistema
Applicazione web
Consulta catalogo
Organizza catalogo
Acquista prodotto
Delimita l’argomento del diagramma, specificando i confini

del sistema.
Elementi del diagramma: associazione (1)
Consulta catalogo
Cliente
Collega gli attori ai casi d’uso.

Un attore si può associare solo a casi d’uso, classi e
componenti (che verranno eventualmente associati ad altri
casi d’uso, classi e componenti).
Un caso d’uso non dovrebbe essere associato ad altri casi
d’uso riguardanti lo stesso argomento.

Elementi del diagramma: associazione (2)
2 proceduraLancio 0..1
Lancia missile nucleare
esecutore lancio
Ufficiale
Alcune caratteristiche opzionali comuni a tutte le

associazioni in UML:
� nome
� molteplicità
� ruoli
Elementi del diagramma: generalizzazione
Impiegato Persona
Acquista orologio Acquista prodotto
Collega un attore o caso d’uso ad un altro più generale.

Il figlio può sostituire il genitore dovunque questi appaia.

Elementi del diagramma: include
<<include>>
Acquista prodotto Consulta catalogo
<<include>>
Effettua pagamento
Una dipendenza tra casi d’uso; il caso incluso fa parte del

comportamento di quello che lo include.
L’inclusione non è opzionale ed avviene in ogni istanza del
caso d’uso.
La corretta esecuzione del caso d’uso che include dipende
da quella del caso d’uso incluso.
Non si possono formare cicli di include.
Usato per riutilizzare parti comuni a più casi d’uso.
Elementi del diagramma: extend

<<extend>>
Acquista prodotto Registra account
Una dipendenza tra casi d’uso (notare il verso della

freccia).
Il caso d’uso che estende (client) specifica un incremento di
comportamento a quello esteso (supplier).
Si tratta di comportamento supplementare ed opzionale
che gestisce casi particolari o non standard.
Diverso da una generalizzazione tra casi d’uso:
� in una generalizzazione, entrambi i casi d’uso sono
ugualmente significativi
� in un extend, il client non ha necessariamente senso se
preso da solo
Extension points
Acquista prodotto <<extend>>

Registra account
Extension Points
Account non registrato
Un caso d’uso raggiunto da almeno un extend può

opzionalmente visualizzare i propri extension points.
Specifica i punti e/o condizioni dell’esecuzione in cui il
comportamento viene esteso.
Se gli extension points sono molti, alcuni tool possono
supportare la rappresentazione a rettangolo (i casi d’uso
sono classificatori).
include vs. extend
Include specifica comportamento obbligatorio.

Extend specifica comportamento supplementare (varianti).
Nell’include la freccia va dal caso d’uso che include verso
quello incluso.
Nell’extend la freccia va dal caso d’uso che estende verso
quello esteso.
Sono entrambi costrutti utili, ma non se ne deve abusare, o
la leggibilità ne risente.

Esempio diagramma
Web store
Consulta catalogo Registra account
<<extend>>
<<include>>
Cliente
Acquista prodotto
Genera ordine
<<include>>
<<include>>
Resp. ordini Evadi ordine
Immetti dati pagamento
Impiegato
Modifica catalogo
Admin
Sono sufficienti questi diagrammi?
Spesso nasce l’esigenza di abbinare i diagrammi dei casi

d’uso a specifiche testuali più formali.
I diagrammi dei casi d’uso non sono adatti a mostrare:
� la sequenza temporale delle operazioni
� lo stato del sistema e degli attori prima e dopo l’esecuzione
del caso d’uso
Manca la parte più importante: la descrizione (specifica) dei
casi d’uso!

Modellazione
Specifiche dei
del caso d’uso casi d’uso
Modellazione di caso d’uso:
Una vista che concentra l’attenzione su come
Ogni caso d’uso ha un nome e una specifica.
viene percepito il comportamento di un
La specifica è composta da:
sistema sw da parte di un utente esterno.
� precondizioni: condizioni che devono essere vere prima
Leche
funzionalità
il caso d’uso di un sistema
si possa eseguirevengono
� sequenza degli eventi: i passi che compongono il caso
suddivise in transazioni (casi d’uso) utili per
d’uso
ciascuna delle classi di utilizzatori (attori)
� postcondizioni: condizioni che devono essere vere quando
il caso d’uso termina l’esecuzione
UML 66
Esempio specificaEsempio
caso d’uso
Nome del caso d'uso Caso d'uso: PagamentoIVA
Identificatore univoco ID: UC1
Gli attori interessati dal caso Attori:
d'uso Tempo, Fisco
Lo stato del sistema prima che il Precondizioni:
caso d'uso possa iniziare
1. Si è concluso un trimestre fiscale
Sequenza degli eventi:

1. Il caso d'uso inizia quando si conclude un
I passi del caso d'uso trimestre fiscale.
2. Il sistema calcola l'ammontare dell'IVA
dovuta al Fisco.
3. Il sitema trasmette un pagamento
elettronico al Fisco.
Lo stato del sistema quando
l'esecuzione del caso d'uso è
terminata Postcondizioni:
1. Il Fisco riceve l'importo IVA dovuto.
UML 68

Sequenza degli eventi
Un elenco di azioni che definisce il caso d’uso nella sua

completezza.
Il caso d’uso si considera eseguito solo se l’esecuzione
arriva fino alla fine.
Un’azione è sempre iniziata da un attore oppure dal sistema
(in UML, gli eventi sono sempre legati a chi li crea).
� Passo iniziale: 1. Il caso d’uso inizia quando
<attore> <azione>...
� Passi successivi: <numero>. Il <attore/sistema>
<azione>
Sequenza (corretta) di eventi
Incomincia quando si seleziona la funzione ’ordina libro’

Il caso d’uso inizia quando il cliente seleziona la funzione
’ordina libro’
Vengono inseriti i dati del cliente
Il cliente inserisce nel form il suo nome e indirizzo
Il sistema verifica i dati del Cliente

Un altro esempio di sequenza di eventi
Nome: Contratto
Precondizione: l’impiegato è connesso
Flusso principale degli eventi
� L’impiegato inserisce il nome cliente e numero di conto
� Controlla la loro validità
� Inserisce il numero di azioni da comprare e ID azienda
quotata
� Il sistema determina il prezzo
� Il sistema controlla il limite
� Il sistema manda l’ordine in Borsa
� L’impiegato memorizza il numero di conferma
Flusso degli eventi
Ogni caso d’uso:

� Ha una sequenza di transizioni (eventi) normale o di base
� Può avere varie sequenze alternative
� Ha varie sequenze di transazioni eccezionali per la gestione
di errori o casi particolari
Per descrivere correttamente il flusso di eventi quindi:
� Descrive solo gli eventi relativi al caso d’uso, e non quel che
avviene in altri casi d’uso
� Descrivere come e quando il caso d’uso inizia e finisce
� Descrivere il flusso base degli eventi
� Descrivere ogni flusso alternativo

E in UML?
UML usa parole chiave per esprimere queste variazioni alla

sequenza principale.
Parola chiave Se: indica una ramificazione della sequenza
degli eventi nel caso si verifichi una condizione.
Ripetizioni all’interno di una sequenza:
� parola chiave Per (For)
� parola chiave Fintantoché (While)
È bene non eccedere con le ramificazioni!
Ramificazioni e sequenze alternative

Facciamo un esempio partendo dal caso d’uso ‘aggiorna
carrello’ di un negozio on-line.
Possibili ramificazioni, dopo aver aggiunto un articolo al
carrello:
� se il cliente richiede una nuova quantità il sistema aggiorna
la quantità di quell’articolo
� se il client seleziona rimuovi articolo il sistema elimina
quell’articolo dal carrello
Le sequenze alternative sono invece ramificazioni che non
possono essere espresse utilizzando il Se.
� Ad esempio dovute a condizioni che si possono verificare in
un qualunque momento: il cliente abbandona la pagina del
carrello

Esempio ramificazioni
Esempio
Caso d'uso: AggiornaCarrello
ID: UC2
Attori: Cliente
Precondizioni:
1. Il contenuto del carrello è visibile
Sequenza degli eventi:

1. Il caso d'uso inizia quando il Cliente
seleziona un articolo nel carrello.
2. Se il Cliente seleziona “rimuovi articolo”
2.1 Il Sistema elimina l'articolo
dal carrello.
3. Se il Cliente digita una nuova quantità
3.1 Il Sistema aggiorna la quantità
dell'articolo presente nel carrello
Postcondizioni:
1. Il contenuto del carrello è stato aggiornato
Sequenza alternativa 1:
1. In qualunque momento il Cliente
può abbandonare la pagina del carrello
Postcondizioni:
UML 72
Come individuare sequenze alternative?
Ad ogni passo della sequenza degli eventi principale,

cercare:
� alternative all’azione eseguita in quel passo
� errori possibili nella sequenza principale
� interruzioni che possono avvenire in qualunque momento
della sequenza principale
Sequenze alternative abbastanza complesse possono
essere descritte separatamente.
� stessa sintassi, si sostituisce ‘caso d’uso’ con ‘sequenza
degli eventi alternativa’
� il primo passo può indicare il punto della sequenza
principale da cui si proviene

Esempio: apertura conto corrente
1 il cliente si presenta in banca per aprire un nuovo c/c
2 l’addetto riceve il cliente e fornisce spiegazioni
3 se il cliente accetta fornisce i propri dati
4 l’addetto verifica se il cliente è censito in anagrafica
5 l’addetto crea il nuovo conto corrente
6 l’addetto segnala il numero di conto al cliente
Varianti:
3 (a) se il cliente non accetta il caso d’uso termina
3 (b) se il conto va intestato a più persone vanno forniti i dati
di tutte
4 (a) se il cliente (o uno dei diversi intestatari) non è censito
l’addetto provvede a registrarlo
Esempio: apertura conto corrente (2)

Il punto 5 (crea conto ) può essere ulteriormente dettagliato:
1 l’addetto richiede al sistema la transazione di inserimento
nuovo conto
2 il sistema richiede i codici degli intestatari
3 l’addetto fornisce i codici al sistema
4 il sistema fornisce le anagrafiche corrispondenti, e richiede
le condizioni da applicare al conto
5 l’addetto specifica le condizioni e chiede l’inserimento
6 il sistema stampa il contratto con il numero del conto
Varianti:
3 (a) se il sistema non riconosce il cliente, o se fornisce
un’anagrafica imprevista, l’addetto può effettuare correzioni
o terminare l’inserimento

Scenari
Uno scenario rappresenta una particolare interazione tra

uno o più attori e il sistema.
Non contiene ramificazioni o sequenze alternative: è
semplicemente la cronaca di un’interazione vera o
verosimile.
� il concetto risulta più immediato pensando agli attori in
maniera concreta: non un generico cliente, ma Alice o Bob
Una definizione alternativa: un caso d’uso è un insieme di
scenari possibili se un utente prova a raggiungere un dato
risultato
Scenario principale e scenari secondari
Corrispondono ad esecuzioni della sequenza principale e

di quelle alternative, rispettivamente.
Strategie per limitare il numero, potenzialmente enorme,
degli scenari secondari:
� documentare solo quelli considerati più importanti
� se ci sono scenari secondari molto simili, se ne documenta
uno solo, se necessario aggiungendo annotazioni per
spiegare come gli altri scenari differiscano dall’esempio.

Un esempio completo: conto in banca
Vedi PDF allegato.
Errori tipici sui diagrammi
Diagrammi di flusso invece di casi d’uso: un caso d’uso è

una sequenza di azioni, non una singola azione!
Nome del caso d’uso che appare più volte nel diagramma
Le frecce tra i casi d’uso non sono tratteggiate (- - - - - -> ) o
etichettate «extend» o «include»
«extend»: la freccia va dal caso che descrive l’evento
alternativo al caso standard
«include»: la freccia va dal caso chiamante al caso che
descrive le azioni da includere

Errori tipici sugli scenari
Assenza di precondizioni
Mancata connessione alla rappresentazione grafica
Nomi diversi per le stesse entità nelle rappresentazioni
grafica e testuale
Flusso eccezionale: mancanza di indicazioni nel flusso
principale del punto in cui va controllata la condizione
eccezionale
Riassumendo
Analizzare il materiale contenente i requisiti

Creare un glossario di progetto con parole chiave e una
breve descrizione
Capire chi sono gli attori
Estrarre i casi d’uso più evidenti
Cominciare ad organizzare i casi d’uso in un diagramma
Modellare i casi d’uso come sequenze di eventi
Raffinare progressivamente se necessario

Conclusioni
Il diagramma UML dei casi d’uso è un tool per la

modellazione del comportamento di un sistema.
Descrive gli attori che interagiscono con il sistema, cosa
fanno, e cosa ottengono dal sistema.
A questo punto non interessa sapere come il sistema
fornisca il comportamento richiesto.
Esercizi

Esercizio gestione biblioteca
Viene richiesto un sistema che permetta al bibliotecario e a

un utente di effettuare ricerche di libri. Il bibliotecario deve
poter effettuare il prestito e gestire la restituzione del libro.
Un utente deve restituire il libro entro una certa data. Se il
prestito risulta scaduto per la prima volta il sistema emette
un avviso, se è la seconda volta il bibliotecario registra e
stampa una multa. L’utente a questo punto può decidere se
pagare la multa subito oppure no. Il sistema deve
permettere la registrazione del pagamento.
Disegnare il diagramma dei casi d’uso e descrivere le
sequenze relative.
Esercizio gestione del personale
Viene richiesto un sistema che permetta la gestione del

personale di un’azienda. Per accedere alle operazione
bisogna autenticarsi. Le operazioni possibili saranno la
modifica dei dati dell’impiegato, la semplice visualizzazione
dei suoi dati, e la cancellazione dei dati.
sequenze relative.

Esercizio Ricerca di un prodotto
Una libreria ha la necessità di un sistema che le permetta di

far effettuare ricerche al suo personale. All’interno della
libreria vengono venduti anche dvd video, e cd musicali.
sequenze relative.
!"#$%&'()*"&(+,-"'(./0(
1$*2#3&*4#(+#4(53'67(5*'4'(8&*9)*3&9&:(
Esempio:
gestione conto corrente
• Il sistema usa uno sportello Bancomat
• L’utente deve poter depositare assegni
• L’utente deve poter ritirare contante
• L’utente deve poter chiedere il saldo
• L’utente deve poter ottenere una ricevuta se lo
richiede. La ricevuta riporta il tipo di transazione,la
data, il numero di conto, la somma, ed il nuovo saldo
• Dopo ciascuna transazione viene visualizzato il
nuovo saldo
Soluzione
<<extend>>
(print receipt) withdraw with
withdraw receipt
<<include>>
check <<include>>
Verify user
balance
User
<<include>>
deposit deposit with

<<extend>> receipt
(print receipt)
Soluzione
Use case: withdraw
Precondition: User has selected withdraw option
Main flow:
• Include (Verify user)
• Prompt user for amount to withdraw
• Check available funds of user
• Check available money of ATM
• Remove amount from account
• Give money
• (print receipt)
• Print current balance
Exceptional flow
• If not sufficient funds or money available, prompt user for lower
amount
Soluzione
Use case: deposit
Precondition: User has selected deposit option
Main flow:
• Prompt user for amount of deposit
• Open slot
• Get check
• (print receipt)
• Print (balance + deposited amount)
Soluzione
Use case: check balance
Precondition: User has selected balance
option
Main flow:
• Print balance
Soluzione
Use case: verify user
Precondition: none
Main flow:
• User enters ID card
• User enters PIN number
• System checks validity of card and number
Exceptional flow:
• If combination is not valid, reject user
Soluzione
Use case: withdraw with receipt
Precondition: User has selected withdraw
option and print receipt option
…
Use case: deposit with receipt

Precondition: User has selected deposit option
and print receipt option
...
I diagrammi di struttura
Angelo Di Iorio
(dal materiale del Prof. Ciancarini, Dott. Favini e Dott.ssa Zuppiroli)
A.A. 2010-2011
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 1 / 106

Tassonomia dei diagrammi UML 2
Structure diagrams show the static structure of the objects in a system. That is, they depict those elements in a
specification that are irrespective of time. The elements in a structure diagram represent the meaningful concepts of an
application, and may include abstract, real-world and implementation concepts. For example, a structure diagram for an
airline reservation system might include classifiers that represent seat assignment algorithms, tickets, and a credit
Ingegneria del Software
authorization ()
service. Structure diagrams do notIshow
diagrammi di struttura
the details A.A. 2010-2011
of dynamic behavior, which are illustrated by behavioral 2 / 106
diagrams. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Behavior diagrams show the dynamic behavior of the objects in a system, including their methods, collaborations,
activities, and state histories. The dynamic behavior of a system can be described as a series of changes to the system over
time. Behavior diagrams can be further classified into several other kinds as illustrated in Figure A.5.
A che punto siamo

Please note that this taxonomy provides a logical organization for the various major kinds of diagrams. However, it does
not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.
The constructs contained in each of the thirteen UML diagrams is described in the Superstructure chapters as indicated
below.
• Activity Diagram - “Activities” on page 307

• Class Diagram - “Classes” on page 21
• Communication Diagram - “Interactions” on page 477
Conosciamo i casi d’uso
• Component Diagram - “Components” di un sistema
on page 147
• Composite Structure Diagram - “Composite Structures” on page 167
Abbiamo steso
• Deployment diagram una specifica
- “Deployments” on page 201 dei requisiti
Abbiamo sequenze di eventi
Abbiamo un glossario di termini di progetto

Fasi di sviluppo
Requisiti (decidere cosa deve essere fatto)

Analisi (dare struttura ai requisiti)
Progettazione (decidere come implementare il sistema
analizzato)
Implementazione
Test
Analisi
Si trovano le entità coinvolte

Si studiano i legami tra le entità (relazioni tra le entità)
Si sta individuando la struttura del sistema

Analisi vs. Progettazione
L’analisi modella i concetti chiave del dominio del

problema.
La progettazione adatta il modello di analisi e lo completa
affinché diventi implementabile.
In altre parole...
L’analisi è vicina al problema.
La progettazione è vicina alla soluzione.
Dal punto di vista di UML, non si usano primitive o diagrammi
diversi, ma gli stessi tipi di diagramma con diversi livelli di
dettaglio (i diagrammi di analisi sono più ‘astratti’ di quelli di
progettazione).
Classi e oggetti
Costituiscono i ‘mattoni’ della struttura di un sistema.

Oggetto: Entità discreta, con confini ben definiti, che
incapsula stato e comportamento; un’istanza di una classe.
Classe: Descrittore di un insieme di oggetti che
condividono gli stessi attributi, operazioni, metodi, relazioni
e comportamento.
Uno dei primi compiti dell’analisi è quello di modellare il dominio
del problema in classi di analisi.
Queste verranno poi trasformate in classi di progettazione
adatte all’implementazione.

Come procedere: analisi
Estrarre un insieme di classi di analisi dalla specifica del

problema (ne parleremo tra poco)
Ragionare su queste classi: quali attributi e quali
operazioni devono fornire?
Stendere una mappa delle classi e delle loro relazioni.
Modellare la dinamica delle classi con i diagrammi di
comportamento.
Procedere per raffinamenti successivi fino a quando il
modello rappresenta efficacemente il dominio del problema.
Come procedere: progettazione
Si parte dal modello di analisi che contiene classi

abbastanza generiche, e lo si raffina.
I costrutti più astratti di UML vengono trasformati in altri più
concreti che possono essere implementati in un linguaggio
di programmazione OO.
Finalmente si considerano i vincoli di piattaforma e
linguaggio, e i requisiti non funzionali.
Le classi di analisi si trasformano in classi di progettazione
(non c’è corrispondenza 1 a 1)
Ancora una volta si procede per raffinamenti successivi.
Il risultato è un modello pronto per l’implementazione.

Come estrarre le classi di analisi
Una classe di analisi modella un concetto o entità del
problema: se la specifica dei casi d’uso è buona i concetti
basilari sono già in evidenza.
I candidati più probabili sono nomi che compaiono nella
specifica e nella documentazione.
Una ragione in più per tenere un glossario di progetto: le
parole nel glossario sono spesso candidati ideali per
diventare classi di analisi.
Le classi di analisi non sopravviveranno necessariamente
alla progettazione.
Due metodi molto diffusi per trovare le classi di analisi:
� analisi nome-verbo
� analisi CRC
Analisi nome-verbo
Si analizza tutta la documentazione disponibile,

selezionando nomi e verbi.
� I nomi: (es: conto corrente) sono i potenziali candidati per
divenire classi o attributi.
� I predicati nominali: (es: numero del conto corrente) sono i
potenziali candidati per divenire classi o attributi.
� I verbi: (es: aprire) sono potenziali candidati a divenire
responsabilità di classe.
Notate che ancora non parliamo di UML!

Analisi CRC
Class-Responsibilities-Collaborators
Si usano post-it divisi in tre sezioni chiamate proprio in
questo modo.
Si tratta di un metodo di brainstorming di gruppo che
coinvolge sviluppatori, esperti, committenti.
Si individuano i nomi delle classi, un insieme ristretto di
responsabilità (cose che la classe sa/fa) e di classi
collaboratori (alle quali viene richiesto
comportamento/informazione).
Le schede sono piazzate su un tavolo, la loro vicinanza
fisica rispecchia quella logica.
Si procede iterativamente.
Usato in congiunzione con analisi nome-verbo.
Esempio CRC

Esempio Classi di Analisi (1/2)
De Montfort University (DMU) offre corsi di laurea modulari,

e altri tipi di percorsi formativi ciascuno dei quali porta al
conseguimento di un titolo di riconoscimento.
Ogni titolo di riconoscimento è pubblicizzato nel prospetto
informativo di DMU
Ogni percorso comprende differenti moduli
Gli studenti di un percorso seguono fino a 8 moduli all’anno
Alcuni titoli sono ‘congiunti’, ad esempio uno studente può
iscriversi a due differenti percorsi (come ‘contabilità’ e
‘ragioneria’)
De Montfort University (DMU) offre corsi di laurea modulari,

e altri tipi di percorsi formativi ciascuno dei quali porta al
conseguimento di un titolo di riconoscimento.
Ogni titolo di riconoscimento è pubblicizzato nel prospetto
informativo di DMU
Ogni percorso comprende differenti moduli
Gli studenti di un percorso seguono fino a 8 moduli all’anno
Alcuni titoli sono ‘congiunti’, ad esempio uno studente può
iscriversi a due differenti percorsi (come ‘contabilità’ e
‘ragioneria’)

Soluzione De Montfort University
La DMU è composta di 6 Facoltà

Ogni facoltà definisce un numero di soggetti (‘contabilità’,
‘ragioneria’, etc.) ciascuno dei quali si occupa di differenti
percorsi.
Il consiglio di Facoltà è composto da studenti e da staff
accademico o ammistrativo
Lo staff accademico insegna un numero arbitrario di moduli
Lo staff accademico supervisiona diversi studenti, ciascuno
dei quali segue un percorso formativo
Alcuni rappresentanti dello staff amministrativo sono
consiglieri ma non insegnano

La DMU è composta di 6 Facoltà

Ogni facoltà definisce un numero di soggetti (‘contabilità’,
‘ragioneria’, etc.) ciascuno dei quali si occupa di differenti
percorsi.
Il consiglio di Facoltà è composto da studenti e da staff
accademico o ammistrativo
Lo staff accademico insegna un numero arbitrario di moduli
Lo staff accademico supervisiona diversi studenti, ciascuno
dei quali segue un percorso formativo
Alcuni rappresentanti dello staff amministrativo sono
consiglieri ma non insegnano
Una buona classe di analisi?
Le qualità di una buona classe di analisi:

il suo nome ne rispecchia l’intento
è un’astrazione ben definita, che modella uno specifico
elemento del dominio del problema
corrisponde ad una caratteristica ben identificabile del
dominio
ha un insieme ridotto e definito di responsabilità
ha la massima coesione interna
ha la minima interdipendenza con altre classi

Qualche regola pratica
3-5 responsabilità per classe

non isolata, collabora con un piccolo insieme di altre classi
evitare il proliferare di classi troppo semplici
evitare la concentrazione del modello in poche classi
complesse
evitare troppi livelli di ereditarietà
tenere in mente i principi object-oriented
Classi di analisi vs. classi di progettazione
Classi di analisi:
� contengono tipicamente solo pochi attributi e operazioni
(candidati)
� a volte basta indicare solo il nome della classe
� pochi ornamenti, specifica incompleta (omessi tipi, signature
delle operazioni, etc.)
Classi di progettazione:
� modellano una classe del linguaggio di programmazione
scelto
� specifica completa (implementabile)

E in UML?
Person Jim : Person
age = 10
Person
-age : int
: Person
+getAge() : int
Le classi possono avere fino a 3 slot:

� uno per il nome (in UpperCamelCase) e l’eventuale
stereotipo (slot obbligatorio)
� uno per gli attributi (opzionale)
� uno per le operazioni (opzionale)
La stessa classe può apparire con diverse quantità di
ornamenti in diagrammi diversi.
Classi e oggetti in UML
Person Jim : Person
age = 10
Person
-age : int
: Person
+getAge() : int
Le istanze delle classi (oggetti) hanno una notazione molto

simile
Il titolo degli oggetti è sottolineato e del tipo ’nome : classe’,
con nome opzionale.
Gli oggetti non hanno uno slot per le operazioni, possono
definire valori per gli attributi.

Relazione tra classe e oggetto
Person
Jim : Person
-age : int
<<instanceOf>>
+getAge() : int age = 10
Si tratta di una dipendenza con stereotipo «instanceOf» (o

«istanzia» sul libro).
Classe: notazione
Stereotipo
Nome
<<entity>>
ContoBancario
Sottosezione
-numero : String
attributi -correntista : String
-saldo : double = 0.0
+create(numero : String, correntista : String)
+deposito(somma : double)
Sottosezione +preleva(somma : double)
operazioni +getNumero() : String
+getCorrentista() : String
+getSaldo() : double
Visibilità
Operazione!con!ambito!di!classe
Nota: questo livello di dettaglio è tipico delle classi di

progettazione, non quelle di analisi.
Attributi
visibilità nome molteplicità:tipo=valoreIniziale
Solo il nome è obbligatorio

Le classi di analisi solitamente contengono solo gli
attributi più importanti (quelli che risultano evidenti
dall’analisi del dominio); spesso specificano solo il nome di
un attributo.
Assegnare un valore iniziale in una classe di analisi può
evidenziare i vincoli di un problema.
Le classi di progettazione forniscono una specifica
completa (implementabile) della classe e dei suoi attributi.
Tipi di visibilità
+ public ogni elemento che può accedere alla clas-

se può anche accedere a ogni suo membro
con visibilità pubblica
- private solo le operazioni della classe possono
accedere ai membri con visibilità privata
# protected solo le operazioni appartenenti alla classe
o ai suoi discendenti possono accedere ai
membri con visibilità protetta
∼ package ogni elemento nello stesso package del-
la classe (o suo sottopackage annidato)
può accedere ai membri della classe con
visibilità package

Operazioni
visibilità nome (nomeParametro:tipoParametro, . . . ):

tipoRestituito
Valgono le stesse considerazioni fatte a proposito degli

attributi per quanto riguarda analisi e progettazione.
In ogni classe non ci possono essere due operazioni con la
stessa signature.
Il nome di attributi ed operazioni è scritto in
lowerCamelCase.
Attributi, operazioni e visibilità

Dalle classi al codice (PHP)
<?php
// Short description of class Point

class Point{
public $x;
public $y;
// Short description of method moveTo

public function moveTo( Integer $newX, Integer $newY)
{
...
}
} // End of class Point

?>
Dalle classi al codice (Java)
public class User {
private Long id;
String name;
protected Boolean enabled;
protected String emailAddress;
protected String password;
...
}

Dalle classi al codice (Java)
public class User {
...
public void enable() {

...
}
public Boolean isValidPassword(String password) {

return null;
}
public Boolean isEnabled() {

return null;
}
public void changePassword(String newPassword) {

...
}
}
Come si esprime in UML?

class Studente extends Persona {
private String name;

private String cognome;
protected SchedaImmatricolazione immatricolazione;
public String getName() {

...
}
public void setName(String name) {

...
}
public SchedaImmatricolazione getImmatricolazione() {

...
}
}
Ambito
Ambito di istanza:
� gli oggetti hanno una propria copia degli attributi, quindi
oggetti diversi possono avere diversi valori negli attributi
� Le operazioni agiscono su oggetti specifici
Ambito di classe:
� gli oggetti di una stessa classe condividono lo stesso valore
per un attributo
� le operazioni non operano solo su una particolare istanza
della classe, ma alla classe stessa. Ad esempio: costruttori
e distruttori di classe.
� rappresentato sottolineando l’attributo/operazione
� analogo alla parola chiave static in Java
Ambito e accessibilità
Operazioni con ambito di istanza possono accedere sia ad

altre operazioni o attributi con ambito di istanza sia con
ambito di classe.
Operazioni con ambito di classe possono accedere solo ad
altre operazioni e attributi con ambito di classe (altrimenti
non si saprebbe quale istanza scegliere).
Valgono le usuali restrizioni di visibilità.

Esempio di ambito di istanza/classe (1)
Definiamo una classe Somma responsabile di sommare

due interi
Usiamo attributi e metodi con ambito di classe per contare
quante somme sono state eseguite.

public class Somma {
public static Integer numSommeEseguite = 0;

private Integer a;
private Integer b;
public void loadIntegers(int a, int b) {

this.a = a; this.b = b;
}
public Integer getSomma() {

EseguitaSomma();
return a + b;
}
private static void EseguitaSomma() {

numSommeEseguite = numSommeEseguite + 1;
}
}
Somma s = new Somma();
s.loadIntegers(1, 1);
s.getSomma(); // da stampare o
// salvare in una variable!
s.loadIntegers(8, 8);
s.getSomma();
Somma s2 = new Somma();
s2.loadIntegers(5, 5);
s2.getSomma();
System.out.println("Hai eseguito " +

Somma.numSommeEseguite +
" somme");
Quante somme sono state eseguite?
Template di classe
Un potente strumento di modellazione che non è limitato

alle classi.
Permette di parametrizzare i tipi che compaiono nella
specifica di una classe.
Perché definire come classi diverse un vettore di integer, un
vettore di float, un vettore di string, etc.?
Conviene molto di più definire un ’vettore di X’, e sostituire
X con quello che serve di volta in volta!

Notazione dei template
I parametri del template sono indicati in un rettangolo

tratteggiato.
Chiaramente servono primitive per istanziare classi basate
sui template, sostituendo valori ai parametri.
Questa operazione si chiama binding.
Binding esplicito
Si usa lo stereotipo «bind», seguito dai parametri di binding.

Binding implicito
Vector<int,100>
Si usa il nome della classe seguito dai parametri di binding.

Pro: più compatto.
Contro: la classe non ha un suo nome proprio (IntVector
nel binding esplicito).
Relazioni tra classi
Ci sono due relazioni statiche tra classi particolarmente

importanti in UML:
Generalizzazione
Associazione
Vi sono poi altre due relazioni che possono legare le classi
anche ad altri tipi di elementi:
Dipendenza
Realizzazione

Generalizzazione
Mammal Vertebrate
Relazione tassonomica tra un elemento più generale e uno

che lo specifica.
La freccia parte dall’elemento specifico e punta verso
quello più generale.
Si tratta dell’ereditarietà in UML.
Tra tutte le relazioni, questa è la più forte e vincolante.
Examples
Generalizzazione: stili grafici
Separate target style

Shape
Polygon Ellipse Spline
Shared target style

Shape
Figure()7.41
Ingegneria del Software - Examples of generalizations
I diagrammi di struttura between classes
A.A. 2010-2011 45 / 106
Package PowerTypes
Generalizzazione: da UML al codice (Java)
public class Shape {
...
Examples
}
public classShape
Polygon extends Shape {
Separate target style
...
}
public classEllipse
Polygon EllipseSpline
extends Shape {
...
}
Shared target style
Shape
public class Spline extends Shape {

...
}
Figure 7.41 - Examples of generalizations between classes

Package PowerTypes
In Figure 7.42, the Person class can be specialized as either a Female Person or a Male Person. Furthermore, Person’s can
be specialized as an Employee. Here, Female Person or a Male Person of Person constitute one GeneralizationSet and
Manager another. This illustration employs the notation forms depicted in the diagram above.
Insiemi di generalizzazione
Person Person
employment
gender status
employment
gender gender status
Female Employee
Female Male Person
Employee
Person Person
Male
Person
Person Person
employment
gender
status
Female Male Employee Female Male Employee

Person Person Person Person
Figure 7.42 - Multiple subtype partitions (GeneralizationSets) example
Permettono di partizionare lo stesso elemento generale in modi

70
diversi. UML Superstructure Specification, v2.0

Classi astratte
In UML, un classificatore può essere dichiarato astratto:

significa che non è istanziabile.
I classificatori astratti si riconoscono per il nome in corsivo.
Le classi possono definire operazioni astratte (in corsivo), di
cui non è data la specifica.
Una classe con almeno un’operazione astratta è
automaticamente una classe astratta.
Una classe astratta non è istanziabile... ma i suoi figli
possono esserlo.
Figli di classi astratte
Shape
-origin
-width
-height
+draw()
+getArea() : int
Rectangle Circle
+draw() +draw()
+getArea() : int +getArea() : int
I figli forniscono il comportamento definito come astratto in

Shape.

Polimorfismo
I figli completano la specifica che il genitore ha volutamente

lasciato incompleta.
Figli diversi forniscono comportamenti diversi alla stessa
chiamata di funzione.
Comportamento diverso di operazioni con la stessa
signature è una delle definizioni di polimorfismo, uno dei
principi cardine del metodo object-oriented.
Se i figli non ridefiniscono le operazioni astratte, devono
rimanere anch’essi astratti, o il modello non è valido.
Esercizio su Polimorfismo
Disegnare il diagramma delle classi della seguente specifica:
In un ristorante è possibile richiedere i piatti elencati nel
menù.
I piatti vengono tutti preparati ma ciascuno ha un modo
diverso per essere cucinato.
I piatti presenti nel menù sono:
� Pasta condita con uno dei sughi disponibili
� Sughi: bolognese, siciliana, matriciana
� Secondi piatti: frittata, caprese, carne alla griglia
� Contorni: verdure grigliate, impanate, fritte
� Dolci: mascarpone, torta di pinoli, torta della nonna
I piatti vengono preparati da un cuoco.

Ereditarietà multipla
Parent1 Parent2
Child
UML supporta l’ereditarietà multipla: un classificatore può

ereditare da un numero arbitrario di altri classificatori.
A tempo di analisi questo permette di modellare
efficacemente situazioni del mondo reale.
Tuttavia, classi con ereditarietà multipla dovranno essere
risolte a tempo di progettazione se il linguaggio scelto non
la supporta.
Associazione
employer employee
Company Person
1 *
employs
Si tratta del tipo di relazione più generico: indica solo

l’esistenza di collegamenti (link) tra le istanze delle classi.
Rappresenta l’abilità di un’istanza di mandare messaggi a
un’altra istanza.
Formalmente, definisce l’esistenza di tuple tra istanze tipate
(se o1 è associato a o2, la coppia ordinata (o1, o2) fa parte
della relazione).
Può coinvolgere più di due classi e la stessa classe più di
una volta.
Tra le relazioni è anche la più flessibile e la meno
vincolante.
Associazione: alcuni ornamenti
employer employee
Company Person
1 *
employs
Nome: opzionale.
Triangolo direzionale: opzionale. Specifica la direzione in
cui leggere l’associazione (aumenta la leggibilità).
Ruoli: opzionali a ciascun estremo.
Molteplicità: opzionale a ciascun estremo.
Generalizations between associations are best drawn using a different colo
associations.
Examples
Figure 7.19 shows a binary association from Player to Year named Played
Associazioni n-arie
* ! PlayedInYear
Year
year
season *
Team * * Player
team goalie
SiFigure
usa un 7.19 - Binary
rombo perand ternary associations
congiungere i vari estremi; in questo
caso non abbiamo coppie ma triple di elementi.
IlThe solid triangle
triangolo indicates
direzionale the usare
si può order ofsolo
reading:
nelle Player PlayedInYear Year
relazioni
between Team, Year, and Player with ends named team, season, and goali
binarie.
Molti ritengonoexample
The following che le relazioni non binarie
shows association endssiano
with superflue.
various adornments.
a b
Molteplicità
employer employee
Company Person
1 *
employs
In una relazione n-aria, indica quante istanze della classe in

quell’estremo possono partecipare alla relazione dopo aver
fissato gli altri n-1 estremi.
Può essere un numero o un intervallo min..max, con * che
indica l’infinito.
1..3,7 significa ’da 1 a 3 oppure 7’.
Molteplicità frequenti sono:
� 1
� 0..1
� 1..*
� *
Associazioni riflessive
parent
0..1
child
File Directory
* 1 *
Un’associazione riflessiva coinvolge la stessa classe più di

una volta.
Esempio: gerarchia di file system.
Se si sostituisce la molteplicità 0..1 di parent con *, si
generano grafi invece di alberi.

Associazioni riflessive e istanze
parent
0..1
child
File Directory
* 1 *
Una possibile realtà che soddisfa l’associazione...
home : Directory memo.txt : File
projects : Directory pictures : Directory
pic01.jpg : File
Navigabilità (1)
playedInYear
Player Year
player year
Specifica se gli altri estremi dell’associazione possono

sapere a quali istanze sono associati.
La freccia indica navigabilità.
La croce indica assenza di navigabilità.
La mancanza di entrambe significa navigabilità non
specificata (tipico della fase di analisi).
Un oggetto di tipo Player sa in quali anni ha giocato, un
oggetto di tipo Year non sa quali giocatori giocarono
quell’anno.
NavigabilitàThe(2)
following examples show notation for navigable ends.
a b
A B
1..4 2..5
c d
C D
1..4 2..5
e f
E F
1..4 2..5
g h
G H
1..4 2..5
i j
I J
1..4 2..5
Figure 7.21 - Examples of navigable ends

Alcuni esempi di navigabilità.
In Figure 7.21:
• The top pair AB shows a binary association with two navigable ends.
• The second pair CD shows a binary association with two non-navigable ends.
• The third pair EF shows a binary association with unspecified navigability.
• The fourth pair GH shows a binary association with one end navigable and the other non-navigable.
Notazione pratica
• The fifth pair IJper la navigabilità
shows a binary association with one end navigable and the other having unspecified nav
Figure 7.22 shows that the attribute notation can be used for an association end owned by a class, becaus
end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow n
it perfectly clear that the attribute is also an association end.
In pratica, si tende a non specificare la navigabilità di ogni

estremo di ogni relazione.
Un metodo diffuso A
è il seguente:
b: B[*]
� non si usano le croci
� l’assenza di frecce indica navigabilità in entrambe le direzioni
Figure 7.22 - Example of attribute notation for navigable end owned by an end class
� una freccia indica navigabilità in quella direzione e assenza
di navigabilità nell’altra
UML Superstructure Specification, v2.0
Doppia navigabilità risulta indistinguibile da navigabilità non

specificata, ma non è un problema in pratica

The attributes in Figure 7.28 are explained below.
• ClassA::name
Un esempio completois an attribute with type String.
• ClassA::shape is an attribute with type Rectangle.
• ClassA::size is a public attribute of type Integer with
• ClassA::area is a derived attribute with type Integer. I
• ClassA::height is an attribute of type Integer with a d
• ClassA::width is an attribute of type Integer.
• ClassB::id is an attribute that redefines ClassA::name
• ClassB::shape is an attribute that redefines ClassA::sh
• ClassB::height is an attribute that redefines ClassA::h
ClassA default of 5.
• ClassB::width is a derived attribute that redefines Cla
An attribute may also be shown using association notation

Figure 7.29.
Attributi come associazioni
size
Window Area
1
Figure 7.29 - Association-like

UML permette di rappresentare un notation
attributo di for
una attribute
classe
con la notazione tipica di un’associazione.
Il nome dell’attributo compare come ruolo insieme alla sua
molteplicità.
Non ci sono ornamenti dalla parte della classe che contiene
l’attributo.
52
The solid triangle indicates the order of reading: Player PlayedInYear Year. The figu
between Team, Year, and Player with ends named team, season, and goalie respecti
Vincoli di associazione
The following example shows association ends with various adornments.
a b
A B
0..1 *
{ordered}
d
C D
1 0..1
Examples {subsets b}
Figure 7.20 - Association ends with various adornments
Possono comparire
The followingtra parentesi
adornments graffe
are shown vicino
on the all’estremo
four association diFigure 7.20.
ends in
una relazione.• Stack
Names a, b, and d on three of the ends.
Specificano informazioni
• Multiplicities
size: Integer
aggiuntive sull’insieme di istanze
{size >= 0}0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
che partecipano alla relazione.
push() • Specification of ordering on b.
Utili perpop()
catturare vincoli del problema durante l’analisi.
• Subsetting on d. For an instance of class C, the collection d is a subset of the coll
constraint:
Figure 7.31 - context C inv: attached

Constraint b->includesAll(d)
to an attribute
Il vincolo xor
40
Person
Account
{xor}
Corporation
Figure 7.32vincolo
Un particolare - {xor} constraint
che esprime una scelta mutualmente
esclusiva.
Un conto è associato a una persona fisica oppure a una
persona giuridica.

0..1 boss
employee employer
Figure 7.32 - {xor} constraint
Altri vincoli
0..1 boss
employee employer
Person Company
* 0..1
{self.boss->isEmpty() or
self.employer = self.boss.employer}
Figure 7.33 - Constraint in a note symbol
Possono essere inclusi in note ed espressi in molti modi:

7.3.11 DataType (from Kernel)
OCL, linguaggi di programmazione, linguaggio naturale, . . .
OgniGeneralizations
impiegato, se ha un capo, lavora per la stessa
compagnia del suo
• “Classifier (fromcapo.
Kernel, Dependencies, PowerTypes)” on page 48.
56 UML Sup
Classi di associazione (1)
Spesso può capitare di avere un’associazione tra classi e la

necessità di aggiungere attributi e comportamento che non
sembrano adatti a nessuna delle due classi.
Ad esempio, si considerino le classi Person e Company...
� dove inserire l’attributo ’salary’?
� non ha senso parlare di salario per un disoccupato
� un salario non sembra un attributo adatto a definire la classe
Company
� questo attributo non si riferisce alla persona o alla
compagnia, ma al rapporto che esiste tra una persona e una
compagnia
Si usano le classi di associazione.

Classi di associazione (2)
* Job 1..*
Person person company
Company
Job
salary
Figure 7.25 - An AssociationClass is depicted by an association symbol (a line) and

Si trattawith
di auna
dashed line. The diagram shows the association class Job, which is defined
classe a tutti gli effetti, chiamata come la
and Company.
relazione.
7.3.5
Collegata alla BehavioralFeature
relazione tramite (from Kernel)
una linea tratteggiata.
Possiede tutte le feature
A behavioral proprietà delleofclassi
is a feature e quelle
a classifier dellean aspect of the behavio
that specifies
associazioni.
Generalizations
La classe di associazione è definita univocamente dai suoi
estremi. • “Feature (from Kernel)” on page 66
• “Namespace (from Kernel)” on page 95
Description
A behavioral feature specifies that an instance of a classifier will respond to a designa

Reificare le classi di associazione
BehavioralFeature is an abstract metaclass specializing Feature and Namespace. Kinds
by subclasses of BehavioralFeature.
Le classi di associazione sono un ottimo strumento di
analisi... ma nella progettazione?
Attributes
Trasformarle in una
No additional forma implementabile significa
attributes
reificarle.
Associations
Si spezza l’associazione in due e siSpecifies
• ownedParameter: Parameter[*]
trasforma in una
the ordered set of formal parameters o
normale classe. The parameter direction can be ‘in,’ ‘inout,’ ‘ou
output, or return parameters. Subsets Namespac
• raisedException:*Type[*] * References the Types representing exceptions tha
Company Person
of this operation.
Constraints Job
No additional constraints
1 *
Additional Operations * 1
Company Job Person
[1] The query isDistinguishableFrom() determines whether two BehavioralFeatures may
specifies that they have to have different signatures.
44 U
Aggregazione e composizione
Si tratta di particolari forme di associazione che rappresentano

la relazione whole-part (tutto-parte) tra un aggregato e le sue
parti.
Aggregazione: relazione poco forte (le parti esistono
anche senza il tutto; es. i computer e il loro cluster).
Composizione: relazione molto forte (le parti dipendono
dal tutto e non possono esistere al di fuori di esso; es. le
stanze e la casa).
Non è sempre semplice capire quale delle due modella meglio
una situazione.
Aggregazione e composizione: notazione
Aggregazione
0..1 *
ComputerCluster Computer
Composizione
1 1..*
House Room

{subsets b}
Figure 7.23 - Derived supersets (union)
Ancora sulla notazione

Figure 7.24 shows the black diamond notation for composite aggregation.
Window
1 1
1
+scrollbar
2 +title 1
1 +body
Slider
Header Panel
Aggregazione
Figure 7.24 -eComposite
composizione possono
aggregation is essere
depictedcombinate
as a black con
diamond
le altre notazioni per le associazioni.
Changes from previous UML
AssociationEnd was a metaclass

Ingegneria del Software ()
in prior UML, nowA.A.
I diagrammi di struttura
demoted
2010-2011
to72a/ 106
member o
that characterized AssociationEnd in prior UML is no longer supported. Fund
it impossible to continue targetScope or replace it by a new metaattribute, or
appropriate model element to tag. In UML 2, the type of the property determ
Aggregazione: semantica (1)
the members of an Association.
7.3.4 AssociationClass (from AssociationClasses)

L’aggregato può in alcuni casi esistere indipendentemente
Adalle
modelparti, ma in
element altri
that hascasi
bothno.
association and class properties. An Associat
also
Le has
particlass properties,
possono or asindipendentemente
esistere a class that also has association properties. It n
defines a set of features that belong to the relationship itself and not to any o
dall’aggregato.
L’aggregato è in qualche modo incompleto se mancano
Generalizations
alcune delle sue parti.
È possibile che più
• “Association aggregati
(from Kernel)”condividano
on page 36 una stessa parte.
L’aggregazione è transitiva.
• “Class (from Kernel)” on page 45
L’aggregazione è asimmetrica.
42

Aggregazione: semantica (2)
Il vincolo più importante di una aggregazione è che le istanze

devono essere acicliche.
In altre parole, la parte non deve essere in grado di
contenere il tutto.
Se il problema richiede di avere cicli, bisogna usare una
normale associazione.
Esempio di ciclo illegale
:A
:A :A
Data un’aggregazione riflessiva (es. struttura dati albero), ecco

un diagramma degli oggetti non valido.

Composizione: semantica (1)
Ogni parte può appartenere ad un solo composito per volta.

Il composito è l’unico responsabile di tutte le sue parti:
questo vuol dire che è responsabile della loro creazione e
distruzione.
Il composito può rilasciare una sua parte, a patto che un
altro oggetto si prenda la relativa responsabilità.
Se il composito viene distrutto, deve distruggere tutte le sue
parti o cederne la responsabilità a qualche altro oggetto.
In altre parole, la composizione è come l’aggregazione, ma la
parte non può esistere separata dal tutto.
Un esempio completo

Associazioni e linguaggi di programmazione
Cosa diventano le associazioni quando sono implementate

in un linguaggio di programmazione?
Dipende dalle caratteristiche del linguaggio e dal tipo e
molteplicità dell’associazione.
� puntatori
� array
� references
� oggetti
Alcune associazioni vanno trasformate in una forma
implementabile (reificate) durante la progettazione.
Associazioni durante la progettazione
La navigabilità viene generalmente aggiunta in fase di

progettazione (le associazioni di analisi tendono ad essere
bidirezionali).
La navigabilità in un solo senso è vantaggiosa in vista
dell’implementazione.
Aggregazione e composizione sono spesso aggiunte in
fase di progettazione.

Reificare: 1 a 1
A è il tutto, B la parte, fortemente legati: una possibilità.
Analisi 1 1
A B
<<refine>>
Progettazione 1 1
A B
Implementata come:
B è un campo di A (in un linguaggio come C++)
A ha un puntatore/reference a B (es. Java)
B non ha nulla di A
Reificare: molti a 1
A è il tutto, B la parte che può appartenere a molti A: una
possibilità.
Analisi * 1
A B
<<refine>>
Progettazione * 1
A B
Implementata come:
A ha un puntatore/reference a B (non può possedere B in
maniera esclusiva)
B non ha nulla di A
Reificare: molti a 1
A è il tutto con molte parti B, che possiede in maniera esclusiva:
una possibilità.
Analisi 1 *
A B
<<refine>>
Progettazione 1 *
A B
Implementata come:
A ha un array o lista di B fornita come primitiva dal
linguaggio
A usa una struttura di supporto (come Vector in Java)
B non ha nulla di A
Molti a 1 con classe di supporto
L’esempio precedente usando una classe Vector.
Analisi 1 *
A B
<<refine>>
Progettazione 1 1 1 *
A Vector B

Molti a molti con classe di associazione
Analisi Company * * Person
Job
<<refine>>
Progettazione
1 * * 1
Company Job Person
Una!persona!ha!un
solo!impego!all'interno!
della!stessa!azienda.
Il vincolo, implicito nel primo modello, ora va aggiunto in

una nota.
Dipendenza
«dependencyName»
NamedElement-1 NamedElement-2
Una
Figurerelazione semantica
7.35 - Notation tra elementi
for a dependency (inelements
between two particolare classi e
loro operazioni).
Examples
Due ruoli: supplier (fornitore) client (cliente); entrambi
In the example below, the Car class has a dependency on the Vehicle Type class. In this case, th
possono essere insiemi di elementi.
instantiate dependency, where the Car class is an instance of the Vehicle Type class.
La freccia va dal cliente verso il fornitore, lo stereotipo
indica il tipo della dipendenza.
Una dipendenza significa che il cliente richiede il fornitore
«instantiate»
propria specifica o implementazione. Car
per laCarFactory
Il cliente dipende strutturalmente o semanticamente dal
fornitore,
Figure 7.36 -eAnse la specifica
example del fornitore
of an instantiate cambia, può
dependency
cambiare anche quella del cliente.
7.3.13 DirectedRelationship (from Kernel)
A directed relationship represents a relationship between a collection of source model elements a

model elements.
Tipi di dipendenza
Uso: il cliente utilizza alcuni dei servizi resi disponibili dal

fornitore per implementare il proprio comportamento.
Astrazione: una relazione tra cliente e fornitore in cui il
fornitore è più astratto del cliente.
Accesso: il fornitore assegna al cliente un qualche tipo di
permesso di accesso al proprio contenuto.
Binding: il fornitore assegna al cliente dei parametri che
saranno istanziati a valori specifici dal cliente.
Dipendenze fornite da UML (1)
Uso:
� «use»: il cliente richiede il fornitore per la sua
implementazione completa
� «call»: il cliente invoca il fornitore (che è un’operazione o la
classe che la contiene)
� «responsibility»: un obbligo o contratto che il cliente ha
verso il fornitore
� «send»: il cliente (solitamente un’operazione) manda un
messaggio al fornitore
� «instantiate»: il cliente può creare istanze del fornitore

Dipendenza: esempi (1)
SimpleClass2
<<use>>
Class1 Class2 <<refine>>
Class3 <<call>>
+foo()
Dipendenze fornite da UML (2)

Astrazione:
� «derive»: il cliente può essere creato o calcolato (derivato)
a partire dal fornitore
� «refine»: indica raffinamenti successivi (es. il cliente è una
classe di progettazione e il fornitore una di analisi)
� «trace»: mostra lo stesso concetto in elementi diversi
Accesso:
� «import»: il cliente importa il fornitore (un package o un
elemento in un package diverso)
� «access»: come «import», ma gli elementi importati
diventano privati (non ulteriormente importabili)
Binding:
� «bind»: il cliente fornisce i valori di binding di un template

1 0..*
ContoBancario Transazione
1
<<derive>> 1
saldo
Quantità
1
Il saldo di un conto può essere derivato dall’elenco delle sue

transazioni.
Il package WebShop contiene una copia delle classi

(classificatori) del package ShoppingCart
I classificatori del package Ordini possono accedere ai
classificatori (pubblici) del package Personale
Realizzazione
Si tratta di una relazione semantica in cui il fornitore

rappresenta una specifica, e il cliente la implementa.
L’esempio canonico di realizzazione è quello in cui il
fornitore è un’interfaccia, e il cliente è la classe che la
implementa.
A livello di analisi si può usare la realizzazione anche tra
altri elementi del modello per indicare il loro legame
specifica/implementazione.
Realizzazione di un’interfaccia
<<interface>>
Apple Edible
+eat()
La classe Apple si impegna a fornire il comportamento

(operazioni) specificato dall’interfaccia Edible.
Lo stereotipo «interface» è usato per indicare una
realizzazione

Da UML al codice (Java)
interface Edible {
public void eat();
}
public class Apple implements Edible {
@Override
public void eat() {
}
Classi, sottoclassi e interfacce
Le interfacce sono simili alle classi (astratte) ma non hanno

‘implementazione’
Una classe astratta può avere alcuni metodi astratti
(implementati nelle sottoclassi) e altri non astratti. Può
essere quindi parzialmente definita.
Una classe può avere da zero a più istanze del suo tipo
Un’interfaccia ha almeno una classe che la implementa

Notation
A Realization dependency is shown as a dashed line with a triangular arrow
Altri tipi di realizzazione realized element. Figure 7.71 illustrates an example in which the Business
and Employee classes.
Business
Owner Employee
Un tipo più astratto di 7.71

Figure realizzazione: laaclasse
- An example of realization dependencyè
Business
realizzata da una combinazione delle classi Owner ed
Employee. 7.3.46 RedefinableElement (from Kernel)
A redefinable element is an element that, when defined in the context of a c

differently in the context of another classifier that specializes (directly or i
Generalizations
• “NamedElement (from Kernel, Dependencies)” on page 93

Package
Description
A redefinable element is a named element that can be redefined in the cont
an abstract metaclass.
utility.conversion
Attributes
• isLeaf: Boolean Indicates whether it is possible to further speci
then it is not possible to further specialize the
Associations
• / redefinedElement: RedefinableElement[*] The redefinable elemen
a derived union.
Entità di raggruppamento.
• / redefinitionContext: Classifier[*] References the contexts
Raggruppa elementi logicamente coesi tra loro. a derived union.
Fornisce un namespace all’interno del quale ogni elemento
Constraints dal suo nome.
è definito univocamente
[1] At least one of the redefinition contexts of the redefining element must be
redefinition contexts for each redefined element.
Ingegneria del Software () self.redefinedElement->forAll(e
I diagrammi di struttura | self.isRedefinitionContextValid(e))
A.A. 2010-2011 97 / 106
Elements that become available for use in an importing package through a package import or an element impo
a distinct color or be dimmed to indicate that they cannot be modified.
Notazioni
Examples
package
There are three representations of the same package Types in Figure 7.63. The one on the left just shows the
without revealing any of its members. The middle one shows some of the members within the borders of the p
the one to the right shows some of the members using the alternative membership notation.
Types
Types Types
Integer
Time
Shape Point
Figure 7.63 - Examples of a package with members
Modi diversi
7.3.38 di rappresentare
PackageableElement unKernel)
(from package e il suo contenuto.
A packageable element indicates a named element that may be owned directly by a package.
Generalizations
• “NamedElement (from Kernel, Dependencies)” on page 99

UML Superstructure Specification, v2.1
Visibilità nei package
Ogni elemento di un package (ad es. una classe) ha una

visibilità associata, che può essere public (+) o private (-).
Quando un package viene importato o acceduto, gli
elementi privati non risultano visibili dall’esterno.
Di solito è opportuno limitare al massimo il numero di
elementi pubblici, proprio come è opportuno limitare gli
attributi e le operazioni pubbliche in una classe.

Esempio package
Club
-RegoleIscrizione
+RegoleClub <<import>> DettagliSocio
+Benefici
+Socio
+AssociazioneClub
Club
+AssociazioneClub
+Benefici
+RegoleClub
+DettagliSocio
+DettagliSocio::Socio
-RegoleIscrizione
Package di analisi
I package di analisi sono creati a partire dalle classi di

analisi, per scomporre lo spazio logico del modello in
sottospazi considerabili separatamente.
Un package raggruppa classi molto coese tra loro (la
maggior parte delle comunicazioni di queste classe avviene
con altre classi dello stesso package).
Se una classe deve accedere ad una classe in un package
diverso, deve esistere una dipendenza «import» oppure
«access».
Sono proibiti i cicli nelle dipendenze tra package: se
necessario, i package devono essere divisi per evitarli.

Conclusioni
I diagrammi di struttura in UML modellano l’architettura

logica o fisica di un sistema indipendemente dal tempo.
Le classi e le loro istanze, gli oggetti, sono i mattoni con i
quali si costruisce un sistema.
I diagrammi di struttura aiutano sia in fase di analisi che di
progettazione, in quanto possono essere usati a diversi
livelli di astrazione.
Esercizi

Esercizio Appartamento
Rappresentare il seguente testo tramite un diagramma

UML delle classi:
Un appartamento è composto da una o più stanze,
ciascuna delle quali ha una lunghezza e una larghezza,
pubbliche e di tipo float. Un appartamento è posseduto da
uno o più persone. Un palazzo è composto da uno o più
appartamenti e possiede un’operazione privata senza
parametri che ne restituisce il numero di piani.
Esercizio Treno
Si rappresenti questo dominio con un diagramma UML

delle classi:
Si deve modellare un singolo viaggio in treno. Un treno ha
200 posti, ciascuno dei quali numerato e accessibile tramite
una prenotazione che contiene la stazione di partenza e
quella di arrivo (per semplicità, si assumano integer). Il
viaggiatore prenota un qualunque numero di posti, e
ovviamente più viaggiatori possono occupare lo stesso
posto in tempi diversi durante il viaggio.

Esercizio Filosofi
Si usino un diagramma delle classi e uno degli oggetti per

rappresentare:
Tutti i filosofi sono uomini e tutti gli uomini sono mortali. Tutti
gli uomini hanno un nome. Ogni filosofo è discepolo di al
massimo un altro filosofo, e un filosofo può avere un
qualunque numero di discepoli. Inoltre, un filosofo può
produrre un qualunque numero di opere, ciascuna delle
quali ha un titolo. Socrate, Platone e Aristotele sono filosofi;
Platone è discepolo di Socrate e Aristotele è discepolo di
Platone. Platone ha scritto ‘La Repubblica’.

UML Ita

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

UML Ita

Caricato da

Copyright:

Formati disponibili

Introduzione a UML

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 1 / 42

Un modello è un’astrazione che cattura le proprietà salienti

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 2 / 42

Per comprendere il soggetto in analisi.

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 3 / 42

I progetti software sono complessi

Un linguaggio di modellazione fornisce le primitive a cui

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 5 / 42

Che cos’è UML (1)

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 6 / 42

Si tratta di un linguaggio di modellazione usato per capire e

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 7 / 42

Si tratta di un vero e proprio linguaggio, non di una

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 8 / 42

Usiamo un semplice diagramma dei Casi d’Uso come

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 9 / 42

UML rappresenta la sintesi di vari approcci metodologici

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 10 / 42

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 11 / 42

Breve storia (2)

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 12 / 42

UML non è solo un linguaggio per la modellazione, ma un

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 13 / 42

OO: un paradigma che sposta l’enfasi della

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 14 / 42

Abstraction : usare classi per astrarre la natura e le

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 15 / 42

Si può dire che in UML tutto è un oggetto.

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 16 / 42

MOF ha 4 livelli: M0, M1, M2 e M3. Ogni livello è un’istanza

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 17 / 42

Si può dire che UML è definito tramite un modello UML (o

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 18 / 42

metamodel Class Association

model Person Mike: Person

age: Integer age = 11

Figure 7.7 - Giving an illustration of a class using an instance specification

UML 2 definisce 13 diagrammi (contro i 9 di UML 1.x), divisi

* : non esiste in UML 1.x

Com ponent Object Activity Use Case State M achine

Com m unication Tim ing

Figure A.5 - The taxonomy of structure and behavior diagram

UML prevede diversi tipi di entità che possono essere

Segue una panoramica delle entità principali ma andremo

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 24 / 42

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 25 / 42

UML: entità di raggruppamento e

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 26 / 42

Descrivono il "behavior": interazioni, collaborazioni

Mattino Pomeriggio Sera

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 27 / 42

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 28 / 42

Gli elementi del modello possono essere collegati da

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 29 / 42

La generalizzazione è una relazione tassonomica da un

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 30 / 42

Anche la realizzazione è una relazione semantica: il

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 31 / 42

Un metodo mnemonico per ricordarsi il verso di tutte le

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 32 / 42

Un’altra primitiva di UML comune ad ogni diagramma.

Ingegneria del Software () Introduzione a UML A.A. 2010-2011 33 / 42