Architectural Views, Layered Architectures, and Architecture Evaluation

This session covers the four classic architectural views and the scenario around them, the decision areas behind each structure, typical layered architectures, responsive design, and the ATAM method used to evaluate an architecture. It begins with the vocabulary an architect needs, continues with the views and how they interconnect, and closes with the trade-off analysis that judges whether a proposed architecture meets its quality goals.

The session builds directly on the previous discussion of quality attributes and architecturally significant requirements. There, we saw what qualities a system must have. Here, we see where those qualities live in a design: each of the four views — logical, process, development, and physical — carries part of every quality goal, and the layered pattern shows how the views look in the most common industrial shape. The session then closes the loop with ATAM, the Architecture Trade-off Analysis Method, which checks whether the finished design can actually deliver the promised qualities before anyone writes production code.

Three threads run through everything that follows:

1. Views — one system, several projections, each serving a different stakeholder.
2. Layers — the everyday layered shape (presentation, business, data) that most enterprise products follow, plus the web techniques (responsive design) that shape the top layer.
3. Evaluation — scenarios, sensitivity points, trade-off points, risks and non-risks: the evidence chain that turns an opinion about an architecture into a justified decision.

7.1 Architectural Views: Purpose and Vocabulary

7.1.1 Stakeholders and the Need for Views

Think of a city. A commuter wants the metro map. A town planner wants the zoning map. An electrician wants the cable layout. The city is one reality, but each profession needs its own projection of it. Software is the same: the analyst asks "what should the system do?", the programmer asks "which file do I edit?", the integrator asks "which process talks to which?", and the hardware engineer asks "which machine runs what?". One diagram that tried to answer all four questions at once would answer none of them well.

So the architect records the system as a set of views. A view is a representation of a set of system elements and the relations among them — not all elements, but those of one particular type. Each view is a projection of the architecture that shows only what one group of stakeholders needs to see, and deliberately hides the rest. Hiding is not a loss; it is the point. A view earns its keep by leaving things out.

This idea is the most fundamental principle of architecture documentation: documenting an architecture means documenting the relevant views, plus a little extra information that applies across views.

7.1.2 The Vocabulary of an Architect

An architect needs a precise vocabulary to describe the parts of a system and how they relate. Vague words produce vague designs and endless arguments; precise words let two people discuss a design and know they mean the same thing. The course material builds this vocabulary from three words: structure, element, and relation.

• A structure is a set of elements together with the relations among them. It is the underlying organisation itself.
• An element is one part appearing in that structure — a module, a runtime component, a processor.
• A relation is a defined link between two elements — "is part of", "depends on", "communicates with", "runs on".

The same system can be described by many structures, and each structure, when documented, gives one view. So the deep pairing to remember is:

• Structure = the underlying reality (the actual set of elements and relations in the system).
• View = a documented projection of a structure (what you draw and hand to stakeholders).

A view is a photograph of the building; the structure is the building. Several photographs can show the same building from different sides, and one wide photograph can capture more than one wing.

7.1.3 Three Kinds of Structures

Every view rests on one of three kinds of structures. Memorise these three names — they organise everything else in this session.

1. Module structures describe the code units and how they are organised. Elements are modules — implementation units such as classes, packages, or layers that each carry a coherent set of responsibilities. Relations are "is part of", "depends on", and "is a". Module structures answer: how is the source code divided up? They are the basis for change-impact analysis: if module X changes, which other modules feel it?
2. Component-and-connector structures describe runtime elements and the connectors between them. Elements are components (principal processing units and data stores — services, servers, databases) and connectors (pathways of interaction — calls, messages, protocols). Relations are attachments: a component's port attaches to a connector's role. These structures answer: what exists while the system runs, and how do the pieces talk?
3. Allocation structures describe how software is assigned to the environment — usually hardware. Elements are software units on one side and hardware units (processors, servers, devices) on the other. Relations are "is allocated to" and "migrates to". These structures answer: which piece of software runs on which machine?

A quick way to hold them: module = code-time, component-and-connector = run-time, allocation = deploy-time.

7.1.4 Trade-offs Shape the Solution

Every stakeholder wants something different: the user wants speed, the security officer wants isolation, the manager wants low cost, the maintainer wants clean code. The architect cannot satisfy everyone at once. Every architectural choice involves trade-offs — gaining one quality usually costs some amount of another. Making the presentation layer talk directly to the database is fast to build but couples the interface to the data schema; separating them through a business layer protects the design but adds a hop that costs response time.

So the architect weighs the competing needs against the goals that matter most for the system at hand, and then proposes a solution that balances them. There is rarely a "perfect" architecture — only a defensible balance, argued from the priorities. This is also why evaluation methods like ATAM (covered at the end of this session) exist: they make the trade-offs explicit instead of leaving them hidden inside the design.

The next sections show the four classic views and how each view is built from one of the three kinds of structures.

7.1.5 The Four Views at a Glance

The four views are the logical view, the process view, the development view, and the physical view. They describe the system from four sides:

This grouping was popularised by the model set down in the classic paper by Philippe Kruchten — often called the "4+1" model, because the four views are tied together by a fifth element: the scenario. The scenario ties the views together so that each quality goal can be traced through the system; it is the "+1" that makes the four views add up to one coherent description.

Real-world connection. Large industrial systems are documented exactly this way. Air-traffic-control vendors, banking platforms, and ERP suites all maintain separate design documents for analysts, developer teams, integrators, and deployment engineers, because each group consumes a different projection. Kruchten's paper came out of his work on large telecom systems at Rational, where the cost of miscommunication between those groups was measured in millions — the views exist because unshared understanding is expensive.

Exam note: the mapping "four views ↔ three kinds of structures ↔ primary stakeholder" is core exam material; be ready to name which structure underlies which view.

7.2 Exam Strategy and Study Advice

7.2.1 The Structure of the Examination

The examiner divides the paper into three questions, and each question has three or four subparts. The subparts carry marks individually, so a partial answer on one subpart still earns some credit. This structure rewards a simple tactic: read each subpart, answer exactly what it asks, and collect the small credits question by question.

Exam note: the paper has three questions with three to four subparts each; partial credit is given per subpart, so never leave a subpart blank — even a partial, correct-on-topic answer earns marks.

7.2.2 A Common Misunderstanding

A frequent misunderstanding among students is that the architecturally significant requirements can be read straight from the problem statement. That is rarely the case. A problem statement tells you what the customer said; it seldom tells you which of those statements will shape the architecture. Many requirements are hidden — implied by the domain, the users, the scale, or the regulations — and must be uncovered before the architecture can take shape.

Think of a doctor diagnosing a patient: the symptoms are stated openly, but the disease behind them must be inferred from knowledge of how bodies work. Requirements work the same way: the statement gives symptoms ("the site feels slow", "we have many branch offices"), and the architect infers the architecturally significant requirements (response-time targets, replication needs) from experience with the domain.

7.2.3 Building on the Previous Session

The earlier session on non-functional requirements is the basis for this one. There we said that quality attributes such as security cannot be decided at the end; they must be considered while the architecture is chosen, because qualities are properties of the whole structure, not features bolted on afterwards. This session uses that previous discussion and turns it into a practical method: the views show where each quality lives in the design, the scenario records how it will be judged, and ATAM (later in this session) checks whether the design delivers it.

Recap in one line: last session defined the goals; this session builds the machinery that traces and tests those goals through an architecture.

7.2.4 Three Kinds of State

The words sound alike, but the software meaning is different. In web applications there are three kinds of state to keep straight:

• View state — the state of the controls on one page (what the user typed, which box is checked), kept so the page can redraw itself after a round trip.
• Session state — the server-side memory that identifies your session between the web page and the server across multiple requests: who you are, what is in your cart, where you were in a workflow.
• Application state — data shared by all users of the application, such as a cached product list.

The professor's parliament joke makes a serious point about vocabulary: an exam answer must use the term in its technical sense. When a student answered "budget session, monsoon session, summer session", the answer failed not because the words were wrong English but because they were the wrong domain. In software architecture, session state means the per-user conversation state between browser and server — typically held in a store keyed by a session token sent back and forth in a cookie.

7.2.5 Discovering the Significant Requirements

"Smelled out" is the honest verb here. Unlike functional requirements ("the system shall print a receipt"), architecturally significant requirements rarely appear as sentences in the problem statement. They hide inside phrases like "our branches are spread across the country" (→ availability and replication needs), "auditors inspect every transaction" (→ security and auditability), or "we run month-end sales" (→ performance spikes). The architect's job is interpretation: read the statement, ask what operational realities it implies, write those implications down as explicit quality-attribute scenarios, and only then choose structures that satisfy them.

This connects straight back to 7.1.4: because trade-offs shape every solution, knowing which requirements are truly significant decides which side of each trade-off the architect protects.

7.3 The Four Views and the Scenario in Detail

7.3.1 The Logical View

The logical view describes the design from the inside: the classes, the objects, and the responsibilities that live in the system. It answers the question what does the system do, and which parts carry which duties? — without saying anything yet about processes or machines. It is the view an analyst uses to understand what the system must do, and it is usually captured with class diagrams (responsibilities and relations) and sequence diagrams (how responsibilities collaborate over time).

UML tools support this view directly: IBM's tool Rational Rose and the open-source StarUML both let you draw class diagrams and sequence diagrams that are the logical view. When an analyst hands you such diagrams, you are looking at functionality decomposed into elements — nothing more, and deliberately nothing less.

7.3.2 The Process View

The process view shows the system in action. It describes the processes, the threads, and the timing behaviour at runtime: which programs run concurrently, how they communicate, where the queues form, and what must finish within what deadline. If the logical view is the anatomy of the system, the process view is its physiology — the same body, seen working.

The process view is built by the integrator, who must ensure that the pieces communicate correctly and finish their work in time. The integrator takes components written by different programmers and makes them cooperate as live processes; timing and concurrency problems (deadlock, missed deadlines, race conditions) surface exactly here, which is why this view belongs to the integrator rather than to any single programmer.

7.3.3 The Development View

The development view looks at the source code. It organises the code into packages and components, and it shows how the work is divided among teams: which team owns which package, in what order the modules can be built, and which versions must stay compatible. The programmer works mostly in this view, because it describes the code units that the programmer writes and maintains day to day.

A useful contrast to remember:

The two views can look similar for small systems but diverge quickly in real projects: one runtime class may be spread over several code modules, and one module may contain many classes.

7.3.4 The Physical View and the ATC Example

The physical view maps the software onto the hardware. It treats the hardware as a black box that we do not open: the view only shows which machines run which parts of the system, and how those machines are connected — it says nothing about what happens inside each machine's electronics.

7.3.5 The Scenario and the PABX Example

The scenario is the written description that specifies how the application functions under a particular set of conditions. A good scenario names the conditions ("a call arrives while all operators are busy"), the actors, and the expected response — so it can be used as a test: run the design through the scenario and see whether the design still stands.

The scenario is tied to each of the four views so a quality goal can be traced through the design: the same "call waiting" scenario appears as objects in the logical view, as processes and message flows in the process view, as packages in the development view, and as boards and lines in the physical view.

7.3.6 Communication Diagrams and the Scenario

Each view can be captured with a diagram type that matches the structure it describes: class diagrams for the logical side, deployment-style diagrams for the physical side, and so on. Communication diagrams show the interactions between objects at runtime — objects as boxes, messages as numbered arrows between them — which makes them a natural fit for walking a scenario through the process/logical side: follow the numbered arrows and you have traced the scenario.

Because the scenario names the exact conditions, each quality goal can be traced from the logical view to the physical view and back. That traceability is the practical payoff of the whole scheme: quality stops being a vague promise ("it will be fast") and becomes a chain of checkable statements ("this responsibility → this thread → this interface → this machine with this capacity").

Real-world connection. Telecom equipment makers document switches and exchanges exactly this way — Kruchten's original paper drew on large telecom projects — and modern equivalents do the same: a video-conferencing product has its logical service responsibilities, its media-processing processes, its code repositories per team, and its data-centre deployment map, each maintained as a separate artefact for a separate audience.

7.4 Views Are Interconnected

7.4.1 The Views Work Together

The four views are not separate pictures; they work together like the circulatory system of the human body. The heart, arteries, and capillaries are different structures, but they carry one blood supply — if one vessel narrows, the whole circulation feels it. In the same way, the four views are projections of one architecture, and a change in any one of them propagates to the others:

• the logical view decides what the elements are (the responsibilities),
• the process view decides how they run (processes, threads, timing),
• the development view decides how they are coded (packages, teams, build order),
• the physical view decides where they live (machines, networks).

Where the analogy breaks: blood flows in one connected loop, while views are linked by mappings you must actively maintain. The mapping from one view to another must be consistent — every element in the process view must trace back to elements in the logical view, and forward to machines in the physical view. A change in one view affects the others through exactly these mappings.

