UML25 — Redundant parameter specifications for Operation and Behavior

A Behavior can be defined in the context of a BehavioredClassifier where it must have a specification BehavioralFeature which defines its parameters and return value. A Behavior may also stand alone in order to represent procedural-based models in which case the Behavior specifies its own parameters and return result.

There is a constraint that specifies the parameters of a Behavior in the context of a BehavioredClassifier must match the parameters of its specification BehavioralFeature. However, parameter matching is not explicitly defined. Is it match in mode, name, type, multiplicity, constraints, etc., or just type?

A better solution would be to disallow behavior parameters if the behavior has a specification. This would eliminate the need to redundantly specify the parameters for a behavior if it has a specification, and then enforce a constraint to have them match.

Specifically:

1. section 13.3.3, remove constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature.

2. add a new (second) constraint: [2] A Behavior with a specification BehavioralFeature obtains its parameters from the BehavioralFeature and cannot specify its own parameters.

3. add a new constraint: [3] A Behavior with a specification BehavioralFeature cannot have any redefinedBehaviors. The redefinitions come from the BehavioralFeature.

Discussion
The UML 2.5 specification is clear now (in 13.2.3, under “Behavioral Features and Methods”) that how the
parameters of a method are matched to its specifying behavioral feature is intentionally not formalized, in
order to allow for different possible approaches to this in different user models.
Disposition: Closed - No Change