Bug 581554 - Conflated {unique} and {id} constraints
Summary: Conflated {unique} and {id} constraints
Status: UNCONFIRMED
Alias: None
Product: Papyrus
Classification: Modeling
Component: Diagram (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-20 11:41 EST by Anthony Simons CLA
Modified: 2023-02-20 11:41 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Simons CLA 2023-02-20 11:41:04 EST
I am using standalone Papyrus 
Version: 2022-12 (4.26) 
Build id: 2022-12-15T14:23:43Z

This report concerns a subtlety in the correct usage of UML constraints, and the possible conflation of the meanings of {unique} and {id} in the Papyrus tool.

In the Papyrus class diagram editor, attribute properties may be declared {unique} - the default setting - and this seems to be the only way to mark any kind of unique identifying property.  I cannot find {id} anywhere.

The UML {unique} constraint strictly applies to collections, not attributes (viz. the constraints {unique, ordered} together specify all four OCL collection types), and {unique} means that every element of a collection is unique (it is a set, not a bag).  If applied to an attribute, I infer the meaning that every instance of the class has a unique value for this attribute (viz. it is a candidate key).

It should be possible instead to specify the UML constraint {id} on one or more attributes of the same class, to indicate that these attributes participate in a (possibly compound) primary key.  I cannot find a way to do this in the Papyrus CD editor without violating EMF syntax check constraints.  

Being able to specify {id} would be more useful, and more general, than specifying {unique}.  Supporting only {unique} and not {id} rules out the possibility of compound keys; and in any case {unique} describes a candidate key (a field that could, but need not, be chosen to represent the primary key if there are other candidates).

This is a subtle point of UML modelling that took me years to figure out; and I hope that I have made this point clear.  It would be great if Papyrus could support {id} in the sense described.