REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIREMINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUEUNIVERSITE D’ORAN ES-SENIA

FACULTE DES SCIENCESDEPARTEMENT D’INFORMATIQUE

MEMOIRE

Présenté par

Melle Chérifa BOUDIA

Pour obtenir

LE DIPLOME DE MAGISTER

Spécialité InformatiqueOption : Informatique et Automatique

Intitulé :

Soutenu le : à la salle de conférences de la faculté des sciences

Devant les membres du jury:

M. M. K. RAHMOUNI Professeur, Université d’Oran, ES-Sénia, Algérie(Président)

M. A. BENYETTOU Professeur à l’USTO Mohamed Boudiaf, Oran, Algérie(Examinateur)

M. A. LEHIRECHE Maître de Conférence, Université de Sidi-bel-abbes, Algérie(Examinateur)

M. K. BOUAMRANE Docteur, Université d’Oran, ES-Sénia, Algérie(Examinateur)

M. B. BELDJILALI Professeur, Université d’Oran, ES-Sénia, Algérie(Rapporteur)

M. B. ATMANI Chargé de cours, Université d’Oran, ES-Sénia, Algérie(Rapporteur)

Étude et mise en pratique d’une démarche

de modélisation (UML)

par Apprentissage Symbolique Automatique

2

L écriture d une telle page n est pas une tâche aisée. Bien sûr, des noms viennentimmé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é estreine. Que ceux et celles que je n ai pas nommés reçoivent l expression de toutes mespensées.

Tout d abord, je remercie le grand Dieu qui m a inspiré le courage et la patiencepour terminer ce travail. Bien évidemment, une mention spéciale revient à M. BouzianeBeldjilali et M. Baghdad Atmani de l université d Oran, d avoir accepté d encadrer cettethèse et m avoir accueilli au sein de l équipe, ils m ont apporté bien plus que la compétencescientifique nécessaire pour obtenir ce magister, leur disponibilité, leur écoute, leursconseils avisés et leur grande humanité font d eux des personnes que j ai en profondeestime.

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é deleurs rapports m honorent sincèrement.

Je remercie également M. M. K. RAHMOUNI, qui m a fait le plaisir d accepter deprésider le jury.

Je remercie les doctorants, les enseignants, les post-graduants et tous les employeursdu 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 desjours d écoute, des aventures inoubliables. Je pense à Tahia Adnane, ma vieille amie pournos nombreux rencontres au cybercafé et discussions multilingues, son écoute et son sensde l humour infini que Dieu te protège.

Et bien sûr, mes galantes salutations vont à ma famille, qui a toujours eu confianceen 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…

4

Table des matières .............................................................................................................................1

Introduction générale........................................................................................................................4

1 Introduction ......................................................................................Erreur ! Signet non défini.2 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 Introduction .................................................................................................................................212 UML : Développement orienté objet................................................................................21

2.1 Concepts de modélisation UML ..................................................................................212.2 Modèles et notations en UML ......................................................................................22

2.2.1 Diagrammes UML .....................................................................................................222.2.2 Vues de modélisation .............................................................................................242.2.3 Méta-modèle...............................................................................................................25

2.3 Processus de développement itératif ......................................................................253 Démarches ...................................................................................................................................26

3.1 Cas d’utilisation .................................................................................................................263.2 Architecture logicielle......................................................................................................273.3 Cycle de vie itératif et incrémental ..........................................................................27

4 Sélection d’une méthode.......................................................................................................285 Critères d’évaluation ...............................................................................................................28

5.1 Qualité de l’architecture logicielle.............................................................................295.1.1 Réutilisabilité ..............................................................................................................295.1.2 Modifiabilité .................................................................................................................295.1.3 Traçabilité ....................................................................................................................29

5.2 Qualité du processus de développement ..............................................................295.2.1 Pouvoir de vérification ...........................................................................................305.2.2 Compréhensibilité ....................................................................................................305.2.3 Facilité d’utilisation ..................................................................................................305.2.4 Pouvoir d’expression...............................................................................................30

5

6 Aspects avancés en UML .......................................................................................................316.1 Aspects dynamiques........................................................................................................316.2 Histoires des utilisateurs et Programmation extrême.....................................326.3 UML et la description d’architectures logicielles ................................................336.4 UML : le chemin vers l’unification des processus..............................................34

7 Le modèle UML obtenu est-il correct ? ...........................................................................358 Présentation d’OCL...................................................................................................................36

8.1 Le paquet UML-OCL.........................................................................................................368.2 Limitations et défauts d’OCL .......................................................................................378.3 Approches existantes : Méta-modèles UML et OCL intégrés .......................37

