Pregunta

En la universidad he tenido numerosos diseños y UML cursos orientados, y reconozco que UML se puede utilizar para beneficiar un proyecto de software, especialmente caso de uso mapeo, pero ¿es realmente práctico?He realizado 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.

¿Fue útil?

Solución

En un sistema suficientemente complejo hay algunos lugares donde algo de UML se considera útil.

Los diagramas útiles para un sistema varían según su aplicabilidad.Pero los más utilizados son los diagramas de estado, los diagramas de actividad y el diagrama de secuencia.

Hay muchas empresas que confían en ellos y muchas que los rechazan rotundamente por considerarlos una total pérdida de tiempo y esfuerzo.

Es mejor no excederse y pensar qué es lo mejor para el proyecto en el que se encuentra y elegir lo que sea aplicable y tenga sentido.

Otros consejos

Usar UML es como mirar tus pies mientras caminas.Es hacer consciente y explícito algo 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á 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á sintonizada con la tarea.

Sin embargo, no se trata sólo 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é pasa dentro de cinco años cuando todos los que actualmente trabajan en el proyecto se hayan ido?

Es increíblemente útil tener documentación básica actualizada disponible para cualquiera que se una al proyecto más adelante.No recomiendo 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 si se modifica la implementación.

Descubrí que la clave para 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 después de algunas páginas.Por otro lado, a la mayoría de la gente le encantaría tener entre 5 y 10 páginas de diagramas de clases simples con algunas descripciones básicas de cómo se construye el sistema.

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 tus pies mientras caminas.Es hacer consciente y explícito algo 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á 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á sintonizada con la tarea.

La excepción es cuando te encuentras en el bosque por la noche sin una linterna y ha empezado a llover, entonces tienes que mirar tus 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 explícitamente la estructura de su programa.Entonces UML es una de las muchas herramientas que puedes utilizar.Otros incluyen pseudocódigo, diagramas de arquitectura de alto nivel y metáforas extrañas.

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

No estoy de acuerdo, UML se usa en todas partes: en cualquier lugar donde se diseñe un proyecto de TI, UML generalmente estará allí.

Ahora si se está utilizando Bueno es otro asunto.

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

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

Uno de los mayores problemas con UML es la cantidad de trabajo requerido 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 todavía lo hacen bien.

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

La forma en que veo UML y el Proceso racional unificado es que es mas HABLANDO sobre lo que vas a hacer que en realidad HACIENDO lo que vas a hacer.

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

Deseche solo en mi opinión.UML es una gran herramienta para comunicar ideas, el único problema es cuando lo almacenas y lo mantienes porque esencialmente estás creando dos copias de la misma información y aquí es donde generalmente falla.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á obsoleto muy rápidamente o requerirá mucho tiempo (con errores manuales) para mantenerse actualizado.

Co-enseñé un curso de proyecto de desarrollo de nivel superior durante mis dos últimos semestres en la escuela.El proyecto estaba destinado a ser utilizado en un entorno de producción con organizaciones locales sin fines de lucro como clientes de pago.Teníamos que estar seguros de que el código hacía lo que esperábamos y que los estudiantes capturaban 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, teníamos que realizar revisiones de código en cada reunión de clase, pero con 25 estudiantes inscritos, el tiempo de revisión individual era muy corto.Las herramientas que encontramos más valiosas en estas sesiones de revisión fueron los ERD, los diagramas de clases y los diagramas de secuencia.Los diagramas de clase y ERD se realizaron únicamente en Visual Studio, por lo que el tiempo necesario para crearlos fue trivial para los estudiantes.

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

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

Llegué a este tema un poco tarde y solo intentaré aclarar un par de puntos menores.Preguntar si UML es útil es demasiado amplio.La mayoría de la gente pareció responder la pregunta desde la perspectiva del típico/popular UML como herramienta de dibujo/comunicación.Nota:Martin Fowler y otros autores de libros sobre UML creen que es mejor utilizar UML únicamente para la comunicación.Sin embargo, existen muchos otros usos para UML.Por encima de 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 del modelo (perfiles UML)
  • Uso de patrones/activos
  • 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 son áreas problemáticas que necesitan una solución estandarizada.

La discusión debería ampliarse desde cómo UML puede ser superado 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 utilizar UML.Hay situaciones en las que UML para un desarrollador también podría resultar útil, como la aplicación de patrones o la generación de código.

UML ha funcionado para mí durante años.Cuando comencé leí Fowler. UML destilado donde dice "hacer suficiente modelado/arquitectura/etc.".Solo usa lo que tu necesidad!

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, aunque creo que la especificación 2.0 ha hecho que lo que alguna vez fue una especificación clara sea algo inflado y engorroso.Estoy de acuerdo con la edición de los diagramas de tiempo, etc., ya que llenaron un vacío...

