Comparaison d’algorithmes de construction de hiérarchies de classes Robert Godin, Thuy-Tien Chau Département d’Informatique Université du Québec à Montréal C.P.8888, Succursale Centre Ville Montréal, Québec Canada, H3C 3P8 (514) 987-3000 (ext. 3088) Fax: (514) 987-8477 [email protected]

Résumé Plusieurs algorithmes ont été proposés pour la construction de hiérarchies de classes à partir de la spécification de leurs propriétés. Entre autres, les algorithmes proposés dans (Dicky, Dony, Huchard & Libourel, 1994) et (Godin, Mineau & Missaoui, 1995a) préservent la structure de sous-hiérarchie de Galois de la relation entre les classes et leurs propriétés. De plus ces algorithmes peuvent incorporer de nouvelles classes à une hiérarchie existante. Le résultat est une hiérarchie qui garantie la factorisation maximale des propriétés et la conformité avec la relation de spécialisation entre les classes. Les deux algorithmes ont été implémentés dans un environnement commun afin de comparer leurs performances. Les résultats d’expériences sont rapportés et analysés. Mots clés: sous-hiérarchie de Galois, algorithmes, hiérarchie de classes

Comparaison d’algorithmes de construction de hiérarchies de classes

1.

2

INTRODUCTION

La conception et la maintenance de la hiérarchie des classes est une des activités les plus difficiles et les plus importantes de l’approche objet (Booch, 1994). Plusieurs chercheurs ont proposés l’utilisation d’algorithmes afin de supporter ces activités (Casais, 1991; Dicky et al., 1994; Dicky, Dony, Huchard & Libourel, 1996; Dvorak, 1994; Godin & Mili, 1993; Lieberherr, Bergstein & Silva-Lepe, 1991; Moore, 1996). Parmi ceux-ci, plusieurs se sont intéressés à l’utilisation de structures basées sur la notion de treillis de Galois. Entre autres, les algorithmes proposés dans (Dicky et al., 1994) et (Godin et al., 1995a) produisent des hiérarchies qui correspondent à la notion de sous-hiérarchie de Galois (Dicky et al., 1994) (aussi appelée treillis de Galois élagué (Godin, Mineau, Missaoui & Mili, 1995b)) de façon incrémentale. Le fait d’être une sous-hiérarchie de Galois garantie la factorisation maximale des propriétés (Dicky et al., 1994) et la conformité à la relation de spécialisation (Godin & Mili, 1993). Ces deux caractéristiques sont généralement vues comme des qualités importantes des hiérarchies de classes (Casais, 1991; Dicky et al., 1996; Johnson & Foote, 1988; Lalonde, 1989; Lieberherr et al., 1991; Liskov, 1988). En étant basée sur un cadre théorique bien défini, la hiérarchie produite est donc indépendante de spécificités algorithmiques, ou de paramètres ajustables ou de l’ordre d’arrivée des classes contrairement à beaucoup des travaux sur les méthodes incrémentales de classification conceptuelle (Fisher & Pazzani, 1991; Gennari, Langley & Fisher, 1990) et de construction de hiérarchies de classes (Casais, 1991; Dvorak, 1994; Lieberherr et al., 1991). L’utilisateur aura tendance à avoir plus confiance dans le résultat d’un algorithme si celui-ci repose sur une conceptualisation claire du résultat attendu. Dans cet article, nous comparons les deux algorithmes de génération incrémentale de la sous-hiérarchie de Galois. La section 2 fait un rappel des notions de base. La section 3 décrit les principales caractéristiques des algorithmes. Des résultats empiriques sont aussi donnés pour comparer les performances des deux algorithmes.

2.

DÉFINITIONS

Cette section fait un rappel des définitions de base d’un treillis de Galois et d’une sous-hiérarchie de Galois.

2.1. Treillis de Galois La définition de treillis de Galois est présentée à partir d’un exemple portant sur la hiérarchie d’interface d’un ensemble de classes et en empruntant la notation de Wille . Plus de détails sur le sujet peuvent être trouvés dans (Barbut & Monjardet, 1970; Davey & Priestley, 1992; Wille, 1992).

Comparaison d’algorithmes de construction de hiérarchies de classes

3

Selon la terminologie de Wille (1992), un contexte formel est un triplet (G, M, I) où G et M sont deux ensembles finis et I est une relation binaire entre G and M, i.e. I ⊆ G × M. La notation gIm est utilisée pour représenter que (g,m) ∈ I. Étant donnés A ⊆ G et B ⊆ M, définissons: A’ = {m ∈ M | (∀g ∈ A) gIm } et B’ = {g ∈ G | (∀m ∈ B) gIm }. Un concept du contexte (G, M, I) est défini comme un couple (A, B) où: A ⊆ G , B ⊆ M, A’=B et B’=A. Les concepts sont partiellement ordonnés par: (A1, B1) • (A2, B2)si A1 ⊆ A2 (ce qui est équivalent à B2 ⊆ B1 ). L’ensemble de tous les concepts du contexte (G, M, I) avec la relation • est un treillis complet appelé treillis de concept s (ou treillis de Galois (Barbut & Monjardet, 1970)) du contexte et est noté ici CL(G, M, I). L’ensemble G est habituellement appelé ensemble d’objets et M ensemble d’attributs. Pour l’application qui nous concerne, G représente un ensemble de classes et M représente un ensemble de propriétés de ces classes. Les propriétés utilisées peuvent être de diverse nature incluant les attributs (variables d’instances), les sélecteurs de messages et les méthodes elles-mêmes. La Figure 2.1.1 montre un exemple de contexte représenté par une matrice Booléenne. Dans l’exemple, seuls les noms des sélecteurs de messages apparaissent comme propriétés des classes. En général, d’autres types de propriétés peuvent être considérées. L’exemple de la Figure 2.1.1 est extrait de (Cook, 1992) and représente un sous-ensemble des interfaces pour un sous-ensemble des classes Collection de la librairie de ObjectWorks Smalltalk. Un sélecteur de message est en relation avec une classe par la relation I s’il fait partie de l’interface de la classe, i.e. l’ensemble des messages auxquels la classe peut répondre. La syntaxe exacte des sélecteurs n’est pas respectée dans l’exemple. Les noms donnés sont formés par la concaténation des mot-clés des arguments de chaque sélecteur. La Figure 2.1.2 montre le treillis de Galois correspondant. Seuls la première lettre de chaque nom de classe n’apparaît dans la Figure. L’ordre partiel entre les concepts est utilisé pour générer le graphe de la manière suivante: il y a un arc (C1, C2) si C1 < C2 et s’il n’y a aucun autre concept C3 dans le treillis tel que C1 < C3 < C2. C1 est appelé parent de C2 et C2 enfant de C1. Le graphe est habituellement appelé diagramme de Hasse de la relation d’ordre. L’orientation des arcs est implicite (ici vers le haut).

4

Comparaison d’algorithmes de construction de hiérarchies de classes

isEmpty size includes add remove minus addWithOccurrences at atput atAllPut first last addFirst addLast keys values

Set

Bag

Dictionary

1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0

1 1 1 1 1 0 1 0 0 0 0 0 0 0 0 0

1 1 1 1 0 1 0 1 1 0 0 0 0 0 1 1

Linke d List 1 1 1 1 1 0 0 1 0 0 1 1 1 1 0 0

Array

1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0

Figure 2.1.1. Représentation matricielle du contexte. ({A,D,LL,B,S}, {isEmpty,size,includes}) ({A,D,LL}, {isEmpty,size,includes,at})

({D,LL,B,S}, {isEmpty,size,includes,add})

({A,D}, ({D,LL}, ({A,LL}, {isEmpty,size, {isEmpty,size, {isEmpty,size, includes,at, includes,at, includes,at, atput}) add}) first,last})

({A}, ({D}, {isEmpty,size, {isEmpty,size, includes,at, includes,at, atput,atAllPut, atput,add, first,last}) minus, keys,values})

({D,S}, ({LL,B,S}, {isEmpty,size, {isEmpty,size, includes,add, includes,add, minus}) remove})

({LL}, ({S}, ({B}, {isEmpty,size, {isEmpty,size, {isEmpty,size, includes,at, includes,add, includes,add, add,first,last, minus, remove, remove, remove}) addWithOccurrences}) addFirst, addLast}) (Ø, {all method selectors})

Figure 2.1.2. Treillis de Galois du contexte de la Figure 2.1.1. Dans cet exemple, le treillis correspond à la hiérarchie d’interface de l’ensemble des classes. Le principe général peut être utilisé pour d’autres types de spécification de classes incluant la distinction

5

Comparaison d’algorithmes de construction de hiérarchies de classes

entre les méthodes et leur interface, et les relations de spécialisations entre les méthodes. La prise en compte de ces relations est traitée dans (Dicky et al., 1996; Godin & Mili, 1993). De plus, dans (Dicky et al., 1996) on montre comment certains cas de spécialisations entre méthodes peuvent être identifiés automatiquement à partir du code source.

