| Lesson 5 | Recognizing patterns of reconciliation |
| Objective | Summarize the three-way comparison among use cases, class diagrams, and interaction diagrams, and apply iterative review, refinement, and enhancement. |
Recognizing Patterns of Reconciliation
Reconciliation is the disciplined practice of comparing and aligning your use cases, class diagram, and interaction diagrams so that behavior, structure, and collaborations tell one consistent story. Each pass reveals omissions, conflicts, and naming drift; addressing these quickly keeps models accurate and build-ready.
Three-way comparison (Use cases ↔ Class diagram ↔ Interaction diagrams)
- From use cases to class diagram: extract nouns to candidate classes and attributes; map verbs to operations; turn pre/postconditions into invariants and constraints on associations or attributes.
- From use cases to interaction diagrams: realize each scenario with a sequence or communication diagram; identify lifelines, messages, and object responsibilities needed to satisfy the flow.
- From interaction diagrams back to class diagram: confirm every message targets a defined operation; ensure required associations, multiplicities, navigability, and exceptions exist; introduce interfaces or abstract classes where multiple collaborators share behavior.
- Close the loop to use cases: update the text to reflect discovered domain terms, alternate paths, error handling, and business rules; ensure traceability from steps → messages → operations.
Common reconciliation patterns
| Pair | What to reconcile |
|---|---|
| Use cases ↔ Scenarios | Scenario steps are concrete examples of the use case; verify main and alternate flows are covered and terminology matches. |
| Use cases ↔ Class diagram | Nouns become classes/attributes; verbs become operations; confirm business rules appear as constraints and invariants. |
| Class diagram ↔ Interaction diagrams | Every message has a corresponding operation; responsibilities align with the chosen classes; multiplicities make collaborations feasible. |
| Scenarios ↔ Interaction diagrams | Message order matches the narrative; include error/timeout branches; validate temporal assumptions. |
| Data dictionary ↔ Use cases | Term definitions are used consistently; avoid synonyms that hide the same concept under multiple names. |
| Data dictionary ↔ Class diagram | Attribute types and allowable values match definitions; units and ranges are explicit. |
| Object diagrams ↔ Class diagram | Sample snapshots are legal instances of the model; multiplicities and constraints hold on concrete examples. |
Iterative review, refinement, and enhancement
1) Iterative review
- Time-box passes (e.g., 30–45 minutes per diagram set) to maintain momentum.
- Run a fixed checklist each pass: naming consistency, operation/message alignment, multiplicities, exceptions, and business rule coverage.
- Log gaps (unknowns, disputes, missing rules) directly on the model or in a visible issue list to drive the next pass.
2) Refinement
- Simplify responsibilities: move behavior to the class with the best information and lowest coupling.
- Normalize names: one term per concept across use cases, diagrams, and dictionary.
- Clarify constraints: record invariants, pre/postconditions, and multiplicities where they are enforced.
3) Enhancement
- Introduce interfaces/abstract classes when multiple lifelines share protocols.
- Factor cross-cutting concerns (logging, validation, authorization) into dedicated services or collaborators.
- Model edge cases with additional scenarios and alternate flows; capture recovery paths and timeouts.
Checklist for each reconciliation pass
- Every scenario step traces to messages, and every message traces to an operation.
- All operations have owning classes with the necessary state and associations.
- Multiplicity/visibility make collaborations possible; no illegal or orphan references.
- Business rules are captured once, in the right place (attribute constraint, association, or operation contract).
- Terminology matches the data dictionary; no competing synonyms.
- At least one object diagram demonstrates a realistic, valid snapshot of key cases.
Exit criteria
- No unresolved naming conflicts; dictionary is current.
- Each use case has at least one realizing interaction diagram; exceptions modeled.
- Message-to-operation mapping is complete; no “phantom” messages or missing operations.
- Sample object diagrams validate multiplicities and constraints on realistic data.
Nothing is set in stone. Keep testing assumptions, asking questions, and using the diagrams to invite participation and uncover better solutions.