Chapter 15. The Critics

Chapter 15. The Critics
Prev	Part 2. User Interface Reference	Next

Chapter 15. The Critics

Table of Contents

15.1. Introduction

15.1.1. Terminology
15.1.2. Design Issues

15.2. Uncategorized

15.3. Class Selection

15.3.1. Wrap DataType
15.3.2. Reduce Classes in namespace <namespace>
15.3.3. Clean Up Diagram

15.4. Naming

15.4.1. Resolve Association Name Conflict
15.4.2. Revise Attribute Names to Avoid Conflict
15.4.3. Change Names or Signatures in a model element
15.4.4. Duplicate End (Role) Names for an Association
15.4.5. Role name conflicts with member
15.4.6. Choose a Name (Classes and Interfaces)
15.4.7. Name conflict in a namespace
15.4.8. Choose a Unique Name for a model element (Classes and Interfaces)
15.4.9. Choose a Name (Attributes)
15.4.10. Choose a Name (Operations)
15.4.11. Choose a Name (States)
15.4.12. Choose a Unique Name for a (State related) model element
15.4.13. Revise Name to Avoid Confusion
15.4.14. Choose a Legal Name
15.4.15. Change a model element to a Non-Reserved Word
15.4.16. Choose a Better Operation Name
15.4.17. Choose a Better Attribute Name
15.4.18. Capitalize Class Name
15.4.19. Revise Package Name

15.5. Storage

15.5.1. Revise Attribute Names to Avoid Conflict
15.5.2. Add Instance Variables to a Class
15.5.3. Add a Constructor to a Class
15.5.4. Reduce Attributes on a Class

15.6. Planned Extensions

15.6.1. Operations in Interfaces must be public
15.6.2. Interfaces may only have operations
15.6.3. Remove Reference to Specific Subclass

15.7. State Machines

15.7.1. Reduce Transitions on <state>
15.7.2. Reduce States in machine <machine>
15.7.3. Add Transitions to <state>
15.7.4. Add Incoming Transitions to <model element>
15.7.5. Add Outgoing Transitions from <model element>
15.7.6. Remove Extra Initial States
15.7.7. Place an Initial State
15.7.8. Add Trigger or Guard to Transition
15.7.9. Change Join Transitions
15.7.10. Change Fork Transitions
15.7.11. Add Choice/Junction Transitions
15.7.12. Add Guard to Transition
15.7.13. Clean Up Diagram
15.7.14. Make Edge More Visible
15.7.15. Composite Association End with Multiplicity >1

15.8. Design Patterns

15.8.1. Consider using Singleton Pattern for <class>
15.8.2. Singleton Stereotype Violated in <class>
15.8.3. Nodes normally have no enclosers
15.8.4. NodeInstances normally have no enclosers
15.8.5. Components normally are inside nodes
15.8.6. ComponentInstances normally are inside nodes
15.8.7. Classes normally are inside components
15.8.8. Interfaces normally are inside components
15.8.9. Objects normally are inside components
15.8.10. LinkEnds have not the same locations
15.8.11. Set classifier (Deployment Diagram)
15.8.12. Missing return-actions
15.8.13. Missing call(send)-action
15.8.14. No Stimuli on these links
15.8.15. Set Classifier (Sequence Diagram)
15.8.16. Wrong position of these stimuli

15.9. Relationships

15.9.1. Circular Association
15.9.2. Make <association> Navigable
15.9.3. Remove Navigation from Interface via <association>
15.9.4. Add Associations to <model element>
15.9.5. Remove Reference to Specific Subclass
15.9.6. Reduce Associations on <model element>
15.9.7. Make Edge More Visible

15.10. Instantiation

15.11. Modularity

15.11.1. Classifier not in Namespace of its Association
15.11.2. Add Elements to Package <package>

15.12. Expected Usage

15.12.1. Clean Up Diagram

15.13. Methods

15.13.1. Change Names or Signatures in <model element>
15.13.2. Class Must be Abstract
15.13.3. Add Operations to <class>
15.13.4. Reduce Operations on <model element>

15.14. Code Generation

15.14.1. Change Multiple Inheritance to interfaces

15.15. Stereotypes

15.16. Inheritance

15.16.1. Revise Attribute Names to Avoid Conflict
15.16.2. Remove <class>'s Circular Inheritance
15.16.3. Class Must be Abstract
15.16.4. Remove final keyword or remove subclasses
15.16.5. Illegal Generalization
15.16.6. Remove Unneeded Realizes from <class>
15.16.7. Define Concrete (Sub)Class
15.16.8. Define Class to Implement <interface>
15.16.9. Change Multiple Inheritance to interfaces
15.16.10. Make Edge More Visible

15.17. Containment

15.17.1. Remove Circular Composition
15.17.2. Duplicate Parameter Name
15.17.3. Two Aggregate Ends (Roles) in Binary Association
15.17.4. Aggregate End (Role) in 3-way (or More) Association
15.17.5. Wrap DataType

15.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
	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.

15.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.

15.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.

Prev	Up	Next
14.4. Item Count	Home	15.2. Uncategorized