Software
Architecture
DR. ALHASSAN ADAM
Lecture Outline
Introduction to Software Architecture
Design Principles
Architectural Patterns
Design Patterns
When you here about Software Architecture
What does it comes to you mine?
Have you ever imagine the final Architecture any
Software
Analogy: Architecture of Buildings
We all live in them
(We think) We know how they are built
Requirements
Design (blueprints)
Construction
Use
This is similar (though not identical) to how we build software
5
Some Obvious Parallels
Satisfaction of customers’ needs
Specialization of labor
Multiple perspectives of the final product
Intermediate points where plans and progress are reviewed
6
Deeper Parallels
Architecture is different from, but linked with the
product/structure
Properties of structures are induced by the design of the
architecture
The architect has a distinctive role and character
7
Deeper Parallels (cont’d)
Process is not as important as architecture
Design and resulting qualities are at the forefront
Process is a means, not an end
Architecture has matured over time into a discipline
Architectural styles as sets of constraints
Styles also as wide range of solutions, techniques and palettes of
compatible materials, colors, and sizes
8
Software Architectural Diagram
Building Architecture vs Software
Architecture
One of the differences between building architecture and software
architecture is that a lot of decisions about a building are hard to
change.
It is hard to go back and change your basement, though it is possible.
There is no theoretical reason that anything is hard to change about
software.
If you pick any one aspect of software then you can make it easy to
change, but we don’t know how to make everything easy to change.
Making something easy to change makes the overall system a little
more complex, and making everything easy to change makes the entire
system very complex.
Complexity is what makes software hard to change. That, and
duplication.
Martin Fowler
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.
Definition
Software Architecture: According to IEEE
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.
Architecture serves as a blueprint for a system. It provides an
abstraction to manage the system complexity and establish a
communication and coordination mechanism among components.
Why is architecture important?
Architecture is important because the architecture of a system has a
fundamental influence on the non-functional system properties.
• Responsiveness • Security
Does the system return results Does the system protect itself and users’ data
from unauthorized attacks and intrusions?
to users in a reasonable time?
• Usability
• Reliability Can system users access the features that
they need and use them quickly and without
Do the system features errors?
behave as expected by both • Maintainability
developers and users? Can the system be readily updated and new
features added without undue costs?
• Availability • Resilience
Can the system deliver its Can the system continue to deliver user
services when requested by services in the event of partial failure or
external attack?
users?
Why is architecture important?
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.
The more complex a system, the more difficult and expensive it is to
understand and change.
Programmers are more likely to make mistakes and introduce bugs
and security vulnerabilities when they are modifying or extending a
complex system..
Architecture in Action: WWW
This is the Web
15
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Architecture in Action: WWW
So is this
16
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Architecture in Action: WWW
And this
17
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
WWW in a (Big) Nutshell
The Web is a collection of resources, each of which has a unique name
known as a uniform resource locator, or “URL”.
Each resource denotes, informally, some information.
URI’s can be used to determine the identity of a machine on the Internet,
known as an origin server, where the value of the resource may be
ascertained.
Communication is initiated by clients, known as user agents, who make
requests of servers.
Web browsers are common instances of user agents.
18
WWW in a (Big) Nutshell (cont’d)
Resources can be manipulated through their representations.
HTML is a very common representation language used on the Web.
All communication between user agents and origin servers must be
performed by a simple, generic protocol (HTTP), which offers the
command methods GET, POST, etc.
All communication between user agents and origin servers must be fully
self-contained. (So-called “stateless interactions”)
19
WWW’s Architecture
Architecture of the Web is wholly separate from the code
There is no single piece of code that implements the architecture.
There are multiple pieces of code that implement the various components
of the architecture.
E.g., different Web browsers
20
Context of Software Architecture
Requirements
Design
Implementation
Analysis and Testing
Evolution
Development Process
21
Requirements Analysis
Traditional SE suggests requirements analysis should remain
unsullied by any consideration for a design
However, without reference to existing architectures it becomes
difficult to assess practicality, schedules, or costs
In building architecture we talk about specific rooms…
…rather than the abstract concept “means for providing shelter”
In engineering new products come from the observation of
existing solution and their limitations
22
New Perspective on Requirements Analysis
Existing designs and architectures provide the solution
vocabulary
Our understanding of what works now, and how it works, affects
our wants and perceived needs
The insights from our experiences with existing systems
helps us imagine what might work and
enables us to assess development time and costs
Requirements analysis and consideration of design must be
pursued at the same time
23
Non-Functional Properties (NFP)
NFPs are the result of architectural choices
NFP questions are raised as the result of architectural choices
Specification of NFP might require an architectural framework to
even enable their statement
An architectural framework will be required for assessment of
whether the properties are achievable
24
The Twin Peaks Model
25
The Twin Peaks Model
The Twin Peaks Model describes how you develop the
requirements and architecture of a system iteratively and in
parallel. It provides the answer to the question “What needs to
be developed first – the requirements or the architecture”.
The Twin Peaks model is visualized with two similar mountains
(therefore called Twin Peaks); one mountain represents the
requirements, the other the architecture
26
Design and Architecture
Design is an activity that pervades software development
It is an activity that creates part of a system’s architecture
Typically in the traditional Design Phase decisions concern
A system’s structure
Identification of its primary components
Their interconnections
Architecture denotes the set of principal design decisions
about a system
That is more than just structure
27
Design Principles
SOLID
DRY
K.I.S.S
SOLID
SOLID is an acronym formed by the names of 5 design principles
centered around better code design, maintainability, and
extendibility.
The SOLID software principles will guide you to:
write code that’s easy to maintain;
make it easier to extend the system with new functionality
without breaking the existing ones;
write code that’s easy to read and understand.
Single Responsibility Principle
Single Responsibility Principle is the S in SOLID.
Single responsibility means that your class (any entity for that
matter, including a method in a class, or a function in structured
programming) should only do one thing.
If your class is responsible for getting users’ data from the
database, it shouldn’t care about displaying the data as well.
Those are different responsibilities and should be handled
separately.
Single Responsibility Principle
Example
Write small classes with very specific names as opposed to large classes
with generic names.
For example, instead of throwing everything inside an Employee class,
separate the responsibilities into:
EmployeeTimeLog, EmployeeTimeOff, EmployeeSalary, EmployeeDetails, etc.
SRP example of customer class
Each class has a single responsibility, which makes the code easier to
understand, maintain, and test. The Customer class is responsible for storing
customer information, the Order class is responsible for managing orders, and
the Item class is responsible for storing item information.
• It is not a responsibility of an IPhone class to calculate the
Total sale
• Problem: what if tomorrow I have IPad class, I’ll have to
re-code the same method for that class as well.
• Solution: Rather we can move the responsibility of
calculating Total sale to the new class Sale. And an IPhone
can encapsulate Sale to calculate its total sale.
What CalculateTotal_Sale()
Exercise
Try vehicle class, separate the responsibilities for the class so
that each class will do one and only activity.
SRP for vehicle class
Open-Closed principle
The Open/Closed Principle states that a class/module should be open for
extension, but closed for modification.
That means you should be able to extend a module with new features
not by changing its source code, but by adding new code instead.
The goal is to keep working, tested code intact, so over time, it becomes
bug resistant
Open/Closed Principle
IPhone Class Example
Problem: We know that different
IPhone models have different specs,
right? IPhone XR has different
specifications than IPhone X.
Solution: We must abstract our
problem so that our IPhone class can
delegate its implementation based on
model type.
Liskov’s Substitution Principle
Parent classes should be easily substituted with their child classes.
In our UML above as we can see that, we have created IModel interface,
now any class which inherits the IModel must define all of it’s methods in
order to satisfy IS-A relationship else you’ll get compile time error. But your
compiler is not going to be there when you inherit classes rather than
interfaces.
Liskov’s Substitution Principle
Problem: Have you ever seen
IPhone with Snapdragon?
So when we try to assemble
Snapdragon’s CPU to our IPhone
class it will throw an error as you can
see in Snapdragon865 class it is
throwing not implemented exception.
Because IPhone X & XR are only
compatible with Bionic chips.
Liskov’s Substitution Principle
Solution: We should not have
child classes which are not
completely implementing
their parent’s behavior.
Interface Segregation
Principle
Remember Single responsibility principle? It is the same principle
but this principle is applied on interfaces instead.
Problem: We should not have a more generalized interface. i.e.
we must avoid jumbling up everything in one single interface
then forcing their concrete classes to define those methods that
they might not require and they end up in throwing a
NotImplementedException.
Interface Segregation
Principle
We have 2 IPhones XR & X: Iphone XR
has single camera where IPhone X
has dual camera. So it would be
wrong for an IPhoneXR to define
DualCamera, as it does not have a dual
camera. Here IPhone XR is only
defining Single camera, DualCamera is
throwing an exception.
Dependency Inversion
Principle
The dependency inversion principle states that high-level modules should
not depend on low-level modules - both should depend on abstractions.
Our application must be loosely coupled. classes should depend on
abstraction but not on concretion. Because tightly coupled applications gets
more tangled with each other as application grows.
Problem: We have tight coupling between IOSUpdate & IPhone. So if
tomorrow Apple needs an IOS update for IPad, then we will have to make
one more tight coupling relationship, And it gets difficult to maintain as
Application grows more.
Dependency Inversion
Principle
As you can see above IUpdate is an
interface which has 2 concrete classes
So in future, when Apple needs to have a new
IPhoneUpdate & IPadUpdate.
product say MacBook
And when our client which is IPhone in we can simply create one more
this case ask for an update we can MacBookUpdate class which will be an
simply inject IPhoneUpdate concrete representation of IUpdate interface.
dependency in constructor or method. And client MacBook can resolve <IUpdate,
MacBookUpdate> dependency.
Summary of SOLID
Single Responsibility Principle: A class (or method) should only have one reason to
change. This principle states that if we have 2 reasons to change for a class, we have to
split the functionality in two classes. Each class will handle only one responsibility and on
future if we need to make one change we are going to make it in the class which handle
it. When we need to make a change in a class having more responsibilities the change
might affect the other functionality of the classes.
Open Closed Principle: Software entities like classes, modules and functions should be
open for extension but closed for modifications. Extending a class shouldn't require any
modification of existing classes.
Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
Interface Segregation Principle: Make fine grained interfaces that are client specific.
Clients should not be forced to depend upon interfaces that they don't use.
For example if we create an interface called Worker and add a method lunch break, all the workers will
have to implement it.
What if the worker is a robot?
Dependency Inversion Principle: DIP states that we should decouple high level modules
from low level modules, introducing an abstraction layer between the high level classes
and low level classes
Next
Do Not Repeat Yourself (DRY) Principles
