Arquitectura de Clases.

El modelo de anlisis tiene como objetivo generar una arquitectura de

objetos que sirva como base para el diseo posterior del sistema. Como
se discuti en la introduccin del libro, dependiendo del tipo de aplicacin
existen diversas arquitecturas que se pueden utilizar, siendo de nuestro
inters aquellas arquitecturas especialmente diseadas para el manejo
de los sistemas de informacin, las cuales involucran ricas interfaces de
usuario y accesos a base de datos como aspectos fundamentales de la
arquitectura.
En trmino de las propias arquitecturas, stas se distinguen segn la
organizacin de la funcionalidad que ofrecen los objetos dentro de ellas o
la dimensin de los objetos. Esta dimensin corresponde a los diferentes
tipos de funcionalidad que manejan los objetos dentro la arquitectura.
Por ejemplo, en el caso de funcionalidad para el manejo de interfaces y
base de datos, si existen tipos distintos de objetos para el manejo de
cada una de estas por separado, entonces se considera que la
arquitectura es de dos dimensiones. Por el contrario, si todos los objetos
manejan de manera indistinta los dos tipos de funcionalidades, entonces
se considera que la arquitectura es de una sla dimensin.
Si aplicamos el concepto de dimensin a los mtodos estructurados,
podemos ver que estos consisten de dos dimensiones, correspondientes
a funciones y datos. Las funciones representan un eje de
comportamiento que no guarda informacin, mientras que los datos se
ubican en un eje de informacin que no contiene comportamiento. En
general, ejes de funcionalidad pueden corresponder a distintos tipos de
funcionalidades, como se ve al contrastar funciones y datos versus
manejo de interfaces y bases de datos. Sin embargo, la pregunta ms
importante que uno se hace respecto al nmero y tipo de dimensiones
es: Si se disea un sistema con mltiples dimensiones, se obtendra un
sistema ms robusto y sensible a modificaciones? Ante todo esta
pregunta se relaciona con el concepto de modularidad, siendo muy
aceptado que cuanto mayor sea la modularidad de un sistema mayor es
su robustez y extensibilidad. La respuesta particular a la pregunta tiene
que ver con qu tan independiente sea un eje de funcionalidad del otro,

ya que en el caso de los mtodos estructurados, usualmente se debe

modificar las funciones cada vez que se modifica la estructura de
informacin, lo cual no es algo deseable. Si logramos ejes de
funcionalidad ortogonales, el efecto de cambios en una dimensin no
debe afectar a las otras dimensiones. Y aunque estas dimensiones no
son del todo ortogonales, si son lo suficientemente independientes se
puede limitar el efecto de posibles cambios. En relacin al nmero de
dimensiones, esto depende de la funcionalidad que la arquitectura debe
manejar, algo que a su vez depende del tipo de aplicacin que se est
desarrollando.
En el caso de los sistemas de informacin, uno de las tipos de
arquitecturas mas importantes es la arquitectua MVC Modelo, Vista,
Control (Model, View, Control) popularizada por los ambientes de
desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones
principales: Modelo (informacin), Vista (presentacin) y Control
(comportamiento) como se muestra en la Figura 7.2.

Figura 7.2 Diagrama de tres dimensiones correspondiente a la

arquitectura MVC Modelo, Vista, Control.
La vista o presentacin de la informacin corresponde a las interfaces
que se le presentan al usuario para el manejo de la informacin, donde
por lo general pueden existir mltiples vistas sobre un mismo modelo.
Tpicamente la informacin representa el dominio del problema y es
almacenada en una base de datos. Por otro lado el control corresponde
a la manipulacin de la informacin a travs de sus diversas
presentaciones. Y aunque existe cierta dependencia entre estas tres
dimensiones se considera que la manera de presentar la informacin es
independiente de la propia informacin y de cmo esta se controla. Sin
embargo, cada una de ellas probablemente experimente cambios a lo
largo de la vida del sistema, donde el control es el ms propenso a ser

modificado, seguido de la vista y finalmente el modelo. En el modelo de

anlisis descrito aqu utilizaremos como base la arquitectura MVC para
capturar estos tres aspectos de la funcionalidad, como se muestra en la
Figura 7.3.
Es importante notar la correspondencia con las tres dimensiones
utilizadas durante el modelo de requisitos. La razn de ser de las tres
dimensiones del modelo de requisitos realmente se deriva para lograr
una rastreabilidad con la arquitectura que se desarrollar en el modelo
de anlisis.

Figura 7.3 Diagrama de tres dimensiones correspondiente a la

arquitectura del modelo de anlisis basado en el modelo de casos
de uso.
La arquitectura para el modelo de anlisis ser implementada mediante
tres tipos o estereotipos de objetos como elementos bsicos de
desarrollo como veremos a continuacin.
Clases con Estereotipos
El tipo de funcionalidad o la razn de ser de un objeto dentro de una
arquitectura se le conoce como su estereotipo. Para los sistemas de
informacin la arquitectura del sistema segn nuestro modelo de anlisis
se basa en tres estereotipos bsicos de objetos:
El estereotipo entidad para objetos que guarden informacin sobre
el estado interno del sistema, a corto y largo plazo,
correspondiente al dominio del problema. Todo comportamiento
naturalmente acoplado con esta informacin tambin se incluye en
los objeto entidad. Un ejemplo de un objeto entidad es un registro

de usuario con sus datos y comportamiento asociados.

El estereotipo interface para objetos que implementen la

presentacin o vista correspondiente a las interfaces del sistema
hacia el mundo externo, para todo tipo de actores, no slo usuarios
humanos. Un ejemplo de un objeto interface es la funcionalidad de
interface de usuario para insertar o modificar informacin sobre el
registro de usuario.

El estereotipo control para objetos que implementen el

comportamiento o control especificando cuando y como el sistema
cambia de estado, correspondiente a los casos de uso. Los objetos
control modelan funcionalidad que no se liga naturalmente con
ningn otro tipo de objeto, como el comportamiento que opera en
varios objetos entidad a la vez, por ejemplo, hacer alguna
computacin y luego devolver el resultado a un objeto interface. Un
ejemplo tpico de objeto control es analizar el uso del sistema por
parte de algn usuario registrado y presentar tal informacin
posteriormente. Este comportamiento no le pertenece a ningn
objeto entidad u objeto interface especfico.
Ntese que no hay ninguna restriccin a los diferentes estereotipos que
puedan utilizarse, no solamente las tres anteriores. La notacin de UML
para un estereotipo se muestra en la Figura 7.4.

<< estereotipo >>

Nombre de la Clase

Figura 7.4 Diagrama de clase con estereotipo.

Los tres estereotipos correspondientes a las tres dimensiones para la
arquitectura del modelo de anlisis se muestra en la Figura 7.5.

Figura 7.5 Diagrama de clase para los tres estereotipo.

Considerando que habr interaccin entre los diferentes tipos de objetos,
existir cierto traslape en la funcionalidad que los objetos ofrecen. Como
se mencion anteriormente, este traslape deber minimizarse para
asegurar una buena extensibilidad, donde tpicamente, cada tipo de
objeto captura por lo menos dos de las tres dimensiones. Sin embargo,
cada uno de ellos tiene cierta inclinacin hacia una de estas dos
dimensiones, como se muestra en la Figura 7.6.

Figura 7.6 Diagrama mostrando traslape en los estereotipos de los

objetos. Clases para Casos de Uso
Cuando se trabaja en el desarrollo del modelo de anlisis, normalmente
se trabaja con un caso de uso a la vez. Para cada caso de uso se
identifican los objetos necesarios para su implementacin. Se identifican
estos objetos segn sus estereotipos para corresponder a la
funcionalidad ofrecida en cada caso de uso. Se define explcitamente
qu objeto es responsable de cual comportamiento dentro del caso de
uso. Tpicamente se toma un caso de uso y se comienza identificando
los objetos interface necesarios, continuando con los objetos entidad y
finalmente los objetos control. Este proceso se contina a los dems

casos de uso. Dado que los objetos son ortogonales a los casos de
uso, en el sentido de que un objeto puede participar en varios casos de
uso, este proceso es iterativo. Esto significa que cuando un conjunto de
objetos ya existe, estos pueden modificarse para ajustarse al nuevo caso
de uso. La meta es formar una arquitectura lo ms estable posible,
reutilizando el mayor nmero de objetos posible. De tal manera, la
descripcin original de los casos de uso se transforma a una descripcin
en base a los tres tipos de objetos, como se muestra en la Figura 7.7.

Figura 7.7 La funcionalidad de cada caso de uso es asignada a

objetos distintos y de acuerdo a los estereotipos de dichos objetos.
Se parte el caso de uso de acuerdo a los siguientes principios:
La funcionalidad de los casos de uso que depende directamente
de la interaccin del sistema con el mundo externo se asigna a los
objetos interface.
La funcionalidad relacionada con el almacenamiento y manejo de
informacin del dominio del problema se asigna a los objetos
entidad.
La funcionalidad especfica a uno o varios casos de uso y que no
se ponen naturalmente en ningn objeto interface o entidad se
asigna a los objetos control. Tpicamente se asigna a un slo
objeto control y si ste se vuelve muy complejo se asignan objetos
control adicionales.
Por ejemplo, consideremos el caso de uso imprimir archivo, usado como
ejemplo en el captulo 6 y que se muestra nuevamente en la Figura 7.8.

Figura 7.8 Caso de uso imprimir archivo.

Para el caso de uso imprimir archivo se pueden utilizar los objetos
(descritos segn el diagrama de clases correspondiente) que se
muestran en la Figura 7.9. Se utilizan dos clases interface: Interface
Archivo e Interface Impresora, cinco clases entidad: Cola, Archivo con
sus subclases Archivo Texto, Archivo Formateado y Archivo Grfico y
una clase control: Servidor Impresora.

Figura 7.9 Objetos identificados para el caso de uso imprimir

archivo.
La arquitectura se completa generando asociaciones entre las distintas
clases como se muestra en la Figura 7.10.

Figura 7.10 Objetos identificados para el caso de uso imprimir

archivo mostrando asociaciones entre si aunque omitiendo
multiplicidad
El desafo para generar esta correspondencia entre objetos o clases y
los casos de uso es precisamente decidir cuales y cuantos objetos deben
utilizarse en dicha correspondencia.

7.2 Identificacin de Clases segn Estereotipos

Para llevar a cabo la transicin del modelo de requisitos al modelo de

anlisis se deben identificar los objetos necesarios para implementar
todos los casos de uso. La arquitectura de objetos debe considerar los
tres tipos de estereotipos de objetos como se discuti anteriormente.
Para lograr esto se debe identificar primero las clases interface, luego
las entidad y finalmente las de control. En general, se desea asignar la
funcionalidad ms especializada correspondiente a la poltica de la
aplicacin a los objetos control, la cual depende y afecta al resto de los
objetos. Por otro lado, los objetos entidad e interface deben contener
funcionalidad ms bien local limitando su efecto en los dems objetos. El
trabajo del analista consiste en distribuir lo mejor posible el
comportamiento especificado en el modelo de requisitos en los
diferentes tipos de objetos de la arquitectura de anlisis. La asignacin
de funcionalidad es bastante difcil en la prctica afectando de gran
manera la robustez y mantenimiento del sistema. Los buenos analistas
consideran cambios potenciales al sistema a la hora de llevar a cabo
este proceso.
En general, los cambios mas comunes a un sistema son los cambios en
su funcionalidad e interfaces. Cambios a las interfaces deben afectar
tpicamente solo los objetos interface. Cambios a la funcionalidad son
mas difciles, ya que la funcionalidad puede abarcar todos los tipos de
objetos. Si la funcionalidad esta ligada a la informacin existente, tales
cambios afectan al objeto entidad representado esa informacin, o

puede involucrar mltiples objetos incluyendo objetos control.

