Louis Forite
email: louis.forite@gmail.com

Charlotte Hug
email: charlotte.hug@univ-paris1.fr

FASMM: Fast and Accessible Software Migration Method

Keywords: migration method, intentional process model, model driven engineering, knowledge management I

With the fast changes of development technologies, organizations often need to migrate their software from a source to a target technology that could comprise a shift in programming paradigm. This operation is not easy and requires precision and structuring. However, in small companies, due to lack of resources (workforce, time, budget…) the migration phase is frequently quickly done and not necessarily in an optimized way: functionalities are not implemented properly, the new architecture is loose and knowledge gained during the migration is not capitalized. This paper presents a method to guide developers in the migration of software functionalities based on model driven engineering techniques and allows capitalizing knowledge as transformation rules, to enable their reuse in future migration projects. This method was built from a case study in a French company that produces software training and support for critical applications.

INTRODUCTION

With the fast changes of development technologies, organizations often need to migrate their software products from a source to a target technology that could comprise a shift in programming paradigm. In this paper, we studied the case of a French SME that produces training and support software products for critical applications. The company was founded 13 years ago and has already trained more than 400,000 users for major worldwide accounts through its software products. It employs 30 engineers that work on the same site. The development team implements agile best practices as pair programming and daily stand-up. In 2013, the company had to migrate one its flagship software product, an Electronic Performance Support System (EPSS), where the data management was developed in Java/J2EE and the users' interaction part for the website was developed in HTML, JavaScript and Ajax. The server is then developed in Java and the communication with the client is done in Ajax. The final objective of this migration was to ensure the full compatibility of the EPSS with the Oracle E-Business Suite ERP by developing a full Java version of the system. Several issues can be raised during a migration project and in the case of this French company in particular. We describe them hereafter:

No proper method of migration is defined or followed. To migrate the software product, no method is recommended. The development team defines the structure and border of the functionalities to migrate by consensus. Functionalities evaluated as essential are migrated first (rewriting the code «from scratch» in the targeted technology). There is a poor visibility on the goals and expectations regarding the business: the scope of the functional coverage of the software to migrate is not clearly defined. Nothing guarantees the quality and consistency of the new developments. Rewriting the code "from scratch" is a risky and lax technique considering the fact that there is a programming paradigm shift between the source and the targeted technology which creates additional difficulties.

The software does not have source analysis models, visibility and understanding of the current software is therefore complex and limited. Indeed, in SME, modelling does not seem to be a priority. Little time is spent on models management and methodology. These methods are often time-consuming, or require too specific knowledge. Thus, software models are often set aside in favor of actual developments. The models are nonexistent or not kept up to date. This has a double impact on future developments: the developers have poor visibility of the overall software architecture and developments are less rationalized.

The paradigm shift in programming between the source software and the target software is a difficulty. Each programming paradigm provides a different view of the software and offers different options to implement the product to the developers for a given problem. Software products are coded very differently according to their programming language. There is a real complexity to migrate software products from one programming paradigm to another as it requires to abstract the first to rethink the other. Some mechanisms in a given paradigm can hardly be feasible while in another they can naturally be implemented.

Developers accumulate technical knowledge during the migration project that will eventually get lost. During the software migration, developers involved gain experience in migrating software products from one technology to another; from JavaScript to Java in this case study. This knowledge, although essential during migration, is not capitalized, but only shared, orally or by memos, between developers participating in the project. It could be interesting to capitalize this knowledge to reuse it and share it in future migration projects to earn resources and time.

Several methods have been proposed to migrate software products or legacy systems [START_REF] Brodie | DARWIN: On the Incremental Migration of Legacy Information Systems[END_REF], [START_REF] Bing | The Butterfly Methodology: a gateway-free approach for migrating legacy information systems[END_REF], [START_REF] Arsanjani | SOMA: a method for developing service-oriented solutions[END_REF]. However, according to our knowledge, those methods do not take into account:

 The technical difficulty introduced by a shift of programming paradigm between the source and target technology,

 The difficulty of their implementation in SME because of their complexity [START_REF] Bing | The Butterfly Methodology: a gateway-free approach for migrating legacy information systems[END_REF], and time and budget consuming constraints.  The loss of technical knowledge acquired during the migration as it is not capitalized.

The goal of this paper is to propose a method that allows to simply perform software migrations while capitalizing the accumulated knowledge. The method supports a shift in programming paradigm thanks to model driven engineering concepts. It is aimed at small development teams in SME with standard knowledge in modeling. The proposed approach is called "Fast and Accessible Software Migration Method" (FASMM). We designed it to be easy to learn and to use for any software developers in time and resources constraining context.

We describe FASMM in section 2. Section 3 presents a first evaluation of the method. Section 4 presents the related work and section 5 concludes this paper.

II. FASMM

The purpose of this method is to provide a framework for the functionalities 'migration of a software product while the source and targeted technologies are based on different programming paradigms. This approach has multiple objectives as to:

 Automate certain phases of the migration,  Ensure that the migrated functionalities fulfill their technical and functional objectives,  Formalize and capitalize the technical knowledge gained during the project,  Be simple enough that it can be applied by developers who do not have very advanced knowledge in modeling and metamodeling.

This method is primarily intended for small development teams. However, it requires the involvement of some functional actors for the definition of user goals as it is necessary to ensure that the project will cover the business requirements. Functional actors as business analysts or users are then needed to ensure the success of the migration project. We built FASMM from the experience of a project migration in a French SME. This section will first present an overview of FASMM, we then describe the artifacts and the process in detail.

A. Overview of the method

The method answers to both problems of migration and knowledge capitalization. The method guides the developers in modeling the functionality to migrate. A system functionality is the ability to perform a set of tasks to achieve a specific goal. The developers can then carry out the migration it-self by applying transformation rules to the existing code and the models. They finally have to validate the migrated functionality. While working on the migration, developers discover transformation rules and add them to the dictionary for knowledge capitalization. The inputs of the method are the application to migrate and the existing related technical (class and state transition diagrams) and functional documents (textual use case, class diagrams). The dictionary of transformation rules is also an input (see section II B.2). The output of the method is the migrated and validated functionality and the updated dictionary of transformation rules. Section II.Q presents a global view of all the inputs and outputs of the method. Fig. 1 presents the method as a map process model, instance of the Map process metamodel [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF]. A map focuses on the different strategies to achieve intentions in a flexible way as each intention is reached independently and when it is achieved with satisfaction, the actor may continue the enactment of the process and achieve new intentions. The nodes represent the intentions and the edges, the strategies to follow to achieve an intention target, from an intention source. A section of a map is a triplet composed of a source intention, a target intention and the corresponding strategy to achieve it. In Fig. 1, the sections in bold are refined as map process models. The method is then presented at different levels of abstraction to ease its understanding and to refine the complex parts of the process to facilitate its use and properly guide developers during the enactment.

We defined five intentions: "get model", "migrate functionality", "validate", "discover transformation rule" and "enrich dictionary". By providing the method as a map, developers will be able to work on the different phases of the migration and at the same time enrich the dictionary by transformation rules: Map allows enacting different paths at the same time according to the reasoning of the developers. The FASMM enactment is then flexible as the developers will be able to follow different strategies to achieve their intentions. For example, to get the models of the functionality to migrate, a developer can enact several times the strategies by reverse engineering and by reviewing existing code as long as the models are not validated (the intention is not achieved). The whole model should be enacted as many times as there are functionalities to migrate.

In the "branch" covering the migration (lower part of Fig. 1), we identified five strategies to get a model. By reverse engineering of the existing code, by reviewing existing code and by reviewing existing models are complementary as there is often a gap between the models and the code. Therefore, it is necessary to complete the existing models before applying transformation rules. It is possible to get models by identifying reusable part of codes and by identifying unsatisfying parts of code. Finally, developers have to validate the technical and functional models by consensus. We identified two strategies to achieve the intention "migrate functionality": manual and semi-automatic, which are complementary. The manual strategy consists in applying transformation rules from the dictionary (pattern recognition…). The semi-automatic strategy allows generating code from the obtained models. Model Driven Engineering techniques can also be considered to transform models into refined models by using Model to Model transformations. The migrated functionality has to be validated by functional tests, i.e. to verify its consistency with the models, and by technical tests to ensure the durability of the solution and its reliability.

The second branch of the method is about knowledge capitalization (upper part of Fig. 1). We identified the intentions "discover transformation rule" and "enrich dictionary". Rules can be discovered by experience, by model analysis, by problem identification during the migration of the functionality or by reviewing the code. Developers can enrich the dictionary by creating new rule, by invalidating or correcting existing rules or by structuring the dictionary it-self.

The method produces three artifacts: the dictionary that contains the knowledge on migration formalized as transformation rules and the migrated functionality with the associated models. The added value of this method is the knowledge capitalized in the dictionary to be reuse and enrich projects after projects.

We first describe the artifacts produced during the enactment of the method. We then present the sections of the method. Some of them (in bold in Fig. 1, are refined as maps).

B. The artifacts 1) Transformation rules

