Filip Stachecki: /* Activity ⌘ */

2013-08-20T15:09:58Z

Activity ⌘

New page

[[Category:Private]]
[[Category:OCUP]]
==Activity Diagram⌘==
*describe the workflow behavior of a system
*this diagram focuses on flows
===Activity, Action⌘===
[[File:ActivityAction.png]]

'''Activity'''
*describes a '''sequence of actions''' based on control models and object flow models
*contains edges and activity nodes (e.g. actions)
*represented by a rectangle with rounded corners

'''Action'''
* represents a '''single step''' within an activity, that is, one that is not further decomposed within the activity.

===Activity ⌘===
[[File:ActivityNodeEdge.png]]

Activity contains nodes and edges.
====Activity Node ⌘====
[[File:ActivityNodeMetamodel.png]]

Subtypes of Activity Node

[[File:ActivityNode.png]]

====Activity Edge⌘====
[[File:ActivityEdge.png]]
* The edges of an activity
* Denoted by a straight line with an open arrowhead
=====Control Flow⌘=====
[[File:ActivityControlFlow.png]]
* A control flow is an edge that starts an activity node after the previous one is finished
=====Object Flow⌘=====
[[File:ObjectFlow.png|333px]] '''OR''' [[File:ObjectFlow2.png]]

[[File:ObjectFlow3.png]]
* An object flow is an activity edge that can have objects or data passing along it

===Objects⌘===
[[File:ActivityParameter.png]]

*Incoming or outgoing objects are parameters
*Placed (as rectangles) on the border
[[File:ActionPin2.png]]
*Or as small rectangle, called a pin ('''input''' or '''output''')

===Token⌘===
*The semantics of an activity is based on a token flow
*Control tokens and object tokens flow '''between''' nodes '''over''' edges

===Activity Example⌘===
[[File:ActivityExample.png]]

===Initial Node⌘===
[[File:ActivityInitialNode.png]]

* It has outgoing edges but no incoming edges
* An activity may have more than one initial node
** Each generates a concurrent flow
* An initial node can have more than one outgoing edge
** Semantics: a control token at each outgoing edge
* Activity diagrams do not have to have initial nodes
* Notation: a filled circle

===Final Node⌘===
[[File:ActivityFinalNode.png]]

*An activity may have more than one activity final node
*The first one reached stops all flows in the activity
** Regardless of the number of tokens in activity
* At least one incoming edge and no outgoing edges
* If several incoming edges only one must carry a token
* Activity diagrams do not have to have final nodes
* Notation: a filled circle with an outer ring

===Decision⌘===
[[File:ActivityDecision.png|350px]]
* is a control node that chooses between outgoing flows
* One incoming edge and several outgoing edges
* When a token is supplied guards on outgoing edges are evaluated
** Token goes to first true outgoing
* Notation: a rhombus

====Decision Input⌘====
[[File:DecisionInput.png]]

* A decision can also define a behavior
* Every token passed over the incoming edge is passed to the behavior before guards evaluated
* Result of the calculation accessed by the '''guards'''
* Calculation doesn't need to be repeated for each guard
* Notation: a note symbol with keyword «decisionInput»

====Decision Input Flow⌘====
[[File:DecisionInputFlow.png]]

*An additional edge incoming to the decision node that provides a decision input value.
*Is a type of '''ObjectFlow'''.

===Merge⌘===
[[File:ActivityMerge.png|350px]]
* A merge node is a control node that brings together multiple alternate flows
**It is not used to synchronize concurrent flows
*Several incoming edges, one outgoing edge
*Nothing calculated, nothing expected
*Notation: an empty rhombus

===Fork, Join⌘===
[[File:ActivityForkJoin.png|350px]]
*'''Fork''' – one incoming edge and multiple outgoing edges
*'''Join''' – multiple incoming edges and one outgoing edge

===Implicit splitting⌘===
[[File:ImplicitSplitting.png]]

Once action A terminates
* a control token is available at both outgoing edges
* actions B and C start concurrently
===Implicit synchronization⌘===
[[File:ImplicitSynchronization.png]]

Action F doesn't start until tokens are available at both incoming edges - actions D and E have to terminate

===Implicit split/synchronization - object flow 1⌘===
[[File:ImplicitObjectFlow.png]]

'''AND''' semantics for object flows
*Once action A terminates it provides two object nodes
*Action F doesn't start until object tokens are available at both incoming edges - actions D and E have to terminate

===Implicit split/synchronization - object flow 2⌘===
[[File:ObjectFlowORsemantics.png]]

'''OR''' semantics for object flows
*Once action A terminates it provides a single object
**Which edge the object will select is undefined
*Action F receives an object from both D and E
**It would be called twice

===Questions⌘===
# What does an action represent?
# What are pins?
# What kinds of edge are there?
# What kinds of activity node are there?
# At which outgoing edges are tokens made available when an action terminates
# When does the OR semantics apply to object flow?
# How many incoming edges can an initial node have?
#What do several edges outgoing from one initial node signify?

OCUP Activity Diagram - Revision history

Filip Stachecki: /* Activity ⌘ */