Object Oriented Analysis
Lectures 12 & 13
1
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.
2
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.
3
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.
4
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) 5
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.
6
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.
7
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.
8
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
9
use case that depends on this info)?
Example: Participating objects for
the ReportEmergency Use Case
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.
Emergency Initial report about an Incident from a
Report
FieldOfficer to a Dispatcher. An
EmergencyReport is composed of an
emergency level, a type(fire, road accident
or other), a location, and a description.
10
Example: Participating Objects for
the ReportEmergency Use Case
(Contd.)
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.
Incident
Situations 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
11
number of FieldOfficers.
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.
12
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.
13
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.
14
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.
15
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.
16
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.
17
Analysis Classes for a Clock
<<entity>>
Time
<<boundary>>
LCDDisplayBoundary
<<control>>
TimeProcesor
<<boundary>>
KeypadBoundary
18
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.
Aircraft
1
owner
2
property
Engine
19
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.
20
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.
21
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.
22
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.
23
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.
24
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)
25
• Always use the user’s terms.
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.
26
Example: ReportEmergency
Use case name
ReportEmergency
Entry condition
1.The FieldOfficer activates the “Report Emergency”
function of his/her terminal.
Flow of Events
2.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.
27
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.
28
Entity Objects for ReportEmergency
Use Case
• Dispatcher
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.
• FieldOfficer
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.
29
Entity Objects for ReportEmergency
Use Case (Contd.)
• Emergency
Report
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.
• Incident
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.
30
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.
31
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.
32
Example: Boundary Objects for
ReportEmergency Use Case
• Acknowledgement
Notice
Notice used for displaying
Dispatcher’s acknowledgement
to the FieldOfficer.
• DispatcherStation
Computer used by the
Dispatcher.
• ReportEmergency
Button
Button used by a FieldOffier to
initiate the ReportEmergency
use case
33
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.
34
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
35
system.
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.
36
Example: Control Objects for
ReportEmergency Use Case
• ReportEmergency Manages the report emergency control
function on the FieldOfficer Station. This
Control
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.
37
Example: Control Objects for
ReportEmergency Use Case(Contd.)
• ManageEmergency Manages the report emergency reporting function on the DispatcherStation.
Control
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.
38
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.
39
Sequence Diagram for ReportEmergency Use Case
40
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.
41
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.
42
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.
43
Sequence Diagrams
• 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.
44
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.
45
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.
46
Example: Associations
FieldOfficer
*
author
1
EmergencyReport
document
47
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.
48
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
49
instances of classes) in particular contexts.
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.
50
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
51
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.
52
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.
53
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.
54
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.
55
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.
56
Example: UML State Chart for
Incident
57
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.
58
Example: Inheritance
relationship
59
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.
60
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.
61
62
Analysis Activities and Their
Relationships