Reasoning and Synthesis in an Object-Oriented

Reasoning and Synthesis in an Object-Oriented System Jan Komorowski and Mihhail Matskin

Knowledge Systems Group Department of Computer Systems and Telematics The Norwegian Institute of Technology, N-7034 TRONDHEIM, NORWAY email: [email protected], [email protected]

Abstract

This paper considers the problem of providing an Object-Oriented (OO) system with reasoning and program synthesis abilities. We consider an object-oriented knowledge system in which methods are synthesized from speci cations using an intuitionistic propositional calculus and a Proof-As-Program methodology. In order to support reasoning about some dynamic aspects of the OO system, we propose to use a logic language of meta-speci cations and we develop transformations from an object base to the meta-speci cations and the inverse ones. Partial Deduction is used as an optimization technique for deduction in the language of meta-speci cations.

1 Introduction This paper reports on our experience from implementing reasoning and program synthesis in an object-oriented system. Object-oriented systems are successful in structuring and organizing software systems, but, traditionally, they are imperative. Consequently, reasoning in such systems about, for instance, dynamic properties is rather dicult. At the same time the importance of modelling dynamic properties of OO applications is widely recognized. Under dynamic properties we understand ability of an OO application to adequately react to modi cations in an environment. The modi cations may be initiated by sources both external (i.e. by the user) and internal (i.e. by the application itself). In this work we focus on reasoning about dynamic properties caused by internal sources. It is well-known that objects may change their properties by obtaining new values. In this case, the objects may obtain properties of objects of another class. Such feature (called migration in the class hierarchy/lattice) is not supported by a traditional OO system. However, its implementation may have a serious in uence on the behaviour of the application. Another type of internal in uences is satis ability of dependencies expressed as constraints on the behaviour of an application. An additional problem in managing such kind of modi cations is that, in order to preserve the correctness of changing an object base and a class description, we need not only derive sucient conditions for such manipulation, but also satisfy some necessary conditions of the object base and class hierarchy. Here we consider an approach to providing OO systems with (logic-based) means for reasoning. The approach is based on using a language of meta-speci cations. These speci cations are in a form of logic programs and express general knowledge about objects, classes and inheritance structure. Usually, this kind of knowledge is used for managing evolution of applications or expressing dynamic properties of classes and objects. According to the meta-speci cation, which represents sucient and necessary conditions for 

On leave of absence from the Institute of Cybernetics of Estonian Academy of Science, Tallinn

1

correct modi cations, and a current state of an object base, modi cations of an application are performed. The approach is implemented in a framework of NUT system (an OO environment with automatic synthesis of methods [21, 16]). The rest of the paper is organized as follows. In Section 2 we brie y describe an example from the area of modeling logical circuits which is used for illustration of the problem and the approach. In Section 3 we consider a program synthesis in the NUT system, describe logical foundations of the synthesis and consider application of the approach to modeling logical circuits. Section 4 contains a discussion of meta-speci cations: the language, transformations, deduction methods, an optimization technique and the use of meta-speci cations in the design of logical circuits. Section 5 contains an example which demonstrates the use of optimization. Section 6 discusses a cooperation of the program synthesis and description in the meta-speci cation language. The last two sections contain a brief overview of related work, conclusions and perspectives for future work.

2 An example of modeling logical circuits In order to illustrate the problem and our approach to its solution, we consider a simpli ed example from the area of modeling logical circuits containing such elements as inverters, AND elements, OR elements, latch elements, etc. The practical system which was implemented in the NUT system has a much more complicated structure and descriptions. A trivial example of a circuit is presented in Figure 1. & X2 1 X1 Y

h

&

h

h

X3 Figure 1: Schema of a logical circuit We demonstrate, rst, how such circuits can be described in a declarative way in an object-oriented environment and how program(s) for modeling circuits can be synthesized from declarative descriptions (we use intuitionistic propositional calculus as a formal bases for synthesis). Then we consider the following problem. Let us assume logical schema is described and the initial delays of elements are given or calculated. Modeling can be done already for the given delays. If the result of modeling is satisfactory, then the next step considers a realization of the schema using the standard elements produced by industry. This process can be thought of as replacing "abstract" elements by standard industrial elements and doing more precise modeling. The process of replacing elements we consider as changing classes of corresponding objects or dynamical modi cation of the application. We show how modi cation (evolution) of circuits can be also described declaratively and how automatic reasoning about dynamic properties can be done (for this purpose we use classical rst order logic). We use combination of constructive (intuitionistic) and classical logics since the rst one is more suitable for program synthesis and the second one is better for reasoning about dynamic properties. In addition, a combination of these logics provides a good framework for building integrated object-oriented environment.

