Issues for Semantics of a Foundational Subset for Executable UML Models 1.3 (fUML) RTF

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

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

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

Jira Issues

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

Click here for this issue's archive.
Source: NIST (Dr. 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: Add active behavior to EventOccurrence Adding an event occurrence into the event pool of the target should always be done in a separate execution thread than that of the sender of the event occurrence. Not only does this better model the asynchronous nature of signal sends, it also better models the semantics of inter-object communication in general, as discussed in 2.4 Genericity of the Execution Model, even for, say, call event occurrences. That is because the semantics of concurrency in fUML allows for arbitrary sequential or parallel ordering of the execution of concurrent behaviors. Therefore, having concurrent threads for actually sending each event occurrence to the target better models the possibility that concurrent sends may be arbitrarily re-ordered, or even potentially lost (if the execution of a send behavior ends up being postponed, say, until sequentially after its target object has been destroyed).
Revised Text: Make the following changes in the specification document and in the normative fUML Semantics XMI. (This resolution presumes the resolutions to issues [1]FUML13-25 and [2]FUML13-23.) In 8.4.3.1 Overview, under Event Occurrences, after the first paragraph, insert the following: The EventOccurrence class is also an active class in the execution model, in a similar way to ObjectActivation, as described above. When an event occurrence is sent using the sendTo operation of EventOccurrence, the event occurrence classifier behavior is started asynchronously and the event occurrence sends a SendSignal to itself. When the classifier behavior asynchronously receives the SendSignal, it carries out the actual sending of the event occurrence to the target object, resulting in the event occurrence being placed in the target object event pool. Thus, not only is the dispatching of the event occurrence asynchronously decoupled from the receipt of the event occurrence, but actual transmission of the event occurrence to the target object is asynchronously decoupled from the execution that initiated the sending of the event occurrence. Note: The above model of the sending of event occurrences supports the general approach to the semantics of inter-object communications in fUML (see 2.4). Since each event occurrence is sent using a concurrently executing behavior in the execution model, the semantics of concurrency (as also discussed in 2.4) allows event occurrences that have been sent concurrently to be arbitrarily re-ordered in time before delivery or arbitrarily delayed in time relative to the concurrent execution of the target object event dispatch loop behaviors. This is consistent with the allowed possibility that inter-object communication may not be reliable or deterministic. At the end of the third paragraph (beginning "To start a classifier behavior"), add the following sentence: (Note that an invocation event occurrence is not sent using the asynchronous EventOccurrence behavior, as described above for signal and call event occurrences, but is placed directly into the event pool of the context object of the classifier behavior execution.) In Figure 8.16 Event Occurrences, add the signal SendSignal. Show that the class EventOccurrence is active with the classifier behavior SendBehavior, and add the following operation to it: + sendTo(in target: Reference) Add a directed association from EventOccurrence to Reference with an association end + target having multiplicity 0..1 and opposite end multiplicity *. Editorial Note. The resolution to [3]FUML13-16 would change the subclause number for EventOccurrence referenced below to 8.4.3.2.6. In 8.4.3.2.3 EventOccurrence, add Figure 8-18 Classifier Behavior for EventOccurrence with the attached diagram: and renumber subsequent figures appropriately. Under Associations, replace "None" with: *target : Reference [0..1] A reference to the target object to which this event occurrence is being sent. Under Operations, add the following operation: [4] sendTo ( in target : Reference ) this.target = target; _startObjectBehavior(); _send(new SendSignal()); Editorial Note. The number of this operation is consistent with the revisions made in the resolution to issue [4]FUML13-25. In 8.6.2.2.9 SendSignalActionActivation, under Operations, in the operation doAction, change the statement ((Reference)target).send(signalEventOccurrence); to signalEventOccurrence.sendTo((Reference)target); Editorial Note. This statement was previously updated in the resolution to issue [5]FUML13-23. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML13-25 [2] http://issues.omg.org/browse/FUML13-23 [3] http://issues.omg.org/browse/FUML13-16 [4] http://issues.omg.org/browse/FUML13-25 [5] http://issues.omg.org/browse/FUML13-23
Actions taken:
December 18, 2008: received issue
January 7, 2013: Deferred
December 22, 2015: closed issue
April 6, 2017: Resolved

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: Out of scope This is an important issue. However. It is more than can be dealt with in the context of the fUML RTF. A general strategy is needed in the context of other standards extending fUML, which are now already emerging (such as PSCS and PSSM). Perhaps this can be done as part of the transition of fUML to UML 2,5, which is also beyond the scope of this issue. In addition, the proposed conformance/compliance terminology is probably not consistent with ISO practice.
Revised Text:
Actions taken:
February 18, 2009: received issue
January 7, 2013: Deferred
October 8, 2015: Closed; Out Of Scope
December 22, 2015: closed issue

Discussion:

Issue 13872: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add (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: 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

Issue 14526: Flow final nodes should be included (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03)  Subclause:  7.4.2 IntermediateActivities         Flow final nodes are currently excluded from the fUML subset. However, such nodes can be useful to explicitly consume tokens without terminating an activity. Since their semantics would be very easy to add to the execution model, it should be considered to add them to the fUML subset

Resolution: Agreed.
Revised Text: In Subclause 7.4.2.1 Overview, remove the following paragraphs: From Control Nodes (see Figure 7.22): � FlowFinalNode. Flow final nodes are not included in fUML because it is generally not necessary to explicitly terminate an individual flow in an activity. (Activity final nodes are included in fUML in order to terminate the entire activity.) In Figure 7.22, Control Nodes, add the following class as a subclass of FinalNode: FlowFinalNode After Subclause 7.4.2.2.9 FinalNode, insert the following subclause (and renumber subsequent subclauses appropriately). 7.4.2.2.10 FlowFinalNode Generalizations � �FinalNode� on page 57 Attributes None Associations None Additional Constraints None In Subclause 8.2.3.2.1 ExecutionFactoryL2, in the instantiateVistor operation (as corrected by the resolution to Issue 17211), after the lines else if (element instanceof ActivityFinalNode) { visitor = new ActivityFinalNodeActivation(); } add the lines else if (element instanceof FlowFinalNode) { visitor = new FlowFinalNodeActivation(); } In Subclause 8.5.2.1, Figure 8.27 Control Node Activations, add the following class as a subclass of ControlNodeActivation: FlowFinalNodeActivation + fire ( incomingTokens: Token [*] ) After Subclause 8.5.2.2.9 DecisionNodeActivation, add the following subclause (and renumber subsequent subclauses appropriately). 8.5.2.2.10 FlowFinalNodeActivation A flow final node activation is a control node activation for a node that is a flow final node. Generalizations � �ControlNodeActivation� on page 202 Attributes None Associations None Operations [1] fire ( in incomingTokens : Token [0..*] ) // Consume all incoming tokens. Debug.println("[fire] Flow final node " + this.node.name + "..."); for (int i = 0; i < incomingTokens.size(); i++) { Token token = incomingTokens.getValue(i); token.withdraw(); }
Actions taken:
October 6, 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

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Defer The RTF agrees this issue needs resolution but, due to lack of time, is deferring its resolution to the next RTF.
Revised Text:
Actions taken:
January 15, 2010: received issue
January 7, 2013: Deferred
December 22, 2015: closed issue

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 15130: An action may not stop firing again (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

The code for ActionActivation::fire, as updated for the resolution of Issue 15094, is missing the statement �fireAgain := false;� that should appear after �_beginIsolation();� and before �_endIsolation();�. As a result, if an action fires again at least once, but eventually is not ready to fire any longer, fireAgain will still stay true, causing it to erroneously continue to fire anyway.

Resolution: agreed
Revised Text: In Subclause 8.6.2.2.1, in ActionActivation::fire, after �_beginIsolation();�, add the statement: fireAgain := false;
Actions taken:
March 21, 2010: received issue
January 7, 2013: closed issue

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: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Remove sentence Agreed.
Revised Text: In 10.4.6.2, remove the last sentence in the paragraph: 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.
Actions taken:
July 27, 2010: received issue
January 7, 2013: Deferred
December 22, 2015: closed issue
April 6, 2017: Resolved

Issue 15986: fUML 1.1 should be based on UML 2.4 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14)         Foundational UML (fUML) 1.0 as finalized is based on UML 2.3. With the completion of the UML 2.4 RTF, fUML should be moved to UML 2.4. This would be consistent with the recently adopted Alf action language specification, which will be finalized based on UML 2.4.         Fortunately, nothing seems to have changed in UML 2.4 that would substantively effect the specification of the fUML abstract syntax subset. However, the fUML normative XMI should be regenerated consistent with UML 2.4/XMI 2.4. Further, UML 2.4 has separated the primitive type model into a separate XMI file with normative XMI IDs, and these should be used for referencing those types in the normative XMI for the fUML Foundational Model Library.

Resolution: The following issues resolved in UML 2.4 and UML 2.4.1 have an impact on the fUML subset. � Issue 10831: �PackageableElement::visibility� uses �false� as default value � Issue 12583: OCL 2.0 8.2 Real � Issue 13718: Section 12.3.48 on page 412 � Issue 13993: UML 2.2 Issue - availability of PrimitiveTypes for UML models � Issue 14631: All enumeration literals in the model have their "classifier" collections empty � Issue 14632: Associations with same name that live in different packages violate unique name constraint � Issue 14926: is composite, but does not subset ownedElement � Issue 14931: remove BehavioredClassifier::ownedTrigger � Issue 14977: Matching subsettting across association ends � Issue 15369: UML 2.4: Add Property::isId � Issue 15370: UML 2.4: Add Package::URI � Issue 15526: Missing subsetting of redefinitionContext by Property::owningAssociation � Issue 15664: Property::isID should not be optional � Issue 16232: No unambiguous way in UML 2.4 to serialize StructuredActivityNode Further, comparison if the fUML 1.0 abstract syntax model with that of UML 2.4.1 identifies the following additional corrections need to fUML. � Remove Class::isAbstract attribute (this is already inherited from Classifier). � Add default of true for Generalization::isSubstitutable. � Note exclusion of Parameter::defaultValue, Parameter::default and Property::default. � Add default of �in� for Parameter::direction. See also the resolution to Issue 15987 �The fUML Foundational Model Library should support the new UML 2.4 Real primitive type�. For simplicity, all revisions related to the new Real type are handled in that resolution.
Revised Text: Clause 3 Normative References Replace the content of the clause with: The following normative documents contain provisions that, through reference in this text, constitute provisions of this specification. The following OMG standards provided the source for the foundational subset. � UML 2.4.1 Infrastructure Specification (formal/11-08-05) � UML 2.4.1 Superstructure Specification (formal/11-08-06) � MOF 2.4.1 Core Specification (formal/11-08-07) � OCL 2.0 Specification (formal/06-05-01) XML Metadata Interchange (XMI) provides a syntactic interchange mechanism for models. It is expected that models conforming to this specification will be interchanged using XMI. � MOF 2.4.1 XMI Mapping Specification (formal/11-08-09)? Subclause 7.2 Classes In Subclause 7.2.2.1 Overview, after the existing bullet under �From Features (see Figure 7.9)�, add: � Parameter::defaultValue. Implicitly computing a default value for a behavioral feature (or behavior) would require coordination of multiple UML actions, since call actions always require explicit inputs or outputs to be provided. � Parameter::default. This is excluded because default values for parameters are not included in fUML. After the first bullet under �From Classes (see Figure 7.11)�, add: � Property::default. This is excluded because default values for properties are not included in fUML. In Figure 7.5 Namespaces, in the symbol for PackageableElement shown immediately, under NamedElement, add the attribute � + visibility : VisibilityKind = public {redefines visibility} In Figure 7.8 Classifiers, � In the specification for the attribute Generalization::isSubstitutable, add � = true�. � In the annotations to the association end attribute, add �subsets redefinableFeature, subsets feature�. � Add the annotation �{subsets redefinitionContext, subsets featuringClassifier}� to the association end classifier opposite to attribute. � Add the annotation �{subsets memberNamespace}� to the association end classifier opposite to inheritedMember. � Add the annotation �{readOnly, union}� to the association end redefinedElement. In Figure 7.9 Features, � In the specification for the attribute Parameter::direction, add � = in�. � In the annotation for the association end feature add the annotations �union, subsets member}�. � In the annotations for the association end featuringClassifier add �subsets memberNamespace�. In Figure 7.10 Operations, � Add the annotation �{subsets redefinedElement}� to the association end redefinedOperation. � Add the annotation �{subsets redefinableElement}� to the association end operation opposite redefinedOperation. � Replace the annotation �{subsets namespace}� on the association end operation opposite to ownedParameter with �{subsets ownerFormalParam}�. � Add the annotation �{readOnly} to the association end �type�. In Figure 7.11 Classes, � Remove the attribute isAbstract from class Class. � In class Property, add the attribute o + isId : Boolean = false � Add the annotation �{redefines general}� to the association end superclass. � Add the annotation �{subsets classifier}� to the association end class opposite to superclass. � In the annotation for the association end ownedOperation, add the annotation �subsets redefinableElement�. � In the annotation for the association end class opposite to ownedOperation, add the annotation �subsets redefinitionContext�. � In the annotation for the association end class opposite to ownedAttribute, remove the annotation �subsets featuringClassifier�. � In the annotation for the association end memberEnd, replace �subsets ownedMember� with �subsets member�. � Add the annotation �{subsets memberNamespace}� to the association end association opposite to memberEnd. � Add the annotation �{subsets owningAssociation}� to the association end association opposite to navigableOwnedEnd. In Figure 7.12 Data Types, � In the annotation for association end datatype opposite to ownedAttribute, remove �subsets featuringClassifier�. � Add a unidirectional association from EnumerationLiteral to Enumeration with association ends: o enumerationLiteral * {redefines instanceSpecificiation} o /classifier 1 {redefines classifier} In Figure 7.13 Packages, � In class Package, add the attribute o + URI : String [0..1] {id} � Replace the annotation �{subsets namespace}� for the association end package with �{subsets owningPackage}�. � Replace the annotation �{subsets namespace}� for the association end nestingPackage with �{subsets owningPackage}�. In Subclause 7.2.2.3 Class, under �Attributes�, � Remove �isAbstract : Boolean = false� In Subclause 7.2.2.10 EnumerationLiteral, under �Attributes� � Before the existing bullet, add a bullet for �classifier : Enumeration�. � Change �enumeration : Enumeration [0..1]� to �enumeration : Enumeration� In Subclause 7.2.2.12 Generalization, under �Attributes�, � At the end of the bullet for �isSubstitutable", add � = true� In Subclause 7.2.2.2.25 Package, under �Attributes�, replace �None� with � URI : String [0..1] {id} In Subclause 7.2.2.2.26 PackageableElement, under �Attributes�, replace �None� with � visibility : VisibilityKind = public In Subclause 7.2.2.2.28 Parameter, under �Attributes�, � At the end of the bullet for �direction�, add � = in�. In Subclause 7.2.2.2.30 Property, under �Attributes�, after the bullet for �isDerivedUnion�, add: � isId : Boolean = false Subclause 7.3 Common Behaviors In Subclause 7.3.1 Overview, remove �From Triggers (see Figure 7.17)� and the following bullet. In Figure 7.15 Common Behavior, � Add the annotation �{subsets namespace}� to the association end behavioredClassifier opposite to ownedBehavior. � Add the annotation �{redefines behavioredClassifier}� to the association end behavioredClassifier opposite to classifierBehavior. � Add the annotation �{readOnly}� to the association end context. � Add the annotation �{subsets namespace}� to the association end behavior opposite to ownedParameter. In Figure 7.16 Reception, � Add the annotation �{subsets memberNamespace, subsets featuringClassifier}� to the association end ownedReception. Subclause 7.4 Activities In Figure 7.23 Flows, � Add the annotation �{subsets owner}� to the association end activityEdge. In Figure 7.24 StructuredNodes, � Add a symbol for the class Activity. � Add an association from Activity to StructuredActivityNode with the ends o +activity 0..1 {redefines activity} o +structuredActivityNode * {readOnly, subsets node} � Add the annotation �{subsets owner}� to the two inStructuredNode association ends and the conditionalNode association end opposite to clause. � Add the annotation �{subsets ownedElement}� to the association ends node, edge and clause. � Add the annotation �{subsets action}� to the two structuredActivityNode association ends. � Add the annotation �{subsets structuredActivityNode}� to the conditionalNode association end opposite to result and the two loopNode association ends opposite to loopVariableInput and result. Subclause 7.5 Actions In Figure 7.28 Basic Pins, � Add the annotation �{subsets owner}� to the two action association ends. In Figure 7.29 Basic Invocation Actions, � Add the annotation �{subsets action}� to the end of every composition association whose opposite end is an InputPin or OutputPin. In Figure 7.30 Object Actions, � Add the annotation �{subsets action}� to the end of every composition association whose opposite end is an InputPin or OutputPin. � Add the annotation �{subsets ownedElement}� to the value association end. � Add the annotation �{subsets owner}� to the valueSpecificationAction association end opposite to value. In Figure 7.31 Structural Feature Actions, � Add the annotation �{subsets action}� to the end of every composition association whose opposite end is an InputPin or OutputPin. In Figure 7.32 Link Identification, � Add the annotation �{subsets action}� to the linkAction association end opposite to inputValue. � Add the annotation �{subsets ownedElement}� to the endData association end. � Add the annotation �{subsets owner}� to the linkAction association end opposite to endData. In Figure 7.33 Read Link Action, � Add the annotation �{subsets action}� to the readlinkAction association end. In Figure 7.34 Write Link Actions, � Add the annotation �{subsets action}� to the clearAssociationAction association end. � Add the annotation �{redefines linkAction}� to the createLinkAction and destroyLinkAction association ends. In Figure 7.35 Accept Event Actions, � Add the annotation �{subsets ownedElement}� to the trigger association end. � Add the annotation �{subsets owner}� to the acceptEventAction association end opposite to trigger. � Add the annotation �{subsets action}� to the acceptEventAction association end opposite to result. In Figure 7.36 Object Lifecycle Actions, � Add the annotation �{subsets action}� to the end of every composition association whose opposite end is an InputPin or OutputPin. Clause 9 Foundational Model Library In Figure 9.1, replace the package UML::AuxiliaryConstructs::PrimitiveTypes package with PrimitiveTypes. In Subclause 9.1, first paragraph, � In the first sentence, replace ��AuxiliaryConstructs::PrimitiveTypes package from the UML 2 metamodel (see sub clause 17.4 of the UML 2 Superstructure Specification).� with ��PrimitiveTypes package from the UML 2 infrastructure (see sub clause 13.1 of the UML 2.4.1 Infrastructure Specification).� � In the last sentence, replace �AuxiliaryConstructs::PrimitiveTypes� with �PrimitiveTypes�. fUML_Syntax.xmi In the normative XMI, change the names of the following associations: � IntermediateActivities::A_outgoing_source to A_outgoing_source_node � IntermediateActivities::A_incoming_target to A_incoming_target_node
Actions taken:
January 26, 2011: received issue
January 7, 2013: closed issue

Discussion:

Issue 15987: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14)         UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library.

