8 SoftwareArchitecture

Software architecture
luca boldrin
Topics
What is an architecture?
Architectural views
Architectural patterns
Eaxmple of application architectures
25/03/23 Lecture 8 - Software Architecture 2

Software architecture
• Architectural design is concerned with understanding how a
software system should be organized and designing the overall
structure of that system.
• Architectural design is the critical link between requirements
engineering and detailed design, as it identifies the main
structural components in a system and the relationships
between them.
• The output of the architectural design process is an
architectural model that describes how the system is organized
as a set of communicating components.

Software architecture: Eight Issues
8. Boundary
1. Identify Design Goals Conditions
Additional NFRs Initialization
Trade-offs Termination
Failure.
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence & Coupling
Monolithic
OOP
Event-Driven
3. Identify Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Persistent Data 6. Global Resource
Parallelism Software Mapping Management Handling
(Processes, Identification of Nodes Storing Persistent Access Control
Threads) Special Purpose Systems Objects ACL vs Capabilities
Buy vs Build Filesystem vs Database Security
Network Connectivity
WHY ARCHITECTURE?
Architecture Design Development Production
Architecture
§ How deep the foundation has to
be?
§ How many pillars are needed?
§ What are their sizes?
§ Which construction material to be
used?
§ On what ratio material has to be
mixed?
§ How would the home look?
§ What features would it have?
§ How the home will be secured?
What type of security systems is
needed?
§ Etc
Design
§ Structural design
§ Electrical design
§ Utility design
§ Interior design
Development
§ Construction of the home
25/03/23 Production
Lecture 8 - Software Architecture 5
§ Hand over the property
Application Architect
Role Application Architect
Owns Overall application architecture and design.
Understands Works with Looks up to Defines

§ Technical depth in § Project Managers § Solution architect Defines Standards for
one or two § Business Analyst’s § Enterprise architect § Application Design
technologies § Designers § UI
§ Requirements and § Developers § Coding
Business Impact § Testers § Coding Templates
§ Project Management § Infrastructure § Naming convention
§ Resourcing Architect § Software Patterns
§ Scheduling § Security
§ Timelines § etc
§ Risk & Risk Mitigation
§ POC
Produces
§ Rapid Prototyping
§ Application architecture (includes layering – both physical & logical, interfaces with external systems, etc.)
§ High and low level design’s
§ Database Model & Design
Typical Application Architecture
Architecture
§ Layering – Presentation, Services,
Business and Data Layers
§ Interfaces between layers
§ High availability of the layers
§ End to end application security
Design
§ Component design
§ Class Diagrams
§ Sequence Diagrams
§ etc
§ Services design
§ Entity design
§ Database design
Development
§ Application Development
Production
§ Go Live

Architectural abstraction
• Architecture in the small is concerned with the architecture of
individual programs. At this level, we are concerned with the
way that an individual program is decomposed into
components.
• Architecture in the large is concerned with the architecture of
complex enterprise systems that include other systems,
programs, and program components. These enterprise systems
are distributed over different computers, which may be owned
and managed by different companies.

Agility and architecture
• It is generally accepted that an early stage of agile processes is
to design an overall systems architecture.
• Refactoring the system architecture is usually expensive
because it affects so many components in the system

Advantages of explicit architecture
• Stakeholder communication
• Architecture may be used as a focus of discussion by system
stakeholders.
• System analysis
• Means that analysis of whether the system can meet its non-functional
requirements is possible.
• Large-scale reuse
• The architecture may be reusable across a range of systems
• Product-line architectures may be developed.

Architectural representations
• Simple, informal block diagrams showing entities and relationships
are the most frequently used method for documenting software
architectures.
• As a way of facilitating discussion about the system design
• A high-level architectural view of a system is useful for communication with
system stakeholders and project planning because it is not cluttered with
detail. Stakeholders can relate to it and understand an abstract view of the
system. They can then discuss the system as a whole without being confused
by detail.
• As a way of documenting an architecture that has been designed
• The aim here is to produce a complete system model that shows the different
components in a system, their interfaces and their connections.

Topics
Architectural views

Architectural views
• What views or perspectives are useful when designing and
documenting a system’s architecture?
• What notations should be used for describing architectural
models?
• Each architectural model only shows one view or perspective of
the system.
• It might show how a system is decomposed into modules, how the run-
time processes interact or the different ways in which system
components are distributed across a network. For both design and
documentation, you usually need to present multiple views of the
software architecture.

