Keywords: Case Management, CMMN, HiLLS, Model Transformation, Process Improvement

In today's business world, customer requirements change more rapidly than ever before, and new competitors are increasing every second. Moreover, the ability of managing changes and unpredictability has become a crucial factor for enterprises to make more value and stay competitive [Oracle 2013]. This results in a fact that nowadays enterprises are challenged with not only managing structured business processes, but also more and more unstructured ones. In a common structured business process, everything regarding the process can be predetermined at design time, such as activities, the execution sequence of activities, and so on. However, in an unstructured one the activities cannot be defined precisely beforehand, as well as the sequence to execute. To stay competitive, meet the ever-changing market demands and improve their business process operational efficiency, organizations need a novel process approach that can help them manage changes, dynamics and unpredictability. Under this context, the concept of Case Management is proposed. Different from Business Process Management (BPM) which standardizes and automates structured business processes, CM overcomes the BPM approach limitations and provides an infrastructure for managing changes, dynamics and unpredictability in unstructured business processes. CM proceeds largely depending on evolving circumstances, and decisions are made on the fly. BPM requires a high level of predictability; whereas CM has a lower level of predictability but a higher level of adaptability and flexibility. With CM approach, enterprises are able to manage their unstructured business processes in a more adaptive and flexible manner.

), and no noticeable contribution has been done in other aspects. This these presents our CM approach that provides case workers full supports in the whole lifecycle of CM: from establishing case models from raw data to optimizing case models. Process Tree is our choice to formalize the discovered model, and CMMN (Case Management Model and Notation, a case modeling specification is selected as the formalism for presenting and constructing case models. In addition, we adopt the HiLLS (High Level Language for Systems Specification) formalism to II conciliate usability, simulation ability and formal analysis capabilities together. Dynamic model analysis is enabled by DEVS formalism, static model analysis is provided by formal methods, and model enactment is given by the implementation of an object-oriented specification of the case. We propose mainly two modules in this these: one module concerning the discovery of the case model from historical event logs, and another module concerning the improvement and the optimization of the case model.

III

Acknowledgment

I would like to thank my fellow doctoral students for their feedback, cooperation and of course friendship, especially to Oumar and Hamzat. Without the discussions with them and their feedback I could not go this far with this these. I would like also to thank my thesis director, Professor Mamadou Kaba Traoré. As a foreigner PhD candidate, he helped me a lot both in my research work and my personal life. He showed me how to be a researcher, as well as how to do the research work in an excellent manner.

I would like to thank my friends for accepting nothing less than excellence from me. Last but not the least, I would like to thank my family: my parents and to my wife for supporting me spiritually throughout writing this thesis and my personal life in general. Table 2- (CFM,suspend,1,[100,180]) .. Figure 4-16: The configuration transition of event (IR,complete,4,[10,15]) .........

IV

Table of Content

VI

Table of Tables

VII

Table of Figures

IX

List of Abbreviations

Context

In today's business world, customer requirements change more rapidly than ever before, and new competitors are increasing every minute. To stay competitive in business, organizations put their focuses on managing their business using scientific management approaches. Examples include:

x Customer Relationship Management (CRM), a management approach focusing on the management of the organization's interaction with their customers, and the goal of CRM is to drive sales growth through the improvement of business relationships with customers [BRIEF 2015].

x Enterprise Content Management (ECM), which refers to a set of strategies, methods, and tools developed for capturing, preserving and controlling process-relating information of any form (e.g., a paper document, an email).

x Enterprise Resource Planning (ERP), which aims at increasing the operational efficiency and effectiveness through integrating and sharing business activity data and standardizing business processes from best practices [Seo 2013].

x Business Process Management (BPM), the most important and widely used process management approach in recent years. Instead of focusing on the management of business activity information, BPM aims at improving corporate performance by managing and optimizing organizations business processes [START_REF] Page | The power of business process improvement: 10 simple steps to increase effectiveness, efficiency, and adaptability[END_REF]], and it has been the most widely studied and implemented process management methodology in business domain. A key feature of BPM is that it targets on automating routine work (and processes within routine work are called structured business processes): activities within such type of processes are completely predictable and repeatable. Everything regarding the process can be predetermined during process-design time, such as activities, the execution sequence of activities, and so on. It leads to a work pattern where BPM workers do their work by strictly following predefined process solutions.

However, in today's enterprises managers realize that the ability of managing knowledge work becomes a crucial factor for them to make more value and stay competitive. Knowledge work refers to the type of work in which the plan is determined and altered by the situation information obtained at execution time [START_REF] Swenson | Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done[END_REF]. Typical examples of knowledge work include medical work (the procedures of treatment cannot be predicted since judgments from doctors are required based on patients symptoms and their diagnosis results), customer support (it is difficult or even impossible to know which type of service is required in advance due to the fact that many details come late), law enforcement (the course of the investigation of a crime depends on the details unfold as time goes by, as well as the knowledge and experience of investigators), etc. All these use cases illustrate the unique features of knowledge work: (1) unpredictable, and (2) non-repeated.

We say that routine work is highly predicted since all the necessary activities required for completing that work can be specified beforehand. However, it is difficult to define how a knowledge work will be done (in terms of specifying all the necessary activities and the execution sequence of those activities) since the course of events is determined by many potential factors as the work proceeds. This is the essential nature of knowledge work: its plan changes in accordance with incoming situation information. As knowledge work proceeds, new information will be generated, and this new knowledge sets the next direction towards which the work will carry on. Then more information will be obtained, and the plan set from the last step will be altered based on that new discovered knowledge, and so on. This explains the reason why knowledge work is considered to be unpredictable. For example, a doctor cannot decide the exact treatment procedures unless he receives enough information regarding the patient condition. But such original treatment procedures will not stay unchanged to the end of the treatment. The patient will come for another diagnosis or an examination after a while, and it is his diagnosis result that determines the treatment to be taken for the next step. The same story repeats until the patient is recovered from his illness. Moreover, in most situations knowledge work does not have the same level of repeatability as routine work has. Once a routine work scenario is standardized, all steps as well as the sequence of them will be specified and stay unchanged, and workers do their work by simply following what have been defined previously, without making any decision. Knowledge work, on the contrary, has many factors that make each instance a unique one. When dealing with knowledge work, the different specifics of each case cause a unique solution to meet its special requirements. Take the example we have mentioned before, due to the fact that patients come under different conditions, the doctor needs to formulate different treatment procedures considering the uniqueness of individual, in order to meet the needs of each particular case.

The first reference of the knowledge work concept was mentioned in [Drucker 1959], a book of Peter F. Drucker's named Landmarks of Tomorrow. Afterwards, the importance of knowledge work has been discussed by him and other researchers. Drucker pointed out that the most important task for organizations was "to make knowledge work productive" in [Drucker 1969]. Later in 1999 he emphasized that knowledge workers will be the most valuable asset in the 21 st century, and their productivity will be the key factor to business success [START_REF] Drucker | Knowledge-Worker Productivity: The Biggest Challenge[END_REF]]. Davenport discussed the importance of knowledge work from the perspective of what knowledge work can yield to organizations: they could come with new management strategies (if they are at the management hierarchy), they are able to design and create new products (if they are in the Research and Development department), they are capable of advertising their products and services in ways that attract customers (if they are in charge of selling products), and so on [START_REF] Davenport | Thinking for a Living: How to Get Better Perforances and Results from Knowledge Workers[END_REF]]. However, efforts regarding theories and approaches of work management and improvement in business domain have focused largely on repeatable routine work. A large number of process management theories have been proposed, and they have been implemented in the real world to help organizations solve their real business problems. The management of knowledge work did not gain much attention until 2010. Since then people start to consider how to improve the knowledge work existing within their business activities. However, due to its unique unpredictable and non-repeated features, the solutions for the pattern of repeated routine work is not appropriate any more. Therefore, a fundamental different process management methodology is required, which helps knowledge workers adapt changes, control dynamics and unpredictability as they work. This is the approach we will introduce and explain in the next section, i.e., Case Management.

Case Management

As more knowledge work appears in business domain over the past few years, managers start to be aware of the importance of the operational efficiency of unstructured processes with knowledge work, which needs a greater deal of flexibility, adaptability, autonomous decision making and collaboration to achieve organizations business objectives [START_REF] Zhu | Advanced Case Management with IBM Case Manager[END_REF]. In today's modern organizations, structured business processes cover around only 30%. Moreover, the following factors from different aspects serve as the driving forces for the research and development interest in a novel support for managing unstructured business processes [START_REF] Swenson | Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done[END_REF]]:

x An increased need to govern the costs and risks rising from the service management (e.g., after-sale service, claims management). x An increased emphasis on managing (i.e., automating and tracking) ad-hoc processes which are not defined precisely beforehand, where an ad-hoc process refers to a type of process that is not predictable. x A demand from government agencies of responding massive citizen requests in a rapid manner. x A need for regulators, auditors, and litigants to quickly react to external regulations.

x An increased demand of managing business with unstructured processes collaboratively and communicably.

Apparently, traditional process management approaches such as BPM or ECM are not sufficient, in some cases even not able, to handle knowledge work processes due to its unique features. Under this context, the concept of Case Management (also known as Adaptive Case Management, Advanced Case Management, etc.) is proposed. Different from BPM which targets on standardizing and automating structured business processes, case management overcomes the BPM approach limitations and provides an infrastructure for managing unstructured business processes. More specifically, case management deals with changes, dynamics and unpredictability. It proceeds largely depending on evolving circumstances, and decisions are made on the fly. Case management provides knowledge workers sufficient capabilities (flexibility, adaptability, autonomous decision making and collaboration) so that they can achieve positive outcomes.

The term of case management has different meanings in different areas, and this concept was referred only in domains such as legal, social work, healthcare markets and government, in a general sense. For example, in the medical care field, it refers to the planning and cooperation of health care services. In social service, it refers to the process of planning, seeking, and monitoring different social services [START_REF] Anastas | NASW standards for Social Work Case Management[END_REF]]. However, in recent years case management has been widely accepted by business organizations, and people render more general definitions of this concept, instead of restricting to one or several specific area(s). [START_REF] Omg | Case Management Model and Notation[END_REF] formally defines the concept of Case as "a proceeding that involves actions taken regarding a subject in a particular situation to achieve a desired outcome." A well accepted generic definition regarding case management is given by Forrester (one of the most powerful research firm that aims at helping clients improve their business results) in [START_REF] Clair | Dynamic Case Management-An Old Idea Catches New Fire[END_REF], where the case management is described as "a collaborative, dynamic, and information-intensive process driven by outside events requiring incremental and progressive responses from the business domain handling the case." [START_REF] Swenson | Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done[END_REF]] also defined case management as "Systems that are able to support decision making and data capture while providing the freedom for knowledge workers to apply their own understanding and subject matter expertise to respond to unique or changing circumstances within the business environment." Many vendors of BPM systems gave their understanding about case management as well, such as Cordys, Global 360, which will be discussed in more detail later in this thesis. All the following statements clearly illustrate the features of case management from the different aspects, and it is crucial to well understand its nature since we can judge which approach will fit and support this kind of work:

x Case management targets on governing unstructured processes occurring in knowledge work. The exact activates required are unknown beforehand, as well as their execution sequence.

x Case management is information sensitive. The unfolding information influences how a case proceeds. x Case management empowers knowledge workers. Unlike BPM where employees are asked to only follow what have been specified, knowledge workers in case management have the power and freedom to make decisions.

x Case management has a clear goal to be achieved. The exact path to reach the goal uncovers by yielded information and knowledge workers decisions, gradually.

x Case management requires communication and collaboration. Information should be shared and assessed by all relating knowledge workers, so that they can make better decisions when responding to ad-hoc events.

In a nutshell, the essential characteristics of case management are unpredictability, information-sensitivity, runtime planning and collaboration. Each Case in case management comes with an explicit goal, and it evolves based on the unfolding circumstances and information yielded from previous steps to achieve that goal. Moreover, it is the data collected and knowledge workers decisions that determine how a Case proceeds. Therefore, to ensure efficient case management practices it is inevitable for knowledge workers to (at least but not limited to): (1) determine which activities should be involved; (2) decide the execution sequence of selected activities; and (3) cooperate with other colleges for decision-making (de Man, 2009a).

Figure 1-1: The spectrum of business processes [START_REF] Kemsley | Case management and bpm[END_REF] As illustrated in the process spectrum given in Figure 1-1 [START_REF] Kemsley | Case management and bpm[END_REF]], on the left-hand side are highly structured processes where the traditional BPM approach is adopted to improve their operational performance. On the right-hand extreme of the spectrum are unstructured processes where case management is considered to be a promising solution as a process management approach (and processes positioning in the middle of the spectrum require a mix between BPM and case management approaches). In addition to this, compared with BPM approach case management solutions are fundamentally different for the following aspects:

x Processes in BPM are predictable and repeatable, while case management processes are unpredictable, and have a low level of repeatability. x BPM is focusing on the process and everything else necessary to complete the process; whereas case management focuses on the data of the Case, as well as other factors needed to achieve its goal. x In BPM, workers solve their problems by following a well-established process model beforehand: the concept of adaptation of the process does not exist. Knowledge workers accomplish their work by runtime planning and executing as the Case proceeds, and additional activities will be added if necessary.

x BPM rarely requires human participants' decisions, while case management requires case workers involvement to make decisions.

Generally, a Case can be categorized as one of the following three types: mass cases, regular cases, and special cases [START_REF] Rooze | eCase Management. An International Study in Judicial Organizations[END_REF]]. Mass cases are cases that can be controlled in a completely automated manner. The processes within mass cases are highly structured and predicted, and traditional process techniques (such as BPM) are adequate management approaches. Mass cases lay in the left-hand extreme of the process spectrum given above. Regular cases refer to cases that repeat over time (and they are positioning in the middle area of that process spectrum). However, the solution of each case instance is not exactly the same. As experience grows, common solution patterns (also known as templates) can be identified and formalized. Consequently, similar cases can be managed in a more rigorous and repeatable manner. Knowledge workers control how regular cases evolve and complete. In addition, the ways to complete cases are also constrained by other factors (business rules, availability of activities to choose from, etc.) that are defined in the templates. With respect to special cases (which are at the right-hand side of the process spectrum), case workers own the whole freedom on deciding how a Case evolves, based on their experience and their evaluation and judgment on incoming information. Solutions to special cases are discovered in a complete ad-hoc manner. Generally speaking, organizations start with managing special cases, with little suggestion to be referred. As time goes by, similar cases repeat, and recurring patterns can be revealed and summarized as templates by business analysts and modeling experts. As a result, special cases become regular ones. This becomes the practice of case management. Nowadays, organizations are more interested in exploring solutions on how to assist Case workers in managing regular cases, such as [START_REF] De Man | Case Management: Cordys Approach[END_REF][START_REF] Clair | Dynamic Case Management-An Old Idea Catches New Fire[END_REF][START_REF] Clair | The Forrester Wave TM : Dynamic Case Management[END_REF] and [START_REF] Zhu | Advanced Case Management with IBM Case Manager[END_REF].

Challenges

Among all the process management approaches, BPM receives the most attention of the business community in recent years. BPM is based on the scientific management principle proposed by Taylorist, in which the idea is to standardize rigid process models then execute these model for many times. The assumption behind BPM solutions is that the target processes are repeatable and predictable. However, due to its unique features of adaptability, unpredictability and non-repeatability, case management cannot take advantages from existing traditional BPM solutions. Knowledge workers need a type of support that allows them to do their work in an adaptive manner, instead of strictly following what have been defined in advance. Making changes to respond ad-hoc events when a case is being executed, anticipating critical problems, sharing information and making decisions collaboratively, etc., are essential capabilities to knowledge workers. From this point, BPM systems are inadequate and not suitable for governing case management processes.

Case management represents a new generation of process management technologies in terms of effectiveness, efficiency and adaptability. However, it lacks supporting methods and software tools. One essential aspect is case management process modeling. There are lots of benefits from modeling processes in the business domain, such as increasing the understanding of processes, visualizing the detailed components of process, identifying hidden risks, and so forth. Therefore, how to model case processes considering its flexible and adaptive characteristics becomes the starting point for researchers and analysts in the business community. This includes the practice of defining formal case management related concepts (e.g., case, case file, and task), specify the conceptual relationships between case management concepts, and nail down the graphical modeling notations, etc. Over the years, several case management modeling techniques have been proposed. Most noticeable ones include Business Artifact [START_REF] Nigam | Business artifacts: An approach to operational specification[END_REF], Case Handling [Aalst et al. 2005], Cordys [Man 2009b], Guard-Stage-Milestone [START_REF] Hull | Introducing the guard-stage-milestone approach for specifying business entity lifecycles[END_REF], IBM Case Manager [START_REF] Zhu | Advanced Case Management with IBM Case Manager[END_REF], etc. Unfortunately, their proposed solutions do not really fill the gap of case management process modeling since most vendors come with their BPM solutions with only few added features and they claim that they offer suitable systems for case management.

In order to formally standardize the modeling practices, OMG (Object Management Group) offered a case management process modeling specification (version 1.0) named CMMN (Case Management Model and Notation) in May 2014[START_REF] Omg | Case Management Model and Notation[END_REF]]. CMMN incorporates current case management research contributions (such as the Business Artifact concept, the Case Handling paradigm, and the Guard-Stage-Milestone approach), and defines an executable visual modeling language for case management processes. However, only a few countable discussions regarding CMMN can be found in literature since the modeling specification was released. Some BPM system vendors implement a case model editor on the basis of CMMN within their BPM systems. But with such case model editors knowledge workers are not able to deeply analyze the underlying processes within their work since what they have are merely static CMMN diagrams.

Regardless of the type of processes to be managed, the ultimate goal of any process management approach is to help organizations achieve their financial goal through improving operational performance. Case management is not exceptional at this point. Key process improvement theories such as Lean, Six Sigma, and Business Process Re-engineering (BPR) have illustrated their great profound influence in terms of process improvement in many areas. However, these theories have focused exclusively upon repeatable type of work. How to manage and finally improve knowledge work process performance was largely ignored in the past. This is no wonder since case management did not gain much attention from the business community until recent years. As far as our knowledge the efforts have been done only in the case management process modeling aspect, not to mention the contributions from the perspective of case management process improvement, such as adopting the Model and Simulation (M&S) technique to analyze case models dynamically, using formal methods to do formal analysis to case models, or embedding process discovery technique to explore case models automatically.

Objectives

To overcome the presented challenges and make contributions in the field of case management, we present here our case management solution in this thesis. The essential objective is to establish a system-theoretic case management framework with which knowledge workers are able to auto-discover and manipulate case models, identify problems (bottleneck, waste, etc.) hidden in processes, and predict operational performance of the system. Ultimately, the original case management process models will be improved. We offer the possibility for knowledge workers (both case managers and case workers) to managing their cases, regardless of the type of the case (i.e., special cases and regular cases). From constructing and analyzing case models to improve those models, our case management framework is expected to provide sufficient supports to manage cases throughout their whole lifecycle, from starting a case instance to its completion. The detailed objectives are:

Case Model Discovery

It refers to the automatic establishment of case models from raw data. Instead of constructing case models manually from scratch, case models can be extracted automatically, which eases the modeling effort of knowledge workers, especially when they are not experts in modeling.

Case Modeling

It refers to the construction and manipulation of case models, where a model represents the real system knowledge workers are interested in. By modeling cases, knowledge workers are able to study and analyze the systems of interest in an abstract manner.

Case Model Analysis

It refers to the detailed study and examination of case models. Through model analysis, case managers can obtain a deeper view on their work. The analysis practices can be classified into two categories: static model analysis, and dynamic model analysis. The former refers to the analysis performed without executing models, e.g., the derivation of properties before the case is enacted, while the latter refers to the model analysis in a dynamic manner through simulation.

Case Model Improvement

It refers to a set of approaches and tools used by case managers to enhance their process operational performance. Generally, after understanding the existing case models and obtaining detailed analysis results, constructing a to-be model and then testing if the predicted performance is accepted or not will be the next step.

Case Model Enactment

It refers to the real time execution of a case scenario, with case workers in the loop.

Different techniques are adopted in our solution for different purposes: process discovery is used to automatically construct case models; BPI techniques, for instance, BPR, Lean, Theory of Constraints (TOC), etc., are used to analyze and optimize case model. Process Tree [START_REF] Schunselaar | Process Tree Package. Seidewitz, E[END_REF]] is selected as our choice to formalize and graphically present discovered case models, and CMMN is considered as the formalism for presenting and constructing case models. In addition, we adopt the HiLLS (High Level Language for Systems Specification) formalism we have defined [START_REF] Maiga | An integrated language for the specification, simulation, formal analysis and enactment of discrete event systems[END_REF]] [Maiga et al. 2015] [Aliyu et al. 2015] to conciliate usability, simulation ability and formal analysis capabilities together in order to analyze case models from different perspectives. Dynamic model analysis is enabled by DEVS (Discrete-Event System Specification) formalism, static model analysis is provided by formal methods, and model enactment is given by the implementation of an object-oriented specification of the case. To bridge the gaps between different modeling specifications and ensure consistency between them, i.e., Process Tree, CMMN and HiLLS, we use model transformation, a core concept in Model-Driven Engineering (MDE).

Contributions

The contributions of this thesis can be summarized as follows:

1. A mapping between the de-facto case management modeling standard and a multi-purpose system modeling formalism. 2. An algorithm to automatically generate an experimental frame (EF) for each case model, i.e., a specification of the set of components required to run experimentations on the case model and derive dynamic properties. 3. An algorithm for the dynamic evaluation of process performance metrics from different perspectives. 4. A simulation-based methodology for predicting the implications of changes made in case models. 5. A connection between formal process discovery models and case models conforming to the de-facto case management modeling standard.

Outline of the thesis

The remainder of this document is structured as follows. In chapter 2, we will introduce and review related works, including process modeling in business domain, case management process modeling, and case management systems. In chapter 3, we will explain our research background, including the introduction of related modeling specifications (Process Tree, CMMN, and HiLLS) as system modeling languages, as well as the techniques and technologies adopted in our work (process discovery, process improvement theories and approaches, model transformation techniques, etc.). Our framework will be presented in chapter 4, where we will explain how case models are discovered, analyzed and improved within this framework. A case study will be given and discussed in Chapter 5 to illustrate how knowledge workers can manage their cases from different perspectives. We will finally make in Chapter 6 a general conclusion followed with research perspectives.

Introduction

In this chapter, we present the state of the art in case management modeling approaches and systems, as well as the improvement efforts made for case management processes. Though case management is a relatively unfamiliar term, it has gained more and more attention steadily over years, and enterprises have shown their own understanding and supporting tools in this new area. Therefore, we will present and discuss all the approaches developed for supporting case management, including the process improvement attempts. Moreover, we will review the work that has been done using process discovery technique in controlling business processes. Regarding the proposed approaches for case management modeling in the literature, we classify them into four categories on the basis of which aspect they offer for knowledge workers to analyze and manage case models:

x Activity-based Modeling Solutions (which focus on the aspect of control-flow modeling).

x Information-based Modeling Solutions (which focus on the aspect of information-flow modeling). x Communication-based Modeling Solutions (which capture the communications and collaborations between people). x Hybrid Activity and Information Modeling Solutions (which emphasize on establishing both the process model and information model when modeling cases).

Case Management Modeling Solutions

Case management emerged as a process management solution for knowledge workers who require a high degree of flexibility in controlling their knowledge work processes. It overcomes the limitations of traditional BPM solutions which restrict their usages in governing and improving highly structured, highly repeated manufacturing processes. In order to gain benefits from using the case management approach, organizations have started to explore novel ideas and approaches that can provide case workers adequate supports for managing cases from both perspectives of process and information, in an adaptive way. Some vendors also proposed their commercial case management applications based on their own understanding of case management. In order to standardize case management modeling practice, the OMG requested a proposal for case management process modeling in 2010, and ten major companies and organizations were involved in the development process (BizAgi Limited, Cordys Nederland BV, etc.). The final response of this collaborative work was the case management modeling specification entitled "Case Management Model and Notation (CMMN)" [START_REF] Omg | Case Management Model and Notation[END_REF]]. Until now this specification is still under development and refinement, but people have reached an agreement to the core concepts, the modeling notations and the execution semantics [START_REF] Marin | Data Centric BPM and the Emerging Case Management Standard : A Short Survey Case Management[END_REF]. It has been progressively accepted by the business community. Before explaining the CMMN specification which we adopt for case modeling in this thesis, we will trace and review the efforts made for developing management approaches for knowledge work. Main concerns are the definition of case management related concepts (such as case, case folder) and the attempts of case management modeling, regarding both the information and processes involved.

In the literature, the modeling paradigms are basically categorized as activity-based (in which case related activities are modeled as the primary concern), information-based (in which the flow of information is constructed), and communication-based (in which the interactions of knowledge workers drive the case to progress and are modeled as the primary means) [START_REF] Wang | A Framework for Document-Driven Workflow Systems[END_REF]] [Man 2009a]. In addition to these three major case modeling approaches, we add one more hybrid modeling paradigm where activity and information are both described in the process model and information model of a case, respectively (i.e., both the process and information are treated as the key constructs for case modeling). Modeling attempts falling in the fourth category are further divided depending on if the process model is merged with the information model or not. [START_REF] Mayer | IDEF1 Information Modeling[END_REF]] defined a family of IDEF (Integrated computer-aided manufacturing DEFinition) approaches for the purpose of increasing manufacturing performance through the aide of computer technology. Within that series of techniques, IDEF1 (also known as the Information Modeling Method) was developed to describe all the information necessary for organizations to accomplish their financial objectives. Generally, an IDEF1 information model identifies the key information controlled by the organization, as well as issues caused by the lack of well managing the key information. The structure of the information is modeled in IDEF1 models, in which: a Real-World Object is defined to represent an object in reality; an Entity is used to describe a piece of information; an Attribute is defined to represent a property of an Entity; and a Relation concept is used to describe the associations between Entities. [START_REF] Manolescu | Micro-workflow: a workflow architecture supporting compositional object-oriented software development[END_REF] proposed a new workflow architecture named Micro-workflow. In their workflow management solution, they adopted the object-oriented paradigm so that the gap between workflow systems with different requirements is bridged. In addition, their Micro-workflow solution offers a reusable architecture with which users are able to configure a model to the new requirements.

Activity-based Modeling

[ [START_REF] Kaan | Modeling support for the Case Management paradigm and Expectations Management in process innovation[END_REF]] proposed a graphical modeling language for case management. Concepts are embedded into traditional BPM modeling paradigm, where the evaluation of case information has an influence on executing activities. The visualization of the modeling language is inspired by the Venn-diagram, a diagram showing the logical relations between different sets. [Strahonja 2007] suggested to model case procedures (criminal case procedures, for example) through UML state machines in the domain of legislation. It focuses on the dynamics of the legal system, and the limitations of automating the verification and validation of anomalies in legislation models have been discussed as well. [START_REF] Hull | Introducing the guard-stage-milestone approach for specifying business entity lifecycles[END_REF]] informally proposed a business operation modeling approach using business entities and the Guard-Stage-Milestone (GSM) approach. It is more declarative than most finite state machine variants in terms of expressing the lifecycles for data-centric business processes. The operational semantics are defined using the ECA rule, which leads the possibilities for formal verification and reasoning.

Due to the fact that case management is information-sensitive and information-driven, the modeling approaches which consider only case activities are not adequate for modeling case management processes. Even in [START_REF] Kaan | Modeling support for the Case Management paradigm and Expectations Management in process innovation[END_REF] activities are controlled by rules evaluating the case information, the flow of information is not explicitly given. Moreover, such diagrams can be difficult for knowledge workers to read if a large amount of rules is defined. Other approaches do not consider much about the strong linkage between processes and information involved when modeling cases, and the modeling approach given in [Strahonja 2007] is only for the legislation area. They are more suitable for routine work rather than knowledge work. In addition, as modeling approaches they do not have formal definitions in terms of syntax (both abstract and concrete) and semantics.

Information-based Modeling

IDEF3 is another approach from the IDEF family, which is entitled as Process Description Capture Method [START_REF] Mayer | IDEF1 Information Modeling[END_REF]. Unlike IDEF1 which focuses on the information flow, IDEF3 captures the knowledge of organizations from the behavior perspective: it was developed specifically for modeling descriptive activities. Within an IDEF3 model, activities are summarized in the Process Flow Description, and the lifecycles of objects are defined in the Object State Transition Description. [START_REF] Nigam | Business artifacts: An approach to operational specification[END_REF] proposed to use the concept of Business Artifact (also known as Business Record) to capture case data. A Business Artifact refers to an entity used to record concrete, identifiable, self-describing and indivisible business information. Their approach was inspired by IDEF0, one of the IDEF family approaches targeting on system function modeling. The lifecycle of a Business Artifact is defined through two constructs called tasks and repositories, where the former defines the place a function applies, and the latter offer means for archiving business information. This artifact-centric thinking in the business area renders a flexible representation of business models, and offers the ability to control changes and system implementation.

The modeling approaches we reviewed in this section focus solely on the information flow of the case model. The evaluation of information captured measures if knowledge workers are on their way to achieve their business targets. However, diagrams modeled by IDEF3 can be too complex for people to understand. Moreover, these information-based modeling languages lack formal definitions of their abstract syntaxes and formal descriptions of their execution semantics. [START_REF] Mayer | IDEF1 Information Modeling[END_REF] informally offered the concrete syntax of IDEF3; but in [START_REF] Nigam | Business artifacts: An approach to operational specification[END_REF] no noticeable graphical modeling notations are given. In addition, without the control flow of activities it is hard to know which information triggers which task, or which activity yields which information. Thus, the dynamic views of cases are missing: they are more like static analysis tools for knowledge workers. [START_REF] Kumaran | ADoc-oriented programming[END_REF]] formalized an XML-based programming language for constructing Adaptive Documents (ADoc) and Collaboration models, where ADoc and Collaborations are the new modeling artifacts proposed. This new modeling language adopts object-oriented technology, and it mainly focuses on describing the information flow, as well as the collaboration aspect of systems: a set of atomic models function together to achieve organizations business objectives. [START_REF] Ould | Business Process Management: a rigorous approach[END_REF][START_REF] Harrison-Broninski | Human Interactions: The Heart and Soul of Business Process Management: how People Really Work and how They Can be Helpful to Work Better[END_REF] proposed Role Activity Diagram (RAD), a process management technique mainly aimed at modeling human communication and collaboration. RAD was developed for enabling communication-based process modeling. It focuses on the "role" of human and how the "role" is defined within related activities. It is considered as the most known process modeling approach aiming at describing communications between people.

Communication-based Modeling

There exists a graphical representation for RAD models as well. [START_REF] Weigand | LAP: 10 years in retrospect[END_REF]] proposed a communication-based process management application named DEMO. It is one of the most prominent applications built on the basis of the Language-Action-Perspective principle, in which business goals are reached by human communications [START_REF] Kethers | Reassessment of the action workflow approach: empirical results[END_REF]. In DEMO, the basic modeling unit is a "speech act", a minimal action of human in terms of communication (e.g., request, accept). The graphical representation is defined, but human tasks involved are not considered in DEMO models. [START_REF] Swenson | Demo: Cognoscenti open source software for experimentation on adaptive case management approaches[END_REF] proposed Cognoscenti, a free open source experimental collaborative and adaptive platform for experiencing with case management. The main idea of this environment is to establish a Project Exchange Protocol for case management. This way, different systems (i.e., BPM systems and case management systems) are able to exchange information when they are integrated to work collaboratively. It offers a set of basic capabilities that case workers require for managing complex, unpredictable work such as tracking documents, exchanging notes, assigning roles.

Collaboration is another key feature of case management, and these approaches we mentioned in this section put their focuses on this important factor. However, as modeling approaches ADoc, RAD and DEMO only have informal graphical representations given in the literature; their abstract syntaxes and how their models execute in reality are not given. The Cognoscenti project is an experimental framework providing a means to work collaboratively, but it is not meant to establish models when dealing with cases. Moreover, these communication models do not link to the case information, or the activity control flow. Therefore, the control on data and tasks is not possible to specify in such models. [START_REF] Weigand | LAP: 10 years in retrospect[END_REF]] criticized that such communication-based models should be considered as a complementary view when modeling processes, instead of being the primary construct. In addition, the details given in ADoc, RAD and DEMO models are generally not precise enough for knowledge workers to have a deeper view of their work. When it comes with larger scale business problems, the readability of these models lowers due to a large amount of arrows and icons.

Hybrid Activity and Information Modeling

Due to the unique features of case management, it is intuitive to view data as the first-class object when modeling cases. However, in order to automate knowledge work processes the control flow of activities is as important as the information flow: on one hand, information drives certain tasks to execute by knowledge workers; on the other hand, tasks also yield information which should be evaluated by knowledge workers in order to make decisions. It makes sense to claim that information and activities function together to achieve business goals in case management. In recent years, many business vendors showed their interests in integrating an information flow into their business process products in order to support case management, such as [START_REF] Van Der Aalst | Case Handling: a new Paradigm for Business Process Support[END_REF], [START_REF] Wang | A Framework for Document-Driven Workflow Systems[END_REF], [START_REF] Bhattacharya | Artifact-centered operational modeling: Lessons from customer engagements[END_REF]], [Vanderfeesten et al. 2009], [Man 2009b], [START_REF] Künzle | PHILharmonicFlows: Towards a framework for object-aware process management[END_REF], [START_REF] Ajay | Managing Unpredictability using BPM for Adaptive Case Management[END_REF]], [Newgen 2013], [START_REF] Pega | Pega Dynamic Case Management[END_REF], and [START_REF] Zhu | Advanced Case Management with IBM Case Manager[END_REF]. A noticeable difference between their applications is that [START_REF] Wang | A Framework for Document-Driven Workflow Systems[END_REF]] and [START_REF] Künzle | PHILharmonicFlows: Towards a framework for object-aware process management[END_REF] merge the control flow of activities together with the information flow in case models, and other approaches have the opposite solution: they separate information models from process models.

[ [START_REF] Van Der Aalst | Case Handling: a new Paradigm for Business Process Support[END_REF] proposed a process management modeling approach called Case Handling. It is a new modeling paradigm for process management towards flexible and knowledge-intensive business processes. Both information and processes are considered as the first-class factors in Case Handling and they are constructed using one uniform modeling paradigm. Metamodels are given to specify the key constructs used in modeling, at different layers. The system dynamics is defined by finite state transition diagrams combined with the Event Condition Action (ECA) rules. [Vanderfeesten et al. 2009] compared the two Case Handling systems: FLOWer and Activity Manager, and discussed to which extent these systems support a product-based workflow design from the aspects of flexibility and adaptability. They argued that the workflow design should be based on products, rather than activities. In such a workflow, each case is viewed as the "product" being manufactured, and the data elements are considered as "parts" assembled into the case when executing tasks.

[ [START_REF] Wang | A Framework for Document-Driven Workflow Systems[END_REF] proposed the concept of Document-driven Workflow, in which the system has no explicit control flow established. In their workflow framework, the control flow and information flow are mixed in one diagram: processes are defined as a set of business documents, activities, and connectors, and it is the receipt of a document that triggers the execution of related processes. This results in a flexible modeling framework for dealing with ad-hoc tasks since users only need to specify what information a task will receive or produce. [START_REF] Bhattacharya | Artifact-centered operational modeling: Lessons from customer engagements[END_REF]] reviewed the Artifact-Centered Operational Modeling (ACOM) language, which is known as a language for modeling cases in an artifact-thinking manner. ACOM was targeted on the information artifacts flowing within the processes, and business operation models are constructed at different levels. It used the UML state machine technique to capture the behavior of business artifacts.

[Man 2009b] introduced their Cordys case management modeling product. New analysis techniques and different notations are adopted in this approach. The information model is constructed using case files with properties, and the behavior model is composed of activities and tasks (which is called activity cluster). The lifecycles of modeling elements are specified by using UML-based state machine with additional rules. It also offers the dynamic planning function so that knowledge workers can manage ad-hoc tasks at run-time.

[ [START_REF] Künzle | PHILharmonicFlows: Towards a framework for object-aware process management[END_REF] proposed PHILharmonicFlows, an object-aware process management framework in which processes and data are strongly merged together. They take both the object behavior and the object interactions into account. In addition, data is integrated with processes so that processes are executed in a data-driven manner. The lifecycle is given by finite state machine, and the processes are modeled at different levels of abstraction (i.e., Macro and Micro levels). [START_REF] Ajay | Managing Unpredictability using BPM for Adaptive Case Management[END_REF]] incorporated a case management add-on in their commercial Oracle BPM Suite. In addition to the control of structured business processes given in their original BPM product, this additional module offers a modeling capability for unpredictable workflows, especially on the flexibility perspective in aspects of case flows, user interfaces, work assignments, and enforcement of business policies. Information is organized in the content management system, and knowledge workers with specific roles can assess to the documents they need when necessary. Case activities and events models are also specified as the control flow in case models. The linkages between process models and the related information models are established as well. The capability of ad-hoc tasks management is enabled.

[Newgen 2013] proposed their commercial case management product for helping organizations control the costs and risks associated with unstructured business processes. The tool is built on a BPM platform, and it mainly focuses on three application areas: investigation, service request, and incident management. It offers knowledge workers capabilities of modeling case information and case tasks, reusing existing case templates, and monitoring executing activities. The lifecycle of a case is informally given by graphs. [START_REF] Pega | Pega Dynamic Case Management[END_REF]] offered Pega Dynamic Case Management, a commercial case management solution to automate knowledge work in order to improve the efficiency of systems in today's fast-changing business environment. It combines together all the people and documents required in one place, and information can be delivered automatically to a right person. It is built for multiple channels (e.g., laptops, tablets, and smartphones) so that people can work with the system from different places. It is considered as one of the most powerful case management tools from the perspective of design-time and runtime modeling supports it offers [START_REF] Clair | The Forrester Wave TM : Dynamic Case Management[END_REF]. [START_REF] Zhu | Advanced Case Management with IBM Case Manager[END_REF]] developed their commercial case management tool named IBM Case Manager. It is built on top of the GSM formalism, and the information model is defined as a content management repository. The actions placed on the files (e.g., create a document, modify a report) within that repository will trigger events, where events are evaluated under various conditions in order to execute tasks defined within stages.

Among all the products given in this section, [START_REF] Wang | A Framework for Document-Driven Workflow Systems[END_REF]] and [START_REF] Künzle | PHILharmonicFlows: Towards a framework for object-aware process management[END_REF]] mix the activities and information involved in one place. A possible drawback of this type of merge is that when it comes to complex business issues with a large amount of data-dependencies the process models will be too complicated to read. Other commercial case management products have a similar feature except the Cordys system mentioned in [START_REF] De Man | Case Management: Cordys Approach[END_REF]]: the business vendors come with their BPM solutions with added flexible and dynamic functionalities and they claim that they offer suitable systems for case management. Each of them provides a means to model case information and case process. However, the concepts and the logical relations between key modeling constructs they defined are unique in their solutions, a common understanding and agreement is missing. In addition, the run-time altering of plans is only noticeable in [START_REF] De Man | Case Management: Cordys Approach[END_REF]] and [START_REF] Pega | Pega Dynamic Case Management[END_REF]], which is another core requirement when developing case management systems. From the modeling perspective, none of them is established on the basis of CMMN which specifies formal modeling syntaxes and semantics for case management modeling. However, they do have contributions for the development of CMMN since CMMN was the result of the collaborative efforts made by many organizations together. The concepts and techniques proposed in [START_REF] Nigam | Business artifacts: An approach to operational specification[END_REF]], [Man 2009b], [START_REF] Zhu | Advanced Case Management with IBM Case Manager[END_REF]], etc., can be found in the CMMN final report. In addition, the capabilities of static/dynamic model analysis, model improvement, model discovery, and enactment for case models are not presented in any of the published case management related literatures.

Summary

An overview and comparison of the literature review regarding the case management modeling approaches and systems considering which requirements they meet for modeling cases is presented in Table 2-1 below.

Process Improvement Practice in Knowledge Work

The ultimate goal of a case management process approach is to help organizations achieve their financial goal through improving their knowledge work operational performance. In [START_REF] May | Lean Thinking for Knowledge Work[END_REF]] [Staats & Upton 2011] and [START_REF] Jones | Lean thinking and knowledge work[END_REF], authors discussed how lean process improvement principles can be adopted in knowledge work theoretically. [Staats et al. 2011] proved the applicability of using lean theory in managing knowledge work processes by providing real-life evidence at an Indian software services company. More specifically, [Staats et al. 2011] suggested the following six principles regarding applying lean in knowledge work, which are borrowed from the classic lean theory: (1) waste should be identified and eliminated;

(2) the work should be specified explicitly; (3) communications among workers should be established; (4) problems should be solved quickly and directly, with scientific methods; (5) managers and workers should realize that making their system lean is a long journey; and (6) a lean culture should be established through the whole organization. Similar suggestions were also given in [Staats et al. 2011] that are summarized from a real-world case study: problems should be identified in an early stage, and problems and solutions should be considered together.

Process discovery is the core application aspect in process mining [START_REF] Castellanos | Business Process Intelligence[END_REF]]. The primary objective of process discovery is to help business analysts extract, understand and improve their business processes from facts (i.e., real data recorded at run-time). It is a novel discipline proposed years ago. However, organizations have shown a great deal of interests in this topic due to its abilities of automatically constructing process models from raw data and helping analysts gain insight into process potential problems. Some work relating to process discovery has been done in the business domain, and major contributions have been made from the perspective of discovering, analyzing and enhancing business process models constructed by BPMN (Business Process Model and Notation, the de facto standard for modeling traditional structured business processes involved in routine work), in the process mining framework named ProM [START_REF] Verbeek | ProM: The Process Mining Toolkit[END_REF]]. [Aalst et al. 2007] proposed their process discovery algorithms in the business context, and explained the application of their algorithms on a basis of a real-life case study in the Dutch National Public Works Department, from different point of view (i.e., process, organizational, and case). [START_REF] Kalenkova | Discovering, analyzing and enhancing BPMN models using ProM[END_REF]] illustrated their tooling support in ProM with respect to BPMN process models discovery, analysis, and enhancement. The support of BPMN standard bridges the gap between formal process discovery model formalisms (e.g., petri net, process tree) and the standard business process modeling formalism (i.e., BPMN). The solution they adopted was to establish conversion mechanisms which allowed the transformation from various formal process discovery models to BPMN models. In [START_REF] Weerdt | Bidimensional process discovery for mining BPMN models[END_REF]], the "BPMN Miner" was presented as a ProM plug-in to allow a bi-dimensional discovery of business process models. It provided the ability to represent discovered BPMN models from both the control-flow point of view and the organizational point of view. This way, improvement can be made from analyzing BPMN models from two different perspectives. Based on this, [START_REF] Conforti | BPMN Miner: Automated discovery of BPMN process models with hierarchical structure[END_REF] proposed their approach to automatically discover business process models in a hierarchical manner. In such mined BPMN models, interrupting and non-interrupting boundary events and activity markers are considered.

However, by reviewing the literature we noticed that in terms of process improvement, all conclusions drawn above in [START_REF] May | Lean Thinking for Knowledge Work[END_REF]] [Staats & Upton 2011] [Staats et al. 2011] and [START_REF] Jones | Lean thinking and knowledge work[END_REF]] are all abstract principles and suggestions: concrete approaches are missing. In other process improvement approaches such as Six Sigma, TOC and BPR, no discussions have been made in the domain of case management since people now are focusing on the standardization of general concepts and modeling notations of case management. Obviously, efforts will be put on case management process improvement very soon. However, currently case management lacks concrete solutions with respect to process improvement. On the other hand, in terms of process discovery we noticed that the contributions that have been made relate merely to structured business process (where BPMN is the de facto modeling standard). No noticeable "process discovery" contribution has been given in terms of unstructured business process (where CMMN is the de facto modeling standard).

Conclusion

We have presented in this chapter a literature review of the state of the art regarding case management modeling approaches and systems, and process improvement practices in case management. The case management modeling solutions were discussed under four categories: activity-based, information-based, communication-based, and hybrid activity and information based. We further summarized to which extent these approaches and systems support knowledge workers modeling processes and information involved in a case.

We noticed that as modeling languages for case management, most of the approaches come with a graphical representation, but they lack a formal description for their abstract syntax and operational semantics. It is reasonable to consider both the process and information as the first-class citizens when modeling cases, due to case management features, and knowledge workers should be able to cooperate with each other, in a collaborative manner. However, most of the proposed modeling languages focus on only one aspect.

We further observed that as commercial case management systems, most of them offer a case modeling language with syntaxes (both abstract and concrete) and operational semantics defined. Moreover, they all consider that the information model is as crucial as the process model, even though the information-flow and the control flow are mixed together in [START_REF] Wang | A Framework for Document-Driven Workflow Systems[END_REF]] and [START_REF] Künzle | PHILharmonicFlows: Towards a framework for object-aware process management[END_REF], and in other systems they have an explicit separation. However, the feature of collaboration is hardly noticeable in most of them, except in [START_REF] Swenson | Demo: Cognoscenti open source software for experimentation on adaptive case management approaches[END_REF]]. In addition, the empowerment of knowledge workers and run-time planning is another key requirement for case management supports, and can be found in only a few publications. None of the approaches were developed on the basis of CMMN. In terms of process simulation, process improvement and process discovery, not a lot of noticeable contributions can be found in the literature. Obviously, it is beneficial for knowledge workers and organizations with intensive knowledge work to have supports in all the aspects we mentioned above when conducting case management. This is what we try to provide in this thesis.

In the next chapter, we will present in detail the theoretical and technological background of our proposal. More specifically, we will explain the concepts and techniques we adopted in developing our case management solutions, including CMMN, Elements of System Modeling language, the System Theory, HiLLS, Process Discovery, Process Improvement Approaches, Model transformation and supporting languages.

Introduction

In this chapter, we introduce the concepts and techniques we adopted in developing our case management framework. Essentially, the contributions of this thesis involve the management, analysis and improvement of case management processes, which relate to the transformation between different system modeling languages, as well as the usage of process management techniques in case management. This chapter presents all the concerning system modeling formalisms and process management techniques. In detail, we start with introducing the elements of modeling languages, followed by relevant system modeling formalism (CMMN in section 3.3, HiLLS in section 3.4 and process tree in section 3.6.1). Sections 3.5 and 3.6 present the process management techniques that are considered as the basis for managing and improving processes. Section 3.7 presents the technique used to manipulate the translations between different modeling languages, i.e., model transformation.

Definition of A Modeling Language

A modeling language helps people build models of systems under study. Basically, a model is a representation of the reality with certain relevant aspects [Seidewitz 2003]. The key reason of modeling systems is that, it is easier and less expensive to analyze the system of interest at the model layer (due to the fact that in reality it is usually too expensive, impractical, or even impossible to study the system of interest) [START_REF] Maria | Introduction to modeling and simulation[END_REF]]. As given in Figure 3-1, a formal specification of a modeling language consists of an abstract syntax, one or a set of concrete syntaxes and semantic domains, the mappings between the abstract syntax and the concrete one(s) (each of which is denoted as M AC ), as well as the mappings between the abstract syntax and the semantic domain(s) (each of which is denoted as M AS ) [START_REF] Kleppe | Software language engineering: creating domain-specific languages using metamodels[END_REF]]. Generally, most languages specify only one concrete syntax and one semantic domain, as well as the mappings M AC and M AS . However, it is possible to have multiple definitions of them, each of which targets on one specific purpose. A general language specification can be expressed as a tuple, , such that:

x A refers to the abstract syntax.

x C refers to the concrete syntax.

x M AC refers to the syntactic mapping from A to C.

x S refers to the semantic domain of the language.

x M AS refers to the semantic mapping from A to S. The abstract syntax of a language refers to a set of rules specifying the well-formed expressions of the abstract modeling constructs. It consists of the definition of modeling elements and the relations between them [START_REF] Selic | The theory and practice of modeling language design for model-based software engineering-a personal perspective[END_REF]]. In MDE, an abstract syntax of a modeling language is often specified by a metamodel: a model of a modeling language that defines the essential properties and features of modeling elements [START_REF] Mellor | MDA distilled: principles of model-driven architecture[END_REF]] [Clark et al. 2008]. Basically, a metamodel and an abstract syntax of a language have the same interpretation in MDE. A model is a representation of the system under study, and it always conforms to its metamodel.

Unlike the abstract syntax, the concrete syntax of a language specifies the notations used to describe the entities and their relations defined in the abstract syntax. It is used to offer human-readable presentations of models [START_REF] Selic | The theory and practice of modeling language design for model-based software engineering-a personal perspective[END_REF]]. The presentation of modeling elements can be textual, graphical, or a mixture of both.

Regardless of the type of model presentation, the information rendered by the model does not change [Seidewitz 2003].

A syntax mapping, denoted as M AC in Figure 3-1, assigns the concrete presentation of a modeling element with its definition defined in the abstract syntax. It bridges the abstract syntax with its concrete notations together, in an unambiguous manner. Therefore, when people see a symbol, for example, they will know what this symbol represents thanks to the syntax mapping. If a language has a group of concrete syntax defined for various purposes, a group of syntax mappings are required as well, each of which maps the abstract syntax to a concrete one.

The meaning of each modeling element is given by the semantics of the language. In particular, the operational semantics of a modeling language specifies the way the execution of models expressed in that language is carried on [START_REF] Slonneger | Formal syntax and semantics of programming languages[END_REF]. It formalizes how the behavior traces will be generated by the model, at execution time. Moreover, the meaning should originate from a well-defined and well-understood area [START_REF] Harel | Meaningful modeling: What's the semantics of "semantics[END_REF]. This is called a semantic domain. A semantic domain offers the context under which a model is interpreted. The semantic mapping, as denoted by M AS , specifies the relations between the modeling concepts defined in the abstract syntax and the semantic domain. Therefore, each notation of that language has an explicit meaning in a specific domain. For a multi-purpose system modeling language, as the one we adopted in this thesis, HiLLS, there are several semantic domains defined. Similar to the syntax mapping, each semantic domain requires a semantic mapping from the abstract syntax.

Case Management Model and Notation

In order to standardize case management process modeling practices, OMG released CMMN, a formal case management modeling specification in May 2014[START_REF] Omg | Case Management Model and Notation[END_REF]]. CMMN incorporates the latest case management research contributions proposed by business analysts and vendors. Typical ones include the business artifact concept [START_REF] Nigam | Business artifacts: An approach to operational specification[END_REF], the case handling paradigm [START_REF] Van Der Aalst | Case Handling: a new Paradigm for Business Process Support[END_REF], the GSM (Guard-Stage-Milestone) approach [START_REF] Hull | Introducing the guard-stage-milestone approach for specifying business entity lifecycles[END_REF], the finite state machine concept, etc.

In CMMN, the case file model is separated from the case plan model, where the former contains case information involved in resolving cases, and the latter depicts related activities to be done in order to achieve business goals. In addition, CMMN distinguishes the design-time modeling phase from the run-time modeling phase, where the latter is one key requirement in case management, as we have discussed. At the design-time modeling phase, an initial plan is established; while dynamic planning (e.g., adding ad-hoc tasks, modifying execution sequence of tasks) can be conducted at the run-time modeling phase. CMMN aims at providing case workers the ability to collaboratively manage and control their knowledge work in a flexible and adaptive manner. When modeling cases with CMMN, case workers are capable of constructing the main episode of the case on one hand. On the other hand, during execution with incoming information and gaining experience, they are able to alter the model to some extent [Grudzińska-Kuna 2013].

In the CMMN modeling standard, the abstract syntax (which defines a set of case management process modeling concepts and the relationships among them) is specified using metamodeling, and the concrete syntax (which defines the visible representations of the modeling elements) is defined by graphical notations. The finite state machine concept is used to define the operational semantics of CMMN modeling elements. The completed definition of CMMN is written in [START_REF] Omg | Case Management Model and Notation[END_REF]. In this section, we briefly introduce the key modeling concepts and their relations as defined in the abstract syntax, their graphical notations, as well as their lifecycles defined as the operational semantics.

Abstract Syntax

We present an overview of the core concepts defined in the CMMN abstract syntax in this section, as summarized in Figure 3-2. The object Case is a top-level concept, in which all other elements constituting that Case are defined. Essentially, a Case contains a caseFileModel and a casePlanModel. The caseFileModel of a Case collects and records all information involved in solving a Case problem, and it is defined by a CaseFile object. A CaseFile object serves as an information container that consists of CaseFileItems, each of which represents a piece of information of any nature. The data structure of information ranges from a simple XML to a complex folder hierarchy structure. Information captured in CaseFileItems is used as a context for case workers to make decisions, e.g., raising events, evaluating conditions.

The casePlanModel of a Case consists of elements used for both design-time planning and run-time planning. On one hand, it contains elements that represent the initial plan of the Case (i.e., these activities must be done during execution). On the other hand, it also consists of elements that support the further evolution of the initial plan, at execution time (i.e., these activities will or will not be done at run-time, according to case workers decisions). Essential elements for modeling the case plan are Stage, Task, Milestone, UserEventListener, and TimerEventListener.

x Stage: A Stage serves as a container grouping basic modeling elements. In particular, the outermost Stage defined within a Case model is considered as the casePlanModel of that Case. x Task: A Task represents a unitary piece of work. In addition, a Task can be further specified as a ProcessTask (which is used to invoke another process), a CaseTask (which is defined to trigger the creation of another Case), and the most common one, a HumanTask (which contains things to be done by case workers).

x Milestone: A Milestone represents a business goal to be achieved. Different from Tasks, no concrete work is associated with Milestones; but they can be used to evaluate the progress of a Case. x UserEventListener: A UserEventListener is defined to capture events that are raised by case workers. Such events are capable of impacting the proceeding of a Case directly. Therefore, case workers are able to directly interact with a Case through UserEventListeners. x TimerEventListener: A TimerEventListener is used to catch a certain predefined elapse of time.

The items used for constructing the initial plan of a Case are called PlanItems, each of which refers to one essential modeling element (which might be a Stage, a Task, a Milestone, a UserEventListener, or a TimerEventListener). The connections and dependencies between PlanItems are expressed by Sentries. Each Sentry is defined as a guarding condition to activate or terminate a PlanItem (the one defined to activate a PlanItem is called the entryCriteriaReference of that PlanItem, while the one defined to terminate a PlanItem is named as the exitCriteriaReference of that PlanItem).

On the contrary, the items used for the further evolution of the initial plan of a Case at executing time are called DiscretionaryItems. Instances of DiscretionaryItems are planned and executed according to the discretion of case workers, and they are defined within the PlanningTables of Stages. Different from PlanItems, each DiscretionaryItem can only refer to either a Stage or a Task. Similar to PlanItems, dependencies and linkages between DiscretionaryItems are also specified using Sentries.

Moreover, each essential modeling element is constrained by the property rules which are specified in PlanItemControl. Aspects of control include:

x An element will be manually or automatically activated once its entryCriteriaReferences are met. This is specified by the ManualActivationRule.

x Whether an element is obliged to be completed or not before the containing Stage becomes completed. This is captured by the RequiredRule.

x An element will be executed only once or many times. This is specified by the RepetitionRule.

Concrete Syntax

CMMN defines a set of notations used for depicting the essential modeling constructs. An overview of the concrete syntax of CMMN is summarized in Figure 3-3. As we can see from this summary table, regarding the case information model CMMN only offers a graphical notation (a "Document" shape) for CaseFileItems involved in a Case. The case behavior model is totally captured in the outermost Stage (which is referred as the casePlanModel of the Case), which is depicted by a rectangle shape with a small rectangle attached to the upper left indicating the name of the Case.

All the planning elements should be defined with the casePlanModel.

A Stage is depicted as a rectangle shape with angled corners. If that Stage is discretionary, i.e., there exists a DiscretionaryItem referring to this Stage, then that angled-corner rectangle shape is depicted by dashed lines, instead of solid one. A Task is depicted by a rectangle with rounded corners. Similarly, the notation for a discretionary Task is a rounded-corner rectangle shape with dashed lines. Only Stage and Task items can be referred by DiscretionaryItems. A simple half-rounded-end rectangle shape represents a Milestone. As to a TimerEventListener, it is depicted by a double-line circle inside which a "Clock" marker centers. If there is a "User" symbol marker centers inside the double-line circle, then it represents a UserEventListener. Dependencies between items are defined by Sentries. If a Sentry is specified as an entryCriteriaReference of an item, then it is depicted by a shallow "Diamond" shape. On the contrary, a Sentry is depicted by a solid "Diamond" shape if it is used as an exitCriteriaReference of an item. A dotted line is defined as the connector to establish the dependencies between certain elements.

In addition, a set of behavior decorators are defined to make the CMMN notations more expressive. The AutoComplete decorator is depicted by a small black square. If the autoComplete attribute of a Stage (it can be either the outermost Stage representing the casePlanModel of a Case, or simply just a Stage element) is set to "true," then that decorator is attached to the bottom of the Stage notation. The ManualActivation decorator is depicted by a small triangle. If the ManualActivationRule attribute of a Stage or a Task element evaluates to "true,", then this decorator is added to the bottom of the element notation. The Required decorator is depicted by an "Exclamation" symbol, and it is added to the bottom of the element notion if the RequiredRule attribute of that item (Stage, Task, or Milestone) is set to "true." The Repetition decorator is identical to the ASCII # shape, which is visible if the RepetitionRule of a Stage or a Task item is set to "true."

Operational Semantics

The operational semantics of CMMN is given by the lifecycles of the essential modeling constructs and a set of their behavior property rules, where the lifecycles are defined using finite state machines. In particular, the majority of the operational semantics consists of the lifecycles of CaseFileItem, CasePlanModel, Stage, Task, Milestone, TimerEventListener, and UserEventListener, as summarized in Figure 3-4 below. The state machine with label "1" illustrates the lifecycle of a CaseFileItem instance. Basically, a CaseFileItem has only two states: Available and Discarded. A CaseFileItem in available indicates that the information represented by the CaseFileItem is available for case workers to use. If the piece of information is deleted and is not available any more, the corresponding CaseFileItem is in the discarded status. Events raised by case workers can influence the state transitions of a CaseFileItem instance, including create, addChild, removeChild, addReference, removeReference, update, and replace.

The state machine labeled with number "2" defines the lifecycle of the outermost Stage instance used as the casePlanModel of a Case. In fact, it represents the possible transitions of a Case instance. Therefore, its lifecycle is different from other Stage instances. A Case can be in status of Active (which indicates that the Case instance is executing), Suspended (which indicates that the Case instance is temporarily suspended by case workers), Completed (which indicates that all the required work defined with the Case has been done), Terminated (which indicates that the Case instance is terminated by case workers), Failed (which indicates that there is an exception or software failure), and Closed (which indicates that no action is allowed in the Case instance). A Case transitions from one state to another when an event is raised by case workers.

A Stage and a Task share the same lifecycle, as the state machine with label "3." In addition to the states (except the closed status) owned by a Case, a Stage or a Task instance has additional states including Available (which indicates that the entryCriteriaReference of that item is "false"), Enabled (which indicates that the item is waiting for case workers to active or disable it), and Disabled (which indicates that this instance will not be executed unless it transitions back to the Enabled state). All the transitions a Stage or a Task instance can undergo all illustrated in the figure above.

The last state machine labeled with number "4" specifies the lifecycle of a Milestone instance, a TimerEventListener instance, or a UserEventListener instance. They can transition among states including Available, Suspended, Completed and Terminated, when triggered by events (including create, suspend, terminate, occur, and resume).

Example

In this sub-section, a simple CMMN case model example, which is constructed on the basis of the example illustrated in [START_REF] Omg | Case Management Model and Notation[END_REF], is given in Figure 345. The entire Case model is named Claims File Management, and it consists of the following elements:

x One CaseFileItem (which is named as Request; each of which defines the information required for processing a Case instance). Attached; each of which defines an achievable target that is used to evaluate the progress of the Case instance). x One UserEventListener (which is named as Cancellation; it is defined to catch an event raised by case workers). x One TimerEventListener (which is named as Deadline; this element is used to capture a predefined elapse of time). Each element introduced above has its own lifecycle defined as the operational semantics. The dotted line connectors between elements are used to specify their dependencies. The elements that are depicted by diamond shapes are Sentries, in which an entry criterion is depicted by a shallow diamond shape, and an exit criterion is depicted by a solid diamond shape. The Sentry associated with the Milestone Responsibilities Identified indicates that this Milestone cannot be completed until the Task Identify Responsibilities is completed. Likewise, the Task Identify Responsibilities cannot be in active state unless the CaseFileItem Request is available. The exit criterion bonding the TimerEventListener Deadline and the whole Case Claims File Management implies that once the deadline defined by Deadline is reached (in this example, the deadline is 5 hours after initialization), the whole Case will be terminated, as well as all its containing elements.

High-Level Language for System Specification

HiLLS (High Level Language for Systems Specification) is a system modeling language for constructing multi-analysis system models. It is developed on the basis of DDML (DEVS-Driven Modeling Language), a DEVS-based graphical modeling language for domain experts to facilitate their use of DEVS for the purpose of building system models [START_REF] Maiga | DDML: A Support for Communication in M&S[END_REF]] [Ighoroje et al. 2012]. HiLLS helps domain experts create models of Discrete-Event Systems (DESs) from various analysis perspectives, where different views of the systems are unified in one single HiLLS model. As a system modeling language, HiLLS can be formalized as , in which A is the abstract syntax, C is the concrete syntax, and M AC is the syntax mapping from A to C, as we have introduced above in section 3.2. However, a special feature of HiLLS is that instead of having one single semantic domain defined, HiLLS specifies a family of semantic domains and a set of corresponding semantic mappings , each of which maps A to S i (where

). This way, HiLLS enables its multiple analysis capabilities including simulation, formal analysis, and system enactment. As detailed in Figure 3-6, HiLLS has a unified abstract syntax for specifying DESs models logically, where concepts borrowed from DEVS and Object-Z are integrated. This way, HiLLS offers a system behavior description in addition to the structural and logical system description given by Object-Z. Moreover, a concrete syntax is defined for graphically representing HiLLS models, which makes it easy for domain experts to learn, share and discuss modeled systems thanks to its high expressive power. The visual representations of HiLLS are inspired by UML class diagram, system control oriented transition diagrams, and Z schemas. Furthermore, HiLLS defines its various semantics domains for different purposes: adopting DEVS as its simulation semantics for system simulation, using Formal Method (FM) as its logical semantics for formal analysis and verification of system properties, and making use of UML as its enactment semantics for system enactment [START_REF] Aliyu | A Framework for Discrete Event Systems Enactment[END_REF]] [Maiga et al. 2015[START_REF] Maiga | An integrated language for the specification, simulation, formal analysis and enactment of discrete event systems[END_REF]]. In this section, we give a brief introduction to HiLLS.

Abstract Syntax

The complete metamodel of HiLLS is formalized and given in [START_REF] Maiga | An integrated language for the specification, simulation, formal analysis and enactment of discrete event systems[END_REF]], and we show it here to illustrate how HiLLS merges and integrates concepts from different domains to provide the ability of analyzing systems from various views. In particular, we focus mainly on the system-theoretic concepts in this sub-section. As we can see in Figure 3-7, from the system theory point of view, the concept of HSystem is defined (classes with a green background). A HSystem instance refers to a HiLLS system describing a DES, and it interacts with others through its input and output ports which are named inputs and outputs, respectively. The behavior aspect of a HSystem is captured by a transition diagram specifying by Configurations and Transitions between them. A Configuration represents a finite or an infinite set of a system's states which can be grouped together and be defined by the same predicate. In addition, each Configuration has a sojournTime associated, which indicates the maximum elapsed time for the system to be in any state of the Configuration. A Configuration is said to be transient if its sojournTime equals to zero (

). If a Configuration is associated with an infinite sojournTime, then it is a passive one (

). Otherwise, a Configuration with a finite sojournTime is said to be finite ( ).

A HSystem has at least one Configuration defined. Regarding ConfigurationTransition, a HSystem may contain zero or many if needed. If a transition occurs due to the expiration of the source Configuration's sojournTime, then it is called an InternalTransition. If a transition is observed because of at least one input event is received before its sojournTime expires, then it is an ExternalTransition. However, if a HSystem receives at least one input event and its sojournTime expires at the same moment, then it is called a ConfluentTransition. Configurations and ConfigurationTransitions are defined together to specify the dynamic aspect of HSystems.

In addition, a HSystem may contain components, each of which is also a HSystem instance. This composition relation is enabled by HComponentReference. If a HSystem has components defined, then the exchange of information is defined through couplings. Three types of couplings are defined: InputCouplings (which is defined to let the HSystem's components receive external events), OutputCouplings (which is established to allow the HSystem's components to send out events), and InternalCouplings (which are created to enable the communications, i.e., the exchanges of events, between components of a HSystem).

From the perspective of logical reasoning, concepts (classes with a blank background) from Object-Z are preserved and reused, such as Predicate, Operation, StateSchema, Declaration, etc., which are adopted to specify Object-Z expressions and predicates used to define the static section of a HSystem.

In addition, basic object-oriented concepts (classes with a red background) are borrowed, such as HClass (which is the equivalence of Class in UML), HAttribute (which is the equivalence of Attribute in UML), HReference (which is the equivalence of Reference in UML), etc., as well as the relations between entities such as composition, inheritance, and so on. This enables the capability of enactment of systems under study.

Concrete Syntax

An overview of the HiLLS concrete syntax is given in Figure 3 A HClass instance is depicted by a UML class symbol: a rectangle box with three compartments. Similar to the UML class graphical notation, the name of the HClass instance is placed in the first compartment, and attributes and operations are specified in the second and third compartment, respectively. The attributes and operations are formalized using the state schema and axiomatic definition borrowed from Object-Z. The references between HClasses (inheritance, reference, composition, etc.) are denoted using the same graphical notations as in UML.

The HSystem inherits from HClass, and its graphical notation extends that of HClass. In addition to the three compartments (each of which is reserved for name, attributes and operations, respectively) like HClass, HSystem has a fourth one defining the system's behavior through Configurations and ConfigurationTransitions. Moreover, each of the input and output ports are depicted by a small triangle shape, which is contained by a rectangle representing the input and output interface, respectively. Input and output interfaces are attached to the HSystem.

A FiniteConfiguration is denoted by a rectangle shape with five compartments, each of which is reserved for its label (the name of the Configuration), properties (the predicates specifying the Configuration using Z schema), sojournTime, activities (the activities to perform), and sub-configurations, from top to bottom. Since a PassiveConfiguration has an infinite sojournTime, it does not require a compartment for representing its sojournTime. Therefore, a PassiveConfiguration is depicted by a four-compartment box (each of which is reserved for label, properties, activities, and sub-configurations) with a vertical stripe attached to the right side indicating its infinite lifespan. Different from these two types of configuration, the TransientConfiguration is depicted by a circle with three compartments, each of which is used for specifying label, properties and activities. Its round shape indicates its zero sojournTime.

The transitions between configurations are represented by lines with arrows. In particular, the InternalTransition is depicted by a solid line with an arrow pointing to the target configuration, and outputEvents and computations are labeled as well, if there exists any. On the contrary, an ExternalTransition is a dashed line with an arrow pointing to the target configuration, and triggers and computations can be specified, instead of outputEvents and computations. A ConfluentTransition is depicted by a dotted-dashed line with an arrow pointing to the target configuration, and triggers, outputEvents and computations are labeled if there exists any. In cases that if the transitions depends on a guarding condition, then the expression of that condition is specified in a diamond shape. Basically, this diamond shape receives flow, and depends on its evaluation result (true or false) different target configuration is chosen.

Semantics

As given in Figure 3-6 HiLLS maps its abstract syntax to various semantic domains for different purposes: DEVS for the purpose of system simulation, Z for the purpose of formal analysis and verification of system properties, and UML for system enactment. A complete definition of the various mappings is given in [START_REF] Maiga | An integrated language for the specification, simulation, formal analysis and enactment of discrete event systems[END_REF]], and we briefly introduce its semantic domain for system simulation, DEVS, as well as the system theory, in order to ease the understanding of the case study provided later in this these. Basically, in system theory a system is studied from the perspectives of system structure and system behavior. As shown in Figure 3456789, system structure refers to a system's states, state transitions, and the mappings between states and outputs; while system behavior refers to the relationship between a system's input and output trajectories [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF]].

Figure 3-9: Basic system concepts When specifying the structure of a system, the concept of decomposition defines how it can be broken down into several meaningful sub-systems, as indicated by the arrow downwards (with a label "decomposition" inside). On the contrary, composition specifies how components (each of which exists as a system) can be grouped together to constitute a larger and more complex system, as illustrated by the arrow upwards (with a label "composition" inside). Moreover, the closure under coupling property ensures that a larger system (which consists of many sub-systems) is also a system. DEVS is the abbreviation for Discrete-EVent System Specification. It is developed on the basis of system theory principles, and it offers a mathematical formalism for modeling and analyzing DESs [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF]. DEVS is originally known as Classic DEVS (CDEVS) which deals with sequential events, and later the Parallel DEVS (PDEVS) is proposed in [START_REF] Chow | Parallel DEVS: a parallel, hierarchical, modular, modeling formalism[END_REF] with the ability to cope with parallel events introduced (we refer to PDEVS if DEVS is mentioned in the rest of this thesis). Before diving into DEVS formalism, we introduce the basic concepts regarding system theory which DEVS relies on.

