0% found this document useful (0 votes)
23 views486 pages

Swa Cs 1to10

The document outlines a course on software architecture, detailing its importance, objectives, learning outcomes, and methodologies. It covers key concepts such as the definition of software architecture, the role of an architect, architectural patterns, and the differences between architecture and design. Additionally, it emphasizes the significance of good architecture in meeting requirements and facilitating stakeholder understanding.

Uploaded by

maaz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views486 pages

Swa Cs 1to10

The document outlines a course on software architecture, detailing its importance, objectives, learning outcomes, and methodologies. It covers key concepts such as the definition of software architecture, the role of an architect, architectural patterns, and the differences between architecture and design. Additionally, it emphasizes the significance of good architecture in meeting requirements and facilitating stakeholder understanding.

Uploaded by

maaz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 486

Software Architecture

Introduction
Author: Viswanathan Hariharan
BITS Pilani Edited by Vijayarajan A
Contents

• What is software architecture?


• Importance of software architecture
• Difference between Architecture and Design
• Architecture patterns
• Characteristics of good architecture
• Challenges in software architecture
• Role of an architect

• About this course


• Faculty Introductions
Objective of the course

No Course Objective

CO1 To enable software engineers to architect software


systems using industry best practices
CO2 To enable project managers to understand techniques of
software architecture, and help them take appropriate
decisions
CO3 To enable software professionals to take up research
activities in the domain of software architecture
Learning outcomes
No Learning Outcome
LO1 Ability to identify architecturally significant requirements and apply
appropriate tactics to address them
LO2 Ability to determine appropriate architecture patterns for given requirements
LO3 Ability to document architecture that meets the needs of stakeholders
LO4 Ability to analyse architecture and determine its appropriateness given the
requirement and determine risks
LO5 Awareness of best practices in design of cloud based applications, distributed
applications and mobile applications
LO6 Awareness of new technologies and their architecture and understanding of
situations when to use these technologies
LO7 Ability evaluate the cost and benefit of different architecture options to aid in
decision making
Methodology

• Lectures
• Activities
• Assignments
• Self study
Evaluation method

• 2 Quizzes
• 2 Assignments
• Mid term exam
• End term exam
Handout

Refer to e-Learn Portal (Taxila)


Faculty Introduction

• M Tech (CS), MBA


• 43 Years of Industry Experience
• Wipro (Chief Executive, Health Science)
• GE Medical (Vice President)
• HP (Vice President)
• InnAccel (Founder & CTO) ✅
• Information Technology, MedTech
• System SW (Compiler, DB Development)
• Electronic Medical Record
• MedTech (Devices and SW)

BITS Pilani, Hyderabad Campus


What is software architecture?

Can we try to define ‘Software architecture’?


Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


What is software architecture?

Software architecture depicts the organization of software components and how


the software system works. It shows:
• The arrangement of software components
• Connection and interaction between software components
• Distribution of software components across different computing systems

Formal Definition of Architecture


the architecture of a system describes its gross structure. This structure illuminates
the top-level design decisions, including things such as how the system is
composed of interacting parts, what are the principal pathways of interaction, and
what are the key properties of the parts and the system as a whole. Additionally,
an architectural description includes sufficient information to allow high-level
analysis and critical appraisal.
SW Architecture another Defn.

• The structure of the system refers to architecture style (or styles) the system is
implemented in (such as microservices, layered, or microkernel)”

• Architecture characteristics refers to the “-ilities” that the system must support”

• Architecture decisions define the rules for how a system should be constructed.
For example, only the business and services layers can access the database
restricting the presentation layer from making direct database calls.

• Design principle is a guideline rather than a hard-and-fast rule. For example, the
design principle may state that the development teams should leverage
asynchronous messaging between services within a microservices architecture to
increase performance.
Role of Architect

• Make architecture decisions


• Continually analyze the architecture
• Keep current with latest trends
• Ensure compliance with decisions
• Diverse exposure and experience
• Have business domain knowledge
• Possess interpersonal skills
• Understand and navigate politics
Difference between
architecture and design
Architecture Design

• Deals with design at a system • Deals with design at Module


level

• Based on business goals, • Based on purpose of module


requirements and constraints

• Involves decomposing the • Involves designing objects


system into components and within a module and
their interactions interactions between modules

BITS Pilani, Hyderabad Campus


Difference between architecture
and design

Architecting Used To be a Phase


SS ZG653
Difference between architecture
and design

Architecting is integrated in the Development Process

SS ZG653
Difference between architecture
and design

“a developer, who must have a significant amount of technical depth to


perform their job, a software architect must have a significant amount of
technical breadth to think like an architect and see things with an
architecture point of view.”

SS ZG653
Architecture - Trade Offs

• There are no right or wrong answers in architecture—only trade-


offs
• Everything in software architecture has a trade-off: an advantage
and disadvantage.
• Thinking like an architect is analyzing these trade-offs, then asking
“which is more important: extensibility or security?”
• The decision between different solutions will always depend on
the business drivers, environment, and a host of other factors.”

SS ZG653
Architecting has become
iterative
Unknown unknowns are the nemesis of software systems.
Many projects start with a list of known unknowns.
However, projects also fall victim to unknown unknowns: things
no one knew were going to crop up yet have appeared
unexpectedly.
This is why all “Big Design Up Front” software efforts suffer:
architects cannot design for unknown unknowns.

All architectures become iterative because of unknown


unknowns, Agile just recognizes this and does it sooner”
Software architecture

Now let us look at an example of software architecture…


Software architecture consists
of many diagrams
• Context diagram
• Logical diagram / Component & Connection diagram
• Physical diagram / Deployment diagram
• A diagram to explain a scenario

• Each diagram provides a different perspective

• Software architecture = These diagrams + associated descriptions


Context diagram
Shows how the software fits in the overall system

Departure Control System at Airport


Logical diagram / Component & Connection view
Shows different components and their logical connection with other components

Passengers using Kiosk Staff using desktop

HTTP

Kiosk req. Desktop req.


handler handler Data
Request
Check-in, Select seat, excess baggage Get passenger list. handler

Reservation
Check-in module
system API

Payment request Get booked Get departed


