a.a. 2000-2001 08UML.1

05 UML (Versione 1.3)

a.a. 2000-2001 08UML.2

Fasi del ciclo di vita del SW(secondo UML)

•Quattro fasi principali– Inception: definizione degli obbiettivi del progetto

– Elaboration: pianificazione, individuazione delle specifiche e della architettura di riferimento

– Construction: realizzazione

– Transition: consegna del SW all’utente

time

Inception Elaboration Construction Transition

Major milestones

a.a. 2000-2001 08UML.3

Iterationi

Inception Elaboration Construction Transition

preliminaryiteration(s)

iteration#1

iteration#2. . .

iteration#n

iteration#n+1

iteration#n+2 . . .

iteration#n

iteration#n+1 . . .

Releases

time

a.a. 2000-2001 08UML.4

Iterative Development

Project Management

Process Configuration

RequirementsAnalysis

ArchitectureLevel

Class Level

Implementation

Test

Design

preliminaryiteration(s)

iter.#1

PhasesProcessComponents

Iterations

Elaboration Construction TransitionInception

SupportingComponents

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

One iteration

a.a. 2000-2001 08UML.5

Diagrammi UML

• Grafi (nodi ed archi)

• Relazioni visuali– connessione (linee che formano un cammino)

– contenimento (figura geometrica 2D)

– connessione visuale (vicinanza tra due simboli)

• Costrutti grafici

a.a. 2000-2001 08UML.6

Costrutti grafici

• IconeUna icona e’ di dimensione e forma determinate, non puo’ essere modificato o ridimensionata. Le icone possono apparire all’interno di un simbolo; come un terminatore o come un simbolo isolato collegato o meno ad un cammino.

• Simboli bidimensionaliI simboli bidimensionali hanno altezza e ampiezza variabili e possono espandersi per contenere altri elementi, come ad esempio stringhe o altri simboli. I cammini sono connessi a simboli bidimensionali.

a.a. 2000-2001 08UML.7

Costrutti grafici

• CamminiConcettualmente un cammino e’ una singolo elemento topologico, I segmenti che lo compongono possono essere modificati graficamente.Gli archi e i cammini sono connessi ad entrambi gli estremi consimboli. Un cammino puo’ avere un terminatore, ovvero una icona che appare vicino alla fine del cammino e che ne qualifica il significato.

• StringheUML assume che per ogni stringa sia definita una sintassi rispetto alla quale essa possa essere analizzata. Per esempio, esiste la sintassi pergli attributi, gli operatori e le transizioni. Ciascuna di esse e’ soggettaad eventuali estensioni definite dagli strumenti di supporto all’analisi.

a.a. 2000-2001 08UML.8

Il Ruolo Dei ToolsUtilizzando uno strumento CASE e’ possibile rappresentare collegamenti addizionali tra gli elementi del linguaggio.

Questi legami possono essere definiti dinamicamente epossono permettere l'accesso ad altre componenti sia in modo grafico che in modo testuale.

I legami dinamici invisibili tra elementi della notazione sono parte integrante del linguaggio ma la definizione di UML non li prescrive.

La definizione di queste informazioni e’ delegata ai produttori degli strumenti di supporto.

a.a. 2000-2001 08UML.9

Ex: Note

a.a. 2000-2001 08UML.10

Constraint (Vincoli)

Un vincolo viene rappresentato da una stringa di testo racchiusa tra parentesi graffe ({}). UML non prescrive il linguaggio in cui esprimere i vincoli. Ogni singolo produttore di strumenti di supporto potrà specificare inquale linguaggio formale si possono esprimere i vincoli. Ad ogni modo essi si potranno esprimere come frasi inlinguaggio naturale.

a.a. 2000-2001 08UML.11

Use case diagram

a.a. 2000-2001 08UML.12

Use Case

• Un Use Case rappresenta una tipica interazione tra un utente ed un sistema. Un use case:

– cattura una qualche funzione visibile dall’utente

– fornisce all’utente un risultato tangibile

• Un Use Case si ottiene attraverso l’interazione tra analista ed utente

• Durante le fasi preliminari del processo di sviluppo non e’opportuno scendere troppo nel dettaglio. Quello che serve e’ una semplice descrizione della funzionalita’ da realizzare.

a.a. 2000-2001 08UML.13

Use Case: Attori

•Uno Use Case definisce un particolare modo di usare un sistema, il quale offre servizi e funzionalità in risposta aeventi prodotti da attori esterni.

•Uno Use Case e’ formulato sulla base delle funzionalità offerte dal sistema così come sono percepite dagli utenti.

•Un attore e’ un ruolo che un utente (una persona o un sistema esterno) gioca interagendo con il sistema.

•Lo stesso utente puo’ essere rappresentato da più di un attore (puo’ avere più ruoli).

•Piu’ utenti possono essere rappresentati dallo stesso attore.

a.a. 2000-2001 08UML.14

Use case nella fase di Analisi dei requisiti

La fase di analisi produce uno schema use-case

Tale schema puo’ essere parte del contratto con l’utente

E’ possbile coinvolgere immediatamente l’utente nella fase di analisi

Uno schema use-case garantisce la comprensione dei requisiti funzionali

Use-CaseModeling

Requisiti

Use-Case Model to agree on

Customer Questions/Answers

a.a. 2000-2001 08UML.15

Use case diagrams

• Un Use Case diagram e’ un grafo i cui nodi possono essere:attori e Use Case (eventualmente racchiusi in un box), mentre gli archi possono rappresentare la comunicazione tra gli attorie gli Use Case, oppure i legami d’uso tra Use Case o ancora l’estensione di uno Use Case da parte di un altro.

a.a. 2000-2001 08UML.16

a.a. 2000-2001 08UML.17

Componenti di un diagramma use case

ATTOREUse Case

associazione

estensione

inclusione

generalizzazione

<<extend>>

<<include>>

Relazioni

a.a. 2000-2001 08UML.18

Studente

Billing System

Register for Courses

This use case provides the capability for a student to select courses for a specified semester.

External system responsible for student billing.

Use case diagram

Studentefuoricorso

a.a. 2000-2001 08UML.19

Use case diagram

Select Courses to Teach

Professor

Select a pair <professor,course>

X

a.a. 2000-2001 08UML.20

Associazione• La partecipazione di un attore ad uno Use

Case e’ rappresentata da un arco tra il simbolo dell’attore e il simbolo di Use Case;si dice che l’attore “comunica” con lo Use Case

Financial PlannerMarket Analysis

a.a. 2000-2001 08UML.21

InclusioneUna relazione d’inclusione tra Use Case è rappresentata

da una freccia tra lo Use Case che include e quello chee’ incluso. La freccia è etichettata con lo stereotype «include». Una relazione d’inclusione da uno Use Case A ad uno Use Cases B, indica che ogni istanza delloUse Case A includera’ anche il comportamento specificato per lo Use Case B.

Market Analysis Printing Reports

<<include>>

a.a. 2000-2001 08UML.22

Registrar Validation

Maintain Courses

Maintain Student Information

Maintain Professor Information

Registrar

<<include>>

<<include>>

<<include>>

Gestore del sistema di iscrizione

Autenticazionedel gestore

This use case provides the capability for the Registrar to maintain professor information needed by the Registration System.

a.a. 2000-2001 08UML.23

Use Case: Associazioni

• Estende– Una relazione estende tra Use Case e’ rappresentata da

una freccia dallo Use Case che definisce l’estensione allo Use Case base. La freccia e’ etichettata con lostereotype «extend». Una relazione estende tra uno Use Case A ed uno Use Case B indica che ogni istanza di uno Use Case B puo’ includere (con riferimento acondizioni particolari specificate nell’estensione) il comportamento definito dallo Use Case A. Per uno stesso Use Case, i comportamenti definiti attraversodiverse estensioni possono occorrere all’interno di ogni singola sua istanza.

a.a. 2000-2001 08UML.24

Use Case: extend & include

a.a. 2000-2001 08UML.25

Use Case: generalizzazione

a.a. 2000-2001 08UML.26

Processo di sviluppo “Use Case Driven”

Capture, Clarify and Validate the Use Cases

Analyze

Realizethe Use Cases

Design andImplementation Verify that the

Use Cases arefulfilled

Test

All process components, from requirements capture to test, are driven by use cases

Use cases bind these work steps together

a.a. 2000-2001 08UML.27

Class diagram

a.a. 2000-2001 08UML.28

Class diagram

• Un Class Diagram descrive gli oggetti presenti nel sistema ed ivari tipi di relazioni statiche esistenti tra essi:

• associazioni (persona vive citta’)

• aggregazioni (ruota parte di automobile)

• subtype (lavoratoree’ una persona)

• Gli oggetti sono descritti tramite Classi con attributi, metodi evincoli

CheckingAccountSavingsAccount

Branch BankCard

Customer

has

Account

1..*

1..*

Transaction

a.a. 2000-2001 08UML.29

Classi e Oggetti: principi generali

• Un oggetto puo’ essere:– una cosa tangibile e/o visibile

– il risultato di un processo di astrazione

– qualcosa verso la quale sono indirizzate delle azioni

• Caratteristiche generiche di un oggetto:– identità

– comportamento

– stato

a.a. 2000-2001 08UML.30

