Intégration d’un ERP guidée par les modèlescampus.hesge.ch/dugerdilp/_private/Rapport-isnet89.pdf · Intégration d’un ERP guidée par les modèles (Model Driven ERP Implementation)

Intégration d’un ERP guidée par

les modèles

(Model Driven ERP Implementation)

Projet ISNet 89

Octobre 2005

Contributeurs : • Gil Gaillard & Philippe Dugerdil (HEG)

o Partie théorique & implantation Adonix

• Yan Betriset (HEVs) o Etude d’implantation SAP

Rapport de fin de projet.

Haute école de gestion Informatique de gestion 7, rte de Drize CH-1227 Genève Suisse +41 22 388 17 00 www.hesge.ch/heg

http://www.hesge.ch/heg

2

Résumé De nos jours, les progiciels de gestion intégré ou ERP1 proposent une réponse efficace aux besoins standards de gestion informatisée des entreprises. Par rapport à un développement spécifique, un ERP propose l’implantation de processus métiers standards qu’il s’agit de configurer pour les besoins propres de l’entreprise. Il y a deux avantages principaux. Le premier est qu’une solution ERP est souvent de meilleure qualité que les logiciels développés spécifiquement. En effet, l’ERP ayant été installé chez de nombreux clients, les problèmes de jeunesse auront souvent disparu. Ensuite les processus métiers préconfigurés représentent un certain standard. Cependant, la configuration d’un ERP est une tâche délicate. Il s’agit en effet de savoir quels sont les processus préconfigurés proposés, comment ils sont organisés, avant de se lancer dans la configuration spécifique. Du point de vue technique, ces systèmes sont souvent très complexes et la maîtrise de leur architecture interne se révèle souvent difficile pour les informaticiens de l’entreprise cliente La mise en place d’une configuration d’ERP passe par la description des processus métier désirés par l’entreprise et l’analyse d’adéquation des processus standards de l’ERP vis-à-vis de ces besoins. Les processus sont en général décrits de manière graphique dans un standard de représentation. Ensuite vient la paramétrisation de ces processus sur l’ERP, tâche consistant à traduire une représentation de haut niveau en opérations techniques de bas niveau. Il s’agit bien entendu de s’assurer que le paramétrage suit fidèlement les processus métiers exprimés graphiquement. Aujourd’hui cette opération est majoritairement faite à la main. Cependant, une nouvelle approche dans le développement de logiciels préconisée par l’OMG2, connue sous le nom de MDA3, pourrait apporter une nouvelle dimension à l’étape de paramétrage des progiciels. En effet, l’approche MDA propose qu’à partir de la modélisation de haut niveau d’un système informatique, l’environnement prenne en charge la génération de l’implantation correspondante pour une plateforme spécifique. Le but de ce projet est d’étudier la possibilité de mettre en œuvre cette approche dans le cadre de la paramétrisation d’une ERP et de fournir un prototype en démontrant la faisabilité. Ce dernier a été développé dans l’environnement IBM/Rational® XDE® qui met à disposition des outils spécifiques de mise en oeuvre de MDA. Notre prototype a été validé sur la base de l’ERP Adonix X3 utilisé à la HEG pour l’enseignement de l’intégration de progiciels. Une tentative d’utilisation de notre outil pour SAP R/3 a également été menée. De multiples difficultés se sont présentées, aussi bien du coté des éditeurs sous forme de rétention d’information, que du coté techniques sous forme de bugs de l’environnement. Le rapport en fait également état.

1 Enterprise Resource Planning: un système d’information intégré qui supporte les processus standards d’une enterprise. 2 Object Management Group : communauté permettant le développement des standards des concepts orientés objet. 3 Model Driven Architecture : l’approche MDA permet, par le biais de modèles à différents niveaux d’abstraction, de séparer la problématique des contraintes techniques

Table des matières

3

1 MODÈLE THÉORIQUE.............................................................................................................. 7 1.1 INTRODUCTION ........................................................................................................................ 7 1.2 ETAT DE L’ART ........................................................................................................................ 8 1.3 MDA........................................................................................................................................ 9 1.4 MDA ET LA CONFIGURATION DES ERP................................................................................. 10 1.5 BUT DU PROJET ...................................................................................................................... 11 1.6 PRINCIPE DE L’APPROCHE...................................................................................................... 11 1.7 LES ÉTAPES DE L’APPROCHE.................................................................................................. 12

1.7.1 Metamodèle des ressources........................................................................................... 12 1.7.2 Métamodèle du CIM...................................................................................................... 12 1.7.3 Métamodèle du PIM ...................................................................................................... 13 1.7.4 Métamodèle du PSM ..................................................................................................... 13 1.7.5 Métamodèle des processus métier ................................................................................. 14 1.7.6 Métamodèle des activités............................................................................................... 14 1.7.7 Règles métier ................................................................................................................. 15 1.7.8 Profil UML .................................................................................................................... 15

1.7.8.1 Elements de modélisation.......................................................................................... 15 1.7.8.2 Règles de transformation du CIM en PIM................................................................. 17 1.7.8.3 Règles de transformation du PIM en PSM ................................................................ 18

1.8 IMPLÉMENTATION DU PROTOTYPE ........................................................................................ 20 1.8.1 MDA Toolkit .................................................................................................................. 21 1.8.2 Profils UML................................................................................................................... 22

1.8.2.1 Profil du CIM ............................................................................................................ 22 1.8.2.2 Profil du PIM............................................................................................................. 24 1.8.2.3 Profil du PSM............................................................................................................ 25

1.8.3 Transformations ............................................................................................................ 26 1.8.3.1 Remise à zéro ............................................................................................................ 26 1.8.3.2 CIM en PIM............................................................................................................... 26 1.8.3.3 Validation .................................................................................................................. 26 1.8.3.4 Transformation .......................................................................................................... 26 1.8.3.5 La vérification ........................................................................................................... 27

1.8.3.5.1 PIM en PSM........................................................................................................ 27 1.8.3.5.2 La validation ....................................................................................................... 27 1.8.3.5.3 La transformation................................................................................................ 27 1.8.3.5.4 La vérification ..................................................................................................... 28

2 ADONIX COMME PLATEFORME SPÉCIFIQUE ............................................................... 29 2.1 INTRODUCTION ...................................................................................................................... 29 2.2 SCÉNARIO .............................................................................................................................. 29 2.3 PROCESSUS DE COMMANDE................................................................................................... 31 2.4 SCÉNARIO DE SAISIE DE COMMANDE SOUS ADONIX ............................................................. 34 2.5 CONFIGURATION DES ÉCRANS ............................................................................................... 37 2.6 RECHERCHE D’INFORMATION................................................................................................ 38 2.7 FICHIER DE MAPPING ............................................................................................................. 39 2.8 VALIDATION DES ÉCRANS ..................................................................................................... 40 2.9 ETAPES DU PARAMÉTRAGE.................................................................................................... 40 2.10 EXEMPLE ............................................................................................................................... 40

3 SAP R/3 COMME PLATEFORME SPÉCIFIQUE................................................................. 47 3.1 INTRODUCTION ...................................................................................................................... 47

4

3.2 SCÉNARIO .............................................................................................................................. 48 3.3 PROCESSUS DE COMMANDE................................................................................................... 48 3.4 SCÉNARIO DE SAISIE DE COMMANDE SOUS SAP ................................................................... 49 3.5 CONFIGURATION DES ÉCRANS ............................................................................................... 51 3.6 RECHERCHE D’INFORMATION................................................................................................ 52

3.6.1 Architecture du système................................................................................................. 52 3.6.2 Recherche des tables de paramétrage d’écrans ............................................................ 53 3.6.3 Alternatives.................................................................................................................... 54

3.7 REMARQUES FINALES SUR NOTRE EXPÉRIMENTATION SAP.................................................. 55 4 CONCLUSION............................................................................................................................ 56 5 ANNEXES.................................................................................................................................... 58

5.1 MANIPULATIONS XDE .......................................................................................................... 58 5.1.1 Mise à jour des profils de notre projet dans XDE et plugin de transformation ............ 58

5.2 INSTALLATION ET GÉNÉRATION DE PLUGIN SOUS ECLIPSE.................................................... 59 6 RÉFÉRENCES ............................................................................................................................ 60

Table des figures

5

Figure 1 : Métamodèle des ressources................................................................................................... 12 Figure 2: Métamodèle des entités métier du CIM ................................................................................. 13 Figure 3 : Métamodèle du PSM ............................................................................................................ 14 Figure 4: Métamodèle des processus métier ......................................................................................... 14 Figure 5: Métamodèle des activités....................................................................................................... 15 Figure 6: Stéréotype des processus métier ............................................................................................ 15 Figure 7: Processus génériques ............................................................................................................. 16 Figure 8: Stéréotypes des domaines et des processus génériques ......................................................... 16 Figure 9: Stéréotypes de but, personne et information.......................................................................... 17 Figure 10: Processus métier et entités métier ........................................................................................ 17 Figure 11: Stéréotypes des trois activités métier du prototype.............................................................. 19 Figure 12: Diagramme des activités métier........................................................................................... 19 Figure 13: Approche MDA adaptée à la configuration d’un ERP ........................................................ 20 Figure 14: Prototype implémenté dans Rational XDE .......................................................................... 21 Figure 15: Stéréotypes des processus métier actif et inactif avec leurs définitions............................... 22 Figure 16: Sélection de l’état actif/inactif du processus générique ‘Commande’ ................................. 22 Figure 17: Profil des éléments pour la transformation du CIM en PIM................................................ 23 Figure 18 : Profil des entités du CIM .................................................................................................... 24 Figure 19: Propriétés de l’activité ‘Saisie client’ .................................................................................. 24 Figure 20 : Profil des éléments pour la transformation du PIM en PSM .............................................. 25 Figure 21 : Profil du PSM ..................................................................................................................... 25 Figure 22: Modèle de données des ventes d’Adonix............................................................................. 29 Figure 23 : Modules proposés par Adonix X3 ...................................................................................... 30 Figure 24 : Modules proposés par SAP R/3 v.4.7 et MS Navision 4.0 ................................................. 30 Figure 25 : La page d’accueil d’Adonix X3.......................................................................................... 31 Figure 26 : Les domaines du prototype ................................................................................................. 31 Figure 27 : Le menu des ventes............................................................................................................. 32 Figure 28 : Processus génériques inclus dans le domaine ventes.......................................................... 32 Figure 29 : Le menu Commandes ......................................................................................................... 33 Figure 30 : Modèles des processus métier............................................................................................. 33 Figure 31 : Sélection du type de commande ......................................................................................... 34 Figure 32: Ecran d’une saisie de commande normale........................................................................... 34 Figure 33: Onglet « Gestion » de la fenêtre « Saisie de commande »................................................. 35 Figure 34: Onglet « Livraison » de la fenêtre « Saisie de commande ».............................................. 35 Figure 35: Onglet « Facturation » de la fenêtre « Saisie de commande » ............................................ 36 Figure 36: Onglet « Lignes » de la fenêtre « Saisie de commande » ................................................... 36 Figure 37: Modèle des activités de la saisie d’une commande sur Adonix X3..................................... 37 Figure 38 : Données du champ ’client commande’............................................................................... 38 Figure 39: Paramétrage du champ ‘client commande’.......................................................................... 38 Figure 40: La table AMSKZON contenant les propriétés du champ ‘client commande’ ..................... 39 Figure 41 : Etapes du paramétrage ........................................................................................................ 40 Figure 42: CIM dans son état initial ...................................................................................................... 41 Figure 43: La propriété du processus ‘Etablir un devis’ est mise à ‘false’ ........................................... 41 Figure 44: Plugin CIMtoPIM dans la barre de menu ............................................................................ 42 Figure 45: Sélection des modèles impliqués dans la transformation CIM to PIM................................ 42 Figure 46: PIM actualisé après la transformation avec le devis désactivé ............................................ 42 Figure 47: Modèle des processus actualisé après la transformation...................................................... 43 Figure 48: Sélection des propriétés de l’activité « saisie de la livraison » ........................................... 43 Figure 49: Fenêtre des propriétés dans Rational XDE .......................................................................... 44 Figure 50: le plugin PIMtoPSM dans la barre de menu ........................................................................ 44 Figure 51: sélection des modèles impliqués dans la transformation PIM to PSM ................................ 44

6

Figure 52: modèle des activités actualisé après la transformation ........................................................ 45 Figure 53: une partie de l’entité « Livraison » dans le PSM actuel....................................................... 45 Figure 54: Onglet des livraisons avec suppression du champ ‘Transporteur’....................................... 46 Figure 55: Revenus total par régions au second trimestre 2005 (Mios EUR) ....................................... 47 Figure 56: Revenus total par type de solution au second trimestre 2005 (Mios EUR) ......................... 48 Figure 57 : Arborescence des opérations et écrans ............................................................................... 49 Figure 58 : Ecran initial des commandes client..................................................................................... 49 Figure 59 : Saisie des informations de la commande ............................................................................ 50 Figure 60 : Calcul de la date de mise a disposition ............................................................................... 50 Figure 61 : Flux de documents .............................................................................................................. 51 Figure 62 : Ecran de configuration de workflow................................................................................... 52 Figure 63 : Accès aux informations techniques d’un champ................................................................. 53 Figure 64 : Outil de développement ABAP .......................................................................................... 53 Figure 65 : Outil de configuration GuiXT............................................................................................. 55 Figure 66 : Propriétés du profil ............................................................................................................. 58 Figure 67 : Exportation d’un ficher JAR............................................................................................... 59

