Hello François,

a) Run the java reverse in batch mode. At this time, this is not done.
Perhaps it could be done further.
b) Have the private stuff included in the java reverse. May be during your
tests you have let the visibility to public. In fact, the reverse tool
filters the elements it reverses and considers the "Public" visibility as
default. If you select "Private" as visibility, you will go down to the
"Private" elements rather than reverse only the public ones. Visibilities
are considered, here, as a hierarchy where Private is the weakest (down) and
Public the strongest (up) :
always visible : Public
then Package
then Protected
then Private.

If you select "Public" you will see the elements "Public".
If you select "Package" you will see the elements "Public" and "Package".
If you select "Protected" you will see the elements "Public" and "Package"
and "Protected".
Indicating Private let you consider all elements with any visibility.


Next version will include a property page that allows to select if we need :
-imports,
-package dependencies
This is already on the Head of the CVS.

Regards
Christophe

-----Message d'origine-----
De : [email protected]
[mailto:[email protected]]de la part de Topcased
user list where issues are discussed
Envoyé : jeudi 9 décembre 2010 17:29
À : [email protected];
[email protected]
Objet : Re: [Topcased-users] TPC Java Reverse tool +
Generationtools...Auto,RT, ... Some Advice requested


Hello,
Thanks for these enhancements.

As far as we are concerned, what would be nice from that is (note: it might
be possible already, but I didn't find how to do):

a) Run the java reverse in batch mode.
We would like to run the reverse (and associated reports) on a "continuous
integration" basis.

b) Have the private stuff included in the java reverse.
We check the naming of java components like classes, interfaces, enums and
attributes. But as our attributes are private we don't have them in the
reverse.

Regards
François


-----Message d'origine-----
De : Topcased user list where issues are discussed
[mailto:[email protected]]
Envoyé : mardi 30 novembre 2010 15:57
À : [email protected];
[email protected]
Objet : Re: [Topcased-users] TPC Java Reverse tool + Generationtools...Auto,
RT, ... Some Advice requested

Hello François,

Some words to tell you that enhancements discussed in this list have been
included in the Java to UML tool of Topcased 4.2.0.
Don't hesitate to report a bug if there is, or to tell which enhancements
you imagine from this new basis.

Regards
Christophe & Ludovic

Here is the list of improvements :
* types management refactoring : types are resolved at their location
avoiding local and multiple datatype creations

* interfaces implementations enhancement : interface realization type
resolution

* classifiers imports : package/element import from Java imports

* "usage" dependencies at package level : usage dependencies between
packages deduced from classifiers imports.

* port, part and reception reverse : port, part and reception recognition
from Java annotation

* partial reverse improvement: merge enhancement of reversed model into the
target one,

* method code reverse: method creation for each reversed operation. Body of
method reversed as opaque behaviour.



-----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 11:31
À : [email protected];
[email protected]
Objet : Re: [Topcased-users] TPC Java Reverse tool + Generation
tools...Auto, RT, ... Some Advice requested


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




_______________________________________________
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

Reply via email to