C. L'UML
A. Les limites
L'UML est devenu très complexe et trop large car on ne
veut pas tout utiliser dans UML (notamment les diagrammes) et parce que les
liens entre les vues ne sont pas toujours évidentes. En utilisant l'UML
on utilise un concept qui est proche de la technologie d'implémentation
(i.e. OO avec classes, interfaces, héritages, etc) alors qu'avec les
DMSL on est déjà plus proche du domaine métier (i.e.
Formulaire, Client, connecteur, communication, message, etc.). Par
définition, un non initié sera plus à l'aise sur un sujet
qu'il désire travailler ou qu'il "maitrise" plutôt que de
travailler sur un outil qui dépend d'une technologie
d'implémentation. De plus, avec l'UML il est vraiment très
difficile d'atteindre les 100% de code généré à
partir des modèles UML. Il y a un peu une relation de causes à
effets avec le fait qu'UML n'arrive pas à s'imposer.
B. L'UML peine à s'imposer
Aujourd'hui l'enthousiasme qu'a suscité UML à
son commencement s'est vite heurté aux réalités
industrielles. Due notamment aux rachats des principaux offreurs d'outils UML
par IBM. Cela a conduit à en réduire considérablement le
nombre, et a fait d'IBM le principal fournisseur d'outils UML. Malgré
cela on trouve quand même d'autres fournisseurs comme Atego (suite
d'outils Artisan) ou encore No Magic (outils simples et complets), mais qui
restent des "poids plumes" comparés au géant.
Un autre signe de faiblesse d'UML est qu'il existe très
peu de grands projets open source susceptibles de rassembler une très
grande communauté de développeurs autour d'UML comme avec GNU par
exemple. Bien sûr comme nous l'avons vu dans l'état de l'art, il
existe plusieurs outils UML open source, mais la majorité d'entre eux
sont de simples modeleurs graphiques qui ne proposent pas tous les diagrammes
UML du standard. Malgré tout on peut quand même citer le projet
Papyrus dont le but est de proposer un outil industriel complet de MBE (Model
Based Engineering), avec Eclipse, avec une notion de modèles qui est
centrale, respectant le standard UML.
C. Ce n'est pas innée
Navigabilité mono directionnelle
Héritage
Comme nous l'avons vu dans la Partie 1, pouvoir
générer du code grâce aux diagrammes UML, nécessite
un processus à suivre. La première action à faire,
après la lecture d'un cahier des charges, c'est d'élaborer les
cas d'utilisation et par la suite le diagramme de classe. Bien qu'il ne soit
pas facile d'élaborer un diagramme d'utilisation on peut quand
même concevoir que sa conception soit à la portée de tout
le monde. En revanche la conception d'un diagramme de classes est d'une tout
autre nature. En effet, un diagramme de classes est composé de plusieurs
items. Il est composé de classes, et une classe se définit par
son nom, ses attributs et ses méthodes. Demander à quelqu'un de
concevoir les attributs et les méthodes d'une classe, c'est comme si on
lui parlait une langue inconnue. De plus, pour faire un diagramme de classes,
il faut mettre des relations entre les classes Comment expliquer à un
non initié que les deux flèches suivantes ne veulent pas dire la
même chose, et que les différencier est ô combien important
?
Ces deux flèches ne sont qu'une petite partie de la
subtilité que pose la navigabilité dans les diagrammes de
classes.
Mais admettons qu'un utilisateur de base arrive à se
dépatouiller comment faire un diagramme de classes cohérent et
robuste Il n'aura dans ce cas que le corps des méthodes, et il lui faut
continuer avec un diagramme de séquences et d'activités. Dans ces
deux diagrammes, en plus des symboles qu'il faut connaitre et qui sont aussi
subtiles que les relations des diagrammes de classes, il faut avoir des
connaissances sur la boucle if-then-else pour pouvoir différencier et
pouvoir traiter les différents cas possibles Il faut donc des
connaissances sur les réactions du système, d'où des
connaissances en informatique solides. On ne peut pas faire de l'UML dans le
but de générer du code pour une application robuste sans
connaissance en informatique. Et même pour un développeur, une
formation en modélisation est primordiale pour pouvoir assimiler les
diagrammes, les symboles et toutes les subtilités que la
modélisation présente.
| 
