Introduction
Objectoriented analysis and design (OOA/D) is a disciplined approach for building software systems that model realworld concepts as objects. By focusing on the problem domain first (analysis) and then on the solution domain (design), practitioners can produce systems that are easier to understand, extend, and maintain. When OOA/D is combined with a robust development framework such as the Unified Process (UP), the resulting methodology provides clear guidance on what to produce, when to produce it, and how to validate it throughout the project.
The following page explains the core ideas of OOA/D, outlines the structure of the Unified Process, and shows how the two complement each other to deliver highquality software.
The Unified Process
The Unified Process is an iterative, architecturecentric software development framework originally described by Jacobson, Booch, and Rumbaugh. Although many flavors exist (RUP, AgileUP, etc.), the core concepts remain the same:
- Iterative development every iteration delivers a usable increment.
- Riskdriven highrisk elements are tackled early.
- Usecase driven functional requirements are captured as use cases.
- Architecturecentric a stable baseline architecture is established early and refined later.
These pillars make the Unified Process particularly well suited for objectoriented projects because use cases naturally translate into object models, and architecturecentric thinking encourages the identification of key objects early on.
Lifecycle Phases
The UP lifecycle is divided into four overlapping phases. Each phase produces a specific set of artifacts, and each artifact is refined in subsequent phases.
1. Inception
The goal is to establish the business case and a rough project scope. Core activities include:
- Identify primary stakeholders and their objectives.
- Define highlevel use cases (the vision).
- Draft a preliminary costbenefit analysis.
- Produce a rough architecture sketch to assess feasibility.
2. Elaboration
This phase reduces risk by solidifying the systems architecture and refining the object model. Typical work includes:
- Detailed usecase specifications (including alternative flows).
- Class diagrams that capture the core domain concepts.
- Allocation of responsibilities using CRC (ClassResponsibilityCollaborator) cards.
- Selection of key architectural patterns (e.g., MVC, layered).
- Prototype of critical components to validate assumptions.
3. Construction
The focus shifts to building a complete, testable system. Activities revolve around:
- Implementing classes derived from the refined design.
- Developing user interface mockups and integrating them with business logic.
- Writing unit tests and executing systemlevel test suites.
- Iteratively extending the class diagram as new features emerge.
4. Transition
The final phase prepares the product for delivery. Tasks include:
- Beta testing with real users to discover remaining defects.
- Performance tuning and security hardening.
- Creation of user manuals and deployment scripts.
- Final acceptance testing and signoff.
Key Artifacts in OOA/D with UP
While the process framework dictates flow, the concrete artefacts are what give the methodology its power. Below are the most important documents and diagrams that link OOA/D to the Unified Process.
UseCase Model
Captures functional requirements from the stakeholders perspective. Each use case includes a brief description, primary actor, preconditions, basic flow, alternative flows, and postconditions. In UP, the usecase model drives the iteration plan: the first iteration implements the most critical use cases.
Conceptual Class Diagram
Shows the domain objects without technical details such as data types or persistence mechanisms. It is derived directly from the vocabulary of the use cases and refined during elaboration. The diagram is a living artifact it evolves with each iteration.
Design Class Diagram
Extends the conceptual model with attributes, operations, visibility, and relationships. Design classes are grouped into packages that map to the architectural layers (e.g., presentation, business, data). The diagram guides developers in code generation and refactoring.
Sequence and Collaboration Diagrams
These dynamic models illustrate how objects interact to fulfil a use case. Sequence diagrams emphasize the time order of messages, while collaboration diagrams focus on object relationships. Both are useful for validating the design and identifying missing responsibilities.
Component & Deployment Diagrams
Represent the physical realization of the architecture. Component diagrams show how logical modules map to software components; deployment diagrams show how those components are installed on hardware nodes. They are created in the construction phase and refined in transition.
Best Practices for Combining OOA/D and the Unified Process
- Start with highlevel use cases. Even a handful of wellwritten use cases give the team a clear vision and help prioritize earlyrisk work.
- Iteratively refine the class model. Treat the class diagram as a hypothesis that is continuously tested by coding and testing.
- Maintain a baseline architecture. Freeze the core architectural components after the elaboration phase; all subsequent work should conform to this baseline unless a compelling reason exists to change it.
- Use CRC cards for early responsibility assignment. This lightweight technique speeds up the discovery of object responsibilities before formal diagrams are drawn.
- Integrate testing into every iteration. Unit tests derived from class specifications and acceptance tests derived from use cases ensure that design decisions are validated continuously.
- Embrace refactoring. When a new use case does not fit the existing design, refactor the model rather than forcing a kludge. The iterative nature of UP makes this safe and inexpensive.
- Document decisions. Capture rationale for architectural and design choices in short decision logs; this prevents knowledge loss as the team grows.
By following these practices, teams can leverage the strengths of objectoriented analysis and designclear domain modeling, encapsulation, and reusewhile the Unified Process provides a disciplined, riskaware schedule that keeps the project on track.
