¿Es UML práctico? [cerrado]

En la universidad he tenido numerosos cursos de diseño y orientados a UML , y reconozco que UML se puede utilizar para beneficiar un proyecto de software, especialmente el mapeo de casos de uso , pero ¿es realmente práctico? He hecho algunos términos de trabajo cooperativo y parece que UML no se usa mucho en la industria. ¿Vale la pena dedicar tiempo durante un proyecto a crear diagramas UML? Además, encuentro que los diagramas de clases generalmente no son útiles, porque es más rápido mirar el archivo de encabezado de una clase. Específicamente, ¿qué diagramas son los más útiles?

Editar: Mi experiencia se limita a proyectos pequeños de menos de 10 desarrolladores.

Editar: Muchas buenas respuestas, y aunque no es la más detallada, creo que la seleccionada es la más equilibrada.

En un sistema suficientemente complejo hay algunos lugares donde algunos UMLse consideran útiles.

Los diagramas útiles para un sistema varían según la aplicabilidad.
Pero los más utilizados son:

• Diagramas de clases
• Diagramas de estado
• Diagramas de actividad
• Diagramas de secuencia

Hay muchas empresas que juran por ellas y muchas que las rechazan rotundamente como una absoluta pérdida de tiempo y esfuerzo.

Es mejor no exagerar y pensar qué es lo mejor para el proyecto en el que se encuentra y elegir las cosas que sean aplicables y tengan sentido.

Usar UML es como mirar sus pies mientras camina. Es hacer algo consciente y explícito que normalmente puedes hacer de forma inconsciente. Los principiantes deben pensar detenidamente sobre lo que están haciendo, pero un programador profesional ya sabe lo que están haciendo. La mayoría de las veces, escribir el código en sí es más rápido y efectivo que escribir sobre el código, porque su intuición de programación está ajustada a la tarea.

Sin embargo, no se trata solo de lo que estás haciendo. ¿Qué pasa con el nuevo empleado que llega dentro de seis meses y necesita ponerse al día con el código? ¿Qué tal dentro de cinco años, cuando todos los que trabajan actualmente en el proyecto se hayan ido?

Es increíblemente útil tener documentación básica actualizada disponible para cualquier persona que se una al proyecto más adelante. No defiendo diagramas UML completos con nombres de métodos y parámetros (MUY difíciles de mantener), pero sí creo que un diagrama básico de los componentes del sistema con sus relaciones y comportamiento básico es invaluable. A menos que el diseño del sistema cambie drásticamente, esta información no debería cambiar mucho incluso cuando se modifique la implementación.

Descubrí que la clave de la documentación es la moderación. Nadie va a leer 50 páginas de diagramas UML completos con documentación de diseño sin quedarse dormido en unas pocas páginas. Por otro lado, a la mayoría de las personas les encantaría obtener de 5 a 10 páginas de diagramas de clases simples con algunas descripciones básicas de cómo el sistema está armado.

El otro caso en el que he encontrado que UML es útil es cuando un desarrollador senior es responsable de diseñar un componente, pero luego entrega el diseño a un desarrollador junior para que lo implemente.

Usar UML es como mirar sus pies mientras camina. Es hacer algo consciente y explícito que normalmente puedes hacer de forma inconsciente. Los principiantes deben pensar detenidamente sobre lo que están haciendo, pero un programador profesional ya sabe lo que están haciendo. La mayoría de las veces, escribir el código en sí es más rápido y efectivo que escribir sobre el código, porque su intuición de programación está ajustada a la tarea.

La excepción es por qué te encuentras en el bosque por la noche sin una antorcha y ha comenzado a llover; entonces necesitas mirarte los pies para evitar caerte. Hay ocasiones en las que la tarea que ha asumido es más complicada de lo que su intuición puede manejar, y necesita reducir la velocidad y establecer la estructura de su programa de forma explícita. Entonces UML es una de las muchas herramientas que puede utilizar. Otros incluyen pseudocódigo, diagramas de arquitectura de alto nivel y metáforas extrañas.

