Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
We l co m e & I n t ro d u ct io n

• About the Instructor

– Kallol Pal
– Contact No: 98451 73500
– E-Mail:
• [email protected]
• [email protected]
Wh a t t o E xp e c t Fr o m t h e C o u rs e?

What are your expectations from the course?

• Understanding of software architecture

• Impact of architecture on software design
• Architectural Styles
• Evaluation of Architectures
• A structured way to define an architecture
• Architectural Best Practices
• Technology Awareness
• Examples & Case Studies
O u t li n e o f t h e C o u r se
• Understanding of Software Architecture
• Importance of Software Architecture
• Quality Attributes
• Techniques to achieve quality attributes
• Attribute driven design
• Agile and Architecture
• Architecture Documentation
• Architecture Patterns
• Cloud Architectures
• Mobile Architectures
• Micro Services
• Architecture and Emerging Technologies
• Testing & Analysis of Architecture
• Case Studies
C o u rse w ar e

• Course Handout
– Plan of Self Study

• Text Books
– Software Architecture in Practice; Bass, Len & Others
– Essential Software Architecture; Ian Gorton
E v a lu a t io n S c h e m e

No Name Type Duration Weight

EC-1 Quiz – I Online 5%

Quiz – II Online 5%

Assignment Online 20%

EC-2 Mid Semester Exam Closed Book 2 Hours 30%

EC-3 Comprehensive Exam Open Book 2.5 Hours 40%

 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Introduction to Software Architecture)
Wh a t is So f t w a re A r ch it e c tu r e?

The software architecture of a program or computing system is the

• structure or structures of the software system, which comprises software elements,

• the externally visible properties of those elements,
• and the relationships among them.

Do requirement specifications of a system lead to architecture?

S O F T W ARE ARCHI TE CT URE S 8 BITS-Pilani

T h e A r ch it e c t u re B u sin e ss C ycl e

• A software architecture is a result of

– Technical
– Business
– Social influences

• The existence of a software architecture in turn influences the Technical, Business & Social
environments which influences future architecture

• This cycle is called the Architecture Business Cycle (ABC)

S O F T W ARE ARCHI TE CT URE S 9 BITS-Pilani

T h e A r ch it e c t u re B u sin e ss C ycl e

S O F T W ARE ARCHI TE CT URE S 10 BITS-Pilani

I n f lu e n ce s o n a n A rc h it e ct u re

• System Stakeholders
– Not all the desired properties of the final system are captured in the requirements
– Goals of stakeholders may be contradictory
• Developing Organization
– Immediate Business
– Long Term Business
– Organization Structure
• The ARCHITECT
• The Technical Environment

S O F T W ARE ARCHI TE CT URE S 11 BITS-Pilani

S t a ke h o lde r s

S O F T W ARE ARCHI TE CT URE S 12 BITS-Pilani

R o le o f a n A r c h it e ct

• Identify and actively engage the stakeholders to solicit their needs and expectations
• Manage expectations and resolve conflicts
• Fill in the gaps
• Articulate decisions

S O F T W ARE ARCHI TE CT URE S 13 BITS-Pilani

I m p a ct s o f Ar c h i t e ct ur e Bu s in e ss Cyc l e

• Structure of the developing organization

• Goals of the developing organization
• Customer Requirements
• Experience Base
• Software Engineering Culture

A business can manage the ABC to handle growth, to expand its enterprise area and to
take advantage of previous investments in architecture and system building.

S O F T W ARE ARCHI TE CT URE S 14 BITS-Pilani

S o f tw a r e Pr o c e s s & A BC

• Creating the business case for the system

• Understanding the requirements
– Relationships to prior systems
– Prototypes
– Quality Attributes
• Creating & Selecting the architecture
– Behavioural & Quality Requirements
• Communicating the Architecture
– Documenting the Architecture
• Analysing or Evaluating the Architecture
– Choosing between competing options
• Implementing Based on the Architecture
• Ensuring Conformance to an Architecture

S O F T W ARE ARCHI TE CT URE S 15 BITS-Pilani

A t tr i b u t es o f a g o o d A rch i t e ct ur e

There is no such thing as an inherently good or bad architecture. Architectures are either more or
less fit for some stated purpose.

• Process Recommendations
– Number of architects
– Functional requirements & prioritized list of quality attributes
– Documentation
– Review with stakeholders
– Evaluated
– Incremental Implementation through a skeletal system
– Clearly defined constraints

S O F T W ARE ARCHI TE CT URE S 16 BITS-Pilani

A t tr i b u t es o f a g o o d A rch i t e ct ur e

• Structural Recommendations
– Well Defined Modules based on Information Hiding and Separation of Concerns
– Components should have well defined interface
– Achieve quality attributes using well known architectural tactics
– No dependence on particular version of a product or tool
– Producers of data separated from consumers of data
– Incremental Implementation through a skeletal system
– Small number of interaction patterns

S O F T W ARE ARCHI TE CT URE S 17 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
I s t h is a so f t wa r e A rc h it e ct u re ?

Control
Process
(CP)

Prop
Reverb Noise
Loss
Model Model
Model
(MODR) (MODN)
(MODP)

System for under water acoustic simulation

S O F T W ARE A RCHI T E CT URE S 2 BITS-Pilani
M a n y t h in g s u n a n s we red

• What is the significance of the elements?

• What are the responsibilities of the elements?

• What is the significance of the connections?

• What is the significance of the layout?

S O F T W ARE A RCHI T E CT URE S 3 BITS-Pilani

S o f tw a r e Ar c h i t e ct ur e

The software architecture of computing system is the set of structures needed to reason about the
system, which comprises software elements, the relations among them, and the externally visible
properties of both.

• Structures could be implementation units, dynamic representation, Mapping to systems

• Defines software elements and their interactions as an abstraction
• Comprises of more than one structure
• Every software system has a software architecture
• Behaviour of each element is part of the architecture
• Does not consider a good or bad architecture

Many definitions exist – Structure, Elements and Connections is a common theme

S O F T W ARE A RCHI T E CT URE S 4 BITS-Pilani

S y st e m & E n t e rp r ise A r ch it e ct u re

• Have broader concerns than software architecture but influence software architecture

• System architecture
– Mapping of functionality into hardware & software components
– Mapping of software architecture to hardware architecture
– Human interactions with both

• Enterprise Architecture
– Description of the structure and behaviour of an organization’s processes, information flow, personnel, organizational
units aligned with the organization’s core goals and strategic directions.
– Need not include information systems, but invariably describe how an enterprises software systems support the
business processes
– Component Business Model (CBM), Enterprise Process Framework (EPF), Enterprise Data Model (EDM)s

S O F T W ARE A RCHI T E CT URE S 5 BITS-Pilani

A rc h it e ct u ra l S t r u ct u re s

• Module Structures
– Embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed
or procured
– A static view where modules are assigned areas of functional responsibility
– Decomposition (Module – Sub Module) Structure, Use Case Structure, Layer Structure, Class Structure (inherits),
Data Model

• Component & Connecter Structures

– Embody decisions as to how the system is to be structured as a set of elements that have runtime behaviour
(components) and interactions (connectors)
– A dynamic view that captures a systems runtime behaviour
– Service Structure, Concurrency Structure

• Allocation Structures
– Embody decisions as to how the system will relate to non-software structures in its environment.
– Usually Domain Centric
– Deployment Structure, Implementation Structure (file system), Work Assignment Structure,

S O F T W ARE A RCHI T E CT URE S 6 BITS-Pilani

I n t e rm e d iat e S t a g e s

• Architectural Patterns (Architectural Style)

– An architectural pattern is a description of element and relation types together with a set of
constraints on how they may be used
– Client Server, MVC
– Exhibit known quality attributes

• Reference Model
– A reference model is a division of functionality together with data flow between the pieces.
– Standard decomposition of a known problem into parts that cooperatively solve the problem
– Represent a mature domain – eTOM & TOGAF reference model for telecom

• Reference Architecture
– A reference architecture is a reference model mapped onto software elements and the data flows
between them
– Usually Domain Centric

S O F T W ARE A RCHI T E CT URE S 7 BITS-Pilani

I n t e rm e d iat e S t a g e s

Reference
Model
Reference Software
Architecture Architecture
Architectural Pattern

S O F T W ARE A RCHI T E CT URE S 8 BITS-Pilani

I n t e rm e d iat e S t a g e s

S O F T W ARE A RCHI T E CT URE S 9 BITS-Pilani

 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Software Quality Attributes)

S O F T W ARE A RCHI T E CT URE S 10 BITS-Pilani

S o f tw a r e Qu a li ty A t tr i b u t e s

• Quality Attributes are part of a software’s non functional requirements

– Focus on how the applications functional requirements are achieved
– May be implicit expectations from the system and may not be always explicitly stated
– May have to be determined by asking the right questions

• They must be quantifiable (specific) to be implementable

– Bad Examples: “Application must run fast”; “Application must be scalable”
– The application should have a maximum response time of 600ms for all update
transactions from the UI (Network Latency not included)

S O F T W ARE A RCHI T E CT URE S 11 BITS-Pilani

C o mm o n Q u a li t y A t t ri b u t es

• Performance
• Scalability
• Security
• Availability
• Usability
• Interoperability
• Testability
• Modifiability
• Integration

S O F T W ARE A RCHI T E CT URE S 12 BITS-Pilani

P e rf o r m an c e

• Gets the maximum attention of all the quality attributes

– No one likes waiting for a system to respond
– Machines must produce results instantly!

• Performance Measures
– Throughput: It is a measure of the amount of work an application must perform in unit
time. (Transactions per Second / Messages Processed per Second)
• Average vs. Peak – When to use what?
– Response Time: This is a measure of the latency an application exhibits in processing
a business transaction.
• Guaranteed, Average, Upper Limit
– Deadlines: Total amount of time allowed to complete a quantified task
• 8 hrs to upload the credit card data of 5 Million users

S O F T W ARE A RCHI T E CT URE S 13 BITS-Pilani

S c a la b i lit y

• “How well a solution to some problem will work when the size of the problem
increases.”

• Examples of “Size of Problem”

– Request Load
• Ideally the growth in response time should be linear – Throughput (tps) remains constant
• Handled with Scale Up (vertical) or Scale Out (Horizontal / Load Balancing)
– Simultaneous Connections
• Increasing user load
– Data Size
• Data Processing increases in size
– Deployment
• Growing User Base – Dynamic Deployment and Configuration

S O F T W ARE A RCHI T E CT URE S 14 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Software Quality Attributes)

S O F T W ARE A RCHI T E CT URE S 2 BITS-Pilani

S e c u r it y

• Authentication: Applications can verify the identity of their users and other applications with which
they communicate.

• Authorization: Authenticated users and applications have defined access rights to the resources of
the system. For example, some users may have read-only access to the application’s data, while
others have read-write.

• Encryption: The messages sent to/from the application are encrypted.

• Integrity: This ensures the contents of a message are not altered in transit.

• Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the
sender’s identity. This means neither can subsequently refute their participation in the message
exchange.
S O F T W ARE A RCHI T E CT URE S 3 BITS-Pilani
A v a il a b ili ty

• Availability is related to an application’s reliability.

– It is relatively easy to specify and measure
– Percentage of time it is required to be usable

• Approaches to ensure High Availability

– Redundancy and Duplication
– Elimination of single points of failure
– Automatic Failure Detection and restart

• Challenges
– Managing Maintenance downtimes
– Cost of building high available systems

• Most internet based applications require a 100% availability

S O F T W ARE A RCHI T E CT URE S 4 BITS-Pilani
U s a b il it y

• Usability is concerned with how easy it is for the user to accomplish a desired task and
the kind of user support the system provides

• Comprises of the following areas

– Learning system features
– Using a system efficiently
– Minimizing the impact of errors
– Adapting the system to user needs
– Increasing confidence and satisfaction

• Keep the user interaction modules / sub-system separate

• Use prototypes to get user feedback early

S O F T W ARE A RCHI T E CT URE S 5 BITS-Pilani
I n t e ro p e ra bi lit y

• Degree to which two or more systems can usefully exchange meaningful information via
interfaces in a particular context.

• Includes both syntactic and semantic interoperability

• There are various strategies in use

– API, FTP, Messages, Web Services, Object Brokers, etc.

• SOAP (Simple Object Access Protocol) vs. REST (Representation State Transfer) for Web
Applications
– SOAP offers Completeness
– REST offers Simplicity

S O F T W ARE A RCHI T E CT URE S 6 BITS-Pilani

T e s ta b i lit y

• Determines how easy or difficult is an application to test

– Minimize design complications, simple designs are easy to test
– Reuse tested components
– Modular and decoupled design
– Think Test Automation
– Requirements must be quantitative and verifiable

• Not quantifiable
– Objective is to minimize test effort

S O F T W ARE A RCHI T E CT URE S 7 BITS-Pilani