7.4.2 Tracing a Quality Goal Through the Views

To prove a quality goal, the architect traces it through all the views. A quality goal is never "in" one view only — each view carries one facet of it:

This table is worth memorising because it turns "the system should be fast" into four checkable statements. If any link in the chain is missing — say, nobody sized the machine — the goal is unproven, no matter how good the other three views look. The same tracing works for security (responsibility → authentication process → credential-handling package → firewall placement) or availability (recovery responsibility → heartbeat process → redundant module → standby server).

7.4.3 Keeping the Views Consistent

The views must be kept in step. When a decision changes one view, the architect must update the others; otherwise the documentation lies and the teams build the wrong thing. A stale physical view that still shows one server, after the team has split onto three, will mislead every capacity discussion that reads it.

Reviews are the practical tool that catches inconsistencies between the views: a group walks one scenario through all four views and checks that the story matches at every step. Where the trace breaks — an element with no owner, a process with no machine, an interface nobody implemented — there lies the inconsistency.

Real-world connection. This is why mature organisations run architecture review boards: when a bank's payment platform adds a new fraud-check service, the board requires the change to appear coherently in all maintained views before approval, because inconsistent documentation between teams is a leading cause of integration failures in large systems.

7.5 Structures, Views, and Decision Areas

7.5.1 The Architect's Key Decisions

An architect makes decisions that are hard to reverse, so they must be made carefully. Changing a class name is cheap; changing the way the whole system is split into subsystems — after ten teams have built against it — is close to rewriting the system. That is why these decisions belong to architecture at all: architecture is the set of decisions that are expensive to undo.

The two central decision areas are decomposition and assignment:

• Decomposition decides how the system is split into parts — which responsibilities group together into one module or component, and which stay separate.
• Assignment decides where those parts live — on which processor, behind which connector, owned by which team.

A helpful analogy: decomposition is how you divide a kitchen into stations (grill, pastry, plating), and assignment is who works each station and where each station stands in the room. Decide the stations badly and every order jams; decide them well and the restaurant scales to a full house.

7.5.2 Decomposition and Assignment in Practice

Decomposition produces modules and components that can be built separately — separate enough that different people can work on them without stepping on each other, related enough that they fit together into one system. Assignment then places the modules on processors and the components on connectors: this service runs here, talks through that message queue, and is maintained by that team.

The two decisions appear in every kind of structure, so the architect always chooses a decomposition and an assignment even when the words are not used. Drawing a layered diagram? You have decomposed. Deciding the database runs on its own server? You have assigned.

7.5.3 How the Decision Areas Map to the Structures

Each of the three kinds of structures answers a different question:

Notice the pattern: decomposition comes first conceptually (you cannot assign what you have not defined), but in practice the architect iterates — a hardware constraint discovered during assignment often forces the decomposition to be re-cut.

7.5.4 Why the Views Are Not the Structures

A view is a projection; a structure is the underlying reality. The same structure can give several views (one module structure yields both a "decomposition" diagram for managers and a "uses" diagram for developers), and the same view can combine several structures (a single drawing may overlay module groupings with deployment notes). Confusing the two is a common trap, so keep the vocabulary precise.

Concretely: if two teams draw different diagrams of the same system, they may still be describing the same structure — the disagreement is about presentation, not substance. Conversely, two identical-looking drawings can hide different structures. The structure is what the system is; the view is what we say about it.

7.5.5 From the Scenario to Measurements

The scenario drives the evaluation. Each scenario names five things:

• the source — who or what triggers the event,
• the stimulus — the event itself,
• the environment — the conditions under which it happens,
• the artefact — which part of the system receives it,
• the response — what the system must do, and how well.

Example: "source: 500 concurrent shoppers; stimulus: search request; environment: normal operation, peak hour; artefact: search subsystem; response: results within 2 seconds." A scenario written this way can be judged true or false — which is exactly what evaluation needs.

Once the scenarios are written, the architect records measurable qualities such as performance in terms of response times and throughput, and these numbers become the evidence for the trade-off analysis. Vague goals cannot be traded off; measured ones can.

7.5.6 The Tester View and Functional Checks

Functional checks verify what the system does; measurable checks verify how well it does it. The distinction matters because passing every functional test says nothing about whether the system survives load: a checkout flow can be perfectly correct and still collapse when a thousand users arrive at once. The tester needs both kinds of evidence — scenario-based functional passes and instrumented measurements (response time distributions, throughput under load).

Real-world connection. Procurement contracts for large government and enterprise systems routinely reference the architecture document: milestones, penalties, and acceptance tests are tied to the published decomposition and assignment, which is precisely why the professor warns that shared architectures carry legal and commercial obligations.

7.6 Typical Layered Architectures

7.6.1 Layers, Business Logic, and Presentation

A layered architecture arranges the system into horizontal layers, and each layer has a single job. A layer is a logical grouping of components that share one kind of responsibility; interactions mostly happen between neighbouring layers, and upper layers send commands downward while data flows back up.

The two layers that appear in nearly every system are:

• the presentation layer — talks to the user: screens, forms, buttons, validation of what the user types;
• the business logic layer — holds the rules of the application: how an order is priced, when an account may be overdrawn, what counts as a duplicate booking.

Below them usually sits the data layer (7.6.5). The separation matters because each kind of change lands in exactly one layer: a new screen design touches presentation only; a new tax rule touches business logic only. That single-job-per-layer discipline is what makes layered systems maintainable — Microsoft's architecture guide calls the style an effective separation of concerns built on high cohesion within a layer and loose coupling between layers.

7.6.2 Enterprise Software and the Vertical Cut

Enterprise products such as the accounting package, the enterprise resource planning (ERP) suite, and the customer relationship manager (CRM) all follow the same layered shape. Packages like Tally, Oracle, SAP, and Dynamics ship as layered products, and the same vertical cut runs through them: pick any feature — payroll, invoicing, lead tracking — and it cuts vertically through a screen on top, rules in the middle, and data at the bottom.

This is why enterprise products feel so similar to use and integrate so predictably: whatever the business domain, the stack shape is the same, so connecting a CRM to an ERP means connecting presentation-to-presentation flows and data-to-data flows along well-known seams.

7.6.3 Pluggable Components

Good layers are built so a component can be swapped without touching the rest of the system. The architect designs the interfaces first — the named set of operations a component offers — and then plugs a concrete component into the interface. Callers depend only on the interface (the socket), never on the concrete part (the plug).

This is why large products can grow over time: the new component plugs into the same socket as the old one. Replace a tax-calculation engine behind its interface and no caller changes a line. The habit also enables parallel teams: once the interface is agreed, both sides build against it independently.

7.6.4 Exchangeable Components and Caching

When the interface is stable, the components are exchangeable. A caching layer is the common example: the application can exchange a slow data source for a fast one that keeps the popular entries in memory. Distributed memory stores such as Memcache sit between the layers without changing the caller — the business layer asks for "product 42" exactly as before; whether the answer comes from RAM or from the database is invisible above the interface.

The exchange has a cost worth naming: cached data can go stale, so the architect must choose a refresh policy (time-to-live, write-through invalidation). Exchangeability gives you the option to optimise; the policy decides whether the option pays off.

7.6.5 The Database Layer and Shared Data

The bottom of the stack is the data layer. Many applications share a single database, so the data layer must be designed for concurrent access: hundreds of requests arrive together, read overlapping rows, and write competing updates. The database keeps the data consistent while several layers read and write at the same time — through transactions that make multi-step updates all-or-nothing, and locking or snapshot isolation that stops two writers from corrupting each other.

Because every layer above funnels down to this one, the shared database is usually the first bottleneck a growing product meets — which is exactly why the caching layer of 7.6.4 sits in front of it.

7.6.6 The Search Box and Parameterized Queries

The search box in an e-commerce site is a classic source of mistakes. The typical vulnerable page asks for a keyword and builds a query by joining the user's text directly into the command:

SELECT * FROM Products WHERE Name = '" + userInput + "'

An attacker can type something crafted instead of an honest keyword — the lecture's memorable version: something like a toothpaste brand followed by extra SQL characters — and the joined text changes the meaning of the query rather than just the value being searched. Such an attack is called SQL injection: untrusted input smuggles structure (new SQL commands) into a statement that the database then obeys.

Real-world connection. Every ERP deployment in industry runs this pattern: SAP's screens, business rules, and database are separate maintainable units, and e-commerce platforms defend their search endpoints with parameterized statements as standard practice — SQL injection remains one of the most exploited web vulnerabilities precisely because the unsafe pattern is so easy to write by accident.

