iSAQB CPSA Foundation Level flashcards
iSAQB CPSA Foundation Level · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Software architecture definition
- The fundamental organization of a system embodied in its components, their relationships to each other and the environment, plus the principles guiding its design and evolution.
- Building block
- Any architectural element such as a subsystem, component, module, or interface. Building blocks can be decomposed hierarchically into finer-grained blocks with defined responsibilities.
- Static vs dynamic structure
- Static structure covers building blocks and their compile-time dependencies. Dynamic structure covers runtime interactions, concurrency, and behavior between blocks during execution.
- Interface contract
- The externally visible agreement of a building block: operations it provides and services it requires. It hides internal implementation so clients depend only on the contract.
- Architectural decision
- A design choice that constrains the solution space and is costly to reverse. It should be documented with context, alternatives considered, and rationale.
- Architecture versus design
- Architecture sets coarse-grained, long-lived structures and cross-cutting rules. Detailed design refines individual building blocks with local, more easily changed implementation decisions.
- Architect responsibilities
- Defining and evolving the architecture, clarifying requirements and constraints, documenting and communicating decisions, evaluating quality, and ensuring implementation conforms to the intended structure.
- Stakeholder mediation
- The architect balances interests of management, developers, operations, and users, translating between business goals and technical constraints and making conflicts explicit rather than hidden.
- Ivory-tower architect
- An anti-pattern where the architect designs in isolation without feedback from implementers. The resulting architecture often ignores feasibility constraints and is not adopted.
- Architecture conformance
- The ongoing check that implementation matches documented architecture. Divergence is either corrected in code or consciously accepted and the architecture description updated.
- Architect skill profile
- Technical depth in design and technology plus communication, moderation, and negotiation skills. Authority comes from justified decisions and credibility, not from hierarchy alone.
- Architecture documentation purpose
- Documentation supports communication among stakeholders, preserves decision rationale, enables onboarding, and provides a basis for evaluation and change impact analysis.
- View and viewpoint
- A view represents specific architectural structures for a concern. A viewpoint defines the conventions, notation, and questions used to construct that kind of view.
- Context view
- A black-box view of the system boundary showing external actors and systems plus the interfaces crossing the boundary. It clarifies scope before internal decomposition.
- UML diagram families
- Structural diagrams include class, component, package, and deployment. Behavioral diagrams include sequence, activity, state machine, and use case. Notation follows the question asked.
- Architecture decision record
- A short document capturing one decision: its context, the decision itself, alternatives considered, and consequences. Records preserve the rationale that code cannot express.
- Diagram abstraction level
- Each diagram should state one consistent level of abstraction and include a legend. Mixing detail levels in a single diagram is a common communication defect.
- Top-down versus bottom-up
- Top-down decomposes from requirements into structures. Bottom-up starts from existing components and constraints. Real projects combine both approaches iteratively.
- Coupling and cohesion
- Cohesion measures how strongly elements inside one building block belong together. Coupling measures dependencies between blocks. Good structure has high cohesion and low coupling.
- Strict versus relaxed layering
- Strict layering allows dependencies only to the next lower layer. Relaxed layering permits defined exceptions, trading purity for practicality where justified.
- Dependency rule
- Source-code dependencies should point toward more stable and more abstract elements. Volatile details depend on stable abstractions, not the reverse.
- Architectural pattern
- A named, reusable coarse-grained solution structure such as layers, pipes-and-filters, microservices, event-driven, or broker. Each pattern carries specific trade-offs.
- Decomposition by volatility
- Isolating parts likely to change behind stable interfaces limits the impact of change. Volatility is a decomposition criterion alongside functionality and technical concerns.
- Quality attribute scenario
- A concrete requirement statement with source, stimulus, artifact, environment, response, and response measure. It makes vague quality goals testable and comparable.
- ISO/IEC 25010 categories
- The standard groups quality attributes into functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability.
- Architecture tactic
- A design decision that influences one quality attribute, such as caching for performance, redundancy for availability, or authentication for security.
- Sensitivity point
- A design decision that significantly affects one quality attribute. Identifying sensitivity points during evaluation reveals where the architecture is fragile.
- Trade-off point
- A design decision that affects several quality attributes in opposite directions. Trade-off points are the places where evaluation must weigh competing goals.
- ATAM evaluation
- Architecture Tradeoff Analysis Method: elicits quality scenarios with stakeholders, then identifies risks, sensitivity points, and trade-off points before major investment.
- Static analysis for architecture
- Tools that parse source code and detect dependency violations such as layer breaches or cycles, enforcing architectural rules automatically in the build.
- Diagram as code
- Storing diagrams as text in version control so they can be diffed, reviewed, and kept consistent with source code alongside other artifacts.
- Architecture metrics tools
- Tools that compute structural measures such as coupling, cohesion, instability, and abstractness to detect erosion and compare design alternatives objectively.