Diagramas UML, Casos de Uso (Use Case), muniecos y pelotas

Los diagramas no son lo importante“, es la frase que tengo en la mente después de leer UML: Casos de Uso. Use Case, y aclara algo muy importante que a veces muchos, cuando empezamos en UML, no entendemos porque tenemos que hacer Casos de Uso, u otro diagrama UML, y pués tenian razón “los diagramas no son lo importante”.

Lo realmente importante de los diagramas UML, son los documento de descripción de casos de uso, este documento explica la forma de interactuar entre el usuario y el sistema. En algunos proyectos hasta solo se podría usar los Documentos de Descripción de Casos de Uso, claro dependiendo del proyecto, y la experiencia con UML, veamos un ejemplo de un Documento de Descripción de Casos de Uso:

Ahora que pasa si tenemos demasiados casos de uso, y es difícil concebir la interrelación de estos, entonces ahora si necesitamos una visión general del asunto, ahora necesiamos un Diagrama de Casos de Uso, en el artículo, los llaman muñecos y pelotas:

Fuente: “Prácticas y métodos para mejorar el desarrollo de Proyectos de Software” -> http://www.ingenierosoftware.com/.

A algunos usar Diagramas UML les puede no parecer util en los proyectos, Documentando software y… más motivos por los que UML no es la solución, leyendo el artículo queda un poco más claro, nuevamente “los diagramas no son lo importante“. Y para algunos imagino que será díficil aceptar, por todo lo que le enseñaron en la universidad, instituto, o algún otro centro, que los Diagramas UML lo eran todo, y hasta a veces caias en discuciones bizantinas si es extends, o include, imagino que a los que no presentaron atención a la clase de UML serán los mas contentos el post de Rodrigo… otro post interesante de Rodrigo Corral, es: Porque no me gusta UML.

P.D.: Se pudo haber detallado más, o obviado algunos detalles, en el caso de uso y en su descripción, pero eso ya depederá de los requeremientos que tengan, y de lo que esten haciendo.

Saludos,

Post cruzado desde starrillo blog

