Software Architecture

What Software Architecture Is exam

Weeks 3 to 9 of the course designed objects one at a time with GRASP and the GoF patterns, almost all of them in the application logic. That leaves a bigger question unanswered: how do the large pieces of a system fit together, and which early choices will be painful to undo? Architecture is the name for that large-scale view.

One colour code runs through every layer diagram on this page, so you can tell at a glance where something lives: UI, Application, Domain, Technical Services and Foundation or external.

Two definitions that fit together

Larman's definition talks about decisions, so it is natural to ask what the decisions are about. The lecture names four decision areas, plus the overall architectural style that guides them. The figure lays them out with the question each answers and an example from the NextGen point-of-sale (POS) system, the textbook's running example.

Architectural decisions, and why they are hard to change exam

An architectural decision is a large-scale or fundamental design choice. Typical examples are which layers and subsystems exist and how they communicate, whether to buy or build, which application server or database to use, where the system is deployed, and how failover works. What makes these different from ordinary design choices is that they are hard to change later, for four reasons.

Because the decisions are so costly to reverse, architectural factors must be identified early, during Unified Process (UP) inception and early elaboration, and the rationale must be recorded in technical memos (§8.5) so that future maintainers know why a choice was made before they change it. Larman gives two requirements that become costly if left until late: "must support English, Chinese and Hindi" and "500 concurrent transactions at one-second average response". Neither can be bolted on at the end: one touches every screen and string, the other the whole deployment.

Why architecture matters: the two cartoons

The lecture (slide 6) makes the point with two cartoons. In the first, a team designs from a partial set of requirements and ends up with an unstable, bolted-on structure. In the second, a team builds the pieces (data, API, cache, security, UI) without focusing on the business logic, and then finds that the business-logic piece does not fit. Architecture guards against both failures: it brings in the high-impact requirements early and keeps the business logic at the centre.

Logical architecture versus deployment architecture

An architecture can be described from two angles, and keeping them apart avoids a classic exam mistake. The logical architecture is how the software classes are organised into packages, subsystems and layers. It is called "logical" because it makes no decisions about processes, operating systems or physical computers. Those belong to the deployment architecture, which places the software on processes and physical nodes, drawn with UML deployment diagrams (§8.9).

This also explains where Week 10 sits in the course. Weeks 3 to 9 focused on objects in the application logic (domain) layer, through GRASP and GoF (Part IV, Part VI). Week 10 takes the holistic view and asks how the domain layer fits with the UI and technical-service layers.

Architectural Analysis exam

If architectural decisions are expensive to reverse, you want to know before you make them which requirements will push the design around. Architectural analysis is the activity that finds those requirements, works out how much they vary and how much they matter, and then resolves them. Q6.1 asks you to describe it, so learn the vocabulary in this section precisely.

So architectural analysis is a specialisation of requirements analysis, focused on the requirements that strongly influence the architecture. In UP terms it covers two halves: architectural investigation (the identification) and architectural design (the resolution). Keep both halves in mind; an exam answer that only identifies factors and never resolves them loses marks.

Variation points and evolution points

Besides the architecturally significant requirements themselves, the analysis looks for two kinds of variation, because variation is what forces you to design in flexibility. The difference between them is simply whether the variation is in today's requirements or only a guess about tomorrow.