M o d if i ab ili ty
• The modifiability quality attribute is a measure of how easy it may be to change an
application to cater for new functional and non-functional requirements.
• The more flexibility that can be built into a design upfront to handle likely changes in
the application as it evolves, the less expensive and painful these changes will be.
• Examples
– Incorporate a new functional features
– Port the application to a new platform
– Replace a COTS package with another one
• Not easy to quantify this attribute
– Can be given as an estimate required to do a change
• Some Techniques
– Configurable Parameters
– Loose Coupling
– Abstract Components
S O F T W ARE A RCHI T E CT URE S 8 BITS-Pilani
I n t e g ra t io n

• Integration is concerned with the ease with which an application can be

usefully incorporated into a broader application context.

• Strategies
– APIs
– Data Integration (XML / CSV Import / Export)
– Web Services

How does it differ from Interoperability?

S O F T W ARE A RCHI T E CT URE S 9 BITS-Pilani

A F e w O t h e r Q u a li t y A t t ri b u t es

• Portability
– A measure of how easily a software system may be run on different platforms (operating
systems, software stacks) without changing the code of the software system
• Supportability
– A Measure of how easy it is to provide support for a software system
• Recoverability
– A Measure of how easily a software system that has suffered an outage may be recovered
• Maturity
– A measure of use of mature technologies, tools, etc.
• Compliance to Standards
– A measure of how complaint a software system is to specified standards

S O F T W ARE A RCHI T E CT URE S 10 BITS-Pilani

T r a d e Of f s – A Ba l a n ci ng A ct

• Quality attributes can be in conflict

– High Availability vs. Performance
– High Performance vs. Portability

• Managing Conflicts
– Prioritize the quality attributes
– Build a best-fit architecture
– Sensitize Stakeholders
– Document all the design decisions

S O F T W ARE A RCHI T E CT URE S 11 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Capturing Architecturally Significant Requirements)
S o f tw a r e Ar c h i t e ct ur e P ro ce s s

• Determine Architecture Requirements Determine

Architecture
– This involves creating a statement or model Requirements
of the requirements that will drive the
architecture design
• Architecture Design
– This involves defining the structure and
responsibilities of the components that will
comprise the architecture.
• Validation
Architecture
– This involves “testing” the architecture, Validation
Design
typically by walking through the design,
against existing requirements and any
known or possible future requirements.

S O F T W ARE A RCHI T E CT URE S 3 BITS-Pilani

D e te r m ine A rc h i t e ctu r e Re q u i rem e nt s

• Also known a Architecturally significant requirements, Quality Requirements, Non Functional Requirements
• Inputs
– Functional Requirements
– Stakeholder requirements (expectations)
– Implicit expectations
• Output
– Architecture Requirements Document
• Some architecture requirements are actually ‘constraints’
– They are non-negotiable
• Examples of Requirements
– The system must run 24x7x365, with overall availability of 0.99. (Availability)
– The application must be able to handle a peak load of 500 concurrent users during the enrollment period.
• Examples of Constraints
– The software application must be available to coincide with the launch of the new product line
– The existing MySql database infrastructure should be used

S O F T W ARE A RCHI T E CT URE S 4 BITS-Pilani

A rc h it e ct u re Re q u i re me n t s - Th e I n p u t s

• Requirements Documents
– Most of the requirements do not impact the architecture
– Most of what is required for an architecture may not even be present in the requirements

• Interviewing Stakeholders
– The Quality Attribute Workshop (QAW)

• Understanding Business Goals

– Provide a quality attribute that impacts the architecture, Ex. Security and User Volume
– Directly impacts the architecture, Ex. Need to utilize certain type of skills available in the organization
– Have no impact on the architecture, Ex. Reduce Cost of Operations
– They can be categorized which further helps in understanding

S O F T W ARE A RCHI T E CT URE S 5 BITS-Pilani

A rc h it e ct u re Re q u i re me n t s - P ri o r it iz e

• Rank the architecture requirements

– High: Requirements that drive the architecture design
– Medium: Requirement can be deferred to a later release
– Low: Do not impact the design and are ‘good to have’ (wish list) features

• Resolve Conflicts
– Architects say ‘no’ in the larger interest of the success of the project

• Get Sign off from project stake-holders

S O F T W ARE A RCHI T E CT URE S 6 BITS-Pilani

Q u a li t y A t t r ib u t e Wo r ksh o p ( Q A W)

• QAW is a facilitated, stake-holder-focused method to generate, prioritize and refine

quality attribute scenarios before the software architecture is completed.
• The QAW is focused on system level concerns and specifically the role that software will
play in the system
• It is keenly dependent on the participation of system stakeholders

S O F T W ARE A RCHI T E CT URE S 7 BITS-Pilani

S t e p s in QA W

• QAW Presentation and Introductions – Motivation for QAW and Explanation of the Process,
introductions of participants
• Business / Mission Presentation – System’s business context, broad functional requirements,
constraints, and known quality attribute requirements
• Architectural Plan Presentation – System architectural plans as they stand on that day, system
description, context drawings, etc.
• Identification of Architectural Drivers – Key architectural drivers derived from the above two steps –
Arrive at list of drivers
• Scenario Brainstorming – Each stakeholder expresses a scenario representing his or her concern
with respect to the system – Scenario must have stimulus and response
• Scenario Consolidation – Similar scenarios are consolidated
• Scenario Prioritization – It is accomplished by voting by the stakeholders – 30% of total scenarios
• Scenario Refinement – After prioritization the top scenarios are refined and elaborated

S O F T W ARE A RCHI T E CT URE S 8 BITS-Pilani

S ig n i f ica nc e o f B u sin e s s Go a ls

• Business Goals are the reason why a system exists

• Business Goals are of interest to Architects as the overall success of a system

depends on the achievement of the business goals set for the system
– Business Goals Often lead to quality attributes of a system
– Business goals may directly affect the architecture without precipitating a quality attribute
– No Influence at all on the quality attributes of the system

S O F T W ARE A RCHI T E CT URE S 9 BITS-Pilani

C a p tu r in g AS R s in a Ut i li t y T re e

• ASRs must have the following characteristics

– A profound impact on the architecture
– A high business or mission value
• Architects can use a construct called a Utility Tree to capture ASRs
– An Utility Tree begins with the word Utility as the root node – representing the goodness of the system
– Elaborate the root node by listing the major quality attributes that is system is required to exhibit
– Under each quality attribute record specific “refinement” of the Quality Attribute
– Finally under each refinement record the appropriate quality attribute
• Once the ASRs are recorded and placed in the tree, evaluate them as High, Medium,
Low against the two characteristics above

