1. Chapter 5, Analysis: Object Modeling

2. Outline From use cases to objects Object modeling
Class vs instance diagrams
Attributes
Operations and methods
Links and associations

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

4. The analysis model analysis model:Model dynamic object functional
use case
diagram:View
class
statechart
sequence

5. From Use Cases to ObjectsLe v
el 1
Level 1 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. From Use Cases to Objects: Why Functional Decomposition is not EnoughLe v
el 1
Scenarios
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

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

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

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

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

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

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

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

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

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

16. 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.
Person
Person
Creates Workorders *
Person
inspector *
Person
Creates Workorders
repairperson

17. Roles in Associations Client Role: Server Role: Agent 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.

18. 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)
Q: What key ideas have we covered so far? A: Patterns, analysis documentation standard, inheritance and multiple inheritance. In the last part of this lecture I would like to come back to the problem of object identification and another tool that helps you infinding objects.
Patterns: A way to put your knowledge about object modeling into drawers.
Analysis documentation standard: The “official” way of drawing object models. The major elements are: CASE Tool Entry: Executive summary and one subsystem per sheet classes per sheet. Documentation: Each subsystem has navigational text.
Difference between aggregation and inheritence
Object identification: Using textual analysis
Multiple Inheritance: Why it cannot be avoided, how you can deal with it.
Software engineering as a special case of Epistemology: Software engineering is a join class of materialism (budget and deadline influencing your modeling (They might limit what you can achieve!). Idealism: Some of the classes do not reflect reality (that is, the customer does not know about them) and dialecticism (iteration and incremental analysis with user participatory decision making capabilities).

19. Mapping parts of speech to object model components [Abbot 1983]
Part of speech
Model component
Proper noun
object
Improper noun
class
Doing verb
method
being verb
inheritance
having verb
aggregation
modal verb
constraint
adjective
attribute
transitive verb
method
Example 
intransitive verb
method (event)

20. Example of application of the Abbot technique
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.

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

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

23. Object Types Entity Objects Boundary Objects Control 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)

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

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

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

27. How to identify control objects
Identify one control object per use case or more if the use case is complex and 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.

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

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

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

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

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

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