Preserving Stereotypes when reverse-engineering

[julian]

Hi all,

I'm doing some analysis on a mid-sized (1800 class) project and finding stereotypes a fantastic way of classifying classes -- tags might work just as well but the colourisation is what I find most beneficial -- I've considered Coad's UML in Colour and decided that a simpler method of stereotyping 'business' / 'presentation' / 'data' etc to be most useful for me right now.

In any case, when I sync from a fresh build all the diagrams are preserved (yay!) but the stereotypes are discarded -- is there any way of preserving stereotypes? I know the real answer is to forward-engineer back to the code base but that would involve changes to a huge number of classes which at this stage I don't see as necessary.

thanks in advance for any perspectives,
Julian

[dserodio]

Nice question, I'd like to hear the answer too.

I case this functionality isn't implemented: I don't know about other languages, but for Java it could be a matter of a @stereotype Javadoc tag.

[Eve]

This is a common problem that is integral to the reverse engineering process.  The model may have more information in it than the code.

There currently isn't any way to stop EA from discarding the stereotype found in the model when reverse synchronising.  I can easily think of cases when an empty stereotype in code should override a non-empty stereotype in the model.  (Eg. Started with a struct and decided that it needed to be a full class.)

The problem is that reverse engineering does effect the stereotype.  Eg, setting the struct or enumeration stereotype.

A javadoc tag wouldn't import as a stereotype because the javadoc parser doesn't know to look for it.

Ultimately, if you want to have information in the model that isn't imported when reverse synchronising (and you want to reverse synchronise) that information has to go somewhere that it will be left alone by the reverse engineering process.

Simon

[julian]

Thanks Simon -- but how about a simple option for stereotypes and other such things:

Override precedence:
[ ] model takes precedence over code

?

regards,
Julian

[dserodio]

I mentioned the Javadoc tag as a least-intrusive way to put this information in the code.

Can we expect this functionality to be implemented?

[cnahr]

Or how about using the .NET attributes for this purpose when reverse-engineering .NET code?

As I said in another thread, I'm concerned with controlling operation visibility in r-e'd code. I just discovered that EA can r-e .NET attributes just fine. I could simply create a "HideInDiagram" custom attribute, and label my methods accordingly in the code.

Unfortunately, EA handles attributes as tagged values, and there's no way to control diagram visibility with tagged values...

But I also would be happy with a very simple reverse-engineering option: "Keep custom stereotypes (y/n)". Or with a simple list of names to show/hide class members in diagrams.

Simon, could you please tell us whether you intend to do anything about this issue -- manual control of the reverse-engineering process?  It's really important for those of us who use EA to document code, as opposed to creating it.

[cnahr]

I guess the silence means "no"...

[Eve]

No... The silence really means that the thread slipped my notice.

In the short term there isn't anything that I can do about it though.

Simon