Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[docs] Add documentation on the proving API.
see #756 Signed-off-by: Stéphane Galland <galland@arakhne.org>
- Loading branch information
1 parent
bd6f1b4
commit 149e0e4
Showing
8 changed files
with
293 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
137 changes: 137 additions & 0 deletions
137
docs/io.sarl.docs.markdown/src/main/documentation/api/Probing.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,137 @@ | ||
# SRE Observing and Probes | ||
|
||
[:Outline:] | ||
|
||
The multi-agent system is composed of multiple elements, including agents, behaviors, contexts and spaces, but not limited to. | ||
Organizational models in multi-agent systems usually position agents as actors-observers within environments shared | ||
by multiple agents and organizational structures at different levels of granularity. | ||
Then, the agents may have the capacity to observe the environment and the other agents, without directly interacting | ||
with them. The observing agent is able to extract information from another agent or from a society of agents, that could be opaque | ||
according to a possible holonic architecture of the system. | ||
|
||
Observation means that data or information could be extracted from the observed object without filtering from this latter. | ||
The observer is not intrusive from the agent point of view. In other words, the observed agent has no knowledge about the fact it | ||
is observed or not. In this case, it cannot adapt its behavior on its observation status. | ||
|
||
Because an agent is defined as an autonomous entity, the agent is supposed to be enabled to specify if a part of itself | ||
is observable or not, i.e. to specify the access rights. | ||
|
||
<caution>The right access management is not yet supported by the SARL API</caution> | ||
|
||
## What is Observable? | ||
|
||
The first question arising when considering the concept of observable multi-agent system is: what is observable? | ||
|
||
Any object within the multi-agent system that could be referred with a name is possibly subject of an observation. | ||
The objects are referred according to a [specific naming convention](./Naming.md). | ||
|
||
Because observation is related to data extraction, only fields could be observed at the concrete level. | ||
Consequently, the observable objects a the fields declared within an: | ||
* agent | ||
* behavior | ||
* skill | ||
* agent context | ||
* space | ||
* service | ||
|
||
## Probe: generic observer implementation | ||
|
||
### General Principles | ||
|
||
A probe is an implementation of the proxy and observer software design patterns for observable multi-agent system. | ||
It is a software tool that extracts the data from the observed object and provide the data to the observer. | ||
Since a probe is a proxy, it filters the interaction from the observer to the observed object by enabling the first | ||
only to get the data (no other function declared into the observed object is accessible). | ||
The implementation of a probe ensures that it is not intrusive to the observed object. | ||
|
||
The observer has to create a probe on a field of the observable object (agent, behavior, etc.). | ||
Then, the probe could be read to obtain the data, or the observer could be notified each time the data has changed | ||
(according to the observer software design pattern). | ||
|
||
### Concrete Definition | ||
|
||
A probe is defined as: | ||
|
||
[:ShowType:](io.sarl.api.probing.Probe) | ||
|
||
The functions are: | ||
* `getName`: Reply the name of the probe, that is constant. | ||
* `getUri`: Reply the URI of the observed object. | ||
* `getValue` : Reply the observed value. | ||
* `getType` : Reply the type of the observed value. | ||
* `sync`: Force the synchronization of the observed value. | ||
* `release`: Release any resource associated to the probe. | ||
* `isActive`: Reply if this probe is active. When a probe is active, it could be synchronized to the observed object. | ||
* `isInvalid`: Reply if this probe is invalid. When a probe is invalid, the value replied by `getValue` may not corresponds to the observed element's value. | ||
|
||
The following functions are provided for convenience, but they should be used with caution: | ||
* `setValue`: Force the observed field to have a specific value (brokes the agent's autonomy) | ||
|
||
### Observe the Probe | ||
|
||
The observer software design pattern that enables to be notified when the observed value changed in implemented into the probe. | ||
According to the standard implementation best practices of the Java programming language, an observer (in this design pattern) | ||
is named a listener, and it defined by an interface. Two types of observers are defined on probes: [:probelistener:] | ||
and [:probereleaselistener:]. | ||
|
||
[:probelistener:] is defined as: | ||
|
||
[:ShowType:](io.sarl.api.probing.[:probelistener]$IProbeListener$) | ||
|
||
It corresponds to the observer on value changes. | ||
|
||
|
||
[:probereleaselistener:] is defined as: | ||
|
||
[:ShowType:](io.sarl.api.probing.[:probereleaselistener]$IProbeReleaseListener$) | ||
|
||
It corresponds to the observer on the release of a probe. | ||
|
||
|
||
The functions `addProbeListener`, `addProbeReleaseListener`, `removeProbeListener` and `removeProbeReleaseListener` enable to (un)register an event listener on the probe. | ||
|
||
|
||
## Probing Service | ||
|
||
In order to manage and run the different probes, the SRE must implement a dedicated service: the [:probeservicename:]. | ||
It is defined as: | ||
|
||
[:ShowType:](io.sarl.api.probing.[:probeservicename]$ProbeService$) | ||
|
||
|
||
Creating a probe is done by calling the `probe` function. Basically, you need to specify the [name](./Naming.md) of the | ||
observed field, the expected type of the value, and optionally the name of the probe. | ||
|
||
From the probe service, you could force the synchronization of all the managed probes by calling the `sync` function. | ||
|
||
Finally, two functions are provided from retrieving the list of the managed probes `getProbes` and releasing all | ||
the probes `releaseAllProbes`. | ||
|
||
To use this service, you have to get it from the SRE, as illustrated below: | ||
|
||
[:Success:] | ||
package io.sarl.docs.namespace | ||
import io.sarl.bootstrap.SRE | ||
import io.sarl.api.probing.ProbeService | ||
class MyProgram { | ||
static def main(arguments : String*) { | ||
[:On] | ||
var bootstrap = SRE::getBootstrap | ||
var probeService = bootstrap.getService(typeof(ProbeService)) | ||
var probe = probeService.probe("agent:[:agentid]$a7fbd4cc-9e1a-48c3-8ee8-3a7974ccb05c$#[:emergencyfield]$emergency$", typeof([:fieldtype]$Integer$), "[:probename]$My Probe$") | ||
while (true) { | ||
System.out.println("Probe: " + probe.value) | ||
} | ||
[:Off] | ||
} | ||
} | ||
[:End:] | ||
|
||
In this example, the probe service is obtained from the SRE. | ||
An probe is attached to the field named [:emergencyfield:] of type [:fieldtype:] that is defined within the agent [:agentid:]. | ||
The name [:probename:] is given to the probe. | ||
The example loops for displaying the observed value (of course it is not the most efficient usage of a probe). | ||
|
||
|
||
[:Include:](../legal.inc) | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.