Functional View: Use Case Modeling Use-Case Modeling Use-case descriptions (or scenarios) Use-Case Diagrams When to model with use cases Use Case Modeling Tips
Use-Case Modeling Use-case models describe how a business system interacts with its environment. They illustrate the activities that are performed by the users of the system. They are functional diagrams in that they describe the basic functions of the system; that is what the users can do and how the system should respond to the user’s actions. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’). Use cases are the discrete activities that the users perform, such as selling CDs, ordering products, creating invoices, and accept returned goods from customers. User Activity or Process
Use Case
The first step in developing use cases is to prepare use-case descriptions or usecase scenarios from the user requirements. Then use-case diagrams are then developed from the use-case descriptions. Use cases are logical models. Use-case descriptions (or scenarios) Use-case descriptions or scenarios are text-based descriptions developed from the requirements gathered from the users. Each use case describes one and only one function or role that the users have with the system; although there can be many roles of a particular type of user. A use-case description contains all the information needed to build the diagram, but it expresses it in a less formal way that is usually simpler for users to understand. The basic parts of a use-case description are: the use-case name, ID number, primary actor, brief description, trigger, relationships, and flow of events. The primary actor is usually the trigger of the use case – the person or thing that starts the execution of the use case. The primary purpose of the use case is to meet the goal of the primary actor. The brief description is typically a single sentence that describes the function of the use case. 1
Each use case has a trigger – the event that causes the use case to begin. A trigger can be an external trigger such as a customer placing an order (click), or it can be a temporal or internal programmatic trigger such as a book being overdue. Use-case relationships explain how the use case is related to other use cases and users. The four basic types of relationships are: association, extend, include, and generalization. An association relationship documents the communication that place between the use case and the actors that use the use case. An extend relationship represents the extension of the functionality of the use case to include optional behavior of another use case. An include relationship represents the mandatory inclusion of another use case. The generalization relationship allows use cases to support inheritance, such as a patient can inherit a new patient and an old patient. The flow of events describes the steps to complete the business process depicted in the use case. It is equivalent to process description in the traditional approach.
Example of an Use Case Description 2
Use-Case Diagrams A use-case diagram illustrates in a very simple way the main functions of the system and the different kinds of users that interact with it. It summarizes all use cases (for the part of the system being modeled) together in one picture. Figure below illustrates the basic syntax rules for a use-case diagram. There are few important aspects of a use-case diagram: actors, use cases, associations, and a system boundary.
3
Actor: An actor, diagrammed as a stick figure, is not a specific user, but a role a user can play while interacting with the system. An actor can also represent another system with which the current system interacts. Actors can provide inputs to the system, receive outputs from the system, or both. Sometimes an actor plays a specialized role of a more general type of actor. For example, a new patient may at times act as specialized of a patient. This can be shown by placing an arrow from the specialized actor to the generalized actor. See next page.
Use Case: A use case, depicted by an oval, is a major process performed by the system that benefits an actor in some way. At times a use case includes the functionality, extends the functionality, or generalizes the functionality of another use case. These are shown by relationships mentioned before. To help understand a usecase diagram, “higher-level” use cases normally are drawn above “lower-level” ones.
An example of a use Case diagram
4
Association: Use cases are connected to actors through association relationships. A line drawn from an actor to a use case depicts an association. The association typically represents two-way communication between the use case and the actor, and there are no arrows on the line. One-way communication is typically depicted by a solid arrow in the direction of the information flow. It is also possible to represent the multiplicity of the association. An asterisk (*) at the actor side represents that any instance of the actor can execute the use case. An asterisk (*) on the use case side represents that the use case can be executed as many times as necessary.
1
*
Place Order
Salesperson
1
*
Establish Credit
Supervisor
5
System Boundary: The use cases are enclosed in a system boundary, which is a box that represents the system and clearly delineates what parts of the diagram are external or internal to it. The boundary is the automation boundary. The name of the system can appear either inside or on top of the box.
System Boundary
Telephone Catalog
Check status
Place order
Salesperson
Fill orders Shipping Clerk
Customer Establish credit
Supervisor
6
Relationships: As mentioned before, it is possible to have use cases that are not directly accessed by the actors but are necessary to be processed to complete the user action. For example, Place Order use case might require Supply Customer Data use case to make sure the customer account exists or Order Product use case to include the products for the order. Thus Place Order use case or Supply Customer Data and Order Product use case. This is shown by a line with an arrow connecting the two use cases. An relationship represents the extension of the functionality of the use case to include optional behavior of another use case
Supply Customer Data
«include»
Order Product
«include»
Arrange Payment
«include»
Place Order 1
*
Extension points additional requests : after creation of the order
«extend» the salesperson asks for the catalog
Request Catalog
7
Organization of the Use Cases: There are various ways to organize the use cases to depict different points of view of the system. One is to organize the use cases by subsystem such as an Order-entry subsystem or Payment subsystem. Another might be to include all subsystems of a system, such as an Order Processing system that includes all use-cases of Order-entry, Invoicing, Payment, etc. Yet another might be to include all use cases of a particular actor in a diagram. An analyst chooses to draw use case diagrams based on the needs of the project team.
8
When to model with use cases •
Model user requirements with use cases.
•
Model test scenarios with use cases.
•
If you are using a use-case driven method, start with use cases and derive your structural and behavioral models from it.
•
If you are not using a use-case driven method, make sure that your use cases are consistent with your structural and behavioral models.
Use Case Modeling Tips •
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
•
When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams
•
Factor out common usages that are required by multiple use cases o If the usage is required use o If the base use case is complete and the usage may be optional, consider use
•
A use case diagram should o contain only use cases at the same level of abstraction o include only actors who are required
•
Large numbers of use cases should be organized into packages
9
