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?

UML class diagram

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?

  • You are right, in most languages, static methods can access instance fields when they are provided with an instance - it's not uncommon to see static methods that take an instance of the class as a parameter. Often these are "utility" methods of some sort. Now, the problem with ad hoc university questions is that they are looking to test your understanding of some specific thing you were taught earlier, so the answer your teachers are looking for is likely more specific then you realize, but as you're not sure what they are after, you're thinking more broadly. This is not a bad thing. 1/2 Dec 28, 2020 at 18:15
  • 1
    The advantage of a uni is that you can interact with your teachers. Don't wait for a test later on - ask them clarifying questions before that (either fire a question right back, or think about it for some time, then ask in a subsequent session). This will (1) help you understand what they are looking for, (2) help deepen your understanding of the material, and (3) let them see that you're trying to understand this stuff, and help them clear any misconceptions that you or other students might have. And also (4) help them realize that there are unstated assumptions in their questions. 2/3 Dec 28, 2020 at 18:15
  • 1
    For example, as I understand UML, this dashed line with a regular arrowhead represents a generalized dependency of an unspecified nature (it could be that Bar inherits from Foo, or that it has a reference to Foo, or that a method in Bar creates internally an instance of Foo). But I can't be sure if that's what they meant, or if they were a bit loose with the notation. So I would ask them about that. They would say something back, we'd have a short discussion, and come to a mutual understanding. Do that. 3/3 Dec 28, 2020 at 18:15
  • P.S. About the relationship between the UML and implementation: The key takeaway is that when you have two elements connected with an arrow, that means, in the abstract, that one object depends on the other (e.g., the code in one object mentions the type/methods of the other object), with the direction of the arrow indicating the direction of the dependency. (Composition and aggregation connectors typically don't have an arrow at the other end, but are unidirectional by definition). Dec 28, 2020 at 18:23
  • @FilipMilovanović Fair enough, I shall ask the teacher to clarify.
    – bp99
    Dec 29, 2020 at 11:59

1 Answer 1


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

The rules for static features are: (...) 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: 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: 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.

  • Thank you for the through explanation! What I am wondering now is what you mean exactly by ‘changing a property in general.’ Do you mean that for example Bar may only change the b property if it’s a property of a Bar instance it knows? Also, if Foo’s a were also static, would bar() then be able to change it? I would think so.
    – bp99
    Dec 29, 2020 at 12:06
  • 1
    @bp99 exactly! only if it knows the instance. If foo‘s a would be static, it would still be visible (+), and bar() could access it/change it, even without knowing any specific instance.
    – Christophe
    Dec 29, 2020 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.