CEN512

COMPUTER
SOFTWARE
ENGINEER
ING (2 II
Course Lecturers:
units)
Dr. Odu Tiwalade & Mr Emmanuel.
Simonyan Department of Electrical &
Information Engineering Covenant University

1
Software architecture 1

2 © Ian Sommerville 2018

Course Learning Outcomes

By the end of the course:

• Students will demonstrate an understanding why the
architectural design of the software is important

• Students will learn how the decisions that have to be made

about the system architecture during the architectural
design process;

• Students will develop the idea of architectural patterns,

well-tried ways of organizing system architectures, which
can be reused in system designs.
 Software architecture
• To create a reliable, secure and efficient product, you need
to pay attention to architectural design which includes:
• its overall organization,
• how the software is decomposed into components,
• the server organization
• the technologies that you use to build the software. The
architecture of a software product affects its performance,
usability, security, reliability and maintainability.
• There are many different interpretations of the term
‘software architecture’.
• Some focus on ‘architecture’ as a noun - the structure of a
system and others consider ‘architecture’ to be a verb - the
process of defining these structures.

4
The IEEE definition of software
architecture
• Architecture is the fundamental organization of a software
system embodied in its components, their relationships to
each other and to the environment, and the principles
guiding its design and evolution.

5
 Software architecture and
components
• A component is an element that implements a coherent
set of functionality or features.
• Software component can be considered as a collection of
one or more services that may be used by other
components.
• When designing software architecture, you don’t have to
decide how an architectural element or component is to
be implemented.
• Rather, you design the component interface and leave
the implementation of that interface to a later stage of
the development process. 6
Access to services provided by software components

7
 Why is architecture important?

• Architecture is important because the architecture of a

system has a fundamental influence on the non-
functional system properties.
• Architectural design involves understanding the issues
that affect the architecture of your product and creating
an architectural description that shows the critical
components and their relationships.
• Minimizing complexity should be an important goal for
architectural designers. Because The more complex a
system, the more difficult and expensive it is to
understand and change. 8
Issues that influence architectural decisions

9
The importance of architectural design issues
Nonfunctional product characteristics
Nonfunctional product characteristics such as security and performance affect all users. If you get
these wrong, your product will is unlikely to be a commercial success. Unfortunately, some
characteristics are opposing, so you can only optimize the most important.

Product lifetime
If you anticipate a long product lifetime, you will need to create regular product revisions. You therefore
need an architecture that is evolvable, so that it can be adapted to accommodate new features and
technology.

Software reuse
You can save a lot of time and effort, if you can reuse large components from other products or open-
source software. However, this constrains your architectural choices because you must fit your design
around the software that is being reused.

Number of users
If you are developing consumer software delivered over the Internet, the number of users can change
very quickly. This can lead to serious performance degradation unless you design your architecture so
that your system can be quickly scaled up and down.

Software compatibility
For some products, it is important to maintain compatibility with other software so that users can adopt
your product and use data prepared using a different system. This may limit architectural choices, such10
as the database software that you can use.
Trade off: Maintainability vs performance
• System maintainability is an attribute that reflects how
difficult and expensive it is to make changes to a system
after it has been released to customers.
• You improve maintainability by building a system from small
self-contained parts, each of which can be replaced or
enhanced if changes are required.
• In architectural terms, this means that the system
should be decomposed into fine-grain components, each
of which does one thing and one thing only.
• However, it takes time for components to communicate with
each other. Consequently, if many components are involved
in implementing a product feature, the software will be
slower. 11
Trade off: Security vs usability
• You can achieve security by designing the system protection as
a series of layers (Figure 3).
• An attacker has to penetrate all of those layers before the system is
compromised.
• Layers might include system authentication layers, a separate
critical feature authentication layer, an encryption layer and so
on.
• Architecturally, you can implement each of these layers as
separate components so that if one of these components is
compromised by an attacker, then the other layers remain intact.

