UML24 — Detailed modeling of the Standard Profiles

I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof.

Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI

BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel.

Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions.

If for no other reason these need to be updated to reference other stereotypes using their upper case name.

The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues:

1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target

3. Likewise for Create (when applied to Dependencies) they must both be Classifiers.

4. There are 2 rows for Create – I presume this is one Stereotype that extends 2 metaclasses.

5. I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

6. The Derive stereotype should have a computation Property to ‘specify the computation’. I suggest this should be of type OpaqueExpression?

7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency?

8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). Is File abstract as implied by the description?

9. Executable is a subclass of File. And I guess it should have the same constraint?

10. Library is a subclass of File

11. ModelLibrary needs to be cleaned up - I will raise a separate issue

12. Description of Process seems a bit lacking

13. It seems Realization and ImplementationClass cannot both be applied to the same element?

14. Script is a subclass of File.

15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target

16. It seems odd to say that Service “computes a value”.

17. Source is a subclass of File.

18. It seems Specification and Type cannot both be applied to the same element?

19. The description of Utility “A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped” – not sure what it means by ‘non-member’, but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances).

This is quite a lot of things in one issue, most of which have already been resolved by explicitly modeling
the profile. Some of the points suggest adding constraints to stereotypes, which I propose not to resolve
here but instead to submit a new issue to capture the proposal. Some of the points require rewording for
clarification, and the current resolution does this.
The point about Derive is incorrect: Abstraction already has a mapping in the model.
I am averse to copying the definitions into the metamodel because it will introduce redundancy and run the
risk of future inconsistency.
This also resolves 15278 and 15279.