SpeADL Minus Java Reference » Historique » Version 9
Anonyme, 16/10/2014 10:44
| 1 | 3 | Anonyme | h1. Java for SpeADL⁻ Reference Guide |
|---|---|---|---|
| 2 | 1 | Anonyme | |
| 3 | 2 | Anonyme | In the [[SpeADL Minus Reference|SpeADL⁻ reference guide]] we saw how one can define components and composition of components. |
| 4 | We now present how to implement these components in Java. |
||
| 5 | 1 | Anonyme | |
| 6 | 4 | Anonyme | h2. Terminology |
| 7 | |||
| 8 | The reader can refer to the [[MAY Terminology]] document to get an overview of the different terms used in SpeADL. |
||
| 9 | |||
| 10 | h2. SpeADL⁻ |
||
| 11 | |||
| 12 | It is needed to understand the content of the [[SpeADL Minus Reference|SpeADL⁻ Reference Guide]] before reading the current document. |
||
| 13 | |||
| 14 | 1 | Anonyme | h2. Component Implementation |
| 15 | |||
| 16 | To implement a component, one has to extend the abstract class generated automatically by the Eclipse plugin. |
||
| 17 | For example, for the previous example _simple.stuffs.MyBeautifulComponent_ defined in SpeADL, a Java class _simple.stuffs.MyBeautifulComponent_ is generated (in the *speadl-gen* folder, different than the *src* folder). |
||
| 18 | |||
| 19 | It is not needed to look at the generated code to use it: when extending the class, some abstract methods will have to be implemented. |
||
| 20 | |||
| 21 | 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. |
||
| 22 | This is one thing that makes a component fundamentally different from an object. |
||
| 23 | |||
| 24 | h3. Special Methods to Implement |
||
| 25 | |||
| 26 | Each provided port *p* of interface *I* must be implemented by overriding a method called *I make_p()* which returns an instance of the implementation for the port. |
||
| 27 | This instance is used for the whole life of the component, i.e., the *make_p()* method is called only once to construct the port when the component is instantiated. |
||
| 28 | |||
| 29 | Each part *p* of component class *C* has a corresponding abstract method *C make_p()* to override and which must return an instance of an implementation of *C*. |
||
| 30 | The bindings and other connections inside the components are totally taken care of by the generated code and the implementation only needs what is Java-specific. |
||
| 31 | |||
| 32 | Furthermore, optionally, a method *void start()* can be override as explained [[SpeADL_Minus_Reference#Component-Initialisation|below]]. |
||
| 33 | |||
| 34 | h3. Special Methods to Exploit |
||
| 35 | |||
| 36 | The *requires()* method (inherited from the extended generated class) gives access to each of the required ports (e.g., _requires().port()_). |
||
| 37 | A port being an implementation of an interface (and not of an operation), it is then necessary to call the desired method on it (e.g., _requires().port().method()_). |
||
| 38 | |||
| 39 | The *provided()* method (inherited from the extended generated class) gives access to each of the provided ports in the same manner. |
||
| 40 | |||
| 41 | It is possible to access to the provided ports of the part from within the implementation of a composite by using the method *parts()* (e.g., _parts().partName().portName().method()_). |
||
| 42 | |||
| 43 | h3. Examples |
||
| 44 | |||
| 45 | Implementing a component with a provided port: |
||
| 46 | 9 | Anonyme | <pre> |
| 47 | 1 | Anonyme | package testpackage; |
| 48 | |||
| 49 | import my.interfaces.AnotherJavaInterface; |
||
| 50 | import simple.stuffs.MySimpleComponent; |
||
| 51 | |||
| 52 | public class MySimpleComponentImpl extends MySimpleComponent { |
||
| 53 | |||
| 54 | @Override |
||
| 55 | protected AnotherJavaInterface make_p1() { |
||
| 56 | return new AnotherJavaInterface() { |
||
| 57 | @Override |
||
| 58 | public Integer test() { |
||
| 59 | return 10; |
||
| 60 | } |
||
| 61 | }; |
||
| 62 | } |
||
| 63 | |||
| 64 | } |
||
| 65 | 9 | Anonyme | </pre> |
| 66 | 1 | Anonyme | |
| 67 | The same result can be obtained by implementing the port directly by the component implementation as follow: |
||
| 68 | 9 | Anonyme | <pre> |
| 69 | 1 | Anonyme | public class MySimpleComponentImpl extends MySimpleComponent implements AnotherJavaInterface { |
| 70 | |||
| 71 | @Override |
||
| 72 | public Integer test() { |
||
| 73 | return 10; |
||
| 74 | } |
||
| 75 | |||
| 76 | @Override |
||
| 77 | protected AnotherJavaInterface make_p1() { |
||
| 78 | return this; |
||
| 79 | } |
||
| 80 | } |
||
| 81 | 9 | Anonyme | </pre> |
| 82 | 1 | Anonyme | |
| 83 | Exploiting a required port: |
||
| 84 | 9 | Anonyme | <pre> |
| 85 | 1 | Anonyme | package testpackage; |
| 86 | |||
| 87 | import my.interfaces.AJavaInterface; |
||
| 88 | import simple.stuffs.MyBeautifulComponent; |
||
| 89 | |||
| 90 | public class MyComponentImpl extends MyBeautifulComponent { |
||
| 91 | |||
| 92 | @Override |
||
| 93 | protected AJavaInterface make_portName() { |
||
| 94 | return new AJavaInterface() { |
||
| 95 | @Override |
||
| 96 | public String aMethod(Integer param1) { |
||
| 97 | return "" + param1 + " and " + requires().anotherPortName().test(); |
||
| 98 | } |
||
| 99 | 6 | Anonyme | @Override |
| 100 | public String anotherMethod() { |
||
| 101 | return "plop"; |
||
| 102 | } |
||
| 103 | 1 | Anonyme | }; |
| 104 | } |
||
| 105 | } |
||
| 106 | 9 | Anonyme | </pre> |
| 107 | 1 | Anonyme | |
| 108 | Implementing a component with parts, calling a part's provided port: |
||
| 109 | 9 | Anonyme | <pre> |
| 110 | 7 | Anonyme | public class CompositeCompImpl extends MyCompositeComponent { |
| 111 | 1 | Anonyme | |
| 112 | @Override |
||
| 113 | protected MySimpleComponent make_s() { |
||
| 114 | return new MySimpleComponentImpl(); |
||
| 115 | } |
||
| 116 | |||
| 117 | @Override |
||
| 118 | protected AnotherJavaInterface make_p1() { |
||
| 119 | return new AnotherJavaInterface() { |
||
| 120 | @Override |
||
| 121 | public Integer test() { |
||
| 122 | return parts().s().p1().test(); |
||
| 123 | } |
||
| 124 | }; |
||
| 125 | } |
||
| 126 | |||
| 127 | @Override |
||
| 128 | protected MyBeautifulComponent make_b1() { |
||
| 129 | return new MyComponentImpl(); |
||
| 130 | } |
||
| 131 | |||
| 132 | @Override |
||
| 133 | protected MyBeautifulComponent make_b2() { |
||
| 134 | return new MyComponentImpl(); |
||
| 135 | } |
||
| 136 | |||
| 137 | @Override |
||
| 138 | protected MyBeautifulComponent make_b3() { |
||
| 139 | return new MyComponentImpl(); |
||
| 140 | } |
||
| 141 | } |
||
| 142 | 9 | Anonyme | </pre> |
| 143 | 1 | Anonyme | |
| 144 | h2. Component Instantiation |
||
| 145 | |||
| 146 | In order to instantiate a component from Java, one need an instance of an implementation of the component and to call the *newComponent()* method (present in the generated class) to get an instance of the component. |
||
| 147 | |||
| 148 | h3. Details |
||
| 149 | |||
| 150 | Only component without required port can be manually instantiated from Java: if a component has required ports, it must be composed with other components in a composite component. |
||
| 151 | |||
| 152 | Once we have an instance of a component, we can call the methods of its provided ports. |
||
| 153 | |||
| 154 | The same applies for composite components, the instantiation of the part of a composite is done automatically by the generated code. |
||
| 155 | |||
| 156 | h3. Example |
||
| 157 | |||
| 158 | 9 | Anonyme | <pre> |
| 159 | 1 | Anonyme | MySimpleComponent.Component c = new MySimpleComponentImpl().newComponent(); |
| 160 | System.out.println(c.p1().test()); |
||
| 161 | 9 | Anonyme | </pre> |
| 162 | 1 | Anonyme | |
| 163 | h2. Component Initialisation |
||
| 164 | |||
| 165 | When the implementation of a component is instantiated (before calling *newComponent()*), its constructor is of course called but the component itself is not yet initialised: in particular its provided required ports and parts can't be called at that time. |
||
| 166 | |||
| 167 | h3. Details |
||
| 168 | |||
| 169 | In order to do some initialisation at the instantiation of a component (during the call to *newComponent()*), one can override the *void start()* method of the extended abstract class. |
||
| 170 | |||
| 171 | h3. Example |
||
| 172 | |||
| 173 | 9 | Anonyme | <pre> |
| 174 | 1 | Anonyme | public class MySimpleComponentImpl extends MySimpleComponent { |
| 175 | |||
| 176 | @Override |
||
| 177 | protected AnotherJavaInterface make_p1() { |
||
| 178 | return new AnotherJavaInterface() { |
||
| 179 | @Override |
||
| 180 | public Integer test() { |
||
| 181 | return 10; |
||
| 182 | } |
||
| 183 | }; |
||
| 184 | } |
||
| 185 | |||
| 186 | @Override |
||
| 187 | protected void start() { |
||
| 188 | // do some initialisation using the requires() or the parts(), create a GUI, etc... |
||
| 189 | } |
||
| 190 | } |
||
| 191 | 9 | Anonyme | </pre> |
| 192 | 1 | Anonyme | |
| 193 | h2. Lifecycle of Component Initialisation at Instantiation |
||
| 194 | |||
| 195 | When *newComponent()* is called on a component implementation, this is what happens: |
||
| 196 | # The component is instantiated (see below). |
||
| 197 | # The instance is started (see below). |
||
| 198 | |||
| 199 | h3. Component Instantiation |
||
| 200 | |||
| 201 | # For each part *partX* in the order of declaration |
||
| 202 | ## The implementation is instantiated with the *make_partX()* method. |
||
| 203 | ## A component is instantiated from the implementation following the current procedure. |
||
| 204 | # For each provided port *portX* in the order of declaration (starting with the super-component in case of specialisation) |
||
| 205 | ## The interface implementation is instantiated with the *make_portX()* method. |
||
| 206 | |||
| 207 | h3. Component Instance Start |
||
| 208 | |||
| 209 | # For each part *partX* in the order of declaration |
||
| 210 | ## The part is started following the current procedure. |
||
| 211 | # The implementation *start()* method is called. |