A Picture Isn’t Always Worth 1000 Words – Use Case Diagrams

In his next post in the series, Alex looks at the next step in creating a useful use case... 

 At this point in our development of a use case model we have:

•  Identified the actors
• Categorised the actors into primary and supporting
• Identified goals for the primary actors

The next stage is to represent the actor goals as use cases on a diagram. Although the actor goals may not map directly to individual use cases it is often a good place to start.

While the use case model contains all the actors, use cases and their relationships; use case diagrams are views into the model and graphically represents actors use cases and the connections between them.  For large systems, many use case diagrams will be needed to communicate the use case model.

In UML and SysML a use case is drawn as an ellipse and contains a name which represents the system functionality described by the use case.  Use cases are then placed on use case diagrams with the actors and the relationships between them added (usually represented as an association in most UML/SysML modelling tools).  In some cases you might wish to add a system boundary box around the use cases with the actors outside the box.

When identifying our primary and supporting actors in the model it was not possible to categorise them as either as there are many instances where an actor might be primary for one use case but supporting for another. As a convention most developers place primary actors on the left of the diagram and supporting actors on the right.

The simple nature of use case diagrams often leads people to believe that use case modelling is easy while nothing could be further from the truth.  A small system can be expressed with a small number of use cases involving two or three actors.  As you tackle larger systems, it will become obvious that this is not a menial or insignificant task.    

In essence use case diagrams can be used to represent or validate the system context but the true power of a use case lies in what sits behind the diagrams.

Do not be fooled into believing that you can just focus on bubbles and stick men while ignoring the detail that sits behind them. Use cases a means on analysing and communicating the detail in the textual requirements and cannot be used to replace them.