Purpose and Scope of Object Design

Technology changes extremely fast. Before any construction begins, the design of the system must be fully interrogated. Jumping to a programming solution without specifying the goal of the implementation would be like telling a group of builders: "Quick, build me a door." The construction workers should refuse and start asking questions:

1. What kind of door?
2. Should it open to the left or to the right?
3. Is it an interior door or an exterior door?
4. Main entrance, back door, closet, security door, screen door?
5. What dimensions? What material and composition?

These questions are all about design. There are an almost infinite number of technological solutions to any problem. The critical question is: what criteria will you use to select the most appropriate solution? Answering that question before construction begins is the purpose of the design phase.

The analysis phase answers the question of what the business needs. The design phase answers the question of how to build it. System design is the determination of the overall system architecture — the hardware, software, services, people, and communication pathways that together will satisfy the system's essential requirements.

During the initial part of design, the project team converts business requirements into system requirements. Business requirements are communicated through use cases, logical process models, and data models — they describe what users expect the system to do. System requirements are communicated through design documents and physical process and data models — they describe the technical decisions that will make the system work. Together, these design documents and physical models form the blueprint for the new system.

In a structured OOP development approach, these phases proceed in sequence. In modern agile environments, the same design activities occur iteratively across sprints, with analysis and design overlapping as the team learns more about the problem domain. The design activities themselves are identical regardless of methodology — only the timing and cadence differ.

The purpose of the object design phase is to create a model of how a software solution will:

1. Fulfill user expectations and requirements
2. Support the architecture on which it will run

Object design begins after the problem domain has been analyzed and the architecture has been established. Architectural choices define the constraints within which the object design must operate — performance boundaries, distribution topology, technology platform. Object design must work within those constraints while satisfying the functional requirements surfaced during problem analysis.

There are three primary tasks of object design. To develop your model, you must:

1. Define the internal implementation of each problem domain resource. During problem analysis, you identified the resources of the problem domain, each with a defined purpose and interface. Object design defines the internal behavior and attributes that support the purpose and interface of each resource. Where problem analysis views each class from the outside — its contract with the rest of the system — object design opens the class and decides how it will keep that contract.
2. Add the classes that enable your software to support the use of the resources. Problem domain classes represent real-world entities, but software solutions require additional classes that have no real-world counterpart. Controllers orchestrate workflows between domain objects. User interface classes mediate between the user and the domain. Database accessor classes handle persistence. Object design identifies and fully specifies all of these software-specific classes.
3. Iterate through the model to enhance and refine it. With the addition of each new class, the model evolves. This evolution takes the form of iterative enhancement — each pass through the model reveals new interactions, new responsibilities, and new opportunities to improve the design.

Iterative enhancement of the object model usually proceeds in the following order:

1. Add a new class or classes.
2. Enhance existing interaction diagrams to reflect the new class.
3. Research the behavior of the new class using dynamic and functional models.
4. Reassign responsibilities among classes where the new class reveals a better distribution.
5. Refine the model with design patterns and class stereotypes.
6. Reconcile the design to the architecture.
7. Test.

Each iteration through this sequence adds fidelity to the model. No single pass produces a complete design — the model converges on correctness through repeated refinement, comparison, and contrast between what the analysis says the system must do and what the design says the system will do.

The heart of the object design solution is the creation of interaction diagrams, which illustrate how objects collaborate to fulfill the requirements. UML 2.x provides two primary interaction diagram types: sequence diagrams, which show the order of messages between objects over time, and communication diagrams, which show the structural relationships between collaborating objects. Both are core UML 2.x artifacts and remain the standard tool for capturing object collaboration in modern OOP design work.

After or in parallel with drawing interaction diagrams, class diagrams are produced. Class diagrams summarize the definition of the software classes and interfaces that will be implemented. In practice, interaction diagrams and class diagrams are created in parallel and synergistically — each informs the other. A new interaction reveals a missing method on a class; a refined class diagram suggests a simpler interaction. The two models are not created in strict sequence but are developed together as the design matures.

What is important in object design is knowing how to think and design in objects. This is a fundamentally different ability from knowing UML diagramming notation, and it is a far more important one. A developer who understands how to decompose a problem into well-defined objects with clear responsibilities and minimal coupling will produce a sound design regardless of which notation they use to express it.

UML 2.x provides a valuable standard visual language for communicating design decisions across a team, and the notation required to support the design work covered in this course is presented alongside the design concepts. But the notation is always in service of the design thinking, not a substitute for it.

Step 5 of the iterative enhancement sequence — "Refine the model with design patterns and class stereotypes" — deserves particular attention. The Gang of Four (GoF) patterns, organized into creational, structural, and behavioral categories, are the foundational vocabulary for this refinement step. Modern C++ implementations use these patterns extensively: Factory Method and Abstract Factory for object creation, Adapter and Decorator for structural composition, Observer and Strategy for behavioral flexibility. Recognizing which pattern addresses a given design challenge is one of the most practical object design skills a developer can develop.

During object design, avoid considering programming specifics. Just as in architectural analysis, maintain a requirements-based approach throughout. Determine the goal of each design decision and identify the best design approaches that satisfy that goal. Then use those criteria to guide your implementation choices during construction.

The object design phase ends when the model is complete enough to guide construction — not when every implementation detail has been decided. Construction translates the design into working code. If programming specifics are introduced during object design, the design becomes entangled with implementation choices that may change, and the model loses its value as a requirements-based blueprint.

Before you move on, click the Quiz link below to take a short multiple-choice quiz.
Object Design - Quiz