JDBC (Card #, Amount,…) passenger list passenger list
(REST) (REST) (REST)

Bank server Reservation Airport


Payment
Gateway system system
Bank server
Physical diagram / Deployment diagram
Shows distribution of sw components across computing units
Client Client
Browser Browser

Firewall

Load Balancer
Server cluster / farm

Web server / App Server Web server / App Server Web server / App Server
SMS
gateway
Case Other Case Other Case Other (Telco)
module modules module modules module modules

Firewall

Primary Backup
DB DB
server server
A diagram (view) to explain a scenario:
Ex. Show how the ‘Stop booking’ request works

Desktop with browser

1
Stop booking request

Web Server
Desktop
req. 2
handler Stop booking request msg

Reservation
system API

Stop booking message (flt #, …)


3 (REST)

Reservation
system
Why is software architecture
important?
• Lays foundation for future work - detailed design, development & testing

• Helps evaluate if approach is correct


• Is the system secure against hacking, snooping, etc. (firewall,
encryption)?
• Is the system easy to maintain (Modular, Layered, Reusable
components, etc.)?
• Will the system provide desired response time (sufficient servers,
replicated data, caching)?

• Helps stakeholders understand how the system will work. Stakeholders are
sponsors, developers, operations staff, etc.
Architecture structures

The 3 structures correspond to 3 broad types of decisions that an


architectural design involves:
• Module structure: How is the system to be structured as a set
of code units?
• Component & Connection structures: How is the system to
be structured as a set of runtime components and
interactions between them?
• Deployment structure: How is the system to relate to non-
software elements in its environment? (CPU, file systems,
networks, development teams, etc)
Module Structure

Module structures allow us to answer questions such as these:


– What is the primary functional responsibility assigned to each
module?
– What other software elements is a module allowed to use?
– What other software does it actually use and depend on?
– What modules are related to other modules by generalization or
specialization (i.e., inheritance) relationships?
Component-and-connector
Structures
Component-and-connector views help us answer questions such as these:
– What are the major executing components and how do they interact at
runtime?
– What are the major shared data stores?
– Which parts of the system are replicated?
– How does data progress through the system?
– What parts of the system can run in parallel?
– Can the system’s structure change as it executes and, if so, how?
Component-and-connector views are crucially important for asking questions
about the system’s runtime properties such as performance, security,
availability, and more.
Allocation structures

Allocation views help us answer questions such as


these:
– What processor does each software element execute on?
– In what directories or files is each element stored during
development, testing, and system building?
– What is the assignment of each software element to
development teams?
Architectural Patterns

Architectural elements can be composed in ways that solve


particular problems.
– The compositions have been found useful over time, and over many different domains
– They have been documented and disseminated.
– These compositions of architectural elements, called architectural patterns.
– Patterns provide packaged strategies for solving some of the problems facing a system.

A common module type pattern is the Layered pattern.


– When the uses relation among software elements is strictly unidirectional, a system of
layers emerges.
– A layer is a coherent set of related functionality.
– Many variations of this pattern, lessening the structural restriction, occur in practice.
Architectural Patterns

Common component-and-connector type patterns:


Shared-data (or repository) pattern.
– This pattern comprises components and connectors that create, store, and
access persistent data.
– The repository usually takes the form of a (commercial) database.
– The connectors are protocols for managing the data, such as SQL.

Client-server pattern.
– The components are the clients and the servers.
– The connectors are protocols and messages they share among each other to
carry out the system’s work.
Architectural Patterns

Common allocation patterns:


Multi-tier pattern
– Describes how to distribute and allocate the components of a system in distinct subsets
of hardware and software, connected by some communication medium.
– This pattern specializes the generic deployment (software-to-hardware allocation)
structure.
Competence center pattern and platform pattern
– These patterns specialize a software system’s work assignment structure.
– In competence center, work is allocated to sites depending on the technical or domain
expertise located at a site.
– In platform, one site is tasked with developing reusable core assets of a software
product line, and other sites develop applications that use the core assets.
Characteristics of good
software architecture
• Meets the functional & non-functional requirements
• Reduces complexity and easy to understand
• Easy to extend and modify
• Not over engineered
• Cost effective
Architecture Influence Cycle

Architect’s Influences
Business
Architecture
Technical Stakeholders

Project

Professional System
Architect
Input for software architecture
• What are the inputs needed for doing software architecture?

• Business goals. Provide a ‘Unified view’ of the customer to the Bank staff,
by presenting information from disparate systems such as Savings bank
system, Loan system, Credit card system, etc. This will enable be better
customer service by staff.

• Functional requirements. System should support customer service


functions, loyalty program functions, customer needs prediction function,
etc.

• Quality attributes (Stakeholder expectations). Need to have <3 sec


response time with a peak load of 1,000 concurrent users and should have
an up-time of 99.95%

• Constraints: Need to work with legacy mainframe systems, Data should


reside within Europe
Expectations of different
stakeholders

Dev &
End user maintenance
team
• Functionality • Easy to dev & modify
• Reliability • Portable
• Ease of use • Customizable
• Speed
Software

Business IT
manager department

• Functionality • Ease of installation


• Low cost • Plug & play
• Short time to market • Scalability
Exercise: Draw architecture of a
Retail banking system with ATMs
1. Identify the different physical components
2. Determine the software components that reside in them
3. Determine the communication between the components
Architecture of a banking
software supporting ATM
See next slide
High level diagram
ATM ATM ATM

ATM ATM ATM


module module module

Dedicated &
Secure network

Bank central Banking application DB


server
DB server
Component and Connection
diagram
ATM ATM ATM

ATM ATM ATM


module module module

OK, Balance, responses


Dedicated &
Secure network

Backend system

Login / logout Withdraw, Deposit, Check balance Cheque book request

Login / Logout Requests


Money transaction module
module module

Read. Update, Add, Delete DB


Data access module DB server
Message communications

Cash dispenser

From book: Software Modelling & design by Hassan Gomaa


Exercise

What kind of a system are you developing?


• Business system (information system)
• Real time system (control system, avionics, etc.)
• Data analytics system
• Mobile application
• Internet of Things system
• Video streaming system
• Image processing system (Medical imaging, Adobe, etc.)
• Networking (routers, SDN, etc.)
• Robotic system
• Others
Exercise
• Create a high level software architecture diagram of the system you are developing, showing its
major components and their inter-relationship, and

• Upload the same in this Google folder

https://drive.google.com/drive/folders/1_iwHUhadscnBEZwopmUWVopkahhy506e?usp=sharing

• File naming convention: <Type of system> <Name of system>.ppt

• Type of system can be one of the following:


• Business system (information system)
• Real time system (control system, avionics, etc.)
• Data analytics system
• Mobile application
• Internet of Things system
• Video streaming system
• Image processing system (Medical imaging, Adobe, etc.)
• Networking (routers, SDN, etc.)
• Robotic system
• Others
Appendix
Many contexts of architecture
Context Description
Technical • Enables achieving the quality attributes such as performance,
availability, security, etc.
• Depends on the technology available such as mainframe, client
server, web based, Object oriented, cloud based, etc.
Project Life • Architecture is created on requirements (ASR)
cycle • It is used to develop software
• It is used during testing, eg. Integration testing, performance
testing, etc.
Business • Business goals result in quality attributes such as response time of 3
seconds, uptime of 99.999%
• Quality attributes influence architecture
Professional • An architect should not only have good technical knowledge but
also be able to explain stakeholders why certain quality attributes
have been given higher priority (trade offs), why certain
expectations are not being fulfilled
Different types of application
and their architecture
• Internet based apps – Banking, eCommerce
• Mobile apps
• Real time systems – Industrial control, avionics
• Operating system
• ERP
• Networking systems
• Workflow based apps
• Content based apps
From book: Software Modelling & design by Hassan Gomaa
Real time systems – Automated guided vehicle
Real time system
Recommendations for making
a good architecture
Process recommendations:
• Use a single architect or a small group with a leader, to architect
• Create a prioritized list of quality attributes
• Document using views to address concerns of most important stakeholders
• Develop in increments & get early feedback

Structural recommendations
• Create well defined modules with information hiding
• Use small number of ways to interact eg. RPC or REST or pipes
• If performance is a major concern, define performance expectation of each
component in the chain
Views

• Views are meant for stakeholders to understand how the architecture


addresses his / her concern

• It consists of a sub set of the software components and their relationships

• It can show
• Structure: Ex. Class diagram, package diagram, context diagram
• Behaviour: Ex Sequence diagram, state diagram,

• It also contains
• Software element description
• Element interfaces
• Rationale
Structures

When we discuss about architecture we refer to different types of


structures

• Module structure
• Decomposition structure (System, sub-system, elements)
• Class diagram (Classes, associations, interfaces, dependencies, inheritance)
• Data model (ER diagram)
• Component & Connector structure
• Interaction between components (sequence diagram, collaboration diagram, interaction
mechanisms such as Call return, message queues, REST)
• Process synchronization (semaphores, critical section)
• Shared data stores (Database and access mechanisms)
• Allocation structure
• Processors and software elements in them
• Directories and files and what software elements they contain
• Assignment of software elements to software teams
The 3 structures correspond to 3 broad types of decisions
that an architectural design involves:
• How is the system to be structured as a set of code
units?
• How is the system to be structured as a set of runtime
components and interactions between them?
• How is the system to relate to non-software elements in
its environment? (CPU, file systems, networks,
development teams, etc)
Different types of software
Type of application Example
Enterprise apps Banking, Telecom, Airline, Retail
Industrial control, avionics Monitoring & controlling a power plant or chemical
factory
Monitoring and controlling an aircraft
Operating system Unix, Android, iOS

Networking systems TCP/IP, VPN, Firewalls, Routers


Workflow based apps Loan processing, Insurance claim processing,
Invoice processing
Portals & Content Newspaper website
management systems
Different types of software &
expectations from stakeholders
Type of application Expectations
Enterprise apps – Banking, Reliability, security, performance
Telecom, Airline, Retail

Industrial control, avionics Time critical, very reliable, life threatening if it fails

Operating system Reliable, support different devices, high


performance, muti-processing, security

Networking systems Fault tolerant, secure, performance


Workflow based apps Configurable, business rules
Portals & Content Personalization, security, data management
management systems
Homework activity

1. Get a sample architecture diagram of a software in your company


Real time system architecture

Inputs
Flight
control
system

Outputs
Real time software
architecture

Engine
Altimeter Fuel level
sensors
Sensors

Altitude Fuel level Speed, temp, vibration

Flight control software


1. Read sensor values
2. Compute control outputs
3. Send control output to actuators

Turn up / down, angle Decrease speed

Wing Engine Actuators


….
Controller controller
Service Oriented Architecture
Example: MakeMyTrip.com
Front end of Inq. Seat
application availability, Indigo
(GUI) Reserve seat system

MakeMyTrip
Internet backend Internet
Front end of system
application
(GUI)
Inq. room
availability,
Reserve room

Front end of Ginger


application system
(GUI)

Services offered by
other systems
Layered pattern:
Example: Architecture of an Information system

Ref: Software Architecture in Practice by Len Bass and others

SS ZG653
Software Architecture

Software Quality Attributes


Viswanathan Hariharan
BITS Pilani Edited by Vijayarajan
Contents

• Recap
• Quality attributes and Tactics Continued
• Architecturally significant Requirements

[email protected]
Assignment

A1 - Build an Architecture for an App


• The App should at minimum include the technologies Web, Mobile, IOT,
cloud and analytics.
• Each team will select an application and get the approval of the TA.
• Duplication May not be allowed …
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic and get the approval of the faculty.
• Duplication may not be allowed.
• Final Paper should be submitted as per the agreed upon template and
schedule
Schdule
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Importance of Quality
attributes
• Functional requirements help us to define the modules

• Quality attributes help us to structure the system


Importance of Quality
attributes

• If we have to design an ERP system, we can design the different


modules based on functional requirements

• But if the goal is to have a portable software that can be easily


ported to other operating systems, then we need to have a layer
that shields us from variations in OS
Quality attributes &
Architecture
• Input for Architecture are:
• Business goals
• Functional requirements
• Non-functional requirements or Quality attributes such
as response time needs, system uptime needs,
security needs, etc.
• Constraints such as choice of technology (client
server, Web, Cloud), language, availability of staff,
external systems (Mainframe) with which it needs to
interact, etc.
Examples of quality attributes

• Availability
• Performance
• Modifiability
Scalability
• Testability
• Usability
• Interoperability
• Security
Quality Attribute Scenario

Quality attribute requirements are expressed with


Scenarios
Quality attribute Scenario
Framework

Source of stimulus. entity ( human,


computer system, or any other
actuator) that generated the stimulus
Stimulus – is a condition that requires
a response when it arrives at a system

Environment: The stimulus occurs within certain conditions - Normal, safe mode,
overload condition etc
Artifact: Some artifact is stimulated – whole system or parts
Response: activity undertaken after the arrival of the stimulus.
Response measure: Measurable outcome, it should be measurable in some
fashion so that the requirement can be tested.
Design Tactics

Tactic is a design option for the architect


Testability

Testability deals with reducing the testing effort

Industry estimates indicate that between 30 and 50 percent (or in some


cases, even more) of the cost of developing well-engineered systems is
taken up by test- ing. If the software architect can reduce this cost, the
payoff is large.
Testability

What are some of the issues that lead to increased testing effort or lead to
delay in testing ?
Example

Fetal Lite Video


For a system to be properly testable, it must be possible to
control each component’s inputs (and possibly
manipulate its internal state) and then to observe its
outputs (and possibly its internal state, either after or on
the way to computing the outputs).
Testability Tactics

Testability Tactics

Control and Observe Limit Complexity


System State

Tests Specialized Limit Structural Faults


Executed Interfaces Complexity Detected

Record/ Limit
Playback Non-determinism
Localize State
Storage

Abstract Data
Sources

Sandbox
Executable
Assertions
Control and Observe System
State
Specialized Interfaces: to control or capture variable values for a
component either through a test harness or through normal
execution.
Record/Playback: capturing information crossing an interface
and using it as input for further testing.
Localize State Storage: To start a system, subsystem, or module in
an arbitrary state for a test, it is most convenient if that state
is stored in a single place.
Control and Observe System
State
Abstract Data Sources: Abstracting the interfaces lets you
substitute test data more easily.
Sandbox: isolate the system from the real world to enable
experimentation that is unconstrained by the worry about
having to undo the consequences of the experiment.
Executable Assertions: assertions are (usually) hand coded and
placed at desired locations to indicate when and where a
program is in a faulty state.
Limit Complexity

Limit Structural Complexity:


– avoiding or resolving cyclic dependencies between components,
– isolating and encapsulating dependencies on the external environment,
Limit Non-determinism: finding all the sources of non-
determinism, such as unconstrained parallelism, and weeding
them out as far as possible. (parallel threads!)
Security

Security is a measure of the system’s ability to protect data and


information from unauthorized access while still providing
access to people and systems that are authorized
Security

What are the common security issues in information systems?


Security
Security has three main characteristics, called CIA:
Confidentiality is the property that data or services are protected from unauthorized access. For
example, a hacker cannot access your income tax returns on a government computer.
Integrity is the property that data or services are not subject to unauthorized manipulation. For
example, your grade has not been changed since your instructor assigned it.
Availability is the property that the system will be available for legitimate use. For example, a
denial-of-service attack won’t prevent you from ordering a book from an online bookstore.
Other characteristics that support CIA are
Authentication verifies the identities of the parties to a transaction and checks if they are truly
who they claim to be. For example, when you get an e-mail purporting to come from a bank,
authentication guarantees that it actually comes from the bank.
Nonrepudiation guarantees that the sender of a message cannot later deny having sent the
message and that the recipient cannot deny having received the message. For example, you
cannot deny ordering something from the Internet, or the merchant cannot disclaim getting
your order.
Authorization grants a user the privileges to perform a task. For example, an online banking
system authorizes a legitimate user to access his account.
Confidentiality
Authenticity
Security Tactics
Security Tactics

Detect Attacks Resist Attacks React to Recover


Attacks from Attacks
Identify
Actors Revoke
Detect Maintain Restore
Access
Intrustion Authenticate Audit Trail
Attack System detects,
Detect Service Actors Lock resists, reacts,
Denial Computer or recovers
Authorize See
Verify Message Actors Availability
Integrity Inform
Actors
Detect Message Limit Access
Delay Limit Exposure

Encrypt Data

Separate
Entities
Change Default
Settings
Detect Attacks

Detect Intrusion: compare network traffic or service request


patterns within a system to a set of signatures or known
patterns of malicious behavior stored in a database.
Detect Service Denial: comparison of the pattern or signature
of network traffic coming into a system to historic profiles
of known Denial of Service (DoS) attacks.
Verify Message Integrity: use techniques such as checksums
or hash values to verify the integrity of messages, resource
files, deployment files, and configuration files.
Detect Message Delay: checking the time that it takes to
deliver a message, it is possible to detect suspicious timing
behavior.
Resist Attacks

Identify Actors: identify the source of any external input to the


system.
Authenticate Actors: ensure that an actor (user or a remote
computer) is actually who or what it purports to be.
Authorize Actors: ensuring that an authenticated actor has the
rights to access and modify either data or services.
Limit Access: limiting access to resources such as memory,
network connections, or access points.
Resist Attacks

Limit Exposure: minimize the attack surface of a system by


having the fewest possible number of access points.
Encrypt Data: apply some form of encryption to data and to
communication.
Separate Entities: can be done through physical separation on
different servers attached to different networks, the use of
virtual machines, or an “air gap”.
Change Default Settings: Force the user to change settings
assigned by default.
React to Attacks

Revoke Access: limit access to sensitive resources, even for


normally legitimate users and uses, if an attack is suspected.
Lock Computer: limit access to a resource if there are repeated
failed attempts to access it.
Inform Actors: notify operators, other personnel, or cooperating
systems when an attack is suspected or detected.
Recover From Attacks

In addition to the Availability tactics for recovery of failed


resources there is Audit.
Audit: keep a record of user and system actions and their effects,
to help trace the actions of, and to identify, an attacker.
Usability

Usability is concerned with how easy it is for the user to


accomplish a desired task and the kind of support it provides
to users
Dimensions of Usability

• Learnability: How easy is it for users to accomplish basic tasks the


first time they encounter the SW?

• Efficiency: Once users have learned the SW, how quickly can they
perform tasks?

• Memorability: When users return to the SW after a period of not


using it, how easily can they re-establish proficiency?

• Errors: how easily can users recover from the errors?

• Satisfaction: How pleasant is it to use the SW?


Usability

What are the ways in which we can make the User


interface easy to use?
Usability Scenarios

• Aggregating Data • Modifying user Interfaces


• Aggregating Commands • Supporting Multiple Activities
• Cancelling Commands • Navigating Within a Single View
• Using Applications Concurrently • Observing System State
• Checking for Correctness • Working at the User’s Pace
• Maintaining Device Independence • Predicting Task Duration
• Evaluating the System (tester) • Supporting Comprehensive Searching
• Recovering from Failure • Supporting Undo
• Retrieving Forgotten Passwords • Working in an Unfamiliar Context (novice)
• Providing Good Help • Verifying Resources (disk space? Battery?)
• Reusing Information • Operating Consistently Across Views
• Supporting International Use • Making Views Accessible
• Leveraging Human Knowledge • Supporting Visualization (print layout)

BITS Pilani, Hyderabad Campus


Usability Tactics

Usability Tactics

Support User Support System


Initiative Initiative
User Given
User Appropriate
Cancel Maintain Task Feedback and
Request
Model Assistance
Undo
Maintain User
Model
Pause/Resume
Maintain System
Aggregate Model
Support User Initiative

Cancel: the system must listen for the cancel request; the
command being canceled must be terminated; resources
used must be freed; and collaborating components must
be informed.
Pause/Resume: temporarily free resources so that they may
be re-allocated to other tasks.
Undo: maintain a sufficient amount of information about
system state so that an earlier state may be restored, at
the user’s request.
Aggregate: ability to aggregate lower-level objects into a
group, so that a user operation may be applied to the
group, freeing the user from the drudgery.
Support System Initiative

Maintain Task Model: determines context so the system can have


some idea of what the user is attempting and provide
assistance. (capital letter)
Maintain User Model: explicitly represents the user's knowledge
of the system, the user's behavior in terms of expected
response time, etc. (configuration, running help)
Maintain System Model: system maintains an explicit model of
itself. This is used to determine expected system behavior so
that appropriate feedback can be given to the user. (progress
bar)
Other quality attributes

• Interoperability
• Scalability
• Portability
• Deployability
• Monitorability
Design trade-offs

Examples

• Modifiability vs Performance: Too much modularity may impact


performance as the request passes through multiple modules

• Security vs performance: High security in the form of encryption will


delay response to end users

• Availability vs Testability: If we introduce redundancy to improve


availability, we need to have mechanism to test if the system is
recovering from faults
Summary

• Architecture is determined not only by functionality but


also quality attributes and constraints

• We looked at some important quality attributes (QA) &


corresponding tactics

• Trying to satisfy one QA may impact another QA. Hence


we need to prioritize the QA
Exercise: Identify one dominant quality
attribute (QA) of systems given below
System Dominant Quality attribute to be addressed

IRCTC

YouTube

Flipkart.com

OnlineSBI.com

Uber
Exercise: Identify one dominant quality
attribute (QA) of systems given below
System Dominant Quality attribute to be addressed

IRCTC Availability, Performance

YouTube Performance

FlipKart.com Availability, Performance, Usability

OnlineSBI.com Security

Uber Usability
Exercise: Identify a tactic to
address the Quality Attribute
System Dominant Quality Tactics
attribute to be
addressed
IRCTC Availability,
Performance
YouTube Performance

Flipkart.com Availability,
Performance, Usability

OnlineSBI.com Security

Uber Usability
Exercise: Identify a tactic to
address the Quality Attribute
System Dominant Quality Tactics
attribute to be
addressed
IRCTC Availability, Multiple servers
Performance
YouTube Performance Content Delivery Network (data
replication)
Flipkart.com Availability, Easy to search and buy (navigation)
Performance, Usability

OnlineSBI.com Security Encryption of sensitive data in DB,


Digital certificate
Uber Usability Easy to book a cab and cancel
Software Architecture

Software Quality Attributes


BITS Pilani Viswanathan Hariharan
Edited by Vijayarajan
Assignment

A1 - Build an Architecture for an App


• The App should at minimum include the technologies Web, Mobile, IOT,
cloud and analytics.
• Each team will select an application and get the approval of the TA.
• Duplication May not be allowed …
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic and get the approval of the faculty.
• Duplication may not be allowed.
• Final Paper should be submitted as per the agreed upon template and
schedule
Contents

• Recap
• Introduction to quality attributes
• Tactics to achieve quality attributes
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Why do we Need Structure

Functionalities are articulated by Functional requirements


There are other requirements generally not articulated
They are implicit or not very explicit
They are domain specific
Importance of Quality
attributes
• Functional requirements help us to define the modules

• Quality attributes help us to structure the system


Importance of Quality
attributes

• If we have to design an ERP system, we can design the different


modules based on functional requirements

• But if the goal is to have a portable software that can be easily


ported to other operating systems, then we need to have a layer
that shields us from variations in OS
Quality attributes &
Architecture
• Input for Architecture are:
• Business goals
• Functional requirements
• Non-functional requirements or Quality attributes such
as response time needs, system uptime needs,
security needs, etc.
• Constraints such as choice of technology (client
server, Web, Cloud), language, availability of staff,
external systems (Mainframe) with which it needs to
interact, etc.
Examples of quality attributes

• Availability
• Performance
• Modifiability
• Testability
• Usability
• Interoperability
• Security
How to achieve quality
attributes?
• Partly through coding
• Partly through architecture
How to achieve quality
attributes?
Example

If we want a high performance software with fast response


time, then

• We have to use the best algorithm which takes minimal time


(coding)
• We have to distribute copies of the software on multiple servers
to handle the load (architecture)
How to achieve quality
attributes?
Example

If we want a software that is easy to modify, then

• We have to divide it into functional modules (architecture)

• We also have to code it using good naming conventions for


variables and functions (coding)
Quality attributes
Deep Dive
Quality Attribute
Requirements
How do we articulate the Quality attribute requirements
Quality Attribute Scenario

Quality attribute requirements are expressed with


Scenarios
Quality attribute Scenario
Framework

Source of stimulus. entity ( human,


computer system, or any other
actuator) that generated the stimulus
Stimulus – is a condition that requires
a response when it arrives at a system

Environment: The stimulus occurs within certain conditions - Normal, safe mode,
overload condition etc
Artifact: Some artifact is stimulated – whole system or parts
Response: activity undertaken after the arrival of the stimulus.
Response measure: Measurable outcome, it should be measurable in some
fashion so that the requirement can be tested.
Quality attribute Scenario
Framework - example
Refer to the PDF
Design Tactics

Tactic is a design option for the architect


Availability

• Availability is the ability of a system to minimize system outages

• Availability is generally measured as % of up-time

• Ex. If a system is down for an average of 1 day in 100 days, its


availability is 99%
• If a system is down for an average of 2 day in 100 days, its
availability is 98%
• If a system is down for an average of 0.5 day in 100 days, its
availability is 99.5%
Availability

Calculating availability

Uptime
Downtime
(Time between failures)
(Time to repair)
(TBF)
(TTR)
99 days
1 day

Availability = Mean TBF / (Mean TBF + Mean TTR)


= MTBF / (MTBF + MTTR)
Availability

What are the issues that affect availability?


Availability
Issue Tactic
Disk failure
Server failure

Link failure
Malicious user
floods the system
with fictitious login
Temporary loss of
connection

Unreliable code /
algorithm
Availability
Issue Tactic
Disk failure Real time replication (Hot standby)
Server failure Backup server running the same application
Master regularly updates the Backup about the progress. Upon
failure, backup becomes master and continues from the last
known state (Warm standby)
Link failure Redundant communication paths
Malicious user Block IP
floods the system
with fictitious login
Temporary loss of Retry after some time. Ex. Mobile app unable to reach
connection application in central server

Unreliable code / Have multiple algorithms compute the result. Compare their
algorithm results. Take the result given my most algorithms
Example: Boeing 777 Triple
Modular Redundancy (TMR)
• The flight computer uses TMR with three dissimilar computation
lanes

• Results of at least 2 computational modules need to match to go


ahead

Compute
altitude using
pressure

Compute
altitude using Compare Altitude of plane
sound wave

Compute
altitude using
infrared?
Availability - Details
① Source of stimulus. entity ( human, computer system, or any other actuator) that generated the stimulus
② Stimulus - condition that needs to be considered when it arrives at a system. Tactic is a design
③ Artifact: Some artifact is stimulated – whole system or parts; option for the
④ Environment: The stimulus occurs within certain conditions - Normal, safe mode, overload condition etc architect
⑤ Response: activity undertaken after the arrival of the stimulus.
⑥ Response measure: Measurable outcome, it should be measurable in some fashion so that the requirement can be tested.


Scenarios should cover a range of
• Anticipated uses of (use case scenarios), ②
• Anticipated changes to (growth scenarios), or ③
• Unanticipated stresses (exploratory scenarios) to the system.


Quality Attributes &Tactics
Identify the Quality attributes and Tactics
require to achieve them ⑥






① ⑥




Measure Availability percentage (e.g., 99.999%)
Time to detect the fault
Time to repair the fault
Availability Scenario
Time or time interval in which system can be in degraded mode
Proportion (e.g., 99%) or rate (e.g., up to 100 per second) of a certain
class of faults that the system prevents, or handles without failing

1
Artifact: 2
Process 3
Stimulus: Response:
Server Inform 4
Unresponsive Environment: Operator
Source: Continue
Response
Normal Measure:
Heartbeat to Operate
Operation No Downtime
Monitor

FIGURE 5.3 Sample concrete availability scenario


Experience sharing

Have you come across situations where you faced


Availability challenges?

How did you address them?


Performance

It is the system’s ability to meet timing requirements.

Measurements
• Latency: Time to respond: Ex. 3 seconds
• Throughput: The number of requests handled per second: Ex. 3000
txns per second
• Jitter of response: Variation in response time: Response time is 3
seconds when # of users is 50, 5 seconds when # of users is 100

• Deadline: The max time within which it should respond


(Requirement)
Latency

Request Response

Time

Latency
Throughput

Throughput = # of
Request requests processed in
unit time

Time

Response

1 second
Jitter

Latency

Jitter

Request
Performance tactics

What are the causes that impact performance?


Performance tactics
Cause Tactic
Poor algorithm

Database retrieval is slow

Volume of data to be
processed is high
Number of concurrent users
is high
Performance tactics
Cause Tactic
Poor algorithm Improve search algorithm

Database retrieval is slow • Index data – Hash index, B+ tree index


• Partition data, De-normalize, etc.
• Run reports in night
• Maintain multiple copies of data
Volume of data to be Distribute data on multiple servers and parallelize data
processed is high processing (ex Map-Reduce)
Number of concurrent users Distribute requests to different servers and do load
is high balancing
How to improve performance
when # of users is very large?
• Load balancing: Distribute requests to different servers in a server
farm

Approaches

• Round robin
• Based on txn load
How to improve performance when multiple
users want to READ the same data?

Maintain multiple copies of data. This reduces contention. However we need to


keep them synchronized

Before After

Poor response due to large data and Replicated data enables load balancing
high volume txns
Example

• Supports the delivery of over 100 million videos per day.

• Most popular content is moved to a CDN (content delivery network):

• CDNs replicate content in multiple places. There's a better chance of content


being closer to the user, with fewer hops, and content will run over a more
friendly network.
CDN – Content Delivery
Network

No CDN CDN with multiple servers serving


neighbouring clients
How does Google Return
Results So Damn Fast?!?
• Search the index not the internet
• Direct the search to nearest datacentre
• Hundreds of computers in each data center perform distributed look up
• Store index in RAM instead of disk

Google Data
centers
① Source of stimulus. entity ( human, computer system, or any other actuator) that generated the stimulus
② Stimulus - condition that needs to be considered when it arrives at a system. Tactic is a design
③ Artifact: Some artifact is stimulated – whole system or parts; option for the
④ Environment: The stimulus occurs within certain conditions - Normal, safe mode, overload condition etc architect
⑤ Response: activity undertaken after the arrival of the stimulus.
⑥ Response measure: Measurable outcome, it should be measurable in some fashion so that the requirement can be tested.


Scenarios should cover a range of
• Anticipated uses of (use case scenarios), ②
• Anticipated changes to (growth scenarios), or ③
• Unanticipated stresses (exploratory scenarios) to the system.


Quality Attributes &Tactics
Identify the Quality attributes and Tactics
require to achieve them ⑥






① ⑥




Performance Scenario

1
Artifact: 2
System 3
Stimulus: Response:
Initiate Transactions 4
Transactions Are Processed
Environment: Response
Source: Normal
Users Measure:
Operation Average
Latency
of Two
Seconds

FIGURE 8.1 Sample concrete performance scenario


Experience sharing

Have you come across any performance issues?

How did you address them?


Modifiability

• Deals with the ease with which we can make changes to a system
Modifiability

• What tactics can we use to increase modifiability?


Modifiability

Tactics for Modifiability

• Reduce complexity – ex. smaller modules

• Encapsulate aspects that are likely to change – ex. interface to


external systems
(Information hiding)

• Increase cohesion & Reduce coupling


Reduce complexity

Weather forecasting

Process air
pressure data

Complex weather
forecasting module Weather
forecasting - Process
Master module Humidity data

Process
Temperature
data
Encapsulate things that are
likely to change
Interface to external Database technology may
systems may change change

Order
Fund xfer
processing
module
module

Interface to SBI Data access


bank layer

via internet

Oracle
SBI system External DBMS
system
Protect system from variations
Variation
Examples of variations: Example

Changes in business rules Income Tax rules, Pricing rules in


• Changes in business rules – IT rules, Pricing rules in airline?
airline change frequently
• Change
Change in business
in business process process – Need one more approval?
Need one more approval
• Changes in module interface – Need to interface with a different SMS
service provider?
• Adding
Changes newinterface
in module recipients Need
of notification of event
to interface with – New order event needs to
a different
be notified to TransportSMS module
serviceinprovider
addition to Fulfilment module
• Enhancing browser to handle new audio file format – such as mp3, wav, ..
Need to notify additional ‘New order’ event needs to be
recipients about an event notified to Order Fulfilment module
& Transport module
Enhancing browser to handle mp3, wav, …
new audio file format
Protect system from variations
Variation
Examples of variations: Example Tactic (Binding)

Changes in business rules Income Tax rules, Pricing rules in Rules engine (Deployment time)
• Changes in business rules – IT rules, Pricing rules in airline?
airline change frequently
• Change
Change in business
in business process process – Need one more approval?
Need one more approval Work flow engine, Configuration
• Changes in module interface – Need to interface with a different
files SMStime)
(Deployment
service provider?
• Adding
Changes newinterface
in module recipients Need
of notification of event
to interface with – New order
a different Adaptorevent needs
pattern totime)
(Build
be notified to TransportSMS module
serviceinprovider
addition to Fulfilment module
• Enhancing browser to handle new audio file format – such as mp3, wav, ..
Adding new recipients of ‘New order’ event needs to be Publish – Subscribe
notification of event notified to Order Fulfilment module (Deployment time)
& Transport module
Enhancing browser to handle mp3, wav, … Plugins (Deployment time)
new audio file format
Example of Rules engine

Book ticket
(Pax name,
Booking Reserva
profession, age, Flt#,
date, etc.) module tion DB

Web
server Determine ticket price
(profession, age, Flt#, date, etc)

Rules engine

Rules
DB
• All flights in the afternoon will have 5% discount
• Flights booked 3 months before will have 20% discount
• Senior citizens above 60 yrs will have 5% discount
• Defence personnel will get 10% discount
Exercise - RTO

Regional Transport Office (RTO) gave a project to Tata Infotech to develop a


software to manage the service they provide to citizens, namely issue of
driving license and registration of vehicles.

The requirement consisted of functional requirements such as application for


license, recording results of test, etc. and a few reports.

As the project entered the design stage, new requirements started coming in.
These consisted of many more reports. They also said that they may
require more reports in the future.

What architecture should be adopted in this scenario?


Exercise - RTO

Regional Transport Office (RTO) gave a project to Tata Infotech to develop a


software to manage the service they provide to citizens, namely issue of
driving license and registration of vehicles.

The requirement consisted of functional requirements such as application for


license, recording results of test, etc. and a few reports.

As the project entered the design stage, new requirements started coming in.
These consisted of many more reports. They also said that they may
require more reports in the future.

What tactic should be adopted in this scenario?

A module for generating ad-hoc reports which can generate a report based on
specification provided by the user, can address most of the reports. Some
examples of report generation tools are Ubiq, Zoho Analytics, BIRT, etc.
Exercise – Airline Loyalty
module
An airline is building a comprehensive flight information & reservation system. It has
several modules such as Flight planning, Flight schedules, Pricing, Reservations,
Departure control, Analytics, etc.

As the airline industry is very competitive, the airline foresees many new requirements
such as Loyalty card, etc. to come up in the future. The new modules to be built in the
future would most probably be dependent on existing modules. For example, the
Loyalty module will have to calculate Loyalty points based on flights undertaken by
the customer, which is an output of Departure control module.

What architecture approach should be take to address this?


Exercise
An airline is building a comprehensive flight information & reservation system. It has
several modules such as Flight planning, Flight schedules, Pricing, Reservations,
Departure control, Analytics, etc.

As the airline industry is very competitive, the airline foresees many new requirements
such as Loyalty card, etc. to come up in the future. The new modules to be built in the
future would most probably be dependent on existing modules. For example, the
Loyalty module will have to calculate Loyalty points based on flights undertaken by
the customer, which is an output of Departure control module.

What architecture approach should be take to address this?

Since new modules would require information from other modules, it is good idea to have
a common database which can be accessed by all modules. If information is needed
in real-time, one can adopt a Publish-Subscribe approach where all important events
taking place in different modules are identified and published to interested
subscribing modules
① Source of stimulus. entity ( human, computer system, or any other actuator) that generated the stimulus
② Stimulus - condition that needs to be considered when it arrives at a system. Tactic is a design
③ Artifact: Some artifact is stimulated – whole system or parts; option for the
④ Environment: The stimulus occurs within certain conditions - Normal, safe mode, overload condition etc architect
⑤ Response: activity undertaken after the arrival of the stimulus.
⑥ Response measure: Measurable outcome, it should be measurable in some fashion so that the requirement can be tested.


Scenarios should cover a range of
• Anticipated uses of (use case scenarios), ②
• Anticipated changes to (growth scenarios), or ③
• Unanticipated stresses (exploratory scenarios) to the system.


Quality Attributes &Tactics
Identify the Quality attributes and Tactics
require to achieve them ⑥






① ⑥




Modifiability Scenario

1
Artifact: 2
Stimulus: Code Response: 3
Wishes Change Made 4
to Change and Unit Tested
the UI Environment: Response
Source: Design
Developer Measure:
Time In Three
Hours

FIGURE 7.1 Sample concrete modifiability scenario


Experience sharing

Have you come across any situation where you had tough time
modifying the design to accommodate a requirement change?

Can you explain the situation? How did you address it?
Software Architecture
Architecturally Significant
Requirements
BITS Pilani Vijayarajan
Requirements

Architectures exist to build systems that satisfy requirements.


But, to an architect, not all requirements are created equal.
An architecturally significant requirement (ASR) is a requirement
that will have a profound effect on the architecture.
How do we find those?
ASRs and Requirements
Documents
An obvious location to look for candidate ASRs is in the
requirements documents or in user stories.
Requirements should be in requirements documents!
Unfortunately, this is not usually the case.
Why?
ASR

Many projects don’t create or maintain the detailed, high-quality


requirements documents.
Standard requirements pay more attention to functionality than
quality attributes.
Most of what is in a requirements specification does not affect
the architecture.
No architect just sits and waits until the requirements are
“finished” before starting work. The architect must begin
while the requirements are still in flux.
ASR from Business Goals

• In house use
• Use Only Open Source
• Align with Legacy Product
• Ahead of Competition
• Development to be outsourced
• Multi Generational Product Road Map
• Huge Number of customers
• International customers
• Deployed as SaaS Model
• Customer specific Configuration (ERP)
ASR from Quality Attribute
Scenarios
Discuss with Stake holders
Elaborate Requirements with Scenarios
Create Questionnaires based on Quality Attributes
ASR from Design Decisions

Architecture is the result of applying a collection of design decisions.


• Allocation of responsibilities - functional decomposition
• Coordination model - communication among functional modules
• Data model - Data representation
• Management of resources - CPU, Memory, Network Bandwidth
• Mapping among architectural elements - Allocation of data to
data-models, execution modules to processors
• Binding time decisions - through lifecycle / runtime / deployment
• Choice of technology

Look for Requirements that will affect theses design decisions


Software Architecture
Architecture Patterns #1

BITS Pilani Vijayarajan A


Contents

• Recap
• Architecture Patterns - 01
Assignment & Quiz 1
A1 - Build an Architecture for an App
• The App should at minimum include the technologies Web, Mobile, IOT,
cloud and analytics.
• Each team will select an application and get the approval of the TA.
• Duplication May not be allowed …
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic and get the approval of the faculty.
• Duplication may not be allowed.
• Final Paper should be submitted as per the agreed upon template and
schedule
Quiz 1 Ignore this Quiz related information… check the portals
Sunday 14th Feb - late evening after 6 PM; Block 45 minutes; 25 questions
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Importance of Quality
attributes & Tactics
• Functional requirements help us to define the modules
• Quality attributes help us to structure the system
Availability
Modifiability
Performance
Security
Usability
Interoperability
Scalability
Testability

Architecturally
significant
requirements
Power Screwdrivers

Context: power screwdrivers


Problem: don't work well with ordinary slot screws
• time wasted in trying to fit the screwdriver into the
slot;
• once you succeed, centrifugal force tends to make
the bit slide off the screw and into the workbench

Solution: Phillips Screwdrivers

Building Construction Example …


What is a Pattern

1. Addresses a recurring design problem


2. Documents existing, well proven design experience
3. Pattern identify and specify abstractions that are above the
level of single classes and instances or of components
Typically, a pattern describes several components, classes or objects,
and details their responsibilities and relationships, as well as their
cooperation.
All components together solve the problem more effectively that the
pattern addresses

Because patterns are (by definition) found repeatedly in


practice, one does not invent them; one discovers them.
What is a Pattern? Formal
Definition
An architectural pattern establishes a relationship between:
A context. A recurring, common situation in the world that gives rise to a problem.
A problem. The problem, appropriately generalized, that arises in the given
context.
A solution. A successful architectural resolution to the problem, appropriately
abstracted. The solution for a pattern is determined and described by:
• A set of element types (for example, data repositories, processes, and objects)
• A set of interaction mechanisms (ex: method calls, events, or message bus)
• A topological layout of the components
• A set of semantic constraints covering topology, element behavior, and interaction
mechanisms
Typically Represented as
• Overview
• Elements
• Relationship
• Constraints
• Weakness
Scope of the Lectures
• We will not discuss the Patterns in the formal definition / representation format
• That are covered in the book
Patterns & Tactics

• Tactics typically use just a single structure or computational


mechanism, and they are meant to address a single architectural
force.
• Patterns typically combine multiple design decisions into a
package. Tactics are the “building blocks” of design, from which
architectural patterns are created.
• Tactics are atoms and patterns are molecules.
• Most patterns consist of (are constructed from) several different
tactics.
• Patterns package tactics.
List of patterns

1. Layer
2. Pipe & Filter
3. MVC
4. Publish & Subscribe
5. Client & Server
6. P2P
7. Shared Data
8. Broker
9. Map-Reduce
10.Multi-tier
11.SOA
Layered pattern
Example: Architecture of Android

http://www.techotopia.com/index.php/An_Overview_of_the_Android_Architecture
1/26/21 SS ZG653 12
Layer Pattern

Context:
Complex systems, needs decomposition & independent evolution of
parts.
Problem:
Developers need a clear & well-documented way to implement
separation of concerns (focus)
Software needs to be segmented such that modules can be
developed and evolved separately with little interaction among
the parts, supporting portability, modifiability, and reuse.
Part of the system can be extended (evolution)
Stable interface among modules – defined by standards
OSI 7 layer model
Network Layering
3
Why Layering?!
Montreal London Paris
Alice wants to send
a mail to Bob and
a parcel to John.

Post Office
Alice drops off both performs final
at the same Post Office. delivery based
on the street and
personal names.

Post Office looks


at the addresses
( city names!!! )
and arranges for
proper transportation.

City A City B City C


15
1/26/21 By Vijayarajan
Network Layering
Why Layering?! (cont.) 4

No Layering • each new application has to be re-implemented for


every network technology!

Application Telnet FTP NFS HTTP

Transmission Coaxial Fiber Packet


Media cable optic radio

Layering • intermediate layer(s) provide a unique abstraction for


various network technologies

Application Telnet FTP NFS HTTP

Intermediate
layer

Transmission Coaxial Fiber Packet


Media cable optic radio

1/26/21 By Vijayarajan 16
Pipe and Filter Pattern

• Useful when we need to perform a number of transformations in a


sequence
• Data arrives at a filter’s input port(s), is transformed, and then is
passed via its output port(s) through a pipe to the next filter.
• A single filter can consume data from, or produce data to, one or
more ports.
Pipe and Filter Pattern

This architecture is useful when we need to perform a


number of transformations in a sequence
Context: Many systems are required to transform streams of
discrete data items, from input to output.
Problem: Such systems need to be divided into reusable, loosely
coupled components with simple, generic interaction
mechanisms.
In this way they can be flexibly combined with each other. The
components, being generic and loosely coupled, are easily
reused. The components, being independent, can execute in
parallel.
Example: Monitoring real time
events by cab operator
An App based cab operator (like Ola / Uber) wants to monitor real time
events and take appropriate action as follows:

a) If the cab deviates from the designated route and if the deviation is
significant, then we want to alert the passenger as well as the ops team
(inform via SMS)
b) If the customer presses the emergency button, we want to inform the
police and the ops team immediately (inform via SMS)

Using Pipe & filter pattern, draw an architecture diagram to implement the
above requirements. Indicate how the pipes and filters are used.
Example: Monitoring real time
events by cab operator
Pickup event Msg. to Ops team
Driver app Analyse delay

API Driver
event
handler Msg. to Ops team &
Cab location event Customer
Analyse
deviation Send
SMS

SMS Msg Q

Customer app

Emergency event
Customer Alert Ops
API
event team
handler Msg. to Ops team
Pipes & Filters: Applications
Applications where Pipes & Filters are useful
• Satellite signal processing – noise reduction, transformations
• Extract – Transform – Load (ETL) is a good fit for Pipes & filters architecture
• Real time recommendations to customer in ecommerce
Weakness
• Not good for interactive system
• More filters - Computational overhead
• Any failure can cause the entire pipeline to fail

Think about availability and Scalability !


Pipes & Filters
Model View Controller (MVC)
MVC framework utilizes • Handles data & business • Presents data to the user
component-based logic • Knows how to display
• independent of the GUI • Not responsible to store data
design approach where
• Does not know How to • when the model changes, the
components belong to present data view automatically redraws
one of 3 types.

Each component
supports an interface

Date Format

• Receives user requests, calls


appropriate modules and performs
business logic
• Specific to Application, least reusable
Model View Controller (MVC)
• Useful when we need different views of data

• Eg. Bar chart & Pie chart of data


Drivers for MVC

• User Interface Changes frequently


• the application displays the same data in different ways
• Skills Required to develop UI .vs. Business Logic
• UI is device dependent
• Test Automation UI vs Business Logic
MVC Exercise: For an eComm system, identify
1 component of each type – Model, View &
Controller

View components

Controller components

Model components
MVC architecture of eComm
system

View components

Product list Product detail Shopping cart Payment


Search screen
screen screen screen screen

Controller components

Find matching Get Product To payment gateway


Check out (..)
products (…) details (prod id)

Model components

Product Shopping cart Customer Payment


Publish-Subscribe Pattern

• Number of independent producers and consumers of data that


must interact.
• The precise number of producers, consumers, amount of data are
not predetermined or fixed
• integration mechanisms to transmit messages among the producers
and consumers who are unaware of each other’s identity
• Consumers subscribe to a set of events.
• Publisher place events on the bus by announcing them
• Connector delivers those events to the subscriber that have registered for those
events
Publish - Subscribe

• Components interested in knowing about events, subscribe to relevant


events
• Publisher place events on an Event bus
• Event bus delivers events to subscribers who have registered for those
events

Example of Topics in a stock exchange


• Change in share price
• Increase in volume of trading
Publish – Subscribe scenarios

• A process may subscribe to more than one topic / channel


• A topic / channel can be subscribed to by more than 1 process
Publish - Subscribe

Example

• Order creation event is subscribed to by Picking module, Transport module,


Loyalty module

Picking
module
New
Order order Transport
Event
module notifier module

Loyalty
module

Publisher Subscribers
Publish-Subscribe tools

• Amazon Simple Notification Service (SNS)


• MQTT (MQ Telemetry Transport) for IoT: Extremely lightweight
publish/subscribe protocol
Benefits of Publish-Subscribe

• Loose coupling between producer & consumer


• New listeners can be added without impacting producer
• Eliminates polling
Publish & Subscribe

Can you describe a scenario where you have used Publish-


Subscribe pattern?
Client-Server Patterns

35
Client-Server Architecture of Internet

36
1/26/21 SS ZG653 By Vijayarajan
Client-Server Pattern

• Access to shared resources and services


• Clients interact by requesting services of servers (central /
Distributed)
• Some components may act as both clients and servers. There may
be one central server or multiple distributed ones.
• By managing shared resources and services, we can promote
modifiability, reuse, scalability and availability
Client Server - Weakness

• Server can be a performance bottleneck.


• Server can be a single point of failure.
• Decisions about where to locate functionality (in the client or
in the server) are often complex and costly to change after a
system has been built.
Client - Server pattern

Useful when several clients want to access the services provided by the server

Examples
• Database server (accessed using ODBC)
• Mail server (MS Outlook)
• Web server (accessed using HTTP request)
Client server pattern: Example

Client PC Client PC Client PC

Containing Front Containing Front Containing Front


end software end software end software

ODBC

LAN

Server machine

Containing DBMS
software
Client server pattern: Example
Client PC Client PC Client PC

Browser Browser Browser

Web server

DB
Place Make
Login Search
order payment
Client-server pattern

Have you come across systems that use this pattern?


Client – Server pattern

Variants of client – server


• Earlier client server communication was synchronous

Now we have
• Asynchronous communication (using AJAX)
• Clients providing call back functions (ex. Javascript). Eg. Updating Live
cricket scores on a Cricket website or updating Live stock prices in a stock
exchange

Demerits

• Server can be a single point of failure


• Server can be a bottleneck
BitTorrent
3 Introduction to BitTorrent
BitTorrent is a technology/protocol which makes the distribution of files, especially large
files, easier and less bandwidth consuming for the publisher. This is accomplished by utilizing
the upload capacity of the peers that are downloading a file. A considerably increase in
downloaders will only result in a modest increase in the load on the publisher hosting the file.

Figure 4 – The basic flow of the BitTorrent protocol.

The illustration in Figure 4 shows the basic flow of BitTorrent. The figure on the left shows a
client-server approach to download. The peers download from the server simultaneous. If we
assume the upload capacity of the server is the same as the download capacity of a peer, the
time for the download to finish will be two times the time if only one peer where downloading
from the server. The figure on the right shows an approach similar to BitTorrent. By splitting
the file and send one part to each peer, and let the peers download the part they are missing
from each other, both download time and load on the server is reduced. Of course, the
BitTorrent protocol is much more sophisticated than this simple example, but this shows the
P2P

A peer-to-peer (P2P) architecture consists of a decentralized


network of peers - nodes that are both clients and
servers. P2P networks distribute the workload between peers,
and all peers contribute and consume resources within the
network without the need for a centralized server.
P2P Network

• Peers first connect to the P2P network


• They discover other peers they can interact with, and then
initiate connections
• Often a peer’s search for another peer is propagated from one
peer to its connected peers.
• A peer-to-peer architecture may have specialized peer nodes
(called super nodes) that have indexing or routing capabilities
and allow a regular peer’s search
P2P Search

Peer A requests for some data that Peer D and Peer H have. The
query will be broadcasted to the neighbors of Peer A, and
gradually, to the other peers in the whole network
2.3 Fully Decentralized P2P Systems 23

Fig. 2.3 Gnutella’s search


mechanism. Peer A requests
for some data that Peer D and
Peer H have. The query will
be broadcasted to the
neighbors of Peer A, and
gradually, to the other peers
in the whole network

other hand, as more and more nodes join the Gnutella network and the nodes is-
sue queries continuously, the network may be congested with floods of messages. 47
1/27/21 By Vijayarajan
and near to the node issuing the lookup. A simple routing process is illustrated in
Fig. 2.4.

P2P Communication
2.3.3.1 Properties

PAST has the following properties:


Peer 2331andissues
− Efficiency a querySince
cost of ownership. forPAST
a file on documents
assigns Peer 1233. Each time, the
to specific
nodes according to some predefined rules, the locations of a file are not totally
queryAsisa forwarded
random. result, the routingto
of aarequest
peercancloser to theIndestination.
be well directed. a steady Finally,
it will
PAST arrive
network, at Peer
all lookups can be1233
resolved in a number of hops at most logarith-
mic to the total number of nodes in the system. The property is valid even when

Fig. 2.4 PAST’s search


mechanism. Peer 2331 issues
a query for a file on Peer
1233. Each time, the query is
forwarded to a peer closer to
the destination. Finally, it will
arrive at Peer 1233

48
1/27/21 By Vijayarajan
P2P Application

Microsoft in Windows 10 uses a proprietary peer to peer


technology called "Delivery Optimization" to deploy
operating system updates using end-users PCs either on
the local network or other PCs. According to Microsoft's
Channel 9 it led to a 30%-50% reduction in Internet
bandwidth usage
P2P & Wireless Adhoc
Networks
Army uses Wireless Ad-hoc networks to share information between different entities in
the battle field.

The entities are on the move and there is no fixed network consisting of links and routers

Every node gathers information about the enemy and shares it with other nodes
Peer-to-Peer Challenges

Challenges
• Data consistency – Copies of data in different nodes might be out of sync
• Data & service availability – No central authority to ensure this
• Backup & Recovery – May be more involved, since there is no single source
from where to recover
Shared-Data Pattern

• Various independent computational components need to


share and manipulate large amounts of data.
• This data does not belong solely to any one of those
components.
• In the shared-data pattern, interaction is dominated by the
exchange of persistent data between multiple data accessors
and at least one shared-data store.
• Exchange may be initiated by the accessors or the data store.
Shared Data Weakness

• The shared-data store may be a performance bottleneck.


• The shared-data store may be a single point of failure.
• Producers and consumers of data may be tightly coupled.
Architectural patterns & tactics: captures proven design structures so that they can be reused; Described as {context, problem, solution }
• A context. A recurring, common situation that gives rise to a problem.
• A problem. The pattern describes the problem, its variants, any complementary or opposing forces. Also includes quality attributes that
must be met.
• A solution. The solution describes the architectural structures that solve the problem, including how to balance the many forces at work.
The solution for a pattern is described by:
• A set of element types (for example, data repositories, processes, and objects)
• A set of interaction mechanisms or connectors (for example, method calls, events, or message bus)
• A topological layout of the components
• A set of semantic constraints

No Style Problem Tactics QA - Strong QA - Weak Application

1 Layer

2 Broker

3 MVC
Pipe &
4
Filter
Client &
5
Server
Peer to
6
Peer
7 SOA
Publish &
8
Subscribe
Shared
9
Data
Map-
10
Reduce
11 Multi Tier
Shared data pattern

Database is the central piece

Different components share the database

The database supports


• Persistence
• Concurrent access Business
ERP CRM
Intelligence
• Fault tolerance
• Access control
• Distribution
• Caching

Shared data
Software Architecture

Architecture Patterns - 2
BITS Pilani Vijayarajan
Contents

• Recap
• Architecture Patterns - 02
Assignment & Quiz 1
A1 - Build an Architecture for an App
• The App should at minimum include the technologies Web, Mobile, IOT, cloud
and analytics.
• Each team will select an application and get the approval of the TA.
• Duplication May not be allowed …
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic and get the approval of the faculty.
• Duplication may not be allowed.
• Final Paper should be submitted as per the agreed upon template and schedule
Quiz 1
In the coming week. It will be available for 3 to 5 days. Wait for announcement in
Taxila
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Importance of Quality
attributes & Tactics
• Functional requirements help us to define the modules
• Quality attributes help us to structure the system
Availability
Modifiability
Performance
Security
Usability
Interoperability
Scalability
Testability

Architecturally
significant
requirements
What is a Pattern

1. Addresses a recurring design problem


2. Documents existing, well proven design experience
3. Pattern identify and specify abstractions that are above the
level of single classes and instances or of components
Typically, a pattern describes several components, classes or objects,
and details their responsibilities and relationships, as well as their
cooperation.
All components together solve the problem more effectively that the
pattern addresses

Because patterns are (by definition) found repeatedly in


practice, one does not invent them; one discovers them.
List of patterns

1. Layer
2. Pipe & Filter
3. MVC
4. Publish & Subscribe
5. Client & Server
6. P2P
7. Shared Data
8. Broker
9. Map-Reduce
10.Multi-tier
11.SOA
Service Oriented Architecture

Started as a means to integrate disparate applications of vendors & partners

SoA consists of:


• Business services deployed in a network
• Application components that make use these services
• Infrastructure to define services and communicate with services
Introduction

Systems that are built to change are more valuable


than systems that are built to last.

In reality, systems that are built to change are the


only ones that last.

2/5/21 By Vijayarajan 9
Banking Example –Process & Tech View

2/5/21 By Vijayarajan 10
Another Example

When a courier company makes the tracking of


shipments visible to its customers, increasing
customer satisfaction and reducing the costly
overhead of status enquiries

2/5/21 By Vijayarajan 11
Towards – SOA

If applications are built using reusable components


as building blocks, those applications are likely to
be more flexible to change and will last longer

2/5/21 By Vijayarajan 12
Services as reusable components

n Companies implemented the service concept at


the business level long before they used it in
software.
n Many business functions in a modern enterprise
are organized in the form of services

Services as reusable components Service oriented Architecture

2/5/21 By Vijayarajan 13
Definition of Service Oriented Architecture

n Service-Oriented Architecture (SOA) is a way of


designing, developing, deploying, and managing
systems, in which
q Services are reusable components that represent business or
operational tasks,

n Reusable is a key element of this definition because it is what


enables the creation of new business and operational
processes based on these services

2/5/21 By Vijayarajan 14
Business Centric SOA Event

IT’s Architectural Evolution: Making IT More Responsive

Pre 1950’s 1970’s to 1980’s to Mid 1990’s to Late


mid 1980’s mid 1990’s early 2000’s
Today
To 1960’s 1990’s

Sub-routines Enterprise
Remote Services
Monolithic /Remote Message Application
Object
Architectures Procedure Processing Integration (SOA)
Invocation
Calls (EAI)

Increasing Modularity to Achieve Flexibility

15 SOA on your terms and our expertise


SOA - Introduction

Service-oriented architecture (SOA) is an


architectural style for designing and developing
distributed systems

Business applications have evolved over a period of


time from a relatively rigid monolithic architecture to
an extremely flexible, distributed one
Data are Distributed
Computation is Distributed
Users are distributed

2/5/21 By Vijayarajan 16
Business Centric SOA Event

SOA: The Next Step on the Connectivity Evolution

Direct Message Message Service


Connectivity Queuing Brokering Orientation

Connectivity,
mediation & Connectivity logic
Lines of code

process-control
logic Connectivity and
Mediation & mediation logic
process-control Connectivity,
logic Process-control mediation & process-
logic control logic

Application Application Application Application


Services

All connectivity, Abstracts the Abstracts the Reduces application


mediation and connectivity connectivity + to its core business
additional logic logic from the mediation logic from functions
buried in the application the application (i.e. a service)
application

Increasing Modularity to Achieve Flexibility

17 SOA on your terms and our expertise


SOA

n A method of design, deployment, and management of


applications where:
q All software is organized into business services that are
network accessible and executable.
q Service interfaces are based on public standards for
interoperability.
n Services become building blocks that form business
flows
n Services can be reused by other applications

18
Business Centric SOA Event

A New Programming Model


Supporting the SOA Abstraction Layering
Traditional Software Development Service-Oriented Development

Business Expertise Business Expertise

Users Users
Define/refine Define/refine
business business
processes processes

Application
Limited Extensive Developers
Overlap Translate business
Overlap processes into
applications by
Service assembling and
configuring
Developers building blocks
Developers Create application
Program building blocks –
applications patterns,
using core templates, and
technologies components using
core technologies
Technical Expertise Technical Expertise

19 SOA on your terms and our expertise


integration of services (interface and implementation), service consumers, and the SOA infra-
structure. Each principle contains a short description and a table that explains the effects that each
Major elements of SOA
principle has on selected system quality attributes.

End User Internal External


Portal
Application System Consumer

Service Consumers

SOA Infrastructure Internet

Data
Security Discovery
Transformation
Infrastructure

Service Service Service Service


A B C D

Service Interfaces

Enterprise Legacy or New External


Information System Service Code System Service
Internal Users Implementation

Figure 2: High-Level Notional View of a Service-Oriented System

Architects of service-oriented systems often find themselves in a conflict. On one hand, there are
2/5/21 By Vijayarajan 20
business/mission goals and quality attribute requirements driving the architecture of a system. On
Service

n A service is a reusable component that can be used as a


building block to form larger, more complex business-
application functionality.
n A service may be as simple as “get me some person
data,” or as complex as “process a disbursement.”
n A service provides a discrete business function that
operates on data. Its job is to ensure that the business
functionality is applied consistently, returns predictable
results, and operates within the quality of service
required.

2/5/21 By Vijayarajan 21
WHAT CAN SERVICES DO?
• Perform business logic • Transform data
• Route messages
• Query databases
• Apply business policy
• Handle business exceptions
• Prepare information for use by a user interface
• Orchestrate conversations between multiple services

2/5/21 By Vijayarajan 22
Service Implementation / service interface

n Service Implementation is the actual code that


implements the capabilities
n ERP Systems, Custom developed code, Legacy
systems
n Service interface: Services are accessed via
standardized service interfaces that hide the
implementation details of the service from
consumers. The Service provider hosts a service
implementation

2/5/21 By Vijayarajan 23
Adapters

n Adapters make SOA possible.


n SOA is about being able to reuse the business
applications that you already have. In order to
do that, you need to add interfaces to these
applications that allow you to directly invoke
n The SOA adapters provide these interfaces.

2/5/21 By Vijayarajan 24
Service Consumers
n Service consumers are the clients for the
functionality provided by the services. Examples
of service consumers are end-users, internal
systems, external systems, and composite
services
Example:
n Tax Payers filing tax returns end users

n Stock analysis program accessing the “real time


stock price” service
n Adding “cash on delivery service” to an existing
e-commerce platform
2/5/21 By Vijayarajan 25
Service Registry, Discovery, Broker

Service discovery is the mechanism by which service consumers become aware of


available services and their capabilities; Discovered at runtime
Service providers publish their services in some form of service registry
Service broker is the component that actually makes all the connections between
components work.

Benefits – choose the right service – functionality, performance, and cost


Easier introduction of system upgrades – an upgraded service can be made available for
selection in parallel with the one that it replaces, which can then be withdrawn

2/5/21 By Vijayarajan 26
Service Invocation

n Services normally invoke each other by exchanging messages, even


where they are executing on the same processor
n enables loose coupling
q services can be moved (execution location)
q Services can be replaced by better one
q Improves configuration flexibility
n Message Monitoring
n Message control
n Message transformation
n Message Security

2/5/21 By Vijayarajan 27
tems, as shown in Figure 2. Because it is the most common technology pattern,
Web Services is often equated to SOA. Initially, Web Services were commonly

n,
Web Service
implemented using the WS* stack. More recently, an alternative called REpre-
sentational State Transfer (REST) has surfaced and is being widely adopted.
often
Class of System Distributed Systems

vices
Architecture Service-Oriented Peer-to-Peer
Pattern Systems Systems ….
g
the Technology
Pattern Web Services Broker Architecture ….
, an

ed Implementation WS*Web Services RESTful Web Services CORBA

ly Implemented using

Web Services is one


Figure 2: Web technology
Services pattern
in the Context of Distributedfor implementing service-
Systems
oriented systems, Because it is the most common technology
WS* Web Services
pattern, Web Services is often equated to SOA.
In the simplest implementation of WS* Web Services
• Service interfaces are described using Web Services Description Language
2/5/21 By Vijayarajan 28
(WSDL).
Few Technologies…

eXtensible The definition language that accompanies information. It


XML Markup tells the software what that information actually is
Language
Simple Object Uses XML to describe messages that are sent from one
SOAP
Access Protocol program / service to another.
Web Services XML document that describes a Web service - methods
WSDL Description (services) available; The parameters and data types; the
Language location of the Service and how to access it
Universal Registry of Web Services; (Yellow Pages, Searchable),
Description, Updated by Web Services providers; Information Stored as
UDDI Discovery, and WSDL
Integration UDDI itself is a Service, Accessed using SOAP
Consumer gets the Info on Services through UDDI
2/5/21 By Vijayarajan 29
Data- and
SOAP WSDLControl
- UDDI Flow indigoo.com
2. Web service architecture
The combo SOAP+WSDL+UDDI defines a general model for a web service architecture.
SOAP: Simple Object Access Protocol
WSDL: Web Service Description Language
UDDI: Universal Description and Discovery Protocol
Service consumer: User of a service
Service provider: Entity that implements a service (=server)
Service registry: Central place where available services are listed and advertised for lookup

The service consumer Service The service provider


looks up a suitable
Find
registry publishes its service with
service using Publish UDDI carried in
UDDI carried in Service
Service SOAP-messages.
SOAP-messages. UDDI Service
description UDDI
description
description
SOAP SOAP

Service interface
Service
WSDL
description
Service SOAP
consumer
The service consumer Service
binds to the service Bind
provider by sending
a SOAP-request. Service
provider
4/31
© Peter R. Egli 2015 Rev. 2.00

2/5/21 By Vijayarajan 30
Business Centric SOA Event

Service Oriented Architecture


Different Things to Different People
Roles

Capabilities that a business wants to expose as a Business


set of services to clients and partner organizations

An architectural style that requires a service provider,


requestor and a service description. It addresses
characteristics such as loose coupling, reuse and simple Architecture
and composite implementations

A programming model complete with standards, tools, Implementation


methods and technologies such as Web services

A set of agreements among service requestors and


service providers that specify the quality of service and Operations
identify key business and IT metrics

31 SOA on your terms and our expertise


Enterprise Service Bus

n An enterprise service bus (ESB) is the


infrastructure that enables high interoperability
between distributed systems for services. It
makes it easier to distribute business processes
over multiple systems using different platforms
and technologies.

2/5/21 By Vijayarajan 32
ESB - Services
n Messaging : provide intelligent content-based routing, and
guarantee delivery.
n Management : Monitor their own performance, helping to
n enforce SLA (latency).
n Interface : Can validate messages against schema and
provide application adapters
n Mediation : Transform messages between the formats
n Metadata : transform data from one format to another by
using metadata definitions.
n Security : Encrypt messages where needed; authorize,
authenticate, and audit all ESB activity.

2/5/21 By Vijayarajan 33
No SOA

n In a solution that does not require the integration


of components or systems running on different
platforms, or implemented using different
technologies, service orientation may be overkill
because there is an overhead for the use of
SOA technologies to provide interoperability
across platforms.

2/5/21 By Vijayarajan 34
No SOA

n Hard real-time systems are clearly not a good match for


service orientation. Strict timeliness requirements conflict
with several aspects of common technologies used in
service-oriented systems (e.g., web services) that may
introduce unbounded overhead in processing
n Embedded systems are not naturally fit to host service-
oriented systems. Embedded platforms have limited
computing power, memory, and disk resources. Many SOA
technologies are heavyweight in terms of memory and CPU
requirements. Thus, designing a SOA solution for the
software on a washing machine or a video-game console
can bring unneeded complication and overhead.

2/5/21 By Vijayarajan 35
SOA - additional Points

n Loose coupling: The consumer of the service is required to provide


only the stated data on the interface definition, and to expect only
the specified results on the interface definition. The service is
capable of handling all processing (including exception processing).
n Stateless: The service does not maintain state between invocations.
It takes the parameters provided, performs the defined function, and
returns the expected result. If a transaction is involved, the
transaction is committed, and the data is saved to the database.
n Location agnostic: Users of the service do not need to worry about
the implementation details for accessing the service. The SOA
infrastructure will provide standardized access mechanisms

2/5/21 By Vijayarajan 36
SOA

n Service-oriented architecture (SOA) is an


architectural style for designing and developing
distributed systems.
n From a quality attribute point of view, the primary
drivers for service orientation adoption are
interoperability and modifiability
n the top drivers for SOA adoption were mainly
internally focused: these top drivers generally
included application integration, data integration,
and internal process improvement.

2/5/21 By Vijayarajan 37
SoA : Travel company
Travel company’s application makes use of business services offered by partner systems such
as Airline, Lodging, Bank, etc.

OPC: Order processing


centre

Contains many application


components

Business services
SoA: Travel company – SoA
components
Does message
routing, format
Travel Company conversion,
application security check,
txn mgmt

Enterprise Service Bus

SOAP REST Message Queue

Service Orchestration Airline Lodging Banking


Registry server service service service

J2EE .Net .Net

Technologies used for connections:


Contains service • Web service standards using
Allows us to combine SOAP
definitions – service
services to create higher
name, request data, • Restful HTTP
level service
response data, location • Messaging such as JMS,
(end point), etc. and define workflows
RabbitMQ
Map-Reduce

2/5/21 By Vijayarajan 40
MAP REDUCE
• Invented by Google.
• Is a programming model for processing large datasets
• distributed on a large cluster.
• Uses the concept of Divide and Conquer.
• Two methods: map() and Reduce() .

• Map() sorting and filtering.


• Reduce() counting and produce Result.

2/5/21 By Vijayarajan 41
Map-Reduce Pattern
n Context: Businesses have a pressing need to quickly analyze
enormous volumes of data they generate or access, at petabyte
scale.
n Problem: The problem the map-reduce pattern solves is to
efficiently perform a distributed and parallel sort of a large data
set and provide a simple means for the programmer to specify the
analysis to be done.
Map-Reduce Pattern
n Solution: The map-reduce pattern requires three parts:
q A specialized infrastructure takes care of allocating software to

the hardware nodes in a massively parallel computing


environment and handles sorting the data as needed.
q A programmer specified component called the map which

filters the data to retrieve those items to be combined.


q A programmer specified component called reduce which

combines the results of the map


2/5/21 By Vijayarajan 44
Map-Reduce Solution - 1
n Overview: The map-reduce pattern provides a framework for
analyzing a large distributed set of data that will execute in
parallel, on a set of processors. This parallelization allows for
low latency and high availability. The map performs the
extract and transform portions of the analysis and the reduce
performs the loading of the results.
Map-Reduce Solution - 2
n Elements:
q Map is a function with multiple instances deployed across

multiple processors that performs the extract and


transformation portions of the analysis.
q Reduce is a function that may be deployed as a single

instance or as multiple instances across processors to


perform the load portion of extract-transform-load.
q The infrastructure is the framework responsible for

deploying map and reduce instances, shepherding the data


between them, and detecting and recovering from failure.
Map-Reduce Solution - 3
n Relations:
q Deploy on is the relation between an instance of a map or

reduce function and the processor onto which it is


installed.
q Instantiate, monitor, and control is the relation between

the infrastructure and the instances of map and reduce.


Map-Reduce Solution - 4
n Constraints:
q The data to be analyzed must exist as a set of files.

q Map functions are stateless and do not communicate with

each other.
q The only communication between map reduce instances is the

data emitted from the map instances as <key, value> pairs.


n Weaknesses:
q If you do not have large data sets, the overhead of map-reduce

is not justified.
q If you cannot divide your data set into similar sized subsets, the

advantages of parallelism are lost.


q Operations that require multiple reduces are complex to

orchestrate.
2/5/21 By Vijayarajan 49
Map-Reduce – Generic Explanation

n The Map step would run first, do computations in the input


key-value pair and generate a new output key-value.
n One must keep in mind that the format of the input key-value
pairs does not need to necessarily match the output format
pair.
n The Reduce step would assemble all values of the same key,
performing other computations over it.
n As a result, this last step would output key-value pairs

2/5/21 By Vijayarajan 50
Multi-tier pattern

• Tier is a physical unit, where the code / process runs. E.g.: client,
application server, database server;

• Layer is a logical unit, how to organize the code. ... Layers are the logical
groupings of the software components that make up the application or
service.

• All layers may reside on one server or can be distributed across multiple
servers

• Also all software components in a layer may run on server or can be


distributed across multiple servers

• Tier makes it easier to ensure security & optimize performance


Multi-Tier Pattern

• Context: In a distributed deployment, there is


often a need to distribute a system’s infrastructure
into distinct subsets.
• Problem: How can we split the system into a
number of computationally independent execution
structures—groups of software and hardware—
connected by some communications media?
• Solution: The execution structures of many
systems are organized as a set of logical
groupings of components. Each grouping is
termed a tier.

© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution
License
Logical Groupings or “Layers” of
SAP R/3 Components
The Presentation Layer
Those SAP R/3 software components that
specialise in interacting with end-users
form the Presentation Layer.

The Application Layer


Those SAP R/3 software components that
specialise in processing business
applications form the Application Layer.

The Database Layer


Those SAP R/3 software components that
specialise in the management, storage and
retrieval of data form the Database Layer

Bas2_01.53 What is Basis?


Three Tiered Client-Server
Architecture “Logical Layers”
Communication

The Presentation Layer


collects user input and
creates process requests.

The Application Layer


uses the application logic of
SAP R/3 programs to collect
and process the process requests.

The Database Layer


stores and retrieves all data.

Bas2_01.54 What is Basis?


Physical Distribution of
R/3’S Logical Layers

Presentation Layer Application Layer Database Layer


components components components

reside in: reside in: reside in:

Presentation servers: Application servers: Database servers:


Systems capable of Specialised systems Specialised systems
providing a graphical multiple CPUs and with fast and large
interface. vast amounts of RAM. hard drives.

Bas2_01.55 What is Basis?


Physical Distribution of R/3’S Three
Layered Client-Server Architecture
Presentation Layer components are installed across many PCs.

The Application Layer


components are installed
across one or more high-
end servers.

The Database Layer components


are installed on one high-end
database server.

Bas2_01.56 What is Basis?


Relationships Between Tactics and
Patterns
• Patterns are built from tactics; if a pattern is a
molecule, a tactic is an atom.
• MVC, for example utilizes the tactics:
– Increase semantic coherence
– Encapsulation
– Use an intermediary
– Use run time binding

© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Tactics Augment Patterns
• Patterns solve a specific problem but are
neutral or have weaknesses with respect to
other qualities.
• Consider the broker pattern
– May have performance bottlenecks
– May have a single point of failure
• Using tactics such as
– Increase resources will help performance
– Maintain multiple copies will help availability
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Tactics and Interactions
• Each tactic has pluses (its reason for being)
and minuses – side effects.
• Use of tactics can help alleviate the minuses.
• But nothing is free…

© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Tactics and Interactions - 2
A common tactic for detecting faults is
Ping/Echo.
Common side-effects of Ping/Echo are:
• security: how to prevent a ping flood attack?
• performance: how to ensure that the performance overhead
of ping/echo is small?
• modifiability: how to add ping/echo to the existing
architecture?
Tactics and Interactions - 3

System

Ping/Echo

Add to Ping Performance


system flood overhead
Tactics and Interactions - 4
A tactic to address the performance side-effect
is “Increase Available Resources”.
Common side effects of Increase Available
Resources are:
• cost: increased resources cost more
• performance: how to utilize the increase resources efficiently?
Tactics and Interactions - 5
System

Ping/Echo

Add to Ping Performance


system flood overhead

Increase Available
Resources

Resource
Cost
Utilization
Tactics and Interactions - 6
A tactic to address the efficient use of resources
side-effect is “Scheduling Policy”.
Common side effects of Scheduling Policy are:
• modifiability: how to add the scheduling policy to the existing
architecture
• modifiability: how to change the scheduling policy in the
future?
Tactics and Interactions - 7
System

Ping/Echo

Add to Ping Performance


system flood overhead

Increase Available
Resources

Resource
Cost
Utilization

Scheduling
Policy

Add to Modify
system policy
Tactics and Interactions - 8
A tactic to address the addition of the scheduler
to the system is “Use an Intermediary”.
Common side effects of Use an Intermediary
are:
• modifiability: how to ensure that all communication passes
through the intermediary?
Tactics and Interactions - 9
System

Ping/Echo

Add to Ping Performance


system flood overhead
Increase Available
Resources

Cost Resource
Utilization
Scheduling
Policy

Add to Modify
system policy
Use an
Intermediary

Ensure
usage
Tactics and Interactions – 10.
A tactic to address the concern that all
communication passes through the
intermediary is “Restrict Communication
Paths”.
Common side effects of Restrict Communication
Paths are:
• performance: how to ensure that the performance overhead
of the intermediary are not excessive?

Note: this design problem has now become recursive!


How Does This Process End?
• Each use of tactic introduces new concerns.
• Each new concern causes new tactics to be
added.
• Are we in an infinite progression?
• No. Eventually the side-effects of each tactic
become small enough to ignore.

© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Broker pattern

Broker is an intermediary software that provides certain services

Examples of Brokers:
• Load balancer
• EJB server
Broker pattern:
Example: Load balancer
Load balancer
• Distributes requests to different servers in a server farm
• Takes care of non-availability issues by switching to another server

Some algorithms used to distribute load are:

•Round robin
•Least connections

Load balancer vendors


• F5
• Citrix
Broker pattern

• Mediates between client and server to provide different kinds of services

• It adds a layer of indirection that may cause performance issues


• A broker can be a single point of failure and hence needs to be designed for
fault tolerance
• It can also be a target for security attacks
Software Architecture

Designing Architecture
BITS Pilani Vijayarajan
Contents

• Recap
• Designing Architecture #1 (will continue in the next class
also)
Assignment & Quiz 1
A1 - Build an Architecture for an App
• The App should at minimum include the technologies Web, Mobile, IOT, cloud
and analytics.
• Each team will select an application and get the approval of the TA.
• Duplication May not be allowed …
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic and get the approval of the faculty.
• Duplication may not be allowed.
• Final Paper should be submitted as per the agreed upon template and schedule
Assignment & Quiz 1
Quiz 1

The quiz will not be available until Sunday, 14 February 2021, 12:00 AM
This quiz will close at Sunday, 21 February 2021, 11:59 PM
20 Questions - 30 minutes
Once you start you should complete in 30 minutes….
Example:
Resynchronizing the state of a repaired component with the current state of
operation and then re-introducing this component is the tactic for improving
which of the following attribute.
A. Security
B. Performance
C. Testability
D. Availability
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Importance of Quality
attributes & Tactics
• Functional requirements help us to define the modules
• Quality attributes help us to structure the system
Availability
Modifiability
Performance
Security
Usability
Interoperability
Scalability
Testability

Architecturally
significant
requirements
What is a Pattern

1. Addresses a recurring design problem


2. Documents existing, well proven design experience
3. Pattern identify and specify abstractions that are above the
level of single classes and instances or of components
Typically, a pattern describes several components, classes or objects,
and details their responsibilities and relationships, as well as their
cooperation.
All components together solve the problem more effectively that the
pattern addresses

Because patterns are (by definition) found repeatedly in


practice, one does not invent them; one discovers them.
List of patterns

1. Layer 8. Broker
2. Pipe & Filter 9. Map-Reduce
3. MVC 10.Multi-tier
4. Publish & Subscribe 11.SOA
5. Client & Server
6. P2P
7. Shared Data
Reference Architecture
Web Application
278 .NET Application Architecture Guide, 2nd Edition

