Object-Oriented Modeling of Rule-Based Programming

Transcription

1 Object-Oriented Modeling of Rule-Based Programming Xindong Wu and Xiaoya Lin Department of Software Development, Monash University 900 Dandenong Road, Melbourne, VIC 3145, Australia Proceedings of the 9th Intl Conference on Software Engineering and Knowledge Engineering Madrid, Spain, June 18-20, 1997, Abstract A domain expertise always comprises a set of concepts and the logical relationships between them. In rule-based programming, rules which describe logical relationships are the fundamental knowledge units, and concepts are embedded in the rules. Objectoriented programming takes the opposite way; objects or classes which are used to describe concepts are the essential knowledge units, and all operations regarding an object are bound together into the object s definition. By embedding rules within objects, this paper designs a factor-centered representation language, Factor++, which models the rule-based paradigm into object-oriented programming. We demonstrate that Factor++ provides facilities to represent all the information that can be represented in rule schema + rule body, a rule-based representation language. 1 Introduction Artificial intelligence (AI) problems are normally NP (non-polynomial) hard by nature. Different from conventional numerical computations, AI research has concentrated on the development of symbolic and heuristic methods to solve complex problems efficiently. Since the 1980 s, AI has found wide realistic applications in those areas where symbolic and heuristic computations are necessary. For example, expert systems have produced startling economic impact. Because of the need for symbolic and heuristic computation, AI has its own programming methodology [Wu 1994b], and rule-based programming has been dominant in AI research and applications. It is probably an axiom of AI that domain expertise is always rule-governed. Firstly, even in the world at large, people have a tendency to associate domain expertise with rules in behaviour and often explain behaviour by appealing to such rules. Secondly, knowledge in an AI system often depends on some domain expert(s) heuristics, which can be easily and naturally encoded into the IF THEN structure. Therefore, rule-based systems have become one of the most widely used models of knowledge representation in AI, in particular expert systems. Rather than expressing logic calculus about the world as in Prolog-like logic programming systems or computing the numeric values defined over data as in conventional programming, rule-based production systems normally determine how the symbol structures that represent the current state of the problem should be manipulated to bring the representation closer to a solution. Problems that have been solved in production systems can be usually encoded in LISP or PROLOG, but production systems and rule-based programming languages are specifically designed to solve those problems, and as a result they solve those problems more efficiently. Meanwhile, rules are the essential component for both rule-based production systems (or rule-based systems) and logic programming systems. Since heuristic knowledge is of major concern in this paper, rule-based programming is more production systems oriented. However, if we do not plan to deal with inexact rules, logic programming can be used to replace rule-based programming hereafter. Rule-based programming has many advantages, 1

