Development of a Work ow Design Tool for the

Development of a Work ow Design Tool for the Scarabaeus Project Cristoforo Castroianni April 24, 1995

Master's thesis Design Methodology Research Group Section Information Systems Department of Computer Science

Committee: Dr. J.N. Brinkkemper Dr.ir. S. Joosten Dr. P.M. Wognum University of Twente P.O. Box 217 7500 AE Enschede The Netherlands

On the cutting edge of technology, you have made yesterday's impossibilities the commonplace realities of today.

|R. Reagan

Documentation preparation with LaTEX. Cover taken from PC Paintbrush (original by M.C. Escher).

c 1995 by Cristoforo Castroiannni, Enschede, the Netherlands. Copyright All rights reserved. No part of this report may be reproduced in any form or by any means, without the prior written permission of the author.

Abstract Development of a Work ow Design Tool for the Scarabaeus Project

Work ow management and work ow automation have drawn the interest of larger administrative organisations. Work ow bears the promise of integrating oce work, causing short delay times, improved customer service and better knowledge of the logistic parameters of oce work. Experience shows that this promise can be realised, but that the design of work ow systems is a dicult task. Work ow analyst are calling for design heuristics that can help to design work ow systems reliably and eciently. Most work ow tool builders aimed at developing tools that support the implementation of work ows (work ow automation software). Fewer tools were developed speci cally to support the phase preceding the implementation, the analysis and design of the work ow. The Scarabaeus project serves the principal purpose of supporting work ow designers, by developing a prototype work ow design tool that makes use of a knowledge-based system, which contains formalised work ow design knowledge. The work presented here, is the nal report of the method engineering part of the Scarabaeus project. The method engineering part consisted of developing a graphical work ow design editor, with a good conceptual background, that makes use of a knowledge-based system, to support work ow design. Also, general experience was gathered with the development of work ow tools in the work ow laboratory at the University. The results show that it is technically possible to develop a graphical work ow design editor, that makes use of a knowledge-based system. However, in its current state, no evaluation on the tool was possible. Furthermore, making work ow design knowledge operational turned out to be a problem. Therefore, no de nite judgement can be given towards the usefulness of knowledge-based support for work ow design, by means of a graphical work ow design tool, until further research has been performed.

i

ii

Abstract

Samenvatting Ontwikkeling van een Werkstroom Ontwerp Tool voor het Scarabaeus Project

Werkstroom management en werkstroom automatisering hebben de aandacht getrokken van de grotere administratieve organisaties. Werkstroom brengt de belofte met zich mee om administratief werk te integreren, hetgeen leidt tot minder vertraging, verbeterde klantenservice en een betere kennis van de logistieke parameters van administratief werk. Ervaring laat zien dat deze belofte kan worden gerealiseerd, maar dat het ontwerpen van werkstroomsystemen een moeilijke taak is. Werkstroomanalisten roepen om heuristieken die kunnen helpen om werkstroomsystemen betrouwbaar en ecient te kunnen ontwerpen. Tot op heden hebben de meeste bouwers van werkstroom tools, zich gericht op het ontwikkelen van tools ter ondersteuning van werkstroom implementatie (werkstroom automatiseringssoftware). Minder tools zijn speciaal ontwikkeld ter ondersteuning van de fase die voorgaat aan implementatie, namelijk de analyse en het ontwerp van de werkstroom. Het Scarabaeus project dient het doel om werstroom ontwerpers te ondersteunen, door een prototype werkstroom ontwerp tool te ontwikkelen, die gebruik maakt van een kennissysteem, dat geformaliseerde werkstroom ontwerp kennis bevat. Het hier gepresenteerde werk, is het afstudeerverslag van het method engineering deel van het Scarabaeus project. Het method engineering deel bestond uit het ontwikkelen van een gra sch werkstroom ontwerp editor, met een goede conceptuele basis, die gebruik maakt van een kennissysteem, om werkstroom ontwerp te ondersteunen. Ook is er algemene kennis opgedaan met het ontwikkelen van werkstroom tools in het werkstroom laboratorium van de Universiteit. De resultaten tonen aan dat het technisch mogelijk is om een gra sch werkstroom ontwerp editor te ontwikkelen, gebruik makend van een kennissysteem. Maar in zijn huidige toestand, was het niet mogelijk om het tool te evalueren. Bovendien was het operationeel maken van werkstroom ontwerp kennis problematisch. Het is dus niet mogelijk om een de nitief oordeel te geven over de bruikbaarheid van een kennissysteem ter ondersteuning van werkstroom ontwerp, totdat er verder onderzoek wordt verricht.

iii

iv

Samenvatting

Preface This report is the result of a master's assignment performed at the University of Twente, within the design methodology research group belonging to the section Information Systems of the Department of Computer Science. Hoping that my work will be of interest for further research, I would like to thank some people for their support:

My two graduation committee members, Stef Joosten and Nel Wognum, who inspired, mo

tivated, and directed me on my way. My graduation teacher Sjaak Brinkkemper, who did not have much time. The Scarabaeus project members: Art van de Belt and Arjen van Bekkum, for their cooperation, their motivation, and everything else they tried to make the project successful. The fellow graduation students: Bartho, Benno, Pascal, Peter, Peter-Paul, Raoul, and the other ones. Members of the university: Frank Harmsen, George Steenbekke, Lynn Packwood, and Frank van Raalte, for helping me with my silly questions. My parents, and my neighbours, who every now and then showed their interest, even though they did not always understand what I was doing. And, last but not least, you, for reading my report.

Thanks

Cristoforo Castroianni Enschede, April 24, 1995

v

vi

Preface

Contents Abstract Samenvatting Preface 1 Introduction 1.1 1.2 1.3 1.4

Purpose of the report Intended audience Structure of the report Terminology

i iii v 1 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

2 Research approach

2.1 Introduction 2.2 The Scarabaeus project 2.2.1 Name 2.2.2 Research problem 2.2.3 Involvement and tasks 2.2.4 Goals 2.3 The method engineering part 2.3.1 Introduction 2.3.2 Research questions 2.3.3 Approach 2.3.4 Justi cation 2.3.5 Plan

3

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

3 Work ow and work ow design 3.1 3.2 3.3 3.4 3.5

1 1 1 2

Introduction Work ow terminology Work ow concepts Work ow design Architecture 3.5.1 Architecture of a work ow support system 3.5.2 Architecture work ow design tool 3.6 Related topics 3.6.1 Groupware and CSCW 3.6.2 Document information systems 3.6.3 Business Process Redesign 3.6.4 Logistics

11

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

vii

3 3 3 3 4 4 5 5 5 5 7 9

11 11 13 15 17 17 18 18 18 19 19 19

Contents

viii

4 Conceptual analysis

4.1 Introduction 4.2 Task analysis 4.2.1 The work ow design task 4.2.2 Tasks supported by the editor 4.2.3 Tasks supported by the knowledge-based system 4.3 Conceptual model 4.3.1 Perspectives on work ow 4.3.2 Control perspective 4.3.3 Organisational perspective 4.3.4 Data perspective 4.3.5 Data ow perspective 4.3.6 Problem-solving perspective

21

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

5 Requirements analysis

5.1 Introduction 5.2 Work ow design tool requirements 5.3 Tool realisation alternatives 5.3.1 Work ow related tools 5.3.2 CASE tools 5.3.3 Meta-CASE tools 5.3.4 Programming environment 5.3.5 Overview of realisation alternatives 5.4 Conclusions 5.4.1 Realisation choice 5.4.2 Overcoming drawbacks

31

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

6 User interface theory 6.1 6.2 6.3 6.4 6.5

Introduction User friendliness Dialog styles Types of user interfaces Conclusions

21 21 21 22 22 24 24 25 28 28 29 30 31 31 32 32 33 34 34 35 35 35 35

37

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

7 Functional design

7.1 Introduction 7.2 Tool composition 7.2.1 Diagramming techniques 7.2.2 Editor speci c concepts 7.3 Tool functionality 7.3.1 Internal and external work ow data 7.3.2 Graphical functionality 7.3.3 Diagram hierarchy 7.3.4 Knowledge-based system 7.3.5 General functionality 7.4 Data structures 7.4.1 Abstract data types 7.4.2 Internal work ow data 7.4.3 User interface 7.5 Process decomposition 7.6 Interaction between user and tool 7.7 Work ow types and functions 7.7.1 List operations 7.7.2 Work ow operations

37 37 38 40 40

41

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

41 41 41 42 43 43 44 44 44 45 45 45 46 46 46 49 51 53 54

Contents

ix

8 Technical design

8.1 Introduction 8.2 Relations of work ow data 8.3 Internal work ow data 8.3.1 List related classes 8.3.2 Work ow related classes 8.3.3 Rules 8.4 External work ow data 8.4.1 Methods to achieve persistence 8.4.2 Extended BNF 8.4.3 Relations between external and internal work ow data 8.4.4 Compiler generator tools 8.5 User interface 8.5.1 Layout aspects 8.5.2 Screens 8.5.3 Relations between graphs and internal work ow data 8.6 Knowledge-based system interface 8.6.1 Interface alternatives 8.6.2 Interface choice 8.7 Pseudo-code 8.7.1 List related 8.7.2 Work ow related 8.8 Implementation issues 8.8.1 Hard- and software requirements 8.8.2 Compiler generator tools

57

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

9 Scarabaeus tool evaluation 9.1 9.2 9.3 9.4

Introduction Current situation of the work ow design tool Work to be done Evaluation plan 9.4.1 Veri cation and validation 9.4.2 Requirements veri cation 9.4.3 Design veri cation 9.4.4 Code veri cation 9.4.5 Validation

77

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

10 Conclusions

10.1 Introduction 10.2 Research results 10.3 Project evaluation 10.3.1 Scarabaeus project 10.3.2 Work ow design 10.4 Recommendations

77 77 79 80 80 80 81 81 81

83

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

A Investigation into existing tools A.1 Introduction A.2 Tools A.2.1 Work ow tools A.2.2 BPR tools

57 57 57 58 58 61 61 61 62 65 66 66 67 67 69 69 69 70 71 71 73 75 75 75

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

83 83 84 84 85 86

87 87 87 87 93

Contents

x

B Scarabaeus products

B.1 Introduction B.2 Products B.2.1 Documentation B.2.2 Software

95

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Bibliography Index

95 95 95 95

97 101

List of gures 3.1 3.2 3.3 3.4 3.5

ER model of the work ow concepts Tasks in the design of a work ow Generic architecture for a work ow support system Architecture of the work ow design tool Three levels of restructuring

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Notation of Task Structure Diagrams Tasks in work ow design Tasks performed by experts to improve a work ow Notation of Entity-Relationship diagrams Relations between the perspectives on work ow Relations between control related concepts Relations between organisation related concepts Relations between data related concepts Relations between data ow related concepts Relations between the problem-solving concepts

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20

Architecture of the work ow design tool Editor transfer chart Extended conceptual model Notation of data ow diagrams DFD: Context diagram DFD: Constituting parts of the tool DFD: Importing work ow data DFD: Exporting work ow data DFD: User interface Notation of state transition diagrams STD: Tool startup and quit STD: Diagram operations STD: Knowledge-based system STD: Syntax errors STD: Loading and saving STD: Activity operations STD: Trigger operations Notation of signature graphs Signature graph of list part Signature graph of work ow part

8.1 8.2 8.3 8.4

Syntax and semantics of work ow data Example screen of the editor Screens of the work ow design tool Creating a compiler with LEX and YACC

: : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

xi

: : : : : : : : : : : : : : : : : : : : : : :

15 16 17 18 20 21 22 23 24 25 26 28 29 29 30 42 42 43 47 47 48 48 48 49 49 50 50 51 51 52 52 53 53 54 56 58 68 68 76

xii

List of gures

List of tables 2.1 Relations between subordinate research questions and tasks 2.2 Dierences between functional and technical design 2.3 Relations between tasks, phases, and report structure

: : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

5.1 Comparison of realisation possibilities 8.1 8.2 8.3 8.4 8.5 8.6

: : : : : : : : : : : : : : : : : : : : : : : : :

EBNF conventions Correspondence between external and internal work ow data Trigger model concepts and symbols Menus of the tool Correspondence between graphs and internal work ow data Pseudo code keywords and meaning

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

9.1 Overview of current implementation situation B.1 Overview of Scarabaeus software

: : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : :

7 8 9 35 62 66 67 69 69 71

: : : : : : : : : : : : : : : : : : : : :

78

: : : : : : : : : : : : : : : : : : : : : : : : : : : :

96

xiii

xiv

List of tables

Chapter 1

Introduction 1.1 Purpose of the report Until now, most work ow tool builders aimed at developing tools that support the implementation of work ows (work ow automation software). Fewer tools were developed speci cally to support the phase preceding the implementation, the analysis and design of the work ow. The purpose of this report is to describe the development of a tool that must support the design of work ows. There must be made use of a knowledge-based system. Because this is a rather new area of research, the study has an experimental character.

1.2 Intended audience This report is a master's thesis, so this report is rstly directed to the teachers / researchers of the university. A new work ow design tool is described in this report, so this report is secondly directed to these (administrative) organisations who are involved with work ows. This report concerns the development of a new work ow design tool, so thirdly this report is directed to work ow tool developers (also organisations participating in the project). Finally, this report contains general work ow design `knowledge', and can therefore be useful to anyone with interest in work ow.

1.3 Structure of the report The report starts with a general part (chapters 1 to 3). The general part is followed by an analysis part (chapters 4 and 5). The following part describes the design of the editor, including theory on user interfaces (chapters 6 to 8). The report is terminated by a tool evaluation (chapter 9) and the conclusions (chapter 10). The contents of each chapter is described brie y below. 1. Introduction. This chapter. 2. Research approach. This chapter gives an overview of the project and a detailed description of the research approach chosen for the method engineering task. 1

1. Introduction

2

3. Work ow and work ow design. This chapter gives an introduction to the theory of work ow and work ow design. The notion 'work ow' and the elements constituting a work ow are de ned and put into context. 4. Conceptual analysis. This chapter summarises the results of empirical research into the design of work ows in practice. The concepts necessary to represent work ows are described. 5. Requirements analysis. This chapter discusses the necessity to develop a new work ow tool, supported by a knowledge-based system. Alternatives for realisation are given, and a choice is made. 6. User interface theory. This chapter gives an introduction to user interfaces. It describes user friendliness, dialog styles, and types of user interfaces. 7. Functional design. This chapter described the functional aspects of the editor. The functionalities of the editor are discussed. The constituting parts of the editor are looked at. The interaction of the editor with the tool is discused. And types and functions of the editor are discussed. 8. Technical design. This chapter described the technical aspects of the editor. The constituting parts of the editor are discussed in detail, to be able to implement them. Implementation issues are discussed. 9. Evaluation. This chapter describes the current situation of the work ow editor, work that has to be done, and an evaluation plan. 10. Conclusions. This chapter describes the conclusions of the research and recommendations for further research.

1.4 Terminology The purpose of this section is to introduce general terminology that is considered familiar in the rest of the report. Other terminology is de ned when used for the rst time.

Dialogue exchange of questions and answers between a computer system and a user. Interface coupling with an other system(part). Knowledge-based system (KBS) is a computer programme in which the best possible sep-

aration is made between problem speci c knowledge and problem independent knowledge.

Modelling technique is a modelling procedure and a corresponding notation to carry out a

certain type of modelling activity. Technique provides the description of the manner in which, and the notation with which a part of information system development must take place. Tool a possible automated means to carry out a part of an information system development process. Work ow Design the process of developing a work ow model. Work ow Model the product that results from the design process.

Chapter 2

Research approach 2.1 Introduction In this chapter the research approach is described. The research done was part of a larger project, the Scarabaeus project. First a global overview of this project is given. The name, problem, involvements and goals of the project are described. The second part of the chapter is focussed on the part of the project that is described in this report. It described the research questions and the approach chosen to answer them.

