Object Oriented Software

Engineering

Analysis
An Overview of Analysis
 Analysis is different from requirements elicitation in that
developers focus on structuring and formalizing the
requirements elicited from users (Figure 5-2).

 This formalization leads to new insights and the discovery

of errors in the requirements.

 Developers need to update the requirements

specification to reflect insights gained during analysis, then
review the changes with the client and the users

2 Object Oriented Software Engineering

Analysis Model
 The analysis model is composed of three individual models:
 the functional model, represented by use cases and scenarios,
 the analysis object model, represented by class and object
diagrams, and
 the dynamic model, represented by state machine and sequence
diagrams

3 Object Oriented Software Engineering

Analysis Concepts
 Analysis Object Models and Dynamic Models
 Entity, Boundary, and Control Objects
 Generalization and Specialization

4 Object Oriented Software Engineering

Analysis Object Models
 The analysis model represents the system under
development from the user’s point of view.
 The analysis object model is a part of the analysis
model and focuses on the individual concepts that are
manipulated by the system, their properties and their
relationships.
 The analysis object model, depicted with UML class
diagrams, includes classes, attributes, and operations.
 The analysis object model is a visual dictionary of the
main concepts visible to the user.

5 Object Oriented Software Engineering

Dynamic Models
 The dynamic model focuses on the behavior of the
system.
 The dynamic model is depicted with sequence diagrams
and with state machines.
 Sequence diagrams represent the interactions among a
set of objects during a single use case.
 State machines represent the behavior of a single object
(or a group of very tightly coupled objects).
 The dynamic model serves to assign responsibilities to
individual classes and, in the process, to identify new
classes, associations, and attributes to be added to the
analysis object model.

6 Object Oriented Software Engineering

Models Representation at Analysis Level
 When working with either the analysis object model or the
dynamic model, it is essential to remember that these models
represent user-level concepts, not actual software classes or
components.
 For example, classes such as Database, Subsystem, SessionManager,
Network, should not appear in the analysis model as the user is
completely shielded from those concepts.

7 Object Oriented Software Engineering

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 are in charge of realizing use cases.
 In the Satwatch example,
 Year, Month, and Day are entity objects;
 Button and LCDDisplay are boundary objects;
 ChangeDateControl is a control object that represents the activity
of changing the date by pressing combinations of buttons.

8 Object Oriented Software Engineering

Analysis classes for the Satwatch example.
 The three-object- type approach also leads to models
that are more resilient to change:
 the interface to the system (represented by the boundary
objects) is more likely to change than its basic functionality
(represented by the entity and control objects).
 UML provides the stereotype mechanism to enable the
developer to attach such meta-information to modeling
elements.

9 Object Oriented Software Engineering

Generalization and Specialization
 Modeling with UML, inheritance enables us to organize
concepts into hierarchies.
 At the top of the hierarchy is a general concept (e.g., an Incident,
Figure 5-6), and
 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).
 Such hierarchies allow us to refer to many concepts precisely.
 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.

10 Object Oriented Software Engineering

Generalization Hierarchy (UML class diagram)

11 Object Oriented Software Engineering

Analysis Activities: From Use Cases to
Objects
 Identifying Entity Objects
 Identifying Boundary Objects
 Identifying Control Objects
 Mapping Use Cases to Objects with Sequence Diagrams
 Modeling Interactions among Objects with CRC Cards
 Identifying Associations
 Identifying Aggregates
 Identifying Attributes
 Modeling State-Dependent Behavior of Individual Objects
 Modeling Inheritance Relationships
 Reviewing the Analysis Model

12 Object Oriented Software Engineering

Identifying Entity Objects
 Natural language analysis is an intuitive set of heuristics
for identifying objects, attributes, and associations from a
requirements specification.

13 Object Oriented Software Engineering

Natural language analysis limitations
 The quality of the object model depends highly on the
style of writing of the analyst
 (e.g., consistency of terms used, verbification of nouns).

 There are many more nouns than relevant classes. Many

nouns correspond to attributes or synonyms for other
nouns.

14 Object Oriented Software Engineering

Analysis Activities: From Use Cases to
Objects

15 Object Oriented Software Engineering

 • Recurring (e.g., Incident)

• Real-world entities (e.g.,

FieldOfficer, Dispatcher,
Resource)

• Real-world activities (e.g.,

EmergencyOperationsPla
n)

• Data sources or sinks

(e.g., Printer).

Heuristics for identifying entity objects

• Recurring nouns in the use cases
• Real-world entities that the system needs to track
• Real-world activities that the system needs to track
• Data sources or sinks

16 Object Oriented Software Engineering

Entity objects for the ReportEmergency
use case.

17 Object Oriented Software Engineering

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 a form that can be used by
both entity and control objects.

18 Object Oriented Software Engineering

Note
 Do not model the visual aspects of the interface
with boundary objects (user mock-ups are better
suited for that).
 Always use the end user’s terms for describing
interfaces; do not use terms from the solution or
implementation domains.

19 Object Oriented Software Engineering

 • EmergencyReportButton

• EmergencyReportForm

• AcknowledgmentNotice

• DispatcherStation

• FieldOfficerStation

• IncidentForm

Heuristics for identifying entity objects

• Identify user interface controls that the user needs
to initiate the use case Identify forms the users
needs to enter data into the system .
• Identify notices and messages the system uses to
respond to the user .
• When multiple actors are involved in a use case,
identify actor terminals to refer to the user
interface under consideration.Object Oriented Software Engineering
20
Boundary objects for the ReportEmergency
use case.