2 such as: Modularity and modifiability. Rules are easily coded and added to a production system. They may be added to the rule base without changing other rules. Naturalness and simplicity. The IF THEN format of production rules is a natural and appropriate method for many kinds of human expertise. It provides an attractive simplicity for the representation of knowledge. Knowledge intensive. An expert system may be adapted for use in another problem domain by simply changing the rule base. In the meanwhile, there are also several significant disadvantages inherent in the mechanism: 1. Rules are inefficient in structural representation. Encapsulation of all relevant information of a single entity is hard with rule-based programming. 2. Rules in general lack software engineering devices such as modules, information hiding, and reuse to make them a viable choice for large programs. In contrast, object-oriented programming, a technology from software engineering, provides powerful facilities to resolve these problems. Section 2 outlines the main features of object technology and possible ways to integrate object technology with rule-based programming. Section 3 designs a factor-centered representation language, Factor++, which models the rule based paradigm into object-oriented (O-O) programming by applying knowledge object techniques [Wu et al. 1995]. 2 Object Technology Object technology in software engineering makes it easier to develop, maintain and reuse a wide range of applications. These applications are mainly concerned with data processing. Object orientation attempts to model the behaviour patterns of collections of cooperating physical entities in the real world. Objectoriented programming (OOP) provides a better way of defining data and procedures that are associated with these physical entities than conventional imperative languages such as C, Pascal and Fortran. OOP was first discussed in the late 1960 s when the so called software crisis began in large systems development. Methods have evolved since then and have shifted the emphasis from a problem of coding to object-oriented design (OOD). The primary aim of OOD is to improve productivity, increase quality and elevate the maintainability of large software systems [Coad & Yourdon 91]. The well defined and widely accepted principles are the concepts of the class, encapsulation, inheritance and polymorphism. At the core of OOD is the class which represents a real world entity by grouping all of its data attributes and procedural operations together into a neatly encapsulated package. Software productivity is improved primarily by reducing the amount of time required for detecting and removing defects from programming code. Reusing software, in the form of class libraries can produce startling increases in productivity and greatly reduce the amount of errors in a large program. However, the emphasis on productivity could have obscured the need for improvements in software quality. Processes that produce high-quality products early in development, such as analysis and design, can greatly reduce errors discovered later in development such as coding and testing and can dramatically improve software quality [Coad & Yourdon 91]. Maintainability, the final objective of OOD, is accomplished by separating the dynamic parts of a system from those parts which are stable. A robust system must be designed with the expectation of change according to the ever changing requirements of clients. Achieving all of these objectives together in a single system is always difficult to accomplish and more than often a trade-off is necessary. With appropriate use, however, the principles of OOD will assist in achieving these goals. 2.1 Abstraction and encapsulation Abstraction is the principle of capturing useful information by ignoring all the detailed features of an entity that are not relevant to understanding what it does or what it is. Rather than trying to comprehend everything about the entity all at once, we select only 2

3 part of it. Abstraction consists of data abstraction and procedural abstraction. Procedural abstraction can already be found in most imperative programming languages in the form of functions and procedures, which can be used to reduce the complexity of programming code. In OOD, data abstraction is carried out by the definitions of abstract data types (ADTs) commonly called classes or types [Atkinson et al. 92]. An ADT is defined in terms of data items and the operations, called methods in OOP, that can be applied to these data items. The data within the ADT can only be modified and manipulated by these methods. The resulting notion of encapsulation leads to a separation of interface and implementation. The data of an ADT can only be accessed via the specified interface, while the implementation details such as the operations are hidden and at the discretion of the class implementor or the dynamic decisions of the ADT. By encapsulation in OOD, each component of a program should hide a single design decision. The interface to each module should be designed so as to reveal as little as possible about its internal implementation details. A language which provides this feature enables the designer to keep related components of a program together in the form of a package in the hope that later changes can be carried out within this package. 2.2 Classes When using an ADT in an imperative language with constructs such as records (used in Pascal) or structs (used in C) the designer will normally create routines which manipulate the structure. Operations or routines defined for the data structure in one construct cannot be used for another structure in these languages. In an object-oriented programming language (OOPL) such as C++, the data structure and the operations are bound together into one package, called a class. A class can have private and public data. The private data cannot be seen or modified by the user without using the public interface, known as member functions in C++. This prevents accidental modification of the data and improves code quality by reducing the amount of bugs evident in the code [Eckel 93]. Variables or instances of a class are called objects. There is a fundamental difference between an object and a class: the class is the definition for the data structure, and an object is an instance of that data structure. More than one object can be created from a class definition. This distinction has also led to distinguish objectbased programming languages from object-oriented (OO) ones. In OO languages, objects encapsulate a concrete data structure and a behavior, and they do not need a type. In OO languages, objects are classified and all objects of the same class share the same behavior. Therefore in an OO language the procedures and functions defined on a data structure are described as part of a class and the class is considered as a generic device for instantiating objects. In this case, the user can use the member functions provided by the public interface of a class to pass messages to objects of the class, and the objects control their own actions and can remember their current state. Two special member functions, called constructors and destructors in C++, are provided in many OO languages to allow the user to pass a message to a class and create or destruct an object. A constructor is used to initialise an instance of a class by allocating memory for an array, for instance. Destructors on the other hand are used for clean-up operations, such as freeing any memory the object may have been explicitly allocated. 2.3 Inheritance In an OOPL a user-defined class can inherit features of another, thus promoting a much higher level of code re-use. The most common view of inheritance within the OOP field is that the subclass inherits all the properties and operations defined for the superclass and will probably add more [Snyder 1986]. Inheritance allows a designer to specify common attributes and services in one class, and then specialise and extend those attributes and services into specific cases. One class may also inherit the properties of more than one other class, and this is called multiple inheritance. Single and multiple inheritance is supported by C++ by means of derived classes. A derived class is declared by following its name with the names of its base classes. A derived class can inherit either the base classes public parts or both their private and public parts. This is still an issue left open-ended, to be used at the discretion of the designers of individual OOPLs. To support multiple inheritance the derived class may 3

4 form a base class of another derived class permitting the construction of class hierarchies. An inheritance structure is one of the ways of offering reusability, extendibility, lower maintenance cost and of achieving the software engineering goals that designers have been aiming at for years [Henderson-Sellers 92]. 2.4 Polymorphism and dynamic/late binding Polymorphism is one of the most powerful concepts of OOD. It is the concept of sending a message from one object to other objects in an inheritance hierarchy and invoking the most appropriate behaviour for the object. Polymorphism presents the property of operator overloading. In C++ overloading allows the user to specify member functions with the same name which perform different functions according to how many, and the types of parameters passed. To allow the functionality of polymorphism the compiler of an OOPL cannot bind the operation names to programs at compile time [Atkinson et al. 92]. Therefore, operation names must be resolved at run-time. This delayed translation is known as late or dynamic binding. Similarly, overloading allows the same member function to be declared for all of the different derived classes of shape. Polymorphism and dynamicbinding are provided in C++ through the use of virtual member functions. A virtual function is provided with definition in its base class, but may be redefined in derived classes. That is, a virtual function may have different versions in different derived classes and it is the responsibility of the run-time system to find the appropriate version for each call of the virtual function. Functions that are not marked as virtual may be bound statically to the base class in which it is defined which allows for easier implementation. There are also other forms of polymorphism than the dynamic binding described above, such as parametric polymorphism, most of which are available in OOP but also in other languages. 2.5 Embedding objects into rules Given the respective features of OOP and rulebased programming, we cannot make a general statement to say whether rule-based programming or O- O languages are superior in computational strength [Wu 1996]. Rule-based programming expresses relationships between objects very explicitly. However, they don t express updates clearly. O-O programming is weak in inference power due to its procedural origin, but updates are defined clearly by assignments. It has the central ideas of encapsulation and reuse which encourage modular program development. On one hand, while the O-O paradigm provides efficient facilities for encapsulation and reuse, it does not support inference engines for symbolic and heuristic computation. A clear advantage of rule-based programming is that recursion can be easily defined within rules while difficult in objects. On the other hand, rulebased programming is very limited in structural representation and for large systems. Therefore, it would be very useful if we can integrate both of them in a seamless and natural way in order to exploit their synergism. It seems as if objects and rules are made for each other. Objects are the best way to simulate or model a problem domain. Rules can be designed to capture and encode human expertise that is applied to a problem domain. A natural way seems to be use objects for modeling the domain and rules to represent decision-making applied to the domain. In a rule-based system, data in the working memory (or database) represents the state of the system and is used to fire rules. In an O-O system, the state is characterized by the the data items in objects. Therefore, a natural integration of objects and rules is to use objects as storage for the working memory in a rule-based system, and rules execute actions depending on the values of objects in the working memory. A number of AI tools such as CLIPS [Donnell 1994], ART and KEE [Harmon & King 1985] have provided such facilities to embed objects in rules. 2.6 Incorporating rules into objects It is argued in [Wong 1990] that it is undesirable to implement objects within rule-based programming, since rule-based programming is not as portable as O-O programming. One way to get round this is to implement rules within objects. We use O-O languages as the basis and implement rules which describe relationships of objects on the top of them. Domain expertise always relates to inter-relationships between objects, therefore a declarative query language for expressing 4

