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
orphan 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. |