7

1 Modèle théorique Gil Gaillard & Philippe Dugerdil

1.1 Introduction En raison de la pression croissante sur les coûts et la standardisation du domaine IT des entreprises, un nombre de plus en plus important de compagnies choissent un système ERP comme colonne vertébrale de leur système informatique. Autrefois l’apanage des multinationales, le phénomène atteint également les PME [Van00]. La preuve n’est plus à faire que les ERPs sont une alternative viable au développement d’applications spécifiques pour des besoins informatiques standards et que la qualité est souvent supérieure en termes d’implémentation de processus métiers [Har02]. Si l’ERP est devenu une véritable alternative aux développements spécifiques, il s’accompagne souvent d’une forte dépendance de l’entreprise par rapport l’éditeur du progiciel. L’intégration d’un ERP est une tâche complexe et il est rare que le département informatique d’une société cliente en maîtrise tous les détails. En réalité, lorsque d’importantes modifications doivent être effectuées au sein d’un tel système, une aide de la part des consultants mandatés par l’éditeur est fréquemment requise. Cette situation peut provoquer chez le chef d’entreprise un sentiment de perte de contrôle de son système informatique. Une possibilité pour atténuer ce problème est de fournir aux décideurs un modèle du système en adéquation avec leur niveau de compréhension et d’expertise : une représentation graphique des processus métier implantés. La difficulté de cette approche est d’assurer que ce modèle reflète fidèlement l’implantation. Dans le cadre de ce projet, nous proposons d’exploiter l’approche MDA afin de permettre la configuration d’un progiciel au travers de modèles des processus métier à implanter. Cependant, l’outil de modélisation ainsi que le langage graphique utilisé ne doivent pas devenir eux-mêmes une source de dépendance pour l’entreprise. Par conséquent, nous avons choisi le standard UML comme langage de modélisation accompagné de ses mécanismes d’extensions (profils) permettant de définir les éléments de représentation des processus métier. Ainsi, nous avons adopté l’extension d’UML pour la modélisation métier proposée par Eriksson et Penker [Erik00]. Cette dernière est très proche du standard BPMN largement utilisé pour la modélisation métier [BPM03]. Elle apporte un complément nécessaire au profil de modélisation métier publié par IBM [Jon04]. Nous avons exploité ce profil au moyen d’un outil de modélisation extensible : XDE® de IBM/Rational®. Mais encore une fois, pour que cette approche soit pertinente, il faut s’assurer que la modélisation corresponde à l’implémentation. C’est là qu’intervient l’approche MDA de l’OMG [MDA03, Fra03]: l’idée est de générer la configuration à partir des modèles. Nous avons donc étudié la possibilité d’utiliser l’approche MDA pour établir un outil de configuration semi-automatique d’ERP. A partir d’un modèle des processus métier, l’outil va modifier ce modèle pour graduellement l’amener à un niveau de détail permettant la mise à jour des bases de données contenant les paramètres de l’ERP. NB : ce document ne contient pas d’information sur la définition d’un processus métier ni sur leur structure et conventions de représentation graphique. Le lecteur intéressé est invité à consulter [Erik00, Sha01, BPM03]. De même, l’approche MDA n’est pas décrite en détail. Une bonne introduction peut être trouvée dans [FRA03] et une information complète sur le site de l’OMG (www.omg.org).

http://www.omg.org/

8

1.2 Etat de l’art Partant du fait que le non alignement entre les besoins des entreprises et la configuration des systèmes est l’un des principaux facteurs d’échec de la mise en place des ERP [Vog02] et que les langages de paramétrage propriétaires sont souvent compliqués à maîtriser, quelques tentatives ont été faites pour remplacer ces derniers par des langages graphiques standards. Depuis quelques temps, le besoin de développer les modèles des processus métier pour la configuration des ERP est reconnue [Gul00]. Depuis le milieu des années 80, Jacobson [Jac85] a proposé d’appliquer la modélisation objet et les cas d’utilisation à la modélisation métier. Il a alors décrit les principaux stéréotypes d’objets métier, qui sont encore en usage aujourd’hui. Plus tard, l’utilisation d’UML en tant que langage de modélisation a été largement documentée par les consultants de Rational [Ng02, Bak01, Heu01]. L’application des concepts orientés objet n’a en revanche été appliqué pour l‘intégrations de système ERP que récemment. Par exemple Arinze et Anandarajan [Ari03] proposent un framework orienté objet afin de faciliter la définition des paramètres d’un ERP. Cependant, leur approche n’a pas réellement augmenté le niveau conceptuel de la modélisation. Elle a tout au plus remplacé les paramètres de langage propriétaire par des représentations orientées objet. Il faut toutefois relever que la modélisation métier n’était pas leur motivation première. La modélisation des processus métier pour les ERP dans un format indépendant a été proposée par Sheer [Sch00] qui a développé un produit commercial ARIS [IDS03]. Cependant, cette approche introduit à son tour une dépendance, pas celle liée à l’éditeur de l’ERP mais à l’outil de modélisation. L’application de l’approche MDA de l’OMG pour modéliser l’entreprise et ses processus a été largement étudiée par Wegman [Weg03]. Ce modèle n’a, en revanche, pas été appliqué au développement de systèmes informatiques et encore moins à la configuration des ERP. Linvald et Østerbye ont récemment proposé d’utiliser l’UML pour configurer les ERP [Lin02]. Toutefois, leur démarche se concentre sur l’aspect visuel d’UML et ne propose pas de méthodologie ni d’application de l’approche MDA. D’un autre côté Rolland et Prakash ont proposé d’utiliser UML afin de modéliser les besoins fonctionnels d’un système informatique d’une entreprise et de comparer ce système à un ERP [Rol01]. Ce travail est resté au stade des spécifications et ne traite pas la problématique du paramétrage d’un ERP. Finalement, il est à noter que l’avantage d’employer un langage de modélisation unique, à savoir UML, pour modéliser aussi bien les éléments métier que système a été soulevé par Heberling et al. [Heb02]. Leur travail ne mentionne cependant pas l’application d’UML pour la configuration des ERP.

9

1.3 MDA L’idée centrale, lors de la création de l’approche MDA, était de fournir un cadre méthodologique et architectural de développement et d’intégration de systèmes qui assure la pérennisation des architectures métiers de l’entreprise en les découplant des préoccupations technologiques. Elle définit une approche orientée modèle, dans laquelle les représentations métier indépendantes de toute plateforme technologique sont graduellement enrichies pour permettre, en fin de processus, une génération de code pour une plateforme cible spécifique. Basée sur trois modèles, l’approche MDA insiste sur les mécanismes de transformation entre ces modèles. Le premier modèle, le CIM (Computational Independent Model) ou modèle du domaine, décrit les exigences du système et la situation dans laquelle le système sera utilisé. Il correspond à la modélisation du système d’information de l’entreprise sans parler encore de système informatique. Le CIM place le système dans son contexte opérationnel et permet de représenter ce que le système devrait réellement assurer comme services. Les exigences décrites dans les modèles CIM doivent pourvoir à la construction d’autres modèles qui les implémentent et inversement. Le deuxième modèle, le PIM (Platform Independent Model) est un modèle de haut niveau d’abstraction qui reste indépendant de la plateforme. Il représente les différentes entités fonctionnelles d’un système d’information informatisé avec leurs interactions, exprimées uniquement en termes de logique d’entreprise. Ainsi, il décrit le système en masquant les détails de son utilisation sur une plateforme technique particulière. Le dernier modèle, le PSM (Platform Specific Model) est, quant à lui, dépendant de la plateforme. Il sert essentiellement de base à la génération de code pour un environnement d’exécution donné. Le PSM est une représentation de l’implémentation dans une technologie particulière. Un PSM doit donc être généré pour chaque plateforme technologique spécifique. Dans la littérature, les premières applications de l’approche MDA s’adressaient aux middleware et à leurs services. Nombre d’ouvrages dans la littérature fournissent des exemples concernant CORBA et autres EJB [Hub02]. Le MOF (Meta-Object Facility) [MOF02], les profils [Rum04] et l’OCL (Object Constraint Language) [OCL03] sont souvent utilisés pour mettre en œuvre l’approche MDA. Concernant le premier, il est extrêmement puissant pour exprimer des métamodèles. Sa mise en œuvre est toutefois délicate pour le non spécialiste. Les profils représentent une extension de la symbolique UML pour une utilisation ou un domaine particuliers. Un profil contient un ensemble de symboles et contraintes supplémentaires ainsi que leur sémantique. La mise en oeuvre d’un profil est plus facilement maîtrisable par un non spécialiste. L’OCL, quand a lui, est largement utilisé pour exprimer les contraintes au niveau des modèles UML ainsi que les transformations MDA. Ce dernier aspect permet de donner à l’approche MDA une indépendance par rapport à l’environnement de développement. Il faut finalement relever que la volonté de maîtriser la complexité et de pérenniser les analyses de haut niveau via MDA a, dans la littérature, été trop souvent reléguée au second plan, derrière la problématique de la transformation de modèles. Conscients que cette dernière représente le plus gros du travail, certains auteurs se sont focalisés sur ces mécanismes sans les situer dans une démarche globale. Il est à ce propos symptomatique que nombres de références ne citent même plus le CIM comme modèle intégrant du MDA. Il est considéré comme une première documentation, la transformation du PIM au PSM retenant toutes les attentions.

10

1.4 MDA et la configuration des ERP Une des motivations de l’approche MDA de l’OMG est de promouvoir l’indépendance par rapport à une plateforme donnée pendant la conception des systèmes informatiques. En effet, l’architecte ou le développeur vont concentrer leurs efforts sur la problématique et les besoins de leur application indépendamment de la plateforme cible et laisseront à l’environnement de développement le soin de s’adapter aux contraintes inhérentes à la plateforme choisie. Le modèle le plus haut dans la hiérarchie de conception, le CIM (Computational Independant Model) s’adresse au domaine métier [MDA03]. Il est parfois appelé modèle du domaine et en inclut les entités et les concepts principaux. Ensuite, en ajoutant la connaissance des processus métiers communs aux ERP, le PIM (Platform Independant Model) peut être à son tour établi. Bien que la technologie propre à un ERP ne doive pas être prise en compte à ce stade de l’approche, il est important de garder à l’esprit que la finalité est la configuration d’un ERP et non le développement d’une application dans son intégralité. Ceci est en concordance avec les observations d’Almeida et al. [Alm04] qui stipule que le PIM doit refléter les capacités et le potentiel de la plateforme cible. Finalement, le PSM (Platform Spécific Model) est un modèle obtenu en ajoutant au PIM la connaissance des activités qui implantent chaque processus métier de l’ERP cible. Comme ces modèles ainsi que les transformations sont décrits en UML, standard de facto pour les ingénieurs informaticiens, cette approche a l’avantage de ne nécessiter pour eux aucune formation sur un nouveau langage de développement. D’ailleurs, notre outil peut être implémenté sur toute plateforme supportant le framework MDA. Pour notre part, nous avons choisi XDE de IBM/Rational. L’approche MDA a été initialement pensée pour définir et concevoir des développements spécifiques d’applications. Dans le cas traditionnel d’utilisation de l’approche MDA, la dernière étape est la génération du code pour la plateforme spécifique. Cependant, dans un ERP, le système est déjà conçu. En quelque sorte, il s’agit d’une boîte à outil contenant des composants (visuels et non visuels) à activer, désactiver ou étendre selon la configuration des processus métiers désirés. C’est pourquoi l’intégration d’un ERP diffère d’un développement d’application dans l’approche MDA : la dernière phase d’une application de MDA pour ERP représente la génération de paramètres. Il n’y a donc pas de génération de composants, mais seulement une activation ou désactivation d’éléments préexistant. Ainsi, la notion de transformation de modèle de MDA est remplacée dans notre cas par la notion de sélection ou de suppression d’éléments de modèles prédéfinis. Bien entendu, les éléments supprimés ne le sont pas physiquement dans l’ERP car ils sont nécessaires à son intégrité. Ils sont simplement rendus inactifs. Finalement, il est clair que certaines situation de paramétrage d’ERP exigent de créer du code afin, par exemple, d’étendre certaines fonctionnalités. Cette problématique n’est pas couverte dans le cadre du présent travail. Cependant, il est envisageable de la traiter par le biais du langage OCL qui permet d’exprimer des contraintes sur les modèles. Cette démarche constituerait le prolongement naturel de la présente recherche.

11

