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;
12 END 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: pernici@elet.polimi.it
工作流中的信息通常关注：什么时候一个工作任务开始执行，执行任务需要的应用信息，将工作任务分配给代理（
组织模型与过程模型严格分离，通过授权机制连接，即用授权将过程模型中的角色映射到组织模型中的代理。）的原则，工作任务结束后将激活的任务是什么。因此，在业务相关的工作流中，较少关注工作任务本身。工作任务只是不正式地被描述。工作任务间的连接要复杂得多，有些工作任务的执行是相关联的。
下面是一个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,
BIS
95].
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
2万+
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
