Untitled Document

There are certain goals that most organizations want to accomplish once they decide to transform their applications. They are:

Historical Overview

Most M applications consist of code that is tightly bound to the database. Business rules are largely embedded in the code. Some rules are embedded in a data dictionary if it exists. This tightly bound approach to creating applications has historical significance in that it offered a low price/performance ratio when computers were much slower and more expensive than they are now. However, tightly bound systems tend to be inflexible whereas loosely bound systems are more flexible. However, within the last 30 years, computer hardware has increased tremendously in speed and has become comparatively economical. Technology has allowed application development from the tightly bound approach to a loosely bound, distributed approach. In addition to this trend, object orientation has added an organizing paradigm that is highly compatible with the distributed trend.

Moving from a tightly bound, inflexible legacy application to a loosely bound, flexible, distributed object oriented application is largely a matter of:

The following sections describe how distributing the business rules can distribute the processing with the consequence of specializing the M environment as a database, and more importantly, permit the integration of other database technologies in a homogeneous fashion.

Business Rules Organization

One of the most important goals of migrating M applications to a distributed object oriented environment is to distribute the business rules as executable code onto the appropriate tiers, primarily to achieve optimum performance. To accomplish this goal, business rules must first be categorized so that they can be applied in a flexible, scalable fashion.

Business Rules Concept

Business rules are derived from a business requirement. Any business requirement can be decomposed into one or more business rules. A business rule is a constraint that is applied to a particular business situation. It can be represented as a conditional statement in the form:

where Constraint is a statement of fact about the business requirement and Action is the action to be taken or not taken based upon the truth value of Constraint.

All prescriptions that are filled must clearly display any warnings on the container.

Many business rules are associated with this one requirement. An example of one business rule produced by this requirement is:

IF the prescription is the drug Claritin, THEN the following warning labels must be clearly displayed on the container:

Take medication on an EMPTY STOMACH 1 hour before or 2 to 3 hours after a meal unless otherwise directed by your doctor.

May cause DROWSINESS. ALCOHOL may INTENSIFY this effect. Use care when operating a car or dangerous machinery.

Organization of Business Rules

The diagram below illustrates the basic premise behind any business organization. That is: Organizations consume Resources through Processes¹

Within the healthcare industry for example, hospitals consume resources such as pharmaceuticals, expendables (ultimately money) through, and as a consequence of, processes that occur daily such as surgery, exams, etc. Applications that are built to model and support the activities within any business environment must enforce business requirements. This is accomplished through business rules.

From a business perspective, this approach to organizing business requirements, and consequently business rules, is a common approach.

Model-View-Controller

The Model-View-Controller (MVC) concept evolved out of the Smalltalk language. It is typically explained using Graphical User Interface (GUI) applications. However, the concept is general and can be applied to any application. It is a design pattern.

The purpose of the MVC is to separate the application object (model) from the way it is presented to the user (view) from the way the user controls it (controller). User in this case may be any user of the model. The MVC provides a way to de-couple these objects, offering much more flexibility and possible re-use.

The model knows about all the data needed by the views. The model's protocol, its interface, contains all the methods and properties needed to access the data.

The view accesses the model. It presents the model as a particular organization. Multiple views can exist for any model. They use the methods of the model to manipulate the data. The model has no knowledge of the views that are accessing it.

Associated with the model is a controller. The controller acts as an intermediary between the model and the views. Any modification to the model is communicated to the views via controller. The controller object within an application often contains the callback code for event processing. For example, if a model side data element is changed, generally an event will be fired, signaling all processes watching for that event to execute the callback. The callback code executed will synchronize the view with the model.

Business Rules Framework

To create a framework for business rules that are implemented within a computerized application, the business organization and MVC concepts can be combined to form a matrix as shown below.

This framework provides a convenient way to map business requirements and rules into a computer application that offers re-usability, scalability and extensibility. It partitions the business rules from a business and a systems perspective.

This framework is the basis for the organization and mapping of business rules that is central to ESI's Application Repository Tools (ART).

Transformation of an M Application

M databases consist of data, a data dictionary (often but not always) and a monolithic code structure that contains the majority of the business rules. The transformation process goals are:

Development Environment

The ART tool set builds on the EsiObjects object oriented development environment. It takes advantage of the large number of reusable foundation classes. It has been designed to accomplish the transformational goals listed above.

Central to the EsiObjects Application Repository Tool Development Environment is the Object Repository. It contains all of the legacy data definitions, business rules and information needed to generate an object oriented runtime system.

Data Definition Extractor - The data definitions are extracted from the Legacy Data Dictionary by the Data Definition Extractor and stored in the Object Repository. The Data Definition Extraction process is fully automated. The Object Repository contains all relevant information collected from the legacy system (data definitions and business rules) stored as objects. It also contains all the information needed to transform the legacy system into an object-oriented system.

During the extraction process, surrogate class definitions are also created and stored in the Object Repository. Surrogate classes are classes that represent the legacy approach to grouping data elements. In the case of a File Manager based system, surrogate classes are substitutes for the physical file concept.

Business Rules Extractor - The business rules are extracted from the Application Code using the Business Rules Extractor and stored in the Object Repository as objects. The business rules extraction is a semi-automatic process.

The Business Rules Extractor makes use of the RE/M tools. These special analysis tools are wrapped and integrated into the ART tool set. To extract business rules form legacy code requires a four-phase approach.

Once separated from the legacy code base, the business rules can be represented as a complex network of objects. There are several benefits associated with this approach.

Class Export/Import - Once the Object Repository fully represents the legacy database or a logical subset of it, the Class Export can be run to transfer the surrogate class definitions into a RoseÔ model via a Rose import file for rationalization against the enterprise integration model.

Furthermore, any classes defined in the enterprise model can be transferred to the repository via the Class Import to insure that the enterprise model can accommodate the legacy class structure.

The bi-directional exchange of this information insures the referential integrity of both environments. That is, the Object Repository knows what the Rose know and vice versa.

Business Rules Export - Additionally, once the business rules have been extracted and normalized, they are exported from the Object Repository via a WordÔ file into RequisiteProÔ. They are associated with the correct business requirements at this point.

Runtime Generator - Finally, a runtime generator builds the surrogate object model stored in the Object Repository into an executable runtime environment. It accomplished it in the following way:

A very important point to remember about the Runtime Generation is that the executable business rules code can be generated:

Moving the executable business rules outside of the M environment facilitates the transparent integration of alternate database technologies.

Runtime Environment

The runtime environment exists as two separate layers (interfaces) that expose the legacy data. They are:

Private Interface - This environment contains the classes and properties that represent the physical database.

Public Interface - This environment contains the classes, methods and properties that represent the logical enterprise integration model.

The Private or Physical Interface

The following diagram illustrates in detail what is known as the private or physical interface. It co-exists within the M environment and is generated by the development environment.

M Database

The M Database holds the legacy data elements to be wrapped. Surrogate classes are generated as substitutes for the physical legacy data structure. They are the object representations of physical database. For File Manager based systems, these classes are based on the concept of a File Manager file and sub-file. Although not shown in the diagram, all surrogate classes are subclassed to support classes that provide the common support services through inheritance.

Surrogate Classes, Manager Classes and Instance Objects

All surrogate classes have a manager class that manages the instances of the surrogate class. An example of a surrogate class within a medical system would be Patient. It would have a manager class known as PatientMgr, which would manage the specific patient object, generated from the surrogate class. The manager object would be responsible for the creation and destruction of the object as well as other functions related to the maintenance of the surrogate object.

Data elements defined within the File Manager file are represented as properties within the surrogate class. A property contains several accessors: Assign, Value, Kill and Validate to name a few. Accessors are chunks of code that contain the business rules for that type of access. As stated previously, business rules are stated in the form of IF/THEN statements.

Accessors

Assign Accessor contains business rules that filter the data element before it sets it into the database. As explained earlier, accessors contain the business rules that are a series of IF/THEN statements that are executed before the data can actually be set into the database. The Assign accessor would naturally call the Validate Accessor to validate the data element. This accessor applies to in-bound data only.

