Transformation des dAC vers owl-s

Transformation des DAC vers owl-s

Introduction

Après avoir présenté dans l’état de l’art la modélisation avec UML, les ontologies des services web OWL-S et la transformation de modèles, nous présentons dans cette section une approche qui consiste à générer automatiquement des ontologies OWL-S à partir des diagrammes UML (Diagramme d’activité). Notre objectif est de faire un passage d’un diagramme UML, à savoir le diagramme d’activité vers une ontologie OWL-S. Cet objectif va être réalisé par la conversion des termes de diagramme d’activité vers des concepts d’ontologie OWL-S. Cette ontologie permet de représenter et intégrer d’une façon cohérente les connaissances des diagrammes UML. Nous montrons dans ce chapitre les différentes phases de transformation de diagramme d’activité vers l’ontologie OWL-S, les outils de développement, les règles de transformation, la réalisation de cette transformation et comment elle fonctionne.

Transformation de DAC vers OWL-S

Vue d’ensemble

Les diagrammes d’activités ont été utilisés largement pour la modélisation des processus métier et des services web. Ils ont cette facilité qui permet de satisfaire les différents niveaux de modélisation des processus métiers, depuis la description générale jusqu’à la conception détaillée. En revanche, le langage OWL-S a été aussi utilisé pour modéliser les services web, elle fournit des constructions pour indiquer des informations sur la façon de composer et d’accéder à des services web. Les deux formalismes ont des correspondances : Description de Méta modèle : Ce méta modèle se compose de plusieurs classes et des relations entre elles telles que :  Une « Activity » se compose au moins de trois (03) « Node », deux (02) « Edge » et zéro (0) ou plusieurs « Swimlane ».  Une « Activity » a exactement un « InitialNode » et zéro (0) ou plusieurs « Paramater ».  « InitialNode », « FinalNode », « MergeNode », » DecisionNode », « ForkNode », « JoinNode » et « ActionNode » sont des « Node »  Le « Target » d’un « Edge » est un « Node ».  La  » Source « Edge » est un « Node ».  Les « Outgoing » d’un « Node » sont des « Edge ».  Les « Incoming » d’un « Node » sont des « Edge ».  Une « ActionNode » a plusieurs « Pin ».  « InputPIN » et « OutputPIN » sont des « Pin ».  Un « Node » peut être appartient à un « Swimlane ».  Un « Swimlane » contient un ou plusieurs « Node ». 

Description de Méta modèle

 Ce méta modèle se compose de plusieurs classes et des relations entre elles telles que :  Un « Service » présente par un « ServiceProfil », décrit par un « ServiceModele » et elle est supportée par un « ServiceGrounding ».  un « Profil » est un « ServiceProfil ». Il spécifie les fonctionnalités offertes par le service qui sont représentées par des « Inputs », « Outputs », « Condition », « Result » et « Parameter ».  Un « Process » est un « ServiceModele ». Un « Process » peut être « Simple », « Atomic » ou « Composite ». La classe « Process » a des relations avec les classes : « Inputs », « Outputs », « Condition », « Result » et « Parameter ».  Un « Composite » est composé d’une seule « ControlStruct ».  « Sequence », « Choice », « If_then_else », « Repeat-while », « Repeat-until », « Split-Join », « Split » et « AnyOrder » sont des « ControlStruct ».  « InputBinding » et « OutputBinding » sont des « Binding ».  Un « ServiceGrounding » indique comment accéder correctement au service.  Un « WsdlGrounding » est un « ServiceGrounding ».  La classe « WsdlGrounding » a une association « HasAtomicProcessGrounding » avec la classe « WsdlAtomicProcessGrounding ».  La classe « WsdlAtomicProcessGrounding » a des attributs suivants : « wsdlService », « wsdlPort », « wsdlInputMsg » et « wsdlOutputMsg ». Elle a une association « owlsProcess » avec la classe « AtomicProcess », une association « wsdlOperation » avec la classe « WsdlOPerationRef », une association « wsdlOutput » avec la classe « WsdlOutputMessage » et une association « wsdlInutput » avec la classe « WsdlInputMessage »

Phases de transformation 

Dans notre étude, nous avons utilisé l’approche à base de Visiteurs, on transforme un modèle (DAC) vers texte (OWL-S) sous forme d’un fichier (.owls) pour générer un code OWL-S. Cette approche a deux mécanismes : une pour le parcours du modèle (chargement et navigation) et l’autre pour la génération du code. En général, on peut représenter notre transformation par le schéma suivant :