Politecnico di Milano © 2005 - CEFRIEL UML (Unified Modeling Language) un linguaggio di...

© 2005 - CEFRIEL

PolitecnicoPolitecnicodi Milanodi Milano

UML (Unified Modeling Language)

un linguaggio di modellazione orientato agli oggetti

Luigi LavazzaCEFRIEL

[email protected]

2 © 2005 - CEFRIELUnified Modeling Language

SommarioSommario

Introduzione ai linguaggi di modellazione Fondamenti del paradigma object-oriented UML: il linguaggio Esempi di modellazione con UML


I modelliI modelli

Ragionare sui sistemi complessi è difficile. Costruire sistemi complessi è difficile. Come fare a valutare aspetti notevoli dei sistemi, o

a valutare l’efficacia di soluzioni costruttive senza affrontare l’intera complessità di un sistema reale?

Usando dei modelli.


Modellare: un’idea nuova?Modellare: un’idea nuova?

Non proprio si pensi al modello di cupola del Brunelleschi


Caratteristiche del modelloCaratteristiche del modello

Astrazione Modularità Viste molteplici


AstrazioneAstrazione

Un sistema reale è caratterizzato da un numero impressionante di elementi.

Spesso, solo una minima parte di tale elementi risultano “interessanti”– NB: cosa sia interessante dipende dal contesto

Ne consegue che il modello può trascurare i dettagli irrilevanti.

Astrazione = descrizione di un sistema (o di parte di esso) che ne riporta solo le caratteristiche rilevanti.


Astrazione: esempioAstrazione: esempio

Caratteristiche di una persone:– Nome,– Indirizzo– Età– Numero di scarpe– Gruppo sanguigno– Codice fiscale– Fede calcistica– Reddito– …

La stragrande maggioranza dei contesti che possiamo immaginare richiedono la conoscenza di un sottoinsieme di queste caratteristiche


ModularitàModularità

Divide et impera Un sistema è modulare se è diviso in parti che

hanno una sostanziale autonomia individuale ed una ridotta interazione con le altre parti– i moduli sono scarsamente connessi e fortemente coesi


Cinque criteri di modularitàCinque criteri di modularità

Scomponibilità modulare– scomporre un problema in sottoproblemi di minori

dimensioni e quindi più facilmente affrontabili Componibilità modulare

– ri-aggregare moduli esistenti per risolvere problemi nuovi– riusabilità– ES: Lego

Comprensione modulare– capire un modulo osservando solo quello e i "confinanti“

Continuità modulare– un piccolo cambiamento nelle specifiche comporta

cambiamenti in un solo (o pochi) moduli– estendibilità

Protezione modulare– errori in un modulo influenzano solo il modulo stesso (o al

massimo si propagano ai confinanti)

10

© 2005 - CEFRIELUnified Modeling Language

Come ottenere la modularitàCome ottenere la modularità

Unità linguistiche modulari Poche interfacce

– ciascun modulo deve comunicare con il minor numero possibile di altri moduli

– in un sistema composto da n moduli il numero delle interfacce deve essere quanto più possibile vicino a (n-1) e lontano da n(n-1)/2

Interfacce piccole– ogni modulo deve scambiare il minor numero possibile di

informazioni con gli altri moduli Interfacce esplicite

– il fatto che due moduli A e B comunichino deve risultare evidente sia dal codice di A che dal codice di B

Information hiding– il modulo deve distinguere tra informazioni pubblicheinformazioni pubbliche ed

informazioni privateinformazioni private

11


Molteplici visteMolteplici viste

Un sistema complesso presenta molteplici “aspetti” che devono essere considerati ed adeguatamente descritti per rappresentare il sistema, ritraendone tutte le caratteristiche.

Risulta quindi difficile comprimere in un unico modello informazioni di natura anche molto diversa: si consideri ad esempio il fatto che una rappresentazione adeguata del sistema deve descrivere – la struttura statica – il comportamento dinamico– l’organizzazione logica– la distribuzione fisica– ecc.

Soluzione: non un modello, ma più modelli, ciscuno specializzato per fornire un certo tipo di informazioni

12


Molteplici visteMolteplici viste

Un’idea nuova? Non proprio …

13


Linguaggi di descrizioneLinguaggi di descrizione

Le “descrizioni” vengono prodotte in svariate fasi del processo:– Descrizione = insieme di affermazioni riguardo una qualche

realtà di interesse– Problem definition = fra l’altro, descrizione del problema da

risolvere– Program design = fra l’altro, descrizione del

comportamento del sistema da realizzare Linguaggi di descrizione = linguaggi adatti a

scrivere “descrizioni”

14


Caratteristiche dei linguaggi di Caratteristiche dei linguaggi di descrizionedescrizione

Completezza– Il linguaggio deve mettere a disposizione strumenti per

descrivere tutti gli aspetti di interesse. Accuratezza

– Deve essere possibile costruire una descrizione precisa. Consistenza

– Il linguaggio deve aiutare a non esprimere concetti contraddittori in diverse rappresentazione della stessa descrizione.

Comprensibilità– La descrizione deve essere facilmente comprensibile da parte di

chi la deve interpretare. Formalità

– Rigore con cui sono definite la sintassi e la semantica del linguaggio.

Stile– Quale aspetto del sistema è più facile descrivere utilizzando il

linguaggio (comportamento o proprietà)

15


Grado di formalitàGrado di formalità

Informale: tipicamente linguaggio corrente (italiano, inglese)– Spesso usato perché è usabile con poco sforzo– Può dar luogo ad ambiguità

Semi-formale (ha sintassi ma poca semantica)– Facilmente comprensibile, ma possibile fonte di ambiguità

Formale (ha sia sintassi sia semantica rigorosa)– Ha fondamenti logico-matematici: elimina ambiguità– Consente di ragionare su e verificare proprietà, anche con

strumenti (semi)automatici che supportano quel linguaggio– N.B. Non tutte le proprietà sono formalmente verificabili

16


StileStile

Stile descrittivo: definisce le proprietà desiderate– Es. La curva soddisfa l’equazione ax2 + by2 + c = 0.

Stile operazionale: definisce il comportamento desiderato (una “macchina”)– Es. La curva rappresenta il cammino di un punto che si

