Software architecture and

design
What is Software Architecture
 Definitions

• The software architecture of a program or

computing system is the structure or structures of
the system which comprise
– The software components
– The externally visible properties of those components
– The relationships among the components

3
Architecture defined
Formal Definition

• IEEE 1471-2000
– Software architecture is 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.
Architecture defined

• Software architecture encompasses the set of

significant decisions about the organization of a
software system
– Selection of the structural elements and their
interfaces by which a system is composed
– Behavior as specified in collaborations among those
elements
– Composition of these structural and behavioral
elements into larger subsystems
– Architectural style that guides this organization
Architecture defined

• Perry and Wolf, 1992

– A set of architectural (or design) elements that have a particular form

• Boehm et al., 1995

– A software system architecture comprises
• A collection of software and system components, connections, and
constraints
• A collection of system stakeholders' need statements
• A foundation which demonstrates that the components, connections, and
constraints define a system that, if implemented, would satisfy the collection of
system stakeholders' need statements
Architecture defined

• Architecture is not a single structure -- no single

structure is the architecture
When to think about
Architecture
Architecture is Early

• Architecture represents the set of earliest design

decisions
– Hardest to change
– Most critical to get right
• Architecture is the first design artifact where a
system’s quality attributes are addressed
Architecture Drives
Architecture Drives

• Architecture not only serves as the blueprint for

the system but also the project:
– Team structure
– Documentation organization
– Work breakdown structure
– Scheduling, planning, budgeting
– Unit testing, integration
• Architecture establishes the communication and
coordination mechanisms among components
Architecture vs. Design
Architecture vs. Design
Architecture: where non-functional decisions are cast, and
functional requirements are partitioned
Design: where functional requirements are accomplished

non-functional architecture
requirements

functional
requirements design

Important : this is a general guideline – sometimes the borders are blurred

System Quality Attribute

• Performance
• Availability Time To Market
• Usability Cost and Benefits
End User’s view Projected life Business
• Security
time Community
view
Targeted Market
Integration with
Maintainability
Legacy System
Portability Roll back
Reusability Developer’s view Schedule
Testability

A list of quality attributes exists in

ISO/IEC 9126-2001 Information Technology – Software Product Quality
Typical Descriptions of
Software Architectures
Typical Descriptions of
Software Architectures

– "Camelot is based on the client-server model and uses remote

procedure calls both locally and remotely to provide communication
among applications and servers." [Spector 87]
– "We have chosen a distributed, object-oriented approach to managing
information." [Linton 87]
– "The easiest way to make the canonical sequential compiler into a
concurrent compiler is to pipeline the execution of the compiler phases
over a number of processors." [Seshadri 88]
– "The ARC network [follows] the general network architecture specified by
the ISO in the Open Systems Interconnection Reference Model."
[Paulk 85]
Architectural Design Level of
Software
 Architectural Design Level of
Software
• Deals with the composition of software systems from
module-scale elements
– Gross decomposition of required function
• What patterns of organization are useful?
• Which organization fits the application best?
– Assignment of function to design elements
• What are the elements?
• How do the elements interact?
– Emergent system properties
• Scaling and performance: Capacities, balance, schedules
• Security
• ...
– Selection among design alternatives
• Which implementations of elements will work best?
Issues for architecture and
programs differ
Architectural Design Task

Issues for architecture and programs differ

Architecture Programs
interactions among parts implementations of parts
structural properties computational properties
declarative operational
mostly static mostly dynamic
system-level performance algorithmic performance
outside module boundary inside module boundary
composition of subsystems copy code or call libraries
Promised Benefits of
Architectural Modeling
Promised Benefits of
Architectural Modeling

• Clarify design intentions

– Intended architecture is often lost. It's mostly informal, it's hard to
communicate anyhow.
• Provide basis for analysis in design
– Engineering design entails performance prediction and design tuning.
Routine practice.
• Improve maintenance
– Over half of maintenance effort goes into figuring out just what's
there.
• Address the hard questions
– Even without formal methods, explicit architectural modelling can
uncover fuzzy requirements, thinking, and design approaches
Promised Benefits of
Architectural Modeling
update document (6%) review document (6%)
test & debug (28%)
define/analyze change
Requirements (18%)

Architecture

trace logic (23%)

Design implement change (19%)

Reduce maintenance
costs, directly and
Code/Integ
• Clarify intentions indirectly
• Make decisions and Test/Accept
implications explicit
• Permit system-level
analysis Maintenance
Architectural Design Reviews
Architectural Design Reviews

Prospectus Planning and

Architecture Phase

Requirements
Discovery
Review Architecture

High-Level
Design
Source:
Joe Maranzano
ATT Bell Labs Architecture Low-Level
Review Design
Architectural Structure:
Components, Connectors,
Systems
 Architectural Structure:
Components, Connectors, Systems

• Components
– computational elements
• Ports
– interface points for components
• Connectors
– interactions between components
• Roles
– interface points for connectors
• Systems
– graphs of component and connectors
Architectural Design Process
Architectural Design Process

• System structuring
– system decomposed into several subsystems
– subsystem communication is established
• Control modeling
– model of control relationships among system components
is established
• Modular decomposition
– identified subsystems decomposed into modules
Architectural Models
Architectural Models

• Static structural model

– shows major system components
• Dynamic process model
– shows process structure of the system
• Interface model
– defines subsystem interfaces
• Relationships model
– data flow or control flow diagrams
CASE Repository Model
Design Code
editor generator

Design Project Program

translator repository editor

Design Report
analyser generator
Call-Return Model
Main
program

Routine 1 Routine 2 Routine 3

Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

Real-Time System Control
Model

Sensor Actuator
processes processes

System
contr oller

Computation User Fault

processes interface handler
Selective Broadcasting Model

Sub-system Sub-system Sub-system Sub-system

1 2 3 4

Event and messa ge handler

Interrupt-Driven Control Model
Interrupts

Interrupt
vector

Handler Handler Handler Handler

1 2 3 4

Process Process Process Process

1 2 3 4
 Compiler Model

Symbol
table

Lexical Syntactic Semantic Code

analysis analysis analysis generation
OSI Reference Model
7 Application
Application Application

6 Presentation Presentation

5 Session Session

4 Transport Transport

3 Network Network Network

2 Data link Data link Data link

1 Physical Physical Physical

Communica tions medium

Distributed Systems
Distributed Systems

• Most large computer systems are implemented as

distributed systems
• Information is also distributed over several
computers rather than being confined to a single
machine
• Distributed software engineering has become very
important
Distributed Systems
Architectures
Distributed Systems
Architectures
• Client/Server
– offer distributed services which may be called by clients
– servers providing services are treated differently than
clients using the services
• Distributed Object
– no distinctions made between clients and servers
– any system object may provide and use services from any
other system object
Middleware
Middleware

• Software that manages and supports the different

components of a distributes system
• Sits in the middle of the system to broker service
requests among components
• Usually off-the-shelf products rather than custom
• Representative architectures
– CORBA (ORB)
– COM (Microsoft)
– JavaBeans (Sun)
Multiprocessor Architecture
Multiprocessor Architecture

• Simplest distributed system model

• System composed of multiple processes that may
execute on different processors
• Model used in many large real-time systems
• Distribution of processes to processors may be
preordered or may be under control of a dispatcher
Multiprocessor Traffic Control
System

Sensor Traffic flow Traffic light control

processor processor processor

Sensor Light
Display control
control process
process process

Traffic lights
Traffic flow sensors
and cameras Operator consoles
Client/Server Architectures
Client/Server Architectures

• Application is modeled as a set of services that are

provided by servers and a set of clients that use
these services
• Clients know the servers but the servers do not
need to know all the clients
• Clients and servers are logical processes (not
always physical machines)
• The mapping of processes to processors is not
always 1:1
Client/Server System

