Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322933

Summary:	[General] Papyrus shall enable to model UML Constraints.
Product:	[Modeling] Papyrus	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	Patrick Tessier <Patrick.Tessier>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	rschnekenburger
Version:	1.0.0	Keywords:	plan
Target Milestone:	M6	Flags:	sebastien.gerard: luna+
Hardware:	PC
OS:	All
Whiteboard:	Editors
Bug Depends on:	322998, 399267, 322987, 322994, 322997, 323001, 399269
Bug Blocks:

Description Ed Willink

2010-08-17 13:06:45 EDT

I tried to emulate Slide 44 of http://www.eclipse.org/modeling/mdt/uml2/docs/presentations/EclipseCon2008_LongTalk_NewFeaturesOfUML2_files/frame.htm using Papyrus.

The support for Constraints seems very counter-intuitive.

a) A Constraint must be dropped as a top-level diagram element;
a Properties entry does not seem to be present.

b) The Constraint can then be given a Context from the Properties drop-down; an edge does not seem to be possible.

c) The Properties offers a large 'Constrained Elements' entry field,
but only a small Specification field.

d) The Specification field allows only selection of literals already defined; no ability to create a new OCL expression.

e) Giving an operation constraint a BodyCondition role is not possible using e.g. a <<body>> sterotype.

f) The Specification is not displayed within the {} of the Constraint.

It seems that Papyrus provides some creation help through the Constraint node but full entry requires detailed understanding of UML and use of the UML2 model level editing. 

Suggest provision of an expression entry editor using the MDT/OCL EssentialOCL Xtext editor when the language is OCL.

Comment 1 Yann Tanguy

2010-08-18 04:17:37 EDT

Thanks for the feedback Ed.

Can you provide some more information for these items:
 a) I dont understand which "Properties entry" you expect here
 b) What you intend to do here is to select an edge (lets say a dependency) as the Constraint context, am I right ?
 f) The specification is not displayed in the Constraint (shown in the diagram) when your constraint specification is not a LiteralString (OpaqueExpression maybe, but the problem probably remains with any other ValueSpecification). Is this correct ?

Comment 2 Ed Willink

2010-10-01 13:10:46 EDT

I think I already replied on a newsgroup thread or mdt-papyrus-dev, but anyway:

a) In order to edit a constraint such as "name.toUpperCase() = name", I need a text entry box that allows me top type the string (better an OCL expression editror with semantic validation), but at least a text entry box. I would expect to find it on the "Properties" View, but it isn't there.

b) yes

f) It seems only possible to re-use a ValueSpecification as the constraint body. This is not very helpful, because there is nowhere obvious to create them, and the UML model has the ValueSpecification owned by the Constraint.

Comment 3 Camille Letavernier

2012-02-07 10:32:44 EST

A few improvements have been brought to the global behavior of the property view, which now makes things "possible".

a) Not fixed (Related to the property view configuration, if I understand well. You'd like to be able to edit the "Body condition" for an Operation from the property view ?)

b) Fixed.

c) Not fixed. The property view is still really close to the UML Metamodel. We're editing a reference here, not the constraint object directly. This could be improved, but this isn't an isolated case, so we'd need a global vision for that.

d) Fixed.

e) This seems to be related to a). The role of the constraint is defined in the Operation, not in the constraint itself, so we really need to be able to edit the "Body condition" somewhere.

f) This seems to be fixed

Comment 4 Ed Willink

2013-01-10 12:37:37 EST

Revisiting on Kepler M4 to see which problems remain.

I assume that a "Link" is the correct relationship between a Constraint and its constrainedElement; there seems to be no graphical clue.

A Constraint can be linked to a Class.

The context can be specified in a pull down, (I was wrong to request a graphical capability here.)

a) A Constraint cannot be graphically linked to an attribute or operation; dropping on a feature constrains the class rather than the feature.

b) A Constraint.constrainedElement can additionally constrain a feature using the properties view, but not a feature of an already constrained class. It is necessary to delete the class constrainedElement to get the features in the panel tree options.

c) The role of a constraint on an operation cannot be specified as <<pre>>, <<post>>, <<body>>; perhaps needs a structured dialog.

d) Entry of constraints on States requires a structured dialog.

Comment 5 Patrick Tessier

2013-01-28 08:26:49 EST

the requirement D becomes must belongs to  the task 399252: [OCL for Papyrus]  The editing pop up for a Constraint in a UML State Diagram should support editing OCL.

Comment 6 Patrick Tessier

2013-01-28 09:24:07 EST

the requirement c) becomes part of the task 399249. 
so now it remains two sub tasks:
a) A Constraint cannot be graphically linked to an attribute or operation; dropping on a feature constrains the class rather than the feature.
see bug  399267

b) A Constraint.constrainedElement can additionally constrain a feature using the properties view, but not a feature of an already constrained class. It is necessary to delete the class constrainedElement to get the features in the panel tree options.
see bug  399269

Comment 7 Sébastien Gérard

2014-01-29 05:04:31 EST

@ Patrick: can you please check the status of this task and clarify what is the remaining work to be done if any. Thanks.

Comment 8 Patrick Tessier

2014-01-29 06:19:15 EST

a)to place a constraint as body pre or post you can use the property view
--> fixed.
b) Fixed.

c) fixed as for A)

d) Fixed.

e) This seems to be related to a). so it is fixed

f) This seems to be fixed from old post.

So this task is fixed