Entonces, cuando estaba en la universidad, me educaron sobre los beneficios de UML y su futuro en el desarrollo de códigos.

Pero según mi experiencia en la industria, descubrí que si bien utilizamos diagramas, que van desde diagramas ER, diagramas de clase, diagramas de estado, a diagramas de flujo de trabajo, todo es para fines de comunicación.

Es decir, nunca he generado código automáticamente a partir de diagramas, y desde el punto de vista de la comunicación, generalmente trato de mantener mis diagramas tan simples y fáciles de entender como sea posible.

Pero cuando miro a Visio y Enterprise Architect, parece que tienen muchos tipos diferentes de gráficos, formas, objetos de propiedades, la mayoría de los cuales no uso.

¿La gente usa UML para hacer cosas más sofisticadas como el código o la generación de bases de datos?

Sí, las herramientas UML CASE fueron uno de los elementos más populares de los años 90 ... y luego no se pudieron entregar.

La razón fundamental de esto es que los diagramas UML (o la mayoría de los otros tipos de) ayudan a comprender el problema y / o el programa que lo resuelve solo en la medida en que el diagrama está abstrayendo los detalles de implementación del código real. Por lo tanto (para cualquier pieza de código no trivial), un diagrama que es fácil de entender es inherentemente inútil para la generación de código , porque carece de los detalles necesarios. Y viceversa, un diagrama que se puede usar directamente para la generación de código no le ayuda mucho a comprender el programa mejor que el código mismo. Si alguna vez has visto un diagrama de clase UML con ingeniería inversa a partir del código de producción, probablemente sabes a qué me refiero.

La única excepción potencial a esto que conozco son los diagramas de entidad-relación, que no abarcan el código per se, solo (como su nombre lo indica) piezas de datos y sus relaciones. Pero nunca he oído hablar de un intento exitoso de usar ningún tipo de diagramas UML para la generación de código real [Actualización] , es decir, más que esqueletos de clase y código trivial como getters / setters, excepto en herramientas / áreas de propósito especial como ORM, como se testificó. por Doc Brown a continuación [/ Actualización] , y creo que esto no es un accidente.

Personalmente, no odio UML, creo que los diagramas UML pueden ser una gran herramienta de comunicación , para mostrar su intención e ideas durante las discusiones de diseño, o para visualizar la arquitectura de su aplicación. Pero es mejor mantenerlos en esto, y no tratar de usarlos para cosas en las que no son buenos.

Entonces, cuando estaba en la universidad (hace un tiempo ahora), me dijeron que UML era el futuro, UML reemplazará la programación y solo generaremos código a partir de diagramas, etc.

Ellos estaban equivocados. Eso sucederá cuando la gente abandone el discurso y vuelva a la pintura rupestre.

Los problemas del mundo real y los programas que los resuelven tienen una complejidad esencial que no se puede reducir. Para producir un programa de trabajo, esa complejidad debe ser capturada y expresada en algún lenguaje ejecutable. La pregunta es si algún lenguaje de programación esquemática podría ser más efectivo que un lenguaje de programación textual. Hemos estado experimentando con la programación esquemática durante unos treinta años, y hasta ahora la evidencia está abrumadoramente a favor de la programación textual. No conozco ninguna aplicación importante producida por la generación de código a partir de diagramas.

NO

La leyenda se basó en la suposición fallida de que escribir:

class ClassName extends SomeThing
{

}

... es difícil y necesita automatización .

Todavía puede encontrar creyentes ocasionales o multitudes de creyentes.
Pero así es como va con las religiones y los cultos.

He estado allí, no lo encontré demasiado útil.

En general, los diagramas lo suficientemente específicos como para generar algún código a partir de ellos, principalmente el diagrama de clases, no agregan mucho en la forma de entender realmente el programa y no se puede generar código a partir de los diagramas generales, como casos de uso o actividades de nivel general que son crucial para la documentación. Un diagrama que es útil para comprender y que puede generar código a partir del gráfico de estado, es útil cuando realmente necesita una máquina de estados. Pero, en general, debe tratar de evitarlos, ya que son inherentemente propensos a errores.

En un proyecto, tuvimos que diseñar el código en el modelador UML (Rhapsody) y generarlo desde allí. Funcionó y probablemente fue un poco más fácil que escribir los encabezados (era C ++) y prototipos a mano. La capacidad de mantener esos dos consistentes automáticamente fue algo útil.

Los cuerpos del método todavía tenían que rellenarse a mano, porque los diagramas realmente no pueden representar eso con la excepción de los esqueletos de máquinas de estado.

