Import source C# auto-implemented properties

[urod]

Hello,

I'm using Code Engineering to import C# source code and the classes contain auto-implemented properties.
Let's say
class ClassA
{    
    public ClassB propertyAB { get; set; }
  }

class ClassB
{}

When I put the 2 classes on a diagram I expect to see an association between them...but I don't...Anyone facing the same problem?

thanks!

[Konrad Wieland]

Some months ago, we requested the same at Sparx HQ. The answer was, that the "automatic" properties correspond to Operations and operations are not represented by Associations.

Cheers
Konrad

[phurst]

Was any reason given for auto properties being treated as operations rather than attributes?

For one thing if you want to set run state in an object diagram for operations you have to type in the name of the operation, but you can set attribute values as run state by selecting the attribute from the combobox. When I set run state its always for a property (auto or otherwise), and never for an operation.

In fact, to C# programmer, operations don't really have state. State is stored in fields and properties.

Treating auto properties as operations seems perverse to me.

[webfox]

Auto-properties in .NET are operations just like regular properties are. When using them in your code, the compiler automatically creates a private member variable for your convenience. You can easily check this out in the MSIL using e.g. .NET Reflector.

I get your point, but Sparx HQ is right: auto-properties are semantically equivalent to operations (= methods). Therefore, they must be treated as such in UML models. Associations, on the other hand, refer to attributes. If you want EA to create an association, you must specify the attribute explicitly in your code. This, unfortunately, means that you cannot use auto-properties.

Cheers,

Till

[Geert Bellekens]

I agree with the operations part in the IL, but if I write

Code: [Select]

class ClassA
{    
   public ClassB propertyAB { get; set; }
 }Then that is just syntactic sugar for

Code: [Select]

class ClassA
{    
   private ClassB _propertyAB;
   public ClassB propertyAB
  {
         get {return this._propertyAB;}
         set {this._propertyAB = value;}
  }

 }
I would expect both snippets to result in exactly the same UML model.

Geert

[webfox]

Geert,

I partly agree with you, but this is just one example of .NET trying to make developers' lives easy while blurring the semantic differences between things at the same time, at least from a modelling perspective.

Treating auto-properties as attributes in models is wrong. They are operations as the underlying attribute is opaque to the model. The model cannot "infer" it.

This is why I try to avoid them whenever possible, especially in cases where I need to maintain and control state. They add little value to your code, you could just as well make your attributes public. Well, this is not exactly true as I can still control access independently for get and set operations using auto-properties. But the point of properties (or getters and setters) is to have complete control over what goes in and what comes out. Auto-properties do not provide any control beyond access modification.

But ultimately this is something one can argue about.  

Cheers,

Till