Classi e Oggetti: principi generali• Stato

– rappresenta le proprieta’ (statiche) ed i valori (dinamici) ditali proprieta’

• Comportamento– e’ il modo in cui un oggetto agisce e reagisce quando

sollecitato da messaggi o in conseguenza a cambiamenti di stato

– lo stato di un oggetto rappresenta anche il risultato cumulato del suo comportamento

• Identita’– e’ la proprietà di ogni oggetto di essere distinto da ogni

altro oggetto indipendentemente dai suoi valori

a.a. 2000-2001 08UML.31

Classi e Oggetti: principi generali• La classificazione e’ una delle astrazioni piu’ potenti e

piu’ usate• Una classe rappresenta un insieme di oggetti che

condividono una struttura ed un comportamento comune

• Un oggetto e’ una istanza di una classe• Gli attributi di una classe rappresentano l’astrazione

delle proprieta’ statiche degli oggetti che la classe rappresenta

• I metodi di una classe rappresentano l’astrazione degli aspetti comportamentali degli oggetti che laclasse rappresenta

a.a. 2000-2001 08UML.32

Classi e oggetti: principi generali

• Il mondo delle Classi e quello degli oggetti sono allo stesso tempo:– intimamente correlati (attraverso la relazione diinstance_of )

– concetti separati

• Per la quasi totalità della applicazioni:– le classi sono statiche, rappresentano cioe’ la

modellizzazione degli aspetti piu’ invarianti del problema

– gli oggetti, al contrario, vengono continuamente creati edistrutti durante l’esecuzione del programma

a.a. 2000-2001 08UML.33

Principi generali: Incapsulamento

• Una classe e’ composta normalmente da 4 parti:– + una interfaccia pubblica, composta da metodi

disponibili per ogni altra classe– # una interfaccia protetta, composta da proprieta’ statiche

e metodi disponibili per ogni sottoclasse diretta o indiretta– - una parte privata, composta da proprieta’ statiche e da

metodi accessibili solo dalla classe stessa– una implementazione che realizza lo stato e il

comportamento• Il modo con il quale e’ mantenuto lo stato di un oggetto e con

il quale sono realizzati i metodinon e’ visibile all’esterno.

a.a. 2000-2001 08UML.34

Classi e oggetti: UML

• Una classe descrive un insieme di oggetti aventi struttura comportamento e relazioni simili.

• UML definisce la notazione per rappresentare classi di oggetti e per specificare le loro proprieta’.

• Le classi sono dichiarate nel Class Diagram e poi usate negli altri diagrammi.

• UML definisce una notazione grafica per dichiarare e usare le classi, cosi’ come definisce una notazione testualeper fare riferimento alle classi nella descrizione di altre componenti del modello

a.a. 2000-2001 08UML.35

Convenzioni UML

• Nome della Classe– nome semplice : SensoreDiTemperatura– cammino : java::awt::Rectangle

• Nome di attributi– nome semplice : inFunzione– nome /tipo : inFunzione : boolean– nome/ tipo/ valore iniziale: inFunzione : boolean = true

• Nome operazioni– nome semplice : calcolaTemperatura()– nome/ parametri : impostaAllarme (t :float)– nome/ tipo : calcolaTemperatura(): float

a.a. 2000-2001 08UML.36

Active classJava ed altri linguaggi OO prevedono il concetto di oggetto attivo. Se una classe modella oggetti che posseggono processi (threads) e quindi oggetti che lavorano in “concorrenza” con altri la classe e’ detta Attiva.

a.a. 2000-2001 08UML.37

Responsabilita’• Nelle fasi iniziali del progetto puo' essere

