An Object-Oriented Environment Based On Multi

An Object-Oriented Environment Based On Multi-Layer Application Design Mihhail Matskin Hele-Mai Haav

Computer Science Department Institute of Cybernetics, Estonian Academy of Sciences EE0108 TALLINN, ESTONIA [email protected], [email protected] FAX: +372-2 57 79 01, Phone: +372-2 57 73 16

Abstract This paper considers both an object-oriented multi-layered approach to application design as well as the programming system which implements the methodology presented. The layered approach was motivated by the need for providing support for dierent kinds of knowledge representation in the application design process and sharing the same object base between software components using these representations. The approach presented is based on layered representation of application using logic for description of application concepts on high level of abstraction and incorporating these into an Object-Oriented (OO) environment. In addition to traditional levels of description in OO systems two original layers are introduced: implicit class description and metaspeci cation. These both are based on logic but of dierent kind. The implicit class description uses Intuitionistic Propositional Calculus and metaspeci cation relies on Horn logic as underlaying fundamental framework. The approach proposed is implemented in the NUT system. Keywords. Multi-layered design, incorporating logic into OO technology, application evolution. .

1 Introduction We consider an approach and a programming system for supporting object- oriented technology in application design. The core idea of the approach is based on a multi-layer application representation and on using logic-based methods for supporting the layers and incorporating them into Object-Oriented (OO) technology. A layer for application description is a set of means allowing represent some knowledge concerning an application area. Dierent layers (means) may be required for representation of dierent kinds of knowledge used in an application design process. On the other hand, all these kinds of knowledge representations share the same object base, but describe its dierent aspects. Therefore, the layered approach is a natural viewpoint to problems which arise when several kinds of knowledge must be taken into account and used in an application design. Our goal is to de ne needed layers for an application representation, to incorporate these into an OO environment and allow such environment to support consistency of model and object base of an application. Within the general framework of OO technology presented in this paper, we propose a solution of the following two research problems of OO programming which have been become very important up to now. 1

The rst problem is providing OO systems with features which support declarative style of programming. This increases the generalicity of knowledge representation. Most of existing OO systems support procedural programming style however many promising attempts were made for introducing declarative features into OO systems [?, ?]. The second problem is modelling dynamics and evolution of OO applications. It is very important when developing highly dynamic applications such as from area of design, CAD/CAM , etc. Dealing with managing evolution has been achieved growing importance in the research area of Object-Oriented Data Bases (OODB). It includes work on speci cation of desired evolution of a database schema and objects as well as propagation of schema changes to objects [?, ?, ?]. We think that the similar problem exists not only for OODB but also for general purpose OO systems. Because of growing need for reusable software components class evolution and reorganization are investigated very intensively in the OO programming community. The rest of the paper is organized as follows. In the Section 2 we propose layers for representation of applications in an OO environment. Section 3 and Section 4 contain detailed description of approaches to implementation of the layers for implicit class description and metaspeci cation. These Sections describe logical foundations and language constructions for supporting the layers in an OO system. In Section 5 we discuss principles of using the approach in an application design process on the basis of an example from the area of modelling logical circuits.

2 Layers for representation of applications Usually OO systems support several layers for representing applications. In the classical case object, class and metaclass layers are used for modelling an application in an OO environment. In addition to these traditional levels of abstraction we introduce two special layers for supporting declarative style of representation of an application as well as for increasing expressiveness of an OO approach. Both layers are based on using logic as an underlaying framework for knowledge representation. The rst layer introduced is called implicit class description and it is based on intuitionistic propositional calculus as a formal basis for construction implicit methods from declarative descriptions. Another layer is called metaspeci cation which uses Horn clauses as metalanguage for specifying semantics of dierent kinds of evolution in an application. Figure 1 shows all layers used for an application design in an OO environment proposed here. metaspeci cations implicit class description classes programs

objects

Figure 1: Layers for representation of applications In our approach objects and class-layer have a traditional meaning. An implicit class description is used for declarative representation of an application, especially semantics of methods presented in the classes implicitly and can be derived au2

tomatically on the basis of the class description. In addition to explicit description of state variables and applicable methods the implicit class description allows non-procedural (implicit) representation of methods as well. An implicit method could be derived from already existent class decription automatically. A trivial example of an implicit method is as follows. Let us have a class "square" containing two methods - the rst one computes sides of square from its perimeter and the second one computes a diagonal from sides. The sequential application of these two methods allows to compute diagonal from a perimeter and it could be considered as an implicit method which could be derived by a system and which is not presented explicitely. It will be demonstrated that in general case such derivation of implicit methods may provide a user with powerful tools for declarative problem description. Actually, languages for class and implicit class description can be joined (as it is done in the NUT system). In this case the derivation of implicit methods can be considered as a feature provided by default in a metaclass. However, we methodologically separate class and implicit class description layers. We also assume that the layer of implicit class descriptions is supported by inheritance mechanism as it is done for classes. Traditional metaclass is not presented explicitely in our approach, but some its features can be modelled by means of metaspeci cations. A metaspeci cation may be used for representing general knowledge about objects, classes, inheritance structure and implicit class descriptions. Usually, this kind of knowledge is used for managing evolution of applications or expressing application dependent rules for checking consistency of object base. According to the metaspeci cation that represents sucient and neccesary conditions for correct modi cations and a current state of the object base the modi cations on an application will be performed. The Horn-clauses are used for writing metaspeci cations. Correspondence between metaspeci cation and class or object layers is implemented by means of transformations (classes and objects could be transformed into predicates and vice versa). The program layer is used for representing programs written in traditional programming languages (in the NUT system the C language is used). Programs forming this layer can be used as bodies of explicit methods which interface is described explicitely in classes.

3 Implicit Class Description 3.1 Meaning of implicit class description The implicit class description layer provides an OO environment with ecient means for declarative representation of an application. Time complexity of derivation of implicit methods used in this layer is linear in usual case. The implicit class description contains explicit description of state variables, methods and reference to superclass(es) (as a traditional class) and implicit description of methods. For implementation of this feature we have made a conjecture that all parameters of methods (arguments and results) are state variables.

3

' $      

 

My class

x1

x2

x3

x4

3   @   B 6 J CZ 2 Z @  2 B J C Z @ 2  B ZJ C RB @ ~J Z CW 2  ^ 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 explicitely presented in a class. For example, if a message for computation of x5 from x1 is sent to object of class "My class" then a body of the method can be synthesized automatically as a sequence of the following message sendings: 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 derived 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 explicitely an interface of a method but omit its body (for example specifying a method f4 with x1 as its argument and x5 as a result and empty body). In more complicated case one of arguments of an explicit method can be a description of interface of an implicit method. In this case it is possible to derive methods with implementation (body) structure more complicated than a simple sequence of message sendings. An implicit class description supports a declarative representation of applications however it does not prohibit to use classes in traditional way i.e. by performing explicitely described methods on corresponding objects.

3.2 Logical foundations for derivation of implicit methods We use an approach described in [?] as a logical basis for implementation of implicit method derivation. It is based on the following three steps to be performed:

 a declarative implicit class description is translated into logical formulas of a calculus,  a proof of derivability of implicit method is made in the calculus,  an implicit method body is extracted from the proof. The logical calculus used is a fragment of intuitionistic propositional logic and it allows only propositional formulas of the following form:

 propositional variables: A, B, ... etc.  unconditional statements A &:::&AK !f B or A !f B 1

4

 conditional statements (A !g B )&:::&(An !gn Bn ) ! (C !F g ;:::;gn D) or (A !g B ) ! (C !F g D) 1

1

1

( 1

)

( )

Propositional variables express the existance (computability) of values of objects and these are true if corresponding object is computable or 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 formulas. The unconditional statement means that f is function for computing B from A. The conditional statement means that D can be computed from C by means of F and functions g that compute B from A. The inference rules for the calculus are as follows: ` (A !g B) ! (C !F (g) V ); 0; A ` B(b);6 ` C (c) (! 00) 0; 6 ` V (F (a:b)(c))

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

The intuitionistic completeness of the rules has been proved in [?]. Meaning of propositional formulas in terms of class description can be de ned as follows. Propositional variables in formulas correspond to state variables, conditional and unconditional statements correspond to descriptions of interfaces of methods in a class, functions f and F correspond to implementations of methods. Methods with more than one output parameters can be translated into several formulas. Invoking implicit method is considered as a theorem to be proved in the calculus (this theorem is presented as an unconditional statement without reference to implementation - f is omitted in the formula). The implementation of an implicit method is derived from the proof.

4 Metaspeci cations 4.1 Meaning of metaspeci cations Metaspeci cations are used for managing evolution of applications and expressing general constraints on integrity and consistency of an application. It is well-known that objects may change their properties (for example, by obtaining new values). In this case according to a problem-oriented semantics the objects may obtain properties of objects of another class. For instance, an object of class "triangle" after getting equal values for all its sides obtains features of "equilateral-triangle" class. The problem is that in order to preserve the correctness of changing object base and a class description we need not only derive sucient conditions for such manipulation, but also satisfy some necessary conditions of object base and class hierarchy. Another types of dynamic modi cations are propagation of changes of class description to existent objects and adaptation of objects to changes in environment. The metaspeci cation layer is developed on the basis of the following proposals:

 general knowledge about an application (classes, objects, inheritance structure, etc.) can be expressed as a set of logical formulas (in our case Horn clauses are used), 5

 special techniques for inference in the logical language can be used. In particular, partial evaluation of logic programs (partial deduction) [?, ?, ?] in addition to general resolution method can be applied,

 transformation of descriptions of classes and objects into predicate form and vice versa can be de ned.

4.2 Language and transformations Metaspeci cations are represented as the following formulas: A0 A1; :::; An where Ai , i=0,...,n are atomic formulas. An atomic formula consists of the predicate symbol and a list of parameters. The following types of predicates are used.

 Abstract predicates are used to represent abstract associations between objects. For example, $inherits(x,y) $super(y,x) $inherits(x,y) $inherits(x,z),$super (y,z) Abstract predicates are denoted by symbol $.

 Computable predicates are names of preprogrammed procedures (they are denoted by !): !change class(x,'eguilateral triangle')

 De ning predicates are derived from a class description or from object base. They

correspond to some objetcs or class description. For this purpose transformations have to be de ned from predicate form to objects or classes and vice versa. These transformations are described in [?]. Here we consider basic idea of such transformations (it is similar to that presented in [?]). A class description corresponds to nonground atomic formula, where predicate symbol corresponds to a class name and list of parameters corresponds to state variables. Objects correspond to ground atomic formulas, where predicate symbol denotes the class of object, the rst parameter is the name of object and other parameters are state variables. These correspondences are implemented by means of automatic transformations of class descriptions and objects into de ning predicate formulas and vice versa.

 Inheritance predicates are #super(x,y) and #leaf(x). They are derived from inheritance structure and correspond to superclass descriptions and terminal nodes in class hierarchy.

5 An example of multi-layered application design We consider a simpli ed example from the area of modelling logical circuits containing such elements as inverters, AND elements, OR elements, latch elements, etc. The class hierarchy for the example is presented in gure 3.

6

ELEMENT

1        

AND

Q k Q Q

6

INV

 3   Q  Q  Q 

Z } Z

NAND

 3     

74LS

Z 6 } Z Z

7400

P i PP PP PP PP PP P

OR

Z

Z Z

* 8 8 8 8 8 8 8

NOR

Z Z

74S

Figure 3: Class hierarchy for modelling logical circuits On the basis of the example we illustrate the implicit class descriptions, the metaspeci cation and, partially, program layers. Object and class layers are assumed to be traditional for OO systems. For representation of the example we use language constructions of the NUT programming system, where the above discussed approach to multi-layered application design is implemented [?, ?]. In the NUT system dierent layers are supported by dierent programming components.

5.1 Using implicit class description An implicit class description in the NUT system may have references to superclasses, state variables (real or virtual), explicit description of methods (denoted by the keyword rel), interfaces of implicit methods and initialisation of state variables. The following six prede ned classes exist: bool , text , numeric , array , prog , any An inverter element which inverts input signal to output can be described as the following class INV:

INV

super ELEMENT; var InINV, OutINV: bool; rel inv: InINV ! OutINV f OutINV := : InINVg;

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

AND super ELEMENT; var InAND1, InAND2, OutAND: bool; rel and: OutAND = InAND1 & InAND2; The NUT system also allows explicit methods be described in the form of Boolean or algebraic expressions. For example, the method and is written in such a form. In this case the interface and the body of the method are generated by the system. 7

The classes OR, NAND (not-and) and NOR (not-or) can be described in a similar way. We consider more complicated description of the class NAND that is not very practical, but it allows to follow the derivation of an implicit method. The real bene t of implicit method derivation will be demonstrated later when considering schema description. According to the class hierarchy (see gure 4) the class NAND (not-and) inherits properties from the classes INV and AND and can be described as follows:

NAND

super INV; super AND; var 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 implicit method nand. Its body is omitted and can be derived automatically (keyword speci cation de nes empty body). Actually, this method realizes the function of the not-and element. However it is described in declarative way: what to do instead how to do that. For derivation of the method nand the approach described in Section 3.2. is used. The description of the class NAND can be transformed into the following set of logical formulas (and, inv and assign indicate methods which implement corresponding formulas): 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: The theorem to be proved is InNAND2 ! OutNAND. Using the set of formulas and inference rules from Section 3.2, the following body of the method will be derived assign(inv (assign(and(assign(InNAND1); assign(InNAND2)))))

or in a simpli ed form OutNAND := inv (and(InNAND1; InNAND2))

Using the classes NOR and NAND the class SCHEMA corresponding to the schema of the logical circuit can be described as follows:

SCHEMA

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

The class SCHEMA is a declarative description of the schema presented in gure 4.

8

X2 X1

&

&

h

1

h

h

Y

X3 Figure 4: Schema of logical circuit A set of implicit methods for the schema may include the following list of methods: Method 1:X1, X2, X3 ! Y fspeci cation g; Method 2:X1, X2, X3 ! A1.OutNAND, A2.OutNAND fspeci cation g; Method 3:X1, X2 ! A1.OutNAND fspeci cation g; Method 4:X1, X3 ! A2.OutNAND fspeci cation g; For some practical application a derived methods may include a number of message sendings. For example we have application (it is modelling of hydraulic systems) where automatically derived implicit method contains 1335 message sendings.

5.2 Using metaspeci cations Let us consider a more complicated case of logical circuits, where elements of a circuit may have delays (output signal is produced some time after getting input signal). A delay can be expressed by the state variable DELAY in the class ELEMENT (it is also assumed that corresponding methods in INV, AND and OR classes use this variable). The variable DELAY gets numeric values and expresses a delay in nanoseconds (ns). Assume that 7400, 74LS and 74S are names of classes corresponding to standard not-and elements produced by industry and they realize standard delays 10 ns, 9.5 ns and 3 ns correspondingly. The following rules on metaspeci cation layer may describe an evolution of objects of the class NAND with respect to delays. !change class(Obj, '7400') NAND(Obj,DELAY),!ge(Obj.DELAY,10.0), $inherits('7400','NAND'). !change class(Obj, '74LS') NAND(Obj,DELAY),!ge(Obj.DELAY,9.5), !lt(Obj.DELAY,10.0),$inherits('74LS','NAND'). !change class(Obj, '74S') NAND(Obj,DELAY),!lt(Obj.DELAY,9.5), $inherits('74S','NAND'). Let us consider the last rule. It says that if there exists an object of the class NAND, its DELAY is less than 9.5 and the class 74S inherits from the class NAND then the class of the object can be changed to class 74S by a program "change class". The last condition about inheritance is required for preserving correctness of an object base after performing modi cations. These rules describe how an object base can be dynamically modi ed. We can also describe general rules for inheritance relationships as follows. $inherits(x,y) $inherits(x,y)

#super(y,x) $inherits(x,z),#super (y,z)

De nitions of the predicate !change class together with the rules for inheritance relationships describe a metaspeci cation for the example. Suppose that the object N1 (N1:=new 9

NAND;) has been created and after computations its state variable DELAY has been evaluated to 3.5. According to transformations described in Section 4.2 the following facts will be automatically generated from the object base and the inheritance lattice and added to the metaspeci cation: NAND('N1',3.5) . #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 metaspeci cation allows to derive the following fact: !change class('N1', '74S') The result of the derivation can be used for performing safe modi cations on object base. After modi cation under consideration the object N1 obtains features of the class 74S and we can see that our application changes dynamically. In the current version of the NUT system the traditional resolution method is applied, however we found that partial evaluation methods (partial deduction) have more advantages in our case [?]. They allow to make incremental inference even in the case when it is not possible to generate all required facts. For example, if an inheritance lattice has been described and the corresponding set of predicates is used then the result for partial evaluation of the !change class predicates is as follows. !change class(Obj, '7400') NAND(Obj,DELAY),!ge(Obj.DELAY,10.0). !change class(Obj, '74LS') NAND(Obj,DELAY),!ge(Obj.DELAY,9.5), !lt(Obj.DELAY,10.0). !change class(Obj, '74S') NAND(Obj,DELAY), !lt(Obj.DELAY,9.5). If the object N1 is created in addition to the result of partial evaluation of the !change class predicate then this set of rules gives the following result after partial evaluation: !change class('N1', '7400') !ge(N1.DELAY,10.0). !change class('N1', '74LS') !ge(N1.DELAY,9.5),!lt(N1.DELAY,10.0). !change class('N1', '74S') !lt(N1.DELAY,9.5). The nal step can be done after assigning value to the state variable DELAY of the object N1. Application of partial evaluation supports eciency and exibility of manipulating metaspeci cation.

5.3 Using program layer The program layer allows programs written in C language to be used in implementations of methods. For example, a C-program "and modeling" can be refered in body of the method "and" as follows: and:DELAY, InAND1, InAND2 OutAND fOutAND:=and modeling(DELAY,InAND1,InAND2)g; Using program layer is supported by convertion of parameters from C to NUT and vice versa. 10

6 Conclusions and Perspectives The approach to multi-layer application design considered in this paper is implemented in the NUT programming system. The rst implementation of the system was developed as a part of the Soviet new generation computer project START in 1988. After that the NUT system was improved and installed for various Unix environments at the Institute of Cybernetics of the Estonian Academy of Sciences. During the last year the NUT system is developed as a common work between the Institute of Cybernetics and the Royal Institute of Technology in Stockholm. At the same time the approach and the system were used for a number of experiments in dierent areas (data modelling, educational systems, systems for solving engineering problems) and for designing two applications. One of them is simulating hydraulic systems. Another is modelling of logical circuits (a very simpli ed and restricted fragment of this application was used in the paper for demonstration of the approach). Our experience of using the approach demonstrates that multi-layer application design and integration of the layers into uni ed environment allows the creation of software components that adequately model the application area. We also understood that the current tools for supporting metaspeci cation layer have to be improved. The further work is needed to investigate problems concerning transformations, incremental speci cations and reusability of partially evaluated metaspeci cations.

7 Acknowledgements We would like to thank Mari Kopp, Jaan Penjam, Kestutis Urbaitis, Peep Eomois, Mait Harf, Benjamin Volozh and Alexander Schmoundak, who implemented dierent parts of the NUT system. Our special thanks are due to Enn Tyugu for advising and supporting the work.

References [1] G. Ariav. Temporally Oriented Data De nitions: Managing Schema Evolution in Temporally Oriented Databases. Data & Knowledge Engineering 6, 1991, pp 451-467. [2] B. N. Freeman-Benson, A. Borning. Integrating Constraints with an Object-Oriented Language. In: ECOOP'92, European Conference on Object-Oriented Programming. Proceedings, Lecture Notes in Computer Science vol. 615. Springer-Verlag, 1992. [3] H-M. Haav, M. Matskin. Using Partial Deduction for Automatic Propagation of Changes in OODB. In: Information Modelling and Knowledge Bases IV: Foundations, Theory and Applications, IOS Press, Amsterdam, 1993 (in print). [4] M. H. Ibrahim, F. A. Cummins. KSL/Logic: Integration of Logic with Objects. In Proc. 1990 Int. Conf. on Comp. Lang., New Orleans, March 1990, pp 228-35. Los Alamitos, CA: IEEE Comp. Soc. Press, 1990. [5] G. M. Lohman, B. Lindsay, H Pirahesh, K. B. Scaiefer. Extentions to Starburst: Objects, Types, Functions and Rules. Communication of ACM, 34 1991, 94-110. [6] J. W Lloyd and J. C. Sheperdson. Partial Evaluation in Logic Programming. Technical Report CS-87-09, Department of Computer Science, University of Bristol, England, 1987. 11

[7] J. Komorowski. A Speci cation of an Abstract Prolog Machine and Its Application to Partial Evaluation. PhD thesis, Linkoping University, Sweden, 1981. [8] J. Komorowski. Elements of a Programming Methodology Founded on Partial Deduction (Part 1). In : Proceedings of the Fifth International Symposium on Methodologies for Intelligent Systems, Tennessee, 1990, North-Holland, pp 514. [9] M. Matskin. The NUT System Papers. Computer Science Department, Aarhus University, DAIMI MD-59, December 1991, 53 p. [10] G. Mints, E. Tyugu. Propositional Logic Programming and the PRIZ system. J. Logic Programming, 9(3), pp 179-93, 1990 [11] G. T. Nguyen, D. Rieu, J. Escamilla. An Object Model for Engineering Design. In: ECOOP'92, European Conference on Object-Oriented Programming. Proceedings, Lecture Notes in Computer Science vol. 615. Springer-Verlag, 1992. [12] E.Tyugu, M. Matskin, J. Penjam, P Eomois. NUT - an Object-Oriented Language. Computer Science and Arti cial Intelligence, No 6, 1986, pp 521-542. [13] C.Zaniolo. Object-Oriented Programming in Prolog. In Proc. 1984 int. Symp. on Logic Programming, Atlantic City, Feb. 1984, pp 265-70. Silver Spring, MD: IEEE comp. Soc.Press, 1984.

12