Chapter 5, Analysis: Object Modeling

1
Chapter 5, AnalysisObject 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
Next chapter
Next chapter
4
The analysis model
5
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
6
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
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
Class identification

• Finding objects is the central piece in object
  modeling
• Approaches
• Application domain approach (not a special
  lecture, examples)
• Ask application domain expert to identify
  relevant abstractions
• Syntactic approach (today)
• Start with use cases. Extract participating
  objects from flow of events
• Use noun-verb analysis (Abbots technique) to
  identify components of the object model
• Design patterns approach (Lecture on design
  patterns)
• Use reusable design patterns
• Component-based approach (Lecture on object
  design)
• Identify existing solution classes

10
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

11
UML Class and Instance Diagrams
Inspector
Class Diagram
anonymous Inspector
joe Inspector
mary Inspector
Instance Diagram
12
Attributes and Values
13
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.

14
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
15
Object Instance Diagram
Example for 1-to-many
16
Many-to-Many Associations
Work on


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

19
Aggregation
2,4
3,4,5

20
Inheritance

• Models "kind of" hierarchy
• Powerful notation for sharing similarities among
  classes while preserving their differences
• UML Notation An arrow with a triangle

Cell
MuscleCell
BloodCell
NerveCell
Pyramidal
21
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)

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

23
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

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

26
Qualification

• The qualifier improves the information about the
  multiplicity of the association between the
  classes.
• It is used for reducing 1-to-many multiplicity to
  1-1 multiplicity

Without qualification A directory has many
files. A file belongs only to one directory.
With qualification A directory has many files,
each with a unique name
27
Example
Pr
oblem Statement

A
stock exchange lists many companies.
However
, a stock exchange lists only one company with a
given ticker symbol.
A
company may be listed on many stock
exchanges, possibly with different ticker
symbols. Find company with ticker symbol AAPL.
28
Use of Qualification reduces multiplicity
0..1
1
29
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)

30
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., EmergencyOperationsP
  lan),
• 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 users terms

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

33
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
34
Avoid Ravioli Models
Account
Customer
Bank
Balance AccountID


Has
Name
Name
Deposit()
Withdraw()
CustomerId
GetBalance()
Dont put too many classes into the same
package 7-2 (or even 5-2)
35
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)

36
Example 2BWatch Objects

• UML provides several mechanisms to extend the
  language
• UML provides the stereotype mechanism to present
  new modeling elements

37
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 users terms

38
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 users terms for describing
  interfaces as opposed to terms from the
  implementation technology.

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

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

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

42
Boundary Objects in the example

• AcknowledgmentNotice
• Notice used for displaying the Dispatchers
  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
  FieldOfficers report.

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

44
Order of activities in modeling

1. Formulate a few scenarios with help from the end
   user and/or application domain expert.
2. Extract the use cases from the scenarios, with
   the help of application domain expert.
3. Analyse the flow of events, for example with
   Abbot's textual analysis.
4. Generate the class diagrams, which includes the
   following steps
5. Class identification (textual analysis, domain
   experts).
6. Identification of attributes and operations
   (sometimes before the classes are found!)
7. Identification of associations between classes
8. Identification of multiplicities
9. Identification of roles
10. Identification of constraints

45
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

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