Kruchten’s 4+1 view model
https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
End-user Programmers
Functionality Software management
Implementation
Logical
Viewpoint
Viewpoint
Scenarios
Process Deployment
Viewpoint Viewpoint
Integrators System engineers

Performance Topology
Scalability Communications
Lecture 8 - Software Architecture

25/03/23 14
Representing architectural views
• Some people argue that the Unified Modeling Language (UML)
is an appropriate notation for describing and documenting
system architectures
• This is not strictly necessary – it might as well be done with free
drawings.
• Architectural description languages (ADLs) have been
developed but are not widely used

Topics
Architectural views
Logical view
Implementation view
Process view
Deployment view
Scenario view

4 + 1: Logical Viewpoint
• The logical viewpoint supports the functional requirements, i.e.,

the services the system should provide to its end users.
• Typically, it shows the key abstractions (e.g., subsystems and
interactions amongst them).
Original Kruchten notation, now superseded by UML

25/03/23 17
REPRESENTATION
• UML class diagrams may be

used
• Ad-hoc representations is
the practice.
From Data Analytics Framework
https://docs.italia.it/italia/daf/daf-docs/en/bozza/architecture/logical_arch/logicalView.html
Topics
Architectural views
Logical view
Implementation view
Process view
Deployment view
Scenario view

4 + 1: Implementation Viewpoint
• The implementation viewpoint focuses on the organization of
the actual software modules in the software-development
environment.
• The software is packaged in small chunks-program libraries or
subsystems-that can be developed by one or more developers.

25/03/23 20
EXAMPLE
UI
UML implementation not the Java

diagrams Swing Swing libraries, but Web
our GUI classes
is the practice. based on Swing
Domain
Sales Payments Taxes
Technical Services
Persistence Logging RulesEngine

USE OF DIMENSIONS
Domain
POS Inventory Tax
Vertical Layers
Technical Services
Persistence Security Logging
Horizontal Partitions

BAD EXAMPLE – GOOD EXAMPLE
Worse Better
mixes logical and deployment views a logical view
a logical representation
Domain(s)
of the need for data or
services related to these
Domain(s)
POS Inventory subdomains, abstracting
implementation
decisions such as a
Technical database.
Services
Technical Services
Foundation Naming and Web

Persistence
Directory Services AppFramework
«component»
Novell
MySQL LDAP Foundation
Inventory
UML notation: A UML component, or replaceable, modular part of the physical system
UML notation: A physical database in the UML.

Topics
Architectural views
Logical view
Implementation view
Process view
Deployment view
Scenario view

4 + 1: Process Viewpoint
• Addresses concurrent aspects at runtime (tasks, threads,
processes and their interactions)
• It takes into account some nonfunctional requirements, such as
performance, system availability, concurrency and distribution,
system integrity, and fault-tolerance.

25/03/23 25
EXAMPLE
UML
acrivity/sequence
diagrams are the
practice.

Topics
Architectural views
Logical view
Implementation view
Process view
Deployment view
Scenario view

4 + 1: Deployment Viewpoint
• The deployment viewpoint defines how the various elements
identified in the logical, process, and implementation
viewpoints-networks, processes, tasks, and objects-must be
mapped onto the various nodes.
• It takes into account the system's nonfunctional requirements
such as system availability, reliability (fault-tolerance),
performance (throughput), and scalability.

25/03/23 28
4 + 1: Deployment Viewpoint
UML
deployment
diagrams are
currently used

25/03/23 29
Topics
Architectural views
Logical view
Implementation view
Process view
Deployment view
Scenario view

4 + 1: Scenario Viewpoint
• The scenario viewpoint consists of a small subset of important
scenarios (e.g., use cases) to show that the elements of the
four viewpoints work together seamlessly.
• This viewpoint is redundant with the other ones (hence the

"+1"), but it plays two critical roles:
• it acts as a driver to help designers discover architectural elements
during the architecture design;
• it validates and illustrates the architecture design, both on paper and
as the starting point for the tests of an architectural prototype.

25/03/23 31
4 + 1: Scenario Viewpoint
Original Kruchten notation
Putting it all together The elements in the four views are shown
to work together seamlessly by the use of a small set of important
scenarios —instances of more general use cases—for which we
describe the corresponding scripts [...]
The scenarios are in some sense an abstraction of the most
important requirements. [...]
This view is redundant with the other ones (hence the “+1”) [...]
Often replaced by a mix of UML diagrams, depending on the level of abstraction

