Chapter 6 – Architectural Design

Lecture 1

Chapter 6 Architectural design 1

Topics covered

 Architectural design decisions

 Architectural views
 Architectural patterns
 Application architectures

Chapter 6 Architectural design 2

Software architecture

 The design process for identifying the sub-systems

making up a system and the framework for sub-system
control and communication is architectural design.
 The output of this design process is a description of the
software architecture.

Chapter 6 Architectural design 3

Architectural design

 An early stage of the system design process.

 Represents the link between specification and design
processes.
 Often carried out in parallel with some specification
activities.
 It involves identifying major system components and
their communications.

Chapter 6 Architectural design 4

The architecture of a packing robot control
system

Chapter 6 Architectural design 5

Architectural abstraction

 Architecture in the small is concerned with the

architecture of individual programs. At this level, we are
concerned with the way that an individual program is
decomposed into components.
 Architecture in the large is concerned with the
architecture of complex enterprise systems that include
other systems, programs, and program components.
These enterprise systems are distributed over different
computers, which may be owned and managed by
different companies.

Chapter 6 Architectural design 6

Advantages of explicit architecture

 Stakeholder communication
 Architecture may be used as a focus of discussion by system
stakeholders.
 System analysis
 Means that analysis of whether the system can meet its non-
functional requirements is possible.
 Large-scale reuse
 The architecture may be reusable across a range of systems
 Product-line architectures may be developed.

Chapter 6 Architectural design 7

Architectural representations

 Simple, informal block diagrams showing entities and

relationships are the most frequently used method for
documenting software architectures.
 But these have been criticised because they lack
semantics, do not show the types of relationships
between entities nor the visible properties of entities in
the architecture.
 Depends on the use of architectural [Link]
requirements for model semantics depends on how the
models are used.

Chapter 6 Architectural design 8

Box and line diagrams

 Very abstract - they do not show the nature of

component relationships nor the externally visible
properties of the sub-systems.
 However, useful for communication with stakeholders
and for project planning.

Chapter 6 Architectural design 9

Use of architectural models

 As a way of facilitating discussion about the system

design
 A high-level architectural view of a system is useful for
communication with system stakeholders and project planning
because it is not cluttered with detail. Stakeholders can relate to
it and understand an abstract view of the system. They can then
discuss the system as a whole without being confused by detail.
 As a way of documenting an architecture that has been
designed
 The aim here is to produce a complete system model that shows
the different components in a system, their interfaces and their
connections.

Chapter 6 Architectural design 10

Architectural design decisions

 Architectural design is a creative process so the process

differs depending on the type of system being
developed.
 However, a number of common decisions span all design
processes and these decisions affect the non-functional
characteristics of the system.

Chapter 6 Architectural design 11

Architectural design decisions

 Is there a generic application architecture that can be

used?
 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?

Chapter 6 Architectural design 12

Architecture reuse

 Systems in the same domain often have similar

architectures that reflect domain concepts.
 Application product lines are built around a core
architecture with variants that satisfy particular customer
requirements.
 The architecture of a system may be designed around
one of more architectural patterns or ‘styles’.
 These capture the essence of an architecture and can be
instantiated in different ways.
 Discussed later in this lecture.

Chapter 6 Architectural design 13

Architecture and system characteristics

Performance:
• Keep important operations close together.
• Reduce unnecessary communication between parts.
• Use bigger components instead of many tiny ones.

Security:
• Protect your most important parts by placing them in the center.
• Use multiple layers of protection around critical assets.

Safety:
• Limit safety-critical features to just a few components.
• Make them easier to monitor and control.
Chapter 6 Architectural design 14
 Architecture and system characteristics

Availability:
• Add backup components.
• Design the system to keep working even if some parts fail.

Maintainability:
• Use small, replaceable parts.
• Make it easy to fix or update components without affecting the
whole system.

Chapter 6 Architectural design 15

Architectural views

What are architectural views?

They are different ways to look at or understand a system when
designing it.
Why use multiple views?
One view shows only one aspect of the system, like:
• How the system is split into modules
• How processes interact while running
• How components are spread across a network
How to describe them: Use diagrams, charts, or other notations to
represent each view clearly.
Key idea: Use different views to explain the full system
Chapter 6 Architectural design 16
4 + 1 view model of software architecture

 Logical View:
• Shows the main parts of the system as objects or classes.
• Focuses on what the system is made of.
 Process View:
• Shows how the system runs as interacting processes.
• Focuses on how the system works at runtime.
 Development View:
• Shows how the software is broken into parts for coding and
development.
• Focuses on how developers organize the system.

Chapter 6 Architectural design 17

4 + 1 view model of software architecture

 Physical View:
• Shows the hardware and where software components run.
• Focuses on how software is mapped to hardware.
 +1 (Scenarios/Use Cases):
• Connects all views using real examples of how the system is
used.

Chapter 6 Architectural design 18

Architectural patterns

 What are patterns?

Patterns help share and reuse design knowledge.
 What is an architectural pattern?
It’s a proven way to design software, tested in different
situations.
 When to use patterns:
Good patterns tell you when they work well and when they don’t.
 How to show patterns:
Use tables or diagrams to describe them clearly.

Chapter 6 Architectural design 19

The Model-View-Controller (MVC) pattern

 MVC -Separates data (Model), user interface (View), and

user interaction(Controller).
 Components:
• Model: Manages data and operations on it.
• View: Shows data to the user.
• Controller: Handles user actions and updates Model/View.

Chapter 6 Architectural design 20

The Model-View-Controller (MVC) pattern

 Advantages:
• Data and its display can change independently.
• Same data can be shown in multiple ways, updates are reflected
everywhere.
 Disadvantages:
• if the system is simple , Extra code and complexity.

Chapter 6 Architectural design 21

The organization of the Model-View-Controller

Chapter 6 Architectural design 22

Web application architecture using the MVC
pattern

Chapter 6 Architectural design 23

Layered architecture

Defn. software we divide the system into layers, each with a role.
Typical Layers in Software Systems
 Presentation Layer (UI / View)
• What the user sees and interacts with.
• Example: Mobile app screen, website pages, forms, buttons.
 Application / Business Logic Layer (Controller/Service)

• Contains the rules, workflows, and processing logic.

• Example: Calculating total bill in a shopping app, checking cab
availability, applying discounts.
 Data Layer (Model / Database)
• Responsible for storing and retrieving data.
24
• Example: Customer records in SQL database, product inventory,
The Layered architecture pattern

Point Easy Explanation

A way to organize a system into layers, where each layer has related tasks
What it is
and helps the layer above.

A library system:
• Top layer: Users borrow books (UI)
Example
• Middle layer: Staff manage records (Logic)
• Bottom layer: Books are stored (Data)

- When building on existing systems- When different teams work on

When used
different parts- When multi-level security is needed

- Layers can be replaced without breaking the system- Extra features like
Advantages
login can be added in each layer- Easy to develop step by step

- Sometimes layers mix up (top layer may talk to bottom directly)- Can
Disadvantages
slow performance because requests go through many layers
Chapter 6 Architectural design 25
A generic layered architecture

Chapter 6 Architectural design 26

The architecture of the LIBSYS system

Chapter 6 Architectural design 27

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 viewssuch 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.
Chapter 6 Architectural design 28
Chapter 6 – Architectural Design

Lecture 2

Chapter 6 Architectural design 29

Repository architecture

Sub-systems in a software system need to share data. This can be

done in two ways:
Central Database (Repository Model)
 All sub-systems use one common database.
 Data is stored in one place and everyone can access it.
 Easy to share, fast, and avoids duplication.
Separate Databases (Distributed Model)
 Each sub-system has its own database.
 If one sub-system needs data from another, it must send/receive it.
 More control, but harder to manage
If a large amount of data needs to be shared, the central repository is
better because it is efficient

Chapter 6 Architectural design 30

The Repository pattern

Name Repository

All data is stored in one central database, and components use

Description
it instead of talking to each other directly.

An IDE where all tools share the same design information

Example
repository.

When large amounts of data need to be stored for a long time,

When used
or in data-driven systems.

Components are independent, changes update everywhere,

Advantages
and data is easy to manage.

If the central database fails, the whole system fails;

Disadvantages
communication may be slow; hard to distribute.

Chapter 6 Architectural design 31

A repository architecture for an IDE

Chapter 6 Architectural design 32

Client-server architecture

Definition: A distributed system model where data and

processing are shared between clients and servers.
 Implementation: Can run on one computer (small scale)
or across many computers (large scale).
 Servers: Independent systems that provide specific
services (e.g., printing, file storage, databases).
 Clients: Users’ machines or programs that request
services from servers.
 Network: Connects clients and servers, allowing
communication and service access.

Chapter 6 Architectural design 33

The Client–server pattern

Name Client–server

System functions are split into services provided by servers

Description
and used by clients.

A film and DVD library system where clients access a central

Example
server.

When shared data must be accessed from many locations or

When used
when system load varies.

Servers can be distributed, and common services are

Advantages
available to all clients.

Single point of failure, performance depends on the

Disadvantages
network, and managing multiple servers can be difficult.

Chapter 6 Architectural design 34

A client–server architecture for a film library

Chapter 6 Architectural design 35

Pipe and filter architecture

 Data flows through a chain of processing steps. Each step (called a

Filter) does some work on the data and passes the result to the next
step using a Pipe.
– Think of it like an assembly line in a factory,
– Each worker (filter) does one specific job.
– The product (data) moves from one worker to the next through a conveyor belt
(pipe).
 Eg: UNIX Commands:
 cat [Link] | grep "word" | sort
 cat [Link] → reads the file (Filter 1).
 grep "word" → picks only lines with “word” (Filter 2).
 sort → arranges the lines in order (Filter 3).
 Each | is a pipe connecting them.
36
Pipe and filter architecture

Advantages
 It is easy to design, implement, test each filter independently.
Reusability – same filter can be reused in other systems
Disadvantages:
 Not suitable for interactive or real-time systems.

Works best for: Sequential data processing (data moves step by step).

Chapter 6 Architectural design 37

The pipe and filter pattern

Name Pipe and Filter

Data is processed step by step; each filter does one task and
Description
sends output to the next through pipes.

Example Invoice processing system, or cat file | grep word |

sort.
In batch or data processing systems where input passes through
When used
many stages.

Easy to understand, reusable filters, flexible, supports step-by-

Advantages
step or parallel execution.

Data format must match; extra work needed to convert data

Disadvantages
(overhead).

Chapter 6 Architectural design 38

An example of the pipe and filter architecture

Chapter 6 Architectural design 39

Application architectures

• Application architectures are ways to design software to meet

business or organizational needs.
• Many businesses have similar needs, so their software often follows
common patterns.
• A generic application architecture is like a template or blueprint for a
type of software system.
• It can be configured or adapted to create a system that meets
specific requirements.
Example: Like a house blueprint that can be customized with different
room sizes or gardens, a generic architecture can be customized for
different businesses.

Chapter 6 Architectural design 40

Use of application architectures

Chapter 6 Architectural design 41

Examples of application types

Chapter 6 Architectural design 42

Application type examples

Chapter 6 Architectural design 43

Transaction processing systems

Chapter 6 Architectural design 44

The structure of transaction processing
applications

Chapter 6 Architectural design 45

The software architecture of an ATM system

Chapter 6 Architectural design 46

Information systems architecture

Chapter 6 Architectural design 47

Layered information system architecture

Chapter 6 Architectural design 48

The architecture of the MHC-PMS

Chapter 6 Architectural design 49

Web-based information systems

 Information and resource management systems are now

usually web-based systems where the user interfaces
are implemented using a web browser.
 For example, e-commerce systems are Internet-based
resource management systems that accept electronic
orders for goods or services and then arrange delivery of
these goods or services to the customer.
 In an e-commerce system, the application-specific layer
includes additional functionality supporting a ‘shopping
cart’ in which users can place a number of items in
separate transactions, then pay for them all together in a
single transaction.
Chapter 6 Architectural design 50
Server implementation

 These systems are often implemented as multi-tier client

server/architectures (discussed in Chapter 18)
 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.

Chapter 6 Architectural design 51

Language processing systems

Chapter 6 Architectural design 52

The architecture of a language processing
system

Chapter 6 Architectural design 53

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.

Chapter 6 Architectural design 54

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.

Chapter 6 Architectural design 55

A pipe and filter compiler architecture

Chapter 6 Architectural design 56

A repository architecture for a language
processing system

Chapter 6 Architectural design 57

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.
Chapter 6 Architectural design 58