Use Case Modeling

Use Case Modeling: Specifying User Requirements

Artifact: Use-Case Model

The Use-Case Model:

• It is a model for specifying “user requirements” by using the approach of actors (the system’s environment) and use cases (intended functions).
• It serves as a contract and communication medium between the customer and the developers. 
• It is used as an essential input to activities in analysis, design, testing and implementation.

Use case models provide the following benefits:

• As a basis to help identify objects their relationships and responsibilities.
• One of the techniques used for creating a list of candidate classes/objects is an analysis of use case models artifact suites.

• A view of the system from an external person’s viewpoint.
• Potential users use the use-case model to better understand the system. 
• The architect uses the use-case model to identify architecturally significant functionality or grouping.
• Designers use the use-case model to get a system overview.
• An effective communication tool for validating requirements.
• You can also use the model to discuss the system with the customer during development. 
• The customer approves the use-case model. When you have that approval, you know the system is what the customer wants.
• People review the use-case model to give appropriate feedback to developers on a regular basis. 
• As a basis for a test plan
• Testers use the use-case model to plan testing activities (use-case, integration and other modes of testing) as early as possible. 
• As a basis for managing and controlling a systems development project.
• The manager uses the use-case model to plan and follow up the use-case modeling and also the subsequent design. 
• Other user managers and steering committees use the use-case model to get an insight into what has been done 
• Those who will develop the next version of the system use the use-case model to understand how the existing version works.
• As a basis for a user’s manual.
• Documentation writers use the use cases as a basis for writing the system's user guides. 
• This means that there are various levels of abstraction of use-case models depending on the amount of detail the user wants to look into.

Informal use cases – written using informal language. 

             The reason why informal language is used is that this is the best       means of communicating with the end users of the system. The users can easily understand this format and help the development of new use cases and the validation of existing ones.

Formal use cases – still written using informal language but with structure (Structured English, Action Diagram, Structure Chart, etc.) to explain in detail what the informal use case mean.

Detailed use cases – written in a formal specification language to explain to the programmer and testers what functionalities to program and test.

Overview of Use Case Modeling

1. Specifying User Requirements

      The first step in analysis is to specify “user requirements” and Use Case model is the primary modeling tool.

Goal -Create use case diagrams graphically depicting system behavior (use cases).

These diagrams present a high level view of how the system is used as viewed from an outsider’s (actor’s) perspective. 

A use case diagram may depict all or some of the use cases of a system.

Use Case Diagram Artifact Suite

The use case diagram artifact suite consist of two components:

1. Use Case Diagram and;

2. Use Case Specification Template

Use Case Diagram

Specifying Use Case Diagrams using UML

• A use case diagram is a diagram that shows a set of use cases and actors and the relationships among them.  

Use Case

A use case is a coherent unit of functionality provided by a system. A short but concise phrase of what the use case will do - Verb + Object Format: i.e. Buy Soda; Moving a Pallet; Manage Order; etc.

A use case is shown as an ellipse containing the name of the use case. 

The name of the use case may be placed below the ellipse - to allow for long name of the use case.

Use case names may be Title case or lower case.

Use Case Icon and Presentation Options

• An Actor element characterizes the role played by an outside object.
• One physical object may play several roles; therefore, several actor icons may model it.
• The standard stereotype icon for an actor is the “stick man” figure with the name of the actor below the figure.
• An actor may also be shown as a class rectangle with the stereotype “«actor»” or any other acceptable stereotype value.
• An actor may also be another system that the use case communicates with. For example, the use case is connected to the Internet – an external system.
• Actor and Role names may be Title case or lower case.

«Communicates» or «communicates» Use Case Relationship

• This is the only relationship between actors and use cases.
• The relationships are shown as solid lines with or without arrowheads between the actors and the use cases.
• The «communicates» stereotype may be omitted, as it is the default value.

Actor - Use Cases «communicates» Relationships

Use Case Specification Template

1. Use Case Name

A short but concise phrase of what the use case will do. 

For example:

Suggested Format: Verb + Object Format

• Buy Soda
• Moving a Pallet
• Manage Order

2. Brief Description

The description should briefly convey the role and purpose of the use                case. A single paragraph should suffice for this description.

3. Flow of Events

Basic Course of Action or Normal Course

You should describe how a use case starts and how it ends.

The use case starts when the actor does something. An actor always initiates use cases. The start of the use case must clearly describe what triggers the use case. Write, for example, "The use case can start when … happens.” or “The use case is initiated by … to ...” The use case ends when the actor does something or it is the normal end. You should clearly state whatever happens in the course of the flow to terminate the use case. 

