![](bg3.png)
3 IMPLEMENTATION AND
CURRENT RESULTS
In this section we observe implementation of CBR,
where case library is organized as ontology, for
solving a task of program synthesis and its practical
realization in our prototype system.
3.1 Knowledge Base Organization
Main part of our knowledge base is hierarchy of
concepts, each of them corresponds to some relation
(predicate or specification). The functions are
associated with some concept via a corresponding
predicates. Also, the system uses library of known
programs and every specification description if our
hierarchy associated with one or more programs in
this library. We use the terminology boxes of the
ontology to perform search and to compare
specifications. Hierarchical organization of the
ontology allows to reduce the search time, which is
an important advantage for CBR approach.
3.2 Common Model of Work
The general CBR cycle is represented in our system
in the following way. The work starts with a first
order logic specification of some program. Then the
search of the most similar specification (of already
known program) is performed. At the next stage the
adaptation of the solution – program is performed.
The adapted program is given to user as a result of
work. After user's estimation (whether the solution
was good or not) the appropriate information is
added to system libraries.
3.3 Building of a Function Concept
After receiving a specification from user, the system
should search for similar ones among the known
functions. Thus, our first task is to build a
sufficiently informative description from the
specification function.
Our translation procedure consists of several
steps. First of all, we build disjunctive normal form
of the specification. Secondly, in every disjunction
we perform elimination of function calls. We replace
function calls for each clause D in the obtained
expression S' by new variables (that don't occur free
in the expression before this stage) and add
predicates that corresponds to these functions. After
that we construct an appropriate ALC concept for
the function. In such description we will use special
roles: Contain, ContainNeg, Variant and the family
of roles Param
1
, …, Param
n
. Also, we will use
special concepts, which describe the roles of
variables in the specification: Output, Input
1
, …,
Input
m
, Variable
1
, …, Variable
p
. First of all we
associate every variable in S' with concept of form
(VarRole /\ VarType), where VarRole is one of
special concepts Output, Input1 etc. and VarType is
concept of domain for variable. Then, for each atom
A(x
1
, …, x
k
) we build a description
AC = cA /\ ∃ Param
1
.x
1
/\ … /\ ∃ Param
k
.x
k
,
where cA is concept associated with predicate A and
variables x
1
, …, x
k
replaced with variable
descriptions (as above).
Next step is building of concept for conjunction.
We describe conjunction as set of intersections
between concepts P
1
, …, P
L
, each of them has form
∃ Contain.AC, if corresponding atom contain in
expression with positive polarity, or
∃ ContainNeg.AC – if it has negative polarity. So,
we get conjunction description
CC = ∃ Contain.AC /\ … /\ ∃ ContainNeg.AC' /\ …
If the expression contains a disjunction then we
build descriptions for each disjunct separately and
include them in the common description:
∃ Variant.CC
1
/\ ∃ Variant.CC
n
.
Thus we obtain a complete description of
specification S. This description is used to compare
with other specifications from the case library.
3.4 Difference Concept Construction
To store and use our knowledge about adaptation for
programs we use another kind of descriptions - the
differences concepts, which are also written on ALC
and organized as a hierarchy. Every such concept
describes a subset of adaptation rules which
eliminates the corresponding differences in
specifications and transforms the program text from
the case library. We build such differences
descriptions as concepts with special roles: Add and
Remove or their intersection. Let we have two
concepts: A = A1 /\ … /\ An and B = B1 /\ … /\ Bm.
We construct differences description D in the
following way: D = Add.Bi1 /\ Add.Bik /\
Remove.Aj1 /\ Remove.Ajp where t, 1 ≤ t ≤ k ∄ g,
1 ≤ g ≤ n such that Bit = Ag and t, 1 ≤ t ≤ p
∄ g, 1 ≤ g ≤ m such that Ajt = Bg.
So we describe addition of subconcepts from B,
which doesn't occur in A, and elimination of
subconcepts from A, which are not in B.
3.5 Adaptation
For the similar (but not the same) cases we usually
need to build a concept of differences and to adapt
the solution. Our adaptation mechanism uses
hierarchy of differences concepts and a list of
A CASE-BASED REASONING APPROACH TO PROGRAM SYNTHESIS
337