Use Case Diagram Lecture # 1

Use Case Diagram Use-cases are descriptions of the functionality of a system from a user perspective.  Depict the behaviour of the system, as it appears to an outside user.  Describe the functionality and users (actors) of the system.  Show the relationships between the actors that use the system, the use cases (functionality) they use, and the relationship between different use cases.  Document the scope of the system.  Illustrate the developer’s understanding of the user’s requirements.

Use Case Use case modeling is an iterative and incremental process. If user requirements change, the changes should be made in all the affected documents.

Use Case Use Case: A Use Case is a description of a set of interactions between a user and the system. Components of use case diagram:  Actor  Use case  System boundary  Relationship

Typical Processes use case name

Example

Actors An actor is some one or something that must interact with the system under development. Usually represented with a stick figure An actor may be: People Computer hardware and devices External systems

External Entities. Primary actors are those who use the system’s main functions, deriving benefits from it directly. Primary actors are completely outside the system and drive the system requirements Primary actors use the system to achieve an observable user goal Secondary actors play a supporting role to facilitate the primary actors to achieve their goals. Secondary actors often appear to be more inside the system than outside.

Actors primary - a user whose goals are fulfilled by the system importance: define user goals supporting - provides a service (e.g., info) to the system importance: clarify external interfaces and protocols offstage - has an interest in the behavior but is not primary or supporting, e.g., government importance: ensure all interests (even subtle) are identified and satisfied

Use Case What is USE case?  A use case is a pattern of behavior, the system exhibits  The use cases are sequence of actions that the user takes on a system to get particular target  USE CASE is dialogue between an actor and the system. Add course

System Boundary It is shown as a rectangle. It helps to identify what is external versus internal, and what the responsibilities of the system are. The external environment is represented only by actors.

Relationship Relationship is an association between use case and actor. There are several Use Case relationships: Association Extend Generalization Uses Include

Association An actor must be associated with at least one use case. An actor can be associated with multiple use cases. Multiple actors can be associated with a single use case.

Generalization Generalization of an actor means that one actor can inherit the role of an other actor. The descendant inherits all the use cases of the ancestor. The descendant have one or more use cases that are specific to that role

Example Actors are treated like classes and thus can be generalized

Uses  When a use case uses another process, the relationship can be shown with the uses relationship  This is shown as a solid line with a hollow arrow point and the > keyword

Extend It extends the base use case and adds more functionality to the system. Here are few things to consider when using the > relationship. The extending use case is dependent on the extended (base) use case. In the below diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit Funds” use case. The extending use case is usually optional and can be triggered conditionally. In the diagram you can see that the extending use case is triggered only for deposits over 10,000 or when the age is over 55. The extended (base) use case must be meaningful on its own. This means it should be independent and must not rely on the behavior of the extending use case.

Example

Include Include relationship show that the behavior of the included use case is part of the including (base) use case. Few things to consider when using the > relationship: The base use case is incomplete without the included use case. The included use case is mandatory and not optional.

Example

Generalization of a Use Case Similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant. This is used when there are common behavior between two use cases and also specialized behavior specific to each use case. For example in banking example there might be an use case called “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

Example registration graduate registration non-graduate registration

Example place phone call cellular network user receive phone call place conference call receive additional call use scheduler > Cellular Telephone

Example

Use-Case Diagram: Example 28 Actor AssociationSystem boundary Use-case System name

Example Let us consider a simple hotel information system for two types of customers: Tour Group customers and Individual customers Tour Group customers are those who have made reservations through a tour operator in advance, while Individual customers make their reservations directly with the hotel Both types of customers can book, cancel, check-in and check- out of a room by phone or via the Internet

Continued

Elements of use case diagram: Other details Connection between Actor and Use Case Boundary of system > Include relationship between Use Cases (one UC must call another; e.g., Login UC includes User Authentication UC) > Extend relationship between Use Cases (one UC calls Another under certain condition; think of if-then decision points) 15

Linking Use Cases Association relationships Generalization relationships One element (child) "is based on" another element (parent) Include relationships One use case (base) includes the functionality of another (inclusion case) Supports re-use of functionality Extend relationships One use case (extension) extends the behavior of another (base)

Generalization The child use case inherits the behavior and meaning of the parent use case. The child may add to or override the behavior of its parent. parent child

Example The actor Order Registry Clerk can instantiate the general use case Place Order. Place Order can also be specialized by the use cases Phone Order or Internet Order.

Example

Include The base use case explicitly incorporates the behavior of another use case at a location specified in the base. The included use case never stands alone. It only occurs as a part of some larger base that includes it. baseincluded >

Example updating grades output generating verifying student id >

Include Include relationship – a standard case linked to a mandatory use case. Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit History (include use case). Standard use case can NOT execute without the include case  tight coupling.

Example

Extend The base use case implicitly incorporates the behavior of another use case at certain points called extension points. The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case baseextending >

Extend Relationship Extend relationship – linking an optional use case to a standard use case. Example: Register Course (standard use case) may have Register for Special Class (extend use case) – class for non-standard students, in unusual time, with special topics, requiring extra fees…). The optional UC extends the standard UC Standard use case can execute without the extend case  loose coupling.

Example

A simple example 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.

Use Case: Log-in Use Case Description: A CUSTOMER needs to log-in before performing any transaction Pre-condition: A registered user. Post-condition: The CUSTOMER has been authorised to perform transactions. Log-in Customer

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

Example 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 must 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

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

Use Case UC-01 Change Password Use case name:Change Password Actors:Admin, Physician, Nurse, Receptionist, Lab Receptionist Purpose:To change the Password of the User. Pre condition:Authorized users for the system. Post condition:The Password has been changed successfully. Overview: To provide the facility of Change password.

Typical Actions Actor’s ActionsSystem Response 1.The user navigates to Change Password form from menu. 2.User enter previous password and then enter the new password 3.The user Changes the Password and press button. 1.Change Password form is displayed 2.Check previous password. 3.The Password is changed successfully.

Alternative actions Actor’s Actions Alternate System Response 1a.The User makes an invalid entry. 2a. Error Message is Displayed to user.

Use case description Use case name:Login Actors:Admin,Lab Receptionist Purpose:To log in the system. Precondition: Application is ready for running. Post condition:Connection to server establishes, and user logs in successfully. Overview: Every user is required to login before using the system. To login user is required to provide username, password.

Typical Actions Actor’s ActionsSystem Response 1. User enters login information (User Name, password and Department) and clicks on Login button. 2 i. The system will connect to Database and check the user name, password and Department against their user type for validity. ii. The system will display the application window to user.

Alternate Actions Actor’s ActionsAlternate System Response 1a.User enters invalid login information and clicks on Login button. 2a i).Connection to database is not established. ii).Login information is incorrect, indicate error.