OBJECT OREINTED SOFTWARE

ENGINEERING

CHAPTER FOUR
ANALYSIS
 Overview of analysis
•Analysis results in analysis model of the system that aims to be
correct, complete, consistent, and verifiable.
•Developers formalize the system specification produced during requirements
elicitation and examine in more detail boundary conditions and exceptional case

•The analysis model is composed of three individual models

Functional model
represented by use cases and scenarios
object model:
represented by class and object diagram
dynamic model:
represented by state chart and sequence diagrams
 Analysis Concepts
Entity, Boundary, and Control Objects
The analysis object model consists of
• Entity objects
– represent the persistent information tracked by the system
• Boundary
– represent the interactions between the actors and the system
• Control objects
– Represent the tasks(operation) that are performed by the user and
supported by the system.
Example: In the 2Bwatch
 entity objects : Year , Month ,Day
 boundary objects: Button Boundary and LCDDisplayBoundary;
 control object :ChangeDateControl: is a that represents the activity of
changing the date by pressing combinations of buttons.
• To distinguish between different types of objects, UML provides
the stereotype mechanism to attach such meta information to
modeling elements
• For example:
– we attach the <<control>> stereotype to the ChangeDateControl object
 Association Multiplicity
• In modeling with UML, the end of an association can be labeled by
a set of integers called multiplicity
• The multiplicity indicates the number of links that can legitimately
originate from an instance of the class connected to the
association end
• In practice, however, most of the associations we encounter
belong to one of the following three types
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., Person and
Car ) denotes composition (e.g., a FireUnit owns one or more
FireTruck s, a FireTruck is owned exactly by one FireUnit ).
many-to-many association
• has a multiplicity 0..n or 1..n on both ends
• denotes that an arbitrary number of links can exist between
instances of the two classes
• eg A FieldOfficer can write for many IncidentReport , an
IncidentReport can be written by many FieldOfficer
 Generalization
• In Modeling with UML, generalization enables us to organize
concepts into hierarchies.
• At the top of the hierarchy is a general concept
– at the bottom of the hierarchy are the most specialized concepts
• There may be any number of intermediate levels in between,
covering more-or-less generalized concepts
• hierarchies allow us to refer to many concepts precisely
• Example: When we use the term Incident, we mean all instances
of all types of Incidents.
– When we use the term Emergency, we only refer to an Incident that requires
an immediate response
• Permits reusability technique through inheritance.
• B.c Child inherits from a class Parent, all the attributes and
methods available and the class Child may add additional
methods or override inherited methods, thus refining the class
Parent
 Analysis Activities: From Use Cases to Objects
 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
 modeling nontrivial behavior with statecharts
 modeling generalization relationships
 reviewing the analysis model
 We illustrate each activity by focusing on the ReportEmergency use
case of FRIEND
 1. Identifying Entity Objects
• Natural language analysis is an intuitive set of heuristics for
identifying objects, attributes, and associations from a system
specification
• But some times imprecise(eg some are non relevant class, writing style problem)
• Heuristics for identifying 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 user’s terms
• For example, after a first examination of the ReportEmergency use
case (Figure 5-11), we use application domain knowledge and
interviews with the users to identify the objects Dispatcher,
EmergencyReport, FieldOfficer, and Incident
• The definition of entity objects leads to the initial analysis model
described in Table 5-2.
• Note that the above object model is far from being a complete
description of the system implementing the ReportEmergency use
case. Unless boundary object is identified
 2. 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
• They 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.
• 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
• Note that the IncidentForm is not explicitly mentioned anywhere
in the ReportEmergency use case.
• We identified this object by observing that the Dispatcher needs
an interface to view the emergency report submitted by the
FieldOfficer and to send back an acknowledgment
• We now have included the interface between the actor and the
system.
– We are, however, still missing some significant pieces of the description, such
as the order in which the interactions between the actors and the system occur
 3. 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
 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
• we model the control flow of the ReportEmergency use case with a
control object for each actor;
– ReportEmergencyControl for the FieldOfficer
– and ManageEmergencyControl for the Dispatcher
• The decision to model the control flow of the ReportEmergency use case with
two control objects
– stems from the knowledge that the FieldOfficerStation and the DispatcherStation
are actually two subsystems communicating over an asynchronous link
 4. Modeling Interactions Between Objects: Sequence Diagrams
• A sequence diagram ties use cases with objects.
• It shows how the behavior of a use case (or scenario) is distributed
among its participating objects.
• Sequence diagrams are usually not a good medium for
communication with the user.
– They represent, however, another shift in perspective and allow the developers
to find missing objects or grey areas in the system specification.
• 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
• 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
• 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

• In general, the second column of a sequence diagram represents
the boundary object with which the actor interacts to initiate the
use case (e.g., ReportEmergencyButton).
• The third column is a control object that manages the rest of the
use case (e.g., ReportEmergencyControl).
• From then on, the control object creates other boundary objects
• and may interact with other control objects as well (in this case,
the ManageEmergencyControl object)
In Figure 5-13, we discover the entity object Acknowledgment that we forgot
during our initial examination of the ReportEmergency use case (in Table 5-2).
The Acknowledgment object is different from an AcknowledgmentNotice: It holds
the information associated with an Acknowledgment and is created before the
• When describing the Acknowledgment object, we also realize that the
original ReportEmergency use case (described in Figure 5-11) is
incomplete.
• It only mentions the existence of an Acknowledgment and does not
describe the information associated with it.
• In this case, developers need clarification from the client to define what
information needs to appear in the Acknowledgment
– By sending an Acknowledgment, the Dispatcher communicates to
the FieldOfficer that she has received the EmergencyReport, created
an Incident, and assigned resources to it. The Acknowledgment
contains the assigned resources and their estimated arrival time