Chapter 6 – Architectural Design

02/01/2015 Chapter 6 Architectural Design 1

Topics covered

❑ Definitions

❑ Architectural design decisions

❑ Architectural views

❑ Architectural patterns

❑ Design patterns

❑ Application architectures

02/01/2015 Chapter 6 Architectural Design 2

Architectural design

➢ Architectural design
• how a software system should be organized and
designed
• identifies the main components and relation among
them.
• early stage of agile processes is to design an
overall systems architecture
➢ Output:
• architectural model that describes how the
system components are organized
02/01/2015 Chapter 6 Architectural Design 3
Architectural scale

 Application architecture
• Small view of system architecture

• Concerned with the way that an individual program is

decomposed into components.
 Enterprise architecture
• Large view of system architecture
• Concerned with the architecture of complex enterprise
systems.
• distributed over different computers, which may be
owned and managed by different companies.

02/01/2015 Chapter 6 Architectural Design 4

Architectural representations

 Box and line diagrams

• Very abstract

• Represents the components with connection from high

level

• useful for communication with stakeholders and for project

planning.

02/01/2015 Chapter 6 Architectural Design 5

Architectural representations

 Box and line diagrams

• Very abstract

• Represents the components with connection from high

level
• useful for communication with stakeholders and for project
planning.

02/01/2015 Chapter 6 Architectural Design 6

AWS architecture

Sample AWS architecture

WebApp architecture

Open Banking architecture

Serverless architecture

02/01/2015 Chapter 6 Architectural Design 7

Architectural representations

02/01/2015 Chapter 6 Architectural Design 8

Architectural representations

02/01/2015 Chapter 6 Architectural Design 9

 Architectural design decisions

02/01/2015 Chapter 6 Architectural Design 10

Fundamental questions of architectural decisions

02/01/2015 Chapter 6 Architectural Design 11

Architecture and non-functional requirements

 Performance
▪ Localise critical operations and minimise communications. Use
large rather than fine-grain components.
▪ Use caching whenever possible
▪ Use indexation engine for your queries
 Security
▪ Use a layered architecture with critical assets in the inner layers.
▪ Reduce surface attack
▪ Security in all layers
▪ Principle of least priviliges
 Safety
▪ Localise safety-critical features in a small number of sub-
02/01/2015
systems. Chapter 6 Architectural Design 12
Architecture and non-functional requirements

 Safety
▪ Localise safety-critical features in a small number of sub-
systems.
 Availability
▪ Include redundant components and mechanisms for fault
tolerance.
 Maintainability
▪ Use fine-grain, replaceable components.

02/01/2015 Chapter 6 Architectural Design 13

 Architectural views

02/01/2015 Chapter 6 Architectural Design 14

4 + 1 view model of software architecture

02/01/2015 Chapter 6 Architectural Design 15

4 + 1 view model of software architecture

❑ Logical view
▪ The functionality, the services.
▪ UML diagrams: class-diagram, state diagram

❑ Process view
▪ Shows dynamics of the system
▪ Communication between components in runtime
▪ UML diagrams: sequence diagram, activity diagram

02/01/2015 Chapter 6 Architectural Design 16

4 + 1 view model of software architecture

❑ Development view
▪ Programmers' perspective
▪ UML diagrams: component diagram, package diagram
❑ Physical view
▪ System engineer point of view
▪ Physical layers and network communication
▪ UML diagrams: deployment diagram
❑ Scenario (+1)
▪ Typical use-case
▪ Connecting views altogether
02/01/2015 Chapter 6 Architectural Design 17
 Architectural patterns

02/01/2015 Chapter 6 Architectural Design 18

Architectural patterns

❑ Pattern
▪ A template for representing, sharing, and reusing

knowledge

▪ Description of best practice for applying a concept

▪ Includes info about when & when not useful

▪ Described as tabular or graphical diagram

02/01/2015 Chapter 6 Architectural Design 19

The Model-View-Controller (MVC) pattern

02/01/2015 Chapter 6 Architectural Design 20

The Model-View-Controller (MVC) pattern

Name MVC (Model-View-Controller)

Description Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The Model
component manages the system data and associated operations on that data. The
View component defines and manages how the data is presented to the user. The
Controller component manages user interaction (e.g., key presses, mouse clicks,
etc.) and passes these interactions to the View and the Model. See Figure 6.3.

Example Figure 6.4 shows the architecture of a web-based application system

organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data. Also used when
the future requirements for interaction and presentation of data are unknown.

Advantages Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made
in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model and
interactions are simple.

02/01/2015 Chapter 6 Architectural Design 21

MVC web application

02/01/2015 Chapter 6 Architectural Design 22

Layered architecture

02/01/2015 Chapter 6 Architectural Design 23

The Layered architecture pattern

Name Layered architecture

