A Linguistic Study of Process Modeling Languages Tao Xie
[email protected] CSE 505 Concepts of PL Course Project Paper 2001 Autumn
ABSTRACT Process model or definition is used to describe the process, either software process or business process, by means of a suitable process modeling language. Choosing one or more linguistic paradigms for a process modeling language is an important design decision during process modeling language design. This paper focuses on the study of process modeling languages from linguistic perspective. To understand what key information in process domain needs to be expressed, we propose a process conceptual framework. Existing process modeling languages can be categorized to one or more of the rule-based, state-based, functional, procedural, or object-oriented paradigm based on their linguistic features. Each paradigm has its drawbacks or benefits in describing different aspects of the process. In order to better support process evolution, several linguistic requirements, including generic, reflective, exception handling, and deviation/inconsistency support, are discussed. Especially there is no effective linguistic support for process genericity, we propose a open research question of whether higher-order function genericity could be an effective solution for process genericity. VoiceXML, the Voice Extensible Markup Language, is a language for describing call flows for Interactive Voice Response applications. PASTA, Process and Artifact State Transition Abstraction, is a process modeling language to model complex processes in a graphical, systematic, precise, and structured way. We perform a linguistic analysis on them and propose some potential extensions for them.
1. INTRODUCTION Process is a logical ordering of people, procedures and technology into work activities designed to transform information, materials and energy into a specified result [Pall 87]. Process model or definition is used to describe the process by means of a suitable process modeling language [Finkelstein 94]. Process automation is composed of process modeling and enactment phases. Process Automation provides computer-based real-time support and guidance for the enactment of processes. Process automation is implemented through a process-centered environment (PCE) that comprises mechanisms for process definition and enactment [SEI]. The process automation and process-centered environment are showed in Figure 1. A PCE may include:
Process Automation Phases
Process Modeling
Model
Process Enactment
Model
Process Flow Engine
Process-Centered Environment
Process Modeling Tools Build time
Runtime
Figure 1. Process Automation and Process-Centered Environment So far process automation has been applied successfully in business domain. Workflow, the automation of business process, gained widespread use in business domain, However, software process automation techniques made progress slowly and did not receive general acceptance in practice partly due to the characteristics of software. The process modeling language research in software process domain is far more active than the one in business process domain. Process model plays a key role in process research work whether the process is enacted with PCE or not. Process modeling languages has been one of the most important topics focused by process researchers. Although there are many process modeling languages proposed, no single one became dominant in practice. Generally most of those process modeling languages are based on one or more linguistic paradigms and extend them to provide enough expressiveness to describe process. In this paper, we investigate the linguistic paradigms of existing process modeling languages to see what benefits and drawbacks of different linguistic paradigms in helping process modeling. In addition, we discussed four different linguistic techniques to support process evolution: generic, reflective, exception handling, and deviation/inconsistency support. An open research question of whether higher-order function genericity could be an effective solution for process genericity is proposed. Based on these observations, we perform a linguistic study on two process modeling languages: VoiceXML, a typical one in relatively simple process domain, PASTA, a typical one in relatively complex process domain. Finally we propose the potential extensions for these two process modeling languages.
•
A process definition/enactment language,
•
Mechanisms for process enactment,
•
Tool invocation mechanisms,
2. PROCESS CONCEPTUAL FRAMWORK
•
Support for communications (tools and people),
•
Debugging capabilities,
•
Applications tools (metrics project management etc.).
A process contains several key elements as showed in the process conceptual framework in Figure 2. Activity is a description of work that forms one logical step within a process. The sequence order constraints imposed on these activities form the control
flow within the process. Artifacts represent final or intermediate work products or the information needed to produce during the process. The associations of artifacts with certain activity form data flow within the process. Certain type of activity can be totally automated without the human intervene as an automated activity. But the other type needs the human involvement as a manual activity. Roles indicate who can perform certain manual activity. There can be different abstraction levels for activities. For example, one big activity can be decomposed to several smaller activities. Those activities that can be directly performed without being decomposed are atom activities. The control flow and data flow among non-atom activities can be refined to the control flow and data flow among atom activities. The process modeling language should express above key elements in the process in addition to some of other complementary information like resource, analysis, monitoring, measurement, etc.
Role
Work On (Manual) Activity
Control flow
Data flow
(Automated) Activity
Data flow Artifact
Figure 2. Process Conceptual Framework
3. LINGUISTIC PARADIGMS Several linguistic paradigms for process modeling languages have been proposed by researchers and practitioners. Rule-based paradigms emphasize constraints on process execution. Statebased paradigms model the structure of roles or artifacts and their interactions. Functional paradigms define a process as a hierarchy of mathematical functions depicting relationships among inputs and outputs. Procedural paradigms model the control flow among the activities explicitly as “transit to” relation. Object-oriented paradigms capture the entities in process as object and express the relationship among objects.
3.1 Rule-Based Paradigm Some process modeling languages use a set of production rules to describe some information in the process. The content of certain activity is described by an action description. The constraints among activities are described by a precondition and a post condition for each activity. An action, a precondition and a post condition form a rule. Certain roles or required resources can be associated with a rule. Since process execution in the real world involves considering various contingencies, the rule-based paradigm is preferred to handle such contingency problems by planning. This paradigm provides mechanisms whereby operators representing possible
actions are selected based on the satisfaction of their preconditions. These operators are applied to the current state of the domain in which the process operates, in order to move that state closer to the desired goal. However, since the rule space in rule-based paradigm is usually flat, it is not good at expressing the process topology or controlling the complexity. LATIN (Language to Tolerate Inconsistencies) [Cugola 95] is a process modeling language for SENTINEL (Software-engineering Environment to Tolerate Inconsistencies Employing Logic project). Processes are modeled in LATIN as collections of task types. A process activity is described by a task type as a state machine. State transitions are described by a precondition (ENTRY) and a body, which contains actions to produce results in system and value assignments (EXIT clause) to modify the values of the task state variable. Global or local invariants are defined as the logical propositions that have to be true in any state of the system. SPELL [Jaccheri 92] is the process modeling language for EPOS. It is based on Prolog language extended with object orientation (types) and reflection (meta-types), and concurrent tasking. The goal-oriented process model can be expressed by using static rules and constraints for automatic network planning. The activityoriented process models can be expressed by using dynamic preconditions, post conditions and scripts. Prolog’s interpretation feature supports the process evolution and its planning tool facilitates the process reasoning. MARVEL Strategy Language [Kaiser 88], is a rule-based process modeling language. There are three kinds of rules: the project rule set that describes process specific issues, the project type set that is used to specify the data with object-oriented classes and the project tool set that describes the interface with external tools. Rules may be executed by applying forward and backward chaining. In forward chaining, when the condition of the activity is satisfied, the activity is executed and the rule effect is asserted, which may cause the conditions of other activities to be satisfied. In backward chaining, if the user wants to execute a rule whose condition is not satisfied, other rules whose effect might satisfy the condition is considered to see whether their conditions are satisfied. If satisfied, the rule is executed. Otherwise, the similar backward process is applied. The result of backward chaining is either the satisfaction of the action or a notification to the user that the command cannot be executed. Merlin [Peuschel 92] is a rule-based process modeling language. Rules are organized to describe a process at three different levels of generality: kernel, process, and project, which together provide a working-context model of developer interaction and cooperation. Similar to MARVEL, rules and facts in the knowledge base may be interpreted in two forms: backward and forward chaining. Backward rules and facts are given in a Prologlike notation and are interpreted in a Prolog-like manner. The backward mechanism is exploited to select the roles and the activities a user may perform. It is also used to collect information in order to answer queries on the process state. Forward chaining is applied when explicit guidance is provided by the system. The rules being interpreted by forward chaining consist of a precondition, a list of activities and a post condition. Merlin offers a comprehensive description method for complex process models, because a significant part of a system can be described in a
declarative manner, and a process model is easily and incrementally extensible by new rules. Oikos [Ambriola 90] is a process modeling language based on a logic programming with the blackboard paradigm for problem solving. Agents are connected to blackboards. Each agent reacts to the presence of facts in its blackboard. The behavior of each agent is defined by a theory, which comprises a set of reaction patterns and a Prolog program known as the knowledge base. Each pattern defines a pair stimulus-response. The stimulus is given as a set of facts and the response as a goal (called the body) and another set of facts (called success set). A pattern can fire if the blackboard contains enough facts to unify with those listed in the stimulus set. A firable pattern is chosen nondeterministically and the body is executed (using the Prolog knowledge base). After the body has been executed, the facts in the success set are written on the backboard. GOLOG [Plexousakis 95] is a high-level logic programming language suitable for defining complex behaviors and capable of simulating action execution. The language was initially designed for high-level robot control and is the result of extending the situation calculus with perceptual and complex actions [Lesperance 94]. The language's features for specifying sequences or iterations of actions, non-deterministic and perceptual actions make it suitable for specifying business processes. GOLOG can be used for the simulation of processes and for proving schematic plans of actions correct. Business processes is viewed as actions (physical or perceptual) that affect the state of affairs or an agent's knowledge of this state. Using GOLOG, business processes can be specified, synthesized and tested
for feasibility and consistency. GRAPPLE [Huff 89] is a plan-based process assistant, which is developed based on the AI planning paradigm. A process step is specified in terms of rules with goals, sub-goals, preconditions, constraints, and effects, where sub-goals represent rules for substeps. Grapple can both generate and recognize plans. Process model is constructed from a set of process steps and a set of constraints in how these steps can be selected, ordered, and applied. Processes are formally defined hierarchically via plan operators, using multiple levels of abstraction. Plans are constructed dynamically from the operators. The sequences of actions in plans are tailored to the context of their use and conflicts among actions are prevented. Monitoring of the development process, to detect and avert process errors, is accomplished by plan recognition. This establishes a context in which programmer-selected goals can be automated via plan generation. GRAPPLE produces process plans dynamically by comparing conditions in current state of the environment with the preconditions of the operators available for acting on it. Plan execution can be simulated to reason about the viability of selecting a particular path for the plan.
3.2 State-Based Paradigm Some process modeling languages are developed based on state machines, Petri Nets or other graphical state-based paradigms. Petri Nets and other state-based paradigms can express the nondeterminism, concurrency, synchronization and other complex constraints among activities succinctly and accurately. Their graphical feature makes them especially useful for the representation of overall process topology and usually they support hierarchical structure to control complexity.
SLANG [Bandinelli 93] is a process modeling language for SPADE software engineering environment, which is based on a high-level Petri nets, called as ER nets. ER-nets is a mathematically defined class of high-level Petri nets to provide a powerful way to describe concurrent and real-time system [Ghezzi 91]. Process artifacts, including process models, are modeled as tokens of Petri net and implemented as objects in an object-oriented database. A guard, acting as precondition for the firing of the transition, and an action, acting as the function of generating new token values, are associated with the transitions of the Petri net. FUNSOFT [Deiters 94] is a process modeling language based on a high level Petri net built on top of Predicate/Transition nets. It supports the analysis of properties of the modeled process, like process simulation, model verification, and process evaluation, etc. Activity models, described in terms of FUNSOFT nets, describe which activities have to be executed within processes, which restrictions concerning the order of these activities have to be respected, and how these activities are implemented. Object models, expressed by extended entity-relationship models, describe the types of objects created and manipulated within processes. Organization models, expressed by organizational charts and roles, describe in which organizational context a process is supposed to take place, including roles. DesignNets [Liu 89] is a software development process modeling language described using a modified deterministic Petri net model to express parallelism augmented with AND/OR graphs to provide hierarchical abstraction. Entity Model [Humphrey 89] uses STATEMATE [Harel 88] to express a set of cooperating finite state machines. Each artifact has a number of states, and the events trigger transitions among these states. The facilities of STATEMATE are exploited to perform schedule planning and analysis of the modeled process.
3.3 Functional Paradigm Only a couple of process modeling languages are found to be based on functional paradigm. Functional paradigm can support hierarchical process decomposition to control complexity. HFSP [Katayama 89], Hierarchical and Functional Software Process, is a process modeling language based on a functional language AG and its environment SAGE [Shinoda 88]. It is developed on the theory of attribute grammars. The basic idea is that activities are functions that produce output objects from given input objects. Activities are decomposed using grammar rules, and attribute rules describe input-output relationships in terms of those associated with sub-activities. HFSP can support parallelism and nondeterminism. It models a process as a collection of process elements with input and output attributes. Each of these process elements can be hierarchically decomposed into process sub elements until a process step that can be mapped to an external tool invocation or manual operation is reached. In general process elements can execute concurrently, limited only by the availability of input attributes. HFSP also includes features to represent the sequencing, iteration and synchronization of process elements; the way they are created, suspended, resumed and destroyed; and communication among process elements. It also includes a process enactment mechanism that is responsible for activity scheduling.
PDL [Inoue 89], Process Description Language, is a process modeling language based on a functional programming language named ASL/F [Inoue 86], which is a subclass of an algebraic specification language ASL/1 [Torii 84]. Process flow and product flow initially given as function definitions in PDL, are transformed into the concrete definitions of the tool activations, message displays, etc. PDL scripts can be developed by stepwise refinement from abstract scripts into concrete ones.
3.4 Procedural Paradigm Procedural paradigm expresses the control flow among activities explicitly similar to conventional programming language’s control flow mechanism. This makes it easier to design the process modeling language as compiled language than other paradigms do. APPL/A [Sutton 95] is a procedural process implementation language, specifically a process-coding language, based on Ada. It extends Ada with persistent programmable relations, concurrent triggers on relation operations (for reactive control), optionally and dynamically enforceable predicates on relations (which may serve as constraints), and composite statements that provide alternative combinations of serializability, atomicity, and consistency enforcement (for programming high-level transactions). Various approaches for representing process state and recording process history can be expressed in APPL/A. Being based on Ada, APPL/A inherits from the language basic features, such as its type system, the module definition style (packages), and task communication paradigm (rendezvous). In APPL/A process descriptions are given in a procedural way. Certain aspects, such as consistency conditions, may be specified using a rule style. APPL/A does not directly embed process-modeling concepts such as activities, roles, or resources. Rather, it provides general-purpose control and data constructs that are computationally expressive and complete and that are not bound to any particular process-modeling scheme. JIL [Sutton 97] is a complex textual process modeling language evolved from APPL/A. It is an activity-oriented language combining proactive and reactive control flow. Proactive control specification is an imperative specification of the order in which sub-steps are to be executed as direct invocation. Reactive control specification is a reactive specification of the conditions or events in response to which sub-steps are to be executed as indirect invocation. Step is the central construct. In JIL, a process is a composition of steps. A step may have constraints, preconditions and post-conditions. Different from rule-based process modeling languages, these conditions are not trigger or enforced effect of the steps. They only act as supporting intra-step or inter-step consistency. An exception handlers are defined for local exceptions, including handlers for consistency violations, such as precondition violation, etc. Little-JIL [Cass 00] is a simpler graphical process modeling language derived from JIL.
3.5 Object-Oriented Paradigm Usually object-oriented paradigm is used to express the artifacts in the process. Object-oriented paradigm makes it easy to describe the complex structure of artifacts and their relationship. But there are some process modeling languages using object-oriented paradigm to model activity as first-order entity. Object-oriented paradigm considers a process to consist of a net of interacting objects.
E3 [Jaccheri 88] is an Object-Oriented (OO) process modeling language designed to express and analyze process, but not intended to be executable by either interpretation or compilation. It offers three conceptual levels that represent information about a software process at different generalization levels. The first is the instance level that is at the same abstraction level of a real process. The second one is the template level that represents characteristics common to various processes. The third one is the meta-template level that expresses general knowledge about how to manipulate templates. Objects and links are offered at instance level; classes and associations at template level; meta-classes and meta-associations at meta-template level. Each object is the instance of a class, and each link is the instance of an association. Moreover, each class is the instance of a meta-class and each association is the instance of a meta-association. Classes, metaclasses, and meta-associations are organized in three single inheritance hierarchies. A class inherits from its super class both attributes and methods, in the OO way. In addition, a special mechanism is designed for association inheritance. A kernel that consists of basic meta-classes, classes and meta-associations is offered. Each process template consists of primary elements, e.g., tasks, roles, humans, tools, and software products, and the relationships among them. These primary process elements are offered as first order elements. UML [UML97], an object-oriented modeling language, is used as a process modeling language [Jäger 99]. Although UML is not executable, a transformation mechanism is designed to generate an executable form, PROGRES (PROgrammed Graph REwriting Systems) [Schiirr 95]. Class diagrams are used for structural modeling and state diagrams and collaboration diagrams are used for behavioral modeling. UML package concept are used to structure process models (modeling-in-the-large). Use case diagrams and object diagrams are used for process analysis. However, some problems are discovered, particularly concerning the selection of a useful subset of diagrams and the adaptation of UML due to missing meta-modeling facilities. SOCCA [Engels 94], Specification of Coordinated and Cooperative Activities, is a graphical formalism and associated method for object oriented modeling of software development processes. The main aim of the SOCCA project is to extend object oriented modeling with means to precisely describe communication in a well-integrated fashion. SOCCA shares a lot of elements and concepts with other graphical notations in widespread use in the area of object orientation, especially OMT [Rumbaugh 91] and UML [UML97]. It is an integration of an object-oriented extension of entity relationship models, STDs (state transition diagrams), PARADIGM (a formalism to model parallel phenomena), and OFDs (object flow diagrams, an object oriented extension of data flow diagrams). EER aims at static aspects, OFD at functional aspects related to streams of data, objects and such, STD aims at isolated pieces of sequential behavior, and PARADIGM aims at influence on behavior via communication. ESCAPE+ [Reimer 97] is a process modeling language partially based on OMT [Rumbaugh 91] and employs class and state diagrams for process modeling. ESCAPE+ models tasks as operations attached to document objects. Several process modeling languages that adopt other paradigms to express activities also use object-oriented paradigm to model the
artifacts in process. For example, SPELL uses a unique objectoriented repository based on the entity-relationship data to describe the descriptions of both the process and the artifacts on which the process operates. SLANG’s process artifacts, the token in the Petri net, are stored as a typed object in an object-oriented database. Artifacts are organized as types in generalization hierarchy following an object-oriented style. Attributes and methods can be defined for each type. DesignNets’ objects and their relation are expressed in an extendible object oriented conceptual schema.
4. PROCESS EVOLUTION SUPPORTS Process domain is full of dynamics and endures the continuous changes. There is a problem of how intrinsic rigidity of a predefined model can be reconciled with the execution of actual process that is evolving and changing. Business process reengineering (BPR) is proposed for business process to adapt environmental changes. The situation is similar in software development process. Genericity, reflection, exception handling, and deviation provide different mechanisms to support process evolution. Generic support aims at design a process that is evolved less difficultly. Reflective support aims at dynamically evolving the process on the fly. Exception handling aims at handling the abnormal cases predicted during evolution. Deviation support provides a mechanism to allow the observed process to diverge from the modeled process.
4.1 Generic Support Generally a process model described by using certain process modeling language represents a family of processes, not just a single process. The generic process model can be applied in broader domain of processes. In addition, during the process modeling, the modeler might not know all the details while facing uncertainty. Refinement or instantiation is used to evolve a generic process to an actual process. Programming languages’ abstraction supporting types, like C++’s generic functions, are claimed to lack the kind of abstractions necessary to model generic processes and genericity mechanisms of programming languages, like generic packages in Ada or templates in C++, have several limitations to support generic processes [Balzer 93]. Some of these limitations are that their instantiation is performed in a single step where the parameters are supplied but generic processes prefer multi-stage instantiation; both the types available for parameter specification and values allowable as parameters are inadequate for generic processes. For example, process-step or task-chain should be allowed as type. Rather than create a new language with generic process support, [Balzer 93] developed a language extension mechanism and an architecture to add such support for existing languages. It supports the refinement of generic process descriptions into concrete instantiations during its enactment. The architecture includes three components. An Expander component linguistically extends a base language with a notation for meta-variables. A Binder component interactively elaborates meta-variables with actual process pieces that satisfy the required syntactic and semantic criteria. An Enactment Harness is engineered to interface with the underlying process engine to partially enact generic process specifications. If the types available for parameter specification and values allowable as parameters are extended to include higher-order
function, which is used to express the process step in functional paradigm, the linguistic support for generic process would probably be provided. We propose this as an open research question for researchers to explore.
4.2 Reflective Support In order to support process evolution on the fly, reflective support is preferred in the requirement of process modeling languages. With the reflective support, the built process can observe and adapt the whole process probably including itself during process evolution. A framework to support evolution by using reflection was proposed in [Conradi 94]. A meta-process, a set of external meta-elements, is designed to evolve and control the whole process. This reflection feature has been developed in programming languages like LISP, Prolog, Smalltalk, Java, etc. The process modeling languages that adopt rule-based or functional paradigms are inherently easy to support reflection. In order to support reflection, the process modeling languages should support late or dynamic binding and allows the executable code to be manipulated like data [Conradi 94]. This requirement makes interpretation languages are preferred to compilation languages. Some process modeling languages provide some reflective constructs to define process of changes made on existing process as one part of the process. This makes the process to be self-adaptable. The system can enable a segment of the process model to be adapted just before it is enacted. In SPELL, there is a reflective feature to define meta-process, which is similar to meta-types in Smalltalk, to define and evolve the process model. SLANG provides mechanisms to describe the meta-process and, in particular, to describe process evolution as part of the process. HFSP realizes flexibility and dynamism needed for process model by introducing reflection. As any functional language, HFSP is reflective, i.e. the execution status is treated as a basic data type that can be handled by the formalisms. This means that a process may be modified during the process itself.
4.3 Exception Handling Support There are two types of exception handling: block-oriented and rule-based. In block-oriented one, an exception-handling block is attached to the scope in which the exception may occur. This type is good to handle different occurrences of the exception in context sensitive way and is adopted by most procedural and objectoriented programming languages. In rule-based one, exceptions trigger exception-handling rules. It is good to handle the case where an exception can be handled uniformly regardless of where it originates. JIL or Little-JIL supports both types of exception handling. Examples of exceptions are violating process constraints such as preconditions or post-conditions, or failing in accomplishing an operation. Global rule-based exception handling is provided by the reactive control mechanism, where exceptions are treated as “normal” event outside of the process where they occur. Local block-oriented exception handling can be provided for a step through exception handler.
4.4 Deviation/Inconsistency Support Reflection supports a kind of gradual evolution of the process when more feedback is provided by gathered data from enactment. When there is an inconsistency between predefined process model
and actual process, reflection adapts the process model to fit the actual process. However, if the actual process during that time is not a normal situation, the dynamically adaptation for it is not appropriate. Exception handling can accommodate the expected exceptions but unable to handle the unexpected exceptions well enough. Deviation provides a mechanism to allow the process behaviors that differ from the predefined process model. Tolerating some deviations may generate inconsistencies between the process model and observed process. Rule-based paradigm has potential in detecting deviations and inconsistencies [Cugola 95]. In SENTINEL, two types of transitions are defined in LATIN: normal transitions and exported transitions. A normal transition is executed as soon as its ENTRY evaluates to be true. An exported transition is executed if the user requests it and its ENTRY is true. But if its ENTRY is not true, the user still can force the execution of the exported transition. In this case, the deviation from the prescribed process model takes place. The system can record the related events to determine the deviations and possibly corrupted data. If certain invariant is violated, the enactment is suspended. PROSYT [Cugola 98], PROcess Support sYstem capable of Tolerating deviations, is further work based on SENTINEL. It is capable of tolerating deviations from the process model by supporting users even when unexpected situations arise. It controls that nothing bad could happen and supports users in reconciling the process model with the process actually followed, if necessary. PLAN, the Prosyt LANguage, is a process modeling language for PROSYT. It adopts an artifact-based approach.
5. DISCUSSION Process modeling languages benefit from conventional linguistic paradigms by borrowing some language features from other domains and extending some other features required in process domain. In practice, most process modeling languages combines several linguistic paradigms to describe different perspectives of the process. Language features of process modeling languages, especially in software process domain, are summarized as follows [Armenise 93]. •
•
•
•
Features inherited from general-purpose sequential programming languages: o Abstraction o Modularity o Genericity o Nondeterminism Features inherited from concurrent, reactive, and realtime system languages: o Parallelism o Time constraints specification o Description of interaction with environment Features inherited from database languages: o Providing a conceptual data model (independent of the physical model) o Efficiently handling persistent objects of different granularity; o Supporting with very long transactions o Support versioning Some other software process specific features. These features are especially significant in software process domain, but probably may not be applied to other domains like business process domain.
Abstraction mechanism is provided to focus on the important information but hide irrelevant details. It is an effective way to control complexity and handle the scaling of the information in addition to information hiding, information reusability, which is closely related to abstraction. It can be used in different aspects of the process, like role, artifact, activity, etc. Hierarchical structure is usually used in organizing abstractions in process model. Modularity is closely related to abstraction. It provides the mechanism to structure the information in many logically independent components, which is called modules. Modularity eases the process evolution and complexity control. Modularity is also employed in different aspects of the process. Since activity is generally more volatile and complex than other aspects, modularity of activity should be paid more attention. Genericity provides the mechanism to describe a general solution for a set of related problems, by parameterizing it with respect to its possible instantiations. The genericity applied to artifact or role aspects appears to be natural and easy, which is similar to the genericity in conventional programming languages. However, the genericity support for process activities seems not to be easy, which is discussed in preceding section. Nondeterminism provides a mechanism not to specify how the choice among several alternatives is actually performed. For example, accepting or refusing an application is showed as a step in a process. Although the process might supply certain decision supportive information for human to make decision, this decision-making is nondeterministic. Another example is that when several tasks are ready to execute at the same time, picking one or more of them by users to execute is nondeterministic. Nondeterminism is everywhere in process. Parallelism provides a mechanism to express concurrency in process. Process is inherently full of concurrency. For example, from the perspective of role-activity relationship, one role can work on several activities at the same time and several roles can work on one activity at the same time. From the activity-activity relationship, several activities can take place at the same time. Process can be viewed as a reactive real-time system that comprises a set of activities that proceed in parallel and react to external events that may occur at unpredictable times. Time constraints specification and description of interaction with environment provide mechanisms to capture the time dependent and interactive properties of process. Database is generally used to store and maintain the data used in process. Separation of conceptual data model and physical mode provides a way of abstraction during process modeling. Representing and manipulating persistent objects of different granularity provides another way of abstraction and mechanisms to manage the complex objects in a process. Supporting with very long transactions can provide a mechanism to handle the process management if we view a process or sub-process as a transaction that has long duration with user interaction and even multi-user synergy. Transactional issues like roll back and interlocking needs to be carefully handled. Versioning provides a mechanism to manage the process history, especially the artifact instance history in the process. No a single linguistic paradigm is capable to describe the all aspects of the process effectively. Multiple paradigms are expected to use to model different facets of the process.
Object-oriented paradigm can effectively express the static entities and their relationship, like artifact, role or resource. But attempts to encapsulate the activity to artifact object or role object are not appropriate unless the process domain is regular and simple enough. This is due to the possibly complicated association between activity and artifact or role. An activity may involve several roles or work on several artifacts. It is difficult to make a decision to encapsulate the activity to which object. Even if we can do this, the relationship among these objects is very complicated. However, it is possible to use object-oriented paradigm to model activity as the object [Joeris 98]. Rule-based or state-based paradigm can effectively express the complex constraints among the activities the parallel order and other complex control flow patterns: AND-Split, AND-Join, ORSplit, OR-Join and iteration, etc. [WFMC]. Procedural or functional paradigm is capable of expressing the simple sequential or parallel constraints among activities, which can be used in the process domain with less complicated constraints. The action content inside an activity is usually expressed by using procedural paradigm. Indeed it is possible to use any conventional programming language that is executable.
control complexity without information expanding and collapsing mechanisms. A VoiceXML document (or a set of documents called an application) forms a Conversational Finite State Machine or Dialog Finite State Machine. The user is always in one conversational state, or dialog, at a time. Each dialog determines the next dialog to transition to. Transitions are specified using URIs, which define the next document and dialog to use. If a URI does not refer to a document, the current document is assumed. If it does not refer to a dialog, the first dialog in the document is assumed. Execution is terminated when a dialog does not specify a successor, or if it has an element that explicitly exits the conversation. A Subdialog is a mechanism for decomposing complex sequences of dialogs to better structure them, or to create reusable components. It is similar to the procedure call in procedural programming language. Figure 3 shows the execution flow when a sequence of documents (D) transitions to a subdialog (SD) and then back.
6. LINGISTIC STUDY OF VOICEXML 6.1 Introduction to VoiceXML Interactive Voice Response (IVR) aims to accomplish the Voice interaction management task between user and system. It represents an extremely cost-effective method of conveying information to callers via the telephone. IVR systems provide callers with fast, convenient, and automatic access to authorized database information, via any touch-tone telephone. Directed by pre-recorded human speech messages, telephone callers use their touch-tone keypad to interact with the host computer and database. IVR operates with existing databases to supply or collect the information necessary to answer questions and complete transactions. In effect, the telephone becomes a remote terminal to the computer, with the telephone keypad acting as the input device and the handset acting as the computers output device. VoiceXML [VXML], the Voice Extensible Markup Language, is a language for describing call flows for IVR applications. It is designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed-initiative conversations. Its major goal is to bring the advantages of webbased development and content delivery to interactive voice response applications. It separates user interaction code (in VoiceXML) from service logic (CGI scripts). VoiceXML is a derivative of the Extensible Markup Language (XML). VoiceXML builds upon the basic concepts and rules set forth by XML to define a logical vocabulary for describing interactive voice applications. Whereas XML is designed to represent arbitrary data, VoiceXML describes grammars, prompts, event handlers, and other data structures useful in describing voice interaction between a human and a computer. Although VoiceXML possess the well-formed hierarchical structure, inherited from XML, some tools only provide developers to edit and view VoiceXML source code in plain text, which is hard to
Figure 3. Execution flow when invoking a subdialog composed of two documents. Within a dialog, a Form Interpretation Algorithm (FIA) is used to drive the interaction between the user and a dialog, VoiceXML form or menu. In our viewpoint, FIA implies an Item Finite State Machine for the dialog items, which are generally the fields in a form. Each state in Dialog Finite State Machine is decomposed to an Item Finite State Machines as showed in Figure 4.
Dialog Finite State Machine Item Finite State Machine ………. i1
i2
i3
Dialog: Form, Menu Field items: , , , , Control items: ,
Figure 4. Dialog and Item Finite State Machines
6.2 Linguistic Analysis of VoiceXML VoiceXML is a combination of multiple linguistic paradigms including object-oriented, state-based and procedural paradigms. In addition, rule-based paradigm can be found implicit in VoiceXML. The whole program is organized by using objectoriented paradigm. Each dialog ( or ) or field item (, , , or ) is like the object in the program. Field item can be considered as the member attribute of its parent dialog. Dialog can contain variable (), like the member variable for that class, in addition to its child filed items. Field item cannot contain explicit variables like dialog. But there is an implicit variable for each field item. Dialog may contain some executable items (, , or ). Field item may also contain an executable item (). These executable items are like the member methods for the object. Usually the content of these executable items is using procedural paradigm. VoiceXML combines the proactive and reactive control mechanisms. The reactive control is implemented by state-based paradigm specifying intra-dialog transition. Intra-dialog/inter-field item transition is using state-based paradigm (Form Interpretation Algorithm). The proactive control is implemented by procedural paradigm specifying inter-dialog transition. Inter-dialog transition is using procedural paradigm (). Indeed a proactive control can occur in intra-dialog transition by using procedural paradigm (). Invocation of the executable items (member methods) is not explicit but implicit by event-driven. Events like the field is filled by user voice matched with associated grammar, make the state transition for the field and invoke the corresponding executable items. State transition can also be activated by using and inside the executable items. Rule-based paradigm can be found implicit in state-based paradigm of VoiceXML. For each field item, if the state of it is in “unfilled” like precondition, this field item will prompt (if any) and wait for the user’s input. When users respond with legal input for that field item, this field item’s block is executed and after its execution has finished, the state of that field item is set as “filled”, like post-condition. If more than one field items are in state of “unfilled”, the system chooses the first one according to their physical location order declared in the dialog. This prohibits the nondeterminism and parallelism. Parallelism is not supported by VoiceXML because IVR domain does not usually allow the concurrent execution of more than one activity. For example, it is not acceptable to prompt two sentences to interactive users at the same time. However the nondeterminism is sometimes preferred in IVR to provide enough flexibility to users. For example, users should be allowed to provide the voice input for a list of field items with any order, not constrained by the physical location order in the dialog. Each field has its own speech and/or DTMF grammars ( and or implicit type attributes). In order to provide the nondeterminism, a form can have form-level grammars. form item contained in that form can handle that its fields can be filled in any order or more than one field can be filled as a result of a single user utterance.
To provide more flexibility, the form’s grammars can be active when the user is in other dialogs. If a document has two forms on it, say a car rental form and a hotel reservation form, and both forms have grammars that are active for that document, a user could respond to a request for hotel reservation information with information about the car rental, and thus direct the computer to talk about the car rental instead. The user can speak to any active grammar, and have fields set and actions taken in response. Exception handling is provided by VoiceXML via its event-driven mechanism. The platform throws events when the user does not respond, does not respond intelligibly, requests help, etc. The interpreter throws events if it finds a semantic error in a VoiceXML document, or when it encounters a element. Each element in which an event can occur has a set of catch elements (, , , , or ). Although the exception handling is well designed in VoiceXML, there is no generic, reflective, or deviation/inconsistency support in VoiceXML.
6.3 Potential Extensions to VoiceXML The extension to existing languages can done via translation mechanism, as is done in Pizza [Odersky 97], Aspect-Oriented Programming [Kiczales 01], generic support for process modeling languages [Balzer 93]. It is more feasible than directly modifying the language standard while the extensions are not matured or being experienced enough. Those potential extensions to VoiceXML proposed below can be implemented by preferably translation mechanism or also possibly modifying the language standard. Inheritance enhancement: Although VoiceXML encapsulates the behaviors of dialog or field item in the “object” of dialog or field item, the inheritance and reusability features of objectoriented paradigm are not exploited. There are no relationships among the similar entities in VioceXML, which share the similar attributes. Therefore, maintenance and evolution of them are difficult. In order to increase the maintainability and reusability, the inheritance can be extended to the objects in VoiceXML. Overloading issue needs to be considered while introducing inheritance. The inheritance structure is orthogonal to the “iscomposed-of” structure implied by XML structure. Crosscutting handling: Similar to other ordinary software programs, the crosscutting is a common phenomenon in VoiceXML. For example, the prompts whose source is from the same URI are played to users in many different places in the VoiceXML code. The same exception handling statements are spread across the majority of the code. This makes the maintenance and evolution of the code difficult. Once we make a change in one place we have to manually modify many places and furthermore we have to maintain the consistency among these codes. To address this, the method invocation or macro with or without arguments can be introduced to VoiceXML. The place originally occupied by a copy of the codes can be replaced with an invocation point or macro reference point. The translation mechanism can translate these invocation or macro reference points to copies of the shared codes. Furthermore, the approach similar to Aspect-Oriented Programming can be introduced to make the reference points implicit. Precondition/post-condition enhancement: VoiceXML adopts the state-based paradigm in its intra-dialog control flow
mechanism. This reduces the programming burden on developer, gaining the expressive power together with the succinctness. In traditional procedural language, the code implementing the same control flow logic is much more complicated and less understandable. However, even for some simple control flow logics, the developers still have to write some conditional statements inside the executable statements. This makes the graphical programming difficult. We can extend current VoiceXML with precondition and post-condition constructs. The semantic of precondition for a field item or dialog is the conditions that need to be satisfied before interpreting that field item or dialog. The semantic of post-condition for a field item or dialog is the assignment results or state enforcement before exiting this field item. We have successfully done some case studies to transform the original VoiceXML to the one with extension of preconditions and post-conditions. Our study showed most of those implicit or explicit state transitions in current VoiceXML can be modeled as preconditions and post-conditions. Controlled deviation mechanism: VoiceXML provides the flexibility of event-based inter-dialog transition mechanism by form level DTMF grammars. However, we think these transitions are not enforced with enough assurance. When we intend to expose the form level DTMF grammars to only certain situations, we have no mechanisms to control it. The scope of the form level grammar in current VoiceXML can only be dialog or document. This event-based transition mechanism should be more controlled. Enhancement with precondition/post-condition is a possible approach. Since we add the explicit constraints of interpreting the dialog or field item, if we could allow certain user input to match certain grammar to interpret its parent dialog without fulfilling its preconditions, this is the deviation. Some existing mechanisms to handle deviation can be used to extend VoiceXML. Reflection support: Since VoiceXML is an interpreted language, it is possible to extend it with the reflection support. However, how the “meta-process model” (VoiceXML code) can monitor and modify the artifact (“process model”/VoiceXML code) is to be investigated. Unlike other process modeling language, VoiceXML can only handle limited types of “artifacts” in IVR domain. In order to support reflection, the VoiceXML interpretation engine probably needs to be modified and some new constructs in VoiceXML or another monitoring language should be designed.
7. LINGISTIC STUDY OF PASTA 7.1 Introduction to PASTA Process and Artifact State Transition Abstraction (PASTA) is a way to model complex processes in a graphical, systematic, precise, and structured way. It can be used to give a brief overview of a process or give a description sufficiently precise and detailed so that it is suitable for automation. Family-Oriented Abstraction, Specification, and Translation (FAST), a familybased software product line engineering process, is described in PASTA in [Weiss 99]. PASTA has been successfully applied in various workflow projects in business process automation. The key elements of PASTA are three hierarchies: •
Artifact Hierarchy: Artifacts represent final or intermediate work products or the information needed to produce them. Artifacts indicate who can perform an activity. The parent-
child relation in artifact hierarchy represents the “iscomposed-of” relation. •
Role Hierarchy: A role can be used to represent a unit of responsibility, assignment, authority, or work force. Roles indicate who can perform an activity. The parent-child relation in role hierarchy represents the “is-composed-of” relation. Generally the leaf role in hierarchy is certain class of users. The non-leaf role is certain organization that comprises certain subordinate organizations or class of users.
•
P-state/Operation Hierarchy: The leaf or elementary activity in hierarchy is called operation. The non-leaf or composite activity in hierarchy is called a process state (P-state). A Pstate is a group of activities that is performed in a particular situation to satisfy a particular concern. A P-State associates the related roles and artifacts for that group of activities. Pstates indicate what must be done to make progress, when it can be done, who can do it, and what the criteria are for completing an activity. Operation is an activity that is directly performable to produce effects on the artifacts.
And two kinds of state machines defined by P-state’s entrance/exit conditions, which are defined by states of artifacts: •
P-state Machine: P-state machine is a state transition machine for P-State activities. It specifies the constraints among a group of P-State activities, such as the sequential or parallel order, and other complex flow patterns: AND-Split, AND-Join, OR-Split, OR-Join and iteration, etc [WFMC].
•
A-state Machine: States of the artifacts are defined to correspond to milestones in the process of making key decisions. Activities performed by participant roles in the process cause the state machines for the artifacts to transition from one A-state to another.
To understand the conceptual framework of PASTA, we show a simple example to illustrate how the element of PASTA to capture and model the process in Figure 5.
Role in hierarchy GUI Form Artifact Role list for P-state Entrance Cond
Entrance Cond
Exit Cond
State-of(A) = empty
Exit Cond
P-state (check)
P-state (fill) State-of(A) = filled
State-of(A) = filled
State-of(A) = checked
empty Artifact List for P-state
Artifact A
Referenced Artifact List for P-state
fill
filled check
A-state machine
checked
Figure 5. PASTA Conceptual Framework with Example In this example, assume there is a form artifact A to be filled by certain role via certain fill activity and then be checked by machine automatically via certain check activity. In the right bottom, there is a A-state machine for this artifact. Artifact list for
P-state associates the artifact that can be modified with P-state. Reference artifact list for P-state associated the artifact that can be read but unwritten with P-state. These associations between the Pstate and artifact form the data flow. The entrance/exit conditions defined using artifact state form the implicit control flow, the execution order constraints among the activities. Certain role in hierarchy is associated with certain P-state via the role list for that P-state. GUI is provided to role to aid their manipulations on the artifact via the Form type artifact that contains the artifacts defined in artifact list for the P-state. Since the P-states and Artifacts are organized in different abstractions in two hierarchies, their corresponding state machines are also defined in different abstractions. In fact, these two types of state machines are two views of the same underlying executable state transition abstraction from two different perspectives. Actually that underlying executable state transition abstraction can be transformed to a global Petri-Net defined by the conversion rule in Table 1. That executable state transition abstraction provides a better and simpler representation than Petri-Net does but with same semantic. Table 1. Mapping between PASTA model and Petri Net Petri Net Places Transitions Triggering of transitions
PASTA States of artifacts Operations Automatic when operation’s role is System; User triggering when operation’s roles are certain users; Different flow instances
Tokens with different colors Note: When one operation does not change the state of one artifact that is present in its entrance condition, a line is added from that Transition (operation) to that Place (that artifact's state in entrance condition). To illustrate this transition, The P-state machine diagram for Qualify_Domain P-state in FAST showed in Figure 6 can be represented in corresponding Petri net showed in Figure 7 [Weiss 99].
Figure 6. P-state Machine Diagram for Qualify_Domain state-of(Economic_Model)=Referenced
Domain_Engineer
.
Gather_Data
Operation as transition Role as triggering of transition
state-of(Economic_Model)=Started
Domain_Manager
A-state as place
Analyze_Data
state-of(Economic_Model)=Reviewed
Domain_Manager
Reject
state-of(Family_Artifact:1)=Domain_Rejected
Accept
Domain_Manager
state-of(Family_Artifact:1)=Domain_Qualified
Figure 7. Petri Net for Qualify_Domain
7.2 Linguistic Analysis of PASTA PASTA is a combination of multiple linguistic paradigms including rule-based and state-based paradigms. Different from VoiceXML, PASTA aims at a more general and broader process domain. Although it is supposed to be a complex process modeling language to handle the complex process domain, the good designs of PASTA make it gain the expressiveness and simplicity at the same time. From the execution mechanism perspective, PASTA is a rulebased paradigm. Each executable activity has a precondition, post-condition and action. As soon as the preconditions for certain activity is satisfied, it is executed if it does not require the role participation and it is awaiting the participant roles to activate it if it requires the role participation. When the action, which is
implemented as the Visual Basic functions or other reusable components, has been executed, the system enforces the postconditions to be true. It adopts the forward chaining mechanism but no backward chaining mechanism is supported. Because rule-base paradigm are typically flat, they are not very good at expressing the overall process topology. To address this problem, PASTA introduces the state-based paradigm to organize these rules. The states of the artifacts are used to specify the preconditions and post-conditions of the rule (activity). Therefore the rules are connected implicitly by the common state predicates in their preconditions and post-conditions. Furthermore, the rules are abstracted by unstrict rule closure, which contains those rules coupled together by involving the state predicates of the same artifacts. The artifact state transition and P-state transition form two state machines from different perspectives. Hierarchy is the key abstraction mechanism to control complexity in addition to two types of state machines. In fact, the combination of rule-based paradigm and state-based paradigm (state machines) forms a Petri net, which is PASTA’s executable model.
7.3 Potential Extensions to PASTA Similar to VoiceXML’s extensions, the extensions to PASTA can be implemented by using translation mechanism or direct modification on language interpreter. However, since PASTA is a graphical process modeling language, the modeling tool needs to be modified to accommodate the extension even if we do not intend to modify the interpreter via adding a translator in between. Exported activity enhancement: Current PASTA only supports reactive control mechanism starting from the initiation points of the process flow. Similar to LATIN, PASTA is expected to provide exported activities for users to invocate or specify directly. Sometimes it is preferable to provide the flexibility for users to start to execute the process from middle or specify the goal activity and focus on the preceding activities of that goal activity. These two situations are corresponding to the application of exported activity mechanism on forward chaining and backward chaining. This enhancement does not require the modification of the language syntax or semantics but requires modification of the PASTA interpreter and interactive GUI between system and users. So are following two extensions. Backward chaining enhancement: Backward chaining can be used to analyze the involved artifacts, roles, or resources and give the optimal path and scheduling if users want the system to reach certain activity (goal). Even during enactment, backward chaining can be used as goal-oriented planning of the process, when we introduce the exported activity mechanism. For example, if users want the system to reach certain activity (goal), users can specify that exported activity. Then the system will notify the users a set of preceding activities that can possibly lead to specified activity and whose preconditions are satisfied in current environment. Generally the forward chaining is good at arriving-input-driven situation but backward chaining is more appropriate in goaloriented situation. This extension can be implemented by translating the PASTA model to Prolog programs and use Prolog tools to provide the planning information. Deviation with exported activity mechanism: Another different usage of exported activity control mechanism is in forward chaining. When users specify an exported activity to invocate, the system executes it without requiring its precondition to be satisfied. If its preconditions are not satisfied, deviation occurs.
Some mechanisms need to be design to handle the deviation and inconsistency, similar to those techniques discussed in [Cugola 95]. Exception Handling: Current PASTA does not provide exception handling explicitly. The exception handling related constructs are expected to design explicitly in the model. Because not only software process automation, but also workflow need the exception handling support [Casati 99]. Exception handling in PASTA can be designed to be event-driven. Both local and global event handling need to be provided. For example, PASTA can provide users to define exception and exception handler. One example is that if the participant role does not login to execute the activity for two days, this exception event will activate the exception handler, which sends a notification to the role users. Inheritance enhancement: This is similar to the one for VoiceXML. In order to increase the maintainability and reusability, the inheritance can be extended to the object (artifact or role) in PASTA. Overloading issue needs to be considered while introducing inheritance. The inheritance structure is orthogonal to the “is-composed-of” structure implied by PASTA’s hierarchical structure. Whether introducing the inheritance to Pstate hierarchy to handle the similar role or artifact association patterns among activities is to be further investigated. Crosscutting handling: This is similar to the one for VoiceXML. If we introduce the exception handling to PASTA, these exception and exception handler definitions can be potential crosscutting points across the model. Reflection support: Since PASTA is an interpreted language, it is possible to extend it with the reflection support. A meta-process can be designed in PASTA to monitor and modify the artifact of “process model”.
8. CONCLUSION Many process modeling languages have been proposed in literature. They can be categorized based on their underlying linguistic paradigms. These linguistic paradigms include rulebased, state-based, functional, procedural, and object-oriented paradigm. No single one paradigm can effectively express all the key elements expressed in the process conceptual framework we propose. Multiple linguistic paradigms are expected to use to model the process. Besides the expressiveness of modeling the information in process conceptual framework, process modeling languages need to provide some additional linguistic mechanisms to support process evolution. These mechanisms include generic, reflective, exception handling, and deviation/inconsistency support. Especially for the generic process support, some more research work needs to be done to see whether higher-order function genericity could be an effective solution for it. A linguistic study is performed on VoiceXML and PASTA. We identified the benefits and weaknesses provided by their underlying linguistic paradigms. Based on these, we propose the potential extension to these two process modeling languages. However, further work is to be done to validate the benefits and cost of adding these extensions in addition to the possible side effects of introducing, such as reducing ease of use, increasing language complexity, affecting other language features, etc.
9. REFERENCES [1] [Ambriola 90] V. Ambriola, P. Ciancarini, and C. Montangero. Software Process Enactment in Oikos. In R. N. Taylor, editor, Fourth ACM SIGSOFT Symposium on Software Development Environments, pages 183--192, Irvine CA, December 1990. ACM Press. Special issue of Software Engineering Notes, 15(6), December 1990.
[2] [Armenise 93] Armenise, Pasquale, S. Bandinelli, C. Ghezzi, and A. Morzenti, A Survey and Assessment of Software Process Representation Formalisms, International Journal of Software Engineering and Knowledge Engineering, 3(3), 1993, pp. 401-426.
[3] [Balzer 93] Robert Balzer, K. Narayanaswamy: Mechanisms for Generic Process Support. ACM SIGSOFT FSE 1993: 2132.
[4] [Bandinelli 93] Sergio Bandinelli , Alfonso Fuggetta, Computational reflection in software process modeling, Proceedings of the 15th international conference on Software Engineering, p.144-154, May 17-21, 1993, Baltimore, Maryland, United States
[5] [Casati 99] Casati F., Ceri S., Paraboschi S., Pozzi G. Specification and Implementation of Exceptions in Workflow Management Systems, ACM Transactions on Database Systems, 1999, vol. 24, n. 3, p. 405-451
[6] [Cass 00] Aaron G. Cass , Barbara Staudt Lerner , Stanley M. Sutton , Eric K. McCall , Alexander Wise , Leon J. Osterweil, Little-JIL/Juliette, Proceedings of the 22nd international conference on on Software engineering, p.754757, June 04-11, 2000, Limerick, Ireland
[7] [Conradi 94] R. Conradi, C. Fernstrom, and A. Fuggetta. Concepts for evolving software processes. In A. Finkelstein, J. Kramer, and B. Nuseibeh, editors, Software Process Modeling and Technology, pages 9--31. 1994
[8] [Cugola 95] G. Cugola , E. Di Nitto , C. Ghezzi , M. Mantione, How to deal with deviations during process model enactment, Proceedings of the 17th international conference on Software engineering, p.265-273, April 24-28, 1995, Seattle, Washington, United States
[9] [Cugola 96] Gianpaolo Cugola , Elisabetta Di Nitto , Alfonso Fuggetta , Carlo Ghezzi, A framework for formalizing inconsistencies and deviations in human-centered systems, ACM Transactions on Software Engineering and Methodology (TOSEM), v.5 n.3, p.191-230, July 1996
[10] [Cugola 98] G. Cugola, Tolerating Deviations in Process Support Systems Via Flexible Enactment of Process Models. In Transactions on Software Engineering (TSE), vol. 24, num. 11, November 1998
[11] [Deiters 94] W. Deiters and V. Gruhn. The FUNSOFT Net Approach to Software Process Management. International Journal of Software Engineering and Knowledge Engineering, 4(2):229- 256, 1994.
[12] [Engels 94] Gregor Engels and Luuk P.J. Groenewegen. SOCCA: Specifications of coordinated and cooperative activi-ties. In A. Finkelstein, J. Kramer, and B.A. Nuseibeh, editors, Software Process Modelling and Technology, pages
71–102. 1994, Research Studies Press Ltd. / John Wiley & Sons Inc., year. Taunton 1994.
[13] [Finkelstein 94] A. Finkelstein, J. Kramer, and B. Nuseibeh, editors. Software Process Modelling and Technology. Research Studies Press Limited (J. Wiley), 1994.
[14] [Ghezzi 91] C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezze, A unified high-level Petri net formalism for timecritical systems, IEEE Trans. Software Eng., vol. 17, pp. 160-172, Feb. 1991.
[15] [Harel 88] D. Harel , H. Lachover , A. Naamad , A. Pnueli , M. Politi , R. Sherman , a. Shtul-Trauring, Statemate: a working environment for the development of complex reactive systems, 10th International Conference on Software Engineering, p.396-406, April 1988, Singapore
[16] [Huff 89] Karen E. Huff , Victor R. Lesser, A plan-based intelligent assistant that supports the software development, ACM SIGPLAN Notices, v.24 n.2, p.97-106, Feb. 1989
[17] [Humphrey 89] Watts S. Humphrey , Marc I. Kellner, Software process modeling, Proceedings of the 11th international conference on Software engineering, p.331-342, May 15-18, 1989, Pittsburgh, Pennsylvania, United States
[18] [Inoue 86] Inoue, K., Seki, H., Taniguchi, K., and Kasami, T., “Compiling and Optimizing Methods for the functional Language ASL/F”, Science of Computer Programming, 7, 11, pp.297-312, Nov. 1986.
[19] [Inoue 89] Inoue, K., Ogihara, T., Kikuno, T. and Torii, K.: A Formal Adaptation Method for Process Descriptions, Proc. of the 1lth Int. Conf. on Software Engineering, pp. 145153(1989)
[20] [Jaccheri 88] Jaccheri, M.L. and Picco, G.P., and Lago, P. Eliciting Process Models in E3, ACM Transactions on Software Engineering and Methodology, 7:4, October 1988, pages 368-410.
[21] [Jaccheri 92] Letizia Jaccheri, Jens-Otto Larsen, Reidar Conradi .Software Process Modeling and Evolution in EPOS Proc. Fourth International Conference on Software Engineering and Knowledge Engineering (SEKE), Capri, Italy, 17--19 June 1992.Also as {EPOS} TR 159, NTH, Trondheim, 31 Jan. 1992, 13 p.
[22] [Jäger 99]Dirk Jäger, Ansgar Schleicher, Bernhard Westfechtel, Using UML for Software Process Modeling,in O. Nierstrasz, M. Lemoine (Eds.): Proceedings of the 7th European Software Engineering Conference held jointly with the 7th ACM SIGSOFT Symposium on the Foundations of Sofware Engineering, ESEC/FSE '99, Lecture Notes in Computer Science (LNCS) 1687, Springer-Verlag, Berlin, Heidelberg, 1999
[23] [Joeris 98] G. Joeris, O. Herzog: 'Towards Object-Oriented Modeling and Enacting of Processes', TZI Technical Report 7/98, Center for Computing Technologies, University of Bremen, 1998.
[24] [Kaiser 88] Gail E. Kaiser, Peter H. Feiler, and Steven S. Popovich. "Intelligent Assistance for Software Development and Maintenance." In 1EEE Software, May 1988, 40-49.
[25] [Katayama 89] T. Katayama. A hierarchical and functional software process description and its enaction. In Proceedings of the 11th International Conference on Software Engineering, pages 343-352, 1989.
[26] [Kiczales 01] Kiczales, G., et al. An overview of AspectJ. In Proceedings of the 15th European Conference on ObjectOriented Programming (ECOOP). Springer, 2001.
[27] [Lesperance 94] Y. Lesperance, H. Levesque, F. Lin, D. Marcu, R. Reiter, and R. Scherl. A Logical Approach to High-Level Robot Programming - A Progress Report. In Proceedings of the AAAI Fall Symposium on Control of the Physical World by Intelligent Systems, New Orleans, LA, 1994.
[28] [Liu 89] L. C. Liu, E. Horowitz, A formal model for Software Project Managemnt, IEEE Transactions on Software Engineering, Oct. 1989.
[29] [Odersky 97] Martin Odersky and Philip Walder. Pizza into Java: Translating theory into practice. In Proceedings 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 146 -- 159, January 1997.
[30] [Pall 87] Pall, Gabriel A. Quality process management. Englewood Cliffs: Prentice-Hall, 1987. ement. Englewood Cliffs: Prentice-Hall, 1987.
[31] [Peuschel 92] Burkhard Peuschel , Wilhelm Schäfer, Concepts and implementation of a rule-based process engine, Proceedings of the 14th international conference on Software engineering, p.262-279, May 11-15, 1992, Melbourne, Australia
[32] [Plexousakis 95] Dimitris Plexousakis, Simulation and Analysis of Business Processes Using GOLOG. In Proc. of the Conference on Organizational Computing Systems (COOCS'95), pp. 311-323, 1995.
[33] [Reimer 97] W. Reimer, W. Schgfer, and T. Schmal. Towards a dedicated object oriented software process modelling language. In Object-Oriented Technology – ECOOP ‘97 Workshop Reader, LNCS 1357, pages 299-302, Jyvtikyla, Finland, June 1997.
[34] [Rumbaugh 91] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. ObjectOriented Modeling and Design. Prentice-Hall, Inc., 1991, ISBN 0-13-620941-9.
[35] [Schiirr 95] A. Schiirr, A. Winter, and A. Ziindorf. Graph grammar engineering with PROGRES. In Proc. ESEC ‘95, LNCS 989, pages 219-234, Barcelona, Spain, Sept. 1995.
[36] [SEI] SEI Software Process Automation Forum: http://www.sei.cmu.edu/legacy/procauto/
[37] [Shinoda 88] Y. Shinoda and T. Katayama. Attribute grammar based programming and its environment. In Proceedings of the Zlst Hawaii International Conference on System Sciences, Software Track, pages 612-620, January 1988.
[38] [Sutton 95] Stanley M. Sutton , Dennis Heimbigner , Leon J. Osterweil, APPL/A, ACM Transactions on Software Engineering and Methodology (TOSEM), v.4 n.3, p.221286, July 1995
[39] [Sutton 97] Stanley M. Sutton , Leon J. Osterweil, The design of a next-generation process language, ACM SIGSOFT Software Engineering Notes, v.22 n.6, p.142-158, Nov. 1997
[40] [Torii 84] Torii, K., Morisawa, Y., Sugiyama, Y., and Kasami, T., “Functional Programming and Logic Programming for the Telegram Analysis Problem”, Proceedings of 7th International Conference on Software Engineering, Orlando, FL. ~~-57-64, March 1984.
[41] [UML 1.0] Unified modeling language 1.0. Technical report, Rational Software Corporation, January 13 1997.
[42] [VXML] W3C Note, Voice eXtensible Markup Language (VoiceXML™) version 1.0, 05 May 2000
[43] [Weiss 99] Weiss, D. and Lai, C.T.R., Software Product Line Engineering, Addison Wesley, Reading, MA, 1999
[44] [WFMC] Workflow Management Coalition, Workflow Management Coalition Terminology & Glossary 3.0, WFMC-TC-1011, Feb1999.
