Generalization / Specialization Use Case Diagrams and Scenarios

Generalization / Specialization Use Case Diagrams and Scenarios

40422 Views
0 Comments
17 Likes
  Several years ago I was looking for examples using the generalization / specialization technique with use cases [1], [2]. They are not easier to find. And they are typically limited to a use case diagram like the two below. This article provides examples of both the diagrams and the scenarios [3] for a future gas station business.

Figure 1. Gas Station Business (As-Is). The original gas station business did not have car wash. The business added a car wash a couple of years later; the additional capability included a car wash service offered at the gas pump via an <<extend>> use case.

Figure 2. Gas Station Business (To-Be) using the Generalization (Validate Credit and Print Receipt) / Specialization (Purchase Fuel, Purchase Lottery Ticket) technique

  The use case diagrams above reflect a gas station business that currently sells [4] fuel at the pump (see Figure 1). However in this example, there recently has been change in government laws:
  • The state government has allowed lottery ticket sales via a debit card (off-line, PIN not required).
  • State issued restrictions concerning debit lottery ticket sales are:
    • Only a single lottery ticket can be purchased at a time.
    • The lottery numbers are selected only by a state lottery system not by the customer and are limited to the current week’s lottery.
    • The customer buying the lottery ticket must at least 18 years of age. Note: There is no age restriction for purchasing gasoline.

These changes provide an opportunity to sell lottery tickets at the fuel pump (see Figure 2).

Diagram for the To-Be

  The To-Be diagram (Figure 2) in our example uses the generalization / specialization technique for both actors and use cases. There are two primary actors: Customer and Adult Customer. The Adult Customer actor must be at least 18 years of age to comply with the new state law; this actor has an association with Purchase Lottery Ticket. The Customer actor has no age restriction and has an association with Purchase Fuel. But, Customer may not access Purchase Lottery Ticket due to the age restriction for buying a lottery ticket. If the Customer is at least 18 years of age, then the Customer can access Purchase Lottery Ticket as an Adult Customer. The Adult Customer actor can step into the role of the Customer actor to Purchase Fuel, but

not necessarily the reverse due to the age restriction for purchasing a lottery ticket; the diagram designates this relationship via a line with a hollow arrow between the Adult Customer and Customer (see Figure 2).

Note: There is no generalization / specialization in the As-Is diagram (Figure 1). The Customer actor covers all purchasers of gasoline regardless of age.

The same generalization / specialization technique is used for the use cases. The specialized behavior use cases are Purchase Fuel and Purchase Lottery Ticket. Both these use cases utilized the Validate and Print Receipt use case for standardizing generalized behavior at the beginning and end of the application. To emphasis the flow, see the high-level sequence flow below:

Below are details in the follow-on use case scenarios with alternates, exceptions, reference business rules and decision tables [6]:

  • Business Rule 1 – three grades (octane rating) of gasoline are offered: unleaded (87), regular (88-90), premium (91-94).
  • Business Rule 2 – three levels of vehicle washes are offered: - good (wash only), better (wash and wax), best (includes undercarriage).
  • Business Rule 14 – customers must be at least 18 years of age to purchase a lottery ticket.
  • Decision Tables
  • Table A - determines the price of the gasoline based on the grade of gasoline.

  •  Table B - determines the price of a car wash based on the level of wash.



Figure 3. Detail use case scenarios; back and forth flow shown by red arrows; the green arrow designates the extend interruption of base case

Note: I chose to document the use cases in a listing format. However, the scenarios could be written in as a graphic process flow (i.e., flowchart, UML activity mode with swim lanes, or Business Process Modeling and Notation (BPMN) choreography. Remember there is no UML standard for writing the scenarios.

P.S. on the Include Check with Credit Bureau or Bank

In general, I avoid the conjunctions “and / or” when defining use cases and their scenarios. But in this case, I used the conjunction “or” instead of splitting the <<Include>> into two use cases: Check with Credit Bureau and Check with Bank. The reason being that my purpose in writing this article was to provide an example of generalization / specialization use case scenarios; splitting the <<Include>> would have eliminated the justification for the generalization / specialization technique. My other choice was to use a credit card for both Purchasing Fuel and Purchasing Lottery Ticket, but I liked the business restrictions I listed with purchasing a lottery ticket by allowing only:

  • customers at least 18 years of age
  • debit card purchase
  • one lottery ticket at a time
  • lottery tickets generated by the State Lottery System

I envisioned that these restrictions may have been negotiated by the state legislatures due to habitual gambling concerns.


  Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master's Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association

for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).

Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via - www.baquickref.com.


References / Footnotes:

 

1. Advanced Use Case Modeling by Frank Armour and Granville Miler, 2001, Addison-Wesley.

2. Use Case Modeling by Kurt Bittner and Ian Spence, 2003, Addison-Wesley.

3. The Object Modeling Group (OMG) through their Unified Modeling Language (UML) has standardized the use case diagram, but not the scenarios.

4. When writing this article I assumed the gas station business was not in Oregon or New Jersey since they only allow an attendant to interface with the pump; no pump self-service.

5. Note the back and forth flow (red arrows) between the use cases.

6. Note that the business rules and decision tables are documented separately and referenced in the follow-on use case scenarios to allow independent changes (i.e. business rule changes without scenarios changes and visa versa).

Like this article:
  17 members liked this article
40422 Views
0 Comments
17 Likes

COMMENTS

Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC