simbologia - ¿Es UML práctico?

uml pdf libro

Question

En la universidad he tenido numerosos cursos orientados al diseño y UML , y reconozco que UML se puede utilizar para beneficiar un proyecto de software, especialmente el mapeo de use-case , 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 el tiempo durante un proyecto para crear diagramas UML? Además, encuentro que los diagramas de clase 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 son las más detalladas, creo que la seleccionada es la más equilibrada.

Answer 1

Usar UML es como mirar tus pies mientras caminas. Está haciendo algo consciente y explícito que normalmente puedes hacer inconscientemente. Los principiantes deben pensar cuidadosamente 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á sintonizada con la tarea.

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

Es increíblemente útil tener alguna documentación básica actualizada disponible para cualquiera que se una al proyecto más adelante. No defiendo los diagramas UML completos con nombres de métodos y parámetros (MANERA demasiado difícil de mantener), pero creo que un diagrama básico de los componentes en el 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 aun cuando la implementación sea ajustada.

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 unas pocas páginas. Por otro lado, a la mayoría de la gente le encantaría obtener 5-10 páginas de diagramas simples de clase con algunas descripciones básicas de cómo el el sistema se arma.

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

Answer 2

Al final, UML solo existe debido 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.

Answer 3

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

El código de Buggy es una cosa. Dejados para derivar aguas abajo, los errores de diseño pueden ser muy hinchados y feos. UML, sin embargo, es autovalidante. Con eso me refiero a que al permitirle explorar sus modelos en múltiples dimensiones, cerradas matemáticamente y de control mutuo, engendra un diseño robusto.

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

Answer 4

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

Answer 5

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 Racional Unificado es que es más HABLAR sobre lo que vas a hacer que REALMENTE HACER lo que vas a hacer.

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

Answer 6

Creo que UML es útil solo por el hecho de que hace que las personas piensen en las relaciones entre sus clases. Es un buen punto de partida para comenzar a pensar en tales 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.

Answer 7

Creo que el UML es útil. Creo que la especificación 2.0 ha convertido lo que antes era una especificación clara algo engorrosa e incómoda. Estoy de acuerdo con la edición de los diagramas de tiempos, etc. ya que llenaron un vacío ...

Aprender a usar el UML efectivamente requiere un poco de práctica. El punto más importante es comunicarse claramente, modelar cuando sea necesario y modelar como un equipo. Pizarras blancas 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 pedazo de papel

2. Altova UModel - Buena herramienta para modelado Java y C #

3. MagicDraw - Mi herramienta comercial favorita para Modelado

4. Poseidón: herramienta decente con buena inversión para el dinero

5. StarUML - La mejor herramienta de modelado de código abierto

Answer 8

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

Así que hice un experimento y hay una publicación aquí con la etiqueta "UML" o "FOWLER". Fue una idea simple para c #. Encuentre una forma de incrustar casos de uso de Cockburn en los espacios de nombres de las construcciones de programación (como los espacios de nombres de clase y clase interna o haciendo uso del espacio de nombres para las enumeraciones). Creo que esta podría ser una técnica viable y simple, pero que aún tiene preguntas y necesita otras personas para comprobarlo. Podría ser bueno para programas simples que necesitan un tipo de lenguaje específico de pseudo dominio que puede existir en el medio del código c sin extensiones de idioma.

Por favor revisa la publicación si estás interesado. Ve here

Answer 9

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

Answer 10

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

Answer 11

En mi experiencia:

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

Conocer los detalles de UML - cuándo usar una línea punteada, o un punto final circular - no es tan necesario, pero aún así es bueno tenerlo.

Answer 12

En un sistema suficientemente complejo, hay algunos lugares donde algunos UML se consideran útiles.

Los diagramas útiles para un sistema varían según la aplicabilidad. Pero los más utilizados son los Diagramas de Estado, Diagramas de Actividad y Diagrama de Secuencia.

Hay muchas empresas que los juran y muchos que los rechazan rotundamente como una pérdida total de tiempo y esfuerzo.

Es mejor no excederse y pensar qué es lo mejor para el proyecto en el que se encuentra y elegir las cosas que son aplicables y tienen sentido.

Answer 13

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

Esencialmente, no importa lo que uses, solo debes tener en cuenta dos cosas:

• ¿Quieres algún tipo de planificación de la arquitectura
• Desea asegurarse de que todos en el equipo estén usando la misma tecnología para la planificación de proyectos

Entonces, UML es solo eso: un estándar sobre cómo planificar sus proyectos. Si contratas nuevas personas, es más probable que conozcas cualquier estándar existente, ya sea UML, Flowchard, Nassi-Schneiderman, lo que sea, en lugar de lo que existes en tu propio equipo.

Usar UML para un desarrollador único y / o un proyecto de software simple me parece exagerado, pero cuando trabajo en un equipo más grande, definitivamente quiero un estándar para el software de planificación.

Answer 14

Estoy llegando a este tema un poco tarde y trataré de aclarar un par de puntos menores. Preguntar si UML es útil porque es demasiado amplio. La mayoría de las personas parecía responder la pregunta del UML típico / popular como una perspectiva de herramienta de dibujo / comunicación. Nota: Martin Fowler y otros autores de libros de UML creen que UML se usa mejor solo para la comunicación. Sin embargo, hay muchos otros usos para UML. Sobre todo, UML es un lenguaje de modelado que tiene anotación y diagramas mapeados a los conceptos lógicos. Aquí hay algunos usos para UML:

