UML Issues and and Deficiencies

Issues and Deficiencies of UML Specification

Generally, the purpose of any specification is to provide complete and precise description (definition) of the matter. Usually it has some formal or formalised parts and informal description. Whether it is formal or informal part, the reader wants it to be precise and as complete as possible. UML Specification has a long way to go. Don't blame yourself if you can't read it and get annoyed.

General Issues and Deficiencies

Slang Used Without Glossary

There was a Glossary as part of the UML Specifications until UML 2.0, and alas! it was removed for unknown reasons. This is really wrong because we may only guess the meaning of many fancy terms UML specifications use. Some examples of "UML slang" (there is neither definition nor explanation of the term) are

• ownership,
• semantic relationship.

Teasing

One annoying feature of the UML specification is teasing. They would usually write something like "it is usually this way but in some rare cases - another way." You may only guess what they mean and what was the purpose of that teasing. Here's one example:

Attributes of a class are represented by instances of Property that are owned by the class. Some of these attributes may represent the navigable ends of binary associations.

Ok, I got it: some of these attributes may represent ..., but what about the others? Are those simply not navigable or not the ends of association at all? And if not former or latter, why?

In the case of multiplicity 1 or 0..1, the qualifier has both semantic and implementation consequences. In the case of multiplicity 0..*, it has no real semantic consequences...

Great, in some cases we'll have both semantic and implementation consequences. What it means? Is it good or bad? Something should happen during implementation, and it will have some or no meaning?

Lack of Examples

It might be obvious for UML designers how some elements should look when they only provide textual description but UML is a visual modeling language, and for UML one picture is definitely worth a thousand words.

Mistakes in BNF Rules

Mistakes in BNF rules describing syntax of some UML elements are very annoying.

No Rules for Element Names

Amazingly, UML specification does not provide exact rules for element names. For example, namespace provides a means for resolving composite names, such as name1::name2::name3. What are the rules for the name1/2/3? Could we use spaces, dashes, digits?

For the class name we should: capitalize the first letter of class names (if the character set supports uppercase). But what are the rules for the class name? A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. But what are the rules for the use case name?

Class Diagrams

Navigability

Navigability in [UML 2.4] means efficient links "at runtime" to the navigable instance. End property of association that is owned by an end class is also navigable. At the same time, some examples in the specification show class attributes as not navigable. Maybe it's not too bad, because not navigable is defined as "access from the other ends may or may not be possible, and if it is, it might not be efficient." which in plain English means "whatever" or "who cares?" navigability. UML 2.4 also states that some of class attributes may represent the navigable ends of binary associations without further clarification whether other attributes are not ends of association or not navigable ends.

Dependency

A single example for dependency relationship [UML 2.4, p.67] shows Car instantiated by CarFactory. Text says that "the Car class has a dependency on the CarFactory class" (isn't it exactly the opposite?), and even worse that "the Car class is an instance of the CarFactory class"! BTW, this issue was submitted to OMG in 2008.

Package Diagrams

Package URI Attribute Uses Obsolete RFC 2396

UML 2.4 specification introduced URI package attribute and requires this attribute to follow the rules and syntax of the IETF URI specification RFC 2396. RFC 2396 was rendered obsolete by the more recent version of the URI syntax - RFC 3986, released in 2005.

Use Case Diagrams

Association

Actors may be connected to use cases by binary association relationship which means that the actor and the use case can communicate with each other. While it looks like association, in practice it causes confusion when somebody uses navigability. It could become even worse should somebody try to use aggregation type or apply association end ownership. Wouldn't it be appropriate to have special subclass of association for use case diagrams?

Profile Diagrams

Profile URI Attribute - Mingled Definition and Use in XMI

While describing profile URI attribute for profiles UML specification mingled definition of URI and format used for XMI. URI value as a whole should follow URI specification RFC 2396 and OMG recommended format.

When URI is used for XMI, profileParentQualifiedName part should also be (made?) valid XML QName, e.g. with "all other illegal XML QName characters removed". Note, that XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to and has no sense as related to the first URI 2396 requirement.

Issues and Deficiencies of UML