c2 c3 c4 c12
c11
Server process
c1
s1 s4

c10
c5
Client process
s2 s3 c9

c6 c8
c7
Representative Client/Server
Systems

• File servers
– client requests selected records from a file
– server transmits records to client over the network
• Database servers
– client sends SQL requests to server
– server processes the request
– server returns the results to the client over the network
Representative Client/Server
Systems

• Transaction servers
– client sends requests that invokes remote procedures on
the server side
– server executes procedures invoked and returns the
results to the client
• Groupware servers
– server provides set of applications that enable
communication among clients using text, images, bulletin
boards, video, etc.
Client/Server Software
Components
Client/Server Software
Components
• User interaction/presentation subsystem
• Application subsystem
– implements requirements defined by the application within
the context of the operating environment
– components may reside on either client or server side
• Database management subsystem
• Middleware
– all software components that exist on both the client and
the server to allow exchange of information
Thin Client Model
Thin Client Model

• Used when legacy systems are migrated to client

server architectures
– the legacy system may act as a server in its own right
– the GUI may be implemented on a client
• It chief disadvantage is that it places a heavy
processing load on both the server and the network
Fat Client Model
Fat Client Model

• More processing is delegated to the client as the

application processing is locally extended
• Suitable for new client/server systems when the
client system capabilities are known in advance
• More complex than thin client model with respect to
management issues
• New versions of each application need to installed
on every client
Three-tier Architecture
Three-tier Architecture

• Each application architecture layers (presentation,

application, database) may run on separate
processors
• Allows for better performance than a thin-client
approach
• Simpler to manage than fat client approach
• Highly scalable (as demands increase add more
servers)
Three-Tier Architecture

Client HTTP interaction

Web server Datab ase server

SQL query
Client Account service Customer
SQL account
provision
database

Client

Client
Design Issues for Client/Server
Systems
Design Issues for
Client/Server Systems
• Data and architectural design
– dominates the design process to be able to effectively
use the capabilities of RDBMS or OODMBS
• Event-driven paradigm
– when used, behavioral modeling should be conducted
– the control-oriented aspects of the behavioral model
should translated into the design model
Design Issues for
Client/Server Systems
• Interface design
– elevated in importance
– user interaction/presentation component implements all
functions associated with a GUI
• Object-oriented point of view
– often chosen, since object structure is provided by
events initiated in the GUI and their event handlers
within the client-based software
Distributed Object Architectures
Distributed Object
Architectures
• No distinctions made between client objects and
server objects
• Each distributable entity is an object that both
provides and consumes services
• Object communication is though an object request
broker (middleware or software bus)
• More complex to design than client/server systems
Distributed Object Architecture
from Sommerville
o1 o2 o3 o4

S (o1) S (o2) S (o3) S (o4)

Software bus

o5 o6

S (o5) S (o6)
Architectural Design Process
 Architectural Design Process

• Basic Steps
– Creation of the data design
– Derivation of one or more representations of the architectural
structure of the system
– Analysis of alternative architectural styles to choose the one best
suited to customer requirements and quality attributes
– Elaboration of the architecture based on the selected architectural
style
• A database designer creates the data architecture for a
system to represent the data components
• A system architect selects an appropriate architectural
style derived during system engineering and software
requirements analysis

69
Emphasis on Software
Components

• A software architecture enables a software engineer

to
– Analyze the effectiveness of the design in meeting its stated
requirements
– Consider architectural alternatives at a stage when making
design changes is still relatively easy
– Reduce the risks associated with the construction of the
software
• Focus is placed on the software component
– A program module
– An object-oriented class
– A database
– Middleware 70
Software Architectural Style

• The software that is built for computer-based systems exhibit

