Download ArgoUML User Manual - The GNU

Transcript
The Critics
15.4.3. Change Names or Signatures in an Artifact
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:
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
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.
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 wellformedness 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 anon). Suggestion that good design requires that all interfaces and classes are named.
15.4.7. Choose a Unique Name for an Artifact (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.
174