tag printable name maker design documentation code-generation uml

design - printable - name tag maker



¿Todavía usas UML? ¿Cómo? ¿Para qué? (19)

Creo que el UML tradicional está muerto. Me refiero a UML estático que pasa algunos meses de modelado de requisitos y generación de código de un modelo. No podemos esperar más de una semana antes de comenzar a codificar porque tenemos que entregar nuestro proyecto cada vez más rápido. Si modela y luego genera un código, el código generado suele ser tan malo que debe arreglarlo. Pasé más tiempo reparando código UML sucio hace algunos años que escribiendo un nuevo código limpio.

Creo que el MDD (por ejemplo, el desarrollo impulsado por el modelo) está muerto, pero no la notación gráfica UML. Todavía lo uso todos los días y funciona muy bien. Cuando obtengo nuevos requisitos, los muestro inmediatamente en un diagrama de clases. Primero reverso mi proyecto existente, luego creo nuevos elementos y lo fusiono con el código existente. No es más de 2 horas para crear el esqueleto de mi requerimiento en mi proyecto existente. Me gusta crear mi esqueleto con un diagrama de clases porque te da un mayor nivel de abstracción y código. Realmente genial. Uso Omondo EclipseUML y estoy hecho para esta herramienta, lo siento por los otros proveedores, pero esta herramienta ha cambiado mi vida. Combino mi proyecto con equipos offshore dos veces al día y recrear nuevos diagramas. Esto no es automático porque prefiero verificar el código antes de aceptar la confirmación. Compruebo la compilación y también el enfoque de objetos y solo UML puede darme una idea de lo que se ha hecho, cómo y dónde se ha agregado el pegamento para cumplir con los nuevos requisitos. Estoy contento porque no uso la generación de código MDD sucio, pero puedo centrarme en la notación UML y el código de calidad.

Hace unos años, todos en nuestra tienda estaban locos con UML . Ahora todo el mundo parece haberse calmado.

Tengo curiosidad de si todavía hay un uso generalizado de UML en proyectos de software.

Si es así, ¿este uso está limitado a la pizarra? ¿Lo usas para la documentación? ¿Utiliza herramientas para generar código a partir de ella?

Relacionado:

¿UML es práctico?

De hecho, uso UML para ayudarme a visualizar y pensar en los problemas. Para este propósito, diagramas de secuencia, diagramas de actividad y diagramas de objetos son muy útiles.

Los diagramas de componentes son buenos cuando intenta comunicar las capas de software.

Los diagramas de implementación son muy útiles para determinar el empaque y la implementación, así como las rutas de comunicación entre nodos.

Los diagramas de clase resultan menos útiles, ya que la mayoría de los IDE pueden proporcionarle la jerarquía de clases construida con bastante facilidad.

Decidí que me gusta el estilo de uso de Cockburn tal como lo describe Fowler en su libro titulado "UML Distilled". Me gustan lo suficiente como para haber ideado una forma experimental de insertarlos directamente en los espacios de nombres de C #.

Al hacer esto, podría codificar la lógica de negocios o UI en términos del contenido en inglés de los casos de uso de forma gratuita sin tener que escribir ningún tipo de lenguaje específico de dominio. El beneficio más inmediato fue que mejoré la legibilidad del código (albiet de una forma muy nueva y esotérica). Todavía es un enfoque experimental. Sin embargo, creo que podría ser útil.

Here está el enlace a una pregunta que publiqué mientras trataba de encontrar otras formas de hacer lo que hice.

Depende de la audiencia y el propósito de lo que está dibujando (suponiendo que está utilizando UML como un lenguaje de modelado visual en lugar de su forma menos abstracta más común).

Si está comunicando la secuencia de control, o la jerarquía de clases, con otros ingenieros, los diagramas UML son ideales.

Al comunicar la arquitectura de macro aplicaciones a clientes o gerentes de tecnología sénior, es probable que encuentre que el powerpoint, por mucho que tenga que aguantarse la nariz, es más efectivo.

Consulte Documentación de arquitecturas de software para obtener un buen resumen de las debilidades en UML para algunos diagramas comúnmente requeridos de vistas arquitectónicas.

