Names of Model Elements in UML 2.1 Models

Browsing the UML 2.1 specification we find that most of the different kinds of model elements that make up UML are examples of a construct call NamedElement. In other words, the meta-classes of most of the model elements defined in the UML specification are specialisations of the NamedElement meta-class.

To Name or Not

The description for the NamedElement class starts with the following sentence, "A named element is an element in a model that may have a name".Closer examine of the UML 2.1 specification indeed reveals that NamedElements have a variable length character string attribute with a multiplicity of 0..1 meaning that it may or may not have a value. Immediately,part of me is objecting to this. Surely something called a named element must have name, not may have a name. Something that may have a name is nameable not named. I am named Steve. This does not mean I may have a name. It means I do have a name.

This apparently innocuous abuse of the English language raises some interesting questions for UML modelling tool designers. As well as diagrams, most UML modelling tools have some sort of tree view that shows the package hierarchy of a model and the contents of each package. For example, Borland's Together 2007 has a Model Navigator view as shown in figure 1.

Together's Model Navigator view
Figure 1: Borland Together 2007's Model Navigator view

If model elements do not have a name, we could in theory have a significant portion of the view with blank names. If there are a  number of elements of the same type without names we can end up with sets of items in views like the Model Navigator that are indistinguishable to users. The same situation can occur in views, reports, and documents generated by features such as automated audits, metrics, searches, and documentation generation. Not only do we have problems distinguishing between these nameless model elements in these situations, we also have problems when trying to refer to these nameless elements if we are discussing the model with colleagues, especially if those colleagues are on the other end of a phone or in some sort of internet-based meeting?

The best we can often do in such a situation is to use the relative position of an item. For example, "The action after the third decision element" (see figures 2 and 3).

Blank names in a diagram
Figure 2: Blank names in a diagram

Blank names in a navigation view
Figure 3: Blank names in a navigation view

A better solution might be for the tool to generate a placeholder name consisting of the type of the element followed by a sequence number, e.g. action001, action002, use case001, use case002, etc. However, in doing this we are essentially naming those elements. Together 2007 does this. It requires that every UML model element have a name and generates an initial value for that name. In doing this it is non-compliant with the UML 2.1 specification but personally I prefer Together's approach. Unfortunately, it does mean that importing a model using XMI, the OMG standard model interchange format, and then immediately exporting it to XMI can result in an output file that does not match the input file when it really should. This is because any unnamed elements in the input file will be given a name by Together that will end up in the exported file. Ideally Together would have user selectable options so that a user can choose to be compliant with the specification or compliant with common sense where the two occasionally diverge.

In my opinion, UML 2.1's NamedElement should work as the name suggests and have a name, even if that name is a generated or derived name to start with. Of course, we do not want names cluttering diagrams where they add little value but the displaying of an element's name should be a matter of choice by the modeller and completely independent of the debate about whether an element must have a name or not.

Mandatory Names Not Enough

Unfortunately, just making names mandatory is not enough and also, unfortunately, this is readily demonstrated by Together 2007. In many cases Together 2007 allows the name of an UML model element to be a string of purely whitespace characters. This is effectively as bad as allowing the name to be 'null' or empty.  Allowing elements to have just whitespace as a name means that we can still end up with nothing a human can use to precisely reference those elements other than their physical location on a diagram or in a list.

In many cases Together 2007 also allows an element's name to be non-unique within their type within their package or containing model element. For example, although it is usually easy enough in most UML modelling tools to distinguish between a component called X and a class call X in the same package, it is not nearly so easy to distinguish between two use cases both called Y in the same package. Not enforcing uniqueness of names of model elements of the same type within a package or containing model element means duplicate names appear in lists of elements and generated documents. This leaves open a big opportunity for ambiguity when referring to elements and possible mis-communication.

Non-unique names in a diagram
Figure 4: Non-unique names in a diagram

In the defense of Together, users can use the Object Constraint Language (OCL) to specify additional checks for a model (the excellent 'model audits' feature) that can be used to flag names consisting of only whitespace characters or names that are not unique within the required context. However, these must be invoked either manually or as part of  a regular, frequent or continuous integration process to be effective.

