UMLR — problems with BehavioralFeature::method

We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs.

The UML metamodel problems:

1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible).
2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible)
3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable.

Clarifications and possible spec corrections are highly appreciated.

UML 2.5 beta spec says:

 method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior).

 specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier.

Proposed changes:
1. Don't constrain where behavior must be owned to implement operation.
2. Let the same behavior be a method of more than one Operation.
3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived.
4. Allow one method only and use redefining Operations instead.