1 / 55

Events and Use Cases: Identifying Requirements in Object-Oriented Analysis

Learn how events can be used to identify use cases and define requirements in Object-Oriented Analysis. Explore the concept of problem domain classes and their role in requirement definition. Use event decomposition and domain modeling techniques to analyze and model system requirements.

rellison
Download Presentation

Events and Use Cases: Identifying Requirements in Object-Oriented Analysis

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. Objectives • Explain how events can be used to identify use cases that define requirements • Identify and analyze events and resulting use cases • Explain how the concept of problem domain classes also defines requirements • Identify and analyze domain classes needed in the system Object-Oriented Analysis and Design with the Unified Process

  2. Objectives (continued) • Read, interpret, and create a Unified Modeling Language (UML) domain model class diagram and design class diagram • Use a CRUD matrix to study the relationships between use cases and problem domain classes Object-Oriented Analysis and Design with the Unified Process

  3. Overview • Objective: refine information gathered • Identify use cases and problem domain classes • Model problem domain classes with UML notation • Introduce use case modeling Object-Oriented Analysis and Design with the Unified Process

  4. Events and Use Cases • Use case • Activity the system carries out • Entry point into the modeling process • Event decomposition: help identify use cases • Elementary business processes (EBPs) • Basic unit of analysis • Initiated by event occurring at specific time and place • Discrete system response that adds business value Object-Oriented Analysis and Design with the Unified Process

  5. Figure 5-1 Identifying Use Cases by Focusing on Users and their Goals Object-Oriented Analysis and Design with the Unified Process

  6. Event Decomposition • Event decomposition • Develops use cases based on system response to events • Perceives system as black box interfacing with external environment • Keeps focus on EBPs and business requirements • Analysts delegated particular events to decompose • Result of the decomposition: • List of use cases triggered by business events • Use cases at the right level of analysis Object-Oriented Analysis and Design with the Unified Process

  7. Figure 5-2 Events Affecting a Charge Account Processing System that Lead to Use Cases Object-Oriented Analysis and Design with the Unified Process

  8. Types of Events • External Events • Occur outside the system • Usually caused by external agent • Temporal Events • Occurs when system reaches a point (deadline) in time • State Events • Asynchronous events responding to system trigger Object-Oriented Analysis and Design with the Unified Process

  9. Figure 5-3 External Event Checklist Object-Oriented Analysis and Design with the Unified Process

  10. Figure 5-4 Temporal Event Checklist Object-Oriented Analysis and Design with the Unified Process

  11. Identifying Events • Three rules of thumb • Distinguish events from prior conditions • Can the transaction complete without interruption? • Is the system waiting for next transaction? • Trace sequence of events initiated by external agent • Isolate events that actually touch the system Object-Oriented Analysis and Design with the Unified Process

  12. Figure 5-5 Temporal Event Checklist Object-Oriented Analysis and Design with the Unified Process

  13. Figure 5-6 The Sequence of “Transactions” for One Specific Customer Resulting in Many Events Object-Oriented Analysis and Design with the Unified Process

  14. Identifying Events (continued) • Identify technology dependent events • Example: logon depending on system controls • Defer specifying technology dependent events • Perfect technology assumption: • Separates technology dependent events from functional requirements • Unlimited processing and storage capacity • Equipment does not malfunction • Users have ideal skill sets Object-Oriented Analysis and Design with the Unified Process

  15. Figure 5-7 Events Deferred until Later Iterations Object-Oriented Analysis and Design with the Unified Process

  16. Events in the Rocky Mountain Outfitters Case • Developing list of external events • Identify all people and organizational units that want something from the system • Developing list of temporal events • Identify regular reports and statements that system must produce at certain times Object-Oriented Analysis and Design with the Unified Process

  17. Figure 5-8 External Events for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

  18. Figure 5-9 Temporal Events for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

  19. Looking At Each Event and the Resulting Use Case • Enter use cases in an event table • Event table includes rows and columns • Each row is a record linking an event to a use case • Columns represent key information   • RMO event table anatomizes customer support system Object-Oriented Analysis and Design with the Unified Process

  20. Figure 5-10 Information about each Event and the Resulting Use Case in an Event Table Object-Oriented Analysis and Design with the Unified Process

  21. Figure 5-11 The Complete Event Table for the RMO Customer Support System Object-Oriented Analysis and Design with the Unified Process

  22. Problem Domain Classes • Problem domain • Set of work-related “things” in system component • Things have data representation within system • Examples: products, orders, invoices, customers • OO approach to things in problem domain • Objects that interact in the system • Identify and understand things in problem domain • Key initial steps in defining requirements Object-Oriented Analysis and Design with the Unified Process

  23. Types of Things • Things can be identified with methodology • Separate the tangible from the intangible • Include information from all types of users • Ask important questions about nature of event • “What actions upon things should be acknowledged and recorded by the system?” • Example case: customer placing an order Object-Oriented Analysis and Design with the Unified Process

  24. Figure 5-12 Types of Things Object-Oriented Analysis and Design with the Unified Process

  25. Procedure for Developing an Initial List of Things • List nounsusers mention when discussing system • Event table as source of potential things • Use cases, external agents, triggers, response • Select nouns with questions concerning relevance • Further research may be needed Object-Oriented Analysis and Design with the Unified Process

  26. Figure 5-13a Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

  27. Figure 5-13b Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

  28. Figure 5-13c Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

  29. Associations among Things • Analyst document entity associations ( relationships) • Example: “Is placed by” and “works in” • Associations apply in two directions • Customer places an order • An order is placed by a customer • Multiplicity: the number of associations • One to one or one to many  • The associations between types of things • Unary (recursive), binary, n-ary Object-Oriented Analysis and Design with the Unified Process

  30. Figure 5-14 Associations Naturally Occur between Things Object-Oriented Analysis and Design with the Unified Process

  31. Figure 5-15 Multiplicity of Relationships Object-Oriented Analysis and Design with the Unified Process

  32. Attributes of Things • Specific details of things are called attributes • Analyst should identify attributes of things • Identifier (key): attribute uniquely identifying thing • Examples: Social Security number, vehicle ID number, or product ID number • Compound attribute is a set of related attributes • Example: multiple names for the same customer Object-Oriented Analysis and Design with the Unified Process

  33. Figure 5-16 Attributes and Values Object-Oriented Analysis and Design with the Unified Process

  34. Classes and Objects • Domain model class diagram as UML class • OOA applies domain model class diagram to things • Problem domain objects have attributes • Software objects encapsulate attributes and behaviors • Behavior: action that the object processes itself • Software objects communicate with messages • Information system is a set of interacting objects Object-Oriented Analysis and Design with the Unified Process

  35. Figure 5-17 Objects Encapsulate Attributes and Methods Object-Oriented Analysis and Design with the Unified Process

  36. Domain Model Class Diagram Notation • Class diagram key • General class symbol: rectangle with three sections • Sections convey name, attributes, and behaviors • Methods (behaviors) not shown in domain model class diagram • Lines connecting rectangles show associations • Multiplicity reflected above connecting lines • Domain class objects reflect business concern, policies, and constraints Object-Oriented Analysis and Design with the Unified Process

  37. Figure 5-21 An Expanded Domain Model Class Diagram Showing Attributes Object-Oriented Analysis and Design with the Unified Process

  38. Figure 5-24 A Refined University Course Enrollment Domain Model Class Diagram With an Association Class Object-Oriented Analysis and Design with the Unified Process

  39. Hierarchies in Class Diagram Notation • Generalization/specialization notation • Inheritance hierarchy • Rank things the more general to the more special • Motor vehicle class includes trucks, cars, buses • Classification: means of defining classes of things • Superclass: generalization of a class • Subclass: specialization of a class Object-Oriented Analysis and Design with the Unified Process

  40. Figure 5-25 A Generalization/Specialization Hierarchy Notation for Motor Vehicles Object-Oriented Analysis and Design with the Unified Process

  41. Hierarchies in Class Diagram Notation (continued) • Whole-part Hierarchy Notation • “The whole is equal to the sum of the parts” • Two types of whole-part hierarchies • Aggregation: association with independent parts • Example: keyboard is part of computer system • Composition: association with dependent part • Example: CRT and monitor • Multiplicity applies to whole-part relationships Object-Oriented Analysis and Design with the Unified Process

  42. Figure 5-27 Whole-part (Aggregation) Associations Between a Computer and Its Parts Object-Oriented Analysis and Design with the Unified Process

  43. Hierarchies in Class Diagram Notation (continued) • Design Class Diagrams • Models classes into precise software analogs • Includes domain class information plus methods • Triangle symbol between classes indicates inheritance • Properties of attributes are shown with curly braces • Class fundamentals • Instances of a class (objects) manage their own data • Abstract classes are not instantiated (created) • Subclasses inherit attributes/behaviors from superclass Object-Oriented Analysis and Design with the Unified Process

  44. Figure 5-29 University Course Enrollment Design Class Diagram (With Methods) Object-Oriented Analysis and Design with the Unified Process

  45. The Rocky Mountain Outfitters Domain Class Diagram • Derives from noun list developed in Figure 5-13 • RMO domain class diagram shows attribute • Models do not show methods • Problem domain classes reflect high-level view of RMO use cases Object-Oriented Analysis and Design with the Unified Process

  46. Figure 5-31 Rocky Mountain Outfitters Domain Model Class Diagram Object-Oriented Analysis and Design with the Unified Process

  47. Locations and the Crud Matrix • Location diagrams store data for future reference • Shows need for network connections • Creates awareness of geographic reach • Use case–location matrix: shows where use cases are performed • Use case–domain class matrix: highlights access requirements  • Example: The RMO CRUD (create, read, update, and delete) Object-Oriented Analysis and Design with the Unified Process

  48. Figure 5-32 Rocky Mountain Outfitters Location Diagram Object-Oriented Analysis and Design with the Unified Process

  49. Figure 5-33a Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System Object-Oriented Analysis and Design with the Unified Process

More Related