Agent Aided Workflow Modeling - CiteSeerX

39

Agent Aided Workflow Modeling* Jinlei Jiang and Meilin Shi Department of Computer Science and Technology, Tsinghua University, 100084 Beijing, P.R. China {jjlei,shi}@csnet4.cs.tsinghua.edu.cn Abstract. Nowadays, workflow processes are mostly built out of the designers' experience, which is usually full of skills and tactics and the correctness of the resulting processes is hard to guarantee, especially for complex ones. To address this issue, a tool called AAWM (Agent Aided Workflow Modeler) is proposed. This paper details the design and implementation issues related to AAWM such as system architecture, user interface and so on.

1 Introduction Workflow modeling plays an important role in building workflow systems because a workflow system runs a process under the direction of the model obtained during modeling phase. Though there are many literatures related to workflow modeling[2, 4, 6, 7, 9, 11], they mostly concentrate on how to describe a process by the supplied symbols/tools rather than to help people build workflow processes. At most time, workflow modeling is more like an art rather than a science[8]. Therefore, it is full of nondeterministic factors. On the other hand, tasks modeled in real world are so complex that persons can't carry it out without professional trainings. This, we think, cumbers the further application of workflow technology. To broaden the application of workflow technology, we believe a tool that assists people to identify the real world requirements and build the corresponding process with few errors introduced is significant. As an endeavor in this direction, a tool called AAWM (Agent Aided Workflow Modeler) is proposed in this paper. AAWM deploys agents to fully utilize the knowledge within an organization and to facilitate the communication between process designers. With the help of AAWM, even ordinary users can build a complex process quickly and accurately.

2 AAWM Overview This section will show the foundation of AAWM and point out the aspects that agent may help. 2.1 System Foundation The design of AAWM is based on the following observations related to workflow modeling. *

This work is co-supported by the National Natural Science Foundation of China under Grant No. 90412009, 60073011 and 985 Project of Tsinghua University.

C.-H. Chi and K.-Y. Lam (Eds.): AWCC 2004, LNCS 3309, pp. 39–45, 2004. © Springer-Verlag Berlin Heidelberg 2004

40

Jinlei Jiang and Meilin Shi

1. The business process/task to model is divisible[3]. It usually includes a series of jobs(sub-tasks) and different users participate different jobs. 2. Roles hold a key position in improving workflow flexibility. With roles and their relations (Ref. to [5] for some basic role relations) identified, designers can then reason at a high abstract level and re-use previous design decisions. 3. Workflow modeling is also a cooperative process itself[3]. 4. Modeling procedure can be divided into two phases[1], i.e., meeting phase and design phase. The main issues in meeting phase are defining objectives, decomposing the domain into smaller functions, defining boundaries and scope. In design phase, the users are asked to provide ever-increasing detail. 5. Object is exploited to guide an agent to achieve the goal specified. It plays a less important role in workflow modeling. 2.2 What Will Agent Help? In AAWM, agents function in the following aspects. • Goal decomposition. Here we emphasize that the decomposition is only done coarsely because workflow modeling is so complex a procedure that current technology can not fulfill all the work autonomously. Furthermore, even if it is possible, it is costly to develop such a system. Therefore, agent is only deployed as an aided approach in AAWM and designers are still needed to make final decisions based on the results got. In this way, the requirements on process designers and system development are both reduced. • Action coordination. It mainly utilizes the social ability and pro-activeness of agents. Once operations from designers are received, they are checked for consistency. If conflict is found, agents will do some actions to reconcile them. • Interaction with users. It mainly utilizes the reactivity of agents. In this scenario, agent will perceive users' operation and then collect and present related information to the users. Therefore, the requirements on process designers are reduced.

3 AAWM Details This section will explain issues related to AAWM design and implementation. 3.1 System Architecture The system architecture is illustrated in Fig. 1. According to the structure of the organization, the system is divided into many levels (only two levels are shown in Fig. 1). The whole system consists of multiple servers and clients. All servers have the same internal structure and can work independently. The only difference between enterprise-level server and department-level server is that tasks of the former are usually complex while those of the latter are relatively simpler. All servers should coordinate the behaviors of its clients. In addition, the top-level server should also coordinate the behaviors of the low-level servers. The adoption of such architecture arises out of two reasons: 1) departments of an organization are usually formed according to their functionalities. Each department has its own familiar business. To allocate proper tasks to them will make the work

