Sei sulla pagina 1di 104

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.

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


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.

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

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?
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 4 / 42
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.

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

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

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


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.

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

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

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


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.

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

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

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


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.

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

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.

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


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

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

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.

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


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.

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

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.

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


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

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

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.

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


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
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 19 / 42
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
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 20 / 42
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
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 21 / 42

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


Ingegneria del Software () Introduzione a UML A.A. 2010-2011 22 / 42
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

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


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

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

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

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


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

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

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

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


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

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

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

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


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

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

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.

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


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

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

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.

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


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.

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

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

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


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

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

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.

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


OCL nei diagrammi (1)

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

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.)
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 40 / 42
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.

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

Alcuni tool

ArgoUML: http://argouml.tigris.org/
Papyrus: http://eclipse.org/papyrus
Umbrello: http://uml.sourceforge.net/
Eclipse: www.eclipse.org/uml2/
...

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


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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 2 / 51


Un esempio: conto in banca

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 3 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 4 / 51


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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 5 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 6 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 7 / 51

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?

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 8 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 9 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 10 / 51


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!

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 11 / 51

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?

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 12 / 51


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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 13 / 51

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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 14 / 51


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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 15 / 51

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?

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 16 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 17 / 51

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]

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 18 / 51


Elementi del diagramma: sistema
Applicazione web

Consulta catalogo

Organizza catalogo

Acquista prodotto

Delimita l’argomento del diagramma, specificando i confini


del sistema.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 19 / 51

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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 20 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 21 / 51

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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 22 / 51


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.
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 23 / 51

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
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 24 / 51
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).

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 25 / 51

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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 26 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 27 / 51

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!

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 28 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 29 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 30 / 51


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>

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 31 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 32 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 33 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 34 / 51


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!

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 35 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 36 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 37 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 38 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 39 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 40 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 41 / 51

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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 42 / 51


Un esempio completo: conto in banca

Vedi PDF allegato.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 43 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 44 / 51


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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 45 / 51

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

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 46 / 51


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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 47 / 51

Esercizi

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 48 / 51


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.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 49 / 51

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.
Disegnare il diagramma dei casi d’uso e descrivere le
sequenze relative.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 50 / 51


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.
Disegnare il diagramma dei casi d’uso e descrivere le
sequenze relative.

Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 51 / 51

!"#$%&'()*"&(+,-"'(./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:
• Include (Verify user)
• 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:
• Include (Verify user)
• 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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 3 / 106


Fasi di sviluppo

Requisiti (decidere cosa deve essere fatto)


Analisi (dare struttura ai requisiti)
Progettazione (decidere come implementare il sistema
analizzato)
Implementazione
Test

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 4 / 106

Analisi

Si trovano le entità coinvolte


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 5 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 6 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 7 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 8 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 9 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 10 / 106

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!

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 11 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 12 / 106

Esempio CRC

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 13 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 14 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 15 / 106


Soluzione De Montfort University

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 16 / 106

Esempio Classi di Analisi (2/2)

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 17 / 106


Esempio Classi di Analisi (2/2)

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 18 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 19 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 20 / 106

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)

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 21 / 106


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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 22 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 23 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 24 / 106

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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 25 / 106
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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 26 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 27 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 28 / 106

Attributi, operazioni e visibilità

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 29 / 106


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


?>

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 30 / 106

Dalle classi al codice (Java)

public class User {

private Long id;

String name;

protected Boolean enabled;

protected String emailAddress;

protected String password;

...
}

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 31 / 106


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


...
}
}
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 32 / 106

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() {


...
}

}
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 33 / 106
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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 34 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 35 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 36 / 106

Esempio di ambito di istanza/classe (2)


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;
}
}
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 37 / 106
Esempio di ambito di istanza/classe (3)
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?
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 38 / 106

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!

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 39 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 40 / 106

Binding esplicito

Si usa lo stereotipo «bind», seguito dai parametri di binding.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 41 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 42 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 43 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 44 / 106

Examples
Generalizzazione: stili grafici

Separate target style


Shape

Polygon Ellipse Spline

Shared target style


Shape

Polygon Ellipse Spline

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 {


...
}
Polygon Ellipse Spline

Figure 7.41 - Examples of generalizations between classes


Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 46 / 106
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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 47 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 48 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 49 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 50 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 51 / 106


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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 52 / 106

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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 53 / 106
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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 54 / 106
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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 55 / 106

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..*
� *
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 56 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 57 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 58 / 106

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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 59 / 106
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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 60 / 106
• 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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 61 / 106


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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 62 / 106

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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 63 / 106
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:
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 64 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 65 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 66 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 67 / 106


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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 68 / 106

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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 69 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 70 / 106

Aggregazione e composizione: notazione

Aggregazione
0..1 *
ComputerCluster Computer

Composizione
1 1..*
House Room

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 71 / 106


{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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 73 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 74 / 106

Esempio di ciclo illegale

:A

:A :A

Data un’aggregazione riflessiva (es. struttura dati albero), ecco


un diagramma degli oggetti non valido.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 75 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 76 / 106

Un esempio completo

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 77 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 78 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 79 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 80 / 106

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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 81 / 106
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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 82 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 83 / 106


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.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 84 / 106

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)
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 85 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 86 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 87 / 106


Dipendenza: esempi (1)

SimpleClass2

<<use>>
Class1 Class2 <<refine>>

Class3 <<call>>
+foo()

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 88 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 89 / 106


Dipendenza: esempi (2)

1 0..*
ContoBancario Transazione

1
<<derive>> 1
saldo
Quantità
1

Il saldo di un conto può essere derivato dall’elenco delle sue


transazioni.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 90 / 106

Dipendenza: esempi (3)

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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 91 / 106
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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 92 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 93 / 106


Da UML al codice (Java)

interface Edible {
public void eat();
}

public class Apple implements Edible {

@Override
public void eat() {
}

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 94 / 106

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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 95 / 106


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
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 96 / 106

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


Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 98 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 99 / 106


Esempio package

Club
-RegoleIscrizione
+RegoleClub <<import>> DettagliSocio
+Benefici
+Socio
+AssociazioneClub

Club
+AssociazioneClub
+Benefici
+RegoleClub
+DettagliSocio
+DettagliSocio::Socio
-RegoleIscrizione

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 100 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 101 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 102 / 106

Esercizi

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 103 / 106


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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 104 / 106

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.

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 105 / 106


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

Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 106 / 106