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 los clientes lo comprendan.

El modelo de requisitos es el primero en desarrollarse, y la base

para formar todos los dems modelos en el desarrollo de software. En
general, cualquier cambio en la funcionalidad del sistema es mas fcil
de hacer, y con menores consecuencias a este nivel que
posteriormente. El modelo de requisitos que se desarrollar se basa
en la metodologa objetory (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]. 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 capitulo 3 que nos servirn
en esta leccin:

Requisitos: el modelo de casos de uso sirven 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 es
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.
Documentos: el modelo de casos de uso se deber registrar a
lo largo de las diversas actividades, dando lugar a distintos
documentos como los manuales de usuario, de administracin,
etctera.
El diagrama de la figura 6.1 ilustra los distintos modelos, los detalles
y la notacin que se describirn ms adelante.

ok

ok
Class El caso
falla

Modelo de Modelo de Modelo de Modelo de Modelo de Modelo de

requisitos anlisis diseo implementacin pruebas documentacin

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 complementar la informacin faltante, y as resolver
ambigedades e inconsistencias. Tambin se debe separar los
requisitos verdaderos de las decisiones relacionadas 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 representados por un diagrama
de tres dimensiones como se muestra en la figura
Comportamiento
(casos de uso)

Informacin
(dominio de problema)

Presentacin
(interfaces/borde)
 El modelo de comportamiento, basado directamente del modelo
de casos de uso, especifica la funcionalidad que ofrece el
sistema desde el punto de vista del usuario. Este modelo utiliza
dos conceptos claves: actores para representar los distintos
papeles que los usuarios desempean con el sistema y casos
de uso para significar qu pueden hacer los actores con
respecto al sistema.
El modelo de presentacin o modelo de interfaces (o borde)
especifica cmo interacta 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, se se fuera el caso. Adems, es utilizado para
guardar informacin temporal en la aplicacin, y eventualmente
servir como parmetro de llamadas entre funciones en el
sistema.

Es importante resaltar que esta separacin en tres ejes de

modelado independientes 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 requisitos.
6.1 Descripcin del problema

La descripcin del problema es un resumen preliminar de las

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
necesidad de recurrir a un agente de viajes. En la actualidad, existen
mltiples sistemas de reservaciones de vuelos que utilizan las
agencias de viajes para dar servicios a los clientes, entre estos los
cuatro ms importantes son: Sabre, Galileo, Worldspan y Amadeus.
Estos sistemas son conocidos como sistemas de distribucin global.
Tambin existen sistemas de reservaciones de vuelo por Internet,
como Travelocity y Expedia, entre otras, los cuales se basan en su
mayora, de manera directa o indirecta, en los sistemas de
distribucin global anteriores.

La descripcin del problema para nuestro sistema de

reservaciones de vuelos es la siguiente:

El sistema de reservaciones de vuelos, permite al usuario hacer

consultas y reservaciones de vuelo, 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 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 servicios 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
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, acceder, 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 Modelos 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 el usuario. Dado que los
casos de uso describen el sistema a desarrollarse, los cambios en los
requisitos significarn cambios en los casos de uso. Por ejemplo, un
caso de uso para manejar un automvil sera la consecuencia de
eventos desde que el conductor entra al 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 quines 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 Caso de uso

Figura 6.3 El actor y el caso de uso son las entidades bsicas del
modelo de casos de uso.

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, 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 actores

del sistema, esto es para que stos sean la herramienta principal que
permita encontrar los 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 Sistema de Operador

computacin

Usuario Administrador

