1. 1 Object Oriented Analysis Lectures 12 & 13

2. 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. 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. 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. 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. 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. 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. 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. 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. 10 Example: Participating objects for the ReportEmergency Use Case DispatcherPolice officer who manages Incidents. A Dispatcher opens, documents and closes incidents in response to emergency reports and other communication with FieldOfficers. Dispatchers are identified by badge numbers. Emergency Report Initial report about an Incident from a FieldOfficer to a Dispatcher. An EmergencyReport is composed of an emergency level, a type(fire, road accident or other), a location, and a description.

11. 11 Example: Participating Objects for the ReportEmergency Use Case (Contd.) FieldOfficerPolice or fire officer on duty. A FieldOfficer can be allocated to at most one Incident at a time. FieldOfficers are identified by badge numbers. IncidentSituations requiring attention from a FieldOfficer or anybody else external to the system. An incident is composed of a description, a response, a status(open, closed, documented), a location and number of FieldOfficers.

12. 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. 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. 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. 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. 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. 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. 18 Analysis Classes for a Clock > Time > LCDDisplayBoundary > TimeProcesor > KeypadBoundary

19. 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. AircraftEngine 12 ownerproperty

20. 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. 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. 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. 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. 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. 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. 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. 27 Example: ReportEmergency Use case nameReportEmergency Entry condition1.The FieldOfficer activates the “Report Emergency” function of his/her terminal. Flow of Events2.FRIEND responds by presenting a form to the officer. The form includes an emergency type menu(General emergency, fire, transportation), a location, incident description, resource request, and hazardous material fields. 3.The FieldOfficer fills the form, by selecting minimally the emergency type and description fields. The FieldOfficer also describes possible responses to the emergency situation and request specific resources. When completed, the FieldOfficer submits the form by pressing the “Send Report” button, at which point the Dispatcher is notified.

28. 28 Example: ReportEmergency (Contd.) 4. The Dispatecher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. All information in the form is included automatically in the incident. The Dispatcher selects a response by allocating resources to the incident(with AllocateResources use case) and acknowledges the emergency report by sending a FRIENDgram to the FieldOfficer. Exit condition 5. The FieldOfficer receives the acknowledgement and the selected response.

29. 29 Entity Objects for ReportEmergency Use Case 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.

30. 30 Entity Objects for ReportEmergency Use Case (Contd.) 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.

31. 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. 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. 33 Example: Boundary Objects for ReportEmergency Use Case 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

34. 34 Example: Boundary Objects for ReportEmergency Use Case (Contd.) 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.

35. 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. 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. 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. 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. 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. 40 Sequence Diagram for ReportEmergency Use Case

41. 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. 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. 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. 44 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. 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. 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. 47 Example: Associations FieldOfficerEmergencyReport * 1 authordocument

48. 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. 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. 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.

51. 51 Attributes Attributes are properties of individual objects. When identifying properties of objects, only the attributes relevant to the system should be considered. Example: –For a FieldOfficer, relevant attributes are: BadgeNumber, CurrentLocation –Irrelevant attributes are: SocialSecurityNumber

52. 52 Attributes (Contd.) Properties represented by associated or component objects are not attributes. Developers should identify as many associations as possible before identifying attributes to avoid confusing attributes and component objects. Attributes have: –A name identifying them within an object –A brief description –A type describing the legal values it can attain.

53. 53 Identification of Attributes Attributes can be identified using Abbott’s heuristics. –Noun phrases followed by possessive phrases or an adjective phrase. Incase of entity objects, any property that needs to be stored by the system is a candidate attribute. Attributes represent the least stable part of the object model. –Usually discovered or added late in the development. –Unless the added attributes are associated with additional functionality, the added attributes do not entail major changes in object or system structure.

54. 54 Heuristics for Identifying Attributes Examine possessive phrases. Represent stored state as attributes of entity objects. Describe each attribute. Do not represent an attribute as an object, use an association instead. Do not waste time describing fine details before the object structure is stable.

55. 55 Modeling Non-trivial Behavior of Individual Objects Sequence diagrams are used to distribute behavior across objects and to identify operations associated with these objects. Sequences diagrams represent the behavior of the system from the perspective of a single use case.

56. 56 Modeling Non-trivial Behavior of Individual Objects (Contd.) State chart diagrams represent behavior from the perspective of a single object. –Enables the developer to Identify the missing use cases. Build a more formal description of the behavior of the object. It is not necessary to build state charts for every class in the system. –Only the state charts of objects with an extended lifespan and nontrivial behavior are worth constructing.

57. 57 Example: UML State Chart for Incident

58. 58 Modeling Generalization Relationships Between Objects Generalization is used to eliminate redundancy from the analysis model. If two or more classes store attributes or behavior, their similarities are consolidated into a super class. E.g., –Dispatchers and FieldOfficers both have a BadgeNumber attribute. –Dispatchers and FieldOffiers are both PoliceOfficers who are assigned different functions. –Classes to represent both are derived from a base class PoliceOfficer.

59. 59 Example: Inheritance relationship

60. 60 Reviewing the Analysis Model Analysis model is built incrementally and iteratively. Analysis model is seldom correct or even complete on the first pass. –Several iterations with the client and the users are necessary before the analysis model converges towards a correct specification usable by the developer for proceeding to design and implementation. –E.g., an omission discovered during analysis will lead to adding or extending a use case in the system specification leading to elicitation of more information.

61. 61 Reviewing the Analysis Model (Contd.) Analysis model is reviewed once it is stable. –Review initially conducted by the developer. –Later reviews conducted jointly by developers and clients. –The goal of review is to ensure that the system specification is correct, complete, consistent and realistic.

62. 62 Analysis Activities and Their Relationships