For these reasons, I believe the UML specification should insist that:

  1. the name of an element be required,  
  2. the name of an element should not be allowed to be the empty string or comprise of only whitespace characters,
  3. the name of an element should be unique within its type and package or immediate namespace,

I also believe that UML modelling tools should

  1. generate initial values for model element names
  2. provide the option to hide an element's name on a diagram 

Of course, where the name of an element is hidden on a particular diagram , there is nothing to stop a tool revealing the name in a tool tip when the mouse cursor.hovers over the element. Alternatively or additionally, the name could be revealed in a status bar located at the edge of the diagram's or modelling tool's window.  This sort of feature would allow the element to be readily identified and precisely distinguished from others by users of the modelling tool in every context in which it appears.

Short and Long Names

Most people do not use my full name when referring to me. If they are trying to sell me something they might call me Mr. Palmer. Friends, family and colleagues simply call me Steve. No-one regularly refers to me as Stephen Richard Palmer but that is the name on my birth certificate.

Similarly, it is very common in many organizations, projects, or software development teams to have both a short name and a longer, fuller name for a UML package, model element or diagram. 

The UML 2.1 specification in general and the NamedElement specifically have no provision for such a scheme. However, in practice, it would frequently be useful if packages, elements and diagrams in UML modelling tools like Together 2007 had an optional long name as well as a required short name.

For example,

  • a use case may have a long descriptive name like 'Register a New Customer for Discounts' but also have a short name or code such as CM006 to make it easier to refer to it in discussions or generated documents and reports. 
  • most programming languages insist that their classes have names without spaces and special characters like '&' but we often want the opposite for names of classes that appear in high-level diagrams, and generated documents, and reports because they communicate better for non-technical audiences. 
  • some modelling tools like Together 2007 support the storing of individual model elements and diagrams in separate files enabling fine grained concurrent access to the model for better collaborative working in team environments. Usually the filename matches the name of the element, and although most modern operating systems support the use of long filenames with spaces, it is not always desirable to have the long names of model elements and diagrams as filenames. 

In LiveSource-enabled projects in Together 2007, there is already some support for this kind of idea. Any model element whose name might be constrained by the underlying programming language naming rules, has an additional alias property that can be populated and will be used instead of the actual name of the element in any diagram it appears on. Often this is simply a slightly more readable form of the name. For example, Java does not allow spaces in class names. The alias field enables a modeller to provide an alternative name for a class that does have spaces in it so that the name looks far more natural in diagrams and reports, and documents generated from the model. 

Whether the short name, long name (when provided), or concatenation of the two are used on a particular diagram or in other views of the model should be a matter of choice for the modeller. In other words, it should be a configurable property or preference of the diagram or view. Unfortunately Together 2007 does not provide this.

This is another example where, ideally, tools like Together 2007 should enable a user to choose between tight compliance with the UML specification and usability where the two conflict.

Where UML modelling tools use files to store UML model diagrams and elements the same principle could also be applied. The choice of short, long or concatenated names for the file or directory created for a diagram/element or package respectively should be that of the modeller enabling them to select a naming scheme for their files that matches any constraints on allowed characters and name lengths in operating systems and version control systems used.

Therefore,  I believe the NamedElement in the UML specification should provide for an optional long name in addition to a shorter name complying with the rules stated earlier.

Summary

Instead of the name attribute of  named elements in the UML being optional, I believe the UML specification should:

  1. provide for an optional long name in addition to a short name
  2. require every element to have short name
  3. require that the short name of an element not be just an empty string or comprise of only whitespace characters,
  4. require the short name of an element be unique within its type, and package or immediate namespace

UML Modelling tools like Borland's Together should

  1. generate initial values for model element names,
  2. provide the option to hide an element's name on a diagram 
  3. enable users to specify whether short, name, long name, or some combination of the two be used in diagrams, other views, generated documents, and files used to store diagrams and model elements.
  4. should always enable a user to choose between tight compliance with the UML specification, or compliance with common sense and ease of use where the two occasionally differ.