Work on the PSCS 1.1 revision has indicated that the resolution to FUML13-1 could be simplified.

1. There is no need to for the SendSignal signal. It is enough for the EventOccurrence classifier behavior to start asynchronously.

2. The call to Reference::send can be moved into a EventOccurrence::doSend operation, simplifying the EventOccurrence SendingBehavior activity and also allowing doSend to be overridden in subclasses of EventOccurrence.

Update EventOccurrence::SendBehavior

Agreed that the resolution to FUML13-1 can be simplified as suggested.

The Reference::equals operation checks that two References are equal if they reference the same Object. This check is done by testing the identity of the two referenced Objects using "==". It would be better if the test on the Objects was done using the Object::equals operation. Even though the Object::equals operation itself simply uses "==", using Object::equals in Reference::equals allows for the possibility of subclasses of Object to redefine equals as used in Reference (this is desirable, for example, for the PSSM DoActivityContextObject class, which should be considered "equal", but not "identical", to the Object that it wraps).

Update Reference::equals and add Object::equals

Actually, Object does not currently override the equals operation, so that the CompoundValue::equals operation is inherited, which specifies equality based on value, not identity. However, if an appropriate Object::equals operation is also added, then the Reference::equals operation may be updated as suggested in the issue description.

The EventOccurrence class was introduced in fUML 1.2 as the parent of SignalEventOccurrence and InvocationEventOccurrence. However, as introduced, it has no operations. This means that, to operate on any EventOccurrence instance, it is necessary to check what the actual type of the instance is and then cast it to the appropriate subclass. This becomes increasingly cumbersome as additional subclasses are added in other specifications built on fUML (such as CallEventOccurrence for PSSM). It would be clearer and more extensible to have certain general operations defined abstractly for EventOccurrence, which could then have proper implementations in appropriate subclasses. Useful such operations would include at least one to match an EventOccurrence against a Trigger and one to extract any event data from an EventOccurrence.

Add operations to EventOccurrence

Other than for invocation event occurrences, the acceptance of an event occurrence is constrained to the case when they match a trigger. In fUML only accept event actions have triggers, and only for signal events, but specifications built on fUML (such as PSSM) may allow other model elements to have triggers (such as transitions in state machines) and allow other kinds of events on triggers (such as call events). Each kind of event occurrence has specific logic required to determine whether it matches a specific trigger and to extract any data embedded in it. Currently, fUML embeds this logic in classes specific to the handling of signal event occurrences, without providing a common interface for allowing other specifications to provide different logic for different kinds of event occurrences.

A better approach would be to provide a common interface of abstract operations in EventOccurrence for matching (match) and data extraction (getParameterValues). These operations would have different behaviors in different concrete subclasses of EventOccurrence, but they could be accessed consistently across all kinds of event occurrences. For fUML, this would then require providing such concrete behavior in the SignalEventOccurrence subclass, with corresponding updates to AcceptEventActionActivation and AcceptEventActionEventAccepter to take advantage of the new operations. (The operations would be essentially stubbed out in InvocationEventOccurrence.)

Note also that the matching of a signal occurrence to a signal event trigger that currently occurs in AcceptEventActionActivation::match uses the checkAllParents helper operation. This helper operations is currently in ActionActivation, since it is also used in ReadIsClassifiedObjectActionActivation::doAction. However, when the signal matching logic is moved to SignalEventOccurrence::match, ActionActivation is no longer a common superclass. In order to avoid repeating the definition of checkAllParents, this helper operation can be moved to the Value class. This allows the definition of a useful Value::isInstanceOf operation, which can be used in both SignalEventOccurrence::match and ReadIsClassifiedObjectActionActivation::doAction instead of calling checkAllParents directly, simplifying both of those operations.

Figure 8.17 shows the return type of ObjectActivation::getNextEvent as SignalInstance. However, the return type given in 8.4.3.2.7 ObjectActivation is EventOccurrence. The type in Figure 8.17 should be updated to EventOccurrence.

Fix getNextEvent return type

Agreed. In addition, the wrong return type is also shown for the getNextEvent operation on the strategy classes. And the return type is wrong in the normative semantic model XMI, too.

