CHAPTER - 5

OBJECT ORIENTED ANALYSIS

1
Outline
• Introduction
• An overview of Analysis
• Analysis concepts and activities
• Entity, boundary and Control objects
• Association Multiplicity, Qualified Associations,
Generalization.
• Identifying Entity objects, Boundary objects, Control
objects
• Modeling interaction between objects
• Identifying Associations and Attributes

2
 Introduction
• In object-oriented analysis, developers build a model describing
the application domain.

• Developers use the analysis model, together with non-functional

requirements, to prepare for the architecture of the system developed
during high-level design (eg. System design).

• In this chapter, we discuss the analysis activities in more detail:-

➢ The identification of objects
➢ their behaviour
➢ their relationships
➢ their classification, and
➢Their organization.

3
 An Overview of Analysis
• Analysis focuses on producing a model of the system, called the
analysis model, which is correct, complete, and consistent.

Fig1:Products of requirements elicitation and analysis (UML activity diagram).

4
• The analysis model is composed of three individual models: -

1-The functional model- represented by use cases and scenarios.

2-The analysis object model- represented by class and object diagrams.
3-The dynamic model- represented by state chart and sequence
diagrams.

Fig 2: The analysis model

5
 Analysis Concepts
• In this section, we describe the main analysis concepts used in this
chapter. In particular, we describe:-

• Entity, boundary and Control objects.

• Association
• Multiplicity
Have already been discussed in
• Qualified Associations
modelling with UML.
• Generalization.

6
 Entity, Boundary, and Control Objects
• The analysis object model - consists of entity, boundary, and
control objects.
• Entity objects -represent the persistent information tracked by the
system.
• Boundary objects -represent the interactions between the actors
and the system.
• Control objects -represent the tasks that are performed by the user
and supported by the system.
• Example 1:If you take watch:-
- Year, Month, Day are entity objects;
- Button and LCDDisplay are boundary objects;
- ChangeDate is a control object that represents the activity
of changing the date by pressing combinations of buttons.

7
8
Analysis Activities: From Use Cases to
Objects
➢In this section, we describe the activities that transform the use cases
and scenarios produced during requirements elicitation into an
analysis model.
➢Analysis activities include:-
- identifying entity objects
- identifying boundary objects
- identifying control objects
- mapping use cases to objects
- identifying associations among objects
- identifying object attributes
- modelling objects’s behavior with state charts
- modelling generalization relationships
- reviewing the analysis model
• We illustrate each activity by focusing on the ReportEmergency use
case of FRIEND described in Requirements Elicitation.
9
 Identifying Entity Objects
• Participating objects form the basis of the analysis model.

• participating objects are found by examining each use case and

identifying candidate objects.

• Natural language analysis [Abbott, 1983] is an intuitive set of

heuristics for:-

➢ identifying objects,
➢ attributes,
➢and associations from a system specification.

• Abbott’s heuristics maps parts of speech (e.g., nouns, having verbs,

being verbs, adjectives) to model components (e.g., objects,operations,
inheritance relationships, classes).

• Table 1 provides examples of such mappings by examining the

ReportEmergency use case.
10
11
• Use case name ReportEmergency

• Participating actor Initiated by Field Officer Communicates

with Dispatcher.
• Entry condition 1. The Field Officer activates the “Report
Emergency” function of her terminal.

• Flow of events 2. FRIEND responds by presenting a

form to the officer.

3. The Field Officer fills the form...

• Exit condition The Field Officer receives the

acknowledgment and the selected
response.

12
13
➢Heuristics for identifying initial analysis objects

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

• use cases (e.g., ReportEmergency)

14
➢Some of the entity objects for ReportEmergeny use case are:-

• Dispatcher -- Police officer who manages Incidents.

→A Dispatcher opens, documents, and closes Incidents in response to
EmergencyReports.

• EmergencyReport-- Initial report about an Incident from a

FieldOfficer to a Dispatcher.
→An EmergencyReport usually triggers the creation of an Incident
by the Dispatcher.

• FieldOfficer-- Police or fire officer on duty. A FieldOfficer can be

