Baixe cloud deployed repository Parte4 e outras Notas de estudo em PDF para Engenharia Unificada Básica, somente na Docsity!
As an example of comparison regarding the code size, we can cite the methods implemented for transformations View to SUM and SUM to View of the ComponentClass. These methods had two hundred and twenty lines of code to perform the six lines of the OCL restriction shown in Figure 4.34. The Table 4.2 displays the metrics of the codification of the transformations rules of the KobrA2 metamodel portion taken as study in this work.
Table 4.2 - Transformations Metrics Statistic Value Packages 3 Classes 9 Total of Lines of Code 7. Size of Implementation 304 KB A Table 4.3 shows the metrics related to general implementation of WAKAMEWebService, including the transformation metrics, but not taking into account the metrics of the model repository. All the WAKAMEWebService code and transformations were implemented manually, while the code of the model repository, presented in Section 4.2.5 was automatically generated by EMF, requiring few manual corrections.
Table 4.3 – WAKAMEWebService Implementation Metrics Statistic Value Packages 11 Classes 57 Total of Lines of Code 23. Size of Implementation 931 KB 4.2.7 WAKAMEWebService Integration with WAKAMEGUI, Tests and Deployment
Throughout the implementation phase were performed unit tests of classes and methods, as they were developed. In these unit tests, several bugs were found and fixed by the author, thus ensuring a minimum quality of the code.
For the integration of WAKAMEWebService with the implementation of WAKAMEGUI, an environment has been created on Google App Engine to store both implementations, Server and GUI. This environment created to perform integration testing is similar to the production environment in which the tool WAKAME is published. This is excellent for testing, because in this way, we avoid (unpleasant) "surprises" when it is published in a production environment, which is likely to occur when dealing with
differences in environments. The test environment can be accessed through the address http://wakameemf.appspot.com.
Both code, WAKAMEWebService and WAKAMEGUI, were placed on version control through SVN, so that both authors could have access to the modifications occurred in the components during the integration phase.
This integration phase consisted primarily of providing the services of WAKAMEWebService through URLs, so that the WAKAMEGUI could access. The communication was set to both through HTTP requests in JSON format, as stated in Section 4.2.6. Therefore, at this stage, we tested the formats of communication defined in the implementation phase, and the bugs have been fixed as they were identified.
After the tests of integration between WAKAMEWebService and WAKAMEGUI, some general WAKAME tests were taken. For these, we have used the same environment of the integration tests. It was created also a project called WAKAME on Google Project Hosting to manager the coordination of the tests. This project provides an issue tracker , so that each issue found in testing, could be registered to be discussed, besides taking the necessary corrections. The issue tracker was used to manage the bugs found, but also to allow requests for improvements in the tool. This tracker can be accessed through the address http://code.google.com/p/wakame/issues/list. Additionally, the main types of problems were categorized, if, for example, they are related to Component UI, Logic or Persistence. As the tool WAKAME was released in a web environment for testing, anyone could access it, and if any problem or suggestion is found, it could register it in the issue tracker. Figure 4.35 shows the screen of the issue tracker that displays the list of existing issues.
The tests were performed and reported by the authors and several collaborators from the research group, in which the tool was performed. Until this date, were opened one hundred and twenty four issues in the project and sixty-seven have been corrected, thirteen issues were invalid, and seven was duplicate, remaining forty-one issues open. Nevertheless, thirty issues are related to improvements.
Figure 4.36 - WAKAME Main Page Figure 4.37 displays the page to create a new model in the tool. Firstly, the user sets the model name, a description and the authors. The page to import a model from a XMI file, Figure 4.38, is similar to the registration page, with only one extra field, which is the one to upload the XMI file. This feature allows only importing KobrA2 models in XMI format; WAKAME does not support importing other types of models, such as UML, MOF or Ecore.
Figure 4.37 - WAKAME Create Model Page
Figure 4.38 - WAKAME Import Model Page
Once you select the link "Go to Model", for a specific model, the user will be redirected the modeling page, Figure 4.41. This is the main project WAKAME page, which allows modeling any system. On the left side, are displayed the combo-boxes for selecting the view, according to the possible different perspectives:
Encapsulation – Specification to select the views of the component specification, or, Realization , which lets you select the realization views of the component; Projection – Structural , for the views of structural modeling of the component, or, Operational , for the views of modeling, in OCL, of the operations declared in structural view; and, View – allows the options: Service , for the views of services that the component will provide, or Type , the views of types used in the component. Below the combo-boxes for selecting the appropriate view, there are the buttons " fromCloud " to refresh the selected view with the new view on the server, and " toCloud " to persist the view on the server.
On the right side, we have the " component navigation tree ", which allows navigation of the views for the component. Just below there is the " element selection tree ", which lets you drag to the current view, an existing element to the current view. The bottom of the tool has a panel for displaying the messages, which can be notifications, error or debug messages.
The center of the tool is the free area for modeling and has at its top, the tool bar with the possible elements for modeling the view in question. The content of this tool bar will vary for each type of view, since each one allows a set of different elements.
Figure 4.41 - WAKAME Modeling Page
Diagram layout control and legibility – This aspect relates to the amount of control the user has over the working diagram and how legible is the diagram for the user. Standard compliance – This criteria takes in consideration aspects related to whether the tool is adherent to its standards and constrains the models created by the user to fit these standards. However it is very difficult to obtain objective measurement data to determine whether the tool could fit these goals, or even to state the level of its agreement, since they have high subjectivity. Therefore we decided to compare the performance of the WAKAME tool with another tool. This comparison had to happen according to the identified business objectives, and the modeling performance would be measured considering the same business objectives in both tools. For accomplish this, we needed to choose a CASE tool where the user could create KobrA2 models and that meets the following constraints:
UML 2 compliance - For being compliant to the UML 2, a tool should present both: concrete and abstract syntax compliance. Concrete syntax compliance, relates to whether users can continue to use a notation they are familiar with across different tools and have their communication easier, because the elements could have the same meaning across different tools. Abstract syntax compliance means that users can move models across different tools, even if they use different notations, what is essential when the language is used as a basis for model-driven development. The user might want to use tool A for creating the model, tool B for validating the model, tool C for somehow transforming/enhancing the model and tool D for generating code from it, this is only possible if all the tools are compliant to the UML 2 abstract syntax. OCL 2 support – The tool should be compliant with the OCL metamodel and to support constraints as well. Availability – The tool should be available for use, so if the tool A is proprietary and we have no license for its use it could not be used in the comparison. Industry acceptance – The tool had to be widely accepted by the software industry around the globe. By satisfying this constraint, the tool would be considered one of the most important tools in its application area.
Portability – The tool should be able to operate under different platforms, so its user would not be restricted to use tool under one specific environment. Multi user support – The tool should allow different users to shared and work on the same model. For comparison, the tool we found that met these constraints was the IBM Rational Software Modeler (RSM). The RSM could offer both, high and concrete syntax compliance to the UML 2 metamodel and support to OCL 2 expressions. Regarding its availability, we had academic licenses of this tool at UFPE, place where the case study would be executed, and the RSM tool has high industry acceptance as an UML and model driven CASE tool. The IBM RSM is also developed in Java technology what means that it can work in different operational systems and hardware platforms, and it enables multiple developers working with the same model through the use of an external version control system.
Once defined the experiment, its goals and the tool that was going to be used, we had to choose a KobrA2 model for the experiment. We decided to use a representative KobrA2 model, in terms of number of components, number of views and model applicability. The chosen model was the KobrA Web App Framework, which comprises 8 components with a total of 18 views and represents a real world model, being also part of this work (Section 3.2). The KWAF model was also consolidated, so the experiment participants wouldn’t have to take design choices, or to create the model from scratch. Instead, they would follow the existing model, and focus their attention only on the model creation.
To the user’s evaluation, we developed a survey, which would take in account aspects related to availability, performance, ease of use, diagram layout control and legibility and standard compliance, since these were our main goals to meet. These criteria and the survey coverage to them are explained bellow:
Availability – At the survey, the availability questions were related to time and ease of installation of the tool and the ease to setup one environment for multiple users collaborate in the same model. Performance – This criteria has been broken down into the survey in questions regarding startup time; upload and download time from and to a persistent medium; and resource consumption (RAM, CPU, network bandwidth).
- Distribution of the case study;
- Installation of the IBM RSM at the computers that don’t have it;
- Half of the participants model for 50 minutes using the IBM RSM, while the others model with the WAKAME tool also for 50 minutes;
- After 50 minutes, who were modeling with the IBM RSM starts to model with the WAKAME tool, while the other group would take the IBM RSM;
- After finishing the specified time the participants were surveyed about their experience in modeling with both tools (Appendix A).
5.2. Execution and Analysis of the Case Study
For the execution of the case study, a room was reserved for accomplishment of the presentation and to make possible that all the participants were in the same atmosphere to not suffer influences of different external factors.
Among the 26 members of the ORCAS research group invited to participate, only fourteen attended. The execution happened according to the planned stages, being: 30 minutes for the presentation of the KobrA2 method; 20 minutes for the presentation of the KWAF model; 40 minutes for the installation of the IBM RSM tool; and, 1 hour and 50 minutes for the accomplishment of the models by the participants (50 minutes in one tool, 10 minutes for interval, and 50 minutes in another tool). After these stages, all the participants answered the survey.
Among the participants, eight didn’t possess the tool RSM installed in their computers and they had to accomplish this installation. The IBM RSM application has approximately 1.2 GB of size in disk and after the installation it occupies 980 Mb approximately. The installation of RSM in the participants’ computers happened without problems, and it took on average 15 minutes each installation.
Now we will present the results obtained in the research. The Figure 5.1 displays a graph with the educational level of the case study participants. It can be observed that the educational level among the participants was diversified, tends, from undergraduate student to a person PhD. holder. Already the participants’ experience with the RSM and WAKAME tools can be seen in the Figure 5.2, where it can be observed that most never
used none of the both tools. However, we see a larger number of people that already had some contact with RSM than with WAKAME.
Figure 5.1 - Educational Level of Participants
Figure 5.2 - Familiarity of the Participants with the RSM and WAKAME tools. The first item verified in the case study was the percentage of the models accomplished in each tool by the participants in the given time (50 minutes). To calculate this measured, the weight of each view of the model used for the case study was defined through the amount of existent elements: ComponentClasses, Classes, Enumerations, Operations, Attributes, Parameters, Associations and Stereotypes (since the same is not generated automatically in RSM as it is in WAKAME). For the operational views, that are just textual for the OCL constraints writing, the weight ONE was defined. The Figure 5. exhibits the percentage of the model done in each tool, for each participant, where each line represents a participant (P1 to P14). The left side of the graph represents the percentage done in WAKAME and the right side the percentage done in RSM. The graph bellow exhibits the general average, of all the participants, of the percentage done in each tool. Observing these results, we can say that the time spent for modeling in RSM is approximately the double of the time spent in WAKAME.
Table 5.1 - Familiarity of Participants with the Tools RSM and WAKAME. How familiar are you with the Tool? WAKAME RSM P1 Used a few times Used a few times P2 Never used Used a few times P3 Never used Several months of self-taught use P4 Never used Never used P5 Never used Never used P6 Never used Never used P7 Never used Never used P8 Used a few times Used a few times P9 I am a trained expert Several months of self- taught use P10 I am a trained expert Several months of self- taught use P11 Never used Never used P12 Never used Never used P13 Never used Never used 1P4 Never used Never used The first criterion to be analyzed is Availability (Figure 5.4). It can be observed that the RSM tool had in larger part the answers Sub-par and Dismal for both questions done, while WAKAME had most of the answers Excellent. A possible reason for this fact is that RSM possess a relatively slow installation process and the same has a difficult download process. Another fact is that RSM doesn’t possess any preinstalled tool for aid in the teamwork development, being necessary the plug-in installation. On the other hand, the WAKAME tool, for being Web, is easily accessible and for its execution it is necessary just to download the necessary JARs file, which the browser automatically does. The size of these necessary files is of approximately 1.5 Mb, almost a thousand times minor than the RSM installation file.
Figure 5.4 –Availability Related Answers Comparison. In the criterion Performance (Figure 5.5), the first question refers to the necessary time to start the tool, for it to be ready for the use. In this point, in understanding of the
participants, the WAKAME tool had a better performance than the RSM tool, being most of the answers Good enough for WAKAME against Sub-par for RSM. In this case, the time spends of start-up of WAKAME is practically the time spend for the download of the necessary files, because, due to its reduced size, the download is fast. Yet RSM, for being a quite robust tool, and also for using the Eclipse’s platform its time of load to the memory is large, though it is not necessary to download any file.
Figure 5.5 - Performance Related Answers Comparison. The second question, of the Performance criterion, refers to the necessary time to load and to save a model in a persistent medium. The RSM had a better evaluation in relation to the other questions of this criterion. It occurs because the persistent medium used by RSM is the local disk of the computer, which possesses a fast access, but the processing necessary to do it still little costly. As the medium of persistence used by WAKAME is in the cloud, the result of this subject is directly tied to the user’s band width. In this case, as the case study was accomplished at CIn/UFPE, and it has a satisfactory access to the internet, WAKAME obtained a good result.
The last evaluated question of the Performance criterion was related to the consumption of computational resources. Again, WAKAME had the results between Good enough and Excellent , because its client component is light and it demands little processing
model. This occurred because if the chosen modeling template is not the most specific, some necessary modeling elements for KobrA2 are hidden.
The next question of the Ease of Use criterion has as objective to measure the usability in agreement with the amount of necessary clicks to include a new element in the model, or a new property of an existing element. In this case, WAKAME was evaluated, in the major part, as Excellent and, the RSM as Dismal. As dictated previously, WAKAME only makes available what is necessary for the view in subject, facilitating like this, the insertion of a new element. To add properties of an element, in WAKAME it happens through the inclusion of its concrete syntax, without the need to access the properties palette, as in RSM. In the question regarding the number of available features for the user, the evaluation was similar to the previous, this happened because of the same reason already explained before – WAKAME only exhibits the necessary and RSM, because of its general purpose, exhibits more information and options than the user usually needs.
The next three questions of the Ease of Use criterion refers to the navigation and the easiness to include items in diagrams. In the first one, that it is the navigation easiness, WAKAME had a good evaluation, in contrast with RSM. That is due to the fact of the navigation in WAKAME to be guided through component and the orthographically options of the views. Yet in RSM, depending on the nesting of the packages, to navigate through the diagrams becomes very complex. However, in the other two questions, regarding the inclusion of existent elements in different diagrams both tools had a similar result, where WAKAME was between Good enough and Excellent , and RSM among Dismal , Sub-par and Good enough.
The last question of Ease of Use refers to the speed for the creation of models. This question depends directly of the previous evaluations, because, a tool with a good usability usually possesses a good speed for development due to the learning curve, simplicity and intuition of its interface. Due to the simple and objective interface for the KobrA2 method, the time spent to model KobrA2 in WAKAME is much smaller than in RSM.
Figure 5.6 - Ease of Use Related Answers Comparison.
Another evaluated criterion was Diagram Layout Control and Legibility , where the result can be seen in the Figure 5.7. In the first two questions WAKAME had a good evaluation, because its interface allows easily manipulation of the size and position of the elements and mainly it allows total control above the disposition of the links in the model. Yet in RSM, its low rate in this criterion, pointed by the participants, is due because of its
