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

Thing \. (Physical_thing \. (Animal \. (Dog instance: Diesel_the_dog The_most_famous_dog_named_Togo) (Human_being exclusion: Dog, \. (Man instance: Sean_Connery Brent_Spinner) //+ James_Bond ? (Woman exclusion: Man) (Human_person \. Natural|Physical_human-person_from_a_legal_aspect) ) ) ) (Person \. (Legal_person|entity exclusion: Natural|Physical_person_from_a_legal_aspect, instance: James_Bond __[author: pm] ) //pm: my choice; not Data_the_android when disconnected (Natural|Physical_person_from_a_legal_aspect \. Natural|Physical_human-person_from_a_legal_aspect ) (Human_person //+??? subtype: Human_cyborg Human_character Android_character, instance: James_Bond ) ) (Movie_character //exclusion: Physical_thing Person //not in the general case \. (Human_character instance: (James_Bond actor: Sean_Connery) ) (Android_character instance: (Data_the_android actor: Brent_Spinner) ) //+? exclusion: Human_character //e.g. a Human-cyborg_character ? (Dog_character instance: (The_character_of_the_most_famous_dog_named_Togo actor: Diesel_the_dog ) ) ).


Les RCs du 1er exemple ne sont donc pas correctes, et ne passent donc pas à l'échelle
→ elles ne sont donc pas à utiliser dans un(e) programme/BdD orienté(e)-objet,
→ simplement ajouter des types ou des instances ne corrigeraient pas le problème.

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

Voici une version FL de la modélisation demandée  (dans cette version là, les quantificateurs sont dans les nœuds relations) :

Company employee _[any->1..*]: Employee; ///exact translation but it would be more correct and // complete to use: Company employee _[any->1..*; 0..*<-any]: (Employee \. Person_employee); Person \. Man Woman Employee; //exact translation but it would be more precise to assert that: // Person \. excl{Man Woman} Person_employee; // since an Employee is not necessarily a Person. //Note: "any Person may be a Man (or something else)" // <=> (∀p,m Person(p) => Man(m) ∨ Person_that_is_not_a_man(m)) // <=> (∀p,m Man(m) => Person(p)) <=> [Person \. Man] // Idem for the representation of "may be a Woman". Employee id _[any->1..*]: ID, photo _[any->1..*]: Photo; //exact translation; more completely: // Employee id _[any->1..*; 0..*<-any]: ID, photo _[any->1..*; 0..*<-any]: Photo;


Concernant la modélisation contenant au moins 4 problèmes conceptuels (6 sont listés ci-dessous) :

  1. Ligne 1: un booléen est utilisé au lieu
    - d'une classe Gender_identity avec des sous-classes telles que Male_identity, Female_identity, ...     ou bien
    - de sous-classes telles que Man, Woman, ... Chaque programmeur réutilisant la classe Person peut ajouter des
      sous-classes si celles qui existent ne sont pas assez précises ou complètes.
      Il s'agit d'une application de la stratégie "retarder les choix" ["delay the choices"].
      Inversement, utiliser un booléen ici est de la "sur-représentation" par rapport au monde modélisé.
  2. Ligne 2 et 3 (problèmes de sous-typage d'un rôle par un type naturel ; cf. page précédente) :
    - une personne au sens légal n'est pas nécessairement un être humain ;
    - un employee n'est pas nécessairement un être humain (e.g., certains chiens ont le statut d'employé)
  3. Ligne 4 :
    • Problème 1 (l'absence d'une collection, e.g. d'un vecteur) :
      - avec "Employee employee;", 1 seul employé (par société) peut être stocké, pas plusieurs;
      - exemple de solution pas assez générique (ici en C++) : array<Employee> employees;
        ou, mieux, avec les préfixes recommendés pour les variables : array<Employee> a__oEmployee;
      - bonne solution (spécialisable et à spécialiser) : Collection<<Employee> employees;
        ou, mieux, avec les préfixes recommendés pour les variables : Collection<Employee> a__oEmployee;
    • Problème 2 (représentation d'un Employee comme une sous-partie d'une entreprise [Company]) :
      - solution partielle: utilisation d'une référence (pointeur ou identifiant) à un objet Employee plutôt que
      d'inclure l'objet entier avec un pointeur, en C++ :   class Company { Employee *poEmployee; }
    • Problème 3 (la relation "employee" entre un objet de type Company et un objet de type Employee est implicite) :
      - solution : rendre cette relation explicite en la rendant instance d'une classe Relation_employee et
      en remplaçant Employee oEmployee; par Relation_employee *rpRelation_employee;
      (notez au passage l'usage des prefixes "o" et "rp" pour les variables, comme conseillé par la section 2.1.1) ;
      cette solution est "lourde" avec tous les langages de programmation ; par contre, avec les langages de RCs,
      les relations sont forcément explicites, faciles à écrire et en plus leurs sources et destinations sont quantifiées
      (-> pour la destination, on parle de "multiplicités" ou de "cardinalités").