7.7 Responsive Design and the Architect's Vocabulary

7.7.1 Responsive Design and the Web Stack

Responsive design is the practice of making one web application fit every screen size. Instead of building a desktop site and a separate mobile site, you build one application whose layout reorganises itself to whatever window it lands in.

The web stack that enables it has four parts:

1. the structure language of the browser — HTML — which holds the page's content and structure;
2. the styling language — CSS — which decides how that content is laid out at each size;
3. the scripting language — JavaScript — which changes the page in response to events;
4. a JavaScript framework technique that updates the page without a reload — Ajax, which fetches data in the background so parts of the page refresh without redrawing everything.

Responsive design is part of the architect's vocabulary because the layout must be planned, not patched later. Retrofitting responsiveness onto a fixed-width design usually means rebuilding the front end; deciding up front that every component must flow into any width costs little extra and saves that rebuild.

7.7.2 The Factor That Changed Web Design

The spread of the smart phone is the factor that changed web design. Until phones carried browsers, pages could assume a generous desktop monitor; desktop pages were simply too large for the small screen, so sites had to respond to the width of the device. From that point on, the layout had to be planned for many sizes from the start.

The shift is architectural in the exact sense of this course: it added a constraint (every width must work) that shapes decisions from the first sketch, like a site built on a flood plain shapes where the building may stand.

7.7.3 The Same Application on Every Device

The viewport is the browser window's visible area on the device. "Responding to the viewport" means the CSS checks how wide the window is and picks a matching arrangement: three columns collapse to one, a side menu folds behind a button, images shrink. One URL, one codebase, many arrangements — contrast this with the older two-site approach (m.example.com), which duplicated everything and doubled maintenance.

7.7.4 The Layout Grid and Styling

The styling language provides the grid that keeps the layout consistent across sizes: the page is divided into columns, and components span a chosen number of them. On a wide screen a product card spans 4 of 12 columns; on a phone the same card spans all 12. The modern style sheet standard is CSS3, whose media queries let styles change at chosen widths, and the page structure standard is HTML5. Frameworks such as Bootstrap provide ready-made grids, so teams inherit tested breakpoints instead of inventing their own.

Together they let the same content flow into narrow and wide columns without duplicating the page — the content stays one set of elements; only its arrangement rules vary by size.

7.7.5 Mobile-First Design

So the same page starts from the phone and grows up, which is the opposite of the old desktop-first habit. Desktop-first meant designing richly and then cutting things out for mobile — painful subtraction under pressure. Mobile-first means designing under the strict constraint first (small screen, slow network, touch fingers) and then adding comfort for larger screens — easy addition with room to spare.

Real-world connection. Social networking sites such as LinkedIn and Facebook serve the same application to phones, tablets, and monitors using exactly these techniques, and industry surveys consistently show mobile devices carrying the majority of web traffic — which is why mobile-first became the default posture for consumer web architecture.

7.8 Presentation, Business, and Data Layers in Depth

7.8.1 The Presentation Layer and the Facade

The presentation layer is the face of the system — everything the user sees and touches. Its danger is accretion: logic creeps into screens until the interface layer secretly runs the business. To keep the client simple, the layer often uses the facade pattern, which presents a single, clean interface to the client while the complexity of the rest of the system stays hidden behind it.

The facade works like a hotel concierge: a guest makes one request at one desk ("book me a taxi and a late checkout"), and the concierge coordinates housekeeping, the garage, and reception behind the scenes. The guest never learns the internal phone directory — and never needs to. In software terms, the client calls one tidy operation like PlaceOrder(order); behind the facade, that operation may touch inventory, pricing, and notification services.

