Chapter 5: Analysis Object Modeling

1. Chapter 5: Analysis Object Modeling

2. A Projector System • Use Case • Show Slides • User, Laptop, and Screen are actors • Objects • controlPad, Lens, Serial Port, PresentationControl, • Sequence Diagram • ….

3. Identifying Initial Analysis Objects • To establish a clear terminology, developers identify the participating objects for each use case into a glossary. • The glossary is included in the requirements specification and, later, in the user manuals. • The identification of participating objects results in the initial analysis object model. – constitutes a first step toward the complete analysis object model.

4. Level 2 Use Cases Le v el 2 Le v el 2 Level 3 Use Cases Le v el 3 Le v el 3 Le v el 3 Operations Le v el 4 Le v el 4 A B From Use Cases to Objects Le v el 1 Top Level Use Case A and B are called Participating Objects

5. Use Cases can be used by more than one object Le v el 1 Top Level Use Case Level 2 Use Cases Le v el 2 Le v el 2 Level 3 Use Cases Le v el 3 Le v el 3 Le v el 3 Operations Le v el 4 Le v el 4 A B Participating Objects

6. Outline • Analysis model overview • Activities during object modeling • Object identification • Object types • entity, boundary and control objects • Object naming • Abbott’s technique helps in object identification • Users of class diagrams • Note: the lecture introduces concepts and provides examples. Active class participation is strongly encouraged.

7. Analysis Model Overview Use case diagram Class diagram Statechart diagram Sequence diagram functional model object model dynamic model analysis model

8. Analysis Model vs. Design Model • Analysis model: Application domain model • System Design and Object design models: Solution domain model • They all use class diagram, sequence diagram, and state chart diagram, but focus on different aspects

9. Activities during Object Modeling • Main goal: Find the important abstractions (classes) • Steps during object modeling • 1. Class identification • 2. Find the attributes • 3. Find the methods • 4. Find the associations between classes • Order of steps • Goal: get the desired abstractions • Order of steps secondary, only a heuristic • Iteration is important

10. Class identification • 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?

11. What is This? Face 1..2 Eye

12. Modeling in Action • Face • Mask • Sad • Happy •  Mood • Is it one Face or two? • Who is using it? • Person at Carnival? • Bankrobber? • Painting collector • How is it used? • Wear on? • Clean?

13. 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 operations: Dynamic model, Functional model

14. Object vs Class • Object (instance): Exactly one thing • This lecture on Software Engineering on November 15 from 14:30 -16:00 • A class describes a group of objects with similar properties • Game, Tournament, mechanic, car, database • Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"): • Class diagram:Template for describing many instances of data. Useful for taxonomies, patterns, schemata... • Instance diagram:A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples

15. How do you find classes? • Learn about problem domain: Observe your client • Apply general world knowledge and intuition • Apply design patterns • Try to establish a taxonomy • Take the flow of events and find participating objects in use cases • Do a textual analysis of scenario or flow of events (Abbott Textual Analysis, 1983) • Nouns are good candidates for classes Heuristic: start with the points in blue

16. 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 • Having three types of objects leads to models that are more resilient to change. • The interface of a system changes more likely than the control • The control of the system change more likely than the application domain • Object types originated in Smalltalk: • Model, View, Controller (MVC)

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

18. 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 <<Entity>> Month <<Boundary>> LCDDisplay <<Entity>> Day Entity Objects Control Objects Boundary Objects

19. Recommended Naming Convention for Object Types • To distinguish the different object types on a syntactical basis, we recommend suffixes: • Objects ending with the “_Boundary” suffix are boundary objects • Objects ending with the “_Control” suffix are control objects • Entity objects do not have any suffix appended to their name. Button_Boundary Year ChangeDate_ Control Month LCDDisplay_Boundary Day Back to the projector example

20. Let’s do Object Modeling – P181 Use Case name: ReportEmergency Flow of events • The FieldOfficer activates the “Report Emergency” function of her terminal. • 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. • The FieldOfficer fills the form, by specifying minimally the emergency type and description fields. The FieldOfficer may also describes possible responses to the emergency situation and request specific resources. Once the form is completed, the FieldOfficer submits the form by pressing the “Send Report” button, at which point, the Dispatcher is notified. • The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. All the information contained in the FieldOfficer’s form is automatically included in the incident. The Dispatcher selects a response by allocating resources to the incident (with the AllocateResources use case) and acknowledges the emergency report by sending a FRIENDgram to the Fieldofficer. • The FieldOfficer receives the acknowledgment and the selected response.

21. Exercise Define at least 3 entity objects, 4 boundary objects, and 2 control objects

22. Heuristics for Identifying Entity Objects • 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) • 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

23. Object Dictionary

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

25. Heuristics for Identifying Control Objects • Identify one control object per use case • Identify one control object per actor in the user case. • The life span of a control object should cover the extend of the use case or extend of a user session. If it is difficult to identify the beginning and the end of a control object activation, the corresponding use case probably does not have well-defined entry and exit conditions.

26. Entity – yellow Boundary – blue Control -- red Let’s do Object Modeling – P181 Use Case name: ReportEmergency • 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. • The FieldOfficer fills the form, by specifying minimally the emergency type and description fields. The FieldOfficer may also describes possible responses to the emergency situation and request specific resources. Once the form is completed, the FieldOfficer submits the form by pressing the “Send Report” button, at which point, the Dispatcher is notified. • The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. All the information contained in the FieldOfficer’s form is automatically included in the incident. The Dispatcher selects a response by allocating resources to the incident (with the AllocateResources use case) and acknowledges the emergency report by sending a FRIENDgram to the Fieldofficer. 1. The FieldOfficer activates the “Report Emergency” button of her terminal. The FieldOfficer receives the acknowledgment and the selected response.

27. Let’s do Object Modeling – P181 • Entity Objects: • Dispatcher, EmergencyReport, FieldOfficer, Incident • Boundary Objects: • AcaknowledgmentNotice, DispatcherStation, ReportEmergencyButton, EmergencyReportForm, FieldOfficerStation, IncidentForm • Control Objects: • ReportEmergencyControl (on the FieldOfficerStation side), ManageEmergencyControl (on the DispatcherStation side)

28. Example: Use Case – from Dental Office System - input for creating the Analysis Model Title: Search for Supplier Information Preconditions: Dental Office System has been initialized Postconditions: If the search is successful, then the supplier information is displayed. If the search is not successful, then an error message is displayed. Normal Flow: • The Operator requests to search for supplier. The Operator may perform a keyword search using the boolean operators “not”, “and”, and “or”. The Operator may enter up to three keywords • The system displays the name, phone number, fax number, and address of the suppliers that match the search criteria. Alternate Flow • The Operator requests to search for supplier. The Operator may perform a keyword search using the boolean operators “not”, “and”, and “or”. • If no matches are found, then the system displays an error message to the Operator.

29. Example: Use Case – from Dental Office System // Circle the nouns (focus on the normal and alternate flows) Title: Search for Supplier Information Preconditions: Dental Office System has been initialized Postconditions: If the search is successful, then the supplier information is displayed. If the search is not successful, then an error message is displayed. Normal Flow: • The Operator requests to search for supplier. The Operator may perform a keyword search using the boolean operators “not”, “and”, and “or”. The Operator may enter up to three keywords • The system displays the name, phone number, fax number, and address of the suppliers that match the search criteria to the Operator. Alternate Flow • The Operator requests to search for supplier. The Operator may perform a keyword search using the boolean operators “not”, “and”, and “or”. • If no matches are found, then the system displays an error message to the Operator. // I started here with proper nouns (actors). // Exercise: identify nouns/possible objects and attributes

30. UML: Class and Object Diagrams Class Diagram Supplier :Supplier Object Diagram ACME Floss: Supplier Vogue: Supplier Anonymous Object

31. Attributes and Values Supplier ACME Floss:Supplier name:string name:ACME Floss Inc. address: 1607 N. Floyd Rd Richardson, Texas, USA address: string phone: string fax: string phone: 972-883-4216 fax: 972-883-2349

32. Operation: A function or transformation applied to objects in a class. All objects in a class share the same operations (Analysis Phase) Signature:Number & types of arguments, type of result value. All methods of a class have the same signature (Object Design Phase) Method: Implementation of an operation for a class (Implementation Phase) Workorder File_name: String Size_in_bytes: integer Last_update: date Stickies: array[max] print() delete() open() close() write() read() Operation, Signature or Method?

33. Links and Associations • Links and associations establish relationships among objects and classes. • Link: • A connection between two object instances. • A link is an instance of an association • Association: • Bidirectional mapping. • One-to-one, many-to-one, one-to-many, • An association describes a set of links like a class describes a set of objects. • Generalization, aggregation, composition, and others

34. 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 • Having three types of objects leads to models that are more resilient to change. • The boundary of a system changes more likely than the control • The control of the system change more likely than the application domain

35. Example: Use Case – from Dental Office System // Circle the nouns (focus on the normal and alternate flows) Title: Search for Supplier Information Preconditions: Dental Office System has been initialized Postconditions: If the search is successful, then the supplier information is displayed. If the search is not successful, then an error message is displayed. Normal Flow: • The Operator requests to search for supplier. The Operator may perform a keyword search using the boolean operators “not”, “and”, and “or”. The Operator may enter up to three keywords. • The system displays the name, phone number, fax number, and address of the suppliers that match the search criteria to the Operator. Alternate Flow • The Operator requests to search for supplier. The Operator may perform a keyword search using the boolean operators “not”, “and”, and “or”. • If no matches are found, then the system displays an error message to the Operator. // Supplier is an entity object; what are name, phone, fax, and address? // Boundary objects? Control objects?

36. Example: Dental Office System - describe as classes - if needed, generalize the objects <<entity>> <<control>> <<boundary>> DentalOfficeControl Supplier GUI <<entity>> <<control>> ... Client <<entity>> TIP If you organize your boundary objects on the left, then this model is going to be organized in a similar way to your sequence diagrams Dental Office

37. Static Modeling in Practice: Encourage Brainstorming Find New Objects (nouns in use case) Generalize as a Class Iterate on Names, Attributes and Methods Find Associations between Classes, Links between Objects Label the associations, links Determine the multiplicity of the associations • Iteratively refine the model • Don’t put too many objects/classes into the same package: 7+-2

38. Example: Dental Office System - a place to start <<control>> <<boundary>> DentalOfficeGUIBoundary DentalOfficeControl <<entity>> <<entity>> Supplier Client name address phone <<entity>> fax Appointment add modify search delete

39. Abbott Textual Analysis • Nouns are good candidates for classes • Verbs are good candidates for operations • Good for generating a list of initial candidate objects • Advantage: focusing on the user’s terms • Limitations: • The quality of object model depends highly on the style of writing • There are many more nouns than relevant classes

40. Example: Flow of events • The customer enters a store with the intention of buying a toy for his child with the age of 7. • 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.

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

42. Example Flow of events: • The customer enters the store to buy a toy. • It has to be a toy that his daughter likes and it must cost less than 50 Euro. • He tries a videogame, which uses a data glove and a head-mounted display. He likes it. Is this a good use Case? An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely the boardgame “Monopoly". Not quite! The use case should terminate with the customer leaving the store

43. Textual Analysis using Abbot‘s technique Grammatical construct Example UML Component “Monopoly" Concrete Person, Thing Object “toy" noun class "3 years old" Adjective Attribute “enters" verb Operation “depends on…." Intransitive verb Operation (Event) “is a" ,“either..or", “kind of…" Classifying verb Inheritance "Has a ", “consists of" Possessive Verb Aggregation “must be", “less than…" modal Verb Constraint

44. store enter() ? enter() daughter daughter age suitable * toy price buy() like() toy buy() toy boardgame videogame Generation of a class diagram from flow of events Flow of events: Customer customer enters store • The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. buy daughter toy less than 50 Euro videogame An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buy the game and leaves the store depends age type of toy boardgame

45. Order of activities in modeling • Formulate a few scenarios with help from the end user and/or application domain expert. • Extract the use cases from the scenarios, with the help of application domain expert. • Analyze the flow of events, for example with Abbot's textual analysis. • Generate the class diagrams, which includes the following steps: • Class identification (textual analysis, domain experts). • Identification of attributes and operations (sometimes before the classes are found!) • Identification of associations between classes • Identification of multiplicities • Identification of roles • Identification of constraints

46. Some issues in object modeling • Improving the readability of class diagrams • Managing object modeling • Different users of class diagrams

47. Account * * Has Amount Customer Bank CustomerId Name Name AccountId Deposit() AccountId CustomerId Withdraw() GetBalance() Avoid Mixing All Models Together Savings Account Checking Account Mortgage Account Don’t put too many classes into the same package: 7+-2 (or even 5+-2) Withdraw() Withdraw() Withdraw()

48. Account Amount CustomerId AccountId Deposit() AccountId Withdraw() GetBalance() Put Taxonomies on a separate Diagram Savings Account Checking Account Mortgage Account Withdraw() Withdraw() Withdraw()

49. Project Management Heuristics • Explicitly schedule meetings for object identification • First just find objects • Then try to differentiate them between entity, interface and control objects • Find associations and their multiplicity • Unusual multiplicities usually lead to new objects or categories • Identify Inheritance: Look for a Taxonomy, Categorize • Identify Aggregation • Allow time for brainstorming , Iterate, iterate

50. Who uses class diagrams? • Purpose of Class diagrams : • The description of the static properties of a system (main purpose) • Who uses class diagrams? • The customer and the end user are often not interested in class diagrams. They usually focus more on the functionality of the system. • The application domain expert usesclass diagrams to model the application domain • The developer uses class diagrams during the development of a system,that is, during analysis, system design, object design and implementation.