|
|
Rank: Newbie
Joined: 12/22/2009
Posts: 8
Location: Canada
|
On reverse engineering UModel find all relations related to class variables members. That's perfect.
But, reverse engineering is not able to add relations between classes related by a C# (.Net) automatic property.
For example:
public class Apple
{
}
public class Basket
{
public Apple Apple { get; set; }
}
No relations are detected altought there is an existing one with the implicit hidden variable. Do you plan to correct the bug ?
|
|
Rank: Advanced Member
Joined: 9/28/2005
Posts: 371
Location: Vienna
|
Hi Eric!
Which kind of relation would you like to see?
Maybe you can attach a picture?
|
|
Rank: Newbie
Joined: 12/22/2009
Posts: 8
Location: Canada
|
I have no picture.
Automatic property are available in C# .Net since Visual Studio 2008. Automatic property are defined like that:
public class Basket
{
public Apple Apple { get; set; }
}
But in reality it is equal to
public class Basket
{
Apple _apple; // innaccessible from code... but we need to have it declared in UML model
public Apple Apple
{
get { return _apple; }
set { _apple = value; }
}
}
Regards,
Eric
|
|
Rank: Advanced Member
Joined: 7/17/2008
Posts: 185
Location: Minutiae, Triviality
|
These are what Objective-C calls "synthetic access methods". They do not exist until you compile the source code, which is when the compiler ... synthesizes ... them.
UModel would need to be made aware of this Magic.
So far as I know, getters and setters are the only two synthetics that most languages accept. Are there any others?
|
|
Rank: Advanced Member
Joined: 9/28/2005
Posts: 371
Location: Vienna
|
Hi!
As rip already said, UModel currently shows what you define in your source code and not what the compiler generates from it (otherwise you would not see templates too).
Back to my previous question: What would you like to see in the model?
An attribute "Apple _apple"?
A dependency to "Apple"?
....?
|
|
Rank: Newbie
Joined: 12/22/2009
Posts: 8
Location: Canada
|
You should do reverse engineering exactly as Visual Paradigm does it. They do it perfectly (it is their interface that is poor). I already own it.
You do the same bad reverse engineering as Sparx Enterprise Architect. That's the problem. They are not ready to improve then I will not buy it.
Please ask anybody who know Visual Studio 2008 "automatic property". You have no idea what I'm talking about. If you add a imple idea of what it is then you would agree. You add relation for property, you should add them also for automatic propery.
// Example. Fine with all 3 products (Sparx, V Paradigm, Umodel)
[XmlElement("Target")]
public EmtpDevice DestDevice;
// Ok only for Visual Paradigm
[XmlArray]
[XmlArrayItem("Dev")]
public List<EmtpDevice> Devices { get; set; }
Now ! If you don't understand that it is because you are dumb !!! (And I will not explain 10 times)
you have a very nice (very very nice) product but the reverse engineering as a problem with c# 2008. You should fix it. And by the way. When it will be fix, can you extend my evaluation period ? You have to correct that very fast because there is a lot of chances that Visual Studio 2010 will probably come out with UML designer in it. I will probably buy your product if you fix that before Visual Studio 2010 release candidate come out with reverse engineering (if any is available at that time.. beta 2 doesn't).
Hope I wake some light somewhere because your products are very nice... Then there should be anybody who should understand what I'm talking about at your location, please ask !!!
Eric Ouellet attached the following image(s):
|
|
Rank: Advanced Member
Joined: 9/28/2005
Posts: 371
Location: Vienna
|
Hello Eric,
UModel does not differentiate between “automatic properties” and “normal” properties – all are reverse engineered.
If you import your source code into UModel, your “Variation” class will look similar to those of your picture and you will also see your “Devices” property (e.g. as attached below).
One difference is that UModel imports C# properties as operations whereas your screenshot shows them as attributes (although they can also have method bodies, you can generate sequence diagrams from them,...)
Another difference is that in your picture the information about a property having getter and/or setter and the attribute sections seem to be missing!?
cor attached the following image(s):
|
|
Rank: Newbie
Joined: 12/22/2009
Posts: 8
Location: Canada
|
... RRRRRRRRRRR
Ok... This is 3 classes and the reverse engineered UModel UML Class diagram.
PLEASE NOTE, That Class 2 and Class3 should be considered identical. They are identical in functionnality.
As you can see in the reverse engineered model, there is missing a relation between Class1 and Class2 !!!
Instead of just cut and pasted code, I snagit to show you that "resharper" want me to transform the property in Class3 (green underline) to an automatic property. Resharoer is a tool that help us to code better code. Resharper tell us the truth. You can "not believe me" but you have to believe "resharper"... Now, do you admit that those portion of code are equivalent ??? I hope ! If not tell me and we will stop right now.
If you admit that code in Class2 and Class3 are equivalent. Then anybody should expect the same result as relations to Class1 from a reverse engineering pass. And the problem is that is not the case because you have a bug. Yes !!! You have a bug. Also... Visual Paradigm does reverse engineered the code properly.
Now... for all of my hours of explanation, can I have the fixed product (when available) for free ??? You should pay people who help improve your product.
Another thing. Fix that quick. The majority of people that try a product and see a bug just throw away that product. It is flower I give you to take the time to improve your product with a real hard time... (and few hours lost)
"Thanks" !!! or "Regards" !!! (as you wish)
Eric Ouellet attached the following image(s):
|
|
Rank: Advanced Member
Joined: 9/28/2005
Posts: 371
Location: Vienna
|
Hi!
You (would like to) consider them identical but as written above we must rely on the source code and that isn’t (btw: also a reflection/binary import of the compiled classes will show them different!).
Anyway – it seems to turn out that all you miss is a “line” (to say it in non-UML words) between Class2 and Class1 showing that the first one depends on the second one.
If so, I can add this to our feature list!?
|
|
Rank: Newbie
Joined: 12/22/2009
Posts: 8
Location: Canada
|
It is fine if you don't want to threat that as a bug but I let you that info to make sure nobody could think i'm wrong in this.
I suggest to use Red Gate's .Net reflector (free).
You can see the autogenerated field for automatic property.
Eric Ouellet attached the following image(s):
|
|
Rank: Newbie
Joined: 6/17/2011
Posts: 5
Location: Switzerland
|
Hello Eric.
I have the same problem with .NET properties and their (not shown) associations.
Today I have installed the newest version of UModel but it seems to be not fixed yet.
Do you know any workaround?
Thanks.
Björn
|
|
Rank: Newbie
Joined: 6/22/2011
Posts: 1
|
why don't you simply use a field instead of an automatic property?
|
|
Rank: Newbie
Joined: 4/8/2011
Posts: 5
|
It is *extremely* disappointing that .NET automatic properties are not supported in UModel. It is also very disappointing that responses from Altova developers show that they just don't get it.
It's very simple.
This...
Code: public class MyClass
{
public string MyProperty { get; set; }
}
...is SOOOO much cleaner than this...
Code: public class MyClass
{
private string m_MyProperty;
public string MyProperty
{
get { return m_MyProperty; }
set { m_myProperty = value; }
}
}
...and that's just ONE property. Imagine a class with five properties.
Code: public class MyClass
{
public string MyProperty1 { get; set; }
public string MyProperty2 { get; set; }
public string MyProperty3 { get; set; }
public string MyProperty4 { get; set; }
public string MyProperty5 { get; set; }
}
I will let you imagine what the long version of this code looks like. So what part of "automatic properties are very cool and heavily used by .NET developers" do you not understand?
[This answers "softwaredevelopers" question: why don't you simply use a field instead of an automatic property? You must be a "javasoftwaredeveloper" if you don't know the answer already.]
Using UModel, we suffer the fact that the automatic properties are not reverse-engineered properly so that the associations are not generated per Eric's explanation. To make matters worse, we cannot forward-engineer automatic properties using UModel either. Frustrating!
If I create a class in UModel first and then generate the code from the model, UModel will produce this:
Code: public class MyClass
{
public string MyProperty
{
get { }
set { }
}
}
And why the heck does it matter what the compiler does??? Who cares? So it makes a private variable for you under the hood. So what? What does that have to do with reverse or forward engineering code from the model?
Why oh why can you not produce this?
Code: public class MyClass
{
public string MyProperty { get; set; }
}
In the case of forward-engineering...how about if you add a stereotype like <<automatic>> to the list of properties for an Operation??? Then if it is checked you can produce the desired automatic .Net property? Or, maybe you can add "automatic" as a checkbox under the <<GetAccessor>> and <<SetAccessor>> stereotypes for an Operation just like the "visibility" is shown under them? Then if that is checked it can produce the desired automatic property?
When reverse-engineering, why can't you just check the body of the "operation" for "get {...}" and/or "set {...}" to determine that it is a "property" and look at the return type to produce the desired association to solve Eric's complaint?
It is extremely disappointing that this is not supported especially since I see that
1. Somebody complained about it two years ago and
2. Competing products produce automatic .NET properties just fine.
What gives? Get it together Altova.
|
|
Rank: Newbie
Joined: 4/8/2011
Posts: 5
|
To further elaborate on the field vs. property question, .NET properties are displayed differently in Visual Studio's intellisense and object explorer. Also, if you start off with an automatic property, it is easier to switch later on to a more elaborate implementation. For example, suppose you want to make a property support lazy-loading later on. It is easier to refactor that code than it is a public field. Finally, maybe it's just a matter of *taste* to use automatic properties as opposed to public variables. If I like properties better than variables, why should I be forced to code the way someone else likes? Bottom line is that given the robustness of UModel, it is surprising and disappointing to see that this isn't supported when so many .Net developers use automatic properties.
|
|
Rank: Advanced Member
Joined: 12/13/2005
Posts: 2,856
Location: Mauritius
|
Ok, it is "extremely disappointing", "very disappointing", "surprising and disappointing". We all got this. I think Altova, like any other software company in the world, would love to implement all feature requests, but has to deal with them step by step. Just look at the https://www.altova.com/umodel/new-features.html list - every major and minor UModel release has added tons of new things, and every of them made somebody happy.
P.S. why is everybody coming here to complain only. Why not sometimes say "thank you", for example, for UModel "robustness"
|
|
Rank: Advanced Member
Joined: 9/28/2005
Posts: 371
Location: Vienna
|
FYI: UModel 2013 introduced the possibility to show .NET properties as associations (also see https://www.altova.com/umodel/new-features.html#UModel2013)
|
|
|
guest |
