Modelo de requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecer desde la perspectiva del usuario. Este modelo puede trabajar como un contrato entre el desarrollador y el cliente, o usuario del sistema, por lo que deber proyectar lo que el cliente desea segn la percepcin del desarrollador. Por ello, es esencial que os clientes lo comprendan. El modelo de requisitos es el primero en desarrollarse, y es la base para formar todos los dems modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es ms fcil de hacer, y con menores consecuencias a este nivel que posteriormente. El modelo de requisitos que se desarrollar se basa en la metodologa Objectoy (Jacobson et al. 1992), que tiene su fundamento en el modelo de casos de uso. Actualmente esta metodologa es parte del Proceso unificado racional (RUP) [Rational Unified Process].l El modelo de casos de uso y el propio modelo de requisitos son la base para los dems modelos. A continuacin se repasarn los conceptos detallados en el captulo 3, que nos servirn en esta seccin: Requisitos: El modelo de caso de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver ms adelante. Anlisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de anlisis, que es estable con respecto a cambios, lo que lo hace un modelo lgico independiente del ambiente de implementacin. Diseo: La funcionalidad de los casos de uso, ya estructurada por el anlisis, la realiza el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms. Implementacin: Los casos de uso se instrumentan mediante el cdigo fuente en el modelo de implementacin. Pruebas: Los casos de uso se comprueban a travs de las pruebas de componentes y de integracin. Documentacin: El modelo de casos de uso se debe registrar a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, de administracin, etctera.

EI diagrama de la figura 6.1 ilustra los distintos modelos, los detalles y la notacin que se describirn ms adelante.

OK class OK falla Modelo de documentacio Figura 6.1 Dependencia de los distintos modelos de proceso de software del modelo n de casos de uso. Modelo de requisitos Modelo de analisis Modelo de diseo Modelo de implementacion Modelo de pruebas El propsito del modelo de requisitos es comprender en su totalidad el problema y sus implicaciones. Los dems modelos, anlisis, diseo, implementacin y pruebas dependen directa o indirectamente del modelo de requisitos. Asimismo, este modelo sirve de base para el desarrollo de las instrucciones operacionales y los manuales, ya que todo lo que el sistema deba hacer se describe aqu desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecnico, el analista debe interactuar constantemente con el cliente para completar la informacin faltante, y as resolver ambigedades e inconsistencias. Tambin debe separar los requisitos verdaderos de las decisiones relacionarlas con el diseo e implementacin. Se deben indicar cules aspectos son obligatorios y cules opcionales para evitar que se limite la flexibilidad de la implementacin. Durante el diseo, se debe extender el modelo de requisitos con las especificaciones de rendimiento y los protocolos de interaccin para los sistemas externos, al igual que las provisiones sobre modularidad y futuras extensiones. Incluso, en ciertas ocasiones se pueden incluir aspectos de diseo, como el uso de lenguajes de programacin particulares. En la metodologa de Objectory, el modelo de requisitos consta de tres modelos principales, visualmente representado por un diagrama de tres dimensiones como se muestra en la figura 6.2. Comportamiento (casos de uso) El caso

Informacin (dominio del problema)

Presentacin (interfaces/borde)

Figura 6.2 Los tres ejes de modelado del modelo de requisitos. El modelo de comportamiento, basado directamente del modelo de casos de uso, especifica la funcionalidad que ofrece el sistema desde el punto de lista del usuario. Este modelo utiliza dos conceptos claves: actores para representar los distintos papeles que los usuarios desempea con el sistema y casos de uso para significar que pueden hacer los actores con respecto al sistema. El modelo de presentacin o modelo de interfaces (o borde) especifica como interactuar el sistema con actores externos al ejecutar los casos de uso. En particular en los sistemas de informacin que tienen mucho contacto con el usuario, especfica cmo se vern visualmente las interfaces grficas y qu funcionalidad ofrecer cada una. El modelo de informacin o modelo del dominio del problema especifica los aspectos estructurales de la aplicacin en trminos de objetos. Este modelo permite identificar rpidamente cules objetos podrn ser guardados en una base de datos, si se fuera el caso. Adems, es utilizado para guardar informacin temporal en la aplicacin, y eventualmente servir mayor parmetro de llamadas entre funciones en el sistema.

Es importante resaltar que esta separacin en tres ejes de modelado inpendientes sirve para una mayor estabilidad en el desarrollo del sistema, lo que permite minimizar los efectos de cada uno sobre los otros dos. Para ilustrar el modelo de requisitos y el desarrollo de los modelos posteriores, se utilizar el ejemplo del Sistema de reservaciones de vuelo como se mencion antes. Para ello, mostraremos inicialmente una descripcin del problema. A partir de esta descripcin inicial se describirn los tres modelos bsicos del modelo de requisitos.

6.1 Descripcin del problema

La descripcin del problema es un resumen preliminar de necesidades que sirve como punto de partida para comprender los requisitos del sistema. Aqu se trata de simular una descripcin preparada por un cliente, la cual debe evolucionar por medio del modelo de requisitos, con objeto de lograr la especificacin Final del sistema a desarrollarse. La descripcin del problema debe ser una especificacin de necesidades y no una propuesta de solucin. La descripcin inicial puede ser incompleta e informal, pues al realizarse sin un anlisis completo, no hay ninguna razn para esperar que sea correcta. Como ejemplo se desarrollar un Sistema de reservaciones de vuelo, el cual permitir al usuario hacer consultas y reservaciones de vuelos; adems de comprar los boletos areos de forma remota, sin la necesidad de recurrir a un agente de Viajes. En la actualidad, existen mltiples sistemas de reservaciones de vuelo que utilizan las agencias de Viajes para dar servicio a los clientes, entre es tos los cuatro ms importantes son: Sabre2, Galileo3, Worldspan4 y Amadeus5. Estos sistemas son conocidos como sistemas de distribucin global. Tambin existen sistemas de reservaciones de vuelo por Internet, como Travelocity6 y Expedia7, entre otras, los cuales se basan en su mayora, de manera directa indirecta, en los sistemas de distribucin global anteriores.

La descripcin del problema para nuestro sistema de reservaciones de vuelos la siguiente: El sistema de reservaciones de vuelos, permite al usuario hacer consultas y reservaciones de vuelos, adems de poder comprar los boletos areos de forma remota, sin la necesidad de recurrir a un agente de viajes. Se desea que el sistema de reservaciones sea accesible a travs de Internet (World Wide Web). El sistema presenta en su pantalla principal un mensaje de bienvenida describiendo los servicios ofrecidos junto con la opcin para registrarse por primera vez, o si ya se est registrado, poder utilizar el sistema de reservaciones de vuelos. Este acceso se da por medio de la insercin de un login previamente especificado y un password ya escogido y que debe validarse. Una vez registrado el usuario, y despus de haberse validado el registro y contrasea del usuario, se pueden seleccionar las siguientes actividades: Consulta de vuelos Reservacin de vuelos Pago de boletos La consulta de vuelos se puede hacer de tres maneras diferentes: Horarios de vuelos Tarifas de vuelos Estado del vuelo La consulta segn horarios muestra los horarios de las diferentes aerolneas que dan servicio entre dos ciudades. La consulta segn tarifas muestra los diferentes vuelos entre dos ciudades que dan prioridad a su costo. La informacin de vuelo se utiliza principalmente para consultar el estado de algn vuelo, incluyendo informacin de disponibilidad de asientos y, en el caso de un vuelo para el mismo da, si est a tiempo. Se pueden incluir preferencias en las bsquedas, como fecha y horario deseado, categora de asiento, aerolnea y si se desea, slo vuelos directos. La reservacin de vuelo permite al cliente hacer una reservacin para un vuelo particular, especificando la fecha y horario, bajo una tarifa establecida. Es posible reservar un itinerario compuesto) de mltiples vuelos, para uno o ms pasajeros, adems de poder reservar asientos. El pago permite al cliente, dada una reservacin de vuelo previa y una tarjeta de crdito vlida, adquirir los boletos areos.

Los boletos sern enviados al cliente posteriormente, o estarn listos para Ser recogidos en el mostrador del aeropuerto antes de la salida del primer vuelo. Es necesario estar previamente registrado con un nmero de tarjeta de crdito vlida para poder hacer compras de boletos, o de lo contrario proveerla en el momento de la compra. Adems de los servicios de vuelo, el usuario podr, en cualquier momento, accesar, modificar o cancelar su propio registro, todo esto despus de haber sido validado en el sistema. Es conveniente que el lector note lo informal y limitado de esta descripcin que se refinar a lo largo del captulo. Dado que el modelo de casos de uso es el principal de todo el sistema, comenzaremos con l.

6.2 Modelado de casos de uso

