UML Diagrammi di attività Activity diagramsrenatoconte.altervista.org/UML/DiagAttivita.pdf · ©Renato Conte - UML Activity Diagrams - 2 / 39 - Diagrammi di attività • I diagrammi

© Renato Conte - UML Activity Diagrams - 1 / 39 -

UMLDiagrammi di attività

Activity diagrams

Università di Padova

Facoltà di Scienze MM.FF.NN

Informatica - anno 2009-10

Corso di Ingegneria del Software

v. 3.1


Diagrammi di attività

• I diagrammi di attività, in UML, sono usati per descrivere il comportamento dinamico di un sistema

• Un diagramma di attività è essenzialmente un flowchart( con alcune modifiche ed aggiunte), che mostra il flusso di controllo tra una attività e l’altra

• Possono essere usati per modellare i workflow, oppure per descrivere i dettagli di un metodo complesso

• I diagrammi di attività sono in correlazione con i diagrammi di stato.

• Un’attività procede senza essere interrotta da segnali esterni


Sintassi dei diagrammi di Attività (1)

Azione Stato di attività

Transizioni

Stato iniziale Initial state

Stato finale Final state


Flows or Edges


Activity node

activity final node

flow final node


Activity and flow final node

ref. Figure 12.91 - UML Superstructure Specification, v2.1.2

Flow final node

Activity final node


Sintassi dei diagrammi di Attività (2)

Fork e join

Branch o Merge

Control flow

Signal sending

Signal receipt


Stati

Activity State

Name: Type[statename]

Uno stato di attività è uno stato atomico. Al completamento dell’azione, avviene la transizione allo stato successivo.

Un “Object flow state” mostra il valore di un oggetto creato od usato in uno stato di attività.


“Branching” e “merging”

[cond1] [cond2]event[cond1]

event[cond2]

event

S1 S2

S S1

S2

S


CalculateCost

ChargeAccount

GetAuthorization

[cost < $50]

[cost >= $50]

esempio “Branching” e “merging”


Fork e join

S

P1 P2

Q1 Q2

R

Da una fork partono due o più thread di controllo.

Una join permetterà la sincronizzazione dei thread.

fork

join


Combinazione di Fork e Join

A B

C equivalente a

A B C

equivalente a


Signal: “send” e “receive”

Await Authorisation

Enter Credit

Card Data

request

authorise

creditCenter

Charge Card

[amount <= $25][amount > $25]

Receiver object

Sender objectAwait

Authorisation

Enter Credit

Card Data

Charge Card

[amount <= $25]

[amount > $25]

/authorise

/send creditCenter.request()


esempio

Signal send Signal

Signal

… interpretata come una transizione con una “send action”.

Signal receipt

… tradotta in un wait state (uno stato con nessuna azione associata e con un signal trigger event ).


Grafi di attività - metodi

POEmployee

sortMail()

deliverMail()«realize»

POEmployee.sortMail() POEmployee.deliverMail()

Check OutTruck

Put MailIn Boxes

POEmployee DeliverMail Method

Sottoattività 1.4


• Subactivities

SubActivity

Input Output

Foo

Bar

Sottoattività 2.x

SubActivity


InstallFoundation

• Uno stato di sincronizzazione ( ) è ereditato dal diagramma a stati, ma prevalentemente è usato in diagrammi di attività

• Permette la comunicazione tra processi paralleli.

Coordinamento e sincronizzazione (1.x)

State machinenotation

Inspect

BuildFrame

InstallElectricity

in Foundation

PutOn

Roof

InstallElectricityIn Frame

InstallElectricityOutside

InstallWalls

* *


Partitions (Swimlane 1.x)

Request

Take Order

Deliver Order

Fill OrderPay

Collect Order

Sales(vendite)

Stockroom(magazzino)

Customer(cliente)

Le partizioni o corsie evidenziano

responsabilità

evadere

consegnare

portar via


• Un speciale tipo di “passo” (stato) che rappresenta la disponibilità di un particolare tipo di oggetto, probabilmente in uno stato particolare.

• Nessuna azione o sottoattività viene invocata ed il controllo passa allo stato successivo (passo).

• Si possono inserire vincoli (constraints) sui parametri di input e output prima e dopo di esso.

oggetto[stato]Attività A Attività B

Object flow state


Partitions & Object flows

Request

Take Order

Deliver Order

Fill Order

Pay

Collect Order

Customer(cliente)

Sales Stockroom

Order[Entered]

Order[Filled]

Order[Placed]

Order[Delivered]

Object[its state]


Object flow state: example

• Take Order must have an output parameter giving an order, or one of its subtypes.

• Fill Order must have an input parameter taking an order, or one of its supertypes.

• Lines used with object flow have the same semantics as any other state transition.

Order[Taken]Take Order Fill Order


Synch State• “Object flow state” possono essere

stati di sincronizzazione

Obj[S2]

A11 A12 A13

A21 A22 A23


Exception Handler Notation


Exception Handler example


Console

e

Code

inp

outp

validity

v

Ports


input/output pin

Sample

Port

Provided Interface

Required Interface

Input/Output

Entry

Stop

Expansion Node


expansion node / expansion region

<<region type>>• iterative• parallel• stream


Riassunto ed esempi


Action/Activity Integration

Amount updateAccount ( Account a, Amount d ){ Amount nb = a.balance + d; // calcolo nuovo saldo

a.balance = nb; // setBalance

send_notice (a.customer, a, nb);

return nb;}


Action/Activity Example

UpdateAccount

Amount

Account

Deposit

GetBalance

+

SetBalance

SendNotice

GetCustomer


Modifiche e flusso dati

<<presentation>>

Modifica Profilo Utente

Sistema di Aggiornamento

Profilo

[OK]

[cancel]

memoria persistente


Diagrammi equivalenti

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

[else]

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

Soluzione meno ambigua


Alternative


Analisi requisiti


parametri


Signals on an activity diagram


Bibliografia

Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide, Addison Wesley (1999).

Grady Booch, James Rumbaugh, Ivar JacobsonThe Unified Modeling Language Reference Manual, Addison Wesley (1999).

Ivar Jacobson, Grady Booch, James Rumbaugh The Unified Software Development Process,Addison Wesley (1999).


Riferimenti nel Web

OMG UML OMG UML • www.omg.org/umlwww.omg.org/uml

UML Superstructure Specification, v2.1.2

UML link: tool, demo, doc, ...• http://www.cetus-links.org


Domain Model Showing Request Kinds

Several kinds of requests exist between instances, for example, sending a signal or invoking an operation.A send invocation occurrence creates a send request and causes a signal occurrence in the receiver. A call invocation occurrence creates a call request and causes a call occurrence in the receiver.

Documents

UML Diagrammi di attività Activity diagramsrenatoconte.altervista.org/UML/DiagAttivita.pdf · ©Renato Conte - UML Activity Diagrams - 2 / 39 - Diagrammi di attività • I diagrammi