Software Engineering

Architectural Design

Published: 2026-08-15

Level: postgraduate

Audience: Postgraduate students in Software Engineering

Prerequisite Knowledge

This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.

Previously Covered in This Subject

Requirements engineering — covered in Lecture 3 (Requirements Engineering)
User requirements and system requirements specifications — covered in Lecture 3 (Requirements Engineering)
The software life cycle and requirements engineering — covered in Lecture 3 (Requirements Engineering)
Non-functional requirements — covered in Lecture 3 (Requirements Engineering)
Emergent properties — covered in Lecture 3 (Requirements Engineering)

This class covers the concept of software architecture and architectural design. We look at why architectural design of software is important, and the architectural design decisions that have to be made during the process. We look at the idea of architectural patterns — well-established ways of organizing software architectures that can be reused in system designs — and how certain architectural patterns are used in particular kinds of systems like transaction processing systems. The process of architectural design in the software development lifecycle establishes the overall structure of the software system. We will also see why different kinds of models may be required to represent and document the software architecture, what the different types of architectural models are, and how certain domain-specific architectural models can be used as a basis for product lines and for comparing software architectures.

The lecture moves through the material in this order: what architectural design is and why it matters (5.1), the models used to represent an architecture (5.2), the decisions architects make (5.3), the non-functional requirements that steer those decisions (5.4), the three-stage design process (5.5), the structural patterns — layered, repository, client-server, and pipes and filters (5.6–5.8) — and the generic application architectures for transaction processing and language processing systems (5.9–5.11). By the end, every major idea is connected: the patterns are the vocabulary of the decisions, the non-functional requirements are the reason the decisions exist, and the application architectures show the patterns working at industrial scale.

5.1 Architectural Design: What It Is and Why It Matters

5.1.1 What Architectural Design Is

The question this section answers: How should the software system be organized? Before a single line of code is written, someone must decide what the major pieces of the system are, what each piece is responsible for, and how the pieces talk to each other. That decision is the architecture.

Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system. It sits at the top of the design effort: it fixes the skeleton of the system, and every later design activity (class design, module design, interface design) fills in the flesh around that skeleton.

Definition — software architecture. The output of the architectural design process is the software architecture, or a description of the software architecture: an architectural model that describes how the system is organized as a set of communicating components. A component is a named part of the system, such as a subsystem, a module, or a service. An interconnection is the link between components over which they exchange data or control signals.

Software architecture is a collection of components and their interconnections — but it is not just a static structure. It is also the dynamic interaction between the various modules and components at runtime: which components start first, who calls whom, and what data flows where when the system is actually running. That is why this class looks at four complementary views of architecture:

Structural modeling — how components and their interconnections can be represented on paper.
Control models — how components interact dynamically at runtime (for example, who decides what happens next).
Modular decomposition — how a high-level architecture is broken down into modules.
Application domain-specific architectures — how known types of systems (transaction processing, language processing) organize themselves.

Architectural design is a very critical link between requirements engineering and design because it identifies the main structural components in the system and the relationships between them. It is the bridge that turns "what the system must do" (requirements) into "how the system is built" (design).

Think of a building. The architecture of a software system can be thought of like the architecture of a building: the building architecture must be designed before construction can begin. You need to understand how the various components are placed, how various requirements are met by the architecture, and you need to analyze and evaluate the architecture for its trade-offs before you refine it and translate it into a detailed blueprint for construction. The analogy holds because in both worlds the structure decides which requirements can be met at all. It breaks in one place: unlike a building, software components can be redeployed to new computers after delivery — but, as section 5.1.3 shows, the architecture itself is still almost impossible to move once the system is built.

Software architecture is a separate area of study in itself, which you will learn in more depth later on, at the master's level. Here, the goal is to master the basics: what the architecture is, what decisions produce it, and which patterns organize it.

Exam note: Knowing the definition of architectural design and its output — an architectural model describing the system as a set of communicating components — is the foundation everything else builds on. Expect this definition to be asked for directly or used as the starting point of a short answer.

5.1.2 Where Architectural Design Sits in Development

After requirements engineering — in which you develop various system models and write the user requirements specification and the system requirements specification — you need a model of the system even to structure the requirements specification itself. At an early stage in the requirements process you identify a high-level architecture of the system, for example a client-server architecture or a microservices architecture. Whatever would be the basis for the development of the application is decided early on, and then you assign requirements to various components like the client side, the server side, and the middleware.

Real-world: Choosing between a client-server architecture and a microservices architecture is one of the first architectural decisions a real project makes, and it happens while requirements are still being written. The choice is hard to reverse later, because the requirements themselves get organized around whichever structure is chosen.

In a plan-driven process, such as the waterfall model, the path through development looks like this:

User requirements definition — what the users want, in their language.
Requirements engineering — analyze the domain and the user needs.
System requirements specification — the precise, checkable version of the requirements.
Architectural design — the overall structure of the system (high-level design).
Formal specification of some modules — for parts of the system that need mathematical precision.
High-level design — for example, a class diagram showing the design classes and their relationships.
Detailed design — the internal design of each module down to the level of methods and data structures.

Along this path, two things move in opposite directions. The customer's (or client's) involvement decreases from requirements engineering through to detailed design and so on: once the requirements are fixed, the customer has little to add until the software is delivered. The developer's (or contractor's) role significantly increases from requirements, to architectural design, to high-level design, to detailed design, coding, and implementation.

The four essential activities of any software development process are specification, development, validation, and evolution — no matter how many sub-stages a process has. Specification includes architectural design: without the architectural design you would not be able to structure the specifications into the requirements for the various components or features of the system. The specification and design phases overlap, starting from the architectural design and going forward; developers' involvement increases as you go toward design and implementation.

For a safety-critical system you may need a formal specification, which is based on mathematical models, in addition — for example, a formal description of a railway signalling module whose correctness must be proved, not just reviewed.

5.1.3 Agile versus Plan-Driven Development

In agile processes it is generally accepted that an early stage of the agile development process should focus on designing an overall system architecture. Then you can do incremental development: once you have the base architecture, you can build the various modules gradually in an incremental way. But you cannot refactor the architecture, or build the architecture itself incrementally.

The living-room analogy. Imagine a building whose architecture exists for only the living room and not the other rooms: you could not add the other rooms later after construction begins — the walls, the plumbing, and the roof would all be in the wrong place. Software behaves the same way. Even in agile development, with incremental development of components, you have an architectural design in place that identifies the various modules and components and how they interact. You cannot refactor the architecture without having to modify most of the system requirements to accommodate the architectural changes.

The point of the analogy: agility applies to building within the architecture, not to re-plumbing the architecture itself. Refactoring a single module in response to change is usually easy. Refactoring the whole architecture is expensive, because most components of the system may have to change to fit the new structure.

In practice there is significant overlap between requirements and design, and architectural design is often carried out in parallel with some specification activities, where you identify the major system components and their communications, or the way they interact.

5.1.4 Architecture in the Small and Architecture in the Large

Software architectures can be designed at two levels of abstraction.

Architecture in the small is the component-level, module-level view, concerned with the architecture of individual programs. It is usually done by the developer in terms of structuring the module or the program they are developing, decomposing an individual program into components like functions and methods. Program architectures are the main focus of this class.
Architecture in the large is concerned with the architecture of complex enterprise-wide systems that include various other systems, programs, and program components. These enterprise systems may be distributed over different sets of computers and different organizations, and may be owned and managed by different organizations. Some aspects of architecture in the large, or application architectures, for a variety of systems are covered toward the later part of this class.

Dimension	Architecture in the small	Architecture in the large
Scope	A single program	An enterprise-wide system of systems
Decomposed into	Functions and methods within one program	Programs, subsystems, and program components
Who usually does it	The developer of that program	A system or enterprise architect across organizations
Distribution	Usually one machine	Often spread over computers owned by different organizations
Where this class covers it	The main focus of the course	Application architectures in the later sections

When in doubt, think small first: a correct program architecture is the foundation, but a system whose pieces do not fit together fails regardless of how well each program is built.

5.1.5 What a Good Architecture Gives You

Software architecture is important because it affects the performance, robustness, distributability, and maintainability of the system. Individual components implement the functional system requirements, but the dominant influence on the non-functional system characteristics, or emergent properties, comes from the system's architecture. Architecturally significant requirements are typically non-functional requirements — the non-functional requirements have the most significant effect, or impact, on the choice of the software architecture.

In other words: a component is responsible for what a feature does, but the architecture decides how well the system as a whole performs, how likely it is to fail, and how easily it can be changed — the properties that emerge only when all components work together.

A clear, descriptive software architecture serves four purposes:

Stakeholder communication. The architectural design is a high-level representation of the system that can be used as a focus for discussion by a range of different stakeholders — customers, users, managers, developers — because it shows the system without drowning them in detail.
Systems analysis. Making the system architecture clear at an early stage in system development requires detailed analysis: you must think hard about the components, their relationships, and the trade-offs between design options.
Meeting non-functional requirements. Architectural design decisions have a significant effect on whether or not the system can meet critical non-functional requirements like performance, reliability, and maintainability.
A compact, manageable description. The architectural model is a compact, manageable description of how a system is organized and how the components interoperate — small enough to hold in your head, complete enough to guide the whole team.

Exam note: The four purposes of architecture — stakeholder communication, systems analysis, non-functional requirement satisfaction, and a compact manageable description — are core examinable points. A common short-answer question is to list them and explain one in a sentence or two.

5.1.6 Product Lines and Large-Scale Reuse

The system architecture is often the same for systems with similar requirements. The architecture of a banking system, or of an ERP for a banking system, will be similar, though the individual modules will differ; architectures for a university information system or for an e-commerce application platform will be largely the same as well.