Aprender a utilizar UML de forma eficaz requiere un poco de práctica.El punto más importante es comunicar claramente, modelar cuando sea necesario y modelar como 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 Java y C#

  3. MagicDraw - Mi herramienta comercial favorita para Modelar

  4. Poseidon: herramienta decente con 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 garantizar que su código cumpla con los requisitos.

Quizás también quieras leer mi respuesta a la siguiente publicación:

¿Cómo aprender “buen diseño/arquitectura de software”? en https://stackoverflow.com/questions/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.Si se los deja a la deriva río abajo, los errores de diseño pueden agravarse. muy hinchado y feo por cierto.UML, sin embargo, se valida a sí mismo.Con esto quiero decir que al permitirle explorar sus modelos en múltiples dimensiones matemáticamente cerradas y que se verifican mutuamente, genera un diseño robusto.

UML tiene otro aspecto importante:"habla" directamente con nuestra capacidad más fuerte, la de la visualización.Si, por ejemplo, ITIL V3 (bastante simple en el fondo) se hubiera comunicado en forma de diagramas UML, se podría haber publicado en unas pocas docenas de desplegables A3.En cambio, apareció 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 mucha gente que los considere valiosos.

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

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

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

  • Quieres algún tipo de planificación arquitectónica.
  • Quiere asegurarse de que todos los miembros del equipo utilicen realmente la misma tecnología para la planificación de proyectos.

Entonces UML es solo eso:Un estándar sobre cómo planificas tus proyectos.Si contrata gente nueva, 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 excesivo, pero cuando trabajo en un equipo más grande, definitivamente querría algún estándar para planificar software.

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

  • Lluvia de ideas sobre cómo debería funcionar un software.Facilita comunicar lo que estás pensando.
  • Documentar la arquitectura de un sistema, sus patrones y las principales relaciones de sus clases.Ayuda cuando alguien ingresa a tu equipo, cuando te vas y quieres asegurarte de que tu sucesor lo entenderá, y cuando finalmente olvidas para qué diablos estaba destinada esa pequeña clase.
  • Documentar cualquier patrón arquitectónico que utilice en todos sus sistemas, por las mismas razones del punto anterior

solo estoy en desacuerdo con Miguel cuando dice eso Usar UML para un solo desarrollador y/o un proyecto de software simple parece excesivo a él.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 los casos de uso de pescado, cometa y nivel de mar de estilo Cockburn, según lo descrito por Fowler en su libro "UML Destilled". 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 incorporar casos de uso de Cockburn en los espacios de nombres de las construcciones de programación (como los espacios de nombres de clase y de clase interna o haciendo uso de los espacios de nombres para enumeraciones).Creo que esta podría ser una técnica viable y sencilla, pero todavía tengo preguntas y necesito que otros la comprueben.Podría ser bueno para programas simples que necesitan una especie de lenguaje específico de pseudodominio que pueda existir justo en medio del código C# sin ninguna extensión de idioma.

Por favor revisa la publicación si estás interesado.Ir 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 meta-metamodelos.Uno de los puntos fuertes 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, éste falla en su objetivo.

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

Viniendo de estudiante, encuentro que UML tiene muy poca utilidad.Me parece irónico que los PROGAMERS aún tengan que desarrollar un programa que genere automáticamente las cosas que usted ha dicho que son necesarias.Sería extremadamente sencillo diseñar una función en Visual Studio que pudiera extraer fragmentos de datos, buscar definiciones y respuestas de productos suficientes para que cualquiera pudiera verlo, grande o pequeño, 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 sólo un lenguaje, en realidad no es un método.

En cuanto a mí, realmente me molesta la falta de un esquema UML para proyectos de código abierto.Tomemos como ejemplo Wordpress, solo tienes un esquema de base de datos, nada más.Tienes que recorrer la API del códice para intentar tener una visión general.

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, por lo que me resulta difícil escribir especificaciones grandes.Prefiero escribir las entradas y salidas y dejar que los desarrolladores diseñen la parte intermedia.

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 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 circular) no es tan necesario, pero aún así es bueno tenerlo.

Creo que UML es útil simplemente 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 trabaja el equipo de desarrollo.

UML es útil de dos maneras:

  • Aspecto 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 arreglar.La sincronización de diagramas UML con código y análisis obliga a comprender bien las solicitudes del cliente;

  • Lado de gestión:Los diagramas UMl son un espejo de las necesidades del cliente que son inexactas: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 la codificación =>ayudar a tu planificación.

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

si estás en el grupo de linkedin INGENIEROS DE SISTEMAS, ver mi vieja discusión.

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 tal como lo haría sin pruebas unitarias.Dicho esto, debe crear 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 hagas sólo por 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 sólo uno de los métodos de comunicación entre las personas.La pizarra es mejor.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top