SDSU CS535 Object-Oriented Programming & Design
Fall Semester, 1996
Doc 30, Object-Oriented Life Cycle

[To Lecture Notes Index]
San Diego State University -- This page last updated Dec 5, 1996

Contents of Doc 30, Object-Oriented Life Cycle

  1. References
  2. Object-Oriented Life Cycle
    1. Recursive/Parallel Life Cycle
    2. Incremental Development
    3. Iterative Development
    4. Software Reuse
    5. Domain Analysis
    6. Maintenance
    7. Testing
  3. Managing a Project
    1. Object-Oriented Team Roles
    2. Management Misconceptions
    3. Stages of Object-Oriented Expertise7

Doc 30, Object-Oriented Life Cycle Slide # 1


Berard, Essays on Object-Oriented Software Engineering, Vol 1, 1993

Booch, Object-Oriented Analysis and Design with Applications, 1991

Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, 1992

Jones, Reusability in Programming: A Survey of the State of the Art, IEEE Transactions on Software Engineering, vol. SE-10(5), Sept. 1984

Lorenz, Object-Oriented Software Development: A Practical Guide, 1993

Doc 30, Object-Oriented Life Cycle Slide # 2

Object-Oriented Life Cycle

Object-Oriented Domain Analysis
Identifying operations, objects and structures that occur across projects in a specific application area

Object-Oriented (Requirements) Analysis
"Examining the requirements from the perspective of the classes and objects found in the problem domain"

Object-Oriented Design
"Process of object-oriented decomposition and a notation for depicting the system under design"[1]

Incremental Development

Iterative Development

Recursive/Parallel Life Cycle




Software Reuse

Doc 30, Object-Oriented Life Cycle Slide # 3
Object-Oriented Life Cycle

More time is spent in analysis and design, less time in implementation, testing and maintenance

Emphasis on data structures before functions
ItemProbability for change[2]
Object from applicationLow
Long-lived information structuresLow

Separation of life cycle phases is less distinct than in other methods

Life cycle phases intermix

Iterative rather than sequential

Doc 30, Object-Oriented Life Cycle Slide # 4

Recursive/Parallel Life Cycle

Systematically decompose a problem into highly-independent components

Re-apply the decomposition process to each component to decompose it further

Decompose each component "simultaneously"

Continue the process until done

Doc 30, Object-Oriented Life Cycle Slide # 5
Recursive/Parallel Life CycleDecomposition Process

Understand the requirements for the product (component)

Design a little
Apply the design process to the product (component)
Implement a little
Implement the programming language interfaces for each of the components (subcomponents)
Implement the algorithm which describes the interaction among the components (subcomponents)
Implement the internals of those components that will not be further decomposed

Test a little
Compile any code produced as a result of the "implement a little" step
Carry out any dynamic testing which is possible

Doc 30, Object-Oriented Life Cycle Slide # 6

Incremental Development

Developing a system in stages, adding new functionality in each stage

Makes testing, design and implementation easier

OO technology aids incremental development by:
Information hiding in classes - continuity
Data is more stable than functionality

Iterative Development

The same portion of the system is worked on a number of times, possibly rewriting it from scratch

One iteration is not iterative development

Improves quality

Solves problems earlier in process

Doc 30, Object-Oriented Life Cycle Slide # 7
Iterative DevelopmentLornez's Modification of Wilfs-Brock Method[3]

Business Phase
Identify and document types of users
Identify and document initial user requirements
Contact customers interested in a development partnership
Exploratory Phase

Design and Test Phase

Packaging Phase
Ship product
Prepare classes for reuse library

Doc 30, Object-Oriented Life Cycle Slide # 8
Lornez's Modification of Wilfs-Brock MethodExploratory Phase

Requirements analysis
Write scenarios, verify with customers
Document requirements
Find classes
Extract nouns from requirements and scenarios
Determine responsibilities

Develop throwaway prototype of scenarios
Model one or more scenarios in prototyping language
The focus in developing the prototype is communication with the user
Verify the prototype with customers
User interface
Update scenarios and requirements as needed

Iterate for areas that don't have solid requirements

Document requirements, draft system architecture and draft user's manual

Doc 30, Object-Oriented Life Cycle Slide # 9
Lornez's Modification of Wilfs-Brock MethodDesign and Test Phase

Produce a development plan

