How unit 3 is examined
Software design turns the requirements into a blueprint that can be coded; design concepts (cohesion and coupling), user interface design, function-oriented design and design metrics carry the most marks.
The Software Design Process
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>
Definition. <mark>Software design is the process of transforming the requirements (the SRS) into a blueprint of the software's architecture, data, interfaces and components from which code can be written.</mark>
Key points.
- Design sits between analysis and coding: the input is the SRS and the output is the design document, which the programmers implement.
- Design proceeds in levels: data design (data structures and database), architectural design (major components and their relations), interface design (user, and between components) and component-level (procedural) design (algorithm of each module).
- It is iterative: a rough high-level design is refined into a detailed design, and each step is checked against the requirements.
- A good design is correct and complete, understandable, modular with high cohesion and low coupling, and easy to change.
- A design strategy is the overall approach used to decompose the system. Function-oriented (top-down) design decomposes the system into functions and sub-functions, starting from the main function and refining it step by step.
- Bottom-up design first builds low-level reusable components and then combines them into larger ones; it suits systems built from an existing library.
- Object-oriented design decomposes the system into objects and classes that hold both data and operations; it suits large, changing systems. Data-driven design derives the structure from the structure of the data (for example, a file or database record layout), as in data-processing programs.
Answer frame. Open with the definition of design and its place between SRS and code; list the four design levels; develop the strategies (function-oriented top-down, bottom-up, object-oriented, data-driven) with one applicability line each; then summarise the design concepts of the next topic in three lines (abstraction, modularity, cohesion-coupling); close with "a good design gives an easily maintainable system".
Asked: [7 marks] (Dec 2020) Explain the types of software design strategies available. Asked: [7 marks] (Jun 2026) Explain the Software Design Process and discuss important Design Concepts and Principles.
Design Concepts and Principles
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>
Definition. <mark>Design concepts are the fundamental ideas (abstraction, modularity, architecture, information hiding, functional independence, refinement, refactoring) that guide the creation of a good software design.</mark>
Key points.
- Abstraction hides detail and shows only the essential view; procedural abstraction names a sequence of instructions (for example, "sort") and data abstraction names a collection of data (for example, "Student").
- Modularity divides the software into separately named and addressable modules, so each is easy to understand, develop, test and change; too few modules give large complex ones and too many raise integration cost.
- Architecture is the overall structure of the software: its components, their properties and the relationships among them.
- Information hiding says each module conceals its design decisions (data and algorithms) behind a small interface, so a change inside it does not spread to other modules.
- Separation of concerns splits the problem into parts so that each part addresses one concern; this is the idea behind modularity.
- Functional independence means each module does one well-defined job with little interaction with others; it is measured by cohesion (inside a module) and coupling (between modules). The goal is high cohesion and low coupling.
- Refinement is stepwise elaboration: start from a general statement and add detail at each step until the code level. Refactoring is restructuring working code to improve its internal design without changing its behaviour.
Modularization. Decomposing the system into modules gives easier development in parallel, easier testing and maintenance, and reuse of modules.
Cohesion (strength within a module), best to worst:
| Type | Meaning |
|---|---|
| Functional | Every element works towards one single task (best) |
| Sequential | Output of one element is input of the next |
| Communicational | Elements work on the same data |
| Procedural | Elements follow one control sequence |
| Temporal | Elements run at the same time (for example, initialisation) |
| Logical | Elements do similar logical tasks, one chosen by a flag |
| Coincidental | Elements are unrelated (worst) |
Coupling (dependence between modules), best to worst:
| Type | Meaning |
|---|---|
| Data | Modules pass only simple data parameters (best) |
| Stamp | Modules pass a whole data structure, using part of it |
| Control | One module passes a flag that controls the other's logic |
| External | Modules share an external device, format or protocol |
| Common | Modules share global data |
| Content | One module uses or changes the inside of another (worst) |
Low coupling and high cohesion make a design easy to maintain, reuse and test, since a change stays inside one module.
Answer frame. Open with the definition of design concepts; then develop points 1-7 in order; give the two tables for the cohesion and coupling question; close with "high cohesion and low coupling give a maintainable, reusable design". For "any four principles" pick abstraction, modularity, information hiding and cohesion-coupling with one example each.
Pitfall: Reversing the order: functional cohesion and data coupling are the best; coincidental cohesion and content coupling are the worst.
Asked: [7 marks] (May 2019, Jun 2023, Jun 2025) Explain about the various design concepts considered during design. Discuss the basic principles of software design. Asked: [7 marks] (Dec 2020, Jun 2020) What is a modular system? Explain the types of cohesion and coupling. Describe how a good design is influenced by cohesion and coupling. Asked: [7 marks] (Jun 2025) Describe any four fundamental software design principles. Asked: [14 marks] (Dec 2020) Write short notes on a) Modularization b) Coupling cohesion c) Use case modeling
Software Modeling and UML
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>
Definition. <mark>Software modeling is building abstract representations of the system, from different views, to understand and communicate its structure and behaviour before it is built; UML (Unified Modeling Language) is the standard graphical language for it.</mark>
Key points.
- A model is a simplified picture of the system; it helps analysts, designers and clients agree on what is to be built and finds errors early.
- The structural view shows the static parts and their relations: class diagram, object diagram, component and deployment diagrams.
- The behavioural view shows how the system acts over time: use case, sequence, collaboration, state chart and activity diagrams.
- The functional view shows what data transformations the system performs, as in a data flow diagram.
- In design, the structural view gives the classes and components, the behavioural view gives their interactions and states, and together they give a complete design that is checked against the requirements.
- A use case diagram shows actors (users or external systems) as stick figures, use cases as ovals, and the association between them; it captures what the system does for each actor.
Example. Library system: the Member actor uses "Issue book" and "Return book", and the Librarian uses "Issue book" and "Add book".
Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-01" viewBox="0 0 424 252" width="424" height="252" role="img" aria-label="Use case diagram of a library system: Mem = Member, Lib = Librarian; Iss, Ret, Add = Issue book, Return book, Add book"><style>#dsfig-u3-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-01 .t{fill:#16181D;font-weight:500}#dsfig-u3-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-01 .dot{fill:#16181D}#dsfig-u3-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-01 .ah{fill:#454C5A}#dsfig-u3-01 .ah.hi{fill:#2340B8}#dsfig-u3-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-01 .e{stroke:#B1B7C3}html.dark #dsfig-u3-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-01 .t{fill:#E6E8ED}html.dark #dsfig-u3-01 .t.inv{fill:#0F1115}html.dark #dsfig-u3-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-01 .dot{fill:#E6E8ED}html.dark #dsfig-u3-01 .ann{fill:#8FA3FF}html.dark #dsfig-u3-01 .lbl{fill:#858D9C}html.dark #dsfig-u3-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-01 .ah{fill:#B1B7C3}html.dark #dsfig-u3-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah10" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh10" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M57,117.5 L195,48.5"/><path class="e" d="M59,126 L193,126"/><path class="e" d="M367,117.5 L229,48.5"/><path class="e" d="M367,134.5 L229,203.5"/><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">Mem</text><circle class="n" cx="212" cy="40" r="18"/><text class="t" x="212" y="40" dy=".35em" text-anchor="middle">Iss</text><circle class="n" cx="212" cy="126" r="18"/><text class="t" x="212" y="126" dy=".35em" text-anchor="middle">Ret</text><circle class="n" cx="212" cy="212" r="18"/><text class="t" x="212" y="212" dy=".35em" text-anchor="middle">Add</text><circle class="n" cx="384" cy="126" r="18"/><text class="t" x="384" y="126" dy=".35em" text-anchor="middle">Lib</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Use case diagram of a library system: Mem = Member, Lib = Librarian; Iss, Ret, Add = Issue book, Return book, Add book</figcaption></figure>
Answer frame. Open with the definition of modeling and UML; develop points 1-5 with the three views; draw the use case diagram above and name the other UML diagrams; close with "UML views together give a complete design".
Asked: [7 marks] (Jun 2022, Dec 2024) What do you mean by software modeling? How are model views used in designing software? Asked: [7 marks] (Dec 2024) How is system modeling achieved using UML? Explain with a suitable example.
Architectural Design
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>
Definition. <mark>Architectural design defines the overall structure of the system: its major components, their responsibilities and the relationships among them.</mark>
Key points.
- Its input is the SRS and its output is the architectural model, which is the base for all later design.
- The steps are: represent the system in context (external actors and systems), identify the major components, choose an architectural style, and refine the components and their interfaces.
- It is shown as block diagrams of components and connectors, so the client also understands it.
- It decides the quality attributes of the system, such as performance, security, scalability and maintainability.
- Procedural (component-level) design comes after it: it fixes the algorithm, data structures and control flow inside each module, using flow charts, decision tables or pseudo-code.
- Architectural design is the "what parts and how connected" view; procedural design is the "how each part works" view.
Example. Online shopping: Web UI, Catalogue, Cart and Payment components over one Database.
Answer frame. Open with the definition; list the steps; draw the block diagram of the example; then describe procedural design in three lines; close with "architecture fixes structure, procedural design fixes the logic".
Asked: [7 marks] (May 2019) Explain architectural and procedural design for a software. Asked: [7 marks] (Jun 2026) Explain Architectural Design with example.
Architectural Views and Styles
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>
Definition. <mark>An architectural style is a reusable pattern of organising components and connectors that suits a class of systems; architectural views are the different perspectives from which the architecture is described.</mark>
Key points.
- The 4+1 view model describes the architecture by the logical view (classes and functions), process view (concurrency and communication), development view (module organisation) and physical view (hardware deployment), tied together by the +1 scenario (use case) view.
- Layered style arranges components in layers where each layer uses only the one below; examples are the OSI model and operating systems.
- Client-server style has servers that provide services and clients that request them over a network; examples are web and database applications.
- Pipe-and-filter style passes data through a chain of filters that each transform it; examples are compilers and Unix pipelines.
- Repository (data-centred) style keeps shared data in a central store that independent components read and write; examples are IDEs and databases.
- MVC splits the application into Model (data), View (display) and Controller (input), so the interface can change without touching the data; microservices build the system as small independent services that talk over the network.
- A design pattern is a proven solution to a recurring design problem, with a name, problem, solution and consequences (creational, structural and behavioural, such as Singleton, Adapter and Observer). Pattern-based design picks matching patterns for each problem, adapts them, and combines them into the design, which gives reuse, a common vocabulary and faster, safer design.
Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-02" viewBox="0 0 80 252" width="80" height="252" role="img" aria-label="Layered style: UI = presentation layer, BL = business logic layer, DB = data layer"><style>#dsfig-u3-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-02 .t{fill:#16181D;font-weight:500}#dsfig-u3-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-02 .dot{fill:#16181D}#dsfig-u3-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-02 .ah{fill:#454C5A}#dsfig-u3-02 .ah.hi{fill:#2340B8}#dsfig-u3-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-02 .e{stroke:#B1B7C3}html.dark #dsfig-u3-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-02 .t{fill:#E6E8ED}html.dark #dsfig-u3-02 .t.inv{fill:#0F1115}html.dark #dsfig-u3-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-02 .dot{fill:#E6E8ED}html.dark #dsfig-u3-02 .ann{fill:#8FA3FF}html.dark #dsfig-u3-02 .lbl{fill:#858D9C}html.dark #dsfig-u3-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-02 .ah{fill:#B1B7C3}html.dark #dsfig-u3-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah11" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh11" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M40,59 L40,105" marker-end="url(#ah11)"/><path class="e" d="M40,145 L40,191" marker-end="url(#ah11)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">UI</text><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">BL</text><circle class="n" cx="40" cy="212" r="18"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">DB</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Layered style: UI = presentation layer, BL = business logic layer, DB = data layer</figcaption></figure>
Answer frame. Open with the definition of style and the 4+1 views; develop points 2-6 as a list with one example each; draw the layered figure; for the pattern question use point 7 and name three patterns; close with "the style is chosen by the quality attributes required".
Asked: [7 marks] (Dec 2024) List and explain different kinds of architecture styles and patterns. Asked: [7 marks] (Jun 2025) What are architectural views? Briefly describe different architectural styles. Asked: [7 marks] (Jun 2024) Discuss pattern based software design in detail.
User Interface Design
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>
Definition. <mark>User interface design creates the screens, controls and interaction through which the user works with the software, so that it is easy, efficient and pleasant to use.</mark>
Key points (Theo Mandel's golden rules).
- Place the user in control: let the user work without being forced into unneeded actions, allow interruption and undo, provide flexible interaction (keyboard or mouse), and hide technical internals.
- Rule 1 also says to let users customise the interface and to design for casual and expert users alike.
- Reduce the user's memory load: show visual cues and reminders instead of forcing recall, keep defaults meaningful, use intuitive shortcuts, and disclose information progressively.
- Make the interface consistent: keep the same look, menus and terminology across screens, so that what the user learns in one place works everywhere.
- Consistency also means the current task stays in context, feedback is given for every action, and an existing model the user knows (for example, a familiar layout) is not changed without reason.
- Following these rules gives good usability: it cuts errors and training time and raises satisfaction.
Interface analysis and design model. Four models take part: the user model (profile of the users), the design model (the designer's view of the system), the mental model (the user's own image of how the system works) and the implementation model (the look and feel of the running interface, with its help and documents). The aim is to make the implementation model match the user's mental model.
Steps. Interface analysis studies the user (who they are, skill level), the task (actions and objects) and the environment (place, devices); design then defines the objects and actions and the screen layout; then it is built with a prototype and tested with users, and the findings loop back to analysis.
Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-03" viewBox="0 0 510 252" width="510" height="252" role="img" aria-label="Interface analysis and design process: Usr = user analysis, Tsk = task analysis, Env = environment analysis, Des = interface design, Imp = implementation (prototype), Val = validation, with feedback to analysis"><style>#dsfig-u3-03 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-03 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-03 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-03 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-03 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-03 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-03 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-03 .t{fill:#16181D;font-weight:500}#dsfig-u3-03 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-03 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-03 .dot{fill:#16181D}#dsfig-u3-03 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-03 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-03 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-03 .ah{fill:#454C5A}#dsfig-u3-03 .ah.hi{fill:#2340B8}#dsfig-u3-03 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-03 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-03 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-03 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-03 .e{stroke:#B1B7C3}html.dark #dsfig-u3-03 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-03 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-03 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-03 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-03 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-03 .t{fill:#E6E8ED}html.dark #dsfig-u3-03 .t.inv{fill:#0F1115}html.dark #dsfig-u3-03 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-03 .dot{fill:#E6E8ED}html.dark #dsfig-u3-03 .ann{fill:#8FA3FF}html.dark #dsfig-u3-03 .lbl{fill:#858D9C}html.dark #dsfig-u3-03 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-03 .ah{fill:#B1B7C3}html.dark #dsfig-u3-03 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-03 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-03 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-03 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah12" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh12" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M57,48.5 L193.2,116.6" marker-end="url(#ah12)"/><path class="e" d="M59,126 L191,126" marker-end="url(#ah12)"/><path class="e" d="M57,203.5 L193.2,135.4" marker-end="url(#ah12)"/><path class="e" d="M231,126 L320,126" marker-end="url(#ah12)"/><path class="e" d="M360,126 L449,126" marker-end="url(#ah12)"/><path class="e" d="M451,126 L61,126" marker-end="url(#ah12)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Usr</text><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">Tsk</text><circle class="n" cx="40" cy="212" r="18"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">Env</text><circle class="n" cx="212" cy="126" r="18"/><text class="t" x="212" y="126" dy=".35em" text-anchor="middle">Des</text><circle class="n" cx="341" cy="126" r="18"/><text class="t" x="341" y="126" dy=".35em" text-anchor="middle">Imp</text><circle class="n" cx="470" cy="126" r="18"/><text class="t" x="470" y="126" dy=".35em" text-anchor="middle">Val</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Interface analysis and design process: Usr = user analysis, Tsk = task analysis, Env = environment analysis, Des = interface design, Imp = implementation (prototype), Val = validation, with feedback to analysis</figcaption></figure>
Answer frame. For the golden rules: open with Mandel's three rules; develop each rule with its sub-points and a UI example (undo, tooltips, same menus); close with the usability gain. For the model question: open with the four models; draw the process figure; explain analysis, design, implementation and validation in order; close with the golden rules.
Asked: [7 marks] (May 2019, Jun 2024) Describe the golden rules for interface design. Asked: [7 marks] (Jun 2022) With a neat diagram explain interface analysis and design model. Asked: [7 marks] (Jun 2024) List and explain the golden rules of User-Interface design.
Function-oriented Design
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>
Definition. <mark>Function-oriented design decomposes the system into a set of functions, each with its own inputs and outputs, refined top-down, with the data flowing between them shown in data flow diagrams.</mark>
Key points.
- The system is seen as a set of functions that transform inputs to outputs; the main function is split into sub-functions, and these into smaller ones, until each is simple enough to code.
- The Data Flow Diagram (DFD) shows processes (circles), data stores, external entities and the data flows between them; it is drawn in levels, from the context diagram (level 0) down to detailed levels.
- The data dictionary defines every data item, flow and store that appears in the DFD, so the meaning is precise.
- The structure chart shows the module hierarchy: boxes are modules, arrows are calls, and small arrows carry the data and control passed.
- The design steps are: draw the DFD, identify the type of flow (transform or transaction), map the DFD into a structure chart, then refine it and check cohesion and coupling.
- Good function-oriented design has high cohesion in each module, low coupling between modules, and limited fan-out.
- Advantages are that it is simple, top-down, easy to follow and suits data-processing systems; the drawback is that data is shared globally, so a change in a data structure affects many functions.
Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-04" viewBox="0 0 285 130" width="285" height="130" role="img" aria-label="tree diagram"><style>#dsfig-u3-04 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-04 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-04 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-04 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-04 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-04 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-04 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-04 .t{fill:#16181D;font-weight:500}#dsfig-u3-04 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-04 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-04 .dot{fill:#16181D}#dsfig-u3-04 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-04 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-04 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-04 .ah{fill:#454C5A}#dsfig-u3-04 .ah.hi{fill:#2340B8}#dsfig-u3-04 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-04 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-04 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-04 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-04 .e{stroke:#B1B7C3}html.dark #dsfig-u3-04 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-04 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-04 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-04 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-04 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-04 .t{fill:#E6E8ED}html.dark #dsfig-u3-04 .t.inv{fill:#0F1115}html.dark #dsfig-u3-04 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-04 .dot{fill:#E6E8ED}html.dark #dsfig-u3-04 .ann{fill:#8FA3FF}html.dark #dsfig-u3-04 .lbl{fill:#858D9C}html.dark #dsfig-u3-04 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-04 .ah{fill:#B1B7C3}html.dark #dsfig-u3-04 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-04 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-04 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-04 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah13" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh13" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><line class="e" x1="128.5" y1="37" x2="43.5" y2="101"/><line class="e" x1="128.5" y1="37" x2="126.5" y2="101"/><line class="e" x1="128.5" y1="37" x2="213.5" y2="101"/><rect class="n" x="102.5" y="22" width="52" height="30" rx="8"/><text class="t" x="128.5" y="37" dy=".35em" text-anchor="middle">Main</text><rect class="n" x="14" y="86" width="59" height="30" rx="8"/><text class="t" x="43.5" y="101" dy=".35em" text-anchor="middle">Input</text><rect class="n" x="89" y="86" width="75" height="30" rx="8"/><text class="t" x="126.5" y="101" dy=".35em" text-anchor="middle">Process</text><rect class="n" x="180" y="86" width="67" height="30" rx="8"/><text class="t" x="213.5" y="101" dy=".35em" text-anchor="middle">Output</text></svg></figure>
Example. A payroll system: main module "Payroll" calls Read Hours, Compute Pay and Print Slip.
Answer frame. Open with the definition and the top-down idea; draw a DFD or structure chart; develop points 2-5 in order (DFD, data dictionary, structure chart, mapping steps); close with cohesion-coupling and the advantages in points 6-7.
Asked: [7 marks] (Nov 2023, Dec 2024, Jun 2024) Discuss the function oriented design strategies in detail. Asked: [7 marks] (Dec 2024, Jun 2024) What do you understand by Function-Oriented design? Discuss in detail. Briefly explain function-oriented design.
SA/SD and Component Based Design
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>
Definition. <mark>SA/SD is the structured method in which Structured Analysis (SA) models what the system does with DFDs, and Structured Design (SD) converts that model into a structure chart of modules.</mark>
Key points.
- Structured Analysis produces the DFD, the data dictionary and the entity-relationship diagram (ERD) for the data, and states each process in a mini-specification.
- Structured Design takes the DFD and produces the structure chart by modular decomposition: a transform DFD gives input, central-transform and output branches, and a transaction DFD gives a transaction centre that calls one module per transaction type.
- Component based design builds the system by assembling pre-built, reusable components, each with a well-defined interface, instead of coding everything anew.
- Its process is: find suitable components in a library, qualify them (check function and interface), adapt them, compose them into the system, and update the library.
- Components communicate only through their interfaces, which are standardised, so a component can be replaced by another with the same interface.
- The advantages are lower cost and shorter time, higher reliability (components are already tested), easier maintenance, and reuse.
Answer frame. Open by expanding SA and SD; list the SA products, then the SD products with the DFD-to-structure-chart conversion; then component based design with steps and advantages; close with "reuse cuts cost and raises reliability".
Asked: [7 marks] (Jun 2023) What are SA and SD? Discuss component based design and its advantages. Asked: [7 marks] (Jun 2025) Explain the SA/SD approach to function-oriented design.
Design Metrics
<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>
Definition. <mark>Design metrics are quantitative measures of a design (its size, complexity, coupling and cohesion) that are used to judge its quality before coding.</mark>
Key points.
- They give an objective view of design quality, help compare alternatives, find weak modules early, and predict maintainability and testability.
- Fan-in is the number of modules that call a module, and fan-out is the number it calls; high fan-in means good reuse, but high fan-out means high complexity and coupling.
- Cohesion and coupling metrics rate how strongly a module is self-contained and how much it depends on others; the aim is high cohesion and low coupling.
- Size metrics count lines of code (LOC) or the number of modules; a larger module is harder to understand and test.
- Cyclomatic complexity is the number of independent paths in a module: $V(G) = E - N + 2$, where $E$ is edges and $N$ nodes of the flow graph; a value above about 10 marks a module hard to test.
- Object-oriented design (OOD) models the system as classes with data and operations; the steps are to identify objects and classes, define their attributes and operations, define relations (inheritance, association), and refine the class design.
- The Chidamber and Kemerer (CK) suite measures OO design: WMC (weighted methods per class), DIT (depth of inheritance tree), NOC (number of children), CBO (coupling between objects), RFC (response for a class) and LCOM (lack of cohesion in methods).
- High DIT, CBO or WMC means a complex, error-prone class; high LCOM means the class should be split.
Example. A flow graph with $E = 9$ edges and $N = 7$ nodes gives $V(G) = 9 - 7 + 2 = 4$, so four independent paths and at least four test cases.
Answer frame. Open with the definition and purpose; list points 2-5 as the general metrics; for the OO question first describe OOD in point 6, then the CK metrics in 7-8; close with "metrics point out the modules to redesign, improving maintainability".
Asked: [7 marks] (Jun 2022, Nov 2023, Jun 2025) How is object oriented design used in the development of software? What are the different metrics used for it? What is a design metric? Explain its importance. Asked: [7 marks] (Jun 2025) What are the key design metrics used to evaluate software design quality?
Last-minute revision
- Software design converts the SRS into data, architectural, interface and component-level design.
- Design strategies: function-oriented (top-down), bottom-up, object-oriented, data-driven.
- Goal of good design: high cohesion, low coupling.
- Cohesion best to worst: functional, sequential, communicational, procedural, temporal, logical, coincidental.
- Coupling best to worst: data, stamp, control, external, common, content.
- Mandel's golden rules: place the user in control, reduce memory load, make the interface consistent.
- Architecture styles: layered, client-server, pipe-filter, repository, MVC, microservices; 4+1 views: logical, process, development, physical plus scenarios.
- SA gives DFD, data dictionary and ERD; SD gives the structure chart.
- Cyclomatic complexity $V(G) = E - N + 2$.
- CK metrics: WMC, DIT, NOC, CBO, RFC, LCOM.
Memory hooks
- Cohesion FSCPTLC: "Fine Students Can Play Table-tennis Like Champions".
- Coupling DSCECC: "Data Stamps Control Every Common Content", best first.
- CK metrics: "WD NCR L" (WMC, DIT, NOC, CBO, RFC, LCOM).
- MVC: Model holds data, View shows, Controller listens.
- Golden rules: Control, Memory, Consistency (CMC).
Coverage checklist
- The Software Design Process: Dec 2020 design strategies, Jun 2026 design process and concepts.
- Design Concepts and Principles: design concepts, modular system with cohesion and coupling, four design principles, Dec 2020 short notes (modularization, coupling cohesion, use case modeling).
- Software Modeling andUML: software modeling and views, system modeling with UML.
- Architectural Design: architectural and procedural design, architectural design with example.
- Architectural Views and Styles: architecture styles and patterns, architectural views and styles, pattern based design.
- User Interface Design: golden rules (May 2019, Jun 2024 twice), interface analysis and design model.
- Function-oriented Design: function oriented design strategies, function-oriented design in detail.
- SA/SD Component Based Design: SA and SD with component based design, SA/SD approach.
- Design Metrics: OOD and its metrics, design metrics and their importance, key design metrics.