Otro consejo: utilice una herramienta textual como el excelente PlantUml . Hay una DSL muy simple para aprender, y luego puede concentrarse en el significado en lugar de obligar a Visio a dibujar líneas rectas o utilizar una herramienta CASE desarrollada al máximo. Verifique en los modelos PlantUml el control de origen y configure un trabajo de CI para construir y publicar automáticamente SVG o PNG.

Encuentro ULM inútil para mí, perjudica mi creatividad. Genero UML solo como un documento, si el cliente lo quiere. Pero no lo uso para modelar clases. La arquitectura es un proceso en evolución, donde pienso una y otra vez y obtengo nuevas ideas donde sea que esté, no solo en la oficina. Estoy constantemente refactorizando para acercarme a lo óptimo, primero en mente y luego en el código. Espero que entiendas lo que quiero decir.

He visto UML generado usado para ayudar a los empleados nuevos a manejar lo que era un sistema complejo y muy complicado. Como el UML se generó automáticamente a partir del código, siempre estuvo actualizado y algunas personas lo encontraron útil.

Juntos / J es un buen punto de referencia porque NO hay ningún esfuerzo para producir el UML, simplemente está allí junto con su código de Java. Es interesante ver si utilicé el UML cuando estaba allí para "gratis".

¿Me pareció útil tenerlo allí? Para ser sincero, me pareció útil como una confirmación visual adicional y verificación cruzada de que el diseño que hice estaba tomando forma y como una herramienta de catalogación visual. No pensé en una lógica específica o esquemas basados ​​en los diagramas. Bueno, tal vez a veces lo hice.

¿Valió la pena el dinero? Me hizo sentir bien sobre el proceso. Se veía impresionante para otros. Pasó unos momentos pensando en el inventario de cosas que estaba pasando. Me hizo pensar más sobre la pulcritud y la simplicidad en general, con cada objeto que ocupa la pantalla de bienes raíces. Me hizo preguntar ¿realmente necesito ese atributo o puedo hacerlo más ordenado? Ocasionalmente me ayudó a "pensar en UML".

Con experiencia adicional, ¿usaría ahora Together / J? ¿Debo pasar tiempo construyendo UML desde cero?

Bien, cuando miro lo que realmente hago para un proyecto, consiste en escribir diseños de IU, esquemas de bases de datos y protocolos de comunicación, considerando casos de uso y uso de memoria, uso de ancho de banda y seguridad. De hecho, casi todo es posible considerar, excepto la orientación a objetos / UML. Y no uso Together / J.

¿Por qué es esto?

Es porque ahora he internalizado mis aprendizajes de UML. Ahora me enfoco en lograr eficiencias de velocidad, espacio y tiempo en los diseños. Mis diseños están muy restringidos por los principios de UML, por lo que valió la pena aprender todo eso, pero no uso diagramas de UML reales en papel ni pienso en UML.

UML es solo asumido; un dado. O más bien su influencia en el diseño es.

Lo que ahora tengo en la pantalla es código y datos puros. También tengo una sensación de logro. :-)

Lo uso para diagramas de casos de uso. no mucho más sin embargo.

Prefiero la adopción ágil de UML (por ejemplo, los bocetos de la pizarra) sobre la adaptación de cascada de UML (por ejemplo, documentos excesivos de diagramas elaborados dibujados en Visio).

UML sigue siendo útil para explicar un diseño a otra persona. Por ejemplo, el patrón de diseño compuesto es fácil de explicar con diagramas de clase simples (es decir, una vez que haya terminado con esas analogías interesantes).

Unos pocos diagramas de clases y secuencias dibujados a mano son útiles para iniciarse rápidamente cuando se enfrentan a un proyecto nuevo o antiguo con clases esparcidas por todos lados y sin documentación suficiente.

Mi equipo también está utilizando con éxito diagramas de clases para generar esquemas de bases de datos. Tal vez hay mejores formas, pero esa es otra pregunta.

Si usa Agile, debería usar UML.

