Herman Tromp

Design recovery and maintenance of build systems

The build system forms an indispensable part of any software project. It needs to evolve in parallel with the source code in order to build, test and install the software. Unfortunately, little tool support exists to help maintainers gain insight into the build system, much less to refactor it. In this paper, we therefore present the design and implementation of a re(verse)-engineering framework for build systems named MAKAO. At its heart the framework makes the builds dependency graph available in a tangible way. Aside from visualisation, this enables powerful querying of all build-related data, as well as various filtering techniques to define views on the build architecture. If desired, all this gathered information can be put to use to write aspects for refactoring the build. Afterwards, validation rules can help in assessing failure or success. We applied our implementation on an industrial C system and the Linux 2.6.16.18 kernel, with good results.

Can we refactor conditional compilation into aspects

Systems software uses conditional compilation to manage crosscutting concerns in a very fine-grained and efficient way, but at the expense of tangled and scattered conditional code. Refactoring of conditional compilation into aspects gets rid of these issues, but it is not clear yet for which patterns of conditional compilation aspects make sense and whether or not current aspect technology is able to express these patterns. To investigate these two problems, this paper presents a graphical ``preprocessor blueprint model which offers a queryable representation of the syntactical interaction of conditional compilation and the source code. A case study on the Parrot VM shows that preprocessor blueprints are able to express and query for the four commonly known patterns of conditional compilation usage, and that they allow to discover seven additional important patterns. By correlating each patterns potential for refactoring into advice and each patterns evolution of the number of occurrences, we show that refactoring into advice in the Parrot VM is a good alternative for three of the eleven patterns, whereas for the other patterns trade-offs have to be considered between robustness and fine-grainedness of the advice.

The Evolution of the Linux Build System

Software evolution entails more than just redesigning and reimplementing functionality of, fixing bugs in, or adding new features to source code. These evolutionary forces induce similar changes on the softwares build system too, with far-reaching consequences on both overall developer productivity as well as software configurability. In this paper we take a look at this phenomenon in the Linux kernel from its inception up until present day. We do this by analysing the kernels build traces with MAKAO, our re(verse)-engineering framework for build systems. This helps us in detecting interesting idioms and patterns in the dynamic build behaviour. Finding a good balance between obtaining a fast, correct build system and migrating in a stepwise fashion turns out to be the general theme throughout the evolution of the Linux build system.

Using aspect orientation in legacy environments for reverse engineering using dynamic analysis-An industrial experience report

Preprint of article published in: Journal of Systems and Software (Elsevier), 82 (4), 2009; doi:10.1016/j.jss.2008.09.031 This paper reports on the challenges of using aspect-oriented programming (AOP) to aid in re-engineering a legacy C application. More specifically, we describe how AOP helps in the important reverse engineering step which typically precedes a re-engineering effort. We first present a comparison of the available AOP tools for legacy C code bases, and then argue on our choice of Aspicere, our own AOP implementation for C. Then, we report on Aspicere’s application in reverse engineering a legacy industrial software system and we show how we apply a dynamic analysis to regain insight into the system. AOP is used for instrumenting the system and for gathering the data. This approach works and is conceptually very clean, but comes with a major quid pro quo: integration of AOP tools with the build system proves an important issue. This leads to the question of how to reconcile the notion of modular reasoning within traditional build systems with a programming paradigm which breaks this notion.

Realistic Tolerance Analysis of Microwave Networks

A general formulation of the network tolerance problem is presented. It allows to deal, in a unified way, with all the disturbing effects, that may affect the network response. It can be used for the realistic analysis and design of networks. Possible simplifications of the formulation are discussed.

Exact Calculation of the Uncertainty on the Input Reflection Coefficient of Arbitiviry Two-Ports, Due to Mismatches and Arbitrary Reference Planes

A specific problem of worst case analysis of microwave networks is dealt with. Exact formulas are derived for the upper and lower limits of the amplitude of the input reflection coefficient of an arbitrary two port, in the presence of mismatched source and load and/or arbitrary reference planes. The derivation is based on certain properties of the bilinear transformation.