Kai Mertins
email: kai.mertins@ipk.fraunhofer.de

Frank-Walter Jaekel
email: frank-walter.jaekel@ipk.fraunhofer.de

Quan Deng
email: quan.deng@ipk.fraunhofer.de

Towards Information Customization and Interoperability in Food Chains

Keywords: food supply chain network, cloud enterprise, traceability, information product, semantic interoperability, ontology, mass customization, Constraint satisfaction, quality management

Food supply chain networks are characterized by clouds of various partners providing required products or services to meet customer demands. The coordination of the SMEs (small and medium-sized enterprise) is a major challenge that food chain networks are facing. Delivering the right information to partners and providing semantic interoperability play key roles in effective coordination. This paper proposes an efficient framework to help these SMEs to easily negotiate and shape the profiles of the traceability information products. It tries to involve various tools to model the contexts of SMEs, and then adopt the concepts of mass customization to suggest optimal profiles for the desired information. In supply chain level, agents and governance boarders are supposed to negotiate and determine the profiles of needed information products. The customized information profiles are then employed to map and integrate various information sources to produce the required information products.

Introduction

Food supply chain networks are characterized by clouds of various partners providing required products or services to meet customer demands. Most of the partners in food chain networks are SMEs [START_REF]Food industry, EU food market overview[END_REF]. With limited resources and knowledge, these SMEs usually have problems to adapt dynamic changes in environment. With the equipment of cloud computing, as shown in Fig. 1, SMEs have chances to collaborate with a large number of other partners and services. The various companies distributed among different countries could dynamically choose the partners or services to meet their particular demands. Meanwhile, they have to adapt themselves to meet their own specific contexts, objectives as well as the requirements from other partners. Considering traceability in food chain networks, many SMEs do not have precise knowledge on the required traceability information that best satisfy their own contexts.

For the cooperation with other partners in the cloud environment, it is difficult for them to negotiate and then determine the profiles of their desired/exchanged information products. The SMEs in the clouds of food chain networks are supposed to work collaboratively to provide high-quality food to customers. However, in the last few years, food-safety issues were frequently discussed, such as avian flu, EHEC foodsafety crisis. Meanwhile, the clear awareness of sustainability and healthy regarding food products is increasing importance. Traceability which is usually referred as following the movement of entities throughout a whole supply chain is often taken as an essential tool to increase food quality [START_REF]Traceability in the feed and food chain -General principles and basic requirements for system design and implementation[END_REF]. Not only movement information, but also much other information related to food products, such as animal warfare, GMO (genetically modified organisms), impact of ingredients to customer's health (e.g. too much sugar in food is not healthy for a patient with diabetes), could be kept as traceability information. The collected traceability information is possible to be used for addressing un-safe food products in case of incidents as well as verification of food quality with respect to safety, healthy and sustainability [START_REF] Hobbs | Information asymmetry and the role of traceability systems[END_REF]. There are many other benefits related to traceability information, for instance, increasing transparency, increasing customers' satisfactions, verification of regulation compliance, etc. But setting up associated systems as well as gathering, processing, storing and sharing of the information is costly. For efficient coordination of the SMEs with respect to traceability, delivering the right information to partners and providing semantic interoperability play key roles. For instance, suppose information regarding GMO is critical important for a specific customer group, then all partners in the supply chain would be required to provide and exchange GMO-related information. However, for other customers, GMO information could be ignored to save cost. Customization of the information profiles which are expressed in ontologies would help SMEs to specify what information should be gathered /delivered with respect to their own contexts, objectives and constraints. And the customized information profiles then provide guidelines for information collection. However, to the best knowledge of the authors, currently there is no suitable framework available to help the users in SMEs to easily negotiate and get the food traceability information related ontologies that could best satisfy their particular business strategies, contexts, objectives and constraints.

With respect to delivering the right information to partners and providing semantic interoperability in food chain networks, some requisites should be satisfied by a proposed framework:

• Framework should provide tools and methodologies to help SMEs specify their own contexts, objectives and constraints with respect to traceability.

• Based on the provided information from SMEs, the framework should be able to propose optimal information profiles (expressed in ontologies) which could best satisfy SMEs' contexts, objectives and constraints.

• Distinctive information profiles should be provided for diversity products under different environments (e.g. different customer demands).

• In case of dynamic changes in business environment, SMEs should be able to easily get their own suitable information profiles.

• Semantic interoperability between information products should be guaranteed, so that SMEs could freely exchange information with other potential partners.

• Partners in the same supply chain should be coordinated to comply with a common information profiles to support all necessary traceability scenarios. For instance, if GMO information at broiler rearing stage is required in a supply chain, then all broiler farms in the supply chain are expected to provide GMO information.

Fig. 1. Sample Cloud Environment for Broiler Supply Chains

The following section provides a review on related areas. And then, section 3 briefly described the proposed approaches. Finally, conclusion and future work to be done are presented.

Related Works

Traceability was first clearly described by Kim in the context of the TOVE (Toronto Virtual Enterprise) project [START_REF] Kim | An ontology of quality for enterprise modeling[END_REF]. Since then, numerous researches were conducted in this area. Traceability systems evolving from centralized to distributed "one step up, one step down", are becoming more distributed, interoperable and intelligent. More and more technologies, e.g. RFID (Radio), Frequency Identification), SOA (Service Oriented Architecture), web service, TraceCoreXML, ebXML (Electronic Business using extensible Markup Language), EDI (Electronic Data Interchange) etc. are used to facilitate integration and interoperability in food traceability. In the process of setting up an effective traceability system, one of the most important things is to determine the information to be recorded [START_REF] Regattieri | Traceability of food products: general framework and experimental evidence[END_REF]. However, Partners are usually not sure, what the optimal traceability level is and what the exactly data that should be gathered is. Depends on traceability objectives, product characteristics, production processes, consumers' expectations and regulations, etc., the needed traceability data elements are different from one to another. There is no common accepted standard regarding the needed traceability data elements, and there is no single best way to introduce traceability because of the differences in product attributes and motivation of traceability etc. [START_REF] Golan | Traceability in the U. S. Food Supply : Economic Theory and Industry Studies Library Cataloging Record[END_REF]. Partners usually collect only limited traceability information for regulation compliance. But for many other purposes, e.g. sustainability verification, the information is usually not sufficient enough to bring maximum benefit. The SMEs are difficult to be coordinated to provide all necessary information for various traceability scenarios.

