PECB CMSA flashcards

34 cards. Read the term and the definition here. The deck at the top of this page is optional.

Architecture definition

The set of structures comprising software elements, their external visible properties, and the relationships among them. It captures decisions that are expensive to change and omits details irrelevant to reasoning about those structures.

Quality attribute scenario template

Six parts: stimulus, source of stimulus, artifact, environment, response, and response measure. Writing all six makes a non-functional requirement testable and comparable across candidate designs.

Information hiding principle

Parnas's rule that modules should hide design decisions most likely to change behind stable interfaces. Clients then depend on the interface, so internal changes do not ripple outward.

Separation of concerns

Decomposing a system so each element addresses a distinct, ideally non-overlapping set of responsibilities. It localizes complexity and makes elements independently comprehensible and replaceable.

Availability tactics

Fault detection (heartbeat, ping/echo, exception detection), recovery (redundancy, rollback, checkpoint), and prevention (removal from service, transactions). Each tactic addresses a distinct point in the fault-to-failure chain.

Modifiability tactics

Reduce coupling via encapsulation, intermediaries, and restricted dependencies; increase cohesion by splitting responsibilities and abstracting common services. These bound the ripple effect of a change.

Conway's Law

System structure tends to mirror the communication structure of the organization that builds it. Inverse Conway maneuvers deliberately restructure teams so the resulting architecture matches the target design.

Architecture vs. detailed design

Architecture comprises structures and decisions whose reversal is costly and that constrain many later choices. Detailed design fills in local decisions that are cheaper to change without architectural impact.

Viewtype categories

Module viewtypes show code units and their relations; component-and-connector viewtypes show runtime elements and interactions; allocation viewtypes map software to environment such as deployment and work assignment.

Layered style

Organizes elements into layers where a layer may use only lower (or specific) layers. Strict layering forbids skipping layers; relaxed layering permits a layer to call any lower layer directly.

Pipe-and-filter style

Filters transform data incrementally and connectors are stateless pipes. It suits streaming and transformation pipelines but is weak for interactive dialogs and for maintaining shared global state.

Broker pattern

A broker mediates communication between clients and servers, providing location transparency and dynamic registration. It adds indirection, which improves distribution flexibility but complicates debugging and failure handling.

Publish-subscribe pattern

Producers publish events to topics; consumers subscribe, decoupling in identity and time. It scales well for notification but yields weaker delivery guarantees and harder end-to-end reasoning.

Microservices tradeoff

Independent deployability, technology heterogeneity, and team autonomy are gained at the cost of distributed transactions, network latency, operational overhead, and harder cross-service consistency.

Utility tree

An ATAM artifact rooted at utility. Its second level is a quality attribute, the third a refined scenario, and leaves carry importance and difficulty ratings used to prioritize evaluation effort.

UML behavioral diagrams

Sequence, activity, state machine, and use case diagrams depict behavior and interaction over time. Structural diagrams such as class, component, and deployment show static organization instead.

Platform-independent model

In Model-Driven Architecture, a PIM expresses the system without platform specifics. A transformation maps it to a platform-specific model, which is then realized on a chosen platform.

View template contents

A documented view includes primary presentation, element catalog, context diagram, variability guide, and architectural rationale. The template ensures consistent, reviewable documentation across all views.

Architecture decision record

A short record of context, the decision, its status, and consequences. ADRs preserve the reasoning behind structural choices, which diagrams and code cannot convey after the fact.

Architectural drivers

The small set of requirements and constraints that most shape the architecture, typically key functional requirements plus prioritized quality attribute scenarios. Documentation should state them before presenting structures.

Documentation roadmap

A guide explaining how the documentation set is organized and which views address which stakeholder concerns. It lets readers navigate without reading every view in sequence.

Architecture Haiku

A lightweight documentation technique conveying architecture essence through a short poetic summary plus small sketches. It communicates the big idea quickly before full documentation exists.

Stakeholder-to-view mapping

Each identified stakeholder concern should map to at least one documented view. A view with no concern behind it is documentation bloat and should be removed or justified.

Diagram comprehensibility limit

Keep element counts small enough to comprehend at a glance, roughly seven plus or minus two. Split large diagrams into multiple views rather than shrinking notation and labels.

Conformance checking

Comparing as-designed architecture against dependencies extracted from source code. Violations such as forbidden layer calls or cycles are reported for correction or formal waiver.

Fitness function

An automated, objective check that preserves an architectural characteristic, such as a dependency rule test or a performance threshold. It turns governance from periodic review into continuous verification.

Architecture review board

A governance body that reviews significant designs and deviations against standards. It grants or denies waivers, usually with an expiry, so exceptions do not become permanent silent decisions.

Technical debt principal and interest

Principal is the cost to rework the shortcut; interest is the ongoing drag it imposes. Prioritizing by interest rate rather than principal alone targets the debt that hurts most.

Architecture runway

The amount of architecture built ahead of feature demand that teams can still absorb without rework. Too little causes rework; too much risks building structures that are never used.

Traceability chain

Links from requirements to architecture decisions, components, and tests. The chain enables impact analysis when a driver changes and supports audit of design coverage.

ATAM phases

Presentation of the method and architecture, evaluation via utility tree and scenario analysis, then reporting. Outputs are risks, non-risks, sensitivity points, and tradeoff points.

Sensitivity and tradeoff points

A sensitivity point is a decision strongly affecting one quality attribute. A tradeoff point is a sensitivity point affecting two or more attributes in opposing directions, so improving one degrades another.

Architecture erosion vs. drift

Erosion is gradual structural decay such as accumulating cycles and coupling. Drift is divergence from the intended architecture without that decay, often from undocumented local decisions.

Scenario categories in evaluation

Use-case scenarios exercise current requirements, growth scenarios stress expected expansion, and exploratory scenarios probe likely future change. Exploratory scenarios are typically the hardest to satisfy.