Software Engineering Design & Modelling Capturing Requirements Using Use Cases

Chapter Outline Use cases Use case diagrams Case Study

Introduction No system exists in isolation. Every system interacts with human or automated actors that use the system for some purpose and those actors expect the system to behave in predictable ways We can use UML to capture and model the requirements associated with a system will look at use cases and use case diagram in modelling requirements

Use Cases

Introduction A use case specifies the behaviour of a system or part of a system is used to capture intended behaviour of the system (functional requirements), without having to specify how that behaviour will be implemented As we implement our system, these use cases are realized by collaborations whose elements work together to carry out each use cases Well-structured use cases denote essential system or sub-system behaviours only.

Definition A use case is a description of a set of sequences of actions, including variants, that a system performs in order to yield an observable result of value to an actor. it is a sequence of actions that an actor performs within a system to achieve a particular goal Graphically, a use case is rendered as an ellipse Use case’s name

Sensors:: Calibrate location Every use case must have a name that distinguishes it from other use cases simple name Path name : the name prefixed by the name of the package in which that use case lives Graphically, a use case is drawn showing only its name Sensors:: Calibrate location Place order simple name path name

Actors An actor represents a coherent set of roles that users of use cases play when interacting with these use cases an actor represents a role that a human (user), a hardware device, or even another system plays with a system An instance of an actor represents an individual interacting with the system in a specific way Although actors are used in models, actors are not actually part of the system they live outside the system

Graphically, actors are rendered as stick figures we can define general kinds of actors (such as Customer) and specialize them (such as CommercialCustomer) using generalization relationships generalization actor Customer actor CommercialCustomer Actors may be connected to use cases only by association indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages

Properties A use case describes a set of sequences each sequence represents the interaction of the things outside the system (its actors) with the system itself (and its key abstraction) a use case represents a functional requirement of your system as a whole A use case involves the interaction of actors and the system A use case may have variants use cases that are specialized versions of other use cases use cases that are included as parts of other use cases use cases that extend the behaviour of other core use cases

A use case carries out some tangible amount of work from the perspective of a given actor, a use case does something that’s of value to an actor Use cases can be applied to the whole or part of the system, including sub-systems and even individual classes and interfaces these use cases not only represent the desired behaviour of these elements, but they can also be used as the basis of test cases for these elements as they evolve during development

Flow of Events A use case describes what a system does but it does not specify how it does it. We can specify the behaviour of a use case by describing a flow of events, that should include: - how and when the use case starts and ends when the use case interacts with the actors and what objects are exchanged the basic flow and alternative flows of the behaviour Therefore, a flow of events can consist of the main flow of events exceptional flow of events or alternative flow of events

Scenarios Typically, we describe the flow of events for a use case in text But eventually, we will want to use interaction diagrams to specify these flows graphically (we will learn in the next chapter) It is desirable to separate main versus alternative flows because a use case describes a set of sequences It would be highly impossible to express all the details of a use case in just one sequence

Each of these variant can be expressed in a different sequence Ex: - A use case HireEmployee in a Human Resource system may have many business variations, e.g.: - A person can be hired from another company (the most common scenario) A person might be transferred from one division to another A foreign national can be hired Each of these variant can be expressed in a different sequence Each sequence is called a scenario A scenario is a specific sequence of actions that illustrates behaviour A scenario is an instance of a use case

Collaborations A use case captures the intended behaviour of the system without having to specify how that behaviour is implemented However, we eventually need to implement our use cases by creating a society of classes and other elements that work together to implement the behaviour of this use case This society of elements (both static and dynamic structure) is modelled in the UML as a collaboration

In UML, we can explicitly specify the realization of a use case by collaboration A given use case is usually realized by exactly one collaboration realization Place Order Order Management use case collaboration

A simple example 1 Example: - Describing the use case ValidateUser in the context of an ATM system Main flow of events The use case starts when the system prompts the CUSTOMER for a PIN number. The CUSTOMER enters a PIN number via the keyboard The CUSTOMER commits the entry by pressing the Enter button The system checks this PIN number to see if it is valid. If it is, the system acknowledges entry Use case ends once the system acknowledges the entry

Exceptional flow of events A CUSTOMER can cancel a transaction at anytime by pressing the CANCEL button, thus restarting the use case No changes are made to the CUSTOMER’s account The CUSTOMER can clear a PIN number anytime before committing it The CUSTOMER can re-enter a new PIN number If the CUSTOMER enters an invalid PIN number, the use case restarts If this happens three times in a row, the system cancels the entire transaction and the card will automatically be swallowed by the ATM machine

Customer Description Use Case Validate User Validate that the customer is an authorised user or the ATM machine. Pre-condition: An ATM card and an authorised PIN number Main flow of events: 1. The user inserts the ATM card. 2. The system prompts the CUSTOMER for a PIN number. 3. The CUSTOMER enters a PIN number via the keyboard. 4. The CUSTOMER presses the ENTER button. 5. The system checks the PIN number to see if it is valid. If it is, the system acknowledges entry. Post-condition: The CUSTOMER is authorised to continue the transaction. Validate User Description Use Case

Use Case Description Validate User (continue…) Alternate flow of events: 1. The user inserts the ATM card. 2. The system prompts the CUSTOMER for a PIN number. 3. The CUSTOMER presses the CANCEL button. 5. The system stops the transaction and returns the ATM cards. Post-condition: No changes are made to the CUSTOMER account. 3. The CUSTOMER enters a PIN number via the keyboard. 4. The CUSTOMER presses the CLEAR button. 5. The CUSTOMER re-enters the PIN number via the keyboard. 6. The CUSTOMER presses the ENTER button. 7. The system checks the PIN number to see if it is valid. If it is, the system acknowledges entry. The CUSTOMER is authorised to continue the transaction.

Use Case Description Validate User (continue…) Alternate flow of events: 1. The user inserts the ATM card. 2. The system prompts the CUSTOMER for a PIN number. 3. The CUSTOMER enters a PIN number via the keyboard. 4. The CUSTOMER presses the ENTER button. 7. The system checks the PIN number to see if it is valid. If it is not valid, the system prompts user to retry. 8. Repeat step 3-7 (maximum three times). 9 If user repeats more than 3 times, system will not return the ATM card to the CUSTOMER. Post-condition: The ATM card is swallowed by the ATM machine. The CUSTOMER is not able to perform any transactions.

A simple example 2 Example: In an on-line Bookstore system, user needs to log-in first before he/she could order and purchase any desired books. Describe the use case for the log-in process of the on-line Bookstore system. Answer: For every log-in process, there are two flows When the log-in is successful (main-flow) When the log-in is not successful (alternate-flows) For each flow, we can describe the sequence/flow of events.

Customer Log-in Log-in A CUSTOMER needs to log-in before performing any transaction Pre-condition: A registered user. Main flow of events: 1. The CUSTOMER clicks the Log-in button on the Home Page. 2. The system displays the Log-in Page. 3. The CUSTOMER enters his/her user ID and password. 4. The CUSTOMER clicks the OK button. 5. The system validates the log-in information against the ACCOUNT table in the database. 6. CUSTOMER is an authorised user; the system displays the Personal Home Page to the CUSTOMER Post-condition: The CUSTOMER has been authorised to perform transactions.

Log-in (cont…) Alternate flow: 1. The CUSTOMER clicks the Log-in button on the Home Page. 2. The system displays the Log-in Page. 3. The CUSTOMER enters his/her user ID and password. 4. The CUSTOMER clicks the OK button. 5. The system validates the log-in information against the ACCOUNT table in the database. 6. CUSTOMER is not an authorised user; the system displays a pop-up message to inform the CUSTOMER. Post-condition: The CUSTOMER is not authorised to perform transactions.

Use Case Diagrams

Introduction Use case diagrams are used to model the dynamic aspect of a system are central to modelling the behaviour of a system, a subsystem, or a class A use case diagram shows a set of use cases and actors and their relationships Use case diagrams are applied to model the use case view of a system involves modelling the context of a system, subsystem or class The requirements of the behaviour of these elements

Use case diagrams are important for visualizing, specifying, and documenting the behaviour of an element They make systems, subsystems, and classes approachable and understandable by presenting an outside view of how those elements may be used in context testing executable systems through forward engineering comprehending executable systems through reverse engineering

With the UML, we apply use case diagrams to visualize the behaviour of a system, subsystem, or class so that users can understand how to use that element developers can implement that element

Definition A use case diagram is a diagram that shows a set of use cases and actors and their relationships It commonly contains: - Use cases Actors Dependency, generalization and association relationships May also contain notes, constraints, packages and instances

Organizing use case diagrams There are three types of relationships that can be applied in a use case diagram: - (A) Generalization relationships between actors (as seen in slide 9) (B) Dependency and generalization relationships between use cases (C) Association relationships between actors and use cases

Receive additional call Place phone call Receive phone call Use scheduler Cellular Telephone Place conference call Receive additional call <<extend>> (B) Time scheduler Date scheduler (C) Cellular network Individual user (A) User Corporate user

Generalization relationships between use cases are similar to generalization among classes: - The child use case inherits the behaviour and meaning of the parent use case The child use case may add to or override the behaviour of its parent The child use case may be substituted any place that the parent may appear

