SWE411 Principles of Software Architecture Dr.

Nissreen El-Saber
Dr. Nissreen El-Saber

- Assistant Professor, FCI-ZU.

- PhD in CS from Uni. of Leicester, UK.
THIS COURSE INTRODUCES:
o concepts, principles, and state-of-the-art methods in software
architectures,
o domain-specific software architectures,
o architectural styles,
o architecture description languages, their properties and the types of
problems for which they are most appropriate,
o and architecture-based testing and analysis.
o The course will also examine the practical applicability of architecture
research, specifically its relationship to work in architectural
frameworks and component interoperability platforms.
PLANNED TOPICS
1. Software Architecture: Why & Fundamental concepts.
2. Designing Architectures.
3. Modelling, description & perspectives.
4. Visualization.
5. Analysis.
6. Implementation.
7. Applied Architecture & Styles.
8. Designing for non-functional properties.
9. Domain-specific Software Engineering.
BOOKS
Software Architecture: Foundations, Theory, and Practice
Richard N. Taylor, Nenad Medvidovic, Eric Dashofy
Wiley and Sons
978-1-119-11580-9
2022
https://www.wiley.com/en-gb/Software+Architecture%3A+Foundations%2C+Theory%2C+and+Practice-p-9781119115809

Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives
Nick Rozanski, Eoin Woods
Addison-Wesley Professional
Second Edition
978-0321718334
2011
https://www.pearson.com/en-us/subject-catalog/p/software-systems-architecture-working-with-stakeholders-using
-viewpoints-and-perspectives/P200000000580?view=educator

To be continued!
ASSUMED STUDENT BACKGROUND
 Familiarity with the basics of software
development: life cycles, activities &
processes; requirements, design, program
construction, analysis and testing.
 Program design concepts (experience?)
are very important.
SWE411 PRINCIPLES OF SOFTWARE
ARCHITECTURE – CREDIT HOURS: 4
Pre-requisite:
SWE311 Principles of Software Design
SWE210 Data Structures and Algorithms
SWE111 Computer Programming and Problem Solving
SWE110 Introduction to Computer Science and Programming
TIMETABLE
GRADING MODEL
EXAMPLE: 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.)
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”)

10
ARCHITECTURE IN ACTION: WWW

This is the Web

11
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

12
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

13
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
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

Stylistic constraints of the Web’s architectural style are not apparent in the code
 The effects of the constraints are evident in the Web

One of the world’s most successful applications is only understood adequately from
an architectural vantage point.

14
DEFINING ARCHITECTURE
 Some architects refer to software architecture as the blueprint of the system, while others
define it as the roadmap for developing a system.
 The issue with these common definitions is understanding what the blueprint or roadmap
actually contains.
 For example, what is analyzed when an architect analyzes an architecture?
 Software Architecture consists of the structure of the system, combined with architecture
characteristics (“-ilities”) the system must support, architecture decisions, and finally design
principles.
Software architecture is the fundamental design of the entire software
system. It defines what elements are included in the system, what function
each element has, and how each element relates to one another. In short, it is
the big picture or overall structure of the whole system, how everything works
together.
15
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
SOFTWARE ARCHITECTURE ROLE

Software architecture doesn‘t exist in isolation, but contains elements of both

requirements analysis and system design. It also has its own unique elements of
course.
… SOFTWARE ARCHITECTURE ROLE IN SDLC
Requirements are an input to architecture
Requirements frame the architectural problem.
Stakeholder needs and desires
Architecture must influence requirements:
The art of possible.
Stakeholders understanding of risk/cost.
Stakeholders understanding of possibilities.

17
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
… SOFTWARE ARCHITECTURE ROLE IN SDLC
Architecture frames design
 architecture is part of the design process
Captures the system-wide decisions
What has to be consistent or constant
Importance of role increases with scale.
 Perfectly compatible with agile.

18
 WHY IS SOFTWARE ARCHITECTURE IMPORTANT
 Having proper software architecture is important especially for a large software
system.
 Having a clear design of the overall system as a starting point helps to provide a
solid basis for developers to follow.
 Each developer will then know what needs to be
implemented and how things relate to meet the Software Architecture is tied to many
desired needs efficiently. practical concerns:
the structure of development team,
 the needs of the business,
 development cycle, and
 the intent of the software itself.
19
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
WHY IS SOFTWARE ARCHITECTURE IMPORTANT
 Higher productivity for your software team. Software development becomes more
effective because there is a defined structure in place for coordinating work, implementing
individual features, or grounding discussions on potential issues.
 With a clear architecture, it is easier to know where key responsibilities of the system
reside and where to make changes to address new requirements or fix failures.
 A clear architecture will help to achieve quality in your software.
 With a well-designed structure using principles like separation of concerns, the system
becomes easier to maintain, reuse and adapt.
 Stakeholders are the people who have an interest in the
software system at hand. They are people who will either be

STAKEHOLDERS
using the system that you're creating or benefiting from it in
some way.

 Developers: Software Architecture helps the developers to create and evolve

software. It makes development easier by providing a strong direction and
organization on what needs to be done.
 Project Managers use software architecture get useful information to identify
possible risks and manage the project successfully. A well-defined architecture will
help project managers to understand tasks dependencies, impacts of change and
coordinate work assignments.
 The Clients make the big decisions about the system like it's funding. A clear
software architecture will help to communicate coherently and confidently that you
know what you're doing.
 Users may not directly care about how the software actually works, but they will
care that it works well for them. (like users of a house!)
DISTINGUISHING ARCHITECTURE
“All architecture is design but not all design is architecture” – Paul Clements
(Software Architecture in Practice, 2021).
 Architecture addresses :
 system qualities.
 cross-cutting concerns.
 risks the system faces.
Architecture provides the system skeleton.
 Architecture decisions are hard to change.
Architecture constrains as much as defines.
WHEN IS ARCHITECTURE IMPORTANT
 Where you’re solving a hard problem with few solutions (Small Solution Space).
 Where getting it wrong has serious implications (High Failure Risk).
 When the system needs to provide some difficult combination of quality attributes
(Difficult Quality Attributes: Scale, Security, Speed, Modifiability, …).
 When you aren’t familiar with the problem domain or the technology you need to use
to build the system (New problem or Technology Domain).
 When creating a software product line and so you need to be very clear what is
common and what varies for each member of the product line (Product Line
Development).

“Just Enough Software Architecture”, Dr George Fairbanks

 HOW MUCH ARCHITECTURE IS ENOUGH?
 Depends on the risks you’re running. Architecture is there to mitigate
risks.
 So, continue architecture until your risks are acceptably mitigated:
 Partial Architectural designs are OK.
 if your risks are under control.
 When your stakeholders are confident then you are probably done.
 Remember you are one of the stakeholders.

Read Just Enough Software Architecture – George Fairbanks

STAKEHOLDERS
 Identifying Stakeholders
People, Groups, Entities.
Those who have an interest in or concerns about the realization of the
architecture.

 Importance of Stakeholders
 Architectures are built for stakeholders.
Decision must reflect stakeholder needs.
 Involving a wide stakeholder community increases your chances of success.
YOUR TURN (STAKEHOLDERS)
- Who cares whether your system get built?
- Why do they care?
- Are they positively or negatively impacted?

CREATE YOUR SYSTEM’S STAKEHOLDER LIST

ATTRIBUTES OF A GOOD STAKEHOLDER
 Informed, to allow them to make good decisions.
 Committed, to the process and willing to make
themselves available in a constructive manner, even if
decisions are hard.
 Authorized, to make decisions.
 Representative, of their stakeholder group so that they
present its views validly.
Eion Woods
CHALLENGES
Essential Difficulties: Accidental Difficulties:
 Multi-dimensional Problem  Little standardization in
 Highly complex mix of people and architectural description
technology.  Difficult to compare and discuss
 Diverse stakeholder community to serve. alternatives.

 Making trade-offs is essential but  Little sharing of proven practices

hard. and known problems and their
solutions.
 Often no “right” answer.
 No framework for handling quality
properties.
SOLVING THE ACCIDENTAL DIFFICULTIES
 Organize the architectural design process.
 define roles and activities

 Define the use of architecture artefacts

 which models? When? Why?

 Capture, Classify and share knowledge:

 proven practices and solutions
 problems and pitfalls
 REPRESENTING ARCHITECTURE

 Software architecture is effectively expressed and communicated through

models and diagrams.
 You will see several UML diagrams to represent the different perspectives to be
considered in software architecture.
ARCHITECTURE CHARACTERISTICS

36
ARCHITECTURE CHARACTERISTICS
 Architecture characteristics are another dimension of defining software
architecture.
 The architecture characteristics define the success criteria of a system,
which is generally orthogonal to the functionality of the system.
 Notice that all of the characteristics listed do not require knowledge of the
functionality of the system, yet they are required in order for the system to
function properly.

37
 38
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
SMART UNIVERSITY REFERENCE ARCHITECTURE
… SMART UNIVERSITY REFERENCE ARCHITECTURE
In May 2021, SECC successfully completed the Smart Universities Project in cooperation
with the Ministry of Communications and Information Technology and the Egyptian Supreme
Council of Universities. The project objective was to assess and define transformation
roadmap for Egyptian universities using Smart Universities Reference Architecture (SURA)
developed by SECC experts.
SURA was developed according to TOGAF enterprise architecture framework and COBIT
framework for IT Governance. The project included 27 universities that obtained training,
certification and assessment services.
Smart Smart Smart
Learning Assessment Classroom

Smart Smart Smart

Support Operations Campus
SOFTWARE ARCHITECTURE VS. SOFTWARE DESIGN
- Software Architecture Patterns: What Are the Types and Which Is the Best One for
Your Project, by Ritvik Gupta, 2024 – 11 mins read.
(https://www.turing.com/blog/software-architecture-patterns-types )
- Difference Between Software Architecture and Software Design | Scott Duffy
(https://www.youtube.com/watch?v=i7aKW7YNOxY )
- Book: “Software Architecture: Foundations, Theory, and Practice”, Richard N. Taylor,
Irvine, Nenad Medvidovic, Eric Dashofy, ISBN: 978-0-470-16774-8 (Ch1. The Big
Idea).
- SURA: https://secc.org.eg/English/Pages/SECC-SURA.aspx