Klaus-Dieter Schewe, en particular, ha reseado lo que l interpreta como un cmulo de limitaciones y oscuridades de UML, popularizando adems su consideracin como

un dinosaurio moderno [Sch00]. Al cabo de un anlisis pormenorizado del que aqu no podemos dar cuenta sin excedernos de espacio, Schewe estima que, dando continuidad a una vieja polmica iniciada por E. F. Codd cuando ste cuestion a los modelos en Entidad-Relacin, UML es el ganador contemporneo cuando se trata de falta de definiciones precisas, falta de una clara semntica, falta de claridad con respecto a los niveles de abstraccin y falta de una metodologa pragmtica. (9) Hoffmeister y otros [HNS99] alegan que UML es deficiente para describir correspondencias tales como el mapeo entre elementos en diferentes vistas, que seran mejor representadas en una tabla; faltan tambin en UML los elementos para modelar comunicacin peer-to-peer. Los diagramas de secuencia de UML no son tampoco adecuados para soportar la configuracin dinmica de un sistema, ni para describir secuencias generales de actividades. A despecho que los responsables de UML insistan en la precisin y rigor de su semntica, se han organizado simposios y workshops enteros para analizar las limitaciones del modelo semntico de UML y su falta de recursos para detectar tempranamente errores de requerimiento y diseo [OOS99]. Si bien se reconoce que con UML es posible representar virtualmente cualquier cosa, incluso fenmenos y procesos que no son software, se debe admitir que muchas veces no existen formas estndar de materializar esas representaciones, de modo que no pueden intercambiarse modelos entre diversas herramientas y contextos sin prdida de informacin. Se ha dicho que ni las clases, ni los componentes, ni los packages, ni los subsistemas de UML son unidades arquitectnicas adecuadas: las clases estn tecnolgicamente sesgadas hacia la OO y representan entidades de granularidad demasiado pequea; los componentes representan piezas fsicas de implementacin de un sistema y por ser unidades de implementacin y no de diseo, es evidente que existen en el nivel indebido de abstraccin; un package carece de

la estructura interna necesaria; los subsistemas pueden no aparecer en los diagramas de despliegue, o mezclarse con otras entidades de diferente granuralidad y propsito, carecen del concepto de puerto y su semntica y pragmtica se han estimado caticas [StS/f]. Una debilidad ms seria tiene que ver con la falta de modelos causales rigurosos; aunque UML proporciona herramientas para modelar requerimientos de comportamiento (diagramas de estado, de actividad y de secuencia), al menos en UML 1.x no existe diferencia alguna, por ejemplo, entre mensajes opcionales y mensajes requeridos; se pueden colorear los mensajes con restricciones, por cierto, pero es imposible hacerlo de una manera estndar. Asimismo, aunque los objetos de UML se pueden descomponer en piezas ms pequeas, no es posible hacer lo propio con los mensajes. Tambin es palpable la sensacin de que su soporte para componentes, subsistemas y servicios necesita ser mejorada sustancialmente (incluso en UML 2.0), que los modelos de implementacin son inmaduros y que no hay una clara diferenciacin o un orden claro de correspondencias entre modelos notacionales y meta-modelos, o entre anlisis y diseo [Dou00] [AW99] [KroS/f].