SOFTWARE ENGINEERING

CHAPTER 4.
SOFTWARE ARCHITECTURE

NGUYỄN QUANG VŨ. PhD

E-mail: nqvu@vku.udn.vn
Handphone: 0901.982.982
CONTENTS

▪ The relationship between software requirements

and architecture;

▪ The relationship between architectural styles and

architecture;

▪ The elements of software architecture;

▪ Common software architecture styles;

▪ REFERRENCES
▪ Fundamentals of Software Architecture: An
Engineering Approach, Mark Richards, Neal Ford,
2020;
▪ Software Architecture in Practice 3rd Edition, Len
Bass, Paul Clements, Ken Bass, 2015;
1. OVERVIEW
▪ Main Software Development Activities
▪ The goal of software design is to build a
Requirements Gathering Analysis Design
model that meets all customer requirements
Define requirement Define the conceptual Design the solution /
and leads to successful implementation; specification model software plan

▪ The success of a software product or system Implementation Integration and Test

Deployment
Code the system based on Prove that the system
largely depends on the success of its Installation and training
the design meets the requirements

architecture design; Maintenance

Post-install review
Support docs
Active support
1. OVERVIEW
▪ What is the software architecture?
▪ IEEE 1471:2000: “The fundamental organization of a system embodied in
its components, their relationships to each other, and to the environment,
and the principles guiding its design and evolution.”
▪ Shaw and Garlan (1996): The description of elements that comprise a
system, the interactions and patterns of these elements, the principles that
guide their composition, and the constraints on these elements.
1. OVERVIEW
▪ Who is responsible for developing the architecture design??
▪ Software architects and designers who translate (map) the software system
requirements into architecture design.
▪ apply various design strategies to
- divide and conquer the complexities of an application domain;
- resolve the software architecture;
.
1. OVERVIEW
▪ Why is software architecture design so important?
▪ A good software design
▪ Reduces risks in software products;
▪ Coordinates development teams to work together orderly;
▪ Makes the system traceable for implementation and testing;
▪ Leads to software products have higher quality attributes.
▪ A poor software design
▪ The software does not meet the user requirements as well as not adaptive to future
requirement changes;
▪ The software is hard to reuse;
▪ The software performs functions not as expected by the user.
▪ ….
1. OVERVIEW
▪ Software architecture plays a very important role in the SDLC.

▪ The input of software design is the Software Requirements Specification (SRS)

▪ The output of software design is the Software Design Description (SDD)

▪ the software architecture or high-level design
▪ the detailed design of the system.
2. ARCHITECTURAL STYLES
▪ Also known as “Architecture Patterns”;

▪ Abstracts the common properties of a family of similar designs;

▪ Contains a set of rules, constraints, and patterns of how to structure a system

into a set of elements and connectors.
▪ Governs the overall structure design pattern of constituent element types and
their runtime interaction of flow control and data transfer.
2. ARCHITECTURAL STYLES
▪ 4 key components

Elements Connectors
Performing functions required by a Enabling communication, coordination, and
system cooperation among elements

Attributes Constraints
The advantages and disadvantages of the Defining how elements can be integrated to form
chosen structure the system
3. SOFTWARE ARCHITECT’S TASKS
▪ Perform system static partitioning

▪ System decomposition into sub-systems and communications between sub-

systems;

▪ A software element (sub-system) can be: configured, delivered, developed, deployed

and is replaceable in future.

▪ Each element has its interface that encapsulates details and provides loose coupling

with others.
3. SOFTWARE ARCHITECT’S TASKS
▪ Establish dynamic control relationships
▪ between different sub-systems in terms of
▪ Data flow;
▪ Control flow orchestration;
▪ Message dispatching.
▪ Consider and evaluate
▪ alternative architecture styles for the problem at hand.
▪ Perform trade-off analysis on quality attributes and other non-functional
requirements
▪ during the selection of architecture styles.
▪ The most important jobs
▪ To map the software requirements specification to the software architecture
▪ To guarantee that the software architecture satisfies functional and non-
functional requirements.
4. COMMON SOFTWARE ARCHITECTURE PATTERNS
▪ Monolithic
▪ Data Flow Architecture: Batch Sequence, Pipe & Filter, Process Control;
▪ Data Centered Architecture: Repository, Blackboard;
▪ Object-Oriented; Component-Based; Service-Based;
▪ Hierarchy Architecture: Layered, Virtual Machine, Main/Subroutine;
▪ Distributed Architecture: Multi-tier, Client/Server;
▪ Asynchronous Communication Architecture: Event-Based, Buffered Messaging;
▪ Interaction Oriented Architecture: MVC, PAC;
▪ Microservices Architecture;
4.1 Monolithic
▪ The software has only one “package” and
contains everything of the program in it;

▪ Communication between components is local and

very efficient;

▪ Only suitable for small and simple software.

4.2 Data Flow Architecture
▪ System as a sequence of successive data transformations through ordered data
processing components;

▪ The output of the preprocessor is the input of the postprocessor;

 4.2 Data Flow Architecture
▪ 4.2.1 Batch Sequential Architecture (BSA)
▪ The traditional data processing model which was widely used in the 1950s - 1970s.

▪ In BSA, each sub-system (data transformation module) cannot start its process until its
previous subsystem completes the computation.

▪ A data stream carries “a common packet of data” to be transferred from one subsystem to
another.

▪ This architecture is effective in building business data processing applications such as

banking and billing utility.

Data 0 Data 1 Data 2 Data 3 Data 4

Filter 1 Filter 2 Filter 3 Filter 4
4.2 Data Flow Architecture
▪ 4.2.1 Batch Sequential Architecture (BSA)
▪ Benefits:
▪ Simple divisions on sub-systems.
▪ Each sub-system can be a stand-alone program working on input data and producing
output data.
▪ Limitations:
▪ Implementation requires external control.
▪ Does no provide interactive interface.
▪ Concurrency is not supported and hence throughput remains low.
▪ High latency.
KIẾN TRÚC LUỒNG DỮ LIỆU (Data Flow Architecture)
▪ 4.2.1 Batch Sequential Architecture (BSA)
Rejected

Example transaction

-123 U
Validated Sorted
Transaction File transaction
transaction

222 U
222 U 111 I
111 I
Validate 111 I sort 222 U
333 D
333 D 333 D
-123 U

100 ----
Update
111 ----
200 ----
222 ----
Generate Report 444 ----

Reports 100 ---

Updated 200 ---
Master file 222 ---
333 ---
444 ---

Master file
 KIẾN TRÚC LUỒNG DỮ LIỆU (Data Flow Architecture)
▪ 4.2.2 Pipes and Filters
▪ The upgrade/improvement of the “Sequential batch” architecture;

▪ The system is divided into 4 components: Data Source - Pipes - Filters (optional standalone
software) - Data Sinks ;

▪ Connections between components are data streams;

▪ Two main quality attributes: Concurrent and Incremental;

Data 1 Data 3 Data 5

Data Filter 2 Filter 3 Data 7 Data
Data 0
Source Filter 1 Filter 4 Sink
Data 4
Data 2 Filter 2 Filter 3 Data 6
4.2 Data Flow Architecture
▪ 4.2.2 Pipes and Filters
▪ Pipe
▪ Moves data stream from one filter to another filter.
▪ Can carry the binary streams or the character streams.
▪ Filter
▪ Is an independent data stream transformer: reads data from its input data stream - transforms
and processes it - writes the transformed data stream over a pipe for the next filter to process.
▪ Does not need to wait for batched data as a whole: As soon as the data arrives through the
connected pipe, the filter can start working right away.
▪ Does not even know the identity of data upstream or data downstream: A filter is just
working in a local incremental mode.
4.2 Data Flow Architecture
▪ 4.2.2 Pipes and Filters
▪ Data transfer types
▪ Push only (Write only)
A data source may pushes data in a downstream.
A filter may push data in a downstream.
▪ Pull only (Read only)
A data sink may pull data from an upstream.
A filter may pull data from an upstream.
▪ Pull/Push (Read/Write)
A filter may pull data from an upstream and push transformed data in a downstream.
4.2 Data Flow Architecture
▪ 4.2.2 Pipes and Filters
▪ Example data source: filter1: pipe: filter2: data sink:
Data Source Filter pipe Filter Data Sink

read

Filter1

W
Filter2
R

write

Data Source Filter1 Filter2 Data Sink

pipe
 4.2 Data Flow Architecture
▪ 4.2.2 Pipes and Filters
▪ Example

e
a
b
c
e
A2
c Upper Case ECBAE DEF Matching (A , E ) AE (Sort * Count )
def ac E2
a Conversion Filter Filter Filter
f
e
d

Data Source
Data Sink
4.2 Data Flow Architecture
▪ 4.2.2 Pipes and Filters
▪ Benefits:

▪ Concurrency – Reusability – Modifiability – Simplicity - Flexibility.

▪ Limitations:

▪ Not suitable for dynamic interactions.

▪ Low Common Denominator (Unpopular)

▪ Is required for data transmission in the ASCII formats

▪ Overhead of data transformation among filters.

4.2 Data Flow Architecture
▪ 4.2.3 Process-Control Architecture
▪ Is suitable for the embedded system software design where the system is manipulated by a
process control variable data, e.g., cars cruise-control systems or temperature control
systems.