S O F T W ARE A RCHI T E CT URE S 10 BITS-Pilani

U ti li t y T re e E x a m p le

Quality Attribute Attribute Refinement ASR

Availability No Downtime The database vendor releases new software, which is

hot-swapped into place, with no downtime (H,L)
The system supports 24/7 web-based account access
by patients (L,L)
Security Confidentiality A physical therapist is allowed to see the part of a
patient’s record dealing with the orthopedic treatment
but not other parts nor any financial information (H,M)

Integrity The system resists unauthorized intrusion and reports

the intrusion attempt to the authorities within 90
seconds (H,M)

S O F T W ARE A RCHI T E CT URE S 11 BITS-Pilani

Architecture Requirements – Prioritize - Exercise
Read the following high level description of a system and identify the potential quality attributes to be
considered while architecting the system. Prioritize the identified quality attributes and state reasons
for the prioritization.
Mobile robotics systems are responsible for controlling manned vehicles such as a car, a submarine, or a
space vehicle. These systems must deal with external inputs and they must respond in real time. In particular,
the software functions of a mobile robot typically include acquiring inputs provided by its sensors, controlling
the motion of its wheels and other moveable parts and planning its future path. Several factors complicate the
task: obstacles may block the robot’s path; the sensor’s inputs may be imperfect; unpredictable events may
demand rapid responses; etc. In particular, the architecture of the solution must address the following.
a) Must account for dangers as human life is involved. It must be fault tolerant and never down.
b) Should accommodate experimentation, reconfiguration and frequent changes.
c) The overall system should be such that it can be accessed and used in an intuitive manner by its
human operators.
d) System must be always responsive.
e) It should be possible to run the application on various types of embedded operating systems with
minimal effort.
f) The effort spent on testing the frequent changes due to experimentation should be minimal and
preferably automated.
S O F T W ARE A RCHI T E CT URE S 12 BITS-Pilani
Example – AS R Trade-offs
• Web Conferencing System - Requirements

– Wide variety of hardware and software platforms

– High Security even on unknown network topologies

– Responsive and real time

– Easily modifiable and ability to integrate with other systems

– Usable and easily installed

– Time to Market & Cost (Competition)

S O F T W ARE A RCHI T E CT URE S 13 BITS-Pilani

E xa m p l e : A SR Tr a d e -o ff s

• High Security vs. Latency (Performance)

• Modifiability vs. Schedule

• Availability vs. Cost

• Performance vs. Modifiability

AND

• Completeness vs. Time to Market

S O F T W ARE A RCHI T E CT URE S 14 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Architecture Design)

S O F T W ARE A RCHI T E CT URE S 2 BITS-Pilani

S o f tw a r e Ar c h i t e ct ur e P ro ce s s

• Determine Architecture Requirements Determine

Architecture
– This involves creating a statement or model Requirements
of the requirements that will drive the
architecture design
• Architecture Design
– This involves defining the structure and
responsibilities of the components that will
comprise the architecture.
• Validation
Architecture
– This involves “testing” the architecture, Validation
Design
typically by walking through the design,
against existing requirements and any
known or possible future requirements.

S O F T W ARE A RCHI T E CT URE S 3 BITS-Pilani

A rc h it e ct u re De s i g n S t r a t e g ies

• Decomposition
– Start with the system as a whole and decompose it to smaller units
– As you decompose the system, decompose the quality attributes also
• Designing to ASRs
– Architecture must satisfy the ASRs
– Non ASRs?
• Generate & Test

Generate Generate
Test
Initial Next
Hypothesis
Hypothesis Hypothesis

Existing Systems, Design satisfies ARS,

Frameworks, Schedule Completion,
Patterns …… Budget
S O F T W ARE A RCHI T E CT URE S 4 BITS-Pilani
A rc h it e ct u re De s i g n

• The most difficult task performed by

an architect

• Input
– Architecture Requirements

• Output
– Architecture Views
– Architecture Documents

S O F T W ARE A RCHI T E CT URE S 5 BITS-Pilani

D e sig n - Ch o o s ing A rc h it e ct u re F ra m e wo rk

• First step is to define an architecture framework

– Apply architecture patterns
– Understanding of the main architecture patterns and how they address certain quality
attributes is important

• Few common architecture patterns (illustration purposes Only, will be covered

in detail later)
– N-Tier Client Server
– Messaging
– Publish-Subscribe
– Broker
– Process Coordinator
– Peer-to-Peer
S O F T W ARE A RCHI T E CT URE S 6 BITS-Pilani
D e sig n - Al l o c a t e Co m p o ne nt s

• Identify major application components and how they plug into the framework

• Identify the interface or services that each component supports

• Identify the responsibilities of the components

• Identify the dependencies between components

• Identify partitions in the architecture that are candidates for distribution over
servers in the network

S O F T W ARE A RCHI T E CT URE S 7 BITS-Pilani

D e sig n - G u id e li ne s f o r Co m p o n en t D e s ig n

• Minimize dependencies between components – Loose Coupling

• Each component should have a highly ‘cohesive’ set of responsibilities

• Isolate dependencies on middleware and COTS – May cost more to build

• Decompose to structure components in an hierarchy

• Minimize calls between components – Coarse vs. Fine Grained interfaces

S O F T W ARE A RCHI T E CT URE S 8 BITS-Pilani

D e sig n - Co m p o n en t De s ig n - E xa mp l e

• Order Input System

– New orders must be saved into a database
– Orders must be validated against an existing customer details system for payment options
– Once validated an email is sent to the customer confirming the order

S O F T W ARE A RCHI T E CT URE S 9 BITS-Pilani

 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Agile Software Development & Architecture)

S O F T W ARE A RCHI T E CT URE S 10 BITS-Pilani

Wh a t is a g il e s o f t wa r e d e ve l op me n t?

• It is an iterative software development methodology

– More responsive to project stakeholders
– Deliver functionality is iterations
– Show progress early in a project life cycle
– Less burdened by documentation

• Came into focus with the Agile Manifesto about 21 years ago (2001)
– Consist of 12 principles that underlie the core of Agile.
– Continue to be used for small to medium size projects with short time frames with great success
– Good with co-located teams

• No Conflict between Agile and use of Architecture

– The issue is not Agile vs. Architecture BUT how best to blend agile and architecture

S O F T W ARE A RCHI T E CT URE S 11 BITS-Pilani

T h e A g i le P r in c ip le s

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
• Welcome change in requirements even late in development
• Deliver working software frequently, from couple of weeks to a couple of months, with preference to the shorter
timescale
• Business People and Developers must work together daily throughout the project
• Build projects around motivated individuals
• The most efficient and effective method of conveying information to and within a development team is face-to-
face conversation
• Working software is the primary measure of progress
• Agile processes promote sustainable developments
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity is essential
• The best architectures, requirements and designs emerge from self-organizing teams.
• At regular intervals the team reflects on how to become more effective and the tunes and adjusts its behaviour
accordingly
S O F T W ARE A RCHI T E CT URE S 12 BITS-Pilani
U p fr o n t Wo r k v s . A g il it y

S O F T W ARE A RCHI T E CT URE S 13 BITS-Pilani

A rc h it e ct u re Me t h o d s f o r A g i li t y

• Highest Likely Friction in Architecture Evaluation and Architecture Documentation

• Principles for architecture documentation

– Write for the reader – No audience => No Document
– YAGNI : You ain’t gonna need it – Only document something when you actually have the need for it
– Views & Beyond : Use Architectural View as the unit of documentation to produce

• Architecture Evaluation
– Helps meet the stakeholders important concerns – An agile priority
– Select the most important quality attributes to evaluate
– Light weight evaluation

S O F T W ARE A RCHI T E CT URE S 14 BITS-Pilani

A g il e A p p r o a ch

• Addressing Complexity of the domain

– Top Down : Meet the demanding quality attributes
– Bottom Up : Address implementation specific and environment specific issues

• Balancing and Analyzing Tradeoffs

– Experiments (Spikes in Agile)
– Convert unknown to known

• Adopting an Iterative Approach

– Start with a crudely analyzed architecture addressing the more important quality attributes that
support the most critical functionality to show to the customer
– Adapt and refactor based on new requirements
– Continue to experiment

S O F T W ARE A RCHI T E CT URE S 15 BITS-Pilani

G u id e l in es f o r Ag i le A rch i t e ct ing

• For large and complex systems with stable and well understood requirements?
– Build the architecture upfront

• For large systems with vague and unstable requirements?

– Build a ‘Walking Skeleton’

• Smaller projects with uncertain requirements?

– Spend less time upfront

• Large & Complex Systems with vague and unstable requirements?

– ?

S O F T W ARE A RCHI T E CT URE S 16 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Attribute Driven Design (ADD))

S O F T W ARE A RCHI T E CT URE S 2 BITS-Pilani

A t tr i b u t e D r iv e n De s ig n ( AD D )

• Attribute Driven Design is an iterative method that at each iteration helps the
architect to do the following

– Choose a part of the system to design

– Marshall all the architecturally significant requirements for that part
– Create and test a design for that part

• Output
– Not an architecture complete in all details
– Produces a workable architecture early and quickly
– Main design approaches have been selected and vetted
– Set of sketches of architectural views including a module decomposition view
– Focus on information that passes through interfaces
S O F T W ARE A RCHI T E CT URE S 3 BITS-Pilani
I n p u t s t o AD D

• ASRs and Functional requirements that are available

• The Context Description
– What are the boundaries of the system being designed
– What are the external systems, devices, users, etc. that the system being designed must interact with

External System 3 External System 1

Actor 1

Software System
Under Construction
External
Data Store
Actor 2

S O F T W ARE A RCHI T E CT URE S 4 BITS-Pilani

S t e p s o f A DD

• ADD is a five step method:

1. Choose an element of the system to design

2. Identify the ASRs for the chosen element

3. Generate a design solution for the chosen element

4. Inventory remaining requirements and select the input for the next iteration

5. Repeat steps 1 to 4 until all the ASRs have been satisfied

S O F T W ARE A RCHI T E CT URE S 5 BITS-Pilani

Step 1: Choose an Element of the System to Design

• Start with a part of the system that has not yet been designed

• In the first iteration ADD will yield a broad shallow design with the high level elements
identified

• In the next iteration take one of the elements identified in the previous iteration –
“chosen element”

• Two strategies to pursue for refinement

– Breadth First
– Depth First
– The strategy used is determined by multiple factors

S O F T W ARE A RCHI T E CT URE S 6 BITS-Pilani

Step 2: Identify the ASRs for this Element

• Identify ASRs to be implemented by the system

– If required split the ASRs and assign to elements (Performance Budget)
– Prioritize if required
– Look for dependencies and trade offs

S O F T W ARE A RCHI T E CT URE S 7 BITS-Pilani

Step 3: Generate a Design Solution for the Chosen
Element

• This is the main step in ADD

• Encompasses the Generate-and-test strategy

• Develop a solution for each ASR assigned to the Element

– Select Candidate Design Approach
– Use patterns
– Influenced by technology

S O F T W ARE A RCHI T E CT URE S 8 BITS-Pilani

Step 4: Verify and Refine Requirements and Generate
Input for the Next Iteration

• Design solution in step 3 may not satisfy all ASRs or may not be detailed enough

• If a ASR cannot be satisfied by further elaborating the existing design the design
needs to be reconsidered

• Take stock of the requirements

– The requirement or constraint has been satisfied
– The requirement or constraint has been delegated to a child
– The requirement or constraint has been distributed to the children
– The requirement or constraint cannot be satisfied

S O F T W ARE A RCHI T E CT URE S 9 BITS-Pilani

Step 5: Repeat Steps 1-4 Until Done

• All quality attributes and constraints have been met

– No more detailing is required in the context of the project

• The allocated budget has been exhausted

• Schedule constraints do not allow for further refinement

• It is not possible to build the system within the imposed constraints

S O F T W ARE A RCHI T E CT URE S 10 BITS-Pilani

G u id e l in es

• Move quickly, do not get stuck with a problem for long, make an assumption and move
on, you can validate the assumption in later iterations

• Be willing to experiment

• Ask for help and on-board people with deep skills in areas of importance in the
architecture, You need not know everything

• Be aware of best practices, design principles, templates, patterns, frameworks, ……

• Work with an open mind, seek feedback, adapt and change, do not be afraid to re-start
if required.
S O F T W ARE A RCHI T E CT URE S 11 BITS-Pilani
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Discussion on Quiz 1
11th June, 2023, Sunday 6pm to 12th June, Monday Midnight – 5 Marks )
S O F T W ARE A RCHI T E CT URE S 12 BITS-Pilani
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Documenting Software Architecture)

S O F T W ARE A RCHI T E CT URE S 13 BITS-Pilani

Why Document S oftware Arc hit ect ure?

• Others can understand and evaluate the design

• We can understand the design when we return to it after a period of time
• Others in the project team and development organization can learn from the architecture by
digesting the thinking behind the design.
• We can do analysis on the design, perhaps to assess its likely performance, or to generate standard
metrics like coupling and cohesion.

• However documenting architecture can be very problematic because

– There’s no universally accepted architecture documentation standard
– An architecture can be complex, and documenting it in a comprehensible manner is time consuming and nontrivial
– An architecture has many possible views. Documenting all the potentially useful ones is time consuming and
expensive
– Keeping the architecture documents current is often an overlooked activity, especially with time and schedule
pressures in a project

S O F T W ARE A RCHI T E CT URE S 14 BITS-Pilani

Wh a t t o Do c u me nt ?

• There is no simple answer

– A lot depends on the judgement and experience of the architect

• Some Influencing factors

– The complexity of the application being developed
– Longevity of the application
– Needs of stakeholders
– Standards to comply with
– Budget
– Schedule
– Driving Quality Attributes

Documentation takes time to develop, and costs money.

S O F T W ARE A RCHI T E CT URE S 15 BITS-Pilani

H o w t o D o c u m e nt ?

• Simple Box & Arrow Diagrams

– Can be effective to communicate concepts especially to an audience not aware of formal
documentation notations
– Allows for flexibility

• UML 2.0
– Currently the predominant language for defining software
– Supported by multiple tools
– Understood by a wide community of professionals
– 2.0 is a significant improvement – Supports Model Driven Development and formalizes many
language constructs
– Will be the only means of documentation acceptable in this course

• The UML 2.0 modelling notations cover both structural and behavioural aspects of
software systems
S O F T W ARE A RCHI T E CT URE S 16 BITS-Pilani
N o ta t i on s

• Informal Notations
– General purpose diagraming tools
– No fixed notations
– Use of natural language
– Cannot be formally analyzed

• Semiformal Notations
– Standardized Notations
– Rudimentary Analysis can be applied
– UML

• Formal Notations
– Mathematically based semantics
– Formal analysis is possible
– Architecture Definition Language (ADL)

S O F T W ARE A RCHI T E CT URE S 17 BITS-Pilani

Ty pes of A rchitec ture Views

• Structural Views
– Represent static views of the system
– Depict the major components of the system and their relationships

• Behavioural Views
– Represent Dynamic Views of the system
– Depicts the states and interactions of the components in the system

S O F T W ARE A RCHI T E CT URE S 18 BITS-Pilani

T y p e s o f S t ru c t u ra l V ie w s
• Module Views
– Module view provide a blueprint for the construction of the system
– Shows the structure of the system
– Modules are the implementation units of software that provide a coherent set of responsibilities
– Modules show the following primary relations
• Is part of, Depends on

• Component & Connector Views

– Shows How the system works
– Depicts major elements of the system and the interaction between the elements
– Components – Principal processing units and data stores.
• Has a set of ports using which it interacts with other components
– Connectors – Path ways of interaction between components
• Rules define how components may use connectors in interactions

• Allocation Views
– How software elements in an architecture is mapped to environmental elements
– Used for assessment of quality attributes, allocation of work, installation, etc.
• Quality Views
– Used to highlight architectural aspects of specific quality attributes
– Can be tailored to address specific concerns of specific stakeholders
– Security View, Communications View, Reliability View
S O F T W ARE A RCHI T E CT URE S 19 BITS-Pilani
Q u a li t y V i e ws

• Security View
– A security view can show all of the architectural measures taken to provide security
– It would show the components that have some security role or responsibility, how these components communicate, and data
repositories that are of security interest
– Other Aspects Considered – Physical Security, Human Interaction, response to threats and vulnerabilities, security protocols

• Communications Views
– Especially useful in systems that are globally dispersed and heterogeneous
– Depicts the component-to-component channels, various network channels, QOS parameters, concurrency concerns
– Analyze deadlock and race conditions

• Reliability Views
– Reliability mechanisms like replication and switch-over are modelled
– Transaction integrity

S O F T W ARE A RCHI T E CT URE S 20 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Documenting Software Architecture Continued….)
Structural Diagrams in UML

• The structural diagrams define the static architecture of a model

– Class diagrams: Show the classes in the system and their relationships.
– Component diagrams: Describe the relationship between components with well
defined interfaces. Components typically comprise multiple classes.
– Package diagrams: Divide the model into groups of elements and describe the
dependencies between them at a high level.
– Deployment diagrams: Show how components and other software artifacts like
processes are distributed to physical hardware.
– Object diagrams: Depict how objects are related and used at run-time. These are
often called instance diagrams.
– Composite Structure diagrams: Show the internal structure of classes or
components in terms of their composed objects and their relationships.
SOFTW ARE A RCHITECTURES 3 BITS-Pilani
O rd e r P ro ce ssin g S yste m
• Formal Representation

SOFTW ARE A RCHITECTURES 4 BITS-Pilani

O rd e r P ro ce ssin g S yste m

• Interaction Diagram

SOFTW ARE A RCHITECTURES 5 BITS-Pilani

O rd e r P ro ce ssin g S yste m

• Component Diagram

SOFTW ARE A RCHITECTURES 6 BITS-Pilani

O rd e r P ro ce ssin g S yste m

• Component Diagram

SOFTW ARE A RCHITECTURES 7 BITS-Pilani

O rd e r P ro ce ssin g S yste m

• Deployment Diagram

SOFTW ARE A RCHITECTURES 8 BITS-Pilani

Types of Behavioural Views
• There are two kinds of notations available
– Trace-oriented representations
– Comprehensive Representation

• Trace Oriented Representations

– Sequence of activities or interactions that describe the system’s behavior to a specific
stimulus
– Use Case Diagrams, Sequence Diagrams, etc.

• Comprehensive Representation
– Depict the complete behaviour of a system
– Can be used to determine all paths between states
– State Machine
SOFTW ARE A RCHITECTURES 9 BITS-Pilani
Behaviour Diagrams in UML
• Behaviour diagrams show the interactions and state changes that occur as
elements in the model execute
– Activity diagrams: Similar to flow charts, and used for defining program logic and business
processes.
– Communication diagrams: Depict the sequence of calls between objects at run-time.
– Sequence diagrams: Often called swim-lane diagrams after their vertical timelines, they show the
sequence of messages exchanged between objects.
– State Machine diagrams: Describe the internals of an object, showing its state and events, and
conditions that cause state transitions.
– Interaction Overview diagrams: These are similar to activity diagrams, but can include other UML
interaction diagrams as well as activities. They are intended to show control flow across a number of
simpler scenarios.
– Timing diagrams: These essentially combine sequence and state diagrams to describe an object’s
various states over time and the messages that alter the object’s state.
– Use Case diagrams: These capture interactions between the system and its environment, including
users and other systems.