Figura 6.4 Delimitacin 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 diferencia del propio
sistema en cada momento puede decidir entre mltiples opciones.
Por otro lado, el sistema y los casos de usos correspondientes deben
ser deterministas, de lo contrario, 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 (stos 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

Sistema de Base de Datos

Reservaciones Reservaciones
de Vuelo
Usuario

Base de Datos
de Registros
Figura 6.5 Delimitacin 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 mismo 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.

Sistema de
Reservaciones
de Vuelos
Usuario Base de Datos

Base de Datos Base de Datos

de Registros Reservaciones

Figura 6.6 Delimitacin del sistema de reservaciones de vuelo con

ejemplo de herencia entre actores.

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.
GENERALIZACION

Una relacin 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 concreto.

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 para pagar Reservacin pudiera generalizarse en dos
casos de uso, pagar con tarjeta y Pagar con Transferencia, como se
muestra en la figura. Uno de estos dos sub casos de uso deberan
instanciarse, ya que el sper caso de uso, pagar Reservacin, sera
abstracto por no conocerse la forma de pago.

Base de Datos Reservaciones

<<extend>
Hacer reservacin >
Usuario Pagar Reservacin

Pagar con Tarjeta Pagar con Transferencia

Figura 6.12 Casos de uso Pagar reservacin 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 diferencias
de la generalizacin, la cual se implementa mediante de 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 extendido
es til por s mismo, la relacin debe ser descrita mediante la
inclusin. Por otro lado, la generalizacin se emplea cuando dos o
mas casos de uso comparten funcionalidad comn, la cual es
extendida por cada uno al estilo 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 Reservacin 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, por que
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 bsico: Registrar
Usuario, Consultar Informacin y Hacer Reservacin.

<< Include >>

Registrar Usuario
<< extend >> Base de Datos
Validar Usuario
de Registros
<< Include >>

Registrar tarjeta
Hacer Reservacin

<< extend >>

Usuario
<< Include >>

<< Include >> Pagar Reservacin

<< Include >>

<< Include >>

Ofrecer Servicio
Consultar Informacin
 Figura 6.13 En el diagrama se muestran los casos de uso
completos para el sistema de reservaciones de vuelo, que consiste en
tres actores y siete casos de uso.

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 Nombre del actor

Casos de uso Nombre de los casos de uso en los cuales
participa
Tipo Primario o Secundario
Descripcin 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:

Caso de uso Nombre del caso de uso

Actores Actores primarios y secundarios que interaccionan
con el caso de uso.
Tipo Tipo de flujo: bsico, inclusin, extensin,
generalizacin o algn otro.
Propsito Razn de ser del caso de uso.
Resumen Resumen del caso de uso.
Precondicion Condiciones que deben satisfacerse para ejecutar el
es caso de uso.
Flujo El flujo de eventos ms importante del caso de uso,
Principal donde dependiendo de las acciones de los actores,
se continuar con alguno de los subflujos.
Subfijos 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 poyar 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 cul 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 cules
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.

6.3 Modelo de interfaces

El modelo de interfaces describe la presentacin de

informacin entre los actores y el sistema. Se especifica en detalle
cmo se vern las interfaces de usuario al ejecutar cada uno de los
casos de uso. Si se trata de la interface humano-computadora (HCI,
Human Computer Interface), se pueden usar esquemas de cmo vera
el usuario las pantallas cuando se ejecuta cada caso de uso. Tambin
se puede generar una simulacin ms sofisticada usando un
sistemamanejador de interfaces de usuario (UIMS, User Interface
Management System). Normalmente, un prototipo funcional de
requisitos que muestra las interfaces de usuario es una estrategia
importante. Esto ayuda al usuario a visualizar los casos de uso segn
se mostrarn en el sistema a construirse. Tal enfoque elimina muchas
posibilidades de malos entendidos. Cuando se disean las interfaces
de usuario, es esencial tener a los usuarios involucrados, y que las
interfaces reflejen la visin lgica del sistema, debiendo haber
consistencia entre la imagen conceptual del usuario y el
comportamiento real del sistema. Si las interfaces son protocolos de
hardware, se pueden referir a los diferentes estndares, como
protocolos de comunicacin. Estas descripciones de interfaces son,
por tanto, partes esenciales de las descripciones de los casos de uso
y las deben acompaar. En estas etapas iniciales del desarrollo, el
diseo de las pantallas no es tan importante como el manejo de la
informacin que se ofrece, el cual, debe corresponder a las
necesidades de cada caso de uso, algo que se mostrar a
continuacin en el Sistema de Reservaciones de Vuelos.
6.4 Actores y casos de uso para el sistema de reservaciones
de vuelos.

Tomando como ejemplo el sistema de reservaciones de vuelo,

mostraremos la documentacin de los actores y casos de uso junto
con el diseo de las interfaces que se usarn como prototipo del
sistema. Estos diseos pueden hacerse en papel o aprovechar una
herramienta que simplifique la tarea del diseo de pantallas. El
objetivo primordial es llegar a un acuerdo rpido sobre la
funcionalidad de la aplicacin, ms que lograr un diseo grafico
sofisticado.

6.4.1 Actores

Se describen en total tres actores en el sistema de

reservaciones de vuelos. El usuario interacta con todos los casos de
uso, aunque todas las asociaciones no fueron diagramadas de manera
explcita 6.13

Actor Usuario.
Casos de uso validar usuario, registrar usuario, registrar tarjeta,
consultar informacin, Hacer Reservacin, Pagar
Reservacin, Ofrecer Servicios.
Tipo Primario.
Descripcin Es el actor principal y representa a cualquier
persona que desee utilizar el sistema de
reservaciones.

La Base de Datos de Registros interacta con los casos de uso

relacionados exclusivamente con registro.

Actor Base de Datos de Registros.

Casos de uso Validar usuario, Registrar Usuario, Registrar Tarjeta
Tipo Secundario.
Descripcin Es un actor secundario y representa a la base de
datos donde se guarda toda la informacin
relacionada con los usuarios, pero independiente de
las reservaciones.

La Base de Datos de Reservaciones interacta con los casos de

uso relacionados exclusivamente con reservaciones.

Actor Base de Datos de Reservaciones.

Casos de uso Consultar informacin, Hacer Reservacin, Pagar
Reservacin.
Tipo Secundario.
Descripcin Es un actor secundario y representa la base de
datos donde se guarda toda la informacin
relacionada con las reservaciones, pero
 independiente de los propios usuarios del sistema.

6.4.2 Casos de Uso

Como apoyo en la descripcin de los casos de uso,

mostraremos las diversas pantallas diseadas, comenzando por la
pantalla principal. Dado que el requisito de uso del sistema es que
todo usuario deba haberse registrado, la pantalla principal debe dar
dos opciones: a) registrarse por primera vez y b) validar un registro
existente como se muestra en la figura.

