OO Concept Chapt4 OOAnalysis

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
Techniques
Background Reading
Interviewing
Observation
Document Sampling
Questionnaires
Brainstorming (e.g.JAD)
Prototyping
35
Techniques
George Prentice Hall, 2004
5-36
Techniques
George Prentice Hall, 2004
5-37
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
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
Summer Collection 2004
OK
Quit
User selects Client.

Campaigns listed.
Client:
Campaign:
Holborn Motors
Lynch Properties
Yellow Partridge
Zeta Systems
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
49
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.
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.
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
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

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

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
70
Early Draft Communication

Diagram
71

Diagram
72

Diagram
73
More Developed
Communication Diagram
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)
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)
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
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
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()
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 ()
getCampaignCost ()
getCampaignStaff ()
recordPayment ()
(b) Campaign class that

meets the needs of
Assign staff to work
on a campaign
84
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
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
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 ()
CreativeStaff
qualification
calculateBonus ()
assignStaffContact ()
Aggregation and
Composition: An Example
A campaign is made up of adverts:
Campaign
0..*
Advert
Unfilled diamond
signifies aggregation
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
Recap
Problem analysis
System Analysis
Requirements Analysis and Modeling
Refining Requirements Models
96

OO Concept Chapt4 OOAnalysis

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

OO Concept Chapt4 OOAnalysis

Caricato da

Copyright:

Formati disponibili

Chapter 4

Determine how to gain a better

What is Problem Analysis?

The process of understanding real-world

and understand the problem domain

The goal of problem analysis is to gain a better

Problem Analysis Steps:

gain agreement on the problem definition

Gain Agreement on the Problem

Simply write the problem down and see whether

Describe the problem

Identify stakeholders affected by the problem

Describe the impact of this problem on stakeholders

Indicate the proposed solution and list a few key

Understand the Root

Variety of techniques to gain understanding of the

Identify the Stakeholders

Understanding of who are the stakeholders and

Who are the users of the system?

Define the Solution System Boundary

Defining a system that can be deployed to

World can be divided into two:

System Context Using Context

Context Diagrams or Use Case diagrams are often

Context diagram helps to decide if requirements

all external things that communicate with the system

Shows one process named system

Use Case Diagram

Structure requirements with use case diagram

Use Case Diagram an

Identify the Constraints to be

Constraints are restrictions on the degrees of

Relevant UML models include use cases, class

Current System meeting

Current System meeting

Reasons for Investigating

Functionality is required in new system

Describe what a system must do

3. Constraining the project plan and

George Prentice Hall, 2004

George Prentice Hall, 2004

The simplest kind: paper prototype.

The most common: a mock-up of the systems UI

When to Use Prototyping

Prototyping is good when:

Prentice Hall, 2004

2010 Bennett, McRobb and Farmer

For user interface prototypes,

2010 Bennett, McRobb and Farmer

User interface prototypes can be

User selects Client.

User selects Campaign.

User Involvement in System

User Involvement in System

User Involvement in Agile

encourage continuous user involvement

Documentation should follow organizational

Activities involved in elicit and modeling

Use Case Model

Use Case ModelDrawing

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

Use Case Descriptions

Can be a simple paragraph