| 1 |
SOLID principles applied; no god classes with excessive responsibilities |
Pass |
Each class has one responsibility (Class Table); view, view model, session, deck and adapters are separate. |
| 2 |
Visibility markers correct and consistent (+ public, - private, # protected) |
Pass |
Visibility markers are on all members. |
| 3 |
Relationships correctly distinguished: Association vs Aggregation vs Composition vs Dependency |
Pass |
Composition (Vocabulary and Card), aggregation (Deck), composition (LevelViewModel and LevelChoice), association, dependency and realization are distinguished. |
| 4 |
Multiplicities and navigability specified on all associations |
Pass |
Multiplicities are on the associations; dependencies are directed. |
| 5 |
Applied design patterns are annotated explicitly (e.g. Singleton, Factory, Strategy) |
Pass |
Pattern Annotations table lists Repository, Ports and adapters, Null Object, MVVM, Composition root. |
| 6 |
Method signatures are traceable to Operation Contracts and/or design Sequence Diagrams |
Pass |
Method Traceability table maps every operation, including Level.first, Deck.within, LevelViewModel.choices and LevelView.choose, to OC-001 and SD-001. |
| 7 |
Class names and structure remain consistent with the Domain Model concepts they refine |
Pass |
The Class Table has a Refines column; Level refines the concept Level of DM-001; names match the dictionary's IT terms. |
| 8 |
No circular dependencies between classes/packages unless explicitly justified |
Pass |
Dependency Check states there are no cycles. |
| 9 |
Dependencies between classes and packages point inward: domain classes do not depend on infrastructure, delivery or framework classes |
Pass |
Domain imports nothing; infrastructure and presentation point inward (Dependency Check). |
