Table of contents

1. Use Cases

1.1. Use Cases - Names

1.2. How to Find Use Cases

1.3. Example

1.4. Why develop a Use Case Model?

1.5. System / Subsystem

1.6. Components of a Use Case Diagram

1.6.1. System

1.6.2. Actors

1.6.2.1. How to find Actors

1.6.2.2. Human Actors

1.6.2.3. Non–Human Actors

1.6.2.4. How to determine who are the actors

1.6.2.5. Actor descriptions

1.6.2.6. Actor Generalization

1.6.3. Use Cases

1.6.4. Relationships / Links

1.6.4.1. Use case relationships

1.6.4.2. Extend – Relationship

1.6.4.3. Generalization Relationship

2. Scenarios

2.1. Pre-Conditions

2.2. Post-Condition

2.3. Example

2.3.1. Main flow of events

2.3.2. Exceptional flow of events:

1. Use Cases

  1. A use Case represents a set of sequence of events (actions) which combine to form some interaction between the software system and the outside world.
  2. Use cases does something of value to an actor.

1.1. Use Cases - Names

  1. Every use case must have a name that distinguishes it from other use case.
  2. A use case name may be text consisting of

-> Any number of letters, numbers and most punctuation marks (except for marks such as the colon, which is used to separate a class name and the name of its enclosing package.)

-> In practice, use case names are short active verb phrases naming some behavior found in the vocabulary of the system you are modeling.

1.2. How to Find Use Cases

  1. Which functions services (full functions) does actors require frame from the system ? What does the actor need to do?
  2. Does the Actor need to read, create, destroy, modify or store some kind of information in the system?
  3. Does the Actor need to get notified when some events occur in the system?
  4. Can some Actors daily work be simplified by functionality in the system? If so what work?

1.3. Example

  1. Joe, the shop attendant of the Video library, manages all the processes related to video lending.
  2. When a customer visit the video library, they can inquire about the video details from Joe. He check the system and tell the details to the customer.
  3. The shop lends videos to customers on daily basis. Joe record these video loans in the system entering the video details and the customer details.
  4. Customers who visit frequently can become members of the video library. Joe registers such interested customers in the system by entering the details and given them a membership number.
  5. Actor – Joe, the shop attendant
  6. What does the shop attendant perform using the system?

-> Help in finding video details

search video data/ Lookup video data, search video

-> Record the details when a video is lent

Record video lending/ Loan video/ Create video loan

-> Collect the details and register new members in the system

Register members/  create memberships

1.4. Why develop a Use Case Model?

  1. Graphically represent the proposed functionality of the new system.
  2. Use Case Model captures the functional requirements of a system.
  3. Help to demonstrate the high-level behavior of the proposed system to the client
  4. It illustrates to the development team exactly what is expected from a system.

1.5. System / Subsystem

  1. A system is a piece or multiple pieces of software that performs some sort of function for its users.
  2. When modeling a very large system that could benefit from being broken down into more maintainable pieces.

-> Creating such pieces are called subsystems

1.6. Components of a Use Case Diagram

  1. To construct a Use Case diagram, there are four basic components.

1.6.1. System

  1. Something that performs function(s).

1.6.2. Actors

  1. An Actor represents an entity in the outside world that takes on the role of interacting with the software system.
  2. An actor can be

-> A user (i.e. Human)

-> Another software system

-> A hardware device (with embedded software)

1.6.2.1. How to find Actors

  1. An Actor indicates an external person or system which is involved in a use case.
  2. The same person or system may play the role of more that on actor, depending on the context.
  3. An actor may be a set of roles, which are related.
  4. An actor may be involved in more that one use case.
  5. One actor is normally the indicator of each use case.

1.6.2.2. Human Actors

  1. Actors must always interact with the software.
  2. A human actor who:

-> Is involved in some process performed by the system.

-> BUT who does not directly interact with the software, is not a valid actor.

  1. Example: Identify the actors

-> Video library lends videos to their customers. When a customer wants to borrow a video, the selected video must be handed over to Joe, the shop attendant, who would record the video loan in the system.

-> Valid actor – Shop attendant (rather than saying Joe the best way is to use the role)

-> Note: the customer in this description is NOT an actor of the video library. Why?

1.6.2.3. Non–Human Actors

  1. A non human actor must:

-> Be an item of hardware of software which is external to the system.

Have a clearly defined mechanism, usually message passing for interacting with objects in the software.

  1. Have a behavior which is:

-> Totally determined by itself.

-> Significant in terms of the design (i.e. high level and relevant)

  1. Operating systems, files, monitors, mice are not valid non-human actors.
  2. Example:

-> When a new vehicle is registered into the National Fuel Pass system, the vehicle registration details are verified by the Vehicle registration system of the RMV.

1.6.2.4. How to determine who are the actors

  1. Answer the following questions:

