This content applies to version 7.5.4 or later. The
rules for analyzing UML models can help you determine whether a UML
model follows best practices. You can detect several 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 the following categories:
completeness, correctness, coupling, Java naming,
style, and traceability.
Completeness rules
The following table
lists the rules in the completeness category:
| Rule name |
Description |
| Abstract classes have concrete subclasses |
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. |
| Orphaned elements |
This rule identifies all elements (excluding packages) that
do not have relationships with any other elements. Elements that are
orphans might be good candidates to delete from the model. |
Correctness rules
The following table lists
the rules in the correctness category:
| Rule name |
Description |
| Interfaces operations are public |
This rule identifies all interfaces in a model that declare
non-public operations, because all operations in an interface must
be publicly visible for concrete implementations of the interface
to reference them. |
| Interfaces attributes are 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. |
Coupling rules
The following table lists
the rules in the coupling category:
| Rule name |
Description |
| Cross-model dependency |
This rule finds all the classifiers in a logical model that
reference classifiers in a different logical model (model or package). |
| Cross-package dependency |
This rule finds all the classifiers in a package that reference
classifiers in a different package. You can exclude subpackage dependencies
from the analysis. |
Java naming rules
The
following table lists the rules in the Java naming
category:
| Rule name |
Description |
| Element names are valid Java identifiers |
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. |
| Type names begin with an uppercase letter |
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. |
| Features names begin with a lowercase letter |
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. |
| Package names are in lowercase letters |
This rule identifies all package names in a model that do
not contain all lowercase letters, because the standard naming convention
in Java is for package names to contain only lowercase letters. |
| Subtype attributes have different names from supertype attributes |
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 |
| Concrete classes do not have abstract subclasses |
This rule identifies all concrete classes that have an abstract
class as a subclass, because this situation indicates a potential
design flow issue. |
| No references to sub-classifiers |
This rule identifies all references to subclassifiers, because
these references are considered bad practice. |
| Public attributes are constant |
This rule identifies all public attributes in a model, because
attributes should not be editable outside of classifiers. Use get
and set methods, or declare attributes as constant instead of declaring
them as public. |
| Interfaces do not have 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. |
Traceability rules
The following table lists
the rules in the traceability category:
| Rule name |
Description |
| Element is involved in a trace relationship cycle |
This rule identifies all elements that are involved in a
trace relationship cycle. |
| Element is missing an implementation |
This rule identifies all elements that do not have an implementation. |
| Element is missing a specification |
This rule identifies all elements that do not have a specification. |