Keywords: Business Process Modeling, model quality, semantic quality, domain knowledge, domain ontology, quality evaluation, quality improvement Business Process Modeling, model quality, semantic quality, domain knowledge, domain ontology, quality evaluation, quality improvement

This thesis is the result of three years of devoted work which would not have been possible without the support of many. Here, I would like to express my thanks to people who have been very helpful to me during the course of this work.

First of all, I would like to thank my two supervisors, Isabelle Comyn Wattiau and Samira Si Said Cherfi for their patience, guidance, encouragement

Prof. Jacky Akoka, as well as all the group members.

My special gratitude goes to my spervisor Samira Si Said Cherfi. You were more than a supervisor, you were like a mother for me in a foreign country. Because of your patience, I learned how to be rigorous not only in my professional life but also in my personal life. You were always there for me, day, night, and even on weekends. I know that I am so lucky to have you as a supervisor. You are a role model to me both as a researcher and a person. Thank you for everything.

I would like to thank Prof. Geert Poels and Prof. Herve Panetto for accepting to review my dissertation. Also many thanks to Prof. Camille Rosenthal-Sabroux, Dr. Selmin Nurcan and Dr. kathia Oliveira for accepting to be a part of jury to evaluate my work.

There are a numerous people with whom I shared the best moments and to whom I am greatly indebted. Dana Azar, you were more than a friend. Rima Daezli, Zeinab Hmedeh, Amina Souag, Manal khalife, Lydia Khalifa, Ryadh Dahimen, Rodney Medina and Sally El Jam. You turned a hard experience into unforgettable memories.

A special thanks are due to Nesrine Baltahji and Basem Alameddine, without whom I couldn't came to france in the begining.

And finally, to my parents who believed in me and supported me, not only morally but also financially.

To father, Mohamad Ayad. The only purpose of my life is to make you proud of me. Thanks for believing in me.

To mother, Mona El kheir, without her continuous support and encouragement I never would have been able to achieve my goals. This one is for you mom! Introduction Une enquête récente de Gartner de plus de 1400 directeurs de l'information a révélé que la priorité de l'entreprise identifiée par leur compagnie était l'amélioration des processus métier (Camp and DeBlois 2007). Et un des éléments clé de la gestion des processus métier (PM) est de rendre le processus explicite pour différents acteurs par la modélisation de ces processus métier (Sinur and Hill 2010).

Ainsi, les avantages de la modélisation des PM ont été étudier par [START_REF] Havey | Essential Business Process Modeling[END_REF], dont comprennent: a)la formalisation des processus existants, b) la facilitation du flux des processus, c)l'augmentation de la productivité, et enfin d) la simplification de la réglementation et les questions de conformité. L'amélioration de la compréhension, la fiabilité et la réutilisation des modèles de PM exigent qu'on leur confère une certaine qualité. Diverses approches pour l'amélioration de la qualité des modèles de PM ont été proposées dans la littérature. Notre étude nous a permis de les classer en trois catégories :

1)

Les approches centrées sur les méthodes dont l'hypothèse est que l'amélioration du processus de développement soutenu par méthode permettront d'améliorer le résultat de ce processus. Les approches centrées sur les méthodes couvrent toutes les recherches qui proposent des guides méthodologiques et des bonnes pratiques pour assurer la qualité des modèles de PM produits. Dans [START_REF] Becker | Guidelines of Business Process Modeling[END_REF] les auteurs proposent un ensemble de guides pour améliorer certaines caractéristiques telles que l'exactitude, la compréhension etc. des modèles de PM. Une autre approche proposée dans [START_REF] Mendling | On the Usage of Labels and Icons in Business Process Modeling[END_REF]) discute de l'impact d'une bonne documentation, de règles de nommage et d'icônes graphiques adéquates sur l'amélioration de la compréhension et de l'adoption des modèles de PM. D'autres auteurs proposent des motifs de conception réutilisables qui aident à produire des modèles de PM(Van Der [START_REF] Aalst | Business Process Management: A Survey[END_REF].

2) les approches d'évaluation de la qualité des PM : Les approches d'évaluation de la qualité des PM s'intéressent à ces derniers au niveau de leur exécution et de leur contrôle. Dans (Jansenvullers and Netjes 2006) les auteurs présentent plusieurs techniques pour la vérification, la validation et l'amélioration des performances des PM.

3) les approches d'évaluation de la qualité des modèles de PM. Cette évaluation passe souvent par la mesure de la qualité à travers la définition de métriques de qualité. Les approches qui s'inscrivent dans ce courant mentionnent les similitudes entre un processus logiciel et un processus métier. Ils appliquent les métriques logicielles pour évaluer les modèles de processus métier. Dans [START_REF] Aguilar | Applying Software Metrics to evaluate Business Process Models[END_REF]) un ensemble de mesures pour l'évaluation de la maintenabilité des modèles des modèles de PM est défini. L'applicabilité des métriques de qualité dans la gestion des processus métier est étudié dans [START_REF] Cardoso | Process control-flow complexity metric: An empirical validation[END_REF], [START_REF] Mendling | What Makes Process Models Understandable?[END_REF] and ( [START_REF] Van-Belle | Empirical Evaluation and Comparison of Enterprise Models: A Framework and Its Application[END_REF] décrit un cadre permettant l'évaluation et la comparaison des modèles de PM en se basant sur une analyse syntaxique, sémantique et pragmatique. Ils mentionnent cinq des mesures qu'ils considèrent importantes : couplage, cohésion, complexité, modularité, et enfin taille. Dans (Gruhn and Laue, 2006) les auteurs ont présenté un ensemble d'enquêtes où ils ont étudié l'importance de l'exactitude des modèles de PM d'un point de vue empirique. Ils ont défini deux métriques qui quantifient la bonne organisation structurelle (structuredness). Enfin, les auteurs dans (Vanderfeesten et al. 2008) proposent des métriques pour mesurer la cohésion des modèles de PM. En conclusion, nous avons étudié cette catégorie en termes de qualité syntaxique, sémantique et pragmatique qualité emprunté (Lindland et al.

1995)

Mais nous avons constaté certaines lacunes liées à la littérature. En fait,

• Très peu de méthodes fournissent des instructions et des directives pour les défauts de notation. Mais aucune de ces méthodes ne fournissent des instructions correctives pour corriger les défauts sémantiques et pragmatiques.

• D'autre part, la plupart des méthodes ne vérifient pas l'application des normes de notations, ni les outils de modélisation détectent de tels défauts. Par exemple, dans BPMN, l'une des normes de base est que chaque modèle devrait avoir au moins un 'end event', mais aucun des outils de modélisation que nous avons testés, ne détecter un tel défaut.

L'un des principaux obstacles à l'évaluation de la qualité des modèles de processus métier est le manque de mesures de qualité. La plupart des approches d'évaluation existantes se concentrent sur l'évaluation de la qualité syntaxique des modèles de PM: la complexité, la taille, la cohésion, etc.

En outre, il existe des approches pour évaluer le comportement des modèles BP (blocages, manque de synchronisation, etc.). Mais il y a très peu d'approches qui fournissent des méthodes d'évaluation de la qualité pour l'évaluation de la qualité sémantique et pragmatique des modèles.

D'autre part, l'évaluation de la qualité n'est qu'une étape pour améliorer la qualité des modèles de processus métier. La plupart des cadres de qualité se concentrent exclusivement sur la détection des défauts (évaluation de la qualité) et ignorer l'aspect de la correction de défaut (amélioration de la qualité).

La modélisation des PM comme toute activité de modélisation consiste à créer un modèle. Au cours du processus de modélisation, le modeleur est préoccupé par l'identification, l'analyse et la conceptualisation des notions essentielles et les contraintes du domaine d'application. En fait, lorsque les états initiaux et objectifs du modèle sont vaguement définis ou peu claires, et quand il a de multiples solutions et si elle ne contient pas toutes les informations nécessaires à leur solution; par conséquent, il n'est pas clair quelles actions sont nécessaires pour les résoudre, il est un modèle de mauvais structure.

La question de recherche qui se pose est : Comment aider les modélisateurs à améliorer la qualité de leurs modèles de processus?

Etat de l'art

La modélisation est une activité difficile, particulièrement la modélisation des PM.

Et afin d'aider les modélisateurs de PM à améliorer la qualité de leurs modèles, nous avons étudié les problèmes de modélisation.

Nous avons constaté que la maturité des experts de modélisation de processus est faible.

En outre (Coughlan et al. 2003) déclare que l'extraction des exigences nécessite une communication intense pour surmonter tout écart de culture ou des différences sémantiques qui peuvent exister entre les utilisateurs et les développeurs.

En outre, différents chercheurs ont étudié la compréhension d'un schéma conceptuel utilisé dans les premiers stades de développement de systèmes. Les résultats de ces études indiquent que les connaissances de domaine (CD) peuvent compenser un manque de clarté et d'information manquante dans la représentation d'un problème. [START_REF] Antón | The Use of Goals to Surface Requirements for Evolving Systems[END_REF], qui rapportent une étude de terrain visant à identifier les facteurs qui conduisent à des malentendus concernant les exigences conclut que les facteurs dominants que les utilisateurs et les développeurs indiquent notamment la manque de compréhension de l'entreprise et des difficultés liées à la langue et la terminologie commune de développeurs. Ces deux facteurs proviennent de développeurs possédant un bas niveau de CD.

Sur la base de [START_REF] Khatri | Understanding Conceptual Schemas: Exploring the Role of Application and IS Domain Knowledge[END_REF], il y a de deux types de connaissances:

• IS domain knowledge

• Application domain knowledge

Dans le cadre de cette thèse, nous proposons une solution qui capture ces deux types de connaissances.

Par conséquent les modèles de PM sont créés tenant compte, l'exigence de domaine, sous des contraintes spécifiées, en s'appuyant sur les connaissances à la fois du domaine et de la notation utilisée.

La question qui se pose : Comment exploiter les connaissances de domaine afin d'aider les modélisateurs de PM dans leur activité de modélisation?

L'approche propose

Figure 1: Vue d'ensemble de l'approche proposée La modélisation des processus métiers permet notamment de mieux les comprendre pour pouvoir détecter les axes d'amélioration, les redondances, les tâches sans valeur ajoutée, etc. Analyser les modèles sur le seul plan structurel limite considérablement les possibilités d'amélioration. C'est pourquoi, nous proposons de nous appuyer sur des ontologies de domaine pour améliorer la qualité sémantique des modèles de PM. Notre travail comprend le développement d'un prototype qui met en oeuvre la méthode développée, laquelle s'appuie sur des ontologies de domaine, sur des modèles de processus métier et sur une approche de mesure de la qualité. L'expérimentation et la validation des hypothèses de recherche seront faites sur des cas réels.

-La première étape de ce travail est d'abord de définir un métamodèle pour les processus métier et un autre pour les ontologies de domaine afin d'avoir une approche indépendante de la notation.

-La détection des défauts s'appuie sur la découverte de similitudes entre les éléments du modèle de processus et les concepts de l'ontologie de domaine.

-Nous proposons un ensemble de métriques pour mesurer la qualité des processus métier, allant au delà des considérations syntaxiques en intégrant aussi le sens des modèles avec les besoins et exigences du domaine. Ainsi nous visons la définition d'une méthode de conception des processus métier intégrant la dimension de la qualité.

-Nous proposons un ensemble des actions correctives pour assurer aux modélisateurs des corrections pour chaque défaut de qualité détecte par les métriques. Nous proposons de définir un métamodèle pour aligner les modèles avec les concepts du métamodèle.

Deux niveaux de contraints sont définit: générique (valable pour toutes les notations) et des contraintes spécifiques de notation. Il existe aussi de nombreuses associations entre les différents connecteurs et les flux d'objets qui ne sont pas présentés dans ce métamodèle. Mais ils sont définis par les règles OCL qui font partie du métamodèle.

Application domain knowledge

Application domain knowledge fait référence à des problèmes du monde réel. Basé sur (J. Buchan 2009) deux des obstacles les plus importants identifiés sont : la diversité entre les groupes et le manque d'un vocabulaire commun.

-La diversité dans le groupe concerne les différents niveaux de connaissances et des techniques.

-Un manque d'un vocabulaire commun, qui peut être dérivé de CD, peut entraîner des interactions et à la confusion et les malentendus.

Notre solution repose sur l'existence de la connaissance du domaine décrivant une connaissance et un vocabulaire partagé et accepté dans des domaines spécifiques. Cette connaissance est capturée par les moyens d'ontologies de domaine.

Notre objectif est d'utiliser les connaissances de domaine pour aider à l'amélioration d'un modèle de processus métier en cours de construction.

La définition de ces ontologies n'est pas dans notre champ. Ontologies de domaine sont disponibles dans la littérature. On aura un modèle de PM exporté dans un fichier XML ou XPDL, dont on applique la dessus les contraints.

path length [START_REF] Wu | Verbs semantics and lexical selection[END_REF], Purandare & Pedersen context vectors (Purandare and Pedersen, 2004).

4.

Niveau plus général: Cette fonction retourne la liste des concepts de l'ontologie qui représentent un niveau plus général du concept du PM. Ce qui veut dire, il existe une relation de supériorité (également appelé hyperonymes ou IS-relation) entre le concept de processus métier en paramètre d'entrée et les concepts de l'ontologie en retour. En d'autres termes, il renvoie le point d'arrivée (Range) de la relation IS-A.

5.

Niveau plus spécifique: Cette fonction renvoie les concepts de l'ontologie ayant une relation d'infériorité avec un concept de l'ontologie détecté comme synonymes ou syntaxiquement équivalent à l'élément de modèle BP.

6.

Les concepts associés: Cette fonction renvoie un ensemble de concepts de l'ontologie liés aux résultats obtenus par la fonction similitude basée sur le nom ou par la similitude partielle base sur le nom par une relation "temporelle" ou "influence" à une autre ontologie notion.

Mesure et évaluation de la qualité

Nous évaluons la qualité des modèles en termes de syntaxique, sémantique et pragmatique sur la base de Lindland et al. [START_REF] Kaufmann | Understanding quality in conceptual modeling[END_REF]. Qualité sémantique: Concerne le modèle du domaine en considérant non seulement la syntaxe, mais aussi les relations et leur signification entre les assertions.

Il y a deux objectifs sémantiques: la validité et la complétude. La validité signifie que toutes les déclarations faites par le modèle sont correctes et pertinentes au problème, tandis que, la complétude signifie que le modèle contient toutes les déclarations sur le domaine qui sont correctes et pertinentes.

Qualité pragmatique: Concerne la participation du public en tenant compte non seulement la syntaxe et la sémantique, mais comment le public ( toute personne impliquée dans la modélisation ) les interprétera.

Evaluation de la qualité syntaxique

Afin d'évaluer la qualité syntaxique, nous avons identifié un ensemble de mesures de la qualité syntaxique basé sur le métamodèle BP.

Evaluation de la qualité sémantique

Selon Guizzardi et al. (Guizzardi, Ferreira Pires, and Sinderen van 2002) , deux positions de la sémantique d'un modèle doivent être séparés:

En premier lieu, la sémantique comprend les règles d'interprétation automatique d'un modèle, c'est-àdire les concepts sémantiques et son rôle dans le modèle. Deuxièmement, chaque construction de modélisation représente certaines entités du monde réel, ce qui est un autre aspect de la sémantique de modèle et est exprimé par les étiquettes des fonctions et des événements.

Pour évaluer la qualité sémantique, nous avons identifié un ensemble de ce que nous appelons défauts d'expressivité tels que les concepts dépourvus de sens, des représentations ambigus et incomplet. Ces défauts correspondent à des choix de modélisation qui pourraient diminuer l'expressivité des modèles, conduisant à des erreurs dans leur interprétation et leur mise en oeuvre. Ces modèles conduisent à des systèmes inadéquats en raison du caractère incomplet ou à des malentendus au cours de leur mise en oeuvre.

• Défaut de clarté: désigne les ambiguïtés qui conduisent souvent à des erreurs d'interprétation.

Une ambiguïté survient lorsque plusieurs termes dans le modèle sont utilisés pour désigner des concepts distincts alors que, d'après l'ontologie du domaine, ces termes sont identifiés comme synonymes.

• Défaut d'abstraction: caractérise le choix d'un niveau d'abstraction non approprié. En effet, dans certains cas, l'utilisation de concepts généraux au lieu de concepts spécifiques peut créer une confusion et avoir un impact sur l'efficacité de l'exécution du processus. Au contraire, dans d'autres situations, l'utilisation de termes précis peut, lors de l'exécution, empêcher par exemple la substitution de ressources ou la délégation de tâches etc. Le choix pertinent d'un niveau d'abstraction dépend de plusieurs facteurs parmi lesquels nous pouvons mentionner l'usage du modèle de PM (les développeurs ou les utilisateurs), l'objectif du modèle (explication ou mise en oeuvre), etc.

• Défaut de complétude: se produit quand un concept est complexe et quand une partie de ses composantes seulement est représentée dans le modèle. Il est nécessaire de vérifier si la couverture partielle des composants est voulue ou est due à une méconnaissance du domaine du problème.

Mesure des défauts d'expressivité

Nous proposons, en premier lieu, un métrique de qualité permettant de mesurer la clarté sémantique.

La clarté calcule le rapport de 1 au nombre total de synonymes détectés dans l'ontologie. Pour évaluer le niveau d'abstraction, on a définit deux métriques de qualité :

• Généralité: calcule le rapport de 1 au nombre total de hyponymes détectés dans l'ontologie.

Amélioration des défauts d'expressivité

Le processus d'amélioration comprend trois étapes.

1.

La première étape réalise les améliorations dans le but de corriger les défauts captés par l'application des contraintes.

2.

La deuxième étape consiste à étiquette refactoring.

3.

La troisième étape met en oeuvre l'amélioration qui corrige les défauts capturés par l'ontologie.

L'activité d'amélioration de la qualité fournit à l'analyste ou à l'expert qualité un ensemble de directives d'amélioration afin de corriger les défauts. Dans tous les cas, les améliorations sont à confirmer par l'expert.

• Les contraintes sont violées quand un défaut de qualité est capturé. Le but est de résoudre le défauts de qualité liés à la façon dont les concepts sont utilisés dans le modèle c.a.d l'utilisation du concept correctement et la façon dont ce concept est élaboré, ainsi ces contraintes soulignent le problème, mais ne les résout pas. Nous visons à proposer l'amélioration de chacune de ces défauts.

• Refactoring des étiquettes d'activité consiste à catégoriser les étiquettes dans des classes et l'extraction informations de ces étiquettes.

• Base sur les valeurs des métriques de qualité, des défauts de qualité sont détectés. En fait, la qualité sémantique dépend de la connaissance fournie par l'ontologie. De même, les résultats des métriques signalent les problèmes, mais ne les résout pas. Nous visons à proposer des améliorations à chacune de ces défauts.

-Correction des défauts de clarté: consiste à remplacer les concepts synonymes, si cette synonymie est confirmée par l'expert ou l'analyste, par un nom de concept unique. Une fois encore, l'ontologie fournit la liste des synonymes pour aider l'analyste à choisir le terme approprié.

-Correction des défauts d'abstraction: en fonction de la situation, les concepts pourraient être remplacés par d'autres plus génériques si plus de généralité est nécessaire. Cependant, si des descriptions plus détaillées sont nécessaires, le concept général dans le modèle est remplacé par d'autres plus spécifiques.

-Correction des défauts d'incomplétude: l'amélioration de la complétude consiste à s'appuyer sur les connaissances fournies par l'ontologie pour compléter les parties manquantes du modèle. Par exemple, si une ressource manquante est détectée cela devrait conduire à l'ajout de cette ressource et éventuellement du fragment du processus qui la manipule.

6.

Validation L'objectif principal de notre validation est d'évaluer la démarche et de démontrer sa valeur. Nous avons effectué deux expériences pour valider notre approche à différents stades. Ainsi, une première expérience a été effectuée afin de vérifier que les contraintes de qualité définie servent à détecter un grand nombre des défauts de qualité dans l'évaluation des modèles de PM. Cet exercice de validation intermédiaire a été réalisée sur une collection de modèles de processus d'affaires de l'initiative BPM académique ( « Academic Initiative BPM | Signavio » 2013) .

Les principaux objectifs derrière cette première validation étaient les suivants: i. Pour s'assurer que ces contraintes détectent un grand nombre des principaux défauts de qualité ii.

Pour s'assurer que les concepts sont bien utilisés dans le modèle.

iii.

Pour étudier le pourcentage des défauts les plus courants.

Les résultats des expériences ci-dessus nous ont aidé à valider la sélection de nos contraintes de qualité et à corriger l'utilisation des concepts.

Nous avons effectué la deuxième expérience pour valider l'efficacité de notre approche complète.

Nous avons soigneusement sélectionné les répondants de l'expérience de validation de telle sorte que tous les répondants ont une connaissance préalable sur les modèles conceptuels et une certaine expérience de la modélisation.

Les principaux objectifs derrière cette deuxième validation sont les suivantes:

i.

Pour vous assurer que les paramètres de qualité définis sont utiles pour évaluer la qualité des modèles de PM.

ii.

Pour veiller à ce que les connaissances fournies par l'ontologie de domaine peut apporter des améliorations à la modèle.

iii.

Pour étudier les améliorations les plus utilisés.

La deuxième expérience nous a aidés à valider les points forts et les avantages de l'emploi de notre approche pour évaluer et améliorer le modèle de PM. Dans les deux expériences, nous avons utilisé plusieurs graphiques et des tableaux pour analyser les défauts les plus épandage. Nous étions surtout intéressés à la façon de détecter et corriger ces défauts.

Outil

Nous avons conçu et développé un prototype « Business Process Model Quality », qui met en oeuvre notre démarche.

Cependant, le but de l'outil est de permettre l'évaluation et l'amélioration semi automatique des modèles de processus métier.

Il est divisé en deux modules: Le module d'annotation et le module de gestion basée sur la connaissance de la qualité de domaine.

Le module d'annotation où l'expert de la qualité est chargé de définir les mappages Modèlemétamodèle. Le Module de gestion basée sur la connaissance de la qualité où l'expert de la qualité est responsable de la gestion de la qualité en définissant les mesures de qualité, des guides d'amélioration de la qualité, etc. De même , il / elle est également responsable de la gestion des connaissances de domaine en définissant les métamodèles (métamodèle de PM et métamodèle d'ontologie) , la définition des règles de mappage, etc et où le modélisateur est responsable de l'exécution des contraintes , des mesures et des améliorations de qualité .

Les deux modules accèdent une base de connaissances commune. En fait "BPM-quality» contient une base de connaissances pour stocker les règles de notations, les metamodeles de PM et l'ontologie, etc.

En outre, la base de connaissances stocke également les sessions de la qualité des modèles de domaine BP.

Figure 6: Architecture de l'outil

Conclusion

La recherche présentée dans cette thèse est un pas en avant dans l'évaluation sémantique et amélioration de la qualité des PM en se basant sur les connaissances de domaine. Afin de formuler une solution complète, nous avons exploiter les connaissances de la sémantique de notations et de l'ontologie de domaine. L'approche prend en compte la variété des notations des modèles de PM en utilisant un métamodèle. L'ontologie de domaine est représenté par une ontologie où la sémantique est enrichie par l'utilisation de plusieurs types de relations entre les concepts. Le processus d'alignement peut être appliquée à chaque domaine pour lequel il existe une telle ontologie. Il peut très faciliter la tâche des modélisateurs de PM et conduire à une amélioration significative de modèles. L'autre avantage est qu'il encourage la capitalisation des compétences. En effet, dans de nombreux domaines, il y a un effort de définition de la connaissance structurée et partagée dans plusieurs domaines : médical pratiques, les processus RH, E-learning, etc. L'approche proposée est une utilisation réelle de ces connaissances.

La plupart des cadres de qualité existants sur les models de PM proposent des mesures de qualité en s'appuyant sur la structure du modèle. En revanche, nous avons proposé:

-Quinze mesures de la qualité syntaxique: chaque métriques a une valeur de retour qui peut être un booléen ou un nombre entier. Nous avons expliqué chacune de ces mesures par la définition de leur rôle, le défaut détectent et l'analyse de leur valeur de retour.

-Six métriques pour évaluer la qualité sémantiques: tous ces paramètres ont une valeur de retour entière et s'appuient sur l'ontologie de domaine pour être calculé. Mots-clés: modélisation des processus métier, la qualité des modèles, la qualité sémantique, les connaissances de domaine, l'ontologie de domaine, évaluation de la qualité, amélioration de la qualité. 3:A basic meta-model of business modelling concepts (Penker et Eriksson 2000) ................................... Figure 4:EPC Meta-model [START_REF] Seel | Meta-model based extensions of the epc for inter-organisational process modelling[END_REF])................................................................................... Figure 5: UML activity diagram Meta-Model (Havey 2005)................................................................................ Figure 6:Petri net meta-model (Bosilj-Vuksic, Giaglis, et Hlupic 2001) .............................................................. Figure 7: The framework of the Guidelines of Modelling (Becker, Rosemann, et Uthmann 2000b) .................... Figure 8: Lindland and al.'s quality framework (Krogstie, Lindland, et Sindre 1995a) ....................................... Figure 9: Krogstie et al.'s Quality framework (Krogstie, Lindland, et Sindre 1995a).......................................... Figure 10: Concepts in the framework of [START_REF] Moody | What makes a good data model? Evaluating the quality of entity relationship models[END_REF] Figure 34: Annotation Process ........................................................................................................................... Figure 35: BPM annotated ................................................................................................................................. Figure 36: Quality Management Module architecture ....................................................................................... Figure 37: Activity synonyms interface ............................................................................................................... Figure 38: Actor hyponyms interface .................................................................................................................. Figure 39: IS knowledge application interface ................................................................................................... Figure 40: Knowledge base Structure ................................................................................................................ Figure 41: Defect types percentage .................................................................................................................. Figure 48: Input completeness metric variation ................................................................................................. Figure 49: Actor allocation metric variation ...................................................................................................... Figure 50: Model richness metric variation ....................................................................................................... Figure 51: Load interface ................................................................................................................................... Figure 52: constraints interface .......................................................................................................................... Figure 53;. Table 1: Notation 's strengths and drawbacks ....................................................................................................... Table 2: Tools comparison.................................................................................................................................... Table 3: Dimensions of BP quality (Heravizadeh, 2009). ..................................................................................... Table 4: Characteristics, attributes and measures of activity (Heinrich et Paech 2010) ..................................... Table 5 : Quality approaches of conceptual models ............................................................................................. Table 6:FMESP set of metrics (Aguilar et al. 2006) ............................................................................................ Table 7: Possible experimental studies (Soffer, Kaner, et Wand 2012) ................................................................ Table 8: Quality approach comparison ................................................................................................................ Table 9: Workflow defects ..................................................................................................................................... Table 10: Concept alignment ..............................................................................................................................

List of Figures

List of Tables

Chapter 1 Introduction

Business process modelling has been receiving increasing attention from companies as well as the academic community, since it is likely to improve practice and working processes in organizations in the future. Indeed, to keep up and remain competitive, companies must be able to asses the quality of their products and the efficiency of their services. This requires understanding the current system and analyzing the potential benefits of the underlying processes. Using models helps reaching such an objective as they provide an abstract and coherent vision of the business and facilitates understanding and reasoning about alternative solutions to reach an agreement [START_REF] Nurcan | Intention-Driven Modeling for Flexible Workflow Applications[END_REF]. Business process models (BPM) can be realized through methodologies, techniques, or software, in a way that helps organizations bring together processes and their context including people, documents, information sources, organizational structures, and applications [START_REF] Van Herk | Activity Monitoring Buzz or Business[END_REF]. As a methodology, BPM help organizations in gaining control over their business processes by modelling, validating, analyzing, and monitoring the processes.

A business process is a collection of activities that takes one or more kinds of inputs and creates output that is of value to the customer (Hammer 1993).

Domain of the thesis

Business process (BP) modelling is an important tool for understanding and revealing weaknesses of business process [START_REF] Heravizadeh | Dimensions of Business Processes Quality (QoBP)[END_REF]. It is recognized as a key part of the business process lifecycle. It is during the modelling stage that a conceptual model is produced by collecting business process requirements and representing them with a specific business process notation (Sánchez-González et al. 2013). In order to meet customer demands, companies have to design business processes in an appropriate way.

BP modelling is a prerequisite. It is now considered as an engineering activity aiming at providing the actors with a better understanding of the processes in which they are involved. The resulting models serve as concrete tools allowing stakeholders to understand i) how processes work, ii) why they may dysfunction, iii) which software could support them efficiently, and so on.

Business processes influence product quality and customer satisfaction, which are fundamental aspects in a market environment (Sánchez-González et al. 2013), and enterprises are therefore constrained to improve their processes in order to improve products and services [START_REF] Cardoso | Process control-flow complexity metric: An empirical validation[END_REF].

