En el gráfico dos opciones posibles. Una más descriptiva que la otra, pero ninguna comete el error de entrar a descomponer las funcionalidades del sistema como si estuviéramos ya desarrollando.
¿Cual de las dos opciones es correcta? Ambas lo son, pues describen la realidad pero toda documentación se deben ajustar a un contexto: ¿quién es el público objetivo de la documentación?. Si son los clientes del proyecto se podría usar la versión 1, pero si son desarrolladores (con más razón si cuentan con poca experiencia) tal vez se podría usar la versión 2 que explica con un poco más de detalle la funcionalidad que tendrá el sistema.
Algunas puntualizaciones sobre el tema de los diagramas de casos de uso:
- Para qué se usan: Los Casos de Uso son empleados para descubrir y capturar requerimientos de los clientes en una forma que sea accesible para todos los participantes del proyecto, tanto desarrolladores como clientes.
- Qué deben comunicar: Un Caso de Uso describe QUÉ hace el sistema sin decir CÓMO lo hace.
- Qué representan: una o varias funcionalidades de nuestro sistema que ofrecen valor al usuario del mismo. Si lo que estamos documentando ("el globo") no devuelve ningún valor al usuario, no debe considerarse un caso de uso.
- Flecha"include": es cuando un caso de uso incluye otro caso de uso. El caso base incorpora explícitamente el comportamiento del otro. En ambos casos el sistema lista ("listar usuarios") o consulta ("consultar usuario") para llegar a mostrar finalmente toda la información del usuario como si fuera una ficha ("mostrar usuario") que en nuestro caso se hace dos veces (se llega por dos caminos distintos a la ficha del usuario).
- Los nombres de los casos de uso: preferiblemente que sean descriptivos de la acción o el valor que generan al actor del sistema. En vez de usar términos como "Listado de Usuarios" se usa una expresión más genérica que describa la acción o uso en el contexto del sistema: "listar usuarios".
Por ejemplo, para el caso de uso "consultar usuario":
Curso Básico
- El usuario ingresa el id o el nombre del usuario
- El sistema lo encuentra y muestra la ficha del usuario
- Si el usuario no ingresa ni id ni el nombre el sistema envía un mensaje de error
- Si el sistema no encuentra el usuario envía un mensaje de ayuda y posibilita volver a intentar la consulta.
Relación entre Casos de Uso y los "módulos" de nuestro sistema
Podemos hacer un paralelismo en nuestro contexto: cada caso de uso puede convertirse literalmente en un "módulo" de nuestra aplicación:
- Caso de Uso "Listar Usuarios" -> listado_usuarios.php
- Caso de Uso "Consultar Usuario" -> consultar_usuario.php
- Caso de Uso "Mostrar Usuario" -> mostrar_usuario.php
En muchos casos pude ver trabajos que incluían el "index" como un caso de uso. A pesar de que nuestro sistema siempre tendrá uno, no necesariamente hay que representarlo (cuanto más minimalista el diagrama, mejor). Lo más realista sería que si nuestro "index" ofrece algo más que información estática (como sucede en el "proyecto base") se podría considerar que ofrece "valor" al usuario. Por ejemplo, si la página principal fuera un sistema de noticias, ordenadas cronológicamente, con posibilidad de comentarios, etc, sí lo agregaría como un caso de uso y lo nombraría "mostrar noticias" (no necesariamente "index", estoy contando la funcionalidad, no cómo la voy a implementar ni en donde).
Espero haber aportado un poco más sobre el tema y haber despejado algunas dudas. Cualquier otra consulta está disponible la sección de comentarios de esta entrada ;-)
10 comentarios:
Hola, bueno yo siempre he tenido una duda con relación a los diagramas de casos de uso y es cuando se presentan las relaciones de inclusión, exclusión etc..
Básicamente lo que deseo preguntar y haciendo alusión al ejemplo del trabajo es:
Necesariamente la relación que existe entre listar usuarios y mostrar usuario debe ser de inclusión?... pues mi pregunta es porque o mas bien yo lo miro así: el objetivo principal de listar usuarios es mostrar todos los usuarios que hay registrados, mas no ver la descripción de cada uno, mas sin embargo a través de él (listar usuarios) se puede acceder a la descripción esta y ahí es donde se llama a mostrar usuarios; por esta razón se me hace complicado entender que sea de inclusión, ya que entiendo por ésta el hecho de que si se incluye un CU dentro de otro CU, es porque necesariamente debe ejecutarlo y pues aquí en el ejemplo éste "que es preciso!!", no se va a mostrar usuario hasta que el usuario indique una selección... entonces viéndolo así, esto no se podría representar con una línea de simple asociación indicándose así que el CU listar usuarios puede hacer uso o no de mostrar usuario…
Gracias... Bye
Estimada paopao1983:
> Hola, bueno yo siempre he tenido
> una duda con relación a los diagramas
> de casos de uso y es cuando se
> presentan las relaciones de inclusión,
> exclusión etc..
Inclusión cuando un caso de uso es parte de otro caso de uso, no necesariamente es un "caso de uso puro". Si entendemos un caso de uso como una funcionalidad, como algo que le retorna "verdadero" valor al usuario, sin llegar a entrar en la descomposición que hacemos a la hora de desarrollar nuestro sistema.
Por ejemplo, un caso de uso "login" no necesariamente es una funcionalidad que retorne valor al usuario, es un mal necesario del sistema para cumplir con un concepto de seguridad, de zonas públicas y privadas.
Pero tú debes decidir si lo documentas o no, de acuerdo a tu contexto y tu público objetivo. Tal vez se sobreentienda que deberá existir un "login", entonces no lo agregas al diagrama, pues a tu cliente no le aporta información, solo es ruido extra.
Pero tal vez tu contexto es otro, y los clientes de tu documentación son los desarrolladores de tu equipo, entonces lo agregas porque quieres luego poder asignar el caso de uso a una persona o grupo para que lo implemente.
En el caso de la extensión, es una variación del mismo: caso de uso "entregar mercadería" y la extensión puede ser "urgente" y "certificada". El caso base es claro, pero las dos extensiones hablan de una variación sobre el caso base, no nuevos casos de uso, que además no tienen por qué darse siempre.
¿Se entiende la diferencia? Pero no hay que olvidar que todo está sujeto a interpretación y pueden haber más de una forma de representar la realidad. Por eso es fundamental que los diagramas estén acompañados por una "especificación de requerimientos" (y ahí aclaras el contexto, tu público objetivo, cada caso de uso, la estrategia, comportamiento, etc).
¿Logras captarlo? El diagrama, repito, está sujeto siempre a interpretación, por lo tanto por sí solo no es preciso.
No te olvides que estamos haciendo el camino forzado más difícil, a partir de la implementación inferir los casos de uso. Visto en ese contexto tú puedes llegar a mi diagrama (tanto la versión con o sin "mostrar usuario"). Usé este ejemplo para romper un poco el razonamiento tradicional. Pero la situación ideal, clásica, es captar las necesidades de tu cliente y sin llegar a bajar hasta el nivel de implementación, documentarla con casos de uso.
Por eso este ejercicio fue más difícil pues les di primero el código, para contaminarlos ;-)
Espero que el próximo, partiendo de un requerimiento vago, pueden hacerlo mejor.
Espero haberte respondido.
hola,
bueno lo que pasa es que estoy realizando un proyecto de una pagina web de una importadora, para un curso de la u,
lo que no entiendo es como voy a hacer un diagrama de casos de uso para una pagina web, si podrias responderme seri increible y estaria eternamente agradecida.
olivia
Estimada Olivia:
Tú problema es claro (mmm, ya sueno a "oráculo"): no puedes asociar conceptualmente "un caso de uso" con "una página web".
Tienes que ser más abstracta y pensar desde un "más alto nivel".
Los casos de uso son el primer paso para tratar de entender el problema (antes de cómo vas a hacer el sistema), no puedes empezar asociando con tecnología.
Mira los ejemplos, busca más ejemplos.
gracias por la ayuda
pero tengo otra pregunta
el problema en la empresa es que quieren ofrecer sus productos via internet, entonces lo que tengo que hacer es ver como funciona toda la empresa y realizar los casos de uso de toda la empresa?
a eso te refieres......
olivia
Estimada Olivia:
Los Casos de Uso son independientes de la tecnología, pensá que son diagramas para empezar a dialogar y documentar de alguna forma lo que quiere hacer el cliente.
Harás los casos de uso para el sistema que quieren, no de toda la empresa y sus procesos.
PD: date una vuelta por wikipedia:
Casos de Uso
muchisimas gracias ahora por fin voy a poder avanzar en mi trabajo, estaba un poco perdida .....
olivia
pd. cuaquier otra consulta te vuelvo a escribir :)
Buen dia, tengo una consulta acerca de la documentación de los casos de uso, por ejemplo un caso de uso "Actualizar Cursos", pero este caso de uso debe entenderse como la acccion de Modificar, Eliminar y Agregar Cursos, pero para documentar todos estos procesos en un solo caso de uso no existen una secuencia de pasos similar, la pregunta es la siguiente: Necesariamente tengo q separar en 3 casos de uso o puedo hacer una descripcion de de todo el caso de uso sin indicar la secuancia de pasos? Muchas Gracias
Estimado Victor:
El mejor ejemplo que te puedo dar es con los ABM's, hay personas que prefieren definir un solo casos de uso y otras uno para cada acción, es decir, uno para Alta Usuarios, Modificación Usuarios, y Baja de Usuarios.
La idea de los casos de uso es que sean genéricos, es el primer relevamiento y no es el diseño del sistema.
Mi sugerencia, cuando más genéricos y de alto nivel, mejor (aunque eso dependerá de tu público objetivo).
Es preferible que hagas un caso de uso "Administración de Usuarios" y que en la documentación escrita (hacer los diagramas es el 10% del caso de uso) explicas todo lo que deberían contemplar.
Espero haber aclarado algo ;-)
Buenas Tardes, Mucho Gusto, estoy iniciándome en el Mundo del UML, Justamente me hice la pregunta, de que si en mi Sistema tengo que usar Login y quisiera Documentarlo, ¿Como quedaría gráficamente ese Caso de Uso?
Publicar un comentario