University of Southern CaliforniaCenter for Systems and Software Engineering
From Dependable ArchitecturesTo Dependable Systems
Nenad MedvidovicCenter for Systems and Software Engineering
Computer Science DepartmentViterbi School of Engineering
University of Southern CaliforniaLos Angeles, U.S.A.
University of Southern CaliforniaCenter for Systems and Software Engineering
Goals of the Talk• Identify some challenges• Suggest some solutions• Motivate future research• Invite dissenting opinions
University of Southern CaliforniaCenter for Systems and Software Engineering
Goals of the Talk
The problem is this big
and sometimes ill-defined
University of Southern CaliforniaCenter for Systems and Software Engineering
Goals of the Talk
I will talk to youabout this much of it
University of Southern CaliforniaCenter for Systems and Software Engineering
Goals of the Talk
I will suggest a solutionfor this much of it
University of Southern CaliforniaCenter for Systems and Software Engineering
Goals of the Talk
But, hopefully, we will havethis much fun!
University of Southern CaliforniaCenter for Systems and Software Engineering
What Is Dependability?• Degree of user confidence that the system will
operate as expected• Key dimensions
– Availability– Reliability– Security– Safety
• But also– Repairability– Maintainability– Survivability– Fault tolerance
University of Southern CaliforniaCenter for Systems and Software Engineering
What Is Architecture?• A high-level model of a system
– The system’s “blueprint”• Represents system organization
– Data– Computation– Interaction– Structure
• Embodies system properties– Communication integrity, performance,
throughput, liveness, . . .Can/does it embody dependability? (how) Can those properties be transferred to the
system itself?
University of Southern CaliforniaCenter for Systems and Software Engineering
A “Traditional” Architectural Model
University of Southern CaliforniaCenter for Systems and Software Engineering
A “Traditional” Architectural Model
What/where is the dependability?
University of Southern CaliforniaCenter for Systems and Software Engineering
A “Standard” Architectural Model
Segment(from ssi)
AttributeDescription(from serializati...
ResourceDescription(from serializati...
HttpCredential(from ht...
PlainRemoteResource(from adm...
HtmlHead(from ht...
SampleMuxHandler(from m...
Stresser(from tes...
JigsawHttpSessionContext(from servl. ..
HtmlStyle(from ht...
AdminContext(from admin)
AuthUserPrincipal(from a...
IPMatcherNode(from au...
HttpBag(from ht...
HtmlGenerator(from ht.. .
DirectoryResource(from resourc...
FileResource(from resourc...
HttpEntityTag(from ht...
HttpManager(from ht.. .
CGIHeaderHolder(from fram...
Shuffler(from ht...
IndexersCatalog(from index...
ResourceIndexer(from index...
MuxClientFactory(from m...
ResourceContext(from resourc...
EventManager(from t ime...
ResourceStoreManager(from sto...
PropertySet(from conf...
FramedResource(from resourc...
ServerHandlerManager(from daem...
AdminWriter(from adm...
Serializer(from serializati...
RequestTimeout(from ht.. .
MimeType(from mime)
IPMatcher(from auth)
ExternalContainer(from resourc...
PICS(from pi...
SSIFrame(from s...
SSIStream(from s...
ArrayDictionary(from ut...
CommandRegistry(from comman...
VariantState(from NegotiatedFra...
SampleResourceIndexer(from index...
ProtocolFrame(from frames)
MimeClientFactory(from ht...
MimeParser(from mi...
DAVMimeClientFactory(from webd...
ResourceException(from resourc...
SocketOutputBuffer(from sock...
DebugThread(from sock...
ThreadCache(from ut...
SocketClientFactoryStats(from sock...
httpd(from http)
MuxSession(from m...
ResourceFilter(from resources)
HttpMimeType(from ht...
HttpTokenList(from ht...
ResourceReference(from resources)
HTTPPrincipal(from a...
ProxyRequestObserver(from pro...
ProfileRef(from cc...
HttpExtList(from ht...
Client(from http)
CCPPRequest(from cc...
University of Southern CaliforniaCenter for Systems and Software Engineering
: WebBrowser
: SocketClient : httpd : DirectoryResource : ContainerResource : FramedResource : LookupResult
processRequest(Request) perform(RequestI nterface) <<create>>
lookup(LookupState, LookupResult) [lookup(LookupState, LookupResult)]
[lookup(LookupState, LookupResult)] setTarget(resourceReference)
internalLookup() lookup(LookupState, LookupResult)
[moreComponents]:
HTTPD Resources
Figure 10: Sequence diagram for the request processing use case.
A “Standard” Architectural Model
University of Southern CaliforniaCenter for Systems and Software Engineering
: WebBrowser
: SocketClient : httpd : DirectoryResource : ContainerResource : FramedResource : LookupResult
processRequest(Request) perform(RequestI nterface) <<create>>
lookup(LookupState, LookupResult) [lookup(LookupState, LookupResult)]
[lookup(LookupState, LookupResult)] setTarget(resourceReference)
internalLookup() lookup(LookupState, LookupResult)
[moreComponents]:
HTTPD Resources
Figure 10: Sequence diagram for the request processing use case.
A “Standard” Architectural Model
What/where is the dependability?
University of Southern CaliforniaCenter for Systems and Software Engineering
But, We Can Model Anything• Meta-H, ROOM, UniCon, etc. can help ensure
real-time properties in models• Markov chains can help ensure reliability in
models• Multi-versioning connectors can help ensure
fault tolerance• Code/data mobility and replication formalisms
can help ensure availability• . . .
University of Southern CaliforniaCenter for Systems and Software Engineering
But, We Can Model Anything• Meta-H, ROOM, UniCon, etc. can help ensure
real-time properties in models• Markov chains can help ensure reliability in
models• Multi-versioning connectors can help ensure
fault tolerance• Code/data mobility and replication formalisms
can help ensure availability• . . .
So then the problem is solved, right?
University of Southern CaliforniaCenter for Systems and Software Engineering
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture(ADL)
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture(ADL)
Design(UML)
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture(ADL)
Implementation(middleware, bus
technolgies)
Design(UML)
Object-Oriented
Programming Language (OOPL)D/COM
CORBAC++
Java
Visual Basic
JEDI
Java Beans
C2
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
P ro b lem S p aceD o m a in E n titie s
C la s s N a m e
A ttr ibute s
O p e ra tion
C la s s N a m e
A ttr ib ute s
O pe ra tion
C la s s N a m e
A ttr ibu te s
O pe ra tion
C la s s N a m e
A ttr ibute s
O pe ra tionC la s s N a m e
A ttr ibute s
O pe ra tion
A rchitecture S p ace
D es ig n S p ace
C o m p on e n tsC o n n e c to rs
C la s s esC O T S C om p on e n ts
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
P ro b lem S p aceD o m a in E n titie s
C la s s N a m e
A ttr ibute s
O p e ra tion
C la s s N a m e
A ttr ib ute s
O pe ra tion
C la s s N a m e
A ttr ibu te s
O pe ra tion
C la s s N a m e
A ttr ibute s
O pe ra tionC la s s N a m e
A ttr ibute s
O pe ra tion
A rchitecture S p ace
D es ig n S p ace
C o m p on e n tsC o n n e c to rs
C la s s esC O T S C om p on e n ts
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
P ro b lem S p aceD o m a in E n titie s
C la s s N a m e
A ttr ibute s
O p e ra tion
C la s s N a m e
A ttr ib ute s
O pe ra tion
C la s s N a m e
A ttr ibu te s
O pe ra tion
C la s s N a m e
A ttr ibute s
O pe ra tionC la s s N a m e
A ttr ibute s
O pe ra tion
A rchitecture S p ace
D es ig n S p ace
C o m p on e n tsC o n n e c to rs
C la s s esC O T S C om p on e n ts
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
P ro b lem S p aceD o m a in E n titie s
C la s s N a m e
A ttr ibute s
O p e ra tion
C la s s N a m e
A ttr ib ute s
O pe ra tion
C la s s N a m e
A ttr ibu te s
O pe ra tion
C la s s N a m e
A ttr ibute s
O pe ra tionC la s s N a m e
A ttr ibute s
O pe ra tion
A rchitecture S p ace
D es ig n S p ace
C o m p on e n tsC o n n e c to rs
C la s s esC O T S C om p on e n ts
Why the Problem Isn’t Solved
University of Southern CaliforniaCenter for Systems and Software Engineering
From Models to Systems
Clock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
University of Southern CaliforniaCenter for Systems and Software Engineering
From Models to Systems
Host 2Host 1
Host 3 Host 4 Host 5
Clock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
University of Southern CaliforniaCenter for Systems and Software Engineering
From Models to Systems
University of Southern CaliforniaCenter for Systems and Software Engineering
The remainder of this talk will focus on two key questions:
University of Southern CaliforniaCenter for Systems and Software Engineering
1. How do we get from
University of Southern CaliforniaCenter for Systems and Software Engineering
Clock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
Host 2Host 1
Host 3 Host 4 Host 5
and
1. How do we get from
University of Southern CaliforniaCenter for Systems and Software Engineering
toClock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
Host 2Host 1
Host 3 Host 4 Host 5
Host 2Host 1
Host 3 Host 4 Host 5
Clock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
and
1. How do we get from
University of Southern CaliforniaCenter for Systems and Software Engineering
toClock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
to
?
Host 2Host 1
Host 3 Host 4 Host 5
Host 2Host 1
Host 3 Host 4 Host 5
Clock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Commander UI
SoldierUI
and
1. How do we get from
University of Southern CaliforniaCenter for Systems and Software Engineering
2. How do we know
University of Southern CaliforniaCenter for Systems and Software Engineering
2. How do we know
University of Southern CaliforniaCenter for Systems and Software Engineering
2. How do we know
is “better” than
?
University of Southern CaliforniaCenter for Systems and Software Engineering
Outline• From architectures to systems• Ensuring dependability
Problem definition Proposed solution
• Concluding remarks
University of Southern CaliforniaCenter for Systems and Software Engineering
Outline From architectures to systems• Ensuring dependability
Problem definition Proposed solution
• Concluding remarks
University of Southern CaliforniaCenter for Systems and Software Engineering
How Do I Dependably Implement an Architecture?
• Architectures provide high-level concepts– Components, connectors, ports, events, configurations
• Programming languages provide low-level constructs– Variables, arrays, pointers, procedures, objects
• Bridging the two often is an art-form– Middleware can help “split the difference”
• Existing middleware technologies– Support some architectural concepts (e.g., components, events)– but not others (e.g., connectors, configurations)– Impose particular architectural styles
University of Southern CaliforniaCenter for Systems and Software Engineering
How Do I Dependably Implement an Architecture?
• Architectures provide high-level concepts– Components, connectors, ports, events, configurations
• Programming languages provide low-level constructs– Variables, arrays, pointers, procedures, objects
• Bridging the two often is an art-form– Middleware can help “split the difference”
• Existing middleware technologies– Support some architectural concepts (e.g., components, events)– but not others (e.g., connectors, configurations)– Impose particular architectural styles
What is needed is “architectural middleware”
University of Southern CaliforniaCenter for Systems and Software Engineering
Architectural Middleware• Natively support architectural concepts as middleware
constructs• Include system design support
– Typically via an accompanying ADL and analysis tools– May support explicit architectural styles
• Support round-trip development– From architecture to implementation and back
• Support automated transformation of architectural models to implementations– i.e., dependable implementation
• Examples– ArchJava– Aura– c2.fw– Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
Dependable ImplementationArchitecture
(ADL)
Implementation(middleware, bus
technolgies)
Design(UML)
Object-Oriented
Programming Language (OOPL)D/COM
CORBAC++
Java
Visual Basic
JEDI
Java Beans
C2
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture(ADL)
Implementation(middleware, bus
technolgies)Object-Oriented
Programming Language (OOPL)D/COM
CORBAC++
Java
Visual Basic
JEDI
Java Beans
C2
Dependable Implementation
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture(ADL)
Implementation(middleware, bus
technolgies)Object-Oriented
Programming Language (OOPL)D/COM
CORBAC++
Java
Visual Basic
JEDI
Java Beans
C2
Dependable Implementation
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Example: Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Example: Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Example: Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Example: Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Example: Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Example: Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
Using Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture - DEMO
class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO");
Using Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture - DEMO
class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO");
Using Prism-MW
// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");
Component BComponent A Component D
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture - DEMO
class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO");
Using Prism-MW
// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");// create connectorsConnector conn = new Connector("C");
Component BComponent A Component D CConnector C
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture - DEMO
class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO");
Using Prism-MW
// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");// create connectorsConnector conn = new Connector("C");// add components and connectors arch.addComponent(a);arch.addComponent(b);arch.addComponent(d);arch.addConnector(conn);
Component BComponent A
Component D
CConnector C
University of Southern CaliforniaCenter for Systems and Software Engineering
Architecture - DEMO
class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO");
Using Prism-MW
// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");// create connectorsConnector conn = new Connector("C");// add components and connectors arch.addComponent(a);arch.addComponent(b);arch.addComponent(d);arch.addConnector(conn);
Component BComponent A
Component D
CConnector C
// establish the interconnectionsarch.weld(a, conn);arch.weld(b, conn);arch.weld(conn, d)
}}
University of Southern CaliforniaCenter for Systems and Software Engineering
Deploying a Prism-MW Architecture
University of Southern CaliforniaCenter for Systems and Software Engineering
Deploying a Prism-MW Architecture
add (DataRepository : source HQ) : HQ;
weld (TopDistributionConnector, C1_AvailableTroops) : Commander1;
University of Southern CaliforniaCenter for Systems and Software Engineering
Outline From architectures to systems Ensuring dependability
Problem definition Proposed solution
• Concluding remarks
University of Southern CaliforniaCenter for Systems and Software Engineering
Outline From architectures to systems Ensuring dependability
Problem definition Proposed solution
• Concluding remarks
University of Southern CaliforniaCenter for Systems and Software Engineering
Let’s Pick Availability• The degree to which a system is operational and
accessible when required for use [IEEE]• Deployment architecture influences availability
– Components on the same host can communicate regardless of the network’s status
– Components on different hosts are insulated from each other’s failures
• Quantifying availability– Ratio of the
number of successfully completed interactionsin the system to the total number of attempted interactions
University of Southern CaliforniaCenter for Systems and Software Engineering
• We may not know many relevant system parameters– Dependability of each component– Frequency of component interactions– Volume of component interactions– Dependability of component interactions– CPU usage on each host– Dependability of each host– Effective bandwidth of each network connection– Dependability of each network connection– . . .
Maximizing Availability a priori
University of Southern CaliforniaCenter for Systems and Software Engineering
• We may not know many relevant system parameters– Dependability of each component– Frequency of component interactions– Volume of component interactions– Dependability of component interactions– CPU usage on each host– Dependability of each host– Effective bandwidth of each network connection– Dependability of each network connection– . . .
Maximizing Availability a priori
Current deployment architecture may not work well
University of Southern CaliforniaCenter for Systems and Software Engineering
• We may not know many relevant system parameters– Dependability of each component– Frequency of component interactions– Volume of component interactions– Dependability of component interactions– CPU usage on each host– Dependability of each host– Effective bandwidth of each network connection– Dependability of each network connection– . . .
Maximizing Availability a priori
Current deployment architecture may not work well
Number of possible deployment architectures is kn
University of Southern CaliforniaCenter for Systems and Software Engineering
Find a function HCf : such that the
n
i
n
jji
n
i
n
jjiji
ccfreq
cfcfrelccfreqA
1 1
1 1
),(
))(),((),(
system’s overall availability
is maximized, and the following conditions are satisfied:
Simplified Problem Definition
],1[],1[ nlnk ))()(()1),(( lklk cfcfcccolloc ))()(()1),(( lklk cfcfcccolloc
University of Southern CaliforniaCenter for Systems and Software Engineering
Outline From architectures to systems Ensuring dependability
Problem definitionProposed solution
• Concluding remarks
University of Southern CaliforniaCenter for Systems and Software Engineering
Overview of the Approach• Objective
– Identify the problem• Log and examine system eventsActively monitor the system during runtime
– Develop a solution• Decide which data to cache• Decide which components to replicate• Introduce multiple execution modesCalculate an improved system deployment
– Apply the solution to eliminate the problem• Cache or hoard data • Replicate data or codeRedeploy (parts of) the system
University of Southern CaliforniaCenter for Systems and Software Engineering
Improving Availability via Redeployment
Time
Availability
A1
A2
TM TRT
TOTE T’M T’RT’
T’OT’E
A3
A4
University of Southern CaliforniaCenter for Systems and Software Engineering
First Identify the Problem
Time
Availability
A1
A2
TM TRT
TOTE
University of Southern CaliforniaCenter for Systems and Software Engineering
First Identify the Problem
Time
Availability
A1
A2
TM TRT
TOTE
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
AbstractMonitor
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
IArchitecture
#mutualPort
Disconnection Rate
EvtFrequency
Monitoring in Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
Monitoring in Action
34
31
18
2 615
16
4 12
21
8
3 9
29 1 28
2030
17
14
0
2226
13
27
10
33
7
24
25
32
19
23
11
5
University of Southern CaliforniaCenter for Systems and Software Engineering
Then Develop a Solution
Time
Availability
A1
A2
TM TRT
TOTE
University of Southern CaliforniaCenter for Systems and Software Engineering
Then Develop a Solution
Time
Availability
A1
A2
TM TRT
TOTE
University of Southern CaliforniaCenter for Systems and Software Engineering
1
100
10000
1000000
Time taken(in ms)
0
0.2
0.4
0.6
0.8
1
z
Achieved availability
10 comps 100 comps 200 comps 1000 comps 100 comps 30 comps 300 comps 4 hosts 10 hosts 20 hosts 100 hosts 40 hosts 7 hosts 70 hosts
Suite of algorithms:Exact – exponential complexityStochastic – quadratic complexityAdaptive greedy – cubic complexityDecentralized – quadratic complexity
Estimating in Action
University of Southern CaliforniaCenter for Systems and Software Engineering
Automatic Algorithm Selection
AC
AS
T0STES
GreedyAG
AEExact
TEG TEE
T0G T0E
Time
Availability
TRTR TRT
Stochastic
University of Southern CaliforniaCenter for Systems and Software Engineering
AC
AS
T0STES
GreedyAG
AEExact
TEG TEE
T0G T0E
Time
Availability
TRTR TRT
Stochastic
Automatic Algorithm Selection
University of Southern CaliforniaCenter for Systems and Software Engineering
Then Apply the Solution
Time
Availability
A1
A2
TM TRT
TOTE
University of Southern CaliforniaCenter for Systems and Software Engineering
Then Apply the Solution
Time
Availability
A1
A2
TM TRT
TOTE
University of Southern CaliforniaCenter for Systems and Software Engineering
IComponentIConnector
Scaffold
AbstractDispatcher
Round RobinDispatcher
AbstractScheduler
FifoScheduler
Brick
Architecture
ExtensibleComponent
Component
Connector
Event
Port
IPort
Serializable
Admin
IArchitecture
#mutualPort
AbstractAdmin
DeployerAbstract
Redeployment Algo
Exact
Stochastic
Adaptive Greedy
Redeployment in Prism-MW
University of Southern CaliforniaCenter for Systems and Software Engineering
Redeployment in Action
Admin
34
31
18
2 615
16
4 12
21
Admin
8
3 9
29 1
Admin
28
2030
17
14
0Admin
2226
13
27
10
33
7
24
25
32
19
23
11
Deployer
5
University of Southern CaliforniaCenter for Systems and Software Engineering
Going from
Host 2Host 1
Host 3 Host 4 Host 5
Clock
Weather Repository
Map
WeatherAnalyzer
ResourceManager
StrategyAnalysisKB
SimulationAgent
ResourceMonitor
SAKBUI
HQ UI
StrategyAnalyzer
Agent DeploymentAdvisor
Commander UI
SoldierUI
Legend:
User interface component(fixed to a host)
Processing or datacomponent
Commander UI
SoldierUI
Host 2
Hardware host
Network link
Interaction pathbetween components
University of Southern CaliforniaCenter for Systems and Software Engineering
to
University of Southern CaliforniaCenter for Systems and Software Engineering
Outline From architectures to systems Ensuring dependability
Problem definitionProposed solution
Concluding remarks
University of Southern CaliforniaCenter for Systems and Software Engineering
Concluding RemarksStill so much to do
Enrich/complete the modelsFocus on additional aspects of dependabilityAddress dependability trade-offsAddress feature interactionsAddress emergent propertiesDetermine which concerns are (not) architectural
University of Southern CaliforniaCenter for Systems and Software Engineering
Promise or Illusion?If we can define it, we should be able to
Analyze for itBuild itMeasure itAct on it
So, why haven’t we done it yet?
University of Southern CaliforniaCenter for Systems and Software Engineering
The Playing Field
Dependability
HardwareProperties
SoftwareProperties
Availability
Reliability
Security
Safety
InteractionFrequency
Interaction Volume
Component Size
Interaction Volume
ComponentCPU Usage
AvailableMemory
Available CPU
NetworkReliability
NetworkBandwidth
Survivability
ComponentFailure Rate
H/W Properties
S/WProperties
Dependability
University of Southern CaliforniaCenter for Systems and Software Engineering
Exploring the Problem Space
University of Southern CaliforniaCenter for Systems and Software Engineering
Exploring the Problem Space
University of Southern CaliforniaCenter for Systems and Software Engineering
Exploring the Problem Space
University of Southern CaliforniaCenter for Systems and Software Engineering
Exploring the Problem Space
University of Southern CaliforniaCenter for Systems and Software Engineering
Questions?