Use Case Concepts in Object-Oriented Analysis
Site: | Saylor Academy |
Course: | CS302: Software Engineering |
Book: | Use Case Concepts in Object-Oriented Analysis |
Printed by: | Guest user |
Date: | Friday, February 4, 2022, 6:12 PM |
Description
Use cases are a powerful way of modeling what the system needs to do. Read this section to learn about use case diagrams and how they capture functional requirements.
1. Use case concepts
A use case is a very powerful UML tool. A use case describes and captures functional requirements, so uses cases are requirements or are functional requirements that indicate what the system will do. They also describe a set of interactions between a user and the system. A set of use case can be a description of the entire system to be implemented.
For example, to carry out the process of buying things at a store when a POST case study is used
- two actors must be involved: Customer and Cashier,
- the following sequence of events must be performed:
√ The Customer arrives at a checkout with items to purchase.
√ The Cashier records the purchase items and collects payment.
√ On completion, the Customer leaves with the items
To a user, a use case is a way of using the system. When a user is interacting with a system, system provides a service to the actors. Each use case then captures a piece of functional requirements for some users. All the use cases together describe the
overall functional requirements of the system. The first step in requirement capture is to capture requirements as use cases. UML provides a simple notation to represent a use case as follows:
Actors
A Use case cannot initiate actions on its own. An actor is someone who can initiate a Use Case. An actor is representing a certain role, instead of representing a particular individual. An actor can be users or external systems that the system interacts with.
With Liu, (2001) an actor:
- Stimulates the system with input events, or receives something from the system.
- Communicate with the system by sending messages to and receiving messages from the system as it performs use cases.
- May model anything that needs to interact with the system to exchange information. Actors can be human users, computer systems, electrical or mechanical devices such as timers.
If there is more than one actor in a use case, the one who generates the starting stimulus is called the initiator actor and the other participating actors. The actors that directly interacts the system are primary/direct actors, the others are called secondary actors.
Example:
An auto bank machine system (ATM system) (Case Study 2 under unit 0) interacts with a type of users who will use the system to withdraw money from accounts, to deposit money to accounts, and to transfer money between accounts. This set of users is represented by the Bank Customer actor. Therefore a use-case model can be used to represent the three use cases WithDraw Money, Deposit Money, and Transfer Money that has association to the Bank Customer actor as shown in Figure 3.2.
Figure 3.2: The Relationship of an Actor and a Use Case
Thus, actors represent parties outside the system that collaborate with the system. Once we have identified all the actors of a system, we have identified the external environment of the system.
For most systems, a single actor can interact with many use cases, and a single use case can be initiated by many different actors. Taking an example from the POST case study, Figure 3.3 shows a complete system described using actors and use cases.
Figure 3.3: Use Case Interacted by two Actors
Source: Ellen Ambakisye Kalinga, https://oer.avu.org/bitstream/handle/123456789/667/CSI%203104_EN%20Object%20Oriented%20Analysis%20and%20Design1.pdf?sequence=1&isAllowed=y
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
2. Use Case Granularity
Ariadne (2001) elaborate clearly that it can be difficult to decide upon the granularity of use cases in particular scenario, should each user-system interaction be a use case, or should the use case encapsulate all of the interactions? Taking an example of the ATM system in Figure 3.3 to allow a user to withdraw money, we may have the following interactions:
- Enter card
- Enter pin number
- Select amount required
- Confirm amount required
- Remove card
- Take receipt
Should each of these steps e.g. "enter pin number" be a use case?
This is a classic mistake in construction of use cases. Here we have generated a large number of small, almost inconsequential use cases. In any non-trivial system, we would end up with a huge number of use cases, and the complexity would become overwhelming.
Figure 3.4: A Not Useful Use Case Diagram
To handle the complexity of even very large system, we need to keep the use cases at a fairly "high level". The best way is to keep the following rule-of-thumb in mind.
"A Use Case should satisfy a goal for the actor"
If we apply this simple rule to our example above, we can notice than none of the presented use cases in Figure 3.4 is qualifying to be a use case, since they do not describe the goal of the use case. The goal of use cases could be withdraw money, deposit money etc as shown in figure 3.5.
Figure 3.5: A More Focused Use Case Diagram
3. Use Cases Identification
Use cases can be identified in two methods: actor-based and event based. Functional requirements document is the main source of information needed. Interviews with potential users of the system can also be one source of getting use cases. In some cases Joint Requirement Planning Workshops (JRP) can be used where all people interested in system being developed come together to give their view of what the system needs to do. Liu,
(2001 state that identifying use cases involves reviewing existing documents of requirements specification:
i. Use case identification on actor-based: method
(a) Find and specify all the actors by looking at which users will use the system and which other systems must interact with it.
(b) For each actor, identifying the processes they initiate or participate in by looking at how the actor communicate/interact with (or use) the system to do his work.
ii. Use case identification on event-based method
(a) Identify the external events that a system must respond to.
(b) Relate the events to actors and use cases.
For the POST application the following potential use actors and use cases as in Table 3.5 can be identified and the two can be presented in a use case diagram as shown in Figure 3.6:
Table 3.5: Actors and Use Cases of POST System
Actor | Processes to Initiate |
Cashier | Log In, Log Out, Cash Out |
Customer | Buy Items, Refund Items |
Manager | Start Up, Shut Down |
System Administrator | Add New User |
Figure 3.6: Partial Use Case Diagram for POST System Use Case descriptions
Each Use Case contains a full set of textual details about the interactions and scenarios contained within it. Use cases are described in order to understand more on its functionality. Table 3.6 shows the template for a Use Case description:
Table 3.6: A Template for a Use Case Description
Use Case: | Use Case name |
Actors: | Role names of people or external entities initiating and participating in the use case |
Short Description: | A brief description of the Use Case |
Pre-Conditions: | A description of the conditions that must be satisfied before the use case is invoked, i.e. what must always be true before beginning a use case scenario. |
Post-Conditions: | A description of what has happened at the end of the use case, i.e. what must be true on successful completion of a use case. |
Main Flow: | A list of the system interactions that take place under the most common scenario. For example for "withdraw money", this would be "enter card, enter pin, etc" |
Alternate Flow)s): | A description of possible alternative interactions |
Exception Flow(s): | A description of possible scenarios where unexpected or unpredicted events have taken place |
In some cases, a high-level use case can be needed to obtain some understanding of the overall process, and then expand it by adding to it with more details. A high-level use case describes a process very briefly, usually in two or three sentences.
Table 3.7: A Template for High-Level Use Case
Use case: | Name of use case (use a phrase starting with a verb). |
Actors: | List of actors (external agents), indicating who initiates the use case |
Purpose: | Intention of the use case. |
Overview: | A brief description of the process. |
Cross References: | Related use cases and system functions. |
With reference to a POST case study, the following as shown in Table 3.8 can be a description of a "Pay by Cash" use case
Table 3.8: A "Pay by Cash" Use Case Description
Use case: | Pay by Cash |
Actors: | Customer, Cashier |
Short Description: | A Use Case allows a cashier to record the cash tendered by the customer |
Pre-Conditions: | Items to be purchased listed and the total amount already displayed |
Main Flow: | 1. The Customer presents cash payment to the cashier
2. The Cashier records the cash tendered to the POST system 3. The system shows the balance due back to the Customer if any 4. The Cashier deposits the cash received and extracts the balance due. 5. The Cashier gives the balance due and the printed receipt to the Customer |
Alternate Flow)s): |
Item 4: Insufficient cash in drawer to pay balance. Ask for cash from supervisor |
Exception Flow(s): |
Item 3. If cash amount tendered is not enough, exception handling |
Having been identified and described use cases, a use case model can be created which describes how use cases relate to each other and to the actor. A use case diagram describes part of the use-case model and illustrates a set of use cases for a system, the actors, and the relation between the actors and use cases
Use cases relationships such as include, uses and extend can be used to reduce the complexity of the model.
Use cases within a development process
Activities in the use case analysis can be summarized as follows:
1. After system functions have been listed, then identify actors and use cases.
2. Draw a use case diagram for the system.
3. Relate use cases and illustrate relationships in the use case diagram.
4. Write the most critical, influential and risky use cases in the use case high-level
5. Describe the uses cases using a use case description template4. Identified Actors and Their Related Use Cases for the POST system
Applying the techniques used to identify use cases, we can have a sample list (not an exhaustive) of relevant actors and use cases as shown in Table 3.9
Table 3.9: Actors and Use Cases for POST System
Actor | Use Case |
Cashier | Log In / Logout Cash Out |
Customer | Buy Items: uses • By cash Refund Items• By credit |
Manager | Start Up Shut Down |
System Administrator | Add New Users |
5. Why use cases?
The reasons why use cases are good for requirement capture include:
1. They answer what the system should do for each user or actor question.
2. Use Cases define the scope of the system. They enable to visualize size and scope of the entire development.
3. They facilitate communication means between the customer and developers (use case diagram is so simple, anyone can understand it)
4. They represent system functions and the relationship among the system functions in a narrative way.
5. They extent the identification of concepts and objects involved in the application domain.
6. Use Cases are very similar to requirements, but whilst requirement tend to be vague, confusing, ambiguous and poorly written, the tighter structure of Use Case tend to make them far more focused
7. The "sum" of the use cases is the whole system. Anything not covered by a use case is outside the boundary of the system to be developed. So the Use Case diagram is complete with no holes
8.Use Cases guide the development teams through the development process. They give the summary of what is needed to be done by the system
9.Use Cases provide a method for planning development work, and allow to estimate how long the development will take
10. Use Cases provide the basis for creating system tests
11. Use cases help with the creation of user guides
12. Use cases can be a source of information during validation and verification of a software6. Conclusion
Use cases are a powerful way of modelling what the system needs to do. A use case is full end-to-end story about the use of the system to carry out a task, not an arbitrary combination of a number of steps of computation. Use cases are excellent way of
describing the system’s scope. We need to be careful on the granularity of the Use Cases to control complexity.