Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2018 (3 hours, open book, 8 questions of equal value; the first FIVE as they appear in the answer book are marked — all eight are solved here as a study resource).
Cohesion. A well-designed class should have a single, well-defined responsibility, with its attributes and methods all working directly toward that one purpose; low cohesion (a class doing unrelated things) is a design smell.
Coupling. The degree to which classes depend on one another — through method calls, shared data, or inheritance. Lower coupling means a class can be understood, changed and reused with less risk of side effects elsewhere.
Complexity. Both the internal complexity of a class's own logic and its structural complexity within the class hierarchy (how many other classes it collaborates with, how deep its inheritance chain is) affect how hard the design is to understand and safely modify.
Sufficiency, completeness and primitiveness. A class should encapsulate everything needed to fulfil its stated responsibility (sufficiency/completeness) without carrying unrelated extra operations (primitiveness) — both too little and too much responsibility degrade quality.
Encapsulation/information hiding. How well the class's internal representation is hidden behind its public interface; a design that leaks internal representation invites callers to depend on details that should be free to change.
Reusability. Whether the class is designed generally enough to be reused in other contexts without modification, which is a direct product of getting cohesion, coupling and encapsulation right.
Part (b) — a proposed OO quality metric: Coupling Between Object classes (CBO). CBO for a class counts the number of other classes to which it is coupled — through method calls, attribute references, inheritance, or parameter/return types. It is computed by static analysis of the class's source: every distinct class referenced from within the class under measurement (excluding itself and standard library types, by convention) increments the count. A high CBO for a class is a direct, measurable signal of poor encapsulation and higher coupling: the class cannot be understood, tested, or changed in isolation, and a change to any of its many collaborators risks breaking it. Tracked across a whole system, CBO highlights architecturally significant classes — the ones sitting at the centre of many dependencies — which is exactly the information a maintainer needs before touching the system: classes with high CBO should be prioritized for design review, refactoring, and extra regression-test coverage before any change, since empirically higher-coupling classes are associated with a disproportionate share of post-release defects and higher maintenance effort. In this way a single, cheaply computed static metric feeds directly back into both understanding the existing architecture (where are the risky dependency hubs) and planning the maintenance process (where should limited review/test effort be spent).
