An Introduction to
Software Architecture
Software Engineering Lab
Table of content
Introduction
Architecture Business Cycle
Architectural Structures and Views
Quality Attributes
Achieving Qualities
Software Architecture Analysis
Method
Introduction
Definition
The software architecture of a
program or computing system is
the structure or structures of the
system, which comprise software
elements, the externally visible
properties of those elements, and
the relationships among them.
Externally Visible vs. Internal
Properties
Externally visible properties are what
assumption other elements can make of
an element
Provided services (and interface to access
those services)
Performance
Fault handling
Shared resource usage
SA intentionally abstracts away internal
properties of elements (to better
encounter complexity)
Why is architecture
important?
Handling
complexity
Communication
among stakeholders
Requirements and concerns of
stakeholders
Time
Budget
Other Resources
Why is architecture important?
(cont)
Early
Design Decisions
Constraints implementation and
implementers
Organizational structure
Enables predicting and ensuring quality
attributes
Helps evolutionary prototyping (risk
reduction)
Why is architecture important?
(cont)
SA
is a transferable, reusable model
Software product lines
Component-based development
Automatic generation of lower-level
models
A basis for training
Hazards
With
regards to SA changes are
categorized to
Local (a single component)
Non-local (a few components)
Architectural (architectural style)
Once
decided architecture is extremely
hard to change
It impossible to reach to some quality
attribute if architecture disallows
Software Arch. vs. System
Arch.
System
Arch. is the overall architecture of
system including hardware and software
architecture
In assuring quality attributes the architect
needs to think about system architecture
too (e.g. performance or reliability)
But architect has more freedom in software
architecture than hardware (hardware
choices is less under the architects control)
Architecture Business Cycle
Who influences SA?
Summary: Influences on the
Architect
Architecture Business Cycle
Architectural Structures and
Views
Architectural Structures and
Views
In construction, there are blueprints of
Plan
Different sides of construction
Electrical wiring
Plumbing
Each of these views specifies a single entity (i.e. the
construction) from a different perspective (used by
a different person, for a different goal).
Similarly there are different structures and views in
SA.
Structures and Views (cont)
Structures is a set of coherent elements and the
relations among them. For each structure these we can
specify:
Types
of elements
Types of relations
A set of syntactic constraints
Semantics of the diagram
Rationale, principles, and guidelines
For what purposes it is useful
View is a representation of software architecture based
on an structure as written by the architect and read by
stakeholders (an instance of the structure)
SA is documented by a number of views.
Categorization of Structures
Module Structures
2. Component and Connector
Structures
3. Allocation Structures
1.
Module Structures
Elements:
modules (units of
implementation). Modules are a code based
way of considering the system
Specifies:
Functional responsibility of modules
Other elements a module is allowed to use
Generalization and specialization relations
Run-time
operation of software is not a
concern from this view
1.1 Decomposition
Structure
Elements:
modules in a hierarchy
Relations: is a sub-module of, shares
secret with
Function
Example:
Contributes to system's modifiability, by
ensuring that likely changes fall within
the scope of at most a few small
modules.
1.2
Uses Structure
Elements:
modules, procedures, or
resources on the interfaces of modules
Relations: uses: one unit uses another
if the correctness of the first requires
the presence of a correct version (not
a stub of) of the second.
Function
Example:
Allows incremental development
1.3
Layered Structure
Is
a subclass of uses structure
Elements: layers: a coherent set of related
functionality
Relations: uses (ideally layer n may only use
the services of layer n 1), provides
abstraction to
Function
Example:
Layers are often designed as abstractions (virtual
machines) that hide implementation specifics below
from the layers above, engendering portability.
1.4
Class Structure
Elements:
classes
Relations: inherits from, is an instance
of
Function
Example:
Allows us to reason about reuse and the
incremental addition of functionality
2 Component and Connector
Structures
Elements:
run-time components (principal units
of computation) and connectors (communication
vehicle among components.)
Specifies:
Major executing components and how they interact
Major shared data-stores
Which part of system is replicated
Flow of data through the system
What parts can run in parallel
How can system structure change as it executes
2.1
Process Structure
Elements:
processes or threads
Relations: attachment (that allow
communication, synchronization,
and/or exclusion operations)
Function
Example:
Engineering a system's execution
performance and availability.
2.2 Shared Data or Repository
Structure
Elements:
data stores, data producers,
and data consumers
Relations: data-flow
Function
Example:
To ensure good performance and data
integrity.
2.3
Client-Server Structure
Elements:
clients and servers
Relations: protocols and message
passing infrastructure.
Function
Example:
Separation of concerns (supporting
modifiability)
Load balancing (supporting runtime
performance)
Allocation Structures
Show
the relationship between the software
and the elements in one or more external
environment in which software is created
and executed.
Specifies:
The processor that executes each software
element
The file that stores each software element
during development
Assignments of software to development team
3.1 Deployment Structure
Shows
how software is assigned to hardware
Elements: software (usually a process from a
component and connector view), hardware
entities, and communication pathways
Relations: is-allocated-to and migrates-to
(for dynamic allocations)
Function
Example:
Allows reasoning about performance, data
integrity, availability, and security.
3.2
Implementation
Structure
Shows
how software elements (usually
modules) are mapped to the file structure(s)
in the system's development, integration, or
configuration management environments.
Elements: any logical unit (e.g. module)
Relations: implemented in
Function
Example:
management of development activities and build
process
3.3
Work Assignment
Structure
Assigns responsibility for implementing and integrating
the modules to the appropriate development teams
Elements: any logical unit (e.g. module)
Relations: is assigned to
Function Example:
The architect will know the expertise required on
each team
The means for factoring functional commonalities
and assigning them to a single team, rather than
having them implemented by everyone who needs
them.
Notes
Each
structure is useful on its own right but
not all structures are used in all projects.
Structures
are not independent and must be
considered together
e.g. relationship of modules with components
(many to many)
Some structures may be the same in some systems
Some structures may be combined (e.g. all
component and connector structures may be
combined in a single structure)
4 + 1 View Model of
Architecture
Logical:
objects and classes (a module view)
Process: (a component and connector view)
Development: modules, libraries,
subsystems, and units of development (an
allocation view)
Physical: mapping of elements to hardware
and communication (an allocation view)
Scenarios (Use-cases) view is not itself
architectural.
Quality Attributes
Traditional Classification of
Requirements
Functional
Non-Functional (Quality Attributes)
A popular software myth: first we build a
software that satisfies functional
requirements, then we will add or inject
non-functional requirements to it.
This idea leads to loss of resources and
finally poor quality.
So we should design for qualities from
the very beginning (architecture level).
Functionality and
Architecture
Functionality
and quality attrs are
orthogonal [in theory]. But not all
qualities are achievable to any level
desired with any functionality.
Functionality may be achieved in many
ways (it is not so architectural.)
Architecture is a means of achieving
quality attributes by structuring
functionality into elements.
Architecture and Qualities
Achieving
qualities must be considered
throughout design (including SA),
implementation, and deployment.
Qualities have both architectural and
non-architectural aspects. For example
Performance: amount of communication
among components vs. algorithms
Classification of Quality
Attributes
1.
2.
3.
Qualities of the system: availability,
modifiability, performance,
security, testability, and usability.
Business qualities (such as time to
market) that are affected by the
architecture.
Architecture qualities, such as
conceptual integrity.
System Quality Attributes
Availability
(related to Reliability)
Modifiability (includes Protability and
Reusability, Scalability)
Performance
Security
Testability
Usability (includes Self-Adaptability and
User-Adaptability)
Business Qualities
Time
to market
Cost and benefit
Predicted lifetime of the system
Targeted market
Rollout schedule
Integration with legacy systems
Qualities of the Architecture
Conceptual
Integrity
Conceptual integrity is the most important
consideration in system design. It is better to
have a system omit certain anomalous features
and improvements, but to reflect one set of
design ideas, than to have one that contains
many good but independent and uncoordinated
ideas. [Brooks 75 ]
Correctness
Buildability
and Completeness
Achieving Qualities
The Whole Story
Business
Requirements
Quality
Requirements
Tactics Selection
Tactics Implementation:
Design Patterns &
Architectural Patterns
Tactics
A
tactic is a design decision that influences a quality
attribute.
e.g.
using redundancy to increase availability
Tactics can be refined to other tactics to become
more concrete; e.g. redundancy: redundancy of
data + process
Availability Tactics
Modifiability Tactics
Patterns
A
pattern is a common abstract solution to
a common abstract problem that
Can be tailored to a given situation
Has predefined characteristics
Abstraction
level of patterns
Business
Analysis
Architecture
Design
Implementation (Idioms)
Test Patterns (or guideline to testing patterns)
Relationship of Tactics to
Patterns
An
architect usually chooses a
pattern or a collection of patterns
designed to realize one or more
tactics.
However,
each pattern implements
multiple tactics, whether desired or
not.
Famous Pattern (Style)
categories
Data-centered
Repository
Blackboard (publisher-subscriber)
Structural
Scalability
solution to integrability of data
Modifiability
Client
Client
Shared Data
Client
Client
Famous Pattern (Style)
categories
Dataflow
Bach sequential
Pipes and filters
Reusability
Modifiability
Not
interactive
Poor performance
Famous Pattern (Style)
categories
Call and Return
Main program and sub-routine
Modifiability
Remote procedure call
Performance
tuning
Object-oriented or abstract data type
Modifiability
Reuse
Layered
Modifiability
Portability
Example: ATM Software
Develop 3 different architectures for ATM
software and compare them regarding
fulfillment of quality attributes.
ATM = Automatic Teller Machine
User operations:
Insert card and enter PIN
Withdraw money
Check Balance
Shared-Memory Style
Abstract Data Type
Style
Layered
Style
Analysis and Comparison
Performance
Change account record
format
New service: close account
and withdraw the remained
balance
Portability
Availability and Reliability
Buildability and Integrability
Sum
SharedMem
3
1
ADT
2
3
Layere
d
1
3
1
2
1
9
2
2
2
13
3
2
3
15
