COMSATS University, Islamabad

Object Oriented Software

Engineering

Analysis

Chapter 5
Recap
 An Overview of Requirements Elicitation
 Requirements elicitation activities
 Identifying actors
 Identifying scenarios
 Identifying use cases
 Refining use cases.
 Identifying relationships among use cases.
 Identifying nonfunctional requirements
 Classification Of requirements

2 Object Oriented Software Engineering

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

3 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

4 Object Oriented Software Engineering

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

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

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

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

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

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

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

11 Object Oriented Software Engineering

Generalization Hierarchy (UML class diagram)

12 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

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

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

15 Object Oriented Software Engineering

Analysis Activities: From Use Cases to
Objects

16 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

Object Oriented Software Engineering

17
Entity objects for the ReportEmergency use
case.

Object Oriented Software Engineering

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

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

20 Object Oriented Software Engineering

 • EmergencyReportButton

• EmergencyReportForm

• AcknowledgmentNotice

• DispatcherStation

• FieldOfficerStation

• IncidentForm

Heuristics for identifying boundary 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
21
Boundary objects for the ReportEmergency
use case.

22 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

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

24 Object Oriented Software Engineering

Control objects for the ReportEmergency
use case

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

26 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

Object Oriented Software Engineering

27
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.
Object Oriented Software Engineering
28
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).

Object Oriented Software Engineering

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

Object Oriented Software Engineering

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

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

32 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?

33 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).
34 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.

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

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

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

38 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

39 Object Oriented Software Engineering

Modeling State-Dependent Behavior of
Individual Objects
 Sequence diagrams are used to distribute behavior across objects and to identify
operations.
 State machine diagrams represent behavior from the perspective of a single
object.
 By focusing on individual states, developers may identify new behavior.
 For example,
 By examining each transition in the state machine diagram that is triggered by a user
action,
 the developer should be able to identify a flow step in a use case that describes the actor
action that triggers the transition.
 Note that it is not necessary to build state machines for every class in the system.
 Only objects with an extended lifespan and state-dependent behavior are worth
considering.
 This is almost always the case for control objects, less often for entity objects,
and almost never for boundary objects.

40 Object Oriented Software Engineering

UML state machine for Incident

41 Object Oriented Software Engineering