The MOF spec 1.4.1 included the following language (6.3.1.5 Class Generalization):
The meaning of MOF Class generalization is similar to generalization in UML and to interface inheritance in CORBA IDL. The sub-Class inherits all of the contents of its super-Classes (i.e., all of the super-Classes Attributes, Operations and References, and all nested DataTypes, Exceptions, and Constants).
Note the absence of Association and Aggregation in this list. If Property and Operation had been attributes of DataType, they would have been inherited. But they're aggregates, and as such are not inherited.
Subsequent versions of the MOF spec have dropped this language, but I can't find anything that supports the idea that MOF generalization was ever extended to include aggregations.
Hmm, never thought of it like that. Although, if not Associations, what would they mean with "References"?
Again from
MOF 1.4.1 (pp 18-19):
"The MOF Model provides an additional kind of Class feature called a Reference that provides an alternative “Attribute like” view of Associations."
This is in addition to associations and attributes, and they provide an example. It is a bit of a weird one, but the point is that it's a different beast from either attributes or associations.
But that was more of a side remark.
Do you agree that the UML syntax allows Generalizations between PrimitiveType and Datatype because they are both Classifiers?
No.
If that were the case then all relationships that pertain to Classifier would apply equally to all subtypes of Classifier. This would mean that actors could generalize use cases, collaborations could redefine enumerations, etc.
In fact, since Classifier itself is a specialization, if you go all the way up to the root concepts, you'll find that that line of reasoning eradicates all but the most fundamental distinctions in UML. Since all elements are ultimately specializations of Element, and all relationships are ultimately specializations of Relationship, and since Elements can have Relationships to other Elements, all UML elements can have all UML relationships to all other UML elements. This is clearly nonsense.
The key, I believe, lies in the fact that Classifier is abstract. While Generalization (which is concrete) is defined as having one directedRelationship from one "specific" Classifier, and one directedRelationship to one "general" Classifier, this doesn't mean that all specializations of Classifier can be substituted freely. Only concrete specializations can be the source/target of those relationships, and I think the correct way to read figure 9.1 is to say that they must both be the same, ie a Generalization is only valid between two
of the same specialization of Classifier. But since Generalization is concrete, we don't need to specialize it into different relationships for ClassGeneralization, ActorGeneralization, etc.
In the DataType case, this means that you can draw Generalizations between two DataTypes, between two Enumerations and between two Primitives, but nothing else.
You should also be able to draw Generalizations between two Classes, but not between a Class and an Interface. And so on.
EA does allow quite a lot of these cross-classifier-specialization generalizations. I think it's wrong in each case.
/Uffe