Value Accessor returns the value of the data element. It would invoke normalization rules about how the data element is to be presented to the outside world. This accessor applies to out-bound data only.

Kill Accessor deletes the data element from the database. Obviously it would check numerous rules before actually deleting the data element.

Validate Accessor contains the rules that actually insure that the data element conforms to specific type and format for that type.

Client Class - Business Objects

A client class provides for an organization (aggregation) of legacy data and business rules into modern business objects. It represents a functional grouping of properties or methods that map to legacy data elements. It manages the complexity of interacting with the manager classes and instances of the surrogate classes. More importantly, it provides one interface for the defined functionality and acts as a bridge between the private and public interfaces. For example, a patient registration client class would provide access through the assign, value, kill and validate individual properties for all the data elements of registration.

The Public or Logical Interface

Once the private interface is in place, a public interface outside the EsiObjects (M) environment is created. This is normally done using the CORBA or RPC IDL, C++ or Java classes. The public interface implements the logical implementation or actual enterprise integration model that accesses the private interface. Three possible methods of access are:

The public interface hides the physical representation of the private interface. Security is usually enforced through the public interface.

In terms of distributing the business rules as executable code, the public interface can play an important role in this process. Client classes within the EsiObjects environment can be replicated as façade classes within the public interface (outside of the M environment). Façade classes are mirror images of the client classes. Rather than generating EsiObjects accessors within the private interface, accessor methods containing the business rules can be generated within the public interface. These façade classes can be implemented in C++ or Java. This approach to distributing the business rules hides the database. At that point, the database can be migrated or combined with other implementations in a transparent fashion.

Target Configurations

Two Tier Commercial-Off-The-Self (COTS) Solution

A COTS system that interfaces with the public interface can be viewed as a closed environment that represents the 1^st and 2^nd tier. It interfaces with the server tier that contains the data and business rules of the legacy application. See the diagram below.

Because the business rules of the legacy system must be preserved, all of the organizational, resource or process rules must reside on the server. There is a disadvantage to this approach in that all data elements received from the COTS system must be validated before they can be filed. This would normally take place in the User Interface (UI) environment. Additionally, all other rules that would be distributed to the application tier must also be executed at file time. This places a burden on the server that would normally be distributed across the UI and Application tiers. In the event that one data element is rejected, special measures must be taken to correct the one data value.

Three Tier Client Server Solution

A three-tier client server solution offers a greater degree of flexibility since the distribution of business rules can be controlled. As illustrated below, the client server configuration offers 3 separate tiers. The UI rules can reside on the Client tier, the application rules on the Application Server and the database rules reside on the Database Server.

N-tier Component Based Solution

Component technology offers reusability. The ultimate goal is to implement component software within a common framework. The framework provides a common environment for components. Since components are manufactured by different organizations, they could not be expected to interoperate with each other on their own. Therefore, a common framework is required to act as a bus for communications between components. Visual BasicÔ is a successful example of component integration within a common framework. It provides that homogeneous environment needed for components to co-exist.

A framework is derived from a well-defined architecture. Without the architecture, a common framework that offers scalability cannot be realized.

Conclusion

Over the years, M applications have evolved in size and sophistication. Application business rules have become embedded in procedural code structures. The tightly bound, procedural approach to building applications has come in conflict with the modern distributed computing. Because of the nature of these systems, concepts like reusability and extensibility have been hard to realize. Support and development cost have been rising as a consequence.

The move to distributed computing, facilitated by the move to object orientation have given new meaning to reusability and extensibility. This technology provides an infrastructure for building application repositories that hold the business rules, data and UI definitions. Having these business specific components stored in a development repository and providing runtime generation into any external environment frees the organization from one specific technical solution. Business rules can be mapped across a distributed environment, leaving the database open to migration.

1 David Taylor, Business Engineering with Object Technology, John Wiley & Sons, Inc.

2 Currently the EsiObjects environment is where we are implementing the business rules code. However, the Runtime Generator can be extended to generate code into other languages (Java, C++, etc.). This allows executable business rules to be distributed to other tiers within the target architecture.

Document Goals

^{The goals of this paper are to:}

Transformation Strategy

Goals