25-Comp-A6 Software Engineering · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2013 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: nine questions, candidates answer any five of the nine (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 nine questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, requirements engineering, software testing, software reuse, rapid development and prototyping, client-server architectures, software validation; 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 three-tier client-server architecture fits this problem well: a dealer client tier providing the interactive user interface and scenario-editing workspace, an application server tier hosting the shared simulation engine, and a data server tier hosting the authoritative company/market data.
Each dealer client is a relatively "fat" client: it holds the presentation logic and, importantly, the scenario-editing logic that lets each dealer configure and drive the simulation according to their own working style and the stocks they cover, since the requirement explicitly states that dealers use the simulation differently depending on experience and stock type — this per-dealer customisation belongs on the client, close to the user, rather than being forced into one rigid shared interface. The client sends a dealer's chosen scenario parameters to the application server, which hosts the computationally expensive simulation engine itself. Centralising the simulation engine on the server (rather than replicating it on every dealer desktop) means the licensed/maintained simulation logic exists in one place, upgrades and corrections take effect for every dealer simultaneously, and the heavy computation runs on server-class hardware rather than being duplicated across many desktops. The application server, in turn, queries the data server for company fundamentals and live/historical market prices, keeping that data centrally maintained, consistent, and independent of both the client and the application tier.
Separating these three concerns onto three tiers gives each one an independent, appropriately-located responsibility: presentation and dealer-specific customisation stays at the client (where per-user variation is wanted), heavy shared computation stays at the application server (where centralising it avoids duplication and eases maintenance/licensing), and authoritative data stays at the data server (where a single consistent source serves every dealer and every simulation run identically). This also scales sensibly: adding more dealers means adding more (comparatively cheap) clients without duplicating the expensive simulation engine or the market-data feed, and the application and data tiers can each be scaled or upgraded independently of the other as load grows.
