SOFTWARE ARCHITECTURE

Why Software Architecture?

 Why Software Architecture ?

1. Increasing Size and Complexity of Software
Systems.
2. Designing and Specifying the overall system
structure.
3. Gross organization and global control of
systems structure.
4. Scaling and Performance.
5. Selection among design alternatives.
 What is Software Architecture?

 A working definition of Software Architecture:

“ A software architecture is a description of the
sub-systems and components of a software system
along with its inter-relationships. Sub-systems and
components can be specified in multiple views or
perspectives to show the various functional and non-
functional properties of a software system. The
software architecture of a system is an artifact. This
is the result of the software design activity.”
Where does Software Architecture fit in the

Requirements Eng. Detailed Design

Arch. Design

Deployment Testing Coding

Maintenance
 What is Software Architecture?


Software Architecture - Involves
3) Description of elements from which
systems are built.
4) Interactions among those elements.
5) Patterns that guide their composition.
6) Constraints on these patterns
7) Systems built in 1) may be in turn used as
a composite element in a larger system
design.
Important Terminologies used in Software Arch

 Component
 Connectors or Relationships
 View
 Functional Property
 Non-Functional Property
 Component.

 An encapsulated part of a software system.

 Serves as building blocks of the system and
has an interface.
 At programming level – modules, classes,
objects or related functions.
 Categorization of Components:
 Processing Elements
 Data Elements
 Connecting Elements.
 Connectors or Relationships

Denotes a connection between components.

 Could be Static or Dynamic.
 Static Relationships
- Placement of Components within architectural
model.
eg. - Aggregation and Inheritance
 Dynamic Relationships
– Temporal Connections and Interactions between
components.
eg. – Creation of Objects and Communication
between Objects.
 View

 A partial aspect of a software architecture that shows

specific properties of a software system.
Eg., - State View, Data Flow View.
 Soni, Nord, Hofmeister - Describes four views of SA
1. Conceptual Architecture 2. Module Architecture
3. Code Architecture 4. Execution Architecture.
 P.B. Kruchten’s 4 views of Software Architecture:
1. Logical View 2. Process View
3. Physical View 4. Development View
 Functional Property

 Deals with particular aspect of a system’s

functionality.
 Related to Specified Functional requirement.
 Seldom explicitly stated in SAs., and mostly assumed
implicitly.
 Stating explicitly with Functional Properties help in
traceability of an architectural element to its
functional requirements.
 Non-Functional Property

 Not covered by its functional description.

 Addresses aspects like reliability, compatibility,
maintainability, interoperability , changeability,
efficiency, testability and reusability of a software
system.
Concerns of Software Architecture and

ARCHITECTURE SOFTWARE
IMPLEMENTED
Interaction among parts Implementation of parts

Structural properties Computational properties

Declarative Operational

Mostly static Mostly dynamic

System level performance Algorithmic performance

Outside module boundary Inside module boundary

 Concerns of Stakeholder in Software Archi

Customer User
1.Consistency with req. and
1.Schedule and budget est. usage scenarios.
2.Feasibility and risk assessment. 2. Future req. growth accom
3.Requirements traceability. -modation.
4.Progress tracking 3. Performance, reliability,
interoperability.
SA
Architect Developer

1. Requirement traceability. 1.Sufficient detail for design.

2. Support of Trade-off-Analysis. 2.Reference for selecting and
3. Completeness. assembling components.
4. Consistency of Architecture 3.Maintain interoperability with
existing system.

Guidance on software modification, architecture evolution and interoperability

Maintainer
 Architectural Styles

a.What are Architectural Styles?

An architectural style
 defines a family of systems

 in terms of a pattern of structural organization

 provides a vocabulary of components and connector

types
 a set of constraints on how they can be combined

 A semantic model may also exist which specify how

to determine a system's overall properties from the

properties of its parts
 Architectural Styles

b. Various types of Architectural Styles

i. Pipes and Filters ( Data flow
Architectures).
ii. Data Abstraction and Object Oriented.
iii. Event Based and Implicit Invocation.
iv. Layered Systems.
v. Repositories.
vi. Interpreters.
vii. Process Control
 4.Heterogeneous Architectures

 The combination of several styles.

 Components of a hierarchical system may have an
internal structure developed using a different method.
 Connectors may also be decomposed into other systems
(e.g. pipes can be implemented internally as FIFO
queues).
 A single component may also use a mixture of
architectural connectors.
Example- Unix pipes-and-filter system
- File system acts as the repository,
- Receives control through initialization switches,
- Interacts with other components through pipes.
MAPPING REQUIREMENTS TO
ARCHITECTURAL DESIGN

1. DATA ARCHITECTING
2. MAPPING
 DATA ARCHITECTING

 Creates a model of data (data modeling) represented

at a higher level of abstraction
 Refined progressively more implementation-specific
representations
 In applications, architecture of data have profound
influence on the software architecture
 Data architecting at various level:
1. Program Component Level – DS and Algorithms
2. Application level – Database
3. Business level – Data Warehousing
 Component Level Data Architecting

 Focuses on representation of data structures that are

accessed by one or more software components
 Data architecting or design begins during the creation
of requirement analysis model
 Set of principles for data specification or model:
1. Systematic analysis principles should be applied to
data as in the cases of function and behavior
2. All Data Structures and operations to be performed
on each should be identified
3. A Data-Dictionary should be established and used to
define both data and program design
 Component Level
Data Architecting…

4. Low-level data design decisions should be

deferred until late in design
5. Representation of data structures be
known only to those modules that must
make direct use of the data
6. Library of useful data structures and
operations should be developed
7. A software design and programming
language should support the specification
and realization of abstract data types.
 Analyzing Alternative
Architectural Designs

1. ATAM
2. QUANTITATIVE TECHNIQUE
 ATAM

 ATAM – Architectural Trade-off Analysis Method

developed at SEI-CMU.
 An iterative evaluation process for software
architectures
 Design analysis activities are:
1. Collect Scenarios
2. Elicit requirements, constraints and
environmental description
3. Describe the Architectural Style/Patterns chosen
to address the Scenarios and Requirements
 ATAM

4. Evaluate quality attributes by considering

each attribute in isolation
5. Identify the sensitivity of quality attributes
to various architectural attributes for a specific
architectural style
6. Critique candidates architectures using the
sensitivity analysis conducted in step 5