¿El código se genera comúnmente a partir de UML? [cerrado]

39

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?

RoboShop
fuente
66
@SK: todos sabemos que SU código es excelente y está escrito de una manera tan clara que incluso un niño de 5 años puede comprender todo el proyecto leyendo solo un par de sus métodos. Sin embargo, para el resto de nosotros que no tenemos su habilidad sobrenatural para escribir código nítido, los diagramas son de gran beneficio al describir cómo funciona el sistema de manera sucinta y los Diagramas UML son una forma estándar de dibujar esos diagramas. No estoy afirmando que sean la mejor manera, solo una forma estándar que funcione en su mayor parte.
Dunk
2
@Dunk, probablemente te hayas perdido ese momento cuando el resto de nosotros inventamos un discurso en lugar de una pintura rupestre. Los diagramas casi siempre no son más que una forma de ocultar lo que se supone que representan. Un texto plano siempre es mejor. Y cuanto más grande es su sistema, más complejo es su comportamiento, mayor es la brecha entre el estilo de comunicación de la pintura de la era de los hombres de las cavernas y un inglés moderno. Nunca vi un diagrama que pudiera entender sin traducirlo manualmente a un texto primero.
SK-logic
9
@ SK-logic - ¿Pensé que una imagen pintaba más que mil palabras?
Michael Arnell
55
@ SK-logic: Entonces, hay algunas cosas mejor comunicadas a través del texto. Y lo creas o no, otros se comunican mejor a través de diagramas, y eso incluye el diseño del sistema, y ​​no solo el diseño OO. E incluso puede ser diferente para diferentes personas y no, su preferencia por la información textual no es una marca de superioridad dada por Dios.
Michael Borgwardt
3
@Sk: aunque su opinión tiene algunos puntos válidos, ya que un diagrama solo casi nunca es suficiente y es necesario agregar algo de texto. Continuaré haciendo uso de lo que crees que son diagramas inútiles mientras sigo construyendo con éxito sistemas bastante grandes con plazos casi imposibles en equipos importantes porque todavía no he visto una mejor manera de comunicarme con otros desarrolladores. Sé que tiene mucho tiempo para sentarse y guiar individualmente a cada desarrollador, pero estoy demasiado ocupado haciendo el trabajo.
Dunk

Respuestas:

64

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.

Péter Török
fuente
55
Exactamente. Pero entonces surge la pregunta de por qué UML con todas sus reglas estrictamente inútiles y, en consecuencia, sus herramientas hinchadas para crear UML, en primer lugar. Los polígonos y elipses simples, conectados por líneas y flechas, hacen un trabajo tan bueno, si no uno mejor, para transmitir la intención como lo hace UML.
Dexter
1
+1 para el bombo publicitario de los 90, el diseño de hardware incluso se movía en la dirección opuesta al mismo tiempo, lejos de la captura esquemática y hacia HDL.
jk.
2
De 1996 a 2002 estuve trabajando para una compañía donde utilizamos con éxito diagramas UML como "mejores" modelos ER. Teníamos nuestros propios generadores de código para generar código C ++ para nuestro marco ORM, SQL / DDL y documentación, todo desde un solo modelo.
Doc Brown
2
Un gran uso del diagrama UML también es el andamiaje. Genere clases, con getters / setters, quizás su árbol de directorios, etc.
Clement Herreman
55
@Dexter: la cuestión es que "los polígonos y elipses simples, conectados por líneas y flechas" dejan mucho abierto a la interpretación. Puede ser que UML intente demasiado tener un símbolo especial para todo, pero ciertamente tiene valor tener una notación estandarizada que le permita distinguir visualmente entre clases y sistemas de hardware, y entre una relación de herencia y un canal de comunicación.
Michael Borgwardt
36

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.

Kevin Cline
fuente
2
+1, gracias por mencionar el problema sobre la complejidad de los problemas de palabras reales. Gran punto
NoChance
¿Qué pasa con G, el lenguaje de programación gráfico utilizado en LabVIEW?
Angelo.Hannes
1
@ Angelo.Hannes: Resolviendo problemas del mundo real en enfoques invariables de vista de laboratorio con
whatsisname
@whatsisname este diagrama está muy abarrotado. Pero he visto muy buenos diagramas estructurados y muy "legibles" en LabVIEW para resolver problemas del mundo real.
Angelo.Hannes
@ Angelo.Hannes: He usado sistemas similares a LabVIEW. Están bien para construir pequeñas aplicaciones en un dominio limitado.
Kevin Cline
9

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.

ZJR
fuente
44
Realmente sentí la necesidad de una respuesta con un gran NO en alguna parte.
ZJR
6

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.

Jan Hudec
fuente
@ Mouviciel: No creo que haya una herramienta que no tenga tales problemas. Rhapsody en realidad trata de mitigar los peores problemas utilizando el código generado, que es texto, como autoridad para los miembros.
Jan Hudec
3

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.

Daniel B
fuente
1

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.

Ninguna posibilidad
fuente
3
Quiero señalar 2 cosas: 1. Te gustan las listas ordenadas.
talnicolas
@talnicolas, tienes razón! Sí :)
NoChance
0

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.

TMN
fuente
0

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.

pinxue
fuente
-1

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.

koya
fuente
-4

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.

Siddhesh Patil
fuente
-5

¡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!

UML_GURU
fuente
1
Esa no es una respuesta hombre, solo una queja. Estoy un poco de acuerdo sobre por qué los codificadores todavía escriben cada código de línea, mientras que es FÁCIL crear pequeños constructores de código con arrastrar y soltar. Tiene toda la razón sobre que Bussiness hizo una mejor implementación de la tecnología que los usuarios que la utilizan. Puede crear una máquina preconfigurada completa con su aplicación en segundos, pero no puede crear software con pocos (miles) clics o pulsaciones de teclas. Extra. Creo que Día y Pythonnect pueden hacer un buen trabajo ejecutando código directamente desde su UML, pero aún no lo probaron.
m3nda