Skip to content
CS-701 · Software Architectures/Quick Revision Short Notes

Software Architectures (CS-701) - Unit 1 Short Notes

How unit 1 is examined

Covers SDLC, quality models, process models and architecture basics; the marks sit in software development models, introduction to software architecture, McCall's quality model, the architecture business cycle, components and connectors, and patterns (MVC).

Overview of software development methodology

<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">Not asked since 2022</span>

Definition. A software development methodology is a structured set of activities, roles and rules for building software, organised as the Software Development Life Cycle (SDLC).

Key points.

  1. The SDLC phases are requirements, design, implementation, testing, deployment and maintenance.
  2. A methodology fixes the order, length and repetition of these phases, for example a single pass (waterfall) or repeated loops (agile).
  3. It reduces risk, makes cost and schedule predictable, and gives the team a common process.
  4. The right choice depends on how stable the requirements are, the project size and the risk.

Software quality model

<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>A software quality model is a framework that breaks the vague idea of "quality" into measurable factors, criteria and metrics so that software can be specified, evaluated and compared.</mark>

Key points.

  1. McCall's model (1977) groups 11 quality factors under three perspectives: product operation, product revision and product transition.
  2. Product operation covers correctness, reliability, efficiency, integrity and usability, that is, how well the software runs.
  3. Product revision covers maintainability, flexibility and testability, that is, how easily it is changed.
  4. Product transition covers portability, reusability and interoperability, that is, how easily it adapts to a new environment.
  5. Each factor is measured through lower-level criteria (for example simplicity, modularity, traceability, self-descriptiveness), which in turn have metrics.
  6. Other models are Boehm's model and ISO 9126 (functionality, reliability, usability, efficiency, maintainability, portability), later ISO 25010.
  7. Importance: quality models give a common vocabulary, allow evaluation and comparison, expose trade-offs (for example efficiency against portability) and keep stakeholders satisfied.
  8. Limitation: McCall's model has too many factors and criteria with no proven measurement for some, and it ignores the functional requirements' business value.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-01" viewBox="0 0 1410 194" width="1410" height="194" role="img" aria-label="McCall's 11 quality factors under three perspectives"><style>#dsfig-u1-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-01 .t{fill:#16181D;font-weight:500}#dsfig-u1-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-01 .dot{fill:#16181D}#dsfig-u1-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-01 .ah{fill:#454C5A}#dsfig-u1-01 .ah.hi{fill:#2340B8}#dsfig-u1-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-01 .e{stroke:#B1B7C3}html.dark #dsfig-u1-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-01 .t{fill:#E6E8ED}html.dark #dsfig-u1-01 .t.inv{fill:#0F1115}html.dark #dsfig-u1-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-01 .dot{fill:#E6E8ED}html.dark #dsfig-u1-01 .ann{fill:#8FA3FF}html.dark #dsfig-u1-01 .lbl{fill:#858D9C}html.dark #dsfig-u1-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-01 .ah{fill:#B1B7C3}html.dark #dsfig-u1-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah1" 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="ahh1" 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="731.8" y1="37" x2="295.8" y2="101"/><line class="e" x1="731.8" y1="37" x2="784.3" y2="101"/><line class="e" x1="731.8" y1="37" x2="1167.8" y2="101"/><line class="e" x1="295.8" y1="101" x2="67" y2="165"/><line class="e" x1="295.8" y1="101" x2="189" y2="165"/><line class="e" x1="295.8" y1="101" x2="307" y2="165"/><line class="e" x1="295.8" y1="101" x2="417.5" y2="165"/><line class="e" x1="295.8" y1="101" x2="524.5" y2="165"/><line class="e" x1="784.3" y1="101" x2="654.5" y2="165"/><line class="e" x1="784.3" y1="101" x2="792" y2="165"/><line class="e" x1="784.3" y1="101" x2="914" y2="165"/><line class="e" x1="1167.8" y1="101" x2="1036" y2="165"/><line class="e" x1="1167.8" y1="101" x2="1158" y2="165"/><line class="e" x1="1167.8" y1="101" x2="1299.5" y2="165"/><rect class="n" x="666.8" y="22" width="130" height="30" rx="8"/><text class="t" x="731.8" y="37" dy=".35em" text-anchor="middle">McCall's model</text><rect class="n" x="219.3" y="86" width="153" height="30" rx="8"/><text class="t" x="295.8" y="101" dy=".35em" text-anchor="middle">Product operation</text><rect class="n" x="14" y="150" width="106" height="30" rx="8"/><text class="t" x="67" y="165" dy=".35em" text-anchor="middle">Correctness</text><rect class="n" x="136" y="150" width="106" height="30" rx="8"/><text class="t" x="189" y="165" dy=".35em" text-anchor="middle">Reliability</text><rect class="n" x="258" y="150" width="98" height="30" rx="8"/><text class="t" x="307" y="165" dy=".35em" text-anchor="middle">Efficiency</text><rect class="n" x="372" y="150" width="91" height="30" rx="8"/><text class="t" x="417.5" y="165" dy=".35em" text-anchor="middle">Integrity</text><rect class="n" x="479" y="150" width="91" height="30" rx="8"/><text class="t" x="524.5" y="165" dy=".35em" text-anchor="middle">Usability</text><rect class="n" x="711.8" y="86" width="145" height="30" rx="8"/><text class="t" x="784.3" y="101" dy=".35em" text-anchor="middle">Product revision</text><rect class="n" x="586" y="150" width="137" height="30" rx="8"/><text class="t" x="654.5" y="165" dy=".35em" text-anchor="middle">Maintainability</text><rect class="n" x="739" y="150" width="106" height="30" rx="8"/><text class="t" x="792" y="165" dy=".35em" text-anchor="middle">Flexibility</text><rect class="n" x="861" y="150" width="106" height="30" rx="8"/><text class="t" x="914" y="165" dy=".35em" text-anchor="middle">Testability</text><rect class="n" x="1087.3" y="86" width="161" height="30" rx="8"/><text class="t" x="1167.8" y="101" dy=".35em" text-anchor="middle">Product transition</text><rect class="n" x="983" y="150" width="106" height="30" rx="8"/><text class="t" x="1036" y="165" dy=".35em" text-anchor="middle">Portability</text><rect class="n" x="1105" y="150" width="106" height="30" rx="8"/><text class="t" x="1158" y="165" dy=".35em" text-anchor="middle">Reusability</text><rect class="n" x="1227" y="150" width="145" height="30" rx="8"/><text class="t" x="1299.5" y="165" dy=".35em" text-anchor="middle">Interoperability</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">McCall's 11 quality factors under three perspectives</figcaption></figure>

