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.
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'
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: 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
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.
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.
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.
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.
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.)
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.)
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.
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.
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.
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.
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.’
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.
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”.
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.
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.
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.
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.
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.
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).
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;
}
...
}
}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;
}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.
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).
Base Semantics should declare the PSL version used to define it.
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.
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
Inference rules not used, and not needed for completeness, should be removed
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