Object Oriented Analysis

1. Object Oriented Analysis Lectures 12 & 13

2. References • Chapter 4: Requirements Elicitation from Object Oriented Software Engineering: Conquering Complex and Changing Systems. • Chapter 5: Analysis from Object Oriented Software Engineering: Conquering Complex and Changing Systems.

3. Identifying Initial Analysis Objects • After consolidating the use cases, developers can identify the participating objects for each use case. • Participating objects correspond to the main concepts in the application domain. • Developers identify, name and describe these participating objects unambiguously and collate them into a glossary.

4. Identifying Initial Analysis Objects (Contd.) • The identification of participating objects results in the initial analysis model that is later transformed into the complete analysis model. • The description of the participating objects and their attributes are visible to the user for review.

5. Heuristics for Identifying Initial Analysis Objects • Terms that developers or users need to clarify in order to understand the use case. • Recurring nouns in the use cases(e.g., Incident) • Real-world entities that the system needs to keep track of(e.g., FieldOfficer, Resource). • Real-world processes that the system needs to keep track of (e.g., EmergencyOperationsPlan)

6. Heuristics for Identifying Initial Analysis Objects(Contd.) • Use cases (e.g., ReportEmergency). • Data sources or sinks (e.g. ,Printer). • Interface artifacts (e.g., Station). • Always use application domain terms.

7. Correspondence Between Use Cases and Participating Objects • During requirements elicitation, participating objects are generated for each use case. • If two use cases refer to the same concept, the corresponding objects should be the same. • If two objects share the same name and do not correspond to the same concept, one or both concepts are renamed to acknowledge and emphasize the difference.

8. Correspondence between Use Cases and Participating Objects (Contd.) • Above mentioned consolidation eliminates any ambiguity in the terminology used. • Once participating objects are identified and consolidated, the developers can use them to ensure that the set of identified use cases is complete.

9. Heuristics for Cross Checking Use Cases and Participating Objects • Which use cases create this object (i.e., during which use case are the values of the object attributes entered in the system)? Which actors can access this information? • Which use cases modify and destroy this object (i.e., which use cases edit or remove this information from the system)? Which actor can initiate these use cases? • Is this object needed (i.e., is there at least one use case that depends on this info)?

10. Example: Participating objects for the ReportEmergency Use Case

11. Example: Participating Objects for the ReportEmergency Use Case (Contd.)

12. Why Analyze • Analysis results in a model of the system that aims to be correct, complete, consistent and verifiable. • System specifications produced during requirements elicitation are formalized and examined in more detailed boundary conditions and exceptional cases. • System specifications are corrected and clarified if errors or ambiguities are detected. • User involvement is considered necessary when the system specifications need to be changed and additional information needs to be collected.

13. Why Analyze (Contd.) • Typically object oriented analysis helps build a model of the application domain. • Analysis models along with the non-functional requirements are transformed into high level design of the system. • Formalization helps identify areas of ambiguity as well as inconsistencies and omissions in a system specification.

14. Why Analyze (Contd.) • Problems in specifications can only be resolved by eliciting more information from users. • Requirements elicitation and analysis are iterative and incremental activities occurring concurrently.

15. Analysis Model • Analysis model consists of the functional model, the analysis object model and the dynamic model. • Functional Model • Represented by use cases and scenarios. • Analysis Object Model • Represented by class and object diagrams. • Dynamic Model • Represented by state charts and sequence diagrams.

16. Entity, Boundary and Control Objects • Entity Objects • Represent the persistent information tracked by the system. • E.g., in a clock, Time is a Entity Object. • Boundary Objects • Represent the objects that assist in interactions between the actors and the system. • E.g., in a clock Keypad or LCDDisplay are boundary objects. • Control Objects • Represent the objects that support tasks performed by the user and supported by the system. • E.g., in a clock, TimeProcessor is a control object.

17. Distinguishing Between Different Types of Objects • Stereotypes attach meta information to modeling elements. • Naming conventions for clarity • Distinction on a syntactical basis • E.g., append Boundary to the names of boundary objects. • Naming conventions assist in distinction even when stereotypes are not available.

18. Analysis Classes for a Clock <<entity>> Time <<boundary>> LCDDisplayBoundary <<control>> TimeProcesor <<boundary>> KeypadBoundary

19. Association and Multiplicity • Association is a relationship between classes. • Multiplicity indicates the number of links that can legitimately originate from an instance of the class connected to the associated ends. • E.g., an aircraft has two engines. 1 2 Aircraft Engine owner property

20. Types of Associations • One to One Association • Has a multiplicity of one on each end. • A one to one association between two classes suggests that exactly one link exists between instances of each class. • One to Many Association • Has a multiplicity of one on one end and 0…n (also represented by a star)or 1…n on the other. • Represents links between an instance of one class with many instances of the other class.

21. Types of Associations (Contd.) • Many to Many Association • Has a multiplicity 0…n or 1…n on both ends. • Represents an arbitrary number of links between instances of two classes. • More complex to implement than the other two types of associations.

22. Analysis Activities: From Use Cases to Objects • Identify entity objects. • Identify boundary objects. • Identify control objects. • Map use cases to objects. • Identify associations among objects. • Identify object attributes. • Model non trivial behavior with state charts. • Model generalization relationships. • Review analysis model.

23. Identification of Entity Objects • Natural language analysis is an intuitive set of heuristics for identifying objects, attributes and associations from a system specification. • Natural language analysis maps parts of speech (eg, nouns, verbs, adjectives, etc.) to components of the model (eg, objects, operations, inheritance relationships and classes). • Natural language analysis focuses on user’s terms.

24. Identification of Entity Objects (Contd.) • Limitations • Quality of the object model depends highly on the style of writing of the analyst (e.g., consistency of the terms used, verbification of the nouns). • Natural language is an imprecise tool and an object model derived literally from text risks being imprecise. • Requires rephrasing and clarification of system specifications as objects, operations and attributes are identified and standardized. • Sorting through all the nouns for a large system specification is a time consuming activity. • Abbott’s heuristics work well for generating a list of initial candidate objects from short descriptions.

25. Heuristics to be Used in Conjunction with Abbott’s Rules • Terms that developers or users need to clarify in order to understand the use case. • Recurring nouns in the use cases(e.g., Incident). • Real-world entities that the system needs to keep track of(e.g., FieldOfficer, Dispatcher, Resource). • Real-world activities that the system needs to keep track of(e.g., EmergencyOperationsPlan) • Use cases (e.g., ReportEmergency) • Data sources or sinks (e.g. ,Printer) • Always use the user’s terms.

26. Naming and Describing Objects • Developers name and briefly describe objects, their attributes and their responsibilities. • Uniquely naming objects promotes a standard terminology. • Brief description of objects allows developers to clarify concepts they use and to avoid misunderstandings. • A stable analysis model should contain a suitably detailed description of each object.

27. Example: ReportEmergency

28. Example: ReportEmergency (Contd.)

29. Dispatcher FieldOfficer Police officer who manages Incidents. A Dispatcher opens, documents, and closes Incidents in response to EmergencyReports and other communication with FieldOfficers. They are identified by badge numbers. Police or fire officer on duty. A FieldOfficer can be allocated to, at most, one Incident at a time. They are identified by badge numbers. Entity Objects for ReportEmergency Use Case

30. Emergency Report Incident Initial report about an Incident from a FieldOfficer to a Dispatcher. An EmergencyReport usually triggers the creation of an Incident by the Dispatcher. It is composed of a level, type, location and description. Situation requiring attention form a FieldOfficer. It may be reported by a FieldOfficer or anybody else external to the system. It contains a description, a response, a status, a location and a number of FieldOfficers. Entity Objects for ReportEmergency Use Case (Contd.)

31. Identification of Boundary Objects • Boundary objects represent the system interface with actors. • In each use case, each actor interacts with at least one boundary object. • Boundary objects collect information from actors and translate it into an interface neutral form useful for both entity and control objects. • Boundary objects model the user interface at a coarse level without describing its detailed visual aspects. • Detailed design of user interface continues to evolve as a consequence of usability tests even after the specification of the system have stabilized.

32. Heuristics for Identifying Boundary Objects • Identify forms and windows the users need to enter data into the system(e.g., Emergency ReportForm, ReportEmergencyButton). • Identify notices and messages the system uses to respond to the user(e.g., AcknowledgementNotice). • Do not model the visual aspects of the interface with boundary objects (user mock-ups are better suited for that). • Always use the user’s terms for describing interfaces as opposed to terms from the implementation technology.

33. Acknowledgement Notice DispatcherStation ReportEmergency Button Notice used for displaying Dispatcher’s acknowledgement to the FieldOfficer. Computer used by the Dispatcher. Button used by a FieldOffier to initiate the ReportEmergency use case Example: Boundary Objects for ReportEmergency Use Case

34. Emergency ReportForm FieldOfficer Station IncidentForm Form used for the input of ReportEmergency. This form is presented to the FieldOfficer when Report Emergency function is selected. Mobile computer used by FieldOfficer. Form used for the creation of Incidents. This form is presented to Dispatcher on DispatcherStation when EmergencyReport is received. The Dispatcher also uses this form to allocate resources and to acknowledge FieldOfficer’s report. Example: Boundary Objects for ReportEmergency Use Case(Contd.)

35. Control Objects • Control objects are responsible for coordinating boundary and entity objects. • Control objects do not usually have concrete real world counterparts. • There is usually a close relationship between a use case and a control object. • A control object is created at the beginning of a use case and ceases to exist at its end. • It is responsible for collecting information from the boundary objects and dispatching it to the entity objects. • E.g., behaviour associated with sequencing of forms, undo and history queues, dispatching information in a distributed system.

36. Heuristics for Identification of Control Objects. • Identify one control object per use case or more if the use case is complex and if it cannot be divided into shorter flows of events. • Identify one control object per actor in the use case. • The life span of a control object should be extent of the use case or the extent of a user session. • If it is difficult to identify the beginning and end of a control object activation, the corresponding use case may not have a well-defined entry and exit conditions.

37. Example: Control Objects for ReportEmergency Use Case • ReportEmergency Control Manages the report emergency control function on the FieldOfficer Station. This object is created when the FieldOfficer selects the ReportEmergency button. It then creates an EmergencyReportForm and presents it to the FieldOfficer. After submission of the form, it creates an EmergencyReport and forwards it to the Dispatcher. The control object then waits for an acknowledgement from the DispatcherStation, upon the receipt of which it creates an Acknowledgement Notice and displays it to the FieldOfficer.

38. Example: Control Objects for ReportEmergency Use Case(Contd.) • ManageEmergency Control Manages the report emergency report-ing function on the DispatcherStation. This object is created when an EmergencyReport is received. It then creates an IncidentForm and displays it to the Dispatcher. Once the Dispatcher has created an Incident, allocated Resources, and submitted an acknowledgment, it forwards the acknowledgment to the FieldOfficer Station.

39. Modeling Interactions Between Objects: Sequence Diagrams • A sequence diagram is linked to use cases with objects. • It demonstrates the behavior of a use case distributed amongst the participating objects of the use case. • Sequence diagrams usually not considered appropriate for communication with the user. • Used to assist developers in finding missing objects or resolving ambiguities in the system specifications.

40. Sequence Diagram for ReportEmergency Use Case

41. Sequence Diagrams • Columns in a sequence diagram represent the objects participating in the use case. • The left most corner is the actor who initiates the use case. • Horizontally directed lines across columns represent messages or stimuli sent from top to bottom. • Rectangle at the vertical column shows activation upon receipt of a message. • Messages to other objects can originate from a rectangle. • Length of the rectangle represents the time the operation is active.

42. Heuristics for Drawing Sequence Diagrams • The first column should correspond to the actor who initiated the use case. • The second column should be a boundary object (that the actor used to initiate the use case). • The third column should be the control object that manages the rest of the use case.

43. Heuristics for Drawing Sequence Diagrams (Contd.) • Control objects are created by boundary objects initiating the use cases. • Boundary objects are created by control objects. • Entity objects are accessed by control and boundary objects. • Entity objects never access boundary or control objects, this makes it easier to share entity objects across use cases.

44. Sequence Diagrams • Sequence Diagrams • Model the order of interaction among the objects. • Distribute the behavior of the use case. • Responsibilities are assigned to each object in the form of a set of operations. • These operations can be shared by any use case in which a given object participates. • The definition of an object that is shared across two or more use cases should be identical.

45. Sequence Diagrams (Contd.) • Sharing operations across use cases allows developers to remove redundancies in the system specifications and to improve its consistency. • Clarity should always be given precedence • Fragmenting behavior across many operations unnecessarily complicates the system specifications • Sequence diagrams focus on high level behavior. • Implementation issues are not addressed.

46. Associations • Interaction diagrams used to represent temporal interactions between objects. • Class diagrams used to represent the spatial connectivity of objects. • An association shows a relationship between two or more classes. • Identification of associations • Clarifies the analysis model by making relationships between objects explicit. • Enables developers to discover boundary cases associated with links. • Boundary conditions are exceptions that need to be clarified in the model.

47. Example: Associations * 1 FieldOfficer EmergencyReport author document

48. Properties of Associations • Name of association • Describes the association between two classes. • Association names are optional and need not be unique globally. • Role at each end of the association • Identifies the function of each class with respect to the association. • Multiplicity at each end • Identifies the possible number of instances.

49. Identifying Associations • Initially associations between entity objects are to be identified. • They reveal information about the application domain. • Using Abbott’s heuristics, associations can be identified by examining verbs and verb phrases denoting a state. • E.g., has, is part of, manages, reports to. • Each association should be named and roles assigned to each end. • The developer must only include necessary associations to avoid complicated models. • Associations can assist in naming specific objects (or instances of classes) in particular contexts.

50. Heuristics for Identifying Associations • Examine verb phrases. • Name associations and roles precisely. • Use qualifiers as often as possible to identify namespaces and key attributes. • Eliminate any association that can be derived from other associations. • Do not worry about multiplicity until the set of associations is stable. • Avoid ravioli models: too many associations make a model unreadable.