What is a good way to understand the relationship between a UML class diagram and an implementation?

Question

At my uni the software design teachers like to ask questions about UML diagrams, such as this:

In the following class diagram, can class Bar’s bar() operation modify Bar’s b attribute? Can it modify class Foo’s a attribute?

Now as far as I know, static operations may only modify a class’s static attributes. Bar’s b is not static. Does this also apply to other classes’ attributes, such as Foo’s a?

But still, how about this?

class Bar {

        public static void bar()
        {
                var bar = new Bar();
                bar.b = something;
        }

}

It seems possible to implement bar() so that in its body it instantiates a Bar object and then modify its non-static attribute. The same could be done with instantiating a Foo and modifying its a.

---

I know I should differentiate between an example Java implementation and the ‘abstract’ UML diagram, but I can’t help but think of what makes sense and can be implemented while looking at these diagrams.

So what is an intuitive way to think about this? Is there anything that ‘prevents’ me from implementing the code I provided in the diagram?

Answer 1

The ambiguity is in the teacher's question not in UML.

The rules for static features are:

9.4.3.1: (...) The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true).

This means that bar() is a static operation that relates to the class Bar. whereas b is a non-static property that relates to an instance (object) of Bar.

The rules for visibility are different: they relate to a namespace, and not to classes or instances:

7.4.3.2: A NamedElement is an Element in a model that may have a name. The name may be used for identification of the NamedElement within Namespaces where its name is accessible. (...) The visibility of a NamedElement provides a means to constrain the usage of the Element, either in Namespaces or in access to the Element. It is intended for use in conjunction with import, generalization, and access mechanisms.

For classes, the kind of access mechanisms referred to above are defined as follows:

11.4.3.1: A Class cannot access private Features of another Class, or protected Features on another Class that is not its ancestor.

There is no constraint about accessing private elements of the classe's own namespace.

Conclusion: According to UML, the static bar() may not change the b property in general (since it's related to specific instances). But bar() may access and change the b property of any Bar instance it may know/discover, such as static Bar properties (e.g. as in a singleton pattern) or a a Bar object passed as parameter, or any Bar object bar() may access indirectly.

In addition, you need to keep in mind that UML does not force you to put all the possible features of a class in a diagram. The absence of a static Bar or a static Foo in the diagram, do not mean that these do not exist.

Finally, for a the principles are the same, since a is public: bar() cannot change the instance property a in general, but it can access/change specific the a of any instances it may know/discover.