Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows to distinguish between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units.

A new method is presented for analyzing and reengineering class hierarchies. In our approach, a class hierarchy is processed along with a set of applications that use it, and a fine-grained analysis of the access and subtype relationships between objects, variables and class members is performed. The result of this analysis is again a class hierarchy, which is guaranteed to be behaviorally equivalent to the original hierarchy, but in which each object only contains the members that are required. Our method is semantically well-founded in concept analysis: the new class hierarchy is a minimal and maximally factorized concept lattice that reflects the access and subtype relationships between variables, objects and class members. The method is primarily intended as a tool for finding imperfections in the design of class hierarchies, and can be used as the basis for tools that largely automate the process of reengineering such hierarchies. The method can also be used as a space-optimizing source-to-source transformation that removes redundant fields from objects. A prototype implementation for Java has been constructed, and used to conduct several case studies. Our results demonstrate that the method can provide valuable insights into the usage of the class hierarchy in a specific context, and lead to useful restructuring proposals.

We introduce the notion of iceberg concept lattices...

al rectangle in the table; the lattice is however independent of row or column permutations in the table; small medium large near far moon no moon Venus Earth Mars Jupiter Uranus Neptune Pluto Saturn Mercury Venus Earth Mars Pluto Jupiter Saturn Uranus Neptune near no moon small moon far large medium Figure 1: A table describing properties of planets and the corresponding concept lattice lattice lements are labelled with attributes and objects; object o has attribut a in the table if and only if o appears below a in the lattice; the lattice presents a hierarchical clustering of objects and attributes; suprema factor out comon attributes, e.g. \Mars and Venus are both near"; in ma factor out common objects, e.g. \Pluto is both small and far"; upward arcs are implications, e.g. \Any planet without moon is also near and small". From a large table, such insights are hard to obtain manually. Lattice construction can be exponential in the worst