I diagrammi di attività e stato
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
I diagrammi di attività e stato
Angelo Di Iorio
(dal materiale di Gian Piero Favini)
A.A. 2010-2011
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 1 / 53
Tassonomia dei diagrammi UML 2
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 2 / 53Cosa sono e a cosa servono
I diagrammi di attività (activity diagram) e stato (state
machine diagram) sono diagrammi che descrivono
comportamento.
Il diagramma di attività modella un comportamento (che
riguarda una o più entità) come un insieme di azioni
organizzate secondo un flusso.
Il diagramma di stato modella il comportamento
(generalmente di una sola entità) come variazioni del suo
stato interno.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 3 / 53
Un passo indietro: Interazione vs. Macchina
a stati
Interazione: un insieme di oggetti che si scambiano
messaggi per raggiungere un dato obiettivo
1: saluta
: Person : Person
2: rispondi
Macchina a stati: descrive la sequenza di stati in cui si
trova un oggetto durante il suo ciclo di vita e in risposta a
eventi
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 4 / 53Macchine a stati in UML
Qualunque classificatore UML può essere associato a una
macchina a stati che descrive il funzionamento delle sue
istanze.
Uno stato è una condizione o situazione nella vita di un
oggetto in cui esso:
� soddisfa una condizione,
� esegue un’attività o
� aspetta un evento
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 5 / 53Semantica
La macchina a stati riceve occorrenze di eventi che
vengono salvati su una coda ed estratti uno alla volta.
La semantica di questi eventi è di tipo run-to-completion:
l’occorrenza di un evento viene estratta solo dopo che la
macchina a stati ha finito di processare quella precedente.
Se ci sono più transizioni eseguibili in un dato momento (es.
2 transizioni dallo stesso stato con lo stesso evento e due
condizioni diverse, entrambe vere), solo una viene eseguita.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 7 / 53
Transizioni
Ogni transizione, oltre allo stato origine e destinazione, può
specificare:
� Event: un ‘trigger’ che attiva il passaggio di stato
� Guard: una condizione che, se vera, permette il passaggio
di stato
� Action: un’azione che risulta dal combio di stato
Sintassi: event[guard]/action
La transizione avviene come risposta a uno degli eventi
(quando la guardia è vera), e al momento della transizione il
contesto esegue l’azione specificata
Sono tutti opzionali
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 8 / 53Un esempio completo (1) Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 9 / 53 Un esempio completo (2) Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 10 / 53
(pseudo)stati iniziali e finali
Gli esempi precedenti mostrano due pseudo-stati, per
avviare e bloccare la macchina a stati:
� Il disco nero marca l’inizio dell’esecuzione. Non è uno stato
vero e proprio ma un marcatore che punta allo stato da cui
partire.
� Il disco nero bordato (nodo finale), indica che l’esecuzione è
terminata.
Possono comparire in qualunque numero all’interno di un
diagramma (o di uno stato composito, che vedremo in
seguito).
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 11 / 53
Azioni interne
Uno stato può reagire ad eventi (e verificare condizioni)
anche senza una transizione ad uno stato diverso
Le internal activities sono mostrate nel secondo slot e
seguono la stessa sintassi delle transizioni
Simile ad una self-transition
Esempio: riempimento di un campo di testo in un form
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 12 / 53Entry, Exit, Do
All’interno di uno stato si possono usare alcune azioni
speciali, indicate tramite keyword:
� entry: eseguita quando l’oggetto entra nello stato
� exit: eseguita quando l’oggetto esce dallo stato
� do (do-activity): eseguita mentre l’oggetto è nello stato
Una self-transition attiva sempre le entry ed exit, le internal
activities invece no
Una do-activity non è ‘istantanea’ ma può durare per un
intervallo di tempo ed essere interrotta (da altri eventi)
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 13 / 53
do-activity: esempio
Modelliamo la ricerca di nuovo hardware da installare su un
sistema operativo.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 14 / 53Figure 15.33 - Composite state with two states
Stati compositi
CompositeState HiddenComposite
entry / start dial tone
State1 State2
exit / stop dial tone
Figure 15.34 - Composite State with hidden deco
Permettono di suddividere la complessità del modello:
dall’esterno si vede un macro-stato, al cui interno vi sono
altri stati.
Si può anche creare uno stato che fa riferimento ad un’altro
diagramma di macchina a stati (submachine state).
Si può usare un’icona per rappresentare uno stato
composito il cui comportamento interno non è mostrato.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 15 / 53
Stati compositi: esempio
UML Superstructure Specification, v2.1
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 16 / 53Stati compositi e transizioni
Si possono definire transizioni da uno stato interno verso
stati esterni
Transizioni in uscita dal bordo dello stato composito e legate
ad un evento sono ereditate da tutti gli stati all’interno.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 17 / 53
History pseudostate
Un history pseudostate indica il più recente stato interno
attivo di uno stato composito
Utile per ripristinare stati precedenti
Esempio: alla ri-accensione di una radio/CD si seleziona
radio o CD in base alla scelta attiva allo spegnimento
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 18 / 53Stati compositi e concorrenza
Gli stati compositi sono utili per modellare la concorrenza.
Si divide lo stato composito in (sotto-)diagrammi ortogonali
eseguiti in mutua esclusione
Il diagramma sarebbe molto meno chiaro senza questo
approccio (bisogna considerare tutte le possibilità)
Esempio: una radiosveglia che o mostra l’orario o fa
ascoltare musica
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 19 / 53
Stati compositi e sincronizzazione
Gli stati compositi sono inoltre utili per modellare la
sincronizzazione. Si divide lo stato composito in
(sotto-)diagrammi e si usano gli operatori di fork e join (che
vedremo tra poco)
Esempio: le attività e prove che uno studente deve
superare per concludere un corso
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 20 / 53Transizioni di completamento
Si tratta di transizioni che non hanno un evento associato
(ma possono avere una guardia).
Nel caso di uno stato semplice, una transizione di
completamento è eseguita al termine dell’attività di quello
stato (fine azioni do).
Nel caso di uno stato composito o submachine state una
transizione di completamento è eseguita quando si giunge
in uno stato finale oppure un exit point.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 21 / 53
Examples
Issue 8415 - replace ‘sub state machine’ with ‘submachine state’
Completamento ed entry/exit points
The diagram in Figure 15.36 shows a fragment from a state machine diagram in which a submachine state (the
FailureSubmachine) is referenced. The actual sub state machine is defined in some enclosing or imported name space.
HandleFailure:
FailureSubmachine
error1/
sub1
error3/
subEnd
/fixed1
Figure 15.36 - Submachine State
L’evento error3 fa partire l’esecuzione dallo stato iniziale
In the above example, the transition triggered by event “error1” will terminate on entry point “sub1” of the
FailureSubmachine state machine. The “error3” transition implies taking of the default transition of the
dello stato composito. FailureSubmachine.
The transition emanating from the “subEnd” exit point of the submachine will execute the “fixed1” behavior in addition
L’evento error1 fa partire l’esecuzione dall’entry point sub1.
to what is executed within the HandleFailure state machine. This transition must have been triggered within the
HandleFailure state machine. Finally, the transition emanating from the edge of the submachine state is taken as a result
Se l’esecuzione termina nell’exit point subEnd si esegue la
of the completion event generated when the FailureSubmachine reaches its final state.
Note that the same notation would apply to composite states with the exception that there would be no reference to a state
transizione di completamento che genera il comportamento
machine in the state name.
fixed1.
Se l’esecuzione termina nello stato finale si segue la
transizione sulla destra.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 22 / 53
UML Superstructure Specification, v2.1 583Entry/exit points (2)
Inizializzazione
connesso ok
Connessione Autenticazione
entry tuttoOK
errore nonRiconosciuto
erroreConnessione nonAutenticato
Esempio
Inizializzazione Funzionante
entry tuttoOK
erroreConnessione nonAutenticato
dopo(60 secondi)
Forniscono un modo per entrare ed uscire dalle macchine a
stati in diversi punti (simili a entry/exit points interni)
Si possono usare in combinazione con i nodi iniziali e finali.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 23 / 53
Examples
Figure 15.41 is an example statemachine diagram for the state machine for simple telephone object. In addition to the
initial state, the state machine has an entry point called activeEntry, and in addition to the final state, it has an exit point
Un esempio completo
called aborted.
activeEntry Active
Time-out
do/ play message
dial digit(n)
after (15 sec.) [incomplete]
after (15 sec.)
DialTone dial digit(n)
Dialing
do/ play dial tone
lift dial digit(n)[invalid]
receiver dial digit(n)[valid]
/get dial tone /connect
Invalid
do/ play message Connecting
Idle
busy
Pinned connected
Busy
callee do/ play busy
callee hangs up tone
caller answers
hangs up
/disconnect Ringing
Talking
callee answers do/ play ringing
/enable speech tone
abort terminate
aborted
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 24 / 53
Figure 15.41 - State machine diagram representing a state machineComportamento vs. Protocollo
Una macchina a stati può essere o del comportamento o di
protocollo (la distinzione è sottile).
Una macchina a stati del comportamento specifica un
comportamento del contesto che va modellato: il modo in
cui reagisce agli eventi.
Una macchina a stati di protocollo specifica quali operazioni
possono essere eseguite sul contesto in ogni momento, e
può essere associata ad oggetti senza comportamento e
perfino non istanziabili (es. interfacce).
Un classificatore può avere al massimo una m.s. di
comportamento e un qualunque numero di m.s. di
protocollo.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 25 / 53
Esempio: m.s. di comportamento
Examples
Dialing
Start digit(n) Partial Dial [number.isValid()]
entry/ start dial tone entry/number.append(n)
exit/ stop dial tone
digit(n)
Figure 15.33 - Composite state with two states
In una m.s. di comportamento, gli stati possono contenere
azioni intraprese all’entrata (entry), all’interno (do) e
HiddenComposite
all’uscita (exit) dello stato.
entry / start dial tone
Finora abbiamo visto soprattutto questo tipo di diagramma,
exit / stop dial tone
che è il più comune
Figure 15.34 - Composite State with hidden decomposition indicator icon
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 26 / 53machines can always be found by having one protocol state machine, with sub state machines in concurrent regions
Notation
The notation for protocol state machine is very similar to the one of behavioral state machines. The keyword {proto
Esempio: m.s. di protocollo
placed close to the name of the state machine differentiates graphically protocol state machine diagrams.
D oor {protocol}
[doorW ay -> isE m pty] C lose/
opened closed
create/
open/ lock/
locked
unlock/
Figure 15.12 - Protocol state machine
In una m.s. di protocollo, gli eventi nelle transizioni sono
15.3.7 ProtocolTransition (from ProtocolStateMachines)
generalmente
Generalizations operazioni del classificatore di contesto (in
questo caso Door)
• “Transition (from BehaviorStateMachines)” on page 594
Il diagramma
Descriptionmostra le operazioni legali in ogni momento
del suoAoperation.
ciclo di vita.
protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for
Transitions of protocol state machines have the following information: a pre condition (guard), on trigger,
L’ordinetoa post
è
the particolarmente importante
condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that bel
context classifier of the protocol state machine.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 27 / 53
UML Superstructure Specification, v2.1
m.s. di protocollo: DBConnector
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 28 / 53Il diagramma di attività
Modella un’attività relativa ad un qualsiasi oggetto, ad
esempio:
� classi
� casi d’uso
� interfacce
� componenti
� interfacce
� operazioni di classe
Alcuni usi dei diagrammi di attività:
� modellare il flusso di un caso d’uso (analisi)
� modellare il funzionamento di un’operazione di classe
(progettazione)
� modellare un algoritmo (progettazione)
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 29 / 53
Notation
Attività: ingredienti
The notations for activity nodes are illustrated below. There are three kinds of nodes: action node, ob
control node. See these classes for more information.
Action node Object node Control nodes
Nodi
Figure - Activity specificano
azione:
12.50 node notation unità di comportamento.
Nodi oggetto: specificano oggetti usati come input e output
Examples
di azioni.
This figure illustrates the following kinds of activity node: action nodes (e.g., Receive Order, Fill Or
Nodi and
(Invoice), controllo:
control nodesspecificano il before
(the initial node flussoReceive
dell’attività.
Order, the decision node after Receive O
node and Join node around Ship Order, merge node before Close Order, and activity final after Close
[order
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 30 / 53
rejected]FigureExamples of actions
12.29 - Local pre-are
andillustrated below. These perform behaviors called Send Payment a
postconditions
Examples
Send Accept
Nodi azione Examples of actions are illustrated
Payment Payment below. These perform behaviors called Send Payme
Figure 12.30 - Examples of actions
Send is an example Accept
Below of an action expressed in an application-dependent action language:
Payment Payment
Figure 12.30 - Examples of actions
FOR every Employee
calculate salary
Below is an example
print check of an action expressed in an application-dependent action langua
ENDFOR
Figure 12.31 - Example of action with tool-dependent action language
FOR every Employee
Un’azione può invocare Package
calculate un’attività,
CompleteActivitiesun comportamento o
salary
un’operazione. print Thecheck
ENDFOR
example below illustrates local pre- and postconditions for the action of a drink-dispe
considered “local” because a drink-dispensing machine is constrained to operate under thes
Come gli altri elementi action.di
Figureto12.31
ForUML,
a machine anche
- Example of action
le azioni
technician scenario, accettano
the situation
with tool-dependent
would be different. Here, a machin
action language
open up the machine, and therefore no money need be inserted to dispense the drink, nor
livelli di dettaglio e linguaggi differenti.
a situation, the global pre- and postconditions would be all that is required. (Global condit
Package CompleteActivities
specification, in the next subsection.) For example, a global precondition for a Dispense Dr
Al contrario dei messaggi neithediagrammi
is selected that di interazione,
vending machine dispenses.” The postcondition,lethen, would be “The v
The example
drink thatbelow illustratesIn local
other pre- and postconditions for the action of a drink-d
azioni non costringono il modellatore a definire tutte le
was selected.” words, there is no global requirement
considered “local” because a drink-dispensing machine is constrained to operate under
for money and cor
entità in gioco. action.326 For a machine technician scenario, the situation would be different. Here, UML a macS
to open up the machine, and therefore no money need be inserted to dispense the drink,
Le transizioni (frecce)
a situation,tra azioni
the global pre-possono avere
and postconditions would unabe allguardia.
that is required. (Global co
specification, in the next subsection.) For example, a global precondition for a Dispens
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 31 / 53
is selected that the vending machine dispenses.” The postcondition, then, would be “T
drink that was selected.” In other words, there is no global requirement for money and
326 UM
Transizioni e token
Per capire la semantica dei diagrammi di attività, bisogna
immaginare delle entità, dette token, che viaggiano lungo il
diagramma.
Il flusso dei token definisce il flusso dell’attività.
I token possono rimanere fermi in un nodo azione/oggetto
in attesa che si avveri una condizione su una freccia,
oppure una precondizione o postcondizione su un nodo.
Il movimento di un token è atomico.
Un nodo azione viene eseguito quando sono presenti token
su tutti gli archi in entrata, e tutte le precondizioni sono
soddisfatte.
Al termine di un’azione, sono generati control token su tutti
gli archi in uscita.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 32 / 53Local pre- and postconditions are shown as notes attache
«localPostcondition», respectively.
Precondizioni e postcondizioni
«localPrecondition»
constraint
name
«localPostcondition»
constraint
Si tratta di condizioni,
Figureespresse in qualunque
12.29 - Local pre- andmodo, che devono
postconditions
essere soddisfatte per far iniziare o terminare l’azione
(permettere a unExamples
token di entrare o uscire).
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 33 / 53
Examples of actions are illustrated below. These perform
Nodi iniziali e finali
Send Accept
Payment Payment
Realizza progetto Supera scritto
Figure 12.30 - Examples of actions
Below is an example of an action expressed in an applica
Il disco nero marca l’inizio dell’attività (genera token).
Quando un token raggiunge un disco nero bordato (nodo
finale), l’attività ha
FORtermine.
every Employee
Possono comparire calculate salary numero all’interno di
in qualunque
print check
un’attività (ogni nodo iniziale fa partire un flusso di
esecuzione, il primoENDFORnodo finale raggiunto ferma tutti i
flussi).
Figure 12.31 - Example of action with tool-dependent ac
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 34 / 53
Package CompleteActivitiesNodi decisione e fusione
[x0]
Action3
I nodi decisione hanno un input e vari output mutuamente
esclusivi: copiano i token in entrata su uno degli output.
I nodi fusione hanno vari input e un solo output, sul quale
vengono indirizzati tutti i token in ingresso.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 35 / 53
Nodi fork/join
Action1
Action2
I nodi fork hanno un ingresso e varie uscite: i token in
ingresso sono duplicati su tutte le uscite.
I nodi join hanno vari ingressi e una sola uscita: quando
sono presenti token su tutti gli ingressi, viene prodotto
almeno un token in uscita.
I nodi fork dividono un’esecuzione in più flussi concorrenti, i
nodi join sincronizzano e riuniscono i flussi.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 36 / 53Nodi finali di flusso
Action1
Action2
Action3
Quando raggiunti da un token, causano la terminazione
solo del flusso che li ha toccati.
Il raggiungimento di un nodo finale di attività causa
comunque la terminazione di tutti i flussi.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 37 / 53
Un esempio completo
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 38 / 53Nodi oggetto
Crea progetto Progetto
Sostieni scritto
Studia
Servono per modellare gli oggetti in input e output delle
azioni
I token in uscita da questi nodi sono object token, e sono
diversi dai control token prodotti dai nodi azione:
rappresentano veri e propri oggetti.
Gli archi in entrata e uscita dai nodi oggetto sono object flow
anziché control flow, e ci sono regole che limitano il loro uso
(es: gli archi che entrano ed escono dai nodi decisione e
fusione devono essere o tutti object o tutti control)
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 39 / 53
Pin
progetto
Crea progetto Consegna progetto
Si agganciano ai nodi azione per definire un input oppure
un output di quell’azione.
Questa notazione è equivalente a quella di un nodo oggetto
tra i due nodi azione.
I pin aiutano a mostrare i parametri e valori di ritorno di
un’azione.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 40 / 53Stato degli oggetti
Progetto
Crea progetto [valutato]
Progetto
Consegna progetto
[finito]
Spesso risulta conveniente aggiungere lo stato di un
oggetto per mostrarne l’evoluzione durante l’attività.
Gli stati devono essere coerenti con la macchina a stati
associata all’oggetto.
Questo è l’anello di congiunzione tra diagrammi di attività e
stato.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 41 / 53
Segnali ed eventi (1)
Manda segnale Accetta evento
Accetta evento temporale
Ci sono alcuni nodi azione specializzati che gestiscono
l’invio e la ricezione di segnali.
L’invio di segnali è asincrono e non blocca l’attività.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 42 / 53Segnali ed eventi (2)
Segui lezioni
Studia Sostieni scritto
Inizio corso Data scritto
Ricevi specifiche Ricevi valutazione
Crea progetto Notifica consegna
I nodi ricezione sono attivi quando hanno token su tutti gli
archi in entrata (se ne hanno) oppure durante l’intera vita
dell’attività (se non ne hanno); generano token alla
ricezione.
La ricezione di eventi temporali funziona nello stesso modo,
i token sono generati in base ad un’espressione temporale.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 43 / 53
Issue 8208 - add explanatory paragraph
Attività: esempio
Figure 12.37shows another example activity for a process to resolve a trouble ticket.
Trouble Ticket
[problem statement rectified]
[cannot
reproduce
[recorded] problem]
Record Reproduce Correct
Problem Problem Problem
[not recorded]
[known
[can problem
reproduce [duplication and solution]
problem] of another
problem]
Communicate
ID Problem Verify Results
and Resolution
Resolution [else]
Audit and
Record
[problem not solved]
Un’attività è costituita da un flusso di azioni che ne sono i
Figure 12.37 - Workflow example
mattoni.
Below In effetti
is an example un’azione
of using class può
notation to show the invocare un’altra
class features of an activity. attività.
Associations and state machines can
also be shown.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 44 / 53
«activity»
Fill OrderAttività: esempio (2)
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 45 / 53
Attività: parametri e valori di ritorno
Rejected
Computers
Produce Assemble Test
Production
Printed-Circuit Computers Computers
Materials
Boards
Accepted
Printed- Computers
Assembled
Circuit
Computers
Boards
Figure 12.55 - Example of activity parameters.nodes
Parametri e valori
In the example below, di materials
production ritorno, se esistono,
are streaming in to feed thesi rappresentano
ongoing come At the
printed circuit board fabrication.
end of the activity, computers are quality checked. Computers that do not pass the test are exceptions. See Parameter for
nodi oggetto
semantics of streamingsul
and bordo dell’attività.
exception parameters.
{stream} Rejected
Ingegneria del Software () I diagrammi di attività e stato A.A.Computers
2010-2011 46 / 53
Produce Assemble Test
Production
Printed-Circuit Computers Computers
Materials
BoardsPartizioni (swimlanes)
Studente Docente
Progetto
Crea progetto Progetto
[finito] Valuta progetto
Progetto
Supera scritto Progetto
[valutato]
(Order (Order (Order
Department) Department) Department) (Order
Fill Order Ship Order Department)
Receive
Suddividono il flusso [order
dell’attività, ma non ne modificano
Order
accepted]
Close Order
il
significato.
La suddivisione
Department)può(Customer)
(Accounting
essere orizzontale,
(Accounting
Department)
verticale o
«external»
Send Invoice Make
multidimensionale. Payment
Accept
Payment
Invoice
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 47 / 53
Figure 12.60 - Activity partition using annotation example
The example below depicts multidimensional swim lanes. The Receive Order and Fill Order behaviors are performed by
an instance of the Order Processor class, situated in Seattle, but not necessarily the same instance for both behaviors.
Even though the Make Payment is contained within the Seattle/Accounting Clerk swim cell, its performer and location are
Partizioni (2)
not specified by the containing partition, because it has an overriding partition.
«attribute» performingLocation:Location
Seattle Reno
Order Processor
«class»
Receive Fill Ship Close
Order Order Order Order
[order
accepted]
Accounting Clerk
«external»
Send Accept
«class»
(Customer)
Invoice Make Payment Payment
Invoice
Figure 12.61 - Activity partition using multidimensional swimlane example
Le partizioni sono generalmente suddivise secondo uno di 359
UML Superstructure Specification, v2.1
questi criteri:
classificatori le cui istanze eseguono le varie parti
istanze che eseguono le varie parti
ruoli/parti del sistema che eseguono le varie parti
attributi o valori relativi alle varie parti
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 48 / 53Regioni interrompibili (1)
Si usano per specificare una reazione che può avvenire in
qualunque momento e comporta l’interruzione dell’attività.
Esempi: eccezioni, interrupt, segnali, situazioni di errore
dall’esterno.
La notazione impiegata è quella di un’attività con i bordi
tratteggiati. Uno o più archi di interrupt (a zigzag) partono
da nodi interni e puntano verso nodi esterni.
L’interrupt è generato quando un arco di interrupt è
attraversato da un token: tutti gli altri token e
comportamenti nella regione sono terminati.
La ricezione di eventi all’interno della regione funziona solo
se ci sono token al suo interno.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 49 / 53
Examples
The first figure below illustrates that when an order cancellation request is made—only while receiving, filling, o
Regioni interrompibili (2)
shipping) orders—the Cancel Order behavior is invoked.
Cancel
Order Order
cancel
request
[order
rejected]
Receive Fill Ship Close
Order Order Order Order
[order
accepted]
Send Make Accept
Invoice Payment Payment
Invoice
Figure 12.100 - InterruptibleActivityRegion example
L’ordine
Rationale
è cancellato solo se un token si trova all’interno della
regione al momento della ricezione del segnale.
Interruptible regions are introduced to support more flexible non-local termination of flow.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 50 / 53
Changes from previous UML
Interruptible regions in activity modeling are new to UML 2.0.Attività vs. Stato
In UML 1.x, i due diagrammi sono in pratica la stessa cosa,
ma usata in due modi diversi (i diagrammi di attività sono
diagrammi di stato in cui gli stati sono azioni).
UML 2 (qui utilizzato) ridefinisce e separa la semantica dei
due diagrammi: quelli di attività si basano sulle reti di Petri,
quelli di stato sulla ricerca di Harel.
Dal punto di vista del modellatore, in UML 1.x entrambi i
diagrammi sono diagrammi di stato privi di alcune
funzionalità introdotte con UML 2.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 51 / 53
Attività vs. Stato (2)
Uno stato al contrario di un’azione dei diagrammi di attività
è solitamente rappresentato con aggettivi e nomi piuttosto
che verbi.
Nei diagrammi di stato non si usano token; le transizioni
sono effettuate quando avviene l’evento corrispondente.
Lo stato iniziale e quello finale si rappresentano allo stesso
modo in entrambi i diagrammi (cerchio nero e cerchio
bordato).
Altri elementi di notazione in comune con i diagrammi di
attività sono i nodi decisione (decidono lo stato di
destinazione in base a una guardia) e i nodi fork/join, che
permettono al sistema di trovarsi in vari stati ortogonali
(paralleli) allo stesso tempo.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 52 / 53Conclusioni
I diagrammi di attività descrivono un flusso di azioni che
realizzano un certo comportamento specifico. L’enfasi non
è sullo scambio di messaggi ma sui blocchi di
comportamento.
I diagrammi di macchina a stati si concentrano su un solo
classificatore di contesto e modellano il suo stato interno in
relazione al suo comportamento o alle operazioni che
possono eseguite sulle sue istanze.
Come tutti i diagrammi UML, possono essere usati sia a
livello di analisi che di progettazione.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 53 / 53
I diagrammi di interazione
Angelo Di Iorio
(dal materiale di Gian Piero Favini e Sara Zuppiroli)
A.A. 2010-2011
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 1 / 47Tassonomia dei diagrammi UML 2
Structure diagrams show the static structure of the objects in a system. That is, they depict those elements in a
specification that are irrespective of time. The elements in a structure diagram represent the meaningful concepts of an
application, and may include abstract, real-world and implementation concepts. For example, a structure diagram for an
airline reservation system might include classifiers that represent seat assignment algorithms, tickets, and a credit
authorization
Ingegneria delservice.
SoftwareStructure
() diagrams do notI show the details
diagrammi of dynamic behavior, which are illustrated
di interazione by behavioral
A.A. 2010-2011 2 / 47
diagrams. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Behavior diagrams show the dynamic behavior of the objects in a system, including their methods, collaborations,
activities, and state histories. The dynamic behavior of a system can be described as a series of changes to the system over
time. Behavior diagrams can be further classified into several other kinds as illustrated in Figure A.5.
Cosa sono e a cosa servono
Please note that this taxonomy provides a logical organization for the various major kinds of diagrams. However, it does
not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.
The constructs contained in each of the thirteen UML diagrams is described in the Superstructure chapters as indicated
Sono diagrammi di comportamento che modellano le
below.
interazioni
• Activity Diagram - tra varie
“Activities” entità
on page 307 di un sistema.
• Class Diagram - “Classes” on page 21
Visualizzano
• Communication Diagramlo scambio
- “Interactions” di messaggi tra entità nel tempo.
on page 477
• Component Diagram - “Components” on page 147
Il• loro
Compositescopo è mostrare
Structure Diagram come
- “Composite Structures” un
on page 167 certo comportamento
• Deployment diagram - “Deployments” on page 201
viene realizzato dalla collaborazione delle entità in gioco.
La parola chiave è realizzare: questi diagrammi mostrano
la realizzazione di un comportamento offerto.
In altri termini: il comportamento del sistema da una
prospettiva interna
Come gli altri diagrammi, possono avere diversi livelli di
astrazione.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 3 / 47Come procedere
Un diagramma di interazione necessita di due cose:
Un comportamento da realizzare tratto da un classificatore
(classificatore di contesto), ad esempio...
� un caso d’uso
� un’operazione di classe
Una serie di elementi che realizzano il comportamento, ad
esempio...
� attori
� istanze di classe
Questi ingredienti provengono da diagrammi creati
precedentemente.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 4 / 47
I diagrammi
Ci sono 4 tipi di diagrammi di interazione, noi ci concentreremo
sui primi 2.
Diagramma di sequenza: adatto a mostrare la sequenza
temporale degli avvenimenti per ogni entità nel diagramma.
Diagramma di comunicazione: adatto a mostrare le
relazioni strutturali e i collegamenti tra le entità e i messaggi
che vi transitano.
Diagramma di interazione generale: adatto a mostrare la
costruzione di interazioni complesse a partire da interazioni
più semplici.
Diagramma di temporizzazione: adatto a mostrare
l’evoluzione dell’interazione in tempo reale.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 5 / 47Elementi dei diagrammi d’interazione
Nei diagrammi di interazione generalmente non compaiono
direttamente classificatori come le classi: al loro posto ci sono
Istanze di classificatori (oggetti, istanze di attori, etc.)
Linee di vita (lifeline) di classificatori (esprimono ruoli, non
specifici oggetti)
La differenza tra istanze e linee di vita è sottile, ma in generale è
preferibile usare le linee di vita.
Questi diagrammi includono anche (anzi, ne sono gli elementi
principali) i messaggi, ossia i segnali che si scambiano le
istanze di classificatori e/o le linee di vita
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 6 / 47
Istanze vs. linee di vita
Un’istanza:
� rappresenta uno specifico oggetto, e solo quello
Una linea di vita:
� è più generale
� rappresenta un’istanza arbitraria di un classificatore
� fornisce modi per specificare come quest’istanza viene
scelta
� esprime il ruolo giocato da un’istanza senza preoccuparsi
della sua identità
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 7 / 47Istanze e linee di vita in UML
Jim : Person buyer : Person
Entrambe usano la notazione del loro classificatore, ma le
linee di vita non sono sottolineate.
La notazione completa per una linea di vita è:
nome [selettore] : tipo
Il selettore è un’espressione booleana opzionale che
permette di scegliere un particolare rappresentante del
classificatore, ad es. [id=”1234”].
Senza selettore la linea di vita rappresenta un’arbitraria
istanza.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 8 / 47
I diagrammi di sequenza
Evidenziano l’ordine temporale delle invocazioni dei metodi
Una linea verticale tratteggiata indica una sequenza
temporale.
Gli eventi hanno luogo nel loro ordine sulla linea; le
distanze sono irrilevanti.
Più linee di vita interagiscono per realizzare il
comportamento offerto, scambiandosi messaggi
buyer : Person
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 9 / 47Messaggi
Rappresentano comunicazioni tra linee di vita: segnali,
chiamate di operazioni, creazione e distruzione di oggetti.
Sette tipi definiti:
� chiamata sincrona
� chiamata asincrona
� ritorno da chiamata
� creazione
� distruzione
� messaggio trovato
� messaggio perso
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 10 / 47
Tipi di messaggi: chiamata (1)
lifeline1 lifeline2
message(param)
Asincrono
message2(p1,p2)
Sincrono
Ritorno
Comunicazione sincrona vs. comunicazione asincrona.
I rettangoli di attivazione (indicano un focus di controllo)
sono opzionali.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 11 / 47Tipi di messaggi: chiamata (2)
I messaggi sincroni fanno bloccare chi li manda fino al
messaggio di ritorno del destinatario.
Nei messaggi asincroni il mittente non si aspetta un
messaggio di ritorno e prosegue immediatamente.
I messaggi di ritorno sono opzionali e in generale inclusi
solo quando non ostacolano la leggibilità del diagramma
oppure per segnalare valori di ritorno.
La distinzione tra messaggi sincroni e asincroni in genere
emerge in fase di progettazione.
In fase di analisi, conviene indicare tutti i messaggi come
sincroni (è il caso più vincolante).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 12 / 47
Sintassi messaggi
In fase di analisi generalmente basta includere il nome del
messaggio.
Se si desidera maggiore dettaglio, si include una lista di
parametri tra parentesi.
Si possono anche usare guardie per verificare condizioni
Si possono indicare i parametri formali, quelli attuali, o
entrambi (in quest’ordine: getArea(shape=g)).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 13 / 47Attivazioni annidate (1)
a:A b:B
Le linee di vita possono mandare messaggi a se stesse.
Si tratta di un caso frequente (es. invocazione di operazioni
private).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 14 / 47
Attivazioni annidate (2)
sd overlap
cc:C aa:A
oper1()
callback()
Figure 14.15 - Overlapping execution occurrences
Le attivazioni possono generare altre attivazioni sulla linea di
vita chiamante (es. callback).
14.3.11 Gate (from Fragments)
GeneralizationsI diagrammi di interazione
Ingegneria del Software () A.A. 2010-2011 15 / 47Esempio completo: ATM machine
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 16 / 47
Tipi di messaggi: creazione/distruzione (1)
a:A
b:B
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 17 / 47Tipi di messaggi: creazione/distruzione (2)
Nel messaggio di creazione lo stereotipo può essere
seguito dal nome di un’operazione e relativi parametri
(costruttore).
Questo si rende necessario nel caso si lavori con linguaggi
di programmazione senza costruttori espliciti.
Differenti linguaggi di programmazione OO gestiscono la
distruzione in modi diversi (esplicita, garbage collector).
In fase di analisi, basta immaginare che dopo la distruzione,
l’oggetto non è più accessibile
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 18 / 47
Tipi di messaggi: trovati/persi (1)
a:A b:B
foundMsg
sendData
sendData
sendData
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 19 / 47Tipi di messaggi: trovati/persi (2)
Raramente usati in fase di analisi.
I messaggi trovati indicano situazioni in cui il mittente è
sconosciuto al momento della ricezione, proviene
dall’esterno del diagramma o i dettagli della provenienza
non interessano.
I messaggi persi permettono di visualizzare il
comportamento nel caso un messaggio non giunga a
destinazione (situazione di errore).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 20 / 47
Stati (1)
Uno stato è definito come una condizione o situazione
durante la vita di un oggetto in cui esso soddisfa una
condizione, esegue un’attività o aspetta un evento.
Ogni oggetto in UML può avere una macchina a stati
associata che ne descrive gli stati possibili.
I diagrammi di stato (state machine diagram) sono i più
adatti a rappresentare gli stati e loro transizioni, ma può
essere conveniente mostrare alcuni cambiamenti di stato
nei diagrammi di sequenza.
Generalmente, ci si limita agli stati principali all’oggetto,
mettendo in risalto i messaggi che provocano un
cambiamento di stato.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 21 / 47Stati (2)
: Lamp
: User
Off
switch()
On
In UML, gli stati si rappresentano con rettangoli arrotondati.
I cambiamenti di stato sono generalmente la conseguenza
di uno o più messaggi.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 22 / 47
Realizzare i casi d’uso
Le primitive introdotte fin qui permettono di rappresentare
sequenze di eventi senza ramificazioni; tuttavia, per
realizzare i casi d’uso è necessario poter descrivere
sequenze più complesse.
Le sequenze degli eventi in un caso d’uso contengono
parole chiave come if, then, else, for e while.
I diagrammi di sequenza permettono di tradurre questi
costrutti ed inserirli nel diagramma.
Si ricorre ai frammenti combinati.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 23 / 47Frammenti combinati (1)
Un frammento combinato è una sottoarea di un diagramma
di sequenza che racchiude una parte dell’interazione e le
modalità della sua esecuzione.
Gli elementi di un frammento combinato sono:
� un operatore, che specifica come il frammento viene
eseguito
� uno o più operandi, sottoaree del diagramma di sequenza
che possono essere eseguite
� zero o più condizioni di guardia, espressioni che
determinano quali operandi sono eseguiti.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 24 / 47
Frammenti combinati (2)
La sintassi UML per un frammento combinato è la
seguente:
� un rettangolo con il nome dell’operatore in alto a sinistra
racchiuso nel simbolo di diagramma (rettangolo con angolo
‘tagliato’)
� gli operandi seguono come strisce orizzontali in sequenza,
separati da linee tratteggiate
� la guardia, se presente, compare dopo l’operatore oppure
nella parte alta di un operando tra parentesi quadre
Il rettangolo del frammento combinato si estende
orizzontalmente per includere le linee di vita interessate
dall’interazione.
La guardia può includere qualunque tipo di condizione
booleana, incluso OCL.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 25 / 47Frammenti combinati: esempio
buyer seller lawyer
pay
giveItem
alt
[buyerSatisfied]
handshake
[buyerNotSatisfied]
sue(seller)
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 26 / 47
Operatori
L’operatore determina la semantica dell’esecuzione del
frammento.
UML specifica parecchi tipi di operatori, ma solo alcuni
sono usati frequentemente (quelli che corrispondono alle
primitive di controllo del flusso definite dai linguaggi di
programmazione).
I più usati:
� opt corrisponde a if/then
� alt corrisponde a case/select
� loop corrisponde a for/while
� break corrisponde a break
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 27 / 47Operatori: opt e alt
opt accetta solo un operando, che viene eseguito se e solo
se la guardia è valutata true.
alt accetta un qualunque numero di operandi e ne esegue
al più uno.
� esamina la lista a partire dal primo operando, valuta le
guardie ed esegue solo il primo operando la cui guardia è
vera
� l’operando opzionale [else] è eseguito se nessuna delle
guardie è vera
� le condizioni di guardia devono essere mutualmente
esclusive; al massimo una può essere vera nello stesso
istante, altrimenti il modello non è corretto
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 28 / 47
Esempio opt
L’operatore opt può anche essere omesso per questioni di
leggibilità
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 29 / 47Operatori: loop
Un solo operando, sintassi speciale:
loop min,max [condizione]
Esegue l’operando min volte, e poi al massimo altre (max -
min) volte mentre la condizione è vera.
Si possono omettere min e max.
La condizione è molto flessibile (può essere espressa in
linguaggio naturale), e permette di ciclare su un insieme di
oggetti (es. condizione [forEach oggetto in
lista]).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 30 / 47
Esempio loop
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 31 / 47Operatori: break
Operando singolo, si usa per terminare l’esecuzione del
frammento di interazione corrente (spesso si tratta di un
operatore loop).
Se break ha una condizione di guardia ed è vera, viene
eseguito l’operando ma non il resto dell’interazione dopo il
frammento break.
Se la condizione di guardia esiste ed è falsa, non viene
eseguito l’operando e si continua normalmente.
Se non c’è una guardia, la scelta tra continuare e saltare è
non-deterministica.
Il frammento break deve essere globale rispetto a quello
che interrompe: nella notazione UML, lo interseca ma si
trova ad un livello di nesting superiore.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 32 / 47
Esempio: loop e break
buyer seller lawyer
loop 10,10 pay
giveItem
break [buyerNotSatisfied]
sue(seller)
Vengono completate al massimo 10 transazioni, se si passa a
vie legali le transazioni finiscono.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 33 / 47Altri operatori
Per rendere i diagrammi di sequenza modulari:
� ref: l’operando contiene il nome di un’altra interazione che
viene eseguita qui.
Altri molto meno usati:
� par: gli operandi sono eseguiti in parallelo, senza vincoli
sull’ordinamento dei messaggi appartenenti a operandi
diversi.
� critical: sezione critica, l’operando è eseguito in maniera
atomica e senza interruzioni dalle linee di vita interessate,
anche se all’interno di par o altri frammenti.
� neg: l’operando rappresenta un’interazione che non deve
accadere.
� assert: l’operando rappresenta l’unica interazione
ammissibile in quel momento.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 34 / 47
Usare ref
sd authentication : User : ATM
: User : ATM
ref
insertPIN
authentication
alt
allowUser
opt
withdraw
yes
no
A destra, l’interazione di sinistra inclusa in un’altra
interazione. Si tratta del modo più semplice di usare ref.
sd vuol dire ’sequence diagram’, ma vale per tutti i
diagrammi di interazione.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 35 / 47Gate
Si tratta di un qualunque punto sulla cornice esterna del
diagramma, che può essere la fonte o la destinazione di
una freccia.
Usati per modellare la comunicazione delle linee di vita del
diagramma con l’esterno.
I gate possono avere un nome e comparire qualunque
numero di volte nello stesso diagramma o in diagrammi
diversi.
Possono essere usati in combinazione con ref, forniscono
l’interfaccia di collegamento tra l’interazione chiamante e
quella chiamata (il frammento combinato può avere gli
stessi gate a cui agganciare messaggi).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 36 / 47
Gate: esempio
sd example
a:A
b:B
in
out
Vengono definiti due gate, in e out.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 37 / 47Diagrammi di comunicazione
Chiamati diagrammi di collaborazione in UML 1.x.
In UML 1.x erano semanticamente equivalenti ai diagrammi
di sequenza, in UML 2 non sono altrettanto espressivi.
Si tratta comunque di diagrammi utili a visualizzare i canali
di comunicazione tra le entità.
Sono simili ai diagrammi degli oggetti, ma i link tra gli
oggetti trasportano messaggi come nei diagrammi di
sequenza.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 38 / 47
Sequenza vs. comunicazione
sd sequence
a:A b:B
sd communication
1: msg1
msg1 a:A b:B
2: msg2
msg2
Questi diagrammi sono equivalenti.
I messaggi e le loro frecce seguono le stesse regole nei
diagrammi di comunicazione.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 39 / 47Numerazione messaggi
sd sequence
a:A b:B c:C sd communication
1: msg1
msg1 a:A b:B
msg2
2: msg3 1.1: msg2
msg3
c:C
Nei diagrammi di comunicazione è necessario numerare i
messaggi.
Poiché msg2 si trova nel focus di controllo di msg1 (viene
generato come parte dell’esecuzione di msg1), il suo
numero di sequenza è quello di msg1 seguito da ’.’ e un
numero di sottosequenza.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 40 / 47
Ancora sulla numerazione
Il numero di sequenza ha tanti componenti quanti sono i
livelli di profondità delle attivazioni: es. 2.5.1.10 .
I numeri di sequenza possono velocemente diventare
complessi e danneggiare la leggibilità del diagramma.
Per questo motivo, da un lato si cerca di limitare la
complessità dei diagrammi di comunicazione...
... e dall’altro è consentito raggruppare vari messaggi
correlati in uno solo per ridurne il numero (specialmente in
fase di analisi).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 41 / 47Ramificazione
Si può rappresentare una condizione if/then nei diagrammi
di comunicazione.
Il numero di sequenza è seguito da una guardia tra
parentesi quadre, ad esempio
1.2.1 [!error]: msg(param1,param2)
Il messaggio è inviato solo se la guardia è vera.
Questo costrutto può complicare il diagramma molto in
fretta, e dovrebbe essere usato solo in casi semplici.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 42 / 47
Iterazione (1)
L’operatore di iterazione nei diagrammi di comunicazione è
*. Per esempio
1.2.1 * [for i=1 to n]: msg(param1,param2)
Si può sostituire * con *|| che significa invio parallelo dei
messaggi.
La guardia può essere scritta in qualunque linguaggio o
pseudocodice, compresa la notazione [loop min, max
[condizione]] dei diagrammi di sequenza.
Come mandare lo stesso messaggio ad una collezione di
istanze con l’iterazione?
Due modi: con indici o con molteplicità.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 43 / 47Iterazione (2)
1 * [for i=1 to n]: sendMessageTo(i)
a:A a:A
1 *: message()
1.1: message()
*
[i] : B
b:B
Nel primo caso [i] è una sola istanza, rappresentata tramite
un indice.
Nel secondo caso a è collegato a molti b, e l’operatore *
manda il messaggio a tutti.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 44 / 47
Esempio completo: ATM Machine (Pin Error)
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 45 / 47Conclusioni sui diagrammi di interazione
Si usano i diagrammi di interazione per mostrare come
varie entità collaborino nel fornire un comportamento
desiderato, ad esempio un caso d’uso.
Possono essere usati sia in fase di analisi che in fase di
progettazione.
Aiutano a scoprire e correggere inconsistenze nel
comportamento desiderato (ad esempio una specifica
scorretta del caso d’uso).
Spesso è utile modellare una situazione semplificata con un
diagramma di comunicazione, per poi passare a uno di
sequenza per i dettagli.
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 46 / 47
E per concludere il modulo UML
Analizziamo un esempio completo di analisi e progettazione
object-oriented basato su UML
Diversi diagrammi usati per modellare diverse viste
consistenti
L’esempio è disponibile su Web e liberamente utilizzabile
per usi didattici:
http://www.math-cs.gordon.edu/courses/cs211/AddressBookExample/
Lo stesso sito include anche un esempio più complesso:
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 47 / 47Puoi anche leggere
