From the author: Dear reader! This is one of our first writings devoted to the topic of business process orientation. Drafted in 1991, it was published by Auerbach in 1997. In no way do we want to discourage you from reading this manuscript. We hope, it can still be of interest for you. However, we want you to be aware of many other papers written and published by us in the last 15 years. For full list consult http://processplatsen.ibissoft.se/node/33. In particular, if you are interested in this paper, you might also be  interested to have a look on:
Khomyakov M., and Bider, I. Achieving Workflow Flexibility through Taming the Chaos. OOIS 2000 - 6th international conference on object oriented information systems. Springer, 2000, pp.85-92. Reprinted in the Journal of Conceptual Modeling, August 2001: http://www.inconcept.com/JCM/August2001/bider.html

 There are several "magic" words which are more and more often used by ordinary programmers in connection with the design and implementation of business software applications. They are: object-oriented, user-friendly, data-model, prototyping. There are almost as many interpretations of these "magic" words as persons who use them. But more often than not, "object-oriented" stands for an object oriented implementation of a system; "user-friendly" stands for the use of menus, windows and icons; "data-model" stands for a static database schema; "prototyping" stands for the animation of a static database schema with the help of 4-th generation tools.

 But if you get down to implementing a system based on the above interpretations of these words, you may be faced with the following consequences:

1. A system is implemented in an object-oriented way, i.e. is written in an object-oriented language - C++, Smalltalk, etc., but it does not represent the application realities in an object-oriented manner, and therefore it is not object-oriented as far as the users are concerned.
2. A user interface includes all state-of-the-art means - pulldown and popup menus, windows, the mouse, etc. However, it is still not object- but functionally-oriented, i.e. a user first chooses a required function in a multilevel menu and only then he can select an object to which this function should be applied. What a nightmare for the user if he afterwards wants to apply another function to the same object.
3. Many static data models can be constructed for the same application. It's impossible to choose the most adequate one without taking into account the application system dynamics. Many of the existing tools for conceptual system design fail to express the dynamic behavior of a system in the same consistent way, as they express system statics. Thus, the use of these tools can't itself guarantee the right choice.
4. It may be too late to start prototyping after the data model has been built (especially when it isn't the best one). The prototype is the only means for dialog between the designer and future users of the system, as the language of data models is usually beyond comprehension of an ordinary user. But this dialog can't be of much use if the choice of the data-model wasn't the happiest one.

 In our opinion, the above problems arise due to the fact that the concepts which the "magic" words usually stands for are applicable only to certain stages of the development process (e.g. implementation), or to specific parts of an application system (e.g. user interface). Of course, different parts of the application can be designed separately, and different approaches and software tools may be used at different stages of the development. This strategy, however, may lead to that the resulting application system will not have the desired properties. For example, object-oriented manner of implementation won't help to produce programs with a clear structure, if the conceptual structure of the system is vague and doesn't adequately express the application field reality. Neither the use of icons or the mouse can help to make such a system user-friendly.

 We prefer a different strategy, namely: at the first stage, a set of notions for expressing the application reality is chosen (or developed), and at the second stage, the ways of presenting these notions in a user interface and in programs structures are developed. Such a strategy can even supply a new meaning to the "magic" words.

The approach discussed in the paper is aimed to support the design and implementation of interactive business applications. In it, we use the method of expressing application realities that is based on four main concepts: object, event, activity and history. A brief presentation of these concepts follows.

OBJECTS are used to represent the elements of the application realm (e.g. people, companies, projects, etc.). Objects possess properties and may have a complex structure, i.e. they can consist of subobjects.

Objects are not static; they undergo changes all the time. When an object changes, i.e. some of its properties and/or its structure change, an EVENT is registered. Event registration is performed by creating a special object - "registered event" at the time of the change. A registered event contains the information on the type of event (customer's call, invoicing, etc.), on the registration time, on the object that has been changed, on the person who has introduced changes, etc.

ACTIVITIES represent the units of actions. An activity is a function which can be applied to an object with a view to modify it in a certain way. Activities can be planned for every object and executed later. Planning is performed with the help of a special class of objects - planned activities. A planned activity contains the information on the type of activity (telephone call, invoice, etc.), on the planned date and time, on the deadline, on the person who is responsible for performing the activity, etc. When executed, a planned activity changes the object to which it belongs. This change may include adding new planned activities and deleting the old ones.

When an object has changed its state, its former state is stored in the database. A sequence of the former object's states makes up a HISTORY of the object's evolution. The history may be used for planning and executing activities.

The above mentioned "magic" words are interpreted in our approach as follows.

1. "Object-oriented" stands in the first place for an object-oriented way of presenting the application realities and an object-oriented user interface; object-oriented implementation is considered only in the second place.
2. User-friendliness of an application can be achieved by means of a specially constructed "navigation system". The navigation system helps a user to "navigate" to the required object or activity as quickly as possible (windows, menus, the mouse are used as navigation controls). The user can browse not only through the current states of the objects, but also through their past (history) and future (planned activities). The activities are planned and executed partly by the application system, partly by the user. The registration of events makes the navigation system more flexible. For example, the user can get a list over all latest events he has registered in the system, choose one of them and quickly access the object that has been changed during this event.
3. A data model is only one part of a system specification which describes all possible states of the objects selected to represent the application. The other part includes all possible transitions from one state to another. The latter can be expressed in terms of events, activities and history. The task of the system design is to develop both parts as an integral entity.
4. Prototyping is an integral part of the design process; prototyping starts before the data model is ready and is over only after the system is fully implemented. A prototype is a system specification written in a language which is fully comprehensible to the future users of the system. The above mentioned navigation system with the database access switched off can be used as a prototyping tool at the very first stage of the system design. Since the database access is switched off, there is no need to have a database schema ready before starting on a prototype. Moreover, a database schema can be later derived from the prototype.

A method informally described in the following sections supports the development of interactive object- and time-oriented systems in the application field which we call management automation. It's suitable for the design and implementation of such systems as: Sales Management, Marketing Support, Medical Patient Journal, etc., i.e. systems for which it is extremely important to have a comprehensive information on everything that had happened and to be able to plan what is going to happen in the future.

This method was named ObjectDriver (OD) because it facilitates the development of the systems whose purpose is to help a user to "drive" certain objects through a number of predefined states to the successful conclusion. For example, a "sale" should be driven to receiving the payment, a "patient" - to recovering and leaving the hospital, etc.

The core of the OD approach consists of a small number of constructs which are used for expressing the variety of application environments. The basic constructs are: Object, Event, Activity and History. None of them is new; the novelty of the OD approach lies in the way these concepts are used to express various elements of application worlds, e.g. plan, calendar, etc.

The rest of the OD approach are the techniques of translating the basic constructs into:

• elements of a user interface,
• a database structure, and
• a structure of application programs.

In this techniques, we use the usual concepts which have been worked out in the software design practice, e.g. windows, fields, menus, shortcuts, records, field entry and exit programs, etc.

The paper is organized as follows. In Section 2, we introduce the notions of object, object state and object modification. In Section 3, we discuss the way of organizing an object-oriented user interface. In Section 4, the notion of event is introduced and the way of registration of events in application systems is presented. Section 5 discusses such notions as activity, plan, calendar. In Section 6, we present the technique of saving the former states of objects. In Section 7, a method of conceptual design by means of prototyping is discussed followed by a discussion of the implementation issues in Section 8. In Section 9, the history of the project is briefly described, and in Section 10, the advantages of the OD approach are outlined.

We tried to discuss the OD approach as informally as possible, that's why theoretical concepts are often discussed along with the way of their implementation. The paper doesn't contain all the details of the OD approach; the primary goal is just to outline the main features of it.

An object is a central notion in OD approach. Abstract objects serve to represent elements from a given application world, e.g. companies, persons, sales, etc. Objects can possess properties, be related to each other (e.g. a relation between a person and the company he is working for) and may have a complex structure, i.e. they can consist of subobjects.

The structure of objects in an application is defined by the database schema of this application. For the time being, the ObjectDriver deals only with formatted data, i.e. the database schema of an application is fixed and can't be changed by its users. The database schema is designed in terms of object domains (classes), attributes, and links - unidirectional relationships. An object domain defines a set of objects with the same main properties (i.e. same meaning). For example, in sales management applications, there will be such domains as COMPANY, PERSON, SALE, etc. Attributes express specific properties of objects from the same domain, e.g. "name" of a company. A link connecting two object domains expresses objects' relations. For example, the "employed by" link from the PERSON domain to the COMPANY domain expresses the fact that an object from the PERSON domain may be connected to an object from the COMPANY domain. Such a connection have the meaning that the given person works for the given company.

To represent the object-subobject relationships between objects, we've introduced a special kind of links called a "link to subobject". If in the database schema there is a link of this type directed from one object domain to another, then an object from the latter can exists only if it's connected according to this link to some "owner" - an object from the former domain. A typical example of a subobject is an item of a sale, which describes what kind of goods has been ordered and how much. Such an item can be created only with a connection to some sale and should be removed from the database as soon as the sale is removed. The connection between sales and items is represented in the database schema by the "ordered" link which is directed from the SALE domain to the ITEM domain; this link has the type of the "link to subobject".

Several object domains can be combined to produce a new object domain; attributes and links can be "multi-valued" (in which case they are called soft attributes and multilinks respectively). These enhancements along with the notion of the "link to subobject" gives our static data model the same expressive power as that of advanced languages for conceptual design. For example, we can easily model the meaning of such concepts as generalization and aggregation with the help of combined domains and multilinks respectively.

Objects in OD-based applications are not static, they change in time. The goal of an application is to control these changes. To express the idea of a change, a formal definition of an object state is required. In OD, the state of an object at a given time is represented by a marked directed graph. It includes attribute arcs which connect the object with the values of its attributes, and link arcs which connect the object with other objects in accordance with the links that were defined in the database schema. Arcs are marked with the names of the corresponding attributes and links. If a link arc ingoing in an object corresponds to a link of the "link to subobject" type, then all the arcs outgoing from this object are also included in the state of its "owner".

The formal definition of the state of an object allows to determine exactly what object(s) have been changed when something happens in the system. For example, if a person has left his job, it means a change in the state of the person, not in the state of the company he was working for. This is so as long as we treat the "employed by" link as directed from the PERSON domain to the COMPANY domain. If the direction of the link is reversed then it's the state of the company that has changed when somebody has left his job. Which direction to choose for links, depends on the goals of an application; such decisions should be made at the stage of conceptual design.

The state of an object can't be changed arbitrarily. A description of the dynamic behavior of an application system should be build which allows to distinguish the valid transitions from one state to another from the invalid ones. In the OD approach this task is partly accomplished by user interface programs which don't allow the users to modify an object arbitrarily (see Sections 7). The greater part of the dynamic behavior of a system, however, is expressed in terms of activities - functions which transform one object state into another. Activities can be planned, thus defining the next desirable steps of the object modifications. Planned activities serve as a means to control the object evolution in time and to express the goals of an application system. (For more details on activities, see Section 5.)

The validity of a transition from one object state to another may depend not only on the current state of the object in question but also on what changes it underwent in the past (e.g., the same goods cant be invoiced twice). The required information about the past is obtained in OD-based systems by means of event registration (see Section 4) and by storing the previous states of the objects (see Section 6).

We believe that the most natural kind of a user interface for applications in the management automation field is an object-oriented one. That implies in the first place that a user can view the objects, understand their complex structures and easily navigate through the space of interrelated objects. In OD-based systems, he does it with the help of a "navigation system" which allows him to move from one object to another along the link which connects these objects. For example, a user can view the list of all persons registered in the system, then filter it by a given street address, then choose one person from the resulting list and inspect all the information related to this person including the company he/she is working for. This company represent the "employed-by" link which goes from the PERSON domain to the COMPANY domain. Then the user can move to the other end of the "employed-by" link - the company and view all the information related to it, e.g. all the persons employed in the company, and so on.

Users of an OD-based system can view objects in two main forms: the list form where objects of the same class are presented, or the object form where all the information related to a particular object is given. To be able to navigate, a user doesn't need to have an explicit knowledge of the intern object structure of the system. He should just know what keys to press or what options of the menus to choose in case he wants to go from the list form to the object form (or vice versa), or from the head object of the object form to one of its subobjects or to some other object linked to the head one. To make it easy to navigate through the object space for a novice, context-sensitive menus are introduced which show the directions in which he can move; an experienced user can use shortcuts to avoid these menus. Navigating in an OD-based system is like driving a car; you don't need to know much about the motor; if you can drive, you'll find the way to your destination.

An OD-based system introduces the techniques which differ radically from those used in a traditional - functionally- oriented administrative system. A user of the latter should first choose the function he wants to perform, often in a multilevel menu, and only then he can reach the object he wants to apply this function to. Such user interface has a great disadvantage when a user wants to apply several functions to the same object, e.g. update an address of some person, write him a letter and make a telephone call. In the traditional system, a user is every time forced to return to the function menu (often through several ESCapes of the multilevel menu), choose another function, and then access the same object once more; the procedure is repeated as many times as there are different functions the user wants to apply to the same object.

With an OD-based system, a user first chooses the object he wants to work with, and then performs all the necessary manipulations with it - modifies its attributes, installs and deletes link arcs, executes activities, etc. It is like working with a state-of-the-art word processing system where one first selects a text block, and only then points what function he wants to perform - delete the block, copy it, print it, etc. However, in case a function-oriented interface is preferred, for example, for users who usually execute only one type of activities (taking order, invoicing, etc.), it is easy to introduce one. Such an interface can be expressed as a special way of navigating through the system's object space (an example is given in Section 5).

If one or more objects have undergone some change at a given point of time, we say that there occurred an event at that time. Event registration is the process of saving certain information about each event that occurs in the application system, e.g.: the time when it happened, event type (e.g. a letter arrived, invoice printed, etc.), the initiator of the changes (e.g. a user or the system itself), etc.

Event registration in OD-based systems is accomplished with the help of a special class of objects - REGISTERED EVENT. The objects of this class are called r-events. A new r-event is created each time a user or the application system changes some object, thus causing an event occur. The structure of r-events (i.e. their attributes and links) depends on the application needs. Usually, however, there are such attributes as: "registration-time" - time when the event was registered in the system, "real-time" - time when the event happened in the real life, "type", "comment" - a free text, and such links as "modified at" - a link to the object which has undergone changes during the event, "initiator" - the link to the object representing a user who has introduced the changes.

Event registration is implemented in the user interface in the following way. Each time a user tries to save the modifications he has introduced in some object, an "event window" appears where certain attributes of the new r-event, such as: real time, type, comment, etc., can be inputted. Only by pressing a transmit key in this window he can save the changes along with the newborn r-event.

Once introduced, registered events can serve as a source of different kind of information. For example, a list of all r-events constitutes the system chronicle. A list of all r-events with the same "modified at" object gives the historic overview of the object evolution. A list of all r-events with the same "initiator" presents the full account of all activities of that person.

The registration of events can be used for increasing the flexibility of the navigation system. Suppose that an OD-based application registers an event of a "temporal interrupt" type each time a user interrupts his work with a current object and moves to another object, for example, to register the incoming phone call. Then a list of all r-events with the "temporal interrupt" type and the same "initiator" shows the job's that haven't been finished by the particular user. The user can choose one of these r-events and easily move to the object which he started to modify earlier. Such a list (if it's not empty) can be shown to a user every time he tries to log off the system.

In OD-based applications, it's possible to register an event even when no objects have been explicitly changed inside the system. Such a need can arise in case a particular application does not computerize all the activities of the company or the organization. For example, incoming mail may be not processed inside the system. But sometimes, it's useful to register a letter arrival from a particular person along with a note on its contents. We treat such an event as a change in the external (not represented inside the application) part of one or more objects. R-events which corresponds to "external" events has the same structure as those which corresponds to "internal" events, e.g., they have a link to the "modified at" object. OD-based applications process both types of events in the same way, e.g., they can be presented to the users on the same list.

Among all the objects chosen to represent an application environment, there is always a class of objects that is central for the kind of application in question. For sales management, it's sale objects that are important; for marketing management, it's prospect objects that are important; for project management, it's project objects that are important. To discover such objects in a given application field is a task of conceptual design. We called such objects "dynamic", not because all other objects are completely static (a company or a person can change a name, an address or a telephone number), but because the goal of the application system is to help its users to "drive" these objects through the given number of states to the successful conclusion. For example, a sale should be driven through shipping and invoicing to getting money, a prospect - to a sale, a project - to a ready product, etc.

The point with all other objects is to provide the users and the system with the information which is required for reaching the goal of driving the dynamic objects.

The name ObjectDriver was chosen just to stress the objective of driving the dynamic objects to the successful conclusion. A particular application system can be named by substituting the word "object" by the name of the central dynamic object of the application, e.g. SaleDriver, ProspectDriver, ProjectDriver, etc.

The drive is performed by using activities. An ACTIVITY is a function which transforms one object state to another. To execute an activity is to apply the corresponding function to a particular object. Activity execution may consist of three of the following actions (the last listed is the obligatory one):

1. An internal action - changing the object state.
2. An external action - printing a document, sending data to an external database, etc.
3. Event registration (see the previous section).

For example, if the activity of "invoicing" is applied to an object from the SALE domain the following results are achieved:

1. the value of the "invoiced amount of money" attribute is changed
2. a printed invoice is produced
3. a new r-event is created; it has the type of "invoicing", and it refers to the given sale object.

 Applicability of a particular activity to a given object may depend on the object's actual state or even on the object history, i.e. events that has been registered about this object. For example, invoicing activity can't be applied to a sale on which an event of the "invoicing" type has been already registered.

Some activities can be performed without intervening of the user. Execution of others is impossible without the user's help. For example, "invoicing" can be done by the system, but in case of "shipping" the user should confirm that all the goods have been shipped or manually fill in how much of each type of goods has been shipped.

Activity execution can be directly started by the user. But in the management automation applications, it is often necessary to plan an activity first and to execute it afterwards. In the OD approach, the idea of planning is realized with the help of a special class of objects - PLANNED ACTIVITY. Objects of this class are called p-activities. These objects has a special attribute called "type" which defines the name of activity being planned, e.g. invoicing, shipping, etc. The presence of additional attributes and links in p-activities depends on the particular application, but there are some "natural" attributes and links that can be applied to all kinds of applications: "planned date and time", "deadline", "responsible" - a link to the user who is responsible for executing of the planned activity (more precisely - to the object which represents this user in the system).

A p-activity can exist only if it is a subobject of some dynamic object, i.e. in the database schema of an application, there is a link of the "link to subobject" type (see Section 2) which connects the domain of dynamic objects with the PLANNED ACTIVITY domain. All planned activities included in the state of a given dynamic object at a given time compose a PLAN of the object evolution.

P-activities are ordinary objects, which means that they can be created modified and deleted, as all other objects. But they possess an additional property: when a user comes to a p-activity, he can execute it. In this case, the function defined by the "type" attribute of the p-activity is applied to the "owner" of the p-activity.

Among all the modifications which are introduced in the owner's state during p-activity execution, we distinguish a special group which changes only the owner's plan. This group is called REPLANNING. It includes at least deleting of the executed p-activity, since it's no longer needed. But this group may also include more complex modifications, i.e. introducing one or more new p-activities which show the next steps in the object evolution. For example, a "shipping" p-activity may plan "invoicing" (if all the goods have been shipped) or a new "shipping" (if only a part of all goods has been shipped). Such replanning can be done automatically or with the user's help.

A list of all p-activities which are connected to the same user according to the "responsible" link makes up a CALENDAR of this particular user. A calendar isn't an object, because all the p-activities on the list are already subobjects of different dynamic objects. It's dynamic objects that are planned in the first place - not the work of people, as in many other systems. People serve as a resource for activity execution. This resource is "limited", naturally, thus care should be taken not to assign too many activities the same person on the same day.

The users of an OD-based system are not forced to execute p-activities one by one. A user can take a list of all p-activities he is responsible for, filter it by a particular activity type, and then issue a special command which is called "execute all". If activities of the given type can be executed without human intervening (e.g. invoicing, printing a standard letter, etc.), then all such p-activities which are ready for execution will be performed automatically. If the activity type needs the user's help, the system will execute the p-activities one by one asking the user to confirm or fill in some information.

The "execute all" command may serve as a means of adding a functionally-oriented user interface to OD-based applications. For example, we can put in the main menu an option "functions" with a submenu of choices: "invoicing", "shipping", etc. As soon as a user chooses one of these functions, the system present him a list of all ready for execution p-activities of the chosen type. Issuing the command "execute all" starts execution of these p-activities.

In certain circumstances, a user needs not only to know that an event of the particular type took place, but also to see the difference between the states of some object before and after this event. For example, suppose that during a "sale driving" there were several "shippings", and during one of them the shipped goods disappeared on the way to the customer. To manage this situation it's not enough to know when the goods were shipped, one should also know how much of each type of goods were shipped at the time of the shipping in question. The latter can be calculated as a difference between the values of the "amount of shipped items" attribute before and after the shipping event. Such kind of information may also be needed for execution of certain kinds of activities. For example, "credit invoicing" needs to know how much money has been invoiced and what for.

One way to walk around such problems is to store all needed information in the current object states or in the r-events. But this approach has the following drawbacks:

• dynamic objects or/and r-events would become more and more complexly structured;
• it will be very difficult to expand the application with new activities which may need another kind of comparing of object states (not saved in the r-events).

A more general approach requires that a system is able to reconstruct the states of its dynamic objects before and after any event. That means saving the whole HISTORY for at least dynamic objects. In the OD approach, this problem is solved as follows.

 All information is stored in the database in small basic units - records each of which contains the values of one or more attributes and/or links of an object. Some of the records belongs to the current state of the system; they are called current. Others describes the previous states of the system; they are said to be historic. Both kind of records are stored in the same physical database structure. To distinguish the current records from the historic ones and to point the interval of time when a historic record was current we have introduced event numbering and event stamping of records.

All events are sequentially numbered. These numbers makes up the time axis of the internal system time. Each record is supplied with two event stamps - opening stamp and closing stamp. The first one is the number of the event when the record was created; the other one is the number of the event after which the record became historic. The closing stamp of a current record contains a special code which is called "far future". This code is represented by a very large integer number which is always greater than the number of the last event which occurred in the system. The "far future" expresses the meaning that the current record may be closed only in the future.

If a new event occurs and some attributes and/or links which were stored in a given current record have been changed, then the following actions are undertaken. Closing stamp of this record changes its value from the "far future" to the number of the new event, thus making the record a historic one. A new record is created to store the modified values of the attributes and/or links; it stores the values of all the attributes and/or links which were represented in the former record, even those which were not touched during the event. This new record automatically becomes current, that means that its closing stamp gets the value of the "far future". Its opening stamp becomes equal to the event number of the new event.

All the current records related to a particular object compose the current state of this object; these records can be easily fetched since they have the "far future" as a value of the closing stamp. All that is needed to reconstruct a state of the object at the time of the event with a given number, is to collect all the records related to the object with the opening stamp greater then or equal to the given event number and the closing stamp less then it.

A query against a database with the described above structure accepts an additional argument which provides the query with the event number of interest. Such a database can also answer such questions as: event number of the given object's birth, last modification or death. The event number of the object's birth is the smallest number among the opening stamps of all the records which are related to the given object. Event number of the object's last modification is the largest number among the opening stamps of all the current records which are related to the given object. Event number of the object's death is the largest number among the closing stamps of all the records which are related to the given object. If this number is equal to the "far future", then the object is still "alive".

An event number is tied to the real time only by the "registered time" attribute of the r-event which was born during this event. It means that if you want to find out what a particular object looked like at a given time, you should first find the r-event with the "registered time" immediately preceding the time of interest. Then you should find the event number of this r-event's birth and only afterwards make a query about the object state at the calculated event number. Of course, all this manipulations can be made by the system automatically.

In OD-based systems, r-events serve as a means of a journey in the past. A user can take a list of all the r-event related to a particular object (a written history of the object), choose one of them and view or move to the object's state that was current before or after the corresponding event. After moving to such a state, the user can continue navigating in the past by moving along the link arcs which existed at the chosen time. the user navigates in the past state of the system in the same way as he does it in the current state, except he can't introduce changes in the database or execute activities.

In fact, saved history along with registered events (written history) gives an OD system an outstanding ability. It works exactly as a time machine from science fiction; you have a history book, you put your finger on one of its pages and go directly to the described on this page time and place.

In OD approach, there is a set of rules for mapping the elements of a database schema into the elements of the screen forms which shows objects to users. For example, an attribute is represented by a field plus a leading text - the name of this attribute. A link is represented by the most important attributes of the "linked" objects. For example, on the form which shows a user an object from the PERSON domain, the "employed by" link, which connects the PERSON domain to the COMPANY domain, may be represented by such attributes as "company name" and "company phone number". Multi-valued attribute and multilinks are represented by scroll areas. An inverse link, i.e. a link ingoing into the given domain, is represented by a popup list which consists of objects from the domain for which this link is outgoing.

Due to the above rules, the OD approach can suggest a developer two opposite ways of conceptual design:

1. A data base schema is created first, followed by the development of all the forms for the user interface. This is the traditional way which appeals to those used to data modeling. When this approach is used, the fact that the chosen database schema is the right one acquires a great importance.
2. The system designer first draws screen forms and ties them with each other with the help of function keys and menus. The resulting prototype is then shown to the potential users. Only after the users are satisfied with the prototype, the designer can proceed to deriving the database schema from the forms which have been drawn in the prototyping process.

The navigation system (described in the Section 3) with the database access switched off can serve as a perfect object-oriented prototyping tool. With its help, one can quickly paint object forms and insert them in the ObjectDriver's navigation system. There is no underlying database in such a prototype, but a user can navigate through the object space in the same way as he does it in the completed application; he can modify attribute values, install and delete link arcs, create new objects, and see how to start different activities. But he can't save the information or see the results of application of some functions (e.g. he can't see the results of the list filtering).

In practice, the designer may use some combination of these two approaches. For example, if a new application is very like the old one, a designer can first create a preliminary version of the database schema. He can then convert it into the interface forms and continue to develop it modifying the prototype. After the prototype is ready, the final database schema can easily be derived from it. However, for a completely new application, it is easier to start directly with the form design.

The database schema and the corresponding interface forms can be modified even after the prototype is ready and the database access has been added to the future application. That means that prototyping doesn't end with the ready "prototype"; the process continues until the whole application is ready for delivery.

To support the implementation of OD-based systems, we have developed two separate software tools: Navi - a navigation system, and Hi-base - a historical database.

Navi serves as a framework for the user interface and as a prototyping tool for conceptual design. It's built on top of JYACC's application manager JAM. JAM allows a designer to paint user interface forms which appear as windows on the user's screen. It permits also to assign various control information to fields, e.g.: justification, currency formats, protections, field entry and exit functions, etc. User-written programs can be tied to a form as screen entry and exit functions, field entry and exit functions, etc. With the help of such programs, one can implement the type of user interface which satisfy any chosen principles. When writing own programs, a developer can use the JAM runtime library. The routines in it give the possibility to control the interactions with the user at runtime. For example, one can change field protections, thus prohibiting a user to change some fields under certain circumstances. Such possibilities allow to introduce some of the dynamic constrains on the objects' evolution directly into the user interface.

Navi is an extension to JAM in the form of C-library which introduces our ideas of navigation in the JAM environment. It's written in Microsoft C under MS-DOS, but may be easily ported to other platforms supported by JAM (JAM exists under 10 operating systems and for more then 100 hardware platforms). The Hi-base is an object-oriented database with the ability to save previous states of the objects. The interface to Hi-base is based on the notion of a neighborhood template. Such a template defines what kind of information related to the object is needed or is going to be changed. The neighborhood template can also be used as a tool for fetching all the objects whose "neighborhoods" match the template. A neighborhood template is a graph which shows what attributes and links we need to fetch or modify an object (restrictions on attributes values and links may also be added to such a template).

Hi-base is also written in Microsoft C and is supported on the low level by Btrieve record manager from Novell inc. Hi-base is a multiuser database which can operate under most LANs available on the market. Hi-base has a C-language interface in the form of neighborhood queries. Porting Hi-base to other platforms is a more difficult task than porting Navi because of the need to use some other record manager instead of Btrieve.

During system development, everything that can't be expressed in the terms of the created software tools is written in a general purpose programming language which we call a shell language. We use the C-language for this end which is complemented with the JPL language that exists in the JAM environment. The application-specific part of an OD-based system is called application programs. Application programs provide an OD-based system with the interface between Navi and Hi-base. Application programs are called from Navi; the task of such a program is to put the contents of the screen into the neighborhood query or vice versa. For the time being, a designer should program the communication between screens and queries element by element. But high level functions which enable sending the whole screen contents to the query or vice versa are under development.

Even after the high level functions are ready, there still will be a room for programming in the shell language, since we feel it is impossible to create high level tools which are adequate for expressing all the nuances of all possible applications. That's why we follow the strategy which has been introduced in JAM - to supply application designers with so called hooks, where they can "hang" their own programs to complement or modify the features of the high level software tools.

The OD project is an implementation part of the larger research project which was started in September 1984 under the name CHAOS (Concurrent Human Assisted Object Systems). The goal of the latter was to find concepts and to develop a formal language for description of the applications which are aimed to maintaining order in a LARGE DISTRIBUTED ECONOMY. CHAOS deals with unformatted data and covers a wider class of applications than the OD approach. The ObjectDriver project was started in March 1989. The goal of the project was to build the DealDriver - an application which supports sale and marketing management. To reach the goal, we were forced to sink the ambitions of the CHAOS project to the level which could be implemented with our resources. As a result, the OD approach was born, and the first version of the tools for prototyping and implementation support were built. They have been tested on several applications and prove to be adequate for system development in the management automation field.

10. Conclusions

The approach described in the previous sections has several advantages:

1. It's consistent, as it's based on a small amount of basic concepts, and it supports all the stages of the design and implementation of management automation systems. A designer doesn't need to use one method and/or design tools for conceptual design (e.g. entity-relationship model) and another - for system implementation (e.g. relational database with some 4th generation language).
2. It supplies applications with a consistent object-oriented user interface. The complexity of the interface is limited; i.e. once instructed how to navigate in one part of an OD-based system, a user can easily move to another part of it or to another OD-based application without any additional education.
3. An OD-based system has a well defined implementation structure - all general programs are included in the high level tools and all the application programs are hanging on the tools' hooks. That allows to expand the system by adding new activities and new objects, without any restructuring of the existing part of the system and/or the user interface.

A designer who wants to follow OD approach do not need to use all four concepts (object, event, activity, history) at once. Using only the object concept and our approach to an object oriented user interface, one can create a system for information maintenance. Adding event registering, at least for some objects and some events, one, for example, can also store the details on when and who has changed the information and what was the source of information. Adding directly executed activities gives a possibilities to create simple management automation systems. Adding planned activities allows to build fairly complex administrative systems. But only all four concepts give the designer possibilities to easily expand and modify the system. Our approach may also be used for system design only. Implementation in this case should be done with a help of conventional means. A designer, for example, is not forced to use our object-oriented database, he can use a relational one and code all the object-oriented interface against the database by means of the SQL or some other query language, though he can still use our navigation system.

The OD approach has been developed by the author in cooperation with Maxim Khomyakov from Magnificent Seven (Moscow). A number of people took part in the implementation of the Navi and Hi-base and in the development of Dealdriver. The author is very grateful to all of them, especially to: A.Borkovsky, R.Sjöborg and R.Svensson.