Tpicamente, esta funcionalidad se define en uno o varios casos de uso
y se asigna a uno o varios objetos control.
A continuacin describimos en ms detalles el proceso de identificacin
de los tres tipos de objetos.
Interface
Toda la funcionalidad especificada en las descripciones de los casos de
uso que depende directamente de los aspectos externos del sistema se
ubica en los objetos de interfaces. Es a travs de estos objetos que se
comunican los actores con el sistema. La tarea de un clase interface es
traducir los eventos generados por un actor en eventos comprendidos
por el sistema, y traducir los eventos del sistema a una presentacin
comprensible por el actor.
Las clases interface, en otras palabras, describen comunicacin
bidireccional entre el sistema y los actores. Las clases interface son
bastante fciles de identificar, donde se cuenta con al menos tres
estrategias:
1. Se pueden identificar en base a los actores.
2. Se pueden identificar en base a las descripciones de las interfaces
del sistema que acompaan al modelo de requisitos.
3. Se pueden identificar en base a las descripciones de los casos de
uso y extraer la funcionalidad que es especfica a las interfaces.
Comenzaremos utilizando la primera estrategia correspondiente a de
actores. Cada actor concreto necesita su propia interface para su
comunicacin con el sistema. En muchos casos un actor puede
necesitar de varios objetos interface. Es evidente que los objetos
interface no son totalmente independientes de cada uno ya que deben
saber de la existencia de los dems para poder resolver ciertas tareas.
Por ejemplo para Reservar un Asiento en un Vuelo el usuario debe
interactuar con las interfaces que a su vez se comunican con las
interfaces que se comunican con la base de datos del sistema de
reservaciones.

Una vez identificado los objetos interfaces, es ms fcil modificar

posteriormente las interfaces de un sistema. Al tener todo lo relacionado
a una interface en un objeto, cada cambio a la interface ser local a ese
objeto. Como los cambios a las interfaces son muy comunes, es vital
que estos sean extensibles.
Existen dos tipos diferentes de interfaces a modelar, interfaces a otros
sistemas e interfaces a los usuarios humanos.
En el caso de objetos interface que se comunican con otros
sistemas, es muy comn que la comunicacin se describa
mediante protocolos de comunicacin. Los objetos interface
pueden traducir las salidas del sistema a un protocolo de
comunicacin estandarizado, o simplemente enviar eventos
producidos internamente sin conversiones complejas. Una ventaja
de esto, es que si se cambia el protocolo, estos cambios sern
locales al objeto interface. Un mayor problema ocurre cuando
existen seales continuas del mundo externo, como en los
sistemas de medicin o control. Entonces los objetos interface
deben muestrear la seal de entrada, o interrumpir cuando ciertos
valores exceden un valor umbral, ya que internamente en el
sistema slo existe comunicacin discreta mediante eventos. Los
objetos interface deben entonces traducir la informacin continua a
informacin discreta. Problemas de cuantificacin pueden
aparecer y deben ser resueltos.

En el caso de los objetos interface que se comunican con usuarios

humanos, los objetos interface pueden ser complejos para
modelar. Existen muchas tcnicas diferentes para un buen diseo
de interfaces, como el diseo de Interfaces Grficas de Usuario
(GUI - Graphical User Interface), Sistemas de Manejo de Ventanas
de Usuario (UIMS - User Interface Management Systems) y
sistemas de Interface de Programacin de Aplicacin (API). Es
fundamental que el usuario tenga una imagen lgica y coherente
del sistema. En las aplicaciones interactivas es comn que la
interface de usuario sea una parte mayor (hasta 80%) de la
aplicacin completa.

Aunque cada tipo de objeto tiene un propsito distinto, es evidente que

los objetos interface tienen como propsito principal las presentaciones.
Sin embargo, tambin pueden manejar informacin y tener
comportamiento. Cunta informacin y comportamiento debe ligarse a
un objeto interface debe decidirse de manera individual. En un extremo,
el objeto interface solo enva el evento que recibe del actor a otros
objetos en el sistema, sin participar activamente en el curso de eventos.
En el otro extremo, el comportamiento del objeto interface es muy
complejo donde la informacin se integra en el objeto interface y puede
funcionar casi independiente de otros objetos. Generalmente, el
potencial para cambios debe afectar la decisin de qu comportamiento
en el caso de uso debe ligarse a un objeto interface particular. Cualquier
cambio en la funcionalidad directamente ligada a la interface debe ser
local al objeto interface, mientras que otros cambios no deben afectarlo.
Esto es algo que debe aprenderse y aplicarse en todas las actividades
del modelado.
Para identificar qu parte del flujo de un caso de uso debe asignarse a
los objetos interface, se debe analizar las interacciones entre los actores
y los casos de uso. Esto significa buscar aspectos con una o ms de las
siguientes caractersticas:
Presentacin de informacin al actor que requiera informacin de
regreso.
Funcionalidad que cambie si cambia el comportamiento del actor.
Flujo de accin que dependa de un tipo de interface particular.
En el ejemplo del sistema de reservaciones de vuelo, cada uno de
los actores concretos, Cliente, Base de Datos de Registro y Base de
Datos de Reserva, necesita su propio objeto interface al sistema, como
se muestra en la Figura 7.11. El Usuario necesita de las pantallas de
presentacin, mientras que la Base de Datos de Registro y Base de
Datos de Reservasnecesitan sus propias interfaces para poder
intercambiar informacin con el sistema.

Figura 7.11 Clases interface para el sistema de reservaciones de

vuelo identificados directamente de los actores.
Aunque estas tres clases interface son suficiente para interactuar con los
actores, necesitamos incluir un nmero de clases interface adicionales
correspondientes a cada pantalla que se le presenta al usuario, como se
especific inicialmente durante el modelo de requisitos. Por otro lado
pueden haber clases interfaces adicionales necesarias para manejos
ms especializados de las bases de datos, algo que postergaremos
hasta el diseo. A continuacin describimos las clases interface
necesarias para cada caso de uso de acuerdo a la documentacin
generada durante el modelo de requisitos del captulo anterior. Se
requieren todas las pantallas (a las cuales llamaremos pginas por ser
una aplicacin en el Web) con las cuales los casos de uso se relacionan.
Ntese que a pesar de que existen mltiples ligas entres pginas para
simplificar la navegacin, slo se identifican como parte del caso de uso
aquellas que se consideran esenciales para la ejecucin del caso de
uso.
Registrar Usuario: Se interacta con los actores Usuario y Base
de Datos Registros a travs de las clases interface
InterfaceUsuario e InterfaceBaseDatosRegistro, respectivamente.
Se utiliza la pantalla principal del sistema (P-1) dado que el caso
de uso se instancia mediante el botn Registrarse por Primera
Vez o mediante la validacin de un usuario existente (esta
validacin se hace a travs del caso de uso Validar Usuario que es
incluido en Registrar Usuario). Esta pantalla ser implementada
por la clase interfacePginaPrincipal. Asimismo se debe incluir la
clase interface PginaServicio correspondiente a la pantalla del
men de servicios (P-2) dado que se puede accesar este caso de
uso a travs del botn Obtener Registro. Adicionalmente se

deben incluir clases interface correspondientes a las pantallas

propias de este caso de uso, que son las pantalla de registro de
usuario por primera Vez (P-3) y de obtener registro (P-4). A las dos
clases interface correspondientes las
llamaremos PginaCrearRegUsuario y PginaObtenerRegUsuario,
respectivamente. En la Figura 7.12 se muestran las clases
interface identificadas en este caso de uso.

Figura 7.12 Clases interface identificadas del caso uso

Registrar Usuario.
Validar Usuario: Se interacta con los actores Usuario y Base de
Datos Registros a travs de las clases interface InterfaceUsuario e
InterfaceBaseDatosRegistro, respectivamente. Se utiliza
nicamente la pantalla principal del sistema (P-1) para la
validacin de usuario. Recurdese que pantallas adicionales como
las de mensajes o error no las estamos considerando an para
nuestro prototipo. Por lo tanto se incluye nicamente la clase
interface PginaPrincipal adems de las dos anteriores. En la
Figura 7.13 se muestran las clases interface identificadas en este
caso de uso.

Figura 7.13 Clases interface identificadas del caso uso Validar

Usuario.
Registrar Tarjeta: Se interacta con los actores Usuario y Base
de Datos Registros a travs de las clases interface
InterfaceUsuario e InterfaceBaseDatosRegistro, respectivamente.
Se utilizan las pantallas de registro de tarjeta por primera vez (P5) y registro de tarjeta (P-6). A las dos clases interface
correspondientes las llamaremosPginaCrearRegTarjeta y
PginaObtenerRegTarjeta, respectivamente. Adems se incluyen
las clases PginaCrearRegUsuario y
PginaObtenerRegUsuario correspondientes a la pantallas de
registro de usuario por primera Vez (P-3) y de obtener registro (P4) de donde se llama la funcionalidad de este caso de uso. En la
Figura 7.14 se muestran las clases interface identificadas en este
caso de uso.

Figura 7.14 Clases interface identificadas del caso uso Registrar

Tarjeta.
Consultar Informacin: Se interacta con los actores Usuario y
Base de Datos Reservas a travs de las clases
interface InterfaceUsuario e
InterfaceBaseDatosReserva,respectivamente. Se utiliza la pantalla
principal del sistema (P-1) dado que el caso de uso se instancia
mediante la validacin de un usuario existente (esta validacin se
hace a travs del caso de uso Validar Usuario que es incluido en
Registrar Usuario). Esta pantalla ser implementada por la clase
interface PginaPrincipal. Asimismo se debe incluir la clase
interface PginaServicio correspondiente a la pantalla del men de

servicios (P-2) dado que se puede accesar este caso de uso a

travs del botn Consultar Informacin.Adicionalmente se deben
incluir clases interface correspondientes a las pantallas propias de
este caso de uso, que son las pantalla de seleccin de tipo de
consulta (P-7), consulta de horarios de vuelos (P-8), resultado de
consulta de horarios de vuelos (P-9), consulta de tarifas de
vuelos (P-10), resultado de consulta de tarifas de vuelos (P11), consulta de estado de vuelo (P-12) y resultado de consulta de
estado de vuelo (P-13). A las clases interface correspondientes las
llamaremos PginaConsultas, PginaConsultaHorarios,
PginaResultadoHorarios, PginaConsultaTarifas,
PginaResultadoTarifas, PginaConsultaEstado y
PginaResultadoEstado, respectivamente. En la Figura 7.15 se
muestran las clases interface identificadas en este caso de uso.

Figura 7.15 Clases interface identificadas del caso uso Consultar

Informacin
Hacer Reservacin: Se interacta con los actores Usuario y Base
de Datos Reservas a travs de las clases
interface InterfaceUsuario e InterfaceBaseDatosReserva,
respectivamente. Se utiliza la pantalla principal del sistema (P1) dado que el caso de uso se instancia mediante la validacin de
un usuario existente (esta validacin se hace a travs del caso de

uso Validar Usuario que es incluido en Registrar Usuario). Esta

pantalla ser implementada por la clase
interface PginaPrincipal. Asimismo se debe incluir la clase
interface PginaServicio correspondiente a la pantalla del men de
servicios (P-2) dado que se puede accesar este caso de uso a
travs del botn Hacer Reservacin. Adicionalmente se deben
incluir clases interface correspondientes a las pantallas propias de
este caso de uso, que son las pantalla de insercin de clave de
reserva (P-14), solicitud de reserva de vuelos (P-15) y rcord de
reserva de vuelos (P-16). A las clases interface correspondientes
las llamaremos PginaClaveReservas,
PginaCrearReservaVuelos y
PginaRecordReservaVuelos, respectivamente. En la Figura 7.16
se muestran las clases interface identificadas en este caso de
uso.

Figura 7.16 Clases interface identificadas del caso uso Hacer

Reservacin.
Pagar Reservacin: Se interacta con los actores Usuario y Base
de Datos Reservas a travs de las clases
interface InterfaceUsuario e InterfaceBaseDatosReservas,
respectivamente. Se utilizan las pantallas de pago de reserva de
vuelos (P-17) y reembolso de reserva de vuelos (P-18). A las dos
clases interface correspondientes las
llamaremosPginaPagoReserva y
PginaReembolsoReserva, respectivamente. Adems se incluyen
las clases PginaCrearRegUsuario y
PginaObtenerRegUsuario correspondientes a las pantalla de
solicitud de reserva de vuelos (P-15) y rcord de reserva de
vuelos (P-16) de donde se llama la funcionalidad de este caso de
uso. En la Figura 7.17 se muestran las clases interface

