Suggestion that two association names in the same namespace have the same name. This is not permitted in UML.

Suggestion that two attribute names of a class have the same name. This is not permitted in UML.

	Note
	The problem may be caused by inheritance of an attribute through a generalization relationship.

Two operations in <artifact> have the same signature. This means their name is the same, and the list of parameters has the same type.

Where there are conflicting signatures, correct code cannot be generated for mainstream OO languages. It also leads to very unclear semantics of the design.

In comparing signatures, this critic considers:

Only if these all match in both type and order, will the signatures be considered as the same.

This follows the line of Java/C++ in ignoring the return parameters for the signature. This may be unsatisfactory for some functional OO languages.

	Note
	Some purists would argue that the comparison should really differentiate between in, out and in-out parameters. However no practical programming language can do this when resolving an overloaded method invocation, so this critics lumps them all together.

The specified association has two (or more) ends (roles) with the same name. One of the well-formedness rules in UML 1.4 for associations, is that all end (role) names must be unique.

This ensures that there can be unambiguous reference to the ends of the association.

To fix this, manually select the association and change the names of one or more of the offending ends (roles) using the button 2 pop-up menu or the property sheet.

A suggestions that good design avoids role names for associations that clash with attributes or operations of the source class. Roles may be realized in the code as attributes or operations, causing code generation problems.

The class or interface concerned has been given no name (it will appear in the model as anon). Suggestion that good design requires that all interfaces and classes are named.

Suggestion that the class or interface specified has the same name as another (in the namespace), which is bad design and will prevent valid code generation.

The attribute concerned has been given no name (it will appear in the model as (anon Attribute)). Suggestion that good design requires that all attributes are named.

The operation concerned has been given no name (it will appear in the model as (anon Operation)). Suggestion that good design requires that all operations are named.

The state concerned has been given no name (it will appear in the model as (anon State)). Suggestion that good design requires that all states are named.

Suggestion that the state specified has the same name as another (in the current statechart diagram), which is bad design and will prevent valid code generation.

Two names in the same namespace have very similar names (differing only by one character). Suggestion this could potentially lead to confusion.

	Caution
	This critic can be particularly annoying, since at times it is useful and good design to have a series of artifacts var1, var2 etc. It is important to remember that critics offer guidance, and are not always correct. ArgoUML lets you dismiss the resulting to-do items through the to-do pane (see Chapter 13, The To-Do Pane).

All artifact names in ArgoUML must use only letters, digits and underscore characters. This critic suggests an entity has not met this requirement.

Suggestion that this artifact's name is the same as a reserved word in UML (or within one character of one), which is not permitted.

Suggestion that an operation has not followed the naming convention that operation names begin with lower case letters.

Caution

Following the Java and C++ convention most designers give their constructors the same name as the class, which begins with an upper case character. In ArgoUML, this will trigger this critic, unless the constructor is stereotyped «create». It is important to remember that critics offer guidance, and are not always correct. ArgoUML lets you dismiss the resulting to-do items through the to-do pane (see Chapter 13, The To-Do Pane).

Suggestion that an attribute has not followed the naming convention that attribute names begin with lower case letters.

Suggestion that a class has not followed the naming convention that classes begin with upper case letters.

	Note
	Although not triggering this critic, the same convention should apply to interfaces.

Suggestion that a package has not followed the naming convention of using lower case letters with periods used to indicated sub-packages.