Summary of Class Discussion for March 19, 2003 by Paul Li
Framework:
I O
C M
^
^
| |
| |
V
V
---------------------------
| | |
---------------------------
| ^
| ^
V | V
|
O’ I’ C’
M’
Beh(c), Old component view: I <-> O
Beh(c), New component view: I x I’ <-> O x O’ or (I’ x O’) -> (I
x O)
Commands, c-> (I’ x O’) -> (I x O)
A command will effect the input output relationship.
A way to understand the relationships between the command and their
effects.
Behavior is steady vs changing. I,O frequently changed. C and M are infrequently changed.
At some level, the component thinks it’s the last step and stops thinking about C and M’s.
For Rainbow, we think that a system needs to have a way to get information
into the system and tell what its state is. Rainbow provides the connections
that make this easier.
Topics
Foundations
User Interfaces
Model-based Approaches
Mobility, Ubiquitous Computing, OS Support
Alternative Models of Computation
Algorithms and Code
Networks, Distributed systems, and Middleware
Fault Tolerance and Dependability
Formal Models
Is this a taxonomy? No, based on what people classify their work as, convenient way of looking at them.
Every system that does self healing must have these qualities?
Monitor: know what you are doing
Detection: see if you what you’re doing meets your needs
Resolution: what to do about it
Adaptation: do something about it
Genetic algorithms might not have all of them. See if every type has these qualities.
From our framework, it seems like these are basic requirements.
What if the system is composed about such entities. What about composition of these sub-components to achieve higher needs? Notions of “self-healing” might differ across styles and levels. Layered thinking might be better.
Thus there are different levels, there are concerns across level and with in levels.
Think about the architectures. What the constraints are and the specific notions are?
As a first cut, describe approaches: What is the architecture of a self healing system in the terms that we have set forth. The input, output, and connectors.
Traditional architectures look at the I/O s. We are extending the view to include how to control it and monitor information.
There are additional needs to make the system self healing. So what are those additional pieces. Do they fit well? Are the pieces so connected that it does not make sense?
What about a biological view where everything that you observe and see changes what you do and would do in the future. Normal input and output causes adaptation.
Is my normal adaptation technique complete for a given adaptation. Do I have information? Do I have controls? Do I have decisions to find the changes necessary? This framework allows for thinking and evaluating the circumstances. Allow people to know what can be changed.
What lives at the control and monitor location?
Topic issues:
Evaluating changes, Peer to Peer issues. Negotiated changes.
User Interface
-Where does this fit?
Model based approaches:
-Owen, Bhuricha
Mobility, Ubiqutous Computing, OS Support, Resources-awareness
-Joao, Vahe
Alternatives Models of Computation
-Kevin
Agent-based
-Justin
Algorithms and code
-Vahe
Networks, Distributed Systems, and Middleware
-Sukanaya
Fault Tolerance, Dependability, Reliability,
-Paul
Formal Models
-Jung Soo + model-based
Chinese menu approach?
Domain: Tools: Goals