To standardize the traceability data elements, some reference data models on traceability, such as the model from von Drop [START_REF] Van Dorp | Reference-data modelling for tracking and tracing[END_REF], and Bechini et al [START_REF] Bechini | A General Framework for Food Traceability[END_REF], were proposed. But they seem to be in a high general level, which cannot easily be customized or configured for partners in a food chain network under a specific environment. The detailed needed data elements cannot be easily derived from the models. Many constraints such as customers' expectations on traceability, regulations are not considered. Partners worldwide with varying regulations and business restrictions, have different markets and traceability expectations from consumers. Some consumers with some diseases, like diabetes or obesity, would have more interest in the traceability information related to nutrition and healthy. Others who concern more on the sustainability aspects (e.g. carbon emission) would be more interested in traceability information regarding sustainability. Besides, foods supply chain networks are becoming more demand driven and dynamical [START_REF] Verdouw | Business process modelling in demand-driven agri-food supply chains : a reference framework[END_REF]. These dynamics in networks imply corresponding changes in the traceability needs, as well as the desired traceability data elements.

Information customization is to tailor information to meet special customer demands [START_REF] Berleant | Customizing Information: Part I[END_REF]. It is usually helpful to personalize information and avoid information overload. Abidi and Han presented an information customization framework which applied constraint satisfaction methods to select the hypermedia documents that conform to the user model [START_REF] Abidi | An adaptive hypermedia system for information customization via content adaptation[END_REF]. Related to identifying the to be recorded traceability information, Diogo M. Souza-Monteiro et al. propose a framework based on vertical control and agency theory to model three dimensions of traceability systems: depth, breadth, and precision [START_REF] Souza-Monteiro | The Economics of Voluntary Traceability in Multi-Ingredient Food Chains[END_REF]. They model and analysis voluntary traceability system in a supply chain producing multi-ingredient foods from the point view of economic implications. However, their assumptions simplified the real supply chain networks, and many other factors besides economic implications such as production process, traceability motivations, products' characteristics, and regulations etc., which influence the determination of the information profiles, are not considered. For the products/ingredients that result more risk than others, more detailed information should be recorded. Thakur et al. present a soybean value chain and model the information that should be captured by three links in the chain [START_REF] Thakur | Modeling traceability information in soybean value chains[END_REF]. On the basis of process models, they specify the data elements that should be included in the traceability information. Based on the information profiles, related information is then gathered, integrated to produce needed traceability information products. For information integration and semantic interoperability, the information profiles of SMEs are expressed as local ontologies that represent SMEs' own perspectives on traceability. Then the problem could be transformed into customization of optimal local ontologies that satisfy various constraints and objectives.

Ontology construction is one of the central research issues in the ontology area. There are lots of tools available for ontologies development, such as Proté gé [START_REF]The Proté gé Ontology Editor and Knowledge Acquisition System[END_REF]. Regarding methodologies for ontology construction, it could trace back to the Cyc Project, in which the experience in the Cyc ontology development process is recorded [START_REF] Elkan | Building Large Knowledge-Based Systems:Representation and Inference in the Cyc Project book review 1 Comments on the Cyc project[END_REF]. Some years later, in the enterprise modelling domain, the experience in development TOVE ontology [START_REF] Kim | An ontology of quality for enterprise modeling[END_REF] is gathered. And then many other methodologies such as METHONTOLOGY [START_REF] Ferndndez | METHONTOLOGY : From Ontological Art Towards Ontological Engineering[END_REF], On-To-Knowledge [START_REF] Staab | Knowledge Processes and Ontologies. Knowledge Creation Diffusion Utilization[END_REF] are presented. To support collaborative and distributed ontology construction, some methodologies like DOGMA [START_REF] Jarrar | Formal Ontology Engineering in the DOGMA Approach[END_REF], DILIGENT [START_REF] Pinto | DILIGENT: Towards a fine-grained methodology for Distributed, Loosely-controlled and evolvInG Engineering of oNTologies[END_REF], Onto-Agent [START_REF] Hadzic | Onto-agent methodology for design of ontology-based multi-agent systems[END_REF] were presented. In DOGMA and Onto-Agent methodologies, ontology resources are explicitly decomposed into ontology bases and ontological commitment. In ontology base, intuitive concepts and relationships between concepts within a domain are kept. In the ontology commitment layer, a set of constraints and rules are contained to allow agents to specify commitment ontology from their own point of view. In DILIGENT methodology, an initial shared ontology is first constructed, and then users could locally adapt the shared ontology for their own purposes. However, in the DOGMA, DILIGENT and Onto-Agent methodologies, users should have enough knowledge on ontology and know clearly about their desired ontology in order to reuse and construct their own ontologies. Farqahar et al. introduced Ontolingua Server for Collaborative Ontology Construction [START_REF] Farquhar | The ontolingua server: A tool for collaborative ontology construction[END_REF]. It supports ontologies reuse through an ontologies library, although the supports for ontology development in a distributed and collaborative environment are still limited [START_REF] Del | NeOn Methodology for Building Ontology Networks: Specification, Scheduling and Reuse[END_REF]. To provide better supports for collaborative and argumentative ontology development as well as on the building of ontology networks, NeOn Methodology was then proposed [START_REF] Del | NeOn Methodology for Building Ontology Networks: Specification, Scheduling and Reuse[END_REF] [START_REF]NeOn Project[END_REF]. It considers the reuse and possible subsequent reengineering of knowledge resources as one of the key aspects.