2

3 A Description of the NUT system 3.1 Program synthesis in an OO framework

Program synthesis provides an OO system with ecient means for declarative representation of an application. In order to implement this features in the NUT system [21, 16] a conjecture is made that all parameters of methods (arguments and results) are state variables.

' $   My class

x1

x2

x3

x4

3   @   B CZ  6 J Z @   B C J Z @   B C ZJ RB @ ~J Z CW   ^ N

f1

&

f2

 

x5

state variables methods

6

input parameters

-

f3

-

%

output parameters

Figure 2: Class in the NUT system

Figure 2 illustrates this feature. It demonstrates that using the conjecture, methods become interconnected as well. This interconnection can be used for performing computations that are not explicitly represented in a class. For example, if a message for computation of x5 from x1 is sent to an object of class My class then a body of the method can be synthesized automatically as a sequence of the following messages: f1, f2, f3. In this case the description of the derived method as well as its body are not presented in the class. However, they can be synthesized if the default method compute is de ned. This method can be applied to objects of any user-de ned class. Another possibility is to specify explicitly an interface of a method and omit its body (for example, by specifying method f4 with x1 as its argument and x5 as the result and the empty body). In a more complicated case one of the arguments of a method can be a description of an interface to another method. In this case, it is possible to derive methods with an implementation (body) structure more complicated than a simple sequence of messages.

3.2 Logical foundations for the program synthesis in NUT

We use a Proof-As-Program approach described in [20] as a logical basis for implementation of program synthesis. There are three main steps in this method:  a class description is translated into logical formulae of a calculus,  a constructive proof of the theorem that there exists a realization of a method from the class is made in the calculus,  a method body is extracted from the proof. The logical calculus used is a fragment of intuitionistic propositional logic. Only propositional formulae of the following form are allowed:

 propositional variables: A, B, ... etc. 3

 unconditional statements A &:::&AK !f B (written equivalently as A !f B )  conditional statements (A !g B )&:::&(An !gn Bn ) ! (C !F g ;:::;gn D ) equivalently (A !g B ) ! (C !F g D ) 1

1

1

1

( 1

)

( )

Propositional variables express the existence (computability) of values of objects. These are true if the corresponding object is computable or it already has a value. The actual value of an object can be computed by means of functions f and F which are implementations of the corresponding formulae. The unconditional statement means that f is a function for computing B from A. The conditional statement means that D can be computed from C by means of F and functions g which compute B from A. The inference rules for the calculus are as follows: ` (A !g B ) ! (C !F (g ) D ); ?; A ` B (b );  ` C (c ) (! ??) ?;  ` D (F (a :b )(c ))

