Diagramming the Scenario

Some requirements analystsand some stakeholdersbelieve that it is more appropriate to use a diagram to explain the functionality of a business use case. This preference is a matter of personal choice, and it depends largely on whether your audience responds more favorably to either text or diagrammatic scenarios. We leave it to you to experiment and decide which method is right for you.

Several diagrams can be used for scenarios. The UML activity diagram seems to be a particularly popular choice. Figure 6.2 shows the airline check-in example in this form.

Figure 6.2.

An activity diagram showing the passenger checking in for a flight.

In Figure 6.2, note the "swim lanes" that divide the work between the participants. Swim lanes are optional, and they are both good and bad: good because they provide a clear explanation of who is doing what; bad because they tread the dangerous path of inviting readers to believe that they define the way the work must be implemented in the future. Be aware that diagrams like Figure 6.2 are used as explanations. Only after the systems architects and designers have done their work can the swim lanes be taken to mean a specification.

The activity diagram shows a certain amount of parallel processing. For example, there is no reason why the "Attach frequent-flyer number" and "Allocate seat" activities cannot be performed in parallel. The text scenario does not show this possibility. However, if you want to point out the parallel nature of these two activities, you could amend the scenario as follows:

The following two things can be done in any order:

Attach the frequent-flyer number to the reservation.

Allocate a seat.

The activity diagram also shows other control aspects. For example, the diamond at the bottom of the model in Figure 6.2 is called a merge. This symbol means that all processing must reach this point before proceeding. In the case of Figure 6.2, the whole process cannot end until both the bag tags and the boarding pass have been printed. Diamonds are also used to denote decisions as they were in flowcharts. We tend to leave them out where the conditions are obvious or can be shown by attaching guard conditions (the words in brackets at the exit of an activity). When using activity diagrams during requirements, simplicity is more useful than maximum precision.

The book you are reading makes no claims to be a treatise on UML modeling. If you look at the model and the text scenario side by side, however, you should get the idea of how you can use either models or text to represent scenarios. For more on UML, we refer you to the books mentioned in the margin, as well as the abundance of information available on the Web.

Ambler, Scott. The Elements of UML 2.0 Style. Cambridge University Press, 2005.

Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (third edition). Addison-Wesley, 2003.

Pilone, Dan, and Neil Pitman. UML 2.0 in a Nutshell. O'Reilly, 2005.