A university for the world real R © 2009, www.yawlfoundation.org Chapter 2 The Language: Rationale and Fundamentals (Part V) Nick Russell Arthur ter Hofstede.

Slides:



Advertisements
Similar presentations
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification.
Advertisements

UML State chart/machine diagram State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state.
Models of Concurrency Manna, Pnueli.
A university for the world real R © 2009, Chapter 3 Advanced Synchronization Moe Wynn Wil van der Aalst Arthur ter Hofstede.
Based on: Petri Nets and Industrial Applications: A Tutorial
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Software and Systems Engineering Seminar Winter 2011 Domain-specific languages in model-driven software engineering 1 Speaker: Valentin ROBERT.
Activity Diagrams. Recap Activity Diagrams – When to use? – Where? – Nodes – Edges – More to come …. 2.
A university for the world real R © 2009, Chapter 15 The Business Process Execution Language Chun Ouyang Marlon Dumas Petia Wohed.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification.
Chapter 8-3 Markov Random Fields 1. Topics 1. Introduction 1. Undirected Graphical Models 2. Terminology 2. Conditional Independence 3. Factorization.
4 July 2005 overview Traineeship: Mapping of data structures in multiprocessor systems Nick de Koning
1 Programming for Engineers in Python Autumn Lecture 5: Object Oriented Programming.
Web Ontology Language for Service (OWL-S). Introduction OWL-S –OWL-based Web service ontology –a core set of markup language constructs for describing.
DAML-S: Sematic Markup for Web Services Zhou Jiefeng CS595 Nov. 25t.
IBM WebSphere survey Kristian Bisgaard Lassen. University of AarhusIBM WebSphere survey2 Tools  WebSphere Application Server Portal Studio Business Integration.
Data Flow Analysis Compiler Design Nov. 8, 2005.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 6 The Relational Algebra and Relational Calculus.
Object Oriented Databases - Overview
Data Flow Analysis Compiler Design Nov. 8, 2005.
Chapter 10: Architectural Design
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Software Design Processes and Management
Chapter 7 Structuring System Process Requirements
CSC 8310 Programming Languages Meeting 2 September 2/3, 2014.
A university for the world real R © 2009, Chapter 14 EPCs Jan Mendling.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
A university for the world real R © 2009, Chapter 18 Process Configuration Florian Gottschalk Marcello La Rosa.
Chapter 10 Architectural Design
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
Chapter 7 Structuring System Process Requirements
CSE314 Database Systems More SQL: Complex Queries, Triggers, Views, and Schema Modification Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson.
Copyright © 2007, Oracle. All rights reserved. Managing Concurrent Requests.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 21. Review ANALYSIS PHASE (OBJECT ORIENTED DESIGN) Functional Modeling – Use case Diagram Description.
ASP.NET Programming with C# and SQL Server First Edition Chapter 3 Using Functions, Methods, and Control Structures.
Agenda Introduction Overview of White-box testing Basis path testing
CSE314 Database Systems The Relational Algebra and Relational Calculus Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson Ed Slide Set.
Conceptual Modelling – Behaviour
Web Services Flow Language Guoqiang Wang Oct 7, 2002.
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
CONTENTS Processing structures and commands Control structures – Sequence Sequence – Selection Selection – Iteration Iteration Naming conventions – File.
Copyright © Cengage Learning. All rights reserved. 1 Functions and Their Graphs.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
A university for the world real R © 2009, Chapter 9 The Runtime Environment Michael Adams.
6. A PPLICATION MAPPING 6.3 HW/SW partitioning 6.4 Mapping to heterogeneous multi-processors 1 6. Application mapping (part 2)
System Testing Beyond unit testing. 2 System Testing Of the three levels of testing, system level testing is closest to everyday experience We evaluate.
Chapter 11 Activity Diagrams. 2 “Activity diagrams are a technique to describe procedural logic, business processes, and work flows” - M. Fowler An activity.
Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part VI: Design Continuous Activity Diagams State Diagrams.
School of Computer Science, The University of Adelaide© The University of Adelaide, Control Data Flow Graphs An experiment using Design/CPN Sue Tyerman.
Systems Analysis and Design in a Changing World, Fourth Edition
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Formal Semantics of Programming Languages 虞慧群 Topic 2: Operational Semantics.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
 Tata consultancy services Production Planning WORK CENTERS.
