Investigacin y fuente: De modelo de nalisis

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 ladimensinde 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 dedos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es deunasla 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 lossistemas de informacin,uno de las tipos de arquitecturas mas importantes es la arquitectuaMVC Modelo, Vista, Control(Model, View, Control) popularizada por los ambientes de desarrollo deSmalltalk. 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 arquitecturaMVCpara 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 EstereotiposEl tipo defuncionalidadola razn de serde un objeto dentro de una arquitectura se le conoce como suestereotipo.Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos: El estereotipoentidadpara 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 estereotipointerfacepara 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 estereotipocontrolpara 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.>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 UsoCuando 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 usoimprimir 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 usoimprimir archivose 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, Archivocon sus subclasesArchivo Texto, Archivo Formateado y Archivo Grficoy 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 multiplicidadEl 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.InterfaceToda 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 paraReservar un Asiento en un Vueloel 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 losactores 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 laBase 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 llamaremospginaspor 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 actoresUsuario y Base de Datos Registrosa travs de las clasesinterface InterfaceUsuario e InterfaceBaseDatosRegistro, respectivamente. Se utiliza la pantalla principal del sistema(P-1)dado que el caso de uso se instancia mediante el botnRegistrarse por Primera Vezo mediante la validacin de un usuario existente (esta validacin se hace a travs del caso de usoValidar Usuarioque es incluido enRegistrar Usuario). Esta pantalla ser implementada por la clase interfacePginaPrincipal.Asimismo se debe incluir la clase interfacePginaServiciocorrespondiente a la pantalla del men de servicios(P-2)dado que se puede accesar este caso de uso a travs del botnObtener 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 llamaremosPginaCrearRegUsuario 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 actoresUsuario y Base de Datos Registrosa travs de las clases interfaceInterfaceUsuario 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 interfacePginaPrincipal 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 actoresUsuario y Base de Datos Registrosa travs de las clasesinterface InterfaceUsuario e InterfaceBaseDatosRegistro, respectivamente. Se utilizan las pantallas de registro de tarjeta por primera vez(P-5)y registro de tarjeta(P-6).A las dos clases interface correspondientes las llamaremosPginaCrearRegTarjeta y PginaObtenerRegTarjeta,respectivamente. Adems se incluyen las clasesPginaCrearRegUsuario y PginaObtenerRegUsuariocorrespondientes a la pantallas de registro de usuario por primera Vez(P-3) yde obtener registro(P-4)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 actoresUsuario y Base de Datos Reservasa travs de las clases interfaceInterfaceUsuario 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 usoValidar Usuarioque es incluido en Registrar Usuario). Esta pantalla ser implementada por la clase interfacePginaPrincipal.Asimismo se debe incluir la clase interfacePginaServiciocorrespondiente a la pantalla del men de servicios(P-2)dado que se puede accesar este caso de uso a travs del botnConsultar 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(P-11),consulta de estado de vuelo(P-12)y resultado de consulta de estado de vuelo(P-13).A las clases interface correspondientes las llamaremosPginaConsultas, 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 actoresUsuario y Base de Datos Reservasa travs de las clases interfaceInterfaceUsuario 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 usoValidar Usuarioque es incluido enRegistrar Usuario). Esta pantalla ser implementada por la clase interfacePginaPrincipal.Asimismo se debe incluir la clase interfacePginaServiciocorrespondiente a la pantalla del men de servicios(P-2)dado que se puede accesar este caso de uso a travs del botnHacer 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 llamaremosPginaClaveReservas, 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 actoresUsuario y Base de Datos Reservasa travs de las clases interfaceInterfaceUsuario 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 clasesPginaCrearRegUsuario y PginaObtenerRegUsuariocorrespondientes 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 UsoActoresClases Interface

Registrar UsuarioUsuario, Base de Datos RegistrosInterfaceUsuario, PginaPrincipal, PginaServicio, PginaCrearRegUsuario, PginaObtenerRegUsuario, InterfaceBaseDatosRegistro

Validar UsuarioUsuario, Base de Datos RegistrosInterfaceUsuario, PginaPrincipal, InterfaceBaseDatosRegistro

Usuario, Base deRegistrar Tarjeta Datos RegistrosInterfaceUsuario, PginaCrearRegUsuario, PginaObtenerRegUsuario, PginaCrearRegTarjeta, PginaObtenerRegTarjeta, InterfaceBaseDatosRegistro

