Use Case Modeling Requirements Engineering 1 Use Case

Use Case Modeling Requirements Engineering 1

Use Case Modeling Needs Features Software Requirements Use Case Modeling Design

The Use Case Model Components Use Case Diagram Textual Descriptions

Use Case Diagram Notation Only Use Cases turn into code. Actors never turn into code. System Use Cases = Services

Actors • Actors are anything that DIRECTLY interacts with the system. • We don’t care about other interactions an actor has with outside systems (or other actors). • An actor can be a human being or another system. • Primary actors are actors who interact with the system to get a service from it. • Secondary actors are actors who interact with the system to facilitate the execution of a service to be delivered for a primary actor. • Since actors are things, then they are written as nouns not verbs.

Actors • Actors play a role not an instance. • Mary, Michael, Ahmed and Vijay are students, then the appropriate actor should be called “Student”, assuming a course registration system. • Why roles not instances? • Mary and Michael (the instances) can later on have a different role in another system. For example, in a restaurant system, they play the role of the “Customer”. • The registration or restaurant systems’ design do not care about the individuals per se, they care about the role they play with the system.

Boundary-Level Interactions System GOLDEN RULE Use cases ONLY describe Functional requirements Service Delivered

The Right Level How big should a use case be? Too BIG!! Use phone Just right!! Make a call GOLDEN RULE 1 use case = 1 service Too small!! Pick up phone Get dial tone Dial number ….

The Association Relationship The only relationship allowed between actors and use cases

The Association Relationship An arrow head indicates who starts the interaction. Make a Caller

The Association Relationship An arrow head indicates who starts the interaction Callee Make a Caller

The Association Relationship No arrow head indicates a bi-directional association. Meaning any party (actor/system) can start the interaction Read email

Reuse Mechanisms Why?

Reuse Mechanisms Why? We don’t want redundant documentation Maintenance becomes a nightmare

Reuse Mechanisms Four reuse mechanisms o o Include Relationship Extend Relationship Generalization Relationship Implementation Relationship

The Include Relationship Base Use Case <<include>> Inclusion Use Case The <<include>> relationship indicates that the Base use case requires the inclusion of the behavior inside the Inclusion use case in to be complete.

The Include Relationship Base Use Case <<include>> Inclusion Use Case

The Include Relationship The included behavior can be added anywhere to the Base use case, in fact it can be added multiple times. This is very similar to function calling Base Use Case <<include>> Inclusion Use Case

The Include Relationship Base Use Case <<include>> Inclusion Use Case

The Include Relationship Base Use Case <<include>> Incomplete Inclusion Use Case Complete -

The Include Relationship Warning: Functional Decomposition An inclusion use case that is included by only one base use case <<include>> Withdraw Cash P P P P Validate PIN This is requirements engineering. We are not in the business of breaking down the problem.

The Include Relationship Warning: Functional Decomposition An inclusion use case that is included by only one base use case Withdraw Cash Problem <<include>> Validate PIN Rather we want to put the pieces together to figure out what is the problem.

The Include Relationship Warning: Functional Decomposition An inclusion use case that is included by only one base use case Withdraw Cash Problem <<include>> Validate PIN After we figure out the problem then we can break it down. Divide and conquer.

The Include Relationship Warning: Functional Decomposition An inclusion use case that is included by only one base use case Withdraw Cash <<include>> Validate PIN After we break it down, we can then start to figure out a solution. Solution

The Include Relationship This is OK! Withdraw Cash Deposit Cash <<include>> < de u l c <in >> Validate PIN

The Include Relationship This is OK too because sometimes the inclusion use case has stand-alone behavior that can be useful to an actor on its own Base Use Case <<include>> Inclusion Use Case

The Extend Relationship The extenion use case extends the Base use case with additional behavior. This behavior is usually optional in nature or to handle exceptional situations. Base Use Case <<extend>> [Condition] Extension Use Case

The Extend Relationship Base Use Case <<extend>> [Condition] Extension Use Case

The Extend Relationship Base Use Case <<extend>> [Condition] Extension Use Case

The Extend Relationship Base Use Case <<extend>> [Condition] Extension Use Case

