ÐÏࡱá > þÿ 4 Í × þÿÿÿ Á Â Ã Ä Å Æ Ç È É Ê Ë Ì ü W Ä y þ H ÷ | ù d
ý
a í H ä C
û
€ þ y ú y ü ï ý } È { Ó T Õ w  @ Ï @ Ï @ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á 5@ ø¿ 0 — bjbjÏ2Ï2 á X X s œ ‡ ÿÿ ÿÿ ÿÿ ˆ r r r r nN nN nN D .[ š‘ š‘ š‘ š“ d þœ ô .[ ø ’ þ¥ d b» ¦ ¼ ¼ 0¼ •Þ `F õ$ | q: À
š÷ œ÷ œ÷ œ÷ œ÷ œ÷ œ÷ $ þ R ÿ P À÷ nN @Z ¥Ù ð •Þ @Z @Z À÷ r r ¼ 0¼ u Õ÷ He He He @Z ø r ¦" ¼ ( nN 0¼ š÷ He @Z š÷ He > He †e š Î ” A V
nN TÕ 0¼ ò¥ éjø7ŽÇ š‘ 8` H ¬Ñ Z ~á ë÷ 0 ø Ò N O €a ² ß ´ TÕ ²O ¶V x r r r r TÕ J ß nN žÕ à H Œ 9N ö He /R , [U å 1E œ ÍG ” aH L À÷ À÷ .[ ä g d v) $h 2e .[ g v) R E P U B L I Q U E A L G E R I E N N E D E M O C R A T I Q U E ET P O P U L A I R E
M i n i s t è r e d e l ’ E n s e i g n e m e n t S u p é r i e u r
& d e l a R e c h e r c h e S c i e n t i f i q u e
Université Abdelhamid Ibn Badis Mostaganem
Faculté des Sciences et Sciences de l’Ingénieur
Département d’Informatique
Mémoire présenté par
Mr BEKKI Khadhir
Pour l’obtention du diplôme de
MAGISTER
Spécialité : Informatique
Option :
Réseaux, Systèmes et bases de données
Elaboration des diagrammes UML à partir
de l’univers de discours
Composition du jury :
Mme BELBACHIR Hafida Professeur Président.Melle BENAMRANE Nacera M.C Examinateur. M. BELDJILALI Bouziane M.C Examinateur M. BENCHHIDA Mohamed C.C Examinateur. M. BELALEM Ghalem C.C Encadreur
Décembre 2006
Remerciements
Que Mr Belalem, Mon encadreur, soit remercié pour avoir accepté de diriger ce travail ainsi que pour ses conseils avisés, ses qualités humaines et sa disponibilité.
Je tiens à exprimer ma gratitude et ma profonde reconnaissance à Mr Malki, maître de conférences au département d’informatique de l’université de Djillali Liabes, pour ses orientations et ses conseils qui m’ont permis de progresser. Que Mrs Bouchiha et Bouida soient également remerciés pour leurs aides précieuses.
Mes remerciements vont aussi à Mr Abdi chargé de cours au département d’informatique de l’université d’Es Sénia, pour ses remarques et son intérêt à ce travail.
Un remerciement spécial à Mr Benchhida pour nous avoir donné la chance, par cette post-graduation, de poursuivre le chemin de la recherche et de la science. Que tous mes enseignants de Post-graduation de Mostaganem trouvent ici ma reconnaissance.
Je remercie tous les membres de jury : Mmes Belbachir et Benamrane et Mrs Beldjilali et Benchhida qui m’ont honoré par leur présence et pour avoir accepté d’examiner et d’évaluer mon travail.
Je tiens à remercier vivement tous ceux qui ont toujours été présents et m’ont apporté leur aide dans mon cursus de post-graduation, notamment Mrs Talbi et Boukhatem, qu’ils trouvent ici, le témoignage de ma profonde gratitude.
Je remercie affectivement tous mes collègues de Naftal pour leur soutien et particulièrement Mrs Belarbi, Benyagoub et Kaddouri et Mrs Belhezeil, Saf et Khelil pour leurs aides précieuses.
Ainsi que tous ceux qui ont contribué de près ou de loin à mettre en œuvre ce travail.
Résumé / Abstract
Résumé
UML (Unified Modeling Language) est devenu aujourd'hui un langage standard pour la conception et la modélisation orientée objet. Cependant, 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 ORM (Object Role Modeling), qui se base sur la modélisation des systèmes d’informations à partir des exemples simples du domaine en utilisant une procédure 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, nous proposons dans ce travail, une adaptation de CSDP à la notation UML et en utilisant l’ontologie de domaine comme source sémantique complémentaire dans une approche appelée UDDP (Uml Diagram Design Procedure).
MOTS- CLES : CSDP, Système d’information, UML, Ontologies, ORM, Rétro- ingénierie, UDDP.
Abstract
The unified modeling language (UML) has become a standard object modeling and design language. Nevertheless, it needs other syntax and tools to capture more data semantics from the universe of discourse (U°D). This capture may be obtained goodly in ORM (Object Role Modeling), which build the information modeling from data use cases using a powerful procedure called CSDP (Conceptual Schema and relational database Design Procedure). To gain the power of this procedure in elaborating semantically expressive UML diagrams, we propose in this work, an adaptation of CSDP to UML using the domain ontology as complementary semantic source. This approach is called UDDP (Uml Diagram Design Procedure).
KEYWORDS: CSDP, Information System, UML, Ontology, ORM, Reverse engineering, UDDP.
Table des Matières
TOC \o "1-3" \u Introduction générale PAGEREF _Toc153088562 \h 1
1.1 Le Contexte Général PAGEREF _Toc153088563 \h 1
1.2 Problématique PAGEREF _Toc153088564 \h 2
1.3 Notre contribution PAGEREF _Toc153088565 \h 2
1.4 Organisation du mémoire PAGEREF _Toc153088566 \h 3
Chapitre 1: Rétro-Ingénierie des bases de données : Etat de l’art PAGEREF _Toc153088567 \h 5
1.1 Introduction PAGEREF _Toc153088568 \h 5
1.2 Définitions PAGEREF _Toc153088569 \h 5
1.3 Les approches de rétro-ingénierie des bases de données PAGEREF _Toc153088570 \h 7
1.3.1 Historique PAGEREF _Toc153088571 \h 7
1.3.2 Rétro-ingénierie des bases de données relationnelles PAGEREF _Toc153088572 \h 7
1.3.3 Synthèse des approches de Rétro-ingénierie des bases de données relationnelles PAGEREF _Toc153088573 \h 13
1.3.4 Outils Industriels PAGEREF _Toc153088574 \h 15
´1.4 Conclusion PAGEREF _Toc153088575 \h 15
Chapitre 2: Les Ontologies PAGEREF _Toc153088576 \h 17
2.1 Introduction PAGEREF _Toc153088577 \h 17
2.2 Définitions PAGEREF _Toc153088578 \h 17
2.3 Le rôle des ontologies PAGEREF _Toc153088579 \h 18
2.4 Les composants d’une ontologie PAGEREF _Toc153088580 \h 19
2.5. Les domaines d'utilisation d'ontologies PAGEREF _Toc153088581 \h 20
2.5.1 Les ontologies et le processus d’ingénierie des systèmes d’information PAGEREF _Toc153088582 \h 20
2.5.2. Les ontologies et les bases de données PAGEREF _Toc153088583 \h 22
2.5.3 Traitement du langage naturel PAGEREF _Toc153088584 \h 23
2.5.4 Web sémantique PAGEREF _Toc153088585 \h 23
2.6 L’ontologie WordNet PAGEREF _Toc153088586 \h 24
2.7 Conclusion PAGEREF _Toc153088587 \h 24
Chapitre 3: Les Notations ORM et UML PAGEREF _Toc153088588 \h 26
3.1 Introduction PAGEREF _Toc153088589 \h 26
3.2 La méthode ORM PAGEREF _Toc153088590 \h 26
3.2.1 Introduction PAGEREF _Toc153088591 \h 26
3.2.2 Les concepts de base PAGEREF _Toc153088592 \h 27
3.2.3 La CSDP d’ORM PAGEREF _Toc153088593 \h 31
3.2.4 Avantages et inconvénients d’ORM PAGEREF _Toc153088594 \h 43
3.3 La Notation UML PAGEREF _Toc153088595 \h 43
3.2.1 Introduction PAGEREF _Toc153088596 \h 43
3.2.2 Les diagrammes d’UML PAGEREF _Toc153088597 \h 43
3.2.3 Intérêts et lacunes d’UML PAGEREF _Toc153088598 \h 51
3.4 Conclusion PAGEREF _Toc153088599 \h 51
Chapitre 4: L’approche UDDP (Uml Diagrams Design Procedure) PAGEREF _Toc153088600 \h 54
4.1 Introduction PAGEREF _Toc153088601 \h 54
4.2 La transformation de schéma conceptuel ORM à UML PAGEREF _Toc153088602 \h 54
4.2.1 La transformation des objets ORM PAGEREF _Toc153088603 \h 54
4.2.2 La transformation de types d’idées unaires PAGEREF _Toc153088604 \h 55
4.2.3 La transformation de types d’idées binaire PAGEREF _Toc153088605 \h 56
4.2.4 La transformation de types d’idées naires PAGEREF _Toc153088606 \h 58
4.2.5 La transformation de types d’objets emboîtés PAGEREF _Toc153088607 \h 58
4.2.6 La transformation de la co-référence PAGEREF _Toc153088608 \h 59
4.2.7 La transformation de sous typage PAGEREF _Toc153088609 \h 60
4.2.8 Tableau de correspondances entre ORM et UML PAGEREF _Toc153088610 \h 61
4.2.9 Exemple de transformation PAGEREF _Toc153088611 \h 62
4.3 La procédure UDDP PAGEREF _Toc153088612 \h 63
4.3.1 Verbalisation des exemples en idées élémentaires PAGEREF _Toc153088613 \h 63
4.3.2 Dessin d’un premier brouillon des diagrammes de classes et d'objets PAGEREF _Toc153088614 \h 64
4.3.3 Arrangement des diagrammes et identification des attributs dérivés PAGEREF _Toc153088615 \h 66
4.3.4 Adjonction de contraintes de multiplicité et vérifications de l’ordre PAGEREF _Toc153088616 \h 66
4.3.5 Adjonction de contraintes de type et de fréquence PAGEREF _Toc153088617 \h 67
4.3.6 Adjonction de contraintes d’agrégation et de généralisation. PAGEREF _Toc153088618 \h 68
4.3.7 Alignement avec l’ontologie de domaine. PAGEREF _Toc153088619 \h 69
4.3.8 Adjonction de contraintes lexicales, de qualifications et d’autres contraintes PAGEREF _Toc153088620 \h 70
4.3.9 Les vérifications finales PAGEREF _Toc153088621 \h 71
4.4 Conclusion PAGEREF _Toc153088622 \h 71
Chapitre 5 : Implementation PAGEREF _Toc153088623 \h 73
5.1 Introduction PAGEREF _Toc153088624 \h 73
5.2 Présentation de la plateforme StarUML PAGEREF _Toc153088625 \h 73
5.2.1 Architecture de Plateforme PAGEREF _Toc153088626 \h 73
5.2.2. Structure d'un module en StarUML PAGEREF _Toc153088627 \h 74
5.2.3. Applications de module StarUML PAGEREF _Toc153088628 \h 74
5.3. Architecture de UDDPTool PAGEREF _Toc153088629 \h 75
5.3.1. Le Module verbalisation PAGEREF _Toc153088630 \h 76
5.3.2. Le Module acquisition PAGEREF _Toc153088631 \h 76
5.3.3. Le Module UDDP PAGEREF _Toc153088632 \h 76
5.3.4 Le Module générateur de diagrammes UML PAGEREF _Toc153088633 \h 76
5.4 Test sur un exemple : un système d’information d’une organisation PAGEREF _Toc153088634 \h 76
5.4.1. Les entrées du système PAGEREF _Toc153088635 \h 77
5.4.2. Des interfaces de l’application PAGEREF _Toc153088636 \h 77
5.4.3. Les Résultats sur StarUML PAGEREF _Toc153088637 \h 79
5.5 Conclusion PAGEREF _Toc153088638 \h 80
Conclusions et Perspectives PAGEREF _Toc153088639 \h 82
Conclusions PAGEREF _Toc153088640 \h 82
Perspectives PAGEREF _Toc153088641 \h 83
Annexes PAGEREF _Toc153088642 \h 85
Quelques ontologies de domaine utilisées dans notre outil PAGEREF _Toc153088643 \h 85
Bibliographie PAGEREF _Toc153088644 \h 96
Liste des Figures
TOC \h \z \c "Figure" HYPERLINK \l "_Toc152552099" Figure 11: Taxonomie de la réingéinierie de Chikofsky PAGEREF _Toc152552099 \h 6
HYPERLINK \l "_Toc152552100" Figure 22: Méthodologie de développement des systèmes d’information PAGEREF _Toc152552100 \h 21
HYPERLINK \l "_Toc152552101" Figure 2-3: Processus de conception traditionnel PAGEREF _Toc152552101 \h 21
HYPERLINK \l "_Toc152552102" Figure 2-4: Processus de conception orienté ontologie PAGEREF _Toc152552102 \h 22
HYPERLINK \l "_Toc152552103" Figure 2-5: Le lien entre l’ontologie et les sources de données (Schéma EA et relationnel PAGEREF _Toc152552103 \h 23
HYPERLINK \l "_Toc152552104" Figure 3-1: Exemple de type d'idée PAGEREF _Toc152552104 \h 27
HYPERLINK \l "_Toc152552105" Figure 3-2: Exemple de sous typage PAGEREF _Toc152552105 \h 28
HYPERLINK \l "_Toc152552106" Figure 3-3: Contrainte d’unicité sur rôle PAGEREF _Toc152552106 \h 28
HYPERLINK \l "_Toc152552107" Figure 3-4: Contrainte d’unicité sur idée PAGEREF _Toc152552107 \h 28
HYPERLINK \l "_Toc152552108" Figure 3-5: Contrainte d’unicité entre rôles PAGEREF _Toc152552108 \h 29
HYPERLINK \l "_Toc152552109" Figure 3-6: Contrainte de rôle obligatoire PAGEREF _Toc152552109 \h 29
HYPERLINK \l "_Toc152552110" Figure 3-7: Contrainte de totalité entre rôles PAGEREF _Toc152552110 \h 29
HYPERLINK \l "_Toc152552111" Figure 3-8: Contrainte de totalité entre sous types PAGEREF _Toc152552111 \h 30
HYPERLINK \l "_Toc152552112" Figure 3-9: Contrainte d’exclusion entre rôles PAGEREF _Toc152552112 \h 30
HYPERLINK \l "_Toc152552113" Figure 3-10: Contrainte d’exclusion entre idées PAGEREF _Toc152552113 \h 30
HYPERLINK \l "_Toc152552114" Figure 3-11: Contrainte d’exclusion entre sous types. PAGEREF _Toc152552114 \h 31
HYPERLINK \l "_Toc152552115" Figure 3-12 : Premier brouillon du diagramme d’occurrences PAGEREF _Toc152552115 \h 33
HYPERLINK \l "_Toc152552116" Figure 3-13 : Premier brouillon du diagramme du S.C. PAGEREF _Toc152552116 \h 34
HYPERLINK \l "_Toc152552117" Figure 3-14 : Les concepts extraits des exemples PAGEREF _Toc152552117 \h 35
HYPERLINK \l "_Toc152552118" Figure 3-15 : Exemple de type d'idée dérivé PAGEREF _Toc152552118 \h 35
HYPERLINK \l "_Toc152552119" Figure 3-16: Exemple de contrainte d’unicité sur un rôle PAGEREF _Toc152552119 \h 36
HYPERLINK \l "_Toc152552120" Figure 3-17 : Exemple de contrainte d’unicité sur deux rôles PAGEREF _Toc152552120 \h 36
HYPERLINK \l "_Toc152552121" Figure 3-18: Les possibilités des contraintes d’unicité sur les rôles PAGEREF _Toc152552121 \h 36
HYPERLINK \l "_Toc152552122" Figure 3-19: Le résultat de l'étape 4 PAGEREF _Toc152552122 \h 37
HYPERLINK \l "_Toc152552123" Figure 3-20 : Le rôle impératif de l’entité superviseur PAGEREF _Toc152552123 \h 38
HYPERLINK \l "_Toc152552124" Figure 3-21 : Le graphe de sous typage PAGEREF _Toc152552124 \h 40
HYPERLINK \l "_Toc152552125" Figure 3-22: Les fréquences d’occurrence PAGEREF _Toc152552125 \h 40
HYPERLINK \l "_Toc152552126" Figure 3-23: Le résultat de l'étape 6 PAGEREF _Toc152552126 \h 41
HYPERLINK \l "_Toc152552127" Figure 3-24: Exemple de la contrainte lexicale PAGEREF _Toc152552127 \h 41
HYPERLINK \l "_Toc152552128" Figure 3-25: Exemple de pont de dénomination PAGEREF _Toc152552128 \h 42
HYPERLINK \l "_Toc152552129" Figure 3-26: Le résultat de l'étape 8 PAGEREF _Toc152552129 \h 42
HYPERLINK \l "_Toc152552130" Figure 3-27: Exemple de diagramme de classes PAGEREF _Toc152552130 \h 44
HYPERLINK \l "_Toc152552131" Figure 3-28: Exemple d'attribut dérivé PAGEREF _Toc152552131 \h 45
HYPERLINK \l "_Toc152552132" Figure 3-29: Représentation d'une association ternaire au moyen d'une classe avec stéréotype PAGEREF _Toc152552132 \h 45
HYPERLINK \l "_Toc152552133" Figure 3-30: Valeurs de multiplicité conventionnelles PAGEREF _Toc152552133 \h 46
HYPERLINK \l "_Toc152552134" Figure 3-31: Restriction d'une association, au moyen d'un attribut particulier appelé clé PAGEREF _Toc152552134 \h 47
HYPERLINK \l "_Toc152552135" Figure 3-32: Représentation des agrégations PAGEREF _Toc152552135 \h 47
HYPERLINK \l "_Toc152552136" Figure 4-1: Transformation de types d’entités dépendants et indépendants PAGEREF _Toc152552136 \h 55
HYPERLINK \l "_Toc152552137" Figure 4-2: Rôle obligatoire en ORM et sa transformation en UML PAGEREF _Toc152552137 \h 55
HYPERLINK \l "_Toc152552138" Figure 4-3: Transformation de type d’idée unaire PAGEREF _Toc152552138 \h 56
HYPERLINK \l "_Toc152552139" Figure.4-4 : Transformation de type d’idée binaire PAGEREF _Toc152552139 \h 56
HYPERLINK \l "_Toc152552140" Figure 4-5: Transformation de type d’idée binaire 1:M PAGEREF _Toc152552140 \h 57
HYPERLINK \l "_Toc152552141" Figure 4-6: Transformation de type d’idée 1:1 PAGEREF _Toc152552141 \h 57
HYPERLINK \l "_Toc152552142" Figure 4-7: Transformation de types d’idées binaires d'ORM en associations d’UML PAGEREF _Toc152552142 \h 58
HYPERLINK \l "_Toc152552143" Figure 4-8: Transformation de type d’idée ternaire en UML PAGEREF _Toc152552143 \h 58
HYPERLINK \l "_Toc152552144" Figure 4-9: Transformation de l'objet emboîté d'ORM en une classe d'association d'UML PAGEREF _Toc152552144 \h 59
HYPERLINK \l "_Toc152552145" Figure.4-10: Transformation de Co-référence d'ORM PAGEREF _Toc152552145 \h 60
HYPERLINK \l "_Toc152552146" Figure 4-11: Transformation de sous type d'ORM à UML PAGEREF _Toc152552146 \h 61
HYPERLINK \l "_Toc152552147" Figure 4-12: Exemple en ORM PAGEREF _Toc152552147 \h 62
HYPERLINK \l "_Toc152552148" Figure 4-13: Transformation de l’exemple en diagramme de classes d’UML PAGEREF _Toc152552148 \h 63
HYPERLINK \l "_Toc152552149" Figure 4-14: Diagramme d’occurrences PAGEREF _Toc152552149 \h 64
HYPERLINK \l "_Toc152552150" Figure 4-15: Diagramme de schéma conceptuel correspondant PAGEREF _Toc152552150 \h 65
HYPERLINK \l "_Toc152552151" Figure 4-16: Diagramme d’objets d’UML PAGEREF _Toc152552151 \h 65
HYPERLINK \l "_Toc152552152" Figure 4-17: Diagramme de classes d’UML PAGEREF _Toc152552152 \h 65
HYPERLINK \l "_Toc152552153" Figure 4-18: La classe superviseur marié PAGEREF _Toc152552153 \h 66
HYPERLINK \l "_Toc152552154" Figure 4-19: Règles de transformation des multiplicités d’ORM à UML PAGEREF _Toc152552154 \h 66
HYPERLINK \l "_Toc152552155" Figure 4-20: Diagramme de classes d’UML après l’étape 6 PAGEREF _Toc152552155 \h 67
HYPERLINK \l "_Toc152552156" Figure 4-21: Graphe de sous typage PAGEREF _Toc152552156 \h 69
HYPERLINK \l "_Toc152552158" Figure 5-1: Présentation de l’architecture de StarUML. PAGEREF _Toc152552158 \h 73
HYPERLINK \l "_Toc152552159" Figure 5-2: Structure d’un module en StarUML. PAGEREF _Toc152552159 \h 74
HYPERLINK \l "_Toc152552160" Figure 5-3: Les modules intégrés dans la version 5.0.2 de StarUML PAGEREF _Toc152552160 \h 75
HYPERLINK \l "_Toc152552161" Figure 5-4: Organisation des modules du UDDPTool PAGEREF _Toc152552161 \h 75
HYPERLINK \l "_Toc152552162" Figure 5-5: L’interface principale de l’application PAGEREF _Toc152552162 \h 77
HYPERLINK \l "_Toc152552163" Figure 5-6: L’interface de verbalisation PAGEREF _Toc152552163 \h 78
HYPERLINK \l "_Toc152552164" Figure 5-7: L’interface d’acquisition de l’ontologie PAGEREF _Toc152552164 \h 78
HYPERLINK \l "_Toc152552165" Figure 5-8: Résultat de l’exemple traité sans l’utilisation de l’ontologie de domaine PAGEREF _Toc152552165 \h 79
HYPERLINK \l "_Toc152552166" Figure 5-9: Résultat de l’exemple traité avec l’utilisation de l’ontologie de domaine PAGEREF _Toc152552166 \h 79
Liste des Tableaux
TOC \h \z \c "Tableau" HYPERLINK \l "_Toc152400797" Tableau 11: Les caractéristiques des approches de rétro-ingénierie de BDDs Relationnelles PAGEREF _Toc152400797 \h 14
HYPERLINK \l "_Toc152400798" Tableau 3-1: Exemples familiers d’informations pertinentes de l’U°D PAGEREF _Toc152400798 \h 32
HYPERLINK \l "_Toc152400799" Tableau 3-2: Matrice de sous typage PAGEREF _Toc152400799 \h 39
HYPERLINK \l "_Toc152400800" Tableau 4-1: Les correspondances entre ORM et UML PAGEREF _Toc152400800 \h 61
HYPERLINK \l "_Toc152400801" Tableau 4-2: Exemple de l’univers de discours PAGEREF _Toc152400801 \h 64
HYPERLINK \l "_Toc152400802" Tableau 5-1: Cas d’utilisation de données PAGEREF _Toc152400802 \h 77
Introduction Générale
Introduction générale
Dans cette introduction, nous commençons dans un premier temps, par définir le contexte général et la problématique de notre domaine de recherche; Puis, nous donnons quelques caractéristiques d’UML (Unified Modeling Language) et avantages de la méthode ORM (Object Role Modeling) qui nous ont motivé à proposer l’approche décrite ci-après.
1.1 Le Contexte Général
Le système d’information reste l’une des principales composantes qui font le succès d’une entreprise (ou d’une organisation en générale). En fait, la gestion efficace de l’information joue un rôle crucial dans la compétitivité des entreprises d’aujourd’hui. Elle leur permet de répondre rapidement aux conditions de changements dans un environnement concurrentiel très dur. Depuis déjà des années, beaucoup d’entreprises ont pris conscience de cette réalité et ont investi des sommes considérables dans le développement, le déploiement et l’entretien de leurs systèmes d’information. Une part de plus en plus importante des budgets informatiques est consacrée à la compréhension et à la réappropriation de l’existant [Hainaut et al.-1996].
Et pour être en phase avec l’évolution de la technologie sans pour autant laisser tomber des années d’investissement et de savoir-faire, un nouveau domaine de recherche a vu le jour il y a une vingtaine d’années dans le milieu académique, en l’occurrence la ré-ingénierie, en vue justement de reconsidérer les applications existantes dans une nouvelle perspective. Cette discipline est issue directement des différents problèmes de maintenance vécus dans les entreprises et du besoin d’intégration des nouvelles technologies.
La ré-ingénierie est l’analyse et la modification d’un système existant pour le reconstituer sous une nouvelle forme et l’implantation conséquente de cette forme. Ce processus est une combinaison d’autres processus, comme la rétro-ingénierie, la restructuration, l’ingénierie directe, la redocumentation et la conversion. Son but est d’améliorer le logiciel (fonctionnalités, performances ou implantation) [Cim-1993].
Selon [Chikofsky et al.-1990], la rétro-ingénierie est “le processus d’analyse d’un système sujet pour identifier ses composants et leurs interrelations, et créer des représentations du système sous une autre forme et à un plus haut niveau d’abstraction”. (i.e. niveau conceptuel). Il est clair que le processus qui assure de telles mutations, tout en préservant des investissements antérieurs, nécessite des efforts considérables de compréhension des aspects structurels et sémantiques des systèmes existants. De plus, la rétro-ingénierie est généralement considérée comme une tâche dont l’interaction avec l’utilisateur (concepteur et expert du domaine) est intensive [Malki- 2002].
Depuis une trentaine d’années, les chercheurs réfléchissent et mettent au point des techniques, des méthodes et des outils pour supporter le concepteur dans toutes les étapes du cycle de vie d’un système d’information. Ils travaillent dans des domaines aussi variés que la conception, la maintenance, la documentation, la rétro-ingénierie de systèmes, l’analyse des besoins ou la définition de méthodologies.
Des modèles et des méthodes ont été développés pour décrire, analyser et concevoir des bases de données. Plus tard sont apparus des ateliers de génie logiciel qui devaient aider le concepteur dans sa démarche de conception. A l’heure actuelle, des modèles tels les modèles Entité/Association, NIAM, UML, ..., des méthodes de conception de bases de données (comme Merise, OMT, ...) et des ateliers (Tramis, SDesigner, AMC designer, Rational Rose, Win Design, ...) sont largement répandus et disponibles dans la communauté de l’Informatique internationale.
Néanmoins, les ateliers de conception vendus aux entreprises sont trop souvent inadéquats et mal utilisés. Le manque de support lors des phases critiques du cycle de vie d’un logiciel (comme la maintenance et l’évolution) est une cause importante de cet échec [Hick-2001].
Aujourd’hui, le langage de modélisation unifié (UML) [OMG-2003], standardisé par l’Object Management Group (OMG) 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.
L’élaboration des outils et des ateliers de qualité pour la re-ingénierie des systèmes d’information en UML est une nécessitée accrue.
1.2 Problématique
La notation UML représente l’état de l’art des langages de modélisation objet. Elle a été adoptée en 1997 par (Object Management Group OMG) comme un langage pour l'analyse et la conception orientée objet [Muller-1997]. UML est devenue la norme pour la conception et la spécification des systèmes d'information, des applications basées sur le Web et des logiciels en général.
La re-ingénierie des systèmes d’information en UML est un passage essentiel pour être en phase avec l’évolution de la technologie.
UML est bien approprié à concevoir le code du programme orientée objet. Cependant, Il est moins adapté pour l'analyse conceptuelle de l'information [Halpin-2001a]. Il souffre de manque d’outils et de syntaxe qui lui permettent de raffiner le maximum de la sémantique de données à partir de l’univers de discours. UML est moins approprié à développer et valider les modèles conceptuels des données avec des experts de domaine.
Ceci nécessite de développer des outils et des approches qui peuvent raffiner au maximum la sémantique des données à partir l’univers de discours et fournir des diagrammes UML sémantiquement plus riches et plus valides constituant un point de départ pour le concepteur en UML.
1.3 Notre contribution
Dans ce mémoire, nous proposons une approche pour l’élaboration de diagrammes UML sémantiquement riches à partir de l’univers de discours (U°D). Cette approche est inspirée de la procédure CDSP (Conceptual Schema Design Procedure) de la méthode systémique ORM (Object Role Modeling).
La méthode ORM est une méthode orientée données développée dans les années 70. Elle présente une sémantique riche pouvant être exprimée syntaxiquement dans les langages graphique et textuel formellement d'un niveau suffisamment élevé pour être utilisée par les utilisateurs non techniciens, afin d'exprimer et valider les règles d’un domaine donné [Halpin-2001a].
ORM dispose de la procédure CSDP qui dérive le schéma conceptuel à partir des exemples significatifs de l’univers de discours en validant la conception avec l’expert de domaine. Elle peut être considérée comme une procédure de rétro-ingénierie de base de données.
La CSDP est une séquence de neuf étapes qui commence par la verbalisation des exemples de l’univers de discours et se termine par l’élaboration d’un schéma conceptuel final.
Nous proposons une adaptation de la procédure CSDP à la notation UML, pour bénéficier des avantages de l’approche d’ORM dans la construction des diagrammes UML (Diagrammes de classes et diagrammes d’objets) plus valides, stables et sémantiquement riches.
Pour l’élaboration des diagrammes UML, nous utilisons les règles de correspondances entre ORM et UML qui ont fait l’objet de plusieurs travaux [Halpin-1998a; Halpin-1998b; Halpin-1998c; Halpin-1998d; Halpin et al.-1999].
En sus, nous utilisons l’ontologie de domaine pour enrichir la conception et minimiser l’intervention de l’expert de domaine.
Donc, Notre procédure appelée UDDP (UML Diagram Design Procedure) utilise trois sources sémantiques :
- Des exemples familiers de l’univers de discours.
Les règles de transformation entre ORM et UML.
L’ontologie de domaine.
L’ontologie de domaine contient les concepts et les relations de ce domaine.
En outre, Pour assurer une meilleure communication entre les intervenants (l’utilisateur, l’expert de domaine et le système), UDDP utilise un langage pseudo-naturel inspiré de la notation ORM.
UDDP se déroule en neuf étapes successives en commençant de la verbalisation des exemples de l’univers de discours jusqu'aux vérifications finales de diagrammes obtenus.
Une expérimentation de cette approche a été réalisée par l’outil UDDPTool (développé dans le cadre de ce projet) et qui nous a permis d’évaluer et de valider l’approche à partir d’exemples.
1.4 Organisation du mémoire
Ce mémoire contient, outre l’introduction, cinq chapitres.
Le premier chapitre présente un état de l’art sur la rétro-ingénierie des bases de données. La première partie est consacrée à des notions de base sur la rétro-ingénierie et sa deuxième aux approches de rétro-ingénierie des bases de données.
Dans le deuxième chapitre, nous essayons de présenter les ontologies. Nous verrons, tout d’abord, les principes, les définitions, les types et les rôles des ontologies, puis l’apport des ontologies au processus d’ingénierie des systèmes d’informations pour les comparer ensuite aux bases de données. Enfin, nous présentons les principales applications utilisant des ontologies.
Au troisième chapitre, nous proposerons une brève vue d’ensemble d’UML et d’ORM. Nous définirons les principaux concepts des deux approches et parlerons de leurs puissances et de leurs faiblesses.
Dans le quatrième chapitre, nous détaillerons l’approche proposée de la verbalisation des exemples de l’univers de discours aux vérifications finales de diagrammes obtenus.
Aussi, le cinquième chapitre traitera-t-il de la description de notre outil UDDPTool que nous avons conçu et implémenté en vue d’étudier et d’analyser l’approche proposée.
Enfin, nous terminons ce travail par une synthèse du travail réalisé et proposerons quelques perspectives.
CHAPITRE I
Rétro-Ingénierie des bases de données: Etat de l’art
Chapitre 1: Rétro-Ingénierie des bases de données : Etat de l’art
1.1 Introduction
Les entreprises et les organisations en général subissent des changements notamment en matière technologique et organisationnelle. En effet, elles sont de plus en plus confrontées à des problèmes de migration de leurs systèmes d’informations. Elles sont amenées à faire évoluer les bases de données existantes vers d’autres environnements, bénéficiant ainsi des avancées technologiques et répondant aux nouveaux besoins des utilisateurs. Parfois, elles sont appelées à maintenir leurs systèmes d’informations à cause de caractère défectueux de la conception et du développement de nouvelles applications notamment lors de la phase d’analyse des besoins des utilisateurs [Malki-2002].
La rétro-ingénierie d’un système d’information est le processus de reconstruction de la spécification fonctionnelle et technique d’un système opérationnel. La reconstruction de ces spécifications a généralement pour objectif la redocumentation, la conversion, la restructuration, la maintenance ou l’extension du système d’information. Nous allons voir dans ce chapitre les définitions de la rétro-ingénierie et un état de l’art sur les approches de la rétro-ingénierie des bases de données.
1.2 Définitions
La rétro-ingénierie est une composante essentielle de la ré-ingénierie des systèmes d’informations. Chikofsky et Cross [Chikofsky et al.-1990] proposent une classification de la terminologie concernant le domaine de la ré-ingénierie.
La rétro-ingénierie (Reverse Engineering) : est le processus d’analyse d’un système permettant l’identification des entités et leurs corrélations en vue de passer d’une forme de représentation à un autre niveau d’abstraction identique ou plus élevé. Cette activité consiste donc à examiner un existant, suivi éventuellement d’une remontée dans les niveaux d’abstraction, permettant ainsi une vue plus large du domaine et une meilleure compréhension du système d’information grâce à une redocumentation.
Le processus de rétro-ingénierie comporte deux activités distinctes mais complémentaires :
La redocumentation (redocumentation) consiste à créer des représentations sémantiquement équivalentes et de même niveau d’abstraction. La redocumentation n’est pas une activité spécifique au processus de rétro-ingénierie, elle est implicitement présente à tous les niveaux de la ré-ingénierie.
La rétro-conception (design recovery) : La rétro-conception consiste à utiliser des connaissances du domaine en vue d’obtenir une abstraction élevée pour permettre une meilleure compréhension du système.
L'ingénierie directe (Forward Engineering) : correspond au processus de développement traditionnel d’un système. On part d’un niveau de représentation conceptuelle élevé et on cherche à obtenir un système opérationnel par une série de développements/modifications progressifs descendants. Cette activité a pour objectif soit la mise au point d’un nouveau système (ingénierie de développement), soit l’évolution d’un système existant (ingénierie de maintenance).
La restructuration (Restructuring) : permet la transformation d’une représentation en une autre au même niveau d’abstraction, tout en conservant la sémantique et le comportement du système.
La ré-ingénierie (Reengineering) : est le processus d’examen et de modification d’un système dans le but de le reconstituer dans une nouvelle forme puis de l’implémenter. La ré-ingénierie utilise donc des techniques de rétro-ingénierie et d’ingénierie directe. Le processus de ré-ingénierie s’emploie à partir d’un existant plus ou moins bien documenté. Il consiste alors à remonter dans les niveaux d’abstraction afin d’approfondir les connaissances. La rétro-ingénierie représente la phase montante de la ré-ingénierie.
EMBED Word.Picture.8
Figure 11: Taxonomie de la réingéinierie de Chikofsky [Chikofsky-1990]
Pour les systèmes d’information ou application centré de données (ou base de données), on admet que la complexité puisse être réduite en effectuant la rétro-ingénierie des données (fichier ou de base de données) indépendamment de la partie procédurale (ou programmes), puis on procède à cette dernière sur la base des connaissances acquises.
En fait, il existe deux principales orientations:
Vers les données : on parle alors de rétro-ingénierie orientée données,
Vers les programmes : on parle alors de rétro-ingénierie de programmes.
La rétro-ingénierie de programmes est difficile car des informations sont à jamais perdues dans les programmes d’application. En effet, la distance sémantique entre les spécifications conceptuelles et l’implémentation physique d’un programme est nettement plus grande que dans le contexte des bases de données (ou fichiers).
La rétro-ingénierie orientée-données est un processus qui consiste à «remonter» les différentes phases nécessaires à l’ingénierie d’une application base de donnée [Hainaut et al.-1995]. Son but est de comprendre la sémantique des données, i.e. leur organisation logique et d’en fournir une abstraction comportant, par exemple une hiérarchie d’héritage. En fait, cette activité connaît aujourd’hui un regain d’intérêt du fait des multiples applications où elle peut intervenir notamment : la maintenance (ou l’évolution), la ré-ingénierie (ou la migration), l’interopérabilité, etc.
1.3 Les approches de rétro-ingénierie des bases de données
La rétro-ingénierie de base de données a pour but quant à elle d’extraire des schémas conceptuels à partir des schémas physiques des bases de données existantes, qu’elles soient hiérarchiques, relationnelles, objets ou multidimensionnelles .
1.3.1 Historique
Dans [Malki-2002], Malki classifie les recherches et les contributions dans le domaine de la rétro-ingénierie des bases de données en trois familles ou générations d’approches.
La première génération avait pour objectif de proposer des démarches de rétro-ingénierie d’applications utilisant des fichiers conventionnels, de type COBOL [Casanova et al.- 1983; Nilson et al.- 1985].
La seconde génération s’est focalisée principalement sur la transformation des schémas de bases de données navigationnelles de type hiérarchique et réseau. Plusieurs démarches ont été proposées notamment [Batini et al.- 1992; Fong-1993].
La troisième génération s’attache à la rétro-ingénierie des bases de données relationnelles. Plusieurs contributions ont été proposées [Anderson-1996; Chiang-1995; Davis et al.- 1987; Hainaut et al.-1995; Johannesson-1994; Mannila et al.- 1994; Markowitz et al.-1990; Navathe et al.-1988 ; Petit et al.-1995 ; Premerlani et al.-1993] vu l’importance du modèle relationnel qui a connu un grand succès comme support de stockage de données.
La rétro-ingénierie des bases de données orientées objets est d’un intérêt récent dans le mesure ou ces bases n’ont été implémentées que dernièrement dans les entreprises. Deux contributions ont été citées [Hainaut et al.-1997 ; Theodoros-1998].
Enfin, deux approches nouvelles, une est spécifique à la rétro-ingénierie des entrepôts de données qui consiste à adapter leur approche de rétro-ingénierie de bases de données relationnelles aux entrepôts de données (Data warehouses). [Akoka et al.-1999, Akoka et al.-1998], et l’autre concerne la rétro- ingénierie des bases de données vers les ontologies pour permettre la migration des pages Web centrées données vers Web sémantique centré ontologie [Astrova et al.-2004].
Nous verrons par la suite et avec plus de détails les approches sur les bases de données relationnelles.
1.3.2 Rétro-ingénierie des bases de données relationnelles
Depuis 1980, de nombreuses méthodes de rétro-ingénierie de base de données ont été publiées. Toutes consistent sur l'extraction du schéma conceptuel à partir d’un système opérationnel. Le schéma conceptuel résultant peut être en modèle entités-associations ou en orientée objet (UML, OMT).
Divers critères peuvent être utilisés pour classifier les méthodes de rétro-ingénierie de base de données [Henrard-2003], à savoir: le système de manipulation de données supporté, le modèle cible, les pré-requis, les informations disponibles sur la sémantique des données, les heuristiques et les techniques utilisées, la complétude et la robustesse, l'interaction avec l'utilisateur, les sources d'informations.
Nous présentons ici une classification selon que la phase d’extraction de la sémantique des données a été réalisée ou non.
1.3.2.1- Non prise en compte de l’extraction de la sémantique des données.
L’ensemble des contributions de ce courant est basé sur des hypothèses de départ fortes, ce qui affecte leur applicabilité dans des cas pratiques. Les hypothèses les plus courantes sont :
- Schéma relationnel de départ en troisième forme normale.
Cette hypothèse avait pour objectif de garantir que chaque relation du schéma considérée correspond à un seul objet du champ d’application.
- Disponibilité.
A priori toutes les connaissances nécessaires sont disponibles (contraintes d’intégrité, clés, …) pour dériver le schéma conceptuel. Cette hypothèse est souvent réalisée à travers la présence d’un expert qui est capable de fournir les connaissances nécessaires au processus de rétro-ingénierie.
Généralement, toutes ces hypothèses ne sont pas valables en pratique [Malki-2002]. Les approches de rétro-ingénierie de bases de données relationnelles qui s’appuient sur de telles hypothèses réduisent en réalité le processus de rétro-ingénierie à la seule activité de transformation de schémas logiques en schémas conceptuels.
Parmi les approches de ce courant, nous trouvons :
[Casanova et al. -1983]
Cette méthode exige d’avoir en entrée un schéma relationnel avec des clés primaires et étrangères. Son modèle cible est le modèle entités-associations sans objets complexes et sans généralisation. Elle utilise la division et la fusion des tables en des types d’entités dont chacune représente un objet dans le schéma conceptuel.
[Dumpala et al.-1983]
Cette méthode exige en entrée un schéma physique relationnel, hiérarchique ou réseau et résulte un schéma entités-associations.
Son processus déroule en deux étapes : -La construction du schéma logique. - L’abstraction du schéma conceptuel.
[Davis et al. -1987]
Elle exige en entrée un schéma relationnel en troisième forme normale. Le modèle cible est un modèle entités-associations sans objets complexes ni généralisation. Son principe est de transformer les tables avec clés simples ou composées de plusieurs attributs en types d’entité. Les tables avec clés composées de clés primaires d’autres tables se transforment à des associations de type n-n. Si une clé primaire d’une table transformée en type d’entité se présente comme attribut non clé dans une autre table, cela indique l’existence d’une relation de type 1-n à créer.
[Navathe et al.-1988]
Elle exige en entrée un schéma relationnel ou hiérarchique. Elle réclame un prétraitement du schéma pour la simplification de la structure. Généralement, il repose sur une classification des relations du schéma relationnel en trois groupes : primaires, primaires faibles et secondaires, conduisant naturellement à l’identification des entités régulières, faibles et associations. Son processus de transformation est composé de sept étapes.
[Markowitz et al.-1990]
Cette méthode poursuit l’approche citée en [Casanova et al.-1983]. Elle exige en entrée un schéma relationnel, les dépendances de clé et les dépendances d’inclusion basées sur les clés (contraintes de référence). Le modèle cible est le modèle entités-associations. La méthode est un processus de quatre étapes. Sa contribution principale est l’indépendance par rapport aux noms d’attributs et la formalisation de la transformation entre les schémas.
[Kalman-1991]
Cette méthode exige en entrée un schéma relationnel en troisième forme normale et son modèle cible est le modèle entités-associations.
Elle consiste à classifier les relations à travers les clés primaires des relations tout en dialoguant avec l’utilisateur (concepteur ou l’administrateur de la base de données). Ainsi, la transformation du schéma relationnel est obtenue à l’aide de cette classification. Les contraintes de cardinalité sont dérivées des dépendances fonctionnelles.
[Ji-1991]
Elle exige en entrée un schéma relationnel en troisième forme normale et résulte un modèle orientée objet.
Elle prend en considération les dépendances d’inclusion basées sur les clés dans la transformation.
[Batini et al.-1992]
Elle exige en entrée un schéma relationnel en troisième forme normale et fournit en résultat le modèle entités-associations
Elle se base sur une classification des relations dans sa transformation du schéma relationnel.
[Fonkam et al.-1992 ]
Elle exige en entrée un schéma relationnel et son modèle cible est le modèle orienté objet. Elle est basée sur la méthode des clés dans la transformation du schéma relationnel sans classification des relations.
[Shoval et al.-1993]
Elle accepte les schémas relationnels en première forme normale à condition de disposer des dépendances fonctionnelles causant la dénormalisation. Elle résulte un schéma entités-associations binaire (Niam).
[Johannesson-1994]
Elle exige en entrée le schéma relationnel en troisième forme normale, les dépendances fonctionnelles et les dépendances d’inclusion.
Le modèle cible est le modèle entités-associations sans objets complexes et sans généralisation.
La méthode définit un ensemble de transformations pour diviser les relations représentant plus d’un type d’entité. Les différentes relations représentant le même type d’entité se fusionnent en une seule relation.
Le principe de l’algorithme de transformation est de transformer chaque relation en un type d’entité et chaque dépendance d’inclusion en, soit une contrainte de généralisation, soit une association.
[Fahrner-1995a, Fahrner et al.-1995b ]
Elle reçoit en entrée un schéma relationnel et son modèle cible est le modèle orienté objet.
Elle est basée sur les clés dans la transformation du schéma relationnel.
[Ramanathan et al.-1996]
Cette méthode exige en entrée le schéma relationnel en troisième forme normale avec des clés primaires et étrangères. Le résultat est un schéma en notation OMT (Object Modeling Technique).
La démarche de cette méthode est divisée en trois étapes. La première étape identifie les tables qui correspondent à des classes objets. La deuxième identifie les relations d’associations, de généralisation/spécialisation et d’agrégations. La dernière étape identifie les cardinalités des associations.
1.3.2.2- Prise en compte de l’extraction de la sémantique des données.
Le second courant, plus récent, où l’extraction de la sémantique des données est prise en compte, utilise une approche heuristique; ce qui mène à des méthodes moins automatiques.
Deux principales sources d’informations existent pour permettre cette prise de connaissances. Ce sont les programmes et les données de l’application opérationnelle.
Ces propositions de cette catégorie ont fait émerger des concepts forts, comme par exemple les programmes d’application ou l’accès aux données de la base pour extraire la structure. Par contre, elles rencontrent des difficultés [Malki-2002] :
Dans les programmes d’application : la recherche d’information dans le code des applications peut s’avérer longue, fastidieuse et sans garantie de résultats.
Dans les extensions de la base : l’analyse des données peut aussi s’avérer longue et peu pertinente vu la taille des bases de données.
Parmi les approches de cette catégorie, nous citons :
[Premerlani et al.-1993]
Cette méthode exige en entrée le dictionnaire de données, les données de l’application et la connaissance de la sémantique de l’application. Elle adopte la notation OMT (Object Modeling Technique) pour la modélisation du schéma conceptuel.
Les clés peuvent être identifiées par l’analyse de données, les indexes et les connaissances de l’utilisateur. Les relations de généralisation peuvent être indiquées par les associations un à un.
Cette méthode préconise d’analyser les extensions de la base de données, les connaissances de l’utilisateur, les programmes pour identifier les contraintes qui ne sont pas exprimées dans le schéma physique.
[Mannila et al.-1994]
Elle exige en entrée un schéma relationnel en troisième forme normale. Le modèle cible est un modèle entités-associations. Elle effectue la restructuration d’un schéma relationnel en basant sur les dépendances fonctionnelles et les dépendances d’inclusion générale. Elle propose des procédures effectives de calcul pour extraire les dépendances fonctionnelles et d’inclusion à partir des données.
[Anderson-1996]
Cette méthode exige en entrée le schéma physique et les fichiers de code source en COBOL.
La sortie est un schéma entités-associations étendu appelé ERC+, qui étend le modèle entités-associations par l’instanciation multiple et les objets complexes.
Cette méthode extrait le schéma de base de données en troisième forme normale en identifiant les dépendances et le transforme en schéma ERC+.
[Signore et al.-1994]
Elle exige en entrée un schéma relationnel, requêtes SQL et un code source en langage élevé.
Le résultat est schéma entités-associations étendu avec objets complexes et généralisation.
Sa démarche se compose de trois phases. La première phase détermine les clés primaires. Si elles ne sont pas présentes dans le schéma relationnel, elles seront identifiées à partir de code source. La deuxième phase est pour la détection des indicateurs des synonymes et des contraintes de référence.
Ces indicateurs sont recherchés dans le code source et les requêtes SQL s’ils ne sont pas présents dans le schéma relationnel. Ils sont donc vérifiés à partir du caractère obligatoire de la contrainte d’intégrité dans le code et par l’utilisateur. La dernière phase est la conceptualisation. Le modèle conceptuel est dérivé à partir des indicateurs trouvés auparavant.
[Petit et al. -1995, Petit-1996]
Elle exige en entrée un schéma relationnel, les instances de données et le requêtes SQL.
La sortie est un schéma entités-associations étendu.
Elle analyse les conditions dans les requêtes pour récupérer les clés étrangères et les dépendances fonctionnelles. Puis, le schéma est restructuré pour obtenir un schéma logique en troisième forme normale.
Enfin, le schéma se transforme en schéma conceptuel validé par l’expert de domaine.
Dans [Lopes et al.-2002], la méthode est étendue par l’analyse de la navigation logique pour extraire les dépendances d’inclusion. La navigation logique est l’utilisation des colonnes de jointure comme un chemin d’accès pour naviguer dans la base de données relationnelle.
[Chiang-1995]
Elle exige en entrée une base de données relationnelle peuplée en troisième forme normale et que les attributs clés de même domaine doivent avoir les mêmes noms dans toutes les tables, vu que les noms des attributs clés sont utilisés pour introduire les références entre les tables. La base de données ne doit contenir aucune erreur dans les instances des attributs clés.
Le modèle cible est le modèle entités-associations étendu (EAE) avec généralisation.
Cette méthode se décompose en trois étapes principales : 1. La structuration de schéma de la base de données 2. L’identification des dépendances d’inclusion. 3. L’identification des concepts de modèle EAE suivant une liste des règles prenant en considération les dépendances d’inclusion.
[Jahnke -1999]
Cette méthode reçoit en entrée toutes les sources informations disponibles sur la base de données relationnelle : requêtes SQL, code procédural, extensions de la base de données, documentation, .etc. Le modèle cible est le modèle orientée objet (OMT).
Elle comprend deux phases : l’analyse de schéma et la migration vers le schéma conceptuel. Dans la première phase, la base de données est analysée pour obtenir une structure logique de données complète et consistante. Cette structure se transforme en schéma conceptuel dans la deuxième phase.
Sa contribution principale est d’utiliser un langage graphique appelé Generic Fuzzy Reasoning Nets(GFRN) pour représenter les connaissances de l’analyseur de schéma logique. En effet, elle permet de révéler les analyses incertaines et inconsistantes pour les traiter.
[Alhaij et al.-2001]
Cette méthode exige en entrée le schéma physique avec clés primaires et étrangères et demande la connaissance du système opérationnel. Le résultat est un schéma orienté objet.
Elle est basée sur la construction d’un modèle intermédiaire RIDG (Relational Intermediate Direct Graph) entre le relationnel et l’orienté objet. RIDG est un graphe dont les nœuds sont des tables et les arcs montrent l’existence d’une clé étrangère entre deux tables.
En fin de cette section, nous citons quelques approches génériques et d’autres approches récentes.
[Hainaut et al.-1993; Hainaut-1998]
C’est une méthode générique, i.e. une méthode indépendante du type de la base de données. Elle regroupe deux grandes phases :
La première, phase d’extraction des éléments décrivant le schéma physique de la base, consiste à obtenir un schéma logique des données (structure et contraintes). Cette phase consiste à analyser : les (ou le) fichier(s) décrivant la structure logique des fichiers, les programmes d’application pour compléter les connaissances sur les structures de données et sur les contraintes, des données (i.e. les instances de la base ou des fichiers). Dans le cas où plusieurs structures logiques (nommées vues) auraient été extraites, l’intégration de ces structures est prévue pour produire un schéma logique unique.
La seconde, phase de conceptualisation, permet la construction d’un schéma conceptuel à partir du schéma logique obtenu précédemment. Cette phase de conceptualisation est décomposée en trois étapes :
Préparation du schéma qui consiste à modifier les noms pour les rendre plus expressifs.
Conceptualisation de la base qui est composée d’une phase de dé-traduction qui consiste à produire un schéma conceptuel à partir du schéma logique et d’une phase de dé-optimisation où les structures optimisées du schéma logique sont supprimées.
Normalisation conceptuelle qui vise à rendre le schéma conceptuel en accord avec une démarche de conception particulière.
[Comyn et al.-1996]
Elle exige en entrée le code source de l’application, les requêtes SQL. Le résultat est le modèle entites-associations étendu avec attributs complexes et généralisation/spécialisation.
Cette méthode porte le nom MeRCI (Méthode de Rétro-Conception Intelligente). Elle est composée de cinq étapes. La première étape extrait le schéma physique à partir de dictionnaire de données, les requêtes SQL et les vues. La deuxième étape applique un ensemble de règles de retro-conception sur le schéma physique en examinant le code SQL et les extensions de base de données. La troisième phase identifie les types d’entité, les associations et les cardinalités en analysant les requêtes SQL, les synonymes [Signore et al.-1994] et les contraintes de référence. La quatrième étape extrait les relations de généralisation/spécialisation par l’analyse de données et de requêtes. La dernière étape identifie le schéma conceptuel.
[Akoka et al.-1998] présente un système expert implémentant la méthode MeRCI.
[Soutou-1998a]
Elle présente un algorithme qui permet d’extraire des associations n-aires. Cette analyse est traitée en deux étapes : Premièrement, l’information concernant les dépendances clés est utilisée pour identifier les relations candidates qui représentent des associations n-aires. Deuxièmement, un algorithme analyse les requêtes pour déterminer les cardinalités de ces associations. En se basant sur ces résultats, [Soutou-1998b] propose une méthode permettant d’extraire des liens d’agrégation dans les schémas relationnels.
[Sousa et al.-1999]
C’est une approche de rétro-conception des schémas de grandes bases de données, basée essentiellement sur le paradigme " diviser pour régner ". Leur idée est d’utiliser l’information relative aux clés qui permettent de classifier des relations en entités abstraites et en associations. Chaque entité abstraite (et association) représente un extrait du schéma de la base qui sera rétro-conçu séparément. Dans une étape finale, les sous-schémas résultant du processus de rétro-conception seront fusionnés en un seul schéma commun.
[Akoka et al.-1999]
Cette méthode appelée MeRCI-M est une extension de la méthode MeRCI [Akoka et al.-1998] à la rétro-conception des entrepôts de données.
Elle exige en entrée le schéma logique de l’entrepôt de données. Elle résulte un schéma entités-associations. Le processus de rétro-conception est exprimé par un ensemble de règles de transformation de schéma logique en schéma conceptuel.
[Malki-2002]
Cette approche nécessite l’utilisation des ontologies de domaine et l’interaction avec l’utilisateur (concepteur, administrateur, et expert de domaine), basée sur l’analyse de la structure et des instances des formulaires manipulant des bases de données. Elle se déroule en deux phases successives : l’extraction de l’aspect statique et l’extraction de l’aspect dynamique.
Dans la première phase, l’extraction de l’aspect statique consiste à :
- Extraire la sémantique des données des formulaires, à partir de l’analyse individuelle des formulaire (Structure et contenu) et le schéma relationnel de la base de données opérationnelle, afin de construire leurs schémas relationnels partiels.
- Transformer ces schémas en schémas objet partiels.
- Fusionner ces schémas objet partiels en un schéma objet global.
- Valider ce schéma objet global obtenu.
Dans la seconde phase, l’extraction de l’aspect dynamique permet de :
- Extraire les liens comportementaux des objets intra-formulaires tout en construisant leurs diagrammes de séquences.
- Extraire les liens comportementaux des objets inter-formulaires afin de construire leur réseau d’interconnexion de formulaire.
1.3.3 Synthèse des approches de Rétro-ingénierie des bases de données relationnelles
Nous présentons un tableau récapitulatif qui synthétise les contributions citées ci-dessus en respectant les critères de classifications suivants :
Modèle de données cibles : la deuxième colonne indique le modèle cible (Entités-associations ou Orienté-objet) utilisé par l’approche.
Prérequis : les approches dont la phase d’extraction de la sémantique des données n’est pas réalisée nécessitent un certain nombre de prérequis pour la transformation. La troisième colonne liste les prérequis à savoir : la 3FN (suivie d’une restructuration ou dénormalisation), la disponibilité de toutes les clés, des dépendances d’inclusion, un ensemble de dépendances fonctionnelles.
Source: les approches dont la phase d’extraction de la sémantique des données est prise en compte utilisent d’autres sources que le schéma physique de la base de données existante. La quatrième colonne présente ces sources telles que le code SQL et les instances de la base.
Méthode : Concernant la transformation, beaucoup d’approches sont basées sur les dépendances d’inclusion, certaines sur les clés et d’autres sont mixtes.
Phases complémentaires. D’autres phases s’ajoutent en amant et en aval de la transformation à savoir la restructuration, la classification, la validation et la migration.
Interaction utilisateur. Certaines approches nécessitent l’interaction avec l’utilisateur. La colonne six l’indique par Oui.
ApprocheModèlePrérequisSourcesMéthodePhases Comp.Util.[Casanova et al.-1983]EAClés, DI-ClésSchDINon[Dumpala et al.-1983]EAClés, DF, 3FNSchClésOui[Davis et al.-1987]EAClés, 3FNSchClésNon[Navathe et al.-1988]EAEClés, 3FNSchClésOui[Markowitz et al.-1990]EAEClés, DI-ClésSchDIRestNon[Kalman et al.-1991 ]EAEClés, 3FNSchClésOui[Ji-1991]OOClés, DI-ClésSch, InstDINon[Batini et al.-1992]EAEClés, 2FN/3FNSchClésRest, ClassOui[Fonkam et al.-1992]OOClés, 3FNSchClésOui[Premerlani et al.-1993]EAEClésSch, SQL, Inst.Clés, DIRest, ClassOui [Johannesson-1994]EAEClés, DI, 3FNSchDIOui[Mannila et al.-1994]EAEClés, DF, DISchDIRest, ClassOui[Signore et al.-1994]EAE-Sch, SQL, CodeClés, CodeRestOui[Chiang-1995]EAEClés, 3FNSch, InstDI, AnalRest, Class, ValOui[Fahrner et al.-1995b]OOClés, DI-ClésSchDI, ClésOui[Anderson-1996]EAEClésSch, Inst, CodeClés, DIRestOui[Petit-1996]EAEClésSch, SQL, Inst.Clés, DIRest, Class, ValOui[Ramanathan et al.-1996]OOClés, DI, 3FNSchClésClassNon[Akoka et al.-1998]EAEClésSchClésRest, ClassOui[Hainaut-1998]EAEClésSch, SQL, CodeClésRest,Class, Val,MigOui[Jahnke-1999]OOClésSchClésRest,Class,Val, MigOui[Alhaij et al.-2001] OOClésSchClés,AnalRest, MigOui[Malki-2002]OO-Frm, Ont, SchAnalRestOuiTableau 11: Les caractéristiques des approches de rétro-ingénierie de BDDs Relationnelles
Modèle cible : EA (Entité-Assoiation), EAE (Entité-Assoiation Etendu), OO (Orienté-Objet).
Prérequis : Clés, DI (Ensemble de dép. d’inclusion), DI-Clés (Ensemble de dép. d’inclusion basées clés), DF (Ensemble de Dép. fonctionnelles), FN (Forme normale assumée).
Sources : Inst (instances de Bases de données), SQL (code SQL), Sch (schéma physique), Frm (formulaire), Ont (Ontologie), Code(code de programme).
Méthode : Clés (Approche basée-Clés), Inc (Approche basée-Dep. Inclusion), Anal (Approche basée-Analyse de données)
Phases Complémentaires : Rest (Restructuration ou dénormalisation), Class (Classification), Val (Validation), Mig (Migration ).
1.3.4 Outils Industriels
Les outils actuels ne proposent qu’une fonctionnalité sommaire et souvent mécanique de rétro-ingénierie, limitée aux seules structures de données (ACM-Designor, Oracle designer 2000, Mega, PowerBuilder, Rational Rose, Tbuilder, Silverrum, Powersoft, LogicWorks, WinDesign, etc.)[Malki-2002]. Les possibilités de rétro-ingénierie sont donc liées aux outils de conception puisqu’ils ne peuvent s’appliquer que sur les schémas qu’ils ont eux-mêmes conçus et sur lesquels aucun effet pervers de la maintenance n’est permis.
La limite principale de ces outils est que seule la traduction du schéma relationnel dans un schéma conceptuel est traité. Ils conduiront souvent à de mauvais résultats si on les applique sur des cas réels.
Hainaut et son équipe ont développé un atelier de génie logiciel appelé DB-MAIN [Hainaut-1998], dont les fonctionnalités de rétro-ingénierie sont les plus avancés sur le marché. Il est conçu comme une boîte à outils d’analyse de structures de données et de programme pour un grand nombre d’environnements différents. Il intègre des possibilités de recherche d’informations dans les fichiers sources des applications et propose une grande variété de transformations pour l’obtention d’un schéma conceptuel.
´1.4 Conclusion
Nous avons présenté dans ce chapitre un état de l’art relatif à la rétro-ingénierie des bases de données. Nous avons donné une classification des approches de rétro-ingénierie des bases de données selon la prise en compte ou non de l’extraction de la sémantique des données. Les principales approches ont été présentées. Nous constatons que des approches récentes de rétro-ingénierie utilisent les ontologies de domaine comme source sémantique complémentaire dans l’extraction de la conceptualisation. Dans le chapitre suivant, nous donnerons une description des ontologies et leur utilisation.
CHAPITRE II
Les Ontologies
Chapitre 2: Les Ontologies
2.1 Introduction
L’ingénierie de nouveaux systèmes d’information et la ré-ingénierie des systèmes existants (i.e. la rétro-ingénierie suivie de l’ingénierie directe) sont des procédures coûteuses. Ce coût est dû en partie à la difficulté de définir un domaine particulier de façon formelle et au temps nécessaire à la modélisation qui en découle. Pourtant chaque application, aussi spécialisée soit-elle, se réfère à un domaine dont d’autres applications utilisent déjà les connaissances et il serait possible de diminuer ce coût de conception (et/ou de ré ingénierie) en partageant certains de ces données et en réutilisant certains modules. Pour pallier les problèmes d’échanges et de modularité et favoriser la compréhension et la lisibilité des données et des programmes, certains membres de la communauté scientifique ont choisi d’utiliser les ontologies.
Dans ce chapitre, nous décrivons les ontologies, leurs définitions, leurs rôles, ainsi que quelques domaines d’utilisation.
2.2 Définitions
Le terme ontologie se réfère au sujet d'existence dans le domaine de la philosophie. Il est définit comme étant : l’étude de l’être en tant qu’être et l’étude de l’existence en général. Dans l'intelligence artificielle et l'ingénierie de connaissance, il est défini comme une spécification explicite d'une conceptualisation [Gruber-1993]. Une conceptualisation est une vision abstraite et simplifiée du domaine à représenter. Elle contient les objets, les concepts et les entités qui décrivent le domaine en plus des associations qui existent entre eux.
Une ontologie peut également être considérée comme une convention de vocabulaire et de relations entre les mots de ce vocabulaire pour parler d’un sujet donné. Les relations sont de plusieurs types : ce peut être des relations d’hyponymie (‘sorte de ’), nominatives (‘a pour nom’), locatives (‘est situé sur’), relations de métonymie (‘partie de’) ou toute autre relation associative (‘a pour fonction’ ; ‘est associé à’, etc.). [Malki- 2002]
Les ontologies peuvent être classifiées en fonction de deux dimensions : leur niveau de détail et leur niveau de dépendances par rapport à une tâche particulière et un point de vue [Guarino-1998]. Nicola Guarino distingue plusieurs niveaux dans les ontologies (Figure 2.1) :
Les ontologies de haut niveau contiennent des concepts généraux, commun à tous les domaines (temps, espace, objet et évènement).
Les ontologies liées à un domaine particulier sont de deux types : i) soit elles contiennent le vocabulaire spécifique à un domaine bien défini et sont des spécialisations d’une ontologie de haut niveau, ii) soit il s’agit d’ontologies de tâches qui contiennent l’ensemble des tâches réalisées dans un domaine donné.
Les ontologies d’applications dépendent à la fois d’un domaine et d’une tâche.
Ainsi, une ontologie peut être vue comme une théorie qui distingue les concepts particuliers, c’est-à-dire les objets concrets, physiques, les évènements, les régions, etc., et les concepts universels c’est-à-dire les propriétés, rôles, relations, états, etc.
EMBED Word.Picture.8
Figure 21: Différents types d’ontologies selon leur degré de dépendance vis-à-vis d’une tâche particulière ou d’un point de vue
2.3 Le rôle des ontologies
L'ontologie peut servir, selon [Uschold et al.-1998], les objectifs de :
Communication (entre humains et/ou organisations) : le bénéfice d'usage d'ontologie ici est sans ambiguïté. Dans l'ontologie, il n'y a jamais deux termes ayant la même signification. Cette situation se produit chaque fois que l'on utilise un langage naturel pour la communication.
Interopérabilité (machines et systèmes): l'ontologie peut être utilisée comme un modèle intermédiaire pour la traduction entre les modélisations de différentes collections d'objets. Elle sert à définir le format d'échange entre systèmes.
Le partage et la réutilisation des informations: l’utilisation des ontologies permet la mise en correspondance des contenus sémantiques des objets utilisés dans différents systèmes. Elle facilite la réutilisation des objets par d’autres systèmes, au moyen d’une traduction automatique.
Ingénierie des systèmes : l'ontologie peut servir divers aspects du développement des systèmes d'information. Elle peut assister le processus de construction de spécification du système. Son usage rend les documents de processus plus compréhensibles et évite l'ambiguïté dans la spécification. En outre, une représentation formelle d'ontologie permet un traitement automatique du développement et soutient également l'automatisation du processus de vérification de la fiabilité des systèmes.
Pour Sowa [Sowa-2000b], " l'ontologie permet de définir les mots d’un langage naturel, les prédicats utilisés dans le calcul de prédicats, les types de concepts et de relations des graphes conceptuels, les classes d’un langage orienté objet ou les champs des tables d’une base de données relationnelles".
Le partage de connaissance est la tâche qui peut jouer un rôle important dans le processus de spécification des systèmes d’information (SI). Guarino [Guarino-1998] propose d’utiliser les ontologies dans le développement et l’exploitation des SI :
Durant le développement (i.e. l’analyse, la conception et l’implémentation), la sémantique exprimée par une ontologie prédéfinie dans une bibliothèque ontologique peut être transformée dans un SI, ce qui permet de réduire considérablement le temps nécessaire pour l’analyse conceptuelle. Une approche informelle devrait utiliser des connaissances stockées dans une ontologie en facilitant le processus d’identification des besoins du système et comprendre les liens sémantiques des composants du système. Tandis que l’approche formelle devrait utiliser l’ontologie comme une spécification déclarative. En utilisant cette méthode, l’application des connaissances du domaine (i.e. l’ontologie) peut être plus facilement partagée aux travers des projets différents et des plates-formes hétérogènes sous forme d’un vocabulaire commun.
Durant l’exploitation des SI, l’utilisation la plus évidente des ontologies concerne le lien de tous les composants de la base de données (i.e. les relations et leurs champs). La disponibilité des ontologies qui décrivent des ressources de l’information est au cœur de l’approche basée sur la médiation pour l’intégration de l’information. En les considérant comme des descriptions génériques d’un domaine, les ontologies peuvent être utilisées pour supporter la construction dynamique de requêtes concernant les bases de données hétérogènes et distribuées.
Pour pouvoir utiliser puis exploiter une ontologie, deux problèmes essentiels se posent [Malki -2002].
1- En terme d’élaboration de l’ontologie, il est nécessaire de trouver une méthodologie permettant sa construction, car il s’agit d’une tâche complexe surtout si l’ontologie est de taille importante.
2- Pour pouvoir exploiter une ontologie dans un système informatique opérationnel, il est nécessaire de la représenter (notamment au niveau de sa structure et de la sémantique associée aux concepts qu’elle définit) au moyen de langages plus ou moins formels.
2.4 Les composants d’une ontologie
Les composants les plus communs entre les différents langages de représentation sont :
Les classes (concepts) : les classes dans une ontologie sont généralement rangées dans une taxonomie analogue à celle du modèle orienté objet. Les concepts sont utilisés dans un large sens et peuvent être abstraits ou concrets. Plus précisément, un concept peut être n’importe quelle chose dans le domaine à décrire. Par exemple un concept peut être une tâche, une fonction, une action, une stratégie, etc. En général, chaque classe dans une ontologie contient un nom qui est unique dans l’ontologie et une liste de synonymes.
- Les relations : les relations représentent un type d’interaction entre les concepts d’un domaine.
Une représentation formelle de relation est définie formellement comme un sous-ensemble d’un produits cartésien de n ensembles, R : C1X C2X…. XCn. Un exemple d’une relation est A sous-ensemble B.
- Les fonctions sont des cas spéciaux de relations dans lesquelles le nième élément de la relation est unique pour les n-1 éléments précédents. Formellement une fonction est définie par, F :C1X C2X...Cn-1 XCn. Un exemple d’une fonction binaire Mère-de.
- Les axiomes sont utilisés pour décrire les phrases valides ou bien toujours vraies. Les axiomes sont aussi utiles pour formuler les contraintes sur les attributs des classes et les valeurs correspondantes. Ils utilisent généralement des expressions de la logique du premier ordre pour décrire des contraintes.
- Les instances sont utilisées pour représenter les éléments dans un domaine ou bien ce qu’on appelle individu dans un certain langage. La particularité des instances consiste à définir des connaissances génériques.
- Les attributs (slots/facettes) : les slots sont des restrictions des concepts ou des classes. A chaque concept est associé un ensemble de slots et à chaque slot est associé un ensemble de facettes.
2.5. Les domaines d'utilisation d'ontologies
2.5.1 Les ontologies et le processus d’ingénierie des systèmes d’information
Le besoin de traiter la sémantique pour construire de meilleurs systèmes d’information est un sujet de recherche très important aujourd’hui. Les ontologies peuvent participer dans chaque étape du processus, à partir de la phase de conception d’un système jusqu’à la construction de l’interface utilisateur et l’interrogation et l’intégration de l’information [Bouchiha-2005]. Plusieurs approches tendent à introduire le concept d’ontologie dans le processus de développement et d’exploitation de système d’information : Sowa, dans [Sowa-2000a] considère que le programmeur a la connaissance pour implémenter une solution, mais la façon pour codifier cette connaissance varie d’un individu à un autre. Le programmeur et le concepteur ont leur propre ontologie, et ils peuvent être soit implicites soit explicites. Guarino invente le terme système d’information orienté ontologie, pour les systèmes qui utilisent des ontologies formelles [Guarino-1998]. Frederico, dans [Frederico-2001] introduit l’utilisation des ontologies dans le développement des systèmes d’information géographiques et propose des techniques pour intégrer les informations géographiques en utilisant les ontologies. La nouvelle génération des systèmes d’information devrait utiliser les ontologies pour résoudre le problème d’hétérogénéité sémantique dans le contexte de l’informatique distribuée (par exemple l’Internet et le Web). Les ontologies peuvent être aussi utilisées pour l’intégration des informations.
2.5.1.1 Processus traditionnel de développement des systèmes d’information
Les approches traditionnelles de développement des systèmes d’information commencent par une analyse de besoin, puis passent à la conception qui est une abstraction ou une description structurelle (statique) et fonctionnelle (dynamique) du monde réel. Enfin, ils implémentent le système en créant les bases de données et les programmes. Ces phases des systèmes d’information traditionnels sont illustrées dans la figure 2-2.
Figure 22: Méthodologie de développement des systèmes d’information
Telle approche force le concepteur à transformer mentalement les concepts acquis du monde réel en instances d’abstractions disponibles dans son paradigme choisi. La transformation est faite informellement et d’une façon ad-hoc, de ce fait introduisant des inconsistances et des inexactitudes qui mènent inévitablement à des conflits entre les concepts de l’utilisateur et les abstractions capturées dans le modèle conceptuel. Ces inexactitudes se produisent parce que la vue du spécialiste est différente à celle du concepteur du problème. La figure 2-3 illustre cette situation, montrant avec des lignes en tirées les chemins les plus problématiques pour l'acquisition des connaissances dans le processus de conception traditionnel.
Figure 2-3: Processus de conception traditionnel
La raison principale de ces conflits est le manque d’un accord initial entre l’utilisateur et le concepteur sur les concepts du monde réel. Tel accord peut être établi en utilisant une ontologie, qui est une conceptualisation partagée d’un domaine d’application.
2.5.1.2. Processus de développement des systèmes d’information à base d’ontologie
Dans le processus de développement des systèmes d’information, l’ontologie peut être utilisée comme un outil de formalisation des concepts et des idées suivant la vision du spécialiste au problème traité [Frederico et al.-2003]. Le degré de formalisation fourni par les ontologies peut corriger les erreurs induites sur le schéma conceptuel par le concepteur. Puisque les ontologies fournissent une vue de haut niveau du problème, le concepteur sollicite le spécialiste pour mieux spécifier des détails sur le schéma conceptuel, tels que les cardinalités et les types d’attributs. Cette approche orientée ontologie pour la conception des systèmes d’information est illustrée dans la figure 2.4
.
Figure 2-4: Processus de conception orienté ontologie
2.5.2. Les ontologies et les bases de données
En système d’information d’entreprise comme dans tout autre domaine (à savoir les SI : géographiques, biologiques, médicaux, etc.), les ontologies vont pouvoir jouer le rôle clé de représentation et de compléter l’information relative aux données à un niveau d’abstraction supérieur [Cui et al.-1999; Meersman-1999]. Les modèles de données présentent un certain nombre de limites. Par exemple, les modèles conceptuels de données se basent sur un seul point de vue dans un domaine, les ontologies peuvent s’étendre au-delà des modèles de données puisqu’on peut représenter dans une ontologie l’ensemble formel des connaissances et des vocabulaires utilisés [Dowell et al.-1995].
La figure 2.5 [Cui et al.-1999] montre les liens entre l’ontologie, les schémas EA et les schémas de la base de données. Ainsi, l’ontologie est utilisée pour représenter des besoins d’information de haut niveau. Les schémas (relations) et les classes sont des concepts de niveau données qui sont des implémentations dépendantes. A ce niveau, les contraintes sont de types opérationnelles dont la majorité ne sont pas représentés explicitement. Cependant, les ontologies peuvent être utilisées pour définir des schémas de bases de données.
EMBED Word.Picture.8
Figure 2-5: Le lien entre l’ontologie et les sources de données (Schéma EA et relationnel
2.5.3 Traitement du langage naturel
La reconnaissance de similitudes conceptuelles entre les mots permet essentiellement d'améliorer la recherche documentaire. Dans les moteurs de recherche actuels, une requête est composée d'un ensemble de mots éventuellement connectés par les opérateurs logiques Ou, Et et Non. Le moteur produira sa réponse en fonction des mots contenus dans les documents parcourus. L'utilisation d'ontologies par ces moteurs doit permettre de retourner, en plus, les documents pertinents par rapport à la sémantique des mots de la requête.
2.5.4 Web sémantique
La popularisation des accès haut débit au réseau Internet provoque un fort engouement sur ce média de communication. Autrefois réservé aux professionnels de l'informatique avec un contenu essentiellement scientifique, celui-ci est aujourd'hui accessible à tous pour une utilisation très variée. Que ce soit pour faire ses démarches administratives, rechercher un emploi ou bien d'autres choses, tout le monde a perçu les bénéfices de ce vecteur de communication.
Cette formidable source d'informations souffre pourtant d'un défaut majeur qui décourage bien des débutants. Alors que l'on parle d'une toile pour décrire ce réseau, l'ensemble des services qui y sont offerts sont complètement isolés. En conséquence, pour arriver au résultat escompté, une personne doit soit avoir une connaissance approfondie du Web, soit passer par une longue période fastidieuse d'errance sur différents sites.
L’idée principale du Web Sémantique [Berners-Lee-01] est de rendre les données compréhensibles par des agents automatiques en définissant des ontologies qui puissent être partagées et référencées sur le Web.
2.6 L’ontologie WordNet
WordNet est un système logiciel qui a été développé par l'université de Princeton qui vise à être une base de données lexicale. WordNet est fondamentalement un système de référence lexical en ligne dont la conception est fortement inspirée des théories psycholinguistiques récentes de la mémoire sémantique humaine. Les noms, les verbes, les adjectifs et les adverbes anglais sont organisés en ensembles de synonymes (synset), chacun représente un concept lexical. Différentes relations lient les synsets sous forme de réseau sémantique.
WordNet peut être utilisée autant qu’un dictionnaire ordinaire. Aussi, elle peut être utilisée dans des applications plus complexes telles que le calcul de la distance sémantique entre les concepts.
2.7 Conclusion
Les ontologies offrent une base solide au développement de nouvelles méthodes d’application et de raisonnement sur les connaissances. Outre leur apport en matière de réutilisabilité, de modularité et de partage de connaissances, les ontologies permettent de définir un vocabulaire précis, sur lequel se base la communication entre les différents acteurs d’un projet. Elles sont également utilisées pour la description des langages naturelles et l’annotation de documents. Enfin, les ontologies permettent de simplifier l’étape d’analyse et de synthèse d’une partie de la connaissance dans le développement [Storey et al.-1998] et la rénovation (i.e. ré-ingénierie) [Yang-1999] des systèmes d’information et diminuent de ce fait le coût de conception et de rétro-conception de ces systèmes.
L’utilisation des ontologies dans le processus de rétro-ingénierie des bases de données concrétise une approche hybride ascendante et descendante d’abstraction des données [Malki-2002].
CHAPITRE III
Les Notations ORM et UML
Chapitre 3: Les Notations ORM et UML
3.1 Introduction
ORM et UML sont deux notations de modélisation de systèmes d’informations. Elles sont de deux générations différentes. ORM est une méthode systémique et UML un langage orienté objet. Chacune d’elles présente des avantages et des inconvénients. Notre travail vise à combler des lacunes d’UML en matière de capture de la sémantique des données de l’univers de discours en proposant une approche inspirée de la méthode ORM. Autrement dit, notre proposition vise à faire bénéficier UML de la puissance d’ORM. Pour cela, nous présenterons dans ce chapitre une description générale des deux notations, en détaillant les concepts qui nous intéressent dans notre proposition.
3.2 La méthode ORM
3.2.1 Introduction
ORM est une méthode de modélisation conceptuelle qui considère tout domaine d’application comme un ensemble d'objets (entités ou valeurs) qui jouent des rôles entre eux (parties dans les relations) [Halpin-2004a]. Elle a été développée dans les années 70 et a succédé NIAM (Natural-language Information Analysis Method) [Verheijen et al.-1982].
Le modèle ORM présente une sémantique riche pouvant être exprimée syntaxiquement dans les langages graphique et textuel formellement d'un niveau suffisamment élevé pour être utilisée par les utilisateurs non techniciens afin d'exprimer et valider les règles d’un domaine donné [Halpin-2001a].
Bien qu’ORM soit conçue à l’origine comme approche de modélisation de base de données, elle est réutilisée par la suite en d’autres scénarios de modélisation conceptuelle, comme la conception du schéma XML [Bird et al.-1999], La modélisation de règles de gestion [Halpin-2004b; North-1999; Demy et al.-2002], la conception des systèmes Web, la modélisation des ontologies [Jarrar et al.-2003; Jarrar -2005], etc.
En outre, Il existe plusieurs outils de modélisation conceptuelle qui utilisent ORM comme IAST, RIDL*, CaseTalk, Microsoft VisioModeler, ActiveQuery, Microsoft Visio Enterprise, etc. Ils permettent la modélisation d'un domaine de l'univers de discours et supportent la génération automatique de schéma de base de données relationnelle normalisé et cohérent [Jarrar et al.-2003].
Dans la section suivante, nous verrons les principaux concepts de la notation ORM.
¶¶
3.2.2 Les concepts de base
3.2.2.1 NOLOT
Les types d'objets non lexicaux (NOLOT : Non Lexical Object Type) représentent des concepts (exemple: étudiant, groupe,…). INCLUDEPICTURE "D:\\..\\khadhir\\magister\\miniprojet\\miniprojet\\belalem\\web niam_fichiers\\image1.gif" \* MERGEFORMATINET \d \z"
3.2.2.2 LOT
Les types d'objets lexicaux (Lexical Object Type) sont la représentation totale ou partielle d'un NOLOT (Exemple. : Le " N° étudiant " est un LOT représentant le NOLOT "Etudiant")
3.2.2.3 Les liaisons binaires (Les types d’idées)
- Un type d’idée (ou prédicat) est une liaison binaire entre deux NOLOTs. C'est une relation binaire (Exemple. : " Un étudiant appartient à un groupe ").
On distingue deux rôles :
- L'étudiant joue le rôle " appartient à " dans l'idée " Appartenance ".
- Le Groupe joue le rôle " comprend " dans l'idée " Appartenance ".
Exemple
EMBED Word.Picture.8
Figure 3-1: Exemple de type d'idée
3.2.2.4. Le sous typage :
Considérons l’exemple suivant :
EMBED Word.Picture.8
Figure 3-2: Exemple de sous typage
Pour montrer que les femmes qui accouchent, on fera le sous typage de l’entité humain en deux entités homme et femme [Henri-1993].
ORM permet de formaliser la notion conceptuelle de l’appartenance (une femme est un humain) à travers la notion de sous-typage.
3.2.2.5 Les contraintes INCLUDEPICTURE "D:\\..\\khadhir\\magister\\miniprojet\\miniprojet\\belalem\\web niam_fichiers\\image7.gif" \* MERGEFORMATINET \d \z"
3.2.2.5.1 La contrainte d'unicité
a) Sur un rôle
La contrainte d'unicité est représentée par la double flèche sur le rôle.
EMBED Word.Picture.8
Figure 3-3: Contrainte d’unicité sur rôle
Une occurrence de A à 0 ou 1 lien avec une occurrence de B
b) Sur une idée
EMBED Word.Picture.8
Figure 3-4: Contrainte d’unicité sur idée
Une occurrence de A à 0 ou plusieurs liens avec une occurrence de B et vis versa.
Un couple (a, b) d’occurrence de A et B est unique.
c) Entre rôles
EMBED Word.Picture.8
Figure 3-5: Contrainte d’unicité entre rôles
Pour une occurrence de B et une occurrence de C, participant aux relations R1 et R2, correspond à une et une seule occurrence de A
3.2.2.5.2 La contrainte de totalité
a) sur une entité (rôle obligatoire)
EMBED Word.Picture.8
Figure 3-6: Contrainte de rôle obligatoire
Toutes les occurrences de A ont des liens (1 ou plusieurs) avec des occurrences de B.
b) entre rôles :
EMBED Word.Picture.8
Figure 3-7: Contrainte de totalité entre rôles
L’union de l’ensemble des occurrences de A ayant des liens avec des occurrences de B, avec celui des occurrences de A ayant des liens avec celles de C est l’ensemble des occurrences de A.
c) entre sous types
EMBED Word.Picture.8
Figure 3-8: Contrainte de totalité entre sous types
3.2.2.5.3 La contraintes d’exclusion
a) entre rôles :
EMBED Word.Picture.8
Figure 3-9: Contrainte d’exclusion entre rôles
L’intersection des occurrences de A ayant des liens avec des occurrences de B et celles de A ayant des liens avec des occurrences de C est vide.
b) entre idées :
EMBED Word.Picture.8
Figure 3-10: Contrainte d’exclusion entre idées
L’intersection de l’ensemble des couples de la relation entre A et B via la première idée avec l’ensemble des couples de la relation entre A et B via la deuxième idée est vide.
c) entre sous types :
EMBED Word.Picture.8
Figure 3-11: Contrainte d’exclusion entre sous types
3.2.2.5.4 Autres contraintes :
Avec le même principe des contraintes précédentes, nous avons la contrainte de sous-ensemble et la contrainte d’égalité. (Pour plus de contraintes voir [Verheijen et al.-1982] et [Wintraecken-1990]).
3.2.3 La CSDP d’ORM
3.2.3.1 Introduction
CSDP (Conceptual Schema and Design Procedure) a été développée originalement par les professeurs G.M Nijssen (de l’université de Queensland) et E.D Falkenberg (Katholieke universiteit, Nijmengen). L’idée de base est d ‘exprimer les concepts du schéma conceptuel en phrases élémentaires du langage naturel. L’approche fondamentale est de construire une conception en commençant avec des exemples significatifs ( cas d’utilisation de données) et puis suivre une procédure bien définie utilisant des diagrammes visuels claires et peuplés pour des buts de validation. On obtient en dernier un schéma conceptuel final d’ORM.
Dans le monde commercial, il y a beaucoup d'applications existantes qui ont été mises en application ¶en utilisant des approches d'un niveau inférieur, ayant pour résultat des conceptions de base de données qui peuvent être contradictoires, ¶incomplètes, inefficaces ou difficiles à maintenir. De tels systèmes sont souvent mal documentés. Ces problèmes peuvent être surmontés par le reengineering des applications existantes en employant des techniques de modélisation conceptuelle. Par exemple, quelques exemples des tables de base de données existantes peuvent être employés comme entrée au CSDP. La conception peut alors être validée et complétée en communiquant avec un expert de domaine. ¶Le schéma conceptuel sera transformé au système de base de données cible pour fournir une ¶exécution améliorée et maintenable. CSDP peut être considérée, ainsi une approche de rétro-ingénierie de bases de données [Halpin-2004a].¶¶
Nous verrons dans cette section les différentes étapes de la CSDP suivant un exemple.
3.1.3.2 La démarche de CSDP :
La CSDP est une procédure de neuf étapes :
Transformer des exemples d'informations familiers en idées élémentaires et appliquer des versifications de qualité.
Dessiner un premier brouillon du SC (diagramme) et appliquer une vérification de population.
Eliminer les types d'entités en surplus et les rôles communs et identifier les types d'idées dérivées.
Ajouter les contraintes d'unicité pour chaque type d'idée.
Vérifier que les types d'idées sont de l'ordre droit.
Ajouter les contraintes de type d’entité, de totalité, de sous type et de fréquence d'occurrence.
Vérifier que chaque entité peut être identifiée.
Ajouter des contraintes d'égalité, d'exclusion, de sous ensemble et d'autres contraintes.
Vérifier que le schéma conceptuel est cohérent avec les exemples originaux, n'a pas de redondance et complet.
La procédure débute avec l’analyse des exemples d’informations qui vont être une sortie ou une entrée d’un système d’information initial.
Tout au long de la procédure, des vérifications sont accomplies pour s’assurer qu’aucune erreur n’a été faite.
CSDP peut être appliquée sur plusieurs parties ou modules de l’univers de discours. Les schémas conceptuels résultants seront intégrés dans un schéma global.
CSDP ETAPE 1 : Des exemples aux idées.
Transformer des exemples d’informations familières en idées élémentaires.
La première étape est de commencer avec des exemples familiers d’informations pertinentes de l’U°D (cas d’utilisation de données) et les exprimer en idées élémentaires, indécomposables et sans perte d’informations.
Une idée élémentaire est une assertion simple ou une proposition atomique sur l’U°D où les objets particuliers jouent des rôles particuliers.
Exemple (extrait de listing d’un SI précédant)
EmployéDeptSuperviseurSit FamTel.DomAnnee MariageNb. enfantsAllocation (DA)MoussaD1AhmedM3715821200321000NaceurD1MoussaC----BrahimD2MoussaM-2005--AhmedD2*M3783437200600N.B : « * » = ‘inexistant’ « - » = ‘non enregistré’
Tableau 3-1: Exemples familiers d’informations pertinentes de l’U°D
Cette étape consiste à relever les informations contenues dans la première ligne en terme d’idées élémentaires.
Résultats :
Employé avec le nom ‘Moussa’ travaille dans le département avec code ‘D1’
Employé avec le nom ‘Moussa’ a Sit.fam avec le code ‘M’
Employé avec le nom ‘Ahmed’ est superviseur de l’employé avec le nom ‘Moussa’
Employé avec le nom ‘Brahim’ est marie à l’année ‘1975’.
Superviseur avec le nom ‘Moussa’ a tel.dom avec le numéro ‘3715821’
Superviseur marie avec le nom ‘Moussa’ a nb enfants avec le nombre ‘2’
Superviseur marie avec le nom ‘Moussa’ a allocation avec la valeur ‘1000 DA’
Vérification de qualité sur les idées élémentaires
La vérification consiste à demander les questions suivantes :
Les idées sont bien elle identifiées ?
Les idées peuvent elles être divisées en idées plus petites sans perte d’informations ?
CSDP ETAPE 2 : Premier brouillon du diagramme de SC.
Cette étape consiste à dessiner un diagramme qui montre tous les types d’idées. Pour ce faire, on a besoin d’une convention pour illustrer les types d’entités, les types d’étiquettes et les rôles.
On présente en premier un diagramme d’occurrence
Pour la première idée élémentaire, on aura le schéma suivant :
EMBED Word.Picture.8
Figure 3-12: Premier brouillon du diagramme d’occurrences
.
Le schéma conceptuel correspondant à ce diagramme d’occurrence est le suivant :
EMBED Word.Picture.8
Figure 3-13 : Premier brouillon du diagramme du S.C.
Pour cet univers de discours, chaque employé a exactement un seul nom, et chaque nom de personne se réfère exactement à un employé. Ce type de référence est appelé la référence1 :1.
Quand ce cas existe, on doit mettre le mode de référence entre parenthèses à côté du nom du type d’entité.
On fait de la même chose pour les autres idées. On aura les concepts suivants :
Employé:
EMBED Word.Picture.8
Employé Marié:
EMBED Word.Picture.8
Superviseur:
EMBED Word.Picture.8
Superviseur marié:
EMBED Word.Picture.8
Figure 3-14 : Les concepts extraits des exemples
CSDP ETAPE 3 : Arranger le schéma et trouver les types d’idées dérivés
Cette étape consiste à éliminer les types d’entités en surplus, à déterminer les rôles communs et identifier n’importe les types d’idées dérivées. Dans cette étape, les questions pertinentes que nous nous demandons peuvent être résumées ainsi :
Une même entité peut-elle être membre de deux types d’entités ? Si oui combiner les entités en une seule.
Des entités de types différentes peuvent-elles être comparées significativement ? Si oui combiner les types d’entités en un seul.
Toutes les instances de deux types d’entités différents peuvent-elles jouer le même rôle ?
Si oui combiner les types d ‘entités en un seul et si nécessaire ajouter un autre type d’entités pour préserver la distinction originale.
Un type d’idée est-il dérivable d’autres ?
Si c’est le cas, marquer le type d’idées avec « * » et fournir une règle de dérivation.
En vérifiant notre brouillon de schéma conceptuel, on trouve que la valeur de allocation peut être dérivée de la valeur de nb.enfants par la règle suivante : Allocation=500*Nb.enf, alors on applique la règle 4 sur le schéma conceptuel de superviseur marié et il devient :
EMBED Word.Picture.8
Figure 3-15 : Exemple de type d'idée dérivé
CSDP ETAPE 4 : Contraintes d’unicité
On représente cette contrainte par un placement d’une double flèche (ou barre) sur le rôle pour indiquer que pour chaque entrée la colonne doit être unique.
Exemple1 : Les entrées de l’entité employée sont uniques dans l’idée ‘emploie’.
EMBED Word.Picture.8
Figure 3-16: Exemple de contrainte d’unicité sur un rôle
Exemple2 : dans le prédicat ….. a tel…….., chaque entrée dans la colonne doit être unique.
EMBED Word.Picture.8
Figure 3-17 : Exemple de contrainte d’unicité sur deux rôles
Il existe quatre possibilités d’appliquer la contrainte d’unicité sur une idée binaire (plusieurs : plusieurs, plusieurs : un, un : plusieurs, un : un)
EMBED Word.Picture.8
Figure 3-18: Les possibilités des contraintes d’unicité sur les rôles
Sur les idées ternaires, on peut avoir huit possibilités de la contrainte d’unicité
Les contraintes impliquant la jointure ou l’emboîtement
On veut exprimer la règle suivante : un superviseur ne peut superviser qu’un seul employé par département.
Autrement dit, pour n’importe quelle combinaison (superviseur, dep) il y’a au plus un seul employé.
EMBED Word.Picture.8
Figure 3-19: Le résultat de l'étape 4
CSDP ETAPE 5 : Les vérifications de l’ordre
Elle consiste à vérifier que les types d’idées ont un ordre exact.
Si nous étions plus précis dans les étapes précédentes, alors celle-ci n’est pas exigée.
Elle permet de vérifier l’ordre d’un type idée c-à-d vérifier qu’elle ne doit être ni trop longue, ni trop courte.
Pour vérifier l’ordre dans la procédure CSDP, trois méthodes peuvent être utilisées :
Utiliser votre sens commun ou la connaissance antécédente de l’U°D lors de la décision de la perte d'information par une division d’un type d’idée.
Utiliser les règles de division de la petite clé.
Fournir une table d’idées significatives pour le type d’idée, diviser celle-ci par projection et ensuite la recombiner par jointure naturelle. Si de nouvelles instances apparaissent alors le type d’idée est indivisible. Tester les chemins disponibles jusqu'à ce qu’une division soit trouvée ou que tous les chemins soient exhaussés.
La vérification de la longueur de la clé :
Chaque combinaison des rôles qui sont marqués par une contrainte d’unicité 1 :1, est appelée ‘clé’ du type d’idée.
La règle suivante nous fournit le cas de division avec la vérification de la longueur de la clé.
Un type d’idée n-aire peut être divisé s’il a une clé de longueur inférieure à n. Cette règle n’est valable que dans le cas des types d’idées de longueur 3 ou plus.
Comme dans notre exemple les types d’idées sont de type binaire, alors l’ordre est vérifié.
CSDP ETAPE 6 : Plus de contraintes : ajouter les contraintes de types d’entités, de rôles obligatoires, de sous type et de fréquence.
Les contraintes de type d’entité :
Elles spécifient une restriction sur les valeurs possibles des instances d’un type d’entité données.
Dans notre exemple, on rétrécit par exemple la liste des départements :{D1, D2} et les codes Sit. Fam. {M, C}.
Les rôles impératifs et optionnels :
Un rôle est impératif si et seulement si pour chaque état de la BD, il doit être enregistré pour tout membre de l’entité qui joue ce rôle, sinon il est optionnel.
Nous constatons dans notre exemple que le rôle de type entité employé est impératif dans le type d’idée ‘a situation familiale’.
Il en est de même pour superviseur avec le type d’idée ‘a tel. domicile’.
Le rôle impératif est marqué par un point.
EMBED Word.Picture.8
Figure 3-20 : Le rôle impératif de l’entité superviseur
Le sous typage :
On fait recours à l’expert de domaine pour définir l’arbre de sous typage. Cependant, une technique d’analyse de la matrice de sous typage peut être utilisée.
Procédure d’analyse de la matrice de sous typage :
Considérons T le tableau des exemples de ce système d’informations
Construire la matrice partition/détails pour T.
Lister les détails enregistrés pour tous les membres de T comme des entêtes de colonnes.
Partitionner A en groupes selon leurs modèles enregistrés et lister ces groupes comme entêtes de lignes.
Entrer le modèle enregistré pour chaque groupe. (1=détails enregistrés, 0=détails non enregistrés).
Esquisser le graphe de sous typage et les détails attachés.
Etiqueter les différents modèles de colonnes comme nœuds A,B,C,D. etc.
Partitionner et déterminer les relations de sous typages entre nœud comme suit :Le nœud x est un sous ensemble de nœud y si pour chaque ligne ou x =0, y=0.
Dessiner le graphe de sous typage et enlever les arcs impliqués transitivement.
Attacher à chaque nœud le (s) rôles(s) indiqués par leurs entêtes de colonne.
Fournir définitions et noms significatifs pour les sous types.
Définir chaque sous type en termes d’un ou plusieurs rôles attachés à son super type.
Compléter le schéma conceptuel
Remplir les détails du schéma conceptuel, avec les définitions de sous types.
Pour notre exemple, on aura:
EmployéeDeptSuperviserSit FamTel.DomAnnée MariageNb. enfantsAllocation (da)MoussaD1AhmedM3715821200321000NaceurD1MoussaC----BrahimD2MoussaM-2005--AhmedD2*M3783437200600(g1 : Moussa, g2 : Naceur, g3 : Brahim, g4 : Ahmed)
EmployéeDeptSuperviseurSit FamTel.DomAnnée MariageNb. enfantsAllocation (DA)(1)1111111(2)1110000(3)1110100(4)1111000AAABCDDTableau 3-2: Matrice de sous typage
A a les sous types : B, C ,D.
B a le sous type : D.
C a le sous type : D.
Le graphe suivant est le graphe de sous typage dont les champs sont attribuées aux nœuds, après l’élimination de toutes les relations de sous typage transitif.
EMBED Word.Picture.8
EMBED Word.Picture.8
Figure 3-21 : Le graphe de sous typage
Les fréquences d’occurrence :
La fréquence d’occurrence est le nombre de fois qu’une entité d’un type de donnée peut être enregistré jouant un rôle donné.
Exemple : Un employé peut être superviseur de deux employées au maximum.
Un département emploie exactement deux employés.
Alors, on peut exprimer cela dans notre schéma comme suit :
EMBED Word.Picture.8
Figure 3-22: Les fréquences d’occurrence
Notre schéma conceptuel devient :
EMBED Word.Picture.8
Figure 3-23: Le résultat de l'étape 6
CSDP ETAPE 7 : les combinaisons de références
Les contraintes lexicales :
EMBED Word.Picture.8
Figure 3-24: Exemple de la contrainte lexicale
La contrainte lexicale {C20} indique que les instances de nom sont des chaînes de caractères ne dépassant pas 20 caractères.
De façon analogue, on peut exprimer d’autres contraintes lexicales sur les autres attributs.
Les combinaisons de référence :
Elles sont souvent appelées figures d’identifications et sont au nombre de quatre. Nous présentons, ici, la plus répandue:
Exemple:
EMBED Word.Picture.8
Figure 3-25: Exemple de pont de dénomination
CSDP ETAPE 8 : Les contraintes supplémentaires
Les contraintes d’égalité, d’exclusion et de sous ensemble
Ces contraintes s’appliquent aux rôles et même aux types d’idées.
EMBED Word.Picture.8
Figure 3-26: Le résultat de l'étape 8
CSDP ETAPE 9 : Les vérifications finales
Cette étape consiste à vérifier que le schéma conceptuel est conforme aux exemples originaux, qu’il n’est pas redondant et qu’il est complet.
3.2.4 Avantages et inconvénients d’ORM
La méthode ORM présente les avantages suivants :
L’expression de domaine de l’univers du discours dans un langage naturel.
La possession des contraintes permettant de raffiner le maximum de la sémantique de données.
La possession d’une CSDP (Conceptual Schema Design Procedure) de haut niveau offre une démarche claire pour aboutir au schéma conceptuel final.
Néanmoins, ORM présente les lacunes suivantes:
La dynamique du système n’est pas prise en compte.
Son schéma conceptuel est condensé.
3.3 La Notation UML
3.2.1 Introduction
UML (Unified Modeling Language, "langage de modélisation objet unifié") est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, OOD et OOSE.
L'absence de consensus sur une méthode d'analyse objet avait longtemps freiné l'essor des technologies objet. Prenant conscience de cette difficulté, les grands acteurs du monde informatique ont favorisé l'unification et la normalisation des méthodes objet dominantes. UML est le fruit de cette démarche.
Comme OMT, UML n'est pas une méthode à proprement parler. Il s'agit en fait d'un langage de représentation de processus. UML ne propose pas de démarche permettant d'organiser l'enchaînement des activités d'une organisation.
UML est essentiellement un support de communication, qui facilite la représentation et la compréhension de solutions objet. Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de solutions. L'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions.
Son indépendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en fait un langage universel. D'autre part, la véritable force d'UML, est du au fait qu'il repose sur un métamodèle. Ainsi, il normalise la sémantique des concepts qu'il propose.
Fin 1997, UML est devenu une norme OMG1 (Object Management Group).
UML définit neuf sortes de diagrammes pour représenter les différents points de vue de modélisation [Booch et al.-2000]. Nous allons détailler la structure statique laquelle nous intéresse dans notre travail (Pour plus de détails voir [Muller-1997; Booch et al.-2000; Rumbaugh et al.-2004]).
3.2.2 Les diagrammes d’UML
3.2.2.1 Structure statique
Cette vue du modèle comporte trois types de diagrammes :
3.2.2.1.1. Diagrammes de classes :
Les diagrammes de classes expriment de manière générale la structure statique d'un système, en termes de classes et de relations entre ces classes. De même qu'une classe décrit un ensemble d'objets, une association décrit un ensemble de liens ; les objets sont instances des classes et les liens sont instances des relations. Un diagramme de classes n'exprime rien de particulier sur les liens d'un objet donné, mais décrit de manière abstraite les liens potentiels d'un objet vers d'autres objets.
L’exemple suivant montre les différents éléments qui se trouvent en diagramme de classes
. EMBED Word.Picture.8
Figure 3-27: Exemple de diagramme de classes
Les classes
Les classes sont représentées par des rectangles compartimentés. Le premier compartiment contient le nom de la classe, les deux autres contiennent respectivement les attributs et les opérations de la classe.
La surface d'un rectangle peut être déterminée à partir de la longueur et de la largeur. Alors, la surface est un attribut dérivé.
RectangleLongueur
Largeur
/SurfaceAfficher ()Figure 3-28: Exemple d'attribut dérivé
Les associations
Les associations représentent des relations structurelles entre classes d'objets. Une association symbolise une information dont la durée de vie n'est pas négligeable par rapport à la dynamique générale des objets instances des classes associées. La plupart des associations sont binaires, c'est-à-dire qu'elles connectent deux classes. Les associations se représentent en traçant une ligne entre les classes associées.
Les associations peuvent être représentées par des traits rectilignes ou obliques, selon les préférences de l'utilisateur.
Les associations n-aires peuvent généralement se représenter en promouvant l'association au rang de classe et en ajoutant une contrainte qui exprime que les multiples branches de l'association s'instancient toutes simultanément, en un même lien. Dans l'exemple suivant, la contrainte est exprimée au moyen d'un stéréotype qui précise que la classe Cours réalise une association ternaire.
EMBED Word.Picture.8
Figure 3-29: Représentation d'une association ternaire au moyen d'une classe avec stéréotype
Comme pour les associations binaires, les extrémités d'une association n-aire sont appelées rôle s et peuvent porter un nom. L’usage recommande de nommer les associations par une forme verbale, soit active comme travaille pour, soit passive comme est employé par [Muller-1997].
L'extrémité d'une association est appelée rôle. Chaque association binaire possède deux rôles, un à chaque extrémité. Le rôle décrit comment une classe voit une autre classe au travers d'une association. Il est fréquent de commencer par décorer une association par un verbe, puis de se servir plus tard de ce verbe pour construire un substantif verbal qui nomme le rôle qui convient.
Multiplicité des associations
Chaque rôle d'une association porte une indication de multiplicité qui montre combien d'objets de la classe considérée peuvent être liés à un objet de l'autre classe. La multiplicité est une information portée par le rôle, sous la forme d'une expression entière bornée.
1 Un et un seul 0..1 Zéro ou un M .. N De M à N (entiers naturels) * De zéro à plusieurs 0.. * De zéro à plusieurs 1.. * D'un à plusieursFigure 3-30: Valeurs de multiplicité conventionnelles
Les valeurs de multiplicité expriment des contraintes liées au domaine de l’application, valables durant toute l'existence des objets.
La détermination de valeurs de multiplicité optimales est très importante pour trouver le bon équilibre, d'une part, entre souplesse et possibilité d'extension, et d'autre part, entre complexité et efficacité. En analyse, seule la valeur de la multiplicité est réellement importante. En revanche, en conception, il faut choisir des structures de données (pile, file, ensemble...) pour réaliser les collections qui correspondent aux multiplicités de type 1..* ou 0..*. La surestimation des valeurs de multiplicité induit un surcoût en taille de stockage et en vitesse de recherche. De même, une multiplicité qui commence à zéro implique que les diverses opérations doivent contenir du code pour tester la présence ou l'absence de liens dans les objets.
Contraintes sur les associations
La multiplicité est une contrainte sur le nombre de liens qui peuvent exister entre deux objets. Les contraintes se représentent dans les diagrammes par des expressions placées entre accolades.
La contrainte {ordonnée} peut être placée sur le rôle pour spécifier qu'une relation d'ordre décrit les objets placés dans la collection
La contrainte {Sous-ensemble} indique qu'une collection est incluse dans une autre collection.
La contrainte {ou-exclusif} précise que, pour un objet donné, une seule association parmi un groupe d'associations est valide. Cette contrainte évite l'introduction de sous-classes artificielles pour matérialiser l'exclusivité.
Les associations peuvent également relier une classe à elle-même, comme dans le cas des structures récursives. Ce type d'association est appelé association réflexive.
Les classes-associations
Une association peut être représentée par une classe pour ajouter, par exemple, des attributs et des opérations dans l'association. Une classe de ce type, appelée parfois classe associative ou classe-association, est une classe comme les autres et peut à ce titre participer à d'autres relations dans le modèle. La notation utilise une ligne pointillée pour attacher une classe à une association.
Une association qui contient des attributs sans participer à des relations avec d'autres classes est appelée association attribuée. Dans ce cas, la classe rattachée à l'association ne porte pas de nom spécifique.
Restriction des associations
La restriction (UML parle de qualification) d'une association consiste à sélectionner un sous-ensemble d'objets parmi l'ensemble des objets qui participent à une association. La restriction est réalisée au moyen d'un tuple d'attributs particuliers (appelé clé) et utilisé conjointement avec un objet de la classe de départ. La clé est représentée sur le rôle de la classe de départ, dans un compartiment rectangulaire. La clé appartient pleinement à l'association et non aux classes associées.
EMBED Word.Picture.8
Figure 3-31: Restriction d'une association, au moyen d'un attribut particulier appelé clé
Chaque instance de la classe A accompagnée de la valeur de la clé, identifie un sous-ensemble des instances de B qui participent à l'association. La restriction réduit la multiplicité de l'association. La paire (instance de A, valeur de clé) identifie un sous-ensemble des instances de B. Très souvent, la multiplicité est réduite à la valeur 1.
Les agrégations
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é. Quelle que soit l'arité l'agrégation ne concerne qu'un seul rôle d'une association. L'agrégation se représente en ajoutant un petit losange du côté de l'agrégat.
EMBED Word.Picture.8
Figure 3-32: Représentation des agrégations
Les critères suivants impliquent une agrégation :
· Une classe fait partie d'une autre classe ;
· Les valeurs d'attributs d'une classe se propagent dans les valeurs d'attributs d'une autre classe
· Une action sur une classe implique une action sur une autre classe ;
· Les objets d'une classe sont subordonnés aux objets d'une autre classe.
La contenance physique est un cas particulier de l'agrégation, appelé composition.
La composition
Les attributs constituent un cas particulier d'agrégation réalisée par valeur : ils sont physiquement contenus par l'agrégat. Cette forme d'agrégation est appelée composition, et se représente dans les diagrammes par un losange de couleur noire.
La composition implique une contrainte sur la valeur de la multiplicité du côté de l'agrégat : elle ne peut prendre que les valeurs 0 ou 1. La valeur 0 du côté du composant correspond à un attribut non renseigné.
La composition et les attributs sont sémantiquement équivalents ; leurs représentations graphiques sont interchangeables. La notation par composition s'emploie dans un diagramme de classes lorsqu'un attribut participe à d'autres relations dans le modèle.
Les classes réalisées par composition sont également appelées classes composites. Ces classes fournissent une abstraction de leurs composants.
La généralisation
UML emploie le terme généralisation pour désigner la relation de classification entre un élément plus général et un élément plus spécifique. En fait, le terme généralisation désigne un point de vue porté sur un arbre de classification.
La relation de généralisation se représente au moyen d'une flèche qui pointe de la classe plus spécialisée vers la classe plus générale. La tête de la flèche est réalisée par un petit triangle vide.
Différentes contraintes peuvent être appliquées aux relations de généralisation, pour distinguer par exemple les formes de généralisation exclusives des formes inclusives. Les contraintes sur les relations de généralisation se représentent au moyen d'expressions entre parenthèses, directement attachées aux généralisations agrégées ou associées à une ligne pointillée qui relie les relations de généralisation concernées.
Par défaut, la généralisation symbolise une décomposition exclusive, c'est-à-dire qu'un objet est au plus instance d'une des sous-classes. La contrainte {Disjoint} ou {Exclusif} indique qu'une classe descendante d'une classe A peut être descendante d'une seule sous-classe de A.
La contrainte {Chevauchement} ou {Inclusif} indique qu'une classe descendante d'une classe A appartient au produit cartésien des sous-classes de la classe A. Un objet concret est alors construit à partir d'une classe.
3.2.2.1.2. Diagrammes d’objets :
Les diagrammes d'objets ou diagrammes d'instances, montrent des objets et des liens. Comme les diagrammes de classes, les diagrammes d'objets représentent la structure statique. La notation retenue pour les diagrammes d'objets est dérivée de celle des diagrammes de classes ; les éléments qui sont des instances sont soulignés.
Les diagrammes d'objets s'utilisent principalement pour montrer un contexte, par exemple avant ou après une interaction, mais également pour faciliter la compréhension des structures de données complexes, comme les structures récursives [Muller-1997]. Ils s’utilisent pour montrer un contexte particulier du système après une exécution.
Le stéréotype de la classe peut être repris dans le compartiment de l'objet, soit sous la forme textuelle (entre guillemets au-dessus du nom de l'objet), soit sous la forme graphique (dans le coin haut droit), soit encore au moyen d'une représentation graphique particulière qui se substitue au symbole de l'objet. Il n'existe pas de stéréotype d'objet ; le stéréotype qui figure dans un objet est toujours le stéréotype de la classe de l'objet.
Représentation des liens
Les objets sont reliés par des liens qui sont instances des relations entre les classes des objets considérés. La représentation concrète d'une structure par des objets est souvent plus parlante que celle abstraite par des classes, surtout dans le cas de structures récursives.
Les objets composites
Les objets composés de sous-objets peuvent être représentés au moyen d'un objet composite, afin de réduire la complexité des diagrammes. Les objets composites se présentent comme des objets classiques, si ce n'est que les attributs sont remplacés par des objets, soit sous une forme textuelle soulignée, soit sous une forme graphique. Le diagramme suivant reprend la forme graphique des objets composites.
3.2.2.1.3 Diagrammes de cas d’utilisation : Les cas d'utilisation
Les cas d'utilisation (use cases) ont été formalisés par Ivar Jacobson. Les cas d'utilisation décrivent sous la forme d'actions et de réactions, le comportement d'un système du point de vue d'un utilisateur. Ils permettent de définir les limites du système et les relations entre le système et l'environnement.
Un cas d'utilisation est une manière spécifique d'utiliser un système. C'est l'image d'une fonctionnalité du système, déclenchée en réponse à la stimulation d'un acteur externe.
Intérêt des cas d'utilisation
La détermination et la compréhension des besoins sont souvent difficiles car les intervenants sont noyés sous de grandes quantités d'information. Les besoins sont souvent exprimés de manière non structurée, sans forte cohérence, de sorte que les cahiers des charges sont de longues litanies de paragraphes qui contiennent des expressions du genre :
· le système devra faire...
· le système devrait faire...
· le système fera éventuellement...
· il faut absolument que...
· il serait intéressant de...
Le formalisme des cas d'utilisation basé sur le langage naturel est accessible sans formation particulière des utilisateurs, qui peuvent ainsi exprimer leurs attentes et leurs besoins en communiquant facilement avec les experts du domaine et les informaticiens.
Les cas d'utilisation focalisent l'effort de développement sur les vrais besoins.
Ils permettent aux utilisateurs de structurer et d'articuler leurs désirs ; ils les obligent à définir la manière dont ils voudraient interagir avec le système, à préciser quelles informations ils entendent échanger et à décrire ce qui doit être fait pour obtenir le résultat escompté. Les cas d'utilisation concrétisent le futur système dans une formalisation proche de l'utilisateur ; ils favorisent la définition d'un cahier des charges qui reflète réellement les besoins, même en l'absence d'un système à critiquer.
Les cas d'utilisation se déterminent en observant et en précisant, acteur par acteur, les séquences d'interaction les scénarios du point de vue de l'utilisateur. Ils se décrivent en termes d'informations échangées et d'étapes dans la manière d'utiliser le système. Un cas d'utilisation regroupe une famille de scénarios d'utilisation selon un critère fonctionnel. Les cas d'utilisation sont des abstractions du dialogue entre les acteurs et le système : ils décrivent des interactions potentielles, sans entrer dans les détails de chaque scénario.
Quelles sont les tâches de l'acteur ?
Quelles informations l'acteur doit-il créer, sauvegarder, modifier, détruire ou simplement lire ?
L’acteur devra-t-il informer le système des changements externes ?
Le système devra-t-il informer l'acteur des conditions internes ?
Un cas d'utilisation décrit ce que l'utilisateur veut fondamentalement faire avec le système. Le nom des cas d'utilisation peut être un indicateur, les associations (objet, opérations) ou (fonction, données) sont fortement suspectes.
La réalisation d'un cas d'utilisation par une collaboration est un instant crucial de la modélisation; c'est le moment du virage vers l'objet. Une décomposition qui suit directement la forme des cas d'utilisation conduit à une approche structurée classique, avec tous les défauts des structures calquées sur les fonctions.
Une approche objet réalise un cas d'utilisation au moyen d'une collaboration entre objets. Les scénarios, instances du cas d'utilisation, sont représentés par des diagrammes d'interaction (diagrammes de collaboration et diagrammes de séquence).
3.2.2.2 Comportement dynamique
Cette vue du modèle comporte quatre types de diagrammes :
3.2.2.2.1 Diagrammes de séquences :
Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue temporel. Ils représentent les échanges de message entre objets au cours du temps. Ils s’utilisent de 2 manières : pour la documentation des cas d’utilisations (scénarios) et pour la représentation précise des interactions entre objets (usage plus informatique).
3.2.2.2.2 Diagrammes de collaborations :
Par rapport aux diagrammes de séquences, ici le contexte des objets est représenté de manière explicite. Ces diagrammes montrent des interactions entre objets dans un contexte (état des objets) particulier.
3.2.2.2.3 Diagrammes d’états-transitions :
Ils constituent une modélisation du comportement de l’objet et relient des événements à des états en spécifiant la séquence d’états provoquée par une séquence d’événements. Ils servent donc à représenter des automates à états finis. En UML ces diagrammes sont associés à une classe
3.2.2.2.4. Diagrammes d’activités :
Une activité représente l’exécution d’un mécanisme, un déroulement d’étapes séquentielles. Ces diagrammes permettent de représenter graphiquement le déroulement d’une méthode ou d’un cas d’utilisation. Ils sont une variante des diagrammes d’états-transitions organisée par rapport aux actions.
3.2.2.3 Constructions d’implémentation
Cette vue du modèle comporte deux types de diagrammes :
3.2.2.3.1. Diagrammes de composants :
Ils permettent de décrire l’architecture physique et statique d’une application en termes de modules de différentes natures (fichiers sources, librairie, exécutables…). Ils montrent la mise en œuvre physique du système avec son environnement de développement.
3.2.2.3.2. Diagrammes de déploiement :
Ils montrent quant à eux la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels. Ils mettent ainsi en évidence l’arrangement physique des ressources d’exécution (les machines et leurs interconnexions)
3.2.3 Intérêts et lacunes d’UML
UML est un langage formel et normalisé. Il présente une notation ouverte et riche qui permet un gain de précision et de stabilité. Il est aussi un support de communication performant qui cadre l’analyse et facilite la compréhension de représentations abstraites. C’est donc un bon moyen de communication dans une équipe qui donne à travers sa représentation d’un système, une bonne compréhension de son fonctionnement.
Par contre, les inconvénients majeurs d’UML [Halpin-2001c] sont :
Le manque d’outils et de syntaxe permettant de raffiner le maximum de la sémantique de données.¶
Son cas d’utilisation est surtout orienté processus.
UML n’est que faiblement intégré dans les outils de conception de base de données.
Sa notation basée sur les attributs empêche la verbalisation et la population.
3.4 Conclusion
ORM est une méthode de modélisation conceptuelle ¶qui regarde le monde comme ensemble d'objets (des entités ou ¶valeurs) jouent des rôles (parties dans les relations). ¶¶¶La différence structurale principale¶ entre ORM et UML est qu'ORM exclut les attributs ¶comme une base de construction, les traitant comme des concepts dérivés.¶
¶
La notation d'ORM emploie seulement un ensemble de symboles, ¶aisément maîtrisé par les concepteurs en UML.¶ ¶
¶Le langage d'ORM a été conçu de bas vers le haut ¶pour répondre aux critères suivants: ¶expressivité, ¶clarté, ¶¶stabilité sémantique (réduire au minimum l'impact de ¶changement), ¶pertinence sémantique (vues de portée juste à la ¶tâche actuelle), ¶mécanismes de validation, ¶¶mécanismes d'abstraction ¶et base formelle.¶¶
¶
La caractéristique la plus spécifique à ORM est son action d'éviter les ¶attributs dans le modèle de base.¶ Cette omission était à l'origine ¶faite pour éviter des distinctions brouillées et instables environ ¶une caractéristique si elle devrait être modélisée comme attribut ou ¶association [Halpin-2002].¶ Son inconvénient est que les diagrammes d'attributs libres ¶prennent souvent plus d'espace. ¶Les avantages principaux ¶sont que tous les faits et les règles peuvent être facilement verbalisés en ¶phrases, toutes les structures de données peuvent être facilement peuplées avec ¶des exemples multiples. Le méta-modele est simplifié, et le ¶modèle et les requêtes sont plus stables puisqu'elles sont immunisées contre les ¶changements qui remodèlent des attributs en associations. ¶Enfin ¶la compacité des modèles basés attributs peut encore être ¶réalisée en les dérivant comme des vues (c'est automatisable).
Enfin, UML est une notation générique, extensible, plus adéquate à la génération de code orienté objet. Mais elle souffre de manque d’outils et de syntaxe permettant de raffiner le maximum de la sémantique de données¶
Notre proposition s’inscrit dans le cadre de génie logiciel. Elle sert à aider le concepteur utilisant UML à capturer mieux la sémantique des données à partir de l’U°D. C'est ce que ¶nous verrons dans le chapitre suivant.
CHAPITRE IV
L’approche UDDP
Chapitre 4: L’approche UDDP (Uml Diagrams Design Procedure)
4.1 Introduction
L’approche proposée est inspirée de la procédure CSDP d’ORM et basée sur un ensemble de règles proposées dans les travaux de Halpin [Halpin-1998a; Halpin-1998b; Halpin-1998c; Halpin-1998d; Halpin et al.-1999] pour la transformation les schémas d’ORM et de la notation UML.
Les ontologies présentent actuellement une source sémantique consistante pour les applications Web et les systèmes d’information. Dans notre proposition, on utilise l’ontologie de domaine d’application pour enrichir les diagrammes obtenus.
¶En effet, notre proposition appelée UDDP (Uml Diagrams Design Procedure) est une démarche hybride (ascendante et descendante). Elle s’inspire de la CDSP d’ORM et bénéficie de l’ingénierie ontologique pour générer des diagrammes UML sémantiquement riches à partir de l’univers de discours.
Nous verrons dans ce chapitre les règles de transformation entre les schémas d’ORM et de la notation UML et le processus UDDP en détail.
¶
4.2 La transformation de schéma conceptuel ORM à UML
Les règles de transformation citées ci-dessous sont inspirées de travaux de Halpin [Halpin-1998a; Halpin-1998b; Halpin-1998c; Halpin-1998d; Halpin et al.-1999].
4.2.1 La transformation des objets ORM
Un type d’entité d’ORM est dit indépendant s’il peut exister seul. Par exemple : étudiant est un type d’entité indépendant, mais nom est un type d’entité dépendant.
Chaque type d’entité d’ORM se transforme en classe UML. Une contrainte textuelle doit être ajoutée aux classes, associations ou attributs liés à cette classe dans le cas où ces entités ne seraient pas indépendantes.
Ceci signifie que dans la transformation ORM-UML, nous avons besoin d'une connaissance globale du schéma conceptuel d'ORM (le statut d'indépendance d'un type d'objet) afin de transformer les types d'objet d'ORM en classes d'objets d'UML. Cette connaissance peut être matérialisée par l’intervention de l’expert de domaine et l’utilisation de l’ontologie de domaine.
Pour le distinguer le statut d’indépendance entre les types d’entités d’ORM, on ajoute un point d’exclamation à côté du type d’entité indépendant [Bollen-2002].
EMBED Word.Picture.8
Figure 4-1: Transformation de types d’entités dépendants et indépendants
Si un rôle joué par un type d’entité d’ORM est un rôle obligatoire, ceci correspond en UML à la multiplicité 1..x ou à une contrainte textuelle attachée à l’association ou à l’attribut.
EMBED Word.Picture.8
Figure 4-2: Rôle obligatoire en ORM et sa transformation en UML
4.2.2 La transformation de types d’idées unaires
[Halpin-1999] donne deux façons de transformer le type d’idée unaire. Soit qu’il le transforme en un attribut booléen, soit en une sous-classe.
EMBED Word.Picture.8
Figure 4-3: Transformation de type d’idée unaire
Nous notons la multiplicité d'attribut par défaut [1..1] dans les cas où aucune multiplicité ne serait indiquée [Rumbaugh et al. -1999].
4.2.3 La transformation de types d’idées binaires
4.2.3.1 Les types d’idées binaires cas M: N
Le schéma suivant présente le cas général de transformation de type d’idée binaire d’ORM en UML.
EMBED Word.Picture.8
Figure.4-4 : Transformation de type d’idée binaire
Les transformations particulières de type d’idées binaires d’ORM se font relativement au statut d’indépendance des entités A,B et la contrainte d’unicité sur le type d’idée.
Dans le cas ou les deux types d’entité seraient indépendants, alors ce type d’idée sera modélisé comme une association ou une classe d’associations. Nous verrons, dans les sections suivantes, presque tous les cas possibles.
4.2.3.2 Cas 1:M
EMBED Word.Picture.8
¶EMBED Word.Picture.8
Figure 4-5: Transformation de type d’idée binaire 1:M
4.2.3.3 Cas 1:1
EMBED Word.Picture.8
Figure 4-6: Transformation de type d’idée 1:1
Nous notons que la contrainte d'unicité qui est définie sur le rôle droit de l'exemple précèdent est transformé en une contrainte U1 d'unicité d'attributs [Halpin-2001a].
4.2.3.4 La transformation de type d’idée binaire en association
EMBED Word.Picture.8
Figure 4-7: Transformation de types d’idées binaires d'ORM en associations d’UML
4.2.4 La transformation de types d’idées naires
EMBED Word.Picture.8
Figure 4-8: Transformation de type d’idée ternaire en UML
¶
4.2.5 La transformation de types d’objets emboîtés
ORM utilise le concept des types d'objets emboîtés pour représenter les schémas de référence composés.
Un type d’objet emboîté en ORM se transforme généralement en classe d’association d’UML.
EMBED Word.Picture.8
EMBED Word.Picture.8
Figure 4-9: Transformation de l'objet emboîté d'ORM en une classe d'association d'UML
4.2.6 La transformation de la co-référence
La troisième façon pour modéliser les schémas de référence dans ORM s'appelle co-référence [Halpin-2001a]. La co-référence est caractérisée par une contrainte externe d'unicité définie sur les rôles qui participent dans le schéma de référence. Par exemple, dans l’exemple suivant, une entité D est référencée par une combinaison unique (A,B). La co-référence se transforme en qualificateur d'association en UML ou à un attribut de classe.
EMBED Word.Picture.8
EMBED Word.Picture.8
Figure 4-10: Transformation de Co-référence d'ORM
4.2.7 La transformation de sous typage
Le concept de sous typage d’ORM correspond au concept de sous classe d’UML. Halpin [Halpin-2001a] propose d’ajouter en contraintes textuelles ou en OCL des définitions formelles de sous classes au modèle UML correspondant.
EMBED Word.Picture.8
Figure 4-11: Transformation de sous type d'ORM à UML
4.2.8 Tableau de correspondances entre ORM et UML
Instances de données/ structuresContraintesORMUMLORMUMLEntitéObjetUnicité InterneMultiplicité ..1EtiquetteValeur de donnéeUnicité externeUtilisation
de classe associationObjetObjet ou valeur de donnéeRôle impératif simpleMultiplicité 1..Type d’entitéClasseRôle impératif disjoint-Type d’étiquetteType de donnéeFréquence interne externeMultiplicitéType d’objetClasse ou type de donnéeValeurénumérationType de relation d’utilisation AttributSous-ensemble, égalitéSous-ensembleType de relation unaireAttribut ou sous typeExclusionOu exclusifType de relation 2+aireAssociation Sous type Sous classe Relation 2+aireLienContrainte de jointure-Relation objectivéeClasse- associationCardinalité d’objetMultiplicité de classeCo-Référence Qualification d’associationUtilisation de l’unicité et de l’impératifAgrégation/compositionContraintes textuellesContraintes textuelles ou OCLTableau 4-1: Les correspondances entre ORM et UML
4.2.9 Exemple de transformation
Le modèle ORM :
EMBED Word.Picture.8
Figure 4-12: Exemple en ORM
Le diagramme UML sera :
EMBED Word.Picture.8
Figure 4-13: Transformation de l’exemple en diagramme de classes d’UML
4.3 La procédure UDDP
Notre proposition UDDP (Uml Diagram Design Procedure) est une adaptation de la procédure CSDP d’ORM pour la génération des diagrammes UML à partir de l’univers de discours. Elle était proposée pour la première fois en première version dans [Belalem et al.-2005]. Quant à sa version actuelle, elle est une procédure de neuf étapes utilisant l’ontologie de domaine comme source sémantique complémentaire.
4.3.1 Verbalisation des exemples en idées élémentaires
La première étape est de commencer avec des exemples familiers d'informations pertinentes de l`univers de discours et de les exprimer en idées élémentaires (des phrases indécomposables et sans perte d'informations).
Les Uses cases de la notation UML ont pour objectifs de modéliser un processus et de capter les différentes spécifications. D'une façon analogue à la CSDP, on commence par les exemples familiers de l'univers de discours qu’on appelle Data uses cases [halpin-2001c]. 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).
Exemple : extrait de listing d'un système d'information
EmployéDeptSuperviseurSituation familiale N° TelAnnée de MariageNbre
EnfantsAllocat(da)MoussaD1AhmedM3715821200321000NaceurD1MoussaC----BrahimD2MoussaM-2005--AhmedD2*M3783437200600N.B : « * » = ‘non-existant’ « - » = ‘non enregistré’
Tableau 4-2: Exemple de l’univers de discours
a) Résultats :
Employé avec le nom `Moussa' travaille dans le département de code `D1'.
Employé avec le nom `Moussa' a une situation familiale de code `M'.
Employé avec le nom `Ahmed' est un superviseur de l'employé avec le nom `Moussa'.
L'employé avec le nom 'Brahim' est marié en l’an `2005'.
Le superviseur avec le nom `Moussa' a le numéro de téléphone `3715821'.
Le superviseur avec le nom `Moussa' a un nombre d'enfants égal à `2'.
Le superviseur avec le nom `Moussa' a une allocation d'enfants égale à `1000 DA'.
b) Vérification de la qualité des idées élémentaires
La vérification consiste à se poser les questions suivantes :
- Les relations sont-elles bien identifiées ?
- Les relations peuvent-elles être divisées en idées plus petites sans perte d'information ?
4.3.2 Dessin d’un premier brouillon des diagrammes de classes et d'objets
Cette étape consiste à dessiner un diagramme de classes à partir des relations élémentaires exprimées. On présente un diagramme d'occurrences à partir des relations élémentaires (idées élémentaires) au sens de Niam [Halpin-2002, Halpin-2002b, Halpin-1993], on aura :
EMBED Word.Picture.8
Figure 4-14: Diagramme d’occurrences
Pour notre univers de discours, chaque employé a un et un seul nom, et chaque nom de personne se réfère exactement à un employé. Ce type de référence est représenté dans le système de référence 1:1. Quand ce cas existe, on doit mettre le mode de référence entre parenthèses à coté du nom du type d'entité. Il en est de même pour les autres idées.
EMBED Word.Picture.8
Figure 4-15: Diagramme de schéma conceptuel correspondant en ORM
Pour représenter les diagrammes de classes et d'objets, on s'est basé sur un ensemble de règles proposées dans [Halpin-2000a, Halpin-2000b]:
Les classes utilisées pour illustrer les types d'entités (No Lexical Object Type);
Les objets pour illustrer les entités;
Les associations pour illustrer les types d'idées;
Les liens pour illustrer les idées;
Les rôles en UML pour illustrer les rôles de point de vue Niam;
Les attributs pour illustrer les types d'étiquettes (Lexical Object Type);
Nous commençons par présenter un diagramme d'objets pour les idées exprimées.
EMBED Word.Picture.8
Figure 4-16: Diagramme d’objets d’UML
Le diagramme de classes déduit à partir du diagramme d’objets
EMBED Word.Picture.8
Figure 4-17: Diagramme de classes d’UML
4.3.3 Arrangement des diagrammes et identification des attributs dérivés
Ayant dessiné notre premier brouillon du diagramme du schéma conceptuel et accompli une vérification de population, on procède dans cette étape à éliminer les associations en surplus ou les rôles communs et identifier n'importe quel attribut dérivé. Les questions pertinentes que nous nous posons ici, peuvent être résumées ainsi :
Un objet peut-il être une instance de deux classes? Si oui combiner les classes en une seule.
Des objets de classes différentes peuvent-elle être comparées d'une façon significative? Si oui combinez-en les classes une seule.
Les instances de deux classes différentes peuvent-elles jouer le même rôle? Si oui combinez les classes en une seule et si nécessaire ajouter une nouvelle classe aux deux pour préserver la distinction originale.
Un attribut est-il 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.
En vérifiant notre brouillon de schéma conceptuel, on trouve que la valeur d’Allocation enfants peut être dérivée de la valeur du 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 :
EMBED Word.Picture.8
Figure 4-18: La classe superviseur marié
4.3.4 Adjonction de contraintes de multiplicité et vérification de l’ordre
a) Les multiplicités sur les associations.
Dans cette étape, on ajoute les contraintes de multiplicité dans les diagrammes de classes obtenues, à partir des règles de passage de [Halpin-2000b, Halpin-2001a] et de la population de départ.
EMBED Word.Picture.8
Figure 4-19: Règles de transformation des multiplicités d’ORM à UML
b) 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 cela soit par la contrainte de multiplicite 1..*, soit par une contrainte textuelle ajoutée comme note.
c) Vérification de l’ordre
Cette étape vérifie que les associations 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 ORM) pour qu’elle ne soit ni trop longue, ni trop courte par rapport à ce qu’elle doit être. Les relations binaires sont préférées en ORM et même en UML. Les auteurs d’UML disent: « En général, c’est mieux d'éviter les associations n-aires, parce que les associations binaires sont plus simples à implémenter et permettent la navigation » [Rumbaugh et al.-2004].
4.3.5 Adjonction de contraintes de type et de fréquence
Les contraintes de type
Elles spécifient une restriction sur les valeurs possibles des instances d’un type d’attribut donné.
Les fréquences d’occurrences
La fréquence d’occurrence représente soit :
le nombre de fois qu’une entité d’un type donné peut être enregistrée pour jouer un rôle donné.
le nombre de fois que les étiquettes peuvent apparaître dans une colonne d’une relation donnée.
En UML, cette fréquence n’est pas toujours exprimée par les contraintes de multiplicité. Dans le cas contraire, on utilise des contraintes textuelles.
EMBED Word.Picture.8
Figure 4-20: Diagramme de classes d’UML après l’étape 6
4.3.6 Adjonction de contraintes d’agrégation et de généralisation.
a) 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égation entre les classes.
La composition est un cas particulier de l’agrégation. Elle implique une contrainte sur la valeur de la multiplicité du côté 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 [Halpin-2001c, Halpin-2004c]. A partir de cette définition, on propose la règle suivante :
Si un attribut participe dans une relation dans le modèle et que sa participation est validée par une population du l’U°D, alors il devient une classe composite.
b) La généralisation
Pour identifier les relations de généralisation entre les différentes classes, on utilise:
Notre intuition et l’assistance de l’expert de l’U°D.
L’ontologie de domaine.
Une technique connue par l’analyse de la matrice de sous typage [Halpin-1993].
L’utilisation de l’ontologie de domaine sera expliquée dans l’étape suivante. Quant à la technique de l’analyse de la matrice de sous typage, on la résume ainsi :
Supposons qu’on ait une entité A et qu’on veuille 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.
Procédure de la matrice de sous typage :
1. Construire la matrice Partition/Détails pour A
Lister les détails enregistrés pour tous les membres de A comme des entêtes de colonnes.
Partitionner A en groupes selon leurs modèles enregistrés et lister ces groupes comme entêtes de lignes.
Entrer le modèle enregistré pour chaque groupe (1=détails enregistre, 0=détails non enregistre).
2. Esquisser le graphe de sous typage et les détails attachés
Etiqueter les différents modèles de colonnes comme nœuds A,B,C,D...
Déterminer les relations de sous typages entre nœud comme suit : le nœud x est un sous ensemble de nœud y si et seulement si pour chaque ligne on a x=0, y=0.
Dessiner le graphe de sous typage et enlever les arcs transitifs de sous typage.
Attacher à chaque nœud le (s) rôles(s) indiqué(s) par son (leurs) entête(s) de colonne (informations de la ligne du titre)
3. Fournir des définitions et des noms significatifs pour les sous types, en définissant chaque sous type en termes d’un ou plusieurs rôles attachés à son super type.
4.Compléter le schéma conceptuel, en remplissant les détails du schéma, avec les définitions de sous types des étapes 2 et 3.
Pour l’exemple présenté par le tableau 4-2, la matrice Partitions/Détails est donnée par:
EmployéDeptSuperviseurSituation familiale N° TelAnnée de MariageNbre
EnfantsAllocat(da)(1)1111111(2)1110000(3)1110100(4)1111000GroupesAAABCDDTableau 4.3: Matrice Partitions/Détails
Le groupe A a les sous types B,C et D.
Le groupe B a le sous type D.
Le groupe C a le sous type D
Donc, de façon analogue à la CSDP, le graphe de sous typage du tableau 4.2 est représenté par la figure suivante
EMBED Word.Picture.8
Figure 4-21: Graphe de sous typage
4.3.7 Alignement avec l’ontologie de domaine.
Pour enrichir la sémantique de notre modèle, on utilise 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 [Malki-2002],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.
Dans cet exemple, nous avons choisi une partie d’une ontologie qui décrit le domaine d’une personne et ses intérêts [Heflin-2001].
Les classes et les propriétés de cette ontologie sont :
Personne
Employé
-Nom
-Date de naissance
-Sexe
-Age
-Photo
-Adresse
-Adresse mail
-Tel Domicile
-Femme
OrganisationReposGroupe socialFonction
Les relations sont:
Membre de (Personne, Groupe social)
Travaille a (Employé, Organisation)Assurer (Employé, Fonction)
En alignant le schéma obtenu avec cette ontologie de domaine, le diagramme s’enrichit avec une nouvelle classe groupe social, une nouvelle association membre de(employé, groupe social) et la classe employé s’enrichit avec d’autres attributs Date de naissance, tel domicile, âge...
Nous constatons que l’association membre de entre les classes employé et groupe social est déduite de la relation ‘est un’ ou ’is a’ (équivalente à la relation d’héritage dans le modèle objet) entre employé et personne dans l’ontologie.
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.
4.3.8 Adjonction de contraintes lexicales, de qualifications et d’autres contraintes
Dans cette étape, on spécifie les contraintes lexicales sur les attributs sur la base de la population de domaine, en tenant compte de l’avis de l’expert de l’U°D.
Dans notre exemple, l’attribut nom de la classe Employé 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.
EMBED Word.Picture.8
Figure 4-22: Diagramme de classes d’UML enrichi par les contraintes textuelles
4.3.9 Les vérifications finales
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.
4.4 Conclusion
La procédure CSDP permet l’élaboration d’un schéma conceptuel à partir d’un domaine en vérifiant sa conformité aux exemples originaux et sa validité avec l’expert de l’U°D tout au long de cette procédure. Notre contribution était de faire bénéficier UML de cet avantage, par une procédure de neuf étapes, en partant d’un premier brouillon du diagramme conceptuel jusqu’à l’aboutissement des schémas conceptuels sémantiquement riches. L’intégration de l’ontologie de domaine dans notre approche permet d’augmenter la consistance des résultats et de diminuer beaucoup plus l’intervention du concepteur et de l’expert de domaine.
Dans le chapitre suivant, nous présenterons une expérimentation de notre approche.
CHAPITRE V
Implémentation
Chapitre 5 : Implementation
5.1 Introduction
Pour valider notre proposition d’élaboration de diagrammes UML à partir de l’univers de discours, nous implantons la procédure UDDP.
Nous avons implanté notre outil sur une plateforme open source de modélisation en UML. Cette plateforme qui porte le nom StarUML[StarUml-2006a], fournit presque tous les éléments de la notation UML qui permettent de réaliser une conception quasi complète en ce langage, d’effectuer l'ingénierie directe et la retro-ingénierie à partir des codes sources en plusieurs langages de programmation tels que : java, C++, CSharp, etc.
Elle est extensible, elle fournit des API pour y insérer des modules externes en utilisant les techniques d'objets COM et les scripts.
Nous avons choisi cette plateforme parce qu’elle répond aux objectifs de notre proposition qui est de fournir un point de départ solide pour le concepteur en UML. Elle lui permet de commencer avec un schéma conceptuel riche en sémantique de données, utilisant notre outil, puis d’accomplir sa conception avec les autres outils et fonctionnalités de cette plateforme.
En sus, StarUML est un travail collaboratif multilingue de plusieurs équipes de développeurs, et est en mise à jour continue. Ce qui rend notre contribution toujours utile et pratique pour plusieurs concepteurs en UML utilisant StarUML.
5.2 Présentation de la plateforme StarUML
5.2.1 Architecture de Plateforme
StarUML est une plateforme extensible de modélisation du logiciel. Elle permet l’ajout de nouvelles fonctions et modules. Le diagramme ci-dessous illustre l'architecture de StarUML. Le bleu indique la plateforme et le vert indique les parties extensibles. Ces dernières peuvent être développées par l'utilisateur ou un tiers et puis être ajoutées à la plateforme de l'intégration.
Figure 5-1: Présentation de l’architecture de StarUML [StarUML2006b].
Approach: L'approche définit le modèle du projet et l'organisation de base des diagrammes.
UML Profile & Notation Extension : Le profil d'UML permet l’extension de l'expression du modèle de logiciel par les mécanismes d’extension d'UML.
Model Framework: Model Framework rend les modèles de logiciel réutilisables pour en définir d'autres modèles.
Add-In COM Object: COM addition permet l'ajout de nouvelles fonctionnalités à StarUML en utilisant les objets COM.
Menu Extension: Le menu d'application de StarUML (menu principal et menu instantané) peut être modifié par l'utilisateur.
Option Extension: Les options de StarUML peuvent être modifiées par l'utilisateur.
Event Subscription: Divers événements se produisant dans StarUML peuvent être souscrits.
External API: L'api externe de StarUML permet l'accès à diverses fonctionnalités et informations de la plateforme.
Les extensions en StarUML peuvent être intégrées dans la plateforme sous formes de modules.
5.2.2. Structure d'un module en StarUML
Le module en StarUML est un paquet logiciel qui permet l'ajout de nouvelles fonctionnalités et caractéristiques en étendant StarUML. Il se compose de divers mécanismes d'extension de StarUML.
Comme illustré dans le diagramme ci-dessous, un paquet d’extension peut se composer de diverses approches, de divers modèles frameworks, de divers profils d'UML, de divers scripts, d'extensions de menu, d'extension d'option, d'aide et d'objets COM.
Figure 5-2: Structure d’un module en StarUML.
5.2.3. Applications de module StarUML
Les modules en StarUML peuvent contenir divers éléments; ils peuvent être développés pour différents buts. Des modules peuvent être utilisés pour supporter des processus spécifiques, langues ou plateformes, pour s'intégrer avec d'autres outils ou étendre des fonctions.
Un module en StarUML peut être :
Un support pour des processus spécifiques :Composants d'UML, RUP, Catalyse, XP…
Un support pour des langages de programmation spécifiques :C/C++, Python, C #, Visual basic, Java, Perl, Pascal objet…
Un support d’intégration avec des outils spécifiques: Visual SourceSafe , CVS, Msword, Eclipse, Visual Studio.NET …
Un support de construction d'environnement spécifique individuel (ou entreprise).
Le schéma suivant illustre les modules intégrés dans la version 5.0.2 de StarUML utilisée dans notre application.
SHAPE \* MERGEFORMAT
Figure 5-3: Les modules intégrés dans la version 5.0.2 de StarUML
Notre application est intégrée sous forme d’un module appelé StarUML UDDP.
5.3. Architecture de UDDPTool
. EMBED Word.Picture.8
Figure 5-4: Organisation des modules du UDDPTool
5.3.1. Le Module verbalisation
Il est chargé de la verbalisation des exemples de domaine de l’univers de discours introduits par l’utilisateur. Il lui permet de faire ceci en deux étapes.
1. En premier lieu, l’outil sert à verbaliser les exemples introduits par l’utilisateur de façon automatique en générant des phrases en langage naturel en base des prédicats et base des contraintes et la population des exemples en base de population.
2. En deuxième lieu, le module verbalisation donne la main à l’utilisateur pour modifier les résultats générés et concevoir d’autres.
5.3.2. Le Module acquisition
Il permet aux utilisateurs d'introduire une ontologie de domaine dans la base des ontologies du système, de choisir l’ontologie qui convient et de faire les modifications nécessaires. L’ontologie choisie sera utilisée dans le processus UDDP pour enrichir la sémantique du modèle.
5.3.3. Le Module UDDP
C’est le module principal dans le système conçu. C’est un enchaînement des procédures qui implémentent les étapes de l’approche UDDP. Il est interactif avec l’utilisateur ou l’expert de domaine pour valider les résultats obtenus de chaque étape. Le processus UDDP pourrait être interrompu par l’utilisateur s’il se contente de résultats obtenus après une étape donnée. Et alors, il visualisera les résultats graphiquement sur StarUML.
5.3.4 Le Module générateur de diagrammes UML
Ce module s’occupe de la visualisation graphique des résultats obtenus sur StarUML. Il se base sur les API fournis par celui-ci pour transformer la base de résultats en éléments visuels d’UML.
5.4 Test sur un exemple : un système d’information d’une organisation
Dans les paragraphes précédents, nous avons montré le fonctionnement de l’outil UDDP et son architecture. Pour valider notre approche, autrement dit, pour vérifier qu'elle est viable, nous avons effectué des tests sur des exemples pour voir l'apport de notre outil sur la qualité des diagrammes obtenus.
Pour ce faire, nous allons présenter ici les différentes interfaces de notre outil suite un exemple traité d’un système d’information d’une organisation.
5.4.1. Les entrées du système
- Exemples de domaine de l’univers de discours (Cas d’utilisation de données)
EmployéDeptSuperviseurSituation familiale N° TelAnnée de MariageNbre
EnfantsAllocat(da)MoussaD1AhmedM3715821200321000NaceurD1MoussaC----BrahimD2MoussaM-2005--AhmedD2*M3783437200600N.B : « * » = ‘non-exitant’ « - » = ‘non enregsitré’
Tableau 5-1: Cas d’utilisation de données
Ontologie de domaine : d’une organisation:
L’ontologie qu’on a choisie dans cet exemple est une ontologie qui décrit le domaine d’une personne et ses intérêts [Heflin-2001]. Les classes et relations de cette ontologie ont été citées dans le chapitre précèdent.
Son contenu est donné en langage DAML dans les annexes.
5.4.2. Des interfaces de l’application
5.4.2.1. L’interface principale de l’application
Figure 5-5: L’interface principale de l’application
5.4.2.2. L’interface de verbalisation
Figure 5-6: L’interface de verbalisation
5.4.2.3. L’Interface de l’acquisition de l’ontologie de domaine
Figure 5-7: L’interface d’acquisition de l’ontologie
5.4.3. Les Résultats sur StarUML
- Sans l’ontologie de domaine
Figure 5-8: Résultat de l’exemple traité sans l’utilisation de l’ontologie de domaine
Nous remarquons, par exemple, que la contrainte textuelle ‘Chaque superviseur ne supervise qu’un seul employé par département’ a été identifiée en utilisant l’outil UDDP, chose qui ne serait pas tout à fait évidente en abordant la conception en UML directement.
- Avec l’ontologie de domaine
Figure 5-9: Résultat de l’exemple traité avec l’utilisation de l’ontologie de domaine
On constate qu’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’.
Notons que relativement à la consistance de l’ontologie de domaine et sa cohérence avec le système d’information traité et l’avis de l’expert de domaine, l’ontologie enrichit davantage la sémantique des diagrammes.
5.5 Conclusion
Notre outil UDDPTool est une implémentation de l’approche UDDP. Elle fonctionne sur une plateforme open source de modélisation UML.
Cette plateforme nous permet d’intégrer notre contribution comme un outil d’aide à la conception dans un environnement assez complet de conception UML. Donc, l’utilisateur peut se servir de notre procédure pour générer des diagrammes UML sémantiquement riches constituant un point de départ solide dans sa conception sur StarUML.
UDDPTool se base sur un langage pseudo-naturel comme un moyen de communication fort entre le système et l’expert ou l’utilisateur. Il utilise l’ontologie de domaine pour enrichir la sémantique du modèle.
Nous avons effectué des tests sur des exemples avec et sans l’ontologie de domaine pour voir l’apport de l’ontologie dans la conception des diagrammes UML.
Conclusions et Perspectives
Implémentation
Conclusions et Perspectives
Conclusions
Les hypothèses formulées au début du travail et sur lesquelles s'est fondée notre problématique étaient :
Le manque de syntaxe et d’outils permettant la capture maximum de la sémantique de données en UML.
Le manque de mécanismes de validation et de communication forte entre le concepteur et l’expert de domaine lors du développement d’une conception en UML.
Les lacunes constatées sur les outils actuels de l’ingénierie des systèmes d’information.
Partant de ces hypothèses, les travaux présentés dans le cadre de ce mémoire ont eu pour objectif de fournir au concepteur en UML une démarche d’élaboration de diagrammes UML valides et sémantiquement riches à partir de l’univers de discours. Les diagrammes obtenus ne représentent pas la totalité de la conception mais ils constituent un point de départ solide pour le concepteur en UML.
Nous avons constaté que la capture de la sémantique 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.
Notre approche est inspirée de la procédure CSDP d’ORM, vu sa puissance dans la capture de la sémantique de données à partir de l’univers de discours.
La CSDP est une procédure de neuf étapes qui permet de dériver un schéma conceptuel ORM à partir des exemples significatifs de l’univers de discours tout en validant avec l’expert de domaine. La notation ORM dispose de plusieurs contraintes qui capturent le maximum de la sémantique de données. Des comparaisons entre ORM et UML ont fait l’objet de plusieurs travaux [Halpin-1998a; Halpin-1998b; Halpin-1998c; Halpin-1998d; Halpin et al.-1999] et, en occurrence, des règles de correspondance entre les deux notations ont été établies.
Ces règles ont été exploitées dans notre approche pour la génération des diagrammes UML à partir de l’univers de discours. En effet, notre approche est une adaptation de la procédure CSDP à la notation UML.
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.
Notre approche exploite l’ontologie de domaine pour enrichir la conception et minimiser l’intervention de l’expert de domaine. En effet, notre démarche peut être considérée comme une approche d’élaboration des diagrammes UML 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).
Le processus de notre démarche appelée UDDP (UML Diagram Design Procedure) se déroule en neuf é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’intérêt de notre approche est de fournir au concepteur en UML un schéma conceptuel sémantiquement riche validé avec l’expert de domaine et décrivant l’univers de discours à base de l’ontologie de domaine.
Une expérimentation de cette approche a été réalisée et les tests ont été effectués sur des exemples afin de vérifier l’apport de cette contribution.
Perspectives
Le travail réalisé dans ce mémoire ouvre diverses perspectives. Nous en donnons ci-dessous quelques-unes.
L’approche actuelle ne traite que l’aspect statique d’un système d’information. Elle pourrait être étendue pour décrire aussi l’aspect dynamique en utilisant les ontologies de tâches ou d’autres techniques.
Notre démarche utilise une ontologie légère de domaine pour enrichir la sémantique du schéma conceptuel élaboré. Nous utiliserions des ontologies lourdes pour une exploitation complète de l’ontologie de domaine.
L’ontologie Wordnet n’était pas utilisée dans notre approche à cause de l’inexistence d’une version française complète. L’utilisation de l’ontologie Wordnet pour le calcul de la distance sémantique entre les termes de domaine et l’ontologie constituerait un travail futur intéressant.
Par ailleurs, nous proposons d’inclure un système intelligent pour décider les relations d’agrégation et de composition.
Enfin, cette proposition pourrait être adaptée à la re-ingénierie des ontologies.
Annexes
Conclusions et Perspectives
Annexes
Quelques ontologies de domaine utilisées dans notre outil
Ontologie 1 : ontologie d’une organisation
personal-ont, v.1.0An ontology that defines elements for describing an individual and his/her interests.
Ontologie 2 : ontologie d’une université
university-ont, v.1.0An ontology for describing universities and the activities that occur at them.
Bibliographie
Bibliographie
[Abba et al.-1993]: Abbattista F., Lanubile F., and Visaggio G.. Recovering conceptual data models is humanintensive, In Proc. of 5th Intl. Conf. on Software Engineering and Knowledge Engineering, San Francisco, California, USA, pages 534–543, 1993.
[Aike et al.-1994]: Aiken P., Muntz A., Richards R., DoD legacy systems reverse engineering data requirements, Communications of the ACM, Vol. 37, No 5, pages. 26-41,1994.
[Akoka et al.-1998]: Akoka J., Comyn-Wattiau, I., MeRCI: An Expert System for Software Reverse Engineering, In Proc. of the 4th World Congress on Expert System, Mexico, 1998.
[Akoka et al.-1999]: Akoka J., Comyn-Wattiau I., Rétro-conception des Datawarehouses et des Systèmes Multidimensionnels, In Proc. of the INFORSID’99, pages 227-255, France, 1999.
[Anderson-1996]: Anderson M., Reverse Engineering of Legacy Systems: From Value-Based to Object-Based Models, PhD thesis, EPFL, Switzerland, 1996.
[Arnold-1993]: Arnold R.S., Software reengineering, Los Alamitos, IEEE Computer society press, California, page 675, 1993.
[Astrova et al.-2004]: Astrova I., Stantic B., Reverse Engineering of Relational Databases to Ontologies, An Approach Based on an Analysis of HTML Forms, 2004
[Batini et al.-1992]: Batini C., Ceri S., Navathe S., Conceptual Database Design: an Entity Relationship Approach, Benjamin Cummings, 1992.
[Belalem et al.-2005]: Belalem G., Bekki K., Mekroufi L., Riadh A., Elaboration des Diagrammes d’UML à partir de l’Univers de Discours, In proc; COSI’05 :Actes du colloque sur l’optimisation et les systèmes d’information, pages 52-64 Bejaia, Algérie, 12-14 juin, 2005.
[Bennet-1991]: Bennett K., Automated support of software maintenance, Information and Software Technology, Vol. 33, No. 1, pages 74-85,1991.
[Berners-Lee et al.-2001]: Berners-Lee T., Hendler J., Lassila O., The semantic Web, in Scientific American, 2001.
[Bird et al.-1999]: Bird L., Goodchild A., Halpin T.A., Object Role Modelling and XML-Schema, In: Proceedings of the 19th International Conference on Conceptual Modeling (ER’00), Laender A., Liddle S., Storey V. (eds.). LNCS, Springer Verlag, 1999.
[Bollen-2002]: Bollen P., A Formal ORM-to -UML Mapping Algorithm, HYPERLINK "http://ideas.repec.org/s/dgr/umamet.html" Research Memoranda N°15, University of Maastricht, The Netherlands, 2002.
[Booch et al.-1999]: Booch G., Jacobson I., Rumbaugh J., The Unified Software Development Process, Addison Wesley Longman, 1999.
[Booch et al.-2000]: Booch G.., Jacobson I., Rumbaugh J., Le guide de l’utilisateur UML, Éditions Eyrolles, février, 2000.
[Bouchiha-2005] : Bouchiha D., Rétro-ingénierie des applications Web à base d’ontologie, mémoire de Magister, Université Djillali Liabes, Sidi Bel Abbès, Algérie, 2005.
[Brodie et al.-1995]: Brodie M.L., Stonebraker M., Migrating legacy systems. Gateways, Interfaces and the incremental approach, Morgan, 1995.
[Casanova et al.-1983]: Casanova M.A., Amaral de Sa J.E., Designing Entity-Relationship Schemes for Conventional Information Systems, In Proc. of the International Conference on Entity-Relationship Approach (ER'83), pages 265-277, 1983.
[Castellanos et al.-1993]: Castellanos M., Saltor F., Extraction of Data Dependencies, In Proc. of 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, 1993.
[Castellanos et al.-1995]: Castellanos M., Saltor F., Garcia-Salco M., Semantically Enriching Relational Databases into Object-Oriented Semantic Model, in Proc. of the 5th Inter. Conf. Of DEXA, vol. 856 in computer science Spinger-Verlag, Athens, 1995.
[Chiang-1995]: Chiang R.H.L, A Knowledge-Based System for Performing Reverse engineering of Relational Databases, Decision Support Systems, 13: pages 295-312, 1995.
[Chikofsky et al.-1990]: Chikofsky E.J., Cross J.H., Reverse engineering and design recovery: A taxonomy, IEEE Software, Vol 7(1) pages13-17, IEEE Computer Society Press, 1990.
[Cim-1993]: Information System Criteria for Applying Software reengineering, Arlington, VA: Software Systems Engineering Directorate – Reengineering Division, DISA-JIEO-CIM, pagination multiple, Mai. 1993.
[Comyn et al.-1996]: Comyn-Wattiau I., Akoka J., Reverse Engineering of Relational Database Physical Schema,. In Proc. of the International Entity-Relationship Conference (ER’96), pages 372-391, Germany, 1996.
[Conallen-1999a]: Conallen J., Building Web Applications with UML object technology, Addison-Wesley Longman Reading, Massachusetts, USA, first edition, Dec. 1999.
[Conallen-1999b]: Conallen J., Modeling Web Application Architectures with UML, Communications of the ACM, vol. 42, n. 10, October 1999.
[Corcho and al.-1999]: Corcho O., Gòmez-Pérez A., Guidelines to study difference in expressiveness between ontology specification languages: A case of study, In proc of int. conf. KAW’99, 1999.
[Cui et al.-1999]: Cui Z., Tamma V., Bellifemine F., Ontology Management in Enterprises, British Telecommunications Technology Journal, October, 1999.
[Davis and al.- 1987]: Davis K., Arora A., Converting a Relational Database Model into an Entity- Relationship Model, In Salvatore T. March editor, Proc. of the 6th Internatial Conference on Entity-Relationship Approach (ER’87), pages 271-285, 1987.
[Demy et al.-2002]: Demey J., Jarrar M., Meersman R. A, Conceptual Markup Language that supports interoperability between Business Rule modeling systems, In Proceedings of the Tenth International Conference on Cooperative Information Systems (CoopIS 02), Springer Verlag LNCS 2519, pages 19–35, 2002.
[Dowell et al.-1995]: Dowell M. L., Stephens L.M., Bonnell R.D., Using a Domain Ontology as a Semantic Geteway among information Ressources, Workshop on Basic Ontological Issues in knowledge Sharing, IJCAI, 1995.
[Dumpala et al.-1983]: Dumpala S.R., Arora S.K., Schema Translation using the Entity-Relationship Approach, In Proc. of the International Conference on Entity-Relationship Approach (ER'83), pages 337-356, 1983.
[Fahrner et al.-1995a]: Fahrner C., Vossen G., A survey of database design transformations based on the Entity-Relationship model, Data Knowledge Engineering, 15(3), 1995.
[Fahrner et al.-1995b]: Fahrner C., Vossen G., Transforming Relational Database Schemas into Object-Oriented Shemas According to ODMG_93, In proc. Of the 4th Inter. Conf. On Deductive and Object_oriented Database, pages 429-446, Spinger-verlag, Singapour, 1995
[Fong-1993]: Fong J., Ho M., Knowledge-Based Approach for Abstracting Hierarchical and Network Schema Semantics, In 12th Int. Conf. on ERA Approach, Arlington Texas, 1993.
[Fonkam et al.-1992]: Fonkam M., Gray W., An Approach to eliciting the Semantics of Relational Databases, In advanced Info. Sys. Engineering, pages 461-480, Berlin, 1992.
[Frederico et al.-2003]: Frederico F., Clodoveu D., Gilberto C., Bridging Ontologies and Conceptual Schemas in Geographic Information Integration, Kluwer Academic Publishers. Manufactured in The Netherlands, 2003.
[Frederico-2001]: Frederico F., Ontology-driven geographic information systems, in Spatial information Science and Engineering, University of Maine, page .118, Orono, 2001.
[Gruber -1993]: Gruber T. R., Toward principles for the design of ontologies used for knowledge sharing, Report KSL 93-04, Stanford University, august, 1993.
[Guarino-1998]: Guarino N., Formal ontology and information systems, In N.Guarino (Ed.). Formal ontology in information systems, IOS Press, pages: 3-15, Amsterdam. The Netherlands, 1998.
[Hainaut et al.-1993]: Hainaut J.-L., Chandelon M., Tonneau C., Joris M., Contribution to a Theory of Database Reverse Engineering, In Proc. of the Working Conference on Reverse Engineering (WCRE’93), IEEE Computer Society Press, Baltimore, 1993.
[Hainaut et al.-1995] : Hainaut J., Englebert V., Henrard J., Hick J., Roland D., Requirements for Information System Reverse Engineering Support, In Proc. Of Int. conf. WCRE, pages 134-145, 1995.
[Hainaut et al.-1996]: Hainaut J., Henrard J., Hick J., Roland D., Englebert V., Database Design Recovery, In Proc of int. Conf. CAISE, pages: 272-300, 1996.
[Hainaut et al.-1997]: Hainaut J., Henrard J., Hick J., Roland D., Englebert V., Contribution to the Reverse Engineering of OO Applications- Methodology and Case Study, IFIP Working Conference On Database Semantics, Chapman et Hall, 1997.
[Hainaut-1998]: Hainaut J., Database Reverse Engineering Book, University of Namur; Institut d’Informatique, 1998.
[Halpin-1993]: Halpin T.A., What is an elementary fact?, Proc. First NIAM-ISDM Conf., eds G.M. Nijssen & J. Sharp, Utrecht, 1993.
[Halpin-1998a]: Halpin T.A.,Object Role Modeling (ORM/NIAM), Handbook on Architectures of Information Systems, P. Bernus, K. Mertins & G. Schmidt eds, Springer-Verlag, Berlin, pages 81-101, 1998.
[Halpin-1998b]: Halpin T. A., Object Role Modeling: an overview, 1998, available online at HYPERLINK "http://www.orm.net/overview.html" http://www.orm.net/overview.html
[Halpin-1998c]: Halpin T. A., UML data models from an ORM perspective: Parts 1-10, Journal of Conceptual Modeling, InConcept, Minneapolis USA, 1998, available online from: HYPERLINK "http://www.orm.net/uml_orm.html" www.orm.net/uml_orm.html
[Halpin-1998d]: Halpin T.A., Bloesch A.C., A comparison of UML and ORM for data modeling, Proc. EMMSAD’98: 3rd IFIP WG8.1 Int. Workshop on Evaluation of Modeling Methods in Systems Analysis and Design, Pisa, Italy, June 1998.
[Halpin et al.-1999]: Halpin T.A., Bloesch, A.C., Data modeling in UML and ORM: a comparison, Journal of Database Management, vol. 13, no. 2, Idea Group Publishing, Hershey PA,1999.
[Halpin-1999]: Halpin T., Data modeling in UML and ORM revisited, in Proceedings EMMSAD'99, 1999.
[Halpin-2000a]: Halpin, T.A., Integrating fact-oriented modeling with object-oriented modeling, Information Modeling in the New Millenium, eds M. Rossi & K. Siau, Idea Group Publishing Company, Hershey, USA,2000.
[Halpin-2000b]: Halpin T., Microsoft’s new database modelling tool: Part 1, Journal of Conceptual Modeling, June 2000.
[Halpin-2001a]: Halpin T.A., Information Modeling and Relational Databases, Morgan Kaufmann, San Francisco, 2001.
[Halpin-2001b]: Halpin T.A., Supplementing UML with concepts from ORM, Unified Modeling Language: Systems Analysis, Design, and Development Issues, eds K. Siau & T. A. Halpin, Idea Publishing, Hershey PA, 2001.
[Halpin-2001c]: Halpin T.A., Augmenting UML with Fact-orientation, In workshop proceedings, UML: a critical evaluation and suggested future, HICCS-34 conference, 2001.
[Halpin-2002a]: Halpin T.A., Metaschemas for ER, ORM and UML: A Comparison, Journal of Database Management, Idea Group Publishing, Hershey PA, pages: 4-13, 2002.
[Halpin-2002b]: Halpin T.A., Business Rules, WG RFI Response North Face Learning, Inc., October 2002.
[Halpin-2004a]: Halpin, T.A., Object-Role Modeling and Business Rules, Cours, Northface University, USA, 2004.
[Halpin-2004b]: Halpin, T.A., Business Rule Verbalization, 3rd International Conference on Information Systems Technologies and Applications (ISTA 2004). Salt lake City, USA, 15-17, July 2004.
[Heflin-2001]: Heflin J., Personal ontology, Univ. of Maryland, 2001. HYPERLINK "http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0" http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0
[Henrard-2003]: Henrard J., Program understanding in database reverse engineering, Thèse de doctorat, University of Namur - Institut d’Informatique, 2003.
[Henri-1993] : Habrias H., Le modèle relationnel binaire, édition Eyrolles, Paris 1993.
[Hick-2001]: Hick J. Marc., Evolution d’applications de bases de données relationnelles méthodes et outils, thèse de doctorat, Université de Namur, 2001.
[Jahnke-1999]: Jahnke J.-H., Managing Uncertainty and Inconsistency in Database Reengineering Processes, PhD Thesis, University of Paderborn, Germany, 1999.
[Jarrar-2005]: Jarrar M., Towards methodological principles for ontology engineering, PhD Thesis, STARLab, Vrije Universiteit Brussel, Belgium, 2005.
[Jarrar et al.-2003]: Jarrar M., Demey J., Meersman R., On Using Conceptual Data Modeling for Ontology Engineering, In Spaccapietra, S., March, S., Aberer, K., (Eds.) Journal on Data Semantics (Special issue on Best papers from the ER, ODBASE, and COOPIS 2002 Conferences). LNCS, Vol. 2800, Springer, pages 185-207, October 2003.
[Ji-1991]: Ji W., An algorithm converting Relational Schemas to Nested Entity-Relationship Schemes, in proc 10th int. Conf. On ERA’91 San Mateo, pages 231-246, 1991.
[Johannesson et al.-1989]: Johannesson P., Kalman K., A Method for translating relational schemas in to conceptual schemas, in proc 8th int. Conf. On the ERA’89, pages 279-293, 1989.
[Johannesson-1994]: Johannesson P., A Method for Transforming Relational Schemas into Conceptual Schemas, in Proc. of the 10th Int. Conf. on Data Engineering, pages 190-201. IEEE Computer Society, USA, 1994.
[Kalman-1991]: Kalman K., Implementation and Critiques of an Algorithm wich maps a Relational Database to a Conceptual Model, In Proc. Of the 3dr Inter. Conf. On computer aided Software Engineering, 1991.
[Kayser-1997] : Kayser D., La représentation des connaissances, Hermès, 1997.
[Lafu-1990]: Lafue G.M.E., Panel on software Re-Engineering, In Proc. 12th International Conference on Software Engineering, page 118, Nice (France), March 1990.
[Lopes et al.-2002]: Lopes S., Petit J.-M., Toumani F., Discovering interesting inclusion dependencies: application to logical database tuning, Information Systems, 27, pages 1-19, 2002.
[Malki-2002]: Malki M., Rétro-ingénierie des applications – bases de données relationnelles : Approche dirigée par l’analyse de formulaires, Thèse de doctorat d’état, université Djillali Liabes, Sidi Belabbes, Algérie, 2002.
[Mannila et al.-1994]: Mannila H. et al, The design of Relational Databases, Addison-Wesley publishing, second edition 1994.
[Markowitz et al.-1990]: Markowitz V.M., Makowsky J.A.: Identifying Extended Entity-Relationship Object Structure in Relational Schemas, IEEE transaction on software engineering, vol. 16(8) pages 777-790, 1990.
[Meersman-1999]: Meersman R., Semantic Ontology Tools in Information System Design, In Proc. Of the ISMIS’99 Conf., Z. Ras and M. Zemankova (eds.), LNCS, Springer Verlag, 1999.
[Melkanoff et al.-1980]: Melkanoff M. A., Zaniolo C., Decomposition of relations and synthesis of Entity-Relationship diagrams, Entity-Relationship Approach to systems analysis end Design, 1980.
[Miller et al.-1993]: Miller R.J., Ioannidis Y.E., Ramakrishnan R., The use of information capacity in schema integration and translation, In Proc. Of the 19th VLDB Conference, Dublin, 1993.
[Muller-1997]: Muller P. A., Modélisation Objet avec UML, 1eme édition, 1997.
[Navathe et al.-1988]: Navathe S.B., Awong A.M.: Abstracting Relational and Hierarchical Data with a Semantic Data Model, In Proc. of the 6th International Conference on Entity-Relationship Approach (ER’87), pages 305-333, 1988.
[Nilson et al.-1985]: Nilson E.G., The Translation of COBOL Data Structure to an Entity-Relationship Type Conceptual Schema, In Proc. Int. Conf. on ERA Approach, 1985.
[North-1999]: North K., Modeling, Data Semantics, and Natural Language, In: New Architect magazine, 1999.
[OMG-2003] OMG, UML. Unified Modeling Language specification, version 1.5. Document formal/03-03-01, March 2003. http://www.omg.org/technology/documents/formal/uml.htm
[Petit et al.-1995]: Petit J.M., Toumani F., Kouloumdjian J., Relational Database reverse Engineering: a Method based on Query Analysis, Inter. Journal of Cooperative Information System , vol.4(2,3), pages 287-316, 1995.
[Petit-1996]: Petit J-M, Fondements pour un Processus Réaliste de Rétro-Conception de Bases de Données Relationnelles, PhD thesis, University Lyon I, France, 1996.
[Premerlani et al.-1993]: Premerlani W.J., Blaha M.R.. An approach for Reverse Engineering of Relational Databases, In Proc. of the Working Conf. on Reverse Engineering (WCRE’93). IEEE Computer society Press, 1993.
[Ramanathan et al.-1996]: Ramanathan S., Hodges J., Reverse Engineering Relational Schemas to Object-Oriented Schemas, techreport 960701, Department of Computer Science, Mississippi State University, 1996.
[Rumbaugh et al.-1999]: Rumbaugh, Jacobson J., Booch G., The Unified Modeling Language Reference Manual, Addison-Wesley, Reading MA, USA, 1999.
[Rumbaugh et al.-2004]: Rumbaugh J., Jacobson I., Booch G.,The Unified Modeling Language: Reference Manual, Addison-Wesley, second edition, page 472, 2004.
[Shoval et al.-1993]: Shoval P., Shreiber N., database reverse Engineering from the Relational model to the Binary Relationship Model. Data and knowledge Engineering, vol 10, pages 293-315, 1993.
[Signore et al.-1994]: Signore O., Loffredo M., Gregori M., Cima M., Using Procedural Patterns in Abstracting Relational Schema,. In Proc. 3rd Workshop on Program Comprehension, 1994.
[Sousa et al.-1999]: Sousa P., Pedro de Jesus L., Pereira G., Brido F., Clustering Relations into abstract schemas for Database reverse engineering, In proc; of the 3rd Conf. on Software Maintenance and Reengineering,Amsterdam, pages 169-176,IEEE Computer Society, 1999.
[Soutou-1998a]: Soutou C., Relational Database Reverse Engineering: Extraction of cardinality constraints, Data and Knowledge Engineering, Elsevier, North Hollond, vol 28(2), pages 161-207, 1998.
[Soutou-1998b]: Soutou C., Inference of aggregation relationships through Database reverse Engineering, In proc. Of Int. conf. on Conceptual Modelling, Vol. 1507, pages 135-145, Springer Verlag, 1998.
[Sowa-2000a]: Sowa J., Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brook/Cole, a division of Thomsom Learning Pacific Grove, CA, 2000.
[Sowa-2000b]: Sowa J., Ontology, Metadata and semiotics, in Proceedings of the 8th International Conference on Conceptual Structures (ICCS’2000), Springer-Verlag, pages 55-81, 2000.
[StarUML-2006a]: StarUML, Software UML/MDA Tool, HYPERLINK "http://www.staruml.com" www.staruml.com
[StarUML-2006b]: StarUML, Developer Guide, HYPERLINK "http://www.staruml.com" www.staruml.com
[Storey et al.-1998]: Storey V., Dey D., Ullrich H., Sundaresan S., An ontology-based expert system for database design, Data and Knowledge Engineering, vol. 28, pages 31-46, 1998.
[Theodoros et al.-1998]: Theodoros L., Edwards H., Bryant A., Reverse Engineering from OO Source Code to OMT Design. 5th working Conf. On Reverse Engineering, Honolulu, 1998.
[Umar-1997]: Umar A., Application (Re)Engineering – Building Web-based Application and Dealing with Legacies, Prentice-hall International, London, 1997.
[Uschold et al.-1998]: Uschold M., King M., Moralee S., Zorgios Y., The Enterprise Ontology, The Knowledge Engineering Review, Vol. 13, Special Issue on Putting Ontologies to Use, 1998.
[Verheijen et al.-1982]: Verheijen G., Bekkum v., NIAM:an Information Analysis Method, In: Olle, T.W., Sol H. and Verrijn-Stuart A. (eds.), IFIP Conference on Comparative Review of Information Systems Methodologies, North-Holland, pages 537-590,1982.
[Vermeer et al.-1995]: Mark W., Vermeer W., Peter M., Apers G., Reverse Engineering of Relational Database Applications, In Proc. Of Int. Conf. OOER, pages 89-100, 1995.
[Wintraecken-1990]: Wintraecken J., The NIAM Information Analysis Method: Theory and Practice, Kluwer, Deventer, 1990.
[Yang et al.-1999]: Yang H., Cui Z., O'Brien P., Extracting Ontologies from Legacy Systems for Understanding and Re-engineering, In proc of IEEE international conference on Computer Software and Applications, 1999.
Résumé
UML (Unified Modeling Language) est devenu aujourd'hui un langage standard pour la conception et la modélisation orientée objet. Cependant, il souffre d’un 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 ORM (Object Role Modeling), qui se base sur la modélisation des systèmes d’informations à partir des exemples simples du domaine en utilisant une procédure 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, nous proposons dans ce travail, une adaptation de CSDP à la notation UML et en utilisant l’ontologie de domaine comme source sémantique complémentaire dans une approche appelée UDDP (Uml Diagram Design Procedure).
MOTS- CLES : CSDP, Système d’information, UML, Ontologies, ORM, Rétro- ingénierie, UDDP.
Abstract
The unified modeling language (UML) has become a standard object modeling and design language. Nevertheless, it needs other syntax and tools to capture more data semantics from the universe of discourse (U°D). This capture may be obtained goodly in ORM (Object Role Modeling), which build the information modeling from data use cases using a powerful procedure called CSDP (Conceptual Schema and relational database Design Procedure). To gain the power of this procedure in elaborating semantically expressive UML diagrams, we propose in this work, an adaptation of CSDP to UML using the domain ontology as complementary semantic source. This approach is called UDDP (Uml Diagram Design Procedure).
KEYWORDS : CSDP, Information System, UML, Ontology, ORM, Reverse engineering, UDDP.
Introduction générale PAGE 3
Chapitre 1: Retro-ingenierie des bases de donnees: Etat de l’art PAGE 15
Chapitre 2: Les ontologies PAGE 24
Chapitre 3: Les notations ORM et UML PAGE 52
Chapitre4: l’approche UDDP PAGE 70
Chapitre 5: Implémentation PAGE 80
Conclusions et Perspectives PAGE 83
Annexes PAGE 94
Bibliographie PAGE 102
EMBED Word.Picture.8
MoussaD1NaceurD1BrahimD2AhmedD2
Moussa3715821Ahmed3783437
EMBED Word.Picture.8
¶
THEME
StarUML -UDDP
StarUML -xmi
StarUML -standard
StarUML -rose
StarUML -pattern
StarUML -java
StarUML -generator
StarUML -csharp
StarUML-cpp
StarUML
(Plateforme)
Z [ \ £ Þ é þ - T V f k m õ ö ÷ ø ù ú û ü îÚÉÚµ¥˜¥˜¥‹zlzXz‹N=‹=‹N !j h‰f hçº OJ QJ U^J hçº OJ QJ ^J &hôxÄ hçº 5CJ OJ QJ \^J aJ hçº CJ OJ QJ ^J aJ hôxÄ hçº CJ OJ QJ ^J aJ h‰f hçº OJ QJ ^J hçº 5OJ QJ \^J hôxÄ hçº 5OJ QJ \^J &hîG^ hçº 5OJ QJ \^J mHsH hçº 5OJ QJ \^J mHsH &hôxÄ hçº 5OJ QJ \^J mHsH "hôxÄ hçº 5CJ \aJ mHsH Z [ \ £ Û Ü Þ 9 T U V l m € ‚ ¡ ª Ä Å Î ï ‚&