Evaluating OO Systems: Based on Good OO Principles

Goals

The goal of this paper is to describe the requirements needed to implement a robust, well-defined Object Oriented Database system and scripting language. We will attempt to show how these features provide organizations and programmers a well-defined path into the future and more importantly, what problems can be encountered if these features are not available.

Good OO Principles

There are some underlying principles of Object Orientation (OO) that are always at the forefront of our development philosophy. Simply stated, they are:

1.       Object Responsibility. In an environment where objects collaborate with each other, each object has a responsibility to provide the services requested of it. Objects have a contract between them and that contract must be honored by all collaborators.

2.       Hiding Complexity. A fundamental precept of Object Orientation is the concept of encapsulating complexity. Whenever possible, an object should hide complexity from the user. The user should see a simple interface that he or she can use (i.e. send a message). The object should handle all the complex operations necessary to fulfill its responsibility to the user.

These principles apply to a development environment where a programmer is collaborating with the development tools. Within each of the environments below, these principles have provided the underlying motivation for developing the features.

For a more formal treatment of good OO principles, go to the free OO Tutorial and review Lesson 2 of the free Object Oriented Concepts tutorial.

Class Development Environment Features

Foundation

Variable Scoping

Problem:

Encapsulation is the cornerstone of the object paradigm and has evolved out of years of software engineering quality issues. It can be viewed as a form of information hiding. M is widely know for its total lack of information hiding. How does one solve this problem?

Solution:

Placing a compiler between the programmer and the raw M system goes a long way to solving some encapsulation problems. However, an equally important aspect of OO is protecting an object’s data from accidental deletion or modification.

Consequences of implementing the Solution:

Implementing the Variable Scoping solution enforces encapsulation and consequently, information hiding. Not implementing it forces the encapsulation responsibility onto the programmer. Aside from the fact that this is not good OO design (hide complexity), it opens the door to software bugs and increases the cost for code maintenance.

Consequences of not implementing the Solution:

Not implementing this feature exposes the problems inherent of M. Local variables must be maintained by the programmer within each execution context.

EsiObjects Approach:

We have always been religious about OO features that are founded in software quality issues. Variable scoping has been a fundamental feature from day one. Variable scoping means never having to NEW a variable.

Event Handling

Problem:

Another fundamental precept of Object Orientation is that an object has a well-defined responsibility within the community of objects. Each object knows what it can do and offers other objects that functionality through its interface. Object A can use the functionality embodied in object B by sending object B a message. When this happens, it is done knowing that object B has certain responsibilities and that it will do what is asked of it. However, how does object A know when object B does something that will affect A. Does object A have to poll object B?

Solution:

Implementing Events solves several problems. First, it assures that an object need not directly monitor another object for an unsolicited event. If an object is interested in certain events, it can simply take out a watch on that event, provide a callback entry point and then go merrily on its way.

Consequences of implementing the Solution:

The Event Handling approach avoids an incredible amount of programming that would be required to poll. It cuts down on support and, properly used, can prevent logical database integrity problems.

Consequences of not implementing the Solution:

If the application requires unsolicited communication between objects, a specific solution will have to be devised to implement it, thus increasing the code base, increasing the number of bugs and consequently increasing support costs.

If the communication is ignored, objects will not be able to communicate in an unsolicited fashion. This can lead to misinterpretation of data and, in some cases, data integrity problems. For example, assume that a doctor is seeing a patient and is viewing the patient’s chart on a PC screen. One of the patient’s test results was entered incorrectly into the patient’s record. Subsequently, a lab technician recognizes the mistake and changes the value. How does the value on the doctor’s PC screen change? Event Handling does this job transparently.

EsiObjects Approach:

Event Handling has been an integral part of EsiObjects for a long time. Three commands implement the concept along with the runtime support. The commands are: Watch, Ignore and Event. An object declares an event that should be watched for using the Event command. Other objects can watch for the firing of that event and provide a callback entry point to process the response to the event using the Watch command.

Objects without Event Handling is like a house without a telephone – isolated!

Comprehensive Set of Object Services

Problem:

Objects must fulfill their contract to other objects. To do that, an object must have a knowledge of any other objects that are part of itself. They form a part of the whole. An object must be able to demonstrate all of its behaviors to collaborating objects and be able to expose some or all of its state to those collaborating objects. Aside from honoring these responsibilities when solicited to do so, it must also be able to communicate to unknown objects in an unsolicited fashion.

Solution:

These responsibilities are honored by providing services to the collaborating object. Relationships are a way of knowing those objects that collaborate to honor a contract. They should be bi-directional and self-maintaining where possible. Methods demonstrate a part of the object’s behavior. Properties expose part of the object’s state. Events fire for those objects watching and pass information to them without knowing who they are. Wizards should be available where possible for creating the service.

Consequences of implementing the Solution:

These four services are absolutely necessary for the functioning of an Object Oriented Database system. Having these available as a part of a class eliminates repetitive programming tasks. Implementing Properties and Relationships using Wizards increase a programmer’s productivity considerably.

Consequences of not implementing the Solution:

Productivity is reduced considerably. The programmer is forced to perform repetitive tasks.