utile indicare in modo generico i compiti (responsabilita') di una classe

Spedizione

Responsibilities

mantiene le informazioni su prodotti spediti a fronte di un ordine

attributi

operazioni/metodi

nome della classe

a.a. 2000-2001 08UML.38

Relazioni: Generalization

• Classica relazione IS-A

SensoreImpermiabile

SensoreDiTemperatura

inFunzione : boolean = truepubblicoprotettoprivato

calcolaTemperatura()impostaAllarme()maxTemperatura()minTemperatura()

a.a. 2000-2001 08UML.39

Relazioni: Binary Association• Classiche relazioni ER binarie

• nome (con un verso di lettura)• cardinalita’ (molteplicita’) invertite rispetto ER• ruoli• verso di navigazione• visibilita'

SensoreImpermiabile

Postazione

SensoreDiTemperatura

inFunzione : boolean = truepubblicoprotettoprivato

calcolaTemperatura()impostaAllarme()maxTemperatura()minTemperatura()

1..11..*

+contiene

1..1

+installato presso

1..*

PRESSO >

a.a. 2000-2001 08UML.40

Verso di navigazione e visibilita’

UserGroup User

*1 *

+user

1

Password

*1 *1

-key+owner

a.a. 2000-2001 08UML.41

Molteplicita’

Esempi di molteplicita’:– 1 (corrisponde a 1.. 1)– * (corrisponde a 0.. n)– 0.. 2, 4..* (qualunque numero tranne 3)– 2,4 (o 2 o 4)

a.a. 2000-2001 08UML.42

Relazioni: Association class• Relazione + attributi

• Classe + relazione

• metarelazioni (relazione tra relazioni)!!!!

a.a. 2000-2001 08UML.43

Vincolo xor

a.a. 2000-2001 08UML.44

Relazioni : Dependency

• Usate quando A “dipende” da B e quindi un cambiamento di B puo’ influenzare A ad esempio:– la implementazione di un metodo di una classe

usa un’altra classe (<< use >>)

• Uml fornisce 17(?) differenti stereotipi per tali relazioni....

<<......>>

a.a. 2000-2001 08UML.45

Dependency

a.a. 2000-2001 08UML.46

Elementi derivati

Si premette un / al nome

a.a. 2000-2001 08UML.47

Qualificatori

• Un attributo (od un insieme di attributi) che partiziona un insieme di instanze associate ad una instanza raggiunta attraverso una associazione. N.B. Gli attributi sono attributi della associazione.

a.a. 2000-2001 08UML.48

Associazioni n-arie

a.a. 2000-2001 08UML.49

Relazioni: Aggregation/ Composition

• Modella la relazione part- of

• e’ un tipo speciale di associazione e ne eredita le caratteristiche (nome, ruoli, cardinalita’, verso)

• puo’ essere

• debole (aggregation)

• forte (composition)

a.a. 2000-2001 08UML.50

Aggregazioni: UML

Aggregazionefortedebole

Ordinamento

Navigazione

a.a. 2000-2001 08UML.51

Aggregazione forte (composizione)

Ruolo

Molteplicità

Composizione

a.a. 2000-2001 08UML.52

Vincoli o proprieta’?

• UML prevede 4 proprieta' delle terminazioni delle associazioni da rendersi come vincoli:– ordered (gli elementi raggiunti sono ordinati)

– changeable

– addOnly

– frozen

a.a. 2000-2001 08UML.53

GeneralizzazioneSpecializzazione

• E’ una relazione tra due classi delle quali una rappresentala generalizzazione dell’altra.

• Due versi di percorrenza:– sottoclasse classe: GENERALIZZAZIONE– classe sottoclasse: SPECIALIZZAZIONE

• ISA. Se la classe B è una specializzazione di una classe Asi dice che B ISA A

• Tutte le istanze di B sono anche istanze di A• Di conseguenza gli oggetti di B ereditano attributi e

metodi della classe A

a.a. 2000-2001 08UML.54

Overlapping

• Una istanza della classe padre puo’ appartenere a piu’ di una sottoclasse

a.a. 2000-2001 08UML.55

Disjoint

• Una istanza della classe padre puo’ appartenere ad una sola sottoclasse

a.a. 2000-2001 08UML.56

Complete• Tutte le sottoclassi devono essere

specificate (anche se non sono visualizzate). Non si prevedono ulteriori sottoclassi

{complete}

a.a. 2000-2001 08UML.57

Incomplete

• Alcune sottoclassi sono state definite ma è noto che l’elenco e’ incompleto. Esisteranno sottoclassi addizionali che non sono ancora nel modello.

a.a. 2000-2001 08UML.58

Incomplete• Alcune sottoclassi sono state definite ma è noto che

l’elenco e’ incompleto. Esisteranno sottoclassi addizionali che non sono rappresentate nello schema.

a.a. 2000-2001 08UML.59

Ereditarietà: UML

a.a. 2000-2001 08UML.60

Realization

• Una via di mezzo tra generalizzazione e dipendenza. Indica una relazione tra due classificatori in cui uno specifica un impegno e l'altro lo realizza

Processo divalidazione

Validazioneutente

a.a. 2000-2001 08UML.61

Manca qualcosa? Stereotype• Permettono di creare nuovi oggetti

derivandoli da quelli esistenti. La sintassi e’: << nome stereotipo>>

<<x>>

a.a. 2000-2001 08UML.62

Manca qualche proprieta’? Tagged value

• Permettono di aggiungere nuove proprieta’ agli elementi presenti in UML (nonche’ agli stereotipi). La sintassi e’ del tipo

{nome_tag = valore}

• Aggiungono attributi alle metaclassi

a.a. 2000-2001 08UML.63

Object Diagrams