ARCHITECTURAL MODELS SPECIFIC TO A PARTICULAR APPLICATION DOMAIN may be used when building new systems. Although instances of these systems differ in detail, the common architectural structure can be reused. TWO TYPES OF DOMAIN-SPECIFIC ARCHITECTURAL MODEL: 1. GENERIC MODELS Abstractions from a number of REAL SYSTEMS. They encapsulate the principal characteristics of those systems. Generic models are usually BOTTOM-UP abstractions — derived by studying what existing systems actually do. → they describe what IS. EXAMPLE: the compiler model below. 2. REFERENCE MODELS More ABSTRACT, idealised models. They provide information about that class of system and compare different architectures. Reference models are usually derived TOP-DOWN from domain knowledge and standards bodies. → they describe what OUGHT TO BE, as a standard for comparison. EXAMPLE: the OSI seven-layer model. THE DISTINCTION, stated for the exam: GENERIC MODEL abstracted from real systems, bottom-up, a description of practice, directly reusable as a design REFERENCE MODEL idealised, top-down, a vocabulary and a yardstick for COMPARING architectures, rarely implemented literally THE OSI MODEL IS THE PERFECT ILLUSTRATION of why reference models are not designs. No widely deployed protocol stack implements all seven layers as separate components — TCP/IP collapses the top three and the bottom two. Yet OSI remains the language everyone uses to DISCUSS networking, which is exactly what a reference model is for.

A COMPILER is the standard example of a generic model, because every compiler ever built has the same components. THE COMPONENTS LEXICAL ANALYSER characters → tokens SYMBOL TABLE names and their attributes, shared SYNTAX ANALYSER tokens → syntax (parse) tree SYNTAX TREE the shared intermediate structure SEMANTIC ANALYSER checks types and scope rules CODE GENERATOR tree → target code THE SAME MODEL, THREE DIFFERENT ARCHITECTURES: (a) AS A DATA-FLOW / PIPELINE ARCHITECTURE Suitable for BATCH COMPILATION — the classic command-line compiler. chars → [lexical] → tokens → [syntax] → tree → [semantic] → tree → [code gen] → object code ✔ each phase testable in isolation; phases reusable ✔ natural for batch use ✘ hopeless for an interactive environment, because a single keystroke would restart the whole pipeline (b) AS A REPOSITORY ARCHITECTURE All phases read and write a shared SYMBOL TABLE and SYNTAX TREE. ┌──────────┬──────────┬──────────┐ │ lexical │ syntax │ semantic │ └────┬─────┴────┬─────┴────┬─────┘ └──────┬───┴──────────┘ ┌──────▼───────────────┐ │ symbol table + tree │ └──────────────────────┘ ✔ this is what real compilers do, because the symbol table genuinely must be shared — a semantic analyser needs names the lexer found ✘ every phase depends on the shared representation (c) AS PART OF AN INTEGRATED PROGRAMMING ENVIRONMENT The compiler components plus an editor, a pretty-printer, a static analyser and a debugger, all sharing the abstract syntax tree. ✔ THIS IS WHY THE MODEL MATTERS. Because the tree is shared, the editor can offer autocomplete (it reads the symbol table), the analyser can underline errors as you type, and the debugger can map machine addresses back to source lines — all from ONE representation. THE LESSON: the same generic model supports several architectures, and the choice among them is driven by whether use is BATCH or INTERACTIVE. That is the reusable insight, and it generalises far beyond compilers.

THE OSI REFERENCE MODEL — the canonical reference model, a seven-layer model for communication systems: 7 APPLICATION the programs using the network 6 PRESENTATION data representation, encryption 5 SESSION dialogue control between endpoints 4 TRANSPORT end-to-end reliable delivery (TCP) 3 NETWORK routing between networks (IP) 2 DATA LINK frames on one link, error detection 1 PHYSICAL bits on the medium Its VALUE: it provides a vocabulary and a decomposition that lets us compare and discuss any real protocol stack, and it cleanly separates concerns so a change at one layer need not affect others. Its LIMIT: as noted, few systems implement it literally. OTHER WIDELY USED REFERENCE ARCHITECTURES: THREE-TIER / N-TIER presentation, application, data. The default for business information systems. MODEL–VIEW–CONTROLLER (MVC) separates the data (model), its display (view) and the input handling (controller). The reference architecture for interactive applications, and the reason nearly every web framework has the same three directories. ETL PIPELINE extract, transform, load — the reference architecture for data warehousing. PUBLISH–SUBSCRIBE the reference architecture for event-driven integration. BROKER ARCHITECTURE CORBA's reference model for distributed objects. SOFTWARE PRODUCT LINES — reference architectures taken to their commercial conclusion: A product line is a set of systems sharing a common, managed set of features, built from a common set of core assets. The reference architecture IS the core asset, and each product is a configuration of it. EXAMPLES: a bank's retail platform deployed for many countries; a car manufacturer's engine-control software across a model range; a medical-device family. THE ECONOMICS: the first product costs MORE than a bespoke build (because the architecture must be generalised), and every product after the second or third costs dramatically less. The break-even is typically quoted around the third product — which is why product lines are worth it for a family and wasteful for a one-off. WHEN A REFERENCE ARCHITECTURE IS THE WRONG CHOICE: · your problem is genuinely novel and the reference model forces a shape that does not fit — the classic symptom is fighting the framework · the reference architecture's non-functional profile does not match yours (a three-tier CRUD architecture applied to a hard real-time control problem) · you would use 5% of it and carry the complexity of the other 95% THE TEST: adopting a reference architecture should REMOVE decisions you did not want to make. If it is adding decisions and workarounds, it is the wrong one.