the authors present results from a research project to investigate the feasibility of software tools for analyzing designs of softwaresystems. Such analysis would help the software developer to assess the acceptabili...
详细信息
ISBN:
(纸本)0818606207
the authors present results from a research project to investigate the feasibility of software tools for analyzing designs of softwaresystems. Such analysis would help the software developer to assess the acceptability of designs before the development of the software moves from the design phase into the implementation phase. If this could be done, futile implementation efforts based on faulty designs could be avoided. the authors have constructed a language for expressing designs of sequential and concurrent softwaresystems, and software tools to analyze these designs. the authors' analysis tools derive behavior information, in terms of reachable states or possible sequences of significant events, from system descriptions in a variety of ways. By means of controlled human-factors experiments, the authors have determined that their analysis tools and techniques are indeed useful, to varying extents, in helping people to understand designs and find flaws in them.
the authors report on experiments with Prolog design descriptions and tools in CAEDE (Carleton Embedded System Design Environment), an experimental, iconic design environment for multitasking, embedded systems. the ph...
详细信息
ISBN:
(纸本)0818606207
the authors report on experiments with Prolog design descriptions and tools in CAEDE (Carleton Embedded System Design Environment), an experimental, iconic design environment for multitasking, embedded systems. the philosophy of CAEDE is to enter structural and temporal design information iconically, via a graphics interface, to serve as the basis for design analysis and skeleton code generation, and then to enter, under control of the iconic interface, program 'strips' to fill in the functional gaps in the skeleton code. the iconic information is converted automatically into a Prolog design database of facts and rules. CAEDE aims to support incremental design and to be incrementally extensible. In the current implementation of CAEDE, which runs on a SUN workstation supporting design for Ada, the iconic interface is limited to structural design. A description is given of the Prolog side of the research, covering the nature of the facts produced from the iconic input by the current implementation and their use by experimental Prolog tools for structural analysis, temporal analysis and Ada code generation. the aim is to show how Prolog is contributing to the framework of a powerful, extensible design environment.
this paper describes a system currently being developed called the “Analyst”. the Analyst is a support system for analysis and design methods. the method support facilities are being implemented using expert system ...
ISBN:
(纸本)9780818606205
this paper describes a system currently being developed called the “Analyst”. the Analyst is a support system for analysis and design methods. the method support facilities are being implemented using expert system or knowledge based techniques. the user can add rules for additional analysis of the application facts. the explicit representation of rules and facts (i.e. the knowledge base) makes it relatively easy to add methods to cover different phases or aspects of the software life cycle.
In this paper are presented the results of a study in which several production softwaresystems are analyzed using ten software metrics. the ten metrics include both measures of code details, measures of structure, an...
ISBN:
(纸本)9780818606205
In this paper are presented the results of a study in which several production softwaresystems are analyzed using ten software metrics. the ten metrics include both measures of code details, measures of structure, and combinations of these two. Historical data recording the number of errors and the coding time of each component are used as objective measures of resource expenditure of each component. the metrics are validated by showing: (1) the metrics singly and in combination are useful indicators of those components which require the most resources, (2) clear patterns between the metrics and the resources expended are visible when both resources are accounted for, (3) measures of structure are as valuable in examining softwaresystems as measures of code details, and (4) the choice of which, or how many, software metrics to employ in practice is suggested by measures of “yield” and “coverage”.
A new method for estimating the present failure rate of a program is presented. A crude nonparametric estimate of the failure rate function is obtained from past failure times. this estimate is then smoothed by fittin...
ISBN:
(纸本)9780818606205
A new method for estimating the present failure rate of a program is presented. A crude nonparametric estimate of the failure rate function is obtained from past failure times. this estimate is then smoothed by fitting a completely monotonic function, which is the solution of a quadratic programming problem. the value of the smoothed function at present time is used as the estimate of present failure rate. A Monte Carlo study gives an indication of how well this method works.
Engineers of large systems must be concerned with both design of new systems and maintenance of existing systems. A great deal of effort goes into arranging things so that systems may be maintained and extended when n...
ISBN:
(纸本)9780818606205
Engineers of large systems must be concerned with both design of new systems and maintenance of existing systems. A great deal of effort goes into arranging things so that systems may be maintained and extended when needed, and that new systems fit into the context of existing structures. Insight about the support of softwareengineering can thus be derived by examining how other branches of engineering support their version of the processes of *** embarking on a design project an engineer must first determine the customer's need. this is always a complex process, involving modeling of the customer's situation, to determine exactly what is essential and what is accidental. the specifications derived from this analysis are the input to the design process. the specifications may be expressed in varying degrees of formality. though mathematical formalism is to be desired because it is unambiguous and because it can be manipulated precisely, existing mathematical technique is usually inadequate to precisely specify the requirements. this means that the specification phase must be part of the debugging *** design engineer first attempts to meet the specifications with some existing artifact. If this fails, he attempts to synthesize an artifact that meets the specifications by combining the behaviors of several parts, according to some standard plan. For example, in electrical engineering, a complex signal-processing system can often be composed as a cascade of simpler signal-processing components - an engineer knows that the transfer function of a cascade is the product of the transfer functions of the parts cascaded, if the loading is correct. Such design depends on the ability to compute the behavior of a combination of parts from their specifications and a description of how they are combined. Often such analysis must be approximate, with bugs worked out by simulation and debugging of breadboard *** design strategy is greatly enhanced b
Before we can assess the roles and values of AI and the tools of logic in the domain of software we must be sure that we appreciate the nature of this domain. Unfortunately there is a great deal of truth to the statem...
ISBN:
(纸本)9780818606205
Before we can assess the roles and values of AI and the tools of logic in the domain of software we must be sure that we appreciate the nature of this domain. Unfortunately there is a great deal of truth to the statement “software is to the computer as life is to the planet”. thus we know that there are many kinds of software created in many kinds of ways and serving myriad purposes. We can appreciate some of the key issues of life by examining the human being but not, in a completely satisfactory way, by examining his tools. his tools. To understand software we must go beyond the techniques and methodologies we have so carefully and painfully crafted, e.g., high level languages, structured programming, data structures and types, semaphores, functional programming, etc. Adding a few more tools will not change things very much and will probably not tell us much about why software is the way it *** dissatisfaction withsoftware surfaced with operating systems and their offspring. Why? I think it was because they were created to provide an open set of services from a pool of loosely cooperating functions. Furthermore the set of services and the pool of functions would not tolerate a bound in number, intricacy of communication, and efficiency of computer use. I believe that the word “software” obscures the issues that dominate our concerns and I choose the word “organithm” to identify that class of programs we study in softwareengineering. Operating systems are the archetype organithms. Paraphrasing Bernal, an organithm is a partial, continuous, progressive, multiform, and conditionally interactive realization of the potentiality of human thought expressed as computer program. thought, being what it is, an organithm is a large collection of other perhaps more limiting programs held together by useful traffic patterns. While we may say that some of the parts are perfect for their purpose, the collection is never more than adequate and thus always in a state of evolut
the history of advances in programming - the little that there is of it - is the history of successful formalisation: by inventing and studying formalism, by extracting rigorous procedures, we progressed from programm...
ISBN:
(纸本)9780818606205
the history of advances in programming - the little that there is of it - is the history of successful formalisation: by inventing and studying formalism, by extracting rigorous procedures, we progressed from programming in machine code to programming in high level languages (HLLs). Note that before HLLs were sufficiently formalised compilers used to be unreliable and expensive to use, programs could not be ported between machines, and the very use of HLLs was more or less restricted to academia. Observe also that if today a piece of software is still difficult to port it is almost invariably due to a deviation from strict *** many application domains HLLs provide an acceptable linguistic level for program (and system) specification. One does not hear horror stories about computer applications in such domains (physics, astronomy). the expert views of such domains, their descriptive theories, can be easily expressed on the linguistic level of HLL, thus becoming prescriptive theories (specifications) for computersoftware. If it is desired to use computers reliably in domains where this is not the case, then we must try to narrow the gap between the linguistic level on which domain-descriptive theories are formulated and the linguistic level on which programs are prescribed (specified).the programs, as ultimately run, are always formal objects. A rigorous, calculably verifiable relationship may be defined only between formal systems (scientific theories of nature are not calculably verified; they are tested by experiments!). therefore, if we want the programs to reliably satisfy their specifications, the latter must be formal objects too. Or, put it differently: from a natural domain to a formal system there cannot lead an unbroken chain consisting of calculably verified steps only. there must be an interface at which the informality of a natural domain (or its description) comes into contact withthe formality of a computer program (or its specification). S
暂无评论