UML25 — UML 2 Super/Interactions/notation for accessing a static feature

Context:

Invoking static or class methods on classes is incredibly common. If you look at a typical Java or .NET app (or the libraries themselves), or even Smalltalk, between 5-10% of the calls are class method calls. If you reverse engineer any Java or C# code to a sequence diagram, one should be able to see what’s a class method call on class X, versus instance calls. When you creatively draw an interaction diagram, the reader (a human or tool) should be able to know when something is a static call on a class.

There are literally thousands of class methods in the Java and .NET core libraries. Any significant java app makes thousands of calls to these many library class methods, in addition to hundreds or thousands of calls to app-defined class methods.

Problem:

This is basic stuff, but the interaction diagram notation is not clear on how to show this. Tool vendors need a solution ASAP; many are in beta, and want to know the “correct” way asap, during rev eng of java code to a seq dgm, to show such calls. E.g., given the basic java code that i show in the attached example picture, how to rev eng the code to a seq dgm.
And my book, that teaches intro OOA/D, has to show the solution – i’ve got an aug 30 publishing deadline.

UML 1 had a way to solve this in interaction diagrams, with underlined/not underlined labels in the boxes, where not underlined indicated it was a class, and thus a class method call. But of course, that convention doesn’t work with UML 2 lifeline boxes.

The problem can probably be solved with the appropriate label in a lifeline box, and ensuring that the context composite structure diagram relates appropriately.

Solution:

I’ve asked this question to Jim Rumbuagh, who gave a “convention” solution i very much like, for the lifeline box label: “ClassName : Class ”

e.g. “Font : Class”, “Collections : Class” or perhaps “Font : Type” if reverse engineering from C#.

e.g.., going meta and viewing the class as an instance of class Class.

In Java and Smalltalk (for example) all classes are indeed instances of class Class. In .NET, they are instances of class Type.

Then the lifeline box still represents an instance (of class Class or Type or whatever), and the “class messages” are still instance messages.

I attach a diagram that gives a sequence diagram example.

And–and i consider this important–the solution should be obviously understandable and straightforward to a novice, as is Jim’s. It corresponds to an OO programmer’s mental model. I encourage the committee members to choose a solution that is simple and obvious, that maps straightforward to the language most OO developers are working in – Java or C#, not an obscure solution.

An outstanding problem, with bigger ramifications, is the names “Font” and “Class” in the related context diagram. Where are they defined? Of course, most of these classes will be from the core Java or .NET libraries (each have about 20,000 classes). I propose being able to declare a convention something like “assume that in this composite structure diagram there is an implicit import of the classes needed from the java libraries (or other libraries).”

Well, some convention like that is needed in any event, because we are frequently calling instance methods on instances of java library classes – in a typical java app, 30-50% of the calls are to objects from the library. You can’t expect (because it would be too fussy/awkward/unusable) a UML modeler working in Java to re-create or have to explicit import specific parts of the Java libraries (or various common 3rd party libraries) every time they want to refer to library objects – which is frequently.

i attach a picture to illustrate.

The issue here is to be able to describe calls on static methods.
Static Operations are defined on Types, with the property “isStatic” declared as true.
It needs to be clarified, that every connectable element can receive messages with signatures associated with
its static operations.