Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Jeff Odell on May 14, 2004, 06:54:25 am
-
Is there any way to reverse engineer C# in such a way to have the properties end up in the UML attribute section? Or is the property attribute on an operation considered the "proper" and best way to map C# properties to UML?
TIA - jlo
-
I find that properties don't reverse engineer to well from c#. but they forward engineer fine when you use the create new attribute, check property box action.
Anyone have c# properties reverse engineer into the same format EA set's them up when modelling?
regards
Ian
-
I don't see a problem, ???
This:
public class Thingo {
private string thingoname;
public Thingo () {}
public string Name {
get {
return thingoname;
}
set {
thingoname=value;
}
}
} //end class
reverse engineers into a class with an attribute "thingoname" and a method "Name" .
Am I missing something?
Bruce
-
I think of the property as an attribute - granted it is a "derived" attribute at times, granted, but an attribute. It is a grey area since C# created a separate idea of a property that has code behind it.
In your example. in my mind Name is an attribute. thingoname is a private implementation of that attribute.
I'm wondering if others see it that way or agree with your perspective on it.
Thanks for your input -
jlo
-
I too would have expected C# (and Delphi) properties to end up in the attributes section. The accessor methods would then be in the operations section.
As I see it C# and Delphi properties are even more "attributes" than are simple instance variables (fields) since they offer full control of code access.
Is this going to be addressed or do we have to live with it?
-
In the UML UG - section 2 - Attributes, it says, "An attribute is ... an abstraction of the kind of data or state an object of the class might encompass".
From that reading, an attribute is a "state-like" property possessed by the object, which places it at odds with a C# property's dynamic behaviour which may potentially have side-effects or rely on outside information.
-
Interesting - I read that paragraph and it seems to support the idea that properties are attributes - in that they are "state-like" and do represent state the object might encompase.
I mean if my property is "ForegroundColor", that is about as stateful as it gets. How it is represented and derived inside the property's implementation is irrelevant to the design. The property might simply reflect the value of a member variable or represent a call to an enclosed window handle. Either way it is state to the user of the object.
Just my .02.
-
I don't disagree with your example!
But I guess that C# properties have the potential to be more operation-like.
In your colours case, could you have a property IsVisible, which depended on whether the object's colour was the same as BackgroundColour ?
In which case I would say it was a "derived attribute" [tick EA 'Derived' box in Attributes dialog] which was not an intrinsic "attribute" but one which was context-dependent.
Perhaps there is a need for another construct where you make a promise to EA that the "property" really is only a getter/setter for a static (i.e. not computed on context) attribute. If you break the promise, that's your problem, but you are allowed to use a C# property like an attribute.
The point is (I think) - does the value of the object's attribute remain absolutely constant unless one of the object's operations is called ? (or unless you explicitly change the attribute value).
-
My opinion is that properties are definitely attributes.
The typical uses of the getter/setter functions are range-checking and possible updating of other objects/attributes that need to know about or are constrained by the value. Constraints, change events etc. are IMO very relevant to attributes. Of course it is possible to use a property as an operation (e.g. a property named SendNumber which sends a number somewhere every time you assign a number to it). But this is one of the many, many situations where the programmer must exercise common sense to avoid going against the idea of a language construct.
Mikkel
-
Encapsulation says you should be unaware of how an object stores it's state. The fact that a property may just store a value in a member variable, may derive it from another object in it's internal state, might calculate it from atmospheric pressure, it doesn't matter - to the user of the object it is an attribute of the object.
When designing, you are not concerned with the implementation of that attribute.
Most recommendations say that C# member variables should never be public and that a property should aways be used to expose it. One of the strongest arguments is that if the implementation of the property needs to change, the interface to the object remains the same. If that implemntation changes, does it suddenly morph from an attribute to a operation?
In Java, Smalltalk, etc. the same recommendation applies - these languages don't have a specific language construct of a "property" - in Java for example a property is generally indicated with methods prefixed by "get" and:"set". Are they only properties when the implementation is to return the value of a member variable? I don't think so.
At any rate, I'd like the option of C# reverse engineering to place the properties in the attribute section. If it is optional then you could use your approach as well.
-
A text on C# properties that gives a completely different slant on this !
http://www.di%63kbaldwin.com/csharp/Cs000106a.htm
The point made is that it doesn't really matter.
Thanks for educating me about this issue !
PS TO SPARX - please turn off 'Finbar Saunders' mode which changes innocent text to "thingy"!
-
I think this article provides support for looking at it both ways, although Microsoft themselves indicated:
"Properties are logically the same as fields. A property is a named aspect of an object's state whose value is typically accessible through get and set accessors. Properties may be read-only, in which case a set routine is not supported."
Evidently they think of properties as state.
At any rate I put in a request for a switch to have properties reverse engineered as methods or attributes so we all can be happy! :D
-
Having [now] seen that EA supports Delphi properties, I would say that it should support C# properties to the same degree.
-
I completely agree with you!
-
Properties are not attributes.
C# language spec 10.6
"...However, unlike fields, properties do not denote storage locations. Instead, properties have accessors that specify the statements to be executed when their values are read or written. Properties thus provide a mechanism for associating actions with the reading and writing of an object's attributes; furthermore, they permit such attributes to be computed."
C# Programer's Reference section: C# Key Words; Method Parameters; out -- states "A property is not a variable and cannot be passed as an out parameter.
"
The reference for ref states: "A property is not a variable and cannot be passed as a ref parameter."
Together this indicates that properties are operations with a possible relation to an attribute.
Chuck
-
Where does it say a class' attributes have to be implemented as storage locations? If I have an internal collection, and I have an property returning it's count, are you Ok with that as an attribute as it refers to something stored within the object?
When I expect the user of the class to get or set a single value in an object, I implement a property. To the user it is transparent how that state is maintained. When I want an action to occur, I create a method. The user can then expect some action to occur.
So I still want propertied to represent a UML attribute of an object.
I only asked for the option so we could all be happy. :)
-
I also use properties as though they were attributes, but they have a direct one - to - one behavior correlation with operations.
if
public type property
{
get {
any code that returns a value of type
}
set {
any code that changes the value of a variable of type
}
}
then
type x = property is <=> with type x = get_property();
and
property = x is <=> with set_property(x);
The point is that properties also have the same limitations as operations (ie can't be used as ref and out parameters)
98% of the time it doesn't make a difference, but when it does, it will bite you. There are several other places where you will get into trouble if you try to use a property as an attribute. I have spent more then a little time changing code when I forgot and used properties incorrectly.
I therefore think that the way the reverse engineering is done now, gives a better view of what is happening. Sometimes, information hiding isn't the best answer.
Chuck
-
But: Every field is translated into IL-properties upon compilation.
-
I just have to disagree - mapping a property directly to a field is just one implementation of an attribute. The fact that I might to write code to derive the value of an attribute, and that code might be wrong, doesn't change that.
In my mind, a property is never an operation, because if it does something, rather than just change the state of something, I code it as an operation anyway - i.e. a C# method rather than a property.
Again - I just want the option to map a property to an attribute in EA. I had asked for the ability to flip a switch in code generation to set the default. Perhaps this should only be the default, with the ability to set individual properties to appear as attributes or operations based on a tag or something. This would allow you the flexibility to decide which properties are attributes and which are functions. I would be disinclined to use that feature - to me they would all be attrbiutes - but if you wanted to designate them you'd have that flexibility.
jlo
-
Hi,
I've noted that an option to reverse engineer C# properties as properties or methods would be appreciated. The same would I assume apply to VB.Net although that hasn't been discussed yet.
I'll look into how hard it would be to do this along with everything else that I am doing. Default behaviour would probably be the existing behaviour.
Simon
-
To me it is clear. An attribute is something that is operated on by operations. An operation is something that can modify the state of an attribute. A C# property can operate on an incoming or outgoing attribute value, therefore is must fall under the operation category.
Paul
-
OK, if a property is modeled as an attribute, how is the code generated? Also, if a property model named Count accesses a private attribute named count, how do you model the association?
-
You can already create properties in the attribute section of the model - create an attribute and attach the "property" stereotype. When you generate code you get:
public string Ssn {
//read property
get{;}
//write property
set{;}
}
That works fine for me.
What I'd like is the opportunity to have reverse engineering reversing properties so they end up in the attribute section.
I don't understand the association question.
-
Simon -
Yes - I'd really like the option for the reverse engineering to place the the properties in the attributes section. Although I was thinking C# I do occasionally work in VB also so that would be great.
jlo
-
Note that you can specify a class attribute to be 'derived' (which is close-ish to a C# property) which makes it display with a '/'.
I don't know how this affects code generation.