www.archive-org-2013.com » ORG » Y » YAWLFOUNDATION

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

    Archived pages: 971 . Archive date: 2013-04.

  • Title: YAWL
    Descriptive info: .. YAWL:.. Yet Another Workflow Language.. YAWL is a BPM/Workflow system, based on a concise and powerful modelling language, that handles complex data transformations, and full integration with organizational resources and external Web Services.. YAWL offers:.. the most powerful process specification language for capturing control-flow dependencies and resourcing requirements.. native data handling using XML Schema, XPath and XQuery.. a formal foundation that makes its specifications unambiguous and allows automated verification.. a service-oriented architecture that provides an environment that can easily be tuned to specific needs.. more.. or browse all downloads.. YAWL Symposium 2013, Bonn, Germany:.. Call for papers.. Home.. Documentation.. Manuals..  ...   Commercial Uptake.. Teaching.. Citations.. In the News.. Resources.. Forum.. YAWL User Group.. Downloads.. Latest Builds.. Case Studies.. Contributions.. Examples.. Lexicon.. newYAWL.. Patterns.. Performance.. Publications.. Screen Shots.. Tutorials.. Videos.. Support.. FAQ.. Commercial Support.. Report a Problem.. Contribute.. Links.. Contacts.. YAWL Team.. Developed with.. Smart Java IDE with best XML support.. Create, validate and refactor XML code.. YourKit is kindly supporting the YAWL Foundation with its full-featured Java Profiler.. YourKit, LLC is creator of innovative and intelligent tools for profiling Java and.. NET applications.. Take a look at YourKit's leading software products:.. YourKit Java Profiler.. and.. YourKit.. NET Profiler.. Copyright 2004-2013 The YAWL Foundation..

    Original link path: /
    Open archive

  • Title: Features of YAWL
    Descriptive info: Features of YAWL.. YAWL offers the following distinctive features:.. YAWL offers comprehensive support for the control-flow patterns.. It is the most powerful process specification language for capturing control-flow dependencies.. The data perspective in YAWL is captured through the use of XML Schema, XPath and XQuery.. YAWL offers comprehensive support for the resource patterns.. It is the most powerful process specification language for capturing resourcing requirements.. YAWL has a proper formal foundation.. This makes its specifications unambiguous and automated verification becomes possible (YAWL offers two distinct approaches to verification, one based on Reset nets, the other based on transition invariants through the WofYAWL editor plug-in).. YAWL has been developed independent from any commercial interests.. It simply aims to be the most powerful language for process specification.. For its expressiveness, YAWL offers relatively few constructs (compare this e.. g.. to BPMN!).. YAWL offers unique support for exception handling, both those that were and those that were not anticipated  ...   mapped to the YAWL environment for execution.. The Declare component (released through declare.. sf.. net) provides unique support for specifying workflows in terms of constraints.. This approach can be combined with the Worklet approach thus providing very powerful flexibility support.. YAWL's architecture is Service-oriented and hence one can replace existing components with one's own or extend the environment with newly developed components.. The YAWL environments supports the automated generation of forms.. This is particularly useful for rapid prototyping purposes.. Tasks in YAWL can be mapped to human participants, Web Services, external applications or to Java classes.. Through the C-YAWL approach a theory has been developed for the configuration of YAWL models.. For more information on process configuration visit.. www.. processconfiguration.. com.. Simulation support is offered through a link with the ProM (.. processmining.. org.. ) environment.. Through this environment it is also possible to conduct post-execution analysis of YAWL processes (e.. in order to identify bottlenecks)..

    Original link path: /pages/support/more.html
    Open archive

  • Title: YAWL Manuals
    Descriptive info: YAWL Manuals.. User Manual.. The YAWL User Manual contains detailed descriptions on how to use the YAWL system, including the process editor, default work lists and administration pages.. LATEST:.. YAWL User Manual 2.. 3 version.. PREVIOUS:.. 2 version.. OLDER:.. 1 version.. Technical Manual.. The YAWL Technical Manual contains detailed technical descriptions on the inner workings of the YAWL system and explanations on how developers can extend the system in numerous ways, including developing custom services and gateways, developing codelets, extending the resourcing service, creating custom forms and external data sources, and so on.. YAWL Technical Manual 2..

    Original link path: /pages/support/manuals.html
    Open archive
  •  

  • Title: Modern Business Process Automation: YAWL and its Support Environment
    Descriptive info: Modern Business Process Management.. YAWL and its Support Environment.. Table of Contents.. Errata.. Where to Buy.. List of Contributors.. Modern Business Process Automation: YAWL and its Support Environment.. This book provides a comprehensive treatment of the field of Business Process Management (BPM) with a focus on Business Process Automation.. It achieves this by covering a wide range of topics, both introductory and advanced, illustrated through and grounded in the YAWL (Yet Another Workflow Language) language and corresponding open-source support environment.. In doing so it provides the reader with a deep, timeless, and vendor-independent understanding of the essential ingredients of business process automation.. The BPM field is in a continual state of flux and is subject to both the ongoing proposal of new standards and the introduction of new tools and technology.. Its fundamentals however are relatively stable and this book aims to equip the reader with both a thorough understanding of them and the ability to apply them to better understand, assess and utilize new developments in the BPM field.. As a consequence of its topic-based format and the inclusion of a broad range of exercises, the book is eminently suitable for use in tertiary education, both at the undergraduate and the postgraduate level, for students of computer science and information systems.. BPM researchers and practitioners will also find it a valuable resource.. The  ...   Arthur H.. M.. ter Hofstede, PhD.. , is a Professor at Queensland University of Technology.. He is an original contributor to the well-known workflow patterns as well as a codesigner of the YAWL language and manager of the development of its open-source support environment.. Wil M.. P.. van der Aalst, PhD.. , is a Professor at Eindhoven University of Technology and an Adjunct Professor at Queensland University of Technology.. He is coauthor of the textbook.. Workflow Management: Models, Methods, and Systems.. and editor of several other books in the areas of Business Process Management and Petri nets.. Together with ter Hofstede he initiated the workflow patterns initiative and the development of YAWL.. Michael Adams, PhD.. , is a Senior Lecturer at Queensland University of Technology.. He has developed the concepts of Worklets and Exlets to deal with workflow evolution and unexpected exceptions in YAWL.. In addition, he is currently the technical lead of the YAWL support environment.. Nick Russell, PhD.. , is a Postdoctoral Researcher at Eindhoven University of Technology.. He has conducted extensive research in the area of workflow patterns leading to collections of control-flow, data, resource and exception handling patterns.. This work formed the basis for.. and the solutions to resource and exception handling in YAWL 2.. 0.. Copyright © 2009-2012 YAWLBook.. All Rights Reserved.. YAWL is a trademark of.. YAWL Foundation..

    Original link path: /yawlbook/
    Open archive

  • Title: Object versioning compliance checking
    Descriptive info: Object versioning compliance checking.. Product Lifecycle Management (PLM) systems are widely used in the manufacturing industry.. A core feature of such systems is providing support for versioning of product data.. As workflow functionality is increasingly used in PLM systems the possibility emerges that versioning policies as encapsulated in process models are inconsistent with respect to their actual lifecycles.. We define compliance of object versioning lifecycles with respect to process models and provide a solution to automatically checking whether compliance holds.. We developed a tool to enable version compliance checking of process models.. Our main objective was to provide a versioning-annotated  ...   an analysis plug-in.. VWF-net analysis.. There are five components to this tool namely, a versioning-annotated WF-net viewer, a syntactical compatibility checker, a WF-net transformer, a soundness checker and a behavioural compliance interpreter.. Among these components, the WF-net transformer, the soundness checker and the behavioural compliance interpreter together constitute the behavioural compliance checker.. The soundness checker is an existing ProM plug-in called Woflan that can be used to verify the soundness property of a WF-net.. VWF-net analysis plug-in.. ProM downloads.. VWF-net analysis manual.. Download PDF (616 Kb).. Data used in Experiments.. Download data used in experiments (426.. 37 Kb).. Technical report..

    Original link path: /pages/research/compliance.html
    Open archive

  • Title: Dynamic Flexibility and Exception Handling
    Descriptive info: Dynamic Flexibility and Exception Handling.. The YAWL system provides support for flexibility and dynamic exception handling through the concept of.. worklets.. , an extensible repertoire of self-contained sub-processes and associated selection rules, grounded in a formal set of work practice principles derived from Activity Theory.. This approach directly provides for dynamic change and process evolution without having to resort to off-system intervention and/or system downtime.. Flexibility is supported by allowing a process designer to designate certain tasks to each be substituted at runtime with a dynamically selected worklet, which contextually handles one specific task in a larger, composite process activity.. An extensible repertoire of worklets is maintained for each task in a specification.. When a task is enabled, a choice may be made from the repertoire based on the contextual data values within the task, using an set of ripple-down rules to determine the most appropriate substitution.. The task is checked out of the YAWL engine, the corresponding data inputs of the original task are mapped to the inputs of the worklet, and the selected worklet is launched as a separate case.. When the worklet has completed, its output data is mapped back to the original task, which is then checked back into the engine, allowing the original process to continue.. The worklet executed for a task is run as a separate case in the engine, so that, from an engine perspective, the worklet and its parent are two distinct, unrelated cases.. The worklet service tracks the relationships, data mappings and synchronisations between cases.. Any number of worklets can form the repertoire of an individual task, and any number of tasks in a particular specification can be associated with a  ...   continuous evolution of the process while avoiding any need to modify the original process definition.. Example of a process-exlet-worklet hierarchy.. Exception handling, when enabled, will detect and handle up to ten different kinds of process exceptions.. As part of the exlet, a process designer may choose from various actions (such as cancelling, suspending, completing, failing and restarting) and apply them at a task, case and/or specification level.. And, since exlets can include compensatory worklets, the original parent process model only needs to reveal the actual business logic for the process, while the repertoire of exlets grows as new exceptions arise or different ways of handling exceptions are formulated.. An extensible repertoire of exlets is maintained for each type of potential exception within each workflow specification.. If an exlet is executed that contains a compensation action (i.. e.. a worklet to be executed as a compensatory process) it is run as a separate case in the enactment engine, so that from an engine perspective, the worklet and its `parent' (i.. the process that invoked the exception) are two distinct, unrelated cases.. Since a worklet is launched as a separate case, it may have its own worklet/exlet repertoire.. Any number of exlets can form the repertoire of an individual task or case.. An exlet may be a member of one or more repertoires.. The exception handling repertoire for a task or case can be added to at any time, as can the rules base used, including while the parent process is executing.. Worklets and exlets can be used in combination within particular case instances to achieve dynamic flexibility.. and.. exception handling simultaneously.. More detailed information about worklets and exlets can be found.. here..

    Original link path: /pages/research/exceptionhandling.html
    Open archive

  • Title: OR-join Semantics in YAWL
    Descriptive info: OR-join Semantics in YAWL.. Workflow languages offer constructs for coordinating tasks.. Among these constructs are various types of splits and joins.. One type of join, which shows up in various incarnations, is the OR-join.. Different approaches assign a different (often only intuitive) semantics to this type of join, though they do share the common theme that synchronisation is only to be performed for active threads.. Depending on context assumptions this behaviour may be relatively easy to deal with, though in general its semantics is complicated, both from a definition point of view (in terms of formally capturing a desired intuitive semantics) and from a computational point of view (how does one determine whether an OR-join is enabled?).. Semantics - When is an OR-join task enabled?.. An OR-join is used in situations when we need to model "wait and see" behaviour for synchronisation.. Consider a scenario where a telecommunication company provides home phone, internet and mobile services.. A customer can select one, all three or any combination of two of these services.. Depending on the service bundle selected, a discounted monthly price is calculated.. Figure 1: A YAWL net with an OR-split and an OR-join.. In a process model, this can be represented by a customer registration task, followed by three individual tasks to sign up for different services (which can be done in any order), and finally price calculation task (see Figure 1).. As it is possible for multiple services to be selected, we need a synchronising point before price calculation task.. If that synchronising point is modelled as an AND-join, it is clear that the process cannot continue (i.. , deadlock) for a customer who decides not to subscribe to all three services.. If it is modelled as an XOR-join (no synchronisation), the price calculation task would be performed multiple times, if a customer selects more than one service.. Therefore, there is a need for a more sophisticated synchronisation construct that is "intelligent" enough to determine when certain activities should be synchronised and when the subsequent activity should go ahead.. In this example, an OR-join waits for synchronisation if the customer has selected more than one service and carries out price calculation without delay if the customer has selected only one service.. Informal semantics.. In general, an OR-join task is.. enabled.. in the following circumstances:.. Full synchronisation: There is at least a token each in all of the input conditions of an OR-join task.. In Figure 1, there is at least one token each in conditions c4, c5 and c6.. Partial synchronisation: If there is at least one token in one of its input conditions and it is not possible for more tokens to arrive in other (currently empty) input conditions in the future states (i.. e, there is no need to wait/synchronise).. In Figure 1, if a customer only selects home phone service (c4), then there is no need to synchronise.. On the other hand, consider a scenario where a customer decides on taking  ...   all tokens from a place when its transition fires.. Through the behaviour of reset arcs, the behaviour of cancellation regions can be captured in a natural manner.. Characteristics of the OR-join semantics.. General: no syntactical restriction and closely matches the intuitive semantics.. Formal: the semantics is defined using reset nets formalism and decided using backwards coverability algorithm.. Decidable: the algorithm is applicable for workflows with cancellation, multiple OR-joins and loops.. Multiple OR-joins.. The informal semantics of an OR-join can be supported quite well when there is only one OR-join in a given net.. However, when dealing with multiple OR-joins where one precedes the other, the semantics is not well-defined.. The question arises as to ``how to treat other OR-joins in the workflow while we try to decide whether one OR-join should be enabled?".. Instead of ignoring other OR-join tasks during the analysis, two alternative treatments have been proposed for those OR-joins:.. XOR-joins (optimistic):.. It is considered optimistic as the analysis waits for synchronisation if the resulting XOR-join can be enabled.. AND-joins (pessimistic):.. The treatment of an OR-join on the path to another OR-join as an AND-join is a pessimistic approach, as this approach now requires tokens in all input conditions of the AND-join and if it is not possible, the OR-join will be enabled.. In the YAWL implementation, the optimistic approach has been used as the treatment of other OR-joins as XOR-joins allows the most delay for possible synchronisation.. The resulting OR-join semantics is well-defined in every circumstance.. However, the interpretation of this semantics can sometime lead to a deadlock in the presence of vicious circles (see below) as both OR-joins will wait for each other to fire first.. A note on vicious circles.. When OR-joins are.. in conflict.. , where both OR-joins are only waiting for each other to fire first so that they can become enabled, there is no satisfactory treatment for multiple OR-joins.. As mentioned before, the XOR-join treatment during the analysis will result in deadlock.. Implementation.. The proposed semantics has been implemented as part of a workflow environment together with two restriction techniques to improve the performance of the algorithm.. As a YAWL net with OR-join tasks is translated into a reset net for OR-join analysis, the optimisation operations are also performed on the reset net.. Optimisation techniques.. For an OR-join analysis, it is possible to consider only a portion of the net that is relevant to the analysis and refrain from exploring those paths that do not affect the OR-join enabling behaviour.. To improve the performance of the OR-join evaluation algorithm, two forms of restriction are proposed:.. structural restriction.. active projection.. Structural restriction.. involves removing from a net tasks and conditions that are not on the path to the OR-join task under consideration.. Active projection.. involves removing tasks and associated conditions that could not be enabled from a given marking.. Active projection enables us to stop exploring those parts of the net that can never be reached from a given marking..

    Original link path: /pages/research/orjoin.html
    Open archive

  • Title: Simulation in YAWL
    Descriptive info: Simulation in YAWL.. Business process simulation is a powerful tool for process analysis improvement.. One of the main challenges is to create simulation models that accurately reflect the real-world process of interest.. Moreover, we do not want to use simulation just for answering strategic questions but also for tactical and even operational decision making.. To achieve this, different sources of simulation-relevant information need to be leveraged.. We present here a new way of creating a simulation model for a business process supported by a workflow management system, in which we integrate design, historic, and state information.. In order to link enactment and simulation we propose to use three types of information (Design information, Historic information, State information) readily available in workflow systems.. These are used to create and initialize the simulation model.. By merging the above information into a simulation model, it is possible to construct an accurate model based on observed behavior rather than a manually-constructed model which approximates the workflow's anticipated behavior.. Moreover, the current state information supports a `fast forward' capability, in which simulation can be used to explore different scenarios with respect to their effect in the near future.. In this way, simulation can be used for operational decision making.. To showcase how real-time data from the workflow system can be utilised in simulation experiments, we have developed software that makes a link between the.. YAWL.. workflow system and the Process Mining framework (.. ProM.. ).. The SimulationFilters can be downloaded as plug-ins from.. sourceforge.. A tutorial on how to use this feature can be found on.. the ProM wiki.. Extracting Simulation Relevant Information from YAWL.. The information contained in the workflow specification is supplemented with historical data obtained from the event logs and data from the organizational model database.. This was achieved by implementing two new functions in the workflow engine to export historical data from the logs for a particular specification and to export the organizational model (i.. , information about roles and resources).. In the YAWL workflow system, event logs are being created whenever an activity is enabled, started, completed or cancelled together with the time when it is enacted and who has enacted this event.. The logs are also kept for the data values that have been entered and used throughout the system.. Therefore, it is possible to easily retrieve  ...   data.. Creating a Simulation Model in ProM.. To generate the simulation model, four basic steps need to be performed within ProM.. The workflow, the organizational model and the event log are imported from the YAWL workflow system and analysed.. Simulation-relevant information from the organizational model and log analysis are integrated into the YAWL model.. The YAWL model is converted into a Petri net model (because our simulation tool is based on Coloured Petri Nets).. Finally, the integrated and converted model is exported as a CPN model.. We can then use the CPN Tools system to simulate the generated model.. However, to produce useful results we do not want to start from an empty initial state.. Instead we load the current state of the actual YAWL system into the CPN Tools for simulation (See Figure 3).. Figure 3: Sample current state data for CPN Tools.. Figure 4: Configurations for CPN model export.. While CPN Tools already provides powerful logging facilities and even generates gnuplot scripts that can be used to plot certain properties of the simulated process, we also generate MXML event log fragments per case during simulation, similar to the one shown in Figure 2a for the workflow log.. These fragments can then be combined using the CPN Tools filter of the ProMImport framework, which facilitates the conversion of event logs from various systems into the MXML format that is read by ProM.. The ability to use the same toolset for analyzing the simulation logs and analyzing the actual workflow logs constitutes a big advantage because the simulation analysis results can be more easily related to the initial properties of the process.. Figure 5: Simulation Log Analysis in ProM.. Related publications.. A.. Rozinat, M.. T.. Wynn, W.. van der Aalst, A.. H.. ter Hofstede, and C.. J.. Fidge.. Workflow Simulation for Operational Decision Support Using Design, Historic and State Information.. Proceedings of the 6th International Conference on Business Process Management (BPM 2008), 1-4 September 2008, Milan, Italy, LNCS 5240, pages.. 196 - 211, 2008, Springer-Verlag.. M.. Wynn, M.. Dumas, C.. Fidge, A.. ter Hofstede, and W.. van der Aalst,.. Business Process Simulation for Operational Decision Support.. , LNCS 4928, pp.. 66-77, Springer-Verlag 2008.. In proceedings of the Third International Workshop on Business Process Intelligence (BPI 2007), in conjunction with Business Process Management Conference, Brisbane, Australia, 24 September 2007..

    Original link path: /pages/research/simulation.html
    Open archive

  • Title: Verification in YAWL
    Descriptive info: Verification in YAWL.. Verification is concerned with determining,.. in advance.. , whether a process model exhibits certain desirable behaviours.. By performing this verification at design time, it is possible to identify potential problems, and if so, the model can be modified before it is used for execution.. Although one would expect verification functionality to be present in any business process modelling tool, workflow management system, or business process management suite, this is not the case.. At best these systems do some basic syntactical checks, but allow for the modelling of processes with deadlocks, livelocks, and other anomalies.. There are several academic process verification tools.. However, until recently, these tools could not verify realistic processes because they assume highly simplified models completely disconnected from real-life languages and systems.. Fortunately, a breakthrough has been realized that makes process verification feasible in a practical setting.. Sophisticated verification techniques for process models with cancellation and OR-joins have been developed in the context of the workflow language YAWL.. The YAWL editor supports two verification approaches:.. Verification using reset nets.. Verification using invariants.. Verification approach using reset nets.. There are established results related to the verification of workflows using Petri nets.. We explore how these results can be used for YAWL workflows with cancellation and OR-joins.. Reset nets form a natural foundation for workflow languages with explicit support for cancellation as the behaviour of reset arcs closely matches the behaviour of cancellation regions.. For verification purposes, the YAWL processes are divided into those with OR-joins and those without OR-joins.. This distinction is necessary as a different verification technique is needed in each case.. A process without OR-joins is mapped to a reset net and verification is performed on the resulting reset net.. However, due to the non-local semantics of OR-joins, it is not possible to map a YAWL workflow with OR-joins to a reset net (without some approximation) and it is not possible to detect the soundness property for a YAWL net with OR-joins using verification techniques available for reset nets.. Therefore, an alternative verification technique using the YAWL formal semantics is used.. These algorithmic approaches have been derived using the state space analysis and the notions of coverability and reachability.. Reduction rules have been used as a means of improving the efficiency of the algorithm.. Four desirable properties for processes with cancellation regions and OR-joins are proposed.. These are:.. Soundness.. Weak soundness.. Irreducible cancellation regions.. Immutable OR-joins.. While soundness and weak soundness properties concentrate on the correctness of the models, the other two properties, irreducible cancellation regions and immutable OR-joins, focus on detecting the existence of unnecessary cancellation regions and OR-joins in the process models.. Verification menu.. Verification functionality can be invoked from the "Analyse specification" menu item under the specification menu of the YAWL Editor.. Figure 1 shows the configuration menu for verification options.. Figure 1: Configuration menu in the YAWL Editor.. Soundness property.. There are certain desirable characteristics that every business process is expected to exhibit.. Firstly, it is important to know that a process,  ...   it will also be weak sound, but not vice versa.. A net satisfies the weak soundness property if and only if it has the weak option to complete, proper completion and no dead transitions.. The weak soundness property check is performed using reset net coverability analysis for nets with and without OR-joins.. For nets with OR-joins, only limited results are available.. Figure 3 shows a screenshot from the editor with the results of the weak soundness property check for all nets.. We can see that all nets satisfy the weak soundness property.. Figure 3: Weak soundness property check.. Irreducible cancellation regions property.. Reducible elements in a cancellation region represent elements that can never be cancelled while that task is being executed (e.. conditions may never contain tokens).. For example, if a model contains truly alternative branches and one path contains a task that covers some places and conditions from the other path within its cancellation region, then those places and transitions are superfluous as there will never be tokens to remove when the task is executing.. A process satisfies the.. irreducible cancellation regions.. property if there are no reducible elements in any of its cancellation regions.. An element within a cancellation region of a task is not necessary if that element can never be marked when the task is being executed.. Such elements are called reducible because they can be removed without changing the behaviour.. To decide the irreducible cancellation regions property of a net without OR-joins, analysis on the corresponding reset net is performed.. The cancellation region for the Stop checks task includes the Finalise basic requirements check task.. As Finalise basic requirements check is an AND-join task, it can never be executed while the Stop checks task is being executed.. Therefore, it should not be in the cancellation region of the Stop checks task.. This is reported by the YAWL editor as shown in Figure 4.. Figure 4: Irreducible cancellation regions property check.. Immutable or-join property.. As the runtime analysis of OR-join tasks is time-consuming and (computationally) expensive, it is desirable to determine at design time whether a more appropriate join structure could be found for a given model.. A convertible OR-join task is an OR-join task for which it is never possible to mark more than one input condition (the task acts as an XOR-join) or when all the input conditions are always marked (the task acts as an AND-join).. Such OR-joins should be replaced by XOR/AND-joins to better reflect their role in the process and to improve the execution speed.. immutable OR-joins.. property if there are no convertible OR-joins in the net.. An immutable OR-join is one that could not be replaced by either an XOR-join or an AND-join.. In Figure 5, the split behaviour of the task.. Decide applicable categories.. has been changed from OR-split to AND-split for testing purposes.. As the net now contains an AND-split followed by an OR-join, the OR-join should be more appropriately modelled as an AND-join.. Figure 5: Immutable OR-join property check..

    Original link path: /pages/research/verification.html
    Open archive

  • Title: Visual Support for Work-list Assignment
    Descriptive info: Visual Support for Work-list Assignment.. Download the YAWL Visualiser.. Typically, PAISs use a so-called.. pull mechanism.. : work is offered to all resources that qualify and the first resource to select the work item will be the only one executing it.. To allow users to pull the.. right work items in the right order.. , basic information is provided, e.. , task name, due date, etc.. However, given the fact that the work list is the main interface of the PAIS with its users it seems important to provide support that goes beyond a sorted list of items.. If work items are selected by less qualified users than necessary or if users select items in a non-optimal order, then the performance of the overall process is hampered.. Assume the situation where multiple resources have overlapping roles and authorisations and that there are times where work is piling up (i.. , any normal business).. In such a situation the questions listed below are relevant:.. "What is the most urgent work item I can perform?".. "What work item is, geographically speaking, closest to me?".. "Is there another resource that can perform this work item that is closer to it than me?".. "Is it critical that I handle this work item or are there others that can also do this?".. "How are the work items divided over the different departments?".. Generally, products sort the work items in a work list using a certain priority scheme specified at design time and not updated at run time.. To support the user in a better way and assist her in answering the above questions, we use maps.. A map can be a geographical map (e.. , the map of a university’s campus).. But other maps can be used, e.. , process schema’s, organisational diagrams, Gantt charts, etc.. Work items can be visualised by dots on the map.. By not fixing the type of map, but allowing this choice to be configurable, different types of relationships can be shown thus providing a deeper insight into the context of the work to be performed.. Work items are shown on maps.. Moreover, for some maps also resources can be shown, e.. , the geographical position of a user.. Besides the "map metaphor" we also use the "distance metaphor".. Seen from the viewpoint of the user, some work items are close while others are far away.. This distance may be geographic, e.. , a field service engineer may be far away from a malfunctioning printer at the other side of the campus.. However, many other distance metrics are possible.. For example, one can support metrics capturing familiarity with certain types of work, levels of urgency, and organisational distance.. The choice of metric is orthogonal to the choice of map thus providing a high degree of flexibility in context visualisation.. Resources could for example opt to see a geographical map where work items, whose position is calculated based on a function supplied at design time, display their level of urgency.. General Framework.. The proposed visualisation framework is based on a two-layer approach:.. Maps.. The visualisation of work items based on a distance notion.. A work item is represented as a dot positioned along certain coordinates on a background map.. A map is meant to capture a particular perspective of the context of the process.. Since a work item can be associated with several perspectives, it can be visualised in several maps at different positions.. Maps can be designed at design time as needed.. When the use of a certain map is envisaged, the relationship between work items and their position on the map should be specified through a function determined at design time.. Several active "views" can be supported whereby users can switch from one view to another.. Resources can (optionally) see their own position on the map and work items are coloured according to the value of the applicable distance metric.. Additionally, it may be helpful to show executing work items as well as the position of other resources.. Naturally, these visualisations are governed by the authorisations that are in place inside the YAWL system.. During run-time the YAWL engine keeps updated about the life cycle states  ...   first task.. Assess the affected area.. represents a quick on-the-spot inspection to determine damage to buildings, monuments and objects.. For each object identified as worthy of further examination an instance of the sub-process.. Assess every sensible object.. is started as part of which a questionnaire is filled in and photos are taken.. After these assessments have finished, the task.. Send data to the headquarters.. can start, which involves the collection of all questionnaires and photos and their subsequent dispatch to headquarters.. This information is used to determine whether these objects are in imminent danger of collapsing and if so, whether this can be prevented and how that can be achieved.. Depending on this outcome a decision is made to destroy the object or to try and restore it.. For the purposes of illustrating our framework we assume that an earthquake has occurred in the city of Brisbane.. The figures below show different maps where dots refer to work items or resources.. Dots for work items are coloured with respect to the distance metric which users are currently chosen.. Figure 1 shows the main process of the.. Disaster Management.. workflow, including eight work items.. Dots for work items which are instances of the tasks.. Send data to the headquarter.. are placed on top of these tasks in this figure.. Figure 1.. "Process schema" Map.. No resources are shown in these diagrams since positioning work items in a "Process" Map is believed not to make sense.. Note that on the left-hand side is shown a list of work items that have no position the map.. Specifically, they refer to work items whose corresponding tasks are not part of workflow.. Figure 1 uses the familiarity metric to highlight cases closer to the user in terms of earlier experiences.. As another illustration consider Figure 2 where work items are positioned according to their deadlines.. This can be an important view in the context of disaster management where saving minutes may save lives.. In the map shown, the x-axis represents the time remaining before a work item expires, while the y-axis represents the case number of the case the work item belongs to.. Here we have also clicked on a specific dot to obtain other information of the corresponding work item.. A dot that is selected as focus obtains a blue colour and further information about the corresponding work item is shown at the bottom of the screen.. Figure 2.. "Time line" map.. Figure 3 shows some screenshots of a geographical map of the city of Brisbane.. On these maps, work items are placed at the location where they should be executed.. If their locations are so close that their corresponding dots overlap, a larger dot (i.. , a joint-dot) is used to represent the work items involved and the number inside corresponds to the number of these items.. The green triangle is a representation of the resource whose work list is visualised here.. Work items for tasks Assess the affected area and Send data to the headquarters are not shown on the map as they can be performed anywhere.. In this example, dots are coloured according to the familiarity distance metric.. One can click on a dot and see the positions of other resources that have been offered the corresponding work item.. For example, by clicking on the dot representing the work item Take photo_4, other resources, represented by triangles, are shown (see Figure 3a).. As for work items, overlapping triangles representing resources are combined.. For examples, the larger triangle shown in Figure 3a represents two resources.. This component provides also a zooming feature in order to make split joint-dots.. Figure 3b shows the result of zooming in a bit further on the map of Figure 3a.. As can be seen, As can be seen, neither dots nor triangles are overlapping anymore.. Figure 3b shows also what happens after clicking on a triangle representing a resource (specifically resource.. leader.. Clicking on a triangle causes work items offered to be seen.. The colour of these work items is determined by their value for the chosen distance metric.. A zooming feature is also provided.. Figure 3.. Screen shots of a possible Geographic Map..

    Original link path: /pages/research/visualisation.html
    Open archive

  • Title: Industrial Uptake of YAWL
    Descriptive info: Industrial Uptake of YAWL.. Systems.. first:utility and.. first:telecom.. in the UK, both companies part of the Impello plc group of companies, providing energy and telecoms services respectively, collaborated with QUT for several years on the YAWL project.. These companies have built software around the YAWL system providing a novel approach to page navigation for web based systems together with the more traditional use of choreographing long-lived business processes.. GECKO.. , a Germany-based software development and IT services company, aims to make use of the new YAWL 2.. 0 release for supporting resource-centric workflows in the context of an R D project.. The project addresses the application domain of clinical surgical suites and aims to provide support for peri-operative clinical processes  ...   (EDA).. is using YAWL 2.. 1 for modelling and implementing personnel management processes.. EDA's domain experts get support from a small.. modelling team.. MMT Seguros.. , a car insurance company based in Spain, is using YAWL to implement claims management and internal quality assurance processes.. Tools.. FERP Worklow System.. uses YAWL as part of its software.. InsuraPro Workflow claims to use YAWL as its "mathematical footing".. As stated in.. this paper.. the workflow management module of.. Axxerion.. "includes concepts from YAWL".. SWS.. has based the long term development strategy for its.. FlowConnect.. platform on YAWL and the workflow patterns.. A Petri net design tool called.. Woped.. , developed at the Berufsakamedie Karlsruhe, Karlsruhe, Germany,.. claims to have an interface to YAWL..

    Original link path: /pages/impact/uptake.html
    Open archive



  •  


    Archived pages: 971