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

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

How unit 4 is examined

This unit covers how an architecture is designed and evaluated; ATAM, ARID and ADD carry the marks, CBAM is medium, and the rest is short.

Requirements for architecture and the life-cycle view

<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. The life-cycle view treats architecture as an activity that runs through every development phase, driven by architecturally significant requirements and checked by analysis methods.

Key points.

  1. Requirements come first: functional needs, quality attributes and constraints decide the architecture, and the quality attributes matter most.
  2. Design follows: architecture is created from the drivers, for example with ADD, and documented.
  3. Analysis follows design: ATAM, CBAM and ARID evaluate the architecture before it is built, when errors are cheapest to fix.
  4. Implementation, testing and maintenance must conform to the architecture, and feedback from each phase refines it iteratively.
  5. Architectural design decisions fall into seven categories: allocation of responsibilities, coordination model, data model, management of resources, mapping among architectural elements, binding time, and choice of technology. Kruchten's classes are existence, ban, property and executive decisions.

<mark>The life-cycle view links architecture to requirements, design, implementation, testing and maintenance, with feedback refining it at every stage.</mark>

Asked: [7 marks] (Dec 2025) Explain the life-cycle view of architecture design. Asked: [7 marks] (Dec 2024) Describe seven categories of architectural design decisions.

Cost Benefit Analysis Method (CBAM)

<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. CBAM is an economic analysis that helps stakeholders choose among architectural strategies by comparing the benefit each gives against its cost, using ROI.

Steps.

Step 1: Collate scenarios and rank them by importance.
Step 2: Refine the top scenarios (best, worst, current, desired response).
Step 3: Prioritise scenarios by votes and give them weights.
Step 4: Assign utility to the response levels of each scenario.
Step 5: Develop architectural strategies and estimate the quality-attribute response of each.
Step 6: Determine each strategy's utility, that is its benefit.
Step 7: Estimate cost, then compute ROI = benefit / cost and choose the highest desirability.

Key points.

  1. Stakeholders supply scenarios, weights and utilities, so the decision reflects business value and not only technical taste.
  2. Benefit of a strategy is the utility gain it gives across all weighted scenarios.
  3. Cost includes development and integration effort.
  4. ROI (desirability) ranks strategies; uncertainty is handled by using ranges.
  5. Benefits: economic reasoning and prioritised spending.

Example. Scenario weights 0.6 and 0.4; strategy X gains 50 and 20 utility; cost 19.

$$\text{Benefit}=0.6(50)+0.4(20)=38,\qquad \text{ROI}=\frac{38}{19}$$

ROI = 2. Strategy Y with benefit 42 and cost 12 has ROI 3.5, so Y is chosen.

<mark>CBAM chooses the architectural strategy with the highest ROI, benefit divided by cost, using stakeholder-weighted utility of scenarios.</mark>

Answer frame. Open with the definition and purpose; list the steps; show the ROI example; close with benefits.

Asked: [7 marks] (Dec 2020, Nov 2022) Explain the Cost Benefit Analysis Method (CBAM) for architecture-based economic analysis; what are its benefits?

Architecture Tradeoff Analysis Method (ATAM)