Product line architecture. Product line architectures are an approach to reuse where the architectural model is used, or reused, across a range of related systems: once you have an architecture in place, you can customize it to suit your requirements and redesign it further. This is large-scale reuse through architectural design — instead of reusing a function or a class, you reuse the whole skeleton of the system.

Real-world: Banking applications are built around a core banking architecture with variants that satisfy specific customer requirements — a classic product line. The core (accounts, transactions, statements) stays the same; each bank's version adds its own products and business rules on top.

Recap. Architectural design defines the overall structure of a software system as a set of communicating components; it precedes implementation in both plan-driven and agile development, and it can be reused wholesale across similar systems as a product line. Next, we look at the models used to represent an architecture — starting with the informal box-and-line diagram and the formal notations that replace it.

5.2 Architectural Models: Box-and-Line Diagrams and Formal Notations

5.2.1 Box-and-Line Diagrams

The question this section answers: If architecture is the skeleton of the system, what do we draw the skeleton with? The most common answer in practice is surprisingly simple: boxes and arrows on a whiteboard.

The most common way to represent an architecture informally is the simple block diagram, or box-and-line diagram, which shows certain entities and relationships. It is most commonly used for discussion with stakeholders, because it helps stakeholder communication. A high-level view of the system is used for communication with the system stakeholders, and it is also helpful in project planning, because a simple box-and-line diagram is not cluttered with too much technical detail. Stakeholders can relate to it and understand a high-level abstract view of the system, and can discuss the system as a whole without being confused by too much detail of the components. The architectural model identifies the key components that have to be developed, so that managers can start assigning people to plan the development of these systems.

The notation is simple:

Each box represents a component.
Boxes drawn within a component show that it has been decomposed into subcomponents.
Arrows drawn from one box to another indicate that data or control signals are passed from one component to another in the direction of the arrows.

Worked picture — a packing robot. A classic box-and-line diagram describes a packing robot that packages objects on a conveyor. The central box, the packing system, is fed by a vision system that picks out objects on a conveyor, identifies the type of object, and selects the right kind of packaging. Arrows flow from the vision system to an object identification system, then to a packaging selection system, and from there to the packing system. A conveyor controller moves objects from the delivery conveyor to be packaged and places packaged objects on another conveyor; an arm controller and a gripper controller carry out the physical pick-and-place. Each arrow names the data that passes: a vision reading, a packaging choice, an arm command. This single diagram lets a manager, an engineer, and a customer all discuss the system without reading any code.

Many examples of this kind of diagram appear in most architectural design discussions at the stakeholder level in the initial stages. The block diagram presents a high-level picture of the system structure that people from different disciplines, who are involved in the system development process, can readily understand. For many projects, block diagrams are in fact the only form of architectural model used — more refined formal models may be used at a later stage, but at the stakeholder discussion level you will have box-and-line diagrams.

5.2.2 The Criticisms of Box-and-Line Diagrams

Warning — the professor's caveat: In spite of their widespread use, box-and-line diagrams are criticized, and they are not good architectural representations — in fact they are very poor architectural representations. They just show that there are various modules and interactions, but they do not specify the precise nature of the interactions: they show neither the type of relationships between the components nor the components' externally visible properties, and they lack semantics.

What exactly is missing? Consider two boxes connected by an arrow. The diagram does not say whether the arrow is a function call, a message, a database read, a network packet, or a hardware signal. It does not say whether a component is a process, a library, or a physical machine. It does not say what a component promises to other components (its externally visible interface and behavior). All of that semantic content is absent.

So the perception of box-and-line diagrams depends on what you use them for: they are fine as a means of discussing the high-level requirements, but weak as a means of documenting the architecture. In short — good for conversation, poor for contracts.

5.2.3 Formal Notations and Documentation Models

Architectural models can also be used as a way of documenting the architecture that has been designed, and this use has to be precise: the aim is to produce a complete system model that shows the different components in the system, their interfaces, and their connections. The argument for such a model is that a detailed architectural description makes it easier for the designers, the developers, and the programmers to understand and build the system as it should be. A more detailed and complete description leaves less scope for misunderstanding the relationship between the architectural components: what each component may expect from its neighbors, and what each must provide.

For a more detailed design, and for translating the architectural design into a detailed design, you need more formal models with the proper notation supported by UML and other architectural description languages. UML (the Unified Modeling Language) contributes class diagrams, component diagrams, and deployment diagrams that name the interfaces and connections explicitly. Architectural description languages (ADLs) go further: their basic elements are components and connectors, and they include rules for well-formed architectures. Ideally, if an architecture is to be documented in detail, you use a more rigorous notation for the architectural description.

However, developing a detailed architectural description is expensive and time-consuming, and it is practically impossible to know whether or not it is cost-effective — so detailed architectural descriptions are not used very often. The same cost logic applies to the "4+1 view model" of architecture (logical, process, development, and physical views, linked by scenarios): it is a useful reference for what could be documented, but in practice teams document only the views that genuinely help communication.

Real-world: UML class and component diagrams are the standard formal notation into which an architecture is translated when it moves from stakeholder discussion to detailed design. The informal whiteboard drawing becomes a precise model only when the team commits to a design.

Box-and-line diagrams remain a very good way of supporting communication between the people involved in the software design process: they are intuitive, domain experts and software engineers can relate to them and participate in discussions about the system, and managers find them helpful in planning the project. The trade-off is not "informal or formal" but "discussion or documentation" — use the right tool for the job.

Recap. Box-and-line diagrams are the universal language of architectural discussion but poor as precise documentation; formal notations such as UML and architectural description languages carry the semantics they lack, at the price of time and cost. Next, we look at the decisions that produce an architecture in the first place.

5.3 Architectural Design Decisions

5.3.1 A Creative, Iterative Process

The question this section answers: If there is no formula for designing an architecture, what do architects actually do? The answer: they make decisions — a chain of informed choices, each one shaping the next.

Architectural design decisions are the first stage in the architectural design process. Architectural design is a creative process in which you design a system organization that will satisfy the functional requirements and the non-functional requirements of the system. There is no formula for designing the architecture of a system: it depends on the type of system being developed, the background and experience of the system architect, and the specific requirements of the system.

So architectural design is a series of decisions to be made in an iterative manner rather than a linear sequence of activities. A decision made early (say, "client-server") narrows the options for later decisions ("which server processes transactions?"), and later decisions can feed back and force an earlier choice to be reconsidered — and that loop is the iteration. During the process, architects have to make a number of structural decisions that will profoundly affect the system and the development process as well. A poor choice at this stage is the most expensive mistake a project can make, because the architecture is the one artifact that everything else must fit into.

5.3.2 The Fundamental Questions

Based on knowledge and experience, system architects consider a number of fundamental questions while making the architectural design:

Is there a generic application architecture that can act as a template for the system being developed?
How will the system be distributed across hardware, cores, or processors?
What architectural patterns or styles may be used?
What is the fundamental approach used to structure the system?
What will be the strategy to control the operation of the components in the system? The structural model defines the components and their communications and relationships, whereas the control model describes, at runtime, what the behavior of the system is — is it event-driven control or broadcast? The control models will be decided here.
How will the structural components be decomposed into sub-components? This is modular decomposition, as done in object-oriented analysis and design, where you have classes and sub-classes and so on.
Which architectural model, or architectural pattern, or architectural organization, is best for delivering the non-functional requirements of the system?
The most important question: how should the architecture of the system be documented?

What these questions decide, in one line each. The generic application architecture decides how much of a known template can be reused; distribution decides where the system runs; patterns and styles decide which well-tried organization to follow; the structural model decides the components and their communications; the control model decides runtime behavior (event-driven or broadcast); modular decomposition decides how components split into sub-components; the non-functional requirements question decides whether the chosen organization can actually deliver performance, security, safety, availability, and maintainability; and the documentation question decides how the architecture is recorded for the people who must build and maintain it.

Exam note: Expect questions on which architectural choice serves which purpose — and the documentation question is emphasized as the most important one. If asked to list the fundamental questions, be ready to give all eight and to explain what each one decides.

5.3.3 Architectural Patterns and Styles

The architecture of a software system may be based on a particular architectural pattern or style. The terms architectural pattern and architectural style are used interchangeably, though they do have some subtle differences. A typical architectural pattern is a description of a system organization — for example, a client-server architecture pattern, a layered architectural pattern, or a pipe and filter architectural pattern.

Terminology caution: "Pattern" and "style" are often used as synonyms — the earliest book on software architecture used "style" (Garlan and Shaw 1993), and later pattern handbooks used "pattern". The subtle difference is one of emphasis: a style stresses the family of organizations that share structural rules (any layered system), while a pattern stresses a named, tried-and-tested solution with known strengths, weaknesses, and when-to-use guidance. On the exam, treat them as interchangeable with that nuance in mind.

Architectural patterns capture the essence of an architecture that has been used in different software systems, so you should be aware of these common patterns, where they can be used, and their strengths and weaknesses, when making decisions about the architecture of the system. Once you choose one or more architectural patterns or styles for various parts of the system, they capture the essence of an architecture and can be instantiated in different ways to meet the requirements — the pattern is the recipe, and your system is one particular dish made from it.

Garland and Shah, the earliest authors of books on software architecture, point to three core tasks (in the reference literature the names are spelled Garlan and Shaw):

Choose the most appropriate structure — such as client-server, layered, or pipe — that will enable you to meet the system requirements.
Decide a strategy for decomposing system components into sub-components.
Develop a general model for the control relationships between the various components, making decisions about how the execution of components can be controlled.