SOFTW ARE A RCHITECTURES 10 BITS-Pilani

O rd e r P ro ce ssin g S yste m
• Sequence Diagram

SOFTW ARE A RCHITECTURES 11 BITS-Pilani

State Machine Diagram
• Cruise Control System

SOFTW ARE A RCHITECTURES 12 BITS-Pilani

Example of State Machine Diagram
• State Transation Diagram Example – Self Study
Numlock Key Typed

Caps Key Typed Caps Locked

Numlock Key Typed Caps Locked
Num Locked
Caps Key Typed
Caps Key Typed Shift Key Released
Shift Key Released
Shift Key Pressed
Shift Key Pressed
Numlock Key Typed Caps Key Typed Numlock Key Typed
Caps Locked Caps Locked
Normal Num Locked
Numlock Key Typed
Shift Pressed Numlock Key Typed Num Locked
Caps Key Typed Shift Pressed
Shift Key Released
Caps Key Typed
Shift Key Released Shift Key Pressed
Shift Key Pressed
Caps Key Typed
Num Locked Caps Key Typed
Shift Pressed Numlock Key Typed
Shift Pressed
Numlock Key Typed

State Transition Diagram for A Keyboard with Number Pad

SOFTW ARE A RCHITECTURES 13 BITS-Pilani

Combining Views
• The basic principle of documenting an architecture as a set of separate views brings a
divide-and-conquer advantage to the task of documentation.
• However if the views have no association with one another, the system would be
incomprehensible
• Because all views in a architecture are part of that same architecture and exist to
achieve a common purpose, many of them have strong associations with one another
• One of the ways to depict this strong association is to collapse the views into a single
view.
• A combined view is a view that contains elements and relations that come from two or
more views. They are be useful as long as not overloaded with to much information.

In summary, the objective of architecture documentation is “communication”. As long as it

achieves it “unambiguously” for the “intendent audience”, its purpose is met!
SOFTW ARE A RCHITECTURES 14 BITS-Pilani
 Philippe Kruchten’s 4+1 view

Logical view depicts the Development view depicts the

functionality that the system system from a programmer's
provides to end-users. Class Logical View Development View perspective. Also known as the
diagrams, State diagrams. implementation view.
(Structural Views) Component diagram, Package
diagram
Scenarios
Process view depicts the Physical view, also known
dynamic aspects of the as the deployment view is
system, focuses on the run Process View Physical View concerned with the
time behavior of the system. topology of software
Sequence diagram, components on the physical
Communication diagram, Use Case scenarios are used to layer as well as the physical
Activity diagram illustrate and validate the architecture connections between these
(Behavioural Views) design. They also serve as a starting components. Deployment
point for tests of an architecture diagram.
prototype. This view is also known as
the use case view.
SOFTW ARE A RCHITECTURES 15 BITS-Pilani
Documentation in Agile

• Write for the reader – No audience => No Document

• YAGNI : You ain’t gonna need it – Only document something when you actually
have the need for it

• Views & Beyond : Use Architectural View as the unit of documentation to

produce
– Document a view if it is likely to be required in the future even if it is not required now

SOFTW ARE A RCHITECTURES 16 BITS-Pilani

Architecture Documentation Package

SOFTW ARE A RCHITECTURES 17 BITS-Pilani

Software Architecture Process

• Determine Architecture Requirements Determine

Architecture
– This involves creating a statement or model Requirements
of the requirements that will drive the
architecture design
• Architecture Design
– This involves defining the structure and
responsibilities of the components that will
comprise the architecture.
• Validation
Architecture
– This involves “testing” the architecture, Validation
Design
typically by walking through the design,
against existing requirements and any
known or possible future requirements.

SOFTW ARE A RCHITECTURES 18 BITS-Pilani

 Software Architectures

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Layered Architecture)

SOFTW ARE A RCHITECTURES 2 BITS-Pilani

Layered Architecture

• Design of a software application can always be decomposed into logical

groupings of software components called layers
• Layers may in turn contain sub-layers
• Why Layers?
– Differentiate between the different kinds of tasks performed by the components
– Easier to create a design that supports reusability of components
– Maximize maintainability of the code
– Optimize the way that the application works when deployed in different ways
– Clear delineation between locations where certain technology or design decisions must
be made
• The simplest Layered Architecture comprises of Presentation, Business & Data
Layers
– Model-View-Controller
SOFTW ARE A RCHITECTURES 3 BITS-Pilani
Layered Architecture
• Presentation Layer contains the
user oriented functionality
responsible for managing user
interaction with the system, and
generally consists of components
that provide a common bridge into
the core business logic
encapsulated in the business layer.
• Business Layer implements the
core functionality of the system,
and encapsulates the relevant
business logic
• Data Layer provides access to data
hosted within the boundaries of
the system, and data exposed by
other networked systems; perhaps
accessed through services.

SOFTW ARE A RCHITECTURES 4 BITS-Pilani

Layered Architecture
• A Services Layer allows the
application to better support
multiple client types, and
promotes re-use and higher level
composition of functionality across
applications

SOFTW ARE A RCHITECTURES 5 BITS-Pilani

Presentation Layer Guidelines
• Consists of
– User Interface Components
– Presentation Logic Components
• Design Issues
– Caching – Performance and Responsiveness
– Communication – Long running requests and user impatience
– Composition – UI Composition patterns and reusable UI elements
– Exception Management – Centralized, nothing goes unhandled
– Navigation – Ease, intuitive and ‘no-need-to-remember’
– User Experience – Over all feel-good factor
– User Interface – Usability guidelines and standards
– Validation – Users make mistakes…
• Technology Considerations
– Mobile Applications
– Rich Client Applications
– Rich Internet Applications
– Web Applications

SOFTW ARE A RCHITECTURES 6 BITS-Pilani

Business Layer Guidelines
• Consists of
– Application Facade
– Business Logic components
• Business Workflow
• Business Entity
• Design Issues
– Authentication – “The user is who the user claims to be”
– Authorization – “The user is allowed to perform the action that she wants to perform”
– Caching – Reference Lookup, lesser network round trips, avoid duplicate processing
– Coupling & Cohesion – Improves scalability
– Exception Management – DoS attacks
– Logging & Instrumentation – Helps debugging and quick trouble shooting, maintainability
– Auditing – Non repudiation
– Validation – Required even if robust client side validation is present, Cross Site Scripting
• Deployment Considerations
– Co-locate business and presentation layer on same physical tier for performance
– Consider SSL for security for web services
– Use appropriate security features for communication between layers

SOFTW ARE A RCHITECTURES 7 BITS-Pilani

Data Layer Guidelines
• Consists of
– Data Access Components
– Service Agents

• Design Issues
– Batching – Helps improve performance
– Binary Large Objects (BLOBs) – Single stream of data, Image, Persistent Objectss
– Connections – Manage Connections Effectively
– Data Format – Aid to interoperability, inter process communication
– Exception Management – Rollback mechanisms
– Object Relational Mapping – Consider translation overheads, and other mismatches
– Queries – Optimize queries for better performance
– Stored Procedures – Provide no significant advantage
– Stored Procedures vs. Dynamic SQL – Consider Maintainability
– Transactions – Essential for maintaining data integrity
– Validation – SQL Injection
– XML – Good for interoperability and data outside a DB, performance issues
• Performance
• Security

SOFTW ARE A RCHITECTURES 8 BITS-Pilani

Service Layer Guidelines
• Consists of
– Service Interfaces
– Message Types
• Design Issues
– Authentication
– Authorization
– Communication – Protocol, TCP, HTTP, etc.
– Exception Management – DoS attacks
– Messaging Channels – ESB
– Message Construction – The wrapper for the message to be transferred
– Message Endpoint – Duplicate / invalid message, connection used to interact with service
– Message Protection – SSL and other means to protect the message in transmission
– Message Routing - Decouple a service consumer from the service implementation
– Message Transformation – Make the consumer and provider understand each other
– Service Interface – Contract of the services
– Validation – Request validation

SOFTW ARE A RCHITECTURES 9 BITS-Pilani

 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Architecture Testing & Evaluation)

SOFTW ARE A RCHITECTURES 10 BITS-Pilani

Software Architecture Process

• Determine Architecture Requirements Determine

Architecture
– This involves creating a statement or model Requirements
of the requirements that will drive the
architecture design
• Architecture Design
– This involves defining the structure and
responsibilities of the components that will
comprise the architecture.
• Validation
Architecture
– This involves “testing” the architecture, Validation
Design
typically by walking through the design,
against existing requirements and any
known or possible future requirements.

SOFTW ARE A RCHITECTURES 11 BITS-Pilani

A rch ite ctu re Te stin g & E va lu a tio n

• It is the process of determining if an architecture is fit for the purpose for which it is
intended

• Architecture is evaluated via Analysis.

• Evaluation usually takes one of three forms.

– Evaluation by the designer within the design process

– Evaluation by peers within the design process
– Analysis by outsiders once the architecture has been designed

SOFTW ARE A RCHITECTURES 12 BITS-Pilani

H o w M u ch A n a lysis?

• Performing analysis is a matter of cost and benefit

– The importance of the decision

– The number of potential alternatives

– Good Enough as opposed to Perfect

Do not spend more time on a decision than it is worth, but also do not spend less
time on an important decision than it needs

SOFTW ARE A RCHITECTURES 13 BITS-Pilani

P e e r R e vie w s

• The following are the steps in a peer review

– The reviewers determine a number of quality attribute scenarios to drive the review

– The architect presents the portion of the architecture to be evaluated

– For each scenario, the designer walks through the architecture and explains how the
scenario is satisfied

– Potential problems are captured

SOFTW ARE A RCHITECTURES 14 BITS-Pilani

P la n n in g fo r a R e vie w
• What artifacts are available?

• Who sees the results?

• Who performs the evaluation?

• Which stakeholders will participate?

• What are the business goals?

SOFTW ARE A RCHITECTURES 15 BITS-Pilani

T h e Ar c h i t e c t u r e T r a d e o f f An a l y s i s M e t h o d
• ATAM has been used for over a decade to evaluate software architectures

• ATAM is designed so that evaluators need not be familiar with the architecture
or its business goals.

• The participants in ATAM are

– The evaluation team
– Project Decision Makers
– Architecture Stakeholders

SOFTW ARE A RCHITECTURES 16 BITS-Pilani

A TA M Ou tp u ts

• A concise presentation of the architecture

• Articulation of the business goals
• Prioritized quality attribute requirements expressed as quality attribute scenarios
• A set of risks and non-risks in the context of architectural decisions
• A set of risk themes
• Mapping of architectural decisions to quality requirements
• A set of identified sensitivity and tradeoff points

SOFTW ARE A RCHITECTURES 17 BITS-Pilani

A TA M S te p s o f E va lu a tio n
• Present the ATAM
• Present the business drivers
• Present the architecture
• Identify architectural approaches
• Generate Quality Attributes Utility Tree
• Analyze architectural approaches
• Brainstorm and Prioritize Scenarios
• Analyze the architecture
• Present Results

The analysis is not meant to be comprehensive. The key is to elicit sufficient architectural information to
establish some link between the architectural decisions that have been made and the quality attribute
requirements that need to be satisfied

SOFTW ARE A RCHITECTURES 18 BITS-Pilani

L ig h tw e ig h t A rch ite ctu re E va lu a tio n

• ATAM is very effort intensive and requires substantial investment

• For smaller less risky projects adaptations of ATAM may be used that are light weight
and quicker to execute

• No participation of people from outside the organization is required

SOFTW ARE A RCHITECTURES 19 BITS-Pilani

 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Software Architectures
(Architecture & Testing)

SOFTW ARE A RCHITECTURES 20 BITS-Pilani

A rch ite ctu re & Te stin g
• A common myth is that Architecture and testing have no relation

– Testing can be purely viewed as a process of functional verification to ensure that the functionality of the application
built meets the stated requirements

• Levels of Testing & Architecture

– Unit Testing: Architectural elements that compose the system can also be considered to be units

– Integration Testing: Architecture plays a critical role in integration testing by helping to identify the integration points
and the integration protocols,.

– Acceptance Testing (Alpha & Beta Testing): Here is where the systems quality attributes are put to a real test in the
field. Architecture can give key pointers to ‘weak areas’ that may require additional attention

– Regression Testing: Architecture can help do an ‘impact analysis’ to determine the best suite of regression test cases
to execute

SOFTW ARE A RCHITECTURES 21 BITS-Pilani

Th e A rc h ite c t’s R o le in Te s tin g
• Design a highly testable system - testability

• Ensure testers have access to all design artifacts and understand them well

• Give testers the ability to install multiple versions of a software product on a single machine

• Ability to reset the state of a database / data set

When a serious problem is found it is usually the architect who is one of the first people asked to
diagnose the problem

SOFTW ARE A RCHITECTURES 22 BITS-Pilani