Use Case Concepts in Object-Oriented Analysis

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

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

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

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

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 

4. 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

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 

6. 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.