Hello, Thank you François for that use case that justifies the implementation of this feature.
If anyone has another use case on this topic, don't hesitate to write it in this list. Thanks. Regards Christophe -----Message d'origine----- De : [email protected] [mailto:[email protected]]de la part de Topcased user list where issues are discussed Envoyé : vendredi 15 octobre 2010 08:33 À : [email protected] Objet : Re: [Topcased-users] TPC Java Reverse tool + Generation tools ...Auto, RT, ... Some Advice requested Hi, Great ideas : all the points are needed, from my viewpoint. As far as point 3 is concerned, we would use this function to fulfill our Quality Assurance reviews. Actually, when dealing with analysis, conception or design, we define the packaging of the system, i.e. what the packages should be and what are their allowed dependencies. We do that in a UML model (using Topcased) by creating the packages and adding package imports between them. Then, we need some way to check that the Java code complies to these dependencies rules. One way would be to use the below point 3 functionality, i.e. reverse the Java code in a "development" UML model, and compare it to our design UML model. For that use case, graphical representation and code generation are not the main concern. Regards. François Fromageot -----Message d'origine----- De : Topcased user list where issues are discussed [mailto:[email protected]] Envoyé : vendredi 8 octobre 2010 12:51 À : [email protected] Objet : [Topcased-users] TPC Java Reverse tool + Generation tools ... Auto,RT, ... Some Advice requested Hello, The Topcased Java reverse tool allows to reverse java code to build an UML model. We are currently in progress to add some functionnalities to this reverse : 1- the types imported from outer packages will be created relatively to their tree in the model and not in the parent package of the class that need this type with a name indicating the full path of the element ex : if a class A imports the B.C.D type then the D type will not be created in the context of the A Class parent package with "B.C.D" name but the D type will be created in a C package nested in a B package assuming that B & C are packages; 2- we probably add the implementations of interfaces for classifiers; 3- we probably add the imports for each classes using "import element" or "import Package". If the 1 & 2 actions are needed the third one is not so clear, Eclipse may provide the right imports using CTRL+Shift+O and in this case why make the model heavier. At the opposite, no one can make diagrams with this notion. We need to know if someone has an advice on this third point, specially concerning : - graphical representation (may be ... not very important ? ) - code generation from the modified model. Regards Christophe _______________________________________________ Topcased-users mailing list [email protected] http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users _______________________________________________ Topcased-users mailing list [email protected] http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
