9. System Design and Software Architecture

This was written entirely with AI.

These notes cover Lecture 12 (System Design) and Tutorial 6 Q1. Requirements and analysis describe the problem. Design describes the solution. This part is the first level, system design: the large parts of the system and how they connect (the software architecture). Part 10 goes down to the classes inside each part. In the exam this is Q3(a): name the one non-functional requirement (Part 2), propose an architecture, draw a detailed class diagram, and propose an alternative architecture for the NFR (8 marks for each of the last two).

How to use this page. Each section teaches one idea in a few lines, then gives concept checks. Tutorial 6 Q1 is in section 8, with the method for the class diagram. Past-paper questions are not on this page: use the original papers.

Quick reference

1. From the problem to the solution

Requirements elicitation and analysis describe the problem. Design describes the solution. Design has two levels:

1. System design decides the software architecture: the large parts of the system and how they connect.
2. Object design (Parts 10–11) decides the detailed classes, interfaces and design patterns inside each part.

The analysis model (boundary, control and entity classes) is the input to system design.

Each SDLC activity produces a model. Each model builds on the model before it:

2. Why architecture matters

Software systems become larger in every way: more code, more users, more developers, a longer life (often decades) and more versions. The technology and the hardware also change. At the same time, the budget is limited, the schedule is tight, and the system must be easy to maintain.

The architecture decides most of the non-functional qualities of a system:

• performance;
• availability;
• security;
• scalability;
• extensibility and maintainability.

A wrong architecture is very costly to change later, because every part of the system depends on it.

3. What a software architecture is

Software architecture describes the elements from which systems are built, the interactions among those elements, the patterns that guide their composition, and the constraints on these patterns. (Shaw and Garlan, 1996)

In short: Software architecture = {Components, Connectors}.

• A component is a unit of software that does a function at run time. Examples: programs, objects, processes, clients, servers, databases.
• A connector is an interaction between components: communication, coordination or cooperation. Examples: shared variables, procedure calls, remote procedure calls, communication protocols, data streams.

An architecture is:

• abstract — it hides the details of the components and connectors;
• about structure and interactions — it shows the topology, the components, and the data and control flow between them;
• purposeful — it lets the team show and analyse important properties, and it documents design knowledge for other people.

4. How to develop an architecture

The large arrow behind the five boxes means that all five feed into one result: the architecture. Read the boxes as five questions that the architect answers. The table below gives each question.

5. Design principles

Read the pyramid from the bottom up, in the direction of the arrow. Design principles are the base. Design patterns, in the middle, apply the principles to common problems. The result at the top is a good design: maintainable, extensible, scalable, testable and reusable. You cannot get the top without the layers under it: a pattern used without understanding the principle behind it rarely gives a good design.

6. Architectural styles

An architectural style is a pattern for how to organise a whole system. It defines:

• a vocabulary of component types (for example filters, layers, clients and servers);
• a vocabulary of connector types (for example procedure calls, data streams, sockets);
• constraints on how they combine (for example “filters do not share state”, “a layer may call only the layer below it”);
• a way to work out the properties of the whole system from the properties of its parts.

The style does not fix the number of components, the type of each connector, or the exact data. A pipe-and-filter system can have 2 filters or 20 filters.

The figure is a tree. Each brace splits a family into its styles. There are five families: independent components, data flow, data-centred, virtual machine, and call and return. The sections below take them one at a time. Note where the layered system sits: it is a call-and-return style, because each layer calls the layer below and waits for the result.

Layered architecture

The system is a stack of layers. Each layer gives services to the layer above it and uses only the services of the layer below it.

The usual three-layer architecture matches the boundary, control and entity classes:

How to read the figure. It is an emergency-response system. Each red frame is a layer, and the icon in its top-right corner is the stereotype of the classes inside it:

• Presentation (boundary): FieldOfficerUI and DispatcherUI, one screen per human actor.
• App Logic (control): Resource, Map and Incident Management.
• Persistent Data (entity): one Database.

Each dashed arrow is a dependency. Every arrow points down, and every arrow goes only to the next layer. A UI never reaches the Database directly. Several UIs can share one logic class: both UIs use Map Management.