On the basis of system theory, DEVS defines both system structure and system behavior. A DEVS atomic model describes the structure and behavior of a single unit of a DES through inputs and outputs, a set of states, transitions between states, etc. A DEVS atomic model can be mathematically defined as , such that x is the input event set, where refers to the input port set x is the output event set, where refers to the output port set x is the state set x is the internal transition function x is the external transition function, where is the total state set refers to the time elapsed since last state transition

x
is the confluent transition function (which solves the collision problem when the system is about to send out events and at the same time it receives external events) x is the output function x ∞ is the time advance function A DEVS coupled model describes a complex model that consists of atomic/coupled DEVS models. The hierarchical structure of a DEVS coupled model is defined. Mathematically, a DEVS coupled model can be specified as , where

x and have the same definitions as in the atomic model, respectively x is the set of names of components that consists of x refers to a component model with a name ;

x is the set of external input couplings (each of which is a coupling from an input of the coupled model to an input of its components)

x is the set of external output couplings (each of which is a coupling from the output of a component to an output of the coupled model)

x is the set of internal couplings (each of which is a coupling from the output of a component to an input of another component)

In addition, simulation algorithms for DEVS models are defined so that any system formalized using DEVS can be simulated in a discrete time manner. Detailed simulation protocol is well defined and explained thoroughly in [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF]. A non-exhaustive list of tools which enable DEVS M&S is maintained and updated in [START_REF] Wainer | DEVS TOOLS[END_REF]]. We make use of SimStudio, a platform-independent DEVS-based modeling and simulation environment [START_REF] Traoré | SimStudio: a Next Generation Modeling and Simulation Framework[END_REF] [START_REF] Touraille | A model-driven software environment for modeling, simulation and analysis of complex systems[END_REF]. SimStudio aims at conducting the practices of modeling, simulation, analysis and collaboration in a single unitary platform. It relies on the MDE approach, and it consists of various modules for different purposes (e.g., a Modeling module for constructing models, a Simulation module for running simulation, an Automation module for converting models from different formalisms into a unified DEVS representation, etc.). It is implemented as an extensible architecture, and additional modules which bring new functionalities can be integrated as plug-ins.

A generic DEVS-based M&S framework defines both entities and relationships between entities required for conducting the M&S practices [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF]]. As given in Figure 3-10, the basic entities with a generic M&S framework include: source system, model, simulator, and experimental frame (EF). They are defined to help gain better understandings about M&S studies, and have a better communication and discussion between modeling and/or simulation experts.

Figure 3-10: The DEVS-based M&S framework [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF] The source system refers to the real or virtual system that users are interested in. It is the source for the observable data, which is stored by the behavior database (where data are gathered either from observing the real system or from conducting system simulation experiments). The model commonly refers to a set of instructions, rules, equations or constraints for generating output trajectories from input ones. Generally, a model is viewed as a virtual representation of the source system we are studying. Models help experts and analysts study and understand the structure and behavior of systems from various aspects. The simulator is capable of executing a model to generate its behavior in a dynamic manner. It basically can refer to any type of a computation system: a single processor, a processor network, etc.

Figure 3-11: General components of an experimental frame [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF] The EF defines the conditions under which a system is experimented with. It is viewed as a system that interacts with the system of interest: it generates data that fed into the system of interest, and it collects and analyzes the results observed. Due to different research interests and objectives, one EF can apply to many models, and vice versa since models are separated from their contexts. In most cases, an EF consists of the following components, as shown in Figure 3-11: a generator (which generates input segments and feeds input segments into the system), an acceptor (which monitors simulation experiments to ensure that specific experimental conditions are met), and a transducer (which observes and analyzes output segments generated from the system). However, it is not mandatory to define all the three components when specifying an EF: one may need only a transducer in his own case. In other cases, an acceptor and/or a generator might be necessary. Users have their freedom to define necessary components they need.

Example

We give a taste of the HiLLS formalism through two simple examples presented below, where the first one is an atomic HiLLS model, and the second one is a coupled one. Figure 3-13 gives another simple example which shows how HiLLS atomic models couple together to form a complex model, in which we omit other details for each atomic model (since we have introduced these above in the example of the HiLLS atomic model). In this example, the coupled HiLLS model is a HSystem named N with two unitary components: S and P, each of which is also a HSystem as well. We call S and P are the components of N, where the composition relation is specified in the same way as how the composition relation is defined in UML class diagram. Other entity relations can be used as well. As indicated in the metamodel, HSystems can interact with others through their ports, and couplings are established to enable such a kind of interaction. There are three types of couplings: InputCouplings (which are defined to let the system's components receive external events), OutputCouplings (which are established to allow the system's components to send out events), and InternalCouplings (which are created to enable the communications between components of the same system). In this example, the predicates specifying couplings are defined in the passive configuration of the HSystem N. More specifically, the predicate defines the InputCoupling, specifies the OutputCoupling, and and define the InternalCouplings.

One can informally see how HiLLS operational semantics can be obtained from DEVS. Regarding a DEVS atomic model, its state set is the set of all states of all HiLLS Configurations. The DEVS input and output sets are those of the HiLLS model. The DEVS external (respectively internal) transition function is derived from the set of all transitions obtained from the dotted (respectively solid) lines of the HiLLS system behavior diagram. The DEVS time advance function is obtained from the sojournTime of the HiLLS Configurations. The DEVS output function is derived from the schemas carried by the internal ConfigurationTransitions of the HiLLS behavior diagram. In term of a coupled DEVS model, the external input coupling, external output coupling, and internal coupling are adapted from HiLLS InputCouplings, OutputCouplings, and InternalCouplings, respectively. A formal semantic mapping between DEVS and HiLLS is given in [START_REF] Maiga | An integrated language for the specification, simulation, formal analysis and enactment of discrete event systems[END_REF]].

The DEVS model that can be derived from the HiLLS examples given in Figure 3 , and

, such that

x x x x x x

Process Enhancement Approaches

Under the continuous threat of competition, there is always a need for organizations to increase their business process operational performance in order to let them achieve their business goals more efficient, and stay competitive in business. Essentially, the reduction of cost, the elimination of waste, and the improvement of control (and information) flows result in more efficient processes, which eventually lead to achieve organizations' financial goals. Therefore, organizations should improve their products and services continually by means of enhancing their process performance in terms of efficiency, effectiveness, and flexibility [START_REF] Clauberg | BPM and Simulation[END_REF]. The large number of buzzwords like BPM (Business Process Management), BPI (Business Process Improvement), Process Analytics, Case Management, etc., shows the interest of organizations to monitor and analyze their business activities. Definitions of these process management approaches vary in publications, but in general all of them relate to one common ultimate goal: the improvement of process performance. We introduce the main process enhancement approaches in this section.

Process Analytics

Process analytics generally refers to a group of approaches and tools used to study information of events, in order to support the decision-making of business managers. Essentially, the results from process analytics offer an insight about the efficiency, effectiveness, and potential risks of processes to managers. From a performance point of view, process analytics helps managers react fast to events, and evaluate immediately the impact of decisions made. While from a compliance perspective, process analytics ensures that governing rules and regulations of processes are met [START_REF] Muehlen | Business Process Analytics[END_REF]].

To provide actionable information to decision makers, a set of process metrics (e.g., Key Performance Indicator (KPI)) should be defined and used. Such process metrics measure and evaluate how processes proceed towards business goals [START_REF] Peterson | The Big Book of Key Performance Indicators[END_REF]]. Usually, they often use rates and percentages to show the process-related information, instead of using mere raw data. In order to obtain insightful information from process metrics, they should meet certain criteria such as accurate, little-cost to obtain, easy to understand, and actionable (actionable process metrics establish unambiguous relationships between metrics values and decisions). In most cases, the general process metrics relate to the time-stamp: e.g., the change-over time (which refers to the difference between the selection of a work and the actual staring of that work, and in terms of knowledge work it often refers to the mental adjustment of workers when they switch from one task to another), the suspending time (which measures how long time a process suspends), and the gross processing time (which refers to the time spent from the instantiation of a process to its final completion) [START_REF] Muehlen | Business Process Analytics[END_REF]. The comparisons between the same time-related metric obtained from different process instances provide a basic view to the process model.

Basically, process analytics can be applied to study process information from three perspectives: understanding what has happened in the past (where the analysis focuses on the historical data collected from completed processes), monitoring what is going on at the moment (where process data recorded at the real time are studied), and forecasting what will happen in the future (where both the historical and the real time process data are used to predict the future behavior). To ease and visualize the process data, as summarized in the table below (Table 3-1), data visualization tools are usually adopted when analyzing process information.

In a nutshell, analyzing process information helps business managers gain insight into their processes, provides supports for their decision-makings, identifies hidden waste and bottlenecks, and yields potential opportunities for optimizing their processes. Currently, most of the BPM systems are implemented with a process analytics component to collect, analyze, and monitor process events data. Such applications focus on either examining completed business process information, (e.g., process controlling), or monitoring active business processes (e.g., business activity monitoring).

Process Improvement

In order to survive and thrive successfully in today's constant changing environment, organizations realize that it is inevitable for them to adjust themselves to meet new requirements. One major thing is to improve the process performance so that they can be competitive. Process improvement is a systematic process management approach to help organizations archive remarkable changes and enhance their operational performance [START_REF] Forster | The Idea behind Business Process Improvement: Toward a Business Process Improvement Pattern Framework[END_REF]]. Essentially, main reasons behind process improvement efforts include the needs for organizations to reduce cost, develop efficiency processes, and respond to regulations [START_REF] Radnor | Review of Business Process Improvement Methodologies in Public Services[END_REF]]. It covers tools and applications for improving process such as process analytics, process monitoring, etc. In general, all process-governing methodologies relate to continuously improvement, identification and elimination of waste or bottlenecks, and establishment of better process models. A basic scenario of process improvement is to establish an as-is model for the current process, analyze and explore potential beneficial changes, and construct a to-be model reflecting the changes, as given in Figure 3-14. Once organizations operational performance is improved, then they are able to produce products or provide services with high quality, low cost and on-time delivery (where Quality, Cost and Delivery (QCD) is regarded as the key for organizations to success), and their ultimate goal, making money, will follow. We explain the widely used process improvement approaches in the following, including Process Reengineering, Lean, and Theory of Constraints (TOC). [START_REF] Hindle | Guide To Management Ideas and Gurus[END_REF]] pointed out that process reengineering is an approach to rethink and redesign business processes to a radical extent. This approach results in a dramatic improvement in terms of cost, quality and service. In literature there are other organizational change approaches, but what makes process reengineering unique is that it focuses primarily on the business process [START_REF] Kettinger | Business process change: A study of methodologies, techniques, and tools[END_REF]]. Many companies reported that they had gained significant benefits from reengineering their processes [START_REF] Cafasso | Rethinking reengineering[END_REF]]. In manufacturing area process reengineering has been a successful approach. Some experts claimed that it is also an effective strategy for knowledge work [START_REF] Davenport | The new industrial engineering: Information technology and business process redesign[END_REF]. Consequently, process reengineering has arisen as a major solution for organizations to change and improve their processes.

Process Reengineering

A generic framework for process reengineering efforts contains six phases [START_REF] Mcdonald | Improving Business Processes[END_REF]]. As illustrated in Figure 3-15, it includes plan, analyze, re-design, acquire resources, implement, and continually improvement. Similar framework was also given in [START_REF] Goksoy | Business Process Reengineering: Strategic Tool for Managing Organizational Change an Application in a Multinational Company[END_REF] with some additional steps.

Plan

Select an existing process to improve, where the targeted process contains transparent or potential problems.

Analyze

Construct the as-is model of the selected process, and examine it for problems.

Re-design

Explore and determine the changes to make in the to-be model of the targeted model, test the ideas and consider potential implications.

Acquire resources

Obtain the resources needed to make the changes.

Implement

Put the process changes into practice.

Continually improve

Evaluate the effectiveness and efficiency of the to-be model, and make further changes in a continually manner.

Figure 3-15: The framework for process reengineering

During the last decades of years, similar buzzwords like process reengineering have been proposed, such as process restructuring, process redesign, etc. They all focus on making process changes in order to increase productivity, reduce cost, and improve product (or service) quality and customer satisfaction. The main difference among them is the degree of change: minor, medium, or radical [START_REF] Cao | A critique of BPR from a holistic perspective[END_REF]]. For instance, process reengineering often brings radical process changes, while the degree of changes in process redesign is medium. The "changes" made for processes is the key factor to the success of process improvement. Therefore, the frequency of change often indicates the frequency of improvement, which determines whether a company is competitive or not. However, one major challenge is that in most cases, it is difficult or impossible to know the outcome of changes before putting them into practice when redesigning the process model and testing new ideas, as is shown in the framework in Figure 3-15. Evidence has shown that the failure rate of process changing projects is as high as 70% [START_REF] Marjanovic | Supporting the "soft" side of business process reengineering[END_REF][START_REF] Cao | A critique of BPR from a holistic perspective[END_REF]. A failed process reengineering practice is a waste of resources (time, money, materials, etc.), which organizations are not willing to pay. However, the payback for a success process reengineering project is so enormous so that organizations strive for improving their processes through this approach.

Lean

Lean (also known as lean manufacturing) is a process management philosophy. It was mainly derived from the Toyota Production System (TPS) theory, and was named as lean since the 1990s [START_REF] Holweg | The genealogy of lean production[END_REF]]. Traditionally, lean is applied within manufacturing area, and it aims at identifying and eventually eliminating all sorts of waste in order to deliver products and services with high quality. It helps organizations make more money with less cost. To this end, several lean principles are established to help managers create a lean culture in their organizations. Major ones include waste elimination, Just-In-Time (JIT), and continuous improvement. As a process analysis and improvement approach, lean has been successfully implemented in numerous companies.

Waste Elimination

Essentially, lean reduces cost by adding value-added activities and eliminating all other non-value-added activities. Generally, the term "value" often refers to the benefits customers expect to gain from services or products. Therefore, it is the customers who define whether an activity (or a task) provides value to them or not. An activity is said to be a value-added activity (i.e., it adds value to customers) if it meets the following criteria [START_REF] Sayer | Lean For Dummies[END_REF]]:

1. The customers must be willing to pay for it. 2. The activity must transform the product or service in some way. 3. The activity must be done correctly the first time.

Consequently, an activity that does not meet the criteria listed above is called a non-value-added one. From the customer's perspective, non-value-added activities are considered as wasted efforts in terms of time, resource, and so on. Non-value-added activities are further categorized into three types: irregularities, overdoing and waste (which are also known as mura, muri and muda in Japanese, respectively). Irregularity refers to the waste caused by the variation happened in quality, cost, and delivery. Understanding the nature of variation is one key point in Deming's System of Profound Knowledge, a quality analysis philosophy for products and services [START_REF] Deming | Out of the crisis[END_REF]]. A smooth workflow will be interrupted by irregularity. Overburdening refers to the unnecessary or unreasonable demands placed on employees or the equipment. Too many demands will exceed the capacity of employees or the equipment, and it often leads to other problems such as out of service of machines. Waste refers to an activity that consumes resources, but does not create any value for customers. Taiichi Ohno (the creator of the TPS theory) defined seven basic types of waste that organizations should eliminate, including transport, waiting, overproduction, defects, inventory, motion, and excess processing, as detailed in the following.

Transportation

The unnecessary movement of products or materials is waste since it requires spaces, causes inventory accumulation, etc. The fact is that no actual value is created or added to the final service or products during transportation. In knowledge work, it often refers to the needless movement of information, e.g., transferring information between different databases (and duplicated information recorded in different data repositories will cause the transportation of information).

Waiting

Waiting means idle time, and waiting in all forms is waste. It often refers to delays like waiting for instructions, approval, or work to arrive. For instance, a case worker waiting for information needed to start or finish his work is considered as waste. This may happen if a bottleneck exists in the upper stream of the workflow.

Overproduction

Producing more than customers required is waste since the excess products consume more raw materials, and require additional manpower before they are needed. Generally, managers try to fully utilize their machines and human resources, and this generally results in excess products. If case workers complete more work than required, the storage of the completed work will be so huge that the products or services may become obsolete since new information might be received.

Defects

A defect may refer to a reject, a design change or an item failing to meet specifications. Any item that is viewed as a defect is waste since it does not add any value to the product. Plus, it requires additional work (e.g., rework) to correct it, where such additional work is also considered as non-value-added activities. If the defect is discarded, then a great waste of resources and effort will be observed. Incorrect data or information commonly leads to defects in knowledge work.

Inventory

Stock of anything (including the final products, semi-final products, raw materials, etc.) anywhere is waste since it takes up space. In addition, it is under the risk of being damaged and obsolete. Moreover, excess items storing in the warehouse as inventory add no actual value to the production process. In knowledge work area, requests accumulated in the backlog can be considered as inventory.

Motion

Motion here refers to any movement of people that does not add value to the process. For instance, employees may move around to look for tools or information due to poor layout or design of the workplace. Another typical example is that case workers are trying to find the key information for them to proceed with.

Excess processing

Excess processing, or extra processing, refers to putting more work or effort into the product or service than necessary. This often happens if employees lack well understanding of the requirements. For example, analyzing and categorizing information when only raw data is needed, or reformatting data when data is formatted already.

Just-In-Time

Traditional manufacturing produces products based on forecast: organizations predict the amount of products customers will require, and start to work before they receive orders. This way, final products will stay as inventory until customers place their orders. This type of manufacturing strategy is known as a push system. Organizations operating as push systems ensure that they will have sufficient products to meet customers' demands. However, a large number of final products and Work-In-Processes (WIPs) will stay in the warehouse as inventories, which are considered as waste in lean. In addition, in most cases this kind of prediction is inaccurate since today's business environment varies from time to time rapidly.

On the contrary, the so called a JIT system (or a pull system) starts with customer orders. It is a manufacturing management philosophy aiming at producing the items demanded by customers just at the right time, with the required quality and quantity [AIDT 2006]. No products will be produced until an order is received from downstream. This way, no excess items (e.g., raw materials, WIPs, final products, etc.) are needed to be stored as inventory. Therefore, the level of inventory will be reduced, as well as the cost on storing and transporting them. Moreover, investment in working spaces will be lower, the lead time (which refers to the amount of time used from receiving an order to delivering to customers) will be shorter, and eventually the quality will be improved [START_REF] Javadian Kootanaee | Just-In-Time Manufacturing System: From Introduction to Implement[END_REF].

To produce at a rate that meets customer orders, JIT focuses on bringing the cycle time to the takt time as close as possible. The cycle time refers to the amount of time used from the start to the end of a process, while the takt time refers to the rate (pace) of customer demand. The ideal situation is to produce one product, then to deliver one, and no inventory exists. This is one of the goals JIT strives to achieve. In addition, kanban cards are used to indicate the need for materials, where a kanban card refers to a visual indicator or symbol that contains order information from downstream to upstream. Moreover, the continuous flow principle is adopted when establishing working procedures, where continuous flow refers to a system in which work units are moved through operations from step-to-step with no WIPs and delays in between. To this end, the workplace is often organized into a U-shape cell (work cells are arranged in a U shape). All necessary equipment will be rearranged in order to ensure the efficiency and effectiveness of employees.

Continuous Improvement

Continuous improvement, also known as Kaizen, refers to the efforts to improve products, services, or processes in a continuous manner. It is a constant improvement practice, and it involves everyone in the organization, from top managers to employees. Continuous improvement focuses on small and subtle improvement, and dramatic changes can be observed over time.

In reality, waste elimination is the core ground rule for continuous improvement. Moreover, the actual improvement practice often involves the adoption of different tools. A major one is the PDCA (Plan-Do-Check-Act) cycle, as is given in Figure 3-16: an iterative four-step management methodology used to maintain and improve system performance, which is very similar to the process reengineering framework showing in Figure 3 Plan refers to establish an effective solution to one or more problems within a process of interest, and determine the target for the improvement practice. Do refers to implement the plan established on a small scale, i.e., put the initiatives into practice experimentally. While Check refers to monitor the value of performance metrics and evaluate the result of the changes. If the expected enhancement of system performance is not shown, managers need to go back to the first step (i.e., Plan) to modify the original proposals. Once they obtain their expected results, they will performance the Act procedure: to standardize and perform all the changes. At this point, a performance-improved system is established. Managers will then target on other problems, and solve them by following more the PDCA cycles. Once the system performance is maintained at a certain level, carrying out another PDCA cycle will bring the system performance to a higher level, and the standard established from the previous round will stop the performance from moving down. Each PDCA cycle will solve one single small issue; and major jump in terms of performance will show over time, after several rounds of PDCA project.

Theory of Constraints

The Theory of Constraints (TOC) is a system management philosophy originally proposed by Eli Goldratt in his book "The Goal" [START_REF] Goldratt | The goal: a process of ongoing improvement[END_REF]. It aims at improving system performance by identifying and eliminating constraints (which are also called bottlenecks), where a constraint refers to the resource (a machine, or an employee) whose capacity is equal or less than the demand. On the contrary, a non-constraint refers to the resource whose capacity is greater than the demand. By now, TOC has been applied to various domains, such as aerospace, automotive, health care, and manufacturing. The companies involved are the world's most renowned ones, including Boeing, General Motors, Intel, and so on [ACCA 2011].

TOC is developed on the basis of the fact that any system can be seen as a chain, where its activities (or processes) are linked and connected together as a whole. The entire system's performance will be determined by its weakest link, i.e., the constraint. Therefore, in order to improve the system's performance organizations need to make the full usage of constraints. However, it is not the same case with regard to non-constraints: if non-constraint resources work at their full capacity, then they will produce extra items to downstream, if a constraint exists in the downstream who cannot consume what it receives from upstream. Additional WIPs and semi-final products will be observed (i.e., the inventory will increase). Moreover, running every machine at 100% can increase the operational expense for both machines and employees since machines lose lifetime hours and employees consume energy and will become exhausted very quickly. Therefore, due to such inter-dependencies and variations existed between activities (or processes) a system's optimum performance will not simply equal to the sum of all the local optima. To improve performance, the system should be considered as a whole instead of a group of isolated individual, and constraints should be well governed since they limit the actual performance of systems [START_REF] Goldratt | The goal: a process of ongoing improvement[END_REF]]. To this end, Eli Goldratt proposed the five focusing steps approach, which targets on identifying and optimizing constraints.

Identify the system's constraints.

Constraints are not always obvious. However, two measurements can be used here to help identify them: the amount of work items waiting in the queue, and the idle time employees from subsequent step spend in waiting for work items. In addition, managers should decide which constraint is the most important one once they have identified all possible candidates. 2. Decide how to exploit the system's constraints.

This step involves making the constraint resource to be used as much as possible (from the perspective of utilization), and to produce work items as many as possible (from the perspective of productivity).

Adjust everything else to the decisions made in Step 2.

At this step the constraint works at its maximum capacity. To pace with the constraint in an efficient manner, all other resources should adjust their working speed. The key principle is to let all resources work in a rhythm so that the work load of the constraint incoming work load reduces, and simultaneously all other employees do not have plant of waiting time. 4. Elevate the system's constraints.

