Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
362 views

An Introduction To Software Architecture

This document provides an introduction to software architecture. It defines software architecture as the structure of a system comprising software elements, their relationships, and externally visible properties. The document discusses why architecture is important for handling complexity, communication, early design decisions, and more. It also covers architectural structures and views, quality attributes, and the software architecture analysis method.

Uploaded by

kingraaja
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
362 views

An Introduction To Software Architecture

This document provides an introduction to software architecture. It defines software architecture as the structure of a system comprising software elements, their relationships, and externally visible properties. The document discusses why architecture is important for handling complexity, communication, early design decisions, and more. It also covers architectural structures and views, quality attributes, and the software architecture analysis method.

Uploaded by

kingraaja
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 56

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

You might also like