Chapter 14. The Critics

Table of Contents

14.1. Introduction
14.1.1. Terminology
14.1.2. Design Issues
14.2. Uncategorized
14.3. Class Selection
14.3.1. Wrap DataType
14.3.2. Reduce Classes in diagram <diagram>
14.3.3. Clean Up Diagram
14.4. Naming
14.4.1. Resolve Association Name Conflict
14.4.2. Revise Attribute Names to Avoid Conflict
14.4.3. Change Names or Signatures in an Artifact
14.4.4. Duplicate End (Role) Names for an Association
14.4.5. Role name conflicts with member
14.4.6. Choose a Name (Classes and Interfaces)
14.4.7. Choose a Unique Name for an Artifact (Classes and Interfaces)
14.4.8. Choose a Name (Attributes)
14.4.9. Choose a Name (Operations)
14.4.10. Choose a Name (States)
14.4.11. Choose a Unique Name for a (State related) Artifact
14.4.12. Revise Name to Avoid Confusion
14.4.13. Choose a Legal Name
14.4.14. Change an Artifact to a Non-Reserved Word
14.4.15. Choose a Better Operation Name
14.4.16. Choose a Better Attribute Name
14.4.17. Capitalize Class Name
14.4.18. Revise Package Name
14.5. Storage
14.5.1. Revise Attribute Names to Avoid Conflict
14.5.2. Add Instance Variables to a Class
14.5.3. Add a Constructor to a Class
14.5.4. Reduce Attributes on a Class
14.6. Planned Extensions
14.6.1. Operations in Interfaces must be public
14.6.2. Interfaces may only have operations
14.6.3. Remove Reference to Specific Subclass
14.7. State Machines
14.7.1. Reduce Transitions on <state>
14.7.2. Reduce States in machine <machine>
14.7.3. Add Transitions to <state>
14.7.4. Add Incoming Transitions to <artifact>
14.7.5. Add Outgoing Transitions from <artifact>
14.7.6. Remove Extra Initial States
14.7.7. Place an Initial State
14.7.8. Add Trigger or Guard to Transition
14.7.9. Change Join Transitions
14.7.10. Change Fork Transitions
14.7.11. Add Choice/Junction Transitions
14.7.12. Add Guard to Transition
14.7.13. Clean Up Diagram
14.7.14. Make Edge More Visible
14.8. Design Patterns
14.8.1. Consider using Singleton Pattern for <class>
14.8.2. Singleton Stereotype Violated in <class>
14.8.3. Nodes normally have no enclosers
14.8.4. NodeInstances normally have no enclosers
14.8.5. Components normally are inside nodes
14.8.6. ComponentInstances normally are inside nodes
14.8.7. Classes normally are inside components
14.8.8. Interfaces normally are inside components
14.8.9. Objects normally are inside components
14.8.10. LinkEnds have not the same locations
14.8.11. Set classifier (Deployment Diagram)
14.8.12. Missing return-actions
14.8.13. Missing call(send)-action
14.8.14. No Stimuli on these links
14.8.15. Set Classifier (Sequence Diagram)
14.8.16. Wrong position of these stimuli
14.9. Relationships
14.9.1. Circular Association
14.9.2. Make <association> Navigable
14.9.3. Remove Navigation from Interface via <association>
14.9.4. Add Associations to <artifact>
14.9.5. Remove Reference to Specific Subclass
14.9.6. Reduce Associations on <artifact>
14.9.7. Make Edge More Visible
14.10. Instantiation
14.11. Modularity
14.11.1. Classifier not in Namespace of its Association
14.11.2. Add Elements to Package <package>
14.12. Expected Usage
14.12.1. Clean Up Diagram
14.13. Methods
14.13.1. Change Names or Signatures in <artifact>
14.13.2. Class Must be Abstract
14.13.3. Add Operations to <class>
14.13.4. Reduce Operations on <artifact>
14.14. Code Generation
14.14.1. Change Multiple Inheritance to interfaces
14.15. Stereotypes
14.16. Inheritance
14.16.1. Revise Attribute Names to Avoid Conflict
14.16.2. Remove <class>'s Circular Inheritance
14.16.3. Class Must be Abstract
14.16.4. Remove final keyword or remove subclasses
14.16.5. Illegal Generalization
14.16.6. Remove Unneeded Realizes from <class>
14.16.7. Define Concrete (Sub)Class
14.16.8. Define Class to Implement <interface>
14.16.9. Change Multiple Inheritance to interfaces
14.16.10. Make Edge More Visible
14.17. Containment
14.17.1. Remove Circular Composition
14.17.2. Duplicate Parameter Name
14.17.3. Two Aggregate Ends (Roles) in Binary Association
14.17.4. Aggregate End (Role) in 3-way (or More) Association
14.17.5. Wrap DataType
14.17.6. Import Parameter Type into Class

14.1. Introduction

The key feature that distinguishes ArgoUML from other UML CASE tools is its use of concepts from cognitive psychology. The theory behind this is well described in Jason Robbins' PhD dissertation http://argouml.tigris.org/docs/robbins_dissertation/.

Critics are one of the main ways in which these ideas are implemented. Running in the background they offer advice to the designer which may be accepted or ignored. A key point is that they do not impose a decision on the designer.

[Note]Note

The critics are asynchronous processes that run in parallel with the main ArgoUML tool. Changes typically take a second or two to propagate as the critics wake up.

14.1.1. Terminology

The critics are background processes, which evaluate the current model according to various “good” design criteria. There is one critic for every design criterion.

The output of a critic is a critique—a statement about some aspect of the model that does not appear to follow good design practice.

Finally a critique will generally suggest how the bad design issue it has identified can be rectified, by raising a to-do item.

14.1.2. Design Issues

ArgoUML categorizes critics according the the design issue they address (some critics may be in more than one category). At present there are 16 such categories.

Within this manual the descriptions of critics are grouped in sections by design issue.