¿Por qué no se usa UML en la mayoría del software libre (por ejemplo, en Linux)?

Estoy tratando de entender por qué UML no se usa en la mayoría de los proyectos de software libre . Por ejemplo, mi sistema Debian / Linux tiene probablemente más de diez mil paquetes de software gratuitos, y no puedo nombrar ni siquiera uno que haya sido desarrollado utilizando un marco y metodología UML explícitos . Por ejemplo, Qt , GCC , kernel de Linux , bash , GNU make , Ocaml , Gnome , Unison , lighttpd , libonion , docker son proyectos de software libre que (AFAIK) no mencionan en absoluto a UML.

^{(Supongo que UML es muy adecuado para la subcontratación formal de tareas de desarrollo, y no es así como se desarrolla el software libre)}

Tenga en cuenta que si bien leí algo de material sobre UML, no pretendo entenderlo bien.

En realidad, no puedo nombrar fácilmente un software gratuito donde se haya usado UML (excepto quizás algunas herramientas UML implementadas como software libre). Quizás OpenStack es una excepción (algo menciona UML).

^{(incluso los antiguos proyectos de software libre podrían haber adoptado UML después de que se iniciaron, pero no lo hicieron)}

Algunos colegas que trabajan en Papyrus mencionaron que la mayoría de los proyectos de software libre no tenían al principio ningún modelo formalizado explícitamente (y lo suficientemente profundo). Además, UML parece mucho más relacionado con Java de lo que dice (no estoy completamente seguro de que tenga sentido para Ocaml o Common Lisp o Haskell o Javascript, y tal vez ni siquiera para C ++ 11 ...). Quizás el desarrollo de software ágil no sea muy amigable con UML.

Vea también esta respuesta a una pregunta relacionada de alguna manera. El blog de M.Fowler ¿Está muerto el diseño? es perspicaz

^{PD. No creo que sea principalmente una cuestión de opinión; debería haber alguna razón objetiva y alguna característica esencial del software libre que explique por qué. Tiendo a adivinar que UML solo es útil para la subcontratación formalizada, y es útil solo cuando una parte del software desarrollado está oculto, como en los proyectos propietarios. Si eso es cierto, UML sería incompatible con el desarrollo de software libre.}

^{NB: yo tampoco soy fanático de UML. No defino UML solo como documentación en papel, sino también como un formato [meta-] de datos para herramientas de software}

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.

Usemos Linux como ejemplo,

• No es un proyecto orientado a objetos, algunas partes, como el VFS, se pueden modelar en UML, pero otras no pueden ser o no muy efectivas, es decir, básicamente solo una traducción directa de structun diagrama de clase sin relaciones.
• UML es bueno para la documentación, para que alguien nuevo en un proyecto se ponga al día. Eso no es algo que realmente atiende Linux, se espera que las personas lo aprendan ellos mismos.
• No estoy seguro de qué herramienta UML usar, la gente necesita ponerse de acuerdo en algo si se va a mantener. Había una aplicación gratuita de Java para eso, pero no creo que muchos quieran usarla.
• En los años 90, la GUI seguía siendo un desafío en Linux. Simplemente vaya a excavar el archivo de la lista de correo, apuesto a que no encontrará ningún tipo de gráficos que no sea el logotipo de Linux en formato xpm que se mostrará en el tiempo de arranque. El texto sin formato es el formato preferido.
• No creo que a nadie realmente le haya importado el diseño. Las personas se preocupan por las características y, si son aceptadas, el código será analizado. Los casos de uso aún se describen mejor en palabras, al igual que cómo se escriben estándares como POSIX y SUS.
• Muchos objetos en el dominio de los sistemas operativos son bien entendidos y estandarizados dentro de la comunidad. Por ejemplo, la gente sabría cómo se struct in_addrve un recuerdo en la memoria, ningún diagrama podría aclararlo.
• UML no ayuda mucho en el algoritmo de modelado, como el asignador de memoria, el planificador, los manejadores de interrupciones, etc. La fuente es probablemente más fácil de entender.

Esas son las cosas que puedo pensar en la configuración del proyecto Linux. Se trata más de practicidad, supongo. Curiosamente, no recuerdo que Tanenbaum haya usado ningún UML en su libro de texto del SO para describir Minix.

Probablemente valga la pena mencionar que tampoco uso UML en el trabajo. Probablemente el 20% de las personas con las que trabajo conocen algún subconjunto de UML.

UML es una representación, por lo que es una forma de lenguaje, y por el bien de los argumentos, supongamos que su propósito es comunicar un modelo mental de una persona a otra.

Lo que busco en un idioma es su eficiencia para capturar los cambios en el modelo mental de uno. Supongamos que después de escribir la descripción del modelo de uno, se necesita hacer un pequeño cambio. ¿Qué tan grande debe hacerse un cambio en la representación? En un lenguaje textual, una manera de medir es ejecutar un diffcódigo entre el código antes y después, y contar las diferencias. En un lenguaje gráfico, debería haber una forma similar de medir la diferencia.

En mi humilde opinión, llamo a un lenguaje "dominio específico" (DSL) en la medida en que minimiza la medida anterior, lo que tiene beneficios obvios en la reducción de costos de mantenimiento y errores. ¿Cómo hacer un DSL? Hay varias formas Una de las más simples es definir estructuras y métodos de datos en un lenguaje de programación existente. Esto agrega sustantivos y verbos al lenguaje base, lo que facilita decir lo que uno quiere. (Nota: no busco un DSL que no tenga curva de aprendizaje. Puede ser que el lector de un DSL deba invertir el costo único de aprenderlo).

El punto importante es: en todos los casos, el DSL tiene que contener los términos que hacen conveniente la expresión del modelo y los cambios en el modelo. Dado que no existe un límite obvio para el rango de dominios posibles, ningún DSL único puede servirlos a todos.

Mi impresión de UML es que eso es lo que trató de hacer.