Introduzione a UML Modellare

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.


Perché Modellare

Per comprendere il soggetto in analisi.Per conoscere il soggetto in analisi (fissando ciò che si ècompreso).Per comunicare la conoscenza del soggetto.


I progetti software sono 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?


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.


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


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.


L come Linguaggio

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

semplice notazione grafica.

Un modello UML è costituito da un insieme di elementi che

hanno anche una rappresentazione grafica.

Il linguaggio è semiformale perché descritto in linguaggio

naturale e con l’uso di diagrammi, cercando di ridurre al

minimo le ambiguità.

Ha regole sintattiche (come produrre modelli legali) e regole

semantiche (come produrre modelli con un significato).


Sintassi e semantica: esempio

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.


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


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.


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.


Object-oriented

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

linguaggio per la modellazione orientata agli oggetti.Questo include sia l’analisi che la progettazione orientata

agli oggetti (OOA e OOD, rispettivamente):

� analisi: capire cosa deve fare il sistema, senza occuparsi

dei dettagli implementativi

� progettazione: capire come il sistema raggiunge il suo

scopo, come viene implementato

UML offre strumenti di modellazione OO in entrambi gli

ambiti; frammenti differenti di UML sono impiegati in diverse

fasi del processo di sviluppo (anche se UML stesso non

fornisce indicazioni sul suo utilizzo).


Object-oriented

OO: un paradigma che sposta l’enfasi della

programmazione dal codice verso le entità su cui esso

opera, gli oggetti.Una rivoluzione copernicana cominciata dagli anni ’60 e

proseguita, lentamente, fino ad affermarsi negli anni ’90.

I principi cardine furono proposti separatamente e solo

successivamente integrati in unico paradigma.

Principi OO comunemente accettati sono: Abstraction,

Encapsulation, Inheritance, Polymorphism.


Principi OO

Abstraction : usare classi per astrarre la natura e le

caratteristiche di un oggetto, che è un’istanza della propria

classe di appartenenza.

Encapsulation : nascondere al mondo esterno i dettagli

del funzionamento di un oggetto; gli oggetti hanno accesso

solo ai dati di cui hanno bisogno.

Inheritance : classi possono specializzare altre classi

ereditando da esse e implementando solo la porzione di

comportamento che differisce.

Polymorphism : invocare comportamento diverso in

reazione allo stesso messaggio, a seconda di quale oggetto

lo riceve.


Meta-Object Facility

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

La relazione classe/istanza costituisce le fondamenta

stessa del linguaggio.

UML stesso, il linguaggio, è un’istanza!

UML fa parte di un’architettura standardizzata per la

modellazione di OMG chiamata MOF (Meta-Object Facility).

Si può vedere MOF come un linguaggio per creare

linguaggi, uno dei quali è UML.


Il metamodello UML

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

di un elemento del livello superiore.

� un elemento di M0 è la realtà da modellare

� un elemento di M1 è un modello che descrive la realtà

� un elemento di M2 è un modello che descrive modelli

(metamodello); UML è qui

� un elemento di M3 è un modello che descrive metamodelli

(meta-metamodello); MOF è qui

OMG usa MOF per definire altri linguaggi oltre a UML.

Tutti i linguaggi basati su MOF e i modelli con essi prodotti

possono essere serializzati e scambiati tramite lo standard

XMI (XML Metadata Interchange).


Semplificando...

Si può dire che UML è definito tramite un modello UML (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.


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


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)


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


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


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


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


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


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


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


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


Relazioni

Gli elementi del modello possono essere collegati darelazioni.Rappresentate graficamente tramite linee.Possono avere un nome.Quattro sottotipi fondamentali:

� Association� Generalization� Dependency� Realization


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


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


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.


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


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.


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.


OCL (1)

Object Constraint Language (OCL) è un linguaggio,

approvato e standardizzato da OMG, per la specifica di

vincoli. Si usa assieme ad UML e a tutti i linguaggi

dell’architettura MOF.

Non è obbligatorio, ma aggiunge rigore formale al modello.

Specifica condizioni che devono essere soddisfatte dalle

istanze di una classe: i vincoli sono espressioni booleane

considerate true.

Un tool UML può usare OCL

� per validare il modello

� per generare codice


OCL (2)