El modelo de casos de uso describe un sistema en trminos de sus distintas formas de utilizacin, cada una de las cuales se conoce como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por l usuario. Dado que los casos de uso describen el sistema a desarrollarse, lo cambios en los requisitos significarn cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automvil sera la secuencia de evento desde que el conductor entra en el coche y enciende el motor hasta llegar a su destino final. Por tanto, para comprender los casos de uso de un sistema primero es necesario saber quienes son sus usuarios; por ejemplo conducir un automvil es distinto de arreglarlo, pues los usuarios tambin son diferentes: el dueo del automvil y el mecnico, respectivamente. Para ello, se define el concepto de actor, que es el tipo de usuario que est involucrado en la utilizacin de un sistema, y que adems es una entidad externa al propio sistema, juntos, el actor y el caso de uso, representan los dos elementos bsicos de este modelo, lo cual se muestra de manera grfica en la figura 6.3 de acuerdo con la notacin UML.

Actor Figura 6.3 caos de uso.

Casos de uso

El actor y el caso de uso son las entidades bsicas del modelo de

Los casos de uso son ideas simples y prcticas que no requieren muchas habilidades tecnolgicas para ser utilizadas (a diferencia de las dems actividades del desarrollo). Por el contrario, si se volvieran muy complejas se perdera su utilidad. Dado que el modelo de requisitos es la primera actividad del desarrollo del sistema, permite hacer muchos cambios en su especificacin sin afectar al resto del sistema. Cuando se identifican y describen los casos de uso, habr ciertas imprecisiones que se irn resolviendo de manera gradual. De esta manera, se pueden desarrollar de forma independiente los distintos casos de uso para despus integrarlos y formar el modelo de

requisitos completo. Esta habilidad de tomar parte de la funcionalidad permite un desarrollo ms flexible, incluso concurrente.

6.2.1 Actores
Los actores son entidades distintas a los usuarios, en el sentido de que stos son las personas reales que utilizarn el sistema, mientras que los actores representan cierta funcin que una persona real realiza, En la terminologa orientada a objetos, se considera al actor una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Incluso, una misma persona puede aparecer como diversas instancias de diferentes actores. Los actores modelan cualquier entidad externa que necesite intercambiar informacin con el sistema. No estn restringidos a ser personas fsicas, por lo que pueden representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Adems, cada uno de estos actores podr ejecutar una o ms tareas del sistema. Antes de identificar los casos de uso, se identifican los atores del sistema, esto es para que stos sean la herramienta principal que permita encontrar los casos de uso. Cada actor ejecuta un nmero especfico de casos de uso en el sistema. Una vez definidos todos los actores y casos de uso en el sistema, se establece la funcionalidad completa de ste. Encontrar actores implica trabajo y raramente se encuentran todos los actores de una vez. Por ejemplo, un sistema de computacin puede tener diferentes tipos de usuarios: programadores, operadores, administradores o usuarios generales. Cada uno de estos tipos de usuario corresponde a un actor diferente y, como mencionamos anteriormente, una misma persona puede desempear la funcin de programador u operador. Para especificar los actores de un sistema, se dibuja un diagrama correspondiente a la delimitacin del sistema, la cual representa al sistema como una caja negra, y a los diferentes actores, como entidades externas a sta, como se muestra en la figura 6.4.

Programador

Sistemas de Computacion

Operador

Usuario Figura 6.4 Delimitacion de un sistema segn los actores En general no se describen los actores con demasiado detalle por ser externos al sistema, adems de que sus acciones no son deterministas; en otras palabras, un actor a

Administrador

diferencia del propio sistema en cada momento puede decidir entre mltiples opciones. Por otro lado, el sistema y los casos de uso correspondientes deben ser deterministas, de lo contrario, el sistema har lo que crea conveniente lo cual no es aceptable. Sin embargo, para reconocer los casos de uso es necesario identificar primero a los actores del sistema, comenzando por aquellos que son la razn principal del sistema, conocidos como actores primarios. Estos actores tpicamente rigen la secuencia lgica de ejecucin del sistema Adems de los actores primarios, existen actores supervisando y manteniendo el sistema, a los que se les llama actores secundarios y existen primordialmente como complemento a los actores primarios, siendo esta distincin importante para dedicarle el esfuerzo principal a las necesidades de los actores primarios. Al contrario de stos, que tpicamente pertenecen a personas fsicas, los actores secundarios corresponden, por lo general a mquinas o sistemas externos (estos ltimos son ms difciles de identificar). Los actores secundarios tienden a responder a secuencias lgicas del sistema y no tanto a inicializarlas de manera propia. En particular, existe siempre la duda, por ejemplo, de si el sistema operativo o una base de datos seran actores. La decisin depende de la funcin que desempeen con respecto al sistema en desarrollo, si desempean una funcin activa entonces deben modelarse como actores. Retomando la descripcin del Sistema de Reservaciones de Vuelos, se puede identificar al menos un actor, el Usuario; quien est encargado de hacer las consultas y reservaciones en el sistema. Si se analiza un poco ms, se puede identificar que las bases de datos de los sistemas externos de reservaciones tienen una funcin muy activa con respecto al sistema en desarrollo. A este actor lo llamaremos la Base de Datos de Reservaciones, el cual mantiene la informacin sobre los vuelos y reservaciones. Ms an, podemos identificar un actor adicional, representando una segunda base de datos, que se involucre en la informacin de los usuarios ms que de las reservaciones. A este actor lo llamaremos la Base de Datos de Registros, encargado de mantener la informacin de los Usuarios sobre la utilizacin del sistema. El diagrama de delimitacin del sistema con los actores correspondientes se muestra en la figura 6.5.

Sistemas de Resevaciones de Vuelo Usuario

Base de Datos Reservaciones

Base de Datos de reguistro Figura 6.5 Delimitacion del sistema de reservaciones de vuelo. Volviendo a la distincin entre actor y persona, una misma persona puede desempear la funcin del actor Usuario cuando hace reservaciones, y adems puede trabajar para el sistema de reservaciones, por ejemplo como Operador, que correspondera a otro actor no mostrado en nuestro ejemplo.

El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de Datos de Reservaciones y Base de Datos de Registros Son ambos actores secundarios, ya que si no existieran usuarios no habra necesidad del sistema. Cuando diferentes actores realizan roles similares, pueden heredar de un actor abstracto comn, como lo muestra el actor abstracto Base de Datos en el ejemplo de la figura 6.6. El resto de los actores se conoce como actores concretos, y utilizan terminologa similar a la de herencia, como se vio en el captulo 4. Sistemas de Reservaciones de Vuelo

Usuario

Base de datos

Base de Datos de Registro Figura 6.6 Delimitacion del sistema de reservaciones de vuelo con ejemplo de herencia entre actores.

Base de Datos de reservacion

La ventaja de modelar actores abstractos es que expresan similitudes entre casos de uso. Si el mismo o parte del mismo caso de uso se puede ejecutar por varios actores diferentes, el caso de uso necesita ser especificado slo con respecto a un actor en lugar de varios. Por otro lado, los actores abstractos tambin pueden utilizarse para especificar privilegios comunes a mltiples actores en un sistema.

6.2.2 Casos de uso

Despus de haber definido a los actores del sistema, se establece la funcionalidad propia del sistema por medio de los casos de uso. Al usarse terminologa orientada a objetos, cada caso de uso define una clase o forma particular de usar el sistema, mientras que cada ejecucin del caso de uso se puede ver como una instancia del mismo, o sea, un objeto, con estado y comportamiento. Cada caso de uso constituye un flujo completo de eventos, que especifican la interaccin que toma lugar entre el actor y el sistema. El actor primario se encarga de dar inicio a esta interaccin, mientras que los casos de uso son instanciados como respuesta al evento anterior. Una instancia de un actor puede ejecutar varias de estas secuencias, que constan de diferentes acciones que a su vez deben llevarse a cabo. La instancia del caso de uso existe mientras ste se siga ejecutando. La ejecucin del caso de uso termina cuando el actor genera un evento que requiere un caso de uso nuevo. Las diferentes instancias de los casos de uso se conocen como escenarios. Como varios casos de uso pueden Comenzar de una misma forma, no

es Siempre posible decidir qu caso de uso se ha instanciado, hasta que ste se haya completado. La descripcin de los casos de uso se basa en diagramas similares a los de transicin de estados. Se puede ver a cada caso de uso como si representara un estado en el sistema, donde un estmulo enviado entre un actor y el sistema ocasiona una transicin entre estados. En la figura 6.7 se muestra un ejemplo de casos de uso, donde un programador escribe y depura un programa, mientras que otro usuario lo ejecuta.

Programador

Escribir programa

Ejecutar programa Depurar programa

Usuario

