ISQI CPSA-FL - Questions & Answers

Common definitions of software architecture describe a system through major structural elements, not through every source file or every detailed requirement. Building blocks are the architectural units that can be decomposed, assigned responsibilities, and connected to other units. Components are a common form of such units, especially when the discussion is about substitutable or deployable parts of a system. Relationships matter because architecture is not only a list of parts; dependencies, calls, data flow, containment, and allowed communication shape the system as much as the parts themselves.

Interfaces are also central because they define what other building blocks can rely on without knowing internal implementation details. Functionality and requirements influence architectural work, but they are inputs and goals rather than the structural vocabulary normally used in the definition. Source code is a realization of architecture at a lower level of detail. The learning point is to separate the architecture description from implementation artifacts: architecture captures important building blocks, components, relationships, and interfaces that guide later design and construction.

Understandability is a first-class quality characteristic for architecture documentation because the document is only useful when its intended readers can apply it. A document can contain many diagrams and still fail if developers, testers, operations staff, or managers cannot determine what decisions were made and why those decisions matter. Correctness is needed because wrong documentation leads to wrong implementation choices. Efficiency is relevant in the documentation sense: readers should be able to find the information they need without excessive effort or unnecessary detail.

Scope and completeness also affect understandability. If the document omits important interfaces, quality requirements, deployment assumptions, or architectural decisions, readers will fill gaps differently and the architecture becomes harder to communicate. If it includes material far outside its intended purpose, the important structure becomes buried. Simplicity and brevity can improve readability, but they are not enough by themselves; an overly short document may omit essential architectural facts. The key idea is that understandable documentation balances accurate content, appropriate scope, sufficient completeness, and economical presentation for its audience.

Template-based architecture documentation is valuable because it gives authors a repeatable structure for describing the same kinds of architectural information across systems and across levels of detail. A white-box description explains the internal decomposition of a building block: which smaller parts it contains, how those parts relate, and why that decomposition was chosen. A black-box description describes a building block from the outside, including its responsibility, externally visible behavior, interfaces, and relevant quality properties. Together, black-box and white-box sections let readers move from external contract to internal structure without mixing the two perspectives.

A standardized document structure is the third essential field because it gives stakeholders predictable places to find context, views, decisions, risks, and interface descriptions. Copyright headers, code templates, and test-case templates may be useful in other engineering activities, but they do not define the core content of architecture documentation. The practical lesson is that an architecture template should guide consistent architectural communication, not simply impose formatting. It should make important structures, contracts, and decompositions easy to locate and compare.

Interactions of runtime building blocks are best explained with notations that show behavior over time. Activity diagrams are useful when the focus is flow of control or parallel activities among collaborating elements. Sequence diagrams are especially strong when the reader must understand messages between participants in chronological order. Flowcharts can express ordered decisions and processing steps in a compact form. Numbered sequential steps are also suitable when a lightweight textual description communicates the runtime collaboration more clearly than a formal diagram.

State diagrams serve a different purpose: they describe the lifecycle of one object or component as it moves between states. That can support runtime reasoning, but it is less direct for showing the interaction among multiple building blocks. Class diagrams describe static types and relationships, not runtime collaboration. Interface tables define contracts and signatures, while screen-flow depictions concentrate on user navigation. The point being tested is the difference between static structure and dynamic behavior. When the concern is how runtime blocks interact, choose behavioral and sequence-oriented representations that make order, responsibility, and collaboration visible.

Quality characteristics influence one another, and architects must understand those tradeoffs instead of treating every quality goal as independent. Simplicity usually improves comprehensibility because fewer concepts, fewer dependencies, and fewer special cases make the architecture easier to explain and reason about. A simple structure is easier to document, review, test, and modify because readers can form a stable mental model of responsibilities and dependencies.

Flexibility can work in the opposite direction when it is achieved through extra indirection, configuration mechanisms, extension points, or generalized abstractions. Those mechanisms may be justified, but they often create more paths through the system and therefore make tests harder to design and maintain. Flexibility does not automatically improve robustness; a highly flexible design can still fail if contracts are unclear or combinations are not controlled. Efficiency and performance are closely related terms, so saying that increased efficiency reduces performance reverses the normal meaning. The architectural lesson is to reason about quality interactions explicitly. Some qualities reinforce each other, while others require conscious balancing and documented decisions.

