Question 4 of 6: Architecture, Alternative Structures, and Architectural Views

Question 4: Architecture, Alternative Structures, and Architectural Views (equal value)

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 Driven by Functional and Non-Functional Requirements

Architecture design is shaped by both requirement types simultaneously, but in different ways. Functional requirements determine WHICH components the architecture must contain, because each major function needs a place to live: the address book's functional requirements to add, delete, modify, save and load contacts directly imply the architecture needs contact-management logic and a persistence mechanism, at minimum. Non-functional requirements determine HOW those components are structured and connected — they usually decide the architectural style itself. If the address book's non-functional requirements include high modifiability (the UI must be replaceable independently of the storage), the architect chooses a layered structure specifically to satisfy that quality target, even though a flat, single-module design could satisfy the identical functional requirements. If instead the dominant non-functional requirement were raw simplicity for a single-user desktop tool with no anticipated UI change, the architect might reasonably choose the flatter, less layered structure. The architecture is therefore the point where functional requirements (what must exist) and non-functional requirements (what quality it must have) are reconciled into one concrete structure.

(b) Two Alternative Architecture Designs

The two diagrams below show genuinely different structures for the same personal address book application (add/delete/modify/save/load contacts), reflecting different quality priorities.

The two designs differ sharply in their quality considerations. Design 1 (flat) is simpler and has lower call/indirection overhead — fewer modules, no layer-crossing calls — which favours quick initial development and slightly better raw performance, but scores poorly on Modifiability: because each function is free to touch storage and UI directly, changing the storage format (flat file to database) risks touching every one of the five functions. Design 2 (layered) trades a small amount of call overhead and extra initial structure for substantially higher Modifiability and Portability: the storage format can change by rewriting only the Data Access Layer, and an entirely new UI (a web front end alongside the desktop UI) can be added by writing only a new Presentation Layer, because the Business Logic Layer in the middle is completely insulated from both. For an application expected to evolve (new UIs, changing storage), Design 2 is the stronger choice despite its extra structure; for a small, fixed-scope utility that will never change, Design 1's simplicity may be the better trade.

(c) The Three Architectural Views

The module view describes the system's static decomposition into implementation units (modules, classes, packages) and the relationships between them at compile/design time — "what pieces of source code exist, and which ones depend on which." The component-connector view describes the system's RUNTIME structure: which components exist as running entities (processes, objects, services) and how they interact through connectors (calls, message queues, shared data) while the system executes — a module view element does not necessarily correspond one-to-one with a runtime component. The allocation view maps the runtime components onto the physical or organisational environment they execute in or are developed by — which processing node each component runs on (the deployment mapping), or which team is responsible for which module. The three views are complementary rather than redundant: the module view is what a developer studies to navigate the source code, the component-connector view is what an architect studies to reason about runtime behaviour and communication, and the allocation view is what an operations team studies to understand physical deployment — together they answer "what is the code structured as," "what actually talks to what while running," and "where does it physically run," and a complete architecture description needs all three because none of them can be derived from the other two alone.

Practical Application

A team choosing Design 2 for the address book would document all three views: a module view showing the Presentation/Business/Data packages and their compile-time dependencies, a component-connector view showing the same three as running objects exchanging method calls, and (if the system were later split into a client and a remote server) an allocation view showing the Presentation Layer deployed on the user's device and the other two layers deployed on a server.