Search code examples
c++uml

How to represent the nested class of C++ in UML?


How to represent the nested class of C++ in UML?

class A {
    class B {

    }
}

Solution

  • I had thought that the spec got away from the cross-and-circle notation. So, I did some wandering around in the specs, and couldn't find it in 2.0. I have to conclude that the 2.0 spec no longer supports it. While it's actually specified in v1.4, I looked all through the 2.4.1 spec, and it isn't anywhere to be seen (in fact, the word "anchor" returns 0 results in a document-wide search). I did some other looking around, and here's what I can piece together.

    First, I had always understood that nested classes were a means of implementing composition. Furthermore, UML attempts to be implementation-agnostic, and nested classes aren't. (You can create composition in other ways, and not all OO languages support nested classes.) Now, 1.4's explanation includes this:

    If Class B is attached to Class A by an “anchor” line with the “anchor” symbol on Class A, then Class B is declared within the Namespace of Class A. That is, the relationship between Class A and Class B is the namespace-ownedElement association.

    Ok. Now UML 2.0 says this:

    Kernel package represents the core modeling concepts of the UML, including classes, associations, and packages.

    Here is a diagram of the Kernel package:

    enter image description here

    That's pretty abstruse, but have a look at the NamedElement abstract class at the top left. (A "NamedElement" class is an element that has a name.) Notice that Namespace derives from it. Now, notice on the right, directly to the right of the top of the Namespace class, there's another NamedElement class. One of the associations has the {subsets ownedElement} property on it, and a composition diamond on the Namespace end. On the Namespace end, there is the {subsets owner} property.

    This means that NamedElement, when in composition association with Namespace, is a subset of Namespace. In other words, the relationship between Namespace and NamedElement is the namespace-ownedElement association described in the 1.4 spec. Therefore, the composition relationship, when adorned with the namespace and ownedElement properties, represents a nested (or inner, or internal, or whatever your favorite coding language calls it) class.

    So, I'm going to say that this is the accepted 2.0 way to show nested classes if you are using composition notation. Like this:

    enter image description here

    Now, another way is to stick the nested class inside the containing class. The notation examples in the spec don't show this AFAICS, but they show it with other NamedElements (packages, components, etc.) so I don't see why you can't.

    However, I don't see that the anchor notation is current. xmojmr's favorite site (and a good site, too), www.uml-diagrams.org, has this to say about it:

    Now obsolete UML 1.4.2 Specification defined nested class as a class declared within another class and belonging to the namespace of the declaring class. Relationship between those classes was called "namespace owned element association

    Nested classifier, e.g. nested class, nested interface, or nested use case could be used like any other classifier but only inside the containing class or interface.

    Per UML 1.4.2 a declaring (nesting) class and a nested class could be shown connected by a line, with an "anchor" icon on the end connected to the declaring class. An anchor icon is a cross inside a circle.

    UML 2.x specifications - including the recent UML 2.4.1 - describe nesting of classifiers within structured classes without providing explicit notation for the nesting. Note, that UML's 1.4 "anchor" notation is still used in one example in UML 2.4.x for packages as an "alternative membership notation" and without providing any other details or explanations.

    I couldn't find that "one example" diagram, so maybe it's still around. But at the very least, the notation seems to be deprecated. I would either use the properties, create a <<nested>> stereotype, or put the nested class inside the owner class.