Variations sur … Treillis de Galois pour la classification de connaissances et la modélisation par objets Marianne Huchard, LIRMM, CNRS et Université.

Présentation au sujet: "Variations sur … Treillis de Galois pour la classification de connaissances et la modélisation par objets Marianne Huchard, LIRMM, CNRS et Université."— Transcription de la présentation:

1 Variations sur … Treillis de Galois pour la classification de connaissances et la modélisation par objets Marianne Huchard, LIRMM, CNRS et Université Montpellier 2 Florence Le Ber CEVH (ENGEES - ULP) et Orpailleur (LORIA Nancy) Cette présentation se propose de mettre en lumière deux utilisations des treillis de Galois dans les approches à objets. Plus précisément : En représentation des connaissances, une étude de la représentation de structures spatiales, pour le raisonnement sur des images satellitaires En génie logiciel, une méthode d’aide à la construction de modèles conceptuels par découverte d’abstractions. Pour cette dernière application, une extension de la théorie classique des treillis de Galois sera introduite.

2 Plan Introduction Treillis de Galois (notions de base)
Analyse relationnelle de concepts Application à l’ingénierie des modèles Généralisation de relations spatiales Application aux SIG Conclusion et perspectives Le plan de la présentation est le suivant. Après une introduction, nous rappelons brièvement les principes généraux de la construction de treillis de Galois. Puis une extension, « l’analyse relationnelle de concepts » est exposée, qui trouve son application dans l’ingénierie des modèles pour la construction de modèles conceptuels. Ensuite nous montrons comment les treillis de Galois peuvent être utilisés pour la classification et le raisonnement de relations et de structures spatiales. Nous concluons enfin par les perspectives générales de ces travaux. RIA's & 21 mars 2006

3 Introduction (du besoin de classer dans les AOO)
Représentation de connaissances Classification courante une façon naturelle d'organiser les connaissances des mécanismes bien établis dans les systèmes de représentation (RCO et LD) Problématiques manipuler les propriétés des objets / concepts pour le raisonnement et la résolution de problème relier le domaine terminologique et le domaine concret (concepts/données) analyser les données à partir du modèle du domaine construire des modèles d'un domaine à partir de données RIA's & 21 mars 2006

4 Introduction (du besoin de classer dans les AOO)
Génie Logiciel Classifications courantes Frameworks, Packages Relation de spécialisation/généralisation Problématiques Regroupement d’entités Calcul de vues abstraites sur le logiciel Calcul de nouvelles généralisations Un modèle théorique utile FCA/treillis de Galois La notion de classification est centrale aux approches du génie logiciel à objets. Pour une bonne part cela provient : de l’hypothèse sur laquelle se sont construites ces approches et qui considère que les représentations informatiques doivent refléter dans une certaine mesure les entités du domaine modélisé ou du problème étudié de la nécessité de comprendre les systèmes qui deviennent de plus en plus importants en taille et en complexité. Les classifications sont ainsi au cœur des modèles et des programmes par exemple sous forme de: Frameworks qui sont des abstractions d’applications réutilisables Paquetages qui regroupent des entités par thématique Hiérarchies de types, de classes, d’interfaces, qui sont organisés par spécialisation ou sous-typage Les problématiques abordées sont principalement les suivantes. On cherche à regrouper des entités pour produire des modules, des paquetages plus faciles d’accès et mieux réutilisables On calcule des vues abstraites sur le logiciel pour : connaître les dépendances implicites entre composants (G. Arevalo et al.) Détecter et contrôler des styles de programmation en examinant les schémas d’appel récurrents (G. Arevalo et al.) On calcule de nouvelles abstractions pour améliorer, simplifier les modèles, avoir des composants plus réutilisables. Les treillis de Galois sont de plus en plus utilisés dans ces approches pour leurs qualités : Aspect systématique de la généralisation Robustesse à l’ordre d’examen des entités Capacité à mettre en évidence des motifs récurrents non connus à l’avance. RIA's & 21 mars 2006