Description Organizes the system into layers with related functionality associated
with each layer. A layer provides services to the layer above it so the
lowest-level layers represent core services that
are likely to be used throughout the system. See Figure6.6.
Example Onion architecture in C#

When used Used when building new facilities on top of existing systems; when
the development is spread across several teams with each team
responsibility for a layer of functionality; when there is a requirement
for multi-level security.
Advantages Allows replacement of entire layers as long as the interface is
maintained. Redundant facilities (e.g., authentication) can be provided
in each layer to increase the dependability of the system.

Disadvantages In practice, providing a clean separation between layers is often

difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately
below it. Performance can be a problem because of multiple levels
of interpretation of a service request as it is processedat each layer.

02/01/2015 Chapter 6 Architectural Design 24

A generic layered architecture

02/01/2015 Chapter 6 Architectural Design 25

The architecture of the iLearn system
Security services

02/01/2015 Chapter 6 Architectural Design 26

Repository architecture

❑ Sub-systems must exchange data. This may be done in

two ways:
▪ Each sub-system maintains its own database and passes data
explicitly to other sub-systems via API.

▪ Shared data is held in a central database or repository and may

be accessed by all sub-systems;

❑ most used when large amounts of data are to be

shared

02/01/2015 Chapter 6 Architectural Design 27

The Repository pattern

Name Repository
Description All data in a system is managed in a central repository that is
accessible to all system components. Components do not interact
directly, only through the repository.
Example In-memory cache
Message broker
Database tables
FTP share
NoSQL change stream
When used You should use this pattern when you have a system in which large
volumes of information are generated that has to be stored for a
long time. You may also use it in data-driven
systems where the inclusion of data in the repository triggers an
action or tool.
Advantages Components can be independent—they do not need to know of the
existence of other components. All data can be managed
consistently (e.g., backups done at the same time) as it is all in one
place.

Disadvantages The repository is a single point of failure so problems in the

repository affect the whole system. May be inefficiencies in
organizing all communication through the repository. Distributing
the repository across several computers may be difficult.
02/01/2015 Chapter 6 Architectural Design 28
A repository architecture for an IDE

02/01/2015 Chapter 6 Architectural Design 29

Client-server architecture

❑ Distributed system model

▪ Set of stand-alone servers which provide specific

services such as printing, data management, etc.

▪ Set of clients which call on these services.

▪ Network which allows clients to access servers.

02/01/2015 Chapter 6 Architectural Design 30

The Client–server pattern

Name Client-server

Description In a client–server architecture, the functionality of the system is

organized into services, with each service delivered from a separate
server. Clients are users of these services and access
servers to make use of them.
Example Figure 6.11 is an example of a film and video/DVD library organized as a
client–server system.
When used Used when data in a shared database has to be accessed from a range of
locations. Because servers can be replicated, may also be used when the
load on a system is variable.
Advantages The principal advantage of this model is that servers can be
distributed across a network. General functionality (e.g., a printing
service) can be available to all clients and does not need to be
implemented by all services.
Disadvantages Each service is a single point of failure so susceptible to denial of service
attacks or server failure. Performance may be unpredictable because it
depends on the network as well as the system. May be
management problems if servers are owned by different organizations.

02/01/2015 Chapter 6 Architectural Design 31

A client–server architecture for a film library

02/01/2015 Chapter 6 Architectural Design 32

 Application architectures

02/01/2015 Chapter 6 Architectural Design 33

Layered (n-tier) architecture

 Best for.
• New applications that need to be built quickly
• Teams with inexperienced developers who don’t
understand other architectures yet
 Caveats
• Source code can turn into a “big ball of mud” if it is
unorganized
• Code can end up slow thanks to what some developers
call the “sinkhole anti-pattern.” Much of the code can be
devoted to passing data through layers without using any
logic
02/01/2015 Chapter 6 Architectural Design 34
Event-driven architecture

 Best for.
• Asynchronous systems with asynchronous data flow
• User interfaces
 Caveats
• Debugging and error handling can be difficult to structure
• Messaging overhead can slow down processing speed
• Developing a systemwide data structure for events can be
complex
• Testing is complex

02/01/2015 Chapter 6 Architectural Design 35

Application architectures

 Microkernel architecture (plugins)

 Best for.
• Tools used by a wide variety of people
• Applications with a fixed set of core routines and a
dynamic set of rules that must be updated frequently
 Caveats
• Deciding what belongs in the microkernel is often an art
• Modifying the microkernel can be very difficult or even
impossible once a number of plug-ins depend upon it

02/01/2015 Chapter 6 Architectural Design 36

Application architectures

 Micro-services architecture
 Best for.
• Application with well-defined boundaries
• Rapidly developing new businesses and web applications
• Development teams that are spread out
 Caveats
