Guidelines: Activity Diagram in the Business Use-Case Model
Topics
The workflow of a business use case describes what the business must do to
provide the value the served business actor requires. The business use case
consists of a sequence of activities that, together, produce something for the
business actor. The workflow often consists of a basic flow and one or more
alternative flows. The structure of the workflow is described graphically with
the help of an activity diagram.
An activity diagram of a workflow explores the ordering of tasks or
activities that accomplish business goals. An activity may be a manual or an
automated task that completes a unit of work.
Activity diagram is a special case of a statechart diagram in which all or
most of the states are activity states and in which all or most of the
transitions are triggered upon completion of actions in the source states.
An activity diagram may have the following elements:
- Activity
states represent the performance of an activity or step within
the workflow.
- Transitions
show what activity state follows another. This type of
transition can be referred to as a completion transition. It differs from a
transition in that it does not require an explicit trigger event;
instead it's triggered by the completion of the activity that the activity
state represents.
- Decisions
for which a set of guard
conditions are defined. Guard conditions control which transition,
of a set of alternative transitions, follows once the activity is complete.
You may also use the decision icon to show where the threads merge again.
Decisions and guard conditions allow you to show alternative
threads in the workflow of a business use case.
- Synchronization
bars are used to show parallel subflows. Synchronization bars allow
you to show concurrent
threads in the workflow of a business use case.
An activity diagram for the business use case Individual
Check-In in the business use-case model of Airport Check-In
Guard conditions are used to show that one of a set of concurrent threads is
conditional. For instance, in the Individual Check-In example from the previous
section, the passenger checking in might be a frequent-flyer member. In that
case, you need to award the passenger frequent flyer miles.
An activity diagram for the business use case Individual
Check-In in the business use-case model of Airport Check-Ins
An activity state may reference another activity diagram, that shows the
internal structure of the activity state. Stated another way, you can have
nested activity graphs. You can either show the subgraph inside of the activity
state or let the activity state refer to another diagram.
A nested activity graph shown within an activity state
To show the subgraph inside of the activity state is convenient if you want
to see all details of the workflow in one diagram. However, if there is any
level of complexity in the presented workflow, this can make the diagram
difficult to read.
Alternatively, put the subgraph in a separate diagram and
let the activity state refer to it
To simplify the workflow graph, you may instead choose to put the subgraph in
a separate diagram and let the activity state that the subgraph details refer to
that diagram.
An activity diagram may be partitioned into swimlanes using
solid vertical lines. Each swimlane represents a responsibility for part of the
overall workflow, carried by a part of the organization. Eventually, a swimlane
may be implemented by an business system or by a set of classes in the
business analysis model.
The relative ordering of swimlanes has no semantic significance. Each
activity state is assigned to one swimlane and transitions may cross lanes.
An activity diagram illustrates the workflow of a
business use-case that represents a generic sales process. In this example, the
swimlanes represent departments in the organization.
What comes first, the activity diagram or the textual description of the
workflow? This depends somewhat on how you are used to working, and whether you
think graphically or not. Some prefer to visually outline the structure in a
diagram first, and then develop the details in the text. Others would rather
start with a bulleted list of the activity states, agree on those, and then
define the structure using a diagram.
Another valid question is whether you really need both the textual document
and the diagram. The activity diagram technique does allow you to write brief
descriptions of each activity state, which should make the textual specification
of the workflow obsolete. Here you need to be sensitive to your audience and
what format they expect for the specification.
We present a sample activity diagram for the workflow of the business use
case Proposal Process as defined in Guidelines: Business
Use Case, to show what an activity diagram adds to the understanding of a
workflow. This example is taken from an organization that sells telecom network
solutions, individually configured for each customer.
An activity diagram for the business use case Proposal
Process
The activity state named "Initial opportunity work" consists of three
sub-steps that can be done in parallel. This is illustrated in a subgraph to
this activity state.
Sub-diagram to the activity state "Initial opportunity
work". Creating a sales plan is optional, which is indicated by a guard
condition on the incoming transition.
An activity state can represent a fairly large procedure (with substructure),
as well as something relatively small. If you're using activity diagrams to
define the structure of a workflow, do not attempt to explore several levels of
activity graphs down to their most atomic level. Doing so will most probably
make the diagram, or set of diagrams if you are using separate subgraphs, very
difficult to interpret. Aim to have one diagram that outlines the whole workflow
where a few of the activity states may have subgraphs.
|