5 Treillis de Galois/treillis de concepts Barbut/Monjardet 1970
Extraction d’abstractions à partir d’un ensemble d’entités décrites par des caractéristiques Concept f1 f2 f3 f4 f5 C1 x C2 C3 C4 ({C3,C4},{f1,f3}) Spécialisation Rappelons brièvement les principes de cette méthode. Il s’agit de construire un ensemble d’abstractions à partir d’un ensemble d’entités décrites par des caractéristiques. La description prend la forme d’une relation ou contexte binaire. Un « concept » est un couple de deux ensembles : l’extension représente l’ensemble des objets couverts par le concept (ex. C3 et C4) L’intension représente l’ensemble des caractéristiques communes à des concepts (ex. f1, f3) Les concepts sont naturellement organisés entre eux par un ordre partiel basé sur l’inclusion des extensions dans un sens ou inversement l’inclusion des intensions. Ex. le concept d’extension C3,C4 spécialise le concept d’extension C2,C3,C4 sur la base de l’inclusion de ces deux ensembles. ({C2,C3,C4},{f3}) Contexte binaire ({C3,C4},{f1,f3}) RIA's & 21 mars 2006

6 Treillis de Galois/treillis de concepts (notions de base)
({C1,C2,C3,C4},{}) ({C1,C3,C4},{f1}) ({C2,C3,C4},{f3}) ({C3,C4},{f1,f3}) ({C2},{f2,f3}) Nous voyons sur ce schéma le treillis complet dont il ne faut pas se cacher la complexité structurelle. Le nombre de concepts est en effet exponentiel (borné par la taille du treillis des parties du plus petit des deux ensembles). Cette théorie a servi et sert encore dans de nombreux problèmes de classification en génie logiciel avec un bon succès. Cependant elle présente des limites. ({C4},{f1,f3,f5}) f1 f2 f3 f4 f5 C1 x C2 C3 C4 ({C3},{f1,f3,f4}) ({},{f1,f2,f3,f4,f5}) Treillis associé au contexte RIA's & 21 mars 2006

7 Analyse relationnelle de concepts (RCA)
Extension de FCA pour prendre en compte des entités décrites par des relations avec d’autres entités Collaboration avec France Télécom R&D : M. Dao UDM : P. Valtchev, M. Rouane Hacène LIRMM/UDM : C. Roume LIRMM : C. Nebut, J.R. Fallery En particulier, prise telle quelle, elle est incapable de prendre en compte des entités décrites par leurs relations avec d’autres entités. C’est un problème qui nous est arrivé par la pratique, en cherchant à abstraire des diagrammes de classes en UML, mais qui est bien entendu un problème général d’abstraction. Nous allons examiner plus en détails cette question qui est étudiée en collaboration avec M. Dao (FT) P. Valtchev et M Rouane Hacène C. Roume Pour les débuts de la technique. Et à présent de nouveaux travaux s’ouvrent avec C. Nebut et J.R. Fallery dans le cadre de l’ingénierie des modèles. RIA's & 21 mars 2006

8 Analyse relationnelle de concepts Un contexte d’application : modèles conceptuels (UML)
Classes UML Modélisation naïve en FCA name owned Attribute type BasicAccount (BA) ‘BasicAccount’ {bba,o} TeenagerAccount (TA) ‘Teenager Account’ {bta,mw} BasicAccountHolder (BAH) ‘BasicAccountHolder’ {bal} TeenagerClient (TC) Client’ {tal} balance from BA (bba) ‘balance’ balance from TA (bta) overdraft (o) ‘overdraft’ maxWithdrawal (mw) ‘max Withdrawal’ bAccountList (bal) ‘bAccountList’ {BA} tAccountList (tal) ‘tAccountList’ {TA} BasicAccount balance overdraft TeenagerAccount balance maxWithdrawal BasicAccountHolder bAccountList : BasicAccount[1.*] Le problème sera présenté dans le contexte où il est apparu et qui reste encore son principal cadre d’application. En modélisation par objets, on cherche à produire un modèle du domaine et du problème à l’aide de classes, d’attributs, d’opérations et d’associations. Ici nous ne décrivons que se qui se passe avec les attributs, étant entendu que l’approche se généralise aux autres éléments de modélisation. Nous avons ici 4 classes décrites par un ou deux attributs. L’une des difficultés lorsque les modèles deviennent complexes est d’y repérer des abstractions qui vont permettre de simplifier le modèle, d’éviter la redondance des informations de produire des éléments mieux réutilisables parce que plus généraux. Une modélisation « naïve » de ce diagramme est présentée à droite. Les entités sont les classes et attributs du modèle tandis que les caractéristiques sont les noms des entitiés, ou leurs relations avec d’autres entités. Ainsi l’attribut bAccountList a pour type la classe BA Ou encore la classe TC possède l’attribut tAccountList. TeenagerClient tAccountList : TeenagerAccount[1.*] 7

9 Analyse relationnelle de concepts (scaling contexte binaire un seul concept)
name ‘Basic Account’ . ‘balance’ ‘tAccount List’ owned Attribute (oa) bba oa bta o mw bal tal type BA TA X BAH TC La précédente table se décrit par le contexte binaire que nous voyons ici. Les colonnes correspondent à des couples (caractéristique, valeur) Ex. (name, ‘Basic Account’) ou (ownedAttribute(oa), overdraft) Dans ce contexte binaire, un seul concept…. 8

10 Analyse relationnelle de concepts (Basic FCA : maigre moisson d’abstractions)
Une abstraction d’attribut … balance specializes BasicAccount balance overdraft BasicAccountHolder bAccountList : BasicAccount[1.*] … Qui est l’abstraction « attribut s’appelant balance » et que nous retrouvons sur ce schéma comme une généralisation des deux attributs portant ce nom. On peut considérer que le travail d’abstraction mené n’est pas très approfondi. TeenagerAccount balance maxWithdrawal TeenagerClient tAccountList : TeenagerAccount[1.*] 9

11 accountList:BankAccount
Analyse relationnelle de concepts (RCA : recueil de meilleures abstractions) BankAccount balance BankClient accountList:BankAccount BasicAccount overdraft Surtout q’un examen attentif montre qu’il serait intéressant de : Créer une classe BankAccount pour accueillir cet attribut et généraliser les deux classes BA et TA Généraliser les deux attributs bal et tal dont les types sont généralisés par BankAccount Enfin créer une classe BankClient pour recevoir cette généralisation accountList. C’est ce que va nous permettre de faire l’extension de la théorie de base qui est présentée à présent. BasicAccountHolder bAccountList : BasicAccount[1.*] TeenagerAccount maxWithdrawal TeenagerClient tAccountList : TeenagerAccount[1.*] 10

12 Analyse relationnelle de concepts (Formalisation)
Kclass name ‘Basic Account’ ‘Teenager ‘BasicAccount Holder’ Client’ BA X TA BAH TC Owned Attribute bba bta o mw bal tal BA X TA BAH TC Relational Context Family (RCF) (K,R) K ensemble de contextes K = {Kclass,Kproperty} R ensemble de relations entre entités des contextes R = {type,ownedAttribute} KProperty name ‘balance’ … ‘tAccount List’ bba X bta o .. mw bal tal type BA TA bba bta o mw bal X tal Tout d’abord, le grand contexte binaire est éclaté en petite relations. Des catégories d’entités sont créées (tables oranges). Classes et Properties sont séparées. Ce n’est pas obligatoire mais évite des généralisations inter-catégories. Dans ces tables on ne trouve plus de description relationnelle. Les relations sont identifiées et séparées (tables roses) Cela donne ce que nous appelons une famille de contextes relationnels qui se compose formellement d’un ensemble de contextes (oranges) et d’un ensemble de relations entre entités de ces contextes (rose). 11

13 Analyse relationnelle de concepts (Construction itérative de treillis)
Treillis des classes Kclass name ‘Basic Account’ ‘Teenager ‘BasicAccount Holder’ Client’ BA X TA BAH TC Owned Attribute Ca Cb Cc Cd Ce Cf BA X TA BAH TC KProperty name ‘balance’ … ‘tAccount List’ bba X bta o .. mw bal tal Au lieu de construire un seul treillis, nous construisons à présent autant de treillis que de contextes. De plus nous ajoutons une composante itérative à la construction. Après la première construction des treillis, nous injectons dans les tables roses (les relations) les concepts des treillis qui viennent remplacer les valeurs initiales. La méthode consiste donc à itérer Construction de treillis Ré-injection des concepts construits dans les relations Jusqu’à stabilisation (plus aucune nouvelle abstraction-concept n’apparaît). type C1 C2 bba bta o mw bal X tal Treillis des propriétés 12

14 Analyse relationnelle de concepts
KProperty name ‘balance’ … ‘tAccount List’ bba X bta o .. mw bal tal type BA TA bba bta o mw bal X tal bba,bta,o,mw,bal,tal Extent Intent Voyons en détails le processus sur l’exemple. Dans la table décrivant les attributs nous remarquons le partage de la caractéristique « être nommé balance ». Ce partage se traduit par un concept dans le treillis que nous construisons à partir de la table orange étendue par la table rose (il pourrait y avoir plusieurs tables roses). Apparaît donc le concept C_bbabta (en vert). Cbbabta Co Cbal Ctal Cmw bba,bta name=‘balance’ o name=‘overdraft’ mw name=‘maxWithdrawal’ bal name=‘bAccountList’ type=BA tal name=‘tAccountList’ type=TA name=…., type=… 13

15 Analyse relationnelle de concepts
bba,bta,o,mw,bal,tal Scaling « relationnel » (BA,bba) OwnedAttribute1 et bba  Extent(Cbbabta) (BA,Cbbabta) OwnedAttribute2 Extent Intent Cbbabta Co Cbal Ctal Cmw bba,bta name=‘balance’ o name=‘overdraft’ mw name=‘maxWithdrawal’ bal name=‘bAccountList’ type=BA tal name=‘tAccountList’ type=TA name=…., type=… Kclass name ‘Basic Account’ ‘Teenager ‘BasicAccount Holder’ Client’ BA X TA BAH TC L’astuce qui va nous permettre de progresser dans les généralisations porte le nom de « scaling relationnel ». Comme dit précédemment, les caractéristiques de la table ownedAttribute, étant précédemment des attributs (ou properties), vont être remplacées par les concepts du treillis des propriétés construit juste avant. Le principe est le suivant. Comme BA a pour attribut bba Et que bba se généralise par C_bbabta Alors dans les nouvelle table, BA a pour attribut C_bbabta. Owned Attribute Cbbabta Co Cmw Cbal Ctal BA X TA BAH TC 14

16 ownedAttribute=Cbbabta
Kclass name ‘Basic Account’ ‘Teenager ‘BasicAccount Holder’ Client’ BA X TA BAH TC Owned Attribute Cbbabta Co Cmw Cbal Ctal BA X TA BAH TC BA,TA,BAH,TC Extent Intent CBATA BA,TA ownedAttribute=Cbbabta A présent, construction du treillis des classes avec la table orange étendue par la table rose. Un concept apparaît qui correspond à une généralisation des classes BA et TA et possède l’attribut C_bbabta. CBA CBAH CTC CTA BA name=‘BasicAccount’ ownedAttribute=Cbbabta,Co TA name=‘TeenagerAccount’ ownedAttribute=Cbbabta,Cmw BAH name=‘BasicAcHolder’ ownedAttribute=Cbal TC name=‘TeenAccount’ ownedAttribute=Ctal name=…., ownedAttribute=… 15

17 name=…., ownedAttribute=… KProperty CBA CTA CBATA
BA,TA,BAH,TC Extent Intent CBATA BA,TA ownedAttribute=Cbbabta CBA CTA CBAH CTC BA name=‘BasicAccount’ ownedAttribute=Cbbabta,Co TA name=‘TeenagerAccount’ ownedAttribute=Cbbabta,Cmw BAH name=‘BasicAcHolder’ ownedAttribute=Cbal TC name=‘TeenAccount’ ownedAttribute=Ctal name=…., ownedAttribute=… KProperty name ‘balance’ … ‘tAccount List’ bba X bta o .. mw bal tal De manière duale à ce que nous avons fait pour les property, les concepts du treillis des classes sont injectés comme caractéristiques dans la table rose décrivant les types des attributs. Ainsi bal qui avait comme type BA, a à présent comme types C_BA et C_BATA, concepts dont l’extension contient bal et donc dont la raison d’être est de généraliser bla. type CBA CTA CBATA bba bta o mw bal X tal 16

