Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-uml2.dev] About StateInvariant implementation
Hi

I've given you my view of what usage might be standard.

So long as you are user and consumer of your models, you may do whatever you like, limited only but what your tooling allows you to enter.

    Regards

        Ed Willink

On 28/10/2014 16:06, Sebastien Bordes wrote:

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


On Mon, Oct 27, 2014 at 9:07 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
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)

 

http://yuml.me/03dd13b5

 

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 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




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


No virus found in this message.
Checked by AVG - www.avg.com
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



_______________________________________________
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


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4040/8467 - Release Date: 10/28/14


Back to the top