Contenido introducción 1



Descargar 278,91 Kb.
Página3/7
Fecha de conversión12.01.2017
Tamaño278,91 Kb.
1   2   3   4   5   6   7

Casos de Uso

Definiciones Básicas


Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso.

El nombre de un caso de uso se expresa con un verbo en 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.



Figura 3 – Los casos de uso se representan gráficamente con óvalos

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. Por eso el segundo caso de uso se llama Recibiendo información de pedidos y no Generando información de pedidos.

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.

La pregunta importante es: ¿Qué es una “funcionalidad claramente diferenciada”? Por ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos válidos para cualquiera de las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos. Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por esto se hace importante usar el sentido común en estas decisiones.

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. Por ejemplo, si uno quiere dar de alta un pedido, accederá a la funcionalidad de alta de pedidos del sistema. Sin embargo, si uno quiere dar de alta un campo del pedido, no debe indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un pedido es una función que forma parte de un caso de uso mayor: dar de alta un pedido.

Esta regla, si bien puede ser útil, no debe seguirse al pie de la letra, ya que se puede prestar a confusiones. Por ejemplo, supongamos que uno quiere especificar un sistema en el cual los usuarios pueden ver un pedido, y tienen disponibles funciones para ver el siguiente pedido, el anterior, el último y el primero. El actor debe indicar al sistema que quiere acceder a cada una de esas funciones, y según nuestra regla serían todas ellas casos de uso distintos. Sin embargo, en esta situación es mucho más práctico definir un único caso de uso navegando pedidos, que especificarlos todos como casos de uso distintos.

Cuando pensamos en el grado de detalle de la división de los casos de uso también resulta útil imaginar que uno está escribiendo el manual del usuario del sistema. A nadie se le ocurriría escribir un manual de usuario con un solo capítulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una especificación con un solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la cantidad de capítulos del manual es variable dependiendo de la persona que lo escriba.

Para dar una idea aproximada del nivel de detalle de la división de los casos de uso en casos menores, también podemos pensar que un trabajo práctico de Ingeniería del Software I debiera tener alrededor de 8 casos de uso primarios.


Descripción de los Casos de Uso


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

  1. El oficial de ventas ingresa el número de cliente en el sistema

  1. El sistema obtiene la información básica sobre el cliente

  1. El cliente informa el producto que quiere comprar, indicando la cantidad

  1. El sistema obtiene la información sobre el producto solicitado, y confirma su disponibilidad.

  1. Se repite el paso 4) hasta que el cliente no informa más productos

  1. ...

Figura 4 – Descripción simplificada del caso de uso “Ingresando Pedido”

Al describir los casos de uso aparece una de sus principales limitaciones. Supongamos que queremos describir un sistema en el cual la interacción con el usuario es muy simple: ingresa un conjunto básico de datos, y con esos datos el sistema realiza una gran cantidad de cálculos, aplicando complejas fórmulas. ¿Cómo hago con un caso de uso para especificar el comportamiento interno del sistema, si su comportamiento no es trivial? La respuesta es que los casos de uso son muy limitados para lograr este objetivo, ya que se basan en el uso de texto informal. Por lo tanto, deberemos usar una nueva notación para especificar este comportamiento interno, algo equivalente a los diagramas de flujo de datos del análisis estructurado. En UML se propone usar una notación llamada “Diagrama de Actividad”, el moderno heredero del diagrama de flujo, o “flowchart”.



Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de la descripción del caso, las decisiones e iteraciones. De esta forma, es común que en las descripciones de los casos se deba recurrir a frases como “Se repite el paso X hasta que ocurre C”, o “Si ocurre C se pasa al paso X”. En estas situaciones lo importante no es la forma en la que se expresan las condiciones e iteraciones, sino hacerlo de una forma consistente. Si la descripción del caso fuera muy compleja, es conveniente usar notaciones gráficas, por ejemplo los diagramas de actividad.
1   2   3   4   5   6   7


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal