Login | Register
My pages Projects Community openCollabNet

15.4.  Naming

These are critics concerning the naming of model elements. The current version of ArgoUML has 18 critics in this category.

15.4.1.  Resolve Association Name Conflict

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

15.4.2.  Revise Attribute Names to Avoid Conflict

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

[Note]Note

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

15.4.3.  Change Names or Signatures in a model element

Two operations in <model element> 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:

  1. the name;

  2. the list of in, out and in-out parameter types in order; and

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]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 critic lumps them all together.

15.4.4.  Duplicate End (Role) Names for an Association

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.

15.4.5.  Role name conflicts with member

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.

15.4.6.  Choose a Name (Classes and Interfaces)

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

15.4.7.  Name conflict in a namespace

The namespace (e.g. package) concerned contains a class or interface specified that has the same name as another (in the same namespace), which is bad design and will prevent valid code generation.

15.4.8.  Choose a Unique Name for a model element (Classes and Interfaces)

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.

15.4.9.  Choose a Name (Attributes)

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

15.4.10.  Choose a Name (Operations)

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

15.4.11.  Choose a Name (States)

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

15.4.12.  Choose a Unique Name for a (State related) model element

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.

15.4.13.  Revise Name to Avoid Confusion

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

[Caution]Caution

This critic can be particularly annoying, since at times it is useful and good design to have a series of model elements 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 14, The To-Do Pane ).

15.4.14.  Choose a Legal Name

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

15.4.15.  Change a model element to a Non-Reserved Word

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

15.4.16.  Choose a Better Operation Name

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

[Caution]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 14, The To-Do Pane ).

15.4.17.  Choose a Better Attribute Name

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

15.4.18.  Capitalize Class Name

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

[Note]Note

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

15.4.19.  Revise Package Name

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