5 these inter-relationships is very useful in integrated systems. In Prolog++ [Moss 1994], for example, an object layer is designed as an encompassing layer for Prolog rules. In this paradigm, objects can call Prolog rules without any special annotation, and if a Prolog predicate is redefined within the Prolog++ class hierarchy, the definition will be taken by default. Rules can be used to make an object s semantics explicit and visible [Graham 1993, Zhao 1994]. They can also provide heuristic procedural attachment in methods. Actually methods within objects can always be implemented in the form of rules. Rules can be defined in an independent rule base so that the methods in objects can call the corresponding predicates (rule heads), in the form of, e.g., obey statements in [Wong 1990]. We can of course implement a set of rules with the same rule head in the form of objects, although some of the O-O advantages like inheritance, cannot be found from such objects. Rules within objects can be divided into two categories [Odell 1993]: constraint rules and derivation rules. The former define restrictions of object structure and behavior, such as consistency and constraints, and the latter are used to infer new data from existing data. In [Kwok & Norrie 1994], for example, an object has four protocol parts: attributes, class methods, instance methods and rules. Rules can be activated by messages as methods. When heuristic rules are embedded within an object, the object can infer on these rules to provide heuristic answers when receiving queries from other objects. Such an object is called a knowledge object [Wu et al. 1995]. A knowledge object consists of at least three parts: data items, inheritance hierarchy, and rules. Methods can be implemented in forms of rules, or as a fourth component. Both rules and methods can be specified as public to allow global access or as private to prevent external visiting and modification. 3 FACTOR++: O-O Modeling of Rule-Based Programming The rule-based and object-oriented paradigms are both self-important and it is not appropriate to say that one should be the master and the other the slave in general, but depending on the application domains, choosing one of them as the basis and building the other on the top are necessary given that a seamless integration is not yet available and constructing one may well be very time consuming. Factor++ is a new representation language based on knowledge object techniques. It models rule-based programming into O-O programming, and provides facilities to represent all the information that can be represented in the rule schema + rule body language [Wu 1994a]. 3.1 Rule schema + rule body Rule schema + rule body [Wu 1994a] is a rule-based representation language. A rule base in rule schema + rule body contains a number of rule sets, each consisting of a rule schema with its corresponding rule body. Rule schemata are used to describe the hierarchy among factors or nodes in domain reasoning networks while rule bodies, which comprise computing rules as well as inference rules, are used to express specific evaluation methods for the factors and/or the certainty factors of the factors in their corresponding rule schemata. A rule schema has a rule-like structure with the general form of: If E 1 ; E 2 ; : : : ; En then A, where all of E 1 ; E 2 ; : : : ; En and A are factors. A factor in rule schema + rule body is a name involved in a domain expertise. It can be a logical assertion, a discrete set variable or a continuous, numeric variable. By representing explicitly numeric computation and inexact calculus as well as inference rules, the language supports a flexible way to process procedural knowledge and uncertainty. 3.2 Factor++: a factor-centered knowledge representation A domain expertise always comprises a set of variables and the relationships between these variables. In rule schema + rule body, the variables are referred to as factors and the relationships are divided into two levels: rule schemata and rule bodies. In an objectoriented system, every entity is encapsulated into an object, a data structure combining the data properties of the entity and the procedures on the data. The data capture the attributes of the object, and the procedures capture the object s behaviours. 5