21 Object Oriented Software Engineering

Identifying Control Objects
 Control objects are responsible for coordinating
boundary and entity objects.
 Control objects usually do not have a concrete
counterpart in the real world.
 It is responsible for collecting information from the
boundary objects and dispatching it to entity objects.
 Initially, we model the control flow of the
ReportEmergency use case with a control object for each
actor:
 ReportEmergencyControl for the FieldOfficer and
 ManageEmergency-Control for the Dispatcher, respectively

22 Object Oriented Software Engineering

Heuristics for identifying control objects
 Identify one control object per use case.
 Identify one control object per actor in the use case.
 The life span of a control object should cover the 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
probably does not have well-defined entry and exit
conditions.

23 Object Oriented Software Engineering

Control objects for the ReportEmergency
use case

24 Object Oriented Software Engineering

Mapping Use Cases to Objects with
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 allow the developers to find missing
objects or grey areas in the requirements specification.
 Sequence diagrams also depict the lifetime of objects.

25 Object Oriented Software Engineering

Sequence Diagram Semantics
 The columns of a sequence
diagram represent the objects
that participate in the use case.
 The left-most column is the actor
who initiates the use case.
 Horizontal arrows across columns
represent messages, or stimuli,
that are sent from one object to
the other.
 Time proceeds vertically from top
to bottom.
 The receipt of a message triggers
the activation of an operation.
 The activation is represented by a
vertical rectangle from which
other messages can originate.
 The length of the rectangle
represents the time the operation
is active

26 Object Oriented Software Engineering

Sequence Diagram Semantics
 An operation can be thought of as a
service that the object provides to
other objects.
 Sequence diagrams also depict the
lifetime of objects.
 Objects that already exist before the
first stimuli in the sequence diagram
are depicted at the top of the
diagram.
 Objects that are created during the
interaction are depicted with the
«create» message pointing to the
object.
 Instances that are destroyed during
the interaction have a cross
indicating when the object ceases to
exist.
 A dashed line represents the time
span when the object can receive
messages.
 The object cannot receive messages
below the cross sign.
27 Object Oriented Software Engineering
Sequence diagram for the ReportEmergency
use case
 Aan object of class
ReportEmergencyForm is created
when object of
ReportEmergencyControl sends the
«create» message and is destroyed
once the EmergencyReportForm has
been submitted.
 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., ReportEmergency–
Control).
 From then on, the control object
creates other boundary objects and
may interact with other control
objects as well (e.g.,
ManageEmergencyControl).

28 Object Oriented Software Engineering

Sequence diagram for the ReportEmergency
use case (continued).
 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:
Acknowledgment holds the
information associated with an
Acknowledgment and is created
before the AcknowledgmentNotice
boundary object.
 When describing the
Acknowledgment object, we also
realize that the original
ReportEmergency use case
(described in Figure 5-7) is
incomplete. It only mentions the
existence of an Acknowledgment
and does not describe the
information associated with it.

29 Object Oriented Software Engineering

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.
30 Object Oriented Software Engineering
Modeling Interactions among Objects
with CRC Cards
 CRC cards (CRC stands for class, responsibilities, and
collaborators).
 Each class is represented with an index card (called the CRC
card).
 The name of the class is depicted on the top,
 Its responsibilities in the left column, and
 The names of the classes it needs to accomplish its responsibilities are
depicted in the right column.

31 Object Oriented Software Engineering

Identifying Associations
 An association shows a relationship between two or
more classes.
 For example, a FieldOfficer writes an EmergencyReport (.
 Identifying associations has two advantages.
 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 exceptions
associated with links.
 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 EmergencyReports?

32 Object Oriented Software Engineering

Properties of Associations
 A name to describe the association between the two classes
 (e.g., Writes ). 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).

 Associations can be identified by examining verbs and verb phrases

denoting a state (e.g., has, is part of, manages, reports to, is triggered by,
is contained in, talks to, includes).
33 Object Oriented Software Engineering
Identifying Aggregates
 Aggregations are special types of associations denoting a whole–part relationship.
 For example, a FireStation consists of a number of FireFighters, FireEngines,
Ambulances, and a LeadCar.
 A State is composed of a number of Counties that are, in turn, composed of a
number of Townships.
 An aggregation is shown as a association with a diamond on the side of the whole
part.
 There are two types of aggregation, composition and shared. A solid diamond
denotes composition.

34 Object Oriented Software Engineering

Composition Aggregation
 A composition aggregation
indicates that the existence of the
parts depends on the whole.
 For example, a County is always part
of exactly one State, a Township is
always part of a County.
 As political boundaries do not change
often, a Township will not be part of
or shared with another County (at
least, in the life time of the emergency
response system).

35 Object Oriented Software Engineering

Shared Aggregation
 A hollow diamond denotes a shared aggregation
relationship, indicating the whole and the part can exist
independently.
 For example, although a FireEngine is part of at most one
FireStation at the time, it can be reassigned to a different
FireStation during its life time.

36 Object Oriented Software Engineering

Identifying Attributes
 Attributes are properties of individual objects.
 For example, an EmergencyReport has an emergency type, a
location, and a description property.
 When identifying properties of objects, only the
attributes relevant to the system should be considered.
 For example, each FieldOfficer has a social security number
that is not relevant to the emergency information system.

37 Object Oriented Software Engineering

Modeling Inheritance 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

38 Object Oriented Software Engineering