(Interfaz).
Figura 6.14 Pantalla Principal del sistema (P-1)

Observe que el caso de uso Registrar Usuario, como lo

describiremos en nuestro ejemplo, agrupa la lgica relacionada con
un usuario ya registrado junto con otro que se registra por primera
vez. Dado que la opcin para registrarse por primera vez debe
aparecer en la pantalla principal (P-1), la opcin en la pantalla de
servicios (P-2) es utilizada por un usuario ya registrado. Y aunque se
podran definir dos casos de uso separados para la lgica de registro,
por ejemplo, Crear Registro Usuario y Obtener Registro Usuario,
consideramos que stos son ms bien subflujos de un mismo caso de
uso. Es conveniente hacer notar que existen muchas maneras de
describir un sistema similar, donde por lo general una forma no es
necesariamente ms correcta que la otra, siendo ms bien una
cuestin de estandarizacin o estilo del analista. En nuestro caso,
buscamos soluciones compactas que reduzcan el nmero total de
casos de uso, siempre y cuando la lgica est muy relacionada. Se
incluyen adems varios subflujos para llamar secciones del flujo
desde distintos lugares, ya que no se puede comenzar un flujo o
subflujo en la mitad del proceso. A continuacin describimos los
distintos casos de uso con las pantallas correspondientes. Se excluyen
pantallas menores como aquellas con mensajes de error o
confirmacin del xito de la operacin. Comenzamos describiendo los
flujos Validar Usuario y Ofrecer Servicios, que se incluyen en los
diversos casos de uso. Posteriormente describimos cada uno de los
casos bsicos y de extensin.

Validar Usuario.

El caso de uso Validar Usuario est vinculado con la pantalla

principal (P-1) y se llama a partir de los casos de uso Registrar
Usuario, Consultar Informacin y Hacer Reservacin como se mostr
en el diagrama de la figura 6.13. dado que este caso de uso se inserta
en los anteriormente mencionados, depende de stos incluirlo y
llamarlo apropiadamente.
Caso de uso Validar Usuario.
Actores Usuario, Base de Datos de Registros
Tipo Inclusin.
Propsito Validar a un usuario ya registrado para el uso del
sistema de reservaciones de vuelo.
Resumen Este caso de uso, se inicia por el usuario. Valida al
usuario mediante un login y password a verificarse
con su respectivo registro de usuario, para que
pueda utilizar el sistema de reservaciones.
Precondicion Se requiere haber ejecutado anteriormente el caso
es de uso Registrar Usuario subflujo Crear Usuario.
Flujo Se presenta al usuario la pantalla principal (P-1). El
Principal usuario puede seleccionar entre las siguientes
opciones: Registrarse por primera vez, ok y
Salir.

