Software Architecture

Objectives
 Definition of software architecture.
 Important of software architecture.
 Architecture design patterns.
 Relationship between non-functional requirements and software architecture.
Brainstorming
 Software Architecture
 Identifying the sub-systems/components that make up a system and the
framework for sub-systems control & communication is known as the
architectural design.

 The primary purpose of architecture to support the life cycle of the system.
Good architecture makes the system easy to understand, easy to
develop, easy to maintain, and easy to deploy. The ultimate goal is to
minimize the lifetime cost of the system and to maximize programmer
productivity.

 It can serve as a design plan to negotiate system requirements among

clients, developers and managers.

 Process output: is an architectural model that describes how the

system is organized as a set of communicating components.
Architectural design (When)
 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.
Two levels of Abstraction for the
Software Architectural Design
1. 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.

2. Architecture in the large is concerned with the architecture of complex

enterprise systems that include other systems, programs, and program
components (distributed systems).
System Organization

 Reflects the basic strategy that is used to structure a system.

 Three widely used organizational patterns:

(1). Shared Data Repository Pattern.
(2). Client-Server Pattern.
(3). Layered Pattern.
(1). The Repository Pattern
 Sub-systems must exchange data. This may be done in two ways:
 Shared data is held in a central database or repository and accessed by all sub-
systems;
 Each sub-system maintains its own database and passes data explicitly to other
sub-systems.

 For large amounts of shared data, the repository model is most commonly
used.
Design Code
editor gener ator

Design Project Pr ogram

transla tor repository editor

Design Repor t
anal yser gener ator
Repository Pattern Evaluation

(+) Advantages
 Centralised management e.g. backup, security, etc.
(-) Disadvantages
 The repository is a single point of failure so problems in the
repository affect the whole system.
(2). The Client-Server Pattern

 Set of servers; each provides a specific service such as printing, file

management or email.

 All clients call on these servers through a network that allows them to access
services .

Client 1 Client 2 Client 3 Client 4

Internet

Catalogue Video Picture

server server server Web server

Library Film clip Digitised Film and

catalogue files photo g raphs photo info.
Client-server Evaluation

(+) Advantages
 Easy to add new servers or upgrade existing servers.

(+) Disadvantages
 Redundant management in each server.
(3). The Layered Pattern
 Used to model the interfacing of sub-systems.
 Organizes the system into a set of layers each of which provide a set of
services.
 Supports the incremental development of sub-systems in different layers.
When a layer interface changes, only the adjacent layer is affected.
A Generic Layered Architecture
Pattern for Software Applications
The Layered Pattern

(+) Advantages
 Multiple applications can reuse the components. For example if we
want a windows user interface rather than a web browser interface.

(+) Disadvantages
 There might be a negative impact on the performance.
Architecture Vs System Characteristics
 Performance (if Performance is a critical requirement)
 Localize critical operations & minimize communications. Use large rather than
fine-grain components.
 Security (if Security is a critical requirement)
 Use a layered architecture with critical assets in the innermost layers, with a
high level of security validation.
 Availability (if Availability is a critical requirement)
 Include redundant components and mechanisms, so that it is possible to
replace and update components without stopping the system.

Compromise solution must be found; different architecture styles for different

parts of the system can be applied!
Conclusion and Summary
 In every case, the best option is for the development organization to
recognize and avoid its own overconfidence and to start taking the quality of
its software architecture seriously.
 To take software architecture seriously, you need to know what good
software architecture is.
 To build a system with a design and an architecture that minimize effort
and maximize productivity, you need to know which attributes of system
architecture lead to that end.
References

 Sommerville, I. (2016) Software Engineering. 10th Edition, Pearson Education Limited, Boston.