Why architectural analysis is important (Larman's three reasons) exam

Q6.1 asks why the analysis matters, and Larman gives exactly three reasons. Learn them as a set, and in the exam give each one a concrete example from the scenario.

Architecturally significant requirements

Any FURPS+ category can be a factor, including schedule, skills and cost. Larman's example is a project with a tight schedule and limited skills but enough money: that combination favours buying or outsourcing over building in-house. In practice the strongest influences tend to come from Functionality, Reliability, Performance and Supportability, and from the "+" categories Implementation and Interface. Usually it is the non-functional quality attributes, more than the functional requirements, that give an architecture its particular character. Many factors are also constraints, for example "must run on Linux" or "third-party component budget is X".

FURPS+ (from Part I) doubles as a checklist: walk through its categories and, in each one, look for requirements with architectural impact. The figure lists the typical finds.

The lecture also gives its own lists of examples. Most of the functional ones are cross-cutting services that many features use, and that is exactly why they shape the architecture: you cannot add a printing or auditing service to one class at a time.

How one answer can change the design

The lecture (slide 12, Larman §33.3) shows why these requirements matter with four NextGen questions. Each can be answered either way, and the answer changes the design significantly.

• Reliability and fault tolerance. If a remote service such as the tax calculator fails, may the POS fail over to a local service? If so, is the local service identical or simplified?
• Adaptability and configurability. To sell to many retailers whose business rules differ, can the retailers change the rules themselves? Should the POS be configurable, or customised by programmers for each sale?
• Branding. Retailers want their own brand in the UI. Can the branding be changed without code changes? (This is the Windows XP lesson again.)
• Licensing cost. A commercial database that charges 2% per sale gives speed and robustness. Is it worth that, compared with a less robust free one?

Justifying that a requirement is significant: WIDEST exam

Q6.1 asks you to justify why your two requirements are architecturally significant. "It is important to users" earns nothing; the marker wants to see why the architecture changes. Give at least three of the reasons below and tie each one to the scenario. The mnemonic WIDEST is the study guide's own, not the course's.

By contrast, "the default font size is 12 pt", "record the patient's date of birth" and "the delete button is red" are not architecturally significant. They are local and cheap to change, and they are handled inside one class or one screen. Run them through WIDEST and none of the six letters applies.

Practice: the lecture's LMS poll

The lecture polls the class on which requirements for a new learning management system (LMS) are architecturally significant. The slides give no answer, so the sort below is the guide's reasoned one.

The process: two common steps exam

The analysis happens in early elaboration, although some factors were already recorded during inception: in the Supplementary Specification, in the Special Requirements and Technology Variations sections of the use cases, and in Open Issues. From there, the work has two common steps. Step through the loop below.

Priorities used in resolving factors

Not every factor can win. Larman (§33.7) and the lecture (slide 14) give a fixed order of priority, and the Priority for success column of the factor table should reflect it.

Four themes of architectural analysis

The lecture sums the activity up in four themes (Larman §33.8). They are a good checklist for the "describe architectural analysis" part of Q6.1.

Architecture in the UP: iterative, not waterfall

Quality Scenarios and the Factor Table exam

"The system will be easy to modify" sounds like a requirement, but nobody can ever prove it has been met, so it gives the architect nothing to design against. A quality scenario fixes that by making a quality requirement measurable, or at least observable, so that it can be tested. The factor table then collects each factor, its scenarios and everything else you need to know about it in one place.

The anatomy of a quality scenario

A few rules make a scenario worth writing.

• A scenario is only valid once it is testable, which means fully specified. Vague words like "most" and "average" must be defined.
• State the environment, such as production or normal load, because a test in a lightly loaded development environment proves little.
• Pick your battles. Write scenarios only for the make-or-break qualities, and have a plan to actually test them. Examples are fast transactions under high load for an airline reservation system, and failover to local services for NextGen.

The architectural factor table

Once you have factors and scenarios, you need somewhere to record them alongside their variability, impact, priority and risk. That is the factor table. In the UP it lives in the Supplementary Specification, with the factors grouped under FURPS+ category headings such as Reliability—Recoverability. It has six columns.

The course's worked example (NextGen POS)

The lecture (slide 16) and Larman's Table 33.1 fill in one complete row under the heading Reliability—Recoverability. Read across it to see how each column is filled in. The next three rows are Larman's other NextGen factors from Table 33.2, useful as patterns to copy; the guide gives only the parts shown for those.

Two details reward a second look. The wireless-terminal row is an evolution point written as a factor: its scenario ("no change to the non-UI layers") is really a demand for Model-View Separation and layering (§8.7). And the legal row shows how difficulty depends on the decision you expect: building a tax engine would be hard, but buying one makes the risk low.

Exam-style rows for the past-paper scenarios

These two rows show what a factor table looks like in a Q6 answer, using the 2021 scenarios worked in full in §8.10. The details are invented but plausible, which the exam explicitly allows.

Resolving Factors: Architectural Design Principles

The factor table tells you what the architecture must cope with; it does not tell you how. Resolving the factors is where the actual design happens, and Larman is honest that it is partly a craft. This section collects the principles and the standard mechanisms you will reach for, especially when you fill in the Solution box of a technical memo.

Larman separates the two halves of the work. The science is collecting and organising the factors, which is what the factor table does. The art is making skilful choices that resolve them, weighing trade-offs, interdependencies and priorities. Note that one decision, and so one memo, may resolve several factors at once.

The same principles as object design, at a larger grain

The principles that guided object design in Part IV still dominate: Low Coupling, High Cohesion and Protected Variations (achieved through interfaces, indirection, service lookup and so on). The difference is that at this level they apply between subsystems, applications and processes rather than between small objects, and there are extra mechanisms available, such as messaging services, application servers and configuration files.

One idea is especially architectural: bind late where change is expected. At this level, protected variation often means choosing the concrete implementation at configuration time or run time instead of fixing it in the code. Larman's mechanisms for this are shown below.

Separation of concerns and cross-cutting concerns exam

Separation of concerns is the large-scale way of thinking about low coupling and high cohesion: each "thing" deals with one concern. Application-logic objects contain only application logic, the persistence subsystem only persistence, and the security subsystem only security.

A cross-cutting concern is one with wide application or influence across the system, such as persistence, security, logging and auditing. If you weave such a concern into every domain class, those classes lose cohesion and gain coupling, so it needs handling separately.

The lecture (slide 39) and Larman (§33.7) give three techniques for handling a cross-cutting concern. Know all three by name; the first is by far the most common.

Under- versus over-engineering

Evolution points call for judgement, because protecting against change costs effort now. Designing for every speculative evolution point is expensive and often wrong: over-engineering. Ignoring a likely one can be disastrous: under-engineering, of which Y2K is the classic case. Larman's rule for deciding is to estimate what the change would cost later, when it is actually needed.

A menu of architectural mechanisms

This table pairs each common type of factor with the solution typically used for it, and links each solution back to the patterns of Part IV and Part VI. When you write the Solution box of a memo, find the row that matches your factor and draw on it.

Technical Memos exam

An architectural decision that nobody wrote down is a trap for whoever maintains the system next: they see an odd design, "simplify" it, and reintroduce the problem it solved. A technical memo prevents that by recording each decision together with its reasons. Q6.2 asks you to write one, so this section is worth knowing in detail.

The motivation and the rejected alternatives are the most valuable parts. When a future architect needs to change the system, they need to know why this approach was chosen and why the others were rejected, so they can reconsider those alternatives intelligently. The exact format is not important; record whatever helps a future reader make an informed change.

Structure: textbook versus exam

Larman and the lecture give a memo seven parts; the 2021 exam answer boxes have only five. The figure shows how they line up, and where the two "missing" parts go.

What good content looks like in each box exam

The marks reward a reasoned architectural argument. For each box, here is the difference between a good answer and a weak one.

The course's worked memo (NextGen POS)

The course's example memo resolves the recovery factor from the factor table in §8.3. Before reading it, look at the design it describes: a Smart Proxy stands in for each remote service, so the rest of the POS never knows whether it is talking to the real remote service or a simplified local stand-in.

Notice how the motivation does the real work: it ties the solution to a business goal (no lost sales, a selling point), explains each limit (small cache, no local tax calculator) by a cost, and names the evolution point it keeps open. Larman's two other memos show how short a good memo can be.

Logical Architecture and Layers

A system with hundreds of classes needs a large-scale shape, or every class ends up depending on every other and a change anywhere ripples everywhere. The logical architecture gives it that shape by grouping classes into packages, subsystems and layers, and the most common shape by far is the Layers pattern.

A logical architecture does not have to be layered, but layering is by far the most common choice. Larman calls it the Layers pattern (also known as Layered Architecture).

The common layers of an information system

Larman's Figure 13.4 (lecture slide 25) lists the layers commonly found in an information system, from the most application-specific at the top to the most general at the bottom. Each goes by several names, and you should recognise them all.

Strict versus relaxed layering

Layered architectures come in two kinds, depending on how far down a layer may call. Know which one information systems use; the exam likes this distinction.

Guidelines for designing with layers exam

1. Organise the large-scale structure into distinct, cohesive layers, running from application-specific at the top to general, low-level services at the bottom.
2. Keep a separation of concerns. UI objects do only UI work: windows, widgets and capturing events. Domain objects do only application logic, such as calculating totals and taxes or moving a game piece. So there is no application logic in UI objects, and domain objects don't trap mouse or keyboard events.
3. Collaboration and coupling go from higher to lower layers. Avoid coupling from lower layers to higher ones; where upward communication is unavoidable, use Observer (§8.7).
4. Don't show external resources as the bottom layer (Larman Fig. 13.7). See the pair of diagrams below.
5. Name domain-layer classes after the domain model (see "Domain layer versus domain model" below).

Problems that layers solve, and their benefits exam

Each benefit of layering is the cure for a specific problem, so learn them as pairs.

Contraindications. Layers are not free. Extra layers of indirection can hurt performance, for example in a graphics-intensive game. And layers are not universal: Pipes and Filters suits processing through a changeable series of transformations, such as image processing, although even then the individual filters can be built with layers.

Other layer issues

• Is the Application layer optional? Yes. NextGen iteration 2 has none; instead Register (the GRASP Controller) plays the role. Add one when there are multiple UIs (Application objects then act as Adapters and Facades for each UI), when the system is distributed with the Domain on a server shared by many clients so that session state must be kept, when the Domain layer cannot or should not keep session state, or when there is a controlled workflow of windows or pages.
• Fuzzy membership. Is something Technical Services or Foundation? Domain or Business Infrastructure? Don't agonise over it: the lower two can be lumped together as "Infrastructure".
• What crosses layers? In a single-process desktop application, domain objects (Sale, Payment) can be visible to the UI and passed to Persistence. In a distributed system, the UI usually receives serializable copies of domain objects, known as data holder or value objects.
• Is coupling to Technical Services and Foundation dangerous? No, because they are stable. Coupling only hurts when it targets unstable variation or evolution points.

Layers versus partitions versus tiers exam

These three words are easily confused, and "tier" is genuinely ambiguous. The picture separates them.

The classic three-tier architecture dates from the 1970s and was popularised in the 1990s. Its tiers are Interface → Application Logic → Storage. The key point is a distinct middle tier of application logic, so that windows forward requests instead of doing the processing themselves. It was intended logically, so the three tiers could run on 2 nodes or on 3. A two-tier design, by contrast, puts the application logic inside window definitions that read and write the database directly, in the style of Visual Basic and PowerBuilder.

Finally, keep the logical and deployment views apart. Layers are a logical view: all of them might run in one process on one device (a PDA application) or be spread across many servers (a large web application). It is the deployment model (§8.9) that maps them to nodes.

MVC and layers

MVC began as a small-scale Smalltalk-80 pattern, in which models are data objects, views are widgets and controllers are event handlers. At the architectural level the term maps onto layers, as shown.

Domain layer versus domain model: a lower representational gap exam

Domain objects are software objects that represent things in the problem domain and hold the related application logic, such as a software Sale that can calculate its total. Because the application-logic layer is built from such objects, it is more accurately called the domain layer. The alternative, one big class holding all the logic, works, but it is a maintenance nightmare and isn't object-oriented thinking.

Keep two similar-sounding terms apart. The domain model (analysis, conceptual perspective; see Part II) is a picture of noteworthy real-world concepts. The domain layer (design, software perspective) consists of software classes. They are not the same thing; what links them is inspiration.

Model-View Separation and Connecting the Layers exam

Layering says the UI sits above the domain, but it does not say how the two may talk. Two questions need answers: what visibility should other packages have to the UI layer, and how should non-window classes communicate with windows? The Model-View Separation principle answers them, and three patterns you already know (Controller, Facade and Observer) do the actual connecting.

The principle

Why bother? Following the principle keeps the models cohesive and focused on domain processes, and lets the UI and the model be developed separately. Changes to UI requirements then have minimal impact on the domain. New views can be attached easily, and several simultaneous views of one model are possible, such as a table and a chart. The model can run without any UI at all, for batch or message processing, and it is easy to port to another UI framework.

The legitimate relaxation: Observer

Sometimes the domain really must tell the UI something, for example that the sale total has changed. The principle allows this, but only through an interface such as PropertyListener. The domain object doesn't know the receiver is a window; it only knows the receiver implements the interface. This is the Observer pattern from Part VI, used architecturally.

In Java, the UI class is deliberately thin: it handles events and delegates, and the only thing it does with an event from the domain is display it.

// UI layer: thin. It handles events and delegates; it contains no application logic.
public class ProcessSaleFrame extends JFrame implements PropertyListener {
    private final Register register;           // domain-layer controller (GRASP Controller)

    private void onEnterItemClicked(ItemID id, int qty) {
        register.enterItem(id, qty);           // the SSD system operation, delegated downward
    }

    public void onPropertyEvent(Object source, String name, Object value) {
        if (name.equals("sale.total")) totalField.setText(value.toString()); // display only
    }
}

Both directions in one interaction

Step through one enterItem to see the whole round trip: calls travel down from UI to controller to domain, and the update travels back up through the listener interface.

Connecting the layers: SSDs, Controller, Facade, Observer

The two architectural design decisions are "What are the big parts?" and "How are they connected?" The Layers pattern answers the first; GRASP and GoF patterns answer the second.

The first link is with the SSDs you already know from Part II: SSD system operations are the calls from the UI layer into the Application or Domain layer. The SSD hides the UI objects, but in reality a UI object such as ProcessSaleFrame captures the actor's input and forwards makeNewSale(), enterItem(id, qty) and endSale() to a domain object such as Register.

The object that receives these system operations is the Controller (GRASP), the first object beyond the UI. It can be a facade controller such as Register, which represents the whole system, or a use-case or session controller such as ProcessSaleSessionFacade in an Application layer. Once there are many use cases, or the system is distributed, session facades keep per-client session state.

For downward access to a subsystem, the usual pattern is Facade (GoF). Clients talk to one public facade, such as PersistenceFacade or POSRuleEngineFacade, and never to the subsystem's internals. A facade should expose a few coarse-grained, high-level operations, for example isInvalid(lineItem, sale) rather than many low-level Jess calls, for two reasons: many fine-grained operations make the facade incohesive, and fine-grained calls perform badly when they are remote. The facade itself does little work; it mediates. A small application may expose just a single object from the Domain layer, but the Technical Services layer exposes at least one facade per subsystem.

For upward communication, the usual pattern is Observer (GoF), as above. The alternative is a UIFacade inside the UI layer that receives requests from below; it adds Indirection, which gives Protected Variations if the GUI changes. Use a push-from-below model when polling would be inefficient, as in monitoring or simulation displays; otherwise the usual pull-from-above (polling) model is fine.

Course example: Tony's Pizza

In the Week 4 case study, all the classes designed so far (Order, OrderLineItem, Pizza, Customer…) live in the domain layer, and a GUI layer sits on top with pages such as Choose Pizza, Cart and Checkout. Compare the two designs.

Why a use-case controller rather than one facade controller for the whole system? Because a single controller for all use cases (deliveries, ingredient orders and so on) would become bloated. OrderHandler handles only ordering.

UML Package Diagrams and Package Design exam

To draw a logical architecture you need a notation for "this group of classes" and "this group depends on that one". UML package diagrams provide exactly that, and a layer is simply modelled as a package, for example a package named UI. A UML package can group anything (classes, other packages, use cases); it is more general than a Java package, and it defines a namespace, so two Date classes can live in different packages.

The full notation

The most common logical-architecture diagram shows roughly 5 to 20 packages and their dependencies. Show only a few noteworthy types inside them, because an architectural view deliberately hides the rest.

Drawing a logical architecture, step by step

The study guide gives a six-step procedure. The stepper applies it to NextGen, ending with a version of Larman's Figure 13.2.

Mapping layers and packages to Java

Larman (§13.6) suggests putting the layer name in the package path, and leaving the application qualifier (nextgen) out of reusable packages so that they can be shared across projects. A UML tool can then reverse-engineer the layered package diagram straight from the code.

// UI layer
com.mycompany.nextgen.ui.swing
com.mycompany.nextgen.ui.web
// Domain layer (NextGen-specific)
com.mycompany.nextgen.domain.sales
com.mycompany.nextgen.domain.payments
// Technical Services layer
com.mycompany.service.persistence   // home-grown, reusable across projects
org.apache.log4j                    // third party
org.apache.soap.rpc
// Foundation layer
com.mycompany.util

Package design guidelines (Larman ch. 35, brief)

Once you have packages, how should you decide what goes in each? Larman gives a short set of guidelines.

• Package functionally cohesive vertical and horizontal slices. Group together the types that work together. A clue is strong coupling inside the package and weak coupling outside it. One measure is relational cohesion = internal relations ÷ number of types; the higher it is, the more cohesive the package.
• Package a family of interfaces separately from their implementations, as in javax.ejb.
• Package by work and by clusters of unstable classes. Split out the subset that changes frequently, so that fewer developers depend on it.
• The most responsible (depended-on) packages must be the most stable. To make a package more stable, have it contain mostly interfaces or abstract classes, give it few dependencies or only stable ones, hide its implementation behind a facade, test it well, and mandate that it change slowly.
• Factor out independent types into their own package. For example, the JDBC utilities move out of Persistence into util.jdbc.
• Use factories to reduce dependency on concrete packages. The factories return interfaces; this is the Domain Object Factory idiom.
• No cycles between packages. There are two ways to break a cycle, shown below.

Component and Deployment Diagrams, and the SAD

Package diagrams show how the code is organised. Two more views complete the picture: component diagrams show the large replaceable building blocks and the interfaces between them (the lecture's "implementation view"), and deployment diagrams show where the software physically runs. The Software Architecture Document then gathers all the views in one place.

Components

A component can be a class, so the difference is mostly intent. Calling something a component says two things: (1) its interfaces are important, and (2) it is modular, self-contained and replaceable, like a home-entertainment unit you can swap. External resources and services, such as a SQL database or a JMS messaging service, are components too. Use components for large-grained elements; a component diagram gives the initial high-level landscape of how the system will be implemented.

Workshop 10: from block diagram to component diagram

1. Start with an informal block diagram: named boxes joined by lines, with no formal notation.
2. Formalise it as a component diagram with ball-and-socket interfaces.
3. The hotel-booking example below shows the result.
4. Notice that this is still a layered structure: UI, then Services, then Domain.

Workshop 10 POS exercise (Mobile Service Terminal)

The official partial solution gives no diagrams. It explains why the worksheet has two exercises: Exercise 1 is for understanding the drivers of the architecture, generating alternative options and weighing their pros and cons without worrying about UML details; Exercise 2 is for understanding component-diagram notation and applying it. The rest is a "General Comment" in four points.

1. External elements should already have been identified, such as the credit check agency and the security subsystem, and the architecture needs an external interface to each of them.
2. The logical elements should be assigned to the layers of a layered architecture, also considering the horizontal partitions within each layer, without being influenced by where the elements will be deployed (the logical-versus-deployment distinction of §8.1).
3. The architectural factors worth considering, with how critical each is: supporting multiple MSTs; credit checks (reliability and security); the security release of purchased items (reliability and security); logging of sales (data security and integrity); updating the inventory (data security and integrity).
4. The deployment architecture must support multiple MSTs, with options from a thin client, through a thick client, to fully distributed peers; what are the pros and cons? On control: every activity starts at an MST, but control need not stay there. With a thin client control is on a server; with a thicker client you can choose how to assign it.

A sketch that fits these points (the study guide's own, not official):

• Architecturally significant FRs: card validation and charging through the external credit agency; releasing sold items to the external security system (barcodes); automatic inventory updates on sales and stock arrivals; supervisor queries.
• NFRs: the dominant one is reliability: card sales must succeed with 99.9999% probability (rule 7). The official solution adds security (credit checks, release of items) and data security and integrity (sales log, inventory). Supporting many wireless terminals at once (mobility) is a factor too, and the guide would add the performance of price lookups.
• Natural decomposition: the MST client (UI plus a sale controller); a Sales/Payment service with a CreditAgencyAdapter plus store-card accounts that use a discount Strategy; an Inventory service; a SecuritySystemAdapter that releases items; and a Transaction log for accounting and analysis. Following point 2, place them in layers before deciding where they run: the MST UI in the UI layer; the sale controller and the sales, payment and inventory logic in the application and domain layers; the two adapters and the transaction log in technical services.
• Control is event-driven from the MST UI. With a thin client, server-side services hold control and wait for requests; with a thicker client, you decide how much control stays on the MST. Messages cross the physical boundaries (MST to server, server to credit agency and security system), while method calls are used within a node. The reliability requirement motivates redundancy, retries and store-and-forward.

Weighing the options. A thin client keeps the MST simple and puts the sale logic, sales log and inventory in one place, which helps security and data integrity and makes updates easy. But every sale then needs both the wireless network and the server, which become single points of failure for the 99.9999% target unless the server side is replicated. A thick client keeps working through short network drops, responds faster and can store and forward its sale records, but the logic and sensitive data now sit on many devices that all have to be secured and updated, and the inventory and logs can briefly disagree. Fully distributed peers remove the central server altogether, but duplicating the sales log on every MST, or electing one MST to hold it, makes integrity, security and consistency much harder to guarantee. The Chauffeured Cars case study (§8.11) shows the same trade-off in real life.

Deployment diagrams

A deployment diagram (Larman §38.1, only lightly covered) shows artifacts, such as .jar, .war or .exe files, deployed on nodes. There are two kinds of node: a device node is hardware, such as a PC or a phone; an execution environment node is software that hosts other software, such as an OS, a JVM, a database engine, a browser or a servlet container. Nodes are joined by communication paths labelled with the protocol (HTTP, SOAP, SQL). This is the physical view, so never mix it into a logical layer diagram.

Documenting architecture: the SAD and the N+1 views

This has low exam priority. The Week 10 lecture doesn't cover it, but the Week 11 and 12 lectures name the SAD as an elaboration artefact (holding, for example, a component diagram, the factor table and the technical memos), so know what it is.

Past Exam Q6: Full Model Answers and a Template exam

Everything in this Part comes together in Q6. This section works both 2021 papers in full, sets the study guide's model answers beside the official answers released on 26/27 October, and ends with a fill-in template you can use under time pressure.

2021 S1: Sportsy (Australian sports-club app)

S1  The app targets Australian sports clubs.
S2  Its users are members, including volunteers and officials.
S3  It handles (a) memberships and fees, (b) events, (c) member communication,
    (d) club purchases, and (e) payments for events and merchandise.
S4  There is a legal requirement to keep a detailed record of all financial
    transactions, incoming and outgoing.
S5  The app must be easily usable by a diverse group of users.
S6  There must be a short development time because of a competitor.

Q6.1 model answer

Q6.2 model answer: a technical memo for the functional ASR

First the design the memo describes, then the memo itself.

Other acceptable choices for Sportsy (if justified)

Its Q6.2 memo, on the logging requirement, is only five short points, which tells you the level of detail 10 marks need:

The guide's memo uses a different mechanism (a Finance facade over an append-only ledger written in the same database transaction), and it is equally valid: the marks reward a concrete solution traced back to the factor, not one particular design. The official one is a useful second example of naming a pattern (Observer) as part of an architectural solution.

2021 S2: Doctar (Australian GP clinic app)

S1  The app is for GP clinics across Australia.
S2  Its users are doctors, health professionals and admin staff.
S3  Its features are (a) add patients and their details, (b) pre-existing conditions,
    (c) schedule consultations, (d) consultation notes (doctors only), and
    (e) print prescriptions (doctors only).
S4  It is made available to different clinics, each configuring its own branding
    and contact information.
S5  It must ensure patient confidentiality: store information securely, with
    appropriate security measures.

Q6.1 model answer

Q6.2 model answer: a technical memo for the security ASR

Other acceptable choices for Doctar (if justified)

• S4 branding as the memo topic. Classify it as an FR, or as an NFR under Supportability—Configurability, and say which. Solution: a ClinicProfile per tenant, and a BrandingService in Technical Services that supplies the name, logo, colours and contacts to all UI themes and print templates, with no literal clinic data in the code (data-driven design, Protected Variations). Motivation: one codebase for all clinics, keeping maintenance low; remember the Windows XP lesson. Unresolved: how far customisation goes (custom fields? layouts?). Alternatives: a forked build per clinic, rejected because of the maintenance explosion; hard-coding and customising per sale, also rejected.
• S3e print prescriptions. An FR (Printing, in the lecture list). Solution: a PrintingService facade, a printer adapter for each clinic's printer or driver, and prescription templates with branding; later, an adapter to an electronic-prescription service. Alternatives: printing from each screen, rejected because of the duplication and coupling.
• S3d/S3e role restrictions. An FR (Security, in the lecture list), handled by the same mechanism as the security memo. Don't pick it together with S5: that gives two overlapping requirements.

The official memo (released 26/27 Oct) is on the same requirement, storing and managing confidential information, and again gives one short point per heading:

The guide's memo covers all of this and goes further, putting role-based access control into the solution where the official answer leaves it as an unresolved issue. Both are valid; the official version is the minimum, and it shows again that naming a GoF pattern (here Façade) inside the solution is welcome. Its Q6.1 follows the Sportsy pattern: architectural analysis as a specialisation of requirements analysis, and the cost of failure for each requirement (failing legal obligations on confidentiality; clinics across Australia not adopting an app they cannot brand).

A reusable template for Q6 under time pressure

Before writing (1 minute). Underline every sentence with a FURPS+ flavour, then pick two requirements that don't overlap. The FR should be cross-cutting or external: auditing or records, payments, printing, messaging, configuration or branding, and security access rules are typical. The NFR should be cross-cutting and high priority: security, reliability or availability, usability across many users and devices, performance or scalability, or a schedule or cost constraint.

Case Study: Chauffeured Cars (Week 11)

Textbook examples start from a clean slate; real architecture work usually starts from a struggling legacy system. The Week 11 lecture ends with such a case, a chauffeured car company, and walks through analysis, options and a staged migration. It is not among the Week 12 key topics, and the review's Q&A says specific tools such as Amazon Web Services are not the subject's focus, so learn the reasoning, not the technology. It illustrates analysis (§8.2), resolving factors (§8.4), weighing alternatives as a memo does (§8.5) and deployment diagrams (§8.9).

The client and its problems

The client runs about 30 drivers. Its Bookings and Dispatch (B&D) system is business critical: bookings arrive by phone and email, and between one and four operators use the system at the same time. Uber-style operators are also encroaching on the business with a different business model, so the company needs to highlight the differences to its customers.

From the client's own perspective there were five problems: the system was slow or hung, especially while a customer was on the phone; when it was unavailable, operators fell back on pen and paper; functionality was missing (invoicing and reporting, and a customer portal for online booking and profiles); the IT provider, "Developer A", was unhelpful; and keeping the status quo carried a significant cost overhead.

Analysis: from complaints to quality attributes

The investigation turned the complaints into quality attributes, which is architectural analysis in miniature, and then traced each one to an architectural cause.

The technical investigation found three more issues. Version 3's technology was dated, so the dependency on it had to go. The database ran on a recent SQL Server, but its schema (types, use of indexing, use of built-in validation) dated from Version 3, so it used none of the newer features for performance and reliability. And the design of both V3 and V5 was generally poor and, in particular, highly coupled.

Options and the decision

The client chose option 3, once a willing developer had been identified, under the banner "Take Control". This is the buy-versus-build kind of decision from §8.1, and the rejected options are exactly what a technical memo records under Alternatives considered.

A staged migration, drawn

The plan ran in four stages, each fixing some issues and leaving others for later. Step through the deployment diagrams. Each 3-D box is a node: «device» nodes for the operators' PCs, with «executionEnvironment» nodes (login sessions, virtual machines, Amazon Web Services) nested inside; component instances such as :B&D System V5 sit inside them.

Two things stand out. Stage 1 is the thin-versus-thick client trade-off from Workshop 10 (§8.9) in practice: a remote-desktop thin client depended on the network for everything, and moving the processing onto the operators' PCs fixed the lag. And Stages 3 and 4 pull pricing and booking out of the monolithic V5 into shared services that both the operators' clients and the customers' web site use: the large-scale version of Low Coupling, High Cohesion and Protected Variations (§8.4).

Lessons

Common Mistakes and the One-Glance Summary

The workshop review slides list no architecture-specific errors, so this list is drawn from the lecture's "worse versus better" examples, the exam's marking criteria and Larman's warnings. Read it the night before the exam.

Spot the errors: layers and package diagrams

1. Solid line used for a dependency. Package dependencies are dashed lines with an open arrowhead.
2. Upward dependency: Domain depends on UI. Coupling goes downward; if the domain must notify the UI, use Observer through an interface.
3. A cycle between Domain and Technical Services. No cycles: factor out the shared types, or depend on an interface in a new package.
4. The database drawn as the bottom layer, mixing the logical and deployment views. Model the data need as a Domain sub-domain plus a Persistence partition.
5. Model-View Separation broken twice: the domain's Sale references a concrete window, and the window holds application logic (calculateTax). Use a Controller going down and an Observer coming up.

The one-glance summary (for your notes sheet)