Static analysis rules for reviewing UML models

The rules for analyzing UML models can help you determine whether a UML model follows best practices. You can detect 15 different types of problems in a model. For example, you can examine a model for broken semantic relationships, missing specifications, or correct Java™ naming conventions. UML review rules are grouped into five categories: completeness, correctness, Java naming, style, and traceability.

Completeness rules

The following table lists the rules in the completeness category:
Rule name Description
Abstract classes should be concretely subclassed This rule identifies all abstract classes in a model that do not have concrete subclasses, because abstract classes cannot be instantiated and must have concrete implementations to be usable.

Correctness rules

The following table lists the rules in the correctness category:
Rule name Description
Interfaces' operations should be public This rule identifies all interfaces in a model that declare non-public attributes, because all operations in an interface must be publicly visible for concrete implementations of the interface to reference them.
Interfaces' attributes should be public This rule identifies all interfaces in a model that declare non-public attributes, because all attributes in an interface must be publicly visible for concrete implementations of the interface to reference them.

Java naming rules

The following table lists the rules in the Java naming category:
Rule name Description
Always have an element's name that is a valid Java identifier This rule identifies all model elements that do not follow standard Java naming conventions, because, to transform a UML model into valid Java code, all elements in a model must have names that are valid names in Java.
Always have a type's name starting with upper case This rule identifies all types in a model whose names do not start with an uppercase letter, because the standard naming convention in Java is for type names to start with an uppercase letter.
Always have a feature's name starting with lower case This rule identifies all names of features that do not start with a lowercase letter, because the standard naming convention in Java is for feature names to start with a lowercase letter.
Always have a package's name all in lower case This rule identifies all package names in a model that do not contain all lowercase letters, because the standard naming convention is for package names to contain only lowercase letters.
Avoid naming an attribute similar to one inherited from a super type This rule identifies all types in a model that have attributes whose names are the same as attributes in a supertype, because naming an attribute in a subtype the same as an attribute in a supertype hides the supertype attribute in all specializations.

Style rules

The following table lists the rules in the style category:
Rule name Description
Avoid subclassing a concrete class with an abstract class This rule identifies all concrete classes that have an abstract class as a subclass, because this situation indicates a potential design flow issue.
Avoid referencing a sub-classifier This rule identifies all references to subclassifiers, because these references are considered bad practice.
Public attributes should be constant This rule identifies all public attributes in a model, because attributes should not be changeable outside of classifiers. Use get and set methods, or declare attributes as constant instead of declaring them as public.
Avoid interfaces with attributes or outgoing associations This rule identifies all interfaces that have attributes or outgoing associations, because interfaces are meant to specify behavior, not data members.

Feedback