Issue 13872: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add (fuml-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Specification: Semantics of a Foundation Subset for Executable UML Models, FTF – Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } Resolution: This issue seems to be a problem with a specific implementation of fUML, not with the fUML specification itself. The uniqueness of association ends is essentially a constraint that there are no duplicate values on that end. fUML only gives semantics to syntactically valide models for which all well-formedness constraints are satisfied, including implicit constraints like multiplicity and uniqueness, as well as constraints given explicitly in OCL. Any implementation that violates syntactic constraints when loading a model is simply an incorrect implementation. It is not necessary to further complicate the fUML semantic specification or the Java=>bUML mapping to account for this. Revised Text: None Disposition: Closed, No Change Revised Text: Actions taken: April 16, 2009: received issue January 7, 2013: closed issue Discussion: The FTF agrees that this is a problem that needs fixing but, due to lack of time, decided to defer its resolution to a future RTF working on this specification. Revised Text: None. Disposition: Deferred End of Annotations:===== m: "Rouquette, Nicolas F" To: "issues@omg.org" CC: Ed Seidewitz , "conrad.bock@nist.gov" , Scott Cinnamond Date: Thu, 16 Apr 2009 15:13:32 -0700 Subject: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Topic: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Index: Acm+4JPipPUFaZ+BRneXadWIb6ReLw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Specification: Semantics of a Foundation Subset for Executable UML Models, FTF . Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } - Nicolas. Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Date: Thu, 16 Apr 2009 18:25:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Index: Acm+4JPipPUFaZ+BRneXadWIb6ReLwAAW7mw From: "Ed Seidewitz" To: "Rouquette, Nicolas F" Cc: , "Juergen Boldt" Nicolas . This is not actually an FTF issue, since the operations on the syntax classes are not normative and are not included in the spec document. And the reference implementation is not an appropriate concern for the FTF. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 6:14 PM To: issues@omg.org Cc: Ed Seidewitz; conrad.bock@nist.gov; Scott Cinnamond Subject: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Specification: Semantics of a Foundation Subset for Executable UML Models, FTF . Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } - Nicolas. From: "Rouquette, Nicolas F" To: Ed Seidewitz CC: "conrad.bock@nist.gov" , Juergen Boldt Date: Thu, 16 Apr 2009 16:23:05 -0700 Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Topic: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Index: Acm+4JPipPUFaZ+BRneXadWIb6ReLwAAW7mwAAEbj5A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Ed, There are really two parts to this issue: - The duplication of activity edges on the node incoming/outgoing attributes which is an issue for the fuml reference implementation only. It is an issue because it presents a distorted view of what the abstract syntax model really is. - Many attributes in the fUML abstract syntax & execution model are specified as unique collections. However, most of the operations in both fUML.Semantics which add something into a collection use the java part of A.5.2 ListAdd. This means that it is possible for the execution engine to add an item to a unique collection twice. This is easily fixable but it will require going through all of the calls to the .*.addValue(.). methods in the execution model. - Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, April 16, 2009 3:26 PM To: Rouquette, Nicolas F Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Nicolas . This is not actually an FTF issue, since the operations on the syntax classes are not normative and are not included in the spec document. And the reference implementation is not an appropriate concern for the FTF. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 6:14 PM To: issues@omg.org Cc: Ed Seidewitz; conrad.bock@nist.gov; Scott Cinnamond Subject: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Specification: Semantics of a Foundation Subset for Executable UML Models, FTF . Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } - Nicolas. Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Date: Thu, 16 Apr 2009 19:28:27 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Index: Acm+4JPipPUFaZ+BRneXadWIb6ReLwAAW7mwAAEbj5AAARB7AA== From: "Ed Seidewitz" To: "Rouquette, Nicolas F" Cc: , "Juergen Boldt" Nicolas . Well, for the purposes of the specification, the meaning of addValue is defined by the mapping in Annex A . that is, it has UML semantics, not Java semantics. This means that it should respect uniqueness. The fact that the Java implementation of this doesn.t is just that . an implementation issue, not a specification issue. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 7:23 PM To: Ed Seidewitz Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Ed, There are really two parts to this issue: - The duplication of activity edges on the node incoming/outgoing attributes which is an issue for the fuml reference implementation only. It is an issue because it presents a distorted view of what the abstract syntax model really is. - Many attributes in the fUML abstract syntax & execution model are specified as unique collections. However, most of the operations in both fUML.Semantics which add something into a collection use the java part of A.5.2 ListAdd. This means that it is possible for the execution engine to add an item to a unique collection twice. This is easily fixable but it will require going through all of the calls to the .*.addValue(.). methods in the execution model. - Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, April 16, 2009 3:26 PM To: Rouquette, Nicolas F Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Nicolas . This is not actually an FTF issue, since the operations on the syntax classes are not normative and are not included in the spec document. And the reference implementation is not an appropriate concern for the FTF. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 6:14 PM To: issues@omg.org Cc: Ed Seidewitz; conrad.bock@nist.gov; Scott Cinnamond Subject: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Specification: Semantics of a Foundation Subset for Executable UML Models, FTF . Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } - Nicolas. From: "Rouquette, Nicolas F" To: Ed Seidewitz CC: "conrad.bock@nist.gov" , Juergen Boldt Date: Thu, 16 Apr 2009 16:46:58 -0700 Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Topic: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Index: Acm+4JPipPUFaZ+BRneXadWIb6ReLwAAW7mwAAEbj5AAARB7AAAARjzA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized I disagree; I believe that this issue is material to the FUML specification. Consider this: 8.3.2.2.2 CompoundValue::featureValues : FeatureValue[0..*] {unique} 8.3.2.2.8 FeatureValue::values : Value[0..*] {ordered} CompoundValue::featureValues.addValue(FeatureValue) should not have the same behavior as: FeatureValue::values.addValue(Value) The Java => bUML mapping considers these two cases to be applications of A.5.2 ListAdd. These two addValue() behaviors should be different. In fact, the difference seems to be missing as well in the CL axiomatization in clause 10 which has only one kind of non-unique collection, a Sequence (10.3.1.3). As it stands, we cannot represent CompoundValue::featureValues in terms of the axiomization in clause 10 unless we start adding a bunch of extra axioms to handle the unicity constraint of CompoundValue::featureValues. - Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, April 16, 2009 4:28 PM To: Rouquette, Nicolas F Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Nicolas . Well, for the purposes of the specification, the meaning of addValue is defined by the mapping in Annex A . that is, it has UML semantics, not Java semantics. This means that it should respect uniqueness. The fact that the Java implementation of this doesn.t is just that . an implementation issue, not a specification issue. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 7:23 PM To: Ed Seidewitz Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Ed, There are really two parts to this issue: - The duplication of activity edges on the node incoming/outgoing attributes which is an issue for the fuml reference implementation only. It is an issue because it presents a distorted view of what the abstract syntax model really is. - Many attributes in the fUML abstract syntax & execution model are specified as unique collections. However, most of the operations in both fUML.Semantics which add something into a collection use the java part of A.5.2 ListAdd. This means that it is possible for the execution engine to add an item to a unique collection twice. This is easily fixable but it will require going through all of the calls to the .*.addValue(.). methods in the execution model. - Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, April 16, 2009 3:26 PM To: Rouquette, Nicolas F Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Nicolas . This is not actually an FTF issue, since the operations on the syntax classes are not normative and are not included in the spec document. And the reference implementation is not an appropriate concern for the FTF. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 6:14 PM To: issues@omg.org Cc: Ed Seidewitz; conrad.bock@nist.gov; Scott Cinnamond Subject: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Specification: Semantics of a Foundation Subset for Executable UML Models, FTF . Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } - Nicolas. Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Date: Thu, 16 Apr 2009 20:43:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Thread-Index: Acm+4JPipPUFaZ+BRneXadWIb6ReLwAAW7mwAAEbj5AAARB7AAAARjzAAAJp/9A= From: "Ed Seidewitz" To: "Rouquette, Nicolas F" Cc: , "Juergen Boldt" OK, let.s go ahead and get this filed as an issue, and we can discuss it in the context of the full FTF. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 7:47 PM To: Ed Seidewitz Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add I disagree; I believe that this issue is material to the FUML specification. Consider this: 8.3.2.2.2 CompoundValue::featureValues : FeatureValue[0..*] {unique} 8.3.2.2.8 FeatureValue::values : Value[0..*] {ordered} CompoundValue::featureValues.addValue(FeatureValue) should not have the same behavior as: FeatureValue::values.addValue(Value) The Java => bUML mapping considers these two cases to be applications of A.5.2 ListAdd. These two addValue() behaviors should be different. In fact, the difference seems to be missing as well in the CL axiomatization in clause 10 which has only one kind of non-unique collection, a Sequence (10.3.1.3). As it stands, we cannot represent CompoundValue::featureValues in terms of the axiomization in clause 10 unless we start adding a bunch of extra axioms to handle the unicity constraint of CompoundValue::featureValues. - Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, April 16, 2009 4:28 PM To: Rouquette, Nicolas F Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Nicolas . Well, for the purposes of the specification, the meaning of addValue is defined by the mapping in Annex A . that is, it has UML semantics, not Java semantics. This means that it should respect uniqueness. The fact that the Java implementation of this doesn.t is just that . an implementation issue, not a specification issue. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 7:23 PM To: Ed Seidewitz Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Ed, There are really two parts to this issue: - The duplication of activity edges on the node incoming/outgoing attributes which is an issue for the fuml reference implementation only. It is an issue because it presents a distorted view of what the abstract syntax model really is. - Many attributes in the fUML abstract syntax & execution model are specified as unique collections. However, most of the operations in both fUML.Semantics which add something into a collection use the java part of A.5.2 ListAdd. This means that it is possible for the execution engine to add an item to a unique collection twice. This is easily fixable but it will require going through all of the calls to the .*.addValue(.). methods in the execution model. - Nicolas. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, April 16, 2009 3:26 PM To: Rouquette, Nicolas F Cc: conrad.bock@nist.gov; Juergen Boldt Subject: RE: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Nicolas . This is not actually an FTF issue, since the operations on the syntax classes are not normative and are not included in the spec document. And the reference implementation is not an appropriate concern for the FTF. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, April 16, 2009 6:14 PM To: issues@omg.org Cc: Ed Seidewitz; conrad.bock@nist.gov; Scott Cinnamond Subject: FUML: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Specification: Semantics of a Foundation Subset for Executable UML Models, FTF . Beta 1 (ptc/08-11-03) Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add Summary: The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification. Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}. This creates a problem in several places where fUML class attributes are defined to be unique; in particular: 7.4.2.2.2 ActivityEdge::source {unique} 7.4.2.2.2 ActivityEdge::target {unique} 7.4.2.2.4 ActivityNode::incoming {unique} 7.4.2.2.4 ActivityNode::outgoing {unique} The fUML reference implementation [1] loads an fUML model by CMOF reflection. This means that it processes each activity edge in three parts: 1. The activity node at the source of the edge 2. The activity node at the target of the edge 3. The edge itself #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node. #2 and #3 lead to a duplication of the same edge on the incoming list of the target node. [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation Proposed resolution: The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML. The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows: public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) { this.target = target; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (!target.incoming.contains(this)) { target.incoming.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); } } public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) { this.source = source; /** * NFR 04/15/2009 * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI, * it turns out that activity edges get a duplication of their source pins because: * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance. * - a second time this ActivityEdge is constructed by reflection. */ if (! source.outgoing.contains(this)) { source.outgoing.addValue(this); } else { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); } } - Nicolas.