Modelo de Diseño

Investigacin y fuente:]

Estrategias de Diseo.

Antes de poder resolver el diseo es necesario tomar decisiones generales sobre las estrategias de diseo a seguir. Algunas de las decisiones a tomar se presentan a continuacin y se relacionan con aspectos que incluyen la arquitectura, robustez, reuso y extensibilidaddel sistema.ArquitecturaEl trmino arquitectura se refiere, en nuestro caso, a la organizacin de las clases dentro del sistema. Durante el modelo de anlisis se gener una arquitectura de clases para el sistema y se defini la funcionalidad conceptual ofrecida por las distintas clases dentro de la arquitectura. Durante el diseo esta arquitectura debe detallarse, pudindose cambiar los aspectos considerados inicialmente, como fue la funcionalidad inicialmente asignada a cada clase, e incluso las propias clases, como hemos mencionado al inicio del captulo.El conocimiento y funcionalidad asignada a cada clase puede ser vista como la inteligencia de cada clase dentro del sistema. En otras palabras, algunas clases pueden ser vistas como ms inteligentes que otras segn el conocimiento y control que tengan sobre las dems clases. Por ejemplo,coleccionesde objetos tales comolistasoarreglos,no se consideran como particularmente inteligentes ya que pueden manipular y obtener informacin sobre las clases que almacenan, pero tienen relativamente poco impacto sobre estas u otras clases dentro del sistema. Por otro lado, un manejador de interface de usuario requiere mayor inteligencia, ya que debe poder administrar la interaccin con el usuario, incluyendo manejo de eventos y manipulaciones sobre las pantallas. Una clase an ms inteligente es el controlador o manejador de la lgica completa de la aplicacin, ya que es responsables de administrar a los propios manejadores de interface de usuario y relacionar su funcionalidad con el resto del sistema.Como parte de la arquitectura de diseo se debe decidir cmo distribuir la inteligencia entre las clase y qu aspectos de la inteligencia total del sistema debe ser asignada a cada una de ellas. Para esto existen tres alternativas principales: Un enfoque es minimizar el nmero de clases inteligentes. En el caso ms extremo, slo un objeto tendra conocimiento sobre todo el sistema. Todos los dems objetos tendrn un mnimo de inteligencia y el objeto inteligente servir como controlador del resto. Una ventaja de este enfoque es que slo se requerira comprender el flujo de control dentro del objeto principal para comprender toda de la aplicacin. Sin embargo, se vuelve ms compleja la extensibilidad del sistema, ya que cualquier cambio en el flujo de control se llevara a cabo en un mismo objeto afectando potencialmente la lgica de toda la aplicacin. En cierta manera esto puede considerarse como la estructuracin del programa, en otras palabras, transformando la orientacin a objetos a programacin estructurada, donde toda la aplicacin consta de un solo objeto.

Otro enfoque opuesto es distribuir la inteligencia del sistema lo ms homogneamente posible, diseando todas las clases con inteligencia similar. Este enfoque va ms con el espritu de la orientacin a objetos. Sin embargo, una distribucin perfectamente homognea es una tarea casi imposible, ya que los objetos varan en sus responsabilidades dependiendo de su razn de ser en la aplicacin. Por otro lado, distribuyendo la inteligencia del sistema de manera homognea entre los objetos permite que cada objeto sepa relativamente menos cosas. Esto produce objetos ms pequeos y ms fciles de comprender. La desventaja es que la inteligencia del sistema va de la mano con la especializacin de las clases. Si todas las clases son inteligentes, esto significar que ellas sern muy especializadas, dificultando la extensibilidad del sistema que requiere mayor generalizacin en las clases.

El tercer enfoque es encontrar un balance entre los dos primeros. La idea es homogenizar la inteligencia del sistema slo entre ciertas clases, tales como las de control. El resto de las clases sern tontas o genricas, cmo las clases entidad e interface, permitiendo un buen porcentaje de extensibilidad en el sistema. Esto sigue la lgica introducida durante el modelo de requisitos y posteriormente anlisis, donde se distingue entre las diversas razones de ser de las clases (comportamiento, presentacin y dominio) para lograr una mayor robustez del sistema.RobustezLa robustez de un sistema debe ser uno de los objetivos principales del diseo. Jams debe agregarse funcionalidad o simplificar cdigo a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos ofrecer diagnsticos para las fallas que an pudiesen ocurrir, en particular aquellas que son fatales. Durante el desarrollo es a veces bueno insertar instrucciones internas en el cdigo para descubrir fallas, aunque luego sean removidas durante la produccin. En general se debe escoger lenguajes de programacin que apoyen estos aspectos, como son el manejo de excepciones. Las principales consideraciones relacionadas con la robustez de un sistema son las siguientes: El sistema debe estar protegido contra parmetros incorrectos proporcionados por el usuario. Cualquier mtodo que acepte parmetros del usuario debe validar la entrada para evitar problemas. El diseador de mtodos debe considerar dos tipos de condiciones de error: (i) errores lgicos que son identificados durante el anlisis y (ii) errores de implementacin, incluyendo errores del sistema operativo, tales como los errores de asignacin de memoria, o errores de archivos de entrada y salida, etc.

El sistema no debe optimizarse hasta que este funcione de manera correcta. A menudo los programadores le dedican demasiado esfuerzo a mejorar partes del cdigo que se ejecutan poco frecuente. Optimizar requiere primero medir el rendimiento del sistema. Se debe estudiar las alternativas, como aspectos de memoria, velocidad, y simplicidad de implementacin. No se debe optimizar ms de lo necesario, ya que la optimizacin compromete la extensibilidad, reuso y comprensin del sistema.

El sistema debe incluir estructuras de datos que no tengan lmites predefinidos. Durante el diseo es difcil predecir la capacidad mxima esperada para la estructura de datos en la aplicacin. Por lo tanto, se debe escoger estructuras de datos como las listas, a diferencia de los arreglos.

El sistema debe instrumentar un monitoreo de rendimiento y bsqueda de errores. El esfuerzo para llevarlo a cabo depende del ambiente de programacin. Si el lenguaje de implementacin no proporciona ningn apoyo, se pueden aadir mtodos de impresin para cada clase. Tambin se pueden aadir mensajes de entrada y salida a los mtodos, imprimiendo selectivamente estos valores.

El encapuslamiento juega un papel fundamental para la robustez del sistema. Ocultar la informacin interna, atributos e implementacin de mtodos, a una clase permite que sta pueda ser cambiada sin afectar al resto del sistema. Unicamente la interface delos mtodos afecta a las dems clases.ReusoEl reuso es un aspecto fundamental del diseo. Cuanto ms se pueda reutilizar el cdigo mejor ser la robustez del sistema. Las siguientes son algunas estrategias para mejorar las posibilidades de reuso del diseo: A travs de la herencia se puede incrementar el reuso de cdigo. Se toman los aspectos comunes a clases similares utilizando superclases comunes. Este enfoque es efectivo cuando las diferencias entre las clases son pequeas y las similitudes son grandes. Es importante considerar la naturaleza de cada herencia para asegurar que no se est llendo a extremos donde la aplicacin de la herencia sea inadecuada.

El uso impropio de herencia puede hace que los programas sean difciles de mantener y extender. Como alternativa, la delegacin provee un mecanismo para lograr el reuso de cdigo pero sin utilizar herencia. Esto se basa en el uso de agregacin a travs de clases intermediarias que ocultan la funcionalidad de las clases a las cuales se delega.

El encapuslamiento es muy efectivo para lograr el reuso, pudindose aplicar tanto al nivel de los objetos como de componentes desarrollados en otras aplicacines. Estos componentes pueden ser reutilizables como fueron diseados a simplemente agregando nuevas interfaces.ExtensibilidadLa mayora de los sistemas son extendidos en manera no prevista por el diseo original. Por lo tanto, los componentes reutilizables mejorarn tambin la extensibilidad. Las siguientes son algunas de las perspectivas de extensibilidad: Nuevamente, se debe encapsular clases, ocultando su estructura interna a las otras clases. Slo los mtodos de la clase deben accesar sus atributos.

No se debe exportar estructuras de datos desde un mtodo. Las estructuras de datos internas son especficas al algoritmo del mtodo. Si se exporta las estructuras se limita la flexibilidad para poder cambiar el algoritmo ms tarde.

Una clase debe tener un conocimiento limitado de la arquitectura de clases del sistema. Este conocimiento debe abarcar nicamente las asociaciones entre ella y sus vecinos directos. Para interactuar con un vecino indirecto, se debe llamar una operacin del objeto vecino para atravesar la siguiente relacin. Si la red de asociaciones cambia, el mtodo de la clase puede ser modificado sin cambiar la llamada.

Se debe evitar expresiones de casos(casestatements) sobre tipos de objetos. Para ello, se debe usar mtodos(polimorfismo)para seleccionar el comportamiento a ejecutarse basado en el tipo del objeto en lugar de expresiones decasos.El polimorfismo evita muchas de estas comparaciones de tipos.

Se debe distinguir entre operaciones privadas y pblicas. Cuando una operacin pblica es usada por otras clases, se vuelve costoso cambiar la interface, por lo cual las operaciones pblicas deben ser definidas con cuidado. Las operaciones privadas son internas a la clase y sirven nicamente de ayudan para implementar operaciones pblicas. Las operaciones privadas pueden ser removidas o su interface cambiada para modificar la implementacin de la clase, teniendo un impacto limitado en los dems mtodos de la clase.

8.2 Diseo de Sistema.

Durante el diseo de sistema se toman condiseraciones en base al ambiente de implementacin teniendo como objetivo lograr una buena rastreabilidad de la arquitectura de objetos al cdigo final. Estos objetos deben ser vistos como abstracciones del cdigo a ser escrito donde, por ejemplo, un tpico objeto sera representado por un archivo en el sistema, como es el caso de Java. En otros lenguajes, como C++, en lugar de un archivo se escriben dos, uno correspondiente a la interface del objeto y el otro a su implementacin. En general, el diseo de sistema incluye diversos aspectos como: Seleccin del lenguajes de programacin a utilizarse, tpicamente estructurados u orientados a objetos; Incorporacin de una base de datos, tpicamente relacionales, relacionales extendidos u orientados a objetos; Acceso a archivos, en sus diferentes formatos; Inclusin de bibliotecas, como por ejemplo, interfaces grficas (GUI), bibliotecas numricas y de estructuras de datos; Consideraciones de tiempo real, si las hay; Aspectos de procesamiento, como concurrencia, paralelismo y distribucin; Aspectos transaccionales, tpicamente en el acceso a bases de datos; Organizacin del sistema en subsistemas; Asignacin de subsistemas a componentes de hardware y software.Estos aspectos pueden variar radicalmente entre uno y otro sistema y tambin pueden afectar de gran manera la arquitectura resultante del sistema. En general existen diversos enfoques para la incorporacin del ambiente de implementacin a la arquitectura del sistema: Agregando clases abstractas o interfaces que luego sern especializadas segn el ambiente de implementacin particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programacin, como en el caso de Java, es comn a los diversos ambientes. Instanciando objetos especializados que administren los aspectos particulares del ambiente de implementacin particular. Esto puede significar una integracin parcial o completa de componentes adicionales a la arquitectura del sistema. Por ejemplo, una integracin con las interfaces nativas de Java (JNI) para manejo de aspectos de bajo nivel del ambiente.

Configurando mltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque ms flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes de programacin incluyendo diseos para lenguajes estructurados.En este captulo simplificaremos de gran manera el efecto del ambiente de implementacin. Utilizaremos a Java como lenguaje de programacin bajo un procesamiento secuencial y con interfaces grficas tambin escritas en Java. Para el Sistema de Reservaciones de Vuelos tambin incluiremos integracin con bases de datos y archivos externos, algo que ser manejador a travs de las clases interface.Interfaces GrficasLas interfaces grficas tienen como aspecto esencial que toda interaccin con el usuario es a travs de elementos grficos, como lo son los botones, mens y textos. En lo que se refiere a la aplicacin, todo sistema que interacte mediante interfaces grficas est dirigido poreventos.Estos eventos corresponden al movimiento del ratn, el oprimir o soltar uno de sus botones, el oprimir una tecla, junto con los que no son directamente iniciados por el usuario, como los eventos de desplegar una pantalla o interrumpir un programa.El desarrollar un sistema dirigido por eventos significa que la aplicacin debe desde un inicio considerar un diseo adecuado. Por ejemplo, en el caso de Java, se debe inicialmente escoger una de sus bibliotecas grficas, como AWT, para luego utilizar el manejo apropiado a travs de clases como Event.El uso de estas bibliotecas tambin afecta la lgica de diseo, ya que se debe contemplar, por ejemplo, en que momentos es apropiado procesar nuevos eventos y cmo se inicializar el sistema. Estas consideraciones y su efecto sobre el resto del sistema sern discutidas ms adelante durante el diseo de objetos.Bases de DatosEl aspecto de bases de datos siempre juega un papel fundamental en los sistemas de informacin. La decisin estratgica ms importante en nuestro contexto es si utilizar bases de datos relacionales o las orientadas a objetos. Dado su amplia utilizacin y la situacin actual en el mercado, escogeremos para nuestro desarrollo una base de datos relacional utilizando el lenguaje SQL estndar. Simplifcaremos al mximo el diseo de la base de datos para minimizar su efecto sobre el sistema completo. Ms bien, demostraremos como es posible disear buenas clases que permitan en un futuro cambiar de manejadores de bases de datos. 8.3 Diseo de Objetos

8.3 Diseo de Objetos.

ServiciosA partir de la Tabla 8.34 se generan las jerarquas para la claseManejadorServicio,como se muestra en la Tabla 8.53.Clase:ManejadorServicio

Mdulo:Servicios

Propiedades:Concreta

Estereotipo:Control

Superclase:Manejador

Subclase:

desplegarPaginaServicioInterfaceUsuario, PaginaServicio

obtenerRegUsuarioManejadorRegistroUsuario

Tabla 8.53. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones y jerarquas a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.A partir de la Tabla 8.35 se generan las jerarquas para la clasePaginaServicio,como se muestra en la Tabla 8.54.Clase:PaginaServicio

Mdulo:Servicio


Estereotipo:Interface

Superclase:Pagina

Subclase:

obtenerRegUsuarioManejadorServicio

Tabla 8.54. Tarjeta para la clase PaginaServicio con responsabilidades, colaboraciones y jerarquas a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.ContratosUn contrato es una mecanismo de diseo para agrupar las responsabilidades de una clase que tienen relaciones entre si, sirviendo como indicadores de los diversos servicios provistos por cada clase.El contrato es un elemento de abstraccin adicional en el manejo de la complejidad del diseo, ayudando en la asignacin y reasignacin de responsabilidades, donde grupos de responsabilidades funcionalmente relacionadas deben ser comunes a un mismo contrato. A diferencia de los contratos, las responsabilidades representan una visin ms detallada de los servicios provistos por la clase. El contrato no es simplemente otro nombre para responsabilidad, ya que la responsabilidad corresponde a una accin especfica, mientras que un contrato define un conjunto de responsabilidades cercanas una de la otra. Cada responsabilidad pueder ser parte de un slo contrato, aunque no tiene que ser necesariamente parte de algn contrato. Esto ocurre cuando las responsabilidades representan comportamiento que una clase debe tener, pero que son privadas a los propios objetos. En general, una clase puede apoyar uno o ms contratos, aunque a menudo una clase con varias responsabilidades apoya un slo contrato.Un contrato entre dos clases representa una lista de servicios que una instancia de una clase puede solicitar de una instancia de otra clase. Todos los servicios especificados en un contrato particular son la responsabilidad del servidor para ese contrato. Las responsabilidades correspondientes al contrato deben ser ofrecidas pblicamente. Por lo tanto, para un mejor manejo de la complejidad del sistema, se debe posponer la definicin de los aspecto privados de una clase y concentrrse inicialmente en las responsabilidades pblicas.En general, un contrato entre un cliente y un servidor no especifica cmo se hacen las cosas, solo qu se hace. Los contratos especifican quien colabora con quien, y qu se espera de la colaboracin. El contrato cliente-servidor divide los objetos en dos categora aquellos que proveen servicios (servidores), y aquellos que piden servicios (clientes). De tal manera, un contrato es una lista de pedidos que le hace un cliente a un servidor. Ambos deben satisfacer el contrato, el cliente haciendo slo los pedidos que el contrato especifica, y el servidor respondiendo apropiadamente a estos pedidos.Como se mencion anteriormente, cliente y servidor son roles que juegan los objetos en cierto momento y no caractersticas inherentes de los propios objetos. Un objeto puede tomar el rol de cliente o servidor en relacin a otros objetos. Por ejemplo, los componentes casi siempre juegan el rol de servidores, ya que satisfacen una responsabilidad especfica. Raramente los componentes necesitaran pedir servicios del propio sistema para poder satisfacer esas responsabilidades. Por el contrario, losmarcos (frameworks)generalmente toman ambos roles, ya que se integran a las aplicaciones para solicitar y proveer funcionalidad.Se puede determinar qu responsabilidades pertenecen a cuales contratos siguiendo ciertos criterios. Una forma de encontrar responsabilidades relacionadas es buscar responsabilidades que sern usadas por el mismo cliente. Aunque es posible que algunas clases den servicio a diferentes clientes mediante diversas responsabilidades, es ms significativo cuando dos o ms responsabilidades de una clase dan servicio a los mismos clientes. En tal caso sera innecesario definir distintos contratos. En su lugar, se puede abstraer de las responsabilidades especficas un slo contrato, satisfaciendo la responsabilidad general.Si una clase define un contrato que tiene relativamente poco en comn con el resto de los contratos definidos por esa clase, este contrato debe ser movido a una clase diferente, usualmente una superclase o subclase. De tal manera, se puede refinar las jerarquas de clases maximizando la cohesin de contratos para cada clase. Maximizando la cohesin tender a minimizar el nmero de contratos apoyados por cada clase. Esto es algo deseable, ya que cuanto menos contratos existan, se lograr un sistema ms fcil de comprender. En general, la mejor manera de reducir el nmero de contratos es buscar responsabilidades similares que puedan generalizarse. Esto tambin resultar en jerarquas de clases ms extensibles.Un buen diseo hace un balance entre clases pequeas con pocos contratos, fciles de comprender y reutilizar, con un nmero reducido de clases ms complejas cuyas relaciones entre ellas se puede comprender mas fcilmente. Una tcnica para definir contratos es comenzar definiendo primero los contratos de las clases ms arriba en las jerarquas. Posteriormente, se definen nuevos contratos para las subclases que agregan nueva funcionalidad. Se debe examinar las responsabilidades para cada subclase y determinar si estas representan nueva funcionalidad o si son simplemente maneras especficas de expresar responsabilidades heredadas, en cuyo caso seran parte del contrato heredado.En cada tarjeta de clase se divide la seccin de responsabilidades en dos. En la parte superior se especifica una seccin para los contratos, mientras que en la parte inferior se especifica una seccin para las responsabilidades privadas. Cada contrato debe incluir un nombre y un nmero de contrato. Se debe listar cada contrato para el cual esta clase es un servidor. Tambin se debe listar contratos heredados, e indicar la clase de la cual se heredan, aunque no hay necesidad de repetir los detalles del contrato. Para cada contrato, se debe listar las responsabilidades de la clase en la cual se basan, asignando cada responsabilidad al contrato correspondiente.Si la responsabilidad requiere colaborar con una clase que define varios contratos, se debe indicar el nmero del contrato correspondiente entre parntesis en la columna de la colaboracin, para as simplificar el seguimiento de qu responsabilidad se relaciona con qu contrato.En esta seccin se describen los contratos para elSistema de Reservaciones,en base a los casos de usoRegistrarUsuario, ValidarUsuarioyRegistrarTarjeta.InterfaceUsuarioA partir de la Tabla 8.36 se generan los contratos para la claseInterfaceUsuario,como se muestra en la Tabla 8.55.Clase:InterfaceUsuario

Mdulo:InterfaceUsuario



Superclase:

Subclase:

Contratos

1. Desplegar Pagina

desplegarPaginaPgina (1)

Responsablidades Privadas

inicializarManejadorPrincipal (2)

manejarEventoManejador (1)

informar

Tabla 8.55. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.37 se generan los contratos para laclase Pagina,como se muestra en la Tabla 8.56.Clase:Pagina


Propiedades:Abstracta

Estereotipo:

Superclase:

Subclase:PaginaPrincipal, PaginaServicio, PaginaRegUsuario, PaginaRegTarjeta

Contratos

1. Desplegar Pagina

desplegarPagina

Tabla 8.56. Tarjeta para la superclase clase Pagina con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.PrincipalA partir de la Tabla 8.38 se generan los contratos para la claseManejador,como se muestra en la Tabla 8.57.Clase:Manejador

Mdulo:Principal


Estereotipo:Control

Superclase:

Subclase:ManejadorPrincipal, ManejadorServicios, ManejadorRegistroUsuario, ManejadorRegistroTarjeta

Contratos

1. Manejar Evento

manejarEvento


desplegarPaginaInterfaceUsuario (1), Pagina (1)

Tabla 8.57. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.39 se generan los contratos para la claseManejadorPrincipal,como se muestra en la Tabla 8.58.Clase:ManejadorPrincipal

Mdulo:Principal


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Inicializar

inicializarPaginaPrincipal (1)


ofrecerServicioManejadorServicio (2)

crearRegUsuario ManejadorRegistroUsuario (2)ManejadorRegistroUsuario (3)

validarRegUsuarioManejadorRegistroUsuario (3)

desplegarPaginaPrincipalInterfaceUsuario (1), PaginaPrincipal (1)

Tabla 8.58. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.40 se generan los contratos para la clasePaginaPrincipal,como se muestra en la Tabla 8.59.Clase:PaginaPrincipal

Mdulo:Principal



Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pgina

desplegarPagina

Tabla 8.59. Tarjeta para la clase PaginaPrincipal con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.DominioA partir de la Tabla 8.41 se generan los contratos para la claseDatos,como se muestra en la Tabla 8.60.Clase:Datos

Mdulo:Dominio


Estereotipo:Entidad

Superclase:

Subclase:RegistroUsuario, RegistroTarjeta

Contratos

1. Actualizar y Consultar Informacin

Actualizar informacin

Consultar informacin

Tabla 8.60. Tarjeta para la clase Datos con responsabilidades, colaboraciones y jerarquas identificadas de las diversas clases entidad para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.RegistroEste mdulo se compone de los mdulos deUsuario, TarjetaeInterfaceBD.UsuarioEsta seccin involucra las clases de registro de usuario que sonManejadoRegistroUsuario, PaginaCrearRegUsuario, PaginaObtenerRegUsuarioyRegistroUsuario.A partir de la Tabla 8.42 se generan los contratos para la claseManejadoRegistroUsuario,como se muestra en la Tabla 8.61.Clase:ManejadorRegistroUsuario

Mdulo:Registro.Usuario


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Crear Registro

Usuario crear

3. Validar Registro Usuario

validarRegistroUsuario (1), InterfaceBaseDatosRegistro (2)

4. Obtener Registro Usuario

obtener

Responsabilidades Privadas

escribirRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

leerRegistroUsuario (1), InterfaceBaseDatosRegistro (1) eliminar RegistroUsuario (1), InterfaceBaseDatosRegistro (1)

crearRegTarjetaManejadorRegistroTarjeta (2), RegistroTarjeta (1)

desplegarPaginaCrearRegUsuarioInterfaceUsuario (1), PaginaCrearRegUsuario (1)

desplegarPaginaObtenerRegUsuarioInterfaceUsuario (1), PaginaObtenerRegUsuario (1)

Tabla 8.61. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.A partir de la Tabla 8.43 se generan los contratos para la clasePaginaRegUsuario,como se muestra en la Tabla 8.62.Clase:PaginaRegUsuario




Superclase:Pagina

Subclase:PaginaCrearRegUsuario, PaginaObtenerRegUsuario

Contratos

1. Desplegar Pagina

desplegarRegistroUsuario (1)

Tabla 8.62. Tarjeta para la clase PaginaRegUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarUsuario.A partir de la Tabla 8.44 se generan los contratos para la clasePaginaCrearRegUsuario,como se muestra en la Tabla 8.63.Clase:PaginaCrearRegUsuario




Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pagina


Tabla 8.63. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarUsuario.A partir de la Tabla 8.45 se generan los contratos para la clasePaginaObtenerRegUsuario,como se muestra en la Tabla 8.64.Clase:PaginaObtenerRegUsuario




Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pagina


Tabla 8.64. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarUsuario.A partir de la Tabla 8.46 se generan los contratos para la claseRegistroUsuario,como se muestra en la Tabla 8.65.Clase:RegistroUsuario



Estereotipo:Entidad

Superclase:Datos

Subclase:

Contratos




Tabla 8.65. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas y contratos de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario.TarjetaEsta seccin involucra las clases de registro de tarjeta que sonManejadoRegistroTarjeta, PaginaCrearRegTarjeta, PaginaObtenerRegTarjetayRegistroTarjeta.A partir de la Tabla 8.47 se generan los contratos para la claseManejadoRegistroTarjeta,como se muestra en la Tabla 8.66.Clase:ManejadorRegistroTarjeta

Mdulo:Registro.Tarjeta


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Crear Registro Tarjeta

crear

3. Obtener Registro Tarjeta

obtener


escribirRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

leerRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

actualizarRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

eliminarRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

desplegarPaginaCrearRegTarjetaInterfaceUsuario (1), PaginaCrearRegTarjeta (1)

desplegarPaginaObtenerRegTarjetaInterfaceUsuario (1), PaginaObtenerRegTarjeta (1)

Tabla 8.66. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta.A partir de la Tabla 8.48 se generan los contratos para la clasePaginaRegTarjeta,como se muestra en la Tabla 8.67.Clase:PaginaRegTarjeta

Mdulo:Registro. Tarjeta



Superclase:Pagina

Subclase:PaginaCrearRegTarjeta, PaginaObtenerRegTarjeta

Contratos

1. Desplegar Pagina

desplegarPaginaRegistroTarjeta (1)

Tabla 8.67. Tarjeta para la clase PaginaRegTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta.A partir de la Tabla 8.49 se generan los contratos para la clasePaginaCrearRegTarjeta,como se muestra en la Tabla 8.68.Clase:PaginaCrearRegTarjeta




Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pagina


Tabla 8.68. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta.A partir de la Tabla 8.50 se generan los contratos para la clasePaginaObtenerRegTarjeta,como se muestra en la Tabla 8.69.vClase:PaginaObtenerRegTarjeta




Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pagina


Tabla 8.69. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta.A partir de la Tabla 8.51 se generan los contratos para la claseRegistroTarjeta,como se muestra en la Tabla 8.70.Clase:RegistroTarjeta



Estereotipo:Entidad

Superclase:Datos

Subclase:

Contratos




Tabla 8.70. Tarjeta para la clase RegistroTarjeta con responsabilidades, colaboraciones, jerarquas y contratos de actualizar y consultar informacin de registro para el caso de uso RegistrarTarjeta.Interface Base DatosA partir de la Tabla 8.52 se generan los contratos para la claseInterfaceBaseDatosRegistro,como se muestra en la Tabla 8.71Clase:InterfaceBaseDatosRegistro

Mdulo:Registro.InterfaceDB



Superclase:

Subclase:

Contratos

1. Registrar Usuario

leerRegistroUsuario (1), BaseDatosRegistro

escribirRegistroUsuario (1), BaseDatosRegistro

actualizarRegistroUsuario (1), BaseDatosRegistro

eliminarRegistroUsuario (1), BaseDatosRegistro


validarRegistroUsuario (1), BaseDatosRegistro

3. Regitrar Tarjeta Usuario

leerRegistroTarjeta (1), BaseDatosRegistro

escribirRegistroTarjeta (1), BaseDatosRegistro

actualizarRegistroTarjeta (1), BaseDatosRegistro

eliminarRegistroTarjeta (1), BaseDatosRegistro

Tabla 8.71. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones, jerarquas y contratos de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.ServiciosA partir de la Tabla 8.53 se generan los contratos para la claseManejadorServicio,como se muestra en la Tabla 8.72.Clase:ManejadorServicios

Mdulo:Servicios


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Inicializar ofrecerServicio

ofrecerServicio


obtenerRegUsuarioManejadorRegistroUsuario (4) )

desplegarPaginaServicioInterfaceUsuario (1), PaginaServicio (1

Tabla 8.72. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas y contratos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.A partir de la Tabla 8.54 se generan los contratos para la clasePaginaServicio,como se muestra en la Tabla 8.73.Clase:PaginaServicio

Mdulo:Servicios



Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pgina

desplegarPagina

Tabla 8.73. Tarjeta para la clase PaginaServicio con responsabilidades, colaboraciones, jerarquas y contratos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.SubsistemasComo se puede apreciar en lo que hemos hecho hasta ahora en el diseo, la complejidad del sistema aumenta a medidad que se incorporan nuevos detalles. Para lograr un mejor manejo de esta complejidad introducimos el concepto desubsistemas, el cual permite dividir el sistema completo en diversas partes siguiendo la frase de divide y conquista.Los subsistemas organizan grupos de objetos dentro de la arquitectura de diseo en mini-sistemas, apoyando una visin jerrquica del sistema mediante mltiples niveles de abstracin, donde el sistema completo se compone de mltiples subsistemas y donde cada subsistema puede ser subdivido en subsistemas adicionales o ser definido en trminos de los objetos finales.La organizacin en subsistemas se hace a partir de las colaboraciones identificadas entre los objetos para apoyar el conjuntos de contratos del sistema completo. Externamente, los subsistemas son mecanismos de encapsulamiento, vistos como cajas negras, donde sus objetos cooperan para proveer una unidad de funcionalidad claramente delimitada por el subsistema. Internamente, los subsistemas revelan tener estructuras complejas, con clases colaborando entre si para satisfacer sus distintas responsabilidades contribuyendo al objetivo general del subsistema, o sea, satisfacer sus responsabilidades.El objetivo es lograr un fuerte acoplamiento funcional dentro del subsistema y un dbil acoplamiento entre subsistemas, en otras palabras, debe haber el mnimo posible de comunicacin entre los diferentes subsistemas.Un subsistema bien diseado tiene pocas clases o subsistemas que directamente apoyan contratos, y un nmero mayor de colaboraciones entre clases internas y subsistemas.Es importante distinguir entre el concepto demduloysubsistema. Un mdulo agrupa clases, correspondiente abibliotecas, o sea, organizaciones definidas para almacenar y facilitar el acceso a las clases. Esto es similar al concepto dedirectoriosen una computadora. Son estructuras completamente estticas, sin ningn efecto durante la ejecucin del sistema. Por otro lado, el subsistema agrupa objetos, siendo una abstraccin dinmica ya que los objetos que se ejecutan dentro de un subsistema son instancias de clases que deben existir forzosamente en un mdulo.El criterio ms importante para la divisin en subsistemas es predecir como afectarn los cambios en el sistema. Los subsistemas debern mantener una buena correspondencia con los casos de uso, de manera que cualquier cambios causado por modificaciones en la funcionalidad del sistema pueda ser rastreado a los subsistemas afectados. Esto se hace siguiendo los casos de uso en orden de importancia.Cabe resaltar, que los subsistemas no existen durante la ejecucin de la aplicacin, son puramente conceptuales, obviamente afectando el diseo del sistema. Sin embargo, es comn definir mdulos con clases que sern utilizadas por ciertos subsistemas particulares, como son las clases de control y por lo general las de interface. Sin embargo, las clases entidad tienden a ser utilziadas por mltiples subsistemas.Si consideramos que la mayor complejidad en el diseo radica en las relaciones entre objetos (a travs de sus colaboraciones), la meta es reducir o al menos manejar de mejor manera estas relaciones. Un enfoque es definir los subsistemas de manera que, aunque el nmero total de relaciones sea el mismo, las relaciones estarn organizadas pro grupos(clusters).Si se observan que cierto grupo de objetos estn muy relacionados entre si pero no tanto con otro grupo de objetos, esto sirve de base para la organizacin de los subsistemas y la reduccin de la complejidad. Por otro lado, gracias a los subsistemas, se puede trabajar en diferentes partes del sistema en paralelo mediante su asignacin a mltiples diseadores.Como parte de la identificacin de subsistemas, se define un protocolo de comunicacin para cada subsistema, el cual restringe las posibles interacciones entre subsistemas. Esto se logra exportando o haciendo pblicos slo ciertos objetos del subsistema. La interface de estos objetos, sus servicios, definen la interface del subsistema completo. Como unidades de encapsulamiento, si se incluyen, los subsistemas deben incluir completos o no ser incluidos, de manera que un sistema pueda ser ofrecido con o sin ciertos subsistemas. Dada la dependencia entre subsistemas, si se incluye un subsistema, se debe tambin entregar el subsistema del cual depende.Los subsistemas, al igual que clases, apoyan contratos. Para determinar los contratos apoyados por un subsistema, se tiene que encontrar todas las clases que proveen servicios a clientes fuera del subsistema. Al menos inicialmente, estos servicios correspondern a los contratos apoyados por el subsistema. Al igual que se hizo para las clases, se debe describir los contratos ofrecidos por cada subsistema. Dado que los subsistemas son solamente entidades conceptuales, estos no pueden directamente satisfacer ninguno de sus contratos. En su lugar, los subsistemas delegan cada contrato a una clase interna que lo satisface.La divisin de subsistemas es normalmente hecha al final del anlisis, cuando est clara la arquitectura. En proyectos grandes a menudo se debe hacer esto temprano, incluso antes de que se haya desarrollado el modelo de anlisis. En general existen mltiples criterios para la divisin de subsistemas, por ejemplo, diferentes grupos de desarrollo tienen diferente competencia o recursos y puede ser deseable distribuir el trabajo de manera correspondiente o los grupos tambin pueden estar geogrficamente separados. Cabe resaltar que un componente externo al sistema puede ser considerado como un subsistema.Las guas bsicas para simplificar los patrones de colaboracin son los siguientes: Minimizar el nmero de colaboraciones que una clase tiene con otras clases o subsistemas. Las clases deben colaborar con el menor nmero posible de clases y subsistemas. Menor nmero de colaboraciones significa que la clase tiene menor probabilidad de ser afectadas por cambios en el resto del sistema. Se puede reasignar responsabilidades o expandir el conocimiento de otra clase para crear un menor nmero de colaboraciones. Una forma para lograr esto es centralizar las comunicaciones fluyendo a un subsistema. Se puede crear una nueva clase en el subsistema para ser el intermediario principal, o utilizando una ya existente. Minimizar el nmero de clases y subsistemas a los cuales un subsistema delega. En un sistema bien diseado, el nmero de clases o subsistemas que tienen contratos delegados a ellos debe mantenerse en el mnimo. Esto va de la mano con la idea de centralizar las comunicaciones, ya que si una clase o subsistema sirve como el intermediario de comunicacin para un subsistema, los contratos son delegados solamente al intermediario. Minimizar el nmero de contratos diferentes apoyados por una clase o subsistema. Demasiados contratos para un subsistema puede ser un signo que demasiada inteligencia de la aplicacin se concentra en el subsistema.Tarjetas de SubsistemasLos subsistemas se describen en tarjetas de subsistemas, un subsistema por tarjeta. Cada tarjeta incluye un nombre en la primera lnea y dos columnas, como se puede ver en la Tabla 8.74.Subsistema:Nombre del Subsistema

Tabla 8.74. Tarjeta para subsistemas.En la columna izquiera se muestran los contratos que se ofrecen externos al subsistema, mientras que en la columna derecha, al lado de cada contrato se escribe la clase interna que ofrece el servicio, en otras palabras, a quien se le delega el contrato. Por ejemplo, en la Tabla 8.75 se muestra el diseo inicial para el subsistema InterfaceUsuario.Subsistema:Subsistema InterfaceUsuario

1. ManejarEventoInterfaceUsuario (1)

Tabla 8.75. Tarjeta para el subsistema InterfaceUsuario.Al incluir los subsistemas es necesario modificar las tarjetas de clase para hacer referencias a estos subsistemas y no a las clases que stas encapsulan. Si una clase externa a un subsistema colabora con una clase dentro de un subsistema, se debe cambiar esto a una colaboracin con el subsistema.Diagramas de ColaboracinPara analizar mejor el efecto de los subsistemas se utilizan los diagramas de colaboracin donde se despliega las colaboraciones entre clases y subsistemas de forma grfica.Como se ha visto, los responsabilidades de una clase se ofrecen como contratos de una clase servidor. Los contratos se muestran como crculos externos a la clase a la cual pertenecen relacionada con la clase mediante una liga de realizacin de interface, como se muestra en la Figura 8.6.

Figura 8.6 Diagrama de clase con contrato.Se dibuja un crculo por contrato y se numeran los crculos con el nmero asignado al contrato correspondiente. Las colaboraciones entre clases se representan por una flecha correspondiente a una asociacin deutilizacin del clienteal contrato apoyado por el servidor, como se muestra en la Figura 8.7 (la flecha de la derecha proveniente de Clase 2).

Figura 8.7 Diagrama de colaboracin donde Clase 2 es cliente del Contrato 1 de Clase 1.Si dos clases colaboran con un mismo contrato de otra clase, se dibuja las flechas al mismo crculo. Por el contrario, se dibujan las flechas a crculos distintos correspondientes a diferentes contratos. Los diagramas de colaboracin para aplicaciones moderadamente grandes pueden volverse grandes y complejas. Por lo tanto, se puede ocultar informacin para simplificarlos ligeramente. Los subsistemas se muestran en el diagrama de colaboracin dibujando rectngulos envolviendo las clases y contratos que las forman, como se ve en la Figura 8.8.

Figura 8.8 Diagrama de subsistema encapsulando clases y contratos.El problema de la complejidad es evidente cuando uno se fija en el diagrama de colaboracin. El diagrama se vuelve un espagueti. No se puede entender fcilmente y la aplicacin se vuelve imposible de mantener o modificar. Por lo tanto la meta es simplificar los patrones de colaboracin.Ntese que simplificando los patrones de colaboracin se traduce en la simplificacin del diagrama de colaboracin.Subsistema de Reservaciones de VueloA continuacin se describen los subsistemas para elSistema de Reservaciones,en base a los casos de usoRegistrarUsuario, ValidarUsuarioyRegistrarTarjeta. En la Figura 8.9 se muestra los tres subsistemas ms importantes y de ms alto nivel en el sistema de reservaciones:SubsistemaRegistro, SubsistemaServicios y SubsistemaInterfaceUsuario.

Figura 8.9 Subsistemas del sistema de reservaciones de vuelos.Estos subsistemas sern descritos con mayor detalle a continuacin.InterfaceUsuarioElSubsistemaInterfaceUsuariose muestra en la Tabla 8.76. Este subsistema se compone principalmente de la claseInterfaceUsuarioque a su vez sirve de servidor para el subsistema.Subsistema:InterfaceUsuario

Clases:InterfaceUsuario

ContratosServidor

1. Desplegar PaginaInterfaceUsuario (1)

Tabla 8.76. Tarjeta de subsistema para SubsistemaInterfaceUsuario mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.ElSubsistemaInterfaceUsuariose muestra grficamente en la Figura 8.10. Ntese como los contratos se muestran comobolitas,el ms cercano a la claseInterfaceUsuariocorresponde al contrato de esa misma clase, mientras que el que aparece en el borde del subsistema es el correspondiente al propio subsistema.

Figura 8.10 Subsistema de interface de usuario.RegistroElSubsistemaRegistrose muestra en la Tabla 8.77. Este subsistema se compone de las diversas clases de los mdulos deRegistro(Usuario, Tarjeta e InterfaceBD).Subsistema:Registro

Clase:ManejadorRegistroUsuario, PaginaCrearRegUsuario, PaginaObtenerRegUsuario, RegistroUsuario, ManejadorRegistroTarjeta, PaginaCrearRegTarjeta, PaginaObtenerRegTarjeta, RegistroTarjeta, InterfaceBaseDatosRegistro

ContratosServidor

1. Manejar EventoManejadorRegistroUsuario (1), ManejadorRegistroTarjeta (1)

2. Crear Registro UsuarioManejadorRegistroUsuario (2)

3. Validar Registro UsuarioManejadorRegistroUsuario (3)

4. Obtener Registro UsuarioManejadorRegistroUsuario (4)

5. Obtener Registro TarjetaManejadorRegistroTarjeta (3)

Tabla 8.77. Tarjeta de subsistema para SubsistemaRegistro mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.ElSubsistemaRegistrose muestra grficamente en la Figura 8.11. Ntese nuevamente como los contratos se muestran comobolitas,mostrando las ligas correspondientes entre el subsistema y los dos servidores.

Figura 8.11 Subsistema de registro.ServiciosElSubsistemaServiciosse muestra en la Tabla 8.78. Este subsistema se compone principalmente de la claseManejadorServicios.Ntese que el resto de los contratos y servidores del subsistema de servicios para el resto de su funcionalidad se muestran en el apndice.Subsistema:Servicios

Clase:ManejadorServicios, PaginaServicio

ContratosServidor

1. Manejar EventoManejadorServicios (1)

2. InicializarManejadorServicios (2)

Tabla 8.78. Tarjeta de subsistema para SubsistemaServicios mostrando sus contratos y servidores a partir del caso de uso RegistrarUsuario.ElSubsistemaServiciose muestra grficamente en la Figura 8.12. Ntese nuevamente como los contratos se muestran comobolitas,mostrando las ligas correspondientes entre el subsistema y el servidor.

Figura 8.12 Subsistema de servicios.PrincipalElsistema principalse muestra grficamente en la Figura 8.13. Este sistema integra los subsistemas anteriores adems de la claseManejadorPrincipal,mostrando las diferentes ligas entre los distintos elementos.Ntese nuevamente como los contratos se muestran comobolitas,mostrando las ligas correspondientes entre subsistemas y servidores.

Figura 8.13 Subsistemas del sistema de reservaciones de vuelo. Mdulos de Reservaciones de VueloEn esta seccin se muestra como los subsistemas afectan a los diversos mdulos descritos anteriormente. A continuacin se describen las clases principales de los distintos mdulos segn la organizacin de subsistemas para elSistema de Reservacionesy en base a los casos de usoRegistrarUsuario, ValidarUsuarioyRegistrarTarjeta.InterfaceUsuarioLa claseInterfaceUsuariose muestra en la Tabla 8.79. En este caso es idntica a la mostrada en la Tabla 8.54.Clase:InterfaceUsuario




Superclase:

Subclase:

Contratos

1. Desplegar Pagina

desplegarPaginaPgina (1)


inicializarManejadorPrincipal (2)

envarEventoManejador (1)

informar

Tabla 8.79. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La descripcin de la clase Pagina se mantiene igual.PrincipalA partir de la Tabla 8.55 se actualizan los contratos segn subsistemas para la claseManejador,como se muestra en la Tabla 8.80.Clase:Manejador

Mdulo:Principal


Estereotipo:Control

Superclase:

Subclase:ManejadorPrincipal, ManejadorServicios, ManejadorRegistroUsuario, ManejadorRegistroTarjeta

Contratos

1. Manejar Evento

manejarEvento


desplegarPaginaSubsistemasInterfaceUsuario (1), Pagina (1)

Tabla 8.80. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.57 se actualizan los contratos segn subsistemas para la claseManejadorPrincipal, como se muestra en la Tabla 8.81.Clase:ManejadorPrincipal

Mdulo:Principal


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Inicializar

inicializarPaginaPrincipal (1)


ofrecerServicioSubsistemaServicio (2)

crearRegUsuarioSubsistemaRegistro (2)

validarRegUsuarioSubsistemaRegistro (3)

desplegarPaginaPrincipalSubsistemaInterfaceUsuario (1), PaginaPrincipal (1)

Tabla 8.81. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La descripcin de la clase PaginaPrincipal se mantiene igual.DominioLa descripcin de la claseDatosse mantiene igual.RegistroEn el mdulo deRegistro,compuesto de los mdulosUsuario, TarjetaeInterfaceBD,slo se modifican las clases de control pero no las de interface o entidad, como se ver a continuacin.UsuarioA partir de la Tabla 8.60 se actualizan los contratos segn subsistemas para la claseManejadoRegistroUsuario,como se muestra en la Tabla 8.82.Clase:ManejadorRegistroUsuario



Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Crear Registro Usuario

crear


validarRegistroUsuario (1), InterfaceBaseDatosRegistro (2)


obtener


escribirRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

leerRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

eliminarRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

crearRegTarjetaManejadorRegistroTarjeta (2), RegistroTarjeta (1)

desplegarPaginaCrearRegUsuarioSubsistemaInterfaceUsuario (1), PaginaCrearRegUsuario (1)

desplegarPaginaObtenerRegUsuarioSubsistemaInterfaceUsuario (1), PaginaObtenerRegUsuario (1)

Tabla 8.82. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificadas de los casos de uso RegistrarUsuario y ValidarUsuario. La descripcin de las clases PaginaRegUsuario, PaginaCrearRegUsuario, PaginaObtenerRegUsuario y RegistroUsuario se mantienen igual.TarjetaA partir de la Tabla 8.65 se generan los contratos para la claseManejadoRegistroTarjeta,como se muestra en la Tabla 8.83.Clase:ManejadorRegistroUsuario



Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento


crear


obtener


escribirRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

leerRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

actualizarRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

eliminarRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

desplegarPaginaCrearRegTarjetaSubsistemaInterfaceUsuario (1), PaginaCrearRegTarjeta (1)

desplegarPaginaObtenerRegTarjetaSubsistemaInterfaceUsuario (1), PaginaObtenerRegTarjeta (1)

Tabla 8.83. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificadas del caso de uso RegistrarTarjeta.La descripcin de las clasesPaginaRegTarjeta, PaginaCrearRegTarjeta, PaginaObtenerRegTarjetayRegistroTarjetase mantienen igual.Interface Base Datos RegistroLa descripcin de la claseInterfaceBaseDatosRegistrose mantiene igual.ServiciosA partir de la Tabla 8.71 se actualizan los contratos segn subsistemas para la claseManejadorServicios,como se muestra en la Tabla 8.84.Clase:ManejadorServicios

Mdulo:Servicios


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento

manejarEvento

2. Inicializar

ofrecerServicio


obtenerRegUsuarioSubsistemaRegistro (4)

desplegarPaginaServicioSubsistemaInterfaceUsuario (1), PaginaServicio (1)

Tabla 8.84. Tarjeta para la clase ManejadorServicios con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.La descripcin de la clasePaginaServiciose mantiene igual.ProtocolosUna vez completadas las etapas anteriores, se debe detallar la especificacin de cada clase para poder derivar la implementacin final. Esto se hace extendiendo las responsabilidades y los contratos de las clases en protocolos, donde unprotocolocorresponde a el conjunto de firmas para las distintas responsabilidades de una clase. El objetivo de los protocolos es refinar las responsabilidades en mtodos precisos dando especial nfasis en los contratos ofrecidos por las clases correspondientes a sus responsabilidades pblicas.En general, responsabilidades privadas representan notas de implementacin a un programador y no deben sobre-especificarse. Sin embargo, en algunos casos se debe generar protocolos para responsabilidades privadas. Por ejemplo, si una superclase abstracta ser implementada por un programador y sus subclases implementadas por otro, las responsabilidades privadas usadas por sus subclases deben especificarse completamente. Es tambin importante seleccionar cuidadosamente los nombres de los mtodos.Durante esta etapa es comn descubrir sitios en el diseo donde el modelo fue impreciso, incorrecto, o pobremente comprendido. Especificando protocolos ayuda a corregir tales situaciones. Por lo tanto, puede que sea necesario tener que repetir etapas anteriores del proceso de diseo antes de poder completar las definiciones de clases y contratos.En general, se incrementa la reutilizacin si se tiene slo uno pocos parmetros, simplificando su comprensin e incrementando la probabilidad de descubrir nuevas bases para la herencia. Se debe escoger los nombres con cuidado, siguiendo un patrn uniforme en el momento de asignar estos nombres.Sistema de Reservaciones con ProtocolosA continaucin se muestra como los subsistemas afectan a los diversos mdulos descritos anteriormente. A continuacin se describen las clases principales de los distintos mdulos segn la organizacin de subsistemas para el Sistema de Reservaciones y en base a los casos de uso RegistrarUsuario, ValidarUsuarioyRegistrarTarjeta.InterfaceUsuarioLa claseInterfaceUsuariose muestra en la Tabla 8.85.Clase:InterfaceUsuario




Superclase:

Subclase:

Contratos

1. Desplegar Pagina

desplegarPagina(Pagina) devuelve voidPgina (1)


InterfaceUsuario()ManejadorPrincipal (2)

actionPerformed(Evento) devuelve voidManejador (1)

Tabla 8.85. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.80 se generan los contratos para la clasePagina, como se muestra en la Tabla 8.86.Clase:Pagina



Estereotipo:

Superclase:

Subclase:PaginaPrincipal, PaginaServicio, PaginaRegUsuario, PaginaRegTarjeta

Contratos

1. Desplegar Pgina

desplegarPagina(InterfaceUsuario) devuelve void

Tabla 8.86. Tarjeta para la superclase clase Pagina con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.PrincipalA partir de la Tabla 8.81 se actualizan los contratos segn protocolos para la claseManejador,como se muestra en la Tabla 8.87.Clase:Manejador

Mdulo:Principal


Estereotipo:Control

Superclase:ManejadorPrincipal, ManejadorServicios, ManejadorRegistroUsuario, ManejadorRegistroTarjeta

Subclase:

Contratos

1. Manejar Evento

manejarEvento(Evento) devuelve void


desplegarPagina(Pagina)devuelve void SubsistemasInterfaceUsuario (1), Pagina (1)

Tabla 8.87. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.82 se actualizan los contratos segn protocolos para la claseManejadorPrincipal,como se muestra en la Tabla 8.88.Clase:ManejadorPrincipal

Mdulo:Principal


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento


2. Inicializar

ejecutarTransaccionInicializar() devuelve voidPaginaPrincipal (1)


ejecutarTransaccionServicio(ManejadorRegistro) devuelve voidSubsistemaServicio (2)

ejecutarTransaccionCrearRegistroUsuario() devuelve voidSubsistemaRegistro (3)

ejecutarTransaccionValidarRegistro(String,String) devuelve voidSubsistemaRegistro (3)

desplegarPagina(PaginaPrincipal) devuelve voidSubsistemaInterfaceUsuario (1), PaginaPrincipal (1)

Tabla 8.88. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.A partir de la Tabla 8.83 se generan los protocolos para la clasePaginaPrincipal,como se muestra en la Tabla 8.89.Clase:PaginaPrincipal

Mdulo:Principal



Superclase:Pagina

Subclase:

Contratos

1. Desplegar Pgina

desplegarPagina se hereda

Tabla 8.89. Tarjeta para la clase PaginaPrincipal con responsabilidades, colaboraciones, jerarquas contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.DominioA partir de la Tabla 8.84 se generan los protocolos para la claseDatos,como se muestra en la Tabla 8.90.Clase:Datos

Mdulo:Dominio


Estereotipo:Entidad

Superclase:

Subclase:RegistroUsuario, RegistroTarjeta

Contratos


setElementAt

elementAt

Tabla 8.90. Tarjeta para la clase Datos con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de las diversas clases entidad para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.RegistroEn el mdulo deRegistro,compuesto de los mdulosUsuario, TarjetaeInterfaceBD, slo se modifican las clases de control pero no las de interface o entidad, como se ver a continuacin.UsuarioA partir de la Tabla 8.60 se actualizan los contratos segn protocolos para la claseManejadoRegistroUsuario, como se muestra en la Tabla 8.91.Clase:ManejadorRegistroUsuario



Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento


2. Crear Registro Usuario

ejecutarTransaccionCrear(Pagina) devuelve void


ejecutarTransaccionValidarRegistro(String,String) devuelve BooleanRegistroUsuario (1), InterfaceBaseDatosRegistro (2)


ejecutarTransaccionObtener(Pagina) devuelve void


ejecutarTransaccionEscribir() devuelve voidRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

ejecutarTransaccionLeer() devuelve voidRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

ejecutarTransaccionEliminar() devuelve voidRegistroUsuario (1), InterfaceBaseDatosRegistro (1)

crearRegistroTarjeta() devuelve RegistroTarjetaManejadorRegistroTarjeta (2), RegistroTarjeta (1)

desplegarPagina(PaginaCrearRegUsuario) devuelve voidSubsistemaInterfaceUsuario (1), PaginaCrearRegUsuario (1)

desplegarPagina(PaginaObtenerRegUsuario) devuelve voidSubsistemaInterfaceUsuario (1), PaginaObtenerRegUsuario (1)

Tabla 8.91. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.La descripcin de las clasesPaginaRegUsuario, PaginaCrearRegUsuarioyPaginaObtenerRegUsuarioy se actualizan de manera similar a laPaginaPrincipal.A partir de la Tabla 8.46 se generan los protocolos para la claseRegistroUsuario, como se muestra en la Tabla 8.92.Clase:RegistroUsuario



Estereotipo:Entidad

Superclase:Datos

Subclase:

Contratos


setElementAt se hereda

elementAtse hereda

Tabla 8.92. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario.TarjetaA partir de la Tabla 8.65 se generan los protocolos para la claseManejadoRegistroTarjeta, como se muestra en la Tabla 8.93.Clase:ManejadorRegistroTarjeta



Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento



ejecutarTransaccionCrear(Pagina) devuelve void


ejecutarTransaccionObtener(Pagina) devuelve void


ejecutarTransaccionEscribir() devuelve voidRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

ejecutarTransaccionLeer() devuelve voidRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

ejecutarTransaccionActualizar() devuelve voidRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

ejecutarTransaccionEliminar() devuelve voidRegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

desplegarPagina(PaginaCrearRegTarjeta) devuelve voidSubsistemaInterfaceUsuario (1), PaginaCrearRegTarjeta (1)

desplegarPagina(PaginaObtenerRegTarjeta) devuelve voidSubsistemaInterfaceUsuario (1), PaginaObtenerRegTarjeta (1)

Tabla 8.93. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas del caso de uso RegistrarTarjeta.La descripcin de las clasesPaginaRegTarjeta, PaginaCrearRegTarjetayPaginaObtenerRegTarjetase actualizan de manera similar a laPaginaPrincipal.Por otro lado,RegistroTarjetase actualiza de manera similar aRegistroUsuario.Interface Base Datos RegistroA partir de la Tabla 8.52 se generan los protocolos para la claseInterfaceBaseDatosRegistro, como se muestra en la Tabla 8.94.Clase:InterfaceBaseDatosRegistro

Mdulo:Registro.InterfaceDB



Superclase:

Subclase:

Contratos

1. Registrar Usuario

leerRegistro(RegistroUsuario) devuelve voidRegistroUsuario (1), BaseDatosRegistro

escribirRegistro(RegistroUsuario) devuelve voidRegistroUsuario (1), BaseDatosRegistro

eliminarRegistro(RegistroUsuario) devuelve voidRegistroUsuario (1), BaseDatosRegistro


validarRegistro(RegistroUsuario, String, String) devuelve booleanRegistroUsuario (1), BaseDatosRegistro

3. Regitrar Tarjeta Usuario

leerRegistro(RegistroTarjeta) devuelve voidRegistroTarjeta (1), BaseDatosRegistro

escribirRegistro(RegistroTarjeta) devuelve voidRegistroTarjeta (1), BaseDatosRegistro

eliminarRegistro(RegistroTarjeta) devuelve voidRegistroTarjeta (1), BaseDatosRegistro

Tabla 8.94. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones, jerarquas, contratos y protocolos de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.ServiciosA partir de la Tabla 8.71 se actualizan los contratos segn protocolos para la claseManejadorServicios,como se muestra en la Tabla 8.95.Clase:ManejadorServicios

Mdulo:Servicios


Estereotipo:Control


Subclase:

Contratos

1. Manejar Evento


2. Inicializar

ejecutarTransaccionInicializar(Pagina) devuelve void


ejecutarTransaccionRegistrar() devuelve voidSubsistemaRegistro (4)

ejecutarTransaccionConsultar() devuelve voidSubsistemaConsultas (2)

ejecutarTransaccionReservar() devuelvevoid SubsistemaReservas (2)

desplegarPagina(PaginaServicio) devuelve voidSubsistemaInterfaceUsuario (1), PaginaServicio (1)

Tabla 8.83. Tarjeta para la clase ManejadorServicios con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.La descripcin de la clase PaginaServicio se mantiene de manera similar a las dems pginas.Diagramas de SecuenciaHasta el momento se ha refinado la descripcin de las clases involucradas en el diseo de objetos de manera esttica. Sin embargo y al igual que durante el anlisis, es muy dificil apreciar la lgica del diseo sin mostrar los aspectos dinmicos de ella. Con tal motivo se vuelve a utilizar los diagramas de secuencias, slo que esta vez a partir de los protocolos de clases anteriormente definidos.Los diagramas de secuencia pueden generarse a partir de las propias clases o incluso a partir de la interaccin entre subsistemas. Esto es a menudo una tcnica muy til ya que se puede disear un subsistema mostrando slo las interfaces de los subsistemas relacionados. A un nivel ms detallado se pueden mostrar las interacciones internas del subsistema entre los propios objetos. Normalmente, los eventos en el diagrama corresponden a protocolos y se especifican exactamente como se veran en el cdigo final.El control en los diagramas de secuencia se disean de dos formas fundamentalmente diferentes, como se muestra en la Figura 8.14.

Figura 8.14 Diagrama de secuencias mostrando del lado izquierdo un ejemplo de control centralizado y del lado derecho control decentralizado.Un enfoque es el diagrama debifurcacin,donde el control escentralizado.Se caracteriza por el hecho de que un objeto controla el flujo y opera sobre los dems objetos. Mucho del comportamiento se pone en el objeto que controla el cual conoce a todos los otros objetos y a menudo los llama directamente, como es generalmente el objeto de control. Los otros objetos se usan tpicamente para informacin o como interface de usuario. Una estructura de bifurcacin a menudo pone mucha responsabilidad en el diseador del objeto controlador, ya que el objeto de control a menudo se vuelve mucho ms complejo que los dems objetos.El otro enfoque es el diagrama deescalera,donde el control esdecentralizado.Se caracteriza por la delegacin de responsabilidades donde el control se distribuye entre los diferentes objetos. Cada objeto solo conoce a unos pocos objetos aunque conoce qu objetos pueden ayudarlo con un comportamiento especfico, sin haber un objeto central. Cada objeto tiene una tarea separada y slo conoce a los objetos alrededor de los cuales necesita ayuda para poder llevar a cabo su tarea. A menudo se dice que la estructura de escalera es mas orientada a objetos y por lo tanto mejor. Sin embargo, esto no es siempre cierto. Lo que se quiere es poder introducir cambios fcilmente y tambin disear objetos y eventos reutilizables. Este es el caso de jerarquas de objetos de control.Ambas estructuras tienen su beneficio. Las dos estructuras se deben combinar para ofrecer una estructura estable y robusta. Los diagramas de secuencia representan mucha de la lgica originalmente definida para los casos de uso y sus asociaciones. Por ejemplo, la relacinincluyeentre casos de uso a menudo corresponde a asociaciones entre objetos correspondientes, mientras que la relacin deextensinentre los casos de uso a menudo corresponde directamente a una relacin de herencia entre objetos.En el diagrama de secuencias, una ubicacin de extensin indica la posicin en el caso de uso a ser extendido, a menudo se acompaada por una condicin la cual indica bajo qu circunstancias la extensin debe ocurrir. La extensin por lo tanto se aplica al caso de uso que extiende y no al que ser extendido para evitar cambiar el caso de uso original cuando se aaden nuevas extensiones.A continuacin se muestran los diagramas de secuencia para el sistema de reservaciones de vuelo para los casos de usoRegistrar Usuarioy Registrar Tarjeta.Ntese como estos diagramas extienden con detalles adicionales los diagramas de secuencias generados anteriormente durante el modelo de anlisis.Registrar Usuario: Crear Registro UsuarioEl diagrama de secuencia para el caso de usoRegistrar Usuario, subflujo Registrarsepor Primera Vez se muestra en la Figura 8.15.

Figura 8.15. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Registrarse por Primera Vez.Registrar Usuario: Actualizar Registro UsuarioEl diagrama de secuencia para el caso de usoRegistrar Usuario, subflujoActualizar Registro Usuariose muestra en la Figura 8.16.

Figura 8.16. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Actualizar Registro Usuario.Registrar Usuario: Eliminar Registro UsuarioEl diagrama de secuencia para el caso de usoRegistrar Usuario,subflujoEliminar Registro Usuariose muestra en la Figura 8.17.

Figura 8.17. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Eliminar Registro Usuario.Registrar Tarjeta: Crear Registro TarjetaEl diagrama de secuencia para el caso de usoRegistrar Tarjeta,subflujoCrear Registro Tarjetase muestra en la Figura 8.18.

Figura 8.18. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Crear Registro Tarjeta.Registrar Tarjeta: Actualizar Registro TarjetaEl diagrama de secuencia para el caso de usoRegistrar Tarjeta,subflujoActualizar RegistroTarjeta se muestra en la Figura 8.19.

Figura 8.19. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Actualizar Registro Tarjeta.Registrar Tarjeta: Eliminar Registro TarjestaEl diagrama de secuencia para el caso de usoRegistrar Tarjeta,subflujoEliminar Registro Tarjetase muestra en la Figura 8.20.

Figura 8.20. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Eliminar Registro Tarjeta.Asociaciones, Operaciones, Mtodos y AtributosEn las secciones anteriores se ha diseado las clases hasta llegar a los protocolos de cada una de ellas. Estos protocolos describen las firmas para las responsabilidades, en otras palabras, las interfaces externas de la clase. Sin embargo, el diseo de objetos an no ha sido terminado. Falta resolver las propias responsabilidades, o sea, las operaciones, en trmino de sus algoritmos. Esto corresponde al cuerpo o implementacin de las mtodos, junto con los atributos de los objetos.Las asociaciones a su vez corresponden a las colaboraciones identificadas durante el diseo de objetos. Sin embargo, es necesario detallar aspectos relacionados con ambos, como es el caso de la multiplicidad y direccin de navegacin entre clases.Tambin es necesario especificar aspectos como lavisibilidadde los mtodos tanto como los atributos, utlizando modificadores comopblicooprivado.Los miembros pblicos del objeto pueden accesarse desde afuera del objeto, correspondientes a los contratos del objeto, mientras que los miembros privados del objetos no pueden accesarse desde fuera y corresponden a las responsabilidades privadas y a los atributos. El encapuslamiento de las clases se basa en ocultar lo mximo posible.AsociacionesLasasociacionesproveen las vas de comunicacin entre los objetos. Durante el diseo de objetos se debe formular una estrategia para implementar las asociaciones.Como se mencion en el captulo 4, las asociaciones son por naturaleza bidireccionales. Esto es cierto en un sentido abstracto, pero si las asociaciones son atravesadas en una sola direccin, su implementacin se podra simplificar. Si la asociacin se atraviesa en una sola direccin, sta se puede implementar como un atributo dereferenciaoapuntadora otro objeto. Si la multiplicidad es de muchos se necesita un arreglo o lista dereferencias.Sin embargo, es posible que algunas asociaciones se deben atravesar en ambos lados. Esto se puede implementar mediante dos atributos de referencia, uno para cada clase involucrada en la asociacin. Este enfoque permite acceso rpido, pero si cualquier atributo es actualizado, entonces el otro debe ser actualizado para mantener la consistencia de la conexin. Otro enfoque es implementar la propia asociacin como un objeto distinto. Esto se puede hacer mediante un objeto de tamao variable que guarde un conjunto de pares de referencias correspondientes a cada liga en la asociacin. El acceso es un poco ms lento que con atributos de referencia, aunque ofrece mayor flexibilidad en la implementacin de la asociacin.En relacin a los atributos de asociacin, estos pueden implementarse segn la multiplicidad correspondiente. En la multiplicidad "1-1" los atributos se pueden guardar como atributos en uno de los objetos. En la multiplicidad "1-muchos" los atributos se pueden guardar como atributos en el objeto del lado "muchos", ya que cada objeto aparece una sola vez en la asociacin. En la multiplicidad "muchos-muchos" el atributo no puede asociarse con ninguno de los dos objetos. En tal caso y en general, el mejor enfoque es implementar la asociacin como una clase distinta, en la cual cada instancia representa una liga entre clase, guardando los atributos en la clase que representa la asociacin. Durante el anlisis no es deseable tener redundancia en las asociaciones, ya que stas no aaden nueva informacin.Durante el diseo se evala la estructura del modelo de objeto para minimizar el costo de acceso y maximizar la conveniencia de la implementacin. Las asociaciones que eran tiles durante anlisis pueden no ser lo ms eficiente para el diseo. Para ello se debe examinar las diversas asociaciones y ver como se puede optimizar las travesas.OperacionesLasoperacionescorresponden directamente a las responsabilidades, la diferencia radica en el trmino particular utilizado. Responsabilidad se basa ms en el aspecto conceptual del servicio dentro de la aplicacin ofrecido por una clase, mientras que operacin est ms relacionado con la funcionalidad orientada a objetos de la clase. Cuando se habla de operaciones se debe pensar tanto en su interface o protocolo como en su implementacin oalgoritmo.Los algoritmos definen la lgica utilizada por cada operacin para resolver la responsabilidad a la cual corresponden. En general, muchas operaciones son suficientemente simples que no requieren de algoritmos, como son las operaciones que atraviesan las asociaciones entre los objetos para consultar o modificar los valores de los atributos. Sin embargo, se necesitan algoritmos para implementar funciones de lgica ms compleja, como ordenar un conjunto de nmeros o palabras. Adems es necesario especificar algoritmos cuando no se ha dado una especificacin procedural para resolver la operacin, para optimizar funciones para las cuales han sido definidos algoritmos simples pero ineficientes, y en general para minimizar el costo de la implementacin de las operaciones. Algunas funciones tambin son especificadas como restricciones declarativas, sin definicin procedural. En tal caso, se debe usar algn conocimiento adicional para implementar el algoritmo. Vale la pena resaltar que los aspectos algortmicos pueden llegar a ser una de las fuentes de mayor complejidad en el sistema completo. En nuestro sistema de reservaciones de vuelos y los sistemas de informacin en general, estos algoritmos tienden a ser sencillos, razn por la cual no profundizaremos aqu.MtodosLos mtodos corresponden a la implementacin de las operaciones, pudiendo haber ms de un mtodo correspondiente a una misma operacin. Se considera que todos los mtodos que tengan el mismo nombre, aunque distinta firma, corresponden a una misma operacin.En general, es deseable generalizar tipos de argumentos, precondiciones, restricciones y suposiciones sobre el comportamiento del mtodo al igual que el contexto en el cual el mtodo opera.Se deben tomar acciones en el caso de valores vacos, extremos, o fuera de rango. Usualmente un mtodo puede hacerse general con un poco ms de cdigo. Se debe documentar la implementacin de los mtodos, describiendo su propsito, funcin, contexto, entradas y salidas.AtributosLosatributoscorresponden a los aspectos estructurales de la clase. Bsicamente existen atributos que guardan valores, como nmeros y textos, y atributos correspondientes a referencias a otros objetos. En el caso de lenguajes como Java y C++ esta distincin es clara ya que los tipos de los atributos definen a cual de los dos se refieren. En el caso de lenguajes como Smalltalk, no hay distncin alguna ya que todos los atributos corresponden a referencias entre objetos.Vale la pena resaltar, que los atributos, en especial aquellos que guardan valores y no referencias, son lo ltimo que se especifica en el diseo de objetos. Los atributos que pueden serderivadosde otros atributos pueden guardarse en su forma computada para evitar recomputacin. Estos atributos derivados deben actualizarse cuando los valores bsicos cambian. Nuevos objetos o clases pueden ser definidos para retener la informacin que debe ser actualizada si un objeto del cual depende es cambiado. Esto se puede hacer mediante cdigo explcito donde cada atributo derivado es definido en trmino de uno o ms objetos fundamentales. Puede tambin hacerse una recomputacin peridica donde todos los atributos derivados se recomputan. Si existen muchos atributos y slo algunos atributos cambian, la recomputacin peridica puede que no sea muy prctica. Otro enfoques es registrar cada valor dependiente con el valor activo definiendo una operacin para actualizar los valores dependientes, algo similar a un trigger.Herencia MltipleHay otro aspecto importante relacionado con la herencia afectando principalmente al dominio del problema. Ya que muchos lenguajes de programacin orientados a objetos no apoyan la herencia mltiple, es necesario en tales casos implementar herencia mltiple a travs de herencia sencilla y posiblemente agregacin (delegacin). Los siguientes tres casos describen el enfoque general: Implementacin de herencia mltiple usando agregacin. Una superclase con mltiples generalizaciones individuales se puede redefinir como un agregado en el cual cada componente del agregado reemplaza una de las ramas de la generalizacin. Se reemplaza las posibles instancias de la herencia mltiple por un grupo de instancias que componen el agregado. La herencia de las operaciones a travs del agregado no es automtica, debiendo ser delegadas a los componentes apropiados. Si una subclase tiene varias superclases, todas de igual importancia, es mejor usar delegacin y preservar la simetra. Implementacin de herencia mltiple heredando de la clase ms importante y delegando el resto. Se toma una como subclase de la superclase ms importante, combinndose con un agregado correspondiendo a las generalizaciones restantes. Si se tiene una superclase principal, se implementa la herencia mltiple a travs de herencia sencilla y agregacin. Si el nmero de combinaciones es pequeo, se puede usar generalizacin anidada (siguiente caso). Si el nmero de combinaciones, o el tamao del cdigo, es grande se debe evitar este tipo de implementacin. Implementacin de herencia mltiple usando generalizacin anidada. Se crean varios niveles de generalizacin, terminando la jerarqua con subclases para todas las posibles combinaciones de clases unidas. En este caso no se utiliza agregacin. Se preserva la herencia pero se duplica las declaraciones, rompiendo con el espritu de la orientacin a objetos. Se debe factorizar primero segn el criterio de herencia ms importante, y luego segn el resto. Si una superclase tiene bastantes ms caractersticas que las otras superclases, o si una superclase es el cuello de botella en el rendimiento, se debe preservar la herencia en relacin a esa clase.Diagramas de Clase del Sistema de ReservacionesUna vez finalizado el diseo de objetos se procede a generar los diagramas de clase para el sistema completo. A continuacin se muestran estos diagramas para el sistema de reservaciones de vuelo.InterfaceUsuarioEl diagrama de clases para las clases del mduloInterfaceUsuariose muestran en la Figura 8.21.

Figura 8.21. Diagrama de clases para las clases del mdulo InterfaceUsuario. PrincipalEl diagrama de clases para las clases del mduloPrincipalse muestran en la Figura 8.22.

Figura 8.22. Diagrama de clases para las clases del mdulo Principal.RegistroEl mdulo deRegistrose compone de los mdulos deUsuario, TarjetayInterfaceBD,como se muestran en las siguientes secciones.UsuarioEl diagrama de clases para las clases del mduloUsuariose muestran en la Figura 8.23.

Figura 8.23. Diagrama de clases para las clases del mdulo Usuario.TarjetaEl diagrama de clases para las clases del mduloTarjetase muestran en la Figura 8.24.

Figura 8.24. Diagrama de clases para las clases del mdulo Tarjeta.InterfaceBDEl diagrama de clases para las clases del mdulo InterfaceBD se muestran en la Figura 8.25.

Figura 8.25. Diagrama de clases para las clases del mdulo InterfaceBD.Diccionario de Clases para el Sistema de ReservacionesComo ltima etapa del modelo de diseo de objetos, se actualiza el diccionario de datos originalmente descrito para el anlisis para incluir todas las actualizaciones hechas. Comenzamos con cuatro mdulos o paquetes principales:InterfaceUsuario, Dominio, Principal, RegistroySevicios, como se muestra en la Figura 8.26.

Figura 8.26. Mdulos principales del sistema de reservaciones de vuelo.InterfaceUsuarioEl mduloInterfaceUsuarioest compuesto por una sla clase: ?? InterfaceUsuario Clase Interface. Toda la interaccin con el usuario se hace por medio de la interface de usuario. Pagina - La Interface para mostrar y recibir informacin del usuario es manejada por la Interface de usuario mediante "pginas" especializadas a partir de esta clase.DominioEl mdulo Dominio est compuesto por una clase: Datos - La clase genrica para todos los objetos entidad.PrincipalEl 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. Manejador -La clase genrica para todos los manejadores. AppletMain- El manejador para applets en el Web.RegistroElmdulo Registrose divide en los siguientes mdulos:InterfaceBD, Usuario y Tarjeta,como se muestra en la Figura 8.27.

Figura 8.27. Mdulos adicionales del mdulo Registro.InterfaceBDEl mdulo InterfaceBD 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.UsuarioEl mdulo Usuario est compuesto por las clases: PaginaRegUsuario -Pgina genrica de registro de usuario. 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.TarjetaEl mdulo Tarjeta est compuesto por las clases: PaginaRegTarjeta -Pgina genrica de registro de tarjeta. 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.ServiciosLas clase principales del mdulo son: 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.

Investigacin y fuente:]francisco reyes

Documents

Modelo de Diseño