UML Diagrammi di attività Activity diagramsrenatoconte.altervista.org/UML/DiagAttivita.pdf ·...

© 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

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

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

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

Sintassi dei diagrammi di Attività (1)

Azione Stato di attività

Transizioni

Stato iniziale Initial state

Stato finale Final state

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

Flows or Edges

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

Activity node

activity final node

flow final node

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

Activity and flow final node

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

Flow final node

Activity final node

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

Sintassi dei diagrammi di Attività (2)

Fork e join

Branch o Merge

Control flow

Signal sending

Signal receipt

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

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

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

“Branching” e “merging”

[cond1] [cond2]event[cond1]

event[cond2]

event

S1 S2

S S1

S2

S

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

CalculateCost

ChargeAccount

GetAuthorization

[cost < $50]

[cost >= $50]

esempio “Branching” e “merging”

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

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

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

Combinazione di Fork e Join

A B

C equivalente a

A B C

equivalente a

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

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

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

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

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

Grafi di attività - metodi

POEmployee

sortMail()

deliverMail()«realize»

POEmployee.sortMail() POEmployee.deliverMail()

Check OutTruck

Put MailIn Boxes

POEmployee DeliverMail Method

Sottoattività 1.4

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

• Subactivities

SubActivity

Input Output

Foo

Bar

Sottoattività 2.x

SubActivity

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

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

* *

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

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

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

• 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

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

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]

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

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

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

Synch State• “Object flow state” possono essere

stati di sincronizzazione

Obj[S2]

A11 A12 A13

A21 A22 A23

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

Exception Handler Notation

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

Exception Handler example

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

Console

e

Code

inp

outp

validity

v

Ports

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

input/output pin

Sample

Port

Provided Interface

Required Interface

Input/Output

Entry

Stop

Expansion Node

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

expansion node / expansion region

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

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

Riassunto ed esempi

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

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;}

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

Action/Activity Example

UpdateAccount

Amount

Account

Deposit

GetBalance

+

SetBalance

SendNotice

GetCustomer

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

Modifiche e flusso dati

<<presentation>>

Modifica Profilo Utente

Sistema di Aggiornamento

Profilo

[OK]

[cancel]

memoria persistente

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

Diagrammi equivalenti

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

[else]

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

Soluzione meno ambigua

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

Alternative

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

Analisi requisiti

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

parametri

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

Signals on an activity diagram

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

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

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

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

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

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.