| |
Use Case Diagram Example
Shows Use Case Abuse
Ambiguous Use Case Diagram
This use case diagram example of Special Handling shows how using actors leads to confusion. The root problems are:
1. When actors are used, the role that each actor plays for the use case is rarely named, much less defined. This is ambiguous.
2. In practice, actors represent a set of users. Rarely are the characteristics that make up the set of users documented unambiguously. The net result is that the diagrams look like they should say something meaningful - yet they often do not. Consider the following use case diagram example. It describes a Special Handling (SH) system whereby custom rules are entered that define how large customers wants their insurance claims to be handled. A customer defined rule might be:
- Notify Mary for claims in the Western territory and Bob for claims in the Eastern territory unless the dollar amount is greater than $250,000. If the amount is over $250,000 only notify Kim regardless of which territory it originated in.
Use Case Fundamental Concept Applied
Let's look at this use case diagram example from the perspective of the
three fundamental concepts
of the Building Requirements Consensus™ Methodology starting with use case.
- What does it mean that six different actors link to the View SH use case? Does the View SH use case behave differently or provide a different benefit of value depending on which actor initiates the use case?
- If the use case does provide a different benefit of value depending on which actor initiates it, the use case is malformed in the Building Requirements Consensus™ Methodology. Remember, all executions of a use case must either deliver the exact same benefit or fail to deliver the benefit.
- Think about it this way. If a telephone is answered in your office, does the telephone behave differently if the person answering it is the CEO or the latest new hire? No! The telephone has no knowledge whatsoever about who is answering it. It simply does what it is set up to do no matter who it is.
Role Fundamental Concept Applied
Now let's look at it from the actor/role perspective. Consider the actor named SH Worker. It links to eight different use cases.
- Remember that the UML definition of actor says "An actor has one role for each use case with which it communicates." So where are these eight roles on the diagram? We don't see them either.
- These roles are unnamed and undefined. This omission creates significant ambiguity.
- Do you think that the role each of the eight actors play when interacting with the View SH use case is the same or can they be different roles? Hint: in the Building Requirements Consensus™ they must all play the same role.
Explore roles here.
System Fundamental Concept Applied
Finally, let's look at it from the system perspective and revisit the View SH use case. The way this diagram is drawn implies that Special Handling is the only system boundary.
- Do you think that a Claims Handler belongs to the same business system (business unit or department) as an Underwriter?
- Does a Claim Handler or Underwriter belong to the same department as a Mainframe?
Of course not. Clearly there are multiple system boundaries that are not documented in this diagram. There are significant questions that should be asked every time a system boundary is crossed. It is all too easy to omit these questions when the system boundaries are not explicitly diagrammed. Out of sight, out of mind.
Defining system boundaries explicitly helps prevent installations that fail at the last minute as you were putting it into production because an interface between two systems was not defined correctly.
Ambiguity Reduced Using the
Building Requirements Consensus™ Methodology
This and other abusive use case diagram examples are prime evidence supporting those who say use cases are broken. The Building Requirements Consensus™ Methodology addresses each and every one of these concerns and gives us robust unambiguous use case documentation.See
UC Role Case Study
for an example of a use case diagram that follows the Building Requirements Consensus™ Methodology. It appears in Part 2 of the case study.
From Diagram Example to Use Case Concepts 101
From Diagram Example to Use Case Concepts 201
Return from Abusive Use Case Diagram Example to
Building Requirements Consensus™ Home
|
