Browse Prior Art Database

Deriving Process Models from Method Traces

IP.com Disclosure Number: IPCOM000014597D
Original Publication Date: 1999-Dec-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 34K

Publishing Venue

IBM

Related People

Frank Leymann: AUTHOR [+2]

Abstract

1 Introduction

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Deriving Process Models from Method Traces

1 Introduction

Applications written to the object oriented paradigm are made up of
individual objects that interact with each other by invoking methods on each
other.

     Applications written to the workflow paradigm are made up of a process
model and a set of activities. Each of these activities has associated with
it an implementation that performs the actual work. As pointed out in (1), an
activity implementation can be the invocation of a method on a business
object.

     When workflow technology is introduced into companies, it could be
desirable to exploit workflow technology for applications that have been
written using object technology, using for example object servers.

     This proposal shows how method traces written either by the individual
objects or by the supporting environment can be used to create process models
which reflect the control and data flow within the application. These process
models together with the called objects represent the application
functionality as a workflow-based application.

2 State of the Art

Object-oriented programming differentiates objects based on their purpose
within applications. Data objects encapsulate the access the data stores that
contain the data of interest. Control objects encapsulate the control flow
and data flow logic of the application. As such, they orchestrate the
invocation of the different methods of the involved objects. In fact, they
implement the underlying business process, that means they contain the
control and data flow of the application. Further information can be
found in chapter 6 of (1).

     Object servers, as defined for example by the OMG in the form of ORBs
and implemented for example in the form of IBM's WebSphere, provide an build
and runtime environment for objects. The buildtime allows the definition of
the object structures, such as the methods that the object implements. The
runtime provides functions to manage objects, such as creating objects,
passing method requests to objects, and deleting objects when they are no
longer needed.

     Making changes to the underlying business process, that means changes
to the sequence in which the different methods are invoked as well as the
addition or removal of methods requires the change of the appropriate code in
the control object. This requires knowledge of the programming language in
which the control object is implemented as well as the internal structure of
the control object. Thus changin...