MARVEL is a kernel for software development environments that enacts a processing modeling notation, called the MARVEL Strategy Language (MSL). The software process is defined in MSL as a collection of modular
Each software development activity is described in MSL by a rule specifying the precondition and multiple postconditions of the activity. Both preconditions and postconditions are written in a subset of the first order predicate logic, stylized to incorporate directives for efficient queries and updates. A precondition is a logical statement that must be true before the activity is initiated; a postcondition is a logical statement asserted to be true when the activity completes. Multiple mutually exclusive postconditions reflect the multiple possible results of many activities. An activity is typically a particular combination of software development tool, options specific to that tool, and typed arguments. The notion of activity could be extended to include loading a new set of strategies to take over at this point in the process, to support both nesting of hierarchical activities and successive activity phases.rn
Enaction of an MSL process model is implemented by what we call
We have designed two facilities for controlling this processing, to prevent runaway automation.
MARVEL version 2.10 was recently completed, an upgrade over the version 2.01 that was demonstrated at the 3rd PSDE conference in November 1988. This latest version of MARVEL adds an X11 windows graphical user interface and new subsystems called Marvelizer and Organ. Marvelizer is a tool for
We have discovered several difficulties with the MARVEL paradigm that seem likely to apply at least partially to enaction of other notations for software process modeling. First, constructing and debugging a process model is hard. We have run into many unanticipated interactions among rules, particularly among those defined in different strategies that happen to be loaded into the MARVEL kernel at the same time. We are working on debugging facilities that will uncover all direct and transitive dependencies by constructing a graphical dataflow graph of the currently loaded rules. It is feasible for a user to enable and disable individual rules, both during debugging to see how that affects the dataflow among rules and also during operation because certain behavior is not currently desired. This would be dangerous, however, if done by a naive user: if rules were turned off and on at arbitrary points, it would be possible for MARVEL to get into what is an inconsistent state with respect to the full set of rules in such a way that automatic recovery is impossible.rn
Similar difficulties seem likely to arise for any enactable process modeling paradigm. The following questions need to be answered: How does an implementor go about writing, testing and debugging a process model? For non-trivial processes, the model is likely to be very large and hence should be modularized. What is the appropriate style of interface among process model modules and how is it enforced? Is the process model visible to the users and, if so, how is it presented? If the users can modify the process model during enaction, how does this affect continuing the process? Should (can) consistency be enforced or should (can) inconsistencies be detected and repaired?rn
Second, constructing envelopes is even harder. We currently use the Shell languages (e.g., CShell) as notations for defining envelopes. Writing the Shell scripts requires an intimate knowledge of both the tool and the mapping of the MARVEL objectbase onto the file system. Although there is no way to avoid the former, we hope to minimizethe latter by developing a higher level envelope language that understands the MARVEL objectbase implementation so the envelope writer doesn't have to. However, this is currently a relatively low priority due to lack of manpower.rn
Again, similar difficulties seem inevitable for other enaction mechanisms intended to work with external tools. The questions: Is it possible (or desirable) to support existing tools, particularly tools where retrofitting is impractical? If only new tools are supported, can a relatively simple standard interface be developed and published so these tools can be developed separately by vendors? Would such an interface pre-empt too many design decisions, or would it be feasible for vendors to upgrade their current products?rn
Third, supporting multiple users is hardest of all. The current MARVEL kernel does not provide any facilities for concurrency control. It would be easy to add locking of the entire objectbase, but a more flexible transaction model is needed. We are working on a number of alternative models that we think are promising for incorporation into the MARVEL kernel.
It is essential for enactable process models to support coordination and cooperation among the members of software development teams. There are two sets of questions: First, what are appropriate processes for programming-in-the-many? This is itself an active area of research, and there is certainly no consensus. One opinion, voiced at the previous workshop, is that the community should not be enacting process models until we understand the processes weare modeling. An opposing opinion is that enaction gives the community the capability to experiment with different processes without prematurely making a full scale commitment to a particular process. Assuming agreement with the second view, what process modeling notations and enaction mechanisms can support a reasonable range of cooperative work facilities?rn
The database and operating system communities have agreed on atomic and serializable transactions, which can be implemented using a wide variety of technologies, as the basis for data consistency, failure recovery and concurrency control across their traditional application areas. Can the software engineering community develop an equally all-encompassing 'transaction' model? Or is there some characteristic of the software development process such that coordination and cooperation policies will always require special support on a case-by-case basis? If so, what does this say about enaction of process models in general?rn
In summary, MARVEL is implemented and in limited use, it works in some cases, it doesn't work in others, it raises a lot of questions, and both we the MARVEL group and we the software engineering community have a lot more work to do.......