FUML11 — 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

.

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

7.4.2.2.4 ActivityNode::incoming

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))

else

}

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))

else

}

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