CPSA-F Sample Questions & Answers

The Context View is specifically designed to show the system as a 'black box' within its environment. It focuses on defining the system's scope and its relationships with external actors and systems, making it the ideal view for providing a high-level overview to a broad audience without delving into internal implementation details.

A well-formed ADR must capture the 'why' behind a decision. This includes the 'Context' (the problem, constraints, and requirements) and the 'Consequences' (the resulting trade-offs, benefits, and drawbacks). This information is crucial for future architects and developers to understand the rationale and avoid re-litigating past decisions. Implementation code and developer names are not core components of an ADR's purpose.

Qualitative analysis, especially for a quality like modifiability, relies on structured reasoning rather than purely quantitative metrics. Quality scenarios provide concrete, hypothetical changes (e.g., 'A change to the tax calculation algorithm should be deployable within one day and affect only one component'). Analyzing the architecture's ability to handle these scenarios is a primary method for assessing modifiability. Server logs relate to performance, and support tickets relate more to usability or reliability.

Architectural goals (the 'ilities' like scalability, maintainability) focus on the long-term health and viability of the system. Project goals (time, scope, budget) are often short-term and tactical. A key responsibility of an architect is to manage the tension between these two. For instance, achieving high scalability might require more time, directly conflicting with an aggressive launch date. This necessitates trade-offs and clear communication with stakeholders.

The Pipes and Filters pattern is ideal for processing streams of data where the processing can be broken down into a series of sequential, independent steps (filters). The data flows through channels (pipes). This pattern provides excellent decoupling between the steps, meeting the architect's requirement to reorder or replace them easily. MVC is for UI, Broker is for distributed component communication, and Layered is for separation of concerns in a more general application structure.

An interface serves as a formal contract between a service provider (the building block) and its consumers. By programming to this stable contract, consumers are decoupled from the provider's internal implementation. This allows the implementation to be modified, fixed, or even completely replaced as long as it continues to honor the interface contract, which is a cornerstone of maintainability and loose coupling.

This is a form of very tight coupling, often called content coupling or pathological coupling, where one module depends on the internal implementation details (the database schema) of another. This breaks the principle of encapsulation. The primary drawback is that the Orders team cannot refactor or change its database schema without coordinating with and potentially breaking the Reporting module, which severely hinders independent evolution and maintainability.

A software architecture is a complex artifact. A single diagram or description cannot capture all important aspects like static structure, runtime behavior, and physical deployment. Different stakeholders have different concerns: developers care about building blocks, operations engineers care about deployment, and project managers may care about high-level interactions. Using multiple, coordinated views allows the architect to communicate relevant information effectively to each target audience.

This solution directly addresses all key requirements. Using a message queue provides strong asynchronous decoupling, ensuring the web dashboard (Requirement 2) remains responsive. It allows the data processing workers to scale independently (Requirement 1) based on queue length. This separation creates two distinct deployment units for the web app and the workers, satisfying independent deployability (Requirement 3). The queue also enhances reliability, as a failing worker can be retried without affecting the web front-end (Requirement 4). This approach is an incremental refactoring, not a full rewrite, respecting the constraints.

The Context View's main purpose is to set the scene by defining what is inside the system (its scope) and what is outside, showing the relationships (interactions, dependencies) with external users, systems, and other entities.