A four-layer version splits the entity layer in two. Business objects are the entity classes in memory, such as an Account or a Booking. Persistent data is the database that stores them. Dependencies still go only downwards: presentation → business application logic → business objects → persistent data. Use it when the stored format should be able to change (another database, files) without a change to the business objects.

The rules for dependencies between stereotypes become rules between layers:

Read the figure left to right. An actor uses a boundary. A boundary calls a control. A control reads and writes entities. The loop on Control means that a control can call another control. The loop on Entity means that entities link to each other through associations. No arrow skips a step: there is no actor → control and no boundary → entity.

Benefits of layers:

• Separation of concerns. Each layer handles a smaller problem.
• Low coupling. A layer knows only the interface of the layer below. It does not know how the lower layer works.
• Changeability. You can replace a whole layer, if its interface stays the same. A web app and a mobile app can share the same logic and data layers.
• Easy maintenance. A change inside a lower layer does not force changes in the layers above.

Drawbacks of layers:

• Performance. Each request passes through all layers. More layers mean more overhead.
• Up-calls. Sometimes a lower layer must tell a higher layer that something changed (for example, data changed and the screen must update). A direct call upward breaks the layer rule. The Observer pattern solves this (Parts 10 and 11).

Client–server

Clients send requests to one or more servers over a network. Servers provide shared services, such as data or computation. Many clients can use one server.

• Good for: many users, shared data, web and mobile access, central security.
• Scalability: add more servers behind a load balancer.
• Risk: the server or the network is a single point of failure, unless servers are replicated.

Data flow: pipe-and-filter and batch sequential

Data passes through a series of processing steps (filters), connected by pipes. Filters do not share state. Good for data transformation, such as compilers and media processing. Batch sequential runs each step on the whole data set before the next step starts.

Data-centred: repository and blackboard

All components share one central data store. Components communicate through the data store and not directly. Good when many tools work on the same data, such as an IDE.

Independent components: event systems

Components do not call each other directly. A component announces an event. Other components that registered for that event react to it (implicit invocation). This is the architecture-level form of the Observer pattern.

Virtual machine: interpreter and rule-based system

The system runs a program or a set of rules that is not native code. An interpreter runs a script language. A rule-based system applies “if–then” rules to facts. Good when users must change the behaviour without recompiling.

Call and return: main program and subroutine, object-oriented

The main program calls subroutines, or objects call methods of other objects. This is the normal style inside one program.

Model–View–Controller

MVC is an architecture for interactive systems. Part 11 covers it in detail.

7. How designers work

Designers do not find the final design in one step. They:

1. understand the requirements and build a model of the problem;
2. propose one or more design solutions;
3. check each solution against the requirements;
4. revise the solution, or look for a new solution, where it does not match;
5. compare the solutions and select one;
6. work out the selected solution in detail, as a blueprint.

8. From architecture to a detailed class diagram

A frequent exam question: “Propose an architecture and draw a detailed class diagram with key attributes and methods that reflects the architecture.”

Method:

1. Choose the architecture and say why. For most systems with a UI, logic and stored data, choose a layered architecture (three layers). For strongly interactive systems with many views of the same data, choose MVC. Give one or two reasons that come from the requirements.
2. Draw each layer as a package or a labelled box: Presentation, Application Logic, Persistent Data.
3. Put the classes into the layers:
   • boundaries in Presentation (one UI per human actor, one interface per external system or device);
   • controls in Application Logic (one manager or controller per use case group);
   • entities in Persistent Data.
4. Give each class key attributes and methods. Attributes: the data from the data dictionary, with types. Methods: the steps from the use case descriptions.
5. Draw the dependencies. UI → controller → entity. A controller can also call a device or external-system interface (control → boundary is allowed). A UI never calls an entity directly. Add multiplicities to the entity associations.
6. Add interfaces where the design must be flexible (for example PaymentMethod, NotificationChannel). This shows “program to an interface”.
7. Check that no boundary calls an entity directly.

How to read the diagram:

• Three frames, one per layer. Presentation holds the boundaries, Application Logic the controls, Persistent Data the entities.
• Visibility icons. This tool draws visibility as icons, not signs. A hollow circle means public (+). A hollow square means private (-). So the UI methods and controller methods are public, isInsideWindow() is a private helper, and every entity attribute is private.
• UnlockDoorUI → UnlockController. The UI method requestUnlock(doorId) calls unlock(guestId, doorId). The controller reads AccessGrant, checks the window with isInsideWindow(), calls sendUnlock() on DoorLockInterface and writes ActivityLog. The arrow to DoorLockInterface points up, from control to boundary. That is allowed: a control may call the interface of a device.
• GuestAccessUI → AccessController. submitGrant(...) calls grantAccess(...), which creates an AccessGrant. revokeAccess(grantId) changes its status.
• Associations among the entities. Guest 1 — * AccessGrant: one guest can hold many grants. AccessGrant * — 1 Door: each grant is for one door.
• Typed attributes. Every attribute has a type (startTime: DateTime, isLocked: boolean). The attributes come from the data dictionary. The methods come from the steps of the use case descriptions.

Tutorial 6 Q1: Layers for boundary, control and entity objects

Grain Elevator System (GES)

1. Refer to the conceptual model developed in Question 1 of Tutorial #4.

Use proper architectural styles to model dependencies among boundary, control, and entity objects.

(The question says Tutorial #4. The conceptual model is from Tutorial #3, Question 1. This is a slip in the question sheet.)

Answer

• Presentation layer (boundary classes): GESMainUI, ShipmentInterface, AllocationInterface, ManualAllocationInterface.
• Business App Logic layer (control classes): GESManager, ShipmentManager, AllocationManager, ManualAllocationManager.
• Business Object layer (entity classes): Shipment, Allocation, Grain, Silo.
• Persistent Data layer (entity): Database.

Every arrow points down and goes to the next layer. The screens use the managers. The managers use the business objects. The business objects are stored in the database. No screen touches an entity, and no layer calls upwards.

Two small differences from the conceptual model of Tutorial 3: the figure leaves out DisplayInterface, and it shows Shipment only, not its kinds ArrivalShipment and DepartureShipment.

Extension 1.1. The processing plants now get a web portal. Which layers change? Which stay the same?

Extension 1.2. Say which of these arrows break the layer rules, and why. (a) ShipmentInterface → Shipment. (b) Silo → ShipmentManager (the silo tells the manager that its level changed). (c) GESMainUI → Database. (d) AllocationManager → Silo. (e) Database → Shipment.

9. Proposing an alternative architecture for a non-functional requirement

Another frequent question: “Identify one relevant non-functional requirement and propose an alternative architecture that addresses it.”

1. Pick the NFR that the description stresses most. Look for words such as “real time”, “many users”, “secure”, “must always be available”, “notify”.
2. Explain why the first architecture is weak for that NFR.
3. Propose a style that fixes it, and explain how.

Exam patterns

This is Q3(a) in the recent papers. Propose an architecture and draw a detailed class diagram with key attributes and methods (8 marks: AY23/24 S1, AY23/24 S2, AY24/25 S1, AY25/26 S1; the two 2023/24 papers add “your solution should address the non-functional requirements identified”). Identify the one NFR and propose an alternative architecture (8 marks: AY24/25 S1, AY25/26 S1). The older CZ3003 paper (AY18/19 S1) asked for the two meta-design principles, the components and connectors of pipe-and-filter with pros and cons, and how to add a security component to an architecture. Tutorial 6 Q1 is the layered diagram.

Common Traps

• Justify the architecture with the description. One or two facts, not a general claim.
• Dependencies go down only, and only to the next layer. A UI never calls an entity.
• A control may call a boundary to a device. The arrow points up, and that is allowed.
• Type every attribute. Take the attributes from the data dictionary and the methods from the use case descriptions.
• Show interfaces where the design must be flexible. This shows “program to an interface”.
• Cohesion high, coupling low.
• An up-call breaks the layer rule. Observer or events fix it.
• A weak NFR answer has no quote. Quote the clue first.
• Event systems do not guarantee delivery.
• The architecture sets the non-functional qualities. That is why the NFR comes first.