If with the improved constraint the requirements still cannot be met, then the constraint should be elevated. It means that larger scale changes regarding the whole process are required through approaches such as process restructuring, resource reallocation, etc. Since the plan of changes may increase the inventory and operational expense, managers should analyze the changes well enough before putting them into practice.

If a new constraint is broken in Step 4, go back to Step 1, but do not let inertia become the system's new bottleneck.

Once the constraint is elevated, another constraint might appear to catch attention. Managers should strive for looking for and removing constraints by following these steps continuously.

Throughput Accounting

In contrast with traditional cost accounting method, Goldratt also proposed the Throughput Accounting (TA) methodology that is used to monitor, manage and analyze organizations operational performance. Traditional cost accounting method focuses on making profit through reducing and cutting cost. It views the profit-increased equals to the cost-saved, where the total cost is the summation of the cost of each component, and its goal is to lower each component's cost by maximizing the usage of each (i.e., the local optimum). However, TA is a management accounting methodology that takes the system's constraints into consideration, and it seeks to achieve balance all components in order to achieve the whole system's optimum. It emphasizes on improving the operational performance and maximizing profits by increasing throughput, while reducing investment and operating expenses simultaneously [START_REF] Goldratt | The goal: a process of ongoing improvement[END_REF]].

From the perspective of TOC, throughput refers to the rate at which the entire system generates money through sales. In most cases, it is used to refer to the added value through sales,

, where variable cost refers to the costs that change along with the volume of production such as direct materials, production supplies, and so on [Garrison et al. 2003]. To increase throughput, it is necessary to well manage the usage of constraints. This way, the amount of items delivered will be increased, and this will result in the increase of total sales supposed that the unit price stays. Investment often refers to the money tied up in the system. Basically, it includes the investment the organization has made (tools, capital equipment, furnishings, etc.), as well as the physical inventory (WIPs, finished products, etc.). In order to decrease investment, organizations should primarily reduce their inventory level. They could also seek to reduce the investment they have made for their business, but in most cases the reduction of things like tools or capital equipment will lead to other potential problems such as low productivity (due to the fact that employees have plenty of idle time in waiting as they do not have the tools they need). Operating expenses refer to the money organizations spend in turning investment into throughput. Expenditures such as salaries of employees, bills of supplies are all considered as operating expenses of organizations, and they should be reduced as well in order to make profits.

These three measurements mentioned in TA are adopted to support the decision making of business managers in the tactical management level. Compared with traditional cost accounting measurements, they provide more valuable and actionable information. Managers are able to identify where the problem hides within their systems. In addition, they also could know which aspect they should pay more attention to. In addition, on the basis of TA measures, financial performance measures (which are at the strategic management level) such as net profit and return on investment (ROI) can be directly obtained, where the former indicates the actual profit organizations have made (where ), and the latter evaluates the efficiency of an investment (where ). We could see that in order to increase net profit, throughput should be increased, and operating expenses should be decreased simultaneously. To make an investment to be more efficient, investment should be decreased as well. Moreover, the efficiency of employees can also be measured on the basis of TA using productivity,

, and the increase of throughput and the decrease of operating expenses will results in a high efficiency of employees [IMA 1999]. A summary of the performance metrics is given in the table below.

Simulation in Process Improvement

As we introduced above, regardless of which process improvement approach organizations adopt, the major factor is to construct a new model of the process (i.e., a to-be model) through redesigning the existing model (i.e., the as-is model) with incremental or even large scale changes proposed. However, managers are challenged with the question of whether or not putting the proposed changes into practice. The fact is that, it is difficult for organizations to make decisions if they do not have sufficient supporting data. Their hesitations arise from the uncertainty of obtaining a positive result [START_REF] Clauberg | BPM and Simulation[END_REF]. A common question for them to answer is: how can we be confident to claim that the to-be model with modifications will be better that the as-is one? Simulation of business processes is considered as a cost-effective means to predict the potential impacts of changes proposed. In addition, process simulation also helps examine and compare all proposed improvement alternatives without actually change the exiting processes. Moreover, through simulating processes potential bottlenecks can be discovered, and waste can be easily identified as well, in both the as-is and to-be situations. The simulation results can be considered as a quantitative data support when comparing potential process improvement scenarios. This way, managers can confidently choose an improvement proposal among others since they ensure that the to-be model will be better than the current one on the basis of the simulation results. Simulation offers business analysts a way to test and verify suggested process improvement changes [START_REF] Hlupic | Business Process Modelling Using Discrete Event Simulation : Potential Benefits and Obstacles for Wider Use[END_REF]].

To ensure the quality of process simulation results, the process models should be established correctly and accurately. Otherwise, inaccurate process models lead to inaccurate simulation results, which further offer unreliable and un-meaningful data supports to managers when making decisions. Many vendors have implemented a simulation module in their process management applications, such as [START_REF] Nissen | Toward Simulation Models of Knowledge-Intensive Work Processes[END_REF][START_REF] Hlupic | Business Process Modelling Using Discrete Event Simulation : Potential Benefits and Obstacles for Wider Use[END_REF][START_REF] Barnett | Modeling & Simulation in Business Process Management[END_REF]] [April et al. 2006[START_REF] Peinl | SimKnowledge -Analyzing impact of knowledge management measures on team organizations with multi agent-based simulation[END_REF][START_REF] Rust | Business Process Simulation by Management Consultants? Introduction of a new approach for business process modeling and simulation by management consultants[END_REF][START_REF] Clauberg | BPM and Simulation[END_REF]. However, for unstructured processes with case management little contribute is found in the literature.

Process Discovery

As we have mentioned, a process model specifies how the activities involved in that process will be performed at run-time, and it is generally a preferred starting point for further process monitoring and analytics. However, establishing process models manually is a difficult and sometimes even error-prone task for both business analysts and modeling experts. Especially when there are many activities involved and their dependencies are complicated and unobvious. Moreover, IT-based solutions are widely used in organizations in recent years, in order to govern and control their business processes [START_REF] Yan | A tool for mining discrete event simulation model[END_REF]. Relevant process information is recorded in their information systems (e.g., the Workflow Management Systems), instead of in paper files. Such information systems record historical business event data in the so called event logs. An event log basically records the process information in terms of the start and end time of each activity. In some situations additional process-relevant data may be recorded as well, such as the resources that are executing the activities, the cost of performing each activity, and so on.

The data collected in event logs constitute the basis for process discovery. Process discovery is a process approach that uses the event logs as its starting point and aims at exploring and constructing business process models by merely analyzing raw data stored in event logs [START_REF] Castellanos | Business Process Intelligence[END_REF]]. Process discovery extracts insight knowledge from them. Moreover, it helps construct process models on the basis of the historical data. In situations where organizations have their business processes without formal (or even informal) process models, process discovery is considered as a dominant approach since with this technique managers are able to explore and obtain process models on the basis of the historical records automatically, instead of constructing process models manually from scratch. Process discovery translates raw process data into process information with which organizations are able to gain deep insight into their business processes. In addition, organizations can acquire additional supports to decision-making if they adopt process discovery with other process management approaches (e.g., process analytics, process improvement).

Process discovery techniques ease the process modeling practices. Over the past years, researchers have developed many mature process discovery algorithms, each of which guarantees one or many quality characteristics of discovered process models (which are replay fitness, simplicity, generalization, and precision) [START_REF] Leemans | Discovering Block-Structured Process Models From Event Logs -A Constructive Approach[END_REF]. Major categories are deterministic mining algorithms (which produce well-defined and reproducible models), heuristic mining algorithms (which incorporate frequencies of events when constructing models), and genetic mining algorithms (which describe the evolution of processes). A detailed introduction regarding process discovery algorithms with the discussion about their advantages and disadvantages can be found in [START_REF] Leemans | Discovering Block-Structured Process Models From Event Logs -A Constructive Approach[END_REF]]. In addition, a bunch of commercial/non-commercial tools are developed as well, such as Disco, ProcessGold, and ProM. ProM is the most widely used one among others. It is a java implemented extensible (through plugins) framework that supports various process mining techniques [START_REF] Verbeek | ProM: The Process Mining Toolkit[END_REF]]. Many ProM plugins have been implemented for different purposes. Thanks to the various algorithms provided with those plugins, sound and robust process models can be established through studying the knowledge hidden in the process execution logs. In this thesis, we select to use the Inductive Miner process discovery plug-in due to the fact that algorithm implemented in the plug-in guarantees to generate sound (i.e., free of deadlocks) and fitting (i.e., all the traces recorded in given event logs can be replayed) process models [START_REF] Leemans | Discovering Block-Structured Process Models From Event Logs -A Constructive Approach[END_REF], where the models are constructed using the process tree formalism.

Process Tree

Process tree is a formal modeling formalism for describing models obtained from process discovery. It depicts block-structured processes using tree notations. A detailed introduction to the process tree formalism with respect to its syntaxes and semantics is given in [START_REF] Buijs | Flexible Evolutionary Algorithms for Mining Structured Process Models[END_REF]]. In this section, we give a taste of the process tree formalism through introducing its syntax and semantics summarized from [START_REF] Buijs | Flexible Evolutionary Algorithms for Mining Structured Process Models[END_REF]]. In addition, a simple process tree model example is given and explained later.

The metamodel of process tree describing its abstract syntax is given in Figure 3-17. Table 3-3: The semantics of process tree • Alternatively, it can be written as . • A sequence operator (SEQ) specifies that all its children will be executed sequentially from left to right at run-time (i.e., one child can be executed only if its previous one is completed). • • Alternatively, it can be written as . • An AND operator indicates that there is no specific order for executing its children. •

• Alternatively, it can be written as . • An OR operator specifies that at least one of its children will be executed at run-time. •

• Alternatively, it can be written as . • An XOR operator specifies that ONLY one of its children will be executed at run-time. •

• Alternatively, it can be written as . • A LOOP operator always has three children defined: a do part (a), a redo part (b), and an exit part (c). • A LOOP operator indicates that after the first execution of a task (the do part), a condition will be evaluated which decides whether the redo part will be executed (which will trigger the do part) or the exit part will be executed. • Alternatively, this model can be expressed as , such that

x : The AND operator indicates that there is no specific order for executing Task a and Task b.

x : The XOR operator specifies that either Task d or Task e will be executed.

x : The SEQ operator specifies that all its children will be executed sequentially from left to right at run-time (i.e., one child can be executed only if its previous one is completed).

Model Transformation

In MDE, models play a key role throughout the whole system development lifecycle. Models represent the systems of interest in an abstract manner: they capture the information regarding different system development steps, such as system design, implementation, analysis, optimization, etc. In addition, models depict systems from different perspectives for various purposes, at different levels of abstraction [START_REF] Biehl | Literature study on model transformations[END_REF]]. Models help organizations gain a better understanding of the systems of interest [START_REF] Hassan | SLMToolBox: enterprise service process modelling and simulation by coupling DEVS and services workflow[END_REF]].

In the context of MDE, model transformation is defined as the "automatic generation of a target model from a source model, according to a transformation description," [START_REF] Kleppe | MDA Explained: The Model Driven Architecture: Practice and Promise[END_REF]] in which the source and target models describe the same system. In some cases, the input of a model transformation can be more than one source model, and the output can be more than one target model as well. In other words, model transformation takes one or more source models as its input, and automatically generate one or more target models, according to the transformation rules specified [START_REF] Mens | A Taxonomy of Model Transformations[END_REF]]. Model transformation offers a mechanism for the reuse of system information captured. On the basis of this point, various practices in MDE (such as model creation, modification, refinement, and so on) can be done automatically. Generally, model transformation is applied to convert platform independent models (PIM) to platform specific models (PSM) in MDA, where PIM refers to models that are independent from the technical space in terms of implementation, and PSM are models that require specific technological tool or platform to implement.

As shown in Figure 3-19, the basic components for a model transformation are a source model, a target model, and a transformation engine used to executing a set of transformation rules. The source model refers to the model to be converted, while the target model refers to the model generated (as the output) through the transformation. Both the source and target models conform to their own metamodels, respectively (e.g., as given in Figure 3-19 the source model A conforms to its metamodel MMA, and the target model conforms to its metamodel MMB). Each transformation rule specifies how an element of the source model will be converted into an element of the target model. The transformation engine will interpret and then execute all the transformation rules. For each element in the source model, it generates the element of the target model by following the transformation rules. The well-defined languages used to implement transformation rules are called model transformation languages. Generally, a system can be described as diagram-based models (e.g., using UML classes), or text-based models (e.g., using Java, C++). With respect to the type of target models, a model transformation can be classified as Model-To-Model (M2M) or Model-To-Text (M2T). Diagram-based models can be obtained in M2M transformations, and text-based models such as system implementation codes can be generated in M2T transformations. Essential purposes of model transformation include the following aspects, and a non-exhaustive list of model transformation intents and their properties is completely summarized in [START_REF] Lúcio | Model transformation intents and their properties[END_REF]].

• Refinement, which aims at producing models with more precise details.

• Abstraction, which aims at generating simplified models with specific information. • Semantic Definition, which aims at specifying the semantics of languages.

• Language Translation, which translates one modeling language to another.

• Constraint Satisfaction, which outputs models satisfying certain conditions.

• Analysis, which implements various algorithms for analyzing different aspects of models. • Editing, which aims at manipulating models.

• Model Visualization, which aims at visually projecting the behavior or render the concrete representation of models. • Model Composition, which aims at merging isolated models into one.

To enable model transformations, different techniques have been developed over years. Essentially, transformation rules can be specified as declarative, imperative, and hybrid. We introduce these different approaches in this sub-section, and present some model transformation languages we adopted in this these. More information regarding model transformation paradigms and languages can be found in [START_REF] Huber | The Model Transformation Language Jungle -An Evaluation and Extension of Existing Approaches[END_REF][START_REF] Dehayni | Some model transformation approaches: a qualitative critical review[END_REF][START_REF] Ferhat | Review of Model-to-Model Transformation Approaches and Technologies[END_REF].

Declarative Approach

When defining transformation rules using the declarative approach, it is necessary to specify clearly the relationship between concepts in the source and target metamodels, respectively. In other words, declarative approach focuses on what should be converted into what. In this context, the transformation rules are often defined as mappings between elements from the source and target metamodels: each element defined in the source metamodel should be mapped onto a given element in the target metamodel. Examples of declarative model transformation languages include QVT (Query/View/Transformation) Core (a model transformation language that supports low-level model transformations, where QVT is the standard of model transformations defined by OMG), QVT Relational (a QVT Core based, high-level declarative model transformation language that supports bidirectional transformations), ModelMorf (a declarative M2M transformation language that designed as a response to the QVT standard), and so on. Generally, adopting the declarative approach makes the mappings straightforward, concise and easy to understand [START_REF] Biehl | Literature study on model transformations[END_REF]].

Graph transformation is considered as a sub-category of the declarative approach. It has a theoretical foundation, it is built on top of algebraic graph grammars, and it is often used in formal approaches and proofs [START_REF] Biehl | Literature study on model transformations[END_REF]]. The graph transformation treats models as graphs, so that the whole model transformation is a process of manipulating (e.g., matching, replacing, etc.) sub-graphs [START_REF] Dehayni | Some model transformation approaches: a qualitative critical review[END_REF]]. In graph transformation, the left-hand side (LHS) graph will be found first, and then it will be replaced by the right-hand side (RHS) graph, where the former and the latter are the sub-graphs of the source and target graphs, respectively. AToM 3 (A Tool for Multi-Formalism and Meta-Modeling) is a well-known application for designing visual system modeling languages. In AToM 3 , model transformation rules are expressed using graphs [START_REF] De Lara | Atom3: A tool for multi-formalism and meta-modelling[END_REF].

Imperative Approach

Instead of centering on what should be transformed during model transformation, the imperative approach emphasizes on the how perspective: it specifies an explicit control flow to manage how a source model will be converted. To this end, constructs used in general programming languages (e.g., Java, C++) are adopted in the imperative approach, such as the for loop statement, the if statement, etc. This provides a high level of control for users to explicitly specify how a target model will be generated step by step. Compared with the declarative approach, using the imperative approach will result in more complex but also more powerful transformation rules. QVT Operational (an imperative model transformation language that is built on the base of QVT Relational) is a typical example of model transformation languages that define transformation rules in an imperative manner [START_REF] Kurtev | State of the art of QVT: A model transformation language standard[END_REF]].

Hybrid Approach

As indicated by its name, the hybrid approach offers both the declarative and the imperative constructs for defining transformation rules. Users decide to choose the hybrid approach to specify transformation rules mostly because of the flexibility it offers: users are able to select different types of constructs when encountering different problems. Basically, an ATL transformation consists of a module (and maybe more modules if the problem is more complex), which is composed of a header section, and a set of helpers and transformation rules, as is given in Figure 3-20. The header section contains basic information for the transformation, such as the name of the transformation, the declaration of the source and the target models. A helper construct can be either an operation or an attribute helper, where the former navigates over the source model(s), and the latter decorates information of the source model(s). Transformation rules are the main building blocks in ATL, and they are classified into two categories: matched rules, and called rules. The former is specified in a declarative style, and the latter one is written in an imperative manner. In addition, the ATL tool is implemented as an Eclipse plug-in, which provides an execution model transformation framework consisting of an ATL compiler, an ATL virtual machine, a Model handler Abstraction Layer, Model handlers, and a Model Repository [START_REF] Jouault | Transforming models with ATL[END_REF].

Instead of enabling M2M transformations, Acceleo aims to the implementation of M2T transformations. Acceleo is a text file generation language that usually adopted to convert a model into corresponding executable codes. It is developed on the basis of the OMG "MOFM2T" Transformation standard [START_REF] Omg | MOF Model to Text Transformation Language TM (MOFM2T TM )[END_REF], and offers many advantages such as customization, interoperability, easy kick off, etc. In addition, it also provides both the declarative and imperative constructs. The language and its implementation (which is a plug-in integrated in the Eclipse IDE) are developed and maintained by a French company called Obeo.

Conclusion

In this chapter, we introduced the theories and techniques used in this these. In section 3.2 we explain the basic components of a system modeling language: an abstract syntax, one or more concrete syntaxes, one or more semantics domains, the syntax mappings between the abstract and concrete syntaxes, and the semantics mappings between the abstract syntax and semantics domains. Then we introduced CMMN, the standard modeling language for case management, including the abstract and concrete syntaxes, and its operational semantics. Then in section 3.4 we introduced HiLLS, a system modeling language developed for constructing multi-aspect system models. HiLLS maps its syntax into different semantics domains for various types of analysis: DEVS for simulation, formal methods for formal analysis, and UML for enactment.

Moreover, we explained the concepts and approaches regarding business process management, including process analytics, process improvement, process reengineering, lean, and TOC. Such concepts and approaches are widely adopted in business domain to help organizations govern and improve their process performance. We also reviewed how organizations used simulation as an approach to predict the potential impacts of proposed process changes, as well as examine and compare all proposed improvement alternatives without actually change the exiting processes. In addition, we also introduced process discovery in section 3.6, a process approach to explore and construct business process models by merely analyzing raw data stored in event logs, and the process tree modeling language, a modeling formalism used to depict models generated from process discovery.

Finally, in section 3.7 we presented model transformation, an essential approach in MDE to automatically generate target model(s) from source model(s) following a set of transformation rules. The different paradigms for model transformation are introduced as well. In particular, the model transformation languages ATL and Acceleo were presented with more details, where the former converts a model to several models, and the latter transforms a model to text (e.g., programming codes). We will use the concepts and techniques described in this chapter in subsequence chapters for the specification of our case management framework.

Introduction

We propose in this thesis a systematic case model management (CMM) solution that provides case workers sufficient supports to manage their cases, throughout their full life-cycles (i.e., from creating a case model to closing it), in an adaptive and flexible manner. To explain in detail, our approach contains two main modules, as given in Figure 4-1: Case Model Discovery (CMD) and Case Model Improvement (CMI). The CMD module relates to exploring case models by analyzing event logs, in which data from reality relating to special cases are recorded. CMI takes advantages of the discovered CMMN case models (which are called the as-is models obtained from CMD) as a starting point, analyzes their potential issues and operational performance from different perspectives, and offers case workers help in constructing and analyzing the improved CMMN case models (which are called the to-be models). In order to analyze the CMMN models and predict their operational performance, we envision transforming CMMN models into HiLLS models. It is the HiLLS models we analyze in both dynamic and static manners. Generally, the as-is model is the one we put our efforts on, and the to-be model is our target to obtain that has better performance and meets requirements. To this end, case workers can analyze the as-is case models in a dynamic manner (through simulation), or in a static manner (through formal analysis). We have also specified a set of performance metrics from different perspectives, in order to help case workers assess and measure the health and performance of both as-is and to-be case models. Case workers will re-construct their case models on the basis of analyzing results, and then analyze them again to check if the result is accepted or not. If not, the same steps will be followed again (steps 5, 3, and 4), until the expected result is shown. We call this repeated effort CMI, which consists of steps 3, 4 and 5. The whole story is illustrated in Figure 4-3 from another point of view. In this chapter, we will begin with explaining the CMI module part first, due to the fact that most of our contributions are done here: we establish an approach to help case workers analyze the as-is case models, assess their performance, explore their hidden problems and provide ideas for designing the to-be models, and predict the performance of the to-be case models. Case models can be finally improved and optimized on a quantitative basis. Then we will introduce the CMD module which we are inspired from the process discovery technique in the next chapter.

Case Model Transformation

As we have mentioned before, there is always a need for organizations to change their as-is process models in order to increase their business process operational performance, stay competitive and make more value in business. A typical challenge is that how to analyze and predict the outcomes of changes made within the to-be models in advance, in order to guarantee a success in a process improvement practice. Process simulation has been proved as an efficient solution to this challenge [START_REF] Barnett | Modeling & Simulation in Business Process Management[END_REF][START_REF] Hlupic | Business Process Modelling Using Discrete Event Simulation : Potential Benefits and Obstacles for Wider Use[END_REF]] [April et al. 2006]. By simulating the to-be models, potential impacts and ridden risks of modifications made can be explored. In addition, if many change plans exist, simulation can help compare all proposals and provide evidence to managers' decision making in terms of whether selecting or rejecting a change initiative [START_REF] Clauberg | BPM and Simulation[END_REF]. To this end, we select the HiLLS formalism to study CMMN case models, where HiLLS is a multi-purpose high level modeling language aiming at helping domain experts create DES models that can be studied from different perspectives, including simulation (DEVS), formal analysis (FM) and enactment (UML), respectively.

As illustrated in Figure 4-4 and Figure 4-5, to benefit from capabilities provided by HiLLS, we envision transforming CMMN models into HiLLS. A generic way to achieve this goal is to map the CMMN metamodel onto the HiLLS one. This way, any case model can be automatically converted into its HiLLS counterpart. In addition, we also propose a systematic way to generate an Experimental Frame (EF) for case models to conduct simulation experiments, where an EF defines the conditions under which a system is experimented with [START_REF] Zeigler | Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems[END_REF]. Consequently, case workers are able to observe their current as-is case model, identify and analyze problems, propose changes to make in the to-be model, and predict the performance of changes before implementation.

System Structure

As proposed in [START_REF] Wang | DEVS-based case management[END_REF], the main idea for the model transformation is to turn a CMMN model into a HiLLS model considering both the system structure and the system behavior. In terms of system structure, as given in Table 4-1 below, we consider to convert the RootStage item -the Stage instance that is defined as the casePlanModel of the Case -to a HSystem. For the rest of the major elements, including CaseFileItem, PlanItem, and DiscretionaryItem, they will be transformed to HClass instances (Both PlanItems and DiscretionaryItems may refer to elements including Stage, Task, Milestone and EventListener. The former are defined at the design phase, and the latter are added at the planning phase at run-time. Later in this thesis if we mention a Stage (Task), we mean a PlanItem referring to a Stage (Task); likewise, if we say a discretionary Stage (Task), we mean a DiscretionaryItem referring to a Stage (Task)). Consequently, we have one and only one HSystem generated for any Case model since a Case has one and only one casePlanModel defined, and many HClasses. In addition, the HSystem has input and output ports generated, as specified in the following. The EventIn input port receives tuples (element, event), where element refers to either the HSystem or a HClass, and event refers to actions that can modify the state of an element (event belongs to the eventSet, where eventSet = {close, complete, create, disable, enable, fault, manualStart, occur, reactivate, reenable, resume, start, suspend, and terminate}). The ParameterIn input port receives the input parameters of the CMMN case (which are defined as CaseFileItems by users). Regarding the output ports, the StatusOut output port sends out the current status of the elements defined within the Case model (including Active, Enabled, Disabled, Completed, Terminated, Failed, Suspended, and Closed), and the ParameterOut output port sends out the Case's output parameters (which are defined as CaseFileItems by users).

The containment relationship between all these CMMN elements will be preserved by the HiLLS composition relationship (which is borrowed from UML Class Diagram) among the HSystem and all HClasses. As specified in the rules below (we use source to refer to the CMMN element from which a HiLLS HClass is converted): a HSystem's components will be those HClasses such that, each of which has a source defining as a CaseFileItem, or a PlanItem (DiscretionaryItem) that is directly contained by the RootStage (which is the source of the generated HSystem).

A HClass has components too, if and only if its source is a PlanItem (DiscretionaryItem) that referring to a Stage. Its components are those HClasses such that, each of which has a source defining as a PlanItem (DiscretionaryItem) that is directly contained by that Stage.

Following the rules specified above, Figure 456gives an example of the system structure of a HiLLS model, which is converted from the Case model we used in Chapter 2 when introducing CMMN. As we can see, the HSystem ClaimsFileManagement (CFM) has two input ports created to receive events, and two output ports generated to send out events, respectively. Moreover, it contains 10 HClasses (which are Request (R), ResponsibilitiesIdentified (RI), CreateClaimsNotification (CCN), BaseInformationAttached (BIA), CreateClaims (CC), IdentifyResponsibilities (IR), ChangeResponsibilities (CR), RequestMissingInformation (RMI), Cancellation (C), and Deadline (D)), and each of which is converted from a CMMN basic element. The missing information of the compartment, System Behavior, will be specified in the next section.

System Behavior

The generation of the system behavior is a challenge in our CMMN to HiLLS model transformation since it is not simply a mapping between different elements. Due to this reason, we use mathematic formulas and tables together to specify how Configurations are generated, as well as how they transit from one to another.

Configuration

Due to the fact that each CMMN element can be in different states, as depicted in Table 4-2, each HiLLS configuration can be seen as a tuple

, where each is a state variable that represents the status (which is represented by state) of the i th basic HiLLS element (which is represented by item) converted from its equivalence defined within the Case modeled. For instance, indicates that the CreateClaims item now is in the Suspended status. To ease the writing of the configuration, we use numbers to represent the items states. Consequently, the HSystem's complete configuration set will be defined as following, and it can be obtained by the combinational set of all elements' state sets. For example, as given in the case model presented in Figure 2-1, each element's state set is defined as follows:

z z z z z
Therefore, its full configuration set can be obtained as As given in the HiLLS metamodel, a Configuration can be finite (where its ), or passive (where its ). Consequently, we established rules to further categorize each Configuration into either finite or passive:

If a Configuration meets all the following conditions, then it is a FiniteConfiguration; otherwise, if at least one condition is not met, then it is a PassiveConfiguration:

x there exists at least one state variable , such that the source of this item refers to a TimerEventListener, AND the source of this item is defined as the exit condition of the RootStage (i.e., the source of this item is one of the items that are defined as the sourceRef of the exit sentries of the RootStage), AND the state is 1

These rules above can be formalized as following: Moreover, in order to observe the status of each item whenever a Transition occurs within the HSystem, a TransientConfiguration (where its

) is added for each FiniteConfiguration and PassiveConfiguration, where each pair of the transient and finite/passive Configurations have the same predicates defined. Assuming that we have a PassiveConfiguration A, and it receives a trigger and transits to a FiniteConfiguration B. In order to observe the status of items, a TransientConfiguration C is added which copies B's predicates. This way, as shown by Figure 4567, configuration A will first transit to configuration C when it receives a trigger; then C will send out the output, and transit to the target Configuration, B. The formal rule of generating TransientConfigurations is specified in below.

Configuration Transition

If the HSystem (h) stays in a Configuration, and it receives a trigger before its life-cycle (ta, which is defined by the sojournTime attribute) is expired, then an external configuration transition (ECT) will be observed, as illustrated in Figure 45678. In this case, the system will first transit to a transient configuration (through an ECT) that corresponds to the target one; and then the system will output the status of items, and transit to the target (through an internal configuration transition (ICT)). Otherwise, an ICT will be observed: an output will be sent out, and the system will transit from a finite configuration to its target. In both situations, the target configuration to which the system will transit to is determined by the CMMN operational semantics given in [START_REF] Omg | Case Management Model and Notation[END_REF]]. We will fully specify how a configuration transits to its target in the following, where we use to refer to the configuration before transitions, and to refer to the one after transitions.

External Configuration Transition

Basically, an ECT will occur if the HSystem receives a trigger before the life-cycle of the configuration it is currently stays in is expired. According to different triggers, c' will have a different value. As we have explained in the beginning of this chapter before, the translations between a CMMN model and its targeted HiLLS model are not simply n-n mappings between their meta-models. Especially for the configurations and the transitions between them, the rules must take into account several conditions, e.g., each element's state, sentry state, etc. The rules of configuration transitions we have defined above serve as the pre-conditions when executing HiLLS model simulations.

Experimental Frame

Once a HiLLS case model is obtained, a simulation EF (which is also a HiLLS model) should be established so that case workers are able to run simulation experiments. An EF defines the environment with which a system interacts with, in simulation experiments. Basically, an EF is considered as a system that is coupled with the system of interest. Generally, case workers are domain experts; their work mainly relates to the construction and manipulation of case models using CMMN. They are not directly dealing with simulated models specified by HiLLS. As a result, it is often difficult and error-prone for them to establish an EF for the purpose of conducting simulation experiments of case models. Moreover, even though they can do this by themselves or receiving help from simulation experts, they are still facing another inconvenience: each time when they have a case model to simulate, or they want to change the simulation environment for a different purpose, they need to create a new EF, manually from scratch.

Due to this fact, we propose here a systematic way to generate EFs, in order to ease the process of simulating case models for case workers. In our approach, the EF contains two parts: one is to generate and feed data into the system of interest (we name this part EventGenerator), the other one collects and analyzes the results observed (we call this part Analyzer), as given in Figure 4-12. On one hand, an EF can be generated in a semi-automatic manner, as shown in Figure 4-13. On the other hand, such an EF is easy to configure so that different simulation environments can be built according to different requirements and research purposes, without having experience from the M&S domain.

Case → EventGenerator

To start with, the whole Case will be transformed to a HiLLS system named EventGenerator. This EventGenerator generates and feeds events to the HiLLS case model. The formal transformation rules are given below.

Port

This EventGenerator has only one port: an output port named EventOut, which sends events to the HiLLS case model.

HComponents

92 Each is a HSystem, which is converted from the item defined within the Case model and serves as an item event generator. Based on the original CMMN element before transformation, the obtained HSystem has different structure and behavior. We will explicitly define the transformation rules for each type of CMMN element.

RootStage → HSystem

Ports

The HSystem converted from the RootStage has two ports: one for receiving incoming events, and one for sending events to other HSystems.

HComponents

h is a HSystem, and it corresponds to a RootStage event If the autoComplete attribute of the RootStage is set to False, then it will contain 7 atomic HSystems, each of which represents a RootStage event (i.e., create, complete, suspend, terminate, fault, reactivate and close). On the contrary, if the autoComplete attribute of the RootStage is set to true, then this HSystem will have 6 atomic HSystems instead of seven, where the atomic HSystem representing the complete event is not considered. The detail of each atomic HSystem is given below.

Ports

concerning belongs to {complete, suspend, terminate, fault} and it receives either a creation or a reactivation event, then an ECT will be observed. On the other hand, if the event his HSystem concerning belongs to {create, reactivate} and it receives an event belonging to {complete, suspend, terminate, fault}, an ECT will also be observed.

Configurations

, such that Note: (s: source; t: target)

In terms of EOC, each atomic event HSystem's output port connects with the output port of the EventGenerator translated from the whole case (which we have introduced above). In terms of IC, depending on the Boolean value of the autoComplete attribute of the RootStage, the total number of atomic event HSystems will be different, so is the total number of the internal couplings.

Stage/Task → HSystem

Here we will explain how a Stage, or a Task element translates to a coupled HSystem which contains a set of atomic HSystems, each of which generates the Stage-or the Task-related events. Please note that

Ports

Like the HSystem which is converted from the RootStage, each HSystem transformed from a Stage/Task element has also two ports: one for receiving incoming events, and one for sending events to other HSystems.

HComponents

According to the different values of related attributes (i.e., item type (planItem or discretionaryItem), manualActivationRule, autoComplete and entrySentry), the contained atomic event HSsystems are various, as specified below:

h is an atomic HSystem, and it corresponds to an Item event (create, complete, suspend, etc.). The detailed specifications of each atomic HSystem are given below.

Ports

Each atomic event HSystem has two ports: one for receiving incoming events, and one for sending events to other HSystems.

The ta of the passive configuration equals to positive infinity, and the ta of the active configuration will be assigned by case workers later.

Transitions

Here we will detail all the possible configuration transitions of each Stage/Task event related atomic HSystem, considering different values of item attributes we have introduce above (where c refers to the source configuration, and c' refers to the target configuration).

Configurations

The configurations of the event generator HSystem converted from a Milestone/EventListener item define the couplings of the atomic event HSystems obtained.

, such that

• • • •

CaseFileItem → HSystem

Here we will explain how a CaseFileItem element translates to a coupled HSystem which contains a set of atomic HSystems, each of which generates the CaseFileItem--related events. Please note that

• Item refers to the CaseFileItem element will be removed, as well as the couplings relating to it.

• For each h where AND if , then this h will be removed, as well as the couplings relating to it. For each pair of couplings (removed) that coming from h' and going into h'', a new coupling will be generated (which is used to establish a connection between h' and h''), where

Example

We will use the CMMN example we introduced in section 3.3 to explain how the EventGenerator of this case model is created. From the HiLLS case model that is generated from the CMMN example, a set of HiLLS events will be generated. It includes events such as , ,

, and so on, which are generated through a union of the Cartesian product results, as given in the following:

z z z z
Based on their research purpose, case workers will then select a subset of events from the eventSet, and specify the missing values as given in Table 4-7. The value in the column of Triggers is the index number representing an event. The value in the column Duration is a uniform distributed random number, in which the two numbers in the bracket are the lower and upper bounds from left to right, respectively.

Following the rules defined above, each selected event will convert to a HSystem. Generally, there are three types of configuration transitions within different HSystems, as given in Figure 4-14, Figure 4-15, and Figure 4-16, respectively, where the configuration with a bold outline is the one the system stays at initialization time. Figure 4-14 shows the configuration transition of the HSystem converting from the event (CFM, create, -, -) to create the whole case, since this type of event occurs immediately once simulation starts, with no triggers required. The system stays in the transient configuration Active for zero time units, and then sends out the event to create the CFM case and transits to the passive configuration. If triggers are required, the system will stay in the passive configuration when simulation initiates. Once the trigger (event (CFM, create)) is received, as given in Figure 4-15, an external configuration transition will be observed: the system will transit to the active configuration and stay until the life-cycle is expired. Then, it sends out the event to the case model and transits back to the passive one. However, we have noticed that with our approach there is a potential limitation relating to the total number of events: if there are many modeling elements in a case model, the total number of events will rise in an exponential growth manner.

Moreover, we establish an Analyzer which is used to collect the output events and analyze the performance of the system of interest. The Analyzer is also a HiLLS HSystem. It has only one input port for receiving item status that is sending out from the case model, computes the value of performance metrics, and provides the results to case workers when simulation ends. It has only one configuration (passive): each time a trigger comes, it transits back to itself, during which the values of performance metrics are calculated. The specification of the Analyzer is given in the following, and gives its graphical representation. In the next section, we will further introduce what are these performance metrics, and how we link them to case models so that they can analyze and reveal the operational performance of cases under study, from different perspectives.

Performance Metrics

From the literature review in chapter 3 regarding process improvement, we select several performance metrics to help case workers monitor, analyze and evaluate the system's performance from different perspectives (lean and TOC), at different management levels (operational, tactical, and strategic). Such performance indicators will show a deeper view in both as-is and to-be cases. For example, waste and bottlenecks can be identified hidden in as-is models. Through re-designing as-is models and simulating to-be models, case workers can check if spotted waste and bottlenecks have been removed or not, and investigate if there is any new issue. In addition, an expected target of system performance should be established in advance, so that case workers can compare the simulation results with their target to see where the difference is. We will explain in detail how we link these metrics to case models in this section.

Lean-related Performance Metrics

Lean aims at identifying and eventually eliminating all kinds of waste within processes. The following indicators are defined to evaluate the system performance and reveal the hidden waste within the system, at the operational level. The goal is to anticipate if any waste exists, and assess the performance of the system to see if it is at an expectable level or not.

Cycle Time

The cycle time refers to the time elapsed from the beginning of a work process until it is completed [START_REF] Tapping | The New Lean Pocket Guide: Tools for the Elimination of Waste! MCS Media[END_REF]]. We use cycle time to represent how long time a Case or a single Task takes to complete from initialization. Case workers can observe the trend of the cycle time obtained from several simulation experiments, in order to determine if it has been reduced or increased through process changes. In CM, the cycle time of a Case or a Task can be calculated by the time stamp when the item is in the completed status, minus the time stamp when the item is in the active status. This indicator will be used to help predict how many employees are required for certain tasks.

Suspending Time

The suspending time refers to the amount of time the work is being suspended. Basically, we use it to indicate for how long time a Case or a single Task suspends, which is viewed as waste. The suspending time of a Case or a Task can be obtained by the time stamp when the item transits to the active status from suspended, minus the time stamp when the item becomes to be suspended.

Downtime

We use downtime to represent the amount of time machines are not being used or case workers are not working, due to technical problems. By observing the trend of downtime, we can see if the technical problems become more serious or less, or being solved totally. The value of the downtime of a Case or a Task can be calculated by the time stamp when the item transits to the active status from failed, minus the time stamp when the item becomes to be failed.

Idle Time

The idle time refers to the amount of time case workers spend in waiting work items or information coming from a previous step in the process. The idle time is a type of waste from the lean point of view. Moreover, a long idle time indicates that the previous step is a bottleneck candidate in the process [START_REF] Goldratt | The goal: a process of ongoing improvement[END_REF]]. The idle time will be observed only in the situation that a Task is repeatable, i.e., the repetitionRule of that Task is set to True. In this situation, if case workers just complete the n th instance of that Task, and waiting for receiving information so that they can continue to work on the n+1 th instance, then the idle time will be observed. The value of the idle time of a repeated Task can be calculated by the time stamp when the n+1 th instance transits to a non-null status from null, minus the time stamp when the n th instance becomes completed.

Work-In-Progress (WIP)

WIP is used to represent the amount of Task instances that have been initialized

but not yet completed. Knowing the WIPs helps organizations improve the flow of value through the whole system, since Tasks cannot add any value to customers unless they are completed. The WIPs of Tasks within a Case can be counted by the summation of Task instances that their status are active.

, where

Backlog

The backlog refers to the amount of Task instances staying in active and waiting for case workers to complete. The same as idle time, the backlog will be observed in the situation that a Task is repeatable. In this situation, if case workers just complete the n th instance of a Task, and waiting for receiving information so that they can continue to work on the n+1 th instance, then the n+1 th instance of that Task is a backlog. By identifying the backlog in the system, managers are able to see where they might get stuck within their processes. Moreover, a smaller backlog leads to a shorter idle time and a shorter total cycle time, and a huge backlog indicates that the succeeding step in the process is a bottleneck candidate. The backlog of repeated Tasks within a Case can be counted by the summation of Task instances that their status are active, and case workers assigning to this Task are waiting for additional information, not working on completing these Task instances.

, where

Employees Needed

This performance indicator specifies how many case workers are required to complete a Case or a Task instance. If unnecessary case workers are assigned to a Case or a Task, then this is a kind of waste. By comparing the simulation results with different amount of needed employees we can identify that how many case workers assigning to different Tasks will lead to the best performance. Moreover, according to different types of payment of case workers, such cost will also be considered as fixed cost (if case workers are paid by fixed salaries, regardless of how many hours they work actually), or variable cost (if case workers are paid according to their working hours), which are explained in the Total Cost indicator.

Total Cost

The indicator of total cost refers to all the costs incurred in producing produces or providing services. Generally, two main types of cost will be observed in business: fixed cost, and variable cost, where . The former is the type of cost that remains fixed, irrespective of changes on the level of products produced or services provided. Typical examples of fixed cost include salaries, insurance, rent, and so on. The latter one, variable cost, refers to the type of cost that changes in proportion to the level of products produced or services provided. For example, the cost of raw materials, billable staff wages (where employees are paid according to their working hours), production supplies such as machinery oil, etc., are all considered as variable costs in business domain.

TOC-related Performance Metrics

TOC is a system management principle aiming at improving system performance by identifying and eliminating bottlenecks. To this end, we use two performance indicators (which are idle time and backlog) to help case workers determine bottlenecks. As we have explained above, a long idle time indicates that the previous step is a bottleneck, and a huge backlog implies that the succeeding step in the process is a bottleneck candidate. In addition, in order to monitor, manage and analyze system performance from the TOC perspective, we propose to use the Throughput Accounting (TA) technique in managing processes in case management, at the tactic level. TA consists of three main concepts, as we have reviewed in section 3: throughput, investment, and operating expenses (OE). The main idea is to increase throughput, while reducing investment and OE simultaneously, in order to balance all components within process to achieve the whole system's optimum.

Throughput

Throughput is the rate at which the entire system generates money through sales. It often refers to the added value through sales, as the formula given in below, where sales refers to the money organizations made through selling products or providing services, and variable cost refers to the type of cost that changes in proportion to the level of products produced or services provided. For example, the cost of raw materials, billable staff wages (where employees are paid according to their working hours), production supplies such as machinery oil, etc., are all considered as variable costs in business domain.

Investment

Investment often refers to the money tied up in the system. Basically, it includes the investment the organization has made (tools, capital equipment, furnishings, etc.), and the physical inventory (e.g., WIPs, finished products). In essence, in order to decrease the level of investment organizations should focus on reducing their inventory level.

Operating Expenses

OE refers to the money organizations spend in turning investment into throughput. Expenditures such as salaries of employees, bills of supplies are all viewed as OE of organizations. In order to make profit, OE should be reduced as well.

In addition, since some performance indicators at the strategic level are linking with throughput, investment and OE, once a certain number of cases have been done managers are able to have a global view on how their business is going on, at a relative higher level. Such indicators include net profit (which indicates the actual profit organizations have made), return on investment (which evaluates the efficiency of investments), and productivity (which measures the efficiency of employees).

Conclusion

In this chapter, we have explained the CMI module we have proposed to help case workers better manage their cases and improve their efficiency and effectiveness. Case workers start with case models, which later will be transformed into HiLLS models in order to allow case workers conduct case model simulations. As we have explained in the beginning of this chapter before, the translations between a CMMN model and its targeted HiLLS model are not simply n-n mappings between their meta-models. Especially for the configurations and the transitions between them, the rules must take into account several conditions, e.g., each element's state, sentry state, etc. To this reason, we have adopted several manners to formally specify the CMMN to HiLLS model transformation rules. Regarding to the system structure, we have used tables in which the mappings between CMMN and HiLLS metamodels were defined. In terms of system behavior, which concerns configurations and their transitions, we have used mathematic formulas and tables together to specify how Configurations are generated, as well as how they transit from one to another. The rules of configuration transitions serve as the pre-conditions when executing HiLLS model simulations.

In addition, we have also proposed a semi-automatic mechanism to generate an EF for a case model, which concerns generating event models, event generator models, as well as an analyzer model. The translated case model, which conforms to HiLLS, will receive events generated from the EF, and will send outputs to the analyzer. This analyzer which will later compute the values of performance metrics we have defined from different point of view: Lean and TOC.

Case workers now start improving their daily work by analyzing a case model. If this model does not exist, it is necessary for them to create one, on the basis of stored information. To ease this model creation phase, we will propose another module in the next chapter, CMD, which aims at constructing case models directly from recorded information automatically, instead of manually. before in chapter 3, and the latter is given in [START_REF] Omg | Case Management Model and Notation[END_REF]]. Process Tree specifies three types of nodes: Task, Event, and Operator. Each node will convert to a corresponding CMMN element, as illustrated in tables below. Basically, each Process Tree Task element will convert to a CMMN PlanItem or a DiscretionaryItem referring to a Task (where a CMMN Task element represents an atomic unit of work). The isBlocking attribute of obtained CMMN Task elements is set to True (if the Process Tree element is a Manual Task), or False (if the Process Tree element is an Automatic Task). Based on the logical relationships between Tasks, the targeted CMMN elements will be either PlanItems or DiscretionaryItems, as specified in Table 5-2 below. Moreover, the equivalent of a Time Out Event of Process Tree is a PlanItem referring to a TimerEventListener element (where CMMN TimerEventListener elements is adopted to catch predefined elapses of time), and the counterpart of a Message Event of Process Tree is a CaseFileItem (which represents a piece of information necessary for proceeding a case). In addition, each Process Tree Edge element will be translated into a CMMN Sentry element. According to different type of nodes and/or operators an Edge connects, the detailed information of the generated sentries will be different as well, as specified in Table 5-2. Table 5-2 illustrates the translations from Operators of Process Tree to CMMN elements. As specified above, there are basically five Operators: SEQ, AND, OR, XOR, and LOOP.

Conclusion

In this chapter, continued with chapter 4 we have explained the CMD module. This CMD module aims at analyzing event logs and constructing case models on the basis of recorded process information. This module should serve as a case mode discovering tool for case workers: case workers start with feeding recorded process information into this module and will obtain a corresponding (as-is) case model; after that, thanks to the CMI module they could begin modifying the as-as case model and forecasting the performance of the to-be models and analyzing the real value of their model modifications.

Due to the fact that a gap exists between these process discovery modeling specifications and the de-facto modeling standard for CM (i.e., CMMN), we proposed in our CMD module the model transformation from Process Tree to CMMN. Essentially, the meta-model of Process Tree concern Nodes and Edges, where the former relate to different types of tasks and the latter refers to the logical relationships between Nodes. Consequently, we have defined the mappings from Nodes to CMMN PlanItems and from Edges to the connections between PlanItems, respectively. Moreover, in order to ensure that the model transformation could be executed effectively when dealing with a massive quantity of process information, we also defined an algorithm with mapped all the nodes and all the edges in a linear time complexity manner.

CASE STUDY

Introduction

In chapter 4 and chapter 5 we have explained our CMD and CMI module, respectively. Moreover, we have showed how the two modules can help case workers improve their work performance. In this chapter, we will use a case study to give a comprehensive understanding about the whole story, from analyzing recorded process information to a successful model improvement.

The case study adapted from [START_REF] Russo | Business Process Modeling and Efficiency Improvement through an Agent-Based Approach[END_REF]] and used in this section is to show how our CM solution help case works manage their daily work in terms of discovering case models, validating model transformations, and analyzing and improving case models in a quantitative and scientific manner. The transformations are implemented by ATL (for model-to-model transformations) and Acceleo (for model-to-text model transformation), and the HiLLS simulator is a java-implemented version.

Background

A bank deals with a certain amount of Manual Credit Transfer (MCT) operation in a monthly manner. The MCT operation is triggered by a request specifying the detailed information required, and it has the highest priority among other tasks.

Generally, two units are working together to complete the operation: a Payment unit, and an Accounting unit. The former deals with operations regarding transferring the payment and recording the operation in the payment information system; while the latter deals with checking the funds availability, confirming the operation and updating the corresponding account information in their accounting information system. Once a request is received (R), the basic tasks performed by the two units are listed below: Payment Unit: At this moment, employees are dealing with MCT cases, and recording their activity information in their data warehouse. In order to stay competitive, the managers are seeking possible ways to manage and eventually improve the operational performance of the MCT process. They want to understand how their process proceeds (e.g., the sequence of activities), and then investigate what the result will be if they implement a change initiative: merging the two units together to accomplish the operation, and reallocating the human resource in accordance. The challenge for them is to know if the change is worthy or not. The change will only be worthy if the benefits after change is larger than the cost which will spend on the change process. Otherwise, there is no sense to change their as-is process model.

Case Model Discovery

The first task for the case manager is to understand how MCT cases proceed. They can obtain a MCT model using the CMD approach, which merely requires activity-related data recorded in the event log. A segment of information is given in Table 6-1. Note that the value in the column Timestamp refers to the timestamp an activity ends. As given in Table 6-1, it is a segment of process date stored in an event log, where three kinds of basic process information are recorded: the process instance, the name of each activity, and the timestamp indicating the time point an activity ends. The process discovery tool we adopted here is ProM (version 6.6), a java implemented extensible (through plug-ins) framework that supports various process mining techniques [START_REF] Verbeek | ProM: The Process Mining Toolkit[END_REF]]. Many ProM plug-ins have been implemented for different purposes. Thanks to the various algorithms provided with such plug-ins, sound and robust process models can be established through studying the knowledge hidden in the process execution logs. In this example, we select to use the Inductive Miner process discovery plug-in with its algorithm, due to the fact that the Inductive Miner algorithm guarantees to generate sound (i.e., free of deadlocks) and fitting (i.e., all the traces recorded in given event logs can be replayed) process tree models [START_REF] Leemans | Discovering Block-Structured Process Models From Event Logs -A Constructive Approach[END_REF].

From Table 6-1 we can also see that this process have been executed for several times continually, and a set of activities have been executed as well. The resulting Process Tree model representing such an event log using the Inductive Miner algorithm is given in Figure 6-1, from where we can see that tasks A 1 , A 2 and A 3 should be executed in sequence (

), and task D (which is a verification task that is executed not often) will or will not be executed (

), where the black node represents a silence action ( ). Moreover, task B 1 is connected with using the AND operator, , where in the model the AND operator is graphically shown as a + symbol. This set of tasks will be executed with R, B 2 and , in a sequence (R, , B 2 , ). As a consequence, the complete process tree model given in Figure 6-1 can be expressed as .

Figure 6-1: The resulting process tree model

To transform this process tree model into a CMMN case model, we start from the Operators at the lowest level, as the transformation algorithm specified above. In this case, it is the SEQ operator with tasks A 1 , A 2 and A 3 :

. From the transformation rules we know that each A i (which belongs to ) will be converted into a PlanItem referring to a Task, and these Tasks are connected by sentries in a sequential way: A 2 connects with A 1 through an entry sentry, and A 3 links with A 2 through its entry sentry, as given in the upper part of Figure 6-2. Now we will be at level 0 to transform the root node (which is an SEQ operator) with its children. The node R (as well as the node B 2 ) will convert to a CMMN PlanItem referring to a Task. In addition, all obtained CMMN model segments from last steps will be linked together in a sequential manner, through certain added sentries: A 1 and B 1 have an entry sentry connecting to R, B 2 has an entry sentry connecting to M, and D has an entry sentry connecting to B 2 , respectively. Figure 6-4 gives the final complete case model obtained from Process Tree to CMMN model transformation.

Figure 6-4: The as-as CMMN case model At run time, this case model will be executed as follows: when the whole case model is initiated, then task R will be executed first. Once R is completed, then A1 and B1 will be triggered to be active, where A1, A2 and A3 will be executed in sequence. B2 will be activated only when M is completed, which indicates that A3 and B1 are both completed. Based on case workers decisions at run time, D will be executed if necessary once B2 is completed, or stay in the null status till the end. Consequently, we can see that all the tasks in both the original Process Tree model and the generated CMMN model will be executed in the same manner. Case workers are able to further analysis and improve their processes on the basis of case models specified using CMMN, a modeling formalism that is more friendly and easy-to-use for them. This is the as-is CMMN case model we start with. Next we will see how to forecast potential performance and predict hidden risks coming with the change initiative.

Generated HiLLS Model and Experimental Frame

According to the CMMN2HiLLS rules defined in chapter 4, the as-is MCT model's HiLLS counterpart is shown in Figure 6-5 in a tree-view HiLLS model editor. A detailed explanation of the obtained case model is illustrated in [START_REF] Wang | DEVS-based case management[END_REF], as given in Figure 6-6 and Figure 67, where the former presents the system structure and the latter presents the system behavior. As we can see, the whole Case transforms to a HiLLS HSystem, and each of the basic modeling elements within that Case transforms to a HClass. For each item event generator (i.e., R_EG, RS_EG, A1_EG, etc.), the structure and the behavior are defined by our IEF generation rules. In the figure below we give the RS_EG HSystem's coupling information graphically as an example. As we can see, there are some information missing: it left to the case worker to complete once the IEF is generated. As explained, not all the possible events are necessary for a simulation practice. Once all the complementary information is added, the final EF will be obtained. For example, based on the information stored in their event log, the time used to perform each task and the human resource allocation is listed in the figure below. The value in the column Time is a uniform distributed random number, where the two numbers in the bracket are the lower and upper bounds from left to right, respectively. , complete). There are two configurations, and the passive one with a wide border indicates that it is the original configuration that the system stays in at the beginning of the simulation. For other atomic HSystems defined, they behave in the same manner, with different assigning value to σ.

To-be Model

The managers' intention is to merge the two separate units together in order to save cost and improve efficiency and effectiveness. To this end, they remove repetitive tasks performed in both units, and rearrange the human resources. In addition, the case managers add one additional non-activity element in the case model, as given in the figure below: a TimerEventListener (T) defining a deadline for completing the case. The equivalent HiLLS model is given in Figure 6-15 in a tree-view HiLLS model editor. The related information for the to-be situation is updated in accordance with the to-be model, and listed in the table below. The final EF is similar with the one for the as-is model, except that the Event Generator has different atomic event generators compared with the as-is situation (due to the fact that in the to-be situation the number of elements concerned is different). To this reason, we will not repeat the same process here.

Results Analysis

There are 40 case requests in the simulation practice, and the goal is to anticipate if the change of units merging is worthy or not.

The results from the simulation presented here are interpreted mainly from two perspectives: Lean and TOC. From the former perspective managers can have a global view on how effective and efficient their operation proceeds, and identify if there exists any waste within their processes. Related performance metrics include lead-time (the amount of time a product takes to flow completely through the process), work-in-progress (WIP, the number of work items being started but not yet finished), backlog (the number of work items waiting between different work steps), idle-time (the non-productive time of employees), handoffs (the number of times the information/product passes from one employee to another), etc, as we have explained in section 4.4. From the TOC point of view, it is possible to identify if any bottleneck exists within their processes. The metrics are backlog and idle-time due to the fact that if a work step has a huge backlog, or the one downstream has a long idle-time, then this work step is a bottlenecks [START_REF] Goldratt | The goal: a process of ongoing improvement[END_REF].

Figure 6-16 shows the backlog in the as-is model simulation, from which we can identify that the work step having the most backlog is A1. However, from the idle-time point of view in Figure 6-17, A2 is also a bottleneck due to the fact that employees at step A3 have plenty of time for waiting. Consequently, A1 and A2 are the bottlenecks that slow other steps down. The idle time in the to-be model [START_REF] Goldratt | The goal: a process of ongoing improvement[END_REF]] pointed out that there will always exist at least one bottleneck within organizations, the key point is that whenever erases one bottleneck, make sure the rest of resources are well rearranged, and the performance improves. We can verify the effectiveness and efficiency of the changes from the perspective of lean. In the following we give some examples. x Lead-time: As shown in Figure 6-20, the Y-axis of the graph represents the time used for all MCT operations, and the X-axis represents the two situations: as-is and to-be. We can see that the lead-time in the to-be model is reduced due to the process restructuring and human resource re-allocation.

x WIP: The Y-axis in Figure 6-21 refers to the number of WIPs existing during simulation, and the X-axis represents the time. From the comparison we can see that the amount of WIPs in the to-be situation is reduced due to the changes made.

From the results and analysis above, this case study shows that:

1. both the lead-time and the WIPs are reduced; 2. potential bottlenecks are well erased; 3. the operational performance is improved.

Consequently, in this case the merger of two units is beneficial, and the manager could make a more reasonable decision based on the simulation results and analysis. Moreover, he could try other change initiatives and run the simulation for each idea, then choose the one the most valuable to the business.

Conclusion

After given the detailed model transformation rules in chapter 4 and chapter 5, in this chapter we have shown a simple case study relating to the manual credit transfer operation in a bank. We started with the introduction of the case study, and we also explained why the manager wanted to change their case model and how the manager could test his change initiatives. Thanks to our CMD module, based on the recorded event logs the manager could easily get a CMMN case model automatically, instead of constructing one manually which is error-prone and requires additional costs. Once the as-is CMMN model is generated, the manager could start to make modifications and forecast the performance of the new to-be model by using our CMI module. His idea was to merge two teams as one, and the simulation results proved that this change was worthy in terms of process performance from the perspectives of lean and TOC, respectively. In order to make the best decision, he could try other change initiatives and run the simulation for each idea, then choose the one the most valuable to the business.

Conclusion

In this these, we have explained in the beginning the background and context of the real problem to be solved: more and more case management processes emerge in today's business, but the research work in this area is not sufficient, especially in terms of case model discovery and case model improvement.

In order to make contribution to this challenge, in chapter 2 we have presented a literature review of the state of the art regarding case management modeling approaches and systems, as well as process improvement practices in case management. The case management modeling solutions were discussed under four categories: activity-based, information-based, communication-based, and hybrid activity and information based. We further summarized to which extent these approaches and systems support knowledge workers modeling processes and information involved in a case. We noticed that as modeling languages for case management, most of the approaches come with a graphical representation, but they lack a formal description for their abstract syntax and operational semantics. It is reasonable to consider both the process and information as the first-class citizens when modeling cases, due to case management features, and knowledge workers should be able to cooperate with each other, in a collaborative manner. However, most of the proposed modeling languages focus on only one aspect. We further observed that as commercial case management systems, most of them offer a case modeling language with syntaxes (both abstract and concrete) and operational semantics defined. None of the approaches were developed on the basis of CMMN. In terms of process simulation, process improvement and process discovery, not a lot of noticeable contributions can be found in the literature.

In chapter 3, we introduced the theories and techniques used in this these. We started by explaining the basic components of a system modeling language since the system modeling language was what we used for building our solutions. Then we introduced CMMN, the standard modeling language for case management, including the abstract and concrete syntaxes, and its operational semantics. We also introduced HiLLS, a system modeling language we have adopted for constructing multi-aspect system models. Moreover, we explained the concepts and approaches regarding business process management, including process analytics, process improvement, process reengineering, lean, and TOC. Such concepts and approaches are widely adopted in business domain to help organizations govern and improve their process performance. We also reviewed how organizations used simulation as an approach to predict the potential impacts of proposed process changes, as well as examine and compare all proposed improvement alternatives without actually change the exiting processes. In addition, we also introduced process discovery in section 0, a process approach to explore and construct business process models by merely analyzing raw data stored in event logs, and the process tree modeling language, a modeling formalism used to depict models generated from process discovery. We presented model transformation in the end of that chapter, an essential approach in MDE to automatically generate target model(s) from source model(s) following a set of transformation rules.

In chapter 4, the CMI module was explained. Essentially, case workers start with case models, which later will be transformed into HiLLS models in order to allow case workers conduct case model simulations. As we have explained in the beginning of this chapter before, the translations between a CMMN model and its targeted HiLLS model are not simply n-n mappings between their meta-models. Especially for the configurations and the transitions between them, the rules must take into account several conditions, e.g., each element's state, sentry state, etc. To this reason, we have adopted several manners to formally specify the CMMN to HiLLS model transformation rules. Regarding to the system structure, we have used tables in which the mappings between CMMN and HiLLS metamodels were defined. In terms of system behavior, which concerns configurations and their transitions, we have used mathematic formulas and tables together to specify how Configurations are generated, as well as how they transit from one to another. The rules of configuration transitions serve as the pre-conditions when executing HiLLS model simulations. In addition, we have also proposed a semi-automatic mechanism to generate an EF for a case model, which concerns generating event models, event generator models, as well as an analyzer model. This analyzer which will receive and compute the values of performance metrics we have defined from different point of view: Lean and TOC.

The CMD module was detailed in chapter 5. This CMD module aims at analyzing event logs and constructing case models on the basis of recorded process information. This module should serve as a case mode discovering tool for case workers: case workers start with feeding recorded process information into this module and will obtain a corresponding (as-is) case model; after that, thanks to the CMI module they could begin modifying the as-as case model and forecasting the performance of the to-be models and analyzing the real value of their model modifications. Due to the fact that a gap exists between these process discovery modeling specifications and the de-facto modeling standard for CM (i.e., CMMN), we proposed in our CMD module the model transformation from Process Tree to CMMN. Essentially, the meta-model of Process Tree concern Nodes and Edges, where the former relate to different types of tasks and the latter refers to the logical relationships between Nodes. Consequently, we have defined the mappings from Nodes to CMMN PlanItems and from Edges to the connections between PlanItems, respectively. Moreover, in order to ensure that the model transformation could be executed effectively when dealing with a massive quantity of process information, we also defined an algorithm with mapped all the nodes and all the edges in a linear time complexity manner.

In order to provide a prove to our approach, in chapter 6 we have selected a case study to show that how case workers can benefit from our two module in managing their daily case work. This case study might be a simple one in a certain sense since we could not find a real complex case study with real data: most of such cases (e.g., the projects in Michelin) are confidential, and even we claimed to erase all sensitive parts the managers were still not agreed that we could use their real cases.

Perspectives

Next step, due to the limit of the IEF generated, a more efficient way could be established in order to not generate all possible element events but only the ones case workers need at the first time. This will save some time in terms of establishing an experimental frame for a case model simulation. Besides, we will focus on how to conduct static analysis on case models using formal analysis. This part is not yet mature for this moment. We mainly focused on the dynamic analysis part by using M&S. Moreover, it will be interesting to explore how business intelligence can be used in CM when performing both static and dynamic model analysis together. Another point is, CM is mainly focused on unstructured processes, and BPM is for structured processes. It will be beneficial to use both CM and BPM together in today's business processes since both structured and unstructured processes are already being observed.

  Abstract .......................................................................................................................... I REFERENCE .............................................................................................................

  1: Benchmark of case management solutions ................................................. Table 3-1: Common data visualization tools ............................................................... Table 3-2: The summary of performance metrics ........................................................ Table 3-3: The semantics of process tree ..................................................................... Table 4-1: The mappings of system structure .............................................................. Table 4-2: States of CMMN modeling elements ......................................................... Table 4-3: Transformation rules of ECT -Part 1......................................................... Table 4-4: Transformation rules of ECT -Part 2......................................................... Table 4-5: Transformation rules of ECT -Part 3......................................................... Table 4-6: Transformation rules of ECT -Part 4......................................................... Table 4-7: The complete information of selected events ........................................... Table 5-1: The mappings between Process Tree and CMMN -1 .............................. Table 5-2: The mappings between Process Tree and CMMN -2 .............................. Table 6-1: The historical event data ........................................................................... Table 6-2: Information for the to-be model ...............................................................

Figure 1 - 1 :

 11 Figure 1-1: The spectrum of business processes [Kemsley 2011] ................................. Figure 3-1: The definition of a modeling language specification ................................ Figure 3-2: The core of the CMMN metamodel .......................................................... Figure 3-3: An overview of the CMMN concrete syntax ............................................ Figure 3-4: An overview of the lifecycles of CMMN essential modeling elements ... Figure 3-5: A CMMN case model ................................................................................ Figure 3-6: An overview of HiLLS .............................................................................. Figure 3-7: The HiLLS metamodel .............................................................................. Figure 3-8: An overview of the HiLLS concrete syntax [Maiga 2015] ....................... Figure 3-9: Basic system concepts ............................................................................... Figure 3-10: The DEVS-based M&S framework [Zeigler et al. 2000] ....................... Figure 3-11: General components of an experimental frame [Zeigler et al. 2000] ..... Figure 3-12: An atomic HiLLS model ......................................................................... Figure 3-13: A coupled HiLLS model ......................................................................... Figure 3-14: A general scenario for process improvement .......................................... Figure 3-15: The framework for process reengineering .............................................. Figure 3-16: The PDCA cycle ...................................................................................... Figure 3-17: The metamodel of process tree ............................................................... Figure 3-18: A simple process tree model .................................................................... Figure 3-19: Basic components of a model transformation ......................................... Figure 3-20: A fragment of ATL transformation rules ................................................. Figure 4-1: A global view of our CMM approach ....................................................... Figure 4-2: The flow chart of our CMM approach ...................................................... Figure 4-3: The whole picture of the CMM approach ................................................. Figure 4-4: The workflow of CMI ............................................................................... Figure 4-5: The whole picture of CMI ......................................................................... Figure 4-6: The system structure of a HiLLS model ................................................... Figure 4-7: An example of configuration transitions ................................................... Figure 4-8: Different types of configuration transitions .............................................. Figure 4-9: Examples of t2f and t2p configuration transitions .................................... Figure 4-10: An example of f2p configuration transitions ........................................... Figure 4-11: An example of ECT ................................................................................. Figure 4-12: The couplings between different HiLLS models .................................... Figure 4-13: The flow chart of generating EFs ............................................................ Figure 4-14: The configuration transition of event (CFM, create, -, -) ....................Figure 4-15: The configuration transition of event (CFM, suspend, 1, [100, 180]) .. Figure4-16: The configuration transition of event(IR, complete, 4, [10, 15]) ......... Figure 4-17: The EOC specified in EventGenerator ..................................................

  Figure 1-1: The spectrum of business processes [Kemsley 2011] ................................. Figure 3-1: The definition of a modeling language specification ................................ Figure 3-2: The core of the CMMN metamodel .......................................................... Figure 3-3: An overview of the CMMN concrete syntax ............................................ Figure 3-4: An overview of the lifecycles of CMMN essential modeling elements ... Figure 3-5: A CMMN case model ................................................................................ Figure 3-6: An overview of HiLLS .............................................................................. Figure 3-7: The HiLLS metamodel .............................................................................. Figure 3-8: An overview of the HiLLS concrete syntax [Maiga 2015] ....................... Figure 3-9: Basic system concepts ............................................................................... Figure 3-10: The DEVS-based M&S framework [Zeigler et al. 2000] ....................... Figure 3-11: General components of an experimental frame [Zeigler et al. 2000] ..... Figure 3-12: An atomic HiLLS model ......................................................................... Figure 3-13: A coupled HiLLS model ......................................................................... Figure 3-14: A general scenario for process improvement .......................................... Figure 3-15: The framework for process reengineering .............................................. Figure 3-16: The PDCA cycle ...................................................................................... Figure 3-17: The metamodel of process tree ............................................................... Figure 3-18: A simple process tree model .................................................................... Figure 3-19: Basic components of a model transformation ......................................... Figure 3-20: A fragment of ATL transformation rules ................................................. Figure 4-1: A global view of our CMM approach ....................................................... Figure 4-2: The flow chart of our CMM approach ...................................................... Figure 4-3: The whole picture of the CMM approach ................................................. Figure 4-4: The workflow of CMI ............................................................................... Figure 4-5: The whole picture of CMI ......................................................................... Figure 4-6: The system structure of a HiLLS model ................................................... Figure 4-7: An example of configuration transitions ................................................... Figure 4-8: Different types of configuration transitions .............................................. Figure 4-9: Examples of t2f and t2p configuration transitions .................................... Figure 4-10: An example of f2p configuration transitions ........................................... Figure 4-11: An example of ECT ................................................................................. Figure 4-12: The couplings between different HiLLS models .................................... Figure 4-13: The flow chart of generating EFs ............................................................ Figure 4-14: The configuration transition of event (CFM, create, -, -) ....................Figure 4-15: The configuration transition of event (CFM, suspend, 1, [100, 180]) .. Figure4-16: The configuration transition of event(IR, complete, 4, [10, 15]) ......... Figure 4-17: The EOC specified in EventGenerator ..................................................

  Figure 1-1: The spectrum of business processes [Kemsley 2011] ................................. Figure 3-1: The definition of a modeling language specification ................................ Figure 3-2: The core of the CMMN metamodel .......................................................... Figure 3-3: An overview of the CMMN concrete syntax ............................................ Figure 3-4: An overview of the lifecycles of CMMN essential modeling elements ... Figure 3-5: A CMMN case model ................................................................................ Figure 3-6: An overview of HiLLS .............................................................................. Figure 3-7: The HiLLS metamodel .............................................................................. Figure 3-8: An overview of the HiLLS concrete syntax [Maiga 2015] ....................... Figure 3-9: Basic system concepts ............................................................................... Figure 3-10: The DEVS-based M&S framework [Zeigler et al. 2000] ....................... Figure 3-11: General components of an experimental frame [Zeigler et al. 2000] ..... Figure 3-12: An atomic HiLLS model ......................................................................... Figure 3-13: A coupled HiLLS model ......................................................................... Figure 3-14: A general scenario for process improvement .......................................... Figure 3-15: The framework for process reengineering .............................................. Figure 3-16: The PDCA cycle ...................................................................................... Figure 3-17: The metamodel of process tree ............................................................... Figure 3-18: A simple process tree model .................................................................... Figure 3-19: Basic components of a model transformation ......................................... Figure 3-20: A fragment of ATL transformation rules ................................................. Figure 4-1: A global view of our CMM approach ....................................................... Figure 4-2: The flow chart of our CMM approach ...................................................... Figure 4-3: The whole picture of the CMM approach ................................................. Figure 4-4: The workflow of CMI ............................................................................... Figure 4-5: The whole picture of CMI ......................................................................... Figure 4-6: The system structure of a HiLLS model ................................................... Figure 4-7: An example of configuration transitions ................................................... Figure 4-8: Different types of configuration transitions .............................................. Figure 4-9: Examples of t2f and t2p configuration transitions .................................... Figure 4-10: An example of f2p configuration transitions ........................................... Figure 4-11: An example of ECT ................................................................................. Figure 4-12: The couplings between different HiLLS models .................................... Figure 4-13: The flow chart of generating EFs ............................................................ Figure 4-14: The configuration transition of event (CFM, create, -, -) ....................Figure 4-15: The configuration transition of event (CFM, suspend, 1, [100, 180]) .. Figure4-16: The configuration transition of event(IR, complete, 4, [10, 15]) ......... Figure 4-17: The EOC specified in EventGenerator ..................................................

Figure 3 - 1 :

 31 Figure 3-1: The definition of a modeling language specification

Figure 3 - 2 :

 32 Figure 3-2: The core of the CMMN metamodel

  1: TEL refers to TimerEventListener. 2: UEL refers to UserEventListener.

Figure 3

 3 Figure 3-3: An overview of the CMMN concrete syntax

Figure 3

 3 Figure 3-4: An overview of the lifecycles of CMMN essential modeling elements

Figure 3

 3 Figure 3-5: A CMMN case model

Figure 3

 3 Figure 3-6: An overview of HiLLS

Figure 3

 3 Figure 3-7: The HiLLS metamodel

Figure 3

 3 Figure3-8: An overview of the HiLLS concrete syntax[START_REF] Maiga | An integrated language for the specification, simulation, formal analysis and enactment of discrete event systems[END_REF]

Figure 3 -

 3 Figure 3-12: An atomic HiLLS model

Figure 3 -

 3 Figure 3-13: A coupled HiLLS model

  -14 and Figure3-15 are the following, respectively:

  Table 3-1: Common data visualization toolsTool Description Bar Chart • A bar chart visually displays data in bars. • The height of the bars is used to represent the size or quantity measured. Pareto Chart • A Pareto chart represents data through the lengths of bars, in which bars are arranged in descending order from left to right. • It helps identify the problems that have the greatest impact. • It is based on the Pareto principle that 20% of the source causes 80% of a problem. Control Chart • A control chart is a statistical tool used to distinguish between common-cause and special-cause variations. • It helps determine which process is out of control. Histogram • A histogram summarizes data that has been collected over a period of time and presents its frequency distribution in bar form. • It helps reveal the centering, variation and shape of the collected data.

Figure 3 -

 3 Figure 3-14: A general scenario for process improvement

  -16.

Figure 3 -

 3 Figure 3-16: The PDCA cycle

Figure 3 -

 3 Figure 3-17: The metamodel of process tree

Figure 3 -

 3 Figure 3-18 shows a process tree model as an example. It consists of eight Nodes (which are Tasks a, b, c, d, and e, and Operators: SEQ (→), AND ( ), and XOR ( )) and seven Edges connecting Nodes.

Figure 3 -

 3 Figure 3-18: A simple process tree model

Figure 3 -

 3 Figure 3-19: Basic components of a model transformation

Figure 3 -

 3 Figure 3-20: A fragment of ATL transformation rules

Figure 4

 4 Figure 4-1: A global view of our CMM approach

Figure 4 - 2 :

 42 Figure 4-2: The flow chart of our CMM approach

Figure 4

 4 Figure 4-3: The whole picture of the CMM approach

Figure 4

 4 Figure 4-4: The workflow of CMI

Figure 4

 4 Figure 4-6: The system structure of a HiLLS model

Figure 4

 4 Figure 4-7: An example of configuration transitions

Figure 4

 4 Figure 4-8: Different types of configuration transitions

  Figure 4-11 gives an example of ECT, where C is a passive configuration, the trigger is (CFM, suspend), and the predicates of C' is computed following the rules specified below.

Figure 4 -

 4 Figure 4-11: An example of ECT

Figure 4 -

 4 Figure 4-12: The couplings between different HiLLS models

  The configurations of the event generator HSystem converted from a Stage/Task item define the couplings of the atomic event HSystems obtained., such that• •TransitionsHere we will detail all the possible configuration transitions of each Milestone-/EventListener-related event atomic HSystem, considering different values of item attributes we have introduce above.

Figure 4 -

 4 Figure 4-14: The configuration transition of event (CFM, create, -, -)

Figure 4 -

 4 Figure 4-15: The configuration transition of event (CFM, suspend, 1, [100, 180])

Figure 4 -

 4 Figure 4-16: The configuration transition of event (IR, complete, 4, [10, 15])

Figure 4 -

 4 Figure 4-17: The EOC specified in EventGenerator

  Figure 4-19: The graphical representation of Analyzer

Figure 6

 6 Figure 6-5: The as-is HiLLS model in a tree-view format

Figure 6

 6 Figure 6-7: The partial graphical behavior representation of the as-is HiLLS model

Figure 6

 6 Figure 6-8: The event generator Hills model

Figure 6

 6 Figure 6-9: The RS_EG HiLLS model's coupling information

Figure 6 -

 6 Figure 6-10: The RS_Suspend atomic HiLLS model

Figure 6 -

 6 Figure 6-11: The complementary information

Figure 6 -

 6 Figure 6-12: The event generator

Figure 6 -

 6 Figure 6-14: The CMMN to-be case model

Figure 6 -

 6 Figure 6-16: The backlog in the as-is model

Figure 6 -

 6 Figure 6-18: The backlog in the to-be model

Figure 6 -

 6 Figure 6-20: The comparison of lead-time

Table 2 -

 2 1: Benchmark of case management solutions

Approach Criteria of Case Management Solutions Category Name Abstract Syntax Concrete Syntax Operational Semantics Run-time Planning Information-flow Control-flow Simulation Formal Analysis Enactment Activity-based Solutions

	Approach	IDEF1	Micro-workflow	A graphical modeling	language on the basis of	Venn-diagram	An approach to model case	procedures	A GSM-and ECA-based	modeling approach	IDEF3	Business Artifact	ADoc	RAD	DEMO	Cognoscenti	Case Handling	Document-driven Workflow	ACOM	Cordys
												Solutions	Solutions		& Activity
												based	tion-based	Information
											Information-	Communica		Hybrid

Criteria of Case Management Solutions Category Name Abstract Syntax Concrete Syntax Operational Semantics Run-time Planning Information-flow Control-flow Simulation Formal Analysis Enactment Hybrid Information & Activity

	PHILharmonicFlows	Oracle BPM Suite	Newgen Case Management	Framework	Pega Dynamic Case	Management	IBM Case Manager

x

  Three Tasks (which are named as Identify Responsibilities, Create Claims Notification, and Create Claim, respectively; each of the Task element refers to a unitary piece of work to be done). x Two DiscretionaryTasks (which are called Change Responsibility and Request Missing Information; these DiscretionaryTasks are available and are ready to be executed at run-time). x Two Milestones (which are Responsibilities Identified and Base Information

Table 3 -

 3 2: The summary of performance metrics Name Formula

			throughput
	Tactical	Level	investment operating expense	the investment the organization has made the money organizations spend in turning investment
				into throughput
	Strategic Level		net profit ROI productivity

Table 4 -

 4 1: The mappings of system structure

	CMMN	HiLLS
	RootStage	HSystem
	CaseFileItem	HClass
	PlanItem	HClass
	DiscretionaryItem	HClass
	Sentry	HClass

Table 4 -

 4 2: States of CMMN modeling elements

	State	Reference Number	CMMN Elements
	Ø	0	RootStage/Stage/Task/Milestone/EventListener /CaseFileItem
	Available	1	Stage/Task/Milestone/EventListener/CaseFileItem
	Enabled	2	Stage/Task
	Disabled	3	Stage/Task
	Active	4	RootStage/Stage/Task
	Completed	5	RootStage/Stage/Task/Milestone/EventListener
	Terminated	6	RootStage/Stage/Task/Milestone/EventListener
	Failed	7	RootStage/Stage/Task
	Suspended	8	RootStage/Stage/Task/Milestone/EventListener
	Closed	9	RootStage
	Discarded	10	CaseFileItem

Table 4 -

 4 3: Transformation rules of ECT -Part 1 We use s(v) to represent the value of the state parameter of v i , and s(v') to represent the value of f(trigger).2 We use autoC to represent the autoComplete attribute of the item.

	s(v) 1	trigger	autoC 2	s(v')
	0	(self 3 , create)	* 4	4
	4 5	(self, complete)	False	5
		(self, terminate)	*	6
		(self, fault)	*	7
		(self, suspend)	*	8
	5/6/7/8	(self, reactivate)	*	4
		(self, close)	*	9
	1

Table 4 -

 4 4: Transformation rules of ECT -Part 2

	s(v)	trigger	P/D	HES 1	ES 2	Manual 3	autoC s(v')
	0	(self, create)	D	True	False	*	*
		(self, create)	D	True	True	True	*
		(self, create)	D	True	True	False	*
		(self, create)	D	False	-	True	*
		(self, create)	D	False	-	False	*
		(parent 4 , create)	P	True	False	*	*
		(parent, create)	P	True	True	True	*
		(parent, create)	P	True	True	False	*
		(parent, create)	P	False	-	True	*
		(parent, create)	P	False	-	False	*
	1	(other, *)	*	True	True	True	*
		(other, *)	*	True	True	False	*
	2	(self, disable)	*	*	*	True	*
		(self, manualStart)	*	*	*	True	*
		(parent, terminate)	*	*	*	True	*
		(parent, suspend)	*	*	*	True	*
	3	(self, reenable)	*	*	*	True	*
		(parent, terminate)	*	*	*	True	*
		(parent, suspend)	*	*	*	True	*
	4	(self, complete)	*	*	*	*	False
		(self, terminate)	*	*	*	*	*
		(parent, terminate)	*	*	*	*	*
		(self, fault)	*	*	*	*	*
		(self, suspend)	*	*	*	*	*
		(parent, suspend)	*	*	*	*	*
	7	(self, reactivate)	*	*	*	*	*
		(parent, terminate)	*	*	*	*	*
	8	(self, resume)	*	*	*	*	*
		(parent, resume)	*	*	*	*	*	H
		(parent, reactivate)
		(parent, terminate)	*	*	*	*	*
	5/6	(parent, reactivate)	P	True	False	*	*
		(parent, reactivate)	P	True	True	True	*
		(parent, reactivate)	P	True	True	False	*
		(parent, reactivate)	P	False	-	True	*
		(parent, reactivate)	P	False	-	False	*
	1 HES (hasEntrySentry) refers to if the item has any entry sentry defined.

Table 4 -

 4 5: Transformation rules of ECT -Part 3 ST (startTrigger) refers to if the condition the item's start trigger specified is met or not.

	s(v)	trigger	HST 1	ST 2	HES	ES	s(v')
	0	(parent, create)	True	True	-	-
		(other, any)
	1	(self, occur)	-	-	-	-
		(self, suspend)	*	*	True	False
		(parent, suspend)
		(self, suspend)	*	*	False	-
		(parent, suspend)
		(self, terminate)	*	*	True	False
		(parent, terminate)
		(self, terminate)	*	*	False	-
		(parent, terminate)
		(other, any)	*	*	True	True
	8	(self, resume)	*	*	*	*
		(parent, resume)
		(self, terminate)	*	*	*	*
		(parent, terminate)
	1 HST (hasStartTrigger) refers to if the item has any start trigger defined.

2

•

  Stage refers to a planItem or a discretionaryItem referring to a Stage • Task refers to a planItem or a discretionaryItem referring to a Task • Item refers to the Stage or the Task element • mar refers to the Item's ManualActivationRule • ac refers to the Item's AutoComplete attribute since a Task has no AutoComplete attribute, so we consider that Task.ac=false if Item.ac=true, then Item=Stage; otherwise it could be either a Stage or a Task • entry refers to the entrySentry of the Item • q refers to the queue of received events • trigger refers to the element the Item's entrySentry referring to trigger.event can be either complete or terminate

Table 4 -

 4 7: The complete information of selected events

	Index	Item	Action	Triggers	Duration
	1	CFM	create	-	-
	2	CFM	suspend	1	[100, 180]
	3	CFM	reactivate	2	[50, 70]
	4	R	create	1	[5, 20]
	5	IR	complete	4	[10, 15]
	6	CCN	complete	5	[17, 25]
	7	CC	complete	6	[10, 18]

Table 5 -

 5 1: The mappings between Process Tree and CMMN -1

	Process Tree	CMMN
	Manual Task	Task (isBlocking=True)
	Automatic Task	Task (isBlocking=False)
	Time Out Event	TimerEventListener
	Message Event	CaseFileItem
	Edge	Sentry

Table 5 - 2 :

 52 The mappings between Process Tree and CMMN -2

	Process Tree	CMMN

Table 6 -

 6 1: The historical event data

	Process Instance	Activity	Timestamp
	1	R	9-3-2004:15.01
	1	A1	9-3-2004:15.18
	1	A2	9-3-2004:15.29
	2	R	9-3-2004:15.30
	1	A3	9-3-2004:15.34
	1	B1	9-3-2004:15.35
	2	A1	9-3-2004:15.37
	3	R	9-3-2004:15.39
	2	B1	9-3-2004:15.41
	2	A2	9-3-2004:15.48
	1	B2	9-3-2004:15.50
	…	…	…

Table 6 -

 6 2: Information for the to-be model

	Task	Employees Required	Time Required per Employee
	R	-	[0, 0]
	A1	2	[4, 6]
	A2	4	[7, 11]
	B2	5	[10, 14]

RELATED WORKS

3. Background

CASE MODEL IMPROVEMENT

If v i .item=trigger.item, then we use self to represents this item; otherwise, we use other.

The symbol "*" means that the value of the attribute could be any (e.g., True, or False).The symbol "-" means that the value of the attribute is null.

If at any time, (1) v i = 4, (2) all its required children are in the state of 3/5/6/7, and (3) all its non-required children are not in the state of 4, then v i ' = 5.2)

ES (entrySentry) refers to if the condition the item's entry sentry specified is met or not.

We use Manual to represent the manualActivationRule attribute of the item.

We use parent to represent the Stage item that consists of the source item v i refers to.

1

GENERAL INTRODUCTION

Internal Configuration Transition

Within the HSystem (h), as we mentioned above, there are three types of possible ICTs: transient → finite (t2f), transient → passive (t2p), and finite → passive (f2p). When a t2f or a t2p transition is observed, C and C' will have exactly the same predicates, and the system output the current status of items, as specified in the following rules. Figure 456789gives examples of the two types of ICTs that are generated from our CMMN example case model. Each atomic RootStage event HSystem has two ports: one for receiving incoming events, and one for sending events to other HSystems.

Configurations

, such that Each atomic RootStage HSystem has two configurations: passive and active. Based on the event type of each HSystem, the time advance function is different: if the event is created then ta = 0; otherwise ta = .

Transitions

, such that , such that z , such that z z Essentially, if a HSystem stays in the active state, and its ta reaches then an ECT will be observed. It will transit to the passive state, and send out an event to other HSystems: the one representing the create event will send out (RootStage, create), the one representing the complete event will send out (RootStage, complete), the one representing the terminate event will send out (RootStage, terminate), etc.

However, if a HSystem stays in the passive state, and the event this HSystem

Configurations

, such that Each atomic event HSystem has two essential configurations: passive and active.

•

Milestone/EventListener → HSystem

Here we will explain how a Milestone/EventListener element translates to a coupled HSystem which contains a set of atomic HSystems, each of which generates the Milestone-or the EventListener-related events. Please note that

Ports

Like the HSystem which is converted from the RootStage, each HSystem transformed from a Miestone/EventListener element has also two ports: one for receiving incoming events, and one for sending events to other HSystems.

HComponents

According to the type of the item, the event set is various, as given below:

Ports

Each atomic event HSystem has two ports: one for receiving incoming events, and one for sending events to other HSystems.

Configurations

Each atomic event HSystem has two essential configurations: passive and active. The ta of the passive configuration equals to positive infinity, and the ta of the active configuration will be assigned by case workers later.

, such that

Ports

Like the HSystem which is converted from the RootStage, each HSystem transformed from a CaseFileItem element has also two ports: one for receiving incoming events, and one for sending events to other HSystems.

HComponents

Unlike other CMMN basic modeling items, the CaseFileItem has no specific attributes. Therefore, all the CaseFileItems will contain the same amount of atomic event HSystems, each of which represents a CaseFileItem-related event:

Ports

Each atomic event HSystem has two ports: one for receiving incoming events, and one for sending events to other HSystems.

Configurations

Each atomic event HSystem has two essential configurations: passive and active. The ta of the passive configuration equals to positive infinity, and the ta of the active configuration will be assigned by case workers later.

, such that

Transitions

Here we will specify all the possible configuration transitions of each CaseFileItem-related event atomic HSystem.

, such that , such that z z , such that z z

Configurations

The configurations of the event generator HSystem converted from a CaseFileItem item define the couplings of the atomic event HSystems obtained.

, such that

Complementary information

Until now from the original case model we could receive an IEF which contains all possible item events and the couplings among them. However, in reality it is not necessary to have all the events for conducting a simulation practice. To this end, case workers have the right to select a set of events which will be used in the simulation practice later. Essentially, the information to complete is as following:

• σ (specified by case workers) • triggers (selected from available generated options)

• internal couplings (selected from available generated options)

• event scheduling (automatically generated on the basis of the information specified above)

Once all required information is specified, then the final EF can be generated.

• Each h (where ) has an index number associated that making it unique.

• For each h where AND , if , then this h

Introduction

The aim of CMD module is to help case workers automatically construct case models from the historical raw data recorded. To this end, we consider to adopt the process discovery approach that extracts process information from event logs. Different process discovering algorithms result in process models conforming to different modeling formalisms: Process Tree, Hidden Markov Models, Yet Another Workflow Language, Event-Driven Process Chains, etc. Apparently, a gap exists between these process discovery modeling specifications and the de-facto modeling standard for CM (i.e., CMMN). To overcome this problem, we envision transforming Process Tree models into CMMN models, as illustrated in Figure 5-1. The reason for us to select Process Tree as the modeling formalism for expressing discovered models among other ones is that Process Tree models are ensured to represent sound models [START_REF] Eck | Genetic process mining: Alignment-based process model mutation[END_REF]]. Moreover, the ETM algorithm used to generate Process Tree models guarantees that the discovered models are error-free, and meet the four quality-evaluation dimensions: replay fitness, simplicity, generalization, and precision [START_REF] Buijs | Flexible Evolutionary Algorithms for Mining Structured Process Models[END_REF]]. In this section, we will first explain how we translate a Process Tree model into a CMMN correspondence. Then we will use a simple example to illustrate our case models discovering approach.

Translations from Process Tree to CMMN

A generic way to transform Process Tree models into CMMN counterparts is to map the Process Tree metamodel onto the CMMN one, where the former is given 1) SEQ Operator, If nodes A 1 , A 2 … A n are linked by an SEQ operator ( ), then each node A i (1≤i≤n) converts to a CMMN PlanItem P i , respectively. P i refers to different types of CMMN elements, based on the type of the Process Tree node it converts from, as given in Table 5-1: (1) P i refers to a Task with its isBlocking attribute set to True, if A i is a Manual Task; (2) P i refers to a Task with its isBlocking attribute set to False, if A i is an Automatic Task; (3) P i refers to a TimerEventListener, if A i is a Time Out Event; or (4) P i refers to a CaseFileItem, if A i is a Message Event. Moreover, each P i (except P 1 ) has a sentry defined as its guarding condition, and these PlanItems are connected as a chain following the sequence specified in the original Process Tree model: P 2 links with P 1 through P 2 's entry sentry, P 3 links with P 2 through P 3 's entry sentry, and so on, as specified below. This way, once P 1 is completed then P 2 will be triggered to execute, and P 3 will be active once P 2 is completed, and so forth. ), then each node A i (1≤i≤n) converts to a CMMN PlanItem P i , respectively. As defined in the SEQ operator, the type of CMMN element each P i referring to is different, according to the element type of A i . The element M is a Milestone used as a constraint to indicate the AND logical relations among all the PlanItems: it will be completed only if each P i is completed. To this end, M is associated with one and only one entry sentry S, and all PlanItems are connecting with S. ), then each node A i (1≤i≤n) converts to a CMMN PlanItem P i , respectively. As defined in the SEQ operator, the type of CMMN element each P i referring to is different, according to the element type of A i . Moreover, a Milestone M is defined and is associated with a set of entry sentries S 1 , S 2 … S n , and each S i (1≤i≤n) links with P i , respectively. This way, the OR logical relation can be enabled: M will be completed if at least one P i is completed.

), then each node A i (1≤i≤n) converts to a CMMN DiscretionaryItem D i , respectively. The same as the situation specified in the SEQ operator, the type of CMMN element each D i referring to is different, according to the element type of A i . Moreover, each D i is associated with an entry sentry S i that has only an ifPart defined, and the CaseFileItem F generated specifies the content for evaluating the ifPart of each S i . In addition, a PlanItem P referring to a Task is created to modify the content of F (i.e., F is the output of P), and it links with D i through its associated entry sentries (S i '). At initial time, all the DiscretionaryItems are at the null status, and their associated entry sentries are set to True. Once a Di is created, then P will be activated to modify the content of F such that all other sentries of the DiscretionaryItems will be evaluated to False, except the one that has been created. This ensures that one and only one DiscretionaryItem can be executed. 5) XOR Operator, However, if a node A is linked with τ (which represents a silent action) using an XOR operator (

), then it indicates that either node A is executed, or nothing will happen. In this case, the node A converts to a CMMN DiscretionaryItem D, and the type of CMMN element D referring to is different, according to the element type of A. D is at the null status when initialization, and is applicable at run time. This way, D can be either created to be executed or still remains at the null status.

6) LOOP Operator, 128

If nodes A, B and C are linked using an LOOP operator ( ), then a PlanItem P referring to a Task will be created. In addition, P is repeatable: the repetitionRule of P is set to True (which is indicated using a # shape). An entry sentry associated as its guarding condition is created too, so that each time the entry sentry evaluates to True, a new instance of P is created. Otherwise, no new instance of P will be created.

Model Transformation Algorithm

In addition, we also define an algorithm in order to execute Process Tree to CMMN model transformations effectively and efficiently, which traverse all the operator nodes starting from the lowest level ones to the highest level one, where in our case the root node is at the highest level. More specifically, assuming that the root node is at level 0, and the lowest level the children operators are at is level n. We start from converting the operators at level n, with all its containing children, and from left to right, as specified in the section above. Each child node will convert to its CMMN equivalence, and they will be joined together in the logical manner the operator node defines (SEQ, AND, OR, XOR, and LOOP). Then we move to the upper level, level n-1, and perform the transformation using the CMMN segments we obtained at level n. Then we continue until we reach to level 0 where the root node stays. Figure 5-2 below summarizes this algorithm using pseudo codes. . This will ease the model transformation process if case workers deal with cases with a great amount of process-related recorded

GENERAL CONCLUSION