Design of a Domain Specific Language for a Dutch Student House

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• ˆ SJ”‰˜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>, </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:
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 </WFTD>
<WF name=”name” version=”version”/>
<ACTIVITY name=”name”> ACond Role TC </ACTIVITY> Activity
<A_COND> Pre Post </A_COND>
<PRE cond=”condition”/>
<POST cond=”condition”/>
<TC cond=”condition”/> TC
<WFRD name=”name” path=”path” /> WFRD
<ROLE name=”name” entity=”entitity”/> 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"/>
<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 (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 <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.
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