Make Agents Yourself

h1. SpeADL Full Reference

In SpeADL, a set of abstractions are provided to describe typical component-oriented architectures.

On top of these, SpeADL introduced two additional abstractions that complete the typical component-oriented ones in order to describe dynamic architectures and in particular Multi-Agent Systems.

The motivations behind these abstractions are fully explained in the Ph.D. thesis that led to the creation of MAY, see "that page":http://www.irit.fr/~Victor.Noel/PhD/Dissertation for more information.

The main idea with these abstraction is to permit to define software components, called ecosystems, that are able to create other software components, called species, dynamically, and link such components to some of their sub-components in a safe and controlled manner.

For example, one can define a Bank component containing a Database and that creates Account component which themselves requires access to the database.

Or one can define a MAS environment component that creates Agent components (internally architectured as desired) like an agent-oriented framework would do.

But more interestingly, one can actually implement its own connection between the dynamically created components and the 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, or to develop domain-specific relations between the agents and their environment.

h2. SpeADL⁻

It is needed to understand the content of the [[SpeADL Minus Reference|SpeADL⁻ Reference Guide]] before reading the current document.

h2. Ecosystem and Species Class Definition

From an external point of view, an ecosystem is exactly similar to a component: it has provided that can be accessed and provided ports that must be connected.

It has a name, can have type parameters and be a specialisation of another component.

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.

On top of that, it can contain what is called species, a special type of component that can only be defined in an ecosystem.

Actually, we can say that a component is an ecosystem without any species.

h3. Keywords

An ecosystem class definition is declared with the keyword *ecosystem* followed by a name, optional type parameters and optional specialization.

Inside an ecosystem, provided and required ports can be declared as with normal components with the keywords *provides* and *requires*.

Inside an ecosystem, parts can be declared as with normal components with the keyword *part*.

A species is declared inside an ecosystem with the keyword *species* followed by a name starting with a capital.

It has no type parameters but follows those of its ecosystem, and cannot specialise a component.

Inside a species, parts can be declared as with normal components with the keyword *part*.

Finally, inside a species, a special type of 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_.