one of many architectural styles
• Each style describes a system category that encompasses
– A set of component types that perform a function required by the
system
– A set of connectors (subroutine call, remote procedure call, data
stream, socket) that enable communication, coordination, and
cooperation among components
– Semantic constraints that define how components can be integrated
to form the system
– A topological layout of the components indicating their runtime
interrelationships

71
A Taxonomy of Architectural Styles
Independent Components

Communicating Event Systems

Processes

Implicit Explicit
Client/Server Peer-to-Peer
Invocation Invocation

Data Flow Data-Centered

Batch Sequential Pipe and Repository Blackboard

Filter

Virtual Machine Call and Return

Main Program Object

and Subroutine Layered Oriented
Interpreter Rule-Based 72
System Remote Procedure Call
Data Flow Style

Validate Sort Update Report

73
Data Flow Style
• Batch sequential style
– The processing steps are independent components
– Each step runs to completion before the next step
begins
• Pipe-and-filter style
– Emphasizes the incremental transformation of data
by successive components
– The filters incrementally transform the data (entering
and exiting via streams)
– The filters use little contextual information and retain
no state between instantiations
– The pipes are stateless and simply exist to move
data between filters
74
Data Flow Style (continued)

• Use this style when it makes sense to view your

system as one that produces a well-defined easily
identified output
– The output should be a direct result of sequentially
transforming a well-defined easily identified input in a
time-independent fashion

75
Call-and-Return Style
Main module

Subroutine B
Subroutine A

Subroutine A-1 Subroutine A-2

Application layer Class V Class W

Transport layer

Network layer Class X Class Y

Data layer
Class Z
76
Physical layer
Call-and-Return Style

• Has the goal of modifiability and scalability

• Has been the dominant architecture since the start
of software development
• Main program and subroutine style
– Decomposes a program hierarchically into small pieces
(i.e., modules)
– Typically has a single thread of control that travels
through various components in the hierarchy

77
Remote procedure call style

– Consists of main program and subroutine style of system

that is decomposed into parts that are resident on
computers connected via a network
– Strives to increase performance by distributing the
computations and taking advantage of multiple
processors
– Incurs a finite communication time between subroutine
call and response
 Call-and-Return Style
• Object-oriented or abstract data type system
– Emphasizes the bundling of data and how to manipulate
and access data
– Keeps the internal data representation hidden and allows
access to the object only through provided operations
– Permits inheritance and polymorphism
• Use this style when the order of computation is
fixed, when interfaces are specific, and when
components can make no useful progress while
awaiting the results of request to other components

79
Call-and-Return Style
Layered system

– Assigns components to layers in order to control inter-

component interaction
– Only allows a layer to communicate with its immediate
neighbor
– Assigns core functionality such as hardware interfacing or
system kernel operations to the lowest layer
– Builds each successive layer on its predecessor, hiding
the lower layer and providing services for the upper layer
– Is compromised by layer bridging that skips one or more
layers to improve runtime performance
Data-Centered Style

Client A Client B Client C

Shared Data

Client D Client E Client F

81
Data-Centered Style (continued)

• Has the goal of integrating the data

• Refers to systems in which the access and update of a
widely accessed data store occur
• A client runs on an independent thread of control
• The shared data may be a passive repository or an active
blackboard
– A blackboard notifies subscriber clients when changes occur in data
of interest
• At its heart is a centralized data store that communicates
with a number of clients
• Clients are relatively independent of each other so they can
be added, removed, or changed in functionality
• The data store is independent of the clients 82
 Data-Centered Style

• Use this style when a central issue is the storage,

representation, management, and retrieval of a large
amount of related persistent data
• Note that this style becomes client/server if the clients are
modeled as independent processes

83
Virtual Machine Style

Program
Program Data
Instructions

Interpretation Program
Engine Internal State

84
Virtual Machine Style

• Has the goal of portability

• Software systems in this style simulate some functionality
that is not native to the hardware and/or software on which it
is implemented
– Can simulate and test hardware platforms that have not yet been built
– Can simulate "disaster modes" as in flight simulators or safety-critical
systems that would be too complex, costly, or dangerous to test with
the real system

