Cuando Usar diagramas UML

Cuando empezamos a desarrollar un sistema por lo general nos encontramos con la dificultad de no saber cuando utilizar diagramas UML y cuando no hacerlo .. muchos de nosotros de preferencia no lo hacemos pues veamos algunas razones para hacer y no hacerlo según lo dice en su libro “UML para programadores Java” Prentice Hall.

No hacer una regla que todo debe ser diagramado. Enorme monto de tiempo en un proyecto puede ser gastado en diagramas que nadie leera.

Cuando utilizar los diagramas

  • Utilizar los diagramas cuando varias personas necesiten entender la estructura de una particular parte del diseño porque todos ellos lo estarán trabajando simultáneamente. Detengase cuando todos ellos esten de acuerdo que lo han entendido.
  • Cuando dos o mas personas esten en desacuerdo con un elemento particular debería ser diseñado, y quieres un consenso del equipo. Pon la discusión dentro de una caja de tiempo para elegir un significado para decidir, como un voto o un juicio imparcial. Detente cuando la decisión haya sido tomada. Borra el diagrama.
  • Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar. Descarta el diagrama.
  • Cuando necesites exponer una estructura de alguna parte del código a alguien mas o a ti mismo. Detente cuando la explicación deberla ser mejor hecha viendo el código.
  • Cuando este cerca al la finalización del proyecto y tus clientes tienen peticiones como parte de un flujo de documentación para otros.

Cuando no utilizar diagramas

  • No dibujar diagramas porque el proceso te lo dice
  • Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño hacerlo. Los buenos diseñadores escriben código y dibujan diagramas solamente cuando es necesario.
  • No dibujar diagramas para crear comprensiva documentación de la fase de diseño priori al código. Los documentos casi no tienen ningún valor y consumen inmensos montos de tiempo.
  • Dibujar diagramas para que otra persona codifique. La verdadera arquitectura del software participa en la codificación de sus diseños, lo pueden poner en la cama y tenerlo hecho.

Epa epa epa pero que hay de la documentación ?

La buena documentación es esencial en cualquier proyecto. Sin esta el equipo se perdería en un mar de código. Por otro lado mucha documentación de la clase equivocada es mala; porque entonces tendras toda esa distracción y papeles engañosos y todavía tendrías el mar de código.

La documentación debe ser creada pero prudentemente. A menudo la elección de no documentar es tan importante como un documento. Un protocolo complejo de comunicación debe ser documentado. Un complejo esquema de relación necesita ser documentado. Un complejo framework reusable debe ser documentado.

Sin embargo ninguna de estar cosas necesita cientos de paginas de UML. La documentación del software debe ser pequeña y puntual. El valor del documento del software es inversamente proporcional al tamaño.

Pondría esta documentación en un wiki o alguna herramienta colaborativa entonces que cualquiera del equipo podría tener acceso a ella, buscar y podría modificarla según la necesidad

Esto toma un gran monto de trabajo hacer un documento pequeño pero que el trabajo este bien, la gente leera un documento pequeño a diferencia de un documento de 1000 hojas.

Saludos y espero les sirva de mucho.