Diagrama de Casos de uso - Apunte teórico - Ana Romero

Vista previa del material en texto

Diagrama de Casos de uso
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el
sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan
(operaciones o casos de uso).
2.1 Actores
Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan
con el sistema que estamos construyendo de la misma forma.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar
actores estamos empezando a delimitar el sistema, y a definir su alcance. Se los identifica
por su Rol que alguien o algo juega cuando interactúa con el sistema para beneficiarse de
sus resultados
Los actores se representan con dibujos simplificados de personas, llamados en inglés “stick
man” (hombres de palo).
Identificar a los actores es el primer paso para usar la técnica de casos de uso. Es común
que los distintos actores coincidan con distintas áreas de la empresa en la que se
implementará el sistema, o con jerarquías dentro de la organización. Todos los actores
participan de los casos de uso. Ahora bien, es lógico que existan intersecciones entre lo que
hacen los distintos actores
¿Cómo identificar actores?
Candidatos:
● Clientes o potenciales clientes
● Socios
● Proveedores
● Autoridades
● Propietarios
● Sistemas de información externos al negocio
● Otras partes de la organización, si ésta es grande.
Consideraciones acerca de los actores:
● Todo lo que interacciona con el ambiente del sistema se modela con actores.
● Ingresan o retiran información del sistema.
● Cada actor humano expresa un rol, no una persona específica.
● Cada actor modela algo fuera del negocio.
● Cada actor se involucra con al menos un caso de uso.
● Cada actor tiene una descripción y un nombre que explica su rol en relación al
sistema.
A la búsqueda de Actores
● ¿Quién está interesado en un requerimiento concreto?
● ¿En qué dominios de la organización se usará el sistema?
● ¿Quién será beneficiario de la nueva funcionalidad?
● ¿Quién proveerá, usará o retirará información?
● ¿Quién dará soporte y administrará el sistema?
● ¿Usará el sistema un recurso externo?
● ¿Un usuario actuará con diferentes roles?
● ¿Diferentes usuarios actuarán con el mismo rol?
● ¿Interaccionará el nuevo sistema con un sistema antiguo?
2.2 Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo,
sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
El nombre de un caso de uso se expresa con un verbo en infinitivo o gerundio, seguido
generalmente por el principal objeto o entidad del sistema que es afectado por el caso.
Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su
interior. Es importante notar que el nombre del caso siempre está expresado desde el punto
de vista del actor y no desde el punto de vista del sistema.
Los casos de uso tienen las siguientes características:
1. Están expresados desde el punto de vista del actor.
2. Se documentan con texto informal.
3. Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa
con él, aunque el énfasis está puesto en la interacción.
4. Son iniciados por un único actor.
5. Están acotados al uso de una determinada funcionalidad –claramente diferenciada–
del sistema.
El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que
todo sistema tiene un único caso de uso Usando el Sistema. Sin embargo, la especificación
resultante sería de poco utilidad para entenderlo; sería como implementar un gran sistema
escribiendo un único programa.
En principio podríamos decir que la regla general es: una función del sistema es un caso de
uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función.
Los casos de uso se documentan con texto informal. En general, se usa una lista numerada
de los pasos que sigue el actor para interactuar con el sistema. A continuación se muestra
una parte simplificada de la descripción del caso de uso “Ingresando Pedido”.
Caso de Uso Ingresando Pedido
Actor: Empleado de Ventas
1) El cliente se comunica con la oficina de ventas, e informa su número de cliente
2) El oficial de ventas ingresa el número de cliente en el sistema
3) El sistema obtiene la información básica sobre el cliente
4) El cliente informa el producto que quiere comprar, indicando la cantidad
5) El sistema obtiene la información sobre el producto solicitado, y confirma su
disponibilidad.
6) Se repite el paso 4) hasta que el cliente no informa más productos
7) ...
¿Cómo identificar Casos de Uso?
A la búsqueda de Casos de Uso
● ¿Cuáles son las tareas y responsabilidades de cada actor?
● ¿Qué actores crearán, almacenarán, cambiarán borrarán o leerán esta información?
● ¿Qué Casos de uso crearán, almacenarán, cambiarán, borrarán o leerán esta
información?
● ¿Es necesario que un Actor sea informado sobre ciertas incidencias del sistema?
● ¿Es necesario que un Actor informe al sistema sobre cambios externos?
● ¿Qué casos de uso darán soporte y mantendrán el sistema?
● ¿Pueden ser realizados por los Casos de uso los requerimientos funcionales
documentados?
Consideraciones:
● Su nombre y descripción breve son claras y fáciles de comprender.
● Cada caso de uso del negocio es completo desde la perspectiva de un actor externo.
● Cada caso de uso del negocio normalmente se involucra con, al menos, un actor.
● Es posible que un caso de uso de apoyo no interactúe con ningún actor.
2.3 Relaciones
Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a
otra operación (caso de uso). Dicha relación se denota con una línea simple.
Existen dos tipos de especialización de esta relación
Composición
Inclusión
Un caso de uso base incorpora explícitamente el comportamiento de otro en algún
lugar de su secuencia. La relación de inclusión sirve para enriquecer un caso de uso
con otro y compartir una funcionalidad común entre varios casos de uso, también
puede utilizarse para estructurar un caso de uso describiendo sus subfunciones. El
caso de uso incluido existe únicamente con ese propósito, ya que no responde a un
objetivo de un actor. Estas relaciones se representan mediante una línea de puntos
con el estereotipo <<include>>
Extensión
Un caso de uso base incorpora implícitamente el comportamiento de otro caso de
uso en el lugar especificado indirectamente por este otro caso de uso. En el caso de
uso base, la extensión se hace en una serie de puntos concretos y previstos en el
momento del diseño, llamados puntos de extensión, los cuáles no son parte del flujo
principal. La relación de extensión sirve para modelar: la parte opcional del sistema,
un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que se
pueden insertar en un punto determinado. Este tipo de relación produce confusión y
no debería utilizarse en exceso. Conviene su uso sólo para insertar un nuevo
comportamiento no previsto en un caso de uso existente. Estas relaciones se
representan mediante una línea de puntos con el estereotipo <<extends>>
Generalización o Herencia
Este tipo de relación es uno de los más utilizados, la herencia nace como una forma de
organizar los enlaces entre actores y casos de uso a fin de simplificar los diagramas y
reducir la necesidad de presentar información repetida.
Mediante esta relación, el actor “hijo” puede hacer todo lo que hace el “padre”, y además
puede llegar a tener comportamiento propio.
En resumen:
Ya hemos visto la única relación posible entre un actor y un caso de uso: asociación.
También podemos establecer una única relación entre actores: generalización.
En UML podemos establecer tres relaciones entre casos de uso: generalización, inclusión y
extensión.
Ejemplo:
Como ejemplo está el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclaje de botellas, tarros y cajones de botellas y
tarros. El sistema debe controlar y/o aceptar:
● Registrarel número de ítems ingresados.
● Imprimir un recibo cuando el usuario lo solicita:
1. Describe lo depositado
2. El valor de cada ítem
3. Total
● El usuario/cliente presiona el botón de comienzo
● Existe un operador que desea saber lo siguiente:
1. Cuantos ítems han sido retornados en el día.
2. Al final de cada día el operador solicita un resumen de todo lo depositado en
el día.
● El operador debe además poder cambiar:
1. Información asociada a ítemes.
2. Dar una alarma en el caso de que:
i. Item se atora.
ii. No hay más papel.
Como una primera aproximación identificamos a los actores que interactúan con el sistema:
Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede cambiar la
información de un Item o bien puede Imprimir un informe:
Además podemos notar que un ítem puede ser una Botella, un Tarro o un Cajón de tarros y
botellas.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de
depositar algún ítem por un cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del diagrama Use Case es: