Software Engineering

Instructor: Mohammed Oumer[M.Sc.]

[email protected]
Samara University
 Chapter Five: Analysis
This Chapter Covers:
 Analysis Concepts
 Analysis Activities: From Use Cases to Objects
 An Overview of Analysis
Analysis is the process of extracting (take out) the needs of a
system and what the system must do to satisfy the users’
requirement.

Analysis step starts to identify some of the candidate objects /

classes that will be needed in the system.

Object Oriented Analysis (OOA) concerned with developing an

object oriented model of the application domain.

Analysis is different from requirements elicitation in that

developers focus on structuring (organizing) and formalizing
(shaping) the requirements elicited from users.
 Entity, Boundary, and Control Objects
The analysis object model consists of (made up of) entity,
boundary, and control objects.
Entity objects represent the persistent (continuously)
information tracked by the system. In the 2Bwatch, Year,
Month, Day are entity objects.

Boundary objects represent the interactions (influence)

between the actors and the system. ButtonBoundary and
LCDDisplayBoundary are boundary objects;

Control objects represent the tasks that are performed by

the user and supported by the system. ChangeDateControl is
a control object that represents the activity of changing the
date by pressing combinations of buttons.
 Analysis Activities: From Use Cases to Objects
Identifying Entity Objects
Participating objects form the basis (base) of the analysis
model.

Participating objects are found by examining each use case

and identifying candidate objects.

Natural language analysis is an intuitive (easy to understand)

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).
 An example of use case: Report-Emergency
Use case name: ReportEmergency
Entry condition 1. The FieldOfficer activates (switch on)
“Report Emergency” function of 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 (risky)
material fields.
 Cont.
3. 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.

4. The Dispatcher reviews the information submitted by the

FieldOfficer and creates an Incident in the database by
invoking the OpenIncident use case.
 Cont.
All the information contained (hold) 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 5. The FieldOfficer receives the

acknowledgment and the selected response.
 Identifying Boundary Objects
Boundary objects represent the system interface with the
actors. In each use case, each actor interacts with at least one
boundary object.
The boundary object collects the information from the actor
and translates it into an interface neutral form that can be used
by the entity objects and also by the control 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).
For example, boundary objects such as “button” or “menu
item” are too detailed.
 Identifying Control Objects
Control objects are responsible for coordinating (process of organizing)
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 behavior associated with the
sequencing of forms.

The control flow of the ReportEmergency use case with a control

object.

For each actor; ReportEmergencyControl for the FieldOfficerStation and

ManageEmergencyControl for the DispatcherStation, respectively.
 Heuristics for Identifying 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 (size) 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.
 Modeling Interactions Between Objects
A sequence diagram ties (bind) use cases with objects.

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

distributed among its participating objects.

Usually not a good medium (channel) for communication

with the user.

The columns of a sequence diagram represent the objects

that participate in the use case.
 Cont.

Horizontal arrows across columns represent messages, which

are sent from one object to the other.

Time proceeds (amount of time) vertically from top to bottom.

The receipt of a message triggers the activation of an

operation. The activation is represented by a rectangle from
which other messages can originate. The length of the rectangle
represents the time the operation is active.

An operation can be thought of as a service that the object

provides to other objects.
 Heuristics for Drawing Sequence Diagrams
The first column should correspond to the actor who
initiated the use case.

The second column should be an 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.
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.
 Examples
The HomePage and Log-in Page objects are boundary
objects, whereas the Account object is an entity object.
 Identifying Associations
An association shows (visible) a relationship between two
or more classes.

Identifying associations has two advantages.

1. It clarifies the analysis model by making relationships
between objects explicit (clear) (e.g., an EmergencyReport
can be created by a FieldOfficer or a Dispatcher).
2. It enables the developer to discover boundary cases
associated with links.
Boundary cases are exceptions (excluded from a general
statement or rule) that need to be clarified in the model.
 Cont.
For example, it is intuitive to assume that most
EmergencyReports are written by one FieldOfficer.
However, should the system support EmergencyReports
written by more than one? Should the system allow for
anonymous (unnamed) EmergencyReports? Those
questions should be investigated during analysis by using
domain knowledge.

An example of association between the EmergencyReport

and the FieldOfficer classes.
 Cont.
Associations have several properties:
• A name, to describe the association between the two
classes (e.g., Writes in Figure above). Association names are
optional and need not be unique globally.

• 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, whereas 1 indicates
that each EmergencyReport has exactly one FieldOfficer as
author.
 Heuristics for identifying associations
Examine verb phrases (denoting a state e.g., has, is part of,
manages, reports to, includes).

Name associations and roles precisely (accurately).

Eliminate any association that can be derived from other

associations.

Do not worry about multiplicity until the set of associations is

stable (fixed).

Too many associations make a model unreadable (eliminating

redundant association.).
 Identifying Attributes
Attributes are properties of individual objects.

For example, an EmergencyReport, has an emergency

type, a location, and a description property. These are
entered by a FieldOfficer when she reports an emergency
and are subsequently tracked by the system.

Only the attributes relevant (closely connected) to the

system should be considered. For example, each
FieldOfficer has a social security number (SSN – given to
each citizen of U.S. by the government) that is not relevant
to the emergency information system.

Instead, FieldOfficers are identified by badge number,

represented by the badgeNumber property.
 Heuristics for Identifying Attributes
Examine possessive phrases (a grammatical case that
denotes ownership).

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.
 Reviewing the Analysis Model
The analysis model is built incrementally and iteratively. It
is rarely correct or even complete on the first pass.

Once the analysis model becomes stable (i.e., when the

number of changes to the model are minimal), 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.
 Cont.
The following questions should be asked to ensure that the
model is correct:
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?
 Cont.
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?

For each attribute: When is it set? What is its type? Should

it be a qualifier?

For each association: When is it traversed (travel across)?

Why was the specific multiplicity chosen? Can associations
with one-to-many and many-to-many multiplicities be
qualified?
 Cont.
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 there objects with similar attributes and associations

that are not in the same generalization hierarchy?
 Cont.
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?
 Cont.
Analysis results in the requirements model described by the
following products (result):

A set of nonfunctional requirements and constraints, such as

response time, reliability, operating system platform, and so on.

A use case model, describing the functionality of the system from

the actors’ point of view.

An object model, describing the entities manipulated by the

system.

A sequence diagram for each use case, showing the sequence of

interactions among objects participating in the use case.
Thank You ...