Hay diferentes formas de usar UML. Martin Fowler llama a estos modos UML e identifica cuatro: UML como Notes , UML como Sketch , UML como Blueprint y UML como lenguaje de programación .
UML como lenguaje de programación nunca despegó realmente. Se han realizado algunos trabajos en esta área bajo diferentes nombres, como Model Driven Architecture o Model Based Software Engineering. En este enfoque, crea modelos altamente detallados de su sistema de software y genera el código a partir de esos modelos. Puede haber algunos casos de uso en los que este enfoque es útil, pero no para el software en general y, especialmente, no fuera de las grandes empresas que pueden permitirse las herramientas que impulsan este enfoque. También es un proceso lento: puedo escribir el código de una clase más rápido de lo que puedo crear todos los modelos gráficos necesarios para implementarlo.
UML como Blueprint a menudo es indicativo de un proyecto de "gran diseño por adelantado" . No tiene que ser, por supuesto. El modelo también se puede describir completamente para un incremento particular. Pero la idea es que se dedica el tiempo a crear un diseño en forma de modelos UML que luego se entregan a alguien para convertirlos en código. Todos los detalles están detallados y la conversión al código tiende a ser más mecánica.
UML como Sketch y UML como Notes son de naturaleza similar, pero difieren en función de cuándo se usan. El uso de UML como croquis significa que esbozará diseños utilizando anotaciones UML, pero es probable que los diagramas no estén completos, pero se centrarán en aspectos particulares del diseño que necesita comunicarse con otros. UML como Notes es similar, pero los modelos se crean después del código para ayudar a comprender la base del código.
Cuando estás considerando esto, creo que todo lo anterior es cierto para cualquier tipo de notación de modelado. Puede aplicarlo a diagramas de relación de entidad, diagramas IDEF , notación de modelado de procesos de negocios, etc. Independientemente de la notación de modelado, puede elegir cuándo aplicarla (antes como una especificación, después como una representación alternativa) y cuántos detalles (detalles completos de los aspectos clave).
El otro lado de esto es la cultura de código abierto.
A menudo, los proyectos de código abierto comienzan para resolver un problema que un individuo (o hoy, una empresa) está experimentando. Si está siendo lanzado por un individuo, el número de desarrolladores es 1. En este caso, la sobrecarga de comunicación es extremadamente baja y hay poca necesidad de comunicarse sobre los requisitos y el diseño. En una empresa, es probable que haya un pequeño equipo. En este caso, es probable que necesite comunicar las posibilidades de diseño y discutir las compensaciones. Sin embargo, una vez que haya tomado sus decisiones de diseño, debe mantener sus modelos a medida que su base de código cambia con el tiempo o desecharlos. En términos de modelado ágil , "documente continuamente" y mantenga una "fuente única de información" .
Como breve resumen, existe la idea de que el código es diseño y que los modelos son solo vistas alternativas del diseño. Jack Reeves escribió tres ensayos sobre el código como diseño , y también hay discusiones sobre el wiki de C2, discutiendo las ideas de que el código fuente es el diseño , el diseño es el código fuente y el código fuente y el modelado . Si se suscribe a esta creencia (lo que hago), entonces el código fuente es la realidad y cualquier diagrama debe existir para comprender el código y, lo que es más importante, la razón detrás de por qué el código es lo que es.
Un proyecto de código abierto exitoso, como los que usted menciona, tiene colaboradores en todo el mundo. Estos contribuyentes tienden a ser técnicamente competentes en las tecnologías que impulsan el software y es probable que también sean usuarios del software. Los contribuyentes son personas que pueden leer el código fuente tan fácilmente como los modelos, y pueden usar herramientas (IDEs y herramientas de ingeniería inversa) para comprender el código (incluida la generación de modelos, si sienten la necesidad). También pueden crear bocetos del flujo por su cuenta.
De los cuatro modos que describe Fowler, no creo que encuentre un proyecto de código abierto, o muchos proyectos en cualquier lugar, que estén usando lenguajes de modelado como lenguajes de programación o planos. Esto deja notas y bocetos como posibles usos para UML. El contribuyente crearía las notas para el contribuyente, por lo que probablemente no las encuentre cargadas en ningún lado. Los bocetos disminuyen en valor a medida que el código se vuelve más completo y probablemente no se mantendrá, ya que eso solo requeriría esfuerzo por parte de los contribuyentes.
Muchos proyectos de código abierto no tienen modelos disponibles porque no agrega valor. Sin embargo, eso no significa que los modelos no fueron creados por alguien al principio del proyecto o que las personas no hayan creado sus propios modelos del sistema. Es más efectivo en el tiempo mantener una fuente de información de diseño: el código fuente.
Si desea encontrar personas que intercambien información de diseño, le recomiendo que busque en cualquier tipo de foros o listas de correo que utilicen los colaboradores. A menudo, estos foros y listas de correo sirven como documentación de diseño para proyectos. Es posible que no encuentre UML formal, pero puede encontrar algún tipo de representación gráfica de información de diseño y modelos allí. También puede ingresar a las salas de chat u otros canales de comunicación para el proyecto; si ve personas hablando sobre decisiones de diseño, es posible que se estén comunicando con los modelos gráficos. Pero es probable que no se conviertan en parte de un repositorio ya que no son valiosos una vez que han cumplido su propósito en la comunicación.