FUML13 — Stand-alone owned behavior of BehavioredClassifier shall be possible

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.