Contenido introducción 1



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

Tipos de Casos de Uso


A partir de la aplicación de los casos de uso en la práctica, aparecen distintas clasificaciones, que son útiles según el tipo de sistema o el modelo de ciclo de vida utilizado.
    1. Esenciales o de Trazo Grueso vs. de Implementación o de Trazo Fino


Uno de los modelos de ciclo de vida de desarrollo de sistemas que más popularidad ha ganado en los últimos años es el llamado “modelo incremental”, en el cual se van entregando versiones parciales del sistema, que implementan una parte de su funcionalidad. La recomendación en este caso pasa siempre por identificar todos los requerimientos que uno pueda, definir sus prioridades, y seleccionar cuáles se van a ir implementado en cada versión. Sin embargo, no se pueden especificar en detalle todos los requerimientos: debemos tener apenas el nivel de detalle suficiente para poder definir sus prioridades y comprenderlos en términos generales.

Para aplicar los casos de uso a desarrollos incrementales, empezamos por identificar todos los casos de uso del sistema, sólo al nivel de su nombre. Una vez que los identificamos, los expresamos en “trazo grueso”, esto es:



  • Ignoramos detalles sobre la forma de la interacción entre el actor y el sistema.

  • Sólo incluimos las alternativas más relevantes, ignorando la mayoría de los errores que aparecen en el uso del sistema.

  • No entramos en detalle sobre las acciones que realiza el sistema cuando el usuario interactúa con él. Por ejemplo, si la empresa tuviera una política de descuentos para sus clientes, no es necesario especificar cómo es esa política: nos alcanza con saber que existe una y que debe ser tenida en cuenta.

De esta forma, terminamos con una descripción “gruesa” de todos los casos de uso. Esto me sirve para tomar mejores decisiones, junto con los usuarios, sobre qué casos de uso implementar en cada fase. Por otro lado, permite analizar los principales aspectos de todos los casos que afectan al diseño.

Los casos de uso de trazo fino son aquellos que se especifican una vez que se ha tomado la decisión de implementarlos. En este momento debemos completar todos los detalles que dejamos pasar:



  • A medida que vamos haciendo prototipos de las interfaces con los usuarios, incluimos detalles sobre la forma de la interfaz en la descripción del caso. Por ejemplo, podemos incluir detalles como: “el operador puede en cualquier momento pasar de la ventana de datos del cliente a la ventana de datos del pedido”. Si bien esto implica anticiparse al diseño, esto no es negativo, ya que es prácticamente imposible –y perjudicial– hablar con los usuarios siempre en términos de un sistema abstracto.

  • Incluimos otras alternativas. En particular especificamos todos los errores o excepciones que provienen de requerimientos de los usuarios. Para esto debemos tener en cuenta que un sistema tiene dos tipos de errores o excepciones: las que provienen de las definiciones del negocio y las que provienen del procesamiento interno del sistema. Por ejemplo, pensemos en un requerimiento del tipo: “si un cliente hace un pedido por un monto mayor al autorizado, se debe rechazar el pedido”. Esta excepción es claramente un requerimiento, y debe ser incluida en las alternativas de los casos de uso. Por el contrario, una excepción del tipo: “Si el usuario ingresa una letra en el lugar del código del producto se le informa que el código de producto debe ser numérico” no debe ser incluida en esta etapa del análisis.

  • Especificamos con más detalle el comportamiento interno del sistema. En nuestro ejemplo de los descuentos, deberíamos especificar cómo es esa política, en un nivel de detalle suficiente para luego poder diseñar una forma de implementarla dentro del sistema.
    1. Casos de Uso Temporales


Los casos de uso tienen un actor que los inicia, y uno o más actores que participan de él. En muchos casos, el inicio de una determinada funcionalidad del sistema es provocado exclusivamente por el paso del tiempo. Supongamos que nuestro sistema de ventas debe generar en forma automática un conjunto de estadísticas para ser entregadas al directorio de la empresa el último día hábil de cada mes. En este caso, el paso del tiempo es el que inicia el caso de uso, y el directorio es el actor del sistema. Sin embargo, para expresar claramente que es el paso del tiempo el que inicia el caso, podemos incluir un símbolo representando un reloj en el gráfico de casos de uso, o usar una línea punteada en el borde del óvalo del caso.



