lunes, 16 de diciembre de 2013

Casos de uso

¿Que es un caso de uso?
Según Wikipedia un caso de uso es una descripción de los pasos o las actividades que deberán realizar para llevar a cabo un proceso. Los personajes o entidades que participan en un caso de uso se denominan actores.
"Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa algunos de sus servicios",  según el manual de ingeniería de software 1.
Varios autores coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema, pero sin especificar el comportamiento interno del mismo.
Osea que para saber como realizar o armar un caso de uso de cualquier tipo, en cualquier ámbito, podemos utilizar lo que acabamos de definir como casos de uso.
Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema.

 Veamos algunos ejemplos de casos de uso:

En este caso se puede ver la relación que hay entre profesores, alumnos, administradores escolares, y la evaluación de los alumnos. 
El alumno está relacionado con el evaluador a través de un sistema de de certificación, que también involucra a un administrador y a un evaluador.

En este ultimo ejemplo vemos como es la relación de un cliente con un restaurante, y nos muestra como hacer un pedido o seleccionar un plato, la forma de pago, dar la dirección para la entrega, etc.


Y aquí tenemos otro ejemplo de como esta formado un caso de uso.



¿Para que sirven los diagramas de caso de uso?
Como lo dijimos anteriormente los diagramas de caso de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.

 Mas ejemplos de casos de uso.
- https://trac.inf.utfsm.cl/proyectos/JJ/wiki/Documentacion2

 ¿De donde provienen los casos de uso?

 Un poco de historia.
Los casos de uso fueron introducidos por Jacobson en 1992. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos precursores del análisis estructurado, sobre el cual publicaron un libro anteriormente.
En ese libro, se define un concepto muy parecido al de caso de uso: el EVENTO. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los limites del sistema, ante lo cual el sistema debe responder.

 Sin embargo existen algunas diferencias entre los casos de usos y los eventos. Los principales son:

  1. Los eventos se centran en describir que hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir como es el dialogo entre el usuario y el sistema.
  2. Los eventos son "atómicos": se recibe una entrada, se la procesa, y genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción entre el usuario y el sistema. De esta forma un caso de uso puede agrupar varios eventos.
  3. Para los eventos, lo importante es que datos ingresan o salen de el cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria.
Los casos de uso combinan el concepto de análisis con otra técnica de especificación de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo.


 Componentes de un caso de uso.

 A continuación veremos algunos de los componentes de los casos de uso.


Actores:
Un actor es una agrupación uniforme de personas, sistemas o maquinas que interactúan con el sistema que estamos construyendo. Por ejemplo, para una empresa que recibe pedidos de forma telefónica, todos los operadores que reciben pedidos y los ingresen en un sistema de ventas, si pueden hacer las misma cosas con el sistema son considerados como un único actor.
Los actores son representados con dibujos simplificados de personas llamados "stick-man".
Los actores son  externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos delimitando el sistema, y a definir su alcance.
Es necesario tener en claro la diferencia entre actor y usuario. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma un usuario puede acceder al sistema como distintos actores. La forma mas simple de entender esto es la de pensar en un perfil de usuario cuando accedemos a un sistema operativo.
Otro sistema que también interactua con el que estamos construyendo también es un actor.
También puede ocurrir que el actor sea una maquina, en el caso de que el software sea operado por una maquina o controle sus movimientos.  
Identificar a los actores es el primer paso en la utilización de la técnica de casos de uso.
Es común que los distintos actores coincidan en distintas áreas de la empresa en la que se implementara el sistema, o con distintas jerarquías dentro de la organización. Todos los actores participan de los casos de uso.

Casos de uso.
Como dijimos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y algo o alguien que hace uso 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 del caso de uso.
El nombre de un caso de uso se expresa con un verbo, seguido por el principal objeto o entidad que es afectado por el caso. Gráficamente el caso de uso es representado por un ovalo, con el nombre de caso de uso en su interior.
Es importante notar que el nombre del caso de uso siempre está expresado desde el punto de vista del actor, y no 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 interactua con el, 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.
Es importante notar que el nombre del caso de uso está expresado desde el punto de vista del actor, y no desde el punto de vista del sistema.
El último caso es el más difícil de definir. Uno podría, después de todo, decir que todo el sistema tiene un único caso de uso Usando el sistema. Sin embargo, la especificación resultante seria de poca utilidad para entenderlo, seria como implementar  un gran sistema escribiendo un único programa.
La pregunta importante es:¿que es una funcionalidad claramente definido?. Por ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlo es otro?¿cancelar los pedidos es un caso de uso, o es parte del caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos validos para cualquiera de los dos casos, en principio la respuesta a todas estas preguntas es que son todos los 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.

Descripción de los casos de uso.

 Los casos de uso se documentan con lenguaje informal. En general, se usa una lista numerada de los pasos que sigue el actor para actuar con el sistema. A continuación veremos un ejemplo:

 Caso de uso: Ingresando pedido
Actor: empleado de ventas

  1. el cliente se comunica con la ofician e indica su número de cliente.
  2. El oficial de ventas ingresa el numero 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 informar, 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.
Al describir los casos de uso aparece una de sus principales limitaciones. ¿Como hago con un caso de uso para explicar el comportamiento interno de un 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.
Otra de las limitaciones de los casos de usos es que no hay sintaxis clara para indicar, dentro de la descripción del caso de uso, las decisiones o interacciones. De esta forma, es común que en las descripciones se deba recurrir a frases como "se repite el paso X". En estas situaciones lo importante no es la forma en la que se expresan las condiciones e interacciones, sino hacerlo de una forma consistente.

 Alternativas.

 Durante la ejecución de un caso de uso suele haber errores o excepciones. El sistema deberá en estos casos informar la situación al usuario que ingresa el pedido. Estas desviaciones del curso normal del caso de uso se llaman alternativas. Las alternativas tienen las siguientes  características.
  1. Representan un error o excepción en el uso normal del caso de uso.
  2. No tiene sentido por si misma, fuera del contexto del caso de uso en el que ocurran.
Si bien en la bibliográfica las alternativas se documentan al final del caso de uso,la experiencia demuestra que resulta útil documentar los casos en tablas, mostrando el curso principal en la primera columna, y las alternativas en una segunda columna.
De esta manera es más fácil leer en que parte del caso de uso puede ocurrir la excepción, y se mantiene la ventaja de poder leer cual hubiese sido el recorrido normal del caso de uso.

Relaciones.

 Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de usos.¿Como hago para no repetir el texto de esta funcionalidad en todos los casos de uso que la accedan? La respuesta es simple: sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de los cuales fue sacado. Este tipo de relaciones se llama relaciones de uso
y se representa por una linea punteada desde el caso que "usa" al caso que es "usado".
Este concepto no es novedoso, es simplemente el concepto de la subrutina o subprograma usado en un nivel más alto de abstracción.
Las características de las relaciones son:

  1. Aparecen como funcionalidad común, luego de haber especificado varios casos de uso.
  2. Los casos usados son casos de uso en si.
  3. El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca las diferencias con las extensiones que son opcionales.


 Tipos de relaciones:
  • Comunica: relación o asociación entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.
  • Usa: relación de dependencia entre dos casos de uso que denota la inclusión de un comportamiento de un escenario en otro.
  • Extiende: relación de dependencia entre dos casos de uso que denota que un caso de uso es una extensión del otro

El proceso de análisis de requerimientos para casos de uso.

 1- Identificar los actores.

 Si la primera pregunta que debe hacer un analista a sus usuarios es ¿para que es este sistema? La segunda es claramente ¿para quienes es este sistema? Como mencionamos anteriormente a los actores, es primordial también identificarlos,  para buen buen análisis de requerimientos. Por eso antes de avanzar en los casos de uso debemos identificar a todos los tipos de usuarios diferentes que tiene el sistema.

Si el sistema funcionara en una empresa, debo preguntar cuales de las áreas afectadas usaran o actualizaran la información.
A pesar de hacer una identificación inicial de los usuarios, siempre es conveniente repetirla a medida que se va desarrollando el sistema, ya que al aparecer nuevos casos de usos pueden aparecer nuevos tipos de usuarios.

2- Identificar los casos de uso de cada actor.

El siguiente paso es identificar los nombres de los principales casos de uso de los actores que identifique en el paso anterior. No es necesario identificar cuales son las acciones dentro del caso de uso. Tampoco debo preocuparme sino aparecen muchas casos de uso, ya que existen técnicas para identificar nuevos casos de uso a partir de los existentes.

3- Identificar nuevos casos de uso a partir de los existentes.

Uno de los principales errores que se puede cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre:!olvidarse de algunos requerimientos¡ Como los requerimientos están en la cabeza de los usuarios, el éxito de esta tarea depende la habilidad de el analista. Para ayudarnos a identificar nuevos casos de uso a partir de los existentes,podemos utilizar la misma técnica para identificar los eventos según el análisis estructurado. Esta técnica se basa en el análisis de cuatro situaciones posibles a partir de los requerimientos ya establecidos.


4-Casos de usos "Opuestos".

Hay dos formas de buscar casos de usos "opuestos". La primera es buscar la función opuesta a la descrita por el caso. Por ejemplo, en el caso de realizar un pedido, la función opuesta es cancelar ese pedido. Si cancelar pedidos es una función que mi sistema debe realizar, y que no había identificado anteriormente, acabo de evitar un error que puede ser muy costoso de corregir más adelante.
La otra forma de buscar casos de uso opuestos, es pensar en la negación de la acción del caso de uso. Supongamos que tenemos un caso de uso "Pagando pedido", que es realizado por el actor cliente. El caso de uso "no pagando pedido", puede ser significativo.Si el cliente no paga el pedido, tal vez nuestro sistema deba hacer algo, y podamos estar frente a un nuevo caso de uso.

5-Casos de uso que preceden a casos existentes.

Una buena pregunta para hacer frente a un caso de uso es:
¿Que es lo que tiene que ocurrir antes de este caso de uso?
Analizando las respuestas podemos deducir que actores están involucrados en este caso de uso, o cuales son las funciones que se deben ver involucradas.


6-Casos de uso que suceden a casos existentes.

Este punto es similar al anterior: La pregunta que debemos hacer es:
¿Que ocurre después de este caso de uso?
En este caso podemos deducir, de la misma forma que en el caso anterior, casos de uso y los actores que están involucrados.

7- Crear descripciones de caso de uso.

Una vez identificados todos los casos de uso, comenzamos a documentar sus pasos. Esta tarea no es estrictamente secuencial de la anterior: es posible que mientras empezamos a documentar los casos sigamos buscando otros nuevos.

8- Definir prioridades y seleccionar casos.

Una vez definidos los casos, es conveniente definir las prioridades de los distintos requerimientos, expresados como casos de uso. Para esto suele ser útil usar tres categorías: 
  • imprescindible
  • importante
  • deseable
Los requerimientos imprescindibles son aquellos que, si no se implementan, el sistema no funcione bien.
Los importantes son aquellos que harían que el usuario se sienta decepcionado sino se implementan.
Los deseables son aquellos que el usuario desearía tener, si tuviera mas tiempo disponible.
Al evaluar un requerimiento también debe analizar su costo o complejidad.
Una vez hecha esta categorización de los requerimientos, puede tomar como estrategia general el incluir los requerimientos imprescindibles, discutir los importantes y descartar los deseables a menos que sean de bajo costo. Por lo dicho anteriormente, esta regla también cumple con la regla de ser relativa pues debo analizar su costo, complejidad y una cantidad de otros factores antes de decidir su inclusión.



9 - Organización de la especificación.

A continuación discutiremos la mejor forma de organizar una especificación de requerimientos en la que se utiliza la técnica de casos de uso.


Gráficos a utilizar.

Dependiendo del tamaño del sistema, es probable que un solo gráfico con todos los casos de uso nos quede chico. No olvidemos que los casos de uso son solo para aclarar el texto, y no para confundir. Si el gráfico de casos de uso es una maraña indescifrable, no está cumpliendo su objetivo. Por lo tanto, podemos utilizar las siguientes reglas, como siempre con criterio y sentido común.
  1. Un gráfico no debe mostrar más de 15 casos de uso.
  2. Si debo particionar mi gráfico, puedo hacerlo por actor. La primera partición debe separar los casos centrales de los casos auxiliares, ya que probablemente le interese a personas diferentes.
  3. Si las relaciones de uso y las extensiones entran en el diagrama principal, sin dejar de cumplir con la regla 1, debo dejarlas ahí.
  4. Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en  gráfico  teniendo en cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un mismo diagrama.
  5. Si tengo un caso de uso, que es usado por gran parte de los otros casos, debo evitar mostrarlo en el gráfico principal, ya que las flechas serán imposibles de organizar. Es probable que no haga falta mostrar esta relación de uso en un gráfico.

Secciones de la especificación.

 Sugerimos el siguiente orden para una especificación de requerimientos utilizados en casos de uso:

  1. Propósito del sistema. Un breve párrafo, de 4 o 5 lineas, que responda a la pregunta: ¿Para que estamos haciendo este sistema?
  2. Gráficos de casos de uso.
  3. Descripción de los casos de uso con su alternativa.
  4. Prototipos para los principales casos de uso.


FUENTES:










Publicado por en No hay comentarios:
Suscribirse a: Entradas (Atom)