Si la actividad seleccionada es Registrarse por

primera vez se ejecuta el caso de uso Registrar
Usuario, subflujo Crear Registro Usuario (S-1).

Si la actividad seleccionada es OK, se valida el

registro de usuario mediante un Login y un
Password insertados por el usuario en la pantalla
principal (P-1).
Una vez validado el usuario (E-1), se contina con el
Caso de uso Ofrecer Servicios.
Si la actividad seleccionada es Salir se saldr del
sistema.
Subflujos Ninguno
Excepciones E-1 no hubo validacin: el login/password no se
valid correctamente. Se solicita al usuario volver a
registrarse.
Despus de tres intentos se saldr del sistema.
OFRECER SERVICIOS.

Si observamos el diagrama de casos de uso de la figura 6.13,

vemos que existen tres casos de uso bsicos que el usuario puede
instanciar: Registrar Usuario, Hacer Reservaciones y Consultar
Informacin. El caso de uso Ofrecer Servicio se incluye en estos tres
casos de uso bsicos para delegarles de manera adecuada, segn las
opciones seleccionadas por el usuario. Tambin se incluye en el caso
de uso Validar Usuario, luego de la validacin de un usuario.

Caso de uso Ofrecer Servicios.

Actores Usuario.
Tipo Inclusin.
Propsito Ofrecer los diversos servicios a un usuario ya
registrado para que use el sistema de reservaciones
de vuelo.
Resumen El usuario inicial este caso de uso. Tiene capacidad
de utilizar las diversas opciones del sistema de
reservaciones.
Precondicion Se requiere haber validado correctamente al
es usuario.
Flujo Se presenta al usuario la pantalla servicios (P-2). El
Principal usuario puede seleccionar entre las siguientes
actividades:
consultar informacin, Hacer reservacin,
Obtener registro y Salir .
Si la actividad seleccionada es consultar
informacin, se contina con el caso de uso
Consultar Informacin, Subflujo Consultar (S-1).
Si la actividad seleccionada es Hacer Reservacin,
se contina con el caso de uso hacer reservacin,
subflujo Solicitar Clave Reservacin (S-1).
Si la actividad seleccionda es Obtener Registro, se
contina con el caso de uso Registrar Usuario,
subflujo Obtener Registro Usuario (S-2).
Si la actividad seleccionada es Salir se saldr del
sistema.
Subflujos Ninguno.
Excepciones Ninguno.

Por tal motivo, la siguiente pantalla del sistema debe permitir al

usuario seleccionar las opciones correspondientes, como se muestra
en la figura 6.15.

REGISTRAR USUARIO.
El caso de uso Registrar Usuario est vinculado con el registro
inicial del usuario y la modificacin de la informacin de registro.
Adems, ya deben incluirse los puntos de inclusin y extensin para
los casos de uso Validar Usuario, Ofrecer Servicios y Registrar Tarjeta
respectivamente.

(Interfaz)
Figura 6.15 Pantalla de men servicios (P-2).

Se describe a continuacin las secciones iniciales del caso de uso, con

las secciones restantes, subflujo y excepciones, ms adelante.

Caso de uso Registrar Usuario

Actores Usuario, Base de Datos Registros
Tipo Bsico
Propsito Permitir a un usuario registrarse en el sistema de
reservaciones de vuelo para usarlo.
Resumen El usuario inicia este caso de uso. Ofrece
funcionalidad para crear, modificar y eliminar el
registro de usuario con el sistema de reservaciones.
Precondicion Todos los subflujos, con excepcin de Crear Registro
es Usuario (S-1), requieren ejecutar inicialmente el
caso de uso Validar Usuario.
Flujo Se ejecuta el caso de uso Validar Usuario.
Principal Dependiendo de las opciones seleccionadas por el
usuario, se continuar con los diversos subflujos de
este caso de uso.

El diseo de la pantalla de registrase por primera vez se muestra en

la figura 6.16

(interfaz)
Figura 6.16 Pantalla para crear registro de usuario por primera vez
(P-3).

El subflujo Crear Registro Usuario (S-1), descrito a continuacin,

se instancia al presionar el botn correspondiente de la pantalla
principal (P-1).

Subflujo S-1 Crear Registro Usuario.

Se presenta al usuario la pantalla crear registro
usuario (P-3), que contiene informacin de registro
que debe llenar el usuario, lo cual incluye nombre,
apellido, calle, colonia, ciudad, pas, cdigo postal,
telfono de la casa y oficina, nmero de fax, login,
email, password y una entrada adicional de repetir
password para asegurarse que se escribi
correctamente. El sistema usar el login y el
password para validar al usuario.

El usuario puede seleccionar entre las siguientes

 actividades:
Registrar y Salir.
Si el usuario selecciona Registrar, el sistema
genera un nuevo registro de usuario ( E-1, E-2, E-3,
E-4). Se contina con el subflujo Administrar
Registro Usuario (S-3).
Si la actividad seleccionada es salir se saldr del
sistema ( Si an no se ha presionado registrar, la
informacin se perder).

En la figura 6.17 se ilustra el diseo de la pantalla para

administrar un registro de usuario existente. Note que la informacin
que ofrece es exactamente igual a la anterior. La nica diferencia son
las opciones que se ofrecen: eliminar y actualizar en lugar de
registrar.

(interfaz)
Figura 6.17 Pantalla de Obtener registro de usuario(P-4).

El resto de los subflujos se describen a continuacin. El subflujo

Obtener Registro Usuario (S-2) se instancia al presionar el botn
correspondiente de la pantalla de servicios (P-2). El subflujo
Administrador Registro Usuario (S-3) se instancia una vez que se
presente la informacin correspondiente en la pantalla de registro (P-
4). El subflujo Actualizar Registro Usuario (S-4) se instancia al
presionar el botn correspondiente de la pantalla de registro (P-4). El
subflujo Eliminar Registro Usuario (S-5) se instancia al presionar el
botn correspondiente de la pantalla de registro (P-4).

Subfijos S-2 Obtener registro Usuario.

El sistema obtiene el registro de usuario de la
base de datos de registro. Se contina con el
subflujo Administrar Registro Usuario (S-3).
S-3 Administrar Registro Usuario.
Se presenta al usuario la pantalla Obtener
registro usuario (P-4) con la informacin de
registro de usuario.
ste podr seleccionar entre las siguientes
actividades: Eliminar, Actualizar, Registrar
tarjeta, Servicios y Salir.
Subfijos Si el usuario presiona Actualizar, se ejecuta el
(continuacin) subflujo Actualizar Registro Usuario (S-A).
Si el usuario selecciona Eliminar, se ejecuta el
subflujo Eliminar Registro Usuario (S-5).
Si el usuario presiona Registrar tarjeta, se
contina con el caso de uso Registrar tarjeta.
Si la actividad seleccionada es Servicios, se
contina con el caso de uso Ofrecer Servicios.
Si la actividad seleccionada es Salir, se saldr
del sistema ( si an no se ha presionado
Actualizar, la nueva informacin se perder)
S-4 Actualizar Registro Usuario.
Se actualiza el registro de usuario con la
informacin modificada (E-1, E-3, E-4).
Se contina con el subflujo Administrar Registro
Usuario.
S-5 Eliminar registro Usuario.
Se elimina el registro de usuario y se contina
con el subflujo Crear Registro Usuario (S-1).

Las excepciones del caso de uso son las siguientes:

Excepciones E-1 Informacin Incompleta: falta llenar

informacin en el registro de usuario. Se vuelve a
solicitar al usuario que complete el registro.

E-2 Registro ya existe: si ya existe un registro

bajo ese Login, se solicitar al usuario que lo
cambie o que termine el caso de uso.

E-3 Login Incorrecto: el Login no es vlido. Se le

colicita al usuario que corrija el registro.

E-4 Password incorrecto: el Password escogido es

muy sencillo o no se valid correctamente. Se
solicita al usuario que corrija el registro.
REGISTRAR TARJETA.

El caso de uso Registrar tarjeta es una extensin del caso de

uso Registrar Usuario. De manera similar a Registrar Usuario, el caso
de uso registrar Tarjeta est compuesto por un registro inicial y por la
modificacin de la informacin ya registrada.

Se describe a continuacin las secciones iniciales del caso de

uso, con las secciones restantes, subflujos y excepciones, ms
adelante. Note que el flujo principal se llama al presionar Registrar
tarjeta en la pantalla de obtener registro de usuario (P-4).

Caso de uso Registrar Tarjeta

Actores Usuario, Base de Datos Registros.
Tipo Extensin
Propsito Permitir a un usuario registrar una tarjeta de
crdito en el sistema de reservaciones de vuelo
para pagar boletos.
Resumen Este caso de uso lo inicia el Usuario. Ofrece
funcionalidad para crear, modificar y eliminar el
registro de tarjeta usuario con objeto de pagar
las reservaciones directamente en el sistema de
reservaciones.
Precondiciones El usuario ya se debi registrar mediante la
activacin del caso de uso Registrar Usuario.
Flujo Principal Se contina con el subflujo Obtener Registro
Tarjeta (S-2). Si no existe un registro de tarjeta
vlido se contina con el subflujo Crear Registro
Tarjeta (S-1). De lo contrario, si ya existe uno, se
contina con el subflujo Administrar Registro
Tarjeta (S-3).

El diseo de la pantalla para registrar la tarjeta por primera vez se

muestra en la figura 6.18

(interfaz)
Figura 6.18 Pantalla de Crear registro de tarjeta por primera vez (P-
5).

El subflujo Registrar Tarjeta (S-1), descrito a continuacin, se

instancia al presionar el botn correspondiente de la pantalla
Servicios (P-5).
Subflujo S-1 Crear Registro Tarjeta.
Se presenta la pantalla Crear Registro tarjeta (P-5). La
pantalla incluye el nombre como aparece en la tarjeta,
nmero de tarjeta, el tipo de tarjeta y la fecha de
vencimiento.

El usuario puede seleccionar entre las actividades

Registrar, Servicios, Salir.
Si el usuario presiona Registrar, el sistema verifica la
informacin (E-1), y se contina con el subflujo
Administrar Registro Tarjeta (S-3).
Si la actividad seleccionada es Servicios, se contina
con el caso de uso Ofrecer Servicios.
Si la actividad seleccionada es Salir, se saldr del
sistema (si an no se ha presionado Registrar, la
nueva informacin se perder.

En la figura 6.19 se ve el diseo de la pantalla para la

administracin de un registro de tarjeta existe. La nica diferencia son
las opciones que se ofrecen: eliminar y actualizar en lugar de
registrar.

(INTERFAZ)
Figura 6.19 Pantalla de Obtener Registro Tarjeta (P-6).

El resto de los subflujos se describen a continuacin. Los subflujos

Ontener Registro Tarjeta (S-2) y Administrar Registro Tarjeta (S-3) se
utilizan para leer y manipular el registro de tarjeta, respectivamente.
El subflujo Actualizar Registro Tarjeta (S-4) se instanciado
presionando el botn correspondiente de la pantalla de 5registro (P-
6). El subflujo Eliminar Registro Tarjeta (S-5) se instancia presionando
el botn correspondiente de la pantalla de registro (P-6).

Subflujos S-2 Obtener Registro tarjeta.

(Continuacin) El sistema obtiene el registro de tarjeta de la base de
datos de registro. Se regresa al flujo anterior.
S-3 Administrar Registro tarjeta.
Se presenta la pantalla Obtener registro tarjeta (P-
6), que incluye el nombre como aparece en la tarjeta,
nmero de tarjeta, el tipo de tarjeta y la fecha de
vencimiento.
El usuario podr seleccionar entre las actividades
Eliminar, Actualizar, Servicios y Salir.

Si el usuario presiona Actualizar se ejecuta el

subflujo Actualizar Registro Tarjeta (S-4).
Subflujos Si el usuario presiona Eliminar, se ejecuta el
(Continuacin subflujo Eliminar Registro Tarjeta (S-5)
Si la actividad seleccionada es Servicios, se
contina con el caso de uso Ofrecer Servicios.
Si la actividad seleccionada es Salir se saldr del
sistema.
S-4 Actualizar Registro tarjeta.
Se actualiza el registro de tarjeta con la informacin
modificada (E-1).
Se contina con el subflujo Administrar Registro
tarjeta (S-2).
S-5 Eliminar Registro tarjeta.
Se elimina el registro de tarjeta y se contina con el
subflujo Crear Registro Tarjeta (S-1).

Las excepciones del caso de uso son las siguientes.

Excepciones E-1 Informacin Completa: falta llenar informacin

indispensable para completar el registro de tarjeta.
Se le vuelve a pedir al usuario que complete el
registro de tarjeta.

CONSULTAR INFORMACIN.

El caso de uso Consultar informacin se instancia a partir de la

pantalla de servicios (P-2), una vez que se haya validado el usuario y
seleccionado el botn correspondiente. Este caso de uso es el ms
complejo de todos los del sistema, ya que incluye tres tipos de
consultas distintas: consulta de horarios de vuelo, consulta de tarifas
y consulta de estado de un vuelo.

El caso de uso se describe a continuacin, y excluye los

subflujos y restricciones que se describen ms adelante.

Caso de uso Consultar informacin

Actores Usuario, base de datos de reservas.
Tipo Bsico
Propsito Permitir a un usuario consultar informacin con el
sistema de reservaciones de vuelo.
Resumen El usuario inicia este caso de uso. Ofrece
funcionalidad para consultar informacin de horarios,
tarifas y estado de vuelos con el sistema de
reservaciones.
Precondicion Se requiere haber ejecutado antes el caso de uso
es Validar usuario.
Flujo Se ejecuta el caso de uso validar usuario.
principal Dependiendo de las opciones seleccionadas por el
 usuario, se continuar con los diversos subflujos de
este caso de uso.

Antes de proseguir con la descripcin del caso de uso, mostramos la

pantalla que resume esta decisin, como se muestra en la figura 6.20.

(Interfaz)
Figura 6.20 Pantalla de seleccin de tipo de consultas (P-7).

Dado que el usuario puede iniciar una consulta de varias pginas

distintas, como se ver posteriormente, se incluye un primer subflujo
para iniciar estas consultas llamado Consultar (S-1), como se observa
a continuacin:

Subflujos S-1 Consultar.

Se despliega la pantalla Consultas (P-7). El usuario
puede seleccionar entre las siguientes actividades:
Horarios, Tarifas, Estado, Servicios y Salir.
Si el usuario presiona Horarios, se activa el
subflujo Consultar Horarios (S-2).
Si el usuario presiona Tarifas, se activa el
subflujo Consultar Tarifas (S-4.
Si el usuario presiona Estado, se activa el
subflujo Consultar Estado (S-6).
Si el usuario presiona Servicios, se pasa al caso
de uso Ofrecer Servicios.
Si el usuario presiona Salir, sale del sistema.

En la figura 6.21 se muestra el diseo de la pantalla para la consulta

de horarios de vuelos, correspondiente al subflujo Consultar Horarios
(S-2).

(Interfaz)
Figura 6.21 Pantalla de Consulta de horarios de vuelos (P-8).

En la figura 6.22 se muestra el diseo de la pantalla para el resultado

de la consulta de horarios de vuelos, correspondiente al subflujo
Devolver Horarios

(Interfaz)
Figura 6.22 Pantalla de Resultados de consulta de horarios de vuelos
(P-9).

Los subflujos Consultar Horarios (S-2) Devolver Horarios (S-3) se

muestran a continuacin:

Subflujos S-2 Consultar Horarios.

(Continuacin) Se presenta al usuario la pantalla Consulta
horarios (P-8). Esta pantalla debe ser llena con
informacin de ciudad de origen y destino, y
preferencias opcionales de: aerolnea, horario y una
opcin de vuelo directo.

El usuario puede seleccionar las siguientes

actividades:
Consultar, Servicios y Salir.
Si el usuario presiona Consultar, el sistema recibe
la informacin (E-1,E-2), se contina con el subflujo
Devolver Horarios (S-3).
Si el usuario presiona Servicios, se contina con el
caso de uso Ofrecer Servicios.
Si el usuario presiona Salir se sale del sistema.

S-3 Devolver Horarios.

Se presenta la pantalla Resultado Horarios (P-9)
que contiene informacin sobres los diferentes
vuelos encontrados. La informacin incluye la
aerolnea, el vuelo, los das, el horario y las
restricciones, tales como fecha de inicio o
terminacin del vuelo. Al principio de cada fila se
encuentra una opcin de seleccin para obtener
informacin adicional sobre el vuelo.
El usuario puede seleccionar entre las siguientes
opciones: +, -, Nueva consulta, Servicios y
Salir.

Si el usuario presiona +, se muestran resultados

adicionales de horarios. Se contina al inicio de este
subflujo.
Si el usuario presiona -, se muestran resultados
anteriores de horarios. Se contina al inicio de este
subflujo.
Si el usuario presiona Nueva Consulta, se contina
con el caso de uso Ofrecer servicios.
Si el usuario presiona Salir, sale del sistema.
La figura 6.25 ilustra el diseo de la pantalla para la consulta de
estado de vuelo. Correspondiente al subflujo Consultar Estado (S-6).

(Interfaz)

Figura 6.25 Pantalla de consulta de estado de vuelo (P-12).

En la figura 6.26 se muestra el diseo de la pantalla para el resultado

de la consulta de estado de vuelo, correspondiente al subflujo
Devolver Estado (S-7).

(Interfaz)
Figura 6.26 Pantalla de resultado de consulta de estado de vuelo (P-
13).

Los subflujos de Consultar estado (S-6) y Devolver Estado (S-7) se

muestran a continuacin:

Subflujos S-6 Consultar Estado.

(Continuacin) Se presenta al usuario la pantalla Consultar
estado (P-12). Esta pantalla debe ser llena con
informacin de la ciudad de origen y el destino, la
aerolnea, el nmero de vuelo y la opcin de vuelo
de da consultado.

El usuario puede seleccionar alguna de las

siguientes actividades: Consultar, Servicios y
Salir.
Si el usuario presiona Consultar, el sistema recibe
la informacin (E-1, E-2) y se contina con el
subflujo Devolver estado (S-7).
Si el usuario presiona Servicios, se contina con el
caso de uso Ofrecer Servicios.
Si el usuario presiona Salir, sale del sistema.
S-7 Devolver Estado.
Se presenta la pantalla Resultado estado (P-13),
que contiene informacin sobre el vuelo, como su
estado, por ejemplo, confirmado, retrasado,
cancelado.
El usuario puede seleccionar entre las siguientes
opciones: Nueva Consulta, Servicios y Salir.
Si el usuario presiona Nueva Consulta, se contina
con el subflujo Consultar Estado (S-6).
Si la actividad seleccionada es Servicios, se
contina con el caso de uso Ofrecer Servicios.
Las excepciones del caso de uso son las siguientes:

Excepciones E-1 Informacin incompleta: falta llenar informacin

indispensable, la ciudad de origen o de destino. Se
le vuelva a pedir al usuario la informacin.
E-2 Informacin Invlida: una de las entradas de la
solicitud es incorrecta.

HACER RESERVACIN.

EL CASO DE USO Hacer Reservacin se instancia a partir de la

pantalla de Servicios (P-2), una vez se haya validado el usuario y
seleccionado el botn correspondiente.

El caso de uso se describe a continuacin, excluyendo los subflujos y

excepciones que se describen ms adelante.

Caso de uso Hacer Reservacin

Actores Usuario, Base de Datos de Reservaciones.
Tipo Bsico.
Propsito Permitir a un usuario hacer reservaciones con el
sistema de reservaciones de vuelo.
Resumen El usuario inicia este caso de uso. Ofrece
funcionalidad para crear, obtener, modificar y
eliminar reservaciones de vuelos con el sistema de
reservaciones.
Precondicion Se debe haber ejecutado anteriormente el caso de
es uso Validar Usuario.
Flujo Se ejecuta el caso de uso Validar Usuario.
Principal Dependiendo de las opciones seleccionadas por el
usuario, se continuar con los diversos subflujos de
este caso de uso.

En la figura 6.27 se muestra el diseo de la pantalla para crear u

obtener una reservacin, si se cuenta con una clave.

Figura 6.27 Pantalla de insercin de Clave de reservaciones (P-14).

El subflujo Solicitar Clave Reservacin (S-1) se muestra a

continuacin.
Subflujo S-1 Solicitar Clave Reservacin.
Se presenta al usuario la pantalla Clave Reserva
(P-14). El usuario puede seleccionar entre las
siguientes actividades: Crear, Obtener,
Servicios y Salir.

Si el usuario presiona Crear se ejecutar el

subflujo Crear Reservacin (S-2).
Si el usuario presiona Obtener (E-1), se ejecuta el
subflujo Obtener Reservacin (S-3).
Si la actividad seleccionada es Servicios, se
contina con el caso de uso Ofrecer Servicios.
Si la actividad seleccionada es Salir, se saldr del
sistema.

En la figura 6.28 se muestra el diseo de la pantalla para la solicitud

de reservaciones