Articles -select to view list A Close Shave With Occam's Razor What Does Your Company Do Fuzzy Knowledge Bases Genetically Tuned Fuzzy Models A Project Risk Assessment Model Distributed Intelligence in B2B Universe Hybrid Text Mining Fuzzy SQL XML and Distributed B2B Intelligence Fuzzy Logic in eCommerce Experts Systems Knowledge Navigator Building Intelligent Models CI and Threat Assessment Object and Knowledge Based Modeling Seeing the Invisible A Protocycling Methodology

AR-PA-014

Knowledge-Based
Business Process Modeling

A Complex Systems Design through A Fusion of Computational Intelligence and Object-Oriented Models

© 2002 Earl Cox

You would think from recent articles and conferences that objects are the Rosetta stone unlocking the mysteries of complex systems and coupling artificial intelligence to modern distributed systems. Rule based systems – the “old” expert systems – have become passé and are relics of a distant time before knowledge engineers and systems designers discovered the wonders of object oriented design and development. Nothing could be further form the truth. The resurgence in business intelligence systems and predictive data mining has resulted in a strong and elastic relationship between object representation and rule-based expert systems. Today’s business intelligence systems use objects to manage complexity. But inside the array of objects and the overlaying messaging systems (such as JMS – the Java Messaging System and Java Spaces, a distributed blackboard facility) are the familiar if-then-else rules of conventional expert systems. In this article we examine the object revolution and see how it has changed the face of these expert systems.

The Object Revolution

There are few changes to modern computer systems design and architecture that have had such a profound influence as the ineluctable rush toward object oriented design (OOD) and object oriented programming (OOP). The last such paradigm shift occurred when John Von Neumann discovered the principles of an internally programmed instruction set and moved computers from hardwired counting machines to high speed logic machines. The uniqueness of this shift is true even when we consider the impressive gains made by the introduction of structured programming and modern fourth generation languages.

As software vendors and leading-edge programmers began embracing the object model, a rapid movement toward the OOD/OOP approach moved through the industry. Books appeared on object oriented programming, Gurus emerged, and leading language vendors, notably Borland, released low cost language compilers (such as C++ and, more recently, Delphi). With books, languages, and a working methodology, the industry movement to object-oriented software models was well under way. Today Object Oriented development is not only a way of thinking but it practically the only way to design and develop programs—all the modern programming language, Java, C++, Python, and so forth—are object based.

But what exactly is an object? Before discussing the revolution in software design and architecture based on the object principle, we need to define some basic terms. We will take up these concepts in much more detail later, so now only a preliminary description is needed. According to the Dictionary

Object ob’jikt, n. a thing presented or capable of being presented to the senses: a thing observed: a material thing: that which is thought of, regarded as being outside, different from, or independent of, the mind (opposed to subject): that upon which attention, interest, action, or some emotion is fixed: a discrete thing: a physical entity. [L. objectus. pa. p. of ob(j)icere, or partly the nound objectus, -us (found in the abl.), or the freq. vb. objectare – ob, in the way of, jacere, to throw]

Thus, an object is a thing. In software design and systems analysis, the object represents a principal component. Each object is a self-contained component of the computer systems, responsible for its own data, its own activities, and the integrity of its actions. As an example, in a marketing or retailing system, an object might be a CUSTOMER. As Figure 1 shows, we can visualize the object as a container holding both private and public parts:

Figure 1. A Basic Customer Object

The CUSTOMER object contains all the information about a particular customer (called an instance of the object). This information, the data fields or variables, may or may not be visible to the users of the object. The object also as associated with it, the procedures necessary to perform all allowable operations on a CUSTOMER (such as adding and deleting customers, updating the data variables, displaying a customer’s profile, or fetching a customer from the organization’s central database.) And, as we will see later, the data variables in an object can, themselves, be other objects. The object model thus provides a unified, uniform, and well-behaved paradigm for the representation, implementation, and use of complex software projects.

What is the revolution in object oriented software and what does it mean? To understand the way that objects have changed our view of programming and lead to a radical re-thinking of systems analysis, we must look at how software systems were designed and built before object orientation.

