This is the third in a series of articles written to a) introduce you to the most important diagrams used in object-oriented development (use case diagrams, sequence diagrams, class diagrams, and state-transition diagrams); b) describe the UML notation used for these diagrams; and c) give you as a tester a set of practical questions you can ask to evaluate the quality of these object-oriented diagrams.
In today's testing world there is good news and bad news. The good news is that, more and more, testers are being asked to evaluate the quality of object-oriented analysis and design work earlier in the development process. The bad news is that most testers do not have an extensive background in the object-oriented paradigm or in UML (Unified Modeling Language), the notation used to document object-oriented systems.
This is the third in a series of articles written to
- introduce you to the most important diagrams used in object-oriented development (use case diagrams, sequence diagrams, class diagrams, and state-transition diagrams)
- describe the UML notation used for these diagrams
- give you as a tester a set of practical questions you can ask to evaluate the quality of these object-oriented diagrams
As in the first two articles, we will use three independent approaches to test these diagrams:
- syntax–"Does the diagram follow the rules?"
- domain expert–Is the diagram correct?" "What else is there that is not described in this diagram?"
- traceability–"Does everything in this diagram trace back correctly and completely to its predecessor?" "Is everything in the predecessor reflected completely and
correctly in this diagram?"
For this set of articles we have been using a case study: a Web-based online auction system that I invented: f-lake. Yes, I invented the idea of online auctions. I'm not sure why f-lake never caught on.
Class Diagrams
A class diagram describes the classes that make up a system and the static relationships between them. Classes are defined in terms of their name, attributes (or data), and behaviors (or methods). The static relationships are association, aggregation, and inheritance.
The UML notation for class diagrams is shown below:
Notation
For those not familiar with the notation used for class diagrams, some explanation is in order.
Object. A specific entity or concept that has meaning in an application domain.
Class. A definition of a set of potential objects that have the same data, behavior, and relationships.
Attribute. A data value defined in a class and held within an object that has meaning within the application domain.
Behavior. A service defined in a class and provided by an object.
Method. The implementation of a behavior in an object-oriented programming language.
Association. A "peer-to-peer" relationship between classes.
Aggregation. A "whole/part" relationship between classes.
Inheritance. A "generalization/specialization" relationship between classes.
Cardinality/Multiplicity. The minimum and maximum number of objects that participate in an association or aggregation. The common (interesting) ones are 0..*, 0..1, 1..*, and 1..1
Polymorphism. The ability to send a message to an object without knowing its specific class.
Syntax Testing
Let's begin with the simplest kind of testing-syntax testing. When performing syntax testing, we are verifying that the class diagram contains correct and proper information. We ask three kinds of questions: Is it complete? Is it correct? Is it consistent?
Do you remember our secret from the previous articles? You do not need to know the answers to any of these questions before asking them. It is the process of asking and answering that is most important. Listen to the answers you are given. Are people confident about their answers? Can they explain them rationally? Or do they hem and haw and fidget in their chairs or look out the window or become defensive when you ask? Now for the questions:
Complete:
- Does each class define attributes, methods, relationships, and cardinality?
- Is each association well named?
- Is each association's and aggregation's cardinality correct?
Correct:
- Are all attributes private?
- Are all parameters explicit rather than being embedded in method names?
- Do all subclasses implement the "is-a-kind-of" relationship properly?
- Are all object states represented explicitly using states and transitions rather than as subclasses?
- In inheritance structures, are all attributes and methods pushed as high in the inheritance structure as is proper?
- Are all polymorphic methods within related subclasses identically named?
- Does each association reflect a relationship that exists over the lives of the related objects?
Consistent:
- Are each 0..* and 1..* relationships implemented with containers/collectors?
- 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:
- Is each class named with a strong noun?
- Have all redundant, irrelevant, or vague classes been removed from the diagram?
- Is each attribute defined within the proper class? Is it of the correct type?
- Is the visibility of each attribute correct?
- Are the default values of each attribute specified correctly?
- Is each attribute essential rather than computable from others?
- Is each method in the correct class?
- Are all method names strong verbs?
- Does each method take the correct input parameters and return the correct output parameter?
- Is the visibility of each method correct?
- Does each method implement one and only one behavior?
- Is the public interface free from unnecessary methods?
Consistent:
- 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:
- Is each object on the sequence diagram represented by a class on the class diagram?
- 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:
