AN OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN METHODOLOGY

1

AN

OBJECT-ORIENTED

SYSTEMS ANALYSIS AND DESIGN

METHODOLOGY

Planning Feasibility Study (optional) Requirements Determination

Conceptual Design Physical Design Construction and/or Purchase

(prototype) Training Conversion - old to new Implementation Evolution - maintenance &

enhancements

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)A

naly

sis

Desig

n

3

METHODOLOGY OVERVIEW

• Methodology defined: The way something gets done. The strategy, steps, directions, or actions.

• Methodologies can be:• purchased

• created

• combination of both

• Thousands available for developing information systems

4

METHODOLOGY OVERVIEW

• Classifications of Methodologies• Traditional• Structured Analysis and Design• Information Modeling/Engineering• Object-Oriented

• Prototyping is a technique - (some say that it

is a methodology)

5

The Traditional Methodology

• Applicable for small teams on small projects

• Functional perspective of problem domain

• Informal, unstructured, unrepeatable,

unmeasurable, ad-hoc way

• Tools used to support it are okay

(1950s - now)

6

Traditional Methodology Tools

-----------TECHNIQUES & TOOLS REPRESENTING-----------System Data Communication ProcessFlows with users Logic

Forms,

Layouts,

Grid Charts

System

Flowcharts

English

Narrative,

Playscript,

Program

Flowcharts,

HIPO Charts

Interviews

7

Structured Analysis and Design Methodology

• Data Flow methodology (synonym)

• Compliments Structured Programming

• Very popular - perhaps the leading one

• Can be repeatable, measurable, & automated

• CASE brought significant assistance

• 1) Yourdon, and 2) Gane & Sarson

• Functional perspective of problem domain

• Describes the real world as data flowing through the information system, being transformed from inputs to outputs

(mid-1970s - now)

8

Structured Analysis and Design Methodology Tools


Data Dictionary,

Data Structure

Diagrams,

Entity-

Relationship

Diagrams

Data Flow

Diagram

Decision

Tree/Table,

Structured

English,

Structure

Charts,

Warnier/Orr

Diagram

Interviews,

User Reviews,

JAD sessions

Reconcile Account Balances

Pay a

Bill

Withdraw Funds from an Account

Deposit Funds into an Account

Bank

Creditor

Employer

Other Income Source

Bank

Monthly Account Statements

Account Transactions

Bank Accounts

Account Transactions

Bill

Payment

Monthly Statement

Account Balance

Transaction

Prior Monthly Statement

New or Modified Monthly Statement

Modified Balance

Pay

Reimbursement

Withdraw or transfer

Deposit

Payment

Modified Balance

Current Balance

(adapted from Systems Analysis andDesign Methods, 4th Edition, Whittenand Bentley, McGraw-Hill, 1998)

(adapted from Systems Analysis andDesign Methods, 4th Edition, Whittenand Bentley, McGraw-Hill, 1998)

CUSTOMER

Customer Number (PK) Customer Name Shipping Address Billing Address Balance Due

ORDER

Order Number (PK) Order Date Order Total Cost Customer Number (FK)

INVENTORY PRODUCT

Product Number (PK) Product Name Product Unit of Measure Product Unit Price

ORDERED PRODUCT

Ordered Product ID (PK) . Order Number (FK) . Product Number (FK) Quantity Ordered Unit Price at Time of Order

has placed

sold

sold as

11

Information Modeling Methodology

• Data modeling & information engineering

(synonyms)

• Describes the real world by its data, the data’s

attributes, and the data relationships

• Can be repeatable, measurable, and automated

• Data perspective of the problem domain

(early-1980s - now)

12

Information Modeling Methodology Tools


Business

Area

Analysis,

Entity-

Relationship

Diagrams

Business

Area

Analysis,

Process

Model

Business

Systems

Design

Interviews,

User Reviews,

JAD Sessions,

Brainstorming

13

Object-Oriented Methodology