The EventOccurrence class was introduced in fUML 1.2, with SignalEventOccurrence . However, the execution model classes Object, ObjectActivation and Reference still use SignalInstance as the type of various operations related to sending. These should be changed to EventOccurrence to allow other specifications built on fUML to specify the sending of other types of EventOccurrences (such as CallEventOccurrences in PSSM).

Change SignalInstance usage to EventOccurrence

In the current shape of the fUML semantic model, active objects can only perform event based communications using signals. This limitation is introduced by the way that: Reference, Object and ObjectActivation classes are defined. Indeed, these latter all provide a send(in signal: SignalInstance) operation which only enables a signalInstance to be sent to the event pool of an active object.

However, it became clear that extensions to fUML may need to support event based communications not limited to signal event occurrence. PSSM is good example of this with the introduction of a support for call event occurrence. In order to relax the constraint on the type of event based communications that can be performed between instance of active objects, the signatures and the implementations of the send operations provided by Reference, Object_ and ObjectActivation must be changed. This change consists in using EventOccurrence in place of SignalInstance in the signatures and implementations of the different send operations. Note that the doAction operation of the SendSignalActionActivation class will have to be updated to account for changes performed in Reference class.

Resolution of issue FUML 13-25 forgets to mention to remove a small piece of code.

At the very end of the proposal, when the change required to be applied to ReadIsClassifierObjectActionActivation was explained, it was proposed to:

­

replace the statement int i = 1; and the while loop immediately after that statement with:

This was not sufficient since the newly proposed if statement implied that it was not required to iterate over the list of types of the input. Hence the above-mentioned change must be replaced with:

replace statements ClassifierList types = input.getTypes() , int i = 1 as well as the while loop immediately after that statements with:”

Remove unnecessary statement

Event though leaving the statement ClassifierList types = input.getTypes(); causes no functional effect, it is, as the issue notes, no longer necessary. Therefore, it is confusing to leave in and should be removed.

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.

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.

In figure 7.3 - Root on page 26, the association roles "/owner" and "/ownedElement" on the recursive Association are flipped. Current "/owner" should be "/ownedElement" and current "/ownedElement" should be "/owner".

Fix Figure 7.3

Agreed, Figure 7.3 is incorrect as indicated in the issue. However, the corresponding normative XMI is correct. This is entirely a diagrammatic problem.

The Java code for various operations in the execution model contains at various points statements consisting of invocations of Debug::println. This is a remnant of the fUML implementation from which this code was extracted. However, since no mapping is provided for Debug::println in Annex A, all statements involving it should be removed from the specification.

Remove "Debug" statements

Agreed.

Consider an application of IntegerFunctions::Div(x,y) when x > 0 but y < 0. In this case, the postcondition in the definition of the function (given in 9.3.2, Table 9.3) requires that -Div(x,y) * y <= -x < (-Div(x,y) + 1) * y. But this is impossible, because (-Div(x,y) + 1) * y < -Div(x,y) * y, since y < 0.