1.5 But du projet Étudier la faisabilité d’une méthode légère (selon [Koe03]) de configuration d’ERP. Afin d’y parvenir, un premier prototype contenant les modèles théoriques et les mécanismes de transformation sera développé. Après une première série de tests, les interactions avec deux éditeurs de progiciels recentreront notre travail sur les problèmes pratiques et permettront d’affiner notre approche. 1.6 Principe de l’approche Le projet se base sur la transformation de modèles d’entités métier qui correspondent à celles supportées par tout ERP. Ainsi, le concept de transformation MDA que nous mettons en œuvre se traduit par une évolution et un enrichissement de l’information liée aux entités métiers. Dans l’étape finale, lors de la génération des paramètres de la configuration, un mapping est effectué entre les noms des entités et attributs compréhensibles par l’utilisateur vers les termes techniques propres à chaque ERP. Dans le cadre de ce projet, les trois modèles CIM, PIM et PSM représentent des entités métier. L’originalité de notre démarche est que les transformations entre modèles s’expriment elle-mêmes par des modèles. Notre approche considère que l’ERP possède initialement la potentialité de couvrir un large éventail de processus. Ainsi, l’utilisateur va configurer son processus métier en supprimant les activités et informations qui lui sont inutiles. Il s’agit donc en quelque sorte d’un paramétrage par suppression plutôt que par ajout. Au départ, l’utilisateur dispose d’un modèle générique des entités métier dans lequel il peut sélectionner les entités à désactiver en fonction de ses besoins. Par défaut, les entités sont toutes « actives » c’est à dire participent potentiellement à l’implantation finale. Par exemple s’il ne veut pas saisir d’information sur le fournisseur pour une commande, il va désactiver l’entité fournisseur. Dans ce cas tous les champs associés aux attributs du fournisseur seront supprimés des écrans de l’ERP. Le modèle initial des entités métier dans lequel l’utilisateur a sélectionné les entités à désactiver représente le CIM. Pour transformer le modèle des entités métier du CIM en modèle PIM, l’utilisateur lance une propagation de propriétés4 par l’intermédiaire d’un processus métier qu’il aura choisi parmi un ensemble prédéfini. A ce niveau les processus métiers sont définis de manière suffisamment générale pour être semblables quelque soit l’ERP considéré. Un processus métier « consomme » des entités métier et en génère au travers de ses différentes tâches. Si une entité métier consommée par une tâche est désactivée, la tâche elle-même est alors désactivée ainsi que toutes les entités produites par la tâche. De plus, l’utilisateur a la possibilité d’agir sur la transformation elle-même en désactivant une tâche du processus choisi. Il s’agit, dans ce cas, d’une tâche qu’il ne souhaite pas voir exécutée dans le cadre de son processus au niveau de l’ERP. Cette opération a pour conséquence que les entités produites par la tâche seront désactivées également. Ces opérations de propagation de propriétés d’entités sont menées de proche en proche sur l’ensemble du modèle des entités. A cette étape de la transformation, les règles métier et les diverses contraintes, écrites en OCL, peuvent être ajoutées sur le modèles des entités (PIM) et des processus (transformation)5. Le modèle des processus contient aussi la représentation des responsables et intervenants au niveau des tâches qui peut être exploitée pour définir des profils utilisateurs.

4 Il s’agit de propager la désactivation de composants, via leur propriété “status”, comme nous le verrons plus loin. 5 Cette étape ne fait pas partie du présent travail mais en constituerait une extension naturelle.

12

Pour transformer le modèle des entités métier de PIM en PSM l’utilisateur va appliquer au PIM un modèle d’activités représentant la réalisation de chaque tâche dans le cadre d’un ERP particulier. Cette application a deux conséquences :

1. Premièrement, en désactivant sélectivement certaines activités d’une tâche, la désactivation va se propager aux entités générées par l’activité et ensuite aux activités qui consomment cette ressource.

2. Deuxièmement, chaque activité étant propre à un ERP particulier, nous avons la possibilité d’enrichir l’information sur chaque attribut d’entité au travers de la sélection d’une propriété de l’activité. Par exemple, si la propriété d’une activité « saisir adresse client » possède la valeur « obligatoire » ou « optionnelle », cette information va être propagée à l’entité manipulée et ses attributs.

Une fois le modèle d’entités PSM créé, il s’agit d’effectuer le mapping avec les entités réelles de l’ERP cible et de mettre à jour les tables de la base de données. Pour cela un fichier de mapping fournit une correspondance entre chaque attribut d’entité et ses propriétés et leurs localisations dans la base de données de l’ERP. Il est alors possible de générer des requêtes de mise à jour de cette base de données. 1.7 Les étapes de l’approche Premièrement, les trois modèles (CIM, PIM et PSM) sont décrits théoriquement par leurs métamodèles. Dans une deuxième partie, les deux modèles (processus métier et activités) utilisés pour les transformations sont expliqués. 1.7.1 Metamodèle des ressources De manière générale les processus utilisent, consomment, manipulent et produisent des ressources. Leur métamodèle peut s’exprimer de la manière suivante [Erik00] :

Figure 1 : Métamodèle des ressources 1.7.2 Métamodèle du CIM Le CIM est constitué d’entités métier qui peuvent être actives ou inactives selon la sélection de l’utilisateur. Cette sélection s’exprime directement sur l’entité au travers d’une propriété (‘status’). En suivant [Erik00] nous considérons les entités consommées et produites par les processus comme des ressources physiques (une ressource de type « information » représente une source de connaissances nécessaire à la réalisation d’une tâche. Elle n’est pas à proprement parler « consommée » par le processus).

13

Resource

Thing

PhysicalProperty1

1 enables/disables

Figure 2: Métamodèle des entités métier du CIM 1.7.3 Métamodèle du PIM Le métamodèle du PIM est identique à celui du CIM (fig. 2).

1.7.4 Métamodèle du PSM Le métamodèle du PSM diffère de celui du PIM par la suppression de la propriété au niveau de l’entité et par l’ajout d’une propriété à chaque attribut des entités métier. Dans le PSM, l’information d’activation est donc représentée au niveau des attributs. Toutefois, il n’est pas question de permettre à l’utilisateur de modifier le status individuel d’une propriété6. Les manipulations d’activation restent globalement au niveau de l’entité, mais les valeurs sont physiquement enregistrées au niveau des attributs. De plus le type de la propriété des attributs n’est plus booléen comme pour l’entité mais le type « String » permettant un plus large éventail de valeurs. Ces dernières dépendront des activités qui manipulent les entités. Finalement, chaque entité et chaque attribut est accompagné d’un mapping vers la base de données du système final. A partir de ces informations (localisation des données dans la base de l’ERP et valeur de ces données) il sera possible de générer des scripts SQL de mise à jour de la base de données de l’ERP.

6 Notre approche perdrait alors un peu de son intérêt car cela reviendrait au même que de paramétrer le système de manière traditionnelle, champ par champ.

14

Resource

Thing

PhysicalProperty

Attribute

*

1

1

qualifies

LocationIdentification

1

maps to

1

maps to

{inv:self.locationIdentification <> self.physical.locationIdentification}

Figure 3 : Métamodèle du PSM 1.7.5 Métamodèle des processus métier La figure 3 exprime le métamodèle des processus métiers, ce dernier est partiellement repris de [Erik00]. La différence est la présence de la propriété qui permet de représenter l’activation ou la désactivation du processus métier lui-même. Il est ainsi possible de désactiver globalement tout un processus (ou une tâche, considérée comme un sous-processus).

Figure 4: Métamodèle des processus métier 1.7.6 Métamodèle des activités Le modèle des activités est spécifique à l’ERP cible. Il intervient dans la seconde transformation, celle du PIM au PSM avec un rôle similaire à celui du modèle des processus métier dans la transformation CIM vers PIM. Le métamodèle de la figure 5 en définit la

15

structure. Les activités possèdent une propriété permettant de les désactiver sélectivement, selon les désirs des utilisateurs.

Figure 5: Métamodèle des activités Un modèle d’activité représente les étapes de la réalisation d’un processus métier donné sur un ERP particulier. Il y a donc autant de modèles d’activités, pour un processus donné, qu’il y a d’ERP cibles différents. 1.7.7 Règles métier Sans les règles métier, les processus de transformations de modèles MDA se limitent à des activations ou désactivations d’éléments. Cependant, dans le cadre limité de notre démonstration de faisabilité de l’implémentation d’un ERP au travers de modèles, les règles métier ne sont pas incluses7. 1.7.8 Profil UML Pour étendre le langage UML afin d’inclure les différents définitions utiles au projet, nous avons définit un profil UML basé sur la version 1.5 du langage. Notre profil inclut de nouveau stéréotypes et propriétés (tagged values) [UML03]. Les propriétés servent à contenir et propager l’information nécessaire aux transformations du MDA. En particulier cela permet d’indiquer si un élément d’un modèles est actif ou non.

1.7.8.1 Elements de modélisation Processus métier (stéréotype): représente un ensemble d’activités effectué par une ou plusieurs personnes. Il peut être constitué de sous processus, ou tâches, selon une décomposition hiérarchique. L’élément de décomposition du plus bas niveau est donc l’activité. Du point de vue profil UML, le processus métier est conçu comme une extension de la métaclasse ”Activité” (fig. 6). Les entités métier vont être associées aux processus et activités qui les manipulent.

«MetaClass»Activity

«Stereotype»Business Process

+ «TagDefinition» status : Boolean

Figure 6: Stéréotype des processus métier

7 Comme nous l’avons déjà soulevé, une extension de ce travail incluant les règles métier via une spécification OCL semble parfaitement envisageable. En particulier, plusieurs compilateurs OCL vers un langage cible de haut niveau sont disponibles (par exemple vers Java [Loe03]). A l’aide de cette technologie, il serait possible de générer le langage de paramétrage propriétaire a chaque ERP cible. Le problème principal étant, comme nous aurons amplement l’occasion de le voir, la localisation de ces règles et contraintes au niveau de la base de données de l’ERP cible.

Domaine (stéréotype): représente un segment ou une catégorie de métiers tels que la comptabilité, la production, les ressources humaines, les ventes et les fournisseurs. Le rôle du stéréotype « domaine » est de regrouper les éléments des modèles, essentiellement des processus et des entités métier. C’est pourquoi le domaine est une extension de la métaclasse ”Package” (fig. 7). Sa propriété est une valeur booléenne agissant comme un indicateur de l’état de l’élément. Lorsque l’utilisateur désactive un domaine au moyen de cette propriété, tous les éléments contenus dans ce domaine sont désactivés au moyen de leurs propriétés respectives. Processus générique (stéréotype): représente un regroupement de processus semblables, présents dans plusieurs domaines. Par exemple, le processus “livraison” peut être inclus dans les domaines : production, achats et ventes (Fig. 7).

livraison

Vente :

Production :

livraison

Processus générique

Figure 7: Processus génériques En conséquence, la livraison contient des activités dans plusieurs domaines. Le processus générique est une extension de la métaclasse “Package” (fig. 8). De manière identique à celle du domaine, une propriété booléenne indique si le processus générique est actif. Cet état s’applique aussi à tous les éléments contenus dans ce processus générique, c’est à dire à l’ensemble des domaines concernés.

«MetaClass»Package

«Stereotype»Domain


«Stereotype»Generic Process


Figure 8: Stéréotypes des domaines et des processus génériques

Contrainte métier : représente une limitation spécifique, une valeur initiale, un message ou une contrainte temporelle pour un processus métier. Elle est exprimée en OCL. Personne (stéréotype): représente une ressource humaine associée à un processus métier. C’est une extension de la métaclasse “Classe” (fig. 8). Cet élément de modélisation peut être exploité pour définir des profils utilisateurs pour les ERP.

16

17

But et information (stéréotypes): représentent le but d’un processus métier [Erik00, Sha01] et l’information (connaissances requises) qui peuvent être liés à ce processus. A ce stade du projet, ces éléments sont utilisés à des fins de documentation uniquement. Ce sont des extensions de la métaclasse “Classe” (fig. 9). Ces éléments sont associés au processus métier correspondant (le symbole en forme de losange représente la ressource « information ») (fig. 10).

«Stereotype»Goal


«MetaClass»Class

«Stereotype»People


«Stereotype»Information


Figure 9: Stéréotypes de but, personne et information

Figure 10: Processus métier et entités métier

1.7.8.2 Règles de transformation du CIM en PIM Une transformation de modèle représente essentiellement une propagation de valeur d’activation d’entité métier. Ainsi pour transformer le modèle des entités métier de leur état

18

« CIM » à leur état « PIM » l’utilisateur va lancer une propagation de la valeur de la propriété d’activation de chaque entité, par l’intermédiaire d’un processus métier dans lequel ces entités sont impliquées. Les règles de propagation de l’activation sont:

1. Intégrité d’association : si une entité métier du CIM est inactive et qu’une autre entité y est associée via une association de cardinalité 1 avec elle (c'est-à-dire que la seconde entité est toujours associée à l’entité désactivée), la seconde entité doit être inactivée à son tour

2. Intégrité d’héritage : si une entité générique (classe) est inactive, ses spécialisations (sous-classes) le sont également

3. Si un processus métier (ou une tâche à l’intérieur du processus) « consomme » une entité métier désactivée alors, le processus (ou la tâche) est désactivée à son tour8.

4. Si un processus métier (ou une tâche à l’intérieur du processus) est désactivée alors toutes les entités produites par le processus (ou de la tâche) sont désactivées9.

5. Si un domaine ou un processus générique est désactivé, tous les éléments inclus sont à leur tour désactivés.

La désactivation d’un processus ou d’une tâche peut être la conséquence de la règle (1) ci-dessus ou d’une désactivation directe par l’utilisateur. Dans ce dernier cas, l’utilisateur n’agit donc plus sur le modèle mais en quelque sorte sur la transformation.

1.7.8.3 Règles de transformation du PIM en PSM Pour transformer le modèle des entités métier de leur état « PIM » à leur état « PSM » l’utilisateur va lancer une propagation de la valeur de la propriété d’activation de chaque entité par l’intermédiaire des activités métier dans lesquelles l’entité est impliquée. Ces activités métiers, qui sont des extensions de la métaclasse “activité” (fig. 11 et 12), représentent la réalisation des processus métier (ou des tâches) dans le cadre de l’ERP cible. Dans notre prototype, une activité métier peut être de type « saisie », « validation » ou « sélection ». Chacune d’entre elles peut contenir des informations spécifiques exprimées au moyen de propriétés. Par exemple, la propriété « status » de l’activité métier de type « saisie » peut prendre les valeurs suivantes : « optionnel », « obligatoire », « affiché » ou « inutilisé ». Durant la transformation PIM vers PSM, la propriété d’état (status) des entités est supprimée au profit de l’ajout d’une propriété de type String à chacun de leurs attributs. En effet, le PSM est un modèle qui doit nous permettre de générer le code SQL nécessaire à la mise à jour de l’ERP. Cette mise à jour se base principalement sur l’état des attributs d’une entité plutôt que sur l’entité elle-même. Par exemple, dans le cas du paramétrage d’un écran, il s’agit de présenter ou non certains champs qui sont des attributs d’entités. En conséquence, la propagation de valeur de propriétés ne se fait plus au niveau des entités mais de chacun de leurs attributs. Les règles de propagation de valeur de propriétés sont:

1. La valeur de la propriété d’état d’une entité du PIM est copiée dans la propriété de chaque attribut de l’entité PSM correspondante.

2. Si une activité « consomme » une entité désactivée (ou dont l’ensemble des attributs est désactivé), alors cette activité est désactivée à son tour. Dans ce cas, la propriété de l’activité ne peut pas recevoir d’autre valeur.

3. Si une activité est désactivée, alors la désactivation est propagée aux attributs des entités produites par l’activité10.

8 En effet, partant du principe que l’entité est nécessaire au déroulement du processus, si elle est absente alors le processus ne peut pas fonctionner. 9 Si la fabrication d’une entité est arrêtée elle ne peut évidemment pas être utilisée.

19

4. Si l’utilisateur sélectionne une valeur particulière pour la propriété d’une activité, cette valeur est propagée aux attributs des entités produites par l’activité. Par exemple, si la valeur de la propriété d’une activité « saisir adresse client » est « obligatoire », cette information est propagée aux attributs de l’entité manipulée (l’entité « client »). Cette valeur, à la différence de la désactivation, n’est pas propagée au delà de l’entité concernée.

Une fois le modèle d’entités PSM mis à jour, le système peut exploiter l’information de mapping des attributs et leurs propriétés ainsi que la valeur de ces attributs et propriétés pour générer des requêtes de mise à jour de la base de données. Cette dernière étape n’est pas à proprement parler une transformation. C’est plutôt l’équivalent de la génération de code dans le cadre d’un développement traditionnel. Bien que cette étape soit conceptuellement simple, le problème essentiel est de construire le mapping en localisant les éléments dans la base de données de l’ERP. Pour cela, le recours à l’éditeur de l’ERP ou à des consultants est indispensable. Ce travail nous a créé de grandes difficultés comme nous le verrons par la suite. Finalement, les contraintes supplémentaires exprimées en OCL peuvent être traduits en enregistrement dans la base de données cible au moyen de scripts SQL. Ce travail n’a toutefois pas été réalisée dans le cadre du présent projet.

«MetaClass»Activity

«Stereotype»Entering


«Stereotype»Validating


«Stereotype»Selection


Figure 11: Stéréotypes des trois activités métier du prototype

Figure 12: Diagramme des activités métier

La figure 13 représente l’architecture complète de notre système de transformation. On voit que les modèles transformés sont constitués exclusivement d’entités et que les transformations s’expriment également sous forme de modèles.

10 Dans ce cas, la désactivation n’est plus représentée par la valeur booléenne “false”, mais par l’une des chaînes de caractères prédéfinies représentant la désactivation. Notre prototype fait ainsi usage de la valeur ‘unused’.

20

Figure 13: Approche MDA adaptée à la configuration d’un ERP

1.8 Implémentation du prototype Le prototype de notre système a été réalisé dans l’environnement de développement IBM/Rational® XDE® à l’aide du MDA toolkit (fig. 14). Notre extension est implémentée sous la forme d’un plugin Eclipse écrit en Java. La plateforme spécifique choisie pour le développement du prototype est Adonix X3. Une tentative a également été menée pour appliquer notre démarche à SAP, comme nous le verrons dans le chapitre correspondant.

21

Figure 14: Prototype implémenté dans Rational XDE 1.8.1 MDA Toolkit Notre prototype a été implanté dans environnement de développement Rational/IBM® XDE® à l’aide du plugin Eclipse « MDA Toolkit 11». Cet outil comprend un wizard pour le développement de transformation, un outil pour générer des profils et une API de manipulation des modèles. La structure standard des transformations proposée par le MDA Toolkit consiste en trois opérations : la validation, la transformation et la vérification. Son API fournit des opérations simples permettant la manipulation des modèles et leurs éléments. Par exemple, il permet de parcourir les classes d’un modèle, de les copier, de parcourir les éléments associés etc. Une limitation importante de sa version actuelle est que seule la manipulation des classes est complète. Les autres éléments ne peuvent être que créés ou effacés. L’outil de création de profil UML permet la définition de stéréotypes, de propriétés ainsi que des symboles associés. A cause de la limitation des APIs nous avons été contraints de définir tous les éléments, processus métier ou autres activités comme des classes (ce qui est contraire à la définition de leur stéréotype). Qui plus est, l’activité qui est pourtant un élément standard de l’UML a aussi du être redéfinit sous forme de classe pour permettre sa manipulation dans le cadre de nos modèles de processus12. 11 MDA Toolkit:http://www-306.ibm.com/software/rational/mda/toolkit.html 12 Nous insistons sur le fait que ces définitions, qui vont à l’encontre de certains standards UML, ont été rendues nécessaires par l’immaturité de l’environnement de développement MDA Toolkit de XDE.

1.8.2 Profils UML

1.8.2.1 Profil du CIM Afin d’alléger la mise en œuvre, nous avons choisi de travailler directement avec les profils d’Eriksson-Penker [Erik00] et non pas au niveau du MOF. Nous les avons toutefois augmentés par l’ajout de propriétés pour véhiculer l’information de paramétrage. Au niveau du prototype, le profil CIM contient non seulement les stéréotypes pour les entités métiers mais également pour le modèle des processus métier nécessaire à la transformation du CIM au PIM. Toutefois, ceci n’est nullement obligatoire. On aurait peu définir deux profils distincts. Afin de renforcer l’aspect visuel de nos modèles, nous avons choisi de colorier les éléments désactivés en rouge. Il est ainsi facile de les identifier et de suivre la propagation des désactivations au travers des transformations. Cependant nous nous sommes à nouveau heurtés à une limitation de Rational XDE et de son MDA Toolkit : il est impossible de définir la couleur d’un élément à l’aide de l’API fournie. Afin de contourner le problème, nous avons été contraints de définir deux stéréotypes par élément, un pour chaque état, comme on peut le voir sur la figure 15.

«MetaClass»Class

«Stereotype»BusinessProcess

+ «TagDefinition» status : Boolean = True

«Stereotype»BusinessProcess_unused

+ «TagDefinition» status : Boolean = False

«ShapeImage»«artifact»ShapeBP

«ExplorerImage»«artifact»ExploBP

«ShapeImage»«artifact»

ShapeBPu

«ExplorerImage»«artifact»ExploBPu

Figure 15: Stéréotypes des processus métier actif et inactif avec leurs définitions Les domaines et les processus génériques sont des stéréotypes de la métaclasse ‘Package’. Ce sont les seuls qui ne sont pas des stéréotypes de la métaclasse ‘Classe’ (ce qui, rappelons-le, nous est imposé par les limitations du MDA Toolkit). Ils ont également la propriété ‘status’ qui indique si l’élément est actif ou non. La figure 16 montre la fenêtre qui permet à l’utilisateur de définir l’état du le processus générique. Les figures suivantes présentent les profils des éléments des modèles de la transformation du CIM vers PIM (fig. 17) et du CIM (fig. 18).

Figure 16: Sélection de l’état actif/inactif du processus générique ‘Commande’

22

23

«Stereotype»Domain


«ExplorerImage»«artifact»

ExploDomain


ShapeDomain

«MetaClass»Package

«Stereotype»Domain_unused



ExploDomain_unused


ShapeDomain_unused

«Stereotype»GenericProcess



ExploGenericP


ShapeGenericP

«Stereotype»GenericProcess_unused



ExploGenericP_unused


ShapeGenericP_unused

«MetaClass»Class

«Stereotype»BusinessProcess



ExploBusinessProcess


ShapeBusinessProcess

«Stereotype»BusinessProcess_unused



ExploBusinessP_unused


ShapeBusinessP_unused


ExploInformation


ShapeInformation

«Stereotype»Information


«Stereotype»Information_unused



ExploInfo_unused


ShapeInfo_unused


ShapePeople

«Stereotype»People


ExploPeople

«Stereotype»Goal

«ExplorerImage»«artifact»ExploGoal


ShapeGoal

«Stereotype»Process Start


ExploStart


ShapeStart

«Stereotype»Process End

«ExplorerImage»«artifact»ExploEnd


ShapeEnd

Figure 17: Profil des éléments pour la transformation du CIM en PIM

24

Remarque : les pseudo-états UML « début » et « fin » des diagrammes d’activités sont des stéréotypes de la métaclasse ‘Classe’ 13.

«MetaClass»Class

«Stereotype»Resource


«Stereotype»Resource_unused



ExploResource


ShapeResource


ExploRes_unused


ShapeRes_unused

Figure 18 : Profil des entités du CIM

1.8.2.2 Profil du PIM Les entités du PIM sont en tous points semblables à celles du CIM. Concernant les activités, il y en a plusieurs types comme la saisie, la validation ou la sélection. Ces types ont été créés pour affiner le rôle de chaque activité. Par exemple, on peut imaginer attribuer des propriétés spécifiques à une activité de validation telles que l’heure de validation ou le nombre d’erreur maximal toléré.

Figure 19: Propriétés de l’activité ‘Saisie client’

La figure 19 présente les propriétés de l’activité « saisie client ». La figure 20 présente l’ensemble des stéréotypes nécessaires à l’expression de la transformation du PIM en PSM, basé sur les activités des processus. Au niveau du prototype, comme précédemment, le profil PIM contient les stéréotypes pour les entités métiers et pour le modèle des activités nécessaire à la transformation. 13 Toujours pour les mêmes raisons de limitation du MDA toolkit.

«MetaClass»Class

«Stereotype»Entering


«Stereotype»Validating


«Stereotype»Selection


«Stereotype»Entering_unused


«Stereotype»Validating_unused


«Stereotype»Selection_unused



ExploActivity


ShapeActivity


ExploActivity_unused


ShapeActivity_unused

«Stereotype»Start

«Stereotype»End


Shapestart


ShapeEnd

«ExplorerImage»«artifact»ExploEnd


ExploStart

Figure 20 : Profil des éléments pour la transformation du PIM en PSM

1.8.2.3 Profil du PSM On remarque sur le profil du PSM que la propriété des entités a disparu. Par contre on y voit l’ajout de propriétés aux attributs.

«MetaClass»Class

«Stereotype»Resource

«MetaClass»Attribute

«TaggedValueSet»Status

+ «TagDefinition» status : String

Figure 21 : Profil du PSM

25

26

1.8.3 Transformations Pour parcourir les éléments, une approche top-down est utilisée en partant des domaines pour descendre aux processus métier puis aux activités métier. A nouveau, l’API du « MDA Toolkit » nous a posé des problèmes : la fonction d’accès aux éléments ne permet pas de distinguer les différents niveaux hiérarchiques de packages. En conséquence, nous avons du contourner le problème par programmation : en analysant les stéréotypes des éléments.

1.8.3.1 Remise à zéro Avant de lancer un test de manipulation et de génération de modèles, il est utile de s’assurer que l’ensemble des modèles est « propre ». Nous avons donc implanté une fonction de remise à zéro qui réinitialise les modèles en rendant actifs tous les éléments des modèles CIM et PIM et supprimant tous les éléments générés ou propagés dans le PSM.

1.8.3.2 CIM en PIM La transformation du CIM au PIM est divisée en trois parties distinctes la validation, la transformation et la vérification. La structure correspondante du code est fournie en standard dans le framework du MDA Toolkit14.

1.8.3.3 Validation Dans le framework MDA cette opération consiste à vérifier un certain nombre de contraintes d’intégrité sur les modèles avant transformation. Dans notre prototype, cette opération n’a pas été implantée.

1.8.3.4 Transformation La transformation consiste à propager l’état d’activation sélectionné par l’utilisateur aux différents éléments du PIM à partir de leur valeur dans le CIM et de l’état des processus. Dans la cadre limité de ce projet, nous avons du faire des choix afin de fournir, dans le temps limité qui nous était imparti, un prototype fonctionnel. Ainsi l’opération de transformation ne prend pas en compte le fait que les domaines et les processus génériques peuvent s’organiser de manière hiérarchique. L’algorithme parcourt les entités et processus et contrôle leur état d’activation. Si la propriété correspondante est « inactive », le stéréotype représentant l’élément inactif est appliqué au possesseur de la propriété. Ceci se fait par l’ajout du suffixe “_unused” au nom du stéréotype (voir fig. 14: profil du PIM et des activités). Le symbole graphique du stéréotype inactif est affiché en rouge. Si l’élément considéré est un domaine ou un processus générique, c'est-à-dire qu’il s’agit d’un conteneur d’éléments, l’état d’activation de l’élément est propagé à l’ensemble des éléments contenus. Si le conteneur est inactivé, son symbole graphique est aussi affiché en rouge. Après avoir parcouru les éléments pour déterminer s’ils sont actifs ou non, on propage l’état d’activation via les processus15:

• Les entités en sortie d’un processus métier inactif sont inactivées • Les entités inactives en entrée d’un processus rendent le processus inactif.

14 Pour le prototype, ces trois opérations sont contenues dans le plugin com.gg.erp. 15 Dans le cadre limité de notre prototype, nous n’avons pas implanté la propagation d’activation correspondent aux intégrité d’héritage et d’association ( § 1.7.8.2 ).

27

L’algorithme est résumé par les expressions OCL suivantes : Context: CimModel inv: self.elements→selectl(x|x.stereotype.name = « Domain » or x.stereotype.name = « GenericProcess ») →forAll(status = false implies setStereotypeToUnused() and (containedElements-> size()>0 implies containedElements→forAll(c | c.status = false))) inv: self.elements→selectl(x|x.stereotype.name = « BusinessProcess ») →forAll( status = false implies setStereotypeToUnused() and (linkedResource-> size() > 0 implies linkedResource →forAll(l | l.status = false))) inv: self.elements→selectl(x| x.stereotype.name = « Resource ») →forAll( status = false implies setStereotypeToUnused() and (linkedProcess-> size() > 0 implies linkedProcess→ forAll(l | l.status = false))) NB : setStereotypeToUnused() : Boolean provoque un changement de stéréotype et retourne true. Il faut toutefois relever qu’à cause des limitations de l’API du MDA Toolkit, l’algorithme n’a pu être implanté aussi simplement que les expressions OCL ci-dessus le laisseraient supposer. Une étape supplémentaire16 consisterait à propager les contraintes et règles métier exprimées en OCL.

1.8.3.5 La vérification Le but de cette opération est de vérifier si toutes les entités ont été copiées du CIM au PIM. Ceci est réalisé en parcourant et en comparant les deux modèles.

1.8.3.5.1 PIM en PSM La transformation du PIM en PSM est comme précédemment divisée en trois parties distinctes la validation, la transformation et la vérification17.

1.8.3.5.2 La validation Dans le framework MDA cette opération consiste à vérifier un certain nombre de contraintes d’intégrité sur les modèles avant transformation. Comme indiqué lors de la précédente transformation, cette opération n’a pas été implantée dans notre prototype.

1.8.3.5.3 La transformation Cette opération débute par une copie des informations du modèle des entités du PIM à celui du PSM. Pour cela, la valeur de la propriété de chaque entité du PIM est propagée à aux attributs de l’entité PSM correspondante. Cependant, comme les propriétés n’ont pas le même type (booléen au niveau des entités du PIM, String au niveau des attributs du PSM), une conversion de valeur est nécessaire. Ainsi, l’algorithme de validation parcourt les activités et entités et propage la valeur des propriétés selon les règles suivantes :

• Si la propriété d’une entité était « false » (désactivé) au niveau du PIM, la propriété de l’ensemble des attributs de cette même entité devient « unused » au niveau du PSM.

16 Qui, rappelons-le, n’est pas implémentée dans notre prototype. 17 Pour le prototype, ces trois opérations sont contenues dans le plugin com.gg.erp2.

28

• Si la propriété d’une entité était « true » (actif) au niveau du CIM, la propriété de l’ensemble des attributs de cette même entité devient « optionnel » au niveau du PSM (valeur de défaut qui permet toutes les manipulations).

• Si une activité consomme une entité dont la propriété des attributs possède la valeur « unused », alors la propriété de l’activité devient à son tour « unused ». Cette valeur écrase la valeur précédente de la propriété de l’activité.

• La valeur de la propriété d’une activité est propagée à l’ensemble des attributs des entités produites par l’activité.

La dernière étape de la transformation est la génération du script SQL de manière à propager les informations du modèle d’entités du PSM aux tables de la base de données de l’ERP cible. Pour chaque entité, attribut et propriété d’attribut, la localisation de l’élément correspondant de la base de donnée du système cible doit être connue. Généralement, cette information est stockée dans une table ou un fichier de mapping correspondant au système cible choisi. Dans le cadre de notre prototype, nous nous sommes contentés de « hard coder » cette information.

1.8.3.5.4 La vérification Cette opération vérifie que toutes les entités du PIM ont été traitées lors de l’opération18.

18 Si nous avions mis en œuvre la représentation et transformation des règles métier, la vérification se chargerait aussi du contrôle syntaxique des expressions OCL.

29

2 Adonix comme plateforme spécifique Gil Gaillard & Philippe Dugerdil

2.1 Introduction Créé en 1979, le groupe ADONIX se positionne avec succès sur le marché de l'ERP Mid Market avec le progiciel Adonix® X3, ainsi que dans les grandes entreprises, en proposant des expertises et des solutions spécialisées dans les domaines de la gestion financière, la gestion de production, la logistique ou encore la gestion des ressources humaines. D'origine française, le groupe ADONIX bénéficie d'un rayonnement international en réalisant plus de 40% de son chiffre d'affaires avec ses filiales en Europe du Sud (Italie, Espagne, Portugal), aux Etats-Unis, en Amérique Latine (Argentine), et avec ses partenaires dans 27 pays. Jusqu’à présent, la HEG utilise ce progiciel comme support pour le cours d’intégration de progiciels. Adonix X3 est le progiciel sur lequel nous avons effectué l’essentiel de la partie ERP de notre travail de recherche. Notre stratégie était d’effectuer des tests avec Adonix puis de passer sur SAP pour valider la généralité de l’approche. La version d’Adonix sur laquelle nous avons travaillé porte la référence 136. Les versions suivantes utiliseront la technologie des webservice ce qui facilitera l’accès au système depuis l’extérieur. Malheureusement, une nouvelle version de cet ERP n’a été disponible que vers la fin du projet, si bien que nous n’avons pas pu exploiter cette technologie pour la réalisation de notre prototype. 2.2 Scénario Afin d’illustrer notre approche, nous avons choisi la saisie de commande de ventes qui est un cas d’école bien connu. Le premier travail est d’identifier les entités manipulées par l’ERP cible. Dans le cas d’Adonix ces entités peuvent être consultées dans le modèle de données d’Adonix X3 (fig. 22).

Figure 22: Modèle de données des ventes d’Adonix

30

Pour la définition des domaines de notre modèle CIM, nous nous sommes basés sur les modules proposés par Adonix (figure 23). Ils sont très semblables entre les différents ERP du marché (voir les cas SAP et Navision dans la figure 24). Cela nous a permis de définir les domaines de notre modèle (voir la figure 26).

Figure 23 : Modules proposés par Adonix X3

Figure 24 : Modules proposés par SAP R/3 v.4.7 et MS Navision 4.0

31

2.3 Processus de commande Ce paragraphe met en parallèle les écrans du processus de commande client sous Adonix avec les modèles de l’approche MDA et les profils UML développés. Notre but étant de justifier les choix effectués pour concevoir le prototype. A chaque écran correspondant à une étape du processus, nous établissons un parallèle avec les éléments du prototype. Il sera plus facile dès lors de comprendre sa structure et les choix que nous avons faits. Les entités métier du CIM sont inspirées du modèle de données des ventes de la figure 22. Dans ce paragraphe, nous nous concentrons sur le modèle des processus métier et des d’activités. Le point de départ pour la saisie des commandes dans Adonix X3 est de choisir un module (fig.25) ce qui correspond à notre définition de domaines. Dans la figure 26 nous illustrons les domaines que nous avons retenus pour le prototype.

Figure 25 : La page d’accueil d’Adonix X3

Figure 26 : Les domaines du prototype

32

La figure 27 montre le domaine des ventes. Une fois ce dernier sélectionné, on peut y trouver les processus associés aux ventes, par exemple la « commande ». La figure 28 présente les processus associés au domaine des ventes dans notre prototype.

Figure 27 : Le menu des ventes

Figure 28 : Processus génériques inclus dans le domaine ventes En seconde étape nous sélectionnons le processus de commande dans le module des ventes (fig. 29). Dans notre prototype, il peut être représenté soit par un processus générique (fig. 28), soit directement par un processus métier (fig. 30). Il faut remarquer que le détail des processus présenté dans les figures 29 et 30 est passablement différent. En effet, nous avons tenus à ce stade à modéliser les processus indépendamment de toute implantation particulière. Cela illustre que notre modélisation métier s’inspire des modules

33

des ERP mais n’est en aucun cas une représentation directe de ces derniers. Encore une fois, c’est au travers d’un mapping approprié qu’on transmettra les informations des modèles à l’ERP. Il est important de noter que les modèles que nous construisons pour configurer l’ERP en constituent du même coup une documentation. De surcroît, comme ces modèles sont exploités pour la configuration semi-automatique, nous sommes assurés qu’ils resteront à jour (pour autant qu’on utilise cette approche pour toute configuration).

Figure 29 : Le menu Commandes La figure 30 montre les processus métier liés aux entités du CIM. C’est par ce lien que le modèle des processus participe à la transformation du CIM en PIM. Les autres artéfacts comme les ‘’buts’’ et les ‘’personnes’’ ont des fonctions diverses : les ‘’buts’’ et les ‘’informations’’ sont présents pour clarifier le modèle, à titre de documentation. En revanche, les ‘’personnes’’, au delà de leur rôle dans la documentation, peuvent être exploitées pour configurer les profils utilisateurs.

Figure 30 : Modèles des processus métier

34

2.4 Scénario de saisie de commande sous Adonix Dès que nous nous intéressons aux étapes réelles d’un processus particulier comme la saisie de commande, les manipulations deviennent spécifiques à un ERP particulier. Il y a, à ce niveau, passablement de différences entre les divers ERP. Pour un processus donné, il y aura donc autant de modèles d’activités au niveau MDA que d’ERP cibles. Suite au lancement du processus de commande, Adonix demande de sélectionner le type de commande (figure 31). Cela lui permet notamment de sélectionner la configuration d’écran appropriée.

Figure 31 : Sélection du type de commande Après cette sélection, le système affiche l’écran de commande correspondant (fig. 32). Il est constitué, à gauche, d’une liste représentant toutes les commandes déjà saisies et, a droite, d’une fenêtre permettant la saisie d’une nouvelle commande ou l’affichage des détails d’une commande déjà existante.

Figure 32: Ecran d’une saisie de commande normale

35

Les figures 33 à 36 présentent les écrans correspondant aux différents « onglets » de la fenêtre de droite de la figure 32. Dans notre exemple, ils contiennent les paramètres d’une commande existante. Cette suite d’écrans correspond à l’enchaînement naturel des activités de saisie d’information pour une commande.

Figure 33: Onglet « Gestion » de la fenêtre « Saisie de commande »

Figure 34: Onglet « Livraison » de la fenêtre « Saisie de commande »

36

Figure 35: Onglet « Facturation » de la fenêtre « Saisie de commande »

Figure 36: Onglet « Lignes » de la fenêtre « Saisie de commande » La figure 37 représente le modèle des activités dans notre prototype. Il correspond à la séquence naturelle de saisie d’information d’une commande sous Adonix. Chaque champ des figures 33 à 36 peut être associé à un attribut de l’entité manipulée par l’activité correspondante de la figure 37. Cette association entre champ d’écran et attribut d’entité constitue le mapping dont nous avons besoin pour générer le code SQL final.

37

Figure 37: Modèle des activités de la saisie d’une commande sur Adonix X3 2.5 Configuration des écrans La technique de configuration des écrans est en général très simple pour beaucoup d’ERP. Elle passe par la mise en oeuvre d’interfaces de configuration. En revanche pour forcer une configuration depuis l’extérieur de l’ERP, c’est beaucoup plus complexe. C’est toutefois ce dont nous avons besoin pour paramétrer les écrans à partir de notre prototype. Pour obtenir le nom de la table qui stocke ces paramètres nécessaires à la configuration des champs d’écrans, il nous fallu suivre un cours d’une semaine, rencontrer les spécialistes à 4 reprises, établir plusieurs contacts téléphoniques et échanger une dizaine de courriers électroniques. Tout cela nous a pris environs 5 mois19. En revanche, il nous a été impossible de connaître la structure des données influencées par les interfaces de configuration. Afin de permettre l’avancement du projet nous avons alors décidé de rechercher l’identité de ces champs manuellement, en espérant que tôt ou tard le nom de la table serait connu20.

19 Sur un projet d’une durée totale de 8 mois ! 20 Par exemple si l’option de livraison est désactivée, nous avons du tester manuellement quels étaient les champs masqués. Cette situation est symptomatique de la réticence avec laquelle nos « partenaires » ont fourni l’information technique nécessaire à notre projet.

2.6 Recherche d’information La technique à mettre en oeuvre pour rechercher l’information sur les champs dans Adonix est la suivante. Tout d’abord, il faut positionner le curseur sur le champ et presser la touche F6 pour obtenir les informations de base sur le champ (fig. 38). Le code du champ et de l’écran sont donnés dans le titre de la fenêtre.

Figure 38 : Données du champ ’client commande’ Lorsque le code du champ et de l’écran sont connus, on peut retrouver les autres paramètres du champ et de l’écran interrogeant l’outil d’affichage des informations d’écrans (menu ‘Développement’ et sous-menus ‘Dictionnaire des traitements’ et ‘Ecrans’. Voir la figure 39).

Figure 39: Paramétrage du champ ‘client commande’ Le paramètre « client commande » (Client cde) dont le nom technique est BPCORD est visible sur les figures 32 à 36. On voit que le code de l’écran est WK2OV1 où OV1 est le type de la commande (fig.31). Après de laborieuses recherches, nous avons obtenu le nom de la table contenant les paramètres d’affichage des champs d’écran : ‘AMSKZON’. C’est elle qui fournit les données pour l’affiche des informations d’écrans présentées en figure 39. Cette table peut être consultée à l’aide des menus ‘Développement’, ‘Utilitaires’ et

38

‘Maintenance’. Ainsi, le champ ‘SAIAFF’ (saisie affichage) détermine les propriétés d’affichage du champ interrogé. On voit à la figure 40, que nous interrogeons l’écran WK2OV1 (code CODMASK) et le champ BPCORD (code CODZON). Ces deux informations constituent la clé primaire d’accès aux enregistrements de cette table. Dans l’exemple présenté, la valeur de SAIAFF est égale à 2 ce qui correspond ‘Affiché’, les valeurs 1 et 3 correspondent respectivement à ‘Saisi’ et ‘Invisible’ comme le montre la figure 39.

Figure 40: La table AMSKZON contenant les propriétés du champ ‘client commande’

2.7 Fichier de mapping Le temps imparti dans le cadre de ce projet et le retard que nous avons pris dans la recherche d’information d’Adonix, ne nous a pas permis de créer un véritable fichier de mapping21. Les éléments de ce mapping entre le modèle (PSM) – et les tables de l’ERP sont les suivants :

Modèle ERP Entité Table (pour le paramétrage des champs

d’écran dans Adonix, table AMSKZON) Attribut de l’entité Champ Propriété de l’attribut Propriété d’affichage de champ (pour

Adonix la valeur de la propriété SAIAFF) Domaine Module Processus générique, processus métier Menu et sous-menus

21 Nous l’avons ainsi « hard-codé » dans notre modèle en ajoutant aux attributs le nom technique pour Adonix séparé par le caractère ‘@’. Pour les propriétés, la correspondance est insérée directement dans le code de la transformation.

39

2.8 Validation des écrans La structure de certains ERP, dont Adonix X3, vise une indépendance par rapport aux bases de données. En particulier, les données des entités métier y sont stockées mais également les informations concernant les affichages. Ces dernières comprennent beaucoup de contraintes d’intégrité afin qu’une information soit toujours identique quelque soit l’écran où elle figure. Comme toutes les bases de données ne représentant pas les contraintes d’intégrité de la même manière, elles sont stockées dans le code de l’ERP. Cela permet de conserver cette indépendance par rapport à la technologie propre d’une base de données. Cette technique demande cependant qu’un processus de validation soit lancé après toute modification de configuration. Les contraintes sont alors compilées et stockées dans la base. Incidemment, cela offre un autre avantage du point de vue de l’éditeur: cela empêche les utilisateurs de modifier facilement la structure interne du système. Après un paramétrage d’écran, il faut donc exécuter une validation. Cette opération peut être lancée manuellement, écran par écran, mais c’est fastidieux et risqué dès lors qu’un grand nombre d’écrans doit être validé (risque d’oubli d’un écran). Une autre solution est de lancer la validation totale du système via le serveur batch d’Adonix. Mais la solution pour l’activer depuis une autre application que l’interface disponible sur Adonix X3 n’a pas été trouvée et nous ne l’avons pas obtenue de la part de l’éditeur. 2.9 Etapes du paramétrage En résumé, les étapes du paramétrage que nous allons mettre en œuvre dans l’exemple qui suit, sont représentées à la figure 41.

Sélection des éléments de la transformation

CIM to PIM

Transformation du modèle CIM

vers le PIM

Génération d’un script SQL de

mise à jour de la BD Adonix

Exécution du script sur la base

de données

Sélection des éléments de la transformation PIM to PSM

Transformation du modèle PIM

vers le PSM

Observation du résultat sur

Adonix

2.10 Exemple Ce paragraphe présente unexpliquée pas à pas afin dLes exemples de manipuld’environnement. Au départ

Validation des écrans par une

commande Adonix

40

Figure 41 : Etapes du paramétrage

exemple de mise en œuvre de notre prototype. La démarche est e pouvoir être reproduite. Des figures montrent les étapes clés. ation de XDE permettent d’illustrer les possibilités de ce type aucune entité du CIM n’est désactivée (fig. 42).

41

Figure 42: CIM dans son état initial

Etape 1 : sélectionner les processus métiers ou les domaines et processus génériques qu’on ne désire pas mettre en œuvre. Pour cela, utiliser la fenêtre des propriétés et mettre la valeur ‘false’ pour la propriété « status » (fig 43).

Figure 43: La propriété du processus ‘Etablir un devis’ est mise à ‘false’

42

Etape 2: sélectionner la transformation CIM to PIM (fig. 44) dans la barre de menu et choix des modèles concernés (fig. 45)

Figure 44: Plugin CIMtoPIM dans la barre de menu

Figure 45: Sélection des modèles impliqués dans la transformation CIM to PIM A la figure 46 nous voyons le modèle des entités PIM dans lequel le devis (entité « Estimate ») a été désactivé par la transformation, car le processus qui produit cette entité est désactivé.

Figure 46: PIM actualisé après la transformation avec le devis désactivé

La figure 47 présente le modèle des processus où on y voit les éléments désactivés.

Figure 47: Modèle des processus actualisé après la transformation Etape 3: configurer la transformation PIM en PSM. Nous le faisons en sélectionnant les valeurs des propriétés des activités dans le modèle des activités. Nous choisissons de configurer l’activité « Saisie livraison » (Delivery entry) du sous-processus « Saisie de commande » (Order entry) en indiquant que cette saisie n’est pas utilisée (« unused »). En réalité, cela ne se fait pas directement sur le diagramme comme la figure 48 pourrait le laisser supposer, mais dans la fenêtre des propriétés de l’activité sous XDE (fig. 49).

Figure 48: Sélection des propriétés de l’activité « saisie de la livraison »

43

44

Figure 49: Fenêtre des propriétés dans Rational XDE Un examen attentif de la figure 49 montre que l’activité est en fait une classe. On se rappelle que nous avons du passer par là pour contourner un bug du MDA Toolkit de XDE. Etape 4: sélection de la transformation PIM to PSM dans la barre de menu (fig. 50) et choix des modèles concernés (fig. 51)

Figure 50: le plugin PIMtoPSM dans la barre de menu

Figure 51: sélection des modèles impliqués dans la transformation PIM to PSM

45

A la figure 52 nous voyons le modèle activités dans lequel l’activité « Saisie livraison » a été désactivée, ce qui a désactivé du même coup l’entité « Livraison ».

Figure 52: modèle des activités actualisé après la transformation

Delivery

+ Address+ AddressStatus = Unused+ City+ CityStatus = Unused+ Country+ CountryStatus = Unused+ Conveyor+ ConveyorStatus = Unused

Figure 53: une partie de l’entité « Livraison » dans le PSM actuel La figure 53 représente l’entité PSM « Livraison » dans laquelle l’ensemble des propriétés des attributs est « inutilisé » (puisque l’entité a été désactivée via la désactivation de l’activité « Saisie Livraison »). Etape 5: génération d’une commande « update » SQL pour modifier la valeur de la propriété ‘SAIAFF’ (fig. 40) correspondant aux champs d’écran à modifier et ceci pour l’ensemble des écrans concernés. Nous allons l’illustrer avec le champ contenant le nom du transporteur (« Conveyor ») dont la propriété au niveau PSM est « unused » (fig. 53). Le mapping nous indique que le champ à mettre à jour possède le code BPTNUM. La correspondance entre les informations du PSM et la table à mettre à jour sous Adonix est:

PSM Adonix Entité ‘Livraison’ Table ‘AMSKZON’ Attribut ‘transporteur’ Champ ‘BPTNUM’ Propriété ‘status’ champ ‘SAIAFF’ Valeur ‘unused’ valeur 3

Remarque : la table à mettre à jour n’est donc pas celle représentant l’entité ‘Livraison’ mais celle qui gère l’affichage des champs des écrans. C’est la même pour tous les écrans. La clé primaire pour accéder au champ d’un écran dans AMSKZON est constitué des colonnes CODMSK_0 (identifiant d’écran) et CODZON_0 (identifiant de champ). Elles prennent, dans notre exemple, les valeurs WK2OV12 (écran de la figure 33) et BPTNUM (nom du transporteur) respectivement. Le script SQL de mise à jour est donc :

46

update AMSKZON set SAIAFF=3 where CODMSK_0 = ‘WK2OV12’ and CODZON_0 = ‘BPTNUM’ Pour rendre invisible le champ « transporteur » sur tous les écrans, il faudrait simplement enlever la condition booléenne sur le nom de l’écran ( CODMSK_0 = ‘WK2OV12’). Ainsi, la mise a jour s’appliquerait sur tous les écrans. Etape 6: exécution de la commande SQL sur la base de données d’Adonix. Etape 7: validation manuelle de l’écran WK2OV12 via le menu ‘Développement \ Dictionnaire traitements \ Ecrans’ 22 . Etape 8: lancement d’Adonix et affichage des informations de livraison : onglet « Livraison » de la fenêtre « Saisie de commande » (fig. 54). En comparant cette figure avec la figure 34 on remarque que le champ ‘transporteur’ a disparu ce qui est conforme au paramétrage issu de nos modèles.

Figure 54: Onglet des livraisons avec suppression du champ ‘Transporteur’

22 Comme indiqué précédemment, une technique de lancement externe et automatisable de la validation des écrans n’a pas pu être trouvée.

47

3 SAP R/3 comme plateforme spécifique Yan Betrisey

3.1 Introduction SAP est le premier fournisseur mondial de solutions logicielles e-business intégrées. Sa plateforme permet aux entreprises du monde entier de mieux communiquer avec leurs clients et partenaires, de rationaliser leurs processus et d'améliorer considérablement l'efficacité de leur chaîne logistique. Les produits et services SAP intègrent tous les pôles d'activités d'une entreprise: finances, ressources humaines, production, ventes et distribution. Fondée en 1972, la société met au service de ses clients un réseau mondial de compétences, de processus et de produits, garantissant leur réussite. Elle emploie aujourd'hui plus de 31'500 personnes dans plus de 50 pays. Près de 84'000 installations SAP ont été mises en oeuvre dans 107 pays. SAP consacre plus de 10% de son chiffre d'affaires global annuel en R&D. Capitalisant sur l'expérience des clients de la société, et considérant les suggestions tant des entreprises leaders dans leur secteur économique que des partenaires intégrateurs de l'offre SAP, 8000 développeurs sont en permanence à la pointe de la technologie. Le groupe SAP a réalisé en 2004 un chiffre d'affaires de 7,5 milliards d’Euro. Vous trouverez plus de détails pour le second trimestre 2005 ci-dessous (Fig. 55 & 56)

Revenue 2Q 2005

Revenue 2Q 2004 Change %

Change

Total 2,016 1,781 +235 +13%

- at constant currency rates +14%

EMEA 1,086 994 +92 +9%


Asia Pacific 238 209 +29 +14%


Americas 692 578 +114 +20%


Figure 55: Revenus total par régions au second trimestre 2005 (Mios EUR)

48

Q2 2005 Q2 2004 Change % Change

ERP 243 205 +38 +19%

SCM 119 107 +12 +11%

CRM 107 110 -3 -3%

SRM 37 27 +10 +37%

PLM 34 29 +5 +17%

SAP NetWeaver and other related products

36 19 +17 +89%

Total Software Revenue 576 497 +79 +16%

Figure 56: Revenus total par type de solution au second trimestre 2005 (Mios EUR)

SAP R/3, est un système informatique générique adapté à un grand nombre de situations. En particulier, il propose des solutions spécifiques pour les domaines suivants : Aerospace & Defense, Automotive, Banking, Chemicals, Consumer Products, Defense & Security, Engineering, Construction & Operations, Healthcare , High Tech, Higher Education & Research , Industrial Machinery & Components , Insurance , Life Sciences, Logistics Service Providers Media, Mill Products, Mining , Oil & Gas, Pharmaceuticals, Postal Services, Professional Services, Public Sector, Retail, Railways, Telecommunications, Utilities, Wholesale Distribution. 3.2 Scénario Comme pour Adonix, nous avons limité notre analyse au scénario de saisie de commande. Le premier travail est donc d’identifier les entités manipulées par l’ERP. Le schéma de base de données SAP est d’une part touffu et d’autre part ce scénario pourtant « basique » touche énormément de tables différentes. Donc, nous avons préféré analyser le processus de vente avec un point de vue utilisateur. Cet aperçu révèle les entités suivantes: • Client • Produit • Commande • Livraison / expédition • Approvisionnement / stock Nous avons choisi d’analyser uniquement « la saisie de commande » sans aller jusqu’à la livraison, facturation, encaissement, etc. Cependant, on peut constater que la livraison et l’expédition figurent parmi cette liste d’entités. Ceci est dû à la vérification de disponibilité de produit qui est faite déjà en amont lors de la saisie de commande dans SAP. 3.3 Processus de commande Dans SAP le scénario de saisie de commande se situe dans le sous-domaine « administration des ventes » appartenant au domaine « logistique ». SAP offre la possibilité d’atteindre un écran soit à travers une arborescence, comme l’illustre la figure 57, soit à travers un code dénommé code de transaction (TCode). En particulier, sur

49

cette figure on voit que SAP, comme Adonix, range les opérations en catégories que nous avons identifiées sous la forme de domaines dans notre outil (Fig. 26). Généralement, les codes d’environ 5 lettres se trouvant dans le texte qui suit sont des codes de transaction.

Figure 57 : Arborescence des opérations et écrans 3.4 Scénario de saisie de commande sous SAP L’écran initial pour la saisie des commandes clients (figure 58) peut être atteint via TCode va01. SAP a adopté le standard suivant : le suffixe 1 signifie écran d’affichage uniquement, 2 signifie écran de modification uniquement, 3 signifie écran d’affichage uniquement. Dans cet écran nous devons saisir le « niveau organisationnel » dans lequel se situe cette commande. C'est-à-dire, dans le cadre d’une grande société, indiquer par exemple la succursale, le canal de distribution, etc… Cette correspondance entre canal, société et entité réelle a dû déjà être choisie tout en amont, lors de l’implémentation de l’ERP. Les tâches de ce type sont dites « customizing ».

Figure 58 : Ecran initial des commandes client

Dans la figure 59, nous saisissons les informations nécessaires au début du workflow de vente. Soit au minimum ; donneur d’ordre, réceptionnaire, n° de commande, articles.

50

Figure 59 : Saisie des informations de la commande Lors de l’enregistrement de cette commande plusieurs tâches processus sont effectuées. Plus que de simples calculs informatiques, ils sont intimement liés à un processus métier. A titre d’exemple, le système va, selon les stocks et certains délais (transport, douane, etc.), calculer la prochaine date de mise à disposition (Fig. 60) pour ces articles.

Figure 60 : Calcul de la date de mise a disposition A tout moment dans le processus les personnes qui interagissent avec le processus document ont une vue du flux de documents (fig. 61) C'est-à-dire l’état dans lequel se situe la commande actuellement.

51

Figure 61 : Flux de documents Pour ce qui concerne la saisie de commandes, le scénario s’arrête là. Pour terminer le workflow et compléter le flux du document il faudrait encore définir les éléments suivants :

• Bon de livraison • Bon de sortie • Livraison • Facturation • Encaissement

Toutes les étapes ci-dessus sont situées dans des domaines et/ou sous-domaines différents. La facturation est naturellement placée dans « gestion comptable ». A noter qu’il n’y a pas un véritable enchaînement séquentiel d’écran depuis un point d’entrée unique pour un même workflow. Les écrans sont atteints à l’intérieur d’un domaine par des spécialistes de ce domaine. Toutefois, les différents écrans interfèrent via les contraintes d’intégrité. 3.5 Configuration des écrans Le « customizing » est l’ensemble d’opérations qui permet d’adapter l’ERP au processus existant dans l’entreprise avant son déploiement en production. Si, parmi les processus préconfigurés un élément ne convenait pas, il est possible de retravailler son workflow à travers la transaction « spro_admin » (Fig. 62). Ce module affiche une liste d’activités, hiérarchisé selon une logique métier. A la suite du choix d’une activité, une séquence de plusieurs écrans (assistant) propose d’entrer différentes informations, valeurs permettant de modifier le workflow ainsi que les paramètres d’affichage des champs d’écran.

52

Figure 62 : Ecran de configuration de workflow Avec cette technique nous pouvons paramétrer des écrans manuellement. Cependant, dans notre cas, il s’agit de pouvoir forcer ce paramétrage depuis l’extérieur. Ainsi, de manière similaire à ce que nous avons fait pour Adonix, nous devons trouver les tables dans lesquelles les informations des champs sont stockées. 3.6 Recherche d’information 3.6.1 Architecture du système En nous entretenant avec un technicien du centre SAP Lausanne, nous avons pris la mesure de la complexité de la gestion des écrans. Le traitement du GUI se subdivise en couches de la même manière que les autres traitements. L’architecture du SAP GUI est basée sur une machine virtuelle (VM) propriétaire, principalement écrite en C. A priori, les éléments de paramétrage des GUI sont stockés dans le SGBD. L’utilité d’une VM compilée est d’assurer une compatibilité horizontale entre les différents OS et les différent SGBD. A l’origine le SAP GUI, qui a été défini dans les années 90, est adapté pour des protocoles de type terminal via BSC / 3270 entre autres. C’est une application à part entière de type thin-client. Entre le serveur d’application et le serveur de présentation s’établit une communication permanente via le protocole DIAG (dialogue) utilisé par la VM. La logique applicative (contraintes, etc.) est remontée depuis les programmes ABAP et ensuite interprétée par la VM. En résumé, et sans tenir compte des spécificités de certains formulaires :

• Les informations sur les champs sont principalement stockés dans le dictionnaire ABAP ;

• Les contraintes ou la logique applicative (formules dans les champs, workflow, intervalle de données, etc.) se retrouvent dans le programme ABAP compilé, lui-même stocké dans la BD.

Aux dires du technicien, la tendance actuelle en termes de présentation d’information est d’aller vers une approche browser WEB. En effet, depuis les versions 4.7 un interpréteur html est directement intégré au moteur Web AS 6.40 sur lequel se basent les serveurs d’application, entre autres le serveur R/3. Ceci contraste avec la vision des versions 4.6C et inférieurs où un interpréteur ITS devait se greffer indépendamment du système R/3.

Actuellement, SAP travaille à la mise au point d’un système GUI html adapté à des normes « modernes ». Cela concerne en particulier la traduction de toute la logique applicative du coté serveur vers une logique applicative en javascript du coté html. Les Web dynpro23 font partie intégrante de cette approche. Elles sont écrites en Java et non plus ABAP ou AS Solution et sont bien plus faciles d’accès. Malheureusement le marché n'utilise des solutions html que pour certains processus bien spécifiques. De plus, cette solution est plus lente et ne remplace pas encore toutes les fonctionnalités. 3.6.2 Recherche des tables de paramétrage d’écrans SAP nous fournit plusieurs moyens pour trouver une partie des informations que nous recherchons. Citons par exemple l’option « info technique » sur un champ. (Fig. 63)

Figure 63 : Accès aux informations techniques d’un champ

A travers l’outil de développement intégré dans SAP (ABAP) nous pouvons également aller chercher des informations sur chaque champ (fig. 64). Cette technique permet de plus d’accéder à tout le code exécutable associé à cet écran.

Figure 64 : Outil de développement ABAP 23 Le Web Dynpro est un modèle de programmation independent du client pour des écrans d’application Web, liée à la technologie NetWeaver.

53

Au travers de ces deux techniques nous pouvons manuellement retrouver une grande partie des informations dont nous avons besoin. Si cela est envisageable pour l’accès à une donnée particulière, l’effort est tel que cela ne l’est plus quand s’agit de récolter toutes les caractéristiques d’un écran complet, lui-même éventuellement subdivisé en sous écrans. Nous avons entrepris une démarche auprès de SAP pour voir s’il était possible de nous mettre à disposition une procédure SQL ou programme ABAP d’accès à ces informations. Dans l’idéal, une telle procédure prendrait en entrée l’identification de l’écran et en sortie fournirait les spécificités de tous les champs de cet écran. Nos démarches se sont soldées par un échec : SAP n’a pas accepté de nous fournir une telle procédure d’accès. En suivant l’exemple de ce que nous avons fait sur Adonix, nous pourrions également envisager d’accéder directement aux tables de paramétrage dans le SGBD. Dans ce cas, le problème est d’identifier la bonne table et de lancer, suite à sa modification, une procédure de validation des données pour en assurer la cohérence. Encore une fois, nous n’avons pas été capables d’obtenir cette information de la part SAP. En d’autres termes nous n’avons pas pu obtenir l’équivalent de l’accès à la table ‘AMSKZON’ de Adonix (fig. 40). 3.6.3 Alternatives A fin de contourner le problème d’accès aux tables de paramétrage d’écrans, nous avons envisagé les alternatives suivantes :

• Utiliser la technologie SAPScript afin de faire exécuter des « macros » avancées de configuration du système. Cependant, cette technique se heurte à nouveau au problème de trouver les bonnes données dans l’arborescence. Cette démarche est par ailleurs trop manuelle et peu générique.

• Mettre en œuvre le produit GuiXT de la société Synactive (Fig. 65) qui se situe, du

côté client, entre le serveur d’application et le serveur de présentation. Sur la base d’un fichier de configuration stocké du coté client, ce programme interprète le flux de données d’affichage et permet, dans une certaine mesure, d’agir sur le GUI à plusieurs niveaux (visibilité des champs, rajout d’intervalle/contrainte, etc.). Bien entendu, cette solution n’est pas une bonne approche puisqu’on agit en surface sans modifier le paramétrage de l’ERP. Cette solution n’est donc pas généralisable.

54

55

Figure 65 : Outil de configuration GuiXT 3.7 Remarques finales sur notre expérimentation SAP Malgré nos multiples essais, il ne nous a pas été possible d’accéder de manière simple et efficace au paramétrage des écrans de SAP. A nouveau, nous avons perdu beaucoup de temps à essayer de trouver une technique d’accès pour suppléer à la rétention d’information de SAP. Aucune solution n’ayant été trouvée, nous n’avons pas pu tester notre prototype avec SAP.

56

4 Conclusion Tout au long de ce projet, le problème principal a été la rétention d’information de la part des éditeurs de progiciels et des consultants. Le fait que notre méthode puisse faciliter l’intégration a peut être été la source des réticences de la part des consultants. Par exemple, nous avons perdu beaucoup de temps pour obtenir le nom des tables contenant les paramètres de configuration des écrans d’Adonix. Pour les obtenir, nous avons réalisé un premier prototype et organisé des rencontres et présentations avec des représentants de l’éditeur et ses consultants. Nous avons tenté de convaincre ces personnes que notre approche pouvait constituer un avantage face à une concurrence de plus en plus vive, à l’heure où Microsoft et d’autres progiciels open source apparaissent sur le marché. Tout cela sans réel succès. Toutefois, après six mois, nous avons enfin reçu le nom de la table de paramétrage des écrans pour Adonix ainsi que la technique d’interrogation de ses éléments. Par ailleurs, une validation des paramètres de configuration d’un ERP doit être effectuée après chaque modification de la base de données. A nouveau, nous n’avons pas pu obtenir d’informations techniques sur la manière de lancer une validation depuis l’extérieur de l’ERP de la part d’Adonix. Dans le cadre de notre prototype, après de fastidieuses recherches, nous avons dû nous résoudre à lancer cette opération à la main. La connaissance technique a également représenté un frein à ce projet. En effet, le niveau de connaissance doit être substantiel pour pouvoir répondre à des questions touchant à la structure interne de l’ERP. Malheureusement, nous avons eu beaucoup de peine à accéder à des personnes possédant le bon niveau de connaissances techniques. A titre anecdotique, une personne qualifiée de key user à laquelle nous avons demandé une solution pour la configuration externe d’un écran SAP nous a proposé de créer une « macro » agissant directement sur l’interface de configuration proposée par l’ERP. Elle n’avait en réalité aucune connaissance de la structure interne de l’ERP. Tous ces retards ont donc largement bloqué l’avancement du développement du prototype. Aussi la mise en oeuvre proposée de notre prototype n’est-elle qu’embryonnaire. Ce dernier laisse toutefois entrevoir les réelles possibilités d’un tel outil. En résumé, si la plupart des consultants ont une bonne expérience de la configuration d’un ERP via les outils mis à disposition, beaucoup moins ont une connaissance de leur fonctionnement interne. Or c’est cette connaissance là qui nous était indispensable. Le constat que l’on peut faire est qu’un tel projet, qui touche à la technologie d’implantation d’un ERP, ne peut pas rencontrer de succès sans une collaboration réelle avec l’éditeur. Nous ne l’avons véritablement obtenue ni d’Adonix ni de SAP. Toutefois, vers la fin du projet, Adonix a soulevé un petit coin du voile ce qui nous a tout de même permis une mise en œuvre, limitée, de notre concept. Malgré ces problèmes d’accès aux informations techniques, notre travail avec Adonix montre que l’approche MDA peut être appliquée à l’intégration d’un ERP et qu’elle est prometteuse. Il montre également que les mécanismes d’extension d’UML autorisent la mise au point de représentations parfaitement adaptées à notre objectif de modélisation métier et de traduction de modèles métier en modèles implantables. Cette technique laisse entrevoir une économie de temps substantielle dans la mise au point d’une configuration correspondant à un processus métier donné. Au delà du gain de temps d’implantation, l’utilisation de MDA apporte l’avantage essentiel d’assurer que la configuration de l’ERP suit fidèlement les processus métier désirés. Par ailleurs, notre approche peut être considérée comme légère

en ce que l’arsenal théorique et technique est limité et qu’elle peut être adaptée à tout environnement de développement supportant l’approche MDA. Une validation complète de l’approche aurait demandé d’expérimenter la transformation d’expressions OCL représentant des contraintes sur les processus, activités et objets métiers. Le cadre temporel limité de ce projet, couplé avec les difficultés et écueils rencontrés ont empêché le développement de cette deuxième phase. Toutefois, nous ne voyons pas de difficulté majeure dans une telle extension. En effet, des mécanismes de traduction d’OCL en langage procédural existent et sont disponibles24. Demeure toutefois réservée la possibilité d’obtenir de l’éditeur l’information sur la localisation de ces contraintes au niveau des tables de l’ERP. Nous avons vu les difficultés d’obtention de telles informations dans le cadre de ce travail. Ce projet s’inscrit dans la ligne directrice de la filière informatique de gestion en combinant modélisation métier et système. Il a permis d’amener au laboratoire de Génie logiciel une meilleure compréhension de la structure d’un ERP. Les résultats de ce projet seront répercutés sur les cours d’intégration de progiciels, notamment par l’apport de la notions de business mapping . Au-delà du travail sur OCL, une extension de notre recherche serait l’étude de la démarche inverse de la configuration. Elle consisterait, à partir d’un ERP existant et déjà intégré, à extraire l’information de paramétrage et générer les modèles représentant sa configuration actuelle. Cela permettrait de documenter automatiquement les processus implantés et de pouvoir, le cas échéant, y apporter des modifications en comprenant l’impact de ces modifications sur le processus complet. Cette démarche demanderait toutefois de connaître encore mieux la représentation interne de l’ERP que pour un paramétrage : une difficulté rédhibitoire. Nous tenons finalement à remercier tous les partenaires de ce projet pour leur support technique ainsi que la Réserve Stratégique HES-SO, sans le financement de qui ce projet n’aurait pas pu être développé.

57

24 Il sont en particulier le résultat de recherche menées à l’Université de Dresde [Loe03].

58

5 Annexes Gil Gaillard & Philippe Dugerdil

5.1 Manipulations XDE 5.1.1 Mise à jour des profils de notre projet dans XDE et plugin de transformation Toute manipulation sur les plugins ou les profils nécessitent l’installation du MDA Toolkit dans l’environnement XDE. Pour mettre à jour les profils, il faut sélectionner et ouvrir dans XDE l’un des projets suivants25 : « CIM » pour le modèle d’entités CIM et le modèle des processus métier, « PIM » pour le modèle d’entités PIM et le modèle des activités métier. Une fois cette sélection faite, le profil peut être modifié comme un simple diagramme standard d’UML. Pour qu’un symbole dans un modèle de profil soit considéré comme un stéréotype il faut, comme valeur de l’élément « stéréotype » dans la fenêtre des propriétés, sélectionner « stéréotype ». Pour définir un nouveau stéréotype, par exemple « BusinessProcess », il faut créer une classe de nom ‘BusinessProcess’ dont le stéréotype est « stereotype ». Afin de permettre la validation par XDE de la définition d’un nouveau stéréotype, il est impératif d’introduire un commentaire pour chaque élément UML dans la fenêtre prévue à cet effet (onglet « documentation »). L’aide et le glossaire mis à disposition sont complets pour trouver tous les détails nécessaires à la mise en œuvre du toolkit MDA. Attention, le MDA Toolkit comporte un autre bug : le nom du package “Profile” dans XDE, visible dans le Model Explorer, doit être modifié pour chaque nouvelle version du modèle de définition des stéréotypes. C’est nécessaire pour permettre leur utilisation dans les modèles. La manière simple de le faire est d’introduire un numéro de version dans le nom du profil. Pour pouvoir utiliser les nouveaux profils dans un modèle il faut, après leur création, sélectionner le fichier correspondant dans les propriétés du modèle, via l’élément ‘Applied profile’ de la fenêtre des propriétés (Fig. 66).

Figure 66 : Propriétés du profil

Pour développer un nouveau plugin, le MDA Toolkit est bien structuré et l’utilisateur est guidé tout au long de la création par un wizard. La structure mise à disposition contient les trois opérations (validation, transformation et vérification) et offre une liste de tâches à effectuer pour obtenir un plugin stable.

25 Inclus dans les livrables de ce projet.

59

Les plugins existants sont stockés dans les projets « comm.gg.erp » pour la transformation du CIM au PIM, « com.gg.erp2 » pour la transformation du PIM au PSM et « com.gg.erp3 » pour la remise à zéro de tous les modèles. 5.2 Installation et génération de plugin sous eclipse Pour utiliser les plugins créés dans le cadre de ce projet, il est impératif d'installer le MDA Toolkit. Toutefois, il faut effectuer une manipulation pour contourner un bug de XDE. Le dossier ‘.metadata’ de XDE contenant les fichiers de configuration doit être copié sur la station de l’utilisateur sinon les plugins ne seront pas visibles dans la perspective de développement de plugin de XDE. Normalement, les plugins sont chargés au démarrage. Toutefois, si on veut tester un plugin dans un environnement XDE déjà ouvert, il suffit de le sélectionner et de lancer son exécution par la commande « execute as workspace ». Pour générer le plugin lui-même et qu’il soit utilisable dès le lancement de l’application, il faut sélectionner son fichier ‘.xml’ dans la perspective de développement de plugin et après un click droit, sélectionner l’exportation sous forme de fichier JAR (Fig. 67).

Figure 67 : Exportation d’un ficher JAR Après cela, le wizard guide l’utilisateur par des instructions claires. Il faut toutefois respecter des conventions de nommage pour le fichier JAR. Pour notre prototype, la convention choisie est « com.gg.XX ». Une fois le fichier JAR généré, il faut le copier ainsi que le fichier XML dans un dossier du même nom que celui du fichier JAR. Finalement, il faut sauvegarder ce dossier dans le répertoire où se trouvent les autres plugins de l’environnement.

60

6 Références [Alm04] Almeida J.P., Dijkman R., van Sinderen M., Fereira Pires L. – On the Notion of

Abstract Platform in MDA Development. Proc IEEE EDOC 2004. [Ari03] Arinze B. and Anandarajan M. - A Framework for Using OO Mapping Methods

to Rapidly Configure ERP Systems. Communications of the ACM Vol. 46, No. 2, February 2003.

[Ark02] Arkin A. - Business Process Modeling Language. November 13, 2002. www.bpmi.org.

[Bak01] Baker B. - Business Modelling with UML: The Light at the End of the Tunnel. The Rational Edge, Rational Software, December 2001.

[BPM03] BPMI.org - Business Process Modeling Notation - Working Draft (1.0) August 25, 2003. www.bpmi.org.

[Erik00] Eriksson H.-E., Penker M. – Business Modeling with UML. John Wiley & Sons, 2000.

[Gul00] Gulla J.A., Brasethvik T. – On the Challenges of Business Modeling In Large Scale Reengineering Projects. 4th International Conference on Requirements Engineering (ICRE'00), IEEE 2000.

[Har02] Harwick T. – Three Half-Truths About Custom Applications, Giga information group, November 27,.2002.

[Heb02] Heberling M., Maier Ch., Tensi T. - Visual Modeling and Managing the Software Architecture Landscape in a large Enterprise by an Extension of the UML. Second Workshop on Domain Specific Visual Languages, OOPSLA, 2002.

[Heu01 Heumann J. – Introduction to Business Modeling Using the Unified Modeling Language (UML). The Rational Edge, Rational Software, March 2001.

[Hub02] Hubert R. – Convergent Architecture. John Wiley & Sons, 2002. [Fra03] Frankel D.S. – Model Driven Architecture. OMG Press. Wiley Publishing,

2003. [IDS03] IDS Sheer AG. _ From Process Models to Application, ARIS P2A. White

Paper, March 2003. [Jac85] Jacobson I., Ericsson M., Jacobson A. - The Object Advantage. Business

Process Reengineering with Object Technology. Addison-Wesley, 1995. [Jac99] Jacobson I., Booch G., Rumbaugh J. – The Unified Software Development

Process. Addison-Wesley, 1999. [Jon04] Johnston S. - Rational UML Profile for business modeling. IBM

Developerworks. 30 June 2004. www-128.ibm.com/developerworks/rational/ library/5167.html

[Kaz04] Kazhamiakin R., Pistore M., Roveri M. - A Framework for Integrating Business Processes and Business Requirements. Proc. IEEE EDOC Conference, 2004.

[Kin03] Source: Kinikin E., Bartels A. - Enterprise Applications: Even New Architectures May Not Bring Market Back to Life. Forrester Research, Sept. 26, 2003.

[Koe03] Koehler et al. - A Model Driven Transformation Method. Proc. IEEE EDOC Conference, 2003.

[Lin02] Linvald J., Østerbye K. - UML tailored to an ERP framework. Second Workshop on Domain Specific Visual Languages, OOPSLA, 2002.

[Loe03] Loecher S., Ocke S. - A Metamodel-Based OCL-Compiler for UML and MOF. Proceedings, 6th International Conference on the Unified Modeling Language and its Applications, UML 2003, volume 154 of ENTCS. Elsevier, Oct. 2003.

[MDA03] Miller J., Mukerji J. - MDA Guide Version 1.0. omg/2003-06-0. OMG, June 2003.

61

[Ng02] Ng P.-W. - Effective Business Modeling with UML: Describing Business Use Cases and Realizations. The Rational Edge, Rational Software, November 2002.

[MOF02] Meta Object Facility (MOF) Specification. Object Management Group, April 2002 (www.omg.org).

[OCL03] UML 2.0 OCL Specification. Ptc 03 -10 -14, Object Management Group, October 2003 (www.omg.org).

[Rol01] Rolland C., Prakash N. – Matching ERP System Functionality To Customer Requirements. Proc. Fifth International Symposium on Requirement Engineering, IEEE RE’01, 2001.

[Rum04] Rumbaugh J., Jacobson I., Booch G. – UML 2.0 Guide de référence. Campus Press, Pearson Education, 2004.

[Sch00] Scheer A.-W., Habermann F. – Making ERP a Success. Communications of the ACM, Vol 43, N°4, April 2000.

[Sha01] Sharp A., McDermott P. - Workflow modeling. Artec House Inc, 2001. [Tho02] Tomas J.L. - ERP et progiciels de gestion integrés (ERP and Packaged

Business Software). Dunod, Paris, 2002. [UML03] Unified Modeling Language Specification, Version 1.5, OMG, March 2003. [Van00] van Everdingen Y. van Hillegersberg J., Waarts E. – ERP Adoption by

European Midsize Companies. Communication of the ACM, Vol 43, N°4, April 2000.

[Vog02] Vogt Ch. - Intractable ERP. A comprehensive Analysis of Failed Enterprise Resource Planning Projects. ACM SIGSOFT, Software Engineering Notes, Vol 27, N°2, March 2002.

[Weg03] Wegman A., Preiss O. – MDA in Enterprise Architecture ? The Living System Theory to the Rescue. Proc. IEEE EDOC Conference, 2003.

[VER02] Verheecke B., Van DER Straeten R. – Specifying and Implementing the Operational Use of Constraints in Object-Oriented Applications. TOOLS Pacific 2002.

[WAR03] Warmer J., Kleppe A. - The Object Constraint Language Second Edition Getting Your Models Ready for MDA, Addison-Wesley 2003

Documents

Intégration d’un ERP guidée par les modèlescampus.hesge.ch/dugerdilp/_private/Rapport-isnet89.pdf · Intégration d’un ERP guidée par les modèles (Model Driven ERP Implementation)