Issues for Mailing list of the Semantics of a Foundational Subset for Executable UML Models 1.1 (fUML) RTF

To comment on any of these issues, send email to fuml-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 13166: Section: Base Semantics
Issue 13510: 7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance
Issue 14979: Annex on normative XMI for fUML
Issue 15383: fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2
Issue 15988: The fUML subset should include central buffer nodes and data stores
Issue 15989: The fUML subset shuold support the raising and handling of exceptions
Issue 18279: ReclassifyObjectAction does not preserve structural feature values
Issue 18280: LoopNodeActivation does not correctly handle the firing of a contained activity final node
Issue 18282: The bodyOutputLists for a loop node need to be cleared when the node fires again
Issue 18321: Certain Boolean flags are not properly initialized in some cases
Issue 18362: Problem with ActivityExecution::terminate
Issue 18364: RealValue::toString puts too many digits in the mantissa
Issue 18365: Objects with cyclic references cannot be converted to string representations
Issue 18508: FoundationModelLibrary, UnlimitedNaturalFunctions: inconsistencies between the spec and the normative xmi
Issue 18510: ListFunctions should have a ListConcat behavior
Issue 18511: The ReadLine::result parameter should have direction "return"
Issue 18512: FoundationalModelLibrary::Common::Notification should be public
Issue 18513: The Listener reception of Notification should have a name
Issue 18514: The types of the ReadLine::errorStatus and WriteLine::errorStatus parametres should be Status
Issue 18529: Feature values need to be created for private structural features of parent classifiers
Issue 18693: ReclassifyObjectAction handles removal of structural features incorrect
Issue 18714: RemoveStructuralFeatureValueActionActivation: Determination of position(s) of value to be removed results in inf. loop
Issue 18721: RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value
Issue 18722: RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly
Issue 18794: Defects in Base Semantics from fUML
Issue 18795: Computer-readable version of the Base Semantics
Issue 18796: Base Semantics PSL version
Issue 18797: Actions outside the bUML
Issue 18798: Cover all ActivityNodes used in bUML
Issue 18799: Remove unneeded inference rules from Base Semantics
Issue 18800: Correction of method UnlimitedNaturalValue.equals

Issue 13166: Section: Base Semantics (fuml-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
SendSignalAction completion semantics. SendSignalAction shouldn't require the event pool to be updated before the action completes.

Resolution: Resolution: 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
Revised Text:
Actions taken:
December 18, 2008: received issue
January 7, 2013: deferred

Issue 13510: 7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance (fuml-rtf)

Click
here for this issue's archive.
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: 2 (Conformance)

 

Since fUML is a subset of the UML, there are two possible kinds of syntactic conformance issues:

 

a)      Checking whether an M1 model written in a superset of fUML (e.g., the UML) conforms to the fUML subset.

b)      Checking whether an M2 extension of fUML (e.g., SysML, UML) complies with the fUML subset

 

Proposed resolution:

 

1)      Clarify the meaning of the confusing terminology:

 

-          Syntactic conformance is a criteria for M1 models, i.e., (a) above.

-          Syntactic compliance is a criteria *relative* to a compliance level of an M2 metamodel, i.e. (b) above or to a package unit defined in an M2 metamodel.

 

This proposed resolution is consistent with the current terminology of compliance levels for metamodels including fUML, UML, UML4SysML, etc…

 

2)      Distinguish in the specification document conformance vs. compliance constraints.

 

For example, per 12.3.34 of the UML 2.2, a JoinNode as a required ValueSpecification:

 

JointNode::joinSpec : ValueSpecification[1..1] with a default value: “and”

 

Clearly, the fUML subset does not support M1 models with a JointNode whose joinSpec is anything except  the default “and” value specification.  This is an M1 conformance constraint that can be specified in OCL.

 

Extensions of fUML such as the UML itself should not have this constraint because it is not a compliance requirement for any extension of fUML such as the UML which specifically allows join specification values other than “and”.

 

Compliance constraints should be constraints that fUML and any M2 extension of fUML satisfy.

 

Conformance constraints are more restrictive; they specify how to verify that an M1 model written in a given superset of fUML (e.g., UML) is still within the fUML subset.

 

7.4.2.2.12 JoinNode

 

Add a comformance constraint:

 

[1] conformance relative to UML::Activities::CompleteActivities (unmerged) or to UML L3 (merged)

-- The join specification must be “and”

self.joinSpec.oclIsTypeOf(LiteralString) and self.joinSpec.oclAsType(LiteralString).value = 'and'

Resolution: 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
Revised Text:
Actions taken:
February 18, 2009: received issue
January 7, 2013: deferred

Discussion:


Issue 14979: Annex on normative XMI for fUML (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 2 (ptc/09-10-05)

 

The specification should have an annex describing the normative serialization of the fUML syntax, semantics and foundational library models, similar to Annexes G and H of the UML 2.3 superstructure specification.


Resolution:
Revised Text:
Actions taken:
January 15, 2010: received issue
January 7, 2013: deferred

Discussion:
Resolution:
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


Issue 15383: fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2 (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2, it states that:

 

The empty-output-parameter-node relation ensures executions of expansion region action (the xac variable) transfer values from an output parameter node of the executions of the constructed activity (xcall) to the corresponding output pin of the expansion region (op). It assumes output pin multiplicity upper (opmax) is one or unlimited. This does not put null tokens in output pins when output parameter nodes are empty, as in UML.

 

The final sentence is no longer consistent with the fUML operational semantics given in the execution model, which was updated by the resolution of Issue 14550 to offer a null token from an output pin if it holds no values when it fires.



 


Resolution: The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification. Revised Text: None Disposition: Deferred
Revised Text:
Actions taken:
July 27, 2010: received issue
January 7, 2013: deferred

Issue 15988: The fUML subset should include central buffer nodes and data stores (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14)

 

Unlike pins, the tokens in central buffer nodes and data stores (which are kind of central buffer node) are not consumed when they are accessed. This allows a value to be, e.g., stored in a data store and used repeatedly in a loop that is modeled directly using flows rather than using a loop node. It is more common to create loops using flows than structured nodes when drawing graphical activity diagrams, and fUML should provide reasonable execution semantics for such models using central buffer nodes and data stores.


Resolution: The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification. Revised Text: None Disposition: Deferred
Revised Text:
Actions taken:
January 26, 2011: received issue
January 7, 2013: deferred

Discussion:


Issue 15989: The fUML subset shuold support the raising and handling of exceptions (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14)

 

The submission team for the Alf action language felt that is was important that the action language be able to support exceptions, since existing class models in UML may include operations that raise exceptions and it should be possible to use the action language to specify methods for such operations without having to change how errors are reported. However, without exceptions being included in the fUML subset, the mapping of the raising and handling of exceptions in the action language to fUML was too complicated and probably semantically questionable.

 

Therefore, support for the raising and handling of exceptions should be included in the fUML subset so that it can properly be included in the surface action language notation.



Resolution: The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification. Revised Text: None Disposition: Deferred
Revised Text:
Actions taken:
January 26, 2011: received issue
January 7, 2013: deferred

Issue 18279: ReclassifyObjectAction does not preserve structural feature values (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 (ptc/2012-10-18)

Subclause: 8.6.4.2.5 ReclassifyObjectActionActivation

 

The UML 2.4.1 specification says, in Subclause 11.3.39, under the Semantics for ReclassifyObjectAction, that "'New' classifiers replace existing classifiers in an atomic step, so that structural feature values and links are not lost during the reclassification, when the 'old' and 'new' classifiers have structural features and associations in common." However, the behavior specified in ReclassifyObjectActionActivation does not act this way. Instead, all feature values for old classifiers are removed before the feature values for new classifiers are added, so any values for common structural features are lost.


Resolution:
Revised Text:
Actions taken:
November 23, 2012: received issue

Issue 18280: LoopNodeActivation does not correctly handle the firing of a contained activity final node (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 RTF Beta (ptc/2012-10-18)

Subclause: 8.5.3.2.3 LoopNodeActivation

 

When an ActivityFinalNode fires within a StructuredActivityNode (other than an ExpansionRegion), the ActivityFinalNodeActivation terminates the containing node activation by calling the terminateAll operation. This operation is specified in StructuredActivityNodeActivation to terminate all activations in the activation group for the structured node activation. As a result, none of these activations can fire any more, and the structured node activation as a whole eventually completes its firing. Note that the structured node itself does not terminate, since it can still fire again.

 

For a LoopNodeActivation, the call to TerminateAll will happen within a loop iteration. Terminating all activations in the loop node activation group will result in the body of the loop completing, resulting in the runBody operation to return from its call within the LoopNodeActivation::fire operation. The fire operation then checks whether the loop should continue. However, this only includes checking whether the loop node as a whole has terminated or been suspended. Neither of these will be the case if the firing of the loop was terminated due to an activity final node. As a result, the loop may be determined to continue, even though it should not.

 

What is necessary is to set a flag when LoopNodeActivation::terminateAll is called and to check this flag in the same conditionals in the fire that check isRunning and isSuspended. This flag also needs to be checked in the LoopNodeActivation::resume operation to prevent the loop from continuing on resumption if the firing has been terminated by an activity final node.

 

(Note also that there are two conditionals at the end of the fire operation as currently specified that use the “&&” operator, which is not allowed by the bUML subset as specified in Annex A.)


Resolution:
Revised Text:
Actions taken:
November 23, 2012: received issue

Issue 18282: The bodyOutputLists for a loop node need to be cleared when the node fires again (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 RTF Beta (ptc/2012-10-18)

Subclause: 8.5.3.2.3 LoopNodeActivation

 

The beginning of LoopNodeActivation::doStructuredActivity creates the bodyOutputLists for the firing of a loop node. However, it does not first clear any bodyOutputLists that may have been created on a previous firing of the loop node. This can result in an exception if a loop node fires repeatedly (for instance, if it is nested in another loop node), because there will be more body output lists than there are result pins.

 

(Also, the variables loopVariables and resultPins are no longer used within doStructuredActivity.)


Resolution:
Revised Text:
Actions taken:
November 26, 2012: received issue

Issue 18321: Certain Boolean flags are not properly initialized in some cases (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)

Subclauses: 8.5.2.2.4 ActivityNodeActivation, 8.6.2.2.1 ActionActivation and 8.6.4.2.1 AcceptEventActionActivation

 

The Boolean attributes ActivityNodeActivation::running, ActionActivation::firing and AcceptEventActionActivation::waiting are presumed to be initialized when instances of the respective classes are created. However, since fUML (and hence bUML) does not support default values, such initialization needs to be done explicitly. Unfortunately, there are times when this is not happening properly.

 

ActivityNodeActivation::running is set to false when an activity node activation is created by ActivityNodeActivationGroup::createNodeActivation. However, there are a couple of cases when activity node activations are created other than by usine this operation:

 

1. When an action has outgoing edges, an anonymous fork node activation is created for the corresponding action activation, to handle the implicit fork semantics for tokens offered on the outgoing edges. The running attribute of this fork node activation is not initialized when it is created. (It the run operation is called on the fork node activation when it’s corresponding action activation is run, but until then the running attribute of the fork node action is unitialized.)

 

2. Output pin activations are created in ExpansionRegionActivation::doStructuredActivity for the expansion activation groups of an expansion region activation. The ActivityNodeActivation::run operation is immediately called on each of these output pin activations, so that running is initialized to true in this case. Unfortunately, the call to add an output pin activations to the groupOutputs of an expansion activation group (the third set of such pin activations in an expansion activation group) erroneously constructs a new output pin activation, rather than adding  the one that has been properly initialized.

 

The attributes ActionActivation::firing and AcceptEventActionActivation::waiting are both set to false in the run operation of their respective classes. However, when an action is in the body of a loop node or conditional node clause, it is possible for isReady operation on the action activation to be called before the action activation is actually run. Since the isReady check for an action, in general, checks the firing attribute, and the isReady check for an accept event action checks the waiting attribute, if isReady is called before run, these attributes will not have been properly initialized. In addition, AcceptEventActionActivation::waiting is checked in AcceptEventActionActivation::terminate, and it will not have been initialized if an accept event action activation is terminated without ever having been run.

 

Resolution:
Revised Text:
Actions taken:
December 17, 2012: received issue

Issue 18362: Problem with ActivityExecution::terminate (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)

Subclauses: 8.5.2.2.2 ActivityExecution

 

The ActivityExecution::terminate operation calls terminateAll on the activationGroup for the activity execution. However, the activationGroup attribute is not set unless the execute operation has been called. If an activity is started asynchronously, then it will be instantiated as an activity execution within a classifier behavior execution, but, since this execution is asynchronous to the invoker of the activity, it is possible for the invoker to destroy (and so terminate) the activity instance before the activity execution is actually executed. That is, it is, in fact, possible for the terminate operation to be called on an activity execution without the execute operation ever having been called.

 

In order to avoid a possible error, the terminate operation should check that the activationGroup is not null before calling terminateAll on it.

 

Resolution:
Revised Text:
Actions taken:
December 30, 2012: received issue

Issue 18364: RealValue::toString puts too many digits in the mantissa (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 8.3.2.2.21 RealValue

 

The toString operation for RealValue is specified to determine the mantissa of a real number to 10  significant digits. It does this by scaling the (absolute value of) the real number and then converting it to an integer. Per the bUML representation in Annex B, the integer value is denoted as a Java int. Unfortunately, the upper bound of a Java int is 2,147,483,647, so some ten digit integers will overflow this value. While it is technically the UML semantics that apply to the specification here, via the Annex B mapping, not the Java semantics, it is still convenient (an intended) for the execution model operations to be able to run as Java methods, too. Therefore, it would be better to limit the mantissa to 9 digits rather than 10, so that the Java int representation of the mantissa never overflows.



Resolution:
Revised Text:
Actions taken:
January 5, 2013: received issue

Issue 18365: Objects with cyclic references cannot be converted to string representations (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 8.3.2.2.2 CompundValue

 

The CompoundValue::toString operation calls toString on each value of each featureValue of a compound value. If one of these values is a reference then Reference::toString operation calls toString on the referenced object. Thus, if two or more objects cyclically reference each other, calling toString on any one of them will result in an infinite recursion.

 


Resolution:
Revised Text:
Actions taken:
January 5, 2013: received issue

Issue 18508: FoundationModelLibrary, UnlimitedNaturalFunctions: inconsistencies between the spec and the normative xmi (fuml-rtf)

Click
here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr)
Nature: Clarification
Severity: Minor
Summary:
Foundational Model Library: There are inconsistencies between the fuml spec and the normative xmi regarding the two following opaque behaviors from the PrimitiveBehaviors::UnlimitedNaturalFunctions:


- ToInteger: the spec provides the following signature ‘ToInteger(x: UnlimitedNatural): Integer[0..1]’ (which is correct) while in the normative xmi (ptc/2012-10-21), the return type is UnlimitedNatural

- ToUnlimitedNatural: in the normative xmi, the type of the return parameter is UnlimitedNatural (which is correct), while the spec provides the following signature ‘ToUnlimitedNatural(x: String): Integer[0..1], Converts x to an Integer value.’

Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18510: ListFunctions should have a ListConcat behavior (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 9.2.6 List Functions

 

The FoundationalModelLibrary::PrimitiveBehaviors::ListFunctions currently includes only ListGet and ListSize behaviors. However, given only these functions and the other capabilities in fUML, it is very difficult (if not impossible) to concatenate two arbitrary lists. The ListFunctions package should have a primitive ListConcat behavior to perform this function.


Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18511: The ReadLine::result parameter should have direction "return" (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 9.4.2 Pre-defined ReadLine and WriteLine Behaviors

 

The definitions for ReadLine and WriteLine in Subclause 9.4.2 do not give the multiplicity and direction for the parameters of those activities. However, one would expect them to be consistent with the multiplicity and direction for the corresponding parameters of the TextInputChannel::readLine and TextOutputChannel::writeLine operations. This is indeed the case as given in the normative fUML_Library.xmi, except for the result parameter of the ReadLine, which has direction “out”, while the readLine operation result parameter has direction “return”.

 

Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18512: FoundationalModelLibrary::Common::Notification should be public (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 9.3 Common

 

As shown in Figure 9.3 of Subclause 9.3, the FoundationalModelLibrary::Common package includes a Notification signal used by the Listener active class. In the normative fUML_Library.xmi, Notification has a visibility of private. It should be public.


Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18513: The Listener reception of Notification should have a name (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 9.3 Common

 

The class FoundationalModelLibrary::Common::Listener has a reception for the signal Notification. However, in the normative fUML_Library.xmi, this reception has no name. It should have a name (preferably the same name as the signal), so it can be referenced as a  behavioral feature.


Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Issue 18514: The types of the ReadLine::errorStatus and WriteLine::errorStatus parametres should be Status (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 9.4.2 Pre-defined ReadLine and WriteLine Behaviors

 

Figures 9.5 and 9.6 in Subclause 9.4.2 show that the type of the errorStatus parameter of the ReadLine and WriteLine activities should be Status. However, in the normative fUML_Library.xmi, these parameters have no type.

Resolution:
Revised Text:
Actions taken:
February 27, 2013: received issue

Discussion:


Issue 18529: Feature values need to be created for private structural features of parent classifiers (fuml-rtf)

Click
here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
Subclause: 8.3.2.2.25 StructuredValue

 

The StructuredValue::createFeatureValues operation is described to “Create empty feature values for all structural features, direct and inherited, of the types of this structured value.” It does this by iterating through the members of all types of the given structured value, which includes inherited members. Unfortunately, structural values that are private members of parent classifiers are not inherited, but they also need to have feature values created in the structured value.

Resolution:
Revised Text:
Actions taken:
March 5, 2013: received issue

Issue 18693: ReclassifyObjectAction handles removal of structural features incorrect (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The ReclassifyObjectActionActivation class implements as a behavior that the newClassifiers are added to the type list of an object and the oldClassifiers are removed. But for the removed oldClassifiers, not the structural features of the oldClassifiers are removed but structural features which have as type set the oldClassifier (which is implemented in the operation CompoundValue.removeFeatureValues(Classifier)).
However, all structural features owned by the removed oldClassifier should be removed regardless of the type of the structural feature itself.

Resolution:
Revised Text:
Actions taken:
May 2, 2013: received issue

Issue 18714: RemoveStructuralFeatureValueActionActivation: Determination of position(s) of value to be removed results in inf. loop (fuml-rtf)

Click
here for this issue's archive.
Source: LieberLieber Software (Mrs. Tanja Mayerhofer, mayerhofer(at)big.tuwien.ac.at.)
Nature: Revision
Severity: Minor
Summary:
If a value of a structured value shall be removed and the isRemoveDuplicates flag of the RemoveStruturalFeatureValueAction is set to true or if the removeAt pin was null, the position(s) of the value to be removed are determined by calling the operation int WriteStructuralFeatureActionActivation.position(Value, ValueList, int). The problem is that the last found position is provided as startPosition for the next call of the position operation. Therefore this found position is found again and again in each call of the operation resulting in an infinite loop.


Resolution:
Replace the following operation call
j = this.position(inputValue, featureValue.values, j);
with
>>> j = this.position(inputValue, featureValue.values, j+1);
In line 113 (last statement in while loop of if (action.isRemoveDuplicates) clause) and 121 (last statement in while loop of else if (action.removeAt == null) clause).

Resolution:
Revised Text:
Actions taken:
May 14, 2013: received issue

Issue 18721: RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value (fuml-rtf)

Click
here for this issue's archive.
Source: LieberLieber Software (Mrs. Tanja Mayerhofer, mayerhofer(at)big.tuwien.ac.at.)
Nature: Clarification
Severity: Minor
Summary:
In the case a RemoveStructuralFeatureValueAction is used to remove a link, the provided input value is not taken into account but only the object owning the defined association end. However, the UML standard states: “If the feature is an association end, the semantics are the same as for destroying links, the participants of which are the object owning the structural feature and the value being removed.” Thus, only links between the provided object (object pin) and value (value pin) should be considered.


The following code could be a resolution to this issue:


public class RemoveStructuralFeatureValueActionActivation
                extends
                fUML.Semantics.Actions.IntermediateActions.WriteStructuralFeatureActionActivation {             
        
        public void doAction() {
                ...
                if (association != null) {
                        LinkList links = this.getMatchingLinks(association, feature, value);
                        
>>>                     if(inputValue != null) {
>>>                             Property oppositeEnd = this.getOppositeEnd(association, feature);
>>>                             LinkList linksMatchingInputValue = this.getMatchingLinks(association, oppositeEnd, inputValue);
>>>                             links = linksMatchingInputValue;
                        }
                        ...
        }
}

Resolution:
Revised Text:
Actions taken:
May 16, 2013: received issue

Issue 18722: RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly (fuml-rtf)

Click
here for this issue's archive.
Source: LieberLieber Software (Mrs. Tanja Mayerhofer, mayerhofer(at)big.tuwien.ac.at.)
Nature: Revision
Severity: Minor
Summary:
RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly


The while loop for finding the link with the position defined with the removeAt pin is implemented incorrectly. The loop variable is not correctly incremented.


The following code would be the resolution for this bug:


>>> while (notFound & i <= links.size()) {
        Link link = links.getValue(i - 1);
        if (link.getFeatureValue(feature).position == removeAt) {
                notFound = false;
                link.destroy();                                         
        }
>>>     ++i;
}

Resolution:
Revised Text:
Actions taken:
May 16, 2013: received issue

Issue 18794: Defects in Base Semantics from fUML (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
There were found 42 issues, 5 of them were enhancements proposals, and 37 were defects.

The main issues concerning defects were:
1.      The Base Semantics had a defect in the section 10.4.8.3 (pg. 383). There was missing a forall construction, which did not allow to parse entire definition.
2.      After applied the necessary remedy actions to the definition, a model finder (EPROVER) was used to check if the fUML definition together with PSL definition - psl_outer_core - was satisfiable. The fUML Base Semantics together with PSL was unsatisfiable. 
3.      A model finder (EPROVER) also was used to check if the Base Semantics alone (without PSL) was satisfiable. The fUML Base Semantics was unsatisfiable. 
 
I have been made available a file with all analyzed files at the following address:

http://es.cs.uni-kl.de/people/romero/fUMLOMGIssue20130630.zip

This file can help to recognize the defects.

Resolution:
Revised Text:
Actions taken:
June 30, 2013: received issue

Issue 18795: Computer-readable version of the Base Semantics (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
It should be made available a computer-readable version of the Base Semantics, as a CLF file. The place would be the OMG site where other files defined by this specification were available, such as, XML Metadata Interchange (XMI).

Resolution:
Revised Text:
Actions taken:
June 30, 2013: received issue

Issue 18796: Base Semantics PSL version (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Base Semantics should declare the PSL version used to define it.

Resolution:
Revised Text:
Actions taken:
June 30, 2013: received issue

Issue 18797: Actions outside the bUML (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
It should not define constraints for Actions outside the bUML: AcceptEventAction and ReadIsClassifiedObjectAction. In the other way around, it should be evaluated if these actions should be included in bUML. The java statement instanceof is used from page 98 to page 328, therefore the ReadIsClassifiedObjectAction should be added to bUML.
 

Resolution:
Revised Text:
Actions taken:
June 30, 2013: received issue

Issue 18798: Cover all ActivityNodes used in bUML (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
The specification should cover all ActivityNodes used in bUML. It should be added declarative definition for ActivityFinalNode because it is used in annex A.3.1, and A.3.2, pages 401, and 402. However, it should be evaluated the replacement of this node to FlowFinalNode. For the last, a proposal is defined

Resolution:
Revised Text:
Actions taken:
June 30, 2013: received issue

Issue 18799: Remove unneeded inference rules from Base Semantics (fuml-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Inference rules not used, and not needed for completeness, should be removed

Resolution:
Revised Text:
Actions taken:
June 30, 2013: received issue

Issue 18800: Correction of method UnlimitedNaturalValue.equals (fuml-rtf)

Click
here for this issue's archive.
Source: LieberLieber Software (Mrs. Tanja Mayerhofer, mayerhofer(at)big.tuwien.ac.at.)
Nature: Revision
Severity: Minor
Summary:
The method UnlimitedNaturalValue.equals compares if the two compared UnlimitedNaturalValue instances refer to the same instance of UnlimitedNatural:


isEqual = ((UnlimitedNaturalValue) otherValue).value.naturalValue == this.value.naturalValue;


Instead the integer values of the attribute "naturalValue" of the referenced UnlimitedNatural instances should be compared:


isEqual = ((UnlimitedNaturalValue) otherValue).value.naturalValue == this.value.naturalValue;

Alternatively the equals method could be overriden in the class UnlimitedNatural and called by the method UnlimitedNaturalValue.equals

Resolution:
Revised Text:
Actions taken:
July 3, 2013: received issue