wsasasdas
It gives a common checklist and language for quality (like usability, reliability, security), so teams set clear goals. It breaks each into measurable sub-points, which guide design and testing. Result: better coverage, fewer surprises, and software built and verified against the right qualities.
Apache Ant, it improves Maintainability → Modifiability because the build logic lives in one XML file that’s easy to change, and Portability → Installability because scripted one-command builds make setup repeatable on any machine/CI.
For Git, it strengthens Maintainability → Analysability since history/diffs/blame make changes easy to understand and faults easier to locate, and Maintainability → Modifiability because branching/merging supports safe, parallel change.
For JavaDocs, it boosts Usability → Learnability by giving clear API guidance so new users can learn usage quickly, and Maintainability → Analysability (also Reusability) since documented contracts and parameters make code easier to reason about and reuse safely.
For JUnit, it enhances Maintainability → Testability by turning requirements into verifiable unit tests and Maintainability → Analysability because failing tests pinpoint defects.
Use case the main actors are the Student, the System, and the Student Record Database
. The Student is the primary actor who registers for classes through the system.
The superfluous detail is “Online classes are 10% cheaper than regular classes,” because pricing does not affect the registration process or system behavior
.
If it’s a hollow triangle pointing to a superclass, that’s Generalization (inheritance)
. If there’s a filled (black) diamond at one end (the “whole”) with a part attached, that’s Composition (part can’t exist without whole). If it’s a hollow (white) diamond, that’s Aggregation (part can exist independently). If it’s just a plain solid line (maybe with multiplicities, no diamond/triangle), that’s a simple Association
.
(i) Model (2 marks)
The Model represents the domain state and rules. It stores and updates game data, enforces constraints, provides read APIs for the UI to query, and notifies interested views when its state changes so they can refresh.
(ii) Controller (2 marks)
The Controller interprets user input and turns it into actions on the system. It translates gestures/commands into updates to the Model and can direct which View to show or refresh based on the user’s actions.
(iii) View (2 marks)
The View is the visual presentation of the Model. It requests the current state from the Model to render the UI and, after being notified of changes, redraws to reflect the updated state.
(iv–viii) Diagram arrows a–e (1 mark each)
Arrow a (Model → View) is “notify state change.” Arrow b (View → Model) is a “state query” to fetch data. Arrow c(View → Controller) is the “user gesture/input” sent for handling. Arrow d (Controller → View) is a “view selection/update” command. Arrow e (Controller → Model) is a “state change” request that applies the user’s action.