identificadas en este caso de uso.

Figura 7.17 Clases interface identificadas del caso uso Pagar

Reservacin.
En la Tabla 7.1 se muestran el resumen los casos de uso identificados
durante el modelo de requisitos junto con los actores y clases interface
correspondientes.
Caso de
Uso

Actores

Clases Interface

Registrar
Usuario

InterfaceUsuario, PginaPrincipal,
PginaServicio,
Usuario, Base de
PginaCrearRegUsuario,
Datos Registros
PginaObtenerRegUsuario,
InterfaceBaseDatosRegistro

Validar
Usuario

Usuario, Base de InterfaceUsuario, PginaPrincipal,

Datos Registros InterfaceBaseDatosRegistro

Usuario,
Base de

InterfaceUsuario,
PginaCrearRegUsuario,
Registrar Tarjeta PginaObtenerRegUsuario,
Datos Registros PginaCrearRegTarjeta,
PginaObtenerRegTarjeta,
InterfaceBaseDatosRegistro

InterfaceUsuario, PginaPrincipal,
PginaServicio, PginaConsultas,
PginaConsultaHorarios,
PginaResultadoHorarios,
Consultar Usuario, Base de
PginaConsultaTarifas,
Informacin Datos Reservas
PginaResultadoTarifas,
PginaConsultaEstado,
PginaResultadoEstado,
InterfaceBaseDatosReserva

InterfaceUsuario, PginaPrincipal,
PginaServicio, PginaClaveReservas,
Hacer
Usuario, Base de
PginaCrearReservaVuelos,
Reservacin Datos Reservas
PginaRecordReservaVuelos,
InterfaceBaseDatosReserva
InterfaceUsuario,
PginaCrearReservaVuelos,
Pagar
Usuario, Base de PginaRecordReservaVuelos,
Reservacin Datos Reservas PginaPagoReserva,
PginaReembolsoReserva,
InterfaceBaseDatosReserva

Tabla 7.1 Relacin entre casos de uso, actores y clases interface

para el sistema de reservaciones de vuelo.
Entidad
Se utilizan objetos entidad para modelar la informacin que el sistema
debe manejar a corto y largo plazo. La informacin a corto plazo existe
por lo general durante la ejecucin del caso de uso, mientras que la
informacin a largo plazo sobrevive a los casos de uso, por lo cual es
necesario guardar esta informacin en alguna base de datos.
Adicionalmente, se debe incluir comportamiento para manejar la propia
informacin local al objeto entidad. Los objetos entidad se identifican en
los casos de uso, donde la mayora se identifican del modelo del dominio
del problema en el modelo de requisitos. Objetos entidad adicionales
pueden ser mas difciles de encontrar. Es muy comn que se identifiquen
muchos objetos entidad, aunque se debe limitar estos objetos a los
realmente necesarios para la aplicacin, siendo esto lo ms difcil del
proceso de identificacin. Es por lo tanto esencial trabajar de forma
organizada cuando se modelan los objetos entidad. Las necesidades de
los casos de uso deben ser las guas y solamente aquellos objetos
entidad que puedan justificarse de la descripcin del caso de uso deben
ser incluidos. No es siempre fcil decidir cuando cierta informacin debe
ser modelada como un objeto entidad o como un atributo. Esto depende
de cmo se usar la informacin, si sta se maneja de forma separada,
debe modelarse como un objeto entidad, mientras que la informacin
que esta acoplada fuertemente a alguna otra informacin y nunca se usa
por si misma debe modelarse como un atributo de un objeto entidad.
Todo depende de cmo los casos de uso manejen la informacin. Cierta
informacin puede modelarse como objeto entidad en un sistema,

mientras que en otro sistema puede ser un atributo.

Es tambin difcil identificar qu operaciones y cuales atributos sern
incluidos dentro de los objetos entidad. Dado que la nica forma para
manipular un objeto entidad es por medio de sus operaciones, las
operaciones identificadas deben ser suficientes para manipular
completamente al objeto entidad. La descripcin detallada de los casos
de uso es de nuevo un medio extremadamente valioso para encontrar
las operaciones deseadas. El flujo completo de eventos que se describe
en los casos de uso, permite extraer las operaciones que conciernen a
los objetos entidad.
Las operaciones asignadas a los objetos entidad pueden ser ms o
menos complejas. En el caso menos complejo un objeto entidad consta
slo de operaciones de acceso a los valores de los atributos. En el caso
ms complejo un objeto entidad puede tener flujos de eventos ms all
de simples accesos a los valores de los atributos. Sea cual sea la
complejidad de estas operaciones, el objetivo es que stas slo
dependan y afecten informacin local. La siguiente es una lista de las
operaciones tpicas que deben ser ofrecidas por un objeto entidad:
Guardar y traer informacin
Comportamiento que debe modificarse si el objeto entidad cambia
Crear y remover el objeto entidad
Dada la complejidad de obtener operaciones, esto es un aspecto que se
deja para la etapa de diseo, como se mencion anteriormente.
Durante la identificacin de objetos entidad, se encontrar que objetos
similares aparecen en varios casos de uso. En tales circunstancias se
debe verificar si deben ser los mismos objetos entidad o si deben haber
objetos entidad separados. Incluso si los casos de uso no interactuan de
la misma manera sobre los objetos, el objeto entidad puede ofrecer
operaciones que satisfagan las necesidades de diversos casos de uso.
Si se considera que dos objetos entidad representan un mismo objeto,
las operaciones, atributos y asociaciones tambin tienen que integrarse.
De manera similar, se puede hacer una identificacin preliminar de los
atributos, sin embargo estos se desarrollarn ms ampliamente durante

el modelo de diseo.
A continuacin describimos las clases entidad necesarias para cada
caso de uso de acuerdo a la documentacin generada durante el modelo
de requisitos del captulo anterior. Ntese que las clases son obtenidas
del dominio del problema generado en el modelo de requisitos. Si fueran
necesarias nuevas clases entidad habra que modificar el dominio del
problema anterior.
Registrar Usuario: Este caso de uso requiere guardar informacin
exclusivamente acerca del usuario, lo que se hace en la clase
entidad RegistroUsuario. En la Figura 7.18 se muestran las clases
entidad identificadas en este caso de uso.

<< Entidad >>

RegistroUsuario

Figura 7.18 Clases entidad identificadas del caso uso

Registrar Usuario.
Validar Usuario: Este caso de uso requiere validar informacin
exclusivamente guardada en el registro de usuario, lo que se hace
en la clase entidad RegistroUsuario, utilizada tambin por el caso
de uso RegistrarUsuario. En la Figura 7.19 se muestran las clases
entidad identificadas en este caso de uso.

<< Entidad >>

RegistroUsuario

Figura 7.19 Clases entidad identificadas del caso uso Validar

Usuario
Registrar Tarjeta: Este caso de uso requiere guardar informacin
exclusivamente acerca de la tarjeta del usuario, lo que se hace en
la clase entidad RegistroTarjeta. En la Figura 7.20 se muestran las
clases entidad identificadas en este caso de uso.
<< Entidad >>
RegistroTarjeta

Figura 7.20 Clases entidad identificadas del caso uso Registrar

Tarjeta.
Consultar Informacin: Este caso de uso requiere de toda la
informacin relacionada con consultas. Se pueden tomar las
clases del dominio del problema y quitar aquellas relacionadas con
registros y reservaciones. De tal manera tenemos las clases
entidad Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo y
Horario. En la Figura 7.21 se muestran las clases entidad
identificadas en este caso de uso.

Figura 7.21 Clases entidad identificadas del caso uso

Consultar Informacin
Hacer Reservacin: Este caso de uso requiere de toda la
informacin relacionada con reservaciones. Se pueden tomar las
clases del dominio del problema y quitar aquellas relacionadas con
registros. De tal manera tenemos las clases entidad Asiento,
Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario,
ViajeroFrecuente, Pasajero y Reservacin. En la Figura 7.22 se

muestran las clases entidad identificadas en este caso de uso.

Figura 7.22 Clases entidad identificadas del caso uso Hacer

Reservacin.
Pagar Reservacin: Este caso de uso requiere de toda la
informacin relacionada con reservaciones. Se pueden tomar las
clases del dominio del problema y quitar aquellas relacionadas con
registro de usuario. En este caso de uso es necesario el registro
de tarjeta para poder completar el pago o el reembolso. De tal
manera tenemos las clases entidadAsiento, Avin, Tarifa,
Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero,
Reservacin y RegistroTarjeta. En la Figura 7.23 se muestran las
clases entidad identificadas en este caso de uso.

Figura 7.23 Clases entidad identificadas del caso uso Pagar

Reservacin.

En la Tabla 7.2 se muestran el resumen de los casos de uso

identificados durante el modelo de requisitos junto con clases entidad
correspondientes.
Caso de Uso
Registrar
Usuario

Clases Entidad
RegistroUsuario

Validar Usuario RegistroUsuario

Registrar
Tarjeta

RegistroTarjeta

Consultar
Informacin

Asiento, Avin, Tarifa, Aeropuerto,

Aerolnea, Vuelo, Horario

Hacer
Reservacin

Asiento, Avin, Tarifa, Aeropuerto,

Aerolnea, Vuelo, Horario, ViajeroFrecuente,
Pasajero, Reservacin

Pagar
Reservacin

Asiento, Avin, Tarifa, Aeropuerto,

Aerolnea, Vuelo, Horario, ViajeroFrecuente,
Pasajero, Reservacin, RegistroTarjeta

Tabla 7.2 Relacin entre casos de uso y clases entidad para el

sistema de reservaciones de vuelo.
Control
Hasta ahora se han identificado partido objetos interface y entidad a
partir de cada caso de uso. En algunas situaciones todo un caso de uso
pudiera implementarse exclusivamente mediante estos dos tipos de
objetos. De tal manera no se necesitara ningn objeto control para el
respectivo caso de uso. Sin embargo, en la mayora de los casos de uso,
existe un comportamiento que no se puede asignar de forma natural a
ninguno de los otros dos tipos de objetos, ya que realmente no
pertenece de manera natural a ninguno de ellos. Una posibilidad es
repartir el comportamiento entre los dos tipos de objetos, como lo
sugieren algunos mtodos, pero la solucin no es buena si se considera
el aspecto de extensibilidad. Un cambio en el comportamiento podra
afectar varios objetos dificultando la su modificacin. Por lo tanto, para
evitar estos problemas tal comportamiento se asigna en objetos
control. Sin embargo, es difcil lograr un buen balance en la asignacin
del comportamiento entre los objetos entidad, interface y control.

Los objetos de control tpicamente actan como pegamento entre los

otros tipos de objetos y por lo tanto proveen la comunicacin entre los
dems tipos de objetos. Son tpicamente los ms efmeros de todos los
tipos de objetos, dependiendo de la existencia del propio caso de uso.
Los objetos control se identifican directamente de los casos de uso.
Como primera aproximacin, se asigna un objeto control a cada caso de
uso, concreto y abstracto. Dado que se asigna inicialmente el
comportamiento a los objetos interface y entidad para cada caso de uso,
el comportamiento restante se asigna a los objetos control. A menudo un
manera de asignar el comportamiento es modelar inicialmente el caso de
uso sin ningn objeto control, o sea slo utilizar objetos interface y
objetos entidad. Cuando tal modelo se ha desarrollado, se ver que hay
ciertos comportamientos que no se asignan de forma natural, ni en los
objetos entidad ni en los objetos interface, o peor an, se dispersan
sobre varios objetos. Estos comportamientos deben ubicarse en los
objetos control. Sin embargo, puede darse la situacin donde no queda
comportamiento restante para modelar en el caso de uso. En tal caso no
se necesita un objeto control. Otra situacin es si el comportamiento que
queda, despus de distribuir el comportamiento relevante entre objetos
interface y entidad, es demasiado complicado, la funcionalidad puede
ser dividida en varios objetos control. Por otro lado, si un caso de uso se
acopla a varios actores esto puede indicar que existen variados
comportamientos en relacin a los diferentes actores y por lo tanto
deben asignarse varios objetos control. La meta debe ser ligar solo un
actor con cada objeto control ya que los cambios en los sistemas a
menudo son originados por los actores y de tal manera se logra
modularizar los posibles cambios. La estrategia de asignacin de control
se debe decidir segn cada aplicacin. En la mayora de los casos, sin
embargo, se promueve la separacin del control de un caso de uso en
un objeto control que delega funcionalidad de manejo ms local a los
otros dos tipos de objetos.
En el sistema de reservaciones de vuelo asignaremos inicialmente un
objeto control para cada caso como se ver a continuacin. A estas
clases las llamaremos manejadores o controladores para distinguir de
los dems estereotipos.
Registrar Usuario: Este caso de uso requiere de un controlador
para manejar la informacin y las interfaces relacionadas con el
registro de usuario, lo que se hace en la clase

