Lesson 1

Reconcile the Object Oriented Models and Why the Class Diagram is not enough

Object oriented analysis does not depend on a single diagram. A class diagram is important because it defines the static structure of a software system, but it does not describe everything the analyst needs to know. A class diagram identifies classes, attributes, operations, and relationships, but it does not fully explain how objects collaborate, how scenarios unfold, how responsibilities are distributed, or how the system behaves while it is running.

This module introduces the process of reconciling object oriented models. Model reconciliation means comparing different diagrams and different views of the same problem domain to determine whether they agree with one another. When two models describe the same system from different perspectives, they should support the same business rules, object responsibilities, and system behavior. If the diagrams contradict one another, the analyst has discovered a modeling discrepancy that must be explained and corrected.

Why the Class Diagram is not Enough

It is tempting to believe that the class diagram is the most important diagram because it is the diagram most directly related to code. In C++ and other object oriented languages, classes are used to define the structure of objects. A class diagram can show the names of classes, their data members, their member functions, their associations, inheritance relationships, aggregations, compositions, and other structural dependencies.

However, that structural view is only one part of the object oriented model. The class diagram does not show the full sequence of events that occurs when a user performs a task. It does not show which object sends the first message, which object responds, which object creates another object, or which object owns responsibility for a specific behavior. It also does not show how many times an operation may be invoked during a scenario, whether an object is created temporarily, or whether the same object participates in several use cases.

A class diagram is like a blueprint for a building. A blueprint can show the rooms, walls, doors, electrical circuits, plumbing lines, and structural supports. It can identify the capacity of a furnace, the size of a water heater, or the rating of an electrical panel. But the blueprint does not show what happens when several people take showers in sequence, when a door is left open during winter, or when the electrical system is stressed by several devices running at the same time.

The same principle applies to software. A class diagram can show that a Customer class is associated with an Order class, and that an Order is associated with one or more OrderItem objects. But it does not, by itself, explain the complete behavior of placing an order, validating payment, reserving inventory, calculating tax, applying discounts, or confirming shipment. To understand those behaviors, the analyst must use other models.

Different Diagrams Reveal Different Facts

Object oriented modeling uses multiple diagrams because each diagram emphasizes a different part of the problem. A class diagram emphasizes static structure. A use case model emphasizes external behavior from the user's point of view. A sequence diagram emphasizes object collaboration over time. A communication diagram emphasizes the network of object interactions. A state machine diagram emphasizes lifecycle behavior. An activity diagram emphasizes workflow, decision paths, and procedural flow.

Each diagram is a partial abstraction. None of these diagrams is the entire system. Each one filters the problem domain so the analyst can focus on a specific kind of question. The value of object oriented analysis comes from using these diagrams together. The analyst studies the same system from several angles and then checks whether the views are consistent.

For example, a use case may state that a customer can cancel an order before shipment. A sequence diagram may show a Customer object sending a cancellation request to an Order object. A state diagram may show that an order can move from Pending to Cancelled, but not from Shipped to Cancelled. The class diagram should then contain the operations, attributes, and relationships needed to support that behavior.

If the class diagram contains no operation for cancellation, no order status, and no relationship to the object responsible for authorization, the diagrams do not reconcile. The missing information is a design problem. The analyst must either revise the class diagram, revise the behavioral model, or clarify the business rule.

Class Diagrams Define Static Structure

Class diagrams remain central to object oriented modeling because they define the structural vocabulary of the system. They identify the classes that represent important concepts in the problem domain. They also define the attributes and operations that belong to those classes. In C++, these concepts are eventually reflected in class declarations, member variables, member functions, constructors, destructors, access control, inheritance, and object relationships.

A class diagram is especially useful when the analyst needs to answer structural questions:

What are the main objects in the problem domain?
What information does each object need to store?
What operations should each object provide?
Which classes are associated with one another?
Which classes generalize or specialize other classes?
Which objects own, contain, or depend on other objects?

These questions are essential, but they are not sufficient. A correct class diagram should be tested against behavior. If the class diagram cannot support the scenarios described by the use cases and sequence diagrams, then the class diagram is incomplete. The purpose of reconciliation is to discover these gaps before the design is implemented in code.

Abstraction Concepts

Facts from the problem domain are valuable, but facts alone do not create a software design. The analyst must convert facts into abstractions, rules, and concepts that can be represented in a model. An abstraction identifies the essential meaning of something while ignoring details that do not matter for the current design.

For example, a real customer may have a name, phone number, email address, billing address, shipping address, purchase history, support history, and account status. The modeler must decide which facts are relevant to the system being built. A customer service system may need different customer details than an order fulfillment system. The same real-world concept can be modeled differently depending on the purpose of the application.
The modeler must determine:

what each class represents,
what information each class owns,
what behavior each class performs,
which other classes it collaborates with, and
which rules constrain its valid states and operations.

These decisions cannot be validated by looking only at one diagram. They must be checked across several views. The class diagram may define the object structure, but sequence diagrams, state diagrams, activity diagrams, and use case descriptions help test whether that structure can support the required behavior.

UML diagrams supporting reconciliation between class structure, behavior models, and generated application code. — Figure 4-1: UML diagrams provide different views of the system so the class diagram can be tested, corrected, and reconciled with application behavior.

Each Class Should Have a Specific Definition

A class should have one clear definition in the model. Even if the same class appears on several diagrams, it should represent the same concept each time. If a Student class appears in a class diagram, a sequence diagram, and a state diagram, those diagrams should refer to the same modeled concept. The behavior shown in the sequence diagram should not contradict the attributes, operations, and relationships shown in the class diagram.

