miércoles, 27 de noviembre de 2013

Introducción a los casos de uso - Parte 1 de 2





Ahora que ha visto lo correspondiente a las clases y sus relaciones, es el momento de volver nuestra atención a otra área principal del UML: los casos de uso.

En esta hora se tratarán los siguientes temas:
  • Qué son los casos de uso
  • Importancia de los casos de uso
  • Inclusión de los casos de uso
  • Extensión de los casos de uso
  • Inicio de un análisis de un caso de uso
En las tres horas anteriores hemos visto los diagramas que proporcionan una idea estática de las clases en un sistema. Ahora veremos a los diagramas que establecen una idea dinámica y mostraremos la forma en que el sistema y sus clases cambian con el tiempo. Las ideas estáticas ayudan a que un analista se comunique con un cliente. La idea dinámica, como verá, ayudará al analista a comunicarse con un grupo de desarrolladores, y ayudará a estos últimos a crear programas.

El cliente y el equipo de desarrollo conforman un importante conjunto de integrantes en un sistema. No obstante, una parte de igual importancia no se ha tomado en cuenta: el usuario. Ni la idea estática ni la dinámica mostrarán el comportamiento del sistema desde el punto de vista del usuario. Comprender tal punto de vista es clave para generar sistemas que sean tanto útiles como funcionales; esto es, que cumplan con los requerimientos y que sea fácil (e, incluso, divertido) trabajar con ellos.

El modelado de un sistema desde el punto de vista de un usuario es el trabajo de los casos de uso. En esta hora comprenderá todo lo relacionado con los casos de uso y su función. En la siguiente hora aprenderá a utilizar el diagrama de casos de uso del UML para visualizar un caso de uso.


Qué son los casos de uso

Recientemente adquirí una máquina de fax. Cuando fui a comprarla, en un almacén de venta de equipo para oficinas, encontré una enorme gama de opciones. ¿Cómo hice para decidirme por una en particular? Me pregunté exactamente qué es lo que deseaba hacer con una máquina de fax. ¿Qué características deseaba? ¿Cuáles funciones necesitaba que tuviera? ¿Deseaba utilizar papel común o térmico? ¿Quería generar copias? ¿Conectarlo a mi computadora? ¿Utilizarlo como digitalizador? ¿Tendría que enviar faxes a tal velocidad que necesitaría una función de marcado rápido? ¿Querría utilizar la máquina de fax para diferenciar entre una llamada telefónica y un fax entrante?

Todos seguimos un procedimiento como éste cuando realizamos una compra que no sea impulsiva. Lo que hacemos es seguir un tipo de análisis del caso de uso: nos preguntamos cómo utilizaremos el producto o sistema que queremos comprar, de modo que podamos obtener algo que cumpla con nuestras necesidades. Lo importante es saber cuáles son esos requerimientos.

Este tipo de análisis es particularmente crucial para la fase de análisis del desarrollo de un sistema. La forma en que los usuarios utilicen un sistema le da la pauta para lo que diseñará y creará.

El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usará un sistema. Con una colección de casos de uso se puede hacer el bosquejo de un sistema en términos de lo que los usuarios intenten hacer con él.

Imagínese al caso de uso como una colección de situaciones respecto al uso de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo. A las entidades que inician secuencias se les conoce como actores. El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inició, o por otro actor.


Importancia de los casos de uso

Así como el diagrama de clases es un buen medio para estimular a un cliente a que hable respecto a un sistema desde su propio punto de vista, el caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde sus propios puntos de vista. No siempre es fácil para los usuarios explicar cómo pretenden utilizar un sistema. Puesto que el desarrollo tradicional de los sistemas era, con frecuencia, algo así como una ciencia oculta, con muy poca información para los usuarios, a aquellos que osaban preguntar se les daba información muy poco explícita o ciertamente confusa respecto a lo que utilizarían.

La idea es involucrar a los usuarios en las etapas iniciales del análisis y diseño del sistema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que supuestamente ayudará, en lugar de ser un manojo de expresiones de computación incomprensibles e inmanejables por los usuarios finales.


Un ejemplo: la maquina de gaseosas