Indeed, it is widely agreed that quality of product depends on the quality of the underlying processes and this is why business process quality is considered as an important issue. Quality problems can inflate system development cost and consume scarce resources, in addition to increasing error detection and correction costs [START_REF] Ravichandran | The dimensions and correlates of systems development quality[END_REF]. Moreover, (Ackoff 1968) found that the existence of defects or deficiencies can hamper IS quality and put its adoption at stake since IS adoption is linked to IS quality, satisfaction, and usage (H. James [START_REF] Nelson | Quality in conceptual modeling: five examples of the state of the art[END_REF].

In recent years research related to modelling and improving business processes has been of growing interest. Thanks to their experience, companies are aware of the undeniable impact of a better tuning of business processes on the effectiveness, consistency and transparency of their business operations. This tuning requires a better understanding and an effective management of BP.

Many research efforts have been devoted to the development of suitable methods and notations for business process modelling. However, to achieve the expected benefits on quality it is necessary to rethink the approach of designing these processes by integrating the quality objectives into design.

Indeed, BP modelling is difficult. As it requires a high level of expertise in modelling and a good understanding of the business domain, the quality of produced models is variable and need to be assessed and improved.

Quality can be defined as the total of properties and characteristics of a product or service that are relevant for satisfying specific and obvious requirements (« ISO 8601 »). Following Boehm and other quality precursors, ISO subdivides quality in a number of quality characteristics such that each one addresses a particular aspect of quality.

The business process modelling approaches share many similarities with conceptual modelling activities, but are much more complex. A business process model is a representation at a very high level of abstraction but it has also to integrate non-functional requirements such as flexibility and maintainability. Modelling these processes requires a high degree of pragmatic expertise: designers refer to a set of mainly empirical rules and heuristics. The latter are difficult to formalize and to share.

In fact, it's too late to identify the defects and deficiencies when the software is already developed, as the maintenance cost of these defects could be enormous and might require major design or architectural modifications. It has been noticed that majority of the IS change-requests result from deficient functionalities in the information systems such as the lack of desired functionalities within a system, etc. However, as mentioned above, these change requests will be expensive to fix when the system is already developed. Studies show that defect detection in the early stages of the application development can be thirty three times more cost effective than testing done at the end of development [START_REF] Walrad | Measurement: The key to application development quality[END_REF].

Therefore, it is imperative to emphasize the need of introducing quality mechanisms at the earlier stages of development such as during analysis and design. It has now been widely agreed that the quality of the end-system depends on the quality of the system's business process model. As a result, different methodologies propose different methods and guidelines to ensure a certain degree of quality to the process models.

The problems addressed during this thesis are discussed in the next section.

Problem statement

In an enterprise, different processes are performed. If the enterprise wants to reach its goal and stay in front in the market, every process has to be evaluated and may be changed to support the goals of the organization. The quality of business processes and business process models have been looked upon in this light in a number of partly uncoordinated works.

Various researches focus on how to produce "good" graphical models. But according to [START_REF] Moody | What Makes a Good Diagram? Improving the Cognitive Effectiveness of Diagrams in IS Development[END_REF], the design of models using a graphical notation is both ad hoc and unscientific. Thus the quality of the model is not limited to the quality of the graphic model but also on the vocabulary used in the model to communicate.

Lindland proposes a semiotic framework for quality that distinguishes syntactic, semantic, and pragmatic quality (Lindland, Sindre, et Solvberg 1994a). The syntactic quality addresses the structural relationships between modelling elements. The semantic quality is related to the relationship between the model and what it stands for (the domain). Finally, pragmatic quality considers the link between models and their interpreters.

On the other hand, commercial tools for business process modelling activities mainly focus on the accuracy of models based on a set of syntactic criteria and provide little or no guide to guarantee the quality of produced models. Recent research work focusing on the quality of process models concentrates mainly on structural aspects of models taking into account two criteria of quality namely correctness and complexity.

The main problems targeted within the context of this thesis are listed in the following.

• Lack of business process models evaluation approaches

One of the major hurdles in evaluating the quality of business process models is the lack of quality metrics. Most of the existing evaluating approaches concentrate on the evaluation of BP models syntactic quality: complexity, size, cohesion, etc. But there are few approaches that provide quality

Chapter 1: Introduction assessment methods for the evaluation of semantic and pragmatic quality of models. Semantic quality of the model includes: (i) the semantic of the concepts labels i.e. the vocabulary used and (ii) the semantic emplacement of different concepts i.e. the relationship of the concept with its neighbours.

The semantic of the concepts depends on the domain. It is presented through the concepts label. The semantic emplacement of the concepts depends on the role of each concept type. The pragmatic quality is related to the understandability and the readability of the model.

Additionally, there are no tools automating the syntactic evaluation process. Most of the existing modelling software tools such as Bizagi, Mega, Blueprint, etc. do not provide a comprehensive evaluation mechanism.

• Lack of business process models improvement approaches

Enterprises try to improve their existing processes in order to provide new or better services. But quality evaluation is only a step to improve the business process models. Most of the quality frameworks focus exclusively on defect detection (quality evaluation) and ignore the defect correction (quality improvement) aspects. Thus they may help in identifying the problem but the analysts must rely on themselves for the solution (D. L. [START_REF] Moody | Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions[END_REF]. Similarly, the domain of BPM quality lacks a guided process helping modellers to improve their models. Limited research is carried out to represent process knowledge for improvement [START_REF] Vergidis | Business Process Analysis and Optimization: Beyond Reengineering[END_REF].

There has been some work done to capture common improvement approaches in the form of business redesign patterns that contribute to the improvement of processes from four main perspectives, namely time, quality, cost, and flexibility (Hajo A. [START_REF] Reijers | Process Design and Redesign[END_REF]. Although these redesign patterns could be used as guidelines for the improvement step, most of the improvement methods do not utilize these patterns. On the contrary, these methods rely heavily on human innovation and creativity rather than on rationality.

Furthermore, available process modelling notations such as BPMN, EPC, Eriksson-Penker do not provide preventive guidelines nor improvement guidelines. Therefore, support for effective improvements are very limited. Some of the above notations are complex and require assistance in their use but these guidelines are insufficient.

To conclude, our review of literature leads us to the conclusion that researchers mainly focused on evaluating the syntactic quality aspects of the model. Therefore, an effort on semantic and pragmatic quality definitions needs to be provided. Moreover business process models quality improvement is required. Our approach is a step forward to improve quality of BP modelling along these two directions.

Objective of the thesis

The business process modelling activity may concern two types of users: i) Technical users that represents modelers and developers as well as ii) Business users that represents domain experts.

The primary objective of a business process model is to provide the modeller with a semi-formal representation of the organization main functions.In particular, a modeller that do not have sufficient domain knowledge or not competent in using a modelling notation.. Although these various formulations can be correct, they might not necessarily be equal in terms of their usage. The core objective of this thesis is to develop a comprehensive quality approach for business process models.

This objective can be divided into the following goals.

Define the semantic quality property for business process model evaluation

The semantic quality measures the degree of correspondence between the model and the domain. The semantic quality is related to both completeness and validity of the models (Krogstie, Lindland, et Sindre 1995a). We consider semantic quality as the conformance of BP models to the domain knowledge.

According to [START_REF] Krogstie | Process Models Representing Knowledge for Action: A Revised Quality Framework[END_REF], in Information Systems (IS) discipline, domain knowledge comprises two parts:

• IS domain knowledge representing know-how provided by methods, notations, and tools.

• Application domain knowledge referring to real-world problems: application domain knowledge can be extracted from several sources such as user's requirements statements, domain expertise or existing models related to the same problem or to similar problems

To conclude, we aim to capture IS Domain Knowledge through Meta modelling and Application domain knowledge through a domain ontology.

Capture the IS domain knowledge

In order to capture the IS knowledge for BP modelling activity.

• We define a business process model meta-model aiming to both structuring BP models to help in their understanding, and ensuring the generality of the approach regarding the variety of BP modelling notations.

• We describe the model semantics by the means of object constraint language (OCL) rules.

These rules are classified into semantic, pragmatic, and syntactic depending on the category of model's quality property they aim to ensure.

Propose an approach based on domain knowledge to improve semantic quality of business process model

In order to evaluate the semantic quality, we aim to identify a set of what we call quality deficiencies.

The latter are detected based on the knowledge provided by the domain ontology. To do so we aim to:

• Exploit the domain ontology.

• Define mappings between the business process model and the domain ontology in order to extract the adequate knowledge.

• Based on the knowledge extracted, evaluate the semantic quality of the model by proposing semantic metrics.

Chapter 1: Introduction

Enrich this approach by proposing guides to help business process modellers to improve their models and thus upgrade their semantic quality

Another problem with existing quality approaches is that they don't propose a guided process. They merely identify and propose evaluation criteria and leave the modeller on his/her own for evaluation.

Similarly, majority of the quality frameworks fail to provide post-evaluation recommendations for improvement. Thus once the modeller is done with evaluation, he/she is left without any guidelines for improvement.

It is therefore required that the proposed quality approach should encompass a complete guidance process helping modellers in evaluating the model and guide them in improving the quality of their BPM based on the evaluation results.

5.

Develop a software utility to automate the evaluation and improvement process

Organization of the thesis

The thesis is organized in a sequential way starting with a thorough state of the art in Chapter 2.

Different existing evaluation methodologies and quality frameworks are categorized and discussed in detail to obtain an overall idea of current state of the target domain.

In Chapter 3, we discuss our proposed solution in detail. It starts with the formulation of a multifaceted quality approach for business process models. It is followed by the description of our quality model including the descriptions of each of its components such as IS constraints and quality metrics.

Quality improvement patterns are one of our major contributions. Therefore we describe the concept of business process quality improvement in details along with all its components such as quality metrics, improvement actions, preventive actions, textual guidelines and recommendations.

Thus in Chapter 3 we discuss the representation of knowledge in two sections:

• IS Domain knowledge: It is divided into two main parts. In the first part, we discuss the business process models meta-model that allow our approach to be independent of any notation. Mappings between concepts of each notation and the meta-model concepts are identified. Whereas in the second part, we describe notation constraints. These constraints are applied on the meta-model level allowing the modeller to detect the modelling defects.

• Application domain knowledge: We define an ontology meta-model. This section is divided into two main parts. In the first part, we discuss the ontology meta-model whereas in the second part, we define different types of mappings between the BPM meta-model concepts and the Ontology meta-model concepts.

In Chapter 4 , we discuss the quality evaluation and quality improvement procedure.

• The evaluation procedure includes the creation of the quality metrics, the definition the quality defects and how to evaluate each defect.

• The improvement process proposed by our approach starts by defining the different types of improvements. It is followed by the description of each step of the improvement process, and finally, by defining the quality patterns.

In Chapter 5, we present our software prototype "BPM-Quality" implementing our proposed solution and process. In the first part of the chapter we describe the application architecture at multiple levels of granularities whereas in the second part we present different interfaces available in "BPM-Quality"

for quality evaluation and quality improvement operations. We have taken small examples to demonstrate the flow of the application.

In Chapter 6, we discuss the two validation experiments conducted for our approach. In the first section, we describe our first experiment and the results aiming at validating the selection of the IS constraints defined. In the second section, we discuss our second experiment that was conducted to validate the efficacy of our complete approach including quality patterns.

In Chapter 7 some perspectives of the work are discussed along with the conclusions of the thesis.

Three appendixes are given at the end. Appendix-A describes the different functions used to mapp the BP model concepts to the domain ontology concepts. It also describe the BPM-Quality tool interfaces.

Appendix-B present the validation scenario and lists the models used in the second experiment.

Appendix-C illustrates the domain ontology used in the second experience.

Bibliography is given after the three appendixes. A list of our publications is provided in the last part of the thesis.

Chapter 2 State of the Art

There is no universal definition of quality for products and services. One of the definitions is that of ISO which is "the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs" (ISO 8402:1994).

Thus quality is a subjective domain. It is highly dependent on multiple view points (consumer, producer, etc.). The notion of quality for an object from one viewpoint might not hold from another viewpoint [START_REF] Reeves | Defining Quality: Alternatives and Implications[END_REF].

The question is why to ensure business process quality? As a matter of fact, business processes are designed to execute strategies that aim at achieving organisational goals [START_REF] Poels | Investigating Goal-Oriented Requirements Engineering for Business Processes[END_REF].

Consequently ensuring its quality means identify and reduce opportunities for defects, which cause reductions in the quality of process outcomes. (BusinessDictionary.com, 2013). To evaluate the quality, we need to identify quality criteria (dimensions, attributes and metrics).

As this thesis is concerned with the quality of business process models, we will be discussing BP modelling notations and tools in this chapter in addition to quality criteria of models. We chose to review literature on business process quality dimensions and metrics. Last of all, we review the quality approaches existing in the literature.

Business process modelling

In recent years research related to modelling and improving business processes has been of growing interest. Thanks to their experience, companies are aware of the undeniable impact of a better tuning of business processes on the effectiveness, consistency and transparency of their business operations.

This tuning requires a better understanding and an effective management of BP.

The Oxford English Dictionary (1999) defines a 'process' as a series of actions or operations conducing to an end, or as a set of gradual changes that lead toward a particular result. Business processes (i.e. processes performed by the 'physical system') are a set of activities intended to transform system inputs into desired (or necessary) system outputs by the application of system resources [START_REF] Leondes | Intelligent Knowledge-Based Systems: Business and Technology in the New Millennium[END_REF].

A BP is a structured set of activities designed to produce a specified output for a particular customer or market so that it implies a strong emphasis on how work is done within an organization, in contrast to a product's focus on what [START_REF] Davenport | Process Innovation: Reengineering Work Through Information Technology[END_REF].

A business process is the combination of a set of activities within an enterprise with a structure describing their logical order and dependencies whose objective is to produce a desired result (Aguilar-Savén 2004a). Business process modelling enables a common understanding and analysis of a business process. A process model can provide a comprehensive understanding of a process.

Recently, an empirical study has shown that business processes have become the central objects in many conceptual modelling efforts [START_REF] Davies | How do practitioners use conceptual modeling in practice?[END_REF]. In fact the aim of the research was to determine whether practitioners still embraced conceptual modelling seriously and to find out what are the most popular techniques and tools used for conceptual modelling. The conclusion of their research was that the highest ranked purposes for which modelling was undertaken were business process improvement and business process documentation.

Even if business process models (BPM) are also conceptual models, they have specific aspects related to the fact that the underlying processes must be executed. In fact, business process execution needs standards for capturing the workflow management [START_REF] Hollingsworth | Workflow Management Coalition -The Workflow Reference Model[END_REF]. Also, it should represent an executable behaviour captured by business process patterns such as parallel split and synchronization.

These patterns specify the basic functional and behavioural requirements of an execution architecture (Van Der [START_REF] Aalst | Business Process Management: A Survey[END_REF], in addition to managing shared resources and simultaneous constraints [START_REF] Malone | The interdisciplinary study of coordination[END_REF].

Thus BPM evaluation needs specific approaches and tools, different from those of conceptual data models quality approaches (D. L. [START_REF] Moody | What makes a good data model? Evaluating the quality of entity relationship models[END_REF].

To understand the terminologies and features of BPM, one should start from an appreciation of the BP Management life cycle. The latter describes the various phases in support of operational business processes [START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF]). In the literature there is no uniform view on the number of phases in this. It varies depending on the chosen granularity for identifying the phases [START_REF] Wetzstein | Semantic Business Process Management: A Lifecycle Based Requirements Analysis[END_REF].

Besides the BP management, the importance of the workflow management is of big interest.

Workflow management supports business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents, and other sources of information (Wil M. P. van der Aalst, Hofstede, et Weske 2003a). Van der Aalst and al. restrict BPM to operational processes. They consider four phases to represent the workflow management (Figure 1) .

1. Process design -In this stage, business processes are modelled into BPM systems. Graphical standards are dominant in this stage. They allow users to express business processes and their possible flows and transitions in a diagrammatic way.

2. System configuration -This stage configures the underlying system infrastructure e.g. synchronization of roles and organization charts.

3. Process enactment -Business processes once modelled are deployed in business process modelling software engines. Execution standards dominate this stage. They computerize the deployment and the automation of business processes.

4. Diagnosis -Given appropriate analysis and monitoring tools, the BPM analyst can identify and improve on potential loopholes in the business process. The tools provide administrative and monitoring capabilities. The conceptual design phase is a critical stage in the business process management lifecycle, since in this stage, designers and other members of the development team brainstorm product ideas based on research into customer needs (Lilton, 2013). Also, according to Boehm [START_REF] Boehm | Software Engineering Economics[END_REF], removing the defect during the design stage costs less than removing the same defect during the other stages since an error detected in the further phase will generally require the expensive rework of much of the previous phases.

At the design stage, users are allowed to express the information flow, decision points and the roles of business processes in a diagrammatic way [START_REF] Ko | Business process management (BPM) standards: a survey[END_REF]. One of the primary motivations for developing any model is to increase the understanding of the business and facilitate communication about the business. The business process models should generate descriptions of a complex reality that capture the core functions of the business.

Current initiatives in the field of Business Process Management (BPM) strive for the development of a BPM standard notation. However, BP modelling techniques need to be carefully examined, analyzed and evaluated. In the literature, a number of notations have been proposed to model business processes e.g. BPMN (Business process modelling and notation) (S. A. White 2004), Eriksson-Penker notation [START_REF] Penker | Business Modeling With UML: Business Patterns at Work[END_REF], Event-Driven Process Chains (EPC) (W. M. P. van der Aalst 1999), Petri

Nets [START_REF] Bosilj-Vuksic | IDEF diagrams and petri nets for business process modeling: suitability, efficacy, and complementary use[END_REF], UML activity diagrams [START_REF] Havey | Essential Business Process Modeling[END_REF] etc. The common feature of these languages is their focus on providing a comprehensive, integrated notation for (business) process modelling.

Business process modelling is commonly used to document information about structure and behaviour of a business process. The main goal of a notation is to capture and present the essential concepts of the process [START_REF] Caetano | A Role-Based Framework for Business Process Modeling[END_REF]. Hence, the quality of business process models is affected directly by the notation. In the next section, we discuss some of the existing business process modelling notations.

Business process modelling notations

Business process modelling has several purposes, we can cite:

1. Use a common representation of the processes in order to help the communication between the business communities (analysts, designers, developers...). They will have the same vocabulary which will facilitate their understanding and communication [START_REF] Luo | A framework for selecting business process modeling methods[END_REF].

2. Modelling business processes requires capturing the essential concepts of the process. These concepts can later be composed, specialized and reused into other process models [START_REF] Caetano | A Role-Based Framework for Business Process Modeling[END_REF].

3. Business process models also improve model reengineering by facilitating model reuse and making explicit the dependencies between the model elements [START_REF] Caetano | A Role-Based Framework for Business Process Modeling[END_REF].

4. The business process model acts as the basis for decision making and affects decisions about prioritizing goals, obtaining the right resources. It allows for changes and improvements in the process and enables decision support during process execution, and control [START_REF] Eriksson | Business Modeling With UML: Business Patterns at Work[END_REF].

Business process modelling represents an important part of information systems (IS) development and evolution within organizations. One of the main issues in business process modelling is the variety of notations.

A lot of conceptual business processes modelling notations are available. The difference between those notations is limited to their abilities to integrate many forms of information into the business process model. Each notation can focus on different facets of the process modelled.

Several languages have been proposed for business process modelling, they emphasize different aspects of processes and related structures, such as organizations, products, and data. Consequently, they are suited for different kinds of processes. We can distinguish between process modeling languages that are hierarchical, flow-oriented, role-oriented, communication-oriented, declarative, goal-oriented, timelines, product and document state machines etc.

Based on Ouyang and al.'s definition (Ouyang, Dumas, et Hofstede), a business process model is a flow-oriented representation of a set of work practices aimed at achieving a goal, such as processing a customer requestor complaint, satisfying a regulatory requirement, etc.

Hence we will review some of the flow oriented languages (BPMN, UML AD, EPC, Petri-net) and the product/data oriented Eriksson-Penker notation whose one of its concern is in the structuring and handling of data, followed by a comparison of the notations based on several references.

Business process modelling and notation

The Business Process Management Initiative (BPMI) has developed a standard Business Process

Modelling and Notation (BPMN) (S. A. White 2004). The BPMN meta-model consists of four different categories: Flow objects, Connecting objects, Swim lanes, artefacts (Figure 2).The elements Activity, Process, Sub-Process, Task as well as Events and Gateways are Flow objects, which define the behaviour of a business process. An event is something that "happens" during the execution of a business process. There are three types of events, based on when they affect the flow: Start, Intermediate, and End. A Gateway is used to control the divergence and convergence of a sequence flow. The connecting objects Sequence Flow, Message Flow and Association describe the ways of connecting the flow objects to each other. A message flow illustrates the exchange of messages. A sequence flow shows the order in which activities are performed in a process. An association is used to link information to activities, and relates a Data Object to a flow or connects it to an activity [START_REF] Omg | Business Process Modeling Notation[END_REF]. The BPMN elements are compliant with most flow charting notations but offer much more precise flow control semantics. The strength of BPMN is that it enables roles to be defined at various levels of granularity through pools and swim-lanes. One of the shortcomings of BPMN is that it lacks formal semantics. Additionally, BPMN lacks concepts hierarchy (Wahl et Sindre 2005a). As stated in (S.

White 2004), BPMN is not suitable for modelling organizational structures and resources, data and information models, strategy or business rules. BPMN contains only concepts that are relevant to model business processes so that concepts related to other domains can not be presented.

BPMN has similar notations to other languages such as Activity diagrams, EPC, Petri nets and others, which is helpful as the modellers may be familiar with the other languages. Also, BPMN concepts are defined in a clear way to avoid confusions.

Eriksson-Penker notation

Eriksson-Penker extensions provide a framework for UML business processing model extensions, to which an enterprise architect can add stereotypes and properties appropriate to his/her business [START_REF] Penker | Business Modeling With UML: Business Patterns at Work[END_REF]. Eriksson-Penker extensions provide symbols for modelling the processes (i.e. the activity performed within the business), resources (such as people, material, information, and products that are used or produced in the business), rules (statement and constraints), and goals (i.e.

the purpose of the business) of a business system (Figure 3). Eriksson-Penker elements are understandable and well defined because of the stereotypes. They describe different types of resources which represent the information flow in the business process.

One of the shortcomings of Eriksson-Penker notation is that it is not sufficiently detailed regarding the synchronization of the activities. In other words, there is only one type of synchronization; it does not include the XOR and OR gateways presented in BPMN for example. In addition, it is not exportable in any other language.

Event-driven process chains

Event-Driven Process chain (EPC) was developed by the Institute for Information Systems (IWi) at the University of Saarland, Germany. It is an intuitive graphical business process description language.

The language is targeted to describe processes on the level of their business logic, not necessarily on the formal specification level (W. M. P. van der [START_REF] Van Der Aalst | Woflan: a Petri-net-based workflow analyzer[END_REF]. It works as an ordered graph of events and functions and supports parallel execution of processes [START_REF] Scheer | ARIS -Architecture of Integrated Information Systems[END_REF]. The metamodel of the EPC is described in (Figure 4) extracted from [START_REF] Seel | Meta-model based extensions of the epc for inter-organisational process modelling[END_REF]. An EPC consists of functions, events, control flow connectors, logical operators, and additional process objects. Each EPC consists of one or more functions and two or more events, as an EPC starts and ends with an event and requires at least one function for describing a process. Events and functions are linked by the control flow as directional edges. The control flow operators OR, XOR, and AND are used to split and join the control flow. The connection between these models elements are represented by the "Predecessor-Successor-Relationship". The last important characteristic of the modelling language EPC are resources, which are consumed/produced by functions. A resource may be an organizational unit, an application system or a document. Each resource has its own specific type e.g. Event-driven process chains have become a widespread modelling technique because of the success of products such as SAP R/3 and ARIS. EPC notation is easy to understand and capable of presenting the information flow in the process. Based on van der Aalst work (W. M. P. van der Aalst 1999) EPC suffers from a serious drawback : neither the syntax, nor the semantics of an event driven process chain are well defined which leads to ambiguous representations of the processes.

UML activity diagrams

Petri-nets

Petri net is the notation suited to model the behaviour of the system in terms of "flow". A Petri net is a particular kind of bipartite directed graphs populated by three types of objects: places, transitions and directed arcs (Figure 6). A transition has a number of input places and output places. Places, represented by circles, are the containers of tokens. Tokens represent the information or the thing that flows through the system. Directed arcs connect places to transitions and vice versa. At a given point, a place may contain zero or several tokens and the number of tokens represents the state of the place.

A transition is enabled if there is at least one token in each input place. When a transition is executed, a token is removed from the input and added to the output of the current transition. ). However, these models also have disadvantages. Perhaps the main disadvantage is that the basic Petri net constructs are quite primitive, so that is not only a significant burden placed on the analyst in order to specify complex models, but in addition the graphical representation may become too complex to be useful. Another disadvantage is that the representation of priorities or ordering is hard to manage, although priority queues are important in performability modelling.

We can seize from the literature other notations such as flowcharts, Yet an other workflow language (YAWL) (W.M.P. van der Aalst et ter Hofstede 2005), Role Activity Diagramming (RAD) (C. [START_REF] Badica | Integrating role activity diagrams and hybrid IDEF for business process modeling using MDA[END_REF], Integrated Computer-aided Manufacturing Definition (IDEF) [START_REF] Badica | A formal IDEF-Based notation for business process modelling[END_REF], etc...

The motive for the choice of the five process modelling notations is that they are widely used in describing business process models and they are commonly used by both practitioners and researchers [START_REF] Johansson | Graphical Modeling Techniques and Usefulness in the Model Driven Arcitechture : Which Are the Criteria for a "Good" Computer Independent Model?[END_REF]).

Comparison of business process modelling notations

Researchers always aim to develop new business process notations because of dissatisfaction with the existing notations for presenting information and knowledge on business processes. Thus the notations which use a less total number of commonly acceptable symbols are intuitively more meaningful than the existing arbitrarily assigned symbolic notations (Birkmeier, Klöckner, et Overhage 2010a).

The evaluation and comparison of conceptual modelling languages in general and process modelling languages in particular has frequently been addressed in literature. This evaluation is important to help in selecting the most suitable language according to the needs, and also to improve existing languages.

Business process modelling notations comparison frameworks

Previous efforts are done to study the strengths and drawbacks of BPM notations by proposing frameworks to evaluate them.

In order to compare BPM notations, Aldin et al. [START_REF] Aldin | A Comparative Analysis Of Business Process Modelling Techniques[END_REF] derive five criteria :

-flexibility, which affirms how easy changes in the business process are possible, -ease of use, the extent to which the technique can be easily applied by business modellers who are not specialists of the technique, -understandability of the modelling technique, -simulation, demonstrates the capability of the modelling technique to simulate a business process, -scope establishes the definition of the process modelling elements.

On the other hand, Wahl and al. proposed the semiotic framework (Wahl et Sindre 2005b) where five criteria are identified for evaluating the quality of conceptual modelling language:

-Domain appropriateness, conveys how suitable the language is for use within different domains.

-Participant language knowledge appropriateness shows if the language is understandable by the modellers.

-Knowledge externalizability appropriateness, verifies if the language is suitable to express all the knowledge of the modellers.

-Comprehensibility appropriateness, evaluates language comprehensibility.

-Technical actor interpretation appropriateness, evaluates the language reasoning process.

The Wohed and al. comparison framework (Wohed et al. 2006) is based on four criteria: (1) widely used;

(2) well accepted;

(3) comprehensible to IT practitioners; and (4) sufficiently detailed to provide a comprehensive basis for assessing the capabilities of process modelling languages.

In the next section, we assess some of the modeling notations for business process models. We selected UML activity diagrams, BPMN, EPC, Petri-nets and Eriksson Penker notations. Moreover, we selected Wohed and al's four criteria [START_REF] Wohed | On the Suitability of BPMN for Business Process Modelling[END_REF] to evaluate these notations. This evaluation combines our expertise and literature studies related to notations understanding and analysis.

Results of business process modelling notations comparison

Several authors who conducted analytical comparisons have highlighted considerable similarities between the notations: Business Process Model and Notation (BPMN) and Activity Diagrams (AD).

Some presumed the superiority of BPMN over AD and others found BPMN to be too complex.

Birkmeier and al. (Birkmeier, Klöckner, et Overhage 2010b), concluded that UML AD was significantly more effective in data handling. Also the usage of BPMN promoted a sequential modelling style in which unrelated activities run one after the other or AD allow the activities to run in parallel, which increases the process flexibility. Similarly, Recker et al. [START_REF] Recker | Measuring Method Complexity: UML versus BPMN[END_REF]) used an established approach for evaluating the complexity of conceptual modelling methods and compared BPMN and AD based on their complexity. They found that BPMN has very high levels of complexity when contrasted with UML AD. On the other hand, some authors used a semiotic quality framework to analyze BPMN such as in [START_REF] Nysetvold | Assessing Business Process Modeling Languages Using a Generic Quality Framework[END_REF]. They found BPMN to be superior on AD with respect to learnability, precision, and its language patterns.

Comparison between BPMN and EPC is also studied. [START_REF] Kunze | Towards Understanding Process Modeling -The Case of the BPM Academic Initiative[END_REF]) concluded that BPMN models expose a higher diversity than EPC's in terms of construct heterogeneity due to the greater and more detailed expressiveness of the BPMN language compared to EPC's, which is also leveraged in process models. Similarly (Tscheschner, 2010) , studied how to transform EPC models to BPMN models due to the fact that BPMN has more expressiveness than EPC.

Vuksic et al. [START_REF] Bosilj-Vuksic | IDEF Diagrams and Petri Nets for Business Process Modelling: Suitability, Efficacy, and Complementary Use[END_REF] compared IDEF diagrams (Aguilar-Savén 2004b) and Petri nets [START_REF] Bosilj-Vuksic | IDEF diagrams and petri nets for business process modeling: suitability, efficacy, and complementary use[END_REF]. They concluded that IDEF diagrams are very simple but not available for very complex models on the contrary of Petri nets. Hierarchical structure is possible in both diagrams. Petri nets have a lack of standardization on the contrary of IDEF diagrams.

We borrowed the choice of BP languages evaluation criteria from [START_REF] Wohed | On the Suitability of BPMN for Business Process Modelling[END_REF] since it is more adequate to our study for the following reasons:

(1) Widely used: help us to asses evaluation based on these criteria.

(2) Well accepted: also help us to identify evaluation criteria.

(3) Comprehensible to IT practitioners: verify the pragmatic quality and it may be used as pragmatic metrics threshold.

(4) Sufficiently detailed: it represents almost all the semantics we are searching for as we are interested in the completeness of a notation.

Widely used Well accepted Comprehensible to IT practitioners

Sufficiently detailed + UML elements are easy to sketch on paper (Wohed et al. 2006).

+ It offers comprehensive support for the control flow and data perspectives [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF]).

-Some of the constructs lack a precise syntax and semantics (Russell et al. 2006).

-It does not fully capture important kinds of synchronization [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF]).

-It is extremely limited in modelling resource-related or organizational aspects of BP [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF]).

-Can not define various role levels of granularity (White 2004). + Supports signal sending and receiving at the conceptual level [START_REF] Dumas | UML Activity Diagrams as a Workflow Specification Language[END_REF]. + Supports both waiting and processing states [START_REF] Dumas | UML Activity Diagrams as a Workflow Specification Language[END_REF]. + Provides a seamless mechanism for decomposing an activity into sub-activities [START_REF] Dumas | UML Activity Diagrams as a Workflow Specification Language[END_REF] White). + Enables roles to be defined at various levels of granularity through pools and swimlanes (White 2004). + Captures the interleaved parallel routing and the synchronising merge patterns [START_REF] Wohed | On the Suitability of BPMN for Business Process Modelling[END_REF]. + Supports the resource perspective [START_REF] Wohed | On the Suitability of BPMN for Business Process Modelling[END_REF]. EPC + EPC is widely used in commercial projects from the field of management information systems [START_REF] Ferdian | A Comparison of Event-Driven Process Chains and UML Activity Diagram for Denoting Business Processes[END_REF]).

-It is not classified as a Graphical Standard [START_REF] Kindler | On the Semantics of EPCs: A Framework for Resolving the Vicious Circle[END_REF]). + Easy for non technical users to pick up.

-The semantics and syntax of the EPC are not well defined [START_REF] Kindler | On the Semantics of EPCs: A Framework for Resolving the Vicious Circle[END_REF]).

-Ambiguity caused by the not well defined presentation of concepts (W. M. P. van der Aalst 1999).

+ EPC does present the information inputs and outputs of the functions -EPC does not present activity or functions hierarchy. . -It is comprehensible as each concept is defined by a stereotype [START_REF] Penker | Business Modeling With UML: Business Patterns at Work[END_REF].

Petri

-It is not detailed regarding events and synchronization. + It is well detailed regarding different types of resources.

Table 1: Notation's strengths and drawbacks

BPMN is an increasingly important standard for the process modelling and offers a wide range of modelling constructs. Its development has been based on the revision of other notations including UML, IDEF, ebXML and Event-driven Process Chains (OMG Final Adopted Specification 2006).

Muehlen et al. [START_REF] Muehlen | How Much Language Is Enough? Theoretical and Practical Use of the Business Process Modeling Notation[END_REF] concluded that not all the BPMN constructs are equally used, less than 20% of the vocabulary is used regularly. Unified Modelling Language (UML) has emerged as the software industry's dominant modelling language [START_REF] Siau | Unified Modeling Language: A Complexity Analysis[END_REF]. UML and BPMN contain a large set of constructs in contrast to competing languages, and offer a multitude of options for conceptual modelling. Both have been found in analytical studies to be not only semantically richer but also theoretically more complex than other modelling languages [START_REF] Siau | Unified Modeling Language: A Complexity Analysis[END_REF]. Similarly, related studies found that frequently less than 20% of the constructs are used [START_REF] Siau | Theoretical vs. Practical Complexity: The Case of UML[END_REF], [START_REF] Kobryn | UML 2001: a standardization odyssey[END_REF].

Muehlen found that the practical complexity of BPMN is remarkably less than its theoretical complexity [START_REF] Muehlen | How Much Language Is Enough? Theoretical and Practical Use of the Business Process Modeling Notation[END_REF]. Practical complexity is measured by the number of constructs actually used in a model while theoretical complexity its measured by the number of constructs originally specified (Keng [START_REF] Siau | Theoretical vs. Practical Complexity: The Case of UML[END_REF] .

On the other hand [START_REF] Siau | Unified Modeling Language: A Complexity Analysis[END_REF] evaluate the complexity of UML using complexity metrics. They concluded that UML is not distinctly more complex than techniques in other object oriented methods. But as a whole, UML is very complex.

Other studies evaluate process oriented modelling techniques such as [START_REF] Johansson | An evaluation of business process model techniques, using Moody's quality criterion for a good diagram[END_REF] where they evaluate BPMN, Flowcharts, EPC and UML activity diagrams using Moody's quality criteria: discriminability, perceptual and cognitive limits, emphasis, cognitive integration, perceptual directness, structure, identification, expressiveness and simplicity. Based on the used quality criteria, this indicates that there are problems to be solved when it comes to modelling techniques. BPMN reached a high score but it is far from the maximum sum which indicates that even BPMN could be improved. All four process modelling techniques have a negative score on emphasis and expressiveness, a neutral value on perceptual directness and identification, and a positive value on simplicity. All these findings indicate that if there is a need to choose which notation to use, the

Business process modelling tools

Business process modelling tools provide business users with the ability to model their business processes, implement and execute those models. As our thesis aims to improve the quality of business process models, we are interested in the BP modelling tools. These tools are developed to describe and analyze business processes.

There exist numerous modelling tools for designing business process models based on different notations such as BPMN, Petri nets, and EPC, etc. However, only some of them provide means to evaluate the quality of the models. And even fewer provide improvement guidelines. In this section we will assess some of these modelling tools.

Bizagi

Bizagi is a business process modelling and documentation tool that allows to model and document business processes in BPMN (Business Process Model and Notation). It offers the capability to export the BP diagrams into: Microsoft Visio, Image files (png, bpm, svg or jpg format) and to XPDL.

Bizagi provides powerful simulation capabilities that enable organizations to make better decisions by visualizing the impact of proposed ideas. Bizagi simulation is robust and easy to use to better illustrate the advantages of analyzing your business operations using simulation in Bizagi.

Bizagi Simulation comprises four levels:

-Process Validation: checks if the process flow works as expected insuring calls and flow rates followed according to the scenario. This step will prevent modelling errors showing up in the results of the excessive levels.

-Time Analysis: measures the end-to-end process time by defining the time required by each activity.

It calculates the processing time under the current conditions.

-Resource Analysis: predicts how the process will perform different levels of resources. It will show the resource utilizations and highlight the possible delays in the process.

-Calendar Analysis: reflects the process performance over dynamic periods of time as shift works, weekends and holidays that may affect the real performance of the process.

To conclude, Bizagi Process modeller does not validate the notation and the logic used in your diagram. However, it validates the elements locations and connections. It also highlights the real world problems over utilization of resources and significant process delays. Moreover, it provides the capability to compare two process models via the resource utilization and the process time.

Star UML

StarUML is an open source modelling tool designed to replace commercial applications such as

Visual Paradigm

It allows to draw the following kinds of diagrams to aid in business process modelling: Business process diagrams with Business process modelling notation (BPMN) 2.0 standard, Data flow diagram which represents flows of data, Event-driven process chain diagram supported by EPC notation, Process map diagram which provides a high level view of business process. The process in the map can drill down using business process diagrams and the process link shows relationships between different business processes and the organization chart that shows the structure of an organization.

From the evaluation point of view, the business process simulation in Visual Paradigm simulation edition helps us to:

-identify bottlenecks, -quantify candidates for task automation, -quantify benefits from possible process change for comparison. It analyzes numerically how much time and money will be spent under the model conditions.

Visual also defines scenarios for load testing i.e. a number of cases of a possible path.

The analysis results can be shown as charts that present the resource usage, queue time, cost per flow object, cost per input and time cost.

Visual paradigm allows the modeller to define and describe business operations, definitions and constraints. Moreover, it detects syntactic errors and suggests corrections. For example it detects an invalid connection and suggests another type of connection which applies the BPMN specifications.

ARIS

ARIS (Architecture of Integrated Information Systems) [START_REF] Scheer | ARIS Architecture and Reference Models for Business Process Management[END_REF] is a professional tool for the dynamic analysis of business processes. It is developed by IDS Scheer AG (www.idsscheer.nl). It uses the modelling language Event-driven Process Chains (EPC).

ARIS provides a business process analysis platform which is ideal for organizations that want to document, analyze, standardize, and improve their processes. They can respond faster to changing business and market requirements. It offers methods for analyzing processes and taking a holistic view of process design, management, work flow, and application processing by analyzing the process throughput times, dynamic wait time and costs rates.

Based on process models and organizational structural simulation, comparisons of actual and targeted processes are enabled in terms of execution ability and efficiency. The focus can also be lading on:

-costs, -execution time, -resource usage.

These simulations provide answers about throughput times, weak points, bottlenecks and resource requirements. The results can be provided through statistics, animations or charts. Thus, the simulation's statistics can be used to process analysis and optimization.

ARIS is intended to serve various purposes: documentation of existing business process types, blueprint for analyzing and designing business processes, and support for the design of information systems (Lankhorst 2013).

MEGA

MEGA Process (« MEGA Process » 2013) provides capabilities for modelling and documenting business processes and organizational structures. This business architecture serves as a reference for decision making and impact analysis for organizational choices at the business, the operational, and the IT levels. Coupled with MEGA Simulation, MEGA Process helps compare and optimize business processes by testing multiple scenarios and their potential outcomes.

MEGA main features are:

-process modelling, -organizations modelling, -analysis of the information flows, -link business process to systems currently in use, -support quality management initiatives.

Mega tool enforces rules to make sure the main modelling standards are respected when the modeller describes his/her process. It detects the syntactic errors by activating the BPMN constraints and pointing out the defect with a red circle. Moreover it can show which BPMN rule has been broken.

The modeller can also identify where risks can occur in the process and the severity of the risk. It allows the modeller to design an alternative version of a process. Thus he/she can analyze the impact of changes by generating an impact analysis report.

Woflan

Woflan (WorkFLow Analyzer) is a Petri-net-based Workflow Diagnosis Tool [START_REF] Verbeek | Diagnosing Workflow Processes Using Woflan[END_REF] which can be used to verify the correctness of a workflow procedure. It is addressed to analyze workflow process definitions specified in terms of Petri nets. It uses state-of-the-art techniques to find potential errors in the definition of a workflow procedure and gives workflow designers a handle to construct correct workflows. It guides the modeller of a workflow process definition towards finding and correcting possible errors. It can be used to verify a process definition i.e. it checks the syntactic and the behavioural properties.

Two of the key concepts on which Woflan is based, are the definition of a workflow net and the soundness property (W. M. P. van der Aalst 1999). For a given workflow net, Woflan is able to decide whether it is sound. Finally, Woflan guides the user in finding and correcting the error. To assist the user in repairing the error, Woflan offers an on-line help facility.

Business process modelling activity should not be restricted to the drag and drop of different concepts.

It should analyze the semantics of the concepts and detect the errors provided by the modeller. Thus, business process modelling tools should propose guidelines to correct the defects. (Table 2) summarizes the above mentioned points about the six evaluated tools.

Tools comparison

Table 2: Tools comparison

To summarize, all modelling tools support actors and represent in different ways the actors participating in the model. In contrast to the process hierarchies, EPC for example does not support functions hierarchy. Thus all the EPC modelling tools do not present functions hierarchy, similarly to Petri nets.

Bizagi, StarUML and Mega allow the modeller to define business rules documentation. Different categories of business rules [START_REF] White | Defining Business Rules ~ What Are They Really?[END_REF]) are possible:

• Business terms : documented in a glossary or entities in the model as in Bizagi and Mega.

• Facts relating terms to each other that can be documented as relationships, attributes etc, sush as in Mega

• Constraints as in StarUML.

Almost all the modelling tools provide the feature to support BPM simulation, and study the variation of cost, time and resource allocation.

Regarding the business process model defects detection, Bizagi detect the very basic defects such as bad emplacement of connectors. On the other hand, Mega does detect BPMN standards defects, as lack of start event, end events, edges conditions ...etc. And Woflan does detects behavioural defects as deadlocks, live locks ... etc. None of the tools detects syntactic and behavioural defects in the same time, nor semantic and behavioural defects.

Moreover, none of the modelling tools do provide improvements in order to correct these defects, except Mega which points out the defects and suggests some corrections.

From modelling to quality

Business process models are a direct input into the software development process (« Business-Driven Development » 2005). Consequently, the impact of the process models on the operational efficiency of an enterprise is increasing. However empirical studies show that more than half of the errors which occur during system development are requirements errors [START_REF] Endres | A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories[END_REF]. Zultner [START_REF] Zultner | Comyn-Wattiau -Improving Business Process Model Quality Using Domain Ontologies[END_REF] suggests that it would be more effective to concentrate quality insurance efforts in the requirements analysis stage.

The choice of the best representation of data is one of the most crucial tasks in information systems

(IS) since it impacts the quality of the final system. It does not only determine the costs, the flexibility of the system but also organizes the work of a developer and gives the ability to the system to meet the user requirements [START_REF] Simsion | Data Modeling Essentials: Analysis, Design, and Innovation[END_REF]. Thus, in the work of Zultner [START_REF] Zultner | Comyn-Wattiau -Improving Business Process Model Quality Using Domain Ontologies[END_REF], the authors argue that the total quality management approaches suggest that it is faster and cheaper to concentrate effort during the early development phases of a product in order to detect and correct defects as early as possible. Also according to Boehm [START_REF] Boehm | Software Engineering Economics[END_REF], the cost of removing a requirement defect at the design phase is 3.5 times more than removing the same defect at the analysis phase, and removing it at the implementation phase is fifty times more. In order to have a reliable development phase, we have to ensure its quality.

When exploring related work on the business process model quality, we found only very few papers that address the measurement of quality for process models. We can cite the work of Koehler and al. [START_REF] Koehler | IBM Research | Technical Paper Search | Process Anti-Patterns: How to Avoid the Common Traps of Business Process Modeling[END_REF]who introduced the anti-patterns for process models that allow us to measure an important aspect of the quality of process models. Anti-patterns capture typical design errors in a process model, which make the process model incorrect. On the other hand, Becker et al.

Quality of business processes

Goals of business process modelling are: to facilitate the understanding of the key mechanisms of an existing business, to serve as the basis for the creation of appropriate information systems supporting the business, to improve the current business structure and operation, to show the structure of an innovated business, to identify outsourcing opportunities, and to facilitate the alignment of business specifications with the technical framework that IT development needs [START_REF] Aguilar | Applying Software Metrics to evaluate Business Process Models[END_REF].

In order to meet customer demands, companies have to design business processes in an appropriate way. In particular, four essential process competencies have been discussed in business process management: process cost, process flow time, process flexibility, and process quality [START_REF] Anupindi | Managing Business Process Flows[END_REF]. Each of these points has been subject to dedicated research. We are interested in the business process quality.

Measuring metrics enables the organizations to improve their business processes: planning, monitoring and control software projects and evaluate software quality. Using these parameters can produce artefacts (software, components, etc.) that are likely to be less error prone, easy to understand, maintain and manage [START_REF] Cardoso | Business process quality metrics: log-based complexity of workflow patterns[END_REF]. We are interested in the business process quality.

Quality of business processes refers to the ability of a process to produce and deliver quality products [START_REF] Anupindi | Managing Business Process Flows[END_REF]. We aim in the next sections to seize from the literature the existing frameworks and standards of BP quality.

Dimensions of BP quality (frameworks and standards)

