Missing UML 2.x Infrastructure Library Metaclasses

[Dave Raymer]

or is it just me ...

When creating a profile, I note that a number of the UML 2.3 Infrastructure Library Metaclasses are not in the list of selectable metaclasses:  Element, NamedElement, Type and TypedElement.  Is this intentional or an oversight?  I can find nothing in the OMG specs that indicates these 4 puppies should not be present.

Wanted check here before I turned to support ...

regards,

Dave

[Geert Bellekens]

Dave,

Could it be that EA has only included the concrete metaclasses and not the abstract ones?

Geert

[Dave Raymer]

Geert,

I was thinking the same thing myself.  The question becomes, if one is attempting to augment the base-capabilities of the language, and the rules of proper inheritance make reuse of the an existing concrete metaclass problematic, what is the proper course of action with regard to EA in this space?

- dave

[Geert Bellekens]

Dave,

I think the ID of the UML profiles in EA is to extend the existing UML structure. So starting from the existing set of (concrete) metaclasses create your own metaclasses.
This way, any model you create using your own profile is still UML.
If you however create your own subclass of NamedElement say MyNamedElement then the instances of this MyNamedElement would be UML anymore (since NamedElement is abstract in UML, and MyNamedElement is not a known concrete subclass in UML)

I'm not sure if I made myself clear, but I hope so :-/

Geert

[Dave Raymer]

Geert,

Initially, I didn't see your point, but I decided to go take yet another look at section 13 of the infrastructure specification.  When you read the first paragraph of the "Extensibility" subclause in section 13,  I don't see your point. but when you read the second paragraph, ok, I see your point, and then you read the "list of reasons", I'm back to I don't see your point.

After a fairly thorough review of section 13 of the UML Infrastructure Library specification, I'll try to paraphrase your point:

Using concrete metaclasses as extension points is supported by the profile mechanism, extending abstract metaclasses is not supported by the profile mechanism.   Is this correct?  If so, I don't see this clearly reflected in the specification.  

Requirement 8 says I can't change the parenting of existing classes, or the semantics of the existing metaclass definitions. Adding a subclass of an existing abstract or concreate metaclass does not change the base meta-model, it is still read only.

If the metaclass were final, I would absolutely agree with you, however, none of the four classes I listed are defined with final semantics.

At this point, I think I need to ask Sparx Systems the question.  

thanks for the discussion, it was most helpful.

regards,

Dave

[Geert Bellekens]

Dave,

I didn't read the OMG specifications earlier, and now that I did, I indeed see no explicit restriction on extending abstract metaclasses.
However, I think that is a restriction that should be there.

How I see it is that applying a profile to a UML model still keeps it a UML model. In other words, every element in such a model can still be identified as a specific UML element, and it would still adhere to all the rules of the UML metamodel.
So if I were to read your model, without knowing your profile, I would still be able to interpret each element as an instance of a UML metaclass.
That would be problematic if you were to extend an abstract metaclass in your profile.

It is indeed a good idea to ask Sparx about this, and an interesting question to pose at some other UML forums as well.

Geert

[Geert Bellekens]

I've posted this as a question on the UML Lovers group on LinkedIn: http://www.linkedin.com/groupItem?view=&gid=143183&type=member&item=60924446&qid=7a1becd7-0063-4aa5-ad4e-e4a4b37caf04&goback=%2Egmp_143183
(I think the link only works if you are a member of that group)

Let's see what the experts have to say about that

Geert