La capture des informations pose un problème dû essentiellement à l'hétérogénéité des acteurs qui vont créer le système. Il fallait donc proposer une méthodologie qui permette une communicabilité importante et des facilités d'utilisation telles que toutes les populations d'intervenants puissent se retrouver face à des mêmes modèles dans un langage universel. Le seul moyen que tous les hommes aient en commun c'est le langage naturel. Toute phrase peut se ramener à la forme sujetverbe-complement. Cette forme peut être facilement formulée par des prédicats binai-res. Pour cela, Nijssen [3,13] a mis au point une méthode appelée Niam pour la construction de schémas conceptuels de base de données en utilisant le modèle relationnel binaire. Son principe est d'exprimer ce que l'on veut à l`aide de phrases simples (indécomposables) sans perte d'informations. Cette méthode a prouvé une puissance sémantique dans la capture des données nécessaires à partir du domaine de l'U°D (Univers de Discours). L'un des facteurs de sa puissance est la possession d'une procédure nommé CSDP permettant de passer des rapports de sortie et/ou formulaires d'entrée en un schéma conceptuel [15]. Ce travail a pour objectif de proposer une démarche nommée UDDPO (Uml Diagrams Design Procedure based Ontology) similaire à celle de la procédure CSDP de Niam pour obtenir des modèles orientés objets d'UML (diagramme de classes et diagramme d'objets) [1,2,11,14,16] à partir d'une partie de l'U°D (tableaux, rapports,…), tout en bénéficiant de la puissance de cette procédure dans le raffinement des modèles de structures d'UML.
L'idée de base de la CSDP [15] est d'exprimer les concepts du schéma conceptuel (SC) en phrases élémentaires du langage naturel. L'approche fondamentale est de construire une conception incrémentale en commençant avec des exemples spécifiques et puis suivre une procédure bien définie utilisant des diagrammes visuels significatifs facilement peuplés pour des buts de validation. On obtient en dernier un schéma conceptuel final de Niam. La CSDP est présentée comme une séquence de neuf étapes: La procédure débute avec l'analyse des exemples d'informations qui vont constituer les entrée au système d`information. Fondamentalement, les trois premières étapes sont concernées par l`identification des types idées (stockées ou dérivées). Dans les autres étapes, on ajoute les contraintes aux types d`idées stockées. Tout au long de cette procédure des vérifications sont accomplies pour s'assurer qu'aucune erreur n'a été faite.
La démarche proposée est inspirée de la procédure CSDP et basée sur un ensemble de règles proposées dans les travaux de Halpin [4][5] [6][7] [8] et enrichie par l'utilisation de l'ontologie de domaine.
Les Uses cases de la notation UML ont pour objectifs de modéliser un processus, capter les différentes spécifications. D'une façon analogue à la CSDP, on commence par les exemples familiers de l'univers de discours. Ces Data Uses cases peuvent être souvent augmentés par des informations de différents types (tables, formes, graphiques, diagrammes). Donc, cette étape consiste à la verbalisation de ces exemples en phrases simples (idées élémentaires).
La vérification consiste à se poser les questions suivantes :
Est-ce que les relations sont bien identifiées ? Est-ce que les relations peuvent être divisées en idées plus petites sans perte d'informations ?
Cette étape consiste à dessiner un diagramme de classes à partir des relations élémentaires exprimées. Tout d'abord, on présente un diagramme d'occurrences à partir des relations élémentaires (idée élémentaire) au sens de Niam [12,13,15], on aura le diagramme d'occurrences suivant:
Dans cette étape, on ajoute les contraintes de multiplicité dans le diagramme de classe obtenu, à partir des règles de passage présentées dans [8,9] (voir Fig. 6) et de la population de départ. On peut également proposer d'autres types de contraintes si elles sont présentées en Niam ou déduites à partir de l'univers de discours, à l'aide des contraintes d'UML {Complet, Incomplet, Disjoint, …}.
Cette étape vérifie que les relations ont un ordre exact. Si nous sommes plus précis dans les étapes précédentes, alors cette étape n'est pas exigée. On vérifie l'ordre d'une association (type idée au sens Niam) de telle sorte qu'elle ne soit ni trop longue, ni trop courte par rapport à ce qu'elle doit être. Trois démarches sont possibles: 1. Utiliser le bon sens ou la connaissance antécédente de l'U°D pour décider si l'information sera perdue par une division d'association. 2. Utiliser les règles de division de la petite clé.
Dans la notation UML, il n'existe pas une syntaxe pour exprimer qu'un rôle est impératif. Alors, on exprime ça par une contrainte textuelle ajoutée comme note.
Une agrégation représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l'autre extrémité. La contribution de l'expert de l'U°D est importante pour déterminer les relations d'agrégations entre les classes. La composition est un cas particulier de l'agrégation. Elle implique une contrainte sur la valeur de la multiplicité du coté de l'agrégat. : elle ne peut prendre que les valeurs 0 ou 1. La composition et les attributs sont sémantiquement équivalents. La notation par composition s'emploie dans un diagramme de classes lorsqu'un attribut participe à d'autres relations dans le modèle [2,11,14]. A partir de cette définition, on peut noter que, si un attribut participe dans une relation dans le modèle et que sa participation est validée par une population du domaine, alors il devient une classe composite.
Pour identifier les relations de généralisation entre les différentes classes, on utilise soit :
-Notre intuition et l'assistance de l'expert de l'U°D, -Une technique connue par l'analyse de la matrice de sous typage [15]. Supposons qu'on a une entité A et qu'on veut lui appliquer le sous typage, on commence par diviser A en groupes où chaque membre d'un groupe a exactement le même rôle enregistré. Les détails enregistrés pour chaque membre de A forment l'enregistrement du modèle. Plusieurs groupes doivent avoir des modèles différents. Ayant partitionné A en groupes sur des modèles de base, nous les affichons à l'aide d'une matrice Partitions/Détails. Employé Dept Fonction Supervis. Sit fam N° Tel Année Mariage Nbre Enf Allocat ($) (1) Pour la sémantique de la conception obtenue, minimiser l'intervention de l'expert de domaine, nous utilisons l'ontologie de domaine. L'identification des relations de l'univers de discours à travers de l'ontologie de domaine se base sur la similarité des classes de modèle et les concepts (ou classes) de l'ontologie. Ainsi, une classe de modèle est similaire à une classe de l'ontologie [13], si :
-Les deux entités (classe et concept) possèdent le même nom.
-Les deux entités (classe et concept) possèdent les mêmes attributs.
-Ils ont en commun un certain nombre d'attributs. Notons ici que l'enrichissement du schéma conceptuel par les concepts de l'ontologie est relatif à l'intervention du concepteur validant les résultats. Dans notre exemple, nous utilisons une ontologie de domaine d'une organisation qui décrit le domaine d'une personne et ses intérêts [14]. Les classes et les propriétés de cette ontologie sont : Personne Employé -Nom -Date de naissance -Sexe -Age -Photo -Adresse Organisation Repos
Les relations sont: Membre de (Personne, Groupe social) Travaille a (Employé, Organisation) Assurer (Employé, Fonction). Avec l'utilisation de l'ontologie du domaine, la description de la classe employé est plus détaillée et le diagramme est enrichi avec une nouvelle classe 'groupe social' et une nouvelle association 'est membre de'.
Dans cette étape on spécifie les contraintes lexicales sur les attributs, sur la base de la population de domaine ou on utilise l'avis de l'expert de l'U°D. Dans notre exemple, l'attribut nom de la classe Employé, par exemple, est une chaîne de taille de 20 caractères. Alors, on ajoute le type chaîne à coté de cet attribut. Les restrictions sur les associations (clés) peuvent être spécifiées par des qualifications.
Les contraintes d'égalité, d'exclusion et de sous ensemble peuvent être appliquées sur les associations. La syntaxe d'UML permet de représenter les contraintes ou-exclusif, disjoint, incomplet, complet, …, sur les associations.
Cette étape consiste à que le schéma conceptuel est consistant avec les exemples originaux , qu' il n'est pas redondant et qu'il est complet. On distingue deux étapes :-On vérifie si les contraintes exprimées sont validées par la population initiale, sinon on effectue des modifications nécessaires.
-On élimine la redondance des classes, des attributs et associations.
Pour élaborer des diagrammes UML sémantiquement riche et de qualité meilleure, nous avons proposée dans cet article une approche hybride (ascendante et descendante) faisant intervenir des sources sémantiques : de bas niveau d'abstraction (i.e. des exemples d'un système existant : tables, états…) et de haut niveau d'abstraction (i.e. l'ontologie de domaine). La capture de la sémantique dans notre démarche s'est matérialisée par plusieurs façons, à savoir :La reprise de l'existant par des exemples significatifs de l'univers de discours, les connaissances de l'expert de domaine, l'utilisation d'un langage pseudo naturel pour assurer une meilleure communication entre les intervenants (l'expert, l'utilisateur et le système),utilisation de l'ontologie de domaine. L'usage des ontologies dans le processus de spécification des systèmes d'information est une discipline récente. Il permet de faciliter le processus d'identification des besoins du système et de comprendre les liens sémantiques de ses composants et de réduire considérablement le temps nécessaire pour l'analyse conceptuelle. Le processus de notre démarche appelée UDDPO (UML Diagram Design Procedure based on Ontology) se déroule en dix étapes successives, il commence par la verbalisation des exemples de l'univers de discours et se termine par la génération du schéma conceptuel en UML.
L'approche actuelle permet d'élaborer les digrammes de classes, d'objets et de cas d'utilisation UML. Elle pourrait être étendue pour élaborer les autres diagrammes en utilisant les ontologies de tâches ou d'autres techniques. Cette proposition pourrait être adaptée à la re-ingénierie des ontologies et la reingénierie des applications web en des applications orientées services web en exploitant l'ontologie de tache OWL-S.