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.

Anuncios

5 comentarios en “Cuando Usar diagramas UML

  1. Saludos.

    Yo diría que te encuentras en el lado ágil del pensamiento sobre desarrollo de software. Desde la otra banca sin embargo, los modelos de software son el tema central del desarrollo; utilizamos modelos para pensar en el sistema, para capturar los requisitos, para planificar la construcción, para validar los construido y así hay una larga lista de usos para el modelado.

    De hecho, desde este punto de vista el código mismo puede ser visto como un modelo. Un modelo ejecutable en maquina dado que es computacionalmente completo, pero que no es el más apropiado para mantener la arquitectura del sistema así como tampoco para capturar los requisitos o servir de base para la documentación de usuario.

    Por otra parte, si bien estoy de acuerdo con muchos de los puntos que señalas, no puedo dejar pasar el rol que le das a la documentación. Tanto diagrama descartado es una lastima, ellos bien pudieran ser tomados para mantener la documentación y es que de hecho, yo no pienso que los documentos se hagan a posteriori del desarrollo, es necesario hacerla al mismo tiempo que se construye el sistema.

    Aun más digo, que el buen desarrollo de software en un proceso normativo como RUP/UP genera documentación como producto secundario de las actividades de desarrollo y es esta documentación, cuya construcción no requirió esfuerzo adicional, la que justamente entregamos al cliente.

    Y finalmente, los modelos se expresan en diagramas. Según el aspecto que queramos mostrar, hacemos mayor o menor cantidad de diagramas.

  2. Saludos.
    En mi experiencia, los diagramas no solo me sirvieron para la captura de requisitos y el entendimiento total del sistema, sino tambien me sirvieron como una documentacion muy importante a la hora de hacer reingenieria de procesos y a la hora de reusar procesesos.
    Si bien es cierto que aveces muchos de estos diagramas son verdaderamente engorrosos y no se le encuentra utilidad inmediata, pero a la lagrga terminas sirviendo.
    Tambien dependeria de la utilización de los diagramas, el tamaño del producto a desarrollar y la cantidad de personas involucradas en el desarrollo.

  3. que tanta importancia le debemos de dar a los diagramas UML? enserio se usan tanto una vez estando en el area labora?, que deberia de ser primero los caso de uso o los requerimientos, pregunto por el echo de que uno depende del otro y veceversa

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s