2.2. Treillis d’héritage Le treillis de Galois tel que représenté à la section précédente n’est pas adéquat pour les hiérarchies de classes à cause de la redondance de cette représentation. Pour un concept C = (A, B), A est présent dans tous les ancêtres de C and symétriquement, B apparaît dans tous ses descendants. Pour la conception des hiérarchies de classes, cette duplication doit être éliminée car le mécanisme d’héritage permet de retrouver l’information. Pour un concept C = (A, B), notons par AN les éléments non redondants de A, et BN les éléments non redondants de B. Un treillis d’héritage de Galois est représenté par l’ensemble des couples (AN, BN). La Figure 2.2.1 est le treillis d’héritage correspondant au treillis de la Figure 2.1.1. Du point de vue de la conception des classes, l’idée consiste à considérer les concepts comme des classes et le graphe comme la relation d’héritage. BN constitue donc l’ensemble des propriétés à déclarer dans la classe. Comme chaque propriété n’apparaît qu’une seule fois, on obtient une factorisation maximale des propriétés communes des classes initiales. Des nouvelles classes peuvent être créées à cet effet. Dans l’exemple, on obtient une hiérarchie où chaque interface n’est déclarée qu’à un seul endroit. On peut étendre ces principes à des spécifications où l’on tient compte de la surcharge des sélecteurs. On obtiendra ainsi une hiérarchie où chaque interface et chaque méthode est déclaré à un et un seul endroit dans la hiérarchie. (Ø, {isEmpty,size,includes}) (Ø, {at})

(Ø, {atput})

({Array}, {atAllPut})

(Ø, {add})

(Ø, Ø)

({Dictionary}, {keys,values})

(Ø, {first,last})

({LinkedList}, {addFirst, addLast})

(Ø, {minus})

(Ø, {remove})

({Set}, ({Bag}, Ø) {addWithOccurrences})

(Ø,Ø)

Figure 2.2.1. Treillis d’héritage.

6

Comparaison d’algorithmes de construction de hiérarchies de classes

2.3. 2.3 Sous-hiérarchie de Galois Pour le problème de conception des hiérarchies de classes, il peut être très avantageux de considérer un sous-ensemble du treillis de Galois. En particulier, on peut éliminer les noeuds vides du treillis d’héritage sans perdre d’information. Le résultat est appelé sous-hiérarchie de Galois (Dicky et al., 1994) ou treillis de Galois élagué (Godin et al., 1995b). La complexité de la sous-hiérarchie peut être de beaucoup inférieure au treillis complet. On obtient ainsi une hiérarchie plus compacte qui préserve les caractéristiques de factorisation maximale et de conformité à la relation de spécialisation. L’inconvénient est que la structure n’est plus nécessairement un treillis et que certaines abstractions potentiellement utiles sont éliminées. La Figure 2.3.1 montre la sous-hiérarchie correspondant à l’exemple de la Figure 2.2.1. On peut remarquer que deux concepts vides ont été éliminés.

(Ø, {isEmpty,size,includes})

(Ø, {at})

(Ø, {atput})

({Array}, {atAllPut})

(Ø, {add})

(Ø, {first,last})

({Dictionary}, {keys,values})

({LinkedList}, {addFirst, addLast})

(Ø, {minus})

(Ø, {remove})

({Set}, ({Bag}, Ø) {addWithOccurrences})

Figure 2.3.1. Sous-hiérarchie de Galois pour l’exemple de la Figure 2.1.1.

3.

ALGORITHMES ET EXPÉRIENCES

Deux algorithmes ont été proposés pour générer la sous-hiérarchie de Galois de façon incrémentale (Dicky et al., 1994; Godin et al., 1995a). Avec ces algorithmes, on peut insérer une nouvelle classe à une hiérarchie existante en produisant si nécessaire de nouvelles classes de factorisation et en modifiant la topologie du graphe d’héritage en conséquence. Les classes utilisées en intrant sont appelées classes de base.

Comparaison d’algorithmes de construction de hiérarchies de classes

7

