Identifying the code needed to perform software maintenance and evolution tasks can be very difficult and time consuming for large, complex software systems. A number of techniques have been proposed that employ either static or dynamic analysis to isolate code related to a feature of interest. Static approaches suffer from poor precision by including irrelevant code, while dynamic approaches can suffer from poor recall by excluding relevant code. This paper presents and evaluates a hybrid approach for feature location that augments execution trace analysis with an analysis based on the program structure and associated semantics. This approach improves the completeness of feature location results by expanding the mapping of features to code provided by dynamic analysis in light of the static structure and semantics of the program. The approach is evaluated relative to a well-known dynamic approach using several features in an open source system.

Even in the most well-designed systems, some modules are difficult to maintain due to tangling of multiple concerns within a single monolithic codebase. Software plans have been proposed as an alternative multi-dimensional representation of software in which the programmer can implement independent concerns in separate views of the code. This reduces the difficulty of maintenance by allowing the programmer to view, reason about, and edit the software in a multidimensional manner, where each dimension corresponds to a concern of interest. As promising as this approach may be, there remains a large amount of legacy code that was developed using the traditional monolithic representation. We present an approach for reverse engineering software plans from existing monolithic code using static and dynamic feature location techniques. To evaluate our approach, we applied it to GNU gcc, extracting software plans that separate previously tangled code into multiple concern dimensions.

Software evolution is made difficult by the need to integrate new features with all previously implemented features in the system. We present Spotlight, a prototype editor for software plans that seeks to address this problem by providing the programmer a principled way to separately develop and incrementally integrate independent features.

In traditional random testing, samples are taken from the set of all possible values for the input types. However, for many programs testing effectiveness can be improved by focusing on a relevant subdomain defined implicitly by the program behavior. This paper presents an algorithm for identifying and randomly selecting inputs from implicitly defined subdomains. The algorithm dynamically constructs and refines a model of the input domain and is biased toward sparsely covered regions in order to accelerate boundary identification and uniform coverage. This method has several desirable qualities: (1) it requires no knowledge of the source code of the software being tested, (2) inputs are selected from an approximately uniform distribution across the subdomain, and (3) algorithmic running time overhead is negligible. We present the requirements for a solution and our algorithm. We also evaluate our solution for both an artificial model and a real-world aircraft collision-avoidance program.

A key goal of educators teaching software engineering is to provide students with useful experience that will benefit them after graduation. A key component of this experience is usually a class project that is meant to expose students to the issues associated with real software development efforts. Unfortunately, educators rarely have the time required to manage software projects in addition to their normal pedagogical duties. As a result, many software engineering courses compromise the project experience by reducing the team sizes, project scope, and risk. In this paper, we present an approach to teaching a one-semester software engineering course in which approximately 30 students work together to construct a moderately sized (22 KLOC) software system. This approach provides a more realistic project experience for the students, without incurring significant managerial overhead for the instructor. We present our experiences using the approach for the spring 2004 software engineering course at The College of William and Mary.

Formal methods hold the most potential to raise the level of rigor in the development of software. Unfortunately, they have had only limited penetration into software development practice, due in part to their cost. In this paper, we summarize prior work, performed in collaboration with other researchers, on a specification-based testing approach called boun ed exhaustive testing(BET). We then describe two aspects of current research for reducing the cost of applying this approach in practice: providing developers with easy-to-use test input generation tools, and providing cost-effective alternatives to oracle implementations. By providing software developers with more user-friendly tools and techniques for specification-based testing, we seek to make the BET approach easier to apply in practice, and to encourage the use of formal methods in software development more generally.

The contribution of this paper is an experiment that shows the potential value of a combination of selective reverse engineering to formal specifications and bounded exhaustive testing to improve the assurance levels of complex software. A key problem is to scale up test input generation so that meaningful results can be obtained. We present an approach, using Alloy and TestEra for test input generation, which we evaluate by experimental application to the Galileo dynamic fault tree analysis tool.

This paper presents an improved and generalized version of intermediate language called the failure automaton (FA). By utilizing a common formal semantic domain such as the FA, languages have a precise meaning, the cost of developing and implementing languages is reduced, advances can be more easily shared among languages, and understanding the differences between languages is easier. This new approach to the definition and implementation of reliability modeling languages helps find ambiguity, reduces implementation effort, and allows sharing of language features.

Automated testing typically uses specifications to drive the generation of test inputs and/or the checking of program outputs. Many software systems have structurally complex inputs that cannot be adequately described using simple formalisms such as context-free grammars. In order to generate such inputs, many automated testing environments require the user to express the structure of the input using an unfamiliar formal notation. This raises the cost of employing automated testing, thereby offsetting the benefits gained. We present yagg (yet another generator-generator), a tool that allows the programmer to specify the input using a syntax very similar to that of LEX and YACC, widely used scanner and parser generators. yagg allows the user to bound the input space using several different techniques, and generates an input generator that systematically enumerates inputs. We evaluate the ease of use and performance of the tool relative to a model checker-based generator used in previous research. Our experiences indicate that yagg generators can be somewhat slower, but that the ease-of-use afforded by the familiar syntax may be attractive to users.

Much of the complexity of software arises from the interactions between disparate concerns. Even in well-designed software, some concerns can not always be encapsulated in a module. Research on separation of concerns seeks to address this problem, but we lack an understanding of how programmers conceptualize the notion of a concern and then identify that concern in code. In this work, we have conducted two exploratory case studies to better understand these issues. The case studies involved programmers identifying concerns and associated code in existing, unfamiliar software: GNU's sort.c and the game Minesweeper. Based on our experiences with these two case studies, we have identified several types of concerns and have detailed a number of factors that impact programmer identification of concerns. Based on these insights, we have created two sets of guidelines: one to help programmers identify relevant concerns and another to help programmers identify code relating to concerns.

Even in well-designed software, some concerns can not be easily encapsulated due to their dependence on surrounding context. Such concerns are intermingled with each other and the context code, making it difficult for developers to reason independently about them. We have introduced software plans as an editor-based approach for addressing the tangling of context-dependent concerns. Software plans provide programmers with partial views of the overall software which present only that code related to concerns of current interest. The problem we address is that the traditional sequence-of-characters representation for code is poorly suited for software plans. It lacks the ability to accurately model the concerns associated with a code block, the relationships between code blocks, and the notion of multiple independent plans. In this paper, we present a formally-defined code/concern model that supports these capabilities and more. Using this model, we were able to implement a prototype editing tool that supports software plans.

Group projects are an essential component of many courses. However, accurately assessing the performance of individual students in group work is notoriously difficult. As a result, students often feel that they are not properly rewarded for the effort they expend. In the worst case, some students may take advantage of a poor grading system, exploiting the hard work of their fellow group members. In this paper we present a new approach to grading individuals in group projects. The approach is integrated with the use of a dynamically updated task list for the project. It provides an automatic, quantitative measure of student performance. To evaluate the approach we employed it as part of a software engineering course at The College of William and Mary. Our experience suggests that the approach is flexible, has reasonable overhead, and can scale to group sizes of at

Complex software often has concerns which cut across the modules of the system. Aspect-oriented programming languages such as AspectJ attempt to address this problem by providing a new abstraction for encapsulating such concerns called aspects. Aspects are integrated automatically during compilation with the base code at well-defined join points. This approach is difficult to apply when concerns are highly context-dependent and have complex relationships not supported by the language. In this paper, we propose an alternative approach based on software plans. In this approach, a specialized editor is first used to annotate code segments as belonging to one or more concerns. The user can then specify a limited view of the code, a plan, which consists of some desired subset of the concerns. Using this plan view, the user can directly implement any complex relationship between overlapping, interdependent concerns. We present our approach using a motivating example from the GNU grep tool. We also present our prototype editor implementation.

cally for a given tim equation (ODE) softw an ordinary differential In addition to combinatorial gates, dynamic fault trees use four additional kinds of gates as modeling elements: Sequence Enforcing (SEQ), Functional Dependency (FDEP), Priority And (PAND), and Cold, Warm and Hot Spare (CSP, WSP and HSP). A SEQ gate asserts that component failures can occur only in the order specified by its inputs. An FDEP gate asserts that the failure of its frrst (trigger) input causes the immediate failure of the rest of its (dependent) inputs. A PAND gate indicates that a subsystem fails if the inputs to the gate fail in the specified order. CSP, WSP and HSP gates model primaryspare relationships. Each gate has a primary and one or more spare inputs. If the primary fails and if there are remaining spares, one is selected as the new primary; otherwise the subsystem represented by the gate fails. Using dynamic gates in conjunction with static gates enables the modeling of a wider range of systems than is possible with static gates alone. However, to have justified confidence in the results of a dynamic fault tree analysis, the analyst must have a clear understanding of the intended meanings of dynamic gates and dynamic fault trees composed from them, as well as trust in the software implementation of these constructs. The semantics can be specified in terms of a transformation that maps a given tree to an underlying semantic domain. In this case, we map a tree to a computerized numerical model amenable to solution by numerical analysis techniques. Because the mapping is complex, confidence in it demands that it be broken into an easy to understand composition of easy to understand intermediate representations and transformation steps. Beyond making the transformation understandable in the abstract, confidence in a tool requires trust in the software. Reliably developing flawless software remains beyond current software engineering capabilities. Thus errors remain a real risk. However, there are numerous important software engineering principles, the adherence to which can provide a justification for reasonable confidence in a software system. Perhaps the most important principle of all is to keep software easy to understand and easy to change. One way to do this is to organize the software as an easy to understand composition of easy to understand modular parts, and, furthermore, to base the structure of the software on the structure of the conceptual problem analysis. In our case, this means basing the software architecture on the decomposition of the problem into a sequence of transformations between representations.

Modeling languages and the software tools which support them are essential to engineering. However, as these languages become more sophisticated, it becomes difficult to assure both the validity of their semantic specifications and the dependability of their program implementations. To ameliorate this problem we propose to develop shared semantic domains and corresponding implementations for families of related modeling languages. The idea is to amortize investments at the intermediate level across multiple language definitions and implementations. To assess the practicality of this approach for modeling languages, we applied it to two languages for reliability modeling and analysis. In earlier work, we developed the intermediate semantic domain of failure automata (FA), which we used to formalize the semantics of dynamic fault trees (DFTs). in this paper, we show that a variant of the original FA can serve as a common semantic domain for both DFTs and reliability block diagrams (RBDs). Our experiences suggest that the use of a common semantic domain and a shared analyzer for expressions at this level can ease the task of formalizing and implementing modeling languages, reducing development costs and improving their dependability.

Modeling and analysis is indispensable in engineering. To be safe and effective, a modeling method requires a language with a validated semantics; feature-rich, easy-to-use, dependable tools; and low engineering costs. Today we lack adequate means to develop such methods. We present a partial solution combining two techniques: formal methods for language design, and package-oriented programming for function and usability at low cost. We have evaluated the approach in an end-to-end experiment. We deployed an existing reliability method to NASA in a package-oriented tool and surveyed engineers to assess its usability. We formally specified, improved, and validated the language. To assess cost, we built a package-based tool for the new language. Our data show that the approach can enable cost-effective deployment of sound methods by effective tools.

Domain-specific modeling languages and tools can deliver enormous computational leverage to domain experts. Such languages and tools are most valuable when they have a number of properties. First, language syntax and semantics must be based on abstract, formal specifications if models and results are to be trusted. Second, tools must implement these languages faithfully. Third, development costs must be low because they cannot be amortized in mass markets. Fourth, tools must be powerful in function and easy to use by domain experts. There are strong tensions among these requirements: formal methods, ease of use, powerful function, and faithful implementation conflict with low cost. We present an approach to overcoming this tension based on a pairing of two approaches. First, we apply formal methods, focused narrowly: not on the tool, but only on its language. Second, we use modern shrink-wrapped packages as vehicles for editing models in these languages. We hypothesize that this approach can help resolve the conflict we identified. Domain-specific languages (unlike tools that support them) are often small enough to be reasonable targets for formalization. Using packages as components reconciles cost, function and usability for the rest of the tool. To test this combination, we are applying it in the experimental design of a new dynamic fault tree tool similar to Galileo. The tool implements a new graphical language based on a formal specification of an abstract syntax and semantics of dynamic fault trees. It uses a domainspecific extension of Microsoft Visio for manipulating models. Overall the tool delivers a low-cost capability to edit models having abstractly and precisely specified meanings, unlike other tools in this category.

This addendum elaborates and clarifies aspects of the proposal presented on May 25, 2000. It presents a reformulation of the three research questions in the context of an overarching approach for the development of engineering environments. It also presents a modified description of the work to be performed and the manner in which the work will be used to evaluate the proposed approaches. Section 2 presents the primary research problem and Section 3 presents the proposed approach. Section 4 describes the experimental design. Sections 5 and 6 describe expected data and contributions. Section 7 provides a timeline, and Section 8 summarizes.