Resolution: The UML 2.4.1 Infrastructure specification states that �A real is a primitive type representing the mathematical concept of real� and that �An instance of Real is an element in the infinite set of real numbers.� However, some care needs to be taken in defining the fUML execution semantics of the Real type and supporting primitive functions, so that it is possible for a real implementation to conform to those semantics. The UML specification also says that �An instance of Integer is an element in the (infinite) set of integers��. And the base semantics for buml:Integer in Subclause 10.3.1.2 of the fUML 1.0 specification does, indeed, include the mathematical axioms necessary to define this infinite set. However, Subclause 9.1 includes the permission that ��a conforming implementation may limit the supported values [of Integer] to a finite set.� Similarly, fUML should allow conforming implementations to limit the supported values of Real to a finite set. However, for Real numbers, this means more than just limiting the upper and lower bounds of the supported range of Real numbers. It also means dealing with the fact that Real numbers can only be represented to finite precision in an actual implementation. Generally, programming languages provide floating-point representations that approximate Real numbers. However, this is an implementation representation, and the most commonly used standard reference on floating-point numbers, IEEE 754, is a standard for the implementation of floating-point computation. For fUML, it is necessary to provide a precise semantic specification for Real numbers that is implementation independent but that provides clear criteria for the conformance of actual implementations. This should allow implementations based on a floating-point standard such as IEEE 754 but also allow implementations using, e.g., fixed-point computation or exact rational number computation. This can be achieved in three steps. 1. Axioms for the Real type need to be added to the fUML base semantics in Clause 10. 2. Criteria are needed in Clause 9 for conformance to the Real type as it is to be provided in the fUML Foundational Model Library. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). So, some permission is needed to allow for the conformance of implementations using, e.g., finite-precision floating-point representations. In addition, IEEE 754 requires some additional special values be represented in the floating-point formats it defines. Since it is expected that it will be common that the fUML Real type will be implemented using a floating-point representation based on IEEE 754, it is necessary to allow for the inclusion of such values in an implementation of Real. 3. Criteria are needed in Clause 9 for conformance to the semantics of the primitive functions for Real to be provided in the Foundational Model Library. The specification of the primitive functions for Real in the Foundational Model Library will define the exact real number result of applying those functions. It is then necessary to define how these exact results may be represented in a conforming implementation that takes advantage of some or all of the permissions allowed relative to the representation of Real numbers. This resolution also presumes the resolution of Issue 15986, �fUML 1.1 should be based on UML 2.4�. For simplicity, all revisions related to the new Real type have been included here. This includes changes to Clause 7 Abstract Syntax, Clause 8 Execution Model and Annex A Java to UML Activity Mapping, as well as the changes to Clauses 9 and 10 discussed above.
Revised Text: Revised Text: Clause 7 Abstract Syntax In Figure 7.6 Expressions, add LiteralReal as a subclass of LiteralSpecification, with one attribute: � + value : Real After Subclause 7.2.2.17 LiteralNull, add the following subclause: LiteralReal Generalizations � �LiteralSpecification� on page xx Attributes � value : Real Associations None Additional Constraints None Clause 8 Execution Model In Subclause 8.2.2.2, under �Primitive Behaviors and Primitive Types�, in the last sentence of the last paragraph, change ��Boolean, Integer, String, and UnlimitedNatural�� to ��Boolean, Integer, Real, String, and UnlimitedNatural��. In Figure 8.11, add the following class as a subclass of PrimitiveValue: RealValue + value : Real + specify ( ) : ValueSpecification + equals ( otherValue : Value ) : Boolean + copy ( ) : Value # new_ ( ) : Value + toString ( ) : String In Figure 8.13, add the following class as a subclass of LiteralEvaluation: LiteralRealEvaluation + evaluate ( ) : Value [0..1] After Subclause 8.3.2.2.15, add the subclause LiteralRealEvaluation A literal real evaluation is an evaluation whose specification is a literal real. Generalizations � �LiteralEvaluation� on page 138 Attributes None Associations None Operations [1] evaluate ( ) : Value [0..1] // Evaluate a real integer, producing a real value. LiteralReal literal = (LiteralReal)specification; RealValue realValue = new RealValue(); realValue.type = this.getType("Real"); realValue.value = literal.value; return realValue; After Subclause 8.3.2.2.19, add the subclause RealValue A real value is a primitive value whose type is Real. Generalizations � �PrimitiveValue� on page 143 Attributes � value : Real? The actual Real value. Associations None Operations [1] copy ( ) : Value // Create a new real value with the same value as this real value. RealValue newValue = (RealValue)(super.copy()); newValue.value = this.value; return newValue; [2] equals ( in otherValue : Value ) : Boolean // Test if this real value is equal to the otherValue.? // To be equal, the otherValue must have the same value as this real value. boolean isEqual = false; if (otherValue instanceof RealValue) {? isEqual = ((RealValue)otherValue).value == this.value; } return isEqual; [3] new_ ( ) : Value // Create a new real value with no value. return new RealValue(); [4] specify ( ) : ValueSpecification // Return a literal real with the value of this real value. LiteralReal literal = new LiteralReal(); literal.type = this.type; literal.value = this.value; return literal;? [5] toString ( ) : String String stringValue = ""; if (this.value == 0) { stringValue = "0"; } else {? float positiveValue = this.value; if (positiveValue < 0) { positiveValue = -positiveValue; } int exponent = 0; if (postiveValue < .1) { while (positiveValue < .1) { positiveValue = positiveValue * 10; exponent = exponent - 1; } else if (positiveValue > 1) { while (positiveValue > 1) { positiveValue = positiveValue / 10; exponent = exponent + 1; } } // This gives 10 significant digits in the mantissa. for (int i=0; i<10; i++) { positiveValue = positiveValue * 10; } IntegerValue integerValue = new IntegerValue(); integerValue.value = (int)positiveValue; stringValue = �0.� + integerValue.toString(); integerValue.value = exponent; stringValue = stringValue + �E� + integerValue.toString; if (this.value < 0) {? stringValue = "-" + stringValue; } } return stringValue; Clause 9 Foundational Model Library In Subclause 9.1 Primitive Types, Table 9.1, add the following row after the row for Integer: Real The Real type has literal values in the infinite, continuous set of real numbers. However, a conforming implementation may limit the support values to a finite subset (see 9.2.3 for further discussion of this). In Subclause 9.2 Primitive Behaviors, add a RealFunctions package to Figure 9.2. In the first paragraph of Subclause 9.2.2 Integer Functions, remove the sentence: The OCL �/� operation is not included, since this returns a Real value, and the Foundational Model Library does not support a Real primitive type. In Table 9.3, add the following row, after the row for the �*� function: /(x: Integer, y: Integer): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result = ToReal(x) / ToReal(y) NOTE: The ToReal and �/� functions used here are those from the RealFunctions package (see 9.2.3). Add the following subclause and renumber subsequent subclauses and tables appropriately: 9.2.3 Real Functions Table 9.4 lists the function behaviors that are included in the package RealFunctions. The naming is consistent with OCL, including the use of the conventional symbols for arithmetic functions, except that the negation function is named �Neg�, rather than overloading the symbol �-�, and alphabetic names are capitalized, per the usual convention for behaviors (as kinds of classes). The Foundation Model Library also provides ToString and ToInteger functions not found in OCL 2.0. The ToReal function does correspond to an OCL operation, though, in OCL, it is a String operation. Table 9.4 � Foundation Model Library Real Functions Function Signature Description Neg(x: Real): Real The negative value of x. +(x: Real, y: Real): Real The value of the addition of x and y. -(x: Real, y: Real): Real The value of the subtraction of x and y. Post: result + y = x Inv(x: Real): Real The inverse (reciprocal) value of x. *(x: Real, y: Real): Real The value of the multiplication of x and y. /(x: Real, y: Real): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result * y = x Abs(x: Real): Real The absolute value of x. Post: if x < 0 then result = Neg(x) else result = x endif Floor(x: Real): Integer The largest integer that is less than or equal to x. Post: result <= x And result + 1 > x Round(x: Real): Integer The integer that is closest to x. When there are two such integers, the largest one. Post: (Abs(x - result) < 0.5) Or ((Abs(x - result) = 0.5) And result > x) Max(x: Real, y: Real): Real The maximum of x and y. Post: if x >= y then result = x else result = y endif Min(x: Real, y: Real): Real The minimum of x and y. Post: if x <= y then result = x else result = y endif <(x: Real, y: Real): Boolean True if x is less than y. >(x: Real, y: Real): Boolean True if x is greater than y. Post: result = Not(x <= y) <=(x: Real, y: Real): Boolean True if x is less than or equal to y. Post: result = (x = y) Or (x < y) >=(x: Real, y: Real): Boolean True if x is greater than or equal to y. Post: result = (x = y) Or (x > y) ToString(x: Real): String Converts x to a String value. Post: ToReal(result) = x ToInteger(x: Real): Integer Converts x to an Integer value, truncating towards zero. Post: if x >= 0 then Floor(x) else Neg(Floor(Neg(x)) endif ToReal(x: String): Real[0..1] Converts x to a Real value. Pre: x has the form of a legal Real value. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). Therefore, implementations are given the following permissions for representing Real numbers and performing computations on them, while still conforming to this specification. NOTE: The permissions below are intended, in particular, to allow the conformance of implementations using finite-precision floating-point representations for Real numbers (such as those based on the popular IEEE 754 standard), while still allowing for other implementations that may not need to take advantage of all the allowed permissions. 1. A conforming implementation may support only a limited range of Real values, such that the absolute value of any supported value is less than or equal to a specified maximum value. If the implementation limits the range of values support for Integer, then the maximum value specified for Real must be no less than the greatest absolute value of any supported Integer value. 2. A conforming implementation may support only a restricted value set for Real, defined as a non-dense subset of the infinite set of rational numbers (such that any bounded interval of this value set contains only a finite set of values) including zero and with no upper or lower bound. If the implementation limits the range of values supported for Integer, then the smallest positive value in the restricted value set shall be at least as small as the reciprocal of the largest supported Integer value. 3. A conforming implementation may provide distinct representations for Real positive zero and Real negative zero. These values shall be considered equal for the purposes of all comparison functions. However, they may be distinguished in certain arithmetic computations (see below). 4. A conforming implementation may include additional special values that are instances of the Real type but are not numeric values (such as infinite values and �not a number� values). Note that, even if included in an implementation of the Real type, none of these special values have any standard literal representation in UML. The functions in the RealFunctions package are specified in Table 9.4 in terms of the semantics for mathematical Real numbers, as defined in Subclause 10.3.1. However, an implementation that takes advantage of some or all of the above permissions may not be able to produce exact results for some computations using these functions. Therefore, conformance to the function behaviors given in Table 9.4 shall be interpreted as follows. � Since a restricted value set is non-dense and unbounded, any exact value that is not in such a set will be between two values that are in the set. If a conforming implementation supports only a restricted value set, and the result of a computation is not a member of this set, then the implementation may implement the computation as resulting in one of the two values in the restricted value set that the exact result is between. (If the exact value of the computation is non-zero, but the chosen value in the restricted value set is zero, then the computation is said to underflow.) � If a conforming implementation supports only a limited range of values, then a computation that results in an exact value that is outside that range is said to overflow. The implementation may implement an overflowing computation as resulting in a special value (e.g., positive or negative infinity). If not, an overflowing computation shall be implemented as having an empty result. � If a numeric result is not defined for a call to a primitive function resulting in a Real value, because one of the arguments is a special value or because a precondition is violated, then a conforming implementation may produce a special value for its result. Otherwise, the computation shall be implemented as having an empty result. � If a conforming implementation supports signed zero, then multiplication of a numeric value by positive zero shall result in positive zero, while multiplication of a numeric value by negative zero shall result in negative zero. A conforming implementation shall not otherwise distinguish between positive and negative zero in any call to a primitive function that is specified as resulting in a numeric result. However, it may distinguish between them if the result is implemented as a special value (e.g., division by negative zero may result in negative infinity). � Other than as given above, this specification does not define the result of calling a primitive function in which one or more of the arguments is a special value. Clause 10 Base Semantics Replace the contents of Subclause 10.3.1.2 Numbers with The less-than relation. (forall (x y) (if (buml:less-than x y) (and (buml:Real x) (buml:Real y)))) (forall (x y) (if (buml:less-than x y) (and (not (buml:less-than y x)) (not (= x y))))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (or (form:less-than x y) (form:less-than y x) (= y x)))) (forall (x y) (iff (buml:less-than x y) (and (buml:Real x) (buml:Real y) (not (buml:less-than y x)) (not (= x y))))) (forall (x y z) (if (and (buml:less-than x y) (buml:less-than y z)) (buml:less-than x z))) (forall (x z) (if (buml:less-than x z) (exists (y) (and (buml:less-than x y) (buml:less-than y z))))) The add relation. (forall (x y z) (if (buml:add x y z) (and (buml:Real x) (buml:Real y) (buml:Real z)))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (exists (z) (buml:add x y z)))) (forall (x y z1 z2) (if (and (buml:add x y z1) (buml:add x y z2)) (= z1 z2))) (forall (x y zxy zyx) (if (and (buml:add x y zxy) (buml:add y x zyx)) (= zxy zyx))) (forall (x y z xy yz rxy ryz) (if (and (buml:add x y xy) (buml:add xy z rxy) (buml:add y z yz) (buml:add x yz ryz)) (= rxy ryz))) (forall (x y xz yz) (if (and (buml:add x z xz) (buml:add y z yz) (buml:less-than x y)) (buml:less-than xz yz))) (buml:Real form:0) (forall (x x0) (if (buml:add x form:0 x0) (= x x0))) (forall (x y) (iff (buml:neg x y) (buml:add x y form:0))) (forall (x) (if (buml:Real x) (exists (nx) (buml:neg x nx)))) The mult relation. (forall (x y z) (if (buml:mult x y z) (and (buml:Real x) (buml:Real y) (buml:Real z)))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (exists (z) (buml:mult x y z)))) (forall (x y z1 z2) (if (and (buml:mult x y z1) (buml:mult x y z2)) (= z1 z2))) (forall (x y zxy zyx) (if (and (buml:mult x y zxy) (buml:mult y x zyx)) (= zxy zyx))) (forall (x y z xy yz rxy ryz) (if (and (buml:mult x y xy) (buml:mult xy z rxy) (buml:mult y z yz) (buml:mult x yz ryz)) (= rxy ryz))) (forall (x y xy) (if (and (buml:mult x y xy) (buml:less-than form:0 x) (buml:less-than form:0 y)) (buml:less-than form:0 xy))) (buml:Real form:1) (forall (x x1) (if (buml:mult x form:1 x1) (= x x1))) (forall (x y) (iff (buml:inv x y) (buml:mult x y form:1))) (forall (x) (if (and (buml:Real x) (not (= x form:0))) (exists (ix) (buml:inv x ix)))) (forall (x y z yz rxyz xy xz xyxz) (if (and (add y z yz) (mult x yz xyz) (mult x y xy) (mult x z xz) (add xy xz xyxz)) (= xyz xyxz))) (less-than form:0 form:1) Rational, integer, natural, unlimited natural, and whole numbers. (forall (x) (if (form:RationalNumber x) (buml:Real x))) (forall (x z) (if (and (form:Rational x) (form:Rational z) (buml:less-than x z)) (exists (y) (and (form:Rational y) (buml:less-than x y) (buml:less-than y z))))) (forall (x z) (if (and (form:Rational x) (form:Rational z) (buml:less-than x z)) (exists (y) (and (buml:Real y) (not (form:Rational y)) (buml:less-than x y) (buml:less-than y z))))) (forall (y) (if (and (buml:Real y) (not (form:Rational y))) (and (not (exists (xu) (and (form:Rational xu) (forall (x) (and (Rational x) (buml:less-than x y) (or (buml:less-than x xu) (= x xu))))))) (not (exists (zl) (and (form:Rational zl) (forall (z) (and (Rational z) (buml:less-than y z) (or (buml:less-than zl z) (= zl z)))))))))) (forall (x) (if (buml:Integer x) (form:Rational x))) (forall (x y) (iff (form:add-one x y) (form:add x form:1 y))) (forall (x) (iff (buml:Integer x) (or (= x form:0) (exists (y) (and (buml:Integer y) (or (form:add-one y x) (form:add-one x y))))))) (forall (x) (iff (form:NaturalNumber x) (and (buml:Integer x) (or (= x form:0) (buml:less-than form:0 x))))) (forall (x) (iff (buml:UnlimitedNatural x) (or (form:NaturalNumber x) (= x buml:*)))) (forall (x) (iff (form:WholeNumber x) (and (form:NaturalNumber x) (not (= x form:0))))) Annex A Java to UML Activity Mapping In Table A.1, after the row for type �int�, add the following row: float Real Change the title of Subclause A.4.13 from �Type Cast� to �Type Cast (non-primitive)�. After Subclause A.4.13, add the following subclause: A.4.14 Type Cast (Numeric) Java (<type>)<expression> � The type must be int or float. � The expression being cast must be of type int or float. UML � A type cast from int to int, float to float or int to float is mapped as the expression being cast. The cast itself is ignored, other than that the result pin for the expression being mapped is always given the UML type corresponding to the type of the cast. � A type cast from float to int maps to a call behavior action for the ToInteger behavior. The result output pin becomes the result pin for the mapping. The argument input pin of the call behavior action is connected by an object flow to the result pin of the mapping of the expression being cast. Note � In the base semantics, an integers is a kind of real number (see 10.3.1.2), so no actual operation is needed to cast an integer to a real.
Actions taken:
January 26, 2011: received issue
January 7, 2013: closed issue