Ontology selection is the process to identify one or more ontologies or ontology modules that satisfy certain criteria [START_REF] Sabou | Ontology Selection : Ontology Evaluation on the Real Semantic Web[END_REF]. In the process, Ontologies could be searched based on specific keywords, logic query, ontology or some more complex query mechanism [START_REF] Sabou | Ontology Selection : Ontology Evaluation on the Real Semantic Web[END_REF]. Some ontology search engines were presented in last few years, such as Swoogle [START_REF] Ding | Swoogle: a search and metadata engine for the semantic web[END_REF] and OntoSelect [START_REF] Buitelaar | OntoSelect : A Dynamic Ontology Library with Support for Ontology Selection The OntoSelect Ontology Library[END_REF]. Some of them like OntoSelect are ontology libraries that offer the ability of ontology selection. The SAIQL (Schema And Instance Query Language for OWL DL) proposed in NeOn project, is a sample language well suited for to extract a domain oriented sub-ontology [START_REF] Kubias | OWL SAIQL-an OWL DL query language for ontology extraction[END_REF].On the ontology selection, sub-ontology extraction and ontology pruning process, users usually need to input the related concepts either by manual input or extraction from other documents/knowledge sources. Some approaches such as TEXT-TO-ONTO [START_REF] Maedche | The TEXT-TO-ONTO Ontology Learning Environment[END_REF] generate ontology based on the concepts discovered from texts or other resources. Lonsdale et al. take natural language (NL) documents and source ontologies as input, and then select/discovery related concepts etc. from source ontologies on the basis of descriptions in NL documents [START_REF] Lonsdalea | Reusing Ontologies and Language Components for Ontology Generation[END_REF]. The main focus in these approaches are discovery/select concepts etc. based on documents for ontology generation, but understanding the contexts of SMEs and then proposing optimal ontologies to best satisfy SMEs' contexts is not the advantage of their approaches.

Although in the construction process, lots of the reuse processes are supported by semantic web technologies like ontology searching, selecting, merging, evaluation, but these technologies are still immature. Most of the processes still need lots of manual interventions. Moreover, they are mostly based on a hidden assumption that users know which the right ontologies considering their particular contexts are, and then users are able to understand, select and reuse ontologies for their own ontology construction. However, when the ontologies as well as application contexts and constraints become increasing complex, for instance, in the traceability context, users (e.g. users in SMEs) usually have no clear ideas about what the optimal traceability level and optimal information profiles (optimal ontologies) for them are. They do not know exactly whether a concept or property should be encompassed. The users in SMEs do have much knowledge on their own process models, motivations of traceability and complied regulations etc., but have little knowledge regarding ontology construction, as a result, the existing approaches for ontology construction would be unsuitable or a great challenge for them.

The term of Mass customization coined by Davis [START_REF] Davis | From 'future perfect': Mass customizing[END_REF] was defined as "producing goods and services to meet individual customer's needs with near mass production efficiency" [START_REF] Tseng | Mass customization[END_REF]. As the definition states, the goals of mass customization are to best server various customers' needs while at the same time maintain high efficiency. Production configuration for generating a product variant for a rapid response of customers' individual demands is one of the key approaches to enable mass customization. Considering the diversities in business environments and dynamics in traceability needs, the concept of mass customization used in manufacturing is possible to be applied in the customization of "local ontologies" (information profile) for traceability in SMEs.

Proposed Approaches

In order to answer aforementioned challenges, a framework which adopts the concepts of mass customization to shape the right information profiles will be presented. The core components for ontology customization in the framework are shown in the Fig. 2.

The service side provides toolkits for domain experts to maintain generic ontology structures, modularized reference ontologies and associated knowledge bases. In the repositories, the ontology modules are kept and the interoperability between ontology modules is pre-analyzed. For reusing and mass customization, related context information is attached to the ontology modules. The context information of ontology modules will be then associated with models of SMEs to help to select the right modules. In the knowledge base, the knowledge related to food traceability as well as the knowledge related to ontology customization like generic ontology structure are kept. Meanwhile, toolkits for SMEs are provided to support them model their own contexts, constraints etc. With the help of the toolkits, the factors like regulations, customer requirements and process models, etc., which would drive the selection of traceability data elements and customization of ontologies, could be clearly modelled.

Service Side

Models of SMEs regarding traceability related contexts, constraints etc.

Reasoners and Components for ontology optimization and customization

Toolkits for experts to maintain ontology repositories and associated knowledge bases For instance, the following or toolkits could be included:

• Toolkits for business process model. Business process models represent processes, resources, products, etc. of an enterprise. Based on the process models, the potential information capture points as well as related costs and constraints are identified. The toolkits could be based on available tools like MO² GO [START_REF] Mertins | MO² GO. Handbook on Architectures of Information Systems[END_REF].

• Toolkits for capturing customer requirements. In order to satisfy customer needs, requirements from customers should be captured and reflect in the information profiles. For example, if health impact of the foods with respect to special customer groups is critical importance, then collection, processing and evaluation health associated information (e.g. nutrition) would be in a relative high priority. Some toolkits from quality management areas like Quality Function Deployment (QFD) are possible to be equipped in the framework.

After the reference modularized ontologies, knowledge bases and the environments of SMEs etc. are specified within the framework, the methodologies used in mass customization, e.g. constraint satisfaction approach, will be employed to propose optimal local ontologies. In the customization process, ontology modules which satisfy the requirements and targets of SMEs' contexts are selected and then merged. For example, if the models of a SME show that sustainability information of a food product is demanded only by a few consumers and is costly to be gathered, then the ontology modules related to sustainability information would not be selected. In the local contextualized ontologies, the data elements/concepts which the SMEs really interested in are displayed. Based on customized ontologies, information dispersed in many other systems is then integrated to produce the needed traceability information products, as shown in Fig. 3. Besides, it provides guidance for the SMEs to collect and prepare the required but missed data elements. Since the customized local ontologies of SMEs are generated on the basis of the repository of modularized ontologies, the semantic interoperability between information products is then supported by the pre-specified interoperability of the reference modularized ontologies. SME To ensure that the required traceability data supporting necessary scenarios are available within all partners of a supply chain, the partners producing the same ingredients in the same supply chain should negotiate to have a customized common shared ontology. In the ontology, the traceability information that needs to be exchanged in the supply chain is explicit expressed. Fig. 4 shows a mechanism for the coordination and determination of the common shared ontology in a sample supply chain. For each specific kind of partners (e.g. broiler farm), a high-level agent is initialized. The high-level agent will first coordinate with its sub-level agents i.e. agents of SMEs, as well as with other high-level agents to get necessary information. The information is then transformed and used as input for the aforementioned ontology customization approach to suggest common shared ontologies for the supply chain. At last, a governance boarder will make some modifications and determine the customized common shared ontology in the supply chain. The common shared ontologies describe the traceability information that will be exchanged and provided by partners. When there are some dynamic changes in business environment (e.g. Changes in partnership or customer demands), the ontologies could be easily recustomized to adapt to the new environment. For instance, imagine sustainability related information is currently missed in a food supply chain, but when this kind of information is required by regulations, and at the same time their target consumers are willing to pay for it, then the common shared ontology as well as local ontologies of the partners need to be quickly re-customized to encompass the sustainability related data elements/concepts.

