4. oose analysis

Object-Oriented Software Engineering
Chapter 4
Object Oriented Analysis
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

An Overview of Analysis
Analysis focuses on producing a model of the
system, called the analysis model, which is
correct, complete, consistent, and
verifiable.
Developers focus on structuring and
formalizing the requirements elicited from
users
In object-oriented analysis, developers build a
model describing the application domain.

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

Analysis Model
The analysis model is composed of three
individual models:
• Functional model
– represented by use cases and scenarios,
• Analysis object model
– represented by class and object diagrams,
• Dynamic model
•represented by state chart and sequence
diagrams

Analysis Model

Stereotype Mechanism
• Stereotype mechanism is used to
 distinguish between different
types of objects in UML .
enables the developer to
attach meta info
• Boundary objects may have the
suffix <<Boundary>> appended
to their name;
• Control objects may have the
suffix <<Control>> appended to
their name;
• Entity objects usually do not have
any suffix appended to their
name sometimes <<entity>>

Analysis Concepts
Entity, Boundary, and Control Objects
• Entity objects represent the persistent information
tracked by the system. The main responsibilities of entity
classes are to store and manage information in 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
• The interface to the system (represented by boundary
objects) is more likely to change than its basic
functionality (represented by the entity and control
objects).

Role of boundary class

Modeling the system with entity, boundary, and
control objects has several advantages.
1. First, It provides developers with simple heuristics to
distinguish different, but related concepts by
differentiating between boundary and entity
objects
2. Second, the three object type approach results in
smaller and more specialized objects.
3. Third, the three object type approach leads to
models that are more resilient to change:
Analysis Concepts
Entity, Boundary, and Control Objects

Analysis classes for the 2Bwatch
example.

Association Multiplicity Revisited
• In Modeling with UML, the end of an association can
be labeled by a set of integers called multiplicity.
• Multiplicity indicates the number of links that can
legitimately originate from an instance of the class
connected to the association end
An example of multiplicity of associations (UML class
diagram). A 2B watch has two buttons and one LCD Display.

One-to-One Association
 A one-to-one association has a
 multiplicity 1 on each end.
 A one-to-one association between two classes
 (e.g., PoliceOfficer and BadgeNumber), means that
exactly one link exists between instances of each
class (e.g., a PoliceOfficer has exactly one
BadgeNumber, and a BadgeNumber denotes exactly
one PoliceOfficer).

A one-to-many association has a multiplicity 1
on one end and 0..n (also represented by * a
star) or 1..n on the other.
A one-to-many association between two classes
(e.g., a FireUnit owns one or more FireTrucks, a
FireTruck is owned exactly by oneFireUnit).
One-to-Many Association

 A many-to-many association has a multiplicity 0..n or 1..n
on both ends.
 A many-to- many association between two classes (e.g.,
FieldOfficer and IncidentReport) denotes that an arbitrary
number of links can exist between instances of the two
classes
 (e.g., a FieldOfficer can write for many IncidentReport, an
IncidentReport can be written by many FieldOfficers).
 Adding multiplicity to associations increases the
amount of information we capture from the
application or the solution domain
Many-to-Many Association

Qualified Associations –Text Example
 Qualification is a technique for reducing multiplicity by
using keys.
 Associations with a 0..1 or 1 multiplicity are easier to understand
than associations with a 0..n or 1..n multiplicity.
 Often, in the case of a one-to-many association, objects on the
“many” side can be distinguished from one another using a name.
 For example, in a hierarchical file system,
 Each file belongs to exactly one directory.
 Each file is uniquely identified by a name in the context of a
directory.
 Many files can have the same name in the context of the file
system;
 however, two files cannot share the same name within the same
directory.

 Without qualification, the association between
Directory and File has a one multiplicity on the
Directory side and a zero-to-many multiplicity on the
File side.
 We reduce the multiplicity on the File side by using
the filename attribute as a key, also called a qualifier
 The relationship between Directory and File is called
a qualified association
Qualified Associations

Generalization
 Generalization enables us to organize concepts into
hierarchies.
At the top of the hierarchy is a general concept (e.g.,
an Incident)
At the bottom of the hierarchy are the most
specialized concepts (e.g., CatInTree,
TrafficAccident, BuildingFire, EarthQuake,
ChemicalLeak).
 There may be any number of intermediate levels in
between, covering more-or-less generalized concepts
(e.g., LowPriorityIncident, Emergency, Disaster). .

Generalization

Analysis Activities:
From Use Cases to Objects
 Analysis activities include:
 identifying entity objects
 identifying boundary objects
 identifying control objects
 mapping use cases to objects
 identifying associations among objects
 identifying object attributes
 reviewing the analysis model

Identifying Entity Objects
Heuristics for identifying entity objects
 Developers or users need entity objects 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)

Use case name ReportEmergency
Entry condition The FieldOfficer activates the “Report Emergency” function
of her terminal
Flow of events  FRIEND responds by presenting a form to the officer
 The FieldOfficer fills the form, by specifying minimally
the emergency type and description fields. Once the form
is completed, the FieldOfficer submits the form by
pressing the “Send Report” button, at which point, the
Dispatcher is notified.
 The Dispatcher reviews the information submitted by the
FieldOfficer and creates an Incident in the database by
invoking the OpenIncident use case. acknowledges the
emergency report by sending a FRIEND gram to the
FieldOfficer
Exit condition The FieldOfficer receives the acknowledgment and the
selected response.

Entity objects for the ReportEmergency
use case
Dispatcher  Police officer who manages Incidents,
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.

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.
 Boundary objects model the user interface.
They do not describe in detail the visual aspects
of the user interface.

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

Boundary objects for the
ReportEmergency use case

Identifying Control Objects
 Control objects are responsible for coordinating
boundary and entity objects.
 There is often a close relationship between a use case
and a control object.
 A control object is usually 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 entity objects.
 For example, control objects describe the behavior
associated with the sequencing of forms, undo and
history queues, and dispatching information in a
distributed system

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

Control objects for the ReportEmergency
use case
ReportEmergency
Control
 Manages the report emergency reporting function on
the FieldOfficer Station.
 This object is created when the FieldOfficer selects the
“Report Emergency” button.
 It then creates an EmergencyReport Form 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
ReportEmergency Control object creates an
AcknowledgmentNotice and displays it to the
FieldOfficer.

Modeling Interactions Between Objects
Sequence Diagrams
 A sequence diagram ties use cases with objects
 shows how the behavior of a use case (or scenario) is
distributed among its participating objects.
 usually not a good medium for communication with the
user.
allow the developers to find missing objects or grey
areas in the system specification.
are used to help identify new participating objects and
missing behavior.
focus on high-level behavior, and, thus, implementation
issues such as performance should not be addressed at
this point.

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

Sequence diagram for the ReportEmergency use case (initiation
from the FieldOfficer Station side).

 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.
 For example, the arrow in Figure represents the press message sent
by a FieldOfficer to an ReportEmergencyButton
 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
Sequence diagram for the ReportEmergency use case (initiation
from the FieldOfficer Station side).

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

Sequence Diagram – Student Example

52
Sequence Diagrams
• Show classifier roles only (no association roles).
• The vertical dimension is the time and the messages
are drawn from top to bottom, in the order they are
sent.
• Each role has a lifeline:
– indicating the period of time during which objects playing
that role exist.
– Syntax: vertical dashed line below the classifier role.
• Messages are shown as arrows leading from the
lifeline of the message’s sender to that of the
receiver.

53
Sequence Diagrams
• The period of time during which an object is processing a
message is called activation.
– Syntax: narrow rectangle whose top is connected to a message.
• When an object finishes processing a message, the control
returns to the sender of the message.
– Syntax: dashed arrow from the bottom of activation rectangle back
to lifeline of the role that sent the message.
• The messages with solid arrowhead denote synchronous
messages, such as normal procedure calls (the object that
sends the message is suspended until the called object
returns the control to the caller).

54
Sequence Diagram: Simple Example
• Suppose statements are to be printed for bank
accounts:
– Bank passes the relevant Account to a Statement object
for printing.
Sequence Diagram

Identifying Associations
• An association shows a relationship between
two or more classes.
• For example, a FieldOfficer writes an
EmergencyReport

 First, it clarifies the analysis model by making
relationships between objects explicit
 (e.g., an EmergencyReport can be created by a FieldOfficer
or a Dispatcher).
 Second, it enables the developer to discover
boundary cases associated with links.
 Boundary cases are exceptions that need to be
clarified in the model.
Advantages of identifying Associations

Properties of Associations
 A name, to describe the association between the two classes
 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
Writesassociation).
 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.

Heuristics for identifying associations
1. Examine verb phrases.
2. Name associations and roles precisely.
3. Use qualifiers as often as possible to identify
namespaces and key attributes.
4. Eliminate any association that can be derived from
other associations.
5. Do not worry about multiplicity until the set of
associations is stable.
6. Avoid ravioli models: Too many associations make a
model unreadable

 We identified two relationships:
 the first between an Incident and the EmergencyReport that
triggered its creation;
 the second between the Incident and the reporting FieldOfficer.
 Given that the EmergencyReport and FieldOfficer already have an
association modeling authorship, the association between Incident
and FieldOfficer is not necessary.
 Adding unnecessary associations complicates the model, leading to
incomprehensible “ravioli models” and redundant information.
An Example - identifying associations

Identifying Attributes
Attributes are properties of
individual objects.
 Attributes have:
 a name identifying them within an object.
 For example, an EmergencyReport may have a reportType attribute and
an emergencyType attribute.
The reportType describes the kind of report being filed (e.g., initial
report, request for resource, final report).
The emergencyType describes the type of emergency (e.g., fire,
traffic, other).
 To avoid confusion, these attributes should not be both called type.
 A type describing the legal values it can take.
 For example, the description attribute of an EmergencyReport is a
string.
 The emergencyType attribute is an enumeration that can take one of
three values : fire, traffic, other.

Heuristics for identifying attributes
• Examine possessive phrases.
• Represent stored state as attributes of entity
object.
• 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
 Once the analysis model becomes stable (i.e., when the
number of changes to the model are minimal and the scope
of the changes localized), 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.
 Note that developers should be prepared to discover errors
downstream and make changes to the specification.

Analysis Model correct or not ..?
The following questions should be asked
to ensure that the model is correct
1. Is the glossary of entity objects understandable by the user?
2. Do abstract classes correspond to user-level concepts?
3. Are all descriptions in accordance with the users’ definitions?
4. Do all entity and boundary objects have meaningful noun
phrases as names?
5. Do all use cases and control objects have meaningful verb
phrases as names?
6. Are all error cases described and handled?
7. Are the start-up and the shut-down phases of the system
described?
8. Are the administration functions of the system described?

to ensure that the model is complete
1. For each object:
 Is it needed by any use case? In which use case is it created?
modified? destroyed?
 Can it be accessed from an boundary object?
2. For each attribute:
 When is it set? What is its type? Should it be a qualifier?
3. 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?
4. For each control object:
 Does it have the necessary associations to access the objects
participating in its corresponding use case?
Analysis Model complete or not ..?

to ensure that the model is consistent
1. Are there multiple classes or use cases with the same
name?
2. Do entities (e.g., use cases, classes, attributes) with
similar names denote similar phenomena?
3. Are all entities described at the same level of detail?
4. Are there objects with similar attributes and associations
that are not in the same generalization hierarchy?
Analysis Model consistent or not ..?

to ensure that the 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?
Analysis Model Realistic or not ..?

4. oose analysis

More Related Content

Viewers also liked

Similar to 4. oose analysis

4. oose analysis