Blog Archives

In my last post I gave an introduction to tokens and how they're used within UML Activity Diagrams.  I also disputed the accuracy of IBM's bording process.  Below is my solution to the fragment of the activity diagram that I believe is wrong; afterwards comes an explanation of how my version works.  I will then point out common pitfalls that business analysts fall into when drawing up Activity Diagrams.  I used a great little online tool called Gliffy to draw up these diagrams, which appears to be great for doing up a UML diagram when you don't have access to enterprise tools. 

What's Different?

Really the only difference betwen my solution and the one produced by IBM is one node.  However choosing this node makes all the difference.  Instead of waiting for all incoming tokens, as the join node does, the merge node (also a diamond symbol like a decision node) joins together two incoming edges with tokens.  However it only needs to receive one token before it emits its own token which as its name suggests, is great for merging concurrent flows.

The Merge Node

When I'm peer reviewing other business analyst's Activity Diagrams, the merge node is the one I see used the least.  I should be seeing it a lot more though.  The reason is that people don't often realise the following:

There may be some technical differences between the above, however in terms of what it means when you're modelling the business (which is what we're about) it ends up being the same.  Whenever you have two incoming edges to an action, that action must wait for both tokens to arrive before it can emit its own token.  Often people think that the action node somehow has powers of descrepancy to determine which token it should wait for.  Well unfortunately it doesn't.  This would become particularly important if you were using a BPMS tool or were attempting xtUML for Model Driven Architecture.

So my suggestion for modelers is to always have one edge coming into an action.  If you are going to have two edges entering an action check the logic of your diagram and make sure it aligns with the intent you're trying to communicate.

A merge node is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept one among several alternate flows.

OMG UML Superstructure Specification, v2.2, pg 387

UML Activity Diagrams are one of the core UML artefacts that a business analyst can use.  Understanding the basics is necessary to model a business process or workflow.  Even if a business analyst chooses another notation, a thorough understanding of Activity Diagrams is often a good prerequisite to understanding the nuances of the other notation.  For example BPMN uses a lot of the same concepts as activity diagrams but allows for a more diverse and sophisticated depiction of a process.

What is a Token?

Activity diagrams work by modelling the flow of control through an invisible object called a token.  Tokens aren’t something you depict when drawing an activity diagram, but having an understanding of how they work is useful to make sure you use the right type of notation for the real world process you’re illustrating.  Different nodes have different effects on the tokens.  The way different nodes treat tokens are described in detail in the UML Superstructure specification, however this is often ignored by people teaching Activity Diagrams to someone unfamiliar with them.

A node may begin execution when specified conditions on its input tokens are satisfied; the conditions depend on the kind of node. When a node begins execution, tokens are accepted from some or all of its input edges and a token is placed on the node. When a node completes execution, a token is removed from the node and tokens are offered to some or all of its output edge.

page 318, UML Superstructure Specification, v2.2

Activity Diagrams as Applications of Graph Theory and Logic

There is a reason that all undergraduate IT degrees teach discrete mathematics to their pupils.  Even when undertaking analysis and approaching IT from a business orientation there needs to be a basic understanding of both graphy theory and logic.  Logic needs to be understood so that a practitioner knows when a node is acting as an AND gate or an XOR gate.  Graph theory will teach someone what nodes and edges are and will help them interpret the UML specification when it refers to its symbols as such.

Even the Big Wigs Get it Wrong

The following activity diagram is produced in IBM’s introduction to UML Activity Diagrams article – Activity Diagrams: What They Are and How To Use Them.  It shows a fairly basic and well understood process – that of making a reservation and boarding some transport.  I’ll use the concept of tokens and refer to the UML specification to show how they have misinterpreted the specification.  What can be intuitively understood would be incorrectly programmed if interpreted literally as the process is modelled below.

Visualising the Tokens for Understanding

The activity diagram begins at the special Initial node, at the top of the diagram.  A control token is passed to the action, Verify reservation.  The task assesses the next control node, the decision node, to see if it can validly receive another token.  It can so a token is emitted from Verify reservation.  The decision node has two guard conditions: incorrect and correct.  Control tokens are offered to all outgoing edges, but the edges are only traversed if the guard condition holds true.

If the Verify reservation is evaluated to incorrect then one token is emitted to the incorrect branch.  The next node is the activity, Send to airport travel agency, the flow of control passes to the activity final node which immediately terminates the activity.

However if the action Verify reservation is evaluated to correct, then a control token is passed to the Get preferences action.  A token is consumed and passed to the special control node the fork node.  A fork node consumes incoming tokens and offers tokens to each of its outgoing edges.  This is how an activity diagram can model concurrent flows.  In our example a token is offered to both the Print boardingcard action and the decision node (baggage, no baggage). This is where this diagram has a logical error.  In the decision node either the baggage or no bagage edge will be taken depending on what is evaluated to true.  However immediately below is another type of control node.  The join node.  The join node waits for all incoming tokens and joins them before emitting one outgoing token.  So logically that is as far as this activity diagram will go.  It will wait for two incoming control tokens before it continues and because there is a decision node immediately above it, only one will arrive.

I will post my semantically correct version later on.  There are a lot more complexities that can be modelled using the more advanced control nodes in Activity Diagrams.  So next time you’re producing an Activity Diagram, try andvisualise your tokens and make sure that activity diagram doesn’t contain logical errors and correctly communicates the business logic you’ve worked so hard to understand so that your system is correct.