Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (15)
Semelhante a présentation PFE (2)
Semelhante a présentation PFE (2) (20)
présentation PFE (2)
- 1. Sujet: Définition d’un modèle hiérarchique de processus configurables et développement d’un outil de modélisation Réalisé par: Khouloud SAHLI Organisme : ISIMM Nom du responsable : M. Mohamed GRAEIT Encadré par : Dr. Sami BHIRI et Dr. Mohamed GRAEIT Supervisé par : Mme. Nesrine BEN YAHIA Université de la Manouba Ecole Nationale Des Sciences De l’Informatique ENSI 2014/2015
- 2. Plan
- 3. Plan
- 4. 4 Dans quel contexte les processus métiers ont apparus ? Un fort besoin à une indépendance entre la logique métier, l’organisation et la technologie. C’est quoi un processus métier ? 1- Les processus métiers: Contexte et définition Contexte: Les processus métiers (1/4) Un processus est un enchainement des activités qui vise à réaliser un but métier bien déterminé.
- 5. 5 Contexte: Les processus métiers (2/4 ) 2- Les processus métiers: Cycle de vie Modélisation Identification Validation Implémentation Journal d’exécution Amélioration de processus Importante !Importante !Importante !
- 6. 6 Contexte: Les processus métiers (3/ 4) 3- Les processus métiers : La phase de modélisation La modélisation à partir de zéro La réutilisation -Exhaustive - Dépend beaucoup de temps - Source d’erreurs - Gain du temps - Moindre ressources La variabilité Les variantes de processus : réalisent le même but métier dont la manière se diffère partiellement. Les modèles de processus configurables Problème de gaspillage d’espace lors de leur stockage Problème de cohérence : lors de mise à jour des éléments en commun Des éléments de processus en commun
- 7. 7 Contexte: Les modèles de processus configurables (4/4) Définition : Le résultat de regroupement de plusieurs variantes de processus. Ils sont conçus pour générer des variantes de processus suite à une configuration. Exemple :
- 8. Plan
- 9. 9 Problématiques Les limites des modèles actuels de processus configurables [L1] Au niveau de la granularité: Structure plate Ne permet pas d’opérer au niveau de fragment de processus. Ne permet pas la réutilisation des fragments de processus. [L2] Absence de l’aspect fonctionnel/ Capacité: Absence d’une description consistante sur la fonctionnalité d’une tache. [L3] Exigence d’une expertise/connaissance du langage de modélisation pour la configuration du modèle. [L4] La maintenance de ces modèles est exhaustive Problématiques et Solutions (1/2)
- 10. 10 Problématiques et Solutions (2/2) Partie1: Définition d’un modèle de processus configurable hiérarchique [S1] Permettant d’opérer au niveau d’une granularité plus fine. [S2] Intégrant la capacité [S3] Des opérations simples de configuration Partie2: Développer un système de modélisation et de configuration. Solutions:
- 11. Plan
- 12. 12 1- Le modèle de processus configurable hiérarchique Partie1 : Le modèle conceptuel (1/5) [S1] Au niveau de la granularité [S2] Intégration de la capacité [S3] Opérations de configuration isvariantof décrit si une tache/une capacité est variante à une autre
- 13. 13 Partie1 : Le modèle conceptuel (2/5) 2- Le modèle de composition 1- Le modèle de processus configurable hiérarchique Une tache configurable: est une tache ayant des taches variantes. 4 types de tache Atomique Atomique Configurable Composée Composée Configurable Exemple: Preparing Documents
- 14. 14 3- Le modèle de capacité Exemple : Export de marchandises Partie1 : Le modèle conceptuel (3/5) - Property Entries = {PE1,PE2,PE3} tels que: PE1 = (CategorieDeMarchandises, Vêtements) PE2 = (AdresseSource, Tunis) PE3 = (AdresseDestination, Paris) - ActionCategory = Export PE = (ActionCategory, Export) Export de marchandises= (ActionCategory, PropertyEntries)
- 15. 15 Exemple: Partie1 : Le modèle conceptuel (4/5) Action Category = Export PE1 = (Catégorie, vêtements) PE2 = (Source, Tunis) PE3 =(Destination, Paris )
- 16. 16 Partie 1 : Le processus d’individualisation(5/5) Le processus d’individualisation consiste à appliquer alternativement/ successivement les deux opérations de configuration. Les opérations de configuration getaVariantGetModel
- 17. Plan
- 18. Partie2: Le système de modélisation et de configuration Analyse et spécifications des besoins
- 19. 19 Partie 2 : Analyse et spécification des besoins (1/3) Créer un modèle de processus configurable hiérarchique Configurer un modèle de processus configurable hiérarchique Concepteur Expert métier Les besoins fonctionnels: Cas d’utilisation global
- 20. ENSI 2014/2015 20 Les besoins fonctionnels: Créer un modèle de processus configurable Partie 2 : Analyse et spécification des besoins(2/3)
- 21. ENSI 2014/2015 21 Les besoins fonctionnels: Configurer un modèle de processus configurable Partie 2 : Analyse et spécification des besoins(3/3)
- 22. Partie2: Le système de modélisation et de configuration Conception
- 23. 23 Partie2 : Conception du système de modélisation et de configuration (1/5 ) L’architecture physique de Signavio (2-tiers) L’architecture logique de Signavio (3 couches) Conception globale: l’architecture de Signavio
- 24. 24 Conception globale: l’architecture de notre système (extension de signavio) Partie2 : Conception du système de modélisation et de configuration (2/5 ) L’architecture physique 3 tiers Diagramme de composants (Architecture logique en 3 couches)
- 25. 25 Le diagramme de séquence: Créer un modèle de processus configurable Partie2 : Conception du système de modélisation et de configuration (3/5 ) Scenario de création d’un modèle de processus configurable hiérarchique
- 26. 26 Le diagramme de séquence: Sauvegarder un modèle de processus configurable Partie2 : Conception du système de modélisation et de configuration (4/5 )
- 27. 27 Le diagramme de séquence: Configurer un modèle de processus configurable Partie2 : Conception du système de modélisation et de configuration (5/5 ) Scenario de configuration d’un modèle de processus configurable
- 28. Partie2: Le système de modélisation et de configuration Réalisation
- 30. Partie2: Le système de modélisation et de configuration Démo
- 31. 31 Partie2 : Réalisation(2/6) Page d’accueil
- 32. 32 Partie2 : Réalisation(3/6 ) 1: Stencils ajoutés 2: Plugin de modélisation 3: Plugin de configuration 4: Ensemble de propriétés 6: Canvas de modélisation 5: Panel pour le résultat de la configuration Interface de modélisation et de configuration de processus hiérarchiques configurables
- 33. 30 Partie2 : Réalisation (4/6 ) Plugin de modélisation
- 34. 34 Partie2 : Réalisation (5/6 ) Interface de sauvegarde Répertoire de processus Sauvegarder un modèle de processus
- 35. 35 Partie2 : Réalisation (6/6) Plugin de configuration Interface de l’opération ‘Show Capability Hierarchy’
- 36. 36 Partie2: Exemple de test(1/ 3) Exemple des variantes de processus d’export de marchandises
- 37. 37 Partie2: Exemple de test(2/3 ) Le modèle de processus configurable hiérarchique bien étalé
- 38. 38 La configuration du modèle de processus configurable hiérarchique Partie2: Exemple de test(3/ 3)
- 39. Plan
- 40. 40 Conclusion et Perspectives Le projet, consiste à: Définir un modèle de processus configurable hiérarchique intégrant un ensemble de solutions pour les limites des modèles configurables actuels. Développer un système de modélisation et de configuration permettant de modéliser et de configurer des modèles de processus hiérarchiques configurables. Perspectives: Traiter le module de capacité. définir un algorithme pour automatiser la détection des points de variation dans le modèle. Ajouter un plugin permettant l’intégration des fragments de processus sauvegardés dans le répertoire.
- 41. Merci Pour Votre Attention ! ENSI 2014/2015 41
Notas do Editor
- Monsieur le président du jury, Mesdames et Messieurs les membres du jury, BONJOUR Nous allons vous présenter notre projet de fin d’études, intitulé « Définition d’un modèle hiérarchique de processus configurable et développement d’un outil de modélisation. Ainsi nous passons tout d’abord à détailler le plan de cette présentation. 555 928 228 820 09
- Nous commençons alors par mettre le projet dans son contexte.
- Notre travail s’articule autour des processus métiers. Ces derniers ont apparus suite à un fort besoin à une indépendance entre la logique métier, l’organisation qui la manipule et la technologie qui la met en œuvre. Ce besoin a été fournie par l’avènement de processus qui servent à décrire la logique métier séparément. En effet, un processus métier est un enchainement des activités qui visent ensemble à réaliser un but métier bien déterminé.
- Le cycle de vie des processus métiers est constitué de 4 phases: La première phase est la phase de modélisation, dite aussi phase de conception, dans cette phase, le concepteur crée le modèle de processus, identifie les acteurs en relation pour chaque tache, et assure la validité du modèle. La deuxième phase est la phase de configuration. Cette phase fait le lien entre le modèle et sa véritable implémentation. Elle consiste a concrétiser le processus logique en instanciant ses paramètres organisationnels et informationnels. Après nous passons à a phase d’exécution. Au cours de cette phase, les activités de processus se mettent en ouvre. Aussi lors de cette phase un nombre important de décisions de contrôle est pris par des acteurs humains : d’où la notion d’enactment. Une caractéristique trop importante de cette phase est le journal d’exécution qui va être utilisé comme support lors de la phase de diagnostic afin d’améliorer le modèle de processus en cours. Etant donné que la phase de modélisation constitue la première phase dans ce cycle de vie, La modélisations des processus métiers avec une haute qualité est une étape primordiale afin d'assurer le bon déroulement des phases en conséquence. Donc ,cette phase est la plus importante. Nous nous focalisons dans notre travail sur la modélisation des processus métiers
- Il existe deux alternatives possibles pour la modélisation de processus métiers. La première consiste à modéliser les processus ‘from scratch’ à partir de zéro: cette alternative est souvent chronophage: elle dépend beaucoup du temps, aussi elle est une technique exhaustive qui nécessite un travail fastidieux afin de créer le modèle de processus, et plus que ca elle représente une source d’erreurs. La deuxième alternative : est la réutilisation, en fait cette technique est en relation avec la notion de variabilité de processus. Elle consiste à réutiliser des variantes de processus afin de les modifier pour supporter les besoins de concepteur. Cette alternative évite la modélisation à partir de zero, d'ou un gain du temps et des ressources lors de la modélisation. En fait les variantes de processus sont des modéles de processus qui vise à réaliser le méme but métier différemment. Ces variantes de processus vont avoir des éléments de processus en commun c à d des taches en commun ou bien un ensemble de taches et don un fragment en commun. Si nous traitons chaque variante à part, ces éléments en commun vont causer un problème de gaspillage d’espace lors de leur stockage et vont provoquer un problème de cohérence lors de mise à jour de ces parties en commun. Ainsi un domaine de recherche actif est de plus en plus adresse a la modélisation de la variabilité dans les processus métiers afin de permettre un ajustement flexible selon diverses exigences. Une catégorie des approches actuels orientées réutilisation est connue sous le nom : les modèles de processus Configurables.
- Ces modèles sont le résultat de regroupement de plusieurs variantes de processus dans un seul modèle. Ainsi, ils prend en considération les communalistes entre ces variantes afin de le traiter une seule fois. En fait, ces modèles sont conçus afin d’être configuré pour générer des variantes de processus. Ainsi leur cycle de vie peut être vu comme suit: la phase de modélisation est décomposée en sous phase: la première consiste à la création de modèle configurable la deuxième est la phase de configuration qui permet de générer la variante cible. Pour expliquer cette technique, nous exposons un exemple simple: La figure a montre deux variante de processus qui ont en commun les taches a et b, et don un fragment en commun , mais ces deux variantes se différent au niveau de la dernière tache, d’où la variabilité. La figure (b) représente le modèle configurable qui regroupe ce 2 variantes. Le nœud avec une bordure en rouge est un operateur configurable. Lors de sa configuration il permet d’activer/desactiver soit la branche qui ramène à la tache c, soit celle à la tache D. Dans la figure c , cette configuration permet de générer la 1 er variante en activant la branche avec la tache C et donc elle permet de générer la 1er variante, nous parlons aussi d’individualisation du modèle.
- A quels niveaux ces approches présentent des problématiques ?
- Les problématiques se résident dans les limites des modèles actuels de processus configurables. En fait, ces modèles présentent des limites au niveau de leur granularité. Vu qu’il sont caractérisés par une structure plate, ils ne permettent pas d’agir au niveau d’une granularité plus fine. Et par conséquent, ils ne permettent pas d’agir au niveau des fragments de processus, et donc ils ne permettent pas la réutilisation des fragments de processus. La deuxième limite de ces modèles est l’absence d’une description consistante de la fonctionnalité des taches de processus et donc du processus tout entier. EN fait, ces modèles décrit la capacité d’une tache avec des labels, une telle représentation est incapable de donner une description consistante de la capacité des taches et donc du processus. La troisième limite est que ces modèles semblent complexes pour être manipules et configures par des experts métiers surtout que ces derniers ne sont pas censés d'avoir une expertise dans les techniques de modélisation utilisées. La quatrième limite est la maintenance. En fait, Malgré qu'elle offre un support aux experts métiers sous forme d'un questionnaire, l'approche de "La ROSA" nécessite des réunions et des discussions entre les experts métiers et les experts de modélisation pour maintenir ce support. Par conséquent, une modification (exp : ajout d'une variante) ou une mise a jour du modèle implique un travail exhaustif et des réunions a refaire et donc une perte flagrante du temps dans la maintenance .
- Les problématiques se résident dans les limites des modèles actuels de processus configurables. En fait, ces modèles présentent des limites au niveau de leur granularité. Vu qu’il sont caractérisés par une structure plate, ils ne permettent pas d’agir au niveau d’une granularité plus fine. Et par conséquent, ils ne permettent pas d’agir au niveau des fragments de processus, et donc ils ne permettent pas la réutilisation des fragments de processus. La deuxième limite de ces modèles est l’absence d’une description consistante de la fonctionnalité des taches de processus et donc du processus tout entier. EN fait, ces modèles décrit la capacité d’une tache avec des labels, une telle représentation est incapable de donner une description consistante de la capacité des taches et donc du processus. La troisième limite est que ces modèles semblent complexes pour être manipules et configures par des experts métiers surtout que ces derniers ne sont pas censés d'avoir une expertise dans les techniques de modélisation utilisées. La quatrième limite est la maintenance. En fait, Malgré qu'elle offre un support aux experts métiers sous forme d'un questionnaire, l'approche de "La ROSA" nécessite des réunions et des discussions entre les experts métiers et les experts de modélisation pour maintenir ce support. Par conséquent, une modification (exp : ajout d'une variante) ou une mise a jour du modèle implique un travail exhaustif et des réunions a refaire et donc une perte flagrante du temps dans la maintenance .
- Nous passons à la première partie de notre travail qui sert à définir un modèle de processus configurable hiérarchique.
- Nous détaillons dans ce diapo les différents composants de ce modèle. Le composant de base d’un modèle de processus est la tache. Ainsi nous distinguons entre une tache atomique et une tache composée. Une tache composée devrait obligatoirement avoir un modèle de composition. Ce modèle contient en fait un fragment de processus. les taches composées permettent d’assurer une structure hiérarchique dans le modèle et surtout elle permettent d’opérer au niveau d’une granularité plus fine et donc elle permettent d’opérer au niveau des fragments de processus. Cette observation représente une solution pour la première limite des modèles actuels. Aussi, pour chaque tache nous représentons sa capacité en tant que entité à part. Cette entité sera détaillée plus tard. Relire chaque tache à sa capacité permet d’intégrer l’aspect fonctionnel dans le modèle. Aussi la tache est susceptible d’être configurée en utilisant des opérations simples de configuration. Ces opérations seront détaillés plutard. Ces opérations sont plus simple à être compris par les experts métiers. La relation ‘isvariantof’ décrit la variabilité entre les taches. Si deux taches réalisent un même but métier mais avec des spécifications différentes nous parlons des taches variantes. Ainsi le lien ‘isvariantof’ décrit si une tache est variante à une autre.
- Par lasuite si une tache a des variantes nous parlons d’une tache configurable. Ainsi nous distinguons 4 types de tache: une tache atomique , atomique configurable; une tache composée, une tache composée configurable. Le modèle de composition sert principalement à décrire le flot de contrôle dans le modèle.
- Le modèle de capacité sert à décrire la capacité en se basant sur un ensemble de propriétés nommées PropertyEntry dans notre exemple. Pour chaque propriété est associé une PropertyValue qui décrit sa valeur et une PropertyDeclaration . Afin de mieux expliquer, nous citons un exemple décrivant la capacité d’envoi d’un courrier. Ainsi cette capacité est décrite avec les propertiés adresse source et adresse destination.
- Afin de mieux expliquer, nous expossons un exemple d’un modèle de processus configurable hiérarchique. Ce modèle est étalé sur 3 niveaux d’abstraction. Ces niveaux sont maintenus par les taches composée dans le modèle. Comme la tache export qui admet le modèle de composition constitué de 3 taches: Aussi la tache Export dec and reg est une tache composée ayant un modèle de composition contenant 2 taches. Ces taches composées et leur Model de composition forme la structure hiérarchique dans le modèle et donc une distinction entre ces différents fragments. Une telle structure permet d’opérer au niveau des fragments de processus et donc elle permet leur réutilisation. La tache Inspection est une tache configurble, ces varinates de configuration sont les taches simple Inspection et detailed Inspection.
- Nous passons maintenant à définir le processus d’individualisation de notre modèle. Le processus d’individualisation consiste à appliquer alternativement/ successivement les deux opérations de configuration suivantes: La première opération nommée ‘GetModel’ s'applique sur toute tache composée. Elle permet d‘étaler son modèle de composition pour l'intégrer dans le résultat de configuration pour être configuré à son tour. Nous appliquons cette opération sur la tache « Export Declaration and registration’ Ainsi son modèle de composition sera intégré dans le résultat de configuration. La deuxième opération « getvariant » permet de choisir une des variantes d’une tache configurable. Nous appliquons cette opération sur la tache « Inspection » dans ce cas nous choisissons la tache variante Simple Inspection pour être intégrée comme résultat de configuration.
- La deuxième partie de notre projet consiste à développer un système de modélisation et de configuration permettant de modéliser et de configurer un modèle de processus configurable hiérarchique. Dans cette partie nous spécifions les besoins de notre système, aussi nous traitons la partie conceptuelle et applicative.
- Nous commençons par l’analyse et la spécification des besoins.
- Les besoins fonctionnels de notre système seront décrites à l’aide des diagramme de cas d’utilisation. Pour notre système, nous distinguons deux acteurs principaux: les concepteurs et les experts métiers. Le concepteurs sont les experts de modélisation désirant créer un modèle de processus configurable hiérarchique. Les experts métiers sont ceux voulant Configurer un modèle de processus configurable hiérarchique.
- Nous passons à détailler le premier cas d’utilisation qui est la création d’un modèle de processus configurable. Ainsi afin de créer un modèle de processus, le concepteur devrait faire un drag&drop de différents composants du modèle y inclus ces taches. Ainsi, si la tache est une tache atomique configurable, il devrait référencier ces taches variantes. Si la tache est une tache composée, il devait référencier son modèle de composition, si la tache est composée configurable il devrait référencier son modèle de composition et ces taches variantes. Après la création du modèle, le concepteur peux l’enregistrer. Aussi il pourra utiliser les options de visualisation du modèle, tels que le déplacement, zoom IN/Out, Expand/Collapse.
- Les expert métier est celui doté de configurer le modèle. Afin de réaliser ce cas d’utilisation, il devrait ouvrir le modèle déjà crée dans l’editeur. Pour configurer le modèle l’expert devrait configurer quelques taches du modèle. Ainsi, si la tache à configurer est atomique configurable, il faut choisir une de ces variantes, cad appliquer l’opération de configuration getavariant. Sinon si la tache à configurer est Composée, il faut configure son modèle de composition , cad appliquer l’opération de configuration getModel. Sinon si la tache à configurer est Composée configurable, l’une des opérations de configuration getmodelou bien getavariant est possible.
- La conception est une étape importante dans le cycle de vie logiciel, dans cette partie nous allons détailler la partie conceptuelle de notre systéme.
- Notre système est en fait une extension, d’un outil de modélisation fortement recommandé pour supporter les nouvelles approches dans le domaine de processus métiers qui s’appelle signavio. Fortement caractérisé par son évolutivité, le système Signavio est susceptible d‘etre etendu avec une architecture 3-tiers: - Le tier clients: Il s'agit des ordinateurs demandeurs de ressources dotés des interfaces graphiques et préoccupée de la présentation (l'editeur de signavio dans notre cas). - Serveur : est celui qui fournit les ressources au client, comme réponse aux requêtes envoyées par l'editeur. Serveur de données : fournit au serveur d'application les données nécessaires pour répondre au client. Notre système est un système en 3 couches. La couche présentation : En fait, c'est l‘éditeur de Signavio. Cette couche assure la logique de navigation. Elle offre des interfaces graphiques assurant l'interaction avec le système. La couche métier : Cette couche reflète l'interaction avec la couche d'acces aux données pour accéder a la base de données et avec la couche de présentation pour retourner le résultat final des exécutions qui sera ensuite transmis a l'utilisateur. La couche d'acces aux données : Cette couche s'occupe de l'encapsulation des méthodes d'interaction avec le repertoire de processus et la base de données de capacités Cette couche donc permet la manipulation des fichiers qui servent a la gestion des processus et l'interaction avec la base de donnees.
- Pour la création du modèle le concepteur, devrait faire un drag&drop des composants de ce modèle. Ainsi si ce composant est une tache, il devrait
- Nous passons maintenant à aborder l’applicative de notre système via des interfaces homme-machine.
- Afin de créer un modele, l’urtilisateur devrait ouvrir l’interface permettant de créer un Modèle de processus hiérarchique configurable.
- Dans cette interface, un ensemble de stencils est offerts où nous avons ajoutés à la notation BPMN quelque éléments pour supporter notre modèle, tels que: une tache configurable, configurable atomique et un modèle de composition. Nous avons ajoutés aussi un plugin de modélisation pour fournir les opérations de modélisation. Nous avons ajoutés aussi un plugin de configuration pour fournir les opérations de configuration. Nous avons ajoutés un ensemble de attribut afin de maintenir le relations reliés à chaque tache, anisi pour les taches composé nous avons ajoutés l’attribut « hasCompositionModel’ pour referencier son modèle de composition. Pour tout le tache nous avons intégré l’attribut ‘hasCapablity’ pour referencier la capacité correspondante. Aussi nous avons ajoutés l’attribut « isvarianteof’ pour maintenir le lien ‘isvarianteof’ entre une variante et sa tache configurable. Nous avons ajoutés un panel dans lequel le résultat d’une configuration sera affiché.
- Le plugin de modélisation permet d’ajouter un modèle de composition à une tache composée en appliquant l’opération « addcompositionModel », suite à cette opération la valeur de l’attribut « hascompositionModel » sera remplit par l’id du modèle de composition ajouté. L’opération « addAvariant » permet d’ajouter une variante à une tache configurable. Et la troisième opération de modélisation « addcapability » permet de référencier la capacité de la tache, pour ce faire, une liste de capacité enregistrés dans la base de données sera affiché pour que l’utilisateur puisse choisir celle qui correspond à la tache sélectionnée. Après ce choix un référencement sur la capacité choisie sera établi à travers l’attribut hascapability.
- Pour enregirer le modèle, une interface sera affiché pour permettre à l’utilisateur de remplir les données reliées à son modèle tels que le titre, description et le commentaire. Après l’enregistrement du modèle deux fichiers xml seront crées dans le repertoire de processus. Un contenant la représentation xml du modèle et l’autre contient les propriétés de signavio tels que la représentation svg et json.
- Pour les opérations du configuration nous avons implémenté l’opération getmodel et getavariant et nous avons ajouté un cas spécifique de l’opération getavariant, en affichant la graphe du capacité, l’expert métier peux la visualiser afin de choisir une capacité, la tache ayant cette capacité sera la variante choisie.
- Un exemple de test a été introduit dans le rapport
- Cette interface montre la création de ce modèle de test,
- En suivant les différents étapes qui sont bien détaillées dans le rapport nous générons la deuxième variante de notre exemple de test;
- Finalement, nous cloturons avec une conclusion générale:
- Notre projet de fin d’études consiste à Définir un modèle de processus configurable hiérarchique intégrant un ensemble de solutions pour les limites des modèles configurables actuels, aussi il sert à Développer un système de modélisation et de configuration permettant de modéliser et de configurer des modèles de processus hiérarchiques configurables. Comme perspectives nous désirons traité les différents parties reliées à la capacité dans le modèle, aussi nous voulons définir un algorithme pour automatiser la détection des points de variation dans le modèle et par la suite la création du modèle. Pour le système, un plugin permettant l’intégration des fragments de processus sauvegardés dans le modèle represente un complément à notre travail.