+ All Categories
Home > Documents > Chapter 2 The Language: Rationale and Fundamentals (Part III)

Chapter 2 The Language: Rationale and Fundamentals (Part III)

Date post: 04-Feb-2016
Category:
Upload: haru
View: 55 times
Download: 0 times
Share this document with a friend
Description:
Chapter 2 The Language: Rationale and Fundamentals (Part III). Nick Russell Arthur ter Hofstede. Overview. Fundamental theory Introduction to BPM Patterns Control-flow Control-flow specification in YAWL Pattern (cont’d) Data (incl how realised in YAWL) - PowerPoint PPT Presentation
29
a university for the world real R W W L L L Y Y Y A A © 2009, www.yawlfoundation.org Y Y Chapter 2 The Language: Rationale and Fundamentals (Part III) Nick Russell Arthur ter Hofstede
Transcript
Page 1: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

WW LLLYYY AA

© 2009, www.yawlfoundation.org YYY

Chapter 2The Language: Rationale and

Fundamentals(Part III)Nick Russell

Arthur ter Hofstede

Page 2: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

2WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Overview

• Fundamental theory• Introduction to BPM• Patterns

– Control-flow

• Control-flow specification in YAWL• Pattern (cont’d)

– Data (incl how realised in YAWL)– Resources (incl how realised in YAWL)

• Syntax of YAWL (ORM and set theory)• Example: Order fulfillment

Page 3: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

3WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Part III: Intro to YAWL

• What is YAWL?• Rationale• Control-flow concepts• Initial brief overview of data perspective

Page 4: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

4WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

YAWL Overview

• Collaboration between TU/e and QUT• Based on Workflow Patterns Initiative• YAWL: 2002 – newYAWL: 2007• System development

– Open source (currently LGPL)– Governed by YAWL Foundation– Industry collaboration

• first:utility • Intercontinental Hotels Group (- 2007)• GECKO• Knexus Research Corporation / US Naval Research Laboratory

• Main publication– W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language,

Information Systems 30(4):245-275, 2005 Citations: 600+ (Google Scholar); 170+ (Scopus); 140+ (Web of Science)

• URLs:– www.yawlfoundation.org (research)– www.sourceforge.net/projects/yawl (system)

Page 5: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

5WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

YAWL Highlights

• Based on the (old) control-flow and the resource patterns• Extends workflow nets• Formalisation• Sophisticated verification support

– Transition invariants– Reset net analysis

• Sophisticated flexibility support– Exception handling – Dynamic workflow– Declarative workflow

Page 6: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

6WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

YAWL vs Petri/workflow nets

• Petri nets have difficulties capturing:– The General Synchronising Merge– Patterns involving Multiple Instances– Cancellation of a certain part of a process

• For the Control Flow Perspective, YAWL takes some concepts from Petri/Workflow nets and adds constructs for:

– OR-join to deal with General Synchronising Merge– Multiple Instance (MI) tasks– Cancellation regions– “Syntactic Sugar” (various splits/joins, direct connections between

tasks)

Page 7: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

7WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

YAWL notation

Composite task Multiple Instance task

Page 8: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

8WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Multiple Instances Example I(source: [AH05])

register_witnesses

archiveprocess_witness_

statements

[1,10,inf,static]

In between 1 and 10 witness statements are processed, witnessescannot be added after registation of them has finished (Pattern 14).

Page 9: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

9WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

An arbitrary number of witnesses can be processed, furthermore,more witnesses can be incorporated after processgin has startedbut before archiving (Pattern 15).

register_witnesses

archiveprocess_witness_

statements

[1,inf,inf,dynamic]

Multiple Instances Example II(source: [AH05])

Page 10: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

10WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

register_witnesses

archiveprocess_witness_

statements

[1,10,3,static]

In between 1 and 10 witness statements are to be processed;after three statements have been processed, or all that werestarted initially, archiving can start (Pattern 9 extended).

Multiple Instances Example III(source: [AH05])

Page 11: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

11WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example I (source: [AH05])

register

flight

hotel

car

pay

Page 12: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

12WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example II (source: [AH05])

register

flight

hotel

car

pay

Page 13: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

13WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example III

register do_itinerary_segment

pay

register_itinerary_segment

flight

hotel prepare_payment_information

car

Page 14: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

14WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Cancellation in YAWL

• The concept of cancellation region generalises the cancel activity and cancel case patterns

• Syntactically, a cancellation region consists of a number of tasks and places (possibly including implicit ones!) part of the same composite task and attached to a so-called cancellation task (also part of the same composite task).

• Semantically, upon completion of the cancellation task all tokens in the cancellation region (or in decompositions of tasks in that region etc) are removed.

Page 15: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

15WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example IV

register do_itinerary_segment

pay

cancel

booking_in_progress

Page 16: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

16WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example VI(source: [AH05], p. 257)

register

flight

hotel

car

pay

cancel

Page 17: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

17WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example VII(source: [AH05], p. 257)

register

flight

hotel

car

pay

cancel

Page 18: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

18WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

General YAWL Example VIII(source: [AH05], p. 257)

