1
Defining the Use Case Approach
One of the first tasks in a project is to set the context and the scope of the proposed application. You need to answer questions such as the following:
What functionality do we need to include and exclude? How does this system relate to other systems in our architecture? Who will use the system? Who or what does the system depend on? What products and/or results does the system provide? Why do the users/other systems need the specific set of features that this system provides?
Then think of the system in terms of encapsulation, which asserts that to use an object, you need know only its purpose and its interfaces, not its internal implementation. As long as the purpose and the interfaces of the system remain unchanged, the internal functionality of the object or system may be replaced or enhanced without affecting the entities that access the functionality. So, the priority in defining a system is to define its purpose and the required interfaces. The purpose is the target of the project
Use Case Diagram (By Sumit Joshi)
Page 1
justification. The interfaces are the channels of communication between the actors outside the system and the features of the system itself, the use cases. Working inward from these fundamental requirements, each feature provides the context for all subsequent modeling of the system's internal behavior. The Use Case diagram provides the means to model the system in precisely this manner. The diagram consists of six very simple graphics that represent actors and use cases, and the different types of relationships between them, namely associations, include and extend relationships, and generalization. The goal of the diagram is to provide an external view of the relationship between the system and the outside world. It is a very flat diagram, providing only a surface-level, or black-box, view of the system. In a very real sense, the Use Case diagram is an encapsulated view of a system.
For example, a system-level Use Case diagram for an ATM application would correspond roughly to the main screen of an ATM, the menu options available immediately after passing the security interface. The ATM offers the user a set of choices such as withdraw, deposit, inquire on balance, and transfer funds. Each option would be represented by a separate use case. The customer (an actor outside the system) is associated with each of the use cases (within the system) that he could use. One major strength of the Use Case diagram is that it frames the issues that affect the development of the subject, be it a system, a subsystem, or a single component. Ensuring the successful development of the subject requires a test plan. Examination of the use case narratives can identify use case scenarios. A use case scenario is a description of a single path of choices in the execution of a use case, and it can form the basis for a test plan. Together, these three elements-the Use Case diagram, the narrative/description, and scenarios-are the artifacts of the use case approach to modeling a system.
Use Case Diagram (By Sumit Joshi) Page 2
2
Modeling Using the Use Case Approach
For tracking all of the modeling efforts in an enterprise, UML provides the concept of packages, containers that are much like directories or folders. Packages store artifacts of the modeling process such as Use Case diagrams, Class diagrams, and so forth. Packages may be decomposed into subpackages to form a hierarchy. When modeling systems, a system is contained in a top-level subsystem package. Subordinate levels of the system are contained in subsystem packages.
When modeling use cases, the standard stereotype for the topmost subsystem package is $useCaseSystem$. Member packages within the $useCaseSystem$ are stereotyped as $useCasePackage$. Figure 1-3 models an example from the theater case study in which the enterprise consists of a number of subsystems, including, but not limited to, Marketing, Sales, Contract Administration, and Scheduling.
Use Case Diagram (By Sumit Joshi)
Page 3
Figure 1-3: Use case model illustrated using a system hierarchy of packages. In addition, UML defines a package stereotype called $useCaseModel$. The distinction between this and the $useCaseSystem$ stereotype is a bit foggy (even UML says that they are synonymous
Use Case Diagram (By Sumit Joshi)
Page 4
3
Modeling the Use Case Diagram
Six modeling elements make up the Use Case diagram: actors, use cases, associations, include and extend relationships, and generalization. These elements are illustrated in Figure 12-4.
Figure 12-4: Use Case diagram elements.
Actor: A role played by a person, system, device, or even an enterprise, that has a stake in the successful operation of the system.
Use Case Diagram (By Sumit Joshi)
Page 5
Use case: Identifies a key behavior of the system. Without this behavior, the system will not fulfill the actor's requirements. Each use case expresses a goal that the system must achieve and/or a result that it must produce. Association: Identifies an interaction between actors and use cases. Each association becomes a dialog that should be explained in a use case narrative. Each narrative in turn provides a set of scenarios that can help in the development of test cases when evaluating the analysis, design, and implementation artifacts of the use case and the association. Include relationship: Identifies a reusable use case that is unconditionally incorporated into the execution of another use case. Responsibility for the decision about when and why to use the included use case lies with the calling use case. Extend relationship: Identifies a reusable use case that conditionally interrupts the execution of another use case to augment its functionality. The responsibility for deciding when the extending use case should be used lies with the extending use case. Generalization: Identifies an inheritance relationship between actors or between use cases.
The construction of a Use Case diagram employs the following steps: 1. Define the context of the system: 1.1 Identify the actors and their responsibilities. 1.2 Identify the use cases, the behaviors of the system, in terms of specific goals and/or results that must be produced. 2. Evaluate the actors and use cases to find opportunities for refinement, such as splitting or merging definitions. 3. Evaluate the use cases to find include type relationships. 4. Evaluate the use cases to find extend type relationships.
Use Case Diagram (By Sumit Joshi)
Page 6
5. Evaluate the actors and use cases for generalization opportunities (shared properties).
3.1 Modeling actors
In UML, the term actor refers to a type of user. Users, in the classic sense, are people who use the system. But users may also be other systems, devices, or even businesses that trade information. In Use Case diagrams, people, systems, devices, and even enterprises are all referred to as actors. The icons to model them may vary, but the concept remains the same. Figure 12-5 models the most common icons for actors. People are typically represented using stick figures. Other types of actors are normally represented with a rectangle stereotyped as an actor and named for the type of actor.
Figure 12-5: UML suggested icons for actors. Any icon may be used to replace these. Figure 12-6 offers some alternatives. A company logo might represent an enterprise. A cartoon image might represent a device. A graphic may be used to represent a system. Often, using alternative icons in a
Use Case Diagram (By Sumit Joshi)
Page 7
modeling tool is as simple as importing the graphics to a specific directory.
Figure 12-6: Alternative actor icon examples. Actors in a low-level use case may even be elements of the physical system, such as a class or a component. An actor is a role that an entity, external to the system, plays in relation to the system, plays in relation to the system. An actor is not necessarily a specific person or system. For example, a person may act in the role of a venue manager scheduling a new event. Later that day the same person might work on setting up the pricing for a series of performances. The same person can play two different roles, and therefore can function as two different actors when interacting with the system. Likewise, many people can function in the same role. For example, many people function as agents for the theater, all performing the same set of duties and having the same relationship with the theater's system. How do you identify actors? Listen to descriptions of the system. Listen for the ways in which people interact with the system. Ask why they are using the system in that manner. The answer to the why question often describes a duty they are performing that supports a function or the creation of some result. When multiple people perform the same function, try to name the role that they all play while performing the particular function.
Use Case Diagram (By Sumit Joshi)
Page 8
Initially actors are modeled as communicating with the system behaviors, the use cases. As the project progresses, use cases are realized or implemented by classes and later components. As the project progresses, actors also evolve. Instead of representing roles that people perform, they transform into the user interfaces that people playing these roles use to interact with the system. For example, in the system-level Use Case diagram, a Customer actor buying seats to a performance at the theater interacts with the PlaceOrder use case. In the designlevel Use Case diagram, the actor becomes two elements: the role of customer, and a user interface used by a customer. The use case becomes one or more objects that manage the behavior of the application to interact with the user interface and the rest of the system.
For example, in Figure 12-7, the VenueManager actor is responsible for scheduling. However, interviews with our clients reveal that only certain venue managers have the authority to reschedule performances and events. Rescheduling can influence customer relations, and may involve the decision whether or not to offer refunds. The two roles have a lot of similarity, and few differences. So, a second actor, ExecutiveVenueManager, is defined to describe the higher level of authority. An executive venue manager has (inherits) all of the responsibilities of a regular venue manager, plus a few unique to the executive role.
Figure 12-7: Using generalization to refine the definitions of actors. Generalization may be used for more than just a single specialization, as in the venue manager example. For example, in
Use Case Diagram (By Sumit Joshi) Page 9
the original system description a customer is defined as someone who is interested in purchasing tickets for performances at the theater. The definition of a customer includes people who have already purchased and those who simply want to browse but don't yet know if there is anything they want to buy. While working on the purchasing rules, we discover that some customers have access to special pricing that other customers do not, and that some customers are extended a line of credit, while others are not. The rules also draw a distinction between customers who are individuals and customers who are companies (corporate customers). Figure 12-8 models a generalization structure for customers. At the top is a basic definition of the customer actor. Below that, and attached by generalization relationships, are the specializations of the customer actor (role).
Figure 12-8: Using generalization to refine the definitions of customers.
3.2 Modeling use cases
A use case defines a behavioral feature of a system (or enterprise, subsystem, and so on). Without these features, the system cannot be used successfully. Each use case is named using a verb phrase that expresses a goal the system must accomplish. For example, use cases for the theater system
Use Case Diagram (By Sumit Joshi) Page 10
include Create Agent Contract, Reschedule Show, and Schedule Event. Although each use case implies a supporting process, the focus is on the goal, not the process. Figure 12-9 illustrates notations for use cases. The name may appear inside or outside of the ellipse.
Figure 12-9: Use case notation alternatives. One very common question about use cases is, "What requirements belong on the Use Case diagram and what requirements should be explained elsewhere?" The simplest answer I've found is to model only the behavioral features of the system that can be seen by an actor. For example, most systems must save data to a database, but the actors can't actually see this happening. The most they typically see is a message indicating that the system did, or did not, save their data. In this situation, the use case-level requirement is a message indicating the success or failure of the save function, not a description of the save process. The implementers can use the success or failure message as a requirement that defines the type of information that needs to be produced by the process used for saving the data. Use cases may also be viewed much like the services provided by classes or states. That is, services may be provided or required. A use case may provide or offer a service to an actor. An offered service is triggered by the user and implemented by the use case. For example, a use case could query the scheduled performances at the theater, or complete a ticket purchase. In an offered service the actor is making a request of the system. The system is responsible for fulfilling the request by asking for input, enforcing integrity rules, and managing the information.
Use Case Diagram (By Sumit Joshi)
Page 11
A use case may also require a service from the actor. For example, a use case might support entering mailing or contact information, or entering contract details. In this type of use case, the system depends on the actor to provide all of the information. It functions a bit like a getSomeInfo() call from the system to the actor. Both types of use cases may be implemented in the form of a dialogue between the actor and the system. Finally, use cases often reflect a business entity's need to manage resources. Managing resources includes acquiring, using, and disposing of those resources. The business often reports on the status and use of the resource throughout the life of the resource. These tasks have been summed up in a humorous acronym CRUD, for Create, Read, Update, and Delete. CRUD can be a checklist to remind you of the tasks to consider when brainstorming use cases.
3.3 Modeling associations
An association is a relationship between an actor and a use case. It is an instance of the same Association metaclass used to model relationships between classes on a Class diagram. The relationship is represented by a line between an actor and a use case. The association represents the fact that the actor communicates with the use case. In fact, in earlier versions of the UML specification, the line was called a Communicates With relationship. This is the only relationship that exists between an actor and a use case. Figures 12-12 and 12-13 model associations between the customer actor, the agent actor, and the use cases with which they each interact.
Use Case Diagram (By Sumit Joshi)
Page 12
Figure 12-12: Modeling associations between agents and use cases.
Figure 12-13: Modeling associations between customers and use cases.
Use case associations may also be adorned with multiplicity. Despite the many times I have seen multiplicity used in Use Case diagrams, I have never seen a good explanation for why to use it or what it adds to the model.
Use Case Diagram (By Sumit Joshi)
Page 13
3.4 Modeling use case relationships
Use cases define discrete behaviors. It is possible for a system to use the same behavior under a variety of circumstances and as part of many larger, more comprehensive behaviors. In other words, behaviors can be reused; and we need some notation to show that use cases can be reused. UML defines two standard stereotypes to represent two common use case relationships: include and extend. 3.4.1 The include relationship While researching systems it is common to find a behavior that can be performed under many different circumstances. In code, we tend to make reusable components such as class libraries, utility classes, subroutines, and functions that we can simply reference or call from within other code. UML supports the same practice when identifying common features in the use case approach. The include relationship is analogous to a call between objects. One use case requires some type of behavior. That behavior is already fully defined in another use case. Within the logic of the executing use case, there is a call to the previously defined use case. The distinguishing characteristic of the include relationship is that the decision to incorporate the second use case is in the calling use case. The called use case is unaware of the calling use case and has no participation in the choice to execute. . To use the include relationship, the use cases must conform to two constraints:
The calling use case may only depend on the result from the called use case. It can have no knowledge of the internal structure of the use case.
Use Case Diagram (By Sumit Joshi)
Page 14
The calling use case must always require the execution of the called use case. The use of the called use case is unconditional.
Figure 12-14 models two include relationships:
Figure 12-14: include notation for the Use Case diagram.
Between PlaceOrder and SelectPerformance Between PlaceOrder and SelectSeats
Figure 12-14 shows how the include relationship is modeled as a dashed open arrow pointing from the calling use case to the called use case- from PlaceOrder to SelectPerformance, for example, where PlaceOrder calls the SelectPerformance use case. The direction of the arrow helps to reinforce visually that the call is initiated by the use case at the base of the arrow.
Use Case Diagram (By Sumit Joshi)
Page 15
This example tells us that when a customer interacts with the PlaceOrder use case, he will always be asked to select a performance and to select the seats at that performance that he wants to order. The diagram does not tell us when, in the execution of use case, the calls will be made, or even the order of the calls. For those details we need a use case narrative. 3.4.2 The extend relationship The extend relationship says that one use case might augment the behavior of another use case. The extension use case provides a discrete behavior that might need to insert itself into the base use case. The arrow is drawn from the extension to the executing use case. Drawing the arrow with the base at the extension use case indicates that the extension, not the executing use case, decides whether to impose itself on the executing use case. The executing use case is unaware of the extension. This might sound strange at first, but consider the impact on changes to the system. As the base use case evolves and new extensions are developed, the base use case does not have to be changed with each new or revised extension. In this respect, the extend relationship functions much like the observer pattern. That is, the extension watches for circumstances that would require it to jump into the execution of the base use case. Using extensions enables us to leave the base use case untouched while freely adding behaviors as the system evolves. The extend relationship is modeled in Figure 12-15 as a dashed stick arrow from the extension use case to the base use case. The direction of the arrow helps to reinforce visually that the call is initiated by the use case at the base of the arrow. The extension use case decides when it is time to execute. The base use case has no part in the decision.
Use Case Diagram (By Sumit Joshi)
Page 16
Figure 12-15: Notation for the extend relationship. Applying an extend relationship requires four elements:
The base use case: The use case that will be augmented by the extension use case (the RescheduleEvent use case, for example). The extension use case: The use case that provides the added behavior (CancelPerformance and ReschedulePerformance are extension uses cases in this example). The extend relationship: A dashed arrow with the base attached to the extension use case and the arrow attached to the base use case. Extension points: One or more locations in the base use case where a condition is evaluated to determine whether the extension should interrupt the base use case to execute. The extension points may be listed within the use case icon or simply identified within the use case narrative.
Use Case Diagram (By Sumit Joshi)
Page 17
Figure 12-16: Extension point notation using a comment. Extension points may also be documented in a comment attached to the extend relationship, as shown in Figure 12-16. The comment uses a page icon with the top right corner folded down. It contains the condition that the extension is watching for and the label (extension point) that identifies the location in the base use case where the decision would take place. In this example, the condition tests to see whether both the start and end dates changed. It is possible that only one of the dates changed, in which case no performances would be rescheduled. They would either be deleted (if the start date moved later or the end date moved earlier) or added (if the end date moved out). The comment is attached with a binary constraint line, a fancy name for a dashed line connecting two model elements.
The contrast between include and extend relationships is sometimes confusing. Table 12-1 sets them side by side to highlight the similarities and differences.
Use Case Diagram (By Sumit Joshi)
Page 18
Table 12-1: Include versus Extend Include Extend
Augments the behavior of the Augments the behavior of the base base use case. use case. The extension use case might be used to augment the executing The included use case is use case. always used to augment the executing use case. The executing use case decides when to call the included use case. The included use case is unaware of the base use case. The relationship arrow is drawn from the executing use case to the included use case. The base of the arrow indicates that the base use case directs the included use case to execute. The extension use case decides when it will insert itself into the execution of the base use case. The base use case is unaware of the extension. The relationship arrow is drawn from the extension use case to the executing use case. The base of the arrow indicates that the extension use case is making the decision whether to interrupt the executing use case.
Use Case Diagram (By Sumit Joshi)
Page 19
4
Describing Use Case Scenarios
Scenarios describe each possible outcome of an attempt to accomplish a use case goal. A use case identifies a primary goal of the system. When an actor attempts to accomplish a goal using the system, there are usually decisions and rules that influence the outcome of the use case. For example, the user may be able to choose from a list of alternatives, or exception conditions may hinder the accomplishment of the goal. A scenario is a single logical path through a use case. UML even defines a scenario as an instance of a use case in that a scenario is one realization, or execution, of the conceptual use case. In other words, a use case defines what could happen, and a scenario defines what does happen under a given set of conditions. A scenario may be modeled using a Sequence diagram.
here are many ways to work with scenarios. You can simply read the narrative and extract each logical path from the text. You can draw out the logic with an Activity diagram so that the flow of logic can be visualized and more easily segmented. Whatever the means, the scenarios start to reveal the inner workings of the system and the expectations of the users in a way that the use case alone cannot. This closer look can open doors to further analysis of the system and ultimately to the design.
Use Case Diagram (By Sumit Joshi)
Page 20
4.1 Why you should care about use case scenarios In some situations a use case is simple enough that the narrative is more than ample to explain all the issues that define its proper execution. But in many other use cases, the logic can become troublesome. Many of the applications we work on today are complex and require significant scrutiny. In addition to addressing complexity, we need some way to test the accuracy and completeness of the use cases. Unfortunately, for many projects, developers often hold off testing until the end of the project, when they're short on time and focused on the solution rather than the requirements. Or worse yet, there is no time for testing at all, so final testing happens in production.
How to find use case scenarios Reading a use case narrative and following every possible path can be difficult. One very simple and practical tool to use to find scenarios visually is an Activity diagram. Visual models provide a valuable complement to text. Together, the two perspectives can reveal insights not visible from only one of these perspectives. Given that people learn in different ways, having different tools to explain the same problem can help everyone grasp the important issues more easily. One major benefit of an Activity diagram is its ability to quickly reveal dead-end segments and incomplete paths. The Activity diagram is still grounded in textual description for each activity, so there is significant overlap with the narrative that helps insure
Use Case Diagram (By Sumit Joshi)
Page 21
that the two representations, the narrative and the Activity diagram, are consistent. To find a scenario, start at the beginning of the use case narrative. It usually works best to determine the path of the successful scenario first, since it's usually the most commonly encountered path in practice. Trace the steps until you come to a decision, represented by a diamond. Now you have to make a choice. Select one of the possible paths leading out of the diamond, preferably the path that leads to the successful completion of the use case, and continue to trace the steps. Continue the process until you reach an end point. That completes scenario 1. Now return to the top and retrace the first scenario to the first branching point (decision). Start identifying the unique-portion of the second scenario at the branch by following a different path leading out of the decision. Continue tracing the steps as before. If you loop back to a place you have already been, then stop. Avoid creating redundant segments.
Use Case Diagram (By Sumit Joshi)
Page 22
Figure 12-20 traces the logic for the successful scenario first. It traces each step, following the choices we make at each decision point. On this-first pass we want the choices that will lead us through the successful scenario.
Figure 12-20: Trace the successful scenario from beginning to end.
Figure 12-21 selects the "No" path out of the confirm decision, representing the fact that the user decided not to go with the show they selected (accidents happen). (This segment will reveal a unique path through the use case narrative that we can use to build the second scenario.) This time the logic leaves the decision and loops back to the merge point just before the first decision.
Use Case Diagram (By Sumit Joshi)
Page 23
The scenario segment stops here. We can later put it together with the steps of scenario 1 that led up to the decision point to complete the definition of scenario 2.
Figure 12-21: In scenario 2, a performance is selected and the confirmation is declined.
Use Case Diagram (By Sumit Joshi)
Page 24
5
ONLINE EXAMINATION SYSTEM
Use Case Diagram (By Sumit Joshi)
Page 25
Use Case Diagram (By Sumit Joshi)
Page 26
Use Case Diagram (By Sumit Joshi)
Page 27
Use Case Diagram (By Sumit Joshi)
Page 28
Use Case Diagram (By Sumit Joshi)
Page 29
6
More Examples
1)HOTEL MANAGEMENT SYSTEM
Use Case Diagram (By Sumit Joshi)
Page 30
2)LIBRARY MANAGEMENT SYSTEM
Use Case Diagram (By Sumit Joshi)
Page 31
3)ATM
Use Case Diagram (By Sumit Joshi)
Page 32
Use Case Diagram (By Sumit Joshi)
Page 33