Deciding the quality of an architecture. Fix the quality attributes from stakeholder requirements (performance, security, modifiability, availability), then judge the architecture by reviews, scenario-based evaluation (SAAM, ATAM), metrics such as coupling and cohesion, and prototypes; stakeholders rank the scenarios and the result is a list of risks and trade-offs.

Answer frame. Open with the definition; draw the McCall tree; then develop points 1-5 with the factors named; close with importance and one limitation. For the architecture-quality question, use the last paragraph in the order attributes, evaluation methods, stakeholders, findings.

Asked: [7 marks] (Nov 2023) What is Software Quality Model? Explain Mc Call's Model in detail. Asked: [7 marks] (Nov 2023) How can we decide the quality of software architecture? Explain. Asked: [7 marks] (Dec 2025) What is a software quality model? Explain its importance in software development.

Different models of software development and their issues

<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>A software process model is an abstract description of the order in which the SDLC activities are carried out, and each model trades off risk, cost, flexibility and speed.</mark>

Key points.

  1. Waterfall runs requirements, design, code, test and maintenance strictly in sequence with no going back; it is simple and well documented, but rigid, and a change of requirement is costly and the customer sees the product only at the end.
  2. Iterative model builds a rough full system first and then refines it in repeated cycles; it gives early feedback, but needs good planning and can drift in scope.
  3. Incremental model delivers the system in working parts, each adding functions; early delivery is possible, but the architecture must allow later increments and integration can be hard.
  4. Prototype model builds a quick throwaway version to clarify requirements; it reduces misunderstanding, but users may mistake the prototype for the product and effort may be wasted.
  5. Spiral model repeats four quadrants with risk analysis in every loop; it handles risk well but is costly, complex and needs risk experts.
  6. RAD (Rapid Application Development) uses prototyping, reusable components and heavy user involvement within a 60-90 day time-box; phases are business modelling, data modelling, process modelling, application generation and testing. It is fast and flexible, but needs skilled people, does not scale to large systems and needs a modular design.
  7. Agile (Scrum, XP) delivers in short sprints with continuous customer feedback; it welcomes change, but has weak documentation, needs an involved customer and is hard to scale.
  8. RUP is use-case driven with phases inception, elaboration, construction and transition; it is architecture-centred but heavy in process and management overhead.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-02" viewBox="0 0 345 338" width="345" height="338" role="img" aria-label="Spiral model, one loop: Obj = determine objectives, Risk = identify and resolve risks, Dev = develop and test, Plan = review and plan next loop; radius equals cost"><style>#dsfig-u1-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-02 .t{fill:#16181D;font-weight:500}#dsfig-u1-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-02 .dot{fill:#16181D}#dsfig-u1-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-02 .ah{fill:#454C5A}#dsfig-u1-02 .ah.hi{fill:#2340B8}#dsfig-u1-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-02 .e{stroke:#B1B7C3}html.dark #dsfig-u1-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-02 .t{fill:#E6E8ED}html.dark #dsfig-u1-02 .t.inv{fill:#0F1115}html.dark #dsfig-u1-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-02 .dot{fill:#E6E8ED}html.dark #dsfig-u1-02 .ann{fill:#8FA3FF}html.dark #dsfig-u1-02 .lbl{fill:#858D9C}html.dark #dsfig-u1-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-02 .ah{fill:#B1B7C3}html.dark #dsfig-u1-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah2" 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="ahh2" 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="M59,40 L270,40" marker-end="url(#ah2)"/><path class="e" d="M298,66 L298,277" marker-end="url(#ah2)"/><path class="e" d="M279,298 L68,298" marker-end="url(#ah2)"/><path class="e" d="M40,272 L40,61" marker-end="url(#ah2)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Obj</text><rect class="n" x="273" y="25" width="50" height="30" rx="15"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Risk</text><circle class="n" cx="298" cy="298" r="18"/><text class="t" x="298" y="298" dy=".35em" text-anchor="middle">Dev</text><rect class="n" x="15" y="283" width="50" height="30" rx="15"/><text class="t" x="40" y="298" dy=".35em" text-anchor="middle">Plan</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Spiral model, one loop: Obj = determine objectives, Risk = identify and resolve risks, Dev = develop and test, Plan = review and plan next loop; radius equals cost</figcaption></figure>