Programs and Systems

Conventional program design, from the time of the first programmable machines, made a clear separation between the software code, the data, and the relationships between functionality in a large system. As an example, Figure 2 illustrates typical computer program relationship.

Figure 2. Conventional Program Organization

The program represents an independent piece of logic. It is coupled to the outside would through such general services as input and output procedures (such as Windows™ dialogs) or to databases and file systems through file manager protocols (such as CICS on mainframes or ODBC on workstations).

When computer systems consisted of relatively few individual programs this arrangement presented few problems. But in the middle 1960’s, with the introduction of IBM’s 360-series computers, the evolution of virtual memory, and the rise of timesharing sharing systems, the focus on small, tightly contained scientific applications gave way to the rise of very complex business systems. As Figure 3 illustrates schematically, these large programs were built from individual pieces of separate programs.

Figure 3. A Computer System

While the programs were designed and written to work co-operatively and were, by the standards of structured programming, a coherent whole, they were, never-the-less, only a coherent whole in the widest possible use of the term. Figure 4 schematically shows this. The application’s client billing subsystem is a logical consideration created by the programming relationships, not by some underlying and intrinsic structure.

Figure 4. An Application Sub-System

Other customer related activities – customer account maintenance, customer credit analysis, and so forth – are handled by their own set of related programs, each providing access to the customer master file and performing integrity and validation checks.

Complexity and Object Models

As the over-all as well as intrinsic complexity of software systems increased, the ability to effectively design large-scale business applications, add new components, as well as test and maintain system enhancements from increasingly sophisticated end-users was further and further reduced. It is toward this problem that object oriented systems are geared. In an object-based system, the functional heart or core of the system is embedded in the collection of objects rather than in the collection of independent programs.

In object oriented design, knowledge is organized in self-contained units. These units or objects represent “things” in the system – patients (or customers or policy holders, etc), treatment protocols, inventories, purchase orders, and so fort. Each thing is a primary component of the business process. Associated with the object is its own collection of variables, rules, methods, and (if necessary) fuzzy sets. Figure 5 shows how this appears in schematic form.

Figure 5. The Schematic of an Intelligent Object

The term Object and Class are often used interchangeably. Both describe a coherent structure corresponding to the organization described in Figure 5, above. Classes can be (and often are) derived from other classes, a property known as inheritance (thus a CUSTOMER and a PROSPECT Class could both be derived from a higher abstraction BUSINESS_ENTITY Class.) Generally speaking an Object or Class is simply a description of the way data is organized. An actual instance of the Class must be created (or allocated) before the object can be used in a software system.

You should notice that the internal structure of an object contains both public and private elements (variables, procedures, and rules). The public elements are those that the user of the object can access. The private elements are used inside the object and cannot be seen or used outside the object’s scope. The use of private object components shields the user from the implementation specifics of a particular object. The methods or procedures associated with an object are used to manipulate the object itself and for the core of the knowledge associated with an object. In essence, an object is a tight grouping of all the knowledge associated with a particular, well-defined noun in the process model.

Methods encapsulate the actual knowledge in the object. They hold the rules which direct processing and represent the intelligence associated with an object’s behavior in the complete system (the enterprise). Thus. Methods should perform a discrete and well-focused action. The rules should be both specific and localized. As you may have noticed, there are two broad categories of methods: algorithmic and intelligence-based. Algorithmic or procedural methods are, essentially, small computer programs that perform routine maintenance, reporting, security, and data integrity services. Adding a new patient to a hospital’s database is generally such an example. Intelligence-based methods, on the other hand, contain rules, are non-procedural and employ on the conventional inference engines to resolve their action. As an example, given the following PRODUCT object,

Class PRODUCT
Public
PR_Desc as string
PR_SKU as string
PR_PRICE as number like “$99999.99” rounded
PR_DOMAIN(2) as number

Methods
SetNewPrice(Competition.Price,Ceiling,Sensitivity)

we have a SetNewPrice method that determines the best price for the item. The contents of the method appear as,

