© 2005 - CEFRIEL
PolitecnicoPolitecnicodi Milanodi Milano
UML (Unified Modeling Language)
un linguaggio di modellazione orientato agli oggetti
Luigi LavazzaCEFRIEL
2 © 2005 - CEFRIELUnified Modeling Language
SommarioSommario
Introduzione ai linguaggi di modellazione Fondamenti del paradigma object-oriented UML: il linguaggio Esempi di modellazione con UML
3 © 2005 - CEFRIELUnified Modeling Language
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.
4 © 2005 - CEFRIELUnified Modeling Language
Modellare: un’idea nuova?Modellare: un’idea nuova?
Non proprio si pensi al modello di cupola del Brunelleschi
5 © 2005 - CEFRIELUnified Modeling Language
Caratteristiche del modelloCaratteristiche del modello
Astrazione Modularità Viste molteplici
6 © 2005 - CEFRIELUnified Modeling Language
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.
7 © 2005 - CEFRIELUnified Modeling Language
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
8 © 2005 - CEFRIELUnified Modeling Language
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
9 © 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Molteplici visteMolteplici viste
Un’idea nuova? Non proprio …
13
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
PolitecnicoPolitecnicodi Milanodi Milano
Il paradigma object-oriented
18
© 2005 - CEFRIELUnified Modeling Language
I concetti base del paradigmaI concetti base del paradigmaObject-OrientedObject-Oriented
Classi Oggetti Generalizzazione/specializzazione Polimorfismo Dynamic binding
19
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
GeneralizzazioneGeneralizzazione
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
© 2005 - CEFRIELUnified Modeling Language
GeneralizzazioneGeneralizzazione
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
PolimorfismoPolimorfismo
Conseguenza dell’esistenza di generalizzazione e della compatibilità delle sottoclassi rispetto alle superclassi
Poligono Ellisse
Figura
FiguraChiusa FiguraAperta
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Dynamic binding: esempioDynamic binding: esempio
Poligono Ellisse
Figura
FiguraChiusa FiguraAperta
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
PolitecnicoPolitecnicodi Milanodi Milano
Unified Modeling Language
41
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
SituazioneSituazione
Dove trovare informazioni costantemente aggiornate:– http://www.rational.com– http://www.omg.org– internet newsgroup comp.object
2004
43
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Cardinalità delle associazioniCardinalità delle associazioni
P2P1
Mondo reale
Indicazione (opzionale) di molteplicità
0..*Poligono Punto
Derfinito_da 3..*
P4P5
P3P6
Px
52
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Associazioni esclusiveAssociazioni esclusive
Talvolta un’associazione può esistere verso una classe o verso un’altra (non verso entrambe)
Partita IVA
Persona
{xor}
Azienda
56
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
GeneralizzazioneGeneralizzazione
Esempio di Object Diagram
Dimensione_in_KB
Copia()
Stampa_di
StessoAutore
65
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Classe A Classe B
Classe C
Classe D
operationZ()
<<calls>>
<<instantiates>>
Dipendenza: EsempioDipendenza: Esempio
77
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Use case diagramUse case diagram
Actor
Use case<<include>>
86
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Use case diagram: esempioUse case diagram: esempio
VenditoreVerifica stato ordine
Acquisizione Ordine
Addetto al magazzinoEvasione ordine
Cliente
SupervisoreAttribuzione credito
90
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
: 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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
OperazioniOperazioni
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
© 2005 - CEFRIELUnified Modeling Language
OperazioniOperazioni
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Diagramma di stato: esempio Diagramma di stato: esempio (1)(1)
120
© 2005 - CEFRIELUnified Modeling Language
Sottostati concorrentiSottostati concorrenti
121
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Implementation diagramImplementation diagram
Component diagram– mostrano la struttura del codice
Deployment diagram– mostrano la struttura del sistema run-time
126
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
ComponentComponentii
dictionaryspell-check
synonyms
mailerRealizes+Mailbox+RoutingList-MailQueue
mailer
+Mailbox
+RoutingList
-MailQueue
mailer+RoutingList
-MailQueue
+Mailbox
128
© 2005 - CEFRIELUnified Modeling Language
Component diagramComponent diagram
Un’architettura a “layer”:
dipendenze
129
© 2005 - CEFRIELUnified Modeling Language
Component diagram con icone ad-Component diagram con icone ad-hochoc
hello.class
hello.jpg
hello.java
hello.html
130
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
AssociazionAssociazionii
Rappresentano le connessioni fisiche tra i nodi
Server
Client1
Client2
<<
RS-232>>
<<RS-232>>
132
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
NodNodii ee component componentii
Server: Host
:schedulerreservations
myPC: PC
:planner
<<tcp/ip>>
Mirror: Host
:scheduler<<tcp/ip>>
<<tcp/ip>>
134
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
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
© 2005 - CEFRIELUnified Modeling Language
Bibliografia: URLBibliografia: URL
Rational/IBM– http://www-306.ibm.com/software/rational/
Object Management Group– http://www.omg.org
Top Related