I.Bider (IbisSoft, Stockholm), M.Khomyakov (M7, Moscow)

There is no common definition of what object is which is accepted by all members of the software development community. The most general definition that everybody might agree is:

An object is a piece of software system that:

• Includes both passive data and actions.
• Reacts on the events from outside and inside by executing actions. An action results in changing the object’s state and/or raising new events. The latter activates other objects in the system.

There can be many possible interpretations of this general definition, however there is one that is mostly spread, i.e.:

• Passive data is defined as a data structure that includes both atomic values (of basic types) and other (complex) objects.
• Actions are defined as static (predefined and not changeable) code written in an object-oriented programming language. This code is usually arranged as a set of methods (functions).
• An event is raised when one object sends a message to another object (or itself).
• An object reacts on the event by executing the method (function) assigned to the corresponding message.
• The action can be completely calculated based on the current state of the object’s data structure.
• Changes in the object’s state concern only the passive data structure.

This definition was worked out in the field of object-oriented programming, and it is powerful enough to code any software system. In recent years, this definition has been also used for design of object-based application systems, technical, as well as nontechnical, i.e. business applications. Even if this definition might be acceptable for the technical system design, it’s not intuitive and hence is not appropriate for designing interactive business applications. In the latter, the software objects represent physical objects of the application domain (companies, people, etc.), and business processes. Behavior of those kind of objects doesn’t correspond to the one of objects from the object-oriented programming paradigm. The common result of using the above definition to business application design is an employee object that has a method of calculating it’s own wages, which doesn’t make any sense from the application domain point of view.

Objects that represent business processes posses some interesting features that require special consideration in an object-oriented model, e.g.:

• They are time-based. An event can be raised when a certain time condition is fulfilled without any external message being received. Of course, this can be emulated by timer objects sending messages to the business process objects. However, it’ll make the object structure too complicated.
• They are history based. It’s not always possible to calculate the reaction on the event based only on the current state of the object. Evaluation of the past states may be required. Of course, there is a way around the problem, to save all the relevant historic information in the current state. However, this method has two drawbacks. First, it’ll make the object structure difficult to understand. Second, and more important, at the design start, it’s not clear what historic information is important, and what’s not. Besides, any application undergo changes during its lifetime, and having the history saved may allow to change old actions and add new ones without objects restructuring.
• They are human assisted. It’s not always possible for a business object to react on the event without a human being’s help. This adds an additional dimension to the object model. Human resources should be represented in the model in order to deal with the task of human resources assignment, e.g. which person(s) should assist in completing the action for the particular object processing the particular event.
• They are nondeterministic. None of business application systems can reflect the whole complexity of the application domain it works in. There always be some information left outside the system that need to be considered when deciding on and performing actions. Human beings working with the application are the main points of nondeterministic behavior. The human nondeterminism may be of two kinds:

1. Action-based nondeterminism - the results of actions performed with the human assistance are not deterministic.
2. Event-based nondeterminism - a human being may intervene and perform some actions without any visible from inside the system reason.

• Their actions may evolve in time. The actions included in the business object define the way of how the corresponding business process should evolve in time by undergoing transitions from one legitimate state to another. The lifetime of the business object may be very long, and the variety of the ways of its evolution may be difficult to grasp at the design start. Adding the nondeterminism mentioned above, it’s difficult to build a kind of state diagram to list all the possible ways of business object evolution. The more appropriate way of dealing with the diversity of business objects evolution is to allow changes in the actions part of the object during its lifetime. The uniform way of doing this, is by including in the notion of object state not only passive data, but actions as well. This allows to define actions which can change not only passive elements of the object structure, but the actions currently residing in the object. This is particularly useful when completing a human assisted action. The assisting end-user may remove some inappropriate for the given object actions from its state and add some new ones.

The described below OO model was worked out in 1989-90 for the "DealDriver" project the objective of which was to build an application for supporting sales and marketing activities of a trading company. The systems was aimed to help office workers in organizing their everyday (routine) work that consisted of the following operations:

• Execution of routine activities, like writing a letter, taking a sale order, etc.
• Registration of the activities performed.
• Planning of new activities.
• Communication with colleagues concerning the above activities.

To build the application, we needed a model that would allow us to tie together different operations that could be performed by different people who might belong to different departments of the company (organization) they worked for. For this end, we considered the company's activity as a number of processes (such as "processing an order", "closing a deal", etc.) without regard to the way these processes were organized and managed within the particular company.

These business process were represented in our model as objects which we call organizing objects (or orgobjects for short) to stress their importance in organizing all activities of the business process The state of an orgobject reflects the current state of the business process, the difference between this state and the legitimate final one showing what further actions should be undertaken in order to reach the process goal.

In our model, object is a central notion. Not only are business processes represented as objects, but also all other entities of the application domain, such as customers, goods, patients, the company’s personnel, etc. Objects are complex and dynamic. The complex nature of objects is reflected by links that show the inclusion of one object into another. The dynamic properties of objects are represented with the help of:

• History
• Events
• Activities

History is the time-ordered sequence of all the previous states of objects. The history is most important for objects that represent business processes (orgobjects, as we call them) as it shows the evolution of the process in time. The history in some cases is used in addition to the current state of the orgobject to figure out what further steps should be completed to transfer the object to the final state.

Events are a special kind of objects that present additional information about transitions from one state of the object to another, like date and time when the transition had occurred in the real world, date and time when it was registered in the system (may differ from the previous one), the person whose actions caused changes in the object (if applicable), his comments on the event, etc. A new event object is born each time some other object in the system has been change. An event is a system object aimed to tie the transition of the orgobject from one state to another to the point in space and time of the real world, e.g., when, where, who, etc. However, it possesses all the properties of other objects in the model. In fact, it can be changed, for example, in order to add additional comments on the event later. Changing the event object, naturally, will cause the creation of a new event to describe who when and why tried to alter the history (no "1984" is allowed). The sequence of events that concern the particular object represent a written history (interpretation) of this object, as opposed to the real history, i.e. the sequence of the previous states.

Activities represent actions that take place in the world of application domain, like getting a sales order, shipping goods, administering a drug to a patient, performing a software module compilation, etc. In the model, the activity moves an orgobject to the next stipulated state. An activity may be planned first and executed later. This process is realized in our model by a notion of planned activity. A planned activity is an object that contains such information as type of activity (shipping, invoicing, etc.), planned date and time, deadline, reference to the person who is responsible for performing the activity, etc. Planned activities are included in the orgobjects which they will affect when executed. All planned activities included in the given orgobject compose the immediate plan of the process evolution. When executed, a planned activity changes the orgobject to which it belongs. This change may include adding new planned activities and deleting the old ones (for example, the one that is being performed) which will affect the object evolution in the future. When executed the planned activity becomes an event registered in the system.

Planned activities helps to realize the idea of dynamic and distributed planning. Dynamic planning involves planning only the first few activities at the first stage. As soon as one or several of these are completed, new activities are planned with regard to the emerging state of the relevant orgobject. Distributed planning implies that the worker who has completed a planned activity himself plans the subsequent activities, thus there is no central planning. Moreover, he/she can assign these new activities not only to himself, but to other people too.

Naturally, human beings that work with the system are also represented as objects, a kind of resource objects. As we’ve seen above this objects are referenced to at least in two places of our model, i.e., events, and planned activities. This references show two main characteristics of the persons’ works:

• A sequence of registered events that refer to the same person shows this person’s workload in the past.
• A sequence of planned activities that refer to the same person constitute a personal calendar of this person, and shows the workload of this particular human resource in the future that should be taken in consideration when planning new activities.

Note: On the surface, our practical model is very much like a workflow diagrams, however internally it’ s quite different, from both theoretical and practical point of views, e.g.:

• It’s based on the object-oriented approach to process representation.
• It’s aimed to embrace all aspects of managing the routine work, not just work-flow.

During the DealDriver project, we created home-made development tools that included Hi-base - an object-oriented historical database, and Navi - an object oriented user-interface system. Hi-base is able to store all the previous states of the objects and show them on demand. Navi allows the end-user to easily navigate along the links connecting various objects to each-other in presence and past (history). The results of the project are summarized in brochures [1,2]. The model, and tools were later successfully used for building prototypes and working applications in other industries. One of those applications won the "Object Applications of the Year Awards 1997" in the group "Best object-based application developed using nonobject-oriented tools" (Object World Show in London, April 1997).

Actually, the business process model described in section 2 is a specialization of a more abstract model from our previous research work on the CHAOS project (CHAOS stands for Concurrent Human-Assisted Object Systems). The project's objective was to work out a formal model for describing distributed interactive systems. This model is based on the notions of objects and connectors.

Objects are used to represent the elements of the "real world", whereas connectors are the active elements of the system whose task is to make changes in the objects. A connector may be thought of as a little computer connected to one or several objects. As soon as some of these objects change, the connector changes all the other objects to restore the consistency of the system. Thus defined, our model has a purely reactive nature, i.e. changes in objects are made as a reaction to changes in other objects. But objects can be complex, i.e. they themselves can contain connectors, which means that a reaction can result in adjusting the system configuration to changes in the environment.

The specialization of the model for business purposes basically consisted in using another set of terms. Complex objects became orgobjects, connectors became planned activities, and the principle of reactive reconfiguration of the system became dynamic and distributed planning. This specialization gave us the possibility to both communicate with the future users, and built real applications. However, having a more abstract model in mind, gave us an additional level of testing different alternatives when working on the practical model.