State Modeling. Introduction A state model describes the sequences of operations that occur in response to external stimuli. As opposed to what the operations.
Cliquez pour modifier le style du titre Cliquez pour modifier les styles du texte du masque Deuxième niveau Troisième niveau Quatrième niveau Cinquième.
More SQL: Complex Queries, Triggers, Views, and Schema Modification
Chapter 9: Value-Returning Functions
Information Delivery Manuals: Process Mapping
Software Testing.
2. Specification and Modeling
Activity Diagram.
ADONIS®-BPM-Toolkit Simulation Component.
State Machine Diagrams
BPMN - Business Process Modeling Notations
Event-Based Architecture Definition Language
Guide for writing a Software Testing Document
Presentation transcript:

a university for the world real R © 2009, Chapter 2 The Language: Rationale and Fundamentals (Part V) Nick Russell Arthur ter Hofstede

a university for the world real R 2 © 2009, 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 (set theory)

a university for the world real R 3 © 2009, Part V: Formal Syntax of YAWL Abstract Syntax in Set Theory

a university for the world real R 4 © 2009, YAWL specification A YAWL specification is a set of YAWL nets which form a rooted graph structure. Each YAWL net is composed of a series of tasks. Definition 12. (YAWL Specification) A YAWL specification is a tuple = (NetID, ProcessID, TaskID, MITaskID, VarID, ParamID, TNmap, NYmap, VarName, Data-Type, VName, DType, VarType, VNmap, VTmap, VMmap) such that: (* global objects *) NetID is the set of net identifiers (i.e. the top-level process together with all sub processes); ProcessID ∈ NetID is the process identifier (i.e. the top-level net); TaskID is the set of task identifiers in nets; MITaskID ⊆ TaskID is the set of identifiers of multiple instance tasks; VarID is the set of variable identifiers used in nets; ParamID is the set of parameter identifiers used in nets;

a university for the world real R 5 © 2009, YAWL specification (cont’d) Definition 12. (YAWL Specification) (* decomposition *) TNmap: TaskID /  NetID defines the mapping between composite tasks and their corresponding sub-process decompositions which are specified in the form of a YAWL net, such that for all t, TNmap(t) yields the NetID of the correspond- ing YAWL-net, if it exists; NYmap: NetID → YAWLnets, i.e. each net has a complete description of its contents such that for all n ∈ NetID, NYmap(n) is governed by Definition 13 where the notation Tn denotes the set of tasks that appear in a net n. Tasks are not shared between nets hence ∀ m,n ∈ NetID[Tm ∩ Tn ≠ ∅ ⇒ m = n]. TaskID is the set of tasks used in all nets and is defined as TaskID =  n ∈ NetID Tn; In the directed graph defined by G = (NetID,{(x,y) ∈ NetID×NetID | ∃ t ∈ Tx [t ∈ dom(TNmap) ∧ TNmap(t) = y]}) there is a path from ProcessID to any node n ∈ NetID;

a university for the world real R 6 © 2009, YAWL specification (cont’d) Definition 12. (YAWL Specification) (* variables *) VarName is the set of variable names used in all nets; DataType is the set of data types; VName: VarID → VarName identifies the name for a given variable; DType: VarID → DataType identifies the underlying data type for a variable; VarType: VarID → {Net,Task,MI} describes the various variable scopings that are supported. The notation VarID x = {v ∈ VarID | VarType(v) = x} identifies variables of a given type; VNmap: VarID Net → NetID identifies the specific net to which each net variable corresponds, such that dom(VNmap) = VarID Net ; VTmap: VarID Task → TaskID identifies the specific task to which a task variable corresponds, such that dom(VTmap) = VarID Task ; VMmap: VarID MI → MITaskID identifies the specific task to which each multiple instance variable corresponds, such that dom(VMmap) = VarID MI.

a university for the world real R 7 © 2009, YAWL net Definition 13. (YAWL net) A YAWL net is a tuple (nid, C, i, o, T, TA, TC, M, F, Split, Join, Default,< XOR, Rem, Nofi, ArcCond) such that: (* basic control-flow elements *) nid ∈ NetID is the identity of the YAWL net; C is a set of conditions; i ∈ C is the input condition; o ∈ C is the output condition; T is the set of tasks; TA ⊆ T is the set of atomic tasks; TC ⊆ T is the set of composite tasks; TA and TC form a partition over T ; M ⊆ T is the set of multiple instance tasks; F ⊆ (C \ {o}×T ) ∪ (T ×C \ {i}) ∪ (T ×T ) is the flow relation, such that every node in the graph (C ∪ T,F) is on a directed path from i to o;

a university for the world real R 8 © 2009, YAWL net (cont’d) Definition 13. (YAWL net) Split : T /  {AND,XOR,OR} specifies the split behavior of each task; Join : T /  {AND,XOR,OR} specifies the join behavior of each task; Default ⊆ F, Default : dom(Split ► {OR}) → T ∪ C denotes the default arc for each OR-split. If none of the outgoing arc expressions evaluate to true, the de- fault arc indicated by Default(t) is selected, thus ensuring that at least one out- going arc is enabled; < XOR ⊆ {t ∈ T | Split(t) = XOR} × Ƥ ((T ∪ C) × (T ∪ C)) describes the evaluation sequence of outgoing arcs from an XOR-split such that for any (t, V ) ∈ < XOR we write < t XOR = V and V is a strict total order over t = {x ∈ T ∪ C |(t, x) ∈ F}. Link conditions associated with each arc are evaluated in this sequence until the first evaluates to true. If none evaluate to true, the minimum element (which corresponds to the default path and is denoted as ⊥ t ) is selected;

a university for the world real R 9 © 2009, YAWL net (cont’d) Definition 13. (YAWL net) Rem : T /  Ƥ +(T ∪ C\{i,o}) specifies the additional tokens to be removed by emptying a part of the net and tasks that should be canceled as a consequence of an instance of this task completing execution; Nofi: M → N×Ninf ×Ninf ×{dynamic,static} specifies the multiplicity of each task – in particular the lower and upper bound of instances to be created at task initiation, the threshold for continuation indicating how many instances must complete for the thread of control to be passed to subsequent tasks and whether additional instances can be created “on the fly” once the task has commenced; (* conditions on arcs *) ArcCond : F ∩ (dom(Split ► {XOR,OR}) × (T ∪ C)) → BoolExpr identifies the specific condition associated with each branch of an OR or XOR split.

a university for the world real R 10 © 2009, Data Passing Definition 14. (Data passing model) Within the context of a YAWL net nid, there is a data passing model (ParamVar, InPar, OutPar, Accessor, Splitter, Instance, Aggregate) with the following components: (* parameter variable definition *) ParamVar: ParamID → VarID × VarID is a function identifying the source and target variables for a given parameter; (* data passing to/from atomic tasks *) InPar: ParamID × T → Expr is a function identifying the input parameter map- pings to a task at initiation; OutPar: ParamID × T → Expr is a function identifying the output parameter mappings from a task at completion;

a university for the world real R 11 © 2009, Data Passing (cont’d) Definition 14. (Data passing model) (* data passing to/from multiple instance tasks *) Accessor : TM → RecExpr is a function identifying the accessor query for a multiple instance task; Splitter : TM → Expr is a function identifying the splitter query for a multiple instance task; Instance: TM → Expr is a function identifying the instance query for a multiple instance task; Aggregate: TM → RecExpr is a function identifying the aggregate query for a multiple instance task.