Review exploratory phase

Document the target language, hardware and software platforms

Search reuse library for applicable components

Find hierarchies and contracts

Draw collaborations graphs and find subsystems

Walk through the design

Implement subsystems
Write methods, test classes
Assess performance, quality, reusability
Iterate step for areas that don't meet requirements
Test subsystems

System test the complete system

Document final architecture and users manual

Doc 30, Object-Oriented Life Cycle Slide # 10
Lornez's Modification of Wilfs-Brock MethodAn Iteration

The same portion of the system is worked on a number of times, possibly rewriting it from scratch

Planning stage (2 weeks)
Determine specific goals for each iteration
Establish schedule

Production stage (10 weeks)
Perform the analysis, design or implementation
Assessment stage (3 weeks)
Evaluate the results of the production stage

Rules of thumb

3 - 6 iterations on system of 200 classes and 3,000 methods

Keep an iteration under 4 months

Doc 30, Object-Oriented Life Cycle Slide # 11

Software Reuse

Up to 85% of software could be composed of reusable components[4]

Code fragmentsDocumentation
ClassesTest code and data

Reuse effort must be an integral part of every software development

Management must encourage, support and reward reuse
Reuse culture

Doc 30, Object-Oriented Life Cycle Slide # 12
Software Reuse

Software reuse implies
Reuse library to hold the software
Appropriate software can be readily found

Tools to find code
Organized process to prepare software for library
Procedures to accept code into library
Procedures for modifying code in library
Time to study library
Organized effort across projects to find common classes

Who pays for the extra effort to design reusable classes?

Doc 30, Object-Oriented Life Cycle Slide # 13

Domain Analysis

"An investigation of a specific application area that seeks to identify the operations, objects, and structures that commonly occur in software systems within this area."[5]

Domain analysis is not part of the life cycle of any project

"When a component is developed in the context of some system, it is difficult to abstract from the concerns of that system to produce a truly flexible, unbiased component."
"It may be difficult to recognize that a particular part is highly reusable, and so many potentially useful components may be ignored"[6]


Reuse, incremental development and iterative development blur the distinction between development and maintenance

Doc 30, Object-Oriented Life Cycle Slide # 14


Class is a larger program unit than a function

Scenarios provide test cases

In hierarchy test parent classes first

Test first, classes which don't depend on other classes

Integration testing is incremental, not big bang

Doc 30, Object-Oriented Life Cycle Slide # 15

Managing a Project

Object-Oriented Team Roles

The team follows classes
The same team does at least the analysis, design and implementation
In large projects, a project group does analysis, design and implementation for a subsystem
Reduces communication time and problems between teams
Results in more consistent designs
The one team approach makes reviews more important

Classes follow people
When possible, a person should "own" a set of classes
One person designs, implements and maintains a class during the project
All changes to class must go through this person
Results in higher quality classes

Initial requirements analysis is done by a small group with much interaction with end users

Doc 30, Object-Oriented Life Cycle Slide # 16

Management Misconceptions

Doc 30, Object-Oriented Life Cycle Slide # 17

Things that the Project Manager Must Understand

Doc 30, Object-Oriented Life Cycle Slide # 18

Stages of Object-Oriented Expertise[7]


Duration: 3 to 6 months

"Novices spend their time trying to get their function-oriented heads turned around, so they can see the application object classes. They have a hard time finding the classes and write a lot of function-oriented code."


Duration: 3 to 6 months

"Apprentices begin to understand what object-orientation really means. They still prefer to work with others, who help foster an environment of discovery. Apprentices begin turning out good designs, although not consistently. Gurus and journeymen still need to keep an eye on apprentices."

Doc 30, Object-Oriented Life Cycle Slide # 19

Stages of Object-Oriented Expertise


Duration: varies greatly, a least a year

"Journeyman have internalized the OO paradigm and work independently. They can provide key inputs during the design reviews. They still have mental roadblocks that may require a guru to break through."


Duration: lifetime

"For gurus, OO development comes naturally. A guru automatically sees things in an OO perspective, moving quickly through the phases of development during rapid iterations. A guru can move the project over mental hurdles, causing others to see something clearly that eluded them before."

"There are very few gurus in the world today. The rest of us will have to rely on proven processes and methodologies."

"I've yet to see someone successfully make it past the novice stage and even consider thinking about software in other than OO terms."