• Comunicación
• Diseño estandarizado / documentación de solución
• DSL (lenguaje específico del dominio) Definición
• Definición del modelo (Perfiles UML)
• Patrón / uso de 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 si son áreas problemáticas que necesitan una solución estandarizada.

La discusión debería ampliarse desde cómo UML puede sobreestimarse o aplicarse a proyectos pequeños para discutir cuándo UML tiene sentido o si realmente mejorará el producto / solución, ya que es cuando se debe usar UML. Hay situaciones en las que UML para un desarrollador también podría detectar, como Pattern Application o Code Generation.

Answer 15

Los diagramas UML son útiles para capturar y comunicar los requisitos y garantizar que el sistema cumpla con esos requisitos. Se pueden usar 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 su sistema funciona, 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.

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

¿Cómo aprender "buen diseño / arquitectura de software"? en https://.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Answer 16

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

Ahora bien, si se está usando bien es otro asunto.

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

El diagrama de clases puede ser muy útil cuando se trata de mostrar las relaciones, así como los atributos del objeto, como la persistencia. Cuando se trata de agregar un solo atributo o propiedad, generalmente son excesivos, especialmente porque a menudo se vuelven obsoletos 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 pueden rediseñar UML del código, y aún hay pocas que lo hacen bien.

Answer 17

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

Answer 18

UML es útil de dos maneras:

• Lado técnico: mucha gente (gerente y algunos analistas funcionales) piensan 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 diagramas UML con código y análisis te obliga a comprender bien las solicitudes del cliente;

• Lado de la administración: los diagramas de UMl son un espejo de las necesidades del cliente que es impreciso: si codifica sin UML, tal vez pueda encontrar un error en la solicitud después de muchas horas de trabajo. Los diagramas UML le permiten encontrar los puntos polémicos posibles y resolver antes de que la codificación ayude a su planificación.

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

si está en el grupo de linkedin INGENIEROS DE SISTEMAS , consulte mi discusión anterior .

Answer 19

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

• Lluvia de ideas sobre las formas en que debería funcionar un software. Hace fácil comunicar lo que estás pensando.
• Documentando la arquitectura de un sistema, sus patrones y las principales relaciones de sus clases. Ayuda cuando alguien ingresa a su equipo, cuando se va y quiere asegurarse de que su sucesor lo comprenda, y cuando finalmente se olvide para qué demonios estaba destinada esa pequeña clase.
• Documentando 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 desarrollador único y / o un proyecto de software simple le parece excesivo . Lo he usado en mis pequeños proyectos personales, y haberlos documentado 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 reunido todas esas clases.

Answer 20

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. Una vez dicho esto, debes crear do UML a medida que esté conectado a tu código, es decir, cuando actualices los diagramas UML, actualizará tu código, o cuando actualices tu código, generará automáticamente el UML. No hagas solo por el bien de hacerlo.

Answer 21

UML es solo uno de los métodos de comunicación dentro de las personas. Pizarra es mejor.

Answer 22

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

Answer 23

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

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

Answer 24

UML se usa tan pronto como se representa una clase con sus campos y métodos, aunque es solo un tipo 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 fuente abierta. Toma algo como Wordpress, solo tienes un esquema de base de datos, nada más. Tienes que deambular por la aplicación del Codex para tratar de obtener una visión general.

Answer 25

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 ejecución, entonces es mejor documentar todo en UML.

Answer 26

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 metametamodelos. 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 para los miembros de la propia OMG, con pocos o ningún resultado. No creo que la comunidad UML sea lo suficientemente madura como para mantenerse.

Answer 27

Usar UML es como mirar tus pies mientras caminas. Está haciendo algo consciente y explícito que normalmente puedes hacer inconscientemente. Los principiantes deben pensar cuidadosamente 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á sintonizada con la tarea.

La excepción es por qué te encuentras en el bosque por la noche sin una linterna y ha empezado a llover, entonces necesitas mirar tus pies para evitar caer. Hay momentos en los 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 explícitamente. Entonces UML es una de las muchas herramientas que puedes usar. Otros incluyen pseudocódigo, diagramas de arquitectura de alto nivel y metáforas extrañas.

Answer 28

Veo diagramas de secuencia y diagramas de actividad usados ​​con bastante frecuencia. Trabajo mucho con sistemas "en tiempo real" e integrados 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 piense que son valiosos.

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

Answer 29

Viniendo de un estudiante, me parece que UML tiene muy poco uso. Me parece irónico que los PROGAMERS aún no hayan desarrollado 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 fragmentos de los datos, buscar definiciones y respuestas de productos suficientes para que cualquiera pudiera verlos, grandes o pequeños, 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.

Answer 30

Yo co-enseñé un curso de proyecto de desarrollo de alto nivel mis últimos dos 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 asegurarnos de que el código hiciera lo que esperábamos y que los estudiantes estuvieran capturando todos los datos necesarios para satisfacer las necesidades de los clientes.

El tiempo de clase era limitado, como lo era 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 diagramas de ERD y de clase se realizaron solo en Visual Studio, por lo que el tiempo requerido para crearlos fue trivial para los estudiantes.

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

Sin usar diagramas, habríamos tenido que tomarnos el tiempo para ir uno por uno a través de los archivos de códigos de los alumnos en busca de problemas.