Professional Documents
Culture Documents
SOFTWARE ARCHITECTURE
Lecture 1: Introduction
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
1/10/2015
Stakeholder
Chief Technologist
Database Designer
Application Development team
Users/Customers
Infrastructure Manager
1/10/2015
9
July 26, 2014
10
1/10/2015
Area of Concern
Does it adhere to organization standards ?
What information to be stored, where, how, access mechanism???
Information security issues?
How do I implement a complex scenario?
How should I organize my code?
How do I plan for division of work?
Does it perform as per my requirement?
What about the cost/budget?
Scalability, performance and reliability of the system?
How easy it is to use?
Is it always available?
Performance and scalability
Idea of system & network usage
Indication of hardware and software cost, scalability, deployment location
Safety and security consideration
Is it fault tolerant- crash recovery & backup
Build strategy
Code management, version control, code organization
How do I replace of a subsystem with minimal impact ?
How fast can I diagnosis of faults and failures and how quickly I can recover?
SS ZG653 Second Semester 2014-15
11
Projects capture
requirements, there are
architects, and large
Development teams
Architect start with
requirements team &
handover to Development
teams
(look at http://www.sei.cmu.edu/architecture/start/glossary/classicdefs.cfm )
1/10/2015
12
1/10/2015
Is this Architecture
13
Whats Ambiguous?
Visible responsibilities
What we understand
The system has 5
elements
They are
interconnected
One is on the top
of another
1/10/2015
14
1/10/2015
15
Whats Ambiguous?
Significance of connections
A structure describing
Modules
Services offered by each module
and their interactions- to achieve the functionality
Information/data modeling
Achieving quality attributes
Processes and tasks that execute the software
Deployment onto hardware
Development plan
Significance of layout
Does level shown signify anything
Was the type of drawing due to space constraint
1/10/2015
16
1/10/2015
17
Architecture of Windows
https://http://blogs.msdn.com/b/hanybarakat/archive/2007/02/25/deeper-into-windows-architecture.aspx
A behavioral description
describing how the structural elements execute
important and critical scenarios
E.g. how does the system authenticates a mobile user
How does the system processes 1 TB of data in a day
How does it stream video uninterruptedly during peak
load
1/10/2015
18
1/10/2015
19
Architecture of Android
Architecture Styles
http://www.techotopia.com/index.php/An_Overview_of_the_Android_Architecture
1/10/2015
20
1/10/2015
21
Inter-relationships
A reference model
Decomposes the functionality into a set of smaller units
How they interact and share data
These units co-operatively implement the total functionality
A reference architecture
Derived from the reference model
Concrete software elements, mapped to the units
of the reference model, that implement the
functionality
1/10/2015
Not architecture by
itself!!
22
1/10/2015
23
Quicker to evaluate these decisions and correct it rather than discovering it later (10 100 times more
costly)
Early analysis of QoS and evaluation of architecture
Early analysis of meeting quality requirements and compromise between different QoS requirements
Early prototyping of important aspects quickly
More accurate cost and schedule estimation
Each view represents certain architectural aspects of the system, created for a
stakeholder
All the views combined together form the consistent whole
Reuse
Based on the architecture, one can quickly decide build-vs use external components
Tool that can automate part of development, testing
1/10/2015
24
1/10/2015
Module Structure
TOGAF, Zachmann
SEI ATAM, SAAM
Component-and-connector structures
How is the system to be structured as a set of elements that have
runtime behavior (components) and interactions (connectors)
What are major executing components and how do they interact
Architecture Framework
&
process
Architecture
description
standards
Architecture Aspects
Architecture
methods,
analysis
Allocation structures
How is the system to relate to non-software structures in its
environment (CPU or cluster of CPUs, File Systems, Networks,
Development Teams )
25
1/10/2015
26
1/10/2015
Reference
Architectures
Architecture description
standards
ISO 10746 RM-ODP
IEEE 1471,
RUP 4+1 views
ISO/IEC 9126 software
quality
Architecture modeling
UML and MDA EDOC
Architecture description
language
Behavior modeling
BPML, BPELWS,
Statechart, CSP, Petri-net
Patterns
Industry specific
Insurance Reference
Architecture: IAA
IBM e-Business
Architecture patterns
Architecture Style
27
A Structure is the underlying part of a view- essentially the set of elements, and
their properties
A view corresponding to a structure is created by using these elements and their interrelationships
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
Attributes
Instructor: Prof. Santonu Sarkar
Jan 11, 2015
Rational Unified Process/Kruchten 4+1 view (uses UML notations to describe these views)
Siemens architecture framework- Conceptual, Module, Code, Execution views
C4ISR framework Operational, system and technical
Classical approach Data flow and control flow views
RM-ODP (suitable for distributed system development) 5 viewpoints
1/11/2015
Software Structures
Module Structure
Decomposition
Module
Sub-modules
All sub-mobiles combined together is the
module
Component-and-connector structures
Decomposition
Uses
Layered
Hierarchical organization with restrictions
that layer n uses the service of layer n-1
Allocation structures
Class
Uses
Layered
Class or generalization
Similar to OO concept
1/11/2015
Allocation
Allocation
Components-and-connector
Client-Server
Concurrency
Process
Deployment
Shared data
Work assignment
Deployment
Client-Server
Components are clients and servers and connectors are how they interact
Concurrency
Opportunities of parallelism, where connectors are logical thread of execution
dependency
Implementation
Units are modules (from module view) and connectors denote how they
are mapped to files, folders
Components that are processes and connectors are how they communicate
Work assignment
Components have data store, and connectors describe how data is created,
stored, retrieved
1/11/2015
Implementation
1/11/2015
Architectural Structures
Architectural Structures
Software Structure
Relations
Useful For
Software Structure
Relations
Useful For
Decomposition
Is a sub-module of
Client-Server
Communicates with;
depends on
Distributed operation;
separation of concerns;
performance analysis; load
balancing
Process
Scheduling analysis;
performance analysis
Uses
Engineering subsets;
engineering extensions
Layered
Incremental development;
implementing systems on
top of virtual machines
portability
Concurrency
Class
In object-oriented design
systems, producing rapid
most-alike implementations
from a common template
Shared Data
Performance; data
integrity; modifiability
1/11/2015
1/11/2015
Architectural Structures
Software Structure
Relations
Useful For
Deployment
Performance, availability,
security analysis
Implementation
Stored in
Configuration control,
integration, test activities
Work assignment
Assigned to
End-user
concerned with functionality
essentially module structure
Logical View
Architect/Integrator
concerned with performance,
scalability..
essentially component-connector
1/11/2015
1/11/2015
Physical View
Development
View
Development team
concerned with software management
essentially allocation (implementation
and work-assignment)
10
A step back
What is functionality?
Ability of the ability of the system to do the work
for which it is intended
The structures and views we discussed so far, are
meant for achieving functionality (mostly)
1/11/2015
Orthogonal to functionality
is a constraint that the system must satisfy while
delivering its functionality
11
1/11/2015
12
Availability
Performance
Security
Usability
Functionality
Modifiability
Portability
Reusability
Integrability
Testability
1/11/2015
Radio button or check box? Clear text? Screen layout? --- NOT
architectural decisions
Architectural decision
13
1/11/2015
14
1/11/2015
15
1/11/2015
16
System
Quality
Business
Quality
Quality of
Architecture
Availability
Time to market
Conceptual
Integrity
Modifiability
Performance
Project lifetime
Security
Targeted market
Testability
Rollout schedule
Usability
Legacy integration
1/11/2015
Source of
Stimulus
Stimulus
Entity (human,
another
software) that
generates the
stimulus
completeness
Condition
that the
system needs
to consider
when it
arrives
Buildability
17
1/11/2015
Architectural Tactics
Stimulus
Activity
undertaken
as a result
of stimulus
A
measurable
response
which can
be tested
for
correctness
of quality
attribute
Response
Business Quality
18
19
Details
Time to Market
Projected lifetime of
the system
Targeted Market
Rollout Schedule
Integration with
Environment
1/11/2015
Measure
Business Qualities
Source of
Stimulus
Some part or
the whole
system is
affected
Conditions
when the
stimulus
occurs
Tactics are
implemented to
achieve the desired
response
Response
Environment
Correctness
Impacted
Artifact
Architectural Qualities
Architectural Quality
Conceptual
Integrity
Correctness and
Completeness
Build ability
Usability
How easy it is for the user to accomplish a
desired task and user support the system
provides
Details
Architecture should do similar things in similar ways
Unify the design at all levels
Essential to ensure systems requirements and run time
constraints are met
Implemented by the available team in a timely manner with
high quality
Open to changes or modifications as time progresses
Usually measured in cost and time
Knowledge about the problem to be solved
WHO
End
user
User Wants to
Learn system
feature
Use systems
efficiently
Minimize the
impact of errors
Adapt system
Feel comfortable
IMPACTED
PART
Whole
System
At run time
At
configure
time
MITIGATING ACTION
Learn
Context sensitive help,
familiar interface
Efficient use
Aggregation of data and
command, reuse of
already entered data,
good navigation, search
mechanism, multiple
activities
Error impact
Undo, cancel, recover,
auto-correct, retrieve
forgotten information
Usability Tactics
Usability is essentially Human
Computer Interaction. Runtime
Tactics are
MEASURABLE
RESPONSE
Task time
Number of errors
User satisfaction
Gain of user
knowledge
Successful
operations
Amount of
time/data lost
User initiative
(and system
responds)
Cancel, undo,
aggregation, store
partial result
System initiative
Task model:
understands the
context of the task
user is trying and
provide assistance
Correct spelling
during typing but not
during password
entry
1/11/2015
SS ZG653
23
1/11/2015
User model:
understands who
the user is and
takes action
System model:
gets the current
state of the system
and responds
Adjust scrolling
speed, user specific
customization, locale
specific adjustment
Time needed to
complete a task
24
Usability Tactics.
Design time tactics- UI is often revised during
testing. It is best to separate UI from the rest of
the application
Model view controller
Presentation abstraction control
Arch/Slinky
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
1/11/2015
Modifiability, Performance
Instructor: Prof. Santonu Sarkar
25
Availability
Availability
Availability vs Reliability
A software is said to be available even when it fails but recovers
immediately
Such a software will NOT be called Reliable
activation
Fault
Hypothesized cause of
error
1/20/2015
propagation
Error
Part of the systems total state that can
leads to failure
SS ZG653 Second Semester 2014-15
Failure
event that occurs when the delivered
service deviates from correct service
2
1/20/2015
Availability Scenarios
Availability Tactics
Availability
WHO
STIMULUS
Internal
Fault causing
or
System does not
External
respond
to
Crash
System
Delay in
response
Errorneous
Response
IMPACTED PART
MITIGATING ACTION
Infrastructure
and/or
application
Fault
detection
MEASURABLE
RESPONSE
Specific time
interval for
availability
Availability number
Time interval when
it runs in degraded
mode
Time to repair
Recovery by
repair
Recovery by
reintroduction
Ping/echo
Voting
Shadow
operation
Heartbeat
Active
redundancy
State
resynchronizati
on
Passive
redundancy
Checkpointing
and rollback
Exception
Failure
prevention
Removal of a component
to prevent anticipated
failure auto/manual
reboot
Create transaction
Process monitor- that can
detect, remove and restart
faulty process
Spare copy
1/20/2015
1/20/2015
Ping
Voting
Redundant processes- all of them perform the same task and their outputs are compared
Any mismatch is considered failure.
Client (or fault-detector) pings the server and gets response back
To avoid less communication bandwidth- use hierarchy of faultdetectors, the lowest one shares the same h/w as the server
Heartbeat
Server periodically sends a signal
Listeners listen for such heartbeat. Failure of heartbeat means that the
server is dead
Signal can have data (ATM sending the last txn)
Exception
Spare copy
Restarted when primary fails
Restarts to the checkpointed position
Downtime in min
1/20/2015
1/20/2015
Shadow
Transaction
State resynch
Process Monitor
1/20/2015
Modifiability Scenarios
Modifiability
Ability to Modify the system based on the
change in requirement so that
WHO
Enduser
Developer
SysAdm
Developer
1/20/2015
10
IMPACTED PART
STIMULUS
They want to modify
Functionality
Add,
modify,
delete
Quality
Capacity
Tries to change
UI
SS ZG653
1/20/2015
Second Semester 2014-15
UI, platform or
System
Runtime
Compile time
Design time
Build time
Artifact
Code
Environment:
Design time
MITIGATING ACTION
MEASURABLE
RESPONSE
Volume of the
When fault occurs it
impact of the
should do one or more of
primary system
Locate (Impact
Cost of
analysis)
modification
Modify
Time and effort
Test
Extent of impact to
Deploy again
other systems
Changes made
and unit test done
Completed in 4
hours
11
Modifiability Tactics
Localize Modifications
Modifiabilty
1.
Localize
change
Defer
binding
Factoring common
service
Limit possible
options
1/20/2015
2.
Adherence
to defined
protocols
12
3.
4.
Handle of A must be
consistent with B, if A
maintains multiple interfaces
Do not keep too many options for modules that are part of the framework
1/20/2015
1.
2.
1/20/2015
Quality of service/data
provided by A
4.
Data
Resource behavior of A
13
Existence of A
Location of A
Module
A
3.
Interface identity
Calls/
Depends
on
Sequence
Semantics of A
Module
B
Component
replacement
Use intermediary
between modules
Polymorphism
Restrict
Communication
Paths
Generaliz
e module
Configuration
files
Maintain Existing
Interface
Anticipate
change
Runtime
registration
Hide
Information
14
1/20/2015
Module
B
Calls/
Depends
on/
Uses
Module
A
15
What is Performance?
Use of pub-sub
2. Configuration Files
Calls/
Depends
on/
Uses
3. Polymorphism
Module
B
Module
A
16
1/20/2015
Performance Scenarios
17
Performance Tactics
Performance
WHO
External
Internal
Users
1/20/2015
STIMULUS
Events that are
Periodic
Sporadic
Stochastic
(with avg 1000
txn/min)
Submits
transactions and
expect response
in 3s
IMPACTED PART
MITIGATING ACTION
System
Running in
normal mode
Overloaded
Processes event in
time
Changes the servicelevel
Transactions
processed
MEASURABLE
RESPONSE
Latency or deadline
by which it must be
processed
Throughput- #of
events
processed/time
Jitter- variation
Miss rate
Data loss
Average latency
of 2s
18
Control Resource
Demand
Reduce
resource
reqd
Reduce #of
events
Manage
event rate
Increase in
compute
efficiency
Reduce
overhead
1/20/2015
Control
sampling
freq
Resource
Management
Control
resource
usage
Bound
execution
time
Bound
queue size
Increase
concurrency
Maintain
multiple
copies of
data/
computation
Increase
Resource
Resource
Arbitration
FIFO
Scheduling
policy
Static
Dynamic
priority
Fixed
priority
19
Resource Consumption
CPU, memory, data store, network communication
A buffer may be sequentially accessed in a critical section
There may be a workflow of tasks one of which may be choked with
request
Manage
event rate: If you have control, dont sample too many events (e.g.
sampling environmental data)
sampling time: If you dont have control, sample them at a lower speed,
leading to loss of request
Resource contention
Availability of a resource
Deadlock due to dependency of resource
Bound
Execution: Decide how much time should be given on an event. E.g.
iteration bound on a data-dependent algorithm
Queue size: Controls maximum number of queued arrivals
1/20/2015
20
1/20/2015
Manage Resources
Resource Arbitration
Increase Concurrency
FIFO
Fixed Priority
Semantic importance
Domain specific logic such as request from a privileged class gets higher priority
Multiple copies
Dynamic priority
Static scheduling
1/20/2015
21
Round robin
Earliest deadline first- the job which has earliest deadline to complete
Also pre-emptive scheduling policy
22
1/20/2015
23
Manage Data
Identify the portion of the data that needs to be managed for this
quality attribute
Plan for various data design w.r.t. the quality attribute
Manage Coordination
Plan how system elements communicate and coordinate
Binding
1/20/2015
24
1/20/2015
25
1/20/2015
26
1/20/2015
27
Determine which resources (CPU, memory) in your system are critical for
performance.
Ensure they will be monitored and managed under normal and overloaded system
operation.
1/20/2015
28
1/20/2015
29
scheduling policy
Priorities
policies for reducing demand
allocation of portions of the technology to processors
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
1/20/2015
Testability, Interoperability
Instructor: Prof. Santonu Sarkar
30
January 27, 2015
What is Security
Security comprises of
Confidentiality
prevention of the unauthorized disclosure of information. E.g. Nobody except you should be able
to access your income tax returns on an online tax-filing site
Integrity
Availability
prevention of the unauthorized modification or deletion of information. E.g. your grade has not
been changed since your instructor assigned it
prevention of the unauthorized withholding of information e.g. DoS attack should not prevent
you from booking railway ticket
4/5/2015
Authentication
WHO
Individual or a
system
Correctly identified OR
Correctly
Incorrectly identified
OR unknown
Who is
Internal or external
Authorized or
unauthrized
Has access to
Limited resource
Vast resource
An insider
4/5/2015
STIMULUS
Tries to
Read data
Change/delete
data
Access system
services
Reduce
availability of
services
Updates
payment details
IMPACTED
PART
System
services,
data
Online/offline
Within
firewall or
Open
Pay
database
table
MEASURABLE
RESPONSE
Encrypts data
Detect anomalous
situation (high access
req.) and informs
people/another system
Restricts availability
Time required to
circumvent security
measure with
Probability of success
Probability of
detecting attack
Probability of
detecting the
individual responsible
%of services available
during attack
Time to restore
data/services
Extent of damagehow much data is
vulnerable
No of access denials
Anomaly detected
Audit trail maintained
Corrective action
taken in 1 day
Authenticates
Hides identity
Corrective Actions
Security Scenario
MITIGATING ACTION
Non repudiation:: An activity (say a transaction) cant be denied by any of the parties involved. E.g.
you cannot deny ordering something from the Internet, or the merchant cannot disclaim getting your
order.
Assurance:: Parties in an activities are assured to be who they purport to be. Typically done through
authentication. E.g. if you get an email purporting to come from a bank, it is indeed from a bank.
Auditing:: System tracks activities so that it can be reconstructed later
Authorization grants a user the privileges to perform a task. For example, an online banking system
authorizes a legitimate user to access his account.
Detection:
Limit the access through security checkpoints
Enforces everyone to wear badges or checks
legitimate visitors
Resist
Armed guards
React
Lock the door automatically
Recover
Keep backup of the data in a different place
4/5/2015
Detect Attacks
Security Tactics
Security
Detect
Resist/
Prevent
Intrusion
detection
Detect service
denial
Verify
message
integrity
Detect message
delay
4/5/2015
Identify
actors
Authenticate and
authorize actors
Limit access and
exposure
Revoke
access
a set of signatures or
known patterns of malicious behavior stored in a database.
Recover
Maintain Audit
trail
Lock
system
Alert
actors
Maintain data
confidentiality
Restore
Use availability
tactics
Change default
setting
SS ZG653 Second Semester 2014-15
4/5/2015
Resist Attacks
Resist Attacks
Limit Access
Restrict access based on message source or destination
ports
Use of DMZ
4/5/2015
4/5/2015
React to Attacks
4/5/2015
10
11
4/5/2015
4/5/2015
12
13
Log
Identify suddenly high demand to a particular resourcefor instance high CPU utilization at an unusual time
Monitor communication
Monitor anomalous communication such as
4/5/2015
14
4/5/2015
15
16
4/5/2015
17
What is Testability
Testable Software
Dijkstras Thesis
Test cant guarantee the absence of errors, but it
can only show their presence.
Fault discovery is a probability
That the next test execution will fail and exhibit the
fault
18
4/5/2015
Testability Scenario
WHO
Unit tester
(typically unit
developers)
Integration tester
System tester or
client acceptance
team
System user
A unit tester
STIMULUS
Milestone in the
development
process is met
Completion of
design
Completion of
coding
Completion of
integration
Performs unit
test
SS ZG653
4/5/2015
Second Semester 2014-15
RESPONSE ACTION
Component or
whole system
Design time
Development
time
Compile time
Integration time
Component that
has controllable
interface
After component
is complete
Prepare test
environment
Access state values
Access computed
values
Observe the
output for inputs
provided
19
IMPACTED PART
%executable
statements executed
(code coverage)
Time to test
Time to prepare test
environment
Length of longest
dependency chain in
test
Probability of failure if
fault exists
Coverage of 85%
is achieved in 2
hours
20
4/5/2015
21
Testability Tactics
Testability
Manage
controllability and
Observability
Internal
Monitoring
Manage
Complexity
Introduce built-in
monitor in the system
Limit Structural
complexity
Limit nondeterminism
Executable assertion
Localize data store
Sandbox
4/5/2015
22
4/5/2015
23
Manage Complexity
4/5/2015
24
25
Internal Monitoring
4/5/2015
26
4/5/2015
4/5/2015
28
27
processes to processors
threads to processes
29
4/5/2015
4/5/2015
Choice of Tools
31
Interoperability
4/5/2015
32
Beyond API
Need to have a set of assumptions you can safely
make about the entity exposing the API
33
Tactics
Interoperability
Locate (Discover service)
Identify the service through a known directory service. Here service
implies a set of capabilities available through an interface
By name, location or other attributes
Manage interface
Orchestrate
Tailor interface
4/5/2015
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
34
Interoperability
Tactics
Interoperability
Locate (Discover service)
Identify the service through a known directory service. Here service
implies a set of capabilities available through an interface
By name, location or other attributes
Manage interface
Orchestrate
Beyond API
Need to have a set of assumptions you can safely
make about the entity exposing the API
Tailor interface
Add or remove capability from an interface (hide a particular function
from an untrusted user)
Use Decorator pattern for this purpose
4/5/2015
REVIEW SESSION
4/5/2015
4/5/2015
Usability Tactics
Availability Tactics
Cancel, undo,
aggregation, store
partial result
Availability
Fault
detection
User initiative
(and system
responds)
User model:
understands who
the user is and
takes action
System model:
gets the current
state of the system
and responds
Correct spelling
during typing but not
during password
entry
Adjust scrolling
speed, user specific
customization, locale
specific adjustment
Recovery by
reintroduction
Ping/echo
Voting
Shadow
operation
Heartbeat
Active
redundancy
State
resynchronizati
on
Passive
redundancy
Checkpointing
and rollback
Exception
4/5/2015
Recovery by
repair
System initiative
Task model:
understands the
context of the task
user is trying and
provide assistance
Time needed to
complete a task
Failure
prevention
Removal of a component
to prevent anticipated
failure auto/manual
reboot
Create transaction
Process monitor- that can
detect, remove and restart
faulty process
Spare copy
6
4/5/2015
Modifiability Tactics
Performance Tactics
Modifiabilty
Localize
change
Performance
Defer
binding
Runtime
registration
Hide
Information
Factoring common
service
Configuration
files
Maintain Existing
Interface
Anticipate
change
Polymorphism
Restrict
Communication
Paths
Generaliz
e module
Limit possible
options
Component
replacement
Use intermediary
between modules
4/5/2015
Control Resource
Demand
Adherence
to defined
protocols
Reduce #of
events
Reduce
resource
reqd
Manage
event rate
Increase in
compute
efficiency
Control
sampling
freq
Reduce
overhead
4/5/2015
Bound
execution
time
Bound
queue size
Increase
concurrency
FIFO
Scheduling
policy
Maintain
multiple
copies of
data/
computation
Static
Dynamic
priority
Fixed
priority
Increase
Resource
Testability Tactics
Testability
Security
Resist/
Prevent
Control
resource
usage
Resource
Arbitration
Security Tactics
Detect
Resource
Management
React
Manage
controllability and
Observability
Recover
Internal
Monitoring
Manage
Complexity
Identify
actors
Authenticate and
authorize actors
Limit access and
exposure
Revoke
access
Maintain Audit
trail
Lock
system
Alert
actors
Maintain data
confidentiality
Restore
Specialized Interface
Separate interface and
implementation
Limit nondeterminism
Executable assertion
Use availability
tactics
Change default
setting
SS ZG653 Second Semester 2014-15
Introduce built-in
monitor in the system
Limit Structural
complexity
Sandbox
10
4/5/2015
11
Thank You
SS ZG653: Software Architecture
Lecture 6: Introduction to OODesign
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
4/5/2015
SS ZG653 Second Semester 2014-15
12
System quality
Register User
Login user
Browse catalog of products
Place order to OPC (asynchronous messaging)
Supplier
Availability
Modifiability
Performance
Security
Testability
Usability
Interoperability
Example
Programming for this
Application
Whats cool?
Structure -- Data
Everything is an object
4/5/2015
4/5/2015
What is a class
Class represents an abstract, user-defined type
Structure definition of properties/attributes
Commonly known as member variables
Object State
Labrador
Age: 1 yr
Price : 3500
Sex:Male
Golden Retriever
Age: 6months
Price : 2000
Sex:Female
Pug
Age: 1.5yr
Price : 1500
Sex: Female
Object-Oriented Languages
Type System
Classes are user-defined data-types
Primitive types
Unified type
C# keyword object mother of all types (root)
Everything including primitive types are objects
Increases understandability
Less chance of committing errors
Makes modifications faster
Compilers can perform stronger error detections
Modules
Value
Reference
10
11
Inheritance
namespace
package
4/5/2015
12
Introducing Interface
Why?
A published declaration of a
set of services
It is easy to change
implementation without
impacting the user
4/5/2015
4/5/2015
13
Interface Definition
What is it?
An interface is a collection of
constants and method
declarations
No implementation, a
separate class needs to
implement an interface
14
Java also allows to define an abstract base class just like C++
15
Creating Objects
Destroying Objects
2.
4/5/2015
UML
Documenting Architecture
UML has not been designed specifically for
architecture, though practitioners use UML for
architecture description
4/5/2015
4/5/2015
Decomposition
Use
One module uses functionality of another module
Layered
Relations
Layering
4/5/2015
4/5/2015
Component
Concurrency
Relationships between components- control flow dependency, and
parallelism
Relations
One can use various other UML relations
such as association class
Client-Server
Components are clients or servers, connectors are protocols
Shared data
Components have data store, and connectors describe how data is
created, stored, retrieved
4/5/2015
4/5/2015
Illustration-Allocation Views
UML Deployment
diagram is a good
option for deployment
structure
No specific
recommendation for
work assignment and
implementation
Allocation Structure
Deployment
Units are software (processes from component-connector) and
hardware processors
Relation means how a software is allocated or migrated to a
hardware
Implementation
Units are modules (from module view) and connectors denote how
they are mapped to files, folders
Work assignment
4/5/2015
10
UML
Unified Modeling Language is a standardized
general purpose modeling language in the field of
object oriented software engineering
Structure diagrams emphasize the things that must be present in the system
being modeled- extensively used for documenting software architecture
Behavior diagrams illustrate the behavior of a system, they are used
extensively to describe the functionality of software systems.
Diagram
Behavior
Diagram
Structure
Diagram
Class Diagram
Profile
Diagram
Composite
Structure
Diagram
Package
Diagram
Activity
Diagram
Object
Diagram
Component
Diagram
Deployment
Diagram
Sequence
Diagram
Use Case
Diagram
State Machine
Diagram
Interaction
Diagram
Communication
Diagram
Interaction
Diagram
Timing
Diagram
Structural Diagrams
Behavioral Diagrams
4/5/2015
Monitoring Component
Customers
Analysis Component
Main Processing
4/5/2015
IT providers
SS ZG653
Business
partners such
as emarketplace
sellers
Use Case
Class Notation
Storefront has the main user interface in a Web front-end. Customers use
the Storefront to place orders for pets
class name
Register User
Login user
Browse catalog of products
Place order to OPC (asynchronous messaging)
operations
attributes
Order Processing Center (OPC)
receives orders from the
Storefront.
Administrator
Examine pending orders
Approve or deny a pending order
Supplier
4/5/2015
Class Relationships
Generalization Example
isA, is-a-type of relation ship
A PostalAddress, or an EmailAddress is an Address
There can be ThirdPartyProduct or a Refurbished product in
the online store
Composition
Inheritance
Association
private
private
private
private
}
String Street;
String city;
String state;
Integer pincode;
SS ZG653
4/5/2015
Second Semester 2014-15
SS ZG653
11
Composition
1. Strongest (Composition)
Implies total ownership, if the owner is destroyed,
the parts are also destroyed
Inner classes will certainly be a composition
2. Aggregation
Implies has-a part ownership
If the owner is destroyed, the parts still exist
Total ownership
A CreditCard exclusively belongs to one Client,
and one client can have many credit cards.
A client exclusively owns her shopping cart.
The shopping cart and the credit card will no
longer exist if the client is removed
1
ClientAccount
1..*
3. Weakest (Association)
General form of dependency based on the usage
of features
4/5/2015
Aggregation Relationship
SS ZG653
4/5/2015
Second Semester 2014-15
Professor
public class ShoppingCart {
private Vector myShoppingCartController;
private ClientAccount myClientAccount;
}
SS ZG653
ShoppingCart
13
CreditCard
Pond
15
1..1000
teaches
1
has
0..*
Students
Duck
Association or Dependency
Relation
0..*
1
category
Category
Dependency Example 2
class B
{
public void doB()
{
System.out.println(Hello);
}
}
class A
{
public void doS()
{
B b1 = new B();
b1.doB();
}
} //End of class Test
calls
Sequence Diagrams
20
Collaborative
Forms a pair for any development task to avoid error
Involves stakeholders from the beginning
It is a physical (electronic)
card
One card for one class
Collaboration
Iterative
Test driven
Before building the component, define the test cases
Continuously test
4/5/2015
Why?
Requirement, design, coding, testing goes through many iterations each having
short duration
Refactoring is a part of the development process
What
CRC Card
Class Name
Collaborators
Responsibilities
assigned to this Class
{
{
{
{
{
{
1.
2.
3.
4.
Box
Responsibilities
Getting length
Getting width
Getting height
Computing area
and volume
Collaborators
<<None>>
}
}
Define Responsibilities
Define Collaborators
4/5/2015
SS ZG653
Second Semester 2014-15
SS ZG653
26
Christopher Alexander
Source:
http://en.wikipedia.org/wiki/Christopher_Alexander
4/5/2015
Properties of Patterns
4/5/2015
4/5/2015
OO Design Principles
Open close
Dependency inversion
Decouple two module dependencies (A B)
Adapter pattern
Liskovs Substitution
Interface Segregation
Dont pollute an interface. Define for a specific purpose
Single responsibility
One class only one task
4/5/2015
4/5/2015
Context
A scenario or situation where design problem arises
Describe situations in which the problem occurs
Ideally the scenario should be generic, but it may not
always be possible
Context
Pattern
Problem
Example
Solution
SS ZG653 Second Semester 2014-15
4/5/2015
Problem
Pattern
Problem
Solution
Context
4/5/2015
Solution
Problem
Solution
Context
4/5/2015
Solution
10
Pattern System
Abstract
Reference Model
An ideal solution for a domain, comprising of only functional elements without any technology or
operational platform
NGOSS framework in Telecom
Open financial services architecture based on the use of intelligent mobile devices, Electronic
Commerce Research and Applications, 2008.
Architecture Style/Pattern
A set of components (or subsystems), their responsibilities, interactions, and the way they
collaborate
address one or more quality concerns
Design Pattern
software-centric solution to implement the application logic, data and the interaction. The
solutions include (but not limited to) package structure, analysis patterns for data modeling
GoF, Fowlers analysis pattern
Idioms
Programming language level best practices
4/5/2015
Implementation
11
4/5/2015
Pattern System
12
Pattern Classification
13
14
Problem Categories
Problem Categories
Category
Description
Creation
Mud to Structure Includes patterns that support suitable decomposition of an overall system task
into cooperating subtasks
Service Variation
Distributed
Systems
Includes patterns that provide infrastructures for systems that have components
located in different processes or in several subsystems and components
Service Extension
Interactive
Systems
Adaptation
Adaptable
Systems
Includes patterns that provide infrastructures for the extension and adaptation
of application in response to evolving and changing functional requirements
Access Control
Structural
Decomposition
Management
Organization of
Work
Communication
Resource handling
Category
4/5/2015
Description
Architectural Patterns
Mud to Structure
Interactive
Systems
MVC, PAC
Adaptable
Systems
Microkernel, Reflection
Abstract Factory, Prototype, Builder
Structural
Decomposition
Whole-Part, Composite
Organisation of
work
Master-Slave, Chain of
Responsibility, Command, Mediator
Access Control
Service Variation
Service Extension
Decorator, Visitor
Adaptation
Communication
Resource Handling
4/5/2015
16
Idioms
Mud to Structure
Management
4/5/2015
Pattern Classification
Distributed
Systems
Creation
Design Patterns
15
Singleton, Factory
Method
Template method
Counted Pointer
17
4/5/2015
18
Architectural Patterns
Mud to Structure
Before we start a new system, we collect
requirement from customer transform those
into specifications
Requirements Architecture (Optimistic View)
19
Mud to Structure
Layers
Pipes and Filters
Blackboard
Distributed Systems
Broker
Interactive Systems
Model-View-Controller
Presentation-AbstractionControl
Adaptable Systems
Microkernel
Reflection
4/5/2015
20
LAYERS
4/5/2015
21
4/5/2015
Name
Category
Age
Price
Labrador
Dog
3500
Pug
Dog
1.5
1500
Goldfish1
Fish
0.5
50
22
product
Category
Application logic is
deciding product price,
managing users
SS ZG653
4/5/2015
Second Semester 2014-15
product
Product
database
23
UI Layer classes
Business Layer classes
Database Layer classes
4/5/2015
24
Layers
Implementing protocols
Conceptually different issues split into
separate, interacting layers
Functionality decomposed into layers; helps
replace layer(s) with better or different
implementation
4/5/2015
25
4/5/2015
26
Context
Problem
Forces
Solution
Layer 7
Layer 6
Session
Layer 5
Transport
Layer 4
Network
Layer 3
Data Link
Layer 2
Physical
Layer 1
Application
Presentation
4/5/2015
27
4/5/2015
Dynamics
Layers
ComponentN.1
Layer N
Layer N
ComponentN.3
cannot carry out the request
completely on its own, it calls
layer N-1
Layer N-1
Component(N-1).1
Component(N-1).2
Component1.2
Layer N-1
Layer N-1
Component(N-1).3
Request passing
continues till
Layer 1 fulfills the
request
Layer 1
Layer 1
Component1.1
4/5/2015
ComponentN.2
Client
receives
Client calls
Layer N
Client
28
Component1.3
29
Scenario - I
4/5/2015
Layer 1
Scenario - II
30
Dynamics
Dynamics
Client calls
Layer N
4/5/2015
Send request
Response
received
Layer N-k
In a network protocol,
lowest layer intercepts a
request
Reports to the higher layer
Middle layer
understands that it is a
repeat request and
sends the notification
Layer N-k
Layer 1
Scenario V
Layer N
Layer N
Layer N-1
Layer N-1
Layer 1
Layer 1
Response sent
31
Implementation Guideline
32
Layer N
Layer 1
Request received
4/5/2015
33
4/5/2015
User-visible elements
Specific Application Modules
Common Service Levels
OS Interface Level
Hardware
SS ZG653 Second Semester 2014-15
34
4/5/2015
35
Layer decoupling
Changes in Layer J can ignore the presence and identity of Layer J+1 [
Suitable for Top-up communication]
36
4/5/2015
37
4/5/2015
38
Benefits
4/5/2015
39
Middleware- J2EE
Application logic
Application logic,
business rules
JVM
Can replace the
vendor
OS
Switch from Windows
to Unix
Virtual Machines
Cascades of changing
behavior
Lower efficiency
Unnecessary work
Difficulty in establishing the
correct granularity
Reuse of layers
Support for standardization
Dependencies are kept local
Exchangeability
4/5/2015
Problem
Mix of low- and high-level issues, where high-level operations rely on low-level ones
A typical pattern of communication flow consists of requests moving from high level to
low level, and answers to requests, incoming data and notification about events
traveling in the opposite direction
Forces
Code changes should not ripple through the system
Stable interfaces; standardization
Exchangeable parts
Grouping of responsibilities for better understandability and maintainability
Solution
Variants
Benefits
Reuse of layers
Support for standardization
Dependencies are kept local
Exchangeability
Liabilities
Kernel
Interrupt, exception,
thread scheduling &
dispatching
Hardware abstraction
Database
Tables, indexes
Can you find (at least 2) more popular uses and document them?
SS ZG653
4/5/2015
Second Semester 2014-15
40
41
Description
A large system that requires decomposition
Conceptual model
of domain elements
Context
Resource Mgmt
Domain layer
Information Systems
Pattern
System services
Presentation
Liabilities
Layers
Examples
Your application
Benefits
4/5/2015
42
Mud to Structure
Context
Problem
Forces
4/5/2015
4/5/2015
Solution
3
4/5/2015
Simple case
Source File
Data
Source
Pipe-1
Filter-1
Pipe-2
Filter-2
Pipe-3
Lexical analyzer
Data Sink
Token string
Parser
Abstract
syntax tree
Semantic Analyzer
Augmented
AST
Code Generator
Listing of scores
Filtering only July scores
Sorting of records
4/5/2015
Object code
Optimizer
Object File
4/5/2015
Various Components
4/5/2015
Scenario-1
Data Source
SS ZG653
Data Sink
collects results from end of the pipeline
Active: pulls results from preceding
processing stage
Passive: allows preceding filter to push
or write the results into it
4/5/2015
Scenario-2
Scenario 3
Pull pipeline
Control flow is started by the data sink calling for
data
4/5/2015
4/5/2015
Scenario 4- Multiprocess
10
Implementation
4/5/2015
11
Steps
4/5/2015
12
Initial Steps
1: Divide the systems tasks
into sequence of processing
stages
4. Filter
Design Depends on
Task it must perform
Adjacent pipe
Implemented as threads or
processes
Filter reuse
Each filter should do one thing
well
Can read from global or external
files for flexible configuration
4/5/2015
13
4/5/2015
Final Steps
14
Variants
4/5/2015
15
4/5/2015
16
Benefits
Liabilities
17
4/5/2015
18
Problem
When there is no deterministic solutions to process raw data, and it is
required to interchange algorithms processing some intermediate
computation
Solutions to partial problems require different representation
No predetermined strategy is present to solve a problem (in functional
decomposition sequence of activations are more hard-coded)
Dealing with uncertain knowledge
Mud to Structure
BLACKBOARD ARCHITECTURE
PATTERN
4/5/2015
19
4/5/2015
20
Forces
Examples
Speech recognition (HEARSAY project 1980)
Vehicle identification and tracking
Robot control (navigation, environment learning,
reasoning, destination route planning)
Modern machine learning algorithms for
complex task (Jeopardy challenge)
Adobe OCR text recognition
Modern compilers tend to be more Blackboard
oriented
4/5/2015
21
4/5/2015
Blackboard Pattern
22
Solution Structure
Runs in a loop
Monitors change in blackboard
Activates next KS
Selection strategy may depend on ControlData
Shared datastore
containing partial
solutions
4/5/2015
23
4/5/2015
24
Benefits
Benefits
Liabilities
Difficulty in testing
No good solution
guaranteed
Computational overhead in
rejecting wrong solutions
High development effort
Concurrent access to
blackboard must be
synchronized, parallelization
is difficult
4/5/2015
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
Systems
Instructor: Prof. Santonu Sarkar
February 25, 2015
25
Context
Complex environment comprises of distributed systems
You want to take advantage of computing power of
many CPUs, or a cluster of low-cost systems
A software may be available only on a specific
computer
Due to security reasons, you want to run different
parts in different systems
Some services are provided by business partners over
the internet
Distributed Systems
BROKER PATTERN
4/5/2015
4/5/2015
Forces
4/5/2015
Architecture should hide system-specific and implementationspecific details from users of components and services
Specifically communication issues, data transfer, security issues
4/5/2015
The Broker:
Locating the appropriate server and forwarding a request
to that server
Transmitting results and exceptions back to the client
SS ZG653 Second Semester 2014-15
4/5/2015
4/5/2015
Broker
Necessary abstraction that makes distribution possible by providing the contract about the service
that the server is going to provide without exposing the implementation details on the server side
Participating components
Clients
Servers
Brokers
Bridges
Client-side proxies
Server-side proxies
Process 1
Process 2
Process 3
4/5/2015
4/5/2015
Scenario 1
The client simply invoke performFunction()
on the client proxy as if it were a local call
locateServer()
marshal()
marshal()
locateServer()
unmarshal()
4/5/2015
10
4/5/2015
11
performFunction()
locateServer()
marshal()
sendRequest()
locateClient()
marshal()
sendResponse()
unmarshal()
performFunction()
4/5/2015
registerServer()
unmarshal()
12
4/5/2015
Broker as Intermediary
13
Broker as intermediary
performFunction()
registerServer()
marshal()
sendRequest()
locateServer()
forwardRequest()
unmarshal()
performFunction()
sendResponse()
forwardResponse()
marshal()
locateClient()
unmarshal()
4/5/2015
14
4/5/2015
15
its interfaces
their semantics and
protocols used for communication (Internet Inter-Orb Protocol IIOP)
CORBA supports the basic Broker pattern.
4/5/2015
16
Since the .NET platform supports reflection to acquire type information, the client proxy is created
automatically at runtime behind the scene, completely transparent for the application developer.
No separate source code generation or compilation step required.
The interface description for the client proxy can be provided by MSIL-Code or by a WSDL-Description
of the interface itself.
The client proxy is responsible of creating the invocation request, but is not in charge of any
communication related aspects.
4/5/2015
Flexible, allows any custom extensions to fulfil for example QoS requirements.
Supports the client-side asynchrony broker variants. Lifecycle management strategies for servants are
also included within the framework.
Doesn't have a central naming or lookup system. Clients have to know the object reference of the
servant in advance. However different strategies exist to avoid the hardcoding of the server destination
inside the client application code
17
Benefits
18
4/5/2015
19
Liabilities
Error HandlingClients have to cope with the
inherent unreliability and the associated errors of
network communication.
Overhead Developers can easily forget about the
location of objects, which can cause overhead if the
expenses of remote communication are not
considered
Performance
Lower fault tolerance (server fails, broker fails, ...)
Testing and debugging
4/5/2015
20
4/5/2015
Context
Grade A: 5
Grade B: 15
Grade C: 50
Grade D: 25
Grade F: 5
Problem
Because the flow of information is between the data store
and UI, one may be inclined to data and UI to reduce the
amount of coding and to improve application performance.
However, the major problem is that UI tends to change
much more frequently than the data storage system.
Another problem is that business applications tend to
incorporate complex business logic which also gets mixed
up
A
B
60
Grade
% of Students
50
15
50
25
D
F
40
30
20
10
0
A
Such an application typically retrieves data and displays it for the user.
After the user changes the data, the system stores the updates in the
data store.
4/5/2015
21
22
4/5/2015
23
Forces
Event
Controller
Controller
Changes are very frequent, more than data and business logic
One should be able to test only the UI part
Skillset: HTML page designer skills are different from core app
development. It is desirable to separate UI with the rest of the app
View
View
Multiple Views
Each view manages
display of
information
Model
24
4/5/2015
Captures data
Sends data to View
Responds to Controller for changing data
SS ZG653 Second Semester 2014-15
25
Model-View-Controller
TO BE CONTINUED..
1.
2.
3.
4.
5.
4/5/2015
26
4/5/2015
27
Interactive Systems
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
Systems
Instructor: Prof. Santonu Sarkar
March 3, 2015
4/5/2015
Model-View-Controller
notify()
display()
1.
2.
3.
4.
5.
4/5/2015
SS ZG653
4/5/2015
Second Semester 2014-15
MVC Initialization
makeController()
startEventProcessing()
4/5/2015
4/5/2015
Fundamental
steps for
realising a
MVC
4/5/2015
Steps
Initial Part
Implementation
#
1: Separate Human-Computer
Interaction
Analyze and separate the
core functionality of your
system and data from input
and output
Decide on the functionality
to be exposed to View(s)
and controller(s)
Decide how many views and
controllers you need
4/5/2015
2. Set-up MVC
Each view may have its own controller (sometimes a set of views can also
share a controller)
Creates a controller using the Factory Method design pattern (makeController() in View
class)
View exposes a method for controller to use directly bypassing the model (a scenario
when models state is not changed by the action of a user)
Initialization
Register with model
Set up relationship with the controller
Look for efficiency of fetching the data from model to build the view
View to decide based on changes if Draw needs to be called
4/5/2015
4/5/2015
10
Variants
Document View
Document = Model
View = View Controller
4/5/2015
11
4/5/2015
12
Benefits
Liabilities
4/5/2015
13
Increased complexity
Potential for excessive number of updates
Intimation connection between view and controller
Close coupling of views and controllers to a model
Inefficiency of data access in view
Difficulty of using MVC with modern user-interface
tools
4/5/2015
14
Context
The development of several applications that use similar programming
interfaces that build on the same core functionality
Developing software for an application domain that needs to cope with a broad
spectrum of similar standards and technologies
Continuous evolution (software and hardware), platform must be extensible,
portable and adaptable
Adaptable Systems
MICROKERNEL
4/5/2015
Problem
Solution- Microkernel
Encapsulate the fundamental services of your application platform in a
microkernel component
Includes functionality that enables other components running in separate
processes to communicate to each other; maintain system resources
15
4/5/2015
16
Microkernel
Microkernel
Client
17
4/5/2015
Participating Components
Microkernel
Internal Servers
External Servers
Adapters
Clients
Microkernel
4/5/2015
18
19
4/5/2015
20
Server
External Server (aka Personality)
Internal Server
Also known as subsystem
Extends functionality provided
by Microkernel
Microkernel invokes services
based on client requests
4/5/2015
Client
Adapter
Represents an application
Associated with exactly one
external server
No direct communication,
through Adapter only
Client
21
4/5/2015
Client Request
22
createRequest()
callInternalServer()
External server
requests a service to
microkernel
This service is
executeService()
provided by an internal
server
Internal server can be
a separate process or
a shared library
findReceiver()
Determines the
address of the
external server
Possibly an RPC
dispatchRequest()
executeService()
4/5/2015
23
4/5/2015
24
Client Requirement
Implementation
#
1. Analyze Application
Domain
Identify the functionality
required
Perform analysis to identify
policies the external servers
need to offer for the
application domain
Steps
10
11
12
13
4/5/2015
25
4/5/2015
4/5/2015
26
3. Categorize Services
Identify all core service functionality
Group them into a set of
semantically-independent categories
27
6. Determine communication
strategies
4/5/2015
28
Microkernel
Resource Management
Separate system-specific
parts from systemindependent parts
Use Layer pattern
4/5/2015
Separate process
Module physically shared by
other components
29
4/5/2015
Client Access
11:Implement external
servers
Each external server is
implemented as a separate
process that provides its
own service interface
Internal architecture
depends on the policies it
comprises
Specify how external
servers dispatch requests to
their internal procedures
4/5/2015
30
Variants
12:Implement adapters
Decide on strategy of
adapter; one adapter for all
clients or every client
associated with one adapter
(trade off)
Adapter needs to package
all relevant information into
a request and forwards the
request to appropriate
external server
Use Proxy pattern
31
4/5/2015
32
Layer
Coupling
Broker is decentralized
Microkernel is more
tightly coupled
Client communiction
In broker, clients
communicate via
message passing
Microkernel uses adapter
strategy so that clients do
not call the service
directly
4/5/2015
Microkernel can be
thought of as a variant of
layered architecture
Each layer is a VM
Lowest layer internal
server
Middle layer external
server+adapter
Topmost layer client
application
33
Benefits
Liability
Portability
Flexibility and Extensibility
Separation of policy and
mechanism
Scalability
Reliability
Transparency
Performance
Complexity of design and
implementation
4/5/2015
34
Known Uses
35
Basic Idea
Reflection pattern allows runtime discovery of
interfaces and dynamic calling of discovered
interfaces
Adaptable Systems
A BRIEF INTRODUCTION TO
REFLECTION
4/5/2015
4/5/2015
Solution
Context
Problem
How to build systems that support unanticipated
changes?
4/5/2015
Examples
4/5/2015
4/5/2015
4/5/2015
Reflection Liabilities
Class Level
Since reflection resolve the types dynamically, it involves extra processing like scanning to
find the class to load and introspect, causing slow performance.
Security Restrictions
Reflection requires runtime permissions that might not be available for system running
under security manager. This can cause you application to fail at runtime because of
security manager.
Field Level
Getting info on field types, get/set info
Security Issues
Using reflection we can access part of code that we are not supposed to access, for
example we can access private fields of a class and change its value. This can be a serious
security threat and cause your application to behave abnormally.
High Maintenance
Reflection code is hard to understand and debug, also any issues with the code cant be
found at compile time because the classes might not be available, making it less flexible
and hard to maintain.
Annotation Level
4/5/2015
Poor Performance
10
4/5/2015
11
Layering
Pipe-n-filter
Blackboard
Broker
MVC
Microkernel
Reflection
X
X
X
4/5/2015
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Runtime binding
Use runtime
registration
Use intermediary
Restrict
communication
path
Maintain existing
interface-wrapper
Generalize
Factor common
services
PATTERN
Increase semantic
coherence
X
X
X
X
X
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
X
12
Architectural Patterns
Design Patterns
Mud to Structure
Interactive
Systems
MVC, PAC
Adaptable
Systems
Microkernel, Reflection
Abstract Factory, Prototype, Builder
Structural
Decomposition
Whole-Part, Composite
Organisation of
work
Master-Slave, Chain of
Responsibility, Command, Mediator
Access Control
Service Variation
Service Extension
Decorator, Visitor
4/5/2015
14
Resource Handling
4/5/2015
Factory Pattern
About creation
Factory Method
Singleton
Adapter
Structural
Composite
About structural
decomposition
Decorator
Proxy
Iterator
Behavioral
4/5/2015
Communication
Visitor
Strategy
Service variation
Command
Organization of task
Singleton, Factory
Method
Template method
Counted Pointer
15
Observer
Management
Idioms
Pattern Classification
Distributed
Systems
Creation
Design Patterns
16
4/5/2015
17
4/5/2015
Factory Pattern
Centralize the decision of what factory (the class
which actually creates the business object) to
instantiate
Singleton
Restricts instantiation of only object for a business
logic class
18
4/5/2015
19
Solution
DocumentMgmtFramework
knows when to create a Document (when user selects the menu item
but DOES NOT anticipate what type of Document to create
20
4/5/2015
21
Benefits
22
4/5/2015
23
Context
Instead of one product, there could be multiple
families of products which needs to be instantiated
System needs to be independent from the way the
products it works with are created
Solution
Create a factory to instantiate objects specific to a
particular family of products
One factory per product family
4/5/2015
24
4/5/2015
25
Singleton Example
Singleton Pattern
4/5/2015
26
4/5/2015
27
Applicability Example
Logger Class
A logger is usualy implemented as a singletons, and
provides a global logging access point in all the application
components without being necessary to create an object
each time a logging operations is performed.
Configuration Classes
Server object
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
4/5/2015
28
What is it?
A set of design patterns
Provides easy and generalized techniques to realize
relationships between entities
We shall study
Decorator pattern
Adapter pattern
Composite pattern
Proxy pattern
Design Patterns
STRUCTURAL PATTERNS
4/5/2015
4/5/2015
Decorator Pattern
1.A component object need to be enhanced (a
window to have a scrollbar) or additional
responsibilities to be added
2.The decorated object can be used in the same
way as the undecorated object
3.The original component class does not want
to take on the responsibility of the decoration
4.There may be many possible decorations
DECORATOR PATTERN
4/5/2015
4/5/2015
Using a Decorator
4/5/2015
Usage in JDK
Consequences
FileIO
4/5/2015
4/5/2015
Adapter
Actual Service
Provider (Adaptee)
Adapter Pattern
Makes a req.
Like any adapter in the real world, an Adapter it is a bridge between two objects
One class expecting some type of object and you have an object offering the
same features, but exposing a different interface
Certainly both of them should be used instead of re-implementing
Changing existing classes is not an option
Therefore, why not create an adapter...
4/5/2015
10
11
4/5/2015
SS ZG653 Second Semester 2014-15
Target
Adaptee
4/5/2015
12
4/5/2015
13
Composite Pattern
14
4/5/2015
15
Composite
Objects
Button, Radio
Button, Check Box,
Text Fields,
JFrame, JPanel
Panel 0
Panel 1
Panel 2
Panel 3
16
4/5/2015
17
4/5/2015
18
4/5/2015
Adding new components can be easy and client code does not
need to be changed since client deals with the new
components through the component interface (GUIShape)
veryComplexShape.render();
}
}
SS ZG653 Second Semester 2014-15
19
Consequences
4/5/2015
20
4/5/2015
21
PROXY PATTERN
4/5/2015
22
4/5/2015
23
Class Diagram
public class SimpleClient{
A client obtains a reference to a Proxy, the client then handles the proxy in the
same way it handles RealSubject and thus invoking the method doOpeationA().
This interface is
implemented by both Real
subject and proxy
Maintains a reference
that allows the Proxy to
access the RealSubject.
Implements the same
interface implemented
by the Real Subject so
that the Proxy can be
substituted for the
RealSubject.
Controls access to the
RealSubject and may be
responsible for its
creation and deletion
4/5/2015
24
4/5/2015
25
Examples
Examples
26
4/5/2015
27
Examples
Firewall proxy
Proxy is a process on a firewall machine
Clients requests to outside world from within the
firewall, is intercepted by this process
Depending on the security policy, it allows or stops
the request
Incoming requests are also intercepted by proxy
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
28
What is it?
A set of design patterns
that identify common communication between objects.
These patterns increase flexibility in carrying out
communication
We shall study
Iterator pattern- Access elements of an aggregate
sequentially
Observer pattern- Publish/Subscribe or Event Listener
Strategy pattern- Select Algorithms on the fly
Visitor pattern- Separate an algorithm from an object
Command pattern- Encapsulate an action, parameters, state
Design Patterns
BEHAVIORAL PATTERNS
4/5/2015
4/5/2015
Iterator Pattern
Intent
Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation
An aggregate object is an object that contains other objects for the purpose
of grouping as a unit
Also called a container or a collection
Examples are a linked list and a hash table.
Motivation
ITERATOR PATTERN
4/5/2015
A list should allow a way to traverse its elements without exposing its
internal structure
It should allow different traversal methods
It should allow multiple traversals to be in progress concurrently
4
4/5/2015
Iterators cont.
Array Representation
0
4
1
-5
2
10
3
6
4
8
5
20
6
-10
7
30
4/5/2015
-5
Advantages of Iterators
10
20
-10
Traversal in C
Traversal in Java
30
4/5/2015
Solution
OBSERVER PATTERN
4/5/2015
4/5/2015
Observer Pattern
Context
Concrete
observers
A real time stock update system that publishes stock prices whenever a
change in stock price happen
Clients can be web-based application or a smart phone application
These clients need to be alerted whenever such change occurs
for(InformationSubscriber s : subscribers) {
o.update(this);
}
10
4/5/2015
Interaction
Many to Many
Triggering update
11
Implementation Issues
4/5/2015
12
4/5/2015
13
Push vs Pull
Push
subjects send detailed information about the change to the
observer whether it uses it or not
Could be inefficient when a large amount of data needs to be sent
and it is not used
STRATEGY PATTERN
Pull
The subject just notifies the observers about the change
Observer pulls the required data
Communication is done in 2 steps extra overhead
4/5/2015
14
4/5/2015
Interaction
Context:
A class can benefit from different variants for
an algorithm
Clients sometimes want to replace standard
algorithms with custom versions
15
Strategy Pattern
4/5/2015
16
4/5/2015
17
Different concrete
strategies (algorithms) to
move the robot
4/5/2015
18
19
4/5/2015
Examples
4/5/2015
4/5/2015
21
Implementation Issues
Usually each strategy need data from the context
Create a data class to hold the data and pass it to strategy
Special care to design data class- what fields should be included?
In the future some new strategy may require data from context
which are not included in this data class!
VISITOR PATTERN
22
4/5/2015
When do we need?
23
Applicability
Similar operations have to be performed on objects of different types
grouped in a structure (a collection or a more complex structure).
Several distinct and unrelated operations needed to be performed on
the structure
New operations may have to be added without affecting the structure
Example
4/5/2015
This is ObjectStructure
Another class that is a collection of visitable
objects
Offers mechanisms to iterate over visitable
24
4/5/2015
25
Consequences
Flexible design for adding new visitors to extend
existing functionality without changing existing code
4/5/2015
4/5/2015
27
4/5/2015
4/5/2015
29
COMMAND PATTERN
30
4/5/2015
31
Applicability
4/5/2015
32
4/5/2015
33
Class Diagram
The invoker who asks the
command to carry out request
Abstract Command to
execute an operation
// Buy Shares
agent.placeNewOrder(bsc);
// Sell Shares
agent.placeNewOrder(ssc);
}
34
Implementation Issues
4/5/2015
35
Asynchronous calls
In the application context, you typically use many command
objects at any time
4/5/2015
37
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
Systems
Instructor: Prof. Santonu Sarkar
March 31, 2015
4/5/2015
Cloud Computing
According to
National Institute of Standard & Technology
Ubiquitous Access
Resource Pooling
Elasticity
Measured Service
Multi-tenancy
4/5/2015
Continuous
adaptation
On demand
Self-serviced & personalized
4/5/2015
Ensure
accountability
and trust
Examples
4/5/2015
4/5/2015
Service
Platform As a Service
Application
Software As a Service
Informed and near optimal decisions on all relevant aspects of the service
Service offering, product design can be improved through realtime feedback
Distribution, production and maintenance can be highly fine tuned
Empowers consumers like never before
(http://www.emc.com/collateral/analyst-reports/diverse-exploding-digital-universe.pdf)
(http://hmi.ucsd.edu/pdf/HMI_2009_ConsumerReport_Dec9_2009.pdf),
(http://www2.sims.berkeley.edu/research/projects/how-much-info-2003/printable_report.pdf)
http://www.mckinsey.com/mgi/publications/big_data/index.asp
SS ZG653 Second Semester 2014-15
http://www.reuters.com/article/2011/07/19/idUS319973276120110719
8 petabytes/yr,
20hrs of new
video/min
Scenarios
1B Txn/day.
They need to detect
credit card fraud
within 5ms.
4/5/2015
Unprecedented
Impact
500M active
users, handles
1.6B queries per
day
From infrastructure
From social ecosystem
185,000
applications on
Force.com
6M Txn/day
Massive data
Data is
massive
1B active users,
500M uses mobile
devices
Application
Framework,
Middleware
Database
Process
Infrastructure
As a Service
Infrastructure Sharing
Provisioning of right
sized infrastructure ondemand
OS
Virtual Hardware
Physical
Hardware
8
System Virtualization
4/5/2015
Application
Application
Application
Application
Application
Application
Ubuntu
Redhat
Windows
VM1
VM2
VM3
Page mapping
Scheduling
Virtual machine
A software that simulates a
machine environment
Infrastructure
As a Service
Platform As a Service
Software As a Service
Hypervisor (VMM)
Physical hardware
Hypervisor
4/5/2015
1
0
10
Virtualized Environment
11
4/5/2015
12
Network- in a Nutshell
Outgoing message
Gateway records the private IP of the source,
replace the header with its own public IP
Sends it to external network
Incoming message
Gateway
4/5/2015
13
4/5/2015
Variety of clusters
A cluster manager
manages node, and
persistent object manager
manages files
Cluster manager controls
execution of VMs on a node
Virtual networking between
VMs and VM external user
14
Networking in IaaS
Infrastructure as a Service
4/5/2015
15
4/5/2015
16
HDFS
17
4/5/2015
HBase
18
MongoDB
4/5/2015
One NameNode
managing multiple
DataNodes
Data stored in
DataNodes in
blocks of 64MB
Each block is
replicated for
Reliability
19
4/5/2015
20
Quality of Service
Availability
Services expected to always available- but there are
many failure points
4/5/2015
21
Failure Estimation
22
4/5/2015
4/5/2015
23
4/5/2015
24
Performance
Security
Multi-tenancy in Cloud can increase security threat possibility
A PM is hosting other VMs alongwith yours
Information stealing
VM escape
As an architect
It is necessary to understand Applications resource
demand and projected resource usage
Application should predict the load and possibly
ask for more resource from the cloud resource
manager
SS ZG653 Second Semester 2014-15
4/5/2015
25
Though rare, an attacker can exploit hypervisor software error and access
information by accessing VM address space
Denial of Service
Malicious tenant grabs maximum resources so that other VMs starve for
resource and that impacts service quality
SS ZG653 Second Semester 2014-15
4/5/2015
CAP Theorem
No distributed system can achieve all of the
three properties
Consistency
The data will be consistent throughout the distributed
system
Helper utilities
Availability
Partition Tolerance
26
27
4/5/2015
28
Architects Decision
How do we tradeoff between C, A, and P?
Eventual Consistency
Accept the write, knowing that neither A nor B will know about this new data until the partition
heals.
Refuse the write, knowing that the client might not be able to contact A or B until the partition
heals.
Nodes across partitions are allowed to be inconsistent- for some timethen it becomes consistent
Architects decision- Design challenge
4/5/2015
29
4/5/2015
30
Architects Role
Mechanism for eventual consistency
Caching, replication, message retry, timeout
Additionally
Interoperability, security
BITS Pilani
Pilani|Dubai|Goa|Hyderabad
April 7, 2015
4/5/2015
31
What is a Pattern
Context
A situation giving rise to a problem
Pattern
Problem
The recurring problem arising in that
context
Solution
4/9/2015
Architectural
Design
Idiom
4/9/2015
Architectural Patterns
Description
Mud to Structure
Layers
Pipes and Filters
Blackboard
Distributed Systems
Broker
Interactive Systems
Model-View-Controller
Adaptive Systems
Microkernel
Reflection
4/9/2015
SS ZG653
Layers
Pattern
Pattern
Layer N
Layer N
Layer N-1
Layer N-1
Layer 1
Solution
Solution
Variants
Variants
Benefits
Reuse of layers
Support for standardization
Dependencies are kept local
Exchangeability
Liabilities
Benefits
Reuse of layers
Support for standardisation
Dependencies are kept local
Exchangeability
Liabilities
4/9/2015
Mix of low- and high-level issues, where high-level operations rely on low-level ones
A typical pattern of communication flow consists of requests moving from high level to low
level, and answers to requests, incoming data and notification about events traveling in
the opposite direction
Forces
Code changes should not ripple through the system
Stable interfaces; standardization
Exchangeable parts
Grouping of responsibilities for better understandability and maintainability
Specify the
communication between
adjacent layers
Problem
Problem
Layer 1
Context
Context
Description
Description
SS ZG653
4/9/2015
Scenarios
Data Source
Filter 1
Filter 2
Data Sink
Data Source
Filter 1
Filter 2
Data Sink
Write(data)
Read
Transform(data)
Problem
Forces
Read
Read
Write(data)
Transform(data)
Push
pipeline
data
Transform(data)
Write(data)
data
Transform(data)
Pull
pipeline
Data Source
Filter 1
Filter 2
Buffering Pipe
Read
data
Data Sink
Read
data
Transform(data)
Write(data)
Read
data
Transform(data)
data
Transform(data)
Write(data)
Write(data)
Multiprocess
Everyone actively
pulls, and then push
Read
data
Transform(data)
Write(data)
Solution
4/9/2015
4/9/2015
Blackboard Architecture
Benefits
Liabilities
No intermediate files
necessary, but possible
Filter addition,
replacement, and Reuse
Rapid prototyping of
pipelines
Concurrent execution
Certain analysis possible
Throughput, latency, deadlock
4/9/2015
10
Problem
no deterministic solutions to process raw data
Required to interchange algorithms processing some intermediate computation
No predetermined strategy, and dealing with uncertain knowledge
Forces
4/9/2015
4/9/2015
Benefits
Liabilities
Difficulty in testing
No good solution
guaranteed
Computational overhead in
rejecting wrong solutions
High development effort
Concurrent access to
blackboard must be
synchronized, parallelization
is difficult
Shared datastore
containing partial
solutions
11
Solution Structure
Runs in a loop
Monitors change in blackboard
Activates next KS
Selection strategy may depend on ControlData
12
4/9/2015
13
Broker Pattern
Broker
Context
Necessary abstraction that makes distribution possible by providing the contract about the service
that the server is going to provide without exposing the implementation details on the server side
Forces
Process 2
Process 1
Process 3
4/9/2015
14
4/9/2015
Model-View-Controller
Benefits
Liabilities
Location Independence
Type System Transparency
Differences in type systems are coped
with by a intermediate network
protocol
Isolation-- Separating all the
communication-related code into its
own layer
Separation of Concerns The
communication and marshaling
concerns are encapsulated in the
requestor, invoker, and marshaler.
Resource Managementseperated
from the application logic.
Portability
4/9/2015
15
16
Description
Context
Problem
Solution
Divide the entire application into Processing, Output and Input (Model, View and Controller)
Model: Encapsulates core data and functionality, independent of specific output representations or
input behaviour
View: Displays information to the user obtained from the model, multiple views possible
Controller: Receives input events which are translated to service requests from the model or the
view
Variants
Benefits
Liabilities
Increased complexity
Potential for excessive number of updates
Intimation connection between view and controller
Close coupling of views and controllers to a model
Inefficiency of data access in view
Inevitability of change to view and controller when porting
Difficulty of using MVC with modern user-interface tools
4/9/2015
17
Microkernel
Fundament
al steps for
realising a
MVC
Additional
Scenarios
Pattern
Steps
Pluggable Controllers
10
4/9/2015
Pattern
Description
Context
The development of several applications that use similar programming interfaces that
build on the same core functionality
Problem
Developing software for an application domain that needs to cope with a broad
spectrum of similar standards and technologies
Continuous evolution (software and hardware), platform must be extensible, portable
and adaptable
Solution
Variants
Benefits
Portability
Flexibility and Extensibility
Separation of policy and mechanism
Scalability
Reliability
Transparency
Liabilities
Performance
Complexity of design and implementation
Description
Context
Problem
Solution
Divide the entire application into Processing, Output and Input (Model, View
and Controller)
Model: Encapsulates core data and functionality, independent of specific
output representations or input behaviour
View: Displays information to the user obtained from the model, multiple
views possible
Controller: Receives input events which are translated to service requests
from the model or the view
Variants
Benefits
Liabilities
Increased complexity
Potential for excessive number of updates
Intimation connection between view and controller
Close coupling of views and controllers to a model
Inefficiency of data access in view
Inevitability of change to view and controller when porting
Difficulty of using MVC with modern user-interface tools
18
4/9/2015
Steps
Pattern
Steps
10
10
11
11
12
12
13
13
4/9/2015
Pattern
Description
Context
The development of several applications that use similar programming interfaces that
build on the same core functionality
Problem
Developing software for an application domain that needs to cope with a broad spectrum
of similar standards and technologies
Continuous evolution (software and hardware), platform must be extensible, portable
and adaptable
Solution
19
Variants
Benefits
Portability
Flexibility and Extensibility
Separation of policy and mechanism
Scalability
Reliability
Transparency
SS ZG653 Liabilities
Second Semester
2014-15
Performance
Complexity of design and implementation
20
Description
Context
Problem
Solution
E apsulate i for atio a out properties a d aria t aspe ts of the appli atio s
structure, behavior, and state into a set of meta-objects.
Separate the meta-objects from the core application logic via a two-layer architecture:
The meta level contains the meta-objects
The base level contains the application logic.
Base-level objects consult an appropriate meta-object before they execute behavior or
access state that potentially can vary
Examples
Java offers Reflection through capabilities provided in the Java Reflection API
Broker Pattern CORBA and RMI
offers Reflection in terms of its Dynamic Invocation Interface (DII) and Interface
Repository
RMI
Benefits
Liabilities
Poor Performance
Since reflection resolve the types dynamically, it involves extra processing like scanning to
find the class to load and introspect, causing slow performance.
Security Restrictions
Reflection requires runtime permissions that might not be available for system running
under security manager. This can cause you application to fail at runtime because of
security manager.
Security Issues
Using reflection we can access part of code that we are not supposed to access, for
e a ple e a a ess pri ate fields of a lass a d ha ge it s alue. This a e a serious
security threat and cause your application to behave abnormally.
High Maintenance
efle tio ode is hard to u dersta d a d de ug, also a issues ith the ode a t e
found at compile time because the classes might not be available, making it less flexible
and hard to maintain.
4/9/2015
21
Factory Pattern
About creation
Factory Method
Singleton
Adapter
Structural
Composite
About structural
decomposition
Decorator
Proxy
Iterator
DESIGN PATTERN
4/9/2015
Behavioral
4/9/2015
Communication
Visitor
Strategy
Service variation
Command
Organization of task
23
Factory Method
Observer
22
4/9/2015
24
DocumentMgmtFramework
knows when to create a Document (when user selects the menu item
but DOES NOT anticipate what type of Document to create
4/9/2015
25
Singleton Pattern
4/9/2015
26
4/9/2015
Structural Patterns
A set of design patterns that provides easy and generalized techniques to realize relationships between
Composite pattern
Adapter pattern
Decorator pattern
Composite Objects are collection objects which can contain other objects (primitive or composite)
Interface for operation (whether for primitive type or composite type) is same
Any operation for primitive type object is atomic in nature but the same operation for a composite type
object is recursive in nature
Proxy pattern
4/9/2015
For example if we need to use only a few methods of some costly objects we'll initialize those objects when we need them entirely.
Till that situation arises, we can use some light objects exposing the same interface as the heavy objects. They will instantiate those heavy
objects when they are really need
Different access rights to an object
Providing a sophisticated means of accessing and referencing objects running in other processes, on other
machines.
SS ZG653 Second Semester 2014-15
27
entities
28
4/9/2015
29
Target
Adaptee
4/9/2015
30
4/9/2015
4/9/2015
This interface is
implemented by both Real
subject and proxy
31
Behavioral Pattern
A client obtains a reference to a Proxy, the client then handles the proxy in the
same way it handles RealSubject and thus invoking the method doOpeationA().
Maintains a reference
that allows the Proxy to
access the RealSubject.
Implements the same
interface implemented
by the Real Subject so
that the Proxy can be
substituted for the
RealSubject.
Controls access to the
RealSubject and may be
responsible for its
creation and deletion
32
We shall study
Iterator pattern- Access elements of an aggregate
sequentially
Observer pattern- Publish/Subscribe or Event Listener
Strategy pattern- Select Algorithms on the fly
Visitor pattern- Separate an algorithm from an object
Command pattern- Encapsulate an action, parameters, state
4/9/2015
33
Iterator Pattern
Concrete
observers
p.getLatestNews();
for(InformationSubscriber s : subscribers) {
o.update(this);
}
4/9/2015
34
4/9/2015
Different concrete
strategies (algorithms) to
move the robot
35
The O erall Co te t
4/9/2015
36
This is ObjectStructure
Another class that is a collection of visitable
objects
Offers mechanisms to iterate over visitable
4/9/2015
37
Cloud Infrastructure
Abstract Command to
execute an operation
Hypervisor
Virtual machine
38
4/9/2015
Data
Quality of Service
NOSQL preferred
No complex join and relational database approach
Key-value pair
Dynamic database schema
HDFS open source implementation is Hadoop
MongoDB- stored data as object using JSON format
Availability
Performance
=1
At least one should be available: 1
=1 1
Use spare-copy, graceful degradation and
active-redundancy tactics
Security
4/9/2015
39
40
4/9/2015
41
CAP Theorem
No distributed system can achieve all of the three
Consistency, Availability, Partition Tolerance
THANK YOU
42
43