muove in modo che la somma delle sue distanze da due punti fissati P1 e P2 rimanga costante.

© 2005 - CEFRIEL


Il paradigma object-oriented

18


I concetti base del paradigmaI concetti base del paradigmaObject-OrientedObject-Oriented

Classi Oggetti Generalizzazione/specializzazione Polimorfismo Dynamic binding

19


ClasseClasse

Una classe definisce un insieme di possibili oggetti È la descrizione –astratta– di una tipologia di oggetti Automobile, felino, fenomeno atmosferico,

copricapo sono possibili classi.

NB: la classe è una descrizione– Gli oggetti che descrive sono elementi del mondo reale– La classe esiste su un piano diverso

20


Classe: dati e comportamentoClasse: dati e comportamento

La classe descrive sia le caratteristiche statiche degli oggetti che il loro comportamento (le operazioni in cui possono essere coinvolti)

Attributi: sono i “dati” che caratterizzano la classe Esempio:

– La classe conto corrente avrà gli attributi: numero, titolare, saldo, ecc.

Operazioni (o “metodi”): sono le operazioni che si può chiedere agli oggetti di eseguire

Esempio:– La classe conto corrente sarà dotata delle operazioni di

versamento, prelevamento, bonifico, ecc.

21


Classi: proprietà pubbliche e Classi: proprietà pubbliche e privateprivate

Contenuti privati– attributi e metodi accessibili solo dall’interno della classe

Contenuti pubblici– attributi e metodi accessibili dall’esterno (cioè da altre classi)

Servono a realizzare l’information hiding È desiderabile che tutti gli attributi siano privati.

– Questo rende la classe accessibile solo attraverso le operazioni pubbliche.

– Conseguenza: la altre classi sanno cosa possono fare con una classe, ma non sanno come la classe funziona internamente

– Modularità!– Concetto nuovo? Non proprio: noi conosciamo solo

l’interfaccia pubblica della banca, del videoregistratore, dell’automobile, …

22


OggettoOggetto

Definizione– Istanza di una classe– Esemplare corrispondente alla descrizione fornita dalla classe

Ogni oggetto ha associate le proprietà descritte nella classe di cui è istanza– Tutte le istanze della stessa classe si comportano nello

stesso modo– Ma oggetti diversi che sono istanze della stessa classe

avranno valori degli attributi diversi Esempio:

– La classe Persona prevede l’attributo età– Rossi e Bianchi sono istanze di persona– Sia Rossi che Bianchi hanno dunque un’età– I valori delle età di Rossi e Bianchi possono chiaramente

essere diversi

23


OggettoOggetto

Un oggetto incapsula:– stato = valore di attributi– comportamento = metodi

Il comportamento dipende spesso dallo stato Esempi

– La classe Persona comprende lo stato civile: l’operazione “matrimonio” è disponibile solo se l’oggetto è nello stato “celibe”

– La classe Motore comprende l’operazione di accensione, che è disponibile solo se gli attributi del motore indicano che non è guasto ed il carburante è presente.

24


La metafora di interazioneLa metafora di interazione

Un metodo si invoca mandando un messaggio all'oggetto

In altre parole: per stimolare un certo comportamento da parte di un oggetto, gli mandiamo un messaggio contenente l’invocazione del metodo dell’oggetto corrispondente al comportamento che desideriamo ottenere.

Chi manda i messaggi? Un altro oggetto. Nel modello object-oriented qualunque cosa è un oggetto.

Persona Conto corrente

Prelievo

25


Classi: attenzione Classi: attenzione all’astrazioneall’astrazione

Lo scopo semantico della classe e l’astrattezza della descrizione possono portare a situazioni apparentemente bizzare, ma perfettamente logiche.

Esempio:– Scopo semantico = bene materiale, caratterizzato dalla sua

descrizione e valore– Classe Bene– La mia auto e il mio box sono istanze della stessa classe– Il cavallo e la stalla del Sig. Rossi sono istanze della stessa

classe Esempio:

– Scopo semantico = gli insegnanti– Classe Insegnante– Il sig. Mauro Rossi e il suo fratello genello sono istanze di

classi diverse (uno è insegnante, l’altro no).

26


Classi come insiemiClassi come insiemi

Una classe può essere vista come un insieme Le istanze della classe appartengono all’insieme

associato alla classe Esempio

– Classe Libro– Le istanze “Pinocchio”, “Tom Sawyer”, “Il nome della rosa”

appartengono all’insieme dei libri, così come tutte le altre istanza di Libro.

28


Identità degli oggettiIdentità degli oggetti

Un oggetto esiste indipendentemente dal suo valore.

Esistono due relazioni di equivalenza sugli oggetti:– identità (due oggetti sono in realtà il medesimo oggetto)– uguaglianza (due oggetti hanno lo stesso valore)

Se l'oggetto é complesso l'uguaglianza può essere "deep" o "shallow".

29


Identità degli oggetti - Identità degli oggetti - condivisionecondivisione

Esempio: una persona ha un nome, un età e un insieme di figli.

Carlo e Maria hanno entrambi un figlio di 15 anni di nome Luca. Sono possibili due situazioni:– Luca é il figlio di Carlo e Maria– Ci sono due persone di nome Luca di 15 anni, uno figlio di

Carlo e uno di Maria Un sistema basato sull'identità rappresenta in modo

naturale entrambe le situazioni:

Carlo Maria Carlo Maria

LucaLucaLuca

31


GeneralizzazioneGeneralizzazione

È una relazione tra classi (cioè tra descrizioni) Rappresenta il ben noto concetto di generalizzazione (o

specializzazione se visto nel senso inverso) Una classe A è una generalizzazione di una sottoclasse

B se la tipologia rapprersentata da A comprende come caso particolare (specializzazione) la tipologia B.

Esempi– La classe Studente è una specializzazione della classe Persona– La classe Primate è una specializzazione della classe

Mammifero, che a sua volta è una specializzazione della classe Animale

La relazione di generalizzazione non è limitata alle classi, ma può essere usata anche tra altri tipi di descrizioni

32



Generalizzazione = relazione "is-a“ (“è un/una”)– Ogni istanza di una classe è anche istanza di tutte le superclassi– Fuffy è un felino. Dunque è anche un mammifero e un animale.