Technologies such as WCF (Windows Communication Foundation, Microsoft's service-communication framework) and the server-side page framework fit into this layer: they are the machinery through which clients reach the system.

7.8.2 The Presentation Stack

The presentation stack runs inside the browser and on the server — it is split across both machines:

• Browser side: the structure language (HTML), the styling language (CSS), and the scripting language (JavaScript) render pages and react to user actions.
• Server side: page templates such as JSP pages (JavaServer Pages — HTML templates with server-side code) and the request handler that receives each HTTP request, fills the template with data, and ships the result.

This split lets the same page be served to many clients: the template is defined once on the server, and every browser gets its own filled copy. The browser-side half of this stack is exactly what responsive design (7.7) styles and scripts.

7.8.3 The Business Layer and Its Patterns

The business layer holds the rules and the workflow of the application: how an insurance claim is assessed, which discounts stack, when an order may be cancelled. It uses patterns such as:

• the facade again — here called an application facade — to hide the underlying services behind coarse operations so callers make one call instead of five;
• the transaction to keep several steps as one unit — either all steps commit or none do, so money never leaves one account without arriving in another;
• business workflows for long-running multi-step processes whose steps must happen in order.

The business layer must be independent of the presentation layer so the rules stay correct when the interface changes. Replacing web pages with a mobile app should change nothing about how refunds are calculated — if it would, the rules have leaked into the wrong layer.

7.8.4 Sessions and Transactions

The business layer also manages the session. The session keeps the identity of the user across several requests, so the server remembers who is asking — recall from 7.2.4 that this per-user conversation state is what turns a series of separate HTTP requests into one continuous interaction.

Credentials are handled with deliberate asymmetry: when the user sends credentials, they stay on the server, and the client only carries a token. The password itself is verified once at login; afterwards the browser presents just the session token, so a stolen cookie reveals a key, not the vault. Communication with the server is secured end to end over the secure channel provided by SSL (Secure Sockets Layer — the encryption protocol behind https://), so tokens, credentials, and business data cannot be read on the wire.

7.8.5 The Data Layer and Database Access

The data layer is the bottom of the stack. It talks to the database through standard interfaces such as ODBC (Open Database Connectivity — a cross-language database API) and JDBC (Java Database Connectivity — the Java equivalent), and it can use the embedded-SQL variant SQLJ, which lets SQL statements sit directly inside Java source code with static checking.

A common refinement is the object mapping approach (object-relational mapping): the code works with objects instead of rows, so a Customer object in memory maps transparently to a CUSTOMERS table row, and developers manipulate objects while the mapping handles the SQL.

Because these interfaces are standard, the web server — such as Apache — talks to the data layer through the same calls whether the data lives on the same machine or on a separate database server. That is layers vs tiers from 7.6.1 in action: moving the database to its own tier changes deployment, not code.

Real-world connection. This is the exact shape of Microsoft's application architecture guidance and of countless enterprise stacks: WCF facades exposing business services, JSP/ASP.NET page frameworks serving browsers, and JDBC/ODBC bridges into shared databases — the same vertical cut seen in 7.6, now with its component types named.

7.9 ATAM: Architecture Trade-off Analysis Method

7.9.1 Why Evaluate the Architecture

The architecture is chosen early, and a bad choice is expensive to undo — recall from 7.5.1 that architectural decisions are precisely the hard-to-reverse ones. So the evaluation must happen before the system is built, so the trade-offs are visible while changes are still cheap: changing a diagram costs an afternoon; changing a deployed system costs months.

ATAM — the Architecture Trade-off Analysis Method — is the method that makes this evaluation structured and repeatable. It was developed at the Software Engineering Institute and has been used for over a decade in domains from automotive to financial to defence systems. Its key design property: evaluators need not be familiar with the architecture or its business goals, the system need not yet be constructed, and there may be a large number of stakeholders.

7.9.2 The Inputs and the Proof

ATAM starts from the quality goals and the scenarios that express them — the same scenario form met in 7.5.5 (source, stimulus, environment, artefact, response). The method produces evidence that the architecture can meet those goals: for each important scenario, the architect walks through the design and shows which decisions carry it.

This evidence is the proof that the design will work, so the stakeholders can see the reasoning instead of trusting a promise. "The system will be available" is a promise; "the heartbeat detects a failed server within two seconds because of this watchdog decision" is proof — checkable, debatable, recordable.

7.9.3 The Review Panel and Peers

The evaluation is done by a team of reviewers, and the review includes the peers of the architect. Three groups participate:

• the evaluation team — three to five outsiders with defined roles (team leader, evaluation leader, scribes, questioner), recognised as competent and unbiased;
• the project decision makers — the people empowered to speak for the project and mandate changes; the architect always participates;
• the architecture stakeholders — developers, testers, integrators, maintainers, users whose work depends on the architecture.

Because the reviewers are independent, the analysis is honest: outsiders are not afraid to raise sensitive problems that insiders have learned to live with. The peer review also spreads the knowledge, because the same method can then be applied to the next project — participants leave having internalised scenario thinking and trade-off analysis.

7.9.4 Trade-offs Between Quality Attributes

The heart of ATAM is the trade-off between quality attributes. Improving one quality often weakens another: more redundancy raises availability but costs money and sync time; tighter security adds authentication steps that hurt usability; caching speeds reads but risks stale data. The method's job is to name the points where the architecture is sensitive:

Classic example from the method's own case material: the frequency of heartbeat messages between servers determines how fast a failure is detected (availability), but higher frequency consumes processing time and network bandwidth (performance). The heartbeat frequency is a sensitivity point for fault-detection time and a trade-off point between availability and performance.

7.9.5 Risks and Non-risks

The output of the analysis is a list of risks and non-risks. A risk is an architectural decision that might violate a quality goal under the stated requirements; a non-risk is a decision that, upon analysis, is deemed safe. Related risks are grouped into risk themes — systemic weaknesses such as "backup capability gets not enough attention" — and each theme is tied back to the business goal it threatens.

The stakeholders can then respond in exactly three ways to each risk: accept it knowingly, change the choices, or lower the goals. ATAM does not decide for them; it makes the decision an informed one.

7.9.6 The Role of the Scenario in ATAM

ATAM closes with the scenarios that drive the decision. The team does the scripting of the scenarios, the utility tree ranks them, and the analysis shows which ones put the architecture at risk.

The utility tree works top-down: quality attribute → attribute refinement → prioritised scenario leaf, e.g. Performance → latency → "search returns results in under 2 seconds for 500 concurrent users (High importance / High difficulty)". Scenarios ranked most important get analysed first, because analytical time is limited.

Real-world connection. ATAM evaluations are used in industry to review architectures before large investments — avionics programmes (such as the Rockwell Collins case studies in the course readings) and battlefield control systems have used it to surface availability and modifiability risks while they were still cheap to fix, and banks apply the same discipline before committing hundreds of developer-years to a platform.

Exam Guidance Summary

• The paper is divided into three questions, each with three or four subparts; answer every subpart because partial credit is given per subpart. A memorized answer that ignores the asked subpart earns nothing — read first, then answer what was asked.
• The four views and the scenario are the core of the examination; know the logical, process, development, and physical views, which stakeholder uses each (analyst, integrator, programmer, system engineer), and the structure each one rests on (module, component-and-connector, allocation).
• The layered pattern is part of the midterm syllabus; practise drawing the presentation, business, and data layers and explaining the flow of a request through them — including where the facade, session, and transaction sit.
• Be aware of responsive design; the examination may ask how the same application is served to phones, tablets, and monitors. Answer with one application responding to the viewport (HTML5 + CSS3 grids + Ajax), designed mobile-first.
• ATAM continues in the next session; expect to apply the trade-off analysis to a small case and to name the risks and the non-risks. Revise the chain: scenarios → utility tree → sensitivity/trade-off points → risks/non-risks.
• Keep the vocabulary precise: structure versus view, decomposition versus assignment, sensitivity point versus trade-off point. Examiners award marks for using these terms in their exact technical senses.

Key Industry Applications

• Enterprise resource planning suites such as Tally, Oracle, SAP, and Dynamics follow the layered architecture, with a presentation layer, a business logic layer, and a data layer — the same vertical cut through every feature, which is what makes these products modular and integrable.
• E-commerce sites protect their search boxes with parameterized queries so that a crafted keyword cannot change the meaning of the query — the standard defence against SQL injection, one of the most commonly exploited web vulnerabilities.
• Social networking sites such as LinkedIn and Facebook use responsive design so the same application serves the phone, the tablet, and the monitor — one codebase responding to the viewport instead of parallel mobile and desktop sites.
• Mobile applications are often written once in a cross-platform framework such as React Native, and the server side can be built on a runtime such as Node.js — an example of exchangeable components behind stable interfaces: swapping the client technology leaves the layered server untouched.
• The ATAM evaluation is used in industry to review architectures before large investments — in avionics (Rockwell Collins), defence systems, and banking platforms — so risks are found while changes are still cheap.

Where this fits in the field: every application above is an instance of this session's three threads at work — views to communicate the design to different stakeholders, layers to organise it, and scenario-based evaluation to justify it. An architect who can draw the four views of a system, place its features along the layered vertical cut, and defend the design with ATAM-style evidence is practising exactly what these industry systems demand.