• Aucun résultat trouvé

2. LES ONTOLOGIES

2.1. L’intégration des ontologies

2.1.1. Le travail de référence

Les ontologies, qui définissent une terminologie pour partager un vocabulaire commun au sein d’un domaine, sont aujourd’hui largement utilisées pour répondre à ce besoin. Il est essentiel de disposer d’une sémantique riche des services afin de faciliter la communication et la compréhension des intervenants qui partagent ses activités dans un domaine particulier.

Dans le contexte des services, les ontologies (buts, produits, processus et rôles) proposées par Guzélian [Guzélian et al., 2004][Guzélian, 2007] définissent une terminologie réutilisable et partageable par les fournisseurs des services « méthode » (ingénieurs de méthodes) et par les clients qui les utilisent (concepteurs/développeurs de SI). Les ontologies permettent aussi d’enrichir la sémantique de la description des services. Ce niveau sémantique joue un rôle essentiel dans l’automatisation de la recherche/sélection, dans l’adaptation et dans la composition de services.

Les ontologies définissent un ensemble de termes qui seront utilisés pour définir les valeurs d’un concept au moment de la spécification de services particuliers. Les termes d’une même ontologie peuvent être utilisés dans les différentes parties de la description d’un service « méthode ». Par exemple, l’ontologie des produits fournit une typologie des artéfacts de SI qui peuvent intervenir dans la description du contexte et dans la définition des ressources d’un même service.

L’utilisation des ontologies de Guzélian [Guzélian et al., 2004][Guzélian, 2007] dans la spécification des services repose sur un mécanisme qui permet de faire le lien entre le modèle de services, les services « méthode » et les ontologies de l’ingénierie des systèmes d’information. Ce mécanisme est illustré par la figure 49. Le modèle de services est utilisé par l’ingénieur de services « méthode » pour spécifier des services. Au contraire, les ontologies sont partagées à la fois par l’ingénieur de services « méthode » (fournisseur de services) et le concepteur de systèmes d’information (consommateur de services). Par exemple, l’ontologie des buts peut à la fois être utilisée au moment de la conception des services pour définir le but d’un service et au moment de la recherche de services pour formuler les requêtes.

FIGURE 49. MECANISME D’UTILISATION DES ONTOLOGIES [GUZELIAN, 2007]

Le modèle de services est constitué de concepts décrits par des diagrammes de classes UML. Il propose un ensemble structuré de concepts pour spécifier les services « méthode ». Certains concepts du modèle de services peuvent être décrits dans une ontologie de l’ingénierie des SI. Les ontologies

(dénotés comme « Onto » dans la figure 49) sont composées de concepts, de termes et de relations entre les concepts et les termes. Dans le modèle de services, un concept défini par une ontologie de l’ingénierie des SI est référencé par : (nom de l’ontologie) nom du concept. Par exemple, le concept de but décrit dans l’ontologie des verbes qui décrivent les intentions spécifiques pour la gestion de modèles est noté comme « Lbut » But dans le modèle de services.

La spécification d’un service « méthode » particulier est une instanciation des concepts du modèle de services. Au moment de la définition du service « méthode », la valeur d’un concept du modèle de services est définie par un terme appartenant à une ontologie de l’ingénierie des SI. Dans un service « méthode », un concept instancié par un terme de l’ontologie est référencé par le nom du terme. Par exemple, le concept de but peut avoir pour valeur le verbe « construire » (figure 50). Cependant, ce concept peut avoir d’autres termes comme développer, créer...

La figure 50 montre un exemple d’utilisation de l’ontologie de verbes. Notons que le concept « but » de la définition de la partie identifiant du modèle de service SO2M est décrit pour le concept « verbe » dans l’ontologie de buts. Cette définition permet de standardiser et classifier l’utilisation des concepts pour spécifier les buts et permet d’établir un vocabulaire commun entre les fournisseurs et les concepteurs.

FIGURE 50. EXEMPLE D’UTILISATION DES ONTOLOGIES [GUZELIAN, 2007]

L’utilisation des ontologies de Guzélian dans la spécification des services est un mécanisme très intéressant qui permet de faire le lien entre le modèle de services et les concepts du domaine de l’ingénierie des systèmes d’information. Cependant, nous considérons très important le fait d’avoir un modèle de services lisible (complèt et uniforme) où on intègre la spécification des services et les termes du domaine de systèmes d’information. La section suivante présente le patron Concept –

Term, un mécanisme utilisé pour réaliser l’intégration des ontologies dans les spécifications de nos modèles de services.

2.1.2. Le patron Concept – Term

Nous avons énoncé au début de cette section que l’utilisation des ontologies nous semble tout à fait pertinente pour disposer, dans les environnements à base de services, d’un vocabulaire commun entre fournisseurs et clients. Notre approche consiste à les intégrer dans les différents méta-modèles correspondant aux trois niveaux d’abstraction de manière à disposer de méta-modèles complets et uniformes.

Pour intégrer une ontologie, dans nos modèles de service, nous nous appuyons sur le principe de catégorisation. La catégorisation permet de classer des concepts selon des propriétés communes. Dans ce contexte, le patron générique Item-Description proposé par [Coad, 1992] (voir Annexe F) ainsi que le patron Type-Object de [Johnson et al., 1997] (voir Annexe G) permettent tous les deux de répondre à ce besoin. Nous nous sommes inspirés du patron Item-Description par le fait que la classe ItemDescription détient les valeurs des attributs qui peuvent s’appliquer à plus d’un objet de type Item. Par rapport au patron Type-Object, nous sommes intéressés par le fait que les instances d’une classe doivent être groupées selon des attributs et/ou comportements communs.

La figure 51 présente une adaptation des patrons Item-Description, Type-Object auquel nous avons rajouté deux classes énumérées pour ajouter les termes et les concepts utilisées dans le patron. Nous appellerons ce patron : Patron « Concept – Term ».

FIGURE 51. PATRON CONCEPT-TERM

Chaque concept de l’ontologie est représenté par :

1. Une valeur du type énuméré « EnumConcept », par exemple : cA.

2. Une instance de la classe « Concept » dont l’attribut « name » est valué par une valeur du type énuméré « EnumConcept », par exemple : objcA.

Chaque terme de l’ontologie est représenté par :

1. Une valeur du type énuméré « EnumTerm », par exemple : t1.

2. Une instance de la classe « Term » dont l’attribut « name » est valué par une valeur du type énuméré « EnumTerm », par exemple : objt1.

Chaque instance de la classe Concept conserve une référence vers ses instances de la classe Term via le rôle term. Inversement, chaque instance de la classe Term pointe vers son Concept.

2.1.3. L’utilisation du Patron Concept – Term dans les méta-modèles de services

La figure 52 montre la vision globale d’utilisation du patron Concept – Term dans les méta-modèles de services de notre approche. Au moins une classe du méta-modèle de services est associée à la classe Term de l’ontologie pour utiliser ses éléments énumérés.

FIGURE 52. UTILISATION DU PATRON CONCEPT – TERM