La generalizzazione forma una gerarchia– Non è possibile (neanche indirettamente) che A sia una

specializzazione di B e B una specializzazione di A

Felino Primate

Animale

MammiferoRettile Uccello

33



Perché usiamo la generalizzazione nei modelli?– Condivisione di proprietà

• Le sottoclassi hanno tutte le proprietà delle super-classi• Possono essere descritte incrementalmente

– Compatibilità• Le sottoclassi sono compatibili con le superclassi• Ad es. se la maestra chiede di disegnare un animale, va

bene sia il disegno di un felino che di un rettile

34


Condivisione di proprietàCondivisione di proprietà

Poligono Ellisse

Figura

FiguraChiusa FiguraAperta

Rettangolo

Attributi: ColoreOperazioni: Rotazione Disegno

Eredita le proprietà di FiguraAggiunge le Operazioni: Perimetro Area

Eredita le proprietà di FiguraChiusa (e quindi anche di Figura)Aggiunge l’attributo: NumeroLati

Eredita le proprietà di FiguraChiusaAggiunge gli attributi: Fuoco1 e Fuoco2

35


Quando usare la Quando usare la generalizzazione?generalizzazione?

Quando esistono classi “simili” (cioè che condividono un insieme di proprietà) che –rispetto agli scopi del modello– presentano differenze rilevanti.

NB: possono esistere tipologie di modelli molto diverse nel mondo reale, ma che rispetto allo scopo semantico richiesto dal modello possono essere rappresentate mediante un’unica classe (cioè mediante un’unica astrazione).

Regola: non creare una specializzazione se non ce n’è bisogno.

36


PolimorfismoPolimorfismo

Conseguenza dell’esistenza di generalizzazione e della compatibilità delle sottoclassi rispetto alle superclassi

Poligono Ellisse

Figura


Rettangolo

Disegno

Attributi: ColoreOperazioni: Rotazione Disegno

Composto_da

Il disegno “sa” di essere composto da figure, cui può chiedere di ruotare o disegnarsi.Non sa nulla delle possibili specializzazioni, salvo che saranno compatibili

37


PolimorfismoPolimorfismo

Un riferimento polimorfico:– ha un tipo statico

• Nell’esempio precedente, il disegno è composto di oggetti di tipo Figura

– ha un tipo dinamico: può riferirsi, nel corso dell'esecuzione del programma, a istanze di più di una classe;

• Nell’esempio precedente, il disegno a un certo punto potrebbe comprendere solo un ellisse, più tardi solo due rettangoli

38


Dynamic bindingDynamic binding

Binding:– Il collegamento tra il nome di una operazione e la sua

implementazione Dynamic binding:

– Un oggetto invia un messaggio a un altro oggetto, di cui ignora il tipo dinamico

– L’operazione eseguita dipende dal tipo effettivo dell’oggetto ricevente

39


Dynamic binding: esempioDynamic binding: esempio

Poligono Ellisse

Figura


Rettangolo

DisegnoComposto_da

Rotazione

Tipo statico

Se il disegno è composto di ellissi la rotazione eseguita è quella delle ellissi, se il disegno contiene rettangoli la rotazione eseguita è quella definita nella classe Rettangolo, ecc.

© 2005 - CEFRIEL


Unified Modeling Language

41


Unified Modeling LanguageUnified Modeling Language

È un insieme di linguaggi che, utilizzati congiuntamente, consentono di descrivere/modellare tutti (o quasi) gli aspetti rilevanti di un sistema, secondo con un approccio object-oriented

Notazione grafica Linguaggio semi-formale Stile misto

– parzialmente dichiarativo, parzialmente operazionale Standard OMG per la modellizzazione di sistemi

Object-Oriented sin dal 1997

42


SituazioneSituazione

Dove trovare informazioni costantemente aggiornate:– http://www.rational.com– http://www.omg.org– internet newsgroup comp.object

2004

43


IndiceIndice

Diagrammi UML– Class e Object Diagram– Use Case Diagram– Interaction Diagram

• Sequence Diagram• Collaboration Diagram

– Composite structure Diagram– Statechart Diagram– Activity Diagram– Component Diagram– Deployment Diagram

44


I class diagramI class diagram

Forniscono una vista strutturale (statica) del sistema in termini di– classi

• attributi• operazioni

– relazioni tra classi (associazioni, generalizzazioni, ...) Un class diagram rappresenta uno schema

concettuale– se una classe A è in relazione con una classe B, allora

ogni istanza di A sarà in relazione con un’istanza di B

45


ClassiClassi

Una classe descrive un gruppo di oggetti con caratteristiche comuni– attributi– comportamento

Gli oggetti (istanze) di una stessa classe differiscono tra loro per i valori degli attributi e per le relazioni che li legano ad altri oggetti.

46


NomeClasse

nome-attributo-1: tipo-dato-1 = valore-di-default-1nome-attributo-2: tipo-dato-2 = valore-di-default-2....

nome-operazione-1 (lista-argomenti-1): tipo-reso-1nome-operazione-2 (lista-argomenti-2): tipo-reso-2....

Notazione generale per le Notazione generale per le classiclassi

Nel caso più generale la notazione è la seguente.

Esempi FilePersona

Nome: stringEtà: int

CambiaLavoroCambiaIndirizzo

Nome: stringDimensione: intCreazione: data

Stampa

Disegno

Titolo: stringAltezza: intLarghezza: int

StampaRuota(gradi: int)

47


OperazioniOperazioni

Un operazione è una funzione o una trasformazione applicabile ad un’istanza di una classe (ogni operazione ha come argomento implicito un oggetto obiettivo)– La stessa operazione può essere definita in classi

diverse– Il comportamento dipende dalla classe a cui appartiene

l'oggetto obiettivo

PersonaClassi con attributi e operazioni

Nome: stringEtà: int

CambiaLavoroCambiaIndirizzo

File

Nome: stringDimensione: intCreazione: data

Stampa

Disegno

Titolo: stringAltezza: intLarghezza: int

StampaRuota(gradi: int)

48


Relazioni in UMLRelazioni in UML

In un Class Diagram vengono rappresentate relazioni oltre alle classi:– Associazioni (semplici, aggregazioni, composizioni)– Relazioni di generalizzazione– Relazioni di dipendenza – Relazioni di raffinamento

