Next:
11. Experiments
Up:
Automatic Generation of an
Previous:
10. Module 3: The
Contents
IV
. Validation
Subsections
11
. Experiments
11
.
1
Introduction
11
.
2
Experimental Setup
11
.
3
Measuring Technique
11
.
4
Experiment 1: A Scheme Representation
11
.
4
.
1
Description
11
.
4
.
2
Results
11
.
5
Experiment 2: Classifier System Representation
11
.
5
.
1
Description
11
.
5
.
1
.
1
Single message reactive systems
11
.
5
.
1
.
2
Multi message reactive systems
11
.
5
.
2
Results
11
.
6
Experiment 3: A Petri-Net Representation
11
.
6
.
1
Description
11
.
6
.
2
Results
11
.
7
Experiment 4: Bypassing a Provided Concurrency Strategy
11
.
8
Experiment 5: Liveness and the Bucket Brigade
11
.
9
Experiment 6: The Liveness Module and a Petri-net Representation
11
.
10
Implementation
11
.
10
.
1
The Component System
11
.
10
.
2
The Petri-net Evaluator Code
11
.
10
.
3
The Adaptor Code
11
.
10
.
4
The Actor Components
11
.
11
Summary
12
. Discussion
12
.
1
Introduction
12
.
2
Observations about the Concurrency Adaptors
12
.
3
Concurrency Strategies are Very Simple
12
.
4
Technical Observations
12
.
4
.
1
Non-Incremental Approach: The Problem of Late Joiners
12
.
4
.
2
The Component System
12
.
4
.
3
Thread based versus Event Based systems
12
.
4
.
4
Learning Algorithms
12
.
5
Observations about Petri-net Interface Descriptions
12
.
6
Performance
12
.
6
.
1
The Liveness Module
12
.
6
.
2
The Enforce Action Module
12
.
6
.
3
The Concurrency Module
12
.
6
.
4
Message Sends
12
.
6
.
4
.
1
Functional (Logic) Messages
12
.
6
.
4
.
2
Synchronization Messages
12
.
6
.
5
Overall Performance
12
.
7
Motivation vs Solution
12
.
7
.
1
Open Distributed Systems
12
.
7
.
1
.
1
Adaptor Deployment
12
.
7
.
1
.
2
Why would somebody want to use Petri-nets ?
12
.
7
.
1
.
3
Meta-Conflicts
12
.
7
.
2
Mobile Multi Agent System
12
.
7
.
2
.
1
The Adaptor Preserves Behavior
12
.
7
.
2
.
2
The Adaptor does not Preserve Coordination
12
.
7
.
3
Embedded Systems
12
.
7
.
3
.
1
Memory constraints
12
.
7
.
3
.
2
Bandwidth Constraints
12
.
7
.
3
.
3
Speed constraints
12
.
7
.
3
.
4
Real time constraints
13
. Conclusions
13
.
1
Technical Summary
13
.
2
Thesis Statement
13
.
2
.
1
Abstract Requirements
13
.
2
.
1
.
1
The adaptor should be able to work on-line
13
.
2
.
1
.
2
The adaptor should work by
only
modifying the message flow between the involved components.
13
.
2
.
1
.
3
The adaptor should resolve conflicts
13
.
3
Contributions
13
.
4
Limitations
13
.
5
Application Scope of our Adaptor
13
.
5
.
1
Truly Open Systems: Feasible ?
13
.
5
.
2
Then: Why Do We Need Adaptors ?
13
.
5
.
3
Impact on Component Development
13
.
5
.
4
Decoupling Client / Server
13
.
6
Some Practical Applications
13
.
6
.
1
Collaborative Computer Supported Work
13
.
6
.
2
Databases Access
13
.
6
.
3
Frequently Changing interfaces: TCP/IP Sockets
13
.
7
Guidelines
13
.
7
.
1
Explore the Environment
13
.
7
.
2
Goal & Reference Frame
13
.
7
.
3
Identify Necessary Extra Information
13
.
7
.
4
State the Adaptor Requirements Explicitly
13
.
7
.
5
Correctly Represent Missing Information
13
.
7
.
6
Create the Adaptor
13
.
8
Future Work
13
.
8
.
1
Meta-conflicts
13
.
8
.
2
The problem of checkpoints
13
.
8
.
2
.
1
Test-scenarios
13
.
8
.
2
.
2
Annotated Petri-nets
13
.
8
.
3
Other Learning Approaches ?
13
.
8
.
4
Peer to Peer Concurrency
13
.
8
.
5
Learning an Interface Description
13
.
8
.
6
Determinism versus Non-Determinism
14
. Thread Based Models for Distributed Systems
14
.
1
Naming/Finding services
14
.
2
Communication
14
.
3
Openness & Remote Objects
14
.
4
Java Threads
14
.
5
Error handling: Exceptions
14
.
6
Java RMI and Concurrency
14
.
6
.
1
Concurrency Primitives
14
.
6
.
2
Java RMI
14
.
7
Writing Adaptors
Werner 2004-03-07