Dans ce qui suit nous présentons l’algorithme AISGOOD en faisant ressortir les différences majeures avec ARES (Dicky et al., 1994). L’algorithme AISGOOD est essentiellement le même algorithme que l’algorithme proposé dans (Godin et al., 1995a). Une modification mineure a été apportée afin de forcer la création d’une classe pertinente même si l’ensemble des propriétés BN de la classe est vide. Les classes de bases utilisées en input sont habituellement considérées comme étant pertinentes car ce sont normalement des classes instantiables. On veut donc qu’elles apparaissent explicitement dans la hiérarchie. La Figure 3.1 montre les modifications effectuées par AISGOOD pour insérer la nouvelle classe Dictionary à la hiérarchie qui aurait été précédemment produite pour l’ensemble des classes {Array, Linked List, Bag, Set}. Les propriétés sont les mêmes que dans les exemples précédents. La nouvelle classe Dictionary possède donc les sélecteurs {isEmpty, size, includes, add, minus, at, atput, keys, values}. Dans la Figure 3.1, chaque classe correspond au couple (A, BN) plutôt que (AN, BN) tel que défini pour la sous-hiérarchie de Galois. En effet, il est nécessaire de calculer soit l’ensemble des classes (A) ou l’ensemble des propriétés (B) en extension pour le traitement de mise à jour du graphe. On peut soit le maintenir explicitement ou le recalculer au besoin. Nous avons choisi de maintenir A plutôt que de le calculer, le coût en espace étant raisonnable. On aurait pu choisir de maintenir B en extension. C’est cette dernière alternative qui est utilisée dans ARES. Dans l’algorithme, la nouvelle classe de base à ajouter est notée g* et son ensemble de propriétés est {g*}’. Pour une classe C, A(C) représente son ensemble de classes et BN(C) son ensemble de propriétés. Les lignes 1 à 16 de l’algorithme déterminent les changements à effectuer aux classes existantes et créent de nouvelles classes si nécessaire. Dans la Figure 3.1 les nouvelles classes sont représentées en gras. Seules les classes ayant au moins une propriété en commun avec la nouvelle classe ne sont visitées. L’accès à ces classes est effectué à l’aide d’un index P qui pour chaque propriété, m, indique la classe où elle se trouve, P(m). Au départ, l’algorithme produit une partition des propriétés de g* en sous-ensembles (S) qui se trouvent dans la même classe (PS). Les nouvelles propriétés sont rassemblées dans Sn.. Ensuite ces classes sont visitées une par une dans un ordre quelconque. Dans l’exemple, on obtient la partition suivante: {at}: classe #2 {add}: classe #3 {atput}: classe #4 {minus}: classe # 6 Sn ={keys, values}: nouvelles propriétés. Une classe sera modifiée si toutes ses propriétés sont incluses dans {g*}’ (lignes 5-6). Dans ce cas, on ajoute g* à son ensemble A. C’est le cas de la classe #1. Dans le cas contraire, on extrait les propriétés communes pour en faire une nouvelle classe de factorisation (lignes 7-11). Dans la Figure 3.1, les propriétés extraites apparaissent en italique. Les classes d’où sont extraites les propriétés sont en quelque sorte les génératrices des nouvelles classes. Les classes #8, #9, #10 et #11 sont ainsi créées à partir des génératrices, #2, #3, #4, #6 respectivement. Une nouvelle classe devient toujours un parent de sa classe génératrice. Une nouvelle classe est aussi créée si g est spécifiée comme étant pertinente ou si de nouvelles propriétés sont présentes (lignes 13-16). Par exemple, la classe #12 est créée pour les nouvelles propriétés {keys, values}. Le reste de l’algorithme (ligne 17-45) s’occupe de mettre à jour les arcs du graphe. Dans la Figure 3.1, les nouveaux arcs sont en gras et les arcs à éliminer sont en pointillés. Dans les lignes 17-24, le lien entre une classe génératrice et un parent qui a été modifié est remplacé par l’arc entre la nouvelle classe

Comparaison d’algorithmes de construction de hiérarchies de classes

8

et le parent modifié. Par exemple, l’arc (#1,#2) est remplacé par (#1,#8) et (#1,#3) par (#1,#9). La section 25-35 supprime les arcs entre une classe modifiée et un parent non modifié. Ce parent doit dans certains cas être relié avec des sous-classes qui n’ont pas été modifiées. La section 36-45 ajoutent les liens qui manquent entre les classes traitées par une vérification exhaustive des combinaisons possibles. Cette section de l’algorithme pourrait être grandement améliorée. Cependant, le gain serait mineur à cause du nombre limité de classes concernées. Si l’on suppose qu’il y a une borne supérieure, k, sur le nombre de propriétés par classes alors le nombre de classes traitées est borné par k (en supposant une factorisation maximale). En effet, dans le pire cas, chaque propriété de g* sera dans une classe différente de la hiérarchie existante. Le nombre de classes visitées est donc borné par une constante qui ne dépend pas du nombre de classes de la hiérarchie. Le temps de traitement de l’algorithme est donc essentiellement de l’ordre d’un polynôme en k. On obtient donc une complexité qui ne dépend pas du nombre de classes dans la hiérarchie. Le seul traitement qui en théorie n’est pas borné par k est celui de la section 25-35 de l’algorithme. Contrairement au reste de l’algorithme, ce traitement n’est pas borné par k, car le nombre d’enfants d’une classe n’est pas borné par k. En pratique, ce pire cas est cependant assez rare. Contrairement à AISGOOD, ARES (Dicky et al., 1996) effectue le travail en parcourant toutes les classes de la hiérarchie initiale selon une extension linéaire de la relation d’ordre partiel. Le fait de parcourir toute la hiérarchie implique une complexité de l’ordre de grandeur de la hiérarchie. En supposant que chaque classe de base utilisée pour produire la hiérarchie soit représentée, ce qui habituellement le cas, on obtient une complexité au moins du même ordre de grandeur que le nombre de classes de base. Si n est le nombre de classes de base, on obtient donc une complexité O(n) au minimum. L’analyse détaillée donnée dans (Dicky et al., 1996) est en accord avec ceci. L’utilisation d’une extension linéaire dans ARES a pour but de garantir qu’avant de visiter une classe, tous ses ancêtres seront visités. L’algorithme compare alors les propriétés déclarées dans la classe avec les propriétés de la nouvelle classe afin de déterminer s’il est nécessaire de créer une nouvelle classe de factorisation en extrayant de la classe existante les propriétés communes. Ceci peut avoir pour effet de vider une classe existante qui devra être éliminée par la suite sauf si la classe a été marquée comme étant pertinente. Dans AISGOOD, plutôt que de créer une nouvelle classe de factorisation et de vider la classe visitée lorsque toutes les propriétés de la classe visitée sont incluses dans la nouvelle classe à ajouter, on modifie tout simplement la classe existante (cas des classes modifiées). L’impact de cette différence de stratégie est cependant assez mineur car le nombre de classes touchées est encore borné par k. Dans ARES, au fur et à mesure de la visite de la hiérarchie, on construit l’ensemble des ancêtres de la nouvelle classe, noté SH. Cet ensemble sert à la mise à jour des arcs du graphe. L’ordre de visite des noeuds garantit que les parents d’une classe seront déjà dans l’ensemble SH au moment de visiter la classe. La recherche des parents est donc effectuée au moment de la création de la nouvelle classe. Il est intéressant de noter que cette stratégie est très semblable à celle proposée dans (Godin et al., 1995c) pour générer le treillis de Galois complet. Ceci est un avantage par rapport à AISGOOD qui visite les classes dans un ordre quelconque. Il est donc nécessaire dans AISGOOD d’attendre que toutes les classes soient visitées avant d’effectuer le travail de mise à jour des parents d’une nouvelle classe. Le résultat est une complexité accrue du fait que l’ensemble des classes à considérer n’est pas contraint par le contexte. L’impact est cependant assez limité car le nombre de classes touchées est borné par k.

Comparaison d’algorithmes de construction de hiérarchies de classes ALGORITHME AISGOOD Input: g*: :nouvelle classe; {g*}’ : l’ensemble des propriétés de la nouvelle classe; index P: P(m) pointe vers la Classe contenant la propriété m; H: la hiérarchie à mettre à jour Pertinente(g*): indique si la classe est pertinente Output: H: la hiérarchie mise à jour P: index mis à jour BEGIN 1. NouvellesClasses:=Ø; ClassesModifiées:=Ø; 2. Partitionner l’ensemble {g*}’ en sous-ensembles de propriétés qui sont dans la même classe de H (i.e. même valeur de P(m) pour toutes les propriétés de la partition); 3. Sn:= l’ensemble des nouvelles propriétés de{g*}’ (absentes des classes de H); 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

{Modifier les classes existantes et créer les nouvelles classes de factorisation} POUR chaque sous-ensemble S de la partition (la classe correspondante est notée PS) SI BN(PS) ⊆ {g*}’ ALORS {C’est une classe modifiée} Ajouter g* à A(PS); Ajouter PS à ClassesModifiées SINON {C’est une nouvelle classe} Créer nouvelle classe Pn= (BN(PS) ∪{g*},S); BN(PS):= BN(PS) - S; Pour tous les m dans S: P(m):=Pn; Ajouter arc (Pn,PS); Ajouter Pnà NouvellesClasses FINSI FINPOUR; SI Pertinente(g*) ou Sn • Ø Créer nouvelle classe Pne = ({g*}, Sn); Pour tous les m dans Sn: P(m):=Pne; Ajouter Pne à NouvellesClasses FINSI;

17. 18. 19. 20. 21. 22. 23. 24.

{Remplacer lien entre génératrice et parent modifié par lien entre nouvelle classe et le parent modifié} ClassesTraitées:=ClassesModifiées ∪ NouvellesClasses; POUR chaque Pn ∈ NouvellesClasses SI Pn possède un enfant Pg {pas le cas pour Pne} POUR chaque parent Pa de Pg SI Pa ∈ ClassesModifiées ALORS Supprimer arc (Pa, Pg); Ajouter arc (Pa,Pn) FINSI FINPOUR FINSI FINPOUR;

25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.

{Mettre à jour les arcs entre classes modifiées et leurs parents qui n’ont pas été modifiés} POUR chaque classe Pm ∈ ClassesModifiées POUR chaque parent Pa de Pm SI Pa∉ ClassesModifiées ALORS Supprimer arc (Pa,Pm); PCS=Ø; ChercherEnfantsPotentiels(PCS,Pm); POUR chaque Pc ∈ PCS SI ¬∃ Pb ∈ PCS ou ¬∃ un enfant Pb de Pa avec Pb ∉ ClassesTraitées tel que A(Pb) ⊆ A(Pc) ALORS Ajouter arc (Pa,Pc) FINSI FIN POUR FINSI FINPOUR FINPOUR;

36. 37. 38.

{Ajouter les liens qui manquent entre les classes traitées} POUR chaque Pa∈ ClassesTraitées POUR chaque Pc ∈ ClassesTraitées SI Pc n’est pas un enfant de Pa ALORS

9

Comparaison d’algorithmes de construction de hiérarchies de classes

10

39. SI ¬∃ Pb ∈ ClassesTraitées tel que A(Pa) ⊆ A(Pb) ⊆ A(Pc) ALORS 40. Ajouter arc (Pa,Pc) 41. FINSI 42. FINSI 43. FINPOUR 44. FINPOUR; 45. H := H ∪ NouvellesClasses FIN PROCÉDURE ChercherEnfantsPotentiels(PCS,Pm) DÉBUT POUR chaque enfant Pc de Pm SI Pc ∈ ClassesModifiées ALORS ChercherEnfantsPotentiels(PCS,Pc) SINON Ajouter Pc à PCS FINSI FINPOUR FIN

Afin de comparer les deux algorithmes, nous les avons implémentés dans un environnement commun: ObjectWorks/Smalltalk. Des expériences ont été effectuées sur diverses librairies de classes sur une plate-forme PC muni d’un processeur Pentium 120. La Figure 3.2 montre le temps cumulatif pour construire incrémentalement la sous-hiérarchie de Galois pour un ensemble de 64 classes de la soushiérarchie des Collections de ObjectWorks/Smalltalk. Chacune des classes est décrite par son protocole, i.e. l’ensemble des sélecteurs de message auxquels la classe répond sans retourner une erreur. Le protocole a été extrait par une analyse automatique tel que décrit dans (Arfi, Godin, Mili, Mineau & Missaoui, 1995). La Figure montre que le temps de traitement pour AISGOOD est inférieur à ARES lorsque le nombre de classe dépasse la vingtaine et que la différence va en grandissant avec le nombre de classes traitées. La Figure inclut aussi une analyse de régression polynomiale d’ordre 2 par rapport au nombre de classes traitées. La variable x de l’équation de régression représente le nombre de classes de bases qui ont été ajoutées à la hiérarchie (et non pas le nombre de classes de la hiérarchie). Quoiqu’assez faible, la composante quadratique pour ARES est plus importante que pour AISGOOD, d’où l’accroissement de la différence. On peut observer que malgré cette différence, le temps de traitement pour les deux algorithmes est très raisonnable. Le temps nécessaire pour ajouter une nouvelle classe est inférieur à une seconde par classe en moyenne malgré le fait que le nombre moyen de propriétés soit assez grand dans cette librairie, soit de plus d’une centaine par classe en moyenne. Dans le cas de AISGOOD, au delà de la trentaine de classes, le temps de traitement pour ajouter une nouvelle classe est presque constant. On obtient donc un accroissement presque linéaire du temps cumulatif de traitement. D’autres expériences portant sur d’autres librairies ont donné des résultats semblables. Ces résultats sont cohérent avec l’analyse de complexité précédente qui indique une composante quadratique plus importante pour ARES à cause de la nécessité de visiter toutes les classes de la hiérarchie alors que AISGOOD ne visite qu’un ensemble limité de classes borné par k qui ne dépend par de n le nombre de classes de base traitées. La Figure 3.3 montre le résultat d’une expérience similaire sur un autre jeu d’essai d’un domaine différent. Les objets correspondent à des éléments de données d’un dictionnaire de données pour une application bancaire et les attributs à des mot-clés descriptifs. Le nombre d’objets est beaucoup plus grand mais le nombre d’attributs plus petit que pour l’expérience précédente. On peut observer un comportement relatif semblable.

11

Comparaison d’algorithmes de construction de hiérarchies de classes #1

({A,D ,LL,B,S}, {isEmpty,size,includes} ) #8

#9

({A,D,LL}, {at})

({D,LL,B,S}, {add})

#10

#11

#2

({A,LL}, {at, first,last})

({A,D}, {atput})

#4

#12

({Array}, {atput, atAllPut})

#5

({Dictionary}, {keys,values})

({S,D}, {minus})

#3

({LL,B,S}, {add, remove})

#6

({LinkedList}, {addFirst, addLast})

#7

({Bag}, ({Set}, {minus}) {addWithOccurrences})

Figure 3.1. Modification incrémentale de la sous-hiérarchie de Galois. 50

y = 0,0068x2 + 0,2523x + 0,2416 R 2 = 0,9993

40

30

20

y = 0,003x2 + 0,2829x + 0,8321 R 2 = 0,9975

10

0 1

11

21

31

41

51

61

Nombre de classes ARES

AISGOOD

Polynomial (AISGOOD)

Polynomial (ARES)

Figure 3.2. Modification incrémentale de la sous-hiérarchie de Galois pour les classes Collections.

12

Comparaison d’algorithmes de construction de hiérarchies de classes 350 y = 0,0003x2 + 0,1807x + 4,3628 R 2 = 0,9999 300

250

200

150

y = 5E-05x2 + 0,1964x - 0,0935 R2 = 0,9999

100

793

769

745

721

697

673

649

625

601

577

553

529

505

481

457

433

409

385

361

337

313

289

265

241

217

193

169

145

97

73

49

1

25

0

121

50

Nombre de classes

ARES

AISGOOD

Polynomial (AISGOOD)

Polynomial (ARES)

Figure 3.3. Modification incrémentale de la sous-hiérarchie de Galois pour l’application des éléments de données.

4.

CONCLUSION

Nous avons comparé les algorithmes ARES (Dicky et al., 1994) et AISGOOD (Godin et al., 1995a) de construction de hiérarchies de classes basées sur la notion de sous-hiérarchie de Galois. Ces algorithmes peuvent incorporer de façon incrémentale des nouvelles classes à une hiérarchie existante. Le résultat est une hiérarchie qui garantie la factorisation maximale des propriétés et la conformité avec la relation de spécialisation. Dans les expériences effectuées, le temps de traitement pour AISGOOD est inférieur à ARES lorsque le nombre de classes dépasse un certain seuil et la différence va en grandissant avec le nombre de classes traitées. La différence est explicable par une composante quadratique plus grande pour ARES par rapport au nombre de classes traitées. Ces résultats sont cohérent avec l’analyse de complexité qui indique que la composante quadratique plus importante pour ARES vient principalement de la nécessité de visiter toutes les classes de la hiérarchie existante alors que AISGOOD ne visite qu’un ensemble limité de classes. Les expériences démontrent que les deux algorithmes peuvent produire les hiérarchies en un temps de traitement fort raisonnable inférieur à une seconde par classe en moyenne dans les essais effectués. La meilleure performance de AISGOOD est due principalement au fait que seules les classes qui ont quelque chose en commun avec la nouvelle classe à insérer ne sont visitées. Ceci est possible grâce à l’utilisation d’un index qui donne pour chaque propriété la classe où celle-ci est déclarée. Une avenue intéressante à explorer serait de combiner cette approche avec ARES en s’assurant toutefois de traiter les classes dans un ordre respectant l’extension linéaire de la relation d’ordre de la hiérarchie.

Comparaison d’algorithmes de construction de hiérarchies de classes

5.

13

RÉFÉRENCES

Arfi, A., Godin, R., Mili, H., Mineau, G. W. & Missaoui, R. (1995). Generating the Interface Hierarchy of a Class Library. In V. S. Alagar & R. Missaoui (Eds.), Technology of Object-Oriented Databases and Software Systems, (pp. 42-57). Singapore, New Jersey: World Scientific. Barbut, M. & Monjardet, B. (1970). Ordre et Classification. Algèbre et Combinatoire, Tome II. Hachette. Booch, G. (1994). Object-Oriented Analysis and Design (2nd ed.). Reading, MA: Benjamin Cummings. Carpineto, C. & Romano, G. (1996). A Lattice Conceptual Clustering System and Its Application to Browsing Retrieval. Machine Learning, 24, 95-122. Casais, E. (1991). Managing Evolution in Object Oriented Environments: An Algorithmic Approach. Thèse de doctorat Thesis, Geneva. Cook, W. R. (1992). Interfaces and Specifications for the Smalltalk-80 Collection Classes. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, A. Paepcke (Ed.), Vancouver, B.C., Canada: ACM Press, pp. 1-15. Davey, B. A. & Priestley, H. A. (1992). Introduction to Lattices and Order. Cambridge: Cambridge University Press. Dicky, H., Dony, C., Huchard, M. & Libourel, T. (1994). Un algorithme d'insertion avec restructuration dans les hiérarchies de classes. In Proceedings of the Langages et Modèles à Objets, Grenoble: Dicky, H., Dony, C., Huchard, M. & Libourel, T. (1996). On Automatic Class Insertion with Overloading. In Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'96), CA, USA: ACM SIGPLAN Notices, pp. 251-267. Dvorak, J. (1994). Conceptual Entropy and Its Effect on Class Hierarchies. IEEE Computer, 27(6), 5963. Fisher, D. H. & Pazzani, M. J. (1991). Computational Models of Concept Learning. In D. H. Fisher,M. J. Pazzani, & P. Langley (Eds.), Concept Formation: Knowledge and Experience in Unsupervised Learning, (pp. 3-44). San Mateo, CA: Morgan Kaufmann. Gennari, J. H., Langley, P. & Fisher, D. (1990). Models of Incremental Concept Formation. In J. Carbonell (Eds.), Machine Learning: Paradigms and Methods, (pp. 11-62). Amsterdam, The Netherlands: MIT Press. Godin, R. & Mili, H. (1993). Building and Maintaining Analysis-Level Class Hierarchies Using Galois Lattices. In Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'93), A. Paepcke (Ed.), Washington, DC: ACM Press, pp. 394-410. Godin, R., Mineau, G. W. & Missaoui, R. (1995a). Incremental structuring of knowledge bases. In Proceedings of the International Knowledge Retrieval, Use, and Storage for Efficiency Symposium (KRUSE'95), Santa Cruz: Springer-Verlag's Lecture Notes in Artificial Intelligence, pp. 179-198. Godin, R., Mineau, G. W., Missaoui, R. & Mili, H. (1995b). Méthodes de Classification Conceptuelle Basées sur les Treillis de Galois et Applications. Revue d'Intelligence Artificielle, 9(2), 105-137. Godin, R., Missaoui, R. & Alaoui, H. (1995c). Incremental Concept Formation Algorithms Based on Galois (Concept) Lattices. Computational Intelligence, 11(2), 246-267.

Comparaison d’algorithmes de construction de hiérarchies de classes

14

Godin, R., Missaoui, R. & April, A. (1993). Experimental Comparison of Navigation in a Galois Lattice with Conventional Information Retrieval Methods. International Journal of Man-Machine Studies, 38, 747-767. Godin, R., Saunders, E. & Gecsei, J. (1986). Lattice Model of Browsable Data Spaces. Information Sciences, 40, 89-116. Johnson, R. & Foote, B. (1988). Designing Reusable Classes. Journal of Object-Oriented Programming, June/July, 22-35. Lalonde, W. R. (1989). Designing Families of Data Types Using Exemplars. ACM Trans. on Prog. Languages and Systems, 11(2), 212-248. Lieberherr, K. J., Bergstein, P. & Silva-Lepe, I. (1991). From Objects to Classes: Algorithms for Optimal Object-Oriented Design. Journal of Software Engineering, 6(4), 205-228. Liskov, B. (1988). Data abstraction and hierarchy. ACM SIGPLAN Notices, 23(5), 17-34. Moore, I. (1996). Automatic Inheritance Hierarchy Restructuring and Method Refactoring. In Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'96), CA, USA: ACM SIGPLAN Notices, pp. 235-250. Wille, R. (1992). Concept Lattices and Conceptual Knowledge Systems. Computers & Mathematics with. Applications, 23(6-9), 493-515.