Write, for example, "When the … chooses the … option, the use case terminates.” or “Normal end of use case.” The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Librarian enters Member’s information. It is better to say the Librarian enters the Member ID and Name. It should be phrased in the form of a dialog between the actor and the system.

Each paragraph expresses an action in the format: "When the actor does … the system does …."

Do not provide too much detail when you describe the use case's interaction with any actor. For example, “The Member ID is first checked by the system for checkdigit match using Modulo 11 method. It is then validated against the member master file to verify that he is indeed a valid member”.

It is better to simply say: “System validates Member ID”.

A Glossary of Terms is often useful to keep the complexity of the use case manageable you may want to define things like customer information there to keep the use case from drowning in details. Simple alternatives may be presented within the text of the use case.  If the alternative flows are more complex, use a separate section to describe it. The Alternative Flow subsection explains how to describe more complex alternatives.

Alternative Flows – Alternative Courses of Action or Alternative Courses.

Think of the Alternative Flow subsections like alternative behaviors:

Each alternative flow represents alternative behavior. It is used to document exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.

Keep each alternative separate to improve clarity. 

Using alternative flows improves the readability of the use case, as well as preventing use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.

4. Special Requirements - optional in the informal use case

A special requirement is typically a non-functional requirement that is specific to a use case, but is not easily or naturally specified in the text of the use case’s event flow. Legal and regulatory requirements and application standards; Quality attributes of the system to be built including usability, reliability, performance or supportability requirements. Additionally, other requirements such as operating systems and environments, compatibility requirements, and design constraints should be captured in this section.

5. Pre-Conditions

A pre-condition of a use case is the state of the system that must be present prior to a use case being performed.

6. Post-Conditions

A post-condition of a use case is a list of possible states the system can be in immediately after a use case has finished.

Use Case Modeling Illustrative Case 1: The Vending Machine

Vending Machine System Description

You were task to procure a vending machine. The machine can accept coins and bills. Based on the selection of the customer it can dispense the following items:

• Canned item - soda, tea, chocolate drinks, etc.;
• Candy and chocolate bars;
• Chips and other items in plastic wrappers.

The owner or a designated person will be allowed to:

• Install or pull out a vending unit;
• Restock the machine with new items;
• Replace expired or defective items;
• Update the selection buttons contents;
• Extract the money in a secured collection box and;
• Replenish the change reserve secured bins.

Step 1: Identify and Define Actors

Identifying Actors

-Try to identify who or what will use the system. 

-Start initially with actual people who will use the system; most people have an easier time focusing on the concrete versus the abstract. 

-As users are identified, try to identify the role the user plays while interacting with the system - this is usually a good name for an actor.

-When identifying actors, do not forget about the other systems with which the system being designed interacts.

Defining Actors

When identifying actors, be sure to write a short description for each actor:

-Usually a few bullet-points capturing the role the actor plays with respect to the system and;

-The responsibilities of the actor will help later on when the time comes to determine what the actor needs from the system.

Summary

• Actors are discovered by answering the following questions:
• Who directly uses the system?
• Who is responsible for maintaining the system?
• What are the external hardware or facilities (Internet) used by the system?
• Who starts the system?
• What other systems interact with the system?

The following actors were identified and defined for the vending machine:

• Customer - any person or entity that wants to purchase an item in the vending machine.
• Owner or designated person playing the following roles:
• Collector - authorized person allowed to:
• Open and close the vending machine;
• Extract money from a secured collection box;
• Replenish the change reserve bins and;
• Reprogram selector button price.
• Stocker - authorized person allowed to:
• Open and close the vending machine
• Replenish and replace items and;
• Update selection button contents.
• Maintenance - authorized person allowed to:
• Install and pull out a vending machine;

Step 2: Identify Use Cases and Actors Involved.

A use case is a specific way of using the vending machine. It shows the functionality performed by the vending machine in response to a stimulus from an actor. 

A use case model how an actor communicates with the vending machine. 

Use cases provide a vehicle to:

• Capture the requirements about a vending machine;
• Communicate with the end users and domain experts - manufacturers and distributors of vending machine - and;
• Test the system from the functional point of view.

The following use cases were identified for each actor:

Customer         Buy an item

Stocker Restock items

Collector         Collect money

        Change item price

Maintenance Install and Pull out machine

Step 3: Draw Use Case Diagrams or Model

Use Case Diagrams for Vending Machine

Step 4: Define Use Case using Template: Format 1

The following are the contents of the Informal Use Case Specification Document:

