UML25 — Package merge on Class metatype causes semantic issues - particularly with state machine context

I recently wrote a code generator for my UML tool for state machines. One of the properties of a state machine is called /context, which is the Class that has the state machine as its Classifier Behavior (if any exists). When I created a submachine state, the /context field of the state machine inside the submachine state was listing the parent state machine as its /context, rather than the class owning the parent state machine. This does not make semantic sense, because the purpose of the context field is the allow the state machine to have access to the methods and data of the class that implements the state machine behavior.

The UML spec says that to find the /context of a state machine, you must travel up the Owner tree until you hit the first Behaviored Classifier. My UML tool vendor pointed out to me that a State Machine is classified as a behaviored Classifier so it qualifies. That did not make sense to me because a State Machine is classified as a Behavior. How can a Behavior also be a class that owns a behavior?

After checking the UML spec further, I discovered that a Behavior, and therefore a State Machine, is derived from Class (Kernel), which is not a Behaviored Classifier. However, after all the packages are merged, Class (Kernel) gets merged with Class (Communications), which is a Behaviored Classifier, and the merge rules allow the class
hierarchy to be merged together. I confirmed this anomaly was present in the merged XMI files at OMG website.

I believe this problem is unique to Class metatype. If you look at Annex F of the UML spec, it shows the complex class hierarchy associated with Classifiers from various packages prior to merging. There are three merge increments for Class in three different places on the tree. These are even called out explicitly in the diagram. You
can see how the inheritance tree would be changed dramatically when these three Class increments are merged together. All other cases where the metatype increments are merged do not change the structure
of the inheritance tree. The Class metatype is unique in this respect.

I thought about a solution and I believe there is an easy fix to this problem. It requires replacing the Class (Communicatoins) increment with a new metatype called BehavioredClass, and replacing the Class (StructuredClasses) increment with the already existing
EncapsulatedClassifier. After this change, a BehavioredClass would be both a Class (Kernel) and a BehavioredClassifier, as is already illustrated in 13.3.8 but would now be more intuitive. Component would now inherit from Class (Kernel) and EncapsulatedClassifier (Ports). Node would inherit directly from EncapsulatedClassifier, thus preserving the pre-merge idea that Node's should not have data and methods associated with them (as with Class (Kernel)). This is another currently odd outcome of merging the packages together.

Because Class (Kernel) is a concrete metatype (and therefore shows up in modeling tools), you would need to make BehavioredClass concrete also. Modelers would have to expose it and I think this would be an improvement. I've always felt that active classes (like OS tasks) and
non-active classes (data and methods only) are such distinct object types that they should have separate representations. The elimination of the Class (StructuredClasses) increment would also prevent the
merge from adding ports to the generic concept of a Class, which is also desirable since ports are not useful without the ability to represent internal structure.

After that modification, there are other modifications that would naturally follow. The one I can see is that the isActive attribute of Class would now be a derived attribute which is set to true for classes that inherit BehavioredClass and false otherwise. With this change, in the fully merged UML package, a StateMachine would be derived from Class with only the Kernel attributes. It would no longer falsely inherit from BehavioredClassifier. A whole bunch of other inherited properties that make no sense would also go away.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change