Technical report
A.3.4 Automated execution
Download 5.82 Mb.
|
- Navigate this page:
- A.3.5 Experiences
- History
A.3.4 Automated executionIn this section, the two approaches for automating test generation and execution are shown. One for the execution guided by UML-based models and the other by using the SCA4SAUT/SCXML models. In the UML based approach the models defined with the Papyrus tool are stored as XMI files. The models are then uploaded into the MIDAS TaaS file system, bundled with the usage journals if UBT has to be employed. When fuzzy methods are to be employed, it is recommended to add more models that refine the fuzzyfication strategies. These models are expressed as UML sequence diagrams and, in the eHealth pilot, the message exchanges are all synchronous. The sequence diagrams have been designed using the same UML modelling tool as the SAUT models and are bundled together as XMI files. The following Figures show examples of sequence diagrams modelling two interactions with IXS MQ interface, one interaction with RLUS MQ interface and one interaction with RLUS Metadata interface. 
Figure 38: Sequence diagrams modelling two interactions with IXS MQ interface 
Figure 39: Sequence diagrams modelling one interaction with RLUS MQ 
Figure 40: Sequence diagrams modelling one interaction with RLUS Metadata interface At this stage, the proper TestGenAndRun method has to be called through the MIDAS TaaS interfaces and this starts a rather lengthy thus asynchronous process of generation, compilation and execution of test cases. A.3.5 ExperiencesAt the time of writing, the MIDAS TaaS is in the phase of finalization, therefore the complete automated test generation use case has not been achieved so far. The preliminary experiences are mainly related to the modelling and auxiliary activities. In particular, there is no complete assessment of the fully automated test scenario yet since the pilot has not yet been able to generate executable TTCN code from the supplied models and PSM artefacts. Modelling with the UML-based language could be quite overwhelming for typical industrial context. Especially when considering that many technical descriptions of a SoA is usually already available in the form of WSDL, XSD, Schematrons and in some cases even UML models. In particular, the datatypes modelling is very expensive and it is hardly reusable or shareable because there is still a severe interoperability issue among the different UML modelling tools. The effort spent by the MIDAS development team to realize a WSDL/XSD importer that transforms all data and component structures into UML significantly enhances the ratio between automated vs manual activities. Summarizing the most significant issues that are currently open to assess the automated use case are: Is the datatype importer stable enough to face all the challenges posed by the very complex models available in XSD and that could be used in a scenario like the eHealth Pilot where generic services are employed? Currently the complexity impedance between XSD and UML is the major cause that has blocked the generation of TTCN code for the healthcare pilot. It is fundamental that this importer becomes stable and the import of datatypes fully automated in order to be able to achieve a positive result for the automated use case. The journal that is used for generating test cases for the usage based testing cannot be used (or only to a certain degree) for the security based testing. This causes the MIDAS user that want to deploy security-testing procedures, to explicitly draw sequence diagrams and instance specifications for the generation of test cases, thus reducing significantly the benefit of the automated testing use-case. The SCA4SAUT/SCXML approach, which we consider to be somehow a more bottom-up approach, works by associating with the already available PSM level information, and other lower level models based on XML (SCA and SCXML). From a developer point of view, this is surely a straightforward and more interoperable approach because it eliminates ambiguities related to graphical models, simplifies the editing of artefacts and in general allows the treatment of the models with the same techniques and procedures adopted for source code management. Anyway, the current lack of a commonly accepted graphical formalism could represent an obstacle to its adoption by people without specific technical skills. Moreover, being this approach based on rather novel standards (particularly true for SCXML), it feels like there are still some issues to be faced in the relation between described artefacts and functionalities inside MIDAS. Currently there is no possibility to fully assess the automated testing use case with this tool stack mainly because of technical issues related to the advanced functionalities, like intelligent planner and scheduler of test cases. Anyway, the lower impedance among the adopted models and the PSM level artefacts will probably be a positive key factor in the final demonstration and, possibly, in a future commercial exploitation. Regarding the installation and implementation of extra tooling, an important consideration is that the installation of software in the form of HTTP proxies into an operating SoA could be an issues, which challenges and violates company or customer security policies. In this case, the creation of a usage journal for UBT could become a tricky issue. The implementation of state-view auxiliary services also presents some impact on the SoA, but since the approach is service oriented and optional, we can assume a smaller impact compared to the first approach. Finally, interface for accessing service implementations' internal state are in general already present and they can typically be reused and adapted. The biggest issue, in this case, is the requirement that those services have a WS* based interface. In order to reduce the burden on SoA developers and maintainers it could be useful to adapt MIDAS services to use also REST-based auxiliary services. History
0 The selected tools used to set up the virtual machine are Vagrant and Ansible. 0the m1.small EC2 instance configuration is the one reported in http://aws.amazon.com/ec2/previous-generation/ 0 https://hssp.wikispaces.com/ Download 5.82 Mb. Share with your friends:
| ||||||||||||||||||