SpeADL Reference Guide¶
- Contenu
- SpeADL Reference Guide
In SpeADL, a set of abstractions are provided to describe typical component-oriented architectures.
On top of these, SpeADL introduces additional abstractions that complete them in order to describe dynamic architectures, in particular for Multi-Agent Systems.
The motivations behind these abstractions are fully discussed in the Ph.D. thesis that led to the creation of MAY, here we stay at the user level.
The main idea with these abstractions is to define software components, called ecosystems, that are able to dynamically create other software components, called species, and to link such components to their ecosystem in a safe and controlled manner.
For example, one could define a Bank component containing a Database and that creates Account component which themselves requires access to the Database.
Or one could define a MAS component that creates Agent components (themselves architectured as desired) connected to simulated situated entities living in a common 2D environment.
With these abstractions, one can actually implement its own interconnection mechanism between the dynamically created components and their creating component.
This enables for example to cleanly and easily implement any needed interaction mechanism in a MAS when there exists no agent-oriented framework proposing it, to develop domain-specific relations between the agents and their environment or more generally to easily separate concerns (the agents architecture, the simulated agents, the communication) by composing them while explicitly taking into account the 1..N relation existing between an ecosystem and its species.
This document focuses on SpeADL, for the implementation, the reader can refer to the Java for SpeADL reference guide.
SpeADL⁻¶
It is needed to understand the content of the SpeADL⁻ Reference Guide before reading the current document.
Ecosystem and Species Definition¶
From an external point of view, an ecosystem is exactly similar to a component: it has provided ports that can be accessed and required ports that must be connected.
It it identified by a name in a namespace, can have type parameters and be a specialisation of component definition.
It has an implementation in Java, it can be used as a part of another component (or ecosystem) or instantiated directly if it has no required ports.
Its only specificity is that it can contain what is called species, a special kind of component definitions that can only be defined in an ecosystem.
Actually, a component is just an ecosystem without any species.
Because of this particular relation to ecosystems, species can access elements inside the ecosystem in two different ways:
- Directly to the parts and ports of the ecosystem.
- Indirectly through a special construct called uses that enables to take into account the dynamic creation aspects of the species to:
- Build tailored ecosystem-species relations.
- Build tailored inter-species relations mediated by the ecosystem.
Keywords¶
An ecosystem definition is declared with the keyword ecosystem followed by a name, optional type parameters and optional specialization.
Provided and required ports can be declared as with normal component definitions with the keywords provides and requires.
Parts can be declared as with normal component definitions with the keyword part.
A part can reference a typical component or an ecosystem.
A species is declared inside an ecosystem with the keyword species followed by a name starting with a capital.
It can't have type parameters but follows those of its ecosystem, and cannot specialise another component.
A species can have parameters (for initialisation) in-between ( and ) and separated by , : they are of the form name: Type, name2: Type2.
Provided and required ports can be declared as with normal component definitions with the keywords provides and requires.
Parts can be declared as with normal component definitions with the keyword part.
Uses are declared with the keyword use as discussed below.
Details¶
Declaring a species means that an instance of the ecosystem containing it will be able to create new instances of the species at runtime.
Such species will be considered strongly linked to the containing ecosystem instance that created them: this is a thus 1..N relation.
The bindings of the parts can point to ports inside the species, as with a normal component, but also to ports inside the ecosystem containing the species.
They can NOT point to other species of the ecosystem (for inter-species connection, one must exploit the use abstraction detailed below).
Example¶
namespace simple.ecos {
ecosystem MyFirstEco {
species S(name: String) {
provides p1: AJavaInterface = c.portName
provides p2: AJavaInterface
requires p3: AnotherJavaInterface
part c: MyBeautifulComponentType {
bind anotherPortName to p3
}
}
}
}
The Use Abstraction¶
As we said previously, species can only be defined inside ecosystems.Such a relation can be exploited either:
- At the SpeADL level with the bindings and delegation from the species to the ecosystem as described above.
- At a higher-level using advanced interconnection mechanisms between ecosystem and their species.
It is a construct that enables to:
- Build tailored ecosystem-species relations.
- Build tailored inter-species relations mediated by the ecosystem.
Keywords¶
Inside a species, a special type of part (and for the rest it behave exactly as a part) can be declared using the keyword use followed by a name without capital letter.It follows the syntax use name: partName.SpeciesName where:
- partName is the name of a part in the ecosystem containing the current species and whose type is an ecosystem.
- SpeciesName is the name of a species declared in the ecosystem of partName.
- And optionally a list of arguments for the species parameters: one can refer to the parameters of the containing species only.
Details¶
The important point about the use abstraction is that it relies on the definition of ecosystem and species: it is a way to recursively exploit an ecosystem and its species in another ecosystem and its species.
The contained ecosystem and its parts are instantiated with the containing ecosystem, and its species instantiated with the species that use them.
Example¶
namespace simple.ecos {
ecosystem MySecondEco {
part e: MyFirstEco
species S(name: String) {
part c: MySimpleComponentType
use s: e.S(name) {
bind p3 to c.p1
}
}
}
}
Mis à jour par Anonyme il y a environ 6 ans · 34 révisions