For dependency relationships among use cases, there are two stereotypes that can be applied: - include one use case explicitly includes the behaviour of another use case at a specified point within a course of action The include use case does not stand alone; it has to be connected with one or more base use cases. We apply include relationship in order to factor common behaviour by pulling such behaviour from other use cases that it includes include relationship is essentially an example of delegation where a set of responsibilities in the system is captured in one place (the included use case) and other parts of the system (other use cases) can include this set of responsibilities whenever they need to use that functionality

UML notation: Example Customer Base Use Case Included Use Case <<include>> Log in Add to Wish List Check Out <<include>> Customer A CUSTOMER of an internet bookstore must be logged-in first before he/she can add items to his/her Wish List or to check out the items in the Shopping Cart

extend A base use case implicitly includes the behaviour of another use case at one or more specified points. We apply extend relationship in order to factor variants by pushing such behaviour into other use cases that extend it extend relationship is used to model the part of a use case the user may see as optional system behaviour model a separate sub-flow that is executed only under given conditions model several flows that may be inserted at a certain point, governed by explicit interaction with an actor

<<extend>> UML notation: Example Base Use Case Extended Use Case <<extend>> <<extend>> (order ID) Check Order Status Cancel Order Customer A CUSTOMER of an internet bookstore has the option of cancelling an Order in conjunction with checking the status of that Order.

Actors may be connected to use cases only by association indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages

Use Case Diagrams – Common Uses When we model the behaviour of a system (the static use case view of the system), we will apply the use case diagrams in two ways: - To model the context of a system To model the requirements of a system

1) Modelling the context of the system Involves drawing a line around the whole system and determining which things or actors lie outside the system and interact with it Ex: - In a credit card validation system, things such as accounts, transactions, and fraud detection agents are found inside the system, whereas things such as credit card customers and retail institutions are found outside the system The things that live inside the system are responsible for carrying out the behaviour that those on the outside expect the system to provide All those things on the outside that interact with the system constitute the system’s context, which defines the environment in which the system lives A use case diagram is used to specify the actors and the meaning of their roles

Example: - Credit Card Validation System Retail institution Customer Perform card transaction Retail institution Customer Process customer bill Reconcile transactions Sponsoring financial institution Individual customer Corporate customer Manage customer account

To model the context of a system, Identify the actors that surround the system by considering Which groups require help from the system to perform their tasks Which groups are needed to execute the system’s functions Which groups interact with external hardware or other software systems Which groups perform secondary functions for administration and maintenance Organize actors that are similar to one another in a generalization/ specialization hierarchy Provide a stereotype for actors, if it aids understandability Populate a use case diagram with these actors and specify the paths of communication form each actor to the system’s use case

2) Modelling the requirements of a system Involves specifying what the system should do (from the point of view of outside the system), independent of how that system should do it A use case diagram is used to specify the desired behaviour or the requirements of a system A requirement is a design feature, property or behaviour of a system When a system’s requirements is stated, we are asserting a contract between the things that lie outside the system and the system itself It declares what we expect the system to do A system’s functional requirements can be expressed as use cases, and the UML’s use case diagrams are essential for managing these requirements

Example: - Credit Card Validation System Customer Retail institution Perform card transaction Report on account status Customer Process customer bill Detect card fraud Retail institution Reconcile transactions Manage network outage Manage customer account Sponsoring financial institution

To model the requirements of a system: - Establish the context of the system by identifying the actors that surround it For each actor, consider the behaviour that each expects or requires the system to provide Name these common behaviours as use cases Factor common behaviour into new use cases that are used by others; factor variant behaviour into new use cases that extend more main line flows Model these use cases, actors, and their relationships in a use case diagram Adorn these use cases with notes that assert non-functional requirements (if necessary)

Use Case Diagrams - Summary When you draw a use case in the UML Give it a name that communicates its purpose Show only those use cases that are important to understand the behaviour of the system or the part of the system in its context Show only those actors that relate to these use cases Try not to show too many kinds of relationships

Case Study: On-Line Bookstore

On-line Bookstore is a web application that can be accessed by the store’s registered customer, whereby each customer can order books, review one or more books sold in the book store, and sell used books to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their account. Problem: Draw the use-case diagram for the above system

The steps involved: - Identify the actor : CUSTOMER Identify the use case for the actor: CUSTOMER REGISTER LOG-IN ORDER BOOKS CHECK OUT REVIEW BOOKS SELL USED BOOKS For each use case, determine include and extend relationships, if any A Customer needs to log-in first before he/she can order books, check out, review books or sell used books: include relationship A Customer can proceed to check out after he/she has ordered books: extend relationship

Use Case Context Diagram On-line Bookstore System Register <<extend>> (CustID) Check out Customer Order books <<include>> <<include>> Sell used books Log-in <<include>> Review books Use Case Context Diagram

