Le diagramme des classes

Dans cette partie, nous détaillons les paquets identifiés dans le paragraphe précédent en expliquant les méthodes, les attributs et les classes relatifs à chacun d’eux. Pour chaque paquet, nous proposons un diagramme de classes dans le formalisme UML ; le diagramme de classes complet est disponible en Annexe C.

2.1.4.1 Les classes du paquet « Spécifications »

Comme nous l’avons présenté dans le chapitre précédent, les premières informations nécessaires à la synthèse de formes sont contenues dans le cahier des charges intermédiaires. Ce dernier, représenté par la classe TCdC (cf. Figure 4-2), est le noyau de l’application. Ses principales méthodes sont :

− Construire_Sol qui construit automatiquement l’espace des solutions à partir d’un ensemble de

contraintes (attribut L_Cont) et d’une bibliothèque de formes. Pour chaque cahier des charges, un espace de solutions est créé ; c’est pourquoi une liste des intervalles de variation des paramètres terminaux de chaque famille de forme est conservé (attribut l_defam) ;

− Evalue_DS estime une forme solution f par rapport à l’ensemble des contraintes du cahier des charges

intermédiaire : c’est le calcul de DS_CdCI(f ) (cf. Chapitre 3, §4.1.1). Ce calcul se fait au niveau de la classe

TCdC puisqu’elle est la seule à connaître l’ensemble des contraintes intermédiaires. Toutefois, elle ne permet pas de calculer directement le degré de satisfaction d’une seule contrainte. Cette tâche est réalisée par la méthode Evalue relative à la classe TContrainte ;

− enfin, cette classe est aussi la seule à connaître l’espace des solutions, de ce fait, elle est la seule à pouvoir présenter de manière conviviale les solutions les plus prometteuses au concepteur : ceci est réalisé par la méthode Morpher. Néanmoins, par souci de simplification et de gain de temps, le parcours de l’espace des solutions implémenté se résume à parcourir à l’aide d’un pas régulier les intervalles de variation de chaque paramètre terminal. Il est bien évident que ce parcours tient compte du produit cartésien de ces intervalles ;

− Charge permet le chargement d’un cahier des charges décrits de manière textuelle dans un fichier.

Espace des Solutions Spécifications Expressions Bibliothèque de Formes Estimation

Chapitre 4 Réalisation informatique et application industrielle

Thèse de l’université de Metz soutenue le 12 Janvier 2000 – D. Pallez 104

Nous présentons ultérieurement le format du fichier à utiliser. Dans le futur, cette méthode pourrait interpréter un cahier des charges écrit en langage naturel pour en extraire les contraintes intermédiaires.

La classe TCdC représente la seule communication entre notre méthodologie de synthèse de formes satisfaisantes et l’interface de dialogue de notre application.

Dans le chapitre précédent, nous avons supposé que nous traduisions les fonctions en contraintes sur des paramètres intermédiaires. Ceci nous a permis de proposer une modélisation pour l’objet contrainte qui est : <Paramètre, Relation, Expression, Poids> en sachant que les trois premières composantes sont des classes des paquets « Expressions » et « Estimation ». Mais, il est possible que d’autres types de contraintes existent : en l’occurrence, des contraintes de types conditionnelles que nous pourrions appeler « algorithmiques » si la complexité de la contrainte conditionnelle vient à croître considérablement. De ce fait, le diagramme de classes comporte deux sous-classes TCParametric et TCAlgorithmic. La classe

TContrainte, considérée comme la classe de base des deux précédentes, permet de regrouper les

propriétés et les méthodes communes à ses sous-classes (ou classes dérivées) qui sont :

− l’importance de la contrainte par rapport aux autres contraintes du cahier des charges, représentée par l’attribut Poids ;

− la possibilité d’estimer le degré de satisfaction de cette contrainte par rapport à une forme solution considérée. Ceci est modélisé par la méthode virtuelle Evalue.

2.1.4.2 Les classes du paquet « Espace des solutions »

Toujours dans le chapitre précédent, nous avons montré comment les contraintes intermédiaires devaient être traduites (aussi automatiquement que possible) en contraintes terminales sur les paramètres

TCAlgorithmic Evalue() : T ReelE TCParametric Evalue() : T ReelE operator==() 1 +param 1 TContrainte poids : T_Reel = 0 seuil : T_Reel = 0 Affiche : Bool = False

Evalue() : TReelE operator==()

T CdC Charge(T Chaine) : void Enregistre(T Chaine) : void Evalue_DS(T _EtatVar) : T ReelE Ajoute(TContrainte) : void Suppr(TContrainte) : Bool Suppr(int) : void EstParam(T Chaine) : Bool Construire_Sol() Morpher() 1..* 1..* +L_Cont 0..* +l_defam 0..*

2 Mise en œuvre

terminaux de chaque classe de forme. Par ailleurs, nous avons précisé que les contraintes terminales devaient s’exprimer sous la forme d’intervalles. Comme les paramètres terminaux d’une classe de forme sont interdépendants, les bornes des intervalles de variation doivent se représenter à l’aide de deux expressions mathématiques. De ce fait, la classe TIntervalle (cf. Figure 4-3) modélise un intervalle de variation d’un seul paramètre terminal. Comme dans la grande majorité des cas, le cahier des charges intermédiaire est constitué de plusieurs contraintes, il s’ensuit une multiplicité d’intervalles de variation pour un seul paramètre terminal. De plus, le produit cartésien de plusieurs intervalles peut donner lieu à une discontinuité du domaine de variation d’un seul paramètre. Ainsi, la classe TDomDefParam permet de modéliser le domaine de variation d’un paramètre (attribut param) en conservant une liste d’intervalles (représenté par l’attribut L_Int).

Enfin, la classe TdomDefFamille permet de conserver le domaine de variation de tous les paramètres terminaux d’une classe de forme par l’attribut l_domp. La principale méthode de cette dernière classe correspond au parcours de l’espace des solutions. En effet, les domaines de variation des paramètres d’une classe de forme correspond à l’espace des solutions relatifs à cette classe de formes.

2.1.4.3 Les classes du paquet « Estimation »

Une fois l’espace des solutions construit, nous avons présenté dans le chapitre précédent une méthode permettant d’estimer une forme par rapport à l’ensemble des contraintes du cahier des charges intermédiaire. Cette méthode consiste à calculer le degré de satisfaction d’une contrainte à partir des valeurs réelles et désirées du paramètre intermédiaire utilisé dans la contrainte. Le calcul se fait en utilisant une courbe dépendante de la relation utilisée dans la contrainte (≥, ≤, ≠, =). La classe TRelation (cf. Figure 4-4) permet de modéliser les différentes relations mathématiques gérées par l’application. Le seul attribut associé à cette classe est le nom de la relation (attribut label). Par ailleurs, nous avons vu que plusieurs courbes pouvaient être associées à la même relation mathématique : les courbes normales et les courbes améliorées. La classe TRelContinue permet de représenter différentes méthodes d’estimation pour la même relation mathématique. Par souci de simplification et de gain de temps, les courbes utilisées pour le calcul de l’estimation sont celles définies au paragraphe 4.1.2 du Chapitre 3. De ce fait, les quatre relations mathématiques sont définies par une seule expression mathématique représentée par l’attribut

exp. La principale méthode de la classe est représentée par Evalue qui permet de calculer le degré de

TDomDefParam Discontinue() : Bool Prochaine_Val() : T ReelE AjouteInter(TIntervalle*) : void 1..* +L_Int 1..* +param 1 T DomDefFamille ev : TEtatVar Ajoute(TDomDefParam) : void Supp(TDomDefParam) : void Supp(i) : void Parcourir() EstVide() : Bool Fusion(TDomDefFamille) : void 1..* +l_domp 1..* 1 +forme 1 TIntervalle Deb : Expression Fin : Expression 1

