Forschungsprojekt ECOMODForschungsgruppe Unternehmensmodellierung

Referenzgeschäftsprozesse und Strategien im E-Commerce

Introduction: Business Process Modelling vs. Workflow Management
Business process modelling (BPM) and Workflow Management (WfM) are two popular subjects in the area of information systems research (IS research, 'Wirtschaftsinformatik'). At first sight, they seem very similar: BPM and WfM foster a mainly  process-oriented perspective on organisations. The process-oriented view comprises activities and their relationships within and to an organisation's context. Relationships among business processes might be specified using control flow (consecutive, parallel, or alternative execution), hierarchical decomposition and/or generic relationships. Relationships to the organisational context comprise the assignment of organisational units (company, department, role) and resources (tools, machinery). However, the different view points taken by BPM and WfM, respectively, have lead to conceptual differences, which require thorough analysis before a mapping of both approaches can take place. They represent  different levels of abstraction on process-oriented organisations. The following table displays typical differences found in the literature:
Business Process ModellingWorkflow Management
  • Includes manual activities/processes [FrLa03]
  • "Conceptual level" of the enterprise (e.g. [Böhm00])
  • Business processes can be related to every kind of resource (i.e. not only IT) [Jung01]
  • Focusses on processing of digital business/office documents [FrLa03]
  • Manual processes or decision making processes are not considered [FrLa03]
  • Emphasises use of information technology [Böhm00, p. 3]
  • Workflows are business processes combined with IT [Sta97]
Overview of Contents
Contents of this Web page describe an approach for mapping concepts of a given business process modelling language to workflow schemata. (These contents have also been published as research report No. 47.)
  • We describe the mapping approach in general including modelling languages, standards and tools that were applied in this context.

  • We outline conceptual foundations, equivalences, and differences of  business process modelling (MEMO-OrgML)  and workflow modelling (XPDL).

  • In order to support mapping of business processes to workflow schemata we especially focus on information which has to be added to business processes in order to map them to workflows.

  • The section on implementation issues gives further insights into the configurations of the tools that are applied in order to achieve the mapping as well as generation of software based on workflow specifications.

  • The literature references used on this Web page are listed on the  References- page

View a complete example.

Towards Generating Software on the Basis of Business Processes
The implementation is based on the mapping of business process models to a workflow model and the appropriate configuration of a WfMS. The overall vision including applied software and corresponding documents as well as modelling languages is shown in the figure below.
The tool MetaEdit+ has been used for
  • modelling business processes (using the modelling language  MEMO-OrgML) and
  • mapping business processes to workflow-descriptions in  XPDL.
The Enhydra Shark workflow-engine has been applied as a runtime environment for workflows (for further details see  Implementation Issues):
  • The workflow-engine uses the generated workflow-descriptions for the execution of workflows.
  • Additionally, users can be managed and associated with workflow-participants inside the Shark-workflow-engine.
  • Java-applications can be developed and linked to workflow-applications in the workflow-engine.
Overview of Models/Diagrams and their Relationships
The actual implementation of the mapping of business process models to a running application consists of four different diagram types. The figure below visualizes the different models togehter with an example for each diagram type.
Workflow Specification Diagram Process Decomposition
A workflow-specification diagram is the root-diagram for the generation of an XPDL-conformant workflow-specification. It contains all participants (one or more), workflow-data (zero or more), and applications required (zero or more) for the workflow-process. For further information see foundations of workflow modelling. The workflow-specification-diagram contains a reference to a process-decomposition containing all (sub-)processes used within the given workflow process. The root process of the decomposition-hierarchy (mandatory) represents the workflow process itself and additional decomposed processes are possible. At least one elementary process has to be assigned to each composed process in the decomposition-diagram using a decomposition-relationship. For further information see  foundations of business process modelling modelling.
Process Model Workflow Activity Specification Diagram
The control flow of every decomposed process has to be specified using a process-model-diagram. This diagram has to include all sub-processes of the given composed process (connected via a decomposition-relationship). For further information see foundations of business process modelling modelling. Every elementary process in the process-decomposition-diagram has to be further described using a workflow-activity-specification-diagram. This diagram contains the binding of workflow-relevant data (actual parameters) to the formal parameters of a workflow-application. For further information see foundations of workflow modelling.

 Foundations - Business Process Modelling
The analysis, representation, and management of knowledge about an organisation and its processes has always been very important [KoPl00]. A lot of work has been done on the development and evaluation of ontologies for process modelling, the specification of process modelling languages as well as on business process modelling methods and concepts (see e.g. [WaWe93], [Web97], [GrRo99], [EJLT99], [SuOs97], [Herb97], and [Öst95]). Business process models can be used for various purposes:
  • Documentation of processes of an organisation to foster communication
  • Analysis of business processes
  • Simulation of processes
  • Support for business process re-engineering
  • Software development of process-oriented applications
Business process models represent a common medium for the communication of domain experts and novices. They offer domain level concepts and enable a broader distribution of knowledge.The analysis of business processes relies on a detailed description of process models and related concepts with respect to the analysis' purpose.
Depending on the analysis' purpose, a modelling language has to offer language features for modelling the facts which are in its scope. Analysis might for example support the detection of weaknesses in existing processes. Appropriate language features provided by a process modelling language support the identification of media clashes, unnecessary processes, or potentials for further optimisations. The potential for further optimisations relies on the degree of formal description of the business process model. Depending on identified weaknesses, business process re-engineering might be applicable.
Business Process Modelling with MEMO-OrgML
Multi-Perspective Enterprise Modelling (MEMO) is a method for modelling organisations according to different views as well as different levels of abstraction. MEMO includes several languages for modelling static, functional, and dynamic aspects of an enterprise. One of these languages is MEMO-OrgML (Organisation Modelling Language), which supports modelling of organisational structures and processes. Resource modelling has not been subject of the first conceptualisation of MEMO-OrgML, but will be added shortly.

An introductory example for a process that has been modelled using MEMO-OrgML is given in the figure below. An order is received by the distribution department and the data will be checked directly afterwards (process No. 1 called 'Check Data'). The order will be further processed if the given data is valid (event No. 4 called 'Valid Data') or aborted if the data seems to be invalid (event No. 3). Aborting an order results in sending a rejection message to the customer in process No. 9 ('Compose Rejection Message'). Further processing of the order comprises entering data into the order-management-system (process No. 2: 'Enter Order') followed by the parallel execution of the processes 6, 7 and 8. Process No. 6 is a composed process which consists of one or more sub processes. The process called 'Compose Acceptance Message' (No. 7) is a semi-automated process executed by the distribution department. Process No. 8 is a fully automated process sending a default email-message to the customer.
The following list gives a brief overview of language concepts and their notation in MEMO OrgML.
Symbols depicting processes

