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