Projet

Général

Profil

SpeADL Reference » Historique » Version 13

Anonyme, 09/10/2014 10:41

1 1 Anonyme
h1. SpeADL Full Reference
2
3 5 Anonyme
h1. DRAFT Document
4 4 Anonyme
5 1 Anonyme
In SpeADL, a set of abstractions are provided to describe typical component-oriented architectures.
6
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.
7
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.
8
9 7 Anonyme
The main idea with these abstraction is to permit to define software components, called ecosystems, that are able to dynamically create other software components, called species, and link such components to some of their sub-components in a safe and controlled manner.
10 1 Anonyme
For example, one can define a Bank component containing a Database and that creates Account component which themselves requires access to the database.
11 7 Anonyme
Or one can define a MAS environment component that creates Agent components (internally architectured as desired)connected through localised interaction mechanisms like an agent-oriented framework would do.
12 1 Anonyme
13
But more interestingly, one can actually implement its own connection between the dynamically created components and the creating component.
14
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.
15
16 12 Anonyme
17
18 1 Anonyme
h2. SpeADL⁻
19
20
It is needed to understand the content of the [[SpeADL Minus Reference|SpeADL⁻ Reference Guide]] before reading the current document.
21
22 6 Anonyme
h2. Ecosystem Class Definition
23 1 Anonyme
24 6 Anonyme
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.
25 1 Anonyme
It has a name, can have type parameters and be a specialisation of another component.
26
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.
27
28 7 Anonyme
Its only specificity is that it can contain what is called species, a special type of component that can only be defined in an ecosystem.
29 1 Anonyme
Actually, we can say that a component is an ecosystem without any species.
30
31 12 Anonyme
Species are to ecosystems what non-static inner classes are to classes.
32
33
Species are components class that can only be instantiated from within an ecosystem instance.
34
Because of this particular relation to ecosystem, species can be connected to elements inside the ecosystem in two different ways:
35
* Directly to the parts and ports of the ecosystem.
36
* Indirectly through a special construct called Uses that enables to take into account the dynamic creation aspects of the species to:
37
** Build tailored ecosystem-species relations.
38
** Build tailored inter-species relations meditated by the ecosystem.
39
40 1 Anonyme
h3. Keywords
41
42
An ecosystem class definition is declared with the keyword *ecosystem* followed by a name, optional type parameters and optional specialization.
43
Inside an ecosystem, provided and required ports can be declared as with normal components with the keywords *provides* and *requires*.
44 9 Anonyme
Inside an ecosystem, parts can be declared as with normal components with the keyword *part*.
45 1 Anonyme
46 12 Anonyme
A species is declared inside an ecosystem with the keyword *species* followed by a name starting with a capital.
47
It has no type parameters but follows those of its ecosystem, and cannot specialise a component.
48
Inside a species, provided and required ports can be declared as with normal components with the keywords *provides* and *requires*.
49
Inside a species, parts can be declared as with normal components with the keyword *part*.
50
51 10 Anonyme
h3. Details
52
53 1 Anonyme
Declaring an ecosystem only enables to declare species in them: if there is no species in it, it is exactly similar to a component.
54
55 12 Anonyme
Declaring a species means that the ecosystem instance that contains it will be able to create new instances of the species at runtime.
56
Such species will be considered strongly linked to the containing ecosystem instance that created them: this is a thus 1..N relation.
57 1 Anonyme
58 12 Anonyme
Such a relation can be exploited either:
59
* In the implementation of the ecosystem and the species (sharing references to Java objects, calling a port of the ecosystem from the species, etc).
60
* At the SpeADL level with the bindings and delegation from the species to the ecosystem.
61
* At a higher-level using advanced interconnection mechanisms between ecosystem and their species as explained [[SpeADL Full Reference#The Use Abstraction|below]] (using a message passing mechanism between the dynamically created instances of a species).
62
63
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.
64
They can NOT point to other species of the ecosystem (for inter-species connection, one must exploit the use abstraction).
65
66 1 Anonyme
h3. Example
67
68
<pre>
69
namespace simple.ecos {	
70 12 Anonyme
	ecosystem MyFirstEco {
71
72 1 Anonyme
		species S {
73 12 Anonyme
			provides p1: AJavaInterface = c.portName
74
			requires p2: AnotherJavaInterface
75
			
76
			part c: MyBeautifulComponent {
77
				bind anotherPortName to p2
78
			}
79 3 Anonyme
		}
80
	}
81
}
82
</pre>
83
84 12 Anonyme
h2. The Use Abstraction
85 3 Anonyme
86
87 1 Anonyme
h3. Keywords
88 11 Anonyme
89 12 Anonyme
Inside a species, a special type of part can be declared using the keyword *use* followed by a name without capital letter.
90 11 Anonyme
It follows the syntax _use name: partName.SpeciesName_ where:
91
* _partName_ is the name of a part in the ecosystem containing the current species and whose type is an ecosystem.
92
* _SpeciesName_ is the name of a species declared in the ecosystem of _partName_.
93
94
h3. Details
95
96
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.
97
The contained ecosystem and its parts are instantiated with the containing ecosystem, and its species instantiated with the species that use them.
98
99
h3. Example
100
101
<pre>
102
namespace simple.ecos {	
103
	ecosystem MySecondEco {
104
		
105
		part e: MyFirstEco
106
		
107
		species S {
108
			
109
			part c: MySimpleComponent
110
			
111
			use s: e.S {
112
				bind p2 to c.p1
113
			}
114
		}
115 1 Anonyme
	}
116
}
117
</pre>