EsiObjects Approach:

EsiObjects implements Methods, Properties, Events and Relationships. Each has an associated editor or property sheet that permits modification of the service.

Relationships can be set up using a Wizard. Properties will have the same type of Wizard in the future (V4.1). Bi-directional relationships are self-maintaining. They use the EsiObjects Event Handling to implement self-maintenance. The programmer can specify any number of collections that are available in EsiObjects as a way to store the relationships. See the section on Reusability.

Methods are implemented with source code versioning and all the functionality needed to syntax check, compile release or debug versions.

Properties are especially integrated into the EsiObjects language. Properties are divided into accessors. An accessor is a special kind of method. Each accessor relates to a particular language construct. Accessors that are currently implemented are: Assign, Value, Create, Kill, $Get, $Data, $Query, $Valid, and $Normalize. For example, this line of code would use the Value accessor if it exists because the Name property is accessed on the right side of the = in the Set command.

Set I%X=PatientObject.Name

Events are used to broadcast information to objects without knowing who they are. See the section Event Handling for more information.

Source Code Versioning

Problem:

Writing code to implement an object’s services should be an iterative process. Each iteration should leave behind a full representation of the last iteration in the event that the programmer needs to fall back to an older level of functionality.

Solution:

Provide source code versioning as a part of the development environment.

Consequences of implementing the Solution:

A clear trail of code that has evolved will always be available to the programmer. Time is saved if the programmer is able to return to a previous working version. Versioning forms the basis for a Configuration Management module.

Consequences of not implementing the Solution:

The programmer can lose valuable code. A special export mechanism must be devised to save the work for fallback.

EsiObjects Approach:

EsiObjects implements source code versioning for Methods, Property Accessors and Events.

Homogeneous Language Elements

Problem:

Should OO extensions to the M language be implemented using a proprietary macro language that is syntactically incompatible with the M syntax? Or, should the M language be extended in a homogeneous fashion?

Solution:

Implement the extensions using M syntax.

Consequences of implementing the Solution:

Extensions can be taken to the standardization committee as is. The programmer will have one, homogeneous language to work with.

Consequences of not implementing the Solution:

Extensions will have to be translated to an equivalent M syntax. The programmer must learn two different syntaxes. Besides, it’s ugly!

EsiObjects Approach:

We chose to extend the language using the M syntax, using only those constructs available. The one exception to this is the message syntax.

Workflow and Productivity

Support and Access to Multiple M Platforms

Problem:

What happens when one is developing in an environment that runs more than One M system? How does one implement the object paradigm on all of those systems? Additionally, how can one access all of those systems transparently as if they were the same system?

Solution:

Implement the object layer at the M level and leverage the underlying M features. Handle the implementation features transparently. Provide a way for the programmer to transparently work within each environment.

Consequences of implementing the Solution:

The system will run on any M system that is supported. The programmer can connect to any environment on one of those systems and work in it in a transparent manner. Exchange of code and data is made easy.

Consequences of not implementing the Solution:

If the object environment only runs on one implementation of M, one is confined to that implementation if one wants objects. Even if the object implementation ran on multiple M platforms, the programmer would have to run two separate tasks to do any work. Problems would also occur with the interchange of code and data.

EsiObjects Approach:

EsiObjects runs on DSM, MSM and Cache at this point. It will soon run on the Open Source version of GT.M as well as the proprietary VMS and UNIX versions from Sanchez.

Structural Partitioning

Problem:

Classes provide the definitional component of an object. Most sophisticated OO Database environments contain hundreds if not thousands of classes. Object systems are highly hierarchical. The class definition forms a hierarchy within itself. Within the class object, there are component objects such as methods, properties, relationships and events. In some systems like EsiObjects, the class is partitioned into interfaces and the interfaces contain the services. In addition, classes hold variable declarations and nested classes. Furthermore, in EsiObjects, library objects exist to organize and partition classes.

Solution:

First, to logically group classes, the concept of a library should be available. A library is an object that is exportable and importable. It should also provide a mapping for all of its classes and components to the underlying M global structures.

Second, class services are also typically organized into logical groups, and a partition within the class should be available to provide the programmer with a way to organize them. For example, a common partitioning is to store all the factory services in one partition, those services that are internal to the service in another partition and those services that are a part of instantiation (constructor) and destruction (destructor) of an object in another.

Consequences of implementing the Feature:

Fast access to what is being looked for. Much faster performance on the client. Easier importing and exporting of services.

Consequences of not implementing the Solution:

Eliminates bloat at the lowest levels. If one doesn’t have classes partitioned logically into libraries, management of those classes (exporting and finding) becomes complicated. If one doesn’t have partitioning of class services, the class interface becomes very bloated and the programmer is forced to wade through all the services just to find one. Lack of these partitioning features also causes performance problems on the client. When these features are added after the fact, they invariably will mean a conversion.

EsiObjects Approach:

EsiObjects implements the following hierarchical partitioning:

1)      Library

2)      Classes

3)      Services

a)      Variables

b)      Nested Classes

c)      Interfaces

i)        Methods

ii)       Properties

iii)     Events

iv)     Relationships

The state of the art tool development tool set (described in the next section) is designed to facilitate using and managing this hierarchy.

Reusability

Problem:

The pace of business today is fast. Organizations need fast turn around on changes to existing applications with no impact on the integrity of the system. Recreating the wheel is no longer an option if a business is to survive.

Solution:

Object Orientation lends itself to reusability because the features that contribute to the OO paradigm also contribute to reusability. This is particularly true in the case of encapsulation. Reusability means building and testing a single time and reusing many times. Reusable components accelerate development considerably. Ideally, not only should the components be reusable, but should also be built based on common design patterns.

Consequences of implementing the Solution:

Programmer productivity is accelerated and systems are completed sooner with a great deal of reliability. The business wins. When common design patterns are implemented, they are understood by most programmers immediately. Productivity is again increased and support is minimized.

Consequences of not implementing the Solution:

Not having a comprehensive set of reusable components increases the time to market considerably. Additionally, the programmer is usually forced to write a component that is specific to the application. “Write and test once—use once” this results in spending much time and money recreating the wheel and causes support problems.

EsiObjects Approach:

All classes in EsiObjects are organized into libraries. The ESI library contains all classes and services that implement EsiObjects. It contains some reusable Transport classes that may be of interest to the application programmer. These special classes are used within EsiObjects to efficiently transport full objects between the server and a client.

The Base library that comes with EsiObjects contains a large number of reusable components. A full array of Collections are available such as List, Array, Set, Bag, Log, Map, MultiMap, Dictionary, etc. Additionally, all Date and Time components are available. The Base library also contains Criteria classes for filtering as well as a Data Manager that can be used to store, self-maintaining indices for objects.

Workspaces and Work Folders

Problem:

As stated earlier, large object oriented applications may contain hundreds of classes and possibly thousands of services. These hierarchies become very large. Finding what you want can be a chore. If you are working on multiple classes and services throughout the hierarchy, you can spend an inordinate amount of time migrating the tree structure.

Solution:

To offer the developer a highly productive development environment containing graphical class development tools for the representation and migration of these hierarchies. Simple tools must be available to quickly access a class, interface or service. The system should provide the programmer with a Workspace that contains libraries that are logically organized. Within that Workspace, the programmer should see the hierarchies displayed graphically and should have the tools available to create hierarchical Work Folders where any object in the Workspace can be stored as a shortcut. Within that Work Folder, all operations available to the library hierarchy should be made available to the contents of the Work Folder. The programmer should be able to set up the Work Folder as shared within a session connection or private to the programmer. Shared folders can be used as common folders work folders for a work group.

Consequences of implementing the Solution:

All work can be stored in a localized Work Folder. Migration of large library hierarchies is minimized or eliminated. All operations within the environment are available on each object in the folder. Work groups can collaborate using shared folders.

Consequences of not implementing the Solution:

A great deal of time is wasted migrating the hierarchy. Sharing between workgroups is minimized.

EsiObjects Approach:

EsiObjects V4.0 implements all the features described in the Solution section.

Object Browsing and Debugging.

Problem:

Object Oriented systems usually consist of a complex network of objects linked together programmatically or physically. They form networks that implement collaborative behavior where the whole is a sum of the parts. Implementing and debugging these environments can be a challenge without the proper tools.

Solution:

Provide an Interactive Debugger and Object Browser that collaborate to provide the programmer with the necessary tools to:

• Execute code on a step-by-step basis while having the ability to alter the object environment, view the internal state (variables) of the object and migrate object linkages to other objects and view their state.
• Independently browse and view the internal state of an object structure outside of the debugging environment.

Consequences of implementing the Solution:

Rapid development is accomplished. Bugs are discovered quickly. Productivity goes up and support goes down.

Consequences of not implementing the Solution:

The programmer is reduced to working in the dark. Artificial means must be employed to debug object code and display the content of the object. Productivity is reduced. Support is increased.

EsiObjects Approach:

EsiObjects contains an interactive debugger that can be used to execute code stepwise. It lets you interact with the object’s context by changing its state (variables) via an Xecute Shell. It displays the objects symbol table and lets you choose the variables scopes of interest. You can migrate linkages to other objects to explore their state. It also displays the stack contents as you walk through the code.

EsiObjects contains an interactive Object Browser. It lets you browse thorough object structures, displaying the object’s state as you go.

Instance Management Environment

This environment is a work-in-progress based on the work we did for a DOD project.

Instance Management Environment consists of all functionality dedicated to the management and integrity of instances created from classes defined in the Class Development Environment. This environment is based on the Object Data Management Group (ODMG) specification for an Object Oriented Database Management System (OODMB). This specification implements all those things necessary for managing instances: Extent Tracking (an integral part of EsiObjects V4.0), Indices control and the Object Query Language (OQL which is based on SQL2) or the Object Constraint Language (OCL which is a part of UML).

The Instance Management Environment contains a client side GUI that lets you construct OQL statements by simply dragging and dropping (based on the way Access does it). The collected results can be fired into an ODBC interface. The GUI will implement other runtime capabilities.

Back to Top of Page
Back to White Papers