Les entités de CAO s'enferment dans leur club
On est tenté d'affirmer que pour répondre au problème posé, il faut abandonner la manipulation d'entités de dessin généraliste, au profit d'entités de dessin spécialisées en architecture et construction. C'est ce que font les logiciels de CAO depuis une quinzaine d'années.
En choisissant une commande spécialisée « Mur courbe », et en spécifiant ses paramètres, le dessin devient automatique. Le logiciel gère tout seul l'intersection des murs entre eux, et intègre les ouvertures. C'est le moins que l'on puisse demander à un logiciel graphique dédié au bâtiment.
On pourrait donc formuler cette conclusion, en guise d'explication de la différence entre entité de dessin, et objet :
« Un objet serait une entité de dessin spécialisée pour un domaine d'application ».
Ce serait faux.
Il peut exister des entités de dessin qui sont structurées en objets. Comme il existe des entités spécialisées - les composants du bâtiment de la plupart des logiciels de CAO- qui ne sont pas structurées en objets.
La différence ne porte pas non plus sur la liste des paramètres et des propriétés propres à l'entité. Si une entité est riche en informations, bien évidemment, elle peut potentiellement susciter un grand nombre d'opérations. Mais ce critère n'est pas suffisant pour rendre cette entité « intelligente ».
A force de développement et de commandes spécialisées l'éditeur peut simuler en programmation traditionnelle un comportement intelligent de certains composants.
Il exécute un cahier des charges de plus en plus complexe. Il donne l'impression qu'une entité est intelligente, alors qu'elle répète comme un animal bien dressé une série de gestes programmés à l'avance pour un contexte bien défini. Les commandes (qui ne s'empilent pas) interdisent d'ailleurs à l'utilisateur de sortir des sentiers battus.
Bien évidemment, cette course aux fonctionnalités aboutit à des monstres de logiciels, dont le nombre de commandes finit par indisposer l'utilisateur, et encore plus le développeur, confronté à une complexité croissante du code et de la maintenance du logiciel.
L'obligation d'intégrer les IFC doit révéler rapidement les limites de cette déjà trop vieille génération de logiciels, juste au moment où ses fonctionnalités atteignent leur apogée.
Trop d'entités différentes, trop de relations à gérer vont faire éclater le club fermé et protocolaire des entités de CAO traditionnelles privées de contact avec l'extérieur.
