Advances in Petri nets 1986, part I on Petri nets: central models and their properties
Language constructs for managing change in process-centered environments
SDE 4 Proceedings of the fourth ACM SIGSOFT symposium on Software development environments
| Hi-index | 0.00 |
At the Fourth Software Process Workshop the final session was devoted to identifying “emerging issues”. The issues that were identified fell into two categories. One had to do with language issues — how to provide the facilities that support the writing of the process programs that implement process models. The other had to do with reporting on experience with writing, evaluating, and sharing process models.Since the last workshop we have made significant progress on several of the issues concerned with specifying and implementing process programs. In the paragraphs below we will comment briefly on these.The context in which we have explored these issues is the E-L System, a new programming language and supporting environment that became operational in prototype form in the Summer of 1989. While we cannot provide much detail about E-L here, we believe that it provides many of the facilities — including both language and system facilities — required to support process modeling and programming.A central concern of E-L is extensibility, both in the language as well as the environment. The environment has a shared software development database, accommodates multiple simultaneous users, and facilitates communication and cooperation among a variety of users.From the user's point of view, the material that would constitute a “program” or “module” in a conventional environment is, in E-L, organized into documents. A document has parts, recursively, and, ultimately, is composed of various objects like program fragments, text, and pictures.We call document as well as their constituents artifacts. An artifact is typed — examples being documents, text in LATEX format, pictures in postscript, and E-L program fragments in the surface syntax or some extension of it.1 In general, an artifact includes other artifacts and has a predecessor2. Once an artifact has been created (and committed) it is not subject to change, although an edit that starts with a copy of it may be the basis for developing its successor. A given artifact is, typically, shared in the sense of being included in several different documents. Examples of sharing include references to library entities, a reference to some artifact in the “current” version of some document as well as references to that same artifact in “previous” versions, and a reference to an artifact in the “current release” of a product as well as in one or more “current developments” of that product.There are three major reasons for using documents and artifacts in the organizing framework for E-L. The first is to provide for literate programming in the sense articulated by Knuth. That is, program constructs like functions and types are presented in the context of a document3 that motivates, explains, and defends the design decisions that underlie these constructs. An “implementation module” is simply the collection of leaves of some document that are program entities. The second reason is to provide for sharing of artifacts so that, given two versions of some document, we can identify what is common and what is different about them. The third reason is that the structure provided facilitates the addition of new types of artifacts.The user interface to E-L provides each user with a “window” into the collection of artifacts that are of interest to that user and supports three main activities. The first is browsing — following various “links” to inspect some collection of artifacts and attributes. In addition to the includes and included-by links that provide a natural way to navigate within a document, there are other links that may be followed like calls, called-by, and recently-modified. The second activity that is supported is editing — evolving some document or set of documents. The editor insures that the integrity of artifacts is maintained.4The third activity is program execution, usually aided by a collection of sophisticated debugging tools.The user is not concerned with conventional tool invocation — calling compilers, analyzers, text processing tools, and the like. In general, such tools, whose purpose is to derive new artifacts or attributes, are scheduled automatically and run opportunistically.A number of the programming language and environment issues that were identified at the last workshop are dealt with directly by E-L, including:The basic system provides facilities for dealing with concurrency and communication, including mechanisms that provide “notification” to interested users upon the occurrence of certain events.The artifact machinery provides the basis for sharing and containment as well as for hierarchies and decomposition.The type system of the E-L language is quite rich and permits user-defined type constructors, expandable unions, and type templates — “types”, useable in function headers, that contain parameters that are bound for use in function bodies.Several other issues are being investigated:Long Term Execution A model for writing programs that execute indefinitely has been developed, a mechanism that transforms such models into program fragments that contain the necessary constructs to insure the persistence of such programs between “active” periods has been designed, and a prototype implementation of the facility is scheduled to be operational in the Fall of 1989.Rules An extension to E-L that provides for rules that react to changes in the database and permit arbitrary programmed responses to such changes has been designed. A preliminary overview of this extension is provided in [Che89].Sketches A “sketch” is a representation of a process program that depicts the process as a state transition diagram. We are currently designing a sketch facility for which we expect to have an operational prototype early in 1990.Specific Process Models We are currently developing specifications for several process models, probably including models for handling software trouble reports, cooperative program development and modification, and developing and maintaining families of programs targeted for a variety of parallel architectures. We are also investigating a process model that has nothing to do with the software process but is concerned with the USAF process for issuing RFPs.Support for Process Modeling and Analysis We are presently investigating the use of Colored Hierarchical Petri Nets (see [Jen86]) for high level specification of process models as well as the use of the Design/CPM tool5 construct graphical representations of these models. Our experience to this point is very positive.