Notice how these three tasks map onto the fundamental questions of 5.3.2: structure answers "how is the system organized", decomposition answers "how do components split", and the control model answers "who runs when".

Exam note: The pattern-versus-style distinction, with its subtle differences, is a terminology point to keep straight — be ready to define both terms and give one example of each.

5.3.4 Generic Application Architectures and Distribution

Although each software system is unique, systems in the same application domain can have similar architectures that reflect the fundamental concepts of the domain. When designing a system architecture you have to decide what your system and the broader application classes, or application architectures, have in common, and decide how much knowledge from these application architectures you can reuse. Application product lines, such as banking applications built around a core banking architecture with variants that satisfy specific customer requirements, are an example of this — the generic banking architecture is the starting template, and each bank's system is a variant of it.

Distribution is another key decision. For embedded systems and applications designed for personal computers, you do not have to design a distributed architecture for the system — everything can live on one machine. However, most large software systems are distributed systems, in which the system software is distributed across different computers and across geographical locations. The choice of distribution architecture is an important decision that affects the performance and reliability of the system: every network hop adds latency and a new chance of failure, so distribution buys scale at the price of complexity.

5.3.5 How to Document the Architecture

Because of the close relationship between the non-functional system requirements — the non-functional characteristics, or emergent properties, of the system — and the software architecture, the choice of architectural pattern or style and the architectural structure should depend on certain non-functional requirements of the system. And the architecture needs to be documented in a way that was decided during the design phase (see 5.2 and the documentation question in 5.3.2).

Evaluating an architectural design is difficult because the true test of an architecture is how the system will meet its functional and non-functional requirements when the system is in use; however, you can do some evaluation by comparing your design against certain already-existing architectures or generic architectural patterns. This is a comparison of shapes: does my design follow the same structural rules as the proven pattern, and where does it deviate? Deviation is not automatically wrong, but it is exactly where the risk concentrates.

Recap. Architectural design is a creative, iterative set of decisions — template, distribution, patterns, structure, control, decomposition, non-functional fit, and documentation — anchored by the three classic tasks of choosing structure, decomposing components, and modeling control. Next, we see how the non-functional requirements steer these decisions, sometimes against each other.

5.4 Non-Functional Requirements and the Choice of Architecture

The choice of architectural pattern or style and the architectural structure should depend on the important non-functional requirements: performance, security, safety, availability, and maintainability. Each non-functional requirement pushes the architecture in a particular direction, and some of these directions conflict with each other. A requirement is non-functional when it describes how the system behaves (how fast, how secure, how available) rather than what it does.

The tension in one sentence: an architecture is a compromise — the five non-functional requirements pull it in different directions, and the architect's job is to pick the structure that satisfies the requirements that matter most for this system.

5.4.1 Performance

If performance is a critical requirement, the architecture should be designed to localize critical operations within a small number of components that interact closely, with these components deployed on the same device or computer rather than being distributed across a network. This may mean using very few but relatively large components rather than small, functionally independent, fine-grained components.

Why? Because every interaction between components costs time: a local function call is measured in nanoseconds, a network message in milliseconds — about a million times slower. Using larger components, where all the functions are co-located within the same module on the same computer, reduces the number of component communications, because most of the interactions between related system features take place within the same component. You may also consider a runtime system organization that allows the system to be replicated and executed on different processes, so several copies of the system can share the workload.

5.4.2 Security

If security is a very important requirement, a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers and a high level of security validation applied to these layers. Each layer must earn the right to reach the next: a user request to the innermost asset travels through validation and access control at every boundary, so an attacker has to break through several independent lines of defense rather than one.

5.4.3 Safety

If safety is a very critical requirement, the architecture should be designed so that safety-related operations are co-located in a single component, or in a small number of components. This reduces the costs and problems of safety validation, and may make it possible to provide related protection systems that can safely shut down the system in case of a system failure. Validating safety is expensive because it demands formal analysis and exhaustive testing; keeping all safety-critical code in one place means you validate one small area instead of hunting across the whole system.

5.4.4 Availability

If availability is a critical requirement, the architecture should be designed to include redundant components, so that it is possible to replace and update components without having to stop the system. This is typically found in fault-tolerant system architectures for high-availability systems. There are also fail-safe designs, where if a component fails, other components take over from the failed component to help sustain the operations — the system degrades gracefully instead of dying.

5.4.5 Maintainability

If maintainability is a critical requirement — and it is a very important concern in all software, especially enterprise applications that will be used for a long time — the system architecture should be designed using fine-grained, self-contained, functionally independent components. Such components can be readily changed whenever the structure or the implementation has to be changed, without affecting the rest of the system. The producers of the data should be separated from the consumers of the data, and shared data storage, or shared data structures, should be avoided. The modules have to be functionally independent so that their implementation can be changed without affecting the rest of the system. This is the basis for object-oriented design, where you have small functionally independent components — each class is a functionally independent component that has a set of attributes and operations. The change you make stays inside one small class instead of rippling through the system.

The five non-functional requirements at a glance.

Requirement	Architecture it pushes toward	Why it works
Performance	Few, large, co-located components	Fewer component communications, most interactions stay inside one component
Security	Layered structure, critical assets innermost	Each layer boundary is an independent validation barrier
Safety	Safety operations co-located in one component	One small area to validate; protection systems can shut the system down safely
Availability	Redundant, replaceable components	Failed components can be swapped or taken over without stopping the system
Maintainability	Fine-grained, self-contained, independent components	Changes stay local; producers separated from consumers, no shared data storage

5.4.6 Trading Off Performance against Maintainability

There is a tension between performance and maintainability. For performance we use large components rather than fine-grained components; for maintainability we use functionally independent, fine-grained, replaceable components. Using large components improves performance, and using small fine-grained components improves maintainability. If both performance and maintainability are important system requirements, you must find some compromise between them, deciding which architecture to use and which requirement is more important, so that you can achieve both goals to some extent. You can do this analysis by trying out different architectural patterns or styles for different parts of the system — the performance-critical hot path gets the large co-located components, while the rest of the system gets the fine-grained structure that is easy to change.

Compromise, not surrender: a system that optimizes only for performance becomes a monolith nobody dares to touch; a system that optimizes only for maintainability spends so much time moving data between small components that it cannot meet its response-time targets. The architect's job is to find the compromise that keeps both requirements tolerable, not to pick one winner.

Security, meanwhile, is almost always a critical requirement, and you have to design an architecture that maintains security while also satisfying the other non-functional requirements. It is the one requirement that rarely gets to be traded away: a fast system that is insecure, or a maintainable system that leaks customer data, is a failure.

5.4.7 Evaluating an Architectural Design

Evaluating an architectural design is difficult, because the true test of an architecture is how the system will meet its functional and non-functional requirements when it is in use. However, you can do some evaluation by comparing your design against certain already-existing architectures or generic architectural patterns, and evaluating the architecture against them. Systems in the same domain often have similar architectures that reflect domain concepts. Application product lines — say banking product lines or e-commerce application product lines — have a core architecture with variants that satisfy particular requirements, which gives you a yardstick to compare against: if the proven core handles the same class of workload, your variant starts from a position of evidence rather than hope.

Recap. Each non-functional requirement pushes the architecture in its own direction — performance toward large co-located components, security toward layers, safety toward co-location, availability toward redundancy, maintainability toward fine-grained independence — and the final architecture is the compromise between these pulls, with security almost always non-negotiable. Next, we look at the three-stage process that produces the architecture: system structuring, control modeling, and modular decomposition.

5.5 The Architectural Design Process: Three Stages

The architectural design process is an early stage of the system design process, it overlaps with the requirements specification, and it is the link between the requirements specification and the design processes. It is often carried out in parallel with some specification activities, and in it you identify the major system components and their communications, or the way they interact. The architectural design process involves three stages: system structuring, control modeling, and modular decomposition. This is a big chunk of material — the class takes time over it.

Exam note: The three stages — system structuring, control modeling, modular decomposition — and what each one produces are a heavily weighted part of this material. Expect a question asking you to name the stages and say what each one outputs.

5.5.1 System Structuring

In system structuring, the system is decomposed into several principal, or main, subsystems, and you specify the communications between these subsystems. This is where you decide on the decomposition into high-level components and how those components talk to each other.

What this stage produces: a partition of the system into a small number of major subsystems, plus the communications between them — in other words, the answer to "what are the big pieces, and which pieces talk to which?" The output is typically a box-and-line diagram of the kind seen in 5.2, and it is the stage where the chosen architectural pattern (layered, client-server, pipes and filters) shows up first.

The decisions made here are the highest-level decisions of the whole process: which pattern to apply, how many subsystems, and what the boundaries between them are. Everything that follows is refinement of this skeleton.

5.5.2 Control Modeling

In control modeling, a model of the control relationship between the different parts of the system is established: how, at runtime, does the system interact, how do the various components interact? This is where decisions such as event-driven control versus broadcast control are made (see the control model question in 5.3.2).

Two classic control strategies. Event-driven control: the system waits for external events (a button press, a sensor reading, a network message) and each event triggers the component that handles it — typical of interactive and embedded systems. Broadcast control: one component sends a message to all other components, and each decides whether to react — typical of systems where independent components must all stay aware of shared state. The choice matters because it decides which component has the "right to act" at any moment.

The structural model says who exists; the control model says who runs when.

5.5.3 Modular Decomposition

In modular decomposition, the subsystems are further decomposed into modules. This is the object-oriented analysis and design style of decomposition into classes and sub-classes that you are already familiar with.

What this stage produces: the module structure of the system — classes, their attributes, their operations, and their relationships. Where system structuring produces a handful of big subsystems, modular decomposition keeps splitting until each module is a cohesive, manageable unit that one developer or one team can build and test.

