UNIVERSITY OF TECHNOLOGY, JAMAICA

SCHOOL OF COMPUTING & INFORMATION TECHNOLOGY

COURSE NAME: Software Requirements Definition (SRD)
Introduction to Software Engineering (SE 1)
TITLE (UNIT 4): Object-Oriented Techniques for Requirement Elicitation
READING: Breugge & Dutoit, Section 4.4 and 5.4
Pressman Chapters 20 & 21

There are many benefits attributed to Object-Oriented software development. Among

these benefits are simplification of requirements, design and implementation. These
benefits are achieved by
- Modeling the problem domain with objects that represent the important entities
- By encapsulating the functions with the data,
- By reusing objects within a project and between projects and
- By having a solution that is much closer intellectually to the problem.

Analysis results in a model of the system that aims to be correct, complete, consistent and
verifiable.

Object-Oriented (O-O) Analysis

Involves:
• Definition of the classes (objects) that represent the problem to be solved
• Definition of the manner in which the classes relate to and inter-relate with one
another
• The inner workings (attributes and operations) of objects
• The communication mechanism (messages) that allow them to work together

O-O Analysis is important because we cannot build software (O-O and otherwise) until
we have a reasonable understanding of the system or product. It offers us a concrete way
in which we may represent our understanding of requirements and then test that
understanding against the customers' perception of the system to be built.

Steps:
1. Begin with a description of Use Cases
2. Translate the information in the use cases into Class-Responsibility-Collaboration
(CRC) models of representation of classes and their collaborators with other
classes.
3. Model the static and dynamic characteristics of classes using UML or some other
method.
Static – Structural in nature/holds throughout the operational life
Dynamic – Focus on control and are sensitive to timing and event processing

To build the O-O Analysis model, five (5) basic principles are applied
1. Model the information domain
2. Describe the function of the system

Prepared by A. Campbell Page 1 of 5

 3. Represent the behaviour of the system
4. Partition the data, functional and behavioural models to explore greater details
5. Represent the essence of the problem in early models and show the
implementation details in later models

UML - A Unified Approach to O-O Analysis

In UML, a system is represented using five different views that describe the system from
distinctly different perspectives
1. User Model View - represents the system from the users perspective
2. Structural Model View - data and functionality are viewed from inside the system.
The static structure (classes, structure and relationships) is modeled
3. Behavioural Model View - represents the dynamic or behavioural aspects of the
system
4. Implementation Model View - structural and behavioural aspects of the system
are represented as they are built.
5. Environment Model View - the structural and behavioural aspects of the
environment in which the system is to be implemented are represented.

UML (O-O Analysis) modeling focuses on the first three models.

The analysis model is composed of three individual models

1. The functional model - represented by use cases and scenarios (describes the
functionality of the system from the users’ point of view)
2. The analysis object model - represented by class and object diagrams (Describes
the structure of a system in terms of objects, attributes, associations and
operations)
3. The dynamic model - represented by statecharts and sequence diagrams (Describes the
internal behaviour of the system. Sequence diagrams describe behaviour as a sequence of
messages exchanged among a set of objects, whereas statecharts diagrams describe behaviour in
terms of states of an individual object and the possible transition between states.)

Use Case Class diagram: State chart Sequence

diagram: View View diagram: View diagram: View

Functional Object model: Dynamic

model: Model Model model: Model

Analysis model:
Model

Prepared by A. Campbell Page 2 of 5

 The Analysis Model

Analysis Concepts
• Entity, boundary and control objects
• Association multiplicity
• Qualified association
• Generalization

Entity, boundary and control objects

• Entity objects represent the persistent information tracked by the system
• Boundary objects represent the interaction between actors and the system
• Control objects represents the tasks that are performed by the users and supported
by the system

Association multiplicity
When we model 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.

2Bwatch
1 1

2 1

Button LCD-Display

Association Multiplicity Diagram

• A one-to-one association has a multiplicity of 1 on each end

• A one-to-many association has a multiplicity of 1 on one end and 0…n on the
other
• A many-to-many association has a multiplicity of 0...n on both ends. A many-to-
many association are easier understand between two classes that an arbitrary
number of links exists between instances of two classes.

Qualified Association
Qualification is a technique for reducing multiplicity-using keys. Association with a 0…1
or 1 multiplicity are easier understood than association with a 0…n or 1…n multiplicity.
Without Qualification
File
Directory *
1 Filename

Prepared by A. Campbell Page 3 of 5

 With Qualification

1 0…1 File
Directory Filename

Example of how a qualified association reduces multiplicity

Reducing multiplicity is always preferable as the model becomes clearer and fewer cases
have to be taken into account.

Generalization
Generalization enables us to organize concepts into hierarchies. At the top is a general
concept and at the bottom of the hierarchy are the most specified concepts. See example

Incident

LowPriority Emergency Disaster

Earthquake ChemicalLeak
CatInTree

TrafficAccident BuildingOnFire
below.

Example of Generalization

Generalization and inheritance are closely related concepts, they are however not
identical. Inheritance is a mechanism for reusing attributes and behaviours, even when
the classes involved in the inheritance do not have a generalization.

Domain Analysis (DA)

This is performed when an organization wants to create a library of reuseable classes
(components) that will be broadly applicable to an entire category of applications.

The DA Process
Definition:
Software domain analysis is the identification, analysis, and specification of common
requirements from a specific application domain, typically for reuse on multiple projects
within that application domain… [Object-Oriented Domain Analysis is] the

Prepared by A. Campbell Page 4 of 5

identification, analysis and specification of common, reusable capabilities within a
specific application domain in terms of common objects, classes, sub-assemblies and
frameworks …"

The process consists of five distinct steps namely:

1. Define the domain to be investigated
a. Isolate the business areas, system types or product category of interest
b. Extract O-O and non O-O items
2. Categorize the items extracted from the domain - establish a classification
hierarchy
3. Collect a representative sample of applications in the domain - ensure that the
application in question has items that fit into the categories that have already been
defined
4. Analyze each application in the sample
a. Identify candidate reusable objects
b. Indicate the reasons that the object has been identified to reuse
c. Define adaptations to the object that may also be reusable
d. Estimate the percentage of applications in the domain that might make
reuse of the object
e. Identify the objects by name and use Configuration Management
Techniques to control them
5. Develop an analysis model for the objects - this will serve as the basis for design
and construction of the domain objects.

Additionally create a set of reuse guidelines and develop an example that illustrates how
the domain objects could be used to create a new application.

Ultimately, the goal of DA is to create software within the domain with a high percentage
of reusable components, lower costs, higher quality and improved time to market.

Analysis Activities: From Use Case to Objects

• Identifying entity objects
• Identifying boundary objects
• Identifying control objects
• Mapping use cases to objects
• Identifying association among objects
• Identifying object attributes
• Modeling non-trivial behaviour and state charts
• Modeling association relationships
• Reviewing the analysis model

Prepared by A. Campbell Page 5 of 5