Architecture SOA (Architecture Orientée Services ). Quelle source de valeur pour le Groupe Terrena?

2.6.3.4 Modélisation du Diagramme d'activités à partir du BPMN

Le diagramme d'Activités ressemble beaucoup au diagramme BPMN car il illustre l'enchainement ordonné des différentes activités du processus. Il utilise des unités organisationnelles, des « partitions », afin de classer les activités par participant, et des opérateurs de choix qui permette de définir des branches d'activités spécifiques à certains contextes. Le début et la fin du diagramme d'activité sont traduits par des opérateurs d'évènements. Entre ces deux objets, s'enchainent un ensemble d'activités, de choix, d'unions, de bifurcations, de flux de contrôle, de commentaires et ce, pour un ensemble de partitions. La génération d'un diagramme d'activité se fait donc sur la base d'un formalisme très proche du BPMN :

q L'élément BPMN « typé » qui ne se retrouve pas à l'identique dans le diagramme d'activité:

q Correspondance sémantique avec le diagramme d'Activités pour les autres éléments BPMN.

Illustration 108 : Diagramme d'Activités obtenu à partir du BPMN

2.6.3.5 Synthèse de la modélisation UML 2.0 à partir du diagramme BPMN

Ce qui caractérise les diagrammes UML est leurs fortes dépendances les uns vis-à-vis des autres. Pour que la cohérence soit garantie entre les branches métier et logiques de la démarche MDA, la conception doit pouvoir être réalisée sur la base de règles de transformation inter-diagrammes. Cela revient à impacter le méta modèle sur la base de règles de transformation propre à chaque « passerelle » BPMN - diagramme UML concerné (par exemple : BPMN - Diagramme de Classes, BPMN - Diagramme de Séquences etc ...). Cet impact est variable selon l'affinité sémantique entre le modèle source (BPMN) et le modèle cible (un des diagrammes UML). Il apparaît alors un début de concept d'interopérabilité sémantique associé aux modèles. Il s'ajoute aux autres types d'interopérabilités propres à la SOA : ceux des outils et des données.

Interopérabilité des Modèles

SOA

Interopérabilité technique

Interopérabilité des Données

Illustration 109 : SOA, une architecture interopérable

Cependant, ce concept est loin d'être abouti, car d'une part, l'isomorphisme n'est pas complet et d'autre part, les diagrammes générés peuvent parfois paraître pauvres : les attributs des classes, les règles de gestion n'apparaissant pas dans le BPMN, et ne figurent pas dans les diagrammes découlant du modèle BPMN. Il faut alors revenir sur ces diagrammes consécutifs et les enrichir pour obtenir un niveau d'information satisfaisant. C'est pour cette raison que dans ce mémoire, le terme d' « ossature » est souvent utilisé, ceci faisant appel à un besoin d'enrichissement à posteriori. Néanmoins, des moteurs de règles (aussi appelés BRMS) apparaissent dans les offres du marché. Nul doute que BPM et BRMS^151(*) trouverons rapidement des axes de convergence afin d'offrir des solutions permettant d'offrir une vue métier exhaustive. Pour ce qui est de la problématique des attributs, il faut maintenant explorer la modélisation des entités à partir desquelles sont constitués les messages : Tiers, Rib, Adresse, Solde ... puis impacter les règles de gestion au sein de cette modélisation.

* ¹⁵¹ BRMS (Business rules management system) : système de gestion des règles métier.