Chapter Four

Object oriented System Analysis

An overview of Analysis
 There have been basically 3 approaches in information system
development area: process-oriented, data-oriented and object-
oriented approaches.
 As information technology (both hardware and software) has
been advancing, people have moved from the earliest process-
oriented approach to data-oriented approach and now begun to
adopt the latest object-oriented analysis methodology.
 Unlike process-oriented and data-oriented that focus either on
process or data, the object-oriented approach combines data and
processes (called methods and attributes) into single entities
called objects.
 Objects usually correspond to the real things an information
system deals with, such as customers, suppliers, contracts, and
rental agreements.
Cont..
 The goal of object-oriented approach is to make system elements
more reusable, thus improving system quality and the productivity
of systems analysis and design
 In object-oriented analysis, developers build a model describing the
application domain
 Analysis is different from requirements elicitation in that developers
focus on structuring and formalizing the requirements elicited from
users
 This formalization leads to new insights/understanding and the
discovery of errors in the requirements.
 Once we’ve some use cases or user stories, the next thing we can do
is create a conceptual model and dynamic of our system.
 It simply means you’re identifying the most important objects and
behaviors of the system.
 Analysis Object Models and Dynamic
Models
 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.
Cont..
 The dynamic model is represented with sequence diagrams,
activity diagrams and with state machine diagrams.
o Sequence diagrams represent the interactions among a set
of objects during a single use case.
o 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.
Entity, Boundary, and Control Objects
 The analysis 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.
Identify Entity, Boundary, and Control Objects
Example – Report Emergency Use Case:
 The Fireman on duty notices a fire incident. The Fireman or his
Replacement (hereafter termed Initiator) reports the emergency
from their car by using the SYSTEM.
 The Initiator enters the address of the corresponding fireplace, a
brief description of its location (i.e., north west corner), and an
emergency level. In addition to a fire unit, the Initiator requests
several paramedic units on the scene. He confirms his input and
waits for an acknowledgment.
 The Dispatcher on duty, is alerted to the emergency by a beep of
his workstation. He reviews the information submitted by the
Initiator and acknowledges the report. He allocates a fire unit
and a suitable number of paramedic units to the Incident site
and sends their estimated arrival time back to the Initiator.
 The Initiator receives the acknowledgment and the ETA.
Analysis activities/Identify entity object
Heuristics for identifying entity objects

 Recurring nouns in the use cases (e.g., Incident)

 Real-world entities that the system needs to track (e.g.,

FieldOfficer, Dispatcher, Resource)

 Real-world activities that the system needs to track (e.g.,

EmergencyOperationsPlan)

 Data sources or sinks (e.g., Printer).

 Example-Entity objects for the
ReportEmergency use case
 Dispatcher- Police officer who manages Incidents. A Dispatcher opens,
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 an emergency level, a
type (fire, road accident, other), a location, and a description.
 FieldOfficer - Police or fire officer on duty. A FieldOfficer can be allocated
to, at most, one Incident at a time. FieldOfficers are identified by badge
numbers.
 Incident - Situation requiring attention from a FieldOfficer. An Incident may
be reported in the system by a FieldOfficer or anybody else external to the
system. An Incident is composed of a description, a response, a status (open,
closed, documented), a location, and a number of FieldOfficers.
 Analysis activities/ Identifying
Boundary Objects
 Boundary objects represent the system interface with the actors
 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
 Heuristics for identifying boundary objects
o Identify user interface controls that the user needs to initiate the
use case (e.g., ReportEmergencyButton).
o Identify forms the users needs to enter data into the system (e.g.,
EmergencyReportForm).
o Identify notices and messages the system uses to respond to the
user (e.g., AcknowledgmentNotice).
 Example-Boundary objects for the
ReportEmergency use case
 AcknowledgmentNotice - Notice used for displaying the Dispatcher’s
acknowledgment to the FieldOfficer.
 DispatcherStation - Computer used by the Dispatcher.
 ReportEmergencyButton - Button used by a FieldOfficer to initiate the
ReportEmergency use case.
 EmergencyReportForm - Form used for the input of the ReportEmergency.
This form is presented to the FieldOfficer on the FieldOfficerStation when the
“Report Emergency” function is selected. The EmergencyReportForm contains
fields for specifying all attributes of an emergency report and a button (or other
control) for submitting the completed form.
 FieldOfficerStation - Mobile computer used by the FieldOfficer.
 IncidentForm - Form used for the creation of Incidents. This form is presented
to the Dispatcher on the DispatcherStation when the EmergencyReport is
received. The Dispatcher also uses this form to allocate resources and to
acknowledge the FieldOfficer’s report.
 Analysis activities/Identifying Control
