waashk/dblp huggingface dataset:
on executable models for rule-based prototyping. this paper proposes a particular style of executable specifications as a method for rapid prototyping. using a general state-transition framework, system behavior is specified by pattern-oriented rules containing pre- and post-conditions for each transition. the specification method is introduced by two small examples in which a finite-state machine and database are modeled. the main example is an executable model of a backtracking prolog interpreter, which is specified using five transition rules adapted from the formal-semantic literature. all models in the paper are executable and written in prolog; minimal familiarity with prolog is assumed.
deriving test plans from architectural descriptions. the paper presents an approach for deriving test plans for the conformance testing of a system implementation with respect to the formal description of its software architecture (sa). the sa describes a system in terms of its components and connections, therefore the derived test plans address the integration testing phase. we base our approach on a labelled transition system (lts) modeling the sa dynamics, and on suitable abstractions of it, the abstract labelled transition systems (altss). altss offer specific views of the sa dynamics by concentrating on relevant features and abstracting away from uninteresting ones. alts is a tool we provide to the software architect that lets him/her focus on relevant behavioral patterns and more easily identify those that are meaningful for validation purposes. intuitively, deriving an adequate set of functional test classes means deriving a set of paths appropriately covering the alts. we describe our approach in the scope of a real world case study and discuss in detail all the steps of our methodology, from alts identification to test plan generation
the software engineering impacts of cultural factors on multi-cultural software development teams. this paper is based on our experiences in trying to apply software engineering practices to development projects staffed by developers from three distinct cultures; japan, india, and the united states. the development of commercial software products has always been difficult. the standard balancing act that occurs between features, schedules, and resources is at the core of the difficulty. we found that cultural differences also had a large impact on our software engineering work.much has been written and said about software engineering methods that can be applied to development projects to reduce and control these core difficulties. methods that were thought to be "best practices" turned out to be ineffective or very difficult to implement. our understanding of the possible root causes for these difficulties greatly increased when we began to study some of the cultural dynamics within the team. this paper describes our observations in terms of how these cultural factors impacted the software engineering techniques used on the projects.
an overview of the icse 2000 workshop program. past icse attendees will recognize&mdash;with pleasure, we hope&mdash;workshops that have been successful in previous years. indeed, we have tried to balance the program between workshops based on novel and promising ideas, with those strongly continuing the work started in previous icses. in two cases, the program also includes workshops that already have some tradition, but are associated with icse for the first time: the isaw workshop (4th edition) and the dsv-is workshop (7th edition).advanced summaries of many of the workshops follow this overview. for those of you unable to attend a workshop, we hope that this provides a flavor of the interesting discussions that occurred. for those of you who were able to attend, we hope it serves as a reminder of those discussions.we would like to thank pascale le gall (university of evry, france) and premkumar (prem) devanbu (university of california at davis, usa) for helping us in reviewing submissions and making the program. their contributions have been invaluable!
a framework for component deployment testing. component-based development is the emerging paradigm in software production, though several challenges still slow down its full taking up. in particular, the "component trust problem" refers to how adequate guarantees and documentation about a component' s behaviour can be transferred from the component developer to its potential users. the capability to test a component when deployed within the target application environment can help establish the compliance of a candidate component to the customer's expectations and certainly contributes to "increase trust". to this purpose, we propose the cdt framework for component deployment testing. cdt provides the customer with both a technique to early specify a deployment test suite and an environment for running and reusing the specified tests on any component implementation. the framework can also be used to deliver the component developer's test suite and to later re-execute it. the central feature of cdt is the complete decoupling between the specification of the tests and the component implementation.
software product lines: organizational alternatives. software product lines enjoy increasingly wide adoption in the software industry. most authors focus on the technical and process aspects and assume an organizational model consisting of a domain engineering unit and several application engineering units. in our cooperation with several software development organizations applying software product line principles, we have identified several other organizational models that are employed as well. in this article, we present a number of organizational alternatives, organized around four main models, i.e. development department, business units, domain engineering unit and hierarchical domain engineering units. for each model, its characteristics, applicability and advantages and disadvantages are discussed, as well as an example. based on an analysis of these models, we present three factors that influence the choice of the organizational model, i.e. product-line assets, the responsibility levels and the type of organizational units.
relational programming with crocopat. many structural analyses of software systems are naturally formalized as relational queries, for example, the detection of design patterns, patterns of problematic design, code clones, dead code, and differences between the as-built and the as-designed architecture. this paper describes crocopat, an application-independent tool for relational programming. through its efficiency and its expressive language, crocopat enables practically important analyses of real-world software systems that are not possible with other graph analysis tools, in particular analyses that involve transitive closures and the detection of patterns in graphs. the language is easy to use, because it is based on the well-known first-order predicate logic. the tool is easy to integrate into other software systems, because it is a small command-line tool that uses a simple text format for input and output of relations.
software variability management. during recent years, the amount of variability that hasto be supported by a software artefact is growingconsiderably and its management is evolving into amajor challenge during development, usage, andevolution of software artefacts. successful managementof variability in software leads to better customizablesoftware products that are in turn likely to result inhigher market success.the aim of this tutorial is to present softwarevariability management both from a ýproblemsý andfrom a ýsolutionsý perspective by discussingexperiences from industrial practice and from appliedresearch in academia. issues that are addressedinclude, but are not limited to, technological, process,and organizational aspects as well as notation,assessment, design, and evolution aspects.
product-line architectures in industry: a case study. in this paper, a case study investigating the experiences from using product-line architectures is presented involving two swedish companies, axis communications ab and securitas larm ab. key persons in these organizations have been interviewed and information has been collected from documents and other sources. the study identified a collection of problems and issues. the identified problems include the amount of required background knowledge, information distribution, the need for multiple versions of assets, dependencies between assets, use of assets in new contexts, documentation, tool support, management support and effort estimation. issues collected from the case study are the questioned necessity of domain engineering units, business units versus development departments, time-to-market versus asset quality and common features versus feature superset. for each problem, a problem description, an example, underlying causes, available solutions and research issues are identified whereas for each issue the advantages and disadvantages of each side are discussed.
post-process feedback with and without attribute focusing: a comparative evaluation. historically, the identification and correction of inadequacies in the process of software production called process feedback has been a difficult, time-consuming, manual exercise. recently, a methodology for process feedback, called attribute focusing, has been developed. the authors compare post-process feedback with and without attribute focusing to determine how the methodology fares against current practice in post-process correction. five project teams analyzed post-process defect data and made recommendations to improve the quality of a large operating systems product. that data was based on a multiple-choice questionnaire that was completed for every defect in a sample of defects that was chosen by each team. subsequently, the same data was reanalyzed using attribute focusing. the comparison suggests attribute focusing can do at least as well or better than current practice in postprocess analysis, while reducing cost of analysis substantially
designing software architectures for usability. usability is increasingly recognized as a quality attribute that one has to design for. the conventional alternative is to measure usability on a finished system and improve it. the disadvantage of this approach is, obviously, that the cost associated with implementing usability improvements in a fully implemented system are typically very high and prohibit improvements with architectural impact. in this tutorial, we present the insights gained, techniques developed and lessons learned in the eu-ist project status (software architectures that supports usability). these include a forward-engineering perspective on usability, a technique for specifying usability requirements, a method for assessing software architectures for usability and, finally, for improving software architectures for usability. the topics are extensively illustrated by examples and experiences from many industrial cases.
a user's viewpoint on the programmer's workbench. the programmer's workbench boasts a broad set of highly useful features aimed at the application program developer. it claims to be a &ldquo;human-end&rdquo; computer providing tools and services to ease the load on the application system designer, programmer, documenter, tester, and delivery personnel. this paper shows the benefits of using the pwb tools, individually and in combination. through specific examples drawn from the history of a software project, evidence is given that the use of the programmer's workbench can be a major contributing factor in the successful development of a software project.
exception handling: formal specification and systematic program construction. we present an algebraic specification language (pluss) and a program construction method. programs are built systematically from an algebraic specification of the data they deal with. the method was tested on a realistic problem (part of a telephone switching system). in these experiments, it turned out that error handling was the difficult part to specify and to program. this paper shows how to cope with this problem at the specification level and during the program development process.
interactive transformation of java programs in eclipse. implementing large and sweeping changes to software source code can be tedious and error-prone. a conceptually simple change may require a significant code editing effort. integrating scriptable source-to-source program transformations into development environments can assist developers with this task. we present a developer-oriented interactive source code transformation tool for java that addresses this need.
investigating the cost-effectiveness of reinspections in software development. software inspection is one of the most effective methods to detect defects. reinspection repeats the inspection process for software products that are suspected to contain a significant number of undetected defects after an initial inspection. as a reinspection is often believed to be less efficient than an inspection an important question is whether a reinspection justifies its cost. in this paper we propose a cost-benefit model for inspection and reinspection. we discuss the impact of cost and benefit parameters on the net gain of a reinspection with empirical data from an experiment in which 31 student teams inspected and reinspected a requirements document. main findings of the experiment are: a) for reinspection benefits and net gain were significantly lower than for the initial inspection. yet, the reinspection yielded a positive net gain for most teams with conservative cost-benefit assumptions. b) both the estimated benefits and number of major defects are key factors for reinspection net gain, which emphasizes the need for appropriate estimation techniques.
evaluating the accuracy of defect estimation models based on inspection data from two inspection cycles. defect content estimation techniques (dcets), based on defect data from inspection, estimate the total number of defects in a document to evaluate the development process. for inspections that yield few data points dcets reportedly underestimate the number of defects. if there is a second inspection cycle, the additional defect data is expected to increase estimation accuracy. in this paper we consider 3 scenarios to combine data sets from the inspection-reinspection process. we evaluate these approaches with data from an experiment in a university environment where 31 teams inspected and reinspected a software requirements document. main findings of the experiment were that reinspection data improved estimation accuracy. with the best combination approach all examined estimators yielded on average estimates within 20% around the true value, all estimates stayed within 40% around the true value.
lutess: a specification-driven testing environment for synchronous software. several studies have shown that automated testing is a promising approach to save significant amounts of time and money in the industry of reactive software. but automated testing requires a formal framework and adequate means to generate test data. in the context of synchronous reactive software, we have built such a framework and its associated tool-lutess-to integrate various well-founded testing techniques. this tool automatically constructs test harnesses for fully automated test data generation and verdict return. the generation conforms to different formal descriptions: software environment constraints, functional and safety-oriented properties to be satisfied by the software, software operational profiles and software behavior patterns. these descriptions are expressed in an extended executable temporal logic. they correspond to more and more complex test objectives raised by the first pre-industrial applications of lutess. this paper concentrates on the latest development of the tool and its use in the validation of standard feature specifications in telephone systems. the four testing techniques which are coordinated in lutess uniform framework are shown to be well-suited to efficient software testing. the lessons learnt from the use of lutess in the context of industrial partnerships are discussed.
linux as a case study: its extracted software architecture. many software systems do not have a documented system architecture. these are often large, complex systems that are difficult to understand and maintain. one approach to recovering the understanding of a system is to extract architectural documentation from the system implementation. to evaluate the effectiveness of this approach, we extracted architectural documentation from the linux/sup tm/ kernel. the linux kernel is a good candidate for a case study because it is a large (800 kloc) system that is in widespread use and it is representative of many existing systems. our study resulted in documentation that is useful for understanding the linux system structure. also, we learned several useful lessons about extracting a system's architecture.
assessing undergraduate experience of continuous integration and test-driven development. a number of agile practices are included in software engineering curricula, including test-driven development. continuous integration often is not included, despite it becoming increasingly common in industry to code, test, and integrate at the same time. this paper describes a study whereby software engineering undergraduates were given a short intensive experience of test-driven development with continuous integration using an environment that imitated a typical industrial circumstance. assessment was made of students' agile experience rather than of project deliverables, using a novel set of process measures that examined students' participation and performance in agile testing. results showed good participation by student pairs, and clear understanding of agile processes and configuration management. future work will investigate automation of the assessment of continuous integration and configuration management server data.
reuse technologies and their niches. this article characterizes various categories of reuse technologies in terms of their underlying architectures, the kinds of problems that they handle well, and the kinds of problems that they do not handle well. it describes their operational envelopes and niches. the emphasis is on generative reuse technologies.
a series of development methodologies for a variety of systems in korea. to meet the development condition of inside of the country, domestic development methodologies are made with the abbreviation of marmi (magic and robust methodology integrated) in a series of methodologies in south korea. the marmi have the four different methodologies for developing information, object-oriented, component-based, embedded systems. in this paper, the authors describe the feature and structure of each methodology and show our movement for the methodology transfer.
extending the potts and bruns model for recording design rationale. an extension of the model proposed by c. potts and g. bruns (1988) for recording design rationale is presented. the extension consists of enriching the internal structure of justification in the potts and bruns model by making explicit the goals presupposed by arguments, the relations among arguments, and the first-class nature of these relations. the author describes the potts and bruns model briefly. a language whose underlying model extends the potts and bruns model and a system that supports the use of this language are presented. related studies on recording design rationale are briefly discussed. the limitations of the language presented are discussed as further research problems
table: object oriented editing of complex structures. this research adopts the point of view that much of software development is a process of editing complex structures, structures that represent a tightly coupled integration of textual and graphical material. in the context of text and table objects, this research explores a smalltalk-like, object oriented architecture for editors of such complex structures. based on this experience, we propose certain design and operation principles for such editors.
the role of software in successful computer applications. this paper discusses the steps that are required to produce computer programs that satisfactorily implement a computer application. it is a major contention that those steps impacted by structured programming are not the most critical to the development of a successful computer application. successful computer applications depend more heavily on the statement of the problem, the conceptual solution, and software specification. ample precedents for approaches to these more crucial steps can be found in good engineering practice and applied science. heavy emphasis is placed on the purpose and use of software specifications.
platform-independent and tool-neutral test descriptions for automated software testing. current automatic test execution techniques are sensitive to changes in program implementation. moreover, different test descriptions are required by different testing tools. as a result, it is difficult to maintain or port test descriptions. to address this problem, we developed testtalk, a comprehensive testing language. testtalk test descriptions are platform-independent and tool-neutral. the same software test in testtalk can be automatically executed by different testing tools on different platforms. the goal of testtalk is to make software test descriptions, which represent a significant portion of a software project, last as long as the software project.
the concept assignment problem in program understanding. the problem of discovering individual human oriented concepts and assigning them to their implementation-oriented counterparts for a given program is the concept assignment problem. it is argued that the solution to this problem requires methods that have a strong plausible reasoning component. these ideas are illustrated through recovery system called desire. desire is evaluated based on its use on real-world problems over the years
introduction to the wellmade design methodology. an overview of a design methodology called wellmade is presented. wellmade is a synthesis of results obtained from recent research on software engineering and the experience gained at his/phoenix. the principles, procedures, and notation of wellmade are briefly outlined and an example is presented, illustrating the approach for deriving correct programs and the notation for its design specification.
a data structure and drive mechanism for a table-driven simulation system employing multilevel structural representations of digital systems. this paper describes the design and development of a very large fortran simulation program. this discussion includes; the data structure, drive mechanism, and event scheduling for a time-based digital simulation system that could handle functional level models of logical devices. five different types of functional modules are likely to be specified: a) combinational, b) ripple-effect arithmetic, c) register, d) memories, and e) basic logical devices. currently implemented modules include decoders, encoders, universal shift registers, up-down counters, random-access memories, and ripple-carry adders. additional functional modules could be added and basic gates can be intermixed with the functions.