CODEWITHSUNDEEP
classinheritancecastingumlprogramming-languages
Samuel
Samuel

Reputation: 686

Object-languages misdescribed by UML?

I've read that UML assumes by default that :

  1. a class can inherit several others
  2. an object is an instance of only one class
  3. an object of a given class cannot change to another class

This leads me to the question : as there are 3 hypothesis, there are 2^3 possible combinations. Could you give me languages which would be examples of each of them ?

I mean for me Java is "false-true-true" and C++ is "true-true-true". What about the 6 others ? Or did I misinterpret the assumptions ?

Upvotes: 1

Views: 43

Answers (1)

Christophe
Christophe

Reputation: 73376

Let's look at the UML 2.5 standard of the OMG, to have a definitive answer:

1.Class inheritance

The UML 2.5 standard clearly defines that a class can have none or several superclasses and, that conversely, a class can be superclass of none or several classes (see section 11.4.2 and 11.8.3.6).

So UML definitively allows multiple inheritance (as in C++ or Python). But you may as well restrict yourself and use only single inheritance and several interface implementations, like in Java and C#. You'd use a realization relationship to show the "inheritance" from an abstract interface (the inheritance arrow is then dotted).

2. Objects and classes

9.8.1: InstanceSpecifications represent instances of Classifiers in a modeled system. They are often used to model example configurations of instances.

FYI: the terms used in the standard are a little more general, but an object is an instance, and a class a classifier. This definition is then further refined in the semantcs in chapter 9.8.3 :

The InstanceSpecification may represent:
• Classification of the instance by one or more Classifiers, any of which may be abstract.

So UML allows objects to be an instantiation of several classes. I don't know languages that allow this, but if you do don't hesitate to comment ;-).

3. Changing class of object

I must admit that I can't answer this answer 100%. I don't think so, because, becoming an instance of another class would mean to re-insantiate a class, so it's not corresponding anymore to the definition of an instantiation.
Furthermore (see 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.

This is somewhat ambiguous: a given object in a given diagram can't change classes. However, you can represent several times the object in different diagrams (snapshot) to show a change.

Conclusions

So your assumption 1 is true, 2 is false, and 3 true or false depending if you're reasoning at diagram or model level.

Upvotes: 1

Related Questions