6 To integrate rules into objects by applying the knowledge objects, we define a factor in Factor++ by three characteristics: (a) the name of the factor (the factor identifier), (b) the names of variables and their value types that are relevant to the definition of the factor, and (c) the relationships between the factor and the relevant variables. Each of the relevant variables here is also a factor in the problem domain. The second characteristic relates to the rule schemata in rule schema + rule body, and the rule bodies in rule schema + rule body can be represented in the third characteristic. Inheritance is certainly an advantage of O-O modeling over rule-based computation, but since the main topic of this paper is to model rules into objects, we will not address inheritance in particular. A factor is an independent knowledge unit in Factor++. It can be described in extended Backus Naur form as follows. <Factor> := <Name><Type><Data Items> <Variables><Premise Links><Procedures> <Inference Status><Certainty Factor> <Name> :- <String> <Type> :- <terminal factor> <goal factor> <Data Items> :- <Data Item> <Data Item> <Data Items> <Data Item> :- <Attribute><Value> <Attribute> :- <String> <Value> :- unknown <a value of any data type> <Variables> :- <Variable> <Variable>, <Variables> <Variable> :- <Factor Name> <Factor Name> :- <String> <Premise Links> :- <Premise Link> <Premise Link>, <Premise Links> <Premise Link> :- <Factor Name> <Factor Name> and <Premise Link> <Procedures> :- <IF... THEN Rules> <Inference Status> :- unknown instantiated failed chaining <Certainty Factor> :- <Real> Definition 1. A factor combines a variable in a domain expertise, its data items, other relevant variables in the domain expertise that are used to define this variable, and the relationships between this variable and other variables. The inference status of a factor will be mentioned in Section Definition 2. A terminal factor is an evidence factor, whose possible data items are supposed to be given by the user. Definition 3. A goal factor is not a terminal factor. Some procedures in the domain expertise are required to evaluate each goal factor. Definition 4. A premise link in a factor is organized as a list structure for a collection of variables. All the variables in the premise link form a logical AND relation, and when values of these variables are all available, the factor can be evaluated. Definition 5. A procedure in a factor contains the domain expertise to evaluate the data items of the factor and/or the certainty factor of the factor. In each procedure, there may be one or more inference rules similar to those in production systems. The inputs to the procedure must be declared in a corresponding premise link of the factor. A procedure in Factor++ corresponds to a rule body in rule schema + rule body. There is no procedure in terminal factors; however, there may be more than one procedure in a goal factor to define the evaluation of the factor and/or its uncertainty factor. Rules in a traditional rule base have been divided into groups in Factor++, in a similar way as in rule schema + rule body, and have been embedded into factors. A knowledge base in Factor++ is a set of factor definitions, each of which is an independent knowledge unit Converting a rule base into Factor++ The following procedure converts a normal rule base into the Factor++ representation. Step 1 Create terminal factors. If a factor appears in the lefthand side of some rules and never appears in the righthand side of any rules, the factor is a terminal factor. Step 2 If a rule contains two or more conclusion factors, split this rule into two or more, simpler rules so that each has only one conclusion factor. Step 3 Group the rules that have the same conclusion factor into one rule set. Each rule set formed this way corresponds to a factor in Factor++. Step 4 Set up factors by filling out their components. 6

7 3.2.2 Reasoning with Factor++ Reasoning with Factor++ starts with a goal factor. With a given set of terminal factors, we can determine whether a factor is one of the premise factors of a goal factor or not when the goal factor is being visited. If a goal factor is unknown, we can infer it immediately. At each inference stage, a factor is in one of the following four states: (1) unknown, (2) instantiated, (3) failed, and (4) chaining. The unknown status indicates that the factor has not been processed. The instantiated status means that the factor has data items in the working memory. A factor being failed means that the factor cannot be evaluated, i.e., there is not enough evidence in the working memory. The last status, chaining, indicates that the factor is being processed. Before a factor is processed, the inference status of the factor is always unknown. After being processed, the factor is either instantiated or failed. When we match the factors on a premise link of a goal factor, we check the inference status of each of the factors on the premise link. If all these factors are instantiated, then we call the corresponding procedure of the premise link in the goal factor to evaluate the goal factor. If there is a factor on the premise link that is failed, the corresponding procedure is dropped immediately. If there is a factor on the premise link that is unknown, we move control to the unknown factor, try to evaluate it, and return after this factor is either instantiated or failed. The time complexity of the above process is linear to the number of factors and the number of rules, if there is no dead cycle 1 in a knowledge base in Factor++. Each factor is processed only once, and we always try a factor at the first time when it is met. After a goal factor is evaluated, it is treated as a terminal factor whether it is instantiated or failed, because its inference information is kept in the working memory. A rule within a factor is matched at most once. If a premise link in a factor fails to match the working memory, the corresponding procedure will not be called, and therefore the rules within the procedure will not be matched and executed. 1 If, for example, A is a necessary condition for B, B is also a necessary condition for A, and there is no other way to determine A or B independently, we say that A and B have formed a dead cycle. 3.3 Comparison between Factor++ and rule schema + rule body A premise link in a factor by Definition 4 corresponds to a rule schema with the factor as the conclusion factor in rule schema + rule body [Wu 1994a]. A procedure by Definition 5 corresponds to a rule body. Therefore, all information in rule schema + rule body can be represented in Factor++. In rule schema + rule body, there may be more than one rule schema with the same conclusion factor; in Factor++, these rule schemata and their associated rule bodies are encapsulated into one knowledge object, which is the conclusion factor. A factor in Factor++ is an object, and therefore all O-O features such as inheritance and polymorphism can be easily explored in Factor++. 4 Conclusions Rule-based programming is the dominant programming paradigm in AI research and applications. Since its insufficient software engineering power in structural representation and for large systems, we have discussed its integration with object technology, a powerful technology from software engineering, and have designed a factor centered representation language which models the rule-based paradigm into object-oriented programming. A factor in Factor++ is an object that holds its data items, inference information, and all the rules in which this factor is computed. Factor++ supports a linear chaining process. Inheritance and polymorphism are also supported in Factor++ because of its object orientation. When a knowledge base gets larger and larger, inheritance and encapsulation become more and more important in the design and maintenance of the knowledge base. References [Atkinson et al. 92] Atkinson, Bancilhon, De Witt, Dittrich, Maier, and Zdonok, The Object- Oriented Database System Manifesto, Building an Object-Oriented Database System: The Story of O2, F. Bancilhon, C. Delobel, and P. Kanel- 7

8 lakis, Eds., Morgan Kaufmann Publishers, 1992, [Booch 1994] G. Booch Object Oriented Analysis and Design with Applications. Addison- Wesley. [Coad & Yourdon 91] P. Coad and E. Yourdon, Object-Oriented Design, Yourdon Press, [Donnell 1994] B.L. Donnell Object Rule Integration in CLIPS. Expert Systems, 11(1). [Eckel 93] B. Eckel, C++ Inside & Out, McGraw- Hill, [Frost 1986] R.A. Frost Introduction to Knowledge Base Systems. Collins. [Graham 1993] I. Graham Migration Using SOMA: A Semantically Rich Method of Object- Oriented Analysis. Journal of Object-Oriented Programming, 5, 9: [Henderson-Sellers 92] B. Henderson-Sellers, Object-Oriented Information Systems: An Introductory Tutorial, The Australian Computer Journal, 24(1992), 1: [Harmon & King 1985] P. Harmon & D. King Expert Systems. Wiley. [Snyder 1986] A. Snyder Encapsulation and Inheritance in Object-Oriented Programming Languages. Proc. of OOPSLA 86. ACM. [Wong 1990] L. Wong Inference Rules in Object Oriented Programming Systems. Deductive and Object-Oriented Databases. W. Kim, J.-M. Nicolas, and S. Nishio (Eds.). Elsevier Science Publishers B. V., North-Holland. [Wu 1996] X. Wu A Comparison of Objects with Frames and OODBs. Object Currents, Vol 1, Issue 1. [Wu 1994a] X. Wu Rule Schema + Rule Body: A 2-level Representation Language. International Journal of Computers and Their Applications, 1: [Wu 1994b] X. Wu, Developing an AI Curriculum for Computer Science Majors, AXIS: The UCISA Journal of Academic Computing and Information Systems, 1(1994), 3: [Wu et al. 1995] X. Wu, S. Ramakrishnan and H. Schmidt Knowledge Objects. Infomatica, 19, 4: [Zhao 1994] L. Zhao ROO: Rules and Object- Orientation. TOOLs Pacific 94 Technology of Object-Oriented Languages and Systems [Kwok & Norrie 1994] A.D. Kwok and D.H. Norrie Integrating a Rule-Based Object System with the Smalltalk Environment. Journal of Object-Oriented Programming, 6, 9: [McCabe 1992] F.G. McCabe Logic and Objects. Prentice-Hall. [Meyer 1988] B. Meyer Object-Oriented Software Construction. Prentice-hall. [Moss 1994] C. Moss Prolog++: The Power of Object-Oriented and Logic Programming. Addison-Wesley Publishing Company. [Odell 1993] J. Odell Specifying Requirements Using Rules. Journal of Object-Oriented Programming, 6(2):