` (A !f B ); ? ` A(a ) (! ?) ? ` B (f (a )) A ` B (b ) ` A !a :b B (! +)

The intuitionistic completeness of these rules was proven in [18]. An informal interpretation of the propositional formulae in terms of class description is as follows. Propositional variables in the formulae correspond to state variables, conditional and unconditional statements correspond to descriptions of interfaces of the methods in a class, f and F correspond to implementations of the methods. Methods with more than one output parameters can be translated into several formulae. Invoking a method without an implementation is considered as a theorem to be proved in the calculus. The theorem is presented as an unconditional statement without a reference to the implementation. In other words, f is omitted in the formula. The implementation of a method is derived from the proof.

3.3 Program synthesis for modeling logical circuits

The class hierarchy for the example described in Section 2 is presented in Figure 3. ELEMENT i P



 

1      

AND

Q k Q Q

6

 

74LS

PP

PP

INV

Q Q Q 

3     

3   

P PP P P

OR

Z } Z Z Z Z

NAND



PP



   

*  

NOR

Z 6 } Z Z Z Z

7400

74S

Figure 3: The class hierarchy for modelling logical circuits 4

A class description in the NUT system can have references to superclasses, state variables (real or virtual), explicit description of methods (denoted by the keyword rel), interfaces of methods and an initialization of state variables. The following six prede ned classes exist: bool, text, numeric, array, program, any. The class ELEMENT contains a description of the state variable DELAY (its meaning is considered in the next Section).

ELEMENT

var

num;

DELAY:

An inverter element which inverts input signal to output is described as the following class INV:

INV

super ELEMENT; vir InINV, OutINV: bool; rel inv: InINV ! OutINV f

OutINV :=

:

g

InINV ;

The class INV contains two virtual components InINV and OutINV of the boolean class and the method inv which has the argument InINV, result OutINV and body described in the brackets. The description of the arguments and results de nes an interface of the method. The AND element with two inputs can be described as the following class:

AND super ELEMENT; vir InAND1, InAND2, OutAND: bool; rel and: OutAND = InAND1 & InAND2; The NUT system also allows methods to be described in the form of Boolean or algebraic expressions. In this case the interface and the body of the method are automatically generated by the system. The classes OR, NAND (not-and) and NOR (not-or) can also be described in a similar way. We consider how an implementation of the method nand can be automatically synthesized. According to the class hierarchy (see Figure 3) the class NAND inherits properties from the classes INV and AND. Its de nition is:

NAND

super INV; super AND; vir InNAND1, InNAND2, OutNAND: bool; rel InAND1=InNAND1; InAND2=InNAND2; OutNAND=OutINV; InINV=OutAND; nand:InNAND1, InNAND2

!

OutNAND

f speci cation g;

The last line in the class NAND describes interface of the method nand to be synthesized. Its body is empty and it can be derived automatically (the keyword speci cation de nes the empty body). Actually, this method implements the function of an element "not-and". However, it is described in a declarative way: "what-to-do" instead "how-todo" that. 5

The approach described in Section 3.2. is used to derive a method for nand. The description of the class NAND is transformed into the following set of logical formulae, where and , inv and assign indicate methods which implement corresponding formulae: InINV !inv OutINV; InAND1, InAND2 !and OutAND; InAND1!assign InNAND1; InNAND1!assign InAND1; InAND2!assign InNAND2; InNAND2!assign InAND2; OutNAND!assign OutINV; OutINV!assign OutNAND; InINV!assign OutAND; OutAND!assign InINV: A theorem to be proved is InNAND1, InNAND2 ! OutNAND. Using these formulae and the inference rules from Section 3.2, the following body of the method will be derived assign (inv (assign (and (assign (InNAND 1); assign (InNAND 2)))))

and in a simpli ed form (using an assignment operator) OutNAND := inv (and (InNAND 1; InNAND 2))

Using the classes NOR and NAND the class SCHEMA, corresponding to the schema of a logical circuit presented in Figure 1, can be described as follows:

SCHEMA

var

bool

X1, X2, X3, Y: ; A1:NAND InNAND1=X1, InNAND2=X2; A2:NAND InNAND1=X1, InNAND2=X3; O1:NOR InOR1=A1.OutNAND, InOR2=A2.OutNAND, OutOR=Y;

A set of implicit methods for the schema may include the following list of methods: Method Method Method Method

1:X1, 2:X1, 3:X1, 4:X1,

! !

fspeci cation g

X2, X3 Y ; X2, X3 A1.OutNAND, A2.OutNAND X2 A1.OutNAND ; X3 A2.OutNAND ;

! !

fspeci cation g fspeci cation g

fspeci cation g;

4 Meta-speci cations

4.1 The need for meta-speci cations

Meta-speci cations are used for managing evolution of applications and for expressing general constraints on integrity and consistency of an application. The meta-speci cation layer is developed on the basis of the following postulates:

 general knowledge about an application (classes, objects, inheritance structure, etc.)

can be expressed as a set of logical formulae (such as Horn clauses),  optimization techniques for inference in the logical language can be used. In particular, partial deduction (partial evaluation of logic programs) [11, 15, 12], in addition to a general resolution method can be applied,  transformations of descriptions of classes and objects into the logical form and vice versa can be de ned.

6

4.2 A Language of meta-speci cations

We establish the following syntactical conventions. Meta-speci cations are represented as Horn-clauses (we use Prolog-like syntax in the NUT system). Variables in the language are pre xed by the symbol . In order to support a connection with an OO system, the following types of predicates have a special interpretation in the language.

De nition 1 (Abstract predicates) An atomic formula which predicate symbol begins with $ is an abstract predicate. It serves to represent abstract associations between objects

Example 1 An inheritance relation is described by a transitive closure of $super abstract predicates:

$inherits ( x ; y ) $super ( y ; x ): $inherits ( x ; y ) $super ( y ; z ); $inherits ( x ; z ):

De nition 2 (Computable predicates) An atomic formula whose predicate symbol begins with ! is a computable predicate, a predicate symbol in a computable predicate is the name of procedure in the OO system (a name of an object of class program). Example 2 A procedure change class can be represented as the following computable

predicate:

!change class (object 1; equilateral triangle ):

De nition 3 (Class predicates ) Atomic formulae has method( x, y), super( x, y) and leaf( x) are class predicates. Class predicates are derived from the inheritance structure. They express belonging of a method to a class, superclass descriptions and terminal nodes in the class hierarchy, correspondingly.

De nition 4 (De ning predicates) All atomic formulae which are not abstract, computable or class predicate are called de ning predicates. The de ning predicates correspond to objects or classes from the object base. The dierent types of predicates allow using dierent tactics and methods for deduction in the metaspeci cation. In order to support the correspondence between de ning predicates and the OO system, a set of transformations is de ned. Examples of de ning predicates and transformations are considered in the next sections.

4.3 Transformations

Our goal is to develop a set of transformations which allow to map selected elements of the OO system into the meta-speci cation language. Elements of the OO system to be mapped have to provide the meta-speci cation with sucient knowledge to reason about a possible evolution of the application. The basic elements of the OO system which we would like to represent in the metaspeci cation are as follows: 7

 Classes: These represent common properties of objects belonging to one class and

are patterns for generating objects. A class contains a description of state variables and methods which can be applied to objects of the class.  Objects: These are instances of a class. They have identity (names) and structure (state variables).  Inheritance: This allows to describe relations between classes. We de ne the following transformations (mappings).

Transformation 1 The names of classes, objects and methods are mapped into constants of the meta-speci cation language.

This trensformation allows to express relations between classes, such as inheritance, or belonging of a method to a class via abstract or class predicates of the meta-speci cation.

Transformation 2 Classes are mapped into de ning predicates where predicate symbols are names of classes, the rst variable in parameters corresponds to the identity of object (i.e., it is the name of object) and the other variables in parameters correspond to state variables.

According to the transformation, classes are non-ground de ning predicates with a special (not interpreted in the meta-speci cation language) meaning of the rst parameter. The transformation preserves structural knowledge about objects of the class. A disadvantage is a possibly long list of parameters in a de ning predicate. A solution to this problem is proposed on the level of the OO language. Namely, it is possible to de ne real and virtual state variables in a class. In this case, only real state variables are represented in a list of parameters of the de ning predicate.

Transformation 3 Objects are mapped into ground de ning predicates where predicate

symbols are names of the corresponding classes of objects, the rst parameter of the de ning predicate is the object name and the other parameters are values of state variables (possibly nil if they do not have a value yet).

The representations of classes and objects in the meta-speci cation language correspond to their OO meaning: classes are patterns for generating objects, and objects are instances of classes.

Transformation 4 Membership of the methods in a class is mapped into a set of ground class predicates has method where the rst parameter is a name of the method and the

second parameter is a name of the class.

Transformation 5 Methods are mapped into functional terms where functors are the names of the methods and the arities are numbers of the arguments of the corresponding methods. Transformation 6 The inheritance structure is mapped into a set of ground class predicates super, where the rst parameter is a name of a subclass and the second parameter is a name of a superclass, and leaf, where the parameter is a name of the terminal class in the class hierarchy.

The above described transformations are called direct transformations. Indirect transformations from de ning and class predicates into elements of the OO system are the inverse of the direct transformations. They are applied when ground de ning predicates or class predicates (dierent from those mapped by direct transformations) are deduced from the meta-speci cation. 8

4.4 Inferences in the meta-speci cation language

The main implemented methods for inference in the meta-speci cation language are topdown and bottom-up deduction. The top-down deduction is applied when a goal is expressed explicitly, for instance, $inherits (equilateral triangle ; triangle ): In case of reasoning about dynamic properties, it is often problematic to express the goal explicitly (in a common case the goal is to deduce everything what is possible). In this case a bottom-up deduction is used. The most important factor which has negative in uence on the eciency of a deduction in the meta-speci cation language is a huge number of atomic formulae generated from a practical OO application by the direct transformations. In order to decrease in uence of this factor, we propose an optimization technique. The main idea of the optimization is to specialize a description in the meta-speci cation language to a particular problem, and to apply the direct transformations according to the specialized description only. We notice that partial deduction is a rather suitable method for implementing such optimizations [6, 17]. Partial deduction is a technique for transformation of logic programs that is sound and complete (under certain syntactic conditions for de nite programs). Partial Deduction (PD) is a source-to-source transformation technique which, given a logic program P and a goal G , produces a new program P 0, which is more speci c and in many cases more ecient than P and has the same set of answer substitutions for the goal G . PD in logic programming is a generalization the unfold transformation method [3] and instantiation. The detailed description of PD can be found in [14]. Here we consider only some de nitions which are necessary for understanding of our approach. In this part we consider a description in the meta-speci cation language as a synonym of logic program. The reader is also referred to [19] for the standard notions of SLD-derivation and SLD-tree. De nition 5 (Partial deduction of an atom) A partial deduction of an atom A in a program P is the set of all non-failing leaves of an SLD-tree of A A. A failing leaf is a selected atom which does not unify with any clause of the program. The assumption that A is an atom can be relaxed to allow a nite set of atoms, A = fA1; : : :; Am g, and a partial deduction of A in P is the union of partial deductions of fA1; : : :; Am g in P . These partial deductions are called residual predicates. De nition 6 (Partial deduction of a program) A partial deduction of P with respect to A is a program P' (also called a residual program) obtained from P by replacing the set of clauses whose heads (the left part of clauses) contain one of the predicate symbols appearing in A with a partial deduction of A in P. In order to allow PD in the meta-speci cation language without (or before) application of the direct transformations the following additional computational rule is de ned. De nition 7 (Computational rule for the meta-speci cations - basic case) Only abstract and computable predicates are selected as the subgoals for uni cation during partial deduction. In case when a goal is not expressed explicitly the opening tactics can be successfully applied. De nition 8 (Opening of predicates) Let A be a nite, independent set of atoms, G a de nite goal, and P a de nite program where P = P1 [ S for some disjoint P1 and S, where S is a set of de nitions of some predicate symbols. We call P1 a source, and S an axiomatization. Let P' be a PD of P with respect to A such that P'[G is A-closed, where the predicates of the atoms selected by computational rule are the predicates of the heads of the of the clauses in S. Such a PD is called opening of predicates S in P with respect to A. 9

Closedness and independence are de ned as follows.

De nition 9 (Closedness) Let S be a set of rst order formulae and A a nite set of atoms. S is called A-closed if each atom in S containing a predicate symbol occurring in an atom in A is an instance of an atom in A. De nition 10 (Independence) Let A be a nite set of atoms. A is independent if no pair of atoms in A have a common instance. Example 3 Let S be a source and A be axioms. S: P( x; y) q ( y ; z ); r ( z ; u ); s ( u ; x ): A: r (a ; b ): r (c ; d ): The residual program obtained by opening the axioms in the source is as follows: p( x ; y ) q ( y ; a ); s (b ; x ): p( x ; y ) q ( z ; c ); s (d ; x ):

Informally, the purpose of opening is to identify where PD steps should take place.

4.5 Sources and axioms in meta-speci cations

The problem of separation of a program to a source and axiomatization in many cases can be solved automatically for PD in the meta-speci cation language.

De nition 11 (Class axiomatization) A subset of clauses from meta-speci cation P

which includes all clauses containing class predicates in their heads is called a class axiomatization.

De nition 12 (De ning axiomatization) A subset of clauses from meta-speci cation P which includes all clauses containing de ning predicates in their heads is called a de ning axiomatization. De nition 13 (Source for meta-speci cation) A subset of clauses from meta-speci-

cation P which does not include clauses from a class axiomatization and de ning axiomatization is called a source for the meta-speci cation.

In case of using opening tactics for PD the computational rule from De nition 7 will not be applied and it will be replaced by the computation rule from De nition 8. 10

4.6 Structuring a description in the meta-speci cation language

In the NUT system an application may have several meta-speci cations. One of them (called global) is valid for all objects and classes of the application and others (called local) are valid for a particular subset of objects only. Clearly, it is convenient to be able to consider local dynamic properties in addition to the global ones. This feature is implemented by associating meta-speci cation to a particular class (local meta-speci cations). In this case, the context where the meta-speci cation is valid will be restricted to the objects of the class. The direct transformations are applied to the state variables of the objects in a similar way as they are applied to ordinary objects. The local meta-speci cations are considered before the global ones. This establishes a priority for consideration of dynamic properties and it allows to describe default and special dynamic properties.

4.7 Modeling logical circuits (via meta-speci cations)

We return now to the initial example and consider a more complicated case of logical circuits in which elements of a circuit may have delays, that is, an output signal is produced some time after getting an input signal. A delay is described by the state variable DELAY in the class ELEMENT (it is also assumed that the corresponding methods in INV, AND and OR classes use this variable). The variable DELAY gets numeric values and expresses delay in nanoseconds (ns). Assume that 7400, 74LS and 74S are the names of the classes corresponding to some standard nand elements produced by industry, and that they realize standard delays 10 ns, 9.5 ns and 3 ns correspondingly. The following rules (P1) in the meta-speci cation layer describe dynamic properties of the objects of the class NAND with respect to the delays (we recall that the symbol $ denotes abstract predicates and the symbol ! denotes computable predicates in the language of meta-speci cations). P1 :

!change class ( Obj ;7400) NAND ( Obj ; DELAY ); !ge ( DELAY ; 10:0); $inherits (7400; NAND ): !change class ( Obj ;74LS ) NAND ( Obj ; DELAY ); !ge ( DELAY ; 9:5); !lt ( DELAY ; 10:0); $inherits (74LS ; NAND ): !change class ( Obj ;74S ) NAND ( Obj ; DELAY ); !lt ( DELAY ; 9:5); $inherits (74S ; NAND ). Let us consider the last rule. It says that for every object of the class NAND if its is less than 9.5 and the class 74S inherits from the class NAND then the class of the object can be changed to the class 74S by the program change class . The last condition about inheritance is required for preserving correctness of the object base after performing modi cations. These rules describe how the object base can be modi ed dynamically. We can also describe general rules (P2) for inheritance relationships as follows. DELAY

11

P2 :

$inherits ( x ; y ) super ( y ; x ): $inherits ( x ; y ) super ( y ; z ); $inherits ( x ; z ): The rules P1 and P2 describe a meta-speci cation for the example. Suppose that object N1 (N1:=new NAND;) has been created and that after some computations its state variable DELAY has been evaluated to 3.5. According to the direct transformations, the following facts P3 and P4 will be automatically generated from the object base and the inheritance lattice, correspondingly; they will be added to the meta-speci cation. P3 : NAND (N 1; 3:5): P4 : super (ELEMENT ; AND ): super (ELEMENT ; INV ): super (ELEMENT ; OR ): super (AND ; NAND ): super (INV ; NAND ): super (OR ; NOR ): super (INV ; NOR ): super (NAND ; 7400): super (NAND ; 74LS ): super (NAND ; 74S ):

The meta-speci cation allows to derive (by a standard such as resolution deduction) the following fact: !change class (N 1; 74S ) The result of the derivation can be used to perform modi cations on the object base (e.g. changing the class of the object N 1 to 74S ). Since class 74S has additional methods and values of state variables (which describe particular properties of the modelled element), a more precise modeling must be done. For the same example, PD allows to make an incremental deduction even in the case when it is not possible to generate all required facts (P3 or P4 ). For example, if an inheritance structure has been described, then the residual predicate change class (using the opening tactics with P1 as a source and P2; P4 as an axiomatization) is as follows. P5 :

!change class ( Obj ;7400) NAND ( Obj ; DELAY ); !ge ( DELAY ; 10:0): !change class ( Obj ;74LS ) NAND ( Obj ; DELAY ); !ge ( DELAY ; 9:5); !lt ( DELAY ; 10:0): 12

!change class ( Obj ;74S ) NAND ( Obj ; DELAY ); !lt ( DELAY ; 9:5): This step can be done after a compilation of classes and before a generation of objects in the OO system. If the object N1:=new NAND; is created then PD with P5 as a source and P6 : NAND (N 1; DELAY ) as an axiomatization gives the following result: P7 : !change class (N 1;7400) NAND (N 1; DELAY ); !ge ( DELAY ; 10:0): !change class (N 1;74LS ) NAND (N 1; DELAY ); !ge ( DELAY ; 9:5); !lt ( DELAY ; 10:0): !change class (N 1;74S ) NAND (N 1; DELAY ); !lt ( DELAY ; 9:5): This step can be done after creating objects and before performing computations. The nal step can be done after assigning value to the state variable DELAY of the object N1. An incremental development of the meta-speci cation by PD allows to specialize it step-by-step and to restrict a context for possible transformations.

5 Focusing deductions In this section we illustrate the ability of the PD technique to restrict a number of possible transformations from an OO system. Let us consider an OO database containing objects of the class person.

person

var mother, father: vir name:text; rel

...

person;

grandf, grandm, children:array of person; add grandm: x grandm ... ;

!

f

g

The database itself contains a large number of objects and one of them is Tom: . . . Rony:= Mary:= John:= Tom:= . . .

new person father=Bill, mother=Lisa; new person father=Bill, mother=Lisa; new person father=Jim, mother=Berta; new person father=John, mother=Mary;

A traditional OO approach does not allow to reason about grandfather or grandmother of a person, however it can be easily expressed in the meta-speci cation language: 13

$parent ( y ; x ) person ( x ; y ; z ): $parent ( z ; x ) person ( x ; y ; z ): $mother ( z ; x ) person ( x ; y ; z ): $father ( y ; x ) person ( x ; y ; z ): $grandm ( x ; z ) $mother ( x ; y ); $parent ( y ; z ): $grandf ( x ; z ) $father ( x ; y ); $parent ( y ; z ): !send message ( z ; add grandf ( x )) $grandf ( x ; z ): !send message ( z ; add grandm ( x )) $grandm ( x ; z ): Suppose that the query for output of Tom's grandmothers is made as the message compute(Tom.grandm). In order to avoid a generation of de ning predicates corresponding to persons from the OO base which are not relevant to the query, rst a PD (with the goal $grandm ( x ; Tom )) is done. It gives the following result. $grandm ( x ;Tom ) person ( y ; t 1; x ); person (Tom ; y ; t 2): $grandm ( x ;Tom ) person ( y ; t 1; x ); person (Tom ; t 2; y ): It is clear from this result that the only required objects to be mapped from the OO base are Tom and his mother and father. After mapping only the required atoms a bottomup inference will be very ecient. The reader may notice that this is similar to a magic sets method as in deductive databases [2].

6 Using meta-speci cations to support program synthesis One of the practical problems with modi cation of an OO application can be formulated as follows. When to start reasoning about possible modi cations and when to change the OO base? There are several possible solutions. The rst one is to analyze possible modi cations and their appilcation after each event (such as, for instance, assigning values) occurred in an OO system. This is the most conservative approach and quite inecient, but it guarantees consistency of the metaspeci cations and the object base at all times. Another possibility is to start reasoning after a user's request (by performing some special command). It is an ecient but non-reliable way (in the case of the internal modi cations of an application, the user may not know about them). A compromise between the rst and the second possibility is to perform changes by need. In the case of the OO system with program synthesis it is implemented as follows. The system begins to reason about possible modi cations (via deduction in the meta-speci cations) when the program synthesis component cannot synthesize a required program. For example, in the case of the above considered example of a database, the query compute(Tom.grandm) can not be solved by the synthesizer. Here a deduction in the meta-speci cation is done. The deduced modi cations are applied to the object base so that processing of the initial query can be attempted by the synthesizer. 14

7 Related work Providing OO systems with declarative features was considered by several authors, for example [4, 7, 22]. Most of these approaches incorporate OO features into declarative languages (basically logic-based languages). An interesting method was implemented in [4] were an OO language was extended with a description of hierarchical constraints. The approach to synthesis of methods, which is implemented in the NUT system, is also relevant to constraint programming (in particular, to statical analysis of constraints). Transformations from an OO representation to a logical representation and vice versa were considered in [8, 1]. In these works the problem is considered as follows. Initial problem is described in an OO language (correspondingly logical language) and then transformed into a logical (correspondingly OO) form as an internal representation. In our approach, we consider both forms in parallel without selecting one of them as an internal form in relation to another. The problem of modifying OO applications is intensivly investigated in the area of Object-Oriented Data Bases (OODB). One of the formal approaches to its solution was touched in the framework of lattice based languages [9, 10, 5]. We do not provide a new semantics for OODB, however the transformations introduced allow to express most of the essential concepts of OO programming in a traditional formalism. Another aspect of supporting modi cations that was investigated in connection with OO systems is change noti cation and change propagation [23]. In order to limit the scope of changes, we use PD as an optimization technique.

8 Conclusions and Perspectives We considered an approach to providing an OO system with means for program synthesis and reasoning. The basic ideas of the approach are: a logic language of meta-speci cations is used for representing OO components, transformations between OO and logic forms, and an optimization technique for deduction in the meta-speci cations. Additional advantages are provided by combining the approach with the program synthesis in an OO framework. We believe that, in this way, the advantages of object-orientation are preserved while the meta-speci cations add a mechanism for reasoning about objects. The approach is partially implemented in the framework of the project of knowledgebased system which uni es NUT [16] and PAL [13] systems. We intend to continue the work on the implementation and experimental application of the approach for practical OO applications. A theoretical research will be done for improvements of several elements of the approach. In particular, further work is needed to investigate problems concerning transformations, incremental speci cations and reusability of residual meta-speci cations.

References [1] M. Bouzeghoub and E. Metais. Semantic modeling of object-oriented databases. In Proc. of the 17th International Conference on Very Large Data Bases, pages 3{14, Barcelona, 1991. [2] F. Bry. Query evaluation in recursive databases: bottom-up and top-down reconciled. Data & Knowledge Engineering, 5(4):289{312, October 1990. [3] R. M. Burstall and J. Darlington. Some transformations for developing recursive programs. Journal of ACM, 24(1):44{67, 1977.

15

[4] B. N. Freeman-Benson and A. Borning. Integrating constraints with an objectoriented language. In ECOOP'92, Proc. of the European Conference on ObjectOriented Programming., volume 615 of Lecture Notes in Computer Science, Utrecht, The Netherlands, June 1992. Springer{Verlag. [5] S. Greco, N. Leone, and P. Rullo. Complex: An object-oriented logic programming system. IEEE Transactions on Knowledge and Data Engineering, 4(4), 1992. [6] H-M. Haav and M. Matskin. Using partial deduction for automatic propagation of changes in oodb. In H. Kangassalo et al., editor, Information Modelling and Knowledge Bases IV: Foundations, Theory and Applications, pages 339{352, Amsterdam, 1993. IOS Press. [7] M. H. Ibrahim and F. A. Cummins. Ksl/logic: Integration of logic with objects. In Proc. of the International Conference on Computer Languages, pages 228{35, New Orleans, March 1990. Los Alamitos, CA: IEEE Comp. Soc. Press. [8] M. Jeusfeld and M. Jarke. From relational to object-oriented integrity simpli cation. In Proc. of the 2nd International Conference on Deductive and OODB, Munchen, Germany, December 1991. [9] M. Kifer and G. Lausen. F-logic: A higher-order language for reasoning about objects, inheritance, and schema. In Proc. of the ACM-SIGMOD International Conference on Management of Data, pages 134{146, June 1989. [10] M. Kifer and J. Wu. A logic for programming with complex objects. Journal of Computer and Systems Sciences, 47:77{120, 1993. [11] J. Komorowski. A Speci cation of An Abstract Prolog Machine and Its Application to Partial Evaluation. PhD thesis, Department of Computer and Information Science, Linkoping Universit y, Linkoping, 1981. [12] J. Komorowski. Elements of a programming methodology founded on partial deduction - p art 1. In Z. Ras, editor, Proc. of the Int. Symp. on Methodologies for Intelligent Systems. North Holland, October 1990. Knoxville, Tennessee. [13] J. Komorowski. Synthesis of programs in the partial deduction framework. In M. Lowry and R. McCartney, editors, Automating Software Design, chapter 15, pages 377{403. AAAI and MIT Press, 1991. [14] J. Komorowski. A prolegomenon to partial deduction. Fundamenta Informaticae, 18(1):41{64, January 1993. [15] J. W. Lloyd and J. C. Shepherdson. Partial evaluation in logic programming. Journal of Logic Programming, 1991. (also, TR-87-09, Dept. of Comp. Sc., U. of Bristol). [16] M. Matskin. The nut system papers. DAIMI MD- 59, Computer Science Department, Aarhus University, Aarhus, The Denmark, December 1991. [17] M. Matskin and Komorowski J. Partial deduction and manipulation of classes and objects in an object-oriented environment. In Proc. of the First Compulog-Network Workshop on Programming Languages in Computational Logic, Pisa, Italy, April 1992. [18] G. Mints and E. Tyugu. Propositional logic programming and the priz system. Journal of Logic Programming, 9(3):179{93, 1990. [19] U. Nilsson and J. Maluszynski. Logic, Programming and Prolog. John Wiley and Sons, 1990. 16

[20] E. Tyugu. Knowledge-Based Programming. Addison-Wesley Publishing Company, 1988. [21] E. Tyugu, M. Matskin, J. Penjam, and P. Eomois. Nut - an object-oriented language. Computers and Arti cial Intelligence, 5(6):521{542, 1986. [22] C. Zaniolo. Object-oriented programming in prolog. In Proc. of the International Symposium on Logic Programming, pages 265{70, Silver Spring, MD, February 1984. IEEE comp. Soc.Press. [23] Stanley B. Zdonik. Version management in an object-oriented database. In Proc. of the Advanced Programming Environments Conference, volume 244 of Lecture Notes in Computer Science, pages 405{422, Utrecht, The Netherlands, 1986. Springer{Verlag.

17