49


Città

Nome: stringCapoluogoDi

Nota: una associazione è naturalmente bidirezionale.

Nome (opzionale) dell'associazione

Regione

Nome: string

AssociazioniAssociazioni

Una Associazione individua una “connessione” logica tra classi– Il significato della relazione è specificato solo attraverso

l’etichetta dell’associazione– si traduce in una connessione fra oggetti istanze delle

classi coinvolte nell’associazione

50


Cardinalità nelle associazioniCardinalità nelle associazioni

Indica il numero di istanze di una classe che possono essere associate ad una singola istanza dell’altra classe

Può non essere specificata ad uno degli estremi (“association-end”) o a entrambi– E in questo caso non significa cardinalità pari a 1!

51


Cardinalità delle associazioniCardinalità delle associazioni

P2P1

Mondo reale

Indicazione (opzionale) di molteplicità

0..*Poligono Punto

Derfinito_da 3..*

P4P5

P3P6

Px

52


Notazione per la cardinalitàNotazione per la cardinalità

Nota: Il class diagram indica che una persona può possedere un numero qualsiasi di auto

Quanti sono i proprietari di una singola auto?– Il diagramma non fornisce questa informazione, dato che la

cardinalità della partecipazione di Persona all’associazione risulta non specificata!

– Inoltre, dato che l’associazione è navigabile in una sola direzione, data un’auto non è mai possibile risalire ai suoi (o al suo) proprietario

Possiede

0..*

Auto

Modello: string

Persona

Nome: string

53


Persona AziendaLavora per

Impiegato DatoreDiLavoro

Il ruolo (opzionale)

1..* 0..1

Ruoli nelle associazioniRuoli nelle associazioni

Una classe può partecipare ad un’associazione con un ruolo specifico, che può essere indicato

54


Studente Corso

Frequenza

anno_accademicoprofitto

Questa è la notazione per indicare che una associazione possiede alcuni attributi

Non si tratta di attributi dello studente perché cambiano da corso a corso.Nè sono attributi del corso (ad es. ogni corso è frequentato da studenti diversi in anni diversi)

1..* 1..*

Attributi delle associazioni Attributi delle associazioni (Association Class)(Association Class)

In molti casi alcune proprietà sono proprie dell'associazione piuttosto che delle classi coinvolte.

55


Associazioni esclusiveAssociazioni esclusive

Talvolta un’associazione può esistere verso una classe o verso un’altra (non verso entrambe)

Partita IVA

Persona

{xor}

Azienda

56


Diagrammi delle Istanze Diagrammi delle Istanze (Object Diagram)(Object Diagram)

Descrivono singole istanze di classi (oggetti) e associazioni (links) rappresentate in un particolare class diagram

Adatti a descrivere esempi o situazioni specifiche (punti di vista o “fotografie” delle istanze esistenti in un certo istante di tempo)

57


Order

Classe Istanze

MyOrder: Order

: Order

Oggetti: Notazione graficaOggetti: Notazione grafica

Scopo delle istanze è solitamente di fornire degli esempi di oggetti, oppure evidenziare oggetti di particolare rilevanza.

MyOrder: Order

number=0amount=10000

58


presidente

cittadinoItalia: Repubblica

C.A.Ciampi: Persona

Dario Fo: Persona

cittadino

Link e Object DiagramLink e Object Diagram

Un legame (link) è una connessione fisica o concettuale fra due istanze.

Mentre un'associazione connette due classi, un link connette due oggetti.

I link sono istanze delle associazioni.

59


Object diagram: EsempioObject diagram: Esempio

Diagramma degli oggetti

Pol: PoligonoP3: Punto

P1: Punto

P2: Punto

P4: Punto

P2P1

Mondo reale

P4P5

P3P6

P5: Punto

P6: Punto

60


Poligono PuntoInsiemeDi

Modello equivalente che usa una associazione convenzionale:

Poligono Punto

Il rombo “vuoto” si legge "è un insieme di"

3..*

3..*

AggregazioneAggregazione

È un caso particolare di associazione molto comune che significa: “è un insieme di".

Essendo un tipo particolare di associazione è sempre possibile specificare la cardinalità

61


ComposizioneComposizione

È un caso particolare di aggregazione che significa: “è composto da".– i componenti non possono esistere senza il contenitore– la proprietà da parte del contenente è esclusiva

• Quindi la molteplicità dal lato dell’aggregato non può essere >1

• Può essere qualsiasi per gli elementi componentiPC

Monitor UnitàBase Mouse Tastiera

HardDisk CD ModuloRAM CPU Coprocessore

1..4 1..2

1..* 0..1

1..21..3 0..1

62


Relazioni di aggregazione: Relazioni di aggregazione: SemanticaSemantica

Varianti

esclusiva, dipendente, ma assenza di propagazione delle operazioni

dipendente indipendente

esclusiva

condivisa

?

1 0..1

*

Dipendenza delle parti dall’oggetto composito

Proprietà

? 1..* + semantica di propagazione delle operazioni definita dall’utente (necessaria)

1

Avanzato

63


Associazioni riflessiveAssociazioni riflessive

Una associazione o aggregazione si dice riflessiva ( o ricorsiva) se coinvolge oggetti della stessa classe– una associazione ricorsiva indica che più oggetti della

stessa classe interagiscono e collaborano in qualche modo

Corso

0..*

0..*

0..*

precedenza

0..*

64


generalizzazione

Documento è una generalizzazionedi Libro e di File

File e libro sono sottoclassidi documento

Attributi, operazioni e associazionivengono ereditati dalle sottoclassi

File Libro

Numero_pagine

Documento

Titolo0..*

0..*

StessoAutore

0..*

{simmetrica}

HuckleberryFinn: LibroTomSawyer : LibroStessoAutore

HF.doc: FileStampa_di


Esempio di Object Diagram

Dimensione_in_KB

Copia()

Stampa_di

StessoAutore

65


Generalizzazione ed Generalizzazione ed ereditarietà: Esempi (2)ereditarietà: Esempi (2)

La classe Studente eredita dal padre:– attributi– metodi

Un oggetto Studente può essere trattato esattamente come un oggetto Persona