9 Conclusion ....................................................................................................................................38

1 Introduction .................................................................................................................................402 Apprentissage automatique .................................................................................................40

2.1 Apprentissage connexionniste....................................................................................412.2 Apprentissage symbolique ...........................................................................................42

2.2.1 Naissance de l'ASA et état de l'art...................................................................442.2.2 Les étapes du processus de l’ECD....................................................................46

2.2.2.1 Prétraitement des données .............................................................................462.2.2.2 Traitement des données ...................................................................................512.2.2.3 Validation .................................................................................................................52

2.2.3 Arbre de décision......................................................................................................522.2.3.1 Mode de fonctionnement ..................................................................................532.2.3.2 Les Systèmes fondés sur les Arbres de Décision..................................532.2.3.3 Finalités sur les Arbres de Décision.............................................................562.2.3.4 Avantages de l induction par graphes d induction................................56

2.2.4 Les algorithmes génétiques.................................................................................572.2.4.1 Mode de fonctionnement ..................................................................................582.2.4.2 Apprentissage des AG ........................................................................................582.2.4.3 Finalités sur les algorithmes génétiques ...................................................59

2.2.5 Raisonnement basé sur les cas : CBR ............................................................592.2.5.1 Mode de fonctionnement ..................................................................................592.2.5.2 Finalités sur le Raisonnement Fondé sur des Cas ................................59

3 Sipina..............................................................................................................................................603.1 Méthode SIPINA ................................................................................................................60

3.1.1 Le choix du critère ...................................................................................................603.1.2 Fixation du paramètre λ........................................................................................613.1.3 Fixation de la contrainte d'admissibilité ........................................................623.1.4 Prise en compte des attributs continus .........................................................633.1.5 Éléments de construction de graphes d'induction ....................................643.1.6 Passage de la partition Si à la partition Si+1 ................................................66

3.2 Algorithme SIPINA ...........................................................................................................694 Conclusion : quelle est la méthode choisie ?...............................................................70

6

1 Introduction .................................................................................................................................732 Méthode d’analyse et de conception logiciel................................................................733 Méthode proposée ....................................................................................................................73

3.1 Démarche proposée pour la modélisation ............................................................743.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............................................783.2.2 Processus de l’ECD pour la gestion de pharmacie....................................82

3.2.2.1 Première Expérimentation ...............................................................................823.2.2.2 Autres Expérimentations ..................................................................................88

5 Conclusion ....................................................................................................................................89

1 Introduction .................................................................................................................................912 La plate-forme de réalisation ..............................................................................................91

2.1 Composition de l’atelier .................................................................................................912.1.1 Module de prétraitement de données.............................................................922.1.2 Module Sipina.............................................................................................................932.1.3 Module de stockage de base de données .....................................................933.1.4 Module ArgoUML .......................................................................................................942.1.5 Intervention du concepteur et de l’expert....................................................96

3 L’organigramme de la plate-forme .................................................................................1004 L’environnement d’implémentation ..................................................................................98

4.1 Langage de programmation JBuilder version X .................................................984.2 WINDOWS XP .....................................................................................................................984.3 Modeleur UML : ArgoUML .............................................................................................98

5 Conclusion ....................................................................................................................................99

Conclusion générale .......................................................................................................................104

Références bibliographiques ......................................................................................................106

Annexe A .............................................................................................................................................114Annexe B .............................................................................................................................................123

Figure 1 Posionnement de l’étude...................................................................................................... 9Figure 2 Neurone biologique............................................................................................................... 43Figure 3 Processus de l’ECD................................................................................................................ 48Figure 4 La systémique des données.............................................................................................. 52Figure 5 Partition courante Si............................................................................................................. 69Figure 6 Liste des partitions générées par le regroupement par paires ........................ 70Figure 7 Eclatement du 1er regroupement avec les trois variables.................................. 70Figure 8 Eclatement du 2ème regroupement avec les trois variables............................... 71Figure 9 Eclatement du 3ème regroupement avec les trois variables............................... 71Figure 10 Eclatement du sommet S1 avec les trois variables................................................ 72Figure 11 Eclatement du sommet S2 avec les trois variables................................................ 72Figure 12 Eclatement du sommet S3 avec les trois variables................................................ 72Figure 13 Problématique.......................................................................................................................... 78Figure 14 Schéma générale de la démarche proposée et la démarche classique........ 79Figure 15 Architacture globale de la démarche proposée ....................................................... 80Figure 16 Schéma de données ............................................................................................................. 82Figure 17 Diagramme de classes sans ASA.................................................................................... 83Figure 18 Diagramme de classes avec ArgoUML ......................................................................... 84Figure 19 Schéma des opérations de préparation de données ............................................. 88Figure 20 Diagramme de classes après ASA ................................................................................. 90Figure 21 Diagramme de classes avant ASA ................................................................................. 91Figure 22 Diagramme de classes après ASA ................................................................................. 91Figure 23 Fenêtre principale de l’atelier........................................................................................... 94Figure 24 Étapes de préparation de données................................................................................ 95Figure 25 Module SIPINA ........................................................................................................................ 96Figure 26 Création et connexion à la base de données ............................................................ 97Figure 27 Lancement du module ARGOUML .................................................................................. 98Figure 28 Fenêtre principale du module ArgoUML ...................................................................... 99Figure 29 Organigramme Générale .................................................................................................. 100