-> who uses the system?

-> who gets information from the system?

-> who provides information to the system?

-> who installs, starts up or maintains the system?

1.6.2.5. Actor descriptions

  1. An actor description briefly describes the actor in terms of role and job title.

-> Example : The shop attendant of the Video library system

  1. The shop attendant uses the system to record new video loans, return of video, registering of new members and search video details on request.

1.6.2.6. Actor Generalization

  1. Actor Generalization is drawn from the concept of inheritance in Object Oriented Programming.
  2. In other words, a child actor:

-> Inherits all of the characteristics and behavior of the parent actor.

-> Can add to, modify or ignore any of the characteristics and behaviors of the parent actor.

1.6.3. Use Cases

  1. high level activities to be supported by the system.

1.6.4. Relationships / Links

  1. which actors are involved in which use cases (dependency, generalization, and association)

1.6.4.1. Use case relationships

  1. Also known as the uses relationship.
  2. Use Case A calls Use Case B.
  3. The included use case never stands alone. It only occurs as a part of some larger base that includes it
  4. Include relationship is to avoid describing the same flow of events several times

-> By putting the common behavior in a use case of its own (the use case that is included by a base use case).

1.6.4.2. Extend – Relationship

  1. If Use Case B extends Use Case A then,

-> The behavior of Use Case B is similar to but more specialized than that Use Case A.

-> The behavior of Use Case A is more generalized than that of Use Case B

-> Use Case A is known as the base Use Case

1.6.4.3. Generalization Relationship

  1. Generalization is a technique used to indicate Inheritance.
  2. This means that a child use case inherits the behavior and meaning of the parent use case.
  3. The child may add or override the behavior of the parent.
  4. The child may be substituted in any place the parent may appear in the system.

2. Scenarios

  1. A Use Case represents a high level description of an actor interacting with a software system.
  2. There may be a number of alternative possibilities for a given Use Case.
  3. Each of theses alternatives is called a scenario.
  4. The first scenario is the basic all went well flow of events.
  5. The other scenarios will be concerned with handling different possible outcomes.

2.1. Pre-Conditions

  1. A text description.
  2. Concerned with what must be true prior to the start of this scenario.
  3. Concerned with facts NOT actions.
  4. Must not contain predictions of what will happen in the flow of event in the scenario.
  5. Example

“A scenario in the member borrows video Use Case.”

Valid pre-condition 

->Member has a library video card and some videos to rent.

Invalid pre-condition 

->Member has invalid membership card which will be rejected.

2.2. Post-Condition

  1. Will be the last step of the basic flow.
  2. Concerned with what must be true after  the end of this scenario.
  3. Concerned with facts NOT actions.
  4. Must not describe future actions because scope should be restricted to the Use case which contains it.
  5. Example

“A scenario in the member borrows video Use Case.”

Valid post-condition 

->The member whose card was scanned was prevented from renting any videos.

Invalid post-condition 

->A member has been denied access and will be arrested by police.

2.3. Example

  1. In the context of an ATM system, you might describe the use case validate User in following way.

2.3.1. Main flow of events

  1. The use case starts when the system prompts the customer for a PIN number.
  2. The customer can now enter a PIN number via keypad.
  3. The customer comments the entry by pressing enter button.
  4. The system then checks the PIN number to see if it is valid.
  5. The PIN number is valid the system acknowledges the entry thus ending the use case.

2.3.2. Exceptional flow of events:

  1. The customer can cancel a transaction at any time by pressing the cancel button, thus restarting the use case. No changes are made to the customer account.
  2. The customer can clear a PIN number anytime committing it and reenter a new PIN number
  3. The customer enters an invalid PIN number, the Use Case restarts, if this happens three times in a row system cancel the entire transaction, preventing the customer from interacting with the ATM for 60 seconds.

Use Case Name

Validate User

Actors

Customer

Pre-Condition

There must a customer with an ATM card

Goal

To check whether the customer is a valid customer

Overview

The use case is used to validate the ATM card using the PIN number before performing any operations

Cross Reference

Typical course of events

Actor Actions

System response

1. The use case starts when the customer is prompt to enter the PIN number

2. The customer can enter a PIN number via keypad.

 

3. The customer comments the entry by pressing enter button.

 

 

4. The system then checks the PIN number to see if it is valid.

 

5. The PIN number is valid the system acknowledges the entry thus ending the use case.

Post - Condition

Successfully validate the customer

Alternative Courses

In step 1-5 : The customer can cancel a transaction at any time by pressing the cancel button, thus restarting the use case. No changes are made to the customer account.

 

In step 2: The customer can clear a PIN number anytime committing it and reenter a new PIN number

 

In step 5: The customer enters an invalid PIN number, the Use Case restarts, if this happens three times in a row system cancel the entire transaction, preventing the customer from interacting with the ATM for 60 seconds.