El flujo de trabajo genérico y los DFD pueden ser muy útiles para procesos complejos. Todos los demás diagramas (ESPECIALMENTE UML) han sido, en mi experiencia, sin excepción una dolorosa pérdida de tiempo y esfuerzo.

Tendría que estar en desacuerdo, UML se usa en todas partes; en cualquier lugar donde se diseñe un proyecto de TI, UML generalmente estará allí.

Ahora bien, si se está utilizando bien es otra cuestión.

Como dijo Stu, encuentro que tanto los casos de uso (junto con las descripciones de los casos de uso) como los diagramas de actividades son los más útiles desde el punto de vista del desarrollador.

El diagrama de clases puede ser muy útil cuando se intenta mostrar relaciones, así como atributos de objeto, como la persistencia. Cuando se trata de agregar un solo atributo o propiedad, generalmente son excesivos, especialmente porque a menudo se vuelven obsoletos rápidamente una vez que se escribe el código.

Uno de los mayores problemas con UML es la cantidad de trabajo que se requiere para mantenerlo actualizado una vez que se genera el código, ya que hay pocas herramientas que puedan rediseñar UML a partir del código y pocas que lo hagan bien.

Calificaré mi respuesta mencionando que no tengo experiencia en entornos de desarrollo corporativo grandes (similares a IBM).

La forma en que veo UML y el Proceso Unificado Racional es que se trata más de HABLAR sobre lo que vas a hacer que de HACER realmente lo que vas a hacer.

(En otras palabras, es en gran medida una pérdida de tiempo)

Tíralo solo en mi opinión. UML es una gran herramienta para comunicar ideas, el único problema es cuando lo almacena y lo mantiene porque básicamente está creando dos copias de la misma información y aquí es donde suena. Después de la ronda inicial de implementación, la mayor parte del UML debe generarse a partir del código fuente; de ​​lo contrario, quedará desactualizado muy rápidamente o requerirá mucho tiempo (con errores manuales) para mantenerse actualizado.

Co-enseñé un curso de proyecto de desarrollo de nivel superior en mis dos últimos semestres en la escuela. El proyecto estaba destinado a ser utilizado en un entorno de producción con organizaciones sin fines de lucro locales como clientes de pago. Teníamos que estar seguros de que el código hiciera lo que esperábamos y de que los estudiantes capturaran todos los datos necesarios para satisfacer las necesidades de los clientes.

El tiempo de clase era limitado, al igual que mi tiempo fuera del aula. Como tal, tuvimos que realizar revisiones de código en cada reunión de la clase, pero con 25 estudiantes inscritos, el tiempo de revisión individual fue muy corto. La herramienta que encontramos más valiosa en estas sesiones de revisión fueron los ERD, los diagramas de clases y los diagramas de secuencia. Los ERD y los diagramas de clases se realizaron solo en Visual Studio, por lo que el tiempo necesario para crearlos fue trivial para los estudiantes.

Los diagramas comunicaron una gran cantidad de información muy rápidamente. Al tener una descripción general rápida de los diseños de los estudiantes, pudimos aislar rápidamente las áreas problemáticas en su código y realizar una revisión más detallada en el acto.

Sin usar diagramas, hubiéramos tenido que tomarnos el tiempo para revisar uno por uno los archivos de código de los estudiantes en busca de problemas.

Llego a este tema un poco tarde y solo intentaré aclarar un par de puntos menores. Preguntar si UML es útil por ser demasiado amplio. La mayoría de la gente pareció responder a la pregunta desde el UML típico / popular como una perspectiva de herramienta de dibujo / comunicación. Nota: Martin Fowler y otros autores de libros sobre UML creen que es mejor usar UML solo para la comunicación. Sin embargo, hay muchos otros usos para UML. Sobre todo, UML es un lenguaje de modelado que tiene notación y diagramas asignados a los conceptos lógicos. A continuación, se muestran algunos usos de UML:

• Comunicación
• Documentación estandarizada de diseño / solución
• Definición de DSL (lenguaje específico de dominio)
• Definición de modelo (perfiles UML)
• Uso de patrón / activo
• Codigo de GENERACION
• Transformaciones de modelo a modelo

Dada la lista de usos anterior, la publicación de Pascal no es suficiente, ya que solo habla de la creación de diagramas. Un proyecto podría beneficiarse de UML si alguno de los anteriores son factores críticos de éxito o áreas problemáticas que necesitan una solución estandarizada.

La discusión debe expandirse desde cómo UML puede ser sobre-eliminado o aplicado a proyectos pequeños para discutir cuándo UML tiene sentido o realmente mejorará el producto / solución, ya que es entonces cuando se debe usar UML. Hay situaciones en las que UML para un desarrollador también podría detectar, como Aplicación de patrones o Generación de código.

UML me ha funcionado durante años. Cuando comencé, leí UML Distilled de Fowler, donde dice "hacer suficiente modelado / arquitectura / etc.". ¡Solo usa lo que necesites !

Desde la perspectiva de un ingeniero de control de calidad, los diagramas UML señalan posibles fallas en la lógica y el pensamiento. Hace mi trabajo más fácil :)

Creo que UML es útil, pero creo que la especificación 2.0 ha hecho que lo que una vez fue una especificación clara sea algo hinchado y engorroso. Estoy de acuerdo con la edición de diagramas de tiempo, etc., ya que llenaron un vacío ...

Aprender a usar UML de manera efectiva requiere un poco de práctica. El punto más importante es comunicarse claramente, modelar cuando sea necesario y modelar en equipo. Las pizarras son la mejor herramienta que he encontrado. No he visto ningún "software de pizarra digital" que haya logrado capturar la utilidad de una pizarra real.

Dicho esto, me gustan las siguientes herramientas UML:

1. Violeta - Si fuera más simple sería un trozo de papel

2. Altova UModel: buena herramienta para modelado en Java y C #

3. MagicDraw: mi herramienta comercial favorita para modelar

4. Poseidón: herramienta decente con una buena relación calidad-precio

5. StarUML: la mejor herramienta de modelado de código abierto

Los diagramas UML son útiles para capturar y comunicar requisitos y garantizar que el sistema cumpla con esos requisitos. Se pueden utilizar de forma iterativa y durante varias etapas de planificación, diseño, desarrollo y prueba.

Del tema: Uso de modelos dentro del proceso de desarrollo en http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Un modelo puede ayudarlo a visualizar el mundo en el que funciona su sistema, aclarar las necesidades de los usuarios, definir la arquitectura de su sistema, analizar el código y asegurarse de que su código cumpla con los requisitos.

También es posible que desee leer mi respuesta a la siguiente publicación:

¿Cómo aprender “buen diseño / arquitectura de software”? en /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Aunque esta discusión ha estado inactiva durante mucho tiempo, tengo un par de puntos -en mi opinión importantes- que agregar.

El código con errores es una cosa. Dejados a la deriva corriente abajo, los errores de diseño pueden volverse muy inflados y feos. UML, sin embargo, se autovalida. Con eso quiero decir que al permitirle explorar sus modelos en múltiples dimensiones, matemáticamente cerradas y de verificación mutua, genera un diseño robusto.

UML tiene otro aspecto importante: "habla" directamente con nuestra capacidad más fuerte, la de visualización. Si, por ejemplo, ITIL V3 (en el fondo bastante simple) se hubiera comunicado en forma de diagramas UML, podría haberse publicado en unas pocas docenas de folletos A3. En cambio, salió en varios tomos de proporciones verdaderamente bíblicas, generando toda una industria, costos impresionantes y un shock catatónico generalizado.

Veo diagramas de secuencia y diagramas de actividad que se utilizan con bastante frecuencia. Trabajo mucho con sistemas integrados y en "tiempo real" que interactúan con otros sistemas, y los diagramas de secuencia son muy útiles para visualizar todas las interacciones.

Me gusta hacer diagramas de casos de uso, pero no he conocido a demasiadas personas que piensen que son valiosas.

A menudo me he preguntado si Rational Rose es un buen ejemplo de los tipos de aplicaciones que se obtienen del diseño basado en modelos UML. Está hinchado, con errores, lento, feo, ...

Encontré que UML no es realmente útil para proyectos muy pequeños, pero es realmente adecuado para proyectos más grandes.

Básicamente, no importa lo que uses, solo debes tener en cuenta dos cosas:

• Quieres algún tipo de planificación arquitectónica
• Desea asegurarse de que todos los miembros del equipo estén utilizando la misma tecnología para la planificación del proyecto.

Entonces, UML es solo eso: un estándar sobre cómo planifica sus proyectos. Si contrata a nuevas personas, es más probable que conozca cualquier estándar existente, ya sea UML, Flowchard, Nassi-Schneiderman, lo que sea, en lugar de su material interno existente.

Usar UML para un solo desarrollador y / o un proyecto de software simple me parece una exageración, pero cuando trabajo en un equipo más grande, definitivamente querría algún estándar para el software de planificación.

UML es útil, ¡sí! Los principales usos que le he dado fueron:

• Lluvia de ideas sobre cómo debería funcionar una pieza de software. Facilita la comunicación de lo que está pensando.
• Documentar la arquitectura de un sistema, sus patrones y las principales relaciones de sus clases. Ayuda cuando alguien ingresa a su equipo, cuando usted se va y quiere asegurarse de que su sucesor lo entienda, y cuando finalmente se olvida para qué demonios estaba destinada esa pequeña clase.
• Documentar cualquier patrón arquitectónico que use en todos sus sistemas, por las mismas razones del punto anterior

Solo estoy en desacuerdo con Michael cuando dice que usar UML para un solo desarrollador y / o un proyecto de software simple le parece excesivo . Lo he usado en mis pequeños proyectos personales, y tenerlos documentados usando UML me ahorró mucho tiempo cuando volví a ellos siete meses después y había olvidado por completo cómo había construido y armado todas esas clases.

Creo que puede haber una manera de utilizar casos de uso de peces, cometas y nivel del mar UML estilo Cockburn, como lo describe Fowler en su libro "UML Distilled". Mi idea era emplear casos de uso de Cockburn como ayuda para la legibilidad del código.

Así que hice un experimento y hay una publicación aquí al respecto con la etiqueta "UML" o "FOWLER". Fue una idea simple para c #. Encuentre una manera de incrustar casos de uso de Cockburn en los espacios de nombres de las construcciones de programación (como los espacios de nombres de clases y de clases internas o haciendo uso de los espacios de nombres para enumeraciones). Creo que esta podría ser una técnica viable y simple, pero todavía tengo preguntas y necesito que otros la revisen. Podría ser bueno para programas simples que necesitan un tipo de lenguaje específico de pseudo-dominio que puede existir justo en medio del código c # sin extensiones de lenguaje.

Por favor, consulte la publicación si está interesado. Vaya aquí .

Uno de los problemas que tengo con UML es la comprensibilidad de la especificación. Cuando trato de comprender realmente la semántica de un diagrama en particular, rápidamente me pierdo en el laberinto de metamodelos y metamodelos. Uno de los puntos de venta de UML es que es menos ambiguo que el lenguaje natural. Sin embargo, si dos o más ingenieros interpretan un diagrama de manera diferente, falla en la meta.

Además, he intentado hacer preguntas específicas sobre el documento de superestructura en varios foros de UML y a los miembros del propio OMG, con pocos o ningún resultado. No creo que la comunidad UML sea lo suficientemente madura como para sostenerse a sí misma.

