OO Concept Chapt4 OOAnalysis

8/10/2019 OO Concept Chapt4 OOAnalysis

1/96

Chapter 4Chapter 4

ObjectObject--OrientedOriented


2/96

Learning Outcome:

Determine how to gain a betterunderstanding 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 requirementsmodeling.

Refining the requirements model

2


3/96

Outline

Problem analysis System Analysis

Re uirements Elicitation

Requirements Analysis and Modeling

Refining Requirements Models

3


4/96

PROBLEM ANALYSIS

4


5/96

What is Problem Analysis?

The process of understanding real-worldproblems and user needs and proposing

solutions to meet those needs

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


6/96

Problem Analysis Steps:

gain agreement on the problem definition understand the root causes the problem behind

the problem

define the solution system boundary

identify the constraints to be imposed on the

solution


7/96

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:

Description

Indicate the proposed solution and list a few key

benefits


8/96

Understand the RootCauses

Variety of techniques to gain understanding of the

real problem and its real causes --- e.g., fishbone

diagram

PROBLEM


9/96

Identify the Stakeholders

Understanding of who are the stakeholders andtheir particular needs is an important factor indeveloping an effective solution

The following questions can be helpful in

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 needsmust be addressed?

Who will maintain the new system? Is there anyone else?


10/96

Define the Solution System Boundary

Defining a system that can be deployed toaddress the problem

Determine the boundaries of the solution

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


11/96

System Boundary

The task of defining system boundaryis to determine which aspects should

be covered and which aspects will not

e covere y t e p anne system Need to identify the part of

environment that will interact with the

system system context


12/96

System Boundary

World can be divided into two: System solution system

Things that interact with the system

System

Othersystems

user user

System boundary


13/96

System Context

System

Othersystems

user user

System context

Context boundary


14/96

System Context Using ContextDiagram and Use-Case Diagram

Context Diagrams or Use Case diagrams are oftenused to document the system context

Context diagram sources and destinations in the

. .,

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


15/96

Context Diagram

Context diagram helps to decide if requirementsapplied to the system or not

Context Diagram shows:

Incoming data and information flows the system must

work with

Outgoing data and information flows produced by the

system

Shows one process named system


16/96

Context Diagram an

example

0

MANAGEMENTOrder

information

Inventory

report,Sales report

OrderSystem

KITCHEN

DEPARTMENT

Receipt

Order information


17/96

Use Case Diagram

Structure requirements with use case diagram(using UML notation)

Relationship represents information exchange

two use cases


18/96

Use Case Diagram an

example


19/96

Identify the Constraints to be

Imposed on the Solution

Constraints are restrictions on the degrees offreedom 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


20/96

SYSTEM ANALYSIS

20


21/96

Introduction

Analysis is a process by which users and

analysts help each other reach anunderstanding of the system requirements

21

specification

To state accurately the users requirements

for a new system accurately

Communicating the current understanding of

the proposed system


22/96

Introduction

Preventing expensive mistakes reduce the

number of omissions, inconsistencies,undetected errors, and minimize their impacton system development

22

Provide system designers all information asa basis for designing a system which willsatisfy those requirements

Stating the conditions for system acceptance to assure users that the system, asdelivered by its developers, will in fact meetthe stated requirements


23/96

Introduction

Focuses on finding out what is to be built forthe users of a system

Known as systems analysis

23

n erstan ng t e sys em con ex as we asdescribing the features needed in the system

The requirements to be identified are both

functional (what the system must do) andnonfunctional (constraints or performanceexpectations)


24/96

Introduction

Relevant UML models include use cases, class

diagrams, interaction diagrams, and activity orstatechart diagrams

24

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


25/96

User Requirements

meeting the needs

Need to understand how the organizationoperates 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


26/96

Current System meeting

the needs

Much of the current system meets theneeds of people who use it

Sections of the system no longer meet

Some aspects of the organizations workare not covered by the current system

The system can no longer evolve butneeds to be replaced

26


27/96

Current System meeting

the needs

It is important to understand the currentsystem to carry functionality forward into

the new system

It is also important to understand it sothat shortcomings and defects can be

corrected in the new system

27


28/96

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


29/96

Types of Requirements

Functional Non-functional

29


30/96

Functional Requirements

Describe what a system must do

Include:

processes

n er aces w users an o er sys ems what the system must hold data about

Modelled with Use Case Diagrams. Thenmodelled with other kinds of diagrams thatshow the structure of the system (ClassDiagrams) and its behaviour (InteractionDiagrams and State Machines)

30


31/96

Non-functional Requirements

Concerned with how well the systemperforms

Include:

31

response times volumes of data

security considerations

All must be verifiable


32/96

Non-functional requirements

Three main types

1. Reflecting: usability, efficiency, reliability,maintainability and reusability Res onse time

32

Throughput Resource usage

Reliability

Availability

Recovery from failure

Allowances for maintainability and enhancement

Allowances for reusability


33/96

Non-functional requirements

2. Constraining the environment and

technologyof the system.

Platform

33

3. Constraining theproject plan and

development methods

Development process (methodology) to be used Cost and delivery date (often put in contract or

project plan instead)


34/96

REQUIREMENTS ELICITATION

34


35/96

Requirements Elicitation

Techniques

Background Reading Interviewing

Observation

Document Sampling

Questionnaires

Brainstorming (e.g.JAD) Prototyping

35


36/96


Techniques

5-36George Prentice Hall, 2004


37/96


Techniques

5-37George Prentice Hall, 2004


38/96


TechniquesPrototyping

Prototyping

The simplest kind:paper prototype.

a set of pictures of the system that are shown to users in

se uence to ex lain what would ha en

38

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

Written in a rapid prototyping language

Does notnormally perform any computations, access any

databases or interact with any other systems

May prototype a particular aspect of the system


39/96

When to Use Prototyping

Prototyping is good when:

Users are unclear about theirrequirements.

5-39 Prentice Hall, 2004

number of users. Designs are complex.

Communication between users and

analysts needs to be strengthened. Rapid application development tools are

available.


40/96

Prototyping

Use case modelling can be supportedwith prototyping

Prototypes can be used to help elicit

40 2010 Bennett, McRobb and Farmer

Prototypes can be used to test outsystem architectures based on theuse cases in order to meet the non-

functional requirements


41/96

Prototyping

For user interface prototypes,

storyboarding can be used with hand-

drawn designs



42/96

Prototyping

User interface prototypes can be

implemented using languages other

than the one that the system will be


eve ope n

OK Quit

Campaign:

Campaign Selection

Holborn MotorsLynch PropertiesYellow PartridgeZeta Systems

Client:

Spring Jewellery Campaign 2003Spring Jewellery Campaign 2004Spring Jewellery Campaign 2005

Summer Collection 2004

Campaign:

Campaign Selection


Client:

Yellow Partridge

Spring Jewellery Campaign 2003Spring Jewellery Campaign 2004Spring Jewellery Campaign 2005

Summer Collection 2004

Campaign:

Campaign Selection


Client:

Yellow Partridge

Spring Jewellery Campaign 2002

Dialogue initialized. User selects Client.Campaigns listed.

User selects Campaign.

OK Quit OK Quit


43/96

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


44/96

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


45/96

User Involvement in Agile

Methodologies

encourage continuous user involvementand adapt to incremental changes insystem design over time

Two approaches:

Agile user-centered design (similar toJAD)

eXtreme programming

45


46/96

Documenting Requirements

Documentation should follow organizational

standards Modelling tools that produce UML models

maintain associated data in a re ositor

Some documents will need separate storage in afiling system:

interview notes

copies of existing documents

minutes of meetings

details of requirements

46


47/96

Documenting Requirements

Documents should be kept in a documentmanagement system with version control

Use use cases to document functional

Maintain a separate requirements list

Review requirements to exclude those thatare not part of the current project

47


48/96

Elicit

requirements

Project InitiationDocument

Requirements

Analyst

Activities involved in elicit and modeling

requirements

Requirements

List

Use Case Model

CandidateRequirementsSelect

requirements

Develop

use cases

48

U C M d l D i


49/96

Use Case ModelDrawing

Use Case Diagrams

Identify the actors and the use cases

Prioritize the use cases

Develop each use case, starting with the


pr or ty ones, wr t ng a escr pt on or eac

Add structure to the use case model:generalization, include and extendrelationships and subsystems


50/96



51/96

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.


52/96

Use Case Descriptions

Can be a step-by-step breakdown of

interaction between actor and system

Assign staff to work on a campaign


1. The actor enters the client name. 2. Lists all campaigns for thatclient.

3. Selects the relevant campaign. 4. Displays a list of all staffmembers not already allocatedto this campaign.

5. Highlights the staff members 6.Presents a message confirming

to be assigned to this campaign. that staff have been allocated.

Alternative CoursesSteps 13. The actor knows the campaign name and enters it directly.


53/96

REQUIREMENTS ANALYSIS

AND MODELLING

53


54/96

From Requirements to


55/96

From Requirements to

Classes

Requirements (use cases) are usually

expressed in user language

Use cases are units of development,


but they are not structured likesoftware

The software we will implement

consists of classes We need a way to translate

requirements into classes

Why Analyse


56/96

Why Analyse

Requirements?

Requirements (Use Case) model alone is

not enough

There may be repetition

Some parts may already exist as standardcomponents

Use cases give little information about

structure of software system

56


57/96

The Purpose of Analysis

Analysis aims to identify:

A software structure that can meet the

requirements

Common elements among the requirementsthat need only be defined once

Pre-existing elements that can be reused

The interaction between differentrequirements

57

What an Analysis Model


58/96


Does

An analysis model must confirm what

users want a new system to do:

Understandable for users

Correct scope Correct detail

Complete

Consistent between differentdiagrams and models

58



59/96


Does

An analysis model must also specify what designers

must design:

Unambiguous about scope and detail

, . . ,

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



60/96


Does

Describes what the software should do

Represents people, things and conceptsimportant to understand the system

among these people, things and concepts Shows the business situation in enough

detail to evaluate possible designs

Is organized / structured so it can be usefulfor designing the software

60


61/96

How to Model the Analysis

The main technique for analysing requirements is

the class diagram

Two main ways to produce this:

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


62/96

Analysis Class Diagram

Classes and objects

Attributes

Attributes and state

Associations between classes

Multiplicity

Operations

62


63/96

63Partial Class Diagram with some attributes and operations


64/96


65/96

Goal of Realization

Realization is name given UML to the

activity of developing an abstract model orelement into another model or element

a s c oser o s mp emen a on

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


66/96

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


67/96


Approach

Analyse one use case at a time

Identify likely classes involved (the use casecollaboration)

These ma come from a domain model

Draw a communication diagram that fulfilsthe needs of the use case

Translate this into a use case class diagram

Repeat for other use cases

Assemble the use case class diagrams intoa single analysis class diagram

67


68/96

Use Case and Collaboration

CampaignManager

Add a new advert toa campaign

Add a new

advert to a

campaign

Add a new

advert to a

campaign

68

Dependency arrow indicates that elements within thecollaboration may reference elements within the use case


69/96

A Possible Collaboration

Add a new advert to a campaign

:AddAdvertUI

Collaboration name

A link between twoobjects allows them tocommunicate

:Advert

:Campaign

:Client

69

The collaborationicon is a dashedellipse

Objects that play a rolein the collaboration


70/96


Early Draft Communication


71/96

y

Diagram

71



72/96

y

Diagram

72



73/96

y

Diagram

73

More Developed


74/96




75/96

Resulting Class Diagram

75


76/96

Resulting Class DiagramUser Interface::AddAdvertUI

startInterface()

createNewAdvert()

selectClient()selectCampaign()

boundary

Control::AddAdvert

showClientCampaigns()

showCampaignAdverts()createNewAdvert()

control

Advert

setCompleted()

createNewAdvert()

entityCampaign

title

campaignStartDate

campaignFinishDate

getCampaignAdverts()

addNewAdvert()

entity

1 0..*

conducted by

Client

companyAddress

companyName

companyTelephone

companyFaxcompanyEmail

getClientCampaigns()

getClients()

entity

1 0..*

places

76

Reasonability Checks for


77/96

Candidate Classes

A number of tests help to check

whether a candidate class isreasonable


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)

Reasonability Checks for


78/96

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 someother way (or do not model it at all)


79/96

CRC CardsClassResponsibilityCollaboration cards help

to model interaction between objects

Invented by Beck and Cunningham (1989)

Used as a way of:

Allocating responsibilities - both operations andattributes (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


80/96

CRC Cards

Class Name:

CollaborationsResponsibilities

espons es o a c ass

are listed in this section.

classes are listed here,together with a brief

description of the purpose

of the collaboration.

80

Class Name Client

Responsibilities Collaborations


81/96


Provide clientinformation.

Campaign providescampaign details.

Class Name Campaign


Provide list ofcampaigns.

r e cam a n information.

Provide list of adverts.Add a new advert. Advert provides advert details.Advert constructs new object.

Class Name Advert


Provide advert details.

Construct adverts.

81


82/96

CRC Cards

Effective role play depends on an

explicit strategy for distributingresponsibility among classes


Each role player tries to be lazy Persuades other players theirclass

should accept responsibility for a

given task May use Paper CASE to document

the associations and links

Assembling the Class


83/96

Diagram

However individual use cases are

analysed, the aim is to produce a singleanalysis class diagram


This models the application as a whole

The concept is simple:

A class in the analysis model needs allthe

details required for that class in eachseparate use case

Campaign

title

campaignStartDate

campaignFinishDate

(c) Campaign class

that meets the needs

of both use cases

Campaign

title

campaignStartDate

campaignFinishDate


84/96

(a) Campaign class that

meets the needs of Addnew

adverttoacampaign

getCampaignAdverts ()

addNewAdvert()

(d) A more fully

getCampaignStaff ()

assignStaff()


addNewAdvert()


(b) Campaign class that

meets the needs ofAssignstafftowork

onacampaign

developed Campaign

class meets the

requirements of these

and several other use

cases too

title

campaignStartDatecampaignFinishDate

estimatedCost

completionDate

datePaid

actualCost


addNewAdvert()

createNewCampaign()

getCampaignStaff ()

assignStaff()completeCampaign ()

getCampaignCost ()

recordPayment ()

Campaign

getCampaignStaff()

assignStaff()

title

campaignStartDate

campaignFinishDate


85/96



86/96

Refining the

RequirementsModel

Obj i


87/96

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

D l t


88/96

Software development has

concentrated on inventing newsolutions

Development

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

D l t


89/96

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


90/96

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

St t


91/96

Structure

Add generalization structures

when:

2010 Bennett, McRobb and Farmer

details, but differ in some respectsMay differ:

In behaviour (operations or methods)

In data (attributes)

In associations with other classes

Addi St t A E l


92/96

Adding Structure: An Example Two types of staff:

Have qualifications recorded

Can be client contact for cam ai n


Bonus based on campaigns theyhave worked on

Creative

Admin

Qualifications are not recorded

Not associated with campaignsBonus not based on campaign profits

Adding Structure:StaffMember A superclass


93/96

0..*1..* allocated

StaffMember

{abstract}

staffName

staffNostaffStartDate

calculate Bonus ()assignNewStaffGrade ()getStaffDetails ()

Grade

gradeName

A superclass


Superclass

associations areinherited by

subclasses

calculateBonus ()

CreativeStaffqualification

assignStaffContact ()

AdminStaff

calculateBonus ()

redefined operation

calculateBonus ()

Aggregation and

Composition: An Example


94/96

Composition: An Example

A campaign is made up of adverts:


Campaign Advert0..*1

Unfilled diamond

signifies aggregation

Aggregation and

Composition


95/96

Another everyday example:

Meal Ingredient1..*1

Composition


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 losethe ingredients too

Recap


96/96

Recap

Problem analysis

System Analysis

Re uirements Elicitation

Requirements Analysis and Modeling Refining Requirements Models

96

OO Concept Chapt4 OOAnalysis

Documents

Transcript of OO Concept Chapt4 OOAnalysis