Class Diagrams

[article]
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?

Consistent:

  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?

Correct:

  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?

Consistent:

  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?

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?

Conclusion
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

Lee Copeland's picture Lee Copeland

Lee Copeland has more than thirty years of experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. Based on his experience, Lee has developed and taught a number of training courses focusing on software testing and development issues. Lee is the managing technical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioner's Guide to Software Test Design. Contact Lee at lcopeland@sqe.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09