• Object modeling

• Compliments object-oriented programming

• Can be repeatable, measurable, & automated

• Object perspective of the problem domain

• Describes the real world by its objects, the attributes,

services, and relationships

• Data & functions are encapsulated together

(mid/late-1980s - now)

14

Object-OrientedMethodology Tools


Object Model

Attributes

Object

Model

Object

Models

Services,

Scenarios,

Decision

Tree/Tables,

Structured

English

Interviews,

User Reviews,

JAD Sessions,

Brainstorming

15

Object-Oriented Methodology

• Revolutionary or Evolutionary?

• Most difficult aspect is the transition some people

have to make from a functional or data problem

solving strategy to an object problem solving

strategy. Some people must change from a “function

think” or “data think” to an “object think” strategy.

16

Object Technology Principles• Abstraction

• Encapsulation (Information Hiding)

• Inheritance

• Message Communication

• Associations

• Polymorphism

• Common Methods of Organization

• Reuse

17

• AbstractionA mental ability that permits people to view real-world

problem domains with varying degrees of detail depending on the current context of the problem.

• Helps people to think about what they are doing• Functional and Data abstraction

18

• Encapsulation (Information Hiding)

A technique in which data are packaged

together with their corresponding procedures.

cakeIngredients

Directions

2 eggs 4 cups flour1 cup milk 1 cup sugaretc.......

Pre-heat oven to 350; Putmilk, eggs, and sugarin 2 quart mixing bowl...

In Object-Oriented Technology the “package” is called an OBJECT

The interface to each object is defined in such a way as to reveal as little as possible

about its inner workings

Encapsulation allows [software] changes to be reliably made with limited effort

[Gannon, Hamlet, & Mills, 1987]

One cake please!

19

• InheritanceA mechanism for expressing similarity

between things thus simplifying their

definition.

• looks• behavior• attitudes• etc...

Person

Student Faculty Staff

Inheritance

20

• Message Communication

OBJECT

OBJECT

OBJECT

OBJECT

Objects communicate via messages

21

• AssociationsThe union or connection of ideas or things.

(Objects need to interact with each other)

• same point in time

Billing StatementAdvertisement #1Advertisement #2

• under similar circumstances

crimescene

#1

crimescene

#2

crimescene

#n

22

• Polymorphism (“many forms”)

The ability to hide different implementations

behind a common interface.

The ability for two or more objects to respond

to the same request, each in its own way.

• H O = water, ice, steam (liquid, solid, vapor)

• Eating

2

versusDoor

#1Door

#2Door

#3

Door#1#2#3

• Polymorphism Two examples

PRINT0

5000

10000

15000

20000

25000

North

Sout

h

East

Wes

t

B L U E S K Y A I R L I N E SSales ReportJanuary

B L U E S K Y A I R L I N E SSales ReportFebruary

PRINT

PRINT

TEXT object

GRAPH object

IMAGE object

Object #1 PO object

Account object

Department object

Object #2

Object #3

Add

Add

Add

= add a line item to the PO

= increase $ Amount Balance

= hire a new employee

24

• Objects and their characteristics

• Wholes and Parts

• Groups (Classes) and Members

Classification Theory(Common Methods of Organization)

O-O Systems Analysis & Design Methodology

25

• Common Methods of Organization

People are accustomed to thinking in terms

of...

• color• price• weight• engine• options...

Objects & Attributes

• number of doors• number of wheels• number of windows• number of lights• number of bolt type 1• number of bolt type 2• etc....

Wholes and PartsGroups & Members

VANS:• light utility• utility• passenger• etc...

26

• Reuse

Varying Degrees of Reuse:

• complete or sharing

• copy, purchase or cloning

• partial or adjusting

• none

The ability to reuse objects

Software:• “Chips”• Components• Controls• Models

27

• Reuse

