I diagrammi di attività e stato - Plone site · The diagram in Figure 15.36 shows a fragment from...

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


Cosa sono e a cosa servono

I diagrammi di attività (activity diagram) e stato (statemachine diagram) sono diagrammi che descrivonocomportamento.Il diagramma di attività modella un comportamento (cheriguarda una o più entità) come un insieme di azioniorganizzate secondo un flusso.Il diagramma di stato modella il comportamento(generalmente di una sola entità) come variazioni del suostato interno.


Un passo indietro: Interazione vs. Macchinaa stati

Interazione: un insieme di oggetti che si scambianomessaggi per raggiungere un dato obiettivo

: Person : Person

1: saluta

2: rispondi

Macchina a stati: descrive la sequenza di stati in cui sitrova un oggetto durante il suo ciclo di vita e in risposta aeventi


Macchine a stati in UML

Qualunque classificatore UML può essere associato a unamacchina a stati che descrive il funzionamento delle sueistanze.Uno stato è una condizione o situazione nella vita di unoggetto in cui esso:

� soddisfa una condizione,� esegue un’attività o� aspetta un evento


Semantica

La macchina a stati riceve occorrenze di eventi chevengono 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 lamacchina 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 duecondizioni diverse, entrambe vere), solo una viene eseguita.


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]/actionLa transizione avviene come risposta a uno degli eventi(quando la guardia è vera), e al momento della transizione ilcontesto esegue l’azione specificataSono tutti opzionali


Un esempio completo (1)


Un esempio completo (2)


(pseudo)stati iniziali e finali

Gli esempi precedenti mostrano due pseudo-stati, peravviare e bloccare la macchina a stati:

� Il disco nero marca l’inizio dell’esecuzione. Non è uno statovero e proprio ma un marcatore che punta allo stato da cuipartire.

� Il disco nero bordato (nodo finale), indica che l’esecuzione èterminata.

Possono comparire in qualunque numero all’interno di undiagramma (o di uno stato composito, che vedremo inseguito).


Azioni interneUno stato può reagire ad eventi (e verificare condizioni)anche senza una transizione ad uno stato diversoLe internal activities sono mostrate nel secondo slot eseguono la stessa sintassi delle transizioniSimile ad una self-transitionEsempio: riempimento di un campo di testo in un form


Entry, Exit, Do

All’interno di uno stato si possono usare alcune azionispeciali, 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 internalactivities invece noUna do-activity non è ‘istantanea’ ma può durare per unintervallo di tempo ed essere interrotta (da altri eventi)


do-activity: esempio

Modelliamo la ricerca di nuovo hardware da installare su unsistema operativo.


Stati compositi

CompositeState

State2State1

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 toneexit / stop dial tone

HiddenComposite


HiddenComposite

Permettono di suddividere la complessità del modello:dall’esterno si vede un macro-stato, al cui interno vi sonoaltri stati.Si può anche creare uno stato che fa riferimento ad un’altrodiagramma di macchina a stati (submachine state).Si può usare un’icona per rappresentare uno statocomposito il cui comportamento interno non è mostrato.


Stati compositi: esempio


Stati compositi e transizioniSi possono definire transizioni da uno stato interno versostati esterniTransizioni in uscita dal bordo dello stato composito e legatead un evento sono ereditate da tutti gli stati all’interno.


History pseudostateUn history pseudostate indica il più recente stato internoattivo di uno stato compositoUtile per ripristinare stati precedentiEsempio: alla ri-accensione di una radio/CD si selezionaradio o CD in base alla scelta attiva allo spegnimento


Stati compositi e concorrenzaGli stati compositi sono utili per modellare la concorrenza.Si divide lo stato composito in (sotto-)diagrammi ortogonalieseguiti in mutua esclusioneIl diagramma sarebbe molto meno chiaro senza questoapproccio (bisogna considerare tutte le possibilità)Esempio: una radiosveglia che o mostra l’orario o faascoltare musica


Stati compositi e sincronizzazioneGli stati compositi sono inoltre utili per modellare lasincronizzazione. Si divide lo stato composito in(sotto-)diagrammi e si usano gli operatori di fork e join (chevedremo tra poco)Esempio: le attività e prove che uno studente devesuperare per concludere un corso


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 dicompletamento è eseguita al termine dell’attività di quellostato (fine azioni do).Nel caso di uno stato composito o submachine state unatransizione di completamento è eseguita quando si giungein uno stato finale oppure un exit point.


Completamento ed entry/exit points


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 inizialedello stato composito.L’evento error1 fa partire l’esecuzione dall’entry point sub1.Se l’esecuzione termina nell’exit point subEnd si esegue latransizione di completamento che genera il comportamentofixed1.Se l’esecuzione termina nello stato finale si segue latransizione sulla destra.


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 astati in diversi punti (simili a entry/exit points interni)Si possono usare in combinazione con i nodi iniziali e finali.


Un esempio completo


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

DialToneDialing

TalkingRinging

Busy

dial digit(n)

connected

callee answers

Idle

busy

liftreceiver

callerhangs up

calleehangs up

Active

dial digit(n)

/get dial tone

do/ play busytone

do/ play ringingtone/enable speech

/disconnect

do/ play dial tone

Pinned

calleeanswers

Connecting

dial digit(n)[valid]

Time-out

do/ play message

dial digit(n)[invalid]

/connectInvalid

do/ play message

[incomplete]after (15 sec.)

after (15 sec.)

activeEntry

aborted

abort terminate


Comportamento vs. Protocollo

Una macchina a stati può essere o del comportamento o diprotocollo (la distinzione è sottile).Una macchina a stati del comportamento specifica uncomportamento del contesto che va modellato: il modo incui reagisce agli eventi.Una macchina a stati di protocollo specifica quali operazionipossono essere eseguite sul contesto in ogni momento, epuò essere associata ad oggetti senza comportamento eperfino non istanziabili (es. interfacce).Un classificatore può avere al massimo una m.s. dicomportamento e un qualunque numero di m.s. diprotocollo.


Esempio: m.s. di comportamento


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


HiddenComposite


HiddenComposite

In una m.s. di comportamento, gli stati possono contenereazioni intraprese all’entrata (entry), all’interno (do) eall’uscita (exit) dello stato.Finora abbiamo visto soprattutto questo tipo di diagramma,che è il più comune


Esempio: m.s. di protocollo


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 -> isEm pty] C lose/

locked

lock/

unlock/

open/

create/

Door {protocol}

opened closed

[doorW ay -> isEm pty] C lose/

locked

lock/

unlock/

open/

create/

Door {protocol}

In una m.s. di protocollo, gli eventi nelle transizioni sonogeneralmente operazioni del classificatore di contesto (inquesto caso Door)Il diagramma mostra le operazioni legali in ogni momentodel suo ciclo di vita.L’ordine è particolarmente importante


m.s. di protocollo: DBConnector


Il diagramma di attività

Modella un’attività relativa ad un qualsiasi oggetto, adesempio:

� 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)


Attività: ingredienti


Notation

The 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 FillOrder

ShipOrderOrder

CloseOrder

SendInvoice

MakePayment

AcceptPayment

[orderaccepted]

[orderrejected]

Invoice

Nodi azione: specificano unità di comportamento.Nodi oggetto: specificano oggetti usati come input e outputdi azioni.Nodi controllo: specificano il flusso dell’attività.


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:


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

AcceptPayment

SendPayment

FOR every Employeecalculate salaryprint checkENDFOR





Examples
















name


AcceptPayment

SendPayment


Un’azione può invocare un’attività, un comportamento oun’operazione.Come gli altri elementi di UML, anche le azioni accettanolivelli di dettaglio e linguaggi differenti.Al contrario dei messaggi nei diagrammi di interazione, leazioni non costringono il modellatore a definire tutte leentità in gioco.Le transizioni (frecce) tra azioni possono avere una guardia.


Transizioni e tokenPer capire la semantica dei diagrammi di attività, bisognaimmaginare delle entità, dette token, che viaggiano lungo ildiagramma.Il flusso dei token definisce il flusso dell’attività.I token possono rimanere fermi in un nodo azione/oggettoin 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 tokensu tutti gli archi in entrata, e tutte le precondizioni sonosoddisfatte.Al termine di un’azione, sono generati control token su tuttigli archi in uscita.


Precondizioni e postcondizioni





Examples
















name


AcceptPayment

SendPayment


Si tratta di condizioni, espresse in qualunque modo, che devonoessere soddisfatte per far iniziare o terminare l’azione(permettere a un token di entrare o uscire).


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 (nodofinale), l’attività ha termine.Possono comparire in qualunque numero all’interno diun’attività (ogni nodo iniziale fa partire un flusso diesecuzione, il primo nodo finale raggiunto ferma tutti iflussi).


Nodi decisione e fusione

Action1 Action2

[x<0]

[x=0]

[x>0]

Action3

I nodi decisione hanno un input e vari output mutuamenteesclusivi: copiano i token in entrata su uno degli output.I nodi fusione hanno vari input e un solo output, sul qualevengono indirizzati tutti i token in ingresso.


Nodi fork/join

Action1

Action2

I nodi fork hanno un ingresso e varie uscite: i token iningresso sono duplicati su tutte le uscite.I nodi join hanno vari ingressi e una sola uscita: quandosono presenti token su tutti gli ingressi, viene prodottoalmeno un token in uscita.I nodi fork dividono un’esecuzione in più flussi concorrenti, inodi join sincronizzano e riuniscono i flussi.


Nodi finali di flusso

Action1

Action2

Action3

Quando raggiunti da un token, causano la terminazionesolo del flusso che li ha toccati.Il raggiungimento di un nodo finale di attività causacomunque la terminazione di tutti i flussi.


Un esempio completo


Nodi oggetto

Sostieni scritto

Crea progetto Progetto

Studia

Servono per modellare gli oggetti in input e output delleazioniI token in uscita da questi nodi sono object token, e sonodiversi dai control token prodotti dai nodi azione:rappresentano veri e propri oggetti.Gli archi in entrata e uscita dai nodi oggetto sono object flowanziché control flow, e ci sono regole che limitano il loro uso(es: gli archi che entrano ed escono dai nodi decisione efusione devono essere o tutti object o tutti control)


Pin

Crea progetto

progetto

Consegna progetto

Si agganciano ai nodi azione per definire un input oppureun output di quell’azione.Questa notazione è equivalente a quella di un nodo oggettotra i due nodi azione.I pin aiutano a mostrare i parametri e valori di ritorno diun’azione.


Stato degli oggetti

Crea progetto

ProgettoConsegna progetto

Progetto

[finito]

[valutato]

Spesso risulta conveniente aggiungere lo stato di unoggetto per mostrarne l’evoluzione durante l’attività.Gli stati devono essere coerenti con la macchina a statiassociata all’oggetto.Questo è l’anello di congiunzione tra diagrammi di attività estato.


Segnali ed eventi (1)

Accetta evento temporale

Manda segnale Accetta evento

Ci sono alcuni nodi azione specializzati che gestisconol’invio e la ricezione di segnali.L’invio di segnali è asincrono e non blocca l’attività.


Segnali ed eventi (2)

Notifica consegnaCrea progetto

Ricevi valutazione

Data scritto

Sostieni scrittoStudia

Inizio corso

Segui lezioni

Ricevi specifiche

I nodi ricezione sono attivi quando hanno token su tutti gliarchi in entrata (se ne hanno) oppure durante l’intera vitadell’attività (se non ne hanno); generano token allaricezione.La ricezione di eventi temporali funziona nello stesso modo,i token sono generati in base ad un’espressione temporale.


Attività: esempio


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 ReproduceProblem

CorrectProblemProblem

Audit andRecord

VerifyResolution

Communicate

Results

[else]

[recorded]

Trouble Ticket

ID Problemand

Resolution

[cannot reproduce problem]

[problem not solved]

[canreproduce problem]

[duplicationof anotherproblem]

[knownproblemand 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 imattoni. In effetti un’azione può invocare un’altra attività.


Attività: esempio (2)


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.


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

ProducePrinted-Circuit

Boards

Printed-CircuitBoards

ProductionMaterials

AssembleComputers

AssembledComputers

TestComputers

AcceptedComputers

RejectedComputers

{stream}

ProducePrinted-Circuit

Boards

Printed-CircuitBoards

ProductionMaterials

AssembleComputers

AssembledComputers

TestComputers

AcceptedComputers

RejectedComputers

Parametri e valori di ritorno, se esistono, si rappresentano comenodi oggetto sul bordo dell’attività.


Partizioni (swimlanes)

Progetto

Progetto Valuta progetto

Docente

Supera scritto

Crea progetto

Studente

Valuta progettoProgetto

Valuta progetto

Progetto

[finito]

[valutato]

Suddividono il flusso dell’attività, ma non ne modificano ilsignificato.La suddivisione può essere orizzontale, verticale omultidimensionale.


Partizioni (2)


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)

[orderaccepted]

Invoice

«external»

ReceiveOrder

Fill Order Ship Order

Close Order

Send Invoice MakePayment

AcceptPayment

(Customer)

Ord

er

Pro

cess

or

Accounti

ng C

lerk

Receive FillOrder

ShipOrderOrder

SendInvoice

AcceptPayment

Invoice

CloseOrder

Make Payment

[orderaccepted]

Seattle Reno

«attribute» performingLocation:Location

«external»(Customer)

«cl

ass»

«cl

ass»

Le partizioni sono generalmente suddivise secondo uno diquesti criteri:

classificatori le cui istanze eseguono le varie partiistanze che eseguono le varie partiruoli/parti del sistema che eseguono le varie partiattributi o valori relativi alle varie parti


Regioni interrompibili (1)

Si usano per specificare una reazione che può avvenire inqualunque momento e comporta l’interruzione dell’attività.Esempi: eccezioni, interrupt, segnali, situazioni di erroredall’esterno.La notazione impiegata è quella di un’attività con i borditratteggiati. Uno o più archi di interrupt (a zigzag) partonoda nodi interni e puntano verso nodi esterni.L’interrupt è generato quando un arco di interrupt èattraversato da un token: tutti gli altri token ecomportamenti nella regione sono terminati.La ricezione di eventi all’interno della regione funziona solose ci sono token al suo interno.


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.


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


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 FillOrder

ShipOrderOrder

CloseOrder

SendInvoice

MakePayment

AcceptPayment

[orderaccepted]

[orderrejected]

Invoice

CancelOrder

Order

cancel

request

L’ordine è cancellato solo se un token si trova all’interno dellaregione al momento della ricezione del segnale.


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à sonodiagrammi di stato in cui gli stati sono azioni).UML 2 (qui utilizzato) ridefinisce e separa la semantica deidue 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 idiagrammi sono diagrammi di stato privi di alcunefunzionalità introdotte con UML 2.


Attività vs. Stato (2)

Uno stato al contrario di un’azione dei diagrammi di attivitàè solitamente rappresentato con aggettivi e nomi piuttostoche verbi.Nei diagrammi di stato non si usano token; le transizionisono effettuate quando avviene l’evento corrispondente.Lo stato iniziale e quello finale si rappresentano allo stessomodo in entrambi i diagrammi (cerchio nero e cerchiobordato).Altri elementi di notazione in comune con i diagrammi diattività sono i nodi decisione (decidono lo stato didestinazione in base a una guardia) e i nodi fork/join, chepermettono al sistema di trovarsi in vari stati ortogonali(paralleli) allo stesso tempo.


Conclusioni

I diagrammi di attività descrivono un flusso di azioni cherealizzano un certo comportamento specifico. L’enfasi nonè sullo scambio di messaggi ma sui blocchi dicomportamento.I diagrammi di macchina a stati si concentrano su un soloclassificatore di contesto e modellano il suo stato interno inrelazione al suo comportamento o alle operazioni chepossono eseguite sulle sue istanze.Come tutti i diagrammi UML, possono essere usati sia alivello di analisi che di progettazione.


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


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 internaCome gli altri diagrammi, possono avere diversi livelli diastrazione.


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.


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.


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


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à


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.


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


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


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.


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).


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)).


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).


Attivazioni annidate (2)


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).


Esempio completo: ATM machine


Tipi di messaggi: creazione/distruzione (1)

b : B<<create>>

<<destroy>>

a : Aa : A

b : B


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


Tipi di messaggi: trovati/persi (1)

a : A b : B

foundMsgsendData

sendData

sendData


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).


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.


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.


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.


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.


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.


Frammenti combinati: esempio

alt

[buyerSatisfied]

buyer seller lawyer

[buyerNotSatisfied]

pay

giveItem

handshake

sue(seller)


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


Operatori: 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 mutualmenteesclusive; al massimo una può essere vera nello stesso

istante, altrimenti il modello non è corretto


Esempio opt

L’operatore opt può anche essere omesso per questioni di

leggibilità


Operatori: 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 inlista]).


Esempio loop


Operatori: 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.


Esempio: loop e break

buyer seller

loop 10,10

lawyer

break [buyerNotSatisfied]

pay

giveItem

sue(seller)

Vengono completate al massimo 10 transazioni, se si passa a

vie legali le transazioni finiscono.


Altri 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.


Usare refsd authentication

alt

: ATM

insertPIN

allowUser

: User

yes

no

: User : ATM

: User : ATM

ref

authentication

optwithdraw

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.


Gate

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).


Gate: esempio

sd example

b : B<<create>>

<<destroy>>

a : Aa : A

b : B

in

out

Vengono definiti due gate, in e out.


Diagrammi 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 canalidi comunicazione tra le entità.

Sono simili ai diagrammi degli oggetti, ma i link tra gli

oggetti trasportano messaggi come nei diagrammi di

sequenza.


Sequenza vs. comunicazione

b : Ba : A

msg1

msg2

sd sequence

a : A b : B

1: msg1

2: msg2

sd communication

Questi diagrammi sono equivalenti.

I messaggi e le loro frecce seguono le stesse regole nei

diagrammi di comunicazione.


Numerazione messaggi

a : A b : B

msg1

c : C

msg2

msg3

sd sequence

a : A b : B

1: msg1

c : C

1.1: msg22: msg3

sd communication

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.


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).


Ramificazione

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.


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à.


Iterazione (2)

a : A

[i] : B

1.1: message()

1 * [for i=1 to n]: sendMessageTo(i)

a : A

b : B

1 *: message()

*

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.


Esempio completo: ATM Machine (Pin Error)


Conclusioni 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.


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

consistentiL’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/


I diagrammi di attività e stato - Plone site · The diagram in Figure 15.36 shows a fragment from...

Documents

Transcript of I diagrammi di attività e stato - Plone site · The diagram in Figure 15.36 shows a fragment from...