Software Engineering

LECTURE 10: SOFTWARE ARCHITECTURE

1
 Software architecture
Software architecture refers to the
• high level structures of a software system
• discipline of creating such structures,
• and the documentation of these structures.
These structures are needed to reason about the software
system.

2
Software Architecture
A software architecture defines:
◦the components of the software system
◦how the components use each other’s functionality and
data
◦How control is managed between the components

3
Architecture vs. design

4
Analysis vs. Design
Analysis
Asks “what is the problem?”
◦ what happens in the current system?
◦ what is required in the new system?
Results in a detailed understanding of:
◦ Requirements
◦ Domain Properties
Focuses on the way human activities are conducted
5
Analysis vs. Design
Design
Investigates “how to build a solution”
◦ How will the new system work?
◦ How can we solve the problem that the analysis identified?
Results in a solution to the problem
◦ A working system that satisfies the requirements
◦ Hardware + Software + Peopleware
Focuses on building technical solutions
Separate activities, but not necessarily sequential
◦ …and attempting a design usually improves understanding of the problem

6
Levels of abstraction

7
 Architecture vs. design
Architecture (what is developed?)
High-level view of the overall system:
◦ What components do exist?
◦ What are the protocols between components?
◦ What type of storage etc.?
Design (how are the components developed?)
Considers individual components:
◦ Data representation
◦ Interfaces, Class hierarchy

8
9
Example

10
Architectural considerations

11
Architectural Building blocks
Architectural Building blocks:

A good architecture:
◦ Minimizes coupling between modules:
◦ Goal: modules don’t need to know much about one another to interact
◦ Low coupling makes future change easier
◦ Maximizes the cohesion of each module
◦ Goal: the contents of each module are strongly inter-related
◦ High cohesion makes a module easier to understand

Coupling and Cohesion

12
Package
General grouping of system elements
Appropriate for denoting subsystem at conceptual level

Conceptual diagram

13
Component
• Replaceable part of a system
• Conforms to and realizes a set of interfaces
• An implementation of a subsystem
• Could be replaced by another component that realizes
the same interfaces, and system would still function
• Components realize interfaces, are assembled into systems

interface diagram

14
Node
Physical element that exists at runtime, provides a
computational resource
• Computer
• Smartphone
• Network router
• Components live on nodes

deployment diagram
15
 Framework
A framework, or software framework, is a platform that provides a foundation for developing software applications. Think of it as a template of a working program that can
be selectively modified by adding code.
A framework is a partially complete software (sub-) system that is intended to be instantiated.
It defines the architecture for a family of (sub-) systems and provides the basic building blocks to create them.

• Web app framework.

• React, Angular, Vue , Spring boot, Asp.net Core, Django, Rails

• Mobile app framework.

• Flutter React Native

• Technology framework
• . Selenium

• Enterprise architecture framework.

• The Zachman Framework , Open Agile Architecture (O-AA), The Open Group Architectural Framework (TOGAF),

• Database framework.
• Hadoop by Apache that stores and distributes large data sets across several servers

• Testing framework.
• Selenium , WebdriverIO , Cypress

• AI application development.
• TensorFlow , PyTorch

• Cross-platform native apps - . Xamarin

16
Architectural Patterns

The fundamental problem to be solved with a large system is how to break it into
chunks manageable for human programmers to understand, implement, and
maintain.

An architectural pattern is a general, reusable solution to a commonly occurring

problem in software architecture within a given context. Architectural patterns are
similar to software design pattern but have a broader scope.

17
 An architectural Pattern expresses a fundamental
structural organization schema for software
systems. It provides a set of predefined
subsystems, their responsibilities, and includes
rules and guidelines for organizing the relationships
Architectural between them.
Pattern Vs
Design Pattern A design pattern provides a scheme for refining the
subsystems or components of a software system,
or the relation ships between them. It describes a
commonly recurring structure of communicating
components that solves a general design problem
within a particular context.

18
 §Architectural Styles
§ Pipe and filter
§ Object oriented:
Software § Client-Server; Object Broker
§ Event based
Architectures § Layered:
§ Designing Layered Architectures
§ Repositories:
§ Blackboard, MVC

19
 Pipe-and-filter
This pattern can be used to structure systems which produce and
process a stream of data.
Each processing step is enclosed within a filter component.
Data to be processed is passed through pipes.
These pipes can be used for buffering or for synchronization
purposes.

Usage:
◦ UNIX shell commands – Grep Command
◦ Compilers:
◦ Lexical Analysis -> parsing -> semantic analysis -> code
generation
◦ Signal Processing
◦ Workflows in bioinformatics.

20
Pipe-and-filter – Example

21
Pipe-and-filter – Example

22
 • Systems can be easily maintained and
enhanced, since new filters can be added to
existing systems and old filters can be replaced by
improved ones.

Pipe and Filter • They permit certain kinds of specialized

analysis, such as throughput and deadlock
Advantages analysis.

• The naturally support concurrent execution

23
 • Not good choice for interactive
systems, because of their
transformational character.
Pipe and Filter
Disadvantages
• Excessive parsing and unparsing
leads to loss of performance and
increased complexity in writing
the filters themselves

24
 Object Oriented Architectures
Examples:
◦ abstract data types
Interesting properties
◦ data hiding (internal data representations are not visible to
clients)
◦ can decompose problems into sets of interacting agents
◦ can be multi-threaded or single thread
Disadvantages
◦ objects must know the identity of objects
they wish to interact with
25
 Variant 1: Client Server
This pattern consists of two parties;
◦ a server and
◦ multiple clients.
The server component will provide services to multiple client components.
Clients request services from the server and the server provides relevant services to those
clients.
The server continues to listen to client requests.
Usage
Online applications such as email, document sharing and banking.
Disadvantages
◦ Client objects must know the identity of the server

26
Variant 2- Master-slave pattern
This pattern consists of two parties;
◦ master
◦ slaves.

The master component distributes the work among identical slave

components, and computes a final result from the results which
the slaves return.
Usage
• In database replication, the master database is regarded as
the authoritative source, and the slave databases are
synchronized to it.
• Peripherals connected to a bus in a computer system (master
and slave drives).

27
 Interesting properties
Ä Adds a broker between the clients and servers
Ä Clients no longer need to know which server they are using
Ä Can have many brokers, many servers.
Disadvantages
Ä Broker can become a bottleneck
Ä Degraded performance

Usage
Message broker software such as Apache ActiveMQ, Apache
Kafka, RabbitMQ and JBoss Messaging.

28

Variant 3: Object Brokers

Broker
Architecture
Example

29
Peer-to-peer pattern
In this pattern, individual components are known as peers.
Peers may function both as a client, requesting services from other
peers, and as a server, providing services to other peers.
A peer may act as a client or as a server or as both, and it can change its
role dynamically with time.

Usage
File-sharing networks such as Gnutella and G2)
Multimedia protocols such as P2PTV and PDTP.
Proprietary multimedia applications such as Spotify.

30
Event based (implicit invocation)
Examples
Ä debugging systems (listen for particular breakpoints)
Ä database management systems (for data integrity checking)
Ä graphical user interfaces
Interesting properties
Ä announcers of events don’t need to know who will handle the event
Ä Supports re-use, and evolution of systems (add new agents easily)
Disadvantages
Ä Components have no control over ordering of computations

31
 Event-bus pattern
This pattern primarily deals with events and has
4 major components;
event source,
event listener,
channel
event bus.
• Sources publish messages to particular channels on an event bus.
• Listeners subscribe to particular channels.
• Listeners are notified of messages that are published to a channel to which they
have subscribed before.
Usage
• Android development
• Notification services
• debugging systems (listen for particular breakpoints)
• database management systems (for data integrity checking)
• graphical user interfaces

32
Event-bus pattern-Example

33
 Layered pattern
This pattern is also known as n-tier architecture pattern.
It can be used to structure programs that can be decomposed into groups of subtasks, each of which
is at a particular level of abstraction.
Each layer provides services to the next higher layer.

Usage
General desktop applications.
E commerce web applications.
Common layers of a general information system

Presentation layer (also known as UI layer)

Application layer (also known as service layer)
Business logic layer (also known as domain layer)
Data access layer (also known as persistence layer)
Layered pattern

• Different levels of abstraction

• Requests go down, notifictions
go back up
• Possible to define stable
interaces between layers
• May add or change layers over
time
Layered pattern

Start with the lowest later

Build layers on top
Use same level of abstraction within each layer
Componenets cannot spread over two layers
Keey lower layers lean
Specify interfaces for each layer
Handle errors at the lowest level possible
How many layers?

38
Repositories
Examples
Ä databases
Ä blackboard expert systems
Ä programming environments
Interesting properties
Ä can choose where the locus of control is (agents, blackboard, both)
Ä reduce the need to duplicate complex data
Disadvantages
Ä blackboard becomes a bottleneck

39
Repository Style Examples
• Information Systems
• Programming Environments
• Graphical Editors
• AI Knowledge Bases
• Reverse Engineering Systems

40
Variant: Model-View-Controller
This pattern, also known as MVC pattern, divides an interactive
application in to 3 parts as,
model — contains the core functionality and data
view — displays the information to the user (more than one view may be
defined)
controller — handles the input from the user
Usage:
Architecture for World Wide Web applications in major programming
languages.
Web frameworks such as Django and Rails.
JavaSpring boot, PHP Laravel, Asp.NET MVC)

41
42
44