Architectural Design

Vũ Thị Hồng Nhạn

(vthnhan@vnu.edu.vn)

Dept. Software Engineering, FIT, UET

Vietnam National Univ., Hanoi

 Contents
 Architectural design decisions

 Architectural views

 Architectural patterns

 Application architectures

4/14/2025 Architectural design Page 2

 Architectural design
 Architectural design is concerned with understanding how a software
system should be organized and with designing the overall structure of that
system

 It serves as a critical link between requirements engineering and design, as

it identifies the main structural components of a system and the
relationships between them

 The output of the architectural design process is an architectural model that

describes how the system is organized as a set of communicating
components

4/14/2025 Architectural design Page 3

 Agility & architecture
 It’s generally accepted that an early stage of agile processes involves
designing an overall system architecture

 Refactoring the system architecture is usually expensive because it impacts

many components within the system

4/14/2025 Architectural design Page 4

 The architecture of a packing robot control system

4/14/2025 Architectural design Page 5

 Architectural abstraction
 Architecture in the small is concerned with the architecture of individual
programs

 At this level, the focus is on how a single program is decomposed into

components

 Architecture in the large refers to the architecture of complex enterprise

system that include other systems, programs, and program components

 These enterprise systems are typically distributed across multiple computers,

which may be owned and managed by different organizations

4/14/2025 Architectural design Page 6

 Advantages of explicit architecture
 For stakeholder communication

 Architecture may be used as a focus of discussion by system stakeholders

 For system analysis

 Analysis of whether the system can meet its non-functional requirements

 For large-scale reuse

 The architecture may be reusable across a range of systems

 Product-line architectures may be developed

4/14/2025 Architectural design Page 7

 Architectural representations
 Simple informal block diagrams showing entities and their relationships are

the most frequently used method for documenting software architectures

 However, they have been criticized for their lack of semantics, as they do

not indicate the types of relationships between entities or the visible

properties of the entities within the architecture

4/14/2025 Architectural design Page 8

 Box and line diagrams
 These diagrams are highly abstract, they don’t reveal the nature of

component relationships or the external visible properties of the sub-

systems

4/14/2025 Architectural design Page 9

 Use of architectural models
 As a way of facilitating discussion about the system design

 Useful for communication with the system stakeholders and for project planning, as it is
not cluttered with detail

 Stakeholders can relate to it and understand an abstract view of the system

 They can discuss the system as a whole without being confused by low-level details

 As a way of documenting an architecture that has been designed

 The aim here is co produce a complete system model that shows the different
components of the system, their interfaces, and their connection

4/14/2025 Architectural design Page 10

 Architectural design decisions
 Architectural design is a creative process, so that approach may vary
depending on the type of system being developed

 However, a number of common decisions are shared across all design processes,
and these decisions significantly influence the system’s non-functional
characteristics

VS.
w.r.t
performance

4/14/2025 Architectural design Page 11

Architectural design decisions

4/14/2025 Architectural design Page 12

 Architecture and system characteristics

 Performance
 Localize critical operations and minimize communication overhead
 Use large, coarse-grained components rather than fine-grained ones
 Security
 use a layered architecture, placing critical asset in the inner layers
 Safety
 localize safety-critical features within a small number of subsystems
 Availability
 include redundant components and implement mechanism for fault tolerance
 Maintainability
 Use fine-grained, replaceable components to ease updates and repairs

4/14/2025 Architectural design Page 13

 Architectural views
 What views or perspectives are useful when designing and documenting a system’s
architecture?

 What notions should be used to describe architectural model?

 Each architectural model represent only one view or perspective of the system

 For example, it might show how the system is decomposed into modules, how run-
time processes interact, or how system components are distributed across a network

 For both design and documentation process, it is usually necessary to represent

multiple views of the software architecture to capture different aspects of the system

4/14/2025 Architectural design Page 14

 Architectural views

4/14/2025 Architectural design Page 15

 4+1 view model of software architecture

 A logical view – shows the key abstraction of the system, typically represented as
objects or object classes
 A physical view – shows the system’s hardware and how the software components
are distributed across processors
 A development view – shows how the software is decomposed for development
purposes (e.g., into packages or modules)
 A process view shows how the system’s processes and threads interact at runtime
