TP Sol. – Exemples d'organisation de types de concepts

Reliez par un maximum de relations les termes (de types de concepts) 'Knowledge_management', 'Knowledge_engineering', 'DBMS', 'KBMS' et 'Information' tels que définis en cours, mais en n'utilisant que des relations ayant des types parmi les suivants : 'subtype' (que vous pouvez abrévier par 's'), 'exclusion' (alias, 'disjointWith' ; vous pouvez abrévier par 'e'), 'tool' et 'input' (n'abréviez pas ces deux derniers noms). Utilisez la notation de votre choix et indiquez son nom.

FL:    Knowledge_management
         tool: 0..* DBMS,
         input: 0..* (Information exclusion: Knowledge_management),
         \. (Knowledge_engineering   tool: 0..* (KBMS exclusion: DBMS Knowledge_management) ).

Pour le "Circle-ellipse problem", les méthodes "possibles" listées par la page Wikipidia, soit ne reconnaissent pas le problème de leur modélisation (qui est fausse et donc ne passe pas à l'échelle), soit n'expliquent pas complètement quel est ce problème et comment le résoudre. Leur problème est

1. de penser que 2 classes sont suffisantes (Ellipse et Circle), avec Circle sous-type de Ellipse, alors que des méthodes différentes d'agrandissement ("stretch" ou, plus généralement, "display") de figure doivent aussi être représentées et que celle pour Circle n'est pas une spécialisation de celle pour Ellipse (ce qui n'est pas compatible avec la représentation de Circle comme sous-type de Ellipse), ou
2. de penser que leur modèle doit avoir seulement ces deux classes (alors que cela n'est en fait jamais précisé), puis d'essayer de faire avec, ce qui n'est pas possible.

Voici le modèle erroné qu'utilisent la plupart des approches (listées dans la page Wikipidia), avec des noms de classes qui mettent en évidence la contradiction de la modélisation en question :

Ellipse_with_distinct_StretchX_and_StretchY_methods_that_work_only_for_an_ellipse_that_is_not_a_circle
 \. Circle_with_StretchX_method_that_works_only_for_a_circle_not_an_ellipse.

//or, more generally:
Ellipse-that-is-not-a-circle_with_additional_methods_for_display
 \. Circle_with_additional_methods_for_display.

Voici, en partant de ces derniers noms plus généraux, un modèle correct (→ un modèle qui distingue et relie correctement les différentes notions impliquées), ici avec 5 classes, même si 3 peuvent suffire pour l'application décrite dans la page Wikipedia :

Mathematical_ellipse
 \. exclusion{ (Mathematical_circle  \. Circle_with_additional_methods_for_display) 
               (Mathematical_ellipse_that_is_not_a_circle   //2 distinct foci
                  \. Ellipse-that-is-not-a-circle_with_additional_methods_for_display) 
             }.

Ainsi, les approches citées qui gardent seulement deux classes (incorrectement nommées Ellipse et Circle alors qu'elles représentent plus que les notions mathématiques associées à ces noms) utilisent des modèles qui sont faux par "sur-représentation" (et sur-restriction, comme pour l'utilisation d'un booléen pour "Male, Female, ..." dans le TD 1).

Toutefois, les sections "Factor out common functionality into an abstract base class" (→ la 2.1.8 si les sections étaient numérotées), la "(2.3) Challenge the premise of the problem" et la "(1.3) Allow for a weaker contract on Ellipse"

1. reconnaissent (directement ou non) le problème ; ce problème est aussi indiqué dans le 1er paragraphe de l'article : c'est la violation du "Liskov substitution principle" ou, plus clairement et complètement, la violation de la définition d'une relation sous-classe, et
2. s'approchent de la solution ci-dessus, sans toutefois être aussi clair et complet.
   • La classe "EllipseOrCircle" du 2.1.8 est la classe "Mathematical_ellipse" ci-dessus.
   • Dans le 2.3, c'est plus compliqué : la classe "OneDiameterFigure" du 2.3 semble être la classe "Circle_with_a_display_method" ci-dessus, et la classe "TwoDiameterFigure" semble être la classe "Ellipse-that-is-not-a-circle_with_a_display_method" mais la conclusion du 2.3 en fait une sous-classe de "OneDiameterFigure", ce qui n'est sémantiquement pas possible si cette dernière est bien "Circle_with_a_display_method" (toute ellipse n'est pas aussi un cercle, même si cela arrange le programmeur).
   • La 1.3 pointe aussi, très rapidement, le problème, mais sa solution est très partielle : son titre est bon mais elle n'introduit pas de nouvelle classes (en plus de Ellipse et/ou Circle) pour contenir les méthodes de dessin/agrandissement spécifiques à, respectivement, un cercle et une ellipse qui n'est pas un cercle.

En conclusion, les "solutions possibles" recensées dans cette page Wikipedia (à part celles de la 2.1.8, mais sa description est incomplète) essaient de résoudre leur problème via des techniques de programmation (souvent compliquées) – ou en ignorant le cas général (comme dans la 1.3) – au lieu de simplement changer et compléter la modélisation des notions impliquées pour qu'elle soit correcte par rapport à la réalité (-> donc ici, correctement représenter par représenter la sémantique d'un cercle et d'une ellipse dans le cas général, puis représenter des sous-classes, et utiliser des relations de sous-classe correctes).

TP Sol. – Exemples d'organisation de types de concepts - Objet/symbole/phrase formel(le) ou non

• Dans la liste, seul ^"hat" est informel puisqu'un "mot" (contrairement à un identifiant unique) peut avoir plusieurs sens (et donc référer à plusieurs types).
• • Référent à au moins un type de concept :  ^"hat",  pm#person  et
    pm#type_de_relation_transitive (car c'est un type de concept du second ordre dont les instances sont les types de relations transitives)
  • Référent à un type de relation :  pm#relation  et  wn#part
  • Référent à un individu :  pm#Paris
•  

  en#"city"
    .>  (en#"Paris"  .> wn#Paris___the_French_capital)
        (wn#city
           > (wn#capital
                pm#instance:
                  (wn#Paris___the_French_capital 
                     =   pm#Paris_the_city_which_was_the_French_capital_in_2010,
                     .>  pm#Paris_in_1860  //the Paris of 1860
                  )));
  
  
  //if we assume that en#"Paris" refers to only 1 individual,
  //                              the current French capital,
  //then  en#"Paris" = wn#Paris___the_French_capital
  //  and the above representation can be precised as follows:
  en#"city"
    .>  (wn#city
           > (wn#capital
                pm#instance:
                  (wn#Paris___the_French_capital 
                     =   pm#Paris_the_city_which_was_the_French_capital_in_2010
                         en#"Paris",
                     .>  pm#Paris_in_1860
                  )));