In short

Mainstream class-based OO languages do not allow the class of an object to change after creation. I assumed the same constraint in UML, based inter alia on the following clauses in the UML 2.5 specification:

7.5.1: Types and multiplicity are used in the declaration of Elements that contain values, in order to constrain the kind and number of values that may be contained.

9.2.3.2: An instance of a Classifier is also an (indirect) instance of each of its generalizations.

However, in the comments to this answer, several highly skilled UML experts questioned this assumption. Therefore my question: can instances change class in UML? What clauses in the UML specs would allow such a change?

Additional arguments

While I couldn't find any firmer claus in the UML specs about the relation between instances and classes, I interpreted the following hints to support the fixed class:

11.4.3.1: (...) An active object is an object that, as a direct consequence of its creation, commences to execute its classifierBehavior, and does not cease until either the complete Behavior is executed or the object is terminated by some external object.

(It's specific for active objects. But if the object could change class after its creation, it could not be active anymore, or it would keep the old behavior with the new class, which seems weird):

In addition there are multiple clauses that would lead to ambiguity, if the class of the instance could change dynamically. For example in 6.5.1:

A class may also have invariant conditions that must be true before and after the execution of the operation but may be violated during the course of the execution of the operation method.

What happens if the invariant is no longer true during an operation on a classifier instance: does the instance just looses its quality of instance of the class? COuld it be an instance not related to any class at all?

The semantics of properties specify that, when a property with a default value is instantiated, in the absence of some specific setting for the property, the default value is evaluated to provide the initial values of the property

If an instance would no longer be an instance of one class with a default value, would it suddenly get the default of another class it could be instance of? Or if an instance could match two similar classes: would it get the defautl value of both?

CodePudding user response：

I might have found the section which bothers you, and basically that's where multiple inheritance comes into play (it's evil for sure).

9.9.9 InstanceSpecification [Class]

9.9.9.1 Description

An InstanceSpecification is a model element that represents an instance in a modeled system. An InstanceSpecification can act as a DeploymentTarget in a Deployment relationship, in the case that it represents an instance of a Node. It can also act as a DeployedArtifact, if it represents an instance of an Artifact.

[...]

9.9.9.5 Association Ends

• classifier : Classifier [0..*] (opposite A_classifier_instanceSpecification::instanceSpecification) The Classifier or Classifiers of the represented instance. If multiple Classifiers are specified, the instance is classified by all of them.

There you are: multiple classification. So the InstanceSpecification (object) is indeed something like a turncloak and can take more than one form.

Additionaly the spec says:

9.8 Instances

9.8.3. Semantics

[...]

An InstanceSpecification may represent an instance at a point in time (a snapshot). Changes to the instance may be modeled using multiple InstanceSpecification, one for each snapshot.

It is important to keep in mind that InstanceSpecification is a model element and should not be confused with the instance that it is modeling. [...]

Using an InstanceSpecification will show the representation of an object in time. As shown above this can change in the limits of its classifications.

CodePudding user response：

Objects can change their class. At least in the real world, this is obvious. A Student could become a ResearchAssistent and maybe even a Professor. A Car could become after some time a ClassicCar. The UML does support this:

16.4.3.7 Reclassify Object Actions A ReclassifyObjectAction is an Action that changes which Classifiers classify the object given on its object InputPin. It may both add and remove Classifiers from the object. Multiple Classifiers may be added and removed at one time. [...] The identity of the input object is preserved, no behaviors are executed, and no default value expressions are evaluated. The newClassifiers replace existing classifiers in an atomic step, so that structural feature values and links are not lost during the reclassification when the oldClassifiers and newClassifiers have structural features and associations in common.

Whether a reclassification makes sense, is not the question. Use it, when it makes sense for you. Of course, you can model nonsense.

It goes without saying, that all new Class invariants must be fulfilled after changing the class. If the new invariant involves features of the old class, there could be a problem when the new invariant would not be fulfilled with the old values. They would have to be updated at the same time by the behavior that changes the class.

Default values are not a problem here. The behavior of the class is responsible for making sure the default value is set, it's not automatic. And if you change the class, the values of the features that still exist in the new class are taken over unchanged.

When you reclassify from an active class to a passive class, well then the classifier behavior simply stops. I doubt that this case would be useful, though.

PS: As has been said above, InstanceSpecifications specify objects as instances of some classifiers, they are not the objects. Therefore, I think whatever the specification says about them is not relevant for our discussion.