"A transformation is the automatic generation of a target model from a source model, according to a transformation definition" and it "is a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language." [START_REF] Kleppe | MDA Explained, The Model-Driven Architecture: Practice and Promise[END_REF] We need to specify a transformation rule to identify a specific situation and to propose a solution, for example how to migrate a GUI from Java to JavaScript. To specify a transformation rule, we propose the following template: title of the rule, the source and the target technology, its categories, the application case, its description, its status and the author of the rule. The proposed template is minimalist; it only comprises six sections to reduce the writing effort of the developers. The experience shows that if the contribution is perceived as a burden, people won't do it [START_REF] Rus | Guest Editors' Introduction: Knowledge Management in Software Engineering[END_REF]. It is then essential to ease the work of the developers. Two sections will then really need an effort: the description and the application case. The description will comprise the transformation itself, described as an algorithm or in a transformation language as ATL [START_REF]Atlas Transformation Language[END_REF] or QVT [START_REF] Omg | Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification[END_REF].

2) Dictionary

The dictionary is a coherent set of transformation rules on different technologies for the migration. It is organized in categories as HMI, algorithm… The available operations on the dictionary are described in the next sections. The dictionary can be implemented as a Wiki to be easily accessible. The dictionary, once defined, can be reused and enriched in other migration projects (it is then an input of the new migration projects).

3) Migrated functionality and models

The migrated functionality comprises the code and the associated models. At the end of the enactment of the method, the functionality will be technically and functionally tested. It will match the business requirements and technical constraints of upgradability, modularity, maintenance, with a minimal effort of recoding. The migrated functionality will be associated with its updated models. The models are all instances of the UML metamodel [START_REF] Kleppe | MDA Explained, The Model-Driven Architecture: Practice and Promise[END_REF]: use case diagram for the functional part and class and state-transition diagrams for the technical part of the functionality to migrate. We chose to use those models because they are easy to understand by developers who would not necessarily have strong experience in modelling. The recommended UML models are those which are the most commonly used in companies [START_REF] Dobing | How UML is used[END_REF]. Fig. 2 presents a simple technical model defined as a class diagram representing an interface "Payable" and two implemented classes "Invoice" and "Employee" (inspired from [START_REF] Deitel | Java for Programmers[END_REF]). Fig. 3 presents the JavaScript code to represent the technical model using the transformation rule defined in TABLE I. To ease the modelling and the transformations, we strongly recommend the use of Integrated Development Environment as EMF [START_REF]Eclipse Modeling Framework[END_REF] for example.

C. <Start, Get model, By reverse engineering>

The section <Start, Get model, By reverse engineering> in Fig. 1 is refined in the map presented below (Fig. 4). There are two different paths in this map: the functional modelling and the technical modelling of the functionality to migrate. The main objective is to understand and define the borders of the functionality to migrate.

1) Functional modelling

Developers have to define a functional scope to better focus on the development of the user goals, using two strategies:

 To interview the people concerned by the functionality to migrate to understand their needs. They can be users or business practitioners. Users are the people who use the system in their daily work. Business practitioners hold the knowledge of the domain of the system, know the related business practices but do not necessarily use the system itself.

 To directly use the functionality in the software to understand its purpose.

These strategies are complementary. Thus, if one of the two strategies is not sufficient to discover the functional scope of the functionality to migrate, the developers may use the other to collect the maximum amount of information.

Once the information gathering is done and satisfying, we recommend the creation of two documents to formalize the functional scope of the functionality to migrate: the textual use case and the use case diagram. The use case diagram should be easily understood, it is in fact a powerful communication notation. In general, the models are an abstraction of reality. They offer a better overview than text documents, but they have the disadvantage of sometimes being less precise. UML [START_REF] Kleppe | MDA Explained, The Model-Driven Architecture: Practice and Promise[END_REF] is recommended for defining the use case diagrams in FASMM.

On the other hand, the textual use cases allow to describe more precisely a business process as they detail the different steps of a use case. To write a textual use case, the structure defined by Alistair Cockburn, "Casual use case" is recommended [START_REF] Cockburn | Writing Effective Use Cases[END_REF]. It has the advantage of being concise; however its quality greatly varies according to the author. A textual use case always follows the same template: title, primary actor, scope, level, and story.

Once these two documents are completed, the functional scope is defined. If developers know in advance what the migrated functionality should do, it will be easier to define what part of the code has to be migrated.

2) Technical modelling

Technical models are class diagrams and state-transition diagrams. State transition diagrams can be easily understood by functional actors as it permits to correlate the object of the system and the corresponding business object. We did not preconize the use of sequence diagram that can be hard to define and to understand without good modelling knowledge. To determine the technical models, we identified two strategies:

 Review existing models and divide them to determine the borders of the migration. This strategy is strongly recommended when the models match the current architecture of the software as they offer a better comprehension of the system. The developers will then be able to measure the impact of the migration and could tell which class will be useful or not to the migration. However, when models are not up to date, we recommend to base the discovery of the technical scope from the models obtained through code introspection.  Review the code by introspection to understand which part has to be migrated or not when models are not available at all. Although it is tedious and less precise to determine which part of the code to migrate or not, yet, it allows to prepare the developers to the next steps of migration as he/she will need to inspect the code of the functionality.

These strategies can be combined as reviewing the code can help checking the obtained models.

Once the technical scope is defined, the developers can obtain the technical models either by automatically reverse engineering the models from the defined source code (by automatic strategy), either by manually designing the models from the reviewed code (by manual strategy). Lots of tools exist to reverse -engineer the code as ObjectAid [START_REF]Object Aid[END_REF], Papyrus [START_REF] Papyrus | [END_REF], eUML2 [START_REF] Soyatec | [END_REF], MaintainJ [START_REF] Maintainj | [END_REF], JS/UML2 [START_REF] Jsuml | [END_REF]… However some technologies are not supported by reverse engineering as JavaScript that is prototyped (dynamic structure during execution). Only libraries written in such languages can be reverse engineered (JQuery [15], script.aculo.us [START_REF]ScriptAculous[END_REF]), if the code is written from scratch, it will be impossible to use such tools. The manual strategy is then the only option, although laborious.

D. <Get model, Get model, By identifying reusable part>

The map in Fig. 5 refines the section <Get model, Get model, By identifying reusable part> of Fig. 1. Before migrating the functionality, we recommend to define what can be reused from the existing code and what should first be transformed. A reusable part is code that is directly exploitable (which can be directly transcribed into the target technology), e.g. a class, a mechanism, a function... This phase is very technical and is addressed to the developers; a lot of time can be spared if this step is done correctly.

To define reusable parts of the software, we defined three strategies:

 By documented research,  By code introspection when developers know that the target technology will support this technology or concept (in terms of architecture, design pattern, interface mechanism…).

 By model reviewing when the target technology will support the same architecture as the source.

Many commodities [START_REF]Invoking JavaScript from applet[END_REF], [START_REF]Invoking Applet Methods From JavaScript Code[END_REF] exist to make technologies communicate as native API that prevent the developers to recode some functionalities. It is then recommended to do a research to check the possibilities of bridge between source and target technologies and to use them. This will accelerate the development and prevent pitfalls.

For example, in our case study, there is an API provided by Oracle [START_REF]Invoking JavaScript from applet[END_REF] authorizing the invocation of JavaScript code from the applet, and vice versa. This avoids redeveloping functionalities that could cause annoying technical issues such as security problems. In the case of web services, it is easy to reuse WS from a technology to another. It is therefore not necessary to redevelop these services, which will save time and effort.

Many functionalities can actually be reused from the source to the target technologies. This is not the case for all functionalities; typically Graphic User Interfaces are rarely reusable from one technology to another. They must then be redeveloped according to the possibilities of the target technology. Generally, there are similarities between the different technologies for HMI, as listeners or event handlers mechanisms.

With the strategy of code introspection, the developer is asked to dive into the heart of the functionality to migrate to arbitrarily judge what could be subject to direct or indirect reuse.

Finally, reviewing the functional and technical models can also be useful to define what is reusable. Developers will be able to tell whether such architecture is reproducible in the targeted technology given the programming paradigm shift. They should then look specifically into the code if the reusability can be effective.

E. <Get model, Validate, by functional tests>

The validation of the functional modeling is dual: there is firstly a semantic validation that checks the compliance of the use case diagrams [START_REF] Charroux | [END_REF] [19], and secondly a functional validation to check the clarity of the use cases. A clear use case must be intelligible and understandable by everyone and must fit into the functional scope previously discovered. This validation will be carried out with the technical team (the developers) and the functional team (business analysts) previously involved: are the models relevant enough? Do they precisely reflect what is required in the software in terms of business and user requirements?

F. <Get model, Validate, by technical tests>

The validation of the technical models (class and statetransition diagrams) of the functionality to migrate focuses on the scope of the previously obtained models. These models are the basis of the functionality migration. This validation is therefore done by consensus of the technical team by agreeing on the technical modeling before moving to the migration itself: is the new architecture coherent? Is it scalable, modular and maintainable?

G. <Get model, Get model, by identifying unsatisfying part>

The map in Fig. 6 refines the section <Get model, Get model, by identifying unsatisfying part> of Fig. 1. When developers work with legacy code, technical or architectural choices are questionable. They must then identify which part must be kept or not for the migration and what should be improved. The way to identify non-reusable code must be done within the team by consensus. Non-reusable code does not follow good practices, is unreadable and unintelligible at first glance, contains misnamed classes...Tools allow measuring the quality of code and therefore improve it, as Checkstyle [START_REF]Checkstyle 5.7[END_REF] for Java.

