¿Debería crear diagramas de clase antes o después de la implementación?

A mi modo de ver, si creas uno antes de obtener la ventaja de:

• Planificar el futuro
• Resumen del proyecto

pero pierdes:

• Tiempo (haciendo un trabajo, probablemente terminarás repitiendo al escribir código)

Por otro lado, podría crearlos todos después de escribir mi código solo para mantenerlo como referencia para futuros desarrolladores.

¿Cuál sirve para los diagramas de clase y cuál es más ventajoso?

Si los crea antes, formarán parte de la fase de diseño.

Si los crea después, puede usarlos para documentación. Pero documentar es mejor y más rápido si lo hace durante el diseño y la codificación.

Por cierto, ¡no pierdes tiempo haciendo diseño! La parte de codificación será más rápida. Y mejor.

Después de todo, ¿crees que diseñar un rascacielos o un puente es una pérdida de tiempo en lugar de comenzar a construirlo?

Un compromiso es comenzar a crear algún código ficticio durante la fase de diseño (solo prototipos de clases / funciones) y usar este esqueleto de código para construir los diagramas de clase.

Cuando los he creado antes de la codificación, los vemos como documentos "temporales". Es decir, creamos los diagramas y llevamos nuestros pensamientos al papel. Comenzamos a codificar a partir de esos diagramas de clases. Luego los tiramos. No vale la pena perder el tiempo para mantenerlos una vez que la codificación ha comenzado. Y si desea modelos de clase actualizados, use una herramienta para crearlos a partir del código.

En cualquier caso, se quedarán como parte de la documentación. Nadie los actualizará cuando se realicen cambios en la implementación. Los diagramas no tendrán fechas, por lo que ni siquiera sabrá a qué versión del código se refieren. Cuando se agrega una nueva persona al proyecto, le dará los diagramas que dicen "Aquí hay algunos diagramas que se crearon en algún momento durante el diseño o la implementación. No sabemos qué tan actualizados están".

Esto es parte del diseño y, por lo tanto, debe crearse antes de la implementación. Esto no quiere decir que no se puedan refinar durante / después de la implementación para reflejar el estado actual de las implementaciones.

Proporcionar un diseño después de la implementación es lo que yo llamaría "codificación de vaquero", y seguro que puedes prosperar en el salvaje oeste salvaje, pero recuerda que los vaqueros generalmente terminan muertos en algún momento u otro.

Depende de la profundidad del diseño. Algunas personas insisten en escribir diagramas de clase incluso para las clases más triviales, porque "es una buena práctica". Creo que es una pérdida de tiempo dibujar algo cuando ya sabes exactamente cómo se implementará. Al crear un nuevo diseño, algo que no le resulta familiar, definitivamente es útil dibujar primero algunos diagramas.

Sin embargo, nunca uso herramientas UML, porque el diseño generalmente cambia tanto durante la implementación que tengo que volver a dibujar el diagrama. Supongo que una buena herramienta de dos vías manejaría estos cambios, pero nunca he usado una buena (aunque solo he usado las gratuitas). En cambio, dibujo en papel o en una pizarra para ayudarme a clasificar el diseño. Después de que lo haya implementado y esté razonablemente seguro de que es sólido, haré un diagrama más formal.

Además, no olvidemos los otros tipos de diagramas. Siempre he encontrado los diagramas de secuencia entre los más útiles, y los uso a menudo cuando hay mucha comunicación entre los componentes.

Antes de la implementación. Como uno de mis antiguos compañeros de trabajo dijo una vez: "Me gusta hacer tanta programación como sea posible antes de comenzar a codificar", y creo que es un buen enfoque.

Me parece que el acto de dibujar un diagrama generalmente me alerta de la falta de información. Esto también sucederá si solo estoy escribiendo un editor de código sin haber dibujado el diagrama, pero las instancias estarán más separadas (porque pasaré tiempo escribiendo algoritmos y cálculos y pruebas y demás) y entonces podría dar más tiempo para pasar antes de obtener mi información faltante.

Además, si el diseño que vagamente tiene en la cabeza resulta ser una mierda, lo notará más rápidamente si lo diagrama primero. Por lo tanto, al menos dibujo algo rápido e informal. Si se convierte en un diagrama electrónico que otros puedan usar como referencia dependerá del proyecto.

La creación del diagrama de clase debe realizarse durante y después porque el modelo debe ser interactivo con el código y las modificaciones de requisitos. Primero necesitas crear un diagrama de clase para comenzar tu proyecto. Sería útil visualizar en un nivel superior de abstracción sus objetos. Podrá crear una arquitectura de software estable e inteligente. Luego necesita codificar y, a veces, notará que la arquitectura que parece estar bien en UML no es realmente posible en el código. Luego cambias tu código y arquitectura. Finalmente, actualiza su modelo con modificación de código y genera documentación.

En mi último proyecto, los tomadores de decisiones han cambiado mis requisitos más de 50 veces en el último año. Es realmente doloroso y UML me ayuda a mantener la trazabilidad de los cambios y por qué. UML debería permitir la fusión de modelo y código en cualquier momento de forma iterativa (por ejemplo, de código a modelo, de modelo a código, de ambos, de código después de refactorizar, etc.). Uso Omondo EclipseUML para Helios y estoy muy contento con esta herramienta. Mi característica favorita es la combinación de modelos que me permite actualizar mi modelo en cualquier momento sin perder la información del modelo. También me gustan las entidades que modelan directamente en el diagrama de clases y crean la base de datos usando estereotipos e hibernación. ¡Realmente poderoso y completo desde el objeto a la base de datos!

Antes : le ayudará a organizar sus pensamientos y comunicar su intención. No entres en detalles aquí.

Después : se genera automáticamente a partir del código como parte del proceso de compilación, obviamente (espero que no esté demasiado conectado a uml)

Ambos son útiles, pero las cosas anteriores se pueden tirar tan pronto como se implementen ... ya están desactualizadas de todos modos en este punto.

Con Topcased , creo mis diagramas de clase durante la fase de diseño. Luego hago clic en el botón "Generar código" para generar un lienzo de mi implementación. Luego relleno los marcadores de posición con código.

Voy a votar por la respuesta (C) No te molestes.

Son en gran medida innecesarios. Personalmente, nunca me molesto en mirarlos cuando se proporcionan.

Son innecesarios antes del desarrollo, porque el diseño cambiará de todos modos. Y si no cree que el diseño de sus clases cambiará, entonces ya está esposado y evitando que su futuro sea capaz de resolver el problema adecuadamente. Si crees que tienes que seguir algunos diagramas de clase preexistentes, entonces trabajas para la NASA o te estás disparando en el pie.

Luego, son documentación innecesaria. Si no puede averiguar qué están haciendo las clases o cómo se relacionan entre sí con una pequeña inspección de código, entonces tiene un hueco en su conjunto de habilidades como desarrollador de software.

Por supuesto, esta respuesta suena realmente arrogante y obstinada; Oh bien.

Con Eiffel y las herramientas asociadas, esto es solo una diferencia de punto de vista que apunta a los mismos archivos subyacentes.