Go to Page 278

Microsoft Application Architecture Guide


Figure 1
The typical structure of a Web application
Mobile Application
.NET Application Architecture Guide, 2nd Edition

Go to page 371

Microsoft Application Architecture Guide


Figure 1
The typical structure of a mobile application
IBM Web Page for IOT
Amazon Reference Architectures - IOT
Designing the Architecture
– My Experience
Drivers for Architecture
Design
1. Design purpose – what we want to achieve
Proposal (mature / new domain)
Prototype (explore),
Development of new (Green Field Matured /Novel, Enhancements)
Development organizations future extension, scalability, re use, skill
set, technology etc
2. Quality Attributes – obvious – priority, utility tree (Page 307
book), biz importance vs technical risk / complexity
3. Functionality – 10% of uses cases are primary
Allocation of responsibilities - promote modifiability, usability
use case -> QA (Movie streaming application)
Drivers for Architecture
Design
4. Architectural concerns (not generally articulated, learnt over
experience)
General – Structure, module to teams, start / Stop, organization of
codebase, Delivery, deployment, Updates, server capacity
Specific – logging, authentication/authorization
Derived requirements – hierarchy of requirements; it has to work
in outdoors – temp range … transport
Issues: Things came up during the last review
Generally, results in additional Quality Attributes
5. Constraints
On which you don’t have control – schedule, team, backward
compatibility, tools, Compliance (industry, company)
Types of Systems