Trace — a small library system through all three stages. Start with the goal: a university library system that lends books and keeps records of members.

System structuring: split the system into three subsystems — the circulation subsystem (lending and returning books), the catalog subsystem (searching and describing the collection), and the member services subsystem (managing members and fines). The communications: circulation asks the catalog for book details and asks member services to check a member's standing.
Control modeling: choose event-driven control — each interaction (scan a book, search the catalog, register a member) is an event triggered by a librarian's action; a broadcast channel is also added so that when a book is returned, both circulation and member services learn of it immediately.
Modular decomposition: the circulation subsystem is decomposed into classes — Loan, BookCopy, DueDateCalculator — with operations like lend(book, member) and renew(loan), which in turn call methods on BookCopy and Member.

The trace shows the grain of decision at each stage: three subsystems, then a control strategy, then fine-grained classes.

Common pitfalls.

Skipping control modeling. Teams that jump straight from subsystems to classes produce systems where nobody knows who decides what happens next — control ends up scattered ad hoc through the code.
Mixing the stages. Deciding class-level decomposition while the subsystem structure is still unsettled wastes work, because a changed subsystem boundary invalidates the classes inside it.
Forgetting the overlap with requirements. The process runs in parallel with specification: waiting for a frozen requirements document before starting system structuring delays the entire project for no benefit.

Recap. The three-stage process — system structuring (major subsystems and their communications), control modeling (who runs when at runtime), and modular decomposition (classes and sub-classes) — converts the architecture's skeleton into a buildable module structure. Next, the class returns to the structural models themselves: the layered model and the repository model.

5.6 Structural Models: The Layered Model and the Repository Model

The architectural patterns used to describe system structure are called structural models. They include the layered model, the repository model, the client-server model, and the pipes and filters model. The first two are introduced here; the class returns to them later — the repository model, in particular, appears again in full detail when we look at language processing systems.

5.6.1 The Layered Model

The question this section answers: How do you stop a change in one part of the system from forcing changes everywhere else? One answer: organize the system as a stack of layers, each with a sharply bounded responsibility.

In a layered architecture, the system is organized as a stack of layers, where each layer provides services to the layer above it and uses services from the layer below it. The layered pattern is used whenever the structure of the system should enforce separation between different levels of responsibility.

The layered contract. Layer $L$ may call only the layer directly beneath it, $L - 1$ ; layer $L - 1$ never calls upward. Because every layer depends only on its neighbor below, replacing one layer with a new implementation (as long as its interface to the layer above is unchanged) does not touch the rest of the stack. This contract is what makes separation of concerns enforceable rather than aspirational.

The strongest use described in this class is security: if security is a very important requirement, a layered structure should be used with the most critical assets protected in the innermost layers and a high level of security validation applied to these layers. A request from outside must cross every layer boundary, and each boundary is a place to validate, authenticate, and authorize — so the deeper the asset, the more independent barriers protect it.

Typical information systems can also be structured in a layered format: for example, internal transaction-processing applications can be arranged as layers for user interface, authentication, information retrieval, and transaction management.

Visual intuition — the stack. Picture a vertical stack with the user interface at the top, authentication below it, information retrieval below that, and transaction management at the bottom. The user interface never talks to the transaction management layer directly; it asks authentication, which asks information retrieval, which finally calls transaction management. The transaction management layer, in turn, knows nothing about buttons or screens — only about transactions.

Where the layered model struggles. Clean separation between layers is often hard to achieve in practice — a high-level layer may have to reach past its neighbor down to a lower layer (for example, the user interface reading a setting that only the database layer knows). And performance can suffer: a service request gets interpreted and translated at every layer, so the price of a clean stack is per-layer overhead.

Recap. The layered model organizes the system into a stack where each layer serves the one above and uses the one below, which localizes change and supports security by placing critical assets in the innermost layers.

5.6.2 The Repository Model

The question this section answers: How do components share large amounts of data without each one sending messages to every other? Answer: stop talking — put the data in a shared store that everyone reads and writes.

In the repository model, all components share access to a central store of data, or repository. Components do not communicate directly with each other about shared state; instead they read from and write to the repository, so a change made by one component is immediately visible to the other components. This model is appropriate when several components need to share large amounts of data and when changes made by one component need to be reflected immediately in other components.

The repository contract. Every interaction with shared state goes through the repository — no component holds its own private copy of the shared data, and no component sends the data directly to another. A tool that generates data simply writes it; the next tool that needs it simply reads it. The cost of this simplicity is that all components must agree on the repository's data model.

Visual intuition — the hub. Imagine a wheel: the repository is the hub, and the components are the spokes. Each spoke touches only the hub; no two spokes touch each other. If one spoke changes, every other spoke that reads the hub sees the change on its next read — no message needs to be sent to anyone.

Strengths of the repository model: components can be independent — they do not need to know of the existence of other components; changes made by one component propagate to all; and because all data lives in one place, it can be managed consistently (for example, backed up at the same time). Weaknesses: the repository is a single point of failure, so problems in it affect the whole system; routing all communication through one store can be inefficient; and distributing the repository across several computers is hard because multiple copies of the data must be kept consistent.

A classic setting for the model is an integrated development environment (IDE): a project repository holds the design and source information, and tools such as editors, code generators, design analyzers, and report generators all read and write the shared store — exactly the structure the compiler uses, as we will see in 5.11.

Recap. The repository model makes all components share a central data store so changes propagate automatically; it suits systems where several components must share large amounts of data and see each other's changes immediately — at the price of a single point of failure.

5.7 Structural Models: Client-Server Architecture

5.7.1 The Client-Server Pattern

The question this section answers: How do you provide a service to many users without giving every user their own copy of the service? Answer: keep one copy of the service on a server, and let many clients call it over a network.

The main components of the client-server model are a set of standalone servers that offer services to other components. Examples of servers could be print servers, file servers, or compilation servers. Servers are essentially software components, and several servers may run on the same computer. The servers are accessed by a set of clients that call on the services offered by the servers. There will normally be several instances of a client program executing concurrently on different computers, and the clients and the servers are connected over a network that allows the clients to access the services provided by the servers. Client-server systems are usually implemented as distributed systems connected using the network protocols.

The three parts of the pattern. (1) Servers — standalone software components that offer services, such as a print server (printing), a file server (file management), or a compilation server (compiling programs); several servers may run on the same computer. (2) Clients — programs that call on the services offered by the servers; normally several instances of a client program run concurrently on different computers. (3) The network — the connections that let clients reach the services, which is why client-server systems are usually implemented as distributed systems using Internet protocols.

An important point: client-server architectures are usually thought of as distributed system architectures, but the logical model of independent services running on separate servers can be implemented on a single computer. The pattern is a way of organizing responsibilities, not a law of physics about machines: the same logical design runs on one box or across a data center.

Real-world: Print servers, file servers, and compilation servers are everyday examples of the standalone servers at the heart of this pattern — every office print queue is a print server, and every shared drive is a file server.

5.7.2 How Clients and Servers Communicate

An important benefit of the model is separation and independence. The services and servers can be exchanged or interchanged without affecting other parts of the system, and you can replace or add more services or servers. The clients have to know the names of the available servers and the services they offer, but the servers do not need to know the identity of the clients, or how many clients are accessing their services.

The asymmetry that makes the pattern scalable. All knowledge flows in one direction: clients must know the servers (their names and the services they offer), but servers need not know who their clients are or how many there are. A server can then be exchanged, upgraded, or replicated without any client knowing — and new clients can join without the server having to register them. The moment a server needs to know its clients' identities, this independence is lost.

Clients access the services provided by a server through remote procedure calls, using a request-reply protocol like HTTP, where a client makes a request to a server and waits until it receives a reply from that server.

Real-world: HTTP request-reply is the familiar face of this pattern — every web browser is a client making remote procedure calls over HTTP to a web server. You click (request), the server answers (reply), and the page arrives; from the server's point of view you are just one anonymous caller among millions.

5.7.3 Example: A Film Catalog Service

Worked picture — a film library. A client-server application like YouTube maintains a film library: a catalog of the videos available, organized as a distributed repository spread across multiple catalogs. The structure follows the pattern naturally, with several servers each specialized for one kind of content:

A catalog server holds the library catalog and handles the variety of queries users make — searching by title, actor, or genre — and provides links into the system's information pages.
A video server stores the film and video clips. Video frames must be transmitted quickly and in synchrony but at relatively low resolution, so the video server may compress and decompress video in different formats to keep streams flowing.
A picture server maintains still pictures at high resolution, which is why they live on their own server rather than competing with video streams.
A web server ties the pieces together into the web information system, including an e-commerce part that supports the sale of photographs, films, and video clips.

The client program is simply an integrated user interface, constructed using a web browser, that accesses all of these services; several clients can be browsing and streaming at the same time, each one anonymous to the servers.

The example shows the pattern's payoff: because the media servers are separate services, each can be scaled, replaced, or upgraded independently — add a second video server when demand grows, without touching the catalog server or the clients.

5.7.4 Advantages and Disadvantages

The client-server architecture pattern can be described in a tabular format: description, example, when to use it, advantages, and disadvantages.

Aspect	Client-server
Description	A set of services, each delivered by a separate server; clients are users of these services and access servers to make use of them
Example	A film library with catalog, video, and picture servers; web applications; print and file servers
When to use it	When data in a shared database has to be accessed from a range of locations; because servers can be replicated, also when the load on a system is variable
Advantages	Servers can be distributed across the network; general functionality (like printing) is available to all clients and does not need to be implemented by each client
Disadvantages	Each service is a single point of failure and is susceptible to denial-of-service attacks or server failure; performance may become unpredictable; management problems arise if servers are owned by different organizations