Conclusions

Identifying the list of data elements to be recorded is significant important for an efficient supply chain traceability systems. Depending on product characteristics, process model, customers' demands, motivation of traceability etc., the optimal information profiles which specify the needed traceability information are usually different from one to another. For information integration and semantic interoperability, the information profiles are expressed as local ontologies that represent SMEs' own perspectives on traceability information. Considering the dynamics in business environments and diversities in traceability needs, the paper adopts the concept of mass customization into the customization of these local ontologies /information profiles. An efficient framework to help these SMEs to negotiate and shape the right traceability information products is briefly presented. It involves the toolkits to help SMEs to model traceability relevance factors, such as business process models, customer demands, etc. With the pre-specified interoperability between modularized reference ontologies, semantic interoperability of the traceability information between various SMEs is also guaranteed. To ensure that the traceability data required to support necessary traceability scenarios are available within all partners of a supply chain, multi-agents and ontology governance boarder are introduced in the coordination mechanism. In traceability areas, this paper is supposed to provide a methodology for the determination of the to be recorded traceability information. In ontology construction area, it tries to adopt the concepts of mass customization to help the users who do not know clearly what right ontology for their purposes is and the ones who are not familiar with ontology technologies to easily get the customized ontologies that could satisfy their particular contexts. For the collaboration of the SMEs in food chain networks, a coordination mechanism is simply introduced.

In future work, we will start detailing the components, associated toolkits and building the framework described in the paper. Definitely, there are many challenges to build the system and run successfully in food industry. Because the ontologies in SMEs are customized through reusing modularized ontologies, the quality and granularity of ontology modules will certainly affect the quality of customized ontologies. The context information of ontology modules should be carefully designed, so that the modules could be correctly reused. With respect to context models of SMEs, some issues like how to model the driving factors and then use them effectively for the selection of traceability data elements as well as customization of related ontologies still need to be further detailed. For the negotiation of common shared ontologies, the cooperation and communication between agents will be further specified. And then the approach is expected to be experimented in food industry to evaluate how well it works in real business scenarios.

Fig. 2 .

 2 Fig. 2. Basic Structure in Framework for Ontology Customization.

Fig. 3 .

 3 Fig. 3. Interoperability between SMEs.

Fig. 4 .

 4 Fig. 4. Coordination Mechanism for Determination of Common Ontologies in a Sample Broiler Supply Chain


Zhaogang Han
email: hanzhaogang@gmail.com

Li Zhang

Jimin Ling
email: lingjimin@126.com

Shihong Huang
email: shihong@fau.edu

Control-flow Pattern Based Transformation from UML Activity Diagram to YAWL

Keywords: Business Process Verification, UML Activity Diagram, YAWL, Transformation,Control-flow Pattern

Business process verification is an important topic in business process management (BPM). The verification of standard UML Activity Diagram is not easy due to lack of mature tools. YAWL (yet another workflow language) has a formal semantics based on Petri net; verification of YAWL model seems easier than other modeling languages such as UML-AD. A series of mature verification tools has been released (Woflan, WofYAWL, ProM) based on YAWL to find structural errors, such as deadlocks in the model. These tools can be used for verifying UML-AD models if they can be transformed to YAWL models. The most challenging problem is that some control-flow patterns in UML-AD can't be transformed via an element-toelement mapping. To solve this problem we provide a control-flow pattern based method for transforming a UML-AD model to YAWL. We regard these patterns that need to be transformed as whole model segments, pick them out from the UML-AD model and transform the left part using an element-to-element mapping as well as an object flow transforming method. We subsequently transform the picked-out patterns via patterns-based transformation and combine all the transformed YAWL segments to a new YAWL net.

Introduction

Business process verification is an important topic in business process management [START_REF] Burlton | Business process management: profiting from process[END_REF][START_REF] Ter Hofstede | Business Process Management[END_REF][START_REF] Hepp | Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management[END_REF][START_REF] Smith | Business Process Management: The Third Wave[END_REF][START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF]. This involves identifying structural conflicts in the business process definition. UML Activity Diagram is intended for modeling computational and business processes [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF][START_REF] Dong | Using π -calculus to Formalize UML Activity Diagram[END_REF][START_REF] List | A UML 2 Profile for Business Process Modelling[END_REF][START_REF] Korherr | Extending the UML 2 Activity Diagram with Business Process Goals and Performance Measures and the Mapping to BPEL[END_REF]. UML Activity Diagram (UML-AD for short) has a wide usage in business process modeling and lots of research work have been done concerning its verification [START_REF] Eshuis | Verification support for workflow design with UML activity graphs[END_REF][START_REF] Baldan | Specifying and Verifying UML Activity Diagrams Via Graph Transformation[END_REF][START_REF] Eshuis | Symbolic model checking of UML activity diagrams[END_REF] , but these work usually take a subset of UML-AD as a verification basis and some advanced control structures (for example, cancel activity and cancel region) has been excluded from this subset.

YAWL [START_REF] Van Der Aalst | YAWL: yet another workflow language[END_REF][START_REF] Van Der Aalst | Design and Implementation of the YAWL System[END_REF][START_REF] Hofstede | Modern business process automation:YAWL and its support environment[END_REF] is a BPM system having a formal semantics based on Petri net. Because of its foundation on Petri net, its verification seems easier than other modeling languages such as UML-AD. There are lots of research works [START_REF] Verbeek | Verifying Workflows with Cancellation Regions and OR-joins: An Approach Based on Relaxed Soundness and Invariants[END_REF][START_REF] Verbeek | Verifying workflows with cancellation regions and ORjoins: an approach based on invariants[END_REF][START_REF] Wynn | Verifying Workflows with Cancellation Regions and OR-Joins: An Approach Based on Reset Nets and Reachability Analysis[END_REF][START_REF] Wynn | Business Process Verification -Finally a Reality![END_REF] and a series of mature tools [START_REF] Verbeek | Woflan 2.0 A Petri-Net-Based Workflow Diagnosis Tool[END_REF][START_REF] Van Der Aalst | ProM 4.0: Comprehensive Support for Real Process Analysis[END_REF][START_REF] Verbeek | Diagnosing Workflow Processes Using Woflan[END_REF][START_REF] Van Dongen | The ProM Framework: A New Era in Process Mining Tool Support[END_REF][START_REF] Verbeek | WofYAWL[END_REF] concerning the verification of YAWL. And YAWL models with advanced control structures like or-join and cancel region can be verified using these mature tools. In order to benefit from these mature tools, a transformation from UML-AD to YAWL is needed. In [START_REF] Han | Transformation of UML Activity Diagram to YAWL[END_REF], the first step has been taken but only a small subset of UML-AD has been taken into account. So it is a good start but far from enough. In this paper we try to give a deep analysis of this transformation.

