Abstraction will play a central role in our approach to design simplification by analogical reasoning. First, abstraction will be used to discover similarities between old (already simplified) and new designs. Second, known simplification processes will be abstracted with the purpose of generating simlification plans for new designs. And third, abstraction will allow to generalize over simplification relations, with the goal of building a hierarchy of design simplifications.

Using Abstraction to Discover Similarities Between Designs

Discovering similarities between objects is one of the fundamental phases of analogical reasoning. Similarities allow the transfer of knowledge about the source object to the target object, with the purpose of solving a given problem (in our case design simplification). One way of discovering similarities between two given objects is to build an (usually maximal) abstraction shared by both of those objects. Such an abstraction is usually built by searching for common elements of the objects such as attributes, components and relations between components. While higher level common elements, such as relations suggest stronger similarities between the objects involved, their importance may be altered by the problem to which the analogical reasoning is being applied. For example if the old simplification consisted solely of changing one attribute of a component not involved in any higher level relations in the design, the importance of that shape will be maximal with respect to the simplification (and as a consequence abstarction, mapping and transfer of simplification knowledge).

From the above considerations it should be clear that when searching for similarities between a new design and old designs in the context of a design simplification task, building shared abstractions should preserve elements relevant to the simplification relation (or process) in which the old design is involved. This implies that the abstraction process must be guided by the simplification goal.

To guide design abstraction for discovering similarities between a new design and an old design involved in a simplification relation at a certain level, in the context of simplification at that level we propose process consisting of two phases. First, based on the simplification relation, a set of aspects of the old design, relevant to the simplification are identified. This is done by searching for aspects that are referred to in the simplification relation or process (e.g. a component that has been removed). Using these aspects a first abstraction is built by removing from both the old and the new design all those aspects the are not in the set of relevant aspects, or are not in some relation with one of the relevant aspects. In the second phase we apply a general abstraction building method (e.g. the Structure Mapping Engine) to build a maximal common abstraction for the two designs. Using this two-phase abstraction process we expect to find the highest level similarity between the two designs, relevant to the simplification problem at hand.

We believe that the proposed approach is both needed and useful. On one hand, it is needed because in the context of a specific problem, such as design simplification, set out to be solved by analogical reasoning, the general structural similarities may not be useful. On the other hand, the approach is useful because it may reduce substantially the amount of expensive structure mapping required.

Abstracting Design Simplification Processes

A design simplification relation between two designs can be given by either the description of the differences between those designs, or by a description of the process by which the less simple design was transformed into the simpler one.

In the latter case the description will consist of a sequence of steps, each of them with a set of preconditions, the description of a transformation and a set of postconditions. Given a simplification problem (i.e. a new design and a point of view) for which a relevant similarity has been discovered with such a simplification relation, transferring the simplification knowledge implies building a simplification process for the new design similar to the one given. One way to do this is to generate an simplification plan from the given simplification process description, by abstraction and then instantiating it for the new design. This raises both general and problem specific problems. The general problems are well known for planning and theorem proving by abstraction: how to abstract the plan, what is the appropriate level of abstraction and how to instantiate the plan for a given problem (if possible at all). The most important problems specific to design simplification that we are going to address is how to use the simplification goal to guide the abstraction process.

For addressing the general problems we need to study the nature of designs and design transformations from the perspective of the known theoretical and practical results in the area of problem solving by abstraction.

In building design simplification processes by abstraction and instantiation we identified the following two most important problems: a) how to abstract a design simplification process such that the aspects (steps) relevant to the simpler relation are preserved; b) how to instantiate an abstract simplification plan such that it is both applicable to the simplification problem at hand and such that it preserves the invariants of the design (e.g. functionality, design requirements and constraints).

For preserving the of the steps simplification process relevant to the simplification problem we propose to preserve during the simplification process all the steps that involve (in their preconditions, transformation or postconditions) aspects of the design identified as relevant to the simplification in the mapping phase. This can be achieved by propagating those aspects of the design all through the abstraction process.

Instantiating the abstract simplification plan for the given simplification problem involves, besides the problem of applicability for individual (abstract) steps, the need of propagating the transformations produced to other levels of design. The problem of propagating those transformations may be a hard problem itself (may even require a complete redesign) and it is doubled by the need of preserving design functionality, design requirements and constraints. Nevertheless this note clearly shows the importance of addressing the problem of propagating design transformations across levels of design (as pointed out earlier).

Abstraction for Generalization of Simplification

One important goal of our research is to build a system capable of constructing a collection of design simplifications organized in different abstraction hierarchies. Such a database of design simplification will obviously improve the capability of our system to solve new simplification problems, as the power of any similarity-based problem solving system is heavily dependent on the "experience" it gains by solving a large number of problems. We also expect to be able to extract from such a database patterns and (hopefully) principles of simplification that could be useful in the future.

Since every simplification relation involves two designs and a simplification description (either as differences between the two designs, or as a simplification process) the number of abstractions, and as a consequence abstraction hierarchies that could be built is very large. It is likely that for the purposes we set out only (relatively) few of these abstarction hierarchies will be useful. Thus the problem that we are facing on one hand how to decide which abstractions will lead to useful hierarchies, and on the other hand how to build those hierarchies such that they can be used effectively and efficiently for our goals.

In our opinion building abstraction hierarchies of designs in a design simplification system is not practical. By no means do we deny the importance of such hierarchies in indexing a database of design. We believe however that for simplification purposes designs should be organized based on elements relevant to known simplifications, rather than some general classification. Moreover, since our goal with building a design simplification database is to be able to discover simplification patterns, rules and principles the abstraction hierarchies should be built around simplifications rather than designs.

At this point we see to kinds of abstractions over design simplifications, depending on the way the simpler relations are described: difference abstraction and simplification process abstraction. As pointed out earlier in this section, our purpose is to guide the building of these types of abstractions by the simplification goal.