Regarding generalization and classification in UML

Question

Currently I am reading UML Distilled - Third Edition (Martin Fowler) to catch up some new thoughts and spot interesting things I am not yet aware of.

On of those things I came up is the differentiation between generalization and classification.

In Chapter 5 - Class Diagrams: Advanced Concepts, Martin Fowler wrote at the end of the section Classification and Generalization on page 76: "The UML uses the generalization symbol to show generalization. If you need to show classification, use a dependency with the ‹‹instantiate›› keyword".

Nevertheless, figure 5.11 from the following section (Multiple and Dynamic Classification) depicts "generalization sets" with generalization arrowheads, including an additional "discriminator" (generalization set name) per set.

It also states at the end of the continued paragraph on page 77: "Single classification corresponds to a single generalization set with no name".

I am a bit confused now. First, it is told that one shall use a "dependency with the ‹‹instantiate›› keyword" for classification but then for "multiple classifications" one is supposed to use "generalization arrowheads" but with an additional "discriminator". So far, so good. Since single and multiple classification are two different things, I can follow the distinction from "general generalizations" because of the discriminator.

But "single classification" would then look like a "normal" generalization because the "set name" is to be omitted?! It sounds somehow contradictory to the very first statement about the "dependency relation and the ‹‹instantiate›› keyword" to me.

May someone could please clarify and explain this to me, ideally with some sort of an example?

Kind regards Chilippso

--edit--

I have read the sections in question again and I think I have a better idea now, what it is about. I think, either this is related somehow to the meta-model itself or it is about object diagrams, since section Multiple and Dynamic Classification starts with: "Classification refers to the relationship between an object and its type".

So, if I have to classify a class itself, then the classifying class have to be a metaclass for it's objects to be classes themselves. Or I am classifying an object - but then this topic is more related to object models in my naive view of things.

Is this assumptation correct? It would also match the note on the meaning of the ‹‹instantiate›› Dependency-Keyword from Tabel 3.1 on page 48: "Note that if the source is a class, the class itself is an instance of the class class; that is, the target class is a metaclass".

Answer 1

I think what you wrote in the edit is more or less correct.

The section you ask about starts with a discussion of what's actually meant by "is-a"; there's a number of subtleties there that are often missed. The motivating example given is:

1. Shep is a Border Collie.
2. A Border Collie is a Dog.
3. Dogs are Animals.
4. A Border Collie is a Breed.
5. Dog is a Species.

And then you are asked to consider how these can be combined, and which relationships are transitive and which are not. Shep (a concrete dog) is-a Border Collie; Border Collie is-a Breed; but Shep is not a Breed. So, there's a qualitative difference hidden behind the vague notion of "is-a".

---

Aside: another subtlety which is often missed is that every taxonomy ("placing things into groups") is done based on some classification criterion, and that these criteria from arbitrary domains don't necessarily translate directly into the domain of a type system. This is the root cause of the Circle-Ellipse problem (the criterion under which a circle "is-an" ellipse in mathematics generally may have nothing to do with criteria that make a derived class an LSP-compatible subtype).

---

One could model the relationships above like in the image below (I turned << instantiate >> into << instance of >>). Note that this is not the one true way to do it; the model might look slightly different depending on the domain.

Regarding the qualitative difference - if you think of these classes as of sets, then "Border Collie" is a set of all individual dogs that belong to that breed, and "Dog" is a superset of "Border Collie"; the "Dog" set also contains as elements individual dogs, it just has all the "Border Collie" dogs + a whole extra bunch (around 900 million elements, which is the estimated number of dogs in the wold according to Wikipedia). The "Breed" set, however, is not a set of individual dogs; its elements are the breeds themselves (which happen to be sets in their own right). So "Breed" has 200-360 elements (depending on who you ask).

Now, in the section about multiple classification, all of the things depicted in the book are classes (or types, if you like) which belong to some generalization hierarchy. The instances themselves are omitted, which is what I think confused you. The idea is that a single instance can be placed into multiple independent categories (classes, types) simultaneously. Another way to say it is that you can assign multiple independent labels to an instance. Here's a slightly modified diagram from the book, augmented with a couple of example instances - I think that'll make the concept clearer:

E.g. imagine a scenario where John is a staff member, a male nurse who happens to also be a patient, and is treated by Jane, who is a doctor (the doctor-patient relationship between Jane and John is not depicted). In multiple inheritance, an instance is always simultaneously an instance of all inherited classes. In multiple classification, an object doesn't have to be an instance of all the available classes (it's more freely combinatorial in nature; e.g. a patient doesn't have to be, and usually isn't, a staff member - and thus, from a programmers perspective, has no behaviors associated with being a staff member).

Note that this is mostly intended for conceptual modeling (understanding the relationships between various aspects of the domain, communicating with domain experts, etc.); this is generally not something that'll translate 1-to-1 to how you'd implement these relationships in actual code (e.g., you might encode something like this via data & behavior, rather than via the type system).

I'm under the impression that this type of diagram is not used that often by people, so if you run into a scenario where doing something like this might be beneficial in the conceptual phase, you'll probably have to explain the semantics of it to your audience (team members, stakeholders) along the way.

Answer 2

Thinking in classes?

We often use class diagrams with the intent to design classes and class hierarchies. In that diagram for example:

• the class Patient is a specialization of the class Person (or Person is a generalization of Patient).
• the class Doctor can be specialized into either Surgeon or Family Doctor
• you could also have multiple inheritance if you'd not be afraid of implementation challenges. But this diagram has no example of it.

We often do this with a class-based OOP bias, i.e. with a focus on programming languages where you first decide on the type and then instantiate objects belonging to a single type. And this fig.5.11 model is not very helpful in that perspective, since it would not allow a person to be at the same time Male and Patient.

Or thinking in objects?

But UML is agnostic in this regard. It is as suitable for prototype based programming as it is for class based programming. And this counter-intuitive reality makes the classification principle difficult to understand.

As you pointed out in your edit, classification is not about choosing a class and instantiating it, but about having instances that has features (attributes, behaviors) that make it belong to classes.

With this in mind, you'd read the diagram differently. So the same object, e.g.

{ name: "Elizabeth Blackwell", 
  sex:  "Female",
  born: "1821-02-03",
  died: "1910-05-31",
  occupation: "Physician"
  title: "Dr.Med." }

could belong to the classes Female, Person and Doctor at the same time. This is btw why UML has half a page about generalization set constraints (e.g. are the specializations in the set complete according to a discriminator, or incomplete? Are the classes in the generalization set disjoint, or may they overlap?)

Thinking dynamic

Another point is that object attributes and behaviors may change over time. So a student could be only a Person when the object is created, but later acquire new skills and professional qualifications via attributes and behaviors, and could be classified as Person and Doctor.

Note that this is very different from class-based thinking where an object keeps the same class from its construction to its destruction. If you have any doubt about this, you may read this language-lawyer question on StackOverflow: Can the class of an object change in UML; the answers provide precise quotes from the UML 2.51. specifications.