Question 4 of 11: Architecture, Multiple Structural Views, and Behavioural View

Question 4: Architecture, Multiple Structural Views, and Behavioural View (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) Architecture and the Other Development Phases

Software architecture sits between requirements analysis and detailed design, and it draws from and constrains almost every other phase. It is derived from requirements analysis — especially the non-functional requirements, since it is scalability, security and reliability targets that usually decide which architectural style (layered, client-server, microservices, event-driven) is chosen, far more than the functional requirements do. Once chosen, the architecture constrains detailed design: each component identified at the architectural level is designed in detail within the boundaries and interfaces the architecture has already fixed, so detailed design cannot silently redraw the component boundaries the architecture established. Architecture also guides implementation directly, since developers write code to the module boundaries and interfaces the architecture defines, and it shapes the testing strategy, because integration tests are organised around exactly those same component boundaries and interfaces. In short, architecture is the single artifact that both derives from requirements and disciplines every phase that follows it.

(b) Two Structures of the Same System

The two diagrams below describe the same online-banking client-server system through two different structures, exactly as the question specifies: one static/component structure and one physical/deployment structure.

Both diagrams describe the same online-banking system, but the first shows how responsibility is divided among software components while the second shows which physical machine each component actually executes on and how those machines are connected — two legitimately different "structures" of one architecture, exactly as the question's own definition anticipates.

(c) Structural View vs. Behavioural View

The structural view describes the system's static organisation: which components, classes or modules exist and how they are connected — by calls, dependencies or composition — independent of any particular point in time. The layered diagram above is a structural view: it shows that a Presentation Layer exists, that it calls a Business Logic Layer, and that the Business Logic Layer calls a Data Access Layer, but it says nothing about the order of events during any specific use case. The behavioural view describes how the components collaborate over time to carry out a particular scenario — the sequence of messages, decisions and state changes involved in one use case — and is typically shown as a sequence, state or activity diagram. For the same banking system, a behavioural view for the "transfer funds" use case would show, in order: the Presentation Layer receiving the transfer request, calling a TransferService in the Business Logic Layer, which debits one account and credits another through the Data Access Layer, and finally returns a confirmation back up to the Presentation Layer. The structural view answers "what parts exist and how are they wired together"; the behavioural view answers "what actually happens, and in what order, when one specific scenario is executed."

Practical Application

Architects typically produce both views because neither alone is sufficient for review: the structural view is what a new developer studies to understand where a change belongs, while the behavioural view is what a reviewer studies to confirm a specific, business-critical use case (such as a funds transfer) will actually work correctly across the components the structural view has separated.