Showing papers on "Halstead complexity measures published in 1982"
13 Sep 1982
TL;DR: In this paper, the authors describe tests made on the validity of the relationships and interpretations which form the foundations of software science and conclude that the majority of them represent neither natural laws nor useful engineering approximations.
Abstract: Karl Popper has described the scientific method as “the method of bold conjectures and ingenious and severe attempts to refute them”. Software Science has made “bold conjectures” in postulating specific relationships between various 'metrics' of software code and in ascribing psychological interpretations to some of these metrics.This paper describes tests made on the validity of the relationships and interpretations which form the foundations of Software Science. The results indicate that the majority of them represent neither natural laws nor useful engineering approximations.
68 citations
30 Aug 1982
TL;DR: The thesis work focuses on the examination of Halstead's theory; with an emphasis on his fundamental assumptions, and elaboration of the basic theory will result in guidelines for the creation of counting rules applicable to specific classes of programs.
Abstract: A number of papers have appeared on the subject of software science; claiming the existence of laws relating the size of a program and the number of operands and operators used. The pre-eminent theory was developed by Halstead in 1972. The thesis work focuses on the examination of Halstead's theory; with an emphasis on his fundamental assumptions. In particular, the length estimator was analyzed to determine why it yields such a high variance; the theoretical foundations of software science have been extended to improve the applicability of the critical length estimator. This elaboration of the basic theory will result in guidelines for the creation of counting rules applicable to specific classes of programs, so that it is possible to determine both when and how software science can be applied in practice.
11 citations
26 Jul 1982
TL;DR: This paper will explore the possible extension of Halstead's theory to include operators, as defined in APL, in the counting methodology and software science formulae.
Abstract: Software engineering is a growing part of computer science. Software engineering attempts to put measurements and metrics into the area of software programming. One of these metrics, Halstead's software science [1], measures a program's difficulty, a language level, and in turn, a programmer's productivity. Software science uses an extensive measure as opposed to the intensive measure of most other software engineering techniques. This is accomplished by counting functions and operands, and applying several formulae modified from thermodynamics. Even though software science attempts to place an objective measurement on these parameters, it is not meant to be a definitive decision tool, but rather a general guideline. This paper will explore the possible extension of Halstead's theory to include operators, as defined in APL, in the counting methodology and software science formulae.
7 citations
IBM1
TL;DR: The difficulty measure reflects the effort required to code an algorithm, to test it, to inspect and review it, and to understand it later when the code needs alterations.
Abstract: The difficulty measure, as defined by Halstead [1], is shown to have useful applications in the measurement of certain properties in code implementations. This difficulty measure reflects the effort required to code an algorithm, to test it, to inspect and review it, and to understand it later when the code needs alterations.
6 citations
30 Aug 1982
TL;DR: An algorithm which measures APL-programs in the sense of software science by M.H. Halstead is designed and implemented and some difficulties encountered in the design of the measuring algorithm and some inherent limitations of it are discussed.
Abstract: We have designed and implemented an algorithm which measures APL-programs in the sense of software science by M.H. Halstead /1/. The reader is assumed to be familiar with the theories of software science.Our purpose has been to find the best possible algorithm to automatically analyse large quantities of APL-programs. We have also used our measuring tool to make some experiments to find out if APL-programs and workspaces obey the laws of software science or not.Becasue our purpose was to analyse large quantities, i.e. hundreds of programs we have not implemented an algorithm, which gives exactly correct results from software science point of view, because this would necessitate manual clues to the analysing algorithm and thus an interactive mode of analysis. Instead of it we have strived for a tool, which carries out the analysis automatically and as correctly as possible.In the next section some difficulties encountered in the design of the measuring algorithm and some inherent limitations of it are discussed. Section 3 summarises the sources of errors in the analysis carried out by our algorithm, while section 4 gives a more detailed description of the way analysis is carried out.The remaining sections of this paper report on some experiments we have carried out using our measuring tool. The purpose of these experiments has been to evaluate the explaining power of Halstead's theory in connection of APL-programs. However, no attempt has been made to process the results of the experiments statistically. The results of the experiments have been treated here only when 'obvious' (in)compatibilities between the theory and the results have been observed. Possible reasons for the (in)compatibilities are also pointed out.
3 citations
01 Aug 1982
TL;DR: The effect of counting GOTO's as several occurrences of a single unique operator on various software science metrics is investigated.
Abstract: Halstead in his Theory of Software Science, proposed that in the Fortran language, each occurrence of a GOTO i for different label i's be counted as a unique operator. Several writers have questioned the wisdom of this method of counting GOTO's. In this paper, we investigate the effect of counting GOTO's as several occurrences of a single unique operator on various software science metrics. Some 412 modules from the International Mathematical and Statistical Libraries (IMSL) are used as the data base for this study.
2 citations
01 Aug 1982
TL;DR: Counting rules in the software metrics field have been developed for counting such software measurables as the occurence of operators, operands and the number of lines of code.
Abstract: Counting rules in the software metrics field have been developed for counting such software measurables as the occurence of operators, operands and the number of lines of code. A variety of software metrics, such as those developed by Halstead and others, are computed from these numbers. Published material in the software metrics field has concentrated on relationships between various metrics, comparisions of values obtained for different languages, etc. Yet, little, if anything has been published on assumptions, experimental designs, or the nature of the counting tools (or programs) themselves used to obtain the basic measurements from which these metrics are calculated.
IBM1
TL;DR: It is suggested that Halstead's seemingly disparate rules for classifying the tokens of programs and the Tokens of English can be generally reconciled, although Halstead himself does not claim such a union.
Abstract: In his Elements of Software Science, Maurice Halstead proposed that software quality measurements could be based on static lexemic analysis of the vocabularies of operators and operands, and the number of occurrences of each class, in computer programs. He also proposed that quality issues in Natural Language text could be addressed from similar perspectives, although his rules for programs and for English seem to conflict.This paper suggests that Halstead's seemingly disparate rules for classifying the tokens of programs and the tokens of English can be generally reconciled, although Halstead himself does not claim such a union. The thesis of Part One is a unification of his two procedures, based on a linguistic partitioning between “open” and “closed” classes. This unification may provide new inputs to some open issues concerning coding, and suggest, on the basis of a conceptual rationale, an explanation as to why programs which are by Halstead's definition “impure” might indeed be confusing to the human reader.Part Two of this paper, by exploring the nodes in a textual “Claim Space,” briefly considers other groupings of the classes taken as primitive by Halstead, in ways which bring to light alternate and supplementary sets of candidate coding rules productive for study of textual quality.