Suponga que empezará a diseñar una máquina despachadora de gaseosas. Para obtener el punto de vista del interesado, entrevistará a varios usuarios potenciales respecto a la manera en que utilizarán dicha máquina.

Dado que la función principal de una máquina de gaseosas es permitir a un cliente adquirir una lata de gaseosa, probablemente las personas le dirán que se enfrentará a diversos escenarios -un caso de uso, en otras palabras- que podría etiquetar como “Comprar gaseosa”. Examinemos cada posible escenario en este caso de uso. Recuerde que tales escenarios podrían aparecer durante la conversación con los usuarios.

Un caso de uso establece un conjunto de escenarios para realizar algo útil para un actor. En este ejemplo, un caso de uso es “Comprar gaseosa".

El caso de uso "Comprar gaseosa"

El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El escenario iniciará cuando el cliente inserte dinero, posteriormente realizará una selección; y si todo funciona bien, la máquina contará con, al menos, una lata de la gaseosa elegida, misma que pondrá al alcance del cliente.

Además de la secuencia, hay otros aspectos del escenario anterior que merecen cierta consideración. ¿Qué condiciones llevaron al cliente a iniciar el escenario en el caso de uso “Comprar gaseosa"? La sed es la más obvia. ¿Qué se obtiene como resultado de tal escenario? Nuevamente, lo obvio es que el cliente tenga una gaseosa en su poder.

¿Lo que he descrito es la única posibilidad de “Comprar gaseosa”? Habría otras cuestiones que saltarían a la vista; por ejemplo, es posible que la máquina no tenga la gaseosa que desee el cliente; también es posible que el cliente no tenga el importe exacto de la gaseosa. ¿Cómo diseñaría a la máquina de gaseosas para controlar tales escenarios?

Veamos el caso en que la máquina se haya quedado sin gaseosa, otra secuencia de pasos en el caso de uso “Comprar gaseosa”. Imagínelo como una ruta alternativa dentro del caso de uso. El cliente inicia el caso de uso al insertar dinero en la máquina y posteriormente hace una selección. La máquina no cuenta con ninguna lata de la gaseosa seleccionada, por lo que mostrará un mensaje al cliente que indicará que no tiene de esa marca. Lo ideal sería que el mensaje le pida al cliente que haga otra selección. La máquina también debería dar la opción de devolver el dinero al cliente. En este punto, el cliente selecciona otra marca que la maquina entregará (siempre y cuando cuente con provisiones de esta marca), o devolverá el dinero. La condición previa es un cliente sediento y el resultado es una lata de gaseosa o la devolución del dinero.

Claro que el escenario de quedarse sin gaseosa sería posible: el mensaje "No hay de esta marca" podría aparecer en cuanto las provisiones de la máquina se acabaran y permanecer a la vista hasta que la máquina sea reabastecida. En tal caso, el usuario podría no insertar el dinero en primera instancia. El cliente para el que usted diseñará la máquina podría preferir el primer escenario: si el cliente ya insertó dinero, la tendencia podría ser hacer otra selección en lugar de pedir a la máquina que lo devuelva.

Analicemos ahora el escenario de la cantidad de dinero incorrecta. Nuevamente, el usuario inicia el caso de uso en la forma usual y posteriormente hace una selección. Asumamos que la máquina tiene provisión de la marca elegida. En la máquina hay una reserva de moneda fraccionaria y devuelve la diferencia al despachar la gaseosa. Si la máquina no cuenta con una reserva de moneda fraccionaria, devolverá el dinero y mostrará un mensaje que pida al usuario el importe exacto. La condición previa es la ya indicada. El resultado será una lata de gaseosa junto con el cambio, o la devolución del dinero originalmente depositado.

Otra posibilidad es que tan pronto como se agote la moneda fraccionaria, aparezca un mensaje que informe a los clientes que se requiere el importe exacto. El mensaje permanecería a la vista hasta que la máquina sea reabastecida con moneda fraccionaria.


Espero haber ayudado en algo. Hasta la próxima oportunidad!





No hay comentarios:

Publicar un comentario

       
free counters

Páginas vistas en total según Google