[gme-users] Constraint problem

Matthew J. Emerson mjemerson at isis.vanderbilt.edu
Thu Mar 2 12:01:00 CST 2006


The constraint manager is really just another GME Add-On (event-driven
model interpreter). You could write your own small Add-On to monitor for
this one even event for your language and disallow in the same way the
constraint manager would without writing an actual constraint that would
get checked on "Check All".

 

Or, you could use GME type-instancing. You could define a container with
the appropriate number of children "off to the side", and then in your
actual model on use instances of the container. The instances would be
read-only, so the number of children could not change.

 

You may also be able to use the multiplicity of the composition
connection if all instances of the container type are supposed to
contain the same static number of children.

 

The only way to make what you describe work with an OCL constraint,
though, is by using some piece of state that persists longer than the
evaluation of the constraint. For example, an attribute on the Container
that gives the number of children it should hold.

 

--Matt

 

  _____  

From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Larry
H.
Sent: Thursday, March 02, 2006 10:32 AM
To: gme-users
Subject: [gme-users] Constraint problem

 

I'm having a problem defining a constraint that concerns a change in
number of children in a container.  My intention is to check this
constraint on an event, like "onlostchild", and to prevent the action by
setting the constraint's Priority=1.  My problem is to find an approach
that does not subsequently trigger a violation when the user chooses the
'Check All' action of the Constraint Manager.

 

It is my current belief that there is no way to define such a
constraint.  The reason is that the focus of this constraint is
"change", whereas the focus of the Constraint Manager, in general, is
"current state".   Constraints concerning "change" typically involve
knowing "state before" and "state after".  Have I failed to consider
something?

 

One thing that occurs to me is that the Constraint Manager might
consider not checking constraints on "Check All" that are checked on
events with Priority=1.  The intuition is that, since such event-based
constraints can only result in aborting the action, there is simply no
reason to check them again on "Check All".  Such a feature would allow
the desired constraint to be defined quite simply with a "false"
predicate.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/gme-users/attachments/20060302/8220cf93/attachment.htm


More information about the gme-users mailing list