Use Case Concepts in Object-Oriented Analysis
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:
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.
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.