Software Architecture and Design

SWE4210
Lecture 01: Introduction
Venue: SWE Lab
Presented by: Saratu Yusuf Ilu
 Course Description
• This course provides an in-depth exploration of software architecture and design,
focusing on advanced design principles, architectural patterns, and the
structural organization of complex systems.

• Students will study contemporary frameworks and middleware architectures,

and learn to design scalable, distributed systems using component-based and
service-oriented approaches.

• Topics include the role of architecture in software engineering, design for quality
attributes (such as reliability, performance, security, and reusability), and the
application of design metrics and measurement theory.

• The course also covers software complexity analysis, architectural evaluation

methods, and the evolution of software systems through techniques such as
reengineering and reverse engineering.
 Learning Outcomes

By the end of this course, students will be able to:

• Understand and explain the principles, roles, and impact of software
architecture in the development lifecycle.
• Apply design principles and architectural styles to build scalable, component-
based, and distributed systems.
• Evaluate architectures based on quality attributes like performance, reliability,
security, and reusability.
• Use software metrics to measure internal qualities such as complexity,
maintainability, and modularity.
• Analyze and evolve existing systems through refactoring, reengineering, and
reverse engineering techniques.
 Course Outline

• Introduction to Software Architecture and Design

• Architectural Styles and Patterns
• Component-Based and Distributed System Design
• Middleware and Frameworks
• Quality Attributes and Design for Non-Functional Requirements
• Metrics, Measurement, and Complexity
• Software Evolution, Reengineering, and Reverse Engineering
 Course Lecturer

• The course will be taken by 1 lecturer

• Dr. Saratu Yusuf Ilu
 Lecture

• 2 Credit Hour Course

• Wednesday – 9 to 11am
 Course Assessment

• CA – 30%

• Exams – 70%
• 5 questions to answer 3
 Reference Text
• Software Architecture in Practice (4th Edition) – Len Bass, Paul Clements, Rick
Kazman
• A foundational book covering architectural concepts, styles, quality attributes,
and case studies. Publisher: Addison-Wesley, 2022
• Designing Software Architectures: A Practical Approach – Humberto Cervantes & Rick
Kazman
• Step-by-step guide to designing architectures with a focus on quality-driven
design. Publisher: Addison-Wesley, 2016
• Software Systems Architecture: Working with Stakeholders Using Viewpoints and
Perspectives (2nd Edition) – Nick Rozanski & Eóin Woods
• Practical techniques for designing and documenting software architecture using
views. Publisher: Addison-Wesley, 2012
• Pattern-Oriented Software Architecture: A System of Patterns – Frank Buschmann et
al.
• In-depth reference for architectural patterns and styles. Publisher: Wiley, 1996
 Lecture Outline

• By the end of this class, students should be able to:

1. Define software architecture and distinguish it from software design.
2. Explain foundational principles of software design like modularity, abstraction,
and separation of concerns.
3. Understand how architecture fits into the software development lifecycle.
4. How Software Architecture relates to Non-Functional Requirements.
 What is Software Architecture??
• Bass, Clements, Kazman
• “The structure of the components of a program/system, their interrelationships, and
the principles and guidelines governing their design and evolution.”

• Perry and Wolf

• “Architecture is concerned with the selection of architectural elements, their
interactions, and the constraints on those elements and their interactions necessary
to provide a framework in which to satisfy the requirements and serve as a basis for
the design.” Elements are divided into processing elements, data elements and
connection elements
• Garlan and Shaw
• Architecture for a specific system may be captured as “a collection of computational
components, or simply components together with a description of the interactions
between these components, the connectors”
• Sommerville, 7th edition
• The design process for identifying the sub-systems making up a system and the
framework for sub-system control and communication is architectural design. The
output of this design process is a description of the Software Architecture.
 What is Software Architecture??
• The software architecture of a program or computing system is the structure or
structures of the system, which comprise:
• software elements (components)
• the externally visible properties of those elements, and
• the relationships among them.”
• Bass, Clements, and Kazman
• Key Points:
• High-level blueprint of a software system.
• Describes what components exist, how they interact, and how the system behaves.
• Focuses on non-functional aspects like scalability, modifiability, performance, and
security.
 Relating Software Architecture to Building Architecture
