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; CED.FHGJI)KLD.C MONQP.G RTSVUVWHX YLZ[]\_^>`2Z[badcfeHghei^YLji\Vk Z[ba]cfeigheH^lYLjH\Jk RmZ[badcfeHghei^YLji\ ` n Z[badcfeHghei^YLji\ `2Z[ba]coeHghei^YLji\Vk Z[ba]cfeigheH^lYLjH\ Rmead^pjig n n ead^yrq&yr^ls ^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 n kltj[ba]y []g 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 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 V i Jˆ QS A ;>=B œ «ªd " " Ē? 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Í ÍQÍ W S J Ÿ ~ 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Ÿ )Œ3W.S)Œ&Ÿ~± Q Q± ÍQÍ US Â8WQW~Œ&±3Ÿ ) ŸQSˆ3 Ï V JW. VˆŸ)WU )ŒJŒ.SQŽ WHS3 )Œ&Ÿ~±ÏSVU 3±V SQÆ)Œi3 JWHSVîŸJ $³ ÍQÍ J Ÿ Ẅ Vˆ _ S )Œ3W J _Œ V 3 ~ V ~3ˆ V ÏUJWQWQŒ.±3ŸJ 3 ¼Vˆ>³ ÍQÍ ~ V Q3ˆ J Ë V JW. JîŸ)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î 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Æ)ŒH3 VW.SVîŸJ 3 Vˆ& ] ˆŸV 8Œ& i JÎQ ~±œ¾ä V JWˆQi 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ŽÌẄ Jˆ 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 Computer system Task Process subscription Actor Distribution employee Task Send out magazine 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 3 2.1 Concrete grammar............................... 3 2.2 Abstract grammar............................... 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>, </WFTD>, <WF name=, version=, <ACTIVITY name=, />, </ACTIVITY>, <A_COND>, </A_COND>, <PRE cond=, <POST cond=, <TC>, </TC>, <WFRD name=, path=, </WFRD>, <ROLE name=, entity=} N = {WFTD, Activity, ACond, Pre, Post, TC, WFRD} S = WFTD P = { p0: WFTD <WFTD> WF Activity WFRD </WFTD>, p1: WF <WF name= name version= version />, p2: Activity <ACTIVITY name= name > ACond Role TC </ACTIVITY> Activity, p3: ɛ, p4: ACond <A_COND> Pre Post </A_COND>, p5: Pre <PRE cond= condition />, p6: Post <POST cond= condition />, p7: TC <TC cond= condition /> TC, p8: ɛ, p9: WFRD <WFRD name= name path= path /> WFRD, p10: ɛ, p11: Role <ROLE name= name entity= entitity /> Role, p12: ɛ } 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: WFTD WF Activity WFRD, p1: WF name version, p2: Activity name ACond Role TC Activity, p3: ɛ, p4: ACond Pre Post 3
, p5: Pre condition, p6: Post condition, p7: TC condition TC, p8: ɛ, p9: WFRD name path WFRD, p10: ɛ, p11: Role name entitity Role, p12: ɛ } 4
A Example <WFTD> <WF name="exam session" version="1.0"/> <ACTIVITY name="assigning proctors> <A_COND> <PRE cond="none"> <POST cond="making a room"> </A_COND> <ROLE name="select" entity="proctors"/> <TC cond="proctors.ready"/> </ACTIVITY> <ACTIVITY name="reserving a room> <A_COND> <PRE cond="assigning proctors"> <POST cond="having the exam"> </A_COND> <ROLE name="select" entity="rooms"/> <TC cond="rooms.available"/> </ACTIVITY> <ACTIVITY name="having the exam"> <A_COND> <PRE cond="reserving a room"> <POST cond="communicating results"> </A_COND> <ROLE name="solve exam" entity="students"/> <TC cond="exams.finished"/> </ACTIVITY> <ACTIVITY name="communicating results"> <A_COND> <PRE cond="having the exam"> <POST cond="none"> </A_COND> <ROLE name="correct" entity="proctors"/> <ROLE name="notify" entity="students"/> <TC cond="exams.corrected"/> <WFRD name="teachers" path="/teachers"/> <WFRD name="students" path="/students"/> <WFRD name="rooms" path="/rooms"/> <WFRD name="proctors" path="/proctors"/> </ACTIVITY> </WFTD> 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("OSIRIS-Terminal", 2) // Create Actors available to this domain Actor("Proctor", 3) Actor("Student", 10) Actor("Examiner", 3) Actor("Administrative", 1) // Create Tasks and assign necessaries Task( "AssignProctors", // Resource (description, // quantity) // Actor (description, // quantity) // 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 = Naam Task_Properties Task_Properties = (Depends_On)* Omschrijving Resultaat Closed Initiator (Actor)+ (Receiver)* (Object)* Date_Due Date_Created Depends_On = Task Closed = Boolean Initiator = Person Actor = Person Receiver = Person Object = Person
IST Assignment 1 Resultaat = Document Document = Naam Location Person = Naam Adres Woonplaats Email Date_Due = Date Date_Created = Date Naam = String Adres = String Woonplaats = String Email = String Omschrijving = String Location = 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
May refer to Workflow type definition Consists of uses has Role Activity Workflow Relevant Data May have uses Transition Conditions Invoked Applications May refer to 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
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 <Actor Name> For Example: The following statement will create an actor, namely Proctor01 AddActor Proctor01 Remove an Actor RemActor <Actor Name> Where <condition> 4.2 Activity Add an Activity AddAct <Activity Name><Actor Name> Where <condition> 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 <Activity Name> <Activity Type> Where <condition> Associate application to activity AssociateApp <Application Name> <Activity 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 <Transition Name> <From Activity Name> <To Activity Name> 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> <Activity Name> <Actor Name> <Result> 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. 7. 8. 5.a. 6. 9.* 1. 2. 3. 4. 5. 6.b. 5.b. 9.b. 9.* 9.a. 10. 11. 12. 13.a. 14. 16. 17. 15. 15. 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.,QNRSHU makes an RUGHU at the dealer 2. Goods come in at the company and the PDJD]LMQPHGHZHUNHU accept signs the RUGHU 3. 6DOHVPDQ sales an item and he makes a UHFHLSW of the sold product 4. The PDJD]LMQPHGHZHUNHU takes the UHFHLSW and gets the product 5. 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 Task Actor Description Document Æ Tasks Æ Task Tasks _ Æ Actor Description Document Actor Description Æ 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 Salesman Take receipt and get product 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 -> Start Element Element -> Action Name Element Choice Condition Element Element Element WaitSplit Element+ Element Wait Condition Element EndElement Name -> string Condition -> 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. reserving a room, entering it on the web site 2. having the exam checked by someone else 3. having the exam session (who are e.g. the actors here) 4. distributing the exam for marking, and collecting and computing final results 5. 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.