The way to identify non-reusable code must be done within the team by consensus.

Once the unsatisfying code is identified, the functionality must be designed in a smarter way. Developers technically model this part of the functionality and integrate it into the global model of the functionality.

H. <Get model, Migrate functionality, by semi-automatic strategy>

The map in Fig. 7 refines the section <Get model, Migrate functionality, by semi-automatic strategy> defined in Fig. 1. M2T transformations allow to automatically generate code from models (By M2T transformations). In FASMM, developers generate the skeleton of the future functionality taking as a basis the models obtained by the reverse engineering strategy and complete it with manual transformations rules from the dictionary. Developers can also go through a more complex modeldriven engineering process by defining a metamodel that represents the domain associated to the functionality (By metamodeling). Developers must then apply Model to Model (M2M) transformations to refine the models in conformance with the metamodel. This process is very complex to implement and requires advanced knowledge in modeling and metamodeling. We do not recommend this strategy, as most developers lack skills and time to enact it correctly.

However, as previously said, the models obtained by reverse engineering will be partially usable. Some parts of the models will be directly usable (by automatically generating code) while others will require more subtle and nonautomatable transformations.

It is highly recommended to use a maximum of best programming practices to get the best quality code as possible, by writing unit tests for example.

I. <Get model, Migrate functionality, by manual strategy>

The strategy of manual processing is complementary to the strategy of semi-automatic transformation. It consists in applying transformation rules on models or source code. Fig. 8 shows the refinement of the section <Get model, Migrate functionality, by manual strategy> of the method presented in Fig. 1. Applying a transformation rule consists first in identifying a particular scenario (in the code, architecture, mechanisms) in which it is necessary to make changes to make it compatible with the target technology. These transformation rules are retrieved from the dictionary that developers complete during the migration. A transformation rule can also be applied by heuristic when a developer knows the rule is adapted to the situation.

We also advise to implement a maximum of best programming practices to get a code as good as possible. By writing unit tests for example (if the technology permits it), a smooth development is ensured.

J. Discover transformation rule

We identified four independent strategies to achieve the intention "Discover a transformation rule" (see Fig. 1). The transformation rules will be defined according to the template presented in section II.B.1)

1) By Experience

The strategy of discovery of new transformation rules based on experience enables developers to directly enrich the dictionary when the project starts. Developers accumulated tacit knowledge during previous projects; they can therefore make it explicit by writing transformation rules in the dictionary.

2) By code review / heuristic

During the migration of the software, developers are encouraged to review the code to determine whether some part of the code is reusable. If part of the code is not directly reusable it will require a transformation that will result in a new rule.

The majority of the rules are discovered by code review. Most of the time, these are technical rules to bridge the gap between two programming paradigms.

3) By problem identification

During migration, many technical problems arise: technical incompatibilities, security problems while using API... The identification and resolution of these problems lead to transformation rules as long as the case is identifiable.

4) By model analysis

By analyzing models, it is possible to know which part of the functionality will be reusable or not, the model analysis is then a good way to discover new rules.

K. Enrich dictionary

To achieve the intention "Enrich dictionary", we identified four strategies (see Fig. 1):

 Create a new transformation rule, and add it to the dictionary,  Disable an existing transformation rule,  Fix an existing transformation rule by detecting an error, inaccuracy, inconsistency,  Improve the structure of the dictionary by adding categories (to better find and organize the capitalized knowledge).

In the short term, this dictionary may seem useless because when a developer finds a transformation rule (consciously or unconsciously), he applies it directly. With the dictionary, the developer has to formalize this rule and systematically think about the impact of its results. In addition, the developer is required to write his understanding of the technology. This dictionary can be reused in the following migration projects to earn time while searching for and applying transformations. The dictionary allows to capitalize knowledge in a formalized way.

L. <Discover transformation rule, Enrich dictionary, by creation> Fig. 9 presents the refinement of the section <Discover transformation rule, Enrich dictionary, by creation> described in Fig. 1.

The creation of a new rule requires its prior discovery and the verification of the existing rules to avoid doubloons. It is then essential for developers to properly identify the rule first by specifying the situation when it applies, its name, its categories, (architecture, algorithm, performance...). The formalization of a rule by review can be done by other developers to ensure the rule is understandable by everyone.

When several developers reviewed the rule and approved its formalization, the status of the rule can be set to active to be visible by the other team members.

M. <Discover transformation rule, Enrich dictionary, by correction>

The map in Fig. 10 presents the refinement of the section <Discover transformation rule, Enrich dictionary, by correction> specified in Fig. 1.

To achieve the intention "Enrich the dictionary", developers can use the correction strategy. They must first identify the rule; to do so, there are three strategies: the developer can look for a rule by its name, by its category, or by keywords.

Then the developers identify the correction to be made: by adding new content to the rule (when developers discover that the rule can be applied in other cases), by generalizing the case of application of the transformation rule, or by correcting a rule which was initially wrong (if poorly initially specified, if it became obsolete in terms of technology or practice…).

N. <Discover transformation rule, Enrich dictionary, by invalidation>

The map in Fig. 11 presents the refinement of the section <Discover transformation rule, Enrich dictionary, by invalidation> defined in Fig. 1.

The invalidation rule strategy may seem paradoxical to reach the "Enrich dictionary" intention. At first glance, the invalidation is perceived as a loss but removing a false or outdated rule participates indeed in the consolidation of the knowledge of developers. To be useful, the dictionary must contain reliable transformation rules.

It is also possible to archive the rules. This action allows to keep track of their history. This is necessary to understand the existing rules and the process that led to them.

O. Validate the migrated functionality

This section is described in Fig. 1. We identified two strategies to validate the migrated functionality. The functionality has to be functionally and technically validated.

1) By functional tests

The functional validation strategy of the migrated functionality consists in checking the conformity of the functionality or part of it to the use cases obtained in the reverse engineering phase. There will be as many tests as use cases.

To validate the migrated functionality it is possible to run end-user tests. If the functionality fulfills its role, it is then validated. Test scenarios can be implemented to ensure the uniformity of functional tests. In addition, questionnaires can be written to enable the collection of users' opinion.

2) By technical tests

The validation by technical tests strategy aims to ensure the technical sustainability of the new architecture and the new code. Developers can verify the implementation of best practices (exception mechanism, use of design patterns, generic code, functionalities developed as components etc.). If there is no legacy code in the new developed functionality, it is then much easier to implement best practices as legacy code often obligates to badly code to keep the system working. It is also possible to test the code by creating unit tests; if they fail the migrated functionality is not validated.

P. <Enrich dictionary, Enrich dictionary, by structuration>

To structure the dictionary, developers can follow three different strategies:

 Create a new category that will better classify the different transformation rules. For example, the HMI elements are not reusable from one technology to another. A developer could create technologic HMI categories that would contain all the knowledge related to specific HMI transformation rules. Another category could be dedicated to the programming paradigm shift and its implications on the code and how to program from one paradigm to another.

 Modify an existing category to make it more specific or generic depending on the need. For example, the HMI category may be specified into HMI: the forms.  Classify the rules in different categories to move rules from one category to another.

Fig. 12 shows the refinement of the section <Enrich dictionary, Enrich dictionary, by structuration>.

Fig. 12. Refined map of the section <Enrich dictionary, Enrich dictionary, by structuration>.

Q. Description of the inputs and outputs of the method

In this section, we focus on the different inputs and outputs of the method. The method is presented as a map; each intention corresponds to the creation or modification of a set of artifacts. We described them in section II.B, however we still need to specify when they are produced and used in the method. TABLE II. presents for each couple of source and target intentions the related inputs and outputs. We do not represent the strategies related to the target intentions as the sections can be enacted as many times as possible until the target intention is achieved. Moreover, different strategies related to the same couple of source and target intentions will be enacted several times to achieve the intention. For instance, from the start intention to the "Get model" intention, the inputs are the existing code, the existing models (functional and technical), and the knowledge hold by the user and the business practitioners on the functionality to migrate. The expected outputs, when the "Get model" intention is achieved, are: the technical models, the textual use cases and the use case diagrams of the functionality to migrate, whatever the applied strategies. We did not detail the inputs and outputs of the refined maps, as it would complicate the understanding of the table.

The final products are presented in the two last rows of the table in bold: the upgraded version of the software or application (each migrated functionality corresponds to an upgrade), and the completed dictionary with the transformation rules discovered during the migration of the functionality.

III. A FIRST VALIDATION

We set up a protocol to evaluate qualitatively the experience of the developers using FASMM, based on exercises and questionnaires. We carried out the evaluation in the French company, with members of the EPSS migration project. A. The protocol We conducted the evaluation as semi-structured interviews. First, we gave an overview of FASMM to the subjects, presented its challenges, the whole process as a map, the definition of key concepts as reverse engineering, textual use case, etc... The questionnaire was then distributed with the wording of the exercise to complete. The exercise consisted in following FASMM to migrate a functionality of calculus for an educative software product from HTML5/JavaScript to Java. The code of the functionality in JavaScript and an incomplete class diagram were provided to the subjects. The purpose of the semi-structured interview was to put the subjects in the context of a migration so they could apply different strategies to achieve the intentions following the method. We wanted to evaluate:

 The clarity of the method (its objectives and challenges),

 The ease of use of the method,  The interest of the developers for the method.

The subjects had to produce different artifacts during the evaluation:

 The artifacts of the method: the models, the migrated functionality, the discovered and formalized transformation rules,  The products of the evaluation: their comments and remarks.

The actual result and the expected results were compared. We measured the delta between them to evaluate the technical efficiency of the method.

B. The evaluation and results

We chose three members of the migration project of the French company as subjects. The evaluation lasted two hours but all the sections of the method were not enacted because of lack of time.

1) Profile of the subjects

The three subjects had technical profiles. They all had a good experience in software development (five years minimum), and participated to software migration projects from Java 1.4 to Java 1.5 and Web to Java, without using any predefined method. They then had a good experience in software migration.

2) Clarity and ease use of the method All the subjects agreed the method was understandable with explanations and guidance. Globally, they understood the method and raised an important point: the modelling is important in the migration process.

However, some sections of the method have not been clearly understood as <Get model, Get model, By identifying reusable part> because the "reusable part" concept was misleading: "Is it the code or the architecture?" (S2). Some subjects did not assimilate the concept of transformation rule: "What should be the level of granularity of a rule?" (S1), "When should a rule be used?" (S3).

The subjects felt the method was difficult to use as it was perceived little iterative and directive. The lack of iteration in the method is probably due to the fact the subjects did not understand the principle of Map which allows enacting a section as long as the intention is not achieved. Paradoxically, they did not consider the steps of the method and their implementation too abstract.

3) Interest for the method

The subjects manifested a great interest for the method. They were unanimous to say it allowed them to achieve the objective to migrate the functionality proposed in the exercise. They agreed FASMM could be used in an organization according to the context (available time to assimilate the method, specific migration projects).

The subjects regretted the fact of not having enough time to implement some parts of the method, including the functional validation. They were therefore unable to assess this part of the method.

C. Conclusion

The subjects all agreed that the exercise was interesting. They underlined that the case presented in the exercise was relevant and that the functionality migration described was justified. The time allotted for the evaluation was too short, however, in two hours, the subjects succeeded in migrating the functionality from JavaScript to Java (without the functional validation).

The results of this evaluation are positive. The method achieved its goal: it guided the subjects through the functionality migration. S1 emphasizes that the migrated functionality was more complete and easier in terms of maintainability, more viable in terms of reusability and genericity than the original functionality. The method helped S2 to overcome the programming paradigm shift thanks to the modelling. S3 described the method as easily affordable.

IV. RELATED WORKS Performing a software migration consists in transforming an existing system into a new one in a new environment, without redeveloping everything from scratch, to meet the requirements that the old system can no longer ensure [START_REF] Koskinen | Evaluation of Software Modernization Estimation Methods Using NIMSAD Meta Framework[END_REF]. These requirements may be of different nature: new business requirements, performance, maintainability, safety... The challenges of a migration are multiple. Paradoxically, few software migration methods have been proposed:  The "Big Bang" or "cold-turkey" method is not actually a method and it is risked. The code is redeveloped from scratch using recent technologies. It is hard to redevelop a software product without reproducing errors present in the legacy code. The knowledge about the software product influences the recoding. There is a high risk of failure [START_REF] Brodie | DARWIN: On the Incremental Migration of Legacy Information Systems[END_REF].  The "Forward migration" method [START_REF] Brodie | DARWIN: On the Incremental Migration of Legacy Information Systems[END_REF] focuses on the data. Incrementally, developers first migrate the data, then the software product, and the HMIs. Gateways are developed to link the old software product to the data in the new environment. However, gateways can be difficult to handle and make the migration more complex as the number of gateways increases.

 "Reverse migration" method [START_REF] Brodie | DARWIN: On the Incremental Migration of Legacy Information Systems[END_REF] focuses on the software product. The migration is done gradually while data stays in the previous environment. Data migration is the last step of the method. Gateways (reversed) are also implemented between the new and the old environment.  The "Chicken Little Methodology" [START_REF] Brodie | DARWIN: On the Incremental Migration of Legacy Information Systems[END_REF] is incremental and iterative, the software products evolve continuously. Three types of software products are distinguished: those with a decomposable structure where the interface, the application and the data are independent components. The semi-decomposable structure comprises application and data that are not independent, and then more difficult to migrate. Finally, non-decomposable structures do not provide any independent components. Many gateways are defined between the old and new environments which make the method complex and hard to enact technically.

 The "Butterfly" method [START_REF] Bing | The Butterfly Methodology: a gateway-free approach for migrating legacy information systems[END_REF] was proposed to avoid the gateways problem in a six steps method: prepare migration, understand legacy code, prepare data migration, incrementally migrate the components, incrementally migrate data and finalize new system. Each phase is independent and decomposed in subtasks.  The SOMA (Service-Oriented Modeling and Architecture) method [START_REF] Arsanjani | SOMA: a method for developing service-oriented solutions[END_REF] allows migrating legacy systems to a SOA environment. SOA architecture is made for large systems, the SOMA method is then quite heavy to implement for SME.

These methods are very specific and difficult to implement in SME as they require budget and the participation of business experts as technical experts. Some of them are complex to handle and require specific knowledge that most developers do not hold. Moreover, once the migration is completed, part the knowledge disappears as it is not capitalized during the migration project itself: none of the method is concerned with knowledge capitalization. Finally, the paradigm shift issue is often left aside [START_REF] Pastor | Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling[END_REF] although it is a complex problem.

The proposed approach in this paper allows precisely to capture and organize this knowledge through a dictionary as transformation rules. Thus, a company with a certain technology and wishing to migrate its software products to a new technology will gain efficiency on each new migration. Finally, FASMM aims to be accessible to any team of developers with basic knowledge in the field of modeling.

V. CONCLUSION AND PERSPECTIVES Actual migration methods are not adapted to SME because they lack resources to learn and apply the existing software migration methods properly. FASMM was developed in the framework of a migration project in a French company to guide developers during a software product migration, based on the concepts of Model Driven Engineering and knowledge capitalization: models are defined and transformed to get the migrated functionality, using transformation rules stored in a dictionary that can be reused and enriched projects after projects. The method was evaluated with a couple of subjects and results are promising.

Processes in FASMM are specified as a map [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] which allows flexibility in its enactment, as the developers can carry out functionality migration and knowledge capitalization at the same time. Some sections are refined as maps themselves; developers can then follow the process according to their knowledge, ways of working or needs. Being based on Model Driven Engineering techniques, FASMM allows developers to represent the functionalities to migrate as functional and technical models. This facilitates their understanding of the functionality and therefore eases the migration itself. Developers validate the migrated functionality and the produced models represent the code in an efficient and complete way.

There are still many challenges to tackle to complete the proposed method for software migration. First, FASMM should consider the migration of the data which is a problem of software migration. Functionalities are migrated one by one but the method has to propose how to deal with the data between the source and the target software product: is the data migrated first? Does the structure of the data also changes? So does the database technology? FASMM should be improved to properly take into account the paradigm shift. There are migrations within the same programming paradigm, Java to JavaScript in the Object Oriented paradigm for example. Other paradigms as imperative, functional or logical programming should be supported by the method. As FASMM is based on Object Oriented modelling, we then raise the following question: what would be the best fitted metamodels to support the modelling of the functionalities and their transformations? New types of artifacts have to be introduced to accurately support the migration.

We have to test and validate the method in other software migration projects. It is necessary to evaluate the understanding of the method, its ease of use, and then, to enhance it according to the obtained feed-back.

Rules that can be applied automatically have to be systematically described in a transformation language (ATL [START_REF]Atlas Transformation Language[END_REF], QVT [START_REF] Omg | Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification[END_REF] or another, according to the knowledge of the developer) to accelerate the migration of the functionalities and to ensure the quality of the migrated functionality.

Finally, we could also represent FASSM as method components to describe precisely the process of each section of the map and the corresponding products to ease the guidance of developers -as one of the answers to the evaluation. Adopting a Situational Method Engineering approach, we could build a component base to store FASMM components, to improve the knowledge on migration methods by adding new components that could be alternative or complementary to FASMM.

Fig. 1 .

 1 Fig. 1. FASMM presented as a map.

Fig. 2 .

 2 Fig. 2. Simple technical model defined as a class diagram.

Fig. 3 .

 3 Fig. 3. Code in JavaScript after applying the transformation rule "Emulation of an interface in JavaScript".

Fig. 4 .

 4 Fig. 4. Refined map of the section <Start, Get model, By reverse engineering>.

Fig. 5 .

 5 Fig. 5. Refined map of the section <Get model, Get model, By identifying reusable part>.

Fig. 6 .

 6 Fig. 6. Refined map of the section <Get model, Get model, by identifying unsatisfying part>.

Fig. 7 .

 7 Fig. 7. Refined map of the section <Get model, Migrate functionality, by semi-automatic strategy>. The semi-automatic strategy is divided into two separate paths. The developers can simply execute Model to Text (M2T) transformations or create complex automated transformations as Model to Model (M2M) and M2T.

Fig. 8 .

 8 Fig. 8. Refined map of the section <Get model, Migrate functionality, by manual strategy>. Developers are required to recode manually the functionality. It is initially advised to generate the source code skeleton using a M2T transformation and to manually fill the classes by model conformance. Developers have to code what cannot be directly transformed (HMI, architecture incompatibilities, differences between programming paradigms...) by legacy code inspiration.

Fig. 9 .

 9 Fig. 9. Refined map of the section <Discover transformation rule, Enrich dictionary, by creation>.

Fig. 10 .

 10 Fig. 10. Refined map of the section <Discover transformation rule, Enrich dictionary, by correction>.

Fig. 11 .

 11 Fig. 11. Refined map of the section <Discover transformation rule, Enrich dictionary, by invalidation>.

TABLE I

 I

	.	EXAMPLE OF A TRANSFORMATION RULE
	Title	Emulation of an interface in JavaScript
	Source Technology	Java
	Target technology	JavaScript
	Categories	Interface
	Application case	An interface can be seen as an abstract class
		with all its methods as abstracts. As the main
		purpose of an interface is to force the
		implementation of the methods it defines, we
		can simulate an interface by implementing a
		class with all its methods throwing exceptions.
		Thus, classes that implement the interface
		without defining the methods thereof hinder an
		error.
	Description	Java Interface → JavaScript Class (Method → Method throwing exception)*
	Status	Active
	Author	L.F.

TABLE I .

 I presents an example of a transformation rule to emulate Interfaces in JavaScript from Java.

TABLE II .

 II INPUTS AND OUTPUTS OF THE METHOD

	Source	Target intention	Inputs	Outputs
	Intention
	Start	Get model	Existing code,	Technical
			existing models,	models, textual
			users and business	use case and use
			practitionners	case diagram of
			knowledge	the functionality
				to migrate
	Get model	Get model	Technical models,	Refined and
			textual use case and	validated models
			use case diagram of	of the
			the functionality to	functionality to
			migrate	migrate
	Get model	Migrate	Refined and	Migrated
		functionality	validated models of	functionality
			the functionality to
			migrate
			Dictionary of
			transformation rules
	Migrate	Validate	Migrated	Validated
	functionality		functionality	functionality
	Start	Discover	Developers	Transformation
		transformation	experience in source	rule
		rule	and target technology
	Get model	Discover	Tehnical models	Transformation
		transformation		rule
		rule
	Discover	Enrich dictionary	Transformation rule	Enriched
	transformation rule		Dictionary of tranformation rules	dictionary of tranformation rules
	Enrich	Enrich dictionary	Dictionary of	Structured
	dictionary		tranformation rules	dictionary
	Validate	Stop	Validated	Upgraded
			functionality	version of the
				application
	Enrich	Stop	Structured dictionary	Completed
	dictionary			dictionary


Ghazaleh Khodabandelou
email: ghazaleh.khodabandelou@malix.univ-paris1.frcharlotte.hug

Charlotte Hug

Rebecca Deneckère

Camille Salinesi
email: camille.salinesi@univ-paris1.fr

Supervised vs. Unsupervised Learning for Intentional Process Model Discovery

Keywords: Supervised Learning, Unsupervised Learning, Intentional Process Modeling, Hidden Markov Models

Learning humans' behavior from activity logs requires choosing an adequate machine learning technique regarding the situation at hand. This choice impacts significantly results reliability. In this paper, Hidden Markov Models (HMMs) are used to build intentional process models (Maps) from activity logs. Since HMMs parameters require to be learned, the main contribution of this paper is to compare supervised and unsupervised learning approaches of HMMs. After a theoretical comparison of both approaches, they are applied on two controlled experiments to compare the Maps thereby obtained. The results demonstrate using supervised learning leads to a poor performance because it imposes binding conditions in terms of data labeling, introduces inherent humans' biases, provides unreliable results in the absence of ground truth, etc. Instead, unsupervised learning obtains efficient Maps with a higher performance and lower humans' effort.

Introduction

Fueled by the impressive growth of events logs in organizations, process mining field has emerged a few years ago as a key approach to design processes [START_REF] Cook | Discovering models of software processes from event-based data[END_REF][START_REF] Van Der Aalst | Process mining: discovery, conformance and enhancement of business processes[END_REF]. Mining processes from logs can be useful for understanding how humans really work, analyzing how actual processes differ from the prescribed ones (conformance checking). This allows improving models, methods and products.

Whereas most process mining approaches specify behaviors in terms of sequences of tasks and branching [START_REF] Van Der Aalst | Process mining: discovery, conformance and enhancement of business processes[END_REF], research on method engineering and guidance shows that an explicit use of intentions in process models structure could effectively mitigate the method engineering issues such as rigidity or lack of adaptation [START_REF] Mirbel | Situational method engineering: combining assembly-based and roadmap-driven approaches[END_REF][START_REF] Jarke | Establishing visions in context: towards a model of requirements processes[END_REF][START_REF] Rolland | Modeling goals and reasoning with them[END_REF][START_REF] Plihon | Modelling ways-of-working[END_REF][START_REF] Rolland | A multi-model view of process modelling[END_REF].

Intention-oriented process modeling emerged at the early 90s, as a driving paradigm. It allows supporting guidance [START_REF] Rolland | Modeling the requirements engineering process[END_REF], handling traceability matters [START_REF] Jarke | Establishing visions in context: towards a model of requirements processes[END_REF], guiding requirements elicitation, surveying strategic alignment [START_REF] Thevenet | Aligning is to organization's strategy: the instal method[END_REF], defining actors and roles, specifying the outcome of business process models [START_REF] Salinesi | Fitting business models to system functionality exploring the fitness relationship[END_REF], describing intentional services [START_REF] Rolland | An intentional approach to service engineering[END_REF], diagnosing use cases, analyzing users behavior, customizing methods or make them more flexible [START_REF] Mirbel | Situational method engineering: combining assembly-based and roadmap-driven approaches[END_REF], etc. Defining strategies and intentions in process model structure has convinced as a robust mean to identify and analyze the relationships between processes, to understand the deep nature of processes, and to visualize any process (simple or complex) under a reduced and human-understandable form [START_REF] Rolland | Modeling goals and reasoning with them[END_REF]. While intention-oriented process modeling has a longer tradition, it has largely neglected event logs so far. Map Miner Method (MMM) is a novel approach of process mining, which aims at constructing intentional process models from users' event logs. As a first step, the MMM framework uses Hidden Markov Models (HMMs) [START_REF] Rabiner | A tutorial on hidden markov models and selected applications in speech recognition[END_REF] to estimate users' strategies. Then, it generates intentional process models (Maps [START_REF] Rolland | Modeling goals and reasoning with them[END_REF]) using Deep Miner and Map Miner algorithms [START_REF] Khodabandelou | Unsupervised discovery of intentional process models from event logs[END_REF]. This paper focuses on the first part of MMM: estimating users' strategies. These strategies can be estimated either with supervised learning or with unsupervised learning. While Supervised learning can be used when there is a priori knowledge about strategies in dataset, unsupervised learning can be used when there is no such knowledge available. Both learning approaches aim at characterizing the strategies that correspond the best to the users' activities in the event logs. These strategies will then be used to construct intentional process models. Thus, the choice of learning approach significantly impacts the discovered model accuracy. Hence, it is important to study limitations, advantages and conditions of use for these learning approaches. The contribution of this paper is twofold: (i) first, in a theoretical context, it compares supervised and unsupervised learning of strategies in terms of convergence speed (complexity) and likelihood; and (ii) second, in an experimental context, it compares the intentional process models obtained with both learning approaches. The resulting Map process models provide a precious understanding of these approaches in terms of their performance as well as their conditions of use. Figure 1 depicts an overview of MMM framework, in which the focus of this paper is shown in the part of estimating users' strategies.

The remainder of this paper is organized as follows: in Section 2, we introduce the MMM and a brief definition of Map process models. In Section 3, supervised and unsupervised learning are described and then formally compared. In Section 4, both approaches are applied on two real datasets. Section 4.3 discusses the results of both approaches as well as the threats to validity. Related works are investigated in Section 5. Finally, Section 6 concludes this work and presents the perspectives.

Map Miner Method

MMM automatically constructs intentional process model from users' event logs. MMM consists of three phases: (1) it estimates users' strategies from activity logs using HMMs, (2) it constructs fine-grained Map process models from estimated strategies using Deep Miner algorithm [START_REF] Cook | Discovering models of software processes from event-based data[END_REF], and (3) it constructs coarse-grained Map process models from fine-grained ones using Map Miner algorithm (2) (figure 1). As mentioned earlier, this paper concentrates only on the first phase of MMM, i.e., estimating users' strategies with the Map formalism. Among other intentional process models such as KAOS [START_REF] Dardenne | Goal-directed requirements acquisition[END_REF] or I* [START_REF] Yu | Modelling strategic relationships for process reengineering[END_REF], we chose the Map formalism for several reasons: (a) it combines intentions and strategies at different abstraction levels, which allows handling large-scale and complex processes [START_REF] Rolland | Modeling goals and reasoning with them[END_REF], (b) it supports process variability and flexibility by defining different strategies to fulfill a given intention, and (c) it has proven to be effective to specify business processes, user requirements, systems functionality, engineering methods, software engineering processes, etc [START_REF] Rolland | A multi-model view of process modelling[END_REF]. Next parts explain briefly the Map metamodel and how HMMs can be adapted to it.

The Map Metamodel

The Map formalism [START_REF] Rolland | A multi-model view of process modelling[END_REF] combines the concepts of intention and strategy with hierarchical abstraction levels and refinement links. In this framework, an intention is defined as a goal, an objective or a motivation to achieve with clear-cut criteria of satisfaction, which can be fulfilled by enacting a process [START_REF] Soffer | Combining intention-oriented and state-based process modeling[END_REF]. The intentions are explicitly represented and form the high-level goals (e.g., organizational goals). A Map process model (an instance of Map metamodel) specifies the multiple ways of working (i.e., strategies) for fulfilling a set of intentions during the enactment of a process. For example, on figure 2, one way to fulfill the intention Specify an entity is to select the strategy S 4 : By generalization. In the next section, we explain how strategies can be linked to the activities logs.

Specify an entity

Start

Estimating Strategies from Activity Logs

Among the techniques to model different aspects of humans' behavior [START_REF] Gray | The precis of project ernestine or an overview of a validation of goms[END_REF], HMMs have been proven to be appropriate for modeling the real world process, particularly unobservable cognitive states [START_REF] Hayashi | Hidden markov models to identify pilot instrument scanning and attention patterns[END_REF], such as underlying users' strategies. HMMs are stochastic Markov chains used for modeling a hidden sequence by a finite number of states. More precisely, HMMs consist of two complementary Markov processes: hidden and observed processes, such that the states of hidden process generate the symbol of observed process. It turns out that the topology of HMMs is particularly adapted to model the relation between strategies and activities in the Map formalism. To make it clear, let us consider an example for a Map process model enacted with 2 strategies and an HMM realized with 2 hidden states (see figure 3). As shown this figure, strategies are used to move from one intention to another and are made of one or several activities. For instance, the strategy 1 allows moving from intention a to intention b and it is made of activities a 1 , a 3 and a 4 . The same structure can be found in an HMM, where hidden states generate observations. In other words, hidden state 1 generates the observations a 1 , a 3 and a 4 , or hidden state 2 generates the observations a 4 and a 7 . This similar topology motivates using HMMs to model activity logs and users' strategies. Formally, the definition of an HMM is the tuple: H ✏ tS, A, E, T, π✉, where S is the set of possible hidden states, A represents the set of possible observations, T is the states transition matrix, i.e., the matrix which represents the probabilities of transition from one state to another, E is the observations emission matrix, i.e., the matrix which represents the probabilities that a given observation appears in a given hidden state, and π is the vector made of the initial probabilities of hidden states. In the MMM framework, the users' strategies are modeled by the hidden process and the users' activities are modeled by the observed process.

Hidden Process: Users' Strategies. Let s ✏ ♣s 1 , . . . , s L q P S L be a temporal sequence of users' strategies of length L. The hidden process of strategies is parametrized by the vector π, π♣uq ✏ Pr ♣s 1 ✏ uq ❅u P S and the matrix T such that:

T♣u, vq ✏ Pr ♣s ℓ ✏ v⑤s ℓ✁1 ✏ uq ❅u, v P S, ℓ P r2, Ls, (1)
Observed Process: Users' Activities. Let a ✏ ♣a 1 , . . . , a L q P A L be a temporal sequence of users' activities of length L. The emission probability of an observation a P A for a given strategy u P S is given by: E♣a, uq ✏ Pr ♣a⑤uq .

(

) 2
Assuming that S, A and π are known, the HMM model is fully described by tE, T✉, which represent the core information about the HMM behavior. These two matrices provide all the necessary information to characterize the strategies of the Map. Indeed E gives the relation between each strategy and the activities in the event logs, and T gives the transition probabilities between strategies. These two matrices have to be learned from the logs and the choice of the learning approach is crucial to ensure that the strategies are correctly characterized.

Learning Approaches to Estimate Users' Strategies

As discussed in section 2, the characterization of the strategies of the Map completely relies on the model parameters of the HMM, i.e., the emission matrix E and the transition matrix T. The learning problem is to find E and T that maximize the probability of generating the observed sequences of activities. There are two learning approaches for estimating these matrices: Supervised or Unsupervised learning. this section discusses in a theoretical context the necessary conditions for using both approaches as well as their respective performances.

Supervised Learning

Supervised learning aims at learning E and T. However, the conditions under which it can be used are very restrictive and the results might be biased.

Conditions of Use. The application of this method requires the knowledge of: (a) the sets A and S, and (b) some sequences of activities a 1 , . . . , a N and their associated sequences of strategies s 1 , . . . , s N . While the knowledge of A and a 1 , . . . , a N is generally not an issue (the possible activities of a given process are usually known and are recorded in traces), the knowledge of S and s 1 , . . . , s N is more problematic. Indeed, since strategies are the cognitive operators, the usual way to obtain the set S is to refer to experts. Since humans' judgment is involved, the obtained set S can be biased. We argue that in a cognitive context such as a humans' strategy and intention, it is impossible to properly label the training data, because this information is not observable. Moreover, humans' bias [START_REF] Tversky | Judgment under uncertainty: Heuristics and biases[END_REF] is unavoidably introduced into training data labeling, which significantly impacts the learning process and may produce incorrect or uninformative process models. Moreover, strategies are usually not recorded in traces [START_REF] Khodabandelou | Supervised intentional process models discovery using hidden markov models[END_REF]. Applying this learning method implies to conduct experiments specially designed to record traces of activities and traces of strategies. This condition highly restricts the range of use of this method in large-scale.

Performance. Given N sequences of activities a 1 , . . . , a N and their associated N sequences of strategies s 1 , . . . , s N , the aim of supervised learning is to find the couple ♣E ✝ , T ✝ q which maximizes the likelihood of generating a 1 , . . . , a N and s 1 , . . . , s N :

♣E ✝ , T ✝ q ✏ arg max E,T N ➵ n✏1 Pr ♣a n ⑤s n , E, Tq (3)
Obtaining the coefficient of T ✝ amounts in counting the number of transitions from one strategy to another and obtaining the coefficients of E ✝ amounts to count the number of occurrences of each activity during each strategy, as shown below:

T ✝ ♣u, vq ✏ Num♣u, vq ➦ wS Num♣u, wq , ❅♣u, vq P S 2 , (4)
E ✝ ♣u, aq ✏ Num♣a⑤uq Num♣aq , ❅u P S, ❅v P A, (5)
where Num♣u, vq denotes the number of transitions from strategy u to strategy v in the traces s 1 , . . . , s N , Num♣aq denotes the number of occurrences of activity a in a 1 , . . . , a N and Num♣a⑤uq denotes the number of occurrences of activity a while the strategy is u, in s 1 , . . . , s N and a 1 , . . . , a N . The computation complexity of this method is very low since all the coefficients of E ✝ and T ✝ can be directly computed from the traces used for learning with (4) and [START_REF] Rolland | Modeling goals and reasoning with them[END_REF].

The set of training sequences a 1 , . . . , a N and s 1 , . . . , s N , is extremely important for the accuracy of the estimation of E ✝ and T ✝ . If the set contains few traces, or they are not fully representative of all the traces that can be produced by the process, the HMM model learned out of it might suffer underfitting issues. From a practical point of view, this issue is common since the conditions to get usable training traces are complex (resulting in few usable traces).

Unsupervised Learning

Unsupervised learning estimates the matrices E and T based only on traces of activities. Since there is almost no prior knowledge on the strategies set S, this method is significantly less biased than supervised learning but the associated computational complexity is high.

Conditions of Use. For unsupervised learning, the required knowledge includes the set of activities A, some traces of activities a 1 , . . . , a N and the cardinality of the set ⑤S⑤, i.e. the number of possible strategies. Regarding strategies, neither the set S nor some traces of strategies s 1 , . . . , s N should be known, only the number of possible strategies is required. This parameter can be chosen by experts (e.g. as a way to set the level of complexity of the model) or can be set with techniques such as BIC [START_REF] Burnham | Model selection and multi-model inference: a practical information-theoretic approach[END_REF], which makes a trade-off between the likelihood of the model and its complexity. Similarly to supervised learning, this choice introduces a bias, but given that only the number of strategies is set and not the strategies themselves, this bias is less important. The advantage of unsupervised learning is being applicable on datasets comprising only activities traces.

Performance. The Baum-Welch algorithm (BWA) [START_REF] Baum | A maximization technique occurring in the statistical analysis of probabilistic functions of markov chains[END_REF] is the most commonly used in HMMs framework to estimate the model parameters E and T. It uses the Expectation Maximization (EM) algorithm [START_REF] Dempster | Maximum likelihood from incomplete data via the em algorithm[END_REF]. The aim of the EM algorithm is estimating the maximum a posteriori of the statistical model (with latent variable) parameters in an iterative way. Given a dataset made of N observed sequences of activities a 1 , . . . , a N , the BWA finds the HMM matrices Ẽ and T that locally maximize the probability of having these sequences generated by the HMM. More precisely, the BWA maximizes the likelihood of E and T:

✁ Ẽ, T✠ ✏ arg max E,T N ➵ n✏1 Pr ♣a n ⑤E, Tq (6)
As we mentioned earlier, the number of strategies is required to know the dimensions of matrices Ẽ and T since the BWA could not run without Ẽ and T being initialized.

What is interesting to note here is the fact the likelihood is not maximized depending on some traces of strategies s 1 , . . . , s N , as it was the case for supervised learning. It means that the space in which the likelihood is maximized is larger than the space for supervised learning. As a consequence, max

E,T N ➵ n✏1 Pr ♣a n ⑤E, Tq ➙ max E,T N ➵ n✏1 Pr ♣a n ⑤s n , E, Tq . (7)
In other words, the maximum likelihood obtained by unsupervised learning is always higher than the maximum likelihood obtained by supervised learning since the latter comes from a constrained space. Unfortunately, the BWA cannot be guaranteed to converge to the global maximum likelihood since it is only proved to converge to a local optimum [START_REF] Rabiner | A tutorial on hidden markov models and selected applications in speech recognition[END_REF]. The limit of convergence depends on the initialization of the matrices T and E and it is verified by our experimental results (see section 4), that a simple initialization of T and E leads to a maximum likelihood of unsupervised learning higher than supervised learning.

Another difference with supervised learning is the computational complexity. While the complexity of supervised learning is very low, the BWA requires several iterations to converge to a local optimum. These iterations make unsupervised learning a more expensive method than supervised learning. The precise computation of both methods, applied on tow experiments, are given in section 4.3.

Summary of the Two Learning Approaches

In table 1, we present a theoretical comparison of the two learning approaches, based on the properties defined in sections 3.1 and 3.2. Regarding the conditions of use, unsupervised learning can be applied on any dataset comprising traces of activities, contrary to supervised learning which can be applied under more restrictive conditions. This makes unsupervised learning the most convenient method for a practical use. However, since unsupervised learning is only proved to converge to a local maximum, it is not guaranteed to provide an estimated model with a better likelihood than supervised learning. In order to investigate about this point, we compare both approaches on the same datasets in the following section.

Comparison of the Approaches in Experiments

To compare the supervised and unsupervised learning in a experimental context, we conducted two tailored experiments with the Master students of computer science of Sorbonne University: Entity/relationship (E/R) diagrams and E-shopping. Due to lack of space, we only show and analyze in details the strategies obtained for E/R diagrams in the current section. In section 4.3, the results of the two learning approaches for the two experiments are compared in terms of several comparison criteria, such as performance (indicated by the likelihood to generate the activities in the event logs), humans efforts, convergence speed, and computation complexity. Note that the traces used for this comparison have to be compatible with both learning approaches. Indeed, they have to comprise traces of activities and corresponding traces of strategies. Although strategies are generally not accompanied recorded logs, we intentionally asked the students participating in the experiments to label their traces of activities to indicate which strategies they followed. The traces of activities are recorded by a web-based tool.

✌ E-shopping experiment: we guided students through a prescribed intentional process model to buy a present. We recorded 90 traces of activity produced by 90 students for which we know the sequence of selected strategies. The size of each trace varies between 6 and 40 activities. Note that with both learning approaches, all the traces are used for training.

✌ The Entity/Relationship diagrams experiment: according the intentional process model given by figure 2, 66 students created E/R diagrams. Here again, all the traces are used for training for both learning approaches. Regarding to this model, students can select ten strategies to fulfill three intentions, i.e., Specify an entity, Specify an association and Stop. From Start, it is possible to progress in the process by selecting strategies leading to the intentions but once the intention of Stop is achieved, the enactment of the process finishes.

To fulfill an intention following a strategy, students have to carry out activities.

There are 12 unique activities related to the process. Table 3 gives the name of the strategies, related activities and the corresponding labels. The size of each trace varies between 3 and 68 performed activities.

☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎ ☎
Table 2. A fragment of some event Log of E/R diagrams experiment an activity, with its corresponding labeled strategy, its timestamps, the trace ID, and the ID of the user who performed the activity. A trace of activities is the ordered (by timestamps) sequence of activities that a user performed. In sections 4.1 and 4.2, the MMM is applied on this dataset with both supervised and unsupervised learning and strategies and associated Maps are discussed.

Supervised Learning for MMM

First, we apply supervised learning on activities traces, to estimate the strategies, as explained in section 2. Since, we had the advantage of setting up the experiments, we were able to record students' strategies sequences in addition to their activity sequences (labeling the activities). This allows estimating the strategies by supervised learning. The inputs of the algorithm are the activities traces and their related strategies. The matrices E and T can then be computed, and provide the relation between strategies and activities and the transition probabilities between strategies, respectively. Since the learning was supervised, the relations between the strategies and the activities are in line with table 3. However, the transitions between strategies indicate that these latter have not been followed exactly as they were prescribed. By successively applying the Deep Miner algorithm and the Map Miner algorithm to the transition matrix T, we extract a Map which emphasizes this phenomenon. This Map is displayed in figure 4. Therefore, it is possible to detect students' deviations from the prescribed Map. In particular, S 4 is never taken by students and S 7 is chosen in the wrong section. Regarding the strategies S 1 and S 2 , they have selected by students from intention Specify an association to intention Specify an entity. This is not shown in the prescribed Map. However, these transitions are not surprising since they are allowed by the intrinsic semantic of the Map process model. Indeed, a given user can return to an intention already fulfilled to start another section.

Specify an entity

Start

Unsupervised Learning for MMM

By applying unsupervised learning on the activities traces, we discover a different set of strategies and a different Map process model. We recall that in this case, no strategies sequences are necessary as inputs to run the learning algorithm. Consequently, only the traces of activities are necessary used. the discovered strategies are detailed in table 4. In particular, from the emission matrix E, we obtain the relation between strategies and activities. Contrary to supervised learning, since no prior information about strategies is available, the names of strategies and intentions are not known. However, based on the names of activities, it is possible to discover the main topics of the strategies. Through a semantic analysis the strategies name can be inferred. As for supervised learning, a Map can be extracted from the estimated transition matrix T, it is displayed in figure 5. Except Start and Stop, two intentions denoted by I ✶ 2 and I ✶ 3 are inferred. The comparison of this Map with the one obtained from supervised learning is made in the next section.

Discussion and Threats to Validity

It is interesting to discuss the results obtained in previous sections from both quantitative (models likelihood, algorithm convergence, complexity) and qualitative (models interpretation) points of view.

✌ Adopting a qualitative point of view, for the E/R diagrams experiment, although some strategies from the prescribed Map and the Map obtained by unsupervised learning are similar (S 1 and S ✶ 1 , S 2 and S ✶ 2 , S 10 and S ✶ 10 , S 7 and S ✶ 7 ), most strategies from unsupervised learning cannot be exactly identified to prescribed strategies. It is not due to a poor compliance of the Map obtained by unsupervised learning but due to the supervised learning assumption, i.e. the prescribed Map is actually followed by students. This assumption is not true. Indeed, during the enactment of the process, students may deliberately or accidentally not follow the prescribed Map. Consequently, assuming that the prescribed model is followed by students creates a bias in the definition of strategies and intentions. In addition, there is no ground truth for labeling the activities sequences. Con-sequently, the labeling could be flawed as it is a subjective process. Moreover, assigning the labels to the strategies and intentions constrains the discovered Map to a limited space which leads to poor performance of supervised learning. This phenomenon can be verified with the deviations of students detected by obtained Maps. Whereas the Map obtained by supervised learning detected only two deviations (S 4 and S 7 ), the Map obtained by unsupervised learning detected five deviations which are not the same as the supervised learning ones

(S ✶ 1 , S ✶ 4 , S ✶ 8 , S ✶ 9 , S ✶ 10 ).
✌ The log-likelihood of the strategies estimated by unsupervised learning in both experiments is higher than supervised learning (see table 5). In other words, the strategies estimated by unsupervised learning have a higher chance to generate the activities observed in the event logs. It makes unsupervised learning more trustworthy than supervised learning. Note that this result is in line with the theoretical study performed in section 3. ✌ From a cost-benefit and human-centric point of view, cognitive tasks are timeconsuming and labor intensive. Since the methodology of labeling activities cannot be generalized to common event logs, this is one serious drawback for supervised learning. Thus, the cost of labeling the data for supervised learning approach is quite high as it involves the students' commitment to label and comment their activities at each step of the process. In comparison, the only humans' effort for unsupervised learning is to choose the number of strategies for the intentional process model. Nevertheless, the unsupervised learning requires a minimal humans' intervention and it allows obtaining intentional process models that match the actual enacted process. The drawbacks of unsupervised learning are a higher computation complexity and the need to automate the naming of obtained strategies and intentions.

✌ The BWA cannot be guaranteed to converge to the global maximum likelihood (see section 3.2). The convergence depends on the initialization of the matrices T and E and it converges at 9, 986 learning iterations for E/R diagrams and at 4, 325 learning iterations for E-shopping. The supervised algorithm converges in the first iteration.

✌ While the complexity of the BWA is high due to its requirement to several iterations until the convergence to a local optimum, complexity of supervised learning is very low. Table 5 presents a summary of both learning approaches for tow experiments.

Related Work

To the best of our knowledge, there is no work comparing supervised and unsupervised learning for process model discovery from event logs. For this reason we position our work with respect to process mining techniques. Process mining approaches propose to model users' behaviors in terms of activities [START_REF] Van Der Aalst | Process mining: discovery, conformance and enhancement of business processes[END_REF]. These techniques aim at recovering the original workflow from event logs, which containing the traces of processes enactments. Process mining approaches use different algorithms and techniques, such as classification and learning techniques to extract the information from event logs [START_REF] Witten | Data Mining: Practical machine learning tools and techniques[END_REF][START_REF] Rozinat | Evaluating the quality of discovered process models[END_REF][START_REF] Herbst | Integrating machine learning and workflow management to support acquisition and adaptation of workflow models[END_REF][START_REF] De Medeiros | Genetic process mining[END_REF]. Some of these techniques are investigated hereafter.

Inference methods infer process models with a tradeoff between accuracy and noise robustness. Cook compares in [START_REF] Cook | Automating process discovery through event-data analysis[END_REF] three inference algorithms of RNet [START_REF] Das | A unified gradient-descent/clustering architecture for finite state machine induction[END_REF], Ktail [START_REF] Biermann | On the synthesis of finite-state machines from samples of their behavior[END_REF] and Markov models [START_REF] Baum | Statistical inference for probabilistic functions of finite state markov chains[END_REF] for process discovery. The latter two are considered as the most promising approaches. Genetic algorithm [START_REF] De Medeiros | Genetic process mining[END_REF] provides process models (Petri nets) built on causal matrix, i.e., input and output dependencies for each activity. This technique tackles problems such as noise, incomplete data, non-free-choice constructs, hidden activities, concurrency, and duplicate activities. Nevertheless, it requires the configuration of many parameters to deal with noise and irrelevant data, which is a complex task. Directed acyclic graphs [START_REF] Agrawal | Mining process models from workflow logs[END_REF] proposes to transform the events into dependency graphs or workflow graphs using directed acyclic graph, representing events and their causal relations without loop. However, using this kind of graphs to model the processes is delicate as loops exist in process models. To tackle this challenge, this approach tries to count the tasks frequencies and then fold the graph. Nevertheless, the results are partially satisfying and the model does not completely fit the actual process. However, all these approaches neglect the underlying humans' cognitive operators such as users' strategies and intentions. In process mining field, HMMs are used in context of inductive workflow acquisition [START_REF] Herbst | Integrating machine learning and workflow management to support acquisition and adaptation of workflow models[END_REF] to model a workflow or in [START_REF] Rozinat | Evaluating the quality of discovered process models[END_REF] as a conformance checking technique. Each state of HMMs corresponds to a task node. The event logs can be observed and generated into workflow nets by inductive learning. This approach supports appearing the same tasks at several times in the model (duplicate tasks). It is similar to the approach of directed acyclic graphs [START_REF] Agrawal | Mining process models from workflow logs[END_REF] due to the presence of the splits and joins in the transformation step. However, the works using HMMs do not consider the hidden states as the cognitive states such as intentions/strategies.

Conclusions

In this paper, we have compared the supervised and unsupervised learning approaches, in both theoretical and practical contexts, to understand which approach allows discovering underlying users' strategies optimally. Applied on a real dataset to obtain Map process models, the results demonstrate that several issues hinder the application of supervised learning in modeling humans' cognitive process, such as considerable humans' involvement in terms of data labeling, introducing inherent humans' biases and lack of accurate ground truth. Therefore, we deduce from our study that unsupervised learning offers better results than supervised learning to discover intentional process models (Maps).

Although the MMM automatically discovers the topology of the intentional model, the names of strategies and intentions are still inferred semi-automatically. However, the logical relations between activities, strategies and intentions established in the intentional model could be exploited to build an ontology to fully automate the process of inferring the names of strategies and intentions. In addition, we are developing an ProM [33] plug-in which will allow modeling processes in intentional manner. This provides our community to have a vision of processes from an intentional angle.

Fig. 1 .

 1 Fig. 1. The overview of Map Miner Method

Fig. 2 .

 2 Fig. 2. Map process model for the construction of Entity/Relationship diagrams.

Fig. 3 .

 3 Fig.3. An example for a Map process model enacted with 2 strategies (above) and an HMM realized with 2 hidden states (below)

Fig. 4 .

 4 Fig. 4. Map process model obtained by supervised MMM

Fig. 5 .

 5 Fig. 5. Map process model obtained by unsupervised MMM

Table 1 .

 1 Theoretical comparison of supervised and unsupervised learning

		Traces for	A-priori	Convergence speed	Likelihood	of	the
		learning	knowledge	(complexity)	estimated parameters
	Supervised	Activities,	Set of activities,	Fast (one iteration)	Maximum over a re-
	learning	Strategies	Set of strategies		strained set
	Unsupervised	Activities	Set of activi-	Slow (several iterations) Local maximum
	learning		ties, Number of
			strategies

  Table 2 illustrates a fragment of some event logs of the E/R diagrams experiment. Each row represents

	UserID TraceID Timestamps	StrategyLabel Activities	☎ ☎ ☎
	45	7	31/10/12 14:54:00 1	Create entity	☎ ☎ ☎
	22	1	31/10/12 15:14:00 4	Create generalization link ☎ ☎ ☎
	12	8	31/10/12 14:54:00 7	Create association	☎ ☎ ☎
	45	7	23/10/12 09:41:00 2	Link attribute to entity

Table 3 .

 3 Strategies and related activities

	Labels Name of strategies	Related activities (activities labels)
	S1	By completeness (model) Create entity (a1)
	S2	By completeness (entity) Link attribute to entity (a2)
	S3	By normalization	Delete Link attribute to entity (a6), Delete entity (a5), De-
			fine primary key (a7)
	S4	By generalization	Create entity (a1), Create generalization link (a3)
	S5	By specialization	Create entity (a1), Create specialization link (a4)
	S6	By reference	{Delete link attribute to entity, Create entity, Create associ-
			ation, Link association to entity} (a8), {Create association,
			Link association to entity} (a9)
	S7	By decomposition	{Create association, Link association to entity} (a9)
	S8	By normalization	{Delete association, Delete Link attribute to
			association}(a10)
	S9	By completeness (assoc.) Link attribute to association (a11)
	S10 By completeness (final) Check the model (a12)

Table 4 .

 4 Intentions, Strategies and Activities obtained by unsupervised learning for ER diagrams.

	Intentions Code	Activities	Strategies Topics by MMM	obtained
	Start Ñ I ✶ 2	S ✶ 1	a1 (0.94)	entity, creation, specify
		S ✶ 1	a1 (0.94)	entity, creation, specify
		S ✶ 2	a2 (0.88), a1 (0.09)	attribute, entity, creation
		S ✶ 3	a2 (0.09), a3 (0.13), a4 (0.39), a5 (0.40) entity, delete, creation, specialize
	I ✶ 2	S ✶ 4	a1 (0.11), a2 (0.54), a8 (0.25)	delete, creation, attribute, entity, association
		S ✶ 5	a5 (0.1), a6 (0.63), a7 (0.28)	primary key, creation, entity
		S ✶ 6	a1 (0.15), a2 (0.79)	creation, entity, attribute, link
	I ✶ 2 Ñ I ✶ 3 I ✶ 3 Ñ I ✶ 2 I ✶ 3	S ✶ 8 S ✶ 9 S ✶ 4 S ✶ 7 S ✶ 8 S9 a1 (0.37), a9 (0.19), a11(0.34) a1 (0.09), a2 (0.81), a9 (0.08) a1 (0.37), a9 (0.19), a11 (0.34) a1 (0.11), a2 (0.54), a8 (0.25) a9 (0.83), a10 (0.05), a11♣0.05q a1 (0.09), a2 (0.81), a9 (0.08)	association, entity, link, attribute, creation creation, association, entity, at-tributes delete, creation, attribute, entity, association link, creation, delete, entity, asso-ciation association, entity, link, attribute, creation creation, association, entity, at-tributes
	I ✶ 3 Ñ Stop S ✶ 10	a9 (0.08), a12 (0.87)	check, model, coherent
	I ✶ 2 Ñ Stop S ✶ 10	a9 (0.08), a12 (0.87)	check, model, coherent

Table 5 .

 5 Practical comparison of supervised and unsupervised learning.

	Experiments Learning	Traces for	A-priori	Convergence	The estimated
			learning	knowledge	speed	parameters
					(complex-	Log-likelihood
					ity)
	E/R diagrams	Supervised learning	66 traces of activities,	set of activities, set of strategies	1 iteration	✁2.54e 3
			66 traces of
			strategies
		Unsupervised learning	66 traces of activities	set of activities, number	9, 986 iterations	✁2.36e 3
				of strategies
	E-Shopping	Supervised learning	90 traces of activities,	set of activities, set of strategies	1 iteration	✁2.81e 3
			90 traces of
			strategies
		Unsupervised learning	90 traces of activities	set of activities, number	4, 325 iterations	✁1.69e 3
				of strategies