Un vincolo OCL opera in un determinato contesto,

specificando proprietà soddisfatte da tutte le istanze di quel

contesto.

Il contesto può essere una classe, un suo attributo o una

sua operazione.

I vincoli hanno un tipo che descrive l’ambito della loro

validità.

context Car inv:fuel>=0

Questo vincolo si applica alla classe Car ed è un invariante

(sempre valido).


Tipi di vincoli in OCL

inv: Invariante, sempre valido nel contesto.

pre: Nel contesto di un’operazione, una precondizione per

la sua esecuzione.

post: Nel contesto di un’operazione, una postcondizione

vera dopo l’esecuzione.

body: Definisce una query nel contesto.

init: Definisce il valore iniziale nel contesto.

derive: Definisce un attributo derivato del contesto.


OCL nei diagrammi (1)


OCL nei diagrammi (2)

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


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.


Alcuni tool

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


Il diagramma dei casi d’uso

Angelo Di Iorio(dal materiale del Prof. Ciancarini, Dott. Favini e Dott.ssa Zuppiroli)

A.A. 2010-2011

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

Il diagramma dei casi d’uso

Si tratta di un diagramma che esprime un comportamento,desiderato o offerto.L’oggetto esaminato è solitamente un sistema o una 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.


Un esempio: conto in banca


I casi d’uso

I casi d’uso esistono da prima dei diagrammi UML!Proposti da Ivar Jacobson nel 1992 per il metodo 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


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.


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


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


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?


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


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


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!


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?


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.


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.


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.


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?


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


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]


Elementi del diagramma: sistema

Applicazione web

Acquista prodotto

Organizza catalogo

Consulta catalogo

Delimita l’argomento del diagramma, specificando i confinidel sistema.


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.


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


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.


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.


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


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


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.


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


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!


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


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


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>


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


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


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


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!


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


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:


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


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


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


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


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.


Un esempio completo: conto in banca

Vedi PDF allegato.


Errori tipici sui diagrammi

Diagrammi di flusso invece di casi d’uso: un caso d’uso èuna sequenza di azioni, non una singola azione!Nome del caso d’uso che appare più volte nel 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


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


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


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.


Esercizi


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.


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.


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.


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


• Prompt user for amount of deposit

• Open slot

• Get check

• (print receipt)

• Print (balance + deposited amount)

Soluzione

Use case: check balance

Precondition: User has selected balance

option

Main flow:


• Print balance

Soluzione

Use case: verify user

Precondition: none

Main flow:

• User enters ID card

• User enters PIN number

• System checks validity of card and number

Exceptional flow:

• If combination is not valid, reject user

Soluzione

Use case: withdraw with receipt

Precondition: User has selected 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


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


Fasi di sviluppo

Requisiti (decidere cosa deve essere fatto)Analisi (dare struttura ai requisiti)

Progettazione (decidere come implementare il sistema

analizzato)

ImplementazioneTest


Analisi

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


Analisi vs. Progettazione

L’analisi modella i concetti chiave del dominio 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).


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.


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.


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.


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


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!


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.


Esempio CRC


Esempio Classi di Analisi (1/2)

De Montfort University (DMU) offre corsi di laurea modulari,e altri tipi di percorsi formativi ciascuno dei quali porta 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’)



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


Soluzione De Montfort University



La DMU è composta di 6 FacoltàOgni facoltà definisce un numero di soggetti (‘contabilità’,‘ragioneria’, etc.) ciascuno dei quali si occupa di 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



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


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


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


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)


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.


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.


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


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.


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.


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


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.


Attributi, operazioni e visibilità


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


Dalle classi al codice (Java)

public class User {

private Long id;

String name;

protected Boolean enabled;

protected String emailAddress;

protected String password;

...}


Dalle classi al codice (Java)public class User {

...

public void enable() {...}

public Boolean isValidPassword(String password) {return null;}

public Boolean isEnabled() {return null;}

public void changePassword(String newPassword) {...}

}


Come si esprime in UML?class Studente extends Persona {

private String name;private String cognome;protected SchedaImmatricolazione immatricolazione;

public String getName() {...}

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

public SchedaImmatricolazione getImmatricolazione() {...}

}


Ambito

Ambito di istanza:� gli oggetti hanno una propria copia degli attributi, quindi