In cosa solitamente può differenziarsi la classe erede– aggiunta di attributi e

metodi– i metodi possono essere

ridefiniti

Studente

- int matricola- String esami[ ]- int voti[ ]

+ Studente(String nome, String ind, int mat)+ aggiungiEsame(String nome, int voto)+ int mediaVoti()

Persona

- String nome- String indirizzo

+ Persona(String nome, String ind) + stampa()+ String nome()+ String indirizzo()

66


Generalizzazione: Esempi (3)Generalizzazione: Esempi (3)

TriangoloRettangolo

+ float diagonale()

Poligono

+ Colore colore

+ sposta(float dx, float dy)+ ruota(Punto centro, float angolo)+ disegna(Schermo s)

Autoveicolo

+ String targa+ String modello

+ stampaLibretto()

VeicoloCommerciale

+ int pesoCarico+ int pesoVuoto+ boolean articolato

VeicoloPrivato

+ int numeroPorte+ int numeroPosti

67


Significati della Significati della generalizzazionegeneralizzazione

Una sottoclasse può ridefinire alcune proprietà della superclasse

Una sottoclasse può anche ridefinire il protocollo delle operazioni– Cioè in una sottoclasse si può ridefinire un’operazione

ereditata dalla superclasse, cambiandone anche parametri e tipo restituito

68


Uso della delega (delegation)Uso della delega (delegation)

Devo definire la classe pila (col solito significato) Dispongo di una classe Sequenza, che vorrei riutilizzare

Sequenza

insert(pos:int, x:item)delete(pos:int)

Pila

push(x:item)pop(): item

Pila

push(x:item)pop(): item Sequenza

insert(pos:int, x:item)delete(pos:int)così la pila erediterebbe

la possibilità di inserire e togliere elementi da qualunque posizione

così la pila contiene (tipicamente nella parte privata) una sequenza di elementi

- content

69


Classi concrete

Classi astratte

Poligono{abstract}

Cerchio

Figura{abstract}

Triangolo Quadrato

Classi astratteClassi astratte

Una classe astratta è una classe che non può essere direttamente istanziata

Può (anzi deve) avere delle sottoclassi concrete– e queste possono essere istanziate (se non sono

astratte a loro volta)Notazione alternativa: nome della classe in corsivo

70


Classi astratte (2)Classi astratte (2)

Il termine “astratto” viene anche utilizzato per per descrivere una operazione per la quale non è stata definita una implementazione– Le operazioni astratte di una classe si rappresentano

scrivendo il nome in corsivo Una classe astratta può avere operazioni

concrete– Almeno una operazione deve essere astratta

Tipicamente vengono usate – per mettere a fattor comune un'astrazione di un certo

tipo – per favorire il riuso

71


Classi astratte: EsempioClassi astratte: Esempio

Il disegno è composto di figure. Non importa come sono fatte. Il disegno sa solo che per disegnare (draw) se stesso può chiamare il metodo draw delle figure.– Aggiungendo una sottoclasse a figura il codice di gestione dei

disegni non cambia!

Figura

Gruppo_Figure Poligono Linea

+figuraPart

1

1..* +draw()#Position : Pos

+lineaPart13..*

1..* Disegno

+draw()

72


Eredità multiplaEredità multipla

VeicoloTerrestre e VeicoloaSpintaUmanasono sottoclassi non disgiunte di Veicolo

Bicicletta eredita sia da VeicoloTerrestre, sia da VeicoloaSpintaUmana

VeicoloTerrestre

Veicolo

VeicoloaSpintaUmana

Auto Bicicletta BarcaaRemi

{propulsione}{superficie}

73


La delegaLa delega

La delega consiste nel "delegare" una entità apposita (es. RapportoDiLavoro) a svolgere particolari operazioni.

Persona Persona

RapportoDiLavoro

Senza delega (eredità multipla) Con delega (eredità semplice)

LavoratoreAutonomo

LavoratoreDipendete

DipendeteConPartitaIva

LavoroAutonomo

LavoroDipendete

74


Persona Aziendaimpiegato

0..1

dipendente 0..1

1..*

datore di lavoro

0..10..*

capo

Vincoli relativi sulle Vincoli relativi sulle associazioniassociazioni

Persona.datore_di_lavoro = Persona.capo.datore_di_lavoro

Nota: in generale, i diagrammi consentono più gradi di libertà di quanti se ne vogliano effettivamente lasciare.Per introdurre vincoli e restrizioni bisogna ricorrere a una notazione testuale.OCL (Object constraint Language) fa questo in modo formale (è un linguaggio logico).

75


DipendenzaDipendenza

Relazione che indica una dipendenza di varia natura tra elementi di un modello UML– Si può avere dipendenza tra classi, packages, use cases,

etc. Individua una connessione “semantica” tra due

elementi, uno dei quali è dipendente dall’altro– Una modifica nell’elemento indipendente ha effetti su

quello dipendente

76


Classe A Classe B

Classe C

Classe D

operationZ()

<<calls>>

<<instantiates>>

Dipendenza: EsempioDipendenza: Esempio

77


Costrutti di raggruppamentoCostrutti di raggruppamento

Modulo: raggruppa classi, associazioni e generalizzazioni– fornisce una vista del problema– diminuisce la complessità del problema

La suddivisione in moduli può essere fatta in diversi modi.– Criterio: forte coesione, scarse connessioni

78


Forniscono un costrutto di raggruppamento per gli elementi definiti in un modello UML

A volte si utilizza il termine subsystem per indicare un package

È possibile definire delle relazioni (tipicamente di dipendenza, raffinamento, generalizzazione) tra packages diversi

A

B

B1

AB

A1 A2

PackagesPackages

83


Use Case DiagramUse Case Diagram

È una tipica interazione tra l’utente e il sistema informatico.– Esempi per un word processor:

• sottolinea una parte di testo• crea un indice

Quindi, uno use case– rappresenta una funzione visibile dall’utente– rappresenta un obiettivo specifico (atomico) per l’utente– può essere di “dimensioni” diverse– Descrive

• Il sistema• L’ambiente • Le relazioni fra sistema e ambiente

Ogni caso di utilizzo identificato– È etichettato con un nome– Viene descritto graficamente– Viene descritto con del testo (la notazione grafica non basta)

84