control ManejadorRegistroUsuario. Adems, de manera similar a la

necesidad de utilizar la pantalla principal y la de servicios en el
caso de uso, tambin es necesario utilizar un controlador principal
y el de servicios para que administren los aspectos que permiten
llegar al control propio de registro. A estas clases las
llamaremos ManejadorPrincipal y
ManejadorServicios, respectivamente. En la Figura 7.24 se
muestran las clases control identificadas en este caso de uso.

Figura 7.24 Clases control identificadas del caso uso Registrar

Usuario.
Validar Usuario: Este caso de uso requiere un controlador para
manejar la informacin y las interfaces relacionadas con la
validacin del registro de usuario. Dado que esto utiliza la misma
informacin de registro podemos como enfoque inicial utilizar la
misma clase control que en el caso de uso anterior, por lo cual
utilizamos las clases controlManejadorPrincipal y
ManejadorRegistroUsuario. En la Figura 7.25 se muestran las
clases control identificadas en este caso de uso.

Figura 7.25 Clases control identificadas del caso uso Validar

Usuario.
Registrar Tarjeta: Este caso de uso requiere guardar informacin
exclusivamente acerca de la tarjeta del usuario, lo que se hace en
la clase control ManejadorRegistroTarjeta. Dado que es una
extensin al caso de uso Registrar Usuario es necesario incluir
al ManejadorRegistroUsuario pero ya no es necesario incluir el
control principal del sistema. En la Figura 7.26 se muestran las
clases control identificadas en este caso de uso.

Figura 7.26 Clases control identificadas del caso uso

Registrar Tarjeta.
Consultar Informacin: Este caso de uso requiere de un
controlador para manejar la informacin y las interfaces
relacionadas con las consultas, lo que se hace en la clase control
ManejadorConsultas. Dado que se tiene tres tipos de consultas
distintas, desde ya incluiremos tres controladores
especializados, ManejadorConsultaHorarios,
ManejadorConsultaTarifas y ManejadorConsultaEstado, para las
consultas respectivas. De manera similar a la necesidad de utilizar
la pantalla principal y la pantalla de servicios en el caso de uso,
tambin es necesario utilizar un controlador principal y otro de
servicios que administren los aspectos que permiten llegar al
control propio de consultas. Para esto utilizamos las clases
control ManejadorPrincipal y ManejadorServicios. En la Figura
7.27 se muestran las clases control identificadas en este caso de
uso.

Figura 7.27 Clases control identificadas del caso uso

Consultar Informacin.
Hacer Reservacin: Este caso de uso requiere de un controlador
para manejar la informacin y las interfaces relacionadas con las
reservas, lo que se hace en la clase
controlManejadorReservas. De manera similar al caso de
uso Consultar Informacin, tambin es necesario utilizar las clases
control ManejadorPrincipal y ManejadorServicios. En la Figura
7.28 se muestran las clases control identificadas en este caso de

uso.

Figura 7.28 Clases control identificadas del caso uso Hacer

Reservacin.
Pagar Reservacin: Este caso de uso requiere guardar
informacin exclusivamente acerca de la pagos, lo que se hace en
la clase control ManejadorPagos. Dado que es una extensin al
caso de uso Hacer Reservacin es necesario incluir el control de
reservas ManejadorReservas. Adems existe una relacin con el
caso de uso Registrar Tarjeta por lo cual es necesario incluir el
control de registro de tarjeta ManejadorRegistroTarjeta. En la
Figura 7.29 se muestran las clases control identificadas en este
caso de uso.

Figura 7.29 Clases control identificadas del caso uso Pagar

Reservacin.
En la Tabla 7.3 se muestran el resumen de los casos de uso
identificados durante el modelo de requisitos junto con clases control
correspondientes.
Caso de Uso

Clases Control

Registrar
Usuario

ManejadorPrincipal, ManejadorServicios,
ManejadorRegistroUsuario

Validar
Usuario

ManejadorPrincipal,
ManejadorRegistroUsuario

Registrar
Tarjeta

ManejadorRegistroUsuario,

ManejadorRegistroTarjeta

Consultar
Informacin

ManejadorPrincipal, ManejadorServicios,
ManejadorConsultas,
ManejadorConsultaHorarios,
ManejadorConsultaTarifas,
ManejadorConsultaEstado

Hacer
Reservacin

ManejadorPrincipal, ManejadorServicios,
ManejadorReservas

Pagar
Reservacin

ManejadorReservas, ManejadorPagos,
ManejadorRegistroTarjeta

Tabla 7.3 Relacin entre casos de uso y clases control para el

sistema de reservaciones de vuelo.

7.4 Diagramas de Secuencias

Dada la complejidad y la importancia de los casos de uso, antes de proseguir a

describirlos de manera textual en trmino de las clases que hemos identificado, es
bueno probar algunas secuencias de sus flujos para revisar que tan bien nuestra
arquitectura se adapta a ellos. Para eso introducimos el concepto de diagramas
de secuencias, interaccin o eventos, los cuales describen como los diferentes
casos de uso son implementados mediante los objetos de nuestra arquitectura
recin generados. Los diagramas correspondientes muestran la interaccin entre
los objetos participantes a nivel de eventos que se envan entre si, excluyendo
cualquier detalle interno de ellos. El formato de un diagrama de secuencia se
muestra en la Figura 7.39. Ntese que es un diagrama exclusivamente de objetos
y no de clases. Sin embargo, los objetos son instancias de clases que al no tener
ningn nombre particular se muestran a travs del nombre de la clase subrayada
y con el prefijo de :, correspondiente a la notacin para diagramas de objetos
como se vio en el captulo 4.

Figura 7.39 Diagrama de secuencia.

Cada clase participante se representa por una barra, dibujadas como lneas
verticales en el diagrama. El orden entre las barras es insignificante y debe
elegirse para dar la mayor claridad. Si hubieran varias instancias de las clases que

interactan entre si, se dibujaran las instancias como barras diferentes. Adems
de los objetos, es importante representar entidades externas al sistema en los
diagramas de secuencia. De lo contrario este tipo de diagrama no sera
demasiado til en el modelo de anlisis. En nuestro caso, estas entidades
externas que se incluyen como barras adicionales en el diagrama
representando instancias de los actores.
El eje de tiempo en el diagrama de secuencia es vertical (paralelo a las barras) y
avanzando hacia abajo. El comienzo del diagrama de secuencia corresponde al
inicio del caso de uso. El avance en el tiempo en el diagrama es controlado por los
eventos, mientras que la distancia entre dos eventos en el diagrama no tiene
relacin con el tiempo real entre estos eventos. Ms an el tiempo no es
necesariamente lineal en el diagrama, pudiendo existir concurrencia.
Para describir la comunicacin entre objetos se utilizan estmulos o eventos, los
cuales se envan de un objeto a otro para activar una ejecucin en ese objeto, que
adems puede enviar nuevos estmulos a otros objetos. El diagrama de secuencia
de la Figura 7.40 muestra un ejemplo de estos eventos.

Figura 7.40 Diagrama de secuencia con eventos.

En el diagrama de la figura 7.40, las barras gruesas corresponden
a actividades dentro del objeto, denominadas por a, mientras que las flechas
corresponden a eventos, denominadas por e. Un evento se dibuja como una
flecha horizontal que comienza en la barra correspondiente al objeto que lo enva

y termina en la barra correspondiente al objeto que lo recibe. En este ejemplo los

eventos son numerados sucesivamente utilizando el formato n:. Las actividades
son iniciadas por el arribo de eventos y el tiempo que duran es slo relevante en
relacin a eventos originados durante esa actividad, como en el caso de el objeto
de la Clase1 que recibe un evento e1, el cual inicia una actividad que consiste en
primero generar un evento e2 y posteriormente otro evento e6. Un aspecto
importante que los diagramas de secuencia deben considerar es que las
secuencias de eventos sean continuas y no all interrupciones. Por otro lado la
gran mayora de los diagramas de secuencia, y por lo tanto los casos de uso,
deben comenzar con un evento externo que se genera a partir de una de las
instancias de los actores del sistema. Por ejemplo, consideremos la secuencia
que comienza con el Actor1 a travs del evento e1. Este evento da lugar al
evento e2 el cual a su vez da lugar al evento e3 y as sucesivamente hasta llegar
el evento e7. Sin embargo se interrumpe la continuidad entre el evento e7 y el
evento e8. Esta situacin es muy delicada y peligrosa ya que al no haber una
dependencia directa entre ambos eventos y si consideramos que no existe una
relacin de tiempo real entre ningn evento, pues e8 pudiera generarse en
cualquier momento lo cual pudiera ocasionar inconsistencias en la aplicacin. Esto
se debe evitar a toda costa, cada nuevo evento debe generarse a partir de uno
que se recibe con la nica excepcin de eventos iniciales que son generados por
el sistema o tpicamente por un actor. Ntese que los actores principales son los
que tpicamente deciden que casos de uso sern instanciados, a diferencia de los
propios objetos y casos de uso secundarios que ms bien responden a eventos
que son recibidos. Durante el modelo de anlisis y como veremos en las
siguientes secciones, utilizaremos los diagramas de secuencia para describir
los flujos principales y subflujos para cada caso de uso. Esto ayudar a revisar si
nuestra lgica es correcta y consistente al relacionar las casos de uso del modelo
de requisitos con la arquitectura de clases del modelo de anlisis.
Registrar Usuario
En el caso de uso Registrar Usuario existen diversos subflujos que pueden ser
instanciados por un usuario. En esta seccin mostramos las secuencias que
pudieran desarrollarse entre los objetos para asegurar que la lgica que estamos
utilizando sea correcta y que corresponda a los casos de uso especificados en el
modelo de requisitos. En esta seccin mostraremos un diagrama de secuencias
para los subflujos Crear Registro Usuario (S-1), Actualizar Registro Usuario (S-4)
y Eliminar Registro Usuario (S-5). Ntese que los subflujos Obtener Registro
Usuario (S-2) y Manipular Registro Usuario (S-3) sern instanciados en los ltimos
dos subflujos mientras que el flujo principal estar presente en todos.
Crear Registro Usuario
El diagrama de secuencia para el subflujo Crear Registro Usuario (S-1) se

muestra en el diagrama 7.41. Dado que el usuario requiere de un sistema ya

