ALF11 — Instance creation should start classifier behaviors of parent classes

In 8.3.12 Instance Creation Expression, it states that "if the class of the object being created is active, then the classifier behavior for that class is automatically started once the object is created and after any constructor call completes." In 17.12, this is mapped to a start object behavior action.

However, if the class of the object being created is a specialization, then, as stated, only a classifier behavior owned by that class (if any) will be started, not any classifier behaviors that may be owned by parent classes and inherited by the specialization. It is possible in fUML to start such parent classifier behaviors, by using a start object behavior action with an object input pin typed by the parent class. But there is no way to express this in Alf, meaning that the active behaviors of parent classes are essentially lost in any specializations.

It would seem better to update the Alf semantics for instance creation so that, in addition starting any classifier behavior owned by the class of an object being created, any classifier behaviors owned by any parent classes are also started.

Start parent classifier behaviors

In addition to what is mentioned in the issue, the Alf 1.0.1 specification also states in 10.4.3 Active Classes that "The classifier behavior of an active class is specified as an activity that is a private owned behavior of the class". However, it says a little later that "an instance of an active class with active superclasses will have the behavior specified for all its superclasses, as well as any behavior specified for the subclass". This latter statement is not supported by the current semantics and mapping of the instantiation of active classes as given 8.3.2 and 17.12, so there is a specification inconsistency that needs to be resolved.

It is generally expected that the behavior of a subclass is a specialization of the behavior of its superclass(es). Thus, when an active class is a subclass of another active class, the active behavior specified for the subclass should include the behavior specified for the superclass – this is the intent of the statement made in 10.4.3. However, if only the subclass classifier behavior is started, this will not be the case. Instead, the active behavior of the subclass would essentially replace the behavior of the superclass.

Consider, for example, an active class that defines and responds to a certain set of signals. Since a subclass of of this class inherits the public receptions from its superclass, an instance of the subclass can also receive any of the signals defined for the superclass. However, if the superclass classifier behavior is not started, then the subclass will not automatically provide any response to these signals. The behavior specified in the superclass would have to be specified again in any subclass, even if it was to be unchanged, and then specified again in any further levels of subclassing. This seems untenable, leading to the conclusion that the classifier behaviors of the superclasses of an active object should also be started when the object is created.

Now, a more elegant solution would be to have the classifier behavior of a subclass redefine the classifier behavior of its superclass, so behavior could be incrementally added in the subclass without having to re-specify the behavior defined in the superclass. However, the semantics of the redefinition of activities is only loosely defined in UML and, as of fUML 1.2.1, behavior redefinition is not allowed at all in fUML.

Nevertheless, the Precise Semantics of UML State Machines (PSSM) specification (in preparation at the time of the writing of this resolution) is expected to include semantics for the redefinition (a.k.a. extension) of state machines. While state machines are not included in the Alf language, it should be possible to use Alf notation to create an instance of an externally defined class with a state machine as its classifier behavior, possibly redefining a state machine that is a superclass classifier behavior. In this case, the redefining state machine in the subclass already includes the behavior of the redefined state machine in the superclass, so only the subclass state machine should be started.

With all this in mind, the proposal is to resolve this issue as follows: update the Alf semantics for instance creation so that, in addition to starting any classifier behavior owned by the class of the object being created, all classifier behaviors owned by any parent classes are also started except for classifier behaviors that are redefined by other parent-owned classifier behaviors.