Marvel extended concepts founded in the consistency and automation rules of ISI’s CommonLisp Framework to more general software processes for mainstream programming languages and environments. In particular, each software development task or subtask was defined by a parameterized rule with preconditions, activity, and effects. The preconditions were required to be satisfied prior to performing the activity, and one of the mutually exclusive effects was asserted on completion of the activity. Opportunistic forward and backward chaining among these rules, to fulfill the preconditions and carry out the implications of the effects, automated some of the more menial segments of processes as well as guiding users through the human-oriented creative steps. Marvel’s client/server architecture, with a shared objectbase and process engine governed by a cooperative transaction manager, supported multi-participant processes. External tools and human activities were integrated into the process through scripted envelopes.
Marvel is a process-centered environment that supports teams of users working on medium to large scale projects (e.g., Marvel has been used to support development and maintenance of a software system with over a quarter million lines of code and ten developers). Marvel is completely generic, and can be used for a variety of applications besides software engineering, ranging from document processing, civil and mechanical engineering to network management, managed healthcare and education. An instantiated environment is created by an administrator who provides the data schema, process model, tool envelopes, and coordination model for a specific application; the typical user of the environment need not be concerned with these details. The schema classes define the structure of a coarse-grained object-oriented database to contain the relevant artifacts (legacy systems can be immigrated into a Marvel objectbase using the Marvelizer utility). The XView user interface supports graphical browsing and ad hoc queries; there is also a command line interface for dumb terminals and batch scripts.
The process (or workflow) is described in a process modeling language. Each process step is encapsulated in a rule that can be invoked from the user’s menu and provided with parameters by clicking on a graphical representation of the objectbase. The body of a rule consists of a query to bind local variables; a logical condition that is evaluated prior to initiating the activity; an optional activity in which an arbitrary external tool or application program may be invoked through an envelope; and a set of effects that each assert one of the activity’s alternative results. Marvel enforces the process, in the sense that the condition must be satisfied in order to execute the activity and effect; forward and backward chaining over the rule base automate tool invocations.
A user decides when to request a particular process step, and then Marvel enacts the process by selecting the rule(s) with matching name and signature, evaluating each of these rules until it finds one whose condition is already satisfied, or is satisfied by backward chaining. This rule’s activity, if any, is then executed. One of the effects is then selected, according to the result of the activity, and Marvel forward chains to all rules whose conditions become satisfied by this effect. However, if none of the conditions of the rule(s) matching the user command can be satisfied, then the user is informed that it is not possible to undertake that process step (at this time). Predicates in the condition and assertions in the effects may be annotated as atomicity vs. automation. By definition, all forward chaining through atomicity assertions to rules with satisfied conditions is mandatory. In contrast, chaining solely for automation purposes is optional. Possible chains are compiled into an efficient internal representation when the environment is instantiated.
Conventional file-oriented tools and application programs are integrated into a Marvel process without source modifications, recompilation or relinking through an enveloping language. The rule activity indicates the envelope name, input and output literals, and file attributes; the envelope’s implicit return code selects the actual effect from among those given. The body of an envelope is a conventional UNIX shell script.
A client/server architecture supports multiple participants in the same process. Each client provides the user interface, checks the arguments of commands, and invokes the appropriate envelope when an activity is executed, whereas the process engine, synchronization management and object management reside in the central Marvel server. Scheduling of client requests by the server is first-come-first-serve, with rule chains interleaved at the natural breaks when clients execute activities. Clients may run on different hosts from the server on the same LAN.
The coordination model includes a lock compatibility matrix and an ancestor lock table for composite objects. The default concurrency control policy distinguishes between chaining for atomicity vs. automation purposes. Chaining via atomicity assertions/predicates is treated as a conventional database transaction: if an atomicity chain incurs a lock conflict, the entire chain should be aborted (rolled back). In contrast, automation annotations define each rule as an independent transaction – and thus automation can be terminated (and not rolled back) at process step boundaries without completing the entire chain. A preliminary coordination modeling language specifies scenarios where this default policy can be relaxed, to increase concurrency and enhance collaboration. The administrator specifies concurrency control policies in terms of primitives to notify a user, abort a rule chain, suspend a rule chain until another has completed, or ignore the conflict.