Published on

object oriented analysis and design with the unified process

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 2. Objectives <ul><li>Explain how events can be used to identify use cases that define requirements </li></ul><ul><li>Identify and analyze events and resulting use cases </li></ul><ul><li>Explain how the concept of problem domain classes also defines requirements </li></ul><ul><li>Identify and analyze domain classes needed in the system </li></ul>
  2. 3. Objectives (continued) <ul><li>Read, interpret, and create a Unified Modeling Language (UML) domain model class diagram and design class diagram </li></ul><ul><li>Use a CRUD matrix to study the relationships between use cases and problem domain classes </li></ul>
  3. 4. Overview <ul><li>Objective: refine information gathered </li></ul><ul><li>Identify use cases and problem domain classes </li></ul><ul><li>Model problem domain classes with UML notation </li></ul><ul><li>Introduce use case modeling </li></ul>
  4. 5. Events and Use Cases <ul><li>Use case </li></ul><ul><ul><li>Activity the system carries out </li></ul></ul><ul><ul><li>Entry point into the modeling process </li></ul></ul><ul><li>Event decomposition: help identify use cases </li></ul><ul><li>Elementary business processes (EBPs) </li></ul><ul><ul><li>Basic unit of analysis </li></ul></ul><ul><ul><li>Initiated by event occurring at specific time and place </li></ul></ul><ul><ul><li>Discrete system response that adds business value </li></ul></ul>
  5. 6. Figure 5-1 Identifying Use Cases by Focusing on Users and their Goals
  6. 7. Event Decomposition <ul><li>Event decomposition </li></ul><ul><ul><li>Develops use cases based on system response to events </li></ul></ul><ul><ul><li>Perceives system as black box interfacing with external environment </li></ul></ul><ul><ul><li>Keeps focus on EBPs and business requirements </li></ul></ul><ul><li>Analysts delegated particular events to decompose </li></ul><ul><li>Result of the decomposition: </li></ul><ul><ul><li>List of use cases triggered by business events </li></ul></ul><ul><ul><li>Use cases at the right level of analysis </li></ul></ul>
  7. 8. Figure 5-2 Events Affecting a Charge Account Processing System that Lead to Use Cases
  8. 9. Types of Events <ul><li>External Events </li></ul><ul><ul><li>Occur outside the system </li></ul></ul><ul><ul><li>Usually caused by external agent </li></ul></ul><ul><li>Temporal Events </li></ul><ul><ul><li>Occurs when system reaches a point (deadline) in time </li></ul></ul><ul><li>State Events </li></ul><ul><ul><li>Asynchronous events responding to system trigger </li></ul></ul>
  9. 10. Figure 5-3 External Event Checklist
  10. 11. Figure 5-4 Temporal Event Checklist
  11. 12. Identifying Events <ul><li>Three rules of thumb </li></ul><ul><li>Distinguish events from prior conditions </li></ul><ul><ul><li>Can the transaction complete without interruption? </li></ul></ul><ul><ul><li>Is the system waiting for next transaction? </li></ul></ul><ul><li>Trace sequence of events initiated by external agent </li></ul><ul><ul><li>Isolate events that actually touch the system </li></ul></ul>
  12. 13. Figure 5-5 Temporal Event Checklist
  13. 14. Figure 5-6 The Sequence of “Transactions” for One Specific Customer Resulting in Many Events
  14. 15. Identifying Events (continued) <ul><li>Identify technology dependent events </li></ul><ul><ul><li>Example: logon depending on system controls </li></ul></ul><ul><li>Defer specifying technology dependent events </li></ul><ul><li>Perfect technology assumption: </li></ul><ul><ul><li>Separates technology dependent events from functional requirements </li></ul></ul><ul><ul><ul><li>Unlimited processing and storage capacity </li></ul></ul></ul><ul><ul><ul><li>Equipment does not malfunction </li></ul></ul></ul><ul><ul><ul><li>Users have ideal skill sets </li></ul></ul></ul>
  15. 16. Figure 5-7 Events Deferred until Later Iterations
  16. 17. Events in the Rocky Mountain Outfitters Case <ul><li>Developing list of external events </li></ul><ul><ul><li>Identify all people and organizational units that want something from the system </li></ul></ul><ul><li>Developing list of temporal events </li></ul><ul><ul><li>Identify regular reports and statements that system must produce at certain times </li></ul></ul>
  17. 18. Figure 5-8 External Events for the RMO Customer Support System
  18. 19. Figure 5-9 Temporal Events for the RMO Customer Support System
  19. 20. Looking At Each Event and the Resulting Use Case <ul><li>Enter use cases in an event table </li></ul><ul><li>Event table includes rows and columns </li></ul><ul><ul><li>Each row is a record linking an event to a use case </li></ul></ul><ul><ul><li>Columns represent key information   </li></ul></ul><ul><li>RMO event table anatomizes customer support system </li></ul>
  20. 21. Figure 5-10 Information about each Event and the Resulting Use Case in an Event Table
  21. 22. Figure 5-11 The Complete Event Table for the RMO Customer Support System
  22. 23. Problem Domain Classes <ul><li>Problem domain </li></ul><ul><ul><li>Set of work-related “things” in system component </li></ul></ul><ul><ul><ul><li>Things have data representation within system </li></ul></ul></ul><ul><ul><li>Examples: products, orders, invoices, customers </li></ul></ul><ul><li>OO approach to things in problem domain </li></ul><ul><ul><li>Objects that interact in the system </li></ul></ul><ul><li>Identify and understand things in problem domain </li></ul><ul><ul><li>Key initial steps in defining requirements </li></ul></ul>
  23. 24. Types of Things <ul><li>Things can be identified with methodology </li></ul><ul><li>Separate the tangible from the intangible </li></ul><ul><li>Include information from all types of users </li></ul><ul><li>Ask important questions about nature of event </li></ul><ul><ul><li>“ What actions upon things should be acknowledged and recorded by the system?” </li></ul></ul><ul><li>Example case: customer placing an order </li></ul>
  24. 25. Figure 5-12 Types of Things
  25. 26. Procedure for Developing an Initial List of Things <ul><li>List nouns users mention when discussing system </li></ul><ul><li>Event table as source of potential things </li></ul><ul><ul><li>Use cases, external agents, triggers, response   </li></ul></ul><ul><li>Select nouns with questions concerning relevance </li></ul><ul><ul><li>Further research may be needed </li></ul></ul>
  26. 27. Figure 5-13a Partial List of “Things” Based on Nouns for RMO
  27. 28. Figure 5-13b Partial List of “Things” Based on Nouns for RMO
  28. 29. Figure 5-13c Partial List of “Things” Based on Nouns for RMO
  29. 30.   Associations among Things <ul><li>Analyst document entity associations ( relationships) </li></ul><ul><ul><li>Example: “Is placed by” and “works in” </li></ul></ul><ul><li>Associations apply in two directions </li></ul><ul><ul><li>Customer places an order </li></ul></ul><ul><ul><li>An order is placed by a customer </li></ul></ul><ul><li>Multiplicity: the number of associations </li></ul><ul><ul><li>One to one or one to many  </li></ul></ul><ul><li>The associations between types of things </li></ul><ul><ul><li>Unary (recursive), binary, n-ary </li></ul></ul>
  30. 31. Figure 5-14 Associations Naturally Occur between Things
  31. 32. Figure 5-15 Multiplicity of Relationships
  32. 33. Attributes of Things <ul><li>Specific details of things are called attributes </li></ul><ul><li>Analyst should identify attributes of things </li></ul><ul><li>Identifier (key): attribute uniquely identifying thing </li></ul><ul><ul><li>Examples: Social Security number, vehicle ID number, or product ID number </li></ul></ul><ul><li>Compound attribute is a set of related attributes </li></ul><ul><ul><li>Example: multiple names for the same customer </li></ul></ul>
  33. 34. Figure 5-16 Attributes and Values
  34. 35. Classes and Objects <ul><li>Domain model class diagram as UML class </li></ul><ul><ul><li>OOA applies domain model class diagram to things </li></ul></ul><ul><li>Problem domain objects have attributes </li></ul><ul><li>Software objects encapsulate attributes and behaviors </li></ul><ul><ul><li>Behavior: action that the object processes itself </li></ul></ul><ul><li>Software objects communicate with messages </li></ul><ul><li>Information system is a set of interacting objects </li></ul>
  35. 36. Figure 5-17 Objects Encapsulate Attributes and Methods
  36. 37. Domain Model Class Diagram Notation <ul><li>Class diagram key </li></ul><ul><ul><li>General class symbol: rectangle with three sections </li></ul></ul><ul><ul><li>Sections convey name, attributes, and behaviors </li></ul></ul><ul><ul><li>Methods (behaviors) not shown in domain model class diagram </li></ul></ul><ul><ul><li>Lines connecting rectangles show associations </li></ul></ul><ul><ul><li>Multiplicity reflected above connecting lines </li></ul></ul><ul><li>Domain class objects reflect business concern, policies, and constraints </li></ul>
  37. 38. Figure 5-21 An Expanded Domain Model Class Diagram Showing Attributes
  38. 39. Figure 5-24 A Refined University Course Enrollment Domain Model Class Diagram With an Association Class
  39. 40. Hierarchies in Class Diagram Notation <ul><li>Generalization/specialization notation </li></ul><ul><ul><li>I nheritance hierarchy </li></ul></ul><ul><ul><li>Rank things the more general to the more special </li></ul></ul><ul><ul><ul><li>Motor vehicle class includes trucks, cars, buses </li></ul></ul></ul><ul><li>Classification: means of defining classes of things </li></ul><ul><ul><li>Superclass: generalization of a class </li></ul></ul><ul><ul><li>Subclass: specialization of a class </li></ul></ul>
  40. 41. Figure 5-25 A Generalization/Specialization Hierarchy Notation for Motor Vehicles
  41. 42. Hierarchies in Class Diagram Notation (continued) <ul><li>Whole-part Hierarchy Notation </li></ul><ul><ul><li>“ The whole is equal to the sum of the parts” </li></ul></ul><ul><li>Two types of whole-part hierarchies </li></ul><ul><ul><li>Aggregation: association with independent parts </li></ul></ul><ul><ul><ul><li>Example: keyboard is part of computer system </li></ul></ul></ul><ul><ul><li>Composition: association with dependent part </li></ul></ul><ul><ul><ul><li>Example: CRT and monitor </li></ul></ul></ul><ul><li>Multiplicity applies to whole-part relationships </li></ul>
  42. 43. Figure 5-27 Whole-part (Aggregation) Associations Between a Computer and Its Parts
  43. 44. Hierarchies in Class Diagram Notation (continued) <ul><li>Design Class Diagrams </li></ul><ul><ul><li>Models classes into precise software analogs </li></ul></ul><ul><ul><li>Includes domain class information plus methods </li></ul></ul><ul><ul><li>Triangle symbol between classes indicates inheritance </li></ul></ul><ul><ul><li>Properties of attributes are shown with curly braces </li></ul></ul><ul><li>Class fundamentals </li></ul><ul><ul><li>Instances of a class (objects) manage their own data </li></ul></ul><ul><ul><li>Abstract classes are not instantiated (created) </li></ul></ul><ul><ul><li>Subclasses inherit attributes/behaviors from superclass </li></ul></ul>
  44. 45. Figure 5-29 University Course Enrollment Design Class Diagram (With Methods)
  45. 46. The Rocky Mountain Outfitters Domain Class Diagram <ul><li>Derives from noun list developed in Figure 5-13 </li></ul><ul><li>RMO domain class diagram shows attribute </li></ul><ul><li>Models do not show methods </li></ul><ul><li>Problem domain classes reflect high-level view of RMO use cases </li></ul>
  46. 47. Figure 5-31 Rocky Mountain Outfitters Domain Model Class Diagram
  47. 48. Locations and the Crud Matrix <ul><li>Location diagrams store data for future reference </li></ul><ul><ul><li>Shows need for network connections </li></ul></ul><ul><ul><li>Creates awareness of geographic reach </li></ul></ul><ul><li>Use case–location matrix: shows where use cases are performed </li></ul><ul><li>Use case–domain class matrix: highlights access requirements  </li></ul><ul><ul><li>Example: The RMO CRUD (create, read, update, and delete) </li></ul></ul>
  48. 49. Figure 5-32 Rocky Mountain Outfitters Location Diagram
  49. 50. Figure 5-33a Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System
  50. 51. Figure 5-33b Use Case–location Matrix for the Rocky Mountain Outfitters Customer Support System
  51. 52. Use Cases, the Domain Model, and Iteration Planning <ul><li>Select use cases for further development </li></ul><ul><ul><li>Identify risks to determine priority </li></ul></ul><ul><ul><li>Core architecture typically selected/implemented first </li></ul></ul><ul><li>Transition into elaboration phase </li></ul><ul><ul><li>Converting use cases into software </li></ul></ul><ul><ul><li>Iteratively integrate software components into more complex systems </li></ul></ul><ul><ul><li>Begin testing of software </li></ul></ul>
  52. 53. Summary <ul><li>Requirements discipline defines business functions </li></ul><ul><li>Key concepts: use cases and problem domain classes </li></ul><ul><li>Use cases derive from elementary business processes (EBPs) </li></ul><ul><li>Three event types: external, temporal, and state </li></ul><ul><li>Problem domain class: category based on OOA </li></ul>
  53. 54. Summary (continued) <ul><li>Multiple associations among classes </li></ul><ul><li>Attributes: specific information about a thing </li></ul><ul><li>Actual software classes include behaviors (methods) and attributes </li></ul><ul><li>UML class diagrams show classes, attributes, methods, and associations </li></ul><ul><li>Domain model class diagram show domain classes in the users’ work environment </li></ul>
  54. 55. Summary (continued) <ul><li>Design class diagram models software classes   </li></ul><ul><li>Generalization/specialization hierarchies allow inheritance from a superclass to a subclass </li></ul><ul><li>Whole-part hierarchies allow a collection of objects to be associated as a whole and its parts </li></ul><ul><li>Requirements are also defined with location diagrams, and matrices </li></ul>