Reference Guides » Historique » Version 1
Anonyme, 02/10/2014 16:15
| 1 | 1 | Anonyme | h1. SpeADL Reference |
|---|---|---|---|
| 2 | |||
| 3 | SpeADL is a language to describe component-oriented architectures and implement them in Java. |
||
| 4 | |||
| 5 | This page is decomposed in two parts: |
||
| 6 | # SpeADL^-^: it concerns the traditional component-oriented abstractions such as components, interfaces, composites, specialisation, provided and required ports, bindings, etc |
||
| 7 | # SpeADL: it concerns the specific abstractions introduced by SpeADL to help the development of MAS with ecosystems and species. |
||
| 8 | |||
| 9 | h2. SpeADL^-^ |
||
| 10 | |||
| 11 | In SpeADL, a set of abstractions are provided to define traditional component-oriented architectures. |
||
| 12 | With it, it is possible to define components and compositions of components, called composites, and to implement them in Java while keeping a strong link between definition and implementation by relying on an Eclipse plugin. |
||
| 13 | |||
| 14 | A component (and thus a composite components) is made of two elements: a definition using SpeADL and an implementation using Java. |
||
| 15 | From the SpeADL definition, an abstract Java class is automatically generated and then relied upon through the Java extension mechanism to implement it in a safe manner. |
||
| 16 | |||
| 17 | h3. Namespaces |
||
| 18 | |||
| 19 | Components and composites are defined inside namespace using the keyword *namespace*. |
||
| 20 | A namespace plays the exact same role as a package in Java. |
||
| 21 | |||
| 22 | In a SpeADL file, there can be many as namespace (as well as nested ones) as wanted. |
||
| 23 | Hence a namespace does not have to follow the name of the directory it is located in as in Java. |
||
| 24 | |||
| 25 | Here is an example of namespace declarations: |
||
| 26 | <pre> |
||
| 27 | namespace simple { |
||
| 28 | |||
| 29 | namespace things { |
||
| 30 | } |
||
| 31 | } |
||
| 32 | |||
| 33 | namespace simple.stuffs { |
||
| 34 | } |
||
| 35 | </pre> |
||
| 36 | |||
| 37 | Each namespace declaration can contain any component as desired as we are going to see. |
||
| 38 | |||
| 39 | h3. Imports |
||
| 40 | |||
| 41 | As in Java, it is possible to import existing types into a file to avoid referring to them with their fully qualified name (i.e., including their package or namespace) using the keyword *import*. |
||
| 42 | |||
| 43 | The syntax is similar to Java: |
||
| 44 | <pre> |
||
| 45 | import java.util.Collection |
||
| 46 | import java.util.* |
||
| 47 | import simple.stuffs.* |
||
| 48 | </pre> |
||
| 49 | |||
| 50 | Notice that namespace of components are also considered, and that there is no semi-colon ";" at the end of the line. |
||
| 51 | |||
| 52 | The imports can be automatically handled and reorganised in Eclipse using the *Ctrl-Shift-O* shortcut as in the Java editor. |
||
| 53 | |||
| 54 | h3. Components and Ports |
||
| 55 | |||
| 56 | A component is made of a definition and an implementation. |
||
| 57 | The definition gives it a name and a list of ports that are either provided or required by the component. |
||
| 58 | Each port has a name and an interface. |
||
| 59 | An interface is understood as a Java interface, i.e., a collection of methods. |
||
| 60 | |||
| 61 | A component that provides a port must thus provide an implementation for its interface. |
||
| 62 | Inversely, a component that requires a port can use in its implementation the methods of the interface of the required port. |
||
| 63 | |||
| 64 | A component with required ports must be composed with other components so that there exist an actual implementation of the interface of the required port: this is covered in the next section. |
||
| 65 | |||
| 66 | When implementing a component, one only has to take care of implementing the provided port, and can exploit the required ports without assuming anything about their implementation and who provides it. |
||
| 67 | This is what makes a component fundamentally different from an object. |
||
| 68 | |||
| 69 | A component is defined using the following syntax: |
||
| 70 | <pre> |
||
| 71 | import my.interfaces.* |
||
| 72 | |||
| 73 | namespace simple.stuffs { |
||
| 74 | component ComponentName { |
||
| 75 | provides portName: AJavaInterface |
||
| 76 | requires anotherPortName: AnotherJavaInterface |
||
| 77 | } |
||
| 78 | } |
||
| 79 | </pre> |
||
| 80 | |||
| 81 | A component is defined using the keyword *component*, has a name and can contains as many port declaration as wanted. |
||
| 82 | |||
| 83 | A port has a name and an interface. |
||
| 84 | The keywords *provides* and *requires* respectfully represents ports that are provided and required by the component and are a mandatory keyword when defining a port inside a component. |
||
| 85 | |||
| 86 | Obviously, having an interface means that there must exist already an interface defined with the same name. |
||
| 87 | Such a definition is done in Java as one would normally do, for example, as follow, in a Java file: |
||
| 88 | <pre> |
||
| 89 | package my.interfaces; |
||
| 90 | |||
| 91 | interface AJavaInterface { |
||
| 92 | public String aMethod(Integer param1); |
||
| 93 | } |
||
| 94 | </pre> |
||
| 95 | |||
| 96 | In SpeADL, one can use completion to complete interface names. |
||
| 97 | Also, the shortcut to organize imports will take interfaces into account. |