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 / 53
Cosa 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
: Person : Person
1: saluta
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 / 53
Macchine 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 / 53
Semantica
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 / 53
Un 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 / 53
Entry, 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 / 53
Stati compositi
CompositeState
State2 State1
UML Superstructure Specification, v2.1 581
Examples
Figure 15.33 - Composite state with two states
Figure 15.34 - Composite State with hidden decomposition indicator icon Start
entry/ start dial tone
Partial Dial
entry/number.append(n) digit(n)
digit(n)
[number.isValid()] Dialing
exit/ stop dial tone
entry / start dial tone exit / stop dial tone
HiddenComposite entry / start dial tone exit / stop dial tone
HiddenComposite
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
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 16 / 53
Stati 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 / 53
Stati 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 / 53
Transizioni 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
Completamento ed entry/exit points
UML Superstructure Specification, v2.1 583
Examples
Issue 8415 - replace ‘sub state machine’ with ‘submachine state’
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.
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 FailureSubmachine.
The transition emanating from the “subEnd” exit point of the submachine will execute the “fixed1” behavior in addition 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 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 machine in the state name.
Figure 15.36 - Submachine State HandleFailure:
sub1
subEnd error1/
error3/
/fixed1 FailureSubmachine
L’evento error3 fa partire l’esecuzione dallo stato iniziale dello stato composito.
L’evento error1 fa partire l’esecuzione dall’entry point sub1.
Se l’esecuzione termina nell’exit point subEnd si esegue la transizione di completamento che genera il comportamento 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
Entry/exit points (2)
Connessione entry
errore
Autenticazione
nonAutenticato
tuttoOK
erroreConnessione
connesso
nonRiconosciuto ok Inizializzazione
Inizializzazione entry
erroreConnessione
Funzionante
nonAutenticato tuttoOK
dopo(60 secondi) Esempio
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
Un esempio completo
UML Superstructure Specification, v2.1 591
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 called aborted.
Figure 15.41 - State machine diagram representing a state machine DialTone
Dialing
Talking Ringing
Busy dial digit(n)
connected
callee answers Idle
busy liftreceiver
caller hangs up
callee hangs up Active
dial digit(n)
/get dial tone
do/ play busy tone
do/ play ringing tone /enable speech
/disconnect
do/ play dial tone
Pinned
callee answers
Connecting
dial digit(n)[valid]
Time-out do/ play message
dial digit(n)[invalid]
/connect Invalid
do/ play message
[incomplete]
after (15 sec.)
after (15 sec.) activeEntry
aborted
abort terminate
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 24 / 53
Comportamento 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
ExamplesFigure 15.33 - Composite state with two states
Figure 15.34 - Composite State with hidden decomposition indicator icon Start
entry/ start dial tone
Partial Dial entry/number.append(n) digit(n)
digit(n)
[number.isValid()]
Dialing
exit/ stop dial tone
entry / start dial tone exit / stop dial tone
HiddenComposite entry / start dial tone exit / stop dial tone
HiddenComposite
In una m.s. di comportamento, gli stati possono contenere azioni intraprese all’entrata (entry), all’interno (do) e
all’uscita (exit) dello stato.
Finora abbiamo visto soprattutto questo tipo di diagramma, che è il più comune
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 26 / 53
Esempio: m.s. di protocollo
UML Superstructure Specification, v2.1 557
2. Executable protocol state machines, that specify all events that an object may receive and handle, together with the transitions that are implied. In this case, the legal transitions for operations will exactly be the triggered transitions.
The call trigger specifies the effect action, which is the call of the associated operation.
The representation for both interpretations is the same, the only difference being the direct dynamic implication that the interpretation 2 provides.
Issue 8407 - fix hyphenation
Elaborated forms of state machine modeling such as compound transitions, sub-state machines, composite states, and concurrent regions can also be used for protocol state machines. For example, concurrent regions make it possible to express protocol where an instance can have several active states simultaneously. sub state machines and compound transitions are used as in behavioral state machines for factorizing complex protocol state machines.
A classifier may have several protocol state machines. This happens frequently, for example, when a class inherits several parent classes having protocol state machine, when the protocols are orthogonal. An alternative to multiple protocol state machines 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 {protocol}
placed close to the name of the state machine differentiates graphically protocol state machine diagrams.
15.3.7 ProtocolTransition (from ProtocolStateMachines)
Generalizations
• “Transition (from BehaviorStateMachines)” on page 594 Description
A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for an operation. Transitions of protocol state machines have the following information: a pre condition (guard), on trigger, and a post condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that belongs to the context classifier of the protocol state machine.
Figure 15.12 - Protocol state machine
opened closed
[doorW ay -> isE m pty] C lose/
locked lock/
unlock/
open/
create/
D oor {protocol}
opened closed
[doorW ay -> isE m pty] C lose/
locked lock/
unlock/
open/
create/
D oor {protocol}
In una m.s. di protocollo, gli eventi nelle transizioni sono generalmente operazioni del classificatore di contesto (in questo caso Door)
Il diagramma mostra le operazioni legali in ogni momento del suo ciclo di vita.
L’ordine è particolarmente importante
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 27 / 53
m.s. di protocollo: DBConnector
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 28 / 53
Il 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
Attività: ingredienti
NotationThe notations for activity nodes are illustrated below. There are three kinds of nodes: action node, object node, and control node. See these classes for more information.Examples
This figure illustrates the following kinds of activity node: action nodes (e.g., Receive Order, Fill Order), object nodes (Invoice), and control nodes (the initial node before Receive Order, the decision node after Receive Order, and the fork node and Join node around Ship Order, merge node before Close Order, and activity final after Close Order).
Rationale
Activity nodes are introduced to provide a general class for nodes connected by activity edges.
Changes from previous UML
ActivityNode replaces the use of StateVertex and its children for activity modeling in UML 1.5.
Figure 12.50 - Activity node notation
Figure 12.51 - Activity node example (where the arrowed lines are only the non-activity node symbols)
Action node Object node Control nodes
Receive Fill
Order
Ship Order Order
Close Order
Send Invoice
Make Payment
Accept Payment [order
accepted]
[order rejected]
Invoice
Nodi azione: specificano unità di comportamento.
Nodi oggetto: specificano oggetti usati come input e output di azioni.
Nodi controllo: specificano il flusso dell’attività.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 30 / 53
Nodi azione
326 UML Superstructure Specification, v2.1
Package CompleteActivities
Local pre- and postconditions are shown as notes attached to the invocation with the keywords «localPrecondition» and
«localPostcondition», respectively.
Examples
Examples of actions are illustrated below. These perform behaviors called Send Payment and Accept Payment.
Below is an example of an action expressed in an application-dependent action language:
Package CompleteActivities
The example below illustrates local pre- and postconditions for the action of a drink-dispensing machine. This is considered “local” because a drink-dispensing machine is constrained to operate under these conditions for this particular action. For a machine technician scenario, the situation would be different. Here, a machine technician would have a key to open up the machine, and therefore no money need be inserted to dispense the drink, nor change need be given. In such a situation, the global pre- and postconditions would be all that is required. (Global conditions are described in Activity specification, in the next subsection.) For example, a global precondition for a Dispense Drink activity could be “A drink is selected that the vending machine dispenses.” The postcondition, then, would be “The vending machine dispensed the drink that was selected.” In other words, there is no global requirement for money and correct change.
Figure 12.29 - Local pre- and postconditions
Figure 12.30 - Examples of actions
Figure 12.31 - Example of action with tool-dependent action language
«localPrecondition»
constraint
name
«localPostcondition»
constraint
Accept Payment Send
Payment
FOR every Employee calculate salary print check ENDFOR
326 UML Superstructure Specification, v2.1
Package CompleteActivities
Local pre- and postconditions are shown as notes attached to the invocation with the keywords «localPrecondition» and
«localPostcondition», respectively.
Examples
Examples of actions are illustrated below. These perform behaviors called Send Payment and Accept Payment.
Below is an example of an action expressed in an application-dependent action language:
Package CompleteActivities
The example below illustrates local pre- and postconditions for the action of a drink-dispensing machine. This is considered “local” because a drink-dispensing machine is constrained to operate under these conditions for this particular action. For a machine technician scenario, the situation would be different. Here, a machine technician would have a key to open up the machine, and therefore no money need be inserted to dispense the drink, nor change need be given. In such a situation, the global pre- and postconditions would be all that is required. (Global conditions are described in Activity specification, in the next subsection.) For example, a global precondition for a Dispense Drink activity could be “A drink is selected that the vending machine dispenses.” The postcondition, then, would be “The vending machine dispensed the drink that was selected.” In other words, there is no global requirement for money and correct change.
Figure 12.29 - Local pre- and postconditions
Figure 12.30 - Examples of actions
Figure 12.31 - Example of action with tool-dependent action language
«localPrecondition»
constraint
name
«localPostcondition»
constraint
Accept Payment Send
Payment
FOR every Employee calculate salary print check ENDFOR
Un’azione può invocare un’attività, un comportamento o un’operazione.
Come gli altri elementi di UML, anche le azioni accettano livelli di dettaglio e linguaggi differenti.
Al contrario dei messaggi nei diagrammi di interazione, le azioni non costringono il modellatore a definire tutte le entità in gioco.
Le transizioni (frecce) tra azioni possono avere una guardia.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 31 / 53
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 / 53
Precondizioni e postcondizioni
Package CompleteActivities
Local pre- and postconditions are shown as notes attached to the invocation with the keywords «localPrecondition» and
«localPostcondition», respectively.
Examples
Examples of actions are illustrated below. These perform behaviors called Send Payment and Accept Payment.
Below is an example of an action expressed in an application-dependent action language:
Package CompleteActivities
The example below illustrates local pre- and postconditions for the action of a drink-dispensing machine. This is
considered “local” because a drink-dispensing machine is constrained to operate under these conditions for this particular action. For a machine technician scenario, the situation would be different. Here, a machine technician would have a key to open up the machine, and therefore no money need be inserted to dispense the drink, nor change need be given. In such a situation, the global pre- and postconditions would be all that is required. (Global conditions are described in Activity specification, in the next subsection.) For example, a global precondition for a Dispense Drink activity could be “A drink is selected that the vending machine dispenses.” The postcondition, then, would be “The vending machine dispensed the drink that was selected.” In other words, there is no global requirement for money and correct change.
Figure 12.29 - Local pre- and postconditions
Figure 12.30 - Examples of actions
Figure 12.31 - Example of action with tool-dependent action language
«localPrecondition»
constraint
name
«localPostcondition»
constraint
Accept Payment Payment Send
FOR every Employee calculate salary
print check ENDFOR
Si tratta di condizioni, espresse in qualunque modo, che devono essere soddisfatte per far iniziare o terminare l’azione
(permettere a un token di entrare o uscire).
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 33 / 53
Nodi iniziali e finali
Realizza progetto Supera scritto
Il disco nero marca l’inizio dell’attività (genera token).
Quando un token raggiunge un disco nero bordato (nodo finale), l’attività ha termine.
Possono comparire in qualunque numero all’interno di un’attività (ogni nodo iniziale fa partire un flusso di esecuzione, il primo nodo finale raggiunto ferma tutti i flussi).
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 34 / 53
Nodi decisione e fusione
Action1 Action2
[x<0]
[x=0]
[x>0]
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 / 53
Nodi 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 / 53
Nodi oggetto
Sostieni scritto
Crea progetto Progetto
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
Crea progetto
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 / 53
Stato degli oggetti
Crea progetto
Progetto
Consegna progetto Progetto
[finito]
[valutato]
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)
Accetta evento temporale
Manda segnale Accetta evento
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 / 53
Segnali ed eventi (2)
Notifica consegna Crea progetto
Ricevi valutazione
Data scritto
Sostieni scritto Studia
Inizio corso
Segui lezioni
Ricevi specifiche
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
Attività: esempio
UML Superstructure Specification, v2.1 337
Issue 8208 - add explanatory paragraph
Figure 12.37shows another example activity for a process to resolve a trouble ticket.
Below is an example of using class notation to show the class features of an activity. Associations and state machines can also be shown.
Rationale
Activities are introduced to flow models that coordinate other behaviors, including other flow models. It supports class features to model control and monitoring of executing processes, and relating them to other objects (for example, in an organization model).
Figure 12.37 - Workflow example
Figure 12.38 - Activity class with attributes and operations
Record Reproduce
Problem
Correct Problem Problem
Audit and Record Verify
Resolution
Communicate Results [else]
[recorded]
Trouble Ticket
ID Problem Resolutionand
[cannot reproduce problem]
[problem not solved]
[canreproduce
problem] [duplication of another problem]
[known problem and solution]
[not recorded]
[problem statement rectified]
«activity»
Fill Order costSoFar : USD
timeToComplete : Integer
suspend () resume ()
Un’attività è costituita da un flusso di azioni che ne sono i mattoni. In effetti un’azione può invocare un’altra attività.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 44 / 53
Attività: esempio (2)
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 45 / 53
Attività: parametri e valori di ritorno
In the example below, production materials are streaming in to feed the ongoing printed circuit board fabrication. At the end of the activity, computers are quality checked. Computers that do not pass the test are exceptions. See Parameter for semantics of streaming and exception parameters.
Rationale
Activity parameter nodes are introduced to model parameters of activities in a way that integrates easily with the rest of the flow model.
Changes from previous UML
ActivityParameterNode is new in UML 2.0.
12.3.10 ActivityPartition (from IntermediateActivities)
An activity partition is a kind of activity group for identifying actions that have some characteristic in common.
Figure 12.55 - Example of activity parameters.nodes
Figure 12.56 - Example of activity parameter nodes for streaming and exceptions Produce
Printed-Circuit Boards
Printed- Circuit Boards Production
Materials
Assemble Computers
Assembled Computers
Test Computers
Accepted Computers
Rejected Computers
{stream}
Produce Printed-Circuit
Boards
Printed- Circuit Boards Production
Materials
Assemble Computers
Assembled Computers
Test Computers
Accepted Computers
Rejected Computers
Parametri e valori di ritorno, se esistono, si rappresentano come nodi oggetto sul bordo dell’attività.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 46 / 53
Partizioni (swimlanes)
Progetto
Progetto Valuta progetto Docente
Supera scritto Crea progetto Studente
Valuta progetto Progetto
Valuta progetto
Progetto [finito]
[valutato]
Suddividono il flusso dell’attività, ma non ne modificano il significato.
La suddivisione può essere orizzontale, verticale o multidimensionale.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 47 / 53
Partizioni (2)
UML Superstructure Specification, v2.1 359
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 not specified by the containing partition, because it has an overriding partition.
Figure 12.60 - Activity partition using annotation example
Figure 12.61 - Activity partition using multidimensional swimlane example (Accounting
Department) (Accounting
Department) (Order
Department)
(Order Department)
(Order
Department) (Order
Department) [order
accepted]
Invoice
«external»
Receive Order
Fill Order Ship Order
Close Order
Send Invoice Make
Payment Accept
Payment (Customer)
Order ProcessorAccounting Clerk
Receive Fill
Order Ship
Order Order
Send
Invoice Accept
Payment
Invoice
Close Order
Make Payment [order
accepted]
Seattle Reno
«attribute» performingLocation:Location
«external»
(Customer)
«class»«class»
Le partizioni sono generalmente suddivise secondo uno di 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 / 53
Regioni 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
Regioni interrompibili (2)
Examples
The first figure below illustrates that when an order cancellation request is made—only while receiving, filling, or shipping) orders—the Cancel Order behavior is invoked.
Rationale
Interruptible regions are introduced to support more flexible non-local termination of flow.
Changes from previous UML
Interruptible regions in activity modeling are new to UML 2.0.
12.3.34 JoinNode (from CompleteActivities, IntermediateActivities) A join node is a control node that synchronizes multiple flows.
Generalizations
• “ControlNode (from BasicActivities)” on page 371
Description
A join node has multiple incoming edges and one outgoing edge.
Issue 8509 - capitalize ‘boolean’ and add package header
Package CompleteActivities
Join nodes have a Boolean value specification using the names of the incoming edges to specify the conditions under which the join will emit a token.
Figure 12.100 - InterruptibleActivityRegion example
Receive Fill
Order Ship
Order
Order Close
Order
Send
Invoice Make
Payment Accept
Payment [order
accepted]
[order rejected]
Invoice
Cancel Order Order
cancel request
L’ordine è cancellato solo se un token si trova all’interno della regione al momento della ricezione del segnale.
Ingegneria del Software () I diagrammi di attività e stato A.A. 2010-2011 50 / 53
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 / 53
Conclusioni
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 / 47
Tassonomia 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 service. Structure diagrams do not show the details of dynamic behavior, which are illustrated by behavioral 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.
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 below.
• Activity Diagram - “Activities” on page 307
• Class Diagram - “Classes” on page 21
• Communication Diagram - “Interactions” on page 477
• Component Diagram - “Components” on page 147
• Composite Structure Diagram - “Composite Structures” on page 167
• Deployment diagram - “Deployments” on page 201
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 2 / 47
Cosa sono e a cosa servono
Sono diagrammi di comportamento che modellano le interazioni tra varie entità di un sistema.
Visualizzano lo scambio di messaggi tra entità nel tempo.
Il loro scopo è mostrare come un certo comportamento 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 / 47
Come 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 / 47
Elementi 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 / 47
Istanze 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 / 47
Messaggi
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
Asincrono
Sincrono
message(param)
message2(p1,p2)
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 / 47
Tipi 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 / 47
Attivazioni 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)
500 UML Superstructure Specification, v2.1
Figure 14.15 - Overlapping execution occurrences
14.3.11 Gate (from Fragments)
Generalizations
• “MessageEnd (from BasicInteractions)” on page 515 Description
A Gate is a connection point for relating a Message outside an InteractionFragment with a Message inside the InteractionFragment.
Gate is a specialization of MessageEnd.
Gates are connected through Messages. A Gate is actually a representative of an OccurrenceSpecification that is not in the same scope as the Gate.
Gates play different roles: we have formal gates on Interactions, actual gates on InteractionUses, expression gates on CombinedFragments.
Constraints
[1] The message leading to/from an actualGate of an InteractionUse must correspond to the message leading from/to the formalGate with the same name of the Interaction referenced by the InteractionUse.
[2] The message leading to/from an (expression) Gate within a CombinedFragment must correspond to the message leading from/to the CombinedFragment on its outside.
Semantics
The gates are named either explicitly or implicitly. Gates may be identified either by name (if specified), or by a
constructed identifier formed by concatenating the direction of the message and the message name (e.g., out_CardOut).
The gates and the messages between gates have one purpose, namely to establish the concrete sender and receiver for every message.
Notation
Gates are just points on the frame, the ends of the messages. They may have an explicit name (see Figure 14.19).
The same gate may appear several times in the same or different diagrams.
sd overlap
cc:C aa:A
oper1() callback()
Le attivazioni possono generare altre attivazioni sulla linea di vita chiamante (es. callback).
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 15 / 47
Esempio completo: ATM machine
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 16 / 47
Tipi di messaggi: creazione/distruzione (1)
b : B
<<create>>
<<destroy>>
a : A a : A
b : B
Ingegneria del Software () I diagrammi di interazione A.A. 2010-2011 17 / 47
Tipi 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 / 47
Tipi 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 / 47
Stati (2)
: User
: Lamp
switch()
Off
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 / 47
Frammenti 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 / 47
Frammenti combinati: esempio
alt
[buyerSatisfied]
buyer seller lawyer
[buyerNotSatisfied]
pay
giveItem
handshake
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 / 47