Dynamic Design Analysis: Testing Without Code

摘要

This paper presents a technique for representing and analyzing the dynamic behavior of a design before time and effort is spent to build it. The technique is based on a mathematical model of objects, software, and software designs and provides operations and inference rules to manipulate not only the objects in a design, but the design itself (see Whitmire, 1997). The technique involves defining an initial state for a scenario and seeding that state with an event that takes the form of a message that originates outside the design. We follow the messages generated as side effects in a breadth-first order until we reach a new steady state, one in which no object changes state without another external event. Working through various scenarios, it is fairly easy to determine which messages will succeed and which will not. The difference between testing a design in this way and testing a design that we've put into code is the time spent writing the code. The schemas above are very easy to modify, especially when compared to the effort to modify any code. For example, I added the feature to send AddEntry an object reference and have the operation create the ListEntry object in a couple of minutes while editing this paper. Modifying code to the same extent would have taken many hours. One additional, if unobvious, benefit of dynamic design analysis is that that you've analyzed a large part of the design, you have complete design contracts for all of the methods you have to build. The specific implementation of each method still needs to be determined, but the rest of the design's view of that method has been fixed and verified. Using this technique does not guarantee that you will find all of the errors in your design. You still have to imagine the combinations of external events and starting states that can cause your design to fail, and it is likely that you'll miss one or two. It will, however, provide you with documented results of the combinations you did analyze, giving you a good start on your set of test cases, including the expected results. This works for combinations that lead to errors, as well as those that succeed in passing a message. The technique also encourages you to state explicitly all of your assumptions. Hidden assumptions, such as which objects are actually in scope, are a leading cause of design errors. Like those who build bridges, machines, and electronic circuits, we can be more confident in our approach to solving a problem if we can show that our approach will indeed work before we build it. Testing a design before building it should lead to more accurate estimates because it eliminates the time required to rework code due to an error in the design, something not included in any estimate. Like steel, concrete, and electronic components, software code is very expensive to modify, so expensive, in fact, that we can no longer afford to build large, complex systems several times while trying to deliver it the first time.