OPM: An Object Process Modeling Environment

Abstract

This document as an attempt to give an overview of OPM, a process modeling environment . By an environment we mean a user interface through which process model templates are designed, instantiated, and tracked as they execute. The two novel features of OPM that we want to stress here are: (i) the way OPM uses conventional CASE tool graphical notations for describing process templates, and (ii) the way OPM supports model instantiation, resource management, and cooperative work among a team of developers.We begin with some basic definitions. A process is a collection of activities that will be carried out over time. An activity is a basic unit of work and it minimally contains a name, and some attributes such as a duration or some resources. Often the activities are ordered in some way, but not necessarily. If an ordering is available, then we can talk about an activity's predecessors and successors. When a process is being carried out (instantiated), typically more than one activity is going on at the same time. The result of an activity may be a product or simply a confirmation that it has concluded. An activity can invoke other processes. In fact, there is no logical reason to distinguish between an activity and a process, so in the future we will use these terms interchangeably.There are several basic features of processes that we assume. In particular: there are several ways a process may be started, e.g. by human intervention, by the arrival of a message, or by the completion of some product;an action by a computer may end a process and start a new one;a process may require access to resources before it can begin;sometimes the time for a process can be reliably estimated and sometimes it cannot;processes must have the ability to look at (access) directories, files, test file attributes, express conditions, and invoke programs.Figure 1 contains a description of how debugging takes place within some hypothetical organization. A database of bug reports is collected and there is an available pool of programmers to work on them. Each instantiation of debugging process will assign a bug report to a programmer for fixing. When the programmer is done, he submits his fix to the QA (quality assurance) group who confirm that his fix is correct. If not, it is returned for further work. If so, then a report is written and submitted to the manager.From this example we can draw conclusions that extend our earlier notions about processes and their descriptions. The use of dataflow diagram notation is suitable for describing this process. Rectangles are used to represent resources and ovals are used to represent processes. Arrows indicate process flow and they may carry data. Other examples we have done indicate that a wide variety of processes can be adequately described by this natural notation. To refine further the debugging example, we assume that when the programmer submits the corrected code to the quality assurance group, a new process is started. That process is shown in Figure 2. From this elaboration we conclude that processes may have lower levels which contain process descriptions. Therefore we see that a process description should be thought of as a hierarchical object.Another observation from this example is that there may be several people all following this process description at the same time. Therefore we see the need to view the process description as a template and talk about its instantiations. When the template of Figure 1 is instantiated we interpret this to mean that a new bug has been assigned to a programmer for repair. Observe that when a single programmer is selected to fix a single bug, that instantiation of the debugging process may give rise to multiple instantiations of the working on bug subprocess. Therefore we see that when a process is executing, subprocess templates may be instantiated multiple times.