Issue 15094: Additional changes required for action firing semantics (fuml-ftf)
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

Subclause:  8.6.2.2.1 ActionActivation

 

Before the adoption of the resolution to Issue 14550 (Revise fUML to be based on UML 2.3), when an action fired it accepted all tokens offered to its input pins, even if this was more than the multiplicity upper bound of a pin. However, on any one firing, it would only consume at most a number of tokens equal to the multiplicity upper bound on each pin. If tokens were left on pins greater than the multiplicity lower bounds, then it would fire again.

 

UML 2.3 clarified that an action never accepts offers for tokens above the multiplicity upper bounds of its pins. The semantics of actions were changed in the resolution of 14550 to be consistent with this. However, the semantics for firing the again were not properly changed to reflect the fact that, if the action is, indeed, ready to fire again, the tokens it needs will not actually be on its input pins yet. The semantics for firing again needs to be updated to explicitly accept the pending offers for incoming tokens when the action fires again.

 

Resolution: Agreed.
Revised Text: In Subclause 8.6.2.2.1 ActionActivation, change the code for the fire operation to:
// Do the main action behavior then concurrently fire all output pin activations 
// and offer a single control token.  Then activate the action again, 
// if it is still ready to fire and has at least one token actually being
// offered to it.

Action action = (Action)this.node;
InputPinList inputPins = action.input;

boolean fireAgain = false;
do {

    Debug.println("[fire] Action " + this.node.name + "...");

    this.doAction();
    this.sendOffers();

    Debug.println("[fire] Checking if " + this.node.name + " should fire again...");

    _beginIsolation();
        this.firing = false;
        if (this.isReady()) {
            incomingTokens = this.takeOfferedTokens();
            fireAgain = incomingTokens.size() > 0;
            this.firing = this.isFiring() & fireAgain;
        }
    _endIsolation();

} while (fireAgain);
In the takeOfferedTokens operation, before the first loop, add the line:
TokenList offeredTokens = new TokenList();
At the end of the nested loop within the first loop, add the line:
offeredTokens.addValue(token);
At the end of the second loop, add:
for (int j = 0; j < tokens.size(); j++) {
    Token token = tokens.getValue(j);
    offeredTokens.addValue(token);
}
Replace:
return new TokenList();
with:
return offeredTokens;

Actions taken:
February 27, 2010: received issue
July 23, 2010: closed issue
Discussion: 

End of Annotations:=====
ubject: Additional changes required for action firing semantics
Date: Sat, 27 Feb 2010 12:31:40 -0500
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Additional changes required for action firing semantics
thread-index: Acq30riPRfQx++bmRr+IKqVW6+9Pcw==
From: "Ed Seidewitz" <ed-s@modeldriven.com>
To: <issues@omg.org>


Specification: Semantics of a Foundational Subset for Executable UML Models

Subclause:  8.6.2.2.1 ActionActivation

 

Before the adoption of the resolution to Issue 14550 (Revise fUML to be based on UML 2.3), when an action fired it accepted all tokens offered to its input pins, even if this was more than the multiplicity upper bound of a pin. However, on any one firing, it would only consume at most a number of tokens equal to the multiplicity upper bound on each pin. If tokens were left on pins greater than the multiplicity lower bounds, then it would fire again.

 

UML 2.3 clarified that an action never accepts offers for tokens above the multiplicity upper bounds of its pins. The semantics of actions were changed in the resolution of 14550 to be consistent with this. However, the semantics for firing the again were not properly changed to reflect the fact that, if the action is, indeed, ready to fire again, the tokens it needs will not actually be on its input pins yet. The semantics for firing again needs to be updated to explicitly accept the pending offers for incoming tokens when the action fires again.