Figura 11 – Un caso de uso temporal

Es importante que cuando se especifican los casos de uso de trazo fino, se exprese claramente cuál es el momento del tiempo en el que se inicia el caso. Es común que se indiquen cosas como “una vez al mes” cuando se habla de casos iniciados por el paso del tiempo. Cuando hacemos los casos de trazo fino, debemos precisar en qué momento del mes eso ocurre (el primer día hábil, el primer día calendario, el último día hábil, etc.). De lo contrario, estamos dejando en los diseñadores la decisión sobre cuándo generar esta salida, y esto no es correcto, ya que la oportunidad de las salidas del sistema debe ser definida por los usuarios.


    1. Casos Primarios Vs. Casos Secundarios


Jacobson hace referencia a la diferencia entre los casos de uso primarios del sistema y aquellos que no se corresponden con procesos del negocio y cuya ejecución sólo es necesaria para que el sistema funcione normalmente.

Supongamos que nuestro sistema requiere de un proceso de depuración de los pedidos que ya han sido cumplidos hace más de 5 años, para evitar que se acumulen indefinidamente. El caso de uso por el cual se depuran estos pedidos, cuyo actor es un Administrador del Sistema, es considerado un caso secundario, ya que no es central al sistema, sino que es necesario para que el sistema pueda funcionar sin problemas. En la experiencia se ve que no todos los casos de uso secundarios se pueden identificar en la etapa de requerimientos, ya que muchos de ellos dependen de decisiones de implementación que se toman en la etapa de diseño. De todas formas, los casos de uso pueden ser actualizados a medida que progresa el desarrollo del sistema, ya que al estar expresados desde el punto de vista del usuario, son una excelente base para construir del manual de usuario.


  1. El Proceso de Análisis de Requerimientos con Casos de Uso


Esta sección describe los pasos a seguir para aplicar la técnica de análisis de requerimientos con casos de uso.
    1. Identificar los Actores


Si la primera pregunta que un analista debe hacer a sus usuarios es ¿Para qué es este sistema?, la segunda es claramente ¿Para quiénes es este sistema? Como mencionamos al hablar sobre los actores, identificar a todos ellos es crítico para un buen análisis de requerimientos. Por lo tanto, antes de avanzar con los casos de uso, debo tratar de identificar todos los tipos de usuario diferentes que tiene el sistema. Si el sistema funcionará en una empresa, debo preguntar cuáles de las áreas afectadas usarán o actualizarán su información.

A pesar de hacer una identificación inicial de los actores, también debo repetirla a medida que empiezo a describir los casos de uso, ya que al conocer más detalles del sistema pueden aparecer nuevos tipos de usuarios.


    1. Identificar los Principales Casos de uso de Cada Actor


El siguiente paso es enunciar los nombres de los principales casos de uso de cada uno de los actores que identifiqué en el paso anterior. No es necesario especificar cuáles son las acciones dentro del caso de uso. Tampoco debo preocuparme si no aparecen muchos casos, ya que existen técnicas para encontrar nuevos casos de uso a partir de los existentes.
    1. Identificar Nuevos Casos a Partir de los Existentes


Uno de los principales errores que se pueden cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre: ¡olvidarse de algún requerimiento! Como los requerimientos están en la cabeza de los usuarios, el éxito de esta tarea depende de la habilidad del analista. Para ayudarnos a identificar nuevos casos de uso a partir de los casos existentes, podemos aplicar las mismas técnicas utilizadas para identificar 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 identificados.

Variaciones Significativas de Casos de Uso Existentes


Muchas veces existen variaciones en los casos de uso en función del actor que los ejecuta, o del tipo de objeto sobre el que se apliquen. Por ejemplo, en el caso del sistema que procesa pedidos, podemos hacernos las siguientes preguntas:

  1. ¿Existen distintos tipos de cliente que hagan pedidos?

  2. ¿Existen distintos tipos de pedidos, que lleven a acciones distintas por parte del sistema?

