introduzione a uml modellare
TRANSCRIPT
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à salientidella realtà che si desidera rappresentare.Idealizza una realtà complessa, individuandone i trattiimportanti e separandoli dai dettagli, facilitandone lacomprensione.La mente umana compie un’attività continua dimodellazione, producendo schemi per comprendere espiegare 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 complessiIl tipico progetto software raramente coinvolge un solosviluppatore, 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 personalenel 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 staragionando?
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 4 / 42
I linguaggi di modellazione
Un linguaggio di modellazione fornisce le primitive a cuiricondurre la realtà in esame.Permette di esprimere le entità che compongono unsistema complesso, le loro caratteristiche e le relazioniche 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 linguaggiosemiformale e grafico (basato su diagrammi) perspecificare, visualizzare, costruire e documentare gliartefatti 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 persviluppare il sistema e comunicare con il cliente (ma anchecon 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 edescrivere le caratteristiche di un nuovo sistema o di unoesistente.Indipendente dall’ambito del progetto.Indipendente dal processo di sviluppo.Indipendente dal linguaggio di programmazione (progettatoper essere abbinato alla maggior parte dei linguaggiobject-oriented).Fa parte di un metodo di sviluppo, non è esso stesso ilmetodo.
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
Cliente
Chiedi prestito
Banca
Usiamo un semplice diagramma dei Casi d’Uso comeesempio.Regola sintattica: una relazione tra un attore e un casod’uso può opzionalmente includere una freccia.Regola semantica: la freccia significa che la primainterazione 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 metodologicifusi in un’unica entità.L’intento era di prendere il meglio da ciascuno dei diversilinguaggi esistenti e integrarli. Per questo motivo, UML è unlinguaggio molto vasto.Questa è una delle critiche principali mosse a UML ("vuolefare 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 RationalSoftware 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 ThreeAmigos, 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 (opiuttosto, usando un modello M3 che usa primitive comuni aUML).In qualunque momento, un oggetto al livello Mx è un’istanzadi uno del livello superiore.Il meta-metamodello di livello M3 è progettato per essereistanza di se stesso, quindi non esiste M4.Chi usa UML crea modelli di livello M1; tuttavia, è benesapere che esistono anche i livelli superiori.
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 18 / 42
UML Infrastructure Specification, v2.0 17
The metamodel hierarchy bottoms out at M0, which contains the run-time instances of model elements defined in a
model. The snapshots that are modeled at M1 are constrained versions of the M0 run-time instances.
When dealing with more than three meta-layers, it is usually the case that the ones above M2 gradually get smaller and
more compact the higher up they are in the hierarchy. In the case of MOF, which is at M3, it consequently only shares
some of the metaclasses that are defined in UML. A specific characteristic about metamodeling is the ability to define
languages as being reflective, i.e., languages that can be used to define themselves. The InfrastructureLibrary is an
example of this, since it contains all the metaclasses required to define itself. When a language is reflective, there is no
need to define another language to specify its semantics. MOF is reflective since it is based on the InfrastructureLibrary,
and there is thus no need to have additional meta-layers above MOF.
7.11 Metamodeling
When metamodeling, we primarily distinguish between metamodels and models. As already stated, a model that is
instantiated from a metamodel can in turn be used as a metamodel of another model in a recursive manner. A model
typically contains model elements. These are created by instantiating model elements from a metamodel, i.e., metamodel
elements.
The typical role of a metamodel is to define the semantics for how model elements in a model get instantiated. As an
example, consider Figure 7.6, where the metaclasses Association and Class are both defined as part of the UML
metamodel. These are instantiated in a user model in such a way that the classes Person and Car are both instances of the
metaclass Class, and the association Person.car between the classes is an instance of the metaclass Association. The
semantics of UML defines what happens when the user defined model elements are instantiated at M0, and we get an
instance of Person, an instance of Car, and a link (i.e., an instance of the association) between them.
Figure 7.6 - An example of metamodeling; note that not all instance-of relationships are shown
Association
Person Car
«instanceOf»
Class
«instanceOf»
*
car
metamodel
model
M1 e M2 a confronto (usando un diagramma UML).
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 19 / 42
18 UML Infrastructure Specification, v2.0
The instances, which are sometimes referred to as “run-time” instances, that are created at M0 from for example Person
should not be confused with instances of the metaclass InstanceSpecification that are also defined as part of the UML
metamodel. An instance of an InstanceSpecification is defined in a model at the same level as the model elements that it
illustrates, as is depicted in Figure 7.7, where the instance specification Mike is an illustration (or a snapshot) of an
instance of class Person.
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 be noted that we are by no
means restricted to only these four meta-layers, and it would be possible to define additional ones. As is shown, the meta-
layers are usually numbered from M0 and upwards, depending on how many meta-layers are used. In this particular case,
the numbering goes up to M3, which corresponds to MOF.
Figure 7.7 - Giving an illustration of a class using an instance specification
InstanceSpecification
Person Mike: Person
«instanceOf»
Class
«instanceOf»
metamodel
model
age: Integer age = 11
Altro esempio con M1 (modello utente) e M2 (metamodelloUML)
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 20 / 42
I diagrammi e le visteUn diagramma è la rappresentazione grafica di unaparte del modello.Fornisce una vista di un sistema o una sua parte, cioè nemette in risalto diverse proprietà.4+1 viste (Kruchten, 1995):
� Logical: mette in risalto la scomposizione logica del sistematramite classi, oggetti e loro relazioni
� Development: mostra l’organizzazione del sistema inblocchi strutturali (package, sottosistemi, librerie, ...)
� Process: mostra i processi (o thread) del sistema infunzione, e le loro interazioni
� Physical: mostra come il sistema viene installato edeseguito 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 BehaviorClass 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
714 UML Superstructure Specification, v2.1
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
authorization service. Structure diagrams do not show the details of dynamic behavior, which are illustrated by behavioral
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.
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
• Component Diagram - “Components” on page 147
• Composite Structure Diagram - “Composite Structures” on page 167
• Deployment diagram - “Deployments” on page 201
Diagram
Structure
Diagram
Behavior
Diagram
Interaction
Diagram
Use Case
Diagram
Activity
Diagram
Composite
Structure
Diagram
Class DiagramComponent
Diagram
Deployment
Diagram
Sequence
Diagram
Interaction
Overview
Diagram
Object
DiagramState Machine
Diagram
Package
Diagram
Communication
Diagram
Timing
Diagram
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 23 / 42
Entità UML
UML prevede diversi tipi di entità che possono essereorganizzati in quattro categorie:
� Strutturali� Comportamentali� Informative� Raggruppamento e contenimento
Segue una panoramica delle entità principali ma andremoin dettaglio quando analizzeremo i diversi diagrammi
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 24 / 42
UML: entità strutturaliDefiniscono le "cose" (classificatori, things) del modelloAlcuni esempi: classi, classi attive, use-case,collaborazioni, interfacce
-age : int
+getAge() : int
Person
TaskRunner Visualizza ordine
Transaction
Person Person
+readTemperature() : double
<<interface>>
Thermometerbuyer seller
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 25 / 42
UML: entità di raggruppamento econtenimento
I package raggruppano altri elementi e forniscono loro unnamespace (che permette poi di identificare ogni elementocon il suo nome).In UML, moltissimi elementi possono contenere altrielementi al loro interno, formando una struttura gerarchica,rappresentabile graficamente in vari modi.
utility.conversion
CelsiusFahrenheit
utility.conversion
CelsiusFahrenheit
OS
Java VM
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.
: Person : Person
1: saluta
2: rispondi
Mattino Pomeriggio Sera
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 27 / 42
Entità informativeUno 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 laleggibilità.
-age : int
+getAge() : int
Person
Le!note!possono!essere!ancorate!a
qualunque!elemento!in!qualunque!
diagramma.
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 darelazioni.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 generalizationUn’associazione descrive l’esistenza di un nesso tra leistanze di classificatori (things) e ha varie caratteristiche,alcune opzionali.
Company Employee
1 **1
La generalizzazione è una relazione tassonomica da unelemento specializzato verso un altro, più generale, dellostesso tipo.
� Il figlio è sostituibile al genitore dovunque appaia, e necondivide struttura e comportamento.
VertebrateMammal
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 30 / 42
Dipendenze e realizzazioniUna dipendenza è una relazione semantica: indica che ilclient dipende, semanticamente o strutturalmente, dalsupplier (variazioni alla specifica del supplier possonocambiare quella del client).
graphics
Renderer
Anche la realizzazione è una relazione semantica: ilsupplier fornisce una specifica, il client la realizza (es:implementazione di interfacce, templates, etc.)
+eat()
<<interface>>
EdibleApple
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 lefrecce 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 nonvice-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 lasemantica dei costrutti UML.Uno stereotipo è una parola chiave tra virgolette e abbinataad 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
<<utility>>
Math
Vector
Lo!stereotipo!«utility»!indica!che!questa!è!una!classe
utility,!cioè!una!collezione!di!variabili!globali!e
operazioni!statiche!usate!da!altre!parti!del!sistema.
<<call>>
Questa!dipendenza!tra!Vector!e!Math!ha!lo!stereotipo
«call»;!significa!che!operazioni!di!Vector!invocano
operazioni!di!Math.
Ingegneria del Software () Introduzione a UML A.A. 2010-2011 34 / 42
Stereotipi come estensioni di UML
Gli stereotipi forniscono significato aggiuntivo ai costruttiUML.Possono essere usati per adattare UML a particolari ambitie piattaforme di sviluppo.Stereotipi, vincoli e regole aggiuntivi vengono raccolti inprofili, che costituiscono uno dei principali meccanismi diestensione 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)
-age : int
+birthdayHappens()
Person
inv:!self.age>=0
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 nonbanale.UML è un linguaggio general-purpose per la modellazione.Non è perfetto, ma è potente e costituisce uno standarddiffuso 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/papyrusUmbrello: 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 suaparteIndividua:
� 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 creatoin un processo o ciclo di sviluppo, nell’ambito dell’analisi deirequisiti.
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 ObjectoryIn realtà la tecnica era già consolidata: studio degli scenaridi operatività degli utilizzatori di un sistemaIn 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, dallapiattaforma, dal linguaggio di programmazione.I requisiti non-funzionali specificano vincoli aggiuntivi, adesempio:
� 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 sistemaNasconde come il sistema lo implementaE’ una sequenza di azioni (con varianti) che producono unrisultato osservabile da un attoreSi 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 progettisoftware.Il diagramma e la modellazione dei casi d’uso aiutanol’interazione con il cliente e migliorano l’estrazione deirequisiti (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 uncatalogo da cui scegliere...vorrei gestire gli ordini da qualunque posto perché viaggiomolto...
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 mieimanufatti...vorrei un catalogo liberamente consultabile da chiunque...vorrei organizzare i manufatti raccogliendoli in categorie...vorrei che gli interessati all’acquisto potessero inviarmi unordine, che io provvederò ad evadere previa una qualcheforma 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)?ClientiAmministratori del negozio onlineReparto ordini
Cosa fanno (casi d’uso)?Il cliente si registra, consulta il catalogo ed effettua acquistiL’amministratore organizza il catalogo, che è diviso incategorieIl reparto ordini riceve ordini da evadereIl 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 altraentità che interagisce col sistema nell’ambito di un’unità difunzionamento (caso d’uso).Un attore è esterno al sistema.Non è necessariamente umano: oggetto fisico, agentesoftware, 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/cosainteragisce 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 altriattori tramite relazioni di generalizationAttori specializzati usano le stesse funzionalità degli attoriche 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 eventualisequenze alternative e/o di errore che un sistema (osottosistema) 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 osu 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, unevento è sempre legato all’entità che lo ha generato.L’attore che inizia un caso d’uso è detto primario, gli altriattori che interagiscono nell’ambito di quel caso d’uso sonosecondari.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 comportamentoprincipale.
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 seguentidomande:
� 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 casod’uso
Interviste con gli esperti del dominio (desiderata benstrutturati)Bibliografia del dominio del sistemaSistemi già esistentiConoscenza 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 dieventi 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 messaggiscambiatiAggiungere eventuali punti di estensioneDescrivere 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
Acquista prodotto
Organizza catalogo
Consulta catalogo
Delimita l’argomento del diagramma, specificando i confinidel sistema.
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 19 / 51
Elementi del diagramma: associazione (1)
Cliente
Consulta catalogo
Collega gli attori ai casi d’uso.Un attore si può associare solo a casi d’uso, classi ecomponenti (che verranno eventualmente associati ad altricasi d’uso, classi e componenti).Un caso d’uso non dovrebbe essere associato ad altri casid’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)
Ufficiale
Lancia missile nucleareesecutore
2
lancio
0..1proceduraLancio
Alcune caratteristiche opzionali comuni a tutte leassociazioni in UML:
� nome� molteplicità� ruoli
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 21 / 51
Elementi del diagramma: generalizzazione
Acquista orologio
Impiegato Persona
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
Acquista prodotto
Effettua pagamento
Consulta catalogo
<<include>>
<<include>>
Una dipendenza tra casi d’uso; il caso incluso fa parte delcomportamento di quello che lo include.L’inclusione non è opzionale ed avviene in ogni istanza delcaso d’uso.La corretta esecuzione del caso d’uso che include dipendeda 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
Acquista prodotto Registra account
<<extend>>
Una dipendenza tra casi d’uso (notare il verso dellafreccia).Il caso d’uso che estende (client) specifica un incremento dicomportamento a quello esteso (supplier).Si tratta di comportamento supplementare ed opzionaleche gestisce casi particolari o non standard.Diverso da una generalizzazione tra casi d’uso:
� in una generalizzazione, entrambi i casi d’uso sonougualmente significativi
� in un extend, il client non ha necessariamente senso sepreso da solo
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 24 / 51
Extension points
Account non registrato
Extension Points
Acquista prodotto
Registra account<<extend>>
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 ilcomportamento viene esteso.Se gli extension points sono molti, alcuni tool possonosupportare la rappresentazione a rettangolo (i casi d’usosono 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 versoquello incluso.Nell’extend la freccia va dal caso d’uso che estende versoquello esteso.Sono entrambi costrutti utili, ma non se ne deve abusare, ola leggibilità ne risente.
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 26 / 51
Esempio diagramma
Cliente
Web store
Evadi ordine
Modifica catalogo
Genera ordine<<include>>
Immetti dati pagamento
<<include>>
Consulta catalogo
<<include>>
Registra account
<<extend>>
Acquista prodotto
Admin
Resp. ordini
Impiegato
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 casid’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’usoManca la parte più importante: la descrizione (specifica) deicasi d’uso!
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 28 / 51
Specifiche del caso d’uso
Ogni caso d’uso ha un nome e una specifica.La specifica è composta da:
� precondizioni: condizioni che devono essere vere primache il caso d’uso si possa eseguire
� sequenza degli eventi: i passi che compongono il casod’uso
� postcondizioni: condizioni che devono essere vere quandoil caso d’uso termina l’esecuzione
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 29 / 51
Esempio specifica caso d’uso
UML 65
Esempio: relazioni tra casi d’uso
UML 66
Modellazione dei casi d’uso
Modellazione di caso d’uso:
Una vista che concentra l’attenzione su come
viene percepito il comportamento di un
sistema sw da parte di un utente esterno.
Le funzionalità di un sistema vengono
suddivise in transazioni (casi d’uso) utili per
ciascuna delle classi di utilizzatori (attori)
UML 67
Specifiche del caso d'uso
• Ogni caso d'uso ha un nome e una specifica.
• La specifica è composta da:
– Precondizioni (entry conditions): condizioni che devono
essere vere prima che il caso d'uso possa essere
eseguito ( sono vincoli sullo stato iniziale del sistema)
– Sequenza degli eventi (flow of events): i passi che
compongono il caso d'uso
– Postcondizioni (exit conditions): condizioni che devono
essere vere quando il caso d'uso termina l'esecuzione
UML 68
Esempio
Caso d'uso: PagamentoIVA
ID: UC1
Attori:Tempo, Fisco
Precondizioni:1. Si è concluso un trimestre fiscale
Sequenza degli eventi:1. Il caso d'uso inizia quando si conclude un
trimestre fiscale.2. Il sistema calcola l'ammontare dell'IVA
dovuta al Fisco.3. Il sitema trasmette un pagamento
elettronico al Fisco.
Postcondizioni:1. Il Fisco riceve l'importo IVA dovuto.
Nome del caso d'uso
Identificatore univoco
Gli attori interessati dal casod'uso
Lo stato del sistema prima che ilcaso d'uso possa iniziare
I passi del caso d'uso
Lo stato del sistema quandol'esecuzione del caso d'uso è
terminata
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 suacompletezza.Il caso d’uso si considera eseguito solo se l’esecuzionearriva 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 clienteIl cliente inserisce nel form il suo nome e indirizzoIl 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: ContrattoPrecondizione: l’impiegato è connessoFlusso 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 particolariPer descrivere correttamente il flusso di eventi quindi:
� Descrive solo gli eventi relativi al caso d’uso, e non quel cheavviene 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 allasequenza principale.Parola chiave Se: indica una ramificazione della sequenzadegli 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 ‘aggiornacarrello’ di un negozio on-line.Possibili ramificazioni, dopo aver aggiunto un articolo alcarrello:
� se il cliente richiede una nuova quantità il sistema aggiornala quantità di quell’articolo
� se il client seleziona rimuovi articolo il sistema eliminaquell’articolo dal carrello
Le sequenze alternative sono invece ramificazioni che nonpossono essere espresse utilizzando il Se.
� Ad esempio dovute a condizioni che si possono verificare inun qualunque momento: il cliente abbandona la pagina delcarrello
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 36 / 51
Esempio ramificazioni
UML 69
Sequenza degli eventi
• La sequenza degli eventi elenca i passi checompongono il caso d'uso
• Comincia sempre con un attore che fa qualcosa perdare inizio al caso d'uso
• Un buon modo per iniziare la sequenza degli eventi è:1. Il caso d'uso inizia quando un <attore> <funzione>
• Ogni passo del caso d'uso dovrebbe avere lastruttura:
<numero> Il <qualcosa> <qualche azione>
UML 70
Esempio: sequenza degli eventi
Pensiamo al caso d'uso NuovoOrdine. I seguenti passidella sequenza degli eventi sono corretti?
1. Incomincia quando si seleziona la funzione “ordinalibro”
2. Il caso d'uso inizia quando il cliente seleziona lafunzione “ordina libro”
3. Vengono inseriti i dati del cliente
4. Il cliente inserisce nel form il suo nome e indirizzo
5. Il sistema verifica i dati del Cliente
sbagliato
corretto
sbagliato
corretto
corretto
UML 71
• UML usa parole chiave per esprimere ramificazione,ripetizione o sequenze alternative
• È bene non eccedere con le ramificazioni• parola chiave Se: indica una ramificazione della
sequenza degli eventi• Sequenze alternative: ramificazioni che non possono
essere espresse utilizzando il Se. Ad esempioramificazioni dovute a condizioni che si possonoverificare in un qualunque momento
• Ripetizioni all'interno di una sequenza:
– Parola chiave Per (For)
– Parola chiave Fintantoché (While)
Ramificazione di una sequenza
UML 72
EsempioCaso 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'articolodal 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:
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 principaleSequenze alternative abbastanza complesse possonoessere descritte separatamente.
� stessa sintassi, si sostituisce ‘caso d’uso’ con ‘sequenzadegli eventi alternativa’
� il primo passo può indicare il punto della sequenzaprincipale da cui si proviene
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 38 / 51
Esempio: apertura conto corrente1 il cliente si presenta in banca per aprire un nuovo c/c2 l’addetto riceve il cliente e fornisce spiegazioni3 se il cliente accetta fornisce i propri dati4 l’addetto verifica se il cliente è censito in anagrafica5 l’addetto crea il nuovo conto corrente6 l’addetto segnala il numero di conto al cliente
Varianti:3 (a) se il cliente non accetta il caso d’uso termina3 (b) se il conto va intestato a più persone vanno forniti i dati
di tutte4 (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 inserimentonuovo conto
2 il sistema richiede i codici degli intestatari3 l’addetto fornisce i codici al sistema4 il sistema fornisce le anagrafiche corrispondenti, e richiede
le condizioni da applicare al conto5 l’addetto specifica le condizioni e chiede l’inserimento6 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 correzionio 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 trauno o più attori e il sistema.Non contiene ramificazioni o sequenze alternative: èsemplicemente la cronaca di un’interazione vera overosimile.
� il concetto risulta più immediato pensando agli attori inmaniera concreta: non un generico cliente, ma Alice o Bob
Una definizione alternativa: un caso d’uso è un insieme discenari possibili se un utente prova a raggiungere un datorisultato
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 edi 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 perspiegare 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 diagrammaLe frecce tra i casi d’uso non sono tratteggiate (- - - - - -> ) oetichettate «extend» o «include»«extend»: la freccia va dal caso che descrive l’eventoalternativo al caso standard«include»: la freccia va dal caso chiamante al caso chedescrive 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 precondizioniMancata connessione alla rappresentazione graficaNomi diversi per le stesse entità nelle rappresentazionigrafica e testualeFlusso eccezionale: mancanza di indicazioni nel flussoprincipale del punto in cui va controllata la condizioneeccezionale
Ingegneria del Software () Il diagramma dei casi d’uso A.A. 2010-2011 45 / 51
Riassumendo
Analizzare il materiale contenente i requisitiCreare un glossario di progetto con parole chiave e unabreve descrizioneCapire chi sono gli attoriEstrarre i casi d’uso più evidentiCominciare ad organizzare i casi d’uso in un diagrammaModellare i casi d’uso come sequenze di eventiRaffinare 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 lamodellazione del comportamento di un sistema.Descrive gli attori che interagiscono con il sistema, cosafanno, e cosa ottengono dal sistema.A questo punto non interessa sapere come il sistemafornisca 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 aun utente di effettuare ricerche di libri. Il bibliotecario devepoter effettuare il prestito e gestire la restituzione del libro.Un utente deve restituire il libro entro una certa data. Se ilprestito risulta scaduto per la prima volta il sistema emetteun avviso, se è la seconda volta il bibliotecario registra estampa una multa. L’utente a questo punto può decidere sepagare la multa subito oppure no. Il sistema devepermettere la registrazione del pagamento.Disegnare il diagramma dei casi d’uso e descrivere lesequenze 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 delpersonale di un’azienda. Per accedere alle operazionebisogna autenticarsi. Le operazioni possibili saranno lamodifica dei dati dell’impiegato, la semplice visualizzazionedei suoi dati, e la cancellazione dei dati.Disegnare il diagramma dei casi d’uso e descrivere lesequenze 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 difar effettuare ricerche al suo personale. All’interno dellalibreria vengono venduti anche dvd video, e cd musicali.Disegnare il diagramma dei casi d’uso e descrivere lesequenze 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 lorichiede. La ricevuta riporta il tipo di transazione,ladata, il numero di conto, la somma, ed il nuovo saldo
• Dopo ciascuna transazione viene visualizzato ilnuovo saldo
Soluzione
User
withdraw
deposit
check
balanceVerify user
<<include>>
<<include>>
<<include>>
withdraw with
receipt
deposit with
receipt
<<extend>>
(print receipt)
<<extend>>
(print receipt)
SoluzioneUse 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 loweramount
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 withdrawoption and print receipt option
…
Use case: deposit with receipt
Precondition: User has selected deposit optionand 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
authorization service. Structure diagrams do not show the details of dynamic behavior, which are illustrated by behavioral
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.
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
• Component Diagram - “Components” on page 147
• Composite Structure Diagram - “Composite Structures” on page 167
• Deployment diagram - “Deployments” on page 201
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 2 / 106
A che punto siamo
Conosciamo i casi d’uso di un sistemaAbbiamo steso una specifica dei requisitiAbbiamo sequenze di eventiAbbiamo 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)
ImplementazioneTest
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 4 / 106
Analisi
Si trovano le entità coinvolteSi 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 delproblema.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 diagrammidiversi, ma gli stessi tipi di diagramma con diversi livelli di
dettaglio (i diagrammi di analisi sono più ‘astratti’ di quelli diprogettazione).
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, cheincapsula stato e comportamento; un’istanza di una classe.Classe: Descrittore di un insieme di oggetti checondividono gli stessi attributi, operazioni, metodi, relazionie comportamento.
Uno dei primi compiti dell’analisi è quello di modellare il dominiodel 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 delproblema (ne parleremo tra poco)Ragionare su queste classi: quali attributi e qualioperazioni devono fornire?Stendere una mappa delle classi e delle loro relazioni.Modellare la dinamica delle classi con i diagrammi dicomportamento.Procedere per raffinamenti successivi fino a quando ilmodello 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 classiabbastanza generiche, e lo si raffina.I costrutti più astratti di UML vengono trasformati in altri piùconcreti che possono essere implementati in un linguaggiodi programmazione OO.Finalmente si considerano i vincoli di piattaforma elinguaggio, 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à delproblema: se la specifica dei casi d’uso è buona i concettibasilari sono già in evidenza.I candidati più probabili sono nomi che compaiono nellaspecifica e nella documentazione.Una ragione in più per tenere un glossario di progetto: leparole nel glossario sono spesso candidati ideali perdiventare classi di analisi.Le classi di analisi non sopravviveranno necessariamentealla 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 perdivenire classi o attributi.
� I predicati nominali: (es: numero del conto corrente) sono ipotenziali candidati per divenire classi o attributi.
� I verbi: (es: aprire) sono potenziali candidati a divenireresponsabilità di classe.
Notate che ancora non parliamo di UML!
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 11 / 106
Analisi CRCClass-Responsibilities-CollaboratorsSi usano post-it divisi in tre sezioni chiamate proprio inquesto modo.Si tratta di un metodo di brainstorming di gruppo checoinvolge sviluppatori, esperti, committenti.Si individuano i nomi delle classi, un insieme ristretto diresponsabilità (cose che la classe sa/fa) e di classicollaboratori (alle quali viene richiestocomportamento/informazione).Le schede sono piazzate su un tavolo, la loro vicinanzafisica 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 alconseguimento di un titolo di riconoscimento.Ogni titolo di riconoscimento è pubblicizzato nel prospettoinformativo di DMUOgni percorso comprende differenti moduliGli studenti di un percorso seguono fino a 8 moduli all’annoAlcuni 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 alconseguimento di un titolo di riconoscimento.Ogni titolo di riconoscimento è pubblicizzato nel prospettoinformativo di DMUOgni percorso comprende differenti moduliGli studenti di un percorso seguono fino a 8 moduli all’annoAlcuni 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 differentipercorsi.Il consiglio di Facoltà è composto da studenti e da staffaccademico o ammistrativoLo staff accademico insegna un numero arbitrario di moduliLo staff accademico supervisiona diversi studenti, ciascunodei quali segue un percorso formativoAlcuni rappresentanti dello staff amministrativo sonoconsiglieri 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 differentipercorsi.Il consiglio di Facoltà è composto da studenti e da staffaccademico o ammistrativoLo staff accademico insegna un numero arbitrario di moduliLo staff accademico supervisiona diversi studenti, ciascunodei quali segue un percorso formativoAlcuni rappresentanti dello staff amministrativo sonoconsiglieri 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 specificoelemento del dominio del problemacorrisponde ad una caratteristica ben identificabile deldominioha un insieme ridotto e definito di responsabilitàha la massima coesione internaha 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 classenon isolata, collabora con un piccolo insieme di altre classievitare il proliferare di classi troppo semplicievitare la concentrazione del modello in poche classicomplesseevitare 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 programmazionescelto
� specifica completa (implementabile)
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 21 / 106
E in UML?
Person
-age : int
+getAge() : int
Person
age = 10
Jim : Person
: Person
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à diornamenti in diagrammi diversi.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 22 / 106
Classi e oggetti in UML
Person
-age : int
+getAge() : int
Person
age = 10
Jim : Person
: Person
Le istanze delle classi (oggetti) hanno una notazione moltosimileIl titolo degli oggetti è sottolineato e del tipo ’nome : classe’,con nome opzionale.Gli oggetti non hanno uno slot per le operazioni, possonodefinire valori per gli attributi.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 23 / 106
Relazione tra classe e oggetto
-age : int
+getAge() : int
Person
age = 10
Jim : Person
<<instanceOf>>
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
-numero : String
-correntista : String
-saldo : double = 0.0
+create(numero : String, correntista : String)
+deposito(somma : double)
+preleva(somma : double)
+getNumero() : String
+getCorrentista() : String
+getSaldo() : double
<<entity>>
ContoBancario
StereotipoNome
Sottosezione
attributi
Sottosezione
operazioni
Visibilità
Operazione!con!ambito!di!classe
Nota: questo livello di dettaglio è tipico delle classi diprogettazione, 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 è obbligatorioLe classi di analisi solitamente contengono solo gliattributi più importanti (quelli che risultano evidentidall’analisi del dominio); spesso specificano solo il nome diun 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 membrocon visibilità pubblica
- private solo le operazioni della classe possonoaccedere ai membri con visibilità privata
# protected solo le operazioni appartenenti alla classeo ai suoi discendenti possono accedere aimembri con visibilità protetta
∼ package ogni elemento nello stesso package del-la classe (o suo sottopackage annidato)può accedere ai membri della classe convisibilità 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 degliattributi per quanto riguarda analisi e progettazione.In ogni classe non ci possono essere due operazioni con lastessa signature.Il nome di attributi ed operazioni è scritto inlowerCamelCase.
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 Pointclass Point{
public $x;
public $y;
// Short description of method moveTopublic 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: costruttorie 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 adaltre operazioni o attributi con ambito di istanza sia conambito di classe.Operazioni con ambito di classe possono accedere solo adaltre operazioni e attributi con ambito di classe (altrimentinon 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 sommaredue interiUsiamo attributi e metodi con ambito di classe per contarequante 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 è limitatoalle classi.Permette di parametrizzare i tipi che compaiono nellaspecifica di una classe.Perché definire come classi diverse un vettore di integer, unvettore di float, un vettore di string, etc.?Conviene molto di più definire un ’vettore di X’, e sostituireX 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 rettangolotratteggiato.Chiaramente servono primitive per istanziare classi basatesui 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 (IntVectornel 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 particolarmenteimportanti in UML:
GeneralizzazioneAssociazione
Vi sono poi altre due relazioni che possono legare le classianche ad altri tipi di elementi:
DipendenzaRealizzazione
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 43 / 106
Generalizzazione
VertebrateMammal
Relazione tassonomica tra un elemento più generale e unoche lo specifica.La freccia parte dall’elemento specifico e punta versoquello 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
Generalizzazione: stili grafici
70 UML Superstructure Specification, v2.0
Examples
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.
Figure 7.41 - Examples of generalizations between classes
Figure 7.42 - Multiple subtype partitions (GeneralizationSets) example
Shape
Polygon Ellipse Spline
Shape
Polygon Ellipse Spline
Separate target style
Shared target style
Female Person
MalePerson
Employee
Person
gender
Female
Person
Male
PersonEmployee
Person
employmentstatus
gender
Female
Person
Male
PersonEmployee
Person
gender
genderemployment
status
employmentstatus
Female
Person
Male
PersonEmployee
Person
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 45 / 106
Generalizzazione: da UML al codice (Java)public class Shape {...}
public class Polygon extends Shape {...}
public class Ellipse extends Shape {...}
public class Spline extends Shape {...}
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 46 / 106
Insiemi di generalizzazione
70 UML Superstructure Specification, v2.0
Examples
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.
Figure 7.41 - Examples of generalizations between classes
Figure 7.42 - Multiple subtype partitions (GeneralizationSets) example
Shape
Polygon Ellipse Spline
Shape
Polygon Ellipse Spline
Separate target style
Shared target style
Female Person
MalePerson
Employee
Person
gender
Female
Person
Male
PersonEmployee
Person
employmentstatus
gender
Female
Person
Male
PersonEmployee
Person
gender
genderemployment
status
employmentstatus
Female
Person
Male
PersonEmployee
Person
Permettono di partizionare lo stesso elemento generale in modidiversi.
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), dicui non è data la specifica.Una classe con almeno un’operazione astratta èautomaticamente una classe astratta.Una classe astratta non è istanziabile... ma i suoi figlipossono esserlo.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 48 / 106
Figli di classi astratte
-origin
-width
-height
+draw()
+getArea() : int
Shape
+draw()
+getArea() : int
Rectangle
+draw()
+getArea() : int
Circle
I figli forniscono il comportamento definito come astratto inShape.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 49 / 106
Polimorfismo
I figli completano la specifica che il genitore ha volutamentelasciato incompleta.Figli diversi forniscono comportamenti diversi alla stessachiamata di funzione.Comportamento diverso di operazioni con la stessasignature è una delle definizioni di polimorfismo, uno deiprincipi cardine del metodo object-oriented.Se i figli non ridefiniscono le operazioni astratte, devonorimanere 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 nelmenù.I piatti vengono tutti preparati ma ciascuno ha un mododiverso 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
Child
Parent1 Parent2
UML supporta l’ereditarietà multipla: un classificatore puòereditare da un numero arbitrario di altri classificatori.A tempo di analisi questo permette di modellareefficacemente situazioni del mondo reale.Tuttavia, classi con ereditarietà multipla dovranno essererisolte a tempo di progettazione se il linguaggio scelto nonla supporta.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 52 / 106
Associazione
PersonCompanyemployeeemployer
*1employs
Si tratta del tipo di relazione più generico: indica solol’esistenza di collegamenti (link) tra le istanze delle classi.Rappresenta l’abilità di un’istanza di mandare messaggi aun’altra istanza.Formalmente, definisce l’esistenza di tuple tra istanze tipate(se o1 è associato a o2, la coppia ordinata (o1, o2) fa partedella relazione).Può coinvolgere più di due classi e la stessa classe più diuna volta.Tra le relazioni è anche la più flessibile e la menovincolante.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 53 / 106
Associazione: alcuni ornamenti
PersonCompanyemployeeemployer
*1employs
Nome: opzionale.Triangolo direzionale: opzionale. Specifica la direzione incui leggere l’associazione (aumenta la leggibilità).Ruoli: opzionali a ciascun estremo.Molteplicità: opzionale a ciascun estremo.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 54 / 106
Associazioni n-arie
40 UML Superstructure Specification, v2.0
Generalizations between associations are best drawn using a different color or line width than what is used for the
associations.
Examples
Figure 7.19 shows a binary association from Player to Year named PlayedInYear.
The solid triangle indicates the order of reading: Player PlayedInYear Year. The figure further shows a ternary association
between Team, Year, and Player with ends named team, season, and goalie respectively.
The following example shows association ends with various adornments.
Figure 7.20 - Association ends with various adornments
The following adornments are shown on the four association ends in Figure 7.20.
• Names a, b, and d on three of the ends.
• Multiplicities 0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
• Specification of ordering on b.
• Subsetting on d. For an instance of class C, the collection d is a subset of the collection b. This is equivalent to the OCL
constraint:
context C inv: b->includesAll(d)
Figure 7.19 - Binary and ternary associations
Team
Year
Player
PlayedInYear
year
*
*season
* *
goalieteam
!
BA
C D
b
{ordered}*
a
0..1
d
{subsets b}
0..11
Si usa un rombo per congiungere i vari estremi; in questocaso non abbiamo coppie ma triple di elementi.Il triangolo direzionale si può usare solo nelle relazionibinarie.Molti ritengono che le relazioni non binarie siano superflue.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 55 / 106
Molteplicità
PersonCompanyemployeeemployer
*1employs
In una relazione n-aria, indica quante istanze della classe inquell’estremo possono partecipare alla relazione dopo averfissato gli altri n-1 estremi.Può essere un numero o un intervallo min..max, con * cheindica 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
DirectoryFile
parent0..1
child
*1*
Un’associazione riflessiva coinvolge la stessa classe più diuna volta.Esempio: gerarchia di file system.Se si sostituisce la molteplicità 0..1 di parent con *, sigenerano grafi invece di alberi.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 57 / 106
Associazioni riflessive e istanze
DirectoryFile
parent0..1
child
*1*
Una possibile realtà che soddisfa l’associazione...
home : Directory
projects : Directory pictures : Directory
memo.txt : File
pic01.jpg : File
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 58 / 106
Navigabilità (1)
Player Yearplayer year
playedInYear
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à nonspecificata (tipico della fase di analisi).Un oggetto di tipo Player sa in quali anni ha giocato, unoggetto di tipo Year non sa quali giocatori giocaronoquell’anno.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 59 / 106
Navigabilità (2)
UML Superstructure Specification, v2.0 41
The following examples show notation for navigable ends.
In Figure 7.21:
• The top pair AB shows a binary association with two navigable ends.
• The second pair CD shows a binary association with two non-navigable ends.
• The third pair EF shows a binary association with unspecified navigability.
• The fourth pair GH shows a binary association with one end navigable and the other non-navigable.
• The fifth pair IJ shows a binary association with one end navigable and the other having unspecified navigability.
Figure 7.22 shows that the attribute notation can be used for an association end owned by a class, because an association
end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make
it perfectly clear that the attribute is also an association end.
Figure 7.21 - Examples of navigable ends
Figure 7.22 - Example of attribute notation for navigable end owned by an end class
bA B
2..51..4
a
E F2..5
f
1..4
e
C D2..5
d
1..4
c
hG H
2..51..4
g
I J2..5
j
1..4
i
bA B
2..51..4
a
E F2..5
f
1..4
e
C D2..5
d
1..4
c
hG H
2..51..4
g
I J2..5
j
1..4
i
A
b: B[*]
Alcuni esempi di navigabilità.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 60 / 106
Notazione pratica per la navigabilità
In pratica, si tende a non specificare la navigabilità di ogniestremo di ogni relazione.Un metodo diffuso è il seguente:
� non si usano le croci� l’assenza di frecce indica navigabilità in entrambe le direzioni� una freccia indica navigabilità in quella direzione e assenza
di navigabilità nell’altraDoppia navigabilità risulta indistinguibile da navigabilità nonspecificata, ma non è un problema in pratica
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 61 / 106
Un esempio completo
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 62 / 106
Attributi come associazioni
52 UML Superstructure Specification, v2.0
Examples
Figure 7.28 - Examples of attributes
The attributes in Figure 7.28 are explained below.
• ClassA::name is an attribute with type String.
• ClassA::shape is an attribute with type Rectangle.
• ClassA::size is a public attribute of type Integer with multiplicity 0..1.
• ClassA::area is a derived attribute with type Integer. It is marked as read-only.
• ClassA::height is an attribute of type Integer with a default initial value of 5.
• 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::shape. It has type Square, a specialization of Rectangle.
• ClassB::height is an attribute that redefines ClassA::height. It has a default of 7 for ClassB instances that overrides the
ClassA default of 5.
• ClassB::width is a derived attribute that redefines ClassA::width, which is not derived.
An attribute may also be shown using association notation, with no adornments at the tail of the arrow as shown in
Figure 7.29.
Figure 7.29 - Association-like notation for attribute
ClassB
id {redefines name}
shape: Square
height = 7
/ width
ClassA
name: String
shape: Rectangle
+ size: Integer [0..1]
/ area: Integer {readOnly}
height: Integer= 5
width: Integer
AreaWindowsize
1
UML permette di rappresentare un attributo di una classecon la notazione tipica di un’associazione.Il nome dell’attributo compare come ruolo insieme alla suamolteplicità.Non ci sono ornamenti dalla parte della classe che contienel’attributo.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 63 / 106
Vincoli di associazione
40 UML Superstructure Specification, v2.0
Generalizations between associations are best drawn using a different color or line width than what is used for the
associations.
Examples
Figure 7.19 shows a binary association from Player to Year named PlayedInYear.
The solid triangle indicates the order of reading: Player PlayedInYear Year. The figure further shows a ternary association
between Team, Year, and Player with ends named team, season, and goalie respectively.
The following example shows association ends with various adornments.
Figure 7.20 - Association ends with various adornments
The following adornments are shown on the four association ends in Figure 7.20.
• Names a, b, and d on three of the ends.
• Multiplicities 0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
• Specification of ordering on b.
• Subsetting on d. For an instance of class C, the collection d is a subset of the collection b. This is equivalent to the OCL
constraint:
context C inv: b->includesAll(d)
Figure 7.19 - Binary and ternary associations
Team
Year
Player
PlayedInYear
year
*
*season
* *
goalieteam
!
BA
C D
b
{ordered}*
a
0..1
d
{subsets b}
0..11
Possono comparire tra parentesi graffe vicino all’estremo diuna relazione.Specificano informazioni aggiuntive sull’insieme di istanzeche partecipano alla relazione.Utili per catturare vincoli del problema durante l’analisi.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 64 / 106
Il vincolo xor
56 UML Superstructure Specification, v2.0
Examples
7.3.11 DataType (from Kernel)
Generalizations
• “Classifier (from Kernel, Dependencies, PowerTypes)” on page 48.
Figure 7.31 - Constraint attached to an attribute
Figure 7.32 - {xor} constraint
Figure 7.33 - Constraint in a note symbol
Stack
size: Integer {size >= 0}
push()
pop()
Account
Person
Corporation
{xor}
Person Companyemployee employer
* 0..1
boss0..1
{self.boss->isEmpty() or
self.employer = self.boss.employer}
Un particolare vincolo che esprime una scelta mutualmenteesclusiva.Un conto è associato a una persona fisica oppure a unapersona giuridica.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 65 / 106
Altri vincoli
56 UML Superstructure Specification, v2.0
Examples
7.3.11 DataType (from Kernel)
Generalizations
• “Classifier (from Kernel, Dependencies, PowerTypes)” on page 48.
Figure 7.31 - Constraint attached to an attribute
Figure 7.32 - {xor} constraint
Figure 7.33 - Constraint in a note symbol
Stack
size: Integer {size >= 0}
push()
pop()
Account
Person
Corporation
{xor}
Person Companyemployee employer
* 0..1
boss0..1
{self.boss->isEmpty() or
self.employer = self.boss.employer}
Possono essere inclusi in note ed espressi in molti modi:OCL, linguaggi di programmazione, linguaggio naturale, . . .Ogni impiegato, se ha un capo, lavora per la stessacompagnia del suo capo.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 66 / 106
Classi di associazione (1)
Spesso può capitare di avere un’associazione tra classi e lanecessità di aggiungere attributi e comportamento che nonsembrano 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 unacompagnia
Si usano le classi di associazione.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 67 / 106
Classi di associazione (2)
44 UML Superstructure Specification, v2.0
7.3.5 BehavioralFeature (from Kernel)
A behavioral feature is a feature of a classifier that specifies an aspect of the behavior of its instances.
Generalizations
• “Feature (from Kernel)” on page 66
• “Namespace (from Kernel)” on page 95
Description
A behavioral feature specifies that an instance of a classifier will respond to a designated request by invoking a behavior.
BehavioralFeature is an abstract metaclass specializing Feature and Namespace. Kinds of behavioral aspects are modeled
by subclasses of BehavioralFeature.
Attributes
No additional attributes
Associations
• ownedParameter: Parameter[*] Specifies the ordered set of formal parameters owned by this BehavioralFeature.
The parameter direction can be ‘in,’ ‘inout,’ ‘out,’ or ‘return’ to specify input,
output, or return parameters. Subsets Namespace::ownedMember
• raisedException: Type[*] References the Types representing exceptions that may be raised during an invocation
of this operation.
Constraints
No additional constraints
Additional Operations
[1] The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same Namespace. It
specifies that they have to have different signatures.
Figure 7.25 - An AssociationClass is depicted by an association symbol (a line) and a class symbol (a box) connected
with a dashed line. The diagram shows the association class Job, which is defined between the two classes Person
and Company.
CompanyPersonJob* 1..*
Job
salary
person company
Si tratta di una classe a tutti gli effetti, chiamata come larelazione.Collegata alla relazione tramite una linea tratteggiata.Possiede tutte le proprietà delle classi e quelle delleassociazioni.La classe di associazione è definita univocamente dai suoiestremi.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 68 / 106
Reificare le classi di associazioneLe classi di associazione sono un ottimo strumento dianalisi... ma nella progettazione?Trasformarle in una forma implementabile significareificarle.Si spezza l’associazione in due e si trasforma in unanormale classe.
Company Person
Job
Company PersonJob
**
1 * * 1
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 69 / 106
Aggregazione e composizione
Si tratta di particolari forme di associazione che rappresentanola relazione whole-part (tutto-parte) tra un aggregato e le sueparti.
Aggregazione: relazione poco forte (le parti esistonoanche senza il tutto; es. i computer e il loro cluster).Composizione: relazione molto forte (le parti dipendonodal tutto e non possono esistere al di fuori di esso; es. lestanze e la casa).
Non è sempre semplice capire quale delle due modella megliouna situazione.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 70 / 106
Aggregazione e composizione: notazione
Aggregazione
ComputerCluster Computer*0..1
Composizione
House Room1 1..*
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 71 / 106
Ancora sulla notazione
42 UML Superstructure Specification, v2.0
Figure 7.23 shows the notation for a derived union. The attribute A::b is derived by being the strict union of all of the
attributes that subset it. In this case there is just one of these, A1::b1. So for an instance of the class A1, b1 is a subset of
b, and b is derived from b1.
Figure 7.24 shows the black diamond notation for composite aggregation.
Changes from previous UML
AssociationEnd was a metaclass in prior UML, now demoted to a member of Association. The metaatribute targetScope
that characterized AssociationEnd in prior UML is no longer supported. Fundamental changes in the abstract syntax make
it impossible to continue targetScope or replace it by a new metaattribute, or even a standard tag, there being no
appropriate model element to tag. In UML 2, the type of the property determines the nature of the values represented by
the members of an Association.
7.3.4 AssociationClass (from AssociationClasses)
A model element that has both association and class properties. An AssociationClass can be seen as an association that
also has class properties, or as a class that also has association properties. It not only connects a set of classifiers but also
defines a set of features that belong to the relationship itself and not to any of the classifiers.
Generalizations
• “Association (from Kernel)” on page 36
• “Class (from Kernel)” on page 45
Figure 7.23 - Derived supersets (union)
Figure 7.24 - Composite aggregation is depicted as a black diamond
A B0..*
/b {union}
0..1
a
A1 B10..*
b1
0..1
a
{subsets b}
Window
SliderHeader Panel
+scrollbar+title +body
11
1
21 1
Aggregazione e composizione possono essere combinate conle altre notazioni per le associazioni.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 72 / 106
Aggregazione: semantica (1)
L’aggregato può in alcuni casi esistere indipendentementedalle parti, ma in altri casi no.Le parti possono esistere indipendentementedall’aggregato.L’aggregato è in qualche modo incompleto se mancanoalcune delle sue parti.È possibile che più aggregati condividano una stessa parte.L’aggregazione è transitiva.L’aggregazione è asimmetrica.
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 dicontenere il tutto.Se il problema richiede di avere cicli, bisogna usare unanormale associazione.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 74 / 106
Esempio di ciclo illegale
A
*
*
:A
:A
:A
Data un’aggregazione riflessiva (es. struttura dati albero), eccoun 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 edistruzione.Il composito può rilasciare una sua parte, a patto che unaltro oggetto si prenda la relativa responsabilità.Se il composito viene distrutto, deve distruggere tutte le sueparti 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 implementatein un linguaggio di programmazione?Dipende dalle caratteristiche del linguaggio e dal tipo emolteplicità dell’associazione.
� puntatori� array� references� oggetti
Alcune associazioni vanno trasformate in una formaimplementabile (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 diprogettazione (le associazioni di analisi tendono ad esserebidirezionali).La navigabilità in un solo senso è vantaggiosa in vistadell’implementazione.Aggregazione e composizione sono spesso aggiunte infase di progettazione.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 79 / 106
Reificare: 1 a 1A è il tutto, B la parte, fortemente legati: una possibilità.
A B
1 1
A B
1 1
Analisi
Progettazione
<<refine>>
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 1A è il tutto, B la parte che può appartenere a molti A: unapossibilità.
A B* 1
A B* 1
Analisi
Progettazione
<<refine>>
Implementata come:A ha un puntatore/reference a B (non può possedere B inmaniera esclusiva)B non ha nulla di A
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 81 / 106
Reificare: molti a 1A è il tutto con molte parti B, che possiede in maniera esclusiva:una possibilità.
A B1 *
A B1 *
Analisi
Progettazione
<<refine>>
Implementata come:A ha un array o lista di B fornita come primitiva dallinguaggioA 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.
A B1 *
A B
Analisi
ProgettazioneVector
1 1 1
*1
11 **1
<<refine>>
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 83 / 106
Molti a molti con classe di associazione
Job*1
Company Person
Company Person
Analisi
Progettazione1 * * 1
Job
* *
Una!persona!ha!un
solo!impego!all'interno!
della!stessa!azienda.
<<refine>>
Il vincolo, implicito nel primo modello, ora va aggiunto inuna nota.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 84 / 106
Dipendenza
UML Superstructure Specification, v2.0 59
Figure 7.35 - Notation for a dependency between two elements
Examples
In the example below, the Car class has a dependency on the Vehicle Type class. In this case, the dependency is an
instantiate dependency, where the Car class is an instance of the Vehicle Type class.
Figure 7.36 - An example of an instantiate dependency
7.3.13 DirectedRelationship (from Kernel)
A directed relationship represents a relationship between a collection of source model elements and a collection of target
model elements.
Generalizations
• “Relationship (from Kernel)” on page 126
Description
A directed relationship references one or more source elements and one or more target elements. Directed relationship is
an abstract metaclass.
Attributes
No additional attributes
Associations
• / source: Element [1..*] Specifies the sources of the DirectedRelationship. Subsets
Relationship::relatedElement. This is a derived union.
• / target: Element [1..*] Specifies the targets of the DirectedRelationship. Subsets Relationship::relatedElement.
This is a derived union.
Constraints
No additional constraints
NamedElement-1 NamedElement-2
«dependencyName»
CarFactory
«instantiate»Car
Una relazione semantica tra elementi (in particolare classi eloro operazioni).Due ruoli: supplier (fornitore) client (cliente); entrambipossono essere insiemi di elementi.La freccia va dal cliente verso il fornitore, lo stereotipoindica il tipo della dipendenza.Una dipendenza significa che il cliente richiede il fornitoreper la propria specifica o implementazione.Il cliente dipende strutturalmente o semanticamente dalfornitore, e se la specifica del fornitore cambia, puòcambiare anche quella del cliente.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 85 / 106
Tipi di dipendenza
Uso: il cliente utilizza alcuni dei servizi resi disponibili dalfornitore per implementare il proprio comportamento.Astrazione: una relazione tra cliente e fornitore in cui ilfornitore è più astratto del cliente.Accesso: il fornitore assegna al cliente un qualche tipo dipermesso di accesso al proprio contenuto.Binding: il fornitore assegna al cliente dei parametri chesaranno 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)
Class1 Class2
+foo()
Class3
<<use>>
<<call>>
SimpleClass2
<<refine>>
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)
ContoBancario Transazione
Quantità
1
1
1 0..*
saldo
1
<<derive>>
Il saldo di un conto può essere derivato dall’elenco delle suetransazioni.
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 ShoppingCartI classificatori del package Ordini possono accedere aiclassificatori (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 ilfornitore è un’interfaccia, e il cliente è la classe che laimplementa.A livello di analisi si può usare la realizzazione anche traaltri elementi del modello per indicare il loro legamespecifica/implementazione.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 92 / 106
Realizzazione di un’interfaccia
+eat()
<<interface>>
EdibleApple
La classe Apple si impegna a fornire il comportamento(operazioni) specificato dall’interfaccia Edible.Lo stereotipo «interface» è usato per indicare unarealizzazione
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 {
@Overridepublic 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 tipoUn’interfaccia ha almeno una classe che la implementa
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 95 / 106
Altri tipi di realizzazione
UML Superstructure Specification, v2.0 125
Notation
A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the
realized element. Figure 7.71 illustrates an example in which the Business class is realized by a combination of Owner
and Employee classes.
7.3.46 RedefinableElement (from Kernel)
A redefinable element is an element that, when defined in the context of a classifier, can be redefined more specifically or
differently in the context of another classifier that specializes (directly or indirectly) the context classifier.
Generalizations
• “NamedElement (from Kernel, Dependencies)” on page 93
Description
A redefinable element is a named element that can be redefined in the context of a generalization. RedefinableElement is
an abstract metaclass.
Attributes
• isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is true,
then it is not possible to further specialize the RedefinableElement. Default value is false.
Associations
• / redefinedElement: RedefinableElement[*] The redefinable element that is being redefined by this element. This is
a derived union.
• / redefinitionContext: Classifier[*] References the contexts that this element may be redefined from. This is
a derived union.
Constraints
[1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the
redefinition contexts for each redefined element.
self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e))
Figure 7.71 - An example of a realization dependency
Business
Owner Employee
Un tipo più astratto di realizzazione: la classe Business èrealizzata da una combinazione delle classi Owner edEmployee.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 96 / 106
Package
utility.conversion
Entità di raggruppamento.Raggruppa elementi logicamente coesi tra loro.Fornisce un namespace all’interno del quale ogni elementoè definito univocamente dal suo nome.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 97 / 106
Notazioni package
UML Superstructure Specification, v2.1 111
Notation
A package is shown as a large rectangle with a small rectangle (a “tab”) attached to the left side of the top of the large
rectangle. The members of the package may be shown within the large rectangle. Members may also be shown by
branching lines to member elements, drawn outside the package. A plus sign (+) within a circle is drawn at the end
attached to the namespace (package).
• If the members of the package are not shown within the large rectangle, then the name of the package should be placed
within the large rectangle.
• If the members of the package are shown within the large rectangle, then the name of the package should be placed
within the tab.
The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (‘+’ for
public and ‘-’ for private). Package elements with defined visibility may not have protected or package visibility.
Presentation Options
A tool may show visibility by a graphic marker, such as color or font. A tool may also show visibility by selectively
displaying those elements that meet a given visibility level (e.g., only public elements). A diagram showing a package
with contents must not necessarily show all its contents; it may show a subset of the contained elements according to
some criterion.
Elements that become available for use in an importing package through a package import or an element import may have
a distinct color or be dimmed to indicate that they cannot be modified.
Examples
There are three representations of the same package Types in Figure 7.63. The one on the left just shows the package
without revealing any of its members. The middle one shows some of the members within the borders of the package, and
the one to the right shows some of the members using the alternative membership notation.
7.3.38 PackageableElement (from Kernel)
A packageable element indicates a named element that may be owned directly by a package.
Generalizations
• “NamedElement (from Kernel, Dependencies)” on page 99
Figure 7.63 - Examples of a package with members
TypesTypes
Integer
Time
PointShape
Types
Modi diversi di rappresentare un package e il suo contenuto.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 98 / 106
Visibilità nei package
Ogni elemento di un package (ad es. una classe) ha unavisibilità associata, che può essere public (+) o private (-).Quando un package viene importato o acceduto, glielementi privati non risultano visibili dall’esterno.Di solito è opportuno limitare al massimo il numero dielementi pubblici, proprio come è opportuno limitare gliattributi e le operazioni pubbliche in una classe.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 99 / 106
Esempio package
Club
+AssociazioneClub
+RegoleClub+Benefici
-RegoleIscrizione
DettagliSocio
+Socio
<<import>>
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 dianalisi, per scomporre lo spazio logico del modello insottospazi considerabili separatamente.Un package raggruppa classi molto coese tra loro (lamaggior parte delle comunicazioni di queste classe avvienecon altre classi dello stesso package).Se una classe deve accedere ad una classe in un packagediverso, deve esistere una dipendenza «import» oppure«access».Sono proibiti i cicli nelle dipendenze tra package: senecessario, 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’architetturalogica o fisica di un sistema indipendemente dal tempo.Le classi e le loro istanze, gli oggetti, sono i mattoni con iquali si costruisce un sistema.I diagrammi di struttura aiutano sia in fase di analisi che diprogettazione, in quanto possono essere usati a diversilivelli 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 diagrammaUML 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 dauno o più persone. Un palazzo è composto da uno o piùappartamenti e possiede un’operazione privata senzaparametri 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 UMLdelle classi:Si deve modellare un singolo viaggio in treno. Un treno ha200 posti, ciascuno dei quali numerato e accessibile tramiteuna prenotazione che contiene la stazione di partenza equella di arrivo (per semplicità, si assumano integer). Ilviaggiatore prenota un qualunque numero di posti, eovviamente più viaggiatori possono occupare lo stessoposto 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 perrappresentare:Tutti i filosofi sono uomini e tutti gli uomini sono mortali. Tuttigli uomini hanno un nome. Ogni filosofo è discepolo di almassimo un altro filosofo, e un filosofo può avere unqualunque numero di discepoli. Inoltre, un filosofo puòprodurre un qualunque numero di opere, ciascuna dellequali ha un titolo. Socrate, Platone e Aristotele sono filosofi;Platone è discepolo di Socrate e Aristotele è discepolo diPlatone. Platone ha scritto ‘La Repubblica’.
Ingegneria del Software () I diagrammi di struttura A.A. 2010-2011 106 / 106