Much time went by without any news noted here. I've been working in the reverse engineering, having added a new translation unit (
DerivedFromAbstract.cxx) that has more constructs to be reverse engineered to UML.
While at it, I've followed the work in the MDR implementation of the Model sub-system of ArgoUML. The developer who is more actively contributing is Ludo (Ludovic Maitre), who, among other things, proposed a GUI extensions model to enable ArgoUML to work with several UML versions. This is very interesting, as it would make ArgoUML more flexible, customizable and modular. The proposed approach to do it is documented in his post. I have sent a different proposal, MDA based, which I think would fit better to ArgoUML (see my post here).
These days ArgoUML development is more active than usual, with work progressing in several fronts. I hope that the interoperability provided by a MDR based implementation of the Model sub-system will attract even more newcomers and previous developers so that this community is boosted to a higher level!
That said, I must complete the
TestCppImport.testParseFileDerivedFromAbstract() test case to start working with Daniele in a common UML profile for C++ that will be used in the module. Maybe if this is developed outside of the ArgoUML project, it might provide a great opportunity for experimentation - Maven instead of Ant - and for reuse outside of ArgoUML. The definition of this profile and its use in both the
GeneratorCpp and the
CppImport is very important for the documentation of the C++ module in the cookbook. It could be described as "the C++ generator uses the conventions defined in the UML profile for C++ for generating C++ specific constructs, such as pointers and references".
I delivered yesterday the first version that actualy includes reverse engineering. It reverses the
SimpleClass.cpp file which is in the
argouml/modules/cpp/tests/org/argouml/language/cpp/reveng directory. Sure, it is just a very limited part (even less than the tip of the iceberg), but, it shows that the reverse engineering work is progressing and that the full concept works! So, now I must re-plan, introducing what I already know about the future work. This is an update to the previous version of the plan.
Learn how to make the ANTLR parser for debugging and build one.
Estimated Effort (EE) = 4 Mh; Short Name (SN) – ANTLR parser 4 debugging
2005-02-25 DONE – Although not actually a fully debug enabled parser, but, using the trace capabilities of the ANTLR generator. Note that this makes the parsing much slower and is only usable with small files!
Actual Effort (AE) = 2:36
Debug the C++ grammar and make it pass the tests.
EE = 20 Mh (see bellow); SN – Fix the C++ grammar
2005-03-07 PARTIAL – It parses cleanly a simple class and a code snippet with which I was attempting to reproduce the current error in parsing of
AE = 2:51
2005-05-13 PARTIAL – I've postponed fixing the parsing of
quadratic.i, since it seams to be complex to solve. Instead, I've started to fix the grammar in order to provide the parsed information to the
Modeler. The test case
TestCppGrammar.testGrammarCallbacks2Modeler()shows the partial fix. This problem makes the effort estimation for this to change in a dramatic way, since it introduces a huge amount of work that must be done.
New EE = 140 Mh
AE = 15:54 Mh
Commit the result of this work and send it to Yolanda. Update the issue.
EE 3 Mh; SN – Commit, Yolanda and issue
2005-03-09 DONE – I committed the work in progress and updated the issue. Due to the release of a stable version of ArgoUML the work was committed in branch
cpp_reveng_work_while_0_18_release. I only sent to Yolanda an e-mail of thanks. I'll send her the version that will be sent to the ANTLR list.
AE = 1:36
2nd re-planning of C++ reveng drop 1
EE 2 Mh; SN – 2nd re-planning of C++ reveng drop 1
2005-03-12 DONE – Re-planned and updated the ProcessDashboard phases.
AE = 1:39
Update the model to reflect the new package and the grammar use.
EE = 2 Mh; SN –Module model update for the C++ grammar
2005-03-16 DONE – Updated and committed.
AE = 2:14
Make tests that show how the parsed information may be used for reveng. If some issue exist, analyze how it is done in java reveng and fix the grammar as needed. This includes creating, or improving the current, test cases, which prove how the parsed information may be used for reveng.
EE 5 Mh; SN – Prove that parsed information is useful for reveng
2005-03-18 DONE – a big issue exists, as documented in the above step.
AE = 1:47 Mh
Planning of C++ reveng drop 1. This task includes all the subsequent plan updates of drop 1, instead of having the planning tasks spread throughout the plan. I estimate I'll have 3 more plan updates, including the final, in the end of drop 1.
EE 6:00 Mh; SN – Planning of C++ reveng drop 1
2005-05-13 PARTIAL – 4th version (3rd update) of the plan.
AE = 1:25
2005-07-03 PARTIAL – 4th update of the plan (5th version).
AE = 3:15
Model the implementation of
org.argouml.application.api.PluggableImportinterface in the C++ reveng module. Generate the realization of the designed classes. If there are issues in the generation, report them in issuezilla.
EE 5 Mh; SN – Model and generate the realization of the
2005-05-20 PARTIAL – the model contains this and ArgoUML was used to generate the implementation skeleton. I found issues in the generation, but, didn't report them, so, this isn't finished.
AE = 3:22
Close the circle, by making the module support reveng of preprocessed C++ files.
EE 15 Mh; SN – Module support of reveng of preprocessed C++
2005-07-02 DONE – The module now reverses the
argouml/modules/cpp/tests/org/argouml/language/cpp/reveng/SimpleClass.cppfile. I consider this a proof that the circle is closed. The work is far from finished though, so, we need to add more steps, related to what I learned while making this part of the work...
AE = 9:45
A warning popup box must be shown to the user, warning him about the limitations of the C++ reveng module. This happens when the user selects C++ in the drop down box of the "Import Sources..." dialog. (If this turns out to be difficult, the popup may be shown just before doing the import, when the
CppImport.parseFile(xxx)method is called.) It provides an option for the warning to be shut down forever. Even if the user doesn't select it, the CppImport instance will remember that the warning was shown and will not repeat it as long as it "lives".The warning should be self explainable, but, may also direct the user to the manual section that describes the C++ modules functionality (see bellow related issue).
EE 6 Mh; SN – Warning pop-up about the C++ reveng limitations
Extend the C++ translation unit files used in the tests to contain a representative C++ sub-set. These files must contain a basic subset of C++ that is the one used by a person the learning C++. They aren't fancy examples of the powerful language C++ is! All should be compilable with gcc > 2.9x and VC++ 6. All are translation units.
EE 8 Mh; SN – Extend C++ translation unit test files
Support clean reveng of the test C++ translation units. This will obviously be the driver task that will require the UML profile for C++ and the Fix the C++ Grammar steps to move forward. I'll consider that as soon as this is finished, the other two will also. This step is dependent of the template support in ArgoUML issue.
EE 30 Mh; SN – Support reveng of test C++ translation units
Develop a UML profile for C++. It should be as much as needed, but, contains everything that is needed to model the elements that are contained in the C++ subset that will mark the capabilities of the module (see above). [Check my note above regarding this step.]
EE 20 Mh; SN – Develop a UML profile for C++
Send a working vanilla version of the grammar to the ANTLR list and announce its use within the ArgoUML project. Provide feedback as appropriate. Automate the adaption of the files in the module build script.
EE 5 Mh; SN – Send grammar 2 ANTLR list
Enjoy and celebrate the achievement! Go back to planning next drops.
EE 4 Mh; SN – Plan next drops
Some of the above steps depend of two of the following issues. These, obviously must be tackled on their own.
- make available to users the module documentation (issue #2857) – I'll use this to also document a bit the reveng part. This will be a great exercise, since it defines the functional requirements of the C++ reveng module.
- Create a section in the cookbook about the C++ module. [TODO: create the issue!] (issue #????) – This should be done at the same time that I'll work in the manual. I'll contribute also to the modules part.
- Lack of support for Parameterized Class (Template) (issue #1446) –