Abstract. In this paper, we make a proposal of extensions to object-oriented notions in order to represent business processes. The idea consists in avoiding to consider object types independently, but taking into account their collaboration based on the context emerging from a goal requirement as business processes and their steps (activities) are constituted on a goal basis. In this way, we introduce ‘Contextual Objects’ as based on a context that does incite objects to collaborate in order to realize a goal (a business goal).

 Keywords : Work Unit, Aggregation, Dominant Entity (Driver) Object, Objects Behavioral States, Object Responsibilities, Contextual Objects, Behabioral State Transition Diagram, Activity Diagram

 1. Introduction

Traditional Object Orientation doesn’t meet the Business Process Modeling requirements since objects do not incorporate the goals for which they collaborate. Indeed, business processes like Order Management, Sales, etc..and their steps (activities) require to be driven by a goal as a business process may be assumed as a goal-oriented graph (purpose of the business process) inside of which each step represents a goal-oriented node (purpose of the business process step).

 Listing in bulk attributes and operations within classes does not help to model business process steps since the goal and the emerging context ( to ensure the goals ) of objects are not expressed in today’s object-oriented models.

Indeed, in the object orientation activities are implicitly executed by objects that collaborate to realize a goal. But as the goal is not explicitly expressed, the behavior of the group of objects is not modeled.

 Goals and contexts may be symbolized by objects contextual behavior that may be expressed using activable attributes, relationships and methods of objects depending on a context.

Modeling the goal requires that each activity inside a process step is considered as conducted by a driver object carrying out the goal. Contextual objects collaborate to realize the goal according to the context emerging whenever a driver object enters into one of its life cycle stages.

Indeed, the entrance of a driver object such an ‘order’ into one of its different stages (entry, evaluation, delivery, billing,..) of its life cycle incites other participating (contextual) objects to react depending on the context. Reactions of different contextual objects like product, customer, delivery, invoice, etc..appearing inside the stages of a driver object’s life cycle are driven by this context. We named the interaction area constituted by a driver object and its contextual objects as the contextual environment of the driver object [Berkem - Modèle des Objets Contextuels / 1995].

Similarly, in UML 1.1., the concept of work unit  is finally defined as a task-oriented set of objects that form a recognizable whole to the end user [UML 1.1- Business Modeling Extensions].

 In the Business Modeling Stereotypes [UML 1.0], the notion of work unit was defined as ‘a shared aggregate with a dominant entity object (marked ‘dominant’) together with the other objects with which it interacts closely’. The state of the work unit is reflected by the state of its dominant entity which goes through state changes as its work unit is manipulated by handler (~actor) operations.

 But nothing is said about the internal dynamics of a work unit whose description becomes necessary to define the responsibilities of its participating objects. In such a way, contextual objects marked by these responsibilities should contribute to model activities inside business processes.

 On the other hand, activity diagrams in UML[1.0] and UML[1.1] try also to model business processes via the notions of action states (activities), and transitions or objects flows between them. Some remarks are proposed here about relevant issues in their adaptability to the business process modeling :

• The internal representation of an activity (action state) is not provided to respond to ‘why and how the action is performed’ in order to model the goal and the emerging context ( i.e., what is the behavioral change that happens in the owning object of an action state to perform the action and what are the responsibilities requested from other objects participating in the action ) !
• There is no information about the destination of the outputs produced by an activity inside its corresponding action state. Indeed, any organizational unit that executes a process step should have the knowledge on the destination of its outputs depending on the status of completion of its activities. This requires the definition of relevant output objects inside each activity, each one carrying out via its links all the necessary information to its target process step. This should considerably reduce the information fetch time of the organization units.

 In order to formalize these in detail, we propose to focus on some characteristics of each work unit, that concern :

• the goal of the work unit and the execution of its activity (the_why and the_how),
• the emerging context (responsibilities required by the objects that collaborate for an activity)

  2.1.a. The goal of a work unit and its execution 

 An activity inside a ‘work unit’ is started whenever its dominant (driver) object has a particular value indicating that the activity is ‘executing’. This value is expressed by the ‘behavioral state’ of the dominant object.

