Can the class of an object change in UML?

Question

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?

Oblivious

Even interpreter langauges do not allow for objects to be turncloaks. You decide them to be something on birth and they keep being that. What would be the sense in turning an object of type Fruit into Car? None, I guess. Think of what such a change would have in consequences. Different attributes and operations. That would just be insane. I'll try to foster the UML spec, but right from my stomach that's just bullshit. P.S. Object is the term from UML 1.5. Now that's an InstanceSpecification. – Decedent

Keep in mind that an InstanceSpecification is not an instance. – Microsporophyll

Some classes are necessarily rigid, others are anti-rigid and contingent. Once a person, always a person; once an employee, later unemployed. UML classes don’t have a way to tell them apart. – Microsporophyll

@JimL. Employment is the association to an employer, not any class change. Modeling this via inheritance? What was it: prefer composition over inheritance? – Decedent

I agree. I didn’t say employment. An employment is the mediation of a person in the role of employee and a company in the role of employer. – Microsporophyll

You may be interested to check out OntoUML for a useful formal theory. – Microsporophyll

@Decedent indeed, I am glad to see that i am not the only one thinking like that. The change of class is something that I have troubles to conceive. However some language lawyers around there have put this assumption in question, and Jim has a point. The other question was about users specialized in new users and returning users, and one could imagine a transition from the one to the other. Let's see the answers ;-) – Oblivious

@JimL. I had a short look (it would take me too far into te philosopical corner, I guess). Indeed this is interesting and I might delve deeper when winter comes. However, I think that UML has become more "rigid" by abandoning the term Object and using InstanceSpecification instead. An object can be anything it is classified with (hence the possibility to change). But only in this frame it's allowed to change. It can not change arbitrarily into "something". – Decedent

@Oblivious Hopefully some of the gurus will provide their point of view (not saying that this is opinion based ;-) – Decedent

Answer 1

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.

Duna

Thank you for this very interesting contribution and references, which answers a couple of concerns that I raised on qwerty_so’s answer. Very helpful. About the introductory real world example however, I’d provocatively pretend that objects do not change class: it’s the same person having different (and not mutually exclusive) social roles ;-) – Oblivious

@Oblivious Yes, they are not mutually exclusive, therefore multiple classification is needed. I agree that this situation would better be modeled with the actor-role-pattern. However, how about a person progressing from baby via child and teenager to adult. It's not just a role and it changes the invariants. – Duna

Still the same person, just different states with different behaviors ;-) But I got your point. Thanks for your patience – Oblivious

@Axel Nailed it. Saved me from having to write an answer. – Microsporophyll

Answer 2

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.

Decedent

Indeed. Maybe you could also add 9.8.3: "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" - So an instance may represent a User, and at a moment in time it is represented by an instance specification of one class New user, and after at a later stage be represented by an instance specification of Returning user. Of course, this raises some ambiguity if each class would have a constructor or a destructor or properties with default values. – Oblivious

@Oblivious I'm still no friend of multiple inheritance since that brings up all these questions... – Decedent

I agree that multiple inheritance is not always easy. But the problem here is not so much multiple inheritance (it's relatively easy to imagine an instance belonging to several distinct classes, and complying to all their constraints at one), but the fact that the classes of an instance can change over time. THey may keep properties of the old class and get properties of the new: is it then multiple inheritance with old and new class ? If not, how to get rid of old properties that are no longer relevant? The classification is then more pattern matching than structuring imho... – Oblivious

@Oblivious That's what they say also in 9.8.3: The purpose of an InstanceSpecification is to show what is of interest about the instance. The instance conforms to each classifier of the InstanceSpecification, and has properties with values indicated by each slot of the InstanceSpecification. Having no slot in an InstanceSpecification for some properties does not mean that the represented instance does not have the property, but merely that the property is not of interest in the model. You don't get rid of the old properties. They are just not important then. – Decedent

Wow ! That sounds like strong decidability : "then it behaves like this because everything it did before is no longer 'of interest'". (Still under shock, in need to assimilate this new knowledge) ;-) – Oblivious