Le Modèle qui convient à de très nombreux usages

Il y a quelques années j'ai été confronté au problème suivant: caractériser la plupart des outils de développement logiciels existants sur le marché, de façon à disposer d'une base de comparaison suffisamment solide. L'idée commerciale sous jacente étant évidemment de sortir les meilleurs arguments pour promouvoir tel outil.

Il m'est apparu que l'on peu caractériser un outil logiciel par les systèmes d'exploitation qui le supportent, par les systèmes de gestion de fichiers et les bases de données compatibles, par les interfaces graphiques ou caractère suppportés, par les langages utilisables, etc ...

On peut considérer chacun de ces points comme autant de caractéristiques élémentaires de l'outil de développement logiciel.
Si la liste de ces caractéristiques est finie et stable, mon problème est bien résolu. En effet cela revient à créer un modèle (version 1) de données ou sont définies les entités CARACTERISTIQUE1 à CARACTERISTIQUEn et l'entité OUTILOGICIEL.

Entre CARACTERISTIQUEn et OUTILOGICIEL, il ya une relation 1-n qui décrit le fait que l'OUTILOGICIEL a cette caractéristique.
Avec ce modèle, je peux spécifier une ou plusieurs caractéristiques et obtenir en retour le ou les outils logiciels qui ont ces caractéristiques. C'est simple... et ça marche !

Oui, mais la liste de ces caractéristiques est en constante évolution; toute apparition d'une nouvelle caractéristique entrainerait l'obligation de créer une nouvelle entité CARACTERISTIQUEi, c'est à dire de retoucher au modèle.

De plus il existe des interactions possibles entre ces caractéristiques qui ne sont plus si indépendantes les unes des autres; par exemple, on peut faire apparaitre sur certaines caractéristiques, une filiation. Par exemple, parmi la famille des systèmes d'exploitation on distingue toutes les versions de WINDOWS, toutes celles d'UNIX ou de LINUX, etc ... Il est important de pouvoir spécifier dans une recherche, le critère système de la famille LINUX et/ou implémentation UBUNTU de linux.

Notre modèle (version 1) a trop de défauts par rapport à la réalité; il faut le jeter et trouver mieux.

De façon générale, on peut dire qu'il existe une relation n-n entre l'OUTILOGICIEL et la CARACTERISTIQUE. En réalisation pratique sur une base de données, cela signifie que notre modèle (version 2) comprend les entités OUTILOGICIEL, CARACTERISTIQUE et LIEN. Il existe une relation 1-n entre OUTILOGICIEL et LIEN et une relation entre CARACTERISTIQUE et LIEN.

Mais la CARACTERISTIQUE est-elle si différente de l'OUTILOGICIEL ? Certes non; par exemple, toute base de données est un outil logiciel. Il faut encore faire un effort de généralisation pour aboutir au modèle (version 3).

Dans ce modèle on a une entité OBJET (un outil logiciel et/ou une caractéristique selon notre point de vue), et une entité LIEN.
L'entité OBJET se compose de 2 sous types correspondant à notre point de vue, un sous type origine ou composant que l'on appellera ORIGINE et un sous type destination ou composé que l'on appellera DESTINATION. Il existe alors une relation 1-n entre ORIGINE et LIEN et une relation 1-n entre DESTINATION et LIEN. En fait, ce modèle est très connu et utilisé pour gérer des nomenclatures.

Nous avons dit que la caractéristique, soit l'objet dans ce modèle (version3), peut avoir une filiation. Exemple: le système UBUNTU est un système de la famille LINUX. Et la famille de systèmes LINUX est un membre de la super famille et/ou du critère SYSTEME_EXPLOITATION. Pour modéliser ce fait on peut dire que l'entité OBJET a un sous type PERE_OBJET et définir une relation 1-n entre ce PERE_OBJET et ses fils OBJET. On obtient ainsi le modèle (version 4).

On remarque facilement que l'entité LIEN définit des relations entre OBJETs. Il peut être utile de caractériser le type de relation correspondante. D'où la nécessité de prévoir une relation 1-n entre OBJET et LIEN qui a pour effet de caractériser les types de relations possibles entre les objets. On obtient alors le modèle final (version 5).

Ce modèle convient très bien pour représenter toutes les données du problème initial et leurs interactions possibles mais qui plus est, il permet de représenter un peu n'importe quoi !

-->Voir schema joint

Le symbole fléche représente les sous types;
Objet_Pere est un sous type de Objet
Origine et Destination sont des sous types de Objet.

Le point représente une relation 1-n;
R1: Un Objet a un père Objet_Pere et un seul. Un Objet_Pere a de 0 à n fils Objet.
Seul l'objet racine de tous les autres objets n'a pas de père.
R2 et R3: Définit la relation n-n existant entre 2 objets ou plus exactement entre un objet Origine et un objet Destination;
R2: Un Lien a un objet Origine et un seul. Un objet Origine a de 0 à n Lien, c'est à dire de 0 à n relations avec un objet Destination.
R3: Un Lien a un objet Destination et un seul. Un objet Destination a de 0 à n Lien, c'est à dire de 0 à n relations avec un objet Origine.
R4: Définit le type de la relation n-n entre objet Origine et objet Destination. Un Lien a un Objet type de lien et un seul. Un Objet type de lien a 0 à n Lien.

Nous verrons, la prochaine fois, que ce modèle convient parfaitement pour notre problème initial.
Ensuite, nous verrons en quoi ce modèle est quasi universel sur divers exemples.
Ensuite, nous détaillerons les méthodes de navigation dans ce modèle en vue de répondre à diverses questions, puis les méthodes d'enrichissement de données.

Nous analyserons encore, les techniques d'éclatement ou de regroupement utiles avec toutes leurs conséquenses.
Enfin, nous réaliserons une maquette opérationnelle sur ces bases.