¿Qué tan importantes son los diagramas UML para un proyecto exitoso? [cerrado]

Estoy en medio de un proyecto y me pidieron que escribiera diagramas UML (casos de uso, diagrama de clase, etc.). El proyecto no es muy complejo.

Me preguntaba si esto sería una pérdida de tiempo? ¿Debería estar haciendo otras cosas divertidas como escribir código? ¿Y cuándo no está bien construir algo sin pasar por toda la fase conceptual? ¿Se trata de complejidad? Y si es así, ¿cómo medirlo?

Yo era un gran fan de UML hace un tiempo. Incluso estoy certificado por OMG. Lo utilicé ampliamente en grandes proyectos empresariales en los que estuve involucrado.

Hoy, detuve UML casi por completo. A veces, uso el diagrama de secuencia que encuentro muy útil para describir las interacciones entre sistemas, pero ningún otro diagrama.

Ahora prefiero trabajar con historias de usuarios, respaldadas por (solo) la documentación necesaria escrita por el propietario del producto (o analistas) Y su (su) dedicación al equipo de desarrollo para dar más detalles según sea necesario.

UML es una herramienta que puede usar, pero ciertamente no es un factor crítico para el éxito de sus proyectos. Después de muchos años, ahora creo que el factor crítico es el equipo de desarrollo, sin importar qué herramientas use.

La planificación es crítica, pero como advierte el famoso estratega Carl von Clausewitz

Ningún plan de campaña sobrevive al primer contacto con el enemigo.

Por lo tanto, no es una gran pérdida de tiempo planificar cómo atacar inicialmente los problemas. Pero probablemente sea una pérdida de tiempo documentar su código para futuros programadores. Para usar una metáfora militar, necesitas un plan de batalla, pero no le darías ese plan a los historiadores para usarlo como un informe posterior a la acción.

Más concretamente, puede usar estos diagramas para comunicar sus intenciones entre su equipo y pensar en su plan de ataque antes y durante el proyecto. Pero lo más probable es que lo que se te ocurra deba modificarse a medida que codifiques y aprendas más sobre el problema. Casi siempre su plan / diseño inicial necesita ser alterado porque no puede saber todo por adelantado.

Creo que los diagramas UML solo pueden ser útiles si expresan algo en un nivel de abstracción más alto que su código .

Escribir UML solo por escribir UML se convierte en una burocracia innecesaria y hace que el proyecto y el código sean menos adaptables a los cambios sin ningún beneficio.

Por ejemplo, un diagrama de clase UML que muestra todas las clases en un paquete, con todos sus atributos y métodos, algo que se puede generar fácilmente de forma automática, no proporciona ningún valor: está en el mismo nivel de abstracción que su código . Además, el código seguramente será una mejor fuente de esa información porque siempre estará actualizado, y probablemente será documentado y organizado de una manera que sea más fácil saber qué métodos / atributos / cosas son más importantes.

Por otro lado, si tiene conceptos de un nivel de abstracción superior al que puede expresarse en el código, puede ser una buena idea documentarlos en un diagrama.

Por ejemplo, un diagrama que muestra los módulos abstractos de nivel superior en un sistema complejo, con sus dependencias y tal vez una pequeña descripción de sus responsabilidades y a qué paquete / espacio de nombres se asignan en el código fuente puede ser realmente útil para un nuevo miembro del equipo eso debe introducirse en el proyecto, o también puede usarse para determinar dónde se debe lanzar una nueva clase / funcionalidad.

Otro ejemplo de un diagrama útil podría ser un diagrama de secuencia que muestre los pasos de alto nivel a seguir en un protocolo de comunicación. Quizás cada paso de esos tenga sus pequeñas peculiaridades y complejidades, pero probablemente sea suficiente para describirlos en el código mismo. El diagrama de nivel superior puede ayudar a un programador a comprender el "panorama general" de las cosas fácilmente sin tener que preocuparse por las complejidades de cada interacción.

De todos modos, esos son solo algunos ejemplos; Hay muchos casos en los que un diagrama simple puede ser de gran ayuda. Solo recuerda que deberías hacerlo solo cuando no puedas expresar algo en el código mismo. Si se encuentra utilizando diagramas UML para explicar el código fuente en sí, haga que el código soruce sea más autodocumentado.

Finalmente, algunas de las reglas generales que se aplican al código también pueden aplicarse a los diagramas: evite repetirlo, manténgalo simple, no tema cambiar las cosas (solo porque algo está documentado en un diagrama UML no significa que no pueda cambiar) y siempre piense en quién leerá / mantendrá esos diagramas en el futuro (probablemente su futuro) cuando los escriba :)

UML tiene valor si los miembros del equipo lo entienden colectivamente y lo consideran una forma útil de resumir y comunicar decisiones de diseño. No necesita saberlo todo, solo ese subconjunto que el equipo encuentra útil.

Además, no necesita dibujar diagramas perfectos y pulidos. Un diagrama de secuencia esbozado en una pizarra o un diagrama de clase en el que las clases son notas post-it pegadas a esa pizarra puede ser suficiente, dependiendo del contexto.

Una vez trabajé en un concierto donde necesitaba administrar un equipo de desarrolladores de contratos en el extranjero.

Algunas de las cosas que estaban produciendo eran bastante horrendas (un síntoma común de los codificadores de contratos remotos: realmente no les importa mucho su código, solo quieren terminarlo rápidamente).

Para administrar el proyecto, me encontré produciendo diagramas UML y entregándoselos a código. Tuvo mucho éxito: no me llevó tanto tiempo escribir un programa en UML, mucho más rápido que en Java, y era algo que los contratistas podían seguir y comparar.

Una advertencia: a veces querían ser creativos y desviarse de mis modelos, sin embargo, en esos casos, en realidad eran correctos y, sobre todo, el UML mejoró la calidad del producto final

Si alguien le pidió que prepare diagramas UML y que alguien le pague su salario, entonces no es realmente una pérdida de tiempo. Puede o no ser una pérdida de tiempo para alguien.

Si esa persona planea comprender su proyecto leyendo sus diagramas UML, entonces probablemente no sea una pérdida de tiempo.

Me resulta útil en la etapa de diseño inicial para obtener ideas en papel o en la pizarra. Principalmente he usado diagramas de clases UML, sin un estricto cumplimiento de los estándares. Es útil volver a visitar su diseño original UML cuando está a medio camino y también al final del proyecto. Me ha ayudado a mirar una base de código en un nivel más alto de abstracción que uno puede leer con solo leer el código, e incluso me ha ayudado a detectar posibles errores.

Hay un punto de buena hecha aquí por ragu.pattabi distingue entre dos tipos de UML ...

Creo que el sabor ágil de UML (por ejemplo, un boceto rápido de pizarra) tiene más éxito que el sabor en cascada de UML (por ejemplo, diagrama elaborado con todos los detalles sangrientos para documentación, generación de código, etc. para hacer felices a los gerentes expertos en documentos).

Cuando UML fue visto como una habilidad 'imprescindible' (hace 10 años o más) probablemente estaba en contra debido a las opiniones obstinadas de sus muchos fanáticos en ese momento. Pero ahora que ha caído en desgracia, me encuentro viéndolo tal como es: una herramienta útil que tiene mérito pero no es la bala de plata del desarrollo de software.

Uso UML (o algo similar a UML :)) cuando hablo con amigos sobre algo que estamos a punto de hacer. Para discutir ideas. No para preparar un proyecto UML que genere código automáticamente para mí. No puedo imaginar crear mis clases en UML y luego generar código y no modificarlo más tarde. Esto nunca pasa. Por lo tanto, tendrá que traer cambios del código a UML. Y cuando uso UML dibujo en pizarra o papel. Nunca en una herramienta como Enterprise Architect.

La única razón para documentar todo mi código en UML sería un contrato donde el cliente lo exige. Por ejemplo, cuando quiere tener una opción para cambiar la tienda de software después de que una parte del software haya terminado.

La documentación de trabajo del proyecto es una entrega fundamental de un proyecto profesional. ¿Cuánto es suficiente? Bueno, depende, por supuesto, de muchos factores. Sin embargo, en mi opinión, los casos de uso, los diagramas de clases, los diagramas de flujo de procesos, etc. no son una pérdida de tiempo en absoluto. Tienen valor en varias fases del proyecto. El único problema con la documentación suele ser los recursos.

Algunos programadores consideran que la documentación es una pérdida de tiempo. Pero esto no es cierto. Si ve la documentación como una muestra de sus reglas de diseño y sistema de una manera elegante y clara, puede llegar a apreciarla más. Además, uno necesita ponerse en la posición de las personas que necesitan mantener el sistema. Lanzar 500 archivos de código y pedirles que solucionen los problemas con ellos es algo malo pero no raro.

Le sugiero que asigne tiempo a su proyecto y produzca los diagramas en ciclos. El primero cubriría los aspectos de alto nivel de su proyecto y los niveles posteriores podrían detenerse más en los detalles.

Los casos de uso en particular no pueden deducirse fácilmente del código (a diferencia de muchos otros aspectos de un sistema). Asegúrate de hacer eso.

UML es una herramienta, nada más, y si es útil o incluso crucial depende únicamente de su flujo de trabajo de desarrollo y diseño. Hay muchas maneras de llegar a Roma, y ​​algunas de ellas involucran UML, mientras que otras no.

Si su flujo de trabajo se basa en UML para documentar o planificar su arquitectura, dejarlo caer sería una tontería. Si UML es la mejor manera posible de comunicar la estructura del proyecto a otros miembros del equipo (en el sentido más amplio), entonces, por todos los medios, úselo. Pero si el proyecto funciona bien sin UML, entonces hacer diagramas UML por el simple hecho de que sea una tontería.

Tengo algunos pensamientos sobre esto. El lenguaje puede ser usado y abusado, obligar y distraer, desencadenar y detener. UML es solo otro idioma adecuado para un conjunto específico de problemas y, como cualquier otro idioma, tomará tiempo y esfuerzo aprender a hablarlo con fluidez y comprenderlo correctamente.

La decisión sobre qué comunicar es increíblemente más importante que el lenguaje en el que se comunica. UML no hará mágicamente comprensibles sus malos diseños. Al igual que cualquier otro idioma, es fácil perderse en los detalles o dejar demasiado a la imaginación.

UML recibió un mal nombre debido a los numerosos IDE horribles, lo que permite la creación de prototipos de ida y vuelta, la manipulación de gráficos intensivos en clics y la dificultad de cambiar cualquier cosa. UML 2.0 puede ser lo suficientemente complejo como para satisfacer a ciertos académicos, pero su metamodelo no parece atraer muchas aplicaciones prácticas.

Aún así, uso UML de vez en cuando. Evaluar un diseño de alto nivel (un buen diseño tiene complejidad en los márgenes y simplicidad en el centro). Comunicar una idea a un colega y recibir comentarios. Encontrar relaciones ocultas, normalizar, etc. Pero siempre es un reflejo de algo que ya está en mi cabeza. En general, dibujo UML con lápiz y papel, preferiblemente lejos de cualquier computadora. Si es necesario, cuando un diseño cristaliza, hago una representación visual en un programa de dibujo.

UML es absolutamente fantástico para obtener una vista gráfica de su arquitectura utilizando un diagrama de clase. La interacción con el diagrama de secuencia es mágica para mí. Por lo tanto, el problema no es UML sino MDD para mí.

Quiero decir que si UML es un espectador del código, entonces es realmente útil para fines de documentación, pero ciertamente no para la generación de código. El proyecto debe estar centrado en el código y ciertamente no centrado en el modelo. UML debe usarse en la etapa de implementación usando un código en vivo y sincronización de modelo. Me refiero no solo al nivel de requerimiento que requiere demasiada inversión para un pequeño retorno en productividad y calidad.

Los encuentro muy sobrevalorados. Las considero las únicas imágenes que no pintan más que mil palabras.

UML solo tiene valor si las personas que diseñan el sistema no pueden escribir el código por sí mismas. es decir, UML es un "lenguaje" que comunica los conceptos arquitectónicos a otra persona. Ahora, si usted es la persona que diseña el código y lo implementa, ¿por qué necesitaría mostrarse qué es lo que va a hacer? ?! Súbete y dirígete directamente a la codificación. Aún tendrá que documentar lo que hizo más tarde, pero la eficiencia general es más rápida.

Pero, si usted fuera un arquitecto de sistemas que quisiera decirle a su equipo de desarrolladores subcontratados lo que quería, entonces tendría que decirles de alguna manera, y ahí es donde entra UML. Sin embargo, creo que hay muchos medios alternativos para realizar Esta tarea hoy en día, y francamente, la complejidad de la creación de diagramas UML significa que todos tienen que entender cómo leerla, lo que es algo autodestructivo si no lo hacen.

Nunca fui fanático de UML, pero he llegado a valorar un buen diagrama de secuencia para describir las interacciones entre sistemas o tareas.

Sin embargo, el diagrama de clases es obsoleto antes de que nazca. Un diseño aproximado no requiere UML, y una documentación completa se extrae automáticamente (en vivo) de la base del código. Javadoc y Doxygen han obsoleto por completo la necesidad de diagramas de clases manuales.

Lo que pasa con la documentación es que hay dos niveles:

• las decisiones de alto nivel (arquitectónicas) deben ser documentación manual
• los hechos de bajo nivel (relaciones entre entidades) deben extraerse automáticamente

Por lo general, itero entre el código y los diagramas UML. Encuentro que los diagramas ayudan a mostrar el panorama general y un camino sólido hacia adelante y pueden cambiarse bastante rápido cuando se descubren problemas. Además, cuando tengo los diagramas, la codificación tiende a ser trivial.

Por el contrario, cuando dibujo el código en imágenes, expone los problemas de dependencia y hace que las oportunidades de mejora del diseño sean obvias, lo que probablemente no se habría notado si solo tuviéramos el código para trabajar. En particular, si es un dolor dibujar, también será un dolor codificar y una pesadilla mantener.

He descubierto que se requiere iteración, porque solo dibujar las imágenes siempre pierde aspectos importantes, mientras que la codificación da como resultado diseños problemáticos.

Sin embargo, como dijo otro cartel, todo se reduce a la gente. Si están capacitados para "usar" diagramas UML, entonces UML es invaluable. Si no lo son, entonces los diagramas no tienen valor.

Por lo tanto, la respuesta a su pregunta realmente es "depende". En este caso, depende de las personas, la complejidad del proyecto y la importancia de que el sistema funcione correctamente.

Desde mi experiencia, el UML es importante para la comunicación entre los desarrolladores sobre los patrones de código y para la arquitectura en general de la aplicación.

Me encantan los diagramas, pero si me pidieran que hiciera uno (¡especialmente UML!), Haría dos preguntas:

1. ¿Para quién?
2. ¿Lo necesitan ahora?

Los diagramas se desactualizan de inmediato. Entonces, a menos que lo esté usando para comunicarse con alguien ahora, simplemente se pudrirá. Y si la persona con la que se está comunicando le iría mejor con una descripción de texto, o una llamada telefónica, o un digram informal en una pizarra, sugiérale eso.

Una de las principales quejas para mí sobre los diagramas UML, como los he visto utilizados hasta ahora, es que en su mayoría solo tienden a servir como "imágenes bonitas" en la pared de alguien o como una página doblada en una encuadernación en algún lugar y rara vez sirven como línea de base para un código de producción.

En este tipo de escenario, los diagramas UML (o cualquier sabor del lenguaje de modelado que use) rara vez son útiles a largo plazo, ya que tienden a sufrir una pérdida de relevancia a medida que pasa el tiempo y el proyecto evoluciona. Estos dibujos iniciales son en su mayoría inútiles e incorrectos en pocos años y tenerlos cerca es en su mayoría perjudicial.

Dicho esto, el uso de herramientas de modelado (no necesariamente UML) no es una práctica totalmente inútil, si los modelos proporcionan una entrada real y relevante al código de ejecución real. Si la descripción del modelo es un artefacto útil del código, debe tratarse como código:

Ya sea utilizándolo como una fuente directa de metadatos para tomar decisiones dinámicas basadas en los conceptos modelados, o utilizando la generación de código para generar artefactos de código estático que se utilizan en el código de trabajo real.

No sé si la pregunta es sobre el mérito de UML, o sobre el mérito de diseñar la arquitectura de los programas.

Sobre UML Por lo general, solo necesita: casos de uso, diagramas de clases y diagramas de secuencia. Simple y fácil, aunque ciertamente podría hacerlo con sus propios tipos de diagramas. En este sentido, UML es un estándar que todos entenderán.

Sobre el diseño de programas.

1. Cada programa tiene un diseño, incluso si no lo planifica. Cuando se escribe el código, simplemente realice ingeniería inversa. Si no lo planeó, apueste a que será un mal diseño.

2. El diseño le ahorrará tiempo al usar patrones conocidos para problemas recurrentes.

3. Si trabaja en equipo, el diseño es necesario para discutir soluciones, transmitir ideas y muy práctico pero necesario para distribuir el trabajo.