TD – Exemples d'organisation de types de concepts

FL-DF (FL Display Form): FL (in its default Linear Form): Person_from_a_legal_aspect Person_from_a_legal_aspect Man^↙s £ ^s↘ Woman subtype: Woman ↓ⁱ ( Man instance: James_Bond, James_Bond exclusion: Woman ).

Legend. "-s→": subtype; "-i→": instance; "£": exclusion

La RC (en FL ou FL-DF) ci-dessus vous paraît-elle correcte ?
Est-elle toujours utilisable sans conséquence négative dans un programme/BdD orienté-objet ?
Pensez-vous que cette organisation passerait à l'échelle, i.e.,
pensez-vous que quelque soient les types ou instances que vous souhaitiez ajouter
vous n'ayez pas à corriger certaines relations ?
Si non, quelles relations sont à corriger ?

QW (Question via Wooclap) "La RC de la page 1 du TD 1 ...".

TD – Exemples d'organisation de types de concepts

Pour répondre aux questions précédentes (et donc pour décider d'une hiérarchie dans un(e) programme/BdD orienté(e)-objet), il faut généraliser. Pour cela, faites l'exercice suivant.

En supposant que les termes suivants de la liste ci-dessous soient des termes formels qui réfèrent au sens le plus commun que ces mots ont en anglais, veuillez les organiser – en FL (dans un graphe unique/connecté, pas via des parties séparées ; faites bien attention à la syntaxe et à l'indentation ; n'utilisez pas FL-DF, c'est compliqué quand il y a beaucoup de termes) – via toutes les relations possibles des types suivants : subtype/supertype, type/instance, exclusion, ainsi que actor (dans le sens de "a pour acteur" : celui/celle qui "joue ce rôle").
Voici la liste (déjà organisée par blocs de termes ayant certains points communs, pour vous faciliter la tâche; placez les termes un par un dans la hiérarchie de sous-types, en commençant par le début; ensuite, occupez-vous des autres relations) :

Thing ("Chose"), Physical_thing (chose ayant une masse), Animal, Dog, Human_being (un animal bipède actuellement très répandu), Man, Woman
Person (au sens légal|juridique ou au sens commun, ce dernier sens référant à un être social doué d'une raison et d'une conscience), Legal_person|entity, Natural|Physical_person_from_a_legal_aspect, Natural|Physical_human-person (attention, c'est encore une notion juridique), Human_person (un être humain qui est aussi une personne),
Movie_character (i.e. "personnage de film"), Android_character (i.e. personnage d'androïde|robot), Human_character, Dog_character,
James_Bond, Sean_Connery (un des acteurs ayant joué James_Bond),
Data_the_android, Brent_Spinner (un acteur ayant joué le rôle de Data_the_android),
Diesel_the_dog (un chien ayant joué divers rôles, dont celui d'un de ses ancêtres ici identifié par le terme The_most_famous_dog_named_Togo), The_most_famous_dog_named_Togo, The_character_of_the_most_famous_dog_named_Togo.

Note: vous pouvez abrévier "subtype: " par "\." et "instance:" par "|.".

Aidez vous des conseils de la page suivante puis, une fois cet exercice terminé,
répondez aux questions de la page précédente.
Solutions.

TD – Exemples d'organisation de types de concepts

Quelques règles importantes:

Un type de concept représentant – ou étant dépendant de –
- un rôle (e.g. les types Actor, Driver),
- une phase (e.g. Teenager, Plane_in_the_1950s, Plane_flying_over_France, Montreal_in_the_1950s),
- d'un point de vue, etc. (tout ce qui n'est pas une propriété|qualité intrinsèque),
ne peut sémantiquement être supertype d'un type de concept "naturel" (i.e. ne dépendant pas d'un rôle, d'une phase, d'un point de vue, ...). E.g., représenter Actor comme supertype de Human_being n'a pas de sens. Concernant Person et ses sous-types dans la catégorisation de la page précédente, voici quelques questions:
- Peut-on en déduire que Person est un type "naturel" (comme Human_being donc) ?
- Human_character et Android_character peuvent-ils être sous-types de Person ? (Voir aussi les autres questions qui sont en commentaire.)
- Dans Star Trek, Data_the_android et au moins les extra-terrestres humanoïdes semblent pouvoir être catégorisés comme des personnes. Toutefois, cela est-il logiquement toujours le cas pour Data_the_android lorsqu'il se déconnecte ? Qu'est-ce qui fait que l'on peut se poser la question alors qu'un être humain qui dort est toujours considéré comme une personne ? I.e., qu'est-ce qu'être une personne ? Similairement, sachant qu'un être humain ayant décédé est référé comme étant une personne, à quoi réfère t-on quand on réfère à un être humain ? Note: les réponses aux 4 dernières questions partagent au moins une même cause.
Les identificateurs|identifiants utilisés doivent autant que possible être
- des noms communs/propres (éviter les verbes, adjectifs, ... car, par exemple, "2 Vol" a un sens mais pas "2 Voler");
- au singulier, ne serait-ce que pour pouvoir être quantifiés (e.g., en FE, écrivez `2 Vol', pas `2 Vols')
- avec le moins possible de majuscules
  → pas de style Intercap;
  → pas de majuscules pour les noms de types de relation;
  → l'initiale peut être en majuscule pour
  - les noms des objets individus (comme dans les langues Européennes),
  - éventuellement les noms de "types de concept"|classes.
Si vous hésitez entre 2 relations dont une seule est transitive, choisissez la transitive (e.g., choisissez "<=" au lieu de "argument").
Sinon, si vous hésitez entre 2 relations, choisissez la plus basique|générique.

TD – Exemples d'organisation de types de concepts

Modélisez - initialement dans le langage que vous souhaitez (UML, XML, C++, ...) -
le schéma d'une BDD (ou document) devant contenir seulement les types d'objets suivants
(les noms - à utiliser - des types de concept commencent par une majuscule, ceux des
types de relations sont en italique) :

any Company has for employee at least one Employee
any Person may be a Man, Woman, ... and may be an Employee
any Employee has for id an ID and for photo a Photo.

Citez 4 problèmes conceptuels de cette modélisation en C++
et résolvez-les en C++ (ou autre langage statique et typé)
(attention, cet exercice est indépendant de celui ci-dessus) :

class HumanBeing { bool isMale ; }
class Person : HumanBeing ;
class Employee : Person ;
class Company { Employee employee; }

Solutions.

Ce TD est poursuivi par ce TP sur organisation de types de concepts.