• Components must be reused three to five times before the costs of creating and supporting them are recovered• It costs one and a half to three times as much to create and support a single reusable component as to create a component for just one use• It costs 25% as much to use a reusable component as it does to create a new one• It takes two to three product cycles (about three years) before the benefits of reuse become significant

Software Reuse Costs and PayoffsOrenstein, D. “Code reuse: Reality doesn’t match promise”,

Computerworld, August 24, 1998, page 8.

28

O-O Systems Analysis & Design Methodology

Three Classic Systems Analysis and Design Problems:

• Data Model versus Function Model

• Analysis to Design Transition

• Maintaining Source Code

VVVVVVVVVVVV

Colorado River

North Rim of theGrand Canyon

South Rim of theGrand Canyon

Classic Software Development Problem #1:Multiple Models

DataModels

FunctionModels

SystemSystemBehaviorBehavior

VVVVVVVVVVVV

Colorado River

North Rim of theGrand Canyon

South Rim of theGrand Canyon

Classic Software Development Problem #2:Model Transformation

DesignModels

AnalysisModels

Classic Software Development Problem #3:Maintaining Source Code

Begin “Caller” Program Init x,y,z... Open (files/database) Read... Compute...

DO “Callee” with x,y,z

Update (files/database) Close (files/database) End Main Program

Procedure Callee Parameters x,y,z Compute... End Procedure

End Program

Spaghetti?

Who wrotethis code?

32

SOLUTION

Colorado River

ObjectTechnology

INTEGRATED MODEL(S)(function, data, behavior)

(analysis, design and implementation)

ROUND-TRIPENGINEERING

33

Coad’s Object-OrientedSystems Analysis & Design

Methodology*

O-O Systems Analysis & Design O-O Systems Analysis & Design MethodologyMethodology

* formerly, Coad and Yourdon

* based on Coad, P., North, D., and Mayfield M., Object Models: Strategies, Patterns, and Applications, Prentice Hall, Englewood Cliffs, NJ, 1995.

Use four object model components (Problem Domain [PD],

Human Interaction [HI], Data Management [DM], and

System Interaction [SI]) to guide and organize the work.

For each of PD, HI, DM, and SI repeat the following:

1. Identify the information system’s purpose and features

2. Select the model component’s objects and organize

them by applying patterns

3. Establish responsibilities for model component’s

objects:

• what the object knows

• who the object knows

• what the object does

4. Work out model component’s dynamics using scenarios

Coad’s Object-Oriented Methodology Standard Sequence

Variation notes for

activities 2, 3 and 4:1. They may be done

in any sequence

that is appropriate

2. One or more of them

may be omitted

3. One or more of them

may be done in parallel

4. Model components

may be done in any

order that is appropriate

ModelComponent

Problem Domain (PD)

Human Interaction (HI)

Data Management (DM)

System Interaction (SI)

Identifyobjects

andpatterns

(behavior,data)

Establishobject

responsibilities

(behavior, data,

functions)

Defineservice

scenarios(behavior

,data,

functions)

IdentifyPurpose

andFeatures

Activities

indicates that the activity has been performed for the model component

1 2 3 4

Coad’s Object-Oriented Methodology Summary

36

Iterative View of Coad’s Methodology

Establishobject

responsibilities

IdentifyPurpose and

Features

Identifyobjects and

patterns

Defineservice

scenarios

}One for each of:• System Interaction

• Data Management

• Human Interaction

• Problem Domain

37

Spiral View of Coad’s Methodology

(SI)(DM)(HI)(PD)

System InteractionData ManagementHuman InteractionProblem Domain

Defineservice

scenarios

Establishobject

responsibilities

Identifyobjects and

patterns

IdentifyPurpose and

Features

Coad’s Object Model Components

Problem Domain

Data Management System Interaction

Information System

Note: PD, HI, and SI are similar to Smalltalk programming language concept called Model-View-Controller (MVC)

Human Interaction

39

Model Components• Problem domain -- directly correspond to the

problem being modeled

• Human interaction -- provide interface between the PD objects and people

