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

Using Abstraction to Dis= cover Similarities Between Designs

Discovering similarities between objects is one of t= he fundamental phases of analogical reasoning. Similarities allow the tra= nsfer 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 a= n abstraction is usually built by searching for common elements of the ob= jects such as attributes, components and relations between components. Wh= ile higher level common elements, such as relations suggest stronger simi= larities between the objects involved, their importance may be altered by= the problem to which the analogical reasoning is being applied. For exam= ple 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 simplifi= cation (and as a consequence abstarction, mapping and transfer of simplif= ication knowledge).

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

To guide design abstraction for discovering similari= ties between a new design and an old design involved in a simplification= relation at a certain level, in the context of simplification at that le= vel we propose process consisting of two phases. First, based on the simp= lification 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 compon= ent that has been removed). Using these aspects a first abstraction is bu= ilt by removing from both the old and the new design all those aspects th= e are not in the set of relevant aspects, or are not in some relation wit= h one of the relevant aspects. In the second phase we apply a general abs= traction building method (e.g. the Structure Mapping Engine) to build a m= aximal common abstraction for the two designs. Using this two-phase abstr= action 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 specif= ic problem, such as design simplification, set out to be solved by analog= ical reasoning, the general structural similarities may not be useful. On= the other hand, the approach is useful because it may reduce substantial= ly the amount of expensive structure mapping required.

Abstracting Design Simplification Processe= s

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 desi= gn 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 descrip= tion of a transformation and a set of postconditions. Given a simplificat= ion problem (i.e. a new design and a point of view) for which a relevant = similarity has been discovered with such a simplification relation, trans= ferring the simplification knowledge implies building a simplification pr= ocess 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 prob= lems are well known for planning and theorem proving by abstraction: how = to abstract the plan, what is the appropriate level of abstraction and ho= w to instantiate the plan for a given problem (if possible at all). The m= ost important problems specific to design simplification that we are goin= g to address is how to use the simplification goal to guide the abstracti= on 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 solvi= ng by abstraction.

In building design simplification processes by abstr= action and instantiation we identified the following two most important p= roblems: a) how to abstract a design simplification process such that the= aspects (steps) relevant to the simpler relation are preserved; b) how t= o instantiate an abstract simplification plan such that it is both applic= able to the simplification problem at hand and such that it preserves the= invariants of the design (e.g. functionality, design requirements and co= nstraints).

For preserving the of the steps simplification proce= ss relevant to the simplification problem we propose to preserve during t= he simplification process all the steps that involve (in their preconditi= ons, transformation or postconditions) aspects of the design identified a= s relevant to the simplification in the mapping phase. This can be achiev= ed by propagating those aspects of the design all through the abstraction= process.

Instantiating the abstract simplification plan for t= he given simplification problem involves, besides the problem of applicab= ility for individual (abstract) steps, the need of propagating the transf= ormations produced to other levels of design. The problem of propagating = those transformations may be a hard problem itself (may even require a co= mplete redesign) and it is doubled by the need of preserving design funct= ionality, design requirements and constraints. Nevertheless this note cle= arly shows the importance of addressing the problem of propagating design= transformations across levels of design (as pointed out earlier).

Abstraction for Generalization of Simplifi= cation

One important goal of our research is to build a sys= tem capable of constructing a collection of design simplifications organi= zed in different abstraction hierarchies. Such a database of design simpl= ification will obviously improve the capability of our system to solve ne= w simplification problems, as the power of any similarity-based problem s= olving system is heavily dependent on the "experience" it gains= by solving a large number of problems. We also expect to be able to extr= act from such a database patterns and (hopefully) principles of simplific= ation that could be useful in the future.

Since every simplification relation involves two des= igns 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) fe= w 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 u= seful hierarchies, and on the other hand how to build those hierarchies s= uch that they can be used effectively and efficiently for our goals.

In our opinion building abstraction hierarchies of d= esigns in a design simplification system is not practical. By no means do= we deny the importance of such hierarchies in indexing a database of des= ign. We believe however that for simplification purposes designs should b= e organized based on elements relevant to known simplifications, rather t= han some general classification. Moreover, since our goal with building a= design simplification database is to be able to discover simplificati= on 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 d= esign simplifications, depending on the way the simpler relations are des= cribed: difference abstraction and simplification process abstraction. As= pointed out earlier in this section, our purpose is to guide the buildin= g of these types of abstractions by the simplification goal.