1. Design of Greenfield Systems for Mature Domains


iteration Focus How do we go about
Initial Overall System Reference Architecture; external components;
Deployment patterns; Best Practices
Primary Functionality Architectural patterns (domain objects); external
components
Refine & additional drivers Tactics; architectural patterns, deployment
patterns; external components

2. Design of Greenfield Systems for Novel Domains


Reference Architecture ? Patterns & Tactics can be used - Prototyping option
3. Design for an Existing System (Brownfield)
Extension, Refactoring, Many Constraints
Architecting… #1

Identification of Design Concepts


Design Decisions - Selecting the Design Concept
Design Concepts

The Building Blocks for Creating Structures


Where do they come from:
Proven methods, reference architecture, Patterns, tactics,
externally developed components - products (SQL DB), library,
framework, Platform (java, .net)
Past experience, Best Practices, Expert Knowledge
For a specific problem, one will combine different types of
design concepts. For example, for security driver, one can use
a security pattern, a tactic, a framework, or some combination
of these.
Look at alternatives…
Design Decisions

Design Process is making Decisions


Making decision is a Process
Make Candidate Decisions (Critical step)
choose one among them after (preliminary, High level) analysis
– Layers - how many layers, communication, distribution of responsibilities
– Cluster - how many servers, load balancers, physical location, network
connectivity
Architecting … #2

