IS223D: OBJECT-ORIENTED DESIGN is223d.blogspot

1. IS223D: OBJECT-ORIENTED DESIGNhttp://is223d.blogspot.com Lecture 2: Use-case Modeling Information Systems Department

2. 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

3. 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

4. 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

5. 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

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

7. 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

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

9. 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

10. 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

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

12. 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 • Apassive 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

13. 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

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

15. updating grades faculty 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. Information Systems Department

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

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

18. 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

19. Cont. • An online shopping portal allows their customers to browse or buydifferent 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.

20. Cont. Online shopping system

21. 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

22. parent child 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. Information Systems Department

23. registration non-graduate registration graduate registration More about Generalization Information Systems Department

24. 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

25. base included <<include>> 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. Information Systems Department

26. updating grades <<include>> verifying student id output generating <<include>> 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. Information Systems Department

27. Check Client’s Credit History Authorize Car Loan <<include>> Include relationship • 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). • The standard UC includesthe mandatory UC (use the verb • to figure direction arrow). • Standard use case can NOT execute without the include case  tight coupling . Information Systems Department

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

29. <<extend>> Exam-grade appeal Exam copy request More about Extend • Enables to model optional behavior or branching under conditions. Information Systems Department

30. Register for Special Class Register Course <<extend>> 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. Information Systems Department

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

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

33. 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

34. 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) <<include>> <<extend>> Extend relationship between Use Cases (one UC calls Another under certain condition; think of if-then decision points) Elements of use case diagramSummary Information Systems Department

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

36. 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

37. The answer Information Systems Department

38. 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

39. 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

40. 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

41. Use case diagram example Library Information System Borrow Resources Librarian Add Resources Patron ReturnResources Information Systems Department

42. 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

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

44. Example of High Level Use case: Buy Items • 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

45. 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

46. Example: Expanded Use caseBuy Items with Cash • 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

47. Typical Course of Events Information Systems Department

48. Typical Course of Events Alternatives: Line 2. Invalid identifier entered. Indicate errors Line 7. Customer didn’t have enough cash. Cancel sales transaction Information Systems Department

49. 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

50. Essential vs. Real Use CasesBuy 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 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