• Data management -- provide interface between PD objects and a database or file management system

• System interaction -- provide interface between PD objects and other systems or devices

40

Coad’s Object-OrientedSystems Analysis & Design

Notation*

O-O Systems Analysis & Design O-O Systems Analysis & Design MethodologyMethodology

* formerly, Coad and Yourdon

* based on Coad, P., North, D., and Mayfield M., Object Models: Strategies, Patterns, and Applications, Prentice Hall, Englewood Cliffs, NJ, 1995.

41

Subject Matter Expert & Notation

• Can you draw a stick figure of a person?

• Can you draw a picture of an automobile?

• Can you draw a picture of the space shuttle?

• Can you draw a picture of an Oopsla?

• Why not?

• Subject Matter Expert (SME)

• Notation - symbols used to communicate

42

Coad’s Object Model Notation

class with objects

model component

class

43


MembermemberNumberfirstNamelastNametelephoneaddresscityetc...

checkOutVideocheckInVideobuyItemetc...

Attributes

Services

{{

Expanded view

of a class or

class with objects

into its three

sections:

top: Class Name

middle: attributes

bottom: services

44


object connection messagen

n

generalization-specializationconnection

whole-partobject connection

n-n

1

n

45

The Problem Domain

Object Model

“The Big Picture”

Inventory

StoreLocationEmployee

Member

SalesTransaction RentalTransaction Vendor

PurchaseOrder

Transaction

ConcessionItemVideo Game VCR

SaleItem RentalItem

1-n

1

1-n

1n

0-1

n n

1 n

1

11-n

POLineItem1

1

1-n

SaleRentalLineItem1

1-n 1-n

1

Video Store - Problem Domain (PD) Object Model

Note: For simplification purposes, the attribute and service sections of classes and class-with-objects have been omitted from the figure.

PD Object Model with Attributes & Services

Inventory

ConcessionItemVideo Game

SaleItem RentalItem

1-n 1-nbarCodeNumberdescriptionqtyOnHandpricecosttaxCode

orderInventoryinquireAboutAvailableInventoryaddNewInventoryItemchangeInventoryItemInformationdelete/RemoveInventoryItemupdateQuantity-On-Order

quantitySoldqtyOnHand

updateQuantitySoldupdateInventoryQty-On-Hand

timesRenteddueDatememberNumber

updateRentalInformation

VCR

1 of 3

Member

SalesTransaction RentalTransaction

Transaction

1

1n

0-1n

n

1


transactionNumberemployeeNumbertransactionDatetransactionTime

payForTransaction

quantitySoldpurchaseForSaleItems

memberNumberrentAnItemchecking-inRentalItem

memberNumber creditCardNumbermemberName creditCardExpireDatememeberAddress depositAmountmemberCity overdueAmountmemberStatememberZipcodememberPhone

acquireMembershipverifyMembershipupdateCreditCardInformationupdateMembershipInformationcancelMembershipupdateOverdueAmountdetermineIfDelinquent

EmployeeemployeeNumberemployeeNameemployeePhonepositionCode

updateEmployeeInformation

1

SaleRentalLineItemtransactionNumberbarCodeNumberpricesalesTax

1-n1-n

11

2 of 3


StoreLocation

Vendor

PurchaseOrder

1

n

1

storeNumberaddresscitystatezipcodetelephone

provideStoreInformation

vendorNumbervendorNamevendorAddressvendorCityvendorStatevendorZipcodevendorPhonevendorFaxNumber

addNewVendorInformationchangeVendorInformationdeleteVendorprovideVendorInformation

purchaseOrderNumberpurchaseOrderDatepurchaseOrderDueDatepurchaseOrderCancelDatevendorNumber

createNewPurchaseOrderdeleteExistingPurchaseOrder

1-n

POLineItempurchaseOrderNumberbarCodeNumberquantityOrdereditemCost

1

1-n

3 of 3

Documents

AN OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN METHODOLOGY