Asumiendo que la respuesta a la primera pregunta es si, lo próximo que debemos preguntarnos es si el sistema ejecuta acciones distintas en función del tipo de cliente. Tal vez la respuesta sea que existen clientes locales y clientes del exterior, y que en estos dos casos el procesamiento es totalmente diferente, ya que los pedidos del exterior deben ser procesados por le Gerencia de Comercio Exterior. Tal vez estemos frente a un nuevo caso de uso, “Ingresando Pedido de Cliente del Exterior”, que es distinto del caso de uso “Ingresando Pedido de Cliente Local”. Tal vez tengamos dudas sobre si estos son dos casos de uso o uno solo, porque el proceso puede tener puntos en común y puntos que los distinguen. En esta última situación me veo obligado a usar nuevamente el sentido común. Tal vez aplicando la modularización de casos de uso a través de las relaciones de uso, puedo factorizar la funcionalidad común y expresar claramente, incluso gráficamente, la funcionalidad que los distingue.

Por supuesto que si la respuesta a la primera pregunta es no, estamos en el caso en que no vamos a encontrar un nuevo caso de uso a partir de este análisis.

Supongamos ahora que la respuesta a la segunda pregunta es sí. En este caso, nuevamente podemos encontrar un nuevo caso de uso. Por ejemplo, podemos encontrar que hay muchas diferencias entre el procesamiento de pedidos de ciertos tipos de productos. En este caso, nuevamente debemos decidir si la funcionalidad diferenciada es lo suficientemente relevante como para especificar un nuevo caso. Para hacer este análisis, debemos tener en cuenta lo siguiente:


  1. Si especificamos dos casos de uso similares como un único caso de uso, en el texto del caso tendremos muchos “Si pasa X, hago A, si no, hago B”. Este hace un poco más difícil de seguir la especificación.

  2. Si especifico dos casos de uso con funcionalidad en común como dos casos de uso distintos, la relación de uso me puede ayudar a evitar la redundancia.

De todas formas, no debo llevar estas reglas al extremo, como por ejemplo buscar que todos los casos sean lineales (sin decisiones), ya que de esta forma lo único que voy a conseguir es una maraña incomprensible de casos de uso.

Casos de Uso “Opuestos”


Hay dos formas de buscar casos de uso opuestos. La primera es buscar la función opuesta a la descrita por el caso. Por ejemplo, en el caso de realizar un pedido, podemos pensar que la función opuesta es cancelar ese mismo pedido. Si cancelar pedidos es una función que mi sistema debe realizar, y que no había identificado anteriormente, acabo de evitarme 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 principal del caso de uso. Supongamos que tenemos un caso de uso “Pagando Pedido”, que es realizado por el actor cliente. El caso “No Pagando Pedido”, puede de nuevo ser significativo. Si el cliente no paga el pedido, tal vez nuestro sistema deba hacer algo, y podemos estar frente a un nuevo caso de uso.


Casos de Uso que Preceden a Casos Existentes


Una buena pregunta para hacer frente a un caso de uso es:

¿Qué es lo que tiene que ocurrir antes de este caso de uso?

En el caso del cliente que hace un pedido, son muchas las cosas que pueden ocurrir antes de ese caso:


  1. El cliente, por ejemplo, debe ser cliente. En esta situación tal vez tenga un nuevo caso de uso “Ingresando Cliente”, que puede o no ser un caso de mi sistema.

  2. El cliente debe poder consultar cuáles son los productos existentes. Probablemente este sea un caso de uso que ya haya sido identificado. Sin embargo, usando esta técnica muchas veces se descubren nuevos requerimientos.

Casos de Uso que Suceden a Casos Existentes


Esto es similar al punto anterior. La pregunta que debo hacerme es:

¿Qué ocurre después de este caso de uso?

En nuestro ejemplo de los pedidos, es evidente que la mayoría de la funcionalidad de nuestro sistema recién empieza cuando el cliente hace un pedido. Por lo tanto, analizar “cómo sigue la historia” es una buena forma de asegurarme que no estoy dejando requerimientos sin identificar.

    1. Crear Descripciones de Casos de Uso de Trazo Grueso


Una vez que identificamos todos los casos de uso, empezamos 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.

La documentación de los casos de uso identificados debe hacerse del tipo “trazo grueso”, salvo que sea un caso de uso que deba implementarse sí o sí en la primera iteración.


    1. Definir Prioridades y Seleccionar Casos de la Primera Iteración


Una vez documentados los casos de trazo grueso, 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 y deseable.

  • Los requerimientos imprescindibles son aquellos que, si no se implementan, hacen que el sistema no tenga sentido.

  • Los importantes son aquellos que harían que el usuario se sienta decepcionado si no se implementan.

  • Los deseables son aquellos que el usuario querría tener, si hubiese tiempo disponible.

Al evaluar un requerimiento debo también analizar su costo o complejidad.

Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los imprescindibles, discutir los importantes y descartar los deseables cuyo costo no sea bajo. 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. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable.


    1. Escribir los Casos de Trazo Fino y Crear Prototipos de Interfaces


Una vez seleccionados los casos de uso que pienso implementar en la primera iteración, empiezo a profundizar sus definiciones. Al mismo tiempo, suele ser una excelente idea crear un prototipo visual de la implementación de los casos. Con las herramientas existentes actualmente, esto es muy simple de hacer, y nos puede evitar muchos problemas.

Cuando creamos prototipos de la implementación de los casos de uso, debemos tener en cuenta que:



  1. Estos son prototipos para descartar: si incluimos algo de código en el prototipo, debe ser descartado o revisado con mucho cuidado si se lo piensa mantener.

  2. Estamos intentando validar el estilo de la interacción, no toda la interacción: no debemos dejarnos llevar por el entusiasmo. Si tenemos varios casos de uso que realizan funciones similares, o con una interfaz similar, puede alcanzar con crear un prototipo de sólo una de ellas. Queremos que el usuario se dé una idea sobre cómo se verá el sistema, no que nos apruebe todas sus pantallas y listados.
  1. Organización de la Especificación


En esta sección discutimos la mejor forma de organizar una especificación de requerimientos en la que se aplicó la técnica de casos de uso.
    1. Gráficos a Utilizar


Dependiendo del tamaño del sistema, es probable que un único gráfico con todos los casos de uso nos quede chico. No olvidemos que los modelos gráficos son 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 usar las siguientes reglas, como siempre con criterio y sentido común:

  1. Un gráfico de casos de uso no debe mostrar más de 15 casos

  2. Si debo particionar mi gráfico, puedo hacerlo por actor. La primera partición debe ser separar los casos centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas.

  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í. Lo mismo se aplica a los actores abstractos.

  4. Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en gráficos 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, como por ejemplo el caso de uso Identificándose ante el sistema, 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.
    1. Secciones de la especificación


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

  1. Propósito del sistema: un breve párrafo, de 4 o 5 líneas, que responde a la pregunta ¿Para qué estamos haciendo este sistema?

  2. Gráfico(s) de casos de uso

  3. Descripción de los casos con sus alternativas

  4. Prototipos para los principales casos de uso

Esta no es obviamente una especificación de requerimientos completa: estamos incluyendo sólo la parte referida a los casos de uso.
  1. Bibliografía




[Brooks87]


Frederik P. Brooks - No Silver Bullet. Essence and Accidents in Software Engineering. IEEE Computer. Abril 1987.

[Jacobson92]

Ivar Jacobson y otros. Object Oriented Software Engineering. A Use Case Driven Approach. Addison Wesley, 1992.

[McMenamin84]

Steve Mc. Menamin y John Palmer. Essential Systems Analysis. Prentice Hall, Yourdon Press, 1984.



Cátedra de Ingeniería del Software I Pág.
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