uml - roma tre university
TRANSCRIPT
1
UML
Paolo Atzeni (con utilizzo di materiale
di A. Parente, L. Baresi, B. Pernici e G. Rumolo)maggio 2001
maggio 2001 P. Atzeni, UML 2
UML: Unified Modeling Language
• Un linguaggio "standard" (accettato dall'OMG) per la modellazione di sistemi software
• È un linguaggio e non una metodologia– può essere utilizzato con diverse metodologie– i proponenti di UML hanno definito una metodologia
• UML deriva dalla "integrazione" di modelli preesistenti (proposti nel contesto di metodologie):– Booch et al.– OMT (Rambaugh et al.)– OOSE (Jacobson et al.)
• Gli autori di UML sono Booch, Rumbaugh e Jacobson • È adottato da strumenti di sviluppo: Rational Rose
2
maggio 2001 P. Atzeni, UML 3
UML: principi ispiratori
• Modellazione (ovviamente non finalizzata a se stessa, ma allo scopo di produrre software migliore)
• La modellazione è essenziale in ogni attività ingegneristica complessa, in quanto permette di astrarre e semplificare: – "we build models so that we can better understand the
system we are developing" [Booch et al: The UML User Guide]
– "we build models of complex systems because we cannot comprehend such a system in its entirety" [ibidem]
maggio 2001 P. Atzeni, UML 4
Finalità della modellazione
• Visualizzazione un sistema (così com'è o come lo si vorrebbe)• Specifica della struttura e/o del comportamento di un sistema• Definizione delle linee guida per la costruzione di un sistema• Documentazione delle decisioni prese
3
maggio 2001 P. Atzeni, UML 5
Principi della modellazione
(secondo Booch et al, op. cit.)
• The choice of what models to create has a profound influenceon how a problem is attacked and how a solution is shaped
• Every model may be expressed at different levels of precision• The best models are connected to reality• No single model is sufficient. Every nontrivial system is best
approached through a small set of nearly independent models.
maggio 2001 P. Atzeni, UML 6
Costrutti di UML ("building blocks")
• Things: elementi di base di un modello (attenzione al termine "modello"); vari tipi:– strutturali– comportamentali– di raggruppamento– per annotazioni
• Relationships: legami, correlazioni fra "things"• Diagrams: raggruppamenti di "things"; molti tipi diversi
4
maggio 2001 P. Atzeni, UML 7
I diagrammi di UML (!)
• Class diagrams• Object diagrams• Use case diagrams• Sequence diagrams• Collaboration diagrams• Activity diagrams• Statechart diagrams• Component diagrams• Deployment diagrams
maggio 2001 P. Atzeni, UML 8
UML, questioni generali
• Diagrammi e specifica:– i diagrammi sono una "semplificazione" di una specifica
testuale, che segue una sintassi precisa– ogni diagramma può presentare una vista (parziale) della
specifica• "Adornments":
– per ogni costrutto esiste una notazione grafica base, cui possono essere aggiunti dettagli
• Distinzioni di livello:– classe-oggetto (schema-istanza); notazione:
• classe• istanza:classe :classe istanza
– interfaccia-implementazione
5
maggio 2001 P. Atzeni, UML 9
UML, questioni generali (2)
• Meccanismi di estensibilità– stereotipo: estensione del vocabolario (introduzione di
nuovi costrutti); ad esempio, la classe eccezione o la classe interfaccia
– "tagged value": estensione delle (meta)-proprietà di un costrutto; ad esempio, un numero di versione ad ogni classe
– vincolo: estende la semantica di un costrutto, aggiungendo o modificando regole
maggio 2001 P. Atzeni, UML 10
Due costrutti trasversali
• package: meccanismo generale per l'organizzazione di elementi in gruppi (sono solo "concettuali"; a livello realizzativo sono sostituiti dai componenti)
• nota: "spiegazione", commento
6
maggio 2001 P. Atzeni, UML 11
Class Diagram
• Il diagramma che illustra gli elementi dichiarativi (statici) di un modello (classi e tipi) assieme alle loro proprietà caratteristiche e alle relazioni tra di loro intercorrenti.
• Una classe è la descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni, metodi, relazioni e semantiche.
• Un oggetto e’ una istanza di una classe• Gli attributi di una classe rappresentano l’astrazione delle
proprietà statiche degli oggetti che la classe rappresenta• I metodi di una classe rappresentano l’astrazione degli aspetti
comportamentali degli oggetti che la classe rappresenta
maggio 2001 P. Atzeni, UML 12
Classi, dettagli base
• attributo: proprietà con un nome e un tipo (opzionale) – una classe ha zero o più attributi– un attributo può avere valori di default, essere modifcabile o
"frozen", avere una visibilità (pubblica "+", privata "-", protetta"#"), avere una molteplicità ([min .. max]); essere a livello di classe (e non di istanza; cfr static del C++)
• operazione: realizzazione di un servizio che può esser richiesto agli oggetti della classe (ad esempio per modificarne lo stato)– se ne può dare la signature (e info sui parametri: I, O, I/O)– proprietà (visibilità, isQuery, .. concurrent)
• responsabilità:contratto o obbligazione di una classe (la "funzione" o lo scopo)– descritta in linguaggio naturale
7
maggio 2001 P. Atzeni, UML 13
Classe
• Ogni classe ha un nome, unico nell'ambito del package in cui la classe è definita
• Rappresentazione grafica
package::Nome Nome
Attributi
Nome
AttributiOperazioni
Nome
AttributiOperazioni
Responsabilità
maggio 2001 P. Atzeni, UML 14
- Class Diagram- Call for papers attributes
Call for papers
conference titleworkshop dateplacecontactsgoalstopics of interest [*]awards [*]important dates [*]attendancerelated conferencesmore information
Important dates are:Deadlines
E-mail / abstract submissionPaper submissionNotification of acceptanceFinal version submission (ready copy)
Event dateWorkshop
8
maggio 2001 P. Atzeni, UML 15
- Class Diagram- Key persons
other names:PC co-chairPC regional chairPC=Program Committee
Person
info
General Conference chair
<<responsabilities>>- Has overall responsabilitiesfor all conference matters
Coordinating program chair
<<responsabilities>>- Coordinates and controlsthe entire technicalprogram committeess
Program committee chair
<<responsabilities>>-Naming of PC members-Supervision of review andselection process-Coordinates the sub-programcommittee
PC member
<<responsabilities>>-Reviews papers andwritesa report-Partecipates to PCmeeting to discuss papers
Web master
<<responsabilities>>-Dispatch mails-Keeps update informationon the web site
Prooceeding chair
<<responsabilities>>-Verifies the final versionpapers-Gets papers ready to print
Author
<<responsabilities>>-Submits a paper-_Writes the final version-Presents his paper at theWorkshop
maggio 2001 P. Atzeni, UML 16
- Class Diagram- A program committee member can be author
Author PC member
review (paper)
PC member and author
review (paper)
<<responsabilities>>- PC members submit theirown or co-authored papers totheir own region for review
<<exception>>
can't review my paper
<<send>>
9
maggio 2001 P. Atzeni, UML 17
Classi, altri dettagli e varianti
• caratteristiche dipendenti dal linguaggio di programmazione (es.: polimorfismo)
• separazione di interfaccia e implementazione• tipi particolari di classi:
– classi attive (per rappresentare processi o thread)– componenti (in una architettura software)– nodi (di una architettura hardware)
• molteplicità (classi singolari, classi con numero fissato di istanze)
• template• stereotipi predefiniti: metaclasse, powertype, utility
maggio 2001 P. Atzeni, UML 18
Classi: "hints and tips"
• Each class should map to some tangible or conceptual abstraction in the domain of the end user or the implementor. A well structured class:– provides a crisp abstraction of something from the problem
domain or the solution domain– embodies a small, well-defined set of responsibilities and
carries them out all very well– provides a clear separation of the abstraction's specification
and its implementation– is understandable and simple yet extensible and adaptable
10
maggio 2001 P. Atzeni, UML 19
Classi: "hints and tips" (2)
• Nei diagrammi:– show only those properties that are important to understand
the abstraction in its context– organize long lists of attributes and operations by grouping
them according to their category– show related classes in the same class diagrams
maggio 2001 P. Atzeni, UML 20
Classi: prospettive
• Concettuale: rappresenta i concetti del dominio di interesse (in modo indipendente da ogni aspetto realizzativo)
• di specifica: concerne il software, a livello delle interfacce, non della realizzazione
• di implementazione
11
maggio 2001 P. Atzeni, UML 21
Relationships
• Tre tipi fondamentali– dipendenza ("usa": ad esempio come parametro; molti
dettagli, tralasciamo)– generalizzazione (possono essere disgiunte/sovrapposte,
complete/incomplete)– associazione (include aggregazione, composizione)
• Inoltre– realizzazione– raffinamento
maggio 2001 P. Atzeni, UML 22
Dipendenza, generalizzazione, associazione
Window
open()close()move()
handleEvent()display()
Event
ConsoleWindow DialogBox Control
12
maggio 2001 P. Atzeni, UML 23
Associazioni
• Possono essere riflessive• Possono essere n-arie (ma "it's not common"!)• Adornments:
– nome: non obbligatorio; può avere un "verso" (di lettura; niente a che vedere con la "navigabilità", che pure esiste in UML)
– ruolo, per ciascuna classe coinvolta– molteplicità (cardinalità): indicate in modo opposto a quello
usato nell'E-R a noi noto• Aggregazione: un tipo particolare di associazione che specifica
un rapporto aggregato-componente• Composizione: aggregazione in cui ogni componente partecipa
ad un solo aggregato
maggio 2001 P. Atzeni, UML 24
Dipendente Aziendaimpiegato datore di lavoro
0:* 1:1
Dipendente Aziendalavora per 1*
Dipartimento Azienda* 1
Tecnico GruppoDiLavoro* *
13
maggio 2001 P. Atzeni, UML 25
Relationship: altri dettagli e varianti
• associazioni: – direzione di navigazione– visibilità– qualificazione– specificatore di interfaccia– "association class"– vincoli: implicit (derivata), ordered, changeable, addOnly,
frozen– realizzaizone
maggio 2001 P. Atzeni, UML 26
Relationships: "hints and tips"
• Use dependencies only when the relationship is not structural• Use generalization only whne you have an "is-a-kind-of"
relationship• Beware of introducing cyclic generalization relationships• Keep you generalization relationships generally balanced;
neither too deep nor too wide• Use associations primarily where there are structural
relationships among objects
14
maggio 2001 P. Atzeni, UML 27
Relationships: "hints and tips" (2)
• Nei diagrammi:– use either rectilinear or oblique lines consistently– avoid lines that cross– show only the relationships that are necessary (and
nonredundant)
maggio 2001 P. Atzeni, UML 28
- Class Diagram- Committees
Coordinating Programchair : person
Organizing CommitteProgram Committe
Committee
Sub Program CommitteeProgram Committechair : person
Program Committemember : person
nam
es
chairperson
member
has responsabilities for
1
1
1
2..3
11
*
11
*
1
15
maggio 2001 P. Atzeni, UML 29
- Class Diagram- Call for papers officials and tracks
Call for Papers
Officier name
role
Person
info
Track
name
Paper
Submission instruction
formatinstructiondeadlines
1
{sub
set}
{sub
set}
{sub
set}
*
*
1..*
0..1
1..*
*
*
*
*
1
1..*
<<incomplete>>
officier
organizingcommittee
PC member
chairperson
*
maggio 2001 P. Atzeni, UML 30
- Class Diagram- Call for papers tracks
Track
ExhibitsIndustrialPanelTutorialDemonstrationPaper
16
maggio 2001 P. Atzeni, UML 31
- Class Diagram- A program committee member can be author
Author PC member
review (paper)
PC member and author
review (paper)
<<responsabilities>>- PC members submit theirown or co-authored papers totheir own region for review
<<exception>>
can't review my paper
<<send>>
maggio 2001 P. Atzeni, UML 32
UML: dinamica
• classi e relationship modellano la struttura di un sistema• gli oggetti (istanze delle classi) interagiscono fra loro secondo
un "comportamento" che è utile modellare– use case – interaction diagram
• sequence• collaboration
– activity diagram– statechart diagram
17
maggio 2001 P. Atzeni, UML 33
Use case
• Specificano il comportamento del sistema, cioè come il sistema agisce e reagisce, visibile all’esterno (scatola nera)
• Gli use case – descrivono il sistema, l’ambiente e le relazioni fra sistema e
ambiente– coinvolgono gli attori: qualcuno (utente) o qualcosa (sistemi
esterni - hardware) che:• scambia informazioni con il sistema• fornisce input o riceve output dal sistema
maggio 2001 P. Atzeni, UML 34
Definizioni
• Use case:descrizione di un insieme di sequenze di azioni, che un sistema svolge per fornire un risultato osservabile ad un attore– gli use case hanno nomi unici nell'ambito dei package
• Attore: un insieme coerente di ruoli di un utente (di uno use case)
• Attori e use cose possono essere correlati (solo) tramite associazioni (l'attore e lo use case comunicano scambiandosi messaggi)
nome UseCase
nome attore
18
maggio 2001 P. Atzeni, UML 35
Descrizione degli use case
• Descrizione sintetica: "enunciato" degli obiettivi; poche frasi• Flusso degli eventi:
– inizio e conclusione dello use case– interazione con gli attori– dati utilizzati– sequenza ordinaria degli eventi– flusso alternativo o "eccezionale"
maggio 2001 P. Atzeni, UML 36
Descrizione di uno use case
Definizione: Il PC chair distribuisce gli articoli tra i membri del comitato di programma
Flusso principale:• Il sistema propone al PC Chair una lista di coppie di articoli e membri
del comitato di programma ("il membro può recensire l'articolo")• Il PC chair seleziona un insieme di coppie, assegnando tre revisori ad
ogni articolo e carichi uniformi ai PC member • Il sistema manda una mail ad ogni PC member con gli articoli da
giudicareCasi anomali• Un articolo viene ritirato• Le coppie proposte portano ad un assegnazione troppo sbilanciata• Un PC member solleva un conflitto di interessi
19
maggio 2001 P. Atzeni, UML 37
Use case e scenari
• Scenario: istanza di use case– ci sono molti più scenari che use case– scenari principali (uno o pochi per ogni use case)– scenari secondari, per le alternative e le eccezioni
• gli scenari sono descritti per mezzo dei diagrammi di interazione (di sequenza e di collaborazione)
maggio 2001 P. Atzeni, UML 38
Use case: organizzazione
• Gli use case possono – essere raggruppati in package– essere correlati tramite
• generalizzazione: come per le classi• include:uno use case ne utilizza un altro (magari
comune a più use case); è una dipendenza (stereotipo predefinito)
• extend:uno use case è basato su un altro, con varianti (estensioni) definibili solo in punti specifici (extension point)
20
maggio 2001 P. Atzeni, UML 39
Use case e relationship
Place order
Extension pointsset priority
Track order
Validate user
Check smart card
Checkpassword
Place rush order
<<include>>
<<include>>
<<extend>>(set priority)
maggio 2001 P. Atzeni, UML 40
Utilizzo degli use case
• Modellazione ad alto livello del comportamento di un elemento:– intero sistema o sottosistema
• Strumento di comunicazione fra analisti, utenti, sviluppatori• Base per il test• Un possibile metodo per definire gli use case
– individuare gli attori– organizzare gli attori (casi particolari: generalizzazioni)– per ogni attore, individuare le principali interazioni con il
sistema (casi base e alternative ed eccezioni)– organizzare gli use case
21
maggio 2001 P. Atzeni, UML 41
Use case diagram
• Permettono di modellare – il contesto di un sistema o sosttosistema (o classe) – i requisiti per il suo comportamento
• Uno use case diagram è un diagramma che include un insieme di use case e di attori e le relationship fra loro
maggio 2001 P. Atzeni, UML 42
- Use Case Diagram- Conference
CoordinatingProgram Chair
PC chair
PC member
Person
Author
Web master
Ranks papers
SelectsPC members
Dispatchingpapers
E-maildiscussion
Authornotification
Papersubmission
Insert contactinfo
Referee report Receivesan e-mail
Generalconference chair
applicationsetup
22
maggio 2001 P. Atzeni, UML 43
- Use Case Diagram- Paper ranking
PC chair
Ranks papers
Insert partialdecision
Insert finaldecision
CoordinatingProgram Chair
maggio 2001 P. Atzeni, UML 44
Diagrammi di interazione
• Descrivono interazioni, cioè insiemi di oggetti e relationship, con i messaggi che vengono scambiati
• Due tipi– sequence diagram: enfatizza l'ordinamento temporale dei
messaggi– collaboration diagram: enfatizza la struttura degli oggetti
che inviano e ricevono messaggi
23
maggio 2001 P. Atzeni, UML 45
Alcune definizioni
• Interazione: specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico.
• Messaggio: specifica di una comunicazione tra istanze, che trasmette informazione nell'aspettativa che ne consegua attività(evento). Tipi:– Call: invoca un'operazione su oggetto (anche se stesso)– Return: restituisce un valore al chiamante– Send: invia un "segnale" ad un oggetto– Create: crea un oggetto– Destroy: distrugge un oggetto (anche se stesso)
maggio 2001 P. Atzeni, UML 46
Notazione per i messaggi
• Call:
• Return:
• Send:
• Create:
• Destroy:
<<create>>
<<destroy>>
24
maggio 2001 P. Atzeni, UML 47
Notazione, ancora
• Interazione sincrona:
• risposta:
• Interazione asincrona:
• Interazione non specificata(di solito asincrona)
maggio 2001 P. Atzeni, UML 48
Sequence diagram
• Asse verticale: tempo, dall'alto verso il basso• Asse orizzontale: oggetti, da sinistra verso destra in ordine
decrescente di importanza; nella prima colonna l'oggetto che avvia la collaborazione
• Due caratteristiche importanti, per ciascun oggetto– la "linea della vita"– il "focus of control": evidenzia il periodo di tempo durante il
quale un oggetto sta eseguendo un'azione, direttamente o utilizzando una procedura subordinata
25
maggio 2001 P. Atzeni, UML 49
- Sequence Diagram (Interaction Diagram)- Program Committee member selection
:PC chair :Person
Invitation to join PC
answer
[answer=no] <<destroy>>
:PC member
[answer=yes] <<became>>
maggio 2001 P. Atzeni, UML 50
-Seq
uenc
e D
iagr
am(I
nter
actio
nD
iagr
am)
-Pap
er su
bmis
sion
:Aut
hor
:PC
chai
r
pape
rID
:Pro
ceed
ing
chai
r:W
eb m
aste
r
a :s
ubm
it ab
stra
ct{a
.star
tTim
e<
ABS
TRA
CT_
DA
TE}
b :s
ubm
it pa
per
{b.st
artT
ime
< PA
PER_
DA
TE}
c :n
otifi
catio
n
{c.st
artT
ime
<N
OTI
FIC
ATI
ON
_DA
TE}
d : f
inal
vers
ion
{d.st
artT
ime
< FI
NA
L_D
ATE
}
conf
irm
[AFT
ER A
LL P
APE
RSH
AV
E BE
EN R
ECEI
VED
]
26
maggio 2001 P. Atzeni, UML 51
-Seq
uenc
e D
iagr
am(I
nter
actio
nD
iagr
am)
-Disp
atch
ing
pap
ers
:PC
chai
r:P
Cm
embe
r
* [1
0~20
times
]req
uest
ing
revi
ewin
gw
ork
(pap
er)
pape
r con
fiden
ce
rl:r
emin
der l
ette
r{r
l.sta
rtTim
e=
REFE
REE_
DA
TE -
15da
ys}
*rr
:ref
eree
repo
rt{r
r.sta
rtTim
e<
REFE
REE_
DA
TE}
maggio 2001 P. Atzeni, UML 52
Collaboration diagram
• Caratteristiche importanti– stereotipi sui link– numero di sequenza, iterazioni, condizioni
27
maggio 2001 P. Atzeni, UML 53
- Collaboration Diagram (Interaction Diagram) - Paper flow
:PC member
:Author
:PC chair
Program Committee
* 3 : report
* 2 : paper1
: pap
er
4 : notification
maggio 2001 P. Atzeni, UML 54
- Collaboration Diagram (Interaction Diagram)- Paper list lifecycle
uno : PC meeting
due : PC meeting
tre : PC meeting
c : Consolidation meeting
p : paper list
accepted : list = emptynotAccepted : list = emptygrayArea : list = empty
addAccepted(p) : listaddNotAccepted(p) : listaddGrayarea(p) : list
p : paper list
accepted [*]notAccepted [*]grayArea [*]
p : paper list
accepted [*]notAccepted [*]grayArea = empty
*[accepted] due1 : addAccepted(p)
*[grayArea] due3 : addGrayArea(p)*[notAccepted] due2 : addNotAccepted(p)
*[accepted] uno1 : addAccepted(p)*[grayArea] uno3 : addGrayArea(p)
*[notAccepted] uno2 : addNotAccepted(p)
*[accepted] tre1 : addAccepted(p)
*[grayArea] tre3 : addGrayArea(p)
*[notAccepted] tre2 : addNotAccepted(p)
1 / c1 : list=readGrayArea()
* c3 : addNotAccepted(p)* c2 : addAccepted(p)
uno3,due3,tre3 / 1 : <<became>>
c3 / 2 : <<became>>
28
maggio 2001 P. Atzeni, UML 55
- Collaboration Diagram (Interaction Diagram) - Final notification
:Consolidation meeting
:Web master
:Authors * 2 : notification
1 : list of papers results
maggio 2001 P. Atzeni, UML 56
- Collaboration Diagram (Interaction Diagram) - User-system interaction
System
User
Form
29
maggio 2001 P. Atzeni, UML 57
Sequence e collaboration diagram
• Sono semanticamente equivalentI:– si può passare dall'uno all'altro senza perdere informazione– anche se non visualizzano esplicitamente le stesse info
• Scelta fra un tipo e l'altro:– sequence sono preferibili per modellare le interazioni con
enfasi sull'ordinamento temporale– collaboration sono preferibili per porre l'enfasi
sull'organizzazione
maggio 2001 P. Atzeni, UML 58
Activity diagram
• Attività: esecuzione non atomica (in una macchina a stati); include azioni (esecuzione di operazioni, calcoli, invio di messaggi,…)
• Activity diagram: descrive il flusso fra attività
• gli activity diagram sono quindi più dettagliati degli interactiondiagram
30
maggio 2001 P. Atzeni, UML 59
Diagrammi di attività: elementi
• Stati: i nodi del diagramma– stati di azioni (action state): atomici– stati di attività: decomponibili– stati particolari: inizio e fine
• Transizioni: archi che descrivono il passaggio da una attività ad un'altra– semplici– diramazioni (branching)– concorrenza: fork e join
• Corsie (swimlanes): descrivono la "competenza" per lo svolgimento delle attività (in termini di soggetti del mondo reale)
• Flusso di oggetti: le attività si possono inviare oggetti, nel cedere il controllo
maggio 2001 P. Atzeni, UML 60
Utilizzo degli activity diagram
• Modellazione di workflow:– attività a livello abbastanza alto (il flusso di oggetti può
essere importante; le corsie possono essere utili)• Modellazione di operazioni:
– a livello più dettagliato (branch, fork, join sono importanti)
31
maggio 2001 P. Atzeni, UML 61
Modellazione di workflow con activity diagram
• Individuare il workflow di interesse (non tutto il sistema)• Individuare i componenti dell'organizzazione che hanno
responsabilità nel workflow: corsie• Individuare le precondizioni dello stato iniziale e le
postcondizioni dello stato finale• A partire dallo stato iniziale, specificare le operazioni (per mezzo
di stati del diagramma)• Se le azioni sono complesse, procedere per livelli di
raffinamento• Rappresentare le transizioni (prima semplici, poi branching,
infine fork e join)• Se ci sono oggetti cimportanti, includerli nel diagramma
maggio 2001 P. Atzeni, UML 62
Con
fere
nce
offic
ials
Aut
hors
Con
fere
nce
setu
p
Pape
rssu
bmis
sion
Pape
rsse
lect
ion
-Act
ivity
Dia
gram
(Wor
kflo
w)
-Con
fere
nce
rele
vant
act
iviti
es
32
maggio 2001 P. Atzeni, UML 63
Gen
eral
Con
fere
nce
chai
r per
son
Prog
ram
Com
mitt
eech
air p
erso
n
Mai
n of
ficia
lsse
lect
ion
PCm
embe
rse
lect
ion
Writ
esth
eca
ll fo
r pap
ers
-Act
ivity
Dia
gram
(Wor
kflo
w)
-Con
fere
nce
setu
p
Cal
lfor
pape
rs
<<cr
eate
>>
maggio 2001 P. Atzeni, UML 64
Abs
tract
subm
issi
on
Pape
rsu
bmis
sion
Subm
issi
onre
ject
ed
-Act
ivity
Dia
gram
(Wor
kflo
w)
-Pap
er su
bmis
sion
Subm
issi
onac
cept
ed
[ELS
E][A
CC
EPTA
NC
E RE
QU
IREM
ENTS
FU
LFIL
LED
]
33
maggio 2001 P. Atzeni, UML 65
Coo
rdin
atin
gpr
ogra
mch
air
PCch
air
Dis
patc
hes
pape
rs a
mon
gPC
mem
bers
Revi
ew p
aper
san
dw
rite
are
port
Prop
oses
ane-
mai
ldis
cuss
ion
onco
ntro
vers
ial p
aper
s
-Act
ivity
Dia
gram
(Wor
kflo
w)
-Pap
ers s
elec
tion
PCm
embe
rs
E-m
aild
iscu
ssio
non
cont
rove
rsia
l pap
ers
and
new
repo
rt
Rank
s pap
ersa
nd P
Cpa
pers
,en
sure
s tha
t eve
ry p
aper
has
atle
ast3
or 4
revi
ews
Det
erm
ines
Ni(
PCde
cisi
on re
spon
sibi
lity)
and
Mi(
gray
area
)fo
r eac
h C
omm
ittee
Show
sthe
PCpa
pers
rank
edlis
t
PC m
eetin
g,ac
cept
Nip
aper
s
*
**
maggio 2001 P. Atzeni, UML 66
All
PCch
airs
+C
oord
inat
ing
prog
ram
chai
rPC
web
mas
ter
cons
olid
atio
nm
eetin
g,m
ake
final
deci
sion
ongr
ay-a
rea
pape
rs
Not
ifica
tion
ofac
cept
ance
/reje
ctio
n
-Act
ivity
Dia
gram
(Wor
kflo
w)
-Con
solid
atio
nm
eetin
g
*
34
maggio 2001 P. Atzeni, UML 67
maggio 2001 P. Atzeni, UML 68
Modellazione di operazioni con activity diagram
• Individuare le astrazioni coinvolte nell'operazione: parametri, attributi della classe, altre classi di interesse
• Individuare le precondizioni dello stato iniziale dell'operazione e le postcondizioni dello stato finale (ed eventuali invarianti)
• A partire dallo stato iniziale, specificare le operazioni (per mezzo di stati del diagramma)
• Utilizzare il branching se necessario per iterazioni e alternative• Se l'operazione appartiene ad una classe attiva, valutare
l'opportunità di introdurre fork e join per specificare flussi di controllo concorrenti
35
maggio 2001 P. Atzeni, UML 69
-Act
ivity
Dia
gram
(Ope
ratio
n)-P
Cm
embe
rs s
elec
tion
[PO
SITI
VE]
Sele
ctsa
pote
ntia
lPC
mem
bers
list
Send
s inv
itatio
nto
join
the
prog
ram
com
mitt
ee
Cre
ates
a ne
w P
Cm
embe
rslis
t
Add
sthe
pers
onto
the
PCm
embe
rslis
t
[NEG
ATI
VE]
wai
ts fo
r an
answ
er
*
[ELS
E][E
MPT
Y]
n= P
Cm
embe
rsnu
mbe
r+
expe
cted
ans
wer
s
Chec
ks e
xpec
ted
answ
ersl
ist
[ELS
E]
[N<E
XPE
CTE
D P
C M
EMB
ERS
]
maggio 2001 P. Atzeni, UML 70
The
PCch
air
crea
tesa
list
ofco
uple
s(p
aper
, PC
mem
ber)
Send
sapa
per t
oa
PCm
embe
r for
each
cou
ple
-Act
ivity
Dia
gram
(Ope
ratio
n)-D
ispat
chin
g pa
pers
Cre
ates
a ne
wco
uple
Chec
ksth
eex
pect
ed a
nsw
ers
list
[LO
W C
ON
FID
ENCE
][H
IGH
CO
NFI
DEN
CE]
wai
ts fo
r an
answ
er
*
Each
PCm
embe
rha
s to
revi
ew10
~20
pape
rs,
each
pap
er m
ust h
ave
atle
ast3
or 4
revi
ews
[ELS
E]
[EM
PTY
]
36
maggio 2001 P. Atzeni, UML 71
Macchine a stati
• Gli activity diagram sono una forma di "macchina a stati", in quanto modellano l'evoluzione di una operazione
• La forma più generale di macchina a stati è descritta con gli statechart diagram, usati soprattutto per descrivere l'evoluzione di oggetti, soprattutto attivi
maggio 2001 P. Atzeni, UML 72
-Sta
tech
art D
iagr
am-P
aper
life
cycl
e
to r
evie
w
disc
ussio
nfa
se
do /
e-m
ail
disc
ussi
on
revi
ewed
The
pape
r has
atle
ast
3re
port
rank
ed
not a
ccep
ted
gray
area
do /
PCco
-cha
irco
nsol
idat
ion
mee
ting
acce
pted
whe
n(PC
_MEE
TIN
G_D
ATE
) /di
scus
sion
[GO
OD
PA
PER]
[ELS
E]
[CO
NTR
OV
ERSI
AL]
[NO
RMA
L]
37
maggio 2001 P. Atzeni, UML 73
-Sta
tech
art D
iagr
am-P
rogr
amC
omm
itte
mem
ber p
aper
life
cycl
e
to r
evie
w
disc
ussf
ase
do/e
-mai
ldi
scus
sion
revi
ewed
The
pape
r has
atle
ast
4re
port
rank
ed
not a
ccep
ted
acce
pted
[con
trove
rsia
l][n
orm
al]
whe
nPC
mee
ting
isov
er[p
aper
scor
e <=
scor
e(n)
]
PCch
air e
xam
inat
ion
whe
nPC
mee
ting
isov
er[p
aper
scor
e >
scor
e(n)
]
maggio 2001 P. Atzeni, UML 74
Modellazione di applicazioni Web con UML
• Estensioni; ricordiamo:– Meccanismi di estensibilità in UML
• stereotipo: estensione del vocabolario (introduzione di nuovi costrutti); ad esempio, la classe eccezione o la classe interfaccia
• "tagged value": estensione delle (meta)-proprietà di un costrutto; ad esempio, un numero di versione ad ogni classe
• vincolo: estende la semantica di un costrutto, aggiungendo o modificando regole
38
maggio 2001 P. Atzeni, UML 75
Stereotipi per pagine sul client e sul server
<<builds>>
<<submits>>
maggio 2001 P. Atzeni, UML 76
- Class Diagram (Web extension)- Application setup
setup Form
conference name:textconference date [*] :text
<<builds>>
<<submits>>
Configuration page
Configuration page
39
maggio 2001 P. Atzeni, UML 77
-Cla
ssD
iagr
am(W
ebex
tens
ion)
-Pro
gram
com
mitt
ee m
embe
r sel
ectio
n
add
pers
onFo
rm
nam
ee-
mai
l
<<bu
ilds>
>
<<su
bmits
>>
PCm
embe
rs s
elec
tion
PCm
embe
rs s
elec
tion
<<in
fo>>
PCm
embe
rs: l
ist
Pers
on: l
ist
<<E-
mai
l>>
Invi
tatio
n to
join
PC
<<se
nd>>
PCm
embe
rpag
e
<<lin
ks>>
maggio 2001 P. Atzeni, UML 78
- Class Diagram (Web extension)- Abstract submission
Abstract submission
Confirm
<<info>>paper ID : string
Confirm
<<builds>>
Abstract SubmissionForm
abstract : Fileauthor : texte-mail : textco-authors [*] : text
<<submits>>
40
maggio 2001 P. Atzeni, UML 79
- Class Diagram (Web extension) - Paper submission
Paper submission
Confirm Confirm
<<builds>>
Paper SubmissionForm
paper : Filepaper ID : text
<<submits>>
maggio 2001 P. Atzeni, UML 80
- Class Diagram (Web extension) - Final version submission
Final versionsubmission
Confirm Confirm
checkAllSubmitted()sendMail()
<<builds>>
Final versionsubmission Form
paper : Filepaper ID : text
<<submits>>
41
maggio 2001 P. Atzeni, UML 81
-Cla
ssD
iagr
am(W
ebex
tens
ion)
-Disp
atch
ing
pape
rs
Pape
rpag
e
<<bu
ilds>
>PCm
embe
rfor
m
PCm
embe
rs[*]
:ch
eckb
ox
mod
ify()
<<su
bmits
>>Pa
perp
age
<<in
fo>>
pape
r inf
oPC
mem
bers
: lis
tpa
pers
to re
view
:nes
ted
list
Send
allp
aper
s
subm
it()
send
pap
ers
send
Mai
l()<<
subm
its>>
maggio 2001 P. Atzeni, UML 82
- Class Diagram (Web extension) - E-mail discussion
Papers list
<<info>>papers : listscores : nested list
Papers list
<<builds>>
Discussion Form
papers todiscuss [*] :checkbox
<<submits>>
Start e-maildiscussion
submit()
Papers list
sendMail()
<<submits>>
42
maggio 2001 P. Atzeni, UML 83
-Cla
ssD
iagr
am(W
ebex
tens
ion)
-Ref
eree
repo
rtan
d co
ntac
tinf
o
PCm
embe
rpag
e
Con
firm
<<bu
ilds>
>
Rep
ortf
orm
pape
rID
:tex
tre
port
: File
ques
tions
[*]pa
per C
onfid
ence
:che
ckbo
x
<<su
bmits
>>
Con
firm
page
Con
tact
sfo
rmco
ntac
ts[*]
:te
xtto
pics
[*] :
chec
kbox
join
PC
mem
ber:
chec
kbox
mod
ify()
PCm
embe
rpag
e
<<bu
ilds>
>
<<su
bmits
>>
maggio 2001 P. Atzeni, UML 84
-Cla
ssD
iagr
am(W
ebex
tens
ion)
-Ran
king
pape
rs Ran
king
pape
rs
<<in
fo>>
pape
rs: l
ist
Pape
r
<<bu
ilds>
>
Pape
rFor
m
scor
e :t
ext
to re
view
: rad
iore
view
ed: r
adio
rank
ed: r
adio
disc
ussi
onfa
se :
radi
oac
cept
ed: r
adio
gray
area
: ra
dio
reje
cted
: rad
io
<<su
bmits
>>
Sele
ctio
nfo
rm
Pape
r typ
e[*]
:ch
eckb
ox
Pape
r
<<in
fo>>
pape
rsID
:st
ring
refe
ree
repo
rts: l
ist
auth
ors
[*] :
strin
g
<<lin
ks>>
pape
rID
<<su
bmit>
>
Send
not
ifica
tion
subm
it()
<<su
bmit>
>
Send
not
ifica
tion
Send
Mai
l()Se
ndM
ail()