We can start with Heravizadeh and al. study [START_REF] Heravizadeh | Dimensions of Business Processes Quality (QoBP)[END_REF]. They have introduced the QoBP which is a framework for capturing the quality dimensions of a process. They have defined four categories of the business process quality:

-Function quality: Concentrates on the quality of functions that correspond to an activity and need to be executed. Thirteen quality dimensions have to be studied in order to evaluate activities quality.

-Input and output quality: They put a particular emphasis on data and information quality as they capture the physical and the informational objects that are consumed and produced by the activities.

Eleven quality dimensions are adopted and gathered from different studies.

-Human Resource quality: The quality of business process is influenced by the competency required to execute a function within a business process. As a consequence, they build their own six human resource quality attributes.

-Non Human resource quality: The non-human resources also influence the quality of functions and the business process as a whole.

For each of these categories, metrics are defined in order to evaluate them. (Table 3) summarizes these metrics. [START_REF] Heravizadeh | Dimensions of Business Processes Quality (QoBP)[END_REF].

Function

The QoBP approach has been presented in more details in [START_REF] Recker | Measuring Method Complexity: UML versus BPMN[END_REF]. In this context, quality has been defined as non-functional but distinguishing characteristics of a business process. They provide a framework for organizations to manage the quality of business processes during different phases of the BPM lifecycle.

On the other hand, Heinrich and Paech proposed a business process quality framework based on software quality [START_REF] Heinrich | Defining the Quality of Business Processes[END_REF]. By looking at typical process problems they derived attributes and measures for the characteristics. They discuss these attributes and measures based on QoBP categories. The characteristics, attributes and measures for the activities are presented in (Table 4). Finally, by looking at typical process problems, they concluded that only part of the characteristics and the ISO-derived measures are really relevant for business processes. Accordingly, the notion of quality for conceptual models (CM) in general and business processes in particular is not well established [START_REF] Krogstie | Integrating the understanding of quality in requirements specification and conceptual modeling[END_REF]. Attempting to describe it, studies have mainly concentrated on providing lists and collections of features and properties of CM. Comprehensive frameworks have been proposed which attempt to organize and structure the key concepts and features of quality in conceptual modelling (Table 5).

Characteristic / Attribute

Other frameworks in the literature, as the conceptual modeling quality framework (CMQF) [START_REF] Nelson | A conceptual modeling quality framework[END_REF] wich is a combination and an extension of both the LSS [START_REF] Krogstie | Information Systems Engineering: Conceptual Modeling in a quality perspective[END_REF] and the BWW [START_REF] Wand | Anchoring data quality dimensions in ontological foundations[END_REF] Organizing the various quality cornerstones and then defining the many quality dimensions that connect one to another.

Table 5 : Quality approaches of conceptual models

Lindland/Sindre/Solvberg's framework

The basic idea of Lindland et al. 's framework (Krogstie, Lindland, et Sindre 1995b) (Lindland, Sindre, et Solvberg 1994b) is to evaluate the quality of models along three dimensions: syntax, semantics, and pragmatics.

• The model is the set of all the statements explicitly or implicitly made in the model.

• The language is the set of all statements which are possible to make according to the vocabulary and grammar of the modelling language used.

• The domain is the set of all statements which would be correct and relevant about the problem at hand.

• The audience interpretation, i.e., the set of all statements that the audience (i.e., various stakeholders of the modelling process) thinks the model consists of.

The primary sources for model quality are defined using the relationships between the model and the three other sets:

-Syntactic quality is the degree of correspondence between model and language.

-Semantic quality is the degree of correspondence between model and domain. It allows detecting the existence of invalid statements or the incompleteness of models.

-Pragmatic quality is the degree of correspondence between model and audience interpretation (i.e., the degree to which the model has been understood). Usually, it is neither necessary nor possible that all stakeholders understand the entire conceptual model. Instead each member of the audience should understand the part of the model which is relevant to him. The main structure of the framework by Lindland et al. is illustrated in (Figure 8).

Moody et Shanks's framework

Moody and Shanks propose a framework for evaluating the quality of conceptual data models (D. L. [START_REF] Moody | What makes a good data model? Evaluating the quality of entity relationship models[END_REF]. It is intended to provide practitioners with a coherent approach to resolving two keys problems which arise in the practice of data modelling: the need to choose between a number of alternative data models and the need to understand and accommodate the different views of the various stakeholders in the data modelling process.

The first problem focuses on what makes one model of higher quality than another, and the second focuses on how the quality of a data model can be improved to meet the needs and expectations of all stakeholders. This framework provides a systematic basis for the evaluation of data models in practice.

It consists of seven main components: model, quality factor, stakeholder, evaluation method, weighting, rating, and strategy.

-A quality factor is a desirable property of a data model. Five quality factors are proposed: correctness, completeness, understandability, flexibility, and simplicity.

-A stakeholder is a participant involved in the data modelling process (business users, data analysts, application developers, and data).

-A strategy is a process or activity which can be used to increase the value of a data model with respect to one or more quality factors.

-An evaluation method or metric is a systematic way of measuring a quality factor.

-A weighting is a value assigned to a quality factor which represents its relative importance in the context of the project.

-A rating is a value assigned to a quality factor representing its validation in a particular model by a stakeholder. Business process modelling is an important tool for understanding and revealing weakness of business processes. The quality of a business process builds on the quality of its functions, input and output, non human resource and human resource participating in the process [START_REF] Heravizadeh | Dimensions of Business Processes Quality (QoBP)[END_REF]. As all these concepts are present when modelling the business process, the quality of business process is directly influenced by the quality of its model.

Process model quality measurement

Quality measurement procedures aims to quantify the quality level [START_REF] Overhage | Quality Marks, Metrics, and Measurement Procedures for Business Process Models[END_REF]. Abd [START_REF] Ghani | Complexity metrics for measuring the understandability and maintainability of Business Process Models using Goal-Question-Metric (GQM)[END_REF]) proposed a Goal-Question-Metric (GQM) framework for measuring the understandability and maintainability of BPMs. The Goal-Question-Measure approach consists in identifying customers goals, and then identifying a set of target attributes. In other words a GQM defines project goals and a set of questions to achieve each goal. Then the team develops metrics to address each question. One of the questions asked is: how easy is it to read the model? The answer would be the number of symbols and formulas used and type of structures used.

We choose to be based on Lindland's framework. predicted by the independent variables. They found that Lindland's framework categories account for more than 93% of the variance in Overall Quality. This provides strong evidence that the set of quality categories is rather complete. Moreover, they studied the independence of the quality Categories, there was no evidence of multicollinearity between the quality categories.

Syntactic quality

The syntactic analysis deals with the purely structural aspects of the model. There is only one syntactic goal, syntactic correctness, meaning that all statements in the model are compliant to the syntax of the language. All the articles proposing quality metrics for business process models mention the similarities between a software process and a business process. Basing on this hypothesis, they apply software metrics to evaluate business process models. In this section, we will analyze and summarize the syntactic metrics existing in the literature into four categories: size, complexity, structure, and modularization.

Size of the model

In an attempt to minimize the influence of "size", there are hundreds of software complexity metrics that have been described and published by a significant number of researchers. Three size measures are reported in (J.-P. [START_REF] Van-Belle | Empirical Evaluation and Comparison of Enterprise Models: A Framework and Its Application[END_REF]): 1) entity counts the total number of entities (classes) in the model, 2) CASE size (or concept counts the number of entities, relationships and group elements) and

3) the number of lines of code (LOC) which simply counts the lines of executable code, data declarations, comments, and so on. While these measures are extremely simple, they have been used

successfully for the purposes like predicting the error rate, estimating development and maintenance costs (J.-P. [START_REF] Van-Belle | Empirical Evaluation and Comparison of Enterprise Models: A Framework and Its Application[END_REF]).

Complexity of the model

We should distinguish between the structural complexity and the workflow complexity of the model.

Aguilar et al [START_REF] Aguilar | Applying Software Metrics to evaluate Business Process Models[END_REF]) suppose the adaptation and extension of the FMESP( framework for the modelling and evaluation of software processes) [START_REF] García | FMESP: Framework for the modeling and evaluation of software processes[END_REF]. They measure the structural complexity of software process models. The aim is to evaluate the influence of the structural complexity of the software process models on their maintainability.

Metric

NDWP(PM)=NDWPIn(MP)+NDWPOut(MP)

NDA Number of precedence dependencies between activities.

NCA Activity coupling in the process model.

NCA(PM) = NA(PM) / NDA(PM)

RDWPIn Ratio between input dependencies of work products with Activities and total number of dependencies of work products with activities.

RDWPIn(PM) = NDWPIn(PM) / NDWP(PM)

RDWPOut Ratio between output dependencies of work products with activities and total number of dependencies of work products with activities.

RDWPOut(PM)=NDWPOut(PM)/NDWP(PM)

RWPA Ratio of work products and activities. Average of the work products and the activities of the process model.

RWPA(PM) = NWP(PM) / NA(PM)

RRPA Ratio of process roles and activities. In [START_REF] Cardoso | Business process quality metrics: log-based complexity of workflow patterns[END_REF] the Control-Flow Complexity (CFC) metric evaluates the complexity introduced in a process by the presence of XOR-split, OR-split, and AND-split constructs. For XOR-splits, the control-flow complexity is simply the fan-out of the split, i.e. CFCXOR-split(a)= fan-out(a). For ORsplits, the control-flow complexity is 2n-1, where n is the fan-out of the split. i.e. CFCOR-split(a)= 2fan-out(a)-1. For an AND-split, the complexity is simply 1, i.e. CFCAND-split(a)= 1.

RRPA(PM) = NPR(PM) / NA(PM)

Itt is necessary to be able to evaluate the quality of a business process model, which in tern requires a set of quality metrics. The latter provide guidance to improve business process models by giving the modeler information about different quality criteria of business processes such as complexity, cohesion, etc.

Structure of the model

One specific category of BP syntactic quality metrics is coupling, which measures the functional and informational dependencies between the tasks/processes in a business process model. Coupling in business process models (BPM) focuses on how strongly the activities in a business process are related, or connected, to each other. The application of these measurements is straight forward if the process model is available in a graph-based notation [START_REF] Khlif | Quality metrics for business process modeling[END_REF]. The average degree, also called coefficient of connectivity refers to the average number of connections that a node has with other nodes of the process. In contrast to that, the density metric links the number of available connections to the number of maximum connections for the given number of nodes.

Moreover the definition for coupling used in (Vanderfeesten, 2013) was taken from the definitions found in the software engineering area since it measures the number of interconnections between the activities in a process model. The degree of coupling depends on how complicated the connections are and also on the type of connections between the activities. So they define a new coupling metric, based on the existing ones and inspired by software metrics, which weights different connections between activities (e.g. AND, OR, XOR). This metric is defined below.

)

1 ( * ) 2 , 1 ( 2 , 1 - ∑ = ∈ T T t t connected CP T t t where connected (t1,t2) = 1 ,if ( 2 1 t t → ) ( ) 2 1 t t ≠ ∧ 1 ,if ( ) ( ) 2 1 2 1 t t t AND t ≠ ∧ → → ( )( ) ( )( ) ( )( ) n m n m n m n m . 1 . 1 2 . 1 2 1 1 2 . 1 2 1 2 . 1 2 1 - - - - - + - - ,if ( ) 2 1 2 1 ) ( t t t OR t ≠ ∧ → → n m. 1 , if ( ) 2 1 2 1 ) ( t t t XOR t ≠ ∧ → → 0 , if (
)

2 1 t t =
in which t1 and t2 are activities, m is the number of ingoing arcs to the connector, and n is the number of outgoing arcs from the connector.

Moreover in [START_REF] Khlif | Coupling metrics for business process modeling[END_REF], the author's contribution consists in adapting object oriented software coupling metrics for business process models. This adaptation is based on correspondences they established between concepts of the Business Process Modelling Notation and object oriented concepts.

• ICP (Imported Coupling of a Process): counts, for each (sub-) process, the number of message/sequence flows sent by either the tasks of the (sub-) process or the (sub-) process itself.

• ECP (Exported Coupling of a Process): counts, for each (sub-) process, the number of message/sequence flows received by either the tasks of the (sub-) process or the (sub-) process itself.

• MPC metric: In the business process domain, it is the number of message or sequence flows sent directly from a process task to a task of another process. Note this measure takes into account only the coupling in terms of interaction between tasks. Thus, it helps to estimate the degree of dependency between the process tasks and the tasks of other processes.

• RFC metric: RS = {Tj} U {Ri} is the set of all responses of a process, where {Ri} is the set of resources invoked by a task i in the process and {Tj} is the set of all tasks j in the process.

Note that, the larger the RFC is, the greater the complexity of the process is: Indeed, if a large number of tasks can be invoked in response to a message, then the process becomes complex and requires a greater level of understanding.

• Locality of Data (LD): This metric links data from the activity (process or sub process) to the total data used by this activity.

Modularization of the models

Cohesion measures the coherence within the parts of the model. The authors in (Hajo A. [START_REF] Reijers | Cohesion and Coupling Metrics for Workflow Process Design[END_REF]) developed a cohesion metric for workflow processes which looks at the coherence within the activities of the process model. Similar to their coupling metric, this cohesion metric also focuses on the information processing in the process and takes a data oriented view. For each activity in the process model, the total cohesion is calculated by multiplying the information cohesion and the relation cohesion of the activity.

Dividing a BPM in modular sub-models cannot only help to make the BPM easier to understand, it can also lead to smaller, reusable models -if modularization is used in a reasonable way (Gruhn et Laue 2006). They measure the fan-in and fan out for every module, where fan-in is a count of all other modules that call a given module and fan-out is a count of all other modules that are called from the model under investigation. Finally, some research, such as (Jan Mendling, Neumann, et Van Der Aalst 2007a) aims to analyze the connection between formal errors and a set of metrics that capture various structural and behavioural aspects of a process model.

• Size SN, which refers to the number of nodes of the process model graph. An increase in SN should imply an increase in error probability.

• Coupling or density Δ, relates the number of arcs to the maximum number of arcs between all nodes. They presume a positive connection i.e. an increase in Δ implies an increase in error probability.

• Control Flow Complexity CFC, sums up all choices of a process based on the number of splits of each type and its number of outgoing arcs presume a positive connection.

Yet [START_REF] Ehrig | Measuring similarity between semantic business process models[END_REF] have shown that calculating only syntactic and linguistic similarities is insufficient since the instance context is not considered and homonyms can not be discovered.

We shall now move to the second category of Lindland's framework, the semantic quality.

Semantic quality

The primary goal of semantic quality is to improve the correspondence between the model and the domain, but this correspondence can neither be established nor checked directly. To build the model, one has to go through the audience's understanding of the domain. To check the model, one has to compare it with the audience's interpretation of the model. Semantic quality improves model efficiency and effectiveness in the activity semantics, reducing the precision deficit in modelling. It leads to a better understanding and knowledge.

The framework in (Krogstie, Lindland, et Sindre 1995b) contains two semantic goals: validity and completeness.

• Validity: means that all statements made by the model are correct and relevant to the problem.

• Completeness: means that the model contains all the statements which would be correct and relevant about the problem domain. (Krogstie, Lindland, et Sindre 1995b) gives a definition for the degree of validity and completeness:

Validity = M D M - 1 Completeness = D M D - 1
Where M represents all the statements made in the model, D represents the statements that are correct and relevant about the domain at hand.

We will analyze and summarize contributions on semantic quality measurement according to these two categories: validity and completeness of models.

Validity of the models

Process is aimed at attaining a goal, which is a set of stable states that satisfy a condition over a criterion function. A process model will be called a valid model if and only if there exists at least one successful process path, where a successful process path is a path that leads to a stable state which is in the process goal set. Based on this definition, they distinguish three types of situations when a process model is invalid i.e. (is not guaranteed to reach its goal).

1. Incompleteness in the process definition: It may be that a certain combination of state variables in the domain does not appear in the process definition. And incompleteness can relate to internal events where the step j of the process does not provide all the information needed to trigger the step j+1 of the process. It can be related also to external events.

2. Inconsistency between the functions of the process and the process definition: It is possible that when the process begins progressing, it reaches a state from which it cannot proceed further to reach a goal state. Two possibilities exist. First the process entered into an infinite loop where activities cause transitions without reaching a stable state. Secondly the process reached a stable state not in the goal. For both cases, there is no continuous path from the start state to a goal state.

3. Dependency of the process on external events, where the process is "waiting" for an external event, with no guarantee that this external event will eventually occur.

Validity also can be affected by the expressiveness, the readability and the clarity of the model. (J. V.

Belle 2004) defines the expressiveness of the model. An expressiveness score can be calculated as the weighted index of the number of meta-model attributes covered in a model.

Model readability refers to the extent to which the model can be understood or comprehended by the users of the model. The perspicuity (clarity) analysis is based on matching all model element names against common domain vocabulary lists.

In [START_REF] Soffer | Goal-driven analysis of process model validity[END_REF] the authors propose a generic theory-based process modelling framework as well as criteria for validity evaluation of process models. They discuss and characterize causes for process invalidity and they suggest ways to avoid these situations.

Completeness of the models

Rozinat et al. in [START_REF] Rozinat | Conformance testing : Measuring the fit and appropriateness of event logs and process models[END_REF]) describe an approach for measuring the compliance between events logs and process models. This compliance measurement indirectly enables the evaluation of BP model completeness. These BP models represent how the system should be used.

Pirro in [START_REF] Pirró | A semantic similarity metric combining features and intrinsic information content[END_REF] proposes a new semantic similarity that exploits some notions of the featurebased theory of similarity. In particular, the proposed metric exploits the notion of intrinsic information content (IC) which quantifies IC values by scrutinizing how concepts are arranged in an ontological structure.

• Similarity Metrics based on WordNet: it's a similarity metric between concepts that belong to the information theoretic approach, which can be considered as a measure quantifying the amount of information a concept expresses. Knowing the IC values for each concept, we may then calculate the similarity between two given concepts.

• Similarity Metrics based on ontology approach: two initiatives have been studied. The first referred to a depth based approach and the second to a path based approach.

• Similarity Metrics based on hybrid approach: it combines different sources of information to assess a score of similarity or distance between concepts.

The third and last category of Lindland's framework concerns the pragmatic quality and is summarized below.

Pragmatic quality

Pragmatics relates the model to the audience (those who are involved in modelling). It defines how well the model corresponds to its audience interpretation. Pragmatic model quality (PMQ) refers to the user's interpretation of the model. This is typically understood as the comprehensionability or understandability of a model [START_REF] Gemino | Complexity and clarity in conceptual modeling: Comparison of mandatory and optional properties[END_REF], [START_REF] Krogstie | A Semiotic Approach to Quality in Requirements Specifications[END_REF]. The common measure for comprehension involves asking the user a number of questions that relate to the meaning of the model and that can only be answered right if the model is understood [START_REF] Rittgen | Quality and perceived usefulness of process models[END_REF]).

Krogstie et al (Krogstie, Lindland, et Sindre 1995b) confirmed that there is only one pragmatic goal: comprehension, that is, how well the model has been understood by the audience.

The authors in (Jan [START_REF] Mendling | What Makes Process Models Understandable?[END_REF] focused on the understandability of process models as an enabler of pragmatic quality. They concluded that measurement of the BP model understandability should include the purpose of the BP model and the field of knowledge that it exploits.

Understandability is defined as the ease with which the concepts and structures can be understood by the users of the model (D. L. [START_REF] Moody | What makes a good data model? Evaluating the quality of entity relationship models[END_REF]. They propose three metrics to measure the understandability of a model. 4. Business user rating: The user must be able to understand the model in order to verify that it is a complete and accurate representation of his/her requirements. 5. Data administrator rating: He/She must be able to understand the model. 6. Application developer rating: He/She relies on the model for implementing it. Thus the model must be a complete specification of the user requirements.

Empirical studies of process modelling are aimed at gaining an understanding that can guide the development of higher quality models [START_REF] Soffer | Towards Understanding the Process of Process Modeling: Theoretical and Empirical Considerations[END_REF]. Soffer et al. propose to study the process of process modelling based on problem solving theories. (Table 7) represents a summary of the research questions that can be asked with basic features of possible experimental designs. Unfortunately, most pragmatic criteria involve a substantial degree of subjectivity. Therefore the discussion in (J. V. Belle 2004) is limited to the two pragmatic measures which are believed to be more objective and universally applicable:

• Model authority refers to the acceptance of the model by practitioners in the field.

• Model flexibility is concerned with how well models can be changed or adapted to different situations.

Moreover, flexibility is defined as the ease with which the model can be adapted to changes in requirements. It is a major determinant of the maintenance costs of a system. The senior management, the industry expert and the expert modeller can rate the flexibility of a model (D. L. [START_REF] Moody | What makes a good data model? Evaluating the quality of entity relationship models[END_REF].

Based on the quality evaluation results, improvements should be applied on the model in order to improve its quality. Thus a quality approaches should contain two main parts: 1) Evaluation of the quality, which is done by different evaluation procedures and 2) Improvement of the quality, which is done by improvement guidelines.

Quality approaches

Quality approach's evaluation procedure covers the measurement task and the defining quality criteria task. Most proposals specify these quality criteria without evaluating how they should be measured.

As a result, the approach should develop formal metrics for measuring quality of the models to reduce subjectivity. Quality approach's improvement procedure should cover the definition of guidelines, improvement patterns, recommendations and other actions that aim to improve the model. Most of the approaches in the literature focus on the evaluation of the model and ignore the issue of improving it.

However, quality management approaches have not yet provided an effective solution to the quality evaluation and improvement issues. Progress in conceptual models can only be made by approaches that are able to integrate quality measures and schema improvements.

Graeme Shanks [START_REF] Shanks | Conceptual Data Modelling: An Empirical Study of Expert and Novice Data Modellers[END_REF]) studied the difference between conceptual models designed by domain experts and those designed by novices by evaluating them using a quality metrics synthesized from previous studies. They concluded that models produced by experts are more correct, more complete, more innovative and more flexible than those produced by novices. Similarly, [START_REF] Batra | Conceptual Data Modelling in Database Design : Similarities and Differences between Expert and Novice Designers[END_REF] found that conceptual models modelled by novices have problems with the domain description but both models are similar in terms of syntactic quality. None of these studies shows how to use this knowledge to improve the quality of models.

Approaches dedicated to conceptual models quality

There are many quality management studies which are not specific to the field of BPM but might be adopted. We will start with Eick's approach. He surveys the back end of a conceptual model called ANNAPURNA [START_REF] Eick | A Methodology for the Design and Transformation of Conceptual Schemas[END_REF]. He introduced quality measures in order to evaluate the validity of the model. To be valid, the model should answer the following quality criteria:

-Completeness: The model is complete if it allows the specification that satisfies the information requirements.

-Rule correctness: The model is called rule correct if the rules defined in the model are not violated.

-High expressive power i.e. it should be possible to describe all rules that hold in a universe of discourse.

-Low complexity in terms of the number of classes and attributes needed for a particular specification.

-Normalized i.e. the equivalent or the similar objects are described in the same way in the model.

Furthermore, in his work, he defined schema transformations in order to improve the model and make it valid. The transformation based on unary and binary relations is possible to specify classes, subclasses and attributes.

Finally, he defined an evaluation function that incorporates the three criteria: complexity, normalized ness and expressiveness:

1. Complexity of the model is measured by the number of classes, subtype-connections, and attributes.

2. Normalizedness is measured by an evaluation function using the number of labels. The models that carry few labels are preferred.

3. The expressiveness of a model can be measured by the number of general functional (expressing at most one constraint) and existence dependencies that hold in the transformed model but which have not been expressed in the model.

In his approach, Eick evaluates the syntactic quality by measuring the complexity of the model, the semantic quality by measuring the normalized ness and finally the pragmatic quality by measuring the expressiveness of the model. As our thesis is oriented towards business process models, we are concentrating on the approaches dedicated the latter.

The quality evaluation procedure of Business process models is not limited to the analysis of the model structure quality. The semantics of the models also should be analyzed. For Dijkman et al. [START_REF] Dijkman | Semantics and analysis of business process models in BPMN[END_REF], BPMN is dedicated to the specification of the syntactic constraints of models but it is inconsistent when it comes to defining the models semantics. On the other hand, Petri net is dedicated to study the semantic behaviour of the model. They proposed to map the BPMN to Petri nets in order to fulfill this gap. Each concept in BPMN is represented by a Petri net concept. These mappings have been implemented in a "ProM" tool, which verifies the soundness of BPMN models.

Approaches that evaluate business process model's quality

First of all, before evaluating the models quality, researchers have concentrated on the modelling competence level. As in Mendling and al's paper (Jan Mendling, Reijers, et van der Aalst 2008), they concentrated on the problem of the low modelling competence level and analyzed existing research on relationships between model structure on the one hand and error probability and understanding on the other hand. As a synthesis they proposed a set of seven process modelling guidelines (7PMG).

As a matter of fact these guidelines are defined in order to make the model more comprehensible, more understandable.

G1: Use as few elements in the model as possible G2: Minimize the routing paths per element.

G3: Use one start and one end event.

G4: Model as structured as possible.

G5: Avoid OR routing elements.

G6: Use verb-object activity labels.

G7: Decompose the model if it has more than 50 elements.

The authors concentrate on several quality criteria that affect the quality of the business process models and propose seven guidelines to improve each of these criteria.

Furthermore, guidelines of Business process modelling are proposed by Becker et al. (Becker, Rosemann, et Uthmann 2000a). Guidelines of modelling (GoM) framework not only provide factors for the evaluation of process models but also guidelines of modelling for workflow management and simulation are presented. It adopts elements from existing approaches for the evaluation of models such as correctness, relevance, economic efficiency, clarity, comparability, and systematic design. But the basic guidelines consist of the guideline of correctness, the guideline of relevance, and the guideline of economic efficiency.

Other studies of Mendling et al, have concentrated on the understandability of the models (Jan [START_REF] Mendling | Influence Factors of Understanding Business Process Models[END_REF]. They discussed the factors that influence the understandability of the business process models. In fact their contribution is based on two steps: first they identified three categories of understandability factors: personal, structural, and textual. Second, they presented the importance of these factors. Furthermore they calculated some model metrics such as size, structuredness, separability, cyclicity, heterogeneity, etc. and some metrics related to the textual labels such as Textlength, correct answer. Finally for the personal metrics they defined a Pscore (It captures the number of correct answers by the person.) and a Mscore (it captures the sum of correct answers for the model given by the participants).

An attempt to develop a "Quality of Business Process framework ( QoBP) " was made by Heravizadeh et al. [START_REF] Heravizadeh | Dimensions of Business Processes Quality (QoBP)[END_REF]. They identified four generic quality categories of business process quality and populate them with quality requirements from related research. The quality dimensions are arrayed along the categories of:

-Function quality: A function is an activity in a BPM which needs to be executed. They mentioned 13 quality dimensions derived from the literature to evaluate the activity and suitability, accuracy, security, reliability, understandability, learn ability, time efficiency, etc -Input/Output quality: Inputs and outputs of a function or an activity represent the information or objects that are consumed and produced by it. Similarly, they adopted quality metrics from the literature such as accuracy, objectivity, accessibility, etc.

-Non human resource: Functions may be executed by non-human resources such as machines, devices, or software programs. It can be measured by the availability metric.

-Human resource: Functions may be executed by human resources. Metrics such as domain knowledge, qualification, certification, experience, etc may evaluate them.

Henrich and Paech proposed a business process quality framework based on software quality [START_REF] Heinrich | Defining the Quality of Business Processes[END_REF]. They used software quality to derive eight activity characteristics:

Functionality, reliability, usability, efficiency, maintability, portability, quality in use and compliance.

Business process reengineering and optimization is related to the BPM improvement domain. A framework for classifying the best practices was given in Reijers et al's paper (H.A. [START_REF] Reijers | Best practices in business process redesign: an overview and qualitative evaluation of successful redesign heuristics[END_REF]. This framework described 29 best practices and evaluated qualitatively their impact on the cost, quality, f1exibility and time criteria.

Evaluation is not restricted on the evaluation of the model structure. On the contrary, business process models contain control-flow errors such as deadlocks and the lack of synchronization. Such errors affect the code generation and the execution of these models. Therefore detecting and removing control-flow errors becomes a main goal of the Business process quality management studies. In the literature different approaches can be used to check the soundness of business process models such as the IBM WebSphere Business Modeller / SESE approach [START_REF] Vanhatalo | Faster and More Focused Control-Flow Analysis for Business Process Models Through SESE Decomposition[END_REF], CTL model checking used by the Petri net model checker LOLA [START_REF] Wolf | Generating Petri net state spaces[END_REF], and Petri net analysis techniques used by Woflan [START_REF] Verbeek | Diagnosing Workflow Processes Using Woflan[END_REF]. To start with the Petrinet analysis techniques, a Petri net model should at least satisfy the following conditions:

-It should always be possible to complete a case i.e. no deadlocks and no live-locks.

-It should not be possible to attend an end event while the process is not finished yet.

-Every task in the model should have a path to be attempted.

To conclude, the verification of a Petri net should guarantee the effectiveness and the efficiency of the model. They also developed a diagnosis process in order to guide the designer in finding and correcting the errors. To do so, they developed the Woflan tool.

Secondly, the single-entry-single-exit (SESE) technique aims to analyze and improve the business process models by decomposing the model into SESE fragments. This approach speeds up the control flow analysis by detecting the structuredness errors and the complexity of the model.

Thirdly, the LoLA tool generates state space reduction techniques for the purpose of verifying a particular property.

Some of the properties that can be verified include:

-Reachability of a given state, -Existence of deadlocks, -Existence of home state, -Liveness of a state predicate.

Fourthly, a novel approach called "causal footprints" (Dongen et Mendling 2006), represents a set of conditions that should be verified by the process model. They identified three kinds of error patterns that affect the soundness of a process model: the deadlock pattern, the multiple termination patterns and the trap pattern.

In short, all these techniques aim to verify the soundness of business process models. Some provide analysis techniques; others propose metric evaluation and improvements. Some are limited to one notation such as SESE and others can be applied on several notations i.e. the Casual Print.

Hallerbach et al. discuss how to ensure soundness for an entire process family [START_REF] Hallerbach | Guaranteeing Soundness of Configurable Process Variants in Provop[END_REF]. They have described the Provop approach that aims to ensure the soundness of the configurable variants of a whole process family taking into account semantic as well as structural constraints. They extended the ABIS approach of adaptive business process modelling with soundness concepts and with an algorithm to apply them.

An approach aimed to automatically correct errors in an unsound process model presented by [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]). Their approach considers three dimensions: the structural distance, behavioural distance and badness of a solution w.r.t. the unsound process model. The approach uses simulated annealing to simultaneously minimize all three dimensions. The edits applied to the process model are aimed to correct the model rather than to balance the five different forces.

Approaches for business process improvement

Forster ( Forster 2013) defines Business Process Improvement as a systematic approach to help organizations to achieve significant changes in the way they do business. So far, academic research has mainly focused on the description of successful Business Process Improvement implementations.

Usually only the situations before and after implementation are outlined, but not the actual act of improvement ( Forster 2013).

Harington [START_REF] Harrington | Performance improvement: the rise and fall of reengineering[END_REF] Process Redesign: Process Redesign is described by Davenport et al. [START_REF] Davenport | Putting the enterprise into the enterprise system[END_REF] as the analysis and design of work flows and processes within and between organizations. Business Process

Reengineering aimed to help organizations fundamentally rethink how they do their work in order to dramatically improve customer service, to cut operational costs, and become world-class competitors [START_REF] Jr | Business Process Reengineering Assessment Guide[END_REF]. In order to redesign a business process, they defined five major steps involved:

Develop the business vision and process objectives: Business vision depends on the company's management. This vision can involve taking the perspective of the customer and developing systems rather than standalone products. It can also consist of improving product quality. Thus multiple objectives in redesigning processes, for example, set out to improve the cost, time, and quality.

Identify the processes to be redesigned: There are two major approaches to identify the processes to be redesigned: the exhaustive approach attempts to identify all processes within an organization and then prioritize them in order of redesign urgency. The high-impact approach attempts to identify only the most important processes or those most in conflict with the business vision and process objectives.

Understand and measure the existing process: There are two primary reasons for understanding and measuring processes before redesigning them. First, problems must be understood so that they are not repeated. Second, accurate measurement can serve as a baseline for future improvements. Thus measurement is related to the objectives of the redesigning process. For example if the objective is to cut time and cost, the time and cost consumed by the untouched process must be measured accurately.

Identify information technology levers: IT usage has always been to first determine the business requirements of a process, or other business entity, and then to develop a system. Thus the awareness of IT capabilities can influence process design.

Design and build a prototype of the new process: using IT as a design tool, understanding generic design criteria, and creating organizational prototypes.

Process Reengineering: Reengineering means to disregard all the assumptions and traditions of the way business has always been done, and instead develop a new, process-centered business organization that achieves a quantum leap forward in performance [START_REF] Hammer | Reengineering the Corporation: A Manifesto for Business Revolution[END_REF].

Reengineering is defined as the fundamental rethink and radical redesign of business processes to generate dramatic improvements in critical performance measures such as cost, quality, service and speed. Based on Hammer et al.'s study, reengineering initiatives typically lead to simplified business processes, a multi dimensional description of tasks, a flatter arrangement of the organizational structure, a focuses on the professionals not the managers and an aligned with the end_to_end process.

Additionally, Tawlar [START_REF] Talwar | Business re-engineering-a strategy-driven approach[END_REF]) define business process re-engineering as a way to deliver discontinuous leaps in performance. He mentioned two main approaches to re-engineering. The firstknown as Process re-engineering, offers the opportunity to rethink and streamline individual processes. The second-termed Business Re-engineering provides an approach to rethinking and redesigning the entire business behind a more focused, competence based competitive strategy.

The central challenge in re-engineering is to understand where and how we can create value for both customers and shareholders. This requires us to ask fundamental questions about what we do, how we do it, whether it is necessary and how it can be improved.

Business Process Change: Paul Harmon's Business Process Change is an outstanding overview and a comprehensive guide to business process initiative [START_REF] Harmon | Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes[END_REF].

Harmon compellingly argues that organizations are systems, and consequently, that processes are the optimal vehicle to analyze and manage organizations. Determining how process methodologies interact, what they involve, which ones are appropriate in which situation, etc., is difficult and not often covered by other texts. Business Process Change provides an easily digestible positioning of the interactions and applications of the numerous process approaches. After setting the context, Business

Process Change moves into a very practical introduction to process modelling basics. The ability to interpret and interact with process models is at the core of all process initiative. Business Process Change then moves on to the more radical approach of process redesign or new process creation.

Lastly, Harmon addresses the large area of business process automation through workflow systems, pre-packaged applications and custom software development.

All these methodologies address the same notion of enhancing the work in organizations by means of Business Processes. However, the level of change, the starting point, the frequency of change, the time and scope differ.

Apart from these methodologies, some researchers came with the hypothesis that they can rely on existing models to complete or improve their models. Chan et al. [START_REF] Chan | Assisting Business Process Design by Activity Neighborhood Context Matching[END_REF] introduced the concept of activity neighbour context. They recommend to the designer the activities that are close to the process under design from existing business processes. Close activities are detected by calculating the "sem" metric, they capture the similar activities and assist the designer in order to improve the process. Also Holschke et al. worked on lining services of business activities (O. [START_REF] Holschke | Business Process Improvement by Applying Reference Process Models in SOA-a Scenario-based Analysis[END_REF]). In fact they analyzed a scenario for business process improvement by applying reference models in a Service Oriented Architecture (SOA) environment. Additionally, they proposed a method for evaluating the implementation effort based on a cost model. They concluded that the use of reference models in business process improvement will contribute to better models. Furthermore, Assenova et al. [START_REF] Assenova | Improving quality in conceptual modelling by the use of schema transformations[END_REF] aim to improve the schema quality by suggesting an approach based on a systematic use of schema transformations. They introduced a set of quality criteria for conceptual schemas (homogeneity, explicitness, size, rule simplicity, rule uniformity, query simplicity, and stability) and they showed how the transformations affect these criteria.

As the models are related to the real world events and demands, there is a big risk of requirements redundancies and of increasing the complexity of the model. Weber et al. developed process model refactoring [START_REF] Weber | Refactoring large process model repositories[END_REF]). They introduced a set of behaviour-preserving techniques for refactoring large process repositories which help the designers to simplify their models and to reduce redundancy.

Detecting deviations of a process model from the observed behaviour has been researched, among others, by W. van der et al. (W. van der Aalst, Adriansyah, et [START_REF] Van Der Aalst | Replaying history on process models for conformance checking and performance analysis[END_REF]. Given a process model and an event log, deviations are expressed in the form of skipped activities (activities that should be performed according to the model, but do not occur in the log) and inserted activities (activities that are supposed to happen according to the model, but that occur in the log). A cost is attributed to these operations based on the particular activity being skipped/ inserted. Based on this information, an alignment can be computed between the process model and the log, which indicated how well the process model can describe the recorded behaviour. While this approach provides an effective measure for the replay fitness quality dimension, the approach does not suggest any corrections to rectify the process model's behaviour.

Buijs and al. [START_REF] Buijs | Improving business process models using observed behavior[END_REF]) proposed a novel process mining algorithm that improves a given reference process model using observed behaviour, as extracted from the event logs of an information system. The proposed algorithm is able to improve the model with respect to the four basic quality aspects (fitness, precision, generalization, and simplicity).

While an extensive set of research contributions has been made on the model's concepts structure verification and improvement techniques, others focus on the style of activity labelling.

Recent research revealed the high impact of the labelling style in business process models on the semantic and pragmatic quality of the models: labelling styles in Business Process Models [START_REF] Leopold | Recognising Activity Labeling Styles in Business Process Models[END_REF] and refactoring the activity labels [START_REF] Leopold | On the refactoring of activity labels in business process models[END_REF] constitute an approach to improve the semantic of the concepts labels. They started their study by differentiating the activity labelling styles as "Verb phrase", "Noun phrase", " Phrase with coordinating conjunctions"… etc. To recognize each of the labelling style, algorithms are proposed.

The goal of these algorithms is to evaluate them and to aid the modellers in labelling their models.

Thus, they completed their research by designing a technique for the automatic refactoring of labels with quality issues. More specifically, they developed an algorithm that is able to correct the activity labels.

The refactoring algorithm works in four phases:

1. Recognition of the activity labelling style 2. Analysis of action-noun labels 3 Derivation of an action and a business object from activity label 4. Composition of a verb-object activity label.

Finally, to evaluate their approach, they introduced two quality metrics: refactoring gain which represents the share of labels which has been correctly refactored and refactoring effect takes into account the erroneously refactored labels. The results of the refactoring shows the growth of the gain curves i.e. the increasing number of gain. They also shows the maintenance of the effect curves i.e. no effects were noticed.

Business process models can also face semantic deficiencies such as ambiguity issues caused by synonyms or different abstraction levels for process element names. Ehrig et al. [START_REF] Ehrig | Measuring similarity between semantic business process models[END_REF] propose, in order to solve such problems, the use of ontology-based description of process models. They proposed an approach, based on ontology concepts, to measure the similarity between business process models, by calculating the syntactic, linguistic and structural aspects similarities. Also [START_REF] Galatescu | Ontologies for Analysis and Improvement of Business Process Quality in a Virtual Enterprise[END_REF]) used three ontologies in a software aiming to assist the improvement and analyze business process models in a virtual enterprise. The ontologies provide the team-based work in BPI with a common vocabulary for the team: automatic integration of verbal diagrams and structures with ideas, communication with structures and an extensible user interface.

It should be mentioned that ontologies can be used for several purposes, provide the team-based work in BPI with a common vocabulary (Alexandra Galatescu 2004), for product data management interoperability [START_REF] Panetto | ONTO-PDM: Product-driven ONTOlogy for Product Data Management interoperability within manufacturing process environment[END_REF], etc.

McCusker et al. [START_REF] Mccusker | Towards an Ontology for Conceptual Modelling[END_REF] show how using an ontology for conceptual modelling provides a common vocabulary which leads to unambiguous models. Shanks et al [START_REF] Shanks | Using ontology to validate conceptual models[END_REF] show how ontologies can be used to facilitate the modelling task and how it can be used to valuate the fit between an organization's needs and the business models.

They came with the conclusion that ontology helps ensure that they select a conceptual modelling grammar needed to produce high-quality models of the focal domain. It can also guide the grammar used to generate clear, complete descriptions of the domain and that the can be used to help make sense of ambiguous semantics in conceptual models that need to be validated. shows that the best way to express creative thoughts is through visual imagery in art [START_REF] Kosslyn | Aspects of a Cognitive Neuroscience of Mental Imagery[END_REF], ergo in graphical patterns that simplify complex circumstances. The idea of trying to identify, analyze, design and organize patterns by describing commonly recurring constructs has been popular in the software community [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. Various kinds of patterns are currently in application.

Business process improvement patterns

We can cite from the literature two types of patterns: adaptation patterns and workflow patterns.

Adaptation patterns allow structurally changing process models using high-level change operations.

They can be applied along to the entire process lifecycle [START_REF] Weber | Change patterns and change support features -Enhancing flexibility in process-aware information systems[END_REF].

Workflow patterns were introduced for analyzing the expressiveness of process modelling languages.

Patterns cover different perspectives like control flow (Van Der [START_REF] Aalst | Business Process Management: A Survey[END_REF], data (Russell, Hofstede, et al. 2005), resources (Russell, Van der aalst, et al. 2005).

Ayora and al. [START_REF] Ayora | Enhancing Modeling and Change Support for Process Families through Change Patterns[END_REF] proposed nine patterns for dealing with changes in process families.

They complement existing work on patterns for creating and modifying BP models by introducing a set of generic and language independent patterns that cover the specific needs of process families.

They first present the research methodology they employed to identify these patterns. Then they identified the set of variability specific language constructs frequently used by existing proposals to capture the variability within a process family.

Comparison of quality approaches

(Table 8) summarizes the information about the different approaches presented in the previous sections. The comparison is done based on seven criteria. 1) What models the approach can be applied on? 2) Does the approach define quality criteria? 3) Does it define metrics in order to evaluate each quality criterion? 4) Does the approach provide guidelines or rules in order to improve the models By comparing these approaches, we can conclude that the majority of business process quality approaches concentrate on either quality evaluation using quality criteria and metrics or on quality improvement. Moreover each of these approaches is applicable on a specific notation.

Anyway, in order to have a complete quality improvement approach, it should:

• Be adaptable to different notations (BPMN, EPC, Petri-nets, etc.).

• Be able to evaluate models quality using metrics defined by defaults.

• Englobe a module to define quality metrics and apply them on the model.

• Define improvement procedures (textual recommendations, constraints, guidelines).

Conclusion

Most of the existing business process model quality studies are rich in syntactic quality metrics, but there is a lack in pragmatic and semantic metrics.

In the literature, studies that show the role of domain knowledge on the quality improvement does not provide any guidelines on how modellers can use this knowledge to improve business process models.

This thesis proposes a step forward in this direction. We aim to explore the domain knowledge to improve the semantic quality of the business process models.

In the following chapters, we present our solution for the above mentioned problems. Our solution includes the following:

i.

We define the semantic quality for business process models.

ii.

We propose an approach based on domain knowledge i.e. application domain knowledge extracted from ontologies and IS domain knowledge represented by semantic constraints to evaluate business process model semantic quality.

iii.

We enrich this approach with proposing guides helping business process modellers to improve their BP model semantic quality.

Chapter 3

IS and Application domain Knowledge

The solution proposed within this thesis aims to provide a method and tool support to help in constructing syntactically, semantically and pragmatically correct process models. Indeed, despite the recent efforts dedicated to improve notations and tools, business process modelling remains difficult since it relies heavily on the modeller's knowledge about the modelled domain and the notation used.

Approach overview

As sketched in (Figure 11), BP modelling as any conceptual modelling activity consists in creating and/or evolving a model considering a given domain requirements, under specified constraints, relying on knowledge about both the domain and the notation used (method knowledge).

The information elicited during this process has to be interpreted, analyzed and modeled before the analysts can feel satisfactorily confident of the requirements completeness and correctness.

In prior studies, which refer to the importance of application domain knowledge in requirements analysis, it has mostly been argued that it positively impacts the effectiveness of IS ( information systems) problem solving [START_REF] Antón | The Use of Goals to Surface Requirements for Evolving Systems[END_REF], [START_REF] Vessey | Learning to Specify Information Requirements: The Relationship Between Application and Methodology[END_REF].

When discussing problem-solving in general, it is important to differentiate between well and ill structured problems. Based on (Khatri et Vessey 2010b), a well-structured models are those that have a well-defined initial state, a clearly defined goal, a well-defined constrained set of activities. On the other hand, ill-structured models are those which the initial and goal states are vaguely defined or unclear. Further, the problem statement does not contain all the information needed for their solution.

The cognitive psychology literature presents evidence that prior domain knowledge may constrain the analyst's search [START_REF] Wiley | Expertise as Mental Set: The Effects of Domain Knowledge in Creative Problem Solving[END_REF].According to [START_REF] Chiesi | Acquisition of domain-related information in relation to high and low domain knowledge[END_REF] a. Lack of centralization: there exists in literature, as well as in notations' handbooks, dozens of rules and advices on the good use of concepts and constructs. However, this knowledge is generally spread out all over tool documentation, websites, research papers and a variety of other sources making its exploitation difficult. Our proposed solution gathers this knowledge and proposes a tool automating its exploitation to support both detection and correction of defects related to notation's conformance.

b. Lack of formality: our analysis of the IS domain knowledge revealed heterogeneity of formalization. While some guides are expressed using formal languages, others are textual and vague and some are just related to modelling expertise and are never explicitly expressed. We propose to use the Object Constraint Language (OCL) to express the rules and advices defining the "right" or the "better" usage of concepts and constructs. These constraints, formally expressed, are thus easy to correct, enrich and use within an automated support.

c. Heterogeneity of notations: there exists a variety of notations for BP modelling each having its own vocabulary and thus specific rules. To ensure the genericity of our approach, we build our reasoning on a BP modelling meta-model. The IS knowledge OCL constraints that are common and valid in all notations are generalized and thus written at the meta-model level making them independent from specific notations. There remain however some specific concepts that holds only for some notations. Our approach allows also the definition of constraints at notation level to handle specific situations. Finally, as models are expressed in different notations we have developed a set of corresponding rules between the meta-model's concepts and those of frequently used notations. An annotation tool uses these corresponding rules to annotate the models making them readable at both notation and meta-model levels.

(ii)

The application domain can be extracted from several sources such as user's requirements statements, domain expertise or existing models related to the same problem or to similar problems such as data models, resource models etc.. Within this thesis we do not address the problem of transforming requirements into models as this problem has been extensively covered by literature. Our objective is to use domain knowledge to help in improving a process model under construction. For example, domains such as healthcare, tourism etc. are facing the challenge of delivering reliable and high quality services at affordable costs. To tackle this challenge they develop decision support systems based on clinical pathways for the healthcare domain or services ontologies for the tourism domain. This knowledge domain is either used manually by actors as in the healthcare domain where clinical pathways are generally textual structured definitions of practices. It could also been exploited through an automated tool as in the case of web services composition [START_REF] Arpinar | Ontology-Driven Web Services Composition Platform[END_REF]. We are more interested in an automated usage of domain knowledge. Our solution relies on the existence of domain ontologies describing concepts and relationships related to the application domain. Such ontology could be the result of a collaborative work in a given domain such as the e-tourism ontology for data exchange in tourism business domain. They also could be constructed by integration of ontology fragments or a mapping process. The construction of such ontologies is out of the scope of this thesis and contributions on this problem can be found in the literature for several applications domains [START_REF] Daniyal | Computerizing Clinical Pathways: Ontology-Based Modeling and Execution[END_REF]) [START_REF] Kouneli | Modeling the Knowledge Domain of the Java Programming Language as an Ontology[END_REF]) [START_REF] Clark | Automatically structuring domain knowledge from text: An overview of current research[END_REF].

We present in this chapter how both IS domain and application domain knowledge are modelled, formalized in our solution. The next chapter is devoted to the process exploiting this knowledge to integrate quality objective into the modelling process.

Capturing IS domain knowledge

The term knowledge refers to the part of the world investigated by a specific discipline and that includes a specific taxonomy, vocabulary, concepts, theories, research methods, and standards of justification (P. A. [START_REF] Alexander | Domain Knowledge: Evolving Themes and Emerging Concerns[END_REF]. The first family of approaches concerns those focusing on methodological guides to ensure quality of models. In (Becker, Rosemann, et Uthmann 2000b) where the authors propose a set of guides to improve various characteristics of a process model such as clarity, comprehensibility, or accuracy (correctness). Other authors focus on improving the comprehensibility of models by providing naming rules, documentation, and use of icons or symbols graphs (Jan [START_REF] Mendling | On the Usage of Labels and Icons in Business Process Modeling[END_REF]. Other approaches, such as (Van Der [START_REF] Aalst | Business Process Management: A Survey[END_REF] propose a set of best practices encapsulated in reusable and applicable patterns depending on the context. A second category of approaches concentrate on the formalization of rules related to methods and notations. In [START_REF] Kent | A Meta-model Semantics for Structural Constraints in UML[END_REF] OCL rules are defined upon a UML meta-model to ensure the validity of structures. Other techniques, based on transformations, are also used to add semantics to meta-models [START_REF] Chen | Semantic anchoring with model transformations[END_REF].The last category explores the idea of combining ontologies, modelling and meta-modelling techniques to support conceptual modelling activity. In [START_REF] Kaiya | Using Domain Ontology as Domain Knowledge for Requirements Elicitation[END_REF] the authors use a domain ontology to help in requirements elicitations. The same authors present in [START_REF] Kaiya | Ontology based requirements analysis: lightweight semantic processing approach[END_REF] a general framework to conduct a modelling activity by the help of meta-models and ontologies.

Our approach fits both in the second and third categories as it uses domain knowledge to improve quality of business process models and OCL rules to express notation's semantics.

Business process modelling is mainly used to document, analyze, and optimize workflows. Hence it contains a lot of domain knowledge. In this chapter, we explain how we exploited the IS domain knowledge from the business process modelling notation and the application domain knowledge. Thus we can apply on them to evaluate and improve the quality of BP models.

There are several elaborate graphical notations that can be used for business process modelling, ranging from the most popular BPMN [START_REF] Omg | Business Process Modeling Notation[END_REF], EPC [START_REF] Kühne | Business Process Modeling with Continuous Validation[END_REF], to less known Eriksson-Penker's notation [START_REF] Penker | Business Modeling With UML: Business Patterns at Work[END_REF]. Each notation has its own concepts and its own semantics. A severe problem is that several languages for business process modelling do not have formal execution semantics which is a pre-request to check correctness criteria. We aim to define constraints on a meta-model that converges all modelling notations.

Figure 12: Independence of a given BP modelling notation

We aim to exploit this knowledge independently from any notation. Therefore we defined a metamodel for BP modelling that integrates these different notations by implementing an interoperability module that maps each notation concept to its corresponding one in our meta-model.

Business process meta-model

The meta-model defined in this section was constructed as a synthesis of a selection of concepts proposed by several authors, according to several notations and more specifically the work presented in (Aguilar-Savén 2004a).

The meta-model provides a synthetic vision of concepts used independently of specific notations helping in the understandability of models.

According to prominent BPM researcher van der Aalst (Wil M. P. van der Aalst, Hofstede, et Weske 2003b), BPM is defined as "a field of knowledge at the intersection between management and information technology, encompassing methods, techniques, and tools, to design, enact, control and analyse operational business processes involving humans, organizations, applications, documents, and other sources of information". We are concerned with the design of operational processes.

We defined a BP modeling meta-model not to capture the key languages concepts as it is never used for modeling. We do not need completeness of the meta-model. It is considered as a pivot model used in order to annotate the different notations concepts so we can apply OCL constraints defined.

Flow objects

The meta-model expresses a business process model as composed of flows of objects and connectors.

A flow object can be an event, an activity or a gateway. It is characterized by an identity (ID), a name and a token. A token is a boolean attribute that indicate if the flow object is executable or not.

• An event that occurs and impacts the progress of a process. The events could be of three types:

start event that initiates the business process, end event that terminates the business process and intermediate events. Intermediate events also have subtypes that differ with each notation.

Let E be the set of Events, E= < n e e .. 1 > where i e =<id, name, type, token>.

• An Activity can be a atomic and non decomposable presented by a task or a process if it is complex and has a visible structure. Each activity has an actor responsible of its execution. > where i a =< id, name, type, token,, inputs[ ], outputs [ ] responsible[ ]>.

Given a set A of activities, A=<

• A gateway is a mechanism able to manage the convergence and divergence of activities flows.

•

A XOR-gateway is used to model an "either/or" situation. Depending on conditions, exactly one outgoing flow will be chosen, the control flow is split. It can also be used as a 'Join' to show that no matter which exclusive path was taken from an XOR Decision, processing will continue with the single output from the 'Join' XOR Gateway.

• OR-gateway is used when one or more of the outgoing Sequence Flows from the Decision may be taken. It can also be used as a 'Join' to show that no matter which paths were taken from an OR Decision, processing will continue with the single output from the 'merge' OR Gateway.

• An And-gateway is used when Sequence Flows can run in parallel. All outgoing Sequence Flows are followed. It can also be used as a 'Join' when two or more parallel sequence flows need to join back into a single output flow.

Let G be the set of gateways, G= < n g g ..

1

> where each gateway is described by its identity (ID), name , type, token, the number of incomings < n i i ..

Connectors

A connecting element can be an association, a sequence, or a message flow. A connector is a connection path from a concept to an other and described by an identity (ID), a name and a type, a > where i as =<id, name, domain, range>. • The Sequence Flow is used to show the order of activities that will be performed in a Process. It is used between flow objects. It is always direct from a domain to a range. The domain is the predecessor and the range is the successor.

Let Sf be the set of sequence flow, Sf= < n sf sf .. 1 > where i sf =<id, name, domain, range>.

• A message flow is used to represent exchange of information between two participants in the process. It is always directed from a sender (the domain) to a receiver (the range).

Let Mf be the set of message flow, Mf= < n mf mf .. 1 > where i mf =<id, name, domain, range>. To conclude with the connectors, the sets Mf, Sf and As are included into the set C.

Resources

Resources are the objects that act or are used in the business. They are the concepts consumed, produced, transformed or used by the business process.

Activities refer to resources. A resource encompasses abstract concepts such as the human agent responsible for execution of the activity and also information produced or consumed by it.

• Information Resources represent information or knowledge as a bank account number, an address ... etc. An information resource is produced or consumed by an activity. So each one has a set of activity consumers < n co co ..

>>.

We have to note that the set of consumers can be an empty set, similarly to the set of producers but not both.

• Abstract Resource represents an idea or a concept. Contracts, accounts are examples of abstract resources. An abstract resource is produced or consumed by an activity. So each one has a set of activity consumers and/or a set of activity producers. Similarly, the set of consumers can be an empty set, similarly to the set of producers but not both.

Let AR be the set of abstract resources, AR= <

• Physical Resource represents physical goods such as production processes.They are not administrative, managementor service process, but a physical resource required in the process. Each one has a set of activity consumers and/or a set of activity producers.

Let PR be the set of physical resources, PR=<pri, prn> with pri = <id, name, consumers< n co co .. • Actors represent the community responsible of the execution of certain activity in the process. Community may represent a company, an association, a human being, etc.

Let PR be the set of actors, PR=< n pr pr .. 1 > with i pr =<id, name, responsibility> The relation "responsible-of" that relates the activity to an actor, represents the responsible allocation to each activity.

Each activity (task or process) requires resources. They have inputs which are a set of resources consumed. And outputs, a set of resources produced.

The relation "require" that relates the activity to resources represents the incomings and outgoings of resources.

Business process model -Business process metamodel alignments

Each concept in a notation has a name and a role or, in other words, a semantic. Mappings from each notation concepts to the meta-model concepts are defined based on two functions types:

• Concepts semantics: maps two concepts of different notations that have the same roles.

• Name matching: maps two concepts from different notations that have the same names.

Relying on [START_REF] Zha | Transforming XPDL to Petri Nets[END_REF]) and (Tscheschner 2010) we completed their mappings to encompass more notations.

Rule 1: Process

Notation Concept

These different concepts are represented by a process in our meta-model, which represents the execution of an act in order to support the completion of a business objective.

As a result, the BPMN process, EPC function and Eriksson-Penker process are related to our metamodel Process. Accordingly, all these flows represent the order of execution of activities or processes. We present them by a sequence flow in our meta-model.

Rule 7: Message Flow

These flows are represented by a message flow in our meta-model representing the exchange of resources (information or abstract resources).

BPM notations' semantics formalization

The objective of defining this BP modeling meta-model is not centered on describing all the notations concepts that exists, but to define constraints for the notations standards. Each instance of the meta model will be restricted by the use of the constraints defined in the Object Constraint language (OCL).

In this section we aim to demonstrate how IS domain knowledge can be used to improve the syntactic, semantic and pragmatic quality of business process models, and how it assists the designer in completing and validating the syntactic correctness of the model.

The main contribution is to define and homogenize the know-how of BP modellers through OCL constraints. Thanks to the object paradigm, we can define abstract constraints applicable to all BP model notations and concrete constraints dedicated to specific notations.

OCL constraints are defined on the meta-model level. They are used to detect and correct quality deficiencies. In fact, each constraint will check the validation of some conditions that the model should respect. Thus, checking the validation of these conditions will lead to the detection of quality deficiencies.

With respect to the categorization of quality in (Lindland, Sindre, et Solvberg 1994a), we separated the constraints into these three categories:syntactic, notations semantics and pragmatic constraints.

The notation errors represent the deviation from the syntax of the language rules. As a consequence, these errors affect the syntactic quality of the model. The syntax is mainly described by the metamodel presented in Section 3.2.1.

There are different aspects of a process model. Axenath et al. [START_REF] Axenath | The Aspects of Business Processes: An Open and Formalism Independent Ontology[END_REF] define three basic aspects of business process models: • The behavioural aspect: defines the order in which the tasks of a business process are instantiated and in which the corresponding activities are executed. There are many different ways, formalisms, and notations for defining the order in which tasks, respectively the corresponding activities must be executed i.e. in a given state, it must be clear which tasks are enabled. This aspect can be detected by the process model workflow.

• The informational aspect: defines the information involved in a business process as well as the propagation of information among different activities. All information involved in a business process can be considered to be resources. Moreover, the information aspect defines how documents are propagated among activities.

• The organisational aspect of a business process model defines the structure of the organisation in which the business process is executed, its organisational units and the relations among them; and it defines the resources and actors within these organisational units.

Many verification approaches in the literature aim to detect as much defects as possible.

The approaches that focus on control flow are generally applied on EPC and Petri nets notations since they are dedicated to lay out business process workflows. Control flow defects are detected by the soundness, relaxed soundness, EPC soundness, decomposition and reduction criteria.

Soundness:

Soundness is an important and prominent correctness criterion for business process models. It was first introduced in (Wil M. P. van der Aalst 1997). The original soundness property is defined for a Workflow net, a Petri net with one source and one sink, and requires that:

i.

For every state reachable from the source, there exists a firing sequence to the sink.

ii.

The state with a token in the sink is the only state reachable from the initial state with at least one token in it.

iii.

There are no dead transitions (Wil M. P. van der Aalst 1997).

It has been shown that soundness of a Workflow net is equivalent to liveness and boundedness of the corresponding short-circuited Petri net (Wil M. P. van der Aalst 1997). Therefore, several liveness and boundedness analysis techniques [START_REF] Murata | Petri nets: Properties, analysis and applications[END_REF]) are directly applicable to the verification of soundness. Soundness identifies all deadlocks and lack of synchronization for process models with one start and one end node.

Relaxed Soundness:

The soundness property of workflow models has stimulated the specification of several soundness derivatives, mainly because some soundness aspects proved to be too restrictive in certain application domains. In [START_REF] Dehnert | Relaxed Soundness of Business Processes[END_REF] the authors define a process to be relaxed sound if every transition in a Petri net representation of the process model is included in at least one proper execution sequence [START_REF] Dehnert | Relaxed Soundness of Business Processes[END_REF]. The relaxed soundness property is used in a study on the verification of the SAP Reference Model (J. [START_REF] Mendling | Faulty EPCs in the SAP Reference Model[END_REF]) (J. Mendling et al. 2007). Relaxed soundness does not necessary identify all deadlocks and lack of synchronization.

EPC Soundness:

The property of EPC soundness proposed in (Jan Mendling et Aalst 2007), builds on the identification of a set of initial markings that covers all start events. The EPC soundness definition demands that:

(i) There exists such a non-empty set of initial markings.

(ii) That, for each initial marking in this set, proper completion is guaranteed.

(iii) There must be a set of final markings reachable from some of these initial markings such that there exists at least one final marking in which a particular end arc holds a token.

If that is fulfilled, proper completion is guaranteed for a set of initial markings that cover all start arcs.

The EPC soundness property is stricter than the relaxed soundness criterion since it requires a guarantee of proper completion. EPC soundness is used in another verification study of the SAP Reference Model (Jan Mendling, Neumann, et Van Der Aalst 2007b). The authors use a two-step approach using first reduction rules and then, if necessary, state space calculation. EPC soundness can identify all those deadlocks and lack of synchronization that occur for all start combinations in which a particular start event participates.

Decomposition:

The approach reported in [START_REF] Vanhatalo | Faster and More Focused Control-Flow Analysis for Business Process Models Through SESE Decomposition[END_REF] builds on the decomposition of a workflow graph into single-entry-single-exit (SESE) components. The authors identify some heuristics for sound and for unsound components. In essence, these heuristics match EPC reduction rules as described in (J. Mendling et al. 2007). The decomposition approach identifies all those deadlocks and lack of synchronization that are defined in the heuristics.

Reduction: Another heuristic for checking the correctness of process models is used in [START_REF] Gruhn | What business process modelers can learn from programmers[END_REF]. The authors identify reduction rules for structured EPC models and heuristics to correct simple connector mismatch errors. This approach identifies all deadlocks and lack of synchronization that can be traced back to variants of unstructuredness.

These different approaches have in common that they detect the same type of defects: workflow defects in different ways. Thus workflow defects are related to logical relationships i.e. gateways in BPMN.

Our solution aim to gather the IS rules from several sources such as the above approaches and research

Syntactic constraints

1. Each activity has to reach the end event.

In every state that is reachable from a start event, there must be the possibility to reach an end event.

context Process inv reach_end_event:

Connector.allInstances() -> forAll(c| c.Domain.fID = self.fID implies Connector.allInstances()-> exists (c1| c1.Domain.fID= c.Range.fID and c1.Range.ftype = #end_event))

Each activity has to be reached from the start event

There should be a path from the start event to any activity in the model. The activity should be a domain of a connector and a range of an other one.

context Process inv proces_sucessors_nb:

Connector.allInstances() -> forAll(c1, c2| c1.Domain.fID = self.fID implies c2.Domain.fID <> self.fID)

Connectors should reach the extremes

When the modeller uses a connector, he/she has to check that the connector reaches the extreme concepts.

context Connector inv proces_sucessors_nb:

Connector.allInstances() -> forAll(c| c.Domain.fID <> '' and c.Range.fID <> '')

An activity can not have two successors

It will create a confusion on which flow to trigger (Van Der Aalst 1998b). Connector.allInstances()->forAll(c1,c2| c1.Range.ftype = #process implies c2.Range.ftype <> #process )

No connector should exist before the start event

There is no connector where range is a start event (Jan Mendling, Reijers, et van der [START_REF] Mendling | Seven Process Modeling Guidelines (7PMG)[END_REF].

context Connector inv connector_range:

Connector.allInstances() -> forAll(c| c.Range.ftype <> #start_event)

No connector should exist after the end event

There is no a connector where domain is an end event (Jan [START_REF] Mendling | Seven Process Modeling Guidelines (7PMG)[END_REF].

context Connector inv connector_domain:

Connector.allInstances() -> forAll(c| c.Domain.ftype <> #end_event)

Notations semantics constraints

According to [START_REF] Esswein | Towards a Framework for Model Migration[END_REF] , two instances of semantics of a model must be separated: first, semantics includes the rules for automated interpretation of a model, that is to say the concepts semantics and role in the model. Second, each modelling construct represents some real-world entities, which is another aspect of model semantics and is expressed by the labels of functions and events.

These errors have been found using the validation techniques mentioned above and some studies.

Other modelling languages like BPMN, Activity diagram, YAWL, Petri net or EPC use the same basic constructs for splits and joins. Thus these errors are common for all the business process modelling languages. We classified the workflow defects into five types: Deadlocks, Preventive deadlock, Lack of synchronization, Preventive lack of synchronization and Undesired situations.

• A deadlock results from a combination of logical relationships or gateways where one of these gateways is blocked waiting to be completed.

• Preventive deadlock results from situations where deadlock may or may not occur

• A process model suffers from a lack of synchronization if multiple branches are activated, but not synchronized later. In other words, we have a path with a handle.

• Preventive lack of synchronization results from situations where lack of synchronization may or may not occur.

• Undesired situations results from situations where there is paths not traversed or others traversed multiple times.

() summarize the different defects by explaining their causes and illustrating them.

Defect type Defect Causes/Subtypes

Deadlock 1. XOR-split with an AND-join: while the split only activates one control path, the AND is waiting for both to be completed

Table 9: Workflow defects

For specifying the constraints, we need some definitions. In order to define the situation that a join connector joins two (or more) control flow paths that have been started by a split before, we use two functions:

• Path-relation: path(s,j) holds iff there is a path from s to j.

• Match-relation: match (s,j) holds iff s is a split, j is a join and there are two paths from s to j whose only common elements are s and j.

1.

context Gateway inv D1:

Gateway.allInstances()->forAll(g1, g2| g1.gtype = #XOR_split and g2.gtype = #AND_join implies Match (g1,g2)= false)

2. An AND-Join is an entry into a loop:

the AND-join will always receive both control paths, that is will not exit the loop.

Preventive Deadlock

3. OR-split with an AND-join: the split may activate only one control path, the AND is waiting for both to be completed.

4. A (X) OR-split can lead the flow of control away from an AND-join which for this reason fails to synchronize its incoming flows.

Lack of synchronization 5. AND-split with a XOR-join: multiple branches are activated due to the AND-split, but not synchronized later at XOR-join.

Preventive Lack of synchronization 6. OR-split with an AND-join: the split may activate two control path, the AND is waiting for both to be completed.

Undesired situations

7. An AND-split and an AND-join with one of the paths between them contain a XOR-join: The flow of control can reach the AND-join without having to pass the ANDsplit before. 8. An AND-or OR-join is an exit from a loop: which permits multiple terminations of the process. It is undesired.

For all the instances of gateways, if there exist an instance g1 and an instance g2 where g1 is of type XOR_Split and g2 of type AND_Join, then a path from g1 to g2 will create a deadlock.

2.

context Gateway inv D2:

Gateway.allInstances()->forAll(g1| g1.gtype =#AND_join implies Entry_of_a_loop(g1)= false)

Entry_of_a_loop is a boolean function that detects if the gateway is an entry of a loop. Hence for all the instances of gateways, an AND_Join gateway can not be the entry of a loop since it will create a deadlock.

3.

context Gateway inv PD3:

Gateway.allInstances()->forAll(g1, g2| g1.gtype = #OR_split and g2.gtype = #AND_join implies

Match (g1,g2)= false)

For all the instances of gateways, if there exist an instance g1 and an instance g2 where g1 is of type OR_Split and g2 of type AND_Join, then a path from g1 to g2 may create a deadlock.

In order to prevent such errors , the following conditions must hold:

• There is a path from the (X)OR-split s to an AND-join j • There is an arc (s, s * ) with s * = j and another arc (j * ,j) with j * = s.

• There is no path from s to j * and no path from s * to j. For all the instances of gateways, if there exist an instance g1 and an instance g2 where g1 is of type AND_Split and g2 of type XOR_Join, then a lack of synchronization is created.

6.

context Gateway inv PL6:

Gateway.allInstances()->forAll(g1, g2| g1.gtype = #OR_split and g2.gtype = #XOR_join implies

Match (g1,g2)= false)

For all the instances of gateways, if there exist an instance g1 and an instance g2 where g1 is of type OR_Split and g2 of type XOR_Join, then a lack of synchronization is created.

7.

context Gateway inv UND7: For all the instances of gateways, if there exist an instance s of type AND_Split, e of type XOR_Split and j of type AND_Join, there shouldn't exist paths connecting s to e and e to j.

8.

context Gateway inv UND8:

Gateway.allInstances()->forAll(g1, g2| g1.gtype =#AND_join implies Entry_of_a_loop (g1)= false)

For all the instances of gateways, if there exist an instance g1 of type AND_Join, it shouldn't be the entry of a loop since it will trigger the loop unlimitedly.

Some units and relations are presented differently in notations .Thus it will create potential defects specific to a notation rather than the others. Some of these defects can be detected by modelling tools either by not permitting the modeller to use a specific concept or by showing the defect.

Each activity should have a name.

An activity without label is a useless concept.

context Process inv lack_Activty_label:

Process.allInstances()->forAll(p| p.fname<> '')

A Sequence flow can not cross the process boundary if it contains a start event

If the process does not contain a start event, the sequence flow should be connected to the trigger task in the process. This defect may occur in BPMN Lane/ Pool or in activity diagrams Swimlane module. Both notations contain concepts represented with boundaries. context Gateway inv lack_ORSplit_label:

Gateway.allInstances()->forAll(g| g.gtype= #OR_split implies g.fname<> '')

context Gateway inv lack_XORSplit_label:

Gateway.allInstances()->forAll(g| g.gtype= #XOR_split implies g.fname<> '')

Each X(OR) Split gateway outgoing edges should be labeled

Each Split XOR/OR outgoing edge should have a name presenting a condition (Figure 20).

context Gateway inv outgoing_edges_label:

self.gtype= #XOR_split or self.gtype= #OR_split implies self.outgoings->forAll( oc1, oc2| oc1 <> oc2 implies (oc1.C_Name <>''))

Each Split gateway have one incoming edge and at least two outgoing edges

Each type of gateway has constraints on the number of the edges coming in and going out from it [START_REF] Dehnert | Relaxed Soundness of Business Processes[END_REF]. Modelling "either" situations is performed via XOR-Split Gateways.

Depending on conditions, exactly one outgoing flow will be chosen, the control flow is split. Thus a Split gateway should have one incoming edge and at least 2 outgoing edges (Figure 20) If XOR split has an arc both to an event E1 as to another event E2, the semantics of the split means that both events can not take place at the same time thus E1.token = true implies E2.token = false. A bad application of XOR Split gateway may occur if E1 and E2 do not contradict each other and may take place at the same time, we can assume that there is an error in the model. The modeller can replace a XOR Split with an OR Split. In fact when applying the XOR split, it blocks one of the successors but semantically both successors can be processed.

context Gateway inv XOR_split:

Gateway.allInstances()->forAll(g| g.gtype=#XOR_split implies g.outgoings->forAll( oc1, oc2| oc1.Domain.fID= g.fID and oc2.Domain.fID= g.fID and oc1.Range.token= true implies oc2.Range.token = false))

A Split XOR gateway outgoing edges presents opposite conditions.

For all the instances of gateways, if there is an instance of type XOR_Split, the outgoing edges labels should be contradictory.

context Gateway inv XOR_split_edges_cdt:

Gateway.allInstances()->forAll(g| g.gtype=#XOR_split implies g.outgoings->forAll( oc1, oc2|

Is_opposit(oc1, oc2)))

Timer intermediate event semantics

Timer event can be used as a delay mechanism or as a task duration (Rozman et al. 2013).

Resources and gateways can not be connected

Gateways should not receive or send any resources.

context Connector inv resource_connection:

Resource.allInstances()->forAll(r1,r2| self.Domain.fID =r1.rID implies self.Range.fID <> r2.rID)

For all the instances of resources, there is no connector that connect two resources, that is if there exist a resource r1 and an other r2, there exist no connector where domain is r1 and range r2. For all the instances of resources, there is no connector that connect a resource to a gateway, that is if there exist a resource r1 and a gateway g, there exist no connector where domain is r1 and range g.

24.

A message flow relate activities to resources (abstract or information resource) and vice versa.

A message flow represents the exchange of messages/information between BPM concepts. For example, activities create outputs (information/abstract resources) and consume inputs (information/abstract resources).

Each activity has an input and an output resource

A business process is focused upon the production of particular products. These may be physical products or less tangible ones like a service (W. V. D. [START_REF] Aalst | Workflow Management: Models, Methods, and Systems[END_REF]. On the other hand, Davenport [START_REF] Davenport | Putting the enterprise into the enterprise system[END_REF]) sharpened his words and added that a business process is a specific ordering of work activities across time and place, with a beginning, and an end, and with clearly identified inputs and outputs -a structure for action.

context Process inv Process_Inputs_Allocation:

Process.allInstances()->forAll(p| p.Inputs ->notEmpty())

context Process inv Process_Outputs_Allocation:

Process.allInstances()->forAll(p| p.Outputs ->notEmpty()) [START_REF] Keith | Human-Centered Business Process Management[END_REF]. Each activity has an actor responsible of its execution.

context Process inv Actor_Allocation:

Pragmatic constraints

Pragmatic constraints do not detect notation defects but incomprehensible representations. It may propose a better way to represent an implicite idea.

1. Each business process model has to contain one and only one start event and at least an end event.

An occurrence of the Start event initiates the process and an End event terminates it (Jan [START_REF] Mendling | Seven Process Modeling Guidelines (7PMG)[END_REF]. In contrast EPC allows multiple start events and multiple end events (Jan [START_REF] Mendling | Yet Another Event-driven Process Chain -Modeling Workflow Patterns with yEPCs[END_REF]. If, in a process there is a parallel occurence of start events, it may be presented by one start event succeded by a parallel gateway that diverge the flow into two parallel paths.

The presence of derived or redundant concepts makes the model less understandable.

context FlowObject inv Redundancy:

FlowObject.allInstances()->forAll(f1, f2| f1.fname <> f2.fname)

An inappropriate concept name is considered as a pragmatic error.

3. An activity name should begin with a verb (Erreur ! Source du renvoi introuvable.).

context Process inv Process_label:

Process.allInstances()->forAll(p| Began_with_verb(p.fname) )

The function began_with_a_verb is a Boolean function that return true if the label begin with a verb.

A resource name cannot contain a verb (Erreur ! Source du renvoi introuvable.).

context Resource inv Resource_label:

Resource.allInstances()->forAll(r| Contain_verb(r.rName)= false)

The function contain-a-verb is a Boolean function that return true if the label contain a verb.

Capturing application domain knowledge

Application domain knowledge refers to real-world problems. It can be extracted from several sources such as user's requirements statements, domain expertise or existing models related to the same problem or to similar problems.

Application domain knowledge covers 1) recurring and shared knowledge enabling the reuse of expertise and 2) application-specific knowledge required for development from scratch. We propose to capture the first category through domain ontology. In computer science, an ontology formally represents knowledge as a set of concepts within a domain, and of relationships between pairs of concepts. This knowledge can be the result of expertise capitalization or standardization effort within a given domain such as the e-tourism ontology for data exchange in tourism business domain. Such ontology can be built using requirements specification documents or requirements models. The definition of these ontologies is not in our scope. Domain ontologies are available in the literature, examples of foundational ontologies are: the Wonder Web Ontology Library [START_REF] Masolo | WonderWeb Deliverable D18 : Ontology Library (final)[END_REF], in [START_REF] Patron | Adaptive mission plan diagnosis and repair for fault recovery in autonomous underwater vehicles[END_REF], the authors presented a mission plan ontology, Suggested Upper Merged Ontology (SUMO) (« Suggested Upper Merged Ontology » 2013), YAMATO (Cuiliqing 2013), UFO [START_REF] Guizzardi | On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models[END_REF], etc.

On the other hand, in the paper of Guarino [START_REF] Guarino | Formal Ontology and Information Systems[END_REF] present numerous domain ontologies are presented and classified into knowledge engineering, database design and integration, information retrieval and extraction.

In the first step, the approach consists in discovering the mappings between business process model elements and domain ontology elements. Similarly to make these alignment rules generic and independent of both the BP modelling notation and the ontology implementation language, we have defined an ontology meta-model presented in detail in Section 3.3.1.

Writing the rules at the notation level implies specifying the same rules several times to take into account the variety of vocabulary used to point out the same concept. The alignment rules aim to identify similarities between the process model elements and the domain ontology concepts. Once these similarities are identified, they serve as input for both semantic quality evaluation and improvement activities.

Ontology meta-model

The ontology meta-model allows representing domain ontologies using the same concepts independently of the language for their implementation. There are several contributions in literature concerning ontology meta-modelling. The authors in [START_REF] Tziviskou | A meta-model for ontologies with ORM2[END_REF] introduced simple concepts and constructors (negation, conjunction, disjunction) to define complex concepts. They also defined several relationships including inheritance links, instantiation, and constraints. In [START_REF] Kaiya | Ontology based requirements analysis: lightweight semantic processing approach[END_REF] five types of concepts have been proposed to represent the functional requirements (function, object, and environment) and non-functional requirements (constraint, quality). Additionally several research projects have attempted to use some form of ontologies for conceptual design. [START_REF] Bergholtz | Classifying the Semantics of Relationships in Conceptual Modeling by Categorization of Roles[END_REF] propose an ontology to classify relationships based upon data abstractions and speech acts. [START_REF] Storey | Ontology Creation: Extraction of Domain Knowledge from Web Documents[END_REF] presents an ontology for classifying the verb phrases of relationships based upon research in linguistics and semantic data models. [START_REF] Storey | An ontology-based expert system for database design[END_REF]) classify entities into various categories. These research efforts, however, concentrate on the classification schemes.

In our approach, we consider an ontology as a set of classes and relationships. This vision is largely adopted and more adequate for our approach as it gathers concepts and relations details that help us to align them with the BP model concepts.

We distinguish between three types of concepts: actor, action and artefact (Figure 27).

• An actor is an independent entity, able to perform actions.

• An action represents the execution of an action.

• An artefact is an inanimate object incapable of performing an action. An artefact may represent information or an abstract concept.

However, most meta-models take into account two kinds of relationships, namely inheritance and structural relationships.

For the needs of our approach we adapted the classification of relationships proposed in [START_REF] Purao | A multi-layered ontology for comparing relationship semantics in conceptual models of databases[END_REF] which has been initially defined to analyze semantics of relationships within a relational database and classify relationships by separating domain-dependent and domain-independent aspects of the relationship constructs [START_REF] Sugumaran | The role of domain ontologies in database design: An ontology management and conceptual modeling environment[END_REF]. This classification offers several types of relationships allowing us to characterize precisely the nature of links between concepts. Each of these categories describes a connector role or semantics.

Relations are first decomposed into three categories:

• Status: represents relationships that may be structural (inheritance, composition, instantiation, etc.), influence (own, control, create, destroy, etc.), or temporal (follow, require, etc.).

• Change of status: reveals the occurrence of remarkable events. This type of relationship is primarily used to express the interdependence of status in the life cycle of an entity.

• Interaction: represents short-term relationships between entities. Several semantic relations are defined for interactions such as communication, observation, execution, etc.

Business Process metamodel -Ontology metamodel mappings

Thanks to the precise categorization of concepts in both ontology and process model meta-models we are able to predefine some concepts correspondences enabling the mapping of the domain ontology concepts with the business process model concepts.

We have defined two kinds of mapping, namely type-based mapping and instance-based mapping.

Each concept in both business process and ontology meta-models have a type and a role. As a result, mappings are identified not only based on their types but also on the context of each instance.

Type-based mapping rules

This mapping involves the types of concepts in order to establish correspondences between the concepts at the meta-level. These correspondences allow reconciliation based on the types of concepts independently of their meaning. These rules are essential to avoid typing errors.

Concept based mappings

Based on the definition of each concept, we can define these mappings:

• An activity, which is the execution of an act in the BP metamodel is represented by an action in the ontology.

• An Actor, which represents the resource responsible of the execution of an activity, is represented by an actor in the ontology meta-model as it is responsible of the execution of an action. .

• An abstract resource in the BP meta-model represents an idea or a thought, it is mapped to an abstract concept in the ontology since it represents something formed in the mind, a thought or a notion.

• An Information resource in the BP meta-model is the Knowledge communicated or received.

It is mapped to a knowledge concept in the ontology since it represents an information.

These mappings are summarized into (Table 10).

BP model meta-model concept Domain Ontology meta-model concept

Actor Actor

Abstract Resource Abstract

Information Resource Knowledge

Chapter 3: IS and Application domain Knowledge

Process/Activity Action

Relation type based mappings

Similarly, we have established mappings between meta-model relations of BP model and of the ontology.

• A sequence flow in the BP meta-model presents the transition from an activity to an other or from a step to the following. It is represented by a temporal relation which shows the transition from a step to an other, from a lifecycle status to an other.

Instance based mapping rules

Based on meta-models presented above, we developed a set of matching rules, allowing the mapping of the ontology field with the concepts of process models.

These rules are written in OCL [START_REF] Brucker | A specification-based test case generation method for UML/OCL[END_REF]. The similarity computation uses the names of Intuitively, it seems reasonable to take the path length into account when determining semantic similarity: the closer two nodes are together in a taxonomy, the more semantically similar they are.

Wu and Palmer propose the following measure to measure the path length:

( )

C B A C c c sim wp 2 2 , 2 1 + + =
where A = len(c1, lcs(c1, c2)), B = len(c2, lcs(c1, c2)), and C = depth(lcs(c1, c2)).

Note that the length of the shortest path from synset ci to cj (measured by counting the edges between nodes) is denoted by len(ci , cj). The least common subsumer lcs(c1, c2) is the common subsumer for which the path length len(c1, c2) is minimal, i.e. the most specific common superclass. Vector. This is intended to be a more general representation than similarity measurements, since the source of the information for the context vectors is a raw corpus of text, not the paths found between concepts in an ontology. We start by creating Word Vectors, which are first order context vectors, for every content word w in our corpus of text. The dimensions of these vectors are content words from the same corpus of text (each dimension corresponding to one content word).

The vector for a word w is created as follows:

1. Initialize the first order context vector to a zero vector ~w.

2. Find every occurrence of word w in the given corpus.

3. For each occurrence of w, increment by 1 those dimensions of ~w which correspond to the words present in a specified window of context around w.

( )

2 1 2 1 2 1 . . , v v v v c c rel vector =
where v1 and v2 are the context vectors corresponding to c1 and c2, respectively. • Collect all their hyponyms. To collect the hyponyms we have to exploit the "IS-A" relations from the ontology, finally returning the IS-A domain. • Collect all the concepts that form the context of b. To do so we have to exploit the connectors of type: "require", "follow", "precede", "assigned-to" , "control", "destroy", "create" from the ontology, finally returning the domain of the connector. These classes of rules are instantiated for each of the concepts of the BP meta-model. For each class, an example of instantiated rule for the Actor BP concept is given below.

More

The second type of mapping, presented in the following chapter, is richer, being based on the semantics of concepts.

Conclusion

To support business process, an enterprise needs to be aware of the process model quality. In fact, the structure of the model does not only affect the development of the system but also the comprehension of the model and leads to misunderstanding between the different participants. Hence it is important to ensure the models quality.

The first step of our approach is the domain knowledge exploitation. And based on Khatri and al.

( [START_REF] Khatri | Understanding Conceptual Schemas: Exploring the Role of Application and IS Domain Knowledge[END_REF]), in information system, domain knowledge comprise two parts: IS domain knowledge and application domain knowledge. We explained in this chapter how we exploit each type of these knowledge.

Therefore, in order to exploit IS domain knowledge, we defined notation constraints that guarantees the absence of live-locks, deadlocks and other anomalies that can be detected without domain knowledge in order to improve the expressiveness of the model and the soundness of its structure. We gathered notation rules from different sources and we formalized them on a BP modeling metamodel level in order to ensure notation independancy. Thus to do so, we defined a BP modeling metamodel, BP model -BP metamodel alignments are defined and notation constraints are defined using OCL.

In order to exploit application domain knowledge, our approach rely on the existence of a domain ontology. We presented the alignment process that can be applied to each domain for which such ontology is available. We described the different types of alignments. BP metamodel -Ontology metamodel alignments: In order to evaluate the quality of BP models using domain knowledge.

The strength of our approach is that it is not domain-specific or notation specific. It may highly facilitate the task of BP modellers and lead to a significant improvement of BP models.

In the next chapter, we describe the evaluation and improvement process. Thus quality evaluation is done via quality metrics (syntactic, semantic and pragmatic) and quality improvement via functions and algorithms.

Chapter 4

Evaluation and Improvement of Business

Process models Quality

Various parameters, frameworks and methodologies have been proposed in the literature to define and evaluate quality of conceptual models as (Lindland, Sindre, et Solvberg 1994c), (D. L. [START_REF] Moody | Improving the Quality of Entity Relationship Models-Experience in Research and Practice[END_REF] and (D. L. [START_REF] Moody | Metrics for Evaluating the Quality of Entity Relationship Models[END_REF]. However, we are interested in evaluating BP models quality.

Modelling activity in general and BP modelling in particular are creative activities conducted by modellers using a given notation or modelling language. The result is of course highly dependent on the modeller experience in the notation practice, on his/her interpretation of the reality, and on the decisions he/she makes regarding the choice of concepts and details to be modelled. This explains the fact that several correct but different models can usually be generated from the same reality. However, these models are supposed to be faithful representations of the reality. Thus the definition of quality requirements for these models is, in fact, a mean to evaluate this modelling activity and ensure a better result. Many factors may be defined to characterize this quality.

To improve the quality of the models produced, several approaches are possible: assistance in the development process phase by generic methodological guides from experience, measurement and improvement of the specifications quality, reusing approved specifications fragments etc. In this thesis, we propose to exploit domain knowledge, which is supposed to reflect the knowledge shared by a community of actors, in order to improve the quality of process models.

Figure 28: The overall approach for quality evaluation and improvement

The approach is based on the process described at (Figure 28). The entry point is composed of a business process model under construction and the associated domain knowledge provided by the process modeller. The process involves three steps:

• Identifying Model-Ontology similarities: In the first step, the approach consists in discovering the mappings between business process model elements and domain ontology elements. The alignment rules aim to identify similarities between the process model elements and the domain ontology concepts. Once these similarities are identified, they serve as input for both quality evaluation and improvement activities.

• Evaluating quality: The second step consists in evaluating the syntactic, semantic and pragmatic quality of business process models. Thus in order to evaluate syntactic quality, we have identified a set of syntactic metrics, related to the graphical symbols used. Many graphical notations are not consistent with principles of BP standards. In fact details of graphical syntax can have dramatic impact on understanding and problem solving performance. It can be measured by syntactic metrics such as quantitative or Boolean constraints. To evaluate the semantic quality, we have identified a set of what we call quality deficiencies such as incompleteness and ambiguity. These deficiencies result from modeling choices producing models that do not cover the intended requirements or with low expressiveness. Such models lead to inadequate systems due to incompleteness or to misunderstanding during their implementation. Once a similarity has been identified between a BP model element, let it be bpmi and an element from the domain ontology doj, our approach exploits the knowledge from the domain ontology related to doj to detect and measure semantic quality deficiencies according to quality metrics we have defined. Finally, to evaluate the pragmatic quality, we also identified a set of pragmatic metrics concentrated on the graphical communication effectiveness, it can be measured by the ease and accuracy in which information can be understood.

• Quality improvement: The quality improvement activity consists in suggesting to the analyst a set of improvement guidelines to improve the quality of their models. Our approach proposes different type of improvements: Textual guidelines, Preventive actions and corrective actions.

Again, this step uses the domain knowledge to generate improvement actions. This means that the completeness and even the relevance of these guides rely partly on the quality of the domain ontology but this aspect is out of the scope of our approach. For example, if the approach identified a similarity between bpmi -a BP model element and doj -an element from the domain ontology-and the domain ontology describes a relationship between doj and dok (an other element from the ontology), then our approach will propose an enrichment action on the BP model based on the relationship between doj and dok. The analyst, with the help of the suggestions made by the approach, adds/removes/rename/replace elements from the initial model that evolves.

However, quality improvement is never done in one shot and this is why the approach is iterative and incremental. The further sections detail the different steps of the proposed approach.

Syntactic quality evaluation

The syntactic quality checks he correctness of the model and evaluate the quality related to the concepts used.

In order to evaluate the syntactic quality we have identified a set of pragmatic quality metric. Each metric has a return type, a name and explanation ( how is it calculated, what is the defect detected and a result analyse). These metrics are presented in (Table 12). If number of start events in the model is less than 1 or higher than 1, a defect is detected.

• If 1< nb_start_event<1, a defect is detected. • If nb_start_event =1, no defect detected.
Integer End_event_nb This metric detects end event defects.

If number of end events in the model is less than 1, defect is detected.

• If nb_end_event<1, a defect is detected.

• If nb_start_event >1, no defect detected.
Boolean Activity_Label This metric detects unlabeled activities.

If an activity has no name, thus name ="", a defect is detected.

• If Activity.name="", an unlabeled activity is detected. • Else no defect detected.

Boolean X(OR)_split_label

This metric detects unlabeled X(OR) gateways. If a X(OR) split gateway has no name, thus name="", a defect is detected.

• If X(OR)gateway.name="", an unlabeled X(OR) split gateway is detected. If a X(OR) outgoing edge has no name, thus name ="", an unlabeled edge is detected.

• If X(OR)_outgoing_edges_label=" ", an unlabeled edge is detected. • Else no defect detected.

Boolean

Usefull_lane This metric detects Useless lanes. If the lane does not contain any activity, thus Useful_lane= false and an unuseful lane is detected.

• If Useful_lane = true, an unuseful lane is detected. This metric detects lack of inputs.

If an activity has no input resources it is an incomplete activity.

• If Activity_consumed_resources<1, an incompleteness defect is detected.

• If Activity_consumed_resources>1, no defect is detected Integer Activity_produced_r esources
This metric detects lack of outputs.

If an activity has no output resources it is an incomplete activity.

• If Activity_produced_resources<1, an incompleteness defect is detected.

• If Activity_produced_resources>1, no
defect is detected

Table 12: Syntactic quality metrics

Each of these metrics detects a syntactic defect, by returning a Boolean or an integer value. They help the modeller to evaluate and improve the syntactic quality of their models.

Semantic quality evaluation

Semantic quality expresses the degree of correspondence between the information expressed within a model and the domain that is modelled (Krogstie, Lindland, et Sindre 1995b). It helps evaluating the ambiguous representations, incomplete representations and the meaningless states of the model [START_REF] Wand | Anchoring data quality dimensions in ontological foundations[END_REF].

• The validity evaluation checks that all the statements of the model are correct. If the model do represent reality as close as possible.

• The completeness evaluation, however, verifies that all the pertinent statements from the domain are captured by the model.

• Meaningless states assessment verifies that the statements are related to the domain.

These deficiencies result from modelling choices producing models that do not cover the intended requirements or with low expressiveness and may be caused by an incorrect use of concepts. Such models lead to inadequate systems due to incompleteness or to misunderstanding during their implementation.

Different semantic measures have been proposed in the literature to evaluate the strength of the semantic link between two concepts or two groups of concepts from either two different ontologies (ontology alignment) or the same ontology. But in this thesis we are interested in the semantic quality of the business process models based on the knowledge provided by different sources (IS domain knowledge and application domain knowledge). Thus we need to study the strength of the semantic link between a business process model and ontology.

Quality defects detection

First, similarities have to be identified between BP model elements and domain ontology elements.

Let m bp be a BPM element and o a domain ontology element. Our approach exploits the knowledge from the domain ontology related to o to detect and measure semantic quality deficiencies.

 We have identified a set of quality deficiencies which result from modeling choices producing models that do not cover the intended requirements or with low expressiveness.

 We identified for each quality deficiency a set of quality metrics in order to measure the semantic quality in quantitative terms. These metrics reduce subjectivity in the evaluation process.

We group the quality defects into four categories: Meaningless states defects, ambiguous representation defects and incomplete representation defects [START_REF] Wand | Anchoring data quality dimensions in ontological foundations[END_REF] .

Meaningless state defects

Meaningless states correspond to states and constructs from the models for which no correspondence is found in the corresponding ontology. This decreases the relevance of models and has an impact on its intelligibility. In fact the analyst may add an activity which does not represent a domain related role. In other words it represents meaningless data.

Ambiguous representation defects:

Ambiguous defects can be caused by:

• Ambiguity: two or more interpretations of a concept i.e. which states of the real-world should be mapped into the same state of the information system [START_REF] Wand | Anchoring data quality dimensions in ontological foundations[END_REF].

• Abstraction concept level: This is usually viewed as a precision problem. In other words, there is no sufficient information to represent the concept of the real-world or vice versa.

Ambiguity

Ambiguity is the ability to express more than one interpretation for the same concept. It results from:

• Using the same name to express different realities. For example consider a model providing a property "telephone number". If the reality corresponding to this model allows several categories of telephone numbers such as personal, office, home and cellular telephone numbers having each its own usage then the property "telephone number" from the model is ambiguous since it represents several realities.

This makes models unclear and creates confusion when trying to understand them. To have a quantified evaluation of the ambiguity of concepts we defined quality metrics.

Clarity Metric

For quality evaluation we speak about clarity (as desired characteristics) instead of ambiguity which is a non quality property. This metric calculates the ratio of 1 to the total number of synonyms detected in the ontology.

if |C_synonyms(o)| ≠ 0 C_clarity ( m bp ) = 1/|C_synonyms (o)| if |C_synonyms(o)|= 0
we have a meaningless state.

The more the concept has synonyms, the more ambiguous it is. When the value of clarity equals 1 for m bp , a given BP model element, this means that there is only one corresponding concept from the domain ontology and thus m bp is not ambiguous. The value of clarity decreases when the number of synonyms in the ontology increases. When the value of clarity is meaningless, this means that there are no corresponding elements found for m bp . In this case, m bp can be a meaningless state. A validation from the modeller has to be performed since the domain ontology is not the exclusive source of knowledge.

Abstraction level

Abstraction level is related to the use of the suitable level of generality. Indeed, in some cases, using general concepts instead of specific and precise ones can decrease the efficiency of the processes, for example "analyze the request" activity is a general activity that may hide a lot of important details. On the contrary, using very specialized terms may decrease the understandability of the models, for example excessive splitting of steps as "check the hotel reservation invoice", "check the plan ticket", "check the registration invoice" activities can be replaced by "check the documents". The relevant choice of an abstraction level depends on several factors among which we can mention the nature of audience (developers or users), the objective of the model (explanation or implementation), etc.

• Generality quality attribute: The more the concept has hyponyms, the more general it is. The value of generality metric decreases when the number of hyponyms increases. When generality metric returns unknown, this means that there are no hyponyms found for c.

Generality (c) =

• Specification quality attribute: The more the concept has hypernyms, the more specific it is. The value of specification metric decreases when the number of hypernyms increases. When specification metric returns unknown, this means that there are no hypernyms found for c.

Specification (c) =

Incomplete representations defects

Incompleteness is related to an incomplete representation of the real world. It occurs when the process model misses some requirements. This incompleteness can result from the complexity of concepts for which only a sub-set of the description is captured within the process model or to a lack of domain knowledge of the analysts or both of them. For example, if a BP model considers only missions with train tickets costs reimbursement whereas the reality includes also missions with hotel costs then the BP model is incomplete. This is generally captured by completeness quality attributes.

We rely on the knowledge provided by the ontology to capture different types of incompleteness.

Incomplete defects can be caused by:

• Input incompleteness • Resource allocation incompleteness • Model richness

Input completeness

Each activity in the BPM needs to consume/produce resources. So incompleteness is detected if the inputs and/or outputs are missing for an activity.

 Let "oa" be the ontology action mapped to the BP model activity "a" by the Instance based mapping rule Name-based-similarity or by one of the synonymy rules described in Section 3.3.2.4.

 Let inputs [ ] be a set of ontology concepts related to "oa" by a "require" relation. As the "require" relation relates ontology actions to abstract and knowledge concepts. These concepts represent information and abstract resources. In other words, if "oa" requires i, where i ∈ inputs [ ] represent a knowledge or an abstract concept then the activity "a" should have as input.

 Let X be is equal to the number of inputs of the activity "a".  Let Y be is equal to the number of concepts required for the action "oa".

 Calculate the ratio of X/Y. The result will be a percentage indicating how complete the inputs of the activity "a" are.

Resource allocation completeness

As each activity (Process or task) is allocated to an actor responsible of its execution, we can rely on the knowledge provided by the ontology based on the "Influential" and "performance" relations to detect the completeness of the resource allocation. "Performance" relations as "Perform", "Operate", "Serve" and "Influential" relations as "Creator", "Destroyer", "Controller", "Owner", "Assigned to" represent the role of an actor over an action. As a result the resource allocation completeness metric detects the completeness of actor allocation of an activity a in the BP model.

 Let "oa" be the ontology action mapped to the BP model activity "a" by the Instance based mapping rule Name-based-similarity or by one of the synonymy rules described in section 3.3.2.4  Let Actors [ ] be a set of ontology concepts related to "oa" by an "influential" or "Performance" relation.

 Let X be equal to the number of actors related to the action oa.

 Let Y be equal to the number of the number of actors related to the activity a.

 Calculate the ratio of X/Y . The result will be a percentage indicating how complete the resource allocations of the activity a are.

Model-richness

Richness of the model is related to the total coverage of the domain. Does the model cover the domain? Does it represent all the steps required? Does it mention all the documentations that can be used in the process? To detect the richness of the model we defined two metrics: the Model Activity Richness and the Model Resource Richness.

 Let X be is equal to the number of activities presented in the model.  Let Y be is equal to the number of actions in the ontology.

 Let U be is equal to the number of resources (abstract and information resources) in the business process model.

 Calculate V which is equal to the number of knowledge and abstract concepts in the ontology.

Model Activity Richness = X/Y

Model Resource Richness = U/V

Pragmatic quality evaluation

Pragmatic quality describes how well the schema is understood by its users (Lindland, Sindre, et Solvberg 1994a). A conceptual schema with good pragmatic quality has been described as a schema that can be interpreted with little cognitive effort (K. [START_REF] Siau | Technical communication in information systems development: the use of cognitive mapping[END_REF].

A complete and accurate understanding of conceptual schemas by future system users is essential in the process of validating the user requirements captured in the schemas, as they are the primary stakeholders in the conceptual modelling process concerned with understandability (D. [START_REF] Moody | Dealing with Complexity in Information Systems Modeling: Development and Empirical Validation of a Method for Representing Large Data Models[END_REF].

Studies on the readability of Conceptual models can also be found in the literature. (Krogstie, Lindland, et Sindre 1995a), for instance, list graph aesthetics and diagram layout among the means to achieve pragmatic quality. Others, [START_REF] Poels | The Pragmatic Quality of Resources-Events-Agents Diagrams: An Experimental Evaluation[END_REF], reported upon an empirical study that evaluated Resources-Events-Agents (REA) model modelling. They present a laboratory experiment that measured the user understanding of diagrammatic conceptual schemas developed using the REA model. Their approach is based on pattern recognition phenomena and the resulting reduction in cognitive effort for understanding conceptual schema.

In order to evaluate the pragmatic quality we have identified a set of pragmatic quality metrics. Each metric, based on its calculation result, detect a defect. These metrics are presented in (Table 13).

Metric return type

Metric Name

Explanation Analyze of results

Integer Redundancy

This metric detects redundancies.

If there are two or more concepts with the same name, a redundancy defect is detected.

• If Redundancy>2, redundancy defect is detected.

BPM quality improvement

Business processes are human-centered activities (V Keith, 2008). Thus they need to be continuously improved in order to fulfill the requirements of the customers. "Improvement" means the organized creation of beneficial change, the attainment of unprecedented levels of performance [START_REF] Juran | Juran's Quality Handbook[END_REF]. Performance is the achievement of a goal which depends on the context of study. In our study the aim of software process model improvement is to increase the business process models quality thus enhancing the understandability and the maintenance costs.

Unterkalmsteiner et al. [START_REF] Unterkalmsteiner | Evaluation and Measurement of Software Process Improvement #x02014;A Systematic Literature Review[END_REF]) seize from the literature different types of software process improvement (SPI) initiatives: 1) frameworks like CMM [START_REF] Paulk | The Capability Maturity Model: Guidelines for Improving the Software Process[END_REF], SPICE (ISO / IEC 15504) ; 2) practices which can be applied in one or more phases of the software development life-cycle and 3) tools i.e. software applications that support software engineering practices.

SPI framework initiatives aim to define a basis for judging a process quality or for solving process problems [START_REF] Paulk | The Capability Maturity Model: Guidelines for Improving the Software Process[END_REF]. The objective of any improvement framework is to bring out a more effective guidance enabling process improvement program. In the literature we can find a lot of frameworks such as CMM [START_REF] Paulk | The Capability Maturity Model: Guidelines for Improving the Software Process[END_REF] which is the most reported one, Six-Sigma (Thomas et Fehlmann), CMMI [START_REF] Ahern | CMMI Distilled: A Practical Introduction to Integrated Process Improvement[END_REF], etc. Practices are about identifying improvement opportunities and eliminating the differences constitutes the actual process improvement. As in these practice approaches, measurements to control process change and to confirm goal achievement are a central part. We can cite top-down, bottom up approaches (H.A. [START_REF] Reijers | Best practices in business process redesign: an overview and qualitative evaluation of successful redesign heuristics[END_REF], the Quality Improvement Paradigm (QIP)/ Experience Factory [START_REF] Basili | The Experience Factory and its relationship to other Improvement Paradigms[END_REF], etc.

Based on the distribution of the SPI initiatives shown in (Figure 29), combinations of SPI initiatives are recorded explicitly. We can conclude that the majority of the contributions are in the frameworks.

However, the frameworks provide guides of insufficient granularity for a real assistance to the improvement. In contrast, initiatives that provide practices and tools are not more than 4% of the publications. Within the context of this thesis we are concerned with providing improvement techniques and a prototype which implements our improvement approach. In this section we will present our proposed methods and techniques applied in the design phase of the business process in order to improve the business process models quality.

Business process improvement initiative

The mantra of many software process improvement frameworks and models originates in the Shwehart-Deming cycle [START_REF] Deming | Out of the Crisis[END_REF] plan-do-check-act:

-Plan: establish an improvement plan -Do: implement the new process -Check: measure the changed process -Adjust: evaluate the effect of the adjust changes

The most dominant evaluation strategy is the "Pre-Post Comparison" [START_REF] Unterkalmsteiner | Evaluation and Measurement of Software Process Improvement #x02014;A Systematic Literature Review[END_REF]. It consists in comparing the success indicator's values before and after the improvements take place [START_REF] Rozum | Concepts on Measuring the Benefits of Software Process Improvement[END_REF]). Hence, it is necessary to define the success indicators i.e. the quality metric which can be used to evaluate the improvement, and to step-up a baseline from which the improvement can be approved.

Establishing that the quality of the process model has improved means that the number of quality defects decreased after the improvement process. As a result, our improvement strategy will contain

Improvement process

The improvement process comprises three steps.

• The first step performs the improvements in order to correct the defects captured by the application of the IS constraints.

• The consists in activity label refactoring

• The third step implements the improvement that corrects the defects captured by the ontology.

We will detail each of these steps (Figure 30) using BPMN. • Activity label refactoring consists in categorizing the labels into classes and extracting information from them. The categorization function and information extraction algorithm will be detailed in Section 4.4.2.

• Based on the quality metrics value, quality defects are detected. In fact, semantic quality metrics depend on the knowledge provided by the domain ontology i.e. on the mappings between the process model concepts and the ontology concepts. But these mappings depend on the type and the semantic of the business process model concepts which we assume that they are improved by the IS constraints improvement propositions. Similarly, these metrics point out the problems but do not solve of. We aim to propose improvements to each of these defects.

Label refactoring

Process model quality has been approached from different angles, including verification, error probability, and comprehension. Also the small pieces of text that capture the names of activities (activity labels) have been investigated from a usability perspective. Usually, information about data is hidden in activity labels. The latter represent actions, which take place during the execution of a business process.

Activity labels can be a complete sentence or a sentence fragment. They may contain a verb that can present an activity, a noun that may present a business object, etc

In this type of improvement, we aim to extract the information from the activity labels in order to complete the model. Based on the work of [START_REF] Leopold | Refactoring of process model activity labels[END_REF], who developed an algorithm for the label style recognition and categorize the sentence fragments into noun phrase labels, verb phrase labels and irregular category. We completed their algorithm to classify the complete sentences into Object-verb-by-Subject, time-porter labels or subject-verb-object labels.

(Table 14) describe the label classes by explaining the structure and providing an example for each class.

Label Class Structure Example Noun phrase

Label that began with a noun.

Invoice[O] creation Verb phrase

Composed of at least one verb and the dependents of that verb: objects, complements. It does not include the subject.

Creating [V] invoice.

Irregular

Label contains characters ":" , "_"or "-" Creation-Level.

Subject-verb-object

The subject comes first, the verb second, and the object third (« SVO (Subject-Verb-Object) » 2013).

The The input of the algorithm is a label, the output is the label style.

• First the algorithm examines if the label contains characters such as ":", "_" or "-" that allow classifying it as irregular.

• The algorithm precedes with the sentence fragments by checking if the label contains a subject, a verb and a noun, it is classified as a Subject-verb-object. If the label contains in order an object, a verb, the preposition "by" and a subject respectively then it is classified as Object-verb-by-Subject.

• Otherwise, we are in a complete sentence case. If it begins with a verb, in this case the label is categorized as verb phrase. If it begins with a noun, it is categorized as noun phrase label.

• The algorithm continues seeking for time conjunctions. If time conjunctions are found, the label is classified as time-porter.

Leopold et al. [START_REF] Leopold | Refactoring of process model activity labels[END_REF], also implemented an algorithm that aims to extract resources from the activity labels. We will adopt their algorithm in order to complete the BP model by proposing, for each activity, an input and an output.

ii.

Name: Extract_Resource

Input: Activity label categorized as noun phrase or verb phrase.

Output: Resource

Description:

If an activity label is a list of words with a special structure, based on these words, we aim to extract resources (information or abstract) so that we can complete our model.

The extraction algorithm is decomposed into three steps:

• Label analysis: In order to determine the action (presented by the verb), the resource (presented by the noun) and the state (presented by the adverb). It is done by tagging the words of the label as verb, noun or adverb.

• Specify the output of the activities: We have several cases, each case has its own analysis. In the first case which is the basic one, an activity a1 precedes an activity a2.

In this case, the resource created is using the noun of the activity label in hand to present the object and the adverb to present the state. The second case occurs when the activity is preceded by a XOR split. In this case, the object and its state are extracted from the XOR condition. The condition is the edge label.

• Specify the input of the activities. The third step aims to create inputs. In the contrary of the outputs, to specify the inputs, we have to analyze the successor.

iii.

Name: Extract_BP_concepts

Input: Activity label categorized as time-porter.

Output: BP_concept Description:

Activity labels categorized as time-porter may contain information that can be presented by a business process concept.

• Time subordinating conjunctions: They present the time transitional words in the sentence.

The latter have the function of limiting, restricting, and defining time. The definitions of the time conjunctions were taken from the English-French Dictionary (« English-French Dictionary WordReference.com » 2013). Time transitional words are the subordinating conjunctions time clauses. Conjunctions relate two clauses in the time: Clause1 Time_Conjunction Clause2. The most common are: while, after, before and as soon as.

Their functions are presented in (Table 15). The phone rang while I was watching TV.

• Create a parallel gateway "pg".

• Add activity (v1) as a successor of "pg" where v1.name = verb extracted from Clause1. When an IS constraint is violated, a textual guideline will indicate to the analyst the quality defect and/or how to correct it. Thus, for each constraint, a proper textual guideline is attached to it. We classify below the textual guidelines in the same way as the IS constraints.

Textual improvements for syntactic constraints

Each textual guideline have a name and a description. The description provide an improvement guideline for the modeller.

Name: Start_event constraint corrective guideline. Description:

A start event is missing. You should add a start event to your model in order to initiate your process.

Name:

Multi_Start events constraint corrective guideline. Description:

There are several start events in the model. It is recommended that the model contains one start event.

Name:

End_event constraint corrective guideline. Description:

An end event is missing. You should add an end event to your model in order to end your process.

Name:

Start_event_emplacement constraint corrective guideline. Description:

A start event is preceded by an other concept. You should remove any concept that precedes the start event.

Name:

End_event_emplacement constraint corrective guideline. Description:

An end event is succeeded by an other concept. You should remove any concept that succeeds the end event.

Name:

Useless_activity constraint corrective guideline. Description:

The activity "Activity_ID" is without a name. It is recommended to rename the activity.

Name:

Activity_Bad_Synchronization constraint corrective guideline. Description:

The Activity "Activity_name" can not reach the end event. You should create a path from the "Activity_name" to the end event respectively.

Name:

Lost_Activity constraint corrective guideline. Description:

The Activity "Activity_name" is not reachable from the start event. You should create a path from the start_event to "Activity_name".

Name:

Connector_Bad_Emplacement constraint corrective guideline. Description:

The connector "Connector_ID" is not connected.

Name:

SequenceFlow_Bad_Emplacement constraint corrective guideline. Description:

The sequence flow "SequenceFlow_ID" crosses the boundary of "Process_name". The process "Process_name" will be initiated with its start event.

Name:

Join_AND_gateway constraint corrective guideline. Description:

The input edges number is less than two. Or the output edges number is higher than one. In both cases, the gateway doesn't serve its purpose.

to meet the IS constraint, a resource can be related only to flow objects. When relating a resource to a flow object the only type of relation that can be used is a message flow. In contrary to AddActivity, Add Resource can have none successor or none predecessor.

iii.

Name: Add_Actor Inputs: Actor, Successor.

Description:

An actor is always related to an activity i.e. its successor is always an activity. It usually doesn't have a predecessor. And it is always linked by an association.

iv. Name: Add_StartEvent Inputs: Successor.

Description:

A start event is related to its successor by a sequence flow.

v. Name: Add_EndEvent Inputs: Predecessor.

Description:

An end event is related to its predecessor by a sequence flow. Description:

Each gateway type differs by the number of incomings and outgoings.

• If the gateway type is a Join gateway, then the number of predecessors should be greater than one and the number of successors is equal to one. For each predecessor, a sequence flow is created to relate it to the gateway.

• If the gateway type is Split gateway then the number of successors should be greater than one and the number of predecessors is equal to one. For each successor, a sequence flow is created to relate it to the gateway.

Rename action

It consists in renaming the concept i.e. it still has the same type, it does just changes the name.

Replace action

It consists in replacing the concept by an other with a different type.

ii. Name: Replace Inputs: Old_Concept, New_Concept.

Description:

This function replaces the concept "a" by another named "b". As the type of the concept changes, the type of the relations associating it to its successor and predecessor may change. This function examines the type of the replacement to check if it has to change the type of the connector.

Remove actions

Name: Remove Inputs: Concept.

Description:

Remove actions can not be applied on all cases. Each of the remove actions should make sure not to violate any of the IS constraints. We can remove a concept "a" in two cases:

If a.Predecessor is a flow object and a.Successor is a flow Object or a resource.

If a.Predecessor is a resource and a.Successor is a flow Object.

If a.Predecessor is a flow Object and a.Successor is a resource.

One of the cases where the action Remove can not be applied if the predecessor and the successor are of type resources. In this case two resources will be related to each other.

And we should always adapt the relations based on the concept types.

Preventive actions

The ability to provide improvement advices that aim to prevent potential problems is essential to reduce the error probability. These improvement advices are presented under the form of preventive actions.

If the usage of a business process model concept indicates that a possible problem is, we develop a preventive action to warn the potential situation.

Three types of preventive actions are: Concept definition, Concept usage patterns and Concept illustration.

Concept definition

A concept definition displays the role of each concept. It will help the modeller to know what is the adequate concept to use in order to model a specific requirement.

• A sequence flow is used to show the order that activities will be performed in a process. Each sequence flow has only one domain and only one range.

• A message flow is used to show the flow of messages between two participants.

• An association is used to link information and artefacts.

• An activity is an action performed in the process.

• Split_OR gateways are locations within the business process where the sequence flow can takes one, two or more alternative paths.

• Split_XOR gateways are locations within the business process where the sequence flow can take only one path from several based on a validate condition.

• Split_AND gateways are locations within the business process where the sequence flow take two or more paths in the same time.

• Join_OR gateways are locations within the business process where at least one path can trigger the activity that succeeds.

• Join_AND gateways are locations within the business process where two or more sequence flows merge in a common path.

• The start event indicates when a business process will start.

• The end event indicates when a business process will end.

• The intermediate event indicates when an event happens between the start and the end event.

• The message intermediate event presents information or an abstract message.

Concept usage explanations

Usage explanations describe the behaviour of a business process model concept. A concept behaviour meets to specific conditions. Thus each concept has to be associated with documentation on how it should be used. The conditions should be respected:

• The usage explanation of an "Activity":

-Each activity should have an actor responsible of its execution.

-The name of an activity should begin with a verb.

-A path should relate a start event to the activity -The end event should be reached from the activity.

• The usage explanation of a "Split_XOR":

-A split_XOR should have a name.

-A split_XOR should have more than one successor.

-A split_XOR should have only one predecessor.

-The output edges should have a name.

• The usage explanation of a "Join_XOR":

-A Join_XOR should have more than one predecessor.

-A Join_XOR should have only one successor.

• The usage explanation of an "Actor":

-An Actor should be associated to at least one activity.

• The usage explanation of a "Resource":

-A Resource should be associated to at least one activity.

-A Resource label should not contain a verb.

• The usage explanation of a "Message flow":

-It connects a flow object to a resource or vice versa.

• The usage explanation of a " Sequence flow":

-It connects two flow objects.

• The usage explanation of an "Association":

-It connects an artefact to a flow object.

Illustration Concept

Illustrations are business process templates containing the best practices that show different usages of a specific concept. They contain the knowledge needed to explain how a concept can be applied in a process.

Quality improvement patterns

A Business Process Improvement Pattern is an abstract form of a recurring instance of a process modification step used in a Business Process Improvement activity (C. Alexander, Ishikawa, et Silverstein 1977b). Quality patterns use IS constraints and Quality metrics in order to detect the problem and suggest improvements. They capitalize the experience and provide an establish solution to a recurring problem. Thus a quality pattern can use multiple metrics and multiple constraints.

Similarly metrics and constraints can be used by multiple patterns.

Based on the results of different metrics and constraints, numerous textual guidelines and corrective actions are proposed for improvements.

Although a pattern can generally be described in any form, we will adopt the problem-solution-context described by Alexander and al. (C. Alexander, Ishikawa, et Silverstein 1977b). This description was used and tested and proved in other fields of application ( Forster 2013b):

Name: The pattern name summarizes the pattern objective. It should categorize each pattern.

Context:

The pattern context defines the situation and the conditions where the pattern can be applied.

Problem:

The problem to be solved is described

Solution:

The recommendations or the corrective actions to solve the problem are defined. An implementation guideline may be given.

We defined five improvement patterns: Concept ambiguity, Model completeness, Organizational aspect correctness, Model behavioural correctness and Model semantic correctness paterns.

A. Pattern Name: concept ambiguity

Context:

To check the concept ambiguity with respect to the number of synonyms, hyponyms, and hypernyms present in the domain ontology, as well as to detect unclearness in any concept label.

This pattern is applicable on each concept in the model.

Problem:

i) If a concept has a big number of synonyms in the domain, that is to say it is not clear then it will create an ambiguity.

ii) If a concept has a big number of hyponyms in the domain then it may hide a lot of details.

iii) If a concept has a big number of hypernyms in the domain then it may conceal a lot of details and create an ambiguity.

Solution:

The following corrective actions can be employed:

i) Rename the concept with one of the synonyms provided by the ontology.

ii) Rename the concept with one of the hyponyms provided by the ontology.

iii) Rename the concept with one of the hypernyms provided by the ontology.

iv) Refactor the concept label.

v) Remove a redundant concept.

The model ambiguity is related to the concepts labels, specially the activities labels. The concept ambiguity pattern enumerates many cases that create ambiguity such as redundancy, an incorrect label structure, a label that represents different concepts in the domain, etc.

Ambiguity is detected via quality metrics such as clarity, generality and specification of a concept and through IS constraints such as Activity label, resource label constraints.

Each of the metrics and the constraints provide textual guidelines that ask the modeller to rename a concept and remove redundant concepts.

B. Pattern Name: model completeness

Solution:

The following corrective actions can be employed: i.

Add Thus to correct these defects, quality metrics can be calculated and IS constraints are checked.

Each of these metrics and constraints suggest to the modeller via textual guidelines different corrective guidelines.

C. Pattern Name: model organizational aspect correctness

Context: The model correctness is related to the correctness of the concepts emplacement in the model.

Problem:

i. Bad emplacement of concepts i.

A predecessor of a start event or a successor of an end event.

ii.

A connector does not reach the extremes or a sequence flow that crosses the boundary of a process iii.

A split gateway with less than two outgoing edges.

iv.

A join gateway with less than two incoming edges.

v.

An activity without successor or that can not be reached from a start event i.e. lost activity i.

Each constraint provides to the modeller corrective guidelines that ask the modeller to use the corrective actions Add, Rename, Replace or Remove.

The organizational aspect correctness of the model is related to the incorrect emplacement of concepts in the models. Such as Start event predecessor, an end event successor, a bad emplacement of connectors, an incorrect use of gateways ( number of incoming and outgoing edges) and a lost activity or a bad activity synchronization.

All these defects are detected by IS constraints.

• Start event constraint detects if the start event exists and if it has a predecessor.

• End event constraint detects if the end event exists and if it has a successor.

• Reach extremes constraint detects if there is any connector that does not reach the extremes (domain and range).

• Process_Boundary constraint detects if a connector crosses a process boundary and creates confusion regarding the starting point of the process.

• Split_Outgoing_edges and Join_Outgoing_edges constraints detect if the number of incoming and outgoing edges are incorrect.

• Activity constraint detects if the activity is not reachable from the start event or can not reach the end event.

• Gateway constraint detect if the gateway does not have a name.

Non validated constraints detect a defect and propose to the modeller improvements.

The solutions provided by the pattern through the constraints are corrective guidelines that ask the modeller to:

• Remove any predecessor of a start event or add a start event if it is missing.

• Remove any successor of an end event or add an end event if it is missing.

• Replace a connector if it does not reach the extremes.

• Rename a gateway.

• Add or Remove outgoing/ incoming edges.

• Add new activities that succeed a bad synchronized activity or add a connector from this activity to the end event.

D. Pattern Name: model behavioural correctness

Context: The model behavioural correctness is related to the workflow correctness. Workflow is related to the gateways emplacement in the model.

Problem:

i. Deadlocks

ii.

Lack of synchronization

iii.

To check if this pattern is relevant for the current situation iv.

Check the behavioural aspect constraints

Solution:

i. Deadlock or Lack of synchronization defects are related to the gateways in the model. Thus the solutions provided by the constraints are: Replace the gateway or remove it.

The behavioural aspect correctness of the model is related to the workflow defects in the model, such as Deadlocks and lack of synchronization.

These defects are detected by the behavioural aspect constraints such as D1, D2, PD3, PD4, L5, PL6, UND7 and UND8 defined in Section.3.2.3.2.

The solutions, provided by the pattern through the constraints, are corrective guidelines that ask the modeller to:

• Add a gateway.

• Remove a gateway.

• Rename a gateway.

• Replace a gateway. i. The connector's constraints suggest replacing the connector by others more adequate. ii.

E. Pattern

The XOR constraints ask the modeller if the activities splited by the gateway are contradictory. If it is not, the modeller is recommended to replace a gateway by an other.

The model semantic correctness is related to the incorrect semantic emplacement of concepts in the models. Such as communication between resources, communication between a resource and a gateway, incorrect use of a connector and incorrect use of a gateway.

All these defects are detected by IS constraints.

• Resource constraint checks the resource communication.

• Gateway constraints check the gateways communication.

• Sequence Flow, Message flow and association constraints check the type of domain and range.

• X(OR) gateways check the labels semantics of thee split gateways successors and the Join gateways predecessors.

The solutions provided by the pattern through the constraints, are corrective guidelines that ask the modeller to:

• Replace a connector.

• Replace a gateway.

• Remove a flow that connects a resource to an other or a resource to a gateway.

Conclusion

In this chapter, we presented our proposed quality evaluation process encompassing quality defects and quality metrics to evaluate the business process models with respect to a domain ontology.

In the syntactic and pragmatic evaluation part, we defined quality metrics that detect syntactic and pragmatic defects respectively.

In the semantic evaluation part, pwe define quality defects such as ambiguous representation, incomplete representation and meaningless states. Whereas in the second part, we identified new quality metrics for each deficiency.

The strength of our guided process lies in the fact that the quality measurement metrics provide the BP modellers with a quantified evaluation of the quality of their process models regarding a given domain ontology.

In addition, we described different processes involved in the identification/creation of the quality improvement such as textual guidelines, corrective actions and preventive actions. We proposed different types of improvements: textual guidelines, preventive actions and corrective actions.

Quality improvement is the process of reducing the number of quality deficiencies. For each quality defect, different quality improvement initiatives are proposed and the impact of these improvements is measured and evaluated.

In the next chapter, we present our software prototype "BPM-Quality" that implements our proposed solution and processes. We discuss the architecture of the prototype along with different interfaces available in "BPM-Quality"..

Chapter 5

BPM-Quality: Software Prototype

Implementing the Proposed Approach

We designed and developed a prototype, "Business Process Quality", which implements our quality approach. This implementation has two core objectives. It first helps in demonstrating the feasibility of the approach. The second is related to the validation of the approach. However, the tool's purpose is to enable the evaluation and the semi-automatic improvement of the Business Process models.

"Business Process Quality" exploits the BP model concepts and the domain ontology concepts. It has an import functionality based on XML allowing the evaluation of the semantic quality of BP models.

General architecture

(Figure 32) illustrates the general architecture of the solution. "Business Process Model Quality" BPM-Quality is able to accept conceptual models designed using any modelling tool that export models into XMI, XML or even XPDL. It is important to mention here that XML file contains all the model elements and connectors information.

"BPM-Quality" is conceived for two types of user: Quality Experts and modellers. Quality expert is a user having in depth knowledge about quality concepts. He/She is responsible for defining the quality concepts such as quality metrics, BP meta-model _ontology mappings, quality improvements, etc. In contrast the modeller is a normal user who is familiar with modelling notations and is responsible for designing different business process models. Analysts can only evaluate the models employing the quality concepts defined by quality experts.

"BPM-Quality" is divided into two core modules: the annotation module and the Domain Knowledge Based Quality Management Module.

• The annotation module where the quality expert is responsible for defining the BP Model -Meta-model mappings.

• The Domain Knowledge Based Quality Management Module where the quality expert is responsible of the quality management by defining the quality metrics, quality improvement guides, etc. Similarly, he/she is also responsible of the domain knowledge management by defining the meta-models (BP meta-model and Ontology meta-model), defining the mappings rules, etc. And where the modeller is responsible of executing the constraints, quality metrics and improvements.

• The two modules access a common knowledge base. In fact "BPM-Quality" contains a knowledge base storing different files as BP notations rules, BP and ontology meta-models, etc. defined by the modeller/analyst. Moreover, the knowledge base also stores the BP models domain quality sessions.

Functional view for quality expert

(Figure 33) illustrates the systems behaviour with respect to quality expert. It can be noticed that quality experts interact with "BPM-Quality" with an aim to define the quality concepts in the following way: To define the mappings between the notation concepts and the BP meta-model concepts.

These mappings are used in the annotation module in order to converge all the notations to match our meta-model. The annotation module is explained in details in Section 5.4.

ii.

To define mappings between the ontology meta-model concepts and the BP meta-model concepts. This requires that the notation concepts are already mapped to the BP meta-model concepts. These mappings are used in the Domain knowledge management submodule in order to detect the similarities between the BPM concepts and the ontology concepts. The domain knowledge management submodule is explained in details in Section 5.5.

iii.

To define evaluation metrics. The metrics are used in the Quality definition submodule. The Quality definition submodule is explained in details in Section 5.5.2.1. iv.

To define new improvements functions. The improvement functions are used in the Quality management submodule. Also, the quality management submodule is detailed in Section 5.5.2.2. v.

To associate the metrics with improvement functions. As the improvements are provided to the modeller based on the metrics values, mappings between them have to be identified. This requires that the metrics and the improvements are already identified.

Functional view for modeller

(Figure 34) illustrates the Modeller use case diagram to evaluate quality. This use case describes the systems behaviour with respect to a modeller. It can be noticed that modellers interact with "BPM-Quality" to evaluate and improve their models. Their interactions include the following: ii.

The modeller can browse his/her model's activities

iii.

The modeller can browse his/her model's actor concepts.

iv.

The modeller can execute the evaluation process with respect to each concept selected. In other words, after browsing the activities/actor, the tool will post the evaluation results with respect to the activity/actor selected by the user. The evaluation process includes calculating metrics and proposing improvements. Each metric is associated to an improvement by the quality expert.

v.

The modeller can request the ontology for synonyms, hyponyms, hypernyms or keywords in order to replace the original concept, add new concepts or remove old concepts based on the improvements proposed. annotating the exported models to make the BP models compatible with our meta-model.

Annotation module

In fact each notation has its own concepts and its own semantics. We want to converge the diagrams from different notations to match our meta-model. To do so, mappings from each notation concepts to the meta-model concepts are defined based on the concepts semantics and name matching rules. And these mappings are presented by adding tags to the exported diagrams.

In BPMN, a Process describes the function or the work that must be done. A Process in Eriksson-Penker notation is a set of activities designed to produce a specified output [START_REF] Eriksson | Business Modeling With UML: Business Patterns at Work[END_REF].

And in EPC, functions are activities which need to be executed (Jan [START_REF] Mendling | Yet Another Event-driven Process Chain -Modeling Workflow Patterns with yEPCs[END_REF]. In our meta-model we represent these different concepts that have the same meaning with a

Knowledge management submodule

As our approach exploit IS domain knowledge and application domain knowledge, our tool has two subsubmodels: 1) Application domain knowledge management and 2) IS domain knowledge management.

Application domain knowledge management

The application domain knowledge management subsubmodule consist of three steps:

• The quality expert defines the mappings between the BP meta-model concepts and the ontology meta-model concepts. Moreover, he/she can use the mappings defined by default.

These mappings are stored as Java functions in the Knowledge base.

• After that the mappings are executed, synonyms, hyponyms, hypernyms, keywords and responsibilities are calculated.

• The results are posted to the modeller via an interface. The activity's interface show the synonyms, hyponyms, hypernyms and actor related to the action mapped to the activity (Figure 38). The actor's interface shows the synonyms, hyponyms, hypernyms and responsibilities (Figure 39). He/She can add new responsibilities to the actor that is to add new activities where the latter is responsible of its execution. Also he/ she can replace the old actor with a new one and he/she can remove the old actor.

IS domain knowledge management

The IS domain knowledge management subsubmodule consists of two steps:

• The quality expert defines the IS constraints. He/ She can use the constraints defined by default. The constraints are stored as Java functions in the knowledge base.

if(bpm.StartEventList.size() ==0) { textArea.append("\n"+ "No start event"); textArea.append("\n"+" The model should contain at least one Start event"); }

• Applying the IS constraints on the model.

Figure 40: IS knowledge application interface

As explained in Chapter 3, three types of constraints are defined: syntactic, semantic and pragmatic.

Thus "BPM-Quality" allows the modeller to check each type of these constraints and displays the constraint violated.

Quality management subModule

The quality management submodule in "BPM-Quality" is responsible for defining quality metrics and improvements. It is also responsible for executing the improvements chosen and calculating the quality metrics defined. The relationships between the metrics and the improvements are defined in this submodel.

• Business Process Meta-model

•

Quality evaluation in BPM-Quality

The scenario presented in this section illustrates how the "BPM-Quality" can be used to evaluate and improve the models. The quality definition module is conceived for quality experts only since it requires in depth knowledge about quality concepts. However as mentioned before, we provide two types of mechanisms to accommodate both basic analysts and quality experts for quality evaluation module. Quality experts can skip the metrics and the improvements definition and directly start the evaluation process by selecting the quality patterns or quality metrics from the knowledge base.

However, it requires that they are aware of all the existing contents of the knowledge base and what each concept proposes.

The quality evaluation process starts by selecting the model to be evaluated. The model must first be exported to the XML file format. XML (XPDL) has widely been used in the industry for enhancing the portability of business process models among different modelling tools. Our prototype is based on XML. Thus it can be used to evaluate models designed using any modelling tool capable of exporting its models into XML. Thus, the user selects the model to be evaluated. Once the model is selected, the BPM-Quality's module annotation, annotates the exported model and produces an XPDL file annotated. Once the XPDL file is annotated, the user is proposed the following six options:

i. Formulate new quality metrics: create new Java functions (for quality experts only).

ii.

Use existing quality metrics i.e. the quality metrics existing in the Knowledge base and which were previously used for evaluation.

iii. Formulate new quality constraints: create new Java functions (for quality experts only).

iv.

Use existing quality constraints i.e. the quality constraints existing in the Knowledge base and which were previously used for evaluation.

v. Formulate new quality improvement procedures: create new Java functions (for quality experts only).

vi. Use existing quality improvement procedures i.e. the quality improvement procedures existing in the Knowledge base and which were previously used for evaluation.

This scenario doesn't include the housekeeping of the knowledge base i.e. it doesn't discuss about the insertion, modification or deletion of quality patterns, quality metrics and constraints to the knowledge base. It uses the existing contents of the knowledge base for evaluation and propositions.

Step-1: Validation of IS notation constraints

After that the model is annotated, IS notation constraints are checked. The modeller can choose to check the syntactic constraints, the semantic constraints and the pragmatic constraints respectively.

Each constraint violated is posted to the modeller with improvement textual guidelines.

In the second step, the modeller applies manually the guidelines on his/her model. He/She can recheck the constraints in order to verify the non-violation of previous constraints.

Step-2: Model evaluation and improvement (Figure 38) displays the screen of the application domain knowledge exploitation. The first combo box on the screen contains all the activities seized from the model. Upon the selection of the activity to evaluate:

• The second combo box will list all the chosen activity synonyms provided by the ontology.

• The third combo box will list all the chosen activity hyponyms provided by the ontology.

• The fourth combo box will list all the chosen activity hypernyms provided by the ontology.

• The fifth combo box will list all the chosen activity keywords provided by the ontology.

• The sixth combo box will list all the chosen activity actor provided by the ontology.

A text area will post all the quality metrics results and the textual guidelines associated to the metrics.

Thus based on the textual guidelines, the modeller applies the corrective actions recommended.

• The modeller can replace the current activity with one of its synonyms/ hyponyms/ hypernyms by choosing the synonym from the synonyms/ hyponyms/ hypernyms list respectively and clicking on the "Replace" Button.

• The modeller can add a new activity by choosing an activity from any list and clicking on the "Add" Button. By clicking on the Add button, a new interface will be created to identify the successor and the predecessor of the new activity.

• The modeller can remove the current activity by clicking on the "Remove" Button.

notation? modelling notations. iii.

Only "BPM-Quality" provides the possibility to define quality metrics using the Quality Metrics definition subsubmodel.

iv.

Only "BPM-Quality" provide the possibility to define quality improvements using the Quality improvement guides definition subsubmodule. It also allows the quality expert to map the metrics to the improvements provided.

v.

Only Bizagi and "BPM-Quality" provides preventive improvement guidelines. When the modeller chooses a concept, a definition of the current concept is posted. But "BPM-Quality"

do post an addition to the definition, the concept usage explanation to prevent from emplacement errors.

vi.

Only "BPM-Quality" supports the evaluation and the improvements of models from a big number of notations.

In view of the above findings, we can say that "BPM-Quality" avoids several shortcomings present in other existing evaluation applications. Moreover, "BPM-Quality" can be used for several notations.

Conclusion

In this chapter, we presented our software prototype "BPM-Quality" that implements our proposed solution and process. We started by illustrating the application architecture and we detailed each of the

Validating the selected quality constraints

In the domain of BPM quality, researchers have proposed different constraints for evaluation but the main problem lies in their disparity and non-converging solutions. Moreover there is not any framework that proves the completeness of the constraints identified i.e. if they cover all possible defects or not. We aim to apply the identified constraints on a big number of models so that we can try to cover as many quality defects as possible. In order to do that, we applied them on a collection of models provided by BPM Academic initiative (« BPM Academic Initiative | Signavio » 2013).

i.

We categorized the defects into syntactic, notation semantics and pragmatic constraints.

ii.

We studied the percentage distribution of these defects.

iii.

We analyzed the causes of the most common defects.

iv.

We compared the defects detected by our approach and those detected by two other open source tools.

In total 100 Business process models extracted from the collection provided by BPM Academic initiative were contacted to complete our validation. The advantage of this collection is that we have a big number of models from different domains but the disadvantage is that we don't have any feedback on the modeller's profile. These models contain connector base, notation semantic and pragmatic defects detected by our constraints. The classification of the defects is based on the classification of the IS constraints that detect them. In fact, they were classified in the same way as the IS constraints: into connector base, notation semantic and pragmatic

We have been able to perform an analysis of all models and detect the number of the discussed defects. Thus we quantified the defects errors.

(Table 17) provides the classification of the different types of defects.

Defect type

The number of defected models

Syntactic

Lost Activity

In every state that is reachable from a start event, there must be the possibility to reach an end event.

60 42) gives a good indication that in this model collection, the notation semantic defects present the higher percentage (64%) followed by the syntactic and pragmatic defects (18%). These results confirm the studies in the literature. This percentage distribution is mainly due to the classification of defects as a high number of defects are classified as notation semantic. Besides, the literature studies confirm our analysis. First [START_REF] Mendling | Thresholds for error probability measures of business process models[END_REF]) used a collection of 429 EPC models of an Australian financial institution for validation. Based on their validation results, they tabulated the probabilities of finding different types of errors. The types of errors they studied, based on our classification, are notation semantic errors. In fact, they studied the size, connection, modularity, connector interplay and complex behaviour and they concluded that the complex and the big size models represent the highest percentage.

On the other hand, [START_REF] Rozman | Analysis of Most Common Process Modelling Mistakes in BPMN Process[END_REF] analyzed the most common process modelling mistakes in BPMN process models and they found that :

1) Bad activity synchronization represented by not connected activities and hanging concepts i.e.

not reachable from the start event are 34% of the errors.

2) Processes without start event are 4% of the errors.

3) Processes with multiple start events are 6% of the errors.

4) Processes without end event are 13% of the errors.

5) Incorrect use of sequence flows are 16% of the errors.

6) Incorrect use of associations is 1% of the errors.

7) Incorrect use of message flow is 3% of the errors.

8) Misplaced concepts are 5% of the errors. 9) Improper use of flow elements are 18% of the errors.

Gruhun et al. (Gruhn et Laue 2010) present a new heuristic approach for finding errors. They define patterns related to a violation of soundness property or bad modelling style. To validate their approach, they analyzed almost 1000 models. For this purpose, they used three different model checkers tools. The results of these tools have been compared with the results given by their approach.

534 of the models were detected for soundness errors i.e. almost 50% of the models. The most remarkable errors are related to bad modelling style. That is from the 443 OR-joins in the models, no less than 106 should be replaced by an AND-or XOR-join which can model the given situation more precisely. They also realized that OR-connectors are used too often.

Back to our model collection validation, (Figure 43) depicts the partition of notation semantic defects in our study. It can be seen that the majority of the notation semantic defects belongs to the lack of inputs/outputs (28%), Incorrect use of message flow (15%), followed by unlabeled split X(OR) gateway (14%). Finally, (Figure 45) depicts the partition of pragmatic defects. It can be seen that the majority of the pragmatic defects belongs to the bad structure of activity labels (30%), Processes with multiple start events (25%), followed by the redundancy defect (39%).

The activity label defect may be due to:

i. None of the modelling notations defines what should be the activity label structure.

ii.

The modeller can name the activity anything he/she wants in all the modelling tools.

Process with multiple start events may be due to:

i.

For some notations, processes can be triggered by multiple events.

ii.

The modeller want to describe the real-world case, but only in BPMN, there exists multi types of start events that describe different ways for triggering a process.

The redundancy defect may be due to:

• When an activity occurs twice in a scenario, it is much easier for the modeller to recreate the activity rather than search for the old one and reconnect it.

• When the same flow object is reused many times, the model became unreadable as the connectors overlap.

As mentioned before, these errors have been found using business process models modelled in BPMN. When we applied the IS constraints, an interesting observation from these first results is that the highest percentage of errors is dedicated to the notation semantic errors, which may be due to the big number of defects categorized as notation semantic.

However, the percentage distribution of the defects is related to the modelling language, because the latter does have an influence in the occurrence of error types. For example, in BPMN it is common to have defects related to the connector's semantics, or in EPC there is no such type of error because there is only one type of connectors. Additionally, deadlock, livelock and lack of synchronization are more common in EPC than in BPMN.

Quality evaluation

In order to compare our heuristic results to the results of the existing evaluations in the literature, we selected four well-known tools that check business process models for the modelling defects:

Logizian, Mega, Blueworks and Bizagi. All these four tools support business process modelling with BPMN. After doing the analysis with the different tools, we compared the results.

• Visual paradigm, Logizian simulacian 10.

Table 18: Tools comparison

After doing the analysis with the different tools, the comparison between our tool results and each of the four tools results showed that:

• The syntactic and some of the semantic notation defects were detected by Blueworks, almost as well as our tool. Nevertheless, it does not detect the unlabeled X(OR) gateways outgoing edges, the useless pools and lanes nor the gateway-resource communication. In fact Blueworks is a Pre-evaluation tool, it enforces the modeller to add a limited number of concepts in a specific position which will prevent a lot of syntactic and semantic notation defects. On the other hand, it does not allow the modeller to create a path between two gateways thus it prevent from any deadlocks and lack of synchronization. Moreover, Méga detect the standard BPMN defects. It is a Post-evaluation tool, any defect that broke a BPMN standard is detected. It also provides recommendation on how to correct the defect. But the BPMN standards are not valid to the other notations. Also some defects detected by out tool are not included in the BPMN standards, such as multiple start events, misplaced activity, waste activity, etc... Finally, Bizagi detects the basic BPMN standards such as the start event and the end event bad emplacement by not allowing the modeller to create them in incorrect places.

To conclude, Blueworks and Bizagi do not provide any recommendations in order to explain why the modeller is enforced in a specific list of concepts but Méga provides some of the BPMN recommendations. "BPM-Quality" tool detects all the syntactic and semantic notation defects defined above with improvements (corrective actions, preventive actions and recommendations) to each of the defects detected. Only the actor allocation defect was detected by Blueworks and Logizian. None of the tools analyzes the emplacement of connectors based on their semantic. It may be due to the differences among the tools when it comes to defining the connectors' semantics (message flow, sequence flow and associations).

All the modelling and evaluation tools of business processes concentrate on correcting the structure of the model with no concern on what is missing nor on the semantic of the concepts.

"BPM-Quality" tool detects the notation semantic defects relying on the semantic constraints that should be validated.

3. Do they have any modelling experience? Respondents were required to select their modelling experience from three classes:

• No experience: If they didn't have any practical course on conceptual models.

• Average experience: If they took practice courses on conceptual models.

• Maximum experience: If they are experts in modelling.

4. Do they have any business process modelling experience? Respondents were required to select their modelling experience from three classes:

• No experience: If they didn't have any practical course on business process modelling.

• Average experience: If they took practice courses of BP modelling.

• Maximum experience: If they are domain experts.

5. What notation are they more comfortable with? Respondents were required to select from a list of five pre-defined notations.

• BPMN

• Eriksson-Penker

• Activity diagram

• EPC

• Petri-net 6. Are they familiar with the scenario' domain?

• If they have never been hospitalized: No familiarity with the scenario domain.

• If they have been hospitalized once: Average familiarity with the scenario domain.

• If they have been hospitalized more than once: Good familiarity with the scenario domain. The clarity metric of the actor "Secretary" is equal to 0.33 i.e. it has a lot of synonyms in the domain, that is the actor label is not clear and creates an ambiguity since it may present several meanings in the domain.

2.

The specification metric of the activity "Check patient" present a very low value and this is due to the provided hyponyms of the concept extracted from the ontology. The more the concept has a big number of hyponyms, the more it is general. The user is recommended to replace the activity by one or more specific activities.

3.

The specification metric of the actor "Doctor" presents a very low value that is it has a big number of hyponyms in the ontology. The user is recommended to replace the actor by one or more specific ones.

4.

The Input completeness of the activity "Complete the registration form" is equal to zero since it does not have any input resources. The modeller is recommended to complete his/her model by adding inputs suggested by the ontology.

5.

The Model-Richness metric's low value confirms that the model does not cover a sufficient part of the domain. The modeller is asked to enrich his model. The model can be enriching by either adding new activities suggested by the ontology or replacing an activity by several more specific. It will increase the number of activities i.e. it will increase the model richness' metric value.

Improvements

As demonstrated in Section 4.4, improvements are proposed for the modeller to improve the quality of his/her model. Once the metrics are calculated, corresponding corrective actions or textual guidelines can be proposed to improve and correct the model. Thus, in view of the above metrics results and their interpretations, the following improvements can be applied to improve the model's quality:

• For improving the ambiguity of the actor "Secretary", the ontology provides synonyms extracted from Wordnet and presented by the data property "has synonyms". The user may use the action Replace (Secretary, front-desk staff).

• For improving the abstraction level of the actor "doctor", similarly the ontology provides hyponyms. (Figure 47) is an extract of the domain ontology that represents these hyponyms.

Based on the type based mapping and the semantic based mapping the actor "doctor" is related to the actor "Doctor" as the function Name_Based_Similarity detects that both concepts have the same names. All the relations in (Figure 47) are "is-a" relations that present some of the concepts hyponyms. The modeller may use the action Replace (Doctor, Surgeon), or/and AddActor (Generalist, fill the form of evaluation).

The ontology is an OWL file. The information is extracted from OWL tags. (Figure 46) is an extract presenting the 'is-a' relations between the actor "Doctor" and its hyponyms.

Quality evaluation

Once all the improvements are applied to the original model, the same set of metrics is recalculated to demonstrate the quality improvement due to our proposed quality evaluation and improvement process. The results are placed in (Table 22). 22), we can see that the clarity metric average was "0.32" in the original model whereas it is "0.66" in the transformed model meaning that the concepts are clearer. In fact, we have to point that not if the clarity metric is equal to 1 means that we are in the best situation. When the clarity metric is equal to 1, it means that there are no more synonyms provided by the domain ontology which have nothing to do with the best choice of concepts. The best choice of concept in the model is subjective and related to the modeller. When the clarity metric has increased, it means that the modeller replaced the concept with another provided by the ontology that has less synonyms in the domain i.e. less ambiguous.

Similarly, the specification metric average was "0.6" in the original models whereas it is "0.64" in the transformed models. The metric value has increased with a tiny difference which means that the hypernym choices do not answer the modellers' requirements.

In contrast to the generality metric average, it was "0.31" in the original model whereas it is "0.71" in the transformed models, signifying that most of the concepts are replaced by the adequate level of concepts. The metric value variation for each model is shown in (Figure 48). The growth of the histogram bars means that the generality metric increases i.e. the number of hyponyms decrease.

Similarly to the clarity metric, if the generality metric is equal to 1, it does not mean that we are in the best situation. The most adequate level does not mean the more specific level. (Figure 48) shows that the generality value of the models M2, M3 and M4 increase significantly that is to say that the model's activities were very vague and the ontology provides the modeller with a big number of hyponyms. If a specification metric is not increased, it may result from two causes: 1) the modeller did not replace the concept or 2) an incomplete ontology. The Input completeness metric average value in the original models were 0.01 whereas in the transformed models is 0.07. The metric value is due to the big number of resources in the ontology.

We can conclude that the majority of the models don't include resources for the activities. The simplicity of the inserting resources process to the activities has increased remarkably the value of the Resource allocation completeness metric. (Figure 49) shows the significant growth of the M5 curve, that is, the ontology provides the modeller with a big number of input resources. In contrast of the M7 curve where the ontology did not provide a big number of input resources, this may be due to three reasons: 1) there are no sufficient mappings between the BPM activities and the ontology actions (the BPM can be irrelevant or badly described activities), 2) the modeller didn't add the resources proposed by the ontology, 3) the ontology is incomplete. The Actor allocation completeness metric average in the original models was 0.05 whereas in the transformed models it is 0.1, that is to say that an average of two actors was added to each model even if the ontology provide much more actors. It is due to the complexity of adding actors. The modeller must repartition the activities with respect the actors added. At last, the average value of the model richness metric was "0.19" before the improvement process and it increases to "0.26" i.e. an average of 5 activities were added in each model. The activities added to the model are provided by the ontology through: 1) hyponyms of an other activity, as hyponyms describe details that the modeller may have skipped, 2) context of an other activity, the ontology exploits the temporal relations (succeed, precede) of each action in the ontology.

We can conclude that all the metrics associated to the completeness such as input completeness, resource allocation completeness and model richness metrics have significantly higher values compared to the original model implying that the transformed models are comparatively more complete compared to the original model.

An interesting observation from these results is that the respondent's feedback seems to have an influence on the occurrence of defects.

• The respondents that are familiar with the domain create models with sufficient details. The specification metric's value and the input completeness value were very acceptable.

• The respondents that have a good experience in Business process models have less annotation defects than those who have an experience in conceptual models in general.

Conclusion

In this chapter, we applied our proposed solution and processes on a set of models as case studies to evaluate their efficacy. We identified the domain ontology and the set of respondents. All the metrics were calculated. Improvements were generated and applied to the original model. The resulting transformed models were re-evaluated to check if the proposed improvements actually improved the model or not. In the end, the initial results were compared with the post-transformation results. We identified that the transformed models have significantly better metrics results than the original models suggesting that the proposed approach has helped in improving the original model.

In the next chapter, we conclude the thesis and provide some perspectives and future extensions of the work.

Most of the existing quality frameworks on BPM propose quality metrics relying on the structure of the model. In reply, we proposed:

• fifteen syntactic quality metrics: each metric has a return value that can be a boolean or an integer. We explained each of these metrics by defining their role, the defect they detect and analyzing their return value.

• six semantic quality metrics: all of these metrics have an integer return value and rely on the domain ontology to be calculated.

• three pragmatic quality metrics: each metric has a return value, two of them rely on wordnet in order to be calculated.

The proposed quality metrics evaluate in a quantitative way the syntactic, semantic and pragmatic quality of the model, relying not only on the structure of the model but also on the concepts semantics.

Relying on the proposed metrics, our approach detects syntactic structure defects (X (OR) Split gateways defects, Deadlocks, Unlabeled Activities, etc), semantic structure defects (Incorrect use of sequence flow, lack of actor, etc) and pragmatic structure defects (eliminate the redundant concepts...etc). In addition to semantic quality metrics based on the knowledge of the domain ontology such as clarity, generality, specification, model richness, etc. Based on the constraints violation and the metrics values, improvements are proposed. Improvements are classified into: textual guidelines, corrective actions and preventive actions. Moreover, quality improvement patterns are identified; each pattern has a name, a context, specific to a problem and provides solutions. Moreover, we were able to correct syntactic defects such as the lack of actors, bad emplacement of gateways, unlabeled activities, etc. Additionally to semantic defects such as ambiguity, input completeness, etc and pragmatic defects such as eliminating the redundant concepts , refactoring the activity labels, etc.

After the formulation of the IS constraints, quality metrics and improvements, we conducted two validation experiments. The first was performed on a set of one hundred business process models from BPM Academic initiative to ensure that the quality constraints defined detected a big number of the important quality defects in the evaluation of Business process models. The second was performed on models described by respondents in order to validate the strengths and benefits of employing our proposed approach in evaluating and improving the BP models. In fact we evaluated the semantic quality of the BP models by calculating the semantic metrics and analyzing the results.

Additionally, we compared the original models's and the transformed models's metrics results in order to demonstrate the effectiveness of the improvements applied. This activity enabled us in identifying the most common used improvement procedures.

We developed a software prototype"BPM-Quality" implementing our proposed quality approach and guidance process for evaluating and improving BPMs. Our prototype automates all the above mentioned steps of our approach and implements a workflow enabling its users to evaluate and improve BPMs efficiently and effectively. "BPM-Quality"maintains a knowledge base storing different quality metrics, IS constraints and improvement procedures. After applying the IS constraints and calculating the quality metrics "BPM-Quality" proposes improvements procedures.

The approach suffers from some limits. The main one is the fact that the domain knowledge in hand is not necessarily complete. This is the reason why we propose to enrich the sources of domain knowledge with IS constraints. Hence the quality of the domain ontology affects the reliability of the metrics results and the effectiveness of the improvements proposed. We can seize from the literature research papers on the quality evaluation of domain ontologies such as [START_REF] Tartir | OntoQA: Metric-based ontology quality analysis[END_REF], [START_REF] Stvilia | A Model for Ontology Quality Evaluation[END_REF]),etc.

An other limit is the completeness of the quality constraints and metrics. We can not assure that we can detect all the defects that a modeller can create, yet we aggregated as much defects from the literature as possible and defined new defects based on experiments done.

Finally, our approach requires further validation models to prove the improvement process robustness.

As a matter of fact, we applied our approach on eight models allowing us to calculate and illustrate the semantic metrics on each concept in the BP models and to convay the different improvemennts proposed for each defect.

Future Work -Perspectives

Our thesis opens multiple directions for future research. This future work could be extensions to the actual work or new perspectives that are new work.

The first research direction aiming at extending our work includes:

• The improvement of distances computing the mappings between the BP models and the ontologies.

• The enrichment of quality metrics, thus defining new semantic quality criteria.

• Define thresholds for the quality metrics. For example, we know that when clarity metric value is decreasing the concept is more ambiguous but there is no specified threshold value.

• The quality metrics results are ranged into the interval [0, 1]. However, the clarity metric value "0.1" has a different meaning then the generality metric value "0.1". For that reason, and as a continuity to this thesis, metrics values should be compared to each others and new boundaries should be analyzed for each metric.

• Validation was done on a small number of models, that is, to analyze and apply the improvements proposed by the approach. We need to broaden the validation on a biger number of models in order to cover as much defects as possible. The integrity of defects detection can not be assured, but the bigger the number of models evaluated, the higher the number of defects are analyzed and detected.

• The synonyms in our approach are calculated via Wordnet. Thus some of the synonyms are not related to the domain. Integrating synonymy in the domain ontology will provide us with more adequate synonyms.

The second research direction, for improving the current work, includes the extension of our prototype in the following ways: i.

To integrate a behavioural domain ontology (if exists) which present domain actions behaviour in order to help the identification of the sequence of activities. Thus a behavioural ontology may detect semantic defects related to the activities flow (two activities cannot happen in parallel, thus relating them with an AND split gateway is incorrect, etc).

ii.

To include the automatic application of proposed transformations. In our approach transformations are a category of recommendations. The current version of our prototype provides details about the relevant transformations whereas the application of these transformations is a manual process.

The third research direction could be to formulate a pivot model that integrates all the business process modelling notation concepts. And based on this pivot model we can transform models from a notation to an other.

The fourth research direction can be to create a SharePoint Online that provides an integrated location where modellers can share their models. As a result, we will have an online database for business process models, this database will enable the modellers to share their knowledge and find organizational resources and information. It will also help to extend the evaluation experiences, largescale experiences, hence detecting the largest number of defects that can be made and hopefully attend a level where no new defects are detected. Based on the defects detected, new constraints and new metrics will be created and stored into the knowledge base and efficiently help the modellers to improve the quality of their models.

  représente la connaissance fournie par les méthodes, les notations, les pratiques et les outils. La solution proposée prend en compte les principaux obstacles à ce genre d'exploitation des connaissances. Les principaux obstacles que nous avons identifiés sont: -Manque de centralisation: il existe dans la littérature, ainsi que dans les manuels de notations, des dizaines de règles et conseils sur le bon usage des concepts. Cette connaissance est généralement étalée partout, dans les documentations d'outil, sur les sites Web, dans les documents de recherche et dans une variété d'autres sources faisant son exploitation difficile. Notre solution proposée rassemble ces connaissances et propose un outil automatisant son exploitation pour prendre en charge la détection et la correction des défauts liés à la conformité de notation. -Absence de formalisme: Pendant notre analyse de la connaissance du domaine, se révèle l'hétérogénéité de formalisation. Alors que certains guides sont exprimées à l'aide des langages formels, d'autres sont textuelles et vague et certains sont tout simplement liés à l'expertise de modélisation et ne sont jamais exprimés explicitement. Nous proposons d'utiliser (Object Constraint Language OCL ) pour exprimer les règles et les conseils définissant la «meilleure» utilisation de concepts. Ces contraintes, formellement exprimé, sont donc faciles à corriger et a utiliser dans un support automatisé. -Hétérogénéité des notations: il existe une variété de notations pour la modélisation des PM ayant chacun son propre vocabulaire et ses règles spécifiques. Pour assurer la généricité de notre approche, nous construisons notre raisonnement au niveau d'un métamodèle de PM. Les contraintes OCL qui sont communes et valable dans toutes les notations sont généralisées et donc écrites au niveau métamodèle qui les rend indépendants de notations spécifiques. Il reste cependant quelques concepts spécifiques qui ne vaut que pour quelques notations. Notre approche permet également la définition des contraintes au niveau de la notation de gérer des situations spécifiques.

Figure 2 :

 2 Figure 2: Métamodèle pour les modèles de PM

Figure 3 :Figure 4 :

 34 Figure3: Métamodèle pour les ontologies[START_REF] Purao | A multi-layered ontology for comparing relationship semantics in conceptual models of databases[END_REF]

Figure 5 :

 5 Figure 5 : Lindland et al. (Lindland, Sindre, and Solvberg 1994)

  Clarity (o) = 1/ |C_synonyms (o)| Si |C_synonyms(o)|= 0 le concept est dépourvu de sens.

Generality

  le rapport de 1 au nombre total de hyperonymes détectés dans l'ontologie. Specialization (c) = 1/ hypernyms(c) Si |hypernyms(c)| ¹0 et inconnu sinon Pour évaluer l'incomplétude, on a définit quatre métriques : • Input incompletness: Chaque activité dans le PM a besoin de consommer/produire des ressources. Donc l'incomplétude est détecté si les entrées et / ou sorties sont manquantes pour une activité. • Actor allocation incompleteness: Chaque activité est attribué à un acteur responsable de son exécution, nous pouvons compter sur les connaissances fournis par l'ontologie pour completer le PM. • Model richness: la richesse du modèle est liée à la couverture totale du domaine. Pour évaluer le modèle richesse, nous avons défini deux mesures: Model activity richness et model resource richness. Model Activity Richness (c) = Nb of activities in the model /Nb of actions in the ontology Model Resource Richness (c) = Nb of resources in the model /Nb of artefacts in the ontology 4.4. Evaluation de la qualité pragmatique Afin d'évaluer la compréhensibilité, nous avons identifié un ensemble de métriques de qualité pragmatiques.

Figure 1 :

 1 Figure 1: Van der Aalst BP Management Life Cycle (Wil M. P. van der Aalst, Hofstede, et Weske 2003)

Figure 2 :

 2 Figure 2: BPMN Meta-Model [http://www.omg.org/spec/BPMN/2.0/]

Figure 3 :

 3 Figure 3:A basic meta-model of business modelling concepts (Penker et Eriksson 2000)

  it has its own relation to a function. So the meta-model contains a relationship between the type of relation and the resource, which determines which type of relation to a function is possible for what resource.

Figure 4 :

 4 Figure 4:EPC Meta-model (Seel et Vanderhaeghen 2005)

OMG' s

 s Unified Modelling Language (UML) captures all attributes and behaviours of the objects modelled. The UML activity diagram is one of these diagrams. It is both a flowcharting technique and a special kind of state machine whose activities are states and interactivity links trigger-less transitions (Havey 2005).

Figure 5 :

 5 Figure 5: UML activity diagram Meta-Model (Havey 2005) An activity diagram is used to display the sequence of activities. It shows the workflow from a start point to an end point passing by decision nodes or fork nodes (Figure 5). UML activity diagram elements are comprehensible. They support the control flow and the information flow. However, they are limited in terms of model resources and of the different synchronization elements.

Figure 6 :

 6 Figure 6:Petri net meta-model (Bosilj-Vuksic, Giaglis, et Hlupic 2001) Petri nets have a limited number of symbols but have a large power of representation. They are well suited for representing the synchronization of resource communication (Bosilj-Vuksic, Giaglis, et Hlupic 2001). However, these models also have disadvantages. Perhaps the main disadvantage is that

  decision can not be done based on the representation power. It is better to base the choice between the notations on other matters such as what I want to present in my model. If I want to discuss the process workflow I have to use EPC notation. If I want to discuss the different types of resources, I need to use Eriksson-Penker notation, etc.

  Objecteering and Rational Rose. It supports UML diagrams i.e. activity diagrams and business process models based on Eriksson-Penker notation by adding the Eriksson-Penker Extensions (EPBE) v1.0 module. To start with the Eriksson-Penker Extensions diagrams we require the EPBE module. This module is developed by Hans-Erik Eriksson and Magnus Penker. The Eriksson-Penker Business Extensions form a basic framework for business extensions to UML to which a business architect can add stereotypes or properties suitable to his or her line of business. Similar to Bizagi, StarUML validates the elements locations and connections. Secondly, StarUML allows creating Activity diagrams and verification of software models by applying the basic UML regulations. By default there are thirty-eight regulations defined for verifying models. These definitions are mostly adaptations of the Well-formedness Rule in the UML specification. StarUML doesn't provide any evaluation report.

(

  Becker, Rosemann, et Uthmann 2000b) present a framework to structure factors for the evaluation of process models: Guidelines of Modelling (GOM) which structures different quality criteria as correctness, relevance, economic efficiency, clarity, comparability, and systematic design. GOM aims to develop specific design recommendations in order to increase the quality of models beyond the fulfilment of syntactic rules.

Figure 7 :

 7 Figure 7: The framework of the Guidelines of Modelling (Becker, Rosemann, et Uthmann 2000b)

  Characteristics, attributes and measures of activity[START_REF] Heinrich | Defining the Quality of Business Processes[END_REF]

Figure 8 :Figure 9 :

 89 Figure 8: Lindland and al.'s quality framework (Krogstie, Lindland, et Sindre 1995a)

Figure 10 :

 10 Figure 10: Concepts in the framework of Moody and Shanks (1994) Lindland, Sindre and Solvberg's framework purpose is to understand quality in conceptual modelling based on the separation of goals from means. Similarly Krogstie, Lindland and Sindre's framework purpose is to understand quality in conceptual modelling by adding the agreement goal and the social construction theory. Both frameworks focus on the theory. On the other hand Moody and Shanks framework purpose is to evaluate the quality of entity relationship models based on evaluation methods. It focuses on the practice.

  In fact, based Moody et al. (D. L. Moody et al. 2002) calculated the Completeness (Sufficiency) of quality Categories: syntactic, semantic and pragmatic by measuring the proportion of the variance of the dependent variable explained or

  Definition and formula NA Number of activities of the software process model. NWP Number of work products of the software process model. NPR Number of roles which participate in the process. NDWPIn Number of input dependencies of the work. Products with the activities in the process. NDWPOut Number of output dependencies of the work products with the activities in the process. NDWP Number of dependencies between work products and activities.

  Or applying Petri nets to workflow management systems has many advantages. One of the advantages beside their clear semantics, is the existence of Petri net verification techniques (W. M. P. V. D. Aalst 1998). Van der Aalst and al. (W. M. P. van der Aalst 1999), Pankratius et al. (Pankratius et Stucky 2005) formalize EPCs, BPMN and workflow models with Petri nets and provide them with clear behavioural semantics that can be analyzed. Sabbagh et al. (Eid-Sabbagh et Weske 2013) introduced a novel Petri net based formalization of Business Process architectures, trigger-flow nets, that enable the analysis of business process architectures, trigger-flow nets, with know Petri nets analyzing techniques in regard to their structural and behavioural properties. They found several dead events and a deadlock that could not be identified by a pattern based verification technique.

  states that Business Process Improvement is basically the product of Business Process Reengineering, Redesign, and Benchmarking, depending on the degree of change necessary. Thus literature mentions many different terms relating to the management and improvement of Business Processes, including: Business Process Redesign, Business Process Reengineering and Business Process change.

  Riehle and Züllighoven[START_REF] Riehle | A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor[END_REF] define pattern as the concrete form which recurs is that of a solution to a recurring problem. WhileAlexander et al. (C. Alexander, Ishikawa, et Silverstein 1977a) define business process improvement pattern as an abstract form of a recurring instance of a process modification step used in a Business process improvement activity. Research

  knowledge in a given domain facilitates the acquisition of new domain requirements. Moreover, different studies confirm these statements, as (Burton-Jones et Weber 1999)[START_REF] Khatri | Understanding Conceptual Schemas: Exploring the Role of Application and IS Domain Knowledge[END_REF], they indicate that domain knowledge can compensate for a lack of clarity and missing information in the representation of a problem.Buchman and Edkadharmawan[START_REF] Buchman | Barriers to sharing domain knowledge in software development practice in SMEs[END_REF] report a number of case studies as a result of which barriers to shared domain understanding among stakeholders and development teams were identified and graded.Two of the most important barriers identified are: i) inter-group diversity relates to different levels of knowledge, both businbess (domain) and technical and ii) lack of common vocabulary that may lead to delays and to confusion and misunderstandings.Similarly, McAllister (McAllister 2006), who reports a field study intended to identify the factors that lead to misunderstandings regarding requirements, as percieved by users and by developers. The dominant factors that both users and developers indicate include developer's lack of understanding difficulties related to common language and terminology. Domain knowledge results from an accumulation of knowledge about a problem domain understanding. Many experiences in academic and non academic topics showed that prior knowledge in a domain has consistently been shown to have positive effects on activity performance[START_REF] Chiesi | Acquisition of domain-related information in relation to high and low domain knowledge[END_REF]. In conceptual modelling several authors pointed out the impact of lack of domain knowledge on the quality of produced models. Indeed, experiences conducted in[START_REF] Agarwal | The role of prior experience and task characteristics in object-oriented modeling: an empirical study[END_REF] [START_REF] Shanks | Conceptual Data Modelling: An Empirical Study of Expert and Novice Data Modellers[END_REF]) (Dinesh Batra et Davis 1992) (Abd[START_REF] Ghani | Complexity metrics for measuring the understandability and maintainability of Business Process Models using Goal-Question-Metric (GQM)[END_REF] suggest that user differences in cognitive abilities, application domain knowledge and method knowledge affect the way that conceptual modelling and information acquisition is conducted. Moreover, authors in[START_REF] Khatri | Understanding Conceptual Schemas: Exploring the Role of Application and IS Domain Knowledge[END_REF] (Khatri et Vessey 2010a) concluded through a study that in Information Systems discipline, domain knowledge comprises two parts: 1) IS domain knowledge embedded in methods, notations, and tools and 2) application domain knowledge referring to real-world problems understanding.In the context of this thesis, we propose a solution that captures the three kinds of knowledge impacting the quality of models namely: (i) IS domain knowledge, (ii) Application domain knowledge and (iii) knowledge related to accumulation of experiences in modelling.

Figure 11 :

 11 Figure 11: Business process modelling context (i)The IS domain knowledge represents the knowledge related to BP modelling notations, methods, and practices. Even if these guides exist, modellers still produce models that do not conform to these guides and advices. Our approach proposes to exploit this knowledge capitalized from notations handbooks, research literature and several sources providing such guides. The proposed solution takes into account the main barriers to this kind of knowledge exploitation. The main barriers we have identified are:

Figure 13 :

 13 Figure 13: Business Process model Meta-Model

  1

•

  domain and a range. Thus a domain represents the input extreme of a connector and the range represents the output extreme of a connector.Let C be the set of connectors, C= < An association is a simple link between two concepts. It has a domain and a range.Let As be the set of associations, As= < n as as ..

  1

  1

Figure 14 :

 14 Figure 14: Mappings between different concepts having the same role: Process Rule 2: Actor

Figure 15 :

 15 Figure 15: Mappings between concepts having the same role: Actor

Figure 16 :

 16 Figure 16: Connectors in different modeling languages (Gruhn et Laue 2010)

Figure

  Figure 17: Resources in different notations

  papers on the most common errors in workflow as Gruhn et al. (Gruhn et Laue 2010) , (Jan Mendling 2009), Mendling and Aalst (Jan Mendling et Aalst 2007), Van der aalst et al. (W. M. P. van der Aalst et al. 2011), Fahland et al.[START_REF] Fahland | Instantaneous Soundness Checking of Industrial Business Process Models[END_REF]) and notations handbooks.

context

  Process inv reached_from_start_event: Connector.allInstances() -> forAll(c| c.Range.fID = self.fID implies Connector.allInstances()-> exists (c1| c1.Range.fID= c.Domain.fID and c1.Domain.ftype = #start_event)) 3. Each activity should have two relationships.

Figure 18 :

 18 Figure 18: Activity with two outgoing edges

Gateway

  and j.gtype = #AND_join and e.gtype= #XOR_split and c1.Domain.fID = s.fID and c1.Range.fID = j.fID and c2.Domain.fID = s.fID and c2.Range= e and c3.Domain = e implies c3.Range.fID <> j.fID ))

Figure 19 :

 19 Figure 19: Sequence flow crosses the process boundary 11. Each X(OR) Split gateway should be labelled Each Split XOR/OR gateway should have a name presenting the split event (Figure 20).

(

  « BPMN Tutorial Gateways -BPMN-Community » 2013).

Figure 20 :

 20 Figure 20: XOR Split Gateway

Figure 21 :

 21 Figure 21: Activity with two outgoing edges

Figure 22 :

 22 Figure 22: Timer intermediate event Informational aspect defines the information involved in a business process. The information are presented by resources from different types. Thus informational constraints are the constraints associated to resources.

context

  Connector inv resource_gateway_connection: Resource.allInstances()->forAll(r| self.Domain.fID = r.rID implies Gateway.allInstances()->forAll(g|self.Range.fID <> g.fID)) context Connector inv resource_gateway_connection2: Resource.allInstances()->forAll(r| self.Range.fID = r.rID implies Gateway.allInstances()->forAll(g|self.Domain.fID <> g.fID))

context

  Message_flow inv Mf_domain: Message_flow.allInstances()->forAll(mf| mf.Domain.ftype = #abstractresource or mf.Domain.ftype = #informationresource implies mf.Range.ftype = #process) context Message_flow inv Mf_range: Message_flow.allInstances()->forAll(mf| mf.Range.ftype = #abstractresource or mf.Domain.ftype = #informationresource implies mf.Domain.ftype = #process)

Figure 23 :

 23 Figure 23: Process with no start event Figure 24: Process with multiple start events

Figure

  Figure 25: Erroneous model

(Figure 26 )

 26 illustrates an example of mappings between BP model concepts and domain ontology concepts. Based on these mappings, we exploit the domain knowledge by studying the different types of ontology relations.

Figure 26 :

 26 Figure 26:Mappings between Domain Ontology and Business Process Model

Figure 27 :

 27 Figure 27: Ontology Meta-model

  Let OD be the set of ontology concepts. OD = ontology concept that can be an actor, an action or even a relation.Let BP be the set of the business process model concepts. BP= process concept that can be a flow object, an activity or a connector.Each business process model concept bpc is mapped to a set of ontology concepts oc [ ].

•

  A message flow in the BP meta-model represents the exchange of messages between two participants. It is represented by a communication and a transfer relation in the ontology since they have the same role. • The Role relation in the BP model describes the role of a resource into an activity. It is presented with an execution, manipulation, observation or influence relation which shows the participation role of the different concepts.

  concepts, the synonyms, and keywords associated to ontology concepts. It is based on Wordnet and distance computation algorithms from literature such as Resnik information content[START_REF] Resnik | Using information content to evaluate semantic similarity in a taxonomy[END_REF],[START_REF] Jiang | Semantic Similarity Based on Corpus Statistics and Lexical Taxonomy[END_REF], Lin[START_REF] Lin | An Information-Theoretic Definition of Similarity[END_REF], Wu and Palmer path length (Wu et Palmer 1994), Pathwardhan & Pedersen context vectors (Purandare et Pedersen). There are six classes of matching rules. The rules are all defined as functions having, as input, one or several BP model concepts and returning one or several concepts from the domain ontology. 0≤ IC(c) ≤ 18.75 where larger values indicate greater relatedness Min = -log (1) = 0 = IC( root) Max =-log(1/freq(root)) = 18.75 = IC( least frequent i.e. most informative) Based on this algorithm, we can compute the ontology concepts that are synonyms of the BPM concept bp. Ontology-Resnik-Synonyms(BPM bpm) { For all the ontology concepts Calculate IC = sim (bp, o); if( IC > 15) return o[i] } b) Synonymy calculated by Wu and Palmer path length (Wu et Palmer 1994): (Wu et Palmer 1994) propose a measure that computes the similarity between two concepts by looking at the path length between them in the Wordnet taxonomy.

  c) Synonymy calculated by Purandare and Pedersen context vectors (Purandare et Pedersen 2004): Purandare developed a measure of semantic relatedness that represents a concept as a Context

4)

  More general level: This function returns the list of the most general concepts of the ontology i.e. there is a relationship of superiority (also called hypernyms or IS-A relationship) between the business process concept in parameter and the ontology concepts in return. In other words, it returns the range of the IS-A relation. The function More-General takes a flow object b as input and returns a set of ontology concepts MG[ ] more general than b. • It retrieves the Name-Based-Similarity(b) , the Partially-Name-Based-Similarity(b) and the Synonymy(b) results • Collect all their hypernyms. To collect the hypernyms we have to exploit the "IS-A" relations from the ontology, finally returning the IS-A range. More-General (FlowObject b) : MG[ ] { /* The name based similarity ontology concepts are saved into a set O[ ] */ O[ ] = Name-Based-Similarity(b) ; /* The partially name based similarity ontology concepts are saved into a set O'[ ] , O'.length is the cardinality of the set O'*/ O'[ ] = Partially-Name-Based-Similarity(b) ; /* The synonyms ontology concepts of the BP concept are saved into a set O''[ ], O".length is the cardinality of the set O" */ O''[ ] = Synonyms(b) ; Connector C; for( int i=0; i<O.length ; i++) { if( C.type=="IS-A" and C.domain = O[i]) return C.range } for( int i=0; i<O'.length ; i++) { if( C.type=="IS-A" and C.domain = O'[i]) return C.range } for( int i=0; i<O".length ; i++) { if( C.type=="IS-A" and C.domain = O"[ispecific level: returns the ontology concepts having an inferiority relationship with a concept from the ontology detected as synonyms or syntactically equivalent to the BP model element. The function More-Specific takes a flow object b as input and returns a set of ontology concepts MG[ ] more specific than b. • It retrieves the Name-Based-Similarity(b), the Partially-Name-Based Similarity(b) and the Synonymy(b) results

  -Specific (FlowObject b) : MG[ ] { /* The name based similarity ontology concepts are saved into a set O[ ] */ O[ ] = Name-Based-Similarity(b) ; /* The partially name based similarity ontology concepts are saved into a set O'[ ] */ O'[ ] = Partially-Name-Based-Similarity(b) ; /* The synonyms ontology concepts of the BP concept are saved into a set O''[ ] */ O''[ ] = Synonyms(b) ; Connector C; for( int i=0; i<O.length ; i++) { if( C.type=="IS-A" and C.range = O[i]) return C. domain } for( int i=0; i<O'.length ; i++) { if( C.type=="IS-A" and C.range = O'[i]) return C. domain } for( int i=0; i<O".length ; i++) { if( C.type=="IS-A" and C.range = O"[iconcepts: returns a set of ontology concepts linked to the results obtained by name based and synonym based similarity by a "temporal" or an "influence" relation to an other ontology concept. The function Context takes a flow object b as input and returns a set of ontology concepts MG[ ] . • It retrieves the Name-Based-Similarity(b), the Partially-Name-Based Similarity(b) and the Synonymy(b) results

  Context (FlowObject b) : MG[ ] { /* The name based similarity ontology concepts are saved into a set O[ ] */ O[ ] = Name-Based-Similarity(b) ; /* The partially name based similarity ontology concepts are saved into a set O'[ ] */ O'[ ] = Partially-Name-Based-Similarity(b) ; /* The synonyms ontology concepts of the BP concept are saved into a set O''[ ] */ O''[ ] = Synonyms(b) ; Connector C; for( int i=0; i<O.length ; i++) { if(( C.type=="influential" || C.type = "temporal" )and C.domain = O[i]) return C. range } for( int i=0; i<O'.length ; i++) { if( ( C.type=="influential" || C.type = "temporal" )and C. domain = O'[i]) return C. range } for( int i=0; i<O".length ; i++) { if( (C.type=="influential" || C.type = "temporal" )and C.range = O"[i

  c ) ≠ 0 and unknown otherwise Where c is a modelling element from the BP model and |hyponyms(c)| is the number of hyponyms of c.

  c) ≠0 and unknown otherwise Where c is a modelling element from the BP model and |hypernyms(c)| is the number of hypernyms of c.

Figure 29 :

 29 Figure 29: SPI Initiatives distribution of the publications (Unterkalmsteiner et al. 2012)

  the improvement process: Explain what the possible ways to correct the defect are. b) Pre-Post comparison: Compare the success indicator after and before the improvement process.

Figure 30 :

 30 Figure 30: Our improvement process • The IS constraints are violated when a quality defect is captured. The IS constraints solve the quality defects related to how the concepts are used in the model i.e. is the concept correctly used and the way this concept is elaborated in, does it yield the necessary information? Thus these constraints point out the problem but do not solve them. We aim to propose improvements to each of these defects.

A

  Sequence flow relates two flow objects. The successor and the predecessor should be of type flow object in order not to violate the Sequence flow constraint. relates a resource to a flow object. Thus to meet the Message Flow constraint, the successor or the predecessor should be of type flow object, the other one should be of an artefact to a flow object. Thus to meet the Association constraint, the successor or the predecessor should be of type flow object, the other one should be of type artefact.

  b): This function aims to rename the BP model Old_concept with the name of the New_concept. No constraints are attached to this function since neither the successor's type nor the predecessor's type is changed.

Context:

  To check the completeness of the model. This pattern is suitable for unfinished and incomplete models. Problem: i. Sometimes models present only a subset of the domain a. Very vague activities b. Activities with no inputs c. Activities with no outputs d. Activities with no actor allocated to it. ii. Some concepts attributes may complete the requirement presented in the model. a. Missing X(OR) Split gateway name b. Missing X(OR) Split outgoing edge name iii.The lack of basic concepts in the model a. A model with no start event b. A model with no end event. iv.To check if this pattern is relevant for the current situation. a. Calculate the Model Richness metric b. Calculate the Resource Richness metric c. Calculate the Input Richness metric d. Calculate the Actor_Allocation metric e. Check the validity of the Start_event constraint f. Check the validity of the End_event constraint g. Check the validity of the X(OR)_Split_name constraint h. Check the validity of the X(OR)_Split_outgoing_edges_name constraint i. Check the validity of the Actor_Allocation constraint j. Check the validity of Activity_Input constraint k. Check the validity of Activity_Output constraint.

  Name: model semantic correctnessContext: The model correctness is related to the semantic correctness of the concepts. Semantic defects may be present due to bad concepts emplacement in the model or inappropriate mappings.

Figure

  Figure 32: Prototype Architecture

Figure 33 :

 33 Figure 33: Use Case Diagram: Define the Quality Concepts

Figure 34 :

 34 Figure 34: Use Case Diagram: Evaluate the Quality i.The modeller selects the target model for evaluation. In order to evaluate it, the model should be annotated by the BPM_Quality annotation module.

  Process. As a result in a XML/XPDL file exported from a BPMN diagram, each Activity is annotated by a "Process". In a XPDL file exported from an EPC diagram, each function is annotated by a "Process". Similarly, an Actor in Eriksson-Penker notation is an actor acting in the process. In BPMN the Pool, Lane and Performer represent the participant in the process. And in EPC, an organization unit is a specific role within the process. All these concepts are represented within an Actor in our meta-model. As a result, in a XPDL file exported from a BPMN diagram, each Pool/Lane/Performer is annotated by an "Actor". The annotation process provides a business process model annotated and compatible with our meta-model.To summarize, the annotation module, it takes as input the BP model exported in XML, XPDL or XMI and BP notation concepts-metamodel mapping rules the annotation rules to generate a BP model annotated and congruent to the BP meta-model Figure35.

Figure

  Figure 35: Annotation Process

Figure 38 :

 38 Figure 38: Activity synonyms interface

Figure 39 :

 39 Figure 39: Actor hyponyms interface Similarly to the activities, when the modeller chooses an actor from his/her model (List of actors), the BPM_Quality tool calculate the mappings between the current actor and the ontology actors. Synonyms, hypernyms, hyponyms, keywords and responsibilities are displayed. Moreover, quality metrics are calculated and posted in the interface's text Area. The modeller can add a new actor.

  Figure 41: Knowledge base Structure

Figure 45 :

 45 Figure 45: Pragmatic errors percentage

2 :

 2 It is BPMN 2.0 Business workflow design software. Logizian identify and Fix Design issues with model quality checker. When running the model quality checker, a series of checking are performed on every model element in the project. When it finds a design issue, marks are deducted from that model element (« Logizian 10.2 » 2013). • IBM Blueworks Live: Blueworks Live combines features of WebSphere Lombardi Blueprint and IBM BPM Blueworks into one online cloud-based BPM tool that enables collaboration and process automation. Blueworks implement modifications adapted on the process model. It does not allow the modeller to misplace the concepts which prevent any syntax error (« IBM Blueworks Live » 2013).• Mega Process: It provides capabilities for modelling, documenting, and improving business processes and organizational structures. It analyse the information flows and detects structure errors. Mega can enforce rules to make sure that the main modelling standards are respected when the modeller describe his/her model. BPMN standards are activated so that it can show which BPMN standard is broken (« MEGA Process » 2013).• The Ford tool, Bizagi: It is business process management software which provides leading process automation and workflow automation solutions. After the modeller finishes describing his/her model, Bizagi checks the model structure and posts the defects detected (

Figure 46 :

 46 Figure 46: OWL extractReading a OWL tags isn't practical Thus we will present the ontology information in a graphical way (Figure47).

Figure 48 :Figure 49 :

 4849 Figure 48: Generality metric variationThe specification and the generality metrics change at every ontology pass since when the modeller replaces an old concept with a new concept from the ontology, the new concept has different number of hyponyms and hypernyms, thus different value of specification and generality metrics.

  Figure 50: Actor allocation metric variation

  Figure 51: Model richness metric variation

Figure

  Figure 59: Model-4

-

  Trois métriques pour évaluer la qualité pragmatiques: chaque métrique a une valeur de retour, deux d'entre eux comptent sur WordNet pour être calculé.Notre approche souffre de quelques limites. Le principal est le fait que la connaissance de domaine en main n'est pas nécessairement complète. C'est la raison pour laquelle nous proposons d'enrichir les sources des connaissances de domaine avec les contraintes. Par conséquent, la qualité de l'ontologie de domaine affecte la fiabilité des résultats des métriques et l'efficacité des améliorations proposées.Une autre limite est la complétude des contraintes et des paramètres de qualité. Nous ne pouvons pas assurer qu'on peut détecter tous les défauts d'un modèle, mais nous avons regroupé autant de défauts de la littérature que possible et on a définis de nouveaux défauts sur la base des expériences faites.Au cours des dernières années, les problèmes liés à la modélisation et l'amélioration des processus métier ont reçu un intérêt croissant. En effet, les entreprises prennent conscience de l'impact indéniable d'une meilleure compréhension et gestion des processus métier (PM) sur l'efficacité, la cohérence et la transparence de leurs opérations commerciales. La modélisation des PM vise à une meilleure compréhension des processus, permettant aux décideurs d'atteindre les objectifs stratégiques de l'entreprise. Cependant, les analystes manquent souvent de connaissances du domaine, ce qui affecte la qualité des modèles qu'ils produisent.Notre approche vise le problème lié à la qualité des modèles de processus métier en proposant une approche globale: des méthodes et des outils) de mesure et d'amélioration de la qualité des modèles de

Enfin, notre approche nécessite d'autres modèles de validation pour prouver la robustesse de notre processus d'amélioration. En fait, nous avons appliqué notre approche sur huit modèles permettant de calculer et d'illustrer les résultats des métriques sur chaque concept dans les modèles de PM et à afficher les différents amélioration proposé pour chaque défaut.

Abstract

Résumé

processus métier (PM. Nous proposons de soutenir cet effort de modélisation avec une approche qui utilise les connaissances de domaine pour améliorer la qualité sémantique des modèles de PM.

La principale contribution de cette thèse est quadruple:

1. L'exploitation des connaissances du domaine d'u système d'information (IS domain knowledge): Un métamodèle des processus métier est identifié. Des règles sémantique ajoutés au métamodèle par des contraintes OCL.

2. Exploiter des connaissances du domaine d'application (application domain knowledge).

Elle s'appuie sur des ontologies de domaine. Des alignement entre les concepts des deux métamodèles sont défini et illustré. 3. La conception du processus de qualité englobant des méthodes et des techniques pour évaluer et améliorer les modèles de processus métiers. Notre processus propose de nombreux contraintes et métrologie de la qualité afin d'évaluer la qualité des modèles et enfin le processus propose des recommandations pour l'amélioration de ces modèles. 4. Développement d'un prototype "BPM-Quality". Ce prototype met en oeuvre tous les objets mentionnés ci-dessus et propose un flux de travail permettant à ses utilisateurs d'évaluer et d'améliorer les PM. Nous avons mené une enquête visant à valider la sélection des contraintes de qualité à travers une première expérience et aussi réalisé une seconde expérience pour évaluer l'efficacité de notre approche globale et des améliorations proposées.

  .. Figure11: Business process modellingcontext .................................................................................................... Figure 12: Independence of a given BP modelling notation ................................................................................. Figure 13: Business Process model Meta-Model .................................................................................................. Figure 14: Mappings between different concepts having the same role: Process ................................................ Figure15: Mappings between concepts having the same role:Actor .................................................................. Figure 16: Connectors in different modeling languages(Gruhn et Laue 2010) ...................................................

Figure 17: Resources in different notations .......................................................................................................... Figure 22: Activity with two outgoing edges ......................................................................................................... Figure 20: Sequence flow crosses the process boundary .................................................................................... Figure 21: XOR Split Gateway ........................................................................................................................... Figure 22: Activity with two outgoing edges ....................................................................................................... Figure 23: Timer intermediate event ..................................................................................................................

Figure 18: Process with no start event Figure 19: Process with multiple start events .................................. Figure 24: Erroneous model ...............................................................................................................................

Figure 25:Mappings between Domain Ontology and Business Process Model .................................................

Figure 26: Ontology Meta-model ....................................................................................................................... Figure 27: The overall approach for quality evaluation and improvement .

....................................................... Figure

28

: SPI Initiatives distribution of the publications

(Unterkalmsteiner et al. 2012) ................................ Figure 29: Our improvement process ................................................................................................................. Figure 30: Improvements type ............................................................................................................................ Figure 31: Prototype Architecture ...................................................................................................................... Figure 32: Use Case Diagram: Define the Quality Concepts............................................................................. Figure 33: Use Case Diagram: Evaluate the Quality .........................................................................................

Table 11 :

 11 Relationships alignment ......................................................................................................................

Table 12 :

 12 Syntactic quality metrics .....................................................................................................................

Table 13 :

 13 Pragmatic quality metrics ...................................................................................................................

Table 14 :

 14 Label classes .......................................................................................................................................

Table 15 :

 15 Time conjunction ................................................................................................................................

Table 16 :

 16 Comparing BPM-Quality with existing evaluation approaches .........................................................

Table 17: Categorization of the defects .

............................................................................................................. Table 18: Tools comparison ...............................................................................................................................

. Table 19: Respondents information with respect to their occupation ................................................................. Table 20: Extract from the computed Metrics for

Table 3 : Dimensions of BP quality

 3

Table 6 :FMESP set of metrics (Aguilar et al. 2006)

 6 LBC = 1 if we have a single activity, since it only generates one entry in the process log. LBC = ∏LBC if we have an ordered series of tasks, with one task starting after a previous task has

	On the other hand, the authors in (Cardoso 2007) began with the hypothesis that high complexity in
	workflows may result in poor understandability, errors, defects, and exceptions leading processes to
	need more time to develop, test, and maintain. Therefore, they describe a quality metric to analyze the
	complexity of workflow patterns from a log-based perspective. They define log-based complexity
	metric as follows:

been completed LBC = ∑pi * LBC if we have an exclusive choice and deferred choice where pi is the probability of following a specific path at runtime.

Table 7 : Possible experimental studies (Soffer, Kaner, et Wand 2012)

 7

Table 8 : Quality approach comparison

 8

	quality? 5) What quality does it evaluate? 6) What notation can be applied? 7) Does the research
	accomplish the work by implementing a tool?
	Approach	Model	Quality	Metrics	Improvement	Quality type	Notation Tool
		caregory	criteria	definition	Procedure
	(Jan	BPM	yes	no	Yes	Syntactic and	EPC	no
	Mendling,					pragmatic
	Reijers, et
	van der Aalst
	2008)
	(Becker,	BPM	yes		yes	Syntactic and	EPC and	no
	Rosemann, et					semantic	Petri nets
	Uthmann
	2000a)
	(Heravizadeh,	BPM	yes	yes	no	Semantic and	EPC	no
	Mendling, et					pragmatic
	Rosemann)
	(Heinrich et	BPM	yes	yes	no	Semantic and	-	no
	Paech 2010)					pragmatic
	(H.A. Reijers	BPM	yes	no	no	Pragmatic	-	no
	et Liman
	Mansar 2005)
	(Eick 1991)	Conceptual	yes	yes	yes	Syntactic, semantic	UML	yes
		models				and pragmatic
	(Jan	BPM	yes	yes	no	Pragmatic	EPC	no
	Mendling et
	Strembeck
	2008)
	(Dijkman,	BPM	no	yes	no	Syntactic, semantic	BPMN	yes
	Dumas, et
	Ouyang
	2008)
	(Vanhatalo,	BPM	no	yes	no	Syntactic	Petri net yes
	Völzer, et
	Leymann
	2013)
	(Wolf 2007)	BPM	no	yes	yes	Syntactic	Petri net yes
	(Verbeek,	BPM	no	yes	no	Syntactic	Petri net yes
	Basten, et
	Aalst 1999)
	(Dongen et	BPM	no	yes	yes	Syntactic	Petri net no
	Mendling

Table 10 : Concept alignment BP model meta-model connectors Domain Ontology meta-model relations

 10

	Sequence Flow

Table 11 : Relationships alignment

 11

•

  Else no defect detected.

	Integer	Split_gateway_outgo	This metric detects bad Split	• If Split_gateway_outgoing_edges_nb
		ing_edges_nb	gateway emplacement.	<2 or
			If the number of outgoing edges	Split_gateway_outgoing_edges_nb
			is less than two, a bad	=0, a bad emplacement gateway
			emplacement gateway defect is	defect is detected.
			detected.	• If Split_gateway_outgoing_edges_nb
				>=2, no defect detected.
	Integer	Split_gateway_inco	This metric detects bad Split	• If
		ming_edges_nb	gateway emplacement.	Split_gateway_incoming_edges_nb>1
			If the number of incoming edges	or Split_gateway_incoming_edges_nb
			is higher than one, a bad	=0 , a bad emplacement gateway
			emplacement gateway defect is	defect is detected.
			detected.	• If Split_ gateway_incoming _nb =1,
				no defect detected.
	Integer	Join_gateway_outgo	This metric detects bad Join	• If Join_gateway_outgoing_edges_nb
		ing_edges_nb	gateway emplacement.	>1 or
			If the number of outgoing edges	Join_gateway_outgoing_edges_nb =0
			is higher than one, a bad	a bad emplacement gateway defect is
			emplacement gateway defect is	detected.
			detected.	• If Split_gateway_outgoing_edges_nb
				=1, no defect detected.
	Integer	Join_gateway_incom	This metric detects bad Join	• If Join_gateway_incoming_edges_nb
		ing_edges_nb	gateway emplacement.	<2 or
			If the number of incoming edges	Join_gateway_incoming_edges_nb =0
			is less than two, a bad	, a bad emplacement gateway defect
			emplacement gateway defect is	is detected.
			detected.	• If Split_gateway_incoming_edges_nb
				>=2, no defect detected.
	Boolean	X(OR)_outgoing_ed	This metric detects Unlabeled
		ges_label	outgoing edges.

Table 13 : Pragmatic quality metrics

 13

Table 14 : Label classes

 14

	The first algorithm aims to categorize the labels.
	i.	Name: Label_categorization
		Input: Activity label
		Output: Label Style
		Description:

Table 15 : Time conjunction

 15

	iv.	Name: Extract_Actor
		Input: Activity label categorized as Subject-verb-object or Object-verb-by-Subject
		Output: Actor
		Description:

  iv) If an activity label does not contain a verb, then it does not present any action. The role of the

	activity is ambiguous.
	v) If a resource label contains a verb, it does not present information, nor an abstract idea nor an
	actor. The role of the resource is ambiguous.
	vi) If an activity has no name.
	vii) If there is a redundancy of concepts
	To check if this pattern is relevant for the current situation:
	a) Calculate the clarity metric of the concept.
	b) Calculate the generality metric of the concept.
	c) Calculate the specification metric of the concept.
	d) Check if the Activity_label constraint is valid.
	e) Check if the Resource_label constraint is valid.
	f) Check if the lack_Activity_label constraint is valid.

  Activity from the hyponyms, hypernyms or keywords provided by the ontologyThe model completeness is related to the complete representation of requirements and the presence of the functional concepts in the model. Such as very general activities that mask a lot of details, activities with no resources consumed or produced, activities with no actor, missing gateways name, or missing gateways outgoing edges names, missing start event, missing end event.

	ii.	Add Start event
	iii.	Add End event
	iv.	Add Resource
	v.	Add Actor
	vi.	Rename a gateway
	vii.	Rename an edge.

  Indeed, the current version of the prototype is interoperable with several BP modelling tools such as Bizagi, ARIS or Star UML. These tools use different modelling notations: BPMN for Bizagi, EPC for ARIS, Eriksson and Penker's notation for StarUML etc. And they provide export utilities based on XML or XPDL. Moreover, the several BP modelling tools use different notations. To solve this problem, we have developed an annotation module able to deal with several export languages by

As our tool aims to support quality evaluation of BP models modelled by different notations and produced by different tools, we aim to reach notation independency. The interoperability model allows supporting quality evaluation of BP models produced by commercial or free BP modelling tools.

Table 16 : Comparing BPM-Quality with existing evaluation approaches

 16 Woflan provides a workflow evaluation to detect deadlocks and lack of synchronization but it does not evaluate the semantics nor the pragmatic quality of the EPC model. Méga evaluates the BPMN model structure and checks the BPMN standard violation, also it do not evaluate the semantic nor the pragmatic quality of the model. Similarly to Mega, Logizian checks the structure of the BPMN model. It does not evaluate the semantic nor the pragmatic quality of the model.ii.Only Visual paradigm and Méga provide improvement guidelines. But their guidelines are restricted to the BPMN standards and they do not cover all the notation defects. In contrast to

	Following findings can be deduced from (Table 16):
	i.	Only "BPM-Quality" (our prototype) provides syntactic, semantic and pragmatic evaluation
		metrics.

"BPM-Quality" which covers a big number of quality defects and provide different types of improvements ( textual guidelines, preventive actions and corrective actions).

Table 17 :

 17 Categorization of the defects(Table17) sum up the defects with respect to the number of models where the defect has been detected. Based on these results, we aim to analyze the causes of the most common process modelling defects.

	Misplaced Activity		Each activity should reach the end	21
				event.
	Waste Activity		Each activity should have at least	2
				two relationships.
	Improper use of flow	A connector that does not reach the	0
	elements			extremes has no role.
	Start	event	bad	There	shouldn't	exist	any	0
	emplacement		predecessor for a start event.
	End	event	bad	There	shouldn't	exist	any	0
	emplacement		successor for a start event.

Table 22 : Metrics average calculation

 22

	Quality	Metric	Original Model Post transformation
	Attribute			models
	Ambiguity	Clarity	0.32	0.66
	Abstraction	Specification	0.6	0.64
	level	Generality	0.31	0.71
	Incompleteness	Input completeness Actor allocation completeness	0.01 0.05	0.07 0.1
		Model richness	0.17	0.215

From (Table

La similitude partielle base sur le nom.

Synonymie: renvoie les concepts d'ontologie qui sont des synonymes du concept de processus métier. La synonymie est calcule en se basant sur des distances de Wordnet : Resnik information content[START_REF] Resnik | Using information content to evaluate semantic similarity in a taxonomy[END_REF],[START_REF] Jiang | Semantic Similarity Based on Corpus Statistics and Lexical Taxonomy[END_REF], Lin[START_REF] Lin | An Information-Theoretic Definition of Similarity[END_REF],Wu and Palmer

Process.allInstances()->forAll(p| p.Responsible ->notEmpty())

Acknowledgements

clean the concepts label from conjunctions as "and", " for", "the" and from the undesired characters as "_", "-", ..etc.

Partially-Name-Similarity( BPM concept bpm) : Ontology-Concept[ ] { int bpm = number of words that compose bpm;

For all the ontology concepts do int lo = number of words that compose o; for (int i=0; i< lbpm; i++) for (int j=0; i< lo; j++) Calculate LevenshteinDistance ( bpm[i], o [j]); if(LevenshteinDistance=0) return o [i] endif enddo }

3) Synonymy: returns a set of ontology concepts that are synonyms of the BP model concept in input.

The synonymy concepts are calculated via two ways. The first method relies on two steps:

• Let o be the ontology concept mapped to the BPM concept bp by the name based similarity function or partially name similarity function.

• Return all the synonyms of o

The second method aims to calculate the ontology concepts that are synonyms of bp.

The synonymy value is calculated by comparing the existence of common names or synonyms based on Wordnet [START_REF] Fellbaum | WordNet: An Electronic Lexical Database[END_REF]) and several algorithms extracted from the literature: Resnik information content [START_REF] Resnik | Using information content to evaluate semantic similarity in a taxonomy[END_REF], Wu and palmer path length [START_REF] Wu | Verbs semantics and lexical selection[END_REF], Purandare

and Pedersen context vectors (Purandare et Pedersen 2004).

a) Synonymy calculated by Resnik information content [START_REF] Resnik | Using information content to evaluate semantic similarity in a taxonomy[END_REF]):

• It is established on the following hypothesis: the more information two concepts share in common, the more similar they are.

The information content of a concept (term or word) is the probability of finding the concept in a given corpus: p(c) is the probability of encountering such concept c. The probability p of a concept c is ranged between 0 and 1. If C1 is related to C2 by an " IS-A" relation i.e. if C1 IS-A C2 then p(c1) is less than p(c2).

• By using the standard argumentation of information theory by [START_REF] Ross | A First Course in Probability par Sheldon Ross[END_REF], information content of a concept is defined as the negative log likelihood, -logp(c).

• As probability increases, informativeness decreases, so the more abstract a concept is, the lower its information content.

• This quantitative characterization of information provides a new way to measure semantic similarity. The more information two concepts share in common, the more similar they are, and the information shared by two concepts is indicated by the information content of the concepts that subsume them in the taxonomy.

IC(c) = sim( C1, C2) = max [-log p(c) ]

Activity labels categorized as Subject-verb-object or Object-verb-by-Subject may contain information about actor.

• If the label is categorized as Subject-verb-Object, the algorithm will return the first word.

• If the label is categorized as Object-verb-by-Subject, the algorithm will return the word that succeeds the preposition "by". In fact "by" is an English preposition that is used to indicate the person that does something in a passive voice sentence.

Quality improvement categorization

We have identified several types of improvement techniques. These improvements can be in the form of any of the following types: textual guidelines, corrective actions and preventive actions (Figure 31). Moreover, a textual guideline can be a recommendation or a corrective action:

• A recommendation is a corrective advice, a suggested improvement action: it consists in suggesting to the analyst a solution to improve the quality of his/her models.

• A corrective request is an obligation. It consists in obliging the analyst to perform the solution.

Name: Split_AND_gateway constraint corrective guideline. Description:

The output edges number is less than two. Or the input edges number is higher than one. In both cases, the gateway doesn't serve a purpose.

Name:

Unlabeled_XOR_Split_gateway constraint corrective guideline. Description:

The XOR_Split gateway has no label. It is not clear which path will be triggered. It is recommended to rename the XOR split gateway Name:

Unlabeled_Split_OR_gateway constraint corrective guideline. Description:

The gateway has no name. It is not clear which path the process triggers.

Name: Join_OR_gateway_edges_nb constraint corrective guideline. Description:

The input edges number is less than two. Or the output edges number is higher than one. In both cases, the gateway doesn't serve its purpose.

Name:

Split_OR_gateway_edges_nb constraint corrective guideline. Description:

The output edges number is less than two. Or the input edges number is higher than one. In both cases, the gateway doesn't serve its purpose.

Name:

Join_XOR_gateway_edges_nb constraint corrective guideline. Description:

The input edges number is less than two. Or the output edges number is higher than one. In both cases, the gateway doesn't serve its purpose.

Name:

Split_XOR_gateway_edges_nb constraint corrective guideline. Description:

The input edges number is less than two. Or the output edges number is higher than one. In both cases, the gateway doesn't serve its purpose.

Name:

Unlabeled_outgoing_Edge constraint corrective guideline. Description:

The edge "Edge_ID" has no name. The edge name after a XOR/OR Split gateway represents the condition that should be approved to initiate the next activity. It is recommended to rename the edge in order to define the condition that initiates each path.

Name:

Activity_synchronization constraint corrective guideline. Description:

The Activity "Activity_name" has two outgoing connectors. It is recommended to create an AND Split gateway.

Name:

Activity_Bad_Emplacement constraint corrective guideline. Description:

The Activity "Activity_name" is detected on the lane's boundary. It should be assigned to one lane.

Name:

Resource constraint corrective guideline. Description:

The Resource "Resource_name" is connected to "Gateway_name". Nevertheless, a gateway does not receive nor send messages.

We should note that all the behavioural constraints are assigned with textual guidelines that point out the error but all of them will recommend the modeller to replace one of the gateways.

Textual improvements for semantic constraints

Semantic constraints detect semantic defects. Hence textual guidelines can recommend ways to correct the defect but there are always many ways to correct a semantic defect. The modeller can change the way of thinking and thus change the concepts in the model.

Name:

Resource_connection constraint corrective guideline. Description:

The Resource "Resource_name" and the Resource "Resource_name" are connected. There is no communication between two resources.

Name:

Sequence_flow constraint corrective guideline. Description:

The sequence flow "Sf_ID" should not relate a resource to an activity. The sequence flow role is to represent the order of the activities in a process. It is recommended that you replace it with a message flow.

Name:

Message_flow constraint corrective guideline. Description:

The message flow "Mf_ID" should not relate two flow objects. The message flow role is to represent the exchange of messages. It is recommended that you replace it with a sequence flow.

Name:

Association constraint corrective guideline. Description:

The association "Af_ID" should not relate two flow objects. The association role is to relate artefacts with flow objects. It is recommended that you replace it with a sequence flow.

Name:

XOR_Split_Bad_emplacement corrective guideline. Description:

The activities that suceed the XOR_split "XOR_name" are not contradictory. It is recommended to replace the XOR_split with an OR_split.

Name:

OR_Split_Bad_emplacement corrective guideline. Description:

The activities that suceed the OR_split "OR_name" are contradictory. It is recommended to replace the OR_split with an XOR_split.

Name:

XOR_Split_edges_labels corrective guideline. Description:

The outgoing edges of the XOR_Split "XOR_name" do not present opposite conditions. It is recommended to rename the outgoing edges.

Name:

Actor_allocation constraint corrective guideline. Description:

The activity "A_name" is not associated to a actor. Each activity should have a resource responsible of its execution.

Name:

Input_Output_Resource_allocation constraint corrective guideline. Description:

The activity "A_name" do not have any input nor output resources. Each activity should have inputs and outputs. It is recommended to add resources to the activity.

Textual improvements for pragmatic constraints

Recommendations are also suggested in order to improve the pragmatic quality of the model.

Name:

Redundancy constraint corrective guideline.

Description:

The concept "concept_name" and the concept "concept_name" have the same names. It is recommended to rename one of them.

Name:

Activity_label corrective guideline. Description:

The Activity "Activity_name" does not respect an activity label structure. It is recommended to rename the activity.

Name:

Resource_label corrective guideline. Description:

The Resource "Resource_name" does not respect a resource label structure. It is recommended to rename the resource.

Corrective actions

Corrective actions are the actions that allow the user to add, rename, replace and remove concepts from the model. Each concept has its own method that respects the concept definition and constraints. A corrective action has a name, inputs and a description.

Add actions

We can add different types of BP model concepts: an activity, an abstract/ information/actor, a connector, a start/end/intermediate event, a gateway or an edge for a gateway.

i.

Name: Add_ Activity Inputs: Activity, Predecessor, Successor.

Description:

To add an activity "a" in the BP model, we should mention its successor and predecessor.

Depending on the type of each of them, a different type of connector is used.

-If the predecessor is a flow object then a sequence flow will connect the flow object to the activity.

-If the predecessor is a of type resource then a message flow will connect the resource to the activity.

-If the successor is a flow object then a sequence flow will connect the activity to the flow object.

-If the successor is a resource then a message flow will connect the activity to the resource.

As a result, when we want to add a new activity we should mention its successor and predecessor.

ii.

Name: Add_Resource

Inputs: Resource, Predecessor, Successor.

Description:

Similarly to add a resource, we should mention its successor and its predecessor. However, based on the IS domain knowledge constraints, a resource can not be related to an other resource. Thus

The mapping rules are defined as Java functions which take one parameter: the tag's type and create a XML comment as shown in Fig. 3.

Domain knowledge based quality management module

This module represents the core of the tool. It contains two submodules.

• Knowledge Management Module  Application domain knowledge management: relies on the domain ontology.

 IS knowledge management: relies on the knowledge provided by the notations and the methods.

• Quality Management Module  Quality Metrics  Quality Improvement guidelines

Metric management

The Metric management subsubmodule in "BPM-Quality" is responsible for quality metrics definition and the execution of these metrics.

• The quality metric definition utility includes a rich set of predefined quality metrics with their definitions. It also offers to the quality expert the possibility to add new metrics as Java functions and document them with definitions.

Double Clarity (Concept a)

{ return 1./ a.Synonyms.lenght(); }

• The metric execution utility is responsible of identifying the metric functions inputs and posts the calculation results to the modeller.

Guides management

Based on the obtained quality metrics values, improvements are proposed to the modeller. The Guide management subsubmodule is responsible for the quality improvement definition such as textual guidelines, corrective actions and preventive actions, the execution of these improvements and defining the relations between metrics, IS constraints and improvements.

• The quality improvement definition utility allows the quality expert to define new improvements and associate them with metrics and constraints. Improvements are proposed according to a given quality threshold of metrics or a constraint violation.

• The quality improvement execution utility is responsible of answering the "If" states of the Java function where it evaluates the results of the calculated metrics. If the metric value is lower/ higher than a specific value, then it proposes the associated improvement function.

Knowledge base

(Figure 41) illustrates the levels of BPM-Quality 's knowledge base. It is composed of three different abstraction levels. The highest level contains the Business Process and the ontology metamodels, BP-ontology mapping rules and annotation mappings rules. The intermediate level is dedicated to quality metrics, semantic notation constraints and improvement guidelines. Finally, the lowest level stores the results of the improvement sessions.

• The modeller can add resources. He/ She chooses a resource from the keywords lists and by clicking the "Add" button a new interface will be created to choose the successor and the predecessor of the resource.

• Finally the modeller can add a new actor by choosing one from the actors list. It will create a new actor but it's up to the modeller to replace manually the activity. And this disadvantage is due to the fact that the XML file does not provide the capability to attach an activity to a pool or a lane in BPMN. Thus if it is in EPC or Eriksson-Penker notation, the new actor will be added as any other resource by identifying the successor and the predecessor.

The same step is done for the actor evaluation. As the "BPM-Quality" tool provides the same interface but for the actors seized from the model. The modeller can always re-evaluate the transformed model. And by re-evaluating the modeller new synonyms, hypernyms, hyponyms and keywords will be provided as there are new concepts added to the model.

Comparison of BPM-quality with other existing software

In Chapter 2, we used (Table 16) to compare existing evaluation approaches. Now we will use the same criteria and some others to compare our prototype with respect to existing evaluation tools. ii. Some of the improvements suggested by the tool as the textual guidelines can not be applied automatically, the modeller should apply them on his model and re-evaluate it by the tool.

In the next chapter, we present the two validation experiments conducted for our approach. In the first experiment, we validated the selection of the IS notation constraints whereas in the second experiment, we validated the efficacy of our proposed quality approach including quality metrics, quality improvement patterns.

Chapter 6 Validation

The main objective of our validation is to evaluate the approach and show its value. We conducted two experiments to validate our proposed approach at different stages.

Thus, a first experiment was performed to ensure that the quality constraints defined in Section 3.2.3 in order to detect a big number of the important quality defects in the evaluation of Business process models. This interim validation exercise was performed on a collection of Business process models from BPM Academic initiative (« BPM Academic Initiative | Signavio » 2013). The main objectives behind this first validation were the following: i.

To ensure that these constraints detect a big number of the important quality defects.

ii.

To make sure that the concepts are well used in the model.

iii.

To study the percentage of the more common defects.

The results of the above experiment helped us in validating the selection of our quality constraints and in correcting the usage of the BPM concepts.

We performed the second experiment to validate the efficacy of our complete approach including domain ontology. We have carefully selected the respondents for the validation experiment such that all the respondents have prior knowledge about conceptual model and some modelling experience.

This experiment consisted that every respondent model the distributed scenario.

The main objectives behind this second validation were the following: i.

To make sure that the quality metrics identified are useful in evaluating the quality of the BPM ii.

To ensure that the knowledge provided by the domain ontology can provide improvements to the model.

iii.

To study the mostly used improvements.

The second experiment helped us in validating the strengths and benefits of employing our proposed approach in evaluating and improving the BP model. In both experiments, we have used multiple charts and tables to analyze the most spreading defects. We were mostly interested in how to detect and correct these defects. i. None of the models prevent the modeler to add resources (objects, messgae events..) into their models.

ii.

For the modeler, the objective of a business process model is to describe the order of execution of activities. They do not concentrate on the presence of resources.

The common causes of the message flow constraint are:

iii. Some of the modelling tools detect this defect but none of them explains the cause.

iv. None of the notations gives a detailed explanation of the message flow's semantics. Most of them define it as the messages exchange representation without specifying how it should be applied in a model.

The unlabeled Split XOR/OR gateway defect may be the result of various causes:

i. None of the modelling tools prevents the modeller that a Split-XOR/OR gateway should be labelled.

ii.

For the modeller, the type of gateway used is sufficient to present the idea. The Split-XOR gateway should represent the question that should be answered in order to know what is the valid condition that triggers the next activity.

Chapter 6: Validation

The lack of actor allocation is due to the fact that:

i. None of the modelling tools oblige the modeller to define the actors, they allow the modellers to begin their models without identifying the actors (lanes, actors...).

ii.

An interesting number of modellers define the actor in the activity label. (Figure 44) depicts the partition of syntactic defects. It can be seen that the majority of the syntactic defects belongs to the lost activity (67%) followed by misplaced activities (23%).

The lost activity defect may also be the result of various causes:

i. The modeller does not double check on his/her model after finishing it.

ii.

The modeller concentrates on the sequence of activities in a specific requirement rather than in the scenario as a whole.

On the other hand, based on the same causes, a misplaced activity is followed.

• Finally, none of the pragmatic defects were detected by the tools. "BPM-Quality" detects the redundant concepts and checks the structure of the concepts labels relying on Wordnet's tags.

Validating the proposed quality approach

In Chapter 3 we proposed quality approach based on domain ontology. However, the viability of our proposed quality approach can only be validated through an experiment. Thus, we used medical domain ontology and an hospitalization process scenario in order to apply the experience. This experiment consists of the following steps:

i.

In the first step, respondents who have a minimum base knowledge about conceptual models were given the scenario that was followed to create the business process model. Respondents were required to analyze the scenario, to identify the tasks and to create a business process model in any language they prefer.

ii.

In the second step, each of these models was evaluated by the IS constraints. Quality improvement suggestions were provided to each defect detected.

iii.

In the third step, using our quality approach tool, type based mappings and semantic based mappings were calculated between the domain ontology and each of these models in order to provide the knowledge needed for not only evaluating the semantic quality of the models but also providing quality improvement.

iv.

In the fourth step, each of the transformed models is re-evaluated by the quality metrics in order to compare it to the original model.

In short, this experiment consists in evaluating and improving each of the models to finally compare them and prove the efficiency of our approach.

Samples

This experiment was given to different students in Conservatoire national des arts et métiers (CNAM) who have prior knowledge and experience about CM. Eight respondents submitted the business process model. We studied the feedback of each of the respondents with five questions.

1. Occupation: Respondents were required to select their occupation from a list of three pre-defined occupations: PhD student, Master student, Professional.

2. How many Conceptual model courses have they taken? We classify them into four classes:

• If they took zero courses: None domain knowledge.

• If they took one course: Average domain knowledge.

• If they took two courses: Good domain knowledge.

• If they took more than two courses: Very good domain knowledge.

domain.

Table 19: Respondents information with respect to their occupation (Table 19) provides the respondent's profile with basic information. It can be seen that our respondents have a prior knowledge and experience about conceptual models. All the respondents have taken at least one course in conceptual models. Only one respondent has good experience in business processes, which explains the familiar notation choice: BPMN. In spite of this, the respondents are very familiar with the scenario's domain and they have good experience in activity diagram's modelling.

In Section 4.1 we proposed quality metrics to evaluate BP models and, in Section 4.4, we defined improvement actions so that they can be associated with the metrics values. However, the viability of our proposed quality metrics and improvements can only be validated through an experiment. This experiment consists of the following five steps:

i.

In the first step, respondents were given a scenario to create a Business process model. As the respondents are not familiar with a specific notation, they were asked to use any notation they prefer.

ii.

In the second step, the models were annotated with the "BPM-Quality" annotation module.

This module annotates the models so they can be mapped to the domain ontology concepts.

iii.

In the third step, IS constraints were applied on each of the models. The defects detected by these constraints are posted to the modeller with improvements that includes textual guidelines. Thus the IS constraints help in identifying the problem but the modeller must rely on the improvements provided for the solution.

iv.

In the forth step, the quality metrics are calculated with respect to each of the concepts selected by the modeller.

v.

In the fifth step, respondents were provided the list of the improvements including textual guidelines and improvement actions in order to improve their models.

Evaluation process

After insuring that the type based mappings are correctly done, the semantic based mappings are executed. And the models are evaluated using the quality metrics identified in Section 4.2.

Based on the metrics calculation results, improvements are proposed to the modeller. In the example shown in Module-4 (Appendix B), we will analyze each of the metrics results and the improvements proposed.

The list of activities in the model are seized by the tool and evaluated by the quality metrics. We will present an extract of the results. (Table 21) sums up the most common improvements used in this experience. However, it is interesting to note that the improvements are related to the type of defects detected.

• Resources were added to the eight models due to the lack of resources detected by the Input completeness metric and due to the knowledge provided by the ontology.

• Activities were renamed due to the undesirable clarity, specification and generality metrics values and due to the different abstraction levels of the same activity provided by the ontology.

• Message flow replaced by an other type of connector. It means that there are twenty seven incorrect uses of the message flow detected by the Message flow constraint.

• Moreover, eighteen unlabeled edges were detected. Thus they renamed outgoing edges.

Chapter 7 Conclusion

It has now been widely agreed that the effectiveness, consistency and transparency of the companies' business operations depends on the quality of the Business Process models. Therefore, a good analysis and evaluation method should ensure that BPM quality. Hence if the Business process models are scanned for defects and then corrected, it is likely to reduce the number of change requests for the end system. Moreover, these errors and deficiencies in the BPMs will not be propagated along the development process.

Research on BPM quality evaluation is rather young and lackes any known standards. However, approaches in the literature concentrate on providing advices and best practices to ensure mainly the syntactic quality of models i.e. the structure of the model. Therefore, an effort on semantic and pragmatic quality definitions needs to be provided. Often the modellers are left with a proposed set of evaluation metrics that can be used for evaluation without helping in improving the models.

In spite of the wide acceptance of the benefits of process awareness, the improvement of Business

Processes is still vague and incomplete. Literature review shows that little or no theoretical guidance is provided to modellers and analysts on how to improve the models.

Another major hurdle in evaluating the quality of Business process models is the lack of tools automating the evaluation process and proposing corrective actions for improvements.

Contributions

The research presented in this thesis is a step forward in semantics based quality evaluation and improvement using domain knowledge. In order to formulate a complete solution, we extracted knowledge from the notations semantics and from domain ontology. The approach takes into account the variety of business process model notations by using a meta-model. The domain ontology is represented by the means of ontologies where semantics is enriched by using several kinds of relationships among the concepts. One advantage of our approach is that it is not domain-specific or notation specific. The alignment process can be applied to each domain for which such ontology is available. It may highly facilitate the task of BP modellers and lead to a significant improvement of BP models. The other advantage is that it encourages capitalization of expertise. Indeed, in many fields, there is an effort of definition of structured and shared knowledge in several areas: medical practices, HR processes, e-learning etc. The proposed approach is an actual usage of such knowledge.

Appendix A Mappings between the ontology concepts and the BP model concepts

Mappings between the ontology concepts and the BP model concepts:

These mappings use:

• Wordnet data base: Protected static final String WORDNET_DATABASE_DIR_PROPERTY "wordnet.database.dir"; System.setProperty(WORDNET_DATABASE_DIR_PROPERTY,(newFile("resources/dict/")).getAb solutePath());

• Wordnet functions: JWS jw= new JWS("C:/Users/sarah/Desktop/Wordnet plugin","wordnet similarity"); sResnik r = jw.getResnik(); sTreeMap<String, Double> p = jw.getPath().path("doctor", "entity", "n"); sLin l = jw.getLin(); WuAndPalmer w = jw.getWuAndPalmer();

Name based similarity: Take a business process model concept "a" and return all the ontology concepts that are syntactically equivalent to "a". It exploits all the ontology concepts and calculate the LevenshteinDistance distance. Partially_Based_Similarity: Take a business process model concept "a" and return all the ontology concepts that are partially equivalent to "a", that is at least a word in common. It exploits all the ontology concepts and calculate the LevenshteinDistance distance between each word in both concepts. • lin similarity takes a BP model concept "a" , it calculates the Lin distance between "a" and each of the ontology concepts. (BPMReader.ConceptList.get(kk). ID.compareTo(BPMReader.Resource_input_List.get(i) ((OntoReader.listeofterms.get(i).type.compareTo("#abstract")==0) || (OntoReader.listeofterms.get(i).type.compareTo("#artefact")==0) || (OntoReader.listeofterms.get(i).type.compareTo("#knowledge")==0)) nb_onto_artefacts++; if(nb_onto_artefacts==0) rr =0.0; else rr = nb_BPM_resources/nb_onto_artefacts; return rr; }

BPM-Quality interfaces:

The first "BPM-Quality" interface is to load the BP model adress and the domain ontology adress. The first textArea will post the name of each constraint checked. The second textArea will post the results of the constraints checked.

The third interface is the activity evaluation and improvement interface. It loads the BP model activites, evaluate them and suggest improvements.

• List of activities comboBox will load all the BP model activities.

• Synonyms comboBox post all the chosen activity synonyms.

• Hyponyms comboBox post all the chosen activity hyponyms.

• Hypernyms comboBox post all the chosen activity hypernyms.

• Keywords comboBox post all the concepts (except people resources) related to the actions mapped to the chosen activity. • People Resource comboBox post the people resources related to the actors mapped to the chosen activity.

Figure 54; Activity evaluation and improvement interface

The improvements proposed by the interface are automatically applied by the tool. • Add a new activity wich will create a new interface to seize the sucessor and the decessor of the new activity. • Rename an activity which will apply the Rename function and take the selected activity from the list of activities and the new one selected from any of the comboBox lists. • Replace an activity which will apply the Replace function and take the selected activity from the list of activities and the new one selected from any of the comboBox lists.

• Remove an activity.

The fourth interface is the people resource evaluation and improvement interface. It loads the BP model people resources, evaluate them and suggest improvements.

• List of people resources comboBox will load all the BP model people resources.

• Synonyms comboBox post all the chosen people resource synonyms.

• Hyponyms comboBox post all the chosen people resource hyponyms.

• Hypernyms comboBox post all the chosen people resource hypernyms.

• Keywords comboBox post all the concepts (except people resources) related to the actors mapped to the chosen people resource. • Responsable comboBox post the activities related to the actions mapped to the chosen people resource. • Complete People Resources botton will display a new interface that contains new people resources not posted in the combo-Boxes. It will allow the modeler to complete his model with new actors.

Figure 55: People Resource evaluation and improvement interface

The improvements proposed by the interface are automatically applied by the tool.

• Add a new people resource.

• Rename a people resource which will apply the Rename function and take the selected people resource from the list of people resources and the new one selected from any of the comboBox lists. • Replace a people resource which will apply the Replace function and take the selected people resource from the list of people resources and the new one selected from any of the comboBox lists. • Remove a people resource.

Appendix B The validation Scenario:

The purpose of this document is to describe the different steps covered in a hospitalization process.

Pre-admission Process

A patient arrives to the hospital, he reports to the reception of the hospital. The secretary, enquires about her/his problem by interviewing her/him. The interview is conducted for the purpose of obtaining information regarding the patient situation and complete her/his medical record. If it's a new patient, he must complete a registration form at the first visit ,which becomes part of the patient's permanent medical record. Meanwhile the secretery create his medical record. Patient information is obtained by the hospital through the use of a patient registration form. The form generally contains fields for information regarding the patient (Demographic information ), insurance carrier (information regarding the insurance carrier or government program underwhich the patient has coverage), guarantor, diagnosis, and physician (Information regarding the patient's condition and thereferring or admitting physician). The patient registration form is completed by the patient and reviewed by the admission representative. The registration process consists of creating a patient account on the hospital's computer system and entering patient information obtained during the patient interview. The patient's account is the computerized record by which the patient information is recorded and maintained. An account and medical record number are assigned to each patient by the system. In fact, the patient's medical record is a folder where the patient's information is stored, including demographic, insurance, financial, and medical information.

Hospitalization Process

The secretary refers the patient to the concerned department/doctor. He is assigned a room and/or a bed as semi private rooms have two beds in each room, therefore the patient would be assigned a room and a bed. Room assignment is also performed in outpatient areas such as Ambulatory Surgery, the Emergency Department, or Observation. The concerned doctor investigates the patient's case history. If requires, patient is advised for admission in the hospital. In case of admission, the patient is given the admission date and admission form for further formalities except for emergency cases. This will be recommended by the specialist during the patient's outpatient consultation. Meanwhile, the patient is counseled by the secretary regarding the treatment package which includes:estimated bill size, average length of stay, various modes of payment accepted, documents to bring on day of admission. Further, when the patient arrives at the ward, the hospital ward staff will orientate the patient to the ward and to his room. Patient will be clerked by the doctor, this involves: -asking for symptoms -taking a detailed medical history -ordering of tests if necessary Based on the symptoms reported by the Patient, laboratory tests are demanded, such as blood tests, X-ray procedures... Results are collected by the nurse and notified to the doctor. Progress notes outline the patient's status, results of diagnostic studies, and response to treatments. The doctor completes progress notes each time the patient is seen. The nurse records notes during each shift. She collect the monitoring results. Her progress notes indicates the patient status, response regarding his condition and vital signs such as blood presure, pulse, temperature. And finally, notify the results to the ward staff and observe the symptoms during all the patient stay. The doctor analyse the results of laboratory exams and classify the problem. According to the patient's presentation a course of antibiotics might be indicated and in some cases a surgical consult is necessary. Medications and other pharmaceuticals required during the patient stay are provided by the Pharmacy Department in accordance with the physician's orders.

Check out Process

Finally, before leaving the ward, patient is handed over with detailed discharge summary, which includes doctor's advice on their further follow-up treatment, daily routine diet, and medical prescription. The doctors may give the patient an appointment for follow-up. If the patient needs to reschedule the outpatient appointment after discharge, they can feel free to contact the concerned doctor.

Create a Business process model or an activity diagramme: -The actors are presented into Lanes in the business process models, or into Swimlanes if it's an activity diagramme.

-You can describe a specific case i.e. declare specific symptoms as hight temperature or diziness. Based on these symptomes a specific laboratory tests are demanded as blood test.

Models used in the 2nd experience:

Appendix C

The domain Ontology

AYAD Sarah

Business Process Models Quality: Evaluation and Improvement Résumé La problématique scientifique abordée correspond à la modélisation et à l'amélioration des processus métiers. Ce problème est d'un intérêt croissant pour les entreprises qui prennent conscience de l'impact indéniable que peuvent avoir une meilleure compréhension et une meilleure gestion des processus métiers (PM) sur l'efficacité, la cohérence et la transparence de leurs activités. Le travail envisagé dans le cadre de la thèse vise à proposer une méthode et un outil pour mesurer et améliorer la qualité des modèles de processus métier. L'originalité de l'approche est qu'elle vise non seulement la qualité syntaxique mais aussi la qualit2 sémantique et pragmatique en s'appuyant notamment sur les connaissances du domaine.

Mots cles : Modelisation des processus metier, qualite de model, qualite semantique, connaissance de domaine, ontologie de domaine, evaluation de la qualite, amelioration de la qualite.

Abstract :

Business process modelling has been receiving increasing attention from companies as well as the academic community, since it is likely to improve practice and working processes in organizations in the future. Indeed, to keep up and remain competitive, companies must be able to asses the quality of their products and the efficiency of their services. This requires understanding the current system and analyzing the potential benefits of the underlying processes. Using models helps reaching such an objective as they provide an abstract and coherent vision of the business and facilitates understanding and reasoning about alternative solutions to reach an agreement [START_REF] Nurcan | Intention-Driven Modeling for Flexible Workflow Applications[END_REF]. Business process models (BPM) can be realized through methodologies, techniques, or software, in a way that helps organizations bring together processes and their context including people, documents, information sources, organizational structures, and applications [START_REF] Van Herk | Activity Monitoring Buzz or Business[END_REF]. As a methodology, BPM help organizations in gaining control over their business processes by modelling, validating, analyzing, and monitoring the processes.