and how system components communicate. Useful for understanding performance,
scalability, and throughput.
 Related use cases or scenarios (+1) – illustrate how the system behaves in
practice and help validate the architecture across different views

4/14/2025 Architectural design Page 16

 Architectural patterns
 Patterns are means of representing, sharing, and reusing design knowledge

 An architectural pattern is a stylized description of a proven design practice that

has been tried and tested in various environments

 Patterns should include information about when they are applicable and when
they are not

 They may be requested using both tabular and graphical descriptions

4/14/2025 Architectural design Page 17

the Model-View-Controller(MVC) pattern

Name MVC

Description Separate representation and interaction from the system data by structuring the system
into 3 logical components that interact with each other
- The Model component manages the system data and the operations associated with
tat data
- The View component defines and manages how the data is represented to the user
- The Controller component handles user interaction (e.g., key presses, mouse clicks)
and passes these inputs to the View and the Model

Example Next slides shows the architecture of a web-based application system organization
using the MVC pattern

When used used when there are multiple ways to view and interact with data, or when future
requirements for data interaction and presentation are unknown

Advantages Allows data to change independently of its representation, and vice verse.
Supports representing the same data in different ways, with changes made in one
representation reflected in all others

Disadvantages can involve additional code and code complexity

 The organization of the MVC

4/14/2025 Architectural design Page 19

 Web application architecture using the MVC pattern

4/14/2025 Architectural design Page 20

 Layered architecture
 Organizes the system into a set of layers,
each providing a specific set of services

 Support incremental development of sub-

systems within different layers

 When a layer’s interface changes, only the

adjacent layers are affected

4/14/2025 Architectural design Page 21

The layered architecture pattern
Name Layered architecture
Description • Organizes the system into layers, with related functionality grouped within
each layer
• Each layer provides services to the layer above it, so the lowest layers
represent core services that are likely to be used throughout the system

When used • Building new facilities on top of existing systems

• Development is spread across several teams, with each team responsible for
a specific layer of functionality
• This is requirement for multi-level security

Advantages • Allows replacement of an entire layer as long as its interface is maintained

• Redundant facilities (e.g., authentication) can be included in each layer to
increase the system’s dependability
Disadvantages • In practice, achieving a clean separation between layers is often difficult
• A high-level layer may need to interact directly with lower-level layers, rather
than going through the layer immediately beneath it
• Performance can also be an issue, due to the multiple levels interpretation
involved in processing a service request through each layer

4/14/2025 Architectural design Page 22

 A generic layer architecture

4/14/2025 Architectural design Page 23

 The architecture of the iLearn system

4/14/2025 Architectural design Page 24

 Repository architecture
 Sub-systems must exchange data, and this can be done in two ways

 Shared data is stored in a central database or repository that can be accessed by all sub-
systems

 Each sub-system maintains its own database and explicitly passes data to other sub-
systems

 When large amounts of data need to be shared, the repository model is most
commonly used, as it provides an efficient mechanism for data sharing

4/14/2025 Architectural design Page 25

The repository pattern
Name repository
Description • All data in the system is managed in a central repository that is accessible to all
system components
• Components don’t interact with each other directly; instead they communicate
only through repository
When used • Used when the system generates large volumes of information that need to be
stored for a long time
• It’s also suitable for data-driven systems, where adding data to the repository
triggers actions or tools

Advantages • Components can be independently – they don’t need to be aware of the existence
of other components
• Changes made by one component can be propagated to all others
• All data can be managed consistently (e.g., backups can be performed at the same
time) since it’s stored in a single location
Disadvantages • Failure in the repository can affect the entire system
• Organizing all communication through the repository may be inefficient
• Distributing the repository across multiple computers can also be challenging

4/14/2025 Architectural design Page 26

 A repository architecture for an IDE
 An example of an IDE is one where components use a shared repository of
system design information
 Each software tool generates information that is then made available for use by
other tools

4/14/2025 Architectural design Page 27

 Client-server architecture
 A distributed system model that shows data and processing data are
distributed across a range of components

 It can also be implemented on….

 A single computer or a set of stand-alone servers that provide specific services

such as printing, data management, etc.

 A set of clients that request and use these services

 A network that allows clients to access the servers

