190 likes | 346 Views
Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box 513 5600 MB Eindhoven The Netherlands w.m.p.v.d.aalst@tm.tue.nl. Analysis of workflows : Verification, validation, and performance analysis. Wil van der Aalst.
E N D
Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box 513 5600 MB Eindhoven The Netherlands w.m.p.v.d.aalst@tm.tue.nl Analysis of workflows: Verification, validation, and performance analysis. Wil van der Aalst
Queuing models service Basic characteristics: • average number of arrivals per time unit: l (mean arrival rate) • average number that can be handled by one server per time unit: m (mean service rate) • number of servers: c waiting arrivals l c m
Basic relationships: average time between arrivals: 1/l average service time: 1/m occupation rate: r = l/(c*m) average number being served: r = l/m Queuing models (2) l c m W,Lq S,L W (S) = average time in queue (system) Lq (L) = average number in queue (system) • L = Lq + r • S = W + 1/m • Lq = l * W • L = l * S (Little’s formula)
M/M/1 queue • Lq = (l* l)/(m * (m-l)) • L = l/(m-l) = r/(1-r) • W = r/(m-l) • S = 1/(m-l) l 1 m • Assumptions: • time between arrivals and service time follow a negative expontential distribution • 1 server (c = 1) • FIFO Also formulas for M/Er/1, M/G/1, M/M/c, ... !
Exercise 1 resource, average service time of 8 minutes difficult cases 1 resource, average Calculate: • occupation rates, • average waiting time, • average throughput time, • average number in system. service time of 2 6 difficult c21 minutes cases per hour task1a c1 c23 task2 c3 task1b 18 easy cases c22 per hour easy cases 1 resource, average service time of 2.66 minutes • Increase the occupation rate until 90%: • average waiting time, • average throughput time, • average number in system.
Simulation • Random walk through the reachability graph • Computer experiment • pseudo random numbers • random generator • Validation • Statistical aspects • start run • subruns • Animation • Flexible • No proof!
Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box 513 5600 MB Eindhoven The Netherlands w.m.p.v.d.aalst@tm.tue.nl Workflow Management Systems: Functions, architecture, and products. Wil van der Aalst
Focus on "classical" workflow management systems, but ... Four types of "workflow-like" systems: • Information systems with hard-coded workflows (process& organization specific). • Custom-made information systems with generic workflow support (organization specific). • Generic softwarewith embedded workflow functionality (e.g., the workflow components of ERP, CRM, PDM, etc. systems). • Generic softwarefocusing onworkflow functionality (e.g., Staffware, MQSeries Workflow, FLOWer, COSA, Oracle BPEL, Filenet, etc.).
Basic idea workflow management system • Separation of control and execution. control (process logistics) execution (task oriented) application
Interfaces Weak! Demo’s Published in Handbook
server client workflow engine in-basket (worklist) DBMS applications Potential problem
The ACID-properties, known from transaction processing, should hold. • Atomicity(atomic, "everything or nothing", rollback if necessary) • Consistency(a completed task results in a proper state of the system) • Isolation(tasks do not affected each other, even if they are executed in parallel) • Durability(the result of a completed task may not get lost; commit tasks)
Examples of systems • COSA (demo) • Staffware • FLOWer • …
Staffware • Leading workflow management system (typically 25 percent of the global “pure” workflow market). • Staffware PLC is headquartered in Maidenhead UK and has offices in 19 countries. • Focus on performance and reliability rather than functionality (e.g., infinite scalability, fault tolerance, etc.) • In the remainder, we present a small case study that is used to: • introduce the design tool and modeling language of Staffware, • show the management/administrator tools of Staffware, • demonstrate the end-user’s view of Staffware, and • show the need for analysis.
WfMC reference model (1) (2) (3)
checkA pay register checkB reject A small case study: Double Check (DC) • Processing of insurance claims involving registration, two checks, and a payment of rejection • Five tasks: • register (register insurance claim) • checkA (check insurance policy) • checkB (check damage reported) • pay (pay for the damage) • reject (inform customer about rejection) • Registration is followed by two checks which can be handled in parallel. • Each of the checks results in “OK” or “not OK”. • If both are OK, pay otherwise reject. • Three roles: register (for task register), checks (for both checks), and pay/reject (for final tasks).