12
Figure 3 Authentication layers

13
Usability issues
• A layered approach to security affects the usability of the
software.
• Users have to remember information, like passwords, that is
needed to penetrate a security layer. Their interaction with the
system is inevitably slowed down by its security features.
• Many users find this irritating and often look for work-arounds
so that they do not have to re-authenticate to access system
features or data.
• To avoid this, you need an architecture:
• that doesn’t have too many security layers,
• that doesn’t enforce unnecessary security,
• that provides helper components that reduce the load on users.14
Trade off: Availability vs time-to-market
• Availability is particularly important in enterprise products, such as
products for the finance industry, where 24/7 operation is expected.
• The availability of a system is a measure of the amount of ‘uptime’
of that system.
• Availability is normally expressed as a percentage of the time that a
system is available to deliver user services.
• Architecturally, you achieve availability by having redundant
components in a system.
• To make use of redundancy, you include sensor components that detect
failure, and switching components that switch operation to a redundant
component when a failure is detected.
• Implementing extra components takes time and increases the cost
of system development. It adds complexity to the system and
therefore increases the chances of introducing bugs and
15
vulnerabilities.
Trade off: Availability vs time-to-market
• Availability is particularly important in enterprise products, such as
products for the finance industry, where 24/7 operation is expected.
• The availability of a system is a measure of the amount of ‘uptime’
of that system.
• Availability is normally expressed as a percentage of the time that a
system is available to deliver user services.
• Architecturally, you achieve availability by having redundant
components in a system.
• To make use of redundancy, you include sensor components that detect
failure, and switching components that switch operation to a redundant
component when a failure is detected.
• Implementing extra components takes time and increases the cost
of system development. It adds complexity to the system and
therefore increases the chances of introducing bugs and
16
vulnerabilities.
Architectural design questions
• How should the system be organized as a set of
architectural components, where each of these
components provides a subset of the overall system
functionality?
• The organization should deliver the system security, reliability
and performance that you need.
• How should these architectural components be distributed
and communicate with each other?
• What technologies should you use in building the system
and what components should be reused?

17
 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:
• 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?
©Ian Sommerville 2018 Software Engineering, 9th edition 18
• 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/styles, which capture the essence of an
architecture and can be instantiated in different ways.

19
Non-functional system requirements

The particular architectural style should depend on the non-

functional system requirements:
• Performance: localize critical operations and minimize
communications. Use large rather than fine-grain components.
• Security: use a layered architecture with critical assets in the
inner layers.
• Safety: localize 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.

20
Architectural Design Process
• The architectural design process involves systematic planning to
create an effective and functional structure for the software
system.
• Requirements Gathering: Define the functional and non-functional
requirements.
• Component Identification: Identify components to meet these
requirements.
• Design Patterns Selection: Choose patterns like microservices or
client-server that fit system requirements.
• Trade-Off Analysis: Balance between attributes (e.g., performance
vs. security).
• Architectural design is frequently documented using Unified
Modeling Language (UML) and flowcharts, providing visual
guidance for implementation.
21
 System Decomposition
• System decomposition is the process of dividing a software system
into smaller, more manageable components, each of which handles a
specific subset of the overall system functionality.
• Modularity: Each component serves a single purpose, making it easy
to understand and manage.
• Independence: Components can operate and be updated
independently, facilitating a flexible development environment.
• Components are the essential building blocks of a software system,
performing specific tasks that contribute to the overall system
functionality. Each component is responsible for a particular function
and interacts with other components through defined interfaces.
• In modern architectures, components often function as services. These
services are designed to be modular, reusable, and accessible through
APIs, allowing them to integrate seamlessly into different applications

22
Source: Skhodali E-commerce system 23
Component organization
• Abstraction in software design means that you focus on the
essential elements of a system or software component
without concern for its details.
• At the architectural level, your concern should be on large-
scale architectural components.
• Decomposition involves analysing these large-scale
components and representing them as a set of finer-grain
components.
• Layered models are often used to illustrate how a system is
composed of components.
24
An architectural model of a document retrieval system

25
Architectural Complexity
• Architectural complexity refers to the intricacies introduced by
interdependencies among system components. High complexity can
hinder system maintainability, as intricate dependencies increase the
difficulty of modifying or updating the system without introducing
errors.
• Managing Complexity:
To address complexity, architectural designs often focus on modularity
and encapsulation, minimizing dependencies between components
and making them self-sufficient.

26
Architectural complexity
• Complexity in a system architecture arises because of the
number and the nature of the relationships between
components in that system.
• When decomposing a system into components, you should
try to avoid unnecessary software complexity.
• Localize relationships
If there are relationships between components A and B, these are
easier to understand if A and B are defined in the same module.
• Reduce shared dependencies
Where components A and B depend on some other component or
data, complexity increases because changes to the shared
component mean you have to understand how these changes affect
both A and B.
• It is always preferable to use local data wherever possible
and to avoid sharing data if you can. 27
Examples of component relationships

28
Architectural design guidelines

29
Design guidelines and layered architectures
• Each layer is an area of concern and is considered separately from other
layers.
• The top layer is concerned with user interaction, the next layer down with user
interface management, the third layer with information retrieval and so on.
• Within each layer, the components are independent and do not overlap in
functionality.
• The lower layers include components that provide general functionality so there is
no need to replicate this in the components in a higher level.
• The architectural model is a high-level model that does not include
implementation information.
• Ideally, components at level X (say) should only interact with the APIs of the
components in level X-1. That is, interactions should be between layers and not
across layers. 30
A generic layered architecture for a web-based application

31
 Layer functionality in a web-based application
• Browser-based or mobile user interface
A web browser system interface in which HTML forms are often used to collect user input. Javascript
components for local actions, such as input validation, should also be included at this level.
Alternatively, a mobile interface may be implemented as an app.
• Authentication and UI management
A user interface management layer that may include components for user authentication and web
page generation.
• Application-specific functionality
An ‘application’ layer that provides functionality of the application. Sometimes, this may be expanded
into more than one layer.
• Basic shared services
A shared services layer, which includes components that provide services used by the application
layer components.
• Database and transaction management
A database layer that provides services such as transaction management and recovery. If your
application does not use a database then this may not be required. 32
Name Layered architecture
Organizes the system into layers with related functionality associated
with each layer. A layer provides services to the layer above it so the
Description
lowest-level layers represent core services that are likely to be used
throughout the system.

Used when building new facilities on top of existing systems; when the
development is spread across several teams with each team
When used
responsibility for a layer of functionality; when there is a requirement
for multi-level security.

Allows replacement of entire layers so long as the interface is

Advantages maintained. Redundant facilities (e.g., authentication) can be provided
in each layer to increase the dependability of the system.

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

and a high-level layer may have to interact directly with lower-level
Disadvantages 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 processed at each layer.
33
 Distribution architecture
• The distribution architecture of a software system defines the servers in
the system and the allocation of components to these servers.
• Client-server architectures are a type of distribution architecture that is
suited to applications where clients access a shared database and
business logic operations on that data.
• In this architecture, the user interface is implemented on the user’s own
computer or mobile device.
• Functionality is distributed between the client and one or more server
computers.

34
Client-server architecture

35
Client-server communication
• Client-server communication normally uses the HTTP protocol.
• The client sends a message to the server that includes an instruction
such as GET or POST along with the identifier of a resource (usually a
URL) on which that instruction should operate. The message may
also include additional information, such as information collected
from a form.
• HTTP is a text-only protocol so structured data has to be
represented as text. There are two ways of representing this
data that are widely used, namely XML and JSON.
• XML is a markup language with tags used to identify each data item.
• JSON is a simpler representation based on the representation of
objects in the Javascript language.

36
Client-server architecture
• Distributed system model which shows how data and
processing is distributed across a range of components,
but can also be implemented on a single computer.
• 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.

37
Client-server architecture

38
Name Client-server
In a client-server architecture, the functionality of the system is
organized into services, with each service delivered from a
Description
separate server. Clients are users of these services and access
servers to make use of them.
Used when data in a shared database has to be accessed from a
When used range of locations. Because servers can be replicated, may also
be used when the load on a system is variable.
The principal advantage of this model is that servers can be
distributed across a network. General functionality (e.g., a
Advantages
printing service) can be available to all clients and does not need
to be implemented by all services.

Each service is a single point of failure so susceptible to denial of

service attacks or server failure. Performance may be
Disadvantages unpredictable because it depends on the network as well as the
system. May be management problems if servers are owned by
different organizations.
39
The model-view-controller pattern

40
Model-View-Controller
• Serves as a basis of interaction management in many
web-based systems.
• Decouples three major interconnected components:
• The model is the central component of the pattern that directly
manages the data, logic and rules of the application. It is the
application's dynamic data structure, independent of the user
interface.
• A view can be any output representation of information, such
as a chart or a diagram. Multiple views of the same information
are possible.
• The controller accepts input and converts it to commands for
the model or view.
• Supported by most language frameworks.
41
Model-View-
Controller

42
Pattern name Model-View-Controller (MVC)
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
Description
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.
The display presented to the user frequently changes over time in response to
input or computation. Different users have different needs for how they want to
Problem description view the program's information. The system needs to reflect data changes to all
users in the way that they want to view them, while making it easy to make
changes to the user interface.
This involves separating the data being manipulated from the manipulation logic
and the details of display using three components: Model (a problem-domain
Solution description component with data and operations, independent of the user interface), View (a
data display component), and Controller (a component that receives and acts on
user input).
Advantages: views and controllers can be easily be added, removed, or changed;
views can be added or changed during execution; user interface components can
be changed, even at runtime. Disadvantages: views and controller are often hard
Consequences
to separate; frequent updates may slow data display and degrade user interface
performance; the MVC style makes user interface components (views, controllers)
highly dependent on model components. 43
Multi-tier client-server architecture

44
Service-oriented architecture
• Services in a service-oriented architecture are stateless
components, which means that they can be replicated
and can migrate from one computer to another.
• Many servers may be involved in providing services
• A service-oriented architecture is usually easier to scale
as demand increases and is resilient to failure.

45
service-oriented architecture

46
Issues in architectural choice
• Data type and data updates
• If you are mostly using structured data that may be updated by different system
features, it is usually best to have a single shared database that provides
locking and transaction management. If data is distributed across services, you
need a way to keep it consistent and this adds overhead to your system.
• Change frequency
• If you anticipate that system components will be regularly changed or replaced,
then isolating these components as separate services simplifies those changes.
• The system execution platform
• If you plan to run your system on the cloud with users accessing it over the
Internet, it is usually best to implement it as a service-oriented architecture
because scaling the system is simpler.
• If your product is a business system that runs on local servers, a multi-tier
architecture may be more appropriate.

47
Technology choices
• Database
Should you use a relational SQL database or an unstructured NOSQL database?
• Platform
Should you deliver your product on a mobile app and/or a web platform?
• Server
Should you use dedicated in-house servers or design your system to run on a public cloud?
If a public cloud, should you use Amazon, Google, Microsoft, or some other option?
• Open source
Are there suitable open-source components that you could incorporate into your products?
• Development tools
Do your development tools embed architectural assumptions about the software being
developed that limit your architectural choices?

48
Database
• There are two kinds of database that are now commonly used:
• Relational databases, where the data is organised into structured tables
• NoSQL databases, in which the data has a more flexible, user-defined
organization.
• Relational databases, such as MySQL, are particularly suitable for
situations where you need transaction management and the data
structures are predictable and fairly simple.
• NoSQL databases, such as MongoDB, are more flexible and
potentially more efficient than relational databases for data
analysis.
• NoSQL databases allow data to be organized hierarchically rather than as
flat tables and this allows for more efficient concurrent processing of ‘big
data’.

49
Delivery platform
• Delivery can be as a web-based or a mobile product or both
• Mobile issues:
• Intermittent connectivity You must be able to provide a limited service without network
connectivity.
• Processor power Mobile devices have less powerful processors, so you need to
minimize computationally-intensive operations.
• Power management Mobile battery life is limited so you should try to minimize the
power used by your application.
• On-screen keyboard On-screen keyboards are slow and error-prone. You should
minimize input using the screen keyboard to reduce user frustration.
• To deal with these differences, you usually need separate browser-based and
mobile versions of your product front-end.
• You may need a completely different decomposition architecture in these different
versions to ensure that performance and other characteristics are maintained.
50
Server
• A key decision that you have to make is whether to design
your system to run on customer servers or to run on the
cloud.
• For consumer products that are not simply mobile apps I
think it almost always makes sense to develop for the cloud.
• For business products, it is a more difficult decision.
• Some businesses are concerned about cloud security and prefer to
run their systems on in-house servers. They may have a predictable
pattern of system usage so there is less need to design your system
to cope with large changes in demand.
• An important choice you have to make if you are running
your software on the cloud is which cloud provider to use.
51
Open source
• Open source software is software that is available freely, which you can
change and modify as you wish.
• The advantage is that you can reuse rather than implement new software, which
reduces development costs and time to market.
• The disadvantages of using open-source software is that you are constrained by
that software and have no control over its evolution.
• The decision on the use of open-source software also depends on the
availability, maturity and continuing support of open source components.
• Open source license issues may impose constraints on how you use the
software.
• Your choice of open source software should depend on the type of
product that you are developing, your target market and the expertise of
your development team.

52
Development tools
• Development technologies, such as a mobile
development toolkit or a web application framework,
influence the architecture of your software.
• These technologies have built-in assumptions about system
architectures and you have to conform to these assumptions to
use the development system.
• The development technology that you use may also have
an indirect influence on the system architecture.
• Developers usually favour architectural choices that use familiar
technologies that they understand. For example, if your team
have a lot of experience of relational databases, they may argue
for this instead of a NoSQL database.
53
 Key points 1
• Software architecture is 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.
• The architecture of a software system has a significant influence on non-
functional system properties such as reliability, efficiency and security.
• Architectural design involves understanding the issues that are critical
for your product and creating system descriptions that shows
components and their relationships.
• The principal role of architectural descriptions is to provide a basis for
the development team to discuss the system organization. Informal
architectural diagrams are effective in architectural description because
they are fast and easy to draw and share.
• System decomposition involves analyzing architectural components and
representing them as a set of finer-grain components.
54
Key points 2
• To minimize complexity, you should separate concerns, avoid
functional duplication and focus on component interfaces.
• Web-based systems often have a common layered structure including
user interface layers, application-specific layers and a database layer.
• The distribution architecture in a system defines the organization of
the servers in that system and the allocation of components to these
servers.
• Multi-tier client-server and service-oriented architectures are the
most commonly used architectures for web-based systems.
• Making decisions on technologies such as database and cloud
technologies are an important part of the architectural design
process.

55
 Assignment 2
1. Suggest an architecture for a system (such as iTunes) that is
used to
sell and distribute music on the Internet. What architectural
patterns are the basis for this architecture?
2. List and explain other software architecture patterns in use
and give
example of applications that run on such architectures.
3. Find out the architecture Google Search engine runs on,
examine
how it works, outline the strength and weakness if there is
any. 56
References
• The design and implementation of an e-commerce https://clas.iusb.edu
SKhodali_thesis
• https://microservices.io/
• https://iansommerville.com/engineering-software-products/
software-architecture/

57