Objects
 Control objects are responsible for coordinating boundary and
entity objects.

 Heuristics for identifying control objects

o Identify one control object per use case.

o Identify one control object per actor in the use case.

o The life span of a control object should cover the extent of the
use case or the extent of a user session.
 Example-Control objects for the
ReportEmergency use case
 ReportEmergencyControl - Manages the ReportEmergency reporting
function on the FieldOfficerStation. This object is created when the
FieldOfficer selects the “Report Emergency” button. It then creates an
EmergencyReportForm and presents it to the FieldOfficer. After
submitting 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
ReportEmergencyControl object creates an AcknowledgmentNotice and
displays it to the FieldOfficer.
 ManageEmergencyControl - Manages the ReportEmergency reporting
function on the DispatcherStation. This object is created when an
EmergencyReport is received. It then creates an IncidentForm and displays
it to the Dispatcher. Once the Dispatcher has created an Incident, allocated
Resources, and submitted an acknowledgment, ManageEmergencyControl
 Analysis activities/Mapping Use Cases to
Objects with Sequence Diagrams
 Sequence diagram shows how the behavior of a use case (or scenario) is
distributed among its participating objects.
 Heuristics for drawing sequence diagrams
o The first column should correspond to the actor who initiated the use
case.
o The second column should be a boundary object (that the actor used
to initiate the use case).
o The third column should be the control object that manages the rest of
the use case.
o Control objects are created by boundary objects initiating use cases.

o Boundary objects are created by control objects.

o Entity objects are accessed by control and boundary objects.

o Entity objects never access boundary or control objects; this makes it

easier to share entity objects across use cases.
Example-Sequence diagram for the
ReportEmergency use case
Cont..
Cont..
 Analysis activities/Object model
 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
Sequence diagrams allow developers to represent interactions
among objects over time, while
class diagrams allow developers to describe the
interdependencies of objects
Cont..
 Class diagrams appear in different contexts. It is very convenient to
classify them based on the stages of the software engineering
lifecycle where they are used.
 Analysis-level classes are the elements of the problem domain.
They help us to understand and document the problem space.
 Design-level classes are about how to transform domain structures
into technical structures so we work in the solution space instead of
the problem space.
 Design-level classes combine domain motivations with technical
aspects. Some of the classes are closer to the domain elements while
others are closer to the elements of the solution.
 Implementation-level classes show how a solution is given. These
classes map directly to the corresponding construct of the
implementation language (Java, C# or C++, etc.).
 Cont..
 A software application is consist of classes and a diagram
depicting(describing ) the relationship between each of
these classes would be the class diagram.
 A class diagram consists of a group of classes and
interfaces reflecting important entities of the business
domain of the system being modeled, and the relationships
between these classes and interfaces.
 A thing to remember is that a class diagram is a static view
of a system.
 The structure of a system is represented using class diagrams.
 Class diagrams are referenced time and again by the developers
while implementing the system.
Cont..
 Now you now know what a class diagram is. But, how does a
class diagram relate to the use case diagrams that you read
about in the earlier classes?
 When you designed the use cases, you must have realized
that the use cases talk about "what are the requirements" of a
system. The aim of designing classes is to convert this "what"
to a "how" for each requirement. Each use case is further
analyzed and broken up into atomic components that form
the basis for the classes that need to be designed.
 However, besides use cases, the artifacts of a project, such as
stakeholder requests, (signed off) requirement documents,
functional specifications, and a glossary of terms for the
project serve as other important inputs to the discovery of
classes.
 Activities during Object Modeling
Main goal: Find the important abstractions
 Steps during object modeling
1. Class identification
o Based on the fundamental assumption that we can
find abstractions
2. Identifying attributes
3. Identifying methods
4. Identifying associations between classes
 What happens if we find the wrong abstractions?
o We iterate and revise the model
 Class Identification
Class identification is essential to object-oriented modeling
o Helps to identify the important entities of a system
Basic assumptions:
1. We can find the classes for a new software system (Forward
Engineering): A software which is constructed from the zero level
'Core' is called forward engineering
2. We can identify the classes in an existing system (Reverse
Engineering):
 Obtaining a class model from existing source code is called reverse
engineering.
 This is generally done when
 It is required to understand the architecture of an existing system,
 either for re-engineering,
 for maintenance,
 upgrade or which is needed to be shift to other operating system.
 Cont..
Approaches
 Application domain approach
o Ask application domain experts to identify relevant
abstractions/concepts
 Syntactic approach
o Start with use cases
o Analyze the text to identify the objects
o Extract participating objects from flow of events
 Component-based approach
o Identify existing solution classes.
 Identifying Objects and Classes
o Abbott and Booch suggest:
o use nouns, pronouns, noun phrases to identify objects and classes

o Pick a use case and look at flow of events

o Do a textual analysis (noun-verb analysis)

o Nouns are candidates for objects/classes

o Verbs are candidates for operations

o After objects/classes are found, identify their types(entity,

boundary, control )
o Coad and Yourdon suggest:
o identify individual or group "things" in the system/problem

o Ross suggests common object categories:

o people o Organizations
o places o Concepts
o things
o events
Cont..
 Classes/Objects are not just found by taking a picture of
a scene or domain
o The application domain has to be analyzed

o Depending on the purpose of the system different

objects might be found
o How can we identify the purpose of a system?
 Scenarios and use cases => Functional model
 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.
Instead, FieldOfficers are identified by badge number, which is
represented by the badgeNumber property.
Cont..
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)
 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.
Cont..
It is not good to have many duplicate attributes
If a subset of a class’s attributes form a coherent group, then
create a distinct class containing these attributes
Pe rson Pe rson Pe rson Address
* address es
name name name * street
addresses street1 municipality
municipality1 provOrState
provOrState1 country
Bad due to country1 postalcode
a plural postalCode1 type
attribute street2
municipality2 Good solution. The
provOrState2 type indicates whether
country2
postalCode2
it is a home address,
business address etc.
Bad due to too many
attributes, and inability
to add more addresses
 Identifying operations(methods)
 Operations are needed to realize the responsibilities of
each class
o There may be several operations per responsibility

o The main operations that implement a responsibility

are normally declared public
o Other methods that collaborate to perform the
responsibility must be as private as possible
 Find the associations between classes
 An association shows a relationship between two or more
classes.
 For example, a FieldOfficer writes an EmergencyReport.
 Identifying associations has two advantages.
o 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).
o Second, it enables the developer to discover boundary
cases associated with links (e.g. , it is natural to assume
that most EmergencyReports are written by one
FieldOfficer)
Who uses and does not use Class Diagrams?
 Purpose of class diagrams
o The description of the static properties of a system

 The main users of class diagrams:

o The developer
 uses class diagrams during the development of a
system
 during analysis, system design, object design and
implementation.
 The client and the end user are usually not interested in
class diagrams
o Clients focus more on project management issues

o End users are more interested in the functionality of the

system.
 Reviewing the Analysis Model
 The analysis model is built incrementally and iteratively.
 Several iterations with the client and the user are necessary
before the analysis model converges toward a correct
specification usable by the developers for design and
implementation
 Then the analysis model is reviewed
 first by the developers (i.e., internal reviews),
then jointly by the developers and the client.
Cont..
 The goal of the review is to make sure that the
requirements specification is correct, complete, consistent,
and unambiguous
The following questions should be asked to ensure that the
model is correct:
 Is the glossary of entity objects understandable by the
user?
 Do abstract classes correspond to user-level concepts?
 Are all descriptions in accordance with the users’
definitions?
 Do all entity and boundary objects have meaningful?
 Do all use cases and control objects have meaningful?
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?
 For each association: Why was the specific multiplicity
chosen? Can associations with one-to-many and many-to-
many multiplicities be qualified?
 For each control object: Does it have the necessary
associations to access the objects participating in its
corresponding use case?
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 concepts?
 Are there objects with similar attributes and associations that
are not in the same generalization hierarchy?
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 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?
 General Order of activities in modeling
 Formulate a few scenarios with help from the end user and/or
application domain expert.
 Extract the use cases from the scenarios, with the help of
application domain expert.
 Analyse the flow of events, for example with Abbot's textual
analysis.
Generate the class diagrams, which includes the
following steps, as before:
o Class identification (textual analysis, domain experts).
o Identification of attributes and operations (sometimes
before the classes are found!)
o Identification of associations between classes
o Identification of multiplicities
o Identification of roles
o Identification of constraints
 Requirements Analysis Questions
1. What are the transformations?
Functional
Create scenarios and use case diagrams
Modeling
Talk to client, observe, get historical records
2. What is the structure of the system?
Create class diagrams Object
- Identify objects. Modeling
- What are the associations between them?
- What is their multiplicity?
- What are the attributes of the objects?
- What operations are defined on the objects?
3. What is its behavior?
Create sequence diagrams Dynamic
- Identify senders and receivers Modeling
- Show sequence of events exchanged between objects.
- Identify event dependencies and event concurrency.
Requirements Analysis Document Template
1. Introduction
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.4 System models
3.4.1 Use case model
3.4.2 Scenarios
3.4.3 Dynamic models
3.4.4 Object models
3.4.5 User interface
4. Reference