The results of a survey I ran recently indicated that most people are using the UML (Unified Modeling Language) for the early lifecycle activities such as explaining business needs, requirements elicitation, and analysis and design.

See the article “The UML Survey Results Are In” at http://bit.ly/cendNd for the results. Here’s one of the charts from the survey:

Many benefits result from using modeling in each of these activities. However, there is one common thread that runs through all of them — communication. Communicating clearly what the business wants, what the requirements are, the system analysis, the design of the software, and so forth are critical for project success.

[login]Sometimes, the UML’s own completeness can be its greatest enemy, causing confusion and the perception of complexity. This only hinders its use, and when used, obfuscates its ability to communicate clearly. (See the negative impact of confusing notation in my previous article “Don’t Rewrite the UML” at http://www.devx.com/architect/Article/44828.) Here we will discuss two elements of the activity diagram that have similar, but definitely distinct semantics.

Activity diagrams are often described as fancy flowcharts. Indeed their primary use is the depiction of flows — business flows, control flows, algorithmic flows, and so forth. They do this very well. Activity diagrams provide a number of ways to depict how flows split and merge. The elements used to depict these splits and merges need to be selected and used carefully, as they have distinctive semantics. Let us look at two of these: the merge and the join.

A merge node takes two or more input flows and directs all of these inputs to one outgoing flow. Whenever any of the incoming flows reach a merge node (see Figure 1), that input flow is immediately directed to the output flow, like tributaries that flow into a river unimpeded. In this example, as soon as a rider or luggage arrives at the loading area it is loaded into the vehicle.

Figure 1: Merge Node.

A join node is similar to a merge node, with one critical difference. Incoming flows do not automatically continue through to the output flow. Using a join node, all the incoming flows must be “at the join”, before the outbound flow begins. (If you want to learn the flow semantics of activity diagrams in detail, I recommend Conrad Bock’s five-part series “UML 2 Activity and Action Models” in the Journal of Object Technology, 2003.)

For example, in Figure 2, when the hydraulics are pressurized AND when the power is initialized AND when the operator key is turned to the enable position, then operations can begin If any of these three activities are not yet complete, the flow does not continue to Begin Operations. As soon as ALL the precursor activities on the incoming flows are complete, the output flow commences.

Figure 2: Join Node.

Modelers who are unaware of this distinction often use join nodes when they really should be using a merge node. Another team member reading the modeler’s diagram may interpret the modeler’s intent very differently (i.e. properly per the UML spec), which will eventually lead to defects and/or a system that does not meet the needs of the stakeholders.