The classical plain-text representation of source code is convenient for programmers but requires parsing to uncover the deep structure of the program. While sophisticated software tools parse source code to gain access to the program's structure, many lightweight programming aids such as grep rely instead on only the lexical structure of source code. I describe a new XML application that provides an alternative representation of Java source code. This XML-based representation, called JavaML, is more natural for tools and permits easy specification of numerous software-engineering analyses by leveraging the abundance of XML tools and techniques. A robust converter built with the Jikes Java compiler framework translates from the classical Java source code representation to JavaML, and an XSLT stylesheet converts from JavaML back into the classical textual form. Keywords: Java, XML, abstract syntax tree representation, software-engineering analysis, Jikes compiler. 1 Introduction Since...

Code analysis tools provide support for such software engineering tasks as program understanding, software metrics, testing, and reengineering. In this article we describe GENOA, the framework underlying application generators such as Aria and GEN� � which have been used to generate a wide range of practical code analysis tools. This experience illustrates front-end retargetability of GENOA; we describe the features of the GENOA framework that allow it to be used with different front ends. While permitting arbitrary parse tree computations, the GENOA specification language has special, compact iteration operators that are tuned for expressing simple, polynomial-time analysis programs; in fact, there is a useful sublanguage of the GENOA language that can express precisely all (and only) polynomial-time (PTIME) analysis programs on parse trees. Thus, we argue that the GENOA language is a simple and convenient vehicle for implementing a range of analysis tools. We also argue that the “front-end reuse ” approach of GENOA offers an important advantage for tools aimed at large software projects: the reuse of complex, expensive build procedures to run generated tools over large source bases. In this article, we describe the GENOA framework and our experiences with it.

Object-oriented languages fail to provide software developers with a way to say many of the things about their systems that they need to be able to say. To address this need, we have designed and implemented a language for use with C++ that allows software developers to express a wide variety of constraints on the designs and implementations of the systems they build. Our language is specifically designed for use with C++, but the issues it addresses are applicable to other object-oriented languages, and the fundamental software architecture used to implement our system could be applied without modification to similar constraint languages for other object-oriented programming languages.

Software is multidimensional but the tools that support it are not. The lack of tool support causes the software artifacts representing different dimensions to evolve independently and inconsistently. In order to support the evolution of multidimensional software, an environment must ensure that the different dimensions evolve concurrently. This can be accomplished through an integration framework that maintains consistency of the different dimensions as they evolve. We have build a prototype of such a mechanism by setting up and maintaining constraints among artifacts representing the different software dimensions. This paper describes that prototype and our experiences with it to date. 1

Usually, programming languages are used according to conventions and rules. Although general rules can be enforced by lint-like tools, there is a large class of rules that cannot be built into such tools because they result from particular design decisions or the reuse of existing software. This paper presents a system, called CoffeeStrainer, that statically checks programmer-specified constraints on Java programs. Unlike previous approaches, which only support constraints that apply to definitions of types, CoffeeStrainer additionally supports a second class of constraints which apply to all uses of a type. Both classes of constraints play an important role for object-oriented class libraries and frameworks, which often make assumptions on their correct use.

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

Submitted for publication

The Law of Demeter [4] is accepted as a useful design principle that promotes tightly encapsulated classes and reduced coupling. Principles like this are routinely adopted in real-life projects, however neither the programming languages nor the existing environments provide enough support for effective realization of these principles. It is our thesis that broad structural principles should be formally specified, strictly enforced, and relaxed whenever relaxation is in order. In this paper we show how this can be done under our darwin-E environment using, the Law of Demeter as an illustration. keywords: Law of Demeter, Law-Governed Architecture, Software Engineering Principles, Enforcement. 1 Introduction One often adopts certain broad principles regarding the structure of a system under development. Such principles may reflect one's general programming style, a methodology adopted by the enterprise, or they may be part of the architecture of the system at hand. It is our thesis that...

this paper, we describe gen++, a tool generator for C++ 3.0. gen++ was implemented by attaching the GENOA/GENII

There is an emerging consensus that an explicit architectural model would be invaluable for large evolving software systems, providing them with a framework within which such a system can be reasoned about and maintained. But the great promise of architectural models has not been fulfilled so far, due to a gap between the model and the system it purports to describe. It is our contention that this gap is best bridged if the model is not just stated, but is enforced. This gives rise to a concept enforced architectural model---or, a law --- which is explored in this paper. We argue that this model has two major beneficial consequences: First, by bridging the above mentioned gap between an architectural model and the actual system, an enforced architectural model provides a truly reliable framework within which a system can be reasoned about and maintained. Second, our model provides software developers with a carefully circumscribed flexibility in molding the law of a proje...