1 / 129

5. Analysis

5. Analysis. Outline. Analysis: Bridging What to How Models for Analysis Activities during object modeling Object Identifications Identify Associations Identify Aggregates Identify Attributes Reviewing the Analysis Model Managing Analysis Case Study. 1. Analysis: Bridging What to How.

matana
Download Presentation

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

  2. Outline • Analysis: Bridging What to How • Models for Analysis • Activities during object modeling • Object Identifications • Identify Associations • Identify Aggregates • Identify Attributes • Reviewing the Analysis Model • Managing Analysis • Case Study

  3. 1. Analysis: Bridging What to How Do the right things Do the things right Analysis How What

  4. 2. Models for Analysis

  5. 2.1 Reality and Model • Reality R: Real Things, People, Processes happening during some time, Relationship between things • Model M: Abstractions from (really existing or only thought of ) things, people , processes and relationships between these abstractions.

  6. 2.2 Why models? • We use models • To abstract away from details in the reality, so we can draw complicated conclusions in the reality with simple steps in the model • To get insights into the past or presence • To make predictions about the future

  7. 2.3 What is a “good” model? • Relationships, which are valid in reality R, are also valid in model M. • I : Mapping of real things in reality R to abstractions in the model M abbildet (Interpretation) • fM: relationship between abstractions in M • fR: relationship between real things in R • In a good model the following diagram is commutative: [It preserves relationships among the objects it represents.] fM M M I I R R fR

  8. …. fM2 M2 M2 Analysis I2 fM1 M1 M1 Requirements Elicitation I1 R R fR 2.4 Models of models of models... • Modeling is relative. We can think of a model as reality and can build another model from it (with additional abstractions). The developmentof Software-Systems is a Transformation of Models: Analysis, Design, Implementation,Testing

  9. use case class statechart sequence diagram:View diagram:View diagram:View diagram:View functional object dynamic model:Model model:Model model:Model analysis model:Model 2.5 Analysis Model • It is composed of three individual models: • Functional model: user cases and scenarios • Analysis object model: class and object diagrams • Dynamic model: state machine and sequence diagrams

  10. Requirements elicitation Analysis Products of requirements elicitation and analysis. Requirements Specification nonfunctional requirements functional model Analysis Model dynamic model analysis object model System design Object design

  11. TimeZoneDatabase UniversalTime TimeZone GPSLocator UserId Location • Analysis models represent user-level concepts, not actual software classes or components • Classes such as Database, Subsystem, SessionManager, Network should not appear in the analysis model Domain concepts that should be representedin the analysis object model. Software classes that should not be representedin the analysis object model. Refers to how time zones are stored (design decision). Denotes to how location is measured (design decision). Refers to an internal mechanism for identifying users (design decision)

  12. 3. Analysis Activities

  13. Analysis Activities • Main goal: Find the important abstractions • Steps during object modeling 1. Object identification Identifying Entity Objects Identifying Boundary Object Identifying Control Objects 2. Mapping Use Cases to Objects with Sequence Diagrams 3. Modeling Interactions among Objects with CRC Cards 4. Identifying Associations, Aggregates and Attributes 5. Modeling State-Dependent Behavior of Individual Objects 6. Modeling Inheritance Relationships 7. Reviewing • Order of steps • Goal: get the desired abstractions • Order of steps secondary, only a heuristic • Iteration is important

  14. 3.1 Object Identifications

  15. 3.1.1 Object Identification • Identify the boundaries of the system • Identify the important entities in the system • Object identification is crucial to object-oriented modeling • Basic assumption: 1. We can find the objects for a new software system (Forward Engineering) 2. We can identify the objects in an existing system (Reverse Engineering)

  16. Object identification is an ancient problem • Objects are not just found by taking a picture of a scene or domain • The application domain has to be analyzed. • Depending on the purpose of the system different objects might be found • How can we identify the purpose of a system? • Scenarios and use cases • Another important problem: Define system boundary. • What object is inside, what object is outside?

  17. 3.1.2 Pieces of an Object Model • Classes • Associations (Relations) • Generic associations • Canonical(规范)associations • Part of- Hierarchy (Aggregation) • Kind of-Hierarchy (Generalization) • Attributes • Detection of attributes • Application specific • Attributes in one system can be classes in another system • Turning attributes to classes • Operations • Detection of operations • Generic operations: Get/Set, General world knowledge, design patterns • Domain[-specific] operations: Dynamic model, Functional model

  18. 3.1.3 Object Types • Entity Objects • Represent the persistent information tracked by the system (Application domain objects, “Business objects”) • Boundary Objects • Represent the interaction between the user and the system • Control Objects: • Represent the control tasks performed by the system • Object types originated in Smalltalk: • Model, View, Controller (MVC)

  19. Having three types of objects leads to models that are more resilient to change. • What types of objects are more resilient to change? • Both interface and control of the system are more likely to change than the application domain [model] • Paradox: The static information model from analysis is more stable, yet the designed representation is most likely to change[implementation] • David Parnas invented the Information Hiding Principle and recommended encapsulation of data structures for this reason. [References: D.L.Parnas: ‘On the Criteria for Decomposing Programs into modules’ and “TBD” CACM 5/72 and 12/72]

  20. 3.1.4 How do you find objects? • Finding objects is the central piece in object modeling • Learn about problem domain: Observe your client • Apply general world knowledge and intuition • Take the flow of events and find participating objects in use cases • Try to establish a taxonomy [inheritance discovery] • Apply design knowledge: • Distinguish different types of objects [recognition/discrimination] • Apply design patterns (Lecture on design patterns – Chapter 8 ) • Do a syntactic analysis of problem statement, scenario or flow of events • Abbott Textual Analysis, 1983, also called noun-verb analysis • Nouns are good candidates for classes • Verbs are good candidates for operations

  21. Finding Participating Objects in Use Cases • Pick a use case and look at its flow of events • Find terms that developers or users need to clarify in order to understand the flow of events • Look for recurring nouns (e.g., Incident), • Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource), • Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan), • Identify data sources or sinks (e.g., Printer) • Identify interface artifacts (e.g., PoliceStation) [e.g., telecomm link?] • Be prepared that some objects are still missing and need to be found: • Model the flow of events with a sequence diagram • Always use the user’s terms

  22. Example: Flow of events • The customer enters a store with the intention of buying a toy for his child with the age of n. • Help must be available within less than one minute. • The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. • The customer selects a dangerous toy which is kind of unsuitable for the child. • The store owner recommends a more yellow doll.

  23. Mapping parts of speech to object model components [Abbott, 1983] Part of speech Model component? * Example Proper noun Jim Smith ? ? ? ? ? ? ? ? ? Improper noun Toy, doll Doing verb Buy, recommend being verb is-a (kind-of) having verb has an modal verb must be adjective 3 years old transitive verb enter intransitive verb depends on

  24. Mapping parts of speech to object model components [Abbott, 1983] Part of speech Model component? * Example Proper noun Jim Smith ? ? ? ? ? ? ? ? ? Improper noun Toy, doll Doing verb Buy, recommend being verb is-a (kind-of) having verb has an modal verb must be adjective 3 years old transitive verb enter intransitive verb depends on * {aggregation|attribute|class|constraint|inheritance|method|method(event)|object?} - RJL

  25. Mapping parts of speech to object model components [Abbott, 1983] Part of speech Model component Example Proper noun object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

  26. store enter() ? enter() daughter daughter age suitable * toy buy() toy boardgame videogame Generation of a classdiagramfromflowofevents Customer Flow ofevents: customer enters store buy • The customerentersthestoretobuy a toy. Ithastobe a toythathisdaughterlikesandit must costlessthan 50 Euro. He tries a videogame, whichuses a datagloveand a head-mounteddisplay. He likes it. toy daughter videogame lessthan 50 Euro An assistanthelpshim. The suitabilityofthegamedepends on theageofthechild. His daughterisonly 3 yearsold. The assistantrecommendsanother type oftoy, namely a boardgame. The customerbuythegameandleavesthestore depends age toy price buy() like() type oftoy boardgame

  27. ReportEmergencyuse case flow of events

  28. Abbott’s technique for mapping parts of speech to model components

  29. (1) Heuristics for identifying entity objects • Terms that developers or users need to clarify in order to understand the use case • Recurring nouns in the user cases (e.g., Incident) • Real-world entities that the system needs to track (e.g., FieldOfficer, Dispatcher, Resource) • Real-world activities that the system need to track (e.g, EmergencyOperationsPlan) • Data sources or sinks (e.g, Printer)

  30. (2) Heuristics for Identifying boundary objects • Identify user interface controls that the user needs to initiate the use case (e.g., ReportEmergencyButton) • Identify forms the users needs to enter data into the system (e.g., EmergencyReportForm) • Identify notices and messages the system uses to respond to the user (e.g., AcknowledgementNotice) • When multiple actors are involved in a use case, identify actor terminals to refer to the user interface under consideration (e.g., DispatcherStation)

  31. (3) Heuristics for Identifying control objects • Identify one control object per use case • Identify one control object per actor in the use case • The life span of a control object should cover the extent of the use case or the extent of a user session

  32. Example: 2BWatch Objects Button Year ChangeDate Month LCDDisplay Day Entity Objects Control Objects Interface Objects

  33. Naming of Object Types in UML • UML provides several mechanisms to extend the language • UML provides the stereotype mechanism to present new modeling elements <<Boundary>> Button <<Entity>> Year <<Control>> ChangeDate <<Entitity>> Month <<Boundary>> LCDDisplay <<Entity>> Day Entity Objects Control Objects Boundary Objects

  34. 3.2 Mapping Use Cases to Objects with Sequence Diagrams • From the flow of events in the use case or scenario, proceed to the sequence diagram • A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (directed acyclic graph) notation • Relation to object identification: • Objects/classes have already been identified during object modeling • Objects are identified as a result of dynamic modeling • Heuristic: • An event always has a sender and a receiver. • The representation of the event is sometimes called a message • Find sender and receiver for each event => These are the objects participating in the use case

  35. Report Manage EmergencyButton EmergencyControl ReportEmergencyControl ReportEmergency Form Sequence diagram for the ReportEmergency use case. FieldOfficer press() «create» «create» fillContents() submit() submitReport() «create» Emergency Report submitReportToDispatcher() «destroy»

  36. Manage EmergencyControl Dispatcher IncidentForm Incident Acknowledgment submitReportToDispatcher() «create» createIncident() «create» submit() «create» «destroy»

  37. ReportEmergency Control Acknowledgment Notice Manage FieldOfficer EmergencyControl acknowledgeReport() «create» dismiss() endReportTransaction() «destroy» «destroy»

  38. Heuristics for Sequence Diagrams • Layout: • 1st column: Should correspond to the actor who initiated the use case • 2nd column: Should be a boundary object • 3rd column: Should be the control object that manages the rest of the use case • Creation: • Control objects are created at the initiation of a use case • Boundary objects are created by control objects • Access: • Entity objects are accessed by control and boundary objects, • Entity objects should never call boundary or control objects: This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects.

  39. :Tournament :Arena :League Boundary League Owner newTournament (league) :Announce «new» Tournament Control checkMax Tournament() setName(name) setMaxPlayers (maxp) create Tournament (name, maxp) commit() createTournament (name, maxp) «new» :Tournament An ARENA Sequence Diagram : Create Tournament

  40. Impact on ARENA’s Object Model • Let’s assume, before we formulated the previous sequence diagram, ARENA’s object model contained the objects • League Owner, Arena, League, Tournament, Match and Player • The Sequence Diagram identified new Classes • Tournament Boundary, Announce_Tournament_Control

  41. League Owner League 1 * Attributes Attributes Operations Operations Tournament Attributes Operations Player Match * * Attributes Attributes Operations Operations

  42. Tournament_ Boundary Announce_ Tournament_ Control Attributes Operations Attributes Operations League Owner League 1 * Attributes Attributes Operations Operations Tournament Attributes Operations Player Match * * Attributes Attributes Operations Operations

  43. Impact on ARENA’s Object Model (ctd) • The Sequence Diagram also supplied us with a lot of new events • newTournament(league) • setName(name) • setMaxPlayers(max) • Commit • checkMaxTournaments() • createTournament • Question: Who owns these events? • Answer: For each object that receives an event [and each incoming event?] there is a public operation in the associated class. • The name of the operation is usually the name of the event. • [Complex transactions may have sub-diagrams and internal events]

  44. :Tournament :Arena :League Boundary League Owner newTournament (league) :Announce «new» Tournament Control checkMax Tournament() setName(name) setMaxPlayers (maxp) create Tournament (name, maxp) commit() «new» :Tournament Example from the Sequence Diagram createTournament is a (public) operation owned by Announce_Tournament_Control createTournament (name, maxp)

  45. Tournament_ Boundary Attributes Operations League Owner League 1 * Attributes Attributes Operations Operations Tournament Announce_ Tournament_ Control Attributes Operations Attributes createTournament (name, maxp) Player Match * * Attributes Attributes Operations Operations

  46. What else can we get out of sequence diagrams? • Sequence diagrams are derived from the use cases. We therefore see the [temporal] structure of the use cases. • The structure of the sequence diagram helps us to determine how decentralized the system is. • We distinguish two structures for sequence diagrams: Fork and Stair Diagrams (Ivar Jacobsen)

  47. Fork Diagram • Much of the dynamic behavior is placed in a single object, usually the control object. It knows all the other objects and often uses them for direct questions and commands.

  48. Stair Diagram • The dynamic behavior is distributed. Each object delegates some responsibility to other objects. Each object knows only a few of the other objects and knows which objects can help with a specific behavior.

  49. Fork or Stair? • Which of these diagram types should be chosen? • Object-oriented fans claim that the stair structure is better • The more the responsibility is spread out, the better • However, this is not always true. Better heuristics: • Decentralized control structure • The operations have a strong connection • The operations will always be performed in the same order • Centralized control structure (better support of change) • The operations can change order • New operations can be inserted as a result of new requirements

  50. 3.3 Modeling Interactions among objects with CRC cards • CRC: Class, Responsibilities, and Collaborators

More Related