The "else" expression in the postcondition should actually be:
((Neg(result) * Abs(y)) <= Abs(x) And ((Neg(result)+1) * Abs(y) > Abs(x)
This would ensure that Div(x,y) = -Div(-x,y) = -Div(x,-y) = Div(-x,-y), for all values of x and y (with y <> 0).

Correct postcondition

Agreed. In fact, the postcondition also doesn't work, for a similar reason, in the case that both operands are less than zero.

Consider an activity with one in parameter having multiplicity lower bound of 0. Suppose this activity contains a top-level structured activity node that, in turn, contains an action with an input pin, also having multiplicity lower bound of 0, and an object flow from the activity parameter node for the in parameter to the action input pin. Assume the structured activity node and the action it contains have no other data or control dependencies.

According to the logic specified in ActivityNodeActivationGroup::run, both the activity parameter node and the structured activity node will be enabled when the enclosing activity is executed (because the structured activity node has no incoming edges, even though the action inside it does). The activity parameter node and the structured activity node therefore fire concurrently. Thus, one allowable execution sequence would be for the structured activity node to fire first, resulting in the firing of its contained action, before the activity parameter node fires. Since the activity parameter node has not fired, it does not yet contain any value that might be on the in parameter, but the action will fire anyway, because its input pin has multiplicity lower bound of 0.

The fact that it is allowable for the action in this example to fire with no input, even if there is an input available on the in parameter, would seem to not be what most modelers would expect in this situation. To avoid this, it would be better if, when an activity is run, any input activity parameter nodes are fired first, before any other enabled activity nodes. Note that this is parallel to the case of a structured activity node, in which any input pins of the structure activity node fire before any nodes within the structure activity node fire.

Update ActivityNodeActivationGroup::run

Agreed.

In 8.6.3.1 Overview, under "Structural Feature Actions", it states in the first note that "In fUML, association ends are always owned by the association and never by the types of the ends (see 7.2.2). Therefore, it is not possible to navigate a link in fUML using a structural feature action." However, as part of the resolution to issue FUML-51 Revise fUML to be based on UML 2.3 (legacy issue number 14550), during fUML 1.0 finalization, the semantics for structural feature actions were change to be in accordance with the resolution to UML22-263 (legacy issue number 10045):

10045 - The resolution of this issue clarifies that a structural feature action can be used to read and write an association end of a binary association as if it was a feature of the opposite classifier, even if the end is not actually owned by that classifier. This requires updating the doAction operations of the various structural feature action activation classes so that the actions behave like the corresponding link action if their structural feature is an association end. (Note that association ends are never classifier-owned in fUML.)

Thus, the above quoted note in 8.6.3.1 is not correct, and it should have been removed as part of the resolution of FUML-51.

Remove identified note

Agreed.

In the FoundationalModelLibrary::BasicInputOutput package, the TextInputChannel and TextOutputChannel classes have specific operations for reading and writing string, integer, boolean and unlimited natural values. However, there are no specific operations for reading or writing real values, which is inconsistent.

(Note that it is still possible to read and write real values by converting real values to/from strings, so this issue is not absolutely critical.)

Add readReal and writeReal operations

Agreed. A readReal operation needs to be added to TextInputCjannel, and a writeReal operation needs to be added to TextOutputChannel. In addition, the discussion of the behavior of the write operation for TextOutputChannel should be updated to mention Real values.

This use of "new" is not defined or explained. It is not used in any of the normative references. Though I can guess what it means, it should be formally defined in for fUML to be a formal document.

If you are using "new" in some sort of Java way, the Java definition needs to be normative, or "new" needs to be defined explicitly.

Fix incorrect notation for unlimited natural values

The issue is referring to the notation new UnlimitedNatural(1) used as the default value for the attribute MultiplicityElement::upper in Figure 7.4 and new UnlimitedNatural(0) used as the default value for the attribute LiteralUnlimitedNatural::value in Figure 7.6. This is, indeed, not standard UML notation. The values should be changed to simply 1 and 0, respectively, in the two diagrams. (Note that the default values are already notated correctly in the class descriptions 7.2.2.2.22 MultiplicityElement and 7.2.2.2.21 LiteralUnlimitedNatural.)

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 StructuralFeature 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.

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.

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.

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.

The resolution to issue FUML12-35 renames the execution model class ClassifierBehaviorExecution to ClassifierBehaviorInvocationEventAccepter, removes the classifier behavior for this class and renames the "execute" operation to "invokeBehavior". The behavior of this operation is also supposed to change from including the starting of the classifier behavior (which no longer exists) to "register[ing] this event accepter with the object activation." However, the revised text of the resolution does not include the update to the code of invokeBehavior for this change (though the change is made in the code in the corresponding normative XMI).

Correct ClassifierBehaviorInvocationEventAccepter::invokeBehavior

Revise the text in the specification document to correspond to the update made in the code for this operation in the normative XMI.

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.

Correct dispatchNextEvent

The issue is indeed a serious bug that has lurked in the specification since version 1.0.

The RealValue::toString operation does not produce the correct result if the real value is equal to 1 or an exact power of 10. For example, when the value is 1, the result of the operation is 0.1E0, rather than the correct result of 0.1E1, and when the value is 10, the result is 0.1E1, rather than 0.1E2.

The problem is that the operation is specified so that, if the positive value is greater than 1, it is divided by 10 until it is less than or equal to 1. Instead, the test should be for the positive value being greater than or equal to 1, and division by 10 should continue until the value is less than and not equal to 1.

Correct RealValue::toString

Agreed.