FeatureHouse is a general approach to the composition of software artifacts. FeatureHouse is language-independent in that software artifacts written in various languages can be composed, e.g., source code, test cases, models, documentation, and makefiles. Software artifacts are represented as feature structure trees (FSTs), which capture the essence of an artifact's modular structure in the form of a tree. As composition paradigm, FeatureHouse supports two approaches: superimposition and three-way merge. FeatureHouse consists of a tool for superimposition, called FSTComposer, a tool for three-way merge, called FSTMerge, and a plug-in and generation mechanism for integrating new languages automatically, called FSTGenerator. FeatureHouse can be used with the visual development environment FeatureIDE. For more details on the concepts that underlie FeatureHouse, we refer the reader to a corresponding scientific paper (IEEE TSE'13).
FeatureHouse relies on a general model of the structure of software artifacts, called the feature structure tree (FST). FSTs are designed to represent any kind of artifact with a hierarchical structure. An FST represents the essential modular structure of a software artifact and abstracts from language-specific details. For example, an artifact written in Java contains packages, classes, methods, etc., which are represented by nodes in the FST. An XML document (e.g., XHTML) may contain elements that represent the underlying document structure, e.g., headers, sections, paragraphs. A makefile or build script consists of definitions and rules that may be nested.
Each node of an FST has (1) a name that corresponds to the name of the structural element it represents and (2) a type that corresponds to the syntactical category the structural element belongs to. For example, a class Foo is represented by a node Foo of type class. Essentially, an FST is a stripped-down abstract syntax tree: it contains only the information that is necessary for the specification of the modular structure of an artifact. The inner nodes denote modules (e.g., classes and packages) and the leaves store the modules' content (e.g., method bodies and field initializers). The inner nodes representing modules are called non-terminals and the leaves representing the modules' content are called terminals. An excerpt of a class Database is shown below. The class is taken of one of the examples included in the FeatureHouse distribution.
One way to compose software artifacts is to superimpose their corresponding FSTs, denoted by `•'. Two FSTs are superimposed by merging their corresponding nodes, matched by theirs names, types, and relative positions, starting from the root and descending recursively. The figure below illustrates the process of FST superimposition by means of the database example. The artifact BaseDB is superimposed with an artifact called Latches. The composition of both artifacts results in a class Database consisting of the union of the members of its instances in BaseDB and Latches. Basically, Latches adds a new method releaseReadLock and extends the method notifyTriggers of BaseDB via overriding (keyword original defines how two method bodies are composed, which is similar to Java's super).
Currently, FeatureHouse provides support for the superimposition of software artifacts written in Java, C#, C, Haskell, JavaCC, Alloy and UML. The examples section contains some code snippets taken from software artifacts written in Java, Haskell, and JavaCC. More information about superimposition and feature structure trees can be found in a corresponding scientific paper (IEEE TSE'13).
Merging FSTs is much like superimposition, but there are two differences. First, the merge operation receives three FSTs, one representing the base program and two representing two independently developed variants. This is exactly what is done in a three-way merge in version control systems such as CVS, SVN, and Git. The second difference is that the content of terminal nodes, such as method bodies, is not composed by specific composition rules, but by a conventional line-based merge algorithm, known from the domain of version control systems (currently, Linux's merge tool is invoked). If some content cannot be merged automatically, conflicts are displayed in the merged program. More information about merging feature structure trees can be found in a corresponding scientific paper (ESEC/FSE'11).
After downloading the archive, FeatureHouse is ready to use. The command below invokes FeatureHouse, i.e., the superimposition algorithm, in the directory in which it was installed:
The command line option --base-directory specifies where the units of composition are located (if they are not in the same directory than the configuration file that lists the selected composition units).
To invoke the merge algorithm, instead of superimposition, FeatureHouse has to be invoked as follows:
More examples are included in the FeatureHouse distribution.
Beside the binaries, the archive contains the Java sources as well as numerous examples. Each example contains at least one configuration file (e.g., Java/Graph/GraphComp.features) that lists the components that are analyzed and/or composed. The examples contain artifacts written in different languages.
For example, in order to superimpose the Graph example invoke
FeatureHouse has been developed at the University of Passau, Germany in cooperation with the Carnegie Mellon University, USA. For more information about the FeatureHouse project, please contact the developers:
