Class Diagrams

Testing UML Models, Part 3
  1. being embedded in method names?
  2. Do all subclasses implement the "is-a-kind-of" relationship properly?
  3. Are all object states represented explicitly using states and transitions rather than as subclasses?
  4. In inheritance structures, are all attributes and methods pushed as high in the inheritance structure as is proper?
  5. Are all polymorphic methods within related subclasses identically named?
  6. Does each association reflect a relationship that exists over the lives of the related objects?


  1. Are each 0..* and 1..* relationships implemented with containers/collectors?
  2. Are each association's cardinalities consistent (instantaneous vs. over-time)?

Domain Expert Testing
After checking the syntax of the class diagrams, we proceed to the second type of testing-domain expert testing. Again, we have two options: find a domain expert or attempt to become one. (The second approach is always more difficult than the first, and the first can be very hard.) Continuing, we ask two kinds of questions: Is it correct? Is it consistent?


  1. Is each class named with a strong noun?
  2. Have all redundant, irrelevant, or vague classes been removed from the diagram?
  3. Is each attribute defined within the proper class? Is it of the correct type?
  4. Is the visibility of each attribute correct?
  5. Are the default values of each attribute specified correctly?
  6. Is each attribute essential rather than computable from others?
  7. Is each method in the correct class?
  8. Are all method names strong verbs?
  9. Does each method take the correct input parameters and return the correct output parameter?
  10. Is the visibility of each method correct?
  11. Does each method implement one and only one behavior?
  12. Is the public interface free from unnecessary methods?


  1. Is the class diagram drawn at the appropriate level: conceptual, specification, or implementation?

Traceability Testing
Finally, after having our domain expert scour the class diagrams, we proceed to the third type of testing-traceability testing. We want to make certain that we can trace from the use cases and the sequence diagrams to the class diagrams and from the class diagrams back to the use cases and sequence diagrams. Again, we turn to one question: Is it consistent?


  1. Is each object on the sequence diagram represented by a class on the class diagram?
  2. Is every message on the sequence diagram reflected as a method in the appropriate class?

This set of questions, based on syntax, domain expert, and traceability testing; and focused on completeness, correctness, and consistency; is designed to get you started testing in an area with which you may not be familiar. The last article will apply the same principles to testing state-transition diagrams.

Have fun testing.

Other articles in this series:

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.