WIDE的模型语言研究

WIDE的模型语言研究

例子：

发布由WIDE生成的技术文档,其流程是：

在文档发布前，先要内部审查一下。

如果审查通过就可以提交。

否则文档就要重写，重审查。在文档通过前写与审查的循环将继续。

下面先是一个form(可看作一种信息)的定义，关于form的概念可见下。

1 FORM_MODEL Paper.Review OP CS OF Twente

2 FORM Review

3 BEADING "REVIEW FORM"; SPACE;

4 LABEL "Paper" LINKS ENTITY: paper;

5 LABEL "Number" LINKS INTEGER[3] : number; NEW.LINE;

6 LABEL "Title" LINKS STRING[120] : title; NEW-LINE; SPACE;

7 HEADING "Rating (1-6)";

8 LABEL [ " O r i g i n a l i t y " , "Technical Quality", "Significance",

"Presentation", "Overall Rating" ];

9 LABEL LINKS ARRAY[S l OF INTEGER[l] : ratings; NEW.LINE;

l0 SPACE; HEADING;

II LABEL "Comment" LINKS STRING[1000] : comment; NEW-LINE;

12 LABEL "Reviewer" LINKS STRINO[~0] : reviewer;

13 LABEL "Date" LINKS DATE: review.date;

14 END-FORM;

15 FORM Author_Form DERIVED_FORM Review

16 WITHOUT reviewer;

17 ONLY READ FOR ratings, comment, review.date;

18 END-FORM;

19 FORM Reviewer.Form DERIVED.FORM Review

20 ONLY READ FOR number, title;

21 ONLY print FOR paper;

22 INITIALLY

23 r a t i n g s . I l l = NULL, ratings.J2] = NULL,

24 ratings.[3] ---- NULL, ratings.J4] = NULLj.

25 comment = NULL,.reviewer = NULL, review.date = NULL;

26 ENDAVORM;

27 END-MODEL

Figure h Form Model - Publication Process

然后是该过程的模型：

1 WORKFLOW-MODEL Publishing OF CS OF Twente

2 USES ORGANISATIONAVIODEL WIDE;//需要的组织模型

3 USES FORM_MODEL Review.Form;//需要的信息之form

4 uSES D.ATA~MODEL Publication;//需要的信息之数据模型

5 CONTROL

6 START Submit-Paper;

7 Submit_Paper ENABLES Receive-Review;

8 Receive_Review IF p-accepted = TRUE

9 ENABLES Polish_Paper;

10 Receive-Review IF p-accepted = TRUE

11 ENABLES Solicit_Funding;

12END Receive-Review 1F p-accepted = FALSE OR

13 (Polish_PapeArN D Solicit_Funding);

14 ROLE

15 Submit_Paper.Write-Paper,

16 PoLish-Paper.Write_Paper BY SAME STAFF;

17 TASK Submit_Paper

18 START Write_Paper;

19 Write-Paper ENABLES Review_Paper;

20 Review_Paper IF p_ratings.[4] > 3 ENABLES Send.Paper;

21 Review_Paper IV p.ratings.[4] < 3 ENABLES Write_Paper;

22 END Send.Paper;

23 ROLE

24 Write_PaperR, eview_Paper BY DIFFERENT STAFF;

2~ END.TASK;

...

26 TASK PoLish.Paper

27 START Write_Paper;

28 Write-Paper, Solicit-Funding TOGETHER ENABLE Send_Paper;

29 END Send-Paper;

30 END_TASK;

...

31 BASE_TASK Review_Paper

32 VIEW Reviewer_Form(p_paper, p_no, p_title, p . r a t i n g s ,

p_comment, p-reviewer, p.date);

33 PRE_CONDITION

34 Reviewer_Form.paper <1> NULL;

35 Reviewer,Form,number <> NULL;

36 Reviewer-Form.title <:> NUbL;

37 MESSAGE

38 "Pleasef ill in alL fields.";

39 POST-CONDITION

40 EVERY Review_Form <> NULL;

41 ROLE

4~ BY SOME x STAFF PROVIDED '~en~lish" IN x.Langu~tges;

43 END.TASK;

...

44 END_MODEL

可以看到，任务间的顺序用ENABLES来指明，其中的判断条件由IF指明，

Write_Paper和Solicit-Funding的joint到Send_Paper，由TOGETHER ENABLE指明的。

WIDE的模型和结构：

WIDE Workflow model and architecture

F. Casati*, P. Grefen**, B. Pernici*, G. Pozzi*, G. Sánchez***

* Politecnico di Milano, Italy

** University of Twente, The Netherlands

*** Sema Group sae, Spain

mailing address:

Barbara Pernici

Politecnico di Milano, piazza Leonardo da Vinci 32

I-20133 Milano MI, Italy

e-mail: [e-mail]

工作流中的信息通常关注：什么时候一个工作任务开始执行，执行任务需要的应用信息，将工作任务分配给代理（组织模型与过程模型严格分离，通过授权机制连接，即用授权将过程模型中的角色映射到组织模型中的代理。）的原则，工作任务结束后将激活的任务是什么。因此，在业务相关的工作流中，较少关注工作任务本身。工作任务只是不正式地被描述。工作任务间的连接要复杂得多，有些工作任务的执行是相关联的。

下面是一个WIDE的模型，主要表现：组织模型与过程模型的分离关系，以及如何使用授权机制将两个模型连接起来。两个模型的分离是WIDE的一个特点。

workflow process model

WIDE的模型具有办公室信息系统的一些特点。WIDE的用户通常会想手工进行工作，并使用应用程序来支持工作。然后交换文档，共享数据。数据可能在数据库中，并且数据库可能与其他程序和系统共享着。

为了支持这种方式的工作，我们需要专门为办公室流程定义的工作流模式，该模式中任务的执行流是相互协调工作的。

WIDE还注重对异常情况的管理。

信息模型：

工作流使用的信息可以在工作流模式层中定义，或在共享的数据库中，或是工作流中传递的文档。

工作流模式层中的定义的变量只能在定义的环境使用。

数据库数据是一个交换格式化数据的地方。

通过文档交换的数据：定义和类型：

文档documentation元素就是用户为了完成任务，显式使用创建，修改的信息的集。文档有类型：

document：外部工具产生的，不由工作流系统解释。如文本文件，图片等。

form：数据字段的集合，可以由工作流系统解释。过程的变量可以由form使用，

比如显示变量，用变量计算。

Compound document：document，forms，其他compound document组成

的，其组成方式是固定。

Dossier：document：document，forms，其他compound document组成

的，其组成方式是可变的。

对临时信息建模：这对于系统的进化是相当重要的。

任务：

任务是完成工作流目标的基本工作单元。

任务的结构：

name，description，version，

actions：manual或者一系列的状态，

role：执行任务的role，以及任务分配时的约束条件，

task information：输入输出，

exceptions，

authorized actions，

compensation action。

任务执行时的状态转换：

WIDE中的三种任务，以及任务间的连接关系：

supertasks：可以再分解为tasks。

Multitasks：有这种情况，多个工作任务并行执行，它们完成类似的任务。意义待考。

WIDE的工作流描述语言WFDL

两部分：

声明部分：变量，共享数据库，文档，dossiers，任务。

工作流结构定义部分。

声明部分：

name，

description，

administrator：定义者，

version，

exception，

variables，types and functions,

responsible agent:允许开始一个case的role列表，

start-case condition:定义case可以自动执行的条件，

document items。

异常：

WIDE以（condition,reaction）的方式来处理异常。

Condition可以根据工作流信息，临时条件，发生的事件来指定。

WIDE中的事件：

警告：

警告alert指出一个计划的异常，警告与异常有点不同，他在normal flow中。但是与异常表示一样的结构。

执行异常，

组织异常，

关于工作流的概念模型的讨论：

The first descriptions of WFs have been proposed by office modeling as a way of describing

office procedures [BP84]. Such descriptions were based on extensions of classical formal

models (such as Petri Nets, production rules and flowcharts); a number of modeling support

tools were proposed. The need of a closer relationship between modeling techniques and

enactment of processes has been particularly developed within the process modeling area in

software engineering. This research has produced several methodological contributions and

WF specification languages [GHS95, EN93]. Several tools for process modeling, generally

based on Petri Nets, are focused on the ability of “animating” WFs, thereby understanding

their dynamic behavior [BFG93].

Recently, a growing interest has concentrated on connecting WF systems to existing

information systems. In particular, the desire of interconnecting to existing data and of coping

with large volumes of WF information has provided impetus to the bridging of WFs and

database technologies. The challenge posed by WF management pushes towards removing

some of the classical limitations of databases in the context of concurrency and transactional

models [H93]. Novel features of databases, such as active rules, are seen as particularly

promising in the context of WFs [DHL90, WC95].

A powerful specification mechanism is proposed in ObjectFlow [HK96]. The specification of

tasks’ coordination can be very complex and case-dependent, and the model includes

advanced task types (static and dynamic compound tasks), with a semantic similar to that of

supertasks and multitasks in WIDE.

Task assignment is based on a pull model; roles are defined in the system, and tasks are

assigned to roles. Agents can then select tasks associated to the roles they belong to. Agents,

before terminating a task, can also specify successors tasks to be executed, bypassing the flow

description. The effects of the change are local to a specific WF instance.

ObjectFlow also offers a limited exception handling mechanisms: special tasks can be defined

to handle anomalous situation. When an agent detects an exception, it aborts active tasks in

the normal flow and modify the flow structure in order to give the control to the handler task.

The WIDE approach is different, since we allow case execution to proceed, and in the

meantime the WFMS (possibly with the aid of a human agent) performs the exception

handling procedure. This should avoid undue losses of work. Anyway, ObjectFlow behaviour

may be represented in the WIDE model by defining suitable exception handling routines.

The ObjectFlow model is very well suited to implement administrative workflows, but the

lack of a flexible exception handling mechanism and of explicit access to external databases

could limit its effectiveness for production workflows.

In the model developed at Bellcore [RS94] the focus is on transactional workflows.

The most peculiar feature of this model is that possible task states may differ from task to

task. This is because tasks can have different characteristics according to their transactional

behaviour. Tasks may also have different isolation properties: the results of an incomplete

task may be made visible to other concurrent tasks, or they may be deferred until task

commitment. Flow control is determined by scheduling preconditions, that can be static

(defined before the workflow execution) or dynamic (created during workflow execution).

Preconditions may relate execution states of other tasks, local workflow variables or external

variables (i.e., variables modified by external events, such as time values). Simple

preconditions can be combined with Boolean operators to form complex scheduling

constraints.

This model gives to the workflow designer a greater flexibility with respect to the WIDE

model; on the other hand, the fact that in principle a task could start independently from the

execution state of the others, and in particular independently from the end of other tasks does

not ease the specification of ad hoc and administrative workflows. Furthermore, it is difficult

to give a graphical representation of the flow structure, since the start of a task is not

necessarily related to the end of another task.

In [BW95] a taxonomy of activities and exceptions is introduced. A interesting proposal,

absent in other workflow models, relate the definition of batch activities, i.e., activities that

require control and data coordination among different instances of a workflow. A proposed

example relates the ranking of candidates for a position. In WIDE, batch activity can be

implemented in ad-hoc schemas, that synchronize with other cases of other workflows by

wait connectors and the shared database.

已有系统和模型：

Many commercial systems have been introduced to support WFM, and we discuss here some

characteristics of WIDE with respect to some of the most popular commercial systems,

namely IBM FlowMark, ActionWorkflow, and InConcert. Extensive reviews of commercial

WFMSs can be found in [GHS95, BIS95].

FlowMark (IBM) is an object-oriented WFMS for OS/2, Windows, and RISC systems. It

supports a heterogeneous client-server environment, and it is based on ObjectStore. It

supports automatic tasks execution, by allowing specifications of software applications that

must be started when a task begins.

Unlike WIDE and many other WFMS, FlowMark is not a stand-alone product: it must be

integrated with external software (such as Lotus Notes) to provide a complete document

management solution. Assignment is based on roles and organization, in a flexible way.

Tasks in FlowMark may be associated to executables on a variety of client platforms, and can

access the WFMS data containers.

Application access to databases is not modeled in FlowMark, which also has limited

mechanism to support exception handling.

FlowMark leaves a lot of freedom to process activities, and its focus is on coordination rather

