Issue 4907: Enforcement of multiplicity (action-semantics-ftf) Source: International Business Machines (Mr. Sridhar Iyengar, siyengar@us.ibm.com) Nature: Uncategorized Issue Severity: Summary: [Sridhar Iyengar] 20. In a number of places in the spec (see Page 2-261, para 3 for an example, Page 2-266 314 next to last paragraph...) , the following statement 20. In a number of places in the spec (see Page 2-appears "The semantics of adding a value that violates the multiplicity of an attribute is undefined". Why did the submitters not choose to treat this event as a violation of well formedness rules and raise an exception (for example by invoking an exceptionAction)? For vendors that implement UML tools that implement these constraints, it would be better if the semantics of actions handles these violations consistently. At some point in time when enough tools implement the Action Semantics spec issues such as these will become more important for interoperability reasons. Imagine a programming language interface (MOF 2 IDL or JMI) used to manipulate a UML metamodel server which has been extended to support the Actions package. It would be good if conformant client implementations treated multiplicity violations consistently. (the fact that the spec leaves this undefined is one way to be consistent I suppose!). Should the spec reviewer assume that for those parts of the spec where the semantics is explicitly marked as undefined, we should raise a red flag for modelers using these capabilities because those models 'may not be executable'? See also Page 2-266, next to last para. 'creating a link that violates 20. In a number of places in the spec (see Page 2-maximum multiplicities has undefined semantics'.. 'modeler must determine when minimum multiplicity associations should be enforced'. There isn't a standard way (I know of), this can be done consistently in UML. May be this will get sorted out as part of UML2 as part of the OCL Metamodel RFP. Multiplicity constraints are very popular in UML and we should look at providing some clear guidelines of when and how these (and other constraints) are checked or ignored in UML. Finally in Page 128 of revised submission the following text "When a semantic variation point' is mentioned. 24. ClearAssociationAction class. I suggest that handling multiplicity be a semantic variation point as opposed to making the arbitrary choice that minimum muliplicity be violated when links of the association in which the object participats is destroyed.This could for example be handled by tags that can be customized (preferably at the package level) to (a) ignore multiplciity constraints (b) enforce them and raise an exception if the constraint is violated. I did notice the the choice to ignore minimum multiplicity is being consistently made - so this will minimize confusion. Resolution: Decline Revised Text: Actions taken: March 5, 2002: received issue December 11, 2002: closed issue Discussion: UML in general does not specify when constraints are enforced or what happens when they are violated. It is not in FTF scope to change this. End of Annotations:===== Summary: Enforcement of multiplicity Text: [Sridhar Iyengar] 20. In a number of places in the spec (see Page 2-261, para 3 for an example, Page 2-266 314 next to last paragraph...) , the following statement 20. In a number of places in the spec (see Page 2-appears "The semantics of adding a value that violates the multiplicity of an attribute is undefined". Why did the submitters not choose to treat this event as a violation of well formedness rules and raise an exception (for example by invoking an exceptionAction)? For vendors that implement UML tools that implement these constraints, it would be better if the semantics of actions handles these violations consistently. At some point in time when enough tools implement the Action Semantics spec issues such as these will become more important for interoperability reasons. Imagine a programming language interface (MOF 2 IDL or JMI) used to manipulate a UML metamodel server which has been extended to support the Actions package. It would be good if conformant client implementations treated multiplicity violations consistently. (the fact that the spec leaves this undefined is one way to be consistent I suppose!). Should the spec reviewer assume that for those parts of the spec where the semantics is explicitly marked as undefined, we should raise a red flag for modelers using these capabilities because those models 'may not be executable'? See also Page 2-266, next to last para. 'creating a link that violates 20. In a number of places in the spec (see Page 2-maximum multiplicities has undefined semantics'.. 'modeler must determine when minimum multiplicity associations should be enforced'. There isn't a standard way (I know of), this can be done consistently in UML. May be this will get sorted out as part of UML2 as part of the OCL Metamodel RFP. Multiplicity constraints are very popular in UML and we should look at providing some clear guidelines of when and how these (and other constraints) are checked or ignored in UML. Finally in Page 128 of revised submission the following text "When a semantic variation point' is mentioned. 24. ClearAssociationAction class. I suggest that handling multiplicity be a semantic variation point as opposed to making the arbitrary choice that minimum muliplicity be violated when links of the association in which the object participats is destroyed.This could for example be handled by tags that can be customized (preferably at the package level) to (a) ignore multiplciity constraints (b) enforce them and raise an exception if the constraint is violated. I did notice the the choice to ignore minimum multiplicity is being consistently made - so this will minimize confusion.