Method SetNewPrice(…)
Engine: Fuzzy Logic
Rules:
[1] our price must be HIGH
[2] our price must be LOW
[3] our price must be around 2*PR_MFGCOST
[4] if competition.price is not very high
then our price must be near competition.price
end Rules
set PR_PRICE=price
end Method

In this intelligence-based method, the fuzzy logic rules [1] through [4] are executed by the system’s inference engine to develop a value for the solution variable price. The method then assigns the value of price to the object variable PR_PRICE. Bear in mind, however, that the purpose of object evolution and method development is knowledge acquisition. We are interested in capturing the fundamental elements of the systems and encoding its behavior.

Object-Oriented Design and Knowledge Acquisition

Before moving on to the use of object-oriented systems in computational intelligence, we should examine the way Object-Oriented Design (OOD) has influenced the way knowledge engineers acquire and represent intelligence. Knowledge-based systems have several unusual characteristics that significantly affect the way they are organized. Conventional machine reasoning paradigms such as backward and forward chaining generally demand that variables and rules, even when enclosed in an object, are visible to the high level inference engines. Also, the nature of intelligent systems often means that the relationships between objects (or their processes) are dynamically established. Thus, a workable object oriented design approach for intelligent systems often involves an early separation of intelligence and form.

Rule-Based Modeling System (Data Representation)

A machine intelligence system supporting rule-based modeling is a rather complex apparatus consisting of many interlocking object classes. The full system, however, is an elegant and robust collection of container classes used to represent a heterogeneous application in computational intelligence. The principal components of the modeling system are two container classes (shown in Figure 6) – Models and Policies. A “container” class is simply a class that contains a collection of similar data elements or a collection of other objects. Container classes have their own methods of accessing, adding, deleting, and looping through their collection of elements.

Figure 6. The Model Class Structure

The Model class provides a container shell encapsulating the entire application framework. One level below the Model is a dictionary of Policies. These Policy objects are the actual “work horses” of the intelligent system. They contain the declared variables (optionally decomposed into semantic units called Fuzzy Sets) and the actual production rules. A Model can also contain (or share) table definitions. Tables represent relations in ODBC (or JDBC)-compliant databases, spread sheets, or matrix variables. Figure 7 shows the Object class organization of the Policy.

Figure 7. The Policy Class Organization

At this schematic level, the class (object) properties combine to form a somewhat hierarchical information architecture with Policies encapsulated by the Model. And within the Policy, itself a container class, are encapsulated the fundamental components of the expert system: table definitions, declared variables, the fuzzy sets, and production rules. Each Policy is a self-contained expert system with its own internal knowledge representation schemes and production if-then-else rules. A Policy has its own inference engine, a goal state (for backward chaining and, optionally, for forward chaining). Policies can be started by the inference engine or through the consequent action of a rule. As an example,

If costs > profits then do;
Profits=(revenue-costs);
If Profits < 0 then
Perform GetBankLoan(abs(profits));
End if
End if;

This rule takes the difference between operating costs and revenues to calculate profit. If there were no profits, the GetBankLoan policy is performed with the absolute value of profits passed as a formal parameter (this is the amount of the loan.)

Fuzzy Sets

Although this article cannot deal even superficially with the concepts underlying fuzzy logic and approximate reasoning, the FuzzySet class is a pivotal component of the machine reasoning capabilities. Fuzzy sets are used to describe both variables and table columns. They are used in production rules as well as in database queries (using advanced FuzzySQL statements). Through fuzzy sets, the knowledge engineer defines the semantics of each variable and allows production rules to reference these semantic spaces. Figure 8 shows the Class organization for Fuzzy Sets.

Figure 8. The Fuzzy Set Class Organization

Variables

The individual elements used in defining rules are called Variables and they come in three flavors: input, working, and solution (or outcome). Each variable has the same properties (the flavor simply determines how it can be used in an expression). Figure 9 shows the structure of the Variable class.

Figure 9. The Variable Class Organization

