"do not reinvent the wheel" – this is one of the strongest rules of Software Engineering! Following the rule, I must select the first option to move the work forward more effectively. The next step is to look at the already existing implementations and start from there.
- The java programming language reverse engineering implementation, made in the context of the main Argo's project – argouml/src_new/org/argouml/uml/reveng/java.
- The classfiles and JAR file import reverse engineering implementation, which exists as an Argo's module argouml/modules/java_rte.
The cookbook is very scarce about how to implement reverse engineering for ArgoUML. The only statement is that the reverse engineering is located in
org.argouml.uml.reveng. From a simple analysis in the java reveng implementation (in
org.argouml.uml.reveng.java), it seams you must implement the
org.argouml.application.api.PluggableImport interface. ArgoUML
reveng provides the
FileImportSupport class to be used as a base for languages based on source code stored in files. For java the class is
JavaImport. The parsing is done by ANTLR generated classes (
JavaRecognizer), being the model populated by the
Picture 1 – Class diagram of ArgoUML's class hierarchy for reverse engineering.
argouml/modules/java_rte wasn't the other module where reveng was available [check my extended note on this]! The Classfile module (
argouml/modules/classfile) was the one, with the class
org.argouml.uml.reveng.classfile.ClassfileImport being an implementation of
PluggableImport. Since the classfile import supports java reverse engineering also, the
Modeller from java source files reveng is reused in this module.
One thing that I still don't know well about the rev eng modules is the generation of the parser classes from the ANTLR grammar. I must check how those classes are being generated, which files are used and if the ANTLR version contained in the ArgoUML CVS contains a grammar for C++.
The main Ant target for generating code is
generateparser. It uses two sub-targets, that actually do the work, one –
generateparser1 – for generating parser classes for
rev eng and another –
generateparser2 for generating parser classes for the
generator. The actual Ant tasks are the execution of
antlr.Tool class with the command line syntax:
java antlr.Tool -o <output_path> <grammar>
Picture 2 – Java generator and reveng ANTLR parser classes generation from grammar.
The ANTLR C++ grammar doesn't exist in the CVS source and the one that exists in the ANTLR site is for integration in C++ programs... I have to look deeper on this... Maybe I'll have to port the grammar to java.
Interesting... I'm working in a modeling tool, but, to make the analysis of the possible solution I started from the correct place, re-checking if the above shown implementations were really the only existing "official or open sourced" implementations of reverse engineering for the ArgoUML project. So I looked for the sources in Eclipse...
I already had sure that Java reveng is supported. It lives within the Argo project. Java classfile reveng I had sure, but, not about the
java_rte module, that has only the package
org.argouml.language.java.ui which isn't certainly for reveng, but, for something UI related. So I looked for alternative modules and the most obvious was
This analysis went from the top of the module's package to the implementation. I had to make several mouse clicks and only at the end – specific implementation package – I selected the correct class. If I had a proper modeling tool and a proper Argo's project model, I should have gone there and read the module description (which would be accessible from the modules diagram) instead of going to the Argo's project in my IDE. So, is there some Argo project model, kept uptodate as the cookbook so that interested contributors could look for software engineering information?
I looked for one and... Nothing in the cookbook, nothing in the developer's zone, and nothing in the developer's list. No shareable and reused model or group of models' of the ArgoUML modeling tool, officially maintained by the project members and existing in the CVS!!! This should be fix and ASAP! So I sent a proposal to the dev list.
(...) Some time went by and I didn't received any answer. I tried with 0.17.2 version, saving the file in text format, but, for a partial rev eng of Argo, the file was about 8 MB! Sure thing this isn't usable for sharing files in CVS... The only way is to have several models, based in the compressed format for each specific section. I'm going to take the lead by adding a development model for the C++ module in the