18 KProperty CBA CTA CBATA bba,bta,o,mw,bal,tal Extent Intent Cbaltal
name ‘balance’ … ‘tAccount List’ bba X bta o .. mw bal tal type CBA CTA CBATA bba bta o mw bal X tal bba,bta,o,mw,bal,tal Extent Intent Cbaltal Retour vers la description des property avec création d’un nouveau concept généralisant bal et tal qui ont un de leurs types en commun. bal,tal type= CBATA Cbbabta Co Cbal Ctal Cmw bba,bta name=‘balance’ o name=‘overdraft’ mw name=‘maxWithdrawal’ bal name=‘bAccountList’ type=CBA,CBATA tal name=‘tAccountList’ type=CBA,CBATA name=…., type=… 17

19 bba,bta,o,mw,bal,tal Extent Intent Cbaltal bal,tal Cbbabta Co Cbal
type=CBATA Cbbabta Co Cbal Ctal Cmw bba,bta name=‘balance’ o name=‘overdraft’ mw name=‘maxWithdrawal’ bal name=‘bAccountList’ type=CBA,CBATA tal name=‘tAccountList’ type=CBA,CBATA name=…., type=… Kclass name ‘Basic Account’ ‘Teenager ‘BasicAccount Holder’ Client’ BA X TA BAH TC Ces nouveaux concepts de property sont injectés à nouveau dans la description des classes. Owned Attribute Cbbabta Co Cmw Cbal Ctal Cbaltal BA X TA BAH TC 18

20 name=…., ownedAttribute=… 19
Kclass name ‘Basic Account’ ‘Teenager ‘BasicAccount Holder’ Client’ BA X TA BAH TC Owned Attribute Cbbabta Co Cmw Cbal Ctal Cbaltal BA X TA BAH TC BA,TA,BAH,TC Extent Intent CBATA CBAHTC BA,TA ownedAttribute=Cbbabta BAH,TC ownedAttribute=Cbaltal Et une nouvelle construction du treillis des classes Nous fait retrouver un concept généralisant C_BATA Nous fait découvrir un nouveau concept généralisant BAH et TC, le concept C_BAHTC Il y a stabilisation à cette étape, si on continuait le calcul on ne découvrirait plus aucune nouvelle généralisation pour cet exemple, Ni dans les classes Ni dans les property. CBA CTA CBAH BA name=‘BasicAccount’ ownedAttribute=Cbbabta,Co TA name=‘TeenagerAccount’ ownedAttribute=Cbbabta,Cmw BAH name=‘BasicAcHolder’ ownedAttribute=Cbal, Cbaltal CTC TC name=‘TeenAccount’ ownedAttribute=Ctal, Cbaltal name=…., ownedAttribute=… 19

21 accountList:BankAccount
BA,TA,BAH,TC Extent Intent CBATA CBAHTC BA,TA ownedAttribute=Cbbabta BAH,TC ownedAttribute=Cbaltal CBA CTA CBAH BA name=‘BasicAccount’ ownedAttribute=Cbbabta,Co TA name=‘TeenagerAccount’ ownedAttribute=Cbbabta,Cmw BAH name=‘BasicAcHolder’ ownedAttribute=Cbal, Cbaltal CTC TC name=‘TeenAccount’ ownedAttribute=Ctal, Cbaltal BankAccount balance BankClient accountList:BankAccount L’exploitation des deux treillis va permettre de revenir vers la modélisation UML. Tout d’abord chaque concept du treillis des classes (sauf souvent le top et le bottom qui ne sont pas intéressants en général) donne lieu à une classe. C_BATA donne une classe qu’un concepteur désignera par exemple comme BankAccount. La spécialisation entre classes est tirée de l’ordre dans le treillis. BasicAccount overdraft BasicAccountHolder bAccountList : BasicAccount[1.*] TeenagerAccount maxWithdrawal TeenagerClient tAccountList : TeenagerAccount[1.*]

22 accountList:BankAccount
bba,bta,o,mw,bal,tal Extent Intent Cbaltal bal,tal type=CBATA Cbbabta Co Cbal Ctal Cmw bba,bta name=‘balance’ o name=‘overdraft’ mw name=‘maxWithdrawal’ bal name=‘bAccountList’ type=CBA,CBATA tal name=‘tAccountList’ type=CBA,CBATA BankAccount balance BankClient accountList:BankAccount Chaque concept du treillis des property donne lieu à un attribut en UML. L’information ownedAttribute du treillis des classes permet de savoir à quelle classe rattacher l’attribut. Exemple l’attribut nommé balance sera rattaché à BankAccount car correspond au concept le plus haut possédant ownedAttribute=C_bbabta BasicAccount overdraft BasicAccountHolder bAccountList : BasicAccount[1.*] TeenagerAccount maxWithdrawal TeenagerClient tAccountList : TeenagerAccount[1.*]

23 Analyse relationnelle de concepts
Méthode générique dans la plateforme Galicia Implémentation dans l’atelier Objecteering (pour UML) Se généralise à toutes les entités UML (associations, opérations, etc.) Cette méthode a bénéficié de plusieurs implémentations. Dans la plate-forme Galicia (également accessible sur sourceforge) une implémentation indépendante d’UML, considérant des entités quelconques reliées par des relations quelconques. Dans l’atelier Objecteering (avec appel d’algorithmes implémentés dans Galicia) sous sa forme générale pour UML, c’est-à-dire prenant en compte les opérations et les associations RIA's & 21 mars 2006

24 Analyse relationnelle de concepts
Une expérience de généralisation sur des modèles France Télécom R&D Projet RNTL MACAO 3 modèles ~ 40 à 60 classes ~ millier d’éléments Obtention d’une forme « normale » Génération ~ un peu plus d’un millier d’éléments UML Analyse « artisanale » avec les concepteurs des modèles d’origine Simplification des modèles Découvertes d’incohérences Une expérience a porté sur des modèles d’analyse et de conception chez France Télécom dans le cadre d’un projet RNTL. Les modèles n’étaient pas très grands (entre 40 et 60 classes). Nous n’avons pas rencontré de difficultés en temps de calcul ou en espace mémoire. L’interprétation s’est faite de manière « artisanale » avec retour vers les concepteurs des modèles d’origine et analyse qualitative. Une partie non négligeable des abstractions construites a été jugée intéressante. Le résultat a également révélé des incohérences dans les modèles. Et globalement les modèles ont pu être améliorés. Pour obtenir une méthode plus effective, il reste cependant des verrous à lever que cette expérience a mis en lumière. RIA's & 21 mars 2006

25 Analyse relationnelle de concepts
Perspectives théoriques définition analytique, efficacité, nombre d’itérations Perspectives applicatives paramétrage, traçabilité, visualisation et manipulation des résultats logique de description, autres langages de représentation … D’un point de vue théorique, la méthode est difficile d’accès pour un concepteur car sa description algorithmique et itérative ne facilite pas l’anticipation du résultat. En termes d’efficacité, les algorithmes utilisés font évoluer incrémentalement les treillis et nous pouvons réfléchir à des algorithmes encore plus efficaces. Pour la mise à disposition dans un atelier de génie logiciel, encore de nombreuses questions à résoudre. Actuellement les implémentations se présentent comme des « boîtes noire » peu paramétrables. Difficile également de tracer le devenir des éléments pendant le processus de généralisation et pourtant de cette traçabilité dépend beaucoup le résultat final ! Enfin il faut spécifier des outils de visualisation et de navigation, voire de manipulation des résultats. Pour conclure la méthode devrait être étudiée pour d’autres langages de représentation disposant de concepts et de relations. L’équipe de l’UDM travaille notamment sur l’application aux logiques de description. RIA's & 21 mars 2006