Migration of a Chosen Architectural Pattern to Service Oriented ...

Chapter 2. Related Work 20/ response messages and corresponding screens are gathered and followingoutputs are generated [23]:(a) Finite State Automation – contains all identified states, transitionsbetween the states and transition triggers. The automation is not deterministicbecause given the same input; user may have a few availablepaths to follow.(b) Screen Templates – contain sets of screens that correspond to eachstate from FSA. Each screen contains features like labels and theirlocalisation. This information is necessary for automatic identification.(c) Interface –more precisely service contract with all the input and outputvariables (see 4.2.4).3. Wrapper Design – the last process makes use of previously created InteractionModel. Designing is meant to make a model interpretable by AutomationEngine. In order to achieve interpretability, the model has tobe enhanced by an additional information regarding activities executed byEngine on Automation Variables or screen fields. The additional data maycontain localization of a field, commands, input /output fields etc.Deploying and validating the wrapped use case The last process is nothingmore than establishing infrastructure for services and testing whether theyfulfill requirements [23].1. Deployment –includes all the information required to export and publishservices. The process is dependent on selected technology, for instance:selection of Web Service requires creation of WSDL document [23]2. Validation –since a significant part of the second process uses automation forcreation of Finite State Automation, validation gains in value and becomesa mandatory activity. The Validation aims at identification of failures. Thefailures may manifest as a lack of screen or an a received message is differentthan expected. Validation process can be performed in following manner[23]:(a) Regressive testing – tests take as an input data used during Reverse Engineeringand check whether expected output is delivered by a legacysystem. The tests require coverage on scenario level, what means thatevery scenario of each use case have to be executed at least once [23].(b) Path testing – the second approach requires analysis of FSA in orderto design tests covering each independent path. This means that allnodes and edges of the FSA need to be visited at least once. PathCoverage is a high level testing that requires a lot of effort to identifyall possible paths.