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

Bug 364062

Summary: [UMLPropertiesView] Multiplicity parser should not be restricted to only integer literals
Product: [Modeling] Papyrus Reporter: Alain Le Guennec <alain.leguennec>
Component: CoreAssignee: Project Inbox <mdt-papyrus-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: cletavernier, eclipse-bugzilla, papyrus-bugs, yann.tanguy
Version: 0.8.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
The model used to reproduced the issue.
none
Screenshot illustrating multiplicity with expressions none

Description Alain Le Guennec CLA 2011-11-17 11:47:04 EST 
Assume you have some integral constants defined in your model (as InstanceSpecifications specifying some LiteralInteger values),
and you want to reuse such constants when expressing multiplicity contraints for MultiplicityElements such as association ends.
For instance, there could be a constant N = 10,
and an association end with multiplicity "N..N" (or just "N"),
to avoid hardcoding the literal everywhere.

It seems that the multiplicity parser used in the property page for multiplicity elements is not able to resolve names of in-scope instance specifications to build corresponding value specifications (ie instance values referring to the instance specifications).
The parser seems to be capable of handling only integer literals.

Using the "Advanced" property tab and the model explorer creation commands, I was able to build the "lowerValue" and "upperValue" manually so that the multiplicity is actually "N..N" in the model, but this is not possible by just entering "N..N" in the text field for the multiplicity, and this is not reflected in the text field (it still displays "1") nor on the diagram.

See attached model and screenshot for details.
Comment 1 Alain Le Guennec CLA 2011-11-17 11:48:20 EST 
Created attachment 207157 [details]
The model used to reproduced the issue.
Comment 2 Alain Le Guennec CLA 2011-11-17 11:52:20 EST 
Created attachment 207158 [details]
Screenshot illustrating multiplicity with expressions
Comment 3 Yann Tanguy CLA 2011-11-21 08:48:53 EST 
Diagram support is incorrect because the test comparing current multiplicity to UML default (relates to the "Show default multiplicity" option). The test uses MultiplicityElement#/lower et /upper which always return an integer, whatever the upperValue and lowerValue, and in particular always return 1 when upper and lower cannot be interpreted as integers. The test shall be done using current lowerValue and upperValue directly.

Done in r6263 (0.9.X) and r6264 (trunk).

Property view support style to be added.
Comment 4 Yann Tanguy CLA 2011-11-21 09:27:40 EST 
Assume default multiplicity when no lowerValue and upperValue (null) are given.
Done in r6266 (0.8.X) and r6267 (trunk).