Tableau 1 Table Individus/Variables ................................................................................................ 50Tableau 2 Exemple d’une table de données ................................................................................. 50Tableau 3 Descriptif de table Carte .................................................................................................. 86Tableau 4 Descriptif de table Client.................................................................................................. 86Tableau 5 Extrait de la Table Client tiré de la base de données ......................................... 86Tableau 6 Extrait de la Table Carte tiré de la base de données.......................................... 87Tableau 7 Table obtenue par Sélection........................................................................................... 87Tableau 8 Table récapitulative des transformations de données ....................................... 88Tableau 9 Extrait de la table finale ................................................................................................... 89

3

4

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.

5

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

6

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.

7

8

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.

9

2 Positionnement2.1 Présentation générale

La figure 1 suivante montre une représentation générale de la démarche proposée.

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.

UML

Vers l’intégration de l’ECD dans la démarche UML

ECD

L’exploitation maximale des données

Figure 1 Positionnement de l’étude

10

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.

11

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].

12

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.

13

§ 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

14

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 ;

15

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.

16

§ 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

17

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

18

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.

19

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.

20

21

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.

22

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.

23

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.

24

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.

25

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.

26

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.

27

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.

28

• 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.

29

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.

30

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

31

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].

32

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.

33

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.

34

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.

35

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.

36

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 post-

conditions 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.

37

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,

38

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.

39

40

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.

41

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].

Cette 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.

Figure 12 Positionnement de l’étude

42

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

43

(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

44

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

45

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 :

46

• 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 :

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

Acquisitiondesdonnées

Pré-traitement

TransformationFouille dedonnées

Préparation des données

DonnéesCibles

DonnéesPrétraitées

DonnéesTransformées

InformationExtraite

Reconstruction etExtraction de paramètres

Nettoyage

Sélection

DonnéesSectionnées

Interprétation/évaluation

Information

47

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.

48

• 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 2Exemple 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.

sexe nationalitérésultat du test

préalable (point)réussi

É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

49

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.

• Nettoyage de données

Figure 3 La systémique des données

50

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 ; ...)

51

• 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 :

52

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:

• É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”.

2.2.2.3 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

53

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

54

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 ;

55

§ 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,

56

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

57

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

58

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.

59

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

60

( ) ( ) ( )11 ++ ℑ−ℑ=ℑ∆ iii SST λλ

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 ℑ (Si), nous pouvons utiliser plusieurs fonctions construites à

61

10

01

0

0

.. +=

+

= τ

τ

τ

τ

i

v

i

u

n

T

n

T

MM

( ) ∑ ∑= =

+

+

+

+−=ℑ

K

j j

ijm

i j

ijji mn

nmn

nn

nS

1 .12

.

. logλ

λ

λ

λλ

( ) ( ) ( ) ( )( )uvuv TTTT λλλλλ ℑ−ℑ=ℑ−ℑ max**

partir de mesures d'incertitude [ZIGH 00] telles que :

• l'entropie de Shannon :

§ l'entropie quadratique

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 ( ) ( )vu TT λλ ℑ≤ℑ . 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].

Bien que Tu et Tv ne diffèrent que d'une unité, on devrait pénaliser fortement Tu. Nous choisirons λ* telle

que :

( ) ∑ ∑= =

+

+−

+

+=ℑ

K

j j

ijm

i j

ijji mn

nmn

nn

nS

1 .1 .

. 1λ

λ

λ

λλ

62

( )

+

+−

+

+=ℑ ∑

= λ

λ

λ

λλ mn

nmn

nT

j

ijm

i j

ijj

.1 .

1

( ) ( )( ) ( )22

2

1222)1(

λτλτλτλττ

λλλ mmmmmTT uv

++++++

−=ℑ−ℑ

<

=

nn

nn

H

nn

nn

H

c

s

sc

c

s

sc

:

:

1

0

En prenant

Nous obtenons

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 ns=nse+nsc 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

63

cs n

nn )ln( 0α−=

( )mi

i,,1

max*K=

= ττ

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 nsc=0, on conclut au rejet de

H0. Ainsi [ZIGH 00], on établit :

d'où on extrait :

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 nc 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 méthodes 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 :

64

21, jkkj

jk

xx −= +δ

>

≤=

jkj

jkjj Xsi

XsiX

δω

δωω

)(2)(1

)('

( ) jkjk X δωω ≤Ω∈=Ω ;1

( ) jkjk X δωω >Ω∈=Ω ;2

jkjq

jq IXss =∈= )(;2, ωω

( ) jjjkjj xxxX α,,,,1

1 KK=Ω−

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

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 :

Chaque bi-partition définit deux sous-ensembles, 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 Si=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

sommet sq par la variable Xj le procédé qui consiste à construire les ensemblesj

qj

qj

q sss α,2,1, ,,, K , tels que :

pour tout jk α,,1 K= (αj étant le nombre de valeurs possibles que peut prendre la variable Xj) :

65

( ) ( ) ( )11 ++ ℑ−ℑ=ℑ∆ iii TTS λλ

jq

jq

jq sss α,2,1, ,,, K

( ) ( ) ( ) 011 >ℑ−ℑ=ℑ∆ ++ iii TTS λλ

On dira que Si+1 est une partition de Ω déduite de Si par Eclatement en remplaçant sq par

§ 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 Si par Regroupement ou par Eclatement, on appellera Gain sur

l'incertitude la quantité :

§ Partition admissible

Soit Si une partition sur Ω, on dira que la partition suivante Si+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

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 ( )1+ℑ∆ iS 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 Si à 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

66

2131

1 , sssSi ∪=+

3212

1 , sssSi ∪=+

3123

1 , sssSi ∪=+

( ) ( )jiji SS 13,2,11 max' +=+ ℑ∆=ℑ∆

( ) 0' 1 >ℑ∆ +iS

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

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 Si à 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 :

qui donne un gain d'incertitude de ( )11+ℑ∆ iS

qui donne un gain d'incertitude ( )21+ℑ∆ iS

qui donne un gain d'incertitude ( )31+ℑ∆ iS

On note'

1+iS la partition telle que :

Si le gain sur l'incertitude 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

Figure 4 Partition courante Si

67

à la phase 2. Notons au passage que le regroupement se fait toujours entre deux sommets comme le

montre la figure 5.

§ P

hase 2

(Passag

e de Si à

Si+1 par

Regrou

pement-

Eclatem

ent) :

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 5 Liste des partitions générées par les regroupements par paires

Figure 6 Éclatement du 1er regroupement avec les trois variables

68

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 iSs ∈ , 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.

Figure 8 Éclatement du 3ème regroupement avec les trois variables

Figure 7 Éclatement du 2ème regroupement avec les trois variables

Figure 9 Éclatement du sommet s1 avec les trois variables

69

( ) ∑ ∑= =

+

+−

+

+=ℑ

K

j j

ijm

i j

ijji mn

nmn

nn

nS

1 .1 .

. 1λ

λ

λ

λλ

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 :

Figure 11 Éclatement du sommet s3 avec les trois variables

Figure 10 Éclatement du sommet s2 avec les trois variables

70

( ) ( )[ ] ( ) ( )[ ]j

pjTTTTquetelleS 10,,1101 max λλλλ ℑ−ℑ=ℑ−ℑ

= K

( ) ( )ii SS λλ ℑ<ℑ +1

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 ( )0Tλℑ .

5. On recherche parmi les p variables exogènes X1 ,Xp celle qui engendre la meilleure partition. Si on

notejS1 la partition engendrée par Xj et

jT1 le tableau de contingence associé, nous aurons à

déterminer Supposons 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 Si à Si+1, décrite

précédemment. On cherche la partition Si+1 décrite par le tableau T telle que :

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 :

71

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.

72

73

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.

74

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 ? ».

75

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 sous-

ensemble 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.

Modèle fonctionnel

Domaineprécis

Proces

Cahier des charges ?Figure 12 Problématique

Figure 13 Schéma générale de la démarche proposée et la démarche classique

77

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

Module prétraitement Module SIPINA

Module stockage de données

Expert Module ARGIUML Concepteur

Domaine d’application

Base de données

Sous ensemble

Modélisation

UML

Sous ensemble

de l’ ECD

Figure 14 Architecture globale de la démarche proposée

78

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).

79

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.

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] :

Figure 15 Schéma de données

80

PharmacieAttributes

