Résumé. Aujourd'hui, le langage de modélisation unifié (UML) a été largement accepté par l'industrie et s'est établi comme le langage commun pour l'analyse et la conception en génie logiciel orienté objet. Néanmoins, il souffre de manque d'outils et de syntaxe qui lui permettent de raffiner davantage la sémantique de données à partir de l'univers de discours. Ce raffinement est maîtrisé dans la méthode Niam (Nijssen Information Analysis Methodology), qui se base sur la modélisation des systèmes d'informations à partir des exemples simples du domaine en utilisant une procedure appelée CSDP (Conceptual Schema and relational database Design Procedure). Afin de bénéficier de la puissance de cette procédure pour l'élaboration de diagrammes UML sémantiquement plus expressifs, on propose dans cet article, une adaptation de CSDP à la notation UML. L'utilisation des ontologies dans le développement des systèmes d'informations peut servir divers aspects. Elle permet d'optimiser l`analyse conceptuelle, de minimiser l'intervention de l'expert de domaine, d'enrichir la conception, d'éviter l'ambiguïté dans la spécification et de soutenir l'automatisation du processus de vérification de la fiabilité des systèmes. Notre approche est consolidée par l'utilisation de l'ontologie de domaine, afin de générer des diagrammes UML sémantiquement riches.
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
binaires. Pour cela, Nijssen [
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 [
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). Employé avec le nom ‘Jones’ travaille dans le département de code ‘D1’ ; Employé avec le nom ‘Jones’ a une situation familiale de code ‘M’; Employé avec le nom ‘Fegan’ est un superviseur de l’employé avec le nom ‘Jones’ Employé avec le nom ‘Edwards’ occupe la fonction 'acheteur'.
Employé avec le nom ‘Giles’ occupe la fonction 'vendeur'.
Employé avec le nom ‘Jones’occupe la fonction 'Chef de serv. mouvements produits'. Employé avec le nom ‘Fegan’ occupe la fonction 'Chef de département commercial' Le mariage de l'employé avec le nom 'Giles' était en ‘1975’.
Le superviseur avec le nom ‘Jones’ a le numéro de téléphone ‘3715821’ Le superviseur avec le nom ‘Jones’ a un nombre d'enfants égal à ‘2’ Chaque superviseur supervise au maximum deux employés. ii) Vérification de qualité sur les idées élémentaires La vérification consiste à se poser les questions suivantes :
Situation N° Tel familiale (Sit fam) M
3715821 C M 3783437
Année Mariage 1964 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 [
E m p l o y é D é p a r t e m e n t .
A v e c n o m A v e c D e p t # J o n eEsd w a Grdisl e s
F e g a n N o m E m p l o y é D 1
D 2
D e p t # C h e f D p t AC cohme t e u r
V e n d e u r
C h e f s e r v M v t
F o n c t i o n On reconnaît trois types d'objets. les entités sont les objets simples dans l'U°D. Les étiquettes sont les objets lexicaux qui sont utilisées pur se référer aux entités. Dans certains cas, on considère les objets et leurs relations comme des objets et on les appellera des objets composés.
F o n c tio n
O c c u p é e p a r o c c u p e
Fig. 2. Diagramme de schéma conceptuel correspondent en Niam
Pour représenter les diagrammes de classes et d'objets, on s'est basé sur un ensemble
de règles proposées dans [
On commence par présenter un diagramme d’objets pour les idées exprimées :
Vendeur:Fonction Chef serv Mvt:Fonction
Acheteur:Fonction Chef dpt Com:Fonction
Giles:Employé Superviseur
Jones:Employé Superviseur
Edwards:Employé
Superviseur Fig. 3. Diagramme d’objets d’UML
Fegan:Employé
D1:Dept D2:Dept
Le diagramme de classes déduit à partir du diagramme d’objets est représenté par la figure suivante :
Employé Nom
Sitfam
Ayant dessiné notre premier brouillon du diagramme du schéma conceptuel et accompli une vérification de population. Cette étape consiste à éliminer les associations en surplus ou les rôles communs et identifier n'importe quelles attributs dérivés. Dans cette étape, les questions pertinentes que nous nous posons, peuvent être résumées ainsi : 1. Est ce qu'un objet peut être instance de deux classes? Si oui combiner les classes en une seule. 2. Est ce que des objets de classes différentes peuvent être comparées d'une façon significative? Si oui combiner les classes en une seule. 3. Est ce que toutes les instances de deux classes différentes peuvent jouer le même rôle? Si oui combiner les classes en une seule et si nécessaire ajouter une nouvelle classe aux deux pour préserver la distinction originale. 4. Est ce qu'un attribut est dérivable à partir d'autres attributs ? Si c'est le cas, marquer le début de l'attribut dérivé par un slach "/" (selon la documentation d'Uml) ou le transformer en une opération qui encapsule le calcul de l'attribut. 5. Est-ce qu'il y a des cas d'utilisation ou acteurs en surplus? Si oui les supprimer. 6. Est ce que des cas d'utilisation différents peuvent être comparées d'une façon significative? Si oui combiner les cas d'utilisation en un seul.
En vérifiant notre brouillon de schéma conceptuel, on trouve que la valeur de Allocation enfants peut être dérivée de la valeur de Nombre d’enfants par la règle suivante : Allocation enfants=500*nombre enfants, alors on applique la règle 4 sur le schéma conceptuel de Superviseur marié, on obtient :
Superviseur M arié N bre enfants /A llocation enfants ()
Quant au cas d'utilisation, on constate que les deux cas d'utilisation travail et
occupation peuvent être combinés en un seul par exemple tache. Les acteurs
département et fonction sont des acteurs en surplus, on les supprime.
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 [
a a b b 1 :N Pour la population des classes dans les associations, on applique la multiplicité sur les associations, et pour la population des attributs, on applique la multiplicité sur les attributs. Quant aux contraintes sur la population qu’on ne peut pas exprimer à l’aide de contraintes dans Uml, on utilise les notes textuelles.
A (Anr) xz/st
B (Bnr)
A Anr{P} xz_B[ ?..1] :bnr
B Bnr{p} st_A[?..*]: anr chaque élément de st_A référencie au maximum un seul B 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é. 3. Fournir une table d’idée significative pour l’association, diviser ceci par projection et ensuite re-combiner par jointure naturelle. Si de nouvelles instances apparaissent alors l’association est indivisible. 4. Pour les cas d'utilisation, on substitue les cas d'utilisation génériques par des cas d'utilisation spécifiques.
Dans notre exemple, on substitue le cas d'utilisation "tache" par les activités spécifiques pour chaque fonction.
Elles spécifient une restriction sur les valeurs possibles des instances d’un type d’entité données.
i) Les rôles impératifs et optionnels 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.
ii) L’agrégation 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 [
iii) La généralisation
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 [
Pour enrichir 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 [
- 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 [
Les classes et les propriétés de cette ontologie sont :
Personne
Employé Organisation Membre de (Personne, Groupe social) Repos 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 à vérifier 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.