waashk/dblp huggingface dataset:
can quality graduate software engineering courses really be delivered asynchronously on-line? this article briefly presents a case study in on-line asynchronous course delivery. it sketches the design of a graduate computer science course entitled &ldquo;software design and quality,&rdquo; illustrating an effective approach to distance learning that accommodates learning by doing, team collaboration, and critical thinking. it also shows that there are effective alternatives to &ldquo;canned&rdquo; streaming media presentations that achieve quality on-line education.
recast: reverse engineering from cobol to ssadm specification. the reverse engineering into case technology (recast) method takes the source code for an existing common business-oriented language (cobol) system and derives a no-loss representation of the system documented in a structured systems analysis and design method (ssadm) format. this representation of the system is derived through the use of a series of transformations. the environment within which recast has been developed is described, the stages and steps of the recast method are outlined, and the use of software support tools is discussed. an overview is given of a case study that has been carried out for a live system
a scenario-driven approach to traceability. design traceability has been widely recognized as being an integral aspect of software development. in the past years this fact has been amplified due to the increased use of legacy systems and cots (commercial-off-the-shelf) components mixed with the growing use of elaborate &ldquo;upstream&rdquo; software modeling techniques such as the unified modeling language (uml). the more intensive emphasis on upstream (non-programming) software development issues has, however, widened the gap between software components (e.g., subsystems, modules) and software models (e.g., class diagrams, data flow diagrams), creating the need for a better understanding of the intricacies and interrelationships between the two. this paper demonstrates how observable run-time information of software systems can be used to detect traceability information between software systems and their models. we do this by employing a technique that evaluates the &ldquo;footprints&rdquo; that usage scenarios (e.g., test cases) make during the execution of software systems. those footprints can be compared, resulting in additional traceability information among modeling elements associated with those scenarios. our approach is tool supported.
instant consistency checking for the uml. inconsistencies in design models should be detected immediately to save the engineer from unnecessary rework. yet, tools are not capable of keeping up with the engineers' rate of model changes. this paper presents an approach for quickly, correctly, and automatically deciding what consistency rules to evaluate when a model changes. the approach does not require consistency rules with special annotations. instead, it treats consistency rules as black-box entities and observes their behavior during their evaluation to identify what model elements they access. the uml/analyzer tool, integrated with ibm rational rose™, fully implements this approach. it was used to evaluate 29 models with tens-of-thousands of model elements, evaluated on 24 types of consistency rules over 140,000 times. we found that the approach provided design feedback correctly and required, in average, less than 9ms evaluation time per model change with a worst case of less than 2 seconds at the expense of a linearly increasing memory need. this is a significant improvement over the state-of-the-art.
modeling software failures and reliability growth during system testing. a number of time-domain software reliability models attempt to predict the growth of a system's reliability during the system test phase of the development life cycle. in this paper we examine the results of applying several types of poisson-process models to the development of a large system for which system test was performed in two parallel tracks, using different strategies for test data selection. we show that the reliability growth predicted by non-homogeneous poisson process models was found for only one of these testing strategies. these results imply that the applicability of a reliability growth model to a given software development project will depend on the nature of that project's system test process; they also raise theoretical questions about the assumption of certain statistical properties for failure occurrence during testing.
an evaluation of software test environment architectures. software test environments (stes) provide a means of automating the test process and integrating testing tools to support required testing capabilities across the test process. specifically, stes may support test planning, test management, test measurement, test failure analysis, test development and test execution. the software architecture of an ste describes the allocation of the environment's functions to specific implementation structures. an ste's architecture can facilitate or impede modifications such as changes to processing algorithms, data representation or functionality. performance and reusability are also subject to architecturally imposed constraints. evaluation of an ste's architecture can provide insight into modifiability, extensibility, portability and reusability of the ste. this paper proposes a reference architecture for stes. its analytical value is demonstrated by using saam (software architectural analysis method) to compare three software test environments: protest ii (prolog test environment, version ii), taos (testing with analysis and oracle support), and cite (convex integrated test environment).
static and dynamic structure in design patterns. design patterns are a valuable mechanism for emphasizing structure, capturing design expertise, and facilitating restructuring of software systems. patterns are typically applied in the context of an object-oriented language and are implemented so that the pattern participants correspond to object instances that are created and connected at run-time. this paper describes a complementary realization of design patterns, in which many pattern participants correspond to statically instantiated and connected components.our approach separates the static parts of the software design from the dynamic parts of the system behavior. this separation makes the software design more amenable to analysis, thus enabling more effective and domain-specific detection of system design errors, prediction of run-time behavior, and more effective optimization. this technique is applicable to imperative, functional, and object-oriented languages: we have extended c, scheme, and java with our component model. in this paper, we illustrate our approach in the context of the oskit, a collection of operating system components written in c.
software architecture recovery of a program family. the concept of software architecture has gained a lot of attention and has found its way into the software development process in industry. software architecture recovery focuses on the recovery of architectural information from existing systems. this paper presents a framework for recovering the software architecture of a program family. based on the available system information architectural properties such as safety or system control are recovered using different reverse engineering methods and tools in combination with architectural descriptions. we describe our architecture recovery process and discuss the recovery of system structure as one example of the case study. the framework was developed while working on the recovery of the family architecture of a train control system
experience in teaching a software reengineering course. software engineering curricula emphasize developing new software systems. little attention is given to how to change and modernize existing systems, i.e., the theory and practice of software maintenance and reengineering. this paper presents the author's experience in teaching software reengineering in a masters-level course at university of leicester, uk. it presents the course objectives, outline and the lessons learned. the main lessons are: first, there is a big shortage of educational materials for teaching software reengineering. second, selecting the suitable materials (that balance theory and practice) and the right tool(s) for the level of students and depth of coverage required is a difficult task. third, teaching reengineering using toy exercises and assignments does not convey the practical aspects of the subject. while, teaching with real, even small size, exercises and assignments, is almost infeasible. getting the balance right requires careful consideration and experimentation. finally, students understand and appreciate this topic much more if they have previous industrial experience and when they are presented with real industrial case studies.
improving web application testing with user session data. web applications have become critical components of the global information infrastructure, and it is important that they be validated to ensure their reliability. therefore, many techniques and tools for validating web applications have been created. only a few of these techniques, however, have addressed problems of testing the functionality of web applications, and those that do have not fully considered the unique attributes of web applications. in this paper we explore the notion that user session data gathered as users operate web applications can be successfully employed in the testing of those applications, particularly as those applications evolve and experience different usage profiles. we report results of an experiment comparing new and existing test generation techniques for web applications, assessing both the adequacy of the generated tests and their ability to detect faults on a point-of-sale web application. our results show that user session data can produce test suites as effective overall as those produced by existing white-box techniques, but at less expense. moreover, the classes of faults detected differ somewhat across approaches, suggesting that the techniques may be complimentary.
incorporating varying test costs and fault severities into test case prioritization. test case prioritization techniques schedule test cases for regression testing in an order that increases their ability to meet some performance goal. one performance goal, rate of fault detection, measures how quickly faults are detected within the testing process. in previous work we provided a metric, apfd, for measuring rate of fault detection, and techniques for prioritizing test cases to improve apfd, and reported the results of experiments using those techniques. this metric and these techniques, however, applied only in cases in which test costs and fault severity are uniform. in this paper, we present a new metric for assessing the rate of fault detection of prioritized test cases, that incorporates varying test case and fault costs. we present the results of a case study illustrating the application of the metric. this study raises several practical questions that might arise in applying test case prioritization; we discuss how practitioners could go about answering these questions.
an experiment in software engineering: the architecture research facility as a case study. software developers often complain that researchers in the field of software engineering propose new ideas without testing these ideas in practical applications. the architecture research facility (arf) was developed utilizing several software engineering techniques in order to discover their usefulness in actual software system developments. such techniques as the complete design and documentation of the individual components and interfaces prior to coding, design reviews, code specification in a pseudo-language, code-reading prior to testing, information-hiding modules, run-time error checking mechanisms, strong-typing and the use of support software tools are discussed. we describe the motivation for using the techniques as well as how these techniques were applied to arf's development. staff reactions to using these techniques were favorable although at the time some frustration at the lack of apparent coding progress was felt. our results would prove useful to software developers planning to use new development techniques since we highlight many of these techniques' strengths and weaknesses.
characteristic program complexity measures. twenty program complexity measures are studied with respect to how well they identify the more complex procedures in a software system. the measures have been applied to three large sets of pl/i procedures representing three different types of applications. four of these complexity measures have been found to form a characteristic set. that is, when procedures are kept within reasonable bounds for the four selected measures, they will most likely be within reasonable bounds for all of the other measures. the measures and their interpreted meanings are length&mdash;the quantity of source code, unique operators&mdash;the variety of programming language actions, data difficulty&mdash;the average number of variable appearances, and unique operands&mdash;the variety of constants and variables.
recognizing and responding to "bad smells" in extreme programming. the agile software development process called extreme programming (xp) is a set of best practices which, when used, promises swifter delivery of quality software than one finds with more traditional methodologies. in this paper, we describe a large software development project that used a modified xp approach, identifying several unproductive practices that we detected over its two-year life that threatened the swifter project completion we had grown to expect. we have identified areas of trouble in the entire life cycle, including analysis, design, development, and testing. for each practice we identify, we discuss the solution we implemented to correct it and, more importantly, examine the early symptoms of those poor practices ("bad smells") that project managers, analysts, and developers need to look out for in order to keep an xp project on its swifter track.
a knowledge structure for reusing abstract data types. a knowledge structure for a software library consisting of abstract data types (adts) is defined. both automatically-derived and explicitly-defined relationships are used to impose a knowledge structure on the adts. adts are defined by an adt descriptor and one or more adt implementations. performance characteristics and default implementations are provided to assist users in choosing among alternatives. an explanation is given as to how the knowledge structure helps users find adts of interest, browse through similar adts to investigate alternatives, and build and customize executable software components from adts in the library.
assessing the quality of abstract data types written in ada. as software systems have become more complex, a search for better abstraction mechanisms has led to the use of abstract data types (adts). to more appropriately use adts, however, it is imperative that their properties and characteristics be understood. in this paper we present a method of assessing the quality of adts in terms of cohesion and coupling. we argue that an adt that contains and exports only one domain and exports only operations that pertain to that domain has the best cohesive properties, and we argue that adts that make neither explicit nor implicit assumptions about other adts in the system have the best coupling properties. formal definitions are presented for each of the cohesion and coupling characteristics discussed. their application to ada&reg; packages is also investigated, and we show how a tool can be developed to assess the quality of an ada package that represents an adt. we analyzed nearly one hundred ada adt packages found in ada text books, articles about ada, and student projects and discovered that more than half of them had inferior cohesive characteristics and almost half of them allowed inferior coupling characteristics.
a discriminant metric for module cohersion. the decomposition of a large program into modules can be guided by the use of a property called cohesion, first described by constantine. cohesion is a quality that describes the degree to which the different actions performed by a module contribute to a unified function. however, this technique may be difficult to apply due to the subjective nature of the definitions of levels of cohesion. in this paper a software metric is defined and proposed as a discriminant for classifying modules according to their cohesion. formal properties of the metric are derived which can be used to set the metric value ranges for module classification.
distributed component technologies and their software engineering implications. in this state of the art report, we review advances in distributed component technologies, such as the enterprise java beans specification and the corba component model. we assess the state of industrial practice in the use of distributed components. we show several architectural styles for whose implementation distributed components have been used successfully. we review the use of iterative and incremental development processes and the notion of model driven architecture. we then assess the state of the art in research into novel software engineering methods and tools for the modelling, reasoning and deployment of distributed components. the open problems identified during this review result in the formulation of a research agenda that will contribute to the systematic engineering of distributed systems based on component technologies.
component technologies: java beans, com, corba, rmi, ejb and the corba component model. this one-day tutorial is aimed at software engineering practitioners and researchers, who are familiar with object-oriented analysis, design and programming and want to obtain an overview of the technologies that are enabling component-based development. we introduce the idea of component-based development by defining the concept and providing its economic rationale. we describe how object-oriented programming evolved into local component models, such as java beans and distributed object technologies, such as the common object request broker architecture (corba), java remote method invocation (rmi) and the component object model (com). we then address how these technologies matured into distributed component models, in particular enterprise java beans (ejb) and the corba component model (ccm). we give an assessment of the maturity of each of these technologies and sketch how they are used to build distributed architectures.
implementing incremental code migration with xml. we demonstrate how xml and related technologies can be used for code mobility at any granularity, thus overcoming the restrictions of existing approaches. by not fixing a particular granularity for mobile code, we enable complete programs as well as individual lines of code to be sent across the network. we define the concept of incremental code mobility as the ability to migrate and add, remove, or replace code fragments (i.e., increments) in a remote program. the combination of fine-grained and incremental migration achieves a previously unavailable degree of flexibility. we examine the application of incremental and fine-grained code migration to a variety of domains, including user interface management, application management on mobile thin clients, for example pdas, and management of distributed documents.
software engineering economics: background, current practices, and future directions. the field of software economics seeks to develop technical theories, guidelines, and practices of software development based on sound, established, and emerging models of value and value-creation---adapted to the domain of software development as necessary. the premise of the field is that software development is an ongoing investment activity---in which developers and managers continually make investment decisions requiring the expenditure of valuable resources, such as time, talent, and money. the overriding aim of this activity is to maximize the value added subject to an equitable distribution among the participating stakeholders. the goal of the tutorial is to expose the audience to this line of thinking and introduce the tools pertinent to its pursuit. the tutorial is designed to be self-contained and will cover concepts from introductory to advanced. both practitioners and researchers with an interest in the impact of value considerations in software decision-making will benefit from attending it.this tutorial is offered in conjunction with the fourth international workshop on economics-driven software engineering research (edser-4). the tutorial is meant in part to enable those who would like to participate in the workshop, but who might not possess the requisite background, to come up to speed.
research summary for dynamic detection of program invariants. explicitly stated program invariants can help programmers by identifying program properties that must be preserved when modifying code; invariants also play a number of other valuable roles in program development and evolution. in practice, however, these invariants are usually implicit. an alternative to expecting programmers to fully annotate code with invariants is to automatically infer invariants from the program itself. this research aims to develop and evaluate dynamic techniques for discovering invariants from execution traces. our hypothesis is that such techniques are effective at extracting invariants from programs and that the extracted invariants are useful to programmers. experiments with our prototype implementation provide preliminary support for this hypothesis.
the groupthink specification exercise. teaching students to read and write specifications is difficult. it is even more difficult to motivate specifications---to convince students of the value of specifications and make students eager to use them. this paper describes the groupthink specification exercise. groupthink is a fun group activity, in the style of a game show, that teaches students about specifications (the difficulty of writing them, techniques for getting them right, and criteria for evaluating them), teamwork, and communication. specifications are not used as an end in themselves, but are motivated to students as a means to solving realistic problems that involve understanding system behavior. students enjoy the activity, and it improves their ability to read and write specifications. the two-hour, low-prep activity is self-contained, scales from classes of ten to hundreds of students, and is freely available to other instructors.
quickly detecting relevant program invariants. explicitly stated program invariants can help programmers by characterizing certain aspects of program execution and identifying program properties that must be preserved when modifying code. unfortunately, these invariants are usually absent from code. previous work showed how to dynamically detect invariants from program traces by looking for patterns in and relationships among variable values. a prototype implementation, daikon, accurately recovered invariants from formally-specified programs, and the invariants it detected in other programs assisted programmers in a software evolution task. however, daikon suffered from reporting too many invariants, many of which were not useful, and also failed to report some desired invariants.this paper presents, and gives experimental evidence of the efficacy of, four approaches for increasing the relevance of invariants reported by a dynamic invariant detector. one of them &mdash; exploiting unused polymorphism &mdash; adds desired invariants to the output. the other three &mdash; suppressing implied invariants, limiting which variables are compared to one another, and ignoring unchanged values &mdash; eliminate undesired invariants from the output and also improve runtime by reducing the work done by the invariant detector.