public int N°_ Pharmaciepublic String Nom_pharmaciepublic String Adressepublic String Télpublic String Faxpublic int Num_ registre

Operations

public void MAJ()public void Vérification()public void Faire_COM()public void Cntrôle_Fact()public Compte[0..*] getCompt...

ArticleAttributes

public int N°_ Articlepublic int Codepublic String Désig...public int Quantité_...public Bool Hors_ ...public Bool Rembo...

Client From Ordonnance

Attributes

public int clientpublic String Nompublic Date Date_Naissancepublic String Sexepublic String Télpublic String adresspublic int Taux_Rembpublic Bool Conventionée

Operations

public void Inscription()

OrdonnanceAttributes

public int N°_ordonn...public Date Datepublic String Médecinpublic String Note

Operations

PaiementAttributes

private int N°_paiementprivate int Dateprivate int Montant

Operations

FournisseurAttributes

public int N°_fournisseurpublic String Catégoriepublic String Raison_ socialepublic String Adressepublic String Télpublic String Faxpublic String Payspublic String E-mail

FactureAttributes

public int N°_facturepublic Date Datepublic Float Montant_d achatpublic Float Montant _vente

Operations

public Pharmacie[0..*] getPharmac...public void setPharmacie(Pharma...

LotAttributes

public int N°_lotpublic String Désignati...public Date Date_ Perpublic int Quantitépublic Float Prix_ venteprivate Float Prix_ d ac...

Operations

public void MAJ()

Lot_ périmésAttributes

public int N°_lotpublic String Désignationpublic Float Prix_ ventepublic Float Prix_ d achat

Operations

public void Affiche()

DictionnaireAttributes

public int N°_dicopublic int Codepublic int Spécialitépublic int Dosepublic int Tarif_ refpublic int Date déli...public int Condit

Operations

public void Ajoute()

DCIAttributes

public int N°_DCIpublic String DCI

Operations

public void Ajout...public void Sup()

PrésentationAttributes

public int N°_présentati...public String Présentati...

Operations

public void Ajoute()public void Sup()

FamilleArticleAttributes

public int N°_familleArti...public String familleArti...

Operations

public void Ajoute()public void Sup()

CommandeAttributes

public int N_compublic Date Date_com

Operations

CompteAttributes

public int Compteprivate int N°_ Compteprivate Date Date_ créationprivate String Solde

Operations

Lot_ BloquésAttributes

public int N°_lotpublic String Désign...public int Quantitépublic Float Prix_ventepublic Float Prix_d'a...

Operations

public void Affiche()

PharmacienAttributes

public int N_Pharmacieprivate String Nom_phar...private String Adresseprivate String Télprivate String grade

Operations

détail-paiementAttributes

private int Paiementprivate int quantité

Operations

Dait_FactAttributes

private int N_factprivate int quantitéprivate int N_lot

Operations

détail comAttributes

private int N_détcomprivate int qte comman...

Operations

CarteAttributes

public String N_cartepublic Date Date_débpublic Date Date_fin

Operations

public void MAJ()

1

1..*1..*

1

1

1..*

travail

1..*1

mFacture

1

1..*

1

1

1

1..*

0..1

1

0..1

1

1..*

1

1

1..*

11..*

1..*

1..*

1..*

1

1..*

11

1..*

1..*

1

1

1..*

11

1

1..*

0..*

1

1..*

Possède1

1

1..*

mCompte

conventionné

1

1..*

Dlivre

1..*

1

0..1

1..*

0..1

1..*

1..*

0..1

Figure 16 Diagramme de classe

81

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

82

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:

83

BooleanConventionné

StringTaux_remboursement

StringAdresse

StringTel

BooleanSexe

DateDate_naissance

StringPrénom_client

StringNom_client

StringN_assuré

NumériqueN_client

TypeNom des champs

DateDate_fin

DateDate_début

StringN_client

StringN_carte

TypeNom des champs

Table CARTE

Table CLIENT

Tableau Extrait de la table Client tiré de la base de données

84

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 :

• 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.

Date_naissance sexe adresse taux_remboursement conventionné date_début date_fin

1

2

Table 2 :

Tableau Extrait de la table Carte tiré de la base de données

85

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 Opération Type résultant

date_début date_fin DateFusionner les deux

date en périodeNumérique

taux_remboursement String Catégories (1, 2, 3) Numérique

conventionné BooleanConvetionné à 1

Sinonà 2Numérique

sexe BooleanFémininà 1

Sinonà 2Numérique

adresse StringOranà 1

Sinonà 2Numérique

date_naissance Date Age Numérique

Sélection Nettoyage Transformation detype de données

Discrétisation

Préparation de données

Supprimer

Calculer lamoyenne

Remplirpar défauts

Saisirl’informatio

n oubliée

Traitement desdonnées manquantes

Remplir parnulle

Figure 20 Schéma des opérations de préparation de données

Tableau

86

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

• 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.

Tableau

87

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

88

3.2.2.2 Autres Expérimentations

Soit le diagramme de classes de la figure hhhh de l’application (gestion aéronautique) [SLIM

05] :

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 22 Diagramme de classes avant ASA

Figure 23 Diagramme de classes après ASA

89

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.

90

91

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).