Por otro lado, es bastante complejo, por lo que debes aprender muchas cosas adicionales y, lo que es más importante, fue difícil combinarlas. La fusión está bien investigada para archivos de texto y funciona con ellos, pero nadie inventó una manera fácil de combinar cambios en los diagramas todavía. Rhapsody en realidad guarda parte de la información en el código generado y la analiza, por lo que no era totalmente inutilizable, pero aún así era una complicación grave.

Si bien es posible generar código (e incluso sistemas completos) directamente desde los modelos UML, nunca he visto que se use de esta manera.

En mi experiencia, la mayoría de las empresas parecen usarlo como una herramienta de comunicación para requisitos, o "MS Paint para dibujar diagramas".

Una distinción importante que me gustaría hacer es que la mayoría de las herramientas de modelado UML le permiten crear un modelo único de su sistema. Visio, por ejemplo, comprende bastante bien cómo funciona UML, y hay muchas cosas que puede agregar que no están directamente relacionadas con el diagrama. Los diagramas reales son simplemente perspectivas diferentes en partes del modelo, lo que le permite resaltar diferentes aspectos del sistema.

todo (diagramas de modelado) es para fines de comunicación

El modelado tiene 4 usos importantes en el proceso de desarrollo de software:

1. Herramienta de diseño integrado

2. Herramienta de comunicación

3. Una ayuda para la generación de software.

4. Una forma de reducir la complejidad del problema de palabras reales (aprendí esto de la respuesta de @kevin cline anterior)

5. El proceso de modelado hace que algunos diseñadores piensen en detalles no considerados durante la codificación (y viceversa). El modelado en tiempo de diseño le permite considerar una imagen más grande que codificar un método o una clase en un idioma.

En mi opinión, el modelado es vital para construir bases de datos (Diagramas ER), comprender los flujos del proceso (Diagramas de actividad) y comprender las interacciones entre el usuario y el sistema (Diagramas de casos de uso).

¿La gente usa UML para hacer cosas más sofisticadas como el código o la generación de bases de datos?

Si de hecho. Se pueden usar ERD (no un diagrama UML) y Diagramas de clase (dependiendo de las capacidades de su herramienta) para generar:

1 - Lenguaje de definición de datos (DDL)

2 - Procedimientos almacenados para CRUD y diagramas de clase en su idioma preferido (menos útil ya que las herramientas ORM hacen más al respecto)

Entre las características más valiosas de las herramientas de modelado se encuentran:

1 - Capacidad para mantener la integridad del modelo. Si haces un cambio, se propaga en el modelo

2 - Capacidad para responder preguntas donde se usa (¿dónde se usa la 'cuenta' en mi modelo?)

3 - Capacidad para permitir que usuarios concurrentes trabajen en el modelo

4 - Buscar dentro de representaciones gráficas

5 - Control de impresión

6 - Capas (organiza los elementos de tu diagrama en capas) para que puedas concentrarte en una capa a la vez

7 - Generación de código de base de datos para varios sistemas de bases de datos

8 - Validación del modelo (verifica la consistencia, faltan claves, ciclos, etc.)

Entonces, las herramientas de modelado, especialmente las buenas, hacen mucho más que Paint.

Usamos Software Architect para hacer diseños de alto nivel y documentar algunas de las interacciones de componentes más arcanos en nuestras cosas. A veces generamos el esqueleto de la aplicación a partir de los diagramas, pero una vez hecho esto, mantenemos ambos por separado, no intentamos realizar ingeniería inversa del código en un diagrama después de que se completa. Solía ​​usar una herramienta llamada Rational XDE que funcionaba bastante bien para programas pequeños, pero se perdería cuando comenzaste a agregar controladores de eventos Swing o intentaste trabajar con Struts.

Creo que una gran parte de la razón por la cual la gente no escribe en UML es que se necesita mucho más trabajo para especificar completamente todo en UML y luego generar el código a partir de su diagrama. Sé que el Departamento de Defensa de los EE. UU. Está trabajando con el OMG para desarrollar algunas herramientas que generarán código "probado" a partir de diagramas que se han verificado correctamente, pero mi impresión es que terminarás con un orden de magnitud más metadatos que el código real. Lo que probablemente sea bueno (es documentación, después de todo), pero generar metadatos no es más rápido que escribir código, por lo que terminas pasando proporcionalmente más tiempo.

UML en sí mismo es un sistema de notación, por lo que es motivo de comunicación y documentación. Es raro el caso de generar código a partir del modelo UML, pero sí, hay muchachos que lo hacen. Los usuarios de Rhapsody lo hacen con más frecuencia que Rose. La parte difícil es mantener el modelo y el código sincronizados, para la mayoría de los proyectos reales, el costo es demasiado alto.

En mi último proyecto estoy usando UML-Lab (https://www.uml-lab.com). Esta es una buena herramienta que permite que el modelo sea también de ingeniería inversa. La herramienta genera código Java e incluso las anotaciones JPA que son bastante precisas.

El desafío para eso es cuando se trabaja en equipo. El modelo es estático y se encuentra en un solo recurso, lo que hace que sea un poco difícil mantenerlo sincronizado con múltiples cambios de desarrollador. Hay una versión de prueba que está disponible durante 1 mes, que es un buen momento para explorar y comparar con otros si está investigando.

Esta es la primera vez que veo un producto haciendo modelado de objetos y modelado de datos de una sola vez junto con la generación de código también.

De lo contrario, en mis proyectos anteriores, siempre he visto modelos obsoletos que son inexactos o demasiado detallados.

En mis proyectos anteriores, a veces generaba diagramas por ingeniería inversa. La mayoría de las veces encontré que los diagramas están desordenados y preferí dibujarlos filtrando manualmente todo el ruido.

Creo que podemos usar UML para generar código. No es lógica empresarial, ya que la lógica empresarial no es un estándar y varía de una aplicación a otra. Los diagramas de clase junto con los diagramas ER se pueden usar para generar interfaces, clases, entidades de hibernación, métodos básicos de dao, etc. También se puede generar otro código repetitivo como la implementación de fachadas, convertidores de tipos de datos (por ejemplo, entidad para transferir objetos) con ayuda de digramas de objetos. .

Además, como se mencionó en comentarios anteriores, se pueden generar esquemas de bases de datos, scripts DDL, etc., utilizando modelos.

Usando OAW y una herramienta de modelado como Enterprise Architect, podemos escribir generadores de código más fuertes, que incluso pueden ayudar a generar archivos de configuración, código de fábrica usando estereotipos y valores etiquetados.

¡Todavía no entiendo por qué la inteligencia de negocios con herramientas como Business Object es capaz de analizar y aprovechar toda la información de la compañía mientras que a nivel tecnológico seguimos trabajando solo a nivel de código o a nivel abstracto con UML!

El problema no es UML, sino la transformación del modelo entre UML y MOF y la generación de código desde un diagrama clas o xmi usando plantillas. Se dice que UML ofrece una visión abstracta del mundo real, por lo tanto, solo se ve lo que es realmente importante. Habiendo dicho eso, ¿cómo generar un código preciso si el diagrama UML es solo una vista del mundo real? Es imposible y, por lo tanto, el desarrollo dirigido por un modelo que generaría código a partir de un modelo ha fallado.

La solución es transformar para mapear el mundo real y, por lo tanto, todo el código del proyecto en un solo modelo UML. Al tener un solo modelo y la lógica completa del proyecto, puede generar vistas desde el modelo y no desde el código cada vez. Hay una valiente iniciativa hecha por Omondo dentro de la tecnología Java / Jee. El concepto es MOF y UML sincronizados en vivo directamente con el código y ORM. El diagrama UML ahora es solo una vista de alto nivel del modelo que está mapeando todo el proyecto. Puede crear cientos de vistas, agregar cientos de notas, etc. para comprender mejor el proyecto. El código se generará solo si el elemento se cambia o se crea. Maravillosa tecnología en la que el ID de Java se asigna al ID de UML sin el puente de transformación tradicional entre MOF y UML.

Lo que también es fantástico es poder modelar mi dominio a nivel UML y obtener mis anotaciones ORM directamente en el código y, por lo tanto, usando Hibernate puedo crear, borrar, crear mi base de datos, implementar, etc., en una integración continua y permanente en la que UML es parte de toda la arquitectura y no la arquitectura misma del proyecto.

UML nunca me ha decepcionado como visor de alto nivel si se sincroniza en vivo con el código, pero estaba absolutamente devastado por el uso tradicional de MDA con la generación de código de plantillas de desarrollo basadas en modelos. La generación de código de un modelo es como una página HTML que proviene de un documento de Word. ¿Cómo cambiarlo una vez que se genera? ¡Es simplemente imposible actualizar y pasa más tiempo limpiando el código que escribiendo desde cero!