29 comentarios en “Diagramas UML, Casos de Uso (Use Case), muniecos y pelotas”

  1. Holas Gorka!

    Tiene varias cosas interesante el libro que comunmente no ponen los libros que visto de UML:

    1. eXtreme Programming (XP) and use cases
    2. Tips for writing use cases
    3. Managing use cases for large projects
    4. Use case templates for five common project types
    5. Test cases
    6. y más….

    Gracias por el dato!

    Saludos,

  2. Hola, Sergio, UML es un estándar en el desarrollo de proyectos de software lo que pasa que no saben o no sabes utilizarlo, existen muchos libros y articulos que en verdad lo que hacen es engañar y decir tantas tonterias que al final se obtiene gente descontenta, espero que te rectifiques y algun dia realices un proyecto de software aplicando UML, saludos

  3. Hola Ricardo!

    Es una opinión personal la información presentada en el post, y si la envié fue porque en un proyecto en el que participe no hubo la necesidad de hacer todos los diagramas UML, lo más importante que teníamos que presentar fueron la descripción de casos de uso.

    Como ya lo han dicho, varios comentarios en los post de Rodrigo Corral, dependerá del tamaño del proyecto, de las políticas de desarrollo que hay en la empresa, poder usar, todos o solo algunos, los diagramas UML. Como programador, no tienes mucha decisiones para elegir cuales diagramas usar o no, al final es el Jefe de Proyecto quien define esta tarea.

    Personalmente no usaría todos los diagramas UML, solamente los que necesite, es decir los que me permitan documentar claramente los procesos del negocio. Por otro lado dependiendo de la complejidad de los procesos se hace más necesario verlos de diversos puntos de vista para entederlos, ahí es necesario y se podría decir obligatorio usar UML.

    P.D.: No pretendi generalizar mi punto de vista a todos los tipos de proyectos.

    Saludos,

  4. Hola,

    simplemente me gustaría comentar una cosa que veo muy amenudo.

    Por ejemplo, en el caso de los “Casos de Uso”. Mucha gente utilizan únicamente en los diagramas flechas y círculos, (dándoles igual si es un include, un extend, una generaliación o una asociación).

    Estas relaciones están para algo. Un diagrama es mucho más rico, tiene más información si conocemos todos sus elementos y se utilizan correctamente.

    Igualmente pasa con el resto de diagramas.

    Un saludo

  5. Mis estimados , solo me basto leer tan solo los primeros comentarios y pues, solo hace falta un descarriado para que yo me manifieste , pues amigo , aun confundido, estas , los diagramas CUS o CUN o cualquier otro , o ocmo dices tu esos muñequitos y pelotitas, son la base de la “comunicacion” entre los realizadores del sistema, se que para algunos se les hace dificil, por no decir aburrido , el hacer los diagramas y solo quieren irse ala programcion y hacer “fisico” el sistema, pero despues de eso que ? terminastes el proyecto, pasan meses quieres implantar ese sistema en otro lugar , como se los explicas a tus clientes ? pues claro necesitas algo tan simple como muñequitos y pelotitas para que te entiendan , y a esto suponer que en el mejor de los casos “recuerdes cada detalle de tu proyecto” pues amigo no creo, y sin ofender tu sapiencia puedas retenr cada detalle de los muchos sistemas que desarrolles en tu vida, otro ejemplo , sales de la empresa, el sistema queda aun implantado, si se desea una modificacion o una extension del sistema que de seguro es muy bueno , tu crees que alguien podria desmarañar todo lo que hicistes ??? si el proyecto no esta debidamente documentado ?? , por eso amigos, compañeros entiendan que antes de nosotros hubieron otros, que descubrieron , que padecieron , y vieron necesario realizar estas metodolgias para un buen diseño de una sistema . pero si su meta de uds. es solo ser programador , pues, esperen que los “Ing” les pasen la documentacion para que empiecen a trabajar. y comprendan que aunque duela la medicina al final no hace bien . su amigo . Renee morales. ing.renee.sis@gmail.com

  6. Una consulta, este caso planteado es de algun Traninig, chamba, Tarea ? o por hobby, lo podriamos desarrollar en Linea, si es asi me apunto 🙂

    Saludos

    Jesus

  7. Lo importante no es la herramienta que utilicemos, da lo mismo si es UML (muñecos o pelotas)lo verdaderamente importante es que quede documentado la forma como se realizo el proyecto, para que despues de un tiempo podamos retomer esta información y entendamos o recordemos que fue lo que hicimos.

  8. Claro ahi te va unos tips

    un include es un caso de uso que siempre se debe realizar en un determinado escenario ejemplo cuando vas a registrar una factura tu caso de uso seria
    RegistroFactura
    y tu include seria
    Buscar Clientes
    ya que como veras siempre al realizar una factura necesariamente tendras que buscar un cliente ya que una factura sin cliente como podria realizarse

    Ahora con respecto a Extend pues es lo contrario es algo que puedes o no puedes hacer dependiendo del escenario

    ejemplo
    Un caso practico cuando recibes pedido de devolucion almacen

    Caso de uso
    recibir devolucion
    eXtend
    generar nota credito

    ya que se puede o no generar una nota de credito dependiendo del producto

    Espero estos conceptos te hayan sido de utilidad

    No he podido acostumbrarme a la extend y al include alguien me da un tip para aprender a discernir entre ellos de una buena vez

    gracias Ing. Adry

  9. buenas, requiero de de su colaboracion proporcionandome una guia para la realizacion de los casos de uso para un sistema de informacion que contiene encuesta, asimismo la ilustracion grafica de la misma.

    gracias

  10. que aplicacion es la mas facil de usar para realizar los casos de uso y lo que son los diagramas de secuencia y todo lo relacionado por que supongo que aunque solo sean muñequitos y pelotitas debe de haber cierta diferencia entre cada aplicacion y aparte como se puede diferenciar entre un caso de uso y un requerimiento? por que a lo que he visto creo que es muy facil confundirlos

  11. Hola!es importante para mi en estos momentos estos comentarios, además me gustaria sabe si como profeción en Organización y Sistemas estoy capacitada para usar casos de uso en área de analisis y diseños de sistemas donde actualmente laboro, ya que nunca he trabajado con ello.

  12. Me parece muy interesante el ejemplo descrito, aunque tenia entendido que solo los actores que intervienen en el caso de uso se los representa con muñequitos y no al sistema.

  13. el prgrama mas comun y a mi parecer es el mas facil de usar para hacer diagramas UML es staruml lo pueden buscar en google esta pra windows y creo que para linux hay una version tambien no estoy seguro es softwarer libre y para mi mejor que visio de microsoft…

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *