Jahziah.
العربية

STUDY GUIDE · GKU 5

Software design study guide (Software Engineering)

Design is where requirements become structure: the decisions about parts, their responsibilities and how they talk, made before the code fixes them in place. The first part covers the design process and the issues every design must settle (concurrency, events, persistence, distribution, errors, interaction, security), the principles that keep complexity down (cohesion, coupling, information hiding, SOLID), the architectural styles and how quality requirements choose among them, the notations and tools — UML and its views — and human-computer interaction, including the keystroke-level model for comparing two interface designs by numbers. The second part is detailed design: the Gang of Four patterns with running code, paradigms, platforms and frameworks, the mechanics of persistence, distribution and fault tolerance, and how a design is evaluated with ISO/IEC 25010 quality attributes, reviews and metrics. Object-oriented basics, design by contract, concurrency primitives and GUI event loops are taught in GKU 1 and are cross-referenced rather than repeated.

Continue in the app

Structured by the official ETEC subject standard for this topic: every listed topic and learning outcome, with formulas, figures and worked examples. The full sections are available to members in the app.

SKU 5.1 · Design concepts and strategies

  1. The design process, its key issues and strategies

    What software design produces and in what order, the seven issues every design must settle — concurrency, events, persistence, distribution, errors, interaction, security — and the strategies for getting from requirements to a structure: top-down, bottom-up, object-oriented, data-driven and component-based.

  2. Design principles: minimising complexity

    The principles that keep a design understandable and cheap to change: abstraction and modularity, the scales of cohesion and coupling, information hiding, and the SOLID principles of object-oriented design, each with the symptom that shows it is being broken.

  3. Architectural design and styles

    The architectural styles a designer chooses from — layered, client–server, pipe-and-filter, model–view–controller, repository, event-driven, microservices — what each is good and bad at, and how quality requirements decide among them.

  4. Design notations, views and tools

    How designs are written down and with what: the UML diagram families and when to use each, Kruchten's 4+1 views, structured notations, and the kinds of design tools — modelling tools, diagrams as code, prototyping tools — with criteria for choosing among them.

  5. Human-computer interaction and interface design

    Designing the interaction and presentation of a system: the user-centred design process, Norman's principles and Shneiderman's golden rules, separating presentation from logic, and interaction analysis with the keystroke-level model, which predicts an expert's task time from the operators it needs.

SKU 5.2 · Detailed design and evaluation

  1. Design patterns

    Named, reusable solutions to recurring design problems: the Gang of Four catalogue in its three families, the intent of the patterns that exams and real code use most, how to recognise when one applies, and Observer and Strategy in running code.

  2. Design paradigms, platforms and frameworks

    The main ways of organising a design — structured, object-oriented, component-based, service-oriented, event-driven, aspect-oriented, model-driven — the platforms software is built on, and frameworks: inversion of control, dependency injection, and how framework code calls yours through events and callbacks.

  3. Persistence, distribution and fault tolerance

    The detailed-design mechanics behind three key issues: keeping data with repositories, object mapping and transactions; splitting components across machines without pretending the network is reliable; and handling errors with exceptions, timeouts, retries with backoff, circuit breakers and redundancy.

  4. Design evaluation and quality

    How a design is judged before and after it is built: the ISO/IEC 25010 quality characteristics, quality-attribute scenarios and architecture reviews (ATAM), and design metrics — the Chidamber–Kemerer class metrics and Martin's package instability, abstractness and distance — with what each can and cannot reveal.

MORE SOFTWARE ENGINEERING GUIDES

All study guides

Read the full guide beside your practice questions.

Open the app