Reverse Engineering Java

[effjay]

Hi,

first I want to say that I really like working with the Enterprise Architect. It does what it should most of the times and responds much more quickly than for example Together (klick...wait...).

But what I don't like is that some parts don't seem to be fully implemented. I am now speaking of the Roundtrip-Functionality. I have read in one article here that Collections cannot be reverse engineered, meaning that the produced diagram will not contain the 0..* links between the entities. But why? The Collection interfaces are a well known construct and any use of Set or List or Collection interfaces should create the links, I don't see why this should be missing. (With generics, the type of the linked entity is known, making this possible. If no generics are used, javadoc type information should be used to infer the linked entity.) You cannot do Roundtrip Engineering properly, if you cannot reverse engineer these constructs.

So thats that. Another annoying thing is, that obviously properties aren't reverse engineered  the way they should. If I have a field foo plus a method setFoo(Foo f) and a method getFoo(): Foo, then I expect EA to correctly recognize a property and show it respectively. Now it doesn't, it recognizes all three things (variable, getter and setter) as single variables and single methods. Then I have to manually go and correct all diagrams (and those can be quite numerous).

I know that it is possible to correctly reverse engineer Java. Do it then, please. And while you are at it, please recognize the use of Generics (for Collections, see above) and Annotations (could maybe map to stereotypes).

Another property thing: if I define an attribute by hand using EAs property wizard, then I can define that the attribute is a property. Why are the default getter and setter names in lower case? Like setfoo? It should be setFoo and getFoo. Definitely.

I hope you don't hate me now, but I get annoyed when stuff doesn't work :-).

Plus: you could improve the usage experience, if you would introduce a "re-layout diagram" button in the toolbar. Just copy the behaviour of Together, thats perfect.

Enough criticism for today :-).

I'll buy another year of EA updates, as soon as the reverse engineering/code generation is perfect. I hope this to be of some motivation ;-).

Best regards
Daniel

[thomaskilian]

Have you searched for "roundtrip" in this forum. Maybe you can join some threads?

[Eve]

I'll start with properties.

Look at Tools | Options | Source Code Engineering | Capitalized Attribute Name for Properties.   It's used for both generating properties and for identifying properties when reverse engineering.  There are also options for the get/set prefixes in the Java options.  Set all these options appropriately and properties will work as you expect.

EA does currently have a Layout diagram toolbar button.  You'll find it in the diagram toolbar, diagram menu and the help file.  You'll even find it in the automation interface with an enumeration for how you want it laid out.  You can also select a subset of the classes in a diagram and lay those out without touching the others.

It's true that EA doesn't reverse 0..* assocations from code. EA isn't just Java, and doesn't look for Java specific types, although handling generics is planned.  Although you would probably need appropriate collection classes set up in EA.  While we're at it.  Search the EA help file for collection classes before you complain that EA doesn't generate 0..* assocations properly.

I hope that helps, even if it's not all "perfect".

[sargasso]

Let's get one or two personal opinions out here.  

1. Neither EA nor any other modelling tool in the known universe can or will perform this so-called "round tripping" miracle for source code.

2. A very clever man in these forums stated once something along the lines that models have a richer semantic content than realized code can ever have.  Ergo, in order to reverse engineer code into such semantically rich modelling concepts such as role multiplicity on association ends - if such ends do exist in the model in the first place - the tool would have to infer the mind of the code as well as the mind of the modeller.  Otherwise every possible semantic construct would have to be considered and placed in the model.
Consider class X with an attribute Y of type Z.  If reverse engineering did presume to know the mind of the modeller it would have to produce:

• An association, source X target Z with a target end role of "Y".
  
• A dependency of X on Z.
  
• A realization of Z by X
  
• At least one aggregation of Z into X with a target end multiplicity of 1..1  (and lets not get into the argument of whether the aggregation is composite or not.
  
• etc
  

3. Houses cannot draw blueprints, nor can they dictate building contracts.  Why then should code be able to prescribe its model?

...and a question

What is a 1..* association in code look like anyway?
For C#,  private int[] x; generates a correct looking attribute in EA but is a meaningless concept until x = new int[100]; or the like is executed.

bruce

[Paolo F Cantoni]

I don't know who the clever man was, but I said:

I've already indicated that one of the problems (perhaps the fundamental) problem with Round-Trip-Code-engineering is that there are more syntaxes available in the model than in the programming languages.  Thus although we can go from model semantics to the equivalent code semantics, we can't necessarily go in the reverse direction.

I thought I'd add a clarification in the light of recent advances in EA and other modelling programs' integration with IDEs and compilers.  

The original assertion was directed at pure code text.  The tighter integration now allows significantly more metadata to be passed in both directions.  Thus although I stand by my fundamental premise (and I love bruce's:  "Houses cannot draw blueprints, nor can they dictate building contracts)", I do believe that we may be able to provide more feedback to the modeller from the coder than previously.

In my instrumentation pattern, I have two concepts:
Anomaly and Intervention.  In considering the relationship between the code and the model, I believe these two concepts would be useful.  If the interface detects a code change which would invalidate the model, it would mark the appropriate elements as anomalous.  If the code had new elements, which did not appear in the model, the interface would mark them as interventions.

In both cases, an agent on the modelling side (whether human or automatic) would determine what the correct model should be.

Clarifyingly,
Paolo

[effjay]

I see now, that my mail was in parts wrong and in parts seems exaggerated.

Also, thanks for the support. I did not find that case name property button, even though I did look for it. Sometimes I seem to be blind. Thanks for pointing that out! The same for the diagram layout button. Why ever I have not seen that one.

Regarding the collection reverse engineering: yes, there is more semantic knowledge in the model than within the code, and there will always be. And I don't expect EA to magically invent details that are not expressed by source code. But: there is still knowledge within the sources that is not reverse engineered (or maybe I haven't found the necessary buttons, yet, this seems to be a possible cause). These are generics and annotations.

I like the idea of recognizing javadoc properties or/and annotations, to allow as much meta data in the sources as possible.

I hope I didn't say, that EA doesn't properly generate Collections, because it does indeed.

Regards,
Daniel

[Eve]

I forgot in my previous post to say that annotations are added as tagged values.  This and more can be found in the EA help http://www.sparxsystems.com/EAUserGuide/index.html?java_conventions.htm.

It doesn't say anything about generics there, but this page describes handline of parameterized classeshttp://www.sparxsystems.com.au/EAUserGuide/index.html?parameterisedclassestemplate.htm and if you do a search for generics in this forum you'll find some more detailed answers.  For java the type restrictions are put in the class parameter type field.

EA imports fields from javadoc comments into relevant fields in the model where possible.  Any that there is no corresponding field in the model, or EA doesn't know about are kept in the notes.

Oh, and you didn't say anything about Collections not generating... That's just one of the things I get a lot from people who haven't read the help, so I just thought I'd make sure it was pointed out before it became an issue.