ESP is a Prolog language extension (derivation) specifically for modeling software processes. My previous encounter with software process descriptions (beyond the inevitable use of UNIX’s make) has been APPL/A, an Ada extension for the same purpose (referenced in this paper, and used in the US STARS program). I believe Prolog to have some features that make it significantly more suitable than Ada extensions to the task of describing processes (after all, make is also a rule specification language, and it is clearly the grandfather of process enaction mechanisms). ESP extends a specialized form of Prolog with the ability to have multiple execution threads that coordinate by passing tuples (vaguely like collections of old Prolog assertions) and tuple spaces (assertion sets) between producing and consuming threads (called agents).
It is not clear to me that ESP is strictly a modeling language, though that is how it is introduced; it seems that the models can also be enaction mechanisms with additional mechanisms (and in fact they seem in the text to be used as enaction mechanisms, much like a make replacement).
The paper introduces a process modeling language based on rules, which is different from the other process modeling language, APPL/A, based on Ada, and certainly different from approaches using directed graphs. The paper fulfills its purpose, though I would like to see more. I would like to hear about the implementation of a language processor for ESP (if one exists), efforts to actually use ESP process descriptions, and more of what comes next, given the existence of this language (for example, users’ experiences with it).
The length is about right. The paper would become too long if it covered all the facets of ESP use that I would have liked to see covered. The paper raises awareness of process modeling languages and the use of Prolog derivatives for rule-based instead of procedural techniques.
Process models should be able to express policy involving both humans and machines. They resemble a make script that includes human decision processes, reviewer interactions, management decisions, peer advice steps, and the like. This paper’s examples concentrate exclusively on the machine part (automating the edit-compile-if_test_okay-checkin process), but not the policy, advice, human interaction, and group coordination. I believe the technology presented is capable of expressing both parts, and I encourage the authors or future users to consider the advice, guidance, policy, and direction elements of a process that are performed by humans as well as machine scripts.
Process modeling languages, if they are also used to enact processes (and I believe ESP is headed in that direction), need to be integrated with other tools. Graphical modeling notations (in the author’s list of future activities), the addition of persistence (such as by the use of PCTE or a similar public tool repository), the addition of object modeling integration (such as by CORBA and OMG OMA feature integration, or Microsoft OLE 2), and even the use of simple intertool notification schemes (CASE Communiqué and X3H6) would be worth discussing.
Process modeling has become a somewhat specialized field. Technical conferences have developed around this topic, tools have come on the market (including the EAST environment, Synervision, and Process Weaver), and a minimal background is assumed. I am not aware of a way to jump into this field other than by diving in. My greatest concern is that some readers may slog through the entire paper and feel they recognize commonplace English words, and not recognize the existence of a separate software engineering process community.
I like the rule-based, Prolog-based approach for process and policy modeling, compared to other descriptions of the use of procedural languages. An equal number of people will prefer procedural instead of rule-based descriptions, however.
The paper includes a good list of technical references. I would like to see product references added.