Some key questions in such a transformation are "Can we keep all the control aspect information without being lost in the transforming procedure" and "what technology should be taken to guarantee a "correct" transformation". In this paper a method based on control-flow patterns is proposed to solve these problems.

We propose a three-step method to implement this transformation. Based on a rigorous analysis, numerous results are drawn on how UML-AD and YAWL support all the 43 control-flow patterns, control information of which patterns will lose during the transformation, which pattern need to be transformed as a model segment and which pattern can be transformed by element-to-element method. After picking out the model segments that need to be transformed by pattern-based way in the first step, we transform the rest parts of model based on an element-to-element mapping rule. In the second step we transform UML-AD object nodes and object flows into YAWL data and control flow since UML-AD object flows also contain control informations. In the third step we transform the picked-out model segments via patterns-based method and combine all the transformed YAWL segments to a whole YAWL net.

The rest of the paper is organized as follows. Section 2 provides background information regarding model transformation and UML activity diagram. In section 3 based on the assumption that the model segments that need to be transformed by pattern-based way have been picked out, we transform the rest parts of model based on UML-AD and YAWL meta-models. An element-to-element mapping is used first followed by transformation of UML-AD objects node and objects flow into YAWL data and control flow. Section 4 illustrates which patterns need to be transformed as a model segment by a pattern-based method and which patterns can be transformed by an element-to-element transformation based on a rigorous analysis. We then pick out the patterns (model segments) that need a pattern-based transformation and transform them via patterns-based method and combine all the transformed YAWL segments to a whole YAWL net. After presenting an example to illustrate our method (Section 5), we draw a conclusion and present future research issues in section 6.

Preliminaries

Model Transformation

Model transformation technology is first used in Model-Driven Software Development and now it has a widely application in many research domains [START_REF] Sendall | Model transformation: The heart and soul of model-driven software development[END_REF]. Two kind of model transformation methods have been identified in [START_REF] Mens | A Taxonomy of Model Transformation[END_REF]: Horizontal transformation where the source and target models reside at the same abstraction level and vertical transformation where the source and target models reside at different abstraction levels. The key point of model transforming is the definition of transformation rules. Traditional model transformation methods usually define their transformation rules based on the meta-models of the source model and the target model. Transformation rules are the mapping relations between the elements in the meta-models of the source and target model in majority of cases.

Model transformation is used to bridge the gaps between different business process languages on a different level of abstraction in BPM. Lots of research work has been done to transform other business process modeling languages to YAWL [START_REF] Han | Transformation of UML Activity Diagram to YAWL[END_REF][START_REF] Jianhong | Transformation of BPMN to YAWL[END_REF][START_REF] Decker | Transforming BPMN Diagrams into YAWL Nets[END_REF][START_REF] Mendling | Transformation of yEPC business process models to YAWL[END_REF][START_REF] Brogi | From BPEL Processes to YAWL Workflows[END_REF]. In [START_REF] Jianhong | Transformation of BPMN to YAWL[END_REF][START_REF] Decker | Transforming BPMN Diagrams into YAWL Nets[END_REF] BPMN (business process modeling notation) has been transformed into YAWL. In [START_REF] Mendling | Transformation of yEPC business process models to YAWL[END_REF] EPC (Event-driven Process Chains) has been transformed into YAWL. In [START_REF] Brogi | From BPEL Processes to YAWL Workflows[END_REF] BPEL has been transformed into YAWL. These transformations all aiming at the benefits from the verification tools based on YAWL since these modeling languages support advanced control-flow patterns such as or-join and cancel region and YAWL verification tools can verify these patterns [START_REF] Wynn | Business Process Verification Finally a Reality![END_REF].

Pattern-based model transformation is not a novel technique. Some researchers have earlier proposed the pattern-based transformation. They suggested selecting some certain model segment in the source model and transforming them to model segment in the target model. But how to determine these model segments (patterns) remains an unsolved problem. Most of current existing researches use design patterns to conduct the pattern-based model transformation when transforming PIM model to PSM model in a MDA environment. Graphic pattern was also used to transform a source graphical model to a target graphical model. This kind of pattern-based method only enlarges the operating granularity during the transformation (from element to model segment), it has no advantage in enhancing the conversion accuracy and ensuring the transforming correctness compared to the element-to-element method. Using the control-flow pattern based method proposed in this paper, we can expect a more precise and more "correct" result than the element-to-element method.

UML Activity Diagram

A business process model usually includes four parts of information: control aspect, data aspect, resource aspect and exception handling aspect. Since Woflan, WofYAWL and ProM mainly verify the control structures of YAWL model and our purpose is to check structural errors in UML-AD model (deadlock and etc.), we only show an analysis on how to transform control-flow aspect information to YAWL, other issues such as resources and exception handling is beyond this paper's scope. Figure 1 is a simplified UML-AD meta-model that contains necessary meta-classes that are needed to model business processes and we will exclude the resource (the ActivityPartation meta-class) and exception handling (the ExecptingHandler metaclass) aspects informations since they have no effects on the control structure correctness of business process model.

Meta-model Based Transformation

UML Meta-model

In order to define the element-to-element transformation rule, UML-AD metamodel and YAWL meta-model is needed. UML is a language defined under the MOF framework, UML-AD meta-model is described in [START_REF]The Unified Modeling Language™ (UML) specification version 2.3[END_REF] (chapter 11 and chapter 12).

The meta-model is, however, scattered in many small segments and some metaclasses solve no purpose for transformation. In this paper we illustrate in Figure 1the recommended subset of UML-AD notation for process definition. Meta-classes in light color rectangles stand for meta-classes having no graphic notations and used as classifier. Meta-classes in dark color rectangle stand for meta-classes having graphic notations which are used in modelling. The details of attributions can be found in [START_REF]The Unified Modeling Language™ (UML) specification version 2.3[END_REF].

YAWL notations