allocated to, at most, one Incident at a time.

• Incident -- Situation requiring attention from a FieldOfficer.

15
➢Identifying Boundary Objects
• Boundary objects represent the system interface with the actors.
• The boundary object collects the information from the actor and
translates it into an interface that can be used by the entity objects
and also by the control objects.

➢ Heuristics for identifying boundary objects

• Identify forms and windows the users needs to enter data into the
system (e.g.,EmergencyReportForm, ReportEmergencyButtonForm).

• Identify notices and messages the system uses to respond to the user
(e.g., AcknowledgmentNotice).

• Always use the user’s terms for describing interfaces as opposed to

terms from the implementation technology.

16
• These are some of boundary objects by examining the
ReportEmergency use case:-

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

➢ReportEmergencyForm- Form used for the input of the

ReportEmergency form.

➢FieldOfficerStation - Mobile computer used by the FieldOfficer.

17
➢Identifying Control Objects
• Control objects are responsible for coordinating boundary and
entity objects.
• It is responsible for collecting information from the boundary objects
and dispatching it to entity objects.
• For example, control objects describe the behaviour associated with:-
1-the sequencing of forms
2-undo and history queues, and
3- dispatching information in a distributed system.

➢Heuristics for identifying control objects:-

• Identify one control object per use case 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.

18
• Here is the model for the control flow of the ReportEmergency use
case with a control object for each actor;

- ReportEmergencyControl for the FieldOfficer and

- ManageEmergencyControl for the Dispatcher, respectively.

➢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 EmergencyReportForm and presents it to the
FieldOfficer.

• ManageEmergencyControl - Manages the report emergency

reporting function on the DispatcherStation.
• This object is created when an EmergencyReport is received.
• It then creates an IncidentForm and displays it to the Dispatcher.
19
➢Modelling Interactions Between Objects:

➢Sequence Diagrams

• A sequence diagram ties use cases with objects.

• It shows how the behaviour of a use case (or scenario) is

distributed among its participating objects.

• In this section, we model the sequence of interactions

among objects needed to realize the use case.

• The following three figures show sequence diagrams

associated with the ReportEmergency use case.
20
• The columns of a sequence diagram represent the objects
that participate in the use case.

• The leftmost column is the actor who initiates the use case.

• Horizontal arrows across columns represent messages, or

stimuli, which are sent from one object to the other.

• Time proceeds vertically from top to bottom.

21
Sequence diagram for the ReportEmergency use case (initiation from the
FieldOfficerStation side).
22
Sequence diagram for the ReportEmergency use case (DispatcherStation).

23
Sequence diagram for the ReportEmergency use case (acknowledgment on
the FieldOfficerStation).

24
25
➢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.
• Control objects are created by boundary objects initiating
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.

26
27
28
➢By constructing sequence diagrams:-

1- we can model the order of the interaction among the objects.

2- we also distribute the behaviour of the use case.

➢In other terms, we assign to each object responsibilities in the form

of a set of operations.

➢In analysis, sequence diagrams are used to help identify:-

1- new participating objects and
2- missing behaviour.

➢They focus on high-level behaviour, and, thus, implementation

issues such as performance should not be addressed at this point.

29
➢Identifying Associations

• Sequence diagrams -allow developers to represent interactions

among objects over time.

• Class diagrams- allow developers to describe the spatial

connectivity of objects.

• In this section, we discuss the use of class diagrams for representing

associations among objects and representing object attributes

• An association shows a relationship between two or more classes.

30
➢Associations have several properties:-
• A name, to describe the association between the two classes (e.g.,
Writes)
• A role at each end, identifying the function of each class with respect to
the associations (e.g., author is the role played by FieldOfficer in the
Writes association).
• A multiplicity at each end, identifying the possible number of instances
e.g.,
- * indicates a FieldOfficer may write zero or more EmergencyReports.
- 1 indicates that each EmergencyReport has exactly one FieldOfficer
as author.

