Object-Oriented Development Process

Part I: Requirement Gathering

Warsun Najib

Department of Electrical EngineeringGadjah Mada University

What is OODP?

Software development process based on object-orientation principleEmphasis on “process”Object-orientation: focusing on “objects”

within and around the software

As a software engineering process, OODP can be modeled in different waysWaterfall Incremental (similar to prototyping)Spiral

Activities of OODP

Requirementgathering

User interfacedesign

Testplanning

User interfaceimpl. and test

Test case design& devt.

Use casetest

Analysis (app.specification)

Use casedesign

Classdesign

Use case & classimpl.

Interface & app.integration

List of use caseinputs & outputs

Use cases &outcomes

Test plan

Screen layout& navigation

Use casedefinitions

Use casedescriptions

Test cases

Tested usecases

Implementedmethods &classes

Functional spec ofeach method

Use casedescriptions &design levelclass diagram

Class diagramUse casedescriptions

User interface

Activities of OODP and Use Cases

OODP activities are centered on the concept of use caseA use case is a transaction that begins with a

user stimulus and ends with a response In between, there are program logic (input

validation, action execution, data update, etc)A use case is triggered by an external event,

needs that motivate a user to stimulate the system Example: “The customer wants to send money to

another account”

Example of use case in respond to the above event: “money transfer”

Use Case Rules

A use case must define a complete transaction It should contain sufficient information Incomplete information makes it impossible

to finish a transactionExample: in the “money transfer” use case,

if only account numbers are provided, it is impossible to complete the transfer (i.e., how much ?)

The required set of information is determined by the user

Use Case Rules

A use case should be a discrete unit of workPrinciple of cohesiveness - focuses only at one activity

Cohesive use case reduces complexityExample of non-cohesive use case: “create a

loan and open a savings acct. to guarantee the loan”

Avoid multiple identical inputs that actually belong to separate transactions

Example of a use case with multiple identical inputs: “disburse payment from an account to up to three user accounts”

Use Case Signature

How to represent use cases in a concise but meaningful way

Four pieces of information about a use case Inputs (and their order)

What are the inputs for the transaction specified by the use case?

Input types Syntactic definition to check validity of inputs

Use case outcomes Possible logical results of the transaction

Any returned information Information outcomes returned to the user

Use Case Signature

Example: “money transfer”Transferring money from an account to another.

Done by specifying the account numbers, PIN, and the amount of money transferred

The use case signature is shown as follows

Transfer (from-acct number, to-acct number, amount, pin number)

{ OK (updated bal. of from-acct, updated bal. of to-acct),

invalid from-acct number,

invalid to-acct number,

wrong pin number,

insufficient fund (available balance of from-acct) }

Requirement Gathering

GoalsTo define the problem space by binding the

scopeTo provide developers with sufficient

abstraction of problem domain without having to go into details

Heavy involvement of users Ways to gather information from users

Existing system walkthroughDocument evaluation Interview

Record all (textual) information!

Requirement Gathering

From problem description to object, attribute, actors, and function identification through grammar examinationCreate vocabulary (i.e., data dictionary) from

the problem domain Identify nouns nouns are potential

candidates for attributes or objects Identify adjectives adjectives can be

attributes, too Identify verbs verbs may point to use cases Identify actors normally persons involved in

running the system

An Example: A Video Store Application

Problem description

Create a video rental tracking system that allows any

member with a credit card on file to rent any available video

for a maximum of three days. Members can rent at most

four videos at a time. When the member brings a video to

the counter, the clerk scans or types the video identifier

and the member’s identification. The video is then rented. If

the video is returned late, the member must pay Rp 2000

per day late fee. Members with outstanding late fees or

overdue videos cannot rent movies.

An Example: A Video Store Application

Initial selection of application business objects and their attributesComplex elements are most likely objectsPrimitives (integer, string, etc.) are most

likely predicates

Member Video identifier identifier fees outstanding status (rented, late, returned) late videos rented videos

An Example: A Video Store Application

Identification of (preliminary) use cases Rent a video (id, customer)Return a rented video (id)Add a new video to the inventory (id, title)Create a new member (id, credit card)Delete an existing video (id)Delete an existing member (id)Make a video late (id)Pay overdue fees (id, amount)

An Example: A Video Store Application

Finding outcomes of each use caseFind for logically invalid inputs

id does not exist a rented video may already be rented a returned video may have status indicating it was

not rented before

Duplicating when creating new objects created id may already exist

Business rules a member with outstanding fines or videos may not

rent members have a max. number of videos that can

be rented videos are considered late after three days

An Example: A Video Store Application

Finalize the use casesRent a video (video id, member id) { OK, video not found, member not found, member has max. videos rented, member owes fines (amount) } Return a rented video (video id) { OK, video not found, video not rented,

video is overdue (fines owed) } Add a new video to the inventory (video id, title) { OK, video id already exists } Delete a video (video id) { OK, video not found, video is rented (due back) } Create a new member (member id, credit card no.) { OK, duplicate member id, invalid credit card } Delete an existing member (member id) { OK, member not found, member owes fines, member has outstanding rentals } Pay fines owed by member (member id, amount) { OK, member not found, member owes no fines, member overpaid by (amount), member still owes fines (amount) }

Post-Processing

Walkthrough of the proposed use cases, between users and developers

Try to come up with an agreement on use cases

The questionsHave all proposed use cases covered the

scope of the application?Are the use cases inputs and their types

correct?Have all outcomes of each use case been

identified?

Partitioning

To logically map use classes into functional requirements

Partitioning by increments Partitioning strategies

Easiest first: to ease the development team into working with use cases or objects

Target use cases for operational support: to get a set of use cases operational a.s.a.p.

Provide most functionality a.s.a.p.: to show as much of the system’s capability a.s.a.p.

Support end user training: to provide most application operations but not enough to run in production mode

Partitioning: An Example

Extended video store application Proposed use cases

Add category Rent video Add vendor Rent override Remove vendor Collect rental fee Add video Cancel rental agreement Remove video Reserve video Define branch Remove member from wait list Remove branch Run overdue report Add copy Return video Remove copy Pay fine Add member Get availability Remove member Set copy status New rental agreement Run royalty Run usage report

Partitioning: An Example

Increment #1Use cases

Add category Define branch Add vendor Add video Add copy

Strategy A practice increment and does not harm if

something wrong happens If successful, user is able to start building the

video database

Partitioning: An Example

Increment #2Use cases

Add member New rental agreement Rent video Run overdue report Return video Collect rental fee Reserve video

Strategy To deliver most of the essential functions

To operate the store To demonstrate a fairly complete system

Partitioning: An Example

Increment #3Use cases

Rent override Get availability Pay fines Run royalty report Run usage report Cancel rental

Strategy To provide additional use cases to make the

system ‘operational’

Partitioning: An Example

Increment #4Use cases

Remove copy Remove video Remove member Remove vendor Set copy status Rent override Remove member from wait list

Strategy Non-critical additional features to make the

system ‘complete’