1. What Is Object-Oriented Development?
Object-oriented development is a way of organizing software construction around objects rather than around actions, and around data rather than around logic alone. Instead of decomposing a problem into a set of procedures that operate on shared data, the developer decomposes it into a set of objects — self-contained units that combine data and behavior — and defines how those objects collaborate to satisfy the requirements of the system.
Unlike traditional development methods, where analysis, design, and implementation often use different concepts and notations, object-oriented development uses the same underlying model — objects and classes — throughout the entire life cycle. This continuity reduces the number of translations a system undergoes as it moves from concept to code, and each of those translations is a place where errors and misunderstandings can creep in.
2. The Stages of Object-Oriented Development
Object-oriented development, as presented in the OMT methodology, proceeds through four broad, overlapping stages. Each stage refines the model produced by the previous one, adding detail and moving closer to a working system, while still expressing that model in terms of objects and classes.
3. Analysis
Analysis is the stage in which the developer builds a model of the real-world situation the software must address, focusing on what the system must do rather than how it will do it. The analyst works with the user or domain expert to identify the relevant objects, classes, relationships, and behavior, deliberately ignoring implementation and hardware concerns at this point.
The output of analysis is an analysis model consisting of:
- An object model, showing the static structure of objects, their attributes, and their relationships.
- A dynamic model, showing how objects change state over time in response to events.
- A functional model, showing the transformations performed on data by the system.
A good analysis model is concise, understandable, and correct — it should be a distillation of the essential structure of the problem, free of implementation bias, so that it remains valid even if the underlying technology changes.
4. System Design and Object Design
4.1 System Design
In system design, the developer makes the high-level strategic decisions about how the system will be organized to satisfy the requirements captured during analysis. Typical decisions made at this stage include:
- Organizing the system into subsystems, based on both the analysis model and the target architecture.
- Identifying inherent concurrency dictated by the problem and assigning subsystems to processors and tasks.
- Choosing an approach to data management, such as files, a relational database, or an object database.
- Deciding how to handle global resources, boundary conditions, and trade-off priorities such as speed versus memory.
4.2 Object Design
Object design builds on system design by producing a design model that is detailed enough to guide implementation. The analysis model is elaborated and optimized: algorithms and data structures are chosen for operations, associations are implemented as specific data structures or pointers, and classes may be adjusted for efficiency while trying to preserve their conceptual clarity.
| System Design Focus | Object Design Focus |
|---|---|
| Overall architecture, subsystem decomposition, concurrency, data management strategy | Class interfaces, algorithms, data structures, associations, inheritance optimization |
| Answers: "What are the major building blocks and how do they fit together?" | Answers: "How exactly does each class do its job?" |
5. Implementation
Implementation translates the design model into a specific programming language, database, or hardware environment. Because the design was expressed in terms of classes and objects, this translation is comparatively direct when an object-oriented programming language is used, since the target language's own classes and objects map naturally onto the design.
Good implementation practice includes following the design faithfully, applying the target language well, and reusing existing code and libraries wherever possible, so that the resulting software remains understandable and consistent with the models produced earlier in development.
6. A Continuous, Iterative Life Cycle
A defining theme of object-oriented development is that analysis, design, and implementation are not sharply separated, one-way phases as in some traditional methods. Because the same object model is refined at each stage, the process is naturally iterative: work at a later stage often reveals gaps or errors in an earlier model, and the developer revisits and revises that model before proceeding.
The cyclical, feedback-driven nature of object-oriented development — later stages routinely feed corrections back to earlier models.
7. Why This Approach Matters
- Seamlessness: using the same object concepts across all stages reduces translation errors between phases.
- Traceability: a class identified during analysis can usually be traced directly into the design and code, making the system easier to understand and modify.
- Reusability: because functionality is packaged into self-contained classes, components built for one system can often be reused in another.
- Resilience to change: because the object model reflects the structure of the problem domain rather than a specific set of functions, it tends to remain stable even as requirements evolve.
8. Reference
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Object-Oriented Modeling and Design, Chapter 1, Section 1.2. Prentice Hall India.
This page presents an explanation of the object-oriented development life cycle inspired by the concepts introduced in the cited chapter, reorganized and reworded for study purposes rather than reproduced verbatim from the source text.