register

flight

hotel

car

decide

cancel

pay

Page 19: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

19WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

YAWL Example with Time(source: [AH05])

send_bill

pay

T

E

T represents a time-out task

What are the disadvantages of using anexternal service for deadline notification?

Page 20: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

20WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

New approach to time

• Tasks can have an associated timer• Timer can be based on variable, hence dynamic• Timing can be

– On enablement– On start

Page 21: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

21WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Exercise

Consider a credit card application process. The process starts when an applicant submits an application (with the proposed amount). Upon receiving an application, a credit clerk checks whether it is complete. If not, the clerk requests additional information and waits until this information is received before proceeding. For a complete application, the clerk performs further checks to validate the applicant’s income and credit history. Different checks are performed depending on whether the requested loan is large (e.g. greater than $500) or small. The validated application is then passed on to a manager to decide whether to accept or reject the application. In the case of acceptance, the applicant is notified of the decision and a credit card is produced and delivered to the applicant. For a rejected application, the applicant is notified of the decision and the process ends. Model this process in YAWL.

(credit: Moe Wynn and Chun Ouyang)

Page 22: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

22WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

A Brief Overview of the Data Perspective in YAWL

• The data patterns (discussed subsequently) were finalized after the initial data perspective for YAWL was developed

• Hence the data perspective in YAWL is not based on a comprehensive analysis of the data perspective

• The data perspective in YAWL relies on XML technology, in particular XML Schema, XPath and XQuery

• Specifying expressions in a correct manner can be non-trivial. Errors in XPath/XQuery expressions are a frequent source of errors

• In order for data to be accessible for a task the data item needs to be passed down the hierarchy

• When discussing the data patterns, the data perspective in YAWL will be explained in more detail

Page 23: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

23WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Native Use of XML

The data inside of YAWL exists as many XML documents

Page 24: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

24WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Native Use of XML #2

The functionality of the YAWL business processing engine uses XML standards internally to perform the actions that one would expect of a Business Process System:

1. Data Validation: XML Schema

2. Transformations: XQuery

3. Decision making: XPath

Page 25: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

25WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Native Use of XML #3:Strong Data Typing

Page 26: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

26WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Native Use of XML #4:Transformations in Data Passing

Page 27: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

27WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Native use of XML #5:System Decisions

Page 28: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

28WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Native Use of XML #6: Generation of XForms

Page 29: Chapter 2 The Language: Rationale and Fundamentals (Part III)

a university for the worldrealR

29WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Sources and References

• [Aalst96] Wil M. P. van der Aalst. Three Good Reasons for Using a Petri-net-based Workflow Management System. In S. Navathe and T. Wakayama, editors, Proceedings of the International Working Conference on Information and Process Integration in Enterprises (IPIC’96), pages 179-201, Cambridge, Massachusetts, November 1996.

• [Aalst97] Wil M.P. van der Aalst. Verification of Workflow Nets. In P. Azéma and G. Balbo, editors, Applications and Theory of Petri Nets 1997, volume 1248 of Lecture Notes in Computer Science, pp 407-426, Springer Verlag, 1997.

• [AH02] Wil M.P. van der Aalst and Kees M. van Hee. Workflow Management: Models, Methods, and Systems. The MIT Press, 2002.

• [AH05] Wil M.P. and der Aalst and Arthur H.M. ter Hofstede. YAWL: Yet Another Workflow Language. Information Systems 30(4):245-275, 2005.

• [JB96] S. Jablonski and C. Bussler. Workflow Management: Modeling Concepts, Architecture and Implementation. International Thomson Computer Press, 1996.

• [BW90] J. Baeten and W.P. Weijland. Process Algebra. Cambridge Tracts in Theoretical Computer Science 18, Cambridge University Press, 1990.

• [Peterson81] J.L.A. Peterson. Petri net theory and the modeling of systems. Prentice Hall, 1981.• [DE95] J. Desel and J. Esparza. Free Choice Petri Nets. Cambridge Tracts in Theoretical Computer Science 40,

Cambridge University Press, 1995.• [HAAR09] A.H.M. ter Hofstede, W.M.P. van der Aalst, M. Adams, and N. Russell (editors). Modern Business

Process Automation: YAWL and Its Support Environment. Springer, 2010.• [WfMC] Workflow Management Coalition - Terminology & Glossary, Document number WFMC-TC-1011, Document

Status 3.0, February 1999. Downloaded from http://www.aiim.org/wfmc/mainframe.htm. (this document contains the quoted definitions)

• [KHA03] B. Kiepuszewski, A.H.M. ter Hofstede and W.M.P. van der Aalst. Fundamentals of Control Flow in Workflows. Acta Informatica 39(3):143-209, 2003.

• [KHB00] B. Kiepuszewski, A.H.M. ter Hofstede, C. Bussler. On Structured Workflow Modelling. Proceedings CAiSE’2000, Lecture Notes in Computer Science 1789, Stockholm, Sweden, June 2000.

• [Kie03] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003.

• www.workflowcourse.com (among others for the animations)


Recommended