|Re: [mdt-uml2.dev] About StateInvariant implementation|
Perhaps one of my stock observations will help.
The "Constraint" class is a dustbin concept at the periphery of the UML specification that seems undesigned and underspecified in either UML or OCL.
In practice, OCL is used in a number of specific ways that could be explicitly specified: PreCondition, ClassInvariant, DerivedValue, GuardCondition. Instead there is often a semi-dedicated property such as precondition that endeavours to make the inherited ownedRule meaningful. StateInvariant can be seen as a variant design approach in which a clear class name was provided but it is nonetheless redirected via a mandatory containment to the dustbin.
Since UML 2.5 missed the opportunity to clarify the semantics of the diverse constraints, OCL 2.5 may have to rise to the challenge without changing the UML metamodel. Sharing of Constraint instances will remain impossible, unless a consensus that the conflicting indications in the UML specification permit the Constraint to be contained/owned by a context that is 'self' (ie. the Class/StateMachine) and applied to the potentially many constrainedElements. This may require OCL to introduce an ability to reference the prevailing constrainedElement and provide a stereotype to distinguish ambiguous Constraint roles.
Sorry. It's a mess.
On 27/10/2014 17:56, Sebastien Bordes wrote:
Back to the top