Use Case Functional Requirements Diagram On-line Bookstore System Register <<extend>> (CustID) Check out Customer Order books <<include>> <<include>> Sell used books Log-in <<include>> Use Case Functional Requirements Diagram Review books

Use Case Description Register A new CUSTOMER needs to first register into the system before performing any transaction. Actor/s: CUSTOMER Pre-condition: An unregistered CUSTOMER. Main flow of events: 1. The CUSTOMER clicks the REGISTER button on the Home Page. 2. The system displays the Register Page. 3. The CUSTOMER enters all of the required information. 4. The CUSTOMER clicks the SEND button. 5. The system checks that all of the required information were entered. If yes, the system update the CUSTOMER’s record in the CUSTOMER and ACCOUNT tables in the database. System displays OK message. Post-condition: The new CUSTOMER has registered. The ACCOUNT and CUSTOMER tables are updated. Log-in A CUSTOMER needs to log-in before performing any transaction Pre-condition: A registered user. 1. The CUSTOMER clicks the Log-in button on the Home Page.

Use Case Description Log-in (continue…) 2. The system displays the Log-in Page. 3. The CUSTOMER enters his/her user ID and password. 4. The CUSTOMER clicks the OK button. 5. The system validates the log-in information against the ACCOUNT table in the database. 6. CUSTOMER is an authorised user; the system displays the Personal Home Page to the CUSTOMER Post-condition: The CUSTOMER has been authorised to perform transactions. Alternate flow: 1. The CUSTOMER clicks the Log-in button on the Home Page. 6. CUSTOMER is not an authorised user; the system displays a pop-up message to inform the CUSTOMER. The CUSTOMER is not authorised to perform transactions.

Use Case Description Order Books A CUSTOMER can order books to purchase. Actor/s: CUSTOMER Pre-condition: User have logged-in. Main flow of events: 1. The CUSTOMER enters the keyword for a book and clicks the SEARCH button on the Personal Home Page. 2. The system displays the matching books on the web Page. 3. The CUSTOMER chooses the desired book and clicks the ADD TO SHOPPING CART button on the web page. 4. The system adds the book into the CUSTOMER’s Order table in the database. Post-condition: The ORDER table has been updated. Check Out A CUSTOMER can purchase the books in his/her Shopping Cart. Pre-condition: The user have logged in and has at least one book in the Shopping Cart. Main flow of events: 1. The CUSTOMER clicks the Check out button on the Web Page.

Use Case Description Check Out (continue…) 2. The system displays the books in the ORDER table of the CUSTOMER on the web Page. 3. The CUSTOMER checks the order list for any inconsistency. If nothing found, CUSTOMER clicks the PROCEED button. 4. The system displays the Invoice page. 5. The Customer enters the relevant credit card information and clicks the OK button. 6. The system checks that the credit card is valid. Then, the system displays the Delivery Details page. 7. The CUSTOMER chooses destination for delivery, along with delivery options. Then, he/she clicks the PROCEED button. 8. The system will display the check-out information for confirmation. 7. The CUSTOMER checks that all information is correct and then clicks the OK button. 8. The system sends a confirmation via CUSTOMER’s e-mail. Post-condition: The ORDER table has been updated. Sell used books A CUSTOMER can sell his/her used books. Actor/s: CUSTOMER Pre-condition: The user have logged-in..

Use Case Description Sell Used Books (continue…) Main flow of events: 1. The CUSTOMER clicks the Sell Used Books button on the Home Page. 2. The system displays the Sell used books web page. 3. The CUSTOMER enters the required information on the used books that he/she wants to sell. 4. The CUSTOMER clicks the SEND button on the webpage. 5. The system displays a confirmation page listing the information that the CUSTOMER has entered. 6. The CUSTOMER checks that the information displayed are accurate. If yes, the CUSTOMER clicks the OK button on the web page. 7. The system updates the USED BOOKS table in the database. Post-condition: The Used Books table has been updated. Review Books A CUSTOMER can review books. Actor/s: CUSTOMER Pre-condition: User have logged-in.. 1. The CUSTOMER enters the keyword to search for a book and then clicks the SEARCH button on the Personal Web Page.

Use Case Description Review Books (continue…) 2. The system displays the matching books on the web Page. 3. The CUSTOMER checks for the desired book and clicks on the chosen book icon. 4. The system displays the book’s detail in the Book Detail web page. 5. The CUSTOMER clicks the REVIEW button on the web page. 6. The system displays the Review Book web page. 7. The CUSTOMER clicks on the desired star button and the click the OK button on the web page. 8. The system calculates the overall rating of the book and updates the Book table in the database. 9. The system displays the Book Detail web pages that have been updated. Post-condition: The BOOK and REVIEW tables are updated.