Software Engineering

Stacey Baror
[email protected]

Software Architecture
Introduction to Software Architecture 3 of 3
 Lecture Outcome
Ø Extracting architectural decisions of quality
requirements/quality attributes from functional requirements
ØIdentifying the requirements of each
quality requirements.
ØArchitectural Strategies (Tactics)
ØArchitectural Patterns (Styles)
Recommended Textbook for Software Architecture

To fulfill the Architectural requirements - recommended Chapters 1, 4,

13, 16, 17 and 18
 What is Software Architecture
Ø Software architecture is the set of structures
needed to reason about the system.
Ø The structures comprise software elements,
relations among them, and properties of
both
Ø Architecture is about reasoning-enabling
structures.
 What is Software Architecture
Ø Software Architecture combines scientific
knowledge with creativity and imagination
to design an artefact and to show of this
design that the resulting artefact will have
desired properties.
Ø Architecture is a set of design of software
structure
 What is Software Architecture?
Architecture determines the quality attributes of a system. The architecture
is not the operational software.
It is a representation that enables a software engineer to:
1. Analyze the effectiveness of the design in meeting its stated requirements
2. Consider architectural alternatives at the stage where making design
changes is still relatively easy.
3. Reduce the risks associated with the construction of the software.
Building the System’s Architectural Design Structure?
What do you need to build the system structure (diagram – structural
view of a system)?
Ø Functional requirements
Ø Non-functional requirements
ü Quality requirements/attributes quantification
ü Architectural patterns (Arch styles)
ü Architectural strategies (Arch Tactics)
ü Architectural constraints
Ø Technology
You use the technology to design (draw) the deployment model of the
system
 Non Functional Requirements Extraction
ØWhat do you need to make the software system’s structure (i.e., an
architectural diagram of the system)?
ØFour or more quality requirements addresses one
or more functional requirements
ØQuality requirements must be quantifiable
ü Usability
ü Availability
ü Performance
ü Scalability
ü Security
ØArchitectural Patterns
ØArchitectural Strategies
+27 (0) 12 434 2500
 Quality requirements
ØQuality requirements, also known as quality attributes, specify criteria that define how well a
software system performs or behaves, rather than defining specific features or functionalities.
ØThese requirements focus on aspects such as performance, reliability, security,
scalability, usability, maintainability, and other characteristics that determine the
overall quality of the software.
ØQuality requirements are essential for ensuring that the software meets the expectations
and needs of its users and stakeholders. Here are some common categories of quality
requirements:
üPerformance: Performance requirements specify the system's responsiveness,
throughput, and resource utilization under varying conditions. This includes
metrics such as response time, throughput, latency, and scalability.
üReliability: Reliability requirements define the system's ability to perform its
functions consistently and accurately over time. This includes measures such as
availability, fault tolerance, failure recovery, and mean time between failures
(MTBF). A+27quality attribute should be unambiguous Testable
(0) 12 434 2500
 Quality requirements
ØSecurity: Security requirements address the protection of the system against
unauthorized access, data breaches, and other security threats. This includes
authentication, authorization, encryption, data integrity, and compliance with regulatory
standards.
ØUsability: Usability requirements focus on the user experience and the ease of use of
the software interface. This includes aspects such as intuitiveness, accessibility,
learnability, and efficiency of user interactions.
ØScalability: Scalability requirements define the system's ability to handle increasing
loads and accommodate growth in users, data volume, and transactions. This includes
horizontal and vertical scaling, elasticity, and performance under peak loads.

ØMaintainability: Maintainability requirements address the ease with which the

software can be modified, extended, and repaired over its lifecycle. This includes factors
such as modularity, documentation, code readability, and ease of debugging.
+27 (0) 12 434 2500
 Quality requirements
ØPortability: It specify the ability of the software to run on different
platforms, environments, and devices without requiring significant
modifications. This includes compatibility with operating systems,
hardware, and software dependencies.
ØInteroperability: Defines the ability of the software to exchange data
and interact seamlessly with other systems, components, or services.
This includes adherence to industry standards, protocols, and data
formats.
ØCompliance: Compliance requirements ensure that the software
meets legal, regulatory, and contractual obligations. This includes
adherence to industry standards, privacy regulations, data protection
laws, and intellectual property rights.
+27 (0) 12 434 2500
 Achieving quality requirement Architectural Strategies?
Ø For every quality attribute identified, there must be corresponding
architectural tactics (strategies) to achieve it

ØAchieving Quality attributes through tactics

ØWe now turn to the techniques an architect must use to achieve the required quality
attributes.
ØWe call these techniques architectural tactics.
ØA tactic is a design decision that influences the achievement of a quality attribute
response—tactics directly affect the system’s response to some stimulus.
ØTactics impart portability to one design, high performance to another, and
integrability to a third.

+27 (0) 12 434 2500

 What are architectural strategies?
ØArchitectural strategies (also known as tactics)?
üAre something you do in order to concretely realize a quality requirement.
– Approach based on Bass, Clements Katzman (SEI, “Software Architecture
in Practices” book)
ü Architectural patterns, on the other hand,
• provide an infrastructure within which quality requirements can be
realized,
• an infrastructure which is aligned with a quality requirement
• Pipes & filters ⇒ responsibility localization, flexibility & low cost.
• Blackboard ⇒ extreme scalability & reliability, innovation & ability to solve
difficult problems without defined process.
• Layering ⇒ pluggable layers.
+27 (0) 12 434 2500
 Architectural Strategies for Quality Requirements
Ø For every quality attribute identified, there must be corresponding
architectural tactics (strategies)

Achieving Quality attributes through tactics

Ø We now turn to the techniques an architect must use to achieve the required
quality attributes.
Ø We call these techniques architectural tactics.
Ø A tactic is a design decision that influences the achievement of a quality
attribute response—tactics directly affect the system’s response to some
stimulus.
Ø Tactics impart portability to one design, high performance to another, and
integrability to a third.
+27 (0) 12 434 2500
 Architectural Strategies for Quality Requirements
QuantifyingScalability and Performance Strategies

+27 (0) 12 434 2500

 Architectural Strategies for Quality Requirements
Quantifying Reliability/ Availability Strategies

+27 (0) 12 434 2500

 Architectural Strategies for Quality Requirements
Quantifying Security Strategies

+27 (0) 12 434 2500

 Architectural patterns aligned to Quality requirements

ØSecurity: Microkernel , Layered, MVC, pipe and filter patterns

Ø Interoperability: Model-view-controller (MVC), Component-based,
SOA and Layered pattern
ØScalability: Microservices, SOA, Blackboard, Space based
ØUsability: MVC, Client-server
ØThe purpose is to achieve the following
üLow coupling
üHigh cohesion
üEasy to comprehend and change
üTend to result in “stupid objects”
+27 (0) 12 434 2500
 Class Assignment
Due Date: 02 Apr 2024 @ 15:00 – Join Your Group CD4

Ø List five (5) or more quality requirements of LinkedIn

system's functional requirements (you should identify the functional requirements
and group them into sub-systems – if you wish to – not required for this assignment; however, it may
help you for a group with identifying 5-core quality requirements)

Ø What are the requirements of the five (5) or more quality

requirements to the LinkedIn system?
Ø Quantifying the quality requirements identified is done by
mapping two or more architectural strategies that must be
addressed to a quality requirement.
 System Architectural Design

• Decomposing the system into a hierarchy

of functional cohesive, loosely coupled
Decomposing subsystems, which partition the system
the System requirements and facilitate reuse of
COTS components.

Allocating System • System requirements are assigned to the

Requirements subsystems.

Visualizing System • The system architecture is depicted using

Architecture a certain diagramming technique.
 Architectural Design Diagrams
Ø UML component diagram

Ø Block diagram

Ø SysML diagrams

Ø Data flow diagram

Ø and more ...

 Architectural Patterns
• An architectural pattern is a reusable solution to a commonly occurring
problem in software architecture within a given context. The
architectural patterns address various issues in software engineering.
• Examples of Architectural patterns:
• Layered pattern
• Microservices
• Pipe-filter pattern
• Service oriented architecture (SOA)
• Microkernel architecture
• Peer-to-peer pattern
• Model-view-controller pattern (MVC)
• Blackboard pattern
+27 (0) 12 434 2500
 Architecture as a Structure
Ø Architecture is a set of software structures
Ø A structure is a set of elements held together by a relation.
Ø Software systems are composed of many structures, and no single
structure can lay claim to being the architecture.
Ø Structures are grouped into categories, and the categories provide
ways to think about the architecture.
Ø Architectural structures is in 3 categories:
ü Design and documentation
ü Component-and-connector structures
ü Module structures
ü Analysis of the architectures
+27 (0) 12 434 2500
 Layered (n-tier) Architectural
Ø Layered Architecture:
Layered architecture divides the
application into distinct layers
(e.g., presentation layer,
business logic layer, data
access layer)

Ø Each layer depends only on the

layer directly below it. This
pattern promotes modularity,
scalability, and maintainability.

+27 (0) 12 434 2500

Model View Controller Architecture
ØModel-View-Controller
(MVC): MVC separates an
application into three
interconnected components:
Model (data and business
logic), View (user interface),
and Controller (handles user
input and updates the model
and view).

ØThe pattern promotes separation

of concerns and modularity.
+27 (0) 12 434 2500
 Microservice Architecture
Ø Microservices architecture is a software development
approach that structures an application as a collection of
loosely coupled services, each representing a single business
capability or function.
Ø The services are independently deployable, scalable, and
maintainable, and communicate with each other through
well-defined APIs.
Ø Microservices architecture contrasts with traditional
monolithic architectures, where the entire application is
built as a single, tightly integrated unit
+27 (0) 12 434 2500
Recent growth in Software Architecture?

+27 (0) 12 434 2500 [email protected] www.enterprises.up.ac.za

 Microservice Architecture
Ø Microservices architecture is a software development
approach that structures an application as a collection of
loosely coupled services, each representing a single business
capability or function.
Ø The services are independently deployable, scalable, and
maintainable, and communicate with each other through
well-defined APIs.
Ø Microservices architecture contrasts with traditional
monolithic architectures, where the entire application is
built as a single, tightly integrated unit
+27 (0) 12 434 2500
 Block Diagram
Airport Baggage Handling System
(ABHS)
Terminal High-Speed
Passenger luggage
Subsystem Tracks
luggage,
luggage Subsystem
ticket, ID
data
ABHS
Control instructions
instructions Software data

luggage &
flight data Flight
Information
System

3-29
 Component based Architecture
Ø Component: It is a self-contained unit of
software functionality that encapsulates
both data and processing logic.

Ø Components typically expose well-defined

interfaces through which they interact
with other components. Examples of
components include user interface
controls, business logic modules, data
It promotes modularity, reusability, and
access layers, and third-party libraries. maintainability by separating concerns and
Ø that decomposes a system into reusable, enabling independent development,
testing, and deployment of components
self-contained modules or components
+27 (0) 12 434 2500
 Event-Driven Architecture
Component 1

events instructions

instructions events

Component 2 State Based Component 4

events Controller instructions

instructions
events

Component 3

+27 (0) 12 434 2500

 UML Component Diagram
<<subsystem>> <<subsystem>>
Mobile Units Base Station

call
air link instructions data
events <<subsystem>>
<<subsystem>>
<<subsystem>> Base Station
Antenna
Mobile <<subsystem>> Account
Hardware Management
Controller
Software

events
<<subsystem>> <<subsystem>> <<subsystem>>
High-Power Controller
Mobile instructions Transceivers Hardware
Software

Legend: component port <<subsystem>> stereotype for introducing new modeling constructs

3-32
 SysML Block Definition Diagram
bdd [package] Legend:
Structure
subsystem
or
component
Airport Baggage
Handling System consist
of

Terminal ABHS High-Speed

Subsyste Control Tracks
m Software Subsystem

3-33
 SysML Internal Block Diagram
ibd [Block] Terminal Subsystem
[Nested Flow]

luggage, Passenger Check-In luggage Conveyor

ID: :
Material Airline Materia
Flow Agent l Flow Conveyor
(human) Hardware luggage High-
Passenger boarding : Speed
Interface pass, ID: Materia Track
Material l Flow Interface
Flow Bar-Code Bag Worker
Check-In Scanner Pushers (human)
Terminal (HW) (HW)
(HW/SW)

bar-code instructions

ABHS Control ABHS Control

Software Interface Software Interface

Legend:
subsystem input or input & association
or output output relation, or port-
component port port to-port flow
3-34
Data Flow Diagram with Material Flows
1 valid 2 3
shipment shipment new titles
slip Verify slip Classify available Handle
Publisher Shipment Publications Documents
Content Received Check-
In/Out
Purchasing Cataloging Circulatio
n
Receiving Cataloging Book
Dock Room Shelves
raw shipment publications publications
w/call
numbers

Legend:
ID information
flow External Internal
Function Entity Entity
material flow
Subsystem

3-35
 Other System Engineering Activities
Ø Development of subsystems
üThe subsystems are developed by different engineering teams.
üThe engineering teams collaborate to jointly solve
interdisciplinary problems.
Ø System integration, testing, and deployment
üThe subsystems and components are integrated and tested for
interoperability.
üThe system is tested to ensure that it satisfies the system
requirements and constraints.
üThe system is then installed and tested in the target
environment.
Thank you