Spiral, advantages. Risk handling, iterative refinement, customer feedback each loop, suitable for large critical projects. Spiral, disadvantages. Costly, complex, depends on risk-analysis skill, hard to manage and unsuitable for small projects.

RAD. Advantages: speed, flexibility, user feedback, reuse. Disadvantages: scalability, resource needs, unsuited to large or high-risk systems.

Issues in general. Rigidity (waterfall), risk (waterfall, prototype), cost (spiral, RUP), requirement change (waterfall against agile) and management overhead (spiral, RUP).

Answer frame. For the general question, open by defining a process model, then give one line per model 1-8 with its issue, and close with the rule that the choice depends on requirement stability and risk. For the spiral, draw the loop, explain the four quadrants, then list advantages and disadvantages. For RAD, define it, give the phases, then advantages and disadvantages.

Pitfall: Writing only the working of each model; the question asks for the issues too.

Asked: [7 marks] (Dec 2020, Dec 2024, Jun 2025) Discuss different models of software development and write down their issues. Asked: [7 marks] (Nov 2022) Draw and explain the spiral model of software development. Enlist the advantages and disadvantages of spiral model. Asked: [7 marks] (Nov 2023) What is Rapid Application Development Methodology? Explain its advantages and disadvantages.

Introduction to software architecture