4/14/2025 Architectural design Page 28

The client-server pattern
Name Client-server
Description • In a client-server architecture, the system’s functionality is organized into
services, with each service provided by a separate server
• Clients are users of these services and access the servers to make use of them

Example Fig.

When used • Used when data in a shared databased needs to be accessed from multiple
locations
• Because servers can be replicated, this model is also suitable when the system
experiences variable load
Advantages • The principle advantage of this model is that servers ca be distributed across a
network
• General functionality (e.g., printing service) can be made available to all
clients and doesn’t need to be implemented by every service

Disadvantages • Performance may be unpredictable, as it depends on both the network and

the system
• They may also be management challenges if servers are owned by different
organizations

4/14/2025 Architectural design Page 29

 A client-server architecture for a film library
An example of a film and video library organized as a client-server system

4/14/2025 Architectural design Page 30

 Pipe & filter architecture
 Functionality transformations process their inputs to produce outputs

 This may be referred to as a pipe and filter model

 Variants of this approach are very common

 When transformations are sequential, it’s called the batch sequential model,
which is widely used in data processing system

 However, it’s not well-suited for interactive systems

4/14/2025 Architectural design Page 31

The pipe and filter pattern
Name Pipe & filter
Description • The data processing in the system is organized so that each
processing component (filter) is discrete and performs a single type of
data transformation
• The data flows like a pipe from one component to the next for further
processing
Example Fig.

When used Commonly used in data processing applications (both batch and
transaction-based), where inputs are processed in separate stages to
generate related outputs
Advantages • The workflow style aligns well with the structure of many business
processes
• Evolution by adding new transformations is straightforward
• It can be implemented as either a sequential or concurrent system

Disadvantages • The data transfer format must be agreed upon by the communicating
transformations
• Each transformation must parse its input and format its output
according to its agreed format
• This adds systems overhead and may make it impossible to reuse
functional transformations that rely on incompatible data structure
4/14/2025 Architectural design Page 32
 An example of the pipe & filter architecture used in a
payment system

4/14/2025 Architectural design Page 33

 Application architectures
 Application systems are designed to meet an organization need

 As businesses have much in common, their application system also

tend to have a common architecture that reflects the application
requirements

 A generic application architecture is an architecture of a type of

software system that may be configured and adapted to create a system
that meets specific requirements

4/14/2025 Architectural design Page 34

 Use of application architectures
 As a starting point for architectural design

 As a design checklist

 As a way of organizing the work of the development team

 As a means of assessing components for reuse

 As a vocabulary for talking about application types

4/14/2025 Architectural design Page 35

 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-centered 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

4/14/2025 Architectural design Page 36

 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

4/14/2025 Architectural design Page 37

 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

 E.g., Find the times of flights from London to Paris

 The structure of transaction processing applications

4/14/2025 Architectural design Page 38

 The software architecture of an ATM system

4/14/2025 Architectural design Page 39

 Information systems architecture
 Information systems have a generic architecture that can be organized 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 databases

4/14/2025 Architectural design Page 40

 Layered information system architecture

4/14/2025 Architectural design Page 41

 The architecture of the Mentcare system

4/14/2025 Architectural design Page 42

 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

 E.g., 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

4/14/2025 Architectural design Page 43

 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

 The architecture of LP system

4/14/2025 Architectural design Page 44

 Compiler components
 A lexical analyzer, which takes input language token 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

4/14/2025 Architectural design Page 45

 Compiler components
 A semantic analyzer that uses information from the syntax tree and the
symbol table to check the semantic correctness for the input language text

 A code generator that ‘walks’ the syntax tree and generates abstract
machine code

4/14/2025 Architectural design Page 46

 A repository architecture for a language processing system

4/14/2025 Architectural design Page 47

 A pipe and filter compiler architecture

4/14/2025 Architectural design Page 48

 Key points
 A software architecture is a description of how a software system is
organized

 Architectural design decision 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 an describe its
advantages and disadvantages

4/14/2025 Architectural design Page 49

 Key points
 Models of application systems architectures help us understand and
compare applications, validate application system design 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 try out the instructions specified in the input language

 They include a translator and an abstract machine that executes the generated
language

4/14/2025 Architectural design Page 50