1 / 43

Software Engineering I, More on Use Cases and Use Case Model

Software Engineering I, More on Use Cases and Use Case Model. Overview of This Lecture. Introduction to Case Studies Requirement Gathering Use Case Modeling Domain Modeling / Business Modeling. Case Study 1: The Restaurant.

paguiar
Download Presentation

Software Engineering I, More on Use Cases and Use Case Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering I, More on Use Cases andUse Case Model

  2. Overview of This Lecture • Introduction to Case Studies • Requirement Gathering • Use Case Modeling • Domain Modeling / Business Modeling CPSC-4360-01, CPSC-5360-01, Lecture 3

  3. Case Study 1: The Restaurant • Example developed in the Practical Object-Oriented Design With UML by Mark Priestley, chapter 4. • Support the day-to-day operations of restaurant by improving the processes of: • Making Reservations • Allocating Tables • Current System is based on manual booking system: • Hand-written forms in large folder. CPSC-4360-01, CPSC-5360-01, Lecture 3

  4. Case Study 1: The Restaurant • Current system uses manual booking sheets. CPSC-4360-01, CPSC-5360-01, Lecture 3

  5. Case Study 1: The Restaurant • Three sittings (slots) in an evening • Booking can span more than one slot • Each Booking records: • Contact Name and Phone Number • Annotation made for various events: • Arrival of customer (Cross out record) • Table switch (Arrow to new table) • Cancellation • Time to vacate • “Walk-In” Customer CPSC-4360-01, CPSC-5360-01, Lecture 3

  6. Case Study 1: Restaurant • Problems with the manual systems: • Slow • Confusing and difficult to read • No backup copies • Hard to get useful management data • Develop an automated computerized version. CPSC-4360-01, CPSC-5360-01, Lecture 3

  7. Requirement Analysis Design Implement Test Where are we now? • Requirement Gathering • Understanding the requirements. • Business Modeling • Understanding the problem domain. CPSC-4360-01, CPSC-5360-01, Lecture 3

  8. Requirement: Overview • Early phase of the development. • Inputs: • informal specification. • Activities: • create use case model. • define use cases. • create domain model. • create glossary. CPSC-4360-01, CPSC-5360-01, Lecture 3

  9. Use Case View • Intended to provide a structured view of the system's functionality. • Description of how users interact with the system. • Supported by UML use case diagrams. • Serves as the starting point for all subsequent development. • Three important definitions: • Use Case • Scenario • Actor CPSC-4360-01, CPSC-5360-01, Lecture 3

  10. Use Case and Scenarios • Use Case: • The different tasks that users can perform while interacting with the system. • Scenarios: • Are particular instances of the use case: • Basic Course of Events: normal flow. • Alternative Course of Events: optional flow. • Exceptional Course of Events: erroneous flow. CPSC-4360-01, CPSC-5360-01, Lecture 3

  11. Actor • Roles played by users when interacting with a system, e.g.: • Receptionist (makes bookings); • Head waiter (assigns tables etc). • Individual user may play one or more roles at different times. • Often corresponds to certain level of access, e.g., logging into Lamar website as Staff or Student. CPSC-4360-01, CPSC-5360-01, Lecture 3

  12. Actor Communication Use Case <<Include>> <<Extend>> Inherit (Actor Relationship) Use Case Dependency Constraints Use Case Diagram • UML diagram to summarize the relationship between actors and use cases. • Diagram Element: CPSC-4360-01, CPSC-5360-01, Lecture 3

  13. Case Study 1: Use Cases • A preliminary list of use cases: • Record new booking. • Cancel a booking. • Record customer arrival. • Transfer a customer from one table to another. CPSC-4360-01, CPSC-5360-01, Lecture 3

  14. System Case Study 1: Use Case Diagram • Show use cases, actors and who does what. CPSC-4360-01, CPSC-5360-01, Lecture 3

  15. Use Cases Description • A use case comprises all the possible interactions that a user can have when performing a given task. • Often a dialogue between system and user. • These are described as courses of events, or scenarios. • A full description of a use case includes: • a basic course of events; • a number of alternative and exceptional courses. CPSC-4360-01, CPSC-5360-01, Lecture 3

  16. Basic Course of Events • Describes what happens in the ‘normal’ case. • For example, for ‘Record Booking’: Record Booking: Basic Course of Events • Receptionist enters date of requested reservation; • System displays bookings for that date; • There is a suitable table available: Receptionist enters details (customer’s name, phone number, time of booking, number of covers, table number); • System records and displays new booking. CPSC-4360-01, CPSC-5360-01, Lecture 3

  17. Use Case Templates • UML does not define a standard format for use case descriptions. • Various templates have been defined to structure descriptions. • Essentially a list of subheadings such as: • Name • Actors • Courses of events CPSC-4360-01, CPSC-5360-01, Lecture 3

  18. Receptionist enters date of requested reservation; there is a suitable table available: Receptionist enters details (customer’s name, phone number, time of booking, number of covers, table number); System displays bookings for that date. System records and displays new booking. Other Use Case Description Template • This version emphasizes the exchange between user and system, e.g.: Actor System CPSC-4360-01, CPSC-5360-01, Lecture 3

  19. User Interface Prototype • During the use case modeling activity, it is usually useful to have a rough idea of the user interface, e.g.: CPSC-4360-01, CPSC-5360-01, Lecture 3

  20. Alternative Courses of Events • Describe predicted alternative flows. • For example, if no table is available: Record Booking – No Table Available: Alternative Course of Event • Receptionist enters date; • System displays bookings; • no table available: end of use case. CPSC-4360-01, CPSC-5360-01, Lecture 3

  21. Exceptional Courses of Events • Situations where a mistake has been made. • E.g., allocate a booking to a small table: Record Booking – table too small: Exceptional course of events • receptionist enters date; • system displays bookings; • receptionist enters details; • system asks for confirmation of oversize booking; • if “no”, use case terminates with no booking made; • if “yes”, booking recorded with warning flag. CPSC-4360-01, CPSC-5360-01, Lecture 3

  22. Shared Functionality • Different use cases can overlap. • E.g., ‘Record Arrival’: Record Arrival: Basic Course of Events • head waiter enters date; • system displays bookings; • head waiter confirms arrival for booking; • system records this and updates display. • First two steps shared with ‘Record Booking’ (even though different actor). CPSC-4360-01, CPSC-5360-01, Lecture 3

  23. Use Case Inclusion • Move shared functionality to a separate use case: Display Bookings: Basic Course of Events • user enters a date; • system displays bookings for that date. • Include this in other use cases, e.g.: Record Booking: Basic Course of Events (revised) • receptionist performs Display Bookings; • receptionist enters details; • system records and displays new booking. CPSC-4360-01, CPSC-5360-01, Lecture 3

  24. The <<include>> Dependency • UML shows inclusion as a dependency between use cases, labelled with the stereotype <<include>> on the dashed arrow: System CPSC-4360-01, CPSC-5360-01, Lecture 3

  25. Case Study 1: Use Case Diagram (Revised) Display booking System CPSC-4360-01, CPSC-5360-01, Lecture 3

  26. Actor Generalization • The last diagram shows that the Receptionist can performs the Display bookings use case independently from the Record Booking use case. • Head Waiters can also performs Display bookings use case. • Introduce a more general actor Staff to show what the other two actors have in common. • The initial actors are specializations of the general actor. CPSC-4360-01, CPSC-5360-01, Lecture 3

  27. Actor Generalization Notation System CPSC-4360-01, CPSC-5360-01, Lecture 3

  28. Use Case Extension • Recording a walk-in can be described as an exceptional course of events: • someone arrives but there’s no booking recorded. • It could also be a separate use case: • a customer arrives and asks if there's a free table. • Then, it can extend ‘Record Arrival’: • even without a booking, the customer stays to eat. CPSC-4360-01, CPSC-5360-01, Lecture 3

  29. Use Case Extension Record Walk-in: Basic Course of Events: • Head waiter performs Display Bookings use case; • Head waiter enters details (time, number of covers and the table allocated to the customer); • System records and displays new booking. • Very similar to Record Arrival use case. Can we simplify? • <<Include>>dependency is inappropriate. (why?) • Record Walk-in is performed in some cases of Record Arrival, when there is no booking for the customer. CPSC-4360-01, CPSC-5360-01, Lecture 3

  30. The <<extend>> Dependency • Use case extension is shown with a <<extend>> dependency. • Record walk-in optionally extends the functionality of Record arrival. • States the constraint (condition) which causes the branch off. No Prior Booking System CPSC-4360-01, CPSC-5360-01, Lecture 3

  31. Case Study 1: Complete Use Case Diagram System CPSC-4360-01, CPSC-5360-01, Lecture 3

  32. Guidelines • Use case: • Should cover full sequence of steps from the beginning of a task until the end. • Should describe user’s interaction with the system. • Should not describe actual computations. • Should be as independent as possible from any particular user interface design. • Should only include actions in which the actor interacts with the computer. • Use case diagram should be used to supplement the use case description, not as the main artifact. CPSC-4360-01, CPSC-5360-01, Lecture 3

  33. Use Cases: Strengths • Simple and Familiar • Can be understood easily by untrained personnel, e.g., the customer. • Involve the customer early in the development. • Emphasize the user goals and perspective. • Scale in term of sophistication and formality. CPSC-4360-01, CPSC-5360-01, Lecture 3

  34. Use Cases: Problems • Care must be taken to ensure the use cases are complete and unambiguous. • Only actor initiated activities are recorded. • Software requirement derived from use cases often mimics the manual system too closely. • Preventing any innovative or more efficient way to be developed. CPSC-4360-01, CPSC-5360-01, Lecture 3

  35. Domain Modelling • Using UML diagram to construct a model of the real-world system: • Understand the problem domain. • Model recorded as a simplified class diagram. • Seamless development: • The same notation is used for analysis and design. • The design can evolve from the initial domain model. CPSC-4360-01, CPSC-5360-01, Lecture 3

  36. Class Name Attributes Class Generalization Constraints Domain Model Notation • A subset of class diagram model elements are used. Name Multiplicity Multiplicity Association Class CPSC-4360-01, CPSC-5360-01, Lecture 3

  37. Domain Model Notation • Classes represent real-world entities. • Attributes represent the data held about entities. • Associations represent relationships between the entities. • Generalization can be used to simplify the structure of the model. • Constraints can be used to indicate conditions. CPSC-4360-01, CPSC-5360-01, Lecture 3

  38. Case Study 1: Customers and Reservations • Basic business fact: customers make reservations. CPSC-4360-01, CPSC-5360-01, Lecture 3

  39. Defining a Relationship • Give a name to the relationship: • use a verb so that the relationship can be read as a sentence: • A customer can make many reservations. • How many people make a reservation? • one principal contact whose details are held; • that principal contact can make more than one reservation (e.g., by postponing the time); • the expected number of diners can be modelled as an attribute of the reservation. CPSC-4360-01, CPSC-5360-01, Lecture 3

  40. Case Study 1: Tables and Reservation • Is table number an attribute of ‘Reservation’? • Better modelled as a separate class: • tables exist even if there are no reservations; • other attributes of tables, e.g., size, can be stored. CPSC-4360-01, CPSC-5360-01, Lecture 3

  41. Use of Constraints • Not all domain properties can be shown graphically: • e.g., it should be impossible to double-book a table. • Constraints add information to models: • written in a note connected to the model element being constrained. CPSC-4360-01, CPSC-5360-01, Lecture 3

  42. Use of Generalization • A superclass can be used to show the properties shared by different types of booking. CPSC-4360-01, CPSC-5360-01, Lecture 3

  43. Correctness • How do we know when a domain model is complete? • we don't: there are lots of plausible models in most cases. • Domain modelling is not an end in itself, but a guide to further development. • Realizing use cases tests the domain model, and will usually lead to refinements. CPSC-4360-01, CPSC-5360-01, Lecture 3

More Related