OCUP2F 06 Activity Diagram

From Training Material
Jump to navigation Jump to search

Module 2. Activity Diagram⌘

References⌘

  • Filip Stachecki, Concurrency in UML, White Paper, March 2014

Activity Diagram⌘

  • Describes the workflow behavior of a system, focuses on flows.
  • A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work.

Activity, Action⌘

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

  • is a fundamental unit of executable functionality contained within an Activity
  • represents a single step within an activity

Activity ⌘

Activity contains nodes and edges.

Activity Node ⌘

Subtypes of Activity Node

Activity Edge⌘

  • The edges of an activity
  • Denoted by a straight line with an open arrowhead
Control Flow⌘

  • A control flow is an edge that starts an activity node after the previous one is finished
Object Flow⌘

OR

  • An object flow is an activity edge that can have objects or data passing along it

Objects⌘

  • Object Node is used to describe object flow within an activity
  • Notation: rectangle

Pin or Parameter⌘

Parameter

  • Incoming or outgoing objects connected to an activity are parameters
  • Placed (as rectangles) on the border


Pin

  • Or as small rectangle, called a pin (input or output) connected to actions
Pin or Parameter example⌘

Stream and exception parameter⌘

  • Streaming parameters allow values to be passed into and out of a Behavior execution any time during its course, rather than just on invocation and completion.
  • Exception Parameter (output only) is annotated with a small triangle.

Token⌘

  • The semantics of an activity is based on a token flow
  • Control tokens and object tokens flow between nodes over edges
  • An object token with no value in it is called a null token.
  • A null token can be passed along an object flow and invoke behavior without passing any value.

Activity Example⌘

Control Nodes⌘

  • Control Node is used to manage the flow of tokens between other nodes in an Activity.

Initial Node⌘

  • 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

Activity Final Node⌘

  • 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

Flow Final Node⌘

  • A Flow Final Node is a Final Node that terminates a flow by consuming the tokens offered to it.

Decision⌘

  • 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

Merge⌘

  • 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
  • incoming to and outgoing from a Merge must be either all Object Flows or all Control Flows.
Decision example⌘

Fork, Join⌘

  • Fork – one incoming edge and multiple outgoing edges
  • Join – multiple incoming edges and one outgoing edge
Join with Object Flow⌘

  • If one of the incoming flows of a Join Node is an Object Flow, then its outgoing flow must be an Object Flow.
Fork with Object Flow⌘

  • The Activity Edges incoming to and outgoing from a Fork Node must be either all Object Flows or all Control Flows.

Implicit splitting⌘

Once action A terminates

  • a control token is available at both outgoing edges
  • actions B and C start concurrently

Implicit synchronization⌘

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⌘

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

Fork/Join and Merge mix⌘

localPrecondition and localPostcondition⌘

  • localPrecondition for an Action is constraint that should hold when an execution of an Action starts
  • localPostcondition for an Action is constraint that should hold when an execution of an Action completes

Call Actions⌘

Call Behavior Action⌘

  • Call Behavior Action invokes a Behavior directly

Call Operation Action⌘

  • Call Operation Action transmits an Operation call request message to the target object

Send Actions⌘

  • Send Signal Action creates a Signal instance and transmits the instance to the object given on its target
  • Broadcast Signal Action transmits the signal instance to all available target objects in the system.
  • Send Object Action transmits any kind of object to the object given on its target

Accept Event Actions⌘

  • Accept Event Action waits for a specific event to occur.

Accept Event Actions examples⌘

Weight⌘

  • Weight specifies minimum number of tokens that must traverse the Activity Edge at the same time.
  • Once the minimum number of tokens are offered, all the tokens offered by the source are offered to the target all at once.
  • If no weight is specified, this is equivalent to specifying a constant value of 1.

Activity/Action Meta Model⌘

Retrieved from "https://training-course-material.com/index.php?title=OCUP2F_06_Activity_Diagram&oldid=82360"