UML22 — UML2: No notation for BehavioredClassifier::ownedTrigger

UML2 provides a number of different ways to initiatiate execution of some behavior, and for specifying what behaviors are offered for invocation. Behaviors provide a realization of these specifications.

The simplest is a BehavioredClassifier can respond to invocations of its ownedBehaviors through a CallOperationAction. The ownedBehavior is a method of a specification Operation which defines the client interface, external view, signature, contract (whatever one likes to call it) of the behavior.

If the ownedBehavior is an Activity, then the activity may contain any number of AcceptEventAction or AcceptCallAction/ReplyAction actions to enable the activity to control when and how additional behavior may be invoked by clients in the context of some broader, perhaps long-running activity. Both AcceptEventAction and AcceptCallAction have trigger: Triger properties whose event: Event could be a SignalEvent or CallEvent respectively. A BehavioredClassifier should indicate to clients its ability to receive the corresponding SignalEvent or CallEvent by including an ownedTrigger designating the event it is prepared to receive.

However, there is no notation specified for BehavioredClassifier::ownedTrigger. In addition, there are other ways to specify the ability to receive signal and/or call events that may make ownedTrigger redundant. The ability to receive a SignalEvent can be denoted by an ownedReception: Reception in a Class. The notation for an ownedReception is a <<signal>> Operation where the operation name is the Signal name, and the in parameters provide the values for the signal's ownedAttributes. There can be no inout, out, or return parameters, and no raisedExceptions. An ownedOperation is all that is needed to indicate the ability to receive a CallEvent.

The metamodel for ownedTrigger needs to be reconciled with ownedOperation and ownedReception. Perhaps the notation should provide a way to distinguish operations that invoke behaviors and operations that indicate the ability to respond to call events as <<trigger>> operations.

Discussion: A classifier declares its “willingness” to handle events by its behavioral features. Currently there are two such features: Operations and Receptions. The former declares that the classifier will handle call events, the latter that the classifier handles signal events. These are the only kinds of events that can be caused by other objects. The issue requests another mechanism to accomplish the same thing without explaining why a second mechanism is required to accomplish what behavioral features already accomplishing. Disposition: Closed, no change