92

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

93

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].

2.1.3 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.

Figure 22 Module SIPINA

94

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.

3.1.4 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).

Figure 22 Création et connexion à la base de données

95

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

96

2.1.5 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.

Figure 22 Fenêtre principale du module ArgoUML

97

3 L’organigramme de la plate-forme

Module SIPINA

Modélisation

Non

Choix des attributs

Affichage des attributs de la classe choisie

Sélectionné des attributs de la classe choisie

Une nouvelle Table

Afficher

Si c’est le dernierattribut

Oui

Modèle de Classes

Affichage des Classe

Sélection d’une classe

Affichage des classes de relation

Choix d’une Classe

Module ArgoUMLModule stockage

de base de données

Figure : Organigramme Générale

Affichage des attributs de la classe choisie de relation

AnalyseModification

Module de préparationde base de données

Table

Statistique

98

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.

99

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.

100

101

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.

102

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.

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. BENARDExtreme programming – Méthodes Agiles : l’état des lieux.White paper © Business Interactif, 2001.

[BISH 95] C. BISHOPNeural networks for pattern recognition.Clarendon Press, 1995.

[BODE 02] J. P. BODEVEIX., T. MILLAN, C. PERCEBOIS, C. LE CAMUS, P. BAZEX, L. FERAUD, etSOBEKExtending OCL for verifying UML models consistency, UML 2002 Workshop on “ConsistencyProblems in UML-based Software Development in Blekinge Institute of Technology”,Research Report, 2002.

[BOOC 00] G. BOOCH, J. RUMBAUGH et I. JACOBSONGuide de l'utilisateur UML.Ed. Eyrolles, 2000.

[BOUD 03] C. BOUDIA, H. DAHMANIAPPRENTISSAGE 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. BELDJILALIRetro 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-AVILAConversational case-based reasoning ,Applied Intelligence, 2001.

[CHAR 99] RICHTER, CHARLESDesigning 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 CHAUCHATEchantillonnage, 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 CLAVED'UML à MDA : En passant par les méta modèlesArticles pour la « Lettre de l’Adeli ».France, 2004.

105

[CODD 93] E. F. CODDProviding 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.MICLETApprentissage Artificiel : Méthodes et AlgorithmesEd. Eyrolles, 2004.

[DAHM 04] DAHMANI. YNavigation d’un robot mobile dans un environnement inconnu : contribution du Q-learning flouThèse Doctorat d’état en Informatique, Université des sciences et des technologies d’OranMohamed Boudiaf 2004.

[DAVO 01] PAULE-ANNICK DAVOINEModélisation UML et outils pour l’analyse spatialeLSR-IMAG, SIGMA team,Institut polytechnique de Grenoble, 2001.

[DECO 01] BERNARD DECOURBEModélisations des processus d'affaires Perspectives d'utilisation de la méthode UMM pour leséchanges électroniques professionnels.France, 2001.

[DELO 02] JEAN-MICHEL DELORMEL’apport de la fouille de données dans l’analyse de texte.Conservatoire National des Arts et MétiersCentre régionale de Montpellier, 2002.

[DESF 04] PHILIPPE DESFRAYRéussir la modélisation UML des phases amont. Techniques de « pré-Modélisation » : un pontvers le modèle.White paper © Softeam 2004.

[DOMI 04] A. DOMINIQUEL’utilisation d’UMLWhite paper © Softeam 2004.

[DREY 04] GÉRARD DREYFUSModélisation par apprentissage d'un nouvel outil de diagnostic des gisements de pétrole.Thèse CIFRE Schlumberger-ESPCI, Laboratoire d'Electronique/ESPCIUniversité 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 etapprentissage.Laboratoire d'Electronique/ESPCIUniversité 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 FAVREUtilisation des index Bitmap pour la fouille de données.Mémoire DEA, Laboratoire ERIC, Université Lyon 2.France, 2003.

106