oggetti diversi possono avere diversi valori negli attributi� Le operazioni agiscono su oggetti specifici

Ambito di classe:� gli oggetti di una stessa classe condividono lo stesso valore

per un attributo� le operazioni non operano solo su una particolare istanza

della classe, ma alla classe stessa. Ad esempio: costruttorie distruttori di classe.

� rappresentato sottolineando l’attributo/operazione� analogo alla parola chiave static in Java


Ambito e accessibilità

Operazioni con ambito di istanza possono accedere sia 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à.


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.


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;}}


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!


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.


Binding esplicito

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


Binding implicito

Vector<int,100>

Si usa il nome della classe seguito dai parametri di binding.Pro: più compatto.Contro: la classe non ha un suo nome proprio (IntVectornel binding esplicito).


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


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.


Generalizzazione: stili grafici


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


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


Generalizzazione: da UML al codice (Java)public class Shape {...}

public class Polygon extends Shape {...}

public class Ellipse extends Shape {...}

public class Spline extends Shape {...}


Insiemi di generalizzazione


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


Shape


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.


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.


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.


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.


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.


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.


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.


Associazione: alcuni ornamenti


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


Associazioni n-arie


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.


Molteplicità


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


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.


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


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.


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


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


Un esempio completo


Attributi come associazioni


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.


Vincoli di associazione


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.


Il vincolo xor


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.


Altri vincoli


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.


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.


Classi di associazione (2)


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.


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


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.


Aggregazione e composizione: notazione

Aggregazione

ComputerCluster Computer*0..1

Composizione

House Room1 1..*


Ancora sulla notazione


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.


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.


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.


Esempio di ciclo illegale

A

*

*

:A

:A

:A

Data un’aggregazione riflessiva (es. struttura dati albero), eccoun diagramma degli oggetti non valido.


Composizione: semantica (1)

Ogni parte può appartenere ad un solo composito per volta.Il composito è l’unico responsabile di tutte le sue parti:questo vuol dire che è responsabile della loro creazione 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.


Un esempio completo


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.


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.


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


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


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


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


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.


Dipendenza


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.


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.


Dipendenze fornite da UML (1)

Uso:� «use»: il cliente richiede il fornitore per la sua

implementazione completa� «call»: il cliente invoca il fornitore (che è un’operazione o la

classe che la contiene)� «responsibility»: un obbligo o contratto che il cliente ha

verso il fornitore� «send»: il cliente (solitamente un’operazione) manda un

messaggio al fornitore� «instantiate»: il cliente può creare istanze del fornitore


Dipendenza: esempi (1)

Class1 Class2

+foo()

Class3

<<use>>

<<call>>

SimpleClass2

<<refine>>


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



ContoBancario Transazione

Quantità

1

1

1 0..*

saldo

1

<<derive>>

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



Il package WebShop contiene una copia delle classi(classificatori) del package ShoppingCartI classificatori del package Ordini possono accedere aiclassificatori (pubblici) del package Personale


Realizzazione

Si tratta di una relazione semantica in cui il fornitore

rappresenta una specifica, e il cliente la implementa.L’esempio canonico di realizzazione è quello in cui 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.


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


Da UML al codice (Java)

interface Edible {public void eat();

}

public class Apple implements Edible {

@Overridepublic void eat() {}

}


Classi, sottoclassi e interfacce

Le interfacce sono simili alle classi (astratte) ma non hanno‘implementazione’Una classe astratta può avere alcuni metodi astratti(implementati nelle sottoclassi) e altri non astratti. Puòessere quindi parzialmente definita.Una classe può avere da zero a più istanze del suo tipoUn’interfaccia ha almeno una classe che la implementa


Altri tipi di realizzazione


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.


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.


Notazioni package


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.


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.


Esempio package

Club

+AssociazioneClub

+RegoleClub+Benefici

-RegoleIscrizione

DettagliSocio

+Socio

<<import>>

Club

+AssociazioneClub

+Benefici

+RegoleClub

+DettagliSocio

+DettagliSocio::Socio

-RegoleIscrizione


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.


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.


Esercizi


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.


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.


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


Date post:	11-Feb-2017
Category:	Documents
Upload:	vohanh
View:	228 times
Download:	4 times

Introduzione a UML Modellare

Documents