▪ Decomposes the whole system into: sub-systems (modules) and connections between sub-
systems.

▪ There are 2 types of sub-systems:

▪ Executor processing unit: for changing process control variables

▪ Controller unit: for calculating the amounts of the changes.

4.2 Data Flow Architecture
▪ 4.2.3 Process-Control Architecture
▪ Elements of Controller Unit:

▪ Controlled Variable provides values for the underlying system and should be measured
by sensors. For example, speed in cruise control system.

▪ Input Variable measures an input to the process. For example, temperature of return air
in temperature control system

▪ Manipulated Variable is adjusted or changed by the controller.

▪ Sensor obtains values of process variables pertinent to control and can be used as a
feedback reference to recalculate manipulated variables
4.2 Data Flow Architecture
▪ 4.2.3 Process-Control Architecture
▪ Elements of Executor processing Unit:

▪ Process Definition includes mechanisms for manipulating some process variables.

▪ Set Point: desired value for a controlled variable.

▪ Control Algorithm: is used for deciding how to manipulate process variables.

4.2 Data Flow Architecture
▪ 4.2.3 Process-Control Architecture
▪ Example
4.3 Data Centered Architecture (DCA)
▪ The software system is decomposed into two major partitions: data store and
independent software component or agents.
▪ The centralized data store is built for sharing to all surrounding software
components;
▪ The connections between the data module and the software components are
implemented either by explicit method invocation or by implicit method
invocation.
▪ There are 2 architectural models (and they are
distinguished by the flow control strategy):
▪ Repository;
▪ Blackboard;
4.3 Data Centered Architecture
▪ 4.3.1 Repository:
▪ The data store (repository) is passive and
agents (software components) are active;

▪ The agents control the logic flow and

may access the repository interactively or
by a batch transaction request.

▪ Suitable for large, complex information

systems with multiple agents access to
the data store;
4.3 Data Centered Architecture
▪ 4.3.1 Repository:
▪ Advantages: Data integrity – Ease of backup and recovery – Easy software
interchangeability and scalability – No data communication between software units;

▪ Disadvantages: The system depends on the structure, security and availability of the data
warehouse;

▪ Example
4.3 Data Centered Architecture
▪ 4.3.2 Blackboard:
▪ The idea of blackboard architecture is similar to the classroom blackboard setting used in
solving problems without deterministic outcome;
▪ Software units (Agents) can work in parallel and very independently, and will try their best
to work together to find the best solution;
▪ Blackboard (Data store) is Active
▪ is used to store data (hypotheses and facts);
▪ Agents (knowledge sources) are Passive
▪ are where the domain-specific knowledge
is stored.
4.3 Data Centered Architecture
▪ 4.3.2 Blackboard:
▪ Besides the Blackboard and the Knowledge Sources, there may be a third partition called the
controller that is used:

▪ to initiate the blackboard and knowledge sources,

▪ and, that takes a bootstrap role and overall supervision control;

4.3 Data Centered Architecture
▪ 4.3.2 Blackboard:
▪ The connection between Blackboard and Knowledge Sources through implicit invocations;

▪ The change of data in Blackboard will trigger (active) one or more Knowledge Sources
(passive) for further processing;

▪ Data changes may be caused by new

deduced information or hypotheses

results by some knowledge sources;

4.3 Data Centered Architecture
▪ 4.3.2 Blackboard:
Advantages
▪ Scalability – Concurrency, parallelism – Reusability – Hypothesis support;
Disadvantages
▪ Changing the Blackboard structure (may) result in changes to the Knowledge
Sources;
▪ The solutions given are only “partially correct” or “approximate”;
▪ There will be conflicts without synchronization and prioritization;
▪ Debugging and testing problems;
4.3 Data Centered Architecture
▪ 4.3.2 Blackboard:
▪ Example
4.3 Data Centered Architecture
▪ 4.3.2 Blackboard:
▪ Example
4.4 Object-Oriented Architecture
▪ A software system is a collection of loosely connected objects and
relationships between them;

▪ Object = attributes + methods);

▪ Objects communicated by exchanging messages to perform a task;

System Object 2

Object 3
Object 1

Object 4
4.4 Object-Oriented
▪ Concepts:
▪ Abstraction;

▪ Inheritance;
▪ Encapsulation;

▪ Polymorphism;

▪ Design principles:
▪ High Cohesion;

▪ Low Coupling;

▪ SOLID (Single-responsiblity principle; Open-closed principle; Liskov substitution principle;

Interface segregation principle; Dependency Inversion Principle);
4.4 Object-Oriented
▪ Advantages:

▪ Very close to the real world;

▪ Easy to reuse;

▪ Hide information (encapsulation);

▪ Lower development cost (inheritance);

▪ Suitable for complex systems;

▪ Disadvantages :
▪ Difficulty to determine all the necessary classes and objects required for a system;
4.5 Component-Based Architecture
▪ The system (problem) is divided into subproblems, each of which is solved by
a specific (software) component;
▪ A component holds a specific functionality/behavior that can be packaged,
deployed, and reused independently;
▪ Each component can request “services” from other components;
▪ The components can be reused;
▪ The interfaces of components play an extremely important role, the
components can change but ensure the interface does not change;
▪ The software system has high reliability;
4.5 Component-Based Architecture
▪ Example:
4.6 Hierarchical Architecture
▪ The hierarchical software architecture is characterized by viewing the whole system
as a hierarchy structure.
▪ The software system is decomposed into logical modules (sub-systems) at different
levels in the hierarchy.
▪ Modules at different levels are connected by explicit or implicit method invocations.
▪ A lower level module provides services to its adjacent upper level modules, which
invokes the methods or procedures in lower level.
4.6 Hierarchical Architecture
▪ 4.6.1 Main-Subroutine Architecture
▪ The system is divided from the main program into
many smaller subroutines in different levels
according to the functional requirements;

▪ Decomposition ends when the lowest-level

subroutines are simple enough but can independently
perform a single function;

▪ Programs can also be invoked by more than one

program above (reuse);
4.6 Hierarchical Architecture
▪ 4.6.1 Main-Subroutine Architecture
▪ Data passed as parameters from the "calling" program to the subroutines by two ways:

- Pass By Value;

- Pass By Reference;);
4.6 Hierarchical Architecture
▪ 4.6.2 Master – Slaves Architecture
▪ The Master-Slave architecture is a variant of the main-subroutine architecture style that
supports fault tolerance and system reliability.

▪ In this architecture, slaves provide replicated services to the master, and the master selects
a particular result among slaves by certain selection strategy.

▪ The slaves may perform the same functional task by different algorithms and methods or
totally different functionality.
4.6 Hierarchical Architecture
▪ 4.6.2 Master – Slaves Architecture
▪ Used to design systems requiring high
reliability;

▪ For example:

▪ Designing the redundant server

systems (replication/redundancy);

▪ Designing the distributed database

servers;
4.6 Hierarchical Architecture
▪ 4.6.3 Layered
▪ The system is divided into several layers, each with a unique,
separate function/responsibility;

▪ A (simple) software system can consist of 2 layers: Interaction

Layer and Processing Layer;
4.6 Hierarchical Architecture
▪ 4.6.3 Layered Architecture
▪ Example
4.6 Hierarchical Architecture
▪ 4.6.4 Virtual-Machine Architecture
▪ System Like an emulator;;

▪ A virtual machine is built up on an existing system and provides a virtual abstraction, a

set of attributes, and operations;

▪ Example

▪ CLR virtual machine in .Net Platform

4.6 Hierarchical Architecture
▪ 4.6.4 Virtual-Machine Architecture
▪ Example

▪ Virtual Machine in Java

4.7 Distributed Architecture
▪ A distributed system is a collection of computational
and storage devices connected through a
communications network.

▪ In this kind of systems: data, software, and users are

distributed.

▪ The sub-systems or components within a distributed

system communicate with each other using a number of
methods including message passing, remote procedure
call, remote method invocation, etc.
4.7 Distributed Architecture
▪ 4.7.1 Multi-tiers Architecture
4.7 Distributed Architecture
▪ 4.7.2 Broker Architecture
4.7 Distributed Architecture
▪ 4.7.3 Service Oriented Architecture (SOA)
4.7 Distributed Architecture
▪ 4.7.3 SOA and Grid Computing
4.8 Interaction Oriented Architecture
▪ 4.8.1 Model-View-Controller
4.8 Interaction Oriented Architecture
▪ 4.8.2 Presentation-Abstraction-Controller
4.9 Microservice Architecture
▪ Microservice is a service-based application development methodology.
▪ Big applications will be divided into smallest independent service units.
▪ Microservice is the process of implementing SOA by dividing the entire
application as a collection of interconnected services, where each service will
serve only one business need.
▪ The small units will communicate to each other using different protocols to
deliver successful business to the client.
=> SOA is a designing pattern and Microservice is an implementation
methodology to implement SOA.
4.9 Microservice Architecture
▪ Advantages
▪ Small in size;

▪ Focused;

▪ Autonomous;

▪ Technology heterogeneity;

▪ Resilience;

▪ Ease of deployment;
4.9 Microservice Architecture
▪ Example
Chapter 4.
SOFTWARE ARCHITECTURE