Abstract not found

Abstract—Software is multidimensional, but the tools that support it are not. This lack of tool support causes the software artifacts representing different dimensions to evolve independently and to become inconsistent over time. In order to properly support the evolution of software, one must ensure that the different dimensions evolve concurrently. We have built a software development tool, CLIME, that uses constraints implemented as database queries to ensure just this. Our approach makes the tool responsible for detecting inconsistencies between software design, specifications, documentation, source code, test cases, and other artifacts without requiring any of these to be a primary representation. The tool works incrementally as the software evolves, without imposing a particular methodology or process. It includes a front end that lets the user explore and fix current inconsistencies. This paper describes the basis for CLIME, the techniques underlying the tool, the interface provided to the programmer, the incremental maintenance of constraints between these artifacts, and our experiences. Index Terms—Software maintenance, evolution, programming tools. 1

Traditional techniques of traceability detection and management are not equipped to handle evolution. This is a problem for the field of software architecture, where it is critical to keep synchronized an evolving conceptual architecture with its realization in an evolving code base. ArchTrace is a new tool that addresses this problem through a policy-based infrastructure for automatically updating traceability links every time an architecture or its code base evolves. ArchTrace is pluggable, allowing developers to choose a set of traceability management policies that best match their situational needs and working styles. We discuss ArchTrace, its conceptual basis, its implementation, and our evaluation of its strengths and weaknesses in a retrospective analysis of data collected from a 20 month period of development of Odyssey, a large-scale software development environment. Results are promising: with respect to the ideal set of traceability links, the policies applied resulted in 95 % precision at 89 % recall. 1.

An approach is presented that automatically determines if a given source code change impacts the design (i.e., UML class diagram) of the system. This allows code-to-design traceability to be consistently maintained as the source code evolves. The approach uses lightweight analysis and syntactic differencing of the source code changes to determine if the change alters the class diagram in the context of abstract design. The intent is to support both the simultaneous updating of design documents with code changes and bringing old design documents up to date with current code given the change history. An efficient tool was developed to support the approach and is applied to an open source system (i.e., HippoDraw). The results are evaluated and compared against manual inspection by human experts. The tool performs better than (error prone) manual inspection. 1.

Software maintenance has long been one of the most difficult and expensive phases of the software life-cycle. Maintenance is especially difficult for large-scale systems. The more code involved, the larger the chance that there may be unexpected interactions that may cause problems when updates and corrections are made during maintenance. The large number of developers who were probably involved at various points in the system’s creation means that it is likely to be difficult to answer questions about the intent behind the design and implementation decisions. The designer’s, or developer’s, intent can be captured as their Design Rationale. Unlike standard design documentation, which is a description of the final design, Design Rationale (DR) offers more: not only the decisions, but also the reasons behind each decision, including its justification, other alternatives considered, and argumentation leading to the decision. To drive and evaluate our research into using rationale for software maintenance, we are developing the SEURAT (Software Engineering Using RATionale) system to support the software maintainer. This system will present the relevant DR when required and allow entry of new rationale for the modifications. The new DR will then be verified against the existing DR to check for inconsistencies. There are several types of inferences that should be made: structural inferences to ensure that the rationale is complete, evaluation, to ensure that it is based on well-founded arguments, and comparison to rationale collected previously for similar modifications to see if the same reasoning was used.

With the relentless growth in software, automated support for visualizing and navigating software artifacts is no longer a luxury. As packaged software components and middleware occupy more and more of the software landscape, interoperability relationships point to increasingly relevant software change impacts. Packaged software now represents over thirty-two percent of the software portfolio in most organizations Benchmark [40]. While traceability and dependency analysis has effectively supported impact analysis in the past, they fall short today as their webs of dependency information extend beyond most software engineers ability to comprehend them. This paper describes research for extending current software change impact analysis to incorporate software architecture dependency relationships. We discuss how we address the extensive dependency information involved, extending impact analysis using software visualization, and outline our approach to employing the Software Impact Analysis Virtual Environment. 1.

Engineering software systems is a multidisciplinary activity, whereby a number of artifacts must be created — and maintained — synchronously. In this paper we investigate whether production code and the accompanying tests co-evolve by exploring a project’s versioning system, code coverage reports and size-metrics. Three open source case studies teach us that testing activities usually start later on during the lifetime and are more “phased”, although we did not observe increasing testing activity before releases. Furthermore, we note large differences in the levels of test coverage given the proportion of test code.

Software is changing and software evolution is going to change with it. In considering software and the problems of software evolution today we make the tacit assumption that we control the software and hence can control its evolution. Current trends point to a world where we only control a small fraction of our own software and the remainder evolves in unpredictable and uncontrolled ways. Current work in addressing evolution is addressing yesterday’s problems. What we need to prepare ourselves for the coming problems are techniques that can cope with uncontrolled evolution. In this position paper we point out several of the problems that need to be addressed and hint at possible techniques for addressing them.

A traditional obstacle in the use of multiple representations is the need to maintain traceability among the representations in the face of evolution. The introduction of software architecture, and architecture-based development, has brought this need to architectural descriptions and corresponding source code. Specifically, the task is to relate versions of architectural elements to versions of source code configuration items, and to update those relations as new versions of the architecture and source code are produced. We present ArchTrace, a new approach that we developed to address this problem. ArchTrace distinguishes itself by continuously updating traceability relations from architectural elements to code elements through a policy-based extensible infrastructure that allows a group of developers to choose a set of traceability management policies that best match their situational needs and/or working styles. We introduce the high-level approach of ArchTrace, discuss its extensible infra-structure, and present our current set of ten pluggable traceability management policies. We conclude with a retrospective analysis of data collected from a twenty month period of development and maintenance of Odyssey, a component-based software development environment comprised of over 50,000 lines of code. This analysis shows that our approach is promising: with respect to the ideal set of traceability links, the policies applied resulted in a precision of 95 % and recall of 89%.

Abstract not found