Issue 13930: Validator issues with TestCase 2 (uml2-rtf) Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: looked at the 7 OCL constraint failures reported in Test Case 2. There are 5 different kinds of constraints that failed. In summary I found: - In 2 of these it appears that the model, valid.xmi, is wrong. - In 2 the OCL is wrong. One can be fixed. The other should be removed from the UML spec. - In 1 I made a mistake when correcting an unrelated problem in the OCL. I'll update the Validator. If my conclusions below are correct, someone should update valid.xmi too. Details below: (Model 'TestCase2') Summary of Model Content: Total objects: 94. UML objects: 94 SysML objects: 0 The model: <uml:Model TestCase2, id=1> Object Inventory Summary of Warnings: * Referent not found: 0 * Unresolved URI used for object identification: 0 * Set members not unique: 0 * Missing mandatory value: 0 * No class with name specified: 0 * Property not found: 0 * Cannot infer class of object: 0 * Multiplicity violation: 0 * Type violation: 0 * Invalid stereotype application: 0 * No object for stereotyping: 0 * Creation of abstract class: 0 * OCL constraint violation: 7 <================ * OCL execution errors: 3 * OCL errors while evaluating derived attribute: 0 * OCL errors due to missing derived attribute specifications: 315 * Identical XMI attribute xmi:id used by multiple XML elements: 0 * Expected a uml:PrimitiveType: 0 * XMI attribute xmi:id references excessive space chars: 0 OCL constraint violation (7) There are 5 variations of this error: 1 instances of this: The constraint Property.redefined_property_inherited() was violated. View Instance 1 2 instances of this: The constraint NamedElement.has_no_qualified_name() was violated. View Instance 1 1 instances of this: The constraint Constraint.value_specification_boolean() was violated. View Instance 1 1 instances of this: The constraint Interface.visibility() was violated. View Instance 1 2 instances of this: The constraint RedefinableElement.redefinition_context_valid() was violated. View Instance 1 The constraint Property.redefined_property_inherited() was violated. This one on instance 84, a Property named "redefiningProperty" The constraint is: redefinedProperty->notEmpty() implies redefinitionContext->notEmpty() and redefinedProperty->forAll(rp|redefinitionContext-> collect(fc | fc.allParents())->asSet()-> collect(c| c.allFeatures())->asSet()->includes(rp)) ... 84.redefinedProperty is not empty, but 84.redefinitionContext is empty. In as far as this constraint is what was intended, the validator is doing the right thing. The file should specify a redefinition context. If you believe the contraint or my conclusion is incorrect, let me know. Otherwise, shall I'll write an issue against the testcase? The constraint Interface.visibility() was violated. This one on instance 29: The constraint is: self.feature->forAll(f | f.visibility = #public) self.feature contains one instance, named "operation1", and its visibility is not set. In as far as this constraint is what was intended, the validator is doing the right thing. If you believe the constraint or my conclusion is incorrect, let me know. The constraint NamedElement.has_no_qualified_name() was violated. This one is my mistake. I corrected an error in the derivation of qualified names, and in an unrelated act, placed that "self.name" text before the endif below. It was Set{} and should be Set{}. I'll fix the OCL in Validator and put out a new version. result = if self.name->notEmpty() and self.allNamespaces()->select(ns | ns.name->isEmpty())->isEmpty() then self.allNamespaces()->iterate( ns : Namespace; result : String = self.name | ns.name.concat(self.separator()).concat(result)) else self.name endif <=== should be Set{} The constraint Constraint.value_specification_boolean() was violated. The constraint is: self.specification.booleanValue().oclIsKindOf(Boolean) The function booleanValue(): result = value It looks like this intends to perform runtime evaluation of the OCL string in the specification property (which should more accurately be specification.body, anyway). Technically, I could do this, but there is no way to describe the evaluation in OCL, and I wouldn't really want to execute arbitrary code on my server. I will mark this OCL as an error, and have it return True. This OCL should be removed from the UML spec. The constraint RedefinableElement.redefinition_context_valid() was violated. After some digging I found that the definition of isRedefinitionContextValid, which is called by this was: redefinitionContext-> exists(c | c.allParents()-> includes(redefined.redefinitionContext)) But redefined.redefinitionContext is a Collection, so the use of includes here is not correct. It should be: redefinitionContext-> exists(c | c.allParents()-> oclIntersection(redefined.redefinitionContext)->notEmpty()) Things work fine with this correction. Resolution: Revised Text: Actions taken: May 12, 2009: received issue Discussion: End of Annotations:===== ted-NM: yes From: "Nerijus Jankevicius" To: "model interchange" Cc: , "Juergen Boldt" Subject: Re: FW: Validator issues with TestCase 2 Date: Thu, 14 May 2009 17:50:16 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 btw, Parameter direction kind default value is not defined in UML metamodel also (I mean abstract syntax diagrams in the spec). It is "in" in the text only. However, it is defined in MOF files. I'm sure Figure 7.10 - Features diagram of the Kernel package must be fixed by adding "=in" to direction. Juergen, please register this issue. Nerijus ----- Original Message ----- From: Ed Seidewitz To: James Bruck Cc: model interchange Sent: Wednesday, May 13, 2009 9:52 PM Subject: RE: FW: Validator issues with TestCase 2 Perhaps this can just be handled under the existing issue of the default visibility for PackageableElement (which would make it more likely that the current RTF would address it.). -- Ed -------------------------------------------------------------------------------- From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Wednesday, May 13, 2009 2:03 PM To: Ed Seidewitz Cc: model interchange Subject: Re: FW: Validator issues with TestCase 2 Should we perhaps raise an RTF issue and request that the default visibility be "public" for NamedElement? - James. "Ed Seidewitz" 13/05/2009 01:42 PM To "model interchange" cc Subject FW: Validator issues with TestCase 2 I meant to admit my mistake to the whole group. -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Wednesday, May 13, 2009 10:12 AM To: Nerijus Jankevicius Subject: Re: Validator issues with TestCase 2 Oops! Sorry, you are right! That's what I get for commenting without paying close attention... Sent from my iPhone On May 13, 2009, at 9:52 AM, "Nerijus Jankevicius" wrote: Ed, Operation is not PackageableElement. Nerijus ----- Original Message ----- From: Ed Seidewitz To: model interchange Sent: Wednesday, May 13, 2009 9:32 AM Subject: RE: Validator issues with TestCase 2 Well, NamedElement::visibility does not have a default, but PackageableElement (which Operation is a kind of) redefines visibility so that it has a default. Actually, the spec says the default is .false., which, of course, doesn.t make sense (see OMG Issue 10379). However, the latest RTF 2.3 discussion on this is that the default for PackageableElement::visibility should be .public.. -- Ed -------------------------------------------------------------------------------- From: Peter Denno [mailto:peter.denno@nist.gov] Sent: Tuesday, May 12, 2009 2:49 PM To: Nerijus Jankevicius Cc: James Bruck; model interchange Subject: Re: Validator issues with TestCase 2 Nerijus Jankevicius wrote: the default visibility of NamedElement is not defined, at least in UML metamodel (I didn't checked all the text, abstract syntax only). We have some problems to load undefined visibility also. Agreed. I just looked at the metamodel XMI, and I don't see a default for NamedElement.visibility. And I cannot find it in the validator's processing of the meta-model: http://syseng.nist.gov/se-interop/class-view?class=type*UML*NamedElement&open-slots=slot*UML*visibility*UML*NamedElement&examples=2#visibility But if I look on that page, I see the "Editor's Note" that I wrote for the constraint visibility_needs_ownership, and it reads: "visibility has default value #public, making this fail whenever namespace is not specified." I'm guessing that comment was made against an older version of UML, in which the default was public. - Peter Nerijus ----- Original Message ----- From: James Bruck To: Peter Denno Cc: model interchange Sent: Tuesday, May 12, 2009 6:35 PM Subject: Re: Validator issues with TestCase 2 Hi Peter, In terms of the visibility of operation1 on the interface, I believe that the default visibility is "public" and it was therefore not explicitly serialized. Should the validator take such defaults into account? Cheers, - James. Peter Denno 12/05/2009 11:12 AM To model interchange cc Subject Validator issues with TestCase 2 Hi MIWGers, I looked at the 7 OCL constraint failures reported in Test Case 2. There are 5 different kinds of constraints that failed. In summary I found: - In 2 of these it appears that the model, valid.xmi, is wrong. - In 2 the OCL is wrong. One can be fixed. The other should be removed from the UML spec. - In 1 I made a mistake when correcting an unrelated problem in the OCL. I'll update the Validator. If my conclusions below are correct, someone should update valid.xmi too. Details below: (Model 'TestCase2') Summary of Model Content: Total objects: 94. UML objects: 94 SysML objects: 0 The model: Object Inventory Summary of Warnings: * Referent not found: 0 * Unresolved URI used for object identification: 0 * Set members not unique: 0 * Missing mandatory value: 0 * No class with name specified: 0 * Property not found: 0 * Cannot infer class of object: 0 * Multiplicity violation: 0 * Type violation: 0 * Invalid stereotype application: 0 * No object for stereotyping: 0 * Creation of abstract class: 0 * OCL constraint violation: 7 <================ * OCL execution errors: 3 * OCL errors while evaluating derived attribute: 0 * OCL errors due to missing derived attribute specifications: 315 * Identical XMI attribute xmi:id used by multiple XML elements: 0 * Expected a uml:PrimitiveType: 0 * XMI attribute xmi:id references excessive space chars: 0 OCL constraint violation (7) There are 5 variations of this error: 1 instances of this: The constraint Property.redefined_property_inherited() was violated. View Instance 1 2 instances of this: The constraint NamedElement.has_no_qualified_name() was violated. View Instance 1 1 instances of this: The constraint Constraint.value_specification_boolean() was violated. View Instance 1 1 instances of this: The constraint Interface.visibility() was violated. View Instance 1 2 instances of this: The constraint RedefinableElement.redefinition_context_valid() was violated. View Instance 1 The constraint Property.redefined_property_inherited() was violated. This one on instance 84, a Property named "redefiningProperty" The constraint is: redefinedProperty->notEmpty() implies redefinitionContext->notEmpty() and redefinedProperty->forAll(rp|redefinitionContext-> collect(fc | fc.allParents())->asSet()-> collect(c| c.allFeatures())->asSet()->includes(rp)) ... 84.redefinedProperty is not empty, but 84.redefinitionContext is empty. In as far as this constraint is what was intended, the validator is doing the right thing. The file should specify a redefinition context. If you believe the contraint or my conclusion is incorrect, let me know. Otherwise, shall I'll write an issue against the testcase? The constraint Interface.visibility() was violated. This one on instance 29: The constraint is: self.feature->forAll(f | f.visibility = #public) self.feature contains one instance, named "operation1", and its visibility is not set. In as far as this constraint is what was intended, the validator is doing the right thing. If you believe the constraint or my conclusion is incorrect, let me know. The constraint NamedElement.has_no_qualified_name() was violated. This one is my mistake. I corrected an error in the derivation of qualified names, and in an unrelated act, placed that "self.name" text before the endif below. It was Set{} and should be Set{}. I'll fix the OCL in Validator and put out a new version. result = if self.name->notEmpty() and self.allNamespaces()->select(ns | ns.name->isEmpty())->isEmpty() then self.allNamespaces()->iterate( ns : Namespace; result : String = self.name | ns.name.concat(self.separator()).concat(result)) else self.name endif <=== should be Set{} The constraint Constraint.value_specification_boolean() was violated. The constraint is: self.specification.booleanValue().oclIsKindOf(Boolean) The function booleanValue(): result = value It looks like this intends to perform runtime evaluation of the OCL string in the specification property (which should more accurately be specification.body, anyway). Technically, I could do this, but there is no way to describe the evaluation in OCL, and I wouldn't really want to execute arbitrary code on my server. I will mark this OCL as an error, and have it return True. This OCL should be removed from the UML spec. The constraint RedefinableElement.redefinition_context_valid() was violated. After some digging I found that the definition of isRedefinitionContextValid, which is called by this was: redefinitionContext-> exists(c | c.allParents()-> includes(redefined.redefinitionContext)) But redefined.redefinitionContext is a Collection, so the use of includes here is not correct. It should be: redefinitionContext-> exists(c | c.allParents()-> oclIntersection(redefined.redefinitionContext)->notEmpty()) Things work fine with this correction. -- Best regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8265 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8265 FAX: +1 301-975-4694 -- Best regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8265 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8265 FAX: +1 301-975-4694