UML es para comunicarse

Algunas de las opiniones vertidas sobre el UML en un reciente cónclave de trolls me han vuelto a sorprender, porque no llego a entender cómo siempre que se critica la forma de construir software se sigue cargando contra algo que, como su nombre Unified Modeling Language indica no es más que una notación, una forma de expresar las cosas, un lenguaje.

Como era de esperar en algo tan complejo, tiene aspectos criticables, pero para mí lo más importante es que proporciona un “estándar semántico” para las descripciones de los sistemas, que nos permite representar e intercambiar más información de forma más exacta. UML no es la única forma de expresarlas, ni en muchos casos la mejor, y a veces ni siquiera orientada a objetos; pero cuando tienes que trabajar en equipo permite compartir una forma de dotar de significado a lo que queremos transmitir al otro.

Entiendo que en parte el problema es que hay quien confunde utilizar UML con utilizar una metodología u otra, con tener el código en perfecta sincronía con los diagramas de diseño, con tener que dibujar absolutamente todas las cosas que se analizan y diseñan con una herramienta en el computador… Desde luego, el mayor desafío de la Ingeniería del Software es que “no hay bala de plata”, no tenemos una receta mágica apropiada para todas las combinaciones de problemas y condiciones de entorno (presupuesto, calendario, equipo, cliente, tecnología, legados, etc), sino que todo debe recaer en el conocimiento, la experiencia, la capacidad del equipo de desarrollo y la confianza que se deposita en ellos, y el buen juicio del responsable de fijar cómo proceder en cada proyecto, o en cada fase del proyecto.

Por poner un ejemplo minimalista sobre la diferencia entre notación y metodología, en el diseño del componente de traffic shaping de eBox se utiliza un único diagrama de clases que permite a los desarrolladores “entender” qué es lo que hace y cómo está implementado. Su finalidad es orientar a quien vaya a tocar ese módulo sobre cómo funciona y cual es el entorno con el que se relaciona:

La “metodología” utilizada ha sido recoger en varias páginas del wiki:

1. Objetivo
1. Requisitos
1. Diseño

Evidentemente, esto se apoya en la existencia de guías de desarrollo que explican la API y cómo se escriben los módulos, en la abundancia de comentarios en el código fuente, en los lenguajes y herramientas utilizadas, en la forma de establecer los requisitos, en su ciclo de vida y en otras características de este proyecto concreto que seguramente no sean directamente aplicables a ningún otro.

¿Y el interfaz de usuario? ¿Y el diseño de la interacción? Pues eso daría para otro artículo, pero básicamente se concibe de forma global y casi no se ha tenido en cuenta hasta ahora, momento en el que casi toda la funcionalidad de los módulos de la versión 1.0 está completa y se puede “organizar” de un modo más integrado. Inicialmente se procuró facilitar el empleo por parte de los usuarios, implementando por ejemplo alguna de las sugerencias por parte de Roberto Abizanda.

Ha habido varias revisiones informales por parte de personas externas al equipo de desarrollo, que casi siempre han concluido en que era mejor esperar a que siguiera evolucionando la funcionalidad antes de abordar un QA exhaustiva sobre usabilidad. Así que permaneced atentos

En estos momento se está migrando el código gradualmente a un MVC desarrollado para eBox que aportará coherencia a todas las representaciones en tabla/pestañas, y se está evaluando una solución a la excesiva profundidad del menú de opciones. Otro problema detectado es la gestión de cientos o miles de cuentas o configuraciones, pero por el momento no se ha fijado como prioridad.