Data (session summary)

Abstract

This session addressed the object base and typing issues needed in support of the modeling and implementation of the life-cycle process. In this summary the terms process and life-cycle process are used interchangeably. However, I do not believe that was the case during the workshop; sometimes it seemed that the term process was used in an abstract way1, which led, at times, to some conceptual misunderstandings. Jack Wileden was the keynote speaker for the session. He started by trying to differentiate between two (2) roles in process modeling:The actual modeling of the process, i.e., how do we describe the process independent of its implementation. Process enaction and the environment needs in support of the process model descriptions. He felt most position papers dealt with the second role, even though a few talked about the first. There was not too much discussion with respect to the differences of those roles but performance was mentioned as a key issue for the second role. Wileden proceeded to distinguish an overall “world view” on data issues from specific dimensions of the data support problem (see section 2 for his list of specific dimensions). He listed several possible world views with respect to data in support of life-cycle processes, including: i) typed objects as in programming languages, ii) files (e.g., documents, code, etc), iii) traditional database view. He described his own view as based on the notion of an “object space” (i.e., collections of objects). This more modern view appears to be shared by many of the workshop participants, as reflected in many of the position papers. The group decided not to debate on the definition of the word object, but to consider it related to the concept of abstract data types. (Note: I like to think of objects as the units of data which are identifiable and accessible within a Software Engineering Environment (SEE) and of an Object Management System (OMS) as the SEE component whose objective is to manage those objects; a precise definition of an object is largely dependent on the type model provided by an OMS.) This session did not try to generate lists of issues or requirements. The objective seemed to be to discuss items which were felt important by the group. There were few agreements. Nonetheless, an emerging consensus seemed to be that the current state of the art and state of the practice in database management systems (or object management systems) do not support all the needs of process programming. This summary will concentrate on some of the key items and/or issues discussed, followed by some observations made during the session.