Design of a Domain Specific Language for. a Dutch Student House Workflow System

Design of a Domain Specific Language for a Dutch Student House Workflow System

After days of trying to find an original system, I have finally chosen to design a domain specific language for a Dutch student house. In such a house, there are several actors with different tasks and activities to perform. There are as well several events that act upon some actors and make them perform some specific activities related to those events. These interactions between events, actors and activities can be called processes. To make the step from general to concrete, let’s start with some examples of scenarios. A student house should have an internal organization, a structure. The actors are represented by all the students living in that house, but some of them are chosen to have special duties. Therefore, in a house with 15 students, one of them is in charge with the organization. I will call this person the head of the house. This head person is in fact the one that has to design the domain specific language and uses it the most, therefore the design I am going to present is nothing but the way the head person is organizing the house. It may be hard to find a beginning to the description of a house workflow, but let’s start with the house variables. There should be some set variables who describe how many rooms are there and how many shared areas, like bathrooms, toilets, kitchens, and living room. Some functions should exist to connect rooms to shared facilities. For example, if there are three toilets in the house and 15 rooms, then 5 rooms will be connected to each toilet. After each room and each facility gets an ID, by using a command like newRoom and newFacility, we can have commands to connect rooms to facilities, like roomToFacility . If a room is already connected to, let’s say, a toilet, and then if one tries to connect it to another toilet, a warning can appear and if the person still wants to proceed, the room will at the same time be disconnected from its former toilet. All these commands are useful for making cleaning schedules, etc. After everything is set, then the house database is ready. This database shouldn’t suffer from changes. Only the change in student’s names should be further necessary, when students move in and out. And by this, let’s go to the next issue that might appear.

At any moment of time, students may leave the house and new students may come instead. Therefore , some basic commands are needed in order to empty a room and to assign a person to a room. L et’s say we can have a command studentToRoom that takes two arguments, a room number and a name to assign to the room, and another command emptyRoom may be used when a student lives the house. In our database, the date each student arrives will be remembered. When a room is emptied, then there is need for “hospiteeren”. That calls for a house meeting, which in fact represents the first activity discussed in this paper. Such an activity can be scheduled by using a command houseMeeting, which can take a date/time argument and a reason. When the command is executed, an event is made and actors have to act on it. By mentioning if they can be present or not, or by proposing a new date. At the moment each actor reacted to each proposal, the meeting date with most actors that can be present will be given as the final date. Commands like studentToMeeting or finalMeetingDate can be used in order to process all the above. Another scenario occurs when students make use of the house telephone. The phone machine should be connected to a computer that allows it to be used only when a student introduced a command usePhone that takes as argument a student’s name or a room number. Maybe, for security reasons, passwords may be assigned to students and, together with that, options to change passwords. The actual use of the phone can be considered an activity. As well, picking up a phone and leaving messages are also activities that can be started with commands like messageToStudent, while a checking for messages command should as well be present. Another useful command for handling phone calls is one to check whether students are in the house or not, which can be named checkPresenceStatus or modifyPresenceStatus. Finally, when the payment comes, the head of the house may check how to distribute the payment within the students in the house. Such a command, phonePayment, can take as argument a time interval and a total payment and it will return as output a table with all payments per student. There are several other payments to be done for in the house, like shopping one does for shared facilities or the ‘borg’. All payments are going to have a similar structure as the telephone payment and can be added altogether in one list. The head of the house will collect money from students and with basic commands can subtract the amount paid from the table of payments. Commands like getStudentDebts and receivePayment can be used. The best example for the student house workflow is represented by the cleaning schedules. There should be a cleaning schedule for each facility and now I go back to the connection between rooms and facilities I wrote about earlier. Only the students living in a room connected to some facility has to be involved in the cleaning of that facility. For each type of facility there is a time interval between two cleanings. For example, a toilet should be cleaned each 5-10 days, while the living room should be cleaned each 15-30 days. An order of cleaning among students will be created using their room numbers. To exemplify, let’s take again the toilet. After 5 days from the previous cleaning, a student, an actor, who is at turn, has the event to clean started.

He has to do the cleaning activity in five days and at the moment it is finished, he or she can use the command facilityCleaned to pass the turn to the next person. If the deadline is not met, a warning or a notification should be processed by the computer. The student missing the deadline will be put on a warning list which can be accessed with, yet, another command. Some student houses have their own special rules. For example, a student house may have the rule that the newest 5 members need to organize a party. Such parties are to be organized every three months. Again, there may be notifications and commands that generate lists with the students that are to organize the next party and the date of the party. These students may as well be assigned, again in the order of longevity in the house, to perform some tasks, like shopping for food and drinks, organizing the living room, dealing with invitations and announcements etc. There is no need to mention again all the commands that may be used in these cases, because they are similar with the ones already presented above. The domain specific language designed here is a simple language based on commands and database administration. This language looks more like an interface for operating systems with strong use of databases, with predefined types for variables like student names etc. The way users operate with this language is by means of commands, with which events may be started and the status of activities may be introduced by the actors in order to be processed. As already known, such a language has the advantage that it is easy to use and any error that occurs is ea sy to be explained and understood. However, such a language has its limitations and cannot be used for other activities than the ones specific to a student house. As well, in the far future, even student houses might change their organization and structure. Therefore, even though it might be harder to learn, to understand and to handle errors, I find a more general language better to use.





   

 "!$#&%')($* + ,-./1023# 452687)7)6 9