Consultar InformacinUsuario, Base de Datos ReservasInterfaceUsuario, PginaPrincipal, PginaServicio, PginaConsultas, PginaConsultaHorarios, PginaResultadoHorarios, PginaConsultaTarifas, PginaResultadoTarifas, PginaConsultaEstado, PginaResultadoEstado, InterfaceBaseDatosReserva

Hacer ReservacinUsuario, Base de Datos ReservasInterfaceUsuario, PginaPrincipal, PginaServicio, PginaClaveReservas, PginaCrearReservaVuelos, PginaRecordReservaVuelos, InterfaceBaseDatosReserva

Pagar ReservacinUsuario, Base de Datos ReservasInterfaceUsuario, PginaCrearReservaVuelos, PginaRecordReservaVuelos, PginaPagoReserva, PginaReembolsoReserva, InterfaceBaseDatosReserva

Tabla 7.1 Relacin entre casos de uso, actores y clases interface para el sistema de reservaciones de vuelo.EntidadSe 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 entidadDada 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 entidadRegistroUsuario.En la Figura 7.18 se muestran las clases entidad identificadas en este caso de uso.

>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 entidadRegistroUsuario, utilizada tambin por el caso de usoRegistrarUsuario.En la Figura 7.19 se muestran las clases entidad identificadas en este caso de uso.

>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 entidadRegistroTarjeta.En la Figura 7.20 se muestran las clases entidad identificadas en este caso de uso.>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 entidadAsiento, 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 entidadAsiento, 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 UsoClases Entidad

Registrar UsuarioRegistroUsuario

Validar UsuarioRegistroUsuario

Registrar TarjetaRegistroTarjeta

Consultar InformacinAsiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario

Hacer ReservacinAsiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero, Reservacin

Pagar ReservacinAsiento, 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.ControlHasta 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 enobjetos 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 controlManejadorRegistroUsuario.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 llamaremosManejadorPrincipal 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 controlManejadorRegistroTarjeta. Dado que es una extensin al caso de usoRegistrar Usuarioes necesario incluir alManejadorRegistroUsuariopero 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 clasecontrol 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 controlManejadorPrincipal 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 usoConsultar Informacin, tambin es necesario utilizar las clases controlManejadorPrincipal 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 clasecontrol ManejadorPagos.Dado que es una extensin al caso de uso Hacer Reservacin es necesario incluir el control de reservasManejadorReservas.Adems existe una relacin con el caso de usoRegistrar Tarjetapor lo cual es necesario incluir el control de registro de tarjetaManejadorRegistroTarjeta.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 UsoClases Control

Registrar UsuarioManejadorPrincipal, ManejadorServicios, ManejadorRegistroUsuario

Validar UsuarioManejadorPrincipal, ManejadorRegistroUsuario

Registrar TarjetaManejadorRegistroUsuario, ManejadorRegistroTarjeta

Consultar InformacinManejadorPrincipal, ManejadorServicios, ManejadorConsultas, ManejadorConsultaHorarios, ManejadorConsultaTarifas, ManejadorConsultaEstado

Hacer ReservacinManejadorPrincipal, ManejadorServicios, ManejadorReservas

