Author Topic: Role name vs. attribute  (Read 1471 times)

qwerty

  • EA Guru
  • *****
  • Posts: 8964
  • Karma: +136/-123
  • I'm no guru at all
    • View Profile
Role name vs. attribute
« on: July 07, 2017, 06:59:44 pm »
It has beed discussed formerly and Geert has a nice blog entry about the usage of role names and attributes. Recently I came upon this once again. If I have a diagram where a typed attribute is shown in the compartment of a class, this is a useful information. However, if this attribute is typed with some class and on another diagram I show both classes with an association, I want to show the role name at the end of the association instead of the attribute in the class' compartment. Having some (global) diagram option for this would really be nice.

One drawback with the current connector implementation with EA is that if you have multiple associations, there is no connection between the association and the attribute. EA offers the attributes from a drop down in the role fields. But once chosen they are no longer connected. That means one would have to set and maintain role names. Only in case there's just a single association, the role name could be derived automatically from the attributes.

q.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Role name vs. attribute
« Reply #1 on: July 31, 2017, 09:56:58 am »
+1

In the "Good Old Days", UML specifically said: "a named Association End IS an Attribute" (my emphasis and perhaps some paraphrasing).  But that seems to have gone by the way side, notwithstanding that it is patently so.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6197
  • Karma: +47/-5
    • View Profile
Re: Role name vs. attribute
« Reply #2 on: July 31, 2017, 03:45:12 pm »
In the "Good Old Days", UML specifically said: "a named Association End IS an Attribute" (my emphasis and perhaps some paraphrasing).  But that seems to have gone by the way side, notwithstanding that it is patently so.

I think you'll find that it was the navigability (possibly in conjunction with a name) that was previously used for this. Now UML explicitly states that they are different.
Quote
Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were
assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the
opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate
concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those
owned by associations may be navigable or not.

Within the UML specification itself you'll find that all association ends are named (with an implicit naming rule if there is no explicit name) but obviously not all of them are intended to be attributes.
Simon

support@sparxsystems.com

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Role name vs. attribute
« Reply #3 on: July 31, 2017, 04:47:57 pm »
In the "Good Old Days", UML specifically said: "a named Association End IS an Attribute" (my emphasis and perhaps some paraphrasing).  But that seems to have gone by the way side, notwithstanding that it is patently so.

I think you'll find that it was the navigability (possibly in conjunction with a name) that was previously used for this. Now UML explicitly states that they are different.
Quote
Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were
assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the
opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate
concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those
owned by associations may be navigable or not.

Within the UML specification itself you'll find that all association ends are named (with an implicit naming rule if there is no explicit name) but obviously, not all of them are intended to be attributes.
Hi Simon,

Agree that they are all separate concepts.  Personally, I don't think I ever considered navigability - just the notion that if the association end was named it was an alternate rendering for an attribute.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

qwerty

  • EA Guru
  • *****
  • Posts: 8964
  • Karma: +136/-123
  • I'm no guru at all
    • View Profile
Re: Role name vs. attribute
« Reply #4 on: July 31, 2017, 04:52:55 pm »
Within the UML specification itself you'll find that all association ends are named (with an implicit naming rule if there is no explicit name) but obviously not all of them are intended to be attributes.
So what is an association that's not going to be an attribute? A ghost?

q.

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2436
  • Karma: +29/-2
    • View Profile
Re: Role name vs. attribute
« Reply #5 on: July 31, 2017, 05:04:44 pm »
So what is an association that's not going to be an attribute? A ghost?

I think the question should be the other way around: what is an attribute that's not going to be an association end? The convention used in the UML specification itself appears to be that they use associations between classes, but attributes with data types (primitive or otherwise).
The Sparx Team
support@sparxsystems.com

qwerty

  • EA Guru
  • *****
  • Posts: 8964
  • Karma: +136/-123
  • I'm no guru at all
    • View Profile
Re: Role name vs. attribute
« Reply #6 on: July 31, 2017, 09:18:25 pm »
Exactly. It should be written down in the UML specs. That's what specifications are good for.

q.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Role name vs. attribute
« Reply #7 on: August 01, 2017, 10:13:20 am »
So what is an association that's not going to be an attribute? A ghost?

I think the question should be the other way around: what is an attribute that's not going to be an association end? The convention used in the UML specification itself appears to be that they use associations between classes but attributes with data types (primitive or otherwise).
I struggle with the difference between a class and a datatype (at a fundamental level).  I think I've come to the conclusion that a datatype IS a class with NO operations and NO reference type attributes.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