1. Use Case Name

• Buying an item

2. Brief Description

• This use case describes the scenario of a customer buying an item from a Vending machine. The machine is able to accept 25-centavo coin, 1-peso coin, 5-peso coin, 10-peso bill and 20-peso bill.

3. Flow of Events

Basic Flow or Normal Course of Actions

1. This use case is initiated when a customer wants to purchase an item.

2. The customer inserts a coin into the machine’s coin receptacle.

3. The machine verifies whether the coin is legitimate, records the amount            deposited, then updates the display with the total deposited.

4. If another coin is inserted, go back to step 2.

5. Customer selects an item by pushing a selection button.

6. Machine calculates whether change is due, then releases the selected             item from its holding bin and drops item to the retrieval receptacle.

7. Machine records transaction and updates item counts.

8. The customer retrieves item from retrieval receptacle and change from             change receptacle.

9. End of Use Case.

Alternative Flows or Alternative Courses of Actions

2a. The customer inserts 10-peso, or 20-peso bill into the bill receptacle.

3a. If coin is not legitimate, release the coin to the change receptacle.

3b. If peso bill is not legitimate, eject bill out of bill receptacle.

5a. If customer cancels transaction by pushing cancel button – money loaded        is returned via change receptacle and/or bill receptacle. Machine records          cancelled transaction and Use Case terminates.

6a. If selected item is out of stock, display message “ Out of Stock, Please             Make Another Selection”. Return to Step 5. 

6b. If money loaded is less than item selected price, display message “Not             enough money deposited. Return to Step 2 

6c. If money loaded is more than item selected price, machine releases appropriate coins into change receptacle. Return to Step 7.

4. Special Requirements 

Optional in the informal use case

5. Pre-Condition

Vending machine operation status light/sign is ON.

6. Post-Conditions

Machine returns original money loaded;

Machine issues out item and;

Machine issues out item and change.

7. Benefiting Actor - extension to notation.

Customer

8. Assumptions – extension to notation.

Use Case Modeling Illustrative Case 2: The Automated Warehouse Case

Notes on Warehouse Case:

• All loads in the warehouse are placed on pallets
• Pallets can be moved around using automatic trucks
• A technician can command a truck to move a pallet to another location
• Operations management sets a policy that after every nth move of a pallet, the pallet has to be checked at a checking station to make sure the load is still stable on the pallet.
• The value of n is the same for all pallets in the warehouse and may be changed at any moment
• If a truck wants to move a pallet for the (n+1)th time, and the destination is not a checking station, the pallet must not be moved
• A pallet may be moved earlier then the (n+1)th time to a checking station.

Use Case Diagram Model

Automated Warehouse Use Case Model

Use Case Diagram

Moving Pallet Use Case Diagram

Use Case Specification Format 2

USE CASE NAME:	Moving a Pallet
ACTOR:	Technician
DESCRIPTION:	Describes the process involved when a technician instructs a truck to move a pallet from one location to another.
NORMAL COURSE:	1.      The use case is initiated when the technician orders a truck to move a pallet to another location.
	2.      The truck moves to pallet location.
	3.      The truck picks up the pallet.
	4.      The truck moves the pallet to the destination location.
	5.      The truck puts down the pallet.
	6.      The truck returns to its base location.
	7.      End of Use Case
ALTERNATIVE COURSES:	2.      If the pallet is currently located at a checking station, the checking station must release the pallet before it can be picked up the truck.
	3.      If the pallet has been moved more n times or more and the destination is not a checking station, the pallet will not be moved. The use case continues at Step 6.
	5.      If the destination location contains a checking station, it will be switched on, resulting in the load on the pallet being stabilized.
PRECONDITION:	Technician is ordered by Operations Management to move a pallet.
POST-CONDITION:	a.      Pallet was successfully moved from one location to another. b.      Pallet was not moved – pallet has been moved n times or more and the destination is not a checking station.
ASSUMPTIONS:	Extension to use case notation.
SPECIAL REQUIREMENTS:	Optional.

Use Case Relationships with Other Use Cases

• Establishing Include-Relationships Between Use Cases 
• If a use case contains a segment of behavior of which only the result, not the method for getting the result, is important; this behavior can be factored out as an «includes» or «include» use case. 

You can use the «includes» relationship to: 

• Factor out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case, only the result of it is important. 
• Factor out behavior that is in common for two or more use cases. Similar to using a common subroutine that can be invoked by other programs.

The «includes» relationship is not conditional: 

