Download Implementing Activity Structures Process Modeling On Top Of The

5
executing on the same object O would be automatically serialized by the MARVEL kernel, because its
concurrency control protocol implicitly places write locks on all object arguments of activities after
evaluating the read-only conditions but prior to initiating the actual activities. Read locks are obtained
during the evaluation of the condition, as needed. (This behavior may in MARVEL version 3.1, which is
planned to incorporate many of Naser Barghouti’s thesis results [Barghouti 90, Barghouti 9x].)
In contrast, MARVEL permits any concurrency relationship among edit(X) and proof(Y), assuming there is
no containment relation between X and Y (MARVEL automatically places intention locks on enclosing
objects), so that they could in fact overlap in time and are thus non-atomic. Synchronization among
shuffled activities is supported by the send/receive synchronization primitives. However, if actually
atomic activities are desired, this is supported by an atomic directive (non-atomic is the default); this
approach is a preferred alternative to introducing begin-edit, end-edit, etc. Any activity structures where
such explicit synchronization is missing represents a ‘‘don’t care’’ scenario where true parallelism should
not be precluded.
A final execution issue involves the presentation view: How are in-progress activity structures
represented to the user? The alternatives seem to be:
• No user-visible presentation at all of activity structures.
• Textual presentation in some form, for example, by printing out a summary in MARVEL’s
Text window. This could be done with or without describing the actual data on which the
activities execute, and could support multiple modes, including a blow by blow listing of
activities as they happen, a history of past activities, and a model of possible near and far
future activities.
• Graphical presentation in the style of Steve Gaede’s environment [Gaede 91], presenting
activity structures only, with no conceptual or visible links to data.
• Graphical presentation of instantiated activity structures, including user-visible links to actual
data instances employed in activities.
The fourth option was followed, as the most user friendly, and also because it turned out to be necessary
for certain user interactions with the objects representing the activity structure instances. However, there
is no cursor indicating the current position(s) in the activity structure definition, and the user interface
leaves much to be desired.
1.5. Design and Implementation
The enaction requires some run-time representation of the activity structures, independent of visibility to
the end-user. An activity is of course always reflected by the envelope that actually implements that
activity, but additional information must be available during execution, such as the control state
indicating position in the currently instantiated activity structure.
• One possibility would be to make control entirely implicit in the rules, those generated to
encapsulate the activities and perform the control specified by the structure primitives, with
all state somehow reflected in attributes of the underlying data. We already have facilities in
MARVEL to instantiate multiple instances of the same rule with different data for the same or
different clients, i.e., rules are re-entrant.
• Another approach would involve explicit representation of activities and/or structures as
objects. These objects need not be visible to end-users, but they could maintain state. For
example, an activity object might include links to the actual data used in that particular