[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. MUELLERAn 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 theSecond International Conference on Knowledge Discovery and Data Mining, 1996.

[FOWL 97] FOWLER, MARTIN, KENDALL et SCOTTUML Distilled: Applying the Standard Object Modeling Language,Ed. Addison-Wesley, 1997.

[GUIS 96] GIUSEPPE PSAILA, ROSA MEO et STEFANO CERIA new sql-like operator for mining association rules.In 22th International Conference on Very Large Data Bases, Morgan Kaufmann, 1996.

[GOLD 89] D. GOLDBERGGenetic Algorithm In Search, Optimization And Machine Learning.Addison-Wesley, 1989.

[HAYK 99] S. HAYKINNeural 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 WebConsortium, W3C Team Submission SUBM.2005.

[HOLL 75] J. H. HOLLANDAdaptation In Natural And Artificial Systems.University of Michigan Press, 1975.

[JACO 92] I. JACOBSON, M. CHRISTERSON, P. JONSSON, et G. ÖVERGAARDObject-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 KADARIAModé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. MITCHELLApprentissage Symbolique : Une Approche de l'Intelligence ArtificielleEd. CEPADUES, France, 1993.

[KODR 97] Y. KODRATOFFL'extraction de connaissances à partir de données : un nouveau sujet pour la recherchescientifique. Revue électronique R.E.A.D, 1997.

107

[KRUC 03] P. KRUCHTEN, P. KROLLGuide pratique du RUP.CampusPress, 2003.

[LEBL 04] PHILIPPE LEBLANCDéveloppement basé sur la modélisation UML 2.0Rapport TechniqueWhite paper © Telelogic, 2004.

[LEFE 01] LEFÉBURE et VENTURIData MiningEd. Eyrolles, 2001.

[MATE 01] P.F. MARTEAU & ALLPROJET APRIME, 2001.

[MAHO 91] RAYMOND J MOONEY, J. J MAHONEYInitializing ID5R with a Domain Theory: Some Negative ResultsTechnical Report:University of Texas at Austin, USA, 1991.

[MEKA 06] A.MEKAMI, L. RAHLIExtraction de connaissances à partir des bases de données XML.Projet de fin d’études,Université d’Oran, 2006.

[MICH 00] MICHEL LAIPenser objet avec UML et JAVA : 2ème editionEd. Dupod, 2000.

[MITC 97] T.M. MITCHELLMachine Learning. Computer SciencePublisher: McGraw-Hill, New York, 1997

[MOUL 97] I. MOULINIERApprentissage et Acquisition de Connaissances.Thèse de doctorat,Université Paris VI, 1997.

[MULL 04] PIERRE-ALAIN MULLER et NATHALIE GAERTNERModélisation Objet avec UML.Ed. Eyrolles, 2004.

[NAUL 98] ELIE NAULLEAUApprentissage et Filtrage Syntaxico-Sémantique de Syntagmes Nominaux Pertinents pour LaRecherche Documentaire.Thèse de doctorat, université de Paris XIII, 1998.

[NEDE 00] C. NÉDELLECKnowledge Extraction from Text, a Machine Learning ApproachIn Proceedings of the Third International Conference on Human-System Learning, CAPS'3,France, 2000.

[OLIV 02] OLIVIER GLASSEY, JEAN-LOUP CHAPPELETComparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML,UER: Management public / Systèmes d'information, l'IDHEAP ? France, 2000.

108

[OMG 99] OMGOMG Unified Modeling Language Specifications. Version 1.3.Technical ReportOMG, 1999.

[PAQU 97] G. PAQUETTE, F. CREVIER et C. AUBINMéthode d'ingénierie d'un système d'apprentissage (MISA),Revue Informations In Cognito.USA, 1997.

[POPI 00] FABRICE POPINEAUIntroduction à la conception Orientée Objet et à UML2000.

[QUIN 93] J.R. QUINLANC4.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 REGEPLfP : un langage de spécification pour supporter une démarche de développement parprototypage 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. WIERINGAThirty one Problems in the Semantics of UML 1.3 DynamicsWorkshop Rigorous Modeling and Analysis of the UML Challenges and Limitations,OOPSLA’99,Denver, CO, 1999.

[REMI 00] R. RÉMI, T. MARCDécouverte de connaissances à partir de données.Thèse de doctorat en Informatique.France, 2000.

[RENA 05] D. RENAUDIEMé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ÉEUML 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 MOHAMEDConception et réalisation d’un système d’extraction de connaissances à partir des BDD : (Etudecomparative avec Tanagra et Sipina)Projet de fin d’études, Université d’Oran, 2006.

109

[SLIM 05] SLIMANI NADERA et MEBARKIA S. BOUBAKEURModé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. ROYELECTRE IS - ASPECTS MÉTHODOLOGIQUES ET GUIDE D'UTILISATION.Document du LAMSADEUniversité de Paris-Dauphine, 1984.

[TALE 06] S. TALEB ZOUGGARGraphes d’induction et réseaux de neurones, une nouvelle technique hybride pour la sélection etla segmentation des données.Thèse de Magister, université d’Oran, 2006.

[ UDRE 98] C. UDRÉA, F. BENTAYEB, J. ARMONT et O. BOUSSAIDPréparation des données pour une intégration efficace de méthodes de fouille de données dansles sgbd.Technical report, Laboratoire ERIC - Université Lyon 2, 2003.

[VAUQ 04] DOMINIQUE VAUQUIERLes six impasses de la conception des processus Vers une alternative à l'approche fonctionnelleArticle pour la « Lettre de l’Adeli »France, 2004.

[VILLA 00] M.VILLANOVAModélisation UML pour les systèmes d’information dédiée aux risques naturelsColloque 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. ZIGHEDMé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.DURUSIPINA : Méthode et Logiciel.Lacassagne, 1992.

[ZIGH 02] D.A. ZIGHED, R. RAKOLOMALALAExtraction de connaissances à partir de données (ECD).In Techniques de l’Ingénieur,volume HA, 2002.

[ZIGH 00] D.A. ZIGHED, R. RAKOLOMALALAGraphe d’induction: Apprentissage et Data Mining.Ed. Hermes Sciences, France, 2000.

110

111

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

112

« 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.

113

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

114

♦ 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.

115

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 :

116

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.

117

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

Ordonnance

Carte

Remplirle chèque

Patient

ComptableBANQUE

CNAS

IMPÔT

Taxes signés

Enregistrer

Fournisseur

Pharmacien

118

Diagramme de séquence

: Patient : Pharmacien : FournisseurDéposer la carte

Déposer l’ordonnace

Assurer les médicaments

Feuille de maladie (Num)

la Commande Envoyé

Vérification sur le stockCommande des produits non disponibles

Délivrance des factures

Chèque envoyé

: CNAS

Construire les dossiers (Num)

Envoyer les dossier ()

Chèque de remboursement

Contrôle la facture ()

Envoyé liste des produits remboursable ()

Enregistrer ()

119

Diagrammed’activité

Diagramme de collaboration

Pharmacien

1 : établir: Commande

2 : envoi

Fournisseur

3 : Délivre

: Facture4: envoi

5 : contrôle

: Chèque6 : remplir un chèque

7: envoi

Pharmacien CNAS

Remplier lesimprimés Construire

le dossier

Envoyer lesdossiers

Vérification sur lesdossiers

Remboursé :Chèque

correcteOui

Non

Envoyer chèqueChèqueArrive

Dossierretourné

DossierArriver

Dossier

[Réglées]

Couloir d’activitéEtat d’objetFinActivité

Départ

Envoyer le dossier(retourne)

120

OCL : Object Constraint LanguageCela résume de manière synthétique mais incomplète et très informelle les principales caractéristiques du langageOCL.Pour plus de précision, se reporter au document de référence UML.

Types des identificateurs utilisés ci-dessous

Constructions syntaxiquesctidself

e op ee. ide . pt ( e, ... , e )c -> pt ( e, ..., e )

ns:: ... ns::idif pd then e else e endiflet id = e : T, id2 = e:T, ... in e2

Types, valeurs et opérations dans la bibliothèque standardInteger 1, -5, 34 i+i2, i-i2, i*i2, i.div(i2), i.mod(i), i.abs, i.max(i2), i.min(i2), <, >, <=, >=Real 1.5, 1.34, ... r+r2, r-r2, r*r2, r/r2, r.floor, r.round, r.max(r2), r.min(r2), <, >, <=, >=Boolean true, false not b, b and b2, b or b2, b xor b2, b implies b2String '', 'une chaine' s.size(), s.concat(s2), s.substring(i1,i2), s.toUpper(), s.toLower(), s.toInteger(), s.toReal()Enumeration Jour::Lundi,

Jour::Mardi, …=, <>

TupleType( x :T1, y : T2, z : T3 )

Tuple y : T2 = …, x = … , z = …

t.xt.yt.z

Collection(T)c->size(), c->includes(o), c->excludes(o), c->count(o), c->includesAll(c2)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(T)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,5Bag

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) OrderedSet10,4,3OrderedSet

…

Sequence(T)

Sequence5,3,5Sequence

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

i : Integerr : Realb : Booleans : String

c : Collection(T)st: Set(T)bg : Bag(T)sq : Sequence(T)

os : OrderedSet(T)t : Tuple(…)id: identificateurpt: property

cs: constantpd : predicate : expressionns: namespace

121