it-swarm-es.com

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

De la forma en que lo veo si crea uno antes de obtener la ventaja de:

  • Planificar el futuro
  • Resumen del proyecto

pero pierdes:

  • Tiempo (trabajando probablemente terminará 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 clases y cuál es más ventajoso?

11
Jonn

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

Si los crea después, puede usarlos como 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 empezar 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 clases.

9
Wizard79

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

12
Jeff Siver

En cualquier caso, permanecerá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 entregará 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".

4
Mark Lutton

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 o 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 vaqueros", y seguro que puedes prosperar en el salvaje oeste, pero recuerda que los vaqueros suelen acabar muertos en algún momento.

3
Chris

Depende de la profundidad del diseño. Algunas personas insisten en escribir diagramas de clases 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 va a implementar. Cuando creando un nuevo diseño, algo que no es familiar, definitivamente es útil dibujar algunos diagramas primero.

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 bidireccional 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 implementarlo y estar razonablemente seguro de que es correcto, haré un diagrama más formal.

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

3
Matt Olenik

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

1
GSto

Encuentro que el acto de dibujar un diagrama generalmente me alerta de la falta de información. Esto también sucederá si solo estoy escribiendo en un editor de código sin haber dibujado el diagrama, pero las instancias estarán más espaciadas (porque dedicaré tiempo a escribir algoritmos, cálculos, pruebas y demás) y, por lo tanto, podría permitir más tiempo para pasar antes de obtener la información que me falta.

Además, si el diseño que tiene vagamente en la cabeza resulta ser una mierda, lo notará más rápidamente si lo diagrama primero. Por 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.

1
Kate Gregory

La creación de diagramas de clases 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 clases para comenzar tu proyecto. Ayudaría a visualizar a un mayor nivel de abstracción sus objetos. Podrás crear una arquitectura de software estable e inteligente. Entonces necesita codificar y, a veces, notará que la arquitectura que parece estar bien en UML no es realmente posible en el código. Luego cambia su 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 la refactorización, etc.). Utilizo 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 gusta modelar entidades directamente en el diagrama de clases y crear la base de datos usando estereotipo e hibernación. ¡Realmente poderoso y completo desde el objeto hasta la base de datos!

1
UML_GURU

Antes: ayudará a organizar sus pensamientos y comunicar su intención. No entre 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 apegado a uml)

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

1
Matthieu M.

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

0
mouviciel

Voy a votar por la respuesta (C) No se moleste.

Son en gran parte innecesarios. Personalmente, nunca me molesto en mirarlos cuando están provistos.

Son innecesarios antes del desarrollo, porque el diseño cambiará de todos modos. Y si no crees que el diseño de tus clases cambiará, entonces ya te estás esposando y evitando que tu yo futuro pueda resolver adecuadamente el problema. Si cree que tiene que ceñirse a algunos diagramas de clases preexistentes, entonces o trabaja para la NASA o se dispara en el pie.

Después, 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 vacío en su conjunto de habilidades como desarrollador de software.

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

0
Chris Holmes

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

0
Greg Domjan