Pagar ReservacinManejadorReservas, 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 dediagramas 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 representandoinstanciasde 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 utilizanestmulos 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 aactividadesdentro del objeto, denominadas por a, mientras que las flechas corresponden aeventos, denominadas pore.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 formaton:. 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 laClase1que recibe un evento e1, el cual inicia una actividad que consiste en primero generar un eventoe2y posteriormente otro eventoe6. 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 elActor1a travs del eventoe1.Este evento da lugar al eventoe2el cual a su vez da lugar al eventoe3y as sucesivamente hasta llegar el eventoe7.Sin embargo se interrumpe la continuidad entre el eventoe7y el eventoe8.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 losflujos principales y subflujospara 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 UsuarioEn el caso de usoRegistrar Usuarioexisten 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 subflujosCrear Registro Usuario (S-1), Actualizar Registro Usuario (S-4) y Eliminar Registro Usuario (S-5).Ntese que los subflujos Obtener Registro Usuario (S-2)yManipular Registro Usuario (S-3)sern instanciados en los ltimos dos subflujos mientras que el flujo principal estar presente en todos.Crear Registro UsuarioEl diagrama de secuencia para el subflujoCrear 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 claseInterfaceUsuariocomo 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 aInterfaceUsuario.Durante el diseo extenderemos ms esta explicacin. De tal manera la claseInterfaceUsuarioenva el evento inicializar a la claseManejadorPrincipalque 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 deInterfaceUsuario. ElManejadorPrincipal solicita el desplegado de laPaginaPrincipalmediante el eventodesplegarPginaPrincipal. En este momento el usuario ya puede interactuar con el sistema. Para que se instancie este subflujo, el usuario debe seleccionar la opcin deRegistrarPorPrimeraVezoprimiendo el botn correspondiente en la pgina. Siendo consistente con la lgica anterior, que las interfaces e interaccin con el usuario son controladas por laInterfaceUsuario,pues esta clase recibe el evento y se lo enva como un nuevo eventocrearRegUsuario al ManejadorPrincipal. El ManejadorPrincipalque 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 laInterfaceUsuarioel desplegado de la pgina correspondiente mediante desplegarPaginaCrearRegUsuario.LaInterfaceUsuariodespliega 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 botnRegistrarpara que esta informacin sea enviada a la claseInterfaceUsuario.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 InterfaceUsuarioenva el eventocrearRegUsuarioalManejadorRegistroUsuario.Este controlador es responsable de guardar la informacin de registro del usuario, por lo cual enva el eventoescribirRegUsuarioa laInterfaceBaseDatosRegistro.Ntese que como en el caso de los datos, los objetos entidad como la claseRegistroUsuario,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 laInterfaceUsuario.Prosiguiendo con nuestra lgica, laInterfaceBaseDatosRegistroenva el evento escribirRegUsuarioal actorBase de Datos Registros.Este actor debe responder de alguna manera, y lo hace mediante unOKel cual es luego enviado de manera sucesiva hasta llegar finalmente aInterfaceUsuario.En ese momento elUsuariopresionaSalir,dando por concluido el subflujo.Ntese que si el usuario decidiera oprimir algn otro botn, comoRegistrar 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 elUsuarioque 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 laInterfaceUsuarioy elUsuarioya 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 evento8es en respuesta al evento6,mientras que el evento12es en respuesta al evento9.Un ejemplo de respuesta indirecta es el caso del evento4respondido mediante los eventos5 y 6.Una situacin particular se da con el ltimo evento correspondiente aSalir,el cual interrumpe estos flujos de respuesta ya que en algn lugar se debe terminar la secuencia.Actualizar Registro UsuarioEl diagrama de secuencia para el subflujoActualizar Registro Usuario (S-4)se muestra en el diagrama 7.42. Este subflujo requiere de una validacin del usuario junto con el seguimiento del subflujoObtener Registro Usuario (S-2)yManipular Registro Usuario (S-3)para llegar a la actualizacin. Se comienza la secuencia el evento inicializar de la claseInterfaceUsuario al ManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.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 eventoOKoprimiendo el botn correspondiente, se instancia la validacin. LaInterfaceUsuarioenva esta vez el eventovalidarRegUsuario al ManejadorPrincipal.ElManejadorPrincipalreconoce 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 laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante un evento adicional con el mismo nombre. LaInterfaceBaseDatosRegistroenva a su vez un evento similar al actorBase de Datos Registros, el cual contesta con unOKsi la validacin es buena. Dado que slo consideramos una secuencia de eventos, una validacin incorrecta se mostrara en otro diagrama. ElOKes sucesivamente enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK, solicita alManejadorServicios que entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios. LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarObtenerRegistro.Este evento es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoobtenerRegUsuario.Este mismo evento es luego enviado por elManejadorServicios al ManejadorRegistroUsuarioel cual solicita a laInterfaceBaseDatosRegistroque obtenga el registro correspondiente medianteleerRegUsuario. Nuevamente, laInterfaceBaseDatosRegistrole pasa un evento similar al actorBase de Datos Registros,el cual contesta con unOK. Junto a esteOKdeben enviarse los propios datos, los cuales no son mostrados por no generar eventos. ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorRegistroUsuarioel cual solicita a laInterfaceUsuariodesplegar la pgina de informacin de registro mediante el eventodesplegarPginaObtenerRegUsuario. Hasta aqu la secuencia es parte del subflujoObtener Registro Usuario.En este momento el usuario actualiza sus datos, que no se muestran aqu, y oprime el botnActualizarpara que esta informacin sea enviada a la claseInterfaceUsuario.Siguiendo con la lgica, laInterfaceUsuarioenva el eventoactualizarRegUsuarioalManejadorRegistroUsuario,el cual es responsable de actualizar el registro, por lo cual enva el eventoescribirRegUsuarioa laInterfaceBaseDatosRegistro.Esta ltima etapa es similar a la del subflujoCrear Registro Usuario. LaInterfaceBaseDatosRegistroenva el eventoescribirRegUsuarioal actorBase de Datos Registros.Este actor responde mediante unOKel cual es luego enviado de manera sucesiva hasta llegar finalmente aInterfaceUsuario.En ese momento elUsuariopresionaSalir,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 UsuarioEl diagrama de secuencia para el subflujoEliminar Registro Usuario (S-5)se muestra en el diagrama 7.43. Este subflujo es muy similar al deActualizar Registro Usuariohasta donde llega la secuencia deObtener Registro Usuario,comenzando desde la validacin del usuario. Se comienza la secuencia el evento inicializar de la claseInterfaceUsuario al ManejadorPrincipal el cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario.ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarObtenerRegistro.Este evento es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoobtenerRegUsuario.Este mismo evento es luego enviado por elManejadorServiciosalManejadorRegistroUsuarioel cual solicita a laInterfaceBaseDatosRegistro queobtenga el registro correspondiente medianteleerRegUsuario.Nuevamente, laInterfaceBaseDatosRegistrole pasa un evento similar al actorBase de Datos Registros,el cual contesta con unOK. ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorRegistroUsuarioel cual solicita a laInterfaceUsuariodesplegar la pgina de informacin de registro mediante el eventodesplegarPginaObtenerRegUsuario.Hasta aqu la secuencia es parte del subflujoObtener Registro Usuarioy es similar al subflujoActualizar Registro Usuario. En este momento el usuario oprime el botnEliminar.La InterfaceUsuarioenva el eventoeliminarRegUsuario alManejadorRegistroUsuario,el cual es responsable de eliminar el registro, por lo cual enva el eventoeliminarRegUsuarioa laInterfaceBaseDatosRegistro.LaInterfaceBaseDatosRegistroenva el eventoeliminarRegUsuarioal actorBase de Datos Registros.Este actor responde mediante unOKel cual es luego enviado de manera sucesiva hasta llegar finalmente aInterfaceUsuario. No es necesario que Usuariogenere el eventoSalir,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 UsuarioEl diagrama de secuencia para el flujoValidar Usuariose 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal. El usuario se valida enviando el eventoOK. LaInterfaceUsuarioenva el eventovalidarRegUsuario alManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro, de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo 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 TarjetaEn el caso de usoRegistrar Tarjetaexisten 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 usoRegistrar Usuario,mostraremos la secuencia completa desde su inicio en el diagrama para mayor claridad.Crear Registro TarjetaEl diagrama de secuencia para el subflujoCrear 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros, el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediante desplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarObtenerRegistro.Este evento es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoobtenerRegUsuario.Este mismo evento es luego enviado por el ManejadorServicios alManejadorRegistroUsuarioel cual solicita a laInterfaceBaseDatosRegistroque obtenga el registro correspondiente medianteleerRegUsuario. Nuevamente, laInterfaceBaseDatosRegistrole pasa un evento similar al actorBase de Datos Registros,el cual contesta con unOK.ElOKes luego enviado porla InterfaceBaseDatosRegistroalManejadorRegistroUsuarioel cual solicita a laInterfaceUsuariodesplegar la pgina de informacin de registro mediante el eventodesplegarPginaObtenerRegUsuario. Hasta aqu la secuencia es parte del subflujoObtener Registro UsuarioyManipular Registro Usuario,siendo similar al subflujoActualizar Registro Usuario.En este momento el usuario oprime el botnRegistrar Tarjeta.LaInterfaceUsuarioenva el eventoobtenerRegTarjeta alManejadorRegistroUsuario, el cual le enva el mismo evento alManejadorRegistroTarjeta.Este controlador, que es responsable de todo lo relacionado con el registro de tarjeta, enva el eventoleerRegTarjetaa laInterfaceBaseDatosRegistro.LaInterfaceBaseDatosRegistroenva el mismo evento al actorBase de Datos Registros. Este actor responde mediante un vaca correspondiente a un registro de tarjeta an no llenado. Este evento es enviado de regreso alManejadorRegistroTarjetael cual solicitadesplegarPaginaCrearRegistroTarjeta a InterfaceUsuario.El usuario registra sus datos de tarjeta y presiona el botn deRegistrargenerando el eventoRegistrar.Como consecuencia de este evento,InterfaceUsuarioenva el eventocrearRegTarjeta al ManejadorRegistroTarjetael cual enva el eventoescribirRegTarjetaaInterfaceBaseDatosRegistro.Este ltimo enva el mismo evento al actorBase de Datos Registros, el cual contesta con unOKque es sucesivamente enviado de regreso a travs deInterfaceBaseDatosRegistro, ManejadorRegistroTarjetaeInterfaceUsuario.En ese momento elUsuariopresionaSalir, 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 TarjetaEl diagrama de secuencia para el subflujoActualizar Registro Tarjeta (S-4)se muestra en el diagrama 7.46. Este subflujo es muy similar aCrear Registro Tarjeta (S-1)y comienza con la validacin del usuario a partir del evento inicializar de la claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con un OKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro, de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK, solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios. ElManejadorServiciossolicita entonces ala InterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarObtenerRegistro.Este evento es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoobtenerRegUsuario.Este mismo evento es luego enviado por elManejadorServiciosalManejadorRegistroUsuarioel cual solicita a laInterfaceBaseDatosRegistroque obtenga el registro correspondiente medianteleerRegUsuario. Nuevamente, laInterfaceBaseDatosRegistrole pasa un evento similar al actorBase de Datos Registros,el cual contesta con unOK.ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorRegistroUsuarioel cual solicita a la InterfaceUsuariodesplegar la pgina de informacin de registro mediante el evento desplegarPginaObtenerRegUsuario.En este momento el usuario oprime el botnRegistrar Tarjeta.LaInterfaceUsuarioenva el eventoobtenerRegTarjeta 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 eventoleerRegTarjetaa laInterfaceBaseDatosRegistro. LaInterfaceBaseDatosRegistroenva el mismo evento al actorBase de Datos Registros.Hasta aqu la secuencia es similar al subflujoCrear Registro Tarjeta,ya que el actorBase de Datos Registrosresponde ahora mediante unOKcorrespondiente a un registro de tarjeta existente. Este evento es enviado de regreso alManejadorRegistroTarjetael cual solicitadesplegarPaginaObtenerRegistroTarjetaaInterfaceUsuario.El usuario actualiza sus datos de tarjeta y presiona el botn deActualizargenerando el eventoActualizar.Como consecuencia de este evento,InterfaceUsuarioenva el eventoactualizarRegTarjetaalManejadorRegistroTarjetael cual enva el eventoescribirRegTarjetaaInterfaceBaseDatosRegistro. Este ltimo enva el mismo evento al actorBase de Datos Registros, el cual contesta con unOKque es sucesivamente enviado de regreso a travs deInterfaceBaseDatosRegistro, ManejadorRegistroTarjetaeInterfaceUsuario.En ese momento elUsuariopresionaSalir,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 TarjetaEl diagrama de secuencia para el subflujoEliminar Registro Tarjeta (S-5)se muestra en el diagrama 7.47. Este subflujo es muy similar aActualizar Registro Tarjeta (S-4)y comienza con la validacin del usuario a partir del evento inicializar de la claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServicios que entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarObtenerRegistro.Este evento es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoobtenerRegUsuario.Este mismo evento es luego enviado por elManejadorServiciosalManejadorRegistroUsuarioel cual solicita a laInterfaceBaseDatosRegistroque obtenga el registro correspondiente medianteleerRegUsuario.Nuevamente, laInterfaceBaseDatosRegistrole pasa un evento similar al actorBase de Datos Registros,el cual contesta con unOK.ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorRegistroUsuarioel cual solicita a laInterfaceUsuariodesplegar la pgina de informacin de registro mediante el eventodesplegarPginaObtenerRegUsuario.En este momento el usuario oprime el botnRegistrar Tarjeta.LaInterfaceUsuarioenva el evento obtenerRegTarjeta al ManejadorRegistroUsuario, el cual le enva el mismoevento al ManejadorRegistroTarjeta. Este controlador, que es responsable de todo lo relacionado con el registro de tarjeta, enva el eventoleerRegTarjeta a la InterfaceBaseDatosRegistro.LaInterfaceBaseDatosRegistroenva el mismo evento alactor Base de Datos Registros.El actor Base de Datos Registrosresponde mediante unOKcorrespondiente a un registro de tarjeta existente. Este evento es enviado de regreso alManejadorRegistroTarjetael cual solicitadesplegarPaginaObtenerRegistroTarjetaaInterfaceUsuario.Hasta aqu la secuencia es similar al subflujoActualizar Registro Tarjeta,ya que el usuario presiona el botn deEliminargenerando el eventoEliminar. Como consecuencia de este evento,InterfaceUsuarioenva el eventoeliminarRegTarjetaalManejadorRegistroTarjetael cual enva el eventoeliminarRegTarjetaaInterfaceBaseDatosRegistro. Este ltimo enva el mismo evento alactor Base de Datos Registros, el cual contesta con unOKque es sucesivamente enviado de regreso a travs deInterfaceBaseDatosRegistro, ManejadorRegistroTarjetaeInterfaceUsuario.En ese momento elUsuariopresionaSalir, 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 InformacinEn el caso de usoConsultar Informacinexisten diversos subflujos que pueden ser instanciados por un usuario. En esta seccin mostraremos un diagrama de secuencias para los subflujosConsultar Horarios (S-2), Consultar Tarifas (S-3)yConsultar Estado (S-4).Consultar HorarioEl diagrama de secuencia para el subflujoConsultar 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.La InterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario.ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro, de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios. LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarConsultar Informacin. Se genera el eventoConsultarque es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoconsultarInformacin.Este mismo evento es luego enviado por elManejadorServiciosalManejadorConsultasel cual enva el eventodesplegarPaginaConsultasaInterfaceUsuario.El usuario presionaHorarioslo cual genera el eventoConsultarHorarios. InterfaceUsuario enva este evento de regreso aManejadorConsultasel cual enva el eventoconsultarHorariosalManejadorConsultaHorarios.Este a su vez enva el eventodesplegarPaginaConsultaHorariosa InterfaceUsuario. El usuario llena la informacin de la consulta y oprime el botnConsultarel cual genera el evento consultar deInterfaceUsuarioalManejadorConsultaHorarios. Este ltimo enva el eventoconsultarHorariosa laInterfaceBaseDatosReservas para que haga la peticin correspondiente al actorBase de Datos Reservas, el cual contesta con unOK.ElOKes luego enviado por la InterfaceBaseDatosRegistroalManejadorConsultaHorariosel cual solicita a laInterfaceUsuariodesplegar la pgina de resultado de la bsqueda mediante el eventodesplegarPginaResultadoHorarios.En ese momento elUsuariopresionaSalir,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 TarifasEl diagrama de secuencia para el subflujoConsultar 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el evento desplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario.ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipal como respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el evento ofrecerServicios. ElManejadorServiciossolicita entonces a la InterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarConsultar Informacin. Se genera el eventoConsultarque es enviado de laInterfaceUsuarioalManejadorServicios mediante el eventoconsultarInformacin.Este mismo evento es luego enviado por elManejadorServiciosalManejadorConsultasel cual enva el eventodesplegarPaginaConsultasaInterfaceUsuario. Hasta aqu la secuencia es similar al subflujoConsultar Horarios (S-2).En este subflujo, el usuario presionaTarifaslo cual genera el eventoConsultarTarifas.InterfaceUsuarioenva este evento de regreso aManejadorConsultasel cual enva el eventoconsultarTarifasalManejadorConsultaTarifas.Este a su vez enva el eventodesplegarPaginaConsultaTarifasaInterfaceUsuario.El usuario llena la informacin de la consulta y oprime el botnConsultarel cual genera el evento consultar de InterfaceUsuarioalManejadorConsultaTarifas.Este ltimo enva el eventoconsultarTarifasa la InterfaceBaseDatosReservaspara que haga la peticin correspondiente al actorBase de Datos Reservas, el cual contesta con unOK. ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorConsultaTarifasel cual solicita a laInterfaceUsuario desplegar la pgina de resultado de la bsqueda mediante el eventodesplegarPginaResultadoTarifas.En ese momento elUsuariopresionaSalir,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 EstadoEl diagrama de secuencia para el subflujoConsultar 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK. LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal. ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro, de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarConsultar Informacin. Se genera el eventoConsultarque es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventoconsultarInformacin.Este mismo evento es luego enviado por elManejadorServiciosalManejadorConsultasel cual enva el eventodesplegarPaginaConsultasaInterfaceUsuario.Hasta aqu la secuencia es similar al subflujoConsultar Horarios (S-2)y al subflujoConsultar Tarifas (S-3).En este subflujo, el usuario presionaEstadolo cual genera el eventoConsultarEstado.InterfaceUsuario enva este evento de regreso aManejadorConsultasel cual enva el eventoconsultarHorariosalManejadorConsultaEstado.Este a su vez enva el eventodesplegarPaginaConsultaEstadoaInterfaceUsuario.El usuario llena la informacin de la consulta y oprime el botnConsultarel cual genera el evento consultar deInterfaceUsuarioalManejadorConsultaEstado.Este ltimo enva el eventoconsultarEstadosa laInterfaceBaseDatosReservaspara que haga la peticin correspondiente al actorBase de Datos Reservas,el cual contesta con unOK. ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorConsultaEstadoel cual solicita a laInterfaceUsuariodesplegar la pgina de resultado de la bsqueda mediante el eventodesplegarPginaResultadoEstado.En ese momento elUsuariopresionaSalir,dando por concluido el subflujo.Hacer ReservacinEn el caso de usoHacer Rservacinexisten 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 (S-5)yEliminar Reservacin (S-6).Crear ReservacinEl diagrama de secuencia para el subflujoCrear 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 claseInterfaceUsuarioalManejadorPrincipal el cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro, de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK, solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios. LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarHacer Reservacin.Se genera el eventoHacerReservacinque es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventohacerReservacin. ElManejadorServiciosenva el eventoobtenerReservacinalManejadorReservasel cual enva el eventodesplegarPaginaClaveReservasaInterfaceUsuario.El usuario presiona el botnCreary se genera el eventoCrear.LaInterfaceUsuarioenva el eventocrearReservade regreso aManejadorReservasel cual enva el eventodesplegarPaginaCrearReservaVuelosaInterfaceUsuario.El usuario presionaReservarlo cual genera el eventoReservar. LaInterfaceUsuario enva el eventocrearReservade regreso aManejadorReservasel cual enva el eventocrearReservaa laInterfaceBaseDatosReservaspara que haga la peticin correspondiente alactor Base de Datos Reservas, el cual contesta con unOK.ElOK es luego enviado por laInterfaceBaseDatosRegistroalManejadorReservasel cual solicita a laInterfaceUsuariodesplegar la pgina de resultado de la solicitud de reserva mediante el eventodesplegarPginaRecordReservaVuelos. En ese momento elUsuariopresionaSalir,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 ReservacinEl diagrama de secuencia para el subflujoActualizar 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.La InterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario.ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro, de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK, solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarHacer Reservacin. Se genera el eventoHacerReservacinque es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventohacerReservacin.ElManejadorServiciosenva el evento obtenerReservacinalManejadorReservasel cual enva el eventodesplegarPaginaClaveReservasaInterfaceUsuario.El usuario presiona el botnObtener, junto con la insercin de la clave de rcord de reservas, y se genera el eventoObtener. LaInterfaceUsuarioenva el eventoobtenerReservade regreso aManejadorReservasel cual enva el eventoleerReservaa laInterfaceBaseDatosReservas,la cual a su vez enva este evento alactor Base de Datos Reservas.Elactorgenera unOKsi todo es correcto y se lo enva de regreso aInterfaceBaseDatosReservas, la cual luego lo enva aManejadorReservas.ElManejadorReservasenva el eventodesplegarPaginaRecordReservaVuelosaInterfaceUsuario.El usuario actualiza los datos de su reservacin y presionaActualizarlo cual genera el eventoActualizar. LaInterfaceUsuarioenva el eventoactualizarReservade regreso aManejadorReservasel cual enva el eventoescribirReservaa laInterfaceBaseDatosReservaspara que haga la peticin correspondiente al actorBase de Datos Reservas,el cual contesta con unOK. ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorReservasel cual solicita a laInterfaceUsuariodesplegar la pgina de resultado de la actualizacin de reserva mediante el eventodesplegarPginaRecordReservaVuelos.En ese momento elUsuariopresionaSalir, 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 ReservacinEl diagrama de secuencia para el subflujoEliminar 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario. ElManejadorRegistroUsuariosolicita a laInterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a laBase de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediante desplegarPaginaServicios.La InterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarHacer Reservacin. Se genera el eventoHacerReservacinque es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventohacerReservacin.ElManejadorServiciosenva el evento obtenerReservacinalManejadorReservas,el cual enva el eventodesplegarPaginaClaveReservasaInterfaceUsuario.El usuario presiona el botnObtener,junto con la insercin de la clave de rcord de reservas, y se genera el eventoObtener.LaInterfaceUsuarioenva el evento obtenerReservade regreso aManejadorReservasel cual enva el eventoleerReservaa laInterfaceBaseDatosReservas,la cual a su vez enva este evento alactor Base de Datos Reservas.El actor genera unOKsi todo es correcto y se lo enva de regreso aInterfaceBaseDatosReservas,la cual luego lo enva aManejadorReservas. ElManejadorReservasenva el eventodesplegarPaginaRecordReservaVuelosaInterfaceUsuario.Hasta aqu la secuencia es similar al subflujoActualizar Reservacin (S-5).En este momento el usuario presionaEliminarlo cual genera el eventoEliminar. InterfaceUsuarioenva el eventoeliminarReservade regreso aManejadorReservasel cual enva el eventoeliminarReservaa laInterfaceBaseDatosReservaspara que haga la peticin correspondiente al actorBase de Datos Reservas,el cual contesta con unOK. ElOKes luego enviado por laInterfaceBaseDatosRegistroalManejadorReservasel cual solicita a laInterfaceUsuariodesplegar la pgina de resultado de la eliminacin de reserva mediante el evento desplegarPginaRecordReservaVuelos. En ese momento elUsuariopresionaSalir,dando por concluido el subflujo.

Figura 7.53 Diagrama de secuencia para el subflujo Eliminar Reservacin (S-6) del caso de uso Hacer Reservacin.Pagar ReservacinEn el caso de usoPagar Rservacinexisten diversos subflujos que pueden ser instanciados por un usuario. En esta seccin mostraremos un diagrama de secuencias para los subflujosPagar Reservacin (S-1)yReembolsar Pago (S-2).Pagar ReservacinEl diagrama de secuencia para el subflujoPagar 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 claseInterfaceUsuarioalManejadorPrincipalel cual le responde mediante el eventodesplegarPginaPrincipal.El usuario se valida enviando el eventoOK.LaInterfaceUsuarioenva el eventovalidarRegUsuarioalManejadorPrincipal.ElManejadorPrincipalenva el eventovalidarRegUsuarioalManejadorRegistroUsuario.ElManejadorRegistroUsuariosolicita a la InterfaceBaseDatosRegistroque haga una validacin del usuario mediante el mismo evento. LaInterfaceBaseDatosRegistroenva a su vez el evento a la Base de Datos Registros,el cual contesta con unOKsi la validacin es buena. ElOKes enviado a laInterfaceBaseDatosRegistro,de all aManejadorRegistroUsuarioy luego aManejadorPrincipalcomo respuesta a las secuencias de validacin. Una vez elManejadorPrincipalrecibi este ltimoOK,solicita alManejadorServiciosque entre en accin mediante el eventoofrecerServicios.ElManejadorServiciossolicita entonces a laInterfaceUsuarioel desplegado de la pgina correspondiente mediantedesplegarPaginaServicios.LaInterfaceUsuariodespliega esta pgina. Para continuar con la lgica principal de este subflujo, el usuario debe presionarHacer Reservaciny debe incluir un nmero correspondiente a la clave de reservacin. Se genera el eventoHacerReservacinque es enviado de laInterfaceUsuarioalManejadorServiciosmediante el eventohacerReservacin.ElManejadorServiciosenva el eventoobtenerReservacinalManejadorReservas.Dado que se incluye la clave de reservacin, elManejadorReservasenva el eventoleerReservaa laInterfaceBaseDatosReservas,la cual a su vez enva este evento al actorBase de Datos Reservas.El actor genera unOKsi todo es correcto y se lo enva de regreso aInterfaceBaseDatosReservas,la cual luego lo enva aManejadorReservas.ElManejadorReservasenva el eventodesplegarPaginaRecordReservaVuelosaInterfaceUsuario.Hasta aqu la secuencia es similar al subflujoActualizar Reservacin (S-5)yEliminar Reservacin (S-6)del caso de usoHacer Reser