The class has no child classes, dependencies, or associations, and it is not used as parameter or property type. You'll probably still need to model the clients of the class, or else consider deleting the class from the model.

Note: for models that were reverse-engineered from source code, this rule may falsely report many classes as "unused". This happens for classes that are only referenced in method implementations, e.g., via local variables.

• Suggested in [Rie96] (heuristic #3.7 eliminate irrelevant classes).

This naming convention is a recommended style guideline in the UML standards [OMG03], [OMG05].

Also known as blob classes, large classes are likely maintenance bottlenecks, sources of unreliability, and indicate a lack of (object-oriented) architecture and architecture enforcement.

Consider refactoring the class to split it up into smaller classes.

• Threshold of 60 cited in [BMM98].
• See also metrics NumOps and NumAttr
• Also known as "Large Class" code smell [Fow99].
• Value reported: number of operations and attributes.

• Suggested in [RVR04].

The use of multiple inheritance is controversial. Some OO programming languages do not support multiple inheritance. Review the class design to confirm that the use of multiple inheritance is justified.

• Suggested in [Rie96].

Leaf classes cannot have any child classes. This is a WFR of the UML.

Abstract classes cannot be instantiated. Without specializations that can be instantiated, the abstract class is useless.

• Suggested in [Rie96].
• Violations of this rule would be justified if the class is part of a framework or library, and is meant to be extended by users of the framework/library.

The inheritance graph must be a tree, no cycles are allowed.

• This is a WFR of the UML.
• You can view the inheritance graph in the graph structures dialog.
• Value returned: number of classes in the cycle.

This is bad design. A child class should be substitutable for the parent class. Since the parent class can be instantiated, but not the child class, substitution is not possible anymore.

• Suggested in [Lan03].
• Value returned: name of the concrete parent class.

There are two or more operations with identical signatures (i.e., operation name and list of parameter types). Operation signatures must be unique within the class.

• This is a WFR of the UML.
• Value reported: name of the duplicate operation.

Attribute names must be unique within the class.

• This is a WFR of the UML.
• Value reported: name of the duplicate attribute.

During code generation, this may inadvertently hide the attribute of the parent class. Consider changing the name of the attribute in the child class.

• Suggested in [RVR04].

This is poor design. A class c should be oblivious of its descendent classes. The reference to the descendent class and the inheritance links back to class c effectively form a dependency cycle between these classes.

Redesign this to eliminate the need for the reference to the descendent class.

• Suggested in [RVR04], [Rie96].
• Value reported: name of the referenced descendent class.

Circular dependencies should be avoided. The classes participating in the cycle cannot be tested and reused independently. The more classes participate in the cycle, the worse the problem is, especially if the classes reside in different packages (see also rule DepCycle for packages).

Consider revising the design to eliminate the cycle.

• See also: Dependency Inversion Principle [Mar03].
• You can view the class dependency graph and its cycles in the Graph Structures View.
• Value reported: number of classes in the cycle.