25-Comp-A6 Software Engineering · December 2016
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2016 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: eight questions, candidates answer any five of the eight (all questions equal weight — each of the five counted questions is worth 20%; only the first five questions as they appear in the answer book are marked). All eight questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, software testing, component-based software engineering, verification and validation, distributed software engineering, software evolution/maintenance; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process, testing and architecture coverage; Gamma, Helm, Johnson & Vlissides, Design Patterns — object-oriented design/reuse vocabulary.
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 centralized system's capacity is bounded by the resources (CPU, memory, I/O bandwidth) of the single machine it runs on: once that machine is saturated, the only way to grow capacity is vertical scaling — buying a bigger machine — which has a hard physical and economic ceiling. A distributed system instead scales horizontally: additional demand is met by adding more processing nodes, each contributing its own CPU, memory and I/O capacity, so total system capacity grows roughly in proportion to the number of nodes rather than being capped by any single machine's limits. This is why distributed systems are described as inherently more scalable — the scaling strategy itself (add nodes) has no equivalent hard ceiling the way "buy an even bigger single machine" eventually does.
The likely limits on distributed scalability are not physical capacity but coordination costs: network bandwidth and latency between nodes (which do not improve just by adding more nodes, and often worsen as more nodes must communicate), the overhead of maintaining consistency across replicated or partitioned data (locking, consensus protocols), and the increasing complexity of partitioning work and data across nodes without creating hot spots or excessive cross-node traffic. In practice, the fraction of the workload that is inherently sequential or requires cross-node coordination (rather than being embarrassingly parallel) sets the effective ceiling on how much adding further nodes actually helps.
A fat-client (thick-client) architecture puts significant application logic — data validation, business rules, even a substantial part of data management — on the client machine, with the server providing mainly data storage and access; the classic example is a traditional desktop application talking to a database server. A thin-client architecture keeps the client responsible for presentation only (rendering the UI and forwarding user input), with essentially all application logic and data management executed on the server; the classic examples are a browser-based web application or an old-style terminal talking to a mainframe.
Fat clients give better responsiveness (logic executes locally, no round-trip needed for every interaction) and can continue limited operation when disconnected from the server, but are harder to deploy and update (every client machine needs the new logic installed) and place processing demand on end-user hardware. Thin clients are trivial to update (a single server-side change reaches every user immediately) and impose minimal requirements on client hardware, but depend entirely on network connectivity and place all processing load on the server, which must then be scaled to handle every client's logic centrally.
Modelling each regional distribution centre's own product inventory as its own remote object (rather than one shared, centralized database of every unit of stock in the country) lets each warehouse's stock-management system remain independently owned and updated while still being reachable through a common interface, which is the central benefit a distributed-object approach brings to this problem over a monolithic centralized design.
The Shopper Client is the customer-facing UI (web or app) through which a user browses the catalogue, checks availability, or places an order. The Order Broker is a façade object that receives the client's request, determines which regional distribution centre(s) it concerns (e.g. by the shopper's shipping postal code, or by fanning a catalogue search out to all regions), and forwards stock-availability queries or purchase operations to the appropriate Warehouse Proxy — a remote-object stand-in for one distribution centre's own inventory-management system, so that each warehouse's internal stock database and fulfilment logic stays local to that facility and is never replicated centrally. Buying a product is executed as a request on the specific Warehouse Proxy that will actually fulfil the order (the one holding stock closest to the shopper, or with the most available units), so no cross-warehouse coordination is needed for an ordinary purchase; the Order Broker calls the external Payment Gateway to charge the customer only once the chosen Warehouse Proxy has confirmed and reserved the stock, and rolls the reservation back if payment is declined.
