27.03.2014 Views

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Table 1. Candidate reverse engineering tools<br />

Tool Reason for elimination<br />

Amateras [2] Extracts class diagrams<br />

ArgoUML [3] Standalone<br />

ATL [4] Not specialized to UML<br />

BoUML [6] Not free<br />

Diver [8] Extracts sequence diagrams<br />

UML2 Incompatible with Eclipse Indigo<br />

Tools [31]<br />

Fujaba [11] Different interpretation<br />

Green Promising, but crashed<br />

UML [15]<br />

Open Model Standalone<br />

Sphere [20]<br />

Papyrus [21] Extracts class diagrams<br />

StarUML [26] Standalone<br />

Umbrello Not windows-based<br />

UML Modeller<br />

[30]<br />

Violet [32] Exemplar, no reverse engineering<br />

Preliminarily, we discovered many reverse engineering<br />

tools; some of these were created for educational<br />

purposes, while others were intended for a different audience.<br />

An examination of this set led to a short list<br />

of candidate reverse engineering tools, summarized in<br />

Table 1. Our further investigation eliminated most of<br />

these tools because they failed to meet one or more of<br />

the selection criteria, and these reasons are also summarized<br />

in the table. Violet represents a large class<br />

of tools that does not offer reverse engineering capabilities.<br />

BoUML had been free, but was no longer so<br />

when we actually experimented with it. ArgoUML and<br />

OpenSphere were standalone and not Eclipse plug-ins.<br />

StarUML used a different interpretation of reverse engineering<br />

from ours; it simply involved generating a<br />

message on to a sequence diagram by clicking on a<br />

method call. Fujaba’s documentation was out of date,<br />

and it had limited capabilities when integrated into<br />

Eclipse. ATL was not specialized for UML diagrams,<br />

rather it was a model transformation tool. UML2Tools<br />

was too old, and not compatible with Eclipse Indigo.<br />

Umbrello was eliminated because it was not Microsoft<br />

Windows-based. Finally, GreenUML appeared promising,<br />

however, it crashed with one of the course projects.<br />

Our exploration did not lead to a single Eclipse plugin<br />

that could extract both static class and dynamic<br />

sequence diagrams. Amateras was selected to extract<br />

class diagrams. Papyrus was an option to substitute<br />

for Amateras. The only free, Eclipse plug-in that actually<br />

extracted dynamic sequence diagrams was Diver.<br />

Diver’s documentation was decent and it had been runner<br />

up for an Eclipse community award, so it seemed<br />

more than adequate. It also worked in conjunction<br />

with all the course projects. All these tools integrated<br />

with Eclipse, and offered an added advantage of being<br />

intended for industrial use.<br />

4. Experiences and Reactions<br />

This section reports experiences and difficulties in<br />

using the chosen tools. It also summarizes the students’<br />

reactions as they experimented with these tools.<br />

4.1 Experiences and Difficulties<br />

In this section, we describe the challenges involved<br />

in set up, installation, and use of the tools. We also discuss<br />

the approaches taken to resolve these challenges.<br />

Integrated Development Environment We<br />

chose Eclipse as the IDE because of student familiarity,<br />

but the thought of mandating it had not occurred.<br />

Several student teams chose to use NetBeans instead<br />

of Eclipse. Thus, they used Eclipse to complete their<br />

assignments as the reverse engineering tools were<br />

reached through Eclipse, and ended up in using two<br />

different development environments.<br />

Configuration Management Tools The presemester<br />

setup of Git and EGit with Eclipse was complicated<br />

by the multiple components of the tool set.<br />

Data was conveyed easily across each individual interface,<br />

but representations of data to be entered on one<br />

end of the tool chain and consumed at an end farther<br />

away than the next immediate tool were not always<br />

easy to deduce. Installation of this tool chain had to<br />

be worked out through a combination of Internet search<br />

and extensive trial and error.<br />

Git and EGit provided the students with a seamless<br />

integration with Eclipse. Prepared keystroke/click by<br />

keystroke/click instructions showed them how to use<br />

it. Once again, the use of Git and Egit was not incentivized,<br />

i.e., no contribution to the final grade encouraged<br />

them to use these tools. Thus, the students chose<br />

whatever they found to be the easiest way to collaborate,<br />

which included emailing each other the project<br />

code, and storing it informally.<br />

Reverse Engineering Tools The first reverse engineering<br />

assignment was to extract static class diagrams<br />

using either Amateras or Papyrus. Using these tools<br />

was a simple matter of opening the project from the<br />

164

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!