iSAQB CPSA Foundation Level cheat sheet

Software architecture = the set of fundamental structures of a system: its components (building blocks), their externally visible properties, and the relationships among them.

Architecture concerns the structures that are hard to change later; implementation details that are locally replaceable are not architecture.

Static structures describe building blocks and their dependencies (modules, layers); dynamic structures describe runtime behavior, interactions, and concurrency.

Architecture is described from multiple views; no single view captures all concerns, so views must be selected by stakeholder interest.

A building block is any architectural element (subsystem, component, module, interface); it can be hierarchically decomposed into finer blocks.

An interface (provided/required) defines a contract: what a building block offers and what it needs from others; it hides internal implementation.

Architecture is not the same as design: architecture sets the coarse-grained, long-lived frame; detailed design refines individual building blocks.

Architecture emerges from requirements plus constraints; functional requirements shape behavior, quality requirements shape structure.

Architectural decisions are the choices that constrain the solution space; they must be documented with rationale and alternatives considered.

The architect owns technical responsibility for the architecture: defining, communicating, and evolving it, and justifying decisions to stakeholders.

Core tasks: clarify requirements and constraints, design structures, evaluate quality, document decisions, and support the implementing teams.

The architect mediates between stakeholders: management (cost, schedule), developers (feasibility), operations (runtime), and users (behavior).

The architect is not a lone decision-maker: decisions are made with the team and stakeholders, but the architect ensures consistency across the system.

The architect must continuously verify that the implementation conforms to the architecture; divergence is either corrected or the architecture is consciously revised.

An architect needs technical depth plus communication, moderation, and negotiation skills; leadership is exercised through decisions and rationale, not authority alone.

Typical anti-patterns: architect as ivory-tower designer, architect as full-time coder without architectural oversight, and architect as pure documenter.

On large systems, architecture responsibility is split (e.g., domain architects, integration architect) with explicit coordination of cross-cutting concerns.

The architect's work is iterative: architecture is elaborated alongside requirements and refined as risks and knowledge grow.

Architecture documentation serves communication, decision support, and onboarding; it must be targeted at its readers, not exhaustive for its own sake.

A view is a representation of a set of architectural structures; a viewpoint defines the conventions, notation, and concerns for building such a view.

Common view types: context, building-block (static structure), runtime (dynamic interaction), and deployment (mapping to infrastructure).

The context view (system boundary) shows the system as a black box with external systems, actors, and interfaces crossing the boundary.

UML offers structural diagrams (class, component, package, deployment) and behavioral diagrams (sequence, activity, state machine, use case).

UML is a notation, not a method: diagram choice must follow the question being answered, and not every UML element needs to be used.

Architecture description languages and models (e.g., SysML for systems, ADLs) add formal semantics; informal sketches are acceptable when clearly labeled.

Documentation should capture decisions and rationale (e.g., as decision records) because the 'why' is lost faster than the 'what'.

Diagrams need a legend, consistent notation, and a stated level of abstraction; mixing abstraction levels in one diagram is a common communication defect.

Top-down design starts from requirements and decomposes; bottom-up design starts from existing components and constraints; real projects combine both.

Decomposition criteria: by domain/functionality, by technical layer, by volatility (likely-to-change parts isolated), and by team organization.

Coupling and cohesion are the central structural metrics: aim for low coupling between building blocks and high cohesion within each.

Layers are a coarse structuring pattern; strict layering allows only downward dependencies, while relaxed layering permits defined exceptions.

The dependency rule: source-code dependencies point toward more stable, more abstract elements, never toward volatile details.

Design patterns (e.g., Adapter, Facade, Observer, Strategy) are reusable solutions to recurring structural problems; they are named vocabulary, not a checklist.

Architectural patterns (layers, pipes-and-filters, microservices, event-driven, broker, MVC) each trade off coupling, distribution, and operational cost.

Interfaces should be designed for stability: publish contracts, hide internals, and prefer narrow interfaces that expose only what clients need.

Iterative architecture development: identify risks, design a candidate structure, evaluate it, implement a slice, and refine based on feedback.

Quality requirements must be made concrete as quality scenarios: source of stimulus, stimulus, artifact, environment, response, and response measure.

A quality attribute scenario distinguishes stimulus, response, and measurable response measure; 'the system shall be fast' is not a requirement.

ISO/IEC 25010 groups quality attributes: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability.

Trade-offs are inevitable: e.g., security vs. usability, performance vs. maintainability, availability vs. consistency (CAP theorem for distributed data).

Tactics are design decisions that influence a quality attribute (e.g., caching for performance, redundancy for availability, authentication for security).

Architecture evaluation methods (e.g., ATAM) elicit scenarios, analyze risks, sensitivity points, and trade-off points before major investment.

A sensitivity point is a design decision that significantly affects one quality attribute; a trade-off point affects several attributes in opposite directions.

Quality is verified by measurement against scenarios, not by assertion; fitness functions or automated checks can guard architectural constraints.

Non-functional requirements often conflict with each other and with constraints (budget, legacy); the architect makes the conflict explicit and documents the choice.

Modeling tools (UML/SysML editors, ArchiMate tools) support consistent notation and traceability from models to views.

Architecture management tools (e.g., repository-based modeling) keep models, decisions, and documentation versioned and linked.

Static analysis tools detect dependency violations (e.g., layer breaches, cycles) and enforce architecture rules in code.

Build and CI tools can run architecture checks automatically (e.g., dependency-rule tests) so conformance is verified continuously.

Metrics tools measure structural properties such as coupling, cohesion, instability, and abstractness to spot erosion.

Documentation tools (wikis, decision-record templates, diagram-as-code) keep architecture descriptions maintainable and reviewable.

Diagram-as-code approaches store diagrams as text in version control, enabling diffing and review alongside source code.

Trade-off analysis and prototyping tools (spikes, load-test harnesses) reduce uncertainty about quality attributes before commitment.

Tool choice follows the communication goal: a whiteboard sketch for discussion, a formal model for long-lived documentation and analysis.