inicializado para poder interactuar, asignamos como primer evento para todos los
casos de uso el evento inicializar. Utilizamos a la clase InterfaceUsuario como el
inicializador de este evento ya que el sistema es controlado por eventos externos,
correspondientes a aquellos eventos generados por el usuario, tpicamente a
travs del ratn y el teclado. De tal manera es importante ya considerar que todas
las actividades de interaccin con los usuarios deben ser controladas por una
clase similar a InterfaceUsuario. Durante el diseo extenderemos ms esta
explicacin. De tal manera la clase InterfaceUsuario enva el evento inicializar a la
clase ManejadorPrincipal que es realmente el responsable de la lgica principal
del sistema, aunque no del control de presentacin de las pginas ni del manejo
de los eventos externos, que son como mencionamos antes, responsabilidad
de InterfaceUsuario. El ManejadorPrincipal solicita el desplegado de
laPaginaPrincipal mediante el evento desplegarPginaPrincipal. En este momento
el usuario ya puede interactuar con el sistema. Para que se instancie este
subflujo, el usuario debe seleccionar la opcin
de RegistrarPorPrimeraVez oprimiendo el botn correspondiente en la pgina.
Siendo consistente con la lgica anterior, que las interfaces e interaccin con el
usuario son controladas por la InterfaceUsuario, pues esta clase recibe el evento y
se lo enva como un nuevo evento crearRegUsuario al ManejadorPrincipal. El
ManejadorPrincipal que es el encargado de controlar la lgica general del sistema,
reconoce que este evento corresponde a una actividad de registro y se lo enva
bajo el mismo nombre del evento alManejadorRegistroUsuario. Este controlador
reconoce el tipo de evento particular y solicita a la InterfaceUsuario el desplegado
de la pgina correspondiente mediante
desplegarPaginaCrearRegUsuario. La InterfaceUsuario despliega esta pgina,
algo que no se muestra en el diagrama por ser un evento interno. Para continuar
con la lgica principal de este subflujo, el usuario debe llenar sus datos, que no se
muestran aqu, y oprime el botn Registrar para que esta informacin sea enviada
a la clase InterfaceUsuario. Es importante resaltar que los datos como tales no
generan eventos ni son de importancia en estos diagramas. Lo que genera
eventos son los botones en las pantallas. Siguiendo con nuestra lgica, la
InterfaceUsuario enva el
evento crearRegUsuario al ManejadorRegistroUsuario. Este controlador es
responsable de guardar la informacin de registro del usuario, por lo cual enva el
evento escribirRegUsuario a la InterfaceBaseDatosRegistro. Ntese que como en
el caso de los datos, los objetos entidad como la clase RegistroUsuario, tampoco
son mostrados en el diagrama, dado que no agregan eventos interesantes para la
lgica del sistema. Incluso se omiten del diagrama todas las clases
correspondientes a pginas ya que sus eventos importantes son manejados por
la InterfaceUsuario. Prosiguiendo con nuestra lgica,
la InterfaceBaseDatosRegistro enva el evento escribirRegUsuario al actor Base
de Datos Registros.Este actor debe responder de alguna manera, y lo hace
mediante un OK el cual es luego enviado de manera sucesiva hasta llegar

finalmente a InterfaceUsuario. En ese momento elUsuario presiona Salir, dando

por concluido el subflujo.
Ntese que si el usuario decidiera oprimir algn otro botn, como Registrar
Tarjeta, pues simplemente estaramos instanciando un nuevo subflujo en este o
algn otro caso de uso.

Figura 7.41 Diagrama de secuencia para el subflujo Crear Registro Usuario

(S-1) del caso de uso Registrar Usuario.
Vale la pena resaltar dos aspectos importantes en el diagrama. El primer aspecto
es que en ningn momento se corta el flujo de los eventos. La nica excepcin en
el diagrama son los eventos generados por el Usuario que slo se pueden generar
a partir de que las pginas hayan sido desplegadas por lo cual realmente no hay
ninguna interrupcin lgica, sino ms bien que no se muestran flujos de evento
entre la InterfaceUsuario y el Usuario ya que estos son todos visuales (tendra el
usuario que tener por ejemplo algn botn en su cuerpo para que realmente se
mostrar tal evento). El segundo aspecto es que los eventos entre objetos son
como una cascada donde un objeto le enva un evento a otro y este otro objeto le
devuelve posteriormente un evento en respuesta, de manera directa o indirecta.
Por ejemplo, el evento 8 es en respuesta al evento 6, mientras que el
evento 12 es en respuesta al evento 9.Un ejemplo de respuesta indirecta es el
caso del evento 4 respondido mediante los eventos 5 y 6. Una situacin
particular se da con el ltimo evento correspondiente a Salir, el cual interrumpe
estos flujos de respuesta ya que en algn lugar se debe terminar la secuencia.
Actualizar Registro Usuario
El diagrama de secuencia para el subflujo Actualizar Registro Usuario (S-4) se
muestra en el diagrama 7.42. Este subflujo requiere de una validacin del usuario
junto con el seguimiento del subflujo Obtener Registro Usuario (S-2) y Manipular

Registro Usuario (S-3) para llegar a la actualizacin. Se comienza la secuencia el

evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. En este momento el
usuario debe validarse, insertando su login y contrasea. Al ser datos, estos no
generan ningn evento. Una vez el usuario genere el evento OK oprimiendo el
botn correspondiente, se instancia la validacin. La InterfaceUsuario enva esta
vez el eventovalidarRegUsuario al
ManejadorPrincipal. El ManejadorPrincipal reconoce que este evento corresponde
a una actividad de registro y se lo enva bajo el mismo nombre del evento
alManejadorRegistroUsuario. Este controlador reconoce el tipo de evento
particular y solicita a la InterfaceBaseDatosRegistro que haga una validacin del
usuario mediante un evento adicional con el mismo nombre.
La InterfaceBaseDatosRegistro enva a su vez un evento similar al actor Base de
Datos Registros, el cual contesta con un OK si la validacin es buena. Dado que
slo consideramos una secuencia de eventos, una validacin incorrecta se
mostrara en otro diagrama. El OK es sucesivamente enviado a
la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita alManejadorServicios que
entre en accin mediante el
evento ofrecerServicios. El ManejadorServicios solicita entonces a
la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar ObtenerRegistro. Este evento es enviado de
la InterfaceUsuario al ManejadorServicios mediante el
evento obtenerRegUsuario. Este mismo evento es luego enviado por
el ManejadorServicios al ManejadorRegistroUsuario el cual solicita a
la InterfaceBaseDatosRegistro que obtenga el registro correspondiente
mediante leerRegUsuario. Nuevamente, laInterfaceBaseDatosRegistro le pasa un
evento similar al actor Base de Datos Registros, el cual contesta con un OK. Junto
a este OK deben enviarse los propios datos, los cuales no son mostrados por no
generar eventos. El OK es luego enviado por
la InterfaceBaseDatosRegistro al ManejadorRegistroUsuario el cual solicita a
la InterfaceUsuario desplegar la pgina de informacin de registro mediante el
evento desplegarPginaObtenerRegUsuario. Hasta aqu la secuencia es parte del
subflujo Obtener Registro Usuario. En este momento el usuario actualiza sus
datos, que no se muestran aqu, y oprime el botn Actualizar para que esta
informacin sea enviada a la clase InterfaceUsuario. Siguiendo con la lgica,
la InterfaceUsuarioenva el
evento actualizarRegUsuario al ManejadorRegistroUsuario, el cual es responsable
de actualizar el registro, por lo cual enva el evento escribirRegUsuario a
laInterfaceBaseDatosRegistro. Esta ltima etapa es similar a la del subflujo Crear
Registro Usuario. La InterfaceBaseDatosRegistro enva el

evento escribirRegUsuario al actor Base de Datos Registros. Este actor responde

mediante un OK el cual es luego enviado de manera sucesiva hasta llegar
finalmente a InterfaceUsuario. En ese momento el Usuario presiona Salir,dando
por concluido el subflujo.

Figura 7.42 Diagrama de secuencia para el subflujo Actualizar Registro

Usuario (S-4) del caso de uso Registrar Usuario.
Eliminar Registro Usuario
El diagrama de secuencia para el subflujo Eliminar Registro Usuario (S-5) se
muestra en el diagrama 7.43. Este subflujo es muy similar al de Actualizar
Registro Usuario hasta donde llega la secuencia de Obtener Registro
Usuario, comenzando desde la validacin del usuario. Se comienza la secuencia
el evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuarioal ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUs
uario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario

mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el

evento a la Base de Datos Registros, el cual contesta con un OK si la validacin
es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all
a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las
secuencias de validacin. Una vez el ManejadorPrincipal recibi este
ltimo OK, solicita al ManejadorServicios que entre en accin mediante el
evento ofrecerServicios. El ManejadorServicios solicita entonces a
laInterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar ObtenerRegistro. Este evento es enviado de
la InterfaceUsuario al ManejadorServicios mediante el
evento obtenerRegUsuario. Este mismo evento es luego enviado por
el ManejadorServicios al ManejadorRegistroUsuario el cual solicita a
la InterfaceBaseDatosRegistro que obtenga el registro correspondiente
medianteleerRegUsuario. Nuevamente, la InterfaceBaseDatosRegistro le pasa un
evento similar al actor Base de Datos Registros, el cual contesta con un OK.
El OK es luego enviado por
laInterfaceBaseDatosRegistro al ManejadorRegistroUsuario el cual solicita a
la InterfaceUsuario desplegar la pgina de informacin de registro mediante el
eventodesplegarPginaObtenerRegUsuario. Hasta aqu la secuencia es parte del
subflujo Obtener Registro Usuario y es similar al subflujo Actualizar Registro
Usuario. En este momento el usuario oprime el botn Eliminar. La
InterfaceUsuario enva el evento eliminarRegUsuario
al ManejadorRegistroUsuario, el cual es responsable de eliminar el registro, por lo
cual enva el evento eliminarRegUsuario a
la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el
evento eliminarRegUsuario al actor Base de Datos Registros. Este actor responde
mediante un OK el cual es luego enviado de manera sucesiva hasta llegar
finalmente a InterfaceUsuario. No es necesario que Usuario genere el
evento Salir, ya que este evento es generado directamente por el sistema, dando
por concluido el subflujo.

Figura 7.43 Diagrama de secuencia para el subflujo Eliminar Registro

Usuario (S-5) del caso de uso Registrar Usuario.
Validar Usuario
El diagrama de secuencia para el flujo Validar Usuario se muestra en el diagrama
7.44. Este flujo es incluido en todos los dems casos de uso por lo cual daremos
una descripcin rpida. Se comienza la secuencia el evento inicializar de la
clase InterfaceUsuario al ManejadorPrincipal el cual le responde mediante el
evento desplegarPginaPrincipal. El usuario se valida enviando el evento OK.
La InterfaceUsuario enva el evento validarRegUsuario
al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario alManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
LaInterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a laInterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin.
El diagrama se interrumpe aqu dado que su continuacin depende del caso de
uso que lo incluya.

Figura 7.44 Diagrama de secuencia para el caso de uso Validar Usuario.

Registrar Tarjeta
En el caso de uso Registrar Tarjeta existen diversos subflujos que pueden ser
instanciados por un usuario. En esta seccin mostraremos un diagrama de
secuencias para los subflujosCrear Registro Tarjeta (S-1), Actualizar Registro
Tarjeta (S-4) y Eliminar Registro Tarjeta (S-5). Aunque este caso de uso es una
extensin del caso de uso Registrar Usuario,mostraremos la secuencia completa
desde su inicio en el diagrama para mayor claridad.
Crear Registro Tarjeta
El diagrama de secuencia para el subflujo Crear Registro Tarjeta (S-1) se muestra
en el diagrama 7.45. Este subflujo comienza con la validacin del usuario a partir
del evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a laInterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicios que

entre en accin mediante el evento ofrecerServicios. ElManejadorServicios solicita

