Architects rarely design from scratch: architectural styles and patterns are documented, reusable solutions with known benefits and consequences. This lecture separates the terms (a style is the overall shape, a pattern a specific recipe; architectural patterns are system-wide, design patterns work inside subsystems), traces their history from Alexander’s building patterns to Buschmann’s architectural patterns, and classifies systems into five types, each with its typical patterns. Lectures 2 and 3 then study those patterns one by one.
A style is a high-level template for the whole structure (e.g. data flow); a pattern is a specific reusable solution within it (e.g. pipes and filters).
1977 Alexander (253 building patterns) → 1990s architectural styles → 1994 Gang of Four (23 design patterns) → 1996 Buschmann et al. (architectural patterns).
Architectural patterns fix system-wide structure; design patterns are medium-scale and don’t change the fundamental structure.
Data-centered (blackboard, repository), data flow (pipes and filters), distributed (client-server, broker), interactive (MVC), hierarchical (layered).
The classification table (system type → pattern) is the base of every pattern question. Midterm 261 Q6 (3.5 marks) matched seven scenarios to layered, pipe-and-filter, broker, blackboard, MVC, client-server and peer-to-peer; Final 252 Q4 and Midterm 252 Q5 asked you to pick and draw a pattern for a scenario.
Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed.
Chapter 4 is about architecture patterns: ready-made system structures. This first lecture is the overview and classification; the patterns themselves come in Lectures 2 and 3.
Homework on the title slide: research serverless architecture (applications built from cloud functions that the provider runs on demand, with no server you manage).
The classification at the end uses five system types: data-centered, data flow, distributed, interactive and hierarchical.
An analogy for reuse: once you know the three steps for an average (list the numbers, total them, divide), you reuse them for students’ scores, weekly temperatures, anything.
Seen as a pattern, each step is a filter that transforms the data and passes it to the next one: pipes and filters. Because each step is independent, the same pipeline is reused for different averages.
Good logical architectures come from past experience: strategies that already worked in other systems.
The caveman has to invent the structure of a house from scratch, which is slow and risky.
Today’s architect reuses years of documented experience. The boxed point is the lesson: it is more efficient to build systems from successfully employed designs than to design from scratch.
The software version of the same story: the customer asks for “an interactive system that displays data from storage in multiple displays and formats”, and the architect recognises the requirement as the Model-View-Controller pattern.
Once a pattern is identified, the architect looks it up in a pattern catalogue for its documented structure (the MVC class and sequence diagrams on the right) and knows the quality properties a system built that way will have.
Styles and patterns are generic, reusable solutions that are easy to understand and apply to new problems with similar needs.
Benefits of that reuse: improved quality (they encode refined best practice), consistency (the same structure across an application or across projects, so it is easier to understand and maintain), and efficiency (well-understood, tested designs speed up design and implementation).
Decisions based on them benefit from years of documented experience describing the solution, its benefits, and the consequences (trade-offs) of using it. Knowing the consequences in advance is the real value.
What is the benefit of reusing architectural styles and patterns?
They are proven, documented solutions: quality improves because they encode best practice, designs are consistent and easier to maintain, design and implementation are faster, and their benefits and consequences are known in advance, which lowers risk and gives the team a shared vocabulary.
In 1977 Christopher Alexander, a building architect, published a pattern language to help people design good buildings and towns of any size.
It became a catalogue of 253 patterns, each documented with a picture, its context, the problem it solves, evidence that it works, and related patterns. That documentation format is the ancestor of every software pattern catalogue.
In the 1990s software engineers began cataloguing recurring high-level solutions (elements and their relationships) and called them architectural styles. Their focus was the solution.
Inspired by Alexander, they called them design patterns: a catalogue of 23 patterns, each described in a fixed specification format. Chapters 6–7 study several of them (Singleton, Builder, Composite, Observer…).
The Gang of Four (1994) catalogued how many design patterns, at what level?
A. 23 detailed-design (object-oriented) patterns
In 1996 Buschmann et al. combined the two lines of work: well-known architectural styles written in a pattern format (context – problem – solution). They called these architectural patterns.
Design patterns are medium-scale: applying one has no effect on the fundamental structure of the system, though it may strongly shape one subsystem. That sentence is the clearest way to tell the two apart.
How do architectural patterns differ from design patterns (Buschmann et al.)?
Architectural patterns specify system-wide structural properties and affect the architecture of all subsystems (e.g. client-server, layers). Design patterns are medium-scale: they do not change the fundamental structure of the system, only the design inside a subsystem (e.g. Observer, Factory).
Architectural patterns define the overall structure of the whole system and how all subsystems are organised and interact: client–server, layers, pipes and filters. The diagram groups them by system type (data-centered: blackboard, repository; data flow: pipes and filters; distributed: client-server, broker; interactive and hierarchical).
Design patterns are solutions at the subsystem or component level that do not change the overall structure: Observer, Factory, Strategy. The lower diagram groups them as creational, structural, concurrency and behavioural.
Put in order and match: Gang of Four, Buschmann et al., Alexander, architectural styles.
Alexander 1977 (253 building patterns) → architectural styles in the 1990s → Gang of Four 1994 (23 design patterns) → Buschmann et al. 1996 (architectural patterns).
Which pattern to apply depends on the type of system, its requirements and the desired quality attributes. These, not the pattern’s popularity, decide between patterns.
Large systems often combine patterns: a client–server system whose server is internally layered, for example.
Patterns are classified by the type of system they suit (next slide).
The table:
Match each scenario with the most suitable architectural style (each used once): (1) payroll app whose UI, salary rules and data storage must evolve independently; (2) security-log app where separate units extract fields, normalise timestamps, remove sensitive values and summarise; (3) hospital app talking to lab equipment from different vendors through one request format; (4) speech-understanding app whose components repeatedly add and reconsider partial interpretations; (5) museum ticketing shown differently on desktop and kiosks, updated by user actions; (6) classroom response app with one authoritative session for hundreds of phones; (7) emergency messaging between nearby phones with no Internet and no central node.
(1) Layered. (2) Pipe-and-filter. (3) Broker. (4) Blackboard. (5) MVC. (6) Client-server. (7) Peer-to-peer. Layered separates responsibilities; pipe-and-filter chains independent transformations; broker hides vendor-specific communication; blackboard combines partial solutions through shared knowledge; MVC separates model, views and control; client-server uses one authoritative service; peer-to-peer needs no central node.
Pipes and filters belongs to which system type?
A. Data flow
The diagram: many client software components around one data store (repository or blackboard). Clients don’t talk to each other, only to the store. Sharing data is easy; the store can become a bottleneck and a single point of failure.
They do not communicate directly with each other; the repository is the intermediary. In a repository the store is passive; in a blackboard, components react to changes on the shared data (Lecture 2).
Example: video streaming. The picture shows data entering from a source, passing through processing nodes (which may branch and rejoin), and leaving to the cloud: each node transforms the stream and hands it on.
Typical uses: signal processing and data streaming, compilers (lexer → parser → code generator), image and video processing.
The diagram: four computers, each with its own local OS, running applications A, B (spread over two machines) and C, joined by a middleware layer that hides the network so the applications can talk as if local. Network delays and partial failures are the price of distribution.
The Extra rule: an app that works offline only (calculator, offline dictionary, offline game) is interactive; an app that needs a server (WhatsApp, Gmail, banking) is distributed. Many real apps are both: interactive on the phone, distributed overall.
Example: a desktop calculator. The flow is user interface (handles interaction) → application logic (processes commands) → data management → local database. This separation of interface from logic is what MVC formalises.
Is an offline dictionary app interactive or distributed? Is WhatsApp?
The offline dictionary is interactive (runs fully on one machine). WhatsApp is distributed (clients communicate through servers over the network).
Example: control systems in manufacturing, robotics and vehicles. In the diagram the top-level node sends tasks and goals down; lower nodes pass sensations and results up; sensors and actuators at the bottom touch the controlled process.
Example: an operating system, from hardware interaction at the lowest layer to user-interface management at the top. Each layer uses only the services of the layer below it. The pattern is layered (and main program and subroutine).
The exercise: pick the pattern for each requirement.
A DBMS can be seen two ways: as a repository (data-centered: all applications share one database) or as part of a client–server system (distributed: clients send SQL queries, the server processes them). The classification depends on the viewpoint.
