1. Software Release Engineering
Question: What do Mary Shelley's “Frankenstein” and software systems have in common? Answer: Surprisingly much! Similar to Frankenstein's monster, a software system is essentially built from “dead” artifacts, i.e., textual source code files, and binary libraries and data files. A mysterious build process, consisting of thousands of build tool and compiler invocations, in the right order and on the right artifacts, effectively stitches together a running software system. After medical checks (test suites) and getting dressed (wrapping up into an installable package), the monster heads out to the end user in a sneaky way (push model) or via the front door (pull model). This whole process is called software release engineering.
The beating heart of the software release engineering process is the build process, but, surprisingly, even with current technology the build process is still a mysterious and frustrating resource to work with. In particular, developers have a hard time keeping their projects buildable and configurable at all times, because this requires the build system to "co-evolve" in a synchronized way with the source code.
To understand this phenomenon of co-evolution, we have developed MAKAO, i.e. the Makefile Architecture Kernel featuring Aspect Orientation, to visualize and interactively query the build dependency graph of GNU Make-based build processes. We have used MAKAO, and other tools, to study the design of build processes, the evolution of the Linux kernel and Java-based build processes, and the build maintenance overhead experienced by developers.
2. Software Modularity
Software modularity separates software concerns into self-contained modules that can be composed in flexible, yet safe, ways to form the behaviour of a software system. A software concern can be anything that software stakeholders deem important about a software system, ranging from security and energy consumption, to business rules. In practice, such concerns do not map one-to-one on individual software modules, because of the tyranny of the dominant decomposition.
I rolled into the world of software modularity through the design of an aspect language for C called Aspicere. Inversion of dependencies makes AOSD a key technology to re-engineer legacy systems, e.g. to extract conditional compilation out of the base code. However, while working with Aspicere I experienced first-hand that the structured and uniform software concerns targeted by most modularity approaches, represent only a minority of software concerns. This observation prompted me to study software concerns in general.
We have developed a novel concern mining technique, named COMMIT, that is able to automatically mine for concerns, regardless of their implementation, based on the development history of a project. We have also been working on statistical models that can track the implementation of software concerns over time in order to accurately monitor the health of concerns.
3. Green Software
Energy consumption has been put forward as the greatest challenge for the software industry in the coming decade. Worldwide, software systems are currently hosted on more than 35 million servers across thousands of data centres. In the US, the total energy consumption of data centres in 2006 accounted for 1.5% of all electricity consumption, with a total cost of $4.5 billion. This energy consumption is estimated to increase by 12\% each year, and to double by 2011.
The exploding energy consumption has important implications. First, the total cost of ownership (TCO) of a software system increases significantly. Second, software systems become unreliable because of energy consumption overload. Third, given the limited energy resources on earth, the energy consumption of software threatens the energy reserves left for future generations.
I am currently active on a project to help companies monitor and test their systems' energy consumption. To be continued!