Use Case: Use Case: Elementi caratteristiciElementi caratteristici

Uno Use case consente di individuare il comportamento (in termini di funzionalità offerte) di un sistema o di una qualsiasi altra entità definita nel sistema senza entrare nel dettaglio della struttura interna dell’entità

Uno Use Case individua una tipologia di possibili utilizzi del sistema (descritti testualmente)

85


Use case diagramUse case diagram

Actor

Use case<<include>>

86


Use case diagramUse case diagram

Esempio: Sistema per la gestione delle vendite dei prodotti di una azienda– Si vuole descrivere la possibilità da parte del venditore

di effettuare l’evasione di un ordine

Acquisizione Ordine

Venditore

Attore

Use-Case

Confine del sistema(non sempre indicato esplicitamente)

87


Actor (attori)Actor (attori)

Attore = Entità esterna al sistema che interagisce con il sistema assumendo un particolare ruolo– non c’è necessariamente corrispondenza tra attori e

individui precisi– possono esserci diversi utenti con lo stesso ruolo, e diversi

ruoli possono essere ricoperti dallo stesso utente– possono esserci diversi attori che esercitano lo stesso use

case, e diversi use case possono essere esercitati dallo stesso attore

– non è detto che un attore corrisponda a uno o più persone: può essere un sistema esterno

• nonostante l’icona standard utilizzata per la rappresentazione

88


Relazioni tra attori e use caseRelazioni tra attori e use case

Venditore

Supervisore

Immissione Ordine

Attribuzione credito

Associazione: Identifica la partecipazione di un attore ad uno Use Case

Generalizzazione: Il supervisore può partecipare a tutti gli use case cui partecipa il Venditore (compatibilità!)

89


Use case diagram: esempioUse case diagram: esempio

VenditoreVerifica stato ordine

Acquisizione Ordine

Addetto al magazzinoEvasione ordine

Cliente

SupervisoreAttribuzione credito

90


Use Case, Use Case Instances Use Case, Use Case Instances e Scenarie Scenari

Uno Use Case individua una tipologia di “storie” d’uso del sistema

Una istanza dello Use Case individua una specifica storia d’uso– Specifica una delle possibili sequenze di azioni che possono

avvenire durante lo svolgimento dello use case Scenario: È una istanza di use case corredata da

una descrizione esplicita – Il termine “scenario” non è usato in modo sempre

consistente.

91


ScenariScenari

Uno “scenario” individua e descrive esplicitamente una particolare istanza di uno use case, ovvero una delle possibili varianti– Ad es. un ordine può essere elaborato regolarmente, o

può mancare la merce ordinata o può mancare il credito nei confronti dell’ordinante, … Ciascuno di questi casi è uno scenario specifico dello use case “gestione ordini”.

Ogni Use Case è caratterizzato da uno scenario base (sequenza tipica di eventi) e da un numero, imprecisato a priori, di varianti

Le varianti possono essere aggiunte nei successivi raffinamenti dello use case

92


Relazioni tra Use CasesRelazioni tra Use Cases

Esistono tre tipi di relazioni possibili tra use cases:– Generalizzazione

• Simile alla generalizzazione tra classi

– Inclusione• Il comportamento individuato dallo use case target viene

incluso nella sequenza di azioni svolta dalle istanze dello use case base

– Estensione• Le funzionalità individuate da uno use case base vengono

estese, al verificarsi di opportune condizioni, con funzionalità definite in un altro use case

<<include>>

<<extend>>

93


EsempioEsempio

SupplyCustomer

Data

OrderProduct

ArrangePayment

Pay by Money Transfer

<<include>><<include>>

<<include>>

RequestCatalog

with Order

<<extend>>[Order created, P1 ]

Place Order

Extension Points:P1: After ordercreation

Customer

SalesPerson

base use case

extension use case

PayCash

94


I requisiti non funzionaliI requisiti non funzionali

Gli use case non sono adatti a specificare i requisiti non funzionali.

Poiché tali requisiti sono di importanza fondamentale occorre inventarsi un modo per descriverli comunque.

UML non fornisce alcuna soluzione. Quindi solitamente si ricorre ad una specifica testuale che viene allegata agli use case diagrams.

95


Interaction diagram e Interaction diagram e comportamento dinamico del comportamento dinamico del

sistemasistema Sono diagrammi che descrivono come gruppi di oggetti collaborano nel mostrare un certo comportamento.

Tipicamente rappresentano il comportamento di uno specifico use case– in termini di specifici oggetti e messaggi scambiati

Ci sono due tipi di interaction diagram:– Sequence diagram– Collaboration diagram

96


Sequence diagramSequence diagram

Mostra una interazione tra oggetti come sequenza temporale di azioni.– oggetti partecipanti– sequenze (temporali) di messaggi scambiati– non si vedono le associazioni tra oggetti

97


Oggetti

Obj1 Obj2 Obj3

a:do_this()

b:do_that()

c

{b-a < 1 sec.}

This call is routed through the network

Tempo

Messaggi

Istanti di tempo

c’

Vincolo temporale

Commento

Messaggio che impiega un certo tempo per essere ricevuto

Sequence diagram: notazioneSequence diagram: notazione

98


physicianwaveformcontroller heart rate

parameteralarm manager

alarm display

patient

physician sets up for patient monitoring

use 4 waveforms Rate=50

Rate=47setsweepspeed(25)

Rate=0

set bradycardiaalarm

set tachycardiaalarm

asystole eventraisebradycardia alarm

alarm textRate=45

physician’s intervention

lowerbradycardia alarm

clear alarm

Esempio: sequence diagramEsempio: sequence diagram

99


Obj1:C1op()

Obj3:C3

Obj2:C2[x>=0] foo(x)

[x<0] bar(x)

doit(w)

AgenteOggettocreato da op()

Oggettocreato da foo(x)

Oggettopreesistente

condizione,equivale aif (x>=0) { Obj2=new(C2); Obj2.foo(x);}else Obj3.bar(x);

“lifeline” dell’oggetto

Notazione estesa: Notazione estesa: terminologiaterminologia

101


doit(z)

more()

Obj2:C2

Obj4:C4

doit(w)

Distruzionedell’oggetto

Oggetto che prosegue la sua esistenza dopo queste interazioni

Messaggi“return”

Confluenza delle due possibili evoluzioni

Attivazioni

Attivazionericorsiva

Notazione estesa: Notazione estesa: terminologiaterminologia

102


Collaboration diagramCollaboration diagram

Collaboration: interazione tra parti di un sistema per un certo scopo– si isolano parti di sistema e si trascurano le interazioni non

essenziali allo scopo L’interazione è descritta in rapporto agli oggetti e

alle relazioni che li legano. Non c’è una dimensione precisa per il tempo

– le sequenze temporali sono descrivibili numerando i messaggi in modo progressivo

103


: OrderEntryWindow

: Order

LineaTrenini : OrderLine MagazzinoTrenini : Stock

: DeliveryItem : ReorderItem

5: NeedToReorder()

1: prepare()

2*: prepare()

7: [check() == true] new

3: check()

4: [check() == true] remove()

6: new

oggetto messaggio

ordine nella sequenza di messaggi

auto-delega

Esempio di interazioneEsempio di interazione

104


State diagramState diagram

Rappresentano il comportamento di una classe di oggetti, descrivendone i possibili stati e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni svolte.

I diagrammi di stato danno un'astrazione di stati, eventi e transizioni

Gli stati dei diversi oggetti evolvono concettualmente in parallelo (sincronizzati dagli eventi comuni).

105


Concetti fondamentali: statiConcetti fondamentali: stati

È l'insieme dei valori degli attributi e dei link posseduti da un oggetto in un certo istante

Ci interessa lo stato astratto– esempio: motore acceso/spento (non ci interessa il numero

di giri/min.)– può corrispondere a diverse - anche infinite - combinazioni

di valori degli attributi Lo stato influenza il comportamento

– L'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in cui si trova.

– Esempio: prelievo da un conto corrente con saldo negativo

106


Concetti fondamentali: statiConcetti fondamentali: stati

Il comportamento quantitativo è influenzato dal valore degli attributi, dei link e dei parametri delle operazioni

Uno stato perdura nel tempo– finché un evento non fa cambiare stato all’oggetto (es. un

versamento fa passare un conto corrente da saldo negativo a saldo positivo)

107


Concetti fondamentali: eventiConcetti fondamentali: eventi

Evento = stimolo esterno– E' istantaneo

• il tempo è un attributo implicito– Se due eventi sono legati da relazione causa/effetto sono

ordinati nel tempo.– Può causare nell'oggetto destinatario un cambio di valore,

di stato o la produzione di ulteriori eventi.– Si intende che un evento ha una individualità ben definita

• raggruppabili in classi di eventi (con attributi caratterizzanti)– La risposta ad uno stimolo dipende dallo stato, e può

implicare una transizione di stato• esempio del versamento su CC

108


MessaggioVocale

Inattivo

TonoPronto

Compos.Numero

ProntoAConnettere

TonoLibero

Connesso

TonoOccupato

TonoTimeOut

Chiamante.Aggancia

T

TCompone(n)

NumValido

NumNonValido

Occupato

Chiamante.Aggancia

Chiamante.Sgancia

Ricevente.Sgancia

Instradato

Compone(n)

Diagramma degli stati: Diagramma degli stati: EsempioEsempio

109


InizioAlBiancoMuovere

AlNeroMuovere

Matto or Abbandono

Stallo or Accordo

MossaBianca

MossaNera

VinceIlNero

VinceIlBianco

Patta

Matto or Abbandono

Stallo or Accordo

Stati iniziali e finaliStati iniziali e finali

Alcuni oggetti hanno diagrammi degli stati ciclici, altri possono avere stati iniziali e/o finali.

110


ProntoVerde [incrocio.stato=libero]

InCorsa

CondizioneEvento

CondizioniCondizioni