The behavioral state of an object is a state with an internal action, but it also includes the responsibility required from the object in the work unit. The behavioral state of an object is expressed as a chronological form and may have either one of the following three values, among ‘to be executed’, ‘executing’, or ‘executed’.

 The chronological form serves to enhance the meaning expressed by an object behavior and is still very useful to fix out the responsibility of any object at any time.

 A behavioral state may be attached to each state of an object’s life cycle and has only one outgoing transition (except the last) whose target is the next chronologically ordered behavioral state. The list ‘to be executed, executing, executed’ presents a chronologically ordered list of forms or a chronologically oriented graph as shown in figure 2.

During the activity, the dominant object sends messages to other objects that participate in the activity in order to activate their responsibilities and keeps its behavioral state as long as the action continues..

At the completion of the activity, the behavioral state of a dominant object takes the implicit ‘executed’ form.

 2.1.b. The Emerging Context (Responsibilities required from objects that collaborate for an activity):

 The dominant object of a work unit acts as an input interface (hides the complexity of its work unit). It sends messages to objects participating to the common work unit in order to activate them to realize the task assigned to the work unit. We named them as ‘contextual objects’ [Berkem- 95 / 96] , [Picavet,Berkem -97] as their behavioral states depend on the context created by their dominant object’s behavioral state. For this purpose, contextual objects of a work unit have their behavioral states marked by the ‘to be executed’ (requested) form that expresses the required responsibility.

 Communication inside and between process steps

 In the figure 3, the communication inside each business process step is modeled using these concepts. The communication between process steps is managed using an output object of the current process step and the input object (dominant object) of the target process step.

Notice that an object appearing as ‘output’ in a work unit should become a dominant object in its target work unit in order to drive its affected responsibility. This means whenever output objects are called to execute their requested responsibility, their behavioral states take the ‘executing’ form. This may be realized by applying a similar principle to the transmutation [Castellani- MCO 93] principle. We name this kind of transmutation as a behavioral transmutation as objects change their behavioral classes. Indeed, objects called to leave their source classes (output classes) affected by a ‘to be executed’ behavioral form go to be placed into the calling target classes (input classes) with an ‘executing’ behavioral form.

Responsibilities asked from contextual objects generally require other object collaborations for their realization. This means that behavioral states of contextual objects might be expanded or refined sufficiently to realize the required responsibility. This expansion may be modeled by nested work unit(s) and should be repeated as long as contextual object’s behavioral states require a refinement in order to realize the needs of the business abstraction level.. More formally nested activities (action states) may be represented in the Behavioral State Transition Diagram that we introduce as an extension to the State Transition Diagram.

The approach by the contextual objects proposes some extensions to the classical object orientation for the business process modeling. Indeed, in the traditional object orientation, the mechanism of object abstraction inside classes doesn’t consider the goal of these objects : instances in any state may form a class and the whole operations may be potentially applied on every object of the class, whatever their states and their goals ! Business Processes require a goal oriented abstraction as they are driven by goals aligned on the company missions, vocations and values. Goals and contexts may be expressed using activable attributes, relationships and methods of objects depending on a context.

This kind of modeling also allows :

• a formal way to find out process-oriented ‘use cases’ [Berkem-98b] from work units of a process step and improves their acceptance tests
• an executability of the process steps using the behavioral states of the participating objects
• a reduced semantic gap during the transformation of business process specifications into robust analysis and design artifacts (business process components transformed in business objects components that can be implemented using a middle-tier within a distributed architecture )
• ...

In the organization domain, ‘contextual objects’ proposes an organizational design by objects ready to understand the business environment dynamics via the stages of strategic business objects.

In such a design, objects allow users to react to the changes and assist them in the propagation of their reaction to the other cells of the enterprise [Berkem-96 b] and thus triggering their reaction coherently according to the company objectives with their values, vocation and finality as these should be stored in the genetical patrimony of the enterprises [Berkem- 98c].