Use Case Example:
Yearlong Case Study Shows
Role Solves Problems
that Actor Cannot - Part 2 of 3
TAP Use Case Example Redo with Building Requirements Consensus™ Methodology
What caused TAP to head down the path of decline in the first place in this use case example? We submit that the way the analysts thought about the problem led them to write faulty use cases. That, in turn, forced the developers to build a fragile system that could not handle change easily. Instead of continuing the slide into the pit of confusion by simply doing what the Change Request Form asked for, we decided to model what TAP would have looked like if the analyst had used the Building Requirements Consensus™ Methodology.
This use case example diagram is very different from the first one. There are three different systems documented: The World system that Kim and you live in, Human Resources (HR) system and the TAP system. It is common for people to think that they are working on a single system. However, in our careers, we have never worked on a single standalone system. Everything has been a system of systems. When you do not specifically document every relevant system involved during UML modeling, you will miss requirements. There are questions that should be asked every time you cross a system boundary. If you do not consciously know you are crossing a boundary you will not usually think to ask those questions! Therefore, in Building Requirements Consensus™ Methodology we document every pertinent system boundary explicitly.
The Term Role
Note that the Building Requirements Consensus™ Methodology states that there is a one-to-one mapping from a use case to a role. This variation from industry standard use case documentation practice is fully supported by the UML specification which states that
an actor plays a different role with every use case with which it interacts.
The industry standard use case practice allowing a one-to-many relationship between actors and use cases leads to serious ambiguity as evidenced by this case study.Use case roles are described in class notation and are intentionally on the system boundary in this diagram. We define role names by inverting the use case name and adding “er” or “or” as appropriate. Sometimes we abbreviate to make the diagram more readable like the Trans. Disqualifier Role for Transaction Disqualifier Role. For a common real-life example, consider the microwave in your kitchen. Typically, when you press the 1 button it will cook on high for one minute. The microwave does not know or care if anything is in it. Likewise, it does not care who or what pushes the 1 button. It behaves the same if you push it or if someone else pushes. It even behaves the same if a broom falls and hit the 1 button just right. In other words, you or the broom handle can play the “1 Button Pusher” role. Just about anyone or anything else can play the role also. What happens in practice is that instead of use case roles, use cases are documented with actors that are either job titles or more or less well-defined sets of people. Job titles were used throughout the TAP use case example – even though they were improperly called roles. Point of view matters! Roles are not defined by whomever or whatever plays them. Let’s test this out with a few examples.
• Who defines what playing the role Taxpayer for the Pay Tax use case within the US Tax system means? Do you? We don’t get to either!
• Who defines what playing the role Vehicle Driver for the Drive Vehicle use case on US roadways means? Do you? Or do legislators, the police and the courts?
• Who defines what playing the role Employee for the Employ Person use case at your place of employment means?
We trust you get the point by now. Roles are defined in relation to specific functionality, i.e., use cases, within a given system. For example, while legislators, the police and the courts define what driver means, in the US we drive on the right side of the road and in United Kingdom and Australia they drive on the left side of the road. The system also matters. While this case study emphasizes role, it is intertwined with the concept of system. System and role are two of the
three fundamental concepts of the Building Requirements Consensus™ Methodology.
There is a price to be paid in using roles improperly with use cases. Let’s see how this plays out.
1st Change in Production Using Roles
If TAP were built using this description, the changes that happened as a result of feedback after the initial rollout can be implemented easily and without any negative side effects. We simply create a mapping from the Field Auditor to the Multiple Office Worker Role and the Something Doer Role. Field Auditors get the new functionality, two blue pluses, and there are no unexpected side effects.
In other words, the mappings from HR’s job titles to TAP’s roles are visual security requirements! TAP security simply needs to handle the mappings. We could, and I admit this is getting a bit radical, abstract out a security SOA service to do the mappings that is reused by new applications.After we completed this use case example diagram, the very first person we showed it to controlled the security for people using TAP. He said “I agree with everything you’ve said so far. However, this will not solve the business problem.” “What do you mean?” we asked in surprise. “After all, this diagram addresses all the issues described in the Change Request Form, doesn't it?”
An Unexpected Discovery!
“The problem isn’t that all Field Auditors need this functionality,” he said, “it’s that some individuals need this functionality.” Immediately we redrew the diagram to look like the following one: [You get extra credit if you figure it out before looking ahead! Here’s a clue: look at how the word role is used in the Change Request Form and in the diagram above.]
After looking at the redrawn use case example diagram, the TAP security manager snapped his fingers and said “I got it!” It clicked for him that even when the requirement changes from all Field Auditors to a set of individuals, represented by Kim, the Building Requirements Consensus™ Methodology handles it easily without code changes.Applying the Building Requirements Consensus™ Methodology uncovered this new disconnect early in this third change to production software – before this round of coding started. It cannot be emphasized enough that no new information was added to this use case example. The facts were present from the very beginning of the case study. However, the right connections were not made because of faulty analysis caused by using actors instead of roles.
From Use Case Example - Part 2 of 3 to Use Case Example - Part 1 of 3
From Case Study - Part 2 of 3 to Case Study - Part 3 of 3
From Case Study Part 2 of 3 to Use Case Concepts 201
|