Agent Aided Workflow Modeling

41

Server

Client

Client

Enterprise Level Department Level

…… Server

Server

……

……

Client

Client

Client

Client

Fig. 1. AAWM Architecture

more efficient and effective, and 2) departments are autonomous. Besides taking part in the enterprise-wide tasks, they also have their own internal business processes. This architecture gives them the most freedom. 3.2 Server Structure The main components of AAWM server are shown in Fig. 2. It consists of an agent and a set of databases. agent Server

Communication Module

Task Resolver

Goal Manager

Client

Action Manager

Database Access Interface

Role

Process

Rules

Other

Fig. 2. Main Components of AAWM Server

Modules within agent are explained as follows. • Communication Module is responsible for the interactions between servers and clients. In more details, it interacts with clients taking part in task decomposition during meeting phase while in design phase, it communicates with clients connected with it as well as the upper or lower servers. • Task Resolver receives original task goal (from task decomposition tool) and decomposes it into sub-goals (Ref. to [10] for the methods), which are then handed to Goal Manager and sent back to clients involved. • Goal Manager maintains both the original goals and the decomposed results. Besides, it records the status of each client or server involved in the process design.

42


• Action Manager is deployed to coordinate various operations related to task decomposition and process design. It is up to it to resolve the conflict occurring. • Database Access Interface fulfills access to the underlying databases. Databases in Fig. 2 function as follows. • Role base contains all the roles identified during process design. They can be used as reference information for subsequent process design. • Process base contains various standard or user-defined workflow processes. • Rules base contains various rules conducting business and knowledge needed for reasoning. They constitute the basis of task decomposition. • Other base contains other information related to the system such as departments and users. 3.3 Client Tools Corresponding to the two phases of workflow modeling, two client tools are provided and they are task decomposition tool and process design tool. 3.3.1 Task Decomposition Tool Task decomposition tool is used to divide a complex task into a set of simpler ones. Its interface is shown in Fig. 3. From the figure, we can see that the whole interface is divided into three areas, i.e., decomposition result window, property window and chatting area. Decomposition result window displays decomposition result in tree view and chatting area provides a way for designers to communicate their ideas. This is one outstanding feature of task decomposition tool. The introduction of chatting makes the communication between designers more fluent and thus forms a well foundation for correct and reasonable decomposition. For example, with this tool two or more designers can easily determine whether a task should be divided into two ones through real-time discussion. In addition, end users can also take part in this procedure and raise their requirements for designers’ information. Therefore, the structure of a process can be quickly determined. Property window shows the properties of the task specified. The important properties of task are as follows. • Name is the unique identifier of a task. • Description describes the goal of the task, which is the foundation of further decomposition or process design. • Designer specifies who can handle the task. The interaction between task decomposition tool and the AAWM server is as follows: 1) One initial designer inputs the original task goal which is then sent to AAWM server; 2) Server agent decomposes the given goal according to the rules specified and sends the results back; 3) Based on the results presented, designers can do further modification and then submit the results to server. 3.3.2 Process Design Tool After a complex task is decomposed, different users can then provide the details of sub-tasks got via process design tool. The internal structure of process design tool is illustrated in Fig. 4. It consists of an agent, an input interface and an output interface, where input interface accepts inputs from designers while output interface presents the related information to designers. Modules within agent are explained as follows.


43

Property Window

Decomposition Result

Chatting Area

SAM: ADrawnPoint is simple enough John: Yes, I agree with you! John: AReview1 should be assigned to Product department SAM: Yes, Mary is an expert there! User Input Area

Sub-Task Areview is too complex and should be divided further

Fig. 3. Task Decomposition Tool

• Communication Module is responsible for information exchange with servers or peer clients. Communication between peer clients is mainly to negotiate activity interface or handle conflicts. • Sensor is the driver of Info Handler. It is up to it to perceive actions of designer and to monitor notifications from server or peer clients. • Task Goal contains the concrete task requirements and a set of constraints. • Current Status records the specified properties of task till now. • Info Handler is the core of design tool. It mainly does two things. That is, 1) handle the notification received, and 2) collect goal-related information according to designer’s behavior and current status. In both cases, the result is presented to designer for their information. agent server peer

Comm. Module Task Goal

Input Interface

Info Handler

Sensor

Output Interface

Current Status

Fig. 4. Internal Structure of Process Design Tool

44


The interface, which is the only model-specific part of AAWM because each workflow system adopts only one workflow model, of process design tool is shown in Fig. 5. Here the model supported is Cova cooperation model[12]. To help designers build a process, the following steps are taken. • Not only the task manipulated directly, but also the ones related to it are displayed in the working area. In other words, work context is supplied. With it, designers are apt to provide more precise details of tasks under modeling. • Task related information is gathered and presented in the form of hint information to the designers in real time. For example, Fig. 5 illustrates the information shown when the mouse moves to role property. It lists the roles available as well as their relations. With the information supplied, designers can gain deep comprehension of the task and thus, it becomes easier to make a correct decision. This is possible due to the Sensor and Info Handler in Fig. 4. In more detail, once an action from designers is perceived by Sensor, Info Handler begins to collect related information according to the task goal and current status and presents the results to designers.

Fig. 5. Interface of Process Design Tool

4 Conclusions Building workflow processes out of the designers’ experience results in two problems: 1) it raises high requirements on process designers, and 2) it is hard to guarantee process correctness for this procedure is full of uncertainties. To address these issues, AAWM is developed bearing such experience in mind that one main reason for people to make wrong decisions is that they don’t learn enough on the related information. The main contributions of AAWM to workflow modeling are 1) it firstly (to our best knowledge) introduces agent to help designers make correct decisions by gathering related information for them, and 2) it allows designers to define a workflow process collaboratively by exchanging their ideas synchronously. In this way, both the requirements on process designers and the uncertainties are reduced. In the end we should point out that AAWM is not limited to specific process model except


45

the process design tool because only one model is adopted in each workflow system. In addition, AAWM can also be used to solve other problems, e.g., co-authoring a document and making a decision.

References 1. Carmel E., Whitaker R. D. and George J. F. PD and Joint Application Design: A Transatlantic comparison. Communications of the ACM, 1993, 36(4): 40-48 2. Davulcu H., Kifer M., Ramakrishnan C. R. and Ramakrishnan I. V. Logic Based Modeling and Analysis of Workflows. In: Proc of ACM PODS'98 (1998) 25~33 3. Hsieh Y. F., Yang G. X. and Shi M. L. CovaModeler: A Multi-user Tool for Modeling Cooperative Processes. International Journal of Computer Applications in Technology, 2003, 16(2/3): 67-72 4. Inamoto A. Agent oriented system approach for workflow automation. International Journal of Production Economics, 1999, 60-61(1-4): 327~335 5. Karageorgos A., Thompson M. and Mehandjiev N. Semi-Automatic Design of Agent Organisations. In: Proc of ACM SAC'02 (2002) 306-313 6. Knolmayer G., Endl R. and Pfahrer M. Modeling Processes and Workflows by Business Rules. In: Lecture Notes in Computer Science 1806, Springer-Verlag (2000) 16~29 7. Sadiq W. and Orlowska M. E. Analyzing Process Models Using Graph Reduction Techniques. Information Systems, 2000, 25(2): 117~134 8. Stohr E. A. and Zhao J. L. Workflow Automation: Overview and Research Issues. Information Systems Frontiers, 2001, 3(3): 281~296 9. van der Aalst W. The application of Petri Nets to workflow management. Journal of Circuits, Systems and Computers, 1998, 8(1):21~66 10. Weld D. S. Recent advances in AI planning. AI Magazine, 1999, 20(2): 55-68 11. Wirtz G., Weske M. and Giese H. The OCoN Approach to Workflow Modeling in ObjectOriented Systems. Information Systems Frontiers, 2001, 3(3): 357~376 12. Yang G. X. and Shi M. L. Cova: a Programming Language for Cooperative Applications. Science in China Series F, 2001, 44(1): 73-80