qwerty

  • EA Guru
  • *****
  • Posts: 8964
  • Karma: +136/-123
  • I'm no guru at all
    • View Profile
Re: Role name vs. attribute
« Reply #8 on: August 01, 2017, 05:34:03 pm »
I don't think so. They are a different concept. More or less, datatypes map directly to a (fixed) piece of memory while classes map to a (sort of) variable memory with optional code parts.

q.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Role name vs. attribute
« Reply #9 on: August 01, 2017, 05:48:40 pm »
I don't think so. They are a different concept. More or less, datatypes map directly to a (fixed) piece of memory while classes map to a (sort of) variable memory with optional code parts.

q.
In some (most?) languages this is the case, but from a conceptual point of view that need not be the case.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

qwerty

  • EA Guru
  • *****
  • Posts: 8964
  • Karma: +136/-123
  • I'm no guru at all
    • View Profile
Re: Role name vs. attribute
« Reply #10 on: August 01, 2017, 09:23:04 pm »
I think it applies to all languages (simply for historical reasons). Integers have been 4 bytes (aka 32 bits) for a long time (only a few oldies remember times when integers used to be 16 bits). Now they occupy 64 bits. But it's some fixed amount of memory for simple hardware reasons. In Python for example Integers are no primitives but objects (so you can really use numbers that occupy more than 64 bits without any precautions).

q.

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2436
  • Karma: +29/-2
    • View Profile
Re: Role name vs. attribute
« Reply #11 on: August 02, 2017, 11:49:36 am »
Is the difference between a class and a datatype that instances of a class have identity whereas instances of a datatype are distinguishable only by their value? (This Fred is not that Fred, but a 3 is a 3 is a 3).
The Sparx Team
support@sparxsystems.com

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Role name vs. attribute
« Reply #12 on: August 02, 2017, 02:38:32 pm »
Is the difference between a class and a datatype that instances of a class have identity whereas instances of a datatype are distinguishable only by their value? (This Fred is not that Fred, but a 3 is a 3 is a 3).
In a local discussion at our site, that's the conclusion we came to.  As you note, Neil, it's not correct to say that datatypes have no instances.

Now, the question arises, what if we have compound datatypes (such as beloved by SAP etc.)?  These are very useful - and we're modelling them (at the conceptual level)  (BTW: we reverse engineered the 38MB SAP datatypes file in a previous life).  If a datatype includes a reference field, it's only the same as another instance of that datatype if the values of the references are the same, no?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

PeterHeintz

  • EA User
  • **
  • Posts: 549
  • Karma: +37/-14
    • View Profile
Re: Role name vs. attribute
« Reply #13 on: August 02, 2017, 09:45:36 pm »
Hi, Paolo
I assume KP is Neil, right?

Neil did not say that datatypes does not have instances but the identification is different.

As long as you have no concrete implementation (Java, C++,) in mind in your model, there is not much need to differentiate between data types and classes.

Concrete languages might have data types/structured data types only or classes only or both, and in many languages you need a kind of new() to create an object of a class but you need no new() for a data type instance and the object data typically you find on the heap but the instance data of a data type you find on a stack.
But all those things only matter, when having concrete programming languages in mind.
Best regards,

Peter Heintz

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5880
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Role name vs. attribute
« Reply #14 on: August 03, 2017, 10:00:20 am »
Hi, Paolo
I assume KP is Neil, right?
Yes.
Quote
Neil did not say that datatypes does not have instances but the identification is different.
Yes, but by noting that there might be multiple instances of a datatype with the same values, he was implicitly refuting the often made assertion (not by him, but others - in various places) that datatypes "don't have instances".
Quote
As long as you have no concrete implementation (Java, C++,) in mind in your model, there is not much need to differentiate between data types and classes.
In principle, I think that even conceptually, there are "things that must be referenced" and "things that have values".  Consequently, I think there is a place for "datatypes" vs "classes".   For example, we've found it useful to differentiate in our MDG between Business Objects (which must be referenced) and Characteristics (which have values).  I think that has helped bring clarity to the models and also helped us to explain data issues to our clients.
Quote
Concrete languages might have data types/structured data types only or classes only or both, and in many languages you need a kind of new() to create an object of a class but you need no new() for a data type instance and the object data, typically, you find on the heap but the instance data of a data type you find on a stack.
But these are implementation mechanisms, they are not "of the essence".  It could be argued (and I would support) that the implementations are the way they are BECAUSE of the essence - but thereby one reveals my point.
Quote
But all those things only matter, when having concrete programming languages in mind.
But if you haven't got the conceptual model right, you are implementing a wrong model.  My questions relate to understanding how to best represent the world to create a viable conceptual model.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!