A software architect is responsible for architectural qualities that are strongly shaped by structure, communication, deployment, and key design decisions. Performance is one of those qualities because choices such as distribution, caching, concurrency, data access, resource ownership, and component boundaries can make later performance work easy or extremely difficult. The architect does not implement every optimization, but the architecture creates the conditions in which performance goals can be met.

The suitability of the design for its purpose is also central. Architecture translates requirements, constraints, and quality goals into a solution structure that can support the intended business and technical use. Technical implementation quality matters, but it is shared with developers and depends on coding, reviews, tests, and engineering discipline at a finer level. Defect freedom cannot be guaranteed by architecture or by any single role. The architect should identify risks, support testability, and guide quality tradeoffs, yet the final absence of errors is not a realistic responsibility. This distinction helps separate architectural accountability from implementation and verification responsibilities.

Iterative and incremental design is useful when requirements, constraints, technologies, or quality tradeoffs are not fully known at the beginning. Iterations allow architects to revisit decisions after feedback, prototypes, reviews, or new stakeholder information. That helps a team handle uncertainty because weak assumptions can be tested before too much implementation depends on them. Iteration also exposes design problems earlier: if a proposed decomposition, interface, or deployment idea does not work, the team learns while change is still affordable.

Incremental design adds value by considering important functionality early rather than postponing all meaningful behavior until the architecture is supposedly complete. It supports risk-driven development because the team can build and evaluate the most critical slices first. Incremental work does not inherently delay risk discovery; done well, it accelerates discovery. Iteration also does not mean customer involvement decreases. In many processes it increases feedback. The lesson is that architecture should evolve under controlled learning. Decisions should be made deliberately, reviewed against evidence, and refined as the system context becomes clearer.

Architectural building blocks can exist at several abstraction levels. A component is a classic architectural unit because it can own responsibilities, expose interfaces, and collaborate with other units. A class can be an architectural building block in a more detailed design view, especially when it represents an important abstraction or boundary. Operations such as methods, procedures, functions, or services can also be treated as building blocks at a fine-grained level when their responsibilities and dependencies are architecturally relevant. Packages are common grouping mechanisms for related classes or components and can be used to express decomposition.

An algorithm is usually a design or implementation strategy inside a building block rather than a building block by itself, unless the architecture explicitly treats it as a replaceable component. A processor belongs more naturally to deployment or hardware context, not to software building-block decomposition. A test harness supports verification, and a local variable is too small and too implementation-specific for architectural structure. The important distinction is granularity and responsibility. Building blocks are units that can be named, decomposed, assigned responsibilities, and connected through defined relationships.

Quality requirements describe how well a system must perform its required behavior under stated conditions. A limit such as handling a defined number of requests per day is a capacity or performance-related quality requirement because it constrains throughput and resource planning. A failure-rate limit is a reliability requirement because it expresses how often the system may fail while still meeting expectations. Both examples influence architecture: they can affect deployment topology, redundancy, monitoring, data storage, communication patterns, and error handling.

The ability to select a sort order is primarily a functional requirement because it states a behavior the user can invoke. Automatic spelling correction is also functional behavior: the system performs a specific action on input text. Those functions may have quality aspects, such as speed or accuracy, but the statements themselves define features. Architects must separate feature descriptions from quality goals because quality requirements often create the strongest architecture drivers. They shape tradeoffs across components, infrastructure, interfaces, and operational concerns even when the visible user function seems simple.

When requirements are incomplete, components should be designed so future change does not spread unnecessarily through the system. Weak coupling helps because a component can evolve behind a stable interface with fewer ripple effects on neighboring components. Strong cohesion helps because related responsibilities live together, making each component easier to understand, test, replace, and extend. Openness for extension is also important because new requirements can be added through planned variation points or controlled extension mechanisms instead of repeated invasive changes.

Meaningful names are useful, but names alone do not make a component resilient to requirement change. Small size can help comprehension, yet size by itself is not the design target; a small component with scattered responsibilities or tight dependencies can still be hard to change. The architectural issue is managing volatility. Components should have clear responsibility, limited knowledge of one another, and boundaries that allow the team to refine behavior as new requirements appear. That combination reduces rework and makes early architectural work compatible with later learning.