Viniendo de un estudiante, encuentro que UML tiene muy poco uso. Me parece irónico que los PROGAMERS todavía tengan que desarrollar un programa que genere automáticamente las cosas que usted ha dicho que son necesarias. Sería extremadamente simple diseñar una función en Visual Studio que pudiera extraer partes de los datos, buscar definiciones y respuestas de productos suficientes para que cualquiera pudiera verla, grande o pequeña, y comprender el programa. Esto también lo mantendría actualizado porque tomaría la información directamente del código para producir la información.

UML se usa tan pronto como representas una clase con sus campos y métodos, aunque es solo una especie de diagrama UML.

El problema con UML es que el libro de los fundadores es demasiado vago.

UML es solo un lenguaje, no es realmente un método.

En cuanto a mí, realmente me molesta la falta de esquema UML para proyectos de código abierto. Tome algo como Wordpress, solo tiene un esquema de base de datos, nada más. Tienes que deambular por la API del Codex para tratar de obtener una imagen completa.

UML tiene su lugar. Se vuelve cada vez más importante a medida que crece el tamaño del proyecto. Si tiene un proyecto de larga duración, lo mejor es documentar todo en UML.

UML parece bueno para proyectos grandes con grandes equipos de personas. Sin embargo, he trabajado en equipos pequeños donde la comunicación es mejor.

Sin embargo, usar diagramas tipo UML es bueno, especialmente en la etapa de planificación. Tiendo a pensar en código, así que me resulta difícil escribir especificaciones grandes. Prefiero escribir las entradas y salidas y dejar que los desarrolladores diseñen el bit en el medio.

Creo que UML es útil solo por el hecho de que hace que la gente piense en las relaciones entre sus clases. Es un buen punto de partida para empezar a pensar en este tipo de relaciones, pero definitivamente no es una solución para todos.

Mi creencia es que el uso de UML es subjetivo a la situación en la que está trabajando el equipo de desarrollo.

En mi experiencia:

La capacidad de crear y comunicar diagramas de código significativos es una habilidad necesaria para cualquier ingeniero de software que esté desarrollando un código nuevo o intentando comprender el código existente.

Conocer los detalles de UML (cuándo usar una línea discontinua o un punto final de círculo) no es tan necesario, pero es bueno tenerlo.

UML es útil de dos formas:

• Lado técnico: mucha gente (gerente y algún analista funcional) piensa que UML es una característica de lujo porque el código es la documentación: comienzas a codificar, después de depurar y corregir . La sincronización de los diagramas UML con el código y los análisis te obligan a comprender bien las solicitudes del cliente;

• Lado de administración: los diagramas UMl son un espejo de los requisitos del cliente que es inexacto: si codifica sin UML, tal vez pueda encontrar un error en los requisitos después de muchas horas de trabajo. Los diagramas UML te permiten encontrar los posibles puntos controvertidos y resolverlos antes de que la codificación => ayude a tu planificación.

Generalmente, todos los proyectos sin diagramas UML tienen un análisis superficial o tienen un tamaño reducido.

si estás en el grupo de LinkedIn SYSTEMS ENGINEERS , mira mi discusión anterior .

Al final, UML solo existe gracias a RUP. ¿Necesitamos UML o cualquiera de sus elementos relacionados para usar Java / .Net? La respuesta práctica es que tienen su propia documentación (javadoc, etc.) que es suficiente y nos permite hacer nuestro trabajo.

UML no gracias.

UML es definitivamente útil al igual que junit es esencial. Todo depende de cómo vendas la idea. Su programa funcionará sin UML del mismo modo que funcionaría sin pruebas unitarias. Dicho esto, debe crear do UML ya que está conectado a su código, es decir, cuando actualiza los diagramas UML, actualiza su código, o cuando actualiza su código, genera automáticamente el UML. No lo haga por el simple hecho de hacerlo.

UML definitivamente tiene su lugar en la industria. Imagine que está creando software para aviones Boing o algún otro sistema complejo. UML y RUP serían de gran ayuda aquí.

UML es solo uno de los métodos de comunicación entre las personas. La pizarra es mejor.