a university for the world real R 12 © 2009, Organizational Model Definition 15. (Organizational model) Within the context of a YAWL specification ProcessID, there is an organizational model described by the tuple (UserID, RoleID, CapabilityID, OrgGroupID, PositionID, CapVal, RoleUser, OrgGroupType, GroupType, PositionGroup, OrgStruct, Superior, UserQual, UserPosition) as follows: (* basic definitions *) UserID is the set of all individuals to whom work items can be distributed; RoleID is the set of designated groupings of those users; CapabilityID is the set of qualities that a user may possess that are useful when making work distribution decisions; OrgGroupID is the set of groups within the organization; PositionID is the set of all positions within the organization; CapVal is the set of values that a capability can have;

a university for the world real R 13 © 2009, Organizational Model (cont’d) Definition 15. (Organizational model) (* organizational definition *) RoleUser : RoleID → Ƥ (RoleUser) indicates the set of users in a given role; OrgGroupType = {team,group,department,branch,division,organization} identifies the type of a given organizational group; GroupType: OrgGroupID → OrgGroupType; PositionGroup: PositionID → OrgGroupID indicates which group a position belongs to; OrgStruct: OrgGroupID / → OrgGroupID forms an acyclic intransitive graph with a unique root which identifies a composition hierarchy for groups; Superior: PositionID / → PositionID forms an acyclic intransitive graph which identifies the reporting lines between positions;

a university for the world real R 14 © 2009, Organizational Model (cont’d) Definition 15. (Organizational model) (* user definition *) UserQual: UserID × CapabilityID → CapVal ∪ {Undefined} identifies the capabilities that a user possesses; UserPosition: UserID → Ƥ (PositionID) maps a user to the positions that they hold.

a university for the world real R 15 © 2009, Work Distribution Model Definition 16. (Work distribution model) Within the context of a YAWL net nid, it is possible to describe the manner in which work items are distributed to users for execution. A work distribution model is a tuple (ResourceVarID, Auto, TM, Initiator, DistUser, DistRole, DistVar, OrgDist, CapDist, SameUser, FourEyes, UserSel, UserPriv, UserTaskPriv) as follows: (* work allocation *) ResourceVarID ⊆ VarID is the set of variables which identify resources or roles; Auto ⊆ TA is the set of tasks which execute automatically without user intervention, where TA is the set of atomic tasks; TM ⊆ TA\Auto is the set of atomic tasks that must be allocated to users for execution;

a university for the world real R 16 © 2009, Work Distribution Model (cont’d) Definition 16. (Work distribution model) Initiator: TM → {system,resource} × {system,resource} × {system,resource} indicates who initiates the offer, allocate and commence actions; DistUser: TM / → Ƥ (User) identifies the users to whom a task should potentially be distributed; DistRole: TM / → Ƥ (Role) identifies the roles to whom a task should potentially be distributed; DistVar: TM / → Ƥ (ResourceVarID) identifies a set of variables holding either user or roles to whom a task should potentially be distributed; dom(DistUser), dom(DistRole) and dom(DistVar) form a partition over TM;

a university for the world real R 17 © 2009, Work Distribution Model (cont’d) Definition 16. (Work distribution model) OrgDist: TM /→ OrgExpr identifies the organizational criterion that users that execute the task must satisfy; CapDist: TM /→ CapExpr identifies the capability that users that execute the task must possess; SameUser: TM /→ TM is an irreflexive function that identifies that a task should be executed by one of the same users that undertook another specified task in the same case; FourEyes: TM /→ TM is an irreflexive function that identifies a task that should be executed by a different user to the one(s) that executed another specified task in the same case; UserSel: TM /→ {random, round-robin-time, round-robin-freq, round-robin-exp, shortest-queue} indicates how a specific user who will execute a task should be selected from a group of possible users;

a university for the world real R 18 © 2009, Work Distribution Model Definition 16. (Work distribution model) (* user privilege definition *) UserPriv: UserID → Ƥ (UserAuthKind) indicates the privileges that an individual user possesses, where UserAuthKind = {choose, concurrent, reorder, viewitem, viewgroup, chainedexec, managecase}; UserTaskPriv: UserID × TaskID → Ƥ (UserTaskAuthKind) indicates the privileges that an individual user possesses in relation to a specific task, where UserTaskAuthKind = {suspend, start, reallocate, reallocate state, deallocate, piledexec, delegate, skip}.