The main advantage of the client-server model is that servers can be distributed across the network. The general functionality of a service is available to all clients and does not need to be implemented by every client — for example, a print service is provided by a server rather than re-implemented by each client.

The disadvantages in detail. Each service in a client-server environment is a single point of failure — if the print server crashes, nobody on the network can print — and it is also susceptible to denial-of-service attacks or server failure: a flood of requests, or a crashed server, takes the service away from everyone. Performance may become unpredictable at times, because it depends on the network as well as on the system itself. And there could be organizational and management problems if servers are owned and managed by different organizations — who pays for the shared server, and who fixes it when it breaks at 3 a.m.?

Exam note: The client-server advantages and disadvantages — distributed servers, shared services, single point of failure, denial-of-service susceptibility, unpredictable performance, ownership problems — are classic short-answer material. Expect to be asked for the tabular description or for the disadvantages list.

5.8 Structural Models: Pipes and Filters

5.8.1 How the Pattern Works

The question this section answers: How do you describe a system whose work is one long sequence of transformations — data in at one end, finished results out at the other? Answer: as a pipeline of filters.

The pipes and filters model is a model of the runtime organization of a system where functional transformations process their inputs and produce outputs. Data flows from one process to another and is transformed as it moves through the sequence. Each processing step is implemented as a transform, and the input data flows through these processes, or transforms, until it is converted into the desired output.

The pipeline contract. Each filter (transform) has exactly one job: read its input stream, pick out the data it can process, transform it, and pass its output downstream. A pipe is the connector between two filters that carries the stream of data. The transformations, or processes, may execute sequentially or in parallel, and the data can be processed by each process or transform either item by item or in a batch, as in batch processing applications.

The strength of the model comes from its uniformity: every filter has the same shape (stream in, stream out), so filters can be combined in any order that respects the data format — the same transformation is reusable in many different pipelines.

5.8.2 Where the Name Comes From: Unix

The name pipes and filters comes from the original Unix system, where it was possible to link various processes, or connect them, using pipes, which passed a text stream of text from one process to another. Systems that conform to this model can be implemented by combining Unix commands using pipes and the control facilities of the Unix shell. The term filter is used because a process, or transform, filters out the data that it can process from the input data stream — that is why it is called the pipes and filters architecture.

Real-world: Chaining Unix commands with pipes in the shell is the direct practical embodiment of this pattern — every filter consumes a stream, transforms it, and passes it on. For example, listing the files in a directory, keeping only the text files, and sorting them is three small filters joined by pipes, each one reusable in other commands.

5.8.3 The Batch Sequential Variant

Variants of this pattern have been used for automatic data processing. When the transformations or processes are sequential and the data is processed in batches, the pipes and filters model becomes the batch sequential model, which is a common architecture for data processing systems like billing systems, where a stream of data is processed. The architecture of an embedded system may also be organized as a process pipeline, with each process executing concurrently in the embedded system — the same pipeline idea, but the filters run at the same time on a continuous stream instead of on one batch after another.

5.8.4 Worked Example: Invoice Processing

Worked example — the invoice processing pipeline. An organization issues invoices to customers. Once a week, the payments that have been made are reconciled with the invoices. For those invoices that have been paid, a receipt is issued; for those invoices that have not been paid within the allowed payment time, a reminder is issued. The system is a simple data-flow pipeline:

Read the invoices. Each invoice enters the pipeline as a record: invoice number, amount, due date.
Read the payments made. Each payment enters as a record: invoice number, amount paid, payment date.
Reconcile and issue receipts. For each invoice matched to a payment, issue a receipt.
Find payments due. For each invoice not paid within the allowed payment time, issue a reminder.
Send the reminders. The reminders stream leaves the pipeline for mailing.

Trace with real data. Suppose the invoices stream contains three invoices — INV-101 for ₹12,000, INV-102 for ₹8,500, and INV-103 for ₹5,000 — and the payments stream contains two payments: ₹12,000 against INV-101 and ₹8,500 against INV-102.

Filter 1 (read invoices) outputs: INV-101 (12,000), INV-102 (8,500), INV-103 (5,000).
Filter 2 (read payments) outputs: PAY-101 (12,000), PAY-102 (8,500).
Filter 3 (issue receipts) matches payments to invoices and issues two receipts: receipt for INV-101, receipt for INV-102. INV-103 passes through unmatched.
Filter 4 (find payments due) sees INV-103 unpaid past its due date and issues one reminder for INV-103.
Filter 5 (send reminders) sends the single reminder.

Final output: two receipts and one reminder. Sense-check: two payments in, two receipts out; one unpaid invoice in, one reminder out — the numbers balance, and each filter touched only the records it owns.

Each step is a filter that takes the incoming stream (invoices, payments, or reconciled data), picks out what it can process, and passes the rest along — the invoice data flows through the sequence and is transformed into receipts and reminders at the end.

Exam note: Expect a question that asks you to describe a batch processing system as a pipes and filters architecture — the invoice processing system is the canonical worked example. Be ready to draw the pipeline and label each filter's input and output.

5.8.5 Strengths and Limits

Strengths. The pipeline is easy to understand — the diagram reads like the business process. Transformations are reusable: the same "find payments due" filter can serve billing, payroll, or any other stream. Evolution is straightforward: adding a new processing stage is just adding one more filter to the chain. And the model can be implemented either sequentially (batch) or concurrently (embedded systems).

Limits — and why interactive systems do not fit. Pipes and filters systems are best suited to batch processing systems, as well as embedded systems where there is limited user interaction. Interactive systems are difficult to model using the pipes and filters architecture, because of the need for a stream of data to be processed. Simple text input and output can be modeled this way. Graphical user interfaces have much more complex input and output formats, and their control strategy is based on events such as mouse clicks or menu selections. It is difficult to implement that control strategy as a sequential stream that conforms to the pipes and filters model — a mouse click is not a stream of data waiting to be transformed; it is an event that can arrive at any time, in any order.

A further practical cost: the format for data transfer has to be agreed between communicating transformations — each transformation must parse its input and unparse its output to the agreed form, which adds overhead and can stop you from reusing components whose data structures do not match.

Recap. Pipes and filters process a stream of data through reusable transforms, shine in batch and embedded systems, and break on event-driven interactive systems; the invoice processing pipeline is its canonical worked example. Next, we step up one level from patterns to application architectures — generic structures for whole classes of systems.

5.9 Application Architectures

5.9.1 Why Application Architectures Exist

The question this section answers: Why do systems that look completely different on the surface keep being built with the same skeleton? Answer: because the businesses behind them have the same shape.

Application systems are intended to meet a business requirement or an organizational need. All businesses of the same type — say e-commerce businesses — have much in common and typically need to provide the same set of services: for example, Amazon, Flipkart, or any other e-commerce company will have a similar architecture. Apart from this, all businesses have certain common organizational functions, like hiring people, issuing invoices, and keeping accounts, and they will use typical business processes and accounting systems. Businesses operating in the same sector will use sector-specific applications — in the e-commerce sector, for example, all e-commerce companies need an architecture to place items and receive orders, deliver items, and collect payment.

These commonalities have led to the development of software architectures that describe the structure and organization of particular types of software systems. Application architectures encapsulate the principal characteristics of a class of systems: for example, real-time systems might have generic architectural models of different system types, such as data collection systems or weather monitoring systems. Although instances of these systems may differ in detail, the common architecture structure can be reused when developing new systems of the same type.

Real-world: Amazon and Flipkart — rival e-commerce platforms with the same shape: place items, receive orders, deliver items, collect payment. The competition is in the details (pricing, logistics, recommendations); the skeleton is shared.

5.9.2 Reuse through Configuration: ERP and Off-the-Shelf Systems

The application architecture may be re-implemented when developing new systems. However, for many business systems, application architecture reuse is implicit when generic application systems are configured to create new applications. We see this in the widespread use of ERP systems and many other commercially available off-the-shelf application systems, like accounting systems and inventory control systems. These systems have a standard architecture and standard components, and the components are configured and adapted to create a specific business application: for example, a system for supply chain management can be adapted for different types of suppliers, goods, and contractual arrangements.

Real-world: ERP systems, accounting systems, and inventory control systems are off-the-shelf products whose standard architecture is configured rather than rebuilt for each customer — supply chain management is adapted per supplier, per good, per contract. The customer pays for configuration, not construction.

This is the economic argument for application architectures: the tenth system of a type costs a fraction of the first, because the architecture is reused wholesale and only the differences are built.

5.9.3 Four Ways to Use an Application Architecture

As a software designer, you can use models of the application architecture in a number of ways:

As a starting point for the architectural design process. If you are unfamiliar with the type of application you are developing, you can base your initial design on the generic application architecture.
To create a design checklist. If you are developing an architectural design for an application system, you can compare it with the generic application architecture and check that your design is consistent with the generic architecture and complete with respect to all the features that are required.
To organize the work of the development team. Application architectures identify stable structural features of the system architectures, and in many cases it is possible to develop these in parallel — you can assign work to group members to implement different components within the architecture.
To assess components for reuse. If you have components that you might be able to reuse, you can compare these reusable components with the components of the generic application architecture to see whether there are comparable components and whether they can be reused in your application.

The fifth, quieter use — a shared vocabulary. Apart from these, application architectures provide a basis for a vocabulary for talking about applications: when discussing a specific application, or trying to compare applications, you can use the concepts identified in the generic architecture to talk about these application types. Two teams that both know the transaction-processing vocabulary can compare their systems part by part instead of describing them from scratch.

5.9.4 Types of Application Systems

There are many types of application systems, and in some cases they may seem very different. However, though the applications may seem dissimilar superficially, many of them have common functionalities deep inside, and they share an abstract application architecture at a higher level. Four types are covered here:

Data processing applications process data in batches — like a billing system or a payment system — without explicit user intervention during the processing. The user is involved at the edges (start the run, collect the output); the processing itself runs unattended.
Transaction processing systems are typically e-commerce applications, reservation systems, and so on. They are data-centered applications that process user requests and update information in a system database. They are the most common type of interactive business system: they are organized in a way that user actions cannot interfere with each other, and the integrity of the database is maintained. This class of systems includes interactive banking systems, e-commerce systems, various booking systems, and typical information systems.
Event processing systems, especially real-time systems, depend on interpreting events from the system's environment — a sensor reading, a control signal, a network message — and reacting in time.
Language processing systems are systems like compilers and interpreters, where the user's instructions are expressed in a formal language like a programming language. The language processing system processes this language into an internal format and then interprets this internal representation.

The two generic application architecture types studied in detail are transaction processing systems and language processing systems — the first because a large share of web-based business software is transaction processing, the second because all software development depends on language processing.

Recap. Application architectures capture the shared skeleton of a whole class of systems, enabling reuse through configuration (ERP, off-the-shelf systems), and giving designers a starting point, a checklist, a team organization, a reuse assessment tool, and a shared vocabulary; the two types studied in detail are transaction processing and language processing. Next: the transaction processing system, component by component.

5.10 Transaction Processing Systems

5.10.1 The Shape of a Transaction Processing System

The question this section answers: How do you let thousands of users update one shared database at the same time, without their actions tripping over each other? Answer: turn every user request into a transaction and process transactions one by one, completely.

A typical transaction processing system has a sequence of operations that satisfies the goal. Users make requests for service that are then processed by a transaction manager.

What a transaction is. From the user's point of view, a transaction is any coherent sequence of operations that satisfies a goal — for example, "find the times of flights from London to Paris". From the database's point of view, a transaction is a sequence of operations treated as a single atomic unit: all of the operations must be completed before the database changes are made permanent. If any operation fails partway through, the database is rolled back as if nothing had happened — this is what guarantees that a failure in the middle of a transaction cannot leave the database inconsistent.

The typical transaction processing system can be organized as four parts that each request travels through in turn:

Input processing — captures the user's request (form entry, card swipe, web click).
Application logic — the application-specific rules that decide what the request means (validate the card, check the balance, select the service).
The transaction manager — usually embedded in the database management system, it creates the transaction, ensures it is properly completed, and signals to the application that processing has finished.
The database — where the persistent data lives and where the committed changes are written.

Users make asynchronous requests for a service, and each request travels through these parts in turn. This structure keeps user actions from interfering with each other and maintains the integrity of the database — the defining property of the class, which includes interactive banking systems, e-commerce systems, booking systems, and typical information systems.

5.10.2 Worked Example: ATM Systems

Worked example — a cash withdrawal from an ATM. Consider a customer withdrawing money from a bank account through an ATM. The transaction processing system can be organized like a pipes and filters architecture, with the system components responsible for input processing. The system is composed of two cooperating software components: the ATM software and the account processing software in the bank's database server. The input and output components are implemented as software in the ATM, and the processing component is part of the bank's database server.

Input (in the ATM): the customer inserts the card and the ATM gets the customer account id; the customer selects a service — withdraw cash — and queries the account.