The Extend Relationship Base Use Case <<extend>> Extension Use Case [Condition] Incomplete Complete +

The Extend Relationship

The Extend Relationship • Optional Behavior Buy Book <<extend>> [Promotion valid] Giveaway T-Shirt

The Extend Relationship • Error-Handling Behavior Buy Drink <<extend>> [Vending machine catches fire] Call Ambulance

The Extend Relationship Warning: Functional decomposition When an extension use case extends more than one base use case Base Use Case <<extend>> > x d> n e t Base Use Case e << Extension Use Case

The Extend Relationship Extension use cases are usually custom-made for their respective base use cases

Extension Points extension point: ep 1 Base Use Case extension points: 1. ep 1 2. ep 2 Base Use Case: 1. 2. ep 1 3. <<extend>> [Condition] Extension Use Case

The Generalization Relationship The behavior in the child use case is a specific version of the behavior in the general use case General Use Case 1. 2. 3. Specific Use Case 1. 2. 3’. 4. 5.

The Generalization Relationship Buy Tickets Buy On-Sale Tickets

The Implementation Relationship Abstract use cases are incomplete in nature and that’s why they HAVE TO be implemented Abstract Use Case 1. 2. 3. Implementing Use Case 1. 2. 3’. 4. 5.

The Implementation Relationship Perform Transaction using Credit Card Perform Transaction using Cash

The Generalization Relationship General Use Case 1. 2. 3. Specific Use Case 1. 2. 3’. 4. 5.

Reuse Mechanisms Four reuse mechanisms o o Include Relationship Extend Relationship (A- + B) (A + B+) Generalization Relationship Implementation Relationship (A + A∆) (A- + A∆)

Actor Generalization Bank Employee Teller

Use case description – Flow of Events : When and how the use case starts and ends What interaction the use case has with the actors What data is needed by the use case The normal sequence of events for the use case The description of any alternate or exceptional flows

Use case description – Flow of Events : Basic Flow of Events Alternate Flow of Events Exceptional Flow of Events (extension points)

Examples: Ticket Booking Basic Flow 1. The use case begins when the customer selects the option to view flight information. 2. The system prompts for the departure and destination cities and the departure and return dates. 3. The user enters the departure and destination city, departure date, and return date. 4. The system displays a list of available flights, including the fare. A 1: There are no available flights. 5. The user selects the flight they would like to reserve. 6. The system displays all available fare options for that flight. 7. The user selects the fare option they would like to reserve. A 2: The user selects a free ticket through frequent−flyer membership.

Ticket Booking … 8. The system displays the fare that the user will pay. 9. The user confirms the rate. 10. The system prompts for a credit card type, number, name, and expiration date. 11. The user enters the card type, number, name, and expiration date. 12. The system submits the credit purchase. A 3: Account not found A 4: Insufficient funds E 1: Credit system not accessible 13. The system reserves a seat on the plane for the user. 14. The system generates and displays a confirmation code to the user. 15. The user confirms receipt of the code. 16. The use case ends.

Ticket Booking…. Alternate Flows A 1: No available flights 1. The system displays a message that there are no available flights for the departure and destination cities, departure date, and return date entered. 2. The user confirms the message. 3. The flow returns to the primary flow, step 2. A 2: Free ticket through frequent−flyer membership 1. The system prompts for the frequent−flyer number. ………….

Ticket Booking…. Extension Points E 1: Credit system not accessible

Template Use Case Name should be an action (a verb) not a noun. “Register Course” is a good name, “Registration” is not. Actors Description Actor 1, Actor 2, Actor 3…. . Just a one/two sentence brief description in case the reader doesn’t want to go in great detail. Includes Use Case X Extends Use Case Y … Dependencies Preconditions Normal Flow Alternative Flow Extension Points Post-conditions Other Requirements A situation that needs to be true BEFORE the use can execute. 1. User does this 2. System does that 3. Use does this 4. … - At BF step X, if user chooses to do this then 1. System does this 2. Use does that Return to BF at step Y (or it can be that the use case terminates) EP 1: Extension point 1 name EP 2: Extension point 2 name A situation that needs to be true upon completion of the use case but BEFORE the use can terminate. Here you can specify non-functional requirements relating to that use case