Chapitre 4 Réalisation informatique et application industrielle

Thèse de l’université de Metz soutenue le 12 Janvier 2000 – D. Pallez 106

satisfaction d’une contrainte à partir des valeurs réelle et désirée du paramètre intermédiaire.

2.1.4.4 Les classes du paquet « Bibliothèque de formes »

La méthode de synthèse de forme que nous avons présenté dans le chapitre précédent consiste à utiliser des formes primitives prédéfinies. Comme toutes ces formes sont supposées utiliser des paramètres terminaux (attribut L_Param), nous définissons une classe virtuelle (ne pouvant pas être instanciée) qui exprime les particularités de toutes les formes primitives : c’est la classe TFamilleForme (cf. Figure 4-5). De cette classe est dérivée un certain nombre de primitives pouvant être instanciées : TRectangle,

TCercle, TTriangle. Nous avons aussi ajouter une classe TCombine2D qui permet de combiner des

formes primitives pour constituer une forme complexe (Chapitre 3, §3.4.4). Néanmoins, cette possibilité n’a pas été plus développée.

L’autre grande particularité de la classe TFamilleForme se situe au niveau des méthodes Traduction

et CalculParametre, répercutée aux différentes sous-classes, qui traduisent les règles et les algorithmes

de la Figure 3-15 : traduire une contrainte intermédiaire en intervalles de variation des paramètres terminaux propre à la famille de forme et calculer la valeur réelle du paramètre intermédiaire utilisée dans la contrainte à partir des valeurs des paramètres terminaux.

2.1.4.5 Classes du paquet « Expressions »

La classe Expression de la Figure 4-6 permet de modéliser une expression mathématique ; en réalité, elle se décompose en une hiérarchie de classes plus complexe, mais l’étude de cette hiérarchie sort du cadre de ce manuscrit. Le fait que la classe TParametre hérite de la classe NVariable qui elle-même hérite de la classe Expression permet de définir des expressions mathématiques utilisant des paramètres intermédiaires. L’intérêt se situe au niveau de la définition des contraintes intermédiaires : un paramètre intermédiaire peut être contraint par un autre paramètre intermédiaire défini préalablement dans le cahier

TRelation label : TChaine

Evalue(valeur_param, valeur_const) : TReelE Label() : TChaine

T RelContinue pente : Reel = 1

Evalue(valeur_param, valeur_const) : TReelE +ev 1 +exp 1 1 1

Figure 4-4. Classes du paquet estimation

T Cercle

TRectangle T Triangle

TCombine2D

TFamilleForme

Traduction(TContrainte*) : TDomDefFamille* CalculParametre(TParametre, TEtatVar) : TReelE Affiche() 1..* +L_Param 1..* 1..* 1..*

2 Mise en œuvre

des charges. Enfin, la classe TEtatVar contient la liste de toutes les variables utilisées dans les expressions mathématiques ainsi que leur valeur numérique associée si elle a été calculée (classe TReelE).

Les algorithmes et équations mathématiques utilisés d’une part pour traduire des contraintes intermédiaires en contraintes terminales et, d’autre part, pour calculer la valeur réelle d’un paramètre intermédiaire à partir de paramètres terminaux ne constituent pas une classe en soi dans la mesure où ils sont directement inclus dans le code source de notre application. Pour bien faire, une classe

TRègle_Métier devrait être définie. De cette façon, elle pourrait se dériver en deux sous-classes

TTraduit_Contrainte et Calcul_VR. Toutefois, cette modélisation aurait nécessité l’interprétation de

règles comme cela est fait dans les systèmes experts à base de règles. Or, notre souci est de démontrer la faisabilité de notre approche et non de développer un logiciel complet permettant de passer de contraintes à des formes satisfaisantes. L’intégration des règles dans le code source nous a permis un gain de temps notable.