Chapter One

Introduction to Software Architecture

Alemayehu Sh.(M.Sc. in CSE)

Wachemo University
College of Engineering and Technology
Department of Software Engineering
Software Architecture and Design─ Introduction

• Software Architecture describes major components of a system, their relationships (structures),

and how they interact with each other
• Software architecture and design includes several contributory factors such as:
• Business strategy
Quality
• Quality attributes Attributes IT
• Human dynamics Environment
• Design, and Design
• IT environment
Software
Architecture

Business Human
Strategy Dynamics
Introduction Cont.
• Architecture is a general term to describe buildings and other
physical structures
• Building in our case is a system or a software
• Three important things in architecture are:
• Durability: should last for a long time
• Utility: should be useful for the people
• Beauty: should look good and rise the users sprits
Introduction Cont.
What is architecture and what is not?
• Architectures are not concerned with the creation of building
technologies and materials.
• Not better glass quality or strong concrete
• Architectures are concerned with how building materials can be put
together in durable, most useable and most aesthetically appealing
way
• The high level design process that indicates the system’s
components, their connections and interactions in a useful, pleasing
and cost-effective way is called architecture.
Introduction Cont.
Software Architecture vs Design

• We can separate Software Architecture and Design into two distinct phases: Software
Architecture and Software Design.

Architecture:

• Architecture serves as a blueprint for a system

• It provides an abstraction to manage the system complexity and establish a communication
and coordination mechanism among components
•It defines a structured solution to meet all the technical and operational requirements, while
optimizing the common quality attributes like performance and security
Introduction Cont.
Architecture
• Architecture involves a set of significant decisions about the
organization related to software development
• Architectural decisions can have a considerable impact on
• Quality
• Maintainability
• Performance, and
• The overall success of the final product
Introduction Cont.
Architectural decisions comprise of:
• Selection of structural elements and their interfaces by which the
system is composed
• Selection of Behavior elements as specified in collaborations among
those elements
• Composition of these structural and behavioral elements into large
subsystem
• Architectural decisions align with business objectives
• Architectural styles guide the organization of architectural elements
Architectural Issues, Options and Decisions

A an architect is faced with a series of architectural design

issues

• These are sub-problems of the overall design problem.

• Each issue normally has several alternative solutions (or design
options)

• The designer makes a design decision to resolve each issue.

• This process involves choosing the best option from among the
alternatives.

8
Taking Decisions
Design
problem
Problem
space
sub-problem sub-problem
(or issue) (or issue)

Decision
Design
space
Design Design Design
Option A Option B Option A Option B
Decision =
Decision =
best option
Alternative Alternative best option
solutions solutions

9
Decision space
The space of possible designs that can be achieved by choosing
different sets of alternatives.

fat-client
Programmed in Java
client in a
separate
client user interface
style layer
client-server
thin-client Programmed in Visual Basic

Programmed in C++

no separate
monolithic user interface Python
layer

10
Tree Decision Space?
• Issues and options are not independent ...

fat-client client in a
separate
client-server user interface
client layer
style
thin-client

no separate
monolithic user interface
layer

11
More than just IT

• Technical and non-technical issues and options are intertwined

• Architects deciding on the type of database

versus
• Management deciding on new strategic partnership
or
• Management deciding on budget

12
Types of Decisions
• Implicit, undocumented
• Unaware, tacit, of course knowledge
• Explicit, undocumented
• Vaporizes over time
• Explicit, explicitly undocumented
• Tactical, personal reasons
• Explicit, documented
• Preferred, exceptional situation

13
Why is Documenting Design Decisions Important?

• Prevents repeating (expensive) past steps

• Explains why this is a good architecture
• Emphasizes qualities and criticality for requirements/goals
• Provides Context and Background

14
Uses of Design Decisions
• Identify key decisions for a stakeholder
• Make the key decisions quickly available. E.g.,
introducing new people and make them up2date.
• ..., Get a rationale, Validate decisions against
requirements

• Evaluate impact
• If we want to change an element, what are the
elements impacted (decisions, design, issues)?
• ..., Cleanup the architecture, identify important
architectural drivers

15
Elements of a Design Decision

• Issues: design issues being addressed

• Decision
• Status: e.g., pending, approved
• Assumptions: underlying assumptions
• Alternatives
• Rationale; the why of the decision taken
• Implications: e.g. need for further decisions

