0% found this document useful (0 votes)

53 views338 pages

Software Architecture PDF

The document discusses various architectural analysis techniques categorized into inspection- and review-based, model-based, and simulation-based methods. It highlights the Architectural Trade-off Analysis Method (ATAM) as a human-centric process for evaluating software architecture against quality attributes like modifiability and security. Additionally, it emphasizes the importance of reliability analysis and the challenges of mapping architectural designs to implementations, noting that multiple analysis techniques should be used together for effective results.

Uploaded by

chisi

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)

53 views338 pages

Software Architecture PDF

Uploaded by

chisi

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/ 338

Analysis Techniques

Software Architecture
Lecture 14

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Architectural Analysis in a Nutshell

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

Analysis Technique Categories

 Inspection- and review-based

 Model-based
 Simulation-based

3
Software Architecture: Foundations, Theory, and Practice

Architectural Inspections and

Reviews
 Architectural models studied by human stakeholders for
specific properties
 The stakeholders define analysis objective
 Manual techniques
 Can be expensive

 Useful in the case of informal architectural descriptions

 Useful in establishing “soft” system properties
 E.g., scalability or adaptability

 Able to consider multiple stakeholders’ objectives and

multiple architectural properties
4
Software Architecture: Foundations, Theory, and Practice

Inspections and Reviews in a

Nutshell
 Analysis Goals – any
 Analysis Scope – any
 Analysis Concern – any, but particularly suited for non-
functional properties
 Architectural Models – any, but must be geared to
stakeholder needs and analysis objectives
 Analysis Types – mostly static and scenario-based
 Automation Level – manual, human intensive
 Stakeholders – any, except perhaps component vendors

5
Software Architecture: Foundations, Theory, and Practice

Example – ATAM

 Stands for architectural trade-off analysis method

 Human-centric process for identifying risks early on in
software design
 Focuses specifically on four quality attributes (NFPs)
 Modifiability

 Security

 Performance

 Reliability

 Reveals how well an architecture satisfies quality goals

and how those goals trade-off
6
Software Architecture: Foundations, Theory, and Practice

ATAM Process

ATAM Business Drivers

 The system’s critical functionality

 Any technical, managerial, economic, or political
constraints
 The project’s business goals and context
 The major stakeholders
 The principal quality attribute (NFP) goals

8
Software Architecture: Foundations, Theory, and Practice

ATAM Scenarios
 Use-case scenarios
 Describe how the system is envisioned by the stakeholders
to be used
 Growth scenarios
 Describe planned and envisioned modifications to the
architecture
 Exploratory scenarios
 Try to establish the limits of architecture’s adaptability with
respect to
 system’s functionality
 operational profiles
 underlying execution platforms
 Scenarios are prioritized based on importance to
stakeholders
9
Software Architecture: Foundations, Theory, and Practice

ATAM Architecture

 Technical constraints
 Required hardware platforms, OS, middleware,
programming languages, and OTS functionality
 Any other systems with which the system must interact
 Architectural approaches that have been used to meet
the quality requirements
 Sets of architectural design decisions employed to
solve a problem
 Typically architectural patterns and styles

10
Software Architecture: Foundations, Theory, and Practice

ATAM Analysis
 Key step in ATAM
 Objective is to establish relationship between architectural
approaches and quality attributes
 For each architectural approach a set of analysis questions are
formulated
 Targeted at the approach and quality attributes in question

 System architects and ATAM evaluation team work together to

answer these questions and identify
 Risks  these are distilled into risk themes

 Non-Risks

 Sensitivity points

 Trade-off points

 Based on answers, further analysis may be performed

11
Software Architecture: Foundations, Theory, and Practice

