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