CREATING USE-CASE DESCRIPTIONS AND USE-CASE DIAGRAMS
Identify the Major Use Cases
1. Review the activity diagram.
2. Find the subject’s boundaries.
3. Identify the primary actors and their goals.
4. Identify and write the overviews of the major use cases for the above.
5. Carefully review the current use cases. Revise as needed.
Expand the Major Use Cases
6. Choose one of the use cases to expand.
7. Start filling in the details of the chosen use case.
8. Write the normal flow of events of the use case.
9. If the normal flow of events is too complex or long, decompose into subflows.
10. List the possible alternate or exceptional flows.
11. For each alternate or exceptional flow, list how the actor and/or system should react.
Confirm the Major Use Cases
12. Carefully review the current set of use cases. Revise as needed.
13. Start at the top again.
Create the Use-Case Diagram
1. Draw the subject boundary.
2. Place the use cases on the diagram.
3. Place the actors on the diagram.
4. Draw the associations.
Identifying the Major Use Cases
The first step is to review the activity diagram. This helps the analyst to get a complete overview of the underlying business process being modeled.
The second step is to identify the subject’s boundaries. This helps the analyst to identify the scope of the system.
The third step is to identify the primary actors and their goals. The primary actors involved with the system will come from a list of stakeholders and users. However, recall that an actor is a role that a stakeholder or user plays, not a specific user (e.g., doctor, not Dr. Jones). The goals represent the functionality that the system must provide the actor for the system to be a success. Identifying what the tasks are that each actor must perform can
facilitate this. For example, does the actor need to create, read, update, or delete any information currently in the system, are there any external changes of which an actor must inform the system, or is there any information that the system should give the actor?
Steps 2 and 3 are intertwined. As actors are identified and their goals are uncovered, the boundary of the system will change.
The fourth step is to identify and write the major use cases, with basic information about each, rather than jumping into one use case and describing it completely (i.e., only an overview use case). Recall from the previous description of the elements of a use case that overview use cases contain only the use case name, ID number, type, primary actor, importance level, and brief description. Creating only overview use cases at this time prevents
the users and analysts from forgetting key use cases and helps the users explain the overall set of business processes for which they are responsible. It also helps them understand how to describe the use cases and reduces the chance of overlap between use cases.
It is important at this point to understand and define acronyms and jargon so that the project team and others from outside the user group can clearly understand the use cases. Again, the activity diagram is a very useful beginning point for this step.
The fifth step is to carefully review the current set of use cases. It may be necessary to split some of them into multiple use cases or merge some of them into a single use case. Also, based on the current set, a new use case may be identified. You should remember that identifying use cases is an iterative process, with users often changing their minds about what a use case is and what it includes. It is very easy to get trapped in the details at this
point, so you need to remember that the goal at this step is to identify the major use cases and that you are creating only overview use cases. For example, in the doctors’ office example in Figure 5-10, we defined one use case as Make Appointment. This use case included the cases for both new patients and existing patients, as well as for when a patient changes or cancels an appointment. We could have defined each of these activities (makes an
appointment, changes an appointment, or cancels an appointment) as separate use cases, but this would have created a huge set of small use cases.
The trick is to select the right size so that you end up with three to nine use cases in each
system. If the project team discovers many more than eight use cases, this suggests that the
use cases are too small or that the system boundary is too big. If more than nine use cases
exist, the use cases should be grouped together into packages (i.e., logical groups of use cases)
to make the diagrams easier to read and keep the models at a reasonable level of complexity.
It is simple at that point to sort the use cases and group together these small use cases
into larger use cases that include several small ones or to change the system boundaries.
Expanding the Major Use Cases
The sixth step is to choose one of the major use cases to expand. Using the importance level of the use case can help do this. For example, the Make Appointment use case
It has an importance level of high. As such, it should be one of the earlier use cases to be
The seventh step is to start filling in the details on the use-case template. For example, list all of the identified stakeholders and their interests in the use case, the level of importance of the use case, a brief description of the use case, the trigger information for the use case, and the relationships in which the use case participates.
The eighth step is to fill in the steps of the normal flow of events required to describe each use case. The steps focus on what the business process does to complete the use case, as opposed to what actions the users or other external entities do. In general, the steps should be listed in the order in which they are performed, from first to last. Remember to write the steps in an SVDPI form whenever possible. In writing the use case, remember the
seven guidelines described earlier. The goal at this point is to describe how the chosen use case operates. One of the best ways to begin to understand how an actor works through a use case is to visualize performing the steps in the use case—that is, role-play. The techniques of visualizing how to interact with the system and of thinking about how other systems work (informal benchmarking) are important techniques that help analysts and users understand how systems work and how to write a use case. Both techniques (visualization and informal benchmarking) are common in practice. It is important to remember that at this point in the development of a use case, we are interested only in the typical successful execution of the use case. If we try to think of all of the possible combinations of activities that could go on, we will never get anything written down. At this point, we are looking
only for the three to seven major steps. As such, focus only on performing the typical process that the use case represents.
The ninth step is to ensure that the steps listed in the normal flow of events are not too complex or too long. Each step should be about the same size as the others. For example, if we were writing steps for preparing a meal, steps such as take fork out of drawer and put fork on table are much smaller than prepare cake using mix. If we end up with more than seven steps or steps that vary greatly in size, we should go back and review each step carefully and possibly rewrite the steps.
One good approach to produce the steps for a use case is to have the users visualize themselves actually performing the use case and to have them write down the steps as if they were writing a recipe for a cookbook. In most cases the users will be able to quickly define what they do in the as-is model. Defining the steps for to-be use cases may take a bit more coaching. In our experience, the descriptions of the steps change greatly as users work through a use case. Our advice is to use a blackboard or whiteboard (or paper with pencil) that can be easily erased to develop the list of steps, and then write the list on the use-case form. It should be written on the use-case form only after the set of steps is fairly well defined.
The tenth step focuses on identifying the alternate or exceptional flows. Alternate or exceptional flows are those flows of success that represent optional or exceptional behavior. They tend to occur infrequently or as a result of a normal flow failing. They should be labeled so that there is no doubt as to which normal flow of events it is related.
The eleventh step is simply to write the description of any alternate or exceptional flows. In other words, if an alternate or exceptional flow is to be executed, describe the response that the actor or system should produce. Like the normal flows and subflows, alternate or exceptional flows should be written in the SVDPI form whenever possible.
Confirming the Major Use Cases
The twelfth step is to carefully review the current set of use cases and to confirm that the use case is correct as written, which means reviewing the use case with the users to make sure each step is correct. The review should look for opportunities to simplify a use case by decomposing it into a set of smaller use cases, merging it with others, looking for common aspects in both the semantics and syntax of the use cases, and identifying new use cases.
This is also the time to look into adding the include, extend, or generalization relationships between use cases. The most powerful way to confirm a use case is to ask the user to roleplay, or execute the process using the written steps in the use case. The analyst will hand the user pieces of paper labeled as the major inputs to the use case and will have the user follow the written steps like a recipe to make sure that those steps really can produce the outputs
defined for the use case using its inputs.
The thirteenth and final step is to iterate over the entire set of steps again. Users will often change their minds about what is a use case and what it includes. It is very easy to get trapped in the details at this point, so remember that the goal is to just address the major use cases. Therefore, the analyst should continue to iterate over these steps until he or she and the users believe that a sufficient number of use cases has been documented to begin identifying candidate classes for the structural model (see Chapter 6). As candidate classes are identified, it is likely that additional use cases will be uncovered. Remember, object-oriented systems development is both iterative and incremental. As such, do not worry about identifying each and every possible use case at this point in the development of the system.
Creating a Use-Case Diagram
Basically, drawing the use-case diagram is very straightforward once use cases have been detailed. The actual use-case diagram encourages the use of information hiding. The only parts drawn on the use-case diagram are the system boundary, the use-cases themselves, the actors, and the various associations between these components. The major strength of the use-case diagram is that it provides the user with an overview of the detailed use cases.
However, remember that anytime a use case changes, it could impact the use case diagram. There are four major steps in drawing a use-case diagram. First, the use-case diagram starts with the subject boundary. This forms the border of the subject, separating use cases (i.e., the subject’s functionality) from actors (i.e., the roles of the external users).
Second, the use cases are drawn on the diagram. These are taken directly from the detailed use-case descriptions. Special use-case associations (include, extend, or generalization) are also added to the model at this point. Be careful in laying out the diagram. There is no formal order to the use cases, so they can be placed in whatever fashion needed to make the diagram easy to read and to minimize the number of lines that cross. It often is necessary to redraw the diagram several times with use cases in different places to make the diagram easy to read. Also, for understandability purposes, there should be no more than three to nine use cases on the model so the diagram is as simple as possible. These includes those use cases that have been factored out and now are associated with another use case through the include, extend, or generalization relationships.
Third, the actors are placed on the diagram. The actors are taken directly from the primary actor element on the detailed use-case description. Like use-case placement, to minimize the number of lines that will cross on the diagram, the actors should be placed near the use cases with which they are associated.
The fourth and last step is to draw lines connecting the actors to the use cases with which they interact.No order is implied by the diagram, and the items added along the way do not have to be placed in a particular order; therefore, it may help to rearrange the symbols a bit to minimize the number of lines that cross, making the diagram less confusing