Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
114 views

Activity Diagrams: Massimo Felici Room 1402, JCMB, KB 0131 650 5899 Mfelici@inf - Ed.ac - Uk

Activity Diagrams describe how activities are coordinated to provide a service. The events needed to achieve some operation, particularly where the operation is intended to achieve a number of different things that require coordination. How a collection of use cases coordinate to create a workflow for an organization.

Uploaded by

api-26462544
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
114 views

Activity Diagrams: Massimo Felici Room 1402, JCMB, KB 0131 650 5899 Mfelici@inf - Ed.ac - Uk

Activity Diagrams describe how activities are coordinated to provide a service. The events needed to achieve some operation, particularly where the operation is intended to achieve a number of different things that require coordination. How a collection of use cases coordinate to create a workflow for an organization.

Uploaded by

api-26462544
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Activity Diagrams

Massimo Felici
Room 1402, JCMB, KB
0131 650 5899
mfelici@inf.ed.ac.uk
Activity Diagrams
ƒ Activity Diagrams describe
• how activities are coordinated to provide a service.
The service can be at different levels of
abstraction.
• The events needed to achieve some operation,
particularly where the operation is intended to
achieve a number of different things that require
coordination.
• How the events in a single use case relate to one
another. In particular, use cases where activities
may overlap and require coordination.
• How a collection of use cases coordinate to create
a workflow for an organization.
ƒ Activity Diagrams consist of activities,
states and transitions between activities
and states
© 2004-2006 SEOC - Lecture Note 14 2
Activity Diagrams’ Rationale
ƒ Model business workflows
ƒ Identify candidate use cases, through the
examination of business workflows
ƒ Identify pre- and post-conditions for use
cases
ƒ Model workflow between/within use cases
ƒ Model complex workflows in operations on
objects
ƒ Model in detail complex activities in a high
level activity diagram
© 2004-2006 SEOC - Lecture Note 14 3
Activity Diagrams at a Glance
Activity Diagrams
• focus on the flow of
activities involved in
a single process
• show how activities
depend on one
another
• capture activities
that are made up of
smaller actions

© 2004-2006 SEOC - Lecture Note 14 4


Activity Diagram Basics
ƒ Activities and Actions
ƒ Transitions and Activity Edges
ƒ Tokens and Activity Nodes
ƒ Control Nodes
• Initial and Final Nodes
• Forks and Joins
• Decision and Merge Points
ƒ States
ƒ Swimlanes

© 2004-2006 SEOC - Lecture Note 14 5


Activities and Actions
ƒ An Activity is the process ƒ An Action is a step in the
being modeled overall activity
ƒ Activities are the vertices of ƒ The work can be documented
the diagram. This is like a as Actions in the activity
state where the criterion for ƒ There are four ways in which
leaving the state is the an action can be triggered
completion of the activity. • On Entry: as soon as the
ƒ An Activity is a unit of work activity starts
that needs to be carried out • Do: during lifetime of the
ƒ Any Activity takes time activity
• On Event: in response to an
event
• On Exit: just before the
activity completes

© 2004-2006 SEOC - Lecture Note 14 6


Transitions or Activity Edges
ƒ A Transition is the movement ƒ The flow of an activity is
from one activity to another, shown using arrowed lines
the change from one state to called edges or paths
another, or the movement
ƒ Control-flow Transitions
between a state and an
indicate the order of action
activity in either direction
states
ƒ Transitions: unlabelled
ƒ Object-flow Transitions
arrows from one activity to
indicate that an action state
the next.
inputs or outputs an object
ƒ Transitions take place when
one activity is complete and
the next can commence ƒ Time could be a factor in an
activity
ƒ Time events are drawn with
an hourglass symbol

© 2004-2006 SEOC - Lecture Note 14 7


Tokens and Activity Nodes
ƒ Conceptually, UML ƒ UML 2.0 defines several
models information types of activity nodes
moving along an edge as to model different
a token (e.g., real data, types of information
an object or focus of flow
control) • Parameters nodes
ƒ Each edge may have • Object nodes
• a weight associated with • (input or output) Pins –
it that indicates how special notation for
many tokens must be object nodes
• Exception pins, value pins
available before the
tokens are presented to
the target action
• a guard condition

© 2004-2006 SEOC - Lecture Note 14 8


Initial and Final Nodes
ƒ An initial node is the starting point for an
activity
ƒ Two types of final nodes: activity final and
flow final
ƒ Activity final nodes terminate the entire
activity
ƒ Flow final nodes terminate a path through
an activity, but not the entire activity
ƒ It is possible to have multiple initial nodes
and final nodes

© 2004-2006 SEOC - Lecture Note 14 9


