marick@m.cs.uiuc.edu (02/27/90)
I asked about symbolic execution. Somehow, I'd missed an outstanding paper on it: W. E. Howden. An Evaluation of the Effectiveness of Symbolic Testing. Software - Practice and Experience, vol. 8, no. 4, pp. 381-398, July-August, 1978. This is one of several Howden papers where he applies testing techniques to programs to see how many and which kinds of faults they detect.** The paper discusses a variety of techniques, not just symbolic execution. Must reading for anyone interested in testing. ** Boy, reading that, it looks pretty peculiar. Can you imagine someone writing that a JAMA article was noteworthy because it was "one of several Howden papers in which he applies surgical techniques to coronary problems to see how many and which kinds of occlusions are corrected"? You'd expect that to be a ubiquitous kind of paper, instead of a prized exception. Brian Marick Motorola @ University of Illinois marick@cs.uiuc.edu, uiucdcs!marick
johnson@m.cs.uiuc.edu (07/08/90)
tom@stl.stc.co.uk writes: >In article <26855613.749b@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >> >>A lot of what is gained in OOD is in the de-sequentializing of our problems. >>Objects can be considered as independently executing processes. Because of >>the extreme decoupling between objects, the problem is broken down into >>more manageable pieces. This seems to me that it should make the problem >Every OO language I have seen makes this claim. However, every OO language >that I've seen (with one experimental exception, a laboratory toy language) >insists that the messages are SYNCHRONOUS, that the channels between the >processes are UNBUFFERED (and blocking), that every message has a REPLY >whose sending is implicit (in result delivery). There is really no contradiction between these statements. OOD lets the designer THINK about objects as if they are desequentialized, it doesn't require that it be true. Object-oriented programmers tend not to worry much about order of execution but rather about interfaces. This is similar to > Abstraction with strong encapsulation I am curious about how software engineers have traditionally practised > Inheritance mechanisms to facilitate re-use I can't see the point you are trying to make. Ralph Johnson -- University of Illinois at Urbana-Champaign