• Software architecture and building architecture share many principles, even though one is
intangible (software) and the other physical (buildings).
• Both involve structural planning, designing for functionality and qualities, and
balancing constraints.
Concept Building Architecture Software Architecture
Floor plans and construction Component diagrams and system
Blueprint
drawings models
Structure Foundation, walls, rooms Modules, services
Components Plumbing, wiring APIs, data bases, UI layers
Connectors Doors, pipes, electrical wiring APIs, protocols, message buses
Quality Performance, security,
Safety, durability, accessibility
Attributes maintainability, usability
Stakeholders Owner, engineer, builders, users Client, developer, user
Standards & Software standards, design
Building codes, zoning laws
Codes patterns, coding practices
Evolution Renovation Reengineering, version upgrades
 Relating Software Architecture to Building Architecture
• Changes and Maintenance

Action In Buildings In Software

Minor fix Repair a leak Bug fix
Upgrade Add a room Add a feature
Redesign Reconstruct a floor Refactor a module
Reuse Use modular furniture Use reusable libraries or components

• Just as building architects create safe, functional, and beautiful structures for people to
live and work in, software architects design systems that are efficient, reliable, and
adaptable for users and businesses.
 Characteristics of Software Architecture

Characteristic Description

Structure Defines organization of components and their interaction

Abstraction Hides low-level details; focuses on the system's big picture

Captures important design decisions, including the pros and cons

Guiding Principles of different options, and follows proven solutions to common
problems.
Affects system evolution, maintenance, and technical debt (The
architecture you choose today determines how easily your system
Long-Term Impact
can grow, adapt, and survive tomorrow. A solid architecture saves
time, money, and stress in the long run.)

Stakeholder Focus Addresses concerns of clients, developers, testers, operations, etc.

 Why Software Architecture Matters
• Strategic Importance:
• Aligns software with business goals.
• Ensures system can meet quality attributes like performance and reliability.
• Helps coordinate teams working on different parts of the system.
• Affects cost, schedule, and risk during development and maintenance.
• Without good architecture:
• System becomes fragile and hard to change.
• Small changes may cause ripple effects.
• Development slows due to tight coupling and poor modularity.
• Tight coupling refers to a situation where two or more components/modules in a
system are highly dependent on each other. If one changes, the other often must
change too.
• Poor modularity means that a software system is not well-divided into
independent, self-contained modules, making it hard to understand, maintain,
reuse, or scale.
 Software Design vs Architecture
• Architecture is the high-level structure of a system.
• Design focuses on the detailed implementation of components.
• Think of architecture as a city plan and design as the blueprints for individual buildings

Aspect Software Design Software Architecture

Scope Module or class-level (component Global (system level)

level)
Focus Algorithms and implementation Structure, interactions, system
details constraints
Stakeholders Developers, testers Architects, business owners,
clients
Abstraction Level Low High
Design class diagrams, pseudo Architecture diagrams, style
Output Artifacts code, flowcharts decisions
 Principles of Software Design

1. Modularity
• Divides a system into manageable, reusable units.
• Promotes low coupling and high cohesion (High cohesion means that all the parts of
a module, class, or component are strongly related and work together to perform a
single, well-defined task.).
2. Abstraction
• Hides complexity by exposing only essential features.
• Example: A database API hides SQL query details from the UI.
3. Separation of Concerns
• Different parts of the system handle different responsibilities.
• Example: MVC (Model-View-Controller) separates data, logic, and interface.
 Relating Software Design to Building Design

1. Modularity: Just as buildings have rooms with specific functions (e.g., kitchen,
bathroom), software has modules (e.g., auth service, payment processor).
2. Abstraction: A software module is like a room; it serves a purpose and hides complexity.
3. Separation of Concerns: In buildings, structure is separated from plumbing and decor.
In software, logic is separated from data storage and user interface.
 Architectural Artifacts
• Architectural artifacts are the documents, models, diagrams, or specifications that
capture and communicate the structure, decisions and rationale of a software system’s
architecture.
• They help stakeholders (developers, designers, clients) understand, analyze, and discuss
the system.
• Goals of Architectural Artifacts
• Documentation: Capture important decisions and structures
• Communication: Help teams understand and discuss the design
• Analysis: Identify risks, trade-offs, and evaluate quality attributes
• Evolution: Provide a baseline for future changes and maintenance
• Why Architectural Artifacts Matter
• Clarify design decisions
• Document system structure for current and future teams
• Support communication and alignment across stakeholders
• Provide a basis for evaluation, review, and evolution
 Examples of Architectural Artifacts
Artifact Type Description Example
Shows components and how they
Architecture Diagram Layered view of a web app
interact
Defines major software units and
Component Model Modules, classes
their roles
Shows how software is mapped to
Deployment Diagram Cloud services across servers
hardware
Defines how components
Interface Specifications REST API contract
communicate
Design Rationale Explains why certain decisions Why you chose a message
Document were made queue
Architecture Description Comprehensive description of the
IEEE 1471
Document (ADD) system’s architecture
Describes non-functional “System must handle 10k
Quality Attribute
requirements and how the system requests/sec with <1s
Scenarios
supports them latency”
 Common Roles of an Architect

Role Responsibility

Technical leader Guides technical decisions across teams

Quality driver Ensures the system meets non-functional goals

Mediator Balances conflicting stakeholder concerns

Planner Anticipates future change and scalability needs

Coach/Mentor Educates teams on architectural principles

 Role of Software Architecture in the Software Lifecycle

Phase Architectural Role

Requirements
Identify critical quality attributes (e.g., performance)

Design
Choose suitable architectural patterns and styles

Implementation Translate architectural plans into code

Testing Verify architectural constraints and interfaces

Deployment Map components to infrastructure. This means Assigning

software components (like databases, or modules) to specific
physical or virtual infrastructure (like servers or cloud instances).
Maintenance Support changes with minimal architectural disruption
 Architecture and Non-Functional Requirements
• Software architecture directly enables or constrains system qualities:

Quality Attribute Architectural Impact Example

Scalability Use of microservices, load balancers, async communication

Availability Redundancy, fault-tolerant components

Security Isolation of services, secure data flows, role-based access

Performance Caching strategies, low-latency communication protocols

Modifiability Loose coupling, high cohesion, modular design

Reusability Component generalization, plug-in architecture

 Benefits of Software Architecture
1. Strategic Alignment with Business Goals
2. Managing System Complexity
3. Facilitating System Evolution and Maintenance
4. Supporting Trade-off Analysis and Decision Making
5. Enhancing System Quality Attributes (Non-Functional Requirements)
6. Improved Team Coordination and Communication
7. Foundation for Reuse and Standardization
8. Architecture as a Basis for System Evaluation
9. Easier Integration with Other Systems
10. Tool and Automation Support
 Strategic Alignment with Business Goals
• Architecture connects technical design to business objectives.
• It Helps to ensure that the system supports core functionalities and key quality attributes
(e.g., performance, scalability, reliability).
• Enables cost-effective planning for future features, scaling, and integration.

• Example: A well-designed e-commerce platform architecture supports rapid addition of

new payment gateways, aligning with global market expansion goals.
 Managing System Complexity

• Architecture provides a high-level view of the system, simplifying comprehension and

analysis.
• It defines clear modules, boundaries, and responsibilities, which:
• Reduce cognitive overload for developers.
• Make systems easier to extend, test, and debug.

• Example: Developers can quickly understand a new service by referring to the

architectural diagram instead of reading thousands of lines of code.
 Facilitating System Evolution and Maintenance
• Architecture enables flexible adaptation to changing requirements or technologies.
• Good architectures isolate volatile components and allow controlled evolution.
• Facilitates refactoring and reuse by enforcing modularity.

• Example: A microservices-based architecture allows an organization to update services

independently without system-wide disruption.
 Enhancing System Quality Attributes (Non-Functional
Requirements)
• Software architecture directly supports many critical system qualities:

Quality Attribute Architectural Benefit Example

Performance Use of caching, load balancing, asynchronous processing
Scalability Horizontal scaling with stateless services
Reliability Redundancy and failover mechanisms
Security Layered security, secure communication protocols
Maintainability Clear module separation and interface definition
Modifiability Low coupling and high cohesion of components
 Improved Team Coordination and Communication

• Architecture acts as a shared mental model for developers, testers, managers, and
stakeholders.
• Enables distributed teams to work independently on separate components.
• Reduces misunderstandings by providing clear documentation and design rationale.

• Example: In large Agile teams, architecture defines APIs and contracts upfront so teams
can develop in parallel.
 Foundation for Reuse and Standardization
• Promotes reusability of components, patterns, and subsystems.
• Enables standardization across products, projects, or organizational units.

• Example: Platform teams build reusable architectural frameworks (e.g., authentication

modules, logging systems) to support many applications.
THANK YOU