• Performance can suffer when tasks are spread out
between different microservices
• Too many microservices can confuse users as parts of the
web page appear much later than others

02/01/2015 Chapter 6 Architectural Design 37

Use of application architectures

 As a starting point for architectural design.

 As a design checklist.
 As a way of organising the work of the development
team.
 As a means of assessing components for reuse.
 As a vocabulary for talking about application types.

02/01/2015 Chapter 6 Architectural Design 38

Examples of application types

 Data processing applications

▪ Data driven applications that process data in batches without
explicit user intervention during the processing.
 Transaction processing applications
▪ Data-centred applications that process user requests and update
information in a system database.
 Event processing systems
▪ Applications where system actions depend on interpreting
events from the system’s environment.
 Language processing systems
▪ Applications where the users’ intentions are specified in a formal
language that is processed and interpreted by the system.
02/01/2015 Chapter 6 Architectural Design 39
Application type examples

 Two very widely used generic application architectures are

transaction processing systems and language processing
systems.
 Transaction processing systems
▪ E-commerce systems;
▪ Reservation systems.
 Language processing systems
▪ Compilers;
▪ Command interpreters.

02/01/2015 Chapter 6 Architectural Design 40

Transaction processing systems

 Process user requests for information from a database

or requests to update the database.
 From a user perspective a transaction is:
▪ Any coherent sequence of operations that satisfies a goal;
▪ For example - find the times of flights from London to Paris.
 Users make asynchronous requests for service which
are then processed by a transaction manager.

02/01/2015 Chapter 6 Architectural Design 41

The structure of transaction processing
applications

02/01/2015 Chapter 6 Architectural Design 42

The software architecture of an ATM system

02/01/2015 Chapter 6 Architectural Design 43

Information systems architecture

 Information systems have a generic architecture that can

be organised as a layered architecture.
 These are transaction-based systems as interaction with
these systems generally involves database transactions.
 Layers include:
▪ The user interface
▪ User communications
▪ Information retrieval
▪ System database

02/01/2015 Chapter 6 Architectural Design 44

Layered information system architecture

02/01/2015 Chapter 6 Architectural Design 45

The architecture of the Mentcare system

02/01/2015 Chapter 6 Architectural Design 46

Server implementation

 These systems are often implemented as multi-tier client

server/architectures (discussed in Chapter 17)
▪ The web server is responsible for all user communications, with
the user interface implemented using a web browser;
▪ The application server is responsible for implementing
application-specific logic as well as information storage and
retrieval requests;
▪ The database server moves information to and from the
database and handles transaction management.

02/01/2015 Chapter 6 Architectural Design 47

Language processing systems

 Accept a natural or artificial language as input and generate

some other representation of that language.
 May include an interpreter to act on the instructions in the
language that is being processed.
 Used in situations where the easiest way to solve a
problem is to describe an algorithm or describe the system
data
▪ Meta-case tools process tool descriptions, method rules, etc
and generate tools.

02/01/2015 Chapter 6 Architectural Design 48

The architecture of a language processing
system

02/01/2015 Chapter 6 Architectural Design 49

Compiler components

 A lexical analyzer, which takes input language tokens

and converts them to an internal form.
 A symbol table, which holds information about the names
of entities (variables, class names, object names, etc.)
used in the text that is being translated.
 A syntax analyzer, which checks the syntax of the
language being translated.
 A syntax tree, which is an internal structure representing
the program being compiled.

02/01/2015 Chapter 6 Architectural Design 50

Compiler components

 A semantic analyzer that uses information from the

syntax tree and the symbol table to check the semantic
correctness of the input language text.
 A code generator that ‘walks’ the syntax tree and
generates abstract machine code.

02/01/2015 Chapter 6 Architectural Design 51

A repository architecture for a language
processing system

02/01/2015 Chapter 6 Architectural Design 52

A pipe and filter compiler architecture

02/01/2015 Chapter 6 Architectural Design 53

Key points

 A software architecture is a description of how a software

system is organized.
 Architectural design decisions include decisions on the
type of application, the distribution of the system, the
architectural styles to be used.
 Architectures may be documented from several different
perspectives or views such as a conceptual view, a
logical view, a process view, and a development view.
 Architectural patterns are a means of reusing knowledge
about generic system architectures. They describe the
architecture, explain when it may be used and describe
its advantages and disadvantages.
02/01/2015 Chapter 6 Architectural Design 54
Key points

 Models of application systems architectures help us

understand and compare applications, validate
application system designs and assess large-scale
components for reuse.
 Transaction processing systems are interactive systems
that allow information in a database to be remotely
accessed and modified by a number of users.
 Language processing systems are used to translate
texts from one language into another and to carry out the
instructions specified in the input language. They include
a translator and an abstract machine that executes the
generated language.
02/01/2015 Chapter 6 Architectural Design 55