Question 4 of 6: Software Architecture's Role, Multiple Structures, and Views

Question 4: Software Architecture's Role, Multiple Structures, and Views (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) The Role of Software Architecture Across the Process

Software architecture is the earliest and most consequential design decision, and it shapes every stage that follows it. During requirements analysis, architecturally-significant requirements (scalability, availability, security, performance targets) are the ones that most constrain the choice of architectural style, so architecture and requirements analysis inform each other iteratively rather than in strict sequence. During system and object design, the architecture fixes the major components and their allowed interactions, so that detailed design of each component and its classes happens inside boundaries the architecture has already drawn, keeping the detailed design of separate components independent of one another. During implementation, the architecture determines how work can be partitioned across teams (each team owns a component whose interface is architecturally fixed) and constrains technology choices, such as which components must be network-callable services versus in-process libraries. During testing, the architecture's component and interface boundaries define the natural units for integration testing, and architecturally-driven quality attributes (load capacity, failover behaviour) are validated against the targets the architecture was chosen to meet.

(b) Two Structures of the Same System

A single software system can be described by several different architectural structures at once, because "structure" depends on which kind of component and relationship is being shown. The two diagrams below both describe the same online course-registration client-server system, but one shows its logical/component decomposition and the other shows its physical deployment — two legitimately different structures of one system.

(c) Structural View vs. Behavioral View

The structural view is static: it shows what the system's components are and how they are connected — the module decomposition, the deployment topology, the class hierarchy — without saying anything about the order in which they act. The behavioral view is dynamic: it shows how those components interact over time to carry out a specific scenario — the sequence of messages exchanged, the states a component passes through, the order operations occur in. For the course-registration system above, the structural view is exactly the two diagrams shown in part (b): they say the business-logic layer exists and calls the data-access layer, but not when. A behavioral view of the same system would instead be a sequence diagram for "student enrols in a course," showing the student's UI calling the business-logic layer, the business-logic layer checking seat availability against the data-access layer, and a confirmation returning back up the chain in that specific temporal order — the same components from the structural view, now shown acting in a concrete sequence.

Practical Application

An architect typically presents both views together: the structural view (a component or deployment diagram) tells a new developer what pieces exist and where they run, while a behavioral view (a sequence or state diagram) for each major use case tells them how those pieces actually collaborate to deliver a feature — neither view alone is a complete architectural description.