• If the use-case instance reaches the location in the base use case for which it is defined, it is always executed. 
• If you want to express a condition, you need to do that as part of the base use case so that it never reaches the location for which the include-relationship is defined, it will not be executed.

The first and last alternatives can be converted into an «includes» use cases:

• Releasing Pallet and;
• Checking Pallet since their implementations are not known 

So the previous use case specifications:

NORMAL COURSE:	…
	2.      The truck moves to pallet location.
	3.      The truck picks up the pallet.
	4.      The truck moves the pallet to the destination location.
	5.      The truck puts down the pallet.
	…
ALTERNATIVE COURSES:	2.      If the pallet is currently located at a checking station, the checking station must release the pallet before it can be picked up the truck.
	5.      If the destination location contains a checking station, it will be switched on, resulting in the load on the pallet being stabilized.

l  Can be converted to:

NORMAL COURSE:	2.      The truck moves to pallet location.
	3a.    If the pallet is currently located at a checking station, then invoke include use case - Releasing Pallet.  // Includes insertion and return points// 3b.    The truck picks up the pallet.
	4.      The truck moves the pallet to the destination location.
	5a.    The truck puts down the pallet. 5b.    If the destination location contains a checking station, then invoke include use case - Checking Pallet.  // Includes insertion and return points//

The alternative course of action 2 and 5 are removed from the specification and replaces with a condition on normal course of action of the base use case and the included use cases.

Showing include-relationships in Use Case Diagram

Include-Relationships in a Use Case Diagram

The include-relationship is shown using a dotted line from the base use case with a thin line arrowhead pointing to the included use case with the stereotype «includes» or «include».

Establishing Extend-Relationships Between Use Cases 

-If a use case has segments of behavior that are optional or exceptional in character, and that do not add to the understanding of the primary purpose of the use case, factor those out to a new extension use case. 

The original use case then becomes a base use case, to which the extension use case has an extend-relationship.

• You can use the extensions for several purposes: 
• To show that a part of a use case is optional or potentially optional. In this way, you separate optional behavior from mandatory behavior in your model. 
• To show that a sub-flow is executed only under certain (sometimes exceptional) conditions, such as triggering an alarm.

The base use case should be complete by itself, meaning that it should be understandable and meaningful without any references to the extensions. 

However, the base use case is not independent of the extensions, since it cannot be executed without the possibility of triggering one or more of the extensions.

Figure 12: Showing Extend-Relationships to a Base Use Case: Place Call

The extend-relationship is shown using a dotted line from the extension use case with a thin line arrowhead pointing to the base use case with the stereotype «extends» or «extend».

Example as shown in Figure 12.

• In a phone system, the primary service provided to the users is represented by the use case - Place Call. Examples of optional services are: 
• Place Conference Call - To be able to add a third party to a call.
• Show Caller Identity - To allow the receiving party to see the identity of the caller 

This is a correct use of the extend-relationship: since Place Call is meaningful in itself, you do not need to read the descriptions of the extension use cases to understand the primary purpose of the base use case, and the extensions use cases have optional character.

The alternative 3 can be converted into a use case - Checking Times Moved.

The «extends» use case relationship is specified because it is possible that the move is not performed at all and the use case terminates after the truck has returned to its base location.

The alternative to making it an extend-relationship is to simply incorporate the alternative into the basic course of action.

Moving Pallet with Other Use Cases and Relationships

Use Case Specification with Extend-Relationships

USE CASE NAME:	Moving a Pallet
ACTOR:	Technician
DESCRIPTION:	Describes the process involved when a technician instructs a truck to move a pallet from one location to another.
NORMAL COURSE:	1.      The use case is initiated when the technician orders a truck to move a pallet to another location.
	2.      The truck moves to pallet location.
	3a.    If the pallet is currently located at a checking station, then invoke include use case - Releasing Pallet.  // Include insertion and return points// 3b.    The truck picks up the pallet.
	4a.    Invoke extend use case – Checking Times Move // Extend insertion point // 4b.    The truck moves the pallet to the destination location. // Extends return point 1//
	5a.    The truck puts down the pallet. 5b.    If the destination location contains a checking station, then invoke include use case - Checking Pallet.  // Include insertion and return points//
	6.      The truck returns to its base location. // Extends return point 2 //
	7.      End of Use Case
PRECONDITION:	Technician is ordered by Operations Management to move a pallet.
POST-CONDITION:	a.      Pallet was successfully moved from one location to another. b.      Pallet was not moved – pallet has been moved n times or more and the destination is not a checking station.
ASSUMPTIONS:	Extension to use case notation.
SPECIAL REQUIREMENTS:	Optional.