Chapter 4:

Software
Architecture

CSC4307
Outline

WHY ARCHITECTURE ARCHITECTURAL SYSTEM

IS IMPORTANT? DESIGN DECOMPOSITION

DISTRIBUTION TECHNOLOGY
ARCHITECTURE ISSUES
 “Architecture represents the significant
design decisions that shape a system,
where significance is measured by cost
of change”
Simon Brown
What is
Architecture?
“Architecture in software development
are decisions that are hard to reverse”
Architecture
Metaphor
 • Software Architecture

Categories • Hardware Architecture

of
Architecture • Network Architecture

• Data Architecture
 • Depict all architectural design including:

• The overall organization,

• How the software is decomposed into

components,

• The server organization

Software
Architecture • The technologies that you use to build the
software.

• Architecture affects performance, usability,

security, reliability and maintainability of
software products.

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

7
 • A component is an element that
Software implements a coherent set of
functionality or features.
architecture
and
• Software component can be
components considered as a collection of one or
more services that may be used by
other components.

8
Access to services provided by software components

Design the component interface and leave the

implementation of that interface to a later
9
 • Big Design Up Front (BDUF)
The program's design is to be completed and
perfected before that program's
implementation is started.

Agile
Terminologies

Source: https://courseux.com/ux-agile/
 • YAGNI, or "You Ain't Gonna Need It", emerged
as one of the key principles of XP. Yagni is a way
to refer to the XP practice of Simple Design.
(need to be used in combination with
continuous refactoring, CI and CAT)

Agile
Terminologies
 • Sprint 0: Set up technology tools
(servers/workstations, set up CI environment, version
control etc…), work on 1-2 stories to finish, Initial
system architecture modeling.
• Spike : an experiment that allows developers to learn
just enough about the unknown elements in a user
story
Agile • Architectural Spikes : is a technical risk-reduction
technique where you write just enough code to
Terminologies explore the use of a technology or technique that
you're unfamiliar with.
(cont.)
 • Timeboxed usually 1-2 days work
for one pair

• Experimental solutions that touch

all relevant layers
Spikes are:
• Are always throwaway code
Why Architecture is important?

Architecture is important because the architecture of

a system has a fundamental influence on its non-
functional properties.
 Security : Does the system protect itself and
users’ data from unauthorized attacks and
intrusions?
Non- Usability: Can system users access the
functional features that they need and use them quickly
and without errors?
system Availability
quality Can the system deliver its services when
attributes requested by users?
A system’s availability is measured by uptime,
so it can be determined how well the system
recovers from issues such as system errors,
high loads, or updates.

15
 Responsiveness: Does the system return
results to users in a reasonable time?

Throughput and latency in response to

Non- user commands/events, determines how
well to respond to a user command or
functional system event.
system
quality
attributes Maintainability: Can the system be readily
updated, and new features added without
undue costs?

The ease at which your system can

undergo changes.

16
 Interoperability: Is your system able to
understand communications and share data
with external systems ?
Non- System’s ability to understand interfaces and
functional use them to exchange information under
system specific conditions with those external
systems.
quality
attributes Reliability: Do the system features behave as
expected by both developers and users?

Resilience: Can the system continue to deliver

user services in the event of partial failure or
external attack?

17
 A centralized security architecture

The • If you maintain all your information in one

place, then you can apply lots of resources to
influence on protect that information and ensure that
architecture intruders can’t get hold of it.

of system
security

18
 Benefits :
• Easier to design and build protection
Centralized
• Information can be accessed more
security efficiently.
architectures Drawbacks:
• If your security is breached, you lose
everything.

Shared
Database
Architecture

19
 If you distribute information, it takes longer
to access all the information and costs more
to protect it.

If security is breached in one location, you

only lose the information that you have
stored there.

Multiple
Database
Architecture

20
Maintainability
and
performance

A multi-database architecture needs a

mechanism (component C3) to ensure that
the data shared by C1 and C2 is kept
consistent when it is changed.
21
 • Software architecture affects software
complexity

• Minimizing complexity.

Minimizing • The more complex a system, the more

complexity difficult and expensive it is to
understand and change.

• Programmers can make mistakes,

introduce bugs, security vulnerabilities
when modifying or extending a complex
system.

22
Architectural Design

Involves understanding the issues that affect the

architecture of your product and creating a
description of the architecture that shows the critical
components and some of their relationships.
Issues that
influence
architectural
decisions

24
 • Nonfunctional product characteristics:
• Security and performance affect all users. If
you get these wrong, your product is unlikely
to be a commercial success.
The • optimize the most important.
importance of
architectural
design issues

25
 • Product lifetime:
• If you anticipate a long product lifetime, you
will need to create regular product revisions.
You therefore need an architecture that is
evolutive, so that it can be adapted to
The accommodate new features and technology.
importance of
architectural
design issues

26
 • 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
The that is being reused.

importance of
architectural
design issues

27
 • 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
The can be quickly scaled up and down.
importance of
architectural
design issues

28
 • 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.
The
importance of
architectural
design issues

29
 • Human and organizational factors

The • The planned schedule

• Skills of dev team
importance of
• Budget
architectural
design issues
If you choose an architecture that requires
(cont.) your team to learn unfamiliar technologies,
then this may delay the delivery of your
system. There is no point in creating a
“perfect” architecture that is delivered late
if this means that a competing product
captures the market.

30
 • Maintainability vs. Performance

Architectural • Security vs. Usability

design
trade-offs • Availability vs. Time to market and cost.

31
 Maintainability Performance

Self contained parts Few components

(components) easy to means better
replace performance
Trade off #1: takes time for Increased complexity
Maintainability components to And maintainability
communicate with
vs Performance each other.
There may be delays
involved in
transferring data

32
 Security Usability

Design the system Interaction with the

Trade off #2: protection as a series system is slowed by its
of layers. security features.
Security vs If one of these Users must remember
Usability components is information, like
compromised by an passwords, that is
attacker, then the needed to penetrate a
other layers remain security layer.
intact.

33
Authentication
layers

To avoid this, you need an architecture that:

• Doesn’t have too many security layers,
• Doesn’t enforce unnecessary security
• Provides helper components that reduce
the load on users.
34
 Availability Time to Market
You achieve availability Implementing extra
by having redundant components takes time
components in a and increases the cost of
Trade off #3: system. system development.
Availability
vs time-to- You include sensor Adds complexity to the
components that detect system
market failure

Switching components Increases the chances of

that switch operation to introducing bugs and
a redundant component vulnerabilities.
when a failure is
detected.

35
 • 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?
Architectural
design • How should these architectural
questions components be distributed and
communicate with each other?

• What technologies should you use in

building the system and what
components should be reused?

36
System Decomposition

Known as factoring, is breaking a complex problem or

system into parts that are easier to conceive,
understand, program, and maintain.
 • Abstraction
• Focus on the essential elements of a system
or software component without concern for
its details.
• Architectural level : large-scale architectural
components.
• Decomposition
• Analyze large-scale components and
represent them as a set of finer-grain
Component components.
Organization • Example : Layered models used to illustrate
how a system is composed of components.

38
An Architectural
Model of a
Document
Retrieval system

39
 • Complexity in a system architecture
arises because of the number and the
nature of the relationships between
components in that system.

Architectural
complexity

40
Examples of component
relationships

41
 • Localize relationships
If there are relationships between
components A and B, these are easier
How to to understand if A and B are defined in
the same module.
Control
Architectural • Reduce shared dependencies
complexity? Where components A and B depend on
some other component or data,
complexity increases because changes
to the shared component mean you
must understand how these changes
affect both A and B.

42
Architectural
Design
Guidelines

43
A generic
layered
architecture for
a web-based
application

44
 Each layer is an
area of concern
and is considered
separately from
other layers. The components
Architectural are independent
Design and do not overlap
in functionality.
Guidelines in
a layered
architecture

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. 45
 • Cross-cutting concerns are concerns
that are systemic. ie: they affect the
Cross- whole system.
Cutting
Concerns • The existence of cross-cutting concerns
is the reason why modifying a system
after it has been designed to improve
its security is often difficult.

46
Cross-cutting concerns

In a layered architecture, cross-cutting concerns

affect all layers in the system as well as the way in
which people use the system. 47
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.
Distribution
• The UI is implemented on the user’s
architecture own computer or mobile device.

• Functionality is distributed between the

client and one or more server
computers.

49
Client-Server
Architecture

50
The model-
view-
controller
pattern

51
 • Client-server communication normally uses
the HTTP protocol.
• HTTP is a text-only protocol so structured
data must be represented as text.
• Two ways of representing this data: XML
and JSON.
Client-server
communication

52
Multi-tier client-server
architecture

53
Service-Oriented
Architecture

54
 • Services in a service-oriented
architecture are stateless components,
which means that they can be replicated
and can migrate from one computer to
another.
Service-
Oriented • Many servers may be involved in
Architecture providing services.

• A service-oriented architecture is
usually easier to scale as demand
increases and is resilient to failure.

55
 Data type and data updates
• structured data that may be updated by different system
features, → single shared DB that provides locking and
transaction management.
• Data is distributed across services, → keep it consistent
(adds overhead to your system).

Issues in Change frequency

Architectural • system components will be regularly changed or
replaced, → isolating these components as separate
Choice services.

System execution platform

• Running system on the cloud with users accessing it over
the Internet, implement SOA → scaling the system.
• Running on local servers, a multi-tier architecture may
be more appropriate.

56
 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?
Technology
Choices
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?
57
 Open Source
Are there suitable open-source
components that you could incorporate
into your products?

Technology
Choices
(cont.) Development Tools
Do your development tools embed
architectural assumptions about the
software being developed that limit your
architectural choices?

58
Technology Issues

The process of making choices about the technologies

that you will use
 • There are two kinds of database that are
now commonly used:
• Relational databases
• NoSQL databases.

Database

60
 Delivery Platform

• Delivery can be as a web-based or a mobile product or

both. Mobile issues:

• Intermittent connectivity
• Processor power
• Power management
• On-screen keyboard

61
 Cloud vs customer Server:

• For consumer products -----> Cloud

• For business products:
• Cloud security/privacy concerns ( in-
house servers) ---> predictable
pattern of system usage ---> less need
to design system to cope with large
changes in demand.
Server
• Choice decision if running software on
the cloud ---> Service provider.

62
 • Open-Source software use/reuse

• Advantage : reuse / implement new

software → reduces development
costs and time to market.
• Disadvantages: constraints to that
software/ no control over its
Open evolution.
Source
• Availability, maturity and continuing
support.

• Open-source license issues (GNU, MIT,

BSD..)

63