Modern modeling tools often support this consistency through a repository. A repository is a shared dictionary of model elements. When a class is created, the modeling tool stores the definition of that class. If the class appears on another diagram, the new diagram references the existing definition instead of creating an unrelated copy. When the class definition changes, the change can be reflected across every diagram that uses that class.

This repository concept is important because reconciliation becomes difficult when diagrams contain duplicate or inconsistent definitions. If one diagram shows Account with a withdraw() operation, another diagram shows CheckingAccount performing the withdrawal, and a sequence diagram sends the withdrawal message to a Transaction object, the analyst must determine whether these differences are intentional or accidental.

Inconsistent definitions may indicate that the modeler has not yet assigned responsibilities correctly. They may also reveal that the system needs another class, a revised inheritance structure, or a clearer separation of responsibilities.

A Class Represents the Same Concept Across Diagrams

A class should represent the same concept no matter where it appears. This does not mean every diagram must show every detail of the class. A sequence diagram may show only the objects and messages relevant to one scenario. A class diagram may show the full structure. A state diagram may show only lifecycle states. However, the underlying meaning of the class should remain stable.

Suppose a Reservation class appears in several diagrams. In the class diagram, it may have attributes such as reservationNumber, startDate, endDate, and status. In a sequence diagram, it may receive messages such as confirm(), cancel(), or expire(). In a state diagram, it may move through states such as Requested, Confirmed, Cancelled, and Expired.

These views should reinforce one another. If the state diagram includes a Cancelled state, the class diagram probably needs data or behavior that supports cancellation. If the sequence diagram sends a confirm() message to the reservation object, the class diagram should include an operation or responsibility that corresponds to confirmation. If the class diagram includes an operation that never appears in a scenario, the analyst should ask whether the operation is truly needed.

This process is not merely documentation. It is a verification technique. By comparing the diagrams, the analyst can discover missing operations, misplaced responsibilities, invalid transitions, incomplete associations, and unclear business rules.

Model Reconciliation and the Checking Account Analogy

A useful analogy is the process of balancing a checking account. A person keeps a register of transactions. The bank keeps another record of the same transactions. The two records are maintained independently and may be organized differently. To determine whether the personal register is accurate, the account holder compares it against the bank statement.

The value of the comparison comes from the fact that the two records describe the same reality from different perspectives. If the records agree, confidence increases. If they do not agree, the discrepancy must be investigated. The cause may be a missing deposit, an unrecorded withdrawal, a bank fee, a timing difference, or an arithmetic error.

Object oriented diagrams work the same way. A class diagram, sequence diagram, use case description, and state diagram may describe the same system from different perspectives. When the diagrams agree, the model becomes stronger. When they disagree, the discrepancy exposes something that needs attention.

Compare structure with behavior: Do the classes contain the operations needed by the sequence diagrams?
Compare behavior with rules: Do the scenarios obey the business rules described by the domain model?
Compare states with operations: Do the operations cause valid state transitions?
Compare associations with messages: Can one object legally communicate with another object according to the class relationships?
Compare terminology: Does the same class name mean the same thing across all diagrams?

One diagram by itself is difficult to verify. Multiple diagrams make verification possible because each diagram can challenge the assumptions made by the others.

Identifying Discrepancies

A discrepancy is a mismatch between two or more views of the system. Discrepancies are not always mistakes, but they are always signals that the model needs further analysis. Sometimes the class diagram is missing a class. Sometimes a sequence diagram assigns behavior to the wrong object. Sometimes a state diagram contains a transition that the business rules do not allow. Sometimes the vocabulary is inconsistent, and two different names are being used for the same concept.

When discrepancies appear, the analyst should not simply force the diagrams to match. The correct response is to ask why the mismatch exists. A discrepancy may reveal a hidden requirement, a misunderstood rule, a missing object, or a design decision that has not yet been documented.
This module introduces several reconciliation questions:

Does each scenario have the classes and operations needed to support it?
Do the messages in the sequence diagrams correspond to valid responsibilities?
Do the objects shown in behavioral diagrams exist in the class diagram?
Do state changes follow valid business rules?
Do interfaces expose the operations needed by collaborating objects?
Do repeated patterns suggest reusable classes or design patterns?
Do all diagrams use consistent names for the same concepts?

These questions help the analyst move from isolated diagrams toward an integrated object oriented model. The goal is not to create more diagrams for their own sake. The goal is to use each diagram as evidence that the model is complete, consistent, and ready to guide implementation.

What This Module Covers

This module focuses on the discipline of comparing object oriented models. You will study why the class diagram must be reconciled with other diagrams, how scenarios test class responsibilities, how interfaces expose required behavior, and how patterns of interaction reveal problems in the design.

By the end of this module, you should understand that a class diagram is necessary but not sufficient. The class diagram defines the structural foundation of the system, but the behavioral diagrams test whether that structure can actually support the system's required use cases. A strong object oriented model is not a collection of unrelated diagrams. It is a coordinated set of views that describe the same system consistently.

In practical C++ design, this matters because classes eventually become code. If the model is inconsistent, the code will inherit those inconsistencies. If responsibilities are unclear in the diagrams, they will be unclear in the implementation. If object collaboration is not tested during analysis, the design may require expensive correction later.

Model reconciliation helps prevent those problems. It gives the analyst a method for finding contradictions before they become defects in the software. It also helps transform diagrams from passive documentation into active design tools.