Forks and Joins
ƒ A transition can be split into ƒ In a detailed design model, you
multiple paths and multiple paths can use forks to represent
combined into a single multiple processes or multiple
transitions by using a threads in a program
synchronization bar ƒ A join is where the paths meet
ƒ A synchronization may have ƒ The bar represents
many in-arcs from activities and synchronization of the
a number of out-arcs to completion of those activities
activities with arcs into the transition
ƒ A fork is where the paths split ƒ A join synchronizes multiple
ƒ On an occurrence of the flows of an activity back to a
transition all the activities with single flow of execution
arcs from the transition are
initiated
ƒ A fork node splits the current
flow through an activity into
multiple concurrent flows

© 2004-2006 SEOC - Lecture Note 14 10


Decision and Merge Points
ƒ A Decision Point shows where the exit transition
from a state or activity may branch in alternative
directions depending on a condition
ƒ A Decision involves selecting one control-flow
transition out of many control-flow transitions
based on a condition
ƒ Each branched edge contains a guard condition
ƒ Guard Expressions (inside []) label the transitions
coming out of a branch
ƒ A merge brings together alternate flows into a
single output flow – note that it does not
synchronize multiple concurrent flows

© 2004-2006 SEOC - Lecture Note 14 11


States
ƒ A state in an activity diagram is ƒ Start and End states
a point where some event needs ƒ The Start state is the entry
to take place before activity can point to a flow.
continue ƒ There can be several End states.
ƒ Activities and States are similar Multiple End states can be used
• States carry out actions as to indicated different follow-on
activities do processes from a particular
• Activities need to complete process
their actions before exiting
ƒ Start and End states can have
• States are used to imply waiting,
not doing
actions too
ƒ It is possible to show an object ƒ Mal-formed diagrams: it is
changing states as it flows possible to form ill-formed
through an activity diagrams that require multiple
activations of activities or can
allow deadlock

© 2004-2006 SEOC - Lecture Note 14 12


Swimlanes
ƒ Swimlanes (or activity ƒ Partitions may be
partitions) indicate where constructed on the basis of:
activities take place. • the class and actor doing
ƒ Swimlanes can also be used the activity
to identify areas at the • Partitioning by class and
technology level where actor can help to identify
new associations that have
activities are carried out
not been documented in the
ƒ Swimlanes allow the partition Class model
an activity diagram so that • the use case the activity
parts of it appear in the belongs to
swimlane relevant to that • Partitioning by use cases
element in the partition can help document how use
cases interact

© 2004-2006 SEOC - Lecture Note 14 13


Sending and Receiving Signals
ƒ In activity diagrams, signals represent interactions
with external participants
ƒ Signals are messages that can be sent or received
ƒ A receive signal has the effect of waking up an
action in your activity diagram
ƒ Send signals are signals sent to external
participants
ƒ Note that combining send and receive signals
results in behavior similar to synchronous call, or a
call that waits for a response
• It is common to combine send and receive signals in activity
diagrams, because you often need a response to the signal
you sent

© 2004-2006 SEOC - Lecture Note 14 14


Advanced Activity Modeling
ƒ Connectors ƒ An action is said to be
ƒ UML 2.0 provides supports streaming if it can produce
for modeling Exception output while it is processing
Handling input
ƒ It is possible to show that an ƒ Interruptible activity region
action, or set of actions, ƒ UML 2.0 introduces a new
executes over a collection of type of activity node, called
input data by placing the the central buffer node,
action in an expansion region that provides a place to
(<<parallel>>, <<iterative>> or specify queuing functionality
<<stream>>) for data passing between
ƒ UML 2.0 defines a construct object nodes
to mode looping in activity ƒ A data store node is a
diagrams. A loop node has special type of central
three subregions: setup, buffer node that copies all
body and test data that passes through it

© 2004-2006 SEOC - Lecture Note 14 15


How to construct Activity Diagrams
Activity Diagrams for Business Modeling
1. Finding business actors and use cases
2. Identifying key scenarios of business use cases
3. Combining the scenarios to produce comprehensive
workflows described using activity diagrams
4. Where appropriate, mapping activities to business
areas and recording this using swimlines
5. Refining complicated high level activities similarly,
nested activity diagrams

© 2004-2006 SEOC - Lecture Note 14 16


How to construct Activity Diagrams
Activity Diagrams for Use Case Modeling
1. Finding system Actors, Classes and use cases
2. Identifying key scenarios of system use cases
3. Combining the scenarios to produce
comprehensive workflows described using activity
diagrams
4. Where significant object behavior is triggered by
a workflow, adding object flows to the diagrams
5. Where workflows cross technology boundaries,
using swimlines to map the activities
6. Refining complicated high level activities similarly,
nested activity diagrams

© 2004-2006 SEOC - Lecture Note 14 17


Summary
ƒ Activity Diagrams are good for describing
synchronization and concurrency between
activities
ƒ Activity diagrams are useful for capturing
detailed activities, but they can also capture
elements of the high level workflow the
system is intended to support
ƒ Partitioning can be helpful in investigating
responsibilities for interactions and
associations between objects and actors

© 2004-2006 SEOC - Lecture Note 14 18

You might also like