Stuart H. Zweben
Ohio State University
Network
Latest external collaboration on country level. Dive into details by clicking on the dots.
Publication
Featured researches published by Stuart H. Zweben.
Advances in Computers | 1991
Bruce W. Weide; William F. Ogden; Stuart H. Zweben
Methods and apparatus, including computer program products, implement techniques for structuring applications into reusable components. A reusable component having an external interface and an internal interface is implemented. The component encapsulates functionality, where multiple instances of the component are reusable at the same time. The component is configurable to embed one or more specified components. The external interface comprises an external programming interface, an external data-binding interface, and an external visual interface. The internal interface comprises an embedding interface, an internal programming interface, an internal data-binding interface, and an internal visual interface. The embedding interface specifies one or more component interfaces of components that can be embedded.
ACM Sigsoft Software Engineering Notes | 1994
William F. Ogden; Murali Sitaraman; Bruce W. Weide; Stuart H. Zweben
In a nutshell, RESOLVE software components are just parameterized modules. A typical specification module defines formally the structural interface and functional behavior of an encapsulated abstract data type (ADT) and associated operations whose parameters are of that type and other types. A typical implementation module describes how such a type is represented as a composition of other ADTs and how the associated operations are effected by invoking sequences of operations associated with the types used in the representation.
IEEE Transactions on Software Engineering | 1991
Allen S. Parrish; Stuart H. Zweben
Test data adequacy criteria are standards that can be applied to decide if enough testing has been performed. Previous research in software testing has suggested 11 fundamental properties which reasonable criteria should satisfy if the criteria make use of the structure of the program being tested. It is shown that there are several dependencies among the 11 properties making them questionable as a set of fundamental properties, and that the statements of the properties can be generalized so that they can be appropriately analyzed with respect to criteria that do not necessarily make use of the programs structure. An analysis that shows the relationships among the properties with respect to different classes of criteria which utilize the program structure and the specification in different ways is discussed. It is shown how the properties differ under the two models in order to maintain consistency that the dependencies are largely a result of five very weak existential properties, and that by modifying three of the properties, these weaknesses can be eliminated. The result is a reduced set of seven properties, each of which is strong from a mathematical perspective. >
workshop on software and performance | 1984
Allen Haley; Stuart H. Zweben
Abstract Program testing techniques can be classified in many ways. One classification is that of “black box” vs. “white box” testing. In black box testing, test data are selected according to the purpose of the program independent of the manner in which the program is actually coded. White box testing, on the other hand, makes use of the properties of the source code to guide the testing process. A white box testing strategy, which involves integrating a previously validated module into a software system is described. It is shown that, when doing the integration testing, it is not enough to treat the module as a “black box,” for otherwise certain integration errors may go undetected. For example, an error in the calling program may cause an error in the modules input which only results in an error in the modules output along certain paths through the module. These errors can be classified as Integration Domain Errors, and Integration Computation Errors. The results indicate that such errors can be detected by the module by retesting a set of paths whose cardinality depends only on the dimensionality of the modules input for integration domain errors, and on the dimensionality of the modules inputs and outputs for integration computation errors. In both cases the number of paths that need be retested do not depend on the modules path complexity. An example of the strategy as applied to the path testing of a COBOL program is presented.
IEEE Transactions on Software Engineering | 1979
Albert L. Baker; Stuart H. Zweben
An investigation is made into the extent to which relationships from software science are useful in analyzing programming methodology principles that are concerned with modularity. Using previously published data from over 500 programs, it is shown that the software science effort measure provides quantitative answers to questions concerning the conditions under which modularization is beneficial. Among the issues discussed are the reduction of similar code sequences by temporary variable and subprogram defmition, and the use of global variables. Using data flow analysis, environmental considerations which affect the applicability of alternative modularity techniques are also discussed.
IEEE Transactions on Software Engineering | 1977
Stuart H. Zweben
A theory of the structural composition of an algoithm is presented which allows the frequencies of occurrence of the individual operators and operands to be estimated. It provides justification for some recent hypotheses which suggest certain functional relationships between properties of algorithms.
IEEE Transactions on Software Engineering | 1993
Allen S. Parrish; Stuart H. Zweben
A software test data adequacy criterion is a means for determining whether a test set is sufficient, or adequate, for testing a given program. A set of properties that useful adequacy criteria should satisfy have been previously proposed (E. Weyuker, 1986; 1988). The authors identify some additional properties of useful adequacy criteria that are appropriate under certain realistic models of testing. They discuss modifications to the formal definitions of certain popular adequacy criteria to make the criteria consistent with these additional properties. >
Journal of Systems and Software | 1993
Lynn M. Foreman; Stuart H. Zweben
Abstract The effectiveness of control and data flow testing strategies is studied through an analysis of a subset of the defects observed in the development of the computer typesetting program TeX. In this study, the strategies are considered effective at revealing a defect only when any test set that satisfies the strategy is capable of revealing the defect. It is shown that even the simplest of the control and data flow strategies are effective at revealing a reasonable number of the defects. For those defects for which the control and data flow strategies were not effective, other well-known methods such as special value testing, boundary testing, or static data flow analysis were usually effective. The results suggest that systematic testing strategies for which tool support is possible can eliminate a significant number of defects undetected by current testing practice.
IEEE Transactions on Software Engineering | 1979
Stuart H. Zweben; Maurice H. Halstead
During the past few years, several investigators have noted definite patterns in the distribution of operators in computer programs. Their proposed models have provided explanations for other observed software phenomena and have suggested possible relationships between programming languages and natural languages. However, these models contain notable deficiencies.
workshop on software and performance | 1984
John B. Lohse; Stuart H. Zweben
Abstract The importance of the scientific investigations of software design principles is discussed, and an experimental investigation of the importance of the design principle of module coupling is described. One important dimension of coupling, as promoted by the authors of the structured design methodology, is that of global variable vs. parameterized methods of intermodule communication. It is shown that different proposed software metrics provide conflicting conclusions as to the preferred method of intermodule communication. The three experiments reported herein were performed in university software engineering courses taken by graduate students and upper level undergraduate majors in computer science. They address the effect of global vs. parameterized interfaces on system modifiability. While the type of modification being performed significantly influenced the modifiability of the system, there were no consistent effects due to the type of coupling present in the system.