entonces a la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar ObtenerRegistro. Este evento es enviado de
la InterfaceUsuario al ManejadorServicios mediante el
eventoobtenerRegUsuario. Este mismo evento es luego enviado por el
ManejadorServicios al ManejadorRegistroUsuario el cual solicita a
la InterfaceBaseDatosRegistro que obtenga el registro correspondiente
mediante leerRegUsuario. Nuevamente, la InterfaceBaseDatosRegistro le pasa un
evento similar al actor Base de Datos Registros, el cual contesta con
un OK. El OK es luego enviado por la
InterfaceBaseDatosRegistro al ManejadorRegistroUsuario el cual solicita a
la InterfaceUsuario desplegar la pgina de informacin de registro mediante el
eventodesplegarPginaObtenerRegUsuario. Hasta aqu la secuencia es parte del
subflujo Obtener Registro Usuario y Manipular Registro Usuario, siendo similar al
subflujo Actualizar Registro Usuario.
En este momento el usuario oprime el botn Registrar
Tarjeta. La InterfaceUsuario enva el evento obtenerRegTarjeta
al ManejadorRegistroUsuario, el cual le enva el mismo evento
alManejadorRegistroTarjeta. Este controlador, que es responsable de todo lo
relacionado con el registro de tarjeta, enva el evento leerRegTarjeta a
la InterfaceBaseDatosRegistro. LaInterfaceBaseDatosRegistro enva el mismo
evento al actor Base de Datos Registros. Este actor responde mediante un vaca
correspondiente a un registro de tarjeta an no llenado. Este evento es enviado de
regreso al ManejadorRegistroTarjeta el cual
solicita desplegarPaginaCrearRegistroTarjeta a InterfaceUsuario. El usuario
registra sus datos de tarjeta y presiona el botn de Registrar generando el
evento Registrar. Como consecuencia de este evento, InterfaceUsuario enva el
evento crearRegTarjeta al ManejadorRegistroTarjeta el cual enva el
evento escribirRegTarjeta a InterfaceBaseDatosRegistro. Este ltimo enva el
mismo evento al actor Base de Datos Registros, el cual contesta con un OK que
es sucesivamente enviado de regreso a travs de InterfaceBaseDatosRegistro,
ManejadorRegistroTarjeta e InterfaceUsuario. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.45 Diagrama de secuencia para el subflujo Crear Registro Tarjeta

(S-1) del caso de uso Registrar Tarjeta.
Actualizar Registro Tarjeta
El diagrama de secuencia para el subflujo Actualizar Registro Tarjeta (S-4) se
muestra en el diagrama 7.46. Este subflujo es muy similar a Crear Registro Tarjeta
(S-1) y comienza con la validacin del usuario a partir del evento inicializar de la
clase InterfaceUsuario al ManejadorPrincipal el cual le responde mediante el
evento desplegarPginaPrincipal. El usuario se valida enviando el
evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario alManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
LaInterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a laInterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicios que
entre en accin mediante el evento ofrecerServicios.
El ManejadorServicios solicita entonces a la InterfaceUsuario el desplegado de la
pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.

Para continuar con la lgica principal de este subflujo, el usuario debe

presionarObtenerRegistro. Este evento es enviado de
la InterfaceUsuario al ManejadorServicios mediante el
evento obtenerRegUsuario. Este mismo evento es luego enviado por
elManejadorServicios al ManejadorRegistroUsuario el cual solicita a
la InterfaceBaseDatosRegistro que obtenga el registro correspondiente
mediante leerRegUsuario. Nuevamente, laInterfaceBaseDatosRegistro le pasa un
evento similar al actor Base de Datos Registros, el cual contesta con
un OK. El OK es luego enviado por
la InterfaceBaseDatosRegistro alManejadorRegistroUsuario el cual solicita a la
InterfaceUsuario desplegar la pgina de informacin de registro mediante el
evento desplegarPginaObtenerRegUsuario. En este momento el usuario oprime
el botn Registrar Tarjeta. La InterfaceUsuario enva el evento obtenerRegTarjeta
al ManejadorRegistroUsuario, el cual le enva el mismo evento
alManejadorRegistroTarjeta. Este controlador, que es responsable de todo lo
relacionado con el registro de tarjeta, enva el evento leerRegTarjeta a
la InterfaceBaseDatosRegistro. LaInterfaceBaseDatosRegistro enva el mismo
evento al actor Base de Datos Registros. Hasta aqu la secuencia es similar al
subflujo Crear Registro Tarjeta, ya que el actor Base de Datos Registros responde
ahora mediante un OK correspondiente a un registro de tarjeta existente. Este
evento es enviado de regreso al ManejadorRegistroTarjeta el cual
solicitadesplegarPaginaObtenerRegistroTarjeta a InterfaceUsuario. El usuario
actualiza sus datos de tarjeta y presiona el botn de Actualizar generando el
evento Actualizar. Como consecuencia de este evento, InterfaceUsuario enva el
evento actualizarRegTarjeta al ManejadorRegistroTarjeta el cual enva el
evento escribirRegTarjeta a InterfaceBaseDatosRegistro. Este ltimo enva el
mismo evento al actor Base de Datos Registros, el cual contesta con un OK que
es sucesivamente enviado de regreso a travs de InterfaceBaseDatosRegistro,
ManejadorRegistroTarjeta e InterfaceUsuario. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo

Figura 7.46 Diagrama de secuencia para el subflujo Actualizar Registro

Tarjeta (S-4) del caso de uso Registrar Tarjeta.
Eliminar Registro Tarjeta
El diagrama de secuencia para el subflujo Eliminar Registro Tarjeta (S-5) se
muestra en el diagrama 7.47. Este subflujo es muy similar a Actualizar Registro
Tarjeta (S-4) y comienza con la validacin del usuario a partir del evento inicializar
de la clase InterfaceUsuario al ManejadorPrincipal el cual le responde mediante el
evento desplegarPginaPrincipal. El usuario se valida enviando el
evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario alManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
LaInterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a laInterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicios que
entre en accin mediante el

evento ofrecerServicios. El ManejadorServicios solicita entonces a

la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionarObtenerRegistro. Este evento es enviado de
la InterfaceUsuario al ManejadorServicios mediante el
evento obtenerRegUsuario. Este mismo evento es luego enviado por
elManejadorServicios al ManejadorRegistroUsuario el cual solicita a
la InterfaceBaseDatosRegistro que obtenga el registro correspondiente
mediante leerRegUsuario. Nuevamente, laInterfaceBaseDatosRegistro le pasa un
evento similar al actor Base de Datos Registros, el cual contesta con
un OK. El OK es luego enviado por
la InterfaceBaseDatosRegistro alManejadorRegistroUsuario el cual solicita a
la InterfaceUsuario desplegar la pgina de informacin de registro mediante el
evento desplegarPginaObtenerRegUsuario. En este momento el usuario oprime
el botn Registrar Tarjeta. La InterfaceUsuario enva el evento obtenerRegTarjeta
al ManejadorRegistroUsuario, el cual le enva el mismo evento al
ManejadorRegistroTarjeta. Este controlador, que es responsable de todo lo
relacionado con el registro de tarjeta, enva el evento leerRegTarjeta a la
InterfaceBaseDatosRegistro. LaInterfaceBaseDatosRegistro enva el mismo
evento al actor Base de Datos Registros. El actor Base de Datos
Registros responde mediante un OK correspondiente a un registro de tarjeta
existente. Este evento es enviado de regreso al ManejadorRegistroTarjeta el cual
solicita desplegarPaginaObtenerRegistroTarjeta a InterfaceUsuario. Hasta aqu la
secuencia es similar al subflujo Actualizar Registro Tarjeta, ya que el usuario
presiona el botn de Eliminar generando el evento Eliminar. Como consecuencia
de este evento, InterfaceUsuario enva el
eventoeliminarRegTarjeta al ManejadorRegistroTarjeta el cual enva el
evento eliminarRegTarjeta a InterfaceBaseDatosRegistro. Este ltimo enva el
mismo evento al actor Base de Datos Registros, el cual contesta con un OK que
es sucesivamente enviado de regreso a travs de InterfaceBaseDatosRegistro,
ManejadorRegistroTarjeta e InterfaceUsuario. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.47 Diagrama de secuencia para el subflujo Eliminar Registro Tarjeta

(S-5) del caso de uso Registrar Tarjeta.
Consultar Informacin
En el caso de uso Consultar Informacin existen diversos subflujos que pueden
ser instanciados por un usuario. En esta seccin mostraremos un diagrama de
secuencias para los subflujos Consultar Horarios (S-2), Consultar Tarifas (S3) y Consultar Estado (S-4).
Consultar Horario
El diagrama de secuencia para el subflujo Consultar Horarios (S-2) se muestra en
el diagrama 7.48. Este subflujo comienza con la validacin del usuario a partir del
evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUs
uario solicita a laInterfaceBaseDatosRegistro que haga una validacin del usuario
mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el
evento a la Base de Datos Registros, el cual contesta con un OK si la validacin
es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all

a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las

secuencias de validacin. Una vez el ManejadorPrincipal recibi este
ltimo OK, solicita al ManejadorServicios que entre en accin mediante el
evento ofrecerServicios. ElManejadorServicios solicita entonces a
la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Consultar Informacin. Se genera el evento Consultar que es enviado
de la InterfaceUsuario alManejadorServicios mediante el
evento consultarInformacin. Este mismo evento es luego enviado por
el ManejadorServicios al ManejadorConsultas el cual enva el
eventodesplegarPaginaConsultas a InterfaceUsuario. El usuario
presiona Horarios lo cual genera el evento ConsultarHorarios. InterfaceUsuario
enva este evento de regreso aManejadorConsultas el cual enva el
evento consultarHorarios al ManejadorConsultaHorarios. Este a su vez enva el
evento desplegarPaginaConsultaHorarios a InterfaceUsuario. El usuario llena la
informacin de la consulta y oprime el botn Consultar el cual genera el evento
consultar de InterfaceUsuario al ManejadorConsultaHorarios. Este ltimo enva el
eventoconsultarHorarios a la InterfaceBaseDatosReservas para que haga la
peticin correspondiente al actor Base de Datos Reservas, el cual contesta con
un OK. El OK es luego enviado por la
InterfaceBaseDatosRegistro al ManejadorConsultaHorarios el cual solicita a
la InterfaceUsuario desplegar la pgina de resultado de la bsqueda mediante el
eventodesplegarPginaResultadoHorarios. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.48 Diagrama de secuencia para el subflujo Consultar Horarios (S-2)

del caso de uso Consultar Informacin.

Consultar Tarifas
El diagrama de secuencia para el subflujo Consultar Tarifas (S-3) se muestra en el
diagrama 7.49. Este subflujo comienza con la validacin del usuario a partir del
evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUs
uario solicita a laInterfaceBaseDatosRegistro que haga una validacin del usuario
mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el
evento a la Base de Datos Registros, el cual contesta con un OK si la validacin
es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all
a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las
secuencias de validacin. Una vez el ManejadorPrincipal recibi este
ltimo OK, solicita al ManejadorServicios que entre en accin mediante el evento
ofrecerServicios. ElManejadorServicios solicita entonces a la InterfaceUsuario el
desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Consultar Informacin. Se genera el evento Consultar que es enviado
de la InterfaceUsuario alManejadorServicios mediante el
evento consultarInformacin. Este mismo evento es luego enviado por
el ManejadorServicios al ManejadorConsultas el cual enva el
eventodesplegarPaginaConsultas a InterfaceUsuario. Hasta aqu la secuencia es
similar al subflujo Consultar Horarios (S-2). En este subflujo, el usuario
presiona Tarifas lo cual genera el
evento ConsultarTarifas. InterfaceUsuario enva este evento de regreso
a ManejadorConsultas el cual enva el
evento consultarTarifas al ManejadorConsultaTarifas. Este a su vez enva el
evento desplegarPaginaConsultaTarifas a InterfaceUsuario. El usuario llena la
informacin de la consulta y oprime el botn Consultar el cual genera el evento
consultar de InterfaceUsuario al ManejadorConsultaTarifas. Este ltimo enva el
evento consultarTarifas a la InterfaceBaseDatosReservas para que haga la
peticin correspondiente al actor Base de Datos Reservas, el cual contesta con
un OK. El OK es luego enviado por
la InterfaceBaseDatosRegistro al ManejadorConsultaTarifas el cual solicita a
la InterfaceUsuario desplegar la pgina de resultado de la bsqueda mediante el
evento desplegarPginaResultadoTarifas. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.49 Diagrama de secuencia para el subflujo Consultar Tarifas (S-3)