El modelado es importante. Por supuesto, es más divertido obtener un código de escritura, sin embargo, desperdicia un poco de tiempo y no tiene idea de si cumple con los requisitos del cliente. Usted modelo para comprender el problema que le piden que solucione, y acelerar el tiempo de desarrollo, y enviar un producto útil a sus clientes.

Ahorre oro en los preciosos cables Monster.

Siempre utilicé gráficos UML (o UML ispired) como documentación de respaldo. Los documentos proporcionan un segmento en el tiempo, como "este fue nuestro concepto original de usuario". Mantener los documentos actualizados es difícil y solo se haría si necesitamos cambiar nuestra definición. Luego tenemos otra instantánea a tiempo. UML no era el diseño, sino parte del proceso de diseño.

He usado algunas herramientas de generación de código que usan UML pero solo para generar stubs iniciales. Por lo general, una vez que se generó el código, evolucionó por separado del diagrama.

Un problema con UML fue que en muchos casos surgieron argumentos sobre la sintaxis / estilo UML adecuado en lugar de concentrarse en si el dibujo ayudó al cliente, analista o desarrollador a entender el concepto. Sé que la sintaxis es importante cuando se genera código, pero encontré que UML se usa mejor para entender un concepto.

Todavía usamos UML. Al igual que otros aquí, me parece que ayudan enormemente en la comunicación. Es mucho más fácil para las personas comunicarse cuando tienen ayudas visuales (ingrese la popularidad de PowerPoint). Esto es especialmente cierto en las fases iniciales de un proyecto donde los escenarios como firebird84 explican suceden mucho. El lado laborioso de UML es el mantenimiento de los diagramas una vez que los desarrolladores en el proyecto comienzan a codificar.

Sin embargo, no generamos código de ellos y todavía no he hablado personalmente con alguien que haya usado UML en esa medida.

Usamos diagramas de clase UML solo para algunos rasguños, principalmente al comienzo de los proyectos, pero también cuando explicamos nuestro propio código a otros desarrolladores. Pero esto solo es una amenaza, no para documentar nuestro software.

En mi opinión, se habla mucho de UML (por personas, revistas), pero no tanta gente realmente lo usa.

Uso UML en discusiones con otros desarrolladores. A menudo pienso para mis adentros que soy más exitoso en la transmisión de información a otras personas a través de imágenes, así que dibujaré un diagrama de clases o un diagrama de actividades en una pizarra cuando haga una lluvia de ideas con el resto del equipo. Otros miembros pueden dibujar y modificarlo, y una vez que todos sabemos de lo que estamos hablando, tendemos a rodar con él. No nos molestamos en generar código directamente de él (en parte porque nuestras herramientas eran horribles) pero, por otro lado, podríamos habernos sentido más restringidos si lo hiciéramos. Esos diseños han cambiado MUCHO desde el whiteboard ...

Uso UML para diseños iniciales y como ayuda para la discusión cuando hablo con otros desarrolladores. Pero, más allá del diseño inicial, el tiempo dedicado a tratar de mantener UML actualizado no vale la pena el esfuerzo.

Utilizo diagramas de clases diariamente para analizar el modelo, tanto objetos como esquemas. Esto realmente arroja los DBAs, hasta que usted señala que puede derivar un ERD de un diagrama de clases deslizando todas las flechas hacia el otro extremo de las líneas ... Las flechas siguen apuntando en la misma dirección. Ahí, ahora representa un FK.

Hay muchos detalles estructurales y semánticos que difieren entre los dos tipos de diagramas, pero la conversión de la flecha parece borrar el bloqueo mental.

Ver SO: ¿Es UML práctico? para algunas respuestas más sobre el tema. Parece ser que UML aún es útil para comunicar conceptos y sistemas. La gente parece usarlo como una descripción, en lugar de una definición. Si separa UML de la implementación en sí, se encontrará con problemas para mantener los dos sincronizados.

Yo uso UML para los diseños iniciales también. Después de hacer la fase de los requisitos y los casos de uso (tanto en UML como en forma textual), el sistema básico se presenta como un diagrama de componentes para identificar componentes individuales, las interfaces y los subsistemas.