16
Introduction
Cont.
Software Design
• Software design provides a design plan that describes the elements of
a system, how they fit, and work together to fulfill the requirement of
the system
• The objectives of having a design plan are as follows
• To negotiate system requirements, and to set expectations
with customers, marketing, and management personnel
• Act as a blueprint during the development process
• Guide the implementation tasks, including detailed design,
coding, integration, and testing
Introduction Cont.
Where to Place Software Architectural Design in the Systems Development Life Cycle

• Domain analysis, requirements analysis, and risk analysis comes before architecture design
phase,
• The detailed design, coding, integration, and testing phases come after it

Hardware
Requirement Architecture
Domain Analysis Desired Quality Software Architecture Hardware
Requirements Analysis
Design Architecture Design
Risk Analysis
Modification
Modification to To h/w arch.
requirements
Implementation Constraints

Detailed Design
 Introduction Cont.
Goals of Architecture

• The primary goal of the architecture is to identify requirements that affect the structure of the
application
• A well-laid architecture reduces the business risks associated with building a technical solution and
builds a bridge between business and technical requirements
• Some of the other goals are as follows :
• Expose the structure of the system, but hide its implementation details
• Realize all the use-cases and scenarios
• Try to address the requirements of various stakeholders
• Handle both functional and quality requirements.
• Reduce the goal of ownership and improve the organization’s market position
• Improve quality and functionality offered by the system
• Improve external confidence in either the organization or system
Introduction Cont.
Limitations of Software Architecture
• Software architecture is still an emerging discipline within software engineering.
• It has the following limitations:
• Lack of tools and standardized ways to represent architecture.
• Lack of analysis methods to predict whether architecture will result in an implementation
that meets the requirements.
• Lack of awareness of the importance of architectural design to software development.
• Lack of understanding of the role of software architect and poor communication among
stakeholders.
• Lack of understanding of the design process, design experience and evaluation of design.
Introduction Cont.
Role of Software Architect
• Software Architect provides a solution that the technical team can create and design for the entire
application
• A software architect should have expertise in the following areas:
• Design Expertise: diverse methods and approaches of software design
• Domain Expertise: system being developed and facilitate requirements
investigation and definition of domain model
• Technology Expertise: Available technology for Implementation and coordinate
their selection
• Methodological Expertise: SDLC and appropriate development approach
• Deliverables of the Architect: deliver clear, complete, consistent, and achievable
set of functional goals to the organization
• Hidden Role of Software Architect: bridge the team members(trust) and protect
from external distracting situation, which has less value to the project
The Role of the Architect

requirements solutions
client,
architect developers
users

assess creates assess

visualises prescribes

appearance, architectural construction,

behaviour design co-operation
22
Introduction Cont.
Quality Attributes of Software Architecture
• Quality is a measure of excellence or the state of being free from deficiencies or defects
• Quality attributes are the system properties that are separate from the functionality of the system
• Implementing quality attributes makes it easier to differentiate a good system from a bad one
• Quality Attributes are overall factors that affect runtime behavior, system design, and user experience
• Software Architecture Quality Attributes can be classified as:
• Static Quality Attributes:
• Reflect the structure of a system and organization, directly related to architecture, design, and
source code.
•They are invisible to end-user, but affect the development and maintenance cost, e.g.: modularity,
testability, maintainability, etc.
• Dynamic Quality Attributes:
•Reflect the behavior of the system during its execution.
•They are directly related to system’s architecture, design, source code, configuration, deployment
parameters, environment, and platform.
• They are visible to the end-user and exist at runtime, e.g. throughput, robustness, scalability, etc.
Introduction
Cont.
Software Architecture Quality Scenarios
• Quality scenarios specify how to prevent a fault from becoming a failure.
• They can be divided into six parts based on their attribute specifications
•Source − An internal or external entity such as people, hardware, software, or physical
infrastructure that generate the stimulus.
•Stimulus − A condition that needs to be considered when it arrives on a system
•Environment − The stimulus occurs within certain conditions
•Artifact − A whole system or some part of it such as processors, communication channels,
persistent storage, processes etc.
•Response − An activity undertaken after the arrival of stimulus such as detect faults,
recover from fault, disable event source etc.
•Response measure − Should measure the occurred responses so that the requirements
can be tested
 Introduction