Process (in the bank's database server): the server validates the card, checks the account balance to see if sufficient funds are available, modifies the balance by the amount withdrawn, and updates the account.

Output (back in the ATM): the ATM dispenses the cash, prints the details, and returns the card.

Why the transaction stays consistent: until all of these steps have been completed — check balance, modify balance, send the command to dispense cash — the transaction is incomplete and the customer accounts database is not changed. If the network dies between "modify balance" and "dispense cash", the whole transaction is rolled back: the customer's balance is untouched and no cash was dispensed, so money is neither lost nor created. Sense-check: the debit and the cash delivery are one unit — you cannot get one without the other.

So the ATM handles the user-facing input and output, while the real processing — the account operations — happens in the bank's database server, reached over the network.

Real-world: Every cash withdrawal from an ATM is a transaction: the ATM software captures input and output, and the bank's database server performs the account processing. The same pattern covers balance inquiries, transfers, and every card payment in a shop.

5.10.3 Layered Information Systems

A variety of information systems can be structured in a layered format. Transaction-processing internal applications could include user interface, authentication, information retrieval, and transaction management, structured as layers — the layered format for typical information system applications described in 5.6.1. The user interface layer only ever talks to the authentication layer, which passes to information retrieval, which finally reaches transaction management — so a user's request is checked for identity and rights at each step before it is allowed near the database.

5.10.4 Worked Example: E-Commerce Systems

Worked example — an Amazon-style e-commerce system. E-commerce systems like Amazon are multi-tiered client-server architectures, with the tiers separating the user-facing web layer from the application logic and from the data storage — the transaction-processing heart of the system. The three classic tiers are:

The web server — responsible for all user communications, with the user interface implemented in a web browser.
The application server — implements the application-specific logic (the shopping cart, pricing, checkout rules) as well as information storage and retrieval requests.
The database server — moves information to and from the database and handles transaction management.

A customer's checkout — placing several items in a shopping cart and paying for them all together — runs as a single transaction: the web server collects the order, the application server applies the business rules, and the database server commits the order atomically. Sense-check: the cart's "add to cart" steps can happen in separate transactions, but the payment step must be one unit, so a partial payment can never be stored.

Why the tiers pay off: using multiple servers allows high throughput — thousands of transactions per minute — and as demand grows, servers can be added at each level to cope with the extra processing involved, without redesigning the architecture.

Recap. Transaction processing systems funnel each user request through input processing, application logic, a transaction manager, and a database, so that concurrent user actions cannot interfere and the database always stays consistent; the ATM walkthrough and the multi-tiered e-commerce system are the two canonical examples. Next, the second generic application architecture: language processing systems, best known as compilers.

5.11 Language Processing Systems

5.11.1 Compilers and Interpreters

The question this section answers: How does a computer turn a formal language — a program, a database command, an XML document — into something it can act on? Answer: a language processing system translates the language into an internal format and then interprets that internal representation.

Language processing systems are systems like compilers and interpreters, where the user's instructions are expressed in a formal language like a programming language. The system processes this language into an internal format and then interprets this internal representation. The best-known language processing systems are compilers, which translate high-level programs into machine code. However, language processing systems are also used to interpret command languages for databases and internal systems, including various markup languages like XML.

The generic architecture. A typical language processing system has two parts: a translator and an abstract machine. The source language instructions define the program to be executed; the translator converts them into instructions for an abstract machine (checking syntax, checking semantics, and generating the instructions); the abstract machine's interpreter then fetches the instructions, executes them — using data from the environment if necessary — and produces the results. If the system is an interpreter, it takes the data and produces the results directly. For many compilers the abstract machine is a real processor and the interpreter is the hardware; for dynamically typed languages, such as Ruby or Python, the interpreter is a software component.

This material builds directly on a compiler design course — the components discussed next should feel familiar.

Real-world: Compilers, command-language interpreters for databases, and processors for markup languages like XML are all language processing systems — every time a database runs a query or a browser parses an XML feed, a language processing system is at work.

5.11.2 The Components of a Compiler

Worked example — the components of a compiler. A typical compiler has a small set of cooperating components:

Lexical analyzer — takes the input language tokens (keywords, identifiers, numbers, operators) and converts them into an internal form.
Symbol table — holds information about the names of entities used in the text being translated: variables, class names, object names.
Syntax analyzer — checks the syntax of the language being translated. It uses a defined grammar of the language and builds a syntax tree.
Syntax tree — the internal structure representing the program being compiled.
Semantic analyzer — uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text (does this variable exist? is this operation type-safe?).
Code generator — walks the syntax tree and generates abstract machine code.

An optimizer may also be present, analyzing and transforming the syntax tree to improve efficiency and remove redundancy from the generated code.

Sense-check of the flow: the source text enters on the left, each component consumes the previous component's output — tokens, then a tree, then checked-and-optimized code — and the final program exits on the right, exactly like a pipeline.

The structure of a compiler can be described in various ways, and it can be organized around a shared data store or as a pipeline — the two classic architectures for it.

5.11.3 The Repository Model of a Compiler

You can model the compiler as a repository model. The important components in the repository are the abstract syntax tree, the grammar definition, the symbol table, and the output definition. These are accessed by the various components: the lexical analyzer, the syntax analyzer, the semantic analyzer, the code optimizer, the code generator, and also the pretty printer and the editor. Each of these tools works on the shared store of intermediate representations rather than passing data directly to each other.

Why the repository fits a compiler. The intermediate representations — the syntax tree and the symbol table — are shared data that many tools need. In the repository model, a syntax-directed editor can check that the syntax of a program is correct as it is being typed, because the grammar definition lives in the repository; a pretty printer can create listings that highlight different syntactic elements, because it reads the same tree. Tools that would otherwise have to pass data to each other instead read and write one shared store.

Exam note: Be ready to label the repository of a language processing system — abstract syntax tree, grammar definition, symbol table, output definition — and the components that access it: the lexical analyzer, syntax analyzer, semantic analyzer, code optimizer, code generator, pretty printer, and editor.

5.11.4 The Pipeline Model and Hybrid Architectures

You can also use the pipeline model of language compilation, because it is effective in a batch environment, where programs are compiled and executed without user interaction. A standard example is the translation of one XML document to another: a stream of XML flows through a chain of transformations and comes out as the target document.

Worked example — XML to XML translation. An organization receives purchase orders as XML documents from many suppliers and must convert them into its own internal XML format. The pipeline model handles this cleanly: one filter parses the incoming XML into an internal representation, the next filter maps supplier-specific fields to the internal names, a third filter validates the result against the internal schema, and a final filter writes the target XML document. Each filter is a small, testable transformation, the document flows through the chain in a batch run overnight, and adding a new supplier format means adding one new conversion filter. Sense-check: every document that enters the chain in one format exits it in the other — nothing leaves the pipeline in a half-converted state.

But the pipeline is less effective when the compiler is integrated with other language processing tools, like an editing system, an interactive debugger, a pretty printer, or a formatting tool. In that situation, changes from one component need to be reflected immediately in other components — the moment you edit the source, the debugger and the pretty printer should see the change. So it is better to organize such a system around the repository, as described above, rather than as a pipes and filters architecture.

The hybrid reality. Even a pipes and filters compiler is usually a hybrid model, with the repository holding the symbol table and the syntax tree while the pipeline carries the compilation stream. The phases of lexical, syntactic, and semantic analysis run sequentially as a pipeline, but they communicate through the shared symbol table — the pipeline is the route, and the repository is the workspace the route passes through.

Recap. Language processing systems translate a formal language into an internal representation and interpret it; compilers can be organized as a repository (shared syntax tree, grammar definition, symbol table, output definition), as a pipeline (effective for batch work like XML-to-XML translation), or as the usual hybrid of both — with the repository winning whenever tools must see changes immediately. Next, the class pulls the whole lecture together.

5.12 What We Covered: The Big Picture

5.12.1 The Core Ideas

Software architecture is a description of how a software system is organized, and the non-functional properties of a system — such as performance, security, and availability — are influenced by the architecture used. Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used, and the ways in which the architecture should be documented and evaluated.

We looked at certain architectural patterns, especially the structural models: the layered model, the repository model, the client-server model, and the pipes and filters model. We also looked at generic application system architectures for transaction processing systems and language processing systems. The three-stage architectural design process — system structuring, control modeling, and modular decomposition — ties the patterns together.

The four structural models at a glance.

Model	Organizes the system as	Best for	Watch out for
Layered	A stack of layers, each serving the layer above	Separation of responsibility, security with innermost assets	Clean separation is hard; per-layer overhead
Repository	Components sharing one central data store	Large shared data with immediate visibility of changes	Single point of failure; agreed data model needed
Client-server	Servers offering services to anonymous clients over a network	Shared services accessed from many locations, variable load	Single point of failure, denial-of-service risk, unpredictable performance
Pipes and filters	A stream of data flowing through reusable transforms	Batch processing and embedded pipelines	Event-driven interactive systems do not fit

The journey of the lecture: first why architecture matters (5.1), then how to represent it (5.2), what decisions produce it (5.3), what forces steer it (5.4), what process builds it (5.5), which patterns shape it (5.6–5.8), and finally which generic architectures whole classes of applications share (5.9–5.11).

5.12.2 Where the Material Continues

The architectural design material continues in the next session, which starts from where this one stops: further architectural patterns and more application domain architectures. The foundation laid here — patterns as reusable organizations, the three-stage process, and the two generic application architectures — is the lens through which the new patterns and domains will be read.

Exam Guidance Summary

The examinable core of this lecture, grouped by topic:

Architectural design fundamentals. Know the definition: architectural design is concerned with understanding how a software system should be organized and designing the overall structure of the system; its output is the software architecture, an architectural model describing the system as a set of communicating components.
Why architecture matters. Architecture affects performance, robustness, distributability, and maintainability; the dominant influence on non-functional characteristics, or emergent properties, comes from the architecture, and architecturally significant requirements are typically non-functional requirements.
Purposes of architecture. Stakeholder communication, systems analysis, meeting critical non-functional requirements like performance, reliability, and maintainability, and providing a compact, manageable description of the system. Expect the purposes to come up in short-answer form.
Architectural design decisions. Architectural design is creative and iterative — there is no formula; it depends on the system type, the architect's background and experience, and the specific requirements. The fundamental questions include the generic application architecture, system distribution, patterns or styles, structural model, control model, modular decomposition, non-functional requirements, and — the most important question — how the architecture should be documented.
Patterns and styles. Pattern and style are used interchangeably but have subtle differences. Be aware of the common patterns, where they can be used, and their strengths and weaknesses. Expect the client-server advantages and disadvantages (distributed servers, shared services, single point of failure, denial-of-service susceptibility, unpredictable performance, organizational and management problems) in short-answer form.
Non-functional requirements and architecture choice. Performance localizes critical operations in a few large co-located components. Security uses a layered structure with critical assets in the innermost layers. Safety co-locates safety-related operations. Availability uses redundant components. Maintainability uses fine-grained, functionally independent components with producers separated from consumers and shared data storage avoided. Performance and maintainability trade off against each other — expect a question about finding the compromise.
The design process. System structuring, control modeling, and modular decomposition are the three stages, and they form a big chunk of this material — expect depth here.
Structural models. Box-and-line diagrams are good for stakeholder discussion but are poor architectural representations because they do not specify the nature of interactions or externally visible properties; formal models use UML and architectural description languages.
Architectural patterns. The layered model, the repository model, the client-server model, and the pipes and filters model are the four structural models to know, with the pipes and filters invoice processing example and the compiler repository example as the canonical worked cases.
Application architectures. The two generic application architecture types studied are transaction processing systems (organized as input processing, application logic, transaction manager, and database) and language processing systems (compilers and interpreters, with translator and abstract machine).

Key Industry Applications

Where each concept of this lecture shows up in real systems:

E-commerce: Amazon and Flipkart are multi-tiered client-server architectures — web server, application server, database server — and every e-commerce business shares the same architecture for placing items, receiving orders, delivering items, and collecting payment.
Banking and ATMs: interactive banking systems and ATM networks are transaction processing systems; the ATM software handles input and output while account processing lives in the bank's database server.
Streaming and catalogs: a client-server application like YouTube keeps its film library as a catalog of available videos, with repositories distributed across multiple catalogs — video, picture, catalog, and web servers each handling their own content type.
ERP and off-the-shelf systems: ERP systems, accounting systems, and inventory control systems are configured rather than rebuilt — supply chain management is adapted for different suppliers, goods, and contractual arrangements.
Microservices and client-server: choosing between a client-server architecture and a microservices architecture is an early decision made while structuring the requirements, with requirements assigned to the client side, the server side, and the middleware.
Unix pipes: the pipes and filters pattern is directly implemented by combining Unix commands with pipes and the control facilities of the Unix shell.
Web communication: clients access server services through remote procedure calls using a request-reply protocol like HTTP — a client makes a request and waits for the reply.
Print, file, and compilation servers are the everyday standalone servers of the client-server pattern.
Billing and payments: billing systems and payment systems are batch data processing applications, and the invoice processing pipeline (receipts for paid invoices, reminders for unpaid ones) is the worked example.
Reservation and booking systems are transaction processing systems alongside e-commerce and interactive banking.
Compilers and interpreters are the best-known language processing systems, translating high-level programs into machine code; language processing also covers command languages for databases and markup languages like XML.
Embedded and real-time systems: embedded systems may be organized as a process pipeline with concurrent processes, and event processing systems interpret events from the system's environment — data collection systems and weather monitoring systems are generic real-time application architectures.

SE Lecture 5 notes · Architectural Design

Software Engineering· postgraduate· 2026-08-15

Sections Breakdown

15.1 Architectural Design: What It Is and Why It Matters

What architectural design is, its place in plan-driven and agile development, architecture in the small and in the large, what a good architecture gives you, and product lines.

25.2 Architectural Models: Box-and-Line Diagrams and Formal Notations

Box-and-line diagrams, their criticisms, and formal notations such as UML and architectural description languages.

35.3 Architectural Design Decisions

Architectural design as a creative, iterative process: the fundamental questions, patterns and styles, generic application architectures, distribution, and documentation.

45.4 Non-Functional Requirements and the Choice of Architecture

How performance, security, safety, availability, and maintainability pull the architecture in different directions, and how they are traded off.

55.5 The Architectural Design Process: Three Stages

System structuring, control modeling, and modular decomposition — the three stages of the design process.

65.6 Structural Models: The Layered Model and the Repository Model

The layered model as a stack of layers and the repository model as a shared central data store.

75.7 Structural Models: Client-Server Architecture

The client-server pattern, how clients and servers communicate, the film library example, and the advantages and disadvantages.

85.8 Structural Models: Pipes and Filters

How the pipes and filters pattern works, its Unix origins, the batch sequential variant, the invoice processing worked example, and its strengths and limits.

95.9 Application Architectures

Why application architectures exist, reuse through configuration, the ways a designer can use them, and the types of application systems.

105.10 Transaction Processing Systems

The shape of a transaction processing system, the ATM worked example, layered information systems, and the e-commerce worked example.

115.11 Language Processing Systems

Compilers and interpreters, the components of a compiler, the repository model, and the pipeline and hybrid architectures.

125.12 What We Covered: The Big Picture

The core ideas of the lecture and where the material continues in the next session.

13Exam Guidance Summary

The examinable core of the lecture grouped by topic.

14Key Industry Applications

Where each concept of the lecture shows up in real systems.

Postgraduate students in Software Engineering

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

5.1 Architectural Design: What It Is and Why It Matters

Must-know: The output of architectural design is the software architecture: an architectural model describing the system as a set of communicating components. The four purposes of architecture are stakeholder communication, systems analysis, meeting non-functional requirements, and a compact manageable description.

⚠️ Top pitfall: Treating the architecture as something that can be refactored incrementally — the architecture must exist before incremental development, and refactoring it forces changes across most system requirements.

Self-check: Name the two levels of abstraction at which software architectures can be designed.

Connects to: Sections 5.2, 5.3, 5.4 of this lecture

5.2 Architectural Models: Box-and-Line Diagrams and Formal Notations

Must-know: Box-and-line diagrams show neither the type of relationships between components nor the components' externally visible properties, and lack semantics — they are fine for discussing high-level requirements but weak for documenting the architecture; formal models use UML and architectural description languages.

⚠️ Top pitfall: Treating a box-and-line diagram as if it documented the architecture: it does not specify the precise nature of interactions, so two teams can build different systems from the same diagram.

Self-check: What does a box drawn inside another box mean in a box-and-line diagram?

Connects to: Sections 5.3, 5.1 of this lecture

5.3 Architectural Design Decisions

Must-know: There is no formula for architectural design; it depends on the system type, the architect's background and experience, and the specific requirements. The most important fundamental question is how the architecture should be documented. Pattern and style are used interchangeably but have subtle differences.

⚠️ Top pitfall: Confusing pattern and style as completely different things: they are interchangeable terms with a subtle difference in emphasis — style stresses the family of organizations, pattern stresses a named, tested solution with known strengths and weaknesses.

Self-check: List the three core tasks pointed out by Garland and Shah (Garlan and Shaw).

Connects to: Sections 5.2, 5.4, 5.5 of this lecture

5.4 Non-Functional Requirements and the Choice of Architecture

Must-know: Performance localizes critical operations in few large co-located components; security uses a layered structure with critical assets innermost; safety co-locates safety-related operations; availability uses redundant components; maintainability uses fine-grained independent components with producers separated from consumers. Performance and maintainability trade off against each other.

⚠️ Top pitfall: Optimizing only for one requirement: a performance-only design becomes an unmaintainable monolith, and a maintainability-only design misses its response-time targets — the architect must find a compromise, possibly with different patterns for different parts of the system.

Self-check: Why does a security-driven architecture put the most critical assets in the innermost layers?

Connects to: Sections 5.3, 5.6 of this lecture

5.5 The Architectural Design Process: Three Stages

Must-know: The three stages are system structuring, control modeling, and modular decomposition: structuring decomposes the system into principal subsystems and specifies their communications; control modeling establishes the runtime control relationships (event-driven versus broadcast); modular decomposition splits subsystems into modules and classes.

⚠️ Top pitfall: Skipping control modeling and jumping from subsystems to classes — control then ends up scattered ad hoc through the code with no clear owner.

Self-check: What does each of the three stages produce, in one line?

Connects to: Sections 5.3, 5.6, 5.7, 5.8 of this lecture

5.6 Structural Models: The Layered Model and the Repository Model

Must-know: Layered model: each layer provides services to the layer above and uses services from the layer below; used to enforce separation of responsibility and to protect critical assets in innermost layers (security). Repository model: all components share a central store and do not communicate directly; used when components must share large amounts of data with immediate visibility of changes.

⚠️ Top pitfall: Forgetting that the repository is a single point of failure and that all components must agree on its data model — a new component whose data model does not fit the schema cannot join the system.

Self-check: Why does a change made by one repository component become visible to the others immediately?

Connects to: Sections 5.4, 5.7, 5.11 of this lecture

5.7 Structural Models: Client-Server Architecture

Must-know: Client-server = set of standalone servers offering services + clients that call them + a network. Clients must know server names and services; servers do not need to know client identity or count. Advantages: servers distributed across the network, general services shared by all clients. Disadvantages: single point of failure, denial-of-service susceptibility, unpredictable performance, organizational/management problems.

⚠️ Top pitfall: Forgetting that each service is a single point of failure: if the one print server fails, the whole organization loses printing, and a denial-of-service attack takes the service away from all clients at once.

Self-check: Why do servers not need to know the identity of their clients?

Connects to: Sections 5.6, 5.10, 5.8 of this lecture

5.8 Structural Models: Pipes and Filters

Must-know: Pipes and filters: functional transformations process a stream of data; each filter picks out what it can process and passes the rest along. Batch sequential model is the variant for billing-style data processing. Strengths: easy to understand, reusable transforms, easy evolution. Limits: interactive systems with mouse-click event control cannot be modeled as a sequential stream.

⚠️ Top pitfall: Forcing an interactive GUI system into the pipeline: graphical interfaces are controlled by events (mouse clicks, menu selections) that arrive in any order, not by a sequential data stream — the pipeline model does not fit.

Self-check: In the invoice processing example, what happens to an invoice that has not been paid within the allowed payment time?

Connects to: Sections 5.7, 5.10, 5.11 of this lecture

5.9 Application Architectures

Must-know: Application architectures capture the common architecture of a class of systems: use them as a starting point for design, a design checklist, a way to organize the development team, a means to assess components for reuse, and a shared vocabulary. The four types of application systems are data processing, transaction processing, event processing, and language processing; the two studied in detail are transaction processing and language processing.

⚠️ Top pitfall: Assuming that because two applications look different on the surface (a billing system and a booking system), they share nothing — many superficially dissimilar applications have common functionality deep inside and share an abstract application architecture.

Self-check: List the four ways a software designer can use an application architecture (plus the vocabulary use).

Connects to: Sections 5.10, 5.11, 5.3 of this lecture

5.10 Transaction Processing Systems

Must-know: A transaction is a coherent sequence of operations treated as a single atomic unit — all operations must complete before database changes become permanent, so failures cannot leave the database inconsistent. The typical structure: input processing, application logic, transaction manager (embedded in the DBMS), and database. The ATM is organized as pipes and filters (input/output in the ATM software, processing in the bank's database server); e-commerce systems are multi-tiered client-server (web server, application server, database server).

⚠️ Top pitfall: Treating a partial transaction as complete: if the network fails between 'modify balance' and 'dispense cash', the transaction must be rolled back entirely — committing half a transaction is how balances and cash go out of agreement.

Self-check: Why must a cash withdrawal be treated as one atomic unit rather than separate steps?

Connects to: Sections 5.9, 5.6, 5.8, 5.11 of this lecture

5.11 Language Processing Systems

Must-know: A language processing system has a translator and an abstract machine: the translator checks syntax, checks semantics, and generates abstract machine instructions, which the interpreter then fetches and executes. The compiler's repository holds the abstract syntax tree, grammar definition, symbol table, and output definition, accessed by the lexical analyzer, syntax analyzer, semantic analyzer, optimizer, code generator, pretty printer, and editor. The pipeline model is effective for batch translation (XML to XML) but the repository wins when tools must see changes immediately; even pipeline compilers are hybrids.

⚠️ Top pitfall: Choosing a pure pipeline for an integrated programming environment: when the compiler is embedded with an editor, debugger, and pretty printer, changes must be reflected immediately across tools, which a sequential pipeline cannot provide — the repository model is the right organization there.

Self-check: Name the four components held in the repository of a language processing system.

Connects to: Sections 5.6, 5.8, 5.9 of this lecture

5.12 What We Covered: The Big Picture

Must-know: Architectural design decisions cover the type of application, the distribution of the system, the architectural styles to be used, and how the architecture is documented and evaluated. The four structural models are layered, repository, client-server, and pipes and filters; the three-stage process is system structuring, control modeling, modular decomposition.

⚠️ Top pitfall: Losing the map: each pattern has a 'watch out for' weakness (single point of failure, per-layer overhead, no fit for interactive streams) — quoting a pattern's strengths without its weaknesses is an incomplete answer.

Self-check: Which two generic application architectures were studied in detail, and where does the material continue next session?

Connects to: Sections 5.1, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.10, 5.11 of this lecture

Exam Guidance Summary

Must-know: The examinable core spans the definition of architectural design and its output (an architectural model of communicating components), the four purposes of architecture, the eight fundamental design questions with documentation as the most important, the three-stage design process, and the two generic application architectures (transaction processing and language processing).

⚠️ Top pitfall: Answering short-answer questions incompletely — e.g., listing client-server advantages without the disadvantages, or the four purposes without explaining one in detail.

Self-check: Which non-functional requirement pushes toward large co-located components, and which pushes toward fine-grained independent components?

Connects to: Sections 5.1, 5.3, 5.4, 5.5, 5.7, 5.10, 5.11 of this lecture

Key Industry Applications

Must-know: Each architectural pattern has a named industry home: multi-tiered client-server in e-commerce, transaction processing in banking/ATMs and bookings, pipes and filters in Unix shell pipelines and billing, repository/client-server hybrids in streaming catalogs, layered structures in information systems, and process pipelines in embedded and real-time systems.

⚠️ Top pitfall: Giving vague application examples ('used in industry') instead of named systems and their concrete architecture.

Self-check: Which architecture do Amazon and Flipkart share, and which parts of it handle transactions?

Connects to: Sections 5.7, 5.8, 5.9, 5.10, 5.11 of this lecture

Previous LectureLecture 04 · Systems Modeling

Next LectureLecture 06 · Architectural Design: Control Models

Was this lecture useful?

Loading comments…

🤖

BitsNotes AI Assistant

Subject Notes Assistant

Configure AI Chat

Choose how to access the chatbot

Have your own API key?

Switch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.

AI Provider Preset

API Endpoint URL (OpenAI-Compatible)

API Key

Model Name

🔑 Enter API key above to fetch live models from provider, or enter model name manually.

Remember key for this session (until tab closes)

OpenAI-Compatible API Support

Choose any provider preset (Gemini, DeepSeek, Kimi, GLM, MiniMax, Qwen, OpenAI, Groq, Ollama, etc.) or enter a custom endpoint URL.

Security & Privacy First

Your API key is sent directly from your browser to your specified provider. BitsNotes servers never store or see your key.