CEN 4065 - Lecture 5: Understanding Quality Attributes – Architecture and Requirements (Vocabulary Flashcards)

A vocabulary-style set of flashcards covering key terms from the lecture notes on quality attributes, availability, deployability, tactics, and patterns.

Functional requirements

Requirements that state what the system must do, how it must behave or react to run-time stimuli.

Quality attribute requirements

Qualify functional requirements by annotating non-functional concerns (e.g., performance, resilience, usability).

Constraints

Design decisions with zero degrees of freedom; decisions that have already been made for you.

Functionality

The system’s ability to do the work it was intended to do; orthogonal to architecture; many architectures can satisfy the functionality.

Quality attributes

Non-functional properties that annotate functional requirements (e.g., performance, availability, usability).

Availability

A property of software being ready to carry out its task when needed; ability to mask or repair faults and minimize outage time; involves MTBF/MTTR and steady-state availability.

MTBF

Mean Time Between Failures.

MTTR

Mean Time To Repair.

Steady-state availability

MTBF/(MTBF + MTTR); the fraction of time the system is operational.

Deployability

The ability to deploy software within a predictable amount of time and effort; continuous deployment if fully automated.

Quality attribute scenario

A structured description of a quality attribute using Stimulus, Stimulus source, Environment, Artifact, Response, and Response measure.

Stimulus

A condition that requires a response when it arrives at the system.

Stimulus source

The entity (human, computer, etc.) that generated the stimulus.

Environment

The conditions under which the stimulus occurs (normal, overload, etc.).

Artifact

The part of the system (or collection) that is stimulated.

Response

The activity undertaken by the system as a result of the stimulus.

Response measure

A measurable way to assess the response (e.g., time, availability percentage).

General quality attribute scenarios

Quality attribute scenarios that are system-independent and potentially apply to any system.

Concrete quality attribute scenarios

Quality attribute scenarios that are specific to the particular system under consideration.

Availability example scenario

A sample general availability scenario with source, artifact, environment, stimulus, and response measure.

Tactics

Primitive design techniques used to achieve quality attribute goals; tools or methods architects apply.

Architectural pattern

A recurring design problem with a well-proven architectural solution; describes roles, responsibilities, relationships, and collaborations.

TMR (Triple Modular Redundancy)

Three identical components receive identical inputs; a voter decides the output and detects faults.

Active redundancy

Hot spare: all nodes process inputs in parallel; the spare can take over quickly with synchronous state.

Passive redundancy

Warm spare: active members update the spare’s state periodically; cheaper and less complex.

Cold spare

Spare remains out of service until failover; Activation involves a power-on-reset procedure; slower recovery.

Fault

The underlying cause of a failure.

Failure

When the system no longer delivers a service as specified.

Detect faults

Tactics used to detect faults before they become failures (e.g., Ping/Echo, Monitor, Heartbeat, Timestamp, Sanity Checking, Voting, Exception Detection, Self-Test).

Ping/Echo

Asynchronous request/response to test reachability and round-trip delay (ICMP).

Monitor

A component that checks the health of other parts of the system and can detect failure or congestion.

Heartbeat

A periodic message between a system monitor and a monitored process.

Timestamp

Used to detect incorrect sequences of events in distributed systems.

Sanity Checking

Validity checks of a component’s operations or outputs, often using an oracle for correct results.

Voting

Checking that replicated components produce the same results; can be replication, functional redundancy, or analytical redundancy.

Exception Detection

Detection of a condition that alters the normal flow of execution (e.g., exception, timeout).

Self-Test

A component tests itself to verify correct operation.

Redundant spare

A spare component that can take over if the primary component fails.

Rollback

Reverting to a previous known-good state.

Software Upgrade

In-service upgrades to executable code that do not interrupt service.

Graceful Degradation

Maintains the most critical functions while dropping less critical ones.

Reconfiguration

Reassigning responsibilities to remaining functioning resources to preserve as much functionality as possible.

Shadow

Operating a previously failed or upgraded component in a shadow mode before making it active.

State Resynchronization

Synchronizing state between active and standby components.

Escalating Restart

Restarting at progressively coarser-grained levels to minimize service impact.

Non-stop Forwarding

Separating supervisory and data planes so forwarding continues during recovery.

Removal from Service

Temporarily taking a component out of service to mitigate potential failures.

Transactions

Bundling state updates so distributed transactions are atomic, consistent, isolated, and durable.

Predictive model

Monitoring health to detect conditions that predict future faults and take action.

Increase Competence Set

Designing a component to handle more fault scenarios within normal operation.