3.5 KiB
3.5 KiB
Quality Criteria: Design Class Diagram (DCD)
Metadata
| Key | Value |
|---|---|
| ID | QC-DCD-001 |
| CrossReference | QC-DM-001, QC-SD-001, QC-ERD-001, QC-PY-001, QC-CL-001, QC-CPP-001, QC-CS-001 |
| DomainLanguages | IT Professional English |
Version History
| Date | Status | Author | Reviewer | Change | Commit |
|---|---|---|---|---|---|
| 2026-10-01 | Accepted | Jens Tirsvad Nielsen | S07 | First public release (1.0.0) | — |
Purpose
The Design Class Diagram specifies the concrete classes, attributes, operations, and relationships that will be implemented, refining the Domain Model with design decisions from the Sequence Diagrams. Its quality directly determines the maintainability and correctness of the resulting implementation.
Quality Criteria Checklist
Level: Mandatory criteria are the baseline every instance must meet; Optional criteria are advanced and may be deferred.
| # | Criterion | Level | ISO/IEC 25010 Characteristic(s) | Notes |
|---|---|---|---|---|
| 1 | SOLID principles applied; no god classes with excessive responsibilities | Mandatory | Maintainability | Single Responsibility Principle is the most commonly violated |
| 2 | Visibility markers correct and consistent (+ public, - private, # protected) |
Mandatory | Maintainability | Encapsulation must be explicit, not assumed |
| 3 | Relationships correctly distinguished: Association vs Aggregation vs Composition vs Dependency | Mandatory | Functional Suitability, Maintainability | Diamond notation must match actual ownership semantics |
| 4 | Multiplicities and navigability specified on all associations | Mandatory | Functional Suitability | Unspecified navigability leads to ambiguous implementation |
| 5 | Applied design patterns are annotated explicitly (e.g. Singleton, Factory, Strategy) | Optional | Maintainability | Pattern intent should be discoverable from the diagram |
| 6 | Method signatures are traceable to Operation Contracts and/or design Sequence Diagrams | Mandatory | Functional Suitability, Maintainability | Prevents drift between design layers |
| 7 | Class names and structure remain consistent with the Domain Model concepts they refine | Mandatory | Maintainability, Compatibility | Design classes should not silently rename or drop domain concepts |
| 8 | No circular dependencies between classes/packages unless explicitly justified | Optional | Maintainability, Reliability | Circular coupling harms testability and portability |
Common Defects
- God classes accumulating unrelated responsibilities
- Missing or incorrect visibility markers
- Composition used where the parts do not share the whole's lifecycle (or vice versa)
- Method signatures that don't match any Operation Contract or Sequence Diagram message
- Unannotated or inconsistently applied design patterns
Traceability Rule
- Backward: Must trace to the Domain Model checklist (QC-DM-001) (concept origin) and the design Sequence Diagram checklist (QC-SD-001) (object collaborations and method signatures)
- Forward: Feeds into the Entity Relationship Diagram checklist (QC-ERD-001) for persistent classes, and into the language code checklists (QC-PY-001, QC-CL-001, QC-CPP-001, QC-CS-001) for the implementation of the classes