25/03/23 32
Topics
1. Layered pattern
2. Client-server pattern
3. Master-slave pattern
4. Pipe-filter pattern
5. Broker pattern
6. Peer-to-peer pattern
7. Event-bus pattern
8. Model-view-controller pattern
9. Blackboard pattern

• Patterns are a means of representing, sharing and reusing
knowledge.
• An architectural pattern is a stylized description of good design
practice, which has been tried and tested in different
environments.
• Patterns should include information about when they are and
when the are not useful.
• Patterns may be represented using tabular and graphical
descriptions.

SOME WELL-KNOWN Patterns
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013

Topics
1. Layered pattern

LAYERED Pattern (logical view?)
• 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.
Layered pattern
Name Layered architecture
Description Organizes the system into layers with related functionality

associated with each layer. A layer provides services to the layer
above it so the lowest-level layers represent core services that
are likely to be used throughout the system. See Figure 6.6.
When used Used when building new facilities on top of existing systems;
when the development is spread across several teams with each
team responsibility for a layer of functionality; when there is a
requirement for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the
system.
Disadvantages In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
lower-level 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.

LAYERED Pattern
• 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
• 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

Topics
2. client-server

CLIENT-SERVER PATTERN
(deployment view?)
• 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.

Client-server PATTERN
• Distributed system model which shows how data and
processing is distributed across a range of components.
• Can 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.

A client–server architecture
for a film library
Client 1 Client 2 Client 3 Client 4
Internet
Catalog Video Picture Web

server server server server
Library Film store Photo store Film and

catalogue photo info.

Topics
3. Master-slave pattern

MASTER-SLAVE
PATTERN (logical view?)
• This pattern consists of two parties;
• master and
• 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).

Topics
4. Pipe-filter pattern

PIPE-FILTER PATTERN
(process view?)
• 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
• Compilers. The consecutive filters perform lexical analysis, parsing,
semantic analysis, and code generation.
• Workflows.
•

Pipe-filter PATTERN
• Functional transformations process their inputs to produce
outputs.
• May be referred to as a pipe and filter model (as in UNIX shell).
• Variants of this approach are very common. When
transformations are sequential, this is a batch sequential model
which is extensively used in data processing systems. (e.g.,
datawarehousing).
• Not really suitable for interactive systems.

PIPE-FILTER
PATTERN
• Pipes eliminate need for
intermediate files
• Can replace filters easily
• Can achive different effects
through recombination
• İf data stream format is
standard, filters may be
developed independently
• Parallelization possible

PIPE-FILTER
PATTERN
• E.g., a compiler
Symbol table
Syntax tree
Lexical Syntactic Semantic Code

analysis analysis analysis generation

Topics
5. Broker pattern

BROKER PATTERN
(logical view?)
• This pattern is used to structure distributed systems
with decoupled components.
• These components can interact with each other by
remote service invocations.
• A broker component is responsible for the
coordination of communication among components.
• Servers publish their capabilities (services and
characteristics) to a broker.
• Clients request a service from the broker, and the
broker then redirects the client to a suitable service
from its registry.
Usage
• Message broker software such as Apache
ActiveMQ, Apache Kafka, RabbitMQ and JBoss
Messaging.

Topics
6. Peer to peer pattern

PEER2PEER PATTERN
(logical view?)
• 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.

Topics
7. Event bus pattern

EVENT-BUS
PATTERN
• This pattern primarily deals with events and
has 4 major components;
• event source,
• event listener,
• channel and
• 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

EVENT-BUS
PATTERN

Topics
8. MVC pattern

MODEL-VIEW-
CONTROLLER PATTERN
• This pattern, also known as MVC pattern, divides an
interactive application in to 3 parts as,
Controller View View
• model— contains the core functionality and data selection
Maps user actions Renders model
• view— displays the information to the user (more than one to model updates Requests model updates
view may be defined) Selects view Sends user events to
User events controller
• controller— handles the input from the user
• This is done to separate internal representations of Change
notification
information from the ways information is presented to, and
State
accepted from, the user. It decouples components and change
State query
allows efficient code reuse. Model
Usage Encapsulates application

state
• Architecture for World Wide Web applications in major Notifies view of state
programming languages. changes
• Web frameworks such as Django and Rails.

MODEL-VIEW-
CONTROLLER PATTERN
Different data views on a spreadsheet

Topics
9. Blackboard pattern

BLACKBOARD PATTERN
• This pattern is useful for problems for which no deterministic solution strategies are known. The
blackboard pattern consists of 3 main components.
• Blackboard (repository) — a structured ACTIVE global memory containing objects from the solution space
• knowledge source— specialized modules with their own representation
• control component— selects, configures and executes modules.
• All the components have access to the blackboard.
• Components may produce new data objects that are added to the blackboard.
• Components look for particular kinds of data on the blackboard, and may find these by pattern
matching with the existing knowledge source.
Usage
• Speech recognition
• Vehicle identification and tracking
• Protein structure identification
• Sonar signals interpretation.

BLACKBOARD PATTERN

BLACKBOARD PATTERN
• Problem solvers work independently on part of the

problem
• Share common data structure
• Central controller manages access to the blackboard
• Blackboard may be strcured in levels of abtraction to allow
work at different levels
• Blackboard contain original input and partial solutions

repository for an IDE
UML Code
editors generators
Java
editor
Design Project
translator repository
Python
editor
Design Report
analyzer generator

Topics

Key points
Architectural views

Key points
• A software architecture is a description of how a software system is
organized.
• Architectural design decisions include decisions on the type of application,
the distribution of the system, the architectural styles to be used.
• Architectures may be documented from several different perspectives or
views such as a conceptual view, a logical view, a process view, and a
development view.
• Architectural patterns are a means of reusing knowledge about generic
system architectures. They describe the architecture, explain when it may
be used and describe its advantages and disadvantages.

8 SoftwareArchitecture

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8 SoftwareArchitecture

Uploaded by

Copyright:

Available Formats

Software architecture

25/03/23 Lecture 8 - Software Architecture 2

25/03/23 Lecture 8 - Software Architecture 3

Owns Overall application architecture and design.

Understands Works with Looks up to Defines

25/03/23 Lecture 8 - Software Architecture 7

25/03/23 Lecture 8 - Software Architecture 8

25/03/23 Lecture 8 - Software Architecture 9

25/03/23 Lecture 8 - Software Architecture 10

25/03/23 Lecture 8 - Software Architecture 11

25/03/23 Lecture 8 - Software Architecture 12

25/03/23 Lecture 8 - Software Architecture 13

Integrators System engineers

Lecture 8 - Software Architecture

25/03/23 Lecture 8 - Software Architecture 15

25/03/23 Lecture 8 - Software Architecture 16

• The logical viewpoint supports the functional requirements, i.e.,

Original Kruchten notation, now superseded by UML

Lecture 8 - Software Architecture

• UML class diagrams may be

From Data Analytics Framework

25/03/23 Lecture 8 - Software Architecture 19

Original Kruchten notation, now superseded by UML

Lecture 8 - Software Architecture

UML implementation not the Java

Sales Payments Taxes

Persistence Logging RulesEngine

POS Inventory Tax

Persistence Security Logging

25/03/23 Lecture 8 - Software Architecture 22

Foundation Naming and Web

UML notation: A physical database in the UML.

25/03/23 Lecture 8 - Software Architecture 24

Original Kruchten notation, now superseded by UML

Lecture 8 - Software Architecture

25/03/23 Lecture 8 - Software Architecture 26

25/03/23 Lecture 8 - Software Architecture 27

Original Kruchten notation, now superseded by UML

Lecture 8 - Software Architecture

Lecture 8 - Software Architecture

25/03/23 Lecture 8 - Software Architecture 30

• This viewpoint is redundant with the other ones (hence the

Lecture 8 - Software Architecture

Often replaced by a mix of UML diagrams, depending on the level of abstraction

25/03/23 Lecture 8 - Software Architecture 33

25/03/23 Lecture 8 - Software Architecture 34

25/03/23 Lecture 8 - Software Architecture 35

25/03/23 Lecture 8 - Software Architecture 36

• This pattern is also known as n-tier

Description Organizes the system into layers with related functionality

25/03/23 Lecture 8 - Software Architecture 38

25/03/23 Lecture 8 - Software Architecture 39

25/03/23 Lecture 8 - Software Architecture 40

25/03/23 Lecture 8 - Software Architecture 41

25/03/23 Lecture 8 - Software Architecture 42

25/03/23 Lecture 8 - Software Architecture 43

Client 1 Client 2 Client 3 Client 4

Catalog Video Picture Web

Library Film store Photo store Film and

25/03/23 Lecture 8 - Software Architecture 44

25/03/23 Lecture 8 - Software Architecture 45

25/03/23 Lecture 8 - Software Architecture 46

25/03/23 Lecture 8 - Software Architecture 47