Le rapprochement de modèles métier et techniques nécessite des liens exploitables entre eux. Dans cette optique, et comme nous l’avons expliqué dans le chapitre précédent, notre approche propose d’utiliser les informations sémantiques et syntaxiques extraites de ces deux niveaux d’abstraction, chaque niveau pouvant être exprimé selon plusieurs formalismes. Afin de faciliter le traitement de ces informations, i.e. la réconciliation entre les activités métier et les services techniques, nous avons défini un méta-modèle séman- tique pivot. Les informations sémantiques et syntaxiques correspondant aux modèles décrivant les activités métier et les services techniques peuvent alors être exprimées en utilisant ce profil pivot. Cette section se propose d’étudier les besoins liés à ce profil sé- mantique pivot et de proposer un méta-modèle répondant à ce besoin, indépendamment des standards utilisés de part et d’autre par les partenaires.
II.2.1 Analyse du besoin
Le profil sémantique que nous souhaitons définir a pour but de faciliter la réconci- liation de services, servant de pivot entre les activités métier et les services techniques. Il doit donc contenir assez d’information pour permettre au moteur de réconciliation de différencier les services entre eux et de proposer à l’utilisateur celui (ou ceux) correspon- dant à l’activité métier attendue. On considèrera alors que plus deux profils sémantiques sont proches, plus l’activité métier et le service technique correspondant le sont.
Bien que la granularité des concepts en jeu soit différente entre les niveaux d’abs- traction, la nature des éléments à rapprocher est semblable. On recherche d’un coté une activité répondant à un besoin (dont le comportement interne est potentiellement décrit) agissant sur des entrées/sorties métier et de l’autre des services techniques répondant à des besoins (dont le comportement interne peut aussi être décrit suivant le formalisme utilisé) et traitant des données techniques. On distingue donc trois parties distinctes, communes aux deux niveaux d’abstraction : les entrées, la fonction (ce que propose le service ou ce qu’est attendu pour l’activité) et les sorties. Chaque partie doit pouvoir être associée à un nom syntaxique et à un ou plusieurs concepts sémantiques permettant une description complète et un traitement ultérieur.
Concernant les informations sémantiques associées aux fonctions, nous souhaitons proposer un profil capable de fournir les informations nécessaires à une composition de service « 1-n » ou « n-m ». Il peut donc être intéressant d’ajouter à notre profil un méca- nisme de description du comportement interne, composé d’une ou plusieurs séquences de fonctions unitaires (comme on peut le voir dans des formalismes tels que WSMO-Lite, présenté plus loin), afin de rendre ce mécanisme réutilisable dans des contextes plus complexes. Ici aussi, la fonctionnalité recherchée, ainsi que chaque activité unitaire de la description interne doit pouvoir être associée à un ou plusieurs concepts sémantiques
ainsi qu’à un nom syntaxique.
Concernant les entrées/sorties, seule une description des éléments (documents ou données) la composant semble nécessaire. Il peut cependant être intéressant, afin de pouvoir exprimer des données métier complexes, que le méta-modèle pivot permette une description hiérarchique de ces entrées/sorties. Ce profil pivot n’a pour but que de faire le lien entre les deux niveaux d’abstraction et ne servira pas à la réconciliation de données (qui elle utilisera les concepts techniques pour faire le lien entre les formats et unités de données). Il contiendra donc principalement des concepts provenant de l’ontologie de domaine. La réconciliation de données, qui elle se basera aussi sur les concepts techniques, se basera directement sur les descriptions de services, plus précises pour décrire les formats de données et surtout décrite dans un même méta-modèle pour tous les services (en XML Schema, potentiellement annoté sémantiquement).
I1 I2 Service/Activity O2 Internal behaviour O3 O1
Figure II.2 – Représentation des besoins en sémantique pour le modèle pivot La Figure II.2 résume nos besoins concernant la couverture de notre profil sémantique pivot. Trois parties sont nécessaires : les entrées, les sorties et la fonction qui peut être détaillée sous la forme de séquence(s) de fonctions unitaires. Les entrées/sorties peuvent être composées d’un ou plusieurs éléments distincts, exprimés ou non sous une forme hiérarchique. Ce profil doit être compatibles avec les différents méta-modèles utilisés par l’utilisateur, aussi bien pour les annotations des processus métiers (voir Section II.3) que des services techniques (Section II.4.2.3).
II.2.2 Présentation du profil sémantique adapté
Sur la base de l’analyse du besoin présentée ci-dessus, un méta-modèle du profil sémantique a été développé, représenté en Figure II.3 sous la forme d’un diagramme de classes UML, afin de rester indépendant de toute implémentation. On y retrouve les différents éléments de la Figure II.2.
Chaque profil, correspondant suivant le cas à une activité métier ou à une opéra- tion d’un service technique, est représenté par la classe SemanticProfile. Le profil est ensuite potentiellement composé d’une fonction, d’une entrée et d’une sortie. La fonc- tion, décrite sous la forme d’une SemanticFunction peut être décomposée au besoin en fonctions unitaires (UnitFunction). L’entrée et la sortie peuvent être décrites sous la forme d’une hiérarchie d’éléments (SemanticElement) dont certains peuvent être op- tionnels. Les différentes classes de représentation sémantique sont composées d’un nom syntaxique et d’un ensemble de concepts sémantiques, issues de l’ontologie de domaine, associés sous la forme d’une liste d’URI. Chaque profil peut être associé à un partenaire
Chapitre II. Annotation sémantique des modèles SemanticProfile SemanticProfile SemanticElement required : bool Partner SemanticFunction InternalBehavior UnitFunction SemanticPart name : string concepts : List< URI>
1. .* 0. .* belongs to 0. .1 0. .1 function 0..1 0. .1 follows 0..1 0..* child 0. .* 0..1 input 0. .1 0..1 output 0. .1 Nicolas Boissel 1 of 1 26.08.2012
Figure II.3 – Représentation UML du profil sémantique
de la collaboration, responsable de l’activité ou du service. Ce partenaire peut être le médiateur lui-même.