par Apprentissage Symbolique Automatique

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE D’ORAN ES-SENIA
FACULTE DES SCIENCES
DEPARTEMENT D’INFORMATIQUE
MEMOIRE
Présenté par
Melle Chérifa BOUDIA
Pour obtenir
LE DIPLOME DE MAGISTER
Spécialité Informatique
Option : Informatique et Automatique
Intitulé :
Étude et mise en pratique d’une démarche
de modélisation (UML)
par Apprentissage Symbolique Automatique
Soutenu le :
à la salle de conférences de la faculté des sciences
Devant les membres du jury:
M. M. K. RAHMOUNI
M. A. BENYETTOU
M. A. LEHIRECHE
M. K. BOUAMRANE
M. B. BELDJILALI
M. B. ATMANI
Professeur, Université d’Oran, ES-Sénia, Algérie
(Président)
Professeur à l’USTO Mohamed Boudiaf, Oran, Algérie
(Examinateur)
Maître de Conférence, Université de Sidi-bel-abbes, Algérie
(Examinateur)
Docteur, Université d’Oran, ES-Sénia, Algérie
(Examinateur)
Professeur, Université d’Oran, ES-Sénia, Algérie
(Rapporteur)
Chargé de cours, Université d’Oran, ES-Sénia, Algérie
(Rapporteur)
2
L écriture d une telle page n est pas une tâche aisée. Bien sûr, des noms viennent
immédiatement à l esprit; mais combien d anonymes ou d oubliés ont, indirectement,
contribué à cette thèse ? Difficile à dire, d autant plus qu en la matière, la subjectivité est
reine. Que ceux et celles que je n ai pas nommés reçoivent l expression de toutes mes
pensées.
Tout d abord, je remercie le grand Dieu qui m a inspiré le courage et la patience
pour terminer ce travail. Bien évidemment, une mention spéciale revient à M. Bouziane
Beldjilali et M. Baghdad Atmani de l université d Oran, d avoir accepté d encadrer cette
thèse et m avoir accueilli au sein de l équipe, ils m ont apporté bien plus que la compétence
scientifique nécessaire pour obtenir ce magister, leur disponibilité, leur écoute, leurs
conseils avisés et leur grande humanité font d eux des personnes que j ai en profonde
estime.
Je tiens aussi à remercier chaleureusement les examinateurs de ce travail, M. A.
BENYETTOU de l’USTO_MB, Oran, M. A. LEHIRECHE de l université de SBA, et M. K.
BOUAMRANE de l université d Oran, qui ont accepté de se plonger dans cet écrit malgré
leur emploi du temps assurément chargé. La pertinence de leurs questions et la qualité de
leurs rapports m honorent sincèrement.
Je remercie également M. M. K. RAHMOUNI, qui m a fait le plaisir d accepter de
présider le jury.
Je remercie les doctorants, les enseignants, les post-graduants et tous les employeurs
du département depuis le directeur aux simples employeurs, qui ont également contribué
à ce travail, par leur simple présence et l ambiance excellente qu ils ont su créer.
Mes amis, sont pour beaucoup dans l achèvement de ce travail de longue haleine,
Mme H. Dahmani, Mme Z. Benhadjla et Mme S. Saichi. Je les remercie pour des jours et des
jours d écoute, des aventures inoubliables. Je pense à Tahia Adnane, ma vieille amie pour
nos nombreux rencontres au cybercafé et discussions multilingues, son écoute et son sens
de l humour infini que Dieu te protège.
Et bien sûr, mes galantes salutations vont à ma famille, qui a toujours eu confiance
en moi, et m a soutenu dans les moments difficiles : mon père, Kada Boudia, ma mère,
Nedjar Fatiha, ainsi que ma s ur Saliha, mes frères, Mohamed, Yacine et Adel. Merci
être restés unis dans toute cette aventure.
Merci à toutes et à tous…
Table des matières .............................................................................................................................1
Introduction générale........................................................................................................................4
1
2
Introduction ...................................................................................... Erreur ! Signet non défini.
Positionnement ............................................................................... Erreur ! Signet non défini.
2.1 Présentation générale.......................................................... Erreur ! Signet non défini.
2.2 Objectifs ..................................................................................... Erreur ! Signet non défini.
3 Travaux connexes.......................................................................... Erreur ! Signet non défini.
3.1 Apprentissage Automatique.............................................. Erreur ! Signet non défini.
3.2 UML .............................................................................................. Erreur ! Signet non défini.
4 Conclusion ......................................................................................... Erreur ! Signet non défini.
1
2
Introduction .................................................................................................................................21
UML : Développement orienté objet................................................................................21
2.1 Concepts de modélisation UML ..................................................................................21
2.2 Modèles et notations en UML ......................................................................................22
2.2.1 Diagrammes UML .....................................................................................................22
2.2.2 Vues de modélisation .............................................................................................24
2.2.3 Méta-modèle...............................................................................................................25
2.3 Processus de développement itératif ......................................................................25
3 Démarches ...................................................................................................................................26
3.1 Cas d’utilisation .................................................................................................................26
3.2 Architecture logicielle......................................................................................................27
3.3 Cycle de vie itératif et incrémental ..........................................................................27
4 Sélection d’une méthode.......................................................................................................28
5 Critères d’évaluation ...............................................................................................................28
5.1 Qualité de l’architecture logicielle.............................................................................29
5.1.1 Réutilisabilité ..............................................................................................................29
5.1.2 Modifiabilité .................................................................................................................29
5.1.3 Traçabilité ....................................................................................................................29
5.2 Qualité du processus de développement ..............................................................29
5.2.1 Pouvoir de vérification ...........................................................................................30
5.2.2 Compréhensibilité ....................................................................................................30
5.2.3 Facilité d’utilisation..................................................................................................30
5.2.4 Pouvoir d’expression...............................................................................................30
4
6
Aspects avancés en UML .......................................................................................................31
6.1 Aspects dynamiques........................................................................................................31
6.2 Histoires des utilisateurs et Programmation extrême.....................................32
6.3 UML et la description d’architectures logicielles ................................................33
6.4 UML : le chemin vers l’unification des processus..............................................34
7 Le modèle UML obtenu est-il correct ? ...........................................................................35
8 Présentation d’OCL...................................................................................................................36
8.1 Le paquet UML-OCL.........................................................................................................36
8.2 Limitations et défauts d’OCL .......................................................................................37
8.3 Approches existantes : Méta-modèles UML et OCL intégrés .......................37
9 Conclusion ....................................................................................................................................38
1
2
Introduction .................................................................................................................................40
Apprentissage automatique .................................................................................................40
2.1 Apprentissage connexionniste....................................................................................41
2.2 Apprentissage symbolique ...........................................................................................42
2.2.1 Naissance de l'ASA et état de l'art...................................................................44
2.2.2 Les étapes du processus de l’ECD....................................................................46
2.2.2.1 Prétraitement des données .............................................................................46
2.2.2.2 Traitement des données ...................................................................................51
2.2.2.3 Validation .................................................................................................................52
2.2.3 Arbre de décision......................................................................................................52
2.2.3.1 Mode de fonctionnement ..................................................................................53
2.2.3.2 Les Systèmes fondés sur les Arbres de Décision..................................53
2.2.3.3 Finalités sur les Arbres de Décision.............................................................56
2.2.3.4 Avantages de l induction par graphes d induction................................56
2.2.4 Les algorithmes génétiques.................................................................................57
2.2.4.1 Mode de fonctionnement ..................................................................................58
2.2.4.2 Apprentissage des AG........................................................................................58
2.2.4.3 Finalités sur les algorithmes génétiques...................................................59
2.2.5 Raisonnement basé sur les cas : CBR............................................................59
2.2.5.1 Mode de fonctionnement ..................................................................................59
2.2.5.2 Finalités sur le Raisonnement Fondé sur des Cas ................................59
3 Sipina..............................................................................................................................................60
3.1 Méthode SIPINA ................................................................................................................60
3.1.1 Le choix du critère ...................................................................................................60
3.1.2 Fixation du paramètre λ........................................................................................61
3.1.3 Fixation de la contrainte d'admissibilité ........................................................62
3.1.4 Prise en compte des attributs continus .........................................................63
3.1.5 Éléments de construction de graphes d'induction ....................................64
3.1.6 Passage de la partition Si à la partition Si+1 ................................................66
3.2 Algorithme SIPINA ...........................................................................................................69
4 Conclusion : quelle est la méthode choisie ?...............................................................70
5
1
2
3
Introduction .................................................................................................................................73
Méthode d’analyse et de conception logiciel................................................................73
Méthode proposée ....................................................................................................................73
3.1 Démarche proposée pour la modélisation ............................................................74
3.2 Architecture globale pour l’expérimentation de la démarche proposée .80
3.2.1 Modélisation UML de la gestion de pharmacie............................................78
3.2.2 Processus de l’ECD pour la gestion de pharmacie....................................82
3.2.2.1 Première Expérimentation ...............................................................................82
3.2.2.2 Autres Expérimentations ..................................................................................88
5 Conclusion ....................................................................................................................................89
1
2
Introduction .................................................................................................................................91
La plate-forme de réalisation ..............................................................................................91
2.1 Composition de l’atelier .................................................................................................91
2.1.1 Module de prétraitement de données.............................................................92
2.1.2 Module Sipina.............................................................................................................93
2.1.3 Module de stockage de base de données .....................................................93
3.1.4 Module ArgoUML .......................................................................................................94
2.1.5 Intervention du concepteur et de l’expert....................................................96
3 L’organigramme de la plate-forme.................................................................................100
4 L’environnement d’implémentation..................................................................................98
4.1 Langage de programmation JBuilder version X .................................................98
4.2 WINDOWS XP .....................................................................................................................98
4.3 Modeleur UML : ArgoUML .............................................................................................98
5 Conclusion ....................................................................................................................................99
Conclusion générale.......................................................................................................................104
Références bibliographiques ......................................................................................................106
Annexe A .............................................................................................................................................114
Annexe B .............................................................................................................................................123
6
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Tableau
Tableau
Tableau
Tableau
Tableau
Tableau
Tableau
Tableau
Tableau
1
2
3
4
5
6
7
8
9
Posionnement de l’étude...................................................................................................... 9
Neurone biologique............................................................................................................... 43
Processus de l’ECD................................................................................................................ 48
La systémique des données.............................................................................................. 52
Partition courante Si ............................................................................................................. 69
Liste des partitions générées par le regroupement par paires ........................ 70
Eclatement du 1er regroupement avec les trois variables.................................. 70
Eclatement du 2ème regroupement avec les trois variables............................... 71
Eclatement du 3ème regroupement avec les trois variables............................... 71
Eclatement du sommet S1 avec les trois variables................................................ 72
Eclatement du sommet S2 avec les trois variables................................................ 72
Eclatement du sommet S3 avec les trois variables................................................ 72
Problématique.......................................................................................................................... 78
Schéma générale de la démarche proposée et la démarche classique........ 79
Architacture globale de la démarche proposée ....................................................... 80
Schéma de données ............................................................................................................. 82
Diagramme de classes sans ASA.................................................................................... 83
Diagramme de classes avec ArgoUML ......................................................................... 84
Schéma des opérations de préparation de données ............................................. 88
Diagramme de classes après ASA ................................................................................. 90
Diagramme de classes avant ASA ................................................................................. 91
Diagramme de classes après ASA ................................................................................. 91
Fenêtre principale de l’atelier........................................................................................... 94
Étapes de préparation de données................................................................................ 95
Module SIPINA ........................................................................................................................ 96
Création et connexion à la base de données............................................................ 97
Lancement du module ARGOUML .................................................................................. 98
Fenêtre principale du module ArgoUML ...................................................................... 99
Organigramme Générale .................................................................................................. 100
Table Individus/Variables ................................................................................................ 50
Exemple d’une table de données ................................................................................. 50
Descriptif de table Carte .................................................................................................. 86
Descriptif de table Client.................................................................................................. 86
Extrait de la Table Client tiré de la base de données......................................... 86
Extrait de la Table Carte tiré de la base de données.......................................... 87
Table obtenue par Sélection........................................................................................... 87
Table récapitulative des transformations de données ....................................... 88
Extrait de la table finale ................................................................................................... 89
3
UML (Unified Modeling Language) est un langage de modélisation unifié reconnu actuellement
par toute la communauté des chercheurs dans le domaine objet. Cependant un certain nombre de risques
peuvent survenir en raison de son inadéquation technique et fonctionnelle du système par rapport aux
besoins préalablement définis dans le cahier des charges.
Lorsque l’expression des besoins part comme il se doit d’une action, elle comporte naturellement
la description du processus. Toute action se ramène, en effet, à un processus selon lequel, partant d’une
situation initiale et par l’application de certaines ressources, on aboutit à un résultat.
La modélisation se construit forcément par étapes successives de plus en plus détaillées. Il est, par
conséquent, impossible de produire un modèle représentant quelques milliers de lignes de code sans
passer par les phases d’avancement, qui permettent d’organiser et d’exploiter judicieusement le volume
d’informations collectées d’où l’intégration de la fouille de données.
Contexte du mémoire
Dans ce mémoire, nous étudions la démarche UML, qui intègre le processus de fouille de
données, dans la phase préliminaire, de façon itérative de la modélisation objet et sa mise en
uvre dans
une plate-forme assez riche. Ainsi, nous sommes concernés par les technologies liées à notre plate-forme
UML et au processus de l’extraction de connaissances à partir de données.
Démarches UML
Afin de répondre aux besoins des développeurs, toujours de plus en plus nombreux, laborieux et
consommateurs de ressources, différents paradigmes de programmation ont vu le jour. Les auteurs
d’UML préconisent trois démarches de développement logiciel : centrée architecture, pilotée par les
besoins d’utilisateurs, incrémentale et itérative souvent confondues.
4
Démarche de la recherche et contribution
Nous avons choisi comme exemples usuels d’application : la gestion de la pharmacie, la gestion
aéronautiques. Il nous semble suffisamment illustratif pour permettre de discuter la démarche proposée
dans le contexte du développement d’applications sur une plate-forme connue.
La réalisation de cette expérimentation basée sur l’approche UML exige dans un premier temps,
une méthodologie, et dans un second temps, une architecture type permettant de mieux répondre aux
changements que subissent ces modèles. Parmi les différentes approches utilisées en UML, se basant sur
le diagramme de classes, nous utilisons et proposons une extension de la démarche guidée par l’utilisateur
[BOOC 00]. Notre proposition diffère de cette dernière par le fait de la distinction explicite entre
l’analyse de besoins et la fouille de données. Les contributions de ce mémoire sont les suivantes :
• L’étude de la modélisation UML dans le contexte de la démarche guidée par l’utilisateur à travers
l’étude de cas « gestion de la pharmacie ».
• Une méthodologie pour mettre en oeuvre la démarche guidée par l’expérience. Dans cette méthodologie,
l’étude est divisée en deux étapes : la spécification des besoins et la fouille de données.
• Une conception et une implémentation d’un atelier permettant d’une part, de réaliser les étapes de
préparation de données (la sélection, le nettoyage, …) et, d’autre part, de générer le graphe d’induction
correspondant aux tables traitées à partir de cette préparation de données.
Organisation de ce mémoire
Le premier chapitre pose la problématique en faisant une projection sur les deux axes de
recherches l’ECD et les démarches de modélisation UML, les sujets abordés dans ce mémoire nous
incitent à présenter un bilan sur les travaux faits autour d’UML et de l’apprentissage automatique. Nous
présentons les travaux conçus autour d’UML, des outils et des technologies développés pour cette fin, de
l’apprentissage automatique, et de leurs domaines.
Le deuxième chapitre présente un aperçu sur UML et les démarches pour la modélisation orientée
objet. Il se focalise sur les démarches recommandées par les auteurs d’UML ainsi que le langage OCL
(quelques notions de base). Nous présentons une étude de cas qui va nous aider à illustrer notre démarche
5
pour la correction des modèles. Nous présentons également les modèles indépendants de plates-formes et
les plates-formes cibles choisies pour réaliser cette étude de cas.
Au troisième chapitre, nous abordons l’apprentissage automatique, ses techniques et ses
approches. Nous justifions notre choix sur les arbres de décision en particulier l’algorithme SIPINA en
illustrant ses étapes, ses avantages et ses applications.
Le quatrième chapitre concerne la description de la démarche que nous avons proposée, la
démarche UML guidée par apprentissage automatique. Nous présentons le schéma général pour
l’expérimentation de cette démarche et ensuite nous détaillons le mode de fonctionnement de chacun des
étapes de manière progressive. Ce chapitre est divisé en sous-sections, qui décrivent l’application
principale que nous avons développée pour illustrer notre démarche : la gestion de pharmacie,….. Puis,
nous concluons par une analyse des propriétés de notre démarche et une présentation des résultats
obtenus.
Le chapitre cinq est consacré à la présentation des différents modules qui coopèrent pour
l'utilisation de la démarche UML guidée par apprentissage automatique: le module de prétraitement de
données, le module d'apprentissage symbolique automatique, le module de dessin et de vérification des
diagrammes de classes.
En conclusion, nous établissons un bilan de nos travaux en synthétisant la problématique étudiée,
la contribution fournie, ses limitations, ainsi que leurs perspectives.
6
7
1
Introduction
Les entreprises se sont accoutumées à manipuler des volumes toujours plus importants de données
sous la contrainte des optimisations qu’elles doivent sans cesse accomplir pour leur survie.
Progressivement, elles prennent conscience qu’au delà de l’usage courant que chacun fait de ses données,
celles-ci renferment également des notions invisibles à l’oeil nu. Le problème se placerait davantage au
niveau de l’interprétation de ces données qu’au niveau de leur récolte. Cette interprétation sous-entend
une extraction d’information. Nous n’avons pas à priori une bonne connaissance des données, que nous
cherchons à étudier et à exploiter, et la fouille de données doit donc nous permettre d’extraire des
informations pertinentes [ZIGH 00].
La fouille de données (datamining) est apparue au début des années 90 et elle peut se définir
comme la conjonction des recherches des bases de données. La principale raison du succès réside dans le
fait que, les créateurs du domaine de fouille de données ont su prendre en considération les problèmes des
industriels. Cela a permis de construire rapidement plusieurs modèles explicatifs des données qu’on peut
vérifier et sélectionner le modèle optimal relevant des compétences de l’expert [REMI 00]. Le datamining
consiste en la réalisation d’un système de collecte ou de fabrication de données lorsque celles-ci
n’existent pas. Plus souvent il s’agit simplement d’élaborer quelques requêtes dans des bases de données,
de concentrer et mettre en forme ces données. Ensuite, l’étape qui met en jeu le coeur du datamining dans
l’optique par exemple de déterminer des relations, de réaliser des prédictions, de faire émerger une ou
plusieurs classifications...
Il reste enfin à exploiter ces découvertes par le développement de traitements informatiques qui
automatisent la collecte de données en flux continu, qui appliquent les modèles déterminés à l’étape
précédente et restituent les résultats opérationnels à un agent informatique ou humain. Les traitements
informatiques sont parfois chargés d’introduire une boucle réactive pour automatiser la mise à jour du
modèle dans son évolution lente.
La mise en
uvre d’un processus industriel demande une analyse des besoins complète et
l’approche UML [CHAR 99] est considérée comme un processus pertinent pour la modélisation des
entités du domaine étudié, en assurant une meilleure organisation de la base de données.
8
2
Positionnement
2.1 Présentation générale
La figure 1 suivante montre une représentation générale de la démarche proposée.
UML
ECD
Vers l’intégration de l’ECD dans la démarche UML
L’exploitation maximale des données
Figure 1
Positionnement de l’étude
Notre problématique générale est de fournir une base de données assez riche à un opérateur
confronté à une modélisation d’un système complexe et de taille importante. Il s’agit donc d’extraire du
domaine d’application des données qui permettent la mise au point d’un modèle plus représentatif des
données traitées.
2.2 Objectifs
La modélisation est une activité importante de nombreux domaines de l’activité humaine que ce
soit en science ou en ingénierie. Réaliser un modèle est en effet nécessaire pour comprendre et représenter
un domaine ou pour communiquer sur un domaine. Un modèle peut être plus ou moins formalisé, être
écrit dans un langage spécifique ou au contraire dans un langage usuel. Le modèle peut être lui-même une
fin en soi ou peut être au contraire un artefact intermédiaire pour effectuer d’autres actions ultérieures
fondées sur ce modèle.
9
En sciences et technologies de l’information et de la communication, la modélisation est une
activité cruciale de l’étape d’analyse du processus de développement d’un produit logiciel. Elle a pris
depuis ces cinq à dix dernières années une part importante des cursus informatiques universitaires à
finalité professionnelle, surtout depuis l’avènement du langage de modélisation orienté objet UML et des
approches par modèles (MDA) standardisés par l’OMG qui en découlent.
La réalisation du modèle doit progresser par étapes caractérisées chacune par la confection d’un
diagramme. La démarche procédant par enrichissement progressif selon un ordre « top down ». Il ne
convient pas de bousculer l’ordre des étapes : il ne faut pas se lancer dans la modélisation proprement dite
sans disposer de l’expression de besoin, ni documenter les cas d’utilisation avant d’avoir produit le
diagramme d’activité etc. Chaque étape de la démarche doit être réalisée entièrement avant que l’on ne
passe à la suivante : l’une des erreurs les plus courantes en modélisation est de s’engouffrer de façon
précoce dans des travaux détaillés qu’il faudra réviser par la suite.
Toute modélisation informatique doit partir d’une expression de besoin écrite, claire, validée par
les responsables. Elle servira de référence tout au long de la réalisation du projet. La première formulation
de l’expression de besoin est souvent vague et incomplète.
Une enquête a été réalisée [DOMI 04] sous forme de questionnaire comportant des questions où
l’utilisation d’UML faisait partie des rubriques classées.
L’emploi d’UML est jugé sans objet par 26 % des répondants. UML est surtout utilisé pour la
modélisation des processus métier lors des phases d’analyse et de conception, 25 % des entreprises
l’utilisent aussi pour la cartographie du Système Informatique, 17 % l’utilisent pour l’expression des
besoins, 52 % pour l’analyse fonctionnelle (spécifications générales), 22 % pour la définition du cahier
des charges.
Comme conclusions de cette enquête, les entreprises mettent en place, dans leurs divers métiers,
des équipes composées d’architectes fonctionnels et de spécificateurs qui jouent, en s’appuyant sur des
experts métier, le rôle d’un traducteur dans les phases amonts d’analyse et de spécification. Certaines
entreprises estiment toutefois qu’UML est une affaire de spécialistes et que les équipes métier n’ont pas
vocation à s’impliquer sur des aspects jugés trop techniques du développement des systèmes.
10
Le langage UML est un langage de modélisation généraliste, de portée large, et qui à l’état "brut"
est d’abord difficile. Il propose un ensemble d’éléments de modélisation ainsi que des diagrammes, sans
définir de modalités d’utilisation précises.
Dans ces phases préliminaires, un enjeu majeur consiste à utiliser des représentations permettant
un dialogue entre les parties impliquées comme les utilisateurs, les analystes, les responsables
hiérarchiques et les experts du domaine [DESF 04].
L’emploi exagéré de techniques de modélisation comme UML constitue un obstacle à la
compréhension pour des intervenants, et va à l’encontre de leur implication dans la modélisation ou dans
leur travail. Par contre, l’absence d’une méthode rigoureuse de représentation empêchera la collecte d’une
information exhaustive, précise, et cohérente, que l’on peut abstraire ou détailler selon les niveaux de
dialogue.
Le but de la modélisation des systèmes (physique, biologique) ou de données complexes (langage
naturel) peut être soit un diagnostic ou plus généralement de l’extraction de l’information pertinente
[DAVO 01]. Mais c’est en fait l’individu qui applique son intelligence pour apporter une signification et
une pertinence à l’information pour agir, transformant ainsi l’information en connaissance. Connaissance
et information sont deux notions souvent confondues dans la perspective de l’ECD [KODR 99],
l’information n’étant qu’un élément de connaissance susceptible d’être codé, mémorisé et traité. Le
processus d’extraction des connaissances comprend, quelque soit la matière étudiée, un certain nombre
d’étapes [CORN 04], des "données brutes" stockées dans la base à l’extraction d’arbres de décision, de
règles ou de représentations spatiales des données.
Mais, la démarche UML est appliquée sur l’existant des données repérées. En raison de la
complexité croissante des systèmes, l’existant ne produit pas un modèle persistant, complet et valide. Il a
été de ce fait nécessaire de préciser l’intégration de la fouille de données [MOUL 97].
L’approche proposée constitue une contribution d’un intérêt avéré pour le monde industriel. Elle
constituera en effet un moyen d’automatiser la recherche, la capture et l’extraction d’informations dans
les grandes masses de données dans lesquels sont des données utiles mais difficiles d’accès [BOUD 05].
11
3
Travaux connexes
Nous allons tout d’abord présenter les travaux faits sur l’ECD en essayant d’affranchir tous les
domaines (que ce soit scientifiques ou industriels) et en cherchant l’information utile cachée pour une
nouvelle interprétation et un nouvel usage, et quelques travaux faits sur UML dont la plupart tendent à
mieux exploiter ses propres outils et les innover dans des environnements consistants pour la
modélisation.
3.1 Apprentissage Automatique
Nous allons illustrer quelques travaux réalisés, parmi les plus récents. Ils ne doivent pas toutefois
masquer d’autres qui sont tout aussi importants selon le domaine sur lequel on travaille [BOUD 03]. Les
travaux décrits ci-après ne constitue pas une liste exhaustive, et montrent que les résultats perfectibles.
Pour faire de la fouille de données sur de grandes bases, une des voies de recherche consiste à
intégrer les méthodes de fouille de données au sein des Systèmes de Gestion de Bases de Données
(SGBD) [CHAU 98]. Cette piste de recherche est conjointement liée à l’avènement des entrepôts de
données et de l’analyse en ligne (OLAP) plus particulièrement [CODD 93]. En effet, OLAP est une
première étape en matière d’intégration de processus d’analyse au sein même des SGBD.
D’autre part, d’autres travaux de recherche ont concerné l’intégration du processus d’extraction de
règles d’association dans les SGBD [GUIS 96], [SARA 98]. Par ailleurs, nous pourrions penser que
certains éditeurs de SGBD semblent aller dans le sens d’une intégration des méthodes de fouille de
données dans les SGBD. Cependant, cette intégration prend la forme d’une boîte noire dans laquelle la
fouille de données est faite aux moyens d’API ("Application Programming Interface") [ZIGH 00] et
d’extensions du langage SQL.
§
Dans [FAVR 03], il s’agit de faire de la fouille de données en utilisant uniquement les
concepts bases de données qui sont fournis par le SGBD (table, vue, procédure stockée, index, ...). Et plus
particulièrement le concept d’index bitmap, comme technique d’optimisation d’accès utilisée dans les
SGBD.
12
§
Les mesures de densités des roches constituent un élément vital, pour l’estimation des
réserves de pétrole dans les gisements, vers l’apprentissage d’un nouvel outil de diagnostic des gisements
de pétrole [DREY 04]. À partir de ces mesures, les analystes peuvent estimer de manière précise la
porosité des roches, d’où ils peuvent ensuite déduire les volumes de pétrole contenus dans les réserves.
L’objectif est de développer des algorithmes originaux, mettant notamment en oeuvre des techniques
d’apprentissage (réseaux de neurones, ...), qui permettent d’obtenir des estimations aussi précises que
possible de la densité de la formation rocheuse, robustes vis-à-vis de toutes les perturbations introduites
par l’environnement.
§
L’aide à la découverte de médicaments constitue un domaine de recherches très actif
[DUPR 04], car c’est un enjeu économique majeur dans le domaine de la santé. Une étude d’un nouvel
outil d’aide à la découverte de médicaments par modélisation et apprentissage. Dans ce cadre, ils ont
proposé une méthode originale de prédiction de propriétés pharmacologiques de molécules. La méthode
comprend essentiellement deux ingrédients : une méthode nouvelle qui permet l’apprentissage de
modèles dont les variables possèdent une structure de graphes, alors que les techniques habituelles
reposent sur des structures vectorielles; et une méthode de détermination du contexte.
§
Méthodes d’apprentissage automatique pour la modélisation de l’élève en algèbre par
David Renaudie [DAV 05]. La conception d’EIAH (Environnements Informatiques d’Apprentissage
Humain) s’adaptant aux difficultés des élèves, nécessite le développement de mécanismes automatiques
capables de diagnostiquer leurs connaissances à partir de l’observation de leur activité. Une base de
données a été constituée, à partir de traces de comportements d’élèves résolvant des exercices d’algèbre.
Ce travail consiste à extraire automatiquement des régularités comportementales de cette base, dont le but
d’aider à la conception d’un tuteur artificiel. Pour cela, l’utilisation des méthodes d’apprentissage
automatique permet de détecter des similarités dans les données, et propose deux approches de
modélisation complémentaires. Des groupes d’élèves ayant des comportements homogènes sont identifiés
pour un exercice donné, à l’aide d’un algorithme de classification non supervisée.
§
L’axe APRIME [MATE 01] s’intéresse aux mécanismes d’apprentissage automatique
susceptibles d’être mis en uvre dans des processus de reconnaissance des formes et de prise de décision.
Les sujets d’étude concernent à la fois des techniques d’apprentissage symbolique et numérique. Les
principes algorithmiques mis en oeuvre reposent sur des modèles statistiques ou probabilistes, des
13
modèles géométriques exploitant des distances, des modèles à base de règles ainsi que sur des modèles de
fusion de critères pour l’intégration des composantes numériques et symboliques.
§
Les recherches sur les techniques d’apprentissage se poursuivent à la fois selon les
approches connexionniste et symbolique [NEDE 00]. Pour l’approche connexionniste, les travaux
réalisés concernent la détection, l’extraction et la sélection des informations pertinentes dans des grandes
bases de données. Pour l’approche symbolique, les travaux concernent l’influence de la représentation et
du contenu en information ainsi que de l’incomplétude des données dans les situations inductives.
3.2 UML
Avant d’aborder les différents travaux qui ont été faits autour d’UML, il est important et judicieux
de préciser le rôle central et fondamental de la modélisation objet tout au long du développement d’une
solution logicielle.
Le recours à la modélisation est depuis longtemps une pratique indispensable au développement,
car un modèle est prévu pour anticiper les résultats du développement. Un modèle est en effet une
abstraction du résultat, dont le but est de documenter, de prévoir, d’étudier, de collecter ou d’estimer les
informations d’un système.
Associé au processus de développement, un modèle représente la vue sur une spécification ou sur
une solution de système, pris à un niveau de détail pertinent pour exprimer ou concevoir la cible de
l’étape en cours.
Le modèle sert donc des objectifs différents suivant l’étape de développement et sera construit
avec des points de vue de plus en plus détaillés :
1. Dans les activités de capture des besoins, il convient premièrement de considérer le
système comme une boîte noire à part entière afin d’étudier sa place dans le système
métier plus global qu’est l’entreprise. On développe pour cela un modèle de niveau
contexte, afin de tracer précisément les frontières fonctionnelles du système ;
14
2. Dans les activités d’analyse, le modèle représente le système vu de l’intérieur. Il se
compose d’objets représentant une abstraction des concepts manipulés par les utilisateurs.
Le modèle comprend par ailleurs deux points de vue, la structure statique et le
comportement dynamique. Il s’agit de deux perspectives différentes qui aident à compléter
la compréhension du système à développer ;
3. dans les activités de conception, le modèle correspond aux concepts qui sont utilisés par
les outils, les langages ou les plates-formes de développement. Le modèle sert ici à étudier,
documenter, communiquer et anticiper une solution. Il est en effet toujours plus rentable de
découvrir une erreur de conception sur un modèle, que de le découvrir au bout de milliers
de lignes codées sans grands horizons. Pour la conception du déploiement enfin, le modèle
représente également les matériels et les logiciels à interconnecter.
La modélisation se construit forcément par étapes successives de plus en plus détaillées. Il est en
effet impossible de produire un modèle représentant quelques milliers de lignes de code sans passer par
les étapes d’avancement qui permettent d’organiser judicieusement le volume d’informations collectées.
Tout processus construit sur un modèle doit donc se doter d’une tactique d’avancement par
consolidation de chaque étape de construction du modèle. Un tel avancement est itératif, car il définit des
objectifs à atteindre suivant un découpage en niveaux de détail allant croissant par rapport au modèle de
développement. Chaque niveau d’abstraction du modèle s’inscrit dans une étape du processus et fixe un
objectif de description du modèle.
Pour la capture des besoins fonctionnels : Le niveau du contexte a pour objet de définir la frontière
fonctionnelle entre le système considéré comme une boîte noire et son environnement. Le niveau des cas
d’utilisation définit ensuite les activités attendues des différents utilisateurs par rapport au système
toujours envisagé comme une boîte noire.
Ce modèle permet de contrôler la bonne adéquation des besoins avec les utilisateurs, puisque que
UML a ouvert le terrain de l’unification en fusionnant les notations et en apportant précision et rigueur à
la définition des concepts introduits. L’introduction d’UML a apporté un élan sans précédent à la
technologie objet, puisqu’elle y propose un standard de niveau industriel. Il reste cependant à définir le
processus pour réellement capitaliser des règles dans le domaine du développement logiciel.
15
§
Définir un seul processus universel serait une grave erreur car la variété des systèmes et
des techniques ne le permet pas. Il est nécessaire de réussir la modélisation UML des phases amont à
l’aide des techniques de « pré-modélisation » [DESF 04].
§
Un bon nombre de risques proviennent de la inadéquation technique et fonctionnelle du
système aux besoins des utilisateurs. Les exigences des utilisateurs sont donc prioritairement traitées dans
les deux branches du processus 2TUP (2 Tracks Unified Process) en Y [ROQU 03], en considérant deux
types d’acteurs différents du système informatique: l’utilisateur consommateur des fonctions du système
et l’utilisateur exploitant le système. L’enjeu du processus en Y est donc de développer le point de vue
utilisateur et de construire la spécification puis la conception objet à partir des concepts maniés par les
acteurs du système. Les cas d’utilisation sont justement des outils construits pour définir les besoins,
développant le point de vue des utilisateurs.
Sur la branche gauche, pour la capture des besoins fonctionnels, les cas d’utilisation portent
uniquement sur la plus-value métier des fonctions du système. Chaque cas d’utilisation met en évidence
des classes d’analyse qui sont les concepts utilisés par l’utilisateur et des scénarios qui établissent les
comportements attendus du système. Sur la branche droite, pour la capture des besoins techniques, la
nature des cas d’utilisation a été quelque peu adaptée en fonction des plus-values opérationnelles du
système pour ses exploitants.
Chaque cas d’utilisation technique structure des spécifications d’architecture que l’on peut par la
suite décomposer par couche logicielle. Les cas d’utilisation techniques permettent de concevoir les
classes qui vont offrir une réponse aux contraintes opérationnelles du système. Les interactions entre ces
classes permettent par ailleurs d’étudier les échanges entre classes, de consolider et de vérifier la
conception des cas d’utilisation techniques.
Au travers des cas d’utilisation, le point de vue utilisateur a donc bien le rôle d’initiation souhaité
pour une conception. On note par ailleurs que l’orientation métier imposée par les cas d’utilisation de la
branche gauche renforce la plus-value apportée par le système et introduit une dimension d’analyse de la
valeur.
Le pilotage par les cas d’utilisation consiste justement à ordonner les cas d’utilisation par priorité,
de manière à organiser les itérations par valeur ajoutée. En phase de construction notamment, c’est une
16
bonne pratique d’inclure les cas d’utilisation les plus prioritaires en réalisatant les premières itérations,
puis de continuer par ordre de priorité. En apportant au plus tôt le maximum de valeur ajoutée au système,
le développement rentabilise plus rapidement, ce qui est encore une manière de réduire les risques.
Il paraît difficile d’envisager le processus 2TUP sans recourir à UML comme support. Certes, les
concepts présentés jusqu’à présent ne sont pas spécifiquement liés à une notation particulière.
§
D’UML à MDA [CLAV 04] (Model Driven Architecture, architecture dirigée par les
modèles). En passant par les méta-modèles vers la standardisation des modèles.
§
Les six impasses de la conception des processus vers une alternative à l’approche
fonctionnelle [VAUQ 04], de nombreuses entreprises s’engagent dans des chantiers pour représenter leurs
processus et les réformer. Il y a, en effet, beaucoup à attendre de ces efforts en vue de rendre les
organismes plus performants. Cependant, faute d’une réflexion fondamentale, une grande partie de ces
efforts ne produit pas tous les effets escomptés. La montagne, souvent, accouche d’une souris et les
améliorations restent à la marge.
§
Les perspectives d’utilisation de
la méthode UMM (UN/CEFACT
Modeling
Methodology) [DECO 01] abordée par EDIFRANCE, pour les échanges électroniques professionnels. Le
contexte introduit le scénario d’échanges électroniques professionnels selon l’architecture technique.
Cette architecture articule des processus négociés de coopération inter organisations entre les
systèmes d’information des entreprises concernées. UMM associe le formalisme UML pour la
représentation des processus d’affaires, et XML, format d’échanges pour les transactions commerciales.
UMM apparaît comme un sous-ensemble de la méthode RUP [KRUC 03] (Rational Unified
Process) assistée par des outils proposés par Rational. Après harmonisation des différentes perspectives
de modélisation, cette démarche de spécifications, sera accompagnée d’une démarche projet.
§
Le travail [CHAR 99], Accord/UML: la validation de lignes de produits à base de
composants, tente d’apporter des réponses à des problématiques générales d’amélioration des méthodes et
outils de développement, pour le temps réel embarqué. Ces dernières sont multiples, elles concernent en
17
particulier la place des modèles dans le cycle de développement, le lien entre les modèles et
l’implémentation, et la validation des choix de conception sur la base des modèles de l’application.
Le document d’analyse devra comporter une modélisation en utilisant UML (Description des cas
d’utilisations, modélisations des processus métier principaux avec des diagrammes d’interactions, un
modèle de classes préliminaires (classes/associations) pour ce qui concerne les classes persistantes.
Le dossier de conception de présentation de la solution s’effectue également avec UML. Afin de
se placer dans un contexte réel contractuel, le cahier de recette doit permettre de valider le modèle final en
conformité avec le cahier des charges. La recette doit faire la preuve de l’existence de toutes les fonctions
demandées et qu’elles font bien ce qui était demandé. Le cahier de recette est à fournir en fin de la phase
d’analyse.
§
L’enseignement de la modélisation informatique se fait habituellement avec des logiciels
commerciaux professionnels plus ou moins élaborés mais qui ne sont pas conçu initialement pour avoir
une finalité pédagogique. L’objectif de Dialects (DIALogues pour Expliquer des ConcepTS) [HAZA 05]
est dans un premier temps d’étudier l’activité de modélisation d’un étudiant afin d’en proposer un modèle
computationnel, puis dans un second temps de proposer, d’implémenter et de tester des outils
pédagogiques spécifiques (interactionnelles ou dialogiques) pour supporter l’activité de modélisation de
l’apprenant.
4
Conclusion
Dans ce chapitre, on a voulu positionner la problématique par rapport aux travaux faits sur les
deux axes que sont l’Apprentissage Automatique et la modélisation Orientée Objet UML pour pouvoir
atténuer les limites d’UML par la contribution de l’Apprentissage Automatique.
Si l’on résume en simplifiant à l’extrême le processus de développement logiciel comme étant une
traduction en langage machine d’idées exprimées en langage naturel, la modélisation est l’activité
essentielle qui consiste à passer d’une description informelle donnée dans un langage sémantiquement
riche à une description formelle ou semi-formelle dans le cas d’UML mais généralement dans un langage
dont le champ d’interprétation est plus restreint que le langage d’expression des besoins.
18
D’autre part, la modélisation est une activité itérative dans laquelle le modèle est obtenu par
raffinements successifs de modèles intermédiaires incomplets et/ou erronés. Lorsque le domaine n’est
pas trivial, le modèle UML ne peut pas être établi directement après une seule lecture de l’énoncé. Ceci
est confirmé par l’expérimentation en montrant l’utilisation les environnements de modélisation et les
nombreux allers-retours entre l’énoncé à modéliser et le modèle en cours.
Il se peut que les contraintes que l’on découvre lors de la réalisation de l’étape N de la démarche
obligent à réviser les résultats des étapes antérieures. Ainsi, alors que la démarche doit progresser sans
que l’on n’anticipe le travail à faire dans les étapes ultérieures, elle ne peut pas exclure les retours en
arrière.
Il faut d’abord réviser l’étape la plus en amont parmi celles qui sont à revoir, puis revenir vers
l’aval jusqu’à l’étape en cours. Un modèle bien fait facilite ces révisions : si la documentation est
correcte, si les outils facilitent la cohérence entre les diverses étapes, si le modèle est convenablement
modulaire, le travail nécessaire aux révisions reste raisonnable. Contrairement à ce que certains éditeurs
prétendent, il n’existe pas dans le cas général d’outil capable de guider l’apprenti pour choisir parmi des
méthodologies, déjouer les pièges et conduire l’analyse en fonction du besoin et des données.
Il est nécessaire d’associer plusieurs techniques informelles et formelles pour saisir les diverses
facettes d’un problème sans le dénaturer, puis pour le détailler dans un modèle central que l’on pourra
préciser et modifier jusqu’à l’implémentation. L’utilisation conjointe de ces diverses techniques permet
de s’adresser à des interlocuteurs qui diffèrent tant par la forme de leur intuition que par le niveau de
visibilité et de lecture des modèles.
Afin de se placer d’une manière informatique et méthodique, et pour procéder dans une démarche
bien définie, le chapitre prochain illustre les différentes démarches recommandées par les auteurs d’UML
dans une tentative de tirer profit pour la conception de solution à la problématique posée.
19
20
1
Introduction
Dans ce chapitre, nous allons présenter les différentes démarches proposées par les auteurs
d’UML. Mais avant tout, nous allons exposer quelques notions d’UML tels que les diagrammes et les
modèles. Le langage unifié de modélisation est un langage visuel pour la spécification, la construction et
la documentation des objets formant les systèmes. C'est un langage de modélisation d'usage général qui
peut être adopté avec les principales méthodes objet et composants, et qui peut être appliquée à tous les
domaines d'application (par exemple, santé, finances, télécommunication, aérospatiales) et plate-formes
d'exécution (par exemple, J2EE, NET).
2
UML : Développement orienté objet
Les caractéristiques de l’objet répondent invariablement par les avantages apportés qui sont la
stabilité de la modélisation par rapport aux entités du monde réel, la construction itérative facilitée par le
couplage faible entre composants et la possibilité de réutiliser des éléments de développement d’un autre
objet. Certains insistent également sur la simplicité du modèle qui ne fait appel qu’à cinq concepts
fondamentaux (les objets, les messages, les classes, l’héritage et le polymorphisme) pour exprimer de
manière uniforme l’analyse, la conception et la réalisation d’une application informatique. Tous ces
points sont parfaitement exacts, mais ils ne sont que la conséquence de la capacité fantastique
d’intégration de l’approche objet [MULL 04].
Le Langage de Modélisation Unifié (UML) est le résultat de la combinaison des trois principales
méthodes orientées objet : OOD, OMT et OOSE. Ses créateurs insistent tout particulièrement sur le fait
que la notation UML est un langage de modélisation objet et non pas une méthode objet [MULL 97].
2.1 Concepts de modélisation UML
La modélisation objet décompose les systèmes en objets collaborants, formés par des données et
des fonctions qui opèrent sur ces données. La notion de classe est utilisée pour saisir la structure et le
comportement des objets [POPI 00]. La partie des données d’une classe est définie par un ensemble
d’attributs et la partie fonctionnelle par un ensemble d’opérations, appelées méthodes.
21
Dans le domaine du temps réel, ces objets sont des modèles des composants tels que des capteurs, des
moteurs ou des interfaces de communication.
2.2 Modèles et notations en UML
La modélisation en UML met en jeu des diagrammes qui forment l’ensemble de vues du système.
Les relations entre les diagrammes suivent des règles précisées dans le méta-modèle de UML [OMG 99].
2.2.1
Diagrammes UML
La modélisation du système en UML est structurée autour de plusieurs diagrammes qui sont
utilisés aux différentes étapes du développement. UML définit neuf types de diagrammes [REGG 99] :
1. Les diagrammes de cas d’utilisation, qui décrivent la façon dont le système sera utilisé. Ils montrent les
relations entre les acteurs (ou agents externes au système à concevoir) et les cas d’utilisation du système.
2. Les diagrammes de séquence, qui montrent l’interaction entre plusieurs objets organisés dans le temps.
Cette interaction est un ensemble de messages échangés entre les objets pour effectuer une opération ou
obtenir un résultat.
3. Les diagrammes de collaboration, qui présentent l’interaction organisée autour des objets et de leurs
liaisons. A la différence des diagrammes de séquence, ils ne montrent pas le temps comme une dimension
séparée. Ces diagrammes, ainsi que les diagrammes de séquence, sont appelés diagrammes d’interaction.
4. Les diagrammes de classes, qui expriment de manière générale la structure statique d’un système, en
termes de classes et de relations entre ces classes.
5. Les diagrammes d’objets, qui sont des instances des diagrammes de classes, utilisés pour présenter un
contexte particulier du problème.
22
6. Les diagrammes d’états, qui montrent le comportement des classes. Ce sont des automates
hiérarchiques, permettant une certaine représentation du parallélisme.
7. Les diagrammes d’activités, qui sont des variantes des diagrammes d’états, organisés par rapport aux
actions (ou opérations). Ils sont utilisés pour représenter le comportement interne d’une méthode ou d’un
cas d’utilisation.
8. Les diagrammes de composants, qui sont utilisés pour modéliser les différents composants du système
et leurs relations. Ces composants peuvent être des modules, des sous-programmes, des tâches et des
sous-systèmes.
9. Les diagrammes de déploiement, qui montrent l’organisation des composants matériels et le
rattachement du logiciel aux dispositifs matériels.
L’utilisation exhaustive d’un des types de diagramme proposés en UML dépend de l’application
développée répondant aux préoccupations du concepteur. Dans notre cas, nous n’utiliserons pas les neufs
diagrammes proposés par UML 1.3, mais seulement quelques uns, en insistant particulièrement sur le
diagramme de classes, les autres seront montrés en annexe.
Cette limitation volontaire permet une réduction significative du temps d’apprentissage de la
modélisation avec UML, tout en restant largement suffisant pour la plupart des projets. Les avantages du
diagramme de classes sont :
- diagramme central du modèle du SI,
- montre les classes et leurs relations statiques,
- le plus riche en notations, équivalence avec le modèle E-A
- et les erreurs dans ce diagramme ont souvent un impact sur les autres diagrammes.
Ainsi, dans le développement d’un système temps réel, par exemple, les concepteurs mettront l’accent sur
les diagrammes des classes, les diagrammes d’interactions et les diagrammes d’états pour définir le
comportement du système.
23
2.2.2
Vues de modélisation
Les diagrammes décrits ci-dessus sont utilisés pour présenter les vues du système. La
modélisation en UML permet la description du système selon cinq vues différentes [BOOC 00] :
1. La vue logique, qui décrit les aspects statiques et dynamiques du système en termes de classes et
d’objets. Elle se concentre sur l’abstraction et l’encapsulation et met en jeu des objets et des classes, ainsi
que des collaborations et des interactions autour de ces objets. Cette vue est composée par des
diagrammes de classes, d’objets, de séquence, de collaboration et d’états.
2. La vue de réalisation, qui se préoccupe de l’organisation des modules dans l’environnement de
développement. Elle montre l’allocation des classes dans les modules, et l’allocation des modules dans les
sous-systèmes. Les sous-systèmes sont eux-mêmes organisés en niveaux hiérarchiques aux interfaces bien
définies. Cette vue traite les modules, les sous-programmes, les sous-systèmes et les tâches, dans des
diagrammes de composants.
3. La vue des processus, qui représente la décomposition en flots d’exécution (processus, fils
d’exécution et tâches), la synchronisation entre flots et l’allocation des objets et des classes au sein des
différents flots. Elle prend toute son importance dans des environnements multitâches. Elle manipule les
tâches, les fils d’exécution, les processus et les interactions, dans des diagrammes de séquence, de
collaboration et d’états.
4. La vue de déploiement, qui décrit les ressources matérielles et l’implantation du logiciel dans ces
ressources. Elle prend toute son importance lorsque le système est distribué. Cette vue se concentre sur
les n uds, les modules et les programmes principaux, dans des diagrammes de déploiement.
5. La vue des cas d’utilisation, qui unifie les quatre vues précédentes. Les cas d’utilisation
permettent d’identifier les interfaces critiques, ils forcent les concepteurs à se concentrer sur les
problèmes concrets et ils démontrent et valident les autres vues. Elle rend compte des acteurs, des cas
d’utilisation, des classes et des collaborations à l’aide de diagrammes de cas d’utilisation et de
diagrammes de séquence ou de collaboration.
24
2.2.3
Méta-modèle
Un méta-modèle est un modèle qui décrit d’autres modèles. Comme une méthode a des concepts
de modélisation et des notations, son méta-modèle a besoin de décrire les deux. Il définit comment les
concepts peuvent être connectés pour former des constructions complexes ainsi que les modèles qui
peuvent être élaborés avec la méthode.
Les différents concepts de UML ont été eux-mêmes modélisés avec UML. Cette modélisation
récursive, qui constitue le méta-modèle de UML, décrit de manière formelle les éléments de modélisation
ainsi que la syntaxe et la sémantique de la notation qui permet de les manipuler. Le méta-modèle de UML
devient, entre autres, l’outil vérificateur qui facilite l’identification des incohérences [REGG 99].
Le méta-modèle d'UML décrit de manière très précise tous les éléments de modélisation et la
sémantique de ces éléments (leur définition et le sens de leur utilisation).
2.3 Processus de développement itératif
La stratégie de la méthode consiste à définir ce qu’est le produit final désiré, avant de déterminer
comment le produire. Ensuite, le but du processus de définition de l’architecture est de prendre en compte
tous les besoins d’architecture et de faciliter les choix à faire lors de la conception. Cette démarche
permettra de fournir une conception acceptable du système.
Les étapes pour élaborer les spécifications complètes du système sont :
1. Créer le modèle des besoins pour recueillir les besoins fonctionnels et de contrôle du système.
2. Enrichir le modèle des besoins en ajoutant les traitements d’entrées et de sorties en utilisant le modèle
d’architecture.
3. Affecter le modèle des besoins enrichi aux entités physiques en accord avec la technologie choisie,
pour produire le modèle d’architecture.
Lors de la construction des différents modèles, la vérification de cohérence est le moyen pour
s’assurer que les composants des modèles sont liés entre eux de manière consistante.
25
3
Démarches
La notion de démarche est importante dans le sens qu’il n’y a pas de règle préétablie dans le
processus de modélisation : beaucoup d’étapes sont fortement conditionnées par l’intuition de l’ingénieur.
Selon les auteurs de UML, le processus de développement associé au langage de modélisation unifié doit
être : Piloté par les cas d’utilisation, Centré sur l’architecture, Itératif et incrémental [BOOC 00].
3.1 Cas d’utilisation
Le terme « cas d'utilisation » (use cases) a été popularisé par Jacobson [JACO 92] comme
étiquette pour la description plus ou moins formelle de la façon dont un acteur utilise un système. Depuis
l'introduction du concept, il y a eu beaucoup de définitions des cas d'utilisation, parmi lesquels celle de
Fowler [FOWL 97] qui a été adopté par Renardus [RENA 00]. Essentiellement, un cas d'utilisation est
une interaction typique entre un utilisateur et un système informatique. Un cas d'utilisation capture une
certaine accessible à l'utilisateur fonction. Un cas d'utilisation peut être petit ou grand.
Un cas
d'utilisation réalise un but discret pour l'utilisateur.
Dans la pratique en matière de technologie de la programmation, particulièrement le
développement des logiciels orienté objet. Par exemple, le formalisme des cas d'utilisation peut inclure la
représentation schématique en langage de modélisation unifiée (UML) [CHAR 99], l'utilisation des
« templates » pour décrire des cas d'utilisation, et l'accumulation des rapports et des liens entre les cas
d'utilisation.
Toutes les activités du cycle de vie, de la spécification de ce qui doit être fait jusqu’à la
maintenance, sont guidées par les cas d’utilisation. Cette propriété du cycle de vie rejoint les besoins
d’organisation et de planification du projet pour la prévention des erreurs.
En effet, l’analyse des besoins est exprimée par les cas d’utilisation. Ils aident l’utilisateur à
articuler ses besoins par la description des services qu’il attend du système sous la forme d’interactions
entre les acteurs et le système. Pendant la spécification, les objets qui appartiennent fondamentalement au
domaine de l’application sont identifiés, puis décrits de manière générale par leurs classes. Chaque cas
d’utilisation est réalisé par une collaboration entre les objets trouvés, qui n’est qu’un cas particulier des
collaborations potentielles.
26
Le début de la conception est marqué par l’introduction de considérations de réalisation dans les
modèles. Les cas d’utilisation délimitent la conception puisqu’ils spécifient ce que les mécanismes
doivent faire. Les scénarios des cas d’utilisation peuvent également servir de base pour la définition des
tests fonctionnels.
3.2 Architecture logicielle
L’architecture est conçue pour satisfaire les besoins exprimés par les cas d’utilisation, mais aussi
pour prendre en compte les évolutions et les contraintes de réalisation. Elle s’intéresse à la forme globale
de l’application, c’est-à-dire aux différents regroupements de classes et d’objets. Ainsi, elle offre une
vision globale de l’application à partir de vues différentes : la vue des cas d’utilisation, la vue logique, la
vue des processus, la vue de réalisation et la vue de déploiement.
3.3 Cycle de vie itératif et incrémental
L’ensemble du travail de développement est divisé en petites itérations, définies à partir du degré
d’importance des cas d’utilisation et de l’étude des risques. Dans le cycle de vie itératif, chaque itération
reproduit le cycle de vie en cascade, à petite échelle. Les phases traditionnelles sont couvertes
graduellement, itération après itération. Chaque itération comprend les activités suivantes:
•
La planification de l’itération, qui est élaborée en fonction des résultats de l’étude des risques.
•
L’analyse, qui étudie les cas d’utilisation et les scénarios à réaliser dans l’itération. Elle met à jour
les modèles de la spécification pour prendre en compte les nouvelles classes et associations
découvertes pendant l’analyse de l’itération.
•
La conception, qui se concentre sur les choix tactiques permettant la réalisation des mécanismes
alloués à l’itération. L’architecture subit les modifications nécessaires et les modèles de la
conception sont mis à jour. Les procédures de test sont définies parallèlement à la conception des
nouveaux mécanismes.
•
Le codage et les tests, qui débutent par la génération de la structure du code à partir des modèles de
conception. Le détail des opérations est rajouté par l’intégration du nouveau code avec le code
existant. Les procédures de test unitaire et d’intégration sont appliquées aux composants de
programmation.
27
•
L’évaluation des composants, qui est conduite par l’examen des résultats des tests. Ces résultats sont
évalués par rapport aux spécifications.
L’objectif de cette démarche est de mieux maîtriser le risque. Par opposition à l’approche
fonctionnelle qui préconisait un développement en une passe, le développement incrémental et itératif
rendu possible par les technologies objet permet de beaucoup mieux gérer le risque.
4
Sélection d’une méthode
Avant de se lancer dans la sélection d’une méthode, il est nécessaire de déterminer avec précision
ce que l’on attend d’elle. Dans le cas du développement du contrôleur de robot, par exemple, on peut
souligner trois objectifs [DAHM 04] :
• La recherche d’un modèle générique de contrôleur de robot.
• L’obtention d’un logiciel plus fiable qui conduit à l’amélioration des conditions de sécurité du site
expérimental.
• La possibilité de maintenir facilement ce logiciel pour pouvoir l’adapter à de nouvelles techniques
de commande et de génération des mouvements ainsi qu’à des techniques destinées à la surveillance et à
la planification.
Cette sélection impose le choix de critères d’évaluation en rapport avec les objectifs du travail
ainsi qu’une comparaison des méthodes appliquées.
5
Critères d’évaluation
Le choix des critères d’évaluation pour la sélection de la méthode permet la vérification des
caractéristiques liées à la qualité de l’architecture logicielle et à la qualité du processus de développement.
En effet, ces caractéristiques ont une incidence directe sur les propriétés de la sûreté de fonctionnement
du produit final. Ainsi, et sur la base des objectifs du travail, les sept critères suivants ont été sélectionnés
[PAQU 97]. Ils ont des incidences directes sur la maintenabilité et la fiabilité du contrôleur.
28
5.1 Qualité de l’architecture logicielle
Trois critères ont été retenus [KRUC 03] pour étudier la qualité de l’architecture logicielle : la
réutilisabilité, la modifiabilité et la traçabilité.
5.1.1
Réutilisabilité
La notion de réutilisabilité a été l’un des moteurs de l’évolution des méthodes de développement
logiciel. Elle consiste à pouvoir utiliser à nouveau dans un processus de développement tout ce qui est en
état de servir. Elle ne se limite pas uniquement à la réutilisation du code, mais aussi à la réutilisation
d’une spécification ou d’une conception. Les gains potentiels, lorsque l’on réutilise des produits abstraits,
comme les spécifications, sont bien supérieurs que ceux que l’on peut dégager lorsque l’on réutilise
simplement du code.
5.1.2
Modifiabilité
Cette notion recouvre la capacité, des modèles produits pendant les phases du cycle de
développement, de subir tout type de changement adaptatif ou évolutif. La modifiabilité a des effets
directs sur la maintenabilité, corrective ou perfective. De même, elle a des effets sur la fiabilité, car une
méthode qui facilite l’introduction de modifications dans le système réduit l’introduction de nouvelles
fautes.
5.1.3
Traçabilité
La traçabilité est la propriété qui permet de retrouver dans une phase du cycle de développement,
et de remonter jusqu’au besoin, les composants (objets, fonctions, etc.) identifiés au cours d’une autre
phase. Cette notion est fortement liée à la maintenabilité du produit car elle permet d’arriver aux sources
des défaillances de façon rapide. Elle est importante aussi pour la vérification de cohérence entre les
différents modèles construits pendant le développement du système.
5.2 Qualité du processus de développement
Quatre critères ont été sélectionnés [PAQU 97], [MULL 04] pour analyser la qualité du processus
de développement : le pouvoir de vérification, la compréhensibilité, la facilité d’utilisation et le pouvoir
d’expression.
29
5.2.1 Pouvoir de vérification
Les différentes phases nécessitent des techniques de vérification. Le pouvoir de vérification est
une caractéristique essentielle pour démontrer que le système créé répond au problème posé et qu’il
fonctionne correctement. La vérification dans le processus de développement du système est conduite
généralement par des méthodes d’analyse statique (preuve, analyse des propriétés) et dynamique (test
fonctionnel et structurel).
La vérification pendant l’utilisation du produit est aussi importante. En effet, si le contrôleur a la
capacité de surveiller le comportement du système, la vérification prend la forme d’auto diagnostic,
indiquant les erreurs générales et lançant une routine d’urgence si une erreur détectable a lieu (le blocage
d’un axe ou la perte d’une fonctionnalité du contrôleur).
5.2.2
Compréhensibilité
La compréhensibilité de la méthode, de ses notations et de ses modèles, joue un rôle très important
dans le processus de développement du système. Elle contribue à la testabilité et à la maintenabilité du
produit développé. En effet, une méthode dont les notations et les modèles sont faciles à comprendre
facilite le test et la maintenance du produit.
5.2.3
Facilité d’utilisation
Une méthode de développement doit fournir des outils qui, non seulement, facilitent le passage
entre les différentes phases du cycle de vie mais qui procurent, également, une clarté suffisante afin que la
fiabilité du produit ne soit pas diminuée et que les étapes de maintenance puissent être achevées avec
succès. Cette facilité d’utilisation est liée à l’assistance fournie par la méthode afin de conduire le
concepteur à travers le processus de développement pas à pas avec des aides, des règles et des principes.
5.2.4
Pouvoir d’expression
Le pouvoir d’expression d’une méthode concerne sa capacité à reproduire de façon précise les
besoins du client, à spécifier de façon exacte le comportement désiré du système et à concevoir et
implémenter correctement le système spécifié. Ce pouvoir est fondamental pour assurer la fiabilité du
30
produit développé, car il s’agit de la représentation des aspects dynamiques, fonctionnels et structuraux
du système, tels que le parallélisme, la hiérarchisation, la synchronisation, la communication, etc.
6
Aspects avancés en UML
UML est le standard pour décrire des applications objets. Cependant, malgré l’existence de
nombreux environnements de qualité et d’un soutien industriel indéfectible, UML souffre de lacunes
rendant délicate son utilisation dans le contexte des systèmes répartis et/ou embarqués :
• UML est un langage semi-formel approprié pour les aspects structurels d’un système mais il ne
permet pas d’en présenter les aspects dynamiques qui restent informellement décrits ;
• Il est reconnu qu’UML ne permet pas de décrire une architecture logicielle.
6.1 Aspects dynamiques
La sémantique d’UML décrit parfaitement la structure d’un système. Ce n’est pas le cas des
aspects dynamiques (ou comportementaux) qui sont exprimés aux moyens de différents diagrammes
(séquence, collaboration, activité, états) sans que la cohérence entre eux puisse être assurée.
Récemment, des groupes tels qu’UML [LEBL 04] ont proposés une sémantique rigoureuse pour la
version 2.0 d’UML (à l’aide du langage OCL [BODE 02] voir section 8) mais ces extensions n’abordent
toujours pas les aspects dynamiques.
L’utilisation de notations de haut niveau (par exemple, orientées objets) présente l’avantage de
fournir des mécanismes de composition et de structuration plus simples à manipuler et fournit une base
intéressante pour la traçabilité des informations dans le système.
D’autres notations, basées sur l’algèbre des processus par exemple : E-LOTOS, … ou sur des
langages d’assertions : Object-Z …, sont également utilisées pour détecter des incohérences et des
ambiguïtés dans les modèles UML au début du processus de développement [REGE 03].
31
Bien que la formalisation d’UML ne permette pas l’utilisation de méthodes de vérification
formelles, les outils correspondants requièrent une expérience importante, considérée comme prohibitive
pour la plupart des projets industriels. Il est dans ce cas souhaitable de cacher la complexité d’utilisation
de ces outils aux développeurs en l’encapsulant dans les services rendus.
6.2 Histoires des utilisateurs et Programmation extrême
Une innovation récente pour les cas d’utilisation est l’histoire de l’utilisateur (User Stories),
définie par les praticiens ou experts de Programmation Extrême (XP : eXtreme Programming).
Les histoires de l’utilisateur sont des phrases mal structurées écrites par le client, sans termes
techniques, pour définir ce dont le système proposé a besoin pour leur répondre. Ils se concentrent sur les
besoins et les avantages des utilisateurs.
En introduisant la méthode XP, ses créateurs voulaient en finir avec la dérive de délais,
l’annulation des projets, l’absence de la qualité, la mauvaise compréhension du métier du client et
l’impossibilité de suivre les changement. Elle peut être définie comme : « une méthode baseé sur des
pratiques qui sont autant de boutons de contrôle poussées au maximum » [BENA 01].
XP met en relief quatre valeurs prenant en considération à la fois les aspects humains et les
enjeux commerciaux des projets de développement d’applications.
1. Communication : l’absence de communication est certainement l’un des défauts les plus graves
qui mettent en péril un projet. Toutes les pratiques qui forcent à communiquer ont pour but de
permettre à chacun de se poser les bonnes questions et de partager l’information.
2. Simplicité : XP encourage l’orientation vers la solution la plus simple qui puisse satisfaire les
besoins du client.
3. Feedback : le retour est immédiat pour les développeurs aux tests unitaires. Un feedback
permanent est positif pour le client qui a une bonne vision du projet, peut détecter tout écart par
rapport au planning et à ses attentes de manière à les corriger rapidement.
4. Pour mener à bien un projet XP, le client doit avoir le courage de donner un ordre de priorité à ses
exigences, de reconnaître que certains de ses besoins ne sont pas toujours très clairs.
32
6.3 UML et la description d’architectures logicielles
UML n’est pas réellement adapté à la description d’architectures. Pour pallier à cela, on peut
utiliser des profils afin de lui donner les caractéristiques d’un ADL (Architecture Description Language)
mais une telle démarche limite la réutilisation qui est son point fort. C’est pourquoi cette approche est
inspirée du framework, qui fournit un standard ouvert dédié au développement d’applications réparties,
tout en étant compatible avec la notation UML.
Pour permettre le développement de logiciels certifiables (c’est-à-dire conformes à une norme de
référence pour un domaine d’application donné), l’ADL utilisé doit décrire non seulement la structure et
la sémantique de l’application, mais aussi les caractéristiques de son environnement d’exécution:
protocoles de communication, gestion de ressources, et algorithmes d’ordonnancement.
Néanmoins, construire une application dédiée à un exécutif cible n’est pas recommandé car cela
limite la portabilité de la solution proposée. Nous résolvons ce problème en intégrant le système dans des
composants externes définissant des gabarits de comportement ce qui permet de construire l’application
de manière plus générique.
L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP,
Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fédère plus de 850 acteurs du monde
informatique. Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre
applications orientées objet, développées sur des réseaux hétérogènes.
Les difficultés de mise en oeuvre d'une approche "réellement objet" ont engendré bien souvent des
déceptions, ce qui a longtemps constitué un obstacle important à l'essor des technologies objet. Beaucoup
ont cédé au leurre des langages de programmation orientés objet et oublié que le code n'est qu'un
"moyen". Le respect des concepts fondamentaux de l'approche objet prime sur la manière dont on les
implémente. Ne penser qu'à travers un langage de programmation objet est un mirage qui vous détourne
de l'essentiel. Pour sortir les technologies objet de cette impasse fatale, l’OMG [OMG 99] propose UML.
Une autre caractéristique importante d'UML, est qu'il cadre l'analyse. UML permet de représenter
un système selon différentes vues complémentaires : les diagrammes. Un diagramme UML est une
représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du modèle.
33
Chaque type de diagramme UML possède une structure (les types des éléments de modélisation
qui le composent sont prédéfinis) et véhicule une sémantique précise (il offre toujours la même vue d'un
système).
Combinés, les différents types de diagrammes UML offrent une vue complète des aspects
statiques et dynamiques d'un système. Les diagrammes permettent donc d'inspecter un modèle selon
différentes perspectives et guident l'utilisation des éléments de modélisation (les concepts objet), car ils
possèdent une structure.
6.4 UML : le chemin vers l’unification des processus
Grâce au principe d'élaboration des modèles, UML permet de mieux maîtriser la part d'inconnu et
d'incertitudes qui caractérisent les systèmes complexes. Mais cet aspect méthodologique d'UML ne doit
pas induire l’utilisateur en erreur.
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus
d'élaboration des modèles ! Qualifier UML de "méthode objet" n'est donc pas tout à fait approprié. Une
méthode propose aussi un processus, qui régit notamment l'enchaînement des activités de production
d'une entreprise. Or UML n'a pas été pensé pour régir les activités de l'entreprise.
Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais ce sujet a été
intentionnellement exclu des travaux de l'OMG [OMG 99]. Comment prendre en compte toutes les
organisations et cultures d'entreprises ? Un processus est adapté (donc très lié) au domaine d'activité de
l'entreprise; même s'il constitue un cadre général, il faut l'adapter au contexte de l'entreprise. Bref,
améliorer un processus est une discipline à part entière, c'est un objectif qui dépasse très largement le
cadre de l'OMG.
Une source fréquente de malentendus sur UML a pour origine la faculté d'UML de modéliser un
processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus ?
Un ensemble d'activités coordonnées et régulées, en partie ordonnées, dont le but est de créer un produit.
UML permet tout à fait de modéliser les activités d'un processus, de décrire le rôle des acteurs du
processus, la structure des éléments manipulés et produits, etc.
34
Une extension d'UML (« UML extension for business modeling ») propose d'ailleurs un certain
nombre de stéréotypes standards (extensions du méta-modèle) pour mieux décrire les processus.
Le RUP (« Rational Unified Process ») [KRUC 03], processus de développement « clé en main »,
proposé par Rational Software, est lui aussi modélisé (documenté) avec UML. Il offre un cadre
méthodologique générique qui repose sur UML et la suite d'outils Rational.
Plus récemment, VALtech propose le 2TUP ("2 Tracks Unified Process"), un processus unifié
(c’est-à-dire construit sur UML, itératif, centré sur l’architecture et conduit par les cas d’utilisation), qui
apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’informations des
entreprises, et la démarche de modélisation « Agile » (‘Agile Modeling’) pour passer des besoins
utilisateurs au code [ROQU 03]. L’axiome fondateur du 2TUP a été le constat que toute évolution
imposée au système d’information peut se décomposer et se traiter parallèlement, suivant un axe
fonctionnel et un axe technique.
A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du
système consiste à fusionner les résultats de ces deux branches du processus. Bien qu’un processus
universel soit une utopie, la capitalisation des meilleures pratiques, à travers une famille de processus
unifiés (tels que le RUP et le 2TUP), devient donc une réalité.
7
Le modèle UML obtenu est-il correct ?
Le modèle UML obtenu doit satisfaire les contraintes structurelles imposées par le méta-modèle
(typage, cardinalité des associations, etc.). Par manque de précision, le diagramme de classe ne permet
pas d'exprimer tout ce qui est défini dans la spécification informelle et ne suffit pas à assurer la correction
d’un modèle UML [REGG 99]. Il est en effet possible tout en respectant ces quelques restrictions de
construire des modèles manifestement aberrants. Si nous considérons ce diagramme des classes au niveau
«méta», c’est une réification des classes du méta-modèle UML.
Pour rejeter ces modèles aberrants, la description du méta-modèle UML dans [OMG 99] a été
complétée par des règles textuelles interdisant explicitement leur construction. Ces règles énoncent les
propriétés que doivent vérifier les éléments d’un modèle (classes, associations, états, etc.) et sont
parfois complexes. Aussi était-il nécessaire de définir un formalisme adapté à la rédaction et la
compréhension de ces contraintes, tout en fournissant une interprétation sans équivoque.
35
8
Présentation d’OCL
Le langage OCL (Object Constraint Language ) [OMG 99], [BODE 02] a été créé
spécialement pour répondre à ce besoin de formaliser des propriétés sur la structure des modèles
par la définition d’invariants sur les classes du méta-modèle [FLAK 01]. Un modèle légal sera donc un
modèle qui considéré comme un ensemble d’objets réifiant des éléments du méta-modèle UML vérifie
ces invariants [WARM 03].
Le méta-modèle UML étant un modèle UML, l’usage du langage OCL s’est rapidement étendu à
la définition d’invariants au niveau des modèles également, la définition de pré-conditions et postconditions des opérations, la spécification des gardes sur les transitions des diagrammes des états, etc.
Nous verrons par la suite que cet élargissement du domaine d’OCL pose quelques difficultés.
Il s’agit de faire profiter la communauté UML des avantages de la conception par contrats.
Nous allons présenter succinctement les caractéristiques du langage OCL. Les concepteurs du langage
OCL se sont attachés à fournir un langage simple à utiliser et aux constructions «intuitives». OCL dispose
de constructions qui permettent d’exprimer facilement une «navigation» dans les modèles UML.
D’ailleurs la RFP (Request for Proposal for OCL 2.0) encourage l’usage d’OCL en tant que langage de
requêtes sur les modèles.
8.1 Le paquet UML-OCL
Le langage OCL est fortement typé et sans effet de bord. Le langage consiste en un
ensemble de types et d’opérations prédéfinis, regroupés et documentés sous la forme d’un paquet UML
appelé UML-OCL.
Le concepteur d’un modèle UML est censé importer ce paquet dans son modèle pour disposer des
fonctionnalités d’OCL. Le paquet UML-OCL contient des types élémentaires tels les booléens, entiers,
réels et chaîne de caractères, ainsi que des types plus complexes tels les types énumérés ou les
collections.
Tous les types OCL sont des sous-types du type OclAny qui définit les propriétés communes à
tous les objets OCL [FLAK 01]. A ces types prédéfinis, viennent s’ajouter des types «importés» qui
correspondent aux classes, interfaces et type de données du modèle.
36
Tous les types OCL, qu’ils soient prédéfinis ou importés sont accessibles via une instance du
type
OCL
OclType.
Cet OclType permet un accès restreint au niveau de modélisation «méta»
supérieur.
8.2 Limitations et défauts d’OCL
À l’usage, le langage OCL révèle ses limitations. Si des raisons pratiques justifient l’introduction
d’extensions, avec par exemple la définition d’opérations supplémentaires dans le package UML-OCL,
ou encore le support du multi contexte, ou la transformation d’OCL en un véritable langage d’actions,
d’autres limitations s’avèrent plus gênantes car liées à l’expressivité du langage.
En particulier, le choix des concepteurs de mettre à plat les collections, c’est-à-dire que la
transformation automatique d’une collection de collections en une seule collection est gênante lors des
navigations successives des associations, car cela fait généralement perdre de l’information, en particulier
sur le typage. La réponse du groupe UML à la RFP OCL 2.0 tente de supprimer cette limitation fort
critiquée.
Certaines de ces limitations sont une conséquence de l’origine d’OCL, initialement prévu
uniquement pour la description de contraintes sur le méta-modèle UML. En effet, ce méta-modèle étant
un sous-ensemble de la notation UML, il n’exploite pas tous les concepts de cette dernière. Il n’y a pas de
types paramétrés, pas d’associations qualifiées au niveau du méta-modèle. C’est sans doute pour cette
raison que la gestion des types paramétrés «importés» d’un modèle UML est complètement ignorée par le
langage OCL. A ces limitations s’ajoute l’inconsistance de certains concepts. La sémantique n’est pas
toujours clairement définie en raison du manque de formalisme de la spécification. Ainsi, il est possible
en naviguant une association 0..1 d’obtenir des valeurs «non-définies», si la multiplicité du lien
réifiant cette association est 0.
8.3 Approches existantes : Méta-modèles UML et OCL intégrés
Notons que plusieurs méta-modèles ont déjà été proposés en réponse à la RFP for OCL 2.0. Les
reproches suivants ont été faite à ces propositions : ces méta-modèles fusionnent les classes d’UML avec
le typage d’OCL, qui sont pourtant deux systèmes différents. Or nous avons dit que les types paramétrés
d’UML ne sont pas gérés par OCL, que le mécanisme de surcharge ou de redéfinition en OCL diffère de
celui d’UML. Une opération UML peut renvoyer un nombre quelconque de résultats (paramètres in-out,
37
out, return), alors qu’une expression OCL est sans effet de bord et renvoie un seul résultat. Le langage
OCL se contente d’un système de type assez simple, fort éloigné des possibilités complexes offertes en
UML.
Enfin, les types prédéfinis OCL sont des types «mathématiques» (les entiers relatifs, par exemple)
exempts de toute contrainte d’implantation. Ce ne sont pas nécessairement les types de données utilisés
par le concepteur et il peut être utile de pouvoir définir précisément les correspondances.
Plus pragmatiquement, l’insertion d’un méta-modèle OCL dans le méta-modèle UML crée un
couplage entre ces méta-modèles qui n’est pas justifié : par exemple, les notions d’attributs,
d’associations, d’opérations sont spécifiques à UML et n’ont pas besoin d’être distinguées en OCL ou
seule la notion de propriété (avec une signature) importe. Les méta-modèles proposés sont donc
relativement compliqués [FLAK 01].
D’un autre côté, il est évident que cette approche favorise l’utilisation des classes, attributs et
opérations d’un modèle UML dans le contexte OCL.
9
Conclusion
Nous avons vu dans cette partie qu’UML n'impose pas de méthode de travail particulière, il peut
être intégré à n'importe quel processus de développement logiciel de manière transparente. UML est une
sorte de boîte à outils, qui permet d'améliorer progressivement nos méthodes de travail, tout en préservant
nos modes de fonctionnement. Nous pouvons à tout instant imposer notre emprunte en intégrant UML par
étapes dans un processus, de manière pragmatique.
La faculté d'UML se fondre dans le processus courant, tout en véhiculant une démarche
méthodologique, facilite son intégration et limite de nombreux risques (rejet des utilisateurs, coûts...).
Cela ne signifie donc pas révolutionner ses méthodes de travail, mais cela devrait être l’occasion de se
remettre en question, en s’inspirant des meilleures pratiques, par exemple, capitalisées à travers les
processus unifiés (RUP et 2TUP) ou d’autres, sinon imposée notre propre méthode de travail sans dévier
du contexte conventionné du monde informatique.
38
39
1
Introduction
En dehors de l'intelligence artificielle (IA), il existe de nombreuses approches de l'acquisition
automatique de connaissances: systèmes adaptatifs issus de l'automatique, inférence grammaticale en
reconnaissance des formes, inférences inductives fortement liées à l'informatique théorique, sans oublier
les méthodes numériques dont le connexionisme est la dernière incarnation.
2
Apprentissage automatique
L'apprentissage automatique dans le contexte informatique veut dire la capacité d'un logiciel
d'améliorer son comportement sans intervention directe de l'extérieur. Cela peut par exemple signifier la
modification de la base de règles ou l'apprentissage d'un réseau de neurones pour suivre des changements
dans un système physique. Il est souvent avantageux d'essayer d'extraire les règles utilisées par un expert
à partir d'exemples de situations de décision. On donne à l'expert un problème à résoudre et il donne la
(les) solution(s) correspondante(s), éventuellement avec un degré de certitude. Une autre possibilité est
d'utiliser des cas réels dont on connaît la solution. Dans ce cas l'expérience ne passe même pas par
l'expert, il est possible de l'entrer directement dans le système. Ces exemples sont alors fournis au système
qui modifie lui-même ses connaissances.
Il y a deux approches en apprentissage automatique. La première s'attache à découvrir les
processus mentaux mis en oeuvre dans la cognition puis à les simuler avec des machines. Elle est du
ressort de l'IA, branche des sciences cognitives. La seconde approche (celle qui nous concerne) est plus
pratique et ne cherche pas à imiter la cognition. Elle est du ressort du traitement automatique de
l'information et vise à construire des programmes qui extrapolent des connaissances à partir de données
fournies en entrée, et qui éventuellement modifient leur comportement en fonction de ces données.
Nous allons présenter un aperçu des différents outils d’apprentissage automatique, parmi lesquels
on distingue deux axes principaux de recherche : les approches symboliques et les approches
connexionnistes (sub-symboliques). Nous allons tout d’abord proposer une brève introduction sur
l’importance et sur le rôle de ces algorithmes d’apprentissage automatique dans le domaine de l'IA.
Ensuite, nous
allons présenter plus
en détail les systèmes symbolique
et
les
systèmes
connexionniste.
40
2.1 Apprentissage connexionniste
Les réseaux connexionnistes sont des assemblages fortement connectés d'unités de calcul, les
neurones formels. Ces derniers ont pour origine un modèle du neurone biologique, dont ils ne retiennent
d'ailleurs qu'une vision fort simplifiée. Le neurone, comme toute cellule, est composé d'un corps (ou
soma), qui contient son noyau et où se déroulent les activités propres à sa vie cellulaire. Cependant, il est
aussi doté d'un axone et de dendrites, structures spécialisées dans la communication avec les autres
neurones [BISH 95].
Figure 12
Cette
Positionnement de l’étude
communication entre cellules nerveuses s'effectue via des impulsions nerveuses. Les
impulsions sont générées à l'extrémité somatique de l'axone et vont vers les terminaisons. Là, elles
affecteront tous les neurones reliés au neurone générateur, par l'intermédiaire de jonctions entre les
terminaisons et les autres cellules. Cette jonction est appelée synapse.
Un réseau connexionniste est constitué par un graphe orienté et pondéré. Les noeuds de ce graphe
sont des automates simples nommés neurones formels ou tout simplement unités du réseau [ABDI 94].
Les unités sont dotées d'un état interne, que l'on appelle état d'activation. Les unités peuvent propager
son état d'activation aux autres unités du graphe en passant par des arcs pondérés appelés connexions,
liens synaptiques ou bien poids synaptiques. La règle qui détermine l'activation d'un neurone en fonction
de l'influence venue de ses entrées et de leurs poids respectifs s'appelle règle d'activation ou fonction
d'activation.
Les changements apportés aux valeurs des poids synaptiques ou dans la structure d'interconnexion
des unités du réseau sont responsables des changements de comportement d'activation de ce réseau, ce qui
lui permet d'apprendre un nouveau comportement.
41
Ainsi, le réseau est capable d'établir des associations entrée-sortie (stimulus et réponse) afin de
bien résoudre un problème. La méthode utilisée pour modifier le comportement d'un réseau s'appelle
règle d'apprentissage [TALE 06].
2.2 Apprentissage symbolique
Le concept "apprentissage symbolique automatique" dans ce contexte veut dire un apprentissage
d'avantage symbolique, c'est-à-dire un apprentissage qui fournit des règles que l'on peut exprimer en
utilisant la logique des prédicats. L'apprentissage symbolique utilise avant tout les méthodes de déduction
et d'induction. Déduction veut dire inférer des faits ou des règles plus spécifiques à partir de faits ou de
règles générales. Induction, par contre, signifie l'inférence de règles plus générales en utilisant des règles
et faits spécifiques. En apprentissage, on utilise le plus souvent l'induction.
Un problème avec ces méthodes est l'explosion combinatoire qui se produit de la même façon que
pour les systèmes à base de règles de production, mais le problème n'est pas aussi grave car les règles sont
gérées par l'algorithme d'apprentissage. L'apprentissage symbolique utilisé dans ce travail permet de
générer des arbres de décision pour déterminer la préférence entre deux choix comme dans la méthode
Electre [SKAL 84], ce qui permet de faire un tri entre tous les choix ou qui permet au moins un
classement des choix. L'apprentissage ne règle pas nécessairement le problème si deux choix sont
incomparables [BOUD 03].
La plupart des travaux ont été réalisés en apprentissage supervisé et ont engendré de nombreux
systèmes dont quelques uns sont couramment utilisés dans le monde industriel. L'un des exemples les
plus connus est celui des arbres de décisions qui prennent en entrée des données décrites par un ensemble
de descripteurs continus ou discrets et des classes impérativement discrètes.
Les descripteurs continus sont alors discrétisés par rapport aux classes et ces systèmes engendrent
des arbres de classement qui peuvent être interprétés comme une description en intention des classes, à
partir des arbres de décision, un ensemble de règles souvent plus compréhensibles pour l'expert [JERO
03].
Les méthodes symboliques sont basées sur des techniques d’Apprentissage Symbolique
Automatique (ASA). Elles assurent l’Extraction de Connaissances symboliques à partir de Données
42
(ECD) et l'utilisation de ces connaissances pour des traitements ultérieurs à savoir la Classification, le
Regroupement, l'Estimation et la Prédiction. Ces méthodes connaissent un grand essor avec le
développement des systèmes de fouille de données (Datamining).
La particularité des méthodes symboliques réside essentiellement dans la compréhensibilité et la
lisibilité des connaissances découvertes, ainsi que la nouveauté et la complémentarité de ces
connaissances par rapport à celles de l'expert humain.
L'Apprentissage Symbolique Automatique (ASA) s'est voulu l'héritier de toutes ces approches :
analyse de données, statistiques, intelligence artificielle, bases de données. Tout en se plaçant résolument
dans la problématique I.A. Si le domaine est jeune [CHAU 02], il n'en demeure pas moins qu'il a déjà
produit un ensemble de théories, de techniques, de mécanismes et de systèmes qui ont fait leurs preuves.
On commence même à faire la part des mythes et des potentialités réelles de ce domaine, et à mieux
savoir poser les problèmes.
Pour prendre la mesure de la vitalité de la discipline, soulignons la grande variété des modèles que
l'ASA a produit, parmi lesquels on peut citer l'apprentissage par punition/récompense, les formes
d'apprentissage rationnel ou empirique, déductif ou inductif, inventif ou découvreur.
Ainsi, l'approche ASA est multiple à bien des égards, et il apparaît difficile de la caractériser dans
sa globalité. Cependant, l'acquisition automatique des connaissances en ASA repose typiquement sur un
apprentissage symbolique, par opposition à un apprentissage numérique [TALE 06]. En outre, on a
régulièrement besoin de savoir formuler un concept général à partir d'exemples : le terme concept peut
désigner ici un objet de l'univers, une action impliquant des objets de cet univers, ou la pré-condition
d'une heuristique, voire une méta connaissance.
Soulignons
également
les
trois
principaux
types
de
questions
qui
se
posent
en
dénominateur commun en apprentissage symbolique ([KODR 86]) :
§
le regroupement ("clustering") : étant donnée un volume de connaissances, comment
découvrir des traits communs entre elles, de sorte qu'on puisse les regrouper en sous-groupes plus simples
43
et ayant une signification ? Il faut savoir que l'immense majorité des procédures de regroupement reste de
nature numérique.
§
la discrimination : étant donné un ensemble d'exemples de concepts, comment trouver une
méthode qui permette le plus efficacement possible de reconnaître chaque concept?
§
la généralisation : comment, à partir d'exemples concrets d'une situation ou d'une règle, en
déduire une formule assez générale pour décrire cette situation ou cette règle, et comment expliquer que
cette formule ait cette capacité de description ?
La première génération des théories modernes d'ASA a donné naissance aux méthodes
d'Apprentissage par Recherche d'Explications (Explanation-Based Learning), d'Apprentissage par
Détection de Similarités (Similarity-Based Learning) et d'Apprentissage par Analogie (Learning by
Analogy). Les chercheurs du domaine ont d'abord voulu perfectionner chacune de ces méthodes
séparément, puis ont pensé à les faire coopérer, eu égard à leur grande complémentarité : on s'est aperçu
qu'on avait parfois intérêt à combiner des mécanismes de déduction, d'abduction et d'induction pour
apprendre. En effet, quant la déduction est un mécanisme de raisonnement qui tend à dégager des
conséquences à partir de données, l'abduction permet de faire progresser un modèle en proposant de
nouveaux faits, et l'induction fait progresser le modèle en suggérant de nouvelles hypothèses et de
nouvelles heuristiques.
En effet, la communication entre agents peut être vue comme la base de l'enrichissement
de leurs connaissances mutuelles. Ainsi, au sein d'un réseau de communication où chacun met en jeu ses
attentes et ses compétences, un système interlocuteur peut devenir un système observateur et acteur au
sein d'une véritable communication multipartite : il sera amené à faire des découvertes pour mieux
s'adapter à cette communication, pour pouvoir en témoigner.
L'Apprentissage Symbolique Automatique est une discipline scientifique jeune, qui est apparue
dans les années soixante-quinze, et dont la première manifestation, le "First Machine Learning
Workshop" a eu lieu en 1980 à l'université de Carnegie –Mellon [CHER 98].
2.2.1
Naissance de l'ASA et état de l'art
Nous n'allons pas retracer de façon exhaustive les différents succès et les différents courants du
domaine. Il faut noter que les premiers essais en ASA datent d'avant cette époque de référence: ils
44
consistaient en une tentative de modélisation incrémentale, où la connaissance est quasiment nulle au
départ et
s'accroît progressivement. Dans les années soixante, une approche conduisait l'ASA à
l'acquisition de concepts et de connaissances structurées : le système DENDRAL, qui engendre des
règles d'explication à partir de données de spectrographie de masse en chimie organique, en est la
plus spectaculaire réussite.
Si la plupart des techniques d'ASA consignées dans ce synoptique ont fait leurs preuves, les
systèmes d'ASA demeurent tous très spécifiques, et il n'existe pas de Système Apprenti général, ni de
méthode simple et universelle de conception d'un tel système. Jusqu'à ces dernières années, la plupart des
recherches en ASA reposaient sur une approche inductive nécessitant un grand nombre d'exemples, et
visant à déterminer de façon empirique des points communs entre ces exemples : les méthodes
engendrées recherchaient les similarités entre les exemples sans utiliser la théorie du domaine. Aussi, leur
inconvénient essentiel était de ne pas produire d'explication de la généralisation obtenue [KODR 86].
Aussi depuis quelques années, plusieurs chercheurs ont, chacun à sa manière, imaginé et mis au
point des méthodes nouvelles, capables d'engendrer une généralisation justifiable à partir d'exemples:
ainsi, moyennant la connaissance de la théorie du domaine et une expression du concept auquel on
s'intéresse, on peut désormais engendrer une formulation du concept en fonction des connaissances
théoriques. Ces méthodes sont basées sur une recherche d'explication, l'explication étant alors la preuve
que l'exemple est bien un exemple positif du concept, et sur la généralisation de cette explication grâce à
une technique proche de la régression de buts.
Ce n'est que depuis peu qu'il existe une vue d'ensemble pertinente de ces méthodes : un algorithme
a été proposé fonctionnant quel que soit le domaine théorique, unifiant les approches des chercheurs en
généralisation par recherche d'explications, en répertoriant et en typant les problèmes ouverts. Pour
appliquer ces méthodes, on a besoin d'une théorie du domaine, d'une définition du concept à étudier, et
qu'on doit indiquer au système la forme de l'expression générale désirée.
Depuis 1985, on distingue l'Apprentissage par Détection de Similarités (Similarity Based Learning
SBL) de l'Apprentissage par Recherche d'Explications (Explanation Based Learning EBL).
La différence fondamentale entre les deux approches peut être exposée comme suit :
45
•
En SBL, on apprend en détectant des similitudes dans un ensemble d'exemples, et des
dissimilitudes entre les exemples et les contre-exemples;
•
En EBL, on apprend à partir d'explications dérivées de l'analyse, d'un exemple ou d'un contre-
exemple, du concept ou de la règle à apprendre, en particulier les algorithmes des arbres de décision,
tout d’abords, nous allons voir l’ECD et ses étapes.
2.2.2
Les étapes du processus de l’ECD
L’extraction d’informations originales, auparavant inconnues et potentiellement utiles, à partir de
données [FRAW 96]. Le processus d'extraction des connaissances comprend, un certain nombre d'étapes,
des données brutes stockées dans la base à l'extraction d'arbres de décision, de règles ou de
représentations spatiales des données. Les principales étapes de la chaîne de découverte des
connaissances sont schématiquement les suivantes :
Préparation des données
Acquisition
des
données
Sélection
Prétraitement
Nettoyage
Données
Cibles
Données
Sectionnées
Transformation
Fouille de
données
Information
Reconstruction et
Extraction de paramètres
Données
Prétraitées
Données
Transformées
Interprétation/
évaluation
Information
Extraite
Figure 4: le processus de l'ECD
2.2.2.1
Prétraitement des données
La bonne préparation de données est l’étape préalable clef dans un processus KDD (Knowledge
Discovery in Databases). La préparation des données prend environ 60 à 80 % du temps consacré au
processus d’extraction de données. Cette phase de prétraitement joue un rôle fondamental dans
46
l’extraction de connaissances interprétables, utiles et exploitables. Plusieurs techniques de préparation de
données existent et nécessitent une préparation et une organisation particulière des données.
§
La sélection
La sélection des données consiste dans un premier temps à obtenir des données en accord avec les
objectifs que l'on s'impose. Ces données proviennent le plus souvent de bases de production ou
d'entrepôts de données.
Tous les algorithmes de fouille de données ne peuvent opérer que sur des données tabulaires
(format individus/variables). N’importe quel ensemble de données non structuré ou complexe n’est pas
analysable par les méthodes dites de datamining. Les objets sur lesquels on peut appliquer les méthodes
de datamining sont appelés tableaux de données. Des objets plus complexes peuvent apparaître en gestion
des données tels les hyper cubes de données mais en définitive, les méthodes mathématiques ne
s’appliquent bien qu’à des situations de tableaux de données. Il faudra alors savoir extraire d’une situation
analysable exprimable en termes de tableaux de données.
Un tableau de données est un tableau à double entrée, consignant des nombres mettant en jeu deux
ensembles d’objets : Les lignes du tableau correspondent aux individus (ou objet) ; les colonnes du
tableau correspondent aux variables (ou attribut). Les tableaux de données se présentent ainsi (Tableau 1).
Tableau 1
§
Table Individus/Variables
Les variables
On distingue schématiquement deux types de variables :
• Variables quantitatives : une variables quantitative prend des valeurs pour les quelles des
opérations arithmétiques telles que différence et moyenne aient un sens.
47
• Variables qualitatives : une variables qualitative prend des valeurs symboliques qui désigne en fait
des catégories.
•
Les individus
L’individu est un objet qui appartient à une population de référence (définie par les variables dites
de contrôle). Si au lieu d’étudier toute la population, on n’en examine qu’une partie on dit qu’on étudie un
échantillon et si cet échantillon est un modèle réduit de la population entière, on dit qu’on étudie un
échantillon représentatif. Exemple de tableau IND/VAR: Les données dont nous avons besoin dans une
étude de datamining, ont normalement la forme d’un tableau (où d’une matrice):
Tableau 2
résultat du test
sexe
nationalité
Étudiant 1
M
français
8
oui
Étudiant 2
F
français
3
non
Étudiant 3
F
anglais
7
non
Étudiant 4
F
allemand
7
oui
Étudiant 5
M
français
9
oui
préalable (point)
réussi
Exemple d’une table de données
Dans chaque rangée du tableau se trouvent les données d’une entité. Une entité peut être une
personne (un individu), mais aussi une organisation, un objet, un événement, etc. La première colonne
contient les noms ou identifiants des entités. Dans les autres colonnes se trouvent leurs caractéristiques.
Nous appelons ces caractéristiques les variables. Dans un état idéal, pour toutes les entités les valeurs de
toutes les variables sont contenues dans le tableau.
À l’intérieur du tableau il y a des types de valeurs différents. Il y a des valeurs numériques (Les
résultats du test préalable) mais aussi des valeurs catégoriques (les nationalités et le contenu de la colonne
« réussi »). Les résultats du test sont numériques et discrets.
48
Nous appelons une variable numérique discrète, si ses valeurs possibles sont prédéfinies. Si ce
n’est pas le cas, la variable s’appelle continue. Beaucoup de variables continues sont traitées en pratique
comme des variables discrètes. Il se peut que les valeurs soient mesurées d’une manière grossière comme
les points du test (Seulement des points entiers sont donnés).
On nomme une variable catégorique, si ses valeurs possibles (ses modalités) ne sont pas numériques
et peuvent être énumérées, comme les modalités de la variable « réussi » (oui, non). Une variable
numérique peut être catégorisée. Pour cela on regroupe les valeurs avant d’assigner à chaque groupe une
valeur catégorique.
Parfois, une variable catégorique est cachée derrière une apparence numérique. Il est alors, par
exemple, possible de donner les valeurs 0 et 1 aux entités pour la variable « réussi » (0 = non réussi, 1 =
réussi).
La figure 3 décrit la systémique des données et les transitions qui sont possibles entre les formes
différentes.
Figure 3
•
La systémique des données
Nettoyage de données
49
Bien sûr, lorsque les données proviennent d'un data warehouse (Entrepôt de données), le travail est
simplifié mais reste néanmoins nécessaire: nous avons maintenant un projet bien défini, précis et les
données doivent être les plus adaptées possibles. Reprenons quelques remarques :
• Doublons, erreurs de saisie : Les doublons peuvent se révéler gênants parce qu'ils vont donner plus
d'importance aux valeurs répétées. Une erreur de saisie pourra à l'inverse occulter une répétition.
• Intégrité de domaine : Un contrôle sur les domaines des valeurs permet de retrouver des valeurs
aberrantes.
• Informations manquantes : C'est le terme utilisé pour désigner le cas où des champs ne
contiennent aucune donnée. Parfois, il est intéressant de conserver ces enregistrements car l'absence
d'information peut être une information. D'autre part, les valeurs contenues dans les autres champs
risquent aussi d'être utiles.
•
Enrichissement
On peut avoir recours à d'autres bases, achetées ou produites en un autre lieu, pour enrichir nos
données. L'opération va se traduire par l'ajout de nouveaux champs en conservant souvent le même
nombre d'enregistrements (objet).
•
Codage et normalisation
Ce sont les valeurs des champs des enregistrements des tables de l'entrepôt de données. Ces
données possèdent un type qu'il faut préciser. En effet, la plupart des méthodes sont sensibles aux
données manipulées. Par exemple, certaines méthodes sont mises en défaut par les données continues
alors
que
•
d'autres
peuvent
être
sensibles
à
la
présence
de
données
discrètes.
Les données discrètes
Les données binaires ou logiques : 0 ou 1 ; oui ou non ; vrai ou faux, sont des données telles que le
sexe, être bon client. Les données énumératives sont des données discrètes pour lesquelles il n'existe pas
d'ordre défini à priori, par exemple : la catégorie socioprofessionnelle, la couleur.
Les données énumératives ordonnées concernant : les réponses à une enquête d'opinion (1: très
satisfait ; 2 : satisfait ; ...), les données issues de la discrétisation de données continues (1 : solde moyen <
2000 ; 2 : 2000 £ solde moyen < 5000 ; ...)
50
•
Les données continues
Ce sont les données entières ou réelles : l'âge, le revenu moyen, ... mais aussi les données pouvant
prendre un grand nombre de valeurs ordonnées. Les dates sont souvent problématiques car mémorisées
selon des formats différents selon les systèmes et les logiciels. Pour les applications en fouille de données,
il est fréquent de les transformer en données continues ou en données énumératives ordonnées. On
transforme une date de naissance en âge entier ou en une variable énumérative ordonnée correspondant à
des tranches d'âge.
•
Les données textuelles
Un texte peut, pour certaines applications, être résumé comme un N-Uplet constitué du nombre
d'occurrences dans le texte de mots clés d'un dictionnaire prédéfini.
2.2.2.2
Traitement des données
Le datamining est un processus itératif, parfois interactif, qui combine plusieurs méthodes
mathématiques, statistiques ou algorithmiques en vue de la détermination d’une situation à un problème
posé, dans un univers décisionnel. Après la préparation des données il ne reste que l’appel aux techniques
du datamining. Il n'existe pas de meilleure méthode de fouille, il faudra faire des compromis selon les
besoins dégagés et les caractéristiques connues des outils.
On peut succinctement donner quatre
catégories :
1 . Classification, régression, prédiction :
Il s'agit de trouver une classe ou une valeur selon un ensemble de descriptions. Ce sont des outils
très utilisés. Les algorithmes reposent sur des arbres de décision, des réseaux de neurones, la règle de
Bayes, les k plus proches voisins.
2 . Association :
51
Il s'agit de trouver des similarités ou des associations. Le sequencing est le terme anglais utilisé
pour préciser que l'association se fera dans le temps.
3 . Segmentation :
La problématique est de trouver des groupes homogènes dans une population. La difficulté
essentielle dans ce type de construction est la validation qui nécessite l'intervention d'experts humains.
4 . Évaluation des résultats:
2.2.2.3
•
Évaluation qualitative : présentation graphique ou textuelle des résultats.
•
Évaluation quantitative : les résultats présentés sont affectés d’un “indice de confiance”.
Validation
Les modèles extraits, notamment par les méthodes d’apprentissage supervisé (segmentation,
association), ne peuvent être utilisés directement en toute fiabilité. Nous devons les évaluer, c’est-à-dire
les soumettre à l’épreuve de la réalité et apprécier leur justesse.
Le procédé habituel consiste à estimer au mieux le taux d’erreur du modèle. Ainsi, l’utilisateur
décidera d’appliquer ou non le modèle de prédiction en connaissance des risques qu’il prend. Nous
distinguerons deux modes de validation : statistique et par expertise. La première tâche à réaliser consiste
à utiliser les méthodes de base de statistique descriptive. L'objectif est d'obtenir des informations qui
permettront de juger le résultat obtenu, ou d'estimer la qualité ou les biais des données d'apprentissage.
Pour la classification supervisée, la deuxième tâche consiste à décomposer les données en plusieurs
ensembles disjoints. L'objectif est de garder des données pour estimer les erreurs des modèles ou de les
comparer.
2.2.3
Arbre de décision
La méthode des arbres de décision est une méthode d’apprentissage supervisée dont le but est de
calculer automatiquement les valeurs de la variable endogène (à prédire), fixée à priori, à partir d’autres
52
informations (variables exogènes ou prédictives). Le principe des arbres de décision repose sur un
partitionnement récursif des données. Le but du partitionnement est d’obtenir des groupes homogènes du
point de vue de la variable à prédire. Le résultat est un enchaînement hiérarchique de règles. Un chemin,
partant de la racine jusqu’à une feuille de l’arbre, constitue une règle d’affectation du type « Si condition
Alors conclusion ». L’ensemble de ces règles constitue le modèle de prédiction [ZIGH 00].
Les arbres de décision sont composés d'une structure hiérarchique en forme d'arbre. Cette
structure est construite grâce à des méthodes d'apprentissage par induction à partir d'exemples. L'arbre
ainsi obtenu représente une fonction qui fait la classification d'exemples, en s'appuyant sur les
connaissances induites à partir d'une base d'apprentissage. En raison de cela, ils sont aussi appelés arbres
d'induction (Induction Decision Trees).
De manière plus formelle nous pouvons définir un arbre de décision comme un graphe orienté,
sans cycles, dont les noeuds portent une question, les arcs des réponses, et les feuilles des conclusions, ou
des classes terminales.
2.2.3.1
Mode de fonctionnement
Un arbre de décision se construit à partir d'un ensemble d'apprentissage par raffinements de sa
structure. Un ensemble de questions sur les attributs est construit afin de partitionner l'ensemble
d'apprentissage en sous-ensembles qui deviennent de plus en plus petits jusqu'à ne contenir à la fin que
des observations relatives à une seule classe. Les résultats des tests forment les branches de l'arbre et
chaque sous-ensemble en forme les feuilles. Le classement d'un nouvel exemple se fait en parcourant un
chemin qui part de la racine pour aboutir à une feuille : l'exemple appartient à la classe qui correspond
aux exemples de la feuille. Quinlan [QUIN 93] a proposé une méthode pour traiter ce problème du choix
de l'attribut. Il utilise une technique fondée sur la théorie de l'information de Shannon [ZIGH 85]. L'idée
consiste à appliquer une méthode qui permet de maximiser le gain d'information apporté par chaque test.
2.2.3.2
Les Systèmes fondés sur les Arbres de Décision
Parmi les méthodes d'apprentissage fondées sur les arbres de décision les plus connues, on trouve
l'algorithme ID3 [QUIN 93] et la méthode CART [QUIN 93]. Ces systèmes sont assez semblables. La
principale différence entre ces deux systèmes réside dans le choix de la mesure utilisée pour la sélection
des attributs pendant la construction de l'arbre. Cette mesure est généralement fondée sur la théorie
53
de l'information de Shannon (entropie et gain d'information utilisées dans ID3). La méthode ID3 est à
l'origine de plusieurs autres systèmes. Le plus ancien est le système C4.5, étendu par Quinlan. A l'origine
du système C4.5 se trouve la volonté de résoudre les différents problèmes rencontrés dans son
prédécesseur : l'algorithme ID3.
Ces problèmes sont assez caractéristiques des arbres de décision en général, à savoir :
§
Les premiers systèmes ont été conçus pour traiter des attributs avec des valeurs
nominales et discrètes (variables qualitatives) et ne pouvaient pas traiter des attributs avec des valeurs
continues (variables quantitatives). Il manquait des méthodes bien adaptées pour trouver les bonnes
questions à poser sur les valeurs continues et qui seront postérieurement associées aux noeuds de l'arbre ;
§
Le choix du meilleur attribut qui va diviser les exemples présente lui aussi
certains
problèmes. Comment peut-on nous assurer que la méthode employée va nous amener à la construction de
l'arbre le plus simple possible ? De plus, il n'est pas difficile de trouver des exemples pour lesquels une
variable a un très grand pouvoir de discrimination, mais n'aide pas beaucoup à la solution du problème
(e.g: l'âge ou le sexe d'une personne permet de discriminer les gens d'une façon très efficiente; toutefois
est-elle une bonne variable par rapport à tous les types de problèmes de classification ?) ;
§
On ne connaît pas toutes les valeurs de chacun des attributs considérés pour la classification.
Le fait que l'on doive travailler sur des domaines représentés par des informations incomplètes ouvre la
problématique du traitement des attributs avec valeurs manquantes ;
§
Les
arbres
de
décision
obtenus
souffrent
du
problème
de
sur-apprentissage
(overtrainning/ovefitting). Le fait que la construction de l'arbre de décision ne s'arrête que lorsque tous les
exemples de la feuille appartiennent à une même classe, suppose des
ensembles d'apprentissage
contenant uniquement des exemples « parfaits ». L'arbre de décision finit par trop se spécialiser dans les
exemples d'apprentissage.
Souvent, les bases d'apprentissage sont incomplètes, elles ont des exemples incorrects, et implique
que cette méthode d'apprentissage ne fonctionnera pas correctement ;
§
Les arbres de décision, tels que ID3, doivent être complètement reconstruits pour
prendre en compte un nouvel exemple ajouté à la base d'apprentissage. Ce type d'arbre n'est pas
incrémental du point de vue de l'acquisition de données, même si sa structure est construite d'une façon
incrémentale. Il faut recommencer tout l'apprentissage pour prendre en compte un nouvel exemple ;
54
§
Malgré le fait que ces méthodes cherchent à construire des arbres simples, certaines branches
peuvent être répliquées. La structure en arbre n'est pas toujours la forme la plus simple et la plus
économique pour représenter les informations. Les graphes de décision restent une alternative à la
structuration en forme d'arbres ;
§
Les arbres de décision, comme leur nom l'indique, servent à obtenir une classification des
donnés et ont donc une ou plusieurs sorties binaires. On ne peut pas avoir une sortie qui représente une
valeur continue. Ce type d'arbres de décision n'est pas utilisable pour l'approximation de fonctions
(régression) ;
§
Finalement, ces arbres de décision n'exploitent pas de méthodes permettant l'utilisation des
connaissances théoriques disponibles sur le problème. Dans leur forme initiale, les arbres d'induction
travaillent uniquement sur les connaissances empiriques.
Plusieurs systèmes fondés sur les arbres de décision ont pris en compte ces différentes remarques
décrites ci-dessus, en essayant d'apporter des solutions plus performantes, tels que:
• C4.5 [QUIN 93] : c'est un système dérivé de l'ID3. Il présente des propositions pour traiter et
améliorer les items A (discrétisation des variables quantitatives), B (prise en compte des coûts associés
au choix de chaque attribut), C (prise en compte par la fonction de sélection d'attributs), D (élagage de
l'arbre à la fin du processus d'apprentissage) et E (explicitation de règles symboliques du type Si-Alors à
partir des arbres de décision);
• Assistant Professional [KONO 88]: il utilise une autre fonction de choix d'attributs qui permet
l'élagage de l'arbre de décision (post-pruning), et implémente une méthode de binarisation des attributs
avec des valeurs continues.
• ID5R [MAHO 91]: Il s'agit d'une méthode de construction incrémentale d'arbres de décision qui
permet d'apprendre de nouveaux exemples sans avoir besoin de recommencer l'apprentissage;
• SIPINA [ZIGH 00]: système de construction de graphes de décision. Il utilise une fonction
particulière de sélection d'attributs, implémente une méthode de discrétisation des variables continues,
55
implémente une méthode qui évite le sur-appentissage et permet aussi l'explicitation de
règles
représentées dans les graphes de décision (voir section 3).
2.2.3.3
Finalités sur les Arbres de Décision
Les arbres de décisions sont largement utilisés, car ce type d'approche est assez stable et donne de
bons résultats dans un grand nombre d'applications. Cependant, dans certains types d'applications, les
arbres de décision donnent des résultats décevants.
Plusieurs systèmes ont été conçus afin de résoudre ou de minimiser ces problèmes. Néanmoins,
certains aspects sont directement liés à la façon dont les arbres de décision sont construits et à leurs
propriétés. Les techniques que nous avons décrites apportent des améliorations, mais les problèmes de
base demeurent, à savoir :
§
La
difficulté
de manipulation de variables quantitatives (valeurs continues).
La
discrétisation des données reste une solution à considérer, mais elle ne résout pas tous les problèmes de
traitement d'informations non-symboliques ;
§
Le choix des attributs à considérer dans les divisions (noeuds de l'arbre) ne garantit pas une
solution toujours parfaite. De plus, la méthode la plus utilisée, fondée sur la théorie de l'information de
Shannon, impose de fortes contraintes aux méthodes incrémentales ;
§
Les méthodes incrémentales restent des méthodes assez intéressantes à étudier, mais elles
imposent d'autres contraintes au niveau de la construction de l'arbre. Dans ces deux cas, le processus
d'élagage semble être difficile à implémenter et la complexité de la tâche de construction et de
maintenance des arbres augmente ;
§
Les arbres de décision n'utilisent pas de connaissances théoriques disponibles sur le
problème posé. Ils exploitent uniquement des connaissances empiriques. Enfin, la méthode de
représentation des connaissances utilisée dans les arbres de décision est très dépendante du type de
questions associées aux noeuds.
2.2.3.4
Avantages de l induction par graphes d induction
56
La précision des graphes d’induction, malgré la simplicité du système de représentation des
connaissances, est excellente [ZIGH 02] face à des méthodes plus complexes, ils constituent certainement
une approche de référence qui permet d’appréhender la complexité du concept et l’évaluation des outils
les plus adaptés.
Couplés avec sa lisibilité, on peut visualiser directement le processus de classement d’un nouvel
individu, il est évident que les graphes d’induction représentent des instructions privilégiés d’exploration
des données, que ce soit en termes de description ou de classement [TALE 06]. Avec l’émergence de
l’ECD, on voit d’ailleurs un accroissement des travaux autour des graphes et des arbres de décision
matérialisés par la diffusion de plus en plus large de logiciels spécialisés sous des plate-formes
différentes.
Leur simplicité en fait un algorithme facile à programmer, qui requiert peu de calculs,
particulièrement adapté pour le traitement de grosses bases de données. Sa mise à jour ne pose pas
particulièrement de problèmes, il existe même des stratégies incrémentales qui, sous certaines conditions,
retrouvent les graphes tels qu’ils seraient. Enfin, leur rapidité en classement dépend tout simplement du
nombre moyen de n uds en partant de la racine aux feuilles. La préférence à la simplicité satisfait tous
les critères d'évaluation des classifieurs mis à part la précision qui peut en souffrir dans certaines
circonstances. En tous les cas, l'expert peut ici piloter à sa guise l'arbitrage entre la complexité et la
précision.
On peut citer la possibilité de construction ou de révision partielle du classifieur par un expert du
domaine, qui permet l’interprétation la traduction exacte en base de règles d'un graphe en vue d'en
améliorer les performances en classement et afin d'alimenter les systèmes experts, la sélection des
meilleurs attributs prédictifs, le traitement automatisé des données manquantes.
S'il est difficile ici de prétendre à l'exhaustivité, qu'en est-il de l'utilisation des graphes d'induction
sur des problèmes réels? Il faudrait une encyclopédie pour les recenser. Les graphes ont été appliqués
avec succès dans de très nombreux domaines tels que la recherche médicale, la géographie, la prévention
des incendies, la surveillance des réseaux électriques…
2.2.4
Les algorithmes génétiques
57
La notion d'Algorithme Génétique (AG) a été introduite par Holland en 1975 [HOLL 75] et a été
développée au cours des années quatre-vingt. Plus récemment, la programmation génétique, a été dérivée
des AG [GOLD 89].
2.2.4.1
Mode de fonctionnement
Les algorithmes génétiques sont des algorithmes d'exploration fondés sur les mécanismes de la
sélection naturelle et de la génétique. Ils utilisent à la fois les principes de survie des structures les mieux
adaptées, et de modification pseudo-aléatoire d'informations, pour former un algorithme d'exploration
qui possède des caractéristiques intéressantes.
Le principe de l'algorithme est simple et repose sur un codage des problèmes et de leurs solutions
sous la forme de chaînes d'éléments de base. Les chaînes peuvent être rompues entre chaque élément de
base, à l'image des chromosomes, qui eux constituent de véritables listes de caractéristiques d'un individu.
Le codage prend habituellement la forme d'une chaîne binaire très structurée, de longueur fixe ou variable
selon le type de problème. On génère tout d'abord une population de solutions potentielles à un problème
donné, sous la forme de telles chaînes, puis on sélectionne, au moyen d'une mesure d'ajustement, les
éléments de la population qui satisfont au mieux les contraintes de la solution recherchée.
2.2.4.2
Apprentissage des AG
Pour pouvoir réaliser un apprentissage de règles avec des AG, il est nécessaire d'avoir une
représentation interne de l'espace de recherche. Le codage utilisé par les AG est donc très important vis-àvis de l'implémentation des outils d'apprentissage automatique. Le choix d'un type de codage spécifique
doit essayer de garder les propriétés des AG, sans imposer des restrictions qui peuvent nuire ou
restreindre la convergence de l'algorithme vers une bonne solution.
Deux approches assez connues pour générer automatiquement un classifieur à partir d'un AG
sont : l'approche postule qu'un élément (chromosome) correspond à une base de règles et qu'une
population de chromosomes est un ensemble de bases de règles. L'autre approche postule qu'un
chromosome représente une règle et qu'une population correspond
donc à une base de règles.
L'algorithme, au cours de ses itérations cherche à construire et à améliorer une seule base de
connaissances.
58
2.2.4.3
Finalités sur les algorithmes génétiques
Les algorithmes génétiques se présentent comme une approche très
intéressante. Ils
sont
capables d'exploiter l'espace de recherche sans avoir à imposer de restrictions liées au type d'algorithme
choisi, ce qui n'est pas le cas des autres algorithmes d'apprentissage automatique. Une des tâches les plus
difficiles est la définition de ces choix d'implémentation des AG. Ce type de problème est délicat dans la
mesure où il n'existe pas de méthodologie générale à suivre.
Il nous reste à souligner que la majorité des AG sont des approches qui manipulent des
informations purement symboliques, d'où la difficulté à travailler avec des variables continues et des
données approximatives.
2.2.5
Raisonnement basé sur les cas : CBR
Le CBR [BRES 01] recouvre un ensemble de méthodes de résolution de problèmes qui exploite
les expériences passées, plutôt que les connaissances générales d'un niveau supérieur, telles que les règles
de production. Les CBR sont des méthodes d'apprentissage totalement fondées sur les connaissances
empiriques, au lieu de faire usage des connaissances théoriques d'un domaine.
2.2.5.1
Mode de fonctionnement
Un système CBR est capable d'utiliser la connaissance spécifique contenue dans son
expérience passée pour résoudre les nouveaux problèmes. Cette expérience est représentée normalement
sous la forme de cas. Ces cas, qui ont été corrigés et assignés par l'expert aux classes auxquelles ils
appartiennent, constituent ainsi la mémoire d'un système CBR. En général, un système de raisonnement
fondé sur des cas contient les phases suivantes:
1. Remémoration des cas les plus similaires par rapport au cas posé en question;
2. Réutilisation de la connaissance du (ou des) cas remémore(s) pour la résolution du problème;
3. Révision de la solution donnée afin de la valider;
4. Mémorisation de cette nouvelle expérience, pour une utilisation future.
2.2.5.2
Finalités sur le Raisonnement Fondé sur des Cas
59
Les CBR font appel à des algorithmes d'apprentissage dits paresseux (lazy learning). Les systèmes
CBR n'essaient pas de traiter les exemples fournis, alors que les autres algorithmes d'apprentissage font
une compilation des exemples d'apprentissage et les remplacent par des abstractions concises (e.g.: arbres
de décision, ensembles de règles).
Les CBR sont des systèmes purement fondés sur les connaissances empiriques et ne permettent
pas l'utilisation de connaissances théoriques. Donc, on ne peut pas profiter des connaissances disponibles
sur le domaine d'application sauf si celles-ci sont représentées par des cas pratiques. Toutefois, on trouve
dans la littérature des méthodes alternatives qui permettent de contourner ce problème d'une manière
assez simple : la solution consiste à transformer les règles
symboliques
en
exemples
qui les
représentent (prototypes des concepts théoriques).
3
Sipina
La méthode SIPINA [ZIGH 92] permet de traiter les problèmes d’explication. Ce type de
problème se retrouve surtout dans le domaine des sciences de l’homme (sociologie, biologie, psychologie,
médecine,…). La méthode SIPINA a été utilisée, par exemple, pour l’aide au diagnostic, l’évaluation
d’un risque, l’établissement de profils caractéristiques de certaines populations…
SIPINA signifie Système Interactif pour les Processus d’Interrogation Non Arborescent. C’est à la
base une méthode d’analyse des données. Elle fait partie des méthodes dites explicatives comme l’analyse
discriminante, la segmentation, la régression… Cette méthode permet d’expliquer une variable qualitative
par des variables explicatives elles-mêmes toutes qualitatives [ZIGH 00].
3.1 Méthode SIPINA
3.1.1
Le choix du critère
Soit λ un paramètre positif non nul. Le critère que nous cherchons à optimiser sera la recherche de
la variation d'incertitude la plus forte par passage d'une partition Si à la suivante Si+1, d'où :
Pour ℑ (S i), nous pouvons ∆ℑ(Ti +1 ) = ℑ λ (S i ) − ℑ λ (S i +1 ) utiliser plusieurs fonctions construites à
60
partir de mesures d'incertitude [ZIGH 00] telles que :
•
K n 
m
nij + λ
nij + λ 
.j


log 2
S
ℑ
=
−
(
)
∑
∑
l'entropie de Shannon : λ i


λ
λ
n
n
m
n
m
+
+
j =1
.j
 i =1 . j

§
l'entropie quadratique
n. j  m nij + λ 
n + λ 
∑
1 − ij

 i =1 n. j + mλ  n. j + mλ  
j =1 n



K
ℑ λ (S i ) = ∑
Toutes les mesures d'entropie peuvent ainsi être adaptées comme mesure d'incertitude au sens que
l'on vient de lui donner [ZIGH 02].
3.1.2
Fixation du paramètre λ
Le paramètre λ contrôle le développement du graphe et pénalise les n uds de faible effectif et, de
ce fait, favorise les fusions entre sommets semblables. L'une des stratégies utilisées pour fixer λ consiste à
définir une situation indésirable et de trouver la valeur λ* qui pénalise le plus cette situation [ZIGH 00].
L'utilisateur peut, par exemple, considérer qu'un sommet sj dont l'effectif n.j est inférieur à τ, est
indésirable dans le graphe. Il souhaiterait alors pénaliser fortement les sommets dont l'effectif total est
inférieur à cette valeur. Nous verrons dans la section suivante une façon automatique possible pour fixer
cette taille minimale. Considérons l'exemple des deux distributions données par Tu et Tv. Compte tenu de
la propriété de sensibilité aux effectifs, parmi toutes les distributions Tk possibles de τ individus sur m
classes, nous avons ℑ λ (Tu ) ≤ ℑ λ (Tv ) . Nous déduisons donc que si un n ud présente une distribution dont
l'effectif total est inférieur ou égale τ la valeur du critère utilisé devrait être la plus mauvaise possible
[ZIGH 00].
Tu
τ
Tv
τ +1
0
M
0
M
0
n .i = τ
0
n .i = τ + 1
Bien que Tu et Tv ne diffèrent que d'une unité, on devrait pénaliser fortement Tu. Nous choisirons λ* telle
que :
ℑ λ * (Tv ) − ℑ λ * (Tu ) = max (ℑ λ (Tv ) − ℑ λ (Tu ))
λ
61
ℑλ (T j ) = ∑
m
En prenant
i =1
Nous obtenons
nij + λ 
n +λ 
1 − ij

n. j + mλ  n. j + mλ 
2τ 2 + 2τ + mλ + 2τmλ
ℑ λ (Tv ) − ℑ λ (Tu ) = λ ( m − 1)
(τ + mλ )2 (τ + 1 + mλ )2
que l'on doit maximiser.
Une solution littérale réelle existe [ZIGH 00], trop longue cependant pour être retranscrite ici.
Pour un exemple simple (m=2 et τ=2), la valeur optimale sera : λ=0.61098.
3.1.3
Fixation de la contrainte d'admissibilité
Il existe deux stratégies pour déterminer la taille minimale d'un sommet. La première consiste à
demander à l'utilisateur de fixer le nombre minimum d'individu τ que doit comporter chaque sommet. La
seconde consiste à calculer le nombre minimum en adoptant un point de vue statistique. Pour simplifier,
considérons que nous cherchons seulement à discriminer deux classes c1 et c2.
Les éléments de la classe c1 seront appelés les exemples et ceux de c2 les contre-exemples. Le
raisonnement étant parfaitement symétrique si on inversait les deux classes. Dans le cas d'un problème à
m classes, l'une jouera le rôle de la classe des exemples, les autres sont réunies pour former celle des
contre-exemples. Dans la suite, on notera la classe des exemples e et celle des contre-exemples c. Le
nombre d'individus dans la classe exemple sera ne et le nombre d'individus dans la classe des contres
exemples sera nc. La taille de l'échantillon d'apprentissage n=ne+nc. Soit s un sommet terminal du graphe
d'induction dont l'effectif total sera n s=n se+n sc où nse et nsc désignent respectivement le nombre
d'individus de la classe des exemples et le nombre d'individus de la classe des contre-exemples dans le
sommet s. Soit le test d'hypothèse suivant
nsc nc

H
:
 0 n = n

s

H : nsc < nc
 1 ns
n
62
H0 signifie que la règle qui conduit au sommet s n'est pas pertinente car la proportion de contre exemples
dans ce sommet est identique à ce qu'elle était à la racine. Autrement dit, la règle R qui définie le sommet
s ne nous apprend rien sur la classe e des exemples.
Nous fixons l'effectif minimum τ comme suit : pour un seuil critique α0=5% par exemple, on
détermine le nombre d'individus total dans un sommet terminal ns tel que si n sc=0, on conclut au rejet de
H0. Ainsi [ZIGH 00], on établit :
n s = − ln(α 0 )
d'où on extrait :
n
nc
la valeur de τ =ns.
La détermination de τ ne pose donc aucun problème puisque le risque critique α0 est fixé par
l'utilisateur et les effectifs n et n c sont connus dès le départ. Il s'agit de préciser maintenant comment nous
allons choisir la classe des exemples et celles des contre-exemples notamment quand nous sommes en
présence de m classes qui n'ont pas le même effectif. Si nous considérons, à tour de rôle, chaque classe
ci,(i=1,…,m) comme la classe des exemples et toutes les autres sont réunies dans une même classe de
contre-exemple, nous déduisons un effectif minimal τi. L'effectif minimal que nous allons retenir sera :
Toutes
les
τ * = max (τ i )
méthodes i =1,K, m basées sur les graphes d'induction introduisent cette
contrainte d'admissibilité sur les sommets. Cette décision [ZIGH 00] a des effets qu'il est nécessaire de
bien repérer pour mieux apprécier la qualité des résultats.
3.1.4
Prise en compte des attributs continus
Il existe de nombreuses stratégies permettant la prise en compte des données continues dans les
graphes d'induction. Dans cette sous section, nous allons simplement décrire le principe, fort simple, de
leur prise en compte dans SIPINA [ZIGH 92] et [ZIGH 00].
Plaçons nous dans le cas où nous souhaitons engendrer une partition sur un sommet, par exemple,
la racine s0 pour simplifier, à partir de la variable continue Xj. La seule manière pour y parvenir est de la
transformer en variable discrète. Puisque tous les individus de Ω (ensemble de la population) sont dans la
racine, l'ensemble des valeurs de la variable prise par Xj sur l'échantillon d'apprentissage est :
63
{
X −j 1 (Ω ) = x j1 , K, x jk , K, x jα j
}
Si on considère toutes ces valeurs observées sur un axe, on note δjk le milieu du segment qui a
pour extrémités xjk et xj,k+1
δ jk =
x j ,k +1 − x jk
2
Nous définissons [ZIGH 00] ainsi αj-1 points médians. Chacun d'eux permet de définir une
bipartition de Ω permettant de transformer la variable continue Xj en une autre variable X'j binaire de la
manière suivante :
1 si X j (ω ) ≤ δ jk
X ' j (ω ) = 
2 si X j (ω ) > δ jk
Chaque bi-partition définit deux sous-ensembles,
Ω = {ω ∈ Ω ; X j (ω ) > δ
k
2
jk
Ω1k = {ω ∈ Ω; X j (ω ) ≤ δ jk }
et,
} à partir desquels on peut former un tableau de contingence qui nous servira
à calculer notre mesure d'incertitude. Le point de discrétisation optimal sera la valeur δjk telle que
l'incertitude mesurée sur le tableau de contingence associé est minimale.
3.1.5
Éléments de construction de graphes d'induction
Avant de présenter l'algorithme utilisé par SIPINA, nous allons donner quelques définitions.
Soit S i={s1,s2
§
,sK} une partition de Ω engendrée par un sous-ensemble de variables exogènes X :
Éclatement
Soit sq un élément de Si et soit Xj une variable exogène. On appelle Eclatement ou segmentation du
j
j
j
sommet sq par la variable Xj le procédé qui consiste à construire les ensembles s q ,1 , s q , 2 , K, s q ,α , tels que :
pour tout k = 1,K , α j (αj étant le nombre de valeurs possibles que peut prendre la variable Xj) :
{
s qj, 2 = ω ∈ s q ; X j (ω ) = I kj
}
64
On dira que Si+1 est une partition de Ω déduite de Si par Eclatement en remplaçant sq par
s qj,1 , s qj, 2 ,K , s qj,α
§
Regroupement
On appelle Regroupement ou Fusion de sq et st l'ensemble sqt=sq∪ st et on dira que la partition Si+1 de Ω
est déduite de Si par Regroupement.
§
Gain sur l'incertitude
Si Si+1 est une partition de Ω déduite de S i par Regroupement ou par Eclatement, on appellera Gain sur
l'incertitude la quantité :
∆ℑ(S i +1 ) = ℑ λ (Ti ) − ℑ λ (Ti +1 )
§
Partition admissible
Soit Si une partition sur Ω, on dira que la partition suivante S i+1 est une partition admissible si et
seulement si elle vérifie la condition suivante : Le gain sur l'incertitude en passant de Si à Si+1 est positif
∆ℑ(S i +1 ) = ℑ λ (Ti ) − ℑ λ (Ti +1 ) > 0
Les notions d'Éclatement et de Regroupement vont constituer les deux opérations de base pour
construire un graphe d'induction. L'algorithme visera donc à rechercher au moyen des deux opérations
précédentes une succession de partitions telles que à l'itération i+1 le Gain sur l'incertitude ∆ℑ(S i +1 ) soit
maximal. Il convient de préciser l'ordre dans lequel vont s'effectuer ces deux opérations.
Soit Si = {s1, s2,…,sK} une partition de Ω engendrée par X. Nous allons définir la manière de
combiner les deux opérations de base pour passer de la partition S i à la partition Si+1. Pour rechercher la
nouvelle partition Si+1 on peut soit :
•
procéder à des éclatements,
•
procéder à des regroupements,
•
effectuer successivement ces deux opérations
Si on procédait systématiquement à des éclatements, on prendrait le risque d'avoir un graphe
arborescent qui pourrait nous conduire vers une partition trop fine dont les éléments contiennent un
effectif relativement faible pour être valides sur le plan statistique. Pour cette raison nous privilégions les
regroupements. Dans le cas, où aucun regroupement ne permet d'obtenir une meilleure partition, nous
65
procédons alors par regroupement suivi immédiatement d'un éclatement. Cela consiste à regrouper deux
éléments de la partition Si et à chercher un éclatement qui conduirait à une meilleure partition.
Le regroupement produit une partition intermédiaire S'i qui est nécessairement de plus mauvaise
qualité [ZIGH 00]. L'éclatement ne doit pas seulement compenser la perte d'information due au
regroupement mais déboucher sur une partition Si+1 telle que le gain d'incertitude soit positif. Nous allons
détailler sur un exemple les enchaînements que l'on vient de décrire et qui constitue le c ur de
l'algorithme de recherche.
3.1.6
Passage de la partition Si à la partition Si+1
Figure 4
Partition courante Si
La partition Si
possède trois éléments {s1 ,s2 ,s3}
nous supposons que nous disposons de trois variables Xj(j=1,…,3) exogènes dichotomiques [ZIGH 00].
Pour passer de la partition S i à la partition Si+1 nous effectuerons les trois phases suivantes :
§
Phase 1 (Passage de Si à Si+1 par regroupement) [ZIGH 00]: Sur l'exemple de la figure 4,
on peut noter, qu'à partir de Si nous pouvons générer trois partitions par regroupement :
( )
∪ s } qui donne un gain d'incertitude ∆ℑ(S )
∪ s } qui donne un gain d'incertitude ∆ℑ(S )
1
S i1+1 = {s3 , s1 ∪ s 2 } qui donne un gain d'incertitude de ∆ℑ S i +1
S i2+1 = {s1 , s 2
S i3+1 = {s 2 , s1
3
2
i +1
3
3
i +1
'
On note S i +1 la partition telle que :
( )
∆ℑ(S 'i +1 ) = max ∆ℑ S i j+1
j =1, 2 ,3
Si le gain sur l'incertitude ∆ℑ(S ' i +1 ) > 0 alors, Si+1=S'i+1. L'algorithme peut alors repartir à
la phase 1 pour engendrer une nouvelle partition [ZIGH 00]. Si cette inégalité n'est pas vérifiée, on passe
66
à la phase 2. Notons au passage que le regroupement se fait toujours entre deux sommets comme le
montre la figure 5.
§
hase
2
(Passag
e de Si à
Si+1 par
Regrou
pementEclatem
ent)
Figure 5
Liste des partitions générées par les regroupements par paires
:
Comme
dans la
phase 1, nous effectuons tous les Regroupements entre toutes les paires de sommets. Nous obtenons trois
regroupements possibles représentés dans la figure 5. Sur chaque sommet issu d'un regroupement, nous
cherchons par Eclatement, avec toutes les variables Xj, la meilleure partition admissible. Par exemple,
avec trois variables, nous générons pour chacun des trois sommets issus de la fusion précédente, trois
partitions, ce qui donne en tout neuf partitions.
Figure 6
Éclatement du 1er regroupement avec les trois variables
67
P
Figure 7
Figure 8
Éclatement du 2ème regroupement avec les trois variables
Éclatement du 3ème regroupement avec les trois variables
Ensuite, parmi toutes les partitions admissibles, nous prenons celle qui conduit au meilleur gain
sur l'incertitude. Dans le cas, où nous trouvons des partitions admissibles, nous prenons la meilleure et
nous pouvons repartir à la phase 1 pour rechercher une nouvelle partition si non, nous poursuivons par la
phase 3.
§
Phase 3 (Passage de Si à Si+1 par Éclatement) : Sur chaque sommet s ∈ S i , nous
cherchons par Éclatement, avec toutes les variables Xj, la meilleure partition admissible. Sur l'exemple
donné par la figure 4, avec trois variables, nous générons pour chacun des trois sommets trois partitions.
68
Figure 9
Éclatement du sommet s1 avec les trois variables
Figure 10
Éclatement du sommet s2 avec les trois variables
Figure 11
Éclatement du sommet s3 avec les trois variables
Ensuite, parmi toutes les partitions admissibles nous prenons celle qui conduit au meilleur gain sur
l'incertitude. Dans le cas où nous trouvons une partition admissible, nous reprenons à partir de la phase 1
si non, le processus s'arrête car nous n'avons pas réussi, de quelque façon que se soit, à améliorer la valeur
de notre critère.
3.2 Algorithme SIPINA
Nous disposons donc de tous les éléments pour décrire l'algorithme de SIPINA [ZIGH 92].
1. Choix de la mesure d’incertitude ℑ . Nous avons défini une famille de mesures vérifiant les propriétés
requises. Nous pouvons prendre la formule de calcul la plus simple celle qui utilise "l'entropie
quadratique''. L'expression générale sur une partition qui possède K éléments est donnée par la
formule suivante :
n. j  m nij + λ 
n + λ 
∑
1 − ij




+
λ
λ
n
n
m
n
m
+
j =1
.j


 i =1 . j
K
ℑ λ (S i ) = ∑
69
2. Nous déterminons la valeur de l'effectif minimal τ exigé en chaque sommet du graphe en utilisant la
procédure décrite dans la section relative à la contrainte d'admissibilité,
3. Nous déterminons la valeur de λ suivant la procédure décrite plus haut,
4. On considère la partition grossière S0 pour laquelle nous déterminons le tableau T0 et nous
calculons ℑ λ (T0 ) .
5. On recherche parmi les p variables exogènes X1
,Xp celle qui engendre la meilleure partition. Si on
j
j
note S 1 la partition engendrée par Xj et T1 le tableau de contingence associé, nous aurons à
déterminer
[
( )]
Supposons S 1 telle que [ℑ λ (T 0 ) − ℑ λ (T1 )] = max ℑ λ (T0 ) − ℑ λ T1 j
j =1,K, p
que
la
meilleure partition S1 que l'on vient de trouver possède K éléments. Dans ce cas précis, K est le
nombre de modalités de la variable utilisée.
6. Soit i l'indice de l'itération, i=1.
7. Itération courante consiste à appliquer la procédure de passage de la partition S i à Si+1, décrite
précédemment. On cherche la partition Si+1 décrite par le tableau T telle que :
ℑ λ (S i +1 ) < ℑ λ (S i )
Il est tout à fait clair que dans l'algorithme que nous venons de présenter, nous privilégions les
regroupements de sommets. Ce choix se justifie encore davantage lorsque nous travaillons sur des
populations d'effectif faible. Mais on peut imaginer d'autres stratégies. Par exemple rechercher la
meilleure partition parmi toutes celles que l'on peut obtenir en effectuant systématiquement les trois
phases : Regroupement, Regroupement-Eclatement et éclatement. Sur l'exemple précédent nous aurons à
chercher la meilleure partition parmi 21 possibilités (3 issues de la phase 1, 9 de la phase 2 et 9 de la
phase 3). C'est d'ailleurs cette version, qui ne privilégie aucune opération, qui est programmée dans le
logiciel SIPINA_W [ZIGH 00].
4
Conclusion : quelle est la méthode choisie ?
Nous avons opté pour une méthode symbolique (graphes d’induction) plutôt que statistique car
nous souhaitions que l'apprentissage génère des règles linguistiquement interprétables. En fournissant des
données linguistiques sous forme de règles, nous souhaitions obtenir d'autres données linguistiques,
présentées sous une forme identique mais plus générale. Cette méthode symbolique présente plusieurs
avantages :
70
1. Elle permet de retrouver des exemples dans les échantillons qui sont la cause d'un certain
comportement.
2. Les règles produites sont interprétables. Les régularités mises en évidence par le système sont
intéressantes en soi d'un point de vue linguistique. Elles représentent certains éléments constitutifs d'une
grammaire de corpus spécialisée.
3. On peut étudier l'action d'une seule règle ou d'un groupe de règles. Ceci est pratique pour vérifier le
bon fonctionnement du système et en faire la mise au point.
4. Elle autorise la mise à jour incrémentale des échantillons d'apprentissage. Cette possibilité est
intéressante car elle permet de mettre à jour les échantillons par un processus en spirale: après définition
d'un premier échantillon, apprentissage puis filtrage, les bons et les mauvais résultats peuvent être
récupérés pour alimenter la base des échantillons positifs et négatifs.
Dans le chapitre suivant, nous allons voir comment ce choix (l’approche symbolique) va être
intégrer pendant la modélisation UML dans la démarche proposée à la problématique posée.
71
72
1
Introduction
Dans ce chapitre, nous présentons les phases de conception de la démarche proposée dans le
développement de logiciel à l’aide du langage UML guidé par la technique d’Apprentissage Automatique.
2
Méthode d’analyse et de conception logiciel
Une méthode définit une démarche reproductible pour obtenir des résultats fiables. Tous les
domaines de la connaissance utilisent des méthodes plus au moins sophistiquées et plus au moins
formalisées. Elles permettent de construire des modèles à partir d’éléments de modélisation qui
constituent des concepts fondamentaux pour la représentation de systèmes ou de phénomènes. Une
méthode se doit de proposer quatre éléments fondamentaux [LEBL 04], [KRUC 03]:
1) Démarche : décrite qui liste les tâches à effectuer pour conduire un projet de systèmes
d’information.
2) Modèle : fourni pour décrire une sémantique des données et leur comportement.
3) Un ensemble de diagrammes : fourni en s’appuyant sur un formalisme de description (graphique
ou langage).
4) Outils logiciels d’aide : Il doit être possible de les trouver sur le marché pour la conception. Ces
outils portent le nom d’A.G.L (Atelier de Génie Logiciel) ou C.A.S.E (Computer Aided Software
Engineering).
3
Méthode proposée
Aujourd’hui, les méthodes de développement comme UML utilisées pour couvrir les besoins du
futur système à modéliser sont encore limités. La majorité des problèmes et les facteurs d’échecs de ces
systèmes sont dus à la non-satisfaction de ces besoins. Pour répondre à ces exigences, il faut récolter le
maximum d’informations propres au domaine et les structurer afin de mieux les exploiter pour faciliter
leur représentation pour une analyse approfondie ainsi que la mise en uvre.
Il est encore plus important de bénéficier de l’expérience des experts du domaine afin de bien
cerner le problème posé. L’expression des besoins correctement menée est la clé pour la réussite de tout
projet.
73
Reconnue comme la partie la plus délicate, souvent à la frontière entre deux points de vue (user et
application), elle nécessite beaucoup attention et une grande rigueur. Vu les raisons indiquées dans le premier
chapitre, nous avons été amené à innover cette méthode visant à intégrer les techniques d’ECD dans la
démarche UML.
3.1 Démarche proposée pour la modélisation
Dans cette partie, nous allons décrire de façon progressive le processus simplifié que nous
préconisons pour la modélisation UML guidée par Apprentissage Automatique.
Le processus que nous proposons de suivre est à mi-chemin entre UP (Unified Process) conduit
par les cas d’utilisation, un cadre général très complet de processus de développement, et XP (eXtreme
Programming) relativement léger et restreint, mais sans négliger les activités de modélisation en analyse
et en conception, une approche minimaliste à la mode centrée sur la technique.
Nous nous inspirons également des bonnes pratiques recommandées par les tenants de la
modélisation agile (Agile Modeling), fondée sur l’utilisation d’un sous-ensemble nécessaire et suffisant
du langage UML.
Nous devrons avoir une grande palette de techniques à notre disposition et connaître les forces et
les faiblesses de chacune de manière à pouvoir appliquer la meilleure au problème courant. On se trouve
souvent plus productif si on se concentre sur un seul type de diagramme plutôt que de se perdre sur
plusieurs modèles simultanément.
Nous allons donc essayer de trouver le meilleur rapport « client/pharmacie » possible afin de ne
pas multiplier les concepts et les diagrammes qui ne sont pas indispensables au développement
d’applications efficaces.
Le problème fondamental auquel ce travail va s’efforcer de répondre est : comment satisfaire les
besoins des utilisateurs sans avoir à les considérer comme source d’information ? Autrement dit, on est
fixé sur ce que l’application doit faire, les fonctionnalités attendues par les futurs utilisateurs en exploitant
les bases de données relevant de l’expertise du domaine. Comment obtenir le plus efficacement possible
une application opérationnelle, complète, testée, et qui réponde parfaitement aux besoins ? ».
74
Domaine
précis
Proces
Cahier des charges
?
Modèle fonctionnel
Figure 12
Problématique
Il ne s’agit pas de se lancer sur la modélisation en négligeant de formaliser les besoins des
utilisateurs et d’élaborer une architecture robuste et évolutive. D’un autre côté, le but est bien de produire
le plus rapidement possible une application qui satisfasse au mieux ses utilisateurs.
Nous allons donc proposer une démarche de modélisation nécessaire et suffisante afin de
construire efficacement une application de gestion : PHARMACIE. Pour cela nous utiliserons un sousensemble du langage de modélisation UML qui sera également nécessaire et suffisant pour la plupart des
projets de même nature. Cette approche est le résultat de plusieurs tentatives sur de nombreux projets
dans des domaines variés [KADA 06], [SLIM 05]. Elle a donc montré son efficacité dans la pratique.
Dans un premier temps, le cahier des charges va être modélisé au moyen de diagramme de classes
UML. La figure 13 montre bien de quoi nous partons et là où nous voulons arriver.
75
Figure 13
Schéma générale de la démarche proposée et la démarche classique
Les diagrammes de classes de conception représentent bien la structure statique du futur
système, par le biais des attributs et des relations entre classes, mais ils contiennent également les
opérations qui décrivent les responsabilités dynamiques des classes logicielles. L’attribution des
bonnes responsabilités aux bonnes classes est l’un des problèmes les plus délicats de la
conception orientée objet. Pour chaque service ou fonction, il faut décider quelle est la classe qui
va la contenir. Nous devons ainsi répartir tout le comportement du système entre les classes de
conception, et décrire les collaborations induites, et vu les raisons précédemment expliquées dans
le chapitre 2, nous nous contentons seulement du diagramme de classes.
3.2 Architecture globale pour l’expérimentation de la démarche proposée
Sous ensemble
Module prétraitement
Module SIPINA
de l’ ECD
Module stockage de données
Expert
Module ARGIUML
Concepteur
Sous ensemble
Modélisation
UML
Base de données
Domaine d’application
Figure 14
Architecture globale de la démarche proposée
77
Cette démarche repose sur deux axes : Modélisation UML et Processus ECD. La première
partie qui est la modélisation UML, cette étape sera affermie par la vérification du langage OCL
en ajoutant des contraintes sous formes de commentaires sur le diagramme de classe grâce au
logiciel ARGOUML free software qui va être détaillé par la suite (voir Annexe B).
3.2.1
Modélisation UML de la gestion de pharmacie
Décrivons les étapes schématisées dans la figure 13:
1) Rédaction, formalisation et mise aux points : cette étape consiste à écrire le cahier des
charges (expression des besoins) : à rédiger en langage naturel puis le transformer en
clause de Horn (logique 1er degré) sous formes de SI prémisse (s) ALORS conclusion.
Cela permet de rédiger des documents techniques clairs et efficaces, notamment des rapports
techniques et des manuels d'utilisateurs ou encore pour évaluer et élaborer des documents qui
répondent à leurs besoins. Choisir le style rédactionnel adapté à un lectorat spécialisé afin de
construire des phrases, paragraphes et sections qu’on peut utiliser des diagrammes, tables,
tableaux et autres outils graphiques efficacement vers un contenu informatif et intéressant que les
lecteurs comprendront et utiliseront.
Un style rédactionnel de qualité est la clé d'une communication réussie. Les documents
techniques donnant aux lecteurs des informations ou des instructions claires et concises
permettent de diminuer les coûts, d'améliorer l'efficacité et de s'approprier plus rapidement le
nouveau système. Lors de ce travail, nous acquerrons les compétences nécessaires pour évaluer
les besoins des utilisateurs et créer des documents techniques pour une grande variété
d'environnements afin d’apprendre les mécanismes de rédaction ainsi que les techniques de
conception et de mise en page.
C’est dans un contexte d’un atelier individuel formé d’une équipe de modélisation que
nous avons pu appliquer les concepts, les modèles et les techniques de rédaction de cahiers des
charges. Cet atelier, ainsi que l’étude de cas, nous a permis d’acquérir une expérience pratique de
la constitution d’une liste de besoins et de documents sur les besoins des utilisateurs et de
l’entreprise. Environ 30% du temps était consacré pour cette fin (voir Annexe A).
78
2) Collecte, organisation des informations : cette section est très délicate et difficile en même
temps car elle nécessite plus d’attention. Correspondant à la modélisation UML
(diagramme de classe), on va concevoir la base de données orientée objet par la fin. Le
modèle physique [KADA 06], constitue la partie la plus importante dans la construction
de notre base. Elle affine le modèle obtenu par la modélisation jusqu’à l’obtention d’une
structure qui puisse être codée convenablement aux concepts informatiques utilisés par les
outils, les langages et les plate-formes de développement. Il est en effet toujours plus
rentable de découvrir une erreur de conception sur un modèle que l’on découvre au bout
de milliers de lignes de codes.
Figure 15
Schéma de données
3) Modélisation UML : ici on s’intéresse au diagramme de classe compte tenu de ses apports
(rassemblement de données utilisées par le système dans les entités encapsulées,
définition d’opérations permettant de manipuler ces données, …) mais on ne pourra pas
aboutir au modèle sans passer par d’autres diagrammes [KADA 06]. Le diagramme de
classe, qui coïncide avec le cahier des charges précédemment établi, est réalisé.
La figure 16montre le diagramme de classe sur lequel nous avons travaillé [KADA 06] :
79
Ordonnance
Attributes
public int N°_ordonn...
public Date Date
public String Médecin
public String Note
Com pte
Attributes
Operations
1..*
1..*
public int Com pte
private int N°_ Compte
private Date Date_ création
private String Solde
1..*
Operations
1
0..*
1..*
Client
{ From Ordonnance }
Attri butes
1
public int client
public String Nom
public Date Date_Nais sance
public String Sexe
public String Tél
public String adress
public int Taux_Remb
public Bool Conventionée
Fourniss eur
1
Attributes
public
public
public
public
public
public
public
public
1..*
Paiem ent
Attributes
private int N°_paiem ent
private int Date
private int Montant
1
Operations
1
Operations
public void Ins cription()
int N°_fournis seur
String Catégorie
String Rais on_ sociale
String Adres se
String Tél
String Fax
String Pays
String E-mail
1 Dlivre
1..*
1..*
1
Possède
public String N_carte
public Date Date_déb
public Date Date_fin
Operations
1..*
1
1..*
Pharmacie
1
conventionné
Attributes
public
public
public
public
public
public
1..*
détail-paiem ent
1
Attributes
private int Paiement
private int quantité
Operations
public void MAJ()
public void Vérification()
public void Faire_COM()
public void Cntrôle_Fact()
public Compte[0..*]
getCom
pt...
1
1
1..*
travail
Dictionnaire
Lot
Attributes
Operations
public void MAJ()
1
1..*
1
1
Attributes
public int N°_fam illeArti...
public String fam illeArti...
Operations
public void Ajoute()
public void Sup()
0..1
1..*
Pharmacien
1..*
Attributes
public int N_Pharm acie
private String Nom _phar...
private String Adres se
private String Tél
private String grade
1
1..*
0..1
0..1
Lot_ Bloqués
1
Operations
Lot_ périm és
Attributes
Attributes
public int N°_ Article
public int Code
public String Dés ig...
public int Quantité_...
public Bool Hors_ ...
public Bool Rembo... 1..*
1..*
1..*
1..*
Attributes
Attributes
private int N_fact
private int quantité
private int N_lot
Operations
public int N°_lot
public String Désignati...
public Date Date_ Per
public int Quantité
public Float Prix_ vente
private Float Prix_ d ac...
Operations
FamilleArticle
1
Dait_Fact
Attri butes
int N°_dico
int Code
int Spécialité
int Dos e
int Tarif_ ref
int Date déli...
int Condit
public void Ajoute()
1
int N°_ Pharmacie
String Nom_pharmacie
String Adress e
String Tél
String Fax
int Num _ registre
Operations
1
Article
int N°_facture
Date Date
Float Montant_d achat
Float Montant _vente
public Pharmacie[0..*] getPharmac...
public void setPharmacie(Pharma...
mFacture
1..*
1..*
1
1
Operations
public
public
public
public
public
public
public
Attributes
public
public
public
public
Attributes
public void MAJ()
Facture
1..*
mCompte
Carte
public int N°_lot
public String Dés ignation
public Float Prix_ vente
public Float Prix_ d achat
public int N°_lot
public String Dés ign...
public int Quantité
public Float Prix_vente
public Float Prix_d'a...
Operations
public void Affiche()
Operations
public void Affiche()
1
DCI
Attributes
public int N°_DCI
public String DCI
Operations
public void Ajout...
public void Sup()
1
0..1
Prés entation
Attributes
0..1
public int N°_présentati...
public String Présentati...
Operations
public void Ajoute()
public void Sup()
détail com
Attributes
private int N_détcom
private int qte com man...
Operations
1..*
1
1..*
1
Com mande
Attributes
public int N_com
public Date Date_com
Operations
Figure 16
Diagramme de classe
80
4) Vérification avec ArgoUML : cette vérification se fait à l’aide d’un outil de modélisation
sophistiqué ArgoUML, ce choix est justifié (voir chapitre 5), dans la mesure où, il s’agit de
redessiner le modèle précédant et ajouter des contraintes sur les classes (voir Annexe B).
Figure 17
Diagramme de classe avec ARGOUML
81
3.2.2
Processus de l’ECD pour la gestion de pharmacie
Dans ce qui suit, nous allons détailler les différents modules de l’ECD implémentés
séparément et utilisés dans l’expérimentation en cours afin d’en tirer des connaissances pour une
meilleure modélisation assez complète pour mettre en
uvre le futur système de l’application
(Gestion de pharmacie).
Nous nous intéressons plus exactement à la relation (client / pharmacie), car pendant la
collecte des informations, nous avons constaté qu’il existe une sorte d’ambiguïté pour gérer cette
relation, peu d’explications ont été données par le gestionnaire de la pharmacie mais nous
pensons que c’est une forte raison qui nous a poussé à nous concentrer sur cette partie et à
appliquer l’ECD.
3.2.2.1 Première Expérimentation
Commençons par le module de prétraitement qui est une étape essentielle dans le
processus d’ECD. Nous avons fait plusieurs expérimentations sur le choix des champs à
sélectionner, nous allons montrer quelques unes qui ont réussi et bien sûr celles qui sont échoués
et par conséquent rejetés sont dues aux hypothèses insignifiantes dés le départ.
• Sélection : La première phase est la sélection qui consiste à fusionner des champs séparés
appartenants aux différentes tables de notre base de données dont le but est commun. Les
tableaux initiaux qui ont subis ce traitement sont : table client, table carte.
Voila un descriptif de ces deux tableaux et un extrait de chacun d’eux:
82
Nom des champs
Type
N_carte
String
N_client
String
Date_début
Date
Date_fin
Date
Table CARTE
Nom des champs
Type
N_client
Numérique
N_assuré
String
Nom_client
String
Prénom_client
String
Date_naissance
Date
Sexe
Boolean
Tel
String
Adresse
String
Taux_remboursement
String
Conventionné
Boolean
Table CLIENT
Tableau
Extrait de la table Client tiré de la base de données
83
Tableau
Extrait de la table Carte tiré de la base de données
Le choix des champs (attributs) à sélectionner est justifié par nos préoccupations
préalablement mentionnées. Les noms des attributs sont : date_naissance, sexe, adresse, de la
table Client et date_début, date_fin de la table Carte. Les champs de la table engendrée sont :
Date_naissance
sexe
adresse
taux_remboursement
conventionné
date_début
date_fin
1
2
Table 2 :
• Nettoyage : cette phase consiste à traiter les données manquantes : soit en supprimant la
ligne entière, ou en calculant la valeur moyenne, ou en la remplissant par défaut, ou en ayant
recours à l’expert pour saisir l’information oubliée ou finalement lui affecter la valeur nulle. Les
algorithmes correspondants sont faciles à implémenter [KADA 06]. La table précédente ne
contient pas des cellules vides alors nous procédons directement à la transformation. Elle consiste
à coder les différents types de variables vers le type Numérique.
84
Ensuite, cette table doit subir la discrétisation s’il existe des variables continues, une
multitude d’algorithme mais nous avons opté à quelques uns (statistiques) [KADA 06].
Type d’origine
date_début date_fin
Date
taux_remboursement
String
conventionné
Boolean
sexe
Boolean
adresse
String
date_naissance
Date
Opération
Type résultant
Fusionner les deux
Numérique
date en période
Catégories (1, 2, 3)
Numérique
Convetionné à 1
Numérique
Sinon à 2
Féminin à 1
Numérique
Sinon à 2
Oran à 1
Numérique
Sinon à 2
Age
Numérique
Tableau
Préparation de données
Sélection
Discrétisation
Nettoyage
Transformation de
type de données
Traitement des
données manquantes
Remplir par
nulle
Supprime
r
Calculer la
moyenne
Figure 20
Remplir
par défauts
Saisir
l’informatio
n oubliée
Schéma des opérations de préparation de données
85
Un échantillon de la table finale :
Periode
Age
Sexe
Taux_remb
Adresse
Conventionné
1
1
1
2
4
2
1
2
2
2
2
1
1
1
3
1
1
2
1
1
1
4
2
1
2
2
1
2
5
1
1
2
4
1
2
6
1
1
2
3
1
2
7
1
2
1
2
1
2
8
4
2
1
1
2
1
9
3
2
1
2
2
2
10
1
2
2
3
2
1
11
2
1
1
4
2
2
12
1
2
2
4
2
1
13
1
2
1
1
1
2
Tableau
•
Apprentissage Symbolique Automatique (SIPINA) : plusieurs règles sont générées parmi
lesquels nous pouvons énumérer:
1) Si (Sexe = 1) Alors (2)
2) Si (Sexe = 2) & (periode = 2) Alors (1)
3) Si (Sexe = 2) & (periode = 1) & (Age = 3) Alors (2)
4) Si (Sexe = 2) & (periode = 1) & (Age = 2) Alors (2)
5) Si (Sexe = 2) & (periode = 1) & (Age = 1) Alors (2)
•
Interprétation, validation et intégration :
Quelques règles qui sont tirées sont redondantes, et d’autres confirment celles qui sont dans le
cahier des charges. Les nouvelles règles ont besoins d’être validées : deux types de validation
sont impliquées dans cette phase : évaluation par le concepteur (règles générales logiques) et par
l’expert du domaine, dans ce cas, le pharmacien.
86
Les règles validées et vérifiées sont :
1) Si la période de validité de la carte n’est pas terminée et le client est de la classe des
assurés alors le client est conventionné.
2) Si la période de validité de la carte est terminée et le client est de la classe des assurés
alors le client est non conventionné.
3) Si le client est masculin d’âge moyen et la période de validité est non terminée alors le
client est conventionné.
4) Si le client est un vieux masculin et la période de validité est non terminée alors le client
est conventionné.
5) Si le client est masculin d’âge moyen et la période de validité est terminée alors le client
est non conventionné.
Le diagramme de classes résultant du nouveau cahier des charges est obtenu en intégrant
les nouvelles règles validées et vérifiées générées par apprentissage symbolique automatique.
Figure 21
Diagramme de classes après ASA
87
3.2.2.2 Autres Expérimentations
Soit le diagramme de classes de la figure hhhh de l’application (gestion aéronautique) [SLIM
05] :
Figure 22
Diagramme de classes avant ASA
Après une modélisation du système dans la figure jjjj avec la nouvelle démarche qui est :
Modélisation UML guidée par Apprentissage Symbolique Automatique.
Figure 23
Diagramme de classes après ASA
88
5
Conclusion
L’approche que nous avons présentée dans ce chapitre, a permis de réaliser une démarche
de modélisation UML guidée par l’expérience (Apprentissage Symbolique Automatique) grâce à
ses techniques et ses outils.
À travers cette démarche, nous avons pu obtenir quelques résultats :
•
Globalement : une réduction du temps des cycles de développement (processus de
développement UML itératif et incrémental,…). La maîtrise des risques et des coûts dans
la réalisation des systèmes quelconques (temps de développement réduit à coûts réduits
à risques minimisés). Automatisation quasi complète des phases capture et analyse des
besoins de (les interviews, …) vers l’ ECD.
•
Scientifiquement : une contribution aux standards et à la diffusion technologiques
(supports aux actions industrielles), intégration du processus ECD dans les ateliers UML,
enfin une maîtrise de l’ECD pour faciliter son intégration avec les outils UML [BOUD
05].
L’utilisation de l’ECD dans la modélisation des systèmes à base de données a une grande
importance pour les domaines industriels lorsque leurs bases de données augmentent rapidement,
et le recours à l’expertise est une solution aux problèmes et aux situations critiques.
Cette contribution nous a permis d’améliorer la modélisation UML et de faciliter toute
démarche de développement couvrant tout le cycle de vie avec une grande maîtrise des
ressources disponible et pouvoir capitaliser l’expertise du domaine à étudier.
L’approche symbolique a un avantage dû à la facilité d’interprétation des résultats obtenus
pour une intégration réussie dans le processus de développement.
89
90
1
Introduction
Dans ce chapitre, nous présenterons la plateforme sur laquelle repose le développement de
notre démarche et des captures d’écrans des expérimentations sur notre approche ainsi que les
résultats obtenus par la maquette informatique développée que nous commenterons.
2
La plate-forme de réalisation
Modélisation UML par Apprentissage Symbolique Automatique :
2.1 Composition de l’atelier
Dans cette section, nous allons décrire les différents modules et les outils impliqués
pendant la réalisation du système, qui coopèrent dans une démarche UML guidée par
Apprentissage Symbolique Automatique.
Il existe des modules principaux (module de préparation de données, module SIPINA) et
d’autres secondaires (module de stockage de base de données, module ArgoUML).
91
Entre temps, deux acteurs interviennent dans les étapes de traitement de ces modules. Le
concepteur, qui est un acteur principal dans le développement, réagissant avec ces modules dont
le but d’accomplir la tache qui lui était attribuée et l’expert du domaine qui joue un rôle
fondamental dans la vérification et la validation de la cohérence et de la performance de
l’intégrité du système modélisé.
2.1.1 Module de prétraitement de données
Ce module est très complexe car les données ne sont pas directement exploitables. Ces
données nécessitent un temps plus important pour préparer les tableaux à l’entrée du module de
traitement (module Sipina). Ce module comporte des étapes qui s’exécutent successivement et/ou
alternativement si nécessaire.
FIG : Etapes de préparation de données
92
2.1.2
Module Sipina
C’est l’étape la plus importante car c’est là où l’apport de l’ECD se renforce prouvant le
besoin de son intégration dans la modélisation UML. Ce module a été développé par [MEKA 06].
Figure 22
2.1.3
Module SIPINA
Module de stockage de base de données
Lors des phases antérieures du cycle de développement, la conception de la base de
données est essentielle puisque l’ECD l’exploite pour la génération de nouvelles connaissances.
Le modèle physique des données est la traduction du modèle logique des données dans une
structure de données protégée spécifique au système de gestion de bases de données utilisé. Le
SGBD précise l’organisation générale de la base de données permettant le stockage des données
sous forme de tables et les différentes opérations possibles.
93
La base de données est accessible à partir de notre interface utilisateur, qui permet de charger la
base en se connectant avec le SGBD. Cette interface permet de créer une base de donnée à l’aide
du SGBD et d’afficher les noms de toutes les tables ainsi que les noms des champs que contient
chaque table séparément de la base connectée et déjà créée.
Figure 22
3.1.4
Création et connexion à la base de données
Module ArgoUML
Nous pouvons accéder à ce module à partir de l’interface utilisateur. ArgoUML est un
outil de modélisation graphique des modèles UML comme par exemple Together, Visio dont le
plus important est Rational Rose. Il utilise les classes basiques de java qui s’accompagne de OCL
un langage de représentation des contraintes en approche objet (plus de détail voir Annexe B). Il
s’agit d’imposer un cadre formel à l’interprétation de toute expression en UML sans perte de
sémantique. Il peut fonctionner sur toutes les plateformes qui possèdent la machine virtuelle de
JAVA (JWS, ou JAVA WEB START).
94
ArgoUML est un produit sous licence GPL (General Public Licence), cela en fait un programme
libre et gratuit utilisable par les développeurs. Il possède des outils de contrôle qui permettent
d’aider à la modélisation :
• L’ «Auto Critique» qui permet d’avertir des erreurs de syntaxes et propose des
améliorations sans interrompre l’utilisateur. Toutes les remarques sont envoyées dans la liste des
éléments à corriger.
• La liste des éléments à corriger ou à contrôler est présentée en trois niveaux
d’importances: élevée, moyenne, basse.
• La Checklist qui permet de lister tous les points de contrôle dans un développement et
de les valider un à un pour être sur de ne rien avoir oublié.
Figure 22
Module ARGOUML
95
Figure 22
2.1.5
Fenêtre principale du module ArgoUML
Intervention du concepteur et de l’expert
Le concepteur est la personne qui dirige toute l’activité de réalisation. L’expert est
relativement impliqué dans cette démarche : deux sortes d’expert peuvent participer à la
validation et à la vérification :
•
Un expert du domaine (comme exemple : expert pharmacien) qui coopère avec le
concepteur pour inspecter le contexte général de l’application (pharmacie) (surtout sur les
nouvelles connaissances à intégrer) ;
•
Un expert de modélisation qui fait des remarques sur le modèle UML fourni et sur les
changements à accomplir lors de l’intégration.
Nous pouvons dire que la validation des deux experts est partielle et qu’il reste encore de
travail à réaliser.
96
3
L’organigramme de la plate-forme
Modélisation
Module stockage
de base de données
Module ArgoUML
Table
Modèle de Classes
Affichage des Classe
Sélection d’une classe
Affichage des classes de relation
Choix d’une Classe
Affichage des attributs de la classe choisie de relation
Choix des attributs
Affichage des attributs de la classe choisie
Non
Si c’est le dernier
attribut
Oui
Sélectionné des attributs de la classe choisie
Afficher
Une nouvelle Table
Statistique
Module de préparation
de base de données
Module SIPINA
Modification
Analyse
Figure : Organigramme Générale
97
4
L’environnement d’implémentation
Notre choix est basé sur deux critères fondamentaux :
•
La programmation sous environnement Windows qui offre des avantages telle : une
interface graphique conviviale. Il s’agit d’une révolution pour les programmeurs qui ont
su tirer partie des concepts de l’orienté objet appliqué à la micro-informatique.
•
La programmation orientée objet bien supportée par le compilateur java est l’un des
langages de programmation parmi les langages les plus utilisés actuellement. Il est à la
fois facile à utiliser et très efficace. Il souffre cependant de la réputation d’être complet et
utilisable. Cette réputation est en partie justifiée.
4.1 Langage de programmation JBuilder version X
JBuilderX est un outil de développement puissant pour la programmation des applications
sous Windows. JBuilderX, est un logiciel Borland, qui offre une librairie très riche de classes qui
exploitent les notions de la programmation orientée objet. Il génère un fichier exécutable capable
de fonctionner seul, sans bibliothèque complémentaire, ce qui augmente en conséquence la
vitesse d’exécution des programmes et permet d’utiliser des logiciels sur le web sous forme (jar).
4.2 WINDOWS XP
Nous avons développé notre atelier sous WINDOWS XP avec comme langage de
programmation JBuilderX. La machine utilisée a été dotée d’un microprocesseur Pentium M et
une RAM de capacité de 512Mo, cette configuration a été largement suffisante pour réaliser cet
atelier en un temps d’exécution performant.
4.3 Modeleur UML : ArgoUML
Les exécutables d'ArgoUML étant disponibles sur le web, il est possible de l’utiliser pour
modéliser les applications. De plus, ArgoUML dispose d'un système de chargement de modules
permettant à n’importe quel utilisateur de développer avec ArgoUML.
98
5
Conclusion
Dans ce chapitre, nous avons montré les différents modules et les outils impliqués dans la
réussite de la démarche proposée qui constituent la plate-forme de l’atelier. Tous ces modules
représentent les éléments essentiels pour achever le processus de modélisation UML guidée par
apprentissage automatique symbolique.
Nous avons vu aussi comment ces outils répondent aux besoins attendus, comment leurs
manipulations ont rendu l’intégration de l’ECD facile et souple. Toutefois, ces outils peuvent être
remplacés par d’autres répondant mieux aux exigences de l’application pour aboutir aux résultats
voulus.
Les éléments principaux d'innovation dans ce processus de modélisation sont de deux
ordres. Le premier est évident et est toujours rappelé comme justification des approches
informatiques : il s'agit de la méthodologie de modélisation UML, c’est-à-dire : suivre les étapes
de processus de développement. Le deuxième, que l'on considère comme plus intéressant ici, est
l'introduction de l’ECD à travers cette démarche d'un autre point de vue sur le problème étudié.
Les différentes étapes de traitements dans la démarche proposée nécessitent une connaissance
suffisamment approfondie pour pouvoir les utiliser correctement.
99
100
UML est une technique plus générique, avec les avantages et les inconvénients que cela
implique, elle ne force pas l’utilisation de certains concepts qui peuvent s’avérer très importants
dans la modélisation de processus, entraînant ainsi une perte d’information ou la création de
modèles incomplets, mais elle est par contre flexible et extensible, ce qui permet à ses utilisateurs
de l’adapter précisément à leurs besoins.
Dans le cadre de cette thèse, nous avons proposé une démarche de modélisation UML
guidée par l’apprentissage automatique symbolique afin d’optimiser l’utilisation de la base de
données pour un meilleur résultat. Dans une tentative d’automatiser la phase d’analyse, cette
approche représente un apport performant dans la modélisation. L'automatisation quasi-complète
des phases de capture et d’analyse apparaît comme une solution de plus en plus souhaitable avec
la montée en complexité des problèmes modélisés.
Cette automatisation nécessite des techniques et des outils puissants pour la fouille de
données ainsi que pour la modélisation UML. Ces techniques raffinent le modèle de l'application
et les changements liés à l'implantation de cette application. Il est évident que ces techniques
monopolisent l'attention du concepteur et lui évitent de se focaliser sur des activités annexes et
sans intérêt pour la conception de l'application [BOUD 05].
Nous avons donc proposé, lors de cette thèse, une solution permettant d'enrichir le cahier
des charges pour une modélisation complète en faisant extraire des connaissances à partir de
données propres au domaine d’application. Notre approche est fondée sur les techniques de
fouille de données, plus précisément l’approche symbolique illustrée par l’algorithme Sipina pour
sa facilité à interpréter les résultats fournis.
Ce mémoire a présenté la faisabilité d’une méthodologie de modélisation UML. Utilisant
une approche dite de fouille de données, cette méthodologie propose de travailler directement sur
la base de données et les phases préliminaires produites par le développeur.
101
De ce fait, cette méthodologie est capable de s’inscrire de manière non-intrusive dans les
méthodes de conception actuellement pratiquées par les industriels. En effet l’application de la
démarche proposée ne nécessite pas de la part du développeur qu’il soit expert en méthodes
d’extraction de connaissances. De surcroît, cette méthodologie permet de répondre au principal
problème rencontré à la fin du cycle de développement, à savoir la coopération entre les
approches expérimentales et les approches déjà existantes. Ainsi, cette méthodologie permet de
capturer les besoins de l’utilisateur de manière rapide, ce à que les propositions actuelles dans le
domaine permettent difficilement de réaliser.
Nous avons testé notre approche sur plusieurs bases de données différentes et les résultats
obtenus sont intéressants. Un des avantages de notre approche est lié au volume de règles
proposées à l'expert. En contre partie, nous ne sommes pas en mesure d'extraire de manière
exhaustive toutes les règles utiles contenues dans les données.
Les résultats obtenus sur les applications exposés ont montré que notre démarche
proposée a prouvé son efficacité nettement plus que ceux obtenus par la démarche de
modélisation classique, sachant que notre approche utilise un support identique pour la
modélisation à celui de l’approche classique. L'évaluation de l'intérêt des règles obtenues à partir
des données n'est pas aisée car peu d'experts s'intéressent vraiment à ces données.
Enfin nous proposons plusieurs perspectives de recherche proches des thématiques
développées dans cette thèse :
•
Une extension de notre travail concernant l’application Pharmacie.
•
Validation de la démarche sur des autres applications réelles et autres artificielles dans des
différents domaines médicales, industrielles,…
•
Développement d’une interface conviviale intégrée (le côté diagramme d’UML et la
représentation graphiques des règles obtenues par apprentissage automatique).
Finalement des développements par rapport à la discrétisation, les modeleurs UML, les règles de
productions et différents types de bases de données.
102
103
[ABDI 94]
H. ABDI,
Les Réseaux de Neurones.
Editions PUG (Presses Universitaires de Grenoble),
Collection ‘Sciences et Technologies de la Connaissance’ ,1994.
[BENA 01]
J. BENARD
Extreme programming – Méthodes Agiles : l’état des lieux.
White paper © Business Interactif, 2001.
[BISH 95]
C. BISHOP
Neural networks for pattern recognition.
Clarendon Press, 1995.
[BODE 02]
J. P. BODEVEIX., T. MILLAN, C. PERCEBOIS, C. LE CAMUS, P. BAZEX, L. FERAUD, et
SOBEK
Extending OCL for verifying UML models consistency, UML 2002 Workshop on “Consistency
Problems in UML-based Software Development in Blekinge Institute of Technology”,
Research Report, 2002.
[BOOC 00]
G. BOOCH, J. RUMBAUGH et I. JACOBSON
Guide de l'utilisateur UML.
Ed. Eyrolles, 2000.
[BOUD 03]
C. BOUDIA, H. DAHMANI
APPRENTISSAGE AUTOMATIQUE SYMBOLIQUE : La sensibilité du graphe d’induction à
la taille de l’échantillon et aux paramètres,
Projet de Fin d’Études, Centre universitaire de Mascara, 2003.
[BOUD 05]
C. BOUDIA, B. ATMANI et B. BELDJILALI
Retro design and UML modeling by Machine Learning.
In Proceedings of the International Arab Conference on Information Technology (ACIT’05),
Jordanie, 2005.
[BRES 01]
L.A. BRESLOW, D.W. AHA et H. MUÑOZ-AVILA
Conversational case-based reasoning ,
Applied Intelligence, 2001.
[CHAR 99]
RICHTER, CHARLES
Designing flexible object-oriented systems with UML.
Macmillan, 1999.
[CHAU 98]
SURAJIT CHAUDHURI.
Data mining and database systems: Where is the intersection?
Data Engineering Bulletin, 1998.
[CHAU 02]
JEAN-HUGUES CHAUCHAT
Echantillonnage, validation et généralisation des connaissances à partir de données.
Université Lumière Lyon 2,
France, 2002.
[CHER 98]
V. CHERKASSKY et F. MULIER
Learning from data: Concepts, theory and methods.
Ed. Wesley Interscience, 1998.
[CLAV 04]
ANTOINE CLAVE
D'UML à MDA : En passant par les méta modèles
Articles pour la « Lettre de l’Adeli ».
France, 2004.
[CODD 93]
E. F. CODD
Providing OLAP (on-line analytical processing) to user analysts: An it mandate.
Rapport technique, E.F. Codd et Associés, 1993.
[CORN 04]
A. CORNUÉJOLS et L.MICLET
Apprentissage Artificiel : Méthodes et Algorithmes
Ed. Eyrolles, 2004.
[DAHM 04]
DAHMANI. Y
Navigation d’un robot mobile dans un environnement inconnu : contribution du Q-learning flou
Thèse Doctorat d’état en Informatique, Université des sciences et des technologies d’Oran
Mohamed Boudiaf 2004.
[DAVO 01]
PAULE-ANNICK DAVOINE
Modélisation UML et outils pour l’analyse spatiale
LSR-IMAG, SIGMA team,
Institut polytechnique de Grenoble, 2001.
[DECO 01]
BERNARD DECOURBE
Modélisations des processus d'affaires Perspectives d'utilisation de la méthode UMM pour les
échanges électroniques professionnels.
France, 2001.
[DELO 02]
JEAN-MICHEL DELORME
L’apport de la fouille de données dans l’analyse de texte.
Conservatoire National des Arts et Métiers
Centre régionale de Montpellier, 2002.
[DESF 04]
PHILIPPE DESFRAY
Réussir la modélisation UML des phases amont. Techniques de « pré-Modélisation » : un pont
vers le modèle.
White paper © Softeam 2004.
[DOMI 04]
A. DOMINIQUE
L’utilisation d’UML
White paper © Softeam 2004.
[DREY 04]
GÉRARD DREYFUS
Modélisation par apprentissage d'un nouvel outil de diagnostic des gisements de pétrole.
Thèse CIFRE Schlumberger-ESPCI, Laboratoire d'Electronique/ESPCI
Université Paris 6, France, 2004.
[DUPR 04]
A. DUPRAT et G. DREYFUS
Étude d’un nouvel outil d’aide à la découverte de médicaments par modélisation et
apprentissage.
Laboratoire d'Electronique/ESPCI
Université Paris 6, France, 2004.
[EVAN 98]
A. S. EVANS et A. N. CLARK,
Foundations of the Unified Modeling Language
Proceeding of the 2nd Northern Formal Methods Workshop,
Springer-Verlag, 1998.
[FAVR 03]
CÉCILE FAVRE
Utilisation des index Bitmap pour la fouille de données.
Mémoire DEA, Laboratoire ERIC, Université Lyon 2.
France, 2003.
105
[FERN 00]
J. L. FERNÁNDEZ, A. TOVAL et J. R. HOYOS,
Rigorously Transforming UML Class Diagrams,
Proceeding of V Spanish Conference on Software Engineering and Database,
University of Valladolid, 2000.
[FLAK 01]
S. FLAKE, W. MUELLER
An OCL Extension for Real-Time Constraints.
In T. Clark, J. Warmer(eds), Advances in Object Modeling with the OCL,
Ed. Springer Verlag, 2001.
[FRAW 96]
U. FRAWLEY, G. PIETSKI-SHAPIRO, et P. SMYTH.
Knowledge discovery and data mining: Towards a unifying framework. In Proceeding of the
Second International Conference on Knowledge Discovery and Data Mining, 1996.
[FOWL 97]
FOWLER, MARTIN, KENDALL et SCOTT
UML Distilled: Applying the Standard Object Modeling Language,
Ed. Addison-Wesley, 1997.
[GUIS 96]
GIUSEPPE PSAILA, ROSA MEO et STEFANO CERI
A new sql-like operator for mining association rules.
In 22th International Conference on Very Large Data Bases, Morgan Kaufmann, 1996.
[GOLD 89]
D. GOLDBERG
Genetic Algorithm In Search, Optimization And Machine Learning.
Addison-Wesley, 1989.
[HAYK 99]
S. HAYKIN
Neural netwoks. A comprehensive foundation.
Ed. Prentice Hall, 1999.
[HAZA 05]
DOMINIQUE HAZAËL, MASSIEUX et DAN CONNOLLY,
Gleaning Resource Descriptions from Dialects of Languages (GRDDL), World Wide Web
Consortium, W3C Team Submission SUBM.2005.
[HOLL 75]
J. H. HOLLAND
Adaptation In Natural And Artificial Systems.
University of Michigan Press, 1975.
[JACO 92]
I. JACOBSON, M. CHRISTERSON, P. JONSSON, et G. ÖVERGAARD
Object-Oriented Software Engineering: A Use Case Driven Approach,
Ed. Addison-Wesley, 1992
[JERO 03]
JÉRÔME AZÉ
Extraction de connaissances à partir de données numériques et textuelles.
Université of Paris-Sud, France, 2003.
[KADA 06]
KADA BENFODDA SAMIRA, SAIM KADARIA
Modélisation UML guidée par l’expérience.
Projet de fin d’études, université d’Oran, 2006.
[KODR 93]
Y. KODRATOFF, R.S. MICHALSKI, J.G. CARBONELL et M. MITCHELL
Apprentissage Symbolique : Une Approche de l'Intelligence Artificielle
Ed. CEPADUES, France, 1993.
[KODR 97]
Y. KODRATOFF
L'extraction de connaissances à partir de données : un nouveau sujet pour la recherche
scientifique. Revue électronique R.E.A.D, 1997.
106
[KRUC 03]
P. KRUCHTEN, P. KROLL
Guide pratique du RUP.
CampusPress, 2003.
[LEBL 04]
PHILIPPE LEBLANC
Développement basé sur la modélisation UML 2.0
Rapport Technique
White paper © Telelogic, 2004.
[LEFE 01]
LEFÉBURE et VENTURI
Data Mining
Ed. Eyrolles, 2001.
[MATE 01]
P.F. MARTEAU & ALL
PROJET APRIME, 2001.
[MAHO 91]
RAYMOND J MOONEY, J. J MAHONEY
Initializing ID5R with a Domain Theory: Some Negative Results
Technical Report:
University of Texas at Austin, USA, 1991.
[MEKA 06]
A.MEKAMI, L. RAHLI
Extraction de connaissances à partir des bases de données XML.
Projet de fin d’études,
Université d’Oran, 2006.
[MICH 00]
MICHEL LAI
Penser objet avec UML et JAVA : 2ème edition
Ed. Dupod, 2000.
[MITC 97]
T.M. MITCHELL
Machine Learning. Computer Science
Publisher: McGraw-Hill, New York, 1997
[MOUL 97]
I. MOULINIER
Apprentissage et Acquisition de Connaissances.
Thèse de doctorat,
Université Paris VI, 1997.
[MULL 04]
PIERRE-ALAIN MULLER et NATHALIE GAERTNER
Modélisation Objet avec UML.
Ed. Eyrolles, 2004.
[NAUL 98]
ELIE NAULLEAU
Apprentissage et Filtrage Syntaxico-Sémantique de Syntagmes Nominaux Pertinents pour La
Recherche Documentaire.
Thèse de doctorat, université de Paris XIII, 1998.
[NEDE 00]
C. NÉDELLEC
Knowledge Extraction from Text, a Machine Learning Approach
In Proceedings of the Third International Conference on Human-System Learning, CAPS'3,
France, 2000.
[OLIV 02]
OLIVIER GLASSEY, JEAN-LOUP CHAPPELET
Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML,
UER: Management public / Systèmes d'information, l'IDHEAP ? France, 2000.
107
[OMG 99]
OMG
OMG Unified Modeling Language Specifications. Version 1.3.
Technical Report
OMG, 1999.
[PAQU 97]
G. PAQUETTE, F. CREVIER et C. AUBIN
Méthode d'ingénierie d'un système d'apprentissage (MISA),
Revue Informations In Cognito.
USA, 1997.
[POPI 00]
FABRICE POPINEAU
Introduction à la conception Orientée Objet et à UML
2000.
[QUIN 93]
J.R. QUINLAN
C4.5: Programs for machine learning.
Morgan Kaufmann Publisher, 1993.
[KONO 88]
I. KONONENKO, B. CESTNIK, et I. BRATKO,
Assistant Professional
User's Guide, 1988.
[REGE 03]
DAN REGEP
LfP : un langage de spécification pour supporter une démarche de développement par
prototypage pour les systèmes répartis.
Thèse de doctorat de l’université Pierre et Marie Curie, Paris VI, 2003.
[REGG 99]
REGGIO, R. J. WIERINGA
Thirty one Problems in the Semantics of UML 1.3 Dynamics
Workshop Rigorous Modeling and Analysis of the UML Challenges and Limitations,
OOPSLA’99,
Denver, CO, 1999.
[REMI 00]
R. RÉMI, T. MARC
Découverte de connaissances à partir de données.
Thèse de doctorat en Informatique.
France, 2000.
[RENA 05]
D. RENAUDIE
Méthodes d'apprentissage automatique pour la modélisation de l'élève en algèbre.
Thèse de doctorat en Informatique.
Institut National Polytechnique de Grenoble, 2005.
[ROQU 03]
PASCAL ROQUES, FRANK VALLÉE
UML en action.
Ed. Eyrolles 2003.
[ SARA 98]
SUNITA SARAWAGI, SHIBY THOMAS, et RAKESH AGRAWAL.
Integrating mining with relational database systems: Alternatives and implications.
In ACM SIGMOD International Conference on Management of Data (SIGMOD 98).
USA, 1998.
[SLIM 06]
SLIMANI NASSIMA, ZIANE CHERIF MOHAMED
Conception et réalisation d’un système d’extraction de connaissances à partir des BDD : (Etude
comparative avec Tanagra et Sipina)
Projet de fin d’études, Université d’Oran, 2006.
108
[SLIM 05]
SLIMANI NADERA et MEBARKIA S. BOUBAKEUR
Modélisation UML guidée par l’extraction des connaissances à partir d’une BDD.
Projet de fin d’études,
Université d’Oran, 2005.
[SKAL 84]
J.M. SKALKA, B. ROY
ELECTRE IS - ASPECTS MÉTHODOLOGIQUES ET GUIDE D'UTILISATION.
Document du LAMSADE
Université de Paris-Dauphine, 1984.
[TALE 06]
S. TALEB ZOUGGAR
Graphes d’induction et réseaux de neurones, une nouvelle technique hybride pour la sélection et
la segmentation des données.
Thèse de Magister, université d’Oran, 2006.
[ UDRE 98]
C. UDRÉA, F. BENTAYEB, J. ARMONT et O. BOUSSAID
Préparation des données pour une intégration efficace de méthodes de fouille de données dans
les sgbd.
Technical report, Laboratoire ERIC - Université Lyon 2, 2003.
[VAUQ 04]
DOMINIQUE VAUQUIER
Les six impasses de la conception des processus Vers une alternative à l'approche fonctionnelle
Article pour la « Lettre de l’Adeli »
France, 2004.
[VILLA 00]
M.VILLANOVA
Modélisation UML pour les systèmes d’information dédiée aux risques naturels
Colloque act SIRNAT,Cemagref, IMAG,
Grenoble, 2000.
[WARM 03]
JOS WARMER , ANNEKE KLEPPE,
The Object Constraint Language: Getting Your Models Ready for MDA,
Second Edition, Addison-Wesley, 2003
[WITT 01]
WITTEN, FRANK.
Data Mining: practical machine learning tools and techniques with Java Implementations.
Morgan Kaufmann Publisher.
USA, 2001.
[ZIGH 85]
D.A. ZIGHED
Méthodes et outils pour les processus d’interrogation non arborescents.
PhD thesis, Université Claude Bernard, Lyon 1,1985.
[ZIGH 92]
D.A. ZIGHED, J.P.AURAY et G.DURU
SIPINA : Méthode et Logiciel.
Lacassagne, 1992.
[ZIGH 02]
D.A. ZIGHED, R. RAKOLOMALALA
Extraction de connaissances à partir de données (ECD).
In Techniques de l’Ingénieur,
volume HA, 2002.
[ZIGH 00]
D.A. ZIGHED, R. RAKOLOMALALA
Graphe d’induction: Apprentissage et Data Mining.
Ed. Hermes Sciences, France, 2000.
109
110
Description du cahier des charges
Le cahier des charges est décris comme suit :
Il est sectionné sur trois gestions :
I. Gestion de stock des médicaments.
Les informations sur les produits « base des données »
1. Un produit possède à un nom.
2. Un produit appartient à une seule classe thérapeutique.
3. Il existe plusieurs classes thérapeutiques.
4. Un produit possède à un prix fixe.
5. Un produit possède plusieurs catégories (comprime, sirop,..).
6. Un produit possède une seule notice.
7. Chaque produit possède un code.
8. Il existe deux types de produit (remboursable, non remboursable).
9. Un produit possède (date de fabrication +date d’expiration).
10. Un produit peut pour les adulte ou enfant ou les deux.
11. Mise à jour des produits (vérification sur date d’expiration).
12. Si un produit est périmé dons il faut mettre dans le stock périmé.
13. Enregistrement des sortie des produit et l’entrée.
14. chaque produit possède un taux remboursable (100,0).
II. Gestion réception « pharmacie --- Patient »
Patient
1. il existe deux type de patient : paiement par une carte, paiement par argent, et nous
concerne le patient paiement par carte.
2. Un patient possède une seule carte, mais une carte peut contient plusieurs patient.
3. chaque patient possède ou moins une ordonnance.
4. chaque patient conventionné avec une seule pharmacie.
III. La gestion externe
111
« Pharmacien ------ fournisseur »
1. pharmacie faire une commande de produit au fournisseur.
2. pharmacie faire un aux plusieurs commandes avec des fournisseurs différents au même
fournisseur.
3. Un fournisseur peut fourni plusieurs produits différent dans même commande.
4. Une commande peut concerne un ou plusieurs produit, mais un produit ne peut être
présente plusieurs fois dans même commande.
5. fournisseur délivrent la facture.
6.
la facture contient un ou plusieurs produits.
7. pharmacien contrôle la facture.
8. pharmacie envoie un seul chèque à une seule commande.
« Pharmacien -----CNAS »
1.CNAS envoie à la pharmacie le logiciel de CNAS
2.CNAS envoie à la pharmacie la liste des produits remboursable avec leur taux de
remboursement.
3.pharmacien remplit les imprimés de chaque patient utilisant la carte.
4.pharmacie envoie à CNAS les dossiers des patients et une liste du totale des dossiers des
patients.
5. CNAS contrôle la liste et les dossiers des patients.
6. CNAS rembourse à la pharmacie.
« Pharmacie -----comptable »
1.pharmacie choisie un seul comptable pour faire bilan général mensuel, annuel.
2. pharmacie envoie entré /sortie.
3.comptable établit le bilan général et il envoie à la pharmacie.
« Pharmacie -----IMPÔT »
1.IMPÔT envoi un taxe à la pharmacie.
2.pharmacie envoie le chèque.
112
Identification de pharmacie : il s’agit d’introduire les informations identifiant votre Pharmacie,
à savoir : (Nom Pharmacie (Obligatoire), Adresse Pharmacie, Tél ou Fax, Numéro du Registre de
Commerce, Comptes Bancaires)
Identification de pharmacien : Le pharmacien et ses collègues doivent pouvoir consulter et
manipuler la liste des utilisateurs (pharmaciens) qui seront identifiés par : (Id pharmacien, Mot
Passe, Nom Pharmacien, Prénom pharmacien, Date de naissance, Grade, Adresse Pharmacien,
Tél Pharmacien)
Le Stock :
♦ Pharmacien doit pouvoir voir son stock complet sous forme d’un tableau
avec une indication sur le nombre de produits.
♦ la liste de
DCI = Dénomination Commune Internationale, ou nom du
principe actif du médicament.
♦ La liste des formes des médicaments.
♦ La liste famille d’article (type de Produit).
Exemple : médicament,
parapharmaceutique.
♦ Lot :
♦ Liste des Lot périmés : si un produit dépasse la date Présomption, supprimer
cette produit qui trouver dans le stock et ajoute dans la liste des produit périmés.
♦ Liste des Lot Bloque
Médicaments : Le pharmacien
doit pouvoir ajouter des médicaments au stock avec leurs
données (désignation, forme c’est à dire le type du médicament, le prix unitaire de vente, le prix
unitaire d’achat et la quantité présente initialement,N_Lot,Remboursable (oui,non)).
(Lot : c’est le numéro de lot associé au produit)
♦ Chaque Désignation correspond à un désignation de DCI.
Entrée en Stock : Fractionnée en deux parties
Partie 1 :
♦ N°Entrée : représente le numéro du bon, il peut être généré automatiquement si
l’option de numérotation automatique a été choisie.
♦ Date Entrée : c’est la date de réception de la marchandise
113
♦ Fournisseur : c’est le code fournisseur à partir duquel l’achat s’est effectué.
Partie 2 :
♦ Détails Entrée : il fout enregistrer dans un Tableau
♦ produit : Code de l’article en entrée
♦ N° Lot : c’est le numéro de lot associé au produit reçu.
♦ Date Péremption : c’est la date à laquelle le produit se périme.
♦ Qte Entrée : c’est la quantité reçue.
♦ Prix d’Achat : c’est le coût d’achat chez le fournisseur
♦ Prix de vente : c’est le prix de vente du produit.
♦ Marge : calculée automatiquement par le système, elle représente la différence
en pourcentage entre le prix d’achat et le prix de vente.
Sortie en Stock : Fractionnée en deux parties :
Partie 1 : regroupe tout les sortie des produit
♦ N°Sortie : représente le numéro Sortie, il peut être généré automatiquement si
l’option de numérotation automatique a été choisie.
♦ Date Sortie : c’est la date de sortie.
♦ Type sorti :
Partie2 : Détails de chaque Sortie :
♦ Produit : Code de l’article en sortie
♦ N° Lot : c’est le numéro de lot associé au produit sorti.
♦ Date Péremption : c’est la date à laquelle le produit se périme.
♦ Qte sortie : c’est la quantité sortie.
♦ Prix d’Achat : c’est le coût d’achat chez le fournisseur, il est affiché par défaut.
♦ Prix de vente : c’est le prix de vente du produit.
Fournisseur : (Nom, Raison sociale, Adresse, Pays, Tel / Fax, N° Registre, Catégorie)
Catégorie : Pharmacien ou Grossiste : cette information est importante surtout lorsqu’il y a des
échanges de produits.
114
Commande : Pour assurer l’approvisionnement du stock, tous les médicaments vendus doivent
être ajouté à la commande courante qui est la commande contenant tous les médicaments vendus
après la dernière commande effectuée. L’utilisateur doit pouvoir consulter cette commande
courante et la modifier.
Le pharmacien commande des médicaments selon stock.
Le fournisseur acquis la commande du pharmacien, il envoie la facture
Facture : Fractionnée en deux parties :
Partie 1 : regroupe tout les facture, contient :
♦ Les numéros de facture
♦ Date facture
♦ Les références clients (fournisseur)
♦ Les montants d’achat
♦ Les montants de vente.
Partie2 : contient les détails de chaque facturée tel que :
♦ Les désignations des articles de chaque facture,
♦ Le numéro de lot de chaque produit,
♦ La date de péremption, …etc.
Client : Il y’a deux type de client, conventionnés (assurés) et non conventionnés.
Client conventionné : il fout enregistrer dans une liste des clients avec ces informations :(Id
client, Nom client, Prénom client, Date de naissance, Catégorie de client, Adresse client, Tél
client), Chaque client conventionné possède une carte : (Id client, Date début de carte, Date fin de
carte). Pour chaque ordonnance on construire un dossier :
♦ Ordonnance
♦ Remplir les imprimés
♦ Ajout le client dans cette période a la liste des clients avec son Montant.
♦ Envoie au service CNAS.
CNAS : remboursé tout les médicament remboursable.
Après l’arrivé des dossiers des client au niveau de CNAS et contrôle, la CNAS envoie un chaque
à pharmacie. Le schéma suivant illustre les tâches de pharmacie avec autre service :
115
Le cahier des charges :
1. chaque article possède un code.
2. chaque article possède un (e) (désignation, dosage, unité, présentation, famille, d’article).
3. chaque article a son n de lot.
4. chaque article possède un prix (P.P.A).
5. chaque article est un présent dans le dictionnaire.
6. chaque article possède une seule désignation de DCI.
7. il existe plusieurs représentations d’article (CP : comprimé, FL : flacon, …)
8. il existe deux types d’article (remboursable, non remboursable).
9. chaque article possède (date de fabrication + date d’expiration).
10. chaque client conventionne possède une carte.
11. chaque carte possède une date début et une date fin.
12. un client possède une seule carte, et une carte peut contenir plusieurs clients.
13. chaque client dispose au moins d’une ordonnance.
14. chaque client est conventionné avec une seule pharmacie.
15. chaque client possède un taux de remboursement (100,0).
16. si un client est conventionné alors il possède un taux de remboursement égale à 100.
17. si un client est non conventionné alors il possède un taux de remboursement égale à 0.
18. la pharmacie commande des articles des fournisseurs (bon de commande).
19. la pharmacie peut faire une ou plusieurs commandes avec des fournisseurs différents.
20. la commande contient un ou plusieurs articles.
21. un article ne peut être présenté plusieurs fois dans une même commande.
22. le fournisseur délivre la facture.
23. la facture contient un ou plusieurs articles.
24. le pharmacien contrôle la facture.
25. le pharmacien envoie le chèque au fournisseur.
26. chaque pharmacie possède un compte.
27. chaque compte possède un (e) (N compte, Solde, Date de création).
28. à chaque facture correspond une somme de paiement.
29. si le client est conventionné et possède une carte alors il sera remboursé par la CNAS.
116
30. chaque ordonnance tient au moins un article.
31. si un lot dépasse la date de péremption alors il doit être ajouté aux lots périmés et
supprimé du stock.
32. si un lot est bloqué alors il doit être ajouté aux lots bloqués et supprimé du stock.
Quelques extraits de différents diagrammes UML pour la gestion de pharmacie
Digramme Cas utilisation
Carte
Patient
Ordonnance
Pharmacien
Enregistrer
CNAS
Fournisseur
Remplir
le chèque
BANQUE
Comptable
Taxes signés
IMPÔT
117
Diagramme de séquence
: Patient
: Pharmacien
: Fournisseur
: CNAS
Déposer la carte
Déposer l’ordonnace
Vérification sur le stock
Commande des produits non disponibles
Enregistrer ()
Assurer les médicaments
Feuille de maladie (Num)
Construire les dossiers (Num)
la Commande Envoyé
Délivrance des factures
Contrôle la facture ()
Chèque envoyé
Envoyer les dossier ()
Chèque de remboursement
Envoyé liste des produits remboursable ()
118
Diagrammed’activité
Pharmacien
Départ
CNAS
Remplier les
imprimés
Construire
le dossier
Dossier
Vérification sur les
dossiers
Dossier
Arriver
Envoyer les
dossiers
[Réglées]
Dossier
retourné
Oui
Non
correcte
Remboursé :
Chèque
Chèque
Arrive
Fin
Envoyer le dossier
(retourne)
Envoyer chèque
Etat d’objet
Couloir d’activité
Activité
Diagramme de collaboration
1 : établir
: Commande
2 : envoi
Pharmacien
Fournisseur
3 : Délivre
4: envoi
: Facture
5 : contrôle
6 : remplir un chèque
: Chèque
7: envoi
119
OCL : Object Constraint Language
Cela résume de manière synthétique mais incomplète et très informelle les principales caractéristiques du langage
OCL.
Pour plus de précision, se reporter au document de référence UML.
Types des identificateurs utilisés ci-dessous
c : Collection(T)
i : Integer
st: Set(T)
r : Real
bg : Bag(T)
b : Boolean
sq : Sequence(T)
s : String
Constructions syntaxiques
ct
id
self
e op e
e. id
e . pt ( e, ... , e )
c -> pt ( e, ..., e )
os : OrderedSet(T)
t : Tuple(…)
id: identificateur
pt: property
cs: constant
pd : predicat
e : expression
ns: namespace
ns:: ... ns::id
if pd then e else e endif
let id = e : T, id2 = e:T, ... in e2
Types, valeurs et opérations dans la bibliothèque standard
1, -5, 34
i+i2, i-i2, i*i2, i.div(i2), i.mod(i), i.abs, i.max(i2), i.min(i2), <, >, <=, >=
Integer
1.5, 1.34, ...
r+r2, r-r2, r*r2, r/r2, r.floor, r.round, r.max(r2), r.min(r2), <, >, <=, >=
Real
true, false
not b, b and b2, b or b2, b xor b2, b implies b2
Boolean
s.size(), s.concat(s2), s.substring(i1,i2), s.toUpper(), s.toLower(), s.toInteger(), s.toReal()
'', 'une chaine'
String
Jour::Lundi,
=, <>
Enumeration
Jour::Mardi, …
t.x
Tuple { y : T2 = …,
TupleType( x :
t.y
x=…,
T1,
t.z
z=…}
y : T2,
z : T3 )
c->size(), c->includes(o), c->excludes(o), c->count(o), c->includesAll(c2)
Collection(T)
c->excludesAll(c2), c->isEmpty(), c->notEmpty(), c->sum()
c->exists(p), c->forall(p), c->isUnique(e), c->sortedBy(e), c->iterate(e)
Set {1,5,10,3}, Set{}
st->union(st2), st->union(bg), st->intersection(st2), st->intersection(bg)
st - st2, st->including(e), st->excluding(e), st->symmetricDifference(st2)
st->select(e), st->reject(e), st->collect(e), st->count(e), st->flatten(),
st->asSequence(), st->asBag()
Bag(T)
Bag {1,5,5}
Bag {}
bg->union(bg2), bg->union(st), bg->intersection(bg2), bg->intersection(st)
bg->including(e), bg->excluding(e), bg->count(e), bg->flatten()
bg->select(e), bg->reject(e), bg->collect(e)
bg->asSequence(), bg->asSet()
OrderedSet(T)
OrderedSet{10,4,3}
OrderedSet{}
Sequence{5,3,5}
Sequence{}
…
Set(T)
Sequence(T)
sq->count(e), sq->union(sq2), sq->append(e), sq->prepend(e), sq->insertAt(i,o)
sq->subSequence(i1,i2), sq->at(i), sq->first(), sq->last(), sq->indexOf(o)
sq->including(e), sq->excluding(e)
sq->select(e), sq->reject(e), sq->collect(e), sq->iterate(e)
sq->asBag, sq->asSet
120
121