billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/20/89)
From ted@nmsu.edu (Ted Dunning): > Another mechanism is the "package". One use of packages is to > describe specifications (*compilable* specifications) for > subsystems which collectively interact to form a larger system. > Once the high-level specifications have been compiled together, > the information flows across the subsystem interfaces have been > verified for completeness and consistency. > > this `checking for completeness and consistency' is actually nothing > more than a static type check. since in a large application, the > constraints on the interface between packages is considerably more > complex than just having the communication merely be of the correct > type, this should not be characterized as a full verification. I don't think I characterized this as a full verification, since I did explicitly refer to integration testing. If a "full verification" was done, including semantics, then integration testing would become unnecessary. "Completeness and consistency" was intended to make it clear that I was excluding semantics. > type checking is a good thing. separate compilation is a good thing. > libraries and linkers that understand type checking are a good thing. > none of these are particular to ada. some or all of these can be > found in ansii c, commercially available pascals, c++ and other > languages. some of these solutions are partitioned differently from > the way specified by ada orthodoxy, often with the result of more > flexibility. this is the case with make. I don't think make has any more flexibility than the tools provided by Ada compiler vendors; see Telesoft's amake, for example. > one place that most of these tools fall down at the current time is > with program generators and preprocessors. the requirement that we > specify interfaces completely in terms of base language leads to very > serious awkwardness if when we try to replace the functionality of > yacc or make heavy use of precompilation as do the internals of the > gnu c compiler. My program generator experiences lead me to believe that such software should generally have an interactive interface. For example, a generator which assists in the design of screen layouts should do so on the basis of interactive inputs, in conjunction with the selective employment of screen editors when the programmer needs to specify a procedure for handling the user input of a particular data item. I think this tactic can be used to successfully handle program generation requirements, since I have used it myself with extremely satisfying results. As for precompilation, I see no reason why this should be a problem. (This seems to be getting away from software components, so I've redirected followups to comp.software-eng...) Bill Wolfe, wtwolfe@hubcap.clemson.edu
hughes@math.Berkeley.EDU (Eric Hughes) (05/20/89)
In article <5535@hubcap.clemson.edu>, billwolf%hazel (William Thomas Wolfe,2847,) writes: > If a "full verification" > was done, including semantics, then integration testing would become > unnecessary. Are you asserting that it is both possible and feasible to specify the semantics of a component so completely that integration testing becomes unnecessary? Eric Hughes hughes@math.berkeley.edu ucbvax!math!hughes
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/22/89)
From hughes@math.Berkeley.EDU (Eric Hughes): > billwolf%hazel (William Thomas Wolfe,2847,) writes: >> If a "full verification" was done, including semantics, then >> integration testing would become unnecessary. > > Are you asserting that it is both possible and feasible to specify > the semantics of a component so completely that integration testing > becomes unnecessary? No, I'm saying that if it were possible, and in fact being done, then the absence of any need for integration testing would be a derivable conclusion. The fact that I indicated that this conclusion did not hold proves the invalidity of the premise that my reference to verification for "consistency and completeness" somehow implied that component semantics were being verified. Bill Wolfe, wtwolfe@hubcap.clemson.edu