<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. ATAM is a scenario-based method that evaluates an architecture against its quality-attribute goals, and shows how the attributes trade off against each other.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-01" viewBox="0 0 492.8 80" width="492.8" height="80" role="img" aria-label="ATAM phases: Presentation, Analysis, Testing, Reporting (step 9)"><style>#dsfig-u4-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-01 .t{fill:#16181D;font-weight:500}#dsfig-u4-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-01 .dot{fill:#16181D}#dsfig-u4-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-01 .ah{fill:#454C5A}#dsfig-u4-01 .ah.hi{fill:#2340B8}#dsfig-u4-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-01 .e{stroke:#B1B7C3}html.dark #dsfig-u4-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-01 .t{fill:#E6E8ED}html.dark #dsfig-u4-01 .t.inv{fill:#0F1115}html.dark #dsfig-u4-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-01 .dot{fill:#E6E8ED}html.dark #dsfig-u4-01 .ann{fill:#8FA3FF}html.dark #dsfig-u4-01 .lbl{fill:#858D9C}html.dark #dsfig-u4-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-01 .ah{fill:#B1B7C3}html.dark #dsfig-u4-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-01 .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><path class="e" d="M59,40 L156.6,40" marker-end="url(#ah13)"/><path class="e" d="M196.6,40 L294.2,40" marker-end="url(#ah13)"/><path class="e" d="M334.2,40 L431.8,40" marker-end="url(#ah13)"/><g class="wl"><rect x="92" y="31" width="33.6" height="18" rx="9"/><text class="t" x="108.8" y="40" dy=".35em" text-anchor="middle">1-3</text></g><g class="wl"><rect x="229.6" y="31" width="33.6" height="18" rx="9"/><text class="t" x="246.4" y="40" dy=".35em" text-anchor="middle">4-6</text></g><g class="wl"><rect x="367.2" y="31" width="33.6" height="18" rx="9"/><text class="t" x="384" y="40" dy=".35em" text-anchor="middle">7-8</text></g><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">P</text><circle class="n" cx="177.6" cy="40" r="18"/><text class="t" x="177.6" y="40" dy=".35em" text-anchor="middle">A</text><circle class="n" cx="315.2" cy="40" r="18"/><text class="t" x="315.2" y="40" dy=".35em" text-anchor="middle">T</text><circle class="n hi" cx="452.8" cy="40" r="18"/><text class="t" x="452.8" y="40" dy=".35em" text-anchor="middle">R</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">ATAM phases: Presentation, Analysis, Testing, Reporting (step 9)</figcaption></figure>

Nine steps in four phases.

  1. Presentation: present ATAM, present business drivers, present the architecture.
  2. Analysis: identify architectural approaches, generate the quality-attribute utility tree, analyse the approaches.
  3. Testing: brainstorm and prioritise scenarios, then analyse the approaches again against them.
  4. Reporting: present the results.

Key points.

  1. The utility tree has quality goals at the top, attributes such as performance and modifiability below, and prioritised scenarios as leaves.
  2. Scenarios probe the architecture; the leaves are rated by importance and difficulty.
  3. A sensitivity point is a decision that strongly affects one attribute.
  4. A trade-off point is a decision that affects several attributes in opposite ways, for example encryption raises security but slows performance.
  5. A risk is a decision that may cause trouble later; a non-risk is a good decision.
  6. Outputs are the approaches, utility tree, scenarios, risks, sensitivity points and trade-off points.
  7. Participants are the evaluation team, the architect, and stakeholders.

Quality attribute scenario (six parts). Source: the entity generating the stimulus. Stimulus: the event arriving. Artifact: the part of the system stimulated. Environment: the conditions when it happens. Response: what the system does. Response measure: how the response is tested.

Example. Source: a user; stimulus: 1000 requests per second; artifact: web server; environment: normal load; response: serves all requests; measure: within 2 seconds.

Analysis methods compared.

Method Purpose Style
SAAM Modifiability, scenario-based Earlier, single attribute
ATAM Many attributes and trade-offs Full, nine steps
ARID Suitability of a partial design Reviewers use the design

<mark>ATAM evaluates an architecture against quality-attribute scenarios to expose risks, sensitivity points and trade-off points.</mark>

Answer frame. Open with the definition; draw the phases figure; list the nine steps; explain utility tree, sensitivity, trade-off and risk; close with the outputs. For the scenario question give the six parts with one example; for the analysis-methods question add the table.

Asked: [7 marks] (Dec 2020, Nov 2022, Nov 2023, Jun 2025) Explain ATAM and its phases; write the steps to analyse quality with ATAM; explain ATAM with an example. Asked: [7 marks] (Nov 2023) What are the six characteristics of a scenario for quality attributes specification? Asked: [7 marks] (Dec 2024) Explain software architecture analysis methods in details.

Active Reviews for Intermediate Design (ARID)

<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. ARID is a stakeholder-centric, scenario-based review of a partial, intermediate design, combining Active Design Reviews with ATAM ideas.

Steps.

Step 1: Identify the reviewers.
Step 2: Prepare the design presentation.
Step 3: Prepare seed scenarios.
Step 4: Prepare for the review meeting.
Step 5: Present ARID.
Step 6: Present the design.
Step 7: Brainstorm and prioritise scenarios.
Step 8: Perform the review, with reviewers using the design on the scenarios.
Step 9: Present the conclusions.

Key points.

  1. Steps 1-4 form the pre-meeting phase and steps 5-9 the review meeting, so it is done in two phases.
  2. Reviewers are the software engineers who will use the design, not only managers.
  3. Reviewers actively use the design to solve scenarios, so they find flaws in usability, not just comment.
  4. It reviews a design that is not yet finished, giving early feedback while change is cheap.
  5. Characteristics: stakeholder-centric, scenario-based, intermediate stage.
  6. Benefits: early error detection and a suitable design. Limitation: it does not analyse quality-attribute trade-offs.
Aspect ARID ATAM
Design stage Partial, intermediate Complete architecture
Focus Suitability for use Quality trade-offs
Reviewers Developers who will use it Architects and stakeholders
Output Issues found in the design Risks, sensitivity, trade-offs
Effort Lighter Heavier

<mark>ARID reviews a partial design early by having its intended users apply it to prioritised scenarios.</mark>

Answer frame. Open with the definition; list the nine steps in two phases; add the characteristics; close with benefits over ATAM using the table.

Asked: [7 marks] (Nov 2022) Describe ARID; what are its benefits over ATAM? Asked: [7 marks] (Nov 2023, Dec 2024) Write a note on Active Reviews for Intermediate Design; define ARID with its characteristics. Asked: [7 marks] (Dec 2025) Explain ARID and ADD methods.

Attribute Driven Design method (ADD)

<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. ADD is an iterative, recursive design method in which the quality-attribute requirements drive the decomposition of the architecture.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-02" viewBox="0 0 596 80" width="596" height="80" role="img" aria-label="ADD loop: Inputs, Choose element, Tactics, Instantiate, Verify"><style>#dsfig-u4-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-02 .t{fill:#16181D;font-weight:500}#dsfig-u4-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-02 .dot{fill:#16181D}#dsfig-u4-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-02 .ah{fill:#454C5A}#dsfig-u4-02 .ah.hi{fill:#2340B8}#dsfig-u4-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-02 .e{stroke:#B1B7C3}html.dark #dsfig-u4-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-02 .t{fill:#E6E8ED}html.dark #dsfig-u4-02 .t.inv{fill:#0F1115}html.dark #dsfig-u4-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-02 .dot{fill:#E6E8ED}html.dark #dsfig-u4-02 .ann{fill:#8FA3FF}html.dark #dsfig-u4-02 .lbl{fill:#858D9C}html.dark #dsfig-u4-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-02 .ah{fill:#B1B7C3}html.dark #dsfig-u4-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah14" 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="ahh14" 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 L148,40" marker-end="url(#ah14)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah14)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah14)"/><path class="e" d="M446,40 L535,40" marker-end="url(#ah14)"/><path class="e" d="M537,40 L190,40" marker-end="url(#ah14)"/><g class="wl"><rect x="331.8" y="31" width="61.5" height="18" rx="9"/><text class="t" x="362.5" y="40" dy=".35em" text-anchor="middle">iterate</text></g><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">In</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">Ch</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Ta</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">Ins</text><circle class="n" cx="556" cy="40" r="18"/><text class="t" x="556" y="40" dy=".35em" text-anchor="middle">Ver</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">ADD loop: Inputs, Choose element, Tactics, Instantiate, Verify</figcaption></figure>

Steps.

Step 1: Confirm there are enough requirements (drivers, constraints, quality attributes).
Step 2: Choose an element of the system to decompose.
Step 3: Identify the candidate architectural drivers.
Step 4: Choose a design concept (patterns and tactics) that satisfies the drivers.
Step 5: Instantiate elements and allocate responsibilities.
Step 6: Define interfaces of the instantiated elements.
Step 7: Verify and refine the requirements, then repeat for the next element.

Key points.

  1. Input is the functional requirements, quality attributes and constraints.
  2. Drivers are the few requirements that shape the architecture most, so design starts with them.
  3. Tactics and patterns are chosen because they achieve the quality attribute.
  4. Each iteration decomposes one element further and yields views.
  5. Output is an architecture sketch, refined until the design is detailed enough.

Example. For an online exam portal, the driver is availability of 99.9 percent. Choose redundancy as the tactic, instantiate two servers behind a load balancer, define their interface, then verify.

<mark>ADD decomposes the system iteratively, choosing patterns and tactics that satisfy the architectural drivers at each step.</mark>

Answer frame. Open with the definition; draw the loop; develop the seven steps; give the exam portal example; close with the output.

Asked: [7 marks] (Nov 2022, Dec 2024, Jun 2025) Explain ADD; describe its steps; illustrate ADD with a case study; short note on ADD.

Architecture reuse

<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 reuse is applying an existing proven architecture, such as a product-line architecture, across several systems.

Key points.

  1. A product-line architecture is shared by a family of related products.
  2. It cuts cost and time, and raises quality since the design is proven.
  3. Reuse needs the variation points to be planned.
  4. Documentation of the architecture makes it reusable.

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

Definition. A domain-specific software architecture (DSSA) is a reusable architecture, with components and a reference model, made for one application domain.

Key points.

  1. Advantages: reuse of components, higher productivity and domain expertise built in.
  2. Quality and predictability are better since the domain is well understood.
  3. Challenges: limited scope, so the architecture cannot be used outside its domain.
  4. The domain evolves, so the architecture needs costly updates, and the initial cost of building it is high.
  5. Examples: avionics, automotive (AUTOSAR), telecom.

<mark>A DSSA gives reuse and productivity within one domain, at the price of limited scope and high initial cost.</mark>

Asked: [7 marks] (Jun 2025) Evaluate the advantages and challenges of domain-specific software architectures.

Last-minute revision

  • ATAM has 9 steps in 4 phases: presentation, analysis, testing, reporting.
  • ATAM outputs: risks, sensitivity points, trade-off points.
  • Scenario parts: source, stimulus, artifact, environment, response, response measure.
  • CBAM: ROI = benefit / cost.
  • ARID = Active Design Review + ATAM ideas, 9 steps, reviewers use the design.
  • ADD is driven by quality-attribute drivers; it iterates through elements.
  • Seven decision categories: responsibilities, coordination, data model, resources, mapping, binding time, technology.
  • DSSA: reuse and productivity against limited scope.

Memory hooks

  • ATAM: "Present, Probe, Prioritise, Publish" for its four phases.
  • ARID: "A Reviewer Is a Developer".
  • Scenario: "SSA-ERR": source, stimulus, artifact, environment, response, response measure.

Coverage checklist

  • requirements for architecture and the life-cycle view of architecture design and analysis methods: life-cycle view; seven decision categories.
  • architecture-based economic analysis: Cost Benefit Analysis Method (CBAM): CBAM.
  • Architecture Tradeoff Analysis Method (ATAM): ATAM, scenario parts, analysis methods.
  • Active Reviews for Intermediate Design (ARID): note, benefits over ATAM, ARID and ADD.
  • Attribute Driven Design method (ADD): steps and case study.
  • architecture reuse: unasked.
  • Domain-specific Software architecture: advantages and challenges.
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