HAL Id: tel-01154046
https://hal.archives-ouvertes.fr/tel-01154046
Submitted on 21 May 2015
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Modélisation “ objet ” du processus de conception dans le domaine du génie électrique: application au cas de la
machine asynchrone, le système OPUS
Eric Escande
To cite this version:
Eric Escande. Modélisation “ objet ” du processus de conception dans le domaine du génie électrique:
application au cas de la machine asynchrone, le système OPUS. Energie électrique. Institut National
Polytechnique de Grenoble, 1996. Français. �tel-01154046�
'illrlii~li Îi~ïr 11imiïli~o
o
051 0978736THESE
présentée par
Eric ESCANDE
Professeur agrégé de génie électrique
pour obtenir le grade de DOCTEUR
de l'INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE (Arrêté ministériel du 30 mars 1992)
(Spécialité: génie électrique)
======================
Modélisation
«objet
»du processus de conception dans le domaine du génie électrique: application au cas de la machine asynchrone,
Composition du jury :
Monsieur Madame Messieurs
le système OPUS
======================
Date de soutenance : 11 Décembre 1996
P. GUILLON, M. REYNIER, F. VERNADAT, H. PIQUET B. CORNUT J. BIGEON
président rapporteur rapporteur
Thèse préparée au sein du Laboratoire d'Electrotechnique de Grenoble
THESE
présentée par
Eric ESCANDE
Professeur agrégé de génie électrique
pour obtenir le grade de DOCTEUR
de l'INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE (Arrêté ministériel du 30 mars 1992)
(Spécialité: génie électrique)
======================
Modélisation
«objet» du processus de conception dans le domaine du génie électrique: application au cas de la machine asynchrone,
Composition du jury :
Monsieur Madame Messieurs
le système OPUS
======================
Date de soutenance : 11 Décembre 1996
P. GUILLON, M. REYNIER, F. VERNADAT, H. PIQUET B. CORN UT J. BIGEON
président rapporteur rapporteur
Thèse préparée au sein du Laboratoire d'Electrotechnique de Grenoble
A mes parents, Isabelle,
Alain et Camille,
Sylvie,
Céline,
Frédéric et Marie-Hélène.
Remerciements
Je remercie Monsieur Pierre Guillon, directeur de l'Institut de Recherche en Communication Optique et Micro-ondes pour m'avoir fait l'honneur de présider le jury de cette thèse.
Je remercie Madame Marie Reynier, professeur
à
l'Université de PARIS X pour avoir honoré le jury de sa présence, pour avoir accepté d'être l'un des rapporteurs de ce travail et pour la grande attention qu'elle y a porté.Je remercie Monsieur François Vernadat, professeur
à
l'université de Metz, pour avoir également accepté d'être rapporteur de ce travail, pour les conseils informatiques qu'il m'a prodigué lors de notre collaboration dans le cadre d'un projet de la région Rhône-Alpes.Je remercie Monsieur Hubert Piquet, Maître de conférence
à
l'Ecole Nationale Supérieure d'Electrotechnique, d'Electronique, d'Informatique et d'Hydraulique de Toulouse, pour avoir participé au jury de cette thèse ainsi que pour les discussions que nous avons eu concernant la mise en oeuvre technique du modèle de conception.Je remercie Monsieur Bruno Cornut pour avoir participé au jury de cette thèse ainsi que pour ses encouragements.
Je remercie Monsieur Jean Sigeon, chargé de Recherche au C.N.R.S., pour m'avoir accepté dans le groupe « lA » devenu Equipe Conception et Diagnostic Intégré du laboratoire.
Je remercie également Messieurs Robert Perret et Jean-Claude Sabonnadière pour m'avoir reçu, tout d'abord comme étudiant en D.E.A. puis comme doctorant, au sein du Laboratoire d'Electrotechnique de Grenoble.
- 3-
Je souhaite remercier ici très chaleureusement Mlle Florence François pour le plaisir que j'ai eu à travailler avec elle durant les cinq années de ma thèse, pour sa bonne humeur quotidienne et sa gentillesse.
Tout au long de ce travail, j'ai trouvé auprès de M. Yves Lembeye, en toutes circonstances, un soutien sans faille et d'une grande honnêteté. Qu'il trouve ici !'expression de ma profonde reconnaissance.
Ces années ont aussi été l'occasion de rencontrer des gens d'une exceptionnelle qualité humaine, comme M. Yves-André Chapuis, Maître de conférence à l'université Louis Pasteur de Strasbourg, ex champion de ski.
Je souhaite également remercier M. Jérôme Delamare, chercheur dans l'âme, pour sa grande gentillesse, sa permanente disponibilité.
En parallèle à ce travail, j'ai consacré du temps à la découverte de l'univers du chant choral.
J'y ai passé des moments d'intenses émotions. Ceux-ci ne furent possibles que grâce à l'ensemble des membres des Choeurs des Universités de Grenoble, sopranos, altos, ténors et basses, ainsi que grâce à son directeur artistique Bernard Spizzy.
Je remercie aussi l'ensemble des personnels du Laboratoire d'Electrotechnique du Laboratoire pour la bonne convivialité qu'ils y font régner, et tout particulièrement M.T. Loubinoux.
Je tiens enfin à remercier les personnels administratifs avec qui j'ai collaboré au sein du service des stages de l'école: tout d'abord Mme Terrot, puis Mlle Sauve, Mlle Malki et Mlle Coquand.
A leurs manières elles ont aussi contribué à l'aboutissement de ce travail.
- 4-
ZADOK THE PRIEST.
A.
Vivaldi, « Gloria », RV589HANDEL.
p~ bn _ ;t~i nt_bu!.
fIJI· •• , ...." .. i.w
blJ _ U8 1 ho ..
J'rOIA lb LOJ'dj,
====
t1!!:;s=:e
~~~~~§~~~~~-
-.·+-"FJi __
.::_.~el lb dU 0,"
e%1!fé!'Z!
\ \
H. Purcell,« Funeral music for Queen Mary»
:2. Min that la born of m womlfl 1CM'iu' lit IWItiltiIOl Job kf. '·1
... __ ...
,.... _--".
M M _ N t u _ _ _ _ _ '"
l'
_._--"
IAIU:
,.
,.,
a-& pax ho _ fw pll.C~ furA Gabrielle D'Estrées
[Saint-Germain-en-Laye, 29 octobre 1598]
Jay pryns le serf an uneure avec tout le plesyr du monde, et suys arryvé an ce Iyeu a catreures. Je suys desandu a mon petyt logys, ou yi fayt amyrablement beau ; mes anfans my sont venus treuver, ou pour myeus dyre, Ion les y a aportés. Ma fYlle amande fort et ce fayt belle, mays mon fYIs cera plus beau que son ayné.
Vous me conjurés mes cheres amours damporter autant damour que je vous an lesse. Ha, que vous mavés fayt plesyr, car jan ay tant que, croyant avoyr tout amporté, je craygnoys quyl ne vous an fut poynt demouré.
Je manvoys las antretenyr Morfée, mays syl me represante autre songe que de vous, je fuyré atousjamays sa compagnye. Bonsoyr pour moy, bonjour pour vous ma chere mettresse, je vous bese umylyon de foys vos beaus yeus.
Ce XXIX' octobre
H.
tIo. Iyad _ _ _ -!Y_a.
"* . *'"_ _... SI .... _ _ -*' AIItp ,.=
_
.... - . . -...
tuf· ...
.""\IIel:narl&t_ ... ',
. . , ... .0
- 5-
Sommaire
REMERCIEMENTS
SOMMAIRE ... 6
AVANTapROPOS ...
13
1.
INTRODUCTION ...14
1.1. PROBLEMATIQUES DE CONCEPTION ... 14
1.2. LES OBJECTIFS ASSIGNES A NOS LOGICIELS, NOS PRE-REQUiS ... 17
1.3. LES UTILISATIONS POSSIBLES D'UN TEL OUTIL ... 19
1.4. PLAN DE CE MANUSCRIT ... 20
2. lES LANGAGES ORIENTES cc OBJET » ... 21
2.1. INTRODUCTION ... 21
2.2. LES CONCEPTS DE BASE DES LANGAGES ORIENTES" OBJET » ... 22
2.2. 1. Le concept de Classe ... 22
2.2.2. Le concept d'instance ... 22
2.2.3. Le concept d'attribut ... 23
2.2.4. Le concept de méthode ... 23
2.3. CLASSES ET HERITAGE ... 24
2.3.1. Intérêt de l'héritage .. ...
252.3.2. Définition de nouvelles propriétés ... 25
2.3.3. Redéfinition des propriétés ... 26
2.3.4. Sélection statique des méthodes ... 26
2.3.5. Exemple d'utilisation de la technique d'héritage ... 27
2.3.6. Sélection dynamique des méthodes ... 28
2.3.7. Programmation fonctionnelle ... 28
2.4. LE NIVEAU « META» ... 29
2.4. 1.
Définition d'un niveau conceptuel plus fort ... 29
2.4.2. La classification du niveau méta ... 32
2.5. DEVELOPPEMENT D'UN LOGICIEL DE CONCEPTION" OBJET» ... 33
2.5. 1.
Une activité pluridisciplinaire ... 33
2.5.2. Des fonctionnalités requises similaires ...
332.5.3. Méthodologie de développement à base d'objets ... 34
2.5.4. Evolutivité des logiciels de conception" objet» ... 35
2.5.5. Précautions ... ... 36
2.6. CONCLUSION ... 36
Sommaire
- 6-
3. MODELISATION DU PROCESSUS DE CONCEPTION ... 31
3.1.
ORGANISATION DES CONNAISSANCES DANS LES MODELES PRECEDENTS ...•...•..•.•...37
3. 1. 1.
Structure du produit à concevoir ... 38
3.1.2. Modélisation des règles d'expertise ... 40
3.1.3. Modélisation de la stratégie de résolution ... 41
3.1.4. Bilan ...
413.2.
LE CYCLE DE BASE DU RAISONNEMENT.. ...41
3.2. 1. Le cycle simplifié ... 42
3.2.2. La construction des actions faisables ... 43
3.2.3. Bilan intermédiaire ... 46
3.2.4. Notation des actions ... ... 47
3.2.5. Sélection des meil/eures actions ...
493.2.6. Hypothèse, préparation d'exécution et exécution d'une règle d'expertise ... 51
3.2.7. Phase de bilan ... 52
3.2.8. Rebouc/age du cycle de base .... ... 52
3.2.9. Représentation du cycle de base du raisonnement ... 53
3.3.
MODELISATION DU PRODUIT A CONCEVOIR ...56
3.3.1. Les informations à caractère dynamique ... 56
3.3.2. Les informations à caractère statique .... ... 59
3.3.3. Bilan ... 61
3.4. LA MODELISATION DES REGLES D'EXPERTISE ... 62
3.4.1. Modélisation des caractéristiques des règles d'expertise ... 62
3.4.2. Modélisation des caractéristiques stratégiques ... 63
3.4.3. Rôle des compilateurs ... 65
3.4.4. Typologie des règles d'expertise ... ... 66
3.5. LA MODELISATION DE LA CONNAISSANCE STRATEGIQUE ... 71
3.5. 1. Les différentes natures de stratégie ... 71
3.5.2. La stratégie de l'expert ...
723.5.3. Stratégie et maintien de cohérence ... 74
3.5.4. Modélisation objet de la stratégie ...
753.6. GRAPHE COMPLET DES CLASSES DU MODELE ... 76
3.7.
EXTENSIBILITE DU MODELE ET COMPETENCES D'INTERVENTION ...77
3.7. 1. Déroulement d'une session de calcul ... 77
3.7.2. Changement de la connaissance déductive ... 78
3.7.3. Modification de la stratégie de résolution ... 78
3.7.4. Modification de la stratégie ...
783.7.5. Modification de l'exploitation du modèle de conception ... 79
4. GUIDE METHODOLOGIQUE DE MODELISATION DU PRODUIT A CONCEVOIR ... 00
4.1.
INTRODUCTION ...81
4.2.
CONNAISSANCES MANIPULEES DANS UN PROBLEME DE CONCEPTION ...82
4.2. 1. Les éléments ... 83
4.2.2. Les caractéristiques ... 83
4.2.3. Les versions de structure ... 83
4.2.4. Les connaissances propres au domaine ... 85
4.2.5. Les modèles de comportement ... 86
Sommaire
- 7-
4.2.6. Les informations de comportement ... 86
4.2.7.
L'édition des résultats ... 874.3. METHODOLOGIE DE REPRESENTATION DES CONNAISSANCES DANS UN LANGAGE ORIENTE OBJETS: LE PRODUIT A CONCEVOIR ...
87
4.3.1. Les éléments ...
87
4.3.2. Les sous-éléments ... ... 90
4.3.3. Les caractéristiques des éléments .... ... 93
4.3.4. Caractéristiques communes ... 94
4.3.5. Les incompatibilités ... 95
4.3.6. Les connaissances du domaine ...
97
4.3.7. Utilisation des connaissances de la base de données ... 99
4.3.8. Le partage des instanœs ... 99
4.3.9. Les caractéristiques des attributs ... 101
4.3.10. L'utilisation des tables . ... 103
4.3.11. Edition de documents, de plans ... 104
4.3.12. Liens de composition explicites entre classes mono-instanciables ... 105
4.3.13. Bilan de la modélisation du produit.. ...
106
4.4. METHODOLOGIE DE REPRESENTATION DES CONNAISSANCES DANS UN LANGAGE ORIENTE OBJETS: LES POINTS DE VUE ... 107
4.4.1. La modélisation d'un point de vue ... ... 107
4.4.2. Association par multi-instanciation ... 109
4.4.3. Association explicite par mu/ti-classification... 110
4.4.4. Association explicite par composition .. ... 111
4.5. GRANULARITE DE LA DECOMPOSiTION ...
i 11
4.6. CONCLUSiON ... 1135. MISE EN OEUVRE DU MODELE: lE SYSTEME OPUS ...•...•.•...••••...• " ... 115
5.1. STRUCTURE NECESSAIRE AU DEVELOPPEMENT D'UN SYSTEME EXPERT ... 115
5.1.1. Le progiciel SMECI ... 115
5. 1.2.
Direction par les faits, par les règles ...117
5.1.3. Modélisation objet des connaissances ... 118
5.1.4. Spécifications d'un outil de développement.. ... 119
5.2. MODELISATION OBJET DE L'ACTIVITE DE CONCEPTION ... 120
5.2. 1.
Contrôle général du système OPUS.... ...122
5.2.2. Définition du produit
à
concevoir... 1225.2.3. Consultation du produit
à
concevoir ... 1235.2.4. Définition de la stratégie de résolution ... 124
5.2.5. Après résolution, consultation du raisonnement... ...
124
5.2.6. Consultation d'une solution donnée. Le produit conçu ...
125
5.2.7. Consultation du raisonnement... 126
5.2.8. Bilan... 127
5.3.
MODELISATION DU PRODUIT A CONCEVOIR. LA MACHINE ASYNCHRONE ...127
5.4. PLATE-FORME DE DEVELOPPEMENT (QUELQUES CHIFFRES) ... 131
5.5.
DEROULEMENT D'UNE SESSION ... 1315.5.1. Prélude au déroulement de la session ... 131
5.5.2. Contrôle dynamique du raisonnement... ... 132
5.5.3. Graphe des solutions ... 133
5.5.4. Consultation d'une solution ... ... 135
Sommaire
- 8-
5.5.5. Exemple de rebouclage ... 136
5.5.6. Exemple de raisonnements en parallèle ...
1375.5.7. Synthèse du raisonnement ... 138
5.6.
LE MODE DE FONCTIONNEMENT MANUEL ...•...••...•.•...•...•..139
5.7.
CONCLUSiON ...•...141
6. EXTENSIBILITE DU MODELE ... 142
6.1.
EXTENSIBILITE DES DONNEES DU PRODUIT A CONCEVOIR ...142
6.2.
EXTENSIBILITE DU MODELE DE REGLES D'EXPERTiSE ••••.•..••...•...••••...•...•..148
6.3.
EXTENSIBILITE DU MODELE CONCERNANT LA STRATEGIE DE RESOLUTION .••••...•...•....•..••...152
6.3.1. Extensibilité de la stratégie de sélection ...
1526.3.2. Extensibilité de la stratégie globale ... 155
6.3.3. L'extensibilité de la stratégie associée à la sémantique des règles d'expertise . ...
1576.4.
MAINTENANCE DES APPLICATIONS ...•...162
7. CONCLUSION ... 163
REFERENCES BIBLIOGRAPHIQUES ... 165
BIBLIOGRAPHIE ... 169
ANNEXE 1 : MACHINE ASYNCHRONE ... 171
ANNEXE 2 : MODELISATION DU PRODUIT A CONCEVOIR, REMARQUES ... 117
ANNEXE 3: lES TYPES DE REGLES D'EXPERTISE ... 183
Règles d'estimation ... 184
Règles de calcul d'attributs... ...
187Règles de calcul d'un attribut de type entier ... 191
Règles de calcul d'un attribut de type symbole... ... 197
Règles de calcul d'un attribut de type float ... 203
Règles de création d'instances et de champs ... 209
Règles de rebouc/age simple ...
213Règles de rebouc/age multiple ... 217
Règles de vérification d'attributs ... 222
ANNEXE 4: TACHES ET REGLES SySTEME ... 226
Sommaire
- 9 -
Table des figures
Figure 2-1 : Exemple de classe et d'instance ... 22
Figure 2-2: Exemple d·attribut ... 23
Figure 2-3 : Exemple de sous-classes ... 24
Figure 2-4 : Exemple de spécialisation des méthodes ... 26
Figure 2-5 : Héritage des méthodes: Exemple de comportement par défaut ... 28
Figure 2-6 : Exemple de Méta-classe ... 30
Figure 2-7: Spécialisation des méta-classes ... 30
Figure 2-8 : Exemple de Méta-attribut ... 31
Figure 2-9 : Exemple de spécialisation du niveau Méta: les attributs numériques ... 32
Figure 3-1 : Cycle de base du raisonnement simplifié ... 42
Figure 3-2 : Le concept .. Rapport d'activité ) •... 43
Figure 3-3 : Composition du produit - définition d'historiques d'attributs ... 44
Figure 3-4 : Caractéristiques d'une règle d'expertise ... .45
Figure 3-5 : Le concept d'action ... 45
Figure 3-6 : Infonnations associées aux éléments du produit utilisateur ... 46
Figure 3-7 : Définition des historiques ... .47
Figure 3-8 : Concept stratégique Mode-de-Filtrage : contrOle de la sélection des actions ... 50
Figure 3-9 : Codage générique de la sélection des meilleures actions ... 51
Figure 3-10 : Le concept d'historique méthodologique ... 52
Figure 3-11 : Exemple de méta-règle. la sélection de l'action unique ... 53
Figure 3-12 : Le cycle de base du raisonnement détaillé ... 54
Figure 3-13: Structure générale des classes du modèle ... 55
Figure 3-14 : Comportements associés par héritage au produit à concevoir ... 57
Figure 3-15 : Spécificité de comportement des historiques ... 68
Figure 3-16 : Définition des infonnations statiques associées aux attributs utilisateur ... 60
Figure 3-17 : Graphe des méta-classes utilisateur ... 61
Figure 3-18 : Graphe de modélisation des informations liées au produit à concevoir ... 62
Figure 3-19 : Définition des règles d·expertise. héritage de propriétés ... 63
Figure 3-20 : Définition des critères de sélection des règles d'expertise ... 64
Figure 3-21 : Exemple de méthode de classement relative au critère de linéarité ... 65
Figure 3-22 : Graphe de spécialisation des règles d·expertise ... 66
Figura 3-23 : Modélisation et accès à une démarche heuristique: le concept d'hypothèse ... 68
Figure 3-24 : Modélisation de la stratégie de résolution ... 74
Figure 3-25 : Graphe de modélisation de la stratégie ... 76
Figure 3-26 : Graphe complet des classes du modèle ...
n
Figure 3-27: Les niveaux d·intervention ... 80Figure 4-1 : Représentation schématique partielle d'un moteur ... 82
Figure 4-2 : Eléments composant un moteur ... 83
Figure 4-3 : Ensembles des rotors ... 84
Figure 4-4 : Représentation des éléments par des classes ... 87
Figure 4-5 : Uste des éléments constituant I·application ... 88
Figura 4-6 : Méta-classe des classes utilisateur ... 89
Figure 4-7: Définition des caractéristiques des classes utilisateur ... 89
Sommaire
- 10 -
Fi~re 4-8 : Graphe des méta-classes utilisateur ... 90
Figure 4-9 : Modélisation des versions par des classes ... 90
Figure 4-10 : Graphe de composition du moteur ... 90
Fi~re 4-11 : Graphe de spécialisation des méta-attributs dans OPUS ... 91
Figure 4-12 : Graphe de spécialisation des méta-attributs dans SHOOD ... 91
Fi~re 4-13: Exemple de définition d'une classe utilisateur dans SHOOD ... 92
Figure 4-14: Exemple d'accès au graphe de composition dans SHOOD : Le moteur ... 92
Figure 4-15 : Caractérisation des éléments ... 93
Figure 4-16 : Spécialisation des caractéristiques : Le rotor à cage ... 94
Figure 4-17: Regroupement des caractéristiques communes: les rotors ... 94
Figure 4-18 : Expression du lien de disjonction au niveau de la Méta-classe des classes ... 95
Figure 4-19: Exemple de disjonction, rotors à cage et rotors bobinés ... 96
Figure 4-20: Expression de la sémantique d'unicité au niveau Méta, exemple du rotor ... 97
Figure 4-21 : Graphe des informations liées au domaine: la base de données ... 98
Figure 4-22 : Caractéristiques des matériaux ... 98
Figure 4-23 : Rattachement de la base de donnée au modèle général ... 99
Figure 4-24 : Utilisation des instances de la base de données ... 99
Figure 4-25 : Sémantique de partage définie dans SHOOD au niveau méta ... 100
Figure 4-26 : Utilisation de la sémantique de partage ... 101
Figure 4-27 : Caractéristiques statiques des attributs utilisateur ... 1 01 Figure 4-28: Valeurs possibles pour deux des caractéristiques des attributs utilisateur ... 102
Figure 4-29 : Visualisation des caractéristiques statiques, le diamètre du ventilateur ... 1 02 Figure 4-30 : Spécialisation de la méthode d'affichage graphique d'une encoche ... 105
Figure 4-31 : Synthèse de la modélisation objet d'un élément du produit à concevoir ... 107
Figure 4-32 : Modélisation d'un point de vue du procruit, le schéma équivalent du moteur ... 1 08 Figure 4-33 : Les deux classes définissant le produit et son modèle ... 109
Figure 4-34 : Uen de muhi-instanciation entre le produit et son modèle ... 109
Figure 4-35 : Uen de muhi-classification explicite entre le produit et son modèle ... 110
Figure 4-36 : Uen de composition explicite entre le produit et son modèle ... 111
Fi~re 4-37 : Granularité de définition des classes utilisateur ... 112
Figure 4-38 : Exemple de traitement rattachée à une classe ... 113
Figure 4-39 : Classes utilisateurs définies pour la machine asynchrone ... 114
Figure 5-1 : Les fenêtres de dialogue de SMECI ... 116
Figure 5-2 : Obtention d'un système dirigé par les faits ... 120
Figure 5-3 : Graphe complet des classes du système OPUS ... 121
Figure 5-4 : Les interfaces graphiques du système OPUS ... 122
Figure 5-5 : Le menu général du système OPUS ... , ... 122
Figure 5-6 : Interface paramètrée d'accès au produit à concevoir ... 123
Figure 5-7: Interface de modification de la stratégie, l'éditeur d'instance de SMECI ... 124
Figure 5-8 : Interfaces d'accès au raisonnement. ... 125
Figure 5-9 : Interfaces de consuitation du produit conçu ... 126
Figure 5-10 : Interface de consuhation du rapport d'activité ... 126
Figure 5-11 : Consultation cru rapport d'activité via l'éditeur d'instances de SMECI ... 127
Figure 5-12 : Graphe des classes définissant l'application de la machine asynchrone ... 128
Figure 5-13 : Règle de définition du cahier des charges ... 129
Figure 5-14 : Stratégie de résolution définie dans notre application ... 130
Figure 5-15 : Préparation d'une session de calcul ... 132
Figure 5-16 : ContrOle du déroulement de la session ... 133
Sommaire
- 11 -
Figure 5-17 : Lors d'une session, affichage dans le terminal SMECI des calcul menés ... 133 Figure 5-18 : Graphe complet de déroulement d'une session ... 134 Figure 5-19 : Configuration de l'affichage d'une solution ... 135 Figure 5-20 : Génération automatiq.Je de l'interface graphique, paramètrisation ... 135 Figure 5-21 : Exemple de rebouclage ... 136 Figure 5-22 : Exemple d'hypothèse multiple ... 137 Figure 5-23 : Consultation d'un historique de calcul, la densité linéique de courant.. ... 138 Figure 5-24 : Choix manuel des actions ... 140 Figure 5-25 : Consultation d'une action ... 140
Figure 6-1 : Consultation d'une règle, édition de la règle donnant le cahier des charges ... 143 Figure 6-2 : Consultation d'un attribut, la tiéquence du réseau du cahier des charges ... 143 Figure 6-3 : Définition d'une nouvelle « facette » des attributs utilisateur ... 144 Figure 6-4 : Détail de la règle de construction graphique de la documentation d'un attribut utilisateur ... 145 Figure 6-5 : Définition de la cohérence via la facette « inverse ... 146 Figure 6-6 : Nouvelle interface de consultation du produit ... 147 Figure 6-7 : Interface possible de consultation ... 148 Figure 6-8 : Exemple de génération d'un hypothèse ... 149 Figure 6-9 : Génération d'hypothèses dans l'arbre des états ... 149 Figure 6-10 : Génération de choix dans l'arbre des états ... 151 Figure 6-11 : Modélisation objet de la sémantique de choix ... 151 Figure 6-12 : Exemple de stratégie de classement vis-à-vis d'un critère, la tâche ... 154 Figure 6-13 : Lltilisation de la méthode de classement dans la stratégie de résolution ... 155 Figure 6-14 : Analyse de la navigation dans un processus de multi-rebouclage ... 158 Figure 6-15 : Exemple de règle de multi-rebouclage ... 159 Figure 6-16 : Modélisation objet de la sémantique de multi-rebouclage ... 160 Figure 6-17 : Héritage de comportements dans le modèle objet.. ... 160 Figure 6-18 : Définition des sémantiques possibles pour un attribut utilisateur ... 161
Sommaire
- 12 -
Avant propos
Je souhaite avant tout faire quelques remarques sur la façon d'exposer les fonctionnalités du système expert qui va être présenté, sur le vocabulaire et les expressions qui seront employées dans ce manuscrit, celles-ci peuvant parfois prêter
à
confusion:Lors de l'exécution d'une session de calcul, l'utilisateur non informaticien du système aura une impression de « spontanéité» ou d'imprévu pour ce qui concerne le raisonnement mené. Il pourra parler « d'enchaînement des règles ", de « génération d'hypothèses» etc. Dans la rédaction de ce mémoire, j'emploierai donc des expressions comme" essayer une solution ", « remettre en cause une hypothèse ", « reboucler par défaut sur une valeur", « valider une hypothèse ", « essayer une structure", « faire un choix de valeur» etc ...
Cette vision fonctionnelle de l'outil est voulue : on désire masquer
à
l'utilisateur le coté« technique informatique» de la résolution.
Cependant, derrière chacune de ces expressions, courtes et imagées, se cache un mécanisme d'exécution ou d'enchaînement de règles d'expertise qui, s'il est souvent simple d'un point de vue fonctionnel, est parfois techniquement un peu complexe mais qui est surtout déterministe.
La compréhension des mécanismes de mise
à
jour des informations implicites ou de navigation dans l'arbre des états, nécessite la connaissance complète de l'implantation des connaissances au sein du système informatique (ici OPUS), ainsi que la bonne maîtrise du langage sur lequelil
repose (Pour le système OPUS, LISP et SMECI).Lorsque l'on connaît la structure complète de cet outil,
il
n'y a aucune surprise ( ...!)
quant au déroulement d'une session età
l'enchaînement des règles: pour toutes les expressions comme pour toutes les fonctionnalités qui seront exposées par la suite, les actions seront effectuées sur la base des informations et des données contenues dans le système et sur la base de la modélisation retenue du processus de conception. Dans un tel système, lors de la résolution du cahier des charges, rien n'est inventé et aucune décision n'est le fruit du hasard.Enfin, les systèmes informatique ayant peu de connaissances en électrotechnique et prenant rarement des initiatives, tout doit être spécifié, consigné, enregistré. La quantité d'informations manipulées est alors très importante, ce qui nous incite
à
bien la répertorier età
bien l'organiser ...- 13 -
1. Introduction
Dans ce chapitre nous allons parler tout d'abord des différentes problématiques de conception et nous verrons comment elles se positionnent les unes par rapport aux autres.
Pour chacune des phases de conception rencontrées nous parlerons ensuite des évolutions techniques qu'elles subissent. Nous verrons également cette évolution au niveau de l'ensemble de la chaîne de production.
Enfin, nous préciserons où se situe notre thème de recherche dans cette problématique.
1 .1 . Problématiques de conception
lorsque l'on parle de conception d'un produit, on englobe dans ce terme un ensemble de problématiques diverses.
Il y a tout au début de la chaîne de production, un besoin qui s'exprime par un cahier des charges. Pour solutionner ce problème on sollicite une équipe chargée de la conception du produit qui répondra à ce besoin.
D'un point de vue technique, l'obtention du produit fini répondant à ce besoin sera obtenu au travers de plusieurs phases [lOWTHER95].
1- Tout d'abord, il y a la conception générale d'une solution répondant globalement au besoin.
C'est ce que nous appellerons la phase de préconception. Suivant le cahier des charges et les contraintes "industrielles" on pourra obtenir cette ébauche de solution, soit à partir de produits déjà existants, soit en partant uniquement des spécifications et en cherchant une solution nouvelle.
la première façon de pré-concevoir en partant de solutions en partie connues est une démarche courante dans l'industrie. la notion de réutilisation peut se faire à plus ou moins grande échelle de la solution finale : Pour une machine électrique par exemple, cela peut aller de la réutilisation de tôles, en passant par la réutilisation de poinçons d'encoches ou de gabarits de bobinages. La réutilisation de ces données dépend de contraintes qui tiennent à la gestion de l'entreprise : gestion des stocks, délais de développement, objectif de réalisation d'une pièce unique ou de grandes séries, coût de développement etc .... On parle parfois de conception par similitude ou de conception routinière. La part de l'expérience dans cette démarche est importante. le concepteur s'appuie dans ce type de conception sur des modèles simplifiés de comportement du produit.
Chapitre 1 Introduction
- 14 -
Nous désignons la seconde approche de la préconception par le terme de conception Înnovante. Dans cette démarche l'expert dispose en général de plus de liberté de développement (temps ou budget) ou alors il cherche à prendre en compte une évolution technologique qui remet en cause les structures de conception usuellement employées (existence d'un nouveau matériau comme les supraconducteurs par exemple). Dans cette démarche, l'obtention de la solution est souvent liée à une approche fonctionnelle de la conception.
2- Une fois le produit ébauché, on utilise des techniques d'optimisation pour améliorer la solution. Cette optimisation se fait aux vues d'un critère donné ou d'une fonction objectif. La notion de coût de fabrication et en général liée à cette fonction objectif. Par exemple, la minimisation du volume de cuivre dans une machine est liée à la baisse de son prix de revient.
Cette étape utilise des modèles de comportement du produit qui sont plus complexes et plus détaillés que précédemment. Il est rare de considérer ici l'expérience du concepteur.
3- Enfin, une fois la solution optimisée, s'ouvre la phase d'analyse et de simulation par des logiciels du type EUCUD, FLUX [FLUX83] etc ....
Dans cette étape d'analyse, la modélisation mathématique du problème cherche à prendre en compte un maximum de caractéristiques physiques du problème : fonctionnement statique ou dynamique, linéaire ou non linéaire. Les outils sont donc généralement des codes de résolution par éléments finis.
4- A l'issue de ces analyses et de ces simulations. on peut alors construire un prototype et faire des essais et des tests pour vérifier les éléments techniques du cahier des charge.
5- Enfin, on lancera la conception réelle du produit final.
Dans toutes ces phases, on peut parler de conception d'un produit. Cependant ces tâches sont bien différentes et sont soumises à des contraintes diverses.
Si ces étapes sont diverses, elles font néanmoins partie du cycle de vie du produit, qui se poursuit par ailleurs du suivi de son utilisation jusqu'à son éventuel recyclage.
Toutes les problématiques de conception qui sont énumérées et ordonnées ci-dessus ont un objectif commun : la satisfaction d'un cahier des charges et au travers de celui-ci, la satisfaction d'un client.
Tous les intervenants dans cette chaîne, chacun à son niveau, sont soumis à la recherche de la meilleure compétitivité, de la meilleure qualité, et de la productivité optimale.
Chapitre 1 Introduction
- 15 -
Lors de la conception d'un produit (conception au sens de l'ensemble de la chaîne exposée plus haut) on va donc chercher
à
gagner du temps et,à
prendre en compte le plus en amont possible des contraintes liées aux intervenants (contraintes de fabrication, contraintes de recyclage, etc .... ).Cette problématique est celle de la conception intégrée.
De ce fait:
1- Si on considère le point de vue de chacun des acteurs, on constate que celui-ci doit formaliser au maximum son activité de conception [ABEL88]. Il est poussé
à
expliciter ses choix età
rationaliser sa démarche. Il demande alorsà
"outil de travail dont il dispose (outil informatique) d'être capable de recevoir cette démarche dans ses étapes les plus élémentaires comme c'était déjà le cas (aide au calcul, au dessin,à
la simulation) mais aussi dans sa complexité (aideà
la décision).On voit donc apparaître actuellement une plus grande sollicitation des outils informatiques.
Ceux-ci cherchent
à
intégrer des démarches plus sophistiquées età
gérer des sémantiques plus fortes.2- Le deuxième point lié
à
cette évolution concerne non pas les besoins de l'acteur visà
vis de son outil de travail, mais concerne en complément les besoins de communication de ,'acteur visà
vis des autres partenaires. Dans cette démarche "entreprise chercheà
faire évoluer chacun des postes de travail existant vers plus de communication. Cette communication doit prendre en compte, elle aussi, le transfert des caractéristiques du produità
concevoir, dans ses éléments les plus simples, mais aussi dans ses sémantiques sophistiquées [NUWENDAM90].Nous ne nous intéresserons pas dans ce travail
à
cette seconde approche de la conception intégrée. Celle-ci està
l'origine de travaux sur la standardisation des échanges de données informatisées ou sur la répartition des tâches entre divers agents [HATON91].Pour chacune des phases de conception exposées plus haut, on peut regarder les évolutions potentielles du travail,
à
la lumière de l'évolution technique des outils.Pour la phase de préconception comme pour la conception innovante, on utilisera des outils
à
base de multi-agents, de systèmes experts, ouà
base d'objets [GSIP93].Pour la phase d'optimisation on pourra faire appel
à
des techniques d'algorithmes génétiques, de réseaux de neurone, de programmation par contraintes ou encore on pourra utiliser des couplages entre outils formels et techniques d'optimisation classique [WURTZ96].Enfin, pour ce qui concerne la phase de simulation et d'analyse, on peut considérer que les nouvelles techniques de programmation et l'évolution du matériel tendent
à
améliorer les performances sans révolutionner les concepts de traitement.Chapitre 1 Introduction
- 16 -
L'évolution des outils de travail de chacun des acteurs tend à faire prendre en compte et à intégrer dans l'outil une partie des connaissances liées à chacun de ces types d'activité. Le modèle sémantique et conceptuel est alors plus complexe. La méthodologie liée à l'activité doit être dégagée.
Dans un souci de formation du personnel comme dans l'exploitation de la documentation de travaii élaborée pour concevoir le produit final, l'outil devra intégrer des capacités d'explications. On utilise alors des techniques d'enseignement assisté par ordinateur (EAO) ou des outils à base d'hypertextes [ABIDI91].
Dans l'ensemble de ces activités de recherche, nous nous limiterons à l'activité de préconception dans le domaine du génie électrique. Dans ce thème d'étude, nous dégageons les objectifs suivants.
1.2. Les objectifs assignés à nos logiciels, nos pré-requis
Dans le laboratoire nous cherchons à développer des logiciels de conception qui sont à destinations des experts du domaine concerné: ici le domaine du génie électrique.
On considère que l'utilisateur de nos logiciels n'a pas besoin de connaissances de programmation de haut niveau en informatique (LISP, C++, connaissance des technologies objet, des systèmes multi-agents, des systèmes expert).
Le logiciel informatique doit être le plus accessible possible, notamment pour ce qui concerne la saisie des règles d'expertise.
La maintenance doit être assurée par un expert et non pas par un spécialiste du produit informatique: l'expert fera évoluer les bases de connaissance, en ajoutant, modifiant les règles d'expertise ou la stratégie de résolution.
En conséquence:
- le logiciel doit bénéficier d'une interface de saisie et de communication performante,
- l'expression des règles d'expertise doit se faire sans la connaissance de l'ensemble des règles contenues dans le système. La formulation des règles d'expertise est donc focalisée sur un problème local.
- l'expert devra pouvoir exprimer ses règles dans un formalisme qui lui est proche (langage
"naturel").
Chapitre 1 Introduction
- 17 -
D'autre part, l'évolution de la base de connaissances et des règles d'expertise implique qu'il n'est pas possible de connaître à l'avance l'ordre d'enchaînement des règles qui sera suivi dans une session de calcul: une règle pourra avoir été retirée, ou éclatée dans plusieurs autres plus précises (à la suite d'une étude spécifique par exemple). On retrouve ici la notion de myopie souhaitée pour la définition d'une règle d'expertise. l'ordre de déclenchement des règles dépendra de la stratégie de résolution définie par l'expert. On trouve dans cet objectif la raison principale qui fait que nos logiciels sont dirigés par les faits.
la possibilité de faire évoluer la base de connaissances au fur et à mesure que de nouveaux experts utilisent le logiciel implique la nécessité de bien documenter ces règles d'expertise. Nous souhaitons ainsi répondre à une demande de capitalisation du savoir-faire.
Cette capitalisation doit comprendre un volant formation à destination d'un utilisateur novice : nous chercherons donc à mettre en place des fonctionnalités de suivi de conception, de traces et d'explication des raisonnements menés.
Nous avons indiqué que nous souhaitions que les experts et les ingénieurs utilisent nos logiciels. Nous cherchons donc à nous approcher de leur propre démarche:
Nous souhaitons que nos logiciels puissent prendre en compte des démarches heuristiques de conception telles que la réalisation d'hypothèses de calcul, de choix de valeurs. On souhaite par là donner à l'expert la possibilité de faire des calculs en parallèle.
L'expert doit aussi pouvoir réaliser des retours en arrière dans ses calculs, dans n'importe quelle branche du raisonnement. On permet ainsi la prise en compte de l'expérience de l'expert.
Dans les deux derniers points exposés, l'existence de différentes branches de résolution (ou mondes parallèles) doit être transparente pour l'expert.
Nous souhaitons aussi que les développements logiciels déjà effectués dans les bureaux d'étude puissent être pris en compte.
Nous souhaitons également prendre en compte des contraintes de dimensionnement. les calculs menés devront s'adapter aux valeurs fixées. Cette démarche implique elle aussi une direction de la résolution par les faits. Par ailleurs, cette fonctionnalité ne pourra être opérationnelle que dans la mesure où un expert aura saisi les règles d'expertises correspondantes.
Enfin, le logiciel étant
à
destination des experts,il
doit intégrer des fonctionnalités assurant la convivialité du dialogue:- Nous devons proposer une gestion des terminologies propres
à
chaque expert.Chapitre 1 Introduction
- 18 -
- Nous devons afficher les grandeurs numériques dans un grand nombre d'unités.
- L'expert aura la possibilité de consulter les solutions calculées par une interface graphique générée automatiquement. Celle-ci sera adaptée
à
l'expert vis-à-vis des points précédents, mais aussi vis-à-vis de l'affichage (procédures de dessin).- L'expert pourra consulter et avoir accès au déroulement du calcul, aux historiques des valeurs.
1.3. Les utilisations possibles d'un tel outil
Les éléments clef de notre approche consistent :
1- à vouloir prendre en compte l'expérience heuristique des experts, par des possibilités d'estimation/rebouclage,
2-
à formaliser explicitement les conditions d'utilisation de ces approches, donc à les capitaliser et3- à chercher à mixer les méthodes de conception,
à
chercher à faire coopérer les experts.Il
n'est pas certain que dans un premier temps, cette démarche reçoive l'accord de tous les experts, notamment pour ceux travaillant au sein d'entreprises éventuellement concurrentes. En effet celles-ci peuvent se sentir dépossédées de leur savoir-faire.Nous pensons cependant que notre approche peut être un atout pour tous ces acteurs, et que ,'on peut utiliser de tels logiciels différemment suivant les objectifs considérés:
- le logiciel est utilisé sans compétence particulière dans le domaine de la conception.
L'utilisateur saisit un cahier des charges et le système tente d'y trouver une solution. Pour protéger le savoir-faire contenu dans le logiciel, l'accès aux informations sensibles doit être bridé (interdiction d'affichage des règles d'expertise etc ... ). L'utilisateur dispose alors du résultat, sans explications sur les règles d'expertises utilisées et le raisonnement mené.
- Pour ce qui concerne les différents experts, leur savoir-faire respectif peut être enregistré dans des fichiers différents. Par la gestion des droits sur ces fichiers, on limite l'accès aux connaissances. Les experts pourront sur la même application exécuter, tour à tour, des sessions de calcul mettant en jeu les règles d'expertise qu'ils auront définies. Chacun d'entre eux a alors à
sa
disposition un outil qui lui permet de faire un grand nombre de raisonnements avec ses propres démarches d'essais/erreur.
Néanmoins,
il
nous semble quel'enjeu scientifique
de tels outils repose sur la recherche de lagestion de cohérence
liéeà
lamulti-expertise.
- Au sein d'une entreprise donnée, on peut aussi utiliser ce type de logiciel comme des outils de transfert de connaissances. Si un expert a explicité ses propres méthodologies de conception au
Chapitre 1 Introduction
- 19 -
sein d'un tel logiciel, l'entreprise conserve une partie de son savoir-faire (lors de son départ
à
la retraite par exemple ce savoir faire peut être consulté par son successeur).Dans tous les modes d'utilisation des logiciels que nous cherchons
à
développer, "exploitation des connaissances par un expert non informaticien est rendue possible par l'existence d'une interface graphique performante.Dans la suite de ce manuscrit, je considérerai toujours l'outil comme étant ouvert au maximum et techniquement non bridé.
1.4. Plan de ce manuscrit
Après cette introduction, nous allons rappeler dans le chapitre 2 quelques notions de base sur les langages
à
objets.Nous exposerons ensuite dans le chapitre 3 le modèle de conception que nous proposons.
Le chapitre 4 a pour objet de proposer un guide méthodologique destiné
à
l'utilisateur de nos logiciels. Ce guide doit faciliter la saisie et la définition du produit de son application.Dans le chapitre 5 nous présentons la maquette (logiciel OPUS) qui met en oeuvre le modèle proposé au chapitre 3.
L'extensibilité de ce modèle est un des atouts de la mise en oeuvre « objets". Nous illustrerons cette extensibilité dans le chapitre 6.
Enfin, compte tenu de l'expérience acquise par "écriture du logiciel, nous indiquerons quels sont les axes de travail et de recherche sur lesquels
il
nous semble intéressant de poursuivre.Chapitre 1 Introduction
- 20-
2. Les langages orientés « objet»
2.1. Introduction
Le logiciel que nous allons présenter dans ce manuscrit a été élaboré
à
partir d'un langageà
objets, [LE-USP91]. et [SMECI92]. Avant de parler du modèle de conception mis en oeuvre dans le logiciel (chapitre 3), nous allons balayer cette technique de programmation dite « orientée objets ".Ce chapitre ne saurait remplacer un cours d'informatique. Nous ne présentons ici que quelques concepts fondamentaux ainsi que le vocabulaire correspondant pour rendre plus aisée la lecture des chapitres suivants.
Le lecteur désireux d'approfondir ces langages
à
objets pourra consulter des ouvrages de spécialistes informaticiens parmi lesquels [MEYER88].Il faut tout d'abord indiquer qu'il existe plusieurs langages
à
objets qui mettent en oeuvre, chacun, plusieurs notions d'objets [SMECI92], C++, SMAL TALK, [SHOOD93]. Les différences entre ces langages résident en général dans les fonctionnalités et sémantiques associées qui sont fournies en standard au programmeur : possibilité de création dynamique de classes, sémantique des liens entre objets, multi-héritage etc ...Certain langages sont dédiés
à
des domaines d'activité particuliers et intègrent donc des fonctionnalités propresà
ces applications. C'est le cas par exemple de [RIEU91 b] qui traite des activités de conception et fabrication assisté par ordinateur (CFAO) et qui intègre des fonctionnalités comme le multi-héritage ou la classification automatique d'instances. C'est le cas de [SMECI92] qui a en partie pour origine les travaux de conception menés dans le domaine de l'aérospatial et qui propose des fonctionnalités comme la gestion de mondes multiples, le prototypage ou la migration automatique d'instances.Dans d'autres langages comme C++ aucune sémantique n'est disponible
à
l'origine. le programmeur peut et doit définir celles dontil
a besoin.Nous allons présenter les quelques concepts de base suivants: la classe, l'attribut, l'instance et la méthode.
Nous verrons le principe d'organisation des classes en graphes de classes et quel intérêt cela représente en terme d'héritage.
Puis nous parlerons du niveau de représentation des données, dit " méta », disponible grâce au concept du " tout objet ».
Enfin, nous aborderons les caractéristiques et les avantages de la programmation
à
partir de langagesà
objets, dans le domaine de la conception.Chapitre 2 : Les langages orientés" objet"
- 21 -
2.2. Les concepts de base des langages orientés
«objet»
2.2.1. Le concept de Classe
Une classe est un concept qui regroupe et qui organise des données. Une classe définit un moule de caractéristiques et de comportements qui seront valables pour toutes les données (appelées instances) rattachées ou appartenant à cette classe.
Pour définir une classe il faut indiquer quelles sont les caractéristiques des données qui appartiennent à cette classe et quels sont les comportements que ('on peut en attendre.
On peut par exemple définir pour un moteur électrique, la classe des
«Ventilateurs ".
La classe ne comporte que la définition des propriétés structurelles et comportementales des données qui lui sont rattachées. La classe n'en porte pas les valeurs.
C'est ainsi que pour la classe des
«Encoches» on spécifie entre autres que celles-ci sont caractérisées ou définies par leur profondeur, leur largeur, etc ...
2.2.2. Le concept d'instance
Pour ce qui est des valeurs numériques ou alphanumériques que peuvent prendre les données appartenant à une classe, la notion d'instance a été définie.
L'instance est la structure informatique qui supporte les valeurs de chacune des caractéristiques qui ont été définies pour la classe.
De ce fait, une instance est toujours rattachée à une classe.
D'un point de vue typographique je noterai toujours le nom d'une classe en commençant par une majuscule et en utilisant le pluriel, pour indiquer que je considère l'ensemble des éléments. Par exemple la classe
«Encoches
».Pour les instances, j'ajouterai un nombre, indiquant ainsi qu'il s'agit d'un élément particulier de la classe : l'instance Encoches-178, qui a par exemple une profondeur de 22mm, une largeur de 5mm etc.
Pour ce qui concerne les conventions graphiques, la relation d'appartenance à une classe (ou
ccinstanciation ») qui relie une instance à sa classe sera représentée par une double flèche comme l'indique la figure ci- contre. Ce formalisme est issu de [GSIP93].
Chapitre 2 : Les langages orientés « objet ..
Figure 2-1 : Exemple de classe et d'instance
- 22-
2.2.3. Le concept d'attribut
Comme on l'a vu, toutes les instances d'une classe ont les mêmes caractéristiques. Ces caractéristiques ou propriétés sont définies au niveau de la classe par les attributs, ou champs de cette classe. Toutes les instances de la classe ont alors cette propriété.
Ainsi, la largeur d'une encoche est l'un des attributs qui a été défini pour la classe des
«Encoches» : toutes les encoches sont caractérisées, entre autres, par leur largeur.
La valeur d'un attribut, au niveau des instances, peut bien sûr différer d'une instance à une autre.
L'Encoches-i78 a une largeur de 5mm, l'Encoches-179 une de 7.
Encoches - largeur
Encoches-178 -5mm
Encoches-l 79 -7mm
Figure 2
m2: Exemple d'attribut
J'utiliserai parfois le verbe
ccinstancier» sur une classe pour indiquer la génération d'une instance de cette classe et/ou pour indiquer l'affectation de valeurs pour l'un ou tous les champs de cette nouvelle instance ou d'une instance existante.
2.2.4. Le concept de méthode
De même que l'on peut définir les caractéristiques qui sont associées aux instances d'une classe et qui sont représentées par les attributs de cette classe, on peut également considérer les comportements que suivent toutes les instances d'une classe.
Ces comportements sont définis entre autres par la notion de méthode rattachée à une classe.
L'accès à ces comportements ou le déclenchement de ces comportements se fait par requête auprès des instances, sous la forme d'envoi de messages et de retour d'un résultat. Ainsi, on envoie à une instance une méthode, en passant d'éventuels arguments, et on obtient en retour le résultat de l'application de la méthode sur l'instance considérée.
Toute activation d'une méthode sur une instance sous-entend l'existence, la définition et le rattachement préalable de cette méthode auprès de la classe qui contient cette instance.
Chapitre 2 : Les langages orientés" objet"
- 23-
Par exemple, on pourra demander à une instance de la classe des encoches, quelle est sa largeur, sa profondeur, mais aussi sa surface, son périmètre, son coût de fabrication etc. Pour y parvenir, il aura été nécessaire que toutes ces méthodes aient été préalablement définies et rattachées à la classe
«Encoches
».2.3. Classes et héritage
Après avoir exposé les concepts de base permettant de décrire l'aspect structurel (la liste des attributs d'une classe) et comportemental (la liste des méthodes associées à une classe) des données d'un problème (les instances d'une classe). on peut aborder une notion importante des langages orientés
ccobjet» : la notion de sous-classe ou spécialisation, qui conduit à la notion d'héritage.
Parmi un groupe de données similaires, donc parmi les instances d'une même classe, il est parfois intéressant d'isoler ou de particulariser un ensemble de ces données car pour celles-ci on peut: soit définir un comportement plus spécifique (donc plus pertinent), soit ajouter des caractéristiques supplémentaires.
Dans le domaine électrotechnique par exemple, on peut considérer l'ensemble des encoches, mais on peut vouloir spécifiquement considérer les encoches à profil rond, oblong, ou encore les encoches profondes etc.
Cette nécessité de particulariser des données d'un ensemble, donc de particulariser des instances d'une classe et d'en constituer un sous-ensemble se traduit par la possibilité de créer une sous-classe d'une classe existante (de la sous-classifier).
Le lien de sous-classification qui existe entre une classe mère et sa classe fille se traduit graphiquement (formalisme de [GSIP93]) par une flèche simple, comme on le voit sur la figure ci- dessous.
1 Encoches-rondes Encoches-profondes
Figure 2·3 : Exemple de sous-classes
Ce lien de sous-classification est directement lié à la notion mathématique de sous-ensemble.
De ce fait il respecte la notion d'inclusion ensembliste des éléments et de leurs propriétés : toutes les
Chapitre 2 : Les langages orientés" objet ..
- 24-
propriétés structurelles ou comportementales qui sont définies au niveau de la classe mère sont et doivent rester vérifiées au niveau de la classe fille.
Toutes les encoches profondes sont des encoches. Par conséquent chacune d'elles a une largeur, une profondeur et on lui associe les mêmes comportements: son calcul de coût, de surlace etc.
la mise en oeuvre technique de ces concepts, qui sont disponibles dans tous les langages orientés C( objet ", implique que la simple définition d'une classe fille n'impose pas la réécriture des propriétés et méthodes qui ont été définies au niveau de la classe mère : elles existent de fait. C'est ce qu'on appelle l'héritage : l'héritage des structures (la liste des attributs) et ('héritage des comportements (la liste des méthodes).
Toutes les instances d'une classe fille héritent donc des comportements de la classe mère.
2.3.1. Intérêt de l'héritage
l'intérêt de l'existence des sous-classes et de l'héritage apparaît
à
plusieurs niveaux dans la programmation d'une application:1- pour la définition de nouvelles propriétés ou de nouveaux comportements, 2- pour la re-définition de ces propriétés ou comportements,
3- pour la sélection automatique de la meilleure méthode
à
appliquerà
une instance donnée, de façon statique, mais aussi4- de façon dynamique. Toute cette organisation des données permet alors
5- de raisonner d'un point de vue fonctionnel, indépendamment des structures manipulées.
Considérons successivement ces différents points :
2.3.2. Définition de nouvelles propriétés
le premier intérêt de la sous-classification concerne la définition de nouvelles propriétés valables pour les instances d'une sous-classe : pour les instances appartenant
à
une sous-classe on peut définir de nouvelles propriétés ou de nouveaux comportements par ajout d'attributs dans la classe fille et par ajout de méthodes rattachéesà
cette classe fille.Par exemple, si on peut définir une largeur et une profondeur pour toutes les encoches,
il
est clair que pour ce qui concerne les encoches oblongues on devra ajouter un certain nombre d'attributs spécifiques permettant la description correcte du profil des encoches oblongues : rayon des arcs de raccordement, hauteur des raccordements, hauteur et largeur de l'isthme.Chapitre :2 : Les langages orientés" objet ..
- 25-
De la même façon que l'on définit des attributs spécifiques à une sous-classe, on peut définir des comportements, donc des méthodes qui ne sont valables que pour les instances de la sous- classe.
2.3.3. Redéfinition des propriétés
Le deuxième intérêt de la sous-classification réside dans la possibilité de redéfinir des attributs ou des méthodes au niveau d'une classe fille. Cela permet, pour les seules instances qui appartiendront à cette sous-classe (donc pour un petit nombre d'éléments), de spécifier des comportements plus spécialisés, plus pertinents donc plus efficaces.
Pour expliciter cela prenons le cas des parallélogrammes, des rectangles et des carrés pour lesquels on peut considérer le graphe des classes suivant:
( Paraléllogrammes - Longueur-1
1 -Longueur-2 - alpha (Rectangles)
l
è
Longueur-1
Figure 2-4 : Exemple de spécialisation des méthodes
La méthode de calcul de surface, S=Longueur-1 x Longueur-2 x sinus(alpha), qui est définie au niveau de la classe mère des
«Parallélogrammes» reste toujours valable quand on manipule un rectangle ou un carré. Cependant on sait qu'il est plus judicieux d'utiliser pour les rectangles S=Longueur-1 x Longueur-2 et pour les carrés S=Longueur-1
2 •Une bonne utilisation de la technique de sous-classification nous conduira donc à redéfinir dans chacune de ces deux sous-classes la méthode de calcul de la surface.
2.3.4. Sélection statique des méthodes
La structure d'héritage des comportements et de redéfinition de comportements plus spécifiques nous conduit à bénéficier de l'avantage cité au point trois ci-dessus : la sélection automatique de la meilleure méthode à appliquer sur une instance.
On vient de voir qu'il était possible sur une classe donnée de définir des méthodes spécifiques à cette classe, d'hériter de méthodes qui existent au niveau de ses classes mère ou encore de redéfinir des méthodes qui existent déjà par héritage. De ce tait, lors du déclenchement d'une méthode sur une instance d'une classe, il convient de sélectionner la meilleure méthode disponible
Chapitre 2 : Les langages orientés « objet ..
