attributes vs. connectors

[ghost23]

Hi,

for expressing, that ClassA has an Attribute of Type of ClassB i can either:

1. define an Attribute in the Details Tab of the Properties of ClassA and say, it should be of Type of ClassB

2. draw a connector (like an association for example) between ClassA and ClassB and set the Source and Target Role respectively

What i don't understand is, if i do the first, EA does not automatically draw a respective connector between the two classes. And if i do the second, EA does not automatically create an attribute in ClassA (although EA does create the attribute when generating the source code).

So can someone please explain to me, why there is difference and when i should use what?

Thank you

[Geert Bellekens]

Hi,

I generally recommend to only use attributes to represent relations when the type of the attribute is defined as a UML DataType (things like Date or BankAccountNbr).

This helps to keep things consistent in a model, and it doesn't have the overhead of having to create both an attribute and an association for every static relation between classes.

Geert

[beginner]

In an earlier discussion Paolo stated that attributes and associations are two different renderings of the same thing. A statement which I absolutely concur. From my point of view it is a design flaw in Superstructure^s to not explicitly describe the relation between associations and related attributes. In EA for example an association can be role-named after an existing attribute. But no attribute can be created from such a relation. And further, once the association is named after an attribute and you rename the attribute the association role name does not change accordingly. That means attributes are "stronger" than associations and the latter should only be used to graphically emphasize relations between elements.

b.

[Paolo F Cantoni]

Hi b,

You just have to be a bit rigourous here... Only a "named Associaiton End" IS an Attribute.

That statement used to be in the Superstructure document, but it (apparently) no longer is; though I still believe that statement is valid.

Paolo

[Makulik]

I generally recommend to only use attributes to represent relations when the type of the attribute is defined as a UML DataType (things like Date or BankAccountNbr).

That's what I usually refer to as 'primitives'. I don't have a really good definition for the term, but most of my colleagues intuitively figure what's meant with it.

Just my 0.02 EUR
Günther

[Geert Bellekens]

Günther,

Primitives are yet another concept, there are also datatypes, but without a substructure:

From superstructure 2.2

A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of
UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically.

Geert

[Makulik]

Yes, I know Geert. But on 'metalevel' I use this term though, and most developers are able to follow that kind of abstraction, because they already know what it means on level of the(ir) programming language ...
I use it when talking about, hmmmm, let's say "closed informational units" that can be (re)used more or less completely "stand alone".
UML DataType is a good definition (or abstraction) also, but I don't always strictly define UML DataTypes for these ...

g.

PS.: I wasn't aware, that there's a definition in the UML Superstructure also. Thanks for the hint.

[Eve]

You just have to be a bit rigourous here... Only a "named Associaiton End" IS an Attribute.

That statement used to be in the Superstructure document, but it (apparently) no longer is; though I still believe that statement is valid.

This convention although still used in the diagrams in the specification, was superseded by explicit end ownership with UML 2.0.  (Or was it 2.1, I forget.)

[Paolo F Cantoni]

[size=18]...[/size]
This convention although still used in the diagrams in the specification, was superseded by explicit end ownership with UML 2.0.  (Or was it 2.1, I forget.)

Thanks Simon,

I thought my memory wasn't failing me.  I'm aware of the explicit end ownership in UML2.x.

But, the question still is...  Does that invalidate the assertion about named Association End and Attributes?

Paolo

[Eve]

My interpretation is that strictly speaking it does invalidate it.  But the reality is that even OMG didn't use end ownership in the specification, the same can probably be said for most people using UML and if you did use it, most people reading your model won't know what those little dots mean.

So, in the end it's still useful.