This is the fourth and last 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 last in a series of four 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 preceding three 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. Previously I wrote that I was not sure why f-lake never caught on. I pronounced it yesterday without the "-" and now I think I understand.
State-transition diagrams describe all of the states that an object can have, the events under which an object changes state (transitions), the conditions that must be fulfilled before the transition will occur (guards), and the activities undertaken during the life of an object (actions). State-transition diagrams are very useful for describing the behavior of individual objects over the full set of use cases that affect those objects. State-transition diagrams are not useful for describing the collaboration between objects that cause the transitions.
The UML notation for state-transition diagrams is shown below:
For those not familiar with the notation used for state-transition diagrams, some explanation is in order.
State. A condition during the life of an object in which it satisfies some condition, performs some action, or waits for some event.
Event. An occurrence that may trigger a state transition. Event types include an explicit signal from outside the system, an invocation from inside the system, the passage of a designated period of time, or a designated condition becoming true.
Guard. A boolean expression which, if true, enables an event to cause a transition.
Transition. The change of state within an object.
Action. One or more actions taken by an object in response to a state change.
Let's begin with the simplest kind of testing-syntax testing. When performing syntax testing, we are verifying that the state-transition diagram contains correct and proper information. We ask three kinds of questions: Is it complete? Is it correct? Is it consistent?
By now I'm sure 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:
- Does each state-transition diagram have one and only