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
- References
- Object-Oriented Life Cycle
- Recursive/Parallel Life Cycle
- Incremental Development
- Iterative Development
- Software Reuse
- Domain Analysis
- Maintenance
- Testing
- Managing a Project
- Object-Oriented Team Roles
- Management Misconceptions
- Stages of Object-Oriented Expertise7
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
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
Prototyping
Testing
Maintenance
Software Reuse
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
| Item | Probability for change[2] |
| Object from application | Low |
| Long-lived information structures | Low |
| Functionality | High |
Separation of life cycle phases is less distinct than in other methods
Life cycle phases intermix
Iterative rather than sequential
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
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
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
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
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
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
- Functionality
- 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
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
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
Up to 85% of software could be composed of reusable components[4]
Software
| Code fragments | Documentation |
| Classes | Test code and data |
| Subsystems | Designs |
Reuse effort must be an integral part of every software development
Management must encourage, support and reward reuse
- Reuse culture
-
- Tools
-
- Personal
-
- Training
Software Reuse
Software reuse implies
- Reuse library to hold the software
-
- Appropriate software can be readily found
Need
- Librarian
- 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?
"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
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
-
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
- Object-oriented technology adoption is simply a programming language
issue
- Object-oriented technology adoption impacts only the analysis, design and
programming staffs
- Any professional can learn, and become proficient with, object-oriented
technology in a short time
- Significant software reuse and cost savings will be seen in the first OO
project
Things that the Project Manager Must Understand
- Object-oriented software development is not the norm in most development
organizations
- Not everyone can learn OOSE technology
- * OOSE technology is best learned in "chunks"
- OOSE technology education is a continuing process
- OO projects require proper tools
- Policies and procedures may need revising
- Technology absorption is not linear
Novice
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."
Apprentice
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."
Stages of Object-Oriented Expertise
Journeyman
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."
Guru
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."