Software Architecture
SYED FEROZ ZAINVI
Writing from:
http://www.computer-science-notes.blogspot.com
Agenda
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
HOWEVER,
“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:
http://www.sei.cmu.edu/architecture/definitions.html
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
Systems]
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
Mechanisms
Multiple components to be simultaneously informed about an
event occurrence in application environment
MANY POSSIBILITIES
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
Mechanisms
Multiple components to be simultaneously informed about an
event occurrence in application environment
MANY POSSIBILITIES
Rescue: Architectural Patterns/Styles
Overview of Patterns
Essentially reusable architectural blueprints that describe the
structure and interaction between collections of participating
components.
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 &
stakeholders
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 &
dependencies
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
components
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
(ADL)
Architectures & Technologies
Architectural decisions to be made in early project
life-cycle
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
stages
Poor Choices Failed Projects
References
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
Publishing
Special Issue on Software Architecture, CSI
Communication, 2008
Notes from RMCS (UK)
Rational Suite – Online Help
More computer science
notes available at:
http://www.computer-science-notes.blogspot.com
Also linked through:
http://www.crossroadsbyzainvi.blogspot.com
