Chapter 5, Analysis: Object Modeling

Chapter 5, Analysis:Object Modeling

Outline • From use cases to objects • Object modeling • Class vs instance diagrams • Attributes • Operations and methods • Links and associations • Examples of associations • Two special associations • Aggregation • Inheritance

Requirements Elicitation system specification :Model Analysis analysis model :Model System Design system model :Model Products of requirements elicitation and analysis Next chapter Next chapter

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 The analysis model

From Use Cases to Objects Level 1 Use Case Le v el 1 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

From Use Cases to Objects: Why Functional Decomposition is not Enough Scenarios Le v el 1 Level 1 Use Cases Le v el 2 Le v el 2 Level 2 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

From Use Cases to Objects Starting from use cases and scenarios, analysis activities performed to obtain the analysis model are: • Identifying entity objects • Identifying boundary objects • Identifying control objects • Mapping use cases to objects • Identifying associations among objects • Identifying object attributes • Modeling behavior with statecharts • Modeling generalization relationships • Reviewing the analysis model

Object Modeling • Main goal: Find the important abstractions • What happens if we find the wrong abstractions? • Iterate and correct the model • Steps during object modeling • 1. Class identification • Based on the fundamental assumption that we can find abstractions • 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

Pieces of an Object Model • Classes • Associations (Relations) • 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 • Methods • Detection of methods • Generic methods: General world knowledge, design patterns • Domain Methods: Dynamic model, Functional model

UML: Class and Instance Diagrams Inspector Class Diagram anonymous: Inspector joe: Inspector mary: Inspector Instance Diagram

Inspector name:string age: integer joe:Inspector mary: Inspector name = “Joe” name = “Mary” age = 24 age = 18 Attributes and Values

Links and Associations • Links and associations establish relationships among objects and classes. • Link: • A connection between two object instances. A link is like a tuple. • A link is an instance of an association • Association: • Basically a 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.

Country City name:String name:String Workorder schedule() 1-to-1 and 1-to-many Associations Has-capital One-to-one association StickyNote * x: Integer y: Integer z: Integer One-to-many association

:Sticky :Sticky :Sticky :WorkOrder x,y,z=(-1,0,5) x,y,z=(1,10,1) x,y,z=(10,1,2) Object Instance Diagram Example for 1-to-many

Mechanics Plane Many-to-Many Associations Work on * *

Do UML associations have direction? A association between two classes is by default a bi-directional mapping. • Class A can access class B and class B can access class A • Both classes play the agent role. A B • If you want to to make A a client, and B a server, you can make the association unidirectional. The arrowhead points to the server role: • Class A ( the “client”) accesses class B (“the server”). B is also called navigable Name of association Name Direction Association Direction A B accesses

Aggregation • Models "part of" hierarchy • Useful for modeling the breakdown of a product into its component parts (sometimes called bills of materials (BOM) by manufacturers) • UML notation: Like an association but with a small diamond indicating the assembly end of the relationship.

Automobile serial number Engine year manufacturer horsepower volume model on color off weight drive purchase Battery Wheel amps volts Brakelight diameter Door charge discharge number of bolts open on close off Aggregation 2,4 3,4,5 *

Red White Smooth Cortical Striate Inheritance • Models "kind of" hierarchy • Powerful notation for sharing similarities among classes while preserving their differences • UML Notation: An arrow with a triangle Cell BloodCell MuscleCell NerveCell Pyramidal

Aggregation vs Inheritance • Both associations describe trees (hierarchies) • Aggregation tree describes a-part-of relationships (also called and-relationship) • Inheritance tree describes "kind-of" relationships (also called or-relationship) • Aggregation relates instances (involves two or more different objects) • Inheritance relates classes (a way to structure the description of a single object)

Other Associations • Uses: • A subsystem uses another subsystem (System Design) • Contains: • Sometimes called “spatial aggregation” • ... contains ... • Example: A UML package contains another UML package • Parent/child relationship: • ... is father of ... • ... is mother of ... • Seniority: • ... is older than ... • ... is more experienced than ...

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 • Object types originated in Smalltalk: • Model, View, Controller (MV)

<<entity>> <<control>> <<boundary>> Year ChangeDateControl ButtonBoundary <<entity>> <<boundary>> Month LCDDisplayBoundary <<entity>> Day Example: 2BWatch Objects • UML provides several mechanisms to extend the language • UML provides the stereotype mechanism to present new modeling elements

Roles • A role name is the name that uniquely identifies one end of an association. • A role name is written next to the association line near the class that plays the role. • When do you use role names? • Necessary for associations between two objects of the same class • Also useful to distinguish between two associations between the same pair of classes • When do you not use role names? • If there is only a single association between a pair of distinct classes, the names of the classes serve as good role names

Person Person Person Person Example of Role Pr oblem Statement : A person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person. * Creates Workorders * inspector Creates Workorders repairperson

Roles in Associations • Client Role: • An object that can operate upon other objects but that is never operated upon by other objects. • Server Role: • An object that never operates upon other objects. It is only operated upon by other objects. • Agent Role: • An object that can both operate upon other objects and be operated upon by other objects. An agent is usually created to do some work on behalf of an actor or another agent.

How do you find classes? • 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 • 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 opeations • Apply design knowledge: • Distinguish different types of objects • Apply design patterns (Lecture on design patterns)

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) • 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

Mapping parts of speech to object model components [Abbot 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

Example: Scenario from Problem Statement • Jim Smith enters a store with the intention of buying a toy for his 3 year old child. • 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. • Jim selects a dangerous toy which is unsuitable for the child. • The store owner recommends a more yellow doll.

Avoid Ravioli Models Account Bank Customer Balance AccountID * * Has Name Name Deposit() Withdraw() CustomerId GetBalance() Don’t put too many classes into the same package: 7+-2 (or even 5+-2)

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)

How to identify entity 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, 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

How to identify boundary objects • Identify forms and windows the users needs to enter data into the system (e.g., EmergencyReportForm, ReportEmergencyButton). • Identify notices and messages the system uses to respond to the user (e.g., AcknowledgmentNotice). • 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.

How to identify control objects • Identify one control object per use case or more if the use case is complexand if it can 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 the end of a control object activation, the corresponding use case may not have a well-defined entry and exit condition.

An example: the ReportEmergency use case Use case name: ReportEmergency Entry condition: The FieldOfficer activates the “Report Emergency” function of her terminal. Flow of events: 1. FRIEND responds by presenting a form to the officer. The form includes an emergency type menu (Genera1 emergency, fire, transportation), a location, incident description, resource request, and hazardous material fields. 2. 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. 3. The Dispatcher reviews the information submitted by the FieldOf f icer and creates an incident in the database by invoking the OpenIncident use case. Al1 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. Exit condition: The FieldOfficer receives the acknowledgment and the selected response.

Entity objects in the example Dispatcher Police 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. EmergencyReport Initial report about an Incident from a FieldOfficer to a Dispatcher. An EmergencyReport usually triggers the creation of an Incident by the Dispatcher. An EmergencyReport is composed of a emergency level, a type (fire, road accident, or other), a location, and a description. Fieldofficer Police or fire officer on duty. A FieldOfficer can be allocated to, at most, one Incident at a time. FieldOfficers are identified by badge numbers. NOT TRUE in this UC. Here FieldOfficers are actors, they can be entity objects in the Allocateresource UC Incident Situation requiring attention from a FieldOfficer. An Incident may be reported in the system by 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 a number of FieldOfficers.

Boundary Objects in the example AcknowledgmentNotice Notice used for displaying the Dispatcher’s acknowledgment to the FieldOfficer. DispatcherStation Computer used by the Dispatcher. ReportEmergencyButton Button used by a FieldOfficer to initiate the ReportEmergency use case. EmergencyReportForm Form used for the input of the ReportEmergency. This form is presented to the FieldOfficer on the FieldOfficerstation when the “Report Emergency” function is selected. The EmergencyReportForm contains fields for specifying all attributes of an emergency report and a button (or other control) for submitting the form once it is completed. FieldOfficerStation Mobile computer used by the FieldOfficer. Incident Form Form used for the creation of Incidents. This form is presented to the Dispatcher on the DispatcherStation when the EmergencyReport is received. The Dispatcher also uses this form to allocate resources and to acknowledge the FieldOfficer’s report.

Control objects in the example ReportEmergencyControl Manages the report emergency reporting function on the FieldOfficerstation. This object is created when the FieldOfficer selects the “Report Emergency” button. It then creates an EmergencyReportFom and presents it to the FieldOfficer. After submission of the form, this object then collects the information from the form, creates an EmergencyReport, and forwards it to the Dispatcher. The control object then waits for an acknowledgment to come back from the DispatcherStation. When the acknowledgment is received, the ReportEmergencyControl object creates an AcknowledgmentNotice and displays it to the Fie1dOfficer . ManageEmergencyControl Manages the report emergency reporting function on the DispatcherStation. This object is created when an EmergencyReport is received. It then creates an IncidentFom and displays it to the Dispatcher. Once the Dispatcher has created an Incident, allocated Resources, and submitted an acknowledgment, ManageEmergencyControl forwards the acknowledgment to the FieldOfficerstation.

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. • Analyse 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

Application domain vs solution domain • Application domain: • The problem domain (financial services, meteorology, accident management, architecture, …). • Application domain class: • An abstraction in the application domain. If we model business applications, these classes are also called business objects. • Example: Board game, Tournament • Solution domain: • Domains that help in the solution of problems (tele communication, data bases, compiler construction, operting systems, ….) • Solution domain class: • An abstraction, that is introduced for technical reasons, because it helps in the solution of a problem. • Examples: Tree, Hashtable, Scheduler

Summary In this lecture, we reviewed the construction of the object model from use case model. In particular, we described: • Identification of objects (entity, boundary, control) • Refinement of objects with attributes and operations • Generalization of concrete classes • Identification of associations • Reduction of multiplicity using qualification. In the next lecture, we describe the construction of the dynamic model from the use case and object models.

Chapter 5, Analysis: Object Modeling