:<;>=?@?A=B; RTSVUVWHXYLZ[]\_^>`2Z[badcfeHghei^YLji\Vk RmZ[badcfeHghei^YLji\` n Z[badcfeHghei^YLji\`2Z[ba]coeHghei^YLji\Vk Z[ba]cfeigheH^lYLjH\ Rmead^pjig n ead^Yrq&Yr^ls n ^sutJ[ ^lsutJ[ RwvLxzyQ{_|}~|dJ€Vf‚hoƒ€_„ ea]^…jHg R†UJ‡.SVˆ‰YLZ[]\_^LkŠ` YLZ[]\_^Lk R‹YLZ[d\J^ n YLZ[]\_^>YLZ[d\J^k ea]^lYrq&Yr^s R†UJ‡.S)Œ.)Œ.S3ŽYLZ[]\_^2ead^Yrq&Yr^s kltV[badY z[dgbk` ea]^lYrq&Yr^s kltV[badY z[dgbkERmead^Yrq&Yr^ls kltJ[ba]Y ‘[]g n ead^Yrq&Yr^ls kltJ[ba]Y ‘[]gBead^Yrq&Yr^ls kltJ[uadY z[dgbk ea]^lYrq&Yr^s kltV[badY z[dg’R<“J”‰~•~ˆ‰i–8”3—z˜~Žš™)YLZ[]\_^Lkz› n –)ˆ—8ŒH•8Œi”VWŠYLZ[]\_^œ™YLZ[d\J^k2› n ‡H‰~”QUSV”JWžYLZ[d\J^>™OYLZ[]\_^Lk&› n Œ&Ÿ)Œ.S)ŒiU~  n •3‰~ˆ.–¡™YLZ[d\J^kœ› n ‰V”3U3—_W¢YLZ[]\_^$™YLZ[d\J^kz› n ‰V”i“Jˆ‰QS

£

CED.FHGJI)KLD.C MONQP.G Z[ba]cfeigheH^lYLjH\Jk

¤’¥¦A§;>=B¨œ©«ªd¬¦­"® ­"§¯E? SVUJWHX˜Q°~±Q²3Ž8‡ 3”$³ ”ŸQ°–´˜Q°~±VµVWHSVUS°)W·¶¸Q¹3ºJ»¸Q¼Q¹3½2¾d¿.ÀQÁ3Â~Ã_¿.½œ¾Ä²V»HÀQÅ)¿&¸3Æ3¹Q½>¾ÄÅ)¿&Ç3¹3½2¾Ä½¹Qº3¹3ÀQ½3¹QÀ3²3Ȝ¾O½É~º~ÃJ¿H²3¼Q¹VÊ$³ ”ŸQ°–´˜Q°~±VµVW”V”‰)Œ.SQŽ¶²3¸)¿.¼8¿H²3Â~ÃVʳ SQŽ3“J”˘Q°~±Ì¶ ÍQÍ USÏÎQ°~±Ð‡H‰V”3US)ŒiˆŸ Œ&ŸQSьH—>³ Ò

WHS3‰)Œ&Ÿ~±Ð‡ˆ.–3–)”Ÿ~S2³ ˜Q°Q±JµVWHSVUS3°)W WHS~US3°)W³ ˜Q°Q±JµVW”~”‰)Œ.SQŽ W”V”‰)Œ.SQŽ2³ ÍQÍ USÏÎQ°~±Ð‡ˆŸ~•8Œ.‰i–)US)ŒiˆŸ Ã8ŒWHS ˜Q°Q±
·—~”“V”ŸV—~”Ÿ8‡~Œi”JW³ QÍ Í W ”SJ”Ÿ —~”i“J”ŸV—~UiŸ~SˆŸ´•8Œ~”JWˈ3• ˆ S J”‰˜Q°Q±8W ÍQÍ °)W”3— U~ ~Wˆ J”Ÿ Œ3W˗°Q“_ VŒ3‡USV”ˈ3• U Ÿ ÍQÍ ”)Œ3W.S)Œ&Ÿ~± ˜Q°Q± Ê$³

ÍQÍ US Â8WQW~Œ&±3Ÿ–)”ŸQSˆ3•Ï‰V”JW.“VˆŸ)WU˜)Œ JŒ.SQŽ WHS3‰)Œ&Ÿ~±ÏSVU‰3±V”SQÆ)Œi 3”JWHSVˆiŸJ”$³ ÍQÍ J”Ÿ WVˆ°_ — S )Œ3W ˜J” •_ŒV”3— —~”V”~ 3ˆ“V”‰ÏUJWQWQŒ.±3ŸJ”3—¼Vˆ>³ ÍQÍ —~”V”Q 3ˆ“J”‰Ë‰V”JW.“JˆiŸ)W~Œ&˜_ ”ˈ3•ÏS Œ3W ˜Q°Q±

UJ‡HSVˆ‰°)Wi”‰2¾h—~”V”~ 3ˆ“V”‰2¾ÄSQ”JW.SV”‰œ¾3U.–8UŸVU±V”i‰2³ UJ‡HS)Œ.8Œ.SQŽÏ•8Œ ”ÎQ°~±Ë“V”‰~•~ˆ‰H–)”3—·˜~ŽÄ°)Wi”‰2¾h—~”V”~ 3ˆ“V”‰2¾OS~”VWHSV”i‰2¾QU.–8UŸ~U±~”‰ ‡.‰V”QUSV”VW ˜Q°~±  ¿&½2¾]‡ˆ.–3–)”Ÿ~S2¾ W.SVUiS3°)W"¾ Wi”V”i‰)Œ&S3Ž  Œ ŸŒ.S)ŒiUQ $³ UJ‡HS)Œ.8Œ.SQŽÌ‡ˆŸ~•8Œ.‰i–JÎ3°~±·“J”‰~•~ˆ‰i–8”3—·˜~ŽhSV”JW.SV”‰2¾h—Q”V”~ 3ˆi“V”‰2¾L–)UiŸVU±~”‰ –)ˆ—8ŒH•8Œi”VW1˜Q°~± ]‡ˆ.–Q–)”iŸ~S2¾]WHS~US3°8W"¾ W”Q”‰8Œ&SQŽœ¾h—3”“V”iŸV—Q”Ÿ_‡~Œi”~W •3‰~ˆ. – u•8Œ 3”iÎQ°~± "³ UJ‡HS)Œ.8Œ.SQŽ UJWQWQŒ.±3ŸQÎQ°Q±·“J”‰Q•~ˆ‰i–)”—·˜~Ž~U.–)UiŸJU±V”‰ –)ˆ3—_ŒH•8Œi”JW ˜3°~± bUJW3W~Œ.±3ŸJ”—3¼Vˆ>¾…SVU‰3±~”SQÆ)ŒH 3”VW.SVˆiŸJ”  •3‰Vˆ& – ]‡ˆŸV•8Œ&‰i–JÎQ°~±œ¾Ä‰V”JWˆQ iV”HÎQ°~± ³ UJ‡HS)Œ.8Œ.SQŽ‰V”JWiˆ~ V”Î3°~±·“J”‰~•~ˆ‰i–8”3—·˜~Žu—~”~”~ 3ˆ“J”‰ –)ˆ—8ŒH•8Œi”VW1˜Q°~± ]‡ˆ.–Q–)”iŸ~S2¾]WHS~US3°8W"¾ W”Q”‰8Œ&SQŽœ¾h—3”“V”iŸV—Q”Ÿ_‡~Œi”~W •3‰~ˆ. – d‡ˆŸV•_Œ.‰i–JÎQ°Q±2¾uUJWQWQŒ&±3ŸÎQ°~±œ¾O‰~”JWˆ3 ~”iÎQ°Q± ³ UJ‡HS)Œ.8Œ.SQŽÌWJˆQÎQ°~±Ë“V”‰~•~ˆ‰H–)”3—·˜~ŽhSV”VWHSV”‰2¾Ä—~”V”~ ˆ“J”‰œ¾~U.–_UŸVU±V”‰ ‰~”QU3—_W ˜Q°~± ‰~”“Jˆ‰QSœ³



Design of a domain specific language for a workflow system To define a domain specific language one has first to identify what workflow system needs to be build. In this example I will elaborate on a general workflow system that can identify work and workers (called task and actor). Task Task has several attributes. The attributes are: Date due: when is de due date of the task. Genre: what kind of task is it? Actor Actor has several attributes. The attributes are: Genre To show how the tasks and actors work together a flow diagram is shown of a call center were a client is calling for a subscription to a magazine. Actor Customer Task Call for a subscription to a magazine

Actor Call Center employee Task Call for a subscription to a magazine

Actor Call Center supervisor Task Check subscription

Actor Distribution employee Task Send out magazine

Actor Computer system Task Process subscription

Actor Computer system Task Process confirmed subscription

Actor Customer Task Read magazine

A domain specific language for a workflow system September 10, 2002

Contents 1 Introduction

2

2 Context-free grammar 2.1 Concrete grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Abstract grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3

A Example

5

B Bibliography

6

1

1

Introduction

Workflow systems basically are the computerised automation of business processes, in whole or part. They are concerned with the automation of procedures where information and tasks are passed between participants according to a predefined set of rules in order to achieve an overall goal. This assignment consists of an simplified attempt to define a domain specific language for this type of systems. We have selected a XML-oriented representation for it as it is a platform independent solution and also tends to be easy to parse. A workflow system has several components which are then combined by the use of a workflow engine. Components such the actors/participants, activities and also transition conditions must be defined accordingly to each case. All this can be defined with the help of a domain specific language which will allow the easy definition of any workflow system and not just a particular model.

2

2

Context-free grammar

2.1

Concrete grammar

G=(T,N,S,P), com T = {<WFTD>, , <WF name=, version=, , , , ,

, , <WFRD name=, path=, , 


p0: p1: p2: p3: p4: p5: p6: p7: p8: p9: p10: p11: p12:



WFTD → WF → Activity → | ACond → Pre → Post → TC → | WFRD → | Role → |



<WFTD> WF Activity WFRD  <WF name=”name” version=”version”/>  ACond Role TC  Activity   Pre Post  
   TC  <WFRD name=”name” path=”path” /> WFRD   Role 



In our language, each workflow has a name and a version, a set of activities and also relevant data. Each activity may have a previous condition/activity and also the one which follows it, creating an automated flow of data. There are also transition conditions, which are used to determine if the activity can be executed and consequently move on to the following step. These activities are performed by entities/actors which play a specific role also defined in the domain specific language. The data consists of entities and its respective location in the system.



2.2 { , , , ,



Abstract grammar p0: p1: p2: p3: p4:



WFTD → WF Activity WFRD WF → name version Activity → name ACond Role TC Activity |  ACond → Pre Post 3



 , , , , , , , , }



p5: p6: p7: p8: p9: p10: p11: p12:



Pre Post TC WFRD Role



→ → → | → | → |



condition condition condition TC  name path WFRD  name entitity Role 



4



 A



Example



<WFTD> <WF name="Exam session" version="1.0"/>   
        
        
        
      <WFRD name="teachers" path="/teachers"/> <WFRD name="students" path="/students"/> <WFRD name="rooms" path="/rooms"/> <WFRD name="proctors" path="/proctors"/>  



5



 B



Bibliography • Workflow Management Coalition [1995] - Workflow Reference Model. • Plesums, Charles - Introduction to Workflow. • Zhao, J. Leon [2002] - Workflow Basics: Architecture and Applications.



6



 Domain Specific Language for a Workflow System By



Introduction This assignment is not about designing the perfect workflow system, but only serves to get a feeling of what is involved when formalising and modelling one. I am a former ‘HTS Hogere Informatica’ student and am currently working on a crash- course on ‘Functional Programming’ and ‘Grammars and Parsing’ in collaboration with Arjan van IJzendoorn to fill in the gaps in my knowledge. I am making quite some progress on ‘Functional Programming’, but haven’t started ‘Grammars and Parsing’ just yet. This means I don’t have any basic knowledge of context- free grammar and language design. In stead of giving a context- free grammar I present a simplified workflow system model and example code of how the hypothetical domain specific language should look like. Simplified Workflow System Model



Figure 1 : Simplified Workflow System Model



Example Code // A task can only start if all resources and actors are available // The resources and actors can be seen as a resource pool and can be used // by the task if they are available. // Create Resources available to this domain Resource("Room", 3)



// Resource (description, // quantity)



Resource("OSIRIS-Terminal", 2) // Create Actors available to this domain Actor("Proctor", 3)



// Actor (description, // quantity)



Actor("Student", 10) Actor("Examiner", 3) Actor("Administrative", 1) // Create Tasks and assign necessaries Task(



"AssignProctors",



// Task (TaskName, StartDate // EndDate, Actor[], // Resource[]) // TaskName



 "12-09-2002:11.00", // StartDate "12-09-2002:11.10", // EndDate [("Administrative", 1), ("Proctor", 2)], // List of necessarie Actors []) // List of necessarie Resources Task( "ReservingRoom", "12-09-2002:11.10", "12-09-2002:11.15", [("Administrative", 1)], []) Task( "ExamSession", "17-09-2002:09.00", "17-09-2002:12.00", [("Proctor", 2), ("Student", 10)], [("Room", 1)]) Task( "DistributeExam", "17-09-2002:12.00", "17-09-2002:13.0", [("Administrative", 1), ("Examiner", 2)], []) Task( "CheckExam", "17-09-2002:13.00", "17-09-2002:17.00", [("Examiner", 2)], []) Task( "CommunicatieResultToAdministration", "18-09-2002:09.00", "18-09-2002:09.30", [("Examiner", 2), ("Administrative", 1)], [("OSIRIS-Terminal", 1]) Task( "CheckExamMarks", "18-09-2002:09.30", "18-09-2002:10.30", [("Proctor", 1)], [("OSIRIS-Terminal", 1]) Task( "SignFinalExamForm", "18-09-2002:11.30", "18-09-2002:12.30", [("Examiner", 1)], [("OSIRIS-Terminal", 1]) Task( "CommunicateResult", "18-09-2002:12.30", "18-09-2002:13.30", [("Examiner", 1), ("Student", 10)], [])



 IST Assignment 1



A Domain-Specific Language for Workflow Management Systems



Objecten: •



task: -



depends on omschrijving resultaat closed (default waarde: false) 4 instanties van person: een initiator, een of meerdere actors, nul of meerdere ontvangers, nul of meerdere lijdend voowerpen date due en date created



•



person: - naw - email



•



document: - naam - locatie (papier, file op disk, etc.)



Toelichting 1. Een taak kan pas worden uitgevoerd als alle dependencies zijn vervuld, m.a.w. voor het uitvoeren van een taak wordt terug in de tijd gekeken 2. Resultaten van taken kunnen op papier of digitaal worden geproduceerd



Context Free Grammar Task Task_Properties



= =



Naam Task_Properties (Depends_On)* Omschrijving Resultaat Closed Initiator (Actor)+ (Receiver)* (Object)* Date_Due Date_Created



Depends_On



=



Task



Closed Initiator Actor Receiver Object



= = = = =



Boolean Person Person Person Person



 IST Assignment 1



Resultaat



=



Document



Document



=



Naam Location



Person



=



Naam Adres Woonplaats Email



Date_Due Date_Created



= =



Date Date



Naam Adres Woonplaats Email Omschrijving Location



= = = = = =



String String String String String String



Voorbeeld NEW person ("directeur") NEW person ("zaal_beheerder") NEW person ("piet") NEW person ("henk") NEW person ("jan") directeur() { naam = "directeur" email = "DIRECTOR@" } zaal_beheerder() { naam = "klaas" email = "zaalbeheer@" } piet() { naam = "piet" email = "piet@" }



 IST Assignment 1



henk() { naam = "henk" email = "henk@" } jan() { naam = "jan" email = "jan@" }



NEW Task ("maakexam") NEW Task ("checkexam") NEW Task ("proctors") NEW Task ("reserveroom") NEW Task ("examsession")



maakexam() { omschrijving = "Tentamen IST klussen" resultaat = NEW document("tentamen_ist") initator = directeur actor = [jan] date due = infinity } checkexam() { depends on = [maakexam] omschrijving = "Tentamen controleren op juistheid" resultaat = NEW document("tentamen_ist_corrected") initiator = jan actor = [piet] resultdewd = [jan] date due = infinity }



 IST Assignment 1



reserveroom() { omschrijving = "Zaal reserveren bij beheerder, nummer bekend maken op website" resultaat = NEW document("tentamen_ist_zaalnummer") initiator = directeur actor = [jan] lijdend voorwerp = zaal_beheerder date due = infinity } proctors() { depends on = [reserveroom] omschrijving = "U dient te surveilleren" resultaat = "" initiator = directeur actor = [piet,jan] date due = infinity } examsession() { depends on = [reserveroom,proctors,maakexam,checkexam] omschrijving = "Tentaminering" resultaat = NEW document("tentamen_ist_ingeleverd") initiator = directeur actor = [piet,jan] date due = infinity }



.... etc. ….



Begin("maakexam") Begin("reserveroom") NB. met deze twee taken wordt gestart, ze hebben geen dependencies



 A Domain Specific Language for A Workflow System Abstract Workflow is concerned with the automation of procedures where documents, information or tasks are passed between participants according to a defined set of rules to achieve, or contribute to, an overall business goal. The procedures are formally documented and followed exactly, ensuring that the work is performed in the way planned by management. The best person (or machine) is assigned to do each case, and the most important cases are assigned first. Users don’t waste time choosing which item to work on. The workflow system defined in this paper, are based on Workflow Reference Model provided by Workflow Management Coalition. 1. Introduction In the last 15 years, we have developed tools to not only do the work, but to manage the workflow. More than just procedural documents, that workflow process is defined formally in the workflow computer system. The process is managed by a computer program that assigns the work, passes it on, and tracks its progress. A simple workflow system could evenly distribute work among all the available resources, or follow a simple algorithm such as giving the waiting work to the resource with the shortest queue, or implement assignments made manually by a supervisor. However, there are often significant benefits when the system can optimize the assignment of the work. In order to do the assignment, the workflow management system must know who or what is available to perform the work, and have a profile about each user. This might include what work the resource is qualified to do, how good they are at that type of work (can they do only routine processing or can they handle the toughest cases), and whether the supervisor wants the work to be assigned to them. 2. Background 2.1 Domain Specific Languages Domain Specific languages are programming languages that are dedicated to specific application domains. They are less comprehensive than general-purpose languages like C or Java, but much more expressive in their domain. Such languages offer the following main advantages. Productivity Programming, maintenance and evolution are much easier (in some cases, development time can be ten times faster); re-use is systematized. For example, SQL is a DSL developed for fast and easy database management. Verification It becomes possible or much easier to automate formal proofs of critical properties of the software: security, safety, real time, etc. For example, a program written in a language with no loops is guaranteed to terminate. 3. The Workflow Reference Model



 Workflow type definition



has



Consists of May refer to Role



uses Activity



Workflow Relevant Data



May have



uses Invoked Applications



Transition Conditions



Workflow Type Definition · Workflow process name · Version number · Process start and termination conditions · Security, audit or other control data Activity · Activity name · Activity type (subflow, atomic flow, etc) · Pre- and post- activity conditions · Other scheduling constraints Transition Conditions · Flow or Execution conditions Workflow relevant data · Data name and path · Data types Role · Name and organisational entity Invoked Application · Generic type or name · Execution parameters · Location or access path



May refer to



 4. DSL for Workflow System The components of a workflow system consist of actor, activity, transition, and history 4.1



Actor • Add an Actor AddActor  For Example: The following statement will create an actor, namely Proctor01 AddActor “Proctor01” •



Remove an Actor RemActor  Where 



4.2



Activity • Add an Activity AddAct  Where  For Example: The following statement will create an activity for making a room by Proctor01 if there is a notification AddAct “Making a Room”, “Proctor01” Where NotificationExist •



Remove an Activity RemAct   Where 



•



Associate application to activity AssociateApp <Application Name>  For Example: The following statement will associate application “Osiris” to the activity “Entering preliminary result” AssociateApp “Osiris”, “Entering preliminary result”



4.3



Transition Transition is needed to link activities to form a process.



 •



Add a transition This method is used to create a link between activities AddTrans   



4.4



History History is used to keep track the process of a workflow. •



Add to history The workflow system will add each result of activities to the History Log AddHistory <Time>   



References [1] http://www.cse.iitk.ac.in/users/deepak/papers/webcal.pdf [2] http://www.e-workflow.org/standards/workflow_ref_model.pdf [3] Edited by Layna Fischer : The Workflow Handbook 2002, March 2002 ______________________________________________________________________________ Name:



 A Workflow System for the Polyclinic Surgery of Patients in a Hospital. By The first time my mother needed a new pace-maker, she had to stay in hospital for nearly a week. Now, 15 years later, it takes one day. In my mother’s case two, but that was because some little complications. Anyway, it takes less time. It’s been made possible by developments in the information technology. Not only the pace-makers are more advanced, the use of surgeons, operating theatres, etc is more efficient. They can be utilised more efficiently because of the use of workflow systems.



What is a workflow system? First of all, it has to be clear that a workflow is a series of activities which together form a business process. These activities have to be performed in a certain order. A workflow system can automate the activities undertaken by both people and the computer resources of an organisation. It depends on the type of system whether all activities are automated or just a part of them. In that case the workflow system will assist by providing a checklist of tasks to be conducted by some actor (person in a specific role). This is the case in my workflow system for the polyclinic surgery of patients.



The workflow for the polyclinic surgery of patients in a Hospital The tasks to be performed before, during and after a polyclinic surgery are in many cases the same. They include, getting information about the patient by checking their history and performing tests, getting consent for the surgery, reserving doctors and the operating theatre and the post-operational treatment. All this can be put in a workflow system that automates some activities and otherwise tells some actor what to do. Here the most important actors are the doctor, surgeon and the anaesthetist. They’re responsible for many activities. They check the patient, update the patient’s clinical record after every test and perform the operation. Doctor and surgeon are roles. They can be the same person. Surgeon, for instance, can be two individuals. The patient clearly has a different role then the surgeon or the anaesthetist. He or she is the object subject to the workflow. In other words: a special case wherefore a number of activities have to be performed. The system keeps all information related to the individual patient (identification, clinical record). The system is responsible for making the appointments and reservations, which are also recorded. A hospital deals with patients. That why the system has to be safe and regularly perform checks. If something is wrong the system will notify the actors by alarms. The system should be able to handle exceptional situations and deal with eventual process changes. If the system suggests a date for an appointment it should be possible to postpone it. The next page shows the workflow for polyclinic surgery of patients in a Hospital. It contains 18 activities. Some of them take little time (update the clinical record), while others are take much more time (performing the operation). The activities have to be performed in a specific order. In the process of polyclinic surgery that is from 1 to 18. Five of them can only be performed if a specific condition is met (split). The agreeing of the patient and (9) for the operation is an example. If one of them doesn’t agree other possibilities should be looked at. Those other possibilities are not specified her, but include medication and/or some other treatment. The next page also shows a diagram of the workflow. Recursive calls and splits are made visible this way. A recursive call is made when the patient has got



 complications(16). Until those complications are solved the patient has to stay in hospital. The * with nine indicates the chain is broken and continued below. 1. Identification of patient with pathology and severity of condition and priority of treatment. This is all introduced to the system. 2. Make appointment for examination. 3. Examination of patient by doctor. 4. Update clinical record with results of examination. 5. If patient agrees (choice True or False). a. True: request for surgical operation. b. False: look for other solution. 6. If more examination required (choice True or False). a. True: system makes appointment for additional tests and a appointment with the anaesthetist(s). b. False: go to 9. 7. During appointment all tests are conducted and judged by anaesthetist. 8. Update clinical record with results of test(s). 9. If patient and doctor agree (choice True or False). a. True: Patient signs consent for surgical operation. b. False: look for other solution. 10. Operating theatre, surgeon(s) and anaesthetist are reserved for operation. 11. Letter to patient with confirmation of date. 12. Just before the surgical intervention the surgeon and anaesthetist check if patient is fit. 13. If patient is fit (choice True or False). a. True: the operation is performed. b. False: postpone or look for other solution (go to 9). 14. Afterwards doctor and anaesthetist evaluate recovery. 15. Update record with operation results. 16. Until patient has no complications. Try to solve them. 17. Release patient with relief plan and medication. 18. Make post-operation appointment.



6.a. 5.a. 1.



2.



3.



4.



7.



8.



6.



9.* 6.b.



5. 5.b.



9.b. 9.*



13.a.



14.



15.



16.



17.



15.



9.a.



10.



11.



12. 13.b.



18.



 Design of a domain specific language for workflow systems



To make a demain specific language design for a workflow system we take a shop for example. We look at the flow of products in the shop, from magazine to buyer. The description is as follow: 1. 2. 3. 4. 5.



,QNRSHU makes an RUGHU at the dealer Goods come in at the company and the PDJD]LMQPHGHZHUNHU accept signs the RUGHU 6DOHVPDQ sales an item and he makes a UHFHLSW of the sold product The PDJD]LMQPHGHZHUNHU takes the UHFHLSW and gets the product The PDJD]LMQPHGHZHUNHU updates the VWRFNDGPLQLVWUDWLRQ



All words in LWDOLF are the actors and all words in EROG are the documents. The attribute free grammar looks as follows: Workflow



Æ Tasks



Tasks



Æ Task Tasks _



Task



Æ Actor Description Document | Actor Description



Actor



Description Document



Æ Inkoper | Magazijnmedewerker | Salesman Æ String Æ Order | Receipt | Stock administration



 The workflow looks as follows:



Make an order Inkoper Order



Accept incoming goods and sign order Mag. mdw Order



Sell a product make receipt



Take receipt and get product



Salesman



Mag. mdw



Receipt



Receipt



Change stock administration Mag. mdw Stock admin.



The laguage can be as follows: Task order = New Task “Make an Order” Inkoper Order Task accept = New Task “Accept incoming goods and sign order” Magazijnmedewerker Order Task sell = New Task “Sell a product and make a receipt” Salesman Receipt Task get = New Task “Take receipt and get product” Magazijnmedewerker Receipt Task change = New “Change stock administration” Magazijnmederwerker Stockadministration Tasks tasks = New Tasks [order, accept, sell, get, change] Workflow workflow = New Workflow tasks



 Domain specific language design for a workflow system Introduction A workflow consists of multiple actions that have to be taken in a certain order. The order of these actions can be formalized by means of a domain specific language. A sentence in such a language represents an entire workflow. We have made a design for such a language.



Design Context free grammar This context free grammar for workflow systems is enough for describing simple situations. The grammar can easily be translated into – UML – activity diagrams (see page 2 and 3). Workflow Element



-> ->



Name Condition



-> ->



Start Element Action Name Element | Choice Condition Element Element Element | WaitSplit Element+ Element | Wait Condition Element | EndElement string string



Explanation We know the WMFC (Workflow Management Coalition) describes four ordering relations. But the stricture we use is easier to understand and most constructions are still possible. Some of the element-types may need some little more explanation: Choice Condition Element Element Element The ‘Choice-Element’ can be used to switch to other actions under a certain condition. It works like an if-then-else-statement: the first element is the action to execute when the given condition holds, otherwise the second element will be invocated. A ‘Choice-Element’ also got a third element, this is the element both paths (the ‘then’ and the ‘else’– path) come together again. This guaranties a linear structure, so you’ll always have only one endpoint. WaitSplit Element+ Element The ’WaitSplit-Element’ can execute a list of actions at once. The statement will wait till all the called paths are finished and then continue with the next element (the second argument in the ‘WaitSplit’constructor). This is almost the same structure as in the ‘Choice’-statement. EndElement The ‘EndElement’ is needed to end a path, for example in a ‘WaitSplit’ or ‘Choice’-statement (it’s like a leaf in a tree). Every workflow ends in an ‘EndElement’.



 Case study As case study we have taken the workflow of an ordering system, wherein customers can place orders. They have to be registered customers so they will be checked. If they are registered customers they will be sent a bill and the workflow will wait for them to pay. At the same time, the order shipment is prepared by checking if there is enough of it in stock. When there is insufficient stock, the ordered items will be produced somehow. When the order is ready and the customer has paid, the order will be shipped. Of course, when the customer is not registered, no action will be taken. We assume that the registering process of customers is dealt with in another workflow. The actions in a workflow each have an actor, who executes the action. In our case study, the actor is someone in the company. That person uses an application that guides him through the workflow by interfacing with the workflow system (WFS). There is also another actor - a customer - that initiates the workflow by placing an order. The actors are represented in this system structure diagram:



The workflow for the organization is depicted in the activity diagram on the next page:



 In our context free grammar, this workflow looks like this: Start Action “Receive Order” Action “Check Customer” Choice “Customer ok” ( WaitSplit [ Action “Check Stock” Choice “Insufficient stock” ( Action “Produce” EndElement EndElement ) EndElement , Action “Send Bill” Wait “Payment received” Action “Handle Payment” EndElement ] Action “Ship Order” EndElement EndElement EndElement



 If you would look at the workflow of the customer (i.e. where the customer is the actor), the activity diagram would look like this:



In our context free grammar, this workflow would look like this: Start Action “Place Order” Choice “Customer accepted” ( Wait “Bill received” Action “Pay bill” Wait “Product Received” EndElement) EndElement EndElement



 Workflow system Domain specific language (system (Process (name) (goal) (start) (step (step) (time) (costs) (sub_goal) ) ) (person (name) (function) (tasks) ) (automate (tasks) ) )



 Context free grammar (a)* Ëmeerdere a’s (a)+Ë1 of meerdere a’s System = (process)* Process = (process.step+person | process.step +automate)* Step=(Step)+ Casus postverhandeling dierenkliniek ‘de zotte zeemeermin” (grote onderneming) System = (ontvangen,versturen,administratie) Ontvangen= (postzak+postbode,openmaken+jan,sorteren+sorteermachine,bekijken+kees,doorgeven+a nja) postbode.name=henk de groot postbode.function= bla bla postbode.tasks=postzak doorgeven.time=1 doorgeven.costs=.5 doorgeven.sub_goal=doorgeven (bekijken.controle+johan).subgoal=controle sorteermachine.tasks=sorteren etc.



 Proposal for a Domain Specific Language for Workflow Systems



1. Introduction In this article I will introduce a simple domain specific language that can be used as the input language for workflow systems. As defined by the Workflow Management Coalition (WfMC), workflow is ‘the computerised facilitation or automation of a business process, in whole or part’. A workflow system defines, manages and executes workflows according to the underlying workflow logic. The workflow logic describes the sequence of interaction between different components c.q. actors for the various business processes. To implement workflow system software it is desirable to represent the workflow logic in a neat, structured way before feeding it to a development tool. One way of doing so, is by formulating the various steps in a business process in terms of a predefined language. An implementation-independent definition of this language is desired, so we can use it on different development platforms. In the next section I will discuss such a language.



2. A domain specific language for workflows I will start off this section by giving the formal definition of the workflow language in EBNFnotation. Then some of the semantics and concepts of this langage will be illustrated by a case study. ProcessDefinition = “process” ProcessName “= (” (ActorName | GroupName) “,” SubprocessName (“,” SubprocessName)* “)” SubprocessDefinition = “subprocess” SubprocessName “= (” (ActorName | GroupName) “,” StartDate “,” DueDate “,” (“,” SubprocessName)* (“,” EventName)* (“, pre (” Precondition (“,” Precondition)* “)” )? (“, post (” Postcondition (“,” Postcondition)* “)” )? “)” ActorDefinition = “actor” ActorName “= (” Description “)” GroupDefinition = “group” GroupName “= (” ActorName (“,” ActorName)+ “)” EventDefinition = “event” EventName “= (” Instruction “)” BooleanDefinition = “boolean” BooleanName “=” Boolean Precondition, PostCondition = Condition Condition = “(” BooleanName “,” Boolean “)” ProcessName, SubprocessName, ActorName, Groupname, EventName, BooleanName, Description = String



 StartDate, DueDate = Date Instruction = some instruction that can be given to an external application such as an



e-mail application Furthermore, there is the restriction that everything you use on the righthand side of a definition has to be declared on the lefthand side of some other definition. For example, you may only use the condition (Bool, True) if there is a declaration like boolean Bool = False. Let us now take a look at the workflow that is associated with an exam session at a department of the university. This might look something like this: • assigning and notifying proctors • making an exam • reserving a room, entering it on the web site • having the exam checked by someone else • having the exam session • distributing the exam for marking, and collecting and computing final results • communicating the preliminary results to the students and having them entered in the central administration • checking that the marks were entered correctly • signing the final exam form • communicating the definitive results to the students If we want to give a program definition of this workflow in our language, we will have to begin by defining the main process as a chain of one or more subprocesses. The order in which the subprocesses appear in the definition of the process is the order in which they will be executed. We also need to specify an actor or a group of actors that has the main responsibilty for the process. In this case, we assume this is the teacher. So we might get: process ExamSession = (Teacher, AssignProctors, MakeExam, ReserveRoom, HaveExamChecked, HaveExamSession, DistributeCollectCompute, CommunicatePreliminaryResults, CheckMarks, SignExamForm, CommunicateDefinitiveResults)



The next thing to do is to define the various subprocesses. This is a bit more complicated since we need some more information. We once again need to specify who is responsible for this particular subprocess. For time scheduling we also need to know what the start date and due date of the subprocess are. It is possible to let a subprocess delegate some of its activities to other subprocesses, provided we include these subprocesses in the declaration of the delegating subprocess. The same goes for the use of external applications (e.g. an e-mail application or a database): we need to include the corresponding events in the declaration of the subprocess. There may be preconditions to start the subprocess. For example, a list of e-mail addresses has to be available before any mail can be sent to the recipients on that list. And finally we need to include the postcondition(s) if variables are changed during the subprocess. So if we look at the subprocess where the preliminary results are communicated to the students and the central administration, this can be translated to something similar to (dates in YYMMDD format):



 subprocess CommunicatePreliminaryResults = (Teacher, 020901, 020914, CommunicatePRToStudents, CommunicatePRToAdministration, pre ((PreliminaryResultComputed, True)), post ((PRCommunicatedToStudents, True), (PRCommunicatedToAdministration, True)))



As can be seen, the subprocess delegates its activities to two the subsubprocesses CommunicatePRToStudents and CommunicatePRToCentralAdministration. The results can only be communicated if they have been computed, so this is a precondition for this subprocess. After the subprocess is completed, the preliminary results have been communicated to the students and the administration so the corresponding booleans are set to ‘True’. The subsubprocess for communicating the preliminary results to the students might look like this: subprocess CommunicatePRToStudents = (Teacher, 020901, 020914, QueryEmailList, SendEmail, post ((PRCommunicatedToStudents, True)))



The precondition for the subsubprocess is the same as for the subprocess, so we can leave it out here. Because the subsubprocess is part of the subprocess, the start date and due date of the subsubprocess are equalto the start date and due date of the subprocess. Notice there are two events, QueryEmailList and SendEmail. The first is an instruction to query the student database for a list of e-mail addresses of the students who have taken the exam and the latter is an instruction for the e-mail application to send an e-mail with the preliminary results to all the students on the mailing list. Another example of a subprocess is the actual exam session: subprocess HaveExamSession = (Teacher, 020901, 020901, TakeExam, SuperviseExam, pre ((ExamMade, True), (RoomReserved, True), (ProctorsAssigned, True)), post ((ExamSessionFinished, True))) subprocess TakeExam = (Students, 020901, 020901) subprocess SuperviseExam (Supervisors, 020901, 020901)



To complete the program, definitions of all the groups, actors, events, condition, booleans et cetera that have not been defined yet should be added to the program. So if we still need to define an actor Student1, a group Students and a boolean ExamSessionFinished, we get: actor Student1 = (Student 1) group Students = (Student1, Student2, Student3) boolean ExamSessionFinished = False



3. Conclusion The workflow language introduced in this article is not complete. Altough the general concepts of a workflow system are here, some definitions (e.g. the definition of an actor) may in reality be more complex and contain more information. Other concepts like roles and objects may be introduced. For now, this language offers a way to build a hierarchical structure of subprocesses within a process.



 Opdracht workflow systems Inleiding Software Technology



& Universiteit Utrecht 10-09-2002



 Beschrijving van een workflow system Ten eerste moeten we definiëren wat een workflow systeem nu eigenlijk is. Een workflow systeem traceert de stappen of taken in bedrijfsprocessen. Om deze stappen te definiëren heeft een workflow systeem een workflow ontwerp module die het proces definieert dat het workflow systeem moet traceren. Dit houdt onder andere in wat de stappen zijn in het proces, wie de gebruikers zijn in het proces, welke documenten worden gebruikt, hoe deze documenten gebruikt worden, hoe deze documenten hun weg vinden van de ene gebruiker naar de andere en hoeveel tijd er voor elke stap of taak staat voor deze af moet zijn. Opzet van een context free grammar Wat moet een taal kunnen die een workflow systeem moet kunnen beschrijven. Er moeten natuurlijk verschillende fases in de workflow aangegeven kunnen worden. Hiervoor introduceren we een step. Een step heeft een aantal attributen. Hierbij moet men denken aan de attributen actor, duration en date due. De actor is de persoon die de betreffende step uit moet gaan voeren, de duration de duur van de step en date due de datum waarop de betreffende step uiterlijk voltooid moet zijn. Voor specifieke gevallen van een workflow systeem zal deze taal natuurlijk nog moeten worden uitgebreid om meerdere mogelijkheden te bieden. Een voorbeeld, wat reeds in de opdracht genoemd is, is de workflow binnen ons instituut aangaande het houden van een examen sessie. 1. 2. 3. 4. 5.



reserving a room, entering it on the web site having the exam checked by someone else having the exam session (who are e.g. the actors here) distributing the exam for marking, and collecting and computing final results communicating the preliminary results to the students and having them entered in Osiris 6. checking that the marks were entered correctly 7. signing the final exam form 8. communicating the definitive results to the students Waarschijnlijk ontbreken er hier enkele stappen, maar het gaat voornamelijk om het uitwerken van het idee en niet om de specifieke details. In de eerste stap van deze workflow omschrijving staat reeds een object genoemd wat tot op heden niet bestaat in onze taal, namelijk een room. Dit object kan een paar attributen hebben als roomNumber en building. Dat maakt op zich weinig uit voor het principe. Wat echter wel belangrijk is dat een step een extra attribuut krijgt van het type room.



 De grammatica zelf Zo kan men dus een grammatica opstellen voor een workflow. workflow = (id, step+) id = int step = (action, actor+, duration, date due, room*) actor = (name, age, …) duration = int date due = date room = (building, roomNumber) action=string Uitleg bij de grammatica Een workflow bestaat uit 1 of meer step’s omdat een workflow van 0 step’s geen workflow is. De workflow heeft ook een idnummer om de workflow te onderscheiden van andere workflows. Dit idnummer zou ook een naam kunnen zijn en deze workflow zou dan het houden van een examensessie heten. Een step bestaat uit een action, 1 of meerdere actors, een duration, een datedue en 0 of meerdere rooms. Een step moet altijd 1 actor hebben die de step uitvoert. Dit hoeft geen menselijk iemand te zijn maar kan ook bijvoorbeeld het automatische zaalreserveringssysteem zijn. Om dit zelfde voorbeeld dan maar te gebruiken, een examen wordt wel in een zaal gehouden, een reservering daarentegen gebruikt geen zaal. Vandaar dat niet elke step een zaal heeft. De action beschrijft wat er moet gebeuren in deze step. Dit kan dus het houden van het examen zelf of het invoeren van de cijfers in Osiris kunnen zijn. Deze beschrijving mag op zich best uitgebreid zijn. Een actor is dus een persoon of machine die de step uitvoert. In dit voorbeeld van de examensessie worden alle steps uitgevoerd door mensen maar dit hoeft natuurlijk niet in alle gevallen zo te zijn. Het kan ook dat de actor een groep is. Dit betekent dat de step uitgevoerd kan worden door een willekeurig lid van die groep. Duration staat voor de tijd die de step in beslag neemt. Dit kan enkele seconden zijn (het reserveren van een zaal) tot enkele uren (het nakijken van het materiaal). Date due is de datum waarop de step op z’n minst voltooid moet zijn. In het geval van het nakijken van de examens is dit dus 30 dagen. Een room bestaat uit een building en een roomNumber. Dit omdat in meerdere gebouwen zalen kunnen zijn met hetzelfde nummer. Door het gebouw erbij te vermelden worden deze zalen van elkaar onderscheiden.



 Workflow Domain Specific Language



Het doel van deze opdracht is om een ontwerp te geven van een domein specifieke taal voor een workflow system.



Concepten Er zijn verschillende concepten die in veel workflows naar voren komen. De volgende concepten zijn de meest veelvoorkomende: - Task - Actor - Job - Event - Status - Date due Een Job is een op zichzelf staande opdracht die voltooid moet worden. Deze is onderverdeeld in verschillende taken, oftewel Tasks, die allemaal afgerond moeten zijn wil de Job afgerond zijn. Een Task kan weer uit verschillende subtasks bestaan. Een Task moet worden uitgevoerd door één (of meerdere) Actor(s), dat een computer of een persoon kan zijn. Voordat er aan de Task kan worden begonnen moet er aan alle pre-condities, oftewel Events, voldaan zijn. Als een Task klaar is kan dit een post-Event (of meerdere) genereren, die weer door andere Tasks als pre-Event nodig zijn. Neem als voorbeeld de case study van een ‘exam session’, er moet een kamer gebouwd zijn voordat die kan worden gereserveerd. Een Task kan een Status hebben, bijvoorbeeld ‘waiting’ of ‘finished’ en ook een datum en tijd wanneer het af moet zijn, de Date due. Een Job kan ook een status, datum en tijd hebben wanneer het af moet zijn. Een Actor is niet gebonden aan een Task, hij kan meerdere Tasks uitvoeren.



Relaties Tussen deze concepten bestaan er verschillende binaire relaties, de belangrijkste zijn (in natuurlijke taal): - have - is - produce - requires have: geeft aan dat een workflow entiteit een atribuut is van een ander. 'Task have Status' geeft aan dat een taak een bepaalde status heeft. is: geeft aan wat een bepaalde workflow entiteit is. 'exam is Task' geeft aan dat een examen afnemen een taak is. produce: geeft aan wat voor resultaat, welk Event, een Task genereerd als deze afgerond is. requires: geeft aan aan welke Events er voldaan moeten zijn voordat er aan de Task kan worden begonnen. Het volgende is een grammatica van een taal die een workflow bestaande uit bovenstaande concepten en binaire relaties kan beschrijven. De taal kan o.a. worden gebruikt om uitleg te geven over een bepaalde workflow entiteit en om atributen zoals Actors en Status aan bepaalde workflow entiteiten toe te kennen. Ook kan de taal opvragen wat de toekenningen aan een bepaalde workflow entiteit zijn, zoals wie de Actor van een bepaalde Task is.



 GRAMMATICA - De productieregels: Methods -> State | Ask State -> Staterelations | Staterecords Ask -> Askrelations | Askrecords Staterelations -> Symbols (Relation_term ',')* Relation_term ';' Relation_term -> Symbol_is Concept | Symbol_have List | Event Symbols Event -> 'produce' | 'requires' Concept -> 'Job' | 'Task' List -> '{' Compound '}' Compound -> ( Symbols ',' )* Symbols | ( Record ',' )* Record Record -> 'Actor' | 'Status' | 'Date_due' Askrelations -> Symbols ( Relation '?,' )* Relation '?;' Symbol_is -> 'is' Symbol_have -> 'have' Relation -> Symbol_is | Symbol_have | Event Staterecords -> Record Symbols Symbol_is Symbols ';' Askrecords -> Record Symbols 'is?;' Symbols -> ' " ' character character* ' " ' Symbols representeerd hier gewoon tekst tussen aanhalingstekens. Een context vrije grammatica bestaat uit een vier-tuple (T,N,R,S). De terminal symbols T zijn hierboven de gewone woorden of karakters tussen ' ' tekens, zoals 'is?;' of '{'. De nonterminal symbols N zijn de gewone woorden, zoals Methods of Askrecords. De productieregels R staan hierboven en het nonterminal start-symbol is Methods.



Case Study Als voorbeeld neem ik de case study "exam session" die ik gedeeltelijk zal beschrijven in de DSL. {-"exam session" is Job, have { "assigning and notifying proctor", "making room", "reserving a room", "enter room on website", "dubbel check exam", "exam", "distribute exam", "collecting and compute result", "prelimanary results to students and Osiris", "check entering marks", "sign final exam", "final results to students"}; "assigning and notifying proctor" is Task, have {Actor, Status, Date_due}, produce "proctors"; "making a room" is Task, have {Actor, Status, Date_due}, produce "room"; "reserving a room" is Task, have {Actor, Status, Date_due}, produce "reserved room", require "room"; "enter room on website" is Task, have {Actor, Status, Date_due}, produce "room on website", requires "reserved room"; "dubbel check exam" is Task, have {Actor, Status, Date_due}, produce "exams"; "exam" is Task, have {Actor, Status, Date_due}, produce "student exams", requires {"exams", "room on website", "proctors"}; --} Je ziet hier dat "exam session" een Job is en dat die bestaat uit vele taken (tussen de brackets). Al deze taken hebben een Actor, Status en Date due. Deze taken kunnen ook weer iets produceren. Voordat er aan sommige taken begonnen kan worden moet er aan alle requirements voldaan zijn (de lijst na 'requires' tussen de brackets). Op deze manier is de gehele workflow te beschrijven. Atributen aan een workflow entiteit toekennen doe je op de volgende manier. {--



 Actor "making a room" is "Robert"; Status "exam" is "finished"; Date_due "exam session" is "16-4-'03"; --} Om vervolgens op te vragen welke Actor de Task "making a room" uitvoert e.d. specificeer je het volgende. {-Actor "making a room" is?; Status "exam" is?; --} Het workflow systeem zal op deze vragen respectievelijk - Actor "making a room" is "Robert"; - Status "exam" is "finished"; antwoorden. Ook kan je informatie opvragen over de verschillende workflow entiteiten, dat gaat als volgt. {-"exam session" is?; "exam" have?; "exam" produce?, requires?; --} Het systeem zal antwoorden: - "exam session" is Job; - "exam" have {Actor, Status, Date_due}; - "exam" produce "student exams", requires {"exams", "room on website", "proctors"};



Tot Slot De hierboven beschreven taal kan nu dus een workflow beschrijven en ook informatie over deze genereren. Ook kan de taal specifieke feedback geven. Als bijvoorbeeld "exam session" niet bestaat dan kan het systeem als antwoord het volgende geven: "exam session" is "NOT DEFINED". Omdat de syntax erg lijkt op de natuurlijke taal is dit makkelijk te leren.



 Datum: 09-09-2002



Domain Specific Languange voor een Workflow systeem (Opdracht 2 van IST)



Opdracht: Ontwerp een Domain Specific Language (DSL) voor een workflow systeem. Overzicht: Eerst komen de belangrijkste concepten in workflows aan bod. Hierbij worden ook de eigenschappen en relaties tussen deze concepten beschreven. (De concepten en eigenschappen staan in het Engels en beginnen met een hoofdletter. Deze concepten zullen verderop gebruikt worden bij het maken van de DSL). Vervolgens wordt er een context vrije grammatica beschreven van een taal die zou kunnen dienen als invoertaal van een hypothetisch workflow systeem. Deze werking van deze DSL zal vervolgens worden geïllustreerd aan de hand van een case studie.



De belangrijke concepten in workflows en eigenschappen en relaties tussen deze concepten Het voornaamste concept in workflows is de Task. Een workflow systeem krijgt een een aantal taken als input en moet deze omzetten naar een geschikte workflow. Hierbij moet het workflow systeem rekening houden met de datum waarop een taak klaar moet zijn. Sommige taken kunnen pas worden uitgevoerd wanneer ander taken zijn afgerond. Een Task wordt uitgevoerd door één of meerdere Actors, deze kunnen vooraf een taak toegewezen krijgen, maar het is ook mogelijk dat het workflow systeem Actors gaat toewijzen aan taken. Het workflow systeem moet dan weten welke Actors er aanwezig zijn en hoeveel tijd er voor elke taak staat (EstimatedTime). Aangezien het mogelijk is dat een taak slechts kan worden uitgevoerd door een Actor met bepaalde bevoegdheden of kennis, zullen we ook Skills van de Actor en de benodigde Skills voor een Task moeten weten (voor zover deze aanwezig zijn). Aan de hand van deze gegevens zou een workflow systeem Actors kunnen toewijzen aan taken. De Actor dient dan echter wel beschikbaar te zijn, dus moet de Status van de Actor worden bijgehouden door het workflow systeem. Er kan een Priority worden toegekend aan een Task om deze taak voorrang te geven ten opzichte van andere taken.



Context vrije grammatica Hieronder wordt een context vrije grammatica beschreven, van een taal die zou kunnen dienen als de invoertaal van een hypothetisch workflow systeem Tasks



->



MTask+



MTask



->



Task | Tasks TaskRelation Tasks



Task



->



TaskID Description StartDate? EstimatedTime DateDue? Actor* RequiredSkills* RequiredTaskID* Priority?



TaskRelation



->



precedes | follows



Actor



->



ActorID Skill* Status?



RequiredSkills



->



Skill+



Status



->



available | unavailable



TaskID is een string variabele (kan ook een nummer zijn). Description is een string variabele. StartDate en DateDue zijn datum variabelen (mogelijk met tijd en tijdzone).



 EstimatedTime bevat de verwachte hoeveelheid tijd die de taak in beslag zal nemen. Het is mogelijk dat de StartDate en/of de DateDue van een taak niet bekend zijn en dat het workflow systeem dit zelf zou moeten bepalen. ActorID is een string variabele (zoals de naam van de Actor). Onder Skill wordt verstaan, welke taken de Actor kan uitvoeren, bijvoorbeeld of de actor bevoegd is om een bepaalde taak uit te voeren. De constructie van RequiredSkills is geschikt om de en-relatie en of-relatie te construeren. RequiredTaskID geeft aan dat de taak met dit TaskID moet zijn afgerond voordat aan de taak begonnen kan worden, waarin dit TaskID als RequiredTaskID is opgenomen. Priority is een getal variabele. Er wordt vanuit gegaan dat het workflow systeem weet welke Actors er aanwezig zijn. De taal is zo geconstrueerd dat het ook mogelijk is om de workflow op te slaan in deze taal, dit is mogelijk door middel van de TaskRelation die het mogelijk maakt om de volgorde van de taken op te slaan.



Illustratie van de bovenstaande DSL d.m.v. een case studie Hier wordt een beperkte workflow besproken van het maken van een website door een Webdesign bedrijf. 1. Bespreken van de inhoud, doel, mogelijkheden en uiterlijk van de site met de opdrachtgever. 2. Maken van een ontwerp en planning. 3. Maken van een kostenraming. 4. Laten goedkeuren van het ontwerp en tekenen van contract. 5. Uitwerken van het ontwerp. 6. Implementeren en documenteren van het ontwerp. 7. Testen van het ontwerp. 8. Presenteren aan de opdrachtgever. Hier volgt de input voor de hypothetische workflow systeem [ “task 1” “bespreking: inhoud, doel, mogelijkheden en uiterlijk met de opdrachtgever” [05-09-2002 15:00 GMT] 2 hours [] [ [“J.Jansen” [“Webdesigner”] [available] ] ] [[“Webdesigner”]] [] [] ,“task 2” “maken van een ontwerp en planning” [] 40 hours [12-09-2002 12:00 GMT] [ [“J.Jansen” [“Webdesigner”] [] ], [“T. Spong“ [“Webdesigner”] [] ] ] [[“Webdesigner“]] [“task 1”] [] ,“task 3” “maken van een kostenraming” [] 8 hours [12-09-2002 12:00 GMT] [[“J. Doe”[] [] ]] [[]] [“task 2”] [] ,”task 4” “Laten goedkeuren van het ontwerp en ondertekenen van contract” [12-09-2002 14:00 GMT] 4 hours [] [ [“M.Johansen”[“bevoegd om contracten te ondertekenen”] []] ] [[“bevoegd om contracten te ondertekenen”]] [task 3] [] ,“task 5” “Uitwerken van het ontwerp” [] 60 hours [] [ [“J.Jansen” [“Webdesigner”] [] ]] [[“Webdesigner”]] [“task 4”] [] ,“task 6” “Implementeren en documenteren van het ontwerp” [] 300 hours [] [ [“K. Kuit” [“Webprogrammeur”] [] ]] [[“Webprogrammeur”]] [“task 5”] [] ,“task 7” “Testen van het ontwerp” [] 50 hours [] [] [[“Doelgroep gebruiker”]] [“task 6”] [] ,“task 8” “Product presenteren aan de opdrachtgever” [12-09-2002 14:00 GMT] 2 hours [] [] [] [“task 7”] [] ]



Deze illustratie is tekst-gebaseerd, maar het zou natuurlijk heel goed via een GUI geprogrammeerd kunnen worden, wat het voor de gebruiker vele malen makkelijker zou maken. De bovenstaande manier is gebaseerd op de Haskell notatie en deze kan nogal onduidelijk worden voor de gebruiker vanwege de geneste []. Men kan een GUI maken die duidelijk aangeeft waar een taak uit bestaat en welke gegevens ingevoerd moeten worden.



 A Domain-Specific Language for a Hypothetical Workflow System



Utrecht University Institute of Information and Computing Sciences Introduction to Software Technology September 10, 2002 Abstract This paper presents a brief overview of a small domain-specific language for a hypothetical workflow system.



1



Introduction



As an very small example of a domain-specific language, we will show the design of a simple language that can be used to describe classes of processes that may serve as input for a fictitious workflow system. Not all aspects of our example language will be addresses: this paper only provides a brief overview; lots of details are left out. We consider a hypothetical workflow system. This system is supposed to support simple processes. These processes are composed from one or more subprocesses. In this manner processes and subprocesses form a tree. The leafs of such are tree consist of atomic processes, which we will call activities. Activities are performed by actors. An actor is a user of the system that is registered as such in some kind of database that is maintained by the system. Actors are identified by a unique user name. Users are assigned roles. A process may have some associated values. Some of these values are used to guide the process and serve as input for the process. Other values are results of the process and can be considered output. A process will experience progress. This progress is captured in a distinction between two or more stages of a process, which we will address to as states. Special states are the initial state or start state, which is entered when the process is initialized, and the end state, which occurs when the process is finished. In most processes that are supported by workflow systems, it is important that a certain activity is perfomed within a given amount of time: this is crucial for planning. The above sketches only the minimal characteristics of processes and activities that can can be handled by a modern workflow system. In such a system the view on processes will be much more complicated—but for our purposes this simple model will be sufficient. 1



 We will now provide an example a class of processes that can be handled by our system. After that, we will discuss the syntax of a small language that was designed to model these kind of processes. To illustrate the use of this language, an example program is given.



2



An Example: Scheduling Exams



We will look at the scheduling of an exam for a certain course at a university. When a course is taught in a given academic period, an exam usually has to be taken in the last week of that period. An exam has to be scheduled before it can actually be taken. Scheduling a exam involves reserving a room. This is done by a scheduler and should have ultimately been taken care of four weeks before the last day of the exam period. The result of the reservation process is an assignment of the exam to a room and a time slot. When a reservation is made, a webmaster can publish the exam data on the institute’s webpages, and—at the same time— proctors can be scheduled by a scheduler. Finally, the exam is taken on the scheduled date by the course’s professor in the presence of the assigned proctors.



3



Syntactic Grammar



We will now present the syntactic grammar of out domain-specific language for modelling classes of processes similar to the process described in the previous section. We will not provide a lexcical syntax. For some nonterminals in the syntactic grammar productions are missing; for these, either the production is trivial or the production is too verbose for our purposes. P rocessDef inition



−→



(P rocessDeclaration | ActivityDeclaration)∗



On the highest level, we define process and activity classes. P rocessDeclaration −→ P rocessM emberDeclaration



−→



process Identif ier { (P rocessM emberDeclaration) ∗ } ContainedActivityDeclaration | HandlerDeclaration | P arameterDeclaration | StateDeclaration | SubprocessDeclaration | V ariableDeclaration



A process is declared by the keyword process followed by an identifier. Then, between curly brackets, a further specification of the process is provided. P arameterDeclaration −→ (input | output) T ype Identif ier ; T ype −→ Date | DateRange | Int | String | StringList | Time | User 2



 For each process we can define a set of typed input and output parameters. Our language does not provide a rich type system: in fact, for now, it only incorporates the types needed to model our example process. V ariableDeclaration



−→



var T ype Identif ier ;



We can declare variables that allow us to store some intermediate data for a process instance. StateDeclaration −→



state ([ end ])? Identif ier ;



Each process can define a set of states. A process should define at least one end state. Furthermore, each process automatically gets a special state definition for the start state. This state is called init. SubprocessDeclaration −→ process Identif ier Identif ier ; ContainedActivityDeclaration −→ activity Identif ier Identif ier ; Within a process definition, we can define subprocesses using process and activity declarations. HandlerDeclaration −→



(ending | entering) Identif ier { Statement ∗ }



A process definition contains a description on how certain events related to the process are handled. We make a distinction between two kind of events. The first kind of event is triggered when a subprocess is ended. The second kind deals with state transitions. A sequence of statements can be provided to indicate the handling of these events. Statement −→



AssignmentStatement −→ Assignment −→ P erf ormStatement −→



ArgumentList −→ P erf ormStatementClauses −→ StartClause DueClause T ransitStatement T riggerStatement



−→ −→ −→ −→



AssignmentStatement | P erf ormStatement | T ransitStatement | T riggerStatement Assignment ; Identif ier = Expression perform Identif ier OpeningP aren ArgumentList? ClosingP aren by Expression P erf ormStatementClauses? ; Assignment (, Assignment)∗ StartClause (, DueClause)? | DueClause start Expression due Expression transit Identif ier trigger Identif ier OpeningP aren ArgumentList? ClosingP aren ;



Statements vary from simple variable or parameter assignments to triggering of subprocesses. We won’t discuss the details of this statements here: most of them are quite intuitive. The language provides support for simple expressions 3



 and provides a small set of functions—for example, a function that selects a user that is assigned a certain role. ActivityDeclaration



−→



activity Identif ier { (P arameterDeclaration) ∗ }



An activity only defines some input and output parameters. The output parameters are entered into the workflow system by an activity’s actor.



4



Example code



The following listing is a program written in our domain-specific language that models our exam-scheduling example. process Exam { input String course; input User professor; input DateRange period; state scheduled; state [end] taken; subprocess Scheduling scheduling; activity Taking taking; var var var var



Date Time String StringList



date; time; room; proctors;



entering init { trigger scheduling ( course = course, professor = professor, period = period; ); } entering scheduling { perform taking ( course = course; proctors = proctors; ) by professor, start date, due date; transit taken; } ending scheduling { date = scheduling.date; time = scheduling.time; 4



 room = scheduling.room; proctors = scheduling.proctors; transit scheduled; } } process Scheduling { input String course; input User professor; input DateRange period; output output output output



Date Time String StringList



date; time; room; proctors;



state roomReserved state [end] proctorsScheduled; activity ReserveRoom reserveRoom; activity ScheduleProctors scheduleProctors; activity PublishInfoOnWeb publishInfoOnWeb; entering init { perform reserveRoom ( course = course; professor = professor; period = period; ) by (select Scheduler), due (end(period) - 28); } entering roomReserved { perform scheduleProctors ( course = course, professor = professor, date = date, time = time, room = room ) by (select Scheduler), due (end(period) - 14); perform publishInfoOnWeb ( course = course, professor = professor, date = date, time = time, room = room ) by (select Webmaster), due (end(period) - 21); }



5



 ending reserveRoom ( date = reserveRoom.date; time = reserveRoom.time; room = reserveRoom.room; transit roomReserved; ) ending proctorsScheduled { proctors = proctorsScheduled.proctors; transit proctorsScheduled; } } activity ReserveRoom { input String course; input User professor; input DateRange period; output Date date; output Time time; output String room; } activity ScheduleProctor { input String course; input User professor; input Date date; input Time time; input String room; output StringList proctors; } activity Taking { input String course; input StringList proctors; }



5



Conclusion



We showed an design for a simple domain-specific language for processes in a workflow system. Our design is limited in application and served only as a brief example of a domain-specific language. The use of the language was illustrated by a small case-study.



6



 Domain Specific Language voor een Workflow Systeem.



Mijn domein specifieke taal zal bedoelt zijn om een workflow systeem voor een internationaal postorder bedrijf te implementeren, zoals Bol en Amazon. Als eerste zal ik een beschrijving geven van de actors, objects, tasks/actionsdie in hets systeem zitten. Vervolgens zal ik een workflow diagram geven, die het systeem dat ik met de taal wil gaan implemteren beschrijft. Als laatste zal ik dan een context vrije grammatica geven voor het systeem. Actors: • • • • •



Leverancier PostOrder bedrijf Interne vervoerder Vervoersbedrijf(denk aan schepen/vliegtuigen voor intercontinentaal vervoer) Klant



Objects • VHS • Cd /dvd’s • Boeken Tasks • • • • •



Object ontvangen van leverancier Object wordt bestelt Verwerk bestelling Object door sturen aan vervoerder Object brengen naar de receiver



Dit is wel een vrij globale definatie van de verschillende aspecten in het systeem. Het kan natuurlijk veel uitgebreider door ook de interne structuur van de Online boekhandel tegeven, zoals de weg die bestelling helemaal aflegt voordat er ook maar een boek of film wordt verzonden. Helaas kan dat niet worden gespecificeerd in 2 à 3 kantjes.



 Relationeel diagram: Hieronder modelleren we de specificatie in een flowdiagram: Vervoersbedrijf



Interne vervoerder



Verstuurt via



Verstuurt via Onlineboekhandel



Bezorgt



Klant



Besteld fd



Bezorgt ert Levert obeject



Levert er t Levert obeject



Leverancier



Context vrije grammatica: Nadat we een globale specificatie van ons workflow systeem hebben gegeven gaan we nu over tot het ontwerpen van de Domain Specific Language. Dit doen we door een context vrije grammaticab te gegeven van de taal :



MyWorkFlowSystem := (Decls+ Action)+ Decls := Decl Decls* Decl := Group;| Object; Group := (Actor *) Actor := String Object := String Actions := { Conditions+ } // Alle acties in het systeem moeten gecheckt worden alvorens ze worden uitgevoerd Conditions := if Expr then DoSomething else DoSomething Expr := Boolean expressie zoals die in java kunnen voor komen. DoSomething := Actions | Do Do := Deliver Object+ to Group | Send Object+ to Group | Make Order* Handle Order



 Order



:= Group Object*



NOTES: Het is wel een vrij globale opzet geworden. Ik vond het nog erg lastig om een context vrije grammatica te geven. Ik denk dat als je echt een goede flexibele taal wil ontwerpen, je dan eerst uit moet gaan van een globale opzet van je grammatica en van daaruit je grammatica verder moet gaan verfijnen.



 Workflow of the production of a computer (simplified)



Importer



imports computer parts



Motherboard



CPU



Videocard



Hard disk



Assembler person



Assembles the computer parts into a computer



Computer



Puts the computer in a box



Assembler person



results in



Computer in a box



many computer boxes go into a container



Container



many containers with computers go into a ship



Ship



the container go into a truck



Truck



Memory



Case



 Context free grammar Import -> param Assemble -> param | param Transport -> param | param load -> param | param unload -> param | param Sell -> param List-type ::== type-atom Type-atom ::== base-type Base-type ::== computerPart | computer | container Param ::== var Var ::== varstartchar Varstartchar ::== [a – z, A – Z] Paramlist ::== param | param paramlist



A simple program Import -> “Motherboard” Import -> “Videocard” Assemble -> “Motherboard”, “New computer” Assemble -> “Videocard”, “New computer” Load -> “New computer”, “Container” Transport -> “Container”, “Truck” Unload -> “Container”, “Truck” Transport -> “Container”, “Sea ship” Unload -> “Container”, “Sea ship” Unload -> “New computer”, “Container” Transport -> “Container”, “Truck” Sell -> “New computer”



Explanation of the example program: First the computers parts, such as a motherboard and a video card are imported. After that, the computer parts are assembled in a new computer. When the new computer has been completed, the computer will be loaded into a container. The container will be loaded in a truck. The truck will transport the container to a shipyard and will load the container into a sea ship. The sea ship will transport the container to a destination point and will unload the container. The container will be unloaded and the computer boxes will be transported by truck to a reseller. The reseller will sell the new computers.



 A Proposal for a Domain Specific Language for Managing Workflow



September 10, 2002



Abstract We briefly sketch the problem of workflow management and then describe a domain specific language for dealing with modeling workflow. Finally we examine a case study to illustrate how to use the mini-language.



Workflow A workflow management system is designed to control the flow of data from one processing point to another. We begin by designing a workflow management system which merely describes in which sequence data must be passed around. First of all, a user should be able to create a new process point: Syntax: new process (p) Given a valid identifier this creates a new process. Each process can be referred to by its name. However we want to describe the flow of data between processing points: Syntax: flow from p to q This states that after the process p the data passes to the process q. Basically, we model the flow of data by a graph, where the processing points form the vertices and edges describe the flow of data.



Data Now we know how to pass around data, we can consider creating and manipulating the data itself. We assume that the data that pass through our graph are of the same type. The data could consist of everything from insurance claims to bug reports, but there should be some common structure. First of all, a new piece of data has to be registered by the workflow system. Syntax: new data returns an unique key to associate with this piece of data. Now every process should be able to state when it is done with a piece of data, so that it can be passed to subsequent processes. Syntax: p finished with key Note that this does not guarantee that the data is indeed passed on to subsequent processes. If, for instance, two processes are handling the same piece of data in parallel, it can only be passed on to a single subsequent node when both are finished with it. Typically, this command would then notify the next processing points that they must now deal with this piece of data. 1



 A processing point may want to pass information about a piece of data to later points. Rather than edit the data itself, we allow the creation and manipulation of fields. Syntax: new field f In practice, the user should also specify the type of the values which can be stored in the new field. However, as we want to keep our language as simple as possible, we will omit such details for now. The value stored in a field can be changed at a processing point. Syntax: set f in key to val Once again we will not worry about what values can be stored in a field, but only concern ourselves with how they can be changed. It seems odd that a workflow system should occupy itself with the manipulation of data or data fields. However, it is not uncommon that the action performed at one processing point, depends on the result of another. This justifies keeping track of results within the workflow system, which is exactly what is done by the fields, as proposed above.



Conditional edges We may want to attach conditions to edges in our graph. Depending on the results of other processes, data will flow in one way or another. For example if a bug is discovered, a new software package should be tested, if not, it can be marketed. Creating an edge with a condition attached to it can be done by: Syntax: only flow from p to q if (C) Now the question arises, what conditions are. We provide the following grammar for a condition: C → data . f is val | (C) ∧ (C) | (C) ∨ (C) ¬(C) There are probably many other useful extensions to this grammar, but it will satisfy our purposes for now. We assume a condition to be either a check if a field in the data received is equal to some value or the composition of other conditions using common logical operators. An application of all this mini-language is discussed below in a case study.



Case study: handling insurance claims Insurance companies receive tremendous amounts of claims. They must investigate each claim to check if the applicant is eligible for financial compensation and if so, honour it. The following model for insurance claims is largely based on an example in [3]. When a claim is received it is registered and the type of claim is determined. Every insurance policy is assumed to have some type associated with it, for example a life insurance or a travel insurance. Subsequently, the insurance company must check that the claim is covered by the claimant’s policy and that the claimant has paid his insurance premium. Based on these observations the company must decide whether to reject the claim or continue and determine exact compensation. Once the amount to pay has been established this can be communicated to the claimant. Hopefully he or she will agree, and the claimant will be indemnified and the claim archived. If the claimant disagrees with the insurers decision, the insurer must either review the claim or take the dispute to court. This whole process can be 2



 summarized in the following diagram: Registration ?



Determine type HH   j H



Policy HH j



Premium



 



Evaluation H  H   j H



Rejected



Determine indemnification ?



6 - Objection



?



Court



Reaction



Payment 



?



?



Close



Note that the controlling of a claimant’s policy and checking if the premiums have been paid can be performed in parallel. Of course this workflow is far from complete. It does not take urgent claims into account and restricts itself to the interaction between the claimant and the insurer. There are no other parties involved, such as experts to determine the amount to be reimbursed or lawyers to settle disputes. It is however sufficiently complicated to give some idea of how to manage a workflow system using our language. First of all, we should make processing points for almost each stage in the above diagram: new process Registration; new process Determination; new process Policy; . . .; new process Close Next we should add all the edges which are traversed unconditionally: flow from Registration to Determination; flow from Determination to Policy; flow from Determination to Premium . . . Now we examine data creation and manipulation, before adding the conditional edges. Once the first claim is received, it is registered and a new key is created with new data. Then it is passed on, so its type can be determined. This can be stored in a special field. When the policy and premium corresponding to this claim are looked up, this information is once again stored in a field. The edges exiting from Evaluation are conditional edges. Hence they should be created as: only flow from Evaluation to Rejected if (data . premium is unpaid) ∨ (data . policy is uncovered) The other edge is defined similarly. The amount to be indemnified can once again be stored in a field, once it has been determined. Once the claimant reacts to an offer this information determines where the claim goes next. Again conditional edges guide the claim through to the subsequent process. Once a client rejects an offer, the insurer must decide to take a claim to court or review it. Based on this choice, the claim continues through the diagram, until it is paid and closed. We can see that it is fairly straightforward to describe how to pass around data and what to do with it, despite the many faults of our language.



3



 Conclusions The language described is far from complete. It does not really describe what actions are performed at a processing point. Malicious users could simply pass on data without doing what they were expected to do. There are no limits as to how long data can stay in one point or when some action should be finished. We do not discuss what values can be stored in fields, as this would complicate matters beyond the scope of such an exercise. Neither do we keep track of who performs tasks, we only notice if they are performed. There are a lot of things missing and a lot of questionable decisions. Yet the case study shows that the mini-language is expressive enough to model simple workflow problems, which was after all our initial purpose.



References [1] www.diffuse.com/workflow.html. [2] www.wfmc.org. [3] Wil van der Aalst and Kees van Hee. Workflow management. Academic Services, 1997.



4