85
Virtual Machine Style

• Examples include interpreters, rule-based systems, and

command language processors
• Interpreters
– Add flexibility through the ability to interrupt and query the program
and introduce modifications at runtime
– Incur a performance cost because of the additional computation
involved in execution
• Use this style when you have developed a program or some
form of computation but have no make of machine to
directly run it on
Independent Component Style
Client A Client B

Server

Client C Client D

Peer W Peer X

Peer Y Peer Z
87
Independent Component Style

• Consists of a number of independent processes that

communicate through messages
• Has the goal of modifiability by decoupling various
portions of the computation
• Sends data between processes but the processes
do not directly control each other

88
Independent Component Style

• Event systems style

– Individual components announce data that they wish to
share (publish) with their environment
– The other components may register an interest in this
class of data (subscribe)
– Makes use of a message component that manages
communication among the other components
– Components publish information by sending it to the
message manager
– When the data appears, the subscriber is invoked and
receives the data
– Decouples component implementation from knowing the
names and locations of other components
Independent Component Style

• Communicating processes style

– These are classic multi-processing systems
– Well-know subtypes are client/server and peer-to-peer
– The goal is to achieve scalability
– A server exists to provide data and/or services to one
or more clients
– The client originates a call to the server which services
the request

90
Independent Component Style

• Use this style when

– Your system has a graphical user interface
– Your system runs on a multiprocessor platform
– Your system can be structured as a set of loosely coupled
components
– Performance tuning by reallocating work among
processes is important
– Message passing is sufficient as an interaction
mechanism among components
Heterogeneous Styles

• Systems are seldom built from a single architectural

style
• Three kinds of heterogeneity
– Locationally heterogeneous
• The drawing of the architecture reveals different styles in different
areas (e.g., a branch of a call-and-return system may have a
shared repository)
– Hierarchically heterogeneous
• A component of one style, when decomposed, is structured
according to the rules of a different style
– Simultaneously heterogeneous
• Two or more architectural styles may both be appropriate 92
descriptions for the style used by a computer-based system
Types of Architecture
Types of Architecture

• Business Architecture
• Technical Architecture
• Solutions Architecture
• Enterprise Architecture
• Product Line Architecture
Business Architecture

• Concerned with the business model as it relates

to an automated solution.
– E-business is a good candidate
– Structural part of requirements analysis.
– Domain Specific
Technical Architecture

• Specific to technology and the use of this

technology to structure the technical points
(Technology Mapping) of an architecture
– .NET
– J2EE
– Hardware architects
Solutions Architecture

• Specific to a particular business area (or

project) but still reliant on being a technical focal
point for communications between the domain
architect, business interests and development.
Enterprise Architecture

• The organizing logic for a firm’s core business

processes and IT capabilities captured in a set
of principles, policies and technical choices
to achieve the business standardization and
integration requirements of the firm’s operating
model.
• Concerned with cross project/solution
architecture and communication between
different practices in architecture.
Product Line Architecture

• Common Architecture for a set of products or

systems developed by an organization
Product Line - Initiation

• Evolutionary
– Product line architecture and components evolve
with the requirements posed by new product line
members.
• Revolutionary
• Product line architecture and components developed to
match requirements of all expected product-line
members
Architectural Analysis in a
Nutshell

101

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
References and Bibliography

1. Software Engineering, Ian Sommerville, Pearson

Education, Inc., publishing as Addison-Wesley.
2. Software Engineering-A practitioner’s approach, Roger S
Pressman, Mcgraw-Hill
3. Software Engineering: Principles And Practice, Waman S
Jawadekar, Tata McGraw-Hill Education Pvt. Ltd.
4. NPTEL Course Website
Acknowledgement

• The content of this document is taken from

different papers, articles, books, blogs, forums,
industry reports and web sources.We would like to
thank all contributors for providing free access of
all these learning materials.