An instance of the Variable class has a specific data type (integer, single or double precision floating point, character string, Boolean, date/time, and so forth) as well as an organization (scalar or time series). A variable has its own active time frame. And a variable also contains reasoning engine controls that tells the system both how to acquire its values and how to resolve a value from a fuzzy reasoning process. This fuzzy reasoning approach depends on decomposing numeric variables into their individual, over-lapping fuzzy sets.

Numeric variables also have a Universe of Discourse (UoD) or domain specifying the minimum and maximum values they can assume (thus the variable AGE might have a UoD of [1,105], while GROSS_TONNAGE for a steel mill (as a measure of monthly production) might have a UoD of [0,100000000]. For numeric fields, such as a customer’s AGE, the Universe of Discourse can be broken down into a set of semantic regions. This is done, as shown in Figure 10, by partitioning the variable into over-lapping Fuzzy Sets.

Figure 10. The Fuzzy Term Set for Customer.Age

Fuzzy sets are associated with the FuzzySet class object. They are used in production rules to provide approximate reasoning capabilities. With fuzzy sets we can write Policy logic statements such as,

If customer.age is MiddleAged
And customer.income is High
Then credit_rating is Elevated;

These rules allow the knowledge engineer to cast the Policy intelligence in terms of the underlying variable semantics. Fuzzy logic provides a powerful representational and machine reasoning capability. It also allows variables to be explicitly decomposed their semantics so that the actual meanings of a variable can be expressed.

Rules

Rules for the actual intelligence are embedded in the Policy. Each rule is a conditional or unconditional statement in the form if-then-else. The Rule class (Figure 11) manages both the source and compiled form of the rule.

Figure 11. The Rule Class Organization

The Rule Class is connected to the Rule Compiler Class object, a tightly encapsulated object that takes the character representation of a rule and generates the compiled, executable form. This compiled code is expressed in Early Operator Reverse Polish Notation (RPN). In reverse polish an expression such as,

A*B+(C/D)

Is stored without parentheses in an unambiguous form:

AB*CD/+

An expression in reverse polish notation is actually stored as a binary tree with the operators located at the root nodes and the variable, constant, or string values located at the terminal leaves. Figure 12 is a schematic representation of the previous expression in RPN binary tree form.

Figure 12. An RPN Binary Tree

We can execute this kind of tree-structured representation (called interpreted code) though a postorder traversal of the binary tree. The generated code is stored in a persistent object (CompiledRPNCode). Any changes to the textual representation of the rule in the Rule Class, sets the UNCOMPILED state in the RPN code class. The Rule Class itself manages the compilation, storage, and execution of rules.

There are two related rule classes: the Rule Object itself (an individual rule) and the Knowledge Base (a collection of compiled rules). When a Model or Policy is activated, its compiled rules are inserted into a Knowledge Base class.

Rules and the Knowledge Base

When compiled and stored, rules represent the application’s intrinsic knowledge. As Figure 13 illustrates a collection of rules constitutes a Knowledge Base.

Figure 13. Knowledge Base as a Container Class of Rules

The knowledge base is the active collection of rules. How these rules are processed is determined by the Inference Engine which selects the necessary rules and places them on its internal agenda. The agenda orders the rules for execution according to a variety of possible criteria (by priority, by specificity, by least cost, by highest resolving power, and so forth). The results of running a collection of rules in the knowledge base can be passed back to the application frame, of, as illustrated in Figure 13, placed on a global blackboard server (such as Java Spaces) for use by other processes.

In Conclusion

Object Oriented Systems have not replaced rule-based systems. They have, however, gone a long way toward providing a suitable framework for the evolution and development of modern, distributed applications. Thought the use of objects, the knowledge engineer can encapsulate and share knowledge among multiple application awhile, at the same time, improving such knowledge management tasks as maintenance, robustness, flexibility, and application specificity.

The combination of recently emerging management and distributed architecture capabilities such as Java Management extensions (JMX), Java Message Services (JMS), and Java Spaces coupled with a better understanding of how intelligence can be captured and deployed in an objected based environment will give eCommerce developers powerful new ways of coupling mission critical applications with expert intelligence.

© Scianta Intelligence 2005 all rights reserved
For more information or to schedule a presentation call (919) 678-0477