... | ... | @@ -14,9 +14,17 @@ The figure illustrates the Traffic Segment Information Collection sub-choreograp |
|
|
|
|
|
**-Experimental unit 1:** *CHOReVOLUTION approach* - full usage of the **CHOReVOLUTION** platform except for the development of the mobile application, which is out of the scope.
|
|
|
|
|
|
**-Experimental unit 2:** *General-purpose enterprise-oriented technology* - full usage of the development technology daily adopted by the Götheborg partner, i.e., NodeJS v9.5.0 and ExpressJS v4.16.0.
|
|
|
**-Experimental unit 2:** *General-purpose enterprise-oriented technology* - full usage of the development technology daily adopted by the Götheborg partner, i.e., NodeJS v9.5.0 and ExpressJS v4.16.0, and Microsoft Visual Studio.
|
|
|
|
|
|
The technologies of the experimental units 2 were selected considering that the industrial partner was already familiar and skilled with them.
|
|
|
As in the other use case, opting for an alternative would have required a training effort that could not be afforded by the partner because of budget constraints. Even if it had been possible to opt for an alternative, it would have been not easy to reach the same level of expertise, hence possibly compromising the validity of the experiment.
|
|
|
|
|
|
The experiment was conducted by two different development teams. The team involved in the experimental unit 1 was formed by two developers of the **CHOReVOLUTION** project. The other team, involved in the experimental units 2, was formed by one of the above two developers plus another one developer from a different project. The experimental tasks were distributed to the different developers to eliminate the potential bias of person-task links. All developers had equivalent professional skills and familiarity with the concerned technologies. |
|
|
\ No newline at end of file |
|
|
The experiment was conducted by two different development teams. The team involved in the experimental unit 1 was formed by two developers of the **CHOReVOLUTION** project. The other team, involved in the experimental units 2, was formed by one of the above two developers plus another one developer from a different project. The experimental tasks were distributed to the different developers to eliminate the potential bias of person-task links. All developers had equivalent professional skills and familiarity with the concerned technologies.
|
|
|
|
|
|
**-Hypothesis 1-** We found that the **CHOReVOLUTION** approach significantly decreased the time required to implement the UTC use case.
|
|
|
|
|
|
| **Tasks** | **Experimental unit 1 (ph)** | **Experimental unit 2 (ph)** |
|
|
|
| :--------: | :--------: | :--------: |
|
|
|
| Coordination logic | The developer models the choreography by means of a dedicated GUI, and specifies the type of the messages through the XML schema notation. After the modeling phase, which is manual, the code realizing the distributed coordination logic is automatically generated into a set of CDs, without requiring any manual intervention. |
|
|
|
Implement the coordination logic and the business logic for each of the distributed workflows with NodeJS and Visual Studio Code IDE. Design the session handling mechanism. Design a mechanism to replace distributed workflow (subsequent tasks, parallel/decision gateways). Design a mechanism to handle asynchronous tasks in parallel.|
|
|
|
| Prosumer services | After the choreography modeling phase, the skeleton code of the prosumer services is automatically generated. Thus, developers are required to only fill in the blanks of highlighted and partially ready pieces of code. | The prosumer services are manually implemented. In particular, for each choreography task involving a specific participant, all the logic to manipulate received messages and to build the messages to be sent need to be coded from scratch (without having the skeleton code generated). The developers have to maintain the data and message storage to ensure the messages are well parsed and routed through different distributed flows with no data lost.| |