Process Models

Enterprises—hospitals, retailers, universities, etc.—are loaded with defined processes: protocols, workflows, life-cycles, assembly lines, etc.

Activities, Actions, and Control Flow

Processes can be modeled as UML activities.

·       An activity contains nodes and edges.

·       There are three types of nodes: actions, objects, and controls.

·       There are two types of edges: control flow and object flow.

An activity diagram depicts an activity:

·       The "build models" activity contains three action nodes and two control nodes: the initial node and the final node.

·       The "Build requirements model" is the start of the activity as indicated by the initial node.

·       The "Build design model is the final activity. An activity can have multiple final actions, but only one initial action.

Control Flows

A control flow edge connects a source node to a target node. Control flow edges model the flow of execution. When the source action is completed, execution of the target action begins.

The "build models" activity contains four control flow edges. The control flow edge connecting the source activity-- "build domain model"-- to the target activity-- "build design model". When the domain model is built, we can begin building the design model.

Edges can also have guards, these are Boolean conditions that must be true in order for execution to flow from the source action to the target action.

Decision and Merge Nodes

·       Decision and merge nodes are control nodes.

·       Control can only flow into an action node from one source and flow out to one target. However, a decision node can have two sources, while a merge node can have two targets.

·       The two control edges exiting a decision node must have complimentary guards.

For example:

We can model multi-way decisions by using multiple decision and merge nodes:

(If we allow activities to be the targets of multiple edges, then we don't need merge nodes.)

Object Flows

·       While control flows model the flow of control between actions, object flows model the flow of data between actions.

·       Data are represented by object nodes (these are rectangular).

·       An object flow connects a source action to its output object or an input object to its target action.

For example:

Fork and Join Nodes

·       Fork and join nodes are also control nodes.

·       A fork node models a split in the flow of control to multiple concurrent flows.

·       When a flow reaches a join node is blocks until all other flows reach the join.

For example:

Fork nodes can also be used to model sequential flows in which the order of execution is unimportant.

Activity Nodes

Activities can also contain (sub-) activity nodes:

This might suggest the Composite Design Pattern appears in the UML meta-model:

Swim Lanes

When activities are executed in parallel, they must be executed by different processors or actors. Swim lanes can be used to indicate which processors/actors execute which activities:

Links

·       Project Management System such as Project Control Panel help managers define work-breakdown structures for large projects.

·       Process and project management occurs frequently enough to be regarded as an analysis pattern: The Process Pattern.

·       Older, but more detailed, lecture notes can be found here: UML Activity Diagrams.

·       Process modeling exercises can be found here: Workflow Modeling Labs.