Figura 6.7 actores.

Ejemplo de casos de uso que muestren la relacin con los

Para identificar los casos de uso, se puede leer la descripcin del problema y discutirlo con aquellos que actuaran como los actores, empleando preguntas como; Cules son las tareas principales de cada actor? Tendr el actor que consultar y modificar informacin del sistema? Deber el actor informar al sistema sobre cambios externos? Desea el actor ser informado sobre cambios inesperados?

Por ejemplo, en un sistema de conmutacin telefnica, un actor podra ser un suscriptor, y un caso de uso tpico sera hacer una llamada local. El caso de uso comienza cuando el suscriptor levanta el telfono. Otro caso de uso es ordenar una llamada al servicio de despertador. Ambos casos de uso comienzan cuando el suscriptor levanta el telfono, pero cuando esto ocurre, no sabemos cul caso desea ejecutar. Por tanto, los casos de uso pueden comenzar de forma similar y no podemos saber cul se est instanciando hasta que se termine. En Otras palabras, el actor no requiere de que un caso de uso se ejecute, slo que inicie una secuencia de eventos que finalmente resulte en la terminacion de algn caso de uso. En el sistema de reservaciones de vuelos utilizamos los actores ya identificados como punto de partida. Dado que el Usuario es el actor primario se comienza con l. El sistema debe ser capaz de dar ciertos servicios al usuario, como consultas y reservaciones. De aqu podemos definir nuestros casos de uso principales. Consultar informacin y hacer una Reservacin. Observe que los nombres de los casos de uso deben corresponder a acciones y no tanto a sustantivos. La figura 6.8 ilustra el sistema con los dos casos de uso, adems de un caso de uso adicional, Mantener el Sistema,

correspondiente a un actor secundario Operador. Sin embargo, para lograr una mejor especificacin de requisitos y evitar complejidad adicional, no se ver ninguna funcionalidad de mantenimiento en nuestro desarrollo: un ejemplo adicional de cmo concentrarse en ciertos aspectos de los requisitos durante diversas etapas.

Usuario

Consultar Informacion

Mantener el Sistema Hacer Reservacion

Operador

Figura 6.8 vuelo

Ejemplo de casos de uso para un sistema de reservaciones de

En la descripcin del problema se menciona que, para utilizar el sistema, el usuario debe estar registrado, por lo cual agregamos un caso de uso Registrar usuario. Por otro lacio, se debe incluir la Base de Datos de Reservaciones y la J3ase de Datos de Registros ya que son actores secundarios necesarios. Estos tres casos de uso se muestran en la figura 6.9. Ntese las flechas unidireccionales dirigindose del actor primario hacia el caso de uso y del caso de uso hacia el actor secundario.

Registrar Usuario

Base de Datos reservaciones

Usuario

Consultar Informacion

Base de Datos de Reservaciones

Hacer Reservaciones

Figura 6.9 vuelo.

principales casos de uso para el sistema de reservaciones de Se elimino en el diagrama la delimitacion del sistema

Aunque la idea del modelo de casos de uso es que los diagramas sean lo ms sencillo posible, a menudo es necesario contar con mecanismos que permitan extender los diagramas de manera ms elaborada. El modelo de casos de uso permite la subdivisin de partes del flujo completo de un caso de uso en casos de uso separados. Las razones son aprovechar distintos subflujos que se repiten en mltiples casos de uso, de manera anloga al concepto de herencia, y resaltar los flujos menos comunes. Aunque, la

complejidad de los casos de uso es un factor importante para la decisin, en general, no siempre es obvio que subflujos deberan definirse como casos de uso separados. Existen dos enfoques distintos para expresar extensiones: Si las diferencias entre los casos de uso son pequeas, stos se pueden describir como variantes de un mismo caso de uso, dando lugar al concepto de subflujos o ramificaciones de flujos dentro de un mismo caso de uso por ejemplo, en el caso de uso Registrar Usuario, la creacin por primer vez del registro y su actualizacin se pueden considerar dos secuencias de eventos lgicamente similares, por lo cual se tratan como distintos subflujos en un mismo caso de uso. En general, primero se describe el flujo principal o bsico, el cual es el flujo ms importante dentro del caso de uso y generalmente el punto de entrada al caso de uso. Posteriormente se describen los subflujos alternos que pudieran incluir flujos para el manejo de variantes en la lgica, en cuyo caso se conocen como subflujos alternos. Normalmente un caso de uso tiene slo un curso bsico, pero varios subflujos y cursos alternos. Si las diferencias entre los casos de uso son grandes, se deben describir como casos de uso separados. Cuando esto ocurre, se utilizan principalmente las relaciones de extensin, inclusin y generalizacin, corno se describe a continuacin.

La identificacin de casos de uso es normalmente un proceso iterativo, donde se hacen mltiples revisiones hasta llegar a una solucin final estable. Cuando esto ocurre, cada caso de uso debe describirse con ms detalle.

EXTENSIN
Un concepto importante que se utiliza para estructurar y relacionar casos de uso es la extensin, la cual especifica cmo un caso de uso puede insertarse en otro para extender la funcionalidad del anterior. El caso de uso donde se insertar la nueva funcionalidad debe ser un flujo completo, por lo cual ste es independiente del caso de uso a insertarse. De esta manera, el caso de uso inicial no requiere consideraciones adicionales al caso de uso a ser insertado, nicamente se especifica su punto de insercin. Tomando como ejemplo el Sistema de Reservaciones de Vuelos, se muestra en la figura 6.10 la notacin para extensin, utilizando la etiqueta extiende (extend), donde el caso de uso de Hacer Reservacin se extiende mediante el caso de uso Pagar Reservacin.

Base de Datos de reservacion <

<<extend>>

Usuario

Hacer Reservaciones

Pagar Reservaciones

Figura 6.10 Casos de uso Hacer Reservaciones con extensin de Pagar Reservacin. En general, la extensin se utiliza para modelar secuencias de eventos opcionales de casos de uso, que al manejarse de manera independiente pueden agregarse o eliminarse del sistema de manera modular. Se puede considerar a la asociacin de extensin como una interrupcin en el caso de uso original que ocurre donde el nuevo caso de uso se va a insertar. Para cada caso de uso que vaya a insertarse en otro caso de uso, se especifica la posicin en el caso de uso original, donde la extensin se insertar. El caso de uso original se ejecuta de forma normal hasta el punto donde el caso de uso nuevo se inserta. En este punto, se contina con la ejecucin del nuevo curso. Despus que la extensin se ha terminado, el curso original contina como si nada hubiera ocurrido. Por regla general, se describe primero los casos de uso bsicos, totalmente independientes de cualquier extensin de funcionalidad, y luego los de extensin. INCLUSIN Una relacin adicional entre casos de uso es la inclusin. A diferencia de una extensin, la inclusin se define como una seccin de un caso de uso que es parte obligatoria del caso de uso bsico. El caso de uso donde se insertar la funcionalidad depende del caso de uso a ser insertado. Esta relacin se etiqueta con incluye (include). Por ejemplo, en el Sistema de Reservaciones de Vuelos, el caso de uso consultar Informacin incluye el caso de uso Validar Usuario como se muestra en la figura 6.11.

Validar Usuario

<<include>>

Usuario

| | | |

Base de Datos reservaciones

Consultar Informacion

Base de Datos de Reservaciones

Figura 6.11 Usuario GENERALIZACIN

Casos de uso Consultar Informacin con Inclusin de validar

Una relacin adicional entre casos de uso es la generalizacin, la cual apoya la reutilizacin de los casos de uso. Mediante la relacin de generalizacin es necesario describir las partes similares una sola vez, en lugar de repetirlas para todos los casos de uso con comportamiento comn. Los casos de uso extrados se conocen como casos de uso abstractos, ya que no sern instanciados independientemente, y servirn slo para describir partes que son comunes a otros casos de uso. Los casos de uso que realmente sern instanciados se llaman casos de uso concretos. Las descripciones de los casos de uso abstractos se incluyen en las descripciones de los casos de uso concretos. Una tcnica para extraer casos de uso abstractos es identificar actores abstractos. Esta

generalizacin es una herencia de secuencias (en lugar de operaciones, en el caso de herencia de objetos). Por ejemplo, en el Sistema de Reservaciones de Vuelos, el caso de uso Pagar Reservacin pudiera generalizarse en dos casos de uso, Pagar con Tarjeta y Pagar con Transferencia, como se muestra en la figura 6.12. Uno de estos dos sub casos de uso debera instanciarse, ya que el sper caso de uso, Pagar Reservacin, sera abstracto por no conocerse la forma de pago.

Base de Datos de Reservacion

<
<<extend>>

Usuario

Hacer Reservaciones

Pagar Reservaciones

Pagar con Tarjeta

Pagar con Transferencia

Figura 6.12

Casos de uso Pagar Reservaciones con generalizacin de pagos: Pagar con Tarjeta y Pagar con Transferencia.

Las relaciones de extensin e inclusin entre casos de uso se implementan ambas mediante asociaciones de clases, a diferencia de la generalizacin, la cual se implementa mediante herencia de clases. En la mayora de los casos, la seleccin es bastante obvia; sin embargo, el criterio principal es ver qu tanto se acoplan las funcionalidades de los casos de uso. Si el caso de uso a ser es tendido es til por s mismo, la relacin debe ser descrita utilizando extensin Si los casos de uso son fuertemente acoplados y la insercin debe tomar lugar para obtener un curso completo, la relacin debe ser descrita mediante la inclusin. Por otro lado, la generalizacin se emplea cuando dos o ms casos de uso comparten funcionalidad comn, la cual es extendida por cada uno al es tilo de la generalizacin entre clases. Tambin hay una diferencia en cmo se identifican estas relaciones. Las extensiones se identifican en un caso de uso existente, que el usuario desea extender con secuencias adicionales, mientras que las inclusiones se encuentran de la extraccin de secuencias comunes ya existente entre varios casos de usos. Las generalizaciones se encuentran al tratar de especializar de diferente manera un caso de uso existente. Finalmente, se desean diagramas sencillos que no sean telaraas, pero que muestren de manera esquemtica las posibles secuencias de interacciones entre los actores y el sistema. En la figura 6.13, se ilustra el diagrama completo de casos de uso para el Sistema de Reservaciones de Vuelos. Los casos de uso adicionales en este diagrama son la extensin de Registrar Tarjeta y Pagar Reservacin. Este ltimo caso de uso es interesante, porque extiende Hacer Reservacin e incluye Registrar Tarjeta, ambos requisitos con el fin de comprar un boleto con el sistema. Adems de la inclusin anterior, tambin se incluyen los casos de uso de Validar usuario y Ofrecer Servicios en

los casos de uso bsicos: Registrar Usuario, Consultar Informacin y Hacer Reservacin. TABLA

6.2.3 Documentacin
Parte fundamental del modelo de casos de uso es la descripcin textual detallada de cada uno de los actores y casos de uso identificados. Estos documentos son sumamente crticos ya que a partir de ellos se desarrollar el sistema completo. El formato de documentacin para cada actor es el siguiente: Actor Casos de uso Tipo Descripcin Nombre del actor. Nombre de los casos de uso en los cuales participa. Primario y secundario. Breve descripcin del actor.

Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema en los eventos enviados o recibidos por stos. En esta etapa no se incluyen eventos internos al propio sistema, ya que esto se estudiar durante el anlisis, y nicamente agregara una complejidad innecesaria. El formato de documentacin para cada caso de uso es el siguiente: Casos de uso Actores Nombre del caso de uso. Actores primarios y secundarios que interactan con el caso de uso. Tipo Tipo de flujo: bsico, inclusin, extensin, generalizacin o algn otro. Propsito Razn de ser del caos de uso. Resumen Resumen del caso de uso. Precondiciones Condiciones que deben satisfacerse para ejecutar el caso de uso. Flujo principal El flujo de eventos mas importantes del caso de uso, donde dependiendo de las acciones de los actores, se continuara con algunos de los subflujos Subflujos Los flujos secundarios del caso de uso, numerados como (S-1), (S-2), etctera. Excepciones Excepciones que pueden ocurrir durante el caso de uso, numerados como (E-1), (E-2), etctera. Dado que el modelo de casos de uso est motivado y enfocado principalmente hacia los sistemas de informacin, donde los usuarios juegan un papel primordial, es importante relacionarse con las interfaces a ser diseadas en el sistema. stas sirven para apoyar de mejor manera la descripcin de los casos de uso, adems de servir de base en prototipos iniciales. Un comentario importante sobre la especificacin de estos documentos, es que se sigue un proceso iterativo para definir cada uno de ellos, el cual se podr modificar o refinar despus. Obviamente, cuanto ms tarde ocurran estos cambios, ms costoso ser implementarlos. Note que en las siguientes descripciones, ya se hace referencia a

pantallas de interaccin con el usuario, las cuales sern mostradas en un diseo preliminar en la siguiente seccin. Los actores y casos de uso del sistema de reservaciones de vuelo son descritos en la seccin 6.4.