Unit 10: Critical Analysis

Maintainability is the ease with which a system can be modified — to fix bugs, add features, or adapt to changing requirements.

In a class diagram, signs of good maintainability:

• Classes with clearly bounded responsibilities (high cohesion)
• Few and purposeful associations (low coupling)
• Encapsulated attributes (private visibility) with controlled access via operations
• Use of inheritance only where justified — not as a shortcut

Signs of poor maintainability:

• God classes with many attributes, operations, and associations
• Bidirectional associations between many classes (high coupling)
• Direct access to attributes across class boundaries

Scalability is the ability of a system to handle increased demand without degradation in performance or correctness.

Three types of scalability matter:

• Load scalability — can the system handle more users or more data? Class design issues include: shared mutable state, god classes that become bottlenecks, insufficient separation between data access and business logic.
• Feature scalability — can new features be added without redesigning the core? Designs with low coupling and clear abstractions scale well; tightly coupled designs resist extension.
• Team scalability — can multiple developers work on the system without conflicts? High coupling means many developers touching the same class; low coupling allows independent parallel development.

Usability is usually associated with user interface design, but it has a place in UML analysis too — at the level of use case and requirements.

Usability questions to ask of a use case diagram:

• Are all user goals represented as use cases?
• Is the number of steps to achieve a common goal reasonable?
• Are optional features («extend») used to keep the core flow simple?
• Are there any mandatory steps that users would find unnecessary?

A system that is functionally correct but requires ten steps to perform a simple task has a usability problem that is visible — and solvable — at the design stage.

Reliability concerns a system's ability to perform correctly under expected and unexpected conditions. At the design level, this means thinking about failure modes.

In a sequence diagram, signs of reliability awareness:

• alt fragments modelling error conditions (not just the happy path)
• Explicit handling of null responses, timeouts, and service failures
• No single object handling every interaction (a single point of failure)

A sequence diagram that only models the "everything goes right" scenario is incomplete. Real systems fail. A design that does not model failure has not been properly analysed.

Security in software design concerns two primary concerns: authorisation (who is allowed to do what) and data protection (what information is kept private).

In a use case diagram:

• Are actor permissions correctly modelled? Can a Guest perform use cases reserved for a Registered User?
• Are administrative use cases separated from user-facing ones?

In a class diagram:

• Are sensitive attributes (passwords, payment data) private?
• Is there a clear separation between authentication/authorisation logic and business logic?

Security is not an add-on — it is visible in the structure of a well-designed model.

Compare these two critiques of the same class diagram element:

The analytical version names the element, cites the evidence (nine associations, twenty-three operations), applies the criterion (maintainability / cohesion), and proposes a specific improvement.

This four-step structure ensures a critique is complete:

• Describe — name the specific element you are examining. "The Enrolment class has a composition relationship with Student."
• Evaluate — apply a quality criterion. "This raises a reliability concern."
• Justify — explain why, with evidence. "If a Student record is deleted, all associated Enrolment records are destroyed too. This could result in unintentional data loss if a student account is deactivated rather than deleted."
• Suggest — propose a specific improvement. "Change the relationship to aggregation, and add a status attribute to Student (active/inactive) to handle deactivation without deletion."

Evidence in a design critique is specific and observable — something another person looking at the same diagram would also see.

Valid evidence:

• The number of associations from a single class
• The number of operations in a class
• The multiplicity values on an association
• The absence of an error path in a sequence diagram
• A missing class or operation
• The direction and type of a relationship (composition vs aggregation)

Not valid evidence:

• "It looks complicated" — this is an impression, not evidence
• "I would have done it differently" — this is preference, not analysis
• "The names are confusing" — this is valid only if you explain why a specific name is misleading

Vague criticism: Stating that a design "has problems" or "could be improved" without identifying the specific element, the criterion violated, or the improvement. This is the most common weakness in student critiques.

Criticism without suggestion: Identifying a problem but not proposing a solution. A good critique closes the loop: here is the problem, here is what to do about it.

Unrealistic suggestions: Proposing improvements that ignore the constraints of the project (e.g. "rebuild from scratch", or suggestions that violate stated requirements). Suggestions should be targeted, feasible, and justified.

Praising without justification: "The class diagram is well-structured" is not an evaluation. If something is done well, cite what it is and why it works.