After a careful study of paper [START_REF] Van Der Aalst | YAWL: yet another workflow language[END_REF][START_REF] Van Der Aalst | Design and Implementation of the YAWL System[END_REF] and the YAWL 2.1 system, we come up with a YAWL meta-model that includes all the notations and meta-classes (without graphic notation) as shown in figure 3. Meta-classes in light color rectangles stand for meta-classes having no graphic notations which are used as classifier. Meta-classes in dark color rectangle stand for meta-classes having graphic notations which are used in modeling. Due to the limitation on space, the attributions have been left out.

Figure 3. YAWL meta-model

Element-to-element Transformation Rule

Based on UML-AD meta-model and YAWL meta-model given in previous section, we can define an element-to-element mapping rule as shown in table 1.

Table Net Not all notations have been listed in table 1. Note that there are no direct mapping relations between every element in UML-AD and YAWL. For example there are no corresponding YAWL notations for UML-AD object node and its subclasses.

Transform Object-Flows

Some business process modeling languages have more than one kind of flows connecting the basic modeling elements. For example BPMN has two types of flow namely sequence flow and message flow [START_REF]Object Management Group/Business Process Management Initiative[END_REF]. Some languages have only one kind of flow. The Event-driven Process Chains (EPCs) only has control flow connecting event, function and connector.

There are two kinds of activity edges in UML-AD, namely control flow and object flow [START_REF]The Unified Modeling Language™ (UML) specification version 2.3[END_REF]. While YAWL only has control flow connecting condition and task. YAWL has no graphic modelling notations for objects and object flow. How to transform object flow and different kinds of objects in UML-AD to YAWL is a big problem.

Objects and object flow are very important in UML-AD and there are several different kinds of object notations. These notations have been listed in figure 4. For more details about these notations refer to [START_REF]The Unified Modeling Language™ (UML) specification version 2.3[END_REF]. Not all object aspect informations will be transformed into YAWL since the majority of them have nothing to do with the control aspect information. Figure 4. Object notations in UML-AD As a business process modeling language, YAWL has provided modeling mechanism to describe objects and data, as well as the movement of objects and data transfer. In YAWL, data-aspects information is modeled as variables. There are two types of variables namely net variable and task variable, both of which can have a variable type pre-defined or defined by the user. Task can have input parameters and output parameters, an input parameter defines a data transformation from a net variable to a task variable and an output parameter defines a data transformation from a task variable to a net variable. For more information about data aspect of YAWL, refer to [START_REF] Ter Hofstede | [END_REF], chapter 5. When transforming object flows in UML-AD to YAWL, we first transform all the object nodes to the "pin" form and then we transform pins attached to actions and object flow related with them to YAWL data attached to tasks and control flow between the tasks. Object flow attributes like weight and effect have been omitted during the transformation since they have nothing to do with the control-flow information contained in object flows.

As an example, consider a UML-AD segment with object flow shown in figure 6.

Figure 6. UML-AD object flow example Figure 7. Corresponding YAWL notations of figure 6 We can model this UML-AD segment in YAWL editor. The graphic notations have been shown in figure 7. And in order to model the object "order" between tasks "FillOrder" and "ShipOrder", we need to define a data type named "OrderType" in the YAWL net that contains these two actions as shown in figure 8 and a net variable named "Order" with that data type. Then we define a task variable of task "FillOrder" and a task variable of task "ShipOrder" with the same name "Order", both of which have a data type of "OrderType". The transformation of "Order" then can be illustrated by two task parameters. One parameter is defined under task "FillOrder" with a parameter type "Out" to illustrate the flow of "Order" from the task "FillOrder" to the net and the other parameter is defined under task "ShipOrder" with a parameter type "In" to illustrate the flow of "Order" from the net to the task "ShipOrder". Workflow pattern was first proposed by Van Aalst in 2003. In [START_REF] Van Der Aalst | Workflow Patterns. Distributed and Parallel Databases[END_REF] Aalst systemically defined 20 workflow control-flow patterns. In 2006 Russell put forward a revised version of workflow control-flow patterns [START_REF] Russell | Workflow ControlFlow Patterns: A Revised View[END_REF]. Shortly after the proposal of control-flow pattern, other workflow patterns like workflow data pattern [START_REF] Russell | Workflow data patterns[END_REF][START_REF] Russell | Workflow Data Patterns: Identification, Representation and Tool Support[END_REF], workflow resource pattern [START_REF] Russell | Workflow resource patterns[END_REF][START_REF] Russell | Workflow Resource Patterns: Identification, Representation and Tool Support[END_REF] and workflow exception pattern [START_REF] Russell | Workflow Exception Patterns[END_REF][START_REF] Russell | Exception Handling Patterns in Process-Aware Information Systems[END_REF] have also been identified. For more information about workflow patterns, refer to http://www.workflowpatterns.com/.

The research of workflow patterns have provided a thorough examination of various perspectives (control flow, data, resource, and exception handling) that need to be supported by a workflow language or a business process modeling language. The examined results can be used to evaluate the suitability of a particular process language or workflow system for a particular project, implement certain business requirements in a particular process-aware information system, and serve as a basis for language and tool development.

43 control-flow patterns are used to guarantee a "correct" transformation and enhance the precision of the transformation in this paper. Control-flow patterns are divided into eight categories, the first and the most simple category is the basic control-flow patterns, which includes sequence, Parallel Split, Synchronization, Exclusive Choice and Simple Merge. Figure 9 illustrates these five patterns in UML-AD. For detail description of these control-flow patterns, refer to [START_REF] Russell | Workflow ControlFlow Patterns: A Revised View[END_REF]. Neither YAWL nor UML-AD supports all the 43 control-flow patterns. For the patterns that are supported only by UML-AD, the control aspect informations that they stand for will be lost during the transformation, since they can't be described in YAWL. These patterns mainly belong to the categories of advanced branching and synchronization and trigger patterns; these patterns are colored as red in table 2. This implies the limits of YAWL when describing control aspect informations of business process model. An improved version of YAWL language has been proposed in [START_REF] Russell | New YAWL: designing a workflow system using coloured Petri Nets[END_REF], this new YAWL supports all the 43 control-flow patterns.

There are 10 patterns that are not supported by UML-AD though YAWL supports them. These patterns mainly belong to the category of advanced branching and synchronization and the category of state-based patterns. These are colored as light green in table 2. State-based patterns are not well supported since there are no notations representing state changing like a condition in YAWL.

Patterns that supported by both UML-AD and YAWL can be and should be transformed from UML-AD to YAWL without losing the control aspect information. But how to transform them properly remains a problem. After a thorough study of these patterns in UML-AD and YAWL, we identify 6 patterns that need to be transformed by a pattern-based way and 2 patterns that in some certain cases need to be transformed by a pattern-based way which are colored as orange in table 2. The patterns colored as green in table 2 represent those patterns that can be easily transformed using an element to element transformation. Detailed analysis will be given in the next section.

Besides these patterns, there are 3 patterns colored as blue in table 2 Table 2.

Control-flow pattern based evaluation of UML-AD and YAWL

To achieve a + rating (direct support) or a +/-rating (partial support) the language should satisfy the corresponding evaluation criterion of the pattern. Otherwise a -rating (no support) is assigned. We use color gray to identify the 8 pattern categories. Blue color stands for patterns that not supported by both UML-AD and YAWL. Light green is used for patterns that UML-AD doesn't support. Red color represents the patterns that YAWL doesn't support. Green color stands for patterns that can be transformed by element-to-element mapping. Orange color stands for patterns that need to be transformed by pattern-based transformation.

Patterns should be transformed by Pattern-based Transformation

There are five basic control patterns that are supported by all BPM languages. Due to their simplicity it seems unnecessary to transform them by the complex pattern-based way. But a careful study reveals that this is not the case. If parallel split (pattern 2) and synchronization (pattern 3) is modeled in UML-AD in the way shown in figure 10 (a), there will be no problem if we transform these two patterns by an element-to-element mapping: action in UML-AD to atomic task in YAWL, ForkNode in UML-AD to And-Split Node in YAWL and JoinNode in UML-AD to And-Join Node in YAWL. Then we will get a YAWL net as shown in figure 10 (c). The YAWL net we obtained is correct as it is in accordance with the YAWL syntax. We only need to first merge the Atomic Task 1 and AndJoin Task and then merge the AndSplit Task and Atomic Task 2 to finally get a result as shown in figure 10 (d).

UML-AD language grammar allows another form of these two patterns. Consider a model segment shown in figure 10 (b). This is another form of parallel split (pattern 2) and synchronization (pattern 3) and they can't be transformed via an element-to-element mapping to YAWL model segment as figure 10 (c) since the ForkNode and JoinNode has been omitted and we can't get the "AndJoinTask" and "AndSplitTask" in figure 10 (c). And only after we have got figure 10 (c) can we simplify it to figure 10 (d). So we can draw a conclusion that parallel split and synchronization in figure 10 (b) can't be transformed to figure 10 (c) by element-toelement mapping and a pattern-based transformation is needed. We need to first recognize parallel split and synchronization in this form and then transform them as a whole to YAWL segment as shown in figure 10 (d). Another pattern that needs a pattern-based transformation is the multi-choice pattern (pattern 6). This pattern provides the ability for the thread of execution to be diverged into several concurrent threads on a selective basis. The decision as to whether to pass the thread of execution to a specific branch is made at runtime. This pattern is essentially an analogue of the Exclusive Choice pattern (pattern 4) in which multiple outgoing branches can be enabled [START_REF] Russell | Workflow ControlFlow Patterns: A Revised View[END_REF]. Since there is no specialized notation for multi-choice in UML-AD, ForkNode is used to achieve this pattern as shown in figure 11(a). It is different from the parallel split pattern since there are guards on each of the output control flows. In the example of figure 11, after execution Action1 will output a ValuePin named "x" and the value of x has been determined during the execution of Action1. It is passed to the ForkNode and the routing is then determined by the value of x. If x>10 Action2 and Action3 will be executed and if x<10, Action4 will be executed. This is different from Exclusive Choice (Pattern 4) since in Exclusive Choice the guards on each of the outgoing control flows after ForkNode must be mutually exclusive. This pattern also needs a pattern-based transformation to get a result YAWL net as shown in figure 11(b) because if we use an element-toelement mapping the ForkNode notation in Multi-Choice pattern will be mapped to a YAWL And-JoinTask resulting in a wrong output. Figure 12 is the multi instance without synchronization (pattern 12) in UML-AD and YAWL (refer to [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF] and [START_REF] Ter Hofstede | [END_REF]). After Action1 (AtomicTask1), a multi-instance action namely "MIActionWithoutSychronization" (a MIAtomicTask named "MITaskWithoutSychronization") is created. The MI action (MITask) will create 10 instances of itself, leaving these instances executing and give the control-flow token to Action2(AtomicTask2) which means Action2(AtomicTask2) will start execution without the synchronization of any instances of the MI action (MI Task). Pattern 12 has a different form in UML-AD and YAWL due to the lack of specialized notation for MI actions in UML-AD.

As shown in figure 12(a), the initial value of x is 0, the action "MIActionWithoutSychronization" will be executed if x<10 so it will be executed 10 times and Action2 will not wait for the finish of its ten instances to start execution. The corresponding YAWL net is shown in figure 12(b). There is a specialized notation for MI actions in YAWL called MIAtomicTask having 4 parameters. The first parameter "10" means the task "MITaskWithoutSychronization" will have a minimum instance number of 10; the second parameter "10" means the task will have a maximum instance number of 10. So these two parameters define the instance number to be 10. The third parameter "0" means 0 instance of this MIAtomicTask needs to be synchronized and the last parameter "s" (short for static) indicates that new instances cannot be created dynamically during the execution of any instances. For more information of MIAtomicTask, refer to [START_REF] Ter Hofstede | [END_REF]. InterruptibleActivityRegion can be used to model cancel-related patterns in UML-AD [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF], whereas in YAWL CancelRegion is used to model these patterns. Element to element mapping transformation of these patterns will be troublesome. Due to the limited space we take cancel task (pattern 19) as an example to illustrate why a pattern-based transformation is needed and the other cancel patterns may be treated as same as cancel task pattern.

As shown in the UML-AD diagram of figure 13(a), the InterrruptibleActivityRegion has two actions in it: Action2 and Action3. Whereas in the corresponding YAWL net in figure 13(b), AtomicTask3 has a cancel region with only one task (AtomicTask2) in it (this is illustrated by the red point in the top right corner of the notation of AtomicTask3 and the red outline of AtomicTask2). So a pattern based transformation is also needed when transforming this pattern. After patterns that need to be transformed by pattern-based method have been identified, we can pick them out of the source UML-AD model, transform the left parts to YAWL using a meta-model based method and then transform the pick-out parts via a pattern based method. We subsequently combine all the transformed YAWL segments together and get a whole target YAWL model.

Example Illustrating Our Method

In order to illustrate our methods we take a UML-AD model shown in figure 14 as a source model and transform it to a target YAWL net as shown in figure 15. The status of Order will be "Accepted" only if both of the checkers accept it, otherwise the status will be "Rejected" and the activity will be terminated. The "ProcessOrder" action will be executed for ten times by different workers so it is a multi-instance action. An InterruptableActivityRegion is used as cancel region (pattern 25), the whole order-processing process can be canceled if a "CancelRequest" is received.

Since there are three patterns that need a pattern based transformation in the source UML-AD model, we have to first pick these patterns out and transform the left parts of the model to YAWL via a meta-model based meethod, that is, an element-toelement mapping and a transformation of object flow. Note that we have omitted the data aspect of the target YAWL net due to a limited space. Then we transform the picked-out patterns using a pattern based transformation. Element-to-element mapping and object flow transformation may also be used during this procedure. The final target YAWL net is as shown in figure 15. Note that there is an additional Or-Split Task in the target YAWL net connecting the InputConditon and the TimeTask "CancelRequest". This signifies a problem caused by the multi-start phenomenon in UML-AD. For details about this problem, refer to [START_REF] Han | Transformation of UML Activity Diagram to YAWL[END_REF].

Conclusion and Future Work

In order to benefit from the mature verification tools (Woflan, WofYAWL, ProM) based on YAWL, UML Activity Diagrams need to be transformed to YAWL nets. Since our goal is to verify UML-AD model and to check if it contains structural errors like deadlock and lack of synchronization, therefore our study has been limited to transformation of control-flow aspect information only. A transformation method that transforms all information that can be transformed to YAWL is beyond our discussion.

Based on a proposed YAWL meta-model, this paper has solved the UML-AD to YAWL transformation problem by a three step method. First UML-AD object nodes and object flows are transformed into YAWL control flows by adding necessary data to the corresponding task nodes. Secondly all control-flow patterns that UML-AD supports are analyzed and classified based on their transformation either by elementto-element mapping or by pattern to pattern methods. Finally the remaining model segments are transformed by element-to-element mapping based on UML-AD metamodel and the proposed YAWL meta-model. Since this method is more precise than the method proposed in [START_REF] Han | Transformation of UML Activity Diagram to YAWL[END_REF], we can expect a better result when verifying UML-AD models using YAWL verification tools.

The future work includes applying this control-flow pattern based transformation method to transform other business process modeling languages to YAWL to check if we can get better transformation results than other transformation methods [START_REF] Jianhong | Transformation of BPMN to YAWL[END_REF][START_REF] Decker | Transforming BPMN Diagrams into YAWL Nets[END_REF][START_REF] Mendling | Transformation of yEPC business process models to YAWL[END_REF][START_REF] Brogi | From BPEL Processes to YAWL Workflows[END_REF]. Moreover we aim to use this transformation method to convert the large amount of UML-AD process models to YAWL and analyze them with verification tools such as Woflan, WofYAWL and ProM.

Figure 1 .

 1 Figure 1. UML-AD meta-model 3.2 YAWL Meta-model unlike UML-AD, YAWL is defined basing on a formal semantic of Petri net and it has no meta-model that fits the MOF framework. The YAWL graphic notations are shown in Figure 2.

Figure 2 .

 2 Figure 2. YAWL notationsAfter a careful study of paper[START_REF] Van Der Aalst | YAWL: yet another workflow language[END_REF][START_REF] Van Der Aalst | Design and Implementation of the YAWL System[END_REF] and the YAWL 2.1 system, we come up with a YAWL meta-model that includes all the notations and meta-classes (without graphic notation) as shown in figure3. Meta-classes in light color rectangles stand for meta-classes having no graphic notations which are used as classifier. Meta-classes in

Figure 5 .

 5 Figure 5. Data aspect meta-classes in YAWL

Figure 8 .

 8 Figure 8. Data type definition of OrderType

Figure 9 .

 9 Figure 9. Basic control-flow patterns in UML-AD 4.2 Control-flow Patterns in UML-AD and YAWLNeither YAWL nor UML-AD supports all the 43 control-flow patterns. For the patterns that are supported only by UML-AD, the control aspect informations that they stand for will be lost during the transformation, since they can't be described in YAWL. These patterns mainly belong to the categories of advanced branching and synchronization and trigger patterns; these patterns are colored as red in table 2. This implies the limits of YAWL when describing control aspect informations of business process model. An improved version of YAWL language has been proposed in[START_REF] Russell | New YAWL: designing a workflow system using coloured Petri Nets[END_REF], this new YAWL supports all the 43 control-flow patterns.There are 10 patterns that are not supported by UML-AD though YAWL supports them. These patterns mainly belong to the category of advanced branching and synchronization and the category of state-based patterns. These are colored as light green in table 2. State-based patterns are not well supported since there are no notations representing state changing like a condition in YAWL.Patterns that supported by both UML-AD and YAWL can be and should be transformed from UML-AD to YAWL without losing the control aspect information. But how to transform them properly remains a problem. After a thorough study of these patterns in UML-AD and YAWL, we identify 6 patterns that need to be

  namely Pattern 22(Recursion), Pattern 27(Complete Multiple Instance Activity), and Pattern 36(Dynamic Partial Join for Multiple Instances) which are not supported by either UML-AD or YAWL.

  (a) Standard form of parallel split and synchronization in UML-AD (b) Simplified form of parallel split and synchronization in UML-AD (c) Transformed YAWL (d) Simplified YAWL Figure 10. Different forms of parallel split and synchronization in UML-AD and YAWL

  (a) UML-AD (b) YAWL Figure 11. Multi-Choice (Pattern 6) in UML-AD and YAWL

Figure 12 .

 12 Multiple Instances without Synchronization (Pattern 12) in UML-AD and YAWL

  (a)UML-AD (b) YAWL Figure 13. Cancel Task (Pattern 19) in UML-AD and YAWL

Figure 14 .Figure 15 .

 1415 Figure 14. An order process model in UML-AD

Acknowledgments This work is supported by the National Natural Science Foundation of China under Grant No. 61170087.