You are on page 1of 23

Software Architecture


Writing from:

Software Architecture – Warm Up

Software Architecture
 Definition
 Elaboration
Architectural Styles/Patterns – Overview
Architecture & Technologies
Before We Start …

The last decade has seen a tremendous rise in this

prominence of a software engineering sub-discipline
called Software Architecture
“Architecture” is one of the most overused and least
understood terms in professional software
development circles.
Regularly misused in project reviews and
discussions, academic paper presentations at
conferences and product pitches.
Software Architecture - Definitions

Easy to understand but no widely accepted definition

Trying to define a term such as software architecture is always a
potentially dangerous activity
Difficult to draw a sharp line between design and architecture
 Architecture is one aspect of design that concentrates on some specific features
 Software architecture is a level of design concerned with issues
To understand the diversity in views, have a browse through the
list maintained by the Software Engineering Institute at:
Software Architecture – IEEE Definition

“Architecture is defined by the recommended practice as

the fundamental organization of a system, embodied in
its components, their relationships to each other and the
environment, and the principles governing its design
and evolution.”

[ANSI/IEEE Std 1471-2000, Recommended Practice for

Architectural Description of Software-Intensive
Software Architecture – Kazman 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.”

[L.Bass, P.Clements, R.Kazman, Software Architecture in

Practice (2nd edition), Addison-Wesley 2003]
Software Architecture – RUP Version

Architecture of a software system (at a given point) is

the organization or structure of the system's
significant components interacting through
interfaces, with components composed of
successively smaller components and interfaces
Software Architecture – Shaw & Garlan Definition

“[Software architecture goes] beyond the algorithms and data

structures of the computation; designing and specifying the
overall system structure emerges as a new kind of problem.
Structural issues include gross organization and global control
structure; protocols for communication, synchronization, and
data access; assignment of functionality to design elements;
physical distribution; composition of design elements; scaling
and performance; and selection among design alternatives.”

[D. Garlan, M. Shaw, An Introduction to Software Architecture,

Advances in Software Engineering and Knowledge Engineering,
Volume I, World Scientific, 1993]
Architecture Defines Structure

Issue is how to sensibly partition an application into a set

of inter-related components
An architecture must be designed to meet the specific
requirements and constraints of the application it is
intended for
A key structural concern for nearly all applications is
minimizing dependencies between components, creating
a loosely coupled architecture from a set of highly
cohesive components.
Responsibility Driven Design is a technique
Architecture Specifies Component Communication

Issue: How divided components communicate data

and control information
Some examples:
 Within same address space: Method Calls
 If in different threads or processes: Synchronization
 Multiple components to be simultaneously informed about an
event occurrence in application environment
Rescue: Architectural Patterns/Styles
Architecture Specifies Component Communication

Issue: How divided components communicate data

and control information
Some examples:
 Within same address space: Method Calls
 If in different threads or processes: Synchronization
 Multiple components to be simultaneously informed about an
event occurrence in application environment
Rescue: Architectural Patterns/Styles
Overview of Patterns

Essentially reusable architectural blueprints that describe the

structure and interaction between collections of participating
Has well-known characteristics that make it appropriate to use
to satisfy particular types of requirements.
Patterns are quite useful, and convey design information.
Proven to work. If used appropriately in an architecture, you
leverage existing design knowledge by using patterns.
Large systems tend to use multiple patterns, combined in ways
that satisfy the architecture requirements.
Architecture Addresses Non-Functional Requirements

Three distinct areas of non-functional requirements:

Technical constraints:
 Design constraints by specifying certain technologies
 Usually non-negotiable.
Business constraints:
 Design constraints due to business, not technical reasons.

Quality attributes:
 Requirements in terms of scalability, availability, ease of change,
portability, usability, performance,
 Address issues of concern to application users & stakeholders
Architecture Is An Abstraction

Marketecture: 1 pg informal depiction of system

structure & interactions
In easy to understand way for team members &
Unnecessary details are suppressed or ignored
Focus is on salient architectural issues
Components as black boxes; specifying only externally
visible properties
Hierarchal decomposition is one such mechanism
Architecture partitions team responsibilities &
Describing An Architecture Hierarchicallly
Architecture Views

Software Architecture is a complex design artifact

There are number of ways of looking at and
understanding an architecture
Philip Krutchen’s 4+1 View Model (IEEE, 1995)
 Logical View: Architecturally significant elements
 Process View: Concurreny & Communication elements
 Physical View: Mapping of processes/components on to
application’s hardware
 Development View: Internal organization of software
Krutchen's 4+1 … Contd…

Views are tied together by the architecturally

significant use cases (UC often called scenarios)
UC basically capture the requirements for the
architecture, and hence are related to more than one
particular view
By working through the steps in a particular use
case, the architecture can be “tested”, by explaining
how the design elements in the architecture respond
to the behavior required in the use case.
SEI's Views & Beyond

Recommends capturing architecture model using 3

different views:
Module: Structural View – code modules, decomposition,
inheritance, association, aggregation
Components & Connectors: Behavioral Aspects
- Components: Objects, Threads, Processe
- Connectors: Shared Memory, Sockets, Middleware
Allocation: Process mapping to hardware,
communication using network/database, source code
view in configuration management, dev. responsibility
Uses terminology of Architecture Description Language
Architectures & Technologies

Architectural decisions to be made in early project

Difficult to validate & test until system is built
Judicious prototyping of key components can help
Still sometimes hard to ascertain success of
particular design choice in given application context
Risks can be reduced by using tried & tested
approaches for solving certain classes of problems
 Architectural Patterns
Patterns - Revisited

Patterns are an abstract representation of an architecture, in the

sense that they can be realized in multiple concrete forms.
Abstract architectures must be reified by software engineers as
concrete software implementations.
Software products vendors have come to the rescue. Widely
utilized architectural patterns are supported in a variety of
commercial offthe-shelf (COTS) technologies
Architectural Patterns & Concrete Technologies
 Software technologies provide reusable,
application-independent software
infrastructures that implement proven
architectural approaches
 Competing commercial and open source
products exist (BLESSING)
 Superficially similar
 Differs in features, implementations,
constraints, cost
 Selecting a product that has quality
attributes that satisfy the application
requirements is difficult (CURSE)
 No one-size-fits-all product available
 Identifying strengths & weaknesses of
a particular choice is difficult in early
 Poor Choices  Failed Projects

Ian Gorton, Essential Software Architecture, Springer

Shaw & Garlan, Software Architecture – Perspectives On
An Emerging Discipline, PHI
R. Pressman, Software Engineering – A Practitioner’s
Approach, McGraw Hill
Pankaj Jalote, Integrated Software Engineering, Narosa
Special Issue on Software Architecture, CSI
Communication, 2008
Notes from RMCS (UK)
Rational Suite – Online Help
More computer science
notes available at:

Also linked through: