waashk/dblp huggingface dataset:
goal-oriented software assessment. companies that engage in multi-site, multi-project software development continually face the problem of how to understand and improve their software development capabilities. we have defined and applied a goal-oriented process that enables such a company to assess the strengths and weaknesses of those capabilities. our goals are to help a) to decrease the time and cost to develop software, b)to decrease the time needed to make changes to existing software, c) to improve software quality, d) to attract and retain a talented engineering staff, and e) to facilitate more predictable management of software projects. in response to the variety of product requirements, market needs, and development environments, we selected a goal-oriented process, rather than a criteria-oriented process, to advance our strategy and ensure relevance of the results. we describe the design of the process, discuss results achieved, and present vulnerabilities of the methodology. the process includes both interviews with projects' personnel and analysis of change data. several common issues have emerged from the assessments across multiple projects, enabling strategic investments in software technology. teams report satisfaction with the outcome in that they act on the recommendations, ask for additional future assessments, and recommend the process to sibling organizations.
the design, analysis, and verification of the sift fault-tolerant system. the sift (software implemented fault tolerance) computer is a fault-tolerant computer in which fault tolerance is achieved primarily by software mechanisms. tasks are executed redundantly on multiple, independent processors that are loosely synchronized. each processor is multiprogrammed over a set of distinct tasks. a system of independently accessible busses interconnects the processors. when task a needs data from task b, each version of a votes, using software, on the data computed by the different versions of b. (a processor cannot write into another processor; all communication is accomplished by reading.) thus, errors due to a malfunctioning processor or bus can be confined to the faulty unit and can be masked, and the faulty unit can be identified. an executive routine effects the fault location and reconfigures the system by assigning the tasks, previously assigned to the faulty unit, to an operative unit. since fault-tolerant computers are used in environments where reliability is at a premium, it is essential that the software of sift be correct. the software is realized as a hierarchy of modules in a way that significantly enhances proof of correctness. the behavior of each module is characterized by a formal specification, and the implementation of the module is verified with respect to its specification and those of modules at lower level of the hierarchy. an abstract, markov-like model is used to describe the reliability behavior of sift. this model is formally related to the specifications of the top-most modules of the hierarchy; thus the model can be shown to describe accurately the behavior of the system. at the time of writing, the verification of the system is not complete. the paper describes the design of sift, the reliability model, and the approach to mapping from the system to the model.
a system to improve incorrect programs. this paper presents a system (phenarete) which understands and improves incompletely defined lisp programs, such as those written by students beginning to program in lisp. this system takes, as input, the program without any additional information. in order to understand the program, the system meta-evaluates it, using a library of pragmatic rules, describing the construction and correction of general program constructs, and a set of specialists, describing the syntax and semantics of the standard lisp functions. the system can use its understanding of the program to detect errors in it, to eliminate them and, eventually, to justify its proposed modifications. this paper gives a brief survey of the working of the system, emphasizing some commented examples.
the design of an integrated, interactive and incremental programming environment. we are currently implementing a system to help experienced programmers during the development, implementation and debugging of their programs. this system, built on top of a screen oriented structural editor, offers possibilities of attaching descriptors to every portion of the program and to maintain - simultaneously - different versions of the program being written, including tentative hypothetical versions. it comprises a mecanism to maintain minimal consistency between modified parts of code, the non-modified parts of code and the attached descriptors, as well as an evaluation module functioning in different modes : normal evaluation, symbolic evaluation and checking evaluation. the standard programming aids, such as indexors, pretty printers, trace packages, undo- and history-facilities are generalized to handle the descriptors and unfinished programs as well.
maxims for malfeasant designers, or how to design languages to make programming as difficult as possible. communication with the computer is by artificial languages: programming languages and command languages, as well as ad hoc languages of messages. while many such languages are sufficiently rich to permit proper expression of what must be said, some are so limited or inconsistent that a user must go to needless effort in learning the language and using it to communicate successfully with the computer. as part of the final exam of a course on the design of computer languages for human use, students were asked to suggest what &ldquo;... the language designer can do to make the programming process as difficult as possible.&rdquo; this paper contains some of the more popular responses, annotated with examples from current programming languages and systems.1
high-integrity code generation for state-based formalisms. we are attempting to create a translator for a formal state-based specification language (rsml-&egr;) that is suitable for use in safety-critical systems. for such a translator, there are two main concerns: the generated code must be shown to be semantically equivalent to the specification, and it must be fast enough to be used in the intended target environment. we address the first concern by providing a formal proof of the translation, and by keeping the implementation of the tool as simple as possible. the second concern is addressed through a variety of methods: (1) decomposing a specification into parallel subtasks, (2) providing provably-correct optimizations, and (3) making worst-case performance guarantees on the generated code.
a defense view of software engineering. the department of defense is engaged in a number of management initiatives to improve the cost and quality of defense software systems. a new dod directive 5000.29 provides guidelines for management and technology to promote software engineering in the dod. a major defense-wide initiative is a thrust toward common programming languages. an hol working group has set unified requirements for dod languages and in evaluating existing languages against these requirements. interim common languages are being set. the eventual goal is a minimal number of common high order programming languages for defense systems. these will be provided with rigorous control and extensive support facilities.
an introduction to java 2 micro edition (j2me); java in small things. by now, most people are familiar with the java 2 platform and how sun has grouped java technologies into three editions (standard, micro and enterprise editions). sun introduced the java 2, micro edition (j2me) in june 1999 to address the needs of the consumer electronics and embedded devices community. specifically, the j2me was built for devices with limited power, network connectivity (often wireless), and graphical user interface capabilities. today, the j2me provides a java platform to an incredibly diverse set of devices. generally speaking, this space covers devices with less computing capabilities than a personal computer, yet more capabilities than a smart card.
enterprise javabean architecture and design issues. enterprise javabeans (ejb) technology has become a staple in distributed object and component architectures. however, like most technologies, ejb provides technology tradeoffs that must be weighted by the architect contemplating its use. furthermore, like most technologies, ejb cannot save a poor system design. design issues surrounding an enterprise system, in particular design issues of an ejb system, can be addressed at two levels. ejb design at the &ldquo;macro&rdquo; level is concerned with system architectural issues such as determining whether ejb technology is right for a project, how to model ejbs, and how to select an appropriate ejb server. ejb design from a &ldquo;micro&rdquo; level perspective concentrates on the use and organization of the various ejb types in an application. these &ldquo;micro&rdquo; issues include: when and where to use entity versus session beans, the granularity (fine or coarse) of ejbs, and the impact of the underlying database on bean design.
towards and engineering approach to software design. the software design process is discussed from an engineering point of view. initially, a distinction is made between software design and program design. software design is then described in terms of evolving a system architecture independently of implementation considerations. computation structures are introduced as a means of modeling the dynamic behavior of a software architecture. functional completeness, quality, machine independence, and performance completeness of a design are then used as criteria for engineering design decisions. finally, the basic elements of a system to support the software design process are described.
experiments determining best paths for testing computer program predicates. zeil has developed a vector space measure which indicates those paths which best detect errors in a selected program predicate. this measure has to be applied to a set of paths post hoc, and so the problem is to heuristically characterize those paths which will provide maximal test information about the selected predicate; the problem of selecting the optimal set of paths is np-hard. experiments have been conducted which utilize the vector space criterion to indicate those characteristics of paths which can best be used to test a given predicate. these characteristics will then provide a selection mechanism for an appropriate set of paths. other questions involve the selection of those paths which sufficiently test all the program predicates, and to experimentally identify those program properties which lead to an irreducible error space for a predicate.
workshop description of 5th intl. workshop on scenarios and state machines: models-algorithms-and tools (scesm). scesm '06 is the 5th international workshop on scenarios and state machines: models, algorithms and tools. it is a one day icse '06 workshop. details about scesm '06 may be found at http://ise.gmu.edu/scesm06/.
generating statechart designs from scenarios. this paper presents an algorithm for automatically generating uml statecharts from a collection of uml sequence diagrams. computer support for this transition between requirements and design is important for a successful application of uml's highly iterative, distributed software development process. there are three main issues which must be addressed when generating statecharts from sequence diagrams. firstly, conflicts arising from the merging of independently developed sequence diagrams must be detected and resolved. secondly, different sequence diagrams often contain identical or similar behaviors. for a true interleaving of the sequence diagrams, these behaviors must be recognized and merged. finally, generated statecharts usually are only an approximation of the system and thus must be hand-modified and refined by designers. as such, the generated artifact should be highly structured and readable. in terms of statecharts, this corresponds to the introduction of hierarchy. our algorithm successfully tackles all three of these aspects and will be illustrated in this paper with a well-known atm example.
from scenarios to code: an air traffic control case study. two high profile workshops at oopsla and icse, an ieee computer article by david harel and a growing number of research papers have all suggested algorithms that translate scenarios of a system's behavior into state machines. one of the uses of such algorithms is in the transition from requirements scenarios to component design. to date, however, most efforts have concentrated on the algorithmic details of the proposed translations. less work has been done on evaluating these algorithms on a realistic case study. in this paper, we do exactly that for the algorithm presented in [10]. our study is a component of an air traffic advisory system developed at nasa ames research center.
producing more reliable software: mature software engineering process vs. state-of-the-art technology? a customer of high assurance software recently sponsored a software engineering experiment in which a real-time software system was developed concurrently by two popular software development methodologies. one company specialized in the state-of-the-practice waterfall method rated at a capability maturity model level 4. a second developer employed his mathematically based formal method with automatic code generation. as specified in separate contracts, c++ code plus development documentation and process and product metrics (errors) were to be delivered. both companies were given identical functional specs and agreed to a generous and equal cost, schedule, and explicit functional reliability objectives. at conclusion of the experiment an independent third party determined through extensive statistical testing that neither methodology was able to meet the user's reliability objectives within cost and schedule constraints. the metrics collected revealed the strengths and weaknesses of each methodology and why they were not able to reach customer reliability objectives. this paper will explore the specification for the system under development, the two competing development processes, the products and metrics captured during development, the analysis tools and testing techniques by the third party, and the results of a reliability and process analysis.
supporting diversity with component frameworks as architectural elements. in this paper, we describe our experience with component frameworks within a family architecture for a medical imaging product family. the component frameworks are handled as an integral part of the architectural approach and are an important means to support diversity in the functionality provided by the individual family members.this paper focuses on a particular kind of component framework that has been applied throughout the medical imaging product family. this kind of framework is useful when the various family members are based on the same concepts and the diversity is formed by the differences in the specific instances of these concepts that are present in the family members. these component frameworks have a number of similarities, allowing a standardised approach to their development. they support the division of the system into a generic architectural skeleton, which can be extended with plug-ins to realise specific family members, each with their own set of features.
specification level interoperability. there is an increasing need and desire to develop systems by combining components that are written in different languages and/or that are run on different kinds of machines. success at this depends in large part on the `interoperability'' of the components---that is, the ability of the compon- ents to communicate and work together despite their differing backgrounds. while most previous approaches to interoperability have provided support at the representation level, we are pursuing an approach that will provide support at the specification level. we have developed a model of such sup- port that consists of four components: 1) a `unified type model'', which is a notation for describing the entities to be shared by interoperating pro- grams; 2) `language bindings'', which connect the type models of the lan- guages to the unified type model; 3) `underlying implementations'', which realize the types used by the different interoperating programs; and 4) `automated assistance'', which eases the task of combining components into an interoperability, describe our current prototype realization of the of the specification level approach and our experience with its use, and outline our plans for extending both the approach and its realization.
design evaluation of the compiler generating system mugi. mug1 has been designed and implemented at the technical university of munich. its purpose is the generation of efficient one-pass compilers. the main goals of the design were to offer a readable and easily modifiable compiler description language, and to build an efficiently usable system. moreover the system was to detect certain classes of errors in the description, to allow for an exchange of alternative system modules such as parser generators, and to be portable. the paper discusses the most important design decisions in terms of their implications for attaining the design goals, and compares the resultant system with other compiler generating systems.
software process modeling: a behavioral approach. recently, the software engineering community has focused its attention on the process of software creation and evolution as well as the products of that process. much of this attention has concentrated on modeling the software process. software process models are seen as important vehicles for understanding and reasoning about software creation and evolution activities. software process models may also provide a basis for structuring automated software environments. despite this attention and the advantages to be gained through the use of software process models, however, no wholly satisfactory model of the software process has yet emerged. this paper presents an approach to software process modeling which is based on behavioral descriptions of software development activities. the use of behavioral descriptions makes it possible to describe the software process at any desired level of abstraction and, therefore, assists in accommodating aspects of the process which are poorly understood. this approach also provides the ability to reason about the software process and is sufficiently rigorous to provide a basis for structuring automated software environments. an overview of the model is presented, followed by a formal definition. examples are given to illustrate the application of the model to existing software processes and software methods. finally, the implications of the model for automated software environments are discussed.
das: an automated system to support design analysis. the das is an automated system that supports design verification with the goal of improved software quality and reduced life cycle costs. the integral use of a system engineering language for requirements and design specification, automatic simulation model generation, and user-oriented features are key to the comprehensive approach. this paper briefly describes das' components and its intended application.
computer aided design of software systems. this paper presents results of studies conducted at hughes aircraft company into automated aids for designing large software systems. in particular, we describe two automated tools that have been developed to establish the feasibility of aiding the construction, modification, and goodness testing of large structure charts of software modules. further, we present conclusions of studies which establish software system design engineering principles that are necessary for disciplined software development. we conclude by proposing a system which incorporates these engineering principles and the experience gained from using current automated tools into a forward thinking computer aided software design system.
an intensional approach to the specification of test cases for database applications. when testing database applications, in addition to creating in-memory fixtures it is also necessary to create an initial database state that is appropriate for each test case. current approaches either require exact database states to be specified in advance, or else generate a single initial state (under guidance from the user) that is intended to be suitable for execution of all test cases. the first method allows large test suites to be executed in batch, but requires considerable programmer effort to create the test cases (and to maintain them). the second method requires less programmer effort, but increases the likelihood that test cases will fail in non-fault situations, due to unexpected changes to the content of the database. in this paper, we propose a new approach in which the database states required for testing are specified intensionally, as constrained queries, that can be used to prepare the database for testing automatically. this technique overcomes the limitations of the other approaches, and does not appear to impose significant performance overheads.
a requirements and design aid for relational data bases. a tool is described for defining data processing system requirements and for automatically generating data base designs from the requirements. the generated designs are specific to system r but the mapping rules are valid for the relational model in general and can be adapted to other data models as well. the requirements and design are stored in a system r data base, are cross-referenced with each other, and can be accessed and used for other purposes. the requirements are defined in terms of an organized common-sense semantic model and serve the function of the conceptual schema in the ansi/sparc three schema framework. the tool generates (synthesizes) relational designs that have no redundancy, no update anomalies, and are in 5th normal form. the requirements analysis and design generation procedures are illustrated with a case study.
version control in families of large programs. programs products are quite often families of large and modular programs. modern programming languages support the formulation of such program families only partially. at the time being it is usually not possible to describe different revisions, variants, and versions of single program building blocks and whole programs. this paper presents a proposal for the formulation of such version information as part of the program text. in a newly introduced config part of a program building block the programmer can express: (1) to which versions the building block belongs, and (2) which versions of other building blocks it uses. in this new construct a version is defined as a pair (revision, variant), and a variant as a vector of attribute values. with these language constructs the &ldquo;knowledge&rdquo; about the program versions can be expressed by facts and rules. the representation of this knowledge is adapted to the structure of the program, and the generation of specific program versions can be done automatically. the configuration algorithm has been implemented in prolog, and this prototype implementation has been used for some examples.
defect content estimations from review data. reviews are essential for defect detection and they provide an opportunity to control the software development process. this paper focuses upon methods for estimating the defect content after a review and hence to provide support for process control. two new estimation methods are introduced as the assumptions of the existing statistical methods are not fulfilled. the new methods are compared with a maximum-likelihood approach. data from several reviews are used to evaluate the different methods. it is concluded that the new estimation methods provide new opportunities to estimate the defect content