A memorable, exam-ready walkthrough of the "parts, connections, and qualities" that make a system work — condensed from Chapter 2 / Week 03 L01, plus ATAM, the 4+1 view model, design patterns, and real midterm questions.
Architecture is about communication: what parts exist, and how they fit together. It is not the code, the algorithms, or the data structures — those come later, in detailed design.
The high-level structure of a system, the discipline of creating it, and the documentation of it. It captures the stuff that's hard to change once built.
Development, algorithms, or data structures — those are detailed design, done after the architecture is set.
| Dimension | Meaning |
|---|---|
| Structure | What the parts are and how they're organized |
| Communication (behavior) | How parts interact / talk to each other |
| Nonfunctional requirements | Qualities the system must exhibit (speed, security, etc.) |
Same shopping-app example, two zoom levels:
| Software Architecture | Detailed Design | |
|---|---|---|
| Focus | Which components exist & how they connect | How each component works internally |
| Shows | Subsystems / major modules | Classes, methods, algorithms |
| Interaction | Component-to-component | Object-to-object / class-to-class |
| Product | Blueprint (high-level diagrams) | Class/sequence diagrams, code-level docs |
| Example | Frontend ↔ Backend ↔ Database ↔ Payment Gateway | ShoppingCart.checkout() calls Payment.processCreditCard() |
Same diagram types can appear in both — the difference is the zoom level: architecture = subsystems/actors; design = classes/methods/attributes.
Software architecture = the foundational design activity that translates requirements into design elements describing the major components, their structure, behavior, and provided quality — supporting detailed design and construction.
Architecture is not optional — it's where designing for quality begins. It's forward engineering (guides the build), not reverse engineering (analyzing after the fact). Skipping quality attributes here is a serious mistake.
Turns textual requirements into graphical design elements, so requirements can be traced through the lifecycle. This assumes requirements are well understood — so architects also need requirements-engineering skills.
No single diagram can show everything (usability, performance, deployment...). Different stakeholders need different diagrams — e.g. a Component Diagram for architects, Class/Sequence diagrams for developers.
It's not enough to say "Component B provides an algorithm." You must tag it with its quality: e.g. Performance = O(n²), Reusability = Low — so clients using it know its limits and can make informed choices.
Quality requirements trickle down into implementation — but architecture alone cannot guarantee quality. If a programmer skips the security requirements during coding, the final code misses them even though the architecture demanded them.
"Synchronicity" = how well the built system still reflects its original design. It's easy to drift on multi-year projects — hence the need for documented, enforced policies (even during maintenance, years later).
A stakeholder's concern = high-level info about desired system characteristics. Concerns are the driving force behind architectural decisions.
| Direct Stakeholders | Indirect Stakeholders |
|---|---|
| Directly use / operate the system | Don't use it directly, but are affected by it |
| Drive functional requirements | Drive non-functional / external requirements |
| End users, admins, developers, testers | Regulators, investors, marketing, managers |
Example: for a university app, students want an easy schedule/grades view, professors need grade upload tools, admins need course management + security. Each group must be consulted before design starts.
| Quality | In one line |
|---|---|
| Usability | How easy it is to learn / use |
| Modifiability | How easy it is to change for current/future needs |
| Security | Ability to protect information & itself |
| Performance | Getting work done within time/resource limits |
| Reliability | The system's failure rate |
| Portability | Ease of adapting to other hardware/software |
| Testability | Ease of verifying & validating functions |
| Availability | System uptime |
| Interoperability | Ability to work with other systems (e.g. Word ↔ Google Docs sharing .docx) |
NFR vs. Quality Tag: an NFR is a system-wide goal ("process 1000 orders/sec"); a quality tag assigns that goal to one specific component ("Order Service ≤ 100ms/order").
Authenticate users, limit exposure/access (need-to-know), detect intrusions.
Event logging — log data/operations so testers can trace what happened.
Localize changes (modularization, abstraction, encapsulation); reduce ripple effects (loose coupling).
Redundancy, task monitors, watchdog timers, heartbeats.
Increase computation efficiency, reduce overhead, introduce concurrency.
| Term | Definition | Example |
|---|---|---|
| Architectural View | A representation of the system for a specific stakeholder's perspective | Deployment view: servers, nodes, network |
| Architectural Style | A general template for organizing a family of systems (high-level shape) | Distributed systems |
| Architectural Pattern | A reusable solution to a recurring, more specific problem (guides detail inside a style) | Client–Server, Pipes & Filters |
Both styles and patterns save time by reusing years of documented experience — but architects must weigh their impact on customers, budget, schedule, and resources.
Because one diagram can't satisfy every stakeholder, Kruchten's 4+1 model gives each group its own view of the same architecture.
| View | Shows | Stakeholder | UML diagrams |
|---|---|---|---|
| Logical (structural) | Object model of the design | End-users, analysts, designers | Class, State, Object, Sequence, Communication |
| Process (behavioral) | Concurrency & synchronization / workflow | Integrators & developers | Activity |
| Development (implementation) | Static organization of software modules | Programmers, project managers | Component, Package |
| Physical (deployment) | Installation, configuration & deployment onto hardware | System engineers, operators, installers | Deployment |
| +1 Use-Case (scenarios) | Validates the design is complete & consistent | Stakeholders of all other views | Use-case |
⚠ Exam trap: a diagram of physical boxes/consoles connected to hardware (like servers) is a Physical/Deployment view, even though it visually resembles a component diagram — check whether it shows hardware/installation (Physical) or just software module organization (Development).
| Role | Responsibility |
|---|---|
| Team Leader | Sets up the evaluation, coordinates with the client, delivers the final report |
| Evaluation Leader | Runs the evaluation, facilitates scenario elicitation & prioritization |
| Scenario Scribe | Writes agreed-on scenario wording on the flipchart/whiteboard |
| Proceedings Scribe | Captures everything electronically: issues, resolutions, adopted scenarios |
| Questioner | Raises architecturally-interesting questions (their expertise area) |
| Phase | Activity | Duration |
|---|---|---|
| 0 | Partnership & prep: logistics, planning, team formation | A few weeks, informal |
| 1 | Evaluation: steps 1–6 | 1–2 days, then a 2–3 week hiatus |
| 2 | Evaluation: steps 7–9 | 2 days |
| 3 | Follow-up: report + process improvement | 1 week |
The tree ranks scenarios by (Importance, Difficulty) so the team spends limited evaluation time on what matters most, e.g. Availability → HW failure → "Redirect traffic in <3s" (H,H) — high importance, high risk, gets evaluated first.
Scenario: Detect & recover from HW failure of the main switch (Attribute: Availability).
Stimulus: A CPU fails, during normal operation → Response: 0.999999 availability of the switch.
Architecture: Primary CPU + Backup CPU (with watchdog) send a 1-sec heartbeat, both feed a Switch CPU. Backup CPU runs a different OS to avoid common-mode failure.
Risk noted: No backup data channel — could threaten the availability requirement even though the CPU failover itself is solid.
Patterns are grouped by what they do: Creational = how objects are made; Structural = how objects are composed; Behavioral = how objects communicate.
| Pattern | Intent |
|---|---|
| Abstract Factory | Create families of related objects without specifying concrete classes |
| Factory Method | Define an interface for creating an object, let subclasses decide which class |
| Builder | Separate construction of a complex object from its representation |
| Singleton | Ensure a class has only one instance with a global access point |
| Pattern | Intent |
|---|---|
| Adapter | Convert one interface into another that clients expect |
| Facade | Provide one unified, simple interface to a complex subsystem |
| Composite | Compose objects into tree structures for whole-part hierarchies, treated uniformly |
| Pattern | Intent |
|---|---|
| Iterator | Access elements of a collection sequentially without exposing its internals |
| Observer | One-to-many dependency — when one object changes, all dependents are notified |
Creational: Abstract Factory, Builder, Factory Method, Prototype, Singleton
Structural: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor
Exam tip — trade-offs: Adapter adds overhead (everything gets forwarded); Facade & Composite reduce client complexity and coupling; Singleton doesn't play well with multithreading.
A standard architecture document is structured so any stakeholder can find their view quickly:
Each view packet repeats the same skeleton: Primary Presentation → Element Catalog → Context Diagram → Variability → Background → Related packets — consistency makes large documents navigable.
Requirements rarely arrive complete — architecture is an iterative loop, not a straight line:
Three support pillars run underneath the whole loop: Resources (people, tools, hardware), Activities (tasks like design reviews), and Controls (rules for how/when/where activities happen — e.g. "reviews need 1 week's notice").
Q1 Modularization & its two strategies
Modularization = continuously decomposing the system until reaching fine-grained components ("what" should be done).
Abstraction = show only what's important, hide detail ("what parts are needed").
Encapsulation = hide data, expose only what's needed ("what info should be shown/hidden").
They work together: abstraction decides what parts matter; encapsulation decides what to reveal or hide about them.
Q2 Are these functional requirements valid?
"The software shall be secure and fast." → Invalid: doesn't say how secure or how fast — not measurable, not testable.
"The system shall maximize communication speed." → Invalid: no concrete target. One stakeholder might think 2 seconds is fine; another won't. Without a specified value, it can't be verified.
Q3 Key tasks in software architecture
Recall the 7-task list in Sheet 04 — common mix-up: "ethical/professional practice" is not one of them. The real tasks are about stakeholders, views, styles, org influence, components, evaluation, and synchronicity.
Q4 Consoles + LAN server diagram
1) This is a Physical (Deployment) view — it shows hardware and installation, not just software module structure (careful: it's easy to mistake it for a Component/Development-view diagram).
2) Structure: multiple consoles connected to each other, and each console also has its own direct link to the LAN server.
3) To allow secure outside access: add a firewall between an external "employee console" and the server, controlling incoming/outgoing traffic.
4) Availability (before): poor — no backup server, so a crash means total downtime.
5) Improve it: add redundant servers connected to the LAN server to act as backups when the primary crashes.
Q5 Heartbeat / unresponsive server scenario
a) Quality attribute = Availability.
b) The heartbeat detects the server going unresponsive during normal operation; the affected artifact is the process; the response is to disable the failing source and attempt repair; the measure is repair time.
c) 4 related availability tactics: Fault Detection (heartbeat/ping-echo), Recovery – Preparation & Repair (redundancy, rollback), Recovery – Reintroduction, Prevention (removal from service, transactions).
Q6 Pipes & Filters (patterns A vs B)
1) Pattern = Pipes and Filters. 2) Used for data-flow / transformation systems. 3) Components: Source (data origin), Filter (transforms data), Pipe (transmits data), Sink (consumes final output).
4) The parallel arrangement (filters running concurrently) has better performance — the sequential arrangement is slower since each filter waits its turn.
5) Yes, it supports security — you can inject a security filter (e.g. firewall, authentication, intrusion detection) at any point in the pipeline.