Rulebase technology for GIS applications

Rulebase technology for GIS applications

Jeffrey R. Meyers
P.E., Miner & Miner
4701 Royal Vista Circle
Fort Collins, Colorado 80528

Introduction
Object-Oriented technology is now widely accepted as the basis for many types of digital information systems, with aspects of O-O Design and Programming Environments now commonplace in the AM/FM/GIS industry. A variety of techniques have been employed to make the most of the benefits of 00, and GIS implementation has used various modeling and programming tools. But the benefits of 00 have proven too elusive at best, and at worst not realized at all. Rapid deployment and code re-use have been offset by the effort required to design and construct the customized objects needed in the complex and changing operating environment of the modern utility.

One technique that has been gathering interest and momentum in a variety of industries is the concept of a RuleBase. Like 00 itself, this technology comes in a variety of applications and has varying definitions; but technically it is simply a technique for codifying abstract behavior or business rules for use within an application. This paper will provide a high-level explanation of RuleBase technology and explore the principal motivations for using RuleBase technology in a GIS context.

What is a rulebase? And why should I care?
An object in an 00 technology possesses two key characteristics in that it embodies both properties and methods. Properties are simply the characteristics of an object, such as its attributes. The diameter and material of a pipe object are properties, as are the install date and manufacturer of a transformer. Methods are the operations that an object can perform or that can be performed on an object. For example, a transformer can be placed onto the map, and connected to the distribution network. A pipe segment can be traced.

One of the principal benefits of 00 technology is that these behaviors can be encapsulated within the data structure of the object to be used in a standard way by an application or interface, or another object with a reference. But, in order to work, the typical 00 approach requires the storage of the properties and encoding of the methods within the object's data structure. This process usually involves writing code in a lowlevel 00 language, such as C++ or SmallTalk. In addition to the fact that these programming tasks require special skills, they often imply longer initial implementation times, and less flexibility at the object level. Maintenance of the object's structure is also problematic, and oflen expensive.

Enter the RuleBase. In a basic sense, a RuleBase codifies the behavior of the object outside of its normal data structure through a description of business logic and relationships. This allows the data modeler, database analyst, or programmer to use straightforward data expressions for object characteristics and behavior, which can be turned into object properties and methods. Modern RuleBase technologies provide engines that use RuleBase definitions to construct the object at a specific use time, such as when the application is launched, rather than persistently storing the object nature in low-level, inaccessible code.

Thus, the RuleBase presents four principal advantages: First, it enables the nature and the behavior of entities to be described in a separate structure, which is easier to build and minimizes low-level coding. Second, these same advantages make the model easier to maintain. Third, it permits many different applications to share in the object definitions that are maintained in the RuleBase. And finally, through codifying business rules and behaviors in a form separate from a particular technology, overall investment in data modeling can be preserved and both applications and data can be more easily migrated as technology advances. It is worth a look at each of these advantages in detail to gain an appreciation for the elegance and worth of the RuleBase for GIS applications.

Object creation using a rulebase
Many things about AM/FM/GIS or facilities objects can be easily codified in terms of relations and validations. These are generally the category of real-world characteristics called object properties. A relation can be described as the way in which the object fits into the overall data model for all facilities and land. Every database has an inherent data model, a description of what data is to be stored for each object, and how the objects relate to each other. Data models for AM/FM/GIS are particularly important, since they have both spatial and aspatial characteristics. For example, a valve object must have data about its operating type, size and material, and the direction that it is turned to operate. It may also have to have a record in a table or file for each time it is exercised or operated. These are examples of aspatial relationships that can be codified for an object using relations.

Validations are another form of spatial or aspatial object properties that are used to represent valid characteristics of the object, rather than relationships. A simple, almost universal example is the unique identifier, such as a valve that must have a unique company identifier assigned to it. More complex validations are also common, such as the value of a property for an object that is dependent on a value of another property. Pipe coating is a good example of this type of validation. A pipe object may have a set of valid values for its material property, including plastic and steel. The same object may also have a property for coating type, which would have various valid values for steel, but no valid values for plastic. Thus, the validity of the pipe-coating-type property is contingent on the selection of the pipe material. This type of complex validation is sometimes referred to as con~ingent validity. Validations are often checked through a post-process in AM/FM/GIS, using a Quality Control (QC) application to ensure validity.

Of course, there is more to the real-world nature of facilities than their relations and validation properties. Facilities objects also have behavior; things that they do or things that can be done to them, which are generally known in object speak as methods. For an AM/FM/GIS object, most methods have to do with how they fit into a network model, and how they appear on a map (either on screen or hardcopy.) These connectivity/cartography methods can also easily be described as a set of rules that match business practices. As an example, when a valve object is placed into the model and map, its rules may dictate that it should attach itself to a pipe, and rotate its symbol according to the line angle or orientation of the pipe to which it is attached.

Creating a RuleBase through Requirements Analysis and Data Modeling

The clarification and documentation of these three types of characteristics for objects representing real-world facilities in the AM/F M/GIS is the function of requirements analysis and data modeling. Here, then, is one key advantage of using a RuleBase technique: data modelers can describe the properties (relations and validations) for objects using standard manual processes or CASE tools. These standard techniques are well known and highly productive. The results of these modeling efforts are usually embodied in structured relational tables. From there, it is the job of an engine or codegenerator to construct this part of the object, with tools that are available on the commercial market to minimize hands-on coding.

While standard relational techniques may be used for describing relations and validations, connectivity/cartography is typically better described using an object modeling technique. A variety of tools and techniques are available to support this approach, and they are well documented in the literature of the industry. Among the most popular tools is the Universal Modeling Language (UML), for which there are several compatible CASE tools. The key to successful object modeling is to recognize the patterns in business behavior, and to organize them in the most effective way according to function and value. These techniques are invaluable aids in the consistent description of the business rules that govern the behavior of the facilities objects.

But a word of caution: experience has shown that O-O modeling techniques can take on a life of their own, supplanting business knowledge and common sense with technical zeal. It is the wise object modeler who regularly reviews the business purposes for each element in the model, and tests the value of religious rigor and purity of technique against the business needs of constructing the model with reasonable speed and accuracy.

Object maintenance using a rulebase
Despite improvements in analysis and object modeling, a large body of existing knowledge about facilities data models, and the great overlap in business practices among utilities, it is the sad fact that data models must be maintained. Over the life cycle of an AM/FM/GIS, requirements and business practices can change, resulting in the need to add or modify properties and methods of objects, and even to add new objects to the model. Though the benefits of creating an AM/FM/GIS using a RuleBase are great, the benefits of maintaining it through this technique are even greater.

The first benefit for object maintenance using the RuleBase comes from the fact that the model can be easily updated using the standard CASE tools or manual techniques described in the preceding section. As an example, the order in which a valve 'looks for' other objects such as mains and laterals to which it can connect itself can be simply described in row-and-column form in a RuleBase. If a new object is added to the model to which a valve can connect, the RuleBase can be updated simply by adding another row. Because low-level coding is minimized or eliminated altogether, the RuleBase can be simply updated, and the engine used to re-instate the object with its new properties and methods.

This ability has two indirect benefits that are worth noting. First, using a modern architecture in the applications context, the RuleBase can be maintained with minimal impact on users. It is possible, for example, to load the RuleBase of objects into memory along with an application, enabling any user to continue to work while the production RuleBase is undergoing maintenance. When the modified RuleBase is ready for release, each user can simply exit the application and start again, reloading the RuleBase with modifications. This is also a significant benefit where large volumes of production data exist, enabling all objects to be re-structured with minimal impact. (Of course, any new properties of existing objects will have to be populated somehow, but the RuleBase can also be handy for populating default values of existing objects.)

One more side benefit of using a RuleBase technique to create a functioning data model: the RuleBase itself is a convenient and comprehensive documentation tool. Because the RuleBase stores the relations, validations, and connectivity/cartography, it is a good place to refer to all object metadata. Further, consistency between the RuleBase and the actual object structures in production is a key function required for model maintenance. Most commercially available RuleBase tools have consistency checking and reporting tools.

One rulebase, many applications
The modern AM/FM/GIS may no longer be thought of as a map and database maintenance tool. Today's requirements dictate that the AM/FM/GIS database be available to create a variety of geographic and non-geographic applications used by an even greater variety of personnel.

By abstracting business rules and properties of the objects that represent the real-world facilities and storing those in the RuleBase, the model can be used by many applications, both spatial and non-spatial. This approach helps to simplify the implementation of many lighter-weight applications, removing the onus of having the application (or the user) know the data structures and relationships to be used in composing a query or a display. Even casual users can gain access to detailed data through relations, and data displayed by different applications appears consistently to all users. Most importantly, the RuleBase can be used to help ensure that editing operations (either geographic or tabular) follow a consistent set of methods or rules, including validations, to secure data and to maintain its integrity.

For example, consider the case of a valve that is created and maintained normally through the AM/FM/GIS, but also must be accessible to have its properties updated by a non-GIS, SQL-based application. Suppose further that the business rules for the valve specify that each time the valve is operated, the activity should be recorded in a business table for valve maintenance. Whether the valve is updated through the GIS application or the SQL application, a relation stored in the RuleBase can be used to ensure that the update follows the same set of rules. And, any lightweight viewing or browsing GIS application can gain access to the valve maintenance business table data through the same relation.

Using a common RuleBase also permits non-GIS applications to share many of the business rules that were formerly considered the purview of GIS-only applications. For example, network connectivity can be understood by tabular (or non-GIS graphic) applications through the RuleBase to facilitate network analysis, without the need for the geographic component of the objects in the network models.

GIS and Non-GIS Applications Can Share the Rule Base

Migration strategies using a rulebase
One of the key challenges facing any IT system, and especially an AM/FMIGIS implementation, is the difficult task of updating operating systems, hardware and applications to take advantage of improvements in technology. Because of the rapid cycle of technological advance, production systems seem to become obsolete almost overnight. And the wide availability of information about the latest and greatest through trade journals and the Web can add to the pressure on IT and system managers to upgrade AM/FM/GIS platforms.

But with the benefits of cheaper and faster hardware, software, and databases, come the complexities of migrating production applications and data to a new environment. Nearly every AMIFMIGIS has used customized applications (either with or without object technology) to fit the business needs of a particular utility. Customized code is built to use the particular data structures and embody the specific business rules necessary to operate the business in a profitable fashion. It is this stuff, the reimplementation of highly customized applications and data, that makes migration of systems so costly and risky.

Fortunately, the RuleBase approach offers some relief. By separating the business logic, that is, the rules and data structures, from the encoded objects, technology independence can be gained to a large extent. First, by separating the business rules from the application, programming customized coding is minimized, resulting in much less custom code to be upgraded. Second, through the use of structured methods for design and construction of the RuleBase, patterns will emerge in data function and value that will remain consistent regardless of the technology used for implementation. With a proper design, the RuleBase itself can be used to drive the logic for new implementation. Of course, no solution is perfect in this regard, and re-coding of individual rules may be required, depending on the nature of migration. But at the very least, the RuleBase affords the applications designer and implementor a comprehensive, valid collection of data structure and operational logic from which to launch a new implementation.

Summation: A rulebase is good
Object-oriented technology affords the AM/FM/GIS developer, implementor, and user great opportunities to use digital representations of real facilities in more powerful ways than ever before. And, by constructing a RuleBase of business logic and relationships, objects can be built in a faster and more flexible way. RuleBase-driven AM/FM/GIS can be implemented more quickly and flexibly, and maintained more easily. And the RuleBase can be used to support a variety of applications, making facilities objects available to GIS and non-GIS applications alike. Finally, through proper design and implementation, the RuleBase helps to minimize the effort in migrating custom applications and specific databases into new environments.