Sono funzioni booleane sui valori degli oggetti. Sono valide in un intervallo di tempo Sono utili come guardie delle transizioni di stato (non basta

l'evento, deve essere verificata la condizione).

111



Durante la loro vita gli oggetti eseguono operazioni.– associate allo stato (attività) – associate alle alle transizioni (azioni)

Le attività hanno una durata– continue– sequenziali

Le azioni sono istantanee

112



Azioni– Sono operazioni che hanno durata istantanea (rispetto alla

granularità del tempo). Tipicamente produzione di eventi.– Sono associate alle transizioni di stato oppure all'ingresso o

all'uscita da uno stato. Attività

– Sono operazioni con durata significativa.– Sono associate ad uno stato

• Continue o sequenziali

Transizioni automatiche– Se uno stato ha una attività associata e una freccia senza eventi

esce da questo, la freccia indica la transizione svolta automaticamente al completamento della attività.

113


event3 [condizione1] / azione5

Transizione automatica (evento scatenante fine della attività1)

event4 [condizione2] / azione6

Transizione causata dall'evento evento3 sotto condizione condizione1. Vengono eseguite azione2 e azione5

Pseudo transizione causata dall'evento evento4nell'ordine vengono eseguiti: azione2, azione6, azione1

In caso di ricezione dell'evento1 nello stato A viene eseguito azione3 senza cambio distato (e quindi senza azioni di entry ed exit)

do: attività1entry / azione1exit / azione2event1 / azione3event2 / azione4

StatoA

Notazione generaleNotazione generale

114


right-mouse-down(location) [location in window] /object:=pick-object(location); object.highlight()

No object selected

One object selected

invio di messaggio a object

Azioni consistenti nell'invio di Azioni consistenti nell'invio di eventieventi

Molto spesso le azioni consistono nell'inviare un evento ad un altro oggetto.– esempio: transazione tra stati di un oggetto Window

115


Invio di eventiInvio di eventi

Gli eventi possono avere attributi Il destinatario può essere unico o un intero set di

oggetti. Tutti gli oggetti riceventi che riconoscono l'evento

possono accettarlo e reagire in parallelo. Attenzione alle corse critiche

116


Invio di eventi: notazione Invio di eventi: notazione graficagrafica

Il segnale accende o spegneIl VCR a seconda dello statocorrente

“power” button/VCR.togglePower

“power” button/television.togglePower

117


Problemi dei diagrammi a stati Problemi dei diagrammi a stati piattipiatti

Diventano poco espressivi e troppo ingarbugliati al crescere delle dimensioni del problema.– Ad esempio, il numero di collegamenti possibili tra stati è

quadratico nel numero di stati. Soluzione: diagrammi strutturati

– la strutturazione favorisce la descrizione sintetica di sistemi complessi

• L'attività corrispondente ad uno stato può essere espansa in un diagramma a stati di più basso livello, dove ogni stato rappresenta una fase dell'attività.

• Generalizzazione (specializzazione delle attività, gerarchie di ereditarietà, ...)

– Aggregazione (stati concorrenti)

118


Folle RetroMarcia

MarciaAvanti

Prima Seconda Terza

levaR

levaN

levaF levaN

accelera accelera

deceleradecelera

ferma

Cambio AutomaticoQuesta transizione, risposta all'evento ferma, viene ereditata da tutti i sotto-stati di MarciaAvanti

Diagrammi a stati strutturatiDiagrammi a stati strutturati

Uno stato strutturato equivale ad una scomposizione OR degli stati: l'oggetto si trova, all'interno di uno stato più generale, in un qualunque sotto-stato.

I sottostati ereditano le transizioni dei loro superstati (a meno di overriding)

119


Diagramma di stato: esempio Diagramma di stato: esempio (1)(1)

120


Sottostati concorrentiSottostati concorrenti

121


NaturalmenteAttento

do: appunti

do: sbadiglia

do: gratta

Distratto

noiarichiamo

ForzatamenteAttento

do: ghirigori

Transazione complessa Sincronizzazione

richiamo

Concorrenza di due attivitàConcorrenza di due attività

122


Activity Graph e Activity Activity Graph e Activity DiagramDiagram

Sono dei casi speciali di macchine a stati, in cui– tutti gli stati (o quasi) contengono un’azione o una attività– tutte le transizioni (o quasi) sono causate dal

completamento delle azioni/attività negli stati Un activity graph è associato ad una classe, o

all'implementazione di un’operazione, o ad uno use case.

Un Activity Diagram è un diagramma contenente un activity graph

Lo scopo deglio activity graph è di evidenziare l’evoluzione guidata dall’elaborazione interna, in contrapposizione agli eventi esterni (meglio trattati negli state diagram).

123


Un Un Activity Activity Graph Graph

Scegli bevanda

[ non c'è caffè ]

Prendi lattina di Coca cola

Bevi

Riempi filtro con caffè

Riempi serbatoio con acqua

Prendi tazze

Inserisci filtro in macchina caffè

Accendi macchina caffè

Prepara caffè

Versa caffè

[ c'è il caffè ]

[ C'è la Coca Cola ]

^macchinaCaffe.accendi

Luce macchina caffè accesa

124


oggetti responsabili di azioni

oggetto in ingresso o in uscita da un’azione

azionistati degli oggetti

Swimlanes (corsie)Swimlanes (corsie)

Customer WarehouseSales

Order[in progress]

Order[delivered]

Order[forwarded]

Order[completed]

Requestproduct

Shipproduct

Pay bill

Receiveorder

Processorder

Findproduct

Bill[unpaid]

Bill[paid]

125


Implementation diagramImplementation diagram

Component diagram– mostrano la struttura del codice

Deployment diagram– mostrano la struttura del sistema run-time

126


Component diagramComponent diagram

Mostra le dipendenze tra componenti software– sorgenti, binari, eseguibili– esistenti a compile-time, a link-time, a run-time

I moduli sono rappresentati come tipi di componenti– le istanze si vedono nei deployment diagram

I diversi componenti offrono e usano interfacce specifiche– Primo passo verso Component Programming

127


ComponentComponentii

dictionaryspell-check

synonyms

mailerRealizes+Mailbox+RoutingList-MailQueue

mailer

+Mailbox

+RoutingList

-MailQueue

mailer+RoutingList

-MailQueue

+Mailbox

128


Component diagramComponent diagram

Un’architettura a “layer”:

dipendenze

129


Component diagram con icone ad-Component diagram con icone ad-hochoc

hello.class

hello.jpg

hello.java

hello.html

130


Deployment diagramDeployment diagram

Mostrano la configurazione a run-time degli elementi attivi a run-time (e dei componenti, processi e oggetti che vi “vivono”).– processi e/o processori

Istanze di componenti software rappresentano le manifestazioni run-time delle unità di codice.

Componenti che non esistono a run-time non appaiono in questi diagrammi.

I legami fra processi possono essere– Connettori passivi

• Generici• Specializzati con opportuni commenti

– Connettori attivi• Modellati con opportuni processi

131


AssociazionAssociazionii

Rappresentano le connessioni fisiche tra i nodi

Server

Client1

Client2

<<

RS-232>>

<<RS-232>>

132


NodNodii e componentie componenti

Un grafo– nodi = risorsa

computazionale• possono contenere

istanze di componenti e/o oggetti

– archi = comunicazione

• tipicamente indicano una relazione di utilizzo

Server: Host

:schedulerreservations

myPC: PC

:planner

Meetings<<database>>

133


NodNodii ee component componentii

Server: Host

:schedulerreservations

myPC: PC

:planner

<<tcp/ip>>

Mirror: Host

:scheduler<<tcp/ip>>

<<tcp/ip>>

134


Dove trovare altre Dove trovare altre informazioniinformazioni

Esistono diverse collezioni di link a siti web contenenti informazioni su strumenti e prodotti vari.

www.cetus-links.org – una collezione estesa di riferimenti a siti sull’analisi e

progettazione OO (non necessariamente UML).

135


Bibliografia: LibriBibliografia: Libri

Terry Quatrani, Visual Modeling with Rational Rose and UML, Addison-Wesley

Unified Modeling Language User Guide Unified Modeling Language Reference Manual H. Eriksson, M. Penker, UML Toolkit, J. Wiley M. Fowler, UML distilled, Addison-Wesley

136


Bibliografia: URLBibliografia: URL

Rational/IBM– http://www-306.ibm.com/software/rational/

Object Management Group– http://www.omg.org

Politecnico di Milano © 2005 - CEFRIEL UML (Unified Modeling Language) un linguaggio di...

Documents

Transcript of Politecnico di Milano © 2005 - CEFRIEL UML (Unified Modeling Language) un linguaggio di...