| Re: [mdt-uml2.dev] About StateInvariant implementation |
We don’t have the need to build complex Constraint hierarchy, end-users are totally lost when too much concept are used.
We really want to keep it as simple as possible.
If the invariant Constraint of StateInvariant couldn't be contained by StateInvariant, it will solve our problem, does-it make sense to have a unique Constraint into StateInvariant that couldn’t be link with anything else ?
Each time you will want to express a pre-requisite on a lifeline (related to a state expressed into a statemachine), you will have to build another instance of Constraint even if it’s the same state invariant… it’s really counter-productive. In this case we could use an Action that will check something instead of using a StateInvariant that finally is useless ...
The norm doesn’t affirm that the invariant cannot be reused, it’s just an implementation problem due to the usage of EMF technology (and particularly its serialization engine that require a parent container for any object).
As is the mdt-uml2 implementation doesn’t allow to make a logical link between State stateInvariant and StateInvariant invariant whereas it would be convenient to reuse state already described into sequence diagram.
Best Regards
Sébastien
Hi
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.
Regards
Ed Willink
On 27/10/2014 17:56, Sebastien Bordes wrote:
State and StateInvariant are not shown into the same diagram, I put them together to demonstrate my goal.
I would be pleased to re-use all my states into sequence diagrams without having to duplicate a ton of useless wrapper objects, definitely Copy-paste/Duplication is not an option for me.
I’m ok with the norm, my question concerns the implementation, more precisely the value of containment property for State.stateInvariant and especially StateInvariant.invariant.
Best Regards
Sébastien
On Mon, Oct 27, 2014 at 5:53 PM, Sebastien Bordes <sebastien.bordes@xxxxxxxxx> wrote:
State and StateInvariant are not shown into the same diagram, I put them together to demonstrate my goal.
I would be pleased to re-use all my state into my sequence diagrams without having to duplicate a ton of useless wrapper objects.
And definitely Copy-paste/Duplication is not an option for me.
I’m ok with the norm, my question concerns the implementation, more precisely the value of containment property for State.stateInvariant and especially StateInvariant.invariant.
Best Regards
Sébastien
From: mdt-uml2.dev-bounces@xxxxxxxxxxx [mailto:mdt-uml2.dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: lundi 27 octobre 2014 17:19
To: mdt-uml2.dev@xxxxxxxxxxx
Subject: Re: [mdt-uml2.dev] About StateInvariant implementation
Hi
I think you are misreading the UML. There is no requirement that the State is 'shared' it is just a draughting convenience to re-use the State box on the diagram.
In general UML does not use sharing of anything. If you want to repeat Constraint content, you must repeat it, at least until you can invoke a re-useable Operation / query. If you're clever you might do something horrible with multiple inheritance or a stereotype.
Regards
Ed Willink
On 27/10/2014 16:25, Sebastien Bordes wrote:Hi,
I’m currently working on Sequence Diagrams and StateMachine Diagrams.
We want to allow to reference a StateMachine’s State into a Sequence Diagram as a StateInvariant that covers a Lifeline.
According to the UML snippet below:
(describing relations between State, StateInvariant and Constraint)
As we can see we can use the Constraint object as a link between both world (Interaction and StateMachine).
Unfortunately the uml2 implementation is done exactly at the inverse I would have expected.
The State’s stateInvariant property has a containment set to false with a cardinality of 0..1
The StateInvariant’s invariant property has a containment set to true with a cardinality of 1
By default the StateInvariant will own an automatically built Constraint.
Whereas the State can have 1 or zero reference of Constraint.
What can I do to share a State stateInvariant on several Lifeline using several StateInvariant invariant ? IMHO the constraint should be owned by the State itself and reuse on any Lifeline by wrapping it with a StateInvariant.
If the containment properties are reversed, I will be able to attach a Constraint to my State and to reference it from several StateInvariant
Is-it a weakness into the implementation ? otherwise how can I link these items simply (without having to use free text)
(I’m using a Luna M6 derived version)
Thank you in advance for your help
Sébastien BORDES
_______________________________________________mdt-uml2.dev mailing listmdt-uml2.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/mdt-uml2.dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4040/8461 - Release Date: 10/27/14
_______________________________________________ mdt-uml2.dev mailing list mdt-uml2.dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-uml2.dev
Version: 2014.0.4765 / Virus Database: 4040/8463 - Release Date: 10/27/14
_______________________________________________
mdt-uml2.dev mailing list
mdt-uml2.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-uml2.dev