Produce the Structure (Module, C&C, Allocation)


– Instantiating Elements (may require customization?)
– Associating Responsibilities
– Establishing Relationships Between the Elements
Defining Interfaces
– External Interfaces (could be a constraint, standard)
– Internal Interfaces (sequence Diagram, Control & Data flow)
Preliminary Documentation

Recording Sketches of the Views


Recording Design Decisions
Iterate

Tracking Design Progress


Use of an Architectural Backlog
Attribute-Driven Design
Purpose , Quality Attributes , Functionality, Architectural concerns , Constraints

1. Review Inputs
2. Establish iteration Goal - Selecting drivers
3. Choose one or more elements of system to refine
4. Choose design concept(s) that satisfy the drivers
5. Instantiate the architecture, allocate responsibilities and
define interfaces
6. Sketch views to record design decisions
7. Analyze the current design against the iteration goal - refine
Iterate …
Software Architecture

Designing an architecture
BITS Pilani Viswanathan Hariharan
Edited by Vijayarajan
Contents

• Recap
• Designing Architecture #2 (part 1 was covered in the last
session)
• Documenting the architecture
• Architecture Evaluation - ATAM Method
Assignment & Quiz 1
A1 - Build an Architecture for an App
• The App should at minimum include the technologies Web, Mobile, IOT, cloud
and analytics.
• Each team will select an application and get the approval of the TA.
• Duplication May not be allowed …
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic and get the approval of the faculty.
• Duplication may not be allowed.
• Final Paper should be submitted as per the agreed upon template and schedule
Assignment & Quiz 1
Quiz 1

The quiz will not be available until Sunday, 14 February 2021, 12:00 AM
This quiz will close at Sunday, 21 February 2021, 11:59 PM
20 Questions - 30 minutes
Once you start you should complete in 30 minutes….
Example:
Resynchronizing the state of a repaired component with the current state of
operation and then re-introducing this component is the tactic for improving
which of the following attribute.
A. Security
B. Performance
C. Testability
D. Availability
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Importance of Quality
attributes & Tactics
• Functional requirements help us to define the modules
• Quality attributes help us to structure the system
Availability
Modifiability
Performance
Security
Usability
Interoperability
Scalability
Testability

Architecturally
significant
requirements
What is a Pattern

1. Addresses a recurring design problem


2. Documents existing, well proven design experience
3. Pattern identify and specify abstractions that are above the
level of single classes and instances or of components
Typically, a pattern describes several components, classes or objects,
and details their responsibilities and relationships, as well as their
cooperation.
All components together solve the problem more effectively that the
pattern addresses

Because patterns are (by definition) found repeatedly in


practice, one does not invent them; one discovers them.
List of patterns

1. Layer 8. Broker
2. Pipe & Filter 9. Map-Reduce
3. MVC 10.Multi-tier
4. Publish & Subscribe 11.SOA
5. Client & Server
6. P2P
7. Shared Data
Reference Architecture - Microsoft, AWS, IBM
Attribute-Driven Design
Purpose , Quality Attributes , Functionality, Architectural concerns , Constraints

1. Review Inputs
2. Establish iteration Goal - Selecting drivers
3. Choose one or more elements of system to refine
4. Choose design concept(s) that satisfy the drivers
• Proven methods, reference architecture, Patterns, tactics, externally developed
components - products (SQL DB), library, framework, Platform (java, .net), Past
experience, Best Practices, Expert Knowledge
• For a specific problem, one will combine different types of design concepts
• Making decision is a Process, Make Candidate Decisions then refine
Attribute-Driven Design
Purpose , Quality Attributes , Functionality, Architectural concerns , Constraints

5. Instantiate the architecture, allocate responsibilities and


define interfaces
6. Sketch views to record design decisions
7. Analyze the current design against the iteration goal - refine
Iterate …
Example: Judiciary system
Step 1: Choose an element

• Since we are designing a new system, the entire system is our element
Business / Mission presentation by sponsor
Example: Judiciary Management System

Business Mission Functional Non functional


• To speed up the requirements requirements
settlement of court cases

Motivation • Filing case • Security of info.


• Scheduling • No deletion
• Huge backlog
• Record court • Logging
• Complex process proceedings
• Record
User categories judgements
• Judges,
• lawyers,
• court staff and
• citizens
Scenario brainstorming - snapshot

Judge:
• The proceedings should not be lost or tampered with, by unauthorized
people, including those working in the court (Security)

Court staff
• Proceedings will consist of text, photos, images & videos (Store pictures)

Citizen
• The system should clearly indicate the steps to file a case (Ease of use)

Lawyers
• I should be notified when the proceedings are posted (Notification)
Scenario refinement & elaboration

Scenario: The proceedings should not be lost or tampered with by


unauthorized people, including those working in the court

Scenario Refinement & Elaboration


• Proceedings once recorded should not be lost even in case of disk crash
• Proceedings can be viewed by concerned lawyers, judge and court staff
• Only judge can modify the proceedings and these changes should be logged
Utility tree: Understanding business value &
Impact on architecture - snap shot
Quality Attrubute Scenrario Business Architect
attribute refinement value ure
impact
Security Integrity The proceedings should not be lost or tampered with by unauthorized High High
people, including those working in the court (1)
Usability Workflow Once the staff enter the proceedings, it should come to the concerned judge High High
for review, changes and approval (3)
Modifiabil Criteria The cases should be intelligently scheduled considering the age of the case, Medium Medium
ity specification criticality, etc. (4)
Interopera Status The system should send notification to the concerned lawyer and parties High High
bility notification when hearings are scheduled (5)
Performan Response time Proceedings will consist of text, photos, images & videos (b) Medium Medium
ce
Usability Understanding Information can be categorized as evidence, arguments, facts, etc. System High Low
user model should aid in the entry of such information and make the data entry
efficient (2)
Usability Intuitiveness Registering a case should be very easy (2) High Medium
Interopera Status I should be notified about the hearing date (5) High High
bility notification
Usability Understanding I should be able to upload documents (2) High Low
user model
Interopera Status I should be notified when the proceedings are posted and I should be able High High
bility notification to view them in chronological order (2)
Usability Intuitiveness I should be able to file affidavits and petitions online (2) High Low
Architectural drivers
Presented by architects & refined by stakeholders

Architect’s understanding of architectural drivers (based on discussion


with sponsor):
1. Security of information
2. Easy to use
3. Work flow management
4. Scheduling of cases
5. Alerts & notifications

Comments by stakeholders (Judges, Lawyers, Court Staff and representative


citizens)
a. Easy to search a case (elaboration of 2)
b. Store pictures & scanned documents and link them to a case
c. Ability to highlight important aspects in proceedings (elaboration of 2)
Identify the ASRs for the element - snap
shot

The critical ASRs of the system are:


• Security: No tampering
• Usability: Workflow, Notification, Intuitiveness
• Send Notification
Generate a design solution for the
element
Quality
Scenario (ASR) Tactics
Attribute
Assign access privileges to different types of users
The proceedings should not be lost or such as Judges, Court staff, Lawyers, Citizens
tampered with by unauthorized
Security Encrypt critical data, such as passwords, in the DB
people, including those working in
the court Store data on a separate database server and protect
the server using a second firewall
Once the staff enter the proceedings,
it should come to the concerned Include a workflow engine that allows
judge for review, changes and configuration of process steps (Defer binding)
Usability approval
1. Use words that are easy to understand.
Registering a case should be very
2. Provide menu option for different user activities
easy
(Understand User’s mental model)

The system should send notification


Interopera Interface with SMS gateway of telecom service
to the concerned lawyer and parties
bility provider
when hearings are scheduled
High level architecture

Citizens & Lawyers

Judges, Court staff

LAN
Firewall

Court management
system
Now let us try to address the
ASRs
Security of data

Court management
system
Allows only the
Court management
Firewall system to access
the database

Separate DB server Only authorized


to protect data from users can access
being accessed by
DB server data
outside world
Sensitive data such
as judge’s notes
are encrypted
Now let us try to address the
ASRs
Workflow

Court management system

Case Case Case Case


creation scheduling proceedings judgement
Passes work to
next step based
Workflow engine on work flow
configuration

Firewall

DB server
Now let us try to address the
ASRs
SMS notification

Court management system


Airtel Airtel SMS
adaptor system
Case Generic
scheduling SMS client
Vodafone
Vodafone
SMS
adaptor
system

Firewall

DB server
Putting it all together
Citizens & Lawyers

Judges, Court staff

LAN

Firewall

Court management system


Case Case Case
Case Airtel Airtel SMS
scheduli proceedi judgem
creation adaptor system
ng ngs ent Generic
SMS
client
Vodafone Vodafone SMS
Workflow engine adaptor system

Firewall

DB server
Verify & refine requirements and
generate input for next iteration

A. Verify:
• Implement and test if it works as expected

B. Refine requirements:
– Sometimes expectations can not be met. In such cases the requirements may
have to be refined in consultation with stakeholders
– Ex. In eCommerce system if Analytics group wants every user action to be
logged and if this is severely impacting response time, we can discuss with
stakeholders to understand what is critical to be logged and what need not be
logged.

Have you come across any situation where you could not
meet a requirement and had to discuss with
stakeholders to modify the requirement?
Verify & refine requirements and
generate input for next iteration

C. Generate input for next iteration:


– When you implement the design, new elements might be introduced.
For example, while designing access control for users, we may decide to use a
central access control component, which already exists in the organization. It is
possible that based on our requirements, the existing access control module
may have to be enhanced.
Example: Architecting one module

Module: Proceedings &


evidences
Data mirroring
• Replicate data
• Create roles and access
privileges
• Usability enablers Business layer Proceedings &
• Automatic spell checks
Evidences
• Search keywords
• Highlighter
• Timestamp for viewing in Spell
chronological order Search
checker
Technical services
layer Highlighter
Example: Architecting one module

Module: Database

1. Disk mirroring
2. 2nd firewall to protect
from accessing the
database directly from
outside the network
Example architecture
Client Client
Browser Browser HTTPS

Firewall

Web server / App Server


Method invocation
Case Proceedings Evidences
mod. module module
Technical Business
services services

Scheduling Judgement
RESTful APIs
module module

Data access Workflow SMS gateway


SMS client
module engine (Telco)
Firewall
JDBC

Mirroring Encrypted passwords


Maxio - Robotic System
Software Architecture

Documenting architecture
BITS Pilani Viswanathan Hariharan
Contents

• Introduction
• Different architectural views
• Combining different views
• Documentation package
Introduction

Importance of documenting architecture

Communication
Basis for evaluation
vehicle
Architects, sponsor, Analyse how well the
business managers, end architecture meets the
users, developers, testers quality attributes
Different architectural views

• Architecture of a large system can be complex

• We may not be able to understand the system with just


one diagram

• We may need different types of diagrams to understand


different aspects such as structure and behaviour
Different views of human body
Different views of human body

Blood
Skeletal view Digestive system circulation Nervous system
system

Can we understand the human body with just one diagram?


Different views of human body

Cavities of the body Detailed view of heart Detailed view of brain


Example: Magic Bricks.com

Have you observed the several photos they show about the house to
get a good idea about the house ?
3 types of architecture views

• Module view: Shows structure consisting of different modules and


sub-modules

• Component & Connector view: Shows how the different


components interact

• Allocation view: Shows where the components reside


Module view of ERP system
Module decomposition view

ERP system

Finance Marketing Production

Market
Accounting Budgeting Audit Advertising Planning Inventory
research
Module view of Judiciary
system
Module decomposition view

Judiciary
system

Business Technical
modules modules

Proceedin Schedulin Judgemen


Case Evidences
gs g t

Data Workflow SMS


access engine Client
Module view: Uses style

If we want to develop admin.client, we need to also develop admin.core, dao and util
Benefits of Module view

What are the benefits of Module view?


Benefits of Module view

What are the benefits of Module view?

• It gives an idea about the scope of construction


• Plan incremental development
• Requirement traceability
Module documentation -
Examples
Name: Inventory module

Responsibilities:
• Maintain quantity in stock of different items
• Handles inventory transactions
• Automatically generate request when quality goes below reorder level

Interface provided:
• Issue inventory (Item code, quantity) Returns Success or Error code
• Receive inventory (Item code, quantity) Returns Success or Error code
• Inquire quantity in stock (Item code) Returns quantity
Module documentation -
Examples
Name: Proceedings

Responsibilities:
• Maintain information about proceedings of different cases
• Logs changes

Interface
• Add proceedings (Case code, Date, Text)
• Retrieve proceedings (Case code, Date) Returns Text of procedings
Module documentation -
Examples
Name: Workflow engine

Responsibilities:
• Maintains workflow graph consisting of sequence of tasks for a process
• Maintains information about pending tasks
• Alerts users of their pending tasks

Interface
• Define task (Task name, Task description, Previous task name, User types
who can perform this task)
• Add task instance (Task name, Id of User who should perform this task)
returns Task Id
Exercise: Module
decomposition
Draw the module decomposition view of Departure Control System
Component & Connection
view
• Shows how components interact
C&C View: ATM example

ATM

Bank server
C&C View: Example

Notification
messges Picking
module
New
Order order
Event
Transport
module dispatcher module

Loyalty
module

The Order module publishes the event of new order creation.


This event is notified to all entities who have subscribed for the event type ‘New
order’
(Publish-Subscribe model)
Component & Connector view

• Components examples: Packages, Objects, Processes, Databases,


Webserver, Load balancer, Firewall, Off-the-shelf packages

• Think of other examples of other components?

• Connector examples: Method invocation, message, REST, HTTPS,


FTP, sFTP, RMI, …

• Think of examples of other connectors?


Types of connections

• Data access module – Database : JDBC


• SMS Client – SMS Gateway : REST
• Client – Webserver : HTTP
• Order module – Other modules : Message queue
• Communication over network : Socket
• Secure communication : Secure sockets

• Process synchronization : Semaphores


– Ex. When DB connections should not exceed a certain #
Inter-process communication
mechanisms
• Message queues: Multiple processes can write to & read from message
queues (Examples: Simple message queue from Amazon, MQ Series from
IBM)

• Socket programming: A data stream sent over a network (TCP / IP)

• Semaphores: Used for process synchronization. Example when we have


limited DB connections to be shared among several processes.
Exercise

Draw the C & C view of Departure Control System


C & C view: Uses
What are the uses of C&C view?
C & C view: Uses
C&C view helps us to
• Understand how system works
• Analyse reliability, performance, security, etc.

Examples of analysis of architecture:


• A system uses SMS gateway. Upon analysis we discover that the SMS gateway
is unreliable and goes down a few times in a day. Then we may want to revise
the architecture to store unsent messages in a queue and then retry after some
time

• A system imports critical data from a service provider such as Dow Jones using
FTP. Upon analysis if realize that data is not encrypted, we may consider S-FTP
(Secure FTP protocol)

• A real-time system has too many layers. If performance is likely to be impacted,


we may think of combining some layers into one layer
Allocation view

• Shows where the modules / components reside


Deployment view: Example
Client Client
Browser Browser

Firewall

Load Balancer
Server cluster / farm

Web server / App Server Web server / App Server Web server / App Server

Generic
Get case Get case Proceedings Scheduling
File case File case SMS
status status module module client

Firewall

Multiple
Primary Backup
servers
dedicated for DB DB
case module server server
Exercise: Deployment view

Draw the Deployment view for Departure Control System


Allocation view

• What is the use of allocation view?


Allocation view

• Useful to analyse performance, security, availability, etc.


Different views

• Module view
• C&C view
• Deployment view

Have you used any other ways to document the


architecture?
Exercise
What type of view is this? Justify
Exercise

What can we know about


the system from this
diagram?
Exercise

It allocates components to
servers and shows the
dependencies between the
components. It’s often useful
to label the dependencies with
a name that indicates the
protocol that is used to
communicate between the
components. For example, the
OrderProcessing executable
component requires JDBC1 to
access the NewOrders table in
the OrdersDB database.
Exercise

What can we know


about the system
from this
diagram?
Exercise

structural view of the


order processing system
architecture
Sequence Diagram
Sequence Diagram
Sequence diagrams are probably the most useful technique in the UML for modelling the
behaviour of the components in an architecture. Although it is possible to represent loops
and selection in sequence diagrams, they quickly become hard to understand and
unwieldy to create
Quality attribute views
Apart from structural views, we can have other views to explain the architecture
to achieve specific quality attributes

• Security view: Shows different types of security measures such as


encryption, protocols, certificate servers, VPN, firewalls

• Communication view: Shows different communication aspects


• Type of network such as private and public networks,
• Medium of communication such as LAN, broadband and satellite communication,
• Communication protocols such as TCP/IP sockets, HTTP,
• Message formats such as XML, JSON,
• Communication mechanisms such as message queues, file transfers, publish-subscribe

• Reliability view: Shows mechanisms used to implement reliability such as


replication, switch over
Security view: What are the security
arrangements in the system?
Citizens & Lawyers

Firewall allows only Judges, Court staff


case creation & case
inquiry requests LAN

Firewall

Court management system


Case Case Case
Case
schedulin proceedin judgeme
creation
g gs nt

Only authorized
Airtel
Generic Airtel SMS
users
adaptor can accesssystem
Workflow engine SMS
client data
Vodafone Vodafone SMS
adaptor system
Sensitive data such
Firewall allows only Firewall
as judge’s notes
Backend servers to
are encrypted
connect to DB server DB server
Combining view

Many a times we need to combine views – Module view, C&C view and
deployment view

This is useful to answer stakeholder concerns or queries and explain


how the system works to address their needs
Combining views: How does the system
ensure that login activity is secure?
Client
Browser
HTTP / SSL (encrypts
user id & password)
Firewall

Load Balancer

Web server / App Server

Login Data access


module modules

Firewall

Primary Backup Passwords are


DB DB encrypted and
server server stored
Combining views: How does
sending SMS work?
Citizens & Lawyers

Judges, Court staff

LAN

Firewall 1 Request to schedule cases

Web server / App Server

2 Request to schedule cases


4
Case Request to send SMS to a set of #s Generic Airtel Airtel SMS
scheduling SMS adaptor system

module client Vodafone Vodafone SMS


adaptor system

Request to get mobile # of


Firewall
3 lawyer and parties
involved, from the DB
DB server
Combining views: How does the system
handle the large volume of case filing and
status requests from citizens?
Client Client
Browser Browser

Firewall

Load Balancer
Server cluster / farm

Web server / App Server Web server / App Server Web server / App Server

Generic
Get case Get case Proceedings Scheduling
File case File case SMS
status status module module client

Firewall

Multiple
Primary Backup
servers
dedicated for DB DB
case module server server
Exercise: Views - DCS

• Draw a view to explain what happens when an airline staff asks the
system to stop booking. How is Reservation system notified about
it?
Exercise: Views - DCS

• Draw a view to explain to the business manager, how the system


makes available the ‘boarded passengers data’ to other systems?
Philippe Kruchten’s 4+1 view

Ref: Architectural Blueprints—The “4+1” View Model of Software Architecture by Philippe Kruchten, IEEE Software Nov 1995 4 plus 1 views
Exercise

What kind of view is this?


Combined View

The Observe and React pattern (Figure in the previous slide ) is a pattern that is
commonly used in monitoring systems.
The values of sensors are observed and when particular values are detected,
the system reacts in some way.

Monitoring systems may be composed of several instantiations of the Observe


and React pattern, one for each type of sensor in the system.

Depending on the system requirements, you may then optimize the design by
combining processes (e.g., you may use a single display process to display the
information from all of the different types of sensors).
Documentation
package
Documentation package: Example

Section 1: Primary presentation

Client Client

Firewall

Case Proceedings Evidences


mod. module module
Business
services

Scheduling Judgement
module module
Technical
services

Data access Workflow SMS gateway


SMS client
module engine (Telco)

Firewall

Mirroring
Documentation package: Example
Section 2: Element catalogue

1. Name: Proceedings
Responsibilities:
• Maintain information about proceedings of different cases
• Allows entry by court staff and verification by judge
• Can retrieve linked evidences and documents
• Logs changes
Interface
• Add proceedings (Case code, Date, Text)
• Verify proceedings (Case code, Date)
• Retrieve evidences (Case code) Returns List of evidences

2. Name: SMS Client


Responsibilities:
• …
Interface
• ---
Sample context diagram
Departure Control System (DCS) in an airport and related entities

Passenger Boarded
list passenger
list

No-fly passenger
list
Documentation package: Example

4. Variability guide
• To switch to a different telecom service provider, switch the adaptor
(SMS client module) using configuration file
• To switch from Oracle to My SQL in the future, use features common
to all R-DBMS

5. Rationale
• Disk mirroring: This is to provide high availability when a disk fails
• Load balancer: This is to provide satisfactory performance when
number of users is large
• 2nd firewall: This is to protect the data from hackers
• In some cases we document alternate designs and why picked one
Exercise
For the Departure Control System

• Draw the Module decomposition view

• Draw the architecture views to show Communication mechanisms used in


different parts of the system
Software Architecture

Architecting for the Cloud


BITS Pilani Viswanathan Hariharan
Contents

• Assignment 1 & 1
• Recap
• Architecting for Cloud
Assignment
A1 - Build an Architecture for an App
• The App should at minimum include the technologies Web, Mobile, IOT, cloud
and analytics.
• Each team will select an application.
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic
• Final Paper should be submitted as per the agreed upon template and schedule
Refer to the template for Assignment #1
Assignment - 2 Sampe
1. Performance - at least 3 popular applications Guidelines
2. Scalability - at least 3 popular applications ● You are not building an architecture
3. Facebook - scalability ● You are studying what is happening
4. Agile and Architecture around
● You must read many papers / case
5. Micro Services
studies
6. Uber / Ola etc ● You can do a Literature survey
7. Architecture For IOT paper
8. Architecture For Mobile ● Key words
9. Architecture For Machine Learning • Study
10. Architecture for Conferencing Platform • Analyze strengths / weakness
11. AWS Lambda • Compare

12. Architecture and NoSql DB • Trend - what is driving the

13. Architecting for cloud - trends trends


14. Compare cloud - Amazon / Azure / Google • Abstract
• Intro
15. YouTube / Netflix
• Scope / objective
• Contents
Assignment - 2 Guidelines
Guidelines Guidelines for the paper
● You are not building an architecture • Intro
● You are studying what is happening • Scope / objective
around • Contents
● You must read many papers / case • References
studies
● You can do a Literature survey paper
● Key words
• Study
• Analyze strengths / weakness
• Compare
• Trend - what is driving the trends
Evolution of SW Architecture

We design and implement information systems to solve problems and


process data.
As problems become larger and more complex and data becomes
more voluminous, so do the associated information systems
– Structured programming, Data Structure, Higher Level languages,
software engineering, Object Oriented etc
Computing become Distributed, on the cloud, Mobile as a front end
As the problem size and complexity increase, algorithms and data
structures become less important than getting the right structure for
the information system.
Specifying the right structure of the information system becomes a
critical design problem itself

< Example from Construction Industry>


Importance of Quality
attributes & Tactics
• Functional requirements help us to define the modules
• Quality attributes help us to structure the system
Availability
Modifiability
Performance
Security
Usability
Interoperability
Scalability
Testability

Architecturally
significant
requirements
What is a Pattern

1. Addresses a recurring design problem


2. Documents existing, well proven design experience
3. Pattern identify and specify abstractions that are above the
level of single classes and instances or of components
Typically, a pattern describes several components, classes or objects,
and details their responsibilities and relationships, as well as their
cooperation.
All components together solve the problem more effectively that the
pattern addresses

Because patterns are (by definition) found repeatedly in


practice, one does not invent them; one discovers them.
Patterns

1. Layer 8. Broker
2. Pipe & Filter 9. Map-Reduce
3. MVC 10.Multi-tier
4. Publish & Subscribe 11.SOA
5. Client & Server
6. P2P
7. Shared Data

Reference Architecture - Microsoft, AWS, IBM


Attribute-Driven Design
Purpose , Quality Attributes , Functionality, Architectural concerns , Constraints

1. Review Inputs
2. Establish iteration Goal - Selecting drivers
3. Choose one or more elements of system to refine
4. Choose design concept(s) that satisfy the drivers
• Proven methods, reference architecture, Patterns, tactics, externally developed
components - products (SQL DB), library, framework, Platform (java, .net), Past
experience, Best Practices, Expert Knowledge
• For a specific problem, one will combine different types of design concepts
• Making decision is a Process, Make Candidate Decisions then refine
Architecting

1. Judicial system Case Study for building the Architecture


2. Documenting the Architecture
3. ATAM - Tradeoff Analysis Method
Architecting for the Cloud

Intro to Cloud
– Definition
– Virtualization
– Architecting for cloud - what is the difference
– Multi Tenancy
Cloud Definition

NIST
Cloud Definition

NIST
Why Cloud

• Soon a corporate with a ‘no-cloud’ policy will be as rare as a


‘no-Internet’ policy is today.
• Cloud is a Vehicle for agile, scalable and elastic solutions
• Cloud: Cost scales with use and enables deferred spending

Core Technology - Virtualization


Virtualization #1

Java Virtual Machine ??


Virtualization #2
Virtual Memory Management with Page Tables
Virtualization #3
Multi Programming
Virtualization #4

Think of Multi Programming with Memory Management


Virtualization #5

Hardware Abstractions - Computer with various configurations


Virtualization #6

A virtual machine consists of several files that are stored on a storage device. The key files are
the configuration file, virtual disk file, NVRAM setting file, and log file
Both Data and Executable code - OS & VM tools (Device drivers etc)

It is a Software Computer -
Roughly equivalent an OS Image in a computer…
When instantiated on a physical Hardware it behaves like a computer on which One can run
applications…
Software Architecture

Mobile application architecture


BITS Pilani Vijayarajan
Architecting Mobile applications
Can you give some examples of mobile apps?
Mobile applications

Examples

• Uber
• Swiggy
• Courier delivery
• eCom
• Banking
• Spotify
• Where Is My Train
• …
Mobile Application: Design
considerations
• Simple User interface: Easy to type, Large buttons, Minimal
features, menu options, actions

• Responsive design: Adapt to different screen sizes & orientations

• Compact code: Less usage of CPU, memory, storage

• Few layers to ensure performance

• Connectivity: Store data locally and synchronize later if connection


is poor
Types of Mobile Apps

Ref: buildfire.com
Mobile Native app

• They are built for specific platforms


• Examples: Google Maps, Facebook, LinkedIn – one version for
iOS and one for Android

• Languages used:
• Native iOS : Swift or Objective-C
• Native Android: Java or Kotlin

• Integrated Development Environment (IDE) such as Android studio


are used for this
Mobile Web apps

• Progressive web apps use modern web technology to deliver app-


like experiences to users, right in their browsers.

• Examples:
• Flipkart
• BookMyShow
• MakeMyTrip

• Uses HTML5, CSS3, JavaScript and runs on a browser


Mobile web application
Hybrid app

• A hybrid app combines elements of both native apps and web


applications.
• Examples: Twitter, Uber, Instagram

• Hybrid apps are essentially web apps (HTML, CSS, Javascript) that
have been put in a native app shell.

• The shell is able to connect to native capabilities of the mobile


platform such as camera, accelerometer, GPS, etc.

• Tools such as Xamarin and React Native allows app to run across
platforms
Pros & Cons

App type Pro Con

• High performance • Runs only on one platform


• Superior user experience • Need to know special language
Native
• Access to all features of OS • Need to update versions

• Easy to deploy new versions • Little scope to use device


• Common code base hardware
Web App • Lower user experience
• Need to search for app

• Does not need browser • Slower


• Single code base
Hybrid
• Access to device hardware
UI design patterns

• Action bars for quick access to frequently used actions


• Login using Facebook, Google, etc. instead of separate user id /
password
• Large buttons for ease of use
• Notifications of recent activity
• Discoverable controls: Controls show up only when an item is
selected (ex. In WhatsApp, the Forward button shows up when a
message is selected)
Mobile optimized web site

All features Reduced features


Responsive design

Example: Boston Globe News

This is how
the display
looks on
desktop
Responsive design

Example: Boston Globe News

This is how
the display
looks on
mobile

Adjusted
vertically
Responsive design

Single website for laptop & mobile & tablet

Principle: Adapt rendering depending on screen sizes & orientation

Ref: Wikipedia
Responsive design
Ref: Wikipedia

Flexi grids

• Divide a screen into multiple columns

• Assign HTML elements to one or more


columns

• Choose a different layout depending on


screen size
Store locally, Sync later
In case of intermittent connectivity

Doctors enter patient data in mobile, which gets synced with server later
Mobile Application Architecture

Android application architecture

4 types of components
• Activity (UI)
• Service (background process) - ex. playing music, download
• Content provider (Storage) - ex. SQLite, files,
• Broadcast receiver (Acts on events received from OS and other apps) - Ex
arrival of SMS
Examples of components
Activity & Content providers

Personal Calendar
App
<<Activity>>

Appointment list

<<Content Provider>>

SQLite API

DB
(Background) Service
Google Play initiating a
download service to
<<Activity>> download an App

Google Play

<<Service>>
Server
Download file

<<Content Provider>>

File API

File
Broadcast receiver (Event
handlers)
<<Service>> <<Service>> 7 Recorded Doctor’s
message phone
Alarm Call doctor
(Makes sound) 4 5 Get doc details
4
<<Broadcast <<Broadcast <<Content
receiver>> receiver>> Provider>>
High Pulse event High Pulse event
receiver receiver File API
High
3
pulse
6 Patient monitoring
event / 3
system
intent
<<Service>>
Config file
(Doc #,
Pulse rate
Recorded
monitor msg)
2
1

Pulse monitoring device


Exercise: Mobile app
components
Give examples of mobile app components in Uber app.

UI
Screen to book a cab

Broadcast receiver
Receive location of cab from backend server and provide to UI for
display

Service
Provide cab location to backend server after journey starts

Database
Configuration file containing user data
Exercise

Consider a mobile app carried by the courier delivery boy.

The app should support the following functions:

a) View courier packages to be delivered


b) Mark a package as delivered.
c) Upon this event, the app should send information to central server

Identify the components of a mobile app & its inter-connections and draw an
appropriate software architecture diagram
a) View courier packages to be
delivered

List of packages to
be delivered

(UI screen)

Courier boy’s mobile


Get list of packages

SQLite content
provider
b) Mark a package as delivered. Upon this event, the app sends
information to central server

Courier boy’s mobile

Mark package as
'Delivered'

(UI screen)

Send data to server


Get list of packages

SQLite content Sync data with


provider server Rest API call to
Server
server
(Service)
Review questions
Mobile apps
1. What is a cross platform mobile app?
2. If connectivity is poor, how do we ensure consistency between data in mobile phone
and backend server?
3. What is ‘Broadcast receiver’ in an Android app?
Software Architecture

Architecting for IOT & AI


BITS Pilani Vijayarajan
Contents

• Clarification on Assignments
• Quiz 2
• Makeup Exam Answers
• Architecting for IOT & AI
Assignment
A1 - Build an Architecture for an App
• The App should at minimum include the technologies Web, Mobile, IOT, cloud
and analytics.
• Each team will select an application.
• The submitted architecture will be evaluated by the TA
• The team will be evaluated for their developed architecture
A2 – Research paper on real life architecture / latest trends etc
• Each team has to select a topic
• Final Paper should be submitted as per the agreed upon template and schedule
Refer to the template for Assignment #1
Assignment - 2 Sample
1. Performance - at least 3 popular applications
2. Scalability - at least 3 popular applications
3. Facebook - scalability
4. Agile and Architecture
5. Micro Services
6. Uber / Ola etc
7. Architecture For IOT
8. Architecture For Mobile
9. Architecture For Machine Learning
10. Architecture for Conferencing Platform
11. AWS Lambda
12. Architecture and NoSql DB
13. Architecting for cloud - trends
14. Compare cloud - Amazon / Azure / Google
15. YouTube / Netflix
Assignment - 2 Guidelines
Guidelines Guidelines for the paper
● You are not building an architecture • Intro
● You are studying what is happening • Scope / objective
around • Contents
● You must read many papers / case • References
studies
● You can do a Literature survey paper
● Key words
• Study
• Analyze strengths / weakness
• Compare
• Trend - what is driving the trends
Quiz 2

Like in Quiz 1, it will be 20 questions 30 minutes


Will open it from 10th April
From 10th April 7 PM (IST) to 16th April 11 PM (IST)
All topics that we have covered in the Contact Sessions
Architecting for IOT Applications

What are the characteristics of an IOT application


Amazon Fulfillment Center Video
smart things;
networks and gateways enabling low-power devices
(which is often the case in IoT) to enter the big Internet;
the middleware or IoT platforms providing data storage
spaces and advanced computing engines along with
analytical capabilities; and
applications, allowing end users to benefit from IoT and
manipulate the physical world.
the perception layer hosting smart things;
the connectivity or transport layer transferring data from the physical layer
to the cloud and vice versa via networks and gateways;
the processing layer employing IoT platforms to accumulate and manage all
data streams; and
the application layer delivering solutions like analytics, reporting, and device
control to end users.
the edge or fog computing layer performing data preprocessing close to the
edge, where IoT things collect new information. Typically, edgy computing
occurs on gateways;
the business layer where businesses make decisions based on the data; and
the security layer encompassing all other layers.
Perception Layer

Sensors such as probes, gauges, meters, and others. They collect physical
parameters like temperature or humidity, turn them into electrical signals,
and send them to the IoT system. IoT sensors are typically small and
consume little power.
Actuators, translating electrical signals from the IoT system into physical
actions. Actuators are used in motor controllers, lasers, robotic arms.
Machines and devices connected to sensors and actuators or having them as
integral parts.
It’s important to note that the architecture puts no restriction on the scope of
its components or their location. The edge-side layer can include just a
few “things” physically placed in one room or myriads of sensors and
devices distributed across the world.
Connectivity
Connectivity
Connectivity
Connectivity - Protocols

Once parts of the IoT solution are networked, they still need messaging
protocols to share data across devices and with the cloud. The most
popular protocols used in the IoT ecosystems are:
DDS (the Data Distribution Service) which directly connects IoT things to
each other and to applications addressing the requirements of real-time
systems;
AMQP (the Advanced Message Queuing Protocol) aiming at peer-to-peer
data exchange between servers;
CoAP (the Constrained Application Protocol), a software protocol designed
for constrained devices — end nodes limited in memory and power (for
example, wireless sensors). It feels much like HTTP but uses fewer
resources;
MQTT (the Message Queue Telemetry Transport), a lightweight messaging
protocol built on top of TCP/IP stack for centralized data collection from
low-powered devices.
Edge or fog computing layer:
reducing system latency
Processing layer: making raw
data useful
The processing layer accumulates, stores, and processes
data that comes from the previous layer. All these tasks
are commonly handled via IoT platforms and include two
major stages.

Data accumulation stage


Data abstraction stage
Processing Layer: Data
accumulation stage
The real-time data is captured via an API and put at rest to meet
the requirements of non-real-time applications. The data
accumulation component stage works as a transit hub
between event-based data generation and query-based data
consumption.
Among other things, the stage defines whether data is relevant
to the business requirements and where it should be placed.
It saves data to a wide range of storage solutions, from data
lakes capable of holding unstructured data like images and
video streams to event stores and telemetry databases. The
total goal is to sort out a large amount of diverse data and
store it in the most efficient way.
Processing Layer: Data
abstraction stage
Here, data preparation is finalized so that consumer applications can use it to
generate insights. The entire process involves the following steps:
combining data from different sources, both IoT and non-IoT, including ERM, ERP,
and CRM systems;
reconciling multiple data formats; and
aggregating data in one place or making it accessible regardless of location
through data virtualization.
Similarly, data collected at the application layer is reformatted here for sending to
the physical level so that devices can “understand” it.
Together, the data accumulation and abstraction stages veil details of the
hardware, enhancing the interoperability of smart devices. What’s more, they
let software developers focus on solving particular business tasks — rather
than on delving into the specifications of devices from different vendors.
Application, Business &
Security
Application layer: addressing business requirements
– At this layer, information is analysed by software to give answers to key
business questions.
Business layer: implementing data-driven solutions
Security layer: preventing data breaches
Architecting for IOT

Do not do from First Principles


Example of AWS
Example from Azure
Architecting for AI

Examples
Amazon Fulfillment Center
Google and Aravind Eye
BUSINESS IMPACT

CUSTOMER SUPPORT CORE SUPPLY COMMERCE MARKETING FOUNDATIONAL


BUSINESS BUSINESS ARCHITECTURAL
SERVICE APPLICATION APPLICATION CHAIN

INFUSE
PROCESS OPERATIONS PRINCIPLES

AI APPS & SERVICES

INSIGHTS
ORCHESTRATOR
OTHER ASSISTANT DISCOVERY OPEN
AI APPS

TRUSTED AI (FIT FOR PURPOSE)

BUSINESS ANALYTICS

NATURAL SPEECH VISUAL OTHER AI

ANALYZE AUGMENTED REPORTING & PLANNING & DECISION


AI TRUST
& MONITORING
LANGUAGE
UNDERSTANDING
TO TEXT RECOGNITION SERVICES

DATA DASHBOARDING MANAGEMENT OPTIMIZATION SECURITY


EXPLORATION
MODEL MACHINE
BUILDER LEARNING
DEPLOYMENT

DATA GOVERNANCE MULTICLOUD


MANAGEMENT

ORGANIZE INFORMATION KNOWLEDGE MASTER DATA


DATA
GOVERNED DATA LAKE
CATALOG REFINERY
GOVERNANCE MANAGEMENT

DATA CONSOLIDATION
OBJECT RDBMS DATA NoSQL OPERATIONAL EVENT DATA
STORAGE WAREHOUSE DATA STORE STORE SANDBOX

COLLECT
DATA DATA
VIRTUALIZATION INTEGRATION

TRANSFORMATION & EDGE


LEGEND
CONNECTIVITY SERVICES Users
DATA SOURCES Application component
Infrastructure services
Management
Data store
ENTERPRISE ENTERPRISE 3RD PARTY 3RD PARTY EXTERNAL SOCIAL WEATHER Analytics
SENSOR
DATA EVENTS CRM CLOUD MARKETING DATA Security
CLOUD SOURCES

• Collect data to make it easier to consume and access


• Organize data to create a trusted analytics foundation on data with business meaning
• Analyse to scale business insight with artificial intelligence everywhere
• Infuse to operationalize artificial intelligence with trust and transparency
Collect & Organize

Collect: Making data simple and accessible


Collect refers to how an enterprise can formally incorporate data into any
analytic process. Properties of data include structured, semi-structured, or
unstructured, proprietary or open, in the cloud or on premises, or any
combination.
Organize: Trusted, governed analytics
.
Ideally, the outcome is a body of data that is curated and that offers the
highest value to an enterprise.
Data is discoverable, catalogued, profiled, categorized, classified, secured,
and a source of truth and utility.
Analyze: Insights on demand
The analyze covers a span of techniques and capabilities, from basic reporting
and business intelligence to deep learning. Through data, you can
determine what happened, what is happening, and what might happen.
You can compare against expectations and automate and optimize
decisions.
Infuse: Operationalize artificial intelligence with trust and transparency
Infuse allows data to be used for automation and optimization, and as
part of a causal loop of action and feedback. Data is exercised in a
deployed model, used for developing insights and decision-making,
beneficial to the organization, and applied by the enterprise.
Architecting AI Applications

From First Principles


Use services provided Amazon, Google, Azure

You might also like