Resumen CU
Diagrama de casos de uso
El diagrama de casos de uso es uno de los diagramas
incluidos en UML 2.5, estando este clasificado dentro del grupo
de diagramas de comportamiento. Es, con total seguridad, el diagrama más
conocido y es utilizado para representar los actores externos que interactúan
con el sistema de información y a través de que funcionalidades (casos de uso o
requisitos funcionales) se relacionan.
Dicho de otra manera, muestra de manera visual las
distintas funciones que puede realizar un usuario (más bien un tipo de usuario)
de un Sistema de Información.
El diagrama de casos de uso, dependiendo de la
profundidad que le demos, puede ser utilizado para muchos fines, entre ellos
podemos encontrar los siguientes:
- Representar los requisitos funcionales.
- Representar los actores que se comunican con el sistema. Normalmente los actores del sistema son los usuarios y otros sistemas externos que se relacionan con el sistema. En el caso de los usuarios hay que entender el actor como un “perfil / rol”, pudiendo existir varios usuarios que actúan como el mismo actor.
- Representar las relaciones entre requisitos funcionales y actores.Guiar el desarrollo del sistema. Crear un punto de partida sobre el que empezar a desarrollar el sistema.
- Comunicarse de forma precisa entre cliente y desarrollador. Simplifica la forma en que todos los participantes del desarrollo, incluyendo el cliente, perciben como el sistema funcionará y ofrecerá una visión general común del mismo.
Elementos de un
diagrama de casos de uso
Un diagrama de casos de uso está compuesto,
principalmente, de 3 elementos: Actores, Casos de uso y Relaciones.
Actores
Un actor es algo o alguien externo al sistema que
interactúa de forma directa con el sistema. Cuando decimos que interactúa nos
referimos a que aporta información, recibe información, inicia una acción, etc.
.
Se representan con una imagen de un “muñeco de palo” con
el nombre del actor debajo.
Representación de un actor
Existen dos tipos de actores: Los usuarios y los
sistemas.
No hay que entender los usuarios como personas
singulares, sino como “perfiles o roles” que identifican a un tipo de usuario,
pero no al usuario en sí. Por ejemplo, en una aplicación de gestión de nóminas,
un actor de este tipo podría ser “gestor de nóminas” que se encarga de emitir y
firmar nóminas. Este rol podría ser tomado, por ejemplo, por cualquier
individuo del personal de recursos humanos y, además, por el jefe de la
empresa. Es un ejemplo sencillo, en donde un actor no representa a una única
persona o a un único usuario.
Ejemplo de actor
Por otro lado, los actores pueden ser otros sistemas que
también interactúan con nuestro propio sistema. Un ejemplo podría ser, en
nuestra aplicación de nóminas, un sistema que almacene las nóminas firmadas a
modo de archivo. En este caso cuando se firma la nómina se recibe la misma por
el sistema de archivo, por tanto el caso de uso se relaciona con el actor.
En ocasiones este tipo de actores no se representa con un “hombre de palo” porque puede dar la sensación de que es un usuario y queda poco intuitivo. Se utiliza un rectángulo rotulado.
Casos de uso
Un caso de uso se utiliza para representar una de las
funcionalidades que realiza el sistema. Es una secuencia de acciones que hace
el sistema y que producen un resultado que puede percibir un usuario.
Formalmente hablando, un caso de uso es una clasificación
de comportamiento que especifica una unidad de funcionalidad completa y que
está realizada por uno o más sujetos que se relacionan con el caso de uso
colaborando para ello con uno o más actores y que produce un resultado que
tiene alguna utilidad para cualquier de esos actores.
Se representan con una elipse que incluye en su interior
el nombre del caso de uso.
Representación de un caso de uso
Ejemplos de casos de uso: Crear pedido, Listar productos,
Enviar correo. Cualquier acción que realice la aplicación.
Las especificaciones anteriores a UML 2.5 requerian que
un caso de uso sea invocado por un actor. En UML 2.5 esto se eliminó, lo que
significa que podría haber algunas situaciones en las que la funcionalidad del
sistema la inicie el propio sistema y, al mismo tiempo, brinde resultados
útiles a un actor. Por ejemplo, el sistema podría notificar a un cliente que se
envió la orden, programar la limpieza y el archivo de la información del
usuario, solicitar información de otro sistema, etc.
Relaciones
Las relaciones conectan los casos de uso con
los actores o los casos de uso entre sí.
Cuando conectan un actor con un caso de uso representa
que ese actor interactúa de alguna manera con ese caso de uso y se
representa con una linea continua con la
identificación <<communicates>>.
Cuando conectan casos de uso entre sí se pueden
diferenciar dos tipos de relaciones: <<include>> y
<<extends>>.
En español a veces se usa la nomenclatura
<<usa>> y <<extiende>>:
<<include>>: Se utiliza para representar
que un caso de uso utiliza siempre a otro caso de uso. Es decir, un
caso de uso se ejecutará obligatoriamente (lo incluye, lo usa). Se representa
con una flecha discontinua que va desde el caso de uso de origen al caso de uso
que se incluye.
Relación
include entre dos casos de uso
Un uso típico de este tipo de relaciones se produce cuando dos casos de uso comparten una funcionalidad. Esa funcionalidad es extraída de los dos y se crea un caso de uso nuevo que se relaciona con los anteriores con un include.
Ejemplo de uso de include
En este ejemplo, los casos de uso emitir factura y enviar producto ejecutarán ambos el caso de uso autenticación.
<<extend>>: Este tipo de relaciones se
utilizan cuando un caso de uso tiene un comportamiento opcional, reflejado
en otro caso de uso. Es decir, un caso de uso puede ejecutar, normalmente
dependiendo de alguna condición o flujo del programa, otro caso de uso. Se
representa con una flecha discontinua que va desde el caso de uso opcional al
original.
Relación extend entre dos casos de uso
Un ejemplo de esta relación podría ser la siguiente:
Ejemplo de relaciones extend
En este supuesto el caso de uso Hacer pedido puede dar lugar
(o no) a otros dos casos de uso: Enviar notificación SMS y Enviar notificación
email. Se supone que, cuando un usuario hace un pedido, el sistema le permite
elegir si quiere que se envíe una notificación de ese pedido por SMS o por
email.
Existe, además, otra relación
denominada generalización que consiste en hacer que un elemento
herede el comportamiento de otro. Aunque se puede utilizar entre casos de uso,
es más común utilizarlo entre actores, haciendo que uno de los actores tenga
acceso a las funcionalidades de otro. Se representa con una flecha con la punta
hueca que va desde el elemento que hereda al elemento heredado:
Generalización entre dos actores
Descripción de requisitos funcionales y no funcionales
Es común en este tipo de diagramas describir cada caso de
uso junto con la secuencia de pasos necesaria para completarlo y las posibles
excepciones hasta definir todas las situaciones posibles. Esta descripción
servirá de guía para el desarrollo, la profundidad de las situaciones que se traten
dependerá de cada fase del proyecto o de cada situación en particular.
Existen dos tipos de requisitos:
- Requisitos funcionales
- Requisitos no funcionales
Los requisitos suelen ser plasmados junto a la siguiente
información:
Identificador y nombre descriptivo: Se utiliza una
identificación única para diferenciarlo de los demás y un nombre descriptivo
que suele coincidir con el objetivo que los actores esperan alcanzar al
realizar el caso de uso.
Versión
Autores
Objetivos asociados
Requisitos asociados
Descripción: Este campo debe completarse de forma
distinta en función de si el caso de uso es abstracto o concreto.
Precondición: se expresan en lenguaje natural las
condiciones necesarias para que se pueda realizar el caso de uso.
Secuencia normal: secuencia normal de interacciones
del caso de uso. En cada paso, un actor o el sistema realiza una o más
acciones, o se realiza otro caso de uso.
Postcondición: se expresan en lenguaje natural las
condiciones que se deben cumplir después de la terminación normal del caso de
uso.
Excepciones: especifica el comportamiento del
sistema en el caso de que se produzca alguna situación excepcional durante la
realización de un paso determinado, lo que modifica el flujo “normal” del caso
de uso.
Ejemplos de representación de un requisito en forma de
tabla:
Modelado de un requisito funcional
Modelado de un requisito no funcional
Cómo dibujar un diagrama de casos de uso
A la hora de dibujar un diagrama de casos de uso es
conveniente que se compruebe que se ha realizado previamente todos estas
tareas, respondiendo a las preguntas detalladas a continuación:
- Recopilar fuentes de información: ¿cómo se supone que debo saber eso?
- Identificar actores potenciales: ¿qué usuarios utilizan los bienes y servicios del sistema empresarial?.
- Identificar posibles casos de uso: ¿a qué bienes y servicios pueden recurrir los actores?
- Conectar los casos de uso: ¿quién puede hacer uso de los bienes y servicios del sistema empresarial?
- Describir actores: ¿a quién o qué representan los actores?
- Buscar más casos de uso: ¿Qué más debe hacer el sistema?
- Documentar casos de uso: ¿qué sucede exactamente en cada caso de uso?
- Relacionar modelos entre casos de uso empresarial: ¿qué actividades se realizan repetidamente?
- Verificar la vista, ¿todo es correcto?
Los pasos se han escrito en este orden a propósito, ya
que es la forma lógica de seguirlos. Sin embargo, este orden no es obligatorio,
ya que en la práctica, los pasos individuales a menudo se superponen unos con
otros.
Para poder seguir los pasos de una forma óptima, es
importante comprender el negocio/sistema para conseguir seguir cada paso individual.
Descargar ejercicios
En la guía de ejercicios se plantean tres casos de estudio: Veterinaria, Ventas y Almacén.
El caso de estudio Veterinaria será resuelto por BONFIETTI, Melina y su presentación oral se realizará el día 22/05/19.
El caso de estudio Ventas se resolverá en clase el día 15/05/19.
El caso de estudio Almacén será resuelto por RUIZ, Agostina y su presentación oral se realizará el día 29/05/19.