¡Hola! he creado este escrito persiguiendo un objetivo: Quiero enseñarle a la gente que UML no es un monstruo. Es útil, es bueno, y hay un lado de la arquitectura de software que poca gente conoce.
UML es una tecnología para hacer diagramas. A todos nos enseñaron en la escuela que hacer mapas mentales, diagramas de flujo, mapas sinópticos, mapas conceptuales, esas figuras que nos ayudan a estructurar la información en nuestra cabeza. UML es eso con esteroides, diseñado para describir problemas tecnológicos. Siendo técnicos, UML es un conjunto de estándares sobre como hacer estos diagramas, para que cada quien no haga su diagrama a su manera.
UML define más de 15 tipos de diagramas diferentes. Los más populares son los diagramas de clases y diagramas de bases de datos. Mucha gente a lo largo de la historia de la construcción del software los ha utilizado. Es considerado la “documentación técnica de un proyecto”.
¿Cuál es el problema? Casi nadie hace diagramas UML hoy en día, y sobre todo en muchas empresas hay un déficit de documentación respecto a la arquitectura del software. ¿Realmente es necesario entonces? ¿Si nadie lo usa, no será que no hace falta?
Respuesta corta. Si necesitas UML.
Imaginemos: Eres un ingeniero, un desarrollador, en una importante empresa de software. Te encargan desarrollar un sistema para un banco, el cual contiene múltiples desarrollos y complejidad. No solo eso, también tienes que exponer a los principales stakeholders (directores, etc) el proyecto, para que ellos lo aprueben y den el visto bueno. Estamos hablando de un proceso de arquitectura de software. El resultado de este proceso serían muchos dibujitos como este:
Quiero aclarar el punto. Este hipotético desarrollador tiene un fuerte problema. Tiene que decirle a personas que “no saben que es un componente, un servicio, un constructor, una key en una DB” como interactuan todas esas partes para que el sistema funcione. El desarrollador sabe construirlo. El director no. El director necesita saber cuanto tiempo te va a tomar y cuanto va a costarte hacerlo. Es decir: Tenemos dos lenguajes,
El reto es decirle a personas que no hablan tu lenguaje, la importancia de tu trabajo, tus razones para hacerlo asi, y que te entiendan. UML sirve para plasmar el lenguaje de ingeniero en mapas que dicen donde poner cada pieza del rompecabezas y porque. Literalmente son mapas de ciudades, pero en este caso de software.
El problema de UML es que es feo, tosco, y habla lenguaje de ingeniería. Es por eso que ha sido delegado al abandono, solo para servir en universidades como herramienta didáctica, y si acaso usado por veteranos del internet.
Ya sabemos que es UML. Ya sabemos para que sirve y porque nadie lo usa. Ya sabemos los retos que UML debería resolver pero no lo hace. Les diré la verdad, la culpa es nuestra, no de UML.
Nosotros los desarrolladores como arquitectos del mundo moderno tenemos la responsabilidad de decirle al mundo como lo estamos construyendo, y no estamos aprendiendo a hablar el lenguaje que habla el mundo. El lenguaje del negocio. No estamos haciendo mapas de las ciudades legibles, entendibles, y no estamos explicándoles a nuestros jefes casi como si fuesen bebés como funciona el mapa.
El reto a resolver es como comunicar mejor el mensaje. UML no lo está logrando, pero tenemos el problema en la mano, hay que encararlo.
Les presento el Modelo C4:
¿Que es el Modelo C4? muy simple. Un chico llamado Simon Brown un día se propuso resolver el problema que he expuesto en este artículo, y tras muchos años que dedicó a investigar, creó un conjunto de buenas prácticas, teorías, y enseñanzas que a cualquier desarrollador como yo y como ustedes nos permitirá hablar lenguaje negocio.
Es una metodología para crear mapas de software que sirvan realmente para explicar como funciona el software tanto para un ingeniero como para un lider de negocio. ¿Que pasa con UML entonces? No pasa nada. UML es un conjunto de teorías, C4 solo te dice como dibujar y explicar mejor las ideas basado en las reglas de UML. va de nuevo, UML te dice donde debe ir la pelota, y C4 te dice como patear la pelota para llegar ahi.
Me entusiasma escuchar la opinión que tengan sobre el tema, no soy “el” experto, ni tampoco estoy diciendo cosas labradas en piedra, es una opinión, que espero construya algo en esta bella comunidad. Feliz año nuevo!
Gracias por esta tú contribución realmente me ha sido de ayuda. Concuerdo contigo que no debemos de dar por muerto a una herramienta que contribuye en forma positiva en la compresión del software que estemos construyendo
Hola Eduardo, recomiendame porfa bibliografía sobre UML, próximamente me toca impartir un módulo en una media técnica y como todo ha sido abrupto apenas me estoy documentando
UML Distilled este libro es la principal referencia didáctica para UML. Si se es profesor, se usa este libro.
Learning UML 2.0 by O’Reilly yo siempre recomiendo libros de la editorial O’Reilly.
Lean Analytics un libro para complementar la parte analítica de la documentación.
UML for dummies versión de dummies de UML. Estos libros son muy buenos para hacer un clavado rapido al tema.
Adicionalmente añadiría que consideres C4 model, leer sobre Kanban, y sobre Lean Startup. el verdadero fundamento y poder de UML se encuentra en la gestión correcta del software.
Muchas gracias!! revisaré los enlaces
Gracias Eduardo, Muy bueno tu punto de vista.