IS223D: OBJECT-ORIENTED DESIGN Information Systems Department Lecture 2: Use-case Modeling

Objectives To explain what use cases are To present UML use case diagram notation To present rules for making use case diagrams. To present the behavior of a use case Information Systems Department

Introduction Use-case modeling describes what a system does to benefit users. A use-case model is built through an iterative process, lead to a requirement specification on which all agree. Information Systems Department

Basics of Use Cases The primary components of a use-case model are use cases, actors, and the system modeled, also called the subject. Each use case specifies a complete functional unit. A use case must always deliver some value to an actor, something the actor wants. Information Systems Department

Cont. How the use cases are implemented, and how they work internally is not important. Use-case modeling is used not only to capture requirements of new systems; it is also used when new generations of systems are developed. Information Systems Department

Cont. The people who have an interest in the use-case models: Stakeholders Developers Integration and system test teams Information Systems Department

The primary purposes for use cases To decide and describe the functional requirements of the system. To give a clear and consistent description of what the system should do. To provide a basis for performing system tests that verify that the system works appropriately and validate it. Information Systems Department

Elements of Use Case Diagram: 2-Actor 3-Use case 4-Relationships 4.1 Between use cases and actors Generalization Include Extend 4.2 Between use cases 4.3 Between actors 1-System Information Systems Department

1.System The boundaries of the system, or subject developed are defined. Defining the boundaries of the system is not easy It’s not always obvious which tasks are best automated and which are best handled manually or by other systems. How large the system should be in its first generation. Information Systems Department

Cont. Identify the basic functionality and concentrate on defining a stable and well-defined system architecture to which more functionality can be added in future generations. system Information Systems Department

2.Actors An actor is someone or something that interacts with the system; it’s who or what uses the system. An actor can be a human being or another system. The actor represents a role, not an individual user of the system. (example: a professor can be an instructor and a researcher – plays 2 roles in the system). Actor triggers use case. name Information Systems Department

Cont. Actor has responsibility toward the system (inputs), and actor has expectations from the system (outputs). Actors can be An active actor: is one that initiates a use case A passive actor: never initiates a use case, but only participates in one or more use cases. An actor has a name (noun), and the name should reflect the actor’s role. Information Systems Department

3.Use cases A use case represents functionality for an actor, named by verb A use case in UML is defined as “a set of actions performed by a system, which yields an observable result for one or more actors”. Do something Information Systems Department

Cont. Each Actor must be linked to a use case, while some use cases may not be linked to actors. = Use Case Information Systems Department

4.1 Relationships between Use Cases and Actors Association: Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages. updating grades faculty Information Systems Department

Example Draw use case diagram for a restaurant that contains at least three use cases. Information Systems Department

Produce Management Reports Cont. Restaurant System Order Food Service Person Customer Hire Employee Produce Management Reports Applicant Manager Information Systems Department

Example An online shopping portal allows their customers to browse or buy different items. A customer may buy item(s) or just view the items and logout. If the customer decides to purchase an item, he/she selects the item and adds it to the shopping cart. Once the customer finishes selecting the item(s) the cart can be viewed. The customer can edit the final cart then submit the final cart for payment, or logout from the site without buying the items. The site's administrator can add or update different items in the system, manage the registration of new customer, and ensure the authorization of already registered customers. Draw the use case diagram for the online shopping system. Information Systems Department

Cont. An online shopping portal allows their customers to browse or buy different items. A customer may buy item(s) or just view the items and logout. If the customer decides to purchase an item, he/she selects the item and adds it to the shopping cart. Once the customer finishes selecting the item(s) the cart can be viewed. The customer can edit the final cart then submit the final cart for payment, or logout from the site without buying the items. The site's administrator can add or update different items in the system, manage the registration of new customer, and ensure the authorization of already registered customers. Draw the use case diagram for the online shopping system.

Online shopping system Cont. Online shopping system

4.2 Relationships between Use Cases Generalization - specifying how a child can specialize all behavior and characteristics described for the parent. Include - use cases that are included as parts of other use cases. Extend - use cases that extend the behavior of other core use cases. Information Systems Department

1.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 Information Systems Department

More about Generalization registration graduate non-graduate Information Systems Department

Generalization 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. Information Systems Department

2. Include When a number of use cases have common behavior, this behavior can be modeled in a single use case that is included by the other use cases. The included use case never stands alone. It only occurs as a part of some larger base that includes it. base included <<include>> Information Systems Department

More about Include Enables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own. If the use case you include has no use for other use cases, don’t separate it out as a separate complete behavior. updating grades output generating verifying student id <<include>> Information Systems Department

Include relationship Include relationship – a standard case linked to a mandatory use case. Authorize Car Loan Check Client’s Credit History <<include>> Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit History (include use case). The standard UC includes the mandatory UC (use the verb to figure direction arrow). Standard use case can NOT execute without the include case  tight coupling . Information Systems Department

3. 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. base extending <<extend>> Information Systems Department

More about Extend Enables to model optional behavior or branching under conditions. Request exam copy Appeal exam-grade <<extend>> Information Systems Department

Extend relationship Extend relationship – linking an optional use case to a standard use case. Register Course Register for Special Class <<extend>> 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. Information Systems Department

Cont. place phone call cellular network user receive conference call additional call use scheduler <<extend>> Cellular Telephone Information Systems Department

4.3 Relationships between Actors Generalization: The specialized actors inherit the behavior of the superclass and then extend that behavior in some way. student non-graduate graduate Information Systems Department

Use case diagram rules At least one use case At least one actor At least one use case associated with each actor No association line between actors No association line between use cases Name every actor and use case Not label any association line Information Systems Department

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

Elements of use case diagram Summary name Use case , starts with a verb name Actor can be human or other system Information Systems Department

Question Suppose we want to develop software for an alarm clock. The clock shows the time of day. Using buttons, the user can set the hours and minutes fields individually, and choose between 12 and 24-hour display. When an alarm fires, it will sound some noise. The user can turn it off, or choose to ’snooze’. If the user does not respond at all, the alarm will turn off itself after 2 minutes. ’Snoozing’ means to turn off the sound, but the alarm will fire again after some minutes of delay. Draw the use case model of the system. Information Systems Department

The answer Information Systems Department

Specifying the Behavior of a Use Case Describing the flow of events within the use case. Can be done in natural language, formal language or pseudo-code. Includes: how and when the use case starts and ends; when the use case interacts with actors and what objects are exchanged; the basic flow and alternative flows of the behavior. Information Systems Department

Use Case Behavior Description Types of use case behavior description format High level use case Expanded use case HL use case describes a process very briefly, usually in 2 or 3 sentences. Expanded use case describes a process in details. It has an additional section not present in HL, Typical course of events Information Systems Department

High level use case format It has the following format: Use Case: Use case name Actors: List of actors (external agents), indicating who initiates the use case Description (Success scenario): Narrative description of the process Information Systems Department

Use case diagram example Library Information System Borrow Resources Librarian Add Resources Patron Return Resources Information Systems Department

Example of High level use case Use Case: Add Resources. Actors: Librarian. Description: The use case begins when the Librarian receives new resources (books and 17 videos) to add to the catalog. The title, call number, and other information are recorded. Then the resources are placed on a shelf organized by resource type and call numbers. Information Systems Department

Use case diagram example POST Buy Items Cashier Log In Customer Refund Purchased Items Information Systems Department

Example of High Level Use case: Buy Items Actors: Customer(initiator) , Cashier Description : A customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items. Information Systems Department

Expanded use case format Use Case: Name of use case Actors: List of actors (external agents), indicating who initiates the use case Purpose: Intention of the use case Overview (Success scenario): Repetition of HL use case, or some similar summary Type: 1-primary, secondary or optional 2- essential or real Cross References: Related use cases and system functions. Typical course of actions: describes in detail the conservation of interaction between the actors and the system. Information Systems Department

Example: Expanded Use case Buy Items with Cash Actor: Customer (initiator), cashier Purpose: Capture a sale & its cash payment Overview (Success scenario): A customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a cash payment. On completion, the Customer leaves with the items Type: primary Cross References: Functions R1.2,… Information Systems Department

Typical Course of Events System Response Actor Action 1. This use case begins when a Customer arrives at the POST checkout with items to purchase 3. Determines the item price and adds the item information to the running sales transaction 2. The Cashier records the identifier from each item If there is more than one of the same item, the Cashier can enter the quantity as well 5. Calculate and presents the sale total 4. On completion of item entry, the Cashier indicates to the POST that item entry is complete 6. The Cashier tells the Customer the total Information Systems Department

Typical Course of Events System Response Actor Action 7. The Customer gives a cash payment possibly greater than the sale total 9. Shows the balance due back to the Customer & generate a receipt. 8. The Cashier records the cash received amount 11. Logs the completed sale 10. The Cashier deposits the cash received & extracts the balance owing The Cashier gives the balance owing, & the printed receipt to the Customer 12. The Customer leaves with the items purchased Alternatives: Line 2. Invalid identifier entered. Indicate errors Line 7. Customer didn’t have enough cash. Cancel sales transaction Information Systems Department

Essential vs. Real Use Cases Use Case Degree of Design Commitment Essential Very abstract Real Very concrete Essential use cases are expanded use cases that are expressed in an ideal form free of technology and implementation details Real use cases concretely describes the process in terms of its real current design, committed to specific input and output technology Information Systems Department

Essential vs. Real Use Cases Buy Items Actor Action 1. This Cashier records the identifier for each item System Response 2. Determines the item price & adds the item information to the running sales transaction The description & price of the item are presented Essential Use Case Actor Action 1. For each item, the Cashier types in the UPC field of Window1. They then press “Enter Item” button with the mouse or Enter key System Response 2. Display the item price & adds the item information to the running sales transaction The description & price of the current item are displayed in Textbox 2 of Window 1 Real Use Case Information Systems Department

Plan & Elaborate Phase Steps Define system function Define system boundary, actors & use cases HL use cases Draw use case diagram Expand critical use cases (essential / Analysis) Real use case (Design) Information Systems Department

Example Write an expanded use case “ATM withdraw cash”; which details the withdraw cash process from an ATM. Assume that: The user will choose only the transaction type withdraw The user account covers the required cash ATM is ready for this service Information Systems Department

Cont. Use Case: ATM withdraw cash Actor: user Purpose: To withdraw some cash from user’s bank account Overview (Success scenario): The use case starts when the user arrives at the ATM and enters his/her identification. The system requests the user password. The system validates the password. If the validation succeeded, the user can choose the withdraw operation. On completion, the user leaves with his/her cash and receipt. Type: primary Information Systems Department

Cont. Typical course of event Information Systems Department Actor System response 1. This use case starts when the user arrives at the ATM and enters his/her identification   3. User enters his password 5. User chooses withdraw transaction 7. User enters the required amount 9. Chose to confirm the receipt operation 11. the user leaves with his/her cash and receipt 2. Validate the user identification. If valid, request password 4. Verifies the authorizations. If authorized, asks for transaction type 6. Display the cash amounts choices 8. Asks for receipt 10. Verifies the requested amount with the account limit and daily limit. If receipt is requested, print the receipt Information Systems Department

Cont. Alternative: Line 2: if identification invalid, operation cancelled   Line 4: If password not authorized, error message is displayed and give 2 more trials Information Systems Department

Example Do the following operations on the use case diagram stated bellow: Information Systems Department

Cont. 1) Update the use case diagram such that a new patient may open a file. Also nurses help in making appointments and they may view a schedule. Also, Management and doctors may view the schedule. Add any other appropriate missing things. Information Systems Department

Cont. Information Systems Department

Cont. 2) Write a high level format for make appointment use case. Use case: Make appointment Actors: Patient (initiator), Nurses Description: This use case begins when the patient ask the nurses to reserve an appointments with a certain doctor and date, and produce an appointment slip. Information Systems Department

Cont. 3) Write typical course of events for make appointment use case. Information Systems Department

Cont. Information Systems Department

Question Write a high level format for snooze use case (slide #37). Information Systems Department

The answer Information Systems Department

Organizing Use Cases You can have a package own a use case. Use cases and actors can and often are placed into a substantial package structure. It is often useful to organize them along either functional lines or by use cases performed by specific actors. Note that the diagram can include use cases that are from other packages Information Systems Department

Cont. Information Systems Department

Cont. Information Systems Department

Testing Use Cases Testing involves two different but related goals: verification and validation. Verification confirms that the system is implemented correctly according to the requirements specifications and the design. Validation ensures that the system under development actually addresses the customer’s needs. Information Systems Department

Cont. Use cases provide the functional view of a software project from the start, making it the main source for validation. If the use cases don’t reflect the needs of the users, then validation is impossible. Verification can’t be carried out until there are working parts of the system. Then, it is possible to test that the system behaves as specified by the users, that the use cases described in the use-case model perform. Information Systems Department

Use Cases and Requirements Management Use cases provide an excellent way to capture and to organize requirements. However, systems will almost always get requirements from additional sources, not just documented use cases. Additional requirements-gathering efforts (interview, questionnaire, prototyping) are likely needed for many projects. Information Systems Department

Summary Use-case modeling is a technique used to describe the functional requirements of a system. Use cases are described in terms of external actors, use cases, and the subject modeled. Actors represent a role that an external entity such as a user, hardware, or another system plays in interacting with the system. Information Systems Department

Cont. Actors initiate and communicate with use cases, where a use case is a set of sequences of actions performed in the system. A use case must deliver a tangible value to an actor and is normally described through text documentation. An actor is typically connected to one or more use cases through associations. Information Systems Department