Common Quality Attributes
Category
Design Qualities
Run-time Qualities
System Qualities
User Qualities
Architecture Quality
Non-runtime Quality
Business quality attributes
Cont.
Quality Attribute Description
Conceptual Integrity Defines the consistency and coherence of the overall design. This includes the way
components or modules are designed.
Maintainability Ability of the system to undergo changes with a degree of ease.
Reusability Defines the capability for components and subsystems to be suitable for use in other
applications.
Interoperability Ability of a system or different systems to operate successfully by communicating and
exchanging information with other external systems written and run by external parties.
Manageability Defines how easy it is for system administrators to manage the application.
Reliability Ability of a system to remain operational over time.
Scalability Ability of a system to either handle the load increase without impacting the performance of
the system or the ability to be readily enlarged.
Security Capability of a system to prevent malicious or accidental actions outside of the designed
usages.
Performance Indication of the responsiveness of a system to execute any action within a given time interval.
Availability Defines the proportion of time that the system is functional and working. It can be measured
as a percentage of the total system downtime over a predefined period.
Supportability Ability of the system to provide information helpful for identifying and resolving issues when it
fails to work correctly.
Testability Measure of how easy it is to create test criteria for the system and its components.
Usability Defines how well the application meets the requirements of the user and consumer by being
intuitive.
Correctness Accountability for satisfying all the requirements of the system.
Portability Ability of the system to run under different computing environment.
Integrality Ability to make separately developed components of the system work correctly together.
Modifiability Ease with which each software system can accommodate changes to its software.
Cost and schedule Cost of the system with respect to time to market, expected project lifetime & utilization of
legacy.
Marketability Use of system with respect to market competition.
IEEE Model for Architectural
Descriptions
Mission

Environment System Architecture

Architecture
Stakeholder Description Rationale

Concern Viewpoint View

Library
Viewpoint Model

26
Some terms (from IEEE standard)
• System Stakeholder: an individual, team, or organization (or
classes hereof) with interests in, or concerns relative to, a
system.

• View: a representation of a whole system from the

perspective of a related set of concerns of the stakeholders.

• Viewpoint: A viewpoint establishes the purposes and

audience for a view and the techniques or methods
employed in constructing a view.

27
Stakeholders
• Architect
• Requirements Engineer
• Designer (also of other systems)
• Implementer
• Tester, integrator
• Maintainer
• Manager
• Quality assurance people

28
 Viewpoint Specification

• Viewpoint name
• Stakeholders addressed
• Concerns addressed
• Language, modeling techniques

29
Kruchten’s 4+1 View Model
End-user Programmers
Functionality Software management

Implementation
Logical Viewpoint
Viewpoint

Scenarios

Process Deployment
Viewpoint Viewpoint

Integrators System engineers

Performance Topology
Scalability Communications

30
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., classes and

interactions amongst them).

31
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.

32
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.

33
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.

34
4 + 1: Scenario Viewpoint (the one the in 4 +
1)
• 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.

35
Architectural views from Bass et al (view = representation of a
structure)
• Module views
• Module is unit of implementation
• Decomposition, uses, layered, class

• Component and connector (C & C) views

• These are runtime elements
• Process (communication), concurrency, shared data (repository), client-server

• Allocation views
• Relationship between software elements and environment
• Work assignment, deployment, implementation

36
Module views
• Decomposition: units are related by “is a
submodule of”, larger modules are composed of
smaller ones
• Uses: relation is “uses” (calls, passes information
to, etc). Important for modifiability
• Layered is special case of uses, layer n can only use
modules from layers <n
• Class: generalization, relation “inherits from”

37
Component and connector views

• Process: units are processes, connected by

communication or synchronization
• Concurrency: to determine opportunities for
parallelism (connector = logical thread)
• Shared data: shows how data is produced and
consumed
• Client-server: cooperating clients and servers

38
Allocation Views
• Deployment: how software is assigned to
hardware elements
• Implementation: how software is mapped onto file
structures
• Work assignment: who is doing what

39
How to Decide on Which Viewpoints

• What are the stakeholders and their concerns?

• Which viewpoints address these concerns?

• Prioritize and possibly combine viewpoints

40
• End of Chapter One…

More Reading is Required to Masters as a Master!

 Assignment 1: Read one of the following 4 articles and
present your understanding in the class ( group of 5-6)

• Hofmeister et al, Generalizing a Model of Software Architecture Design

from Five Industrial Approaches, Journal of Systems and Software,
2007 (G-1-Senedu’s Group)
• Tyree and Ackerman, Architecture decisions: demystifying architecture,
IEEE Software, vol. 22(2), 2005. (G-2-Yonas’s Group)
• Kruchten, Lago and van Vliet, Building up and exploiting architectural
knowledge, WICSA, 2005. (G-4-Miraj’s Group)
• Lago and van Vliet, Explicit assumptions enrich architectural models,
ICSE, 2005. (G-3-Ashenafi’s Group)

42