31
➢Identifying Attributes
• Attributes are properties of individual objects.
• When identifying properties of objects, only the attributes relevant to
the system should be considered.
• (For example, each FieldOfficer has a social security number, Instead,
FieldOfficers are identified by badge number, represented by the
badgeNumber property.

Attributes of the EmergencyReport class.

32
➢Attributes have:-

• a name identifying them within an object.

→ an EmergencyReport may have a reportType
attribute and an emergencyType attribute.

• A brief description.
• A type describing the legal values it can take.
→ the description attribute of an EmergencyReport is a
string.

33
 Modelling the Behaviour of Individual
Objects
➢Sequence diagrams are used to distribute behaviour
across objects and to identify operations.
➢Sequence diagrams represent the behaviour of the
system from the perspective of a single use case.
➢Statechart diagrams represent behaviour from the
perspective of a single object.
• Viewing behaviour from the perspective of each object
enables the developer:-
- To identify missing use cases.
- To build a more-formal description of the behavior of
the object.

34
• The following Figure displays a statechart for the Incident
class.

➢The examination of this statechart may help the developer

check if there are use cases for documenting, closing, and
archiving Incidents.

35
 Modeling Generalization Relationships
Between Objects
• Generalization is used to eliminate redundancy from the
analysis model.
• If two or more classes share attributes or behavior, the
similarities are consolidated into a superclass.
• For example, Dispatchers and FieldOfficers both have a
badgeNumber attribute that serves to identify them within a
city.
• FieldOfficers and Dispatchers are both PoliceOfficers who
are assigned different functions.
• To model explicitly this similarity, we introduce an abstract
PoliceOfficer class from which the FieldOfficer and
Dispatcher classes inherit.

36
fig: An example of inheritance relationship (UML class diagram).

37
 Reviewing the Analysis Model
• The analysis model is built incrementally and iteratively.
• Once the analysis model becomes stable
• The analysis model is reviewed:
- first by the developers (i.e., internal reviews),
- then jointly by the developers and the client.

• The goal of the review is to make sure that the system

specification is correct, complete, consistent, and
realistic.

• The review can be facilitated by a checklist or a list of

questions.

38
correctness:
➢The following questions should be asked to ensure that the model is
correct:
• Is the glossary of entity objects understandable by the user?
• Do abstract classes correspond to user-level concepts?
• Are all descriptions in accordance with the users’ definitions?
• Do all entity and boundary objects have meaningful noun phrases
as names?
• Do all use cases and control objects have meaningful verb phrases
as names?
• Are all error cases described and handled?
• Are the start-up and the shut-down phases of the system
described?
• Are the administration functions of the system described?

39
Completeness
• The following questions should be asked to ensure that the
model is complete:
• For each object: Is it needed by any use case? In which use
case is it created? modified? destroyed? Can it be accessed
from a boundary object?
• For each attribute: When is it set? What is its type? Should
it be a qualifier?
• For each association: When is it traversed? Why was the
specific multiplicity chosen? Can associations with one-to-
many and many-to-many multiplicities be qualified?
• For each control object: Does it have the necessary
associations to access the objects participating in its
corresponding use case?

40
Consistency

➢The following questions should be asked to ensure that

the model is consistent:

• Are there multiple classes or use cases with the same

name?

• Do entities (e.g., use cases, classes, attributes) with similar

names denote similar phenomena?

• Are all entities described at the same level of detail?

• Are there objects with similar attributes and associations

that are not in the same generalization hierarchy?

41
Realistic
➢The following questions should be asked to ensure that
the system described by the analysis model is realistic:

• Are there any novel features in the system?

• Were there any studies or prototypes built to ensure their

feasibility?

• Can the performance and reliability requirements be met?

• Were these requirements verified by any prototypes

running on the selected hardware?

42
Analysis Summary

• The requirements activity is highly iterative and incremental.

• Chunks of functionality are sketched and proposed to the users and

the client.

• The client may add:-

- additional requirements
- criticizes existing functionality
- modifies existing requirements.

• The following Figure depicts a typical sequence of the analysis

activities we described in this chapter.

43
Analysis activities (UML activities diagram).
44