There are a few tools or instruments—also principles and patterns—that occasionally find me thinking: «Why only few people use this?». This is the case of the old GoF design patterns for object-oriented applications, and the truly effective Use Case models. This time I will disclose the points why I think that Use Case Modeling (UCM) is one of the most underestimate tools in software development. It’s a shame because, by more than 15 years of practice, I think it is one of the best tools. UCM is a way to «Combat the abstractions» pattern, when definitions and concreteness are inescapable requirements.

On the less terrible situations, Use Case Modeling is treated badly, discouraging any good intention to continue its practice. I made the emphasis that I will discuss the text form of Use Cases (UC) not the visual modeling UC using UML. In this article I only treat the general grounds of the UCM. In other entries, I will discuss all parts, and how the UC could be used for every aspect when you need a concrete visualization—step by step—of actions and goals to be achieved in any procedure.

The born and development of the UC date from the mid 1980 by I. Jacobson at Object Systems (later acquired by Ericksson). In the mid 1990, and after, one of the main sponsors of UC was A. Cockburn. His book on the subject Writing Effective Use Cases haven’t be surpass. Surely, if you are interested on the matter, read this book…twice, and practice whenever you find the occasion.

For many practitioners, the UC is the non-object oriented cousin of all object oriented projects, myself included. Thus, I’m not writing about a new instrument for requirements gathering, but a strong tool with some decades of history. My version of UC is a more concise version of the Cockburn «fully-dressed» version, minimizing the metadata parts mainly, and avoiding additional adornments. By experience, in the near future, you could decide what is really important to you or your organization, and what is only extra feats that add little value for UC template. After all, a UC is an instrument to display concrete scenarios of use. The steps, alternatives and exceptions are what really matter. The other parts are mere complimentary to maximize understanding and communication.

What is a Use Case? It’s a textual genre. A kind of essay or document type, with clearly defined parts: metadata preface, main scenario, alternatives and exceptional scenarios. As a programmer, I’m more interested in what it is called a System UC, not its counterpart Business UC. In the former, one of both of the participants, are software pieces. In the business version, the modeling is about human interactions and procedures under a business group, a department or a whole organization.

The main goal of the system UC is to gather the interactions between a role (typically a human, but could be a software component or subsystem) and a system (a machine, an application, or another component). By my liberal arts and literature backgrounds, I felt that UC fulfill my thirst of drama: the extensive display of interactions between a user, trying to accomplish a goal, and a system supposed to fulfill it. But unless a normal play, in the UC there is always a happy path, and the actors will ever decide when running the scene, what route they will follow. The UC must show all the tension, the bifurcations and diversity of routes, that a specific business or organization-role have to surpass to obtain what the business (the ultimate commander) wants.

Evidently, it’s not difficult to distinguish when a piece of software is coded without actual scenarios in mind. The opposites to «use case-driven» applications are the «feature driven» applications. Those are the applications constructed by a list of features,  enumerating all the capabilities of a system, without too much of a context. Those applications have an unnumbered amount of entry points, deviations, and alternatives, making difficult to catch real goals, when there is one. Have you ever been in the typical digital version of a daily newspaper? Those web versions are a populated display of links to the news, and one or two disparate top bars with more links for their sections and categories. Many of them are really difficult to follow and understand. On the other extreme side, a wizard (a good one), always goes to the point…next…next…finish. The user has no alternatives, just follow the main path to the end. And this is how a wizard is supposed to work, no? In the middle, are many good standard applications with clear goals and paths. The clever the applications is, the easy is for anybody, with a comprehensive understanding of computer use, to catch what to do, and what patterns should be pursue, to achieve any goal. Check the case of many well-established word processor applications. Goal: write a document. How I write letters in bold, do upper case, use italics, format paragraphs, etc.? No matter how new is the application for you, it’s probably that you can manage over the cases without much further complications.

But how do we start? How can we write a UC as the foundation of software construction? The road map for the UC model begin with an outline of the roles, the goals and the reasons. This outline is what I call an «Actor-Goal-Reason» (AGR) list. Anyone with a contact with Agile methodologies knows the common template of a User Stories in the format of: «As a [role], I want [something/goal], so that [benefit/reason]». For many developers that’s all they need to start with requirements. The inner true story is that this is only the beginning. You can’t develop a concrete software piece for a client with such phrases. But you can start digging into client desires with the AGR list. The user stories however give us an estimate of the kind of work to be done. It puts the ball in the park. The real work starts when you begin to ask about specifications of the «something» or «goal», and the further «reasons» or «benefits» the end-user express as foundation to them. After all, what is a goal or a reason? How concrete or shallow they should be expressed? Are there overlaps that should be cleared, separated or merged? A very simple way to measure the concreteness of the goals is to pay attention of the execution of the main scenario (or any alternative scenario). Any scenario that could be represented as a play, where the actor performs actions in real-time, is a user-level UC. A summary of those actions or a more detailed version of components (of the future system) actions are as we know summary or sub-functions UCs. These UC are the most important, and the foundation to software construction, testing, validation, and data specifications, at least.

The AGR list must focus in the user-level scenarios at first, using the other two types as executive summaries for managers, or more detailed versions for programmers when coding components and functions.

After a good user-level AGR list, with comprehensive coverage of all the necessities, I focus—before start  coding the first scenario realization—with the called «happy path» or normal path, main scenario. It is the list of steps the end user should follow, and the responses the system should brings, without exceptions or alternatives: the goal is achieved. Although for many AGR list items no other part of the UC is realized, at least you should write the main scenario path.

Let’s see a UC example (details are omitted):

Use case MULA01: Deliver Dosage

---

Preface:

Context of use: A nurse delivers dosage prescribed to an inmate.
Scope: MULA application
Level: user-goal
Primary Actor: Nurse, Inmate
Stakeholders and Interests:
* Nurse: deliver the correct dosage to inmate
* Inmate: receive the correct dosage for every medicine
* …
Precondition: Nurse is identified and authenticated. Dosages are correctly organized.
Minimal Guarantee: All dosages are delivered or returned.
Success Guarantee: The dosage is delivered to the inmate. All remaining dosage is returned.

Main Success Scenario:

1. Inmate comes to Nurse to get his current dosages.
2. Nurse request MULA the prescription of an inmate for the current day, providing his keyword.
3. MULA shows the prescription requested.
4. Nurse selects a prescribed dosage from the prescription and delivers to the inmate.
5. Nurse registers the dosage as delivered in MULA.
6. Inmate signs with his signature in MULA the receipt of the dosage.
Repeat 4-5 until prescription is completed.
7. Inmate gets away with his current dosages.

Alternatives/Exceptions (numbers are of the steps in main scenario): 

*a. Inmate is not available:

1…

1a. MULA get the prescriptions of more than one inmate (possible issue because the actual use of the name of the inmate as a keyword):

1.…

2a. MULA couldn’t find any prescription for the inmate:

1…

2b. MULA couldn’t find the inmate based on keyword provided:
…
3-4a. Inmate refrain the dosage:
…

Technology & Data Variations List: 

Step 2. The actual keyword is the inmate name, but in the future it is possible that an ID number could be used or any other identification available.

---

The Alternatives and Exceptions scenarios are very similar to the Main scenario, but with a first conditional phrase specifying the alternative or the exceptional case: «Claim not found:», «SSN bad content:», etc. Another important aspect is the Technology and Data Variations list. Most actions result or involve some data or other kind of physical objects. How the users must enter their IDs? What is the definition of an Inmate or a Dosage? In each step those objects must be named with controlled name, defined in a Glossary and in Data Variation list after the scenarios displayed in the UC. This list is the real foundation of an entity in a relational database, a class in an object oriented application, or simply a standard data type over your organization. The more detailed the properties are, the more information you have to start coding. The brainstorming exercise to gather this specifications, properties, alternatives, synonyms, etc. is the perfect field for discoveries and define the real subjects you are working with.Notice the terse writing of the steps. The formula is: <Object|System>.

It is very important to control the vocabulary to be used to name the Actors, the System, and—most important—the Actions. In the UC preface there are entries for the two first: Primary actors list, and Scope or the System under consideration (SuC). In some UCs the Stakeholders list is useful data to oversee who needs to be informed or who has an implication with the process or the results of the UC. I’m inclined to use a very limited action verbs. I use verbs related to data manipulation: select or retrieve, create or insert, destroy or delete, change or update. And verb referring some data manipulation or validation: validate, evaluate, archive, split, merge, encrypt. A Glossary should define this verbs for a common understanding. A Business Rules document could be cross-referred to define special treatment over data, when using those verbs, and to show the application of standard formulas (encryption algorithms, validations rules, etc.).

For now, this is sufficient. In other future posts, I will go more deeply in the main parts, and show some example of sub-functions UCs. Those type of UC have been very important to represent in verbal form the algorithms that a concrete procedure or function must be executed at the components level.