<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>The software architecture of a system is the set of structures needed to reason about it, comprising software elements, the relations among them and the properties of both.</mark>

Key points.

  1. Architecture is the high-level structure: components (computation units), connectors (interactions) and constraints on them.
  2. It is the earliest set of design decisions, because it is fixed before detailed design and is the hardest and costliest to change later.
  3. These early decisions fix the structure (layers, tiers), the quality attributes (performance, security, modifiability), the platform and technology, and the build-versus-buy choice.
  4. Architecture constrains the implementation, so developers must obey it, and it decides how the work is divided among teams.
  5. It is the vehicle of communication among stakeholders, who use it to negotiate trade-offs.
  6. It enables reuse of components and whole systems, and it shapes how the system evolves.
  7. Architecture allows early analysis: performance and modifiability can be predicted before any code exists.

Example. Choosing a three-layer client-server web system is an early decision. The layering makes the UI easy to modify because the database is hidden behind the business layer (modifiability), the separate server tier can be replicated for load (performance), and buying a ready database instead of building one is a build-versus-buy decision. Changing any of these after coding means rewriting most of the system.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-03" viewBox="0 0 596 80" width="596" height="80" role="img" aria-label="Layered client-server example: Cl = client browser, Web = presentation tier, Bus = business logic tier, DB = database tier"><style>#dsfig-u1-03 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-03 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-03 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-03 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-03 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-03 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-03 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-03 .t{fill:#16181D;font-weight:500}#dsfig-u1-03 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-03 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-03 .dot{fill:#16181D}#dsfig-u1-03 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-03 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-03 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-03 .ah{fill:#454C5A}#dsfig-u1-03 .ah.hi{fill:#2340B8}#dsfig-u1-03 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-03 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-03 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-03 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-03 .e{stroke:#B1B7C3}html.dark #dsfig-u1-03 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-03 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-03 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-03 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-03 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-03 .t{fill:#E6E8ED}html.dark #dsfig-u1-03 .t.inv{fill:#0F1115}html.dark #dsfig-u1-03 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-03 .dot{fill:#E6E8ED}html.dark #dsfig-u1-03 .ann{fill:#8FA3FF}html.dark #dsfig-u1-03 .lbl{fill:#858D9C}html.dark #dsfig-u1-03 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-03 .ah{fill:#B1B7C3}html.dark #dsfig-u1-03 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-03 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-03 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-03 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah3" 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="ahh3" 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="M59,40 L191,40" marker-end="url(#ah3)"/><path class="e" d="M231,40 L363,40" marker-end="url(#ah3)"/><path class="e" d="M403,40 L535,40" marker-end="url(#ah3)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Cl</text><circle class="n" cx="212" cy="40" r="18"/><text class="t" x="212" y="40" dy=".35em" text-anchor="middle">Web</text><circle class="n" cx="384" cy="40" r="18"/><text class="t" x="384" y="40" dy=".35em" text-anchor="middle">Bus</text><circle class="n" cx="556" cy="40" r="18"/><text class="t" x="556" y="40" dy=".35em" text-anchor="middle">DB</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Layered client-server example: Cl = client browser, Web = presentation tier, Bus = business logic tier, DB = database tier</figcaption></figure>

Answer frame. Open with the definition (elements, relations, properties); draw the layered example; then develop points 2, 3, 4, 5, 6 with the example's decisions; close with the sentence that architecture is hard to change, so it is the earliest and most important design decision. For 14 marks, expand each of points 3-6 into two sentences.

Asked: [14 marks] (Dec 2020, Nov 2023) What is Software Architecture? Discuss with an example how software architecture represents a System's earliest set of design decisions?

Evolution of software architecture

<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">Not asked since 2022</span>

Definition. Architecture evolution is the shift in how software structure is designed, from unstructured code to formal, pattern-based, distributed and cloud designs.

Key points.

  1. The stages ran roughly from unstructured programs, to structured and modular design, to object-oriented design with design patterns.
  2. Then came component-based and layered client-server systems, followed by service-oriented architecture.
  3. Recent styles are microservices, event-driven and cloud-native architectures.
  4. Each step was driven by growing size and complexity, the need for reuse, distribution and easier change.

Software components and connectors

<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>A component is a unit of computation or data storage with a well-defined interface, and a connector is the mechanism that mediates interaction between components.</mark>

Key points.

  1. A component encapsulates its implementation and exposes its services only through interfaces (ports), so it can be replaced or reused.
  2. Component examples are a client, server, filter, database, object or module.
  3. A connector defines the communication rules, that is, the protocol, between the components it joins; it may carry data, control or both.
  4. Connector types are procedure call, pipe, event bus, shared data or repository, and message passing (client-server request-reply).
  5. Connectors are first-class design elements: they decide coupling, performance and reliability as much as the components.
  6. An architecture is then described as a configuration of components joined by connectors under constraints.

Example. In a pipes-and-filters compiler, the lexer and parser are components (filters) and the pipes between them are connectors.

Answer frame. Open by defining both terms; draw a small box-and-arrow figure of two components joined by a connector; then develop points 1-5; close with the configuration sentence (point 6).

Asked: [7 marks] (Nov 2022, Dec 2025) Write a short note on software components and connectors. What are software components and connectors? Give examples.

Common software architecture frameworks

<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">Low weight</span>

Definition. A software architecture framework is a set of conventions, viewpoints and reusable structure that guides how architectures are described and built (for example Zachman, TOGAF, 4+1 views).

Key points.

  1. It fixes the views (logical, process, development, physical) so stakeholders see the system from their own concern.
  2. The client-server pattern has clients send requests to a server that replies; many clients share one server.
  3. The master-slave pattern has a master divide work among slaves and combine their results, with replication for reliability.
Point Client-server Master-slave
Control Server serves, client initiates Master controls, slaves obey
Communication Request-reply Master commands, slave returns result
Scalability Add clients, scale the server Add slaves, master is a bottleneck
Failure Server is a single point of failure Master failure stops work; slaves replicate data
Use Web, email, databases Database replication, parallel computing

Asked: [7 marks] (Nov 2022) What is a software architecture framework? Write the difference between client-server and master-slave software architecture patterns.

Architecture business cycle

<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>The architecture business cycle (ABC) is the feedback loop in which the organisation's business goals, stakeholders and the architect's experience shape the architecture, the architecture shapes the system, and the system in turn changes the organisation and the architect's experience.</mark>

Key points.

  1. Stakeholders (customers, users, managers) bring requirements and expectations that influence the architecture.
  2. The developing organisation adds its structure, business goals, budget, schedule and existing assets.
  3. The architect brings technical background and experience, which shape the choices made.
  4. These three influences produce the architecture, and the architecture is used to build the system.
  5. The finished system gives feedback: it changes customer requirements, adds to the organisation's assets and increases the architect's experience.
  6. The cycle repeats with each new system, so architecture is a business decision as well as a technical one.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-04" viewBox="0 0 596 424" width="596" height="424" role="img" aria-label="ABC: Stk = stakeholders and requirements, Org = developing organisation, Arc = architect's experience, SA = architecture, Sys = system; the arrows from Sys are the feedback"><style>#dsfig-u1-04 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-04 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-04 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-04 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-04 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-04 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-04 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-04 .t{fill:#16181D;font-weight:500}#dsfig-u1-04 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-04 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-04 .dot{fill:#16181D}#dsfig-u1-04 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-04 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-04 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-04 .ah{fill:#454C5A}#dsfig-u1-04 .ah.hi{fill:#2340B8}#dsfig-u1-04 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-04 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-04 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-04 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-04 .e{stroke:#B1B7C3}html.dark #dsfig-u1-04 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-04 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-04 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-04 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-04 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-04 .t{fill:#E6E8ED}html.dark #dsfig-u1-04 .t.inv{fill:#0F1115}html.dark #dsfig-u1-04 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-04 .dot{fill:#E6E8ED}html.dark #dsfig-u1-04 .ann{fill:#8FA3FF}html.dark #dsfig-u1-04 .lbl{fill:#858D9C}html.dark #dsfig-u1-04 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-04 .ah{fill:#B1B7C3}html.dark #dsfig-u1-04 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-04 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-04 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-04 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah4" 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="ahh4" 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="M55.8,50.5 L280.5,200.4" marker-end="url(#ah4)"/><path class="e" d="M59,212 L277,212" marker-end="url(#ah4)"/><path class="e" d="M55.8,373.5 L280.5,223.6" marker-end="url(#ah4)"/><path class="e" d="M317,212 L535,212" marker-end="url(#ah4)"/><path class="e" d="M538,206 L59.9,46.6" marker-end="url(#ah4)"/><path class="e" d="M537,212 L61,212" marker-end="url(#ah4)"/><path class="e" d="M538,218 L59.9,377.4" marker-end="url(#ah4)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Stk</text><circle class="n" cx="40" cy="212" r="18"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">Org</text><circle class="n" cx="40" cy="384" r="18"/><text class="t" x="40" y="384" dy=".35em" text-anchor="middle">Arc</text><circle class="n" cx="298" cy="212" r="18"/><text class="t" x="298" y="212" dy=".35em" text-anchor="middle">SA</text><circle class="n" cx="556" cy="212" r="18"/><text class="t" x="556" y="212" dy=".35em" text-anchor="middle">Sys</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">ABC: Stk = stakeholders and requirements, Org = developing organisation, Arc = architect's experience, SA = architecture, Sys = system; the arrows from Sys are the feedback</figcaption></figure>

Answer frame. Open with the definition; draw the ABC figure; then develop points 1-5 as the arrows; close with the point that the feedback makes the cycle repeat.

Asked: [7 marks] (Dec 2024, Jun 2025) Explain architectural business cycle in detail. Describe the software architecture business cycle with a suitable diagram.

Architectural patterns and reference model

<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 pattern is a reusable, proven solution to a recurring structural problem, while a reference model is a standard division of a whole problem domain into components and data flow.</mark>

Key points.

  1. Common patterns are layered, MVC, pipes-and-filters, client-server, broker and event-driven.
  2. Model-View-Controller (MVC) has the Model holding data and business logic, the View displaying it, and the Controller taking user input and updating the Model and View.
  3. The Controller sends the user's action to the Model; the Model notifies the View, which redraws.
  4. MVC characteristics are separation of concerns, reusability (several views on one model), testability of the model without a UI, and parallel team development.
  5. Applications of MVC are web frameworks (Django, Spring MVC) and GUI toolkits.
  6. A pattern is chosen by the quality attributes required (performance, modifiability, security) and the trade-offs it brings; patterns improve reuse and quality.
  7. A reference model (for example the OSI seven layers or the compiler pipeline) is a domain template; a reference architecture maps it onto software.
  8. An improved reference model can be proposed by keeping its layers but replacing the monolith with microservices, using event-driven messaging between them and an API gateway at the front; this improves scalability and independent deployment.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-05" viewBox="0 0 424 252" width="424" height="252" role="img" aria-label="MVC: U = user, C = controller, M = model, V = view"><style>#dsfig-u1-05 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-05 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-05 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-05 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-05 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-05 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-05 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-05 .t{fill:#16181D;font-weight:500}#dsfig-u1-05 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-05 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-05 .dot{fill:#16181D}#dsfig-u1-05 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-05 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-05 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-05 .ah{fill:#454C5A}#dsfig-u1-05 .ah.hi{fill:#2340B8}#dsfig-u1-05 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-05 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-05 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-05 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-05 .e{stroke:#B1B7C3}html.dark #dsfig-u1-05 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-05 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-05 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-05 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-05 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-05 .t{fill:#E6E8ED}html.dark #dsfig-u1-05 .t.inv{fill:#0F1115}html.dark #dsfig-u1-05 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-05 .dot{fill:#E6E8ED}html.dark #dsfig-u1-05 .ann{fill:#8FA3FF}html.dark #dsfig-u1-05 .lbl{fill:#858D9C}html.dark #dsfig-u1-05 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-05 .ah{fill:#B1B7C3}html.dark #dsfig-u1-05 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-05 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-05 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-05 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah5" 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="ahh5" 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 L193.2,49.4" marker-end="url(#ah5)"/><path class="e" d="M229,48.5 L365.2,116.6" marker-end="url(#ah5)"/><path class="e" d="M367,134.5 L230.8,202.6" marker-end="url(#ah5)"/><path class="e" d="M195,203.5 L58.8,135.4" marker-end="url(#ah5)"/><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">U</text><circle class="n" cx="212" cy="40" r="18"/><text class="t" x="212" y="40" dy=".35em" text-anchor="middle">C</text><circle class="n" cx="384" cy="126" r="18"/><text class="t" x="384" y="126" dy=".35em" text-anchor="middle">M</text><circle class="n" cx="212" cy="212" r="18"/><text class="t" x="212" y="212" dy=".35em" text-anchor="middle">V</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">MVC: U = user, C = controller, M = model, V = view</figcaption></figure>

Answer frame. For MVC, define it, draw the figure, explain the three roles and then characteristics; close with advantages. For the short note, define patterns, list examples, then selection and benefits. For the improved reference model, state the model and its limitations, then the added patterns and the resulting benefits.

Asked: [7 marks] (Nov 2023) What is Model View Architecture? Explain its Characteristics in detail. Asked: [7 marks] (Nov 2023) Write short note on Architectural Patterns. Asked: [7 marks] (Jun 2025) Propose an improved version of a reference model by integrating new architectural patterns.

Last-minute revision

  • SDLC phases: requirements, design, implementation, testing, deployment, maintenance.
  • McCall: 11 factors in three groups, operation (5), revision (3), transition (3).
  • ISO 9126 has six characteristics: functionality, reliability, usability, efficiency, maintainability, portability.
  • Spiral quadrants: objectives, risk analysis, development and test, planning; the radius is cost.
  • Waterfall is rigid; spiral is risky to manage; agile welcomes change; RAD suits small modular systems.
  • Software architecture equals elements, relations and properties; it is the earliest and costliest-to-change decision.
  • A connector defines the interaction protocol between components (pipe, event bus, procedure call).
  • ABC: stakeholders, organisation and architect shape the architecture, which builds the system, which feeds back.
  • MVC: Model holds data, View displays, Controller handles input.
  • Client-server has the client initiating; master-slave has the master controlling.

Memory hooks

  • McCall's PRT: Product operation, Revision, Transition.
  • Spiral quadrants: "O-R-D-P", objectives, risk, develop, plan.
  • Architecture: "ERP", elements, relations, properties.
  • MVC: user talks to Controller, Controller to Model, Model to View.
  • ABC feedback: the system teaches the architect and the customer.

Coverage checklist

  • Overview of Software development methodology: SDLC phases and choice of methodology.
  • software quality model: Nov 2023 (McCall), Nov 2023 (architecture quality), Dec 2025 (importance).
  • different models of software development and their issues: Dec 2020, Dec 2024, Jun 2025 (all models); Nov 2022 (spiral); Nov 2023 (RAD).
  • Introduction to software architecture: Dec 2020, Nov 2023 (earliest design decisions, 14 marks).
  • evolution of software architecture: stages of evolution.
  • software components and connectors: Nov 2022, Dec 2025.
  • common software architecture frameworks: Nov 2022 (client-server against master-slave).
  • Architecture business cycle: Dec 2024, Jun 2025.
  • architectural patterns - reference model: Nov 2023 (MVC), Nov 2023 (patterns), Jun 2025 (improved reference model).
Go to where you left off?

Quick Add to Notes

Save questions, your own notes and screenshots into notes filed by unit. It takes a free account.

Create free account

Have an account? Log in