than control. With respect to WIDE, this allows increased modularity and software reuse, but

it reduces the capability of the WFMS to monitor and supervise task executions, and to offer

an efficient exception handling mechanism.

The InConcert workflow management system by Xerox Xsoft [MS93] is strongly DBMSbased,

like WIDE. The system builds a partly object-oriented layer on top of a commercial

database management systems, like Oracle or Sybase. The aim is not to provide advanced

database mechanisms to the workflow management layer, as in the WIDE case, but rather use

the DBMS support to store views of object attributes and process histories. The system

provides a flexible interface to enable specialisation towards specific application areas.

InConcert is a document-centered product, although it is moving towards transactional

workflows and fully distributed architectures.

The Action Technologies workflow management system [MWFF92] does not use a DBMS

basis, but the Lotus Notes groupware system as its storage layer. The system uses a workflow

paradigm that is based on speech act, i.e. on specific communication patterns between actors

that require the performance of tasks and actors that provide the performance of tasks.

Workflow applications are modeled in so-called business process maps, consisting of

interlinked workflow loops.

The workflow model is very peculiar: the goal is to achieve customer satisfaction rather than

task completion. Customers and performers agree (after some negotiations) on the work to be

done. Again, the flexibility of this model is paid by a steeper learning curve and by a harder

formalization of simple, repetitive processes.

一个示例：海军的招生

其建模示意图：

该例的PDL：

PROCESS "Military enrollment"

FILE milita.pro

DESCRIPTION 'Compulsory enrollment procedure of a military office.`

DECLARATION

CONSTANTS

NONE

VARIABLES

VAR "Physical Test Result" BOOLEAN NULL

VAR "Psychological Test Result" BOOLEAN NULL

VAR "Drafted" BOOLEAN NULL

VAR "Applicant Data" STRING ""

KEYS

KEY "Applicant SSN" INTEGER 0

KEY "Applicant Name" STRING ""

INFOS

FORM "Application"

applica.for

EXPRESSIONS

COND "@[Physical Test Result]" : NULL ENDCOND

COND "@[Psychological Test Result]" : NULL ENDCOND

TASKS

TASK "Get and record data"

ROLE AdministratorOfficer

SERVER Server@Case

USER User@Case

DESCRIPTION 'A new candidate is registered.`

IN

NONE

OUT

FORM "Application"

MANDATORY

ENDTASK

TASK "Physical test"

ROLE Doctor

SERVER Server@Case

USER User@Case

DESCRIPTION 'The candidate is submitted to physical test and the result is registered in the "Application" form.`

IN

FORM "Application"

MANDATORY

OUT

FORM "Application"

MANDATORY

ENDTASK

TASK "Psychological test"

ROLE Psychologist

SERVER Server@Case

USER User@Case

DESCRIPTION 'The applicant is submitted to psychological test and the result is registered in the "Application" form.`

IN

FORM "Application"

MANDATORY

OUT

FORM "Application"

MANDATORY

ENDTASK

TASK "Draft"

ROLE AdministratorOfficer

SERVER Server@Case

USER User@Case

DESCRIPTION 'The candidate is enrolled and the "Application" form is completed.`

IN

FORM "Application"

MANDATORY

OUT

FORM "Application"

MANDATORY

ENDTASK

TASK "Reject"

ROLE Officer

SERVER Server@Case

USER User@Case

ESCRIPTION 'The candidate is refused and the "Application" form

is completed.`

IN

FORM "Application"

MANDATORY

OUT

FORM "Application"

MANDATORY

ENDTASK

ENDDECLARATION

//下面是结构定义部分，即上述各任务间的关系。

TASK "Get and record data"

IF TASK "Get and record data" THEN

TASK "Physical test";

IF TASK "Physical test" THEN

COND "@[Physical Test Result]";

IF COND "@[Physical Test Result]" THEN

TASK "Psychological test";

IF TASK "Psychological test" THEN

COND "@[Psychological Test Result]";

IF COND "@[Psychological Test Result]" THEN

TASK "Draft";

IF (OR (NOT COND "@[Physical Test Result]")

(NOT COND "@[Psychological Test Result]")) THEN

TASK "Reject";

(OR TASK "Draft" TASK "Reject")

END