ATAM in a Nutshell
Completeness
Consistency
Goals
Compatibility
Correctness`
Subsystem- and system-level
Scope
Data exchange
Concern Non-functional
Informal
Models
Semi-formal
Type Scenario-driven

Automation Level Manual

Architects
Developers
Stakeholders
Managers
Customers 12

Model-Based Architectural
Analysis
 Analysis techniques that manipulate architectural description to
discover architectural properties
 Tool-driven, hence potentially less costly
 Typically useful for establishing “hard” architectural properties only
 Unable to capture design intent and rationale

 Usually focus on a single architectural aspect

 E.g., syntactic correctness, deadlock freedom, adherence to a
style
 Scalability may be an issue
 Techniques typically used in tandem to provide more complete
answers

13
Software Architecture: Foundations, Theory, and Practice

Model-Based Analysis in a Nutshell

 Analysis Goals – consistency, compatibility, internal

correctness
 Analysis Scope – any
 Analysis Concern – structural, behavioral, interaction,
and possibly non-functional properties
 Architectural Models – semi-formal and formal
 Analysis Types – static
 Automation Level – partially and fully automated
 Stakeholders – mostly architects and developers

14
Software Architecture: Foundations, Theory, and Practice

Model-Based Analysis in ADLs

 Wright – uses CSP to analyze for deadlocks

 Aesop – ensures style-specific constraints
 MetaH and UniCon – support schedulability analysis via NFPs such
as component criticality and priority
 ADL parsers and compilers – ensure syntactic and semantic
correctness
 E.g., Rapide’s generation of executable architectural simulations

 Architectural constraint enforcement

 E.g., Armani or UML’s OCL

 Architectural refinement
 E.g., SADL and Rapide

15
Software Architecture: Foundations, Theory, and Practice

ADLs’ Analysis Foci in a Nutshell

Consistency
Goals Compatibility
Completeness (internal)
Component- and connector-level
Subsystem- and system-level
Scope Data exchange
Different abstraction levels
Architecture comparison
Structural
Behavioral
Concern
Interaction
Non-functional
Semi-formal
Models
Formal
Type Static
Partially automated
Automation Level
Automated
Architects
Developers
Stakeholders
Managers
16
Customers
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

Architectural Reliability Analysis

 Reliability is the probability that the system will perform its intended
functionality under specified design limits, without failure
 A failure is the occurrence of an incorrect output as a result of an
input value that is received, with respect to the specification
 An error is a mental mistake made by the designer or programmer
 A fault or a defect is the manifestation of that error in the system
 An abnormal condition that may cause a reduction in, or
loss of, the capability of a component to perform a
required function
 A requirements, design, or implementation flaw or
deviation from a desired or intended state

17
Software Architecture: Foundations, Theory, and Practice

Reliability Metrics

 Time to failure
 Time to repair
 Time between failures

18
Software Architecture: Foundations, Theory, and Practice

Assessing Reliability at
Architectural Level
 Challenged by unknowns
 Operational profile
 Failure and recovery history
 Challenged by uncertainties
 Multiple development scenarios
 Varying granularity of architectural models
 Different information sources about system usage
 Architectural reliability values must be qualified by assumptions
made to deal with the above uncertainties
 Reliability modeling techniques are needed that deal effectively with
uncertainties
 E.g., Hidden Markov Models (HMMs)

19
Software Architecture: Foundations, Theory, and Practice

Architectural Reliability Analysis in a

Nutshell
Consistency
Goals Compatibility
Correctness
Component- and connector-level
Scope
Subsystem- and system-level
Concern Non-functional
Models Formal
Static
Type
Scenario-based

Automation Level Partially automated

Architects
Managers
Stakeholders
Customers
Vendors 20

Simulation-Based Analysis

 Requires producing an executable system model

 Simulation need not exhibit identical behavior to system
implementation
 Many low-level system parameters may be
unavailable
 It needs to be precise and not necessarily accurate
 Some architectural models may not be amenable to
simulation
 Typically require translation to a simulatable language

21
Software Architecture: Foundations, Theory, and Practice

Architectural and Simulation

Models

Simulation-Based Analysis in a
Nutshell
 Analysis Goals – any
 Analysis Scope – any
 Analysis Concern –behavioral, interaction, and non-
functional properties
 Architectural Models – formal
 Analysis Types – dynamic and scenario-based
 Automation Level – fully automated; model mapping
may be manual
 Stakeholders – any

23
Software Architecture: Foundations, Theory, and Practice

Example – XTEAM

 eXtensible Tool-chain for Evaluation of Architectural Models

 Targeted at mobile and resource-constrained systems
 Combines two underlying ADLs
 xADL and FSP

 Maps architectural description to adevs

 An OTS event simulation engine

 Implements different analyses via ADL extensions and a model

interpreter
 Latency, memory utilization, reliability, energy consumption

24
Software Architecture: Foundations, Theory, and Practice

Example XTEAM Model

Example XTEAM Analysis

XTEAM in a Nutshell
Consistency
Goals Compatibility
Correctness
Component- and connector-level
Scope Subsystem- and system-level
Data exchange
Structural
Behavioral
Concern
Interaction
Non-functional
Models Formal
Dynamic
Type
Scenario-based

Automation Level Automated

Architects
Developers
Stakeholders Managers
Customers
Vendors 27

Closing Remarks
 Architectural analysis is neither easy nor cheap
 The benefits typically far outweigh the drawbacks
 Early information about the system’s key characteristics is
indispensable
 Multiple analysis techniques often should be used in
concert
 “How much analysis?”
 This is the key facet of an architect’s job

 Too many will expend resources unnecessarily

 Too few will carry the risk of propagating defects into

the final system
 Wrong analyses will have both drawbacks
28
Implementing
Architectures

Software Architecture
Lecture 15

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 Implementation as a mapping problem
 Architecture implementation frameworks
 Evaluating frameworks
 Relationships between middleware, frameworks,
component models
 Building new frameworks
 Concurrency and generative technologies
 Ensuring architecture-to-implementation consistency
 Examples
 Different frameworks for pipe-and-filter
 Different frameworks for the C2 style
 Application
 Implementing Lunar Lander in different frameworks
30
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 Implementation as a mapping problem
 Architecture implementation frameworks
 Evaluating frameworks
 Relationships between middleware, frameworks,
component models
 Building new frameworks
 Concurrency and generative technologies
 Ensuring architecture-to-implementation consistency
 Examples
 Different frameworks for pipe-and-filter
 Different frameworks for the C2 style
 Application
 Implementing Lunar Lander in different frameworks
31
Software Architecture: Foundations, Theory, and Practice

The Mapping Problem

 Implementation is the one phase of software engineering that is not
optional
 Architecture-based development provides a unique twist on the
classic problem
 It becomes, in large measure, a mapping activity

Design Implementation
Decisions Artifacts

 Maintaining mapping means ensuring that our architectural intent is

reflected in our constructed systems

32
Software Architecture: Foundations, Theory, and Practice

Common Element Mapping

 Components and Connectors

 Partitions of application computation and
communication functionality
 Modules, packages, libraries, classes, explicit
components/connectors in middleware
 Interfaces
 Programming-language level interfaces (e.g.,
APIs/function or method signatures) are common
 State machines or protocols are harder to map

33
Software Architecture: Foundations, Theory, and Practice

Common Element Mapping

(cont’d)
 Configurations
 Interconnections, references, or dependencies
between functional partitions
 May be implicit in the implementation

 May be externally specified through a MIL and

enabled through middleware
 May involve use of reflection

 Design rationale
 Often does not appear directly in implementation

 Retained in comments and other documentation

34
Software Architecture: Foundations, Theory, and Practice

Common Element Mapping

(cont’d)
 Dynamic Properties (e.g., behavior):
 Usually translate to algorithms of some sort

 Mapping strategy depends on how the behaviors are specified

and what translations are available
 Some behavioral specifications are more useful for generating
analyses or testing plans
 Non-Functional Properties
 Extremely difficult to do since non-functional properties are
abstract and implementations are concrete
 Achieved through a combination of human-centric strategies like
inspections, reviews, focus groups, user studies, beta testing,
and so on

35
Software Architecture: Foundations, Theory, and Practice

One-Way vs. Round Trip Mapping

 Architectures inevitably change after implementation begins
 For maintenance purposes

 Because of time pressures

 Because of new information

 Implementations can be a source of new information

 We learn more about the feasibility of our designs when we
implement
 We also learn how to optimize them

Design Implementation
Decisions Artifacts

36
Software Architecture: Foundations, Theory, and Practice

One-Way vs. Round Trip Mapping

(cont’d)
 Keeping the two in sync is a difficult technical and
managerial problem
 Places where strong mappings are not present are
often the first to diverge
 One-way mappings are easier
 Must be able to understand impact on implementation
for an architectural design decision or change
 Two way mappings require more insight
 Must understand how a change in the implementation
impacts architecture-level design decisions

37
Software Architecture: Foundations, Theory, and Practice

One-Way vs. Round Trip Mapping

(cont’d)
 One strategy: limit changes
 If all system changes must be done to the architecture first, only
one-way mappings are needed
 Works very well if many generative technologies in use

 Often hard to control in practice; introduces process delays and

limits implementer freedom
 Alternative: allow changes in either architecture or implementation
 Requires round-trip mappings and maintenance strategies

 Can be assisted (to a point) with automated tools

38
Software Architecture: Foundations, Theory, and Practice

Architecture Implementation
Frameworks
 Ideal approach: develop architecture based on a known
style, select technologies that provide implementation
support for each architectural element OO Class

Design Software
Decisions Library

Database
39
Software Architecture: Foundations, Theory, and Practice

Architecture Implementation
Frameworks
 This is rarely easy or trivial
 Few programming languages have explicit support for
architecture-level constructs
 Support infrastructure (libraries, operating systems,
etc.) also has its own sets of concepts, metaphors,
and rules
 To mitigate these mismatches, we leverage an
architecture implementation framework

40
Software Architecture: Foundations, Theory, and Practice

Architecture Implementation
Frameworks
 Definition: An architecture implementation framework
is a piece of software that acts as a bridge between a
particular architectural style and a set of implementation
technologies. It provides key elements of the
architectural style in code, in a way that assists
developers in implementing systems that conform to the
prescriptions and constraints of the style. F OO Class
r
a
m
Design
Design e Software
Decisions
Decisions w Library
o
r
k Database 41
Software Architecture: Foundations, Theory, and Practice

Canonical Example

 The standard I/O (‘stdio’) framework in UNIX and other

operating systems
 Perhaps the most prevalent framework in use today

 Style supported: pipe-and-filter

 Implementation technologies supported: concurrent

process-oriented operating system, (generally) non-
concurrent language like C

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

 Frameworks are meant to assist developers in following a style

 But generally do not constrain developers from violating a style if
they really want to
 Developing applications in a target style does not require a
framework
 But if you follow good software engineering practices, you’ll
probably end up developing one anyway
 Frameworks are generally considered as underlying infrastructure or
substrates from an architectural perspective
 You won’t usually see the framework show up in an architectural
model, e.g., as a component

43
Software Architecture: Foundations, Theory, and Practice

Same Style, Different Frameworks

 For a given style, there is no one perfect architecture

framework
 Different target implementation technologies induce
different frameworks
 stdio vs. iostream vs. java.io
 Even in the same (style/target technology) groupings,
different frameworks exist due to different qualitative
properties of frameworks
 java.io vs. java.nio

 Various C2-style frameworks in Java

44
Software Architecture: Foundations, Theory, and Practice

Evaluating Frameworks
 Can draw out some of the qualitative properties just
mentioned
 Platform support
 Target language, operating system, other
technologies
 Fidelity
 How much style-specific support is provided by the
framework?
 Many frameworks are more general than one
target style or focus on a subset of the style rules
 How much enforcement is provided?
45
Software Architecture: Foundations, Theory, and Practice

Evaluating Frameworks (cont’d)

 Matching Assumptions
 Styles impose constraints on the target architecture/application

 Frameworks can induce constraints as well

 E.g., startup order, communication patterns …

 To what extent does the framework make too many (or too few)
assumptions?
 Efficiency
 Frameworks pervade target applications and can potentially get
involved in any interaction
 To what extent does the framework limit its slowdown and
provide help to improve efficiency if possible (consider buffering
in stdio)?
46
Software Architecture: Foundations, Theory, and Practice

Evaluating Frameworks (cont’d)

 Other quality considerations
 Nearly every other software quality can affect
framework evaluation and selection
 Size
 Cost
 Ease of use
 Reliability
 Robustness
 Availability of source code
 Portability
 Long-term maintainability and support
47
Software Architecture: Foundations, Theory, and Practice

Middleware and Component

Models
 This may all sound similar to various kinds of
middleware/component frameworks
 CORBA, COM/DCOM, JavaBeans, .NET, Java Message
Service (JMS), etc.
 They are closely related
 Both provide developers with services not available in
the underlying OS/language
 CORBA provides well-defined interfaces, portability,
remote procedure call…
 JavaBeans provides a standardized packaging
framework (the bean) with new kinds of introspection
and binding 48
Software Architecture: Foundations, Theory, and Practice

Middleware and Component

Models (cont’d)
 Indeed, architecture implementation frameworks are
forms of middleware
 There’s a subtle difference in how they emerge and
develop
 Middleware generally evolves based on a set of
services that the developers want to have available
 E.g., CORBA: Support for language heterogeneity,
network transparency, portability
 Frameworks generally evolve based on a particular
architectural style that developers want to use
 Why is this important?
49
Software Architecture: Foundations, Theory, and Practice

Middleware and Component

Models (cont’d)
 By focusing on services, middleware developers often make other
decisions that substantially impact architecture
 E.g., in supporting network transparency and language
heterogeneity, CORBA uses RPC
 But is RPC necessary for these services or is it just an enabling
technique?
 In a very real way, middleware induces an architectural style
 CORBA induces the ‘distributed objects’ style

 JMS induces a distributed implicit invocation style

 Understanding these implications is essential for not having major

problems when the tail wags the dog!

50
Software Architecture: Foundations, Theory, and Practice

Resolving Mismatches

 A style is chosen first, but the middleware selected for

implementation does not support (or contradicts) that style
 A middleware is chosen first (or independently) and has undue
influence on the architectural style used
 Strategies
 Change or adapt the style

 Change the middleware selected

 Develop glue code Use the middleware

 Leverage parts of the middleware as the basis for
and ignore others a framework
 Hide the middleware in components/connectors

51
Software Architecture: Foundations, Theory, and Practice

Using Middleware to implement

Connectors
Comp 1 Architecture Comp 1

(thread)

Async Event RPC

(thread)

Implementation

Comp 2 Comp 2
52
Software Architecture: Foundations, Theory, and Practice

Building a New Framework

 Occasionally, you need a new framework

 The architectural style in use is novel

 The architectural style is not novel but it is being

implemented on a platform for which no framework exists
 The architectural style is not novel and frameworks exist for
the target platform, but the existing frameworks are
inadequate
 Good framework development is extremely difficult
 Frameworks pervade nearly every aspect of your system

 Making changes to frameworks often means changing the

entire system
 A task for experienced developers/architects
53
Software Architecture: Foundations, Theory, and Practice

New Framework Guidelines

 Understand the target style first

 Enumerate all the rules and constraints in concrete
terms
 Provide example design patterns and corner cases

 Limit the framework to the rules and constraints of the

style
 Do not let a particular target application’s needs creep
into the framework
 “Rule of three” for applications

54
Software Architecture: Foundations, Theory, and Practice

New Framework Guidelines

(cont’d)
 Choose the framework scope
 A framework does not necessarily have to implement
all possible stylistic advantages (e.g., dynamism or
distribution)
 Avoid over-engineering
 Don’t add capabilities simply because they are clever
or “cool”, especially if known target applications won’t
use them
 These often add complexity and reduce performance

55
Software Architecture: Foundations, Theory, and Practice

New Framework Guidelines

(cont’d)
 Limit overhead for application developers
 Every framework induces some overhead (classes must
inherit from framework base classes, communication
mechanisms limited)
 Try to put as little overhead as possible on framework
users
 Develop strategies and patterns for legacy systems and
components
 Almost every large application will need to include
elements that were not built to work with a target
framework
 Develop strategies for incorporating and wrapping these

56
Software Architecture: Foundations, Theory, and Practice

Concurrency

 Concurrency is one of the most difficult concerns to address in

implementation
 Introduction of subtle bugs: deadlock, race conditions…

 Another topic on which there are entire books written

 Concurrency is often an architecture-level concern

 Decisions can be made at the architectural level

 Done carefully, much concurrency management can be

embedded into the architecture framework
 Consider our earlier example, or how pipe-and-filter architectures
are made concurrent without direct user involvement

57
Software Architecture: Foundations, Theory, and Practice

Generative Technologies
 With a sufficiently detailed architectural model, various
implementation artifacts can be generated
 Entire system implementations

 Requires extremely detailed models including

behavioral specifications
 More feasible in domain-specific contexts
 Skeletons or interfaces

 With detailed structure and interface specifications

 Compositions (e.g., glue code)

 With sufficient data about bindings between two

elements
58
Software Architecture: Foundations, Theory, and Practice

Maintaining Consistency

 Strategies for maintaining one-way or round-trip mappings

 Create and maintain traceability links from architectural
implementation elements
 Explicit links in a database, in architectural models, in
code comments can all help with consistency checking
 Make the architectural model part of the implementation

 When the model changes, the implementation adapts

automatically
 May involve “internal generation”
 Generate some or all of the implementation from the
architecture
59
Implementation
Techniques

Software Architecture
Lecture 16

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 Implementation as a mapping problem
 Architecture implementation frameworks
 Evaluating frameworks
 Relationships between middleware, frameworks,
component models
 Building new frameworks
 Concurrency and generative technologies
 Ensuring architecture-to-implementation consistency
 Examples
 Different frameworks for pipe-and-filter
 Different frameworks for the C2 style
 Application
 Implementing Lunar Lander in different frameworks
61
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 Implementation as a mapping problem
 Architecture implementation frameworks
 Evaluating frameworks
 Relationships between middleware, frameworks,
component models
 Building new frameworks
 Concurrency and generative technologies
 Ensuring architecture-to-implementation consistency
 Examples
 Different frameworks for pipe-and-filter
 Different frameworks for the C2 style
 Application
 Implementing Lunar Lander in different frameworks
62
Software Architecture: Foundations, Theory, and Practice

Recall Pipe-and-Filter

 Components (‘filters’) organized linearly,

communicate through character-stream ‘pipes,’ which
are the connectors
 Filters may run concurrently on partial data
 In general, all input comes in through the left and all
output exits from the right

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

Framework #1: stdio

 Standard I/O framework used in C programming language

 Each process is a filter
 Reads input from standard input (aka ‘stdin’)

 Writes output to standard output (aka ‘stdout’)

 Also a third, unbuffered output stream called standard error

(‘stderr’) not considered here
 Low and high level operations
 getchar(…), putchar(…) move one character at a time
 printf(…) and scanf(…) move and format entire strings

 Different implementations may vary in details (buffering

strategy, etc.)

64
Software Architecture: Foundations, Theory, and Practice

Evaluating stdio
 Platform support  Matching assumptions
 Available with most, if  Filters are processes and
not all, implementations pipes are implicit. In-
of C programming process P&F applications
language
might require
 Operates somewhat modifications
differently on OSes with
no concurrency (e.g.,  Efficiency
MS-DOS)  Whether filters make
 Fidelity maximal use of
 Good support for concurrency is partially
developing P&F up to filter
applications, but no implementations and
restriction that apps have partially up to the OS
to use this style 65
Software Architecture: Foundations, Theory, and Practice

Framework #2: java.io

 Standard I/O framework used in Java language

 Object-oriented
 Can be used for in-process or inter-process P&F
applications
 All stream classes derive from InputStream or
OutputStream
 Distinguished objects (System.in and System.out) for
writing to process’ standard streams
 Additional capabilities (formatting, buffering) provided
by creating composite streams (e.g., a Formatting-
Buffered-InputStream)
66
Software Architecture: Foundations, Theory, and Practice

Evaluating java.io  Matching assumptions

 Easy to construct intra-
 Platform support and inter-process P&F
 Available with all Java applications
implementations on many  Concurrency can be an
platforms issue; many calls are
 Platform-specific blocking
differences abstracted
 Efficiency
away
 Fidelity  Users have fine-grained
 Good support for control over, e.g.,
developing P&F buffering
applications, but no  Very high efficiency
restriction that apps have mechanisms (memory
to use this style mapped I/O, channels)
not available (but are in
java.nio)
67
Software Architecture: Foundations, Theory, and Practice

Recall the C2 Style

 Layered style
with event-based
communication
over two-way
broadcast
buses
 Strict rules on
concurrency,
dependencies,
and so on
 Many frameworks developed for
different languages; focus on two
alternative Java frameworks here 68

Framework #1: Lightweight C2

Framework
 16 classes, 3000
lines of code
 Components &
connectors extend
abstract base classes
 Concurrency,
queuing handled at
individual
comp/conn level
 Messages are
request or
notification objects

Evaluating Lightweight C2
Framework  Matching assumptions

 Platform support  Comp/conn main

 Available with all Java classes must inherit
implementations on from distinguished
many platforms base classes
 Fidelity  All messages must be
in dictionary form
 Assists developers with
many aspects of C2  Efficiency
but does not enforce  Lightweight
these constraints framework; efficiency
 Leaves threading and may depend on
queuing policies up to threading and queuing
individual elements policy implemented by
individual elements
70
Software Architecture: Foundations, Theory, and Practice

Framework #2: Flexible C2

Framework

 73 classes, 8500
lines of code
 Uses interfaces
rather than base
classes
 Threading policy
for application
is pluggable
 Message queuing policy is
also pluggable
71

Framework #2: Flexible C2

Framework

Evaluating Flexible C2 Framework

 Platform support
 Matching assumptions
 Available with all Java  Comp/conn main classes
implementations on must implement
many platforms distinguished interfaces
 Fidelity  Messages can be any
 Assists developers with serializable object
many aspects of C2  Efficiency
but does not enforce  User can easily swap out
these constraints and tune threading and
queuing policies without
 Provides several disturbing remainder of
alternative application- application code
wide threading and
queuing policies
73
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 Implementation as a mapping problem
 Architecture implementation frameworks
 Evaluating frameworks
 Relationships between middleware, frameworks,
component models
 Building new frameworks
 Concurrency and generative technologies
 Ensuring architecture-to-implementation consistency
 Examples
 Different frameworks for pipe-and-filter
 Different frameworks for the C2 style
 Application
 Implementing Lunar Lander in different frameworks
74
Software Architecture: Foundations, Theory, and Practice

Implementing Pipe and Filter

Lunar Lander

 Framework: java.io
 Implementing as a multi-process application
 Each component (filter) will be a separate OS process
 Operating system will provide the pipe connectors
 Going to use just the standard input and output streams
 Ignoring standard error
 Ignoring good error handling practices and corner cases for
simplicity
75

Implementing Pipe and Filter

Lunar Lander

 A note on I/O:
 Some messages sent from components are intended for output
to the console (to be read by the user)
 These messages must be passed all the way through the
pipeline and output at the end
 We will preface these with a ‘#’
 Some messages are control messages meant to communicate
state to a component down the pipeline
 These messages are intercepted by a component and
processed
 We will preface these with a ‘%’
76

Implementing Pipe and Filter

Lunar Lander

 First: GetBurnRate component

 Loops; on each loop:

 Prompt user for new burn rate

 Read burn rate from the user on standard input
 Send burn rate to next component
 Quit if burn rate read < 0

GetBurnRate Filter
//Import the java.io framework
import java.io.*;

public class GetBurnRate{

public static void main(String[] args){

//Send welcome message

System.out.println("#Welcome to Lunar Lander");

try{
//Begin reading from System input
BufferedReader inputReader =
new BufferedReader(new InputStreamReader(System.in));

//Set initial burn rate to 0

int burnRate = 0;
do{
//Prompt user
System.out.println("#Enter burn rate or <0 to quit:");

. . .
78

GetBurnRate Filter
//Import the java.io framework
import java.io.*;
. . .
public class GetBurnRate{
//Read user response
public static void
try{main(String[] args){
String burnRateString = inputReader.readLine();
//Send welcome message
burnRate = Integer.parseInt(burnRateString);
System.out.println("#Welcome to Lunar Lander");
//Send user-supplied burn rate to next filter
try{ System.out.println("%" + burnRate);
//Begin reading
} from System input
BufferedReader inputReader =
catch(NumberFormatException nfe){
new BufferedReader(new InputStreamReader(System.in));
System.out.println("#Invalid burn rate.");
}
//Set initial burn rate to>=0 0);
}while(burnRate
int burnRate = 0;
inputReader.close();
do{ }
//Prompt user
catch(IOException ioe){
System.out.println("#Enter
ioe.printStackTrace();burn rate or <0 to quit:");
}
. . . }
} 79

Implementing Pipe and Filter

Lunar Lander

 Second: CalcNewValues Component

 Read burn rate from standard input

 Calculate new game state including game-over

 Send new game state to next component

 New game state is not sent in a formatted string;

that’s the display component’s job

CalcBurnRate Filter
import java.io.*;

public class CalcNewValues{

public static void main(String[] args){

//Initialize values
final int GRAVITY = 2;
int altitude = 1000;
int fuel = 500;
int velocity = 70;
int time = 0;

try{
BufferedReader inputReader = new
BufferedReader(new InputStreamReader(System.in));

//Print initial values

System.out.println("%a" + altitude);
System.out.println("%f" + fuel);
System.out.println("%v" + velocity);
System.out.println("%t" + time);

. . . 81

CalcBurnRate Filter
import java.io.*;
String inputLine = null;
do{
public class CalcNewValues{
inputLine = inputReader.readLine();
if((inputLine != null) &&
public static void
(inputLine.length()
main(String[] args){
> 0)){
//Initialize values
final int GRAVITY
if(inputLine.startsWith("#")){
= 2;
int altitude = 1000;
//This is a status line of text, and
int fuel = 500; //should be passed down the pipeline
int velocity = 70;
System.out.println(inputLine);
int time = 0; }
else if(inputLine.startsWith("%")){
try{ //This is an input burn rate
BufferedReadertry{
inputReader = new
BufferedReader(new
int burnRate
InputStreamReader(System.in));
= Integer.parseInt(inputLine.substring(1));
if(altitude <= 0){
//Print initial values
System.out.println("#The game is over.");
System.out.println("%a"
} + altitude);
System.out.println("%f"
else if(burnRate
+ fuel); > fuel){
System.out.println("%v"
System.out.println("#Sorry,
+ velocity); you don't" +
System.out.println("%t"
"have
+ that
time);much fuel.");
}
82
. . . . . .
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

CalcBurnRate Filter
else{ inputLine = null;
import java.io.*;
String
//Calculate new application state
do{
time = time
public class CalcNewValues{
inputLine + 1;
= inputReader.readLine();
altitude = altitude
if((inputLine - velocity;
!= null) &&
velocity
public static void = ((velocity
(inputLine.length()
main(String[] args){ + GRAVITY) * 10 -
> 0)){
burnRate * 2) / 10;
//Initialize values
fuel
final int GRAVITY ==fuel
2; - burnRate;
if(inputLine.startsWith("#")){
int altitudeif(altitude
= 1000;
//This is <=a 0){
status line of text, and
altitude = 0;
int fuel = 500; //should be passed down the pipeline
int velocity =if(velocity
70; <= 5){
System.out.println(inputLine);
int time = 0; } System.out.println("#You have landed safely.");
}
else if(inputLine.startsWith("%")){
try{ else{
//This is an input burn rate
System.out.println("#You
BufferedReadertry{inputReader = new have crashed.");
}
BufferedReader(new
int burnRate
InputStreamReader(System.in));
= Integer.parseInt(inputLine.substring(1));
} if(altitude <= 0){
}
//Print initial valuesSystem.out.println("#The game is over.");
//Print new
System.out.println("%a"
} values
+ altitude);
System.out.println("%a"
System.out.println("%f" + fuel);+> altitude);
else if(burnRate fuel){
System.out.println("%f"
System.out.println("%v" + fuel);
System.out.println("#Sorry,
+ velocity); you don't" +
System.out.println("%v"
System.out.println("%t" "have+ that
time); + velocity);
much fuel.");
System.out.println("%t"
} + time);
. . . . . .}
catch(NumberFormatException nfe){
} 83
. . .
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

CalcBurnRate Filter
else{ inputLine = null;
import java.io.*;
String
//Calculate new application state
do{
time = time
public class CalcNewValues{
inputLine + 1;
= inputReader.readLine();
altitude = altitude
if((inputLine - velocity;
!= null) &&
velocity
public static void = ((velocity
(inputLine.length()
main(String[] args){ + GRAVITY) * 10 -
> 0)){
burnRate * 2) / 10;
//Initialize values
fuel
final int GRAVITY ==fuel
2; - burnRate;
if(inputLine.startsWith("#")){
int altitudeif(altitude
= 1000;
//This is <=a}0){
status line of text, and
altitude = 0;
int fuel = 500; //should }be passed down the pipeline
int velocity =if(velocity
70; <= 5){
}while((inputLine
System.out.println(inputLine);!= null) && (altitude > 0));
int time = 0; } System.out.println("#You
inputReader.close(); have landed safely.");
}
else }
if(inputLine.startsWith("%")){
try{ else{ catch(IOException
//This is an input burnioe){
rate
System.out.println("#You
BufferedReadertry{ ioe.printStackTrace();
inputReader = new have crashed.");
} int} burnRate
BufferedReader(new InputStreamReader(System.in));
= Integer.parseInt(inputLine.substring(1));
} }
if(altitude <= 0){
} }
//Print initial values
System.out.println("#The game is over.");
//Print new
System.out.println("%a"
} values+ altitude);
System.out.println("%a"
System.out.println("%f" + fuel);+> altitude);
else if(burnRate fuel){
System.out.println("%f"
System.out.println("%v" + fuel);
System.out.println("#Sorry,
+ velocity); you don't" +
System.out.println("%v"
System.out.println("%t" "have + that
time); + velocity);
much fuel.");
System.out.println("%t"
} + time);
. . . . . .}
catch(NumberFormatException nfe){
} 84
. . .
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

Implementing Pipe and Filter

Lunar Lander

 Third: DisplayValues component

 Read value updates from standard input

 Format them for human reading and send them to

standard output

DisplayValues Filter
import java.io.*;

public class DisplayValues{

public static void main(String[] args){

try{
BufferedReader inputReader = new
BufferedReader(new InputStreamReader(System.in));

String inputLine = null;

do{
inputLine = inputReader.readLine();
if((inputLine != null) &&
(inputLine.length() > 0)){

if(inputLine.startsWith("#")){
//This is a status line of text, and
//should be passed down the pipeline with
//the pound-sign stripped off
System.out.println(inputLine.substring(1));
}

. . . 86

DisplayValues Filter
else if(inputLine.startsWith("%")){
import java.io.*;//This is a value to display
if(inputLine.length() > 1){
public class DisplayValues{
try{
char valueType = inputLine.charAt(1);
public static void int
main(String[] args){
value = Integer.parseInt(inputLine.substring(2));
try{
BufferedReader switch(valueType){
inputReader = new
BufferedReader(new
case InputStreamReader(System.in));
'a':
System.out.println("Altitude: " + value);
String inputLine = break;
null;
do{ case 'f':
inputLine = inputReader.readLine();
System.out.println("Fuel remaining: " + value);
if((inputLine != break;
null) &&
(inputLine.length()
case 'v':> 0)){
System.out.println("Current Velocity: “ + value);
if(inputLine.startsWith("#")){
break;
//This is acase
status
't':line of text, and
//should be passed down the pipeline with
System.out.println("Time elapsed: " + value);
//the pound-sign stripped
break; off
System.out.println(inputLine.substring(1));
}
} }
catch(NumberFormatException nfe){
. . . }
. . .
87

DisplayValues Filter
else if(inputLine.startsWith("%")){
import java.io.*;//This is a value to display
if(inputLine.length() > 1){
public class DisplayValues{
try{
char valueType = inputLine.charAt(1);
public static void int
main(String[] args){
value = Integer.parseInt(inputLine.substring(2));
try{
BufferedReader switch(valueType){
inputReader = new
}
BufferedReader(new InputStreamReader(System.in));
case 'a': }
System.out.println("Altitude:
} " + value);
String inputLine = break;
null;
}while(inputLine != null);
do{ case 'f':
inputReader.close();
inputLine = inputReader.readLine();
System.out.println("Fuel remaining: " + value);
}
if((inputLine != break;
null) &&
catch(IOException ioe){
(inputLine.length()
case 'v':> 0)){
ioe.printStackTrace();
System.out.println("Current
} Velocity: “ + value);
if(inputLine.startsWith("#")){
}break;
//This is acase
status
't':line of text, and
}
//should be passed down the pipeline with
System.out.println("Time elapsed: " + value);
//the pound-sign
break;stripped off
System.out.println(inputLine.substring(1));
}
} }
catch(NumberFormatException nfe){
. . . }
. . .
88

Implementing Pipe and Filter

Lunar Lander

 Instantiating the application

 java GetBurnRate | java CalcNewValues | java DisplayValues

Implementing Pipe and Filter

Lunar Lander

Implementing Pipe and Filter

Lunar Lander

91
Software Architecture: Foundations, Theory, and Practice

Implementing Pipe and Filter

Lunar Lander

Implementing Pipe and Filter

Lunar Lander

93
Software Architecture: Foundations, Theory, and Practice

Takeaways
 java.io provides a number of useful facilities
 Stream objects (System.in, System.out)
 Buffering wrappers
 OS provides some of the facilities
 Pipes
 Concurrency support
 Note that this version of the application would not work if it
operated in batch-sequential mode
 We had other communication mechanisms available, but did not use
them to conform to the P&F style
 We had to develop a new (albeit simple) protocol to get the correct
behavior

94
Software Architecture: Foundations, Theory, and Practice

Implementing Lunar Lander in C2

 Framework: Lightweight
C2 framework
 Each component has its
own thread of control
 Components receive
requests or notifications
and respond with new
ones
 Message routing follows
C2 rules
 This is a real-time, clock-driven version of Lunar Lander
95

Implementing Lunar Lander in C2

(cont’d)
 First: Clock component
 Sends out a ‘tick’ notification
periodically
 Does not respond to any
messages

import c2.framework.*;
Clock Component
public class Clock extends ComponentThread{
public Clock(){
super.create("clock", FIFOPort.class);
}

public void start(){

super.start();

Thread clockThread = new Thread(){

public void run(){
//Repeat while the application runs
while(true){
//Wait for five seconds
try{
Thread.sleep(5000);
}
catch(InterruptedException ie){}

//Send out a tick notification

Notification n = new Notification("clockTick");
send(n);
}
}
}; 97

import c2.framework.*;
Clock Component
public class Clock extends ComponentThread{
public Clock(){
super.create("clock", FIFOPort.class);
}

public void start(){

clockThread.start();
super.start();
}
Thread clockThread = new Thread(){
publicprotected void handle(Notification n){
void run(){
//This
//Repeat component
while does not runs
the application handle notifications
}
while(true){
//Wait for five seconds
protected void handle(Request r){
try{
//This component does not handle requests
Thread.sleep(5000);
}}
}catch(InterruptedException ie){}

//Send out a tick notification

Notification n = new Notification("clockTick");
send(n);
}
}
}; 98

Implementing Lunar Lander in C2

 Second: GameState
Component
 Receives request to update
internal state
 Emits notifications of new
game state on request
or when state changes
 Does NOT compute new
state
 Just a data store

GameState Component
import c2.framework.*;

public class GameState extends ComponentThread{

public GameState(){
super.create("gameState", FIFOPort.class);
}

//Internal game state and initial values

int altitude = 1000;
int fuel = 500;
int velocity = 70;
int time = 0;
int burnRate = 0;
boolean landedSafely = false;

100

GameState Component
protected void handle(Request r){
if(r.name().equals("updateGameState")){
//Update the internal game state
if(r.hasParameter("altitude")){
import c2.framework.*;
this.altitude = ((Integer)r.getParameter("altitude")).intValue();
}
public class GameState extends ComponentThread{
if(r.hasParameter("fuel")){
this.fuel = ((Integer)r.getParameter("fuel")).intValue();
public GameState(){
}
super.create("gameState", FIFOPort.class);
} if(r.hasParameter("velocity")){
this.velocity = ((Integer)r.getParameter("velocity")).intValue();
}
//Internal game state and initial values
if(r.hasParameter("time")){
int altitude = 1000;
int fuel this.time
= 500; = ((Integer)r.getParameter("time")).intValue();
}
int velocity = 70;
if(r.hasParameter("burnRate")){
int time = 0;
this.burnRate
int burnRate = 0; = ((Integer)r.getParameter("burnRate")).intValue();
boolean} landedSafely = false;
if(r.hasParameter("landedSafely")){
this.landedSafely = ((Boolean)r.getParameter("landedSafely"))
.booleanValue();
}
//Send out the updated game state
Notification n = createStateNotification();
send(n); 101
}
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

GameState Component
protected else
void if(r.name().equals("getGameState")){
//If
handle(Request r){
a component requests the game state
if(r.name().equals("updateGameState")){
//Update//without updating
the internal gameit, send out the state
state
if(r.hasParameter("altitude")){
import c2.framework.*;
Notification
this.altitude n = createStateNotification();
= ((Integer)r.getParameter("altitude")).intValue();
} send(n);
public class GameState extends ComponentThread{
}
if(r.hasParameter("fuel")){
}
this.fuel = ((Integer)r.getParameter("fuel")).intValue();
public GameState(){
}
super.create("gameState", FIFOPort.class);
protected Notification createStateNotification(){
if(r.hasParameter("velocity")){
}
//Create a new
this.velocity notification comprising the
= ((Integer)r.getParameter("velocity")).intValue();
} //current game state
//Internal game state and initial values
if(r.hasParameter("time")){
int altitude = 1000;
Notification
this.time n = new Notification("gameState");
= ((Integer)r.getParameter("time")).intValue();
int fuel = 500;
} n.addParameter("altitude", altitude);
int velocity = 70;
n.addParameter("fuel",
if(r.hasParameter("burnRate")){ fuel);
int time = 0;
n.addParameter("velocity",
this.burnRate velocity);
= ((Integer)r.getParameter("burnRate")).intValue();
int burnRate = 0;
n.addParameter("time", time);
boolean} landedSafely = false;
n.addParameter("burnRate", burnRate);
if(r.hasParameter("landedSafely")){
n.addParameter("landedSafely",
this.landedSafely landedSafely);
= ((Boolean)r.getParameter("landedSafely"))
return n;
.booleanValue();
} }
protected
//Send void
out the handle(Notification
updated game state n){
//This component
Notification does not handle notifications
n = createStateNotification();
}
send(n); 102
} }
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

Implementing Lunar Lander in C2

 Third: GameLogic
Component
 Receives notifications of
game state changes
 Receives clock ticks
 On clock tick notification,
calculates new state
and sends request up

103

GameLogic Component
import c2.framework.*;

public class GameLogic extends ComponentThread{

public GameLogic(){
super.create("gameLogic", FIFOPort.class);
}

//Game constants
final int GRAVITY = 2;

//Internal state values for computation

int altitude = 0;
int fuel = 0;
int velocity = 0;
int time = 0;
int burnRate = 0;

public void start(){

super.start();
Request r = new Request("getGameState");
send(r);
}
104

GameLogic Component
protected void handle(Notification n){
if(n.name().equals("gameState")){
import c2.framework.*;
if(n.hasParameter("altitude")){
this.altitude =
public class GameLogic extends ComponentThread{
((Integer)n.getParameter("altitude")).intValue();
public GameLogic(){
}
super.create("gameLogic", FIFOPort.class);
if(n.hasParameter("fuel")){
} this.fuel =
((Integer)n.getParameter("fuel")).intValue();
//Game constants
}
final int GRAVITY = 2;
if(n.hasParameter("velocity")){
this.velocity =
//Internal state values for computation
((Integer)n.getParameter("velocity")).intValue();
int altitude
} = 0;
int fuel = if(n.hasParameter("time")){
0;
int velocity this.time
= 0; =
int time = 0; ((Integer)n.getParameter("time")).intValue();
int burnRate
} = 0;
if(n.hasParameter("burnRate")){
public void start(){
this.burnRate =
super.start();((Integer)n.getParameter("burnRate")).intValue();
Request r} = new Request("getGameState");
send(r);
}
}
105

GameLogic Component
protected void handle(Notification n){
if(n.name().equals("gameState")){
else
import if(n.name().equals("clockTick")){
if(n.hasParameter("altitude")){
c2.framework.*;
//Calculate new lander= state values
this.altitude
public int
classactualBurnRate
GameLogic = burnRate;
((Integer)n.getParameter("altitude")).intValue();
extends ComponentThread{
if(actualBurnRate
}
public GameLogic(){ > fuel){
//Ensure we don’t burnFIFOPort.class);
more fuel than we have
if(n.hasParameter("fuel")){
super.create("gameLogic",
} actualBurnRate
this.fuel == fuel;
} ((Integer)n.getParameter("fuel")).intValue();
}
//Game constants
finaltime
int =GRAVITY
time + =1;2;
if(n.hasParameter("velocity")){
altitudethis.velocity
= altitude - =velocity;
velocity
//Internal =((Integer)n.getParameter("velocity")).intValue();
state ((velocity
values for+ computation
GRAVITY) * 10 –
actualBurnRate
int altitude } = 0; * 2) / 10;
fuel ==if(n.hasParameter("time")){
int fuel fuel - actualBurnRate;
0;
int velocity this.time
= 0; =
//Determine
int time if we landed (safely)
= 0; ((Integer)n.getParameter("time")).intValue();
boolean
int burnRate } landedSafely
= 0; = false;
if(altitude <= 0){
if(n.hasParameter("burnRate")){
public altitude = 0;
this.burnRate
void start(){ =
if(velocity
super.start(); <= 5){
((Integer)n.getParameter("burnRate")).intValue();
RequestlandedSafely = true;
r} = new Request("getGameState");
} }
send(r);
} }
106

GameLogic Component
protected void handle(Notification n){
if(n.name().equals("gameState")){
else if(n.name().equals("clockTick")){
if(n.hasParameter("altitude")){
import //Calculate
c2.framework.*; new lander= state values
this.altitude
int actualBurnRate = burnRate;
((Integer)n.getParameter("altitude")).intValue();
public if(actualBurnRate
class }GameLogic extends > fuel){ComponentThread{
public //Ensure
GameLogic(){
Request werdon’t
= newburn
Request("updateGameState");
more fuel than we have
if(n.hasParameter("fuel")){
super.create("gameLogic",
r.addParameter("time",
actualBurnRate
this.fuel == fuel; FIFOPort.class);
time);
} } r.addParameter("altitude", altitude);
((Integer)n.getParameter("fuel")).intValue();
r.addParameter("velocity",
} velocity);
//Game constants
time = r.addParameter("fuel",
time + 1; fuel);
if(n.hasParameter("velocity")){
finalaltitude
int r.addParameter("landedSafely",
GRAVITY = 2;
= altitude
this.velocity - =velocity; landedSafely);
velocitysend(r);
=((Integer)n.getParameter("velocity")).intValue();
((velocity + GRAVITY) * 10 –
//Internal} } state
actualBurnRate values for/ computation
* 2) 10;
int altitude
}
fuel = 0;
=if(n.hasParameter("time")){
fuel - actualBurnRate;
int fuel = 0;this.time =
int velocity
protected
//Determine = ((Integer)n.getParameter("time")).intValue();
0;
void
if wehandle(Request
landed (safely) r){
int time
boolean= }0;landedSafely
//This component does not handle requests
= false;
int burnRate
}
if(altitude = 0;<= 0){
if(n.hasParameter("burnRate")){
} altitude = 0;
this.burnRate =
public if(velocity
void start(){ <= 5){
((Integer)n.getParameter("burnRate")).intValue();
super.start();
landedSafely
} = true;
Request} } r = new Request("getGameState");
send(r);
}
} 107

Implementing Lunar Lander in C2

 Fourth: GUI Component

 Reads burn rates from
user and sends them
up as requests
 Receives notifications of
game state changes and
formats them to console

108

GUI Component
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

import c2.framework.*;

public class GUI extends ComponentThread{

public GUI(){
super.create("gui", FIFOPort.class);
}

public void start(){

super.start();
Thread t = new Thread(){
public void run(){
processInput();
}
};
t.start();
}

109

public void processInput(){

GUI Component
System.out.println("Welcome to Lunar Lander");
try{
BufferedReader inputReader = new BufferedReader(
new InputStreamReader(System.in));
import java.io.BufferedReader;
import java.io.IOException;
int burnRate = 0;
import java.io.InputStreamReader;
do{
System.out.println("Enter burn rate or <0 to quit:");
import c2.framework.*;
try{
public class GUI String
extendsburnRateString = inputReader.readLine();
ComponentThread{
public GUI(){ burnRate = Integer.parseInt(burnRateString);
super.create("gui", FIFOPort.class);
} Request r = new Request("updateGameState");
r.addParameter("burnRate", burnRate);
send(r);
public void start(){
}
super.start();
Thread t = catch(NumberFormatException
new Thread(){ nfe){
public voidSystem.out.println("Invalid
run(){ burn rate.");
}
processInput();
} }while(burnRate >= 0);
}; inputReader.close();
}
t.start();
} catch(IOException ioe){
ioe.printStackTrace();
}
} 110

public void processInput(){

GUI Component
System.out.println("Welcome to Lunar Lander");
protected try{
void handle(Notification n){
BufferedReader inputReader = new BufferedReader(
if(n.name().equals("gameState")){
import java.io.BufferedReader;
new InputStreamReader(System.in));
System.out.println();
import java.io.IOException; game state:");
System.out.println("New
import java.io.InputStreamReader;
int burnRate = 0;
do{
if(n.hasParameter("altitude")){
import c2.framework.*;
System.out.println("Enter
System.out.println(" Altitude: " burn rate or <0 to quit:");
+ n.getParameter("altitude"));
} try{
public class GUI String
extendsburnRateString
ComponentThread{
if(n.hasParameter("fuel")){ = inputReader.readLine();
publicSystem.out.println("
GUI(){ burnRate = Integer.parseInt(burnRateString);
Fuel: " + n.getParameter("fuel"));
super.create("gui",
} FIFOPort.class);
} if(n.hasParameter("velocity")){
Request r = new Request("updateGameState");
r.addParameter("burnRate",
System.out.println(" burnRate);
Velocity: " + n.getParameter("velocity"));
public
} void start(){
send(r);
super.start();
}
if(n.hasParameter("time")){
Thread t = catch(NumberFormatException
new Thread(){ Time: " + n.getParameter("time"));
System.out.println(" nfe){
}public voidSystem.out.println("Invalid
run(){ burn rate.");
processInput();
}
if(n.hasParameter("burnRate")){
} System.out.println("
}while(burnRate >= 0);rate: " + n.getParameter("burnRate"));
Burn
};
} inputReader.close();
t.start();
}
} catch(IOException ioe){
ioe.printStackTrace();
}
} 111

public void processInput(){

GUI Component
System.out.println("Welcome to Lunar Lander");
try{
protectedif(n.hasParameter("altitude")){
void handle(Notification n){
BufferedReader inputReader = new BufferedReader(
if(n.name().equals("gameState")){
int altitude =
import java.io.BufferedReader;
new InputStreamReader(System.in));
System.out.println();
((Integer)n.getParameter("altitude")).intValue();
import java.io.IOException;
System.out.println("New
if(altitude game state:");
int burnRate<= = 0){
import java.io.InputStreamReader;
0;
boolean landedSafely =
do{
if(n.hasParameter("altitude")){
((Boolean)n.getParameter("landedSafely"))
import c2.framework.*;
System.out.println("Enter burn rate or <0 to quit:");
System.out.println(" Altitude: " + n.getParameter("altitude"));
.booleanValue();
try{
} if(landedSafely){
public class GUI extendsburnRateString
ComponentThread{
String = inputReader.readLine();
if(n.hasParameter("fuel")){
public GUI(){ System.out.println("You have landed safely.");
burnRate = Integer.parseInt(burnRateString);
System.out.println("
}
super.create("gui", Fuel: " +
FIFOPort.class); n.getParameter("fuel"));
} } else{
Request r = new Request("updateGameState");
if(n.hasParameter("velocity")){
System.out.println("You have crashed.");
r.addParameter("burnRate", burnRate);
System.out.println("
} send(r);
public void start(){ Velocity: " + n.getParameter("velocity"));
} System.exit(0);
super.start();
}
if(n.hasParameter("time")){
}
Thread t = catch(NumberFormatException
new Thread(){ nfe){
System.out.println("
} Time: " +
public voidSystem.out.println("Invalid
run(){ n.getParameter("time"));
burn rate.");
} processInput();
} }
if(n.hasParameter("burnRate")){
}} }while(burnRate >= 0);
}; System.out.println("
inputReader.close();
Burn rate: " + n.getParameter("burnRate"));
}protected void handle(Request r){
t.start();
}
} //This component does
catch(IOException not handle requests
ioe){
} ioe.printStackTrace();
} }
} 112

Implementing Lunar Lander in C2

 Lastly, main program

 Instantiates and connects
all elements of the system

113

import c2.framework.*;
Main Program
public class LunarLander{

public static void main(String[] args){

//Create the Lunar Lander architecture
Architecture lunarLander = new
SimpleArchitecture("LunarLander");

//Create the components

Component clock = new Clock();
Component gameState = new GameState();
Component gameLogic = new GameLogic();
Component gui = new GUI();

//Create the connectors

Connector bus = new ConnectorThread("bus");

//Add the components and connectors to the architecture

lunarLander.addComponent(clock);
lunarLander.addComponent(gameState);
lunarLander.addComponent(gameLogic);
lunarLander.addComponent(gui);

lunarLander.addConnector(bus);
114

import c2.framework.*;
Main Program
public class LunarLander{

public static void main(String[] args){

//Create the Lunar Lander architecture
Architecture lunarLander = new
SimpleArchitecture("LunarLander");
//Create the welds (links) between components and
//connectors
//Create the components
lunarLander.weld(clock, bus);
Component clock = new Clock();
lunarLander.weld(gameState, bus);
Component gameState = new GameState();
lunarLander.weld(bus, gameLogic);
Component gameLogic = new GameLogic();
lunarLander.weld(bus, gui);
Component gui = new GUI();
//Start the application
//Create the connectors
lunarLander.start();
Connector
} bus = new ConnectorThread("bus");
}
//Add the components and connectors to the architecture
lunarLander.addComponent(clock);
lunarLander.addComponent(gameState);
lunarLander.addComponent(gameLogic);
lunarLander.addComponent(gui);

lunarLander.addConnector(bus);
115

Takeaways

 Here, the C2 framework provides most all of the scaffolding we

need
 Message routing and buffering

 How to format a message

 Threading for components

 Startup and instantiation

 We provide the component behavior

 Including a couple new threads of our own

 We still must work to obey the style guidelines

 Not everything is optimal: state is duplicated in Game Logic, for
example

116
Applied
Architectures

Software Architecture
Lecture 17

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Objectives

 Illustrate how principles have been used to solve

challenging problems
 Usually means combining elements

 Highlight some critical issues

 I.e., ignore them at your peril

 Show how architecture can be used to explain and

analyze common commercial systems

118
Software Architecture: Foundations, Theory, and Practice

Outline

 Distributed and networked architectures

 Limitations

 REST

 Commercial Internet-scale applications

 Decentralized applications
 Peer-to-peer

 Web services

 Some interesting domains

 Robotics

 Wireless sensors

 Flight simulators
119
Software Architecture: Foundations, Theory, and Practice

Limitations of the Distributed Systems

Viewpoint
 The network is reliable
 Latency is zero
 Bandwidth is infinite
 The network is secure
 Topology doesn’t change
 There is one administrator
 Transport cost is zero
 The network is homogeneous
-- Deutsch & Gosling

120
Software Architecture: Foundations, Theory, and Practice

Architecture in Action: WWW

 (From lecture #1) This is the Web

121

Architecture in Action: WWW

(cont’d)
 So is this

122

Architecture in Action: WWW

 And this

123

WWW’s Architecture
 The application is distributed (actually, decentralized)
hypermedia
 Architecture of the Web is wholly separate from the code
 There is no single piece of code that implements the
architecture.
 There are multiple pieces of code that implement the various
components of the architecture.
 E.g., different Web browsers
 Stylistic constraints of the Web’s architectural style are not
apparent in the code
 The effects of the constraints are evident in the Web
 One of the world’s most successful applications is only
understood adequately from an architectural vantage point.
124
Software Architecture: Foundations, Theory, and Practice

REST Principles
 [RP1] The key abstraction of information is a resource,
named by an URL. Any information that can be named
can be a resource.
 [RP2] The representation of a resource is a sequence of
bytes, plus representation metadata to describe those
bytes. The particular form of the representation can be
negotiated between REST components.
 [RP3] All interactions are context-free: each interaction
contains all of the information necessary to understand
the request, independent of any requests that may have
preceded it.

125
Software Architecture: Foundations, Theory, and Practice

REST Principles (cont’d)

 [RP4] Components perform only a small set of well-

defined methods on a resource producing a
representation to capture the current or intended state
of that resource and transfer that representation
between components. These methods are global to the
specific architectural instantiation of REST; for instance,
all resources exposed via HTTP are expected to support
each operation identically.

126
Software Architecture: Foundations, Theory, and Practice

REST Principles (cont’d)

 [RP5] Idempotent operations and representation

metadata are encouraged in support of caching and
representation reuse.
 [RP6] The presence of intermediaries is promoted.
Filtering or redirection intermediaries may also use both
the metadata and the representations within requests or
responses to augment, restrict, or modify requests and
responses in a manner that is transparent to both the
user agent and the origin server.

127
Software Architecture: Foundations, Theory, and Practice

REST Constraints
 Client–server A uniform interface separates clients from servers.
This separation of concerns means that, for example, clients are not
concerned with data storage, which remains internal to each server,
so that the portability of client code is improved. Servers are not
concerned with the user interface or user state, so that servers can be
simpler and more scalable. Servers and clients may also be replaced
and developed independently, as long as the interface between them
is not altered.
 Stateless The client–server communication is further constrained by
no client context being stored on the server between requests. Each
request from any client contains all of the information necessary to
service the request, and session state is held in the client. Important
to note is that the session state can be transferred by the server to
another service such as a database to maintain a persistent state for a
period of time and allow authentication.
128
Software Architecture: Foundations, Theory, and Practice

REST Constraints
 Cacheable As on the World Wide Web, clients can cache
responses. Responses must therefore, implicitly or
explicitly, define themselves as cacheable, or not, to
prevent clients reusing stale or inappropriate data in
response to further requests. Well-managed caching
partially or completely eliminates some client–server
interactions, further improving scalability and
performance.
 Layered system A client cannot ordinarily tell whether it
is connected directly to the end server, or to an
intermediary along the way. Intermediary servers may
improve system scalability by enabling load-balancing
and by providing shared caches. They may also enforce
129
security policies.
Software Architecture: Foundations, Theory, and Practice

REST Constraints
 Code on demand (optional) Servers can temporarily
extend or customize the functionality of a client by the
transfer of executable code. Examples of this may
include compiled components such as Java applets and
client-side scripts such as JavaScript. "Code on demand"
is the only optional constraint of the REST architecture.
 Uniform interface The uniform interface between clients
and servers, discussed below, simplifies and decouples
the architecture, which enables each part to evolve
independently. The four guiding principles of this
interface are detailed below.

130
Software Architecture: Foundations, Theory, and Practice

An Instance of REST

Pro xy Gateway Origin Servers

$ $ o rb
h ttp h ttp
h ttp
a
User Agent DNS
b
$ $
h ttp
c Pro xy

DNS $
h ttp wais

Client Con nector: Client+Cach e: $ Server Co nn ecto r: Server+Cach e: $

131
Software Architecture: Foundations, Theory, and Practice

REST — Data Elements

 Resource
 Key information abstraction

 Resource ID
 Representation
 Data plus metadata

 Representation metadata
 Resource metadata
 Control data
 e.g., specifies action as result of message

132
Software Architecture: Foundations, Theory, and Practice

REST — Connectors

 Modern Web Examples

 client libwww, libwww-perl
 server libwww, Apache API, NSAPI
 cache browser cache, Akamai cache network
 resolver bind (DNS lookup library)
 tunnel SOCKS, SSL after HTTP CONNECT

133
Software Architecture: Foundations, Theory, and Practice

REST — Components
 User agent
 e.g., browser

 Origin server
 e.g., Apache Server, Microsoft IIS

 Proxy
 Selected by client

 Gateway
 Squid, CGI, Reverse proxy

 Controlled by server

134
Software Architecture: Foundations, Theory, and Practice

An Instance of REST

Pro xy Gateway Origin Servers

$ $ o rb
h ttp h ttp
h ttp
a
User Agent DNS
b
$ $
h ttp
c Pro xy

DNS $
h ttp wais

Client Con nector: Client+Cach e: $ Server Co nn ecto r: Server+Cach e: $

135
Software Architecture: Foundations, Theory, and Practice

Derivation of REST

Key choices in this derivation include:

 Layered Separation (a theme in the middle portion of
diagram) is used to increase efficiencies, enable
independent evolution of elements of the system, and
provide robustness;
 Replication (left side of the diagram) is used to address
latency and contention by allowing the reuse of
information;
 Limited commonality (right side) addresses the
competing needs for universally understood operations
with extensibility.
The derivation is driven by the application(!)
136
Software Architecture: Foundations, Theory, and Practice

Derivation of REST (cont’d)

137

REST: Final Thoughts

 REpresentational State Transfer

 Style of modern web architecture
 Web architecture one of many in style

 Web diverges from style on occasion

 e.g., Cookies, frames

 Doesn’t explain mashups

138
Software Architecture: Foundations, Theory, and Practice

Commercial Internet-Scale
Applications
 Akamai
 Caching to the max

 Google
 Google distributed file system (GFS)

 MapReduce

 Data selection and reduction

 All parallelization done automatically

139
Software Architecture: Foundations, Theory, and Practice

Architectural Lessons from Google

 Abstraction layers abound: GFS hides details of data

distribution and failure, for instance; MapReduce hides
the intricacies of parallelizing operations;
 By designing, from the outset, for living with failure of
processing, storage, and network elements, a highly
robust system can be created;
 Scale is everything: Google’s business demands that
everything be built with scaling issues in mind;

140
Software Architecture: Foundations, Theory, and Practice

Architectural Lessons from Google

(cont’d)
 By specializing the design to the problem domain,
rather than taking the generic “industry standard”
approach, high performance and very cost-effective
solutions can be developed;
 By developing a general approach (MapReduce) to
the data extraction/reduction problem, a highly reusable
service was created.

141
Applied Architectures,
Part 2

Software Architecture
Lecture 18

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Decentralized Architectures

 Networked applications where there are multiple

authorities
 In other words
 Computation is distributed

 Parts of the network may behave differently, and vary

over time

It’s just like collaboration in the real

world

143
Software Architecture: Foundations, Theory, and Practice

Grid Protocol Architecture

 Coordinated resource sharing in a
distributed environment
 E.g., Folding-at-home

 GLOBUS
 A commonly used infrastructure

 “Standard architecture”
 Fabric manages low-level
resources
 Connectivity: communication and
authentication
 Resource: sharing of a single r.

 Collective: coordinating r. usage

144

Grid GLOBUS (Recovered)

145

Peer-to-Peer Architectures

 Decentralized resource sharing and discovery

 Napster

 Gnutella

 P2P that works: Skype

 And BitTorrent

146
Software Architecture: Foundations, Theory, and Practice

Peer-to-Peer Style
 State and behavior are distributed among peers
which can act as either clients or servers.
 Peers: independent components, having their own
state and control thread.
 Connectors: Network protocols, often custom.
 Data Elements: Network messages
 Topology: Network (may have redundant connections
between peers); can vary arbitrarily and dynamically
 Supports decentralized computing with flow of
control and resources distributed among peers.
Highly robust in the face of failure of any given node.
Scalable in terms of access to resources and
computing power. But caution on the protocol!
147
Software Architecture: Foundations, Theory, and Practice

Peer-to-Peer LL

148

Napster (“I am the Napster!”)

--Lyle, “The Italian Job” (2003)

149

Gnutella (original)

150

Skype

151

Insights from Skype

 A mixed client-server and peer-to-peer architecture addresses
the discovery problem.
 Replication and distribution of the directories, in the form of
supernodes, addresses the scalability problem and robustness
problem encountered in Napster.
 Promotion of ordinary peers to supernodes based upon
network and processing capabilities addresses another aspect
of system performance: “not just any peer” is relied upon for
important services.
 A proprietary protocol employing encryption provides privacy
for calls that are relayed through supernode intermediaries.
 Restriction of participants to clients issued by Skype, and
making those clients highly resistant to inspection or
modification, prevents malicious clients from entering the
network.
152
Software Architecture: Foundations, Theory, and Practice

Web Services

153

Web Services (cont’d)

154

Mobile Robotics
 Manned or partially manned vehicles
 Uses
 Space exploration

 Hazardous waste disposal

 Underwater exploration

 Issues
 Interface with external sensors & actuators

 Real-time response to stimuli

 Response to obstacles

 Sensor input fidelity

 Power failures

 Mechanical limitations

 Unpredictable events
155
Software Architecture: Foundations, Theory, and Practice

Robotics: Sense-Plan-Act

156

Robotics Subsumption
Architecture

157

Robotics: Three-Layer

158

Wireless Sensor Networks

159

Flight Simulators: Key

Characteristics
 Real-time performance constraints
 Extremely high fidelity demands

 Requires distributed computing

 Must execute at high fixed frame rates
 Often called harmonic frequencies
 e.g. often 60Hz, 30Hz; some higher (100Hz)

 Coordination across simulator components

 All portions of simulator run at integral multiple of base
rate
 e.g. if base rate = 60Hz, then 30Hz, 15Hz, 12Hz, etc.
 Every task must complete on time
 Delays can cause simulator sickness 160
Software Architecture: Foundations, Theory, and Practice

Flight Simulators: Key

Characteristics (cont’d)
 Continuous evolution
 Very large & complex
 Millions of SLOC

 Exponential growth over lifetime of simulator

 Distributed development
 Portions of work subcontracted to specialists

 Long communication paths increase integration complexity

 Expensive verification & validation

 Direct by-product of above characteristics

 Mapping of Simulation SW to HW components unclear

 Efficiency muddies abstraction

 Needed because of historical HW limitations 161

Software Architecture: Foundations, Theory, and Practice

Functional Model

Cockpit
Simulation Displays Cockpit
Models Controls
Visual
Air Cueing
Vehicle System
Crew
Motion
Cueing
Environment
System

Audio
Cueing
Instructor/ System
Operator
Station 162
Software Architecture: Foundations, Theory, and Practice

How Is the Complexity Managed?

 New style
 “Structural Modeling”

 Based on

 Object–oriented design to model air vehicle’s

 Sub-systems
 Components

 Real-time scheduling to control execution order

 Goals of Style
 Maintainability

 Integrability

 Scalability
163
Software Architecture: Foundations, Theory, and Practice

How Is the Complexity Managed?

(cont’d)
 Style principles
 Pre-defined partitioning of functionality among SW
elements
 Restricted data- & control-flow

 Data-flow through export areas only

 Decoupling objects
 Small number of element types
 Results in replicated subsystems

164
Software Architecture: Foundations, Theory, and Practice

How Is the Complexity Managed?

(cont’d)
 Style principles (continued)
 Objects fully encapsulate their own internal state

 No side-effects of computations

 Narrow set of system-wide coordination strategies

 Employs pre-defined mechanisms for data &

control passing
 Enable component communication &
synchronization

165
Software Architecture: Foundations, Theory, and Practice

F-Sim In The Structural Modeling

Style
 Five basic computational elements in two classes
 Executive (or infrastructure)

 Periodic sequencer
 Event handler
 Synchronizer
 Application

 Components
 Subsystems
 Each of the five has
 Small API

 Encapsulated state

 Severely limited external data upon which it relies 166

Software Architecture: Foundations, Theory, and Practice

Level–0 Architecture

167
Software Architecture: Foundations, Theory, and Practice

Level–1 Architecture

168
Software Architecture: Foundations, Theory, and Practice

Takeaways

 A great architecture is the ticket to runaway success

 A great architecture reflects deep understanding of the
problem domain
 A great architecture probably combines aspects of
several simpler architectures
 Develop a new architectural style with great care and
caution. Most likely you don’t need a new style.

169
Designing for NFPs

Software Architecture
Lecture 19

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

What Is an NFP?

 A software system’s non-functional property (NFP)

is a constraint on the manner in which the system
implements and delivers its functionality
 Example NFPs
 Efficiency

 Complexity

 Scalability

 Heterogeneity

 Adaptability

 Dependability
2
Software Architecture: Foundations, Theory, and Practice

Designing for FPs

 Any engineering product is sold based on its functional properties
(FPs)
 TV set, DVD player, stereo, mobile telephone
 Providing the desired functionality is often quite challenging
 Market demands
 Competition
 Strict deadlines
 Limited budgets
 However, the system’s success will ultimately rest on its NFPs
 “This system is too slow!”
 “It keeps crashing!”
 “It has so many security holes!”
 “Every time I change this feature I have to reboot!”
 “I can’t get it to work with my home theater!”
3
Software Architecture: Foundations, Theory, and Practice

FPs vs. NFPs – An Example

 Microsoft Word 6.0

 Released in the 1990s

 Both for the PC and the Mac

 Roughly the same functionality

 It ran fine on the PC and was successful

 It was extremely slow on the Mac

 Microsoft “solved” the problem by charging customers

for downgrades
 A lot of bad publicity

4
Software Architecture: Foundations, Theory, and Practice

FPs vs. NFPs – Another Example

 Linux – “as-documented” architecture

FPs vs. NFPs – Another Example

 Linux – “as-implemented” architecture

Challenges of Designing for NFPs

 Only partially understood in many domains

 E.g., MS Windows and security

 Qualitative vs. quantitative

 Frequently multi-dimensional
 Non-technical pressures
 E.g., time-to-market or functional features

7
Software Architecture: Foundations, Theory, and Practice

Design Guidelines for Ensuring

NFPs
 Only guidelines, not laws or rules
 Promise but do not guarantee a given NFP
 Necessary but not sufficient for a given NFP
 Have many caveats and exceptions
 Many trade-offs are involved

8
Software Architecture: Foundations, Theory, and Practice

Overarching Objective

 Ascertain the role of software architecture in ensuring

various NFPs
 At the level of major architectural building blocks

 Components
 Connectors
 Configurations
 As embodied in architectural style-level design
guidelines

9
Software Architecture: Foundations, Theory, and Practice

Efficiency

 Efficiency is a quality that reflects a software system’s

ability to meet its performance requirements while
minimizing its usage of the resources in its computing
environment
 Efficiency is a measure of a system’s resource usage
economy

 What can software architecture say about efficiency?

 Isn’t efficiency an implementation-level property?

 Efficiency starts at the architectural level!

10
Software Architecture: Foundations, Theory, and Practice

Software Components and

Efficiency
 Keep the components “small” whenever possible
 Keep component interfaces simple and compact
 Allow multiple interfaces to the same functionality
 Separate data components from processing components
 Separate data from meta-data

11
Software Architecture: Foundations, Theory, and Practice

Multiple Interfaces to the Same

Functionality

Software Connectors and

Efficiency
 Carefully select connectors
 Use broadcast connectors with caution
 Make use of asynchronous interaction whenever possible
 Use location/distribution transparency judiciously

13
Software Architecture: Foundations, Theory, and Practice

Distribution Transparency

Architectural Configurations and

Efficiency
 Keep frequently interacting components “close”
 Carefully select and place connectors in the architecture
 Consider the efficiency impact of selected architectural
styles and patterns

15
Software Architecture: Foundations, Theory, and Practice

Performance Penalty Induced by

Distance

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

Software Architecture
Lecture 20

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Complexity

 IEEE Definition
 Complexity is the degree to which a software
system or one of its components has a design or
implementation that is difficult to understand and
verify
 Complexity is a software system’s a property that is
directly proportional to the size of the system, number of
its constituent elements, their internal structure, and the
number and nature of their interdependencies

2
Software Architecture: Foundations, Theory, and Practice

Software Components and

Complexity
 Separate concerns into different components
 Keep only the functionality inside components
 Interaction goes inside connectors
 Keep components cohesive
 Be aware of the impact of off-the-shelf components on
complexity
 Insulate processing components from changes in data
format

3
Software Architecture: Foundations, Theory, and Practice

Software Connectors and

Complexity
 Treat connectors explicitly
 Keep only interaction facilities inside connectors
 Separate interaction concerns into different connectors
 Restrict interactions facilitated by each connector
 Be aware of the impact of off-the-shelf connectors on
complexity

4
Software Architecture: Foundations, Theory, and Practice

Architectural Configurations and

Complexity
 Eliminate unnecessary dependencies
 Manage all dependencies explicitly
 Use hierarchical (de)composition

5
Software Architecture: Foundations, Theory, and Practice

Complexity in Linux

Scalability and Heterogeneity

 Scalability is the capability of a software system to be adapted to

meet new requirements of size and scope
 Heterogeneity is the quality of a software system consisting of
multiple disparate constituents or functioning in multiple disparate
computing environments
 Heterogeneity is a software system’s ability to consist of
multiple disparate constituents or function in multiple disparate
computing environments
 Portability is a software system’s ability to execute on multiple
platforms with minimal modifications and without significant
degradation in functional or non-functional characteristics

7
Software Architecture: Foundations, Theory, and Practice

Software Components and

Scalability
 Give each component a single, clearly defined purpose
 Define each component to have a simple,
understandable interface
 Do not burden components with interaction
responsibilities
 Avoid unnecessary heterogeneity
 Results in architectural mismatch
 Distribute the data sources
 Replicate data when necessary

8
Software Architecture: Foundations, Theory, and Practice

Software Connectors and

Scalability
 Use explicit connectors
 Give each connector a clearly defined responsibility
 Choose the simplest connector suited for the task
 Be aware of differences between direct and indirect
dependencies
 Avoid placing application functionality inside connectors
 Application functionality goes inside components

 Leverage explicit connectors to support data scalability

9
Software Architecture: Foundations, Theory, and Practice

Architectural Configurations and

Scalability
 Avoid system bottlenecks
 Make use of parallel processing capabilities
 Place the data sources close to the data consumers
 Try to make distribution transparent
 Use appropriate architectural styles

10
Software Architecture: Foundations, Theory, and Practice

Adaptability

 Adaptability is a software system’s ability to satisfy

new requirements and adjust to new operating
conditions during its lifetime

11
Software Architecture: Foundations, Theory, and Practice

Software Components and

Adaptability
 Give each component a single, clearly defined purpose
 Minimize component interdependencies
 Avoid burdening components with interaction
responsibilities
 Separate processing from data
 Separate data from metadata

12
Software Architecture: Foundations, Theory, and Practice

Software Connectors and

Adaptability
 Give each connector a clearly defined responsibility
 Make the connectors flexible
 Support connector composability

13
Software Architecture: Foundations, Theory, and Practice

Composable Connectors

Architectural Configurations and

Adaptability
 Leverage explicit connectors
 Try to make distribution transparent
 Use appropriate architectural styles

15
Software Architecture: Foundations, Theory, and Practice

Dependability
 Dependability is a collection of system properties that allows
one to rely on a system functioning as required
 Reliability is the probability that a system will perform its
intended functionality under specified design limits, without
failure, over a given time period
 Availability is the probability that a system is operational at
a particular time
 Robustness is a system’s ability to respond adequately to
unanticipated runtime conditions
 Fault-tolerant is a system’s ability to respond gracefully to
failures at runtime
 Survivability is a system’s ability to resist, recognize,
recover from, and adapt to mission-compromising threats
 Safety denotes the ability of a software system to avoid
failures that will result in (1) loss of life, (2) injury, (3)
significant damage to property, or (4) destruction of
property 16
Software Architecture: Foundations, Theory, and Practice

Software Components and

Dependability
 Carefully control external component inter-dependencies
 Provide reflection capabilities in components
 Provide suitable exception handling mechanisms
 Specify the components’ key state invariants

17
Software Architecture: Foundations, Theory, and Practice

Software Connectors and

Dependability
 Employ connectors that strictly control component
dependencies
 Provide appropriate component interaction guarantees
 Support dependability techniques via advanced
connectors

18
Software Architecture: Foundations, Theory, and Practice

Architectural Configurations and

Dependability
 Avoid single points of failure
 Provide back-ups of critical functionality and data
 Support non-intrusive system health monitoring
 Support dynamic adaptation

19
Security and Trust

Software Architecture
Lecture 21

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Outline

 Security
 Design Principles
 Architectural Access Control
 Access Control Models
 Connector-Centric Architectural Access Control
 Trust
 Trust Model
 Reputation-based Systems
 Architectural Approach to Decentralized Trust
Management

2
Software Architecture: Foundations, Theory, and Practice

Security

 “The protection afforded to an automated information

system in order to attain the applicable objectives of
preserving the integrity, availability and
confidentiality of information system resources
(includes hardware, software, firmware,
information/data, and telecommunications).”
 National Institute of Standards and Technology

3
Software Architecture: Foundations, Theory, and Practice

Confidentiality, Integrity, and

Availability
 Confidentiality
 Preserving the confidentiality of information means
preventing unauthorized parties from accessing the
information or perhaps even being aware of the existence
of the information. I.e., secrecy.
 Integrity
 Maintaining the integrity of information means that only
authorized parties can manipulate the information and do
so only in authorized ways.
 Availability
 Resources are available if they are accessible by
authorized parties on all appropriate occasions.

4
Software Architecture: Foundations, Theory, and Practice

Design Principles for Computer

Security
 Least Privilege: give each component only the
privileges it requires
 Fail-safe Defaults: deny access if explicit permission is
absent
 Economy of Mechanism: adopt simple security
mechanisms
 Complete Mediation: ensure every access is permitted
 Design: do not rely on secrecy for security

5
Software Architecture: Foundations, Theory, and Practice

Design Principles for Computer

Security (cont’d)
 Separation of Privilege: introduce multiple parties to
avoid exploitation of privileges
 Least Common Mechanism: limit critical resource
sharing to only a few mechanisms
 Psychological Acceptability: make security
mechanisms usable
 Defense in Depth: have multiple layers of
countermeasures

6
Software Architecture: Foundations, Theory, and Practice

Security for Microsoft IIS

--from [Wing, 2003] 7

Software Architecture: Foundations, Theory, and Practice

Architectural Access Control

Models
 Decide whether access to a protected resource should
be granted or denied
 Discretionary access control
 Based on the identity of the requestor, the resource,
and whether the requestor has permission to access
 Mandatory access control
 Policy based

8
Software Architecture: Foundations, Theory, and Practice

Discretionary Access Control

Database A Component Q Interface F

Alice Read-Write; Bend Yes

Always
Bob Read-Write; Fold No
Between 9 and
5
Charles No access Spindle No

Dave No access Mutilate Yes

Eve Read-only; None No

Always
9
Software Architecture: Foundations, Theory, and Practice

Mandatory Access Control

 Bob: Secret
 Alice: Confidential
 Tom: Top Secret

Arrows show access (read/write) privileges

What about just appending?
10
Software Architecture: Foundations, Theory, and Practice

Connector-Centric Architectural
Access Control
 Decide what subjects the connected components are
executing for
 Regulate whether components have sufficient privileges
to communicate through the connectors
 Provide secure interaction between insecure components
 Propagate privileges in architectural access check
 Participate in deciding architectural connections
 Route messages according to established policies

Static analysis of architectures coupled with dynamic

checking
11
Software Architecture: Foundations, Theory, and Practice

Decentralization

 No centralized authority to coordinate and control

entities
 Independent peers, with possibly conflicting goals,
interact with each other and make local autonomous
decisions
 Presence of malicious peers in open decentralized
applications
 Need for measures to protect peers against malicious
attacks

12
Software Architecture: Foundations, Theory, and Practice

Some Threats of Decentralization

 Impersonation: Mallory says she is Bob to Alice

 Fraudulent Actions: Mallory doesn’t complete
transactions
 Misrepresenting Trust: Mallory tells everyone Bob is evil
 Collusion: Mallory and Eve tell everyone Bob is evil
 Addition of Unknowns: Alice has never met Bob
 Trust management can serve as a potential
countermeasure
 Trust relationships help peers establish
confidence in other peers
13
Software Architecture: Foundations, Theory, and Practice

Decentralized Auctioning
Carol

 Open decentralized Bob

application
 Independent
buyers/sellers Alice
Decentralized
 Potentially Auctioning
malicious
participants
 Need to counter
threats
Marvin Mallory
(malicious) (malicious)

14
Software Architecture: Foundations, Theory, and Practice

Impersonation
Bob
Alice

Bob is reliable and everyone

has a good opinion about Bob

“I am Bob”

Mallory
(malicious)
15
Software Architecture: Foundations, Theory, and Practice

Fraudulent Actions

Alice pays
for the items

Marvin does
Marvin “seller”
not ship the items Alice “buyer”
(malicious)

16
Software Architecture: Foundations, Theory, and Practice

Misrepresentation
Bob
Alice

Bob is reliable and everyone

has a good opinion about Bob

“Bob is unreliable”

Mallory
(malicious)
17
Software Architecture: Foundations, Theory, and Practice

Collusion
Bob
Alice

Bob is reliable and everyone

has a good opinion about Bob

“Bob is unreliable”

Marvin
(malicious) Mallory
(malicious)

18
Software Architecture: Foundations, Theory, and Practice

Addition of Unknowns
Carol
(new entrant in the system)

Bob has no information Carol is new and does not

about Carol; he is not sure know Alice; she is not sure
whether to interact with Carol whether to interact with Alice

Bob Alice

19
Software Architecture: Foundations, Theory, and Practice

Background: Trust Management

 Trust
 Trust is a particular level of the subjective probability with which
an agent assesses that another agent will perform a particular
action in a context that affects his actions [Gambetta, 1990]
 Reputation
 Expectation about an entity’s behavior based on past behavior
[Abdul-Rahman, 2000]
 May be used to determine trust

 Two types of trust management systems

 Credential and Policy-based

 Reputation-based

20
Software Architecture: Foundations, Theory, and Practice

Role of Trust Management

 Each entity (peer) must protect itself against these

threats
 Trust Management can serve as a potential
countermeasure
 Trust relationships between peers help establish
confidence
 Two types of decentralized trust management systems
 Credential and policy-based

 Reputation-based

21
Software Architecture: Foundations, Theory, and Practice

Architecture and Trust

Management
 Decentralized trust management has received a lot of
attention from researchers [Grandison and Sloman,
2000]
 Primary focus has been on developing new models

 But how does one build a trust-enabled

decentralized application?
 How do I pick a trust model for a given
application?
 And, how do I incorporate the trust model
within each entity?

22
Software Architecture: Foundations, Theory, and Practice

Approach

 Select a suitable reputation-based trust model for a

given application
 Describe this trust model precisely
 Incorporate the model within the structure (architecture)
of an entity
 Software architectural style for trust management
(PACE)
 Result – entity architecture consisting of
 components that encapsulate the trust model

 additional trust technologies to counter threats

23
Software Architecture: Foundations, Theory, and Practice

Key Insights
 Trust
 Cannot be isolated to one component

 Is a dominant concern in decentralized applications and

should be considered early on during application
development
 Having an explicit architecture is one way to consistently
address the cross-cutting concern of trust
 Architectural styles
 Provide a foundation to reason about specific goals

 Facilitate reuse of design knowledge

 Allow known benefits to be leveraged and induce desirable

properties
24
Software Architecture: Foundations, Theory, and Practice

Design Guidelines: Approach

 Identify threats of decentralization

 Use the threats to identify guiding principles that help
defend against the threats
 Incorporate these principles within an architectural style
focused on decentralized trust management

25
Software Architecture: Foundations, Theory, and Practice

Design Guidelines

Threats Strategies
Impersonation Digital identities, signature-based
verification
Fraudulent Actions Explicit trust, comparable trust
Misrepresentation Explicit trust, comparable trust,
separation of internal and external data
Collusion Explicit trust, comparable trust,
separation of internal and external data
Addition of unknowns Implicit trust of user

26
Software Architecture: Foundations, Theory, and Practice

PACE Architectural Style

 Basis: C2, a layered event-based style

 Allows the natural structuring of the four functional
units according to their dependencies
 Facilitates reuse

 Extensive tool support

 The resultant architectural style is called PACE (Practical

Architectural approach for Composing Egocentric trust)

27
Software Architecture: Foundations, Theory, and Practice

Functional Units

 Communication
 Responsible for external interaction with other peers
including data collection and transmission; does not
depend upon data storage or analysis
 Information
 Store all data including internal beliefs and reported
information
 Trust
 Responsible for trust computation and managing
credentials; depends upon internal data for computation
 Application
 Application-specific components including user interface;
Builds upon services provided by the other three
28
Software Architecture: Foundations, Theory, and Practice

PACE Components Multicast Handler

Communication
HTTP Sender Custom Protocols Multicast Manager

Layer
Communication
Manager

Signature Manager

Information
Layer
Internal External
Information Information

Credentia
Key Trust

Layer
Layer Trust
l
Manager Manager
Manager

Application
Application Trust Rules

APPLICATION
29
Software Architecture: Foundations, Theory, and Practice

PACE: Communication Multicast Handler

Layer

Communication
HTTP Sender Custom Protocols Multicast Manager

Layer
 Multiple protocol Communication Manager
handlers. Translate
internal events into
external messages and Signature Manager
vice-versa

Information
Creates and manages

Layer

Internal External
protocol handlers Information Information
 Signs requests and
verifies notifications
Key Credential Trust

Layer
Trust
Manager Manager Manager

Application
Application Trust Rules

Layer
APPLICATION 30
Software Architecture: Foundations, Theory, and Practice

PACE: Information Layer

Multicast Handler

Communication
HTTP Sender Custom Protocols Multicast Manager

Layer
Communication Manager

 Separates internal
beliefs from reported Signature Manager
information

Information
 Stores internal beliefs

Layer
persistently Internal External
Information Information

Key Credential Trust

Layer
Trust
Manager Manager Manager

Application
Application Trust Rules

Layer
APPLICATION 31
Software Architecture: Foundations, Theory, and Practice

PACE: Trust Layer

Multicast Handler

Communication
HTTP Sender Custom Protocols Multicast Manager

Layer
 Incorporates different
trust models and Communication Manager
algorithms; can
assign trust values to
Signature Manager
notifications received

Information
 Generates unique
public-private key

Layer
Internal External
pairs Information Information
 Maintains local cache
of other peers’ Key Credential Trust

Layer
identities; requests

Trust
Manager Manager Manager
public keys from
peers and responds
to revocations

Application
Application Trust Rules

Layer
APPLICATION 32
Software Architecture: Foundations, Theory, and Practice

Multicast Handler
PACE: Application Layer

Communication
HTTP Sender Custom Protocols Multicast Manager

Layer
Communication Manager
 Domain-specific
trust rules;
includes context Signature Manager
of trust

Information
 User-interface and

Layer
Internal External
application- Information Information
specific
components
Key Credential Trust

Layer
Trust
Manager Manager Manager

Application
Application Trust Rules

Layer
APPLICATION
33
Software Architecture: Foundations, Theory, and Practice

Multicast Handler
Countering Fraudulent Actions

Communication
HTTP Sender Custom Protocols Multicast Manager

Layer
 User sends request for
trust information Communication Manager
 Others respond
 Responses are verified Signature Manager
and tagged with trust

Information
values

Layer
 User sees these Internal External
messages and makes an Information Information
informed decision
 Post-interaction, user Key Credential Trust

Layer
Trust
can change trust Manager Manager Manager
information

Application
Application Trust Rules

Layer
APPLICATION
34
Software Architecture: Foundations, Theory, and Practice

Result: Decentralized Auctioning

Carol
Trust-enabled
Trust-enabled entity
entity
Bob
architecture
architecture

Alice
Decentralized Trust-enabled
entity
Auctioning architecture

Mallory
Marvin
(malicious) 35
(malicious)
Deployment and
Mobility

Software Architecture
Lecture 22

What Are Deployment and Mobility?

 Deployment is the process of placement of a system’s

software components on its hardware hosts
 Changing the deployment of a component during
runtime is called migration or redeployment
 Migration or redeployment is a type of software system
mobility
 Mobility entails a superset of deployment issues

2
Software Architecture: Foundations, Theory, and Practice

Deployment and Mobility

Challenges
 Widely distributed target processors
 Target processors embedded inside heterogeneous
devices
 Different software components may require different
hardware configurations
 System lifespans may stretch over decades and require
periodic maintenance mean require redeployment.
 Software system evolution is continuous (requiring
redeployment)
 Mobile code may mandate that running, stateful
components be redeployed
3
Software Architecture: Foundations, Theory, and Practice

Software Architecture and

Deployment
 A system is deployed to a set of hosts or sites
 Each site provides a set of resources needed by the
system’s components
 Hardware (memory, CPU)

 Network (protocol and IP port no.)

 Peripheral devices (HDD, keyboard)

 System software (OS, device driver, middleware)

 Other application software (GUI builder, database)

 Data resources (data files)

 Resources may be exclusive(IP port no.) or sharable

4
Software Architecture: Foundations, Theory, and Practice

How Is Deployment Changing ?

Then Now
 Complete Installation  Software producers and
procedure for software consumers cooperating
system on CD ROM and negotiating.
 Entire software system  “Update” of Software
installation Systems

All this because of high connectivity

5
Software Architecture: Foundations, Theory, and Practice

Deployment, Architecture, and Quality

of Service

 Deployment Architecture: allocation of s/w components to h/w hosts

 hc deployment architectures are possible for a given system
 Many provide the same functionality

 Provide different qualities of service (QoS)

6
Software Architecture: Foundations, Theory, and Practice

Deployment Activities
Architecture driven s/w deployment comprises a process
that must be carefully planned, modeled, analyzed, and
executed.
 Planning
 Modeling
 Analysis
 Implementation

7
Software Architecture: Foundations, Theory, and Practice

Deployment Planning
How do we find and effect a deployment architecture
that improves multiple QoS dimensions?

Scenario with a Single QoS

Dimension

Latency

Schedule

ModifyResourceMap ResourceMonitor

 Objective is to minimize latency

 The optimal deployment architecture is deployment 1 9

Conflicting QoS Dimensions

Durability Latency

Schedule

ModifyResourceMap ResourceMonitor

 Objective is to minimize latency and maximize durability (inverse of

energy consumption rate). Deployment reduces energy consumption
rate
 There is no optimal deployment architecture! 10

Resolving Trade-Offs between QoS

Dimensions
Commander

Durability Latency

 A utility function denotes a user’s

Schedule

ModifyResourceMap ResourceMonitor preferences for a given rate of

improvement in a QoS dimension

 Guiding Insight
 System users have
varying QoS preferences
for the system services  Allows expression of optimization
they access in terms of a single scalar value 11
Software Architecture: Foundations, Theory, and Practice

Dep 1

A Slightly Larger
20
Dep 2
Dep 3
18
Dep 4
Dep 5
16 Dep 6

Scenario
Dep 7
Durability (hours) x

14 Dep 8
Dep 9
12 Dep 10
Dep 11
Dep 12
10
Dep 13
Dep 14
8 Dep 15
Dep 16
Troop Commander Dispatcher
6 Dep 17
Dep 18
4 Dep 19
Dep 20
80 Dep 21
2
Dep 22
Dep 23
0 Dep 24
0 70 Security 5 10
Durability Latency
15 20 25 Dep 25
Dep 26 Troop, Latency, Exchange Plan
Latency (ms)
Dep 27
Troop, Latency, Schedule
60
Troop, Durability, Exchange Plan

Dep 1
Troop, Durability, Schedule Dep 1
40 50 Exchange Plan Schedule
Dep 2
40
Dep 2
Dep 3
Troop, Security, Exchange Plan Dep 3
Dep 4 35 Dep 4
Utility x

35
Troop, Security, Schedule
40ModifyResourceMap ResourceMonitor Dep 5
Dep 6
Dep 5
Dep 6
30 Dep 7 30 Commander, Latency, Exchange
Dep 7
Dep 8 Plan Dep 8

x
CreatePlan Commander, Latency, Schedule
Dep 9
30 Dep 9
x

25 25
Dep 10 Dep 10
Dep 11
Commander, Durability, Exchange
Dep 11
Plan
Security
Dep 12
Security

20 Dep 12
20
Dep 13
20 Dep 14
Dep 13
Dep 14
Dep 15 15
15 Dep 15
Dep 16 Dep 16
Dep 17
10
10 Dep 18
10 Dep 17
Dep 18
Dep 19
Dep 19
Dep 20
5 Dep 20
5 Dep 21
0 Dep 22
Dep 21
Dep 22
Dep 23 0
0 0% 100% 200% 300% 400% 500% Dep
600%24 700% 0 5 10 15 20 25
Dep 23

QoS Change Rate 12

0 2 4 6 8 10 12 14 16 18 20 Dep 24
Dep 25
Dep 26
Latency (ms) Dep 25
Durability (hours) Dep 26
Dep 27
Dep 27
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

Deployment Modelling

 In order to be able to make and effect a

deployment plan for large, long-lived,
distributed software system, the system’s
architects first need to create a model.
 Architect would need to know lot of information
(how large repository is; how clock component
updates other component, what types of GUI
facilities) than is constrained in two diagrams.

13
Software Architecture: Foundations, Theory, and Practice

Deployment Modeling

Modeling Architectural Elements

 Define sets that specify system elements and
their properties
 Set C of software components
 C = {ResourcesMap, SendMessage, Display, …}
 Set CP of software component properties
 CP = {size, reliability, …}
 Other sets
 H of hardware nodes, N of network links, I of
logical links, S of services, Q of QoS, U of users
 HP of hardware params, NP of network link
params, CP of software component params, IP
of logical link params
 Define functions that quantify system
properties
 Function cParam:C×CP→R
 cParam(ResourcesMap, size) = 150
 Other functions
 hParam, nParam, IParam, sParam
15
Software Architecture: Foundations, Theory, and Practice

Modeling QoS Dimensions

 Define QoS functions
 qValue:S×Q×DepSpace → R
 quantifies the achieved level
of QoS given a deployment
 qValue(Schedule, Latency,
Dep 1) = 1ms
 Define users’ preferences in terms
of utility
 qUtil:U×S×Q×R →
[MinUtil,MaxUtil]
 represents the accrued utility
for given rate of change
 qUtil(Commander, Schedule,
Latency, 0.25) = -1
16
Software Architecture: Foundations, Theory, and Practice

Modeling System Constraints

 A set PC of parameter constraints
 PC={memory, bandwidth,…}
 A function pcSatisfied:PC×DepSpace → [0,1]
 1 if constraint is satisfied
 0 if constraint is not satisfied
 Functions that restrict locations of s/w components
 loc:C×H → [0,1]
 loc(c,h)=1 if c can be deployed on h
 loc(c,h)=0 if c cannot be deployed on h
 colloc:C×C → [-1,1]
 colloc(c1,c2)=1 if c1 has to be on the same host as c2
 colloc(c1,c2)=-1 if c1 cannot be on the same host as c2
 colloc(c1,c2)=0 if there are no restrictions 17
Software Architecture: Foundations, Theory, and Practice

Deployment Analysis

1. Are both deployments valid?

2. Which of the two deployments is “better”?
3. Does the selected deployment have required properties?
18

Deployment Analysis Strategies

 Different strategies with different strengths

 Most of them offer approximate solutions

1. Mixed Integer Non-linear Programming (MINLP)

2. Mixed Integer Linear Programming (MIP)
3. Heuristic-based strategies
A. Greedy

B. Genetic

C. Decentralized

19
Software Architecture: Foundations, Theory, and Practice

Deployment Implementation

 Release
 Install
 Activate
 Deactivate
 Update
 Adapt
 Reconfigure
 De-install or remove
 De-release or retire

20
Software Architecture: Foundations, Theory, and Practice

Software Deployment Life Cycle

Deployment Tool Support – An Example

Software Mobility
 Mobile computing involves the movement of human
users together with their hosts across different physical
locations
 This is also referred to as physical mobility

 Movement of software across hardware hosts during the

system’s execution, that action is referred to as code
mobility or logical mobility
 If a software module that needs to be migrated contains
runtime state, then the module’s migration is known as
stateful mobility
 If only the code needs to be migrated, that is known as
stateless mobility 23
Software Architecture: Foundations, Theory, and Practice

Mobility Paradigms
 Remote evaluation
 Re-deploy needed component at runtime from a source
host to a destination host
 Install component on the destination host
 Ensure that the system’s architectural configuration and
any architectural constraints are preserved
 Activate the component
 Executed the component to provide the desired service
 Possibly de-activate and de-install
 Code-on-demand
 Same as remote evaluation, but roles of target and
destination hosts are reversed
 Mobile agent
 Migration of a stateful software component that needs
some remote resources to complete its task 24
Software Architecture: Foundations, Theory, and Practice

Mobility and Quality of Service

Closing Thoughts

 It may be impractical or unacceptable to bring systems

down for upgrades
 (Re)deployment is thus necessary

 Architecture as a set of principal design decisions

naturally encompasses (re)deployment
 Maintaining the relationship between architectural model
and implementation stems degradation

26
Intro to Domain-
Specific Software
Engineering
Software Architecture
Lecture 23

Objectives

 Concepts
 What is domain-specific software engineering
(DSSE)
 The “Three Lampposts” of DSSE: Domain,
Business, and Technology
 Domain Specific Software Architectures

 Product Lines
 Relationship between DSSAs, Product Lines, and
Architectural Styles
 Examples of DSSE at work 2
Software Architecture: Foundations, Theory, and Practice

Objectives

 Concepts
 What is domain-specific software engineering
(DSSE)
 The Three Key Factors of DSSE: Domain,
Business, and Technology
 Domain Specific Software Architectures

 Product Lines
 Relationship between DSSAs, Product Lines, and
Architectural Styles
 Examples of DSSE at work 3
Software Architecture: Foundations, Theory, and Practice

Domain-Specific Software
Engineering
 The traditional view of software engineering shows us
how to come up with solutions for problems de novo
 But starting from scratch every time is infeasible
 This will involve re-inventing many wheels

 Once we have built a number of systems that do similar

things, we gain critical knowledge that lets us exploit
common solutions to common problems
 In theory, we can simply build “the difference”
between our new target system and systems that
have come before

4
Software Architecture: Foundations, Theory, and Practice

Examples of Domains
 Compilers for programming languages
 Consumer electronics
 Electronic commerce system/Web stores
 Video game
 Business applications
 Basic/Standard/“Pro”

 We can subdivide, too:

 Avionics systems

 Boeing Jets
 Boeing 747-400
5

Traditional Software Engineering

 One particular problem can be solved in innumerable

ways
6

Architecture-Based Software
Engineering

 Given a single problem, we select from a handful of

potential architectural styles or architectures, and go
from these into specific implementations 7

Domain-Specific Software
Engineering

 We map regions of the problem space (domains) into domain-

specific software architectures (DSSAs)
 These are specialized into application-specific architectures
 These are implemented 8

Three Key Factors of DSSE

 Domain
 Must have a domain to constrain the problem space and
focus development
 Technology
 Must have a variety of technological solutions—tools,
patterns, architectures & styles, legacy systems—to
bring to bear on a domain
 Business
 Business goals motivate the use of DSSE

 Minimizing costs: reuse assets when possible

 Maximize market: develop many related applications
for different kinds of end users 9
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Domain
 Must have a domain
to constrain the
problem space Domain Business
and focus
development

Technology

10
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Technology
 Must have a variety
of technological
solutions—tools, Domain Business
patterns,
architectures &
styles, legacy
systems—to bring
to bear on a
domain
Technology

11
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Business
 Business goals
motivate the use of
DSSE
Domain Business
 Minimizing
costs: reuse
assets
when possible
 Maximize
market: develop
many related
applications for Technology
different kinds
of end users 12
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Domain + Business
 “Corporate Core
Competencies”
 Domain expertise Domain Business
augmented by
business
acumen and
knowledge of
the market

Technology

13
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Domain + Technology
 “Application Family
Architectures”
 All possible Domain Business
technological
solutions to
problems in a
domain
 Uninformed
and unconstrained by
business goals Technology
and knowledge
14
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Business + Technology
 “Domain independent
infrastructure”
 Tools and Domain Business
techniques for
constructing
systems
independent of any
particular domain
 E.g., most generic ADLs,
UML, compilers, word Technology
processors, general-
purpose PCs 15
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Domain + Business +
Technology
 “Domain-specific
software engineering” Domain Business
 Applies technology
to domain-specific
goals, tempered by
business and market
knowledge

Technology

16
Software Architecture: Foundations, Theory, and Practice

Three Key Factors

 Product-Line Architectures
 A specific, related set
of solutions within
a broader DSSE Domain Business
 More focus on
commonalities and
variability between
individual solutions

Technology

17
Software Architecture: Foundations, Theory, and Practice

Becoming More Concrete

 Applying DSSE means developing a set of artifacts more

specific than an ordinary software architecture
 Focus on aspects of the domain

 Focus on domain-specific solutions, techniques, and

patterns
 These are
 A domain model and

 A domain-specific software architecture (DSSA)

18
Software Architecture: Foundations, Theory, and Practice

Domain Model

 A domain model is a set of artifacts that capture

information about a domain
 Functions performed

 Objects (also known as entities) that perform the

functions, and on which the functions are performed
 Data and information that flows through the system

 Standardizes terminology and semantics

 Provides the basis for standardizing (or at least
normalizing) descriptions of problems to be solved in the
domain
19
Software Architecture: Foundations, Theory, and Practice

Domain Model

 Defines vocabulary for the domain

Domain Model

 Describes the entities and data in the domain 22

Domain Model

 Defines how entities and data combine to provide features 23

Domain Model

 Defines how data and control flow through entities 24

(Partial) Domain Dictionary

Lunar Module (LM): this is the portion of the spacecraft that lands on the moon.
It consists of two main parts: the Ascent Stage (which holds the crew cabin) and the
Descent Stage, which contains thrusters used for controlling the landing of the LM.
Reaction Control System (RCS): a system on the Lunar Module responsible for the
stabilization during lunar surface ascent/descent and control of the spacecraft’s orientation
(attitude) and motion (translation) during maneuvers
Vertical velocity (see also One-dimensional motion):
For a free-falling object with no air resistance, ignoring the rotation of the lunar surface,
the altitude is calculated as follows:
y = ½ * a * t2 + vi * t + yi
y = altitude
a = constant acceleration due to gravity on a lunar body (see Acceleration for sample values)
t = time in seconds; vi = initial velocity; yi = initial altitude
When thrust is applied, the following equation is used:
y = ½ * (aburner – agravity) * t2 + vi * t + yi
y = altitude
aburner = constant acceleration upward due to thrust
agravity = constant acceleration due to gravity on a lunar
(see Acceleration for sample values)
t = time in seconds; vi = initial velocity; yi = initial altitude
25

Info Model: Context Info Diagram

 Defines high-
level entities
 Defines what is
considered
inside and
outside the
domain (or
subdomains)
 Defines
relationships and
high-level flows

Info Model: Entity-Relationship

Diagram

 Defines entities
and cardinal
relationships
between them
27

Info Model: Object Diagram

 Defines attributes
and operations on
entities
 Closely resembles
class diagram in
UML but may be
more abstract

Feature Model: Feature

Relationship Diagram
Feature Relationship Diagram – Landing Phase
Mandatory: The Lunar Lander must continually read altitude from the Landing Radar and
relay that data to Houston with less than 500 msec of latency. Astronauts must be able to
control the descent of the Lunar Lander using manual control on the descent engine.
The descent engine must respond to control commands in 250msec, with or without
a functioning DSKY…
Optional/Variant: Lunar Lander provides the option to land automatically or allow the
crew to manually steer the spacecraft.
Quality Requirements:
Real-time requirements: The thrusters and the descent engine must be able to respond to
commands from the computer system in real-time.
Fault tolerance: Lunar Lander must be able to continue in its flight-path even when the
main computer system (Primary Navigation Guidance & Control) goes down. Lunar Lander
must be able to maintain system altitude even when one of the thrusters and propellant
supplies goes down in the Reaction Control System.
 Describes overall mission operations of a system
 Describes major features and decomposition 29

Feature Model: Use Case Diagram

 Defines use cases

within the domain
 Similar to use case
models in UML

Feature Model: Representation

Diagram
 Defines how
information is
presented to
human users

Operational Model: Data Flow

Diagram

 Focuses on
data flow
between
entities
with no
notion of
control

Operational
Model:
Control Flow
Diagram

 Focuses on
control flow between
entities separate from
data flow

Operational Model: State

Transition Diagram

 Focuses on states
of systems and
transitions between
them
 Resembles UML
state diagrams

Reference Requirements
 Mandatory
 Must display the current status of the Lunar Lander (horizontal and
vertical velocities, altitude, remaining fuel)
 Must indicate points earned by player based on quality of landing
 Optional
 May display time elapsed
 Variant
 May have different levels of difficulty based on pilot experience
(novice, expert, etc)
 May have different types of input depending on whether
 Auto Navigation is enabled
 Auto Throttle is enabled
 May have to land on different celestial bodies
 Moon
 Mars
 Jupiter’s moons
 Asteroid

Domain-Specific Software
Architecture
 Definition: Definition. A domain-specific software
architecture (DSSA) comprises:
 a reference architecture, which describes a general
computational framework for a significant domain of
applications;
 a component library, which contains reusable chunks
of domain expertise; and
 an application configuration method for selecting and
configuring components within the architecture to
meet particular application requirements.
(Hayes-Roth)
36
Software Architecture: Foundations, Theory, and Practice

Reference Architecture

 Definition. Reference architecture is the set of principal

design decisions that are simultaneously applicable to
multiple related systems, typically within an application
domain, with explicitly defined points of variation.

 Reference architectures are still architectures (since they

are also sets of principal design decisions)
 Distinguished by the presence of explicit points of
variation (explicitly “unmade” decisions)

37
Software Architecture: Foundations, Theory, and Practice

Different Kinds of Reference

Architecture
 Complete single product architecture
 A fully worked out exemplar of a system in a
domain, with optional documentation as to how to
diversify
 Can be relatively weak due to lack of explicit
guidance and possibility that example is a ‘toy’
 Incomplete invariant architecture
 Points of commonality as in ordinary architecture,
points of variation are indicated but omitted
 Invariant architecture with explicit variation
 Points of commonality as in ordinary architecture,
specific variations indicated and enumerated
38
Software Architecture: Foundations, Theory, and Practice

Example Reference Architecture

 Structural view
of Lunar Lander
DSSA
 Invariant with
explicit points
of variation
 Satellite relay

 Sensors

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
Domain-Specific
Software Architecture
and Product Lines

Software Architecture
Lecture 24

Objectives
 Concepts
 What is domain-specific software engineering
(DSSE)
 The “Three Lampposts” of DSSE: Domain,
Business, and Technology
 Domain Specific Software Architectures

 Product Lines
 Relationship between DSSAs, Product Lines, and
Architectural Styles
 Examples of DSSE at work
2
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 What is domain-specific software engineering
(DSSE)
 The “Three Lampposts” of DSSE: Domain,
Business, and Technology
 Domain Specific Software Architectures

 Product Lines
 Relationship between DSSAs, Product Lines, and
Architectural Styles
 Examples of DSSE at work
3
Software Architecture: Foundations, Theory, and Practice

Product Lines

 A set of related products that have substantial

commonality
 In general, the commonality exists at the architecture
level
 One potential ‘silver bullet’ of software engineering
 Power through reuse of

 Engineering knowledge
 Existing product architectures, styles, patterns
 Pre-existing software components and connectors

4
Software Architecture: Foundations, Theory, and Practice

Domains vs. Product Lines

Domains are in the problem space, product lines are in
the solution space

 Domain  Product Line

 Consumer electronics  Sony WEGA TVs
 Avionics  Boeing 747 Family

 Compilers  GNU compiler suite

 Video games  Suite of games

built on same
engine
5
Software Architecture: Foundations, Theory, and Practice

Business vs. Engineering Product

Lines
 Business Product Line
 A set of products marketed under a common banner
to increase sales and market penetration through
bundling and integration
 Engineering Product Line
 A set of products that have substantial commonality
from a technical/engineering perspective
 Generally, business product lines are engineering
product lines and vice-versa, but not always
 Applications bundled after a company acquisition

 Chrysler Crossfire & Mercedes SLK V6

6
Software Architecture: Foundations, Theory, and Practice

Business Motivation for Product

Lines

Traditional Software
Engineering

Business Motivation for Product Lines

Traditional Software
Engineering

Business Motivation for Product Lines

Product-line-based
engineering

Capturing Product Line

Architectures

 Common: features common to all products

 A: features specific to product A
 B: features specific to product B
 Product A = Common + A
 Product B = Common + B 10

A Product-Line Architecture

 Definition: A product-line architecture captures the

architectures of many related products simultaneously

 Generally employs explicit variation points in the

architecture indicating where design decisions may
diverge from product to product

11
Software Architecture: Foundations, Theory, and Practice

A Lunar Lander Product Line

“Lite” “Demo” “Pro” 12

Product Component Table

 Helps us
decide

System Clock Connector

Game Logic Connector

UI Plug-ins Connector
Data Store Connector
whether
creating a

Demo Reminder
Text-based UI

System Clock
product line is

Graphical UI
Game Logic
Data Store

viable or
feasible
Lite X X X X X X
Demo X X X X X X X X X X
Pro X X X X X X
13

Group Components into Features

 Not a mechanical
process
Attempt to identify

System Clock Connector



Game Logic Connector

UI Plug-ins Connector
Data Store Connector
(mostly) orthogonal
features, or features

Demo Reminder
Text-based UI

System Clock
Graphical UI
that would be

Game Logic
Data Store
beneficial in different
products
Core
X X X X X
Elements
Text UI X
Graphical UI X
Time
X X X
Limited 14

Reconstitute Products from

Features
Use technical and business

Core Elements


Time Limited
Graphical UI
knowledge to identify which
combinations form feasible

Text UI
or marketable products
that will be constructed
Lunar Lander Lite X X
Lunar Lander Demo X X X
Lunar Lander Pro X X

Modeling Product Line

Architectures
 Architectural models need to be diversified with
information about variation points and features
 Not all ADLs have good support for this
 Exceptions include

 Koala
 xADL 2.0
 These ADLs have explicit support for capturing
variation points

16
Software Architecture: Foundations, Theory, and Practice

Selection
 Product-line selection is the process of extracting a
single product architecture (or smaller product line) from
an architectural model that contains explicit points of
variation
 ADLs such as Koala and xADL 2.0 can do selection
automatically with tools

Product Lines for Evolution

 Products in a product line don’t have to exclusively capture
alternatives
 They can also capture variation over time

Product Lines for Evolution

Product Lines for ‘What-If’

Analysis
 In addition to alternative products and different versions
of the same product, product lines can capture different
potential products
 Selection can be used to quickly generate product
architectures for potential products
 These can be checked for certain properties or
subjected to more rigorous analysis for feasibility or
quality
 Can also be used to generate new product ideas

21
Software Architecture: Foundations, Theory, and Practice

Implementation Issues
 Important to partition implementations along variation-
point boundaries

Bad Good
22

Implementation Issues (cont’d)

 Keeping evolving architectures and version-controlled
source repositories (e.g., RCS, CVS, Subversion) in sync

Unifying Products with Different

Heritage
 Often, the idea to create a product line emerges after several
products have been implemented and commonality is noticed
 Strategies include
 No product line
 It may be more expensive to create a product line or there
may not be enough commonality
 One master product
 One product architecture becomes the basis for the product
line
 Hybrid
 A new product line architecture emerges out of many
products
 Seems ideal but can be hard in practice
24
Software Architecture: Foundations, Theory, and Practice

Architectural Styles, DSSAs,

Product Lines
 Architectural Styles
 Can be general or domain-specific

 Provides general guidelines for diverse kinds of

applications; focus on –ility development
 DSSAs
 Domain specific; includes elaborate domain model
and specific reference architecture
 Product lines
 Explicit set of related products with common aspects

Style DSSA / Ref Arch Product Line

25
Software Architecture: Foundations, Theory, and Practice

Families of Styles

Objectives
 Concepts
 What is domain-specific software engineering
(DSSE)
 The “Three Lampposts” of DSSE: Domain,
Business, and Technology
 Domain Specific Software Architectures

 Product Lines
 Relationship between DSSAs, Product Lines, and
Architectural Styles
 Examples of DSSE at work
27
Software Architecture: Foundations, Theory, and Practice

Koala

 An ADL and tool-set for developing product lines of

consumer electronics
 A successor to Darwin in terms of structural modeling
 One of the first ADLs to capture points of variation
explicitly
 Has tight bindings to implementations such that
architecture descriptions can be “compiled” into
application skeletons

28
Software Architecture: Foundations, Theory, and Practice

Lunar Lander in Koala

 No product line features yet

 Note similarities to Darwin,
xADL 2.0
 xADL 2.0 Archipelago
visualization is derived
from Koala
interface IDataStore{
void setAltitude(int altitudeInMeters);
int getAltitude();
void setBurnRate(int newBurnRate);
int getBurnRate();
...
}

Lunar Lander PL in Koala

 Switch construct
routes calls to one
of two potential
data stores
 ‘Diversity interface’
lets game logic
component select
callee from external
config component
 Same IDataStore
interface ensures
call compatibility
30

Software Defined Radios

 Variation points in radio configuration, board

configuration, software configuration
31

SDR in xADL 2.0

 Two-node “SCARI” SDR with just device drivers

loaded 32

SDR in xADL 2.0

 Same radio with one waveform deployed

SDRs in xADL 2.0

 By applying product line techniques to SDRs

 Can manage different configurations of the radio

 Deploying components on alternative hosts

 Deployments with
 No waveforms
 One waveform

 Different combinations of waveforms

 Can show radio in different states as radio starts up

or transitions from one waveform to another

14 Analysis Techniques
No ratings yet
14 Analysis Techniques
28 pages
Architectures in Context: Software Architecture
No ratings yet
Architectures in Context: Software Architecture
36 pages
Sed302 2
No ratings yet
Sed302 2
29 pages
Architectures in Context: Software Architecture
No ratings yet
Architectures in Context: Software Architecture
38 pages
Software Architecture Design Patterns - Basic Concepts
No ratings yet
Software Architecture Design Patterns - Basic Concepts
28 pages
03 Basic Concepts
No ratings yet
03 Basic Concepts
28 pages
Basic Concepts of Software
No ratings yet
Basic Concepts of Software
28 pages
09 Introduction To Modeling
No ratings yet
09 Introduction To Modeling
37 pages
SWE411 Week5 L2 Ch9inbook
No ratings yet
SWE411 Week5 L2 Ch9inbook
37 pages
Importance of Modeling
No ratings yet
Importance of Modeling
22 pages
04 Designing Architectures
No ratings yet
04 Designing Architectures
30 pages
27 People Roles and Teams
No ratings yet
27 People Roles and Teams
37 pages
Architectural Design: Software Architecture
100% (1)
Architectural Design: Software Architecture
29 pages
Lecture 9-People Roles and Teams
No ratings yet
Lecture 9-People Roles and Teams
37 pages
01 The Big Idea
No ratings yet
01 The Big Idea
40 pages
15 Implementing Architectures
No ratings yet
15 Implementing Architectures
31 pages
26 Standards
No ratings yet
26 Standards
47 pages
01 The Big Idea
No ratings yet
01 The Big Idea
38 pages
Fundamentals of Software Architecture A Comprehensive Guide To Patterns Characteristics and Best Practices Neal Ford Full Access
No ratings yet
Fundamentals of Software Architecture A Comprehensive Guide To Patterns Characteristics and Best Practices Neal Ford Full Access
142 pages
Swe411 Week 1
No ratings yet
Swe411 Week 1
41 pages
Lecture 1 - Introduction To Software Architecture
No ratings yet
Lecture 1 - Introduction To Software Architecture
61 pages
18 Applied Architectures Part 2
No ratings yet
18 Applied Architectures Part 2
28 pages
Module 1
No ratings yet
Module 1
30 pages
Software Architecture & Design Course
No ratings yet
Software Architecture & Design Course
31 pages
Software Architecture Essentials
No ratings yet
Software Architecture Essentials
45 pages
Chapter 3 - Envisioning Architecture
No ratings yet
Chapter 3 - Envisioning Architecture
52 pages
Software Architecture Speaker Notes
No ratings yet
Software Architecture Speaker Notes
3 pages
CH12 Lecture - Sware Archi 0 Fwork 1-2
No ratings yet
CH12 Lecture - Sware Archi 0 Fwork 1-2
28 pages
SA Mo 6
No ratings yet
SA Mo 6
28 pages
Chapter 5
No ratings yet
Chapter 5
45 pages
Ilovepdf Merged
No ratings yet
Ilovepdf Merged
11 pages
Software Engineering 3 & 4 TBD
No ratings yet
Software Engineering 3 & 4 TBD
66 pages
Software Engineering - Architecture and UI
No ratings yet
Software Engineering - Architecture and UI
44 pages
Software Architecture in Practice (SEI Series in Software Engineering), 4th Edition Len Bass Instant Download
No ratings yet
Software Architecture in Practice (SEI Series in Software Engineering), 4th Edition Len Bass Instant Download
141 pages
Model-Based Software Architectures
100% (1)
Model-Based Software Architectures
13 pages
339033lecture 24 - Software Architecture and Error Handling-1751457842014
No ratings yet
339033lecture 24 - Software Architecture and Error Handling-1751457842014
41 pages
Lecture 5 Notes - Software Architecture and Design
No ratings yet
Lecture 5 Notes - Software Architecture and Design
16 pages
19-Architectural Design-21-02-2024
No ratings yet
19-Architectural Design-21-02-2024
33 pages
Software Architecture Overview
No ratings yet
Software Architecture Overview
239 pages
Chapter Analysis
No ratings yet
Chapter Analysis
47 pages
Lecture 8-Architectural Styles in Practice
No ratings yet
Lecture 8-Architectural Styles in Practice
36 pages
What Is Software Architecture - Lecture Note
100% (1)
What Is Software Architecture - Lecture Note
45 pages
Introduction To Software Architecture
No ratings yet
Introduction To Software Architecture
12 pages
6 Sa Edited
No ratings yet
6 Sa Edited
60 pages
SWE411 Week6 L1 Modeling and Notations
No ratings yet
SWE411 Week6 L1 Modeling and Notations
63 pages
Software Architecture. Foundations, Theory, and Practice: Brochure
No ratings yet
Software Architecture. Foundations, Theory, and Practice: Brochure
8 pages
Chapter 3 - Envisioning Architecture
No ratings yet
Chapter 3 - Envisioning Architecture
73 pages
Chapter1 Basic Concepts
No ratings yet
Chapter1 Basic Concepts
60 pages
Architecture Views: Software Design and Architecture
No ratings yet
Architecture Views: Software Design and Architecture
37 pages
Software Architecture Course
No ratings yet
Software Architecture Course
715 pages
Lecture 1 Software Architecture
No ratings yet
Lecture 1 Software Architecture
31 pages
Report On Software Architecture
No ratings yet
Report On Software Architecture
4 pages
Software Architecture For Developers, Volume 1 - Simon Brown
100% (1)
Software Architecture For Developers, Volume 1 - Simon Brown
106 pages
Sewp Zg651 Software Architectures: Akumbhar@wilp - Bits-Pilani - Ac.in
No ratings yet
Sewp Zg651 Software Architectures: Akumbhar@wilp - Bits-Pilani - Ac.in
40 pages
5732fundamentals of Software Architecture A Comprehensive Guide To Patterns Characteristics and Best Practices Neal Ford Instant Download
No ratings yet
5732fundamentals of Software Architecture A Comprehensive Guide To Patterns Characteristics and Best Practices Neal Ford Instant Download
95 pages
WINSEM2022-23 CSI3024 TH VL2022230503267 2022-12-14 Reference-Material-I
No ratings yet
WINSEM2022-23 CSI3024 TH VL2022230503267 2022-12-14 Reference-Material-I
24 pages
Nit Rourkela Software Testing Assignment
No ratings yet
Nit Rourkela Software Testing Assignment
4 pages
Hashing Complete Notes by Deeksha GitHub
No ratings yet
Hashing Complete Notes by Deeksha GitHub
16 pages
Nit Rourkela White Box Testing Software Testing
No ratings yet
Nit Rourkela White Box Testing Software Testing
17 pages
Untitled Notebook
No ratings yet
Untitled Notebook
2 pages
BinarySearchTrees Notes PDF by Deeksha. Github
No ratings yet
BinarySearchTrees Notes PDF by Deeksha. Github
13 pages
Hashing - in - Cryptography Presentation NIST
No ratings yet
Hashing - in - Cryptography Presentation NIST
9 pages
Solana Staking & Validators (PDF Ready) - Claude - Claude
No ratings yet
Solana Staking & Validators (PDF Ready) - Claude - Claude
2 pages
Solana Development Guide (PDF Ready) - Claude - Claude
No ratings yet
Solana Development Guide (PDF Ready) - Claude - Claude
2 pages
Solana Fundamentals (PDF Ready) - Claude - Claude
No ratings yet
Solana Fundamentals (PDF Ready) - Claude - Claude
2 pages
Solana Development Guide (PDF Ready) - Claude - Claude
No ratings yet
Solana Development Guide (PDF Ready) - Claude - Claude
2 pages
K-Nearest Neighbourhood
100% (1)
K-Nearest Neighbourhood
7 pages
Solana DeFi Ecosystem (PDF Ready) - Claude - Claude
No ratings yet
Solana DeFi Ecosystem (PDF Ready) - Claude - Claude
2 pages
PNN
No ratings yet
PNN
13 pages
Boundary Feature Enhancement
No ratings yet
Boundary Feature Enhancement
12 pages
Engineering Project TTTTT
No ratings yet
Engineering Project TTTTT
32 pages
Doc8385 ATxmega128A1U Manual
No ratings yet
Doc8385 ATxmega128A1U Manual
216 pages
Microprocessor Full Hand Made Notes
No ratings yet
Microprocessor Full Hand Made Notes
151 pages
Learning3 6pp
No ratings yet
Learning3 6pp
15 pages
BCS Course Catalog0411202012435124072021041107
No ratings yet
BCS Course Catalog0411202012435124072021041107
46 pages
Year 7 End of Term Ict
No ratings yet
Year 7 End of Term Ict
10 pages
Guide Sofistik
No ratings yet
Guide Sofistik
445 pages
An Analysis On Measuring Graph Patterns in Social Networks
No ratings yet
An Analysis On Measuring Graph Patterns in Social Networks
6 pages
Question Paper Code:: Reg. No.
No ratings yet
Question Paper Code:: Reg. No.
2 pages
Audio Headroom Essentials
No ratings yet
Audio Headroom Essentials
9 pages
IBM Watson Analytics Automating Visualization Desc
No ratings yet
IBM Watson Analytics Automating Visualization Desc
12 pages
Annex A Barangay Profile DCF No. 1
77% (13)
Annex A Barangay Profile DCF No. 1
5 pages
QP 1
No ratings yet
QP 1
3 pages
Data Cleaning: Missing Values: - For Example in Attribute Income If
No ratings yet
Data Cleaning: Missing Values: - For Example in Attribute Income If
30 pages
E-commerce Dashboard Insights
No ratings yet
E-commerce Dashboard Insights
8 pages
Practical 2.2
No ratings yet
Practical 2.2
2 pages
Premium Power Supply Scheme For Data Center With SMES and DG Integration
No ratings yet
Premium Power Supply Scheme For Data Center With SMES and DG Integration
5 pages
Payment Slip: Summary of Charges / Payments Current Bill Analysis
No ratings yet
Payment Slip: Summary of Charges / Payments Current Bill Analysis
4 pages
Case+study-+IIITB+ +upGrad+Template
No ratings yet
Case+study-+IIITB+ +upGrad+Template
19 pages
Cyber Law
No ratings yet
Cyber Law
43 pages
(Advances in Information Systems and Business Engineering) Tahvo Hyötyläinen (Auth.)-Steps to Improved Firm Performance With Business Process Management_ Adding Business Value With Business Process Ma
100% (1)
(Advances in Information Systems and Business Engineering) Tahvo Hyötyläinen (Auth.)-Steps to Improved Firm Performance With Business Process Management_ Adding Business Value With Business Process Ma
235 pages
E3d Command List
No ratings yet
E3d Command List
13 pages
Warehouse Optimization
No ratings yet
Warehouse Optimization
4 pages
Guide To Effective ChatGPT Prompting
No ratings yet
Guide To Effective ChatGPT Prompting
42 pages
VMDR Presentation Slides
No ratings yet
VMDR Presentation Slides
126 pages
Lucknow University
No ratings yet
Lucknow University
2 pages
BRUSH A3100 Data Sheet - 10 - 20
No ratings yet
BRUSH A3100 Data Sheet - 10 - 20
2 pages
Word Chapter 5 Study Guide
No ratings yet
Word Chapter 5 Study Guide
3 pages
5 Elsevier
No ratings yet
5 Elsevier
25 pages
Compiled Presentation Notes
No ratings yet
Compiled Presentation Notes
35 pages