Abstract process Aggregated process Manual process

Semi-automatic process Automatic process Continuing process

Process performed by contractor Process performed by an autonomous institution Externally managed process('Black Box')
Hierarchie of composed processes

Displays processes as components of abstract or aggregated processes.
Symbols depicting events

Start-Event End-Event Relevant change of information change
(unspecified event)

Message arrived Temporal event -
certain time interval has exceeded
Temporal event -
certain point in time has been reached
Control structures

Process produces event Event triggers process

Parallel execution Synchronization after termination of one of the parallel processes

Synchronization after termination of all parallel processes
Exceptions are defined for the entire system
(e.g. collapse of communication channel, time out)
Annotations (natural language)

Constraints    Other comments
Further Business Modelling Concepts
In addition to the process-oriented concepts given above, there are two further concepts relevant for process-oriented modelling of organisations. Organisational units correspond to departments, divisions or roles assigned to a particular business process. Resources are actors or tools which are required for the execution of a business process.
Organisation units
The static structure of organisations can be described by an organisational chart. Such a chart shows an organisation by its sub-units and their respective relationships. The meta-model for the modelling of organisational charts is given in part a) of the figure to your right. An abstract organisation unit might either be a position or an organisational unit. Every organisational unit is a composition of other abstract organisational units. A position is an elementary description of the responsibilities of an employee. An example for an organisational chart is given in part b) of the figure to your right: An imaginary company consists of three departments (procurement, production, and distribution).

Organisational units and roles are elements assigned to business processes and refer to human actors which are responsible for the execution of a business process. Organisational units and positions as described here can be assigned to business processes. Roles are not necessarily defined in an organisational chart but can be assigned to business processes.
Resources are essential for modelling processes [PSO99]. Processes and their relationships mainly describe dynamic aspects and the order of events. Resources assigned to processes additionally specify objects required or used by business processes. Resources are usually not available in an unlimited amount (see [Nübe01],[PSO99]). Hence, the usage of scarce resources has to be taken into account for the analysis or simulation of processes as well as for the development of a workflow application or an information system. As the resource-modelling-language for MEMO-OrgML is currently under development, no graphical notation will be given here but a short introduction into the underlying meta-model. An excerpt from this meta-model is shown in the figure below. The class AbstractResource is the root of the generalisation hierarchy on resources. Every resource has a name (name : String), a textual description (description : String) and a list of resource attributes (attributes[0..*]:ResourceAttribute). Every resource attribute is a name-type pair for the specification of user-defined attributes on resources.
Within the context of process modelling, we generally distinguish human, physical, and intangible resources. A human resource is an abstraction of different perspectives on staff. Examples for such perspectives are concrete employees, roles filled by employees or business-oriented functions. Physical resources comprise all tangible objects used within a business process. Examples for physical resources are production plants, raw material, or computer hardware. In contrast to this, intangible resources do not have a physical manifestation. Examples for intangible resources are data, information, software, or even knowledge.

Human resources might be associated with concrete persons or employees of an organisation as well as abstract organisational units in an organisational chart. Hence, a human resource can be characterised by different aspects; it
  • can play an active role
  • may be responsible for the execution of e-business processes
  • needs some qualification and competences for its job
The type HumanResource is a subtype of AbstractResource and has the two attributes qualification and competenceProfile, both of type String. The qualification is an objectively describable criterion for the capabilities of a human resource. Usually, the qualification certificate is issued by an established educational body. The competence of a human resource reflects personal skills of human beings. Hence, a competence profile corresponds to a set of skills or competences of a particular role or person.

Physical resources comprise all tangible objects used within a business process and are neither human nor intangible. According to Heinen [Hei88, p. 242] - in the context of industrial production - it can be differentiated between non-consumable resources (Potentialfaktoren) and consumable resources (Repetierfaktoren). Non-consumable resources are not used up during a manufacturing process and are still available afterwards, whereas consumable resources either become a part of the resulting product or are used up and therefore not available anymore [SS01, pp. 89 f]. At this point we abstract from physical resources, because these are not relevant in our context of workflow applications and the perspectives we present on it.

Intangible resources are resources without a physical manifestation. Software in terms of a set of programs that run on a computer hardware is a key resource in the process of supporting workflows. The meta-type Software has two attributes: systemRequirements and scalability, both of type String. The system requirements are modelled as text and describe the environment for the execution of a software system (i.e. processor architecture, minimum main memory or operating system). Scalability corresponds to the ability of supporting growing numbers of clients. The meta-type Information was created to represent information or knowledge that is relevant within workflows. It has the attributes name (a symbolic reference to an information instance) and typeDefinition of type String which describes how the information is structured. Examples for information are certain customer data or enterprise knowledge of some kind.

 Foundations - Workflow Modelling
This section provides a short introduction into workflow management by giving an overview on common terminology and the description of the standards of the Workflow Management Coalition.
WfMC and Workflow Specification Languages
The Workflow Management Coalition (WfMC) was founded in 1993 as an alliance of companies and organisations dealing with workflow management. The mission of the WfMC is to establish a common terminology and standardised interfaces for workflow management. These interfaces comprise the definition, execution and management of workflows as well as references to external documents and applications [Jung01, pp. 126]. The conceptualisation of the interfaces is given by the WfMC's reference model depicted in the figure below. The workflow enactment services - using one or more workflow engines for the execution of workflows - represent the core of the reference model [Holl95]. A workflow engine is a software managing workflows with respect to given workflow definitions.
WfMC Reference Model
WfMC Reference Model [Holl95, p. 20]
The five different interface definitions correspond to the integration of external aspects:
  • Interface 1 specifies the exchange of workflow models between external modelling tools and a workflow management system. External tools might be graphical or textual editors for workflow definitions. Some general purpose process modelling tools supporting the WfMC standard can be used for the specification of workflows, too [Holl95, p. 20].
  • Interface 2 describes the communication between a WfMS and workflow client applications. Workflow client applications are applications directly correlated with the workflow engine. They usually implement basic functionality of workflow applications like notification and data transfer [Holl95, pp. 31].
  • Interface 3 addresses the need to integrate external applications. Usually, the needed functionality is not provided by the WfMS itself. Hence, there has to be an interface to other applications already running in the enterprise [Holl95, pp. 35]. Examples for such kind of applications are business related software and special software tools.
  • Goal of interface 4 is to integrate other workflow management systems. The specification comprises the invocation of remote activities, data transfer as well as synchronisation aspects between different workflow enactment services [Jung01, p. 126] [Holl95, pp. 41].
  • Interface 5 describes the communication between the workflow enactment services and external monitoring and administration tools [Jung01, p. 126].
Interface 1 is the most relevant specification for the purpose of mapping business process models to workflows. It concentrates on the specification of different types of workflows (processes) as well as associated organisational units and applications. The system-specific integration of applications is done using  interface 2/3 [Holl95, p. 20].
The Workflow Process Definition Language (WPDL) is the first attempt of the WfMC to specify of a standard for the interchange of workflow definitions. Being a standard for exchanging models, it does not comprise a graphical notation. Meanwhile, WPDL has been replaced by the XML Process Definition Language (XPDL), an XML-based document definition for workflows (see [Nori02]).
XML Process Definition Language (XPDL)
Concepts supported by XPDL are represented by the meta-model shown in the figure below. This meta-model generally comprises static entities (e.g. data or applications) as well as dynamic concepts (processes). Static entities are represented by the meta-types
  • Workflow Relevant Data,

  • Workflow Participant Specification and

  • Workflow Application Declaration.
Workflow-relevant data is initialised, created, read from external applications, and used during the execution of workflows [Nori02, p. 10]. It might be produced by an activity within a workflow or extracted from an external data source (e.g. an enterprise information system). For example, corporate databases are typical external data sources. These data sources are represented by the meta-type System and Environmental Data.
The workflow participant specification describes the resources which perform the given workflow processes [Nori02, p. 9]. This specification does not necessarily correspond to a human or a single person. It actually represents an abstract resource or a role which can be filled by one or more humans as well as an automated machine. Hence, the specification of a workflow participant corresponds to a resource available in an organisation or an entity in an organisational chart (Resource Repository or Organisational Model). The workflow application declaration provides the description of software applications needed for the execution of a workflow process [Nori02, p. 9]. Those applications are usually invoked by the workflow engine and workflow-relevant data has to be passed as a parameter (e.g. internal or external applications like corporate information systems or common office applications). Internal applications are usually provided as part of a workflow management system or can be developed using a proprietary development environment or language.
XPDL Meta-Model
XPDL Meta-Model [Nori02, p. 12]
A workflow process definition is an aggregation of static entities (data, applications, participants) as well as the description of the system's dynamic behaviour. Dynamic aspects of the meta-model are represented by the entity-types Transition Information as well as Workflow Process Activity and its concrete subtypes
  • Block Activity,
  • Atomic Activity and
  • Sub-Process Definition.
An activity is a given unit of work which will be executed by a participant using computer applications and relevant data (see [Nori02, p. 8]). Additionally, every activity is characterised by a start- and end-time as well as the fact whether it can be executed automatically by the WfMS or by a workflow participant. The transition information specifies the control flow between activities [Nori02, p. 9]. It consists of a starting activity, an end-activity and a condition under which the transition is made. An atomic activity is an indivisible unit of work which has to be done at one go. A sub-process definition allows the embedding of another workflow process definition. A block activity consists of a set of other activities (type Activity Set). The semantics of an activity set is similar to the one of a macro. If an activity set is called during the execution of a workflow process, the activities contained in the set are copied into the calling process definition [Mato03, p. 13].
Basic Workflow Concepts
Main concepts for the description of the dynamic aspects of a workflow system are activities and transitions. Activities correspond to defined units of work which can be atomic or consist of a set of activities. The control flow between activities is specified by transitions. Hence, a transition relation between two activities defines the ordering of these activities. An activity can be started if its preceding activities (connected by transitions) have terminated. Transitions, activities, and static entities (i.e. IT-related resources) are grouped by a so called workflow process definition.
Workflow Process Definition
A workflow process definition groups all elements necessary for the execution of a workflow. As shown in the meta-model depicted in the figure above, these elements comprise dynamic (activities and transitions) and static aspects (data, applications and participants). Additional attributes are a unique identifier, a name and two headers:
  • The process header comprises the creation date, a textual description and different time-related properties (e.g. estimated duration of a process' execution) of a workflow process.
  • The redefinable header consists of information about the author of the process definition, a country key, its publication status, responsible participants and a version number.
An activity set is a set of activities and transitions. All transitions contained in this set can only start from activities within this set and end in activities within this set. In other words, there are no transitions leaving an activity set or coming from outside. Properties of an activity set are a list of activities, a list of transitions and a unique identifier.
Workflow Process Activities
As shown in the figure below there are different types of activities within a workflow process definition. An atomic activity is an indivisible unit of work executed under the control of a WfMS. Such an activity can be executed automatically or by a human participant and usually works on workflow-relevant data. In contrast to this, block and route activities do not refer to workflow-relevant data. A block activity executes an activity set and has no own behaviour. Invoking an activity set means the start of the first activity in the set. The execution terminates with the last activity in the activity set (see the figure below [Nori02, p.30]). A route activity is an activity with no behaviour. It only serves as a dummy activity for cascading transition conditions (see subsequent section on transitions).
Different kinds of activities in XPDL [Nori02, p.30]
Different kinds of activities in XPDL [Nori02, p. 30]
According to XPDL there is only one general XML-element for activities called  Activity. Specific elements for route, block or sub-flow activities are missing. The differentiation between different types of activities is done by the annotation of alternative attributes. Those attributes are named  Route, Implementation and BlockActivity. Activities can additionally be specified in terms of their level of automation (automatic or manual) as well as their implementation alternatives (no implementation, tool or subflow):
  • An automatic activity can be fully controlled by the workflow engine using internal and external applications.
  • Manual activities require the involvement of a human being.
  • Activities corresponding to the no-implementation alternative cannot be supported by an WfMS (e.g. manual tasks).
  • A tool supported implementation implies the usage of a software application.
  • If the implementation type is set to  subflow, the execution has to be delegated to another workflow process definition. Parameters can be passed to such a sub-flow activity and the synchronisation can be specified with respect to a synchronous or asynchronous execution.  Synchronous execution requires the calling process to wait for the termination of the called process. After its termination the called process might pass output values to the calling process. During an  asynchronous execution the calling process does not have to wait for the termination of the called process and no output values can be returned.
Additional information for activities are deadlines and simulation information:
  • A deadline is the expiration of a given period of time. A deadline might for example be a milestone (given a project management context) or a specific appointment. The occurrence of a deadline can be handled synchronously (the current activity is interrupted by the deadline) or asynchronously (the handling of the deadline has to be done parallel to the currently running activity).
  • Simulation information extends the model by giving specific data for the simulation of models. Examples for specific data are average costs, expected duration and average waiting time.
As shown in the figure above, every activity is a join-point for several incoming transitions  (join element) and specifies the type of splitting for outgoing transitions  (split element). Both - join and split - can refer to parallel or alternative executions of workflows. An alternative split (XOR) represents a fork specifying that exactly one of the given alternatives can be executed. An alternative join corresponds to the synchronisation of an alternative split . The parallel execution of activities is started by an AND-split and ended by an AND-join. Rules for the construction of workflow descriptions regarding parallel and alternative connectors (splits and joins) are classified by so called  conformance classes:
  • A NON-BLOCKED conformance class implies no formal properties of a diagram regarding the relationships between splits and joins.
  • If the conformance class is set to LOOP-BLOCKED, the graph build by the activities and transitions is a directed acyclic graph (DAG).
  • A FULL-BLOCKED graph implies that every AND-split has exactly one AND-join, every XOR-split exactly one XOR-join and vice versa. Additionally every path starting from the split will reach the corresponding join.
A transition is partly specifies the control flow between activities. As shown above the information whether incoming transitions of an activity are disjoint (alternative) or conjoint (parallel) is assigned to the activity. Additional information about a transition is assigned to the so called transition information [Nori02, p. 40]. Basic elements of such a transition are
  • its name (i.e. a character string),
  • a textual description and
  • a condition.
A condition should be a (semi-)formal specification - represented by a Boolean expression - of the circumstances enabling or disabling a transition. Additionally, a starting and an ending node are assigned to transition information. Consequently, every transition is characterised by exactly one source activity (from), exactly one destination activity (to), and a Boolean expression representing a firing condition. There are four different kinds of conditions in XPDL:
  • CONDITION: A transition can fire if its condition is evaluated to true.
  • OTHERWISE: Indicates a default transition which will fire if no other transition's condition evaluates to true.
  • EXCEPTION: An exception is a special transition indicating an abnormal behaviour. An exception-condition can trigger the rising of a special condition.
  • DEFAULTEXCEPTION: A default exception is triggered if all other exception conditions are evaluated to false.
Extended Workflow Concepts
Workflows are managed by a workflow management system by assigning tasks (as parts of workflow instances) to given resources. Such a resource might be either a human participant or a workflow application. A human resource usually corresponds to a role filled by a specific person in an organisation. A workflow application might be categorised into internal and external applications. An internal application is usually implemented by the WfMC itself and is closely coupled to the workflow system. An external application is an application independent from the WfMS.

Regarding the specification of resources for the execution of workflows there is one major problem. On the one hand, XPDL aims to be a language for a system-independent workflow definition interchange. Hence, a workflow model described using XPDL should be independent from any specific workflow engine. On the other hand, the description given by an XPDL-document should be sufficiently precise for the execution of workflows. This aspect might require the annotation of specific users or applications which are subject to a proprietary definition by a WfMS. Consequently, the XPDL-definition only provides an abstract mechanism for the specification of human resources and software-applications.
Workflow Participants
The XPDL-specification describes workflow participants as "an abstraction level between the real performer and the activity, which has to be performed" [Nori02, p. 43]. The engine has to map every abstract participant to a user given in the workflow management system's environment. The characterisation of every abstract participant includes its unique name and type. Possible types of workflow participants are:
  • RESOURCE: A specific resource given in a workflow management system's environment.
  • RESOURCE_SET: A set of resources.
  • ROLE: A role description that directly corresponds to a role given in an organisational chart. Such a role might be a function or some kind of qualification filled by a human.
  • ORGANIZATIONAL_UNIT: An arbitrary element of an organisational chart.
  • HUMAN: A human being interacting with the WfMS by worklists and/or applications (i.e. a concrete human being, like 'John Miller')
  • SYSTEM: A software application representing the participant of a fully automated workflow.
Those participants are assigned to activities of a workflow model using the Performer-attribute of an activity [Nori02, p. 31]. Hence, an activity keeps a reference to an abstract participant using the performer-attribute (which is rather a character string than a reference to a workflow participant).
Workflow Application Declaration
According to Junginger, workflow applications can be divided into internal and external applications [Jung01].
  • An internal workflow application is implemented as part of the WfMS. They are usually implemented using a programming language given by the WfMS. In the context of XPDL, those applications are called procedures.
  • An external application is an individual software package which can be used by a WfMS.
Using XPDL, a workflow application is specified by a unique identifier, its type and a list of parameters. The name of an application represents a unique id and does not necessarily correspond to its physical location or a specific implementation. Like the description of workflow participants, the identification of a workflow application is only a symbolic link. The interpretation of such a symbolic link representing a workflow application depends on the WfMS at hand. There are workflow engines supporting internal applications, external applications, or both [Jung01].

 Conceptual Mapping
On this page we present the mapping of business process model concepts to workflow descriptions in XPDL.
Workflow Process Definitions
Every workflow process definition in XPDL generally consists of activities, transitions, applications, participants, and workflow-relevant data. Hence, such a workflow process definition comprises its activities and corresponding resources. Additionally, every workflow process definition consists of two different headers and a body. The two headers are the definition header and the redefinable header (see table below). The workflow process definition header is valid for all sub-activities and a workflow process redefinable header might be overridden in subflows.
Definition Header
  • Meta-information on a process and
  • Instance-specific data
  • For example: version, temporal unit, estimated duration, priority
Re-definable Header
  • Meta-information on a workflow process
  • Properties can be overridden in subprocesses
  • For example: author, publication status
Activity Set
  • Set of activities and transitions
Workflow Process Definition Header
Attributes of a definition header for workflow processes are listed in the table to your right. The creation date is assigned to a process definition during its definition and therefore represents the definition time of a workflow schema. This information can be extracted from the modelling tool supporting MEMO-OrgML and is not part of the MEMO languages' specification. The workflow process' description can be seen as the description of the top-level process of a decomposition hierarchy in MEMO-OrgML.
The valid-from- and valid-to-attributes allow to specify a period of time for the validity of a process definition. Hence, a process definition can only be used between valid from and valid to (empty string means unlimited validity). Since there is no equivalent concept in MEMO-OrgML we assume an unlimited validity for all processes. The other attributes only contain information on workflow instances. The duration- and limit-attribute (the limit has to be interpreted by a specific WfMS and has no meaning in the context of XPDL) contain an expected duration for the execution of the given workflow-process using a specific duration unit. The time estimation is an aggregation of waiting- and working-time and duration. The waiting time corresponds to the time needed for the preparation of a process' execution and the working time correlates with the expected execution time. Those concepts are not part of the MEMO-OrgML and have to be added to a process model.
OrgML (Meta Data)XPDL: Definition Header
Creation Date (meta)Created (creation date)
Process DescriptionDescription
 -Duration & Duration Unit
 -Limit (vendor-specific)
 -Time Estimation
 -Valid From/To
 -Waiting Time
 -Working Time
Workflow Process Re-definable Header
The attributes of a workflow process redefinable header are listed in the figure to your right. The meta-information on the author of a model and its version can be derived from the data available in the modelling tool. The codepage specifies the character-set used for the presentation of texts. Country keys are specified by the ISO in the ISO 3166 standard. The publication status indicates whether a process definition is under revision (UNDER_REVISION), released (RELEASED) or in use (UNDER_TEST). Responsible(s) corresponds to an organisational unit which is responsible for the execution of a given workflow process. The responsible person can be derived from the organisational unit in the MEMO-diagram.
OrgML (Meta Data)XPDL: Re-definable Header
Modeller (meta)Author
 - Codepage
 -Country keyt
 -Publication status
Organisational UnitResponsible(s)
Version (meta)Version
Generation of headers
XPDL-workflow-headers contain information on a workflow process (e.g. author, version), process-information (e.g. description, responsible(s)) and instance-related information (e.g. duration, time-estimation). This kind of information is not part of a language specification. Instead, it can be managed by a modelling tool and then be mapped directly to an XPDL-based description. Some process information (e.g. priority) is not yet available in MEMO-OrgML and has to be added to a process' definition. Instance-specific information should not be included in a business process modelling language for conceptual modelling. However, it can complement existing business processes on a different level of abstraction.
Mapping of Resources, Applications, and relevant Information
At first sight, resources seem to be easy to map to workflow participants, workflow applications, and workflow-relevant data. However, this task is hampered by some details concerning the abstraction level of resources on the one hand and the concepts given in XPDL on the other hand.
Human Resources
According to MEMO-OrgML, a human resource is an abstraction on persons, employees, roles, or other staff-related perspectives. In XPDL, a workflow participant "is an abstraction level between the real performer and the activity, which has to be performed. During run time these abstract definitions are evaluated and assigned to concrete human(s) and/or program(s)." [Nori02, p. 43]. Mapping of an abstract actor (as given in an XPDL-description) to a concrete actor (e.g. the user of a WfMS) has to be done by the workflow-management-system.
As shown in the table to your right, the resource's properties 'name' and 'description' can directly be mapped to an XPDL-file. The properties attributes 'qualification' and 'competenceProfile' will be neglected because they have no direct correspondents in XPDL. A unique identifier required by XPDL can be generated in the context of the mapping of OrgML to XPDL. Such an identifier corresponds to an object identifier in MEMO and the generated XPSL-Id has to be unique within the XPDL-definition.
The specifications of "participant-type", "extended attributes" and "external reference" are an extension to a business process model (modelled using MEMO-OrgML). Alternatives for a participant type are resources, roles, organisational units, humans, and software systems [Nori02, p. 44].
OrgML: Human ResourceXPDL: Participant
 -Participant Type
 -Extended Attributes
 -External Reference
attributes -
qualification -
competenceProfile -
Extended attributes are name-value pairs and allow the annotation of system-specific information for different WfMS-products. (Note the difference between resource-attributes and extended attributes: A resource-attribute is a name-type-pair and an extended attribute is a name-value-pair.) The name is used to identify the extended attribute and the value contains information relevant for a particular WfMS. An external reference is a reference to an external document providing the specification of a workflow-related entity. Such a document can for example be a globally available XML-DTD (specifying the structure of a workflow entity) or a web-services interface-definition (using WSDL). All these extensions have to be provided by a workflow-specific extension to business-process-models.
The XPDL's notion of a workflow application declaration mostly corresponds to software used within a business process. A workflow application represents a software-tool required for the execution of a workflow. Every application might be invoked by the WfMS and the XPDL abstracts from concrete implementations. Every application is defined as a symbolic reference in XPDL which has to be assigned to concrete applications by the WfMS.
The resource's (software) properties 'name' and 'description' can be directly mapped to an XPDL-document. The properties 'systemRequirements' and 'scalability' will be neglected because they have no correspondents in XPDL. XPDL requires a unique identifier, which cannot be expressed in MEMO-OrgML. However, such an identifier could either be explicitly assigned to OrgML models (which would require a small extension of the language) or generated within the automatic mapping of OrgML to XPDL. External attributes and an external reference are handled equivalent to the respective attributes for Human Resources (see above).
The attribute 'Formal Parameters' corresponds to a list of single formal parameters which are specified using the following properties:
  • Id: Identifier
  • Data Type: Type of the formal parameter
  • Description: Textual description of the formal parameter
  • Index: Position in the parameter list
  • Mode:
    • IN: read-only parameter
    • OUT: write-only parameter
    • INOUT: Parameters used as in- and output parameter
The Id of a formal parameter has to be unique within the namespace of a process.
OrgML: SoftwareXPDL: Application
 -Formal Parameters
 -Extended Attributes
 -External Reference
systemRequirements -
scalability -
In the context of business process modelling, the description of information usually corresponds to the specification of information types which are used within a business process. In contrast to this, workflow-relevant data is associated with variables containing concrete information. Such variables are generally referenced by a unique name (as identifier) and correspond to a given type.
The appropriate Id for a workflow specification might be generated automatically. Name, description and data type can directly be resolved from the corresponding attributes of the MEMO-process model (see table to your right). Extended attributes have to be handled the same way as extended attributes of human resources and applications. Additionally, an initial value might be assigned to a variable. The maximum length and the property of being a collection can be determined by the attributes Is Array (the variable is a multi-valued type) and Length (upper bound of a sequence).
OrgML: InformationXPDL: Data
typeDescriptionData Type
 -Extended Attributes
 -Initial Value
 -Is Array
Mapping of Process Types
MEMO-OrgML supports several different kinds of process types, which have to be mapped to appropriate (i.e. similar) concepts given in XPDL. In MEMO-OrgML there are concepts such as composed, manual, automated, and semi-automated processes. In XPDL, there are generic and block activities. Conceptual relationships between MEMO-OrgML-processes and XPDL-activities are discussed in this section.
Manual Processes
There are various alternative options for mapping manual processes to workflows (see the corresponding research report for details). The alternative chosen comprises mapping manual processes to workflow activities. Every manual process will be mapped to an activity with a human actor and no applications. Consequently, manual processes correspond to some kind of dummy-activities in a workflow-schema. Such a dummy-activity only serves for the recognition of the completion of a manual process. The termination of a manual process might trigger the start of a following process. As an effect, every manual activity has to be confirmed in the WfMS. The described option allows mapping the process itself as well as relevant participants (human resources) to the workflow model.
OrgML: Manual ProcessXPDL: Generic Activity
organisational unitPerformer
 -Transition Restrictions:
  • Join: AND, XOR
  • Split: AND, XOR
The Id will be generated out of the manual process' identifier and the attributes name and description can be directly mapped from the process definition to the XPDL-document. The organisational unit of a manual process can be mapped to the performer of the workflow activity. The transition restriction specifies whether all incoming transitions (Join) are synchronised (AND) or alternative (XOR) as well as all outgoing transitions (Split) are parallel (AND) or alternative (XOR). This information is determined by the kind of in- and outgoing arcs of the business process models.
A parallel split will be mapped to an AND-split and an alternative split to an XOR-split. Analogously, a parallel join is mapped to an AND-join and an alternative join to an XOR-join. Information which is not included in the business process model but necessary for a workflow activity's specification is shown in the table below.
As most of the workflow-relevant data is not available in a business process model, there has to be an extension to those models. We emphasise a so called workflow-diagram for every business process which has to be mapped to a workflow schema. This diagram contains all additional information for the implementation and simulation of business processes in a workflow-environment.
DeadlineSpecification of a deadline and an action to be taken if it is reached.
DocumentationIdentifier of an external documentation file (e.g. URL or a filename).
Start ModeManual Mode: The user has to start the activity manually (indicating the beginning of his work)
Finish Mode Manual Mode: The activity has to finish according to a user's interaction (indicating the end of his work).
ImplementationNo: Implementation by manual procedures
IconReference to an external file containing an image for the representation of an activity.
LimitExpected maximum duration for the execution of a process (vendor-specific)
PriorityA value describing the initial priority of a process.
Simulation InformationEstimations for the simulation of an activity.
Semi-automated Processes
In MEMO-OrgML semi-automated processes are executed by human resources using IT-related resources (soft- and hardware). Hence, semi-automated processes rely on human and software-technical resources. Those kinds of processes can be mapped to generic activities.
Mapping of general information on a semi-automated process is equivalent to the one of a manual process as shown above. Most workflow-specific information can be generated using a workflow-diagram. Additionally Start- and Finish-Mode as well as the process' implementation have to be determined:
Start ModeManual Mode: The user has to start the activity manually (indicating the beginning of his work)
Finish Mode Manual Mode: The activity has to finish according to a user's interaction (indicating the end of his work).
ImplementationTool: Implementation is supported by an application
Fully Automated Processes
An automatic process is executed without the intervention of a human participant. Nevertheless, an organisational unit can be assigned to an automatic process, too. That means that it is responsible for the execution of this process. Basically, the mapping of automated processes can be handled like a manual process (see table). In contrast to a manual or semi-automatic process the assignment of a performer has no effect on the execution of an automatic process.
Start ModeAutomatic: Triggered by the system.
Finish ModeAutomatic: Triggered by the system.
ImplementationTool: Implementation is supported by an application
Aggregated Processes
Aggregated processes in MEMO-OrgML have no inherent implementation but consist of other processes. A block-activity in XPDL corresponds to a set of sub-activities and has no own resources. We will not use subflows, because every subflow contains its own set of performers and tools. As there is no support of name-spaces (in OrgML) we will not support the concept of sub flows. Hence, every aggregated process will be mapped to a block-activity and all contained processes are collected into an activity set.
Mapping of Control Flow and Events
The type of control flow is determined by the workflow activity's definition. All outgoing transitions of an activity are either parallel (AND) or alternative (XOR). Every join (incoming transitions) is either a parallel or alternative synchronisation. The specification of joins and splits is associated with a process' definition.
Events do not exist as specific concepts in XPDL. Hence, there is no direct correspondence between events in a business process model and a workflow-schema. Nevertheless events given in a business process model can be used for the definition of conditions for firing of a transition. As given in the table to your right an event's name and description can be mapped to an XPDL-description. The Id can be constructed from an event's Id and context. The condition has to be complemented to the activities description. Preceding and succeeding activities can be derived from the business process model.
OrgML: EventXPDL: Transition Information
 -From (set of activities)
 -To (set of activities)

 Implementation Issues
The mapping of business process models to XPDL-documents is the basis for the development of a prototype for software-generation. The underlying vision is the automatic generation of software (i.e. executable programs) out of models. To achieve this goal, we used the following approach:
  1. Creating business process models using MEMO-OrgML

  2. Extending the business process models by workflow-relevant information

  3. Mapping each business process model to an XPDL-document

  4. Executing the processes on the basis of the XPDL-document using a Workflow-Engine
    (including importing the XPDL-description into the WfMS and customizing the WfMS)
MetaEdit+ 4 and the Shark Workflow Engine by Enhydra were used in order to develop a prototype for software generation.

(Download: Patch for import in MetaEdit)

Implementing a modelling language using MetaEdit+
We implemented a MEMO-OrgML modelling tool using MetaEdit+. MetaEdit+ is a tool for the development of modelling tools and currently available in version 4. Basic concepts of MetaEdit+ are objects, relationships, roles, and diagrams.
  • Objects represent the nodes within a diagram.
  • Relationships represent the edges between (or connecting) objects.
  • Roles specify additional information on the appearance of an object in a given relationship.
  • Proper combinations of objects via relationships using roles are defined in diagrams.
Implementation of MEMO-OrgML
The two most important diagram types of MEMO-OrgML have been implemented: Decomposition of processes and Process models. A process-decomposition-diagram expresses decomposition-relationships between processes. Every composed process consists of several elementary and/or composed processes. Every composed process has the role of a composite in the context of decomposition. Every subordinated process (with respect to a decomposition-relationship) plays the role of a part. A part can either be another composed process or an elementary process.

A composed process used in a process-decomposition-diagram can be further specified by a process-model-diagram. Such a diagram can be connected to a given model-element by a so called explosion. An explosion is a concept given in MetaEdit+ that allows for the connection of an object in a diagram to another diagram. This concept can be used to connect a composed process with a process-model-diagram. (Please refer to the corresponding research report for more details and examples.)
Implemenation of additional diagrams
In order to map a business-process-model to an XPDL-document, missing information has to be added to the business-process-model. The section on conceptual mapping describes rules for mapping the concepts of MEMO-OrgML to the concepts of XPDL. Since the language concepts of MEMO-OrgML have not yet been documented thoroughly, we decided - for practicality reasons - to extend the existing process modelling concepts by additional diagrams representing the information required for valid workflow descriptions in XPDL. Two diagram-types have been added to achieve this goal: workflow-specification-diagram and workflow-activity-specification-diagram. A workflow-specification-diagram supplements a business-process-model with workflow-related abstractions. This diagram-type contains objects of the following types:
  • Workflow Process: A workflow-process contains a reference to a corresponding business-process. Usually, the corresponding business process is a composed process which in turn consists of other business processes and their control-flow. Business processes are mapped to XPDL-activities according to the rules given in the section on mapping. Additionally, a link to the documentation of a business process and the annotation of extended attributes is possible.

  • Workflow Participant: A workflow-participant is an XPDL-specific concept and determines the actor of a workflow. Such a participant is associated with an organisational unit in MEMO-OrgML and is supplemented with extended attributes and a participant-classifier. Possible classifiers are the ones given in the section on workflow modelling

  • Workflow Application: An application is the specification of a workflow-related tool. Such a tool can either be an internal procedure or an external application (the section on workflow modelling). The application-object in a workflow-specification specifies a unique identifier, name, and formal parameters of a workflow-application.

  • Workflow Information: A workflow-information-object specifies information used in a workflow and can be seen as a variable. This specification consists of a unique identifier, a name and a data-type as well as a default-value and other XPDL-related fields (refer to the section on mapping).

A workflow-activity-specification-diagram is associated with an elementary process (using an explosion). The workflow-activity-specification describes the workflow-application as well as actual parameters used for the execution of such a process. Generally speaking, a workflow-activity-specification-diagram relates a process to an application and the assignment of actual parameters. Hence, an activity-specification associated with a process binds an application to workflow information. Additionally, it is specified whether an application is an internal procedure or an external tool.
Generation of XPDL-Documents with MetaEdit+
The mapping of MEMO-OrgML-models to XPDL-conformant workflow-definitions is realised using the code-generation mechanisms of MetaEdit+. MetaEdit+ includes a language for the specification of mappings between internal models and external textual specifications. Every workflow-process-specification is mapped to one XPDL-file. The header of the XML process-definition-language-based file starts with the XML-header (determining the XML-version and character-encoding). The WfMC recommends the generation of at least one package for each XPDL-file [Nori02, p. 19]. (For details about the structure and syntax of the headers see the corresponding research report.)

Every generated XPDL-file consists of exactly one package-definition and one workflow-definition included in this package. The workflow-definition consists of the following sub-definitions:

  • data-fields
  • participants
  • applications
  • activity-sets
  • activities
  • transitions

The specification of data-fields, participants, and applications is derived from the workflow-specification diagrams. Afterwards, the activity-sets are generated based on the workflow-specification-diagram. There will be an activity-set for every composed process in the decomposition-diagram (except for the root-process). The root-process is mapped to the package specification and the workflow-process-specification. Every composed process which is part of a decomposition of the root process will be mapped to an activity set. Each activity-set contains the herein included processes as well as their transitions.
After the generation of the headers, the workflow-process' data-fields, participants and applications as well as activity-sets, MEMO-OrgML processes are mapped to workflow-activities. Every process (composed or elementary) is mapped to exactly one activity using the direct mapping exemplified here and following the rules given in the table to your right.
  • A manual process is performed by a human being and requires no IT-related resource. Hence, the corresponding activity-specification requires a workflow-participant and does not allow the annotation of a workflow-application. The workflow-activity has to be started manually (indicating the beginning of the execution of the manual process) and finished manually (end of process) as well.
  • A semi-automated process also requires a participant but a workflow-application has to be specified, too. It has to be started and finished by the human participant.
  • An automated process will be started and terminated automatically (by the WfMS). It does not necessarily need a participant (it can be annotated) but requires a workflow-application.
  • A block-activity contains a set of activities (an activity-set) and does not require a participant or an application. Hence, a composed process is mapped to a block activity (as well as to an activity set containing its subsequent processes).
Process Type (MEMO OrgML)Activity Specification in XPDL
Manual processParticipant: required
Application: not applicable
Start-mode: manual
Finish-mode: manual
Semi-automated processParticipant: required
Application: required
Start-mode: manual
Finish-mode: manual
Automated processParticipant: not required
Application: required
Start-mode: automatic
Finish-mode: automatic
Composed processParticipant: not required
Application: not required
Start-mode: not applicable
Finish-mode: not applicable
A transition between two workflow activities corresponds to a followed-by relationship. A transition starting in activity A and ending in activity B means, that activity B can be started after the termination of activity A. Information about the kind of control-flow is not part of a transition-specification. Nevertheless it will be part of the activities' specification. Another conceptual difference between process-models in MEMO-OrgML and XPDL-activities is the absence of events in a workflow-specification. The mapping of MEMO-OrgML's control-flow to XPDL-transitions will be explained using an abstract example in the figure below.This example consists of four processes and three events. The process called A is followed by event No. 10 which in turn results in the parallel (or concurrent) execution of processes B and C. The termination of process B is connected to the occurrence of event No. 11 and the one of C to the occurrence of 12. If both events occurred (parallel join), process D can be started.
The generation of transitions is based on a simple algorithm: Every MEMO-event will be mapped to at least one transition. There will be one transition for every combination of starting (from) and ending (to) points. Event No. 10 given in the model above will for example be mapped to two transitions: One transition from A to B and one from A to C. The unique identifier of each transition is generated by concatenating the identifier of the preceding process, the event's id and the identifier of the succeeding process. The information about the type of control-flow is associated with the preceding process. The split-transition-restriction of process A is set to AND. The events 11 and 12 will be mapped to one transition each and the join-transition-restriction of process D is set to AND.
Using Shark/Enhydra as Workflow Engine
An open-source workflow-engine implemented in the programming language Java has been used for the execution of the XPDL-files. The Shark-engine fully supports the XPDL-standard of the WfMC and provides the association of workflow-participants with concrete users as well as the association of workflow-applications (in XPDL) with procedures.
Mapping participants to users
Workflow-participants can be declared using the XPDL-concepts presented here. Different types of participants are
  • Resource (also: resource-set; a set of resources)
  • Role
  • Organizational_Unit
  • Human
  • System
The Shark-engine provides a mechanism for the association of participants with specific users of the WfMS. This is applicable if the type of the participant is a resource (resource-set), role or organisational unit. Depending on the context, the role of an escalation coordinator for example might be assigned to a specific user and reassigned to another user after the reorganisation of the company. If a participant cannot automatically be mapped to a Shark-user, the activity will - by default - be assigned to the administrator. If the type of participant is Human the participant will be mapped to a WfMS-user with the same name. For example: A workflow-participant of the type Human and with the name jjung will be associated with the local user (say: in the Enhydra Shark-engine) named jjung. If the participant's type is System, the actor is assumed to be a software-system and the activity is performed by a workflow-application. Hence, the association between workflow-participants and WfMS-users generally has to be defined by an administrator. Such an association can be omitted for human participants and software systems. In the latter cases an automatic assignment is provided by the workflow-engine.
Updating workflow data
The XPDL-standard provides no mechanism for the manipulation of workflow-relevant data except for the execution of workflow-applications. The Shark-engine allows for the manipulation of data by using extended attributes in the context of workflow-activities. The relevant extended attributes are listed as follows:
  • Name: VariableToProcess_UPDATE  -  Value: <workflow-data>
  • Name: VariableToProcess_VIEW  -  Value: <workflow-data>
The first attribute specifies data which can be manipulated in a workflow-activity and the second one only allows for the display of a variable's value. The symbolic identifier <workflow-data> has to be replaced by a specific workflow-data's name.
Mapping workflow applications to procedures/appliations
A workflow-application is specified in an XPDL-file by an application-declaration (as explained here). Such a specification only includes a symbolic reference to a concrete application. Generally, the WfMC distinguishes between a procedure (an application implemented within the WfMS) and an application (an external piece of software). The current version of the Shark-engine only supports internal procedures implemented in Java. The association of a workflow-application to a procedure is provided by the Shark-engine. Every application included in an XPDL-specification has to be associated with a Java class which is under the control of the Shark-engine. Such a Java-class has to be placed in the storedprocedure-directory of the Shark-installation and has to implement a public static method called execute without a return parameter.


This section on 'Mapping Business Processes to Workflows' is based on the following working report:
Jung, J.: Mapping of Business Process Models to Workflow Schemata - An Example using MEMO-OrgML and XPDL,
Arbeitsberichte des Institut für Wirtschaftsinformatik, Nr. 47, April 2004.
Literature References
[Böhm00]Böhm, M.: Entwicklung von Workflow-Typen: Ein Leitfaden der methodischen Anwendungsentwicklung am Beispiel ausgewählter Workflow-Aspekte, Berlin et al.: Springer, 2000
[EJLT99]Eertink, H.; Janssen, W.; Luttighuis, P.O.; Teeuw, W.; Vissers, C.: A Business Process Design Language, In: Wing, J.; Woodcock, J.; Davies, J. (Eds.): FM '99, Vol. I, LNCS 1708, Springer, 1999, pp. 76-95
[FrLa03]Frank, U.; Laak, Bodo van: Anforderungen an Sprachen zur Modellierung von Geschäftsprozessen, Research Report of the IS Research Institute, University of Koblenz, Nr. 34, 2003
[GrRo99]Green, P.; Rosemann, M.: An Ontological Analysis of Integrated Process Modelling, In: Jarke, M.; Oberweis, A. (Eds.): CAiSE '99, LNCS 1626, Springer, 1999, pp. 225-240
[Hei88]Heinen, E.: Produktions- und Kostentheorie, In: Jacob, H. (Hrsg.): Allgemeine Betriebswirtschaftslehre, pp. 209-299, Gabler, 5. Edition, 1988.
[Herb97]Herbst, H.: Business Rule-Oriented Conceptual Modeling, Physica- Verlag, 1997
[Holl95]Hollingsworth, D.: The Workflow Reference Model, Document Number TC00-1003, Winchester: Workflow Management Coalition, 1995
[Jung01]Junginger, S.: Workflowbasierte Umsetzung von Geschäftsprozessen, Dissertation, Universität Wien, 2001
[KoPl00]Koubarakis, M.; Plexousakis, D.: A Formal Model for Business Process Modelling and Design, In: Wangler, B.; Bergman, L. (Eds.): CAiSE 2000, LNCS 1789, Springer, 2000, pp. 142-156
[Mato03]Matousek, P. :Verification of Business Process Models, PhD Thesis, Technical University of Ostrava, 2003
[Nori02]Norin, R.: Workflow Process Definition Interface: XML Process Definition Language, Document Number WfMC.TC-1025, Lighthouse Point (Fl): Workflow Management Coalition, 2002
[Nübe01]Nübel, H.: The resource renting problem subject to temporal constraints, In: OR Spektrum (2001) 23, pp. 359-381.
[Öst95]Österle, H.: Business Engineering: Prozess- und Systementwicklung, Springer, 1995
[PSO99]Podorzhny, R.M.; Staudt Lerner, B.; Osterweil, L.J.: Modeling Resources for Activity Coordination and Scheduling, In: Ciancarini, P.; Wolf, A.L. (Eds.): COORDINATION '99, LNCS 1594, Springer, 1999, pp. 307-322
[SS01]Schiemenz, B.; Schönert, O.: Entscheidung und Produktion. Lehr und Handbücher der Betriebswirtschaftslehre, München, Wien, Oldenbourg Verlag, 2001
[Sta97]Stark, H.: Understanding Workflow, In: Lawrence, P.: "Workflow Handbook 1997." Chichester et al.: Wiley, 1997, pp. 5-25
[SuOs97]Sutton, S.M.; Osterweil, L.J.: The Design of a Next-Generation Process Language, In: Jazayeri, M.; Schaure, H. (Eds.): Software Engineering - ESEC/FSE '97, LNCS 1301, Springer, 1997, pp. 142-158
[WaWe93]Wand, Y.; Weber, R.: On the Ontological expressiveness of Information Systems Analysis and Design Grammar, In: Journal of Information Systems, Vol. 3, Nr. 2, 1993, pp. 217-237
[Web97]Weber, R.: Ontological Foundations of Information Systems, Coopers and Lybrand Accounting Methodology, Monograph No. 4, 1997
Further Links