Chapter 4
Object--Oriented
Object
Analysis
Learning Outcome:
Determine how to gain a better
understanding of the problem being solved
Determine how to conduct requirements
elicitation, analysis and modelling
Describe how to structure requirements with
use case diagrams andUML standards.
Construct use case model for requirements
modeling.
Refining the requirements model
2
Outline
Problem analysis
System Analysis
Requirements Elicitation
Requirements Analysis and Modeling
Refining Requirements Models
PROBLEM ANALYSIS
What is Problem Analysis?
The process of understanding real-world
problems and user needs and proposing
solutions to meet those needs
Analyse
and understand the problem domain
Explore a variety of solution domains
The goal of problem analysis is to gain a better
understanding, before development begins, of the
problem being solved
Problem Analysis Steps:
gain agreement on the problem definition
understand the root causes the problem behind
the problem
identify the stakeholders and the users
define the solution system boundary
identify the constraints to be imposed on the
solution
Gain Agreement on the Problem
Definition
Simply write the problem down and see whether
everyone agrees
It is helpful to write the problem in a standardized
format as following example:
Element
Description
The problem of
Describe the problem
Affects
Identify stakeholders affected by the problem
The result of
which
Describe the impact of this problem on stakeholders
and business activity
Benefits of
Indicate the proposed solution and list a few key
benefits
Understand the Root
Causes
Variety of techniques to gain understanding of the
real problem and its real causes --- e.g., fishbone
diagram
Factor contribute
Factor contribute
to the problem
to the problem
PROBLEM
Factor
contribute to the
problem
Factor
contribute to the
problem
Identify the Stakeholders
Understanding of who are the stakeholders and
their particular needs is an important factor in
developing an effective solution
The following questions can be helpful in
identifying the stakeholders:
Who are the users of the system?
Who is the customer for the system?
Who else will be effected by the outputs that the system produces?
Are there any other internal/external users of the system whose needs
must be addressed?
Who will maintain the new system?
Is there anyone else?
Define the Solution System Boundary
Defining a system that can be deployed to
address the problem
Determine the boundaries of the solution
system
System boundary defines the border between
the solution and the real world that surrounds
the solution describes an envelope in which
the solution system is contained
System Boundary
The task of defining system boundary
is to determine which aspects should
be covered and which aspects will not
be covered by the planned system
Need to identify the part of
environment that will interact with the
system system context
System Boundary
World can be divided into two:
System solution system
Things that interact with the system
System
user
user
Other
systems
System boundary
System Context
System
user
user
Other
systems
System context
Context boundary
System Context Using Context
Diagram and Use-Case Diagram
Context Diagrams or Use Case diagrams are often
used to document the system context
Context diagram sources and destinations in the
environment (i.e., system context) are modeled
Use Case diagram actors (e.g. people or other
systems) define the environment and its
relationships with the use cases of the planned
system are modeled
Context Diagram
Context diagram helps to decide if requirements
applied to the system or not
Context Diagram shows:
all external things that communicate with the system
Incoming data and information flows the system must
work with
Outgoing data and information flows produced by the
system
Shows one process named system
Context Diagram an
example
0
Order
information
CUSTOMER
Inventory
report,
Sales report
MANAGEMENT
Food
Order
System
Order information
Receipt
KITCHEN
DEPARTMENT
Use Case Diagram
Structure requirements with use case diagram
(using UML notation)
Relationship represents information exchange
between an actor and a use case and between
two use cases
Use Case Diagram an
example
Identify the Constraints to be
Imposed on the Solution
Constraints are restrictions on the degrees of
freedom we have in providing a solution
Potential system constraints:
Economic budget
Political internal/external issues
Technical technology selection
System platform and operating system
Environmental standards, legal, security requirements
Schedule and resources
SYSTEM ANALYSIS
20
Introduction
Analysis is a process by which users and
analysts help each other reach an
understanding of the system requirements
that is sufficient for their accurate
specification
To state accurately the users requirements
for a new system accurately
Communicating the current understanding of
the proposed system
21
Introduction
Preventing expensive mistakes reduce the
number of omissions, inconsistencies,
undetected errors, and minimize their impact
on system development
Provide system designers all information as
a basis for designing a system which will
satisfy those requirements
Stating the conditions for system acceptance
to assure users that the system, as
delivered by its developers, will in fact meet
the stated requirements
22
Introduction
Focuses on finding out what is to be built for
the users of a system
Known as systems analysis
Understanding the system context as well as
describing the features needed in the system
The requirements to be identified are both
functional (what the system must do) and
nonfunctional (constraints or performance
expectations)
23
Introduction
Relevant UML models include use cases, class
diagrams, interaction diagrams, and activity or
statechart diagrams
Requirements are expressed in terms of use
cases which describe explicitly what the new
system must do
Use cases may be identified by finding the
significant events or occurrences in the
systems environment and the expected
responses of the system
24
User Requirements
meeting the needs
Need to understand how the organization
operates at present
What are the problems with the current
system?
What are the requirements users have of a
new system that are not in the current
system?
25
Current System meeting
the needs
Much of the current system meets the
needs of people who use it
Sections of the system no longer meet
the needs of the organization
Some aspects of the organizations work
are not covered by the current system
The system can no longer evolve but
needs to be replaced
26
Current System meeting
the needs
It is important to understand the current
system to carry functionality forward into
the new system
It is also important to understand it so
that shortcomings and defects can be
corrected in the new system
27
Reasons for Investigating
the Current System
Functionality is required in new system
Data must be migrated into new system
Technical documentation provides details of
processing algorithms
Defects of existing system must be avoided
Parts of existing system may have to be kept
We need to understand the work of the users
Baseline information about the existing system
helps set targets for the new one
28
Types of Requirements
Functional
Non-functional
29
Functional Requirements
Describe what a system must do
Include:
processes
interfaces with users and other systems
what the system must hold data about
Modelled with Use Case Diagrams. Then
modelled with other kinds of diagrams that
show the structure of the system (Class
Diagrams) and its behaviour (Interaction
Diagrams and State Machines)
30
Non-functional Requirements
Concerned with how well the system
performs
Include:
response times
volumes of data
security considerations
All must be verifiable
31
Non-functional requirements
Three main types
1. Reflecting: usability, efficiency, reliability,
maintainability and reusability
Response time
Throughput
Resource usage
Reliability
Availability
Recovery from failure
Allowances for maintainability and enhancement
Allowances for reusability
32
Non-functional requirements
2. Constraining the environment and
technology of the system.
Platform
Technology to be used
3. Constraining the project plan and
development methods
Development process (methodology) to be used
Cost and delivery date (often put in contract or
project plan instead)
33
REQUIREMENTS ELICITATION
34
Requirements Elicitation
Techniques
Background Reading
Interviewing
Observation
Document Sampling
Questionnaires
Brainstorming (e.g.JAD)
Prototyping
35
Requirements Elicitation
Techniques
George Prentice Hall, 2004
5-36
Requirements Elicitation
Techniques
George Prentice Hall, 2004
5-37
Requirements Elicitation
TechniquesPrototyping
Prototyping
The simplest kind: paper prototype.
a set of pictures of the system that are shown to users in
sequence to explain what would happen
The most common: a mock-up of the systems UI
Written in a rapid prototyping language
Does not normally perform any computations, access any
databases or interact with any other systems
May prototype a particular aspect of the system
38
When to Use Prototyping
Prototyping is good when:
Users are unclear about their
requirements.
The system affects a relatively small
number of users.
Designs are complex.
Communication between users and
analysts needs to be strengthened.
Rapid application development tools are
available.
Prentice Hall, 2004
5-39
Prototyping
Use case modelling can be supported
with prototyping
Prototypes can be used to help elicit
requirements
Prototypes can be used to test out
system architectures based on the
use cases in order to meet the nonfunctional requirements
2010 Bennett, McRobb and Farmer
40
Prototyping
For user interface prototypes,
storyboarding can be used with handdrawn designs
2010 Bennett, McRobb and Farmer
41
Prototyping
User interface prototypes can be
implemented using languages other
than the one that the system will be
developed in
Campaign Selection
Campaign Selection
Client:
Holborn Motors
Lynch Properties
Yellow Partridge
Zeta Systems
Campaign:
Client:
Campaign:
OK
Quit
Dialogue initialized.
Campaign Selection
Holborn Motors
Lynch Properties
Yellow Partridge
Zeta Systems
Spring Jewellery Campaign 2003
Spring Jewellery Campaign 2004
Spring Jewellery Campaign 2005
Summer Collection 2004
OK
Quit
User selects Client.
Campaigns listed.
2010 Bennett, McRobb and Farmer
Client:
Campaign:
Holborn Motors
Lynch Properties
Yellow Partridge
Zeta Systems
Spring Jewellery Campaign 2003
Spring Jewellery Campaign 2004
Spring Jewellery
Jewellery Campaign
Campaign 2005
2002
Spring
Summer Collection 2004
OK
Quit
User selects Campaign.
42
User Involvement in System
Development Lifecycle
A variety of stakeholders:
senior managementwith overall
responsibility for the organization
financial managerswho control budgets
managers of user departments
representatives of users of the system
43
User Involvement in System
Development Lifecycle
Different roles:
as subjects of interviews
as representatives on project
committees
as evaluators of prototypes
as testers
as trainees on courses
as end-users of new system
44
User Involvement in Agile
Methodologies
encourage continuous user involvement
and adapt to incremental changes in
system design over time
Two approaches:
Agile user-centered design (similar to
JAD)
eXtreme programming
45
Documenting Requirements
Documentation should follow organizational
standards
Modelling tools that produce UML models
maintain associated data in a repository
Some documents will need separate storage in a
filing system:
interview notes
copies of existing documents
minutes of meetings
details of requirements
46
Documenting Requirements
Documents should be kept in a document
management system with version control
Use use cases to document functional
requirements
Maintain a separate requirements list
Review requirements to exclude those that
are not part of the current project
47
Activities involved in elicit and modeling
requirements
Requirements
Analyst
Project Initiation
Document
Elicit
requirements
Glossary
Candidate
Requirements
Select
requirements
Develop
use cases
Requirements
List
Use Case Model
48
Use Case ModelDrawing
Use Case Diagrams
Identify the actors and the use cases
Prioritize the use cases
Develop each use case, starting with the
priority ones, writing a description for each
Add structure to the use case model:
generalization, include and extend
relationships and subsystems
2010 Bennett, McRobb and Farmer
49
2010 Bennett, McRobb and Farmer
50
Use Case Descriptions
Can be a simple paragraph
Assign staff to work on a campaign
The campaign manager wishes to record
which staff are working on a particular
campaign. This information is used to
validate timesheets and to calculate staff
year-end bonuses.
2010 Bennett, McRobb and Farmer
51
Use Case Descriptions
Can be a step-by-step breakdown of
interaction between actor and system
Assign staff to work on a campaign
Actor Action
1. The actor enters the client name.
3. Selects the relevant campaign.
5. Highlights the staff members
to be assigned to this campaign.
System Response
2. Lists all campaigns for that
client.
4. Displays a list of all staff
members not already allocated
to this campaign.
6.Presents a message confirming
that staff have been allocated.
Alternative Courses
Steps 13. The actor knows the campaign name and enters it directly.
2010 Bennett, McRobb and Farmer
52
REQUIREMENTS ANALYSIS
AND MODELLING
53
Requirements and
Classes
From Requirements to
Classes
Requirements (use cases) are usually
expressed in user language
Use cases are units of development,
but they are not structured like
software
The software we will implement
consists of classes
We need a way to translate
requirements into classes
2010 Bennett, McRobb and Farmer
55
Why Analyse
Requirements?
Requirements (Use Case) model alone is
not enough
There may be repetition
Some parts may already exist as standard
components
Use cases give little information about
structure of software system
56
The Purpose of Analysis
Analysis aims to identify:
A software structure that can meet the
requirements
Common elements among the requirements
that need only be defined once
Pre-existing elements that can be reused
The interaction between different
requirements
57
What an Analysis Model
Does
An analysis model must confirm what
users want a new system to do:
Understandable for users
Correct scope
Correct detail
Complete
Consistent between different
diagrams and models
58
What an Analysis Model
Does
An analysis model must also specify what designers
must design:
Unambiguous about scope and detail
Consistent, e.g. about the names of classes,
operations, etc. in different diagrams
Complete, e.g. regarding non-functional
requirements such as localization
Correct, e.g. regarding the multiplicities of
associations between classes
59
What an Analysis Model
Does
Describes what the software should do
Represents people, things and concepts
important to understand the system
Shows connections and interactions
among these people, things and concepts
Shows the business situation in enough
detail to evaluate possible designs
Is organized / structured so it can be useful
for designing the software
60
How to Model the Analysis
The main technique for analysing requirements is
the class diagram
Two main ways to produce this:
Directly based on knowledge of the application
domain (from a Domain Model)
By producing a separate class diagram for each
use case, then assembling them into a single
model (an Analysis Class Model)
61
Analysis Class Diagram
Classes and objects
Attributes
Attributes and state
Links between instances
Associations between classes
Multiplicity
Operations
62
Partial Class Diagram with some attributes and operations
63
Realizing Use
CasesUse Case
Driven
Goal of Realization
Realization is name given UML to the
activity of developing an abstract model or
element into another model or element
that is closer to its implementation
Use case realization involves the
identification of a possible set of classes,
understanding how those classes interact
to deliver functionality of the use case.
65
Goal of Realization
An analysis class diagram is only an
interim product
This in turn will be realized as a
design class diagram
The ultimate product of realization is
the software implementation of that
use case
66
Communication Diagram
Approach
Analyse one use case at a time
Identify likely classes involved (the use case
collaboration)
These may come from a domain model
Draw a communication diagram that fulfils
the needs of the use case
Translate this into a use case class diagram
Repeat for other use cases
Assemble the use case class diagrams into
a single analysis class diagram
67
Use Case and Collaboration
Add a new advert to
a campaign
Campaign
Manager
Add a new
advert to a
campaign
<<realize>>
Add a new
advert to a
campaign
Dependency arrow indicates that elements within the
collaboration may reference elements within the use case
68
A Possible Collaboration
A link between two
objects allows them to
communicate
Collaboration name
Add a new advert to a campaign
:AddAdvertUI
:AddAdvert
:Advert
:Client
:Campaign
The collaboration
icon is a dashed
ellipse
Objects that play a role
in the collaboration
69
2010 Bennett, McRobb and Farmer
70
Early Draft Communication
Diagram
71
Early Draft Communication
Diagram
72
Early Draft Communication
Diagram
73
More Developed
Communication Diagram
2010 Bennett, McRobb and Farmer
74
Resulting Class Diagram
75
Resulting Class Diagram
boundary
User Interface::AddAdvertUI
control
Control::AddAdvert
startInterface()
createNewAdvert()
selectClient()
selectCampaign()
showClientCampaigns()
showCampaignAdverts()
createNewAdvert()
entity
Client
companyAddress
companyName
companyTelephone
companyFax
companyEmail
getClientCampaigns()
getClients()
entity
Campaign
1
0..*
places
title
campaignStartDate
campaignFinishDate
getCampaignAdverts()
addNewAdvert()
0..*
conducted by
entity
Advert
setCompleted()
createNewAdvert()
76
Reasonability Checks for
Candidate Classes
A number of tests help to check
whether a candidate class is
reasonable
Is it beyond the scope of the system?
Does it refer to the system as a
whole?
Does it duplicate another class?
Is it too vague?
(More on next slide)
2010 Bennett, McRobb and Farmer
77
Reasonability Checks for
Candidate Classes (contd)
Is it too tied up with physical inputs
and outputs?
Is it really an attribute?
Is it really an operation?
Is it really an association?
If any answer is Yes, consider
modelling the potential class in some
other way (or do not model it at all)
2010 Bennett, McRobb and Farmer
78
CRC Cards
ClassResponsibilityCollaboration cards help
to model interaction between objects
Invented by Beck and Cunningham (1989)
Used as a way of:
Identifying classes that participate in a scenario
Allocating responsibilities - both operations and
attributes (what can I do? and what do I know?)
For a given scenario (or use case):
Brainstorm the objects
Allocate to team members
Role play the interaction
79
CRC Cards
Class Name:
Responsibilities
Collaborations
Responsibilities of a class
are listed in this section.
Collaborations with other
classes are listed here,
together with a brief
description of the purpose
of the collaboration.
80
Class Name
Client
Responsibilities
Collaborations
Provide client
information.
Provide list of
campaigns.
Class Name
Campaign provides
campaign details.
Campaign
Responsibilities
Collaborations
Provide campaign
information.
Provide list of adverts.
Add a new advert.
Class Name
Advert provides advert details.
Advert constructs new object.
Advert
Responsibilities
Collaborations
Provide advert details.
Construct adverts.
81
CRC Cards
Effective role play depends on an
explicit strategy for distributing
responsibility among classes
For example:
Each role player tries to be lazy
Persuades other players their class
should accept responsibility for a
given task
May use Paper CASE to document
the associations and links
2010 Bennett, McRobb and Farmer
82
Assembling the Class
Diagram
However individual use cases are
analysed, the aim is to produce a single
analysis class diagram
This models the application as a whole
The concept is simple:
A class in the analysis model needs all the
details required for that class in each
separate use case
2010 Bennett, McRobb and Farmer
83
Campaign
campaignFinishDate
campaignStartDate
title
(c) Campaign class
that meets the needs
of both use cases
addNewAdvert()
getCampaignAdverts ()
<<entity>>
Campaign
campaignFinishDate
campaignStartDate
title
addNewAdvert()
assignStaff()
getCampaignAdverts ()
getCampaignStaff ()
(a) Campaign class that
meets the needs of Add new
advert to a campaign
<<entity>>
Campaign
campaignFinishDate
campaignStartDate
title
(d) A more fully
developed Campaign
class meets the
requirements of these
and several other use
cases too
assignStaff()
getCampaignStaff ()
<<entity>>
Campaign
actualCost
campaignFinishDate
campaignStartDate
completionDate
datePaid
estimatedCost
title
addNewAdvert()
assignStaff ()
completeCampaign ()
createNewCampaign ()
getCampaignAdverts ()
getCampaignCost ()
getCampaignStaff ()
recordPayment ()
(b) Campaign class that
meets the needs of
Assign staff to work
on a campaign
2010 Bennett, McRobb and Farmer
84
2010 Bennett, McRobb and Farmer
85
Refining the
Requirements
Model
Objective:
The aim of refining and adding further
structure to create the conditions for reuse.
OOA offers three main mechanisms for
reuse:
Fundamental abstraction mechanisms
Specification of reusable software
components
Application of analysis patterns
87
Reuse in Software
Development
Software development has
concentrated on inventing new
solutions
Recently, the emphasis has shifted
Much software is now assembled from
components that already exist
Component reuse can save money,
time and effort
88
Reuse in Software
Development
Achieving reuse is still hard
Reuse is not always appropriate cant
assume an existing component meets a
new need
Poor model organisation makes it hard to
identify suitable components
The NIH (Not-Invented-Here) syndrome
Requirements and designs are more
difficult to reuse than code
89
Reuse: The Contribution of
OO
Generalization allows the creation of new
specialised classes when needed
Encapsulation makes components easier
to use in systems for which they were
not originally designed
Aggregation and composition can be
used to encapsulate components
90
Adding Generalization
Structure
Add
generalization structures
when:
Two
classes are similar in most
details, but differ in some respects
May differ:
In behaviour (operations or methods)
In data (attributes)
In associations with other classes
2010 Bennett, McRobb and Farmer
Adding Structure: An Example
Two types of staff:
Creative
Have qualifications recorded
Can be client contact for campaign
Bonus based on campaigns they
have worked on
Admin
Qualifications are not recorded
Not associated with campaigns
Bonus not based on campaign profits
2010 Bennett, McRobb and Farmer
Adding Structure:
A superclass
StaffMember
{abstract}
Grade
gradeName
1..*
allocated
0..*
staffName
staffNo
staffStartDate
calculate Bonus ()
assignNewStaffGrade ()
getStaffDetails ()
Two subclasses with
redefined operation
calculateBonus ()
Superclass
associations are
inherited by
subclasses
AdminStaff
calculateBonus ()
2010 Bennett, McRobb and Farmer
CreativeStaff
qualification
calculateBonus ()
assignStaffContact ()
Aggregation and
Composition: An Example
A campaign is made up of adverts:
Campaign
0..*
Advert
Unfilled diamond
signifies aggregation
2010 Bennett, McRobb and Farmer
Aggregation and
Composition
Another everyday example:
Meal
1..*
Ingredient
Filled diamond signifies composition
This is (probably) composition:
Ingredient is in only one meal at a time
If you drop your dinner on the floor, you probably lose
the ingredients too
2010 Bennett, McRobb and Farmer
Recap
Problem analysis
System Analysis
Requirements Elicitation
Requirements Analysis and Modeling
Refining Requirements Models
96