2.2 The Scarabaeus project 2.2.1 Name The title of the project is `Scarabaeus'. [Merriam-Webster, 1963] gives the following description: scar.a.bae.us s_ kar-*-'be{*s 'be{.i- n or scar.a.bae.us.es or scar.a.baei [L] pl 1: a large black or nearly black dung beetle (Scarabaeus sacer) 2: a stone or faience beetle used in ancient Egypt as a talisman, ornament, and a symbol of the resurrection. The title has no deeper meaning related to the project.

2.2.2 Research problem Work ow management and work ow automation are an area of CSCW (Computer Supported Cooperative Work) that has attracted the interest of larger administrative organisations. Work ow bears the promise of integrating oce work, achieving short delay times, improved customer service and better knowledge of the logistic parameters of oce work. Experience with work ow systems shows that the promise can be realised, but this is usually a dicult task [Joosten et al., 1994a]. For the actual support of work ow management, several dozens of tools are available. Now, work ow analysts are calling for design heuristics that can help to design work ow systems reliably and eectively. So what is needed is a tool that supports the analyst in the phase preceding the actual implementation, i.e. a work ow design tool. This tool should consist of a graphical editor supported by a knowledge-based system that contains work ow design knowledge. The description of the problem leads to the following principal research questions: 3

2. Research approach

4

Which design heuristics are used in work ow design? How is work ow design knowledge best represented for the purpose of building a knowledge

based system that discloses this knowledge? Is it possible to make formalised work ow design knowledge operational in a work ow design tool?

2.2.3 Involvement and tasks In the project a number of dierent roles have been de ned. The actual research has been performed by three graduation students.

an empirical researcher to elicit and analyse the knowledge of work ow design experts. This

role was ful lled by Arjen van Bekkum, and is described in [van Bekkum, 1995]. a knowledge engineer to model and formalise the knowledge obtained from previous projects, course material and the results of the empirical researcher, and to design and build the knowledge-based system. This role was ful lled by Art van de Belt and is described in [van de Belt, 1995]. a method engineer to design and build the work ow design tool that uses the knowledgebased system. This part was ful lled by Cristoforo Castroianni and is described in this thesis.

The tasks that have been performed by them relate to the three main research questions. A small number of experts has been involved, who have been questioned thoroughly by the empirical researcher. Experts from the organisations DCE, Pallas Athena, Bull, and Data General have been involved. The research has been coordinated by two project leaders, Nel Wognum and Stef Joosten.

2.2.4 Goals By the end of the project, the following results must have been produced:

A report on the acquisition of design knowledge from work ow design experts A knowledge-based system that contains the formalised knowledge of work ow design ac

quired from previous projects, a work ow design course, and work ow designers in practice A prototype work ow design tool that makes use of the knowledge-based system

The goals of the work ow design tool are:

Support the design of eective and ecient work ows Ease adaptation of a work ow Allow work ow designers to explore and evaluate several alternatives in a limited period of

time before selecting an alternative to pursue Help less experienced work ow designers to maintain the work ow

2.3 The method engineering part

5

2.3 The method engineering part 2.3.1 Introduction In this report the results of the method engineering part of the project are described. The goal of this part is to develop a graphical work ow design editor that makes use of a knowledge-based system containing knowledge on work ow design. The emphasis in this report is on the development of a graphical work ow design editor supported by a knowledge-based system. Used work ow knowledge will only be described to be able to use it in the editor. For an extensive justi cation of the work ow knowledge see [van Bekkum, 1995]. The justi cation of the representation of the knowledge for use in a knowledge-based system can be found in [van de Belt, 1995].

2.3.2 Research questions The principal research question for the method engineering part of the project is: Is it possible to make formalised work ow design knowledge operational in a work ow design tool?

This question is re ned into the following list: 1. What is work ow design knowledge? 2. Do existing work ow or related tools support work ow design, taking into account the Scarabaeus requirements? 3. What functionality should a work ow tool oer with regard to work ow design? 4. How should a work ow design tool interface with the user? 5. How should a work ow design tool interface with a knowledge-based system? 6. Does formalised work ow design knowledge, used in a knowledge-based system, contribute to a work ow design tool?

2.3.3 Approach In the design of a graphical work ow design editor and in answering the above stated research questions the following tasks are distinguished:

Study research area

First the research area is studied to get an idea of what we are talking about and to collect information that can be used in the rest of the research. Topics of interest are: work ow and work ow design, interfacing, techniques and methods, and related topics. This task does not belong to a speci c phase, but the results are used throughout the research.


6

Conceptual analysis (of work ow design in practice)

This is a task of the empirical researcher, but the results are important for the development of the work ow design tool. The tool as a whole must support the design of work ows. Part of this support is provided by the editor and another part is provided by the knowledge-based system. During the analysis of work ow design in practice, the process of work ow design must be decomposed to the level at which tasks can be uniformly assigned to either the editor or the knowledge-based system. The decomposition is denoted using task structure diagrams (TSDs). Together with the empirical researcher and the knowledge engineer, a model of work ow design concepts has to be developed. For this purpose the entity-relationship data modelling technique is used, to make a model of work ow design.

Analyse existing tools and choose alternative

To be able to decide what tool(s) are needed to realise the graphical work ow design tool, a list of requirements must be made. After that, four alternatives to realise the tool have to be analysed:

Work ow/BPR tools, CASE tools, Meta-CASE tools, and programming environment

Taking the requirements into account, the best alternative will be chosen. Finally this choice has to be re ned.

Design graphical work ow design editor

Based on the work ow design conceptual model a graphical work ow design editor is designed. A distinction is made in functional and technical design. Subtasks that are distinguished are:

Design an internal data representation. Design an external data representation. Design import/export facilities. Design operations on work ow data. Design a user interface.

Techniques that will be used for the functional design are:

editor transfer charts. data ow diagrams (DFDs). state transition diagrams (STDs). and signature graphs.

In the technical design the Extended Backus Naur Form (EBNF), and pseudo code will be used.

Design knowledge-based system interface

Together with the knowledge engineer, an interface between the editor and the knowledgebased system has to be developed. Three alternatives (indirect, semi-direct, and direct interaction) will be analysed. Taking the requirements into account, the best alternative is chosen.

2.3 The method engineering part

7

Questions Tasks 1p 2p 3p p 4 p 5 p 6 Study research area p p p Conceptual analysis p p p p Analyse existing tools p p Design editor p Design KBS interface p p Implement editor p p Implement KBS interface p Evaluate tool Table 2.1: Relations between subordinate research questions and tasks

Implement graphical work ow design editor

The graphical work ow design editor has to be implemented, taking into account that it should be platform independent. Platforms that will be supported are: MS-Dos/MSWindows and Unix. The main tools that will be used to realise the graphical work ow design tool are: a C++ compiler, a User interface toolkit, and compiler generator tools.

Implement knowledge-based system interface

Together with the knowledge engineer, the interface with the knowledge-based system has to be implemented.

Evaluate work ow design tool

The evaluation of the new work ow design tool consists of an overview of work that has been done, and an overview of work to be done including priorities. Furthermore, a plan to evaluate the tool will be made.

The relation between the subordinate research questions and the tasks to be performed, is given in table 2.1.

2.3.4 Justi cation Conceptual model and ERD

All modeling techniques make use of concepts, relationships between those concepts and rules that must hold for these concepts and relationships. These concepts, relationships and rules can be modeled using a data modeling technique. The resulting model is called method data model or meta model [Brinkkemper, 1993]. Lay-out aspects of modeling techniques are not incorporated in meta-models: shape, size, position, fonts, etc. are ignored. A data modelling technique that is often used is entity-relationship (ER) [Batini et al., 1992].

Techniques used

For which purpose techniques are used is explained below: entity-relationship (see above). task structure diagrams [Bots and Sol, 1987], are used because the process of work ow design must be decomposed to the level at which tasks (and products) can be uniformly assigned to either the editor or the knowledge-based system.


8 Functional design WHAT should the system do functionality architecture focus on design user is responsible

Technical design HOW to realise the 'what' means to realise the functionalities equipment focus on implementation programmer is responsible

Table 2.2: Dierences between functional and technical design

editor transfer charts, are used because the tool will have to support several dia

gramming techniques. Switching from one diagramming technique to another, corresponds to an event that causes a state change. Using these charts makes it possible to model, which switchings are possible between the diagramming techniques [Brinkkemper, 1993]. data ow diagrams, are used because a system consists of processes that use data. In order to model the processes and how data ows, DFDs are used [Yourdon, 1989]. state transition diagrams [Yourdon, 1989], are used because it is needed to know how the interaction between the user and the tool will be. The tool can nd itself in several states. An operation performed by the user causes zero or more state changes. According to [Shneiderman, 1992], these diagrams are helpful during design, for instruction, and as a predictor of learning time, and errors. signature graphs, are used because it is needed to know of which types, work ow data consist, and which operations are allowed, and how these operations use the types [MacLennan, 1990]. ebnf, is used because the syntax of external work ow data can be described that way. This syntax is used by a compiler generator tool, to import work ow data [Aho et al., 1986]. pseudo code, is used because in that way it is possible to make detailed programs speci cations.

Functional and technical design

The need for a functional design as well as technical design, can be understood looking at dierences between them. Some dierences of functional and technical design [Eilers, 1987] are shown in table 2.2.

MS-Dos/MS-Windows and Unix platforms

Looking at [Joosten and Brinkkemper, 1995], in the WA-12 project [Joosten et al., 1994a] it appeared that, of the 12 participating organisations 8 use MS-Dos/MS-Windows, 6 use Unix (of which 3 use also MS-Dos/MS-Windows). In short, it appeared that 11 of 12 participating organisations in the WA-12 project use MS-Dos/MS-Windows and/or Unix. So the choice for the MS-Dos/MS-Windows and Unix platform for realising a work ow design tool is reasonable.

Evaluate work ow design tool

Everyone who has ever been associated with software projects, realises how dicult it has always been to exactly match the developed product to the user's needs and how software 'bugs' seem to surface at the worst possible times. Software development is de nitely an inexact process. So software evaluation is absolutely necessary [Lewis, 1992]. It is performed in order to improve the quality and reliability of the software, and to assure that the delivered product satis es the user's operational needs.

2.3 The method engineering part Tasks Study research area Conceptual analysis Analyse existing tools Design editor Design KBS interface Implement editor Implement KBS interface Evaluate tool

9

Phases 1 2 3 4 5 2, 3, 6 3, 4 5, A 7 8 7 8 9 9 9

Table 2.3: Relations between tasks, phases, and report structure

2.3.5 Plan The tasks to be performed are phased according to the traditional system development methodology (SDM) [Eilers, 1987]. Where needed, the phases are adapted to suit this project. These development phases (development life cycle) are quite standard, and therefore they are also described in other literature 1 , for example [Hawryszkiewycz, 1991], [van Vliet, 1993], and [Lewis, 1992]. 1. De nition study. In this phase: the problem (goals, bounds) is de ned, data on the current situation is collected and analysed, objectives and requirements are de ned, possible solutions are de ned, and solutions are evaluated and a selection is made. 2. Functional design. In this phase: all functions of the system are described, the system is divided in subsystems and processes, input and output is described, interaction is described, and the data structure is described. This phase furnishes 'what' the system should do. 3. Technical design. In this phase: all input and output is described, the storage structure is described, program speci cations are made, and o the shelf software is speci ed. This phase furnishes 'how' the 'what' is realised. 4. Implementation. In this phase: programs are written, compiled and adjusted, test data is made, and the programs are tested separately. Documentation is written. 5. Testing. In this phase: a test plan is made, the system is tested, and acceptation testing is performed. Documentation is written. Because of the experimental character of the project and the fact that there exists no previous experience designing and building a similar tool, a prototyping approach is desired. In table 2.3 the relation between the tasks to be performed, the phases, and the report structure, is given. A cell in the table contains a reference to a chapter. The following means are available: 1

Some times dierent names are used for the phases.


10

Information sources

Literature, World Wide Web, newsgroups, a literature guide [Joosten et al., 1994b], the Inspec data base, and experts participating in the project.

Hardware

Personal computers running MS-Dos/MS-Windows, and Sun machines running Unix.

Software

MS-Dos/MS-Windows, Unix, C(++) compilers, Yacc and Lex, LaTeX, ABC owcharter, Coreldraw, etc.

Chapter 3

Work ow and work ow design 3.1 Introduction This chapter contains an introduction to the eld of work ow and work ow design. It is meant to describe the context of the problem. First, some de nitions of the notion 'work ow' and other work ow terminology are given followed by a description of the basic work ow concepts. Then the basis of work ow design is described. The chapter is concluded with a description of topics related to work ow and work ow design.

3.2 Work ow terminology In literature, a lot of dierent de nitions for the notion 'work ow' are used. Some of these de nitions are listed below. De nitions originally in Dutch have been translated into English.

Work ow concerns the automated recording, routing, processing and management of all

objects (data, text, voice, documents, electronic forms), to realise an added value in oce processes [Wasser, 1992]. Work ow enables users to draw up a script, in which the business process (as a set of procedures/tasks) is modelled. This script is leading for the course of the process. For that purpose, the system can access and send the necessary (internal and external) information, give instructions to the users (employees in the project) and follow the planning, coordination and settlement of the work between employees [Novius Adviesgroep voor Informatie & Organisatie, 1993]. A work ow is the order in which steps have to be performed to achieve a result. This order can be serial, parallel and/or conditional. A step in a work ow is a set of actions that has to be performed by a person or a group of persons to produce an output [van Duin, 1993]. By a work ow we mean all processing an object has to go through between entering and leaving the organisation [Gielkens, 1992]. Work ow is the process by which objects are routed to a list of recipients [Identitech, 1993]. A work ow is a concrete implementation of a work process. A work process is what the organisation does in order to, starting at the business stimuli (events), end at the response (products) [Overbeek et al., 1994]. 11

3. Work ow and work ow design

12

A work ow is a system whose elements are activities, related to one another by a trigger relation and triggered by external events, which represents a business process starting with a commitment and ending with the termination of that commitment [Joosten, 1994a].

The de nitions of the notion work ow are given from dierent scopes and dierent points of view. The de nitions mentioned rst associate work ow with automation. The other de nitions leave aside if automation is involved. General to all de nitions is that steps are executed in a particular order. The de nition of work ow we use, is the de nition of [Joosten, 1994a]. This is a very general de nition, that leaves aside if automation is involved. Three types of work ow environments can be distinguished [Pallas Athena, 1993, Joosten et al., 1994a]:

Ad-hoc work ow.

This type of work ow is often encountered in environments where a lot of ad-hoc work or work on low-frequency basis is done. Processes are often speci ed by the end user. Little or no attention is paid to eciency, eectiveness, etc. The processes are often informal. Examples are review processes and processes in which a document is created. Characteristic is that each case is dierent and that there are few or no rules. Structured work ow. This type of work ow is encountered in administrative environments where processes are well-de ned. There are many cases with few or no exceptions. The cases per process are similar. Several employees, often entire departments, are available to handle a particular type of process. An example of a structured environment is the settlement of simple damages, for example a car window damage and the processing of account mutations. Flexible structured work ow. This type of work ow supports the work processes that are well-de ned and also are handled frequently, but where exceptions exist. The exceptions consist of skipping steps, re-processing steps, processing extra information that sometimes comes in at a late stage, etc. Each case in a process is dierent, but similar to other cases. An example of a exible structured environment is the claim settlement for car damage, when matters as injury, several parties, police reports and expertise reports play a role.

Because this project is (as far as we know from literature and empirical research) the rst that copes with knowledge-based supported design of work ows, we only take into consideration the simplest case, being structured work ows. In a later stage, exible structured work ows might be regarded. It is of little use developing a tool for analysing and improving ad-hoc work ows, because they are informal and often change. Another division of work ows used in practice in the one in task oriented and route oriented work ows. In a route oriented work ow, the routing of objects through the organisation is most important. A work ow is considered a route through the organisation followed by a document, folder or another unit of data. A task oriented work ow is primarily aimed at the activities. The routing of information is a derivative of the activities and is not as important as is the case in the route oriented work ow. Because the support of work ows is often aimed at realising a greater

exibility, the task oriented approach is often preferred. If used in literature, the notion 'work ow' is mostly used together with 'management', 'automation' or 'system'. Work ow management is the control of the (dynamic) aspects of the administrative business processes in an organisation. A distinction can be made between the logistic and the procedural aspects. The logistic aspects concern the way information is routed within the organisation. The procedural aspects concern the performance of tasks, in particular the way in which they relate to

3.3 Work ow concepts

13

each other and the authorisations that play a role in the handling of these tasks (task management) [Pallas Athena, 1993]. A work ow system contains a work ow, all actors and all structures and the means involved in that work ow. This notion of work ow system does not refer to the technology alone, but includes all related elements [Joosten, 1994a]. Work ow software automates administrative processes in such a way, that the completion of a particular task in the process by a particular person has the result that one or more tasks following this task are oered to one or more persons in the process (the procedural aspect). The information needed for these tasks (documents, folders, etc.) are routed automatically (the logistic process). This is known as work ow automation [Pallas Athena, 1993]. Work ow management as described above is used for a long time already, but the introduction of work ow automation increases the possibility for a better eciency, eectiveness and service level in administrative environments.

3.3 Work ow concepts The previous section handled some terminology on work ows. In this section we take a closer look at work ows. An empirical study into experiences with work ow management [Joosten et al., 1994a] showed that triggers are an important notion in describing work ow systems, relating activities to one another that are performed by people and/or machines. If activities, actors and triggers are so important, the analysis and design of work ow systems should take these notions as a starting point [Joosten, 1994a]. The concepts in this section are built using the following basic notions (meanings taken from [Merriam-Webster, 1963]).

act a thing done event something that happens; something that occurs object something that is capable of being seen, touched, or otherwise sensed The notion 'work ow' can be divided into two parts: 'work' and ' ow'. The concepts and their relations are shown in gure 3.1. The symbols used in this gure are explained in gure 4.4. The cardinalities are not shown. First, the 'work part' is described. The work in a work ow is made up of activities.

De nition 3.1 (activity) An activity is a set of acts that are performed under the responsibility of one actor playing a speci c role.

In this de nition, the notions responsibility, actor and role need further explanation. Besides the performing of activities, the de nition emphasises the responsibility for an activity. The de nition allows an activity to be performed by several actors, as long as one actor (in a speci c role) is responsible. For example, sending out a letter may involve secretaries, delivery services, etc., but is considered an activity when those acts are performed under responsibility of the sender. Whenever the distinction between performance and responsibility is relevant, but not clear from the context, the phrases responsible actor or performing actor are used. The distinction

14


between performing and responsible actors appears to be important for the analysis of work ow systems [Joosten, 1994a]. An actor can be either a person, a group of persons, or a machine. It is possible to assign an actor directly to an activity, but this is pretty in exible. When people change their status, their assignments to activities have to be revised in order to see whether they are still valid or not. For example, actors might change the group they are working for. To overcome the drawbacks stemming from this static type of assignment, roles are introduced as an intermediate step between activities and actors [Jablonski, 1994].

De nition 3.2 (role) A role is a set of capabilities that speci es when an actor is quali ed to be assigned to an activity.

The assignment to an activity can relate to the responsibility for the activity and/or to the performing of the activity. A role is de ned for every activity. Only one role is responsible for an activity, but there may be several performing roles. A role can be played by several actors and an actor can play more than one role. In a speci c scenario for example, the activity 'type letter' has to be performed by a role 'secretary'. All actors currently able to play this role are permitted to perform the activity. The responsible role for this activity might be 'sales manager'. In case a person quali ed as secretary leaves the company, the work ow descriptions referring to the 'secretary' role do not have to be changed, because other persons are also able to play the role [Jablonski, 1994]. The reports-to relationship determines a manager-subordinate relation for roles. An event occurs as the result of performing an activity. In turn, activities are performed as a result of the occurrence of events. This behaviour is called triggering, and represents the ' ow part' of the notion work ow.

De nition 3.3 (trigger) An event e triggers an activity a if the occurrence of e causes a to be performed.

An activity is triggered by an event and may generate other triggers, so that other activities are activated. The word 'trigger' is also used as a noun. A distinction is made between external triggers and internal triggers, dependent on if the trigger occurs within or without the boundary of the system.

De nition 3.4 (trigger) A trigger is the object that carries a triggering event. An object can have any physical form, for example a telephone call, a letter, a note, a form, an electronic message. Objects may have information content as well. For example, a damage claim form can carry the event of submitting a damage claim.

De nition 3.5 (work ow) A work ow is a system whose elements are activities, related to one another by a trigger relation and triggered by external events, which represents a business process starting with a commitment and ending with the termination of that commitment.

[Work ow Management Coalition, 1994] de nes a business process as:

De nition 3.6 (business process) A business process is a kind of process that supports and/or

is relevant to business organisational structure and policy for the purpose of achieving business objectives.

3.4 Work ow design

15

Figure 3.1: ER model of the work ow concepts

3.4 Work ow design According to [Smith, 1993] work ow analysis and design is not an exact science { common sense and compromise play a part in work ow design. The goals of work ow design are centred around:

reducing the opportunity of errors to occur increasing the productivity of work processes ensuring that the tasks people perform are meaningful and satisfying These are not mutually exclusive goals. Errors occur for a variety of reasons, including insucient information, too much information, too many steps, or too complicated a procedure, boredom, carelessness, interruptions, and distractions. These factors also in uence productivity. In addition, productivity is diminished through improper task sequencing and redundancy. When designing a work ow a distinction can be made between designing a work ow for a new process, improving an existing work ow and making changes to an existing work ow. In the last two cases it is possible that the process is already supported by an automated work ow management system and/or a document information system (DIS, see section 3.6.2). Which case of design we are dealing with in uences the contents of the tasks in work ow design and the support that is available. Work ows can be supported by software tools in many dierent ways. [Joosten, 1994b] mentions the following tools:

The support can consist of the charting of a work ow by means of a CASE tool aimed at

work ows. This support is aimed at the analysis of work ows. Support by generating information about the work ow with the intent of letting managers decide about interventions in the work ow is important for the actual operation of a (partly) automated work ow.


16

Animating a work ow is a useful support during the design process, because people can

develop a feeling concerning the course of the work ow in practice. The simulation of the work ow can be important when quantitative arguments are under discussion. The work ow can be supported by a programme that directs an administrative procedure. This support is oered by a work ow server that triggers, monitors and administers the procedure at run-time.

Note that this list of tools does not mention the use of a knowledge-based system. One of the goals of the Scarabaeus project is to investigate if knowledge-based support should be added to the list. The editor part of the tool can be considered a CASE tool.

Figure 3.2: Tasks in the design of a work ow Figure 3.2 shows a so called task structure diagram of the tasks performed and the products produced in the design of a work ow. The diagram also shows where the editor and a knowledgebased system can support the user. The symbols used in the diagram are explained in gure 4.1.

choose process The speci cation of the process and its boundaries can be supported by a CASE tool.

construct initial work ow model When designing a work ow for an existing process this step

can be considered the analysis of the work ow. In case a new work ow is designed, an initial model for the desired situation must be made. In both cases, the charting can be supported by a CASE tool. improving Before the actual work ow is implemented or improved, the model must be improved. The model thereby functions as a kind of laboratory for testing certain changes in the organisation. In this step the dierence between designing a new work ow and changing an existing work ow is the greatest. This is because in the latter case data about the performance of the work ow can be used. When designing a new work ow this data is not yet available. Performance data can be obtained from analysing the audit trail created

3.5 Architecture

17

by an automated WFMS or from responsible actors. Both the designing a new work ow and changing of an existing work ow can be supported by animation, simulation and a knowledge-based system. adapt model The charting in this step can be supported by a CASE tool.

3.5 Architecture Due to the fact that a work ow system is a combination of centralised control and local interactive processing, it is ideally suited for a client/server architecture. This architecture allows for implementations ranging from conventional mainframe based situations through interconnected local area networks. Many organisations have the infrastructure already in place, which is frequently based on PC workstations with MS-DOS/MS-Windows. Few work ow tools support character terminals explicitly.

3.5.1 Architecture of a work ow support system Figure 3.3 gives the generic architecture of work ow support systems. This is essentially a LEGEND client component active component

worker

developer

manager

storage component

Interface processor

event manager

workflow manager

definitions

transactions

observations

Figure 3.3: Generic architecture for a work ow support system client/server architecture. It is generic in the sense that each of the components can occur multiply in dierent guises. It is also generic with respect to the concrete machines on which the components are located. Any component can be mapped on any machine, which includes the possibility of combinations of components on one machine. Three dierent storage components are distinguished: a de nition store, a transaction store and an observation store. The de nition store contains the structure of work ows. The transaction store keeps track of all activities performed in a work ow-instance. The observation store contains information about work ows, which is used for workload balancing, productivity measurement, accounting, etc. There are three dierent types of active component in a work ow support system: interface processors, event managers and work ow managers. An interface processor links applications to the work ow system. It can be either custom or tailor-made. The event manager maintains a list of work to be done, guarding deadlines and work conditions and notifying other actors. A work ow


18

manager coordinates within work ows, spawns and monitors other work ows, and communicates with other work ow managers when necessary. The clients occur in three dierent roles: workers, developers and managers. They are distinguished because they require dierent functionality from a work ow support system. In practice, combinations of these roles are not uncommon. In many situations, work ow support and document imaging are an obvious and successful combination. A mature electronic communication infrastructure within an organisation stores and transports most of the information objects used in a business process. This includes documents, les and archives, which makes the role of imaging technology an obvious one. A document imaging system is often an essential part of the infrastructure in which a work ow system is operational.

3.5.2 Architecture work ow design tool Figure 3.4 depicts the architecture of the work ow design tool. The correspondence of this gure with gure 3.3 is the following:

The work ow design tool corresponds with the developer. The external representation corresponds with the de nitions.

Figure 3.4: Architecture of the work ow design tool

3.6 Related topics In this section, some topics related to work ow and work ow design are described.

3.6.1 Groupware and CSCW Groupware is a collection of tools to facilitate the co-operation within an organisation. These tools have led to the creation of a specialised eld named Computer Supported Co-operative Work (CSCW). A groupware system, or a co-operation support system, is de ned as a computer-based system that supports groups of people engaged in a common task (or goal) and that provides an interface to a shared environment [Ellis et al., 1991]. A signi cant part of a person's work occurs in a group rather than an individual context, which makes group support an important issue. Coordination, communication and co-operation are the cornerstones of group activity. Work ow automation is a part of this discipline, due to the fact that the purpose of work ow automation is facilitating and coordinating activities of groups [Joosten et al., 1994a].

3.6 Related topics

19

3.6.2 Document information systems As a result of the rise of techniques as there is document image processing (DIP) , a strong need for systems that can manage electronic documents evolved. Document information systems (DIS) concern the storage and distribution of documents by electronic means. Nowadays, next to scanned documents, all kinds of les can be stored in an electronic archive. Next to document images, a DIS also contains word processing les, spreadsheet les, database les and more [Hales and Lavery, 1991]. Work ow automation is often confused with document information systems. [Joosten et al., 1994a] think that it is important to make a distinction, because a work ow essentially consist of work. The fact that documents are an important part of that work means that the two can make a useful combination. It does not mean that they are identical. For example a telephone conversation, a spoken word or an unwanted situation can trigger work just as well as a document. Furthermore, the functionality of work ow tools contains components that go beyond the technology of document imaging, such as the monitoring of a work ow. The advantages of both technologies should not be confused either. Advantages of a document information system are le consistency and fast and unlimited access of document les. Advantages of work ow management are possibilities for monitoring the status of the work process, optimising the work and increasing the throughput as result of the optimisation.

3.6.3 Business Process Redesign Business Process Redesign (BPR) is closely related to work ow. BPR may cause major changes of the organisation, because business processes are subject of discussion. Work ow management deals with the organisation of business processes, without disputing the business process itself. Work ow automation has its main eect on operational management. It enables improvement of tactical and strategic management because managers spend less time on operational management tasks. Furthermore, work processes can be simpli ed and monitored quantitatively, which enables improved job scheduling, shorter feedback loops and improved insight in the work process [Joosten et al., 1994a]. Batelaan uses the following levels of restructuring (see gure 3.5): 1. Business redesign: This is reorganisation at the strategic level, where the changes or improvements concern the corporate mission, the clients and the products. 2. Business Process Redesign. Here complex compound business processes such as the process of distribution and purchase are re-designed. 3. Work Process Redesign: This is at the operational level. It concerns improving the administrative transactions within an existing business process. An example is the routing of forms and information in the purchase process.

3.6.4 Logistics The resemblance between work ow management and logistics is obvious. In both areas processes must be streamlined regarding throughput and supplies. The fact that logistics are mostly associated with production while work ow management is associated with administrative processes does not alter the case; none of both disciplines is restricted to production or administration. The term 'oce logistics' seems to be appropriate in this context. It is associated with the situation where actors are processing ows of information [Joosten et al., 1994a].

20


Figure 3.5: Three levels of restructuring

Chapter 4

Conceptual analysis 4.1 Introduction In this chapter the way work ows are designed by experts in practice is analysed. The goal is to collect all information necessary to specify how a work ow design editor can support the design of work ows. First the tasks that should be supported by the editor are described. Then the task that should be supported by the knowledge-based system are described. Finally, a conceptual model will be given.

4.2 Task analysis For the notation of the tasks Task Structure Diagrams are used. The meaning of the symbols in these diagrams is given in gure 4.1.

4.2.1 The work ow design task The process of work ow design is depicted in gure 4.2.

Figure 4.1: Notation of Task Structure Diagrams 21

4. Conceptual analysis

22

Figure 4.2: Tasks in work ow design In section 3.4 the tasks 'choose process', 'construct initial model' and 'adapt model' were assigned to be supported by the editor part of the tool. These tasks are shaded in gure 4.2. The task 'improve WF model', was assigned to the knowledge-based system. The tasks assigned to the editor are described below, and how they can be supported by the editor. Furthermore, the task 'improve WF model' is described, which is not considered in the rest of this report.

4.2.2 Tasks supported by the editor In 'choose process' a business process for which a work ow must be (re)designed must be chosen. Choosing the process also means that the boundaries of the process must be determined. A process may be chosen for dierent reasons, depending on the type of goals that are identi ed. External goals are aimed at satisfying the demands of the environment and internal goals are aimed at internal eectiveness and eciency. External reasons are the demand of higher throughput, more client focus and exibility. Internal reasons are the archiving problem, the desire for more control over the process, quality of data, integration, a malfunctioning system or more management information [Joosten et al., 1994a]. In 'construct initial WF model' an inventory is made of what activities are performed, when the activities are performed (sequencing), by whom they are performed and who is responsible, and what information elements are produced/consumed by the activities. Also as much as possible characteristics of the process must be collected to be able to identify problems in the next tasks. In 'adapt WF model' an existing work ow model can be adapted. This adaptation can relate to suggestions for improvement given by the knowledge-based system. The model can also be adapted because the actual situation has changed. The editor provides support for the above tasks, by making it possible to input, store, and process the collected data. For example, the editor makes it possible to specify a work ow graphically. For a detailed description of the editor, see the chapters 7 and 8 concerning the design.

4.2.3 Tasks supported by the knowledge-based system In section 3.4 the goals of work ow were described to be centred around reducing the opportunity of errors to occur and increasing the productivity of the work process. These two goals are addressed during improving.

4.2 Task analysis

23

Figure 4.3: Tasks performed by experts to improve a work ow In literature (see [Hammer, 1990, Hickman, 1994, Born, 1994, Parry, 1994, Smith, 1993]) several indications for improvement are given. However, these indictions are super cial. Human interpretation and intuition are necessary to use the indications for a work ow at hand. Empirical research had to be done to make the knowledge of work ow design experts explicit, i.e. make their knowledge operational. A description of the results of the empirical research can be found in [van Bekkum, 1995]. In this section only a summary of the results is presented. The task 'improve WF model' consists of four subtasks (see gure 4.3).

De ne objectives and preconditions. First objectives for improving are de ned using perfor-

mance criteria. The criteria used were found to be time, costs, exibility and quality. The preconditions specify the degree to which changes are allowed to the so called supporting disciplines: organisation, human resources, information technology and oce facilities. Find problems. To nd problems, the model of the work ow is studied and all locations in the model that can be improved are identi ed. The identi cation of the problems is done using rules-of-thumb. These rules use the structure of the work ow model and the characteristics speci ed during 'construct initial WF model'. Determine possible solutions. For the problems identi ed, solutions must be found. A solution speci es which adaptations must be made to the work ow model. Examples of adaptations are, the elimination of an activity, and changing the responsibility for an activity. Determine suggestions. The solutions all have an in uence on the performance criteria and the supporting disciplines. Only solutions that do not violate the objectives and the preconditions are selected. An applicable solution is called a suggestion. The task 'de ne objectives and preconditions' is supported by the editor. The handling of 'suggestions' is also an editor task. The goals of improving indicate that the problems can be divided into two types. To reduce the opportunity of errors to occur, the design of a work ow must be checked for design errors. Design errors can occur as soon as changes to a model are made and even when the analyst wrongly charts the current (error free) situation. The other type of problem is a possibility for optimisation. Even


24

if a design is free of errors, it is not certi ed to be optimal. In order to increase productivity, the design of the work ow can be optimised, also called streamlined. This means among others that waste is eliminated. The tasks performed for both types of problems are basically the same. The dierence is that, when eliminating design errors, no objectives and preconditions are de ned because the errors should always be solved. Consequently, all possible solutions for design errors are suggestions for improvement. The conceptual basis is laid is the next section.

4.3 Conceptual model This section describes the knowledge that is static in the sense that it presents a description of the facts about the domain of work ow design without making statements about how this knowledge might be used in problem solving. It is a detailed analysis of all concepts necessary for performing the design tasks. The conceptual model is based on empirical research and literature. The model has been developed by all three project members together because it is the basis of all three project tasks. For the notation of the conceptual model we use the Extended Entity Relationship model as described in [Batini et al., 1992]. The meaning of the symbols is given in gure 4.4.

Explanation: The rectangles denote entities and the lines represent relations between the entities. For each relation a cardinality is de ned. In the gure an instance of entity A has a relation AB with 1 or more instances of entity B. An instance of B has a relation with zero or one instance of A. An instance of A has a relation AC with exactly one instance of C. Finally, an instance of C has a relation with zero or more instances of A. Note that this last cardinality is not shown. Entities D and E are disjunctive subsets of entity B.

Figure 4.4: Notation of Entity-Relationship diagrams

4.3.1 Perspectives on work ow To be able to adequately describe processes many forms of information must be integrated. [Curtis et al., 1992] mention the following four perspectives in process representation:

The functional perspective represents what activities are being performed and what ows of

informational entities (e.g. data, artifacts, products) are relevant to these activities. The behavioral perspective represents when activities are performed (e.g. sequencing), as well as aspects of how they are performed through feedback loops, iteration, complex decisionmaking conditions, entry and exit criteria, and so forth.

4.3 Conceptual model

25

The organisational perspective represents where and by whom in the organisation activities

are performed, the physical communication mechanisms used for transfer of entities and locations used for storing entities. The informational perspective represents the information entities produced or manipulated by a process; these entities include data, artifacts, products, and objects; this perspective includes both the structure of informational entities and the relationships among them.

These perspectives were also distinguished in [Joosten et al., 1994a] as respectively process, control, organisational and data perspective. It is stated that support of work ow should focus on triggering, activities and responsibility of actors. To emphasise this focus the following perspectives are distinguished:

data ow the ows of informational entities between activities and stores. control represents which activities are in the work ow, their triggering relations and the

responsibility of actors. organisational represents where and by whom in the organisation roles can be ful lled. data represents the objects created, deleted, used and changed by activities, the structure of these objects and the relations between them.

The dierence with the perspectives distinguished by [Curtis et al., 1992] is that the activities have been moved from the functional perspective to the control perspective. As this leaves only the ow of informational entities for the functional perspective this perspective is called data ow perspective. Each perspective consists of a set of related concepts. The relations between the perspectives are depicted in gure 4.5. The circles represent the perspectives. The lines between the circles indicate the concept that relates the perspectives. For example, the relation between the control perspective and the organisational perspective is realised by the concept role.

Figure 4.5: Relations between the perspectives on work ow Next to the four perspectives on work ow described above, there is a group of problem-solving concepts that are needed by the knowledge-based system in speci c. All perspectives are described in the next subsections.

4.3.2 Control perspective The control related concepts and their relations are depicted in gure 4.6. An activity is a set of acts that are performed under the responsibility of one actor in a speci c role. Activities are the basic unit of work. Three kinds of activities are distinguished:


26

Figure 4.6: Relations between control related concepts 1. An atomic activity is used to denote that no deeper structure is recognised in an activity. 2. The synchronising activity is an activity for synchronising ingoing and/or outgoing triggers. This kind of activity does not take any time and is only used to indicate the synchronisation. 3. A complex activity can be expanded to see the inner structure. This inner structure is a sub work ow. It is used for introducing dierent levels of detail in the work ow. If the inner structure is not speci ed, the activity is called a temporary activity. This denotes that further elaboration is needed. Atomic and synchronisation activities are also called basic activities. The attributes of an atomic activity are:

Type of activity Added value Performing mode Supporting tools Batch size Necessary capacity Criteria for division of work The dierent types of activities are not made subtypes of an atomic activity, because up to now there are no attributes available that relate to one of the types in speci c. The types of activities are:

A processing activity processes input into output. A decision activity makes a decision which way to go based on the input. A veri cation activity veri es if the input is correct according to speci ed norms. A documentation activity only registers or archives. Registration and archiving often only change the format of the registered or archived information.


27

A communication activity is an activity in which a group of actors consult with each other.

In a communication activity a consensus may be reached so the activity may result into multiple optional triggers coming out of the activity. A transport activity only moves objects from inside or outside the work ow. A time activity can be represented by a clock. It can be used to implement deadlines.

The added value describes how important an activity is. Three values are distinguished: low, medium or high. A high added value means that the activity is important or even obligated. The performing mode describes how the activity is performed. There are three modes: automatic mode, manual mode, and mixed mode. In automatic mode the activities are executed automatically. In manual mode the activity is performed completely manual. In mixed mode there is interaction between people and computers. The supporting tools describe which tools and applications are used. The batch size describes the size of batches which have to be handled by an activity. The necessary capacity describes how much capacity is needed for an activity. There are ve criteria to divide the work over the actors: 1. Based on time. The rst actor that is available to perform the activity. 2. Based on geographic location. The actor that is nearest. 3. Based on workload. Each portion of work has a weight to indicate how dicult the work is. Each actor is given the same workload. 4. Based on a key. A key is de ned on how to divide the work. For example based on the rst letter of the last name of a customer, or based on region the customer lives. 5. Based on other activities. Here the activity must be performed by an actor that is the same or not the same as the actor that has performed another activity for the same work. Characteristics that can be obtained by simulation, analysis of an audit trail, or experience are:

Average processing time Deviation in processing time Average completion time Deviation in completion time Arrival pattern. This is the pattern of arrival of work for an activity The processing time, completion time, and arrival pattern are a distribution function. A trigger is an event that can be perceived by its carrying object and that leads to the start of an activity. Triggers are used to implement the control aspect. For a trigger the following attributes are de ned:

probability condition


28

A decision, communication or veri cation activity can be the originator of only one trigger at a time. The probability gives the relative frequency the dierent triggers are activated. In case of other types of activities (processing, transport, time, documentation) the probability of the trigger they start is always 100%. The condition describes the criteria for moving from the current activity to the next activity. An activity must be the beginning of a trigger, the end of a trigger, or both. An isolated activity has no signi cance. The role is an intermediate step between activities and the actual performer/responsible in the organisation (see section 3.3). For each activity there is exactly one responsible role. Atomic activities can be performed by one or more roles. As the activities can be decomposed, the roles can also be decomposed. Because a role is an intermediate step, it does not have to be responsible or performer. A role can be performing and responsible at the same time, e.g. a manager that performs an activity and is also responsible for it.

4.3.3 Organisational perspective The organisation related concepts and their relations are depicted in gure 4.7.

Figure 4.7: Relations between organisation related concepts An organisation consists of organisational units that can be hierarchically organised. Each unit consists of actors. An actor can be a person, a machine, or a group. The word group is used to stress that people work together for a speci c purpose, and not because they are in the same organisational unit. However, a group corresponds to an organisational unit if both contain the same actors. The concept role has already been described as a link between the activities and the organisation. A role can be played by an actor. Because a role is an intermediate step, it is not obligatory that a role is played by an actor. The actor chosen to play a role, depends on the level of detail (decomposition) of the activities in the control perspective.

4.3.4 Data perspective To be able to perform the activities in the work ow, data are needed. The data related concepts and their relations are depicted in gure 4.8. An object is something that is perceptible and that can be located. Following [van Hattum, 1994], data objects can be divided into three classes:


29

Figure 4.8: Relations between data related concepts

An elementary data element. The data type can be integer, boolean, string and date. An

example of such a data element is a customer number that can be used as a reference to that customers data. A document. A document can be a paper, an e-mail, EDI, a fax or a le. It can consist of elementary data objects. A folder. A folder is a collection of data objects. It can consist of other folders, or documents.

Within each atomic activity possible operations on data are: create, delete, use, and change.

4.3.5 Data ow perspective

Figure 4.9: Relations between data ow related concepts The information ow perspective consists of a limited part of the functional perspective of [Curtis et al., 1992], namely the ow of information between activities and stores. Data are needed to perform an activity. Where the data comes from, and where they go to after the activity has been performed, is speci ed by means of a store. A store is a place where objects can be stored. A store is a means to exchange data between activities. Only ows between stores and activities are considered. No ows are de ned between activities directly because that implicates a synchronisation between the activities.


30

Figure 4.10: Relations between the problem-solving concepts An activity always stores (source) an object in a store, or gets (sink) an object from a store, or does both. An object does not necessarily have to be stored, in case it is not needed by other activities. A store that stores objects that are never used is not allowed. It is also not allowed to get objects from a store that have never been stored. A store that is never used is also not allowed.

4.3.6 Problem-solving perspective The concepts of the four perspectives described until here are all used to describe a work ow. Other concepts exist that are related to nding and solving problems in a work ow model in particular. The concepts and their relations are depicted in gure 4.10. The concepts are mentioned here, only to show how the 'objectives and preconditions', and the 'suggestions for design errors and improvement' used by the editor, relate to the other concepts. For a detailed explanation see [van de Belt, 1995].

Chapter 5

Requirements analysis 5.1 Introduction In this chapter requirements that must be satis ed with regard to the development of the work ow design tool are discussed. Then four possible ways to realise the tool are proposed. Finally one of the possibilities that meets the requirements in the best way is chosen and re ned.

5.2 Work ow design tool requirements What is needed is a tool that supports the analyst in the phase preceding the actual implementation, i.e. a work ow design tool. This tool should consist of a graphical editor supported by a knowledge-based system that contains work ow design knowledge (see gure 3.4). With regard to this some general requirements must be taken into account. The tool should:

focus on triggering, activities and responsibility of actors; the basis of trigger modelling as described in [Joosten, 1994a].

have a good conceptual background. have knowledge-based system support. be platform independent (portable). have a graphical user interface. perform well. be robust. be easily adaptable. be realisable with an available 'environment'. 31

5. Requirements analysis

32

5.3 Tool realisation alternatives In order to establish which tools are suitable and available for reuse, an investigation into existing tools and tool kits has been conducted. If contemporary work ow tools provide adequate support during the design phase of work ows, then there is no need to develop a new tool. Probably some small adaptations to an existing tool are sucient to meet the requirements. Therefore we have investigated, which work ow (or related) tools are available, and to what extent they oer support during the design phase. If contemporary work ow tools do not meet the requirements, then the question arises: which alternatives are available to build a work ow tool that supports work ow design. Answering this question is interesting enough, even if work ow tools meet the requirements. To get an answer we looked at software development. Alternatives for using an o the shelf solution are: Computer Aided Software Engineering (CASE) or Computer Aided Method Engineering (CAME) tools. If that is not satisfying it is possible to build a new tool using a programming language (supported by dedicated libraries that facilitate the building of the tool). In the following subsections the above stated possibilities for realising the work ow design tool are worked out:

(extend) existing work ow/BPR tools (like FlowMark, Action Work ow Analyst, BDF). use CASE tools (like SDW or Excelerator). use Meta-CASE / CAME tools (like Meta-edit, Maestro II, or Toolbuilder). build a new tool using a programming environment (like C++). For each possibility, advantages and drawbacks are discussed with regard to the requirements.

5.3.1 Work ow related tools A distinction between work ow tools and BPR tools is made, because of their dierent character. BPR tools support at a tactical level, and work ow tools support at an operational level (see also gure 3.5). In appendix A an overview of work ow related tools can be found. For each tool the aspects: general, philosophy, concepts, components, user, design, management, and control, are discussed according to [van der Harst, 1994]. Looking at appendix A, some general shortcomings of contemporary tools for the purpose of supporting work ow design are:

The conceptual background of tools is often not founded in a conceptual framework, which

makes an ad-hoc impression. Data ow and triggering are often confused or put together in one diagramming technique, whereas the separation of primary process data and control are an important factor in the success of work ow management. Inadequate support during the design of work ows (streamlining and design error detection), testing the work ow before putting it into practice. Lacking standards to support interoperability among work ow systems and third party software.

5.3 Tool realisation alternatives

33

To use an existing work ow (or related) tool as the basis of the Scarabaeus tool, has the following advantages: Little work has to be done to realise the required functionality. The tool is already available, known, and tested in practice. Using a work ow tool has the following drawbacks: The basic concepts of trigger modelling are not supported. Knowledge-based system support is not available. Integration with other tools (e.g. knowledge-based system) is dicult or even impossible. Platform dependency. Probably low performance, because it is not dedicated to its tasks.

5.3.2 CASE tools First of all, what is a CASE tool? CASE tool: Computer Aided Software Engineering, the development of information systems with an automated tool [Kusters et al., 1992]. As described by [Fisher, 1988] CASE tools substantially reduce or eliminate many of the design and development problems inherent in medium to large software projects by automatically generating most of the software based on designs speci ed by the software architect. Examples of CASE tools are: SDW and Excelerator. Looking at the description, a CASE tool can be seen in dierent ways: it has much resemblance with a work ow (related) tool. it supports the design of an information system. To use a CASE tool as the basis of the Scarabaeus tool, has the following advantages: No need for own conceptual model, or a few changes are sucient (if possible), because of its resemblance with a work ow tool. The tool is already available, known, and tested in practice. Consistency, adaptability, maintainability and standardisation. Using a CASE tool has the following drawbacks: The basic concepts of trigger modelling are not supported. Dicult or even impossible to modify incorporated conceptual model. Knowledge-based system support is most likely not available. Integration with other tools (e.g. knowledge-based system) is dicult or even impossible. CASE tool dependency. Platform dependency. Probably low performance, because it is not dedicated to work ow design. Dedicated to information systems. Information system modelling is dierent from work ow modelling [Joosten, 1994a].


34

5.3.3 Meta-CASE tools First of all, what is a Meta-CASE tool?

Meta-CASE or CAME tool: Computer Aided Method Engineering, environments that are dedicated to realise CASE tools [Wijers, 1992].

Examples of Meta-CASE tools are: Meta edit [Smolander et al., 1991]: is a tool that oers the possibility to draw a conceptual model (meta-model), and draw symbols that represent concepts. A diagram editor is then created based on the conceptual model and symbols. Maestro II [Merbeth, 1991]: is a complex development environment meant to support large development teams. It is possible to de ne new diagram techniques. Also a procedural programming language is available. To use a Meta-CASE tool as the basis of the Scarabaeus tool, has the following advantages:

Easy editor building and adaptation, because once one has the conceptual model, 'little

work' has to be done, because the editor building is standard. Uniform user-interface / editors. The tool is already available, known, and tested in practice.

Using a Meta-CASE tool has the following drawbacks:

Knowledge-based system support is not available (closed system). Integration with other tools (e.g. knowledge-based system) is dicult or even impossible. Meta-CASE tool dependency. Platform dependency. Probably low performance, because Meta-CASE tools are often very extensive/powerful to be applicable to a large area.

5.3.4 Programming environment If none of the before discussed alternatives are suitable, the only remaining possibility is to build the editor using some programming language supported by some tools, i.e. a programming or development environment like C or Pascal, or even an object oriented environment. To use a programming environment to realise the Scarabaeus tool, has the following advantages:

Mostly platform independent. High performance is possible, because the tool will be dedicated to its task. Easier to commercialise, because there is no environment dependency (only for development). Integration with other tools is easier.

Using a programming environment has the following drawbacks:

Time consuming to build an editor (e.g. a user interface has to be build). Perhaps not easy to maintain. Conceptual model must be somehow represented internally as well as externally.

5.4 Conclusions

35

Possibility WF/BPR-tools CASE-tools Meta-CASE-tools Programming language

Trigger model no no can be done can be done

KBS no no dicult can be done

Criterion Platform dependency yes yes yes some

Performance low low low high

Table 5.1: Comparison of realisation possibilities

5.3.5 Overview of realisation alternatives In table 5.1 a summary is given of the main advantages and drawbacks of the above mentioned possibilities in relation with the requirements as mentioned in section 5.2.

5.4 Conclusions In this concluding section a choice for one of the realisation possibilities is made. Drawbacks of the choice are mentioned and solved as far as is possible at this point.

5.4.1 Realisation choice Looking at section 5.3 and especially table 5.1 a programming environment is the most promising realisation possibility. A good alternative is a Meta-CASE tool. The major reasons to choose for a programming environment are: The conceptual background of work ow (or related) tools is rather ad-hoc in nature (one of the major drawbacks). The required support for trigger modelling concepts. The required integration with a knowledge-based system. Platform dependency of (Meta-)CASE tools. Low performance of (Meta-)CASE tools. Bad experiences with (complex) Maestro II [Kloos, 1994]. Simplicity of Meta-edit and no documentation, and no access to the internal and external Meta-edit data.

5.4.2 Overcoming drawbacks To overcome the drawbacks of a programming language as mentioned in section 5.3.4, the following is done: An object oriented language (like C++) can be used. Advantages are: data abstraction, encapsulation, inheritance, polymor sm and dynamic binding, reusability, extendability, correctness when modifying [van Winkel and Willems, 1993]. User-interface toolkits can be used. If the external representation is by means of les, compiler generator tools can be used, for (importing) the external representation of the conceptual model.


36

User interface With regard to the user interface, there are several possibilities to prevent building it ourselves:

Commercial graph editor toolkit, from Tom Sawyer [Tom Sawyer, 1994] (California, USA). Toolkit from Pallas Athena (De Meern, The Netherlands). Public domain graph editor toolkit, as described in [Paulisch, 1993]. Public domain toolkit WxWindows (World Wide Web, Internet). Public domain toolkit YACL (World Wide Web, Internet). Requirements that must be satis ed while choosing one of the above mentioned possibilities to realise the user interface are:

good documentation. good support from the supplier. good performance. After investigation, only the rst two possibilities meet the requirements. The best solution is the graph editor toolkit from Tom Sawyer, because it has several layout algorithms that have been optimised through years of practical experience. The reason to choose for a graph editor is based on [Paulisch, 1993]. He states that there are several ways of representing information graphically, and one of the most general is to represent the information as a graph. A graph consists of a set of nodes and a set of edges. Each node typically represents some object (e.g. activity) and the edges represent binary relationships between these objects (e.g. triggers).

External representation With regard to the external representation, the main possibilities are: databases or les. A detailed discussion can be found in section 8.4.

Chapter 6

User interface theory 6.1 Introduction In this chapter the theory on user interfaces is described as is done in literature and choices are made. User interface design combines two awkward disciplines: psychology and computer science. These disciplines have very dierent cultural backgrounds. Psychology is concerned with people; computer science with computer machinery. Good user interface design requires these two perspectives to be united [Thimbleby, 1990].

6.2 User friendliness In this section four requirements for the user friendliness of a user interface are discussed as can be found in [Pikaar et al., 1991].

Robustness

The degree of robustness refers to aspects of the user interface, that it must give the user a reliable and solid impression. Simple mistakes made by the user must have no undesirable reactions of the system. The system must be able to deal with input that is not correct according to the speci cations. In short: mistakes made by the user cause an appropriate reaction of the system rather than a system failure.

Consistency

refers to the property that the reactions of the system are uniform in any situation. For example, dierent languages should not be used together. If function keys are used, they should have one function that is not changed.

Symmetry

means that one is able to move forwards and backwards through the system, add and delete, start and stop. For example, if it possible to insert data, it must also be possible to delete this data.

Control

The degree of control refers to the fact that the user gets the idea, that he controls the system and knows what it is doing. The system must act like a user controlled system and not otherwise. Every reaction of the system must be a logical reaction to an action performed by the user. For example, every presentation on the screen should have a logical name, and possible actions must be visible for the user. 37

6. User interface theory

38

6.3 Dialog styles In this section a classi cation of dialogue styles are discussed as can be found in [Downton, 1991].

Menus

The primary design problem in organising a menu-based dialogue results from the fact that most realistic tasks require more commands than can conveniently be represented on a single menu. The most widely used solution for this problem is the hierarchical tree, which allows selection from a large number of choices with a relatively small number of options in each menu and few levels in the hierarchy. Selection mechanisms can be: typing the required number of the selection; typing its name; pointing and clicking on the item by use of a mouse etc. Advantages of this dialogue style are: the minimal typing required; the well-de ned structure; and the low memory load. Drawbacks are, that it is not suited for: data-entry; user-initiated dialogues; and mixed initiative dialogues.

Form- lling

Form- lling is a metaphor in human-computer dialogues, because humans are inherently familiar with the concept of lling in forms, and computers are widely used to manipulate and process databases of information, which are stored as records containing dierent elds of related information. These records are generally most conveniently visualised as forms. The key bene t of form lling is that all information in the record is simultaneously visible giving the user a feeling of control over the dialogue. Because of this control the user has to learn various application-speci c syntactic rules before pro ciency is attained. Advantages of this type of dialogue are: the familiar metaphor of form- lling; the simpli ed data entry; and the well de ned structure. Drawbacks are: the consuming of screen space; the need of some training; and systems are sometimes slow.

Command language

Command language dialogues are user-initiated and generally consist of the user typing a command or command string of syntactically correct words, without prompting or help from the system. The user is expected to know or learn these commands. Command languages can be simple from typing a command from a command-list to commands with subsequent words as quali ers or parameters, which specify the action of the command in more detail. Advantages of this type of dialogue are:

6.3 Dialog styles

39

the exibility; the eciently and user-initiated actions. Drawbacks are:

the long training needed; the need of regular use to maintain pro ciency; and the poor error handling. Natural language

In a natural language dialogue, a user can communicate with the system by using his own language. Although the idea looks promising, implementing a natural-language dialogue is substantially more complex to programme than any other dialogue style discussed before. Natural-language recognition still represents a major linguistic research problem, and current natural-language processing systems are generally constrained to operate within limited knowledge domains using constrained syntax and restricted vocabularies (see also the Parlevink project). Advantages of this type of dialogue are:

the exibility; the fact that it is a natural form of interaction; and that no special syntax is required. Drawbacks are:

the complex software design; and the fact that natural language is ambiguous, imprecise and verbose. Direct manipulation

Direct manipulation is a dialogue style with the characteristic that some kind of direct representation of the task is presented to the user by the system, with the result that the desired operation or command is achieved by directly manipulating the virtual reality embodied in the display. The primary advantage of using a metaphor to represent the actual function is that operations and command can be readily suggested by analogy between the computer representation and its real life equivalent. An example is the displaying of a folder on the screen that can be opened and looked inside. Advantages of this type of dialogue are:

the visual appeal; the task analogy; and the reduced learning time needed. Drawbacks are:

the complex software; and the skilled graphics design required.

6. User interface theory

40

6.4 Types of user interfaces In this section two possible types of user interfaces for computers are discussed.

Character-based

A character-based user interface can only work with characters and not with graphical objects. The dialogue styles: menus, form lling, command language, and natural language can be implemented as a character-based user interface. A cursor is used to navigate through screens. Until recently, character-based user interfaces were the only possibility to implement dialogue styles.

Graphical User Interface (GUI)

A graphical user interface is an application environment that can work with graphical objects. The dialogue styles: menus, form- lling, and direct manipulation can be implemented as a GUI. All application environments for GUIs support some sort of pointing device, usually a mouse. GUIs are often used as an interface to database systems.

[Powell, 1990] stresses that the main bene t of a GUI above a character-based interface is, that it enforces consistency by restricting developers, because they must support features for the programme to run under the GUI.

6.5 Conclusions In this concluding section the theory as described in the above sections is used with regard to the Scarabaeus work ow design tool.

User friendliness

The work ow design tool has to be user friendly. While developing the tool the robustness, the consistency, the symmetry, and the degree of control must be taken into account.

Dialogue styles

With regard to the dialogue styles, it is appropriate (having in mind other work ow or related tools) to make use of menus, form- lling and direct-manipulation.

Type of user interface

As required the user interface must be graphical. The dialogue styles mentioned above match to the ones mentioned of a GUI.

Chapter 7

Functional design 7.1 Introduction In this chapter the functional design of the work ow design tool is described. First the composition of the tool and an editor transfer chart is given, together with an extended conceptual model. This is followed by an overview of the functionality needed by the work ow design tool. Data structures in general are discussed, and how they can be used for the tool. Then a process decomposition is presented using data ow diagrams. After that the user interaction with the system is presented using state transition diagrams. Finally the types and functions are presented by means of signature graphs. The design tasks performed and the techniques used are in conformity with the research approach (section 2.3.3).

7.2 Tool composition The tool consists of two main parts and an interface between them ( gure 3.4):

Graphical work ow design editor, as described in this thesis. Knowledge-based system, as described in [van de Belt, 1995]. Interface between editor and knowledge-based system. 7.2.1 Diagramming techniques The four perspectives on work ow (section 4.3: control, organisation, data, and ow of data) have to be re ected as diagramming techniques in the editor, as illustrated in gure 7.1. The possibility to switch between several diagramming techniques can be represented by so-called editor transfer charts [Brinkkemper, 1993]. An editor transfer chart contains the diagram techniques represented by bold rounded rectangles and labeled arrows representing the links to switch from one diagram technique to another. The direction of an arrow represents the direction in witch it is possible to switch between the diagramming techniques. An arrow with the name of a diagram component denotes the capability to switch from one editor to the other by choosing any of the instances of the component, e.g. by a mouse click on a component of a diagram. 41

7. Functional design

42 Trigger editor

Flow of data editor

Organisation editor

Data editor

Repository

KBS

Figure 7.1: Architecture of the work ow design tool Complex Activity

Trigger editor

Role

Organisation editor

Activity Atomic Activity

Data editor

Object

Flow of data editor

Figure 7.2: Editor transfer chart In gure 7.2 the editor transfer chart for the work ow design tool is given. For example, in the 'trigger editor' the user selects an 'atomic activity' and gives the command to switch to the 'data editor'. Then the user can edit data concerning the 'atomic activity' that was selected. The user returns to the 'trigger editor' by quitting the 'data editor'. Decomposition in a 'trigger model' is represented by the loop 'complex activity'.

7.2.2 Editor speci c concepts In order to make the conceptual model (section 4.3) usable for the graphical work ow design editor, it must be extended with new concepts and attributes that are speci c to the editor. Concepts of interest are:

Diagram: which can be subdivided, according to the four perspectives on work ow, in:

{ { { {

trigger diagram (control perspective). organisation diagram (organisational perspective). data diagram (data perspective).

ow of data diagram (data ow perspective). Work ow: being at least the name of the work ow, and all diagrams (= all data available about the work ow).

Attributes of interest among others are:

7.3 Tool functionality

43

Figure 7.3: Extended conceptual model

x and y co-ordinates (for an activity, a trigger or a diagram). layout style. symbols used. The extended conceptual model is given in gure 7.3. The relations that are not depicted, are the same as between 'work ow' and 'diagram', and between 'data diagram' and 'object'. In this thesis focus is on the control perspective. This means that trigger modelling is one of the rst (and for the time being the only) diagramming techniques that is provided by the editor. However, the design is as broad as possible. This choice has been made because empirical research has been primarily focussed on the control perspective, so fewer is known about the other three perspectives.

7.3 Tool functionality In this section the functional aspects of the graphical work ow design editor are described. It concerns: internal and external work ow data, graphical functionality, diagram hierarchy, knowledgebased system interfacing and general functionality.

7.3.1 Internal and external work ow data

Internal representation: Work ow data must be internally represented, and have operations on it.

External representation:

It must be possible to represent the internal data on long persistent storage. Save / export: It must be possible to save the current situation any time the user wants. This means writing the internal work ow data to its external representation. Load / import: It must be possible reading in work ow data from its external representation.


44

7.3.2 Graphical functionality

Adding: It must be possible to add nodes/edges in a diagram (e.g. adding an activity or a trigger).

Deleting: It must be possible to delete nodes/edges. Moving: It must be possible to move nodes/edges. Adding properties: It must be possible to add properties to nodes/edges. Showing properties: It must be possible to show properties of nodes/edges. Updating properties: It must be possible to update properties of nodes/edges. Zooming: It must be possible to zoom in and zoom out. Scrolling: It must be possible to scroll into the X and Y direction. Resizing the drawing area: Resizing must be possible to show a smaller or greater part of a work ow diagram.

Centralising: It must be possible to place a work ow diagram in the middle of the drawing area.

Automatic layout:

It must be possible to reorganise a diagram automatically (without loosing the column grouping of a trigger model). For example, minimise edge crossings.

7.3.3 Diagram hierarchy

Grouping nodes: It must be possible to select some nodes, and group them together in a new (sub)diagram.

Sub diagrams: It must be possible to draw a new (sub)diagram for a node. Moving through levels: It must be possible to move between dierent levels of abstractions in the diagram hierarchy.

7.3.4 Knowledge-based system

Design errors: It must be possible, given a work ow diagram, to contact the knowledgebased system and let it detect design errors.

Streamline: It must be possible, given a work ow diagram, to contact the knowledge-based system and let it detect possibilities for streamlining.

Handling: It must be possible to receive and handle suggestions from the knowledge-based system.

Presenting: It must be possible to present suggestions from the knowledge-based system to the user in an easy understandable way.

Highlighting: It must be possible to highlight the elements of a diagram which are involved in a suggestion or an error.

7.4 Data structures

45

7.3.5 General functionality

Columns: It should be possible to divide the screen in columns. This is needed in trigger

modelling to specify a role for each column, which is responsible for the activities in his column. Switching diagrams: It must be possible to switch between several diagrams ( gure 7.2). Symbols: It must be possible to use a dynamic set of symbols for drawing. Quitting: It must be possible to leave the editor whenever the user wants. If there are still unsaved changes the user must be asked if he wants to save the changes. Syntax checks: It must be possible to let the editor detect syntax errors. Menus: Pull-down menus, pop-up menus and context sensitive menus should be available, in which several actions are possible (e.g. save, add, update). Status bar: Which displays help information on the current situation should be available. On-line help: On-line help should be available. Portability: The tool has to work on PCs with MS-Dos/MS-Windows, and also on UNIX machines (and possibly other platforms). Mode of operation: There could be made dierence in supporting a novice user and an expert.

7.4 Data structures In this section rst the theory on data structures is discussed as in literature. Then choices are made for the work ow design tool.

7.4.1 Abstract data types An abstract data type is a set with associated operators [Esakov and Weiss, 1989]. For example, the integers with addition, subtraction, multiplication, and division constitute an abstract data type. A data structure is a particular method of representing an abstract data type. There are three main classes of data types:

Atomic data types store single indivisible data values. Usually, programming language built-in

types exist that are adequate for this kind of data. Fixed-aggregate data types values can be viewed as containing a xed number of atomic components. For example, the abstract data types 'complex number' can be viewed as a pair of real components. Variable-aggregate data types values contain a varying number of subcomponents. For example, the abstract data type 'ordered integer list' contains an arbitrarily long ordered sequence of integers. A software model of an abstract data type consists of a set of operations for creating, manipulating, and destroying a particular kind of data object.


46

7.4.2 Internal work ow data For the internal work ow data a variable-aggregate data type is the most appropriate, because it can contain a varying number of subcomponents. One of the best known and general data structures is the list. Lists are ordered collections of objects. This does not mean that lists are sorted, but that as items are added, one can predict their relative positions. For example, one can de ne an operator that adds items at the front, or at the end. Lists have the following properties:

a list can have zero or more items. a new item can be added to the list at any position. any item in the list can be deleted. any item in the list can be accessed. each item in the list can be visited in turn (list traversal). The list mechanism is satisfying for representing work ow data internally. However, it is annoying if a list is of a particular type. In that case there is no way to make a heterogeneous list (containing data of a variety of types). Therefore, it is desirable to have a polymorphic list (type-independent).

7.4.3 User interface For the user interface a variable-aggregate data type is the most appropriate, because it can contain a varying number of subcomponents. There are several ways of representing information graphically, and one of the most general is to represent the information as a graph [Paulisch, 1993]. A graph is a set of points (called vertices or nodes) together with a set of connections (called edges, links, arcs, or branches) [Esakov and Weiss, 1989]. The edges in a graph can be either one-way (the graph is called directed) or two-way (the graph is called undirected). Each node typically represents some object (e.g. activity) and the edges represent binary relationships between these objects (e.g. triggers). The graph mechanism can be realised on top of the list mechanism. In that way, advantage can be taken of the list mechanism that is also needed for the internal work ow data (see previous section).

7.5 Process decomposition The process decomposition is a hierarchical model of processes, data stores, data ows and terminators. Each process is represented by means of a data ow diagram (DFD) [Yourdon, 1989]. The notation used is depicted in gure 7.4. Processes, data stores, and terminators with the same name (or number) in dierent gures are the same. In gure 7.5 the context diagram is given. Here can be seen that a user interacts with the work ow design tool, that is from his point of view like a black box. The constituting parts of the tool are:

7.5 Process decomposition

Process

47

Terminator

Data store

Data flow

Figure 7.4: Notation of data ow diagrams 1 WF design tool

User

Figure 7.5: DFD: Context diagram

a user interface, internal work ow data, means to handle work ow data, external work ow data, means to import and export work ow data, and a knowledge-based system, These constituting parts are depicted in gure 7.6. The central part of the tool is the 'work ow data handler'. Here reside all operations on the 'internal work ow data'. Operations that the user performs with the 'user interface' result in:

direct operations on the 'internal work ow data', handled by the 'work ow data handler'. operations to 'import' or 'export' work ow data, that also result in operations on the 'internal

work ow data'. operations that activate the 'knowledge-based system', that also result somehow in operations on the 'internal work ow data'.

Operations performed by a user, also have consequences for the 'user interface' itself (e.g. drawing a node, changes the screen and also creates a work ow object). As described in section 7.4.2, the 'internal work ow data' is represented by means of lists, with operations on it. The process 'work ow data handler' can be sub-divided in a 'list handler' and 'work ow operations handler' that covers the lists. This subdivision can be seen in the gures 7.7, 7.8 and 7.9. The process 'import and export handler' can be sub-divided in an 'import handler' and an 'export handler' as can be seen in gure 7.7 and 7.8. How work ow data is mapped from the 'external work ow data' to the 'internal work ow data' is depicted in gure 7.7. How data import is originated is not depicted. In most cases it is the user to cause the 'user interface' to start the 'import handler'. How work ow data is mapped from the 'internal work ow data' to the 'external work ow data' is depicted in gure 7.8. How data export is originated is not depicted. In most cases it is the user to cause the 'user interface' to start the 'export handler'.


48

1.2 External WF data

Im- & export handler

Internal WF data

1.1

1.4

WF data handler

User interface

User

1.3 Knowledgebased system

Figure 7.6: DFD: Constituting parts of the tool

Internal WF data

1.1.1

1.1.2

1.2.1

List handler

WF operations handler

Import handler

External WF data

Figure 7.7: DFD: Importing work ow data

Internal WF data

1.1.1

1.1.2

1.2.2

List handler


Export handler

Figure 7.8: DFD: Exporting work ow data

External WF data

7.6 Interaction between user and tool Internal WF data

49

1.1.1

1.1.2

1.4

List handler


User Interface

User

Figure 7.9: DFD: User interface

State

Transition

Figure 7.10: Notation of state transition diagrams How the user aects the 'internal work ow data' using the 'user interface', is depicted in gure 7.9. Actions with regard to work ow data manipulation are handled by 'the user interface' graphically and are propagated to the 'work ow operations handler', and propagated to the 'list handler' that accesses or modi es the 'internal work ow data'.

7.6 Interaction between user and tool In this section the interaction of the user with the tool is described. Because every operation will be user initiated, this section is a description of the user interface. For this purpose state transition diagrams (STD) are used (see gure 7.10). The tool can nd itself in several states. A state is modelled by a circle with a name in it. An operation performed by the user causes the tool to change zero or more states. This is modelled by an arrow between states, with a name on it, indicating the event that caused the state change. No state change occurs, for example, when the user does an operation that is not allowed. States with the same name in dierent gures are the same. The main categories of interaction, that can be derived from the functionalities (section 7.3), are:

Tool startup and quit ( gure 7.11) Diagram operations ( gure 7.12) Knowledge-based system interaction ( gure 7.13) Syntax errors ( gure 7.14) Loading and saving ( gure 7.15) Activity operations ( gure 7.16) Trigger operations ( gure 7.17) The most elementary operations are starting and quitting the tool as depicted in gure 7.11. Starting the tool is done in the shell (environment) in which the tool works (e.g. MS-Windows). The tool will nd itself in a state in which no diagrams exist. Quitting the tool is possible in several states:

no diagrams exists (e.g. directly after starting the tool), nothing special has to be done.


50 start wf editor WF Editor active, no diag

Shell active

Editor startup / quit

quit wf editor

quit editor WF diagram active (WF saved)

ok to save

quit editor WF diag active (WF not saved)

Input filename to save

Shell active

Quit editor

cancel save

Figure 7.11: STD: Tool startup and quit create new wf WF Editor active, no diag

commit

commit Input ’toplevel’ diagram prop.

Input WF prop. cancel

WF diagram active

Create workflow

cancel click on other diag

new diag WF diagram active

Input diagram prop.

Create new diagram

WF diagram active

Change diagram

ok / cancel del diag WF diagram active

WF diagram active

del last diag

WF Editor active, no diag

Delete diagram

Figure 7.12: STD: Diagram operations

if diagrams exist, then two possibilities occur:

{ they have already been saved, nothing special has to be done. { they have not been saved yet, then before quitting the user has to be consulted.

The tool returns back to the environment that started it, except if the user does a cancel in the last possibility. As depicted in gure 7.12 the user can create a work ow (including the rst diagram), create a diagram, change from one diagram to another, and delete a diagram. Once the user has created at least one diagram, it is possible to put the knowledge-based system into action. This means letting the KBS check for design errors or generate suggestions for streamlining a work ow, as depicted in gure 7.13. If the user wants the KBS to generate suggestions for streamlining, then objectives and preconditions (see section 4.2.3) have to be input rst. It does not matter if the diagrams have been saved or not, so it is not mentioned in the gure. If no diagrams exist, then it is not possible to check for design errors or generate suggestions for streamlining. Besides design errors and streamlining, it must be possible to let the editor detect syntax errors. Two ways to handle syntax errors are:

while the user is drawing, he directly gets an error message.

7.7 Work ow types and functions

51

check design errors

KBS ready

WF diagram active

Solutions presented to user

KBS active

Check design errors

ready to go on streamline wf

ok to start KBS Input precond. and object.

WF diagram active

KBS ready Solutions presented to user

KBS active

Streamline workflow

cancel streamline ready to go on

Figure 7.13: STD: Knowledge-based system check syntax errors Error report presented to user

WF diagram active

Check syntax errors

ready to go on

Figure 7.14: STD: Syntax errors

at a certain point the user wants to know if there are syntax errors, then he pushes some button and the editor generates an error report.

In gure 7.14 the second possibility can be seen. Important features of the tool are saving and loading work ow data as depicted in gure 7.15. Loading work ow data is possible in several states:

no diagrams exists (e.g. directly after starting the tool), then the user is asked to input a

lename to load. if diagrams exist, then two possibilities occur: { they have already been saved, then the user is asked to input a lename to load. { they have not been saved yet, then before asking to input a lename to load, the user is asked whether he wants to save the current diagrams.

While asking the user to input a lename to load, he can cancel loading work ow data. As depicted in gure 7.16, while a work ow diagram is active it is possible to add an activity to the diagram, update it, delete it, and associate a (complex) activity with a work ow diagram. It does not matter if the diagrams have been saved or not, so it is not mentioned in the gure. As depicted in gure 7.17, while a work ow diagram is active it is possible to add a trigger to the diagram, update it, and delete it. It does not matter if the diagrams have been saved or not, so it is not mentioned in the gure.

7.7 Work ow types and functions The types (classes) needed in the work ow design tool can be derived from the conceptual model, each entity corresponds to a type (see section 4.3). In this section signature graphs


52

ok to save

save wf WF diag active (WF not saved)

save wf WF diag active (WF saved)


Save workflow

cancel save

load wf

ok to load

WF editor or diag active

Input filename to load

WF diagram active

Load workflow

cancel load WF diag active (WF saved)

cancel load (after saving)

cancel load wf

save & load

WF diag active (WF not saved)

ok to save

Want to save mode


ok to load Input filename to load

WF diagram active

cancel load

load without saving cancel load (after saving)

Figure 7.15: STD: Loading and saving

add activity WF diagram active

click in diag Add activity mode

Add activity

ok / cancel

other

upd activity

sel activity WF diagram active

Input activity data

Update activity data

Activity selected

Update activity

other

commit / cancel upd activity sel activity WF diagram active

Activity selected

Delete activity

delete / other sel activity

associate Associate act with diag mode

WF diagram active other

sel diag / other

Activity selected

Associate activity with diagram

Figure 7.16: STD: Activity operations

7.7 Work ow types and functions add trigger

53 sel begin act

WF diagram active

sel end act

Add trigger mode

Beginactivity selected

other

Input trigger data

Add trigger

other ok / cancel upd trigger

sel trigger WF diagram active

Update trigger data

Trigger selected

Update trigger

other commit / cancel upd trigger sel trigger WF diagram active

Trigger selected

Delete trigger

delete / other

Figure 7.17: STD: Trigger operations

Type

Function

Usage

Figure 7.18: Notation of signature graphs [MacLennan, 1990] are given, to have an overview of which work ow types exist and which functions (methods) use them. The notation of a signature graph is shown in gure 7.18. For example (see gure 7.19), a type (double rectangular box) is 'elem' and 'list', and a function (single rectangular box) is 'new elem' and 'append'. The function 'new elem' creates (outgoing arrow) an 'elem', and the function 'append' needs an 'elem' and a 'list' (incoming arrow) to insert the 'elem' to the 'list' (outgoing arrow). In short, inputs and outputs of a certain type, to and from functions, are represented by signature graphs.

7.7.1 List operations For a list the following functions are needed:

New list: to create and initialise a new list. New element: to create and initialise a new list element. Append: to insert an element after the last element in the list. Prepend: to insert an element before the rst element in the list. Detach: to delete an element belonging to the list. FirstThat: to nd the rst elment that satis es a certain condition. ForEach: to apply a function to every element in the list.


54 Boolean

CondFunc

IsEmpty

Append / Prepend / Detach

New list

DelList

List

ForAllNext

New elem

Elem

IterFunc

Length FirstThat

ForEach

Function

Integer

Params

Figure 7.19: Signature graph of list part

ForAllNext: to apply a function to the elements starting from a certain element until the

end of the list. Delete list: to delete every element of the list and the list itself. Is empty: to determine if a list is empty (does not contain any element). Length: to know how many elements are contained in a list.

In gure 7.19 the signature graph of the list part is given.

7.7.2 Work ow operations For a work ow the following functions are needed:

New work ow: to create and initialise a new work ow. New work ow diagram: to create and initialise a new work ow diagram. Delete work ow diagram: to delete a work ow diagram with all its objects in it. Find work ow diagram: to nd a work ow diagram in work ow data. Load work ow: to load work ow data from its external representation to its internal representation.

Save work ow: representation.

to save work ow data from its internal representation to its external

7.7 Work ow types and functions

55

New activity: to create and initialise a new activity. Add activity: to add an activity to a work ow diagram. Delete activity: to delete an activity from a work ow diagram. Update activity: to update the properties of an activity. Find activity: to nd an activity in a work ow diagram. Associate activity: to associate a complex activity with a work ow diagram. In this way

hierarchy is formed. New trigger: to create and initialise a new trigger. Add trigger: to add a trigger to a work ow diagram. Delete trigger: to delete a trigger from a work ow diagram. Update trigger: to update the properties of a trigger. Find trigger: to nd a trigger in a work ow diagram.

In gure 7.20 the signature graph of the work ow part is given.


56

New workflow Delete WF diagram

New WF diagram

Workflow Load workflow Save workflow

Find WF diagram

Workflow file

Workflow diagram

Delete trigger

String

Find activity

Add activity

Associate (complex) activity

Delete activity

Add trigger

New trigger

Trigger

Update trigger

Activity New activity

Update activity

Figure 7.20: Signature graph of work ow part

Find trigger

Chapter 8

Technical design 8.1 Introduction In this chapter, rst relations that exist between internal work ow data and other parts of the tool are discussed. Then the classes that constitute the internal work ow data representation are discussed. After that, the external representation is detailed using EBNF, and its relation with the internal data is given. The user interface is discussed, looking at layout aspects, screens, and its relation with the internal work ow data. Alternatives to realise the knowledge-based system interface are discussed, and one is chosen. Pseudo-code is given of the editor parts of the tool. Implementation issues conclude this chapter.

8.2 Relations of work ow data The work ow data structure, being the internal representation of work ow data, relates to:

a work ow language, the external representation of work ow data. graphs, the graphical representation of work ow data. petrinets, the dynamic behaviour of trigger models [Joosten, 1994a]. These relations are depicted in gure 8.1. The work ow data structure, the language, the graphs and the petrinets are called the syntax. The relations between each syntax are called the semantics. In the sections 8.4 and 8.5 the relations between the internal work ow data and the external representation, and the graphical representation are discussed. The relations with petrinets fall outside the scope of this thesis (for a discussion see [Joosten, 1994a]).

8.3 Internal work ow data In the following subsections, tables are given of the elds of all the list and work ow classes needed, and the type of each eld. 57

8. Technical design

58 WF data structure

Graph

WF language

Petrinet

Figure 8.1: Syntax and semantics of work ow data

8.3.1 List related classes The types seen in section 7.7.1 that constitute the classes of a list can be seen in a detailed form in the tables below. Class: Field next prev

Elem Type Elem pointer Elem pointer

Class: Field rst last

List Type Elem pointer Elem pointer

8.3.2 Work ow related classes The types seen in section 7.7.2 that constitute the classes of a work ow can be seen in a detailed form in the tables below. They are given divided, according to the perspectives of section 4.3. The classes that inherit from class 'Elem' are to be inserted in a list. For example, class 'Activity' inherits from class 'Elem' because a list of activities is maintained by the class 'Diagram'.

Control perspective Class: Inherits from: Field id name responsible Class: Inherits from: Field subdiagram

Activity Elem Type string string role

Complex Activity Type Diagram pointer

8.3 Internal work ow data

59

Class: Inherits from: Field activity type performer added value performing mode supporting tools batch size capacity work division average processing time deviation in processing time average completion time deviation in completion time arrival pattern

Atomic Activity Type 'proc, dec, ver, doc, comm, trans, time' role 'low, medium, high' 'automatic, manual, mixed' string number number string distribution function number distribution function number distribution function

Class: Sync Inherits from: Activity Field Type no own elds Class: Inherits from: Field id from to probability condition

Trigger Elem Type string Activity pointer Activity pointer number string

Organisational perspective Class: Inherits from: Field id name Class: Field id name actors Class: Field id name actors

Actor Elem Type string string

Role Type string string list

Organisation unit Type string string list

8. Technical design

60 Class: Field id name actors

Group Type string string list

Class: Field id name

Object Type string string

Data perspective

Class: Inherits from: Field id name

Elementary data object Elem Type string string

Class: Inherits from: Field id name elem. data obj. Class: Field id name documents

Document Elem Type string string list Folder Type string string list

Flow of data perspective Class: Field id name

Store Type string string

Editor speci c Class: Inherits from: Field id name activities triggers

Diagram Elem Type string string list list

8.4 External work ow data

61

Class: Field id name diagrams

Work ow Type string string list

8.3.3 Rules In [Medina-Mora, 1992] is mentioned that rules must hold for a work ow. Also for the conceptual model of section 4.3 rules exist that must hold. They are already described in that section.

8.4 External work ow data When using an interactive tool, a user wants to be able to save the current state of the system and be able to restart later with exactly the same con guration. This means that some, or all of the tool's internal data structure must be saved in long persistent storage in some external representation that can be reloaded later. Persistence is needed, meaning that the internal data structure is preserved beyond the execution of the programme [Paulisch, 1993].

8.4.1 Methods to achieve persistence The two main alternatives for the storage of persistent data are text les and databases. Below advantages and drawbacks are described. Advantages of using text les or databases, for the external storage of work ow data, are:

Advantages of using text les are:

{ Platform, language and programme independency. Every platform has a lesystem. { Text les can be easily edited by the user 1. { Text les can be easily exchanged (for example via e-mail).

Advantages of using databases are:

{ Concurrency and high reliability. Sharing is possible by several programmes or users. { Data are accessible with standard database tools. For example, it is possible to use query languages like SQL to do operations on data.

Drawbacks of using text les or databases, for the external storage of work ow data, are:

Drawbacks of using text les are:

{ Dierent methods must be used to generate the textual representation of each data

type. { Any solution on textual attening must address the issue of how pointer variables are represented. { Diculty to represent graphical objects externally. 1

It may not be desirable however

8. Technical design

62

Drawbacks of using databases are:

{ Platform dependency. { Database dependency. { Is a complex solution, if the tool using it is rather simple in nature.

Files are chosen for the external storage of work ow data, because:

of the required platform independency. a textual representation is easy to edit using a text editor. For example, making a global

substitution or changing names to upper- or lower-case, are very easy using a text editor. even if it is a simple solution it is satisfying for the Scarabaeus tool.

8.4.2 Extended BNF The syntax of the textual representation of the work ow data can be described by the EBNF (Extended Backus-Naur Form) notation. EBNF uses the conventions as described in table 8.1. Similar descriptions, with regard to work ow, can also be found in [van Hattum, 1994] and [Lee et al., 1994]. E* E+ [E] E | F E F (E)

sux * sux + rectangular brackets in x bar juxtaposition parentheses

zero or more occurrences of E one or more occurrences of E zero or one occurrence of E either E or F E followed by F conventional bracketing

Table 8.1: EBNF conventions The syntax is de ned by specifying the terminal symbols, non-terminal symbols, the starting symbol and production rules. The terminal symbols with their representations are de ned as follows: arr_symb atom_symb batch_symb comm_symb cplx_symb cplxty_symb ctim_symb ctimvar_symb cond_symb dec_symb diag_symb doc_symb end_wf_symb exttrig_symb from_symb

= = = = = = = = = = = = = = =

"ARRIVAL" "ATOM" "BATCH" "COMMUNICATION" "COMPLEX" "COMPLEXITY" "COMPL_TIME" "COMPL_TIME_VAR" "CONDITION" "DECISION" "DIAGRAM" "DOCUMENTATION" "END_WORKFLOW" "EXTERNAL_TRIGGER" "FROM"

8.4 External work ow data has_sub_symb prob_symb proc_symb ptim_symb ptimvar_symb resp_symb sync_symb tmp_symb time_symb to_symb trans_symb trig_symb tp_symb ver_symb wf_symb 0_symb ... 9_symb a_symb ... z_symb A_symb ... Z_symb undersc_symb punct_symb

63 = = = = = = = = = = = = = = = =

"HAS_SUB" "PROBABILITY" "PROCESSING" "PROC_TIME" "PROC_TIME_VAR" "RESPONSIBLE" "SYNC" "TEMP" "TIME" "TO" "TRANSPORTATION" "TRIGGER" "TYPE" "VERIFICATION" "WORKFLOW" "0"

= "9" = "a" = "z" = "A" = "Z" = "_" = "."

The non-terminal symbols are: activity diagram digit external identifier letter number trigger workflow

The starting symbol is: workflow. Now the production rules are discussed. Examples are given of the rules. The examples are derived from the 'complaint work ow' as described in [Joosten, 1994a]. A workflow and a diagram are de ned as: workflow ::= wf_symb identifier diagram+ end_wf_symb diagram ::= diag_symb identifier ( activity resp_symb identifier | trigger | external )*

8. Technical design

64 Examples of a workflow and of a diagram are: WORKFLOW Complaint_Workflow DIAGRAM Complaint_Workflow_Diagram ... DIAGRAM Analysis_Workflow_Diagram ... END_WORKFLOW

An activity is de ned as: activity ::= sync_symb identifier | atom_symb identifier tp_symb ( proc_symb | dec_symb | ver_symb | trans_symb | doc_symb | comm_symb | time_symb ) [ cplxty_symb identifier ] [ ptime_symb number ] [ ptimvar_symb number ] [ ctim_symb number ] [ ctimvar_symb number ] [ arr_symb number ] [ batch_symb number ] | tmp_symb identifier | cplx_symb identifier has_sub_symb identifier

Examples of an activity are: SYNC execute_solution RESPONSIBLE manager ATOM complain TYPE communication ... RESPONSIBLE customer TEMP file_complaint RESPONSIBLE representative COMPLEX analysis HAS_SUB Analysis_Workflow_Diagram RESPONSIBLE inspector

There are two possibilities for a trigger: either it is a trigger only on one level in the work ow diagram hierarchy (then it is a trigger), or it is a trigger on dierent levels (then it is an external). A trigger and an external are de ned as:

8.4 External work ow data

65

trigger ::= trig_symb identifier from_symb identifier to_symb identifier [prob_symb number] [cond_symb number] external ::= exttrig_symb identifier ( from_symb identifier | to_symb identifier)

Examples of a trigger and an external are: TRIGGER trig0 FROM complain TO file_complaint TRIGGER trig3 FROM analysis TO summarise EXTERNAL_TRIGGER trig2 TO anal_wait EXTERNAL_TRIGGER trig3 FROM produce_report

A letter, digit, identifier and number are de ned as: letter ::= a_symb | ... | z_symb | A_symb | ... | Z_symb digit ::= 0_symb | 1_symb | ... | 9_symb identifier ::= letter ( letter | digit | undersc_symb )* number ::= digit [ [ punct_symb ] digit+ ]

8.4.3 Relations between external and internal work ow data The correspondence that exists between external and internal work ow data, can be seen in table 8.2. In this section is discussed, how work ow data must be imported from its external representation, and how it is exported to it.

8. Technical design

66

External work ow data Internal work ow data activity Atomic, Complex, and Sync Activity trigger and external Trigger diagram Diagram workflow Work ow Table 8.2: Correspondence between external and internal work ow data

Importing data When workflow is recognised a new work ow must be created. When diagram is recognised a new diagram must be created. When activity is recognised, there are four possibilities: A sync has been recognised, a synchronisation activity must be created. A atom has been recognised, an atomic activity must be created. A temp has been recognised, a complex activity having no subdiagram must be created. A complex has been recognised, a complex activity must be created. When trigger is recognised, a trigger between the two speci ed activities must be created. When external is recognised, there are two possibilities: from, a trigger from an activity goes to a higher level. A trigger must be created having only the from part de ned. to, a trigger from a higher level goes to an activity. A trigger must be created having only the to part de ned.

Exporting data The beginning is with the class 'work ow'. All properties of the 'work ow' must be written to a le. Then foreach 'diagram', its properties and the 'activity' and 'trigger' list must be written. If a complex activity has no sub diagrams de ned, it becomes temp otherwise it is complex. If a 'trigger' has only one reference to an 'activity, it becomes an external, otherwise it is trigger.

8.4.4 Compiler generator tools To prevent building mechanisms to import work ow data, compiler generator tools like Lex and Yacc are used as described in [Aho et al., 1986] and [Mason and Brown, 1990]. Exporting the internal work ow data to its external representation is easier than importing, and does not require any additional tools other then the programming language itself.

8.5 User interface As mentioned in section 5.4, it is necessary to use a user interface toolkit. This to overcome the drawbacks of a programming language, in which all parts of the tool have to be build manually. Building the entire user-interface ourselves is very time consuming and falls outside the scope of the project. The user interface toolkit of Tom Sawyer [Tom Sawyer, 1994], in which several layout algorithms are implemented and tested in practice will be used for the user interface of the Scarabaeus tool.

8.5 User interface

67

Concept Atomic activity Complex activity Synchronisation activity

Symbol Circle Rectangle Triangle

Table 8.3: Trigger model concepts and symbols

8.5.1 Layout aspects As described in [Paulisch, 1993], the aesthetics of a graph measure how good the appearance of the graph is. Some aesthetics discussed in literature are: 1. Minimise edge crossings Place nodes and edges such that the number of edge crossings is minimised. 2. Hierarchical Maximise the number of edges that point in the same direction. 3. Maximise symmetry Display symmetry inherent in the drawing. 4. Uniform edge length Place nodes and edges such that all edges are of approximately equal length. 5. Uniform node distribution Place nodes such that the spacing between nodes is approximately equal. 6. Isomorphic subgraphs Subgraphs with the same structure should always be displayed alike. The Tom Sawyer software oers three ways of automatic layout:

hierarchical layout (supports aesthetic 2), symmetric layout (supports aesthetic 3, 4 and 6), and circular layout (supports aesthetic 5). All three support aesthetic 1. The Tom Sawyer software does not handle constraints speci ed by the user. Columns of the trigger model are an example of such a constraint. Because columns are an important part of the trigger model, and the columns may not get lost during an automatic layout, the given layout algorithms need to be adapted. (However, this has a low priority.)

8.5.2 Screens An example screen of the editor is given in gure 8.2. An overview of the screens of the work ow editor is given in gure 8.3. Symbols used for the trigger concepts are described in table 8.3. Menus that should at least be oered by the tool, are given in table 8.4. The 'create' and 'update' menu option, must have 'diagram', 'activity' and 'trigger' as suboptions. Also a toolbar can be oered, which contains several shortcuts to menu entries.

8. Technical design

68

Figure 8.2: Example screen of the editor

Shell screen

Workflow tool

Organisation editor

Activity dialog screens

Trigger editor

Trigger dialog screens

Flow of data editor

Data editor

Diagram screens

KBS dialog screens

Figure 8.3: Screens of the work ow design tool

8.6 Knowledge-based system interface

69

Main menu File

Sub menu new open save exit Edit undo cut paste create update delete move Improvement check syntax errors check design errors streamline work ow Layout hierarchical circular symmetric Help Table 8.4: Menus of the tool Graphs Node Edge sub graph all graphs

Internal work ow data Atomic, Complex, and Sync Activity Trigger Diagram Work ow

Table 8.5: Correspondence between graphs and internal work ow data

8.5.3 Relations between graphs and internal work ow data The correspondence that exists between graphs and internal work ow data, can be seen in table 8.5. Every time a user wants to create a new diagram, a (sub) graph is created to hold the nodes (representing activities) and edges (representing triggers) of a diagram. All graphs together represent the work ow. Every time a user creates an activity in a diagram, he places a node on the drawing area. The node is added to the current graph, and the activity and its properties are added to the work ow data. Every time a user creates a trigger, he places an edge between two nodes on the drawing area. The edge is added to the current graph, and the trigger and its properties are added to the work ow data. When the user wants to detail a complex activity (node), he creates a new diagram (graph) associated with the complex activity (node).

8.6 Knowledge-based system interface 8.6.1 Interface alternatives The knowledge-based system needs problem speci c data that are entered by the user through the editor. This data consists of a work ow model, objectives, and preconditions. On the other hand,

8. Technical design

70

the editor needs to present the results of the knowledge-based system to the user. The exchange of information between the editor and the knowledge-based system can be direct, semi-direct, or indirect.

Indirect case The communication between the editor and the knowledge-based system takes

place using external storage, i.e. les or a database. Each time a model of a work ow must be diagnosed, the internal work ow data is written to external storage (in the form of frames, the internal representation of the knowledge-based system). The knowledge-based system imports the data, uses them and writes the results back to external storage. The results are imported by the editor.

Semi-direct case The editor does not have to create a frame structure. It only generates a list

of commands that should be executed by the knowledge-based system. Possible commands are: create frame, delete frame, change the value of a certain slot of a frame. The commands can be transported to the knowledge-based system by using external storage, or by means of messages if the editor and the knowledge-based system can run in parallel. Each time the user wants to diagnose the model, the commands to change the frame structure with respect to the previous time the model was diagnosed, are communicated to the knowledge-based system in stead of a fully new frame structure.

Direct case The editor and the knowledge-based system both operate on the same internal data

structure. No information has to be transferred explicitly. This approach is only possible if the editor and the knowledge-based system are compiled together.

The choice of whether direct, semi-direct, or indirect communication is used, has his in uence on the way the class frames and possible operations must be encoded. Because the tool is also developed for MS-Dos/MS-Windows, parallel execution of a 'knowledgebased system task' and an 'editor task' is not easily possible. But in that case, the knowledge-based system has to be started every time the user wants to analyse his model. The use of a command le with changes of the frames with respect to the previous analysis is only useful if the model is big. Otherwise, the editor could as well write a new le with the actual frame structure. Indirect communication and semi-direct communication using a le or database are always possible.

8.6.2 Interface choice The direct case is preferred, having one executable that contains the editor and the knowledgebased system, because:

no inconsistency exists between the internal data structure and whatever temporary le used by the other solutions.

it does not require import and export facilities for the knowledge-based system. the tool will have a better performance, because only the needed part of a knowledge-based system will be used and it will be entirely written in the same programming language as the editor.

the knowledge-based system is reduced to function calls, instead of having parallel processes and handling communication between these processes.

8.7 Pseudo-code

71

Keyword WHILE (expr) IF (expr) THEN ELSE RETURN (expr) a=b

Meaning repeat 0 or more times depending on 'expr' repeat 0 or 1 time depending on 'expr' if 'expr' of if evaluates true, execute code if 'expr' of if evaluates false, execute code output 'expr' of a function assignment of value b to variable a

Table 8.6: Pseudo code keywords and meaning

8.7 Pseudo-code In this section pseudo-code is given of the work ow editor. The functions described, are derived from section 7.7.1 and 7.7.2. The input and output of the functions was given by means of a signature graph. Therefore the input and output will not be discussed in this section, except if necessary for clearness. Keywords are written in capital letters. The meaning of the keywords can be found in table 8.6.

8.7.1 List related The functions of a list as described in section 7.7.1 are discussed here in the form of pseudo code.

New list Initialise first and last pointer

New element Initialise prev and next pointer

Append IF NOT is_empty(list) THEN use last to insert at end of list ELSE use first and last to insert

Prepend IF NOT is_empty(list) THEN use first to insert at begin of list ELSE use first and last to insert

Detach

8. Technical design

72 handle prev pointer of element handle next pointer of element delete element physically

FirstThat starting element is first WHILE (list has not reached end AND NOT elem_found) IF condition_function holds(element, params) THEN elem_found = current element get next element RETURN elem_found

ForEach starting element is first WHILE (list has not reached end) apply iter_function(element, params) get next element

ForAllNext starting element is element passed as parameter WHILE (list has not reached end) apply iter_function(element, params) get next element

Delete list starting element is first WHILE (list has not reached end) detach(current element) get next element delete list physically

Is empty RETURN (first pointer refers to an element?)

Length starting element is first initialise length with 0 WHILE (list has not reached end) raise length with 1 get next element RETURN length

The ForEach, FirstThat and ForAllNext functions, are very powerful, because there will be no loops needed in the code that uses these functions. In this way list traversal become super uous, and the readability of the code is improved.

8.7 Pseudo-code

73

8.7.2 Work ow related The functions of a work ow as described in section 7.7.2 are discussed here in the form of pseudo code.

New work ow initialise properties of workflow (e.g. name) initialise diagram list

New work ow diagram initialise properties of diagram (e.g. name) initialise activity list initialise trigger list

Delete work ow diagram delete activity list delete trigger list delete diagram physically

Find work ow diagram input diagram to find diagram = use firstthat to locate diagram RETURN(diagram)

Load work ow input filename to load open file call yyparse function generated by yacc close file

Save work ow input filename to load open file write workflow properties use foreach to write diagrams, activities and triggers close file

New activity input properties of (atomic, complex or sync) activity

8. Technical design

74

Add activity append activity to activity list

Delete activity WHILE activity has related triggers delete related trigger using firstthat detach activity

Update activity input updated properties

Find activity find activity using firstthat

Associate activity has_sub of complex activity = diagram pointer

New trigger input properties of trigger

Add trigger append trigger to trigger list

Delete trigger detach trigger from trigger list

Update trigger input updated properties

Find trigger find activity using firstthat

8.8 Implementation issues

75

8.8 Implementation issues 8.8.1 Hard- and software requirements Operating systems that are supported are MS-Dos/MS-Windows and Unix. In this section the needed software and hardware will be mentioned. Needed software for MS-Dos/MS-Windows: Tom Sawyer's graph editor toolkit. This is used for the graphical user interface. Borland C++ 4.02. The graph editor toolkit is build with borland C++ version 4.02. Compiler generators like Yacc and Lex. Needed software for Unix: C++ compiler. Compiler generators like Yacc and Lex. Needed hardware for MS-Dos/MS-Windows: The graph editor requires about 10 megabyte of disk space. Borland C++ 4.02 requires about 80 megabyte of disk space. Because of the size of the graph editor (2.3 million rules of C++ code), it is comprehensible to have 486 personal computer with 16 megabyte of memory. (A test to compile the graph editor with 4 megabyte of memory took 5 hours.) No special hardware requirements are needed for Unix. Literature that will be used for C++ programming: [Ellis and Stroustrup, 1992], [Lippman, 1992], [Stoustrup, 1993], and [van Winkel and Willems, 1993]. And also the Borland C++ manuals. First a prototype is made on Unix (without a graphical user interface) of the kernel of the work ow design tool. At the same time it is 'ported' to MS-Dos/MS-Windows. This approach is chosen because the needed software for MS-Dos/MS-Windows was not available, when the implementation phase started.

8.8.2 Compiler generator tools In order to read a work ow, from le to its internal representation, a compiler has to be build. For this purpose tools like Lex and Yacc, are used according to [Aho et al., 1986]. In section 8.4.2 the EBNF grammar is given, that forms the syntax of a work ow le. Yacc allows to install calls to application-de ned routines at any point in a BNF grammar. These calls are embedded in the generated compiler, and whenever the generated compiler meets a sentence in the language, the appropriate routine calls are made. How Lex and Yacc are used can be seen in gure 8.4. In our case, the names in the gure stand for: Lex and Yacc are object oriented (like lex++ and yacc++ on Unix), because C++ calls are needed. The C compiler is a C++ compiler (like CC on Unix and Borland C++ on MS-Dos). The 'new compiler' is not stand-alone, but it is part of the work ow tool. The input is a work ow le, and the output is the internal data structure.

8. Technical design

76

Lex specification

LEX

lex.yy .c

Yacc specification

YACC

y.tab.c

lex.yy .c y.tab.c

C Compiler

New Compiler

input

New Compiler

output

Figure 8.4: Creating a compiler with LEX and YACC

Chapter 9

Scarabaeus tool evaluation 9.1 Introduction This chapter, rst gives an insight into the current situation in which the Scarabaeus work ow design tool resides. After that, an overview is given of work that has to be done, including priorities. An evaluation plan for test purposes concludes the chapter.

9.2 Current situation of the work ow design tool As described in section 7.5 the constituting parts of the tool are:

a user interface, internal work ow data, means to handle work ow data, external work ow data, means to import and export work ow data, and a knowledge-based system, Based on these parts, and on the Unix and MS-Dos/MS-Windows platforms, the current situation is explained. An overview is given in table 9.1. Again is stated that only the trigger modelling part (control perspective) has been developed in a complete sense. The organisation, data, and ow of data perspective are only partially present in the tool. Everything indicated as nished, is meant in the sense of trigger modelling.

User interface

Until now, the user interface on the Unix platform is character based, it must be graphical. On the MS-Dos/MS-Windows platform, only a beginning was made with a graphical user interface using the Tom Sawyer software. The available Tom Sawyer software, supports only the MS-Dos/MS-Windows platform. Also Borland C++ supports only the MS-Dos/MSWindows platform. Status Unix: un nished, has to be made graphical. Status MS-Dos/MS-Windows: un nished. 77

9. Scarabaeus tool evaluation

78 Parts User interface Int WF data WF data handling Ext WF data Import/Export KBS

Unix character based ok ok ok both ok ok

Platform MS-Dos/MS-Windows graphical (partial) ok ok ok only export ok

Table 9.1: Overview of current implementation situation

Internal work ow data

The internal data structure is derived from the conceptual model, providing a good conceptual background for the tool. Much time was spent on the conceptual model. Concepts used by dierent experts and from literature have been combined into one model. The internal work ow data can be depicted as a platform independent part of the tool (represented by list and work ow classes). It was rst developed on Unix and then 'used' on MS-Dos/MSWindows. It works well on both platforms (without any modi cation). Status: nished.

Work ow data handling

This can also be depicted as a platform independent part of the tool (represented by operations on list and work ow classes). It was rst developed together with the internal work ow data on Unix and then 'ported' to MS-Dos/MS-Windows. It works well on both platforms (only some insigni cant adaptations were needed). Status: nished.

External work ow data

The EBNF of the work ow data is a good way to describe the syntax of work ow data in a text le. It is platform independent. Status: nished.

Import and export of work ow data

Importing work ow data has been achieved using compiler generator tools. There are several compiler generator tools available for both platforms. But unfortunately, none of these worked well with Borland C++ (they are mostly compiled for use with GNU C++). Therefore, import works only on the Unix platform. Exporting work ow data to its external representation is fully programmed in C++, and works well on both platforms. Status Unix: nished. Status MS-Dos: export nished, import has to be done.

Knowledge-based system

The knowledge-based is partially complete (see [van de Belt, 1995]), and works on both platforms. The interface between editor and KBS is complete, and works well on both platforms. Status: KBS partially complete, the interface is nished.

An overview of the products made is given in appendix B.

9.3 Work to be done

79

9.3 Work to be done The editor in its current situation is not complete. Work that must be performed to extend the Scarabaeus tool, is described below.

Graphical user interface

Building the graphical user interface on the MS-Dos/MS-Windows platform, must be continued using the Tom Sayer software. For the time being the Unix user interface remains character based. A new version of the Tom Sawyer software will also support the Unix platform. When this version is available, the user interface code can be 'ported' from MSDos/MS-Windows to Unix. This 'porting' job will be 'easy' if Borland C++ will support the Unix platform.

Import facility on MS-Dos platform

Because compiler generator tools like yacc++ and lex++ did not work together with Borland C++, other tools that are dedicated to (compiled for use with) Borland C++, must be looked for. Otherwise, the source code of the compiler generator tools (mostly public domain), can be examined, adapted, and compiled with Borland C++. Or, if nothing else works, the import facility for the MS-Dos/MS-Windows platform must be programmed manually in C++.

Support for the four perspectives on work ow

The internal work ow data in its current state contains classes for all four perspectives on work ow, as described in the conceptual model. The tool must be extended with an organisation editor, data editor, and ow of data editor. For this purpose, further research needs to be done in order to extend the conceptual model with attributes (and possibly other concepts), and to establish how needed (diagramming) techniques should interact with the user. The tool can be seen as one editor (and a KBS), oering dierent views on the internal work ow data, through several diagramming techniques. The user interface for new diagramming techniques, can also be realised with the Tom Sawyer software.

Testing the tool

For a description on how the tool has to be tested, see the next section.

Formalisation

A formal speci cation can be made, to give a mathematically precise de nition of the concepts and functions. This is useful for a precise understanding of the product. Such understanding is helpful for product comparison or to conduct a well informed discussion about the product. For this purpose a Z speci cation [Spivey, 1992] is appropriate, because this is a well known and powerful mechanism. Tools exist to check a Z speci cation for type inconsistencies, for example as described in [Jia, 1994].

Simulation/Animation support

An analysis must be made, in order to establish if simulation support contributes to work ow design. Then the tool can be extended with simulation/animation facilities. In section 4.3, in the control perspective, attributes are mentioned that are already incorporated in the tool for the simulation purpose.

The highest priority is assigned to the user interface task. Completing the user interface, makes it possible to test the tool in practice, and draw conclusions on the usefulness of the tool in general. In the mean time, research can be conducted, regarding the currently not supported work ow perspectives. After the user interface is ready and the tool is tested, the tool can be extended with the other diagramming techniques, and tested again. The import facility on the MS-Dos platform is also an important part, because without it, it is not possible to load previous saved work ow


80

data. Formalisation can be performed while carrying out the other tasks. Simulation/animation support has the lowest priority, because other work ow tools already provide such support (and none of the tools seem to provide knowledge-based support). Furthermore, the way in which a connection with work ow automation software can be established must be analysed. Because the software area is growing very fast, in the period that the Scarabaeus tool has been developed using C++, new tools have become available (for example, the meta-case tool Object Maker). Evaluating the (new) available software again, in the way it was done in chapter 5, is surely not super uous.

9.4 Evaluation plan In its current state, no evaluation on the tool has been done. This section presents an evaluation plan, which is to be executed once the tool is suciently complete.

9.4.1 Veri cation and validation The de nitions of veri cation and evaluation [Lewis, 1992], are:

Veri cation is an iterative process aimed at determining whether the product of each step in the development cycle:

1. ful lls all the requirements levied on it by the previous step; 2. is internally complete, consistent and correct enough to support the next phase.

Validation is the process of executing the software to exercise the hardware and comparing the test results to the required performance.

Veri cation and validation phases [Lewis, 1992] [DeMillo et al., 1987], are: requirements veri cation, design veri cation, code veri cation, and validation. In the next subsections, for each veri cation and validation phase, the tasks that must be performed are mentioned. Each phase, contains a task 'produce problem report' in which all problems encountered, in the tasks of a phase, are reported. During the project, some of the veri cation tasks were performed. Because a prototyping approach was chosen for the development, all the task can be performed (again) in the next cycle.

9.4.2 Requirements veri cation Tasks that must be performed are:

Verify work ow tool speci cations. Verify requirements speci cations. Produce problem report.

9.4 Evaluation plan

81

9.4.3 Design veri cation Tasks that must be performed are:

Verify editor design. Verify knowledge-based system interface design. Verify results of used techniques during design. Verify work ow data structure. Verify user interface:

{ Make an extensive, general list of requirements and test the user interface against

this list of requirements. In literature [Downton, 1991] [Eberts, 1994] [Galitz, 1993] [Shneiderman, 1992] [Thimbleby, 1990] very much requirements on the user interface are discussed. { Look at other work ow tools (see also appendix A). { Discuss the user interface with possible users of the tool. Verify used algorithms. Produce problem report.

9.4.4 Code veri cation Tasks that must be performed are:

Verify consistency between the code and the design. Verify consistency between the code and the work ow data. Verify sample input and output data. Verify algorithms. Produce problem report. 9.4.5 Validation Make a case description of a real world problem, and conduct experiments with involved experts and students, in order to obtain information on usability of the tool as a whole, the user interface, and the knowledge-based system. Tasks that must be performed are:

Preparation. Running experiments. Evaluate results. Produce problem report. For a description on conducting experiments, with regard to work ow tools, see [Boersma, 1994].

82


Chapter 10

Conclusions 10.1 Introduction The conclusions of the research described in this report are presented in this chapter. First the research results of the method engineering part are discussed. The results are related to the other two parts of the Scarabaeus project, and to the eld of work ow design. Recommendations for further research conclude this chapter.

10.2 Research results In this section the answers to the subordinate research questions, as presented in section 2.3.2, concerning the method engineering part of the project, are summarised. Answering these questions provides an answer to the principal research question of the method engineering part of the project. We can also conclude that the research approach for the method engineering part of the project, as presented in section 2.3.3, provides a solid basis to answer the research questions. Question: What is work ow design knowledge? Work ow design knowledge consists of three elements. Firstly, the process used to design a work ow consisting of a number of tasks to be performed. These tasks were described in the chapters 3 and 4. Secondly, the concepts necessary to describe the work ow design, and problemsolving concepts necessary to make statements about it. The concepts, their structure, and their relations were described in the conceptual model in section 4.3. The concepts were grouped into ve perspectives: 'control', 'organisational', 'data', 'data ow', and 'problem-solving'. Thirdly, the set of rules that is used to combine the concepts in order to nd design errors and possibilities for optimisation in a work ow model (see [van de Belt, 1995]). Question: Do existing work ow or related tools support work ow design, taking into account the Scarabaeus requirements? Contemporary work ow or related tools, as described in section 5.3.1, do not meet the requirements that were posed in section 5.2. This resulted in looking at other possibilities to realise a work ow design tool that meets the requirements. A distinction was made between the realisation possibilities: CASE tools, Meta-CASE/CAME tools, and a programming environment. The choice made was to develop a new work ow design tool (section 5.4) using a programming environment, supported by a user-interface toolkit and other tools, to overcome (part of) the drawbacks of a programming environment, and to facilitate the building of the tool. 83

84

10. Conclusions

Question: What functionality should a work ow tool oer with regard to work ow design? Four diagramming techniques were distinguished: trigger modelling, organisation modelling, data modelling, and ow of data modelling (section 7.2). This was done according to the control, organisational, data and data ow perspective (section 4.3). The functional aspects of the graphical work ow design editor, with regard to: internal and external work ow data, graphical functionality, diagram hierarchy, knowledge-based system, and general aspects were described (section 7.3). Data ow diagrams were used to distinguish components of the tool (work ow data handler, import and export handler, knowledge-based system, and user interface) and to describe how they interact with each other (section 7.5). Question: How should a work ow tool interface with the user? The theory on user interfaces was discussed in chapter 6. A graphical user interface was chosen, together with the dialog styles: menus, form- lling, and direct-manipulation. The interaction between the user and the tool was modelled using state transition diagrams (section 7.6). Between several user interface toolkits (section 5.4.2), a choice was made for the Tom Sawyer graph editor, to be the basis for the user interface of the work ow design tool. Because graphs are a general way to represent information graphically, a graph editor is an appropriate choice. Question: How should a work ow design tool interface with a knowledge-based system? Three possible ways (indirect, semi-direct, and direct) to interface the tool with a knowledgebased system were discussed (section 8.6). The direct way was chosen, having one executable that contains the editor and the knowledge-based system, and the exchange of information via the shared internal data structure. This was done because of a better performance, simpli cation of the knowledge-based system (only needed KBS functionality, and only function calls instead of parallel processes), direct access to the internal work ow data for both parts (no inconsistency can exist between internal data and some temporary le). For this purpose the knowledge-based system was implemented using the same language as for the editor, namely C++. Question: Does formalised work ow design knowledge, used in a knowledge-based system, contribute to a work ow design tool? The design and the tool in its current state, indicate that it is technically possible to make a work ow design tool, with knowledge-based system support. However, as described in [van de Belt, 1995] the area of work ow design does not t too well in the range of areas for which knowledge-based applications have been developed until now. For example, streamlining a work ow is a very intuitive process. The current knowledge-based system is not very useful because of a limited set of rules. So, at this moment it is not possible to give a de nite judgement towards the suitability of knowledge-based system support for work ow design.

10.3 Project evaluation In this section the results of the method engineering part are related to the other two parts of the Scarabaeus project, and to the eld of work ow design.

10.3.1 Scarabaeus project The primary purpose of the Scarabaeus project was to support work ow designers. To this end a graphical work ow design tool had to be developed that makes use of a knowledge-based system. Because the design of work ows is a rather new eld of research, it caused several delays in the development of the graphical work ow design tool.

10.3 Project evaluation

85

Some diculties that were encountered are:

Little literature on work ow, work ow design, and work ow tools was available. Diculties in obtaining work ow tools. It was very dicult to get (good) demo software or

a trial licence. Diculties in obtaining tool speci cations, e.g. which underlying model is used, which concepts are used. This can be explained because companies do not want their knowledge to be available for everyone, because work ow is a new eld (some tools awake the impression that they do not have a good conceptual basis). Participants (external) did not have enough time. Delays in obtaining the software to realise the Scarabaeus tool (Borland C++ and the Tom Sawyer Software).

The collection of knowledge from empirical research and course material resulted in a set of design heuristics. Only few of these heuristics could be made operational so that they could be used in the knowledge-based system. Therefore, the contribution of the resulting knowledge-based system to the work ow design tool is small. However, the knowledge-based system can easily be extended if new design knowledge becomes available. Although the knowledge-based system itself is not very useful yet, the development of the knowledge-based system had its impact on the project. The knowledge required for the knowledgebased system, and for the editor, directed the elicitation of knowledge from work ow design experts by the empirical researcher. Furthermore, the conceptual model served as a basis for both the knowledge-based system and the editor. The performance of empirical research, building a tool and building a knowledge-based system at the same time did not seem to be the best approach. There was too much discussion on the basic concepts and the models used to represent a work ow. These concepts and models should be clear before research after knowledge-based support of the design of work ows is started. From the above stated, it seems that an alternate project approach could have lead to better results. For example, it could have been better if empirical research on the design of work ows had been done rst to create the basis for a theory. This research could have been done by a group of researches, eliciting knowledge from as many as possible experts. Information can be exchanged between the researchers to make the basis of the theory as complete as possible. Based on this theory, a graphical work ow design tool, comprising a knowledge-based system, can be developed. This does not mean that the approach used for the project was wrong. On the contrary, performing all three parts together ensured an intense co-operation between the three participants, resulting in a direct evaluation on practical usability of knowledge obtained by the empirical researcher. The knowledge was analysed directly by the other two members, and processed in order to be usable for a knowledge-based system and a graphical tool. Performing the tasks in a sequential way as suggested above, does not guarantee better results. For example, developing only a theory does not directly take into account the practical usability, and could deliver a theory that is unusable in a practical sense.

10.3.2 Work ow design The work ow design area is rather new. The usage of a knowledge-based system, for work ow design support, with the knowledge that is available at this moment seems not to be satisfying. Further research on work ow design is needed. But, the Scarabaeus tool, even without a

10. Conclusions

86

knowledge-based system, is usable. Using the tool in practice, makes it possible for the tool to evolve. Experience gathered by using the tool creates possibilities for further extensions, and one day even a very good knowledge-based support. Experts involved in the project had dierent point of views on work ow design. This made it dicult to obtain clear design heuristics, and formalise these, in order to be usable by a knowledgebased system. The tool should nd approval by the experts, meaning that the tool must oer the possibility to represent all things that contribute to work ow design, according to experts. The Scarabaeus project has contributed in the sense that the current situation of work ow design has been made explicit. Furthermore, the project has proven that it is (technically) possible to develop a tool, that supports work ow design, making use of a knowledge-based system. This must be a motivation for work ow tool builders to spend more time on this issue, than has been done until now. This can possibly result in building a tool based on the research that has been performed for the Scarabaeus project.

10.4 Recommendations We would like to give the following recommendations:

Conduct further research on the work ow design area. Perform the work to be done as described in section 9.3. Validate the tool (in practice). Analyse if simulation/animation support contributes to work ow design, and extend the

tool. Provide a connection with work ow automation software.

Appendix A

Investigation into existing tools A.1 Introduction This appendix contains an investigation into work ow (or related) tools, to be able to decide if contemporary tools can satisfy the Scarabaeus requirements.

A.2 Tools In this section an overview is given of existing tools. A distinction is made between work ow tools and BPR tools. For each tool the aspects: general, philosophy, concepts, components, user, design, management, and control, are discussed (if sucient information is available or can be obtained) according to [van der Harst, 1994].

A.2.1 Work ow tools Action Work ow Supplier: Ten Ham Informatiesystemen. Philosophy: An actionwork ow loop is distinguished, with always an identi ed customer and a performer. The loop proceeds in four phases:

Proposal / preparation:

The customer requests (or the performer oers) completion of a particular action according to some stated conditions of satisfaction. Agreement / negotiation: The two parties come to mutual agreement on the condition of satisfaction, including the times by which further steps will be taken. Performance: The performer declares to the customer that the action is complete. Satisfaction / acceptance: The customer declares to the performer that the completion is satisfactory. 87

A. Investigation into existing tools

88

The loop deals with a particular action that a performer agrees to complete to the satisfaction of a customer. The key dierence in this approach is the shift from the task structure to the coordination structure. Concepts and attributes are:

Work ow: name, type, customer, performer, observer, form name, conditions of satisfaction,

associated text. Phase: name, cycle time, value. Request connection set: number. Oer connection set: number. Request Connection Point: name, type. Oer Connection Point: name, type. Conditional link: id. State: type.

Components are: Analyst, Builder, and Manager. A full description can be found in [Medina-Mora et al., 1992] and [Geertsma, 1994].

ExSpect Supplier: Bakkenist / University of Eindhoven. ExSpect means executable speci cation tool. It is based on petri-nets. Petri-nets are used because of:

Ease of use, there are several other petri-net based tools. Good formal basis, needed for simulation. Choosing a standard on simulations. The extensions on the traditional petri-nets are:

Colour: tokens can be of a complex type. Time: every token gets a time stamp. Hierarchy: multiple layers of petri-nets can be modelled. Concepts of ExSpect are:

Channel. Processor. Directed connection. Token.

A.2 Tools

89

Store. Double oriented connection. Proces. Input connector. Output connector. Store connector. A processor is enabled if on every input channel there are enough tokens. A processor can re if it is enabled, this means that the processor consumes the tokens on his input channels and puts tokens on his output channel. A petri-net can be translated into a matrix, and from this matrix it is possible to derive invariants: place and transition invariants. Components of the tool are:

Shell. Graphical design interface. Type checker. Interpreter. Run-time interface(s). The user interface is graphical as well as textual. Interfacing with other applications is possible. Analysis methods:

Simulation. Place & transition invariants. Temporal analysis. Links with other tools. When simulating it is possible to use the animation facility, which visualises the simulation going on. Similar tools:

CPN design. PACE.


90

FlowMark Supplier: IBM. Provides a graphical interface for making process models. An animation facility helps you detect problems in models before they become problems in actual operations. Concepts of FlowMark are:

Activity: an activity represents a business action that is a semantical unit at a certain phase

of modelling eort. In general, an activity is associated with both input parameter types and output parameter types. Containers: { Output container: the collection of all output parameters. The results that are in general produced by an activity are put into an output container. { Input container: the collection of all input parameters. An activity will in general require to access output containers of other activities, each activity is associated with an input container. Control connectors: since activities might not be executed arbitrarily they are bound together via control connectors. An edge represents the potential control ow from one activity to another. Transition conditions: boolean functions are associated with each edge that connects two activities. Exit conditions: boolean functions are associated with each node. Synchronisation conditions: an activity having more than one incoming edge can function as a 'join'. For that purpose a boolean expression is associated with each activity in the boolean functions that weight the incoming edges of the respective activity. Data connectors: a directed edge pointing from a particular parameter type of an activity's output container to a particular parameter type of another activity's input container may be speci ed. Tasks.

An extensive discussion can be found in [Leymann and Altenhuber, 1994].

FlowPATH Supplier: Bull. Philosophy: FlowPATH is meant to support organisations, to organise and automate routine business processes and communication. Concepts of FlowPATH are:

Procedure: a prede ned set of work steps and a partial ordering of these steps.

Dierent steps of a procedure may be executed by dierent people or dierent groups of people. In some cases several steps of a procedure may be executed at the same time or in any order which is why a procedure is said to be a 'partially ordered' set of steps. Partial ordering means that all steps do not necessarily need to be executed sequentially and that loops are allowed.

A.2 Tools

91

Activity:

is the body of a work step of a procedure. An activity is a basic unit of work which must be a set of actions carried out by a single actor. An activity is a reusable unit of work, so one activity may be the body of several work steps. An activity can have one of three modes. Some work step activities may be automatically executed (automatic mode), some completely manual (manual mode) and some may require the interaction of people and computers (mixed mode). Role: a role is a named designator for an actor or a grouping of actors. Thus instead of naming a person as the executor of a work step, we can specify that it is to be executed by a given role. Actor: an actor is a person or computer system that can ful ll roles to execute and/or be responsible for activities of procedures. To cater for possible absence, etc. an actor (person) can have a named substitute within the FlowPATH system. Workcase: a workcase is a job owing through the system. A workcase has at any instant a 'state' which is denoted by one or more activities being performed on it. Task: is the combination of a workcase and an activity. Exception: an exception is an unanticipated event in the ow of a workcase for which a dynamic change in the normal process is required. This may involve skipping a task, reassigning a task to another actor or cancelling a workcase.

The model that is used within FlowPATH for the speci cation of procedures is called the Information Control Net (ICN), a simple but mathematically rigorous formalism created to model oce procedures [Ellis, 1979]. Components are: Data management module, Scheduler module, Dispatcher module, Messagebox module, Noti er module, Coordinator module, Administrator module, Activity execution module, and User interface module. Further, there is the MOBILE graph editor, which is a graphics interactive tool for work ow analysis (procedure description, testing, process simulation) and the creation of procedures.

InConcert Supplier: Xerox. Has a graphical work ow editor, which permits a graphical object-oriented work ow de nition.

OPEN/Work ow Supplier: Wang. Philosophy: OPEN/Work ow is a tool to manage business processes, and to improve the productivity and quality. Concepts:

Cases: are running processes. Tasks: are the basis pieces of work. Participants: the actors that perform tasks.


92

StaWare Supplier: Staware. Is a work ow implementation tool. One part of staware is EXIT (external interfaces). It contains an external case start, which allows other applications to automatically start o a staware procedure and pass data to it.

TeamFlow Supplier: ICL. Philosophy: TeamFlow is part of TeamOFFICE, a collection of groupware applications. Major objectives are: time gain and productivity increase. Concepts: TeamFlow is based on sending electronic messages (the work ow case). Components are:

Supervisor tool. Case plan editor. Case editor. Folder application.

WorkParty Supplier: Siemens Nixdorf. Philosophy: Open tool to support administrative processes. Concepts: The organisation model contains:

Organisation unit. Workplace. Person. Group. Authorisation.

There is also a process model.

Other work ow tools

ECHO from Digital Equipment/Philips EPIC/WORKFLOW from Computron Technologies Europe FLOWARE from Recognition Equipment TEAMROUTE from Digital Equipment POWERFLOW from ICL PROCESIT from NCR/Recognition Equipment Visual WorkFLO from Olivetti/FileNet. WORKMANAGER from HP

A.2 Tools

93

Imaging tools The following tools are not pure work ow products, they have to do with image processing:

DOC from Borsu Systema. Event Manager from Unisys. FYI Work ow from Logisterion Automatisering/IdentiTech: Has an information manage

ment system that allows users to create, store and route documents. ImagePlus from IBM: Imaging (electronic representation) and document management. KeyFile from Borsu Systema: Imaging (electronic representation) and document management.

A.2.2 BPR tools In [Dale, 1994] an overview of tools for Business Re-Engineering tools is given. Here follows an overview of the key features of these tools.

APACHE Supplier: EDS Corporation. Supports the collection of information on processes with a pictorial language.

Business Design Facility (BDF) Supplier: Texas Instruments. Process modelling, organisational modelling, data modelling, ow modelling, model object interaction using matrices, simulation and evaluation of existing and proposed designs, information engineering support, IDEF0 and IDEF1 support, model extensibility/customisation, model repository.

Business Improvement Facility (BIF) Supplier: Virtual Software Factory Ltd. Enabling and support for:

Design and redesign of business processes, manufacturing processes, technical processes. IT requirements. People/human resource requirements.

Caddie Supplier: Logica Cambridge Ltd. Object-oriented approach, support for explicit representations and use of organisational knowledge for modelling, support for sophisticated user de ned performance evaluation metrics, open distributed multi-user architecture, well suited to strategy analysis and business gaming.


94

IThink Supplier: High Performance Systems Inc. Graphical process simulation tool.

Object Management Workbench (OMW) Supplier: Intellicorp Inc. Full life cycle CASE tool with executable diagrams that is well suited to Business Process Engineering.

RADitor Supplier: Co-ordination Systems Ltd. An Activity Editor provides drawing business processes as Role Activity Diagrams.

SES/Workbench Supplier: Scienti c and Engineering Software. Behavioural modelling and simulation of systems and processes. Performance and dynamic visualisation.

TOP-IX Supplier: TOP-IX Ltd. Process analysis and design features:

Powerful process mapping. Top-down process decomposition. Process documentation. Value-added analysis. Cycle-time analysis. Human resources and costs directly linked to processes and volumes of business. Powerful RDBMS.

Appendix B

Scarabaeus products B.1 Introduction This appendix describes which documentation and software has been produced for the Scarabaeus project, and where it can be found.

B.2 Products B.2.1 Documentation Each member of the Scarabaeus project has written his thesis using LaTEX. The '*.tex' les can be found in the directory '.../scarab/tex'. The pictures used can be found in the directory '.../scarab/pic'. A postscript version of the reports can be found in the directory '.../WWW' as well as on World Wide Web (home page http://wwwis.cs.utwente.nl:8080/~ joosten/scarabaeus/scarabaeus.html). The literature that has been used during the project can be found in the le: 'scarab.bib'.

B.2.2 Software In table B.1 an overview is given of the les constituting the work ow tool. The contents of each le is shortly described. The les can be found in the directory '.../scarab/code'. On the MS-Dos/MS-Windows platform the extension of the C++ les is 'cpp'. The Tom Sawyer les that have been extended, in order to integrate the work ow code with the user interface code are:

in the 'docview' directory: appdefs, appdocvu, appgrfdc, appgrfvu, and appnvmgr. in the 'engine' directory: appedge, appgraph, appnode, and apppath. These les can be found in the directories: '.../tsget/extend/docview' and '.../tsget/extend/engine'. For the integration purpose the work ow les are also available in the directory: '.../tsget/extend/wf'. The le 'tsget.ide' is a sort of make le for Borland C++, and can be found in the directory: '.../tsget'. 95

B. Scarabaeus products

96

Files trigger.l trigger.y list.h list.c wf.h wf.c kbs.h kbs.c kbs.pl utils.h utils.c editor.c example.wf make le

Description LEX speci cation (for import) YACC speci cation (for import) class de nitions of list part function de nitions of list part class de nitions of work ow part function de nitions of work ow part class de nitions of KBS part function de nitions of KBS part prolog prototype of KBS part prototypes of some general functions de nitions of general functions character-based work ow editor (for Unix) example input work ow le of 'complaint work ow' use with 'make', to compile source code to executable Table B.1: Overview of Scarabaeus software

Bibliography [Aho et al., 1986] Aho, A., Sethi, R., and Ullman, J. (1986). Compilers; Priciples, Techniques, and Tools. Addison-Wesley Company, Reading, MA. [Batini et al., 1992] Batini, C., Ceri, S., and Navathe, S. (1992). Conceptual database design: An entity-relationship approach. The Benjamin/Cummings Publishing Company, Redwood City, CA. [Boersma, 1994] Boersma, P. (1994). Experimental research into usability and organizational impact of work ow software. University of Twente. [Born, 1994] Born, G. (1994). Apache: A pictorial case tool for business process engineering. In Spurr, K., Layzell, P., Jennison, L., and Richards, N., editors, Software Assistance for Buiness Re-Engineering, pages 65{79. Wiley. [Bots and Sol, 1987] Bots, P. and Sol, H. (1987). An environment to support problem solving. Decision Support Systems, 4(3):225{231. [Brinkkemper, 1993] Brinkkemper, J. (1993). Integrating diagrams in case tools through modelling transparency. Information and software technology, 35(2):101{105. [Curtis et al., 1992] Curtis, W., Kellner, M. I., and Over, J. (1992). Process modelling. Communications of the ACM, 35(9). [Dale, 1994] Dale, M. W. (1994). Business re-engineering: The business realities. In Spurr, K., Layzell, P., Jennison, L., and Richards, N., editors, Software Assistance for Business ReEngineering, pages 5{17. Wiley. [DeMillo et al., 1987] DeMillo, R., McCracken, W., Martin, R., and Passa ume, J. (1987). Software testing and evaluation. Benjamin/Cummings publishing company Inc., Menlo Park, California. [Downton, 1991] Downton, A. (1991). Engineering the Human-Computer Interface. Mc Graw-Hill, London. [Eberts, 1994] Eberts, R. (1994). User Interface Design. Prentice-Hall international, New Jersey. [Eilers, 1987] Eilers, H. (1987). Systeemontwikkeling volgens SDM. Academic Service, Den Haag. [Ellis, 1979] Ellis, C. (1979). Information control nets: a mathematical model of oce information

ow. In Proceedings ACM Conference on simulation, measurement, and modelling of computer systems. [Ellis et al., 1991] Ellis, C., Gibbs, S., and Rein, G. (1991). Groupware; some issues and experiences. Communications of the ACM, 34(1):39{58. [Ellis and Stroustrup, 1992] Ellis, M. and Stroustrup, B. (1992). The annotated C++ reference manual. Addison Wesley, New Jersey. 97

98

Bibliography

[Esakov and Weiss, 1989] Esakov, J. and Weiss, T. (1989). Data structures: an advanced approach using C. Prentice-Hall, Englewood Clis. [Fisher, 1988] Fisher, A. (1988). CASE, Using software development tools. Wiley, New York. [Galitz, 1993] Galitz, W. (1993). User-interface screen design. Wiley, New York. [Geertsma, 1994] Geertsma, W. (1994). Formalisation of the action work ow approach. University of Twente. [Gielkens, 1992] Gielkens, F. (1992). Klantgericht werken door de werkstroom te automatiseren. Kantoor en Eciency, 31(7/8):24{26. [Hales and Lavery, 1991] Hales, K. and Lavery, M. (1991). Work ow management software: the business opportunity. Technical report, Ovum Ltd, 7 Rathbone Street, London W1P 1AF, UK. [Hammer, 1990] Hammer, M. (1990). Reengineering work: Don't automate, obliterate. Harvard Business Review, pages 104{112. [Hawryszkiewycz, 1991] Hawryszkiewycz, I. (1991). Introduction to systems analysis and design. Prentice hall, Sydney. [Hickman, 1994] Hickman, L. (1994). Automating business process re-engineering with the business design facility. In Spurr, K., Layzell, P., Jennison, L., and Richards, N., editors, Software Assistance for Business Re-Engineering, pages 177{192. Wiley. [Identitech, 1993] Identitech (1993). Fyi work ow overview. Technical report, IdentiTech, Inc. [Jablonski, 1994] Jablonski, S. (1994). Functional behavioral aspects of process modeling in work ow management systems. In Chroust, G. and Benczur, editors, Work ow Management challenges, paradigms and products, pages 113{133. Oldenbourg. [Jia, 1994] Jia, X. (1994). ZTC: A type checker for Z, User's guide. [Joosten, 1994a] Joosten, S. (1994a). Trigger modelling for work ow analysis. In Chroust, G. and Benczur, editors, Work ow Management - challenges, paradigms and products, pages 236{247. Oldenbourg. [Joosten, 1994b] Joosten, S. (1994b). Werkstromen: een overzicht. Memorandum Informatica 94-78. [Joosten et al., 1994a] Joosten, S., Aussems, G., Duitshof, M., Humeijer, R., and Mulder, E. (1994a). Wa-12: an empirical study about the practice of work ow management. Technical report, University of Twente. Research monograph. [Joosten and Brinkkemper, 1995] Joosten, S. and Brinkkemper, J. (1995). Fundamental concepts for work ow automation in practice. University of Twente. [Joosten et al., 1994b] Joosten, S., Mulder, E., and McCrory, J. (1994b). Work ow literature guide. Report, University of Twente. [Kloos, 1994] Kloos, S. (1994). Design and implementation of the method base for a computer aided method engineering tool. University of Twente. [Kusters et al., 1992] Kusters, R., G.M.Wijers, and van Dort, H. (1992). Nieuwe ervaringen met case. Informatie, 35(Themanummer). [Lee et al., 1994] Lee, J., Yost, G., and the PIF Working Group (1994). The pif process interchange format and framework. PIF Working Group.

Bibliography

99

[Lewis, 1992] Lewis, R. (1992). Independent veri cation and validation: a life cycle engine ering process for quality software. Wiley, New York. [Leymann and Altenhuber, 1994] Leymann, F. and Altenhuber, W. (1994). Managing business processes as an information resource. IBM systems journal, 33(2). [Lippman, 1992] Lippman, S. (1992). Programmeren in C++. Addison Wesley, Reading, MA. [MacLennan, 1990] MacLennan, B. (1990). Functional programming: practice and theory. Addison-Wesley, Reading, Massachusetts. [Mason and Brown, 1990] Mason, T. and Brown, D. (1990). Lex & yacc. O'Reilly, Sebastopol, CA. [Medina-Mora, 1992] Medina-Mora, R. (1992). Book from action technologies. Chapter 4: Analist consistency checking. [Medina-Mora et al., 1992] Medina-Mora, R., Winograd, T., Flores, R., and Flores, F. (1992). The action work ow approach to work ow management technolo gy. In Turner, J. and Kraut, R., editors, Proceedings CSCW '92: Sharing perspectives, pages 281{288. ACM. [Merbeth, 1991] Merbeth, G. (1991). Maestro ii - the integrated case system of softlab. In Balzert, H., editor, CASE systeme und werkzeuge, volume 3e au age. BI Wissenschaftsverlag. [Merriam-Webster, 1963] Merriam-Webster, I. (1963). Webster's 7th Collegiate Dictionary. [Novius Adviesgroep voor Informatie & Organisatie, 1993] Novius Adviesgroep voor Informatie & Organisatie (1993). Beheersing van administratieve bedrijfsprocessen en de toepassing van work ow-management-systemen. Handout at Euroforum symposium. [Overbeek et al., 1994] Overbeek, J., Pottjewijd, P., Broekhuisen, H., and Spanho, G. (1994). Stroomlijnen van werkprocessen. DCE Nederland b.v. [Pallas Athena, 1993] Pallas Athena (1993). Algemene visie op werkstroombesturing. Bull Nederland N.V./Pallas Athena B.V. [Parry, 1994] Parry, M. (1994). Reengineering the business process. In White, T. and Fischer, L., editors, New Tools for New Times: The Work ow Paradigm. Future Strategies Inc. [Paulisch, 1993] Paulisch, F. (1993). The design of an extendible graph editor. Springer, Berlin. [Pikaar et al., 1991] Pikaar, R., Bakker, P., and van Spijker, H. (1991). Gebruikersvriendelijkheid van geautomatiseerde systemen. University of Twente, Enschede. [Powell, 1990] Powell, J. (1990). Designing User Interfaces. Microtrend Books, San Marcos, USA. [Shneiderman, 1992] Shneiderman, B. (1992). Designing the User Interface. Addison-Wesley Publishing Company, Reading, MA. [Smith, 1993] Smith, J. A. (1993). Analyzing and redesign of work ows for imaging. Document & imaging, 3:9{15. [Smolander et al., 1991] Smolander, K., Martin, P., Lytinen, K., and Tahvainanen, V. (1991). Meta-edit - a exible graphical environment for methodology modelling. In R. Andersen, J. B. and Solvberg, A., editors, Advanced information systems engineering, Lecture notes in computer science 498, Berlin. Springer. [Spivey, 1992] Spivey, J. (1992). The Z notation : a reference manual. Prentice-Hall, New York. [Stoustrup, 1993] Stoustrup, B. (1993). The C++ programming language. Addison Wesley, New Jersey.

100

Bibliography

[Thimbleby, 1990] Thimbleby, H. (1990). User interface design. ACM Press, New York. [Tom Sawyer, 1994] Tom Sawyer (1994). Graph layout toolkit: users guide and reference manual. Tom Sawyer Software Corporation. [van Bekkum, 1995] van Bekkum, A. (1995). Elicitation of work ow design knowledge for the scarabaeus project. University of Twente. [van de Belt, 1995] van de Belt, A. (1995). Representation of work ow design knowledge for the scarabaeus project. University of Twente. [van der Harst, 1994] van der Harst, G. (1994). Work ow evaluatierapport. Technical report, Stichting SERC. [van Duin, 1993] van Duin, S. (1993). Work ow management systemen: de nitie, indeling,acceptatie en toekomst. Master's thesis, University of Leiden, Subfaculty of Mathematics and Computer Science. [van Hattum, 1994] van Hattum, M. (1994). Process analysis language. Technical report, Pallas Athena b.v. [van Vliet, 1993] van Vliet, H. (1993). Software engineering. Wiley, Chichester. [van Winkel and Willems, 1993] van Winkel, J. and Willems, L. (1993). Het C++ boek. Academic Service, Schoonhoven. [Wasser, 1992] Wasser, J. (1992). Work ow: een nieuwe kijk op automatisering. VIP, pages 59{60. [Wijers, 1992] Wijers, G. (1992). Meta-case. Software engineering research centre, Utrecht. [Work ow Management Coalition, 1994] Work ow Management Coalition (1994). Glossary. Technical report, Work ow Management Coalition, Brussels. [Yourdon, 1989] Yourdon, E. (1989). Modern structured analysis. Yourdon Press, Englewood Clis, NJ.

Index act, 13 activity, 13 actor, 14 architecture, 17 work ow design tool, 18 work ow support system, 17

starting symbols, 63 terminal symbols, 62 Groupware, 18 implementation issues, 75 interface, 2

business process, 14 business process redesign, 19 tools, 93 CAME tools, 34 CASE tools, 33 compiler generator tools, 66, 75 concepts control perspective, 25 data ow perspective, 29 data perspective, 28 organisational perspective, 28 work ow, 13 conceptual model, 24 conclusions, 83 CSCW, 18

knowledge-based system, 2, 44 interface, 69 alternatives, 69 choice, 70 tasks, 22 list

classes, 58 operations, 53 pseudo code, 71 logistics, 19 Meta-CASE tools, 34 modelling technique, 2 object, 13 objectives and preconditions, 23, 30 optimisation, 23

data ow diagrams, 46 design functional, 41 technical, 57 design errors, 23 diagramming techniques, 41 dialogue, 2 document image processing, 19 document information system, 19

programming environment, 34 pseudo code, 71

editor speci c concepts, 42 tasks, 22 editor transfer charts, 41 entity relationship diagrams, 24 evaluation, 77 plan, 80 event, 13 Extended Backus Naur Form, 62 conventions, 62 non-terminal symbols, 63 production rules, 63

Scarabaeus, 3 goals, 4 involvement, 4 method engineering part, 5 approach, 5 justi cation, 7 plan, 9 research questions, 5 research results, 83 name, 3 products, 95

requirements hard- and software, 75 responsibility, 13 role, 14

101

102 research problem, 3 tool investigation, 87 signature graphs, 51 state transition diagrams, 49 streamlining, 24 task structure diagrams, 21 technique, 2 tool, 2 trigger, 14 user interface, 36, 49 data structure, 46 layout aspects, 67 screens, 67 theory, 37 dialog styles, 38 types of user interfaces, 40 user friendliness, 37 validation, 80 veri cation, 80 work ow, 14 automation, 13 classes, 58 management, 12 model, 2 operations, 54 pseudo code, 73 system, 13 tools, 32, 87 work ow data external, 43, 61 internal, 43, 57 internal data structure, 46 persistence, 61 relations, 57 graphs and external, 69 internal and external, 65 work ow design, 2, 15 task, 21 work ow design tool current situation, 77 functionality, 43 realisation alternatives, 32 choice, 35 requirements, 31 work to be done, 79

Index