del caso de uso Consultar Informacin.
Consultar Estado
El diagrama de secuencia para el subflujo Consultar Estado (S-4) se muestra en el
diagrama 7.49. Este subflujo comienza con la validacin del usuario a partir del
evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a laInterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicios que
entre en accin mediante el evento ofrecerServicios. ElManejadorServicios solicita
entonces a la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Consultar Informacin. Se genera el evento Consultar que es enviado
de la InterfaceUsuario alManejadorServicios mediante el
evento consultarInformacin. Este mismo evento es luego enviado por
el ManejadorServicios al ManejadorConsultas el cual enva el
eventodesplegarPaginaConsultas a InterfaceUsuario. Hasta aqu la secuencia es
similar al subflujo Consultar Horarios (S-2) y al subflujo Consultar Tarifas (S-3). En
este subflujo, el usuario presiona Estado lo cual genera el
evento ConsultarEstado. InterfaceUsuario enva este evento de regreso
a ManejadorConsultas el cual enva el

evento consultarHorarios alManejadorConsultaEstado. Este a su vez enva el

evento desplegarPaginaConsultaEstado a InterfaceUsuario. El usuario llena la
informacin de la consulta y oprime el botn Consultarel cual genera el evento
consultar de InterfaceUsuario al ManejadorConsultaEstado. Este ltimo enva el
evento consultarEstados a la InterfaceBaseDatosReservas para que haga la
peticin correspondiente al actor Base de Datos Reservas, el cual contesta con
un OK. El OK es luego enviado por
la InterfaceBaseDatosRegistro al ManejadorConsultaEstado el cual solicita a
la InterfaceUsuario desplegar la pgina de resultado de la bsqueda mediante el
evento desplegarPginaResultadoEstado. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.
Hacer Reservacin
En el caso de uso Hacer Rservacin existen diversos subflujos que pueden ser
instanciados por un usuario. En esta seccin mostraremos un diagrama de
secuencias para los subflujosCrear Reservacin (S-2), Actualizar Reservacin (S5) y Eliminar Reservacin (S-6).
Crear Reservacin
El diagrama de secuencia para el subflujo Crear Reservacin (S-2) se muestra en
el diagrama 7.51. Este subflujo comienza con la validacin del usuario a partir del
evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a laInterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicios que
entre en accin mediante el evento ofrecerServicios. ElManejadorServicios solicita
entonces a la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Hacer Reservacin. Se genera el evento HacerReservacin que es
enviado de la InterfaceUsuario alManejadorServicios mediante el
evento hacerReservacin. El ManejadorServicios enva el
evento obtenerReservacin al ManejadorReservas el cual enva el
eventodesplegarPaginaClaveReservas a InterfaceUsuario. El usuario presiona el

botn Crear y se genera el evento Crear. La InterfaceUsuario enva el

evento crearReserva de regreso aManejadorReservas el cual enva el
evento desplegarPaginaCrearReservaVuelos a InterfaceUsuario. El usuario
presiona Reservar lo cual genera el evento Reservar. LaInterfaceUsuario enva
el evento crearReserva de regreso a ManejadorReservas el cual enva el
evento crearReserva a la InterfaceBaseDatosReservas para que haga la peticin
correspondiente al actor Base de Datos Reservas, el cual contesta con
un OK. El OK es luego enviado por
la InterfaceBaseDatosRegistro al ManejadorReservas el cual solicita a
laInterfaceUsuario desplegar la pgina de resultado de la solicitud de reserva
mediante el evento desplegarPginaRecordReservaVuelos. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.51 Diagrama de secuencia para el subflujo Crear Reservacin (S-2)

del caso de uso Hacer Reservacin.
Actualizar Reservacin
El diagrama de secuencia para el subflujo Actualizar Reservacin (S-5) se
muestra en el diagrama 7.52. Este subflujo comienza con la validacin del usuario
a partir del evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el
cual le responde mediante el evento desplegarPginaPrincipal. El usuario se
valida enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUs
uario solicita a laInterfaceBaseDatosRegistro que haga una validacin del usuario

mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el

evento a la Base de Datos Registros, el cual contesta con un OK si la validacin
es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all
a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las
secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK,
solicita al ManejadorServicios que entre en accin mediante el
evento ofrecerServicios. ElManejadorServicios solicita entonces a
la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Hacer Reservacin. Se genera el evento HacerReservacin que es
enviado de la InterfaceUsuario alManejadorServicios mediante el
evento hacerReservacin. El ManejadorServicios enva el evento
obtenerReservacin al ManejadorReservas el cual enva el
eventodesplegarPaginaClaveReservas a InterfaceUsuario. El usuario presiona el
botn Obtener, junto con la insercin de la clave de rcord de reservas, y se
genera el evento Obtener. LaInterfaceUsuario enva el evento obtenerReserva de
regreso a ManejadorReservas el cual enva el evento leerReserva a
la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base
de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de
regreso a InterfaceBaseDatosReservas, la cual luego lo enva
a ManejadorReservas.El ManejadorReservas enva el
evento desplegarPaginaRecordReservaVuelos a InterfaceUsuario. El usuario
actualiza los datos de su reservacin y presiona Actualizar lo cual genera el
evento Actualizar. La InterfaceUsuario enva el evento actualizarReserva de
regreso a ManejadorReservas el cual enva el evento escribirReserva a
la InterfaceBaseDatosReservas para que haga la peticin correspondiente al
actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego
enviado por la InterfaceBaseDatosRegistro al ManejadorReservas el cual solicita
a la InterfaceUsuario desplegar la pgina de resultado de la actualizacin de
reserva mediante el evento desplegarPginaRecordReservaVuelos. En ese
momento el Usuariopresiona Salir, dando por concluido el subflujo.

Figura 7.52 Diagrama de secuencia para el subflujo Actualizar Reservacin

(S-5) del caso de uso Hacer Reservacin.
Eliminar Reservacin
El diagrama de secuencia para el subflujo Eliminar Reservacin (S-6) se muestra
en el diagrama 7.53. Este subflujo comienza con la validacin del usuario a partir
del evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario.
El ManejadorRegistroUsuario solicita a laInterfaceBaseDatosRegistro que haga
una validacin del usuario mediante el mismo evento.
La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos
Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado
a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego
a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez
el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicios que
entre en accin mediante el evento ofrecerServicios. ElManejadorServicios solicita
entonces a la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Hacer Reservacin. Se genera el evento HacerReservacin que es
enviado de la InterfaceUsuario alManejadorServicios mediante el

evento hacerReservacin. El ManejadorServicios enva el evento

obtenerReservacin al ManejadorReservas, el cual enva el
eventodesplegarPaginaClaveReservas a InterfaceUsuario. El usuario presiona el
botn Obtener, junto con la insercin de la clave de rcord de reservas, y se
genera el evento Obtener. LaInterfaceUsuario enva el evento obtenerReserva de
regreso a ManejadorReservas el cual enva el evento leerReserva a
la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base
de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de
regreso a InterfaceBaseDatosReservas, la cual luego lo enva
a ManejadorReservas. El ManejadorReservas enva el
evento desplegarPaginaRecordReservaVuelos a InterfaceUsuario.
Hasta aqu la secuencia es similar al subflujo Actualizar Reservacin (S-5). En
este momento el usuario presiona Eliminar lo cual genera el evento Eliminar.
InterfaceUsuario enva el evento eliminarReserva de regreso
a ManejadorReservas el cual enva el evento eliminarReserva a
la InterfaceBaseDatosReservas para que haga la peticin correspondiente al
actorBase de Datos Reservas, el cual contesta con un OK. El OK es luego
enviado por la InterfaceBaseDatosRegistro al ManejadorReservas el cual solicita
a la InterfaceUsuario desplegar la pgina de resultado de la eliminacin de
reserva mediante el evento desplegarPginaRecordReservaVuelos. En ese
momento el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.53 Diagrama de secuencia para el subflujo Eliminar Reservacin (S6) del caso de uso Hacer Reservacin.
Pagar Reservacin
En el caso de uso Pagar Rservacin existen diversos subflujos que pueden ser
instanciados por un usuario. En esta seccin mostraremos un diagrama de

secuencias para los subflujosPagar Reservacin (S-1) y Reembolsar Pago (S-2).

Pagar Reservacin
El diagrama de secuencia para el subflujo Pagar Reservacin (S-1) se muestra en
el diagrama 7.54. Este subflujo comienza con la validacin del usuario a partir del
evento inicializar de la clase InterfaceUsuario al ManejadorPrincipal el cual le
responde mediante el evento desplegarPginaPrincipal. El usuario se valida
enviando el evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el
evento validarRegUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUs
uario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario
mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el
evento a la Base de Datos Registros, el cual contesta con un OK si la validacin
es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all
a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las
secuencias de validacin. Una vez el ManejadorPrincipal recibi este
ltimo OK, solicita al ManejadorServicios que entre en accin mediante el
evento ofrecerServicios. ElManejadorServicios solicita entonces a
la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionar Hacer Reservacin y debe incluir un nmero correspondiente a la
clave de reservacin. Se genera el evento HacerReservacin que es enviado de
la InterfaceUsuario al ManejadorServicios mediante el
evento hacerReservacin. El ManejadorServicios enva el
evento obtenerReservacinal ManejadorReservas. Dado que se incluye la clave
de reservacin, el ManejadorReservas enva el evento leerReserva a
la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base
de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de
regreso a InterfaceBaseDatosReservas, la cual luego lo enva
a ManejadorReservas.El ManejadorReservas enva el
evento desplegarPaginaRecordReservaVuelos a InterfaceUsuario. Hasta aqu la
secuencia es similar al subflujo Actualizar Reservacin (S-5) y Eliminar
Reservacin (S-6) del caso de uso Hacer Reservacin. En este momento el
usuario presiona Pagar lo cual genera el evento pagarReserva.
InterfaceUsuario enva el eventopagarReserva de regreso
a ManejadorReservas el cual enva el
evento pagarReserva al ManejadorPagos. El ManejadorPagos enva el
evento pagarRegTarjeta alManejadorRegistroTarjeta. Este ltimo enva el
evento leerRegTarjeta a la InterfaceBaseDatosRegistro la cual enva el mismo
evento al actor Base de Datos Registros. Este actor regresa un OK a
la InterfaceBaseDatosRegistro la cual a su vez lo enva de regreso
a ManejadorRegistroTarjeta. Este ltimo enva

el OK a ManejadorPagos. ManejadorPagos enva el

eventodesplegarPaginaPagoReservas a la InterfaceUsuario. El usuario genera el
evento Pagar. La InterfaceUsuario recibe la peticin y enva el
evento pagarReserva al ManejadorPagos. Este a su vez enva el
evento pagarReserva a la InterfaceBaseDatosReservas para que haga la peticin
correspondiente al actor Base de Datos Reservas, el cual contesta con un OK.
El OKes luego enviado por la InterfaceBaseDatosRegistro al ManejadorPagos el
cual enva el OK al ManejadorReservas. El ManejadorReservas el cual solicita a
la InterfaceUsuario desplegar la pgina de resultado del pago de reserva mediante
el evento desplegarPginaRecordReservaVuelos. En ese momento
el Usuario presiona Salir, dando por concluido el subflujo.

Figura 7.54 Diagrama de secuencia para el subflujo Pagar Reservacin (S-1)

del caso de uso Pagar Reservacin.
Reembolsar Pago
El diagrama de secuencia para el subflujo Reembolsar Pago (S-2) se muestra en
el diagrama 7.55. Este subflujo es muy similar a Pagar Reservacin (S-1). El
subflujo comienza con la validacin del usuario a partir del evento inicializar de la
clase InterfaceUsuario al ManejadorPrincipal el cual le responde mediante el
evento desplegarPginaPrincipal. El usuario se valida enviando el
evento OK. La InterfaceUsuario enva el
evento validarRegUsuario al ManejadorPrincipal. El ManejadorPrincipal enva el

evento validarRegUsuario alManejadorRegistroUsuario. El ManejadorRegistroUsu

ario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario
mediante el mismo evento. LaInterfaceBaseDatosRegistro enva a su vez el
evento a la Base de Datos Registros, el cual contesta con un OK si la validacin
es buena. El OK es enviado a laInterfaceBaseDatosRegistro, de all
a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las
secuencias de validacin. Una vez el ManejadorPrincipal recibi este
ltimo OK, solicita al ManejadorServicios que entre en accin mediante el
evento ofrecerServicios. El ManejadorServicios solicita entonces a
la InterfaceUsuario el desplegado de la pgina correspondiente
mediante desplegarPaginaServicios. La InterfaceUsuario despliega esta pgina.
Para continuar con la lgica principal de este subflujo, el usuario debe
presionarHacer Reservacin y debe incluir un nmero correspondiente a la clave
de reservacin. Se genera el evento HacerReservacin que es enviado de
la InterfaceUsuario alManejadorServicios mediante el
evento hacerReservacin. El ManejadorServicios enva el
evento obtenerReservacin al ManejadorReservas. Dado que se incluye la clave
de reservacin, el ManejadorReservas enva el evento leerReserva a
la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base
de Datos Reservas. El actor genera unOK si todo es correcto y se lo enva de
regreso a InterfaceBaseDatosReservas, la cual luego lo enva
a ManejadorReservas. El ManejadorReservas enva el
eventodesplegarPaginaRecordReservaVuelos a InterfaceUsuario. Hasta aqu la
secuencia es similar al subflujo Pagar Reservacin (S-1). En este momento el
usuario presiona Reembolsar lo cual genera el
evento reembolsarReserva. InterfaceUsuario enva el
evento reembolsarReserva de regreso a ManejadorReservas el cual enva el
evento reembolsarReserva alManejadorPagos. El ManejadorPagos enva el
evento reembolsarRegTarjeta al ManejadorRegistroTarjeta. Este ltimo enva el
evento leerRegTarjeta a la InterfaceBaseDatosRegistro la cual enva el mismo
evento al actor Base de Datos Registros. Este actor regresa un OK a
la InterfaceBaseDatosRegistro la cual a su vez lo enva de regreso
a ManejadorRegistroTarjeta.Este ltimo enva el OK a ManejadorPagos.
ManejadorPagos enva el evento desplegarPaginaPagoReservas a
la InterfaceUsuario. El usuario genera el
evento Reembolsar. LaInterfaceUsuario recibe la peticin y enva el
evento reembolsarReserva al ManejadorPagos. Este a su vez enva el
evento reembolsarReserva a la InterfaceBaseDatosReservas para que haga la
peticin correspondiente al actor Base de Datos Reservas, el cual contesta con
un OK. El OK es luego enviado por
la InterfaceBaseDatosRegistro al ManejadorPagos el cual enva
el OK al ManejadorReservas. El ManejadorReservas solicita a
la InterfaceUsuario desplegar la pgina de resultado del reembolso de reserva
mediante el eventodesplegarPginaRecordReservaVuelos. En ese momento

el Usuario presiona Salir, dando por concluido el subflujo.

Diccionario de Clases.

Como ltima etapa del modelo de anlisis, se actualiza el diccionario de

datos originalmente descrito para el dominio del problema para incluir
todas las clases identificadas durante el modelo de anlisis. Separamos
estas clases en diferentes mdulos para lograr una mejor
correspondencia entre clases y casos de uso. Aquellas clases que
participan en varios casos de uso se pueden asignar a distintos mdulos,
como veremos a continuacin para el sistema de reservaciones de vuelo.
Comenzamos con cuatro mdulos o paquetes principales:
InterfaceUsuario, Principal, Registro y Sevicios, como se muestra en la
Figura 7.56

Figura 7.56 Mdulos principales del sistema de reservaciones de

vuelo.
InterfaceUsuario
El mdulo InterfaceUsuario est compuesto por una sla clase:
InterfaceUsuario Clase Interface. Toda la interaccin con el
usuario se hace por medio de la interface de usuario.
Principal

El mdulo Principal est compuesto por dos clases:

PaginaPrincipal - Clase Interface. Pgina principal (P-1)
ManejadorPrincipal - Clase Control. El manejador principal es el
encargado de desplegar la pgina principal de interaccin con el
usuario, y luego delegar las diferentes funciones a los manejadores
especializados apropiados.
Registro
El mdulo Registro se divide en los siguientes
mdulos: RegistroPrincipal, Usuario y Tarjeta, como se muestra en la
Figura 7.57.

Figura 7.57 Mdulos adicionales del mdulo Registro.

RegistroPrincipal
El mdulo RegistroPrincipal est compuesto por una sla clase:
InterfaceBaseDatosRegistro - Clase Interface. La informacin de
cada usuario se almacena en la base de datos de registro la cual
se accesa mediante la interface de la base de datos de registro.
Esto permite validar a los distintos usuarios adems de guardar
informacin sobre la tarjeta de crdito para pagos en lnea.
Usuario
El mdulo Usuario est compuesto por las clases:

 PaginaCrearRegUsuario - Clase Interface. Pgina de solicitud de

registro de usuario (P-3).
PaginaObtenerRegUsuario - Clase Interface. Pgina de
devolucin con informacin de registro de usuario (P-4).
RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de
reservaciones, el usuario debe estar registrado con el sistema. El
registro contiene informacin acerca del usuario que incluye
nombre, direccin, colonia, ciudad, pas, cdigo postal, telfono de
casa, telfono de oficina, fax, email, login y password.
ManejadorRegistroUsuario - Clase Control. El manejador de
registro de usuario se encarga de todo lo relacionado con registro
del usuario para poder utilizar el sistema.
Tarjeta
El mdulo Tarjeta est compuesto por las clases:
PaginaCrearRegTarjeta - Clase Interface. Pgina de solicitud de
registro de tarjeta (P-5).
PaginaObtenerRegTarjeta - Clase Interface. Pgina de devolucin
con informacin de registro de tarjeta (P-6).
RegistroTarjeta - Clase Entidad. Para poder hacer un pago con
una tarjeta de crdito, se debe tener un registro de tarjeta. El
registro contiene informacin acerca de la tarjeta incluyendo
nombre, nmero, expedidor y vencimiento. LA tarjeta est ligada a
un registro de usuario.
ManejadorRegistroTarjeta - Clase Control. El manejador de
registro de tarjeta se encarga de todo lo relacionado con registro de
la tarjeta del usuario para poder pagar las reservaciones.
Servicios
El mdulo Servicio se divide en los siguientes mdulos: ServicioPrincipal,
Dominio, Consultas, Reservas, y Pagos, como se muestra en la Figura
7.58.

Figura 7.58 Mdulos adicionales del mdulo Servicios.

ServicioPrincipal
El mdulo ServicioPrincipal est compuesto por las clases:
InterfaceBaseDatosReserva - Clase Interface. La informacin del
sistema de reservaciones de vuelo se almacena en la base de
datos de reservas la cual se accesa mediante la interface de la
base de datos de reservas. Esto permite generar consultas,
reservas y pago de reservas de manera dinmica.
PaginaServicio - Clase Interface. Pgina de servicios (P-2).
ManejadorServicios - Clase Control. El manejador de servicios se
encarga de enviar las peticiones particulares de servicios a los
manejadores espacializados para consulta, reserva y compra.
Dominio
El mdulo Dominio est compuesto por las clases:
Vuelo - Clase Entidad. Se denomina por medio de un nmero. El
vuelo tiene como origen un aeropuerto en una ciudad y tiene como
destino un aeropuerto de otra ciudad. Un vuelo puede tener
mltiples escalas y mltiples vuelos se relacionan por medio de
conexiones. El vuelo pertenece a una aerolnea y puede operar
varios das a la semana teniendo un horario de salida y otro de
llegada.
Reservacin - Clase Entidad. Para poder tomar un vuelo es
necesario contar con una reservacin previa, la cual debe pagarse

antes de una fecha lmite, que puede ser el propio da del vuelo.
Una reservacin puede hacerse para mltiples vuelos y mltiples
pasajeros. La reservacin cuenta con una clave identificando un
rcord de reservacin particular.
Horario - Clase Entidad. El horario de un vuelo se determina por
su hora de salida y hora de llegada durante los das que opera.
Aerolnea - Clase Entidad. La aerolnea provee servicio de
mltiples vuelos entre diferentes ciudades bajo diferentes horarios.
La aerolnea se identifica por un nombre.
Aeropuerto - Clase Entidad. El aeropuerto sirve como origen,
destino y escalas de un vuelo. El aeropuerto se encuentra en una
ciudad de un pas determinado.
Tarifa - Clase Entidad. Los diferentes vuelos tienen mltiples tarifas
para compra de boleto, variando segn la clase de boleto, si son de
ida o de ida y vuelta, y dependiendo de las diversas restricciones y
ofertas existentes.
Asiento - Clase Entidad. Una reservacin de vuelo puede incluir la
asignacin de asiento, especificada mediante una fila y un nmero.
El nmero de asientos disponibles en un vuelo particular dependen
del tipo de avin que opere ese da.
Pasajero - Clase Entidad. Para poder hacer una reservacin se
requiere dar el nombre del pasajero. Varios pasajeros pueden
aparecer bajo una sola reservacin
Avin - Clase Entidad. Un vuelo en una fecha determinada se hace
en un tipo de avin particular. El tipo de avin define la cantidad
mxima de pasajeros que pueden viajar en ese vuelo para esa
fecha.
ViajeroFrecuente - Clase Entidad. El pasajero tiene la opcin de
acumular millas para un vuelo particular si cuenta con una tarjeta
de viajero frecuente para la aerolnea correspondiente.
Consultas

El mdulo Consultas se divide en los siguientes

mdulos: ConsultasPrincipal, Horarios, Tarifas y Estado, como se
muestra en la Figura 7.59.

Figura 7.59 Mdulos adicionales del mdulo Consultas.

ConsultasPrincipal
El mdulo ConsutlasPrincipal est compuesto por las clases:
PaginaConsultas - Clase Interface. Pgina de presentacin de
consultas (P-7).
ManejadorConsultas - Clase Control. El manejador de consulta se
encarga de enviar las peticiones de consulta particular a los
manejadores de consulta especializados.
Horarios
El mdulo Horarios est compuesto por las clases:
PaginaConsultaHorarios - Clase Interface. Pgina de
presentacin de consulta de horarios (P-8).
PaginaResultadoHorarios - Clase Interface. Pgina de devolucin
de consulta de horarios (P-9).
ManejadorConsultaHorarios - Clase Control. El manejador de
consulta de horarios se encarga de controlar las peticiones de
consulta de horarios.

Tarifas
El mdulo Tarifas est compuesto por las clases:
PaginaConsultaTarifas - Clase Interface. Pgina de presentacin
de consulta de tarifas (P-10).
PaginaResultadoTarifas - Clase Interface. Pgina de devolucin
de consulta de tarifas (P-11
ManejadorConsultaTarifas - Clase Control. El manejador de
consulta de tarifas se encarga de controlar las peticiones de
consulta de tarifas. Estado El mdulo Estado est compuesto por
las clases:
PaginaConsultaEstado - Clase Interface. Pgina de presentacin
de consulta de estado (P-12).
PaginaResultadoEstado - Clase Interface. Pgina de devolucin
de consulta de estado (P-13).
ManejadorConsultaEstado - Clase Control. El manejador de
consulta de estado se encarga de controlar las peticiones de
consulta de estado.
Reservas
El mdulo Reservas est compuesto por las clases:
PaginaClaveReservas - Clase Interface. Pgina de solicitud de
clave de reservas (P-14).
PaginaCrearReservaVuelos - Clase Interface. Pgina de solicitud
de reservas (P-15).
PaginaRecordReservaVuelos - Clase Interface. Pgina de
devolucin de reservas (P-16).
ManejadorReservas - Clase Control. El manejador de reserva se
encarga de enviar las solicitudes de reserva a la base de datos del
sistema de reservaciones.

Pagos
El mdulo Pagos est compuesto por las clases:
PaginaPagoReserva - Clase Interface. Pgina de solicitud de
pago de reservas (P-17)
PaginaReembolsoReserva - Clase Interface. Pgina de solicitud
de reembolso de pago (P-18).
ManejadorPagos - Clase Control. El manejador de compra se
encarga de enviar las solicitudes de compra de boleto a la base de
datos del sistema de reservaciones.