/* Please excuse my own formatting, I've only just subscribed to the list.
Apologies for the length and concluding rant as well. */
In response to Vincent IBANEZ question:
The problem is that I have attributes of type String.
When I make my reverse, the attributes of type String don't appear
in my
class diagram. But there are association create with String Class.
Oliver Schoenhaar said:
The answer is partly about the philosophy of attributes :-)
The UML and many other design books suggest an attribute is
something
that has no intrinsic behaviour - in other words, it has none of its
own operations, it can only be operated on.
This means that primitives, fundamental types, POD (Plain Old Data)
types like struct and union can all be attributes, but classes (like
String) cannot or should not. In this case, structural features
involving items with intrinsic behaviour should be modelled as
relationships to classes instead.
I'm grappling with the same problem as Vincent. I get problems with things
like String and Vector but also with Swing classes for interfaces (e.g.
private JTabbedPanel fred;) and our own classes.
Looking back over the cafe rose and rose_forum archives, it is clear that
this problem has been aruond for a long time. It is quite surprising that a
more tolerant approach has not yet been provided by Rational.
I'd like to make two points...
First, I understand Olivers point, to a point (and this is NOT a dig at his
response).
Key to the development process (e.g. RUP) is the notion of perspective.
With a specification perspective, it could indeed be said that a reference
to a class member of another class type (e.g. private String fred;) should
be modelled as an association (composition) between the two concerned
classes. However, from an implementation perspective, as embodied in the
Java code, the relationship is realised as an attribute of type String.
As the whole point of reverse engineering is to recover implementation
design from code; _Rational's_ approach of not supporting class typed
attributes seems untenable. How else could I represent an association other
than as an attribute (at some point)? If the referenced class type is in my
classpath, or in the packages that I'm importing I'd expect Rose to pick it
up (even if the definition appears after the class currently benig parsed).
Second, the workaround of adding referenced classes to the Windows
_registry_ (for goodness sake!) is surely a joke (on Rationals part). If
the workaround has to be done like this, surely Rose should provide an
in-tool way of doing it (i.e. as part of the project spec or rev-eng
dialogue).
This utility seems to be so precious about how the code is written that it
really isn't a very useful at the moment. Rose can rev-eng .class files and
that those class files contain fully referenced class definitions
(java.lang.String) - to my mind this REALLY highlights the weakness of this
utility.
I'd say a very smiple benchmark should be:
"If the Java compiles clean then we can rev-eng it". OK so that process may
entail a two-phase creation of classes where an attribute of a user-defined
class type is encountered but has not been defined yet. Even better would
be the creation of appropriately stereotyped dependencies between model
components (i.e. com.morse.X <<imports>> java.lang.String).
/* I noticed a suggestion that if the required class is added to the class
diagram for the package that the 'to be rev-enged' class will go into then
the reverse engineering will work. I've just tried this and it didn't work
- still got a Cannot resolve symbol error. */
John
--
John Skelton
Technical Design Authority
Wireless
Morse Hughes Rae Ltd
Main +44 [0]1332 224515
Switchboard +44 [0]1332 826000 ext. 216
Fax
Mobile 07765 236252
Internet http://www.morse.com
This email and any attachments are confidential and are intended only for
the addressee. If you are not the intended recipient of this email and have
received it in error, please notify the sender immediately by reply email
and then delete it from your system.
<<John Skelton (E-mail).vcf>>
John Skelton (E-mail).vcf
