AW: AW: AW: [jwt-dev] About the JWT Model

["Christian Saad" <christian.saad@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Pierre,

> What will prevent the user (in other words what will enforce
> constraints) will
> be an external part. The current model does not guarantee constraints.
> So you
> only rely on the editor to get that a fork node is actually an UML Fork
> Node.
> Basically, my point is that current leaf nodes do not represent any
> useful
> information at the model level (again, the external layer will
> guarantee that
> the Fork is what you expect to be a Fork, the model does not tell
> that).

The constraints are actually in the model (the upper and lower bound of the
relationships) but not enforced by EMF. These constraints could be made to
work from the model level, either by putting OCL constraints on the model,
or reading the lower/upper bound from the EClasses in the EditParts using
reflection. However, I think there may be a problem with the generalization
hierarchy, since if the parent node allows an arbitrary number of
connections, the child will probably not be able to put restrictions on the
inherited relationship (but maybe I'm wrong here).

> > This means that a user can now
> > have an AndControlNode with several incoming and several outgoing
> edges.
> 
> Sure, this is possible. BPMN allows that. By the way, our end-users
> want that.
> Therefore, at least one JWT-based editor will have such a feature:
> ours!
> 
> I bet that if JWT gain some wide adoption, you will find some other
> editors
> with the same pattern.

You are right, it is important that this will be supported. The basic
question is: How can we integrate both options in a way that not only works,
but also makes sense ;)
One obvious (but ugly) solution would be to put AND, FORK, JOIN as childs of
ControlNode and activate/deactivate AND or FORK/JOIN using views.

Regards,
Chris