Discussion:

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Add central buffer nodes and data stores Actually, the tokens in a central buffer node are withdrawn from the central buffer node when offers for them are accepted. On the other hand, values on tokens in data store nodes do effectively "persist". This makes data store nodes the important ones to include. However, since data store nodes are kinds of central buffer nodes, including data store nodes implies the need to also include central buffer nodes. CentralBufferNode is in the IntermediateActivities package in UML 2.4.1, which is already included in the fUML subset. DataStoreNode, however, is in the CompleteActivities package, which, heretofore, has not been part of the fUML subset. Therefore, in order to add DataStoreNode, it is necessary to add a new subclause for the CompleteActivities package, even though only one metaclass is to be included from that package. Further, this package must be added to the L3 merge for fUML.
Revised Text: Make the following updates to the specification document and also correspondingly update the normative fUML Syntax and Semantics XMI files. In 2.2 Conformance Levels, in the bullet list following Figure 2.4, add the following as the first bullet: *Activities::CompleteActivities In Figure 2.5, update the diagram to show that the package CompleteActivities (from fUML::Syntax::Activities) is merged into package L3 (from fUML::Syntax). In Figure 2.6, update the diagram to show that the package CompleteActivities (from fUML::Semantics::Activities) is merged into package L3 (from fUML::Semantics). In 7.4.1 Overview, in the bullet list after the first paragraph, add the following as the second bullet: *CompleteActivities Replace the last paragraph with the following: Only data stores are included from the UML 2 Superstructure package CompleteActivities (see 7.4.3). Other capabilities from this package are excluded because they are considered to be more appropriate for "higher level" process modeling and outside the scope of fUML. In Figure 7.19, update the diagram to show that the package CompleteActivities (from fUML::Syntax::Activities) imports the package IntermediateActivities (from fUML::Syntax::Activities). In 7.4.2.1 Overview, remove the line "From Object Nodes (see Figure 7.21):" and the following bullet. In Figure 7.21, add the class CentralBufferNode as a subclass of ObjectNode. Add the following subclause, renumbering subsequent subclauses as appropriate. 7.4.2.2.6 CentralBufferNode Generalizations *ObjectNode Attributes None Associations None Additional Constraints None Add the following subclause, renumbering subsequent subclauses and figures appropriately. 7.4.3 Complete Activities 7.4.3.1 Overview The fUML Activities::CompleteActivities package includes only the class DataStoreNode, as shown in Figure 7.24. All other features from the CompleteActivities package in the UML 2 Superstructure Specification have been excluded and are, therefore, not reflected in the fUML abstract syntax diagrams. Figure 7.24 - Data stores 7.4.3.2 Class Descriptions 7.4.3.2.1 DataStoreNode Generalizations *CentralBufferNode Attributes None Associations None Additional Constraints None In 8.5.1 Overview, in the third paragraph, in the first sentence, change "Subclause 8.5.2 describes" to "Subclauses 8.5.2 and 8.5.3 describe". In the second sentence, change "8.5.3" to "8.5.4" and "8.5.5" to "8.5.6". In Figure 8.19 Activities Semantics Packages, update the diagram to show the package CompleteActivities (from fUML::Semantics::Activities) as importing the package IntermediateActivities (from fUML::Semantics::Activities) and CompleteActivities (from fUML::Syntax::Activities). In 8.5.2.1 Overview, in Figure 8.25, add the class CentralBufferNodeActivation as a subclass of ObjectNodeActivation, with the operation + fire(in incomingTokens: Token[0..*]) Editorial Note. Figures 8.19 and 8.25 are renumbered to Figures 8.20 and 8.26 due to the resolution of issue [1]FUML13-1. In 8.5.2.2.5 ActivityNodeActivationGroup, in the operation run, in the second for loop, in the first nested if statement, replace if (activation instanceof ActionActivation | activation instanceof ControlNodeActivation | activation instanceof ActivityParameterNodeActivation) { with if (!(activation instanceof PinActivation | activation instanceof ExpansionNode)) { Add the following subclause and renumber subsequent subclauses appropriately. 8.5.2.2.7 CentralBufferNodeActivation A central buffer node activation is an object node activation for a node that is a central buffer node. Generalizations *ObjectNodeActivation Attributes None Associations None Operations [1] fire ( in incomingTokens : Token [0..*] ) // Add all incoming tokens to the central buffer node. // Offer any tokens that have not yet been offered. this.addTokens(incomingTokens); this.sendUnofferedTokens(); In 8.5.2.2.16 ObjectNodeActivation (8.5.2.2.17 as renumbered), replace the body of the operation terminate with // Terminate the node activation and remove any held tokens. super.terminate(); this.clearTokens(); Add the following subclause and renumber subsequent subclauses and figures appropriately. 8.5.3 Complete Actions 8.5.3.1 Overview The fUML subset includes only data store nodes from the Complete Activities abstract syntax package (see 7.4.3). Figure 8.28 Data Store Node Activations 8.5.3.2 Class Descriptions 8.5.3.2.1 DataStoreNodeActivation A data store activation is a central buffer node activation for a node that is a data store node. Generalization *CentralBufferNodeActivation Attributes None Associations None Operations [1] addToken ( in token : Token ) // Add the given token to the data store only if it is unique, // that is, if its value is not the same as the value of // another token already held in the data store. Value value = token.getValue(); boolean isUnique = true; if (value != null) { TokenList heldTokens = this.getTokens(); int i = 1; while (isUnique & i <= heldTokens.size()) { isUnique = !heldTokens.getValue(i-1).getValue().equals(value); i = i + 1; } } if (isUnique) { super.addToken(token); } [2] removeToken ( in token : Token ) : Integer // Remove the given token from the data store, but then immediately // add a copy back into the data store and offer it (unless the // node activation has already been terminated). int i = super.removeToken(token); if (this.isRunning()) { super.addToken(token.copy()); this.sendUnofferedTokens(); } return i; ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML13-1
Actions taken:
January 26, 2011: received issue
January 7, 2013: Deferred
December 22, 2015: closed issue
April 6, 2017: Resolved

Discussion:

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Defer The RTF agrees this issue needs resolution but, due to lack of time, is deferring its resolution to the next RTF.
Revised Text:
Actions taken:
January 26, 2011: received issue
January 7, 2013: Deferred
December 22, 2015: closed issue

Issue 16654: Error in ExpansionRegionActivation::takeOfferedTokens (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundation Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)    Subclause: 8.5.4.2.3 ExpansionRegionActivation         In the ExpansionRegionActivation class, operation [8] takeOfferedTokens is missing an initial call to super.takeOfferedTokens(). This means that, when an expansion region activation fires, it does not properly handle tokens on control flows incoming to the expansion region, nor does it fire any input pin activations for the region, both of which should be handled as usual for an action. Because of this, the subsequent copying of input tokens from input pin activations in ExpansionRegionActivation never actually produces any tokens, even though some may have been offered to the input pins.

Resolution: agreed
Revised Text: In Subclause 8.5.4.2.3, in ExpansionRegionActivation::takeOfferedTokens, at the beginning, add the statement: super.takeOfferedTokens();
Actions taken:
November 7, 2011: received issue
January 7, 2013: closed issue

Issue 16686: Error in CreateLinkAction semantics (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)    Subclause: 8.6.3.x CreateLinkActionActivation         In Subclause 8.6.3.1 (Overview), under �Link Actions�, it says for a Create Link Action that �if a link already exists in the association extent with the same tuple of values, and all the ends of the association are specified as unique, then no new link is actually created (though this is not an error).� However, the specification for CreateLinkActionActivation::doAction in Subclause 8.6.3.2.4 always creates a new link even if an identical link already exists (unless isReplaceAll=true for one of the ends), regardless of whether the ends of the association are all unique.

Resolution: Agreed. Actually it is OK to always create a new link, as long as a link with all matching ends is destroyed first in the case of an association with all ends unique, since links with matching ends are not distinguishable
Revised Text: In Subclause 8.6.3.4, in doAction, add the following to the initial comment block, before the first sentence: // If the association has any unique ends, then destroy an existing link // that matches all ends of the link being created. Replace the statement �Link oldLink = null;� and the following for loop with: boolean unique = false; for (int i = 0; i < endDataList.size(); i++) { if (endDataList.getValue(i).end.multiplicityElement.isUnique) { unique = true; } } for (int i = 0; i < extent.size(); i++) { ExtensionalValue value = extent.getValue(i); Link link = (Link) value; boolean match = true; boolean destroy = false; int j = 1; while (j <= endDataList.size()) { LinkEndCreationData endData = endDataList.getValue(j - 1); if (this.endMatchesEndData(link, endData)) { if (endData.isReplaceAll) { destroy = true; } } else { match = false; } j = j + 1; } if (destroy | unique & match ) { link.destroy(); } } In the subsequent for loop, remove the following if statement: if (oldLink != null) { if (oldLink.getFeatureValue(endData.end).position < insertAt) { insertAt = insertAt - 1; } }
Actions taken:
November 14, 2011: received issue
January 7, 2013: closed issue

Issue 16687: Duplicate code for ActionActivation::putToken (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)    Subclause: 8.6.2.2.1 ActionActivation         The code listed under operation [12] PutToken for class ActionActivation is accidentally duplicated. The lines starting with the second set of comments to the end should be deleted.

Resolution: agreed
Revised Text: In Subclause 8.6.2.2.1 remove the repeated code for PutToken, from the second set of comments to the end.
Actions taken:
November 15, 2011: received issue
January 7, 2013: closed issue

Issue 16948: Error in DecisionNodeActivation semantics (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)    Subclause: 8.5.2.2.9 DecisionNodeActivation         In the method for the DecisionNodeActivation::getDecisionInputFlowValue operation contains the statement:         value = ((ObjectToken)(tokens.getValue(0))).value;         Since a decision input flow must be an object flow, it would seem reasonable to be able to assume that this flow would only contain ObjectTokens. However, all tokens offered by ForkNodeActivations are wrapped in ForkTokens, which is directly a subclass of Token. If such a token is offered on a decision input flow, then the above cast will fail.         To fix this, the above statement should be replaced with:         value = tokens.getValue(0).getValue();         The getValue operation is defined for all types of tokens (it returns null for control tokens, but that would not be an issue here).

Resolution: agreed
Revised Text: In Subclause 8.5.2.2.9, in the getDecisionInputFlowValue operation, replace the statement value = ((ObjectToken)(tokens.getValue(0))).value; with value = tokens.getValue(0).getValue();
Actions taken:
January 9, 2012: received issue
January 7, 2013: closed issue

Issue 17168: Spurious comment on operation PinActivation::fire (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/11-02-01)    Subclause: 8.6.2.2.8 PinActivation         The operation PinActivation::fire includes the comment �[Note that a pin will consume all tokens offered to it, even if this is more than the multiplicity upper bound, but will only offer tokens up to that upper bound.]� However, this is not true in fUML as finalized. The incoming tokens passed to the fire operation are determined using the takeOfferedTokens operation, which is defined to �Take only a number of tokens only up to the limit allowed by the multiplicity upper bound of the pin for this activation.�

Resolution: agreed
Revised Text: In Subclause 8.6.2.2.8, in the fire operation, remove the comment �[Note that a pin will consume all tokens offered to it, even if this is more than the multiplicity upper bound, but will only offer tokens up to that upper bound.]�.
Actions taken:
February 23, 2012: received issue
January 7, 2013: closed issue

Discussion:

Issue 17200: Error in RemoveStructuralFeatureVauleActionActivation::doAction (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0    Subclause: 8.6.3.2.12 RemoveStructuralFeatureValueActionActivation         The following conditional appears toward the end of the specification of the RemoveStructuralFeatureValueActionActivation::doAction() operation:         if (featureValue.values.size() <= removeAt) {        featureValue.values.remove(removeAt - 1);    }         The �<=� operator in the condition should instead be �>=�.

Resolution: agreed
Revised Text: In Subclause 8.6.3.2.12, in doAction operation, in the condition �featureValue.values.size() <= removeAt�, replace �<=� with �>=�.
Actions taken:
February 25, 2012: received issue
January 7, 2013: closed issue

Issue 17201: Bug in DestroyObjectActivation::objectIsComposite (fuml-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Destroying an object (with "isDestroyLinks" = true) can potentially result in an infinite loop, since the loop variable "i" is never incremented.      Solution:   while (!isComposite & i <= linkFeatureValues.size()) {        FeatureValue featureValue = linkFeatureValues.getValue(i-1);        if (!featureValue.values.getValue(0).equals(reference) &           ((Property)featureValue.feature).aggregation == AggregationKind.composite) {              isComposite = true;        }        i = i + 1;  }

Resolution: agreed
Revised Text: In Subclause 8.6.3.2.7 DestroyObjectActionActivation, in the objectIsComposite operation, add �i = i + 1;� at the end of the while loop
Actions taken:
February 28, 2012: received issue
January 7, 2013: closed issue

Issue 17203: Bug in ForkedToken::withdraw when the baseToken is a ForkedToken (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclause: 8.5.2.2.10 ForkedToken         ForkedToken::withdraw calls isWithdrawn() to check if its baseToken is withdrawn, and then withdraws it if that is false. The intent is that baseToken.withdraw() only be called once. However, if the baseToken is itself a ForkedToken, then calling withdraw() may only decrement the remainingOffersCount of that token, with isWithdrawn() only becoming true if this count goes to zero. This means that additional calls to withdraw() on the first ForkedToken may result in additional calls to withdraw() on its baseToken, prematurely reducing the remainingOffersCount for the baseToken.         This can be avoided by adding an explicit baseTokenIsWithdrawn flag to ForkedToken that is set when the baseToken is withdrawn and then checked to avoid further withdraws.

Resolution: agreed
Revised Text: In Subclause 8.5.2.2.10, and in Figure 8.27, add the attribute � baseTokenIsWithdrawn: Boolean. Indicates whether withdraw() has been called on the base token. In the withdraw operation, replace: if (!this.baseToken.isWithdrawn()) { this.baseToken.withdraw(); } with: if (!this.baseTokenIsWithdrawn & !this.baseToken.isWithdrawn()) { this.baseToken.withdraw(); // NOTE: This keeps a base token that is a forked token from being // withdrawn more than once, since withdrawing a forked token may // not actually remove it from its fork node holder. this.baseTokenIsWithdrawn = true; }
Actions taken:
February 28, 2012: received issue
January 7, 2013: closed issue

Issue 17205: Error in ActivityNodeActivationGroup::getOutputParameterNodeActivations (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)     Subclause: 8.5.2.2.5 ActivityNodeActivationGroup         The ActivityNodeActivationGroup::getOutputParameterNodeActivations operation is supposed to return the output ActivityParameterNodeActivations for an Activity. As currently specified, it finds all the ActivityParameterNodes for parameters with direction inout, out and return. However, inout parameters actually have two ActivityParameterNodes: one for input and one for output. The current specification results in the operation incorrectly returning both the input and output nodes for an inout parameter.         The UML well-formedness constraints require that an input ActivityParameterNode only have outgoing edges and that and output ActivityParameterNode only have incoming edges. Therefore, instead of checking the parameter to determine output nodes, getOutputParameterNodeActivations should instead check whether the node activation has incoming edges.

Resolution: agreed
Revised Text: In Subclause 8.5.2.2.5, in the getOutputParameterNodeActivations operation, replace: ParameterDirectionKind direction = ((ActivityParameterNode) (activation.node)).parameter.direction; if ((direction.equals(ParameterDirectionKind.inout)) | (direction.equals(ParameterDirectionKind.out)) | (direction.equals(ParameterDirectionKind.return_))) { with: if (activation.incomingEdges.size() > 0) {
Actions taken:
February 29, 2012: received issue
January 7, 2013: closed issue

Issue 17209: Error handling creation and destruction of links of associations with ordered ends (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)    Subclause: 8.3.2.2.11 Link         The behavior of the Link::setFeatureValue operation results in the FeatureValues for an ordered end to be totally ordered by �position� across all links of an association. However, when a new link is created, the insertAt position for an ordered end isn�t relative to all links but only relative to links for which the other ends have the same values as the link being created. This means that the FeatureValues of the ordered ends of the new link may not be inserted at the correct position.

Resolution: agreed
Revised Text: In Subclause 8.5.2.2.11 and Figure 8.12, add the following operations to the Link class: � isMatchingLink(link: ExtensionalValue, end: Property): Boolean // Test whether the given link matches the values of this link on all // ends other than the given end. PropertyList ends = this.type.memberEnd; boolean matches = true; int i = 1; while (matches & i <= ends.size()) { Property otherEnd = ends.getValue(i - 1); if (otherEnd != end & !this.getFeatureValue(otherEnd).values.getValue(0).equals( link.getFeatureValue(otherEnd).values.getValue(0))) { matches = false; } i = i + 1; } return matches; � getOtherFeatureValues(extent: ExtensionalValue[*], end: Property) // Return all feature values for the given end of links in the given // extent whose other ends match this link. FeatureValueList featureValues = new FeatureValueList(); for (int i = 0; i < extent.size(); i++) { ExtensionalValue link = extent.getValue(i); if (link != this) { if (isMatchingLink(link, end)) { featureValues.addValue(link.getFeatureValue(end)); } } } return featureValues; � addTo(locus: Locus) // Add this link to the extent of its association at the given locus. // Shift the positions of ends of other links, as appropriate, for ends // that are ordered. Debug.println("[addTo] link = " + this.objectId()); PropertyList ends = this.type.memberEnd; ExtensionalValueList extent = locus.getExtent(this.type); for (int i = 0; i < ends.size(); i++) { Property end = ends.getValue(i); if (end.multiplicityElement.isOrdered) { FeatureValue featureValue = this.getFeatureValue(end); FeatureValueList otherFeatureValues = this.getOtherFeatureValues(extent, end); int n = otherFeatureValues.size(); if (featureValue.position < 0 | featureValue.position > n) { featureValue.position = n + 1; } else { if (featureValue.position == 0) { featureValue.position = 1; } for (int j = 0; j < otherFeatureValues.size(); j++) { FeatureValue otherFeatureValue = featureValues.getValue(j); if (featureValue.position <= otherFeatureValue.position) { otherFeatureValue.position = otherFeatureValue.position + 1; } } } } } locus.add(this); Remove the (overriding) operation getFeatureValue. In Subclause 8.6.3.2.1 AddStructuralFeatureValueActionActivation, in operation doAction, replace the �else� part of the if statement beginning �if (action.isReplaceAll)� with: if (feature.multiplicityElement.isUnique) { int i = 1; boolean destroyed = false; while (!destroyed & i <= links.size()) { Link link = links.getValue(i - 1); FeatureValue featureValue = link.getFeatureValue(feature); if (featureValue.values.getValue(0).equals(inputValue)) { position = link.getFeatureValue(oppositeEnd).position; link.destroy(); destroyed = true; } i = i + 1; } } Subsequently in the code, remove the lines // This necessary when setting a feature value with an insertAt position newLink.locus = this.getExecutionLocus(); and replace the statement newLink.locus.add(newlink); with: newlink.addTo(this.getExecutionLocus()); Finally, remove the statement: if (insertAt > 0 & j < insertAt) { insertAt = insertAt - 1; } In Subclause 8.6.3.2.4 CreateLinkActionActivation, in operation doAction, replace the code starting at the comment �// This necessary when setting a feature value with an insertAt position� to the end of the operation with: for (int i = 0; i < endDataList.size(); i++) { LinkEndCreationData endData = endDataList.getValue(i); int insertAt = 0; if (endData.insertAt != null) { insertAt = ((UnlimitedNaturalValue) (this .takeTokens(endData.insertAt).getValue(0))).value.naturalValue; } newLink.setFeatureValue(endData.end, this.takeTokens(endData.value), insertAt); } newLink.addTo(this.getExecutionLocus());
Actions taken:
March 3, 2012: received issue
January 7, 2013: closed issue

Discussion:

Issue 17211: ExecutionFactoryL2::instantiateVistor duplicates code from ExecutionFactorL3::instatiateVistor (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: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)         Subclause: 8.2.3.2.1 ExecutionFactoryL2    The code listed under operation [1] instantiateVisitor for class ExecutionFactoryL2 accidentally duplicates code from ExecutionFactoryL3.instantiateVisitor. The code of ExecutionFactoryL2.instantiateVisitor should be modified to properly cover L2 elements.

Resolution: agreed
Revised Text: In Subclause 8.2.3.2.1, in the instantiateVisitor operation, replace all the code with: // Instantiate a visitor object for the given element (at Conformance // Level 2) SemanticVisitor visitor = null; if (element instanceof Activity) { visitor = new ActivityExecution(); } else if (element instanceof ActivityParameterNode) { visitor = new ActivityParameterNodeActivation(); } else if (element instanceof InitialNode) { visitor = new InitialNodeActivation(); } else if (element instanceof ActivityFinalNode) { visitor = new ActivityFinalNodeActivation(); } else if (element instanceof JoinNode) { visitor = new JoinNodeActivation(); } else if (element instanceof MergeNode) { visitor = new MergeNodeActivation(); } else if (element instanceof ForkNode) { visitor = new ForkNodeActivation(); } else if (element instanceof DecisionNode) { visitor = new DecisionNodeActivation(); } else if (element instanceof InputPin) { visitor = new InputPinActivation(); } else if (element instanceof OutputPin) { visitor = new OutputPinActivation(); } else if (element instanceof CallBehaviorAction) { visitor = new CallBehaviorActionActivation(); } else if (element instanceof CallOperationAction) { visitor = new CallOperationActionActivation(); } else if (element instanceof SendSignalAction) { visitor = new SendSignalActionActivation(); } else if (element instanceof ReadSelfAction) { visitor = new ReadSelfActionActivation(); } else if (element instanceof TestIdentityAction) { visitor = new TestIdentityActionActivation(); } else if (element instanceof ValueSpecificationAction) { visitor = new ValueSpecificationActionActivation(); } else if (element instanceof CreateObjectAction) { visitor = new CreateObjectActionActivation(); } else if (element instanceof DestroyObjectAction) { visitor = new DestroyObjectActionActivation(); } else if (element instanceof ReadStructuralFeatureAction) { visitor = new ReadStructuralFeatureActionActivation(); } else if (element instanceof ClearStructuralFeatureAction) { visitor = new ClearStructuralFeatureActionActivation(); } else if (element instanceof AddStructuralFeatureValueAction) { visitor = new AddStructuralFeatureValueActionActivation(); } else if (element instanceof RemoveStructuralFeatureValueAction) { visitor = new RemoveStructuralFeatureValueActionActivation(); } else if (element instanceof ReadLinkAction) { visitor = new ReadLinkActionActivation(); } else if (element instanceof ClearAssociationAction) { visitor = new ClearAssociationActionActivation(); } else if (element instanceof CreateLinkAction) { visitor = new CreateLinkActionActivation(); } else if (element instanceof DestroyLinkAction) { visitor = new DestroyLinkActionActivation(); } else { visitor = super.instantiateVisitor(element); } return visitor;
Actions taken:
March 6, 2012: received issue
January 7, 2013: closed issue

Issue 17213: ActionActivation.sendOffers(): Missing sending of offers on outgoing control flows? (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: Uncategorized Issue
Severity:
Summary:

It seems that in ActionActivation.sendOffers(), a loop for sending a control token on outgoing edges is missing. The code should probably be completed with something like:         // *** Send offers on all outgoing edges concurrently. ***    ActivityEdgeInstanceList outgoingEdges = this.outgoingEdges;    for (Iterator i = outgoingEdges.iterator(); i.hasNext();) {    ActivityEdgeInstance outgoingEdge = (ActivityEdgeInstance)i.next();    TokenList tokens = new TokenList();    tokens.addValue(new ControlToken());    outgoingEdge.sendOffer(tokens);    }

Resolution: agreed
Revised Text: In Subclause 8.6.2.2.1 ActionActivation, add the following to the end of operation [15] sendOffers(): // Send offers on all outgoing control flows. if (this.outgoingEdges.size() > 0) { TokenList tokens = new TokenList(); tokens.addValue(new ControlToken()); this.addTokens(tokens); this.outgoingEdges.getValue(0).sendOffer(tokens); }
Actions taken:
March 8, 2012: received issue
January 7, 2013: closed issue

Issue 17270: Structural Feature Actions on Data Values Need to Create a new Result Value (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclauses: 8.6.3.2.1 AddStructuralFeatureValueActionActivation, 8.6.3.2.3 ClearStructuralFeatureActionActivation, 8.6.3.2.12 RemoveStructuralFeatureValueAction         Data values are not mutable, so, when given a data value, the structural feature actions are supposed to produce a new data value on the result pin, with the same feature values as for the input data value except for the structural feature on which the action acts. However, the current specifications for the activations of these actions do not copy the value before modifying it, resulting in an incorrect �in place� modification of the feature value of the original data value.

Resolution: Agreed, with the understanding that the term �data value� means specifically an instance of a data type, not an object, which is an instance of a class. Only objects are passed as references, which allows them to be updated mutably. Any value that is not a reference is to be considered an immutable data value.
Revised Text: In Subclauses 8.6.3.2.1, 8.6.3.2.3 and 8.6.3.2.12, in the respective doAction operations, after �} else if (value instanceof StructuredValue) {�, insert: // If the value is a data value, then it must be copied before // any change is made. if (!(value instanceof Reference)) { value = value.copy(); }
Actions taken:
March 23, 2012: received issue
January 7, 2013: closed issue

Discussion:

Issue 17282: Error in check for enable nodes (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclauses: 8.5.2.2.5 ActivityNodeActivationGroup, 8.5.3.2.4 StructuredActivityNodeActivation         The ActivityNodeActivationGroup::run operation checks which of the node activations in a given set are initially enabled. It does this using the checkIncomingEdges operation to check whether a node has incoming edges with a source within the given set of node activations. The checkIncomingEdges operation in turn uses the ActivityNodeActivation::sourceFor operation to check if an activity node activation is the source for a given activity edge instance. By default, this is true if the activity node activation is the source of the activity edge instance. The sourceFor operation is overridden in ActionActivation to account for the fact that outgoing control flows are attached to an ActionActivation via an anonymous fork node but, otherwise, the default behavior is used.         With the current specification for sourceFor, if a node activation has an incoming edge instance from within a structured activity node activation, rather than from the structured activity node itself, the structured activity node activation will not be considered the source for the edge instance, and the current specification for checkIncomingEdges does not look for sources inside structured activity nodes. This means that, if an activity node only has incoming edges with sources nested within a structured activity node, it may be spuriously considered to be enabled when it really has predecessor dependencies.

Resolution: agreed
Revised Text: In Figure 8.25, add the operation �hasSourceFor(edgeInstance: ActivityEdgeInstance): Boolean� to the class ActivityNodeActivationGroup, and add the following specification for it to Subclause 8.5.2.2.45 hasSourceFor(edgeInstance: ActivityEdgeInstance): Boolean // Returns true if this activation group has a node activation // corresponding to the source of the given edge instance. boolean hasSource = false; ActivityNodeActivationList activations = this.nodeActivations; int i = 1; while (!hasSource & i <= activations.size()) { hasSource = activations.getValue(i-1).isSourceFor(edgeInstance); i = i + 1; } return hasSource; In Figure 8.28, add the (overriding) operation �isSourceFor(edgeInstance: ActivityEdgeInstance): Boolean� to the class StructuredActivityNodeActivation, and add the following specification for it in Subclause 8.5.3.2.4: isSourceFor(edgeInstance: ActivityEdgeInstance): Boolean // Returns true if this node is either the source for the given // edgeInstance itself or if it contains the source in its // activation group. boolean isSource = super.isSourceFor(edgeInstance); if (!isSource) { isSource = this.activationGroup.hasSourceFor(edgeInstance); } return isSource;
Actions taken:
March 28, 2012: received issue
January 7, 2013: closed issue

Issue 17288: ExpansionRegionActivation does not reset its activationGroups (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)  Subclause: 8.5.4.2.3 ExpansionRegionActivation         ExpansionRegionActivation creates a set of activation groups that it uses to run the contents of the expansion region for each input value. However, after an ExpansionRegionActivation fires, it does not clear its activationGroups attribute. This means that, if the same activation fires again (as might happen if it is within a loop), subsequent firings add additional activation groups to the set already created in previous firings. This results in spurious extra executions of the contents of the expansion region.         To avoid this, the statement �this.activationGroups.clear();� should be added before the loop in ExpansionRegionActivation::doStructuredActivity.

Resolution: agreed
Revised Text: In Subclause 8.5.4.2.3, in operation doStructuredActivity, before the statement �int n = this.inputExpansionTokens.getValue(0).tokens.size();� add the statement �this.activationGroups.clear();�.
Actions taken:
March 30, 2012: received issue
January 7, 2013: closed issue

Issue 17291: ForkNodeActivation does not clear its tokens on termination (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclause: 8.5.2.2.11 ForkNodeActivation         Unlike other control nodes, a fork node actually holds forked tokens pending their acceptance by downstream nodes. Therefore, when a ForkNodeActivation terminates, it needs to clear its held tokens, similarly to an ObjectNodeActivation. It currently does not do this, which means, if it is fired repeatedly in a loop node, and not all of its held tokens are accepted on previous iterations, it will be spuriously holding extra tokens on subsequent iterations.         Adding the following overriding method to ForkNodeActivation is sufficient, because ActivityNodeActivation::clearTokens() repeatedly withdraws held tokens until none are left, which will work even for multiply forked tokens.                         public void terminate() {                                    // Remove any offered tokens and terminate.                                         this.clearTokens();                                    super.terminate();                    } // terminate

Resolution: agreed
Revised Text: In Figure 8.27, add the (overriding) operation �terminate()� to the class ForkNodeActivation, and add the following specification for it in Subclause 8.5.2.2.11: terminate() // Remove any offered tokens and terminate. this.clearTokens(); super.terminate();
Actions taken:
April 6, 2012: received issue
January 7, 2013: closed issue

Issue 17298: ExpansionRegionActivation isReady condition is too strong (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclause: 8.5.4.2.3 ExpansionRegionActivation         The specification for ExpansionRegionActivation::isReady() requires that each of the input expansion nodes for an expansion region have the same (non-zero) number of values offered to it before the expansion region can fire. In particular, this means that if an expansion region receives null tokens representing �empty collections�, then the expansion region will not fire. This may seem to be the same as having the expansion region fire and do nothing, except that, if the region does not actually fire, then it does not offer control tokens on any outgoing control flows and any node downstream of those flows will be inhibited from firing. This does not like a reasonable limiting case of expansion region semantics on �empty� collections, and, in fact, it seems to violate what would be expected from the semantics of expansion regions as described in the full UML spec.         The requirement for all input expansion nodes to have the same number of values also seems to strong, requiring careful sizing of all expansion inputs lest the region not be able to fire. Instead, the size of the smallest input collection could be used to govern the number of executions of the body of the expansion region, to insure there are parallel inputs available from each input expansion node for each body execution.

Resolution: agreed
Revised Text: In Section 8.5.4.2.3, in operation takeOfferedTokens, before the second for loop, add the statement: int n = this.numberOfValues(); Within the second for loop, replace the statements TokenSet tokenSet = new TokenSet(); tokenSet.tokens = expansionNodeActivation.takeTokens(); with TokenList tokens = expansionNodeActivation.takeTokens(); TokenSet tokenSet = new TokenSet(); int j = 1; while (j <= n) { tokenSet.tokens.add(tokens.getValue(j-1)); j = j + 1; } Remove the (overriding) operation isReady (and remove it in Figure 8.29). In operation runGroup, in the second for loop, replace the statement groupInput.addToken(tokenSet.tokens .getValue(activationGroup.index - 1)); with if (tokenSet.tokens.size() >= activationGroup.index) { groupInput.addToken(tokenSet.tokens .getValue(activationGroup.index - 1)); } And replace the entire specification for the operation numberOfValues with // Return the number of values to be acted on by the expansion region of // this activation, which is the minimum of the number of values offered // to each of the input expansion nodes of the activation. ExpansionRegion region = (ExpansionRegion) (this.node); ExpansionNodeList inputElements = region.inputElement; int n = this.getExpansionNodeActivation(inputElements.getValue(0)) .countOfferedValues(); int i = 2; while (i <= inputElements.size()) { int count = this.getExpansionNodeActivation( inputElements.getValue(i - 1)).countOfferedValues(); if (count < n) { n = count; } i = i + 1; } return n;
Actions taken:
April 10, 2012: received issue
January 7, 2013: closed issue

Issue 17299: LoopNodeActivation does not properly handle termination due to an activity final node (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclause: 8.5.3.2.3 LoopNodeActivation         If an activity final node directly owned by a loop node fires, then the loop node should terminate. However, the loop node should still produce values on its output pins based on any computations that have happened so far. Currently, when such an activity final node fires, the enclosing loop node is indeed immediately terminated via a call to its terminate(), but this does not actually terminate the loop in LoopNodeActivation::doStructuredActivity(). That loop only terminates once the test part of the loop executes, producing a null value (since all its nodes will no longer be running), which is interpreted as false. Further, the prior call to terminate() removes all tokens from the output pins in the body part of the loop, meaning that they are no longer available to be moved to the output pins of the loop node. As a result, the loop node produces no output, even if outputs have been computed prior to the firing of the final node.

Resolution: Agreed. Note that the modification of ActivityFinalNodeActivation in the revised text below to use a terminateAll operation from StructuredActivityNodeActivation allows this new operation to be overridden in LoopNodeActivation to specify �last wishes before termination� functionality.
Revised Text: In Subclause 8.5.2.2.3 ActivityFinalNodeActivation, replace the specification for fire with // Terminate the activity execution or structured node activation // containing this activation. Debug.println("[fire] Activity final node " + this.node.name + "..."); if (this.group.activityExecution != null) { this.group.activityExecution.terminate(); } else { this.group.containingNodeActivation.terminateAll(); } In Subclause 8.5.3.2.4 StructuredActivityNodeActivation, replace the specification of the operation terminate with // Terminate the execution of all contained node activations (which // completes the performance of the structured activity node // activation), and then terminate this node itself. this.terminateAll(); super.terminate(); In Figure 8.28, add the operation �terminateAll()� to the class StructuredActivityNodeActivation, and add the following specification for it in Subclause 8.5.3.2.4: terminateAll() // Terminate the execution of all contained node activations (which // completes the performance of the structured activity node // activation). this.activationGroup.terminateAll(); In Subclause 8.5.3.2.3, in operation doStructuredActivity, in the do loop, in the else part of the if statement following the comment �Run the loop�, replace the statement continuing = this.runTest(); with if (this.isRunning()) { continuing = this.runTest(); } After the if statement, replace the statement this.activationGroup.terminateAll(); with if (this.isRunning()) { this.activationGroup.terminateAll(); } else { continuing = false; } After the do loop, surround the final for loop with an if statement �if (this.isRunning()) { � }�. In Figure 8.28, add the (overriding) operation �terminateAll()� to the class LoopNodeActivation, and add the following specification for it to Subclause 8.5.3.2.3: terminateAll() // Copy the values of the body outputs to the loop outputs, and then // terminate all activations in the loop. OutputPinList resultPins = ((LoopNode)this.node).result; for (int i = 0; i < bodyOutputLists.size(); i++) { Values bodyOutputList = bodyOutputLists.getValue(i); OutputPin resultPin = resultPins.getValue(i); this.putTokens(resultPin, bodyOutputList.values); } super.terminateAll();
Actions taken:
April 10, 2012: received issue
January 7, 2013: closed issue

Issue 17300: An activity final node should not fire if it is not offered any tokens (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclause: 8.5.2.2.3 ActivityFinalNodeActivation         ActivityFinalNodeActivation::fire(incomingTokens) currently terminates the activity node activation group containing the activity final node, even if incomingTokens is empty. This is normally not a problem, since fire is usually only called if at least one token has been offered. However, if the activity final node is in a loop node or a conditional clause with an incoming edge from the body of the loop node or clause, then, when the test for the loop node or clause is being executed, the body part is not yet activated. If the source of the incoming edge to the activity final node is a body part node that is not activated, then the edge will be ignored in determining whether the final node is enabled, resulting in the final node being considered enabled and, unless otherwise prevented, firing  prematurely, terminating the enclosing loop node or conditional node.

Resolution: Agreed. Note that the revised text below also includes a check for the final node having no incoming edges at all (which is valid), so that, in this case, it will fire when enabled, even though it will have no incoming tokens.
Revised Text: In Subclause 8.5.2.2.3, in operation fire, surround the termination functionality in the if statement if (incomingTokens.size() > 0 | this.incomingEdges.size() == 0) { � }
Actions taken:
April 10, 2012: received issue
January 7, 2013: closed issue

Issue 17311: Having a fork node as initial enabled node does not work (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:

If a fork node is identified as initial enabled node in the method ActivityNodeActivationGroup.run(ActivityNodeActivationList), and the method ActivityNodeActivation.receiveOffer() is called for the ForkNodeActivation, the method ForkNodeActivation.fire(TokenList) does not produce any forked tokens (because there is no real incoming token for the fork node) and because of this, the method call this.sendOffers(forkedTokens) (last statement of the method ForkNodeActivationActivation.fire(TokenList)) does not result in offers sent to successor nodes but this should be possible.

Resolution: A fork node is required to have a single incoming edge (this is Constraint [1] under Subclause 12.3.30 ForkNode in the UML Superstructure spec, constraints from which also apply to fUML). The intent is that a fork node only generates forked tokens based on tokens offered to it on that one incoming edge. More specifically, consider that the only way a fork node can be initially enabled (in fUML) is if the source for its one incoming edge is either outside the activity node activation group containing the fork node activation or it is in the same activation group but not yet activated. The first case occurs when the fork node is contained a structured node but is the target of an edge crossing into the structured node from a source outside it. In this case, receiveOffer is called on the (enabled) fork node activation when the structured node fires, and this operation in turn calls takeOfferedTokens, which accepts any tokens offered on the incoming edge into the fork node. If tokens have been offered on that edge previously to the structured node firing, then the fork node activation will create forked tokens for them and offer them on the outgoing edges from the fork node. On the other hand, if no tokens have been offered, then the fork node activation does nothing further, which is correct. The second case occurs when the fork node is part of a conditional node or a loop node and the source of the incoming edge is an action or pin within the same node. The executable nodes for a conditional or loop node are divided up into test and body parts, which are activated incrementally per the semantics of the containing nodes. Contained control nodes, however, are always activated unconditionally (or, in the case of a loop, on each iteration). If a fork node is thus activated before the source of its incoming edge is, then it is not possible for anything to have been offered on that edge yet and, therefore, it is correct that the fork node should not offer anything on its outgoing edges. If that source node is later activated and does eventually offer something on the edge to the fork node, then that will trigger another call to receiveOffer on the fork node activation, which will result in forked nodes being offered on outgoing edges as appropriate. So, the current semantics for fork nodes are actually correct. Revised Text: None. Disposition: Closed, No Change
Revised Text:
Actions taken:
April 16, 2012: received issue
January 7, 2013: closed issue

Issue 17312: DecisionNodeActivation can send offers to multiple outgoing edges (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 method DecisionNodeActivation.fire(TokenList), a token offer is sent to each outgoing edge for which the guard evaluates to true resulting in the execution of multiple successor nodes.   Only one successor node should receive an offer also if the guards of several outgoing edges evaluate to true.

Resolution: In Subclause 12.3.22 DecisionNode of the UML Superstructure specification, it says: �Notice that the semantics only requires that the token [offered to a decision node] traverse one edge, rather than be offered to only one edge. Multiple edges may be offered the token, but if only one of them has a target that accepts the token, then that edge is traversed. If multiple edges accept the token and have approval from their targets for traversal at the same time, then the semantics is not defined.� Thus, it is correct that an incoming token to a decision node is offered on all outgoing edges for which the guard is satisfied. In fUML, if multiple downstream targets then try to accept the offered token at the same time, the semantics is the same as in any case of contention for a token. Only one of the targets can actually accept the token � since a decision node does not duplicate tokens, there is only one token to be accepted. Which of the targets actually gets the token is indeterminate, however. Revised Text: None. Disposition: Closed, No Change
Revised Text:
Actions taken:
April 16, 2012: received issue
January 7, 2013: closed issue

Issue 17314: Structured activity node activations do not wait for contained accept event action activations (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)  Subclauses: 8.5.2.2.5 ActivityNodeActivationGroup, 8.5.3.2.4 StructuredActivityNodeActivation, 8.6.4.2.1 AcceptEvent ActionActivation         When a structured activity node contains one or more accept even actions, then, when those actions are waiting for the reception of event occurrences, one would expect that the structured activity node as a whole would also be waiting, pending the triggering of the actions. As currently specified, when  accept event action activation registers to wait for event dispatching, it is not considered to be complete. Nevertheless, once all such actions have registered, and all other contained in a structured activity node have completed, the running of the node activations in the activation group for the structured node finishes, and the structured activity node activation completes, allowing execution to continue to subsequent nodes. This is not correct; the structured activity node activation should essentially be suspended until all the accept event actions activations have actually completed.

Resolution: agreed
Revised Text: In Figure 8.26, add the operations �suspend()� and �resume()� to the class ActivityNodeActivation, and add the following specifications for them to Subclause 8.5.2.2.4: suspend() // Suspend this activation within the activation group that contains it. this.group.suspend(this); resume() { // Resume this activation within the activation group that contains it. this.group.resume(this); In Figure 8.25, add an association from ActivityNodeActivationGroup to ActivityNodeActivation with end name suspendedActivations and multiplicity *, and add the following description of it to Subclause 8.5.2.2.5: � suspendedActivations: ActivityNodeActivation [*] Activity node activations in this activation group that are suspended waiting for an event occurrence. If an activation group has a containing node activation and any suspended activations, then the containing node activation will also be suspended. In Figure 8.25, add the operations �isSuspended(): Boolean�, �suspend(activation: ActivityNodeActivation)� and �resume(activation: ActivityNodeActivation)� to the class ActivityNodeActivationGroup, and add the following specifications for them to Subclause 8.5.2.2.5: isSuspended(): Boolean // Check if this activitation group has any suspended activations and is, // therefore, itself suspended. return this.suspendedActivations.size() > 0; suspend(activation: ActivityNodeActivation) // Suspend the given activation in this activation group. If this is // the only suspended activation, and the activation group has a // containing node activation, then suspend that containing activation. if (!this.isSuspended()) { StructuredActivityNodeActivation containingNodeActivation = this.containingNodeActivation; if (containingNodeActivation != null) { containingNodeActivation.suspend(); } } this.suspendedActivations.addValue(activation); resume(activation: ActivityNodeActivation) // Resume the given activation by removing it from the suspended // activation list for this activation group. If this is the last // suspended activation, and the activation group has a containing // node activation, then resume that containing activation. boolean found = false; int i = 1; while (!found & i <= this.suspendedActivations.size()) { if (this.suspendedActivations.get(i-1) == activation) { this.suspendedActivations.removeValue(i-1); found = true; } i = i + 1; } if (!this.isSuspended()) { StructuredActivityNodeActivation containingNodeActivation = this.containingNodeActivation; if (containingNodeActivation != null) { containingNodeActivation.resume(); } } In Figure 8.28, add the operations �isSuspended(): Boolean�, �completeAction(): Token[*]� and �resume()� to the class StructuredActivityNodeActivation, and add the following specifications for them in Subclause 8.5.3.2.4: isSuspended(): Boolean // Check if the activation group for this node is suspended. return this.activationGroup.isSuspended(); completeAction(): Token[*] // Only actually complete this structured activity node if it is not // suspended. TokenList incomingTokens = new TokenList(); if (!this.isSuspended()) { incomingTokens = super.completeAction(); } return incomingTokens; resume() // Only actually complete this structured activity node if it is not // suspended. TokenList incomingTokens = new TokenList(); if (!this.isSuspended()) { incomingTokens = super.completeAction(); } return incomingTokens; In Section 8.6.2.2.1 ActionActivation, in the operation fire, replace the body of the specification after the initial comment block with do { Debug.println("[fire] Action " + this.node.name + "..."); Debug.println("[event] Fire activity=" + this.getActivityExecution().getBehavior().name + " action=" + this.node.name); this.doAction(); incomingTokens = this.completeAction(); } while (incomingTokens.size() > 0); In Figure 8.31, add the operation �completeAction():Token[*]� to the class ActionActivation, and add the following specification for it in Section 8.6.2.2.1: completeAction(): Token[*] // Concurrently fire all output pin activations and offer a single // control token. Then check if the action should fire again // and, if so, return additional incoming tokens for this. this.sendOffers(); Debug.println("[fire] Checking if " + this.node.name + " should fire again..."); _beginIsolation(); TokenList incomingTokens = new TokenList(); this.firing = false; if (this.isReady()) { incomingTokens = this.takeOfferedTokens(); this.firing = this.isFiring() & incomingTokens.size() > 0; } _endIsolation(); return incomingTokens; In Subclause 8.6.4.2.1 AcceptEventActionActivation, in the accept operation, in the if statement, after �this.receiveOffer()�, add the statement: this.resume(); In the fire operation, at the end of the specification, add the statement: this.suspend();
Actions taken:
April 16, 2012: received issue
January 7, 2013: closed issue

Discussion:

Issue 17345: Correction to the resolution of Issue 17209 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)  Subclause: 8.3.2.2.11 Link         The resolution to Issue 17209 (Error handling creation and destruction of links of associations with ordered ends) included the addition of an addTo operation to the Link class. The specification of this new operation contains the statement:         FeatureValue otherFeatureValue = featureValues.getValue(j);         This should, instead, have been:         FeatureValue otherFeatureValue = otherFeatureValues.getValue(j);         Also, the resolution didn�t not the need to update Figure 8.12 to reflect the addition to Link of the operations isMatchingLink, getOtherFeatureValues and addTo, and the removal of the operation getFeatureValue.

Resolution: agreed
Revised Text: In Subclause 8.3.2.2.11, in the addTo operation, replace the statement FeatureValue otherFeatureValue = featureValues.getValue(j); with FeatureValue otherFeatureValue = otherFeatureValues.getValue(j); In Figure 8.12, add the following operations to the Link class: isMatchingLink(link : ExtensionalValue, end : Property) : Boolean getOtherFeatureValues(extent : ExtensionalValueList[*], end : Property) : FeatureValue[*] addTo(Locus locus) and remove the operation getFeatureValue.
Actions taken:
April 29, 2012: received issue
January 7, 2013: closed issue

Issue 17346: Read link actions and read structural feature actions do not handle ordered ends correctly (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)  Subclause: 8.6.3.2.9 ReadLinkActionActivation, 8.6.3.2.13 StructuralFeatureActionActivation         Read link actions and read structural feature actions do not always return the values for an ordered association end in the correct order. In ReadLinkActionActivation::doAction, after the loop searching for the position at which to insert a featureValue, the statement         featureValues.addValue(k-1, featureValue);         should be replaced with         if (continueSearching) {        featureValue.addValue(featureValue);    } else {        featureValue.addValue(k-1, featureValue);    }         in order to correctly handle the case in which the featureValue should be added at the end of the list.         There is a similar statement in StructuralFeatureActionActivation::getMatchingLinks to insert a link at the correct position in the list of matching links, and it should be replaced in a similar manner to the above.

Resolution: agreed
Revised Text: In Subclause 8.6.3.2.9, in the doAction operation, within the first for loop, after the while loop, replace the statement featureValues.addValue(k-1, featureValue); with if (continueSearching) { featureValue.addValue(featureValue); } else { featureValue.addValue(k-1, featureValue); } In Subclause 8.6.3.2.13, in the getMatchingLinks operation, after the while loop, replace the statement links.addValue(j�1, (Link)link); with if (continueSearching) { links.addValue((Link)link); } else { links.addValue(j�1, (Link)link); }
Actions taken:
April 29, 2012: received issue
January 7, 2013: closed issue

Issue 17391: Error in setting result pin values for CallActions (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)  Subclause: 8.6.2.2.2 CallActionActivation         At the end of CallActionActivation::doAction, the output parameter values from the call execution are placed on the result output pins of the call action. However, the current specification presumes that the parameter values from the execution will be in the same order as the output parameters (and output pins). But this will not always be the case.          For example, if a parameter is an inout parameter, then it will have a parameter value added to the execution with its input before the execution is executed. It�s output will then be written to this existing output parameter value, while parameter values for out parameters will be created ordered after the one for the inout parameter, even if the out parameters are ordered before the inout parameter. Thus, the wrong values will be copied to the output pins.         Instead of relying on ordering, the specification for doAction should us the parameter reference for each output parameter value to identify the correct result output pin to which the parameter value should be written.

Resolution: agreed
Revised Text: In Subclause 8.6.2.2.2, in the doAction operation, near the end, replace the text for (int j = 0; j < outputParameterValues.size(); j++) { ParameterValue outputParameterValue = outputParameterValues.getValue(j); OutputPin resultPin = resultPins.getValue(j);? this.putTokens(resultPin, outputParameterValue.values); } with pinNumber = 1; i = 1; while (i <= parameters.size()) { Parameter parameter = parameters.getValue(i - 1); if ((parameter.direction == ParameterDirectionKind.inout) | (parameter.direction == ParameterDirectionKind.out) | (parameter.direction == ParameterDirectionKind.return_)) { for (int j = 0; j < outputParameterValues.size(); j++) { ParameterValue outputParameterValue = outputParameterValues.getValue(j); if (outputParameterValue.parameter == parameter) { OutputPin resultPin = resultPins.getValue(pinNumber - 1); this.putTokens(resultPin, outputParameterValue.values); } } pinNumber = pinNumber + 1; } i = i + 1; }
Actions taken:
May 23, 2012: received issue
January 7, 2013: closed issue

Issue 17392: Addition to resolution to Issue 17299 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)  Subclause: 8.5.2.2.3 ActivityFinalNodeActivation         The resolution to Issue 17299 did not take into account, in the revision to ActivityFinalNodeActivation::fire, that the group for the ActivityFinalNodeActivation may be an ExpansionActivationGroup, which has a regionActivation property set instead of containingNodeActivation.

Resolution: Agreed. In addition to modifying ActivityFinalNodeActivation, to call the terminate operation on an enclosing expansion region, it is necessary to modify the ExpansionRegionActivation to fire the outputs of the expansion region before it terminates (which is the problem identified in Issue 17299). (Note that the resolution to Issue 17300 also modified the ActivityFinalNodeActivation::fire operation.)
Revised Text: In Subclause 8.5.2.2.3, in the fire operation, replace the if statement, as introduced by the resolution to Issue 17299 and further modified by the resolution to Issue 17300, with if (incomingTokens.size() > 0 | this.incomingEdges.size() == 0) { if (this.group.activityExecution != null) { this.group.activityExecution.terminate(); } else if (this.group.containingNodeActivation != null) { this.group.containingNodeActivation.terminateAll(); } else if (this.group instanceof ExpansionActivationGroup){ ((ExpansionActivationGroup)this.group).regionActivation.terminate(); } } In Subclause 8.5.4.2.3, in operation terminate � In the terminate operation, replace the statement activationGroup.terminateAll(); with OutputPinActivationList groupOutputs = activationGroup.groupOutputs; _beginIsolation(); for (int j = 0; j < groupOutputs.size(); j++) { OutputPinActivation groupOutput = groupOutputs.getValue(j); groupOutput.fire(groupOutput.takeOfferedTokens()); } activationGroup.terminateAll(); _endIsolation(); � In the runGroup operation, surround the existing body of the operation with the if statement �if (this.isRunning()) { � }�. Further surround the statements after (but not including) the statement �activationGroup.run(activationGroup.nodeActivations);� with a similar if statement. (Note: the resolution to Issue 17499 proposes a further modification to this operation.)
Actions taken:
May 23, 2012: received issue
January 7, 2013: closed issue

Issue 17396: Errors in ReduceActionActivation::doAction (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)  Subclause: 8.6.4.2.6 ReduceActionActivation         The specification for ReduceActionActivation::doAction has a number of errors.         1. The test �input1 != null� should be �input1 == null�.         2. The test for �parameter.direction == ParameterDirectionKind.out� should also test for a parameter direction of return.         3. After the execution of the reducer behavior, parameterValue1 should not be set to the resulting ParameterValue. Instead, only parameterValue1.values should be set to the resulting values (parameterValue1.parameter should remain unchanged as being equal to input1).         4. There is no abstract syntax constraint that the output of the reducer cannot be empty. The semantics for a reduce action should take into account the possibility of the reducer returning no value and not try to feed an empty input into the next reducer call.

Resolution: Agreed. A reasonable approach for dealing with the reducer returning an empty value is to simply start the reduction computation over with the remaining values in the list.
Revised Text: In Subclause 8.6.4.2.6, in the doAction operation: 1. Nested within the first while loop, change the condition �input1 != null� to �input1 == null�. 2. Also nested within the first while loop, change the condition �parameter.direction == ParameterDirectionKind.out� to �parameter.direction == ParameterDirectionKind.out | parameter.direction == ParameterDirectionKind.return_�. 3. Within the second while loop, change the statement parameterValue1 = this.currentExecution.getParameterValue(output); to parameterValue1.values = this.currentExecution.getParameterValue(output).values; 4. Within the second while loop, after the statement �j = j + 1�, add: if (parameterValue1.values.isEmpty() & j <= values.size()) { parameterValue1.values.add(values.getValue(j - 1)); j = j + 1; }
Actions taken:
May 25, 2012: received issue
January 7, 2013: closed issue

Issue 17397: Null tokens are not sent on by control nodes (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)  Subclause: 8.5.2.2.15 ObjectNodeActivation         When an object node has no tokens, ObjectNodeActivation::sendOffers creates a null token to send. However, the holder attribute of this token is not set. This means that, even though the token gets offered, when a node tries to take it from the offering edge instance, the token is considered to have been withdrawn and is not passed on to the token. The effect of this is, in particular, that control node activations will never pass on null tokens, which is incorrect.         To avoid this, sendOffers should set the holder of the null token to be the object node sending it.

Resolution: agreed
Revised Text: In Subclause 8.5.2.2.15, in the sendOffers operation, replace the statement tokens.addValue(new ObjectToken()); with ObjectToken token = new ObjectToken(); token.holder = this tokens.addValue(token);
Actions taken:
May 28, 2012: received issue
January 7, 2013: closed issue

Issue 17499: Conditional node and loop node activations do not wait for contained accept event action activations (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)    Subclauses: 8.5.3.2.2 ConditionalNodeActivation, 8.5.3.2.3 LoopNodeActivation, 8.5.4.2.3 ExpansionRegionActivation         The resolution to Issue 17314 (Structured activity node activations do not wait for contained accept event action activations), on adopted on Ballot 2 of the fUML 1.1 RTF, works for plain structured activity nodes, but it does not work for structured activity nodes that are conditional nodes, loop nodes or expansion regions. For conditional nodes, the resumption of suspension of the node must take place in the context of a specific conditional clause. For loop nodes, resumption must allow continued iteration of the loop, rather than just completion of the node activation. For expansion regions, resumption must take place in the context of a specific expansion activation group.

Resolution: Agreed. In order to simplify the resolution, it seems unnecessary to allow accept event actions within the test parts of conditional node clauses or loop nodes. Such tests are supposed to be �side effect free� and waiting for an external event to happen is essentially a non-functional side effect. If accept event actions are not allowed in tests, then, for a conditional node, suspension and resumptiuon can only happen in the body of a selected clause with a true test and, for a loop node, it can only happen in the body of the loop.
Revised Text: (Note: The revisions given here presume the revisions given in the resolution to Issue 17314.) In Subclause 7.5.4.1, Figure 7.37, add a note to ReduceAction with the body �An accept event action may not be contained directly or indirectly in the test part of a clause or loop node.� In Subclause 7.5.4.2.1 AcceptEventAction, add the following under �Additional Constraints�: [4] fUML_no_accept_event_action_in_tests An accept event action may not be contained directly or indirectly in the test part of a clause or loop node. self->closure(inStructuredNode.oclAsType(ActivityNode))->forAll(n | let s : StructuredActivityNode = n.inStructuredNode in s->notEmpty() implies (s.oclIsType(ConditionalNode) implies s.clause.test->excludes(n) and s.oclIsType(LoopNode) implies s.test->excludes(n))) In Subclause 8.5.3.1, Figure 8.28: � In the class ConditionalNodeActivation, add the following operations: completeBody() completeAction(): Token[*] resume() � In the class LoopNodeActivation, add the following operations: doLoop(continuing : Boolean) saveBodyOutputs() resume() continueLoop() In Subclause 8.5.3.2.2 ConditionalNodeActivation: � At then end of the operation doStructuredActivity, remove the following statements: OutputPinList resultPins = node.result; OutputPinList bodyOutputPins = selectedClause.bodyOutput; for (int k = 0; k < resultPins.size(); k++) { OutputPin resultPin = resultPins.getValue(k); OutputPin bodyOutputPin = bodyOutputPins.getValue(k); this.putTokens(resultPin, this.getPinValues(bodyOutputPin)); } � Add the following operations: completeBody() // Complete the activation of the body of a conditional note by // copying the outputs of the selected clause (if any) to the output // pins of the node and terminating the activation of all nested nodes. if (this.selectedClause != null) { ConditionalNode node = (ConditionalNode) (this.node); OutputPinList resultPins = node.result; OutputPinList bodyOutputPins = this.selectedClause.bodyOutput; for (int k = 0; k < resultPins.size(); k++) { OutputPin resultPin = resultPins.getValue(k); OutputPin bodyOutputPin = bodyOutputPins.getValue(k); this.putTokens(resultPin, this.getPinValues(bodyOutputPin)); } } this.activationGroup.terminateAll(); completeAction() : Token[0..*] // Only complete the conditional node if it is not suspended. if (!this.isSuspended()) { completeBody(); } return super.completeAction(); resume() // When this conditional node is resumed after being suspended, complete // its body and then resume it as a structured activity node. // [Note that this presumes that accept event actions are not allowed // in the test part of a clause of a conditional node.] completeBody(); super.resume(); In Subclause 8.5.3.2.3 LoopNodeActivation: � At the end of the operation doStructuredActivity, replace the statements from �boolean continuing = true;� to the end of the operation specification with the single statement this.doLoop(true); � At the end of the operation runBody, replace the statements OutputPinList bodyOutputs = loopNode.bodyOutput; ValuesList bodyOutputLists = this.bodyOutputLists; for (int i = 0; i < bodyOutputs.size(); i++) { OutputPin bodyOutput = bodyOutputs.getValue(i); Values bodyOutputList = bodyOutputLists.getValue(i); bodyOutputList.values = this.getPinValues(bodyOutput); } with if (!this.isSuspended()) { this.saveBodyOutputs(); } � Add the following operations: doLoop(in continuing : Boolean) // If isTestedFirst is true, then repeatedly run the test part and the // body part of the loop, copying values from the body outputs to the // loop variables. // If isTestedFirst is false, then repeatedly run the body part and the // test part of the loop, copying values from the body outputs to the // loop variables. LoopNode loopNode = (LoopNode) (this.node); OutputPinList loopVariables = loopNode.loopVariable; OutputPinList resultPins = loopNode.result; while (continuing) { // Set loop variable values this.runLoopVariables(); for (int i = 0; i < loopVariables.size(); i++) { OutputPin loopVariable = loopVariables.getValue(i); Values bodyOutputList = bodyOutputLists.getValue(i); ValueList values = bodyOutputList.values; this.putPinValues(loopVariable, values); ((OutputPinActivation) this.activationGroup .getNodeActivation(loopVariable)).sendUnofferedTokens(); } // Run all the non-executable, non-pin nodes in the conditional // node. ActivityNodeActivationList nodeActivations = this.activationGroup.nodeActivations; ActivityNodeActivationList nonExecutableNodeActivations = new ActivityNodeActivationList(); for (int i = 0; i < nodeActivations.size(); i++) { ActivityNodeActivation nodeActivation = nodeActivations .getValue(i); if (!(nodeActivation.node instanceof ExecutableNode | nodeActivation.node instanceof Pin)) { nonExecutableNodeActivations.addValue(nodeActivation); } } this.activationGroup.run(nonExecutableNodeActivations); // Run the loop if (loopNode.isTestedFirst) { continuing = this.runTest(); if (continuing) { this.runBody(); } } else { this.runBody(); if (this.isRunning() & !this.isSuspended()) { continuing = this.runTest(); } } if (this.isRunning() && !this.isSuspended()) { this.activationGroup.terminateAll(); } else { continuing = false; } Debug.println("[doStructuredActivity] " + (continuing? "Continuing." : this.isSuspended()? "Suspended": "Done.")); } if (this.isRunning() && !this.isSuspended()) { for (int i = 0; i < bodyOutputLists.size(); i++) { Values bodyOutputList = bodyOutputLists.getValue(i); OutputPin resultPin = resultPins.getValue(i); this.putTokens(resultPin, bodyOutputList.values); } } saveBodyOutputs() // Save the body outputs for use in the next iteration. LoopNode loopNode = (LoopNode) this.node; OutputPinList bodyOutputs = loopNode.bodyOutput; ValuesList bodyOutputLists = this.bodyOutputLists; for (int i = 0; i < bodyOutputs.size(); i++) { OutputPin bodyOutput = bodyOutputs.getValue(i); Values bodyOutputList = bodyOutputLists.getValue(i); bodyOutputList.values = this.getPinValues(bodyOutput); } resume() // When this loop node is resumed after being suspended, continue with // its next iteration (if any). Once the loop has completed execution // without being suspended again, complete the action. LoopNode loopNode = (LoopNode) (this.node); this.saveBodyOutputs(); if (loopNode.mustIsolate) { _beginIsolation(); this.continueLoop(); _endIsolation(); } else { this.continueLoop(); } if (this.isSuspended()) { // NOTE: If the subsequent iteration of the loop suspends it again, // then it is necessary to remove the previous suspension from the // containing activity node activation group. this.group.resume(this); } else { super.resume(); } continueLoop() // Continue the loop node when it is resumed after being suspended. If // isTestedFirst is true, then continue executing the loop. If // isTestedFirst is false, then run the test to determine whether // the loop should be continued or completed. // [Note that this presumes that an accept event action is not allowed // in the test part of a loop node.] LoopNode loopNode = (LoopNode) (this.node); boolean continuing = true; if (!loopNode.isTestedFirst) { continuing = this.runTest(); } if (this.isRunning()) { this.activationGroup.terminateAll(); this.doLoop(continuing); } In Subclause 8.5.4.1, Figure 8.29: � In class ExpansionActivationGroup, add the following operations: suspend(activation : ActivityNodeActivation) resume(activation : ActivityNodeActivation) � In class ExpansionRegionActivation, add the attribute: next : Integer [0..1] and the following operations: runIterative() runParallel() doOutput() terminateGroup(activationGroup : ExpansionActivationGroup) isSuspended() : Boolean resume(activationGroup : ExpansionActivationGroup) In Subclause 8.5.4.2.1 ExpansionActivationGroup, add the following operations: suspend(in activation : ActivityNodeActivation) // Suspend the given activation in this activation group. If this is // the only suspended activation, then suspend the associated region // activation. if (!this.isSuspended()) { this.regionActivation.suspend(); } super.suspend(activation); resume(in activation : ActivityNodeActivation) // Resume the given activation in this activation group. If this is the // last suspended activation, then resume the associated region // activation. super.resume(activation); if (!this.isSuspended()) { this.regionActivation.resume(this); } In Subclause 8.5.4.2.3 ExpansionRegionActivation: � Under �Attributes� replace �None� with � next : Integer [0..1] The index of the next activation group to be run, if the expansion region is iterative. � In the doStructuredActivity operation: o In the first branch of the if statement near the end, replace the statements for (int i = 0; i < activationGroups.size(); i++) { ExpansionActivationGroup activationGroup = activationGroups .getValue(i); this.runGroup(activationGroup); } with the statements this.next = 1; this.runIterative(); o In the second branch of the if statement, replace the statements // *** Activate all groups concurrently. *** for (Iterator i = activationGroups.iterator(); i.hasNext();) { ExpansionActivationGroup activationGroup = (ExpansionActivationGroup) i .next(); this.runGroup(activationGroup); } with the single statement this.runParallel(); o Replace the for loop at the end with the single statement this.doOutput(); � In the runGroup operation, replace the following statements (as already modified per the resolution to Issue 17392) if (this.isRunning()) { // Added OutputPinActivationList groupOutputs = activationGroup.groupOutputs; for (int i = 0; i < groupOutputs.size(); i++) { OutputPinActivation groupOutput = groupOutputs.getValue(i); groupOutput.fire(groupOutput.takeOfferedTokens()); } activationGroup.terminateAll(); } with this.terminateGroup(activationGroup); � Add the following operations: runIterative() // Run the body of the region iteratively, either until all activation // groups have run or until the region is suspended. ExpansionActivationGroupList activationGroups = this.activationGroups; while (this.next <= activationGroups.size() & !this.isSuspended()) { ExpansionActivationGroup activationGroup = activationGroups .getValue(this.next-1); this.runGroup(activationGroup); this.next = this.next + 1; } runParallel() // Run the body of the region concurrently. ExpansionActivationGroupList activationGroups = this.activationGroups; // *** Activate all groups concurrently. *** for (Iterator i = activationGroups.iterator(); i.hasNext();) { ExpansionActivationGroup activationGroup = (ExpansionActivationGroup) i .next(); this.runGroup(activationGroup); } doOutput() ExpansionRegion region = (ExpansionRegion) this.node; ExpansionNodeList outputElements = region.outputElement; Debug.println("[doOutput] Expansion region " + region.name + " is " + (this.isSuspended()? "suspended.": "completed.")); if (!this.isSuspended()) { for (int i = 0; i < activationGroups.size(); i++) { ExpansionActivationGroup activationGroup = activationGroups .getValue(i); OutputPinActivationList groupOutputs = activationGroup.groupOutputs; for (int j = 0; j < groupOutputs.size(); j++) { OutputPinActivation groupOutput = groupOutputs.getValue(j); ExpansionNode outputElement = outputElements.getValue(j); this.getExpansionNodeActivation(outputElement).addTokens( groupOutput.takeTokens()); } } } terminateGroup(in activationGroup : ExpansionActivationGroup) if (this.isRunning() & !this.isSuspended()) { OutputPinActivationList groupOutputs = activationGroup.groupOutputs; for (int i = 0; i < groupOutputs.size(); i++) { OutputPinActivation groupOutput = groupOutputs.getValue(i); groupOutput.fire(groupOutput.takeOfferedTokens()); } activationGroup.terminateAll(); } isSuspended() : Boolean // Check if the activation group for this node is suspended. boolean suspended = false; int i = 1; while (i <= this.activationGroups.size() & !suspended) { ActivityNodeActivationGroup group = this.activationGroups.get(i-1); suspended = group.isSuspended(); i = i + 1; } return suspended; resume(in activationGroup : ExpansionActivationGroup) // Resume an expansion region after the suspension of the given // activation group. If the region is iterative, then continue with the // iteration. If the region is parallel, and there are no more suspended // activation groups, then generate the expansion node output. ExpansionRegion region = (ExpansionRegion) this.node; this.resume(); this.terminateGroup(activationGroup); if (region.mode == ExpansionKind.iterative) { this.runIterative(); } this.doOutput();
Actions taken:
July 13, 2012: received issue
January 7, 2013: closed issue

Discussion:

Issue 17502: Specification of ClassifierBehaviorExecution and ObjectActivation are not consistent with Annex A (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)    Subclause: 8.4.3.2.1 ClassifierBehaviorExecution, 8.4.3.2.5 ObjectActivation         Subclause A.3.7 establishes the Java notation �_startObjectBehavior();� as mapping to a start object behavior action, not an operation call, and it also states that �A class may not define a user operation called �_startObjectBehavior.�� However, in Subclause 8.4.3.1, Figure 8.17, _startObjectBehavior is shown as an operation on both ClassifierBehaviorExecution and ObjectActivation, and it is specified in as an operation for these classes in Subclauses 8.4.3.2.1 and 8.4.3.2.5.          Subclause A.3.8 establishes the Java notation �_send(new <signal>());� as mapping to a send signal action, not an operation call. However, in Figure 8.17, _send is shown as an operation of ObjectActivation, and it is specified as an operation in Subclause 8.4.3.2.5.

Resolution: Agreed. Note also that the activity shown in Figure 8.18 has a call to _startObjectBehaviorAction and the activity shown in Figure 8.19 has a call to _send.
Revised Text: In Subclause 8.4.3.1, Figure 8.17: � In the class ClassifierBehaviorExecution, remove the operation _startObjectBehavior. � In the class ObjectActivation, remove the operations _startObjectBehavior and _send. In Subclause 8.4.3.2.1: � In Figure 8.18, replace the call operation action �Call _startObjectBehavior� with a read structural feature action for the feature �execution�, the result of which feeds into a call operation action for the operation �execute�. � Remove the specification for the operation _startObjectBehavior. In Subclause 8.4.3.2.5: � In Figure 8.19, replace the call operation action �Call _send� with a call to the operation �dispatchNextEvent� (which does not take any arguments). � Remove the specifications for the operations _startObjectBehavior and _send.
Actions taken:
July 16, 2012: received issue
January 7, 2013: closed issue

Issue 17557: Addition to the resolution to fUML Issue 15987 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to Issue 15987 (The fUML Foundational Model Library should support the new UML 2.4 Real primitive type) adds LiteralReal and LiteralRealEvaluations class, but neglects to update the ExecutionFactoryL1::instantiateVisitor operation to instatiate an instance of the latter class when given an instance of the former.

Resolution: agreed
Revised Text: In Subclause 8.2.2.2.3 ExecutorL1, in the specification for the instantiateVisitor operation, after the statement �return visitor;� add else if (element instanceof fUML.Syntax.Classes.Kernel.LiteralReal) { visitor = new LiteralRealEvaluation(); }
Actions taken:
August 21, 2012: received issue
January 7, 2013: closed issue

Issue 17558: Addition to the resolution of fUML Issue 17203 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to Issue 17203 (Bug in ForkedToken::withdraw when the baseToken is a ForkedToken) adds a Boolean baseTokenIsWithdrawn attribute to the ForkedToken class. However, since bUML (like fUML) does not support default values on attributes, this attribute needs to be explicitly set to false when a ForkedToken is created in ForkedNodeActivation::fire(). The resolution neglects to include this revision.

Resolution: agreed
Revised Text: In Subclause 8.5.2.2.11 ForkNodeActivation, in operation fire, in the for loop, after the statement �forkedToken.remainingOffersCount = outgoingEdgeCount;�, add token.baseTokenIsWithdrawn = false;
Actions taken:
August 21, 2012: received issue
January 7, 2013: closed issue

Issue 17559: Correction to the resolution to fUML Issue 17209 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

The Revised Text instructions in the resolution to Issue 17209 (Error handling creation and destruction of links of associations with ordered ends) includes the statement �Remove the (overriding) operation getFeatureValue.� However, Link does not have an overriding getFeatureValue operation. The correct instruction is to remove the setFeatureValue operation.

Resolution: agreed
Revised Text: In Subclause 8.3.2.1, Figure 8.12, and in Subclause 8.3.2.2.11, remove the (overriding) operation setFeatureValue
Actions taken:
August 21, 2012: received issue
January 7, 2013: closed issue

Issue 17560: Addition to the resolution to fUML Issue 17499 (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to Issue 17499 (Conditional node and loop node activations do not wait for contained accept event action activations) removes some lines from the specification for the operation ConditionalNodeActivation::doStructuredActivity. However, it neglects to state to remove the final line �this.activationGroup.terminateAll();�, which also needs to be removed.

Resolution: Agreed. In addition, the selectedClause attribute needs to be set to null before the if statement that tests if there are any clauses to select, since this is tested in the new completeBody operation. Otherwise, selectedClause could contain a spurious value from a previous activation of the conditional node, causing completeBody to try to copy outputs from that clause, rather than just doing the terminateAll call.
Revised Text: In Subclause 8.5.3.2.2 ConditionalNodeActivation, in operation doStructuredActivity (as modified by the resolution to Issue 17499): � Before the if statement with the condition �this.selectedClauses.size() > 0 & this.isRunning()�, add the statement �this.selectedClause = null;� � Remove the final line �this.activationGroup.terminateAll();�.
Actions taken:
August 21, 2012: received issue
January 7, 2013: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update ReclassifyObjectActionActivation Agreed. In addition, the semantics for a reclassify object action should ensure that private superclass attributes are removed or initialized as appropriate, consistent with the resolution to issue [1]FUML12-20. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML12-20
Revised Text: Note: This resolution presumes the resolution to issue [1]FUML12-20. In 8.6.4.2.5 ReclassifyObjectActionActivation, in operation doAction, replace the last line in the initial comments: // Add (empty) feature values to the referent object for the structural features of all added classifiers. with // Add feature values to the referent object for the structural // features of all added classifiers. // Any features that previously had values maintain those values, // while new features are initialized as being empty. In the first if statement, in the while statement, in the if statement that begins if (toBeRemoved), remove the statement object.removeFeatureValues(type); In the for statement, in the if statement that begins if (toBeAdded), remove the statements NamedElementList members = classifier.member; for (int k = 0; k < members.size(); k++) { NamedElement member = members.getValue(k); if (member instanceof StructuralFeature) { object.setFeatureValue((StructuralFeature) member, new ValueList(), 0); } } After the for statement, add the statements: FeatureValueList oldFeatureValues = object.getFeatureValues(); object.featureValues = new FeatureValueList(); object.addFeatureValues(oldFeatureValues); ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML12-20
Actions taken:
November 23, 2012: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update LoopNodeActivation Agreed.
Revised Text: In the normative XMI, in 8.5.3.1, Figure 8.28, and in 8.5.3.2.3 under Attributes (replacing "None"), add the following attribute to LoopNodeActivation: isTerminateAll : Boolean In 8.5.3.2.3 LoopNodeActivation, in operation doStructuredActivity, before the line this.doLoop(true); add the line this.isTerminateAll = false; In operation doLoop, in the if statement at the end of the while loop, change this.isRunning() && !this.isSuspended() to !this.isTerminateAll & this.isRunning() & !this.isSuspended() In the if statement at the end of the operation, change this.isRunning() && !this.isSuspended() to !this.isTerminateAll & this.isRunning() & !this.isSuspended() In operation runBody, in the if statement at the end of the operation, change !this.isSuspended() to !this.isTerminateAll & !this.isSuspended() In operation terminateAll, replace the body of the operation (after the comment) with this.isTerminateAll = true; LoopNode loopNode = (LoopNode) this.node; OutputPinList bodyOutputs = loopNode.bodyOutput; OutputPinList resultPins = loopNode.result; for (int i = 0; i < bodyOutputs.size(); i++) { OutputPin bodyOutput = bodyOutputs.getValue(i); OutputPin resultPin = resultPins.getValue(i); this.putTokens(resultPin, this.getPinValues(bodyOutput)); } super.terminateAll(); In operation resume, place the first if statement if (loopNode.mustIsolate) { _beginIsolation(); this.continueLoop(); _endIsolation(); } else { this.continueLoop(); } inside a surrounding if statement if (!this.isTerminateAll) { if (loopNode.mustIsolate) { _beginIsolation(); this.continueLoop(); _endIsolation(); } else { this.continueLoop(); } }
Actions taken:
November 23, 2012: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update LoopNodeActivation::doStructuredActivity Agreed.
Revised Text: In 8.5.3.2.3 LoopNodeActivation, in operation doStructuredActivity, replace the lines OutputPinList loopVariables = loopNode.loopVariable; OutputPinList resultPins = loopNode.result; ValuesList bodyOutputLists = this.bodyOutputLists; with this.bodyOutputLists.clear();
Actions taken:
November 26, 2012: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Add attribute initializations Agreed. The first two points in the issue can be handled by small updates to ActionActivation and ExpansionRegionActivation. The remaining points, however, require more extensive updates, to ensure that all activations are properly initialized when they are added to an activity node activation group, even before they are run.
Revised Text: In 8.5.2.1, Figure 8.25, and in the normative XMI, remove the operations addNodeActivation and addEdgeInstance from class ActivityNodeActivationGroup. In Figure 8.26, add the following operation to class ActivityNodeActivation: initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) In 8.5.2.2.4 ActivityNodeActivation, add the following operation after operation getTokens and renumber subsequent operations appropriately: [14] initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) // Initialize this action activation to be not firing. super.initialize(node, group); this.firing = false; [Editor's Note: The code listed above for the ActivityNodeActivation::initialize operation (added to 8.5.2.2.4) is an accidental duplicate of the code listed for ActionActivation::initialize (added to 8.6.2.2.1 below). The correct code (as tested in the prototype implementation) is: // Initialize this node activation. this.node = node; this.group = group; this.running = false; ] In 8.5.2.2.5 ActivityNodeActivationGroup, remove operations [2] addEdgeInstance and [3] addNodeActivation and renumber subsequent operations as appropriate. In the createNodeActivation operation, replace the statements activation.node = node; activation.running = false; this.addNodeActivation(activation); with activation.initialize(node, this); this.nodeActivations.addValue(activation); In the createEdgeInstances operation, in the first for statement, replace the statement this.addEdgeInstance(edgeInstance); with edgeInstance.group = this; this.edgeInstances.addValue(edgeInstance); In 8.5.4.2.3 ExpansionRegionActivation, in operation doStructuredActivity, in the third nested while loop, change the statement activationGroup.groupOutputs.addValue(new OutputPinActivation()); to activationGroup.groupOutputs.addValue(groupOutput); In 8.6.2.1, Figure 8.31, and in the normative XMI, add the following operation to class ActionActivation: initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) In 8.6.2.2.1 ActionActivation, add the following operation after the operation getTokens and renumber subsequent operations appropriately: [9] initialize ( in node : ActivityNode, in group : ActivityNodeActivationGroup ) // Initialize this action activation to be not firing. super.initialize(node, group); this.firing = false; In the addOutgoingEdge operation, after the statement forkNodeActivation = new ForkNodeActivation(); add the statement forkNodeActivation.running = false; In 8.6.4.1, Figure 8.36, and in the normative XMI, add the following operation to class AcceptEventActionActivation: initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) In 8.6.4.2.1 AcceptEventActionActivation, after the operation fire, add the following operation and renumber subsequent operations appropriately: [4] initialize ( in node : ActivityNode, in group : ActivityNodeActivationGroup ) // Initialize this accept event action activation to be not waiting for an event. super.initialize(node, group); this.waiting = false;
Actions taken:
December 17, 2012: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update ActivityExecution::terminate Agreed.
Revised Text: In 8.5.2.2.2 ActivityExecution, in the terminate operation, replace the line this.activationGroup.terminateAll(); with if (this.activationGroup != null) { this.activationGroup.terminateAll(); }
Actions taken:
December 30, 2012: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update RealValue::toString Agreed.
Revised Text: In 8.3.2.2.21 RealValue, in the toString operation, change the comment // This gives 10 significant digits in the mantissa. to // This gives 9 significant digits in the mantissa. and, on the following line, in the header of the for statement, change 10 to 9.
Actions taken:
January 5, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update CompoundValue::toString Agreed. If the feature value is a reference, then it is sufficient to show the object ID and list the names of the types of the object.
Revised Text: In 8.3.2.2.2 CompoundValue, in the toString operation, in the nested while statement while (j <= featureValue.values.size()) { buffer = buffer + " " + featureValue.values.getValue(j - 1).toString(); j = j + 1; } replace the first statement in the loop with Value value = featureValue.values.getValue(j - 1); if (value instanceof Reference) { Object_ object = ((Reference)value).referent; buffer = buffer + " Reference to (" + object.objectId() + ":"; types = object.getTypes(); int n = 1; while (n <= types.size()) { buffer = buffer + " " + types.getValue(n - 1).name; n = n + 1; } buffer = buffer + ")"; } else { buffer = buffer + " " + value.toString(); }
Actions taken:
January 5, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Fix discrepencies The issue description is correct.
Revised Text: In the normative fUML_Library.xmi, in the FunctionBehavior FoundationalModelLibrary::PrimitiveBehaviors::UnlimitedNaturalFunctions::ToInteger, change the href of the type of the return parameter from https://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi#UnlimitedNatural to https://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi#Integer In the specification document, 9.3.5 UnlimitedNatural Functions, Table 9.6, change the return type of ToUnlimitedNatural from Integer to UnlimitedNatural. In the description, change "Converts x to an Integer value." to "Converts x to an UnlimitedNatural value."
Actions taken:
February 27, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Add ListFunctions::ListConcat It actually is possible to implement a ListConcat activity, using two "pass-through" structured activity nodes connected by a control flow, which sequentially feed the two lists to be concatenated to a merge node. However, this is certainly not a particularly natural construction. ListSize and ListGet could also actually be implemented using expansion regions/loop nodes (as currently noted in the spec), but it is still more useful to have them as primitive functions. The same is true of ListConcat.
Revised Text: In 9.3.6 ListFunctions, replace the last sentence of the first paragraph with: Note that the list arguments for all the list functions are untyped and that the results of ListGet and ListConcat are also untyped. In the first sentence of the second paragraph, remove the phrase "using expansion regions". In Table 9.7, add a new row: ListConcat(list1[*]{ordered,nonunique}, list2[*]{ordered,nonunique}) [*]{ordered,nonunique} Returns the list with all the values of list1 followed by all the values of list2. In the normative fUML_Library.xmi, within the representation for the package FoundationalModelLibrary::PrimitiveBehaviors::ListFunctions, add the following: <packagedElement xmi:type="uml:FunctionBehavior" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat" name="ListConcat" isAbstract="true" isReentrant="false"> <ownedParameter xmi:type="uml:Parameter" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-list1" name="list1" isOrdered = "true" isUnique = "false"> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-list1-_lowerValue"/> <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-list1-_upperValue" value="*"/> </ownedParameter> <ownedParameter xmi:type="uml:Parameter" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-list2" name="list2" isOrdered = "true" isUnique = "false"> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-list2-_lowerValue"/> <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-list2-_upperValue" value="*"/> </ownedParameter> <ownedParameter xmi:type="uml:Parameter" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-result" name="result" direction="return" isOrdered = "true" isUnique = "false"> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-result-_lowerValue"/> <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="PrimitiveBehaviors-ListFunctions-ListConcat-result-_upperValue" value="*"/> </ownedParameter> </packagedElement>
Actions taken:
February 27, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Change the result parameter direction to return Agreed that the ReadLine::result parameter should have direction "return".
Revised Text: In the normative fUML_Library.xmi, in the Activity FoundationalModelLibrary::BasicInputOutput::ReadLine, change the direction of the parameter named result from out to return.
Actions taken:
February 27, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Make Notification public Agreed that Notification should be public.
Revised Text: In the normative fUML_Library.xmi, in the representation of the Signal FoundationalModelLibrary::Common::Notification, remove visibility = "private" (which makes Notification public, since this is the default).
Actions taken:
February 27, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Give the reception a name Agreed that it would be better if the reception had a name. For example, this is required in order to send a signal via the reception in Alf.
Revised Text: In the normative XMI, in the Class FoundationalModelLibrary::Common:Listener, in the representation of the ownedReception, set the XML attribute name = "Notification" and change the xmi::id to Common-Listener-Notification.
Actions taken:
February 27, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Give the parameters type Status Agreed that the parameters should have type Status.
Revised Text: In the normative fUML_Library.xmi, in the representation for the errorStatus parameters of both FoundationalModelLibrary::BasicInputOutput::ReadLine and FoundationalModelLibrary::BasicInputOutput::WriteLine, set the XML attribute type = "Common-Status".
Actions taken:
February 27, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.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: Update StructuredValue Agreed. However, in an AcceptEventAction, if isUnmarshall = true, then there are output pins only for the visible members (owned and inherited) of the accepted Signal. Currently, AcceptEventActionActivation places values from all the featureValues of a signal onto the output pins. This needs to be changed to only place the values of visible features onto the output pins.
Revised Text: Note: The changes proposed here also support the resolution of Issue [1]FUML12-7. In 8.3.2.1, Figure 8.11, and the normative XMI, add the following operations to the class StructuredValue: getMemberValues ( ) : FeatureValue [*] addFeatureValues ( type : Classifier ) addFeatureValuesForType ( type : Classifier ) getValues ( feature : NamedElement, featureValues : FeatureValue [*] ) : Value [*] [Editor's Note: To be consistent with the text added in 8.3.2.2.25 below, the signatures for addFeatureValues and addFeatureValuesForType in Figure 8.11 should actually be addFeatureValues(oldFeatureValues : FeatureValue [*]) and addFeatureValuesForType(type : Classifier, oldFeatureValues : FeatureValue [*]).] In 8.3.2.2.25 StructuredValue, replace the body of the operation createFeatureValues with // Create empty feature values for all structural features of the types // of this structured value and all its supertypes (including private // features that are not inherited). this.addFeatureValues(new FeatureValueList()); And add the following operations (renumbering other operations appropriately): [1] addFeatureValues ( in oldFeatureValues : FeatureValue [0..*] ) // Add feature values for all structural features of the types // of this structured value and all its supertypes (including private // features that are not inherited). If a feature has an old feature // value in the given list, then use that to initialize the values of // the corresponding new feature value. Otherwise leave the values of // the new feature value empty. ClassifierList types = this.getTypes(); for (int i = 0; i < types.size(); i++) { Classifier type = types.getValue(i); this.addFeatureValuesForType(type, oldFeatureValues); } [2] addFeatureValuesForType ( in type : Classifier, in oldFeatureValues : FeatureValue [0..*]) /// Add feature values for all structural features of the given type and // all of its supertypes (including private features that are not // inherited). If a feature has an old feature value in the given list, // then use that to initialize the values of the corresponding new // feature value. Otherwise leave the values of the new feature value // empty. // Set feature values for the owned structural features of the given // type. (Any common structural values that have already been added // previously will simply have their values set again.) NamedElementList ownedMembers = type.ownedMember; for (int j = 0; j < ownedMembers.size(); j++) { NamedElement ownedMember = ownedMembers.getValue(j); if (ownedMember instanceof StructuralFeature) { this.setFeatureValue((StructuralFeature) ownedMember, this.getValues(ownedMember, oldFeatureValues), 0); } } // Add feature values for the structural features of the supertypes // of the given type. (Note that the feature values for supertype // features always come after the feature values for owned features.) ClassifierList supertypes = type.general; for (int i = 0; i < supertypes.size(); i++) { Classifier supertype = supertypes.getValue(i); this.addFeatureValuesForType(supertype, oldFeatureValues); } [6] getMemberValues ( ) : Value [0..*] // Return the feature values for this structured value that are for structural // features that are members of one of the types of the structured value. // (That is, they are owned are inherited, excluding private features of // supertypes that are not inherited.) FeatureValueList featureValues = this.getFeatureValues(); FeatureValueList memberValues = new FeatureValueList(); ClassifierList types = this.getTypes(); for (int i = 0; i < featureValues.size(); i++) { FeatureValue featureValue = featureValues.getValue(i); Boolean isMember = false; int j = 1; while (j <= types.size() & !isMember) { Classifier type = types.getValue(j-1); NamedElementList members = type.member; int k = 1; while (k <= members.size() & !isMember) { NamedElement member = members.getValue(k-1); isMember = featureValue.feature == member; k = k + 1; } j = j + 1; } if (isMember) { memberValues.addValue(featureValue); } } return memberValues; [7] getValues( in feature : NamedElement, featureValues : FeatureValue [0..*] ) : Value [0..*] // Return the values from the feature value in the given list for the // given feature. If there is no such feature value, return an empty // list. FeatureValue foundFeatureValue = null; int i = 1; while (foundFeatureValue == null & i <= featureValues.size()) { FeatureValue featureValue = featureValues.getValue(i-1); if (featureValue.feature == feature) { foundFeatureValue = featureValue; } i = i + 1; } ValueList values; if (foundFeatureValue == null) { values = new ValueList(); } else { values = foundFeatureValue.values; } return values; In 8.6.4.2.1 AcceptEventActionActivation, in operation accept, in the first statement of the else clause of the nested if statement, change signalInstance.getFeatureValues() to signalInstance.getMemberValues(). ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML12-7
Actions taken:
March 5, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Remove CompoundValue::removeFeatureValue Agreed. However, with the resolution to issue [1]FUML12-7, ReclassifyObjectActionActivation no longer uses removeFeatureValue, and the new specification of the action functionality correctly handles the removal of attributes from the old classifiers. Since CompoundValue::removeFeatureValue is not used by anything else, it can be removed. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML12-7
Revised Text: Note: This resolution presumes the resolution to issue [1]FUML12-7. In 8.3.2.1, Figure 8.12, and in the normative XMI, remove the operation removeFeatureValues from the class CompoundValue. In 8.3.2.2.2 CompoundValue, remove the operation removeFeatureValues and renumber subsequent operations appropriately. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML12-7
Actions taken:
May 2, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Update RemoveStructuralFeatureValueActionActivation In the case of action.isRemoveDuplicates = false and action.removeAt = null, the issue is correct that the current specification will result in an infinite loop if the given structural feature holds any instances of the given value. However, the issue is not correct for the case action.isRemoveDuplicates = true. In that case, instance of the given value found at position j is removed before the search for the position of the next instance, so beginning the search at position j is correct. Indeed, starting the next search at position j+1 could cause an instance of the value to be skipped, if it happened to come right after the instance that had just been removed.
Revised Text: In 8.6.3.2.12 RemoveStructuralFeatureValueActionActivation, in operation doAction, in the third if statement, in the else clause beginning if (value instanceof StructuredValue), in the else clause of the second nested if statement beginning if (action.removeAt == null), within the while statement, replace the statement j = this.position(inputValue, featureValue.values, j); with j = this.position(inputValue, featureValue.values, j + 1);
Actions taken:
May 14, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Update RemoveStructuralFeatureValueActionActivation The issue is correct about the problem. However, the suggested solution would not work properly. As suggested, in the case that inputValue != null, the set of matching links previously found is replaced by a list of links that have the correct value for the action's structural feature. But these links will no longer necessarily have the action's object value as their opposite end value. What is needed is for matching links to have both the current opposite end value and, if inputValue != null, the correct near end value.
Revised Text: In 8.6.3.1, Figure 8.33, and the normative XMI, add the following operation to class StructuralFeatureActionActivation: getMatchingLinksForEndValue( association : Association, end : StructuralFeature, oppositeValue : Value, endValue : Value [0..1] ) : Link [*] In 8.6.3.2.12 RemoveStructuralFeatureValueActionActivation, in the if clause of the third if statement (beginning if (association != null)), in the first statement, replace the call this.getMatchingLinks(association, feature, value) with this.getMatchingLinksForEndValue(association, feature, value, inputValue) In 8.6.3.2.13 StructuralFeatureActionActivation, replace the body of the operation getMatchingLinks (after the comment) with return this.getMatchingLinksForEndValue(association, end, oppositeValue, null); Add the following operation after getMatchingLinks, and renumber subsequent operations accordingly, [3] getMatchingLinksForEndValue ( in association : Association, in end : StructuralFeature, in oppositeValue : Value, in endValue : Value [0..1] ) : Link [0..*] // Get the links of the given binary association whose end opposite // to the given end has the given opposite value and, optionally, that // has a given end value for the given end. Property oppositeEnd = this.getOppositeEnd(association, end); ExtensionalValueList extent = this.getExecutionLocus().getExtent( association); LinkList links = new LinkList(); for (int i = 0; i < extent.size(); i++) { ExtensionalValue link = extent.getValue(i); if (link.getFeatureValue(oppositeEnd).values.getValue(0).equals(oppositeValue)) { boolean matches = true; if (endValue != null) { matches = link.getFeatureValue(end).values.getValue(0).equals(endValue); } if (matches) { if (!end.multiplicityElement.isOrdered | links.size() == 0) { links.addValue((Link) link); } else { int n = link.getFeatureValue(end).position; boolean continueSearching = true; int j = 0; while (continueSearching & j < links.size()) { j = j + 1; continueSearching = links.getValue(j - 1).getFeatureValue(end).position < n; } if (continueSearching) { links.addValue((Link) link); } else { links.addValue(j - 1, (Link) link); } } } } } return links;
Actions taken:
May 16, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Update RemoveStructuralFeatureValueActionActivation Agreed.
Revised Text: In 8.6.3.2.12 RemoveStructuralFeatureValueActionActivation, in operation doAction, in the first clause of the third if statement (beginning if (association != null)), in the second else clause of the nested if statement, in the condition for the while statement change i < links.size() to i <= links.size() and, at the end of the body of the while statement, add the statement i = i + 1;
Actions taken:
May 16, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed 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: Defer The RTF agrees this issue needs resolution but, due to lack of time, is deferring its resolution to the next RTF.
Revised Text:
Actions taken:
June 30, 2013: received issue
October 8, 2015: Deferred
December 22, 2015: closed 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).

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.

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.

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

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

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: Update UnlimitedNaturalValue::equals The two code snippets given in the issue description are identical. However, the actual statement in the current specification is isEqual = ((UnlimitedNaturalValue) otherValue).value == this.value; which, as stated in the issue, incorrectly compares the UnlimitedNatural objects, not their natural values. The correction is as given in the issue.
Revised Text: In 8.3.2.2.26 UnlimitedNaturalValue, in operation equals, change the statement isEqual = ((UnlimitedNaturalValue)otherValue).value == this.value; to isEqual = ((UnlimitedNaturalValue) otherValue).value.naturalValue == this.value.naturalValue;
Actions taken:
July 3, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

Issue 19007: ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06) (fuml-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

ReadSelfAction issue - in a scenario where an activity with a context (classifier) calls (CallBehaviorAction) an activity owned by other classifier, the ReadSelfAction (from fUML execution model) violates the constraint defined in UML superstructure 2.4.1 because it returns the context from the caller activity (not necessary the same classifier).      8.6.3.2.10 ReadSelfActionActivation   Reference context = new Reference();  context.referent = his.getExecutionContext();      11.3.36 ReadSelfAction (from IntermediateActions), pg. 280 - UML 2.4.1  [3] The type of the result output pin is the host classifier.  self.result.type = self.context

Resolution: fUML constrains calls to behaviors with contexts The semantics of ReadSelfAction is exactly as called for by the UML standard: it retrieves the context object for an execution. The issue raised is really a question about the propagation of the dynamic context object specified as part of the semantics of CallBehaviorAction. But note that, in 7.5.2.2.3 CallBehaviorAction, the following constraint is included on the fUML subset of the UML abstract syntax: [3] proper_context If the behavior has a context, it must be the same as the context of the enclosing activity or a (direct or indirect) superclass of it. self.behavior.context->notEmpty() implies union(self.context.allParents())->includes(self.behavior.context) [Actually, the OCL here has an error. The call to {{union}} should be {{self.context->union}}. This will be submitted as a separate issue.] If this constraint is satisfied, then the propagation of the context object in 8.6.2.2.3 CallBehaviorActionActivation is consistent, as noted in the following comment on the doAction operation: [Note that this requires the behavior context to be compatible with the type of the current contect object.]. If the above constraint is violated, then the model is outside the fUML subset, and fUML does not provide semantics for it. This constraint was added to the abstract syntax in order to be able to provide reasonable semantics at all for making a call to a behavior with a context. Unless one can propagate the caller's context, it is not clear what context object one would give to the new execution of the called behavior. Unlike the case of an operation call, in which the target object of the call becomes the context for the execution of the operation method, no target object is specified for a behavior call. However, if the above constraint holds, then the called behavior's context is guaranteed to be consistent with the caller's context, and it is then valid to propagate the dynamic context object at runtime. (This might be useful, e.g., for doing a functional decomposition of a behavior that is the method of an operation.) And, in this case, the current semantics for ReadSelfAction is then completely consistent. While a called behavior may have a different context classifier than the calling behavior, the constraint ensures that it will at least be a generalization of the context classifier of the calling behavior, so the runtime context object from the calling execution will conform to the caller's context classifier. On the other hand, if the called behavior does not have a context classifier, then an execution of the called behavior will have itself as its context object, which will then be (correctly) what is returned by a ReadSelfAction.
Revised Text:
Actions taken:
October 11, 2013: received issue
October 8, 2015: Closed; No Change
December 22, 2015: closed issue

Issue 19008: Extensional values should have an unique identifier (fuml-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Locus has a "set" for all extensional values, however, there is no unique identifier in the ExtensionalValue to support the uniqueness.       It should be defined an attribute objectId as "isID" (from UML 2.4.1, isID, indicates this property can be used to uniquely identify an instance of the containing class.) in the class ExtensionalValue.       The only mention to an object identifier is a reference marked as non-normative, which uses Java to define an object identifier.      8.2.2.2.6 Locus pg. 103  extensionalValues : ExtensionalValue [0..*]  The set of values that are members of classifier extents at this locus.       8.3.2.2.27 Value pg. 159  [6] objectId ( ) : String // Return an identifier for this object. // [Non-normative.] return super.toString();

Resolution: Normatively define IDs for extensional values In general, it is not necessary in UML to model an explicit ID attribute in order to enforce uniqueness of a property with multiple values. Objects (instances of classes) are automatically distinguishable and unique under UML semantics. Identifying a property typed by a class as isUnique (the default) then means directly that no instance of that class (note that ExtensionalValue is a class in the Execution Model) can appear more than once in the set of values for the property. Nevertheless, the issue does make a reasonable point that a Value::objectId operation is provided, but that its specification is non-normative. However, this operation is, in fact, used normatively in CompoundValue::toString. Indeed, while it is unclear how to assign unique IDs to all values within the context of the Execution Model, it is certainly reasonable to assign IDs to the extensional values at a locus, as the issue requests. This ID could be assigned when the extensional value is added to the extent at a certain locus. To make the ID unique across multiple loci then requires that each locus also have an ID that can be used to further qualify the IDs of extensional values at that locus. Such an ID could be assigned when the locus is created, as part of the initialization of the execution environment. Finally, note that the isID meta-attribute is not given any semantics in bUML, so it is not used in the Execution Model.
Revised Text: (Note: This proposal presumes the resolution to issue [1]FUML12-13.) In 8.2.2.1 Overview, under the heading "Configuring the Execution Environment at a Locus", add the following to the first bullet in the second paragraph: The identifier for this instance must be initialized to a non-empty string, which should be distinct from the identifiers for any remote loci that may be available from this locus. In Figure 8.4, and in the normative XMI, add the following attribute to the class Locus: identifier : String [Editor's Note: The operation makeIdentifier, added below, also needs to be added to Figure 8.4.] In 8.2.2.2.6 Locus, under "Attributes", replace "None" with *identifier : String The identifier of this locus, which should be unique at least within the current execution environment. In operation add, after the statement value.locus = this; add the statement value.identifier = this.identifier + "#" + this.makeIdentifier(value); After the operation instantiate, add the following operation, and renumber subsequent operations appropriately: makeIdentifier ( in value : ExtensionalValue ) : String // Return an identifier for the given (newly created) extensional value. // [No normative specification. A conforming implementation may create an identifier // an identifier in any way such that all identifiers for extensional values created // at any one locus are unique.] In 8.3.2.1, Figure 8.11, and in the normative XMI, remove operation objectId from class Value. In Figure 8.12, and in the normative XMI, add the following attribute to class ExtensionalValue: identifier : String and add the following operation to class ExtensionalValue: toString ( ) : String In 8.3.2.2.2 CompoundValue, in operation toString, replace the first statement String buffer = "(" + this.objectId() + ":"; with String buffer = "("; In the body of the first while loop, replace the statement buffer = buffer + " " + types.getValue(i - 1).name; with if (i != 1) { buffer = buffer + " "; } buffer = buffer + types.getValue(i - 1).name; Within the body of the second while loop, in the nested while loop with index j (as already modified by the resolution to issue [2]FUML12-13), replace the statement buffer = buffer + " Reference to (" + object.objectId() + ":"; with buffer = buffer + " Reference to " + object.identifier + "("; In the following while loop, with index n, replace the statement buffer = buffer + " " + types.getValue(n - 1).name; with if (n != 1) { buffer = buffer + " "; } buffer = buffer + types.getValue(n - 1).name; In 8.3.2.2.7 ExtensionalValue, under Attributes, replace "None" with *identifier : String The identifier for this extensional value, unique among the extensional values created at the same locus as this value. Add the operation [3] toString ( ) : String return this.identifier + super.toString(); In 8.3.2.2.11 Link, in operation addTo, remove the statement Debug.println(?[addTo] link = ? + this.objectId()); In operation destroy, remove the statement Debug.println("[destroy] link = " + this.objectId()); In 8.3.2.2.19 Object, in operation destroy, remove the statement Debug.println("[destroy] object = " + this.objectId()); In 8.3.2.2.27 Value, remove operation [7] objectId and renumber subsequent operations appropriately. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML12-13 [2] http://issues.omg.org/browse/FUML12-13
Actions taken:
October 11, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

Issue 19130: Problem with CallActionActivation: possible infinite loop in removeCallExecution() (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:

The loop variable 'i' is never incremented, which might lead to an infinite loop.

Resolution: Update CallActionActivation::removeCallExecution Agreed.
Revised Text: In 8.6.2.2.2 Call Action Activation, in operation removeCallExecution, in the while loop, after the if statement, add the statement: i = i + 1;
Actions taken:
December 1, 2013: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

Issue 19528: AcceptEventActionActivation::match should match instances of descendants of a trigger's signal (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Semantics of a Foundational Subset for Executable UML Models (FUML), v1.1 (formal-13-08-06)  Subclause: 8.6.4.2.1 AcceptEventActionActivation      The AcceptEventActionActivation::match operation should not require equality of Signals to match a signal instance to the Signal of a trigger of the AcceptEventAction. Rather, it should allow the Signal of the signal instance to be a descendant of the Signal of a trigger SignalEvent.

Resolution: Change AcceptEventActionActivation::match The UML 2.4.1 specification is not explicit on how the receipt of a signal is matched to a signal event. The UML 2.5 specification, however, in 13.3.3, states that "A SignalEvent is a MessageEvent for messages requesting the reception of an instance of a specific Signal." Since an instance of a specialization of a signal is also an instance of the general signal, the statement in the UML 2.5 specification supports the view that the intent is that instances of specialized signals also match a signal event for the general signal.
Revised Text: In 8.6.2.1, Figure 8.31, and in the normative XMI, add the following operation to class ActionActivation: checkAllParents( type : Classifier, classifier : Classifier) : Boolean In 8.6.2.2.1 ActionActivation, after operation addPinActivation, add the following operation and renumber subsequent operations appropriately: [3] checkAllParents ( in type : Classifier, in classifier : Classifier ) : Boolean // Check if the given classifier matches any of the direct or indirect // ancestors of a given type. ClassifierList directParents = type.general; boolean matched = false; int i = 1; while (!matched & i <= directParents.size()) { Classifier directParent = directParents.getValue(i - 1); if (directParent == classifier) { matched = true; } else { matched = this.checkAllParents(directParent, classifier); } i = i + 1; } return matched; In 8.6.4.1, Figure 8.35, and in the normative XMI, remove operation checkAllParents from class ReadIsClassifiedObjectActionActivation. In 8.6.4.2.4 ReadIsClassifiedObjectActionActivation, remove operation [1] checkAllParents and renumber subsequent operations appropriately. In 8.6.4.2.1 AcceptEventActionActivation, in operation match, replace the statement matches = ((SignalEvent)(triggers.getValue(i-1).event)).signal == signal; with Signal triggerSignal = ((SignalEvent) (triggers.getValue(i - 1).event)).signal; if (triggerSignal == signal) { matches = true; } else { matches = this.checkAllParents(signal, triggerSignal); }
Actions taken:
July 18, 2014: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

Issue 19679: Initial execution of an activity is not run-to-completion (fuml-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

When an activity accepts an event, its execution proceeds as a �run-to-completion step�, and any new event occurrences (signal instances) are saved in the event pool and not dispatched until after the completion of the step. However, when an activity first starts executing (asynchronously), it is NOT in a run-to-completion step before it waits for the first time at an accept event action. This means that, during this time, any event occurrences that arrive could potentially be dispatched immediately and lost. Further, even if the first action to be executed in an activity is an accept event action, the specification would allow an execution trace in which all event occurrences happened before the action fired for the first time, meaning that, currently, it can never be ensured that an activity will be able to accept any event occurrences at all.      Recommended solution:      Rather than having the ClassifierBehaviorExecutionActivity start asynchronously from the EventDispatchLoop of the object activation for the context object, the EventDispatchLoop should make a synchronous call to execute the initial classifier behavior execution, and then only start looping once the initial execution completes. Note that the equivalent behavior should also be specified for bUML, so that the ArrivalSignal instances sent to an object activation are properly queued while the EventDispatchLoop is waiting for the initial classifier behavior execution to complete.

Resolution: Invoke classifier behaviors from the event dispatch loop The UML 2.5 specification calls the initial event that starts the execution of a behavior the "event of its invocation". Essentially, what is required to resolve this issue is for such an invocation event occurrence to be handled as a run-to-completion step in the behavior execution, just as signal event occurrences are currently handled. A particularly direct way to do this would be to explicitly model invocation event occurrences, place them in the event pool for the context object of the behavior being (asynchronously) invoked and then having them dispatched and accepted using the current event loop and run-to-completion mechanisms. Doing this would also manage the case of a context object with multiple classifier behavior executions that don't all start at the same time. This can happen if the object has multiple types with classifier behaviors. If the object is the target value for a start object behavior action whose object input pin is explicitly typed by one of the relevant classes, than only the classifier behavior associated with that class is started, even if the object has other types with classifier behaviors (in contrast, if the object pin is untyped, then classifier behaviors are started for all the object's types that have them; see the definition of the ObjectActivation::startBehavior operation in 8.4.3.2.5 of the fUML 1.1 specification). This means that, when a classifier behavior execution is started, this may happen after other classifier behavior executions have already started and are already handling incoming (signal) event occurrences. Thus, the new invocation could happen when there are already event occurrences in the event pool waiting to happen and even possibly when there is already an ongoing run-to-completion step happening for a previously dispatched event occurrence. By explicitly modeling the invocation event occurrence for the new classifier behavior, the invocation can be managed in the same way as other event occurrences, by being placed in the event pool and eventually dispatched and handled in a run-to-completion step for the initial execution of the classifier behavior. Finally, this approach provides an opportunity to generalize the model of the event pool to contain event occurrences other than signal instances. This will likely be eventually necessary anyway, in order to allow future specifications to incorporate the handling of other kinds of events into the fUML Common Behaviors framework (such as call events for state machines). So, the proposal to resolve this issue is as follows: 1. Create a new abstract EventOccurrence class, with a concrete SignalEventOccurrence subclass that has a reference to a SignalInstance. 2. Generalize the eventPool to contain EventOccurrences instead of just SignalInstances. 3. Create a new InvocationEventOccurrence subclass of EventOccurrence with a reference to an Execution being invoked. 4. Change the ObjectActivation::startObjectBehavior operation to create an InvocationEventOccurrence and place it into the eventPool, rather than directly initiating the asynchronous execution of a behavior. 5. Change the ClassifierBehaviorExecution class to ClassifierBehaviorInvocationEventAccepter, an EventAccepter that registers itself to match the InvocationEventOccurrence for a specific behavior Execution and, when it accepts a matching InvocationEventOccurrence, runs that Execution as a run-to-completion step.
Revised Text: In 8.4.3.1 Overview, in the third to the last paragraph of the section title "Active Objects", add the following sentence at the end: These semantics are captured in the object activation for an active object, which is created when the active behavior of the object is started. Replace the last two paragraphs under "Active Objects" with the following paragraph: Note that a behavior may itself be instantiated as an active object and the active behavior of a behavior instance is just the behavior itself, acting as its own context object. For simplicity, in the description of the semantics of active objects and event handling below, the running behavior of an active object is always referred to as its "classifier behavior execution". However, in the case of an active object that is a behavior instance (which is already an execution), the "classifier behavior execution" will actually be the active object itself, not an instance of some other "classifier behavior". Replace the "Event Dispatching" section with Event Dispatching An active object may asynchronously react to the occurrence of various events. When an object is notified of the occurrence of an event, it is said to have received the event occurrence. Asynchronicity means that the receipt of the event occurrence is decoupled from the dispatching of that occurrence, which is when a determination is made as to how the object will react to the event occurrence (if at all). In order to achieve this decoupling, ObjectActivation is itself an active class (in the execution model). The classifier behavior for ObjectActivation (see Figure 8.17) is a simple dispatch loop. When an event occurrence is received by an active object, its is placed into the event pool of the object activation for that object, after which the object activation sends an ArrivalSignal to itself. The dispatch loop waits for an ArrivalSignal and, when this happens, calls the dispatchNextEvent operation. This operation dispatches a single event occurrence from the event pool. Once this is complete ("run to completion semantics" for dispatched event occurrences), the dispatch loop returns to waiting for another event occurrence to arrive. It is important to carefully note the two semantics levels in the above description. At the level of a user model, the execution model is modeling the receipt of an event occurrence and the dispatching of that event occurrence, to be handled as defined in the user model. However, the semantic model itself also uses the active class ObjectActivation and the signal ArrivalSignal, whose receipt by an object activation is an event occurrence handled by the classifier behavior of the object activation (i.e., the event dispatch loop). The semantics for active class and signals, as used in the execution model, are given by the base semantics for those model constructs (see Clause 10; also see Clause 6 for a general discussion of fUML execution semantics versus base semantics). Note, while an event occurrence is being dispatched, it is possible that the active object will receive additional event occurrences. In this case, these event occurrences will be concurrently placed into the event pool for the active object and an ArrivalSignal will be generated for each arriving event occurrence. When the dispatch loop is ready to accept another event occurrence, it will accept exactly one pending ArrivalSignal, causing another event occurrence to be dispatched. The dispatch loop will continue to dispatch event occurrences, one at a time, until there are no more pending ArrivalSignals (or until the active object is destroyed). Which event occurrence is actually dispatched out of the event pool is not determined by the ArrivalSignal but, rather, by the dispatchNextEvent operation. However, the exact behavior to be specified for this operation is a semantic variation point in fUML. (See 2.4 for a full discussion of semantic variation within fUML.) Following the general approach of using the Strategy Pattern to model semantic variation points (see 8.2.1), the variability of event dispatching is captured by using strategy classes for the ObjectActivation::getNextEvent operation. GetNextEventStrategy provides the abstract base class for this type of strategy. The default dispatching behavior is given by the concrete FIFOGetNextEventStrategy, which dispatches event occurrences on a first-in first-out (FIFO queue) basis. Any variant behavior must be fully specified by overriding the behavioral specification of the dispatchNextEvent operation. A conforming execution tool may define an alternative rule for how this dispatching is to take place by defining a new GetNextEventStrategy subclass specifying whatever rule is desired. An instance of this alternate strategy must then be registered with the execution factory at a given locus, rather than the default strategy. Once an event occurrence is selected for dispatch, it is matched against the list of waiting event accepters for the active object. If a match is found, the event occurrence is passed to the event accepter using its accept operation. If no matching event acceptor is found, the event occurrence is not returned to the event pool and is lost. (Note that deferred events are not included in the fUML subset.) The event accepters for an active object are points within the executing classifier behaviors of the object that are waiting for certain events. An executing classifier behavior may register an event accepter for itself using the Object::registerForEvent operation. The event accepter is then added to the list of waiting event accepters for the object and any matching event occurence is passed back to the executing classifier behavior via the accept operation of the event accepter. Add the following new section: Event Occurrences The event-dispatching framework described above is intended to be general enough to handle the occurrence of various different kinds of events defined in UML. However, currently there are two kinds of events whose occurrences are handled in the fUML execution model: classifier behavior (asynchronous) invocation events and signal reception events. It is expected that other specifications building on fUML may specify the semantics of other kinds of events within the general fUML event-handling framework. A classifier behavior for an active object may be started using a start object behavior action (see 8.6.4.2.8). When a behavior of an active object is so started, if no object activation yet exists for the active object, one is created. An active object with multiple types may have multiple classifier behaviors, which may be started separately, so it is possible that an object activation may already exist when a classifier behavior is started, if it is not the first one. In either case, the actual starting of the behavior is then delegated to the object activation. To start a classifier behavior, an Execution instance is created for it (see 8.4.2.2.1), but this execution does not run immediately. Instead, an invocation event occurrence for the execution is added to the event pool and a classifier behavior invocation event accepter is registered to handle this event occurrence. As previously described in general for event occurrences, this decouples the receipt of the event occurrence requesting the start of a classifier behavior from the dispatching of the event occurrence, at which point the classifier behavior invocation event accepter actually starts the classifier behavior execution. In this way, the classifier behavior executes asynchronously from its invocation and within an initial run-to-completion step, so that any event occurrences received by the active object during this initial execution are saved until the object is ready to handle them. An object activation also keeps a list of the classifier behavior invocation event accepters created to start classifier behavior executions. This maintains a link between the object activation and any ongoing executions so that, if the associated active object is destroyed, any running classifier behavior executions may be terminated. Once a classifier behavior is running, it may register event accepters to handle the occurrences of other kinds of events received by its context object. In particular, the firing of an accept event action results in the registration of an event accepter for the events declared in the triggers of that action (see 8.6.4.2.1 and 8.6.4.2.2). Currently, an accept event action in fUML is limited to handling signal events. When a signal instance is received by an active object, a signal event occurrence for the signal instance is placed in the event pool. When this signal event occurrence is dispatched, if there is a matching accept event action event accepter for it, then the corresponding signal instance will be accepted by the accept event action, resulting in the resumption of execution of the activity containing the action. Replace Figures 8.16 and 8.17 with the diagrams in the attachments (to be provided). Change the title of 8.4.3.2.1 to ClassifierBehaviorInvocationEventAccepter. Replace the sentence A classifier behavior execution executes the classifier behavior from a specific active class. with A classifier behavior invocation event accepter accepts an invocation event occurrence for the invocation of the execution of a classifier behavior from a specific active class. [Editor's Note: Under "Generalizations", "None" also needs to be changed to "EventAccepter", per the generalization relationship from ClassifierBehaviorInvocationEventAccepter to EventAccepter on the new diagram for Figure 8.17. ] Remove Figure 8.18 (and remove ClassifierBehaviorExecutionActivity from the execution model). Change the name of the execute operation to invokeBehavior (with the same arguments). In the initial comments for that operation, change the final line // Then start the active behavior of this ClassifierBehaviorExecution object, which will execute the execution object on a separate thread of control. to // Then register this event accepter with the object activation. Add the following operations in alphabetical order with the other operations and renumber the operations appropriately. accept ( in eventOccurrence : EventOccurrence ) // Accept an invocation event occurrence. Execute the execution of this // classifier behavior invocation event accepter. if (eventOccurrence instanceof InvocationEventOccurrence) { this.execution.execute(); } match ( in eventOccurrence : EventOccurrence ) : Boolean // Return true if the given event occurrence is an invocation event // occurrence for the execution of this classifier behavior invocation // event accepter. boolean matches = false; if (eventOccurrence instanceof InvocationEventOccurrence) { matches = ((InvocationEventOccurrence)eventOccurrence).execution == this.execution; } return matches; In 8.4.3.2.2 EventAccepter, change the names of the arguments of both operations from signalInstance to eventOccurrence and change their types from SignalInstance to EventOccurrence. In 8.4.3.2.3 FIFOGetNextEventStrategy, in the getNextEvent operation, change the return type and the type of the signalInstance variable from SignalInstance to EventOccurrence. Change the name of the signalInstance variable to eventOccurrence. In 8.4.3.2.4 GetNextEventStrategy, in the getNextEvent operation, change the return type from SignalInstance to EventOccurrence. In 8.4.3.2.5 ObjectActivation, under Associations, replace *classifierBehaviorExecutions : ClassifierBehaviorExecution [0..*] The executing classifier behaviors for this object activation. *eventPool : SignalInstance [0..*] The pool of signals sent to the object of this object activation, pending dispatching as events. (All the data values in the pool must be signal instances ? that is, they must have a single type that is a signal.) with *classifierBehaviorInvocations : ClassifierBehaviorInvocationEventAccepter [0..*] The invocations of the executing classifier behaviors for this object activation. *eventPool : EventOccurrence [0..*] The pool of event occurrences received by the object of this object activation, pending dispatching. Change the description of waitingEventAccepters from The set of event accepters waiting for signals to be received by the object of this object activation. to The set of event accepters waiting for event occurrences to be dispatched from the event pool. In the dispatchNextEvent operation, change the initial comment to: // Get the next event occurrence out of the event pool. // If there are one or more waiting event accepters with triggers that // match the event occurrence, then dispatch it to exactly one of those // waiting accepters. In the body of the operation, change the name of the signalInstance variable to eventOccurrence and change its type from SignalInstance to EventOccurrence. Change the type of the getNextEvent operation from SignalInstance to EventOccurrence. Replace the body of the send operation with: // Add a signal event occurrence for the given signal instance to the event pool // and signal that a new event occurrence has arrived. SignalEventOccurrence eventOccurrence = new SignalEventOccurrence(); eventOccurrence.signalInstance = (SignalInstance) signalInstance.copy(); this.eventPool.addValue(eventOccurrence); _send(new ArrivalSignal()); In the startBehavior operation, in the initial comment, change "classifier behavior execution" to "classifier behavior invocation" (four times). At the end of the second sentence, after "for it", insert "and add an invocation event occurrence to the event pool." Before the statement boolean notYetStarted = true; add the statement _beginIsolation(); In the while loop, change this.classifierBehaviorExecutions to this.classifierBehaviorInvocations (twice). In the if statement beginning if (notYetStarted), replace all the statements within the if statement with ClassifierBehaviorInvocationEventAccepter newInvocation = new ClassifierBehaviorInvocationEventAccepter(); newInvocation.objectActivation = this; this.classifierBehaviorInvocations.addValue(newInvocation); newInvocation.invokeBehavior(classifier, inputs); InvocationEventOccurrence eventOccurrence = new InvocationEventOccurrence(); eventOccurrence.execution = newInvocation.execution; this.eventPool.addValue(eventOccurrence); _send(new ArrivalSignal()); After the if statement, add the statement _endIsolation(); In the operation stop, change the name of the variable classifierBehaviorExecutions to classifierBehaviorInvocations and change its type from ClassifierBehaviorExecutionList to ClassifierBehaviorInvocationEventAccepterList. Change the name of the variable classifierBehaviorExecution to classifierBehaviorInvocation and change its type from ClassifierBehaviorExecution to ClassifierBehaviorInvocationEventAccepter. Add the following subclause after 8.4.3.2.2 EventAccepter: 8.4.3.2.3 EventOccurrence An event occurrence represents a single occurrence of a specific kind of event. Generalizations None Attributes None Associations None Operations None Renumber 8.4.3.2.3 FIFOGetNextEventStrategy to 8.4.3.2.4, renumber 8.4.3.2.4 GetNextEventStrategy to 8.4.3.2.5 and add the following subclause: 8.4.3.2.6 InvocationEventOccurrence An invocation event occurrence represents a signal occurrence of the event of the asynchronous invocation of a specific behavior execution. Generalizations *"EventOccurrence" on page 173 Attributes None Associations *execution : Execution The execution being asynchronously invoked. Operations None Renumber 8.4.3.2.5 ObjectActivation to 8.4.3.2.7 and add the following subclause: 8.4.3.2.8 SignalEventOccurrence A signal event occurrence represents the occurrence of a signal event due to the receipt of a specific signal instance. Generalizations *"EventOccurrence" on page 173 Attributes None Associations *signalInstance : SignalInstance The signal instance whose receipt caused this signal event occurrence. Operations None Renumber 8.4.3.2.6 SignalInstance to 8.4.3.2.8. In 8.6.4.1 Overview, under the "Accept Event Action" section, in the third paragraph, in the first sentence, replace "singal instance" with "signal event occurrence" and, after "context object" insert "with a signal instance". In Figure 8.36 (as currently numbered), in class AcceptEventActionEventAccepter, change the arguments of each of the operations from signalInstance : SignalInstance to eventOccurrence : EventOccurrence. In 8.6.4.2.2 AcceptEventActionEventAccepter, replace the two operations with [1] accept ( in eventOccurrence : EventOccurrence ) // Accept a signal event occurrence. Forward the signal instance to the action activation. if (eventOccurrence instanceof SignalEventOccurrence) { this.actionActivation.accept(((SignalEventOccurrence)eventOccurrence).signalInstance); } [2] match ( in eventOccurrence : EventOccurrence ) : Boolean // Return true if the given event occurrence is a signal event occurrence and the // signal instance matches a trigger of the accept action of the action activation. boolean matches = false; if (eventOccurrence instanceof SignalEventOccurrence) { matches = this.actionActivation. match(((SignalEventOccurrence)eventOccurrence).signalInstance); } return matches;
Actions taken:
December 12, 2014: received issue
October 8, 2015: Resolved
December 22, 2015: closed issue

Issue 19842: Bad event accepter removed from the waitingEventAccepter list (fuml-rtf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA (Dr. Jeremie Tatibouet, jeremie.tatibouet(at)cea.fr)
Nature: Revision
Severity: Significant
Summary:

Consider the case where an active class that has two classifier behaviors is instantiated. Each classifier behavior start on a run-to-completion step to completion step. This step is triggered by the consumption of �InvocationEventOccurrence� that was previously registered into the event pool of the object activation of the instantiated active object. When the first classifier behavior executes it suspends on a accept event action �Wait(Start)�. This provokes the registration in the waiting event accepter list of an �accepter� for the signal �Start�. The run-to-completion steps completes. waitingEventAccepters [ AcceptEventActionEventAccepter ] To start the second classifier behavior in a RTC step an �ClassifierBehaviorInvocationEventAccepter� is placed in the list of the waiting event accepters. waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ] The RTC steps starts when the �InvocationEventOccurrence� placed in the event pool gets consumed. The match between the event and the accepter is determined as being at index 1 of the list of waitingEventAccepters. matchingEventAccepterIndexes [ 1 ] The choice strategy returns 1. Consequently the selected event accepter becomes the one which is at j � 1 position the �matchingEventAccepterIndexes� list; so 1. waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ] However the event accepter that is removed is the one at j-1. Therefore the ClassifierBehaviorInvocationEventAccepter remains in the waiting event accepter list while the AcceptEventActionAccepter is removed. The assumption is that this.waitingEventAccepters.remove(j - 1); should be replaced by this.waitingEventAccepters.remove(matchingEventAccepterIndexes.get(j - 1)); to ensure the deletion of the right event accepter.

Resolution: Correct dispatchNextEvent The issue is indeed a serious bug that has lurked in the specification since version 1.0.
Revised Text: In 8.4.3.2.7 ObjectActivation, in operation dispatchEvent, near the end, replace the statements EventAccepter selectedEventAccepter = this.waitingEventAccepters.getValue(matchingEventAccepterIndexes.getValue(j-1)); this.waitingEventAccepters.removeValue(j-1); with int k = matchingEventAccepterIndexes.getValue(j - 1); EventAccepter selectedEventAccepter = this.waitingEventAccepters.getValue(k); this.waitingEventAccepters.removeValue(k); Also update this in the normative XMI.]
Actions taken:
October 22, 2015: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19845: Introduce CallEvent, AcceptCallAction and ReplyAction to keep consistency with PSSM (fuml-rtf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Significant
Summary:

fUML shall introduce CallEvent, AcceptCallAction and ReplyAction into fUML and harmonize their semantics with the "fragmented method" paradigm of state machines (and PSSM). In fact, the handling of CallEvents should be the same as the handling of SignalEvents in fUML.      This would mean that CallOperationActions do not any longer result in the execution of the method Behavior of an Operation, but in the generation of a CallEvent that is put into the event pool of the target object of the CallOperationAction. This would also require to not permit Operations to contain method - this would be then in synch with Reception.      AcceptCallAction should be introduced, or AcceptEventAction should be relaxed to specify Trigger that refer to CallEvents.     In addition, ReplyActions shall be included in order to finally send the result of the execution of the Operation.

Resolution: Add CallEvent, AcceptCallAction and ReplyAction To disallow the use of methods to implement operations, as suggested in the issue description, would be a major backward incompatibility with previous versions of fUML and a radical departure from typical object-oriented practice. It would also essentially require all classes to be active, since only active objects have event pools and can react to event occurrences. Finally, it would require that the fUML execution model be completely rewritten, along with its base semantics, since it currently uses an OO style in which (concrete) operations always have methods. On the other hand, the Precise Semantics of State Machines (PSSM) specification (as submitted) adds the ability for state machines to handle call events, as an alternative to, not a replacement for, using methods to implement operations. But the generic handling of operations via call events (as described in the UML 2.4.1/2.5 semantics) is not really specific to state machines. So it is reasonable to suggest that this capability would be better incorporated into the common behavior semantics of fUML, rather than only being available when a tool conforms to PSSM. Indeed, the PSSM alpha specification gets around the lack of support for call events in the fUML common semantics by introducing a specialization of the RedefinitionBasedDispatchStrategy class that returns a special kind of Execution when a call is to be handled using a call event. However, this means that any tool using an alternative dispatch strategy would also need to have a specialization of that strategy that is similarly modified to be able to handle calls using call events ? but only for use when PSSM is supported. It would clearly be better if any properly specified dispatch strategy would automatically work whether a call ended up being handled by a method or by a call event occurrence. Further, the PSSM alpha specification uses a "spin loop" (i.e., a loop that continually checks the value of a semaphore, which is expected to be reset by a concurrent process) to specify the blocking of a caller while it waits for a call event occurrence to be handled by the target object. This is problematic, since the fUML concurrency semantics do not guarantee that any one executing process allow any other process to execute, except at a "wait point" (such as an accept event action). This means that, as currently specified in PSSM, it would be a legal execution trace for a "blocked" caller to continually execute its loop, without allowing the target object classifier behavior to ever execute to handle the call event occurrence, so the call would never complete. Any alternative to using a "spin loop" blocking approach would need to be incorporated directly into the fUML common behavior semantics. Unfortunately, to do so would require a major change to the handling of synchronous calls in general. This is because, even if a behavior is itself invoked directly, whether via a direct call or as an operation method, it could (directly or indirectly) call an operation that is handled using a call event occurrence. Thus, the execution model would have to take into account that, on any call action or other synchronous behavior execution, the call might have to block for an arbitrarily long amount of time (or forever), waiting while some call event occurrence remains unhandled. One way to handle this would be by specifying that output parameter values from any behavior execution be delivered via a "call back" mechanism. A caller would provide a "continuation" object when calling the execute operation on the behavior execution, and output parameter values from the invocation would be delivered by calling an operation on the provided object, rather than being set during the running of execute itself. Thus, if the call gets blocked waiting for the handling of a call event occurrence, the original execute call could return, with the caller only continuing once a call back is made to its continuation object (if ever). But this would be a major change to the fundamental approach for handling synchronous invocation in the fUML execution model, all the way up to the event accepter mechanism (since a run-to-completion step is essentially specified in the fUML execution model by making a synchronous call to an event accepter). And this would not only complicate the specification of fUML, it would also make it significantly more complicated to handle, e.g., the invocation of entry, exit and effect behaviors on state machines in PSSM. It is therefore not considered feasible to propose this approach in the context of an RTF issue resolution. Another possibility would be to introduce a mechanism into the base semantics, that is, the formal semantics of Base UML (bUML), in which the fUML execution model is written. However, in order to do this, it would be necessary to also extend bUML syntactically with a UML feature that could represent such blocking. For example, an accept event action could be used with a trigger for a change event on a semaphore attribute (which would avoid the need for a spin loop) or for a time event (which would allow a caller to "wait" for some period of time during an iteration of a spin loop, allowing other processes to execute). But one of the fundamental tenets of bUML is that it is a syntactic subset of fUML ? that is, the fUML execution model is itself a legal fUML model. That means that any new feature introduced into bUML would also need to be introduced into fUML. But both change events and time events have not been incorporated into fUML so far because of the difficulty in specifying their (general) functionality. So, again, it is not considered appropriate to attempt introducing this functionality simply to address an issue that did not even request that functionality specifically. Therefore, while this resolution does propose adding CallEvent, AcceptCallAction and ReplyAction to fUML, it specifies their semantics using an approach similar to that in the PSSM alpha specification, using a spin loop. However, a requirement is added, without further formal basis, that an execution trace that consists entirely of a caller executing a spin loop for all time is not allowed, unless no other execution trace is possible (i.e., no other non-blocked concurrent processes are available to execute). It is considered clear that this can be implemented in practice in any execution tool, evn in the absence of further formalization. However, it is also expected that the requirement will be more formally specified in a future major revision of fUML.
Revised Text: Update the specification document as follows, and also make corresponding updates to the normative fUML Syntax and Semantics XMI files. (Note: This resolution presumes the resolution to issue [1]FUML13-25.) Clause 7 Abstract Syntax In 7.2.2.2.25 Operation, under Additional Constraints, replace the operation [1] zero_or_one_method with the following: [1] fUML_operation_has_at_most_one_method If an operation is abstract, it must have no method. Otherwise it must not have more than one method and it must have exactly one method unless owned by an active class. if self.isAbstract then self.method->isEmpty() else self.method->size() <= 1 and ((self.class = null or not self.class.isActive) implies self.method->size() = 1) endif In 7.3.2.1 Overview, in Figure 7.15 Common Behavior, replace the body of the comment on the class Operation with "If an operation is abstract, it must have no method. Otherwise it must not have more than one method and it must have exactly one method unless owned by an active class." In 7.3.3.1 Overview, in the bullet list after "From Events", remove the second bulleted item in the list. In Figure 7.18 Events, replace the diagram with: Add the following subclause, and renumber subsequent subclauses appropriately. 7.3.3.2.1 CallEvent Generalizations *MessageEvent Attributes None Associations *operation : Operation Additional Constraints [1] fUML_call_event_operation_has_no_method The operation of the call event must not have any methods. self.operation.method->isEmpty() In 7.5.4.1 Overview, in the bullet list following "From Accept Event Actions", remove the first two bulleted items. In Figure 7.35 Accept Event Actions, replace the diagram with: Editorial Note. Figure 7.35 is renumbered to 7.36 as a result of the resolution to issue [2]FUML13-4. Add the following subclause, and renumber subsequent subclauses appropriately. 7.5.4.2.1 AcceptCallAction Generalizations *AcceptEventAction Attributes None Associations *returnInformation : OutputPin Additional Constraints [1] fUML_accept_call_action_call_event_operations The operations of the call events on the triggers of an accept call action must be owned or inherited by the context class of the action. let cls: Class = self.context.oclAsType(Class) in let classes:Bag(Class) = cls.allParents()->select(oclIsKindOf(Class))->collect(oclAsType(Class))->union(cls->asBag()) in classes.ownedOperation->includesAll(self.trigger.event->collect(oclAsType(CallEvent)).operation) In 7.5.4.2.1 AcceptEventAction (7.5.4.2.2 as renumbered), under Additional Constraints, in constraint [2] fUML_only_signal_event_triggers, in the description, replace "All" with "Unless the action is an accept call action, all". Add the following to the beginning of the OCL: not self.oclIsKindOf(AcceptCallAction) implies. In constraint [3] fUML_receive_all_triggering_signals, in the description, replace "The" with "Unless the action is an accept call action, the". Add the following to the beginning of the OCL: not self.oclIsKindOf(AcceptCallAction). After 7.5.4.2.5 ReduceAction (7.5.4.2.6 as renumbered), add the following subclause, and renumber subsequent subclauses appropriately. 7.5.4.2.7 ReplyAction Generalizations *Action Attributes None Associations *replyToCall : Trigger *replyValue : InputPin [0..*] *returnInformation : InputPin Additional Constraints None Clause 8 Execution Model In 8.2.2.2.3 ExecutionFactoryL1, in the operation [1] instantiateVisitor, after the last else clause but before the return statement, add the following: else if (element instanceof CallEventBehavior) { visitor = new CallEventExecution(); } In 8.2.4.2.1 ExecutionFactoryL3, in the operation [1] instantiateVisitor, before else if(element instanceof AcceptEventAction), add the following: // Note: Since AcceptCallAction is a subclass of AcceptEventAction, // element must be tested against AcceptCallAction before // AcceptEventAction. else if (element instanceof AcceptCallAction) { visitor = new AcceptCallActionActivation(); } In 8.3.2.1 Overview, under Polymorphic Operation Dispatching, at the end of the first sentence, change "an abstract getMethod operation" to "a second operation, getMethod". After that paragraph, insert the following: It is also possible for a concrete operation to have no method, if calls to it are to be handled using a call event (see the discussion of accept call actions in 8.6.4). This case is still managed through the dispatch strategy. Instead of using a method behavior defined for the operation in the model, an instance of a special CallEventBehavior class (see 8.4.3) is created to act as an effective method for the call. For convenience, the getMethod operation in the DispatchStrategy superclass this functionality, which may be used as appropriate in the definition of the getMethod operation for a subclass of DispatchStrategy (for example, the redefinition based dispatch strategy getMethod operation calls the superclass operation if it identifies a concrete, most-redefined operation, but that operation does not have a method). The execution created for a call event behavior is an instance of the CallEventExecution class, which carries out the behavior of sending a call event occurrence and waiting for a response. In Figure 8.12 Structured Values, show the operation DispatchStrategy::getMethod as being concrete rather than abstract. In 8.3.2.2.4 Dispatch Strategy, under Operations, change the body of operation [3] getMethod to: // Get the method that corresponds to the given operation for the given object. // By default, the operation is treated as being called via a call event occurrence, // with a call even behavior as its effective method. Concrete dispatch strategy // subclasses may override this default to provide other dispatching behavior. CallEventBehavior method = new CallEventBehavior(); method.setOperation(operation); return method; In 8.3.2.2.22 RedefinitionBasedDispatchStrategy, replace the introductory description with the following: A redefinition-based dispatch strategy is one that requires an overriding subclass operation to explicitly redefine the overridden superclass operation. If a concrete operation has no methods, then it is assumed to be handled by a call event; otherwise, it should have at most one method. Under Operations, in the operation [1] getMethod, change the introductory comment to: // Find the member operation of a type of the given object that // is the same as or a redefinition of the given operation. Then // return the method of that operation, if it has one, otherwise // return a CallEventBehavior as the effective method for the // matching operation. // [If there is more than one type with a matching operation, then // the first one is arbitrarily chosen.] Replace the nested statement method = memberOperation.method.getValue(0); with if (memberOperation.method.size() == 0) { method = super.getMethod(object, memberOperation); } else { method = memberOperation.method.getValue(0); } In 8.4.3.1 Overview, under Event Dispatching, after the first paragraph, add the following: Note: Operations calls are always synchronous invocations in fUML, as opposed to signal sends, which are always asynchronous invocations. Nevertheless, when an operation call is handled by an active object via a call event, the call even occurrence is handled asynchronously by the object, in the sense discussed above. The synchronous nature of the call is maintained for the caller by requiring the caller to block the execution thread making the call until the call event occurrence is dispatched and replied to. See also the discussion of call event occurrences under Event Occurrences below. Under Event Occurrences, in the first paragraph, in the second sentence, change "two kinds of events" to "three kinds of events" and change "and signal reception events" to ", signal reception events and operation call events". In the fifth (last) paragraph, replace the third and following sentences with: Currently, a regular accept even action in fUML is limited to handling signal events, while an accept call action (a special kind of accept event action) is used to handle call events (see 8.6.4.2.1). When an event occurrence is received by an active object, it is placed in the event pool. When this event occurrence is dispatched, if there is a matching accept event action accepter for it, then it will be accepted by the accept event action (or accept call action, for a call event occurrence), resulting in the resumption of execution of the activity containing the action. After that paragraph, add the following new paragraph: As mentioned above under Event Dispatching, an operation call is always a synchronous invocation from the point of view of the caller, even if it is handled asynchronously using a call event at the target. In order to achieve this, a call event occurrence is always sent by executing a special call event execution object (see 8.4.3.2.2), after which the calling execution thread is blocked until a reply to the call is received. Blocking is specified in the suspend operation of the call event execution using a loop that repeatedly checks for the callSuspended flag to be reset by the concurrent thread responding to the call. The body of the loop consists of a call to a special wait operation, which does nothing but, during which, a conforming execution tool must allow other concurrent threads to run. That is, an execution trace that, after a certain point, consists entirely of a caller executing one or more suspend loops for all time is not allowed, unless no other execution trace is possible (i.e., no other non-blocked concurrent threads are available to execute). Note: The special rule above concerning waiting is necessary because fUML allows great flexibility in whether a conforming execution tool actually implements a concurrent thread as a parallel execution or not (see 2.4). Without this rule, it would be allowable for an conforming execution tool to consume all processing resources executing one or more suspend loops and never allow the execution of the dispatch loops necessary to handle the call event occurrences that have been sent. Even with the rule, however, it is not inherently guaranteed that any call event occurrence will ever be dispatched, since the dispatch loop of the target object that receive it may still be blocked forever, in a particular implementation, by some other non-suspended thread. In Figure 8.16 Event Occurrences, replace the diagram with: Editorial Note. This diagram also reflects changes made in the resolutions for issues [3]FUML13-1 and [4]FUML13-25. Under 8.4.3.2 Class Descriptions, add the following subclauses, and renumber subsequent subclauses appropriately: 8.4.3.2.1 CallEventBehavior A call event behavior is a special kind of behavior used to represent the type of a call event execution. It is not directly a part of a user model, but has a signature constructed from the signature of the operation being called. Generalizations *Behavior Attributes None Associations *operation : Operation The operation whose call is to be handled via a call event. Operations [1] setOperation ( in operation : Operation ) // Set the operation for this call event behavior and construct // the behavior signature based on the operation signature. this.operation = operation; for(int i = 0; i < operation.ownedParameter.size(); i++){ Parameter operationParameter = operation.ownedParameter.get(i); Parameter parameter = new Parameter(); parameter.name = operationParameter.name; parameter.type = operationParameter.type; parameter.multiplicityElement.lowerValue = operationParameter.multiplicityElement.lowerValue; parameter.multiplicityElement.lower = operationParameter.multiplicityElement.lower; parameter.multiplicityElement.upperValue = operationParameter.multiplicityElement.upperValue; parameter.multiplicityElement.upper = operationParameter.multiplicityElement.upper; parameter.direction = operationParameter.direction; parameter.owner = this; parameter.namespace = this; this.ownedElement.addValue(parameter); this.ownedMember.addValue(parameter); this.member.addValue(parameter); this.ownedParameter.addValue(parameter); } this.isReentrant = true; this.name = "CallEventBehavior"; if (operation.name != null) { this.name = this.name + "(" + operation.name + ")"; } Editorial Note. Using the operation EventOccurrence::sendTo in the operation CallEventExecution::makeCall below is consistent with the resolution to issue [5]FUML13-1. 8.4.3.2.2 CallEventExecution A call event execution acts as the effective method execution for an operation call that is to be handled by a call event. When executed, a call event execution sends a call event occurrence to the target object and then suspends until a reply is received. Generalizations *Execution Attributes *callerSuspended : Boolean Indicates whether the caller is suspended, waiting for a reply to the sent call event occurrence. Concurrently setting this flag to "false" releases the caller. Associations None Operations [1] copy ( ) : Value // Create a new call event execution that is a copy of this execution, with the // caller initially not suspended. CallEventExecution copy = (CallEventExecution)super.copy(); copy.callerSuspended = false; return copy; [2] createEventOccurrence ( ) : EventOccurrence // Create a call event occurrence associated with this call event execution. // (This operation may be overridden in subclasses to alter how the event // occurrence is create, e.g., if it is necessary to wrap it.) CallEventOccurrence eventOccurrence = new CallEventOccurrence(); eventOccurrence.execution = this; return eventOccurrence; [3] execute( ) // Make the call on the target object (which is the context of this execution) // and suspend the caller until the call is completed. // Note: The callerSuspended flag needs to be set before the call is made, // in case the call is immediately handled and returned, even before the // suspend loop is started. this.setCallerSuspended(true); this.makeCall(); this.suspendCaller(); [4] getInputParameterValues ( ) : ParameterValue[0..*] // Return input parameter values for this execution. ParameterValueList parameterValues = new ParameterValueList(); for(int i=0; i < this.parameterValues.size(); i++){ ParameterValue parameterValue = this.parameterValues.get(i); if(parameterValue.parameter.direction == ParameterDirectionKind.in | parameterValue.parameter.direction == ParameterDirectionKind.inout){ parameterValues.addValue(parameterValue); } } return parameterValues; [5] getOperation ( ) : Operation // Return the operation being called by this call event execution. return ((CallEventBehavior)this.getBehavior()).operation; [6] isCallerSuspended ( ) : Boolean // Check if the caller is still suspended. // This is done in isolation from possible concurrent updates to this flag. _beginIsolation(); boolean isSuspended = this.callerSuspended; _endIsolation(); return isSuspended; [7] makeCall ( ) // Make the call on the target object (which is the context of this execution) // by sending a call event occurrence. (Note that the call will never be // completed if the target is not an active object, since then the object // would then have no event pool in which the event occurrence could be placed.) Reference reference = new Reference(); reference.referent = this.context; this.createEventOccurrence().sendTo(reference); [8] new_ ( ) : Value // Create a new call event execution. return new CallEventExecution(); [9] releaseCaller ( ) // Release the caller, if suspended. this.setCallerSuspended(false); [10] setCallerSuspended ( in callerSuspended : Boolean ) // Set the caller suspended flag to the given value. // This is done in isolation from possible concurrent queries to this flag. _beginIsolation(); this.callerSuspended = callerSuspended; _endIsolation(); [11] setOutputParameterValues ( parameterValues : ParameterValue[0..*]) // Set the output parameter values for this execution. ParameterList parameters = this.getBehavior().ownedParameter; int i = 1; int j = 1; while (i <= parameters.size()) { Parameter parameter = parameters.get(i-1); if (parameter.direction == ParameterDirectionKind.inout | parameter.direction == ParameterDirectionKind.out | parameter.direction == ParameterDirectionKind.return_ ) { ParameterValue parameterValue = parameterValues.get(j-1); parameterValue.parameter = parameter; this.setParameterValue(parameterValue); j = j + 1; } i = i + 1; } [12] suspendCaller ( ) // Suspend the caller until the caller is released. while(this.isCallerSuspended()) { this.wait_(); } [13] wait_ ( ) // Wait for an indeterminate amount of time to allow other concurrent // executions to proceed. // [There is no further formal specification for this operation.] 8.4.3.2.3 CallEventOccurrence A call event occurrence represents the occurrence of a call event due to a call to a specific operation. Generalizations *EventOccurrence Attributes None Associations *execution : CallEventExecution The call event execution that created this call event occurrence. Operations [1] getOperation ( ) : Operation // Get the operation being called by this call event occurrence. return this.execution.getOperation(); [2] getParameterValues ( ) : ParameterValue [0..*] // Return the input parameter values from the call event execution for // this call event occurrence, which correspond to the values of the // operation input parameters for the call. return this.execution.getInputParameterValues(); [3] match ( trigger : Trigger ) : Boolean // Match a trigger if it references a call event whose operation is the // operation of this call event occurrence. boolean matches = false; if (trigger.event instanceof CallEvent) { CallEvent callEvent = (CallEvent)trigger.event; matches = callEvent.operation == this.getOperation(); } return matches; [4] returnFromCall ( ) // Release the caller on return from the call. this.execution.releaseCaller(); [5] setOutputParameterValues ( parameterValues : ParameterValue[0..*] ) // Set the output parameter values of the call event execution for // this call event occurrence, which correspond to the values of the // operation output parameters for the call. this.execution.setOutputParameterValues(parameterValues); In 8.6.4.1 Overview, under Accept Event Action, in the first paragraph, replace the last sentence with: In fUML, an accept event action is either a regular accept event action, in which case it can only with for signal events, or it is specialized accept call action, which case it can only wait for call events (see 7.5.4). The discussion on accept event actions below also applies to accept call actions. This is followed by some additional discussion specific to accept call actions. In the third paragraph, in the first sentence, change "a signal event occurrence" to "an event occurrence" and remove "with a signal instance". After the section Accept Event Action and before the section Reduce Action, add the following: Accept Call and Reply Actions An accept call action is a specialized accept event action used to wait for call events. It registers and accepts event occurrences as described for accept event actions in general above. However, when triggered, in addition to producing the unmarshalled values of the input parameters of the called operation (if any), an accept call action produces another output, the return information for the call. Return information is a special value that may be passed on an object flow of an activity, but is only usable as input to a reply action, in order to return from a call. The return information contains a link back to the call event occurrence that triggered the accept call action for the call. When a reply action fires, it takes values for the output parameters of the called operation (if any) from its replyValue input pins and a return information value from its returnInformation pin. It then returns output parameter values to the caller using the reply operation on the return information. This reply operation then sets the output parameter values via the call event occurrence and releases the calling thread, which will have been suspended waiting for a reply to the call (see 8.4.3). Note: A reply action is associated with a trigger that identifies the call event from which the reply actionis returning. The UML Superstructure Specification (subclause 11.3.43) states that "The operation specified by the call event on the trigger must be consistent with the information returned at runtime." In fUML, this is interpreted as meaning that the operation specified by the call event on the trigger must be the same as the operation that was called by the call event occurrence on the return information provided to the call action. If the operations do not match, the reply action has no effect. In Figure 8.35 Accept Action Activations, replace the diagram with: Editorial Note. The above diagram also reflects changes made in the resolution to issue [6]FUML13-25. Under 8.6.4.2 Class Descriptions, add the following subclause, and renumber subsequent subclauses appropriately: 8.6.4.2.1 AcceptCallActionActivation An accept call action activation is a specialized accept event action activation for an accept call action. Generalizations *AcceptEventActionActivation Attributes None Associations None Operations [1] accept ( eventOccurrence : EventOccurrence ) // Accept the given event occurrence, which must be a call event occurrence. // Place return information for the call on the return information // output pin. Then complete the acceptance of the event occurrence // as usual. AcceptCallAction action = (AcceptCallAction) this.node; OutputPin returnInformationPin = action.returnInformation; ReturnInformation returnInformation = new ReturnInformation(); returnInformation.callEventOccurrence = (CallEventOccurrence) eventOccurrence; this.putToken(returnInformationPin, returnInformation); super.accept(eventOccurrence); After 8.6.4.2.6 ReduceActionActivation (8.6.4.2.7 as renumbered), add the following subclauses, and renumber subsequent subclauses appropriately: 8.6.4.2.8 ReplyActionActivation A reply action activation is an action activation for a reply action. Generalizations *ActionActivation Attributes None Associations None Operations [1] doAction ( ) // Reply to the call represented by the return information on // the return information pin using the reply values given // on the reply value pins. ReplyAction action = (ReplyAction) this.node; Trigger replyToCall = action.replyToCall; InputPinList replyValuePins = action.replyValue; InputPin returnInformationPin = action.returnInformation; ValueList values = this.takeTokens(returnInformationPin); ReturnInformation returnInformation = (ReturnInformation) values.getValue(0); if (replyToCall.event instanceof CallEvent & ((CallEvent)replyToCall.event).operation == returnInformation.getOperation()) { ParameterValueList parameterValues = new ParameterValueList(); int i = 1; while (i <= replyValuePins.size()) { ParameterValue parameterValue = new ParameterValue(); parameterValue.values = this.takeTokens(replyValuePins.getValue(i - 1)); parameterValues.addValue(parameterValue); i = i + 1; } returnInformation.reply(parameterValues); } 8.6.4.2.9 ReturnInformation Return information is a value that contains the information necessary to return from an operation call handled as a call event in an activity. It is placed on the returnInformation output pin of an accept call action and is only usable as a value on the input pin of a reply action. Generalization *Value Attributes None Associations *callEventOccurrence : CallEventOccurrence The call event occurrence for the call to which the return information applies. Operations [1] getOperation ( ) : Operation // Return the operation associated with the call event occurrence of this // return information. return this.callEventOccurrence.getOperation(); [2] copy ( ) : Value // Create a new return information value that is a copy of this value, with // the same call event occurrence. ReturnInformation copy = (ReturnInformation)super.copy(); copy.callEventOccurrence = this.callEventOccurrence; return copy; [2] equals(Value otherValue) : Boolean // One return information value equals another if they are for the // same call event occurrence. boolean isEqual = false; if (otherValue instanceof ReturnInformation) { isEqual = ((ReturnInformation)otherValue).callEventOccurrence == this.callEventOccurrence; } return isEqual; [3] getTypes ( ) : Classifier[0..*] // Return information is untyped. return new ClassifierList(); [4] new_ ( ) : Value // Create a new return information value, with an empty call event occurrence. return new ReturnInformation(); [5] reply ( outputParameterValues : ParameterValue[0..*] ) // Reply to the call by setting the output parameters and // releasing the caller. this.callEventOccurrence.setOutputParameterValues(outputParameterValues); this.callEventOccurrence.returnFromCall(); [6] specify ( ) : ValueSpecification // Return information cannot be specified using a value specification. return null; [7] toString ( ) : String // Return a string representation of the return information. String s = "ReturnInformation"; String name = callEventOccurrence.getOperation().name; if (name != null) { s = s + "(" + name + ")"; } return s; ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/FUML13-25 [2] http://issues.omg.org/browse/FUML13-4 [3] http://issues.omg.org/browse/FUML13-1 [4] http://issues.omg.org/browse/FUML13-25 [5] http://issues.omg.org/browse/FUML13-1 [6] http://issues.omg.org/browse/FUML13-25
Actions taken:
November 4, 2015: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19856: Stand-alone owned behavior of BehavioredClassifier shall be possible (fuml-rtf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Revision
Severity: Minor
Summary:

The constraint [1] UML_allowed_owned_behaviors in section 7.3.2.2.2 prohibits stand-alone owned behaviors of a BehavioredClassifier. This wastes a lot of potential, in particular when CallEvents are finally included into fUML (like in PSSM). Owned behaviors that are not classifier behaviors and not operation methods serve the purpose of tailoring the classifier behavior into smaller scenarios which could even be invoked independently from each other. It further allows the extraction of shared procedures without the need of calling an Operation. It would simply provide higher expressiveness at specification level.

Resolution: Remove fUML_allowed_owned_behaviors constraint Removing the constraint BehavioredClassifier::fUML_allowed_owned_behaviors might give some benefit, as suggested in the issue description, and would seemingly not cause any problem, at least for calling a non-classifier-behavior owned-behavior synchronously. The constraint CallBehaviorAction::proper_context would still apply, meaning that an owned behavior of a class could only be called from an activity that had the same static context as the target behavior, so that the dynamic context could be properly propagated. However, starting such an owned behavior asynchronously would be a problem. Since using a start object behavior action on a non-behavior object always started its classifier behavior (if it has one), the only way to start a non-classifier-behavior owned behavior would be to use it directly as the object of a start object behavior action. But, in this case, there would be no other context object given, so the resulting behavior execution would become its own context ? which would not be consistent with the static context of the owned behavior. Actually, though, this is already a problem in the current specification, since there currently is no constraint nothing to prevent the method of an operation (or a classifier behavior, for that matter) from being instantiated and a start object behavior action being used on the resulting object. So eliminating fUML_allowed_owned_behaviors does not introduce any new problems. Nevertheless, this problem can be easily fixed by simply disallowing the use of a create object action on an owned behavior. In this way, classifier behaviors could only be started asynchronously by using a start object action on their context object, while other owned behaviors could only be called synchronously.
Revised Text: In 7.3.2.1 Overview, in Figure 7.15, remove the constraint "An owned behavior must be either the classifier behavior of or the method for an operation of its behaviored classifier." on BehavioredClassifier. In 7.3.2.2.2 BehavioredClassifier, under Additional Constraints, replace the specification of the constraint [1] fUML_allowed_owned_behaviors with "None". In 7.5.3.1 Overview, in Figure 7.30 Object Actions, add the constraint "The given classifier must not be an owned behavior (or otherwise have a context classifier)." to the class CreateObjectAction. In 7.5.3.2.5 CreateObjectAction, under Additional Constraints, add the following constraint: [2] fUML_not_owned_behavior The given classifier must not be an owned behavior (or otherwise have a context classifier). self.classifier.oclIsKindOf(Behavior) implies self.classifier.oclAsType(Behavior).context = null Also make the above changes in the normative fUML Syntax XMI. In 8.6.3.1 Overview, under Object Actions, at the end of the the first bulleted paragraph, add the following: The classifier for a create object action may be a behavior, in which case the instance created is an unstarted behavior execution that may be started asynchronously using a start object behavior action (see 8.6.4). However, in fUML, the classifier may not be an owned behavior (see 7.5.3), because starting an instance of such a behavior asynchronously would not allow for the execution context (which must be an instance of its context classifier) to be set properly. An owned behavior may be called synchronously or, if it is a classifier behavior, it may be started asynchronously using a start object behavior action on an instance of its (owning) context classifier (see 8.6.4).
Actions taken:
November 12, 2015: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19866: Prose for semantics of AddStructuralFeatureValueAction required (fuml-rtf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity: Minor
Summary:

UML 2.5, section 16.8.3.3 Add Structural Feature Value Actions says:      "The semantics are undefined for adding a value that violates the upper multiplicity of the StructuralFeature, and for   adding a new value to a StructuralFeature with isReadonly=true after initialization of the object that would have the   value."      In fUML, this undefined semantics is resolved. Values are simply added to the StrucutalFeature of the target object. This semantics is also described in the implementation of AddStructuralFeatureValueActionActivation.doAction() (section 8.6.3.2.1, pp. 298).    Since this implementation represents the resolution of an undefined semantics of the UML specification, section 7.5.3.2.1 AddStructuralFeatureValueAction should add a prose description of this resolution to its "semantics" clause. It would increase the readability and comprehensibility of the spec.

Resolution: Add note on AddStructuralFeatureValueAction Agreed, in principle. However, 7.5.3.2.1 in the fUML specification does not have a "semantics clause", because it is in the clause on abstract syntax, not semantics. Instead, a note should be added under "Structural Feature Actions" in 8.6.3.1, the Overview for Intermediate Actions. Also, currently, the UML specification reference still needs to be to the UML 2.4.1 Superstucture Specification.
Revised Text: In 8.6.3.1, under "Structural Feature Actions", after the first paragraph, add: Note: The UML Superstructure Specification (subclause 11.3.5) states that, for an add structural feature value action, "The semantics is undefined for adding a value that violates the upper multiplicity of the structural feature." Nevertheless, the fUML semantics are defined in this case, such that the given value is always added, even though it violates the upper multiplicity of the structural feature.
Actions taken:
December 3, 2015: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue