430 likes | 449 Views
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.
E N D
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
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
Case Study 1: The Restaurant • Current system uses manual booking sheets. CPSC-4360-01, CPSC-5360-01, Lecture 3
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
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
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
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
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
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
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
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
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
System Case Study 1: Use Case Diagram • Show use cases, actors and who does what. CPSC-4360-01, CPSC-5360-01, Lecture 3
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
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
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
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
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
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
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
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
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
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
Case Study 1: Use Case Diagram (Revised) Display booking System CPSC-4360-01, CPSC-5360-01, Lecture 3
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
Actor Generalization Notation System CPSC-4360-01, CPSC-5360-01, Lecture 3
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
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
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
Case Study 1: Complete Use Case Diagram System CPSC-4360-01, CPSC-5360-01, Lecture 3
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
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
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
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
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
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
Case Study 1: Customers and Reservations • Basic business fact: customers make reservations. CPSC-4360-01, CPSC-5360-01, Lecture 3
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
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
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
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
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