EA/UML newbie with .NET XMI import question

[fluxtah]

Hiya,

I used AssemblyMetaDatatoXMI converter tool to convert the .NET framework and import it into EA, one thing I was wondering is the way it imports properties,

it imports them  as methods with a get_ and set_ prefix.

I started to replace the get_/set_ methods with public attributes and set their stereotype to property.

I was wondering if this an ok thing to do as There seems to be no option to specify wether an attribute has a getter and setter, if you set the stereotype to property it implements both.

I understand you can check the property checkbox and it will implement a method with a get/set.

I guess I only want an exact model of the framework within EA, I don't need to forward engineer it so I suppose by deleting the imported get_ set_ methods and replacing with attributes of stereotype 'property' will have no bad side effects when using the framework model in my projects?

Another thing I noticed that it does it's best to maintain the generalizations between the classes, however it implements the methods and properties of the parent class... I am also deleting these and re-linking the generalizations that did not import correctly. I was wondering if this is also ok thing to do.

Here is a link to a screenshot of ea and the section I am working on in the System.CodeDom namespace, I have re-organized the import packages to have a package per namespace in a folder like heirarchy.


http://www.sunmoonsystems.com/eanet.gif

Whilst working through the classes I am copying the documentation from the framework sdk manual into their respective attributes/operations.

If anyone can point out anything I might run into or if I am doing this all wrong please help me now :]

regards

Fluxtah

[oliverson]

Hi.
I can't answer your question but I adopted the same approach as you using AssemblyMetaData2XMI.
However, while the Framework types were imported into the model, as evidenced by the log file, I can't see the non-public ones in Project View.  All i see is private types!!  Can you actually see the type System.Object for example?  I can't.
See my thread entitled
'Successful XMI import of types but can't see them'
This is hampering my ability to make progress so if anybody can resolve my issue as well, it would be greatly appreciated.
thanks

[fluxtah]

Hi Oliverson!

Just answered your post, I overcome this by basically checking all the boxes in the converter, I have tidied up the framework model a lot, would you like my eap file and maybe we can develop it into a nice working model?

So far I have re-organised the namespaces neatly into packages, when forward engineering c# code it is working wonderfully importing the correct namespaces, etc.

- Fluxtah

-------------------------------------
Just Discovered another thing, the conversion does'nt produce protected class members

[oliverson]

Thanks for your assistance fluxtah and for the offer of your EAP file.  My need is purely to get the types and methods of the Framework assemblies into my model so that I can reuse them in the model.  I have no plans to generate classes from them so I don't anticipate the need to clean up the resultant import (unless I'm missing something).  I'm going to have a go at it again just to satisfy myself that I can do it and hence, be able to recommend to others the correct process.  I do appreciate the offer though.
best of luck

[fluxtah]

Cool, thanks. I think I have found the answer to my problem now, it seems that you can't override/implement attributes of a parent class anyway so it would make sense to just use the property checkbox option and live with the fact that I will have an attribute and operation with the same name

This is actually great as far as my own classes go, I can have a private property ie: 'myProperty' and a public property 'MyProperty' with getters/setters, when it comes to fwd engineer, it works out great but as far as  a .NET framework model goes it makes the class attribute/operation list look long with all the doubles

[oliverson]

Fluxtah.
I checked the Private checkbox in the AssemblyMetadat2XMI tool and it did in fact produce the Public types that had been omitted in the previous generation.
I reported this strange behaviour to the tool author http://www.anticipatingminds.com and they promptly fixed the bug.  The latest version is available for download and  I can confirm it works.
A big thanks to you for discovering the bug and for Anticipating Minds for fixing it quickly and for producing a great tool in general.