Requirements Modelling and Specification for Service Oriented Architecture

4.3. UML Activity Diagrams

UML provides only one notation explicitly for business process modelling: the activity diagram. Activity diagrams are said to be a special case of state charts, which implies that they must describe the state of some thing - or object. However, the way they are used, as Martin and Odell, (1998) point out, makes them look dangerously like data flow diagrams, albeit with some characteristics of flow charts added. Their origins were in the Ptech method and Martin Odell, event schemata. The states are usually 'process states'. Figure 4-1 shows an activity diagram in the domain of order processing. You will see that it is entirely unclear which object(s) the process states are states of - unless order processing is itself an object of some sort. We can improve the situation somewhat by adding swimlanes, as we have done in this figure.

In the figure, process states are rounded rectangles and arrows represent, possibly conditional, threads of control flow. The diamonds are decision branches, as in a flowchart. The thick horizontal bars represent forks and joins of control. It is distinctly better to annotate these with pre- and post-conditions (guards), as we have done with the 'order prepared' fork. I have shown two swimlanes with grey outlines and names.

The problem is that, without swimlanes, the processes are entirely 'disembodied' and the notation is not object-oriented at all. By 'disembodied' I mean that the processes are not encapsulated within any ...