INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS

Teora y Prctica con UML y Java

Dr. Alfredo Weitzenfeld

Departamento Acadmico de Computacin Divisin Acadmica de Ingeniera

Mxico, Octubre 2002

Weitzenfeld: Captulo 1

Parte I Introduccin En esta era tecnolgica en la cual vivimos, nuestras vidas estn regidas de gran manera por las computadoras y por el software que las controlan. Las consecuencias del uso del software son muy importantes, a favor y en contra. Cuando todo funciona bien las computadoras son de gran ayuda pero cuando no, el resultado puede ser nefasto, algo que se ha visto a lo largo de los aos en mltiples ocasiones. En esta primera parte del libro se da la motivacin al rea de ingeniera de software orientada a objetos donde se discuten los siguientes temas: (1) el costo del software para la sociedad, (2) la razn para utilizar tecnologa orientada a objetos y (3) el proceso de software necesario para desarrollar y mantener tales desarrollos. 1 El Costo del Software para la Sociedad Se comienza haciendo una pregunta muy sencilla: Cunto le cuesta a la sociedad utilizar sistemas de software? De manera bsica el costo del software puede calcularse en base al gasto mundial en comprar productos y servicios relacionado al software. Por ejemplo, en 1995 se calcul que el mercado mundial de software fue de alrededor de $400 billones de dlares y para el 2000 se estim que sera mayor a $1 trilln de dlares. Segn estadsticas del departamento de comercio americano, el mercado mundial de software empacado en 1994 fue de $77 billones de dlares (se calcula que en 1993 se perdieron $13 billones por piratera). Se calcula que para el ao 2000 sera de $153 billones de dlares. Este software empacado incluye herramientas de aplicacin, soluciones de aplicacin, software de sistemas, y utileras. El mercado de servicios de informacin mundial en 1995 en $324.7 billones de dlares con un incremento de 13% anualmente, lo que significara un mercado de $600 billones de dlares para el ao 2000. Sin embargo, estos costos no representan la realidad completa dada la dependencia que tenemos en el software. En este captulo profundizar un poco ms en este tema para entender cuales son los gastos "ocultos" del software y que consecuencias pueden tener para la sociedad, desde costos econmicos adicionales hasta, incluso, vidas humanas. 1.1 Costos Ocultos y Consecuencias del Software Quizs el costo oculto (externalidades) ms importante del software (el costo no oculto es el que se paga para adquirir o desarrollar ms servicios adicionales) tiene que ver con su funcionamiento incorrecto. La pregunta que nos hacemos es, dada la dependencia sobre el software en el mundo, cules son las consecuencias de su funcionamiento incorrecto? Estas consecuencias se pueden agrupar de la siguiente forma: ? ? Consecuencias inmediatas y efectos directos. Pueden significar horas de cada de los sistemas involucrados y horas de transacciones perdidas. A su vez, esto puede significar que la organizacin tenga que arreglrselas mientras tanto sin sus sistemas; y si los sistemas son centrales a los propsitos de la organizacin, una falla puede representar un costo inmenso. Estos costos corresponden a aplicaciones "criticas de negocios" o "crticas a la misin". Sin embargo, el costo total de una falla de computadora es ms que las consecuencias inmediatas y/o efectos directos. ? ? Consecuencias a mediano y largo plazo y efectos indirectos. Pueden significar productividad perdida, ventas perdidas, costos de servicios de emergencia, costos de restaurar datos, costos por propaganda negativa, costos por accidentes causados, incluyendo posibles juicios en su contra. Estos costos adicionales pueden volver insignificantes el costo bsico del software inicial. Estos puntos anteriores son indicativos de que es difcil predecir el costo real del software para la sociedad a mediano y largo plazo si consideramos los problemas que pudieran ocasionar por su utilizacin. Por otro lado el no utilizar software no sera una alternativa aceptable hoy en da ya que los efectos seran mucho mayores. A lo largo de estos ltimos aos se han podido presenciar casos de fallas de software con consecuencias nefastas. Existen muchos casos donde errores en el software o su mala utilizacin han costado vidas humanas o perdidas econmicas multimillonarias. Peter G. Neumann, moderador del foro de la ACM sobre riesgos al pblico en el uso de computadoras y sistemas relacionados, ha mantenido una lista comprensiva de desastres ocasionados por fallas del software o su mala utilizacin. Otros grupos, como los Profesionales de la Computacin para la Responsabilidad Social (CPSR por sus siglas en ingles) reportan sobre las implicaciones sociales de todo tipo de fallas en las computadoras. Lamentablemente se aprende ms de los errores que de la correcta ejecucin de los sistemas. Las siguientes secciones ilustran algunos de estos casos que sirven para motivar y concientizar al lector en que el software no es algo que pueda o deba tomarse a la ligera en especial si se conoce poco del tema. Ms adelante analizaremos qu se puede hacer para manejar su complejidad y evitar desastres.

Weitzenfeld: Captulo 1

1.1.1 Fallas en Sistemas de Software El orden en la presentacin de los siguientes ejemplos de desastres ocasionados directa o indirectamente por software y por las computadoras que lo operan, es exclusivamente cronolgico sin relacin al rea de aplicacin o las consecuencias que ocasionaron. Por supuesto que slo algunos ejemplos son mencionados, de lo contrario todo el libro pudiera haber sido dedicado al tema! ? ? Fracaso del Mariner 1 (1962). Podemos remontarnos bastante tiempo atrs para descubrir errores ya causados por computadoras. La primera misin del programa Mariner (con costo total de la misin Mariner 1 hasta Mariner 10 de 554 millones de dlares) fracas por culpa de un caracter incorrecto ('? ') en la especificacin del programa de control para el cohete de propulsin Atlas lo cual caus finalmente que el vehculo se saliera de curso. Ambos, el cohete y el vehculo espacial tuvieron que ser destruidos poco despus del lanzamiento. Adicionalmente, se cree que un error de computadora tambin fue la causa del fracaso del Mariner 8 en 1971. ? ? Sobregiro del Banco de New York (1985). En Noviembre de 1985, el Banco de New York (BoNY) tuvo accidentalmente un sobregiro de $32 billones de dlares (una buena suma si consideramos que esto fue hace 15 aos!) por culpa de un contador de 16 bits (la mayora de los dems contadores eran de 32 bits) que se activ ocasionando un "overflow" del contador que nunca fue verificado. BoNY no pudo procesar nuevos crditos de transferencias de "securities", mientras que la Reserva Federal de New York automticamente hizo un traspaso de $24 billones de dlares al BoNY para cubrir sus gastos por un da, por lo cual el banco tuvo que pagar $5 millones de dlares por los intereses diarios, hasta que el software fue arreglado. ? ? Accidente de un F-18 (1986). En Abril 1986 un avin de combate F-18 se estrell por culpa de un giro descontrolado ("unrecoverable spin") atribuido a una expresin "IF-THEN" para la cual no haba una instruccin "ELSE" porque se pens que era innecesaria, resultando en una transferencia fuera de control del programa. ? ? Muertes por el Therac-25 (1985-1987). El acelerador lineal mdico, Therac-25, producido por AECL (Atomic Energy of Canada Limited), fue diseado para tratamiento a pacientes por medio de radiacin de Rayos X de dos tipos: (i) tratamiento de rayo directo de bajo poder, y (ii) tratamiento de rayo indirecto reflejado de alto poder. Entre 1985 y 1987 este sistema ocasion la muerte de varios pacientes en diferentes hospitales de USA y Canad por culpa de radiaciones de alto poder aplicadas de manera incontrolada. La probable causa de los accidentes consista en que para ciertas secuencias de comandos del operador de la mquina, los controles de la computadora llevaban la mquina a un estado interno errneo y muy peligroso, generando una sobredosis masiva de radiacin al paciente. Despus de amplia publicidad de estos accidentes se descubri que la FDA (Federal Drug Agency) no especificaba requisitos, y no haca revisiones sobre prcticas de desarrollo de software o control de calidad de software en dispositivos mdicos. El FDA inform en Septiembre de 1987 que comenzara a requerir controles de software integrados a ciertas clases de dispositivos mdicos. ? ? Avin derribado por el USS Vincennes (1988). En julio de 1988 la fragata USS Vincennes estaba asignada al golfo prsico. Despus de repetidos intentos de comunicacin por radio, el USS Vincennes dispar un misil (por error) derribando un avin Airbus comercial Iran matando a todos los 290 pasajeros y tripulantes. Esto ocurri mientras el Airbus ganaba altura, bajo la suposicin incorrecta de que era un avin de combate F-14 que descendera sobre el barco de manera hostil. Aunque la orden de disparo fue dada por el comandante del navo, se culpa como causa contribuyente del incidente al sistema de radar AEGIS, el cual con su sistema de interface de usuario mostraba nicamente un punto junto a un dato textual representando al avin, en lugar del eco real del radar sobre el avin. Posteriormente se supuso que en algn momento la aerolnea Iran estuvo en la proximidad de un F-14, probablemente durante el despegue del aeropuerto, confundiendo al sistema AEGIS y asociando de manera incorrecta la informacin transmitida por los "transponders" aire-tierra del F-14 a la aerolnea. Cuando el avin despeg, ste qued asociado con los datos del F-14 sobre la pantalla. Un despliegue inconveniente y posiblemente confuso de la informacin de altitud del avin posiblemente confundi an ms a los oficiales del barco, los cuales supusieron que el F-14 estaba descendiendo, aunque en realidad estaba ganando altura. La inclusin de un eco real del radar sobre la pantalla hubiera hecho posible determinar que el eco del radar del avin era del tamao incorrecto para un avin de combate. ? ? Falla del software de AT&T (1990). El 15 de enero de 1990, AT&T (American Telegraph and Telephone) la compaa que controla las redes del mayor sistema de comunicacin en el mundo, experiment una falla masiva que dej fuera de servicio su sistema de comunicaciones de larga distancia. La falla dur alrededor de nueve horas e interrumpi millones de llamadas de larga distancia. Un error en el software de manejo de excepciones de un tipo particular de sistema de switching telefnico result en una falla de switching, que a su vez caus otras fallas de switching en un efecto cascada. Segn Neuman, se report que la ltima causa del problema tuvo

Weitzenfeld: Captulo 1

??

??

??

??

??

origen en un programa en el lenguaje C que contena una instruccin "BREAK" dentro de una clusula "IF" dentro de una clusula "SWITCH". Aberracin esfrica en el telescopio espacial Hubble (1990). El 25 de Abril de 1990 se puso en rbita el famoso telescopio espacial Hubble desde el vehculo espacial Discovery. Al poco tiempo, NASA descubri que el componente ms crtico del telescopio de $4 billones de dlares, su espejo principal, tena una gran falla, imposibilitando producir imgenes altamente enfocadas. El problema en su lente es tcnicamente conocido como una "aberracin esfrica". Una investigacin de la NASA revel que el espejo se haba construido con la forma incorrecta siendo 2 micrones (1 micrn = 10-6 metros) ms plano a los lados de lo estipulado en el diseo original, un error bastante grande segn los estndares de precisin de la ptica moderna. Este fue el error principal encontrado en el telescopio, considerando que hubo otros problemas adicionales, como en sus paneles solares, sus giroscopios, y contactos elctricos. El problema del lente radic en que nunca fue realmente probado antes de ser enviado al espacio. En su lugar, una simulacin de computadora se us como mtodo de menor costo para validar el rendimiento del espejo. Por desgracia, malos datos de entrada se utilizaron en la simulacin, significando resultados despreciables. Para corregir el error final en el espacio, se agreg al telescopio ptica correctiva a un costo muchas veces mayor que una prueba en tierra del espejo, significando adems que el espejo nunca funcionara tan bien como se plane. Por lo pronto, la NASA no planea otro telescopio de la magnitud del Hubble, por lo cual los astrnomos tendrn que limitarse a las restricciones actuales del Hubble, con el cual slo se pueden ver objetos aproximadamente 20 veces ms grandes de lo original. Duplicacin de solicitudes de transferencias bancarias (1990). En 1990 un error de software ocasion que un banco en el Reino Unido duplicara cada solicitud de transferencia de pago por un periodo de media hora, acumulando 2 billones de libras esterlinas adicionales. Aunque el banco expres haber recuperado todos los fondos, se especul que los posibles intereses perdidos pudieran haber llegado a medio milln de libras por da. Falla del software de los misiles Patriot (1991). En las primeras etapas de la guerra del golfo prsico de 1991, el sistema Patriot fue descrito como altamente exitoso. En anlisis posteriores, los estimados de su efectividad fueron disminuidos seriamente de 95% a 13% o incluso menos. El sistema fue diseado para trabajar en un ambiente mucho ms limitado y menos hostil que el que haba en Arabia Saudita. Segn report posteriormente el New York Times, una falla en la computadora de tierra del misil Patriot fue responsable de evitar la peor baja americana durante la guerra. Esto result en su inoperabilidad, permitiendo que un misil "scud" destruyera unas barracas militares americanas en Dhahran, Arabia Saudita, causando 29 muertos y 97 heridos. Aparentemente el sistema de radar del Patriot nunca vio al misil Scud. Segn oficiales del ejrcito "una combinacin imprevista de docenas de variables - incluyendo la velocidad, altura y trayectoria del Scud - causaron la falla del sistema del radar [este caso fue] una anomala que nunca apareci durante las horas de pruebas." El error se atribuye a una acumulacin de inexactitudes en el manejo interno del tiempo de la computadora del sistema. Aunque el sistema ejecutaba segn las especificaciones, ste deba ser apagado y prendido con la suficiente frecuencia para que el error acumulado nunca fuera peligroso. Como el sistema se us de manera no planeada, una pequea inexactitud signific un serio error. Despus de 8 horas de uso se detect el problema del reloj acumulado. La correccin slo se logr al da siguiente de la catstrofe (Mellor, 1994; Schach 1997). Error en el procesador Pentium de Intel (1994). En 1994 un error de punto flotante en el procesador Pentium le cost US $475 millones a Intel. El error no fue reconocido pblicamente por varios meses por Intel diciendo que el procesador era "suficientemente bueno" adems de que sera muy difcil que el error ocurriera. Actualmente, Intel est sufriendo otros problemas similares con sus procesadores, como la unidad MTH (Memory Translator Hub) usado para transferir seales de la memoria a otra unidad de la computadora (Intel 820) que podra significarle un costo similar. Recientemente ha tenido problemas con la ltima generacin del Pentium III de 1 Ghz, donde se ha visto obligada a retirarlo del mercado. Al menos la compaa ya ha aprendido a reconocer sus errores! Error en sistema de autentificacin de tarjeta de crdito (1995). Segn un artculo del 4 de Noviembre 4 de 1995 del peridico Guardian en UK se relata que los dos sistemas ms grandes en UK para la autorizacin de crdito (Barclay's PDQ y NatWest's Streamline) fallaron el sbado 28 de octubre de 1995 dejando a los negocios sin poder verificar las tarjetas de crdito de sus clientes. En el caso de Barclay, ms del 40% de las transacciones fallaron por un "error en el sistema de software". Para NatWest, el problema fue una gran cola de llamadas, por razones desconocidas, las cuales retrasaron la autentificacin de tarjetas. Aunque ambos tenan sistemas de contingencia permitiendo a los negocios telefonear para autenticar solicitudes, por el volumen de ventas las lneas se saturaron rpidamente.

Weitzenfeld: Captulo 1

??

??

??

??

??

??

Explosin del cohete Ariane 5 (1996). El 6 de Junio de 1996 una computadora fue culpada por la explosin del primer vuelo, el 501, del cohete Ariane 5 con un costo de US$500 millones de dlares. El cohete, que parece que no estaba asegurado, llevaba cuatro satlites, ocasionando prdidas totales de $1.8 billones de dlares. El Ariane-5 estaba funcionando perfectamente hasta los 40 segundos iniciales cuando de repente empez a salirse de su curso y fue destruido remotamente por una explosin solo fracciones de segundo despus, ocasionadas por una seal enviada por un controlador de tierra del Ariane. Segn ESA (Agencia Espacial Eurpea), la desviacin fuera de curso fue ocasionada por instrucciones de la computadora controlando los escapes de los dos poderosos impulsadores del cohete. Incluso se especul que la instruccin fue generada por la computadora porque crey que el cohete se estaba saliendo de su curso y de esta manera estara corrigiendo el curso de vuelo. Segn el reporte final, la causa de la falla fue una excepcin de software ocurrida durante la conversin de un nmero flotante de 64-bits a un nmero entero de 16 bits. El nmero flotante siendo convertido tena un valor mayor del que poda ser representado por un nmero entero de 16 bits (con signo). Esto result en un "error de operando". Las instrucciones de conversin de datos (cdigo en Ada) no estaban protegidos de causar tal error de operando, aunque otras conversiones de variables similares en el mismo lugar, s estaban protegidas. El origen del problema parece haber sido en que el Ariane 5 poda llevar un mayor nmero de satlites que el Arianne-4, incrementando as su peso. Sin embargo el Ariane-5 utilizaba una gran cantidad de software diseado para el Ariane-4. Las conclusiones finales no oficiales fueron que ningn mtodo formal hubiera detectado el problema, ya que la raz de tal era a nivel de comunicacin entre humanos, en relacin a informacin fsica aparentemente no relacionada y no un problema de programacin. Error del sistema de cobranza lleva a una compaa a la quiebra (1996). Un artculo en la edicin de Abril de 1996 de "TVRO Dealer" (una publicacin del rea de televisin por satlite) describe cmo el intento de un servicio de programacin de una gran compaa de televisin por satlite de cambiar a un nuevo sistema de software de cobranza el 28 de Marzo anterior finalmente caus la quiebra de la compaa. Error del sistema de cobranza en MCI (1996). En la edicin del 29 de marzo de 1996 del Washington Post, MCI report que devolveran aproximadamente 40 millones de dlares a sus clientes por causa de un error de cmputo. El error de cobranza fue descubierto por un reportero investigador de una estacin local de televisin en Richmond, VA. Los reporteros encontraron que fueron facturados por 4 minutos despus de hacer una llamada de tan solo 2.5 minutos, dando lugar a una profunda investigacin. Mayor falla de una computadora en la historia de bancos en USA (1996). El 18 de mayo de 1996 la revista US & World Report, y al siguiente da el diario The Boston Globe, reportaron que aproximadamente 800 clientes del First National Bank of Chicago fueron sorprendidos al ver que sus saldos eran $924 millones de dlares ms de lo que tenan la semana pasada. La causa fue el tradicional "cambio en el programa de la computadora". De acuerdo a la Asociacin de Banqueros Americanos, el total de $763.9 billones fue la cantidad ms grande para tal error en la historia bancaria de los Estados Unidos, ms de seis veces el total de fondos ("assets") del First Chicago NBD Corp. El problema fue atribuido a un "error de la computadora". Falla de la computadora del centro de control de trfico areo de NY (1996). El 20 de Mayo 1996 fall la computadora del Centro de Control Areo de Nueva York (ARTCC - NY Air Route Traffic Control Center) que controla el trfico areo sobre los estados de New York, Connecticut, New Jersey, Pennsylvania y parte del ocano Atlntico. La computadora de 7 aos de vigencia perdi capacidad de servicio efectivo ("fall") dos veces la tarde del lunes 20 de mayo; la primera vez por 23 minutos y la segunda por alrededor de una hora, una hora ms tarde. Parece que 4 das antes se haba instalado un nuevo software en el sistema. Se volvi al sistema anterior, con procedimientos de control de trfico areo ms ineficientes, ocasionando un lmite ms bajo de saturacin de trfico y retrasos en los despegues de alrededor de una hora en los aeropuertos principales en el rea; junto con un incremento en la carga de trabajo de los controladores y menor seguridad, incluyendo la desactivacin de la "alerta automtica de conflictos". Mala planificacin del nuevo sistema de una administradora de servicios de salud (1997). Segn report el Wall Street Journal el 11 de diciembre de 1997, Oxford Health Plans Inc., administradora de servicios de salud en USA, de gran crecimiento en los ltimos tiempos, anunci que registrara una prdida de US$120 millones o ms durante ese trimestre, adems de una prdida adicional de US$78,2 millones, su primera prdida desde que sali a la bolsa en 1991. La razn principal fue la larga lista de problemas ocurridos con un sistema informtico que se puso en lnea en 1996; desde el diseo del sistema y su instalacin hasta cmo fue administrado por los ejecutivos del grupo Oxford. Los problemas ocasionaron que Oxford no pudiera enviar facturas mensuales a miles de cuentas de clientes adems de incapacitarla para rastrear los pagos a cientos de mdicos y hospitales. En menos de un ao, los pagos no cobrados de sus clientes se triplicaron a ms de US$400 millones, mientras que el monto que Oxford deba a los proveedores de servicios mdicos aument en ms del 50%, a una suma

Weitzenfeld: Captulo 1

??

??

??

superior a los US$650 millones. La administradora de servicios mdicos comenz a planear su nuevo sistema informtico en 1993, cuando slo tena 217,000 miembros. El sistema, desarrollado por Oracle, no comenz a utilizarse hasta Octubre de 1996, cuando el nmero de abonados a su seguro mdico haba llegado a 1,5 millones. En ese momento el sistema ya era obsoleto. En lugar de tomar 6 segundo inscribir a un nuevo miembro, tomaba 15 minutos. A pesar de esto y que la infraestructura administrativa de Oxford no daba abasto, los ejecutivos seguan inscribiendo nuevos clientes, en el ltimo ao se incorpor medio milln adicional. A finales de 1993, Oxford trat de ajustar el sistema, adems de convertir de una sola vez la mayora de su base de datos para facturacin: unas 43,000 cuentas cubriendo a 1,9 millones de miembros. Esto signific la catstrofe final, ya que la transformacin entre base de datos no funcion, y mientras tanto se suspendi por unos meses la facturacin ya que no se contaba con un sistema de seguridad, ni siquiera manual. A pesar de todo esto, Oxford sigui sus prcticas habituales de contabilidad, registrando aquellas facturas que no se haban cobrado como facturacin trimestral. Los problemas finales surgieron cuando Oxford comenz a poner al da las cuentas vencidas contactando a los clientes por primera vez en varios meses. Muchos se negaron a pagar y otros dijeron que haca mucho que haban cancelado su cuenta. Por consiguiente, Oxford tuvo que registrar US$111 millones como deudas incobrables y reconoci que tena 30,000 afiliados menos de lo que haba calculado. El presidente reconoci que deba haber contratado un ejrcito de trabajadores temporales para que escribieran a mquina las facturas. Por otro lado, lo primero que perdieron fueron los clientes pequeos, pero como luego no resolvieron ningn problema comenzaron a perder a los clientes grandes. Error de un controlador de discos de Toshiba (1999). En noviembre de 1999 Toshiba lleg a un arreglo fuera de corte que le costara a la compaa ms de $2 billones de dlares para cubrir errores que pudiesen haber significado la prdida de informacin por culpa de fallas en los controladores de discos "floppy" producidos en sus computadoras porttiles a partir de 1980. Aunque los controladores fueron diseados originalmente por NEC, Toshiba produca sus propios componentes y nunca incluy la modificacin hecha por NEC en 1987 lo cual hubiese evitado el problema. Lo mas interesante del caso es que realmente nunca se report falla alguna. Queda por ver que consecuencias traer este caso al resto de los fabricantes de computadoras para los cuales este precedente los tiene extremadamente preocupados. Actualizacin de software mal planificada paraliza Nasdaq (1999). El 17 de noviembre de 1999 los corredores de la bolsa de valores Nasdaq no pudieron comprar ni vender acciones durante 17 minutos cruciales, despus de que oficiales de Nasdaq intentaran actualizar sobre la marcha un sistema de software durante la ltima media hora de la sesin. Algo funcion mal y los inversionistas tuvieron que pagar el precio. Error del milenio (2000). Concluyo estos ejemplos con un pequeo pero nocivo error que se le conoce como el problema Y2K, error del milenio, o inclusive el problema de software del siglo 20. El problema se remonta a la dcada de los 60, y radica en que hace mucho tiempo los programadores adoptaron la convencin de representar el ao con dos dgitos en lugar de cuatro. Esta convencin ocasionara fallas en los sistemas al llegar al ao 2000, ya que se alambraba el "19" (no se permita utilizar un nmero que no fuera el 19), para generar la fecha lo cual al llegar al ao 2000 fallara por saturar el registro de almacenamiento ("overflow"). Para empeorar las cosas a menudo los dgitos "99" o "00" eran valores reservados (nmeros mgicos) significando "nunca borrar esto" o "esta es una cuenta de demostracin". Adems, esto resultaba en el uso de un algoritmo incorrecto para reconocer aos bisiestos. No est claro si hay una razn nica para haber hecho esto; porque la memoria de las computadoras en esa poca era extremadamente cara, o porque no se esperaba que estos sistemas duraran tanto tiempo, o incluso quizs porque no reconocieron el problema. Aunque el problema se activ en este nuevo milenio, se tiene precedentes. Muy pocos se dieron cuenta que la IBM 360 no poda manejar fechas mayores al 31 de Diciembre de 1969, hasta que estas mquinas empezaron a fallar a la medianoche hora local. IBM recomend a sus clientes en Amrica y Asia mentirles a las computadoras cambiando a una fecha anterior, mientras IBM empez a crear una solucin al problema. El problema es muy extenso, afecta hardware (BIOS, relojes de tiempo real, "embedded firmware", etc.), lenguajes y compiladores, sistemas operativos, generadores de nmeros aleatorios, servicios de seguridad, sistemas de manejo de bases de datos, sistemas de procesamiento de transacciones, sistemas financieros, hojas de clculo, conmutadores telefnicos, sistemas telefnicos y ms. No es solamente un problema de sistemas de informacin, todo aquel sistema que use fechas est expuesto: automviles, elevadores, etc. (Por ejemplo, en cierto momento Visa y MasterCard pidieron a sus bancos asociados que dejen de dar tarjetas que expiren en el 2000 o despus.) No solamente es un problema de aplicaciones antiguas: el ao pasado el paquete Quicken para manejo de finanzas personales fue corregido para ir ms all de 1999. En enero se report que el Instituto Nacional de Salud (NIH) en USA recibi nuevas PCs con tres versiones diferentes de BIOS, dos de las cuales fallaron a la transicin Y2K. Las soluciones fueron muchas, consistiendo de diferentes etapas para analizar el problema particular y decidiendo las medidas a tomar, incluyendo no hacer nada y dejar que el problema ocurriera para luego

Weitzenfeld: Captulo 1

arreglarlo. Existe an toda una industria alrededor de este problema, con 1,800 compaas asociadas a la organizacin "year200" (year2000.com, year2000.org) y proporcionando certificaciones. Se dice que lleg a ser tanta la demanda por programadores del lenguaje Cobol (donde el problema fue ms significativo) y tan desesperada la situacin, que segn se report, se fue a buscar programadores de Cobol ya retirados en asilos para ancianos Actualmente se desconoce el costo final al problema de Y2K. Es difcil estimar cual fue el costo total del problema Y2K. Segn la compaa TMR (Technology Management Reports) de San Diego, los costos podran haber sido superior a $1 trilln de dlares. Esto incluye reescribir programas existentes, adquisicin e instalacin de sistemas que los reemplacen, y productividad perdida por culpa de la interrupcin de los sistemas para pruebas y las propias fallas por no ser funcionales en el ao 2000. Y esto no incluye demandas por daos ocasionados. Otras compaas predijeron rangos de costos similares, como el grupo Gartner, que predijo un costo de $600 billones de dlares a nivel mundial. Varias compaas asignaron presupuestos para este problema: Chase Manhattan dijo que gastara $250 millones de dlares, American Airlines y Hughes Electronics dijeron que gastaran $100 millones de dlares cada una. La oficina de administracin de presupuesto de la Casa Blanca (OMB - Office of Management and Budget) calcul sus costos de reparacin en 2.8 billones. Esto inclua 4,500 computadoras para defensa nacional, trfico areo, pagos de impuestos y seguridad social. El Grupo Gartner estim que los costos para el Departamento de Defensa de USA podran ser superior a los US$30 billones. 1.1.2 Sobrecostos, Retrasos y Cancelaciones en los Sistemas de Software Lamentablemente los costos de los sistemas de software no se restringen a fallas en el software o los sistemas de computadora. Segn una encuesta hecha por el Standish Consulting Group en 1995 compaas y agencias gubernamentales americanas perdieron $81 billones de dlares por proyectos de software cancelados. Segn Rob Thomsett, las causas de esto pueden ser de dos niveles principales: (i) factores que casi garantizan la cancelacin del proyecto, como la falta de un dueo del proyecto; y (ii) factores que no resultan en una cancelacin inminente del proyecto, pero seguramente ocasionarn reducciones substanciales en su calidad. En esta seccin se muestran algunos ejemplos clsicos en orden cronolgico. ? ? Sobrecosto y retraso en sistema de Allstate Insurance (1982). En 1982, Allstate Insurance comenz a construir un sistema para automatizar su negocio por $8 millones. El supuesto esfuerzo de 5 aos continu hasta al menos 1993 cuando termin costando cerca de $100 millones. ? ? Sobrecosto, retraso y cancelacin en sistema de London Stock Exchange (1983-1988). El proyecto Taurus de la Bolsa de Valores de Londres estaba originalmente cotizado en 6 millones de libras. Varios aos ms tarde y ms de 100 veces (13,200%) sobre presupuesto el proyecto fue cancelado, costando a la ciudad de Londres al momento de ser abandonado, 800 millones de libras. ? ? Sobrecosto y retraso en sistema del bombardero B-1 (1985). El bombardero B-1 en servicio desde 1985 requiri US $1 billn adicional para mejorar su software de defensa area que era inefectivo, aunque problemas de software imposibilitaron alcanzar los objetivos originales. ? ? Sobrecosto, retraso y cancelacin en sistema de Bank of America (1988). En 1988, Bank of America gast US $23 millones en una plan inicial de 5 aos para desarrollar MasterNet, un sistema computarizado para contabilidad y reportes de "trust". Luego de abandonar el sistema viejo, gastaron $60 millones adicionales para lograr que el nuevo sistema funcionara y finalmente terminaron desistiendo. Las cuentas de los clientes perdidos pudieron haber excedido los billones de dlares. ? ? Sobrecosto y retraso en sistema de control de rastreo por satlite (1989). El software para la modernizacin de la Facilidad de Control de Rastreo por Satlite tom 7 aos ms de lo previsto y cost $300 millones adicionales ofreciendo menor capacidad de la requerida. ? ? Sobrecosto y retraso en sistema Airborne Self-Protection Jammer (1989). El sistema ASJP (Airborne SelfProtection Jammer), un sistema electrnico de defensa area instalado en alrededor de 2,000 aviones de combate y ataque de la Marina Americana, cost US $1 billn adicional, tom 4 aos adicionales, y slo fue "efectivo operacionalmente marginalmente y apropiado operacionalmente marginalmente". ? ? Sobrecosto en sistema del avin de carga C-17 (1989). El avin de carga C-17 construido por Douglas Aircraft cost $500 millones adicionales por problemas del software aeronutico. Un reporte de GAO not que existieron 19 computadoras a bordo, 80 microprocesadores, y 6 lenguajes diferentes de programacin. 1.1.3 Razn de los Problemas del Software Cmo podemos justificar tantos problemas en el software y las computadoras? Una pequea ancdota refleja la situacin.

Weitzenfeld: Captulo 1

Se dice que hace unos aos se juntaron un mdico, un ingeniero civil y un ingeniero en computacin para discutir cual era la profesin ms antigua del universo. El mdico explic: Dios cre a Eva de la costilla de Adn; obviamente se requiri ciruga, por lo cual la medicina tiene que haber sido la profesin ms antigua. A esto dijo el ingeniero civil: antes de Adn y Eva, Dios cre todo el universo, del caos puso orden en el cielo y en la tierra, siendo sta la aplicacin ms espectacular de la ingeniera civil y tambin la ms antigua. Finalmente, exclam el ingeniero en computacin, quin creen que cre el caos en primer lugar. Una frase ms actual dice que para hacer las cosas mal es suficiente una persona, pero para hacerlas verdaderamente desastrosas se requiere una computadora. 1.2 Complejidad del Software El problema principal que hemos visto en la seccin anterior radica en que cuanto ms grandes son los sistemas de software mayor es su complejidad. Uno se pregunta, de dnde proviene toda esta complejidad? Se puede hablar de dos aspectos que causan esta complejidad, uno esttico y otro dinmico. El aspecto esttico del software tiene que ver con la funcionalidad que el software ofrece. Cuanto mayor es su funcionalidad mayor es el nmero de requisitos que debe satisfacer un sistema. Esto significa que los sistemas se vuelven ms grandes y ms difciles de comprender por la cantidad de informacin y funciones que manejan. El nivel de complejidad radica en estos aspectos intrnsicos a la aplicacin. Para reducir tal complejidad habra que simplificar la funcionalidad que el sistema ofrece. Obviamente, la complejidad puede fcilmente aumentar si la aplicacin no est desarrollada de manera adecuada. El aspecto dinmico del software tiene que ver con los cambios que pudieran hacerse en un sistema en el futuro. Segn una ley de desarrollo de software (Lehman, 1985), todo programa que se use se modificar; y cuando un programa se modifica, su complejidad aumenta, siempre y cuando uno no trabaje activamente contra esto. Esto es similar al problema de la entropa, una medida de termodinmica sobre desorden. Segn la segunda ley de termodinmica, la entropa de un sistema cerrado no puede ser reducida, solo puede aumentar o posiblemente mantenerse sin cambios. Una alternativa es aplicar reingeniera para reducir esta entropa, y as poder continuar con el mantenimiento del sistema. Por otro lado, cuando se llega a tal desorden, no es econmicamente justificable continuar con el sistema, ya que es demasiado caro modificarlo. Lamentablemente, como se vi antes, la historia nos muestra que los sistemas raramente se desarrollan a tiempo, dentro del presupuesto y segn las especificaciones originales. Ms an, los sistemas tienden a fallar. Sin embargo, segn veremos en el Captulo 3, no todo es negativo. Un aspecto importante para poder manejar la complejidad de los sistemas, es seguir un buen proceso de software. 1.2.1 Robustez del Software Tomemos el caso de los sistemas de control de trfico areo de Estados Unidos. El gobierno requiere que sus nuevos sistemas no dejen de funcionar por ms de 3 segundos al ao. Adems requiere que en los sistemas de las aerolneas civiles la probabilidad de ciertas fallas catastrficas no sean mayor a 10-9 por hora. La problemtica de esto es cmo comprobar que dichas fallas nunca ocurran dado que de por s ocurren muy raras veces. Por ejemplo, el requisito anterior significa que se tendra que ejecutar un programa varios mltiplos de 109 (100,000 aos) para asegurarse que el sistema funcione bien y que tales fallas no ocurran. Segn Edward Adams de IBM Thomas Watson Research Center, un tercio de todas los errores (bugs) son defectos de "5,000 aos" (MTBF - mean time between failures): cada una de ellas produce un error una vez cada 5,000 aos. Adems de la dificultad para encontrar la falla, remover una de ellas significara una mejora insignificante en la robustez del sistema. Segn Caper Jones (1995), se puede estimar el nmero de defectos "latentes" en un sistema tpico de acuerdo al tamao del sistema, medido en puntos de funciones, subido a la 1.2 potencia. Se calcul que cuando Microsoft Windows 3.1 se envi al mercado en 1992 contaba con 5,000 errores (bugs) conocidos. Considerando que Windows 95 consista aproximadamente de 80,000 puntos de funcin, esto sugiere que Windows 95 tena aproximadamente 765,000 errores latentes (o sea, errores que en el proceso de desarrollo deban componerse durante las etapas de pruebas). Si todas estas pruebas removieran el 99% de los errores, aun quedaran 7,650 para ser encontrados despus de haberse enviado el software al mercado. La primera versin de Word tuvo 27,000 lneas mientras que Word 6.0 tena 2 millones. Word 6.0 tena 10 veces ms funcionalidad que Word 5.1, y 3 veces la cantidad de cdigo, significando obviamente una gran lentitud en el sistema. Los nmeros para Office 2000 y Windows 2000 aterraran a cualquiera! Por supuesto que existen mtodos formales que son pruebas matemticas para garantizar si un programa funciona de acuerdo a sus especificaciones. Sin embargo, esto tampoco ofrece una solucin completa, aunque siempre ayuda. Entonces, que alternativa tenemos para mejorar la robustez del software? Analizaremos esto y otros temas ms adelante.

Weitzenfeld: Captulo 1

1.2.2 Software Suficientemente Bueno En general no existe una sola medida que nos diga que tan bueno es un sistema de software. Por un lado, un sistema de software se puede considerar exitoso cuando satisface y posiblemente excede las expectativas de los clientes y/o usuarios en el momento de utilizarse. A nivel de negocios, esto tambin implica que se desarrolle a tiempo, de manera econmica, y que se ajuste a modificaciones y extensiones posteriores. De manera general se pueden caracterizar aspectos externos e internos al sistema. Como factores externos, los usuarios esperan resultados rpidos, que el software sea fcil de aprender, sea confiable, etc. Como factores internos los administradores del software esperan que el sistema sea fcil de modificar y extender, al igual que sea fcil de comprender, verificar, migrar (a diferentes ambientes de cmputo), etc. Quizs de todos estos aspectos, lo que ms se puede medir cuantitativamente es la cantidad de errores o defectos que resultan. Aunque en la prctica no se puede garantizar el software perfecto, o sea cero defectos, la pregunta es cundo el software es suficientemente bueno, y cuanto esfuerzo amerita invertir para eliminar defectos adicionales. Segn Yourdon los tres elementos ms importantes del software "suficientemente bueno" son funcionalidad ("feature richness"), calidad y tiempo (schedule) como se muestra en la Figura 1.1. Cualquier cambio en uno de estos aspectos afecta a los otros.
Funcionalidad

Calidad

Tiempo

Figura 1.1 Diagrama de calidad versus funcionalidad versus horario del software. Actualmente la situacin es tan extrema que en el apogeo de la guerra de "browsers" entre Netscape y Microsoft se competa por quien liberaba ms rpido su siguiente browser, agregando cada vez mayor funcionalidad, con ciclos de desarrollos de slo unos pocos meses. Esto obviamente afect la calidad del producto significando muchos errores en los nuevos "browsers" que no fueron depurados de manera adecuada, volvindose el usuario el encargado de probar realmente el software y encontrar sus errores. En 1997 errores de seguridad en Netscape y Explorer 4.0 hicieron que las compaas revisaran sus programas y los quitaran temporalmente del mercado. Situaciones similares son comunes en la actualidad. Lo peor del caso es que ante la opcin de escoger entre un software perfecto, con cero defectos o una versin ms nueva con todo lo novedoso, pero que pudiera tener algunos errores, la gente siempre quiere la nueva. En cierta manera nosotros mismos impulsamos el deterioro en la calidad del software comercial. La famosa frase "ms rpido, ms barato, mejor" realmente significa en la actualidad "suficientemente rpido, suficientemente barato, suficientemente bueno". 1.2.3 La Bala de Plata ("Silver Bullet") En 1975 Fred Brooks, "el padre del Sistema 360 de IBM", escribi su famoso libro "The Mythical Man-Month" en el cual resaltaba la complejidad en el desarrollo de sistemas de software; un clsico an hoy en da vuelto a publicar en 1995 para su vigsimo aniversario. El sistema operativo OS/360 de IBM escrito en la dcada de los 60 tuvo en su apogeo 1000 personas trabajando al mismo tiempo en el proyecto, incluyendo programadores, documentadores, operadores, secretarias, administradores y dems. Entre 1963 y 1966 se calcul que se utilizaron para el diseo, construccin y documentacin del sistema 5000 aos-persona. Calculado a 100 lneas/persona/mes esto sera equivalente a 5,000x100x12 = 6 millones de lneas. Este sistema es el precursor de MVS/370 y MVS/390 an utilizado por los mainframes de IBM. Uno de sus ms conocidos legados es la famosa "Ley de Brooks" que resalta que cuanto ms gente se agregue a un proyecto de software ya retrasado ms se retrasa el proyecto, como se muestra en la grfica de la Figura 1.2.

Weitzenfeld: Captulo 1

Tiempo

Nmero de Programadores

Figura 1.2 Ley de Brooks: cuanto ms se aumente el nmero de trabajadores mayor el tiempo de desarrollo. La razn para esto se basa en que las necesidades de personal se calculan inicialmente segn una simple medida de lneas de cdigo producidas por una persona al mes (el estndar actual es aproximadamente de 100 a 1,000 lneas por personas al mes), lo cual significara que si un proyecto requiere 10 millones de lneas, simplemente se puede dividir por los meses y personas que se requieren para lograr esa cantidad y si llegase a haber un retraso, simplemente se pueden agregar ms personas en base a un clculo similar. Sin embargo, esto no funciona as en la realidad. La razn principal de esto es que a las nuevas personas hay que entrenarlas y explicarles el proyecto. Significa que se quita temporalmente personal ya involucrado en el proyecto para dedicarle a las nuevas contrataciones, causando que el proyecto se retrase an ms. Pero esta ley no es el legado ms importante de Fred Brooks para la computacin. Brooks ha contribuido con muchas ideas, incluso algunas controversiales. En 1987 (IEEE Computer, Abril 1987) public su ya clebre artculo "No Silver Bullet" en el cual menciona: "..segn miramos al horizonte de una dcada, no vemos ninguna bala de plata. No existe un solo desarrollo, en la tecnologa o tcnica de administracin, que por si slo prometa incluso una mejora de un orden de magnitud en productividad, seguridad (reliability), simplicidad, dentro de una dcada". En otras palabras, no hay nada que permita mejorar la calidad del software de manera radical. 1.2.4 Ciclo de Vida del Software Para apreciar esto es necesario comprender un poco ms en qu consiste desarrollar software. Un sistema de software tiene un ciclo de vida que comienza con la formulacin de un problema, seguido por la especificacin de requisitos, anlisis, diseo, implementacin, verificacin, validacin, integracin y pruebas del software, continuado de una fase operacional durante la cual se mantiene y extiende el sistema. Todo desarrollo de software incluye aspectos esenciales, como la creacin de las estructuras que resuelvan el problema, junto con aspectos secundarios ("accidentales"), como la codificacin y las pruebas. Segn Brooks, existe una regla emprica ("thumb rule") que dice que para el desarrollo de un proyecto de software se debe asignar, 1/3 del tiempo a la planeacin, 1/6 a codificacin, 1/4 a pruebas de componentes, y 1/4 a pruebas del sistema, como se muestra en la Figure 1.3. O sea, la mitad del esfuerzo (2/4) son dedicados a pruebas lo cual tambin incluye la depuracin y aspectos secundarios del software.

1/6 Codificacin

1/4 Pruebas Componentes

1/3 Planeacin

1/4 Pruebas Sistema

Figura 1.3 Estimado general del tiempo dedicado al desarrollo de un proyecto de software. La mayora de las mejoras en la productividad del sofware se han dado histricamente simplificando las tareas secundarias como las herramientas, ambientes y lenguajes de programacin. Segn la premisa de Brooks, a menos

Weitzenfeld: Captulo 1

10

que lo secundario fuese ms de 9/10 del esfuerzo total, reduciendo estas actividades a cero no resultara en un orden de magnitud de mejora. Ya que ste no es el caso, sera necesario tambin reducir el tiempo dedicado a lo esencial. Entonces, como hacer para mejorar tan radicalmente la productividad del software? El autor muestra cierto pesimismo, y lamentablemente bastante realismo. Todo esto es un reflejo de que los sistemas de software son muy complejos, pudiendo contar con muchos millones de lneas de cdigo. Esta complejidad requiere de un proceso de desarrollo de software eficiente y sistemtico, con base a buenas metodologas y herramientas de apoyo. Como no se puede eliminar la complejidad, por lo menos se podr reducirla a un nivel manejable. Otro famoso autor y tecnlogo, Ed Yourdon discute en su libro "Rise and Resurrection of the American Programmer" en 1996 (una revisin a su libro anterior titulado "Decline and Fall of the American Programmer, 1993), que aunque no hay un slo desarrollo que sea la "bala de plata", s se pueden ver varios aspectos que juntos pueden dar ese incremento en orden de magnitud. En particular, l da nfasis en la cuestin humana ("peopleware"), proceso de software, tecnologa de objetos, reuso y mtricas de software. Estos temas han sido tratados por mltiples autores, algunos ms optimistas que otros. Considerando que es inevitable seguir desarrollando software, veamos qu se puede hacer. Analicemos en el resto de la introduccin de este libro los aspectos ms relevantes en la actualidad, del software orientado a objetos (Captulo 2) y del proceso de software (Captulo 3).

Weitzenfeld: Captulo 2

2 Tecnologa Orientada a Objetos

Dado que un aspecto primordial de este libro es el software orientado a objetos es entonces necesario comprender que significa esta tecnologa. Comenzamos discutiendo brevemente cuales son los mitos y cuales las realidades con esta tecnologa. Continuamos describiendo los aspectos bsicos que distinguen a la programacin orientada a objetos con respecto a la manera tradicional de programacin. El resto del captulo describir la motivacin, y conceptos detrs de esta tecnologa junto con una breve resea de los ms importantes lenguajes orientados a objetos. 2.1 Mitos y Realidades La orientacin a objetos es un buen ejemplo de cmo un pequeo detalle puede significar tan crtico, algo similar a la famosa frase de Neil Armstrong cuando pis la luna: Un pequeo paso para un hombre, un gran paso para la humanidad. Sin exagerar con la similitud analicemos qu significa este pequeo paso tecnolgico que tanto ha significado para el desarrollo de software. 2.1.1 Programacin Tradicional En la programacin tradicional, conocida como estructurada, es separar los datos del programa de las funciones que los manipulan. El programa o aplicacin completa, consiste de mltiples datos y mltiples funciones, como se muestra en la Figura 2.1.

Datos

Funciones
Figura 2.1 Programacin estructural: datos y funciones globales. Esta forma de programar tiene sus orgenes en la arquitectura von Neumann de las primeras computadoras modernas. La arquitectura bsica es la misma utilizada en la actualidad a nivel comercial en las PCs y se basa de manera simplificada en una unidad central de procesamiento (CPU) y una memoria donde se carga el programa o aplicacin que debe ejecutarse. (El disco duro guarda a largo plazo la aplicacin para que sta no se pierda pero no juega un papel primordial cuando la aplicacin se ejecuta.) La memoria en s se divide en una seccin donde se guardan las funciones del programa, correspondiente al cdigo que controla la lgica de la aplicacin, y otra seccin de datos donde se guarda la informacin que quiere manipularse. Dada esta separacin entre funciones y datos en la memoria lo ms lgico siempre ha sido utilizar una programacin que se ajustara a ello dando origen a un gran nmero de lenguajes basados en esta estructuracin. Esta manera de programar tiene dos problemas principales. El primer problema es obligar a un programador a pensar como la mquina, en lugar de lo opuesto. El segundo problema es que toda la informacin presente es conocida y potencialmente utilizada por todas las funciones del programa y si se hiciera algn cambio en la estructura de alguno de los datos (se consideran todos como globales), potencialmente habra que modificar todas las funciones del programa para que stas pudieran utilizar la nueva estructura. Que tan problemtico pudiese ser esto? Pues que mejor ejemplo que el problema del ao 2000 donde un dato tan insignificante como la fecha, que al cambiarse de dos a cuatro dgitos result en costos mundiales de cerca de $1 trilln de dlares. Lo que empeor las cosas fue que todos estos programas tenan miles de funciones donde cada una de ellas requera de la fecha para funcionar correctamente, cmo en el caso de aplicaciones bancarias y nminas de compaas. 2.1.2 Programacin Orientada a Objetos Cmo puede ayudarnos la orientacin a objetos a solucionar los dos problemas principales de la programacin tradicional? La respuesta es que la orientacin nos ayuda a mejorar radicalmente ambas situaciones gracias a que la unidad bsica de programacin es el objeto. A nivel organizacional el concepto del objeto nos acerca ms a la manera de pensar de la gente al agregar un nivel de abstraccin adicional donde internamente la estructura del programa se ajusta a la arquitectura de la mquina. En relacin al segundo problema, los datos globales desaparecen, asignando a cada objeto sus propios datos y funciones locales, resultando en un programa o aplicacin definido exclusivamente en trmino de objetos y sus relaciones entre s, como se muestra en la Figura 2.2.

Weitzenfeld: Captulo 2

Objeto Objeto

Objeto
Figura 2.2 Programacin orientada a objetos: objetos globales. Obviamente debemos tener datos y funciones para que un programa tenga sentido, pero estos son guardados en cada objeto de manera independiente, como se muestra en la Figura 2.3.
Objeto
Funciones

Datos

Figura 2.3 Programacin orientada a objetos: objetos globales que contienen datos y funciones locales. Ntese en el diagrama, que los datos estn ubicados en el centro del objeto (un concepto puramente ilustrativo) resaltando el efecto de que un cambio en la estructura de uno de estos datos slo afecta a las funciones del mismo objeto pero no al resto de la aplicacin. Todo lo relacionado al detalle de los objetos junto con sus datos y funciones ser descrito en el Captulo 4. 2.1.3 El Problema del Ao 2000 Revisado Cules hubieran sido las consecuencias del problema del ao 2000 si todas esas aplicaciones hubiesen sido programadas mediante la programacin orientada a objetos. La fecha como tal no hubiese sido un dato sino un objeto y aunque el objeto Fecha hubiese contenido originalmente dos en lugar de cuatro dgitos, el resto de la aplicacin se relacionara nicamente con el objeto Fecha como se muestra en la Figura 2.4.

Objeto Objeto

Fecha
Figura 2.4 El objeto "Fecha" como ejemplo de un objeto.

Weitzenfeld: Captulo 2

Llegando el ao 2000 donde se reconoce la deficiencia de los dos dgitos se habra cambiado la estructura interna de los datos del objeto Fecha a cuatro dgitos solamente afectando las funciones internas encargadas de manipular los datos internos del objeto Fecha, como se muestra en la Figura 2.5.
Funciones Datos de 2 dgitos Funciones Datos de 4 dgitos

Fecha (2) Fecha (4) Figura 2.5 Extensin de la estructura de dato de "Fecha" de 2 a 4 dgitos. El resto de la aplicacin nunca se hubiera enterado y el diagrama mostrado en la Figure 2.4 hubiese sido idntico. Como consecuencia el mundo se hubiera ahorrado $1 trilln de dlares! Un cambio insignificante para un programa pero repercusiones brutales para la humanidad. Por supuesto que an con tecnologa orientado a objetos, un mal diseo no hubiese solucionado el problema, aunque el desafo para lograr malos diseos es mayor!

2.2 Programacin Orientada a Objetos El software orientado a objetos apoya ciertos aspectos que mejoran la robustez de los sistemas, este software requiere de ciertas caractersticas mnimas para considerarse orientado a objetos y finalmente debe integrarse como parte de un lenguaje de programacin. Estos temas son descritos a continuacin. 2.2.1 Aspectos que Mejoran la Robustez de los Sistemas Existen razones un poco ms tcnicas que motivan a la orientacin a objetos, como son la abstraccin, modularidad, extensiblidad y reutilizacin. ? ? Abstraccin. Una de las consideraciones ms importantes para tratar el problema de la complejidad del software es el concepto de abstraccin. La idea bsica de la abstraccin es reducir el nivel de primitivas o representaciones bsicas necesarias para producir un sistema de software. De manera sencilla esto se logra mediante el uso de lenguajes de programacin que contengan estructuras de datos de alto nivel. En otras palabras, la pregunta opuesta sera: por qu no programar en cdigo binario, o sea 0s y 1s ? La respuesta es que ninguna persona sera capaz de comprender una aplicacin al verse el cdigo y por otro lado requerira de programas extremadamente extensos para representar la aplicacin completa dada la simplicidad de la primitiva bsica. Los sistemas de software construidos con lenguajes de programacin de ms alto nivel reducen el nmero total de lneas de cdigo por lo tanto reducen su complejidad. Con la programacin orientada a objetos se definen dos niveles de abstraccin. El nivel ms alto, el de los objetos, es utilizado para describir la aplicacin mientras que el nivel ms bajo, el de los datos y las funciones, es utilizado para describir sus detalles. Este nivel inferior corresponde al nico nivel de la programacin tradicional. Esto refleja que la complejidad se maneja de mejor manera con la tecnologa orientada a objetos. En general cuanto ms podamos simplificar las tareas de desarrollo mejor ser el manejo de la complejidad. Por otro lado el objeto como estructura bsica sirve para separar el que de una aplicacin del como, o sea sus detalles, al contrario de la programacin tradicional donde el que y el como se resuelven a la vez. ? ? Modularidad. Otro aspecto importante de una aplicacin es su modularidad. La modularidad de un sistema depende de sus abstracciones bsicas, lo cual permite dividir el sistema en componentes separados. Al tener abstracciones de mayor nivel la modularidad de los componentes tambin es de mayor nivel reduciendo el nmero final de componentes lo cual a su vez simplifica su manipulacin y mantenimiento. Con la orientacin a objetos, la modularidad del sistema se da en base a objetos, un nivel ms alto que los datos y funciones tradicionales. El nmero final de mdulos, o sea objetos, es menor que el nmero original de datos y funciones. Esto reduce la complejidad de la aplicacin ya que el programador piensa en menos componentes a la vez descartando detalles innecesarios. ? ? Extensibilidad. En general, los sistemas de software tienden a ser modificados y ampliados durante el transcurso de su vida. Como se mencion en el Captulo 1, la Ley de Lehman dice que todo programa que se use se modificar. O sea, si un programa no se modifica es porque nadie lo quiere usar, por lo cual uno se pregunta: que tan larga es la vida de un sistema? En otras palabras, cundo se vuelve ms costoso mantener un sistema de software que desarrollar uno nuevo? La extensibilidad tiene como objetivo permitir cambios en el

Weitzenfeld: Captulo 2

sistema de manera modular afectando lo mnimo posible el resto del sistema. Con la orientacin a objetos, los cambios se dan a dos niveles: modificacin externa e interna de los objetos. Los cambios internos a los objetos afectan principalmente al propio objeto, mientras que los cambios externos a los objetos afectarn de mayor forma al resto del sistema. Dada la reduccin en el nmero de entidades bsicas en un sistema mediante abstracciones de nivel ms alto, se logra un desarrollo de sistemas ms estables con menor complejidad, y por lo tanto ms fcilmente extensibles. ? ? Reutilizacin. Una de las maneras de reducir la complejidad del software es mediante la reutilizacin o reuso de partes existentes. La pregunta que uno se hace es: cunto puedo reutilizar del cdigo y sistemas ya existentes? El reuso de cdigo reduce el tiempo del diseo, la codificacin, y el costo del sistema al amortizar el esfuerzo sobre varios diseos. El reducir el tamao del cdigo tambin simplifica su entendimiento, aumentando la probabilidad de que el cdigo sea correcto. Mediante el reuso de cdigo se puede aprovechar componentes genricos para estructurar bibliotecas reutilizables, y as lograr una estandarizacin y simplificacin de aplicaciones por medio de componentes genricos prefabricados. Tradicionalmente, los componentes o libreras de software han existido por muchos aos como procedimientos y funciones, particularmente para aplicaciones numricas y estadsticas. Y aunque el reuso es posible en lenguajes convencionales, los lenguajes orientados a objetos aumentan substancialmente las posibilidades de tal reuso, gracias a la modularidad de los sistemas. En particular, lenguajes como Java ofrecen componentes de estructuras de datos bsicas como colas, pilas, listas, rboles, junto con aquellas de ms alto nivel, utilizadas por ejemplo para la construccin de interfaces de usuario facilitando el desarrollo de nuevas aplicaciones. La problemtica mayor de la reutilizacin radica en que para construir componentes genricos, sencillos, con interfaces bien definidas y que puedan utilizarse en varias reas de aplicacin el esfuerzo es mucho mayor que para construir componentes que sern utilizados en una aplicacin. Con la orientacin a objetos, el objeto es la unidad de reuso ms pequea, pudindose aprovechar definiciones similares de objetos dentro de la misma aplicacin o incluso en distintas aplicaciones. Al agrupar objetos similares se puede lograr reutilizacin de componentes de ms alto nivel. Por otro lado, se puede aprovechar objetos con estructuras de datos y funciones similares, definiendo una sola vez los aspectos comunes y especializndolos en objetos adicionales. A un nivel ms amplio existen los marco de aplicacin (frameworks) donde una aplicacin genrica en un dominio particular se especializa para diferentes ambientes, algo promovido con diferente xito por compaas como SAP y PeopleSoft. Al definir una aplicacin en trminos suficientemente abstractos o generales, se puede en teora especializar su comportamiento sin tener que hacer ningn cambio en la estructura bsica de los componentes y de la propia aplicacin. Esto extendera de manera radical la utilidad de la aplicacin. Esto sera el elixir de la ingeniera de software, lograr crear nuevas aplicaciones sin escribir una sola lnea de cdigo, solamente integrando componentes ya existentes, como en la construccin de casas o puentes prefrabricados. Dado que es difcil lograr grandes niveles de reutilizacin sin contar con niveles intermedios, se ha realizado un esfuerzo muy importante conocido como Patrones de Diseo (Design Patterns), algo que discutiremos con mayor detalle en el captulo de diseo. 2.2.2 Caractersticas Mnimas de los Lenguajes Orientados a Objetos En la seccin anterior mencionamos la motivacin detrs de la orientacin a objetos: lograr mayor productividad en el desarrollo de software y mejorar la calidad de ste mediante niveles ms altos de abstraccin, apoyo a la modularidad, extensiblidad y reutilizacin de cdigo. En esta seccin describimos los conceptos bsicos que hacen que un lenguaje sea considerado efectivamente orientado a objetos. En general, cuatro aspectos deben existir en tal lenguaje: encapsulamiento, clasificacin, generalizacin y polimorfismo. En esta seccin nicamente introducimos los conceptos, los cuales sern descritos en mucho mayor detalle y ejemplos en el Captulo 4. ? ? Encapsulacin. Encapsulacin o encapsulamiento es la separacin de las propiedades externas de un objeto, o sea su interface, correspondiente a la interface de sus funciones, de los detalles de implementacin internos del objeto, o sea sus datos y la implementacin de sus funciones, como se muestra en la Figura 2.5. Esta separacin es muy importante. Si nos referimos al diagrama de la Figura 2.2, realmente el conocimiento de un objeto por otros objetos en la misma aplicacin es exclusivamente en base a la interface de dichos objetos. Todo el detalle, al estar encapsulado, es desconocido por el resto de la aplicacin, limitando el impacto de cualquier cambio en la implementacin del objeto, ya que los cambios a las propiedades internas del objeto no afectan su interaccin externa. Obviamente cualquier cambio en la propia interface del objeto afectara potencialmente a todo el resto de la aplicacin. Sin embargo el porcentaje de cdigo dedicado a las interfaces es por lo general muchsimo menor que el porcentaje total de lneas de cdigo utilizados para datos e implementacin de funciones. De tal manera se reduce la complejidad del sistema protegiendo los objetos contra posibles errores, y permitiendo lograr de mejor manera extensiones futuras en la implementacin de los objetos.

Weitzenfeld: Captulo 2

Interface Funciones Implementacin Funciones

Datos

Figura 2.5 Un objeto da a conocer a los dems objetos slo las interfaces de sus funciones. Clasificacin. En todo programacin orientada a objetos la clasificacin es un aspecto fundamental, donde objetos que contienen estructuras similares, correspondiente a tipos de datos y funciones similares, se clasifican como pertenecientes a la misma clase de objeto. Ntese de que hablamos de tipos de datos similares, dado que los valores de los datos an pueden cambiar en objetos de clase similar. Si todos los valores de los datos tuvieran que ser tambin iguales entonces todos los objetos de una misma clase seran idnticos, algo que limitara el alcance de la clasificacin adems de ser muy aburrido! ? ? Generalizacin. Si tomamos como base la clasificacin, y consideramos que no slo los objetos similares pueden clasificarse, sino tambin las propias clases de los objetos, entonces se define la generalizacin o especializacin de clases. Mediante la generalizacin, clases de objetos con estructura y comportamiento similar se reutilizan en la definicin de las nuevas clases. Estas nuevas clases se consideran clases ms especializadas o subclases mientras que las originales se consideran clases ms generales o superclases. El mecanismo para describir jerarquas de generalizacin de clases se conoce como herencia, un trmino muy utilizado en la orientacin a objetos, se dice que una subclase hereda de una superclase. La herencia puede ser sencilla, donde una subclase hereda de una sola superclase directa, o mltiple, donde una subclase hereda de mltiples superclases directas. La herencia es tambin una forma de reutilizacin de cdigo, ya que se aprovechan descripciones de clases de objetos para luego definir clases de objetos parecidos. ? ? Polimorfismo. Quizs el concepto ms complicado de explicar y en cierta manera el ms poderoso es el polimorfismo. De manera simplificada, mediante el polimorfismo se definen funciones con el mismo nombre e interfaz en distintas clases de objetos, pero bajo implementaciones distintas. Para qu sirve entonces el polimorfismo? Sin adelantarme a las explicaciones ms detalladas que vendrn en el Captulo 4, el polimorfismo es til para extender la funcionalidad existente en los objetos del sistema, a nuevos objetos an desconocidos en ese momento. Es como definir un estndar de interfaces para los objetos la cual debe ser seguida por todos los existentes y nuevos. Haciendo una analoga, todo el tiempo aparecen nuevas aplicaciones de software que pueden ejecutarse en sistemas ya existentes. Para que todo funcione correctamente el diseador del nuevo software debe mantener un estndar en las interfaces de sus funciones que sea ya conocida y aceptada aunque la implementacin de las funciones sea obviamente distinta. Nuevamente, esto es un ejemplo de cmo necesidades actuales en los sistemas pueden ser apoyado de mejor manera mediante nueva tecnologa que ayude a mejorar los diseos aunque no garantiza el resultado final. 2.2.3 Lenguajes de Programacin Los lenguajes orientados a objetos varan en su apoyo a los conceptos de orientacin a objetos y en los ambientes de desarrollo que incorporan. Por lo general, cada lenguaje, aunque orientado a objetos, tiene un diseo particular teniendo aspectos comunes entre si. El usuario debe considerar los distintos aspectos y tomar una decisin de cual es el lenguaje ms apropiado para su aplicacin. En general, el lenguaje que utilizaremos en este libro es Java por tres motivos principales: su integracin con el Web, sus buenas caractersticas como lenguaje de programacin y su gran aceptacin en el mercado que lo hacen uno de los ms utilizados en la actualidad. No sera completa una descripcin de la programacin orientada a objetos sin mencionar algunos de los lenguajes de programacin ms importantes. Considerando que existen lenguajes de programacin orientados a objetos ya desde hace varias dcadas sera bueno revisar brevemente la historia de estos lenguajes, como se muestra en la Tabla 2.1, en orden cronolgico. (Ntese que a partir de la dcada de los 80 la gran mayora son orientados a objetos.) ?? Ao 1957 Lenguaje FORTRAN Descripcin FORmula TRANslator fue el primer lenguaje de alto nivel y an sigue OO? No

Weitzenfeld: Captulo 2

1959

LISP

1959

COBOL

1960

ALGOL

1962

SIMULA

1962

PL/I

1962

APL

1964

BASIC

1968

Pascal

1972

Smalltalk

siendo el ms utilizado para clculos numricos. Fue diseado originalmente por John Backus entre 1954 y 1957. La versin actual es FORTRAN-90. Lisp fue diseado por McCarthy entre 1956 y 1961. Existen diferentes extensiones, conocidas hoy en da como CommonLisp. El lenguaje se utiliza principalmente para aplicaciones en Inteligencia Artificial. En un esfuerzo por hacer de LISP un lenguaje ms moderno, ste se extendi en 1988 con orientacin a objetos dando lugar a CLOS ("Common LISP Object System"). COmputer Business Oriented Language fue un lenguaje diseado a partir de 1959 por un grupo de profesionales conocidos como CODASYL (COnference on DAta SYstems Languages) y fue creado para aplicaciones principalmente financieras. Este lenguaje es el principal culpable del problema del milenio. La versin ms reciente es COBOL-97 conteniendo incluso extensiones de orientacin a objetos. ALGOrithmic Language fue desarrollado por J. Backus y P. Naur entre 1958 y 1960. Se le considera el primer lenguaje de propsito general para aplicaciones tanto industriales como cientficas. La ltima versin fue Algol68. El primer sistema con objetos fue B1000 en 1961, seguido por Sketchpad en 1962, conteniendo clones e instancias. Sin embargo, se le atribuye como el primer lenguaje orientado a objetos conteniendo objetos y clases, a Simula I, diseado por Ole Dahl y Kristen Nygaard del Centro de Computacin de Noruega (NCC Oslo) en 1962. El lenguaje, implementado por primera vez en 1964, fue diseado como una extensin a Algol 60 para la simulacin de eventos discretos. En 1967, se introdujo el lenguaje de propsito ms general Simula67 con un nmero mayor de tipos de datos adems de apoyo a objetos. Simula se estandariz en 1977. Programming Language 1 fue un lenguaje bastante complejo inventado en IBM a partir de 1962 para su famosos System/360. PL/I quera ser el lenguaje para los sistemas grandes y aplicaciones. Fue utilizado principalmente en la dcada de los 80s. "A Programming Language" fue diseado por Ken Iverson a partir de 1962 y utilizado por IBM. El objetivo principal era programar matemticamente. Inclua letras griegas, siendo un lenguaje extremadamente compacto. La versin actual es APL2. Este famoso lenguaje fue inventado por los profesores John G. Kemeny y Thomas E. Kurtz de la Universidad de Dartmouth, Estados Unidos. El primer programa de BASIC fue ejecutado el 1 de Mayo de 1964. Los dialectos ms modernos incluyen, a partir de 1991, VisualBasic diseado por Microsoft (reminicencias de su primer negocio en 1975 vendiendo interpretadores de Basic!) Este famosos lenguaje fue diseado por Niklaus Wirth del Instituto Tecnolgico Federal de Zurich entre 1968 y 1971. Pascal evolucion el diseo de Algol siendo por muchos aos el lenguaje para la enseanza de la introduccin a la programacin en las diversas universidades. Las versiones ms reconocidas posteriormente fueron promovidas por la compaa Borland con TurboPascal, y luego ObjectPascal en su ambiente de desarrollo Delphi, actualmente muy utilizado. Smalltalk diseado por Alan Kay (quien haba diseado y construido entre 1967 y 1968 la primera computadora personal basada en programacin orientada a objetos, llamada FLEX) y otros en XEROX PARC. La primera versin fue conocida como Smalltalk 72, cuyas races fueron Simula 67. Sigui Smalltalk 76, una versin totalmente orientada a objetos. En 1980, Smalltalk 80, fue la primera versin comercial del lenguaje, incluyendo un

No

No

No

No

No

No

No

Weitzenfeld: Captulo 2

1972

Prolog

1972

1977

CLU

1980

Modula

1983

Ada

1983

Objective-C

1983

Beta

1984

ML

1985

C++

ambiente de programacin orientado a objetos uniforme. El lenguaje Smalltalk ha influido sobre otros lenguajes como C++ y Java, y aunque no ha tenido el grado de xito de estos dos ltimos, quizs por lo tardo en volverse gratis junto a razones de eficiencia, este lenguaje tiene un gran nmero de seguidores en la actualidad, los cuales consideran a Smalltalk como el mejor lenguaje que existe. PROgramming in LOGic fue el progenitor de la programacin lgica. Fue diseado por Robert A Kowalski de la Universidad de Edinburgo, Reino Unido, y Alain Colmerauer de la Universidad de Aix-Marseille, Francia. C fue diseado por Ritchie y Thompson entre 1969 y 1973, en paralelo con los primeros desarrollos del sistema operativo Unix. Otra etapa del desarrollo fue hecha por Kernighan y Ritchie entre 1977 y 1979, cuando la portabilidad de Unix era demostrada. En esa poca se escribi el famoso libro The C Programming Language [Kernighan y Ritchie, 1978]. Es uno de los lenguajes de mayor utilizacin en la actualidad. "CLUster" es un lenguaje diseado por Barbara Liskov del MIT entre 1974 y 1977. El lenguaje utiliza conceptos bsicos de la orientacin a objetos aunque no es propiamente considerado como tal. La versin original se conoci como Modula-2 desarrollada por Niklaus Wirth diseada a mediado de los 70s como descendiente director de Pascal. El lenguaje inclua concurrencia y ciertos aspectos de la orientacin a objetos. La ltima versin conocida como Modula-3 fue diseada por Luca Cardelli. Dada su simpleza se desconoce por qu la falta de xito en la utilizacin de este lenguaje. El lenguaje fue diseado a partir de 1977 por el Departamento de Defensa de Estados Unidos, teniendo como autor principal a Jean Ichibah, para apoyar programacin de gran escala y promover la robustez del software. Su nombre fue en honor de Lady Ada Lovelace (1815-1852), una amiga y confidente de Charles Babbage, considerado el padre de la computacin por su trabajo terico hace un siglo y medio. Aunque la versin original no era orientada a objetos, la versin actual Ada 1995 s lo es. Existe otra versin no orientada a objetos conocida como Ada 83 o Ada Clsica. El lenguaje fue diseado por Brad Cox como una extensin a C pero con orientacin a objetos. El lenguaje ofreca muchos aspectos de diseo de Smalltalk-80 como su misma naturaleza sin tipos, aunque incorporaba datos sencillos de C, como enteros y reales. Su popularidad inicial vino a raz de su utilizacin en la computadora NeXT, incluyendo una interfaz de construccion como parte del ambiente NeXTSTEP, conocido luego como OpenStep, y actualmente adquirido por Apple como base para su nuevo sistema operativo MacOS X. Beta, desarrollado por Madsen en la Universidad de Aarhus en Dinamarca es otro lenguaje orientado a objetos inspirado por Simula con sintaxis similar a Pascal y algo parecido a C. Standard ML (Meta Language) representa una familia de lenguajes funcionales propuestas originalmente en 1983 y diseadas entre 1984 y 1988 por Milner y Tofte. La versin actual, Standard ML '97 es una revisin modesta y simplificada del languaje. C++ diseado por Bjarne Stoustrup, AT&T Bell Labs, entre 1982 y 1985 es uno de los lenguajes de programacin ms populares actualmente. El lenguaje se agrega aspectos de orientacin a objetos al lenguaje de C, siendo realmente un lenguaje hbrido donde un programador puede efectivamente programar en C aunque utilizando C++. En la actualidad muchos de los seguidores de este lenguaje se han pasado a Java. La razn primordial de esto es la complejidad de C++ junto con muchos aspectos

No

No

No

No

Weitzenfeld: Captulo 2

problemticos y falta de estandarizacin bajo distintas plataformas. S Eiffel, honrando a la famosa torre en Pars, fue diseado por Bertrand Meyer como un lenguaje orientado a objetos con una sintaxis superficialmente similar a C. Eiffel ofrece un ambiente interpretado de bytecode similar a Java, aunque por eficiencia este cdigo normalmente se traduce a C para luego ser compilado en el ambiente particular. El diseo del lenguaje apoya un enfoque de ingeniera de software conocido como Diseo por Contrato. Aunque es un lenguaje muy sencillo y poderoso nunca logr la aceptacin lograda por C++ y Java, posiblemente por la falta de compiladores gratis. S 1986 Self Self diseado por David Ungar y Randall Smith es un lenguaje cuya sintaxis es similar a Smalltalk. Un aspecto muy novedoso es la omisin de la nocion de clase en el lenguaje, donde un objeto se deriva de otro (su prototipo) por medio de copiado y refinado. Dado esto, Self es un lenguaje muy poderoso, sin embargo, es an un proyecto de investigacin requiriendo una gran cantidad de memoria y una gran mquina para ejecutar. 1988 CLOS CLOS ("Common LISP Object System") es una extensin de CommonLisp S mediante la orientacin a objetos desarrollada originalmente en 1988 por David Moon (Sumbolics), Daniel Bobrow (Xerox), Gregor Kiczales (Xerox) y Richard Gabriel (Lucid), entre otros. S 1990 Haskell Haskell desarrollado por un comit (Hughes, Wadler, Peterson y otros) tiene su nombre en honor a Haskell Brooks Curry, cuyo trabajo en lgica matemtica sirve como fundamento para los lenguajes funcionales. El lenguaje est altamente influenciado por Lisp aunque fue extendido con ciertos aspectos de la orientacin a objetos para ser ms moderno. S 1992 Dylan Dylan ( DYnamic LANguage es un lenguaje orientado a objetos ) originalmente desarrollado por Apple, se parece mucho a CLOS y Scheme, aunque ha sido influenciado por Smalltalk y Self. S 1995 Java Java, diseado por Gosling en Sun Microsystems entre 1994 y 1995 es el lenguaje orientado a objetos ms utilizado en la actualidad. El lenguaje es sencillo y porttil, bastante similar a C++, aunque tomando ideas de Modula-3, Smalltalk y Objective-C, hacindolo ms robusto y seguro. Java es tpicamente compilado en bytecodes que son luego interpretados por una mquina virtual de Java (JVM). Un aspecto primordial en el xito del lenguaje es su integracin con el Web mediante aplicaciones conocidas como applets que pueden ser ejecutadas desde un navegador del Web (browser). Otro aspecto importante es la inclusin de un gran nmero de paquetes y libreras que estandarizan y facilitan el desarrollo de nuevos programas. 2000 C# Este lenguaje conocido como C Sharp es el ltimo intento por parte de S Microsoft de competir contra el xito y el seguimiento que tiene Java. El lenguaje revisa muchos aspectos problemticos de C++. Tabla 2.1 La tabla describe los lenguajes ms importantes de la historia de la computacin haciendo nfasis en aquellos orientados a objetos.. 1986 Eiffel

Introduccin

10/11/2002

Weitzenfeld: Captulo 3

3 El Proceso para el Desarrollo de Software

Un proceso est definido como una serie de acciones u operaciones que conducen a un fin. En general, una empresa u organizacin requiere de uno o ms procesos para lograr sus objetivos, los cuales por lo general involucran la utilizacin de sistemas de software. En el caso de una empresa que se dedica al desarrollo de software, se requieren procesos que abarquen desde la creacin de un sistema de software hasta su mantenimiento. Todo esto es conocido como el ciclo de vida del software. Como hemos visto en el Captulo 1, el desarrollo de sistemas de software es algo muy complejo. De lo contrario todos haramos siempre software perfecto! Un aspecto bsico para manejar la complejidad inherente en los sistemas de software es contar con un modelo de proceso a seguir, como se discutir en el resto del captulo. 3.1 Modelo del Proceso El modelo de proceso define un orden para llevar a cabo los distintos aspectos del proceso. El modelo se puede definir como un grupo de estrategias, actividades, mtodos y tareas, que se organizan para lograr un conjunto de metas y objetivos. El modelo de proceso abarca aspectos como la planeacin, autoridad, prediccin, evaluacin y rastreabilidad (traceability). ? ? La planeacin involucra definir cmo se llevarn a cabo las diversas etapas del proceso sin limitarse a aspectos de desarrollo si no tambin por ejemplo, los organizacionales. ? ? La autoridad define cmo se puede influir para llegar a donde se quiere. ? ? La prediccin describe a donde se va a llegar. ? ? La evaluacin describe donde se encuentra el proceso actualmente. ? ? La rastreabilidad describe cmo se logr un resultado particular. En particular, el proceso de desarrollo es considerado como un conjunto de personas, estructuras organizacionales, reglas, polticas, actividades, componentes de software, metodologas y herramientas usadas o creadas especficamente para conceptualizar, desarrollar, ofrecer un servicio, innovar o extender un producto de software, es decir la forma en que la organizacin realiza sus distintos proyectos de generacin de software. Los modelos de proceso varan mucho entre s y dependen de las diversas opiniones o mximas generales en las cuales se basan [Goldberg & Rubin 1995], donde obviamente cada persona puede tener una opinin distinta al respecto. Por ejemplo algunas creencias en el desarrollo de software son: ? ? Es mejor comprender el problema antes de desarrollar una solucin. ? ? El proceso para resolver un problema debe dar un resultado predecible, sin importar del individuo que hace el trabajo. ? ? Debe ser posible planear y calcular el proceso con gran precisin. ? ? Evaluar y administrar el riesgo es importante para el xito del proceso. ? ? Etapas bien definidas con entregas intermedias aumentan la confianza que se tiene en el resultado final. En general, todas las creencias luego actan como base para definir las estrategias, actividades, mtodos, y tareas del modelo de proceso. Estos conceptos se describen a continuacin. ? ? Una estrategia es un plan para llevar a cabo un objetivo, en nuestro caso el desarrollo de software. Existen diversas estrategias para lograr mejor calidad en el software final. Una estrategia bsica se relaciona con el tipo de arquitectura que se desea crear, por ejemplo, utilizando elementos sencillos como bloques y componentes o como elementos prefabricados de ms alto nivel. Esta arquitectura puede incluso integrar diversos niveles de sofisticacin en los elementos. Las estrategias bsicas escogidas afectan directamente el tipo de programacin y los lenguajes que se utilizarn. En cierta manera, para este libro ya hemos definido nuestra estrategia bsica de desarrollo de software, la cual es el uso de tecnologa orientada a objetos, en particular usando el lenguaje Java. Sin embargo, an dentro esta estrategia de orientacin a objetos puede refinarse an mas. (Obviamente, se puede utilizar una estrategia distinta, incluso que no sea orientada a objetos.) La estrategia no slo afecta la arquitectura del sistema sino tambien cmo se llevarn a cabo las actividades del proceso. Mientras no se tengan conflictos, es posible combinar mltiples estrategias, donde las distintas actividades del proceso de software pueden hacerse bajo estrategias diferentes, definiendo implcitamente la estrategia global del modelo de proceso. Dos estrategias importantes son el uso de prototipos y reutilizacin. Hablaremos de esto ms adelante. ? ? Una actividad es una unidad o paso organizacional para llevar a cabo cierto aspecto de un proceso. En nuestro caso las actividades definen los distintos pasos necesarios para lograr las metas y objetivos definidos en el modelo de proceso, o sea en el desarrollo de software. Las actividades dependen de la arquitectura de software y deben ser simples de aprender y usar; deben simplificar la comprensin del sistema, deben ser suficientemente

Weitzenfeld: Captulo 3

poderosas para expresar la informacin requerida para modelar el sistema, deben ser lo suficientemente descriptivas para poder discutir el sistema sin ambigedades y deben proveer un modelo evolucionable del sistema. Las actividades bsicas necesarias para el proceso de desarrollo de software son las siguientes: (i) requisitos para capturar los aspectos funcionales correspondientes, cmo un usuario interactuara con el sistema; (ii) anlisis para dar al sistema una estructura robusta y extensible bajo un ambiente de implementacin ideal; (iii) diseo para adoptar y refinar las estructuras al ambiente de implementacin particular; (iv) implementacin para codificar el sistema; (v) pruebas para validar y verificar el sistema; (vi) integracin para pegar componentes del sistema; (vii) documentacin para describir los distintos aspectos el sistema y (viii) mantenimiento para extender la funcionalidad del sistema. ? ? Un mtodo es un procedimiento definiendo las tareas que deben llevarse a cabo para satisfacer la actividad. Existen mtodos, por ejemplo, para asegurar la calidad del software, seguir el progreso del proyecto y probar el software. Durante el anlisis, el mtodo debe ayudar en la identificacin de los objetos necesarios para la arquitectura del sistema. Anlisis estructurado y anlisis orientado a objetos son ejemplos de diferentes mtodos para hacer anlisis, cada uno con sus propias tareas. Una metodologa se refiere al estudio de los mtodos, existiendo un gran nmero de metodologas para el desarrollo de software. En general, distintas metodologas llevan a cabo las actividades del desarrollo de software de diferente manera. En este libro buscamos aplicar las metodologas ms evolucionadas utilizando tecnologa orientada a objetos. En el apndice del libro contrastaremos algunas de estas metodologas. ? ? Una tarea es un grupo relacionado de acciones contribuyendo a una accin mayor. Cada mtodo define un conjunto de tareas a llevarse a cabo para lograr los objetivos deseados. La tarea puede incluir condiciones de entrada y de salida que sern satisfechas antes y despus de su realizacin. Existen procesos de acuerdo al tipo de proyecto como se ver en la Seccin 3.1.1 y aunque no hay lmite a los diversos modelos de proceso que puedan existir, describiremos los ms clsicos: el Modelo de Cascada en la seccin 3.1.2 y el Modelo de Espiral en la seccin 3.1.3. Cada uno de estos modelos de proceso est definido con un propsito particular y posee distintas estrategias para especificar las diferentes actividades, mtodos y tareas. El tema de la madurez del modelo ser tratada en la seccin 3.1.4. 3.1.1 Procesos Adaptados a Tipos de Proyectos Una creencia comn pero equivocada en la industria del software es que hay un slo modelo de proceso que sirve para todo tipo de proyecto basados en tecnologa orientada a objetos. En general, el modelo de proceso depende del tipo particular de proyecto que se est llevando a cabo. Algunos de estos tipos de proyectos son: ? ? Primer proyecto de su tipo, donde se va a crear la mayora del software desde cero, aunque obviamente se pueden aprovechar componentes genricos para su desarrollo. Por ser la primera vez que se crea este tipo de software, se requiere ms tiempo para analizar el dominio del problema que para otros proyectos. Incluso aunque el dominio del problema sea familiar pudiera ser sta la primera versin de un sistema de software de este tipo. En un primer proyecto en su tipo, la incertidumbre crea riesgos adicionales. ? ? Segundo proyecto en su tipo, donde se busca agregar nueva funcionalidad a un proyecto conocido. El desarrollador tpicamente tiende a excederse agregando demasiada funcionalidad en comparacin al proyecto anterior (featuritis). El sistema se vuelve muchos ms grande que el original significando retrasos en el sistema, como ocurre con muchos de los paquetes comerciales de la actualidad. ? ? Variacin de un proyecto, donde se extiende un sistema ya existente. Esto puede involucrar introducir componentes de software reutilizables como un marco (framework), crear nuevos componentes o simplemente extender la aplicacin existente mediante nueva funcionalidad. Dependiendo de la estrategia particular, el modelo de proceso debe variar. Por lo general, el riesgo en este tipo de proyectos es mucho menor que en los primeros proyectos de su tipo. Lo que se debe hacer ya est definido por la naturaleza del software existente, sin embargo se debe comprender las nuevas extensiones en el software en especial si stos involucran componentes reutilizables. ? ? Proyecto de reescritura de legado (legacy), donde se busca transformar o hacer una reingeniera de un sistema ya existente desarrollado bajo tecnologas anteriores, a un sistema desarrollado bajo nuevas tecnologas, tales como las orientadas a objetos. Este ha sido el enfoque ms importante para tratar el problema del ao 2000. En lugar de remendar sistemas se aprovech para rescribirlos. Como la organizacin ya ha escrito el sistema por lo menos una vez antes, el proyecto de reescritura de legado tiene varias caractersticas en comn con otros modelos, como variacin de un proyecto donde por ejemplo, se incluir actividades para examinar el sistema existente, para extraer requisitos y para comprender la arquitectura anterior. Tambin tiene aspectos comunes con un primer proyecto en su tipo, ya que, se debe crear una nueva arquitectura sin poder contar con

Weitzenfeld: Captulo 3

??

??

software reutilizable del proyecto anterior. Adems, existen todos los riesgos involucrados con un primer proyecto usando una nueva tecnologa. Proyecto de creacin de software reutilizable, donde se busca crear uno o ms componentes de software reutilizables. Este tipo de proyecto es muy similar a otros proyectos de desarrollo de software, siendo necesario comprender requisitos y desarrollar el diseo completo del componente. Sin embargo, es diferente de otro tipo de sistemas, en que los requisitos tienen que considerar las necesidades de mltiples proyectos, asegurando que el diseo es suficientemente general para ser til en otras situaciones desconocidas. Por lo general, esto requiere de esfuerzos mucho mayores que para software no reutilizable, razn por la cual la mayora del software existente no es reutilizable. Proyecto de mejora de sistema o mantenimiento, donde se busca modificar los componentes bsicos de un sistema para apoyar nueva funcionalidad. Tales proyectos a menudo son relativamente pequeos en alcance y no incluyen rescribir componentes o la aplicacin completa. Se debe tener una buena comprensin de los componentes a ser mejorados y cmo estos cambios afectan el resto del sistema.

3.1.2 Modelo Cascada El modelo de cascada clsico data de la dcada de los 60s y 70s (Royce 1970, Boehm 1981). El modelo de cascada se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisin bien definidos (milestones o checkpoints). En su poca de esplendor, este modelo tuvo gran aceptacin en la comunidad de contratistas gubernamentales estadounidenses, ya que stos reciban sus pagos del gobierno en base a entregas basadas en horarios (schedule) predefinidos. El desarrollo de software implicaba una secuencia de actividades a realizarse y cuyo seguimiento era verificar que cada actividad haya sido completada. La ejecucin del modelo era muy lineal, por lo cual el modelo fue sencillo y atractivo; donde se especificaba las actividades para luego hacerlas de principio a fin. Se consideraba que una vez terminada una actividad se continuaba con la siguiente. La Figura 3.1 muestra un diagrama conceptual del modelo describiendo el orden a seguir de las actividades del desarrollo de software. No se muestra una etapa explcita de documentacin dado que sta se llevaba a cabo durante el transcurso de todo el desarrollo.

especificacin de requisitos anlisis diseo implementacin pruebas parciales integracin mantenimiento

Figura 3.1 Diagrama del modelo de cascada. Las siguientes mximas sirven de base para el Modelo de Cascada (Goldberg y Rubin 1995): ? ? Las metas se logran de mejor manera teniendo como fin puntos de revisin bien definidas y documentadas, dividiendo el desarrollo en etapas secuenciales bien definidas. ? ? Documentos tcnicos son comprensibles para usuarios y administradores no-tcnicos, y estos participantes notcnicos pueden comunicarse de forma efectiva durante las diversas actividades. Cada detalle sobre los requisitos puede conocerse de antemano antes de desarrollarse el software, y estos detalles son estables a travs del desarrollo. ? ? Pruebas y evaluaciones pueden llevarse a cabo eficientemente al final del desarrollo. El modelo de cascada fue inicialmente bien recibido ya que identificaba etapas razonables y lgicas para las diversas actividades. Lamentablemente, el modelo no explicaba entre otras cosas cmo modificar un resultado. No exista una gua del por qu y cundo se deba revisar un resultado previo para sus posibles cambios, en especial

Weitzenfeld: Captulo 3

considerando que es extremadamente difcil definir todos los requisitos de un sistema al inicio y que estos se mantengan estables y sin cambios a lo largo del desarrollo. Esta rigidez trajo dudas sobre la utilidad del modelo. La irona en la mayora de los proyectos de desarrollo que usan este modelo es que los administradores no estn de acuerdo con las mximas bsicas, aunque eligen modelos de proceso basados en ellas. A menudo, el requisito de producir entregas intermedias (mayormente documentos) para ser seguidos por financiamiento obliga a seguir este enfoque secuencial, separando drsticamente las actividades, an cuando los administradores crean que otro enfoque sera mejor. Por lo tanto, el modelo de cascada dej de ser utilizado de acuerdo a su definicin original, llevando a los usuarios a utilizar variantes del modelo bsico. Ed Yourdon, en su libro Decline and Fall of the American Programmer (Yourdon 1992), discute los problemas con el Modelo de Cascada: ? ? Los documentos a entregar rigen el proceso de software. ? ? Toma demasiado tiempo ver resultados. ? ? Depende de requisitos estables correctos. ? ? Hace difcil rastrear (ver la dependencia) de los requisitos iniciales y el cdigo final. ? ? Retrasa la deteccin de errores hasta el final. ? ? No promueve el reuso de software. ? ? No promueve el uso de prototipos. ? ? No se practica de manera formal. 3.1.3 Modelo Espiral El modelo de espiral es una modificacin al modelo de cascada desarrollado durante la dcada de los 80s (Boehm 1988). El modelo de espiral se basa en una estrategia para reducir riesgo, al contrario del modelo de cascada que es dirigido por documentos. Como parte del manejo de riesgo el modelo incorpora una estrategia de uso de prototipos, algo muy aceptado en la actualidad. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la identificacin de los objetivos para una parte del producto, formas alternativas de lograr los objetivos, restricciones asociadas con cada alternativa, y finalmente procediendo a una evaluacin de las alternativas. Cuando se identifica incertidumbre, se utilizan diversas tcnicas para reducir el riesgo en escoger entre las diferentes alternativas. Cada ciclo del modelo de espiral termina con una revisin que discute los logros actuales y los planes para el siguiente ciclo, con el propsito de lograr la incorporacin de todos los miembros del grupo para su continuacin. La revisin puede determinar si desarrollos posteriores no van a satisfacer las metas definidas y los objetivos del proyecto. En tal caso, se terminara el espiral. Para utilizar este modelo se debe ser particularmente bueno en identificar y manejar riesgos. La Figura 3.2 muestra un diagrama conceptual del modelo de cascada describiendo los distintos ciclos del espiral. Nuevamente, no se muestra una etapa explcita de documentacin dado que sta se llevaba a cabo durante el transcurso de todo el desarrollo.

diseo

anlisis

versin 1 versin 2 versin 3 lista lista lista

implementacin

pruebas

Figura 3.2 Diagrama del modelo en espiral.

Weitzenfeld: Captulo 3

El modelo de espiral contempla que el desarrollo de sistemas es un proceso de cambios progresivos. Un sistema normalmente se desarrolla mediante cambios en la especificacin de la versin anterior del sistema que son incorporados a nuevas versiones, donde un cambio se conoce como un delta en la especificacin de requisitos o versin. En la Figura 3.3 se ilustra este concepto.
primer ciclo de desarrollo versin 1 versin 1 versin 2

versin n

Figura 3.3 Secuencia de versiones en el modelo de espiral. Aunque modificaciones a sistemas existentes constituyen la mayor parte del costo total durante el ciclo de vida del software, la mayora de los mtodos de desarrollo de software se concentran en nuevos desarrollos, tratando revisiones como algo menor. El modelo de proceso debiera enfocarse en los cambios del sistema. Las mximas del modelo de espiral (Goldberg y Rubin 1995) son: ? ? Una actividad comienza con un entendimiento de los objetivos y riesgos involucrados. ? ? Basado en la evaluacin de soluciones alternas, se usa las herramientas que mejor reduzcan los riesgos. ? ? Todo el personal relacionado debe involucrarse en una revisin que determina cada actividad, planeando y comprometindose a las siguientes actividades. ? ? El desarrollo puede proceder en incrementos en cada etapa, permitiendo prototipos sucesivos del producto. Con algunas variantes, este es el modelo de proceso ms importante en la actualidad. 3.1.4 Modelo Win-Win El modelo Win-Win [Boehm 1998] se basa en el modelo de espiral y da nfasis en la identificacin de las condiciones de ganancia para todas las partes implicadas. Se crea un plan para alcanzar las condiciones ganadoras, determinando los riesgos involucrados. El principal objetivo del modelo es establecer las reglas para la definicin del proceso de desarrollo del proyecto tomando en cuenta a todos los implicados. Son cuatro los ciclos del modelo consistiendo de cuatro actividades principales cada uno: ? ? Definicin de los objetivos del proceso y elaboracin del sistema y subsistemas del producto. ? ? Evaluacin de las alternativas con respecto a los objetivos del proyecto. Identificacin y resolucin de las fuentes principales de riesgo en el proceso de desarrollo de los productos. ? ? Elaboracin de la definicin de los productos y procesos. ? ? Planeacin del siguiente ciclo. Calendarizacin del ciclo de vida del plan, incluyendo la particin del sistema en subsistemas para llevar el proceso en ciclos paralelos. Una vez revisadas las actividades principales, los ciclos manejados en el modelo marcan lneas muy especficas a seguir: Ciclo 0. Aplicacin bsica. Se determina la viabilidad de la plataforma para el desarrollo de la aplicacin. Ciclo 1. Aplicacin de los objetivos del ciclo de vida. Se desarrolla los objetivos del ciclo de vida, incluyendo prototipos, planes, especificaciones de aplicaciones bsicas y verificacin de la existencia de una arquitectura viable para cada capa de la aplicacin. Ciclo 2. Aplicacin de arquitectura del ciclo de vida. Se genera la especificacin del proyecto, detallando la arquitectura del ciclo de vida. Ciclo 3. Capacidad de operacin inicial. Se define el alcance inicial para cada proyecto. Las mximas o creencias del modelo son las siguientes: 1. Crear software basado en componentes para lograr mayor calidad en sistemas de mayor tamao. 2. Escribir software reutilizable para eficientar el proceso de desarrollo. 3. Medir la calidad del sistema como aspecto clave del desarrollo del producto. 4. Lograr mayor calidad en el proceso de ensamblaje a partir de componentes menores. 5. Usar tecnologa basadas objetos como aspecto bsico para lograr la calidad. 6. Poder lograr sistemas ms rpidamente, sencillos, confiables y de calidad a travs de procesos bien definidos.

Weitzenfeld: Captulo 3

7. Utilizar el modelo de espiral como base del proceso. 8. Flexibilizar el proceso de desarrollo del software para lograr los objetivos generales de eficiencia. 9. Involucrar al cliente mediante el manejo de prototipos. 10. Analizar los riesgos en el proceso del desarrollo del software para asegurar la calidad final del sistema. No hay lmite en el alcance o tipo de proyectos donde pueda ser aplicado el modelo Win-Win. No se necesita mucho tiempo de gestin, de forma que se puede utilizar en proyectos pequeos, tanto como proyectos ms grandes. 3.2 Calidad de Software y Madurez del Proceso La calidad de software significa diferentes cosas para distintos grupos. Para la IEEE la calidad de software es el grado en que un sistema, componente o proceso cumple con los requerimientos especificados y con las necesidades o expectativas del cliente o usuario [American National Standard, 1984]. En la definicin de la norma ISO 9000, la calidad de software es el grado (pobre, bueno o excelente) en que un conjunto de caractersticas inherentes del software cumplen con los requisitos. La calidad del software est directamente ligada con el proceso de desarrollo de software. En general, se supone que un proceso bien conocido y ampliamente utilizado, sustentado en medicin y prediccin de eventos, debe permitir controlar en buena medida la produccin de software [De Marco, 1982] y consecuentemente la calidad de estos productos. Sin embargo, la produccin de software sigue siendo compleja y difcil de obtener, aunque se estn haciendo esfuerzos importantes para facilitar la produccin y aumentar su calidad. Uno de los esfuerzos que han logrado mejores frutos es el desarrollo de modelos de madurez del proceso de produccin de software que permite no slo la estandarizacin de la produccin a manera de cualquier otro producto sino el permitir una mejora continua. Una de las principales razones es que los modelos plantean un cambio de cultura de la organizacin y una fuerte inversin en recursos, como son financieros, tecnolgicos y principalmente humanos. La industria del software slo lleva medio siglo, razn por la cual una gran parte de los lderes de proyectos, anlisis, diseadores y desarrolladores de productos siguen trabajando de manera artesanal. Es lamentable ver que no slo empresas pequeas, sino tambin medianas y grandes siguen viendo al software cmo algo difcil de predecir y controlar. Los factores implicados en la obtencin de un producto de calidad: ? ? el cliente/usuario, participante primordial en el proceso de desarrollo del producto y responsable en definir los requisitos del producto final (sistema). ? ? el desarrollador, responsable del proceso de produccin y del aseguramiento de la calidad del producto. ? ? el proceso, (definido anteriormente). ? ? el producto, correspondiente al sistema a ser desarrollado. Todos estos aspectos tienen una estrecha y continua interrelacin que determinan no slo aspectos de la ingeniera del producto, sino tambin la organizacin, soporte y administracin. En general, la organizacin debe primero establecer los estndares, el proceso de desarrollo y el proceso de evaluacin a travs de mtricas bien establecidas, para luego poder lograr mejoras en los productos. La evaluacin de los procesos evita especificaciones incompletas o anmalas, la aplicacin incorrecta de metodologas, etc. [Jones, 1993]. Para ello se utilizan distintos modelos de madurez de procesos que tienen como objetivo apoyar distintas estrategias de desarrollo y evaluacin para as lograr una mejora continua en los productos. Cabe resaltar que no se debe aplicar alguno de estos modelos de madurez bajo el supuesto de mejorar en su calidad sin antes establecer y definir los procesos correspondientes. En particular, la calidad de un sistema de software est gobernada por la calidad del proceso utilizado para desarrollarlo y mantenerlo [Humphrey, 1995]. Por lo general, la calidad en los productos se da a travs del control de los procesos de produccin o procesos de desarrollo. Tomando en cuenta la definicin y medicin de los procesos de desarrollo como paso previo haca una mejora, revisaremos a continuacin los enfoques de los modelos ms conocidos y sus implicaciones. 3.2.1 CMM (Capability Maturity Model) El modelo "clsico" en el tratamiento de la capacidad de los procesos de desarrollo y su madurez es CMM (Capability Maturity Model) del SEI (Software Engineering Institute). CMM tiene como objetivo evaluar los procesos en sus distintos niveles de madurez, identificar los niveles a travs de los cuales una organizacin debe formarse para establecer una cultura de excelencia en la ingeniera de software. El modelo de madurez de procesos fue generado a travs de la experiencia colectiva de los proyectos ms exitosos de software, generando as un conjunto de prcticas importantes que deben ser implantadas por cualquier entidad que desarrolla o mantiene software.

Weitzenfeld: Captulo 3

En particular, CMM es un marco de trabajo especificando guas para organizaciones de software que quieren incrementar su capacidad de procesos, considerando los siguientes puntos: ? ? Identificar fortalezas y debilidades en la organizacin. ? ? Identificar los riesgos de seleccionar entre diferentes contratos y monitorear los mismos. ? ? Entender las actividades necesarias para planear e implementar los procesos de software. ? ? Ayudar a definir e implementar procesos de software en la organizacin a travs de una gua. Los procesos son evaluados a travs de distintos niveles de madurez, que van desde prcticas desordenas o ad-hoc, hasta lograr una mejora continua de procesos y por ende de producto, como se muestra en la Figura 3.4.

Figura 3.4. Los cinco niveles de madurez del proceso de software. Se describe con mayor detalle los niveles de madurez en la Tabla 3.1. Nivel Caractersticas Transicin al siguiente nivel Iniciar una administracin rigurosa del proyecto, y 1 Inicial Ad Hoc, poca formalizacin, asegurar la calidad. junto con herramientas informalmente aplicadas al proceso. Establecer un grupo de proceso y una arquitectura de 2 Repetible Se logr un proceso estable con proceso de desarrollo de software. Introducir mtodos y un nivel repetible de control tecnologas de ingeniera de software. estadstico. 3 Definido Se logr una base para un Establecer un conjunto bsico de administraciones de progreso mayor y continuo. proceso para identificar la calidad y costo de los parmetros y una base de datos del proceso. Juntar y mantener datos del proceso. Calcular la calidad relativa de cada producto e informar a la administracin. 4 Administrado Mejoras sustanciables en calidad Apoyar la recopilacin automtica de datos del proceso. junto con medidas comprensivas Usar datos para analizar y modificar el proceso. del proceso. 5 Optmizado Mejoras en base a mayor calidad Continuar mejorando y optimizando el proceso. y cantidad. Tabla 3.1. Los 5 niveles del modelo de CMM. 3.2.2 ISO-9000 El ISO-9000 (International Standard Organization) En contraste a CMM, la certificacin ISO-9000 para la calidad del software fue adaptada de estndares generales y no incluye mltiples niveles, por lo cual o se est certificado o no se est. La certificacin es equivalente al nivel 3 de la escala de SEI. Se calcula que hasta el ao 1994, aproximadamente el 90% de las organizaciones de USA estaban por debajo del nivel 3. La madurez de los procesos es determinada por las distintas KPA (Key Process Area), es decir por las reas bsicas que componen a las organizaciones y su evolucin. Al definir los procesos se tiene luego la capacidad de repetirlos,

Weitzenfeld: Captulo 3

estandarizarlos en toda la organizacin, predecirlos para luego administrarlos (planificarlos, organizarlos, dirigirlos y controlarlos) y por ltimo optimizarlos continuamente (hacerlos eficientes y eficaces). A pesar de lo anterior, la implementacin de los modelos no ha sido cosa fcil, por ejemplo CMM a pesar de tener casi diez aos de liberado slo cuenta con 60 empresas en todo el mundo han logrado estar en el nivel 5 optimizado a Octubre del 2001 [Software Engineering Community, 2001]. 3.2.3 PSP/TSP El PSP (Personal Software Process) es una tecnologa que tiene como justificacin la premisa de que la calidad de software depende del trabajo de cada uno de los ingenieros de software y de aqu que el proceso diseado debe ayudar a controlar, manejar y mejorar el trabajo de los ingenieros [Humphrey, 1998]. El objetivo de PSP es lograr una mejor planeacin del trabajo, conocer con precisin el desempeo, medir la calidad de productos y mejorar las tcnicas para su desarrollo. La instrumentacin de esta tecnologa consiste en lo que se denomina evolucin del PSP. Se siguen ciertos pasos comenzando con las lneas base PSP0 y PSP0.1, el proceso personal de planeacin PSP1 y PSP1.1, el manejo personal de calidad PSP2 y PSP2.1 y por ltimo el proceso personal cclico PSP3, como se muestra en la Figura 3.5.

Figura 3.5. Los niveles de PSP. PSP0 (i) define el proceso de trabajo personal identificando y ordenando las principales (ii) introduce la recoleccin de datos para medir la productividad y calidad a travs del registro de tiempo y defectos (iii) establece las bases para las mejoras en planificacin de trabajo por tiempos y evaluacin de resultados y (iv) documenta el proceso usando formas especficas. PSP0.1 (i) registra el tamao del producto a travs de puntos funcionales y estandarizacin de la codificacin y (ii) registra los problemas y propuestas de mejora. ? ? PSP1 (i) mejora la planeacin introduciendo la estimacin del tamao del producto y (ii) introduce los reportes de pruebas. PSP1.1 (i) introduce las estimaciones de recursos e (ii) introduce la calendarizacin. ? ? PSP2 (i) introduce las actividades de deteccin temprana de defectos a travs de revisiones de diseo, cdigo y uso de listas de verificacin. PSP2.1 (i) introduce formas para el diseo detallado facilitando as la revisin del diseo. ? ? PSP3 (i) introduce el proceso cclico para desarrollar programas de mayor tamao, (ii) introduce el registro de seguimiento de asuntos y (iii) lleva el resumen de planeacin y registro de tiempo, tamao y defectos por ciclo. El PSP se considera la solucin para pasar rpidamente entre niveles de CMM al lograr un mejor entendimiento de nuestras capacidades y habilidades y un mejor control sobre nuestro trabajo. Sin embargo, PSP tiene el problema de que es implementada a nivel individual. Al momento de la integracin colectiva existen conflictos en el nivel organizativo, por lo cual se defini TSP (Team Software Process). El TSP se concentra en los aspectos del desarrollo de software realizados por equipos de trabajo, definiendo aspectos como la asignacin y control de tareas para los diversos miembros del equipo. ??

Weitzenfeld: Captulo 3

3.2.4 SPICE SPICE (Software Process Improvement and Capability dEtermination) [Dorling, 1995] es un modelo de madurez de procesos internacional. SPICE fomenta productos de calidad, promueve la optimizacin de procesos y facilita la evaluacin del producto a travs de los procesos de desarrollo. SPICE tiene diversos alcances, se aplica tanto a nivel directivo como a nivel de usuarios para asegurar que el proceso se encuentra alineado con las necesidades del negocio, apoya en que los proveedores de software tengan que someterse a una sola evaluacin para aspirar a nuevos negocios y busca que las organizaciones de software dispongan de una herramienta universalmente reconocida para dar soporte a su programa de mejoramiento continuo. SPICE tiene tres caractersticas principales: el marco de valor que contempla una dimensin funcional del procesos, la evidencia para la evaluacin y la recurrencia dada por la seleccin de instancias de proyectos o productos. SPICE est conformado por 9 documentos que permiten instrumentar paso a paso el modelo con su correspondiente evaluacin, como se muestra en la Figura 3.6: ? ? Informacin del modelo - (parte 1) conceptos y gua introductoria, (parte 4) gua para conduccin de aseguramiento, (parte 6) calificacin y entrenamiento de asesores, (parte 7) gua para mejora del proceso, (parte 8) gua para determinar capacidad del proceso de un proveedor y (parte 9) vocabulario general. ? ? Normatividad del modelo - (parte 2) modelo de referencia de procesos y capacidad, (parte 3) realizacin de evaluacin, (parte 5) construccin, seleccin y uso de aseguramiento de instrumentos y herramientas.

Figura 3.6. Componentes del modelo SPICE. El modelo establece un comn denominador para una evaluacin uniforme de los procesos de software, aunque la evaluacin no pretende ser una nueva instancia de certificacin, sino que a travs de los resultados se pretende demostrar lo adecuado del mismo. Al igual que CMM (CMMi - Capability Maturity Model Integrated), SPICE integra una serie de niveles por la que sus procesos debern pasar para obtener cmo resultado final la madurez. Los niveles son: Nivel 0 Incompleto, Nivel 1 Fabricado informalmente, Nivel 2 Planeado, Nivel 3 Bien definido, Nivel 4 Controlado cuantitativamente, y Nivel 5 Mejora continua. Adicionalmente hay una definicin de procesos generales que abarcan a toda la organizacin y a travs de los cules se identifica el cmo lograrlos: Cliente Proveedor CUS, Ingeniera ENG, Administracin MAN, Apoyo o soporte SUP y Organizacin ORG. Los procesos generales son soportados por prcticas especficas que debern cumplirse para lograr un paso de niveles, adems de la estrecha relacin entre los mismos. SPICE hace hincapi en la calidad y actualizacin, as como en la vigencia del producto. Ya que la tecnologa es cambiante, las fases que marca el modelo SPICE son sin duda uno de los pilares en que se tendr que trabajar con la

Weitzenfeld: Captulo 3

10

mayor dedicacin para obtener calidad en el producto y que el servicio del mismo sea excelente, adems de generar la confianza necesaria hacia la direccin y hacia el usuario de donde se obtiene la informacin. 3.2.5 PEMM PEMM (Performance Engineering Maturity Model) [Scholz, 1999] presenta un modelo para evaluar los niveles de integracin, aplicacin, ejecucin y diseo, llamado ingeniera de la ejecucin del modelo de madurez. Al igual que SPICE se apoya en el modelo de madurez de capacidades CMM. El objetivo de PEMM es poder evaluar la Ejecucin de la Ingeniera (EI) as como la integracin del proceso. El modelo sirve tanto para evaluar una organizacin como los propios desarrollos de procesos tecnolgicos especficos. Sirve tambin para definir el criterio al escoger un proveedor de software para los productos crticos o semi-crticos de la compaa. Al igual que el CMM, PENN cuenta con 5 niveles, los cuales determinan la mejora del comportamiento de ejecucin y el decremento del riesgo de ejecucin a travs de estos niveles, como se muestra en la Figura 3.7.

Figura 3.7. Modelo general PEMM. La evaluacin de una compaa se hace a travs de la medicin de aspectos generales, la organizacin, la definicin de procesos de ingeniera, el proyecto de la direccin y la tecnologa, a travs de 34 preguntas, utilizando el mtodo Meta-Pregunta-Mtrico (GQM, Goal Question Metric). GQM se usa para encuestas expertas identificando y midiendo los objetivos a travs de preguntas con respuestas cuantificables (en la actualidad slo ' Si' o ' No'). 3.2.6 TickIt Tick It [Tick It, 1992], desarrollado por el Departamento de Comercio e Industria del Reino Unido, surge por la poca adopcin de las normas internacionales de calidad ISO 9000 para el rea de desarrollo de software. TickIt es primordialmente una gua que presenta las estrategias para lograr la certificacin en la produccin de software a travs de la interpretacin de los estndares ISO. Los objetivos principales de TickIt son, adems de desarrollar un sistema de certificacin aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad, dando la direccin y guas necesarias para tal efecto. El objetivo de certificacin es demostrar que las prcticas necesarias para asegurar la calidad durante el desarrollo de software existen y son verificables [Blackman, 1995]. En general el modelo permite certificar cualquier tipo de proyecto a travs de una estructura ms flexible. La gua de auditoria provee la liga necesaria para que la conformacin (o no) del sistema auditado respecto al modelo TickIt, pueda ser expresada en funcin de los criterios de la ISO 9001, logrando as la aplicacin de esta ltima al desarrollo de software. Finalmente, los requerimientos de experiencia y conocimientos que se piden a los auditores hacen posible la aplicacin del modelo, suponiendo que la experiencia y conocimientos de los auditores no se vean obsoletos frente a prcticas y tcnicas nuevas dentro del medio de desarrollo de software. Esta gua se compone de (i) un captulo de conceptos de calidad, (ii) la norma ISO 9000-3, (iii) una serie de guas para proveedores y compradores, (iv) una gua para la auditoria del sistema de calidad, (v) el proceso de certificacin y (vi) guas complementarias.

Weitzenfeld: Captulo 3

11

3.3 Estrategias Como mencionamos anteriormente, existen mltiples estrategias que afectan el modelo del proceso de software. En esta seccin analizaremos algunas de las ms importantes como son los tipos de tecnologa, arquitectura, desarrollo, prototipo y reutilizacin. 3.3.1 Tecnologa Uno de los factores ms importantes es el tipo de tecnologa que se utilizar. Este aspecto tiene grandes repercusiones en todo el proceso y debe escogerse con sumo cuidado. En general, la seleccin del tipo tecnologa tiene que ver con diversos aspectos del sistema, algunos de los cuales ya se han mencionado en el Captulo 2, como la robustez, extensibilidad, etc. Tomemos el caso de extensibilidad, donde el desarrollador debe lograr una arquitectura muy estable que minimice los efectos de cambios en el sistema. Existen por ejemplos algunas estadsticas informales (Coad y Yourdon 1991) que muestran la tendencia a cambios en varios elementos de un sistema, como se muestra en la Tabla 3.2. Elemento Probabilidad de cambio Alto Interfaces Alto Funcionalidad Medio Datos Medio Funciones Bajo Objetos Bajo Informacin Tabla 3.2 Probabilidad de cambios futuros en el software de acuerdo al tipo de elemento de diseo. Esta tabla resalta dos aspectos importantes en el desarrollo de software: (i) la arquitectura del sistema y el lenguaje de programacin deben apoyar elementos lo ms estable posible, en otras palabras elementos con menor probabilidad de cambios; y (ii) la arquitectura del sistema debe distinguir al mximo entre los distintos tipos de elementos de manera que aquellos de mayor probabilidad de cambio no arrastren a los ms estables. En el captulo 2 se dieron algunas razones para la utilizacin de tecnologa orientada a objetos en lugar de la estructurada. La tabla anterior apoya lo dicho anteriormente. Si el lector an no est convencido de las razones dadas, considere que los autores anteriores han sido de los primeros en apoyar, a inicio de los 90s, el enfoque orientados a objetos para la construccin de sistemas, y el propio Yourdon fue en la dcada de los 80s el pionero de los enfoques estructurados! Este tema lo discutiremos con mayor detalle en la seccin de metodologas. Ntese en la tabla anterior que los ltimos dos elementos, interfaces y funcionalidad, son elementos de ms alto nivel que objetos, informacin, datos y funciones, y son manejados a travs de las metodologas, por lo cual stas deben integrar tambin los conceptos orientados a objetos si esperamos sacarle provecho a los lenguajes de programacin. 3.3.2 Arquitectura La arquitectura de software se define como la estructura general del sistema incluyendo aspectos de como cambiarlo, verificarlo y mantenerlo. La arquitectura general se especializa a travs de las distintas actividades del modelo de proceso hasta llegar a una arquitectura particular implementada por el cdigo final. En el caso de desarrollo de sistemas orientados a objetos, la arquitectura general estar basada en clases y objetos. Las arquitecturas deben especializarse de acuerdo a los diferentes tipos de sistemas. Algunos tipos de sistemas comunes son: ? ? Transformacin en lote (batch), son sistemas de transformacin secuencial sobre un conjunto de entradas, resultando en un conjunto de salidas que se procesa sin interaccin con el mundo externo. Un ejemplo de un sistema de este tipo es un compilador. ? ? Transformacin contnua, son sistemas en los cuales las salidas dependen activamente de las entradas que cambian frecuentemente y deben ser actualizadas de manera correspondiente. Ejemplos de estos sistemas son los sistemas de control de seales. ? ? Interfaz interactiva, son sistemas regidos por interacciones externas, tpicamente por un usuario. Las interfaces interactivas son por lo general parte de una aplicacin de mayor alcance. Ejemplos de estos sistemas son los clsicos sistemas de ventanas como Windows u Office. Estos sistemas son controlados por manejadores de eventos, donde el manejador responde a cada evento externo, generalmente un click del ratn o la presin de una tecla en el teclado.

Weitzenfeld: Captulo 3

12

??

?? ??

Simulacin dinmica, son sistemas que simulan objetos del mundo real y que evolucionan con el tiempo. El mayor problema en la simulacin es proveer un rendimiento adecuado. Idealmente un nmero arbitrario de procedimientos paralelos ejecuta la simulacin. Ejemplos de estos sistemas son simuladores de sistemas financieros, redes neuronales [Weitzenfeld et al, 2000], sistemas elctricos (como SPICE), etc. Sistemas de tiempo real, son sistemas regidos por restricciones estrictas en el tiempo. Por lo general se requieren garantas en el tiempo de respuesta, siendo este tipo de sistemas de los ms complejos en desarrollar. Ejemplos de estos sistemas son los controladores de procesos industriales y dispositivos de comunicacin. Administracin de transaccin, son sistemas que se ocupan de consultar, guardar y actualizar bases de datos y que incluyen, por lo general, acceso concurrente y distribuido para mltiples usuarios. En particular las transacciones deben ser atmicas y no deben tener interferencia con otras transacciones. Ejemplos de estos sistemas son los de reservaciones de vuelos y los de control de inventario.

3.3.3 Desarrollo A nivel de actividades, existen dos estrategias bsicas que vale la pena describir con ms detalle: el desarrollo de actividades de forma iterativa y de manera incremental. Lamentablemente los trminos iterativo e incremental a menudo se usan indistintamente, sin embargo, las dos son estrategias de desarrollo distintas e independientes, aunque pueden utilizarse de forma separada o en conjunto. ? ? Iterativo: Se conoce como desarrollo iterativo el acto de revisar un resultado previo para ser luego modificado. Desarrollo iterativo apoya rehacer porciones del sistema. La idea detrs del desarrollo iterativo es revisar parte del sistema de forma controlada para remover errores o hacer mejoras basadas en la retroalimentacin del usuario. Despus de cada iteracin, se evala el resultado y se planea, en la iteracin siguiente, mejorar el sistema y la calidad del diseo. Aunque lo ideal es no tener que hacer dos veces lo mismo, a veces esto se justifica cuando un problema es bastante nuevo o difcil. Por ejemplo, en el caso de un marco reutilizable a menudo se requiere que este se utilice y revise varias veces antes de tener suficiente confianza en su calidad y potencial de reuso. Por otro lado, esto puede servir de excusa para hacer un trabajo incompleto, y no hacerlo bien la primera vez. ? ? Incremental: Se conoce como desarrollo incremental el acto de incrementar o aadir desarrollo. Desarrollo incremental apoya dividir los sistemas para desarrollarse en diferentes momentos para obtener progreso en pequeos pasos. El desarrollo incremental se puede ver como una forma explcita para evitar la teora del Big Bang para desarrollo de software, donde una gran explosin de desarrollo de repente se transforma de una sola vez de forma milagrosa en el sistema completo. Al contrario, el desarrollo de sistemas se considera un proceso lento, el cual puede durar varios aos, dependiendo del tamao del sistema. El enfoque incremental requiere que un problema se divida en varios subproblemas para que cada cual se desarrolle a su vez. Segn se completa cada seccin, se verifica e integra con las dems secciones ya completadas del sistema. En cada paso, el sistema parcialmente completado se puede evaluar en relacin al desarrollo de secciones futuras. El conocimiento sobre el sistema crece progresivamente segn el trabajo progresa. En la mayora de los casos es mejor desarrollar el sistema paso a paso, comenzando con algunas de sus funciones bsicas, permitiendo posteriormente aadir nueva funcionalidad. El sistema se agranda incrementalmente hasta llegar al nivel deseado, ofreciendo retroalimentacin ms frecuente durante el proceso de desarrollo. Esta es la idea detrs del modelo de espiral, donde cada ciclo significa un incremento en el sistema. El trmino software factory describe la divisin en procesos y subprocesos de las actividades del desarrollo. Para que la secuencia de las etapas de desarrollo sean exitosas, es esencial definir etapas que no requieran cambiar los resultados anteriores al introducir nuevas etapas. Por lo tanto, una comprensin inicial de los requisitos que sirven de base para el sistema completo es importante. Cada etapa se desarrolla como un ciclo y es verificada antes de completar la etapa. Es la regla ms que la excepcin que los requisitos de los sistemas no son totalmente conocidos al iniciarse el proyecto. En general, el desarrollo de software es un proceso incremental y muchas iteraciones ocurrirn antes de poder completar el sistema. Estas iteraciones ocurrirn y no tiene sentido impedirlas, sino encontrar la forma de manejarlas. 3.3.4 Prototipo Un prototipo es una versin preliminar, intencionalmente incompleta o reducida de un sistema. El trmino prototipaje rapido (RAD Rapid Application Development) se refiere al proceso de construir y evaluar uno o ms prototipos rpidamente. Los prototipos son estrategias aplicadas a la mayora de actividades del proceso de software, las cuales pueden estar relacionadas con aspectos tcnicos, funcionales, eficiencia o interfaces de usuario. Los prototipos rpidos permiten el desarrollo sencillo con resultados inmediatos. Ya que un prototipo se concentra en las

Weitzenfeld: Captulo 3

13

propiedades que requieren mayor investigacin, aspectos adicionales pueden dejarse de lado, siendo mostrados nicamente de forma esquemtica. El propsito de los prototipos es buscar de manera preliminar informacin necesaria para ayudar en la toma de decisiones. Los prototipos complementan el desarrollo de sistemas incrementales y pueden ayudar a reducir el riesgo en la especificacin de requisitos o en el diseo de la arquitectura del sistema. Una ventaja de los prototipos es que sirven como medio de comunicacin entre el desarrollador y el cliente, ayudando a visualizar rpidamente la dinmica del sistema. Por lo general un prototipo no es lo suficientemente robusto para ser el producto final. Sin embargo, la existencia de la demostracin apoya la creencia de que el producto completo puede desarrollarse de manera satisfactoria. Si el prototipo es diseado con cuidado puede inclusive utilizarse en el sistema final. A pesar de las mltiples formas de interaccin con el usuario final, stos raramente son capaces de expresar claramente lo que quieren y a menudo prefieren algo diferente de lo que reciben. Por desgracia, este es el aspecto ms problemtico del desarrollo de software ya que a menudo ocurre temprano durante la especificacin del proyecto y se detecta muy tarde durante la entrega del proyecto. Esta situacin ocurre porque los encargados de la toma de decisiones a menudo les faltan informacin clave. En general, se puede pensar en un prototipo de software como un medio para la especificacin de requisitos o un enlace de comunicacin entre el usuario final y el diseador. Tambin se le puede ver como un modelo incompleto demostrando las capacidades del sistema final, que provee al usuario con una representacin fsica de las partes ms importantes del sistema antes de su implementacin completa. Los prototipos son una manera rpida para comprender los modelos de requisitos, anlisis, diseo, implementacin y pruebas de un sistema. Sin embargo, existe la idea errnea de que gracias a la tecnologa orientada a objetos los prototipos se pueden evolucionar iterativamente hasta llegar al sistema final. Se cree que simplemente se comienza a codificar y se deja que el producto se desarrolle. Esto realmente vara y depende del tipo de prototipo que se est desarrollando: ? ? Prototipos de requisitos: Un prototipo de requisitos permite que los usuarios interacten con una interfaz del sistema que muestre toda o casi toda la funcionalidad requerida del producto final sin que realmente se implemente. El objetivo es ayudar a clarificar los requisitos y solicitar nuevas ideas. Como las interfaces complejas son difciles de documentar, el prototipo puede incluirse como parte de la documentacin de requisitos. ? ? Prototipos de anlisis: Un prototipo de anlisis permite generar una arquitectura general del sistema de manera rpida que considere las caractersticas principales del sistema, como qu componentes podran ser utilizados. La idea es mostrar un bosquejo rpido de esta arquitectura que se apegue a los requisitos especificados originalmente. ? ? Prototipos de diseo: Un prototipo de diseo se desarrolla para explorar y comprender la arquitectura particular del sistema. El prototipo puede servir como base para la evaluacin de rendimiento y espacio, y para pruebas de redundancia o inconsistencias en el diseo. Evaluacin del rendimiento de un prototipo de diseo puede identificar cuellos de botella en el sistema, dnde se requiere revisar con ms detalle antes de poder desarrollar el producto final. ? ? Prototipos verticales: Un prototipo vertical se usa para comprender una seccin o parte de un problema y su solucin completa. Esto se hace cuando los conceptos bsicos no estn bien comprendidos y cuando el desarrollar todos los aspectos de una funcionalidad muy limitada ayuda a aclararlos. ? ? Prototipos de factibilidad: Un prototipo de factibilidad se usa para demostrar si un aspecto del proyecto es posible. Por ejemplo, si una arquitectura particular es aplicable; si la manera de conectarse a una base de datos ofrece un rendimiento adecuado; si es posible que un grupo de desarrollo aprenda a programar en cierto lenguaje; si la tecnologa es apropiada para la organizacin; o si los costos esperados por un proyecto cubren sus gastos. En el pasado, los modelos de desarrollo tales como el Modelo de Espiral incorporaban prototipos nicamente como una forma de reducir el riesgo en obtener una interfaz de usuario correspondiente a las necesidades del cliente. Estos prototipos eran secuencias de pantallas mostrando como el usuario vera el producto, dando la ilusin de un sistema funcional el cual poda comentarse con los clientes. Esto es apropiado para lograr una mejor retroalimentacin con los clientes. Sin embargo, la implementacin de un prototipo no es necesariamente un producto de calidad, diseado para ser mantenido a largo plazo. Por el contrario, el prototipo es a menudo pegado rpidamente, para ser probado y luego reescrito. Como tal, la implementacin debe tirarse. Sin embargo, no se puede considerar slo los extremos; guardar o tirar los prototipos. Por lo general, partes de un prototipo se guardan cuando se crea el siguiente prototipo o versin del producto. En especial el prototipo de diseo

Weitzenfeld: Captulo 3

14

tiene una mayor probabilidad de evolucionar en el software final que otros tipos de prototipos. Es probable, por ejemplo, que el ambiente donde se estudia el diseo sea el mismo a utilizarse en el desarrollo del producto. Tambin un prototipo de anlisis pueda evolucionar en el producto final, como en el caso de una biblioteca de componentes de software con interfaces consistentes entre s, como es el caso de los JavaBeans. Este tambin es un ejemplo donde los prototipos pueden hacer uso de los componentes reusables. Asumiendo que los componentes reusables sean de calidad, es probable que un producto completo pueda evolucionar del prototipo inicial modificando su implementacin en respuesta a la retroalimentacin del usuario y otros aspectos de diseo. Sin embargo, siempre existir un conflicto entre un desarrollo rpido y un producto de calidad. Existe tambin una tendencia que para tratar de ganarle el mercado a los competidores, algunos administradores tratan de enviar el prototipo como si fuera ya el producto final. La siguiente lista muestra algunas de las razones para crear prototipos, categorizadas segn diferentes metas (Goldeberg y Rubin 1995). ? ? Asegurarse que el sistema hace lo deseado: Probar conceptos, obtener definicin de producto, determinar funcionalidad completa, disear interfaces de usuario, disear subsistemas, asegurar la autorizacin de los cliente para minimizar cambios y confusin despus de la entrega y proveer un contexto de discusin cuando los interesados tienen diferentes perfiles o hablan diferentes lenguajes. ? ? Asegurarse que el sistema hace correctamente lo deseado: Determinar el modelo de comportamiento del sistema y probar algoritmos alternos. ? ? Mejorar la implementacin del sistema actual o futuro: Ayudar a identificar clases para reuso, disear marcos para aplicaciones y ayudar a estimar tiempo de construccin. ? ? Mejorar procesos y recursos: Crear prueba de concepto para obtener un contrato, probar nuevas herramientas (lenguajes, ambientes de desarrollo), determinar si una tecnologa trabaja en un ambiente particular, aprender una tecnologa; un lenguaje, un conjunto de herramientas, un conjunto de tcnicas, ganar una ventaja de negocio antes de que el sistema final se entregue ofreciendo a los clientes y la prensa una demostracin temprana del producto y entrenar temprano el grupo de soporte tcnico y ventas. Existen diversos aspectos de los cuales depende el xito del prototipo (Goldberg y Rubin 1995): ? ? Comprender el propsito del prototipo y usarlo de manera adecuada. ? ? Comprender la tecnologa a utilizarse y su relacin con el proceso de prototipos. ? ? Juntar un grupo tcnico apropiado para hacer el prototipo: lder de proyecto, documentador, elaborador de prototipos de requisitos y anlisis, y otro de diseo. ? ? Evaluar al grupo y las entregas finales. ? ? Involucrar temprano en el proceso a los usuarios finales. ? ? Estar dispuestos a repetir el proceso de prototipos para comprender mejor la arquitectura bsica. ? ? Imponer criterios de evaluacin apropiados al comienzo de cada etapa de prototipos, y basarse firmemente en estos criterios para su terminacin. ? ? Construir prototipos basados en una biblioteca de cdigo reusable, controlada por el bibliotecario asignado. Los prototipos fallan cuando (Goldberg y Rubin 1995): ? ? No se comprende qu es un prototipo y cmo debe usarse. ? ? No se comprende el proceso lo suficientemente bien como para organizar al grupo correctamente. ? ? No se sabe cuando dejar de evolucionar el prototipo y comenzar de cero, o sea, se extiende demasiado el proceso. ? ? No se sabe cuando continuar para tratar de lograr los criterios de evaluacin deseados, o sea, se termina prematuramente el proceso. ? ? No se utiliza ambientes o herramientas de apoyo para el desarrollo orientado a objetos, solamente un lenguaje orientado a objetos. ? ? Se cree que un prototipo razonable es un producto aceptable. ? ? Los prototipos nunca terminan. 3.3.5 Reutilizacin En general la reutilizacin del cdigo se puede hacer dentro de un mismo proyecto o entre proyectos. Reutilizacin de cdigo dentro de un mismo proyecto involucra simplemente descubrir secuencias de cdigo redundantes en el diseo y usar las facilidades del lenguaje de programacin, como procedimientos o herencia. Este tipo de reuso de cdigo es siempre bueno, produciendo programas ms pequeos y resultando en correcciones ms rpidas. Reuso entre proyectos requiere planeacin y representa una inversin. No es muy probable que una clase aislada sirva para

Weitzenfeld: Captulo 3

15

mltiples proyectos pero s estructuras bien analizadas como tipos de datos abstractos, paquetes grficos, y bibliotecas de anlisis numrico. El consumo de componentes reutilizables es una muy buena estrategia para minimizar el esfuerzo en completar una tarea. Sin embargo, la estrategia tiene que ser complementada por un esfuerzo en producir los componentes reusables. El modelo de proceso de productor/consumidor de software, es un modelo de proceso que mezcla proyectos que producen componentes reusables con aquellos que consumen componentes reusables. La decisin para reutilizar componentes se basa en la evaluacin de costos entre crear una nueva solucin o adaptar una existente. Asimismo, una organizacin debe considerar los costos adicionales en la produccin del componente reutilizable planificando la reduccin de costos posterior al utilizar los componentes en otros proyectos. Una organizacin puede administrar costos y hacer del reuso una parte efectiva de su modelo de proceso. ? ? Consumiendo Componentes Reusables. Cuando se requiere una solucin a un problema la primera pregunta que se hace el consumidor es si ya hay una solucin disponible. Se debe aprovechar toda solucin completa o parcial existente ya que las ventajas incluyen soluciones consistentes entre aplicaciones, adems que las mejoras a la solucin se propagan a todas las aplicaciones, mejorando la calidad del componente al ser probado por mltiples aplicaciones y sirve para ver si alguna de estas partes ya ha sido resuelta anteriormente. Obviamente para lograr un buen reuso la solucin debe adaptarse a los objetivos de la tarea donde el reuso fue considerado. Por lo general, los desarrolladores solamente reusan soluciones existentes donde se confa con el nivel de calidad requerido. El reuso puede ocurrir durante las diversas actividades. Por ejemplo, a nivel de requisitos pueda que ya se haya resuelto el mismo problema anteriormente, y de manera similar durante las dems actividades, incluso a nivel de documentacin como en la utilizacin de ejemplos similares. Las oportunidades ocurren en todo el ciclo de vida de un proyecto. ? ? Produciendo Componentes Reusables. Crear componentes reusables es una meta importante que cambia la visin del software, de un problema a una ventaja. Los productores de reuso crean resultados que no se evalan como funcionalidad final independiente y completa, sino como recursos que contribuirn a otros proyectos, por lo tanto, se debe tener una perspectiva de mltiples proyectos. Adems, los productores de reuso llevan a cabo tareas especiales para incrementar el potencial de reuso, como el anlisis variante, que ayuda a identificar y darle prioridad a posibles variantes de los componentes (Barnes y Bollinger 1991). Otras tareas del productor de reuso incluyen crear documentacin orientada a reuso y aplicar evaluaciones especiales de reuso. La documentacin debe expresar suposiciones y limitaciones del componente, y describir cmo extender o refinar el componente. La evaluacin de reuso se beneficia del anlisis variante para identificar los casos de pruebas. Para un marco, se pide una descripcin de la categora de la aplicacin que se pueda derivar del marco, y se prueba para ver si la aplicacin de este tipo se puede realmente derivar. Para componentes, se pregunta si las descripciones son suficientemente generales para poder participar en diversas aplicaciones de inters para la organizacin. En la prctica, productores y consumidores de reuso trabajan de forma concurrente. La produccin de marcos y componentes reusables, junto con la produccin de sistemas, son procesos ligados. Los productores necesitan ver lo que han hecho los consumidores para decidir que es til. Y los consumidores necesitan probar software de los productores para proveer retroalimentacin necesaria para decidir si los resultados son realmente generales y suficientemente valiosos. A continuacin se muestra un resumen (Golberg and Rubin 1995) sobre las razones para utilizar reuso. La mayora de las preocupaciones con reuso se relacionan con aspectos de tiempo y calidad. El reuso es valioso porque: ? ? Lo comn es ms fcil de apoyar. ? ? Se promueve consistencia externa al incorporar estndares. ? ? El reuso incrementa la habilidad para discutir problemas entre diversos grupos. ? ? El reuso reduce costos. ? ? El reuso hace ms fcil comenzar el desarrollo, incluso cuando el componente reusable no se ajusta perfectamente a las nuevas necesidades. ? ? El reuso acelera el tiempo de entrega. ? ? El reuso de resultados ya probados mejora la calidad del producto. El reuso no es valioso porque: ? ? Los componentes generalizados pueden que no se ajusten a los requisitos de rendimiento. ? ? El tiempo de aprendizaje de nuevos componentes puede que no se ajuste a los tiempos del proyecto. ? ? Los estndares pueden ser limitantes. Debe hacerse reuso cuando: ? ? Se necesita conservar recursos.

Weitzenfeld: Captulo 3

16

? ? Se incrementa la base de funcionalidad. ? ? Hacindolo provee una gua para el diseo. ? ? Los componentes reusables mejoran la calidad del producto. ? ? Conociendo partes del sistema permite predecir tiempo de desarrollo. ? ? Reusar es ms rpido. ? ? Las suposiciones actuales corresponden a las suposiciones del componente. ? ? Los componentes han sido probados operando correctamente en otras situaciones. No debe hacerse reuso cuando: ? ? Los objetivos de diseo no se satisfacen al hacerlo. ? ? Se tiene que forzar un ajuste haciendo demasiados cambios. ? ? Los componentes reusables proveen aspectos que hacen que el resultado sea inapropiado para el mercado al que va dirigido. ? ? Los componentes reusables proveen exceso de funcionalidad. ? ? La interfaz del componentes reusable no est bien entendida por los miembros del proyecto. ? ? Los componentes reusables son propiedad de un proyecto especfico. ? ? Los componentes de reuso incluyen demasiada funcionalidad no requerida, aumentando el tamao del sistema y el esfuerzo de desarrollo. ? ? El reuso no disminuye la cantidad de cdigo a ser probada. 3.4 Actividades La Tabla 3.3 muestra las actividades ms importantes para el ciclo de vida del desarrollo de software. Estas actividades corresponden a las mostradas en la Figura 3.1 en el Modelo de Cascada y corresponden de manera similar a las actividades del Modelo de Espiral. La diferencia entre ellas radica en el proceso y orden para llevarlas a cabo junto con las estrategias y mtodos utilizados para cada actividad. Actividad Requisitos Descripcin Se especifica las necesidades del sistema a desarrollarse. La especificacin de requisitos puede servir como base para la negociacin entre los desarrolladores y clientes del sistema y tambin para planear y controlar el proceso de desarrollo. Anlisis Se busca comprender los requisitos del sistema logrando la estructuracin de una solucin, correspondiente a la arquitectura general. Se contesta la pregunta del qu del sistema. Diseo Se transforma la arquitectura general de anlisis, a una arquitectura particular y detallada del sistema que satisfaga todos los requisitos del sistema, donde las condiciones idealizadas durante el anlisis se reemplazan por requisitos del ambiente de implantacin particular. Se contesta la pregunta del cmo del sistema. Implementacin Se expresa la arquitectura particular del sistema, en una forma aceptable para la computadora, o sea el cdigo. Pruebas Se verifica y valida el sistema a nivel de componentes y la integracin de ellos. Este es uno de los aspectos ms crticos del desarrollo y debe ser aplicado desde el inicio, durante todas las actividades. De tal manera se busca descubrir cualquier defecto en los requisitos, anlisis, diseo, implementacin e integracin. Las pruebas se hacen a varios niveles, desde funciones sencillas hasta el sistema completo. Integracin Se combinan todos los componentes creados de manera independiente para formar el sistema completo. Documentacin Se describen los aspectos sobresalientes de los requisitos, anlisis, diseo, implementacin, integracin y pruebas. Esto servir para usuarios externos e internos, aquellos encargados en mantener el sistema y extenderlo. Mantenimiento Se corrigen errores no encontrados durante el desarrollo y pruebas originales del sistema. Se extiende el sistema segn existan nuevas necesidades. Tabla 3.3 Actividades del desarrollo de software. La transicin entre las distintas actividades debe ser natural, debiendo existir una continuidad o rastreabilidad (traceability) de una actividad a la siguiente o la anterior. A continuacin describimos con mayor detalle cada una de estas actividades.

Weitzenfeld: Captulo 3

17

3.4.1 Requisitos La actividad o modelo de requisitos tiene como meta definir y delimitar la funcionalidad del sistema de software. El modelo de requisitos puede servir como base de negociacin y contrato entre el desarrollador del sistema y el cliente, y por lo tanto debe reflejar los deseos del cliente. Es esencial que los clientes que no tengan un conocimiento de la computacin puedan comprender el modelo de requisitos para facilitar la interaccin con ellos. El modelo de requisitos gobierna el desarrollo de todos los dems modelos, siendo central durante el desarrollo del sistema completo. El modelo de requisitos se estructura mediante el modelo de anlisis, se realiza mediante el modelo de diseo, se implementa mediante el modelo de implementacin y se prueba mediante el modelo de pruebas. Adems, todos los dems modelos deben verificarse contra el modelo de requisitos. El modelo de requisitos tambin sirve como base para el desarrollo de las instrucciones operacionales y los manuales, los cuales son descritos desde el punto de vista del usuario. El desafo de la especificacin de requisitos comienza cuando el experto debe comunicar los conceptos, lo cual no es generalmente posible de hacer adecuadamente por medio de una simple expresin. Como resultado, se provee explicaciones mltiples, verbales o escritas. El desarrollador pide y captura estas explicaciones y las integra en una representacin coherente. La especificacin de requisitos es particularmente difcil cuando la informacin es incompleta, los expertos no pueden articular lo que saben, o no estn seguros o incluso son incoherentes sobre su conocimiento o creencias. Una meta importante es minimizar las diferencias entre los espacios de concepto y el modelo de requisitos. Si la distancia entre el modelo y la comprensin del experto es grande, ser bastante difcil, sino imposible para el experto verificar la precisin. Consecuentemente, una de las necesidades principales de cualquier modelo de requisitos es que sea comprensible para cualquier persona. 3.4.2 Anlisis Despus del desarrollo del modelo de requisitos y de haber sido ste aprobado por parte de los usuarios del sistema o clientes, se puede iniciar realmente a desarrollar el sistema. Esto comienza con el desarrollo del modelo de anlisis que toma como punto de partida la especificacin de requisitos y tiene como meta construir una arquitectura capaz de resolver el problema bajo condiciones ideales. Esto significa que se busca desarrollar una estructura lgica del sistema, la cual debe ser estable, robusta, mantenible y extensible. El anlisis se enfoca en qu debe hacer el sistema, en lugar de cmo se supone que lo har. El alcance del modelo de anlisis est directamente relacionado con la naturaleza de los conceptos del modelo. En el caso de la tecnologa orientada a objetos, se desea: encontrar los objetos, organizar los objetos, describir cmo los objetos interactan, definir las operaciones de los objetos y definir los objetos internamente. 3.4.3 Diseo El propsito del modelo de diseo es extender la arquitectura general de anlisis. Este refinamiento se debe a dos razones principales: ? ? El modelo de anlisis no es suficientemente formal por lo cual para poder llegar al cdigo final se debe refinar las estructuras de la arquitectura general. Se debe especificar las operaciones que deben utilizarse, la comunicacin entre componentes, los eventos, etc. Este aspecto es conocido como el diseo de estructuras o de manera general como el diseo de objetos en el caso de arquitecturas orientadas a objetos. ? ? Durante el anlisis se asume un mundo ideal para el sistema. En la realidad este mundo ideal debe adaptarse al ambiente donde se implementar el sistema. Entre otros aspectos, se debe considerar los requisitos de rendimiento, aspectos de tiempo real, concurrencia, propiedades del lenguaje de programacin, el sistema de manejo de base de datos, etc. Este aspecto es conocido como el diseo de sistema. La razn para no incluir estos aspectos durante el modelo de anlisis se debe a que los aspectos anteriores deben influenciar la arquitectura del sistema lo menos posible. En general, la propia aplicacin controla la arquitectura y no las circunstancias existentes durante su implementacin. Desde otra perspectiva, el modelo de anlisis debe ser visto como un modelo conceptual y lgico del sistema, mientras que el modelo de diseo debe acercarse ms al cdigo final. Esto significa que se cambia el punto del vista del modelo de diseo a una abstraccin del cdigo fuente a ser escrito. Es esencial guardar y congelar el modelo de anlisis para un mantenimiento futuro incluso despus de terminar el diseo. En general, se debe comenzar el diseo temprano, preferiblemente al mismo tiempo que se comienza con el modelo de anlisis. El primer paso segn se comienza a trabajar es identificar el ambiente de implementacin y esto se puede hacer en paralelo con el anlisis para que est listo cuando el diseo actual comience. Si se ha hecho un modelo de anlisis muy detallado, el grado de refinamiento necesario durante el diseo puede ser muy pequeo. La

Weitzenfeld: Captulo 3

18

decisin de la transicin de anlisis a diseo depende de cada proyecto, siendo importante decidir esto temprano, lo cual debe basarse en el resultado de la identificacin del ambiente de implementacin. ? ? Diseo de objetos. El diseo de objetos consiste de decisiones tcticas, tales como la seleccin de algoritmos y estructura de datos para satisfacer los objetivos de rendimiento y espacio. El modelo de anlisis y el diseo de objetos tienen bastante en comn, incluyendo los mismos conceptos, tcnicas y notaciones. Como consecuencia, las mismas herramientas de desarrollo pueden utilizarse para llevar a cabo ambas actividades. A menudo, estas similitudes hacen difcil saber que actividad se est llevando a cabo. Uno de los beneficios ms importantes de la tecnologa orientada a objetos es la representacin de la solucin como una consecuencia directa de la representacin del problema, por lo cual la distincin entre anlisis y diseo de objetos no es realmente crtica, a diferencia de otros enfoques ms tradicionales. El diseo de objetos especializa la arquitectura general mediante subsistemas que agrupan funcionalidad o estructuras comunes, que constan de interfaces bien definidas con otros subsistemas, usualmente identificados por los servicios que proporcionan. Los subsistemas pueden definirse en capas correspondientes a un conjunto de subsistemas horizontales construido en trmino de subsistemas o capas inferiores que pueden ser cerradas o abiertas. A diferencia de las capas que dividen un sistema de manera horizontal, las particiones dividen verticalmente al sistema. Estas divisiones son dbilmente conectadas, cada una ofreciendo otro tipo de servicios. Un sistema puede ser descompuesto usando capas y particiones a la vez, donde las capas pueden ser divididas en particiones y las particiones en capas. El diseo de objetos debe definir el manejo de control, como son los sistemas impulsados por procedimientos y sistemas impulsados por eventos. En los sistemas impulsados por procedimientos, el control es mediante procedimientos, mientras que en los sistemas impulsados por eventos, el control reside en un despachador o monitor provisto por el lenguaje, subsistema, o sistema operativo, siendo ms apropiado para sistemas interactivos en especial aquellos controlados por el ratn. Otros aspectos que afectan el diseo de objetos son los componentes o bibliotecas y herramientas, donde los componentes permiten construir un sistema mediante estructuras prefabricadas de ms alto nivel que lo ofrecido por el lenguaje de programacin, mientras que las herramientas son esenciales en la administracin de los sistemas. Estas herramientas incluyen ambientes de desarrollo para la escritura y configuracin del cdigo, como lo son compiladores, depuradores, preprocesadores y dems. ? ? Diseo de Sistema. El diseo de sistema define las decisiones estratgicas sobre como se organiza la funcionalidad del sistema en torno al ambiente de implementacin. El ambiente de implementacin se divide en el ambiente de hardware y el ambiente de software, los cuales estn muy ligados entre s. El ambiente de hardware afecta al ambiente de software, en especial si el software depende de la plataforma. Es importante restringir el efecto del ambiente de implementacin sobre la arquitectura de anlisis. Para adaptar el modelo de diseo al ambiente de implementacin, se debe identificar las restricciones tcnicas bajo las cuales el sistema debe ser construido. Esta identificacin debe ser hecha temprano, idealmente durante el modelo de requisitos. Aunque no todas las decisiones son hechas durante el diseo de sistema, las prioridades para hacerlas s deben ser establecidas anteriormente. Existen razones importantes para introducir el ambiente de implementacin temprano. No se quiere que el ambiente de implementacin afecte la estructura bsica del sistema, ya que las circunstancias actuales probablemente sern cambiadas de una manera u otra durante el ciclo de vida del sistema. No se quiere que el problema se complique an ms por la complejidad introducida a travs del ambiente de implementacin. De esta manera es posible enfocar lo esencial cuando se desarrollan los aspectos importantes del sistema, o sea, su estructura bsica. Entre otras cosas, se identifica la concurrencia en el sistema y se deciden las prioridades durante el diseo, incluyendo rendimiento, memoria, protocolos de comunicacin, flexibilidad y extensibilidad. Los subsistemas se asignan a los procesadores y tareas segn la arquitectura propuesta, se escoge el manejo de almacenamientos de datos, se escogen los mecanismos para coordinar el acceso a recursos globales, se escoge la implementacin del control del software, se escoge el enfoque para el manejo de condiciones de borde, incluyendo manejo de errores. Las decisiones ms importantes en relacin al ambiente de implementacin tiene que ver con el rendimiento y memoria, concurrencia, manejo de procesos, manejo de almacenamiento de datos y manejo de recursos globales. Los requisitos de rendimiento y uso de memoria tienen un gran efecto sobre la arquitectura del sistema. Por ejemplo, los primeros juegos de video corran en un procesador con memoria limitada, donde conservar memoria era la prioridad mxima, seguido por ejecucin rpida. Actualmente, la prioridad es de mayor rapidez de ejecucin sin importar el espacio de memoria necesario. Es bastante comn que un buen diseo se arruine por malos rendimientos. Una meta importante del diseo de sistema es identificar cuales componentes deben estar activos concurrentemente y cuales tienen actividades secuenciales. Cada subsistema concurrente debe considerar el manejo de procesos para lograr un mejor rendimiento del sistema, donde se deben seguir los siguientes pasos: (i) estimar los requisitos de recursos; (ii) balancear entre hardware y software; (iii) asignar las tareas a los procesadores; y (iv) determinar la

Weitzenfeld: Captulo 3

19

conectividad fsica. El manejo de almacenamiento de datos debe considerar aspectos interno como la memoria y externos como los discos. Diferentes tipos de almacenamiento proporcionan diferentes costos, capacidad, y tiempo de acceso. Los archivos son simples pero sus operaciones son de bajo nivel, mientras que las bases de datos organizan el acceso a datos de forma ms eficiente, aunque sus interfaces son complejas y muchas de ellas no se integran bien con los lenguajes de programacin. El diseador del sistema debe manejar los recursos globales incluyendo el acceso a unidades fsicas como procesadores, controladores, o espacio de disco, o nombres lgicos, como archivos o clases. Ms all de esto, el diseo de sistema debe apoyar aspectos como una terminacin inesperada del sistema que puede ocurrir por errores del usuario, agotamiento de recursos, o por fallas externas como de hardware. Un buen diseo considera posibles fallas, incluyendo errores del programa, y debera imprimir o guardar la mxima informacin sobre el error cuando este ocurra. Estos aspectos son apoyados de manera variada por los distintos lenguajes de programacin 3.4.4 Implementacin El modelo de implementacin toma el resultado del modelo de diseo para generar el cdigo fuente anotado. Esta traduccin debe ser relativamente sencilla y directa, ya que todas las decisiones han sido hechas en las etapas previas. La especializacin al lenguaje de programacin o base de datos describe cmo traducir los trminos usados en el diseo a los trminos y propiedades del lenguaje de implementacin. Aunque el diseo de objetos es bastante independiente del lenguaje actual, todos los lenguajes tendrn sus especialidades durante la implementacin final incluyendo las bases de datos. Existen ciertamente sistemas que automticamente traducen descripciones SDL (Specification and Description Language, CCITT [1988?) a cdigo fuente, pero esto requiere que los grafos SDL se extiendan con formalismos similares a los lenguajes de programacin. Sin embargo, en su gran mayora los programadores hacen de manera manual la transicin final a cdigo fuente. En el modelo de implementacin, el concepto de rastreabilidad es tambin muy importante, dado que al leer el cdigo fuente se debe poder rastrear directamente del modelo de diseo y anlisis. ? ? Lenguajes de Programacin. Un aspecto importante durante el diseo de objetos es la seleccin del lenguaje de programacin. El lenguaje de programacin no tiene que ser necesariamente orientado a objetos. El uso de un lenguaje de programacin orientado a objetos hace ms fcil la implementacin de un diseo orientado a objetos. La eleccin del lenguaje influye en el diseo, pero el diseo no debe depender de los detalles del lenguaje. Si se cambia de lenguaje de programacin no debe requerirse el re-diseo del sistema. Los lenguajes de programacin y sistemas operativos difieren mucho en su organizacin, aunque la mayora de los lenguajes tienen la habilidad de expresar los aspectos de la especificacin de software que son las estructuras de datos (objetos), flujo dinmico de control secuencial (ciclos, condiciones) o declarativo (reglas, tablas) adems de contar con transformaciones funcionales. En el caso de un lenguaje orientado a objetos la estructura bsica son las propias clases. Aunque no todos las caractersticas mnimas de la orientacin a objetos (ver captulo 2) sean ofrecidas, un lenguaje de programacin orientado a objetos implementar de mejor manera todos los conceptos anteriores. En especial, es deseable tener una buena y fcil correspondencia entre un objeto en el modelo de objetos con estructuras en el lenguaje de programacin. Dependiendo del lenguaje de programacin esto puede hacerse ms sencillo o complicado. Los lenguajes ms utilizados varan desde los semi orientados a objetos como Ada y Modula-2 hasta los estructurados tradicionales, como C, Pascal, Fortran y COBOL. En general, el aspecto ms difcil de implementar con estos lenguajes es la herencia. Estos temas sern tratados con mayor detalle en el Captulo de Implementacin. ? ? Bases de Datos. Las bases de datos son parte integral de los sistemas de software, en especial de los sistemas de informacin. En general, se pueden utilizar bases de datos orientadas a objetos u otros tipos de bases de datos, como las relacionales. Si los aspectos dinmicos y funcionales del sistema son menores en relacin a las estructuras del sistema, una base de datos relacional puede que sea suficiente ya que stas se dedican a almacenar principalmente los aspectos estructurales del sistema. Por otro lado, las bases de datos orientadas a objetos van ms all de las estructuras, guardando aspectos funcionales del sistema adems de integrarse de mejor forma con una arquitectura basada en tecnologa orientada a objetos. En el Captulo de Implementacin revisaremos estos aspectos. 3.4.5 Integracin El modelo de integracin es un aspecto muy importante del proceso de desarrollo. Una caracterstica primordial en todo sistema es mantener la modularidad en los subsistemas, esto significa que inicialmente los subsistemas se desarrollan de manera independiente, llegando el momento para su integracin final. Este enfoque maneja de mejor

Weitzenfeld: Captulo 3

20

forma la complejidad del sistema y significa que tambin debern hacerse pruebas, primero en los componentes por separado y luego en su totalidad como se describe en la siguiente seccin. 3.4.6 Pruebas El modelo de pruebas es quizs el responsable de revisar la calidad del sistema siendo desarrollado. Los aspectos fundamentales de este modelo son bsicamente la prueba de especificacin y la prueba de resultado. Probar un sistema es relativamente independiente del mtodo utilizado para desarrollarlo. Las pruebas comienzan con los niveles ms bajos, como son los mdulos de objetos, hasta llegar a la prueba de integracin donde se van integrando partes cada vez ms grandes. Una herramienta para pruebas de integracin involucra usar el modelo de requisitos para integrar requisitos de manera incremental. En particular, las actividades de pruebas normalmente se dividen en verificacin y validacin. ? ? Verificacin: Verificacin prueba si los resultados estn conformes a la especificacin, en otras palabras si se est construyendo el sistema correctamente. La verificacin debe comenzar lo antes posible, desde el nivel ms bajo mediante la verificacin de subsistemas, progresando hacia la verificacin de la integracin, donde las unidades se verifican juntas para ver si interactan de forma correcta. Finalmente se verifica el sistema completo. La etapa de verificacin en la orientacin a objetos es menos dramtica que en los sistemas que separan funciones de datos, ya que los objetos son unidades ms grandes y durante su diseo las unidades ya se estn verificando. Por otro lado, herencia al igual que polimorfismo pueden dificultar la verificacin, ya que las operaciones varan segn los ancestros o descendientes y los datos de verificacin deben ser elegidos cuidadosamente. Incluso la especificacin de verificacin puede considerarse como una extensin al modelo de requisitos y ser integrada en la arquitectura del sistema. La especificacin de verificacin debe aplicarse a todos los modelos descritos. ? ? Validacin: Validacin prueba si los resultados corresponden a lo que el cliente realmente quera. Este enfoque en la satisfaccin del cliente se concentra en obtener la especificacin y el resultado correcto. Se hace la pregunta de si se est construyendo el sistema correcto, en contraste a la verificacin donde se pregunta si se est haciendo el sistema correctamente. La validacin se captura por medio de anlisis extensivo del modelo de requisitos incluyendo interaccin constante con los clientes mediante, uso de prototipos, etc. Se debe validar los resultados del anlisis. Segn el sistema crece y se formaliza, se estudia qu tan bien el modelo de anlisis y el modelo de requisitos describen al sistema. Durante el diseo, se puede ya ir viendo si los resultados del anlisis son apropiados para el diseo. Si se encuentran puntos que no estn claros en el modelo de anlisis o en el modelo de requisitos, se les debe clarificar, quizs regresando a la actividad de anlisis nuevamente. 3.4.7 Documentacin De manera similar a las pruebas la documentacin debe ocurrir a lo largo del desarrollo del sistema y no como una etapa final del mismo. Existen diferentes tipos de documentos que deben ser generados como apoyo al sistema. Cada uno de estos documentos tiene diferentes objetivos y est dirigidos a distintos tipos de personas, desde los usuarios no tcnicos hasta los desarrolladores ms tcnicos. Los siguientes son algunos de los documentos o manuales ms importantes: ? ? Manual del Usuario, que le permite a un usuario comprender como utilizar el sistema. ? ? Manual del Programador, que le permite a un desarrollador entender los aspectos de diseo considerados durante su implementacin. ? ? Manual del Operador, que le permite al encargado de operar el sistema comprender que pasos debe llevar a cabo para que el sistema funcione bajo cierta configuracin de ambiente particular. ? ? Manual del Administrador, que le permite al encargado de administrar el sistema comprender aspectos ms generales como son los modelos de requisitos y anlisis. Realmente no hay lmite al nmero y detalle que se puede lograr mediante la documentacin, de manera similar a que no hay lmite a que tanto se puede extender y optimizar un sistema. La idea bsica es mantener un nivel de documentacin que sea til aunque es necesario adaptarlo al proceso de la organizacin. 3.4.8 Mantenimiento Una visin equivocada del mantenimiento de un sistema es que esto involucra nicamente la correccin de errores. El mantenimiento realmente va ms all de corregir problemas y debe basarse principalmente en considerar las extensiones al sistema segn nuevas necesidades. En otras palabras, se basa en generar nuevos desarrollos pero tomando como punto de partida el sistema ya existente. En cierta manera es regresar al resto de las actividades pero

Weitzenfeld: Captulo 3

21

sin partir de cero. Como se mencion en la seccin 3.1, el proceso de mantenimiento tendr que adaptarse a las nuevas circunstancias del desarrollo. 3.5 Mtodos y Metodologas Los mtodos definen las reglas para las distintas transformaciones dentro de las actividades. Las metodologas definen el conjunto de mtodos. La seleccin de las metodologas a utilizarse es otra de las decisiones crticas en el proceso de software. Hasta hace poco, los mtodos para anlisis y diseo eran muy similares y las herramientas de software como apoyo a los mtodos no eran ms que herramientas de dibujo asistidas por computadora. En los ltimos aos, los desarrolladores de software se han hecho ms sofisticados en su comprensin de los beneficios de mtodos completos y comprensibles, dando mayor nfasis a las metodologas y notaciones correspondientes. Dado que se ha escogido utilizar tecnologa orientada a objetos, los nicos mtodos de anlisis y diseo de los cuales se debe escoger son aquellos que se basan en conceptos orientados a objetos. Los mtodos deben proveer tcnicas para crear modelos estticos y dinmicos del sistema. El modelo esttico incluye descripciones de los objetos que existen en el sistema, su relacin mutua, y las operaciones que pueden ejecutarse en el sistema. El modelo dinmico incluye la secuencia aceptada de operaciones sobre el sistema, al igual que la secuencia de mensajes entre objetos necesaria para ejecutar las operaciones del sistema. En general, los mtodos difieren en los diversos aspectos que apoyan, tales como el tipo de informacin recopilada, sus requisitos de consistencia, el dominio de aplicabilidad, modelo de proceso, modelos generados y notaciones. ? ? Tipo de Informacin Recopilada: Los mtodos de anlisis y diseo que se consideran buenos deben proveer un conjunto de tcnicas para recopilar informacin. Estas tcnicas se usan para crear una descripcin completa del dominio del problema y los medios para crear una solucin que satisfaga los objetivos de calidad del sistema. Si la meta del proyecto es crear componentes reusables, entonces una consideracin en la seleccin del mtodo de anlisis y diseo es si el mtodo tiene tcnicas para desarrollar resultados reusables. ? ? Requisitos de Consistencia: Consistencia es un atributo de un modelo donde todos los componentes son precisos y relacionados apropiadamente, lo que sirve de base para la integridad del modelo. Los mejores mtodos evitan los errores de consistencia e integridad, mientras que mtodos aceptables tienen por lo menos tcnicas para detectar si existen violaciones. Los mtodos deben tener herramientas que apoyen la verificacin de los modelos. Este requisito significa que las herramientas sencillas que apoyan slo diagramas en base a cierta notacin no son de inters ya que carecen de manejo de consistencia. Los mtodos deben indicar claramente donde falta informacin y cuando sta no es crtica para continuar con la siguiente actividad. Adems, las herramientas asociadas con el mtodo deben apoyar la liga de modelos que han sido derivados independientemente. Los mtodos deben permitir apoyar particiones y trabajo independiente que, para sistemas grandes con mltiples analistas y diseadores, ser uno de los aspectos ms importantes. ? ? Dominio de Aplicabilidad: Algunos mtodos slo se aplican a sistemas basados en comportamiento secuencial, mientras que otros mtodos manejan concurrencia, e incluso otros se aplican especialmente para sistemas de tiempo real (Selic, Gullekson, y Ward 1994). Se debe escoger mtodos que apoyen las caractersticas del dominio escogido. ? ? Modelo de Proceso: Los mtodos seleccionados tambin deben ajustarse al modelo de proceso preferido, apoyando las entradas esperadas de las distintas actividades, especialmente documentacin. Los mtodos no deben contradecir el orden deseado de actividades del modelo de proceso, deben proveer guas para revisiones correspondientes y deben apoyar modelos evolucionables. Consideraciones de mantenimiento tambin pueden influir en la seleccin de los mtodos. Se recomienda seleccionar mtodos que administran suficiente informacin para explicar por qu existe una estructura particular en los distintos modelos. La explicacin debe rastrear las suposiciones, metas y objetivos que llevaron hacia ese resultado. Los estructuras finales de implementacin deben ser consistentes con aquellas especificadas en los modelos anteriores. A veces es til poder hacer ingeniera en reversa en un sistema, o sea, derivar el modelo de diseo del cdigo final. En tal caso, se debe evaluar la extensibilidad del mtodo para apoyarla. ? ? Modelos Generados: Una forma para calificar un mtodo es determinar si los modelos que se desean producir pueden derivarse de la informacin que se obtiene y es representada por el mtodo. Por ejemplo, si en cierto desarrollo se requiere un modelo de seguridad o un modelo de rendimiento antes de poder implementar una solucin, entonces los mtodos que se deben considerar son aquellos que manejan directamente estos requisitos o aquellos que pueden agregarse para derivar la informacin deseada. Se evala el apoyo provisto por el mtodo y sus herramientas, y cunto esfuerzo se necesita para extraer los resultados requeridos. Una notacin es usada para comunicar el resultado de aplicar un mtodo, donde los elementos de la notacin consisten de elementos grficos, textuales, o alguna combinacin de ambos. A menudo se confunde el concepto de

Weitzenfeld: Captulo 3

22

actividad, mtodo, y notacin, los cuales estn relacionados pero son diferentes. La Figura 3.8 ilustra la relacin entre ellos.

Modelo de Proceso

Mtodo

Notacin

Anlisis

Mtodos de Anlisis OBA Fusion Objectory actor 1 Casos de Uso en Objectory

actor 2

Diseo

Mtodos de Diseo OMT Booch Fusion RDD

clase 1

clase 2

Asociacin de clases en OMT

Implementacin

Mtodo de Codificacin Tcnicas de Java Tcnicas de C++ Tcnicas de Smalltalk

class Cuadrado extends Figura { .... }

Figura 3.8 Contraste de las actividades de desarrollo de software versus mtodos y notacin utilizados. El lado izquierdo ilustra posibles actividades de un modelo, el del medio muestra ejemplos de mtodos para llevar a cabo estas actividades, y el lado derecho muestra ejemplos de notaciones para capturar el resultado de los mtodos. La mayora de los mtodos pueden compararse examinando cmo se comunican los modelos estticos y dinmicos, o sea, que tipo de diagrama de representacin textual o grfica se recomienda. Una notacin no es simplemente buena o mala, si no ms o menos efectiva en comunicar los resultados entre los miembros del equipo. La meta es escoger la notacin que sea ms efectiva para los equipos. Una buena notacin debe tener suficiente poder de expresividad para modelar conceptos a nivel del detalle deseado. Algunas notaciones tienen un vocabulario ms extenso que otras por lo cual pueden representar mayores niveles de detalle. Tambin se desea una notacin que permita representar modelos a varios niveles de abstraccin. Una buena notacin es tambin una que se puede aprender rpidamente, donde sus smbolos tienen sentido y son intuitivos. Las notaciones ms pobres expresan grandes cambios semnticos con pequeos cambios en los smbolos. La ubicacin, orientacin o escala de un smbolo tiene un profundo significado que a menudo slo el diseador de la notacin puede apreciar. Las notaciones deben comunicar informacin de manera que minimicen la sorpresa del lector. Como no siempre se tiene apoyo de herramientas para dibujar una notacin, se quiere una notacin que fcilmente se pueda dibujar a mano. La mayora de las organizaciones an utilizan mtodos que no estn basados en conceptos orientados a objetos. Utilizan mtodos tradicionales, como los estructurados, basados en modelos de datos, descomposicin funcional, o programacin de flujo de datos. Cuando tales organizaciones desean usar lenguajes orientados a objetos y componentes orientados a objetos reusables, el enfoque debe modificarse. Existe una gran disparidad entre los mtodos tradicionales y los orientados a objetos, y entre los modelos de anlisis y diseo creados con los mtodos tradicionales y con los orientados a objetos, incluyendo el ciclo de vida del software. Los mtodos tradicionales, especialmente la descomposicin funcional, asumen que todos los requisitos primarios pueden representarse como funciones que estn relacionados en una estructura jerrquica fija y pueden implementarse de la misma forma. Este enfoque no toma en cuenta las estrategias de desarrollo incremental e iterativo para construir sistemas con

Weitzenfeld: Captulo 3

23

tecnologa orientada a objetos, ya que no reconoce que la gente resuelve problema de una forma no estructurada. Ms an, las funciones que estn dentro de las jerarquas tienden a apoyar slo una superfuncin, dificultando el reuso. Los mtodos tradicionales se basan en la idea de que los datos y funciones deben separarse para que nuevas funciones puedan aadirse utilizando los datos comunes. La mayora de las tcnicas de los mtodos tradicionales tratan con el modelado de datos. La idea que los datos son independientes de las funciones contradice la base conceptual de la tecnologa orientada a objetos. En general, pueden existir proyectos que usen mtodos tradicionales con tecnologa orientada a objetos, pero se trabajara el doble para obtener los comportamientos del sistema y los datos asociados. 3.5.1 Metodologas Estructuradas La metodologa de anlisis y diseo estructurado, conocido por sus siglas en ingls como SA/SD (Structured Analysis and Structured Design) ha tenido mucho seguimientos durante las ltimas dcadas (Yourdon y Constantine 1978, DeMarco 1979, Page-Jones 1980, Ward y Mellor 1985, Yourdon 1989, Martin y Jackson). Existen mltiples variaciones al concepto bsico estructurado como son SADT (Structured Analysis and Design Technique) (Ross, 1985) y RDD (Requirement Driven Design) basado en SREM (Alford, 1985). La metodologa estructurada se basa primordialmente en la divisin entre funciones y datos, como se mencion en la seccin 2.1. Extendiendo este concepto bsico, la metodologa estructurada identifica durante el anlisis las funciones del sistema, mientras que durante el diseo identifica los datos. Otros enfoques como la programacin funcional rompen con este esquema (Backus 1977, Bird and Wadler 1988). Durante las fases de requisitos y anlisis se utilizan las siguientes herramientas para describir el sistema lgico: diagramas de flujo de datos, especificacin de procesos, diccionario de datos, diagramas de transicin de estados, y diagramas de entidad-relacin. Durante las fases de diseo e implementacin, los detalles son incorporados a los modelos anteriores y los diagramas de flujo de datos son convertidos a cartas estructuradas (charts) las cuales especifican el cdigo fuente. ? ? Diagramas de flujo de datos (DFD) sirven para modelar la transformacin de los datos en el sistema, y es uno de los modelos ms importantes de SA/SD. Un diagrama de flujo de datos se compone de procesos, flujo de datos, actores (entidades externas) y almacenamiento de datos. Durante el diseo, los procesos del DFD son agrupados en tareas y asignados para su ejecucin en el sistema operativo. Procesos del DFD se convierten en funciones del lenguaje de programacin, y una carta estructurada es creada mostrando el rbol de llamadas de procedimientos. ? ? Especificacin de procesos sirve para describir los procesos a nivel ms detallado. Esta especificacin comienza desde el nivel ms alto del diagrama de flujo de datos, donde los procesos se dividen de manera recursiva, con ayuda de subdiagramas, hasta que existen procesos suficientemente pequeos que sean fciles de implementar. Esta especificacin puede ser expresada con tablas de decisin, pseudo-cdigo, u otras tcnicas. ? ? Diccionario de datos contiene detalles omitidos en los diagramas de flujo de datos, definiendo el significado de los nombres de los flujos y almacenamiento de datos. ? ? Diagramas de transicin de estados modelan el comportamiento que depende del tiempo. La mayora de los diagramas de transicin describen procesos de control o tiempo de ejecucin de funciones y acceso a datos causado por eventos. ? ? Diagramas de Entidad-Relacin (ER) (Chen, 76) muestran la relacin entre el almacenamiento de datos que de otra forma slo seran vistos en la especificacin de proceso. Cada elemento del ER corresponde a un dato almacenado. (La notacin del diagrama de clases es una extensin del diagrama ER.) Este es el enfoque ms comn para el modelo de informacin. ER es una tcnica grfica que es popular ya que su notacin es fcil de comprender, y suficientemente poderosa para modelar problemas del mundo real. Los diagramas ER son usualmente traducidos directamente a implementaciones de bases de datos. 3.5.2 Metodologas Orientadas a Objetos Los sistemas orientados a objetos se desarrollan alrededor de entidades del dominio del problema, lo cual resulta en desarrollos bastante estables. El anlisis orientado a objeto, a diferencia del estructurado, que considera comportamiento y datos de forma separada, combina ambos. Las caractersticas principales de los orientados a objetos son que ofrecen una forma de pensar ms que una forma de programar. Adems, reducen la complejidad en el diseo de software, y permiten atacar los errores durante el diseo en lugar de durante la implementacin, donde el costo de reparacin es bastante mayor. Las actividades son: (i) encontrar los objetos (dominio de la aplicacin y problema particular); (ii) organizar los objetos (clases, asociaciones); (iii) describir cmo los objetos interactan

Weitzenfeld: Captulo 3

24

(escenarios, casos de uso); (iv) definir las operaciones de los objetos (interfaces); y (v) definir los objetos internamente (atributos). Existen diversas formas de encarar estas actividades en conjunto y de manera particular. Las tcnicas de anlisis guan al analista en la transformacin de la informacin provista por los expertos a las representaciones del modelo de anlisis en el espacio del modelo de anlisis. La naturaleza exacta de los intercambios varan, y es aqu donde los diferentes mtodos de anlisis divergen. Aunque la mayora de los mtodos estn de acuerdo en los conceptos para modelar un problema, los mtodos varan segn las tcnicas a utilizarse. Por ejemplo, se han propuesto diversas tcnicas para identificar objetos en el dominio del problema: ? ? Escenarios: Capturar comportamientos del sistema en guiones (scripts) o casos de usos para derivar los roles y responsabilidades del sistema, como con Object Behavior Analisis (OBA) (Rubin and Goldberg 1992) y Objectory (Jacobson 1992). Este es uno de los enfoques ms utilizados en la actualidad. ? ? Tarjetas CRC: Lluvia de ideas (brainstorm) entre un grupo de expertos dando como resultado los objetos del dominio del problema que son anotadas en las tarjetas (Wirfs-Brock 1990). ? ? Ingenieria de informacin: Identificar la estructura de la informacin que se guarda y mantiene por las aplicaciones, y mapearla a objetos. En el caso de Shaler y Mellor (1988), se adapta el modelo entidad-relacin, estableciendo los objetos como entidades. ? ? Resaltar Texto: Una tcnica muy utilizada es subrayar nombres y verbos en la especificacin de requisitos, como se hace en OMT. Los diagramas que se utilizan tienen cierta similitud con los utilizados en las metodologas estructuradas aunque obviamente tienen sus diferencias. A diferencia de las metodologas estructuradas, los diagramas en las metodologas orientadas a objetos tienden a variar ms. ? ? Diagramas de clases son los ms importantes describiendo los componentes bsicos para las arquitecturas del anlisis y diseo. A diferencia de los diagramas de flujo, que no son utilizados por la mayora de las metodologas orientadas a objetos, los diagramas de clases muestran relacin de asociacin entre objetos y no flujo de datos entre ellos. ? ? Diagramas de casos de uso son los que utilizaremos en este libro y se basan en Objectory correspondientes a la especificacin de requisitos. Son completados por documentos en forma de textos. ? ? Diagramas de transicin de estado son probablemente los nicos que tienen su equivalente en las metodologas estructuradas mostrando los cambios de estado en los objetos. ? ? Diagramas de interaccin, tambin conocidos como diagramas de eventos, muestran aspectos dinmicos de los objetos en relacin a la comunicacin con otros objetos en el tiempo. ? ? Diagramas de colaboracin son diagramas que resumen los aspectos de comunicacin entre objetos de un sistemas. ? ? Diagramas de subsistemas son diagramas que muestran grupos de clases utilizadas en los distintos subsistemas. Existe un gran nmero de metodologas orientadas a objetos, siendo las ms importantes las mostradas en la Tabla 3.4. Nombre del Mtodo Descripcin RDD Responsibility-Driven Design [Wirfs-Brock 90] OOAD Object-Oriented Analysis and Design [Coad y Yourdon 91] OOAD Object-Oriented Analysis and Design [Booch 1991] OMT Object Modeling Technique [Rumbaugh et al. 1991] OOSE/Objectory Object Oriented Software Engineering [Jacobson 92] OOK/MOSES Object-Oriented Knowledge [Henderson-Sellers et al. 92] OOSA Object-Orientd System Analysis [Schlaer y Mellor 92] OOAD Object-Oriented Analysis and Design [Martin y Odell 92] OOSA Object-Oriented Systems Analysis [Embley et al. 92] OBA Object Behavior Analysis [Rubin y Goldberg 92] OORA Object-Oriented Requirements Analysis [Firesmith 93] Synthesis Synthsis Method [Page-Jones y Weiss 93] OOSD Object-Oriented System Development [de Champeaux 93] OOAD/ROSE Object-Oriented Analysis & Design [Booch 94] FUSION Object-Oriented Development [Coleman et al. 94] Unified Rational's Unified Software Development Process [Booch et al. 99] Tabla 3.4 Mtodos de desarrollo de software

Weitzenfeld: Captulo 3

25

3.5.3 Integracin de Metodologas Un aspecto importante que resulta de las discusiones de las secciones anteriores es que es sumamente importante escoger una metodologa apropiada al tipo de desarrollo que se est haciendo. Ms an, a veces es necesario integrar metodologas diferentes aplicadas a las diferentes actividades de desarrollo. Esto ocurre generalmente porque las metodologas tienen fortalezas para ciertos aspectos del desarrollo pero no para otros. El integrar metodologas, sin embargo, requiere tener mucho cuidado asegurando que los resultados de una sirvan como entrada a la otra. Esto no significa que las metodologas se puedan mezclar durante el desarrollo de una misma actividad. 3.6 Herramientas Existen herramientas que apoyan los diversos aspectos del proceso de software. Al conjunto de herramientas aplicables al desarrollo de sistemas de software se les conoce como CASE (Computer-Aided Software Engineering), herramientas para asistir al desarrollador en las diferentes fases del ciclo de vida del proceso del software: planeacin, requisitos, anlisis, diseo, implementacin, pruebas (verificacin y validacin), documentacin, mantenimiento y administracin. Las herramientas varan en el tipo de componentes que incorporan, editores (textuales y grficos), programadores (codificadores, depuradores, compiladores y ensambladores), verificadores y validadores (analizadores estticos y dinmicos y diagramas de flujos), medidores (monitores), administradores de la configuracin (versiones y libreras) y administradores del proyecto (estimacin, planeacin y costo). La herramienta particular a ser usada debe apoyar el modelo de proceso escogido, y no se debe considerar mtodos independientes de herramientas. Si las herramientas son buenas, stas deben resultar en mejoras notorias en la produccin del sistema. Las herramientas deben manejar aspectos de administracin de informacin, generar los distintos tipos de diagramas e incluso el cdigo final. La sofisticacin de las herramientas vara desde aquellas que apoyan a un slo desarrollador en un slo proyecto hasta aquellas que apoyan mltiples desarrolladores trabajando juntos en un proyecto con almacenamiento compartidos, e incluso mltiples proyectos. Existen actualmente productos que manejan mltiples mtodos y notaciones. La idea llama la atencin si se considera a estas herramientas como manejadores de almacenamiento, donde la informacin obtenida por uno o ms mtodos se puede almacenar en una representacin comn y luego mostrarse con la notacin preferida, una de las motivaciones detrs de UML. La idea de una sola herramienta que pudiese ajustarse a distintos tipos de proyectos parece ser buena, pero en la prctica puede que no lo sea, dado que se arriesga crear un gran almacenamiento de datos de informacin no relacionada, sin enfocarse bien a ningn mtodo. Adems, se arriesga crear una situacin donde los diferentes productos generados no son consistentes. El xito de las herramientas actuales de proveer mltiples notaciones se asocia con el hecho de que los distintos mtodos son fundamentalmente similares en relacin a los conceptos bsicos que apoyan. Se debe seleccionar herramientas de acuerdo a los siguientes criterios: ? ? Proveer apoyo explcito para cada paso del mtodo. ? ? Administrar toda la informacin que el mtodo requiere obtener o especificar. ? ? Poder manejar grandes cantidades de informacin y ser escalable. ? ? Incluir un mecanismo por el cual se pueda probar que la informacin recolectada es consistente. ? ? Apoyar la organizacin de los diagramas de manera automtica. ? ? Manejar mltiples usuario simultneos en uno o mltiples proyectos. ? ? Poder generar una implementacin inicial junto con la documentacin. ? ? Apoyar ingeniera en reversa para asegurar que cambios directos en la implementacin sean consistentes con los modelos administrados. La Tabla 3.5 hace un resumen los aspectos ms relevantes para seleccionar entre los diversos mtodos. Criterio de Seleccin Conceptos apoyados Propiedad notacional Cobertura del modelo de proceso Tipos de aplicaciones Personalizacin Descripcin El mtodo debe apoyar conceptos bsicos que se cree son significativos en resolver el problema. La notacin debe ser comprensible inmediatamente, y debe haber un subconjunto mnimo para principiantes. Debe ser dibujable a mano. El mtodo debe aplicarse a las actividades identificadas en el modelo de proceso. El mtodo debe orientarse hacia el tipo de aplicaciones que la organizacin construye. Si se espera refinar algn mtodo seleccionado, entonces el mtodo debe identificar aspectos apropiados para presonalizacin. Alternativamente, si se espera componer varios

Weitzenfeld: Captulo 3

26

mtodos, debe asegurarse que las entradas y salidas sean complementarias. El mtodo debe ser consistente con la habilidad de la organizacin para incorporar nueva tecnologa. El mtodo propuesto debe ser fcil de aprender. El mtodo debe mantener un mapa claro y consistente entre componentes. El mtodo (y herramientas relacionadas) deben ser apropiados para el tamao del problema a resolverse. Un mtodo necesita escalar hacia arriba y abajo segn las necesidades del proyecto. Material colateral El mtodo debe producir los documentos colaterales requeridos por la organizacin. Ambiente de la Las herramientas que apoyen al mtodo deben integrarse correctamente, con un acceso herramienta abierto a la informacin recolectada. Momento en el Se debe tener confianza en que el mtodo y herramientas se mantendrn en el mercado, mercado para los cuales hay amplio entrenamiento y consultores. Tabla 3.5 Criterio de seleccin para mtodos de desarrollo de software Enfoque evolucionario versus revolucionario Aprendizaje Rastreabilidad Escalabilidad

Weitzenfeld: Proceso de SW

10/11/2002

Weitzenfeld: Captulo 4

Parte II Modelado y Programacin Orientada a Objetos

En esta segunda parte se describir la programacin orientada a objetos desde dos perspectivas distintas. La primera es el modelado (Captulo 4), una descripcin terica de los conceptos bsicos de la orientacin a objetos, en nuestro caso utilizando la notacin UML (Unified Modeling Language). La segunda es la programacin (Captulo 5), una descripcin prctica basada en el modelado orientado a objetos, en nuestro caso utilizando el lenguaje Java.

4 Modelado con UML

El modelado, o modelo de objetos, describe los conceptos principales de la orientacin a objetos: las estructuras estticas y sus relaciones. Las principales estructuras estticas son los objetos y clases, los cuales estn compuestos de atributos y operaciones, mientras que las principales relaciones entre objetos y entre clases corresponden a las ligas y asociaciones, respectivamente. Estos temas y otros sern descritos en este captulo, en trmino de los objetos, clases, atributos, operaciones, asociaciones, composicin, herencia y mdulos. 4.1 Objetos Los objetos son las entidades bsicas del modelo de objeto. La palabra objeto proviene del latn objectus, donde ob significa hacia, y jacere significa arrojar; o sea que tericamente un objeto es cualquier cosa que se pueda arrojar. Ejemplo: Una pelota o un libro se pueden arrojar, por lo tanto estos son objetos. Por otro lado, un avin o un elefante tambin se consideran objetos, aunque sean bastante pesados para ser arrojados. Los objetos son ms que simples cosas que se puedan arrojar, son conceptos pudiendo ser abstractos o concretos. Ejemplo: Una mesa es un objeto concreto, mientras que un viaje es un objeto abstracto. Los objetos corresponden por lo general a sustantivos, pero no a gerundios. Ejemplo: Mesa y viaje son ambos sustantivos y por lo tanto objetos. Trabajando y estudiando son gerundios por lo cual no se consideran objetos. Cualquier cosa que incorpore una estructura y un comportamiento se le puede considerar como un objeto. Ejemplo: Una pelota es slida y redonda y se le puede arrojar o atrapar. Un libro es rectangular y slido y se le puede abrir, cerrar, y leer. Un objeto debe tener una identidad coherente, al que se le puede asignar un nombre razonable y conciso. Ejemplo: Se consideran manzanas todas las frutas con un sabor, textura, y forma similar. La existencia de un objeto depende del contexto del problema. Lo que puede ser un objeto apropiado en una aplicacin puede no ser apropiado en otra, y al revs. Por lo general, existen muchos objetos en una aplicacin, y parte del desafo es encontrarlos. Ejemplo: La temperatura se puede considerar un objeto abstracto, teniendo propiedades tales como el valor de la temperatura y el tipo de la escala en que se mide (Celsius o Fahrenheit). Por otro lado, si hablamos de un termmetro, la temperatura pasa a ser una propiedad del termmetro. Los objetos se definen segn el contexto de la aplicacin. Ejemplo: Una persona llamada Juan Prez se considera un objeto para una compaa, mientras que para un laboratorio el hgado de Juan Prez es un objeto. Una universidad como la ITAM se considera un objeto, mientras que dentro de la ITAM los objetos seran las aulas, los estudiantes y los profesores. Los objetos deben ser entidades que existen de forma independiente. Se debe distinguir entre los objetos, los cuales contienen caractersticas o propiedades, y las propias caractersticas. Ejemplo: El color y la forma de una manzana no se consideran propiamente objetos, sino propiedades del objeto manzana. El nombre de una persona se considera una propiedad de la persona. Un grupo de cosas puede ser un objeto si existe como una entidad independiente. Ejemplo: Un automvil se considera un objeto el cual consiste de varias partes, como el motor y la carrocera. Los objetos deben tener nombres en singular, y no en plural. Ejemplo: Un automvil es un objeto, automviles son simplemente muchos objetos y no un solo objeto. Parte de una cosa puede considerarse un objeto. Ejemplo: La rueda, la cual es parte del automvil, se puede considerar un objeto. Por otro lado, el lado izquierdo del automvil sera un mal objeto. Los objetos deben tener nombren razonables y concisos para evitar la construccin de objetos que no tengan una identidad coherente. Ejemplo: Datos o informacin no son nombres concisos de objetos. Por otro lado, un estudiante es un objeto, ya que contiene propiedades como el nmero de matrcula y nombre del estudiante, adems incluye un comportamiento tal

Weitzenfeld: Captulo 4

como ir a clases, presentar exmenes, y graduarse. Todos los estudiantes cuyos apellidos comiencen con "A" sera un mal objeto ya que el nombre del objeto no es conciso. El objeto integra una estructura de datos (atributos) y un comportamiento (operaciones). 4.1.1 Diagramas de Objetos Los objetos se describen grficamente por medio de un diagrama de objetos o diagrama de instancias. La notacin general para una objeto es una caja rectangular conteniendo el nombre del objeto subrayado, el cual sirve para identificar al objeto, como se muestra en la Figura 4.1.

Nombre del Objeto

Figura 4.1. Notacin para un objeto. Ejemplo: Los objetos Juan Prez y ITAM se muestran en la Figura 4.2.

Juan Prez

ITAM

Figura 4.2. Notacin para los objetos Juan Prez y ITAM. 4.1.2 Identidad Los objetos se distinguen por su propia existencia, su identidad, aunque internamente los valores para todos sus datos sean iguales.. Todos los objetos se consideran diferentes. Ejemplo: Si tenemos una biblioteca llena de libros, cada uno de esos libros, como La Ilada, Hamlet, La Casa de los Espritus, etc., se consideran e identifican como objetos diferentes. Dos manzanas aunque sean exactamente del mismo color y forma, son diferentes objetos. Los objetos tienen un nombre que puede no ser nico. Ejemplo: Pueden existir mltiples copias de un solo libro, lo cual requiere identificadores especiales para distinguir entre diferentes objetos con propiedades similares, como el cdigo del libro en la biblioteca. Los objetos necesitan un identificador interno nico cuando son implementados en un sistema de computacin para accesar y distinguir entre los objetos. Estos identificadores no deben incluirse como una propiedad del objeto, ya que solo son importantes en el momento de la implementacin. Ejemplo: Los diferentes personas se distinguiran internamente dentro de una computadora por los identificadores Persona1, Persona2, Persona3, etc. Por otro lado, el nmero del seguro social de la persona es un identificador externo vlido, ya que existe fuera de la implementacin en una computadora. 4.2 Clases Una clase describe un grupo de objetos con estructura y comportamiento comn. (Clase y tipo no son necesariamente equivalentes, tipo se define por las manipulaciones que se le puede dar a un objeto dentro de un lenguaje y clase involucra una estructura, pudiendo corresponder a una implementacin particular de un tipo. En el captulo 5 se hablar ms de esto.) Las estructuras o propiedades de la clase se conocen como atributos y el comportamiento como operaciones. Una clase define uno o ms objetos, donde los objetos pertenecen a la clase, teniendo caractersticas comunes. Ejemplo: Juan Prez y Mara Lpez se consideran miembros de la clase persona, donde todas las personas tienen una edad y un nombre. El ITAM y la UNAM pertenecen a la clase universidad, donde todas las universidades tienen una direccin y un grado mximo. Chrysler y Microsoft pertenecen a la clase compaa, donde todas las compaas tienen una direccin, un nmero de empleados, y una ganancia al ao. Una clase se considera un "molde" del cual se crean mltiples objetos. Ejemplo: La clase es como un molde de una cermica de la cual se pueden crear mltiples cermicas, todas con exactamente las mismas caractersticas. Para modificar las cermicas hay que primero construir un nuevo molde. Al definir mltiples objetos en clases se logra una abstraccin del problema. Se generaliza de los casos especficos definiciones comunes, como nombres de la clase, atributos, y operaciones. Ejemplo: Los objetos impresora a lser, impresora de burbuja, e impresora de punto son todos objetos que pertenecen a la clase impresora. Una clase como se ha definido en esta seccin se conoce tambin como clase bsica.

Weitzenfeld: Captulo 4

4.2.1 Diagramas de Clases Las clases se describen por medio del diagrama de clases. La notacin para una clase es una caja rectangular conteniendo el nombre de la clase con letras negritas, como se muestra en la Figura 4.3.

Nom bre de la Clase

Figura 4.3. Notacin para una clase. Ejemplo: Las clases Persona y Universidad se muestran en la Figura 4.4.

Persona

Universidad

Figura 4.4. Notacin para los clases Persona y Universidad. La notacin general para el objeto se extiende mediante el nombre de la clase subrayado seguido al nombre del objeto, como se muestra en la Figura 4.5.

Nombre del Objeto : Nombre de la Clase

Figura 4.5. Notacin para un objeto incluyendo el nombre de la clase. Ejemplo: Los objetos Juan Prez y ITAM se muestran en la Figura 4.6 incluyendo el nombre de sus respectivas clases Persona y Universidad.

Juan Prez : Persona

ITAM : Universidad

Figura 4.6. Notacin para los objetos Juan Prez y ITAM incluyendo el nombre de la clase. Por lo general, se utilizan ms los diagramas de clases que los diagramas de objetos, ya que los diagramas de clases son ms generales, y corresponde a varios diagramas de objetos. 4.2.2 Instanciacin El proceso de crear objetos pertenecientes a una clase se conoce como instanciacin, donde los objetos son las instancias de la clase. El objeto es la instancia de la clase a la que pertenece. Se utiliza un flecha punteada para mostrar los objetos como instancias de las clases, como se muestra en la Figura 4.7. <<instanceOf>> Nombre de la Clase Nombre del Objeto Figura 4.7. Notacin para instanciacin de objetos. Ejemplo: Juan Prez y Mara Lpez son instancias de la clase Persona, como se muestra en la Figura 4.8.

<<instanceOf>> Persona <<instanceOf>>

Juan Prez : Persona

Mara Lpez : Persona

Figura 4.8. Notacin para la instanciacin de objetos de la clase Persona. Pueden ser instanciados un nmero indefinido de objetos de cierta clase.

Weitzenfeld: Captulo 4

4.3 Atributos Los atributos definen la estructura de una clase y de sus correspondientes objetos. El atributo define el valor de un dato para todos los objetos pertenecientes a una clase. Ejemplo: Nombre, edad, peso, son atributos de la clase persona. Color, precio, modelo, son atributos de la clase automvil. Los atributos corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos. Ejemplo: Nombre, edad, color, son sustantivos. Juan, 24, son sustantivos, y verde es un adjetivo. Se debe definir un valor para cada atributo de una clase. Los valores pueden ser iguales o distintos en los diferentes objetos. No se puede dar un valor en un objeto si no existe un atributo correspondiente en la clase. Ejemplo: el valor del atributo edad puede ser "24" para los objetos Juan Prez y Mara Lpez, y "15" para Ramn Martnez. Dentro de una clase, los nombre de los atributos deben ser nicos (aunque puede aparecer el mismo nombre de atributo en diferentes clases). Ejemplo: Las clases persona y compaa pueden tener ambas un atributo direccin, en cambio no pueden existir dos atributos llamados direccin dentro de la clase persona. Los atributos no tienen ninguna identidad, al contrario de los objetos. Ejemplo: Los atributos nombre y edad de la clase persona tienen valores simples. El valor para nombre puede ser "Juan" o "Mara", mientras que el valor para edad puede ser "17" o "25". (Ntese que pudieran existir dos objetos distintos con exactamente el mismo nombre y edad, donde estos identificaran dos personas distintas.) Un atributo como se ha definido en esta seccin se conoce tambin como atributo bsico. Los atributos se listan en el diagrama de clases a continuacin del nombre de la clase, en una segunda seccin, como se muestra en la Figura 4.9.
Nom bre de la Clase Lista de Atributos

Figura 4.9. Diagrama de clases conteniendo atributos. Ejemplo: En la Figura 4.10 se muestran dos atributos, Nombre y Edad, para la clase Persona.

Persona Nombre E da d
Figura 4.10. Diagrama de clases, para la clase Persona, conteniendo los atributos, Nombre y Edad. La notacin para el diagrama de objetos incluye los valores para los atributos que se ubican en el centro de la caja en letra normal a continuacin del nombre de la clase. Existen dos notaciones alternas: ? ? La notacin extendida se muestra en la Figura 4.11.

Nom bre de la Clase Atributo1 = Valor1 Atributo2 = Valor2 ...

Figura 4.11. Notacin extendida del diagrama de instancias, para objetos conteniendo valores de atributos. Ejemplo: En la Figura 4.12 se muestran dos objetos de tipo Persona, utilizando la notacin extendida. Los valores de los dos objetos para el atributo Nombre, son Mara Lpez y Juan Prez, y para el atributo Edad, 24 y 21, respectivamente. (Los valores para los atributos pueden ser o no iguales.)

Weitzenfeld: Captulo 4

Persona Nombre = Mara Lpez Edad = 21

Persona Nombre = Juan Prez Edad = 24

??

Figura 4.12. Diagrama de instancias, para dos objetos de tipo Persona, conteniendo valores de atributos, usando la notacin extendida. La notacin compacta se muestra en la Figura 4.13.
Nom bre de la Clase Valor-Atributo1 Valor-Atributo2 ...

Figura 4.13. Notacin compacta del diagrama de instancias, para objetos conteniendo valores de atributos. Ejemplo: En la Figura 4.14 se muestran dos objetos de tipo Persona, utilizando la notacin compacta. Los valores de los dos objetos para el atributo Nombre, son Mara Lpez y Juan Prez, y para el atributo Edad, 21y 24, respectivamente. En esta notacin, es muy importante mantener el mismo orden de como han sido definido los atributos en el diagrama de clases.

Persona Mara Lpez 21

Persona Juan Prez 24

Figura 4.14. Diagrama de instancias, para dos objetos de tipo Persona, conteniendo valores de atributos, usando la notacin compacta. Se puede asociar con cada atributo un tipo de dato, por ejemplo, entero, cadena, etc., para restringir sus posibles valores. El tipo se aade, separado por dos puntos, al diagrama de clases inmediatamente despus del nombre del atributo. Tambin se puede definir un valor de omisin para cada atributo, o sea un valor que se asigna en caso de no haberse especificado uno, el cual se aade separado por un signo de "igual", a continuacin del tipo de dato. La notacin se muestra en la Figura 4.15. (El diagrama de objetos no vara con respecto a esta informacin adicional.)
Nombre de la Clase Atributo1 : Tipo1 = Valor-Omisin1 Atributo2 : Tipo2 = Valor-Omisin2 ...

Figura 4.15. Notacin extendida para diagrama de clases conteniendo atributos. Ejemplo: En la Figura 4.16 se muestran los dos atributos de la clase persona, nombre y edad, donde nombre est definido como una cadena de caracteres, con valor de omisin " ", mientras que edad est definido como un entero, con valor de omisin "0".
Persona Nombre : Cadena = " " Edad : Entero = 0

Figura 4.16. Diagrama de clases, para la clase persona, conteniendo atributos con definicin de tipo de datos y valores de omisin. La notacin compacta sera anloga a la anterior. (El detalle que se muestra en cualquier diagrama de puede variar.) Ejemplo: Los diagramas de clases que se muestran en la Figura 4.17 son todos correctos, variando segn el detalle deseado en la descripcin.

Weitzenfeld: Captulo 4

Persona Nombre Edad

Persona

Persona Nombre : Cadena Edad : Entero

Persona Nombre : Cadena = " " Edad : Entero = 0

Figura 4.17. Diagrama de clases, para la clase Persona, conteniendo diferente nivel de detalle. 4.3.1 Identificadores En el momento de incluir atributos en la descripcin de una clase se debe distinguir entre los atributos los cuales reflejan las caractersticas de los objetos en el mundo real, y los identificadores los cuales son utilizados exclusivamente por razones de implementacin. Estos identificadores internos del sistema no deben ser incluidos como atributos. Ejemplo: Nmero del Seguro Social, o nmero de la licencia de conducir, son identificadores vlidos del mundo real, en cambio un identificador para distinguir entre objetos de tipo persona no se debe incluir en el diagrama. En la Figura 4.18 se muestra la forma incorrecta de incluir un identificador (identificador : ID) en la clase del objeto, seguido por la forma correcta (omitido). Persona Persona nombre : Cadena nombre : Cadena edad : Entero edad : Entero no. seguro social no. seguro social no. licencia de conducir no. licencia de conducir identificador : ID

incorrecto correcto Figura 4.18. Diagrama de clases mostrando de forma incorrecta la inclusin de un atributo identificador, seguido por la forma correcta.
4.3.2 Atributos Derivados Los atributos bsicos son atributos independientes dentro del objeto. En contraste, los atributos derivados son atributos que dependen de otros atributos. Los atributos derivados dependen de otros atributos del objeto, los cuales pueden ser bsicos o derivados. La notacin es una diagonal como prefijo del atributo, como se muestra en la Figura 4.19.

Nom bre de la Clase / Atributo

Figura 4.19. Notacin para atributos derivados. Ejemplo: El Area de un Rectngulo se puede calcular conociendo su Ancho y Largo, por lo cual no se define como una atributo bsico de la caja, sino como un atributo derivado, como se muestra en la Figura 4.20.
Rectngulo Ancho Largo / Area

Figura 4.20. Diagrama mostrando Area como un atributo derivado de los atributos bsicos Ancho y Largo. 4.3.3 Restricciones de Atributos Los valores de los atributos de una clase pueden restringirse. La notacin para una restriccin (en ingls "constraint") es incluir, por debajo de la clase y entre corchetes, la restriccin para los valores del atributo, como se muestra en la Figura 4.21.

Nombre de la Clase Lista de Atributos { restriccin } Figura 4.21. Notacin para restriccin en un diagrama de clases.

Weitzenfeld: Captulo 4

Ejemplo: Un Rectngulo puede restringir que su Ancho y Largo sean siempre iguales, lo que es equivalente a un Cuadrado. As mismo, el Area del Rectngulo est definida como el Ancho por el Largo. Las dos restricciones se muestran en la Figura 4.22.
Rectngulo Ancho Largo / Area { Ancho = Largo } { Area = Ancho X Largo }

Figura 4.22. Diagrama mostrando dos restricciones para un Rectngulo: la restriccin que el Largo sea igual al Ancho para el caso de cuadrados, y la restriccin que el Area es igual al Ancho por el Largo. 4.4 Operaciones Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase particular. La operacin puede ser una accin ejecutada por el objeto o sobre el objeto. Ejemplo: Arrojar, atrapar, inflar, y patear, son operaciones para la clase pelota. Abrir, cerrar, ocultar, y dibujar, son operaciones para la clase ventana. Las operaciones deben ser nicas dentro de una misma clases, aunque no necesariamente para diferentes clases. Ejemplo: Las clases pelota y libro pueden las dos tener operaciones de comprar, pero no pueden tener cada una dos operaciones comprar. No se debe utilizar el mismo nombre para operaciones que tengan un significado totalmente diferente. Ejemplo: No se debe utilizar el mismo nombre invertir para la operacin de invertir una figura y para la operacin de invertir una matriz, ya que son operaciones totalmente diferentes. Invertir una figura es rotarla por 180 grados, mientras que invertir una matriz M es encontrar su inverso N, para que MxN = 1. Se deben usar nombres diferentes, como invertir-figura e invertir-matriz. Las operaciones pueden tener argumentos, o sea, una lista de parmetros, cada uno con un tipo, y pueden tambin devolver resultados, cada uno con un tipo. Las operaciones se incorporan en la tercera seccin de la clase, como se muestra en la Figura 4.23.

Nombre de la Clase Lista de Atributos Lista de Operaciones

Figura 4.23. Notacin para diagrama de clases conteniendo atributos y operaciones. Ejemplo: En la Figura 4.24 se muestra tres clases, Persona, Universidad y Rectngulo, conteniendo atributos y operaciones. Trabajar y Votar son operaciones en Persona; Ensear y Graduar son operaciones en Universidad; mientras que Dibujar y Borrar son operaciones en Rectngulo.
Persona Nombre Edad Trabajar() Votar() Universidad Nom bre D ireccin Ensear() Graduar () R ectngulo Ancho Largo Dibujar() Borrar()

Figura 4.24. Diagrama de clases conteniendo atributos y operaciones para las clases Persona, Universidad y Rectngulo. En la Figura 4.25 se muestra la notacin extendida para una clase conteniendo atributos y operaciones, donde las operaciones pueden incluir una lista de tipos de argumentos, adems de un lista de tipos de resultados.

Weitzenfeld: Captulo 4

Nombre de la Clase Atributo1 : Tipo1 = Valor-Omisin1 Atributo2 : Tipo2 = Valor-Omisin2 ... Operacin1(Lista-Tipo-Arg1) : Tipo-Result1 Operacin2(Lista-Tipo-Arg2) : Tipo-Result2 ...
Figura 4.25. Notacin extendida para una clase, conteniendo atributos y operaciones. Ejemplo: En la Figura 4.26 se muestra dos clases, Figura y Archivo, conteniendo atributos y operaciones. Mover y Rotar son operaciones de Figura conteniendo los argumentos V de tipo vector y Angulo, respectivamente. Ambas operaciones devuelven un resultado de tipo Booleano el cual devuelve un valor de Cierto o Falso (True o False). Imprimir es una operacin de Archivo conteniendo un argumento D de tipo dispositivo que puede ser el nombre de una impresora, y el nmero N de copias a imprimir. El resultado puede ser un valor booleano.

Figura Posicin Color Mover(v:Vector)() : Booleano Rotar(Angulo)() : Booleano Nombre

Archivo

Imprimir(d:Dispositivo,n:Entero) : Booleano

Figura 4.26. Diagrama de clases de Figura y Archivo conteniendo atributos y operaciones con notacin extendida. Ntese que los objetos no incluyen ninguna informacin sobre sus operaciones, a diferencia de las clases, ya que las operaciones son idnticas para todos los objetos de una misma clase, a diferencia de los atributos que varan entre objetos en relacin a su valor. A continuacin se describen otros conceptos relacionados con operaciones: consultas, accesos, mtodos, polimorfismo, parametrizacin y firmas: ? ? Consultas. Las operaciones que no tienen efectos secundarios, las cuales no cambian los valores de los atributos en el objeto, se les llama consultas (query). Una consulta es una operacin que no modifica al objeto. Las consultas por lo general devuelven valores de atributos, bsicos o derivados, y pueden o no tener argumentos. Ejemplo: Para una clase Rectngulo conteniendo los atributos Ancho y Largo pueden existir operaciones de consulta para leer los valores del Ancho y Largo sin afectarlos. Una consulta se puede definir para la lectura de atributos derivados, ya que los atributos derivados no cambian los valores de los atributos del objeto. Ejemplo: En la clase Rectngulo el atributo Area puede ser ledo por medio de una consulta implementada como la multiplicacin de los valores de los atributos Largo y Ancho. La notacin para las operaciones de consulta es la misma que para las operaciones, la diferencia es slo en su comportamiento. Por regla general estas consultas no se incluyen de forma explcita en el modelo de objetos. Estas se agregan durante la etapa de diseo ya que son operaciones bastante bsicas. ? ? Accesos. Se puede definir operaciones de acceso para leer o escribir los atributos de un objeto. Si el acceso es hecho para leer solamente, sin afectar los valores de los atributos, entonces el acceso se considera tambin una operacin de consulta. Se utiliza la notacin de punto para indicar, dentro de la operacin de acceso, el acceso a un atributo: "objeto.atributo". Ejemplo: para accesar el nombre de una persona se utiliza: persona.nombre La notacin para las operaciones de acceso es la misma que para las operaciones, la diferencia es slo en su comportamiento. Por regla general estas operaciones de acceso no se incluyen de forma explcita en el modelo de objetos. Estas se agregan durante la etapa de diseo ya que son operaciones bastante bsicas. ? ? Mtodos. El trmino mtodo se utiliza para distinguir entre la operacin, como un concepto de alto nivel, de la propia implementacin de la operacin, algo correspondiente a un concepto de ms bajo nivel. Ejemplo: La operacin Imprimir de la clase Archivo se implementa mediante un mtodo Imprimir conteniendo un argumento llamado dispositivo, conteniendo el cdigo para la implementacin de la operacin Imprimir. En ciertos lenguajes de programacin orientados a objetos se permite incluir ms de un mtodo para implementar una misma operacin, en otras palabras mltiples descripciones de bajo nivel o implementaciones

Weitzenfeld: Captulo 4

??

?? ??

para un mismo concepto a alto nivel. En estos casos los mtodos varan segn el nmero y tipo de argumentos, debiendo ser todos los mtodos deben ser consistentes entre s. Ejemplo: La operacin Imprimir de la clase Archivo se puede implementar con diferentes mtodos. Un mtodo Imprimir contiene el argumento dispositivo el cual manda el archivo a la impresora correspondiente. Otro mtodo Imprimir, con exactamente el mismo nombre, pero sin argumentos, mandara el archivo a la pantalla, en lugar de la impresora. Polimorfismo. El polimorfismo se define como una misma operacin tomando diferentes formas. Una operacin se considera polimrfica si sta se implementa en diferentes clases de forma diferente. Ejemplo: Para las clases Archivo-ASCII y Archivo-PostScript pueden existir diferentes mtodos para implementar la operacin Imprimir. Estos mtodos corresponden a la misma operacin Imprimir, pero se implementan de diferentes formas. El Archivo-ASCII imprime el texto en ASCII, mientras que el Archivo-PostScript requiere un interpretador PostScript. Una operacin tambin se considera polimrfica si sta se implementa en una misma clase por diferentes mtodos, con diferente nmero y tipo de argumentos. Ejemplo: La operacin Imprimir de la clase Archivo implementada con diferentes mtodos Imprimir conteniendo diferente nmero de argumentos se considera polimrfica. Con polimorfismo el transmisor de un mensaje no necesita saber la clase del objeto receptor. Usando terminologa ms tcnica, el vnculo (binding) entre el mensaje recibido y la operacin apropiada se hace mediante: (i) un vnculo esttico durante la compilacin del lenguaje o (ii) un vnculo dinmico durante la ejecucin, el cual tambin se conoce como vnculo virtual. Parametrizacin. La parametrizacin de una operacin est definida por el nmero y tipo de argumentos de cada mtodo. Ejemplo: La parametrizacin de la operacin Imprimir de la clase Archivo est definida por su argumento de tipo dispositivo. Firmas. La firma de una operacin se define por el tipo y nmero de argumentos y el tipo de resultados que devuelve. Ejemplo: La firma de la operacin Imprimir en la clase Archivo est definida por su argumento de tipo dispositivo. En operaciones polimrficas a travs de diferentes clases las operaciones deben mantener la misma firma. Ejemplo: La operacin Imprimir para las clases Archivo-ASCII y Archivo-PostScript deben tener la misma firma a travs de sus respectivos mtodos.

4.5 Ligas y Asociacin La relacin entre objetos se conoce como liga. Una asociacin describe la relacin entre clases de objetos, y describe posibles ligas, donde una liga es una instancia de una asociacin, al igual que un objeto es una instancia de una clase. Tipos de asociaciones entre clases: ? ? Una asociaciones de conocimiento (acquaintance associations) es una asociacin esttica entre instancias y significa que una instancia conoce de la existencia de otra instancia. Denota conocimiento entre clases durante largos periodos. ? ? Una asociacin de comunicacin es una asociacin dinmica que modela la comunicacin entre dos objetos, sirviendo para intercambiar informacin con entre objetos. Denota relacin entre clases cuando existe una comunicacin ellos A travs de estas asociaciones, un objeto enva y recibe eventos. Ejemplo: Los objetos Juan Prez e ITAM estn relacionadas por la liga estudia-en que describe que "Juan Prez estudia en la ITAM". Ejemplo: Las clases Estudiante y Universidad estn relacionadas por la asociacin estudia-en que describe que un "estudiante estudia en la universidad". El nombre de una liga debe ser igual al nombre de la correspondiente asociacin. Ejemplo: Juan Prez es una instancia de la clase Estudiante, y ITAM es una instancia de la clase Universidad. Por lo tanto, la liga estudia-en entre Juan Prez y ITAM lleva el mismo nombre que la asociacin estudia-en entre Estudiante y Universidad. La asociacin, al igual que la liga, es por naturaleza bidireccional. Por lo general, el nombre de la liga o asociacin implica una direccin, pero puede ser invertida para mostrar la direccin opuesta. Cualquiera de las dos direcciones es igualmente correcta, aunque por lo general se acostumbra a leer de izquierda a derecha. Ejemplo: El opuesto de "estudiante estudia en la universidad" sera "universidad da estudios a estudiante". Las dos direcciones se refieren a la misma asociacin.

Weitzenfeld: Captulo 4

10

La notacin describiendo una liga es una lnea conectando los dos objetos, conteniendo el nombre de la liga en letras cursivas, como se muestra en la Figura 4.27. Nombre de la Liga : Nombre de la Clase 1 : Nombre de la Clase 2 Figura 4.27. Notacin para diagrama de objetos conteniendo una liga. En la Figura 4.28 se muestra la liga estudia-en entre objetos de tipo Estudiante y Universidad. estudia-en Juan Prez : Estudiante ITAM : Universidad Figura 4.28. Diagrama de objetos conteniendo la liga estudia-en entre los objetos Juan Prez, de tipo Estudiante, y ITAM, de tipo Universidad. Ejemplo: En la Figura 4.29 se muestra la liga trabaja-para entre los objetos Ral Gonzlez, de tipo Persona, y IBM, de tipo Compaa. trabaja-para R al Gonzlez : Persona IBM : Compaa Figura 4.29. Diagrama de objetos conteniendo la liga trabaja-para entre los objetos Ral Gonzlez, de tipo Persona, y IBM, de tipo Compaa. La notacin describiendo una asociacin es una lnea conectando las dos clases, conteniendo el nombre de la asociacin en letras cursivas, como se muestra en la Figura 4.30.
Nombre de la Asociacin Nombre de la Clase 1 Nombre de la Clase 2

Figura 4.30. Notacin para diagrama de clases conteniendo una asociacin. Ejemplo: En la Figura 4.31 se muestra la asociacin estudia-en entre Estudiante y Universidad. estudia-en Estudiante Universidad Figura 4.31. Diagrama de clases conteniendo la asociacin estudia-en entre Estudiante y Universidad. Ejemplo: En la Figura 4.32 se muestra la asociacin trabaja-para entre Persona y Compaa. trabaja-para Persona Compaa Figura 4.32. Diagrama de clases conteniendo la asociacin trabaja-para entre Persona y Compaa. 4.5.1 Implementacin Vale la pena mencionar algo acerca de la implementacin de ligas y asociaciones, ya que es un aspecto que la gran mayora de los lenguajes orientados a objetos no apoyan de forma directa. El mecanismo principal que se utiliza en la mayora de los lenguajes es la referencia o apuntador que permite a una entidad referirse a otra de manera primitiva. Por tal motivo, la referencia o apuntador se guardara como un atributo adicional de la clase, algo que veremos con mayor detalle en el captulo 8 y 9 donde discutiremos aspectos de diseo e implementacin, respectivamente. Sin embargo, esta solucin casi obligatoria, oculta el hecho de que la asociacin no es parte de ninguna clase, sino depende de la combinacin de varias clases. Como las asociaciones son bidireccionales, sera necesario el uso de un par de atributos, lo cual ms an ocultara el hecho de que las dos direcciones de la asociacin son dependientes. Por tales razones, es un error conceptual modelar asociaciones por medio de referencia o

Weitzenfeld: Captulo 4

11

apuntadores, pero como se mencion antes, no tenemos alternativa. (Durante el diseo se puede decidir implementar la asociacin por medio de uno o ms referencias o apuntadores.) Ejemplo: Sera incorrecto modelar la asociacin estudia-en por medio de un apuntador apuntando de Estudiante hacia Universidad, y otro de Universidad hacia Estudiante, como se muestra en la Figura 4.33.

Estudiante Universidad : Referencia

Universidad Estudiante : Referencia

incorrecto Figura 4.33. Diagrama de clases describiendo de forma incorrecta la asociacin estudia-en por medio de una referencia entre Estudiante y Universidad.
Ejemplo: Sera tambin incorrecto modelar la liga estudia-en por medio de una referencia apuntando de Juan Prez hacia ITAM, y otro de ITAM hacia Juan Prez, como se muestra en la Figura 4.34. ("&" se usa como notacin para referencias.)

Juan Prez : Estudiante &ITAM

ITAM : Universidad &Juan Prez

incorrecto Figura 4.34. Diagrama de objetos describiendo de forma incorrecta la liga estudia-en por medio de una referencia entre Juan Prez y ITAM.
4.5.2 Grado de la Asociacin El grado de una asociacin se determina por el nmero de clases conectadas por la misma asociacin. Las asociaciones pueden ser binarias, ternarias, o de mayor grado. Las asociaciones se consideran binarias si relacionan solo dos clases. Ejemplo: La asociacin entre Persona e Instituto es una asociacin binaria. Las asociaciones pueden ser de mayor grado si relacionan a la misma vez ms de dos clases. Aparte de relaciones binarias, lo ms comn son relaciones ternarias (entre tres clases), relaciones de ms alto nivel son mucho menos comunes. Mientras el grado de una relacin aumenta, su comprensin se dificulta, y se debe considerar partir las relaciones en varias relaciones binarias. Ejemplo: Puede existir una relacin ternaria entre Estudiante, Profesor, y Universidad donde "un estudiante estudia con un profesor en una universidad". El grado de las ligas corresponden al de las asociaciones. Ejemplo: Para una asociacin binaria entre las clases estudiante y universidad, la liga correspondiente tambin es binaria ya que relaciona exactamente dos objetos, un objeto de tipo estudiante y otro de tipo universidad, como Juan Prez y ITAM. La notacin para una relacin ternaria entre objetos se muestra en la Figura 4.35. La relacin no se etiqueta.

: Nombre de la Clase 1

: Nombre de la Clase 2

: Nombre de la Clase 3
Figura 4.35. Notacin para diagrama de instancias describiendo una asociacin ternaria. Ejemplo: En la Figura 4.36 se muestra posibles relaciones entre objetos correspondiendo a esta relacin ternaria. El Estudiante Juan Prez estudia con el Profesor Alfredo Weitzenfeld en la Universidad ITAM.

Weitzenfeld: Captulo 4

12

Juan Prez : Estudiante

Alfredo Weitzenfeld : Profesor

ITAM : Universidad

Figura 4.36. Diagrama de instancias describiendo una relacin ternaria entre objetos de tipo Estudiante, Profesor y Universidad. La notacin para una relacin ternaria entre clases se muestra en la Figura 4.37. La relacin no se etiqueta.

Nombre de la Clase 1

Nombre de la Clase 2

Nombre de la Clase 3
Figura 4.37. Notacin para diagrama de clases describiendo una asociacin ternaria. Ejemplo: En la Figura 4.38 se muestra una asociacin ternaria entre las clases Estudiante, Profesor y Universidad, describiendo a diferentes estudiantes que estudian con diferentes profesores en diferentes institutos.

Estudiante

Profesor

Universidad
Figura 4.38. Diagrama de clases describiendo una asociacin ternaria entre Estudiante, Profesor y Universidad. 4.5.3 Asociaciones Reflexivas Las asociaciones pueden ser reflexivas, relacionando distintos objetos de una misma clase. Ejemplo: Para una clase persona puede existir una asociacin pariente que describe que dos objetos de tipo persona, como Juan Prez y Laura Prez son parientes. El grado de una asociacin reflexiva puede ser binario, ternario, o de mayor grado, dependiendo del nmero de objetos involucrados. Ejemplo: Para la clase persona puede existir una asociacin ternaria entre tres personas donde uno es el abuelo, el otro es el hijo del abuelo, y el tercero es el nieto del abuelo. Las asociaciones reflexivas relacionan distintos objetos de una misma clase. Ejemplo: Juan Prez es pariente-de Laura Prez, donde ambos son objetos de tipo Persona, como se muestra en la Figura 4.39. pariente-de Juan Prez : Persona Laura Prez : Persona Figura 4.39. Diagrama de instancias describiendo una asociacin reflexiva objetos de la clase Persona. Ejemplo: La asociacin reflexiva pariente-de para la clase Persona se muestra en la Figura 4.40.

Weitzenfeld: Captulo 4

13

Persona

parien te -de

Figura 4.40. Diagrama de clases describiendo una asociacin reflexiva para la clase Persona. 4.5.4 Multiplicidad La multiplicidad (cardinalidad) de una asociacin especifica cuantas instancias de una clase se pueden relacionar a una sola instancia de otra clase. Ejemplo: En el caso de Estudiante y Universidad, la multiplicidad est dada por el nmero de estudiantes que puedan estudiar en una sola universidad. En otras palabras, muchos objetos de tipo Estudiante se conectan a un solo objeto de tipo Universidad. Es necesario decidir la multiplicidad para cada clase en una asociacin, o sea dos multiplicidades por cada relacin binaria, una para cada extremo de la relacin. Ejemplo: En la relacin estudia-en es necesario definir la multiplicidad para el Estudiante y para la Universidad. La multiplicidad restringe una asociacin limitando el nmero de objetos que pueden relacionarse a un objeto particular. Ejemplo: En la asociacin estudia-en se puede restringir el nmero de estudiantes que pueden estudiar en una universidad. La multiplicidad depende del contexto de la aplicacin. Existen, distintos tipos de multiplicades para las asociaciones de las cuales las ms relevantes son las siguientes: ? ? "uno-uno": donde dos objetos se relacionan de forma exclusiva, uno con el otro. Ejemplo: Cada Universidad tiene un Rector, y cada Rector rige una Universidad. ? ? "uno-muchos": donde uno de los objetos pueden estar ligado a muchos otros objetos. Ejemplo: Muchos Estudiantes pueden estudiar en una Universidad, y una sola Universidad da estudios a cada Estudiante. ? ? "muchos-muchos": donde cada objeto de cada clase puede estar ligados a muchos otros objetos. Ejemplo: Muchos Estudiantes pueden estudiar en varias Universidades. La multiplicidad se incluye en el diagrama de clases nicamente. La multiplicidad para relaciones de mayor grado es ms compleja, volvindose esta notacin un poco ambigua para relaciones de mayor orden ya que no sabra cmo leerse la relacin. Se incorpora la siguiente notacin en cada uno de los extremos de una asociacin binaria. La notacin para relaciones "uno-uno", donde dos objetos solo pueden tener una liga entre ellos, es la notacin bsica de asociacin hasta ahora dada, como se muestra en la Figura 4.41.
Nombre de la Clase 1 Nombre de la Clase 2

Figura 4.41. Diagrama de clases describiendo una multiplicidad de "uno-uno". La notacin para relaciones "uno-muchos", donde uno de los objetos pueden estar ligado a muchos otros objetos, est dada por una "bolita negra" representando el lado de "muchos", el cual corresponde a cero o ms ligas, como se muestra en la Figura 4.42.

Nombre de la Clase 1

Nombre de la Clase 2

* Figura 4.42. Diagrama de clases describiendo una multiplicidad de "uno-muchos".

Ejemplo: En el caso de una Universidad donde pueden atender muchos Estudiantes, el diagrama se muestra en la Figura 4.43, donde la relacin de "muchos" se incorpora del lado de Estudiantes. (El contrario significara que un estudiante puede atender muchas universidades.)

Weitzenfeld: Captulo 4

14

Estudiante

Universidad

* Figura 4.43. Diagrama de clases describiendo una multiplicidad de "uno-muchos" entre Estudiantes y Universidad.

La notacin para relaciones "muchos-muchos", donde los dos objetos pueden estar ligados a muchos otros objetos, est dada por dos "bolitas negras" correspondiendo cada una a una multiplicidad de "muchos", como se muestra en la Figura 4.44.

Nombre de la Clase 1

Nombre de la Clase 2

* * Figura 4.44. Diagrama de clases describiendo una multiplicidad de "muchos-muchos".

Ejemplo: En el caso de muchas Universidades donde pueden atender muchos Estudiantes, el diagrama se muestra en la Figura 4.45.
Estudiante Universidad

* * Figura 4.45. Diagrama de clases describiendo una multiplicidad de "muchos-muchos" entre Estudiantes y Universidad.

La notacin para representar una relacin opcional, donde la multiplicidad es "uno" o "cero", describiendo una relacin opcional, 0 o 1. Esto significa que dos objetos pueden o no estar conectados, y si lo estn corresponden a una multiplicidad de 1. La notacin se muestra en la Figura 4.46.

Nombre de la Clase 1

Nombre de la Clase 2

0..1 1 Figura 4.46. Diagrama de clases describiendo una multiplicidad "opcional".

Ejemplo: El caso de muchos Estudiantes que pueden o no atender a una sola Universidad se muestra en la Figura 4.47. (Esto es a diferencia del ejemplo anterior donde los estudiantes tienen que atender a una universidad.)
Estudiante Universidad

* 0..1 Figura 4.47. Diagrama de clases describiendo una multiplicidad de "opcional-muchos" entre Estudiantes y Universidad.

La notacin de "asterisco", correspondiendo a una relacin de muchos, se pude restringir con un nmero, conjunto de nmeros, de objetos que deben estar conectados entre s. Ejemplo: En la Figura 4.48 se muestra una relacin con multiplicidad de cero o ms personas que trabajan para una compaa.
Persona Compaa

* 1 Figura 4.48. Diagrama de clases incluyendo multiplicidad en la asociacin.

Ejemplo: En la Figura 4.49 se muestra una relacin donde exactamente dos personas trabajan en una compaa.
Persona Compaa

2 1 Figura 4.49. Diagrama de clases incluyendo multiplicidad de "2" en la asociacin.

Ejemplo: En la Figura 4.50 se muestra una relacin donde por lo menos diez personas trabajan para una compaa.

Weitzenfeld: Captulo 4

15

Persona

Compaa

10..* 1 Figura 4.50. Diagrama de clases incluyendo multiplicidad de "10" o ms en la asociacin.

Ejemplo: En la Figura 4.51 se muestra una relacin donde una o dos personas trabajan para una compaa.
Persona Compaa

1..2 1 Figura 4.51. Diagrama de clases incluyendo multiplicidad de "1" o "2" en la asociacin.

Ejemplo: En la Figura 4.52 se muestra una relacin, de tipo opcional, donde cero o una persona trabajan para una compaa.
Persona Compaa

0..1 1 Figura 4.52. Diagrama de clases incluyendo multiplicidad de tipo opcional, donde "0" o "1" personas se relacionan con compaa.

4.5.5 Rol El rol describe el papel que juega cada extremo de una asociacin. Una asociacin binaria tiene dos roles, uno en cada extremo, los cuales pueden tener un nombre diferente cada uno. Una relacin de n clases tendra n roles. El nombre del rol provee una forma de atravesar la asociacin de un objeto en un extremo sin mencionar explcitamente el nombre de la asociacin. Ejemplo: Una Persona asume el rol de Empleado con respecto a la Compaa; y la Compaa asume el rol de Empleador con respecto a la Persona. Cuando hay solamente una asociacin conectando dos clases, a menudo el nombre de la clase sirve como nombre de rol, y no es necesario agregar un nombre de rol de forma explcita. Ejemplo: Estudiante y Universidad son bastante descriptivos que no es necesario agregar un nombre de rol. Si la clase fuera Persona, el nombre de rol Estudiante sera ms descriptivo. Los nombres de los roles no deben duplicar los atributos de la clase a la cual stos describen. (Esto se hace por razones de implementacin.) Ejemplo: El rol empleado no debe ser un atributo de Persona. Se pueden incorporar nombres de los roles y de la asociacin a la misma vez, o uno de los dos solamente, lo cual es m que suficiente para describir la relacin. La Figura 4.53 muestra la notacin para un rol.

Nombre de la Clase 1

rol1 Nombre de la Asociacin rol2

Nombre de la Clase 2

Figura 4.53. Notacin para diagrama de clases conteniendo nombres de los roles. Ejemplo: Persona tiene el rol de empleado con respecto a la Compaa, la cual tiene el rol de empleador con respecto a Persona, como se muestra en la Figura 4.54. trabaja-para Empleado Empleador Persona Compaa

* * Figura 4.54. Diagrama de clases para una asociacin con los nombres de los roles, nombre de la asociacin y multiplicidad.
Los nombres del rol son necesarios para asociaciones reflexivas (asociaciones entre objetos de la misma clase), ya que slo sabiendo el nombre de la asociacin no es suficiente para distinguir el papel que juegan los diferentes objetos en la asociacin. Ejemplo: Si una Persona puede ser jefe o empleado en una Compaa, entonces la nica forma de distinguir el papel que la Persona juega es por medio de un nombre de rol, como se muestra en la Figura 4.55.

Weitzenfeld: Captulo 4

16

Jefe 0..1

Persona *

Empleado

trabaja-para

Empleador *

Compaa

* Empleado Figura 4.55. Diagrama de clases para una asociacin reflexiva con roles.

Es importante utilizar nombres de rol para distinguir entre dos asociaciones diferentes las cuales relacionan a un mismo par de clases. Los roles deben ser diferentes segn la asociacin para el mismo extremo de la relacin. Ejemplo: Una Persona adems de ser empleado de una Compaa tambin puede ser el dueo de ella. Por lo tanto existen dos asociaciones entre Persona y Compaa, la primera es trabaja-para y la segunda es dueo-de. Ambas relaciones se pueden describir por medio de roles, como se muestra en la Figura 4.56. Empleador Compaa Persona Empleado * *

Dueo * 1 Figura 4.56. Diagrama de clases para asociaciones entre dos clases distinguidas por los nombres de rol.
4.5.6 Restricciones de Ligas y Asociaciones Las restricciones especifican una relacin particular entre las diferentes asociaciones o ligas. Las restricciones restringen los valores que estas entidades pueden asumir. Las restricciones sencillas se pueden aadir al modelo de objeto, mientras que las ms complejas deben ser especificadas en el modelo funcional. Por lo general las restricciones se describen de forma declarativa, aunque luego deban convertirse a un procedimiento para ser implementadas. Las restricciones pueden ser expresadas en lenguaje natural o por medio de ecuaciones. Las restricciones son limitadas por corchetes y son ubicadas cerca de la entidad restringida, como se muestra en la Figura 4.57.
Nombre de la Clase 1 Nombre de la Clase 2

??

{ restriccin } Figura 4.57. Notacin para un diagrama de clases mostrando una restriccin de asociacin. La restriccin debe ubicarse cerca de la entidad que afecte, y no necesariamente en el centro como se muestra en la figura. Subconjunto. Las posibles ligas de una asociacin pueden ser un subconjunto de las posibles ligas de otra asociacin. La multiplicidad de la asociacin del subconjunto debe ser igual o menor que la multiplicidad de la asociacin del superconjunto. Una flecha se utiliza para relacionar el subconjunto con la entidad de la cual depende, como se muestra en la Figura 4.58.

Nombre de la Clase 1

* { subconjunto } *

Nombre de la Clase 2

Figura 4.58. Diagrama de clases mostrando una restriccin de subconjunto entre dos asociaciones. Ejemplo: El presidente de un Pas debe ser un habitante del Pas. La asociacin presidente-de es un subconjunto de la asociacin habitante-de, como se muestra en la Figura 4.59.

Weitzenfeld: Captulo 4

17

Persona *

habitante-de

Pas 1

{ subconjunto }
presidente-de 1 Figura 4.59. Diagrama de clases mostrando a presidente-de como un subconjunto de habitante-de. ? ? Orden. La multiplicidad "muchos" indica que un conjunto de objetos puede estar relacionados a un mismo objeto. Estas relaciones pudieran estar ordenadas, como se muestra con la notacin en la Figura 4.60. { orde nad o } Nombre d e la Clase 1 Nombre de la Clase 2

* Figura 4.60. Notacin para un diagrama de clases mostrando una restriccin de orden.
Ejemplo: Una ventana en una estacin de trabajo est superpuesta por varias otras ventanas. Las ventanas son ordenadas para que se desplieguen en el orden correcto y la de ms arriba se despliegue por ltimo. Para indicar esta situacin se incluye una restriccin especial de orden, como se muestra en la Figura 4.61. visible-en * Ventana Estacin de Trabajo
{ ordenado }

Figura 4.61. Diagrama de clases mostrando una restriccin de orden para las ventanas en una estacin de trabajo. 4.5.7 Asociaciones Derivadas Las asociaciones derivadas se consideran asociaciones dependientes o redundantes, las cuales estn determinadas directa o indirectamente a travs de otras asociaciones y que se agregan para facilitar la bsqueda de informacin.. La notacin es una diagonal atravesando la asociacin, como se muestra en la Figura 4.62. asociacin-bsica

Nombre de la Clase 1

Nombre de la Clase 2

asociacin-derivada Figura 4.62. Notacin para un diagrama de clases mostrando asociaciones derivadas.
Ejemplo: Para la clase Persona puede existir una asociacin padre-de que define que una persona es el padre y la otra el hijo. Se puede crear una asociacin derivada abuelo-de que depende de que existan dos ligas padre-de definiendo a uno de los objetos como abuelo y el otro como nieto. La relacin abuelo-de es una asociacin derivada, como se muestra en la Figura 4.63. Tambin se podra definir las relaciones derivadas to, suegra, primo, las cuales se pueden deducir de otras relaciones bsicas como padre-de, esposo, y hermana. padre abuelo Persona abuelo-de padre-de

nieto hijo Figura 4.63. Diagrama mostrando la clase Persona conteniendo abuelo-de como una asociacin derivada de padre-de.

Weitzenfeld: Captulo 4

18

Ejemplo: Un Profesor ensea una sola Materia a muchos Estudiantes, como muestra la Figura 4.64. La relacin Estudiante estudia Materia es una asociacin derivada ya que conociendo al Profesor, se puede conocer la Materia, y por la tanto deducir que Materia se le es enseada a los Estudiantes. ensea * 1 Estudiante Profesor

estudia

1
Materia

1 1 1

ensea

Figura 4.64. Diagrama de clases con asociaciones derivadas redundantes. No todas las asociaciones que forman mltiples conexiones entre clases indican redundancia. A veces la existencia de una asociacin se deriva de dos o ms asociaciones primitivas, pero la multiplicidad no. Se debe mantener la asociacin adicional, ya que puede ser importante para una restriccin adicional de multiplicidad. Ejemplo: Los Profesores ensean muchas Materias a muchos Estudiantes, como muestra la Figura 4.65. La relacin Estudiante estudia Materia no es en este caso una asociacin derivada ya que conociendo al Profesor, no se puede deducir la Materia, ya que cada profesor da muchas materias, y por la tanto es necesario agregar la relacin adicional para saber que Materia se le es enseada a cada Estudiante. ensea * * Estudiante Profesor

estudia

1
Materia

1 * *

ensea

Figura 4.65. Diagrama de clases con asociaciones no redundantes. 4.5.8 Accesos Las operaciones de acceso son operaciones que adems de leer o escribir atributos, pueden servir para accesar las ligas relacionadas con un objeto. Se utiliza la notacin de punto para indicar el acceso a una liga: "objeto1.objeto2". Ejemplo: Se puede accesar la cuenta la cual esta ligada a una persona por medio de la instruccin persona.cuenta, la cual se incluira dentro de la operacin accesar-cuenta, como se muestra en la Figura 4.66.

Persona Accesar-cuenta()

Cuenta

Figura 4.66. Diagrama mostrando una Persona relacionada con una Cuenta. Se puede accesar los objetos por medio de "pseudo-atributos" de los roles de las asociaciones. Ejemplo: Se puede accesar la universidad a la cual asiste una persona por medio de su rol de estudiante utilizando la instruccin estudiante.universidad, la cual se incluira dentro de la operacin accesar-universidad, como se muestra en la Figura 4.67.

Weitzenfeld: Captulo 4

19

Persona Accesar-universidad()

Estudiante *

Universidad

Figura 4.67. Diagrama mostrando una Universidad relacionada con varios Personas, segn su rol de Estudiantes. 4.5.9 Atributos de Liga y Asociacin Al igual que un atributo de clase es propiedad de la clase, un atributo de asociacin (o atributo de liga) es propiedad de una asociacin. La notacin es similar a la usada para los atributos de clases, excepto que se aade a la asociacin, y no se incorpora un nombre de clase, como se muestra en la Figura 4.68.
Nombre de la Clase 1 Nombre de la Clase 2

L ista d e A tributos

Figura 4.68. Notacin para diagrama de clases con asociaciones conteniendo una lista de atributos de asociacin. Ejemplo: Para una asociacin entre Persona y Compaa, se puede definir los atributos salario y puesto como atributos de la asociacin trabaja-para, como se muestra en la Figura 4.69.

Persona

trabaja-para

Compaa

Salario Puesto
Figura 4.69. Diagrama de clases para asociacin salario y puesto. Persona y Compaa conteniendo los atributos de

La notacin en el diagrama de objetos es similar, como se muestra en la Figura 4.70.

: Nombre de la Clase 1

: Nombre de la Clase 2

Valores de Atributos Figura 4.70. Notacin para diagrama de objetos con ligas conteniendo valores de atributos de las ligas.
Ejemplo: Para una liga entre Ral Gonzlez e IBM, se da un valor de $100,000 al salario y un valor de gerente al puesto, como se muestra en la Figura 4.71.

Weitzenfeld: Captulo 4

20

trabaja-para Ral Gonzlez : Persona IBM : Compaa

100,000 gerente
Figura 4.71. Diagrama de objetos para Ral Gonzlez e IBM conteniendo el valor de $100,000 para el atributo de asociacin salario, y gerente para el atributo de liga puesto. Modelo Alternativo Las siguientes son diferentes alternativas al modelo como atributo de asociacin. Se puede modelar tal atributo como atributo de una de las clases involucradas en la relacin, segn la multiplicidad de la relacin. Aunque las alternativas son posibles, es conceptualmente ms correcto describir los atributos los cuales dependen de ambas clases, como atributo de asociacin. Si la multiplicidad de la asociacin es de "uno-uno", el atributo de asociacin se podra modelar como un atributo en cualquiera de las dos clases. Ejemplo: En la Figura 4.72 se incluyen salario y puesto como parte de Persona (podra tambin ser parte de Compaa).
Persona Salario Puesto 1 1 Compaa

Figura 4.72. Diagrama de clases para Persona y Compaa conteniendo multiplicidad "uno-uno" y los atributos de asociacin salario y puesto incluidos directamente en la clase Persona (o de forma alterna en la clase Compaa). Si la multiplicidad de la asociacin es de "uno-muchos", el atributo de asociacin se podra modelar como un atributo en el lado de la clase "muchos". Ejemplo: En la Figura 4.73 se incluyen salario y puesto como parte de Persona, ya que Persona est del lado "muchos" de la asociacin. Del otro lado sera incorrecto ya que significara que todas las Personas estaran ganando el mismo salario y tendran el mismo puesto.
Persona Salario Puesto * 1 Compaa

Figura 4.73. Diagrama de clases para Persona y Compaa conteniendo multiplicidad "unomuchos" y el atributo de asociacin salario y puesto incluidos directamente en la clase Persona. Si la multiplicidad de la asociacin es de "muchos-muchos" no es posible modelarlo como un atributo de clase. Ejemplo: En la Figura 4.74 se muestra de forma incorrecta la incorporacin de salario y puesto a Persona (o de forma alterna a Compaa) ya que la relacin es de "muchos-muchos", y esto significara que una Persona tendra el mismo salario y el mismo puesto en todas las Compaas en las cuales trabajara. Esto no es necesariamente correcto. La representacin correcta ser mostrada ms adelante.

Weitzenfeld: Captulo 4

21

Persona Salario Puesto

Compaa

Figura 4.74. Diagrama de clases incorrecto para Persona y Compaa conteniendo los atributos de asociacin salario y puesto incluidos directamente en la clase Persona. Asociaciones Ternarias Los atributos de asociacin tambin pueden existir para las asociaciones ternarias. Ejemplo: Un Estudiante toma una Materia en una Universidad donde se le da una Calificacin la cual depende de las tres clases, como se muestra en la Figura 4.75.

Universidad Nombre

Estudiante Nombre

Materia Nombre

Calificacin
Figura 4.75. Diagrama de clases mostrando una asociacin ternaria entre las clases Estudiante, Materia y Universidad incluyendo el atributo Calificacin. Ejemplo: En la Figura 4.76 se muestra un ejemplo de modelo de objetos para la relacin ternaria anterior.

:Universidad UNAM

:Estudiante Juan Prez

:Materia DSOO

10
Figura 4.76. Diagrama de instancias para Estudiante, Materia y Universidad incluyendo un valor para el atributo Calificacin para la asociacin ternaria entre estas clases. 4.5.10 Operaciones de Asociacin Se pueden modelar como operaciones de asociacin aquellas operaciones que dependan de las clases involucradas en la relacin, de forma anloga a los atributos de asociacin. La notacin se muestra en la Figura 4.77.

Weitzenfeld: Captulo 4

22

Nombre de la Clase 1

Nombre de la Clase 2

Lista de Atributos Lista de Operaciones

Figura 4.77. Notacin para el diagrama de clases conteniendo atributos y operaciones de asociacin. Ejemplo: La operacin Calcular-Ganancia depende del Salario de la Persona con respecto a la Compaa por lo cual se modela como operacin de asociacin, como se muestra en la Figura 4.78.

P ersona

trabaja-para

Compaa

Salario Puesto Calcular-ganancia()

Figura 4.78. Diagrama de clases conteniendo los atributos y operaciones de asociacin, Salario y Puesto, y Calcular-Ganancia, respectivamente. 4.5.11 Asociaciones como Clases Se puede modelar una asociacin como si fuera una clase, en particular si se desea asociar la propia asociacin con otras clases. Los atributos y operaciones de la asociacin pasan a ser miembros de la clase correspondiente a la asociacin. La notacin se muestra en la Figura 4.79.

Nombre de la Clase 1

Nombre de la Clase 2

Nombre de la Asociacin Lista de Atributos Lista de Operaciones

Figura 4.79. Notacin para diagrama de clases modelando la asociacin como una clase. Ejemplo: La relacin trabaja-para entre Persona y Compaa, se puede convertir en una clase, si pensamos en relaciones con otra clase como Seguro-de-Trabajo para cada Persona que est trabajando en una Compaa, como se muestra en la Figura 4.80.

Weitzenfeld: Captulo 4

23

Persona

trabaja-para

Compaa

Trabaja-Para Salario Puesto Calcular-ganancia() *

Seguro de Trabajo Nombre Costo Cobrar() Pagar()

Figura 4.80. Diagrama de clases para una asociacin, trabaja-para, modelada como una clase. 4.6 Ensamblados: Agregacin y Composicin Los ensamblados, en particular la agregacin y composicin, son formas especiales de asociacin entre un todo y sus partes, en donde el ensamblado est compuesto por sus componentes. El ensamblado es el objeto central, y la estructura completa se describe como una jerarqua de contenido. Un ensamblado puede componerse de varias partes, donde cada relacin parte-todo se considera una relacin separada. En el caso de agregacin, las partes del ensamblado pueden aparecer en mltiples ensamblados. En el caso de composicin, las partes del ensamblado no pueden ser compartidas entre ensamblados. Ejemplo: Una Red de Computadoras se puede considerar un ensamblado, donde las Computadoras son sus componentes. Este tambin es un ejemplo de agregacin, ya que las Computadoras pudieran ser partes de mltiples Redes de Computadoras a la vez. Adicionalmente, las Computadoras pueden existir independientemente de la existencia de la Red de Computadoras. Ejemplo: Un Automvil se puede tambin considerar un ensamblado, donde el Motor y la Carrocera son sus componentes. Este tambin es un ejemplo de composicin, ya que el Motor y la Carrocera son partes del Automvil, y a diferencia de la agregacin, no pueden ser compartidos entre distintos Automviles a la vez. Adicionalmente, no tiene mucho sentido que el Motor y la Carrocera existan de manera independiente al Automvil, por lo cual la composicin refleja de manera importante, el concepto de propiedad. El ensamblado tiene propiedades de transicin: Si A es parte de B y B es parte de C; entonces A es parte de C. Ejemplo: Si el Motor es parte del Automvil, entonces sus propiedades, como su posicin y velocidad, estn dadas por la posicin y velocidad del Automvil. El ensamblado es antisimtrico: Si A es parte de B, entonces B no es parte de A. Estas propiedades se propagan entre el ensamblado y sus componentes. Ejemplo: Si el Motor es parte del Automvil, entonces el Automvil no es parte del Motor. Se considera un ensamblado y no una asociacin regular: ? ? Si se puede usar la frase "parte-de" o "consiste-de" o "tiene"; ? ? Si algunas operaciones en el todo se pueden propagarse a sus partes; ? ? Si algunos atributos en el todo se pueden propagar a sus partes; El ensamblado es comn en los objetos interfaz. En un sistema de ventanas, por ejemplo, una ventana puede consistir de botones, mens, y barras (scrollbars), cada una modelada por su propio objeto interfaz. El resultado es una estructura de interfaz en forma de rbol. La decisin de usar ensamblados es un poco arbitraria, y en la prctica no

Weitzenfeld: Captulo 4

24

causa grandes problemas la distincin imprecisa entre agregacin, composicin y asociacin, aunque es bueno ser consistente. La notacin para un ensamblado, en particular para un agregado, es un diamante adherido al lado del objeto correspondiente al ensamblado total, conectado por una lnea a sus componentes, como se muestra en la Figura 4.81. Ensamblado Componente (Agregacin) Figura 4.81. Notacin en un diagrama de clases para una agregacin. La notacin para la composicin es similar a una agregacin y al ensamblado en general, aunque a diferencia de la agregacin el diamante se rellena de color negro, como se muestra en la Figura 4.82. Ensamblado Componente (Composicin) Figura 4.82. Notacin en un diagrama de clases para una composicin. Existe una notacin adicional para la composicin descrita como un anidamiento grfico, como se muestra en la Figura 4.83.

Ensamblado (Composicin)

Componente

Figura 4.83. Notacin en un diagrama de clases para una composicin. Ejemplo: El Automvil con sus componentes, Motor y Carrocera, se muestran en el diagrama de la Figura 4.84.

Automvil

Carrocera

Motor

Figura 4.84. Diagrama de clases para la composicin de un Automvil que contiene un componente Motor y otro componente Carrocera. Ejemplo: Una computadora personal (PC) est compuesta por uno o varios monitores, un sistema, un teclado y opcionalmente un ratn. El sistema tiene un chasis, un procesador central (CPU), varias tarjetas de memoria (RAM), y opcionalmente un ventilador. El diagrama se muestra en la Figura 4.85.

Weitzenfeld: Captulo 4

25

Computadora

1 Monitor

1 Sistema

1 Ratn

1 Teclado

1 Tarjeta Madre

1..* Procesador

1..* Memoria

1..* Disco

Figura 4.85. Diagrama de clases para la composicin de una computadora personal (PC) conteniendo diferentes componentes. Ejemplo: Una Universidad est compuesta de sus Divisiones, que estn a su vez compuestas de sus Departamentos. Una Universidad es indirectamente una composicin de sus Departamentos; pero la Universidad no es una composicin de sus Estudiantes, si no ms bien una agregacin, ya que sus Estudiantes son objetos independientes, incluso pudiendo pertenecer a mltiples Universidades, como se muestra en la Figura 4.86. (Este es un ejemplo de ensamblado variable, como se describe en la siguiente seccin.)

Universidad * 1 *

Divisin 1 *

Departamento

* Estudiante
Figura 4.86. Diagrama de clases para la composicin de una Universidad que contiene componentes de Divisin que a su vez contiene componentes de Departamento. La relacin entre Universidad y Estudiante es de agregacin. 4.6.1 Tipos de Ensamblados Los tipos de ensamblados pueden ser: ? ? Fijos. Los ensamblados fijos tienen una estructura fija donde el nmero de componentes est predefinido. Ejemplo: Un Automvil tiene un Motor, una Carrocera, y cuatro Ruedas, como se muestra en la Figura 4.87.

Weitzenfeld: Captulo 4

26

Automvil

1 Carrocera 4 1 Rueda
Figura 4.87. Diagrama de clases para un ensamblado fija describiendo un Automvil que contiene varios componente: un Motor, una Carrocera, y cuatro Ruedas. ?? Variables. Los ensamblados variables tienen un nmero finito de niveles, pero el nmero de componentes vara. Ejemplo: Un Pas contiene varias Ciudades, que contienen a su vez varias Casas. No se sabe cuantas ciudades existen, ni tampoco cuantos casas, aunque si se sabe el nivel del ensamblado, como se muestra en la Figura 4.88.

Motor

P as *

Ciudad *

Casa

Figura 4.88. Diagrama de clases para un ensamblado variable describiendo un Pas que contiene varias Ciudades, que a su vez contienen varias Casas. ?? Recursivos. Los ensamblados recursivos contienen de forma directa o indirecta una instancia del mismo tipo de agregado, donde el nmero de niveles de ensamblado es potencialmente ilimitado. Ejemplo: Un Directorio en un sistema operativo est definido de forma recursiva, pudiendo contener otros directorios que a su vez pueden contener otros directorios, y a as sucesivamente de forma indefinida, como se muestra en la Figura 4.89.

Directorio *

Figura 4.89. Diagrama de clases para un ensamblado recursivo describiendo un Directorio que puede contener otros varios Directorios de forma recursiva. 4.6.2 Propagacin de Operaciones Una de las metas del ensamblado es que las operaciones aplicadas al ensmablado puedan propagarse de forma automtica a sus objetos componentes. La operacin se propaga en una sola direccin, y puede ser aplicada a las partes del ensamblado de forma independiente. La notacin para la propagacin de operaciones se muestra en la Figura 4.90. La propagacin se indica con una flecha, en el sentido de la propagacin, junto al nombre de la operacin etiquetando la asociacin. Ensamblado Componente

Operacin() Operacin()

Operacin()

Figura 4.90. Notacin en un diagrama de clases para la propagacin de operaciones en un ensamblado.

Weitzenfeld: Captulo 4

27

Ejemplo: Cuando el Automvil se mueve, la operacin de moverse se propaga por el Automvil, y tambin se mueven todas sus partes, como el Motor, la Carrocera, y las Ruedas. La operacin no se propaga en sentido contrario, ya que, por ejemplo, la Carrocera no puede moverse sin que se mueva el Automvil completo, como se muestra en la Figura 4.91. Tambin se pudieran propagar otras operaciones, como pintar, vender, comprar, etc.

Automvil Mover()
Mover() Mover()

1 Carrocera Mover() 2..5 Puerta Mover()

Mover()

Mover()

1 4 Rueda Mover()

Motor Mover()

Figura 4.91. Diagrama de clases para la propagacin de la operacin mover del ensamblado Automvil a Carrocera, y luego a Puerta la cual es parte a su vez de la Carrocera. La operacin se propaga a todos los componentes. 4.7 Generalizacin y Herencia Las clases con atributos y operaciones comunes se pueden organizar de forma jerrquica, mediante la herencia. La herencia es una abstraccin importante para compartir similitudes entre clases, donde todos los atributos y operaciones comunes a varias clases se pueden compartir por medio de la superclase, una clase ms general. Las clases ms refinadas se conocen como las subclases. Ejemplo: Las Impresoras Lser, de Burbuja, y de Matriz, son todas subclases de la superclase Impresora. Los atributos generales de una Impresora son el Modelo, Velocidad, y Resolucin, mientras que sus operaciones son Imprimir y Alimentar. Herencia es una relacin "es-una" entre las clases las ms refinadas y ms generales. Ejemplo: Impresora Lser es una Impresora. Herencia es til para el modelo conceptual al igual que para la implementacin. Como modelo conceptual da buena estructuracin a las clases. Como modelo de implementacin es un buen vehculo para no replicar innecesariamente el cdigo. Generalizacin define una relacin entre una clase ms generalizada, y una o ms versiones refinadas de ella. Ejemplo: La clase Impresora es una generalizacin de las clases Impresoras Lser, de Burbuja, y de Matriz. Especializacin define una relacin entre una clase ms general, y una o ms versiones especializadas de ella. Ejemplo: Impresoras Lser, de Burbuja, y de Matriz, son todas especializaciones de Impresoras. La superclase generaliza a sus subclases, y las subclases especializan a la superclase. El proceso de especializacin es el inverso de generalizacin. Una instancia de una subclase, o sea un objeto, es tambin una instancia de su superclase. Ejemplo: Cuando se crea un objeto de tipo Impresora Lser, este objeto incluye toda la informacin descrita en la subclase Impresora Lser, al igual que en la superclase Impresora; por lo tanto se considera que el objeto es una instancia de ambas. La herencia es transitiva a travs de un nmero arbitrario de niveles. Los ancestros de una clase son las superclases de una clase en cualquier nivel superior de la jerarqua, y los descendientes de una clase son las subclases de una clase en cualquier nivel inferior de la jerarqua. Ejemplo: Si adems de Impresora de Burbuja, se define una clase ms especializada como Impresora de Burbuja Porttil, entonces Impresora e Impresora de Burbuja son ancestros de la clase Impresora de Burbuja Porttil, mientras que Impresora de Burbuja e Impresora de Burbuja Porttil son descendientes de Impresora.

Weitzenfeld: Captulo 4

28

Las siguientes caractersticas se aplican a clases en una jerarqua de herencia: ? ? Los valores de una instancia incluye valores para cada atributo de cada clase ancestra. ? ? Cualquier operacin de cualquier clase ancestra, se puede aplicar a una instancia. ? ? Cada subclase no solo hereda todas las caractersticas de sus ancestros sino tambin aade sus propios atributos y operaciones. (Los nombres de atributos y operaciones deben ser nicos en la jerarqua de herencia.) Ejemplo: Una Impresora de Burbuja Porttil incorpora todas las caractersticas, primero de una Impresora, y luego de una Impresora de Burbuja, conteniendo valores para todos los atributos ancestrales y pudindose aplicar todas las operaciones ancestrales. La generalizacin se puede extender a mltiples niveles de jerarquas, donde una clase hereda de su superclase, que a su vez hereda de otra superclase, hacia arriba en la jerarqua. En otras palabras, las relaciones entre subclases y superclases son relativas. La herencia define una jerarqua de clases donde existen ancestros y descendientes, que pueden ser directos o no. Para representar herencia y generalizacin, se utiliza un tringulo conectando a la superclase con sus subclases. La superclase est del lado superior del vrtice del tringulo, mientras que las subclases estn en la parte inferior de la base del tringulo, como se muestra en la Figura 4.92.

Superclase

Subclase1

Subclase 2

Figura 4.92. Notacin en diagrama de clases para generalizacin y herencia. Ejemplo: Un Barco tiene un Nombre, Fabricante, y Costo. Tipos especiales de Barco, como Velero, tienen adems de estas caractersticas bsicas, un Nmero de Velas, mientras que otro tipo especial de Barco, como Barco a Motor, tiene un Motor. Barco es la clase bsica (la superclase) mientras que Velero y Barco a Motor son las clases refinadas (las subclases). Se debe definir las caractersticas bsicas de los barcos una sola vez, y luego aadir detalles para veleros, barcos a motor, etc. En la Figura 4.93 se muestra el diagrama de clases describiendo la relacin de herencia.

Barco Nombre Fabricante Costo

V elero Nme ro de Velas

Yate Potencia del Motor

Figura 4.93. Diagrama de clases describiendo herencia de la superclase Barco a las subclases Velero y Barco a Motor. SE incluyen atributos para las diferentes clases. Ejemplo: Una jerarqua conteniendo una superclase Mueble, y varias subclases Mesa y Asiento, puede ser extendida con nuevas subclases, como Mesa Circular, Mesa Rectangular, mientras que un Asiento puede extenderse con las subclases Silla, Silln, y Taburete, como se muestra en la Figura 4.94. Cada clase tiene sus propios atributos los cuales se van especializando a medida que las clases son cada vez ms especializadas. Ntese que no necesariamente todas las clases tienen que incluir atributos.

Weitzenfeld: Captulo 4

29

M ueb le Fabricante Peso Costo Altura Material Asiento Mesa

S illa Nmero de Brazos

Silln Capacida d d e P ersonas

Taburete Nmero de Patas

Mesa Circular Dimetro

Mesa Rectang ula r A ncho L argo

Figura 4.94. Diagrama de clases describiendo diferentes tipos de Mueble, Asiento y Mesa, con sus respectivas subclases. Ejemplo: En la Figura 4.95 se muestran instancias de Silln y Mesa Circular con valores para los distintos atributos.

:Silln Fabricante = Frei Peso = 250 Costo = 10,000 Altura = 1 Material = Caoba Capacidad de Personas = 4

:Mesa Circular Fabricante = Ikea Peso = 100 Costo = 15,000 Altura = 1.20 Material = Cedro Dimtero = 2

Figura 4.95. Diagrama de instancias para un Silln y una Mesa Circular. Agregacin o composicin no es lo mismo que generalizacin, el ensamblado relaciona clases correspondientes a muchos objetos, mientras que generalizacin relaciona clases las cuales finalmente corresponden a un solo objeto. Agregacin o composicin es una forma de estructurar la descripcin de un solo objeto, mientras que con generalizacin, un solo objeto es una instancia de la combinacin de su superclase y subclases. El ensamblado es una relacin parte-de, en cambio generalizacin es una relacin tipo-de o es-una. Ejemplo: Un Automvil est compuesto de un Motor, una Carrocera, y cuatro Ruedas. El Automvil puede ser clasificado, como Automvil Deportivo y Automvil Sedan. Cada subclase puede tener sus propias partes, como Rin de Magnesio o Parrilla para Maletas. Rin de Magnesio es subclase de Rin, el cual es un componente de Rueda, al igual que Llanta. El diagrama se muestra en la Figura 4.96.

Weitzenfeld: Captulo 4

30

Automvil

1 Sedn Coup Carrocera

4 Rueda

1 Motor

Puerta

Rin de Magnesio Rin Llanta 2, 4 Figura 4.96. Diagrama de clases para un ensamblado describiendo un Automvil que contiene varios componente: un Motor, una Carrocera, y cuatro Ruedas. Pueden haber diferentes tipos de Automvil, Deportivo o Sedan, conteniendo Rin de Magnesio o una Parrilla para Maletas, respectivamente. Rin de Magnesio es subclase de Rin, el cual es componente de Rueda al igual que Llanta.

Ejemplo: Una clase Ventana tiene atributos para los vrtices de la ventana y operaciones para Desplegar, Ocultar, Mover y Modificar la ventana. Canvas, Panel, y Ventana de Texto son tipos diferentes de Ventanas. Un Canvas se utiliza para diferentes despliegues grficos, incluyendo atributos como el tamao del elemento grfico y operaciones para Aadir y Borrar tales elementos. El Canvas se relaciona con varios Elementos (Formas) que son Lneas o Formas Cerradas, como Elipses o Polgonos. Un Polgono consiste de una lista ordenada de Puntos. Un Panel contiene diferentes Artculos de Panel, los cuales pueden ser de tipo Botn, Seleccin, o Texto. Todos los Artculos de Panel estn relacionados con Eventos del ratn, y el artculo de tipo Texto se relaciona adems con un Evento del teclado. Cuando un Artculo de Panel se escoge, un Evento se genera. Una Seleccin se relaciona con diferentes Posibles Selecciones, aunque solo una puede escogerse a la vez. El diagrama se muestra en la Figura 4.97.

Weitzenfeld: Captulo 4

31

Canvas cx1, cy1, cx2, cy2 Aadir-elemento() Borrar-elemento() Ventana Texto Texto Insertar() Borrar() * Elemento

Ventana x1, y1, x2, y2 Desplegar() Ocultar() Mover() Modificar() Panel Nombre Artculo

Forma Color Ancho Lnea

Evento Accin 1 1 *

Artculo Panel Color Ancho Lnea

Lnea x1, y1, x2, y2 Dibujar()

Forma Cerrada Patrn Relleno Color Relleno

1 Texto Cadena Largo Seleccin x1, y1, x2, y2 Dibujar() 1 seleccin actual 1 1 { subconjunto } Botn Apretado

* Selecciones

Elipse x, y, a, b Dibujar()

Recngulo x, y Dibujar()

Posibles Selecciones Valor

Figura 4.97. Diagrama de clases para un sistema de Ventanas. Ejemplo: La clase Persona tiene un Nombre, Direccin, y Nmero del Seguro Social. Una persona puede trabajar en algn proyecto y ganar un salario. Una Compaa tiene un Nombre, Direccin, Nmero de Telfono, y Producto Primario. Una Compaa contrata y despide Personas. Persona y Compaa tienen una relacin "muchos-muchos". El ttulo del trabajo depende de la persona y de la compaa. Hay dos tipos de Personas: Trabajadores y Administradores. Cada Trabajador est involucrado en varios Proyectos; cada Administrador es responsable de varios proyectos. En un proyecto pueden trabajar varios trabajadores y un solo administrador. Cada proyecto tiene un Nombre, Presupuesto, y una Prioridad Interna para asegurar recursos. Adems una Compaa est compuesta de mltiples Departamentos; cada departamento dentro de una compaa se identifica de forma nica por su Nombre. Un departamento usualmente tiene un administrador. La mayora de los administradores manejan un departamento; y algunos administradores no estn asignados a ningn departamento. Cada departamento manufactura varios productos; mientras que cada producto est hecho por un solo departamento. Un producto tiene Nombre, Costo, y Peso. El diagrama se muestra en la Figura 4.98.

Weitzenfeld: Captulo 4

32

Persona Nombre Direccin RFC

Empleado *

trabaja-para

Empleador *

Compaa Nombre Direccin Telfono Producto

Ttulo

* Trabajador * trabaja-en * Proyecto Nombre Presupuesto Prioridad

Figura 4.98. Diagrama de clases para Personas trabajando en Compaas. La generalizacin puede hacerse por diferentes razones: ? ? Extensin: clases definidas por operaciones con estructuras de informacin. ? ? Restriccin: clases como implementaciones de tipos, especializaciones, subconjunto de todas las instancias de un ancestro. 4.7.1 Extensin de Clase La extensin de clase expresa que una subclase puede aadir nuevos atributos u operaciones a la superclase. Ejemplo: La clase Rectngulo aade los nuevos atributos, Ancho y Largo, como se muestra en la Figura 4.99.

Administrador 0..1 1 responsable-de *

administra 0..1

Departamento 1 manufactura * Producto Nombre Costo Peso

Weitzenfeld: Captulo 4

33

Figura

Rectngulo Ancho Largo

Figura 4.99. Diagrama de clases para una herencia describiendo una superclase Figura y una subclase Rectngulo. 4.7.2 Restriccin de Clase La restriccin de clase indica como una subclase puede restringir los atributos heredados de una superclase. Una clase descendiente no puede suprimir los atributos u operaciones de sus ancestros. Ejemplo: La clase Cuadrado restringe los atributos de Rectngulo, ya que Ancho debe ser igual a Largo, como se muestra en la Figura 4.100.

Figura

Rectngulo A ncho L argo

Cuadrado

{ Ancho = Largo }
Figura 4.100. Diagrama de clases para una herencia describiendo una superclase Figura, una subclase Rectngulo, y una nueva subclase Cuadrado. Cambios arbitrarios a los valores de los atributos pueden violar las restricciones de una clase creada por medio de restricciones. La restriccin define la condicin para la membresa en una clase, donde todos los objetos cuyos valores satisfacen la regla pertenecen a la clase.

Weitzenfeld: Captulo 4

34

Ejemplo: La clase Cuadrado debe suprimir la Escala desigual, ya que una escala arbitraria en las dimensiones de los ejes puede resultar en un Rectngulo y no en un Cuadrado. (La clase Rectngulo est cerrada bajo la operacin de Escala, pero no la clase Cuadrado.) 4.7.3 Sobrescritura de Operaciones Una subclase puede sobrescribir atributos y operaciones de una superclase, al definir nuevos atributos y operaciones con el mismo nombre. Se pueden sobrescribir atributos, por ejemplo, para redefinir sus valores por omisin, y se pueden sobrescribir operaciones para mejorar el rendimiento de un algoritmo. (No se puede sobrescribir las firmas de los atributos o de las operaciones). Ejemplo: La operacin Desplegar se define en la superclase Figura y se redefine (sobrescribe) en varias de las subclases, como Punto y Lnea. En general, sobrescritura va contra el principio de herencia, ya que se deja de heredar ciertos aspectos del ancestro. Sin embargo, la sobrescritura es parte fundamental de la orientacin a objetos, en particular del polimorfismo. Se puede sobrescribir operaciones por varias razones: extensin, restriccin, optimizacin y implementacin. ? ? Extensin. En la sobrescritura por extensin, una nueva operacin es igual a una heredada, excepto que agrega algn comportamiento nuevo afectando algunos de los atributos de la subclase. Ejemplo: La clase Ventana tiene una operacin Dibujar para Borde y Contenido, mientras que la clase Ventana-Etiquetada tiene una operacin Dibujar donde el mtodo Dibujar-Ventana-Etiquetada llama al mtodo Dibujar de Ventana, agregando cdigo para dibujar la Etiqueta, como se muestran en la Figura 4.101.

Ventana Dibujar()

V entana Etiquetada Dibuja r()

Figura 4.101. Diagrama de clases para una Ventana y una Ventana-Etiquetada. ?? Restriccin. En la sobrescritura por restriccin, una nueva operacin restringe el protocolo de la operacin (firma), como el tipo de argumentos. Ejemplo: Una superclase Conjunto puede tener una operacin Sumar(Objeto). La subclase Conjunto-Entero tiene una operacin ms restringida Sumar(Entero). El diagrama se muestra en la Figura 4.102.

Conjunto Sumar(Objeto)

Conjunto Entero Sumar(Entero)

Figura 4.102. Diagrama de clases para un Conjunto y un Conjunto-Entero, restringiendo la operacin Sumar. ?? Optimizacin. En la sobrescritura por optimizacin, la implementacin de una clase puede aprovechar las restricciones impuestas para mejorar el cdigo de la operacin. El protocolo externo debe ser el mismo para la

Weitzenfeld: Captulo 4

35

nueva operacin, aunque internamente sea totalmente diferente. Ejemplo: La superclase Conjunto-Entero puede tener una operacin Mximo para encontrar el Entero ms grande. El mtodo podra ser implementado usando una bsqueda secuencial. La subclase Conjunto-Entero-Ordenado puede proveer una implementacin ms eficiente del mtodo Mximo teniendo en cuenta que los nmeros ya estn ordenados, como se muestran en la Figura 4.103, optimizando la operacin Mximo.

Conjunto Sumar(Objeto)

Conjunto Entero Sumar(Entero) Mximo()

Conjunto Entero Ordenado Mximo()

Figura 4.103. Diagrama de clases para un Conjunto, un Conjunto-Entero, y un Conjunto-EnteroOrdenado, optimizando la operacin Mximo. ?? Implementacin. Es malo desarrollar nuevas clases sobrescribiendo los mtodos de las superclases simplemente por conveniencia de implementacin, sobrescritura por implementacin, sobre las cuales no existe ninguna relacin conceptual. Se puede introducir herencia adicional en el sistema durante la etapa de diseo. Ejemplo: Las clases Persona y Compaa tienen ambas los atributos Nombre y Direccin, y se podra crear una superclase conteniendo los atributos comunes. Hacer esto durante la etapa del modelo de objetos es incorrecto, ya que las clases Persona y Compaa son semnticamente diferentes. Crear una superclase, Dato-Comn, que contenga ambos atributos, como se muestra en la Figura 4.104, sera mas bien una decisin hecha durante la etapa del diseo.

Dato Comn Nombre Direccin

Persona

Comp aa

Figura 4.104. Diagrama de clases para una Persona y una Compaa, compartiendo atributos comunes guardados en la superclase Dato-Comn. 4.7.4 Discriminador Un discriminador indica el atributo de la superclase cuyo valor distingue a las subclases. El discriminador indica cual propiedad de la superclase es abstrada por las subclases en la herencia. (Slo una propiedad debe ser discriminada a la vez.) La etiqueta "tipo" representa el discriminador ms comn, por lo cual a veces no se incluye. Si el discriminador es obvio no es necesario incluirlo. La notacin, la cual es opcional, se muestra en la Figura 4.105.

Weitzenfeld: Captulo 4

36

Superclase Discriminador

Subclase1

Subclase2

Figura 4.105. Notacin para el diagrama de clases con generalizacin conteniendo discriminadores. Ejemplo: Un Asiento se puede discriminar segn su funcionalidad, en Silla, Silln, o Taburete, como se muestra en la Figura 4.106.

Funcio nalida d

Asiento Altura

Silla Nmero de Brazos

Silln Capacidad de Personas

Tab ure te Nmero de Patas

Figura 4.106. Diagrama de clases para diferentes tipos de Asientos, segn su funcionalidad. Ejemplo: Una Mesa se puede discriminar segn su forma, en Mesa Circular o Mesa Rectangular, como se muestra en la Figura 4.107.
Mesa Form a

Mesa Circular Dimetro

Mesa Rectangular Ancho Largo

Figura 4.107. Diagrama de clases para diferente tipo de Mesa segn su forma. Ejemplo: En la Figura 4.108 se muestra un diagrama de clases para figuras grficas geomtricas. Las Figuras se discrimina segn sus dimensiones, 0, 1, y 2. La operacin desplegar se ha sobrescrito en todas las subclases de ltimo nivel.

Weitzenfeld: Captulo 4

37

Figura Color Posicin Centro Tipo de Lpiz Grosor de Lpiz Mover() Rotar() Seleccionar() Desplegar() Dimensin

0 Dime nsin

1 Dimensin Orientacin Escala()

2 Dimensin Orientacin Relleno Escala() Tipo Tipo

Tipo

Punto Desplegar()

Lnea Extremos Desplegar()

Arco Radio Angulo Despleg ar()

P olg ono Nmero de Lados Vrtices Desplegar()

Crculo Dimetro Desplegar()

Figura 4.108. Diagrama de clases para diferente tipo de Figuras, segn sus dimensiones. 4.7.5 Clases Abstractas Hasta ahora todas las clases descritas anteriormente se conocan como clases concretas o simplemente clases. Donde cualquiera de estas clases tena la cualidad de ser instanciable. En contraste, una clase abstracta es una clase que no tiene directamente instancias, pero que sus clases descendientes s las tienen. Las clases abstractas organizan caractersticas comunes a varias clases; pueden aparecer naturalmente en la aplicacin, o pueden ser introducidas artificialmente para promover el reuso de cdigo, para compartir atributos y mtodos. Ejemplo: Para la clase Mueble, la clase Asiento es abstracta, ya que para crear un asiento se debe instanciar una de sus tres subclases, Silla, Silln, o Taburete. Cuando una superclase es dividida en subclases por un discriminador y existe una subclase para cada valor posible del discriminador, entonces la superclases se considera una clase abstracta. La clase abstracta puede definir mtodos para ser usados por la subclase, o puede definir el protocolo de la operacin, o sea el tipo y nmero de argumentos, el resultado, y la intencin semntica, sin dar el correspondiente mtodo (operacin abstracta). Cada clase concreta debe proveer su propia implementacin, y no debe tener operaciones abstractas. Ejemplo: Ocupaciones, como Ingeniero, Arquitecto, y Doctor, son clases concretas. Una superclase Trabajador guardando aspectos comunes a todas las ocupaciones sera una clase abstracta, ya que se debe instanciar un trabajador con una ocupacin particular, como se muestra en el diagrama de la Figura 4.109.

Weitzenfeld: Captulo 4

38

Trab ajado r

Inge niero

Arquitecto

Doctor

Figura 4.109. Diagrama de clases para una clase abstracta Trabajador y diferentes clases concretas Ingeniero, Arquitecto, y Doctor. (Ntese que el nombre de la clase Trabajador es en letras itlicas, correspondiente a una clase abstracta.) Ejemplo: En el diagrama de la Figura 4.110, se muestra una variante del problema anterior donde Trabajador es una clase concreta, ya que para instanciar un Trabajador de tipo no especificado en el diagrama, se debe hacer una instancia de la superclase Trabajador.

Trabajador

Inge niero

Arquitecto

Doctor

Figura 4.110. Diagrama de clases donde Trabajador es una clase concreta ya que adems de poder instanciar objeto de las clases concretas Ingeniero, Arquitecto, y Doctor, tambin se pueden instanciar trabajadores no especificados en el diagrama. (Ntese que el nombre de la clase Trabajador es en letras normales, correspondiente a una clase concreta.) Ejemplo: La clase Empleado es una clase abstracta, ya que los empleados deben especificarse si son Honorarios o Nmina, como se muestra en la Figura 4.111. La operacin Computar Pago es una operacin abstracta en la clase abstracta Empleado, requiriendo su implementacin en las subclases de Empleado. Ntese que el nombre de la clase abstracta es en letras cursivas.

Empleado Ganancias Computar-pago()

Empleado Honorarios

Empleado Nmina

Figura 4.111. Diagrama de clases donde Empleado es una clase abstracta, mientras que Empleado Honorarios, y Empleado Nmina son clases concretas. La operacin Computar Pago debe ser definida como una operacin abstracta en la clase abstracta Empleado.

Weitzenfeld: Captulo 4

39

La jerarqua general de clases, para clases abstractas y concretas, se muestra en la Figura 4.112. El diagrama es muy conciso aunque un poco complicado ya que el concepto de herencia se describe utilizando un diagrama con herencia. Comenzando desde arriba y llendo hacia abajo en la jerarqua, podemos ver que la clase Clase puede especializarse en una Clase Concreta o en una Clase Abstracta. La Clase Concreta, que es una clase instanciable, se vuelve una Clase Hoja si no hay ninguna otra clase que herede de ella, mientras que la Clase Nodo contiene subclases adicionales. En otras palabras, la distincin entre una clase hoja y una clase nodo es su posicin dentro del rbol de herencia, siendo ambas son instanciables. Por otro lado, la asociacin Tiene-Subclase entre Clase Nodo y Clase muestra las posibles subclases de la jerarqua, comenznado nuevamente con Clase. De tal manera el rbol puede continuar indefinidamente mientras sigan existiendo una nueva Clase Nodo o una Clase Abstracta, que tambin es un nodo. Dado que la Clase Abstracta por definicin no es instanciable, no se agrega un nivel de herencia adicional como se hizo con la Clase Nodo.

Subclase 1..*

Clase

Subclase 1..* Tiene-Subclase

Tiene-Subclase Clase Concreta

Superclase Clase Abstracta *

Superclase Clase Nodo *

Figura 4.112. Jerarqua general de clases, describiendo la relacin entre clases abstractas y concretas. 4.7.6 Herencia Mltiple La herencia mltiple permite a una clase tener ms de una superclase y heredar aspectos de todos sus ancestros. Ejemplo: Una jerarqua de clases conteniendo una superclase Vehculo, con dos subclases Vehculo de Agua y Vehculo de Tierra, y una subclase comn a ambas llamado Vehculo Anfibio. El diagrama de muestra en la Figura 4.113.

Clase Hoja

Weitzenfeld: Captulo 4

40

Vehculo

V ehculo de Agua

V ehculo de Tierra

B arco

Vehculo Anfibio

Autom vil

Figura 4.113. Diagrama de clases de herencia mltiple para Vehculo, conteniendo la clase Vehculo Anfibio, la cual hereda a la vez de Vehculo de Agua y Vehculo de Tierra. En herencia sencilla no existen conflictos entre superclases. Cuando se hereda la misma operacin de mltiples ancestros, como opcin, se debe sobrescribir la operacin en la nueva clase para evitar conflictos. Verificar que no se herede ms de una vez aspectos de una clase (superclase comn a varias jerarquas). La ventaja de incorporar herencia mltiple, es que permite integrar informacin de dos o ms superclases a la vez, dando ms poder en la especificacin de clases y ms oportunidad de reuso, siendo por lo general ms natural para el modelo de objetos que la herencia sencilla. Por otro lado, la desventaja de incorporar herencia mltiple, es que es ms complicada que herencia sencilla, ya que se pierde la simplicidad conceptual y de implementacin. El mayor problema resultante es que se podra estar heredando varias veces una misma caracterstica de diferentes clases ancestrales. En general, se pueden definir reglas para resolver ambigedades y evitar conflictos entre las caractersticas heredadas por varios recorridos en la jerarqua de herencia. Ejemplo: Un Vehculo Anfibio estara heredando caractersticas comunes a todos los Vehculo, como Velocidad, de forma repetida, ya que heredara tales caractersticas a travs de Vehculo de Agua y Vehculo de Tierra. Clases disjuntas son clases que semnticamente describen caractersticas diferentes, de diferente jerarqua de herencia (discriminadores diferentes). Clases no disjuntas son clases que tienen aspectos comunes (mismo discriminador) por lo cual una clase que herede caractersticas de ambas estara compartiendo tales propiedades. Se puede incorporar herencia mltiple de una misma generalizacin, si las clases dentro de la generalizacin son no disjuntas. (No se debe heredar de dos clases perteneciendo a una misma generalizacin si las clases dentro de la generalizacin son disjuntas.) Ejemplo: La clase Vehculo Anfibio est heredando de una sola jerarqua de generalizacin, Tipo de Vehculo, por lo cual Vehculo de Tierra y Vehculo de Agua deben ser no disjuntos para que la herencia mltiple sea correcta, o sea, que exista la posibilidad de tener un vehculo que funcione en agua y tierra a la vez. Por otro lado, una clase Empleado Honorario Asalariado estara heredando a la vez de las clases Empleado Honorario y Empleado Asalariado, siendo esto incorrecto ya que estas son clases disjuntas dentro de una misma jerarqua de generalizacin, o sea que es incorrecto que un empleado se le considere que gana por honorarios y tambin es asalariado. La decisin si dos clases en una misma generalizacin son disjuntas o no disjuntas depende de su interpretacin. Se puede incorporar herencia mltiple de dos generalizaciones distintas, donde las clases son disjuntas. Cada generalizacin debe cubrir una sola propiedad, por lo cual una nueva clase creada por medio de la herencia mltiple estara siendo refinada sobre dimensiones de generalizacin diferentes e independientes.

Weitzenfeld: Captulo 4

41

Ejemplo: De la generalizacin de Empleado se puede crear dos jerarquas diferentes de herencia, una jerarqua se define segn el Tipo de Pago del Empleado, dando lugar a Empleado Honorario y Empleado Asalariado. Otra jerarqua se define segn el Tipo de Pensin, dando lugar a Empleado Con Pensin y Empleado Sin Pensin. Se puede definir una nueva clase Empleado Honorario Con Pensin el cual hereda caractersticas de dos clases disjuntas, Empleado Honorario y Empleado Con Pensin, de dos jerarquas de generalizacin independientes, y la herencia mltiple es correcta. Ejemplo: En la Figura 4.114, se muestra la clase Empleado Honorario Con Pensin que hereda de dos generalizaciones diferentes, Tipo de Pago y Tipo de Pensin. Por lo tanto, Empleado Honorario y Empleado Con Pensin definen clases disjuntas de dos jerarquas de generalizacin independientes, y la herencia mltiple de Empleado Honorario Con Pensin es correcta.
Empleado <<Forma de Pago>> <<Prestaciones>>

Empleado por Honorarios

Empleado por Nmina

Empleado con Prestaciones

Empleado sin Prestaciones

Empleado por Honorarios con Prestaciones

Figura 4.114. Diagrama de clases de herencia mltiple para Empleado Honorario Con Pensin heredando a la vez de Empleado Honorario y Empleado Con Pensin. 4.8 Mdulos Un mdulo o paquete (package) es una construccin lgica para agrupar clases, asociaciones y generalizaciones. El mdulo captura diferentes perspectivas de un sistema. Los bordes entre los diferentes mdulos pueden ser bastante arbitrarios. Un modelo de objetos consiste de uno o ms mdulos. Los nombres de clases y asociaciones deben ser nicos en cada mdulo, y se debe mantener consistencia entre los nombre de varios mdulos. La misma clase puede aparecer en diferentes mdulos, aunque debe ser definida solamente en uno de los mdulos y referido en los otros. Deben haber menos conexiones entre mdulos que asociaciones dentro de los mdulos. En sistemas grandes la jerarqua de mdulos puede ser de mltiples niveles. Cada mdulo debe proveer una visin de alto nivel de las clases ms importantes del sistema, mostrando las clases y sus asociaciones sin atributos u operaciones. Cada una de estas clases se asigna a su propio mdulo, mostrando su descomposicin en clases por generalizacin y agregacin. En la Figura 4.115 se muestra la notacin para un mdulo o paquete en UML. Ntese que el mdulo no tiene ninguna propiedad, a diferencia de la clase. Sirve nicamente como elemento organizacional de las clases.
Nombre del Mdulo

Figura 4.115. Notacin para un mdulo en UML. Por ejemplo, modelos en forma de "estrella" son bastante comunes, donde la estructura de alto nivel est en un mdulo, y otros mdulos expanden las superclases con generalizacin y aaden asociaciones a clases de bajo nivel. Para integrar estos y los conceptos anteriores que se han descrito a lo largo del captulo, presentamos en esta seccin un ejemplo mas completo de un Automvil correspondiente al diagrama de la Figura 4.116.

Weitzenfeld: Captulo 4

42

Automvil

Figura 4.116. Diagrama para un mdulo de un Automvil. Los mdulos en los cuales est subdividido el mdulo principal del Automvil son los siguientes: Carrocera, Sistema de Frenos, Sistema de Alimentacin, Sistema Elctrico, y Sistema Mecnico, como se muestra en la Figura 4.117.
Carrocera Sistema de Frenos Sistema de Alimentacin Sistema E lctrico Sistema Mecnico

Figura 4.117. Mdulos que componen el mdulo principal del Automvil: Carrocera, Sistema de Frenos, Sistema de Alimentacin, Sistema Elctrico, y Sistema Mecnico. Estos mdulos son descritos con mayor detalle a continuacin y cada uno por separado. En el captulo 6 veremos como se pueden aplicar el concepto del mdulo para organizar sistemas de mayor complejidad. Vale la pena notar que esta descripcin de un automvil corresponde al dominio de una aplicacin, en este caso del automvil. En el diagrama de la Figura 4.118 se muestra los mdulos descritos como clases. Esta descripcin puede coexistir con la de los mdulos anteriores si as se desea, donde cada una de estas clases se asigna al mdulo con su mismo nombre.
Automvil Sistema Mecnico

Carrocera

Sistema Elctrico

Sistema de Frenos

Sistema de Alimentacin

Figura 4.118. Clases para el mdulo de un Automvil: Carrocera, Sistema de Frenos, Sistema de Alimentacin, Sistema Elctrico, y Sistema Mecnico. El mdulo de la Carrocera incluye el Chasis, la Cajuela, el Cofre, las Puertas y las Ventanas, las cuales pueden ser partes de las Puertas, como se muestra en la Figura 4.119.

Weitzenfeld: Captulo 4

43

Carrocera

2..n Cajuela 1 Puerta

1 Cofre 1 Chsis

Ventana

Figura 4.119. Mdulo de la Carrocera, el cual est compuesto por el Chasis, la Cajuela, el Cofre, las Puertas, y las Ventanas. El mdulo del Sistema de Freno incluye el Freno de Mano, el Pedal de Freno, los Frenos de Tambor y de Disco, y las Balatas, como se muestra en la Figura 4.120.
Sistema de Frenos

1 Freno de Mano

1 Pedal de Freno

1..* Freno 1..* Balata

Freno de Tambor

Freno de Disco

Figura 4.120. Mdulo del Sistema de Freno, que incluye el Freno de Mano, el Pedal de Freno, los Frenos de Tambor y de Disco, y las Balatas. El mdulo de Alimentacin incluye el Tanque de Gasolina, la Bomba de Gasolina, el Filtro de Aire y de Gasolina, y el Carburador o la Inyeccin, como se muestra en la Figura 4.121.

Weitzenfeld: Captulo 4

44

Sistema de Alimentacin

Tanque de Gasolina

Mezclador

Bomba de Gasolina

Filtro de Aire

Filtro de Gasolina

Carburador

Inyeccin

Figura 4.121. Mdulo de Alimentacin, que incluye el Tanque de Gasolina, la Bomba de Gasolina, el Mezclador conteniendo el Filtro de Aire y de Gasolina, y que se especializa en el Carburador o la Inyeccin. El mdulo Elctrico incluye el Distribuidor, la Bobina, la Batera, el Interruptor de Arranque, el Regulador de Voltaje, el Alternador, y las Bujas, como se muestra en la Figura 4.122.
Sistema Elctrico

1 Distribuidor Bobina

1 Batera

1 Interruptor de Arrangue

1 Regulador de Voltaje

1 Alternador

2..n Buja

2 Solenoide

1 Condensador

* Escobilla

Figura 4.122. Mdulo Elctrico, que incluye el Distribuidor, la Bobina compuesta por dos Solenoides, la Batera, el Interruptor de Arranque, el Regulador de Voltaje, el Alternador, y las Bujas. El mdulo Sistema Mecnico incluye los mdulos de Sistema de Transmisin, Sistema de Lubricacin, Sistema Motriz, Sistema de Enfriamiento, Sistema de Suspensin, y Sistema de Direccin, como se muestra en la Figura 4.123.
Sistema de Transmisin Sistema de Lubricacin Sistema Motriz Sistema de Enfriamiento Sistema de Suspensin Sistema de Direccin

Figura 4.123 Mdulo Mecnico que incluye los mdulos de Sistema de Transmisin, Sistema de Lubricacin, Sistema Motriz, Sistema de Enfriamiento, Sistema de Suspensin, y Sistema de Direccin. Estos mdulos Sistema Mecnico tambin pueden ser descritos como clases: Sistema de Transmisin, Sistema de Lubricacin, Sistema Motriz, Sistema de Enfriamiento, Sistema de Suspensin, y Sistema de Direccin, como se muestra en la Figura 4.124.

Weitzenfeld: Captulo 4

45

Sistema Mecnico

Sistema de Transmisin

Sistema de Direccin

Sistema de Lubricacin

Sistema de Suspensin

Sistema Motriz

Sistema de Enfriamiento

Figura 4.124 El mdulo Sistema Mecnico que incluye las clases de Sistema de Transmisin, Sistema de Lubricacin, Sistema Motriz, Sistema de Enfriamiento, Sistema de Suspensin, y Sistema de Direccin. El mdulo de Transmisin incluye la Palanca de Velocidades, la Caja de Velocidades, el Overdrive, la Transmisin Manual o Automtica, y el Embriague, como se muestra en la Figura 4.125.
Sistema de Transmisin

Palanca de Velocidades

Caja de Velocidades

Transmisin

Embriague

Manual

Automtica

Figura 4.125. Mdulo de Transmisin, que incluye la Palanca de Velocidades, la Caja de Velocidades, el Overdrive, la Transmisin Manual o Automtica, y el Embriague. El mdulo de Lubricacin incluye la Bomba de Aceite, y el Crter, como se muestra en la Figura 4.126.
Sistema de Lubricacin

Bomba de Aceite

Crter

Figura 4.126. Mdulo de Lubricacin, que incluye la Bomba de Aceite, y el Crter. El mdulo Motriz incluye el Cigeal, el Arbol de Levas, los Pistones, y los Pistones, como se muestra en la Figura 4.127.

Weitzenfeld: Captulo 4

46

Sistema Motriz

1 Cigeal

1 Arbol de Levas

4..* Cilindro

4..* Pistn

Figura 4.127. Mdulo Motriz, que incluye el Cigeal, el Arbol de Levas, el Cilindro, y los Pistones. El mdulo de Enfriamiento incluye el Radiador, el Termostato, el Ventilador, y la Bomba de Agua, como se muestra en la Figura 4.128.
Sistema de Enfriamiento

Radiador

Termostato

Ventilador

Bomba de Agua

Figura 4.128. Mdulo de Enfriamiento, que incluye el Radiador, el Termostato, el Ventilador, y la Bomba de Agua. El mdulo de Suspensin incluye los Amortiguadores, la Barra Estabilizadora, y los Resortes, como se muestra en la Figura 4.129.
Sistema de Suspensin

1 4 Amortiguador Delantera

1 Trasera 4 Resorte

Barra Estabilizadora

Figura 4.129. Mdulo de Suspensin, que incluye los Amortiguadores, la Barra Estabilizadora, y los Resortes. El mdulo de Direccin incluye la Caja de Direccin, el Eje, y el Volante, como se muestra en la Figura 4.130.

Weitzenfeld: Captulo 4

47

Sistema de Direccin

Eje

Volante

Caja de Direccin

Figura 4.130. Mdulo de Direccin, que incluye la Caja de Direccin, el Eje, y el Volante. Ya que el diagrama de un modelo complejo puede ser muy grande, los mdulos se deben diagramar en una o ms pginas. Por lo general no se debe incluir ms de un mdulo por pgina, siendo el uso de pginas una conveniencia de notacin y no un aspecto de lgica. Las asociaciones y generalizaciones deben aparecer en una sola pgina, mientras que ciertas clases, pueden aparecer en mltiples pginas para servir de vnculo entre ellas. Se busca minimizar el nmero de estas clases puente.

Weitzenfeld: Objetos

10/11/2002

48

Weitzenfeld: Captulo 5

5 Programacin con Java

En este captulo haremos una breve introduccin al lenguaje de Java. Este captulo no es sustituto de ninguna manera de un libro dedicado exclusivamente a la programacin en Java. Ms bien buscamos dar una introduccin que permita relacionarse ante todo con el lenguaje y luego con la programacin que se mostrar ms adelante durante el captulo 10 correspondiente al Modelo de Implementacin, donde se mostrar parte del cdigo final del Sistema de Reservaciones de Vuelo. 5.1 Sistema Para apreciar el gran movimiento que detrs de Java hay que comprender que Java es mucho ms que un lenguaje, es ms bien un sistema con un alcance muy amplio. Es en cierta manera un fenmeno como el que desato Smalltalk hace 20 aos gracias al sistema que tena alrededor de su lenguaje. Por lo tanto comenzaremos esta seccin analizando las caractersticas principales del sistema de Java, siguiendo con otros aspectos significativos. 5.1.1 Caractersticas El lenguaje de Java tiene ciertas caractersticas que lo han hecho un lenguaje trascendental en la actualidad para la programacin de sistemas de cmputo. Estos se pueden reducir a los siguientes puntos: ? ? Orientado a Objetos Ante todo Java es un lenguaje orientado a objetos, lo cual lo pone en la misma categora que lenguajes como C++ y Smalltalk. Como parte esta caracterstica, se cuenta con un ligado dinmico de clases en tiempo de ejecucin, herencia y polimorfismo, adems de aspectos de metanivel similares a los de Smalltalk. ? ? Porttil Uno de los aspectos que han hecho de Java un lenguaje muy utilizado es su portabilidad. A diferencia de lenguajes como C y C++ que varan en su detalle dependiendo de la mquina en que sean ejecutados, Java es exactamente igual bajo cualquier plataforma. Por ejemplo, a diferencia de C y C++, el tamao de los tipos de datos en Java es fijo, independiente de la mquina. La gran importancia de este aspecto es que si se compila el programa bajo una plataforma particular, el sistema correr en cualquier mquina, reduciendo mucho el costo de desarrollo (tiempo y dinero). Para ello existen el concepto de la mquina virtual de Java (JVM Java Virtual Machine) que debe existir en cada plataforma donde se ejecute un programa de Java. ? ? Abierto El aspecto de portabilidad se da gracias a su diseo abierto que permite a cualquier compaa, e incluso desarrollador, tomar el cdigo fuente, para adaptarlo a una nueva plataforma donde an no se ha probado. Ninguno de los dems lenguajes ofrecen tal diseo abierto. Otra razn para la gran aceptacin de Java. ? ? Gratis Muy de la mano con el aspecto abierto de Java es que el lenguaje se ofrece gratis aunque bajo licencia a cualquier usuario. Esto reduce obviamente el costo de la aplicacin y fortalece la decisin para su utilizacin bajo distintas plataformas, donde no se incurre en el gran nmero de licencias pagadas, tpicamente por mquina, que la mayora de los dems productos obligan. ? ? Integrado al Web Entre todos los aspectos mencionados hasta ahora, quiz el de su integracin al Web, ha sido la razn para su gran difusin en una poca donde el Internet ha sido de tanta importancia. Java es el nico lenguaje, con excepcin de algunos lenguajes de scripts, que viene integrado con los browsers ms utilizados en el Web. ? ? Simple Otro aspecto para lograr la gran aceptacin de Java es su similitud con C y C++ en relacin a las expresiones bsicas del lenguaje. Esto ha permitido a los programadores aprender Java ms rpidamente, a diferencia de lenguajes como Smalltalk que requieren un cambio en la manera de pensar para programadores ya acostumbrados a C y C++. Sin embargo, Java se considera ms puro que C++, ya que un programa en Java no contiene ms que clases, simplificando el programa y al propio compilador. Java elimina mucha de la complejidad de C++, como es la aritmtica de apuntadores lo cual agrega mucha complejidad en la administracin de memoria. Se elimina la complejidad adicional de tipos como estructuras y el uso de asociaciones de tipo a travs de typedefs, junto con el preprocesador de C++ con palabras reservadas como #define , ? include y ? ifdef. Otro aspecto que es eliminado es la sobrescritura de operadores. Tambin se eliminan aspectos de manejo complicado como es la herencia mltiple. ? ? Robusto En contraste a C++ y en especial a C, Java es fuertemente tipificado, lo que ayuda a encontrar ms fcilmente los errores de programacin durante la etapa de compilacin. Java tambin incluye manejo de excepciones y recoleccin de basura para lograr programas ms robustos.

Weitzenfeld: Captulo 5

?? ??

??

??

Seguro Gracias a la eliminacin de los apuntadores de C y C++, Java logra un modelo de manejo de memoria mucho ms seguro. Esta seguridad es adems apoyado por el modelo de verificacin de cdigo en tiempo de ejecucin, como veremos ms adelante en la descripcin del modelo completo de Java. Eficiencia Java en la actualidad se le considera un lenguaje eficiente. Y aunque nunca llegue a la eficiencia de C si se le compara en la actualidad con C++ en relacin a esto. Esta eficiencia se basa, en que se cuenta con un compilador para la generacin de cdigo en contraste con aquellos lenguajes completamente interpretados donde el rendimiento es menor. En Java se cuenta en la actualidad con un compilador incremental (JIT Just-inTime Compiler), que ayuda a lograr estos objetivos. Bibliotecas Otro aspecto que ha hecho de Java un lenguaje de mucha aceptacin es la gran riqueza de sus bibliotecas, llamadas paquetes (package). Esto es en radical contraste con C y C++ donde las bibliotecas realmente no existen. Al contrario, Java contiene un sin fin de bibliotecas que facilitan de gran manera la creacin de programas, adems de asegurar una estandarizacin entre aplicaciones. Existen bibliotecas para el manejo de estructuras de datos avanzadas, manejo de multimedia, manejo de redes como TCP/IP, procedimientos remotos y concurrencia mediante mltiples hilos. En la actualidad, aprender el lenguaje de Java como tal es slo un 10% del esfuerzo, el 90% restante debe dedicarse a aprender a utilizar sus bibliotecas. Obviamente se estudian slo aquellas que se deseen utilizar. Por ejemplo, una biblioteca importante es la del sistema de ventanas que puede correr bajo cualquier plataforma. Existe el AWT (Abstract Window Toolkit) desde la primera versin de Java, y se cuenta en la actualidad con las bibliotecas JFC (Java Foundation Classes), tambin conocidas como SWING. Adems de stas existen bibliotecas para manejo de grficas en 2 y 3 dimensiones. Incluso existen versiones para correr en plataformas mviles, por ejemplo, como asistentes personales. Tecnologa Existe una gran nmero de productos y tecnologa en general desarrollada alrededor de Java. Aparte de Java como lenguaje se cuenta con productos tales como EJB (Enterprise JavaBeans), JSP (Java Server Pages), Java Servlets y JDBC (Java Data Base Connectors). Adems de estas y otras, existen productos relacionados con estndares tales como CORBA (Common Object Request Brower Architecture) y XML (eXtended Markup Language). En la actualidad se cuenta con tres ediciones principales Java: J2EE (Java2 Enterprise Edition), J2SE (Java2 Standard Edition) y J2ME (Java2 Micro Edition).

5.1.2 Ambiente de Compilacin y Ejecucin El modelo de compilacin y ejecucin de Java se muestra en la Figura 5.1. Del lado izquierdo se muestra los pasos para la compilacin de un programa en Java, mientras que del lado derecho se muestran los pasos para su ejecucin.
Tiempo de Compilacin Cdigo Java Tiempo de Ejecucin Cargador de Clases Verificador de Bytecode Compilador Java Red Interpretador Generador de Cdigo

Bytecode Java

JVM Runtime Hardware

Figura 5.1 Modelo de compilacin y ejecucin de Java. Compilacin Se escribe un programa en cdigo Java. Este programa, que tiene como extensin el sufijo .java, es compilado por cualquiera de los compiladores de Java en alguna de las distintas plataformas. En general debe existir un archivo .java por cada clase que exista en el programa, donde el archivo debe tener el mismo nombre que la clase contenida. El compilador genera el cdigo final, conocido como bytecode, a ser interpretado por la mquina virtual

Weitzenfeld: Captulo 5

de Java. El programa generado tiene como extensin el sufijo .class. Se genera un archivo .class por cada clase que se tenga en la aplicacin. Por ejemplo, si se tiene una clase llamada ej, el nombre del archivo debe ser ej.java. El archivo se compilara mediante algn ambiente de desarrollo o utilizando el comando javac que viene incluido en los kit de desarrollo de Java como JDK (Java Development Kit) o SDK (Standard Development Kit). Por ejemplo, para compilar el archivo anterior, para compilar el archivo anterior se ejecutara javac ej.java Esta compilacin resultara en el archivo ej.class. Ejecucin Durante la ejecucin se obtiene el bytecode, guardado en los archivos .class, que puede ya estar en la plataforma actual o haber sido enviado por la red, como en el caso de un browser. El bytecode es cargado en la mquina virtual por el cargador de clases. A continuacin este cdigo es verificado por el verificador de bytecode, y dependiendo del hardware con que se cuenta, puede ser interpretado y ejecutado por el procesador virtual de la mquina virtual o traducido a cdigo de un procesador de Java mediante el generador de cdigo. ? ? Existen dos maneras de ejecutar (y estructurar) un programa dependiendo de su ambiente de ejecucin. En el caso de una aplicacin normal (standalone, esta se ejecuta mediante el siguiente interpretador de Java, llamado simplemente java: java ej2 ? ? En el caso de una aplicacin que se ejecuta desde un browser, llamado un applet, el contenido de los archivos .class que estn almacenados en el servidor, son transmitidos a travs de la red y ejecutadas en la mquina cliente (que puede ser la misma mquina que el servidor). Dado que un browser slo comprende archivo .html, el applet debe ser relacionado con un archivo llamado, por ejemplo ej.html. Este archivo debe contener la siguiente lnea: <applet code=ej.class width=200 height=200></applet> Dado que pueden haber mltiples archivos .class, slo el principal es el que se incluye en la lnea anterior. Otra forma adicional de ejecutar el applet es mediante el comando appletviewer, de la siguiente forma: appletviewer ej.html A lo largo del captulo iremos describiendo con mayor detalle el desarrollo de programas en Java junto con ejemplos. 5.1.3 Paquetes Java lleva a un nuevo nivel el concepto de bibliotecas o paquetes. Estos paquetes proveen una amplia funcionalidad para crear nuevas aplicaciones para Java. Adems de servir como bibliotecas, definen un API (Application Program Interface) que permite al desarrollador extender las clases de estos paquetes para adaptarlos a las necesidades bsicas de un programa. Java organiza estos paquetes en componentes jerrquicos a partir de dos directorios raz principales. El primero es java siendo parte esencial de lo que actualmente se conoce como el API 1.1 de Java. Los paquetes de este API se muestran en la Tabla 5.1.

Weitzenfeld: Captulo 5

Paquete java.applet

Contenido Clases para implementar applets correspondientes a aplicaciones que corren dentro de los browsers. java.awt Clases para grficas, componentes (GUI Graphic User Interface) y administradores de control de ventanas, adems de clases ms especializadas como para procesamiento de imgenes (AWT Advanced Window Toolkit). java.beans Clases e interfaces para construir JavaBeans correspondientes a GUIs independientes de plataformas. java.io Clases para control de entradas y salidas, tales como archivos y streams. java.lang Clases que componen el ncleo del lenguaje. java.math Clases para aritmtica avanzada, incluyendo manejo de precisin numrica arbitraria. java.net Clases relacionadas con el manejo de redes, tales como datagramas y sockets. java.rmi Clases para el manejo de mtodos remotos. java.security Clases para aspectos de seguridad, tales como criptografa. java.sql Clases para acceso a base de datos con el lenguaje SQL. java.text Clases para internacionalizacin del idioma, independiente del lenguaje particular. java.util Clases adicionales, tales como estructuras de datos avanzadas y compresin de datos. Tabla 5.1 Paquetes bsicos de Java. En la actualidad se cuenta con el API 1.2 de Java, mejor conocido como Java2, el cual incluye adems del paquete java, el paquete javax donde se encuentran componentes ms avanzados, como se muestra en la Tabla 5.2. Paquete javax.accessibility Contenido Clases que definen contratos entre componentes de interfaces de usuario y una tecnologa asistente que provee acceso a esos componentes. javax.activation Clases que definen activacin de los componentes de JavaBeans. javax.ejb Clases para el manejo de EJB (Enterprise JavaBeans). javax.jms Clases para el manejo de JMS (Java Message Server). javax.mail Clases para el manejo de correo. javax.naming Clases para el acceso de los servicios de nombres. javax.rmi Clases para la invocacin de mtodos remotos incluyendo CORBA. javax.servlet Clases para el manejo de servlets y JSP (Java Server Pages). javax.sql Clases para el acceso a base de datos con SQL. javax.swing Clases que proveen un conjunto de componentes para GUIs que trabajan en cualquier plataforma. javax.transaction Clases para el manejo de transacciones entre componentes. Tabla 5.2 Paquetes extendidos de Java.

En Java, cada clase debe ser parte de un paquete (package), y esta clase puede ser referida por su nombre completo calificado, el cual consiste de la jerarqua del paquete y el nombre de la clase, todos separados por puntos. Los propios nombres de paquetes generalmente estn compuestos de mltiples componentes separados por puntos. Por ejemplo, la clase PixelGrabber que se encuentra en el paquete java.awt.image sera accesado mediante: java.awt.image.PixelGrabber Vale la penar notar que los paquetes se guardan en distintos directorios, donde el . realmente corresponde a / (\ en la PC), donde se traduce, por ejemplo java.awt.image a java/awt/image. Por lo tanto la clase PixelGrabber estra guardada dentro del directorio anterior. Adems de los paquetes mencionados en las Tablas 5.1 y 5.2 existe un nmero muy extenso de productos y productos adicionales desarrollados por Sun y por otras compaas como los paquetes para grficas en 2 y 3 dimensiones que son tambin parte de Java y las paquetes para acceso a bases de datos de Oracle y Sybase. 5.2 Lenguaje El lenguaje de Java contiene muchos aspectos que deben dominarse por un programador. Comenzaremos por los aspectos ms bsicos hasta llegar a lograr programas completos.

Weitzenfeld: Captulo 5

5.2.1 Aspectos Generales Existen ciertos aspectos bsicos del lenguaje que se requieren describir antes de poder proseguir con los tipos de datos y expresiones que se pueden aplicar para generar un programa completo. Comentarios El primer aspecto que debe conocerse en cualquier lenguaje es como distinguir entre cdigo y comentarios. En Java existen tres tipos distintos para la especificacin de comentarios, como se muestra en la Tabla 5.3. Notacin Descripcin // lnea comentada Las dos diagonales indican el comienzo de un comentario que tiene efecto hasta el final de la lnea. /* prrafo comentado */ La diagonal seguida por el asterisco indica el inicio de un prrafo comentado. Para terminarse el comentario debe aadirse un asterisco seguido de otra diagonal. Estos comentarios no pueden anidarse uno dentro del otro. /** prrafo comentado */ La diagonal seguida por dos asteriscos indica el inicio de un prrafo comentado. Para terminarse el comentario debe aadirse un asterisco seguido de otra diagonal. A diferencia del comentario anterior, este es un comentario documentable que puede ser extrado mediante el comando javadoc para producir un documento de documentacin sencillo a partir del cdigo fuente de Java. Estos comentarios no pueden anidarse uno dentro del otro. Tabla 5.3 Notacin para comentarios. Caracteres La especificacin de caracteres en Java es distinta a la mayora de los dems lenguajes. Java utiliza 16 bits en lugar de los ms comunes 8 bits correspondientes al cdigo ASCII para especificar caracteres. Este cdigo de 16 bits es conocido en Java como Unicode, el cual mantiene compatibilidad con ASCII. Existen actualmente 34,000 caracteres definidos en Unicode pero no todos pueden ser desplegados en todas las plataformas, por lo cual se utilizan secuencias especiales de escape con el siguiente formato: \uxxxx, donde xxxx representa una secuencia de uno a cuatro dgitos hexadecimales. Por ejemplo, el caracter nulo es \u0000. Adems de este formato de especificacin, tambin se apoya las secuencia especiales de escape, como en C, que son \n y \t, y de manera ms general \xxx , donde xxx representa un dgito octal. Palabras reservadas Todo lenguaje de programacin cuenta con un nmero de palabras reservadas que tienen un significado especial y predefinido para Java. Tales palabras incluyen if, else, etc. En Java son 48 las palabras reservadas, las cuales el usuario no puede utilizar para sus propios usos. Identificadores Dentro de las palabras que el usuario puede definir se encuentran los identificadores. Los identificadores sirven para relacionarse con estructuras del programa. Por ejemplo, para poder definir una clase o accesar un objeto, se requiere definir un identificador. Identificadores que guardan o se refieren a valores de algn tipo son tambin conocidos como variables. Los nombres de los identificadores son cualquier palabra, con excepcin de las reservadas por Java, que inician con cualquier letra del alfabeto o que comienzan con los siguientes smbolos: $ o _. Estos identificadores pueden ser de cualquier tamao. Por ejemplo, identificadores aceptables son: ID, nombre, _temp, $dolar, etc. Oraciones Toda oracin en Java correspondiente a una lnea de ejecucin tiene como caracter final el ;. Una notacin relacionada el bloque que utiliza de llaves { y } para especificar el inicio y fin de un grupo de oraciones. Paquetes Como mencionamos anteriormente, Java organiza sus bibliotecas alrededor del concepto de paquetes (packages). Dado el amplio nmero de paquetes que existen en el sistema de Java, adems de aquellos que son generados por los propios desarrolladores, es necesario tener un manejo modular de manera que clases dentro de un paquete no tengan

Weitzenfeld: Captulo 5

conflictos con clases en otros paquetes, inclusive con clases que pudieran tener el mismo nombre. Por tal motivo, Java utiliza la expresin package que debe aparecer como primera instruccin en un archivo de cdigo fuente en Java. Por ejemplo, un paquete con el nombre ej se incluira como primera instruccin de todos los archivos que contengan clases de este paquete: package ej; De tal manera se especifica de qu paquete es componente la clase (y el archivo correspondiente). Las clases que son parte de un paquete particular tienen acceso a todas las dems clases del mismo paquete, algo que discutiremos con mayor detalle ms adelante. Cuando un archivo es parte del un paquete, la clase compilada debe ubicarse de manera apropiada dentro de la jerarqua de directorios para poder ser accesada de manera correcta, como se mencion anteriormente. Importar Muy relacionada al concepto de paquetes es la instruccin import, la cual permite utilizar clases definidas en otros paquetes bajo nombres abreviados. Aunque siempre es posible utilizar otras clases por medio de sus nombres calificados completos, import, que no lee la clase ni la incluye, permite ahorrar escritura haciendo al cdigo ms legible. En otras palabras, sin la expresin de import, se puede utilizar la clase PixelGrabber siempre y cuando al utilizarla se le llame por su nombre calificado completo java.awt.image.PixelGrabber. Existen tres formatos para import: ? ? import package; que permite que el paquete especificado sea conocido por el nombre de su ltimo componente. Por ejemplo, la siguiente expresin import java.awt.image; permite que la clase java.awt.image.PixelGrabber se le llame de la siguiente manera image.PixelGrabber ? ? import package.class; que permite que la clase especificada en el paquete sea conocida por su nombre de clase directamente. Por lo tanto, la expresin import java.awt.image.PixelGrabber; permite que la clase java.awt.image.PixelGrabber se le llame de la siguiente manera PixelGrabber ? ? import package.*; que permite que todas las clases en un paquete sean accesibles por medio del nombre de su clase directamente. Por ejemplo, la expresin import java.awt.image.*; permite que la clase java.awt.image.PixelGrabber y cualquier otras dentro de ese mismo paquete se le llame mediante su nombre directo, como PixelGrabber Se pueden incluir cualquier nmero de expresiones import, aunque todas deben aparecer despus de la expresin inicial de package y antes de cualquier definicin de clases o cdigo en general. Si dos paquetes importados mediante esta forma contiene clases con el mismo nombre, es un error usar sus nombres ambiguos sin usar el nombre calificado completo. 5.2.2 Estructuras Bsicas Una vez mencionados los aspectos bsicos del lenguaje de Java, proseguimos con la definicin de las estructuras o tipos de datos que se pueden definir dentro de Java. Comenzamos con los tipos de datos primitivos. Tipos Primitivos En Java existen un nmero de tipos primitivos o predefinidos como parte del lenguaje. Estos tipos se muestran en la Tabla 5.4.

Weitzenfeld: Captulo 5

Tipo Descripcin Valor Omisin byte 0 Es un estructura de 8 bits. char \u0000 Es una estructura en base a Unicode de 16 bits (sin signo). short 0 Es una estructura numrica de tipo entero de 16 bits. int 0 Es una estructura numrica de tipo entero de 32 bits. long 0 Es una estructura numrica de tipo entero de 64 bits. float 0.0 Es una estructura numrica de tipo real de 32 bits. double 0.0 Es una estructura numrica de tipo real de 64 bits. boolean false Es una estructura de 1 bits, con valores true o false. Tabla 5.4 Tipos primitivos predefinidos en Java. Los tipos primitivos son estructuras que guardan un valor primitivo y que son manipulados a travs de variables, declaradas de manera correspondiente, como veremos ms adelante. Los valores asignados por omisin a variables de estos tipos se muestra en la ltima columna. Los nombres correspondientes a tipos primitivos comienzan con una letra minscula. Existe un sin-tipo, llamado void. Los primeros cinco tipos en la tabla byte, char, short, int y long, son conocidos como tipos integrales. Tipos No-Primitivos Los tipos no-primitivos corresponden a clases los cuales son instanciadas en objetos. Los objetos son referenciados a travs de variables que guardan referencias de estos. A diferencia de las variables correspondientes a tipos primitivos que guardan un valor, las variables correspondientes a tipos no-primitivos guardan una referencia al objeto instanciado. En Java no existe un nmero predeterminado de tipos no-primitivos, aunque si existen algunos predefinidos a travs de las bibliotecas del lenguaje. Existe una clase muy particular que vale la pena mencionar. Esta clase es Object, que tiene como particularidad servir como la superclase a todas las dems clases del sistema, clases definidas en una biblioteca de Java o clases definidas directamente por el programador. Por ejemplo, una de estas clases ya definidas en Java es String. Esta clase es esencial en el manejo de cadenas. Variables Para poder utilizar uno de estos tipos de datos primitivos es necesario primero definir alguna variable que guarde el valor del tipo correspondiente. Las variables se representan por medio de un nombre seleccionado dentro de los posibles identificadores. Por ejemplo, dos nombres de variables vlidos seran, x y y. Habiendo definido el nombre de la variable se prosigue a declararla de acuerdo a algn tipo de dato. Como nota importante, todas las variables existen dentro de las clases y no pueden existir sueltas en un archivo como ocurre en C++. Declaraciones Una declaracin consiste en relacionar una variable con el tipo de dato que va a guardar. Por ejemplo si consideramos las dos variables, x y y, donde se desea que cada una de ellas guarde un valor entero, tendramos que hacer la siguiente declaracin: int x,y; Estas variables guardan inicialmente el valor de 0, hasta que se les haga una asignacin con un nuevo valor, algo que veremos ms adelante. Por ejemplo, una variable valor de tipo boolean se declarara de la siguiente forma: boolean valor; Las variables que hacen referencias a objetos de alguna clase se declaran de la misma forma. Si obj representa una variable de tipo ClaseX, su declaracin ser la siguiente: ClassX obj; A diferencia de las variables de tipos primitivos que guardan valores, las variables de clases guardan nicamente referencias a los objetos instanciados de estas clases. Esto se hace por la sencilla razn de que los objetos son estructuras ms complejas que los tipos primitivos por lo cual estos se guardan en memoria y las variables se refieren a esta ubicacin. De tal manera, una variable de clase guarda por omisin una referencia vaca o nula que corresponde a null en Java. Vale la pena resaltar que esta referencia nula no equivale al 0 como ocurre en C. En particular, null es una palabra reservada que significa ausencia de referencia. Constantes Como parte de las declaraciones de variables, Java permite agregar distintos tipos de modificadores, que afectan diversos aspectos de las variables. Existen por ejemplo modificadores para la visibilidad, correspondiente al manejo

Weitzenfeld: Captulo 5

del encapsulamiento, que sern mostrados ms adelante cuando se describan objetos y clase. Sin embargo, vale la pena mencionar un modificador particular que hace que una variable se vuelva una constante. Esto se hace a travs del modificador final como se muestra a continuacin. Por ejemplo, la siguiente declaracin hara que la variable c no pueda cambiar de valor. final int c = 5; Dado que la variable no puede cambiar de valor, es necesaria inicializarla con algn valor en el momento de su declaracin. Sera un error tratar de cambiar luego este valor. Arreglos El arreglo es una estructura presente en la gran mayora de los lenguajes por lo cual tampoco falta en Java. Aunque se utiliza una notacin similar a los dems lenguajes, su manejo es un poco diferente. Esto ltimo se debe a que los arreglos se manipulan por referencia, al igual que los objetos. La declaracin bsica de un arreglo es de la siguiente forma: int numeros[]; Esta declaracin especifica que la variable numeros har referencia a un arreglo de nmeros enteros. Estos nmeros sern luego accesados mediante la siguiente notacin, donde i representa el elemento del arreglo: numeros[i]; Para que esto funcione correctamente, es necesario inicializar la variable numeros para que se refiera a algn arreglo, ya que hasta ahora slo hemos hecho una declaracin. Existen dos formatos diferentes para hacer esta inicializacin. El primer formato es al similar al de C: int numeros[] = {1,2,4,8,16,32,64,128} Esta declaracin crea un arreglo de 8 elementos inicializando sus elementos a los valores especificados. La variable numeros guarda la referencia a dicho arreglo. La segunda manera de inicializar un arreglo es mediante la palabra new, que como veremos ms adelante se utiliza para instanciar cualquier tipo de objetos. La inicializacin de un arreglo mediante la palabra new es ms comn y especifica el tamao del arreglo, como se muestra a continuacin. int numeros[] = new int[50]; Por ejemplo, esta declaracin incluye la inicializacin de numeros como referencia a un arreglo de 50 enteros donde cada uno es inicializado con el valor de 0. Un aspecto importante con los arreglos es que se puede conocer su largo utilizando el modificador length, como se muestra a continuacin: numeros.length Esto permite obtener el largo definido para el arreglo. Los arreglos no tienen que ser de una sola dimensin, ya que Java apoya mltiples dimensiones. Estos arreglos son implementados como arreglos de arreglos. Por ejemplo, un arreglo de dos dimensiones de enteros se declara e inicializa de la siguiente manera: int numeros2[][] = new int[10][20]; Esta declaracin genera un arreglo con 200 elementos inicializados todos a 0. Como mencionamos antes, el manejo de Java implica que existen 10 arreglos cada uno de ellos refirindose a un arreglo de una dimensin de 20 elementos. Cuando se asigna un arreglo multidimensional, no se tiene que especificar el nmero de elementos que se contiene en cada dimensin. Por ejemplo, la siguiente es una declaracin vlida: int numero3[][][] = new int[10][][]; Esta declaracin asigna un arreglo que contiene 10 arreglos de una dimensin, donde cada se refiere a un arreglo de tipo int[][].La regla bsica en Java es que las primeras n dimensiones, con n ? 1, deben especificar el nmero de elementos. Ntese que en el caso de funciones (que veremos ms adelante en la seccin de clases), la declaracin de un arreglo como argumento de la funcin es similar al manejo descrito aqu. Sin embargo, existen dos formatos aceptados: ? ? Se puede utilizar la notacin similar a C: void func(char buf[]) { char s[] = new char [50]; ... } ? ? Pero tambin se puede utilizar la siguiente notacin: void func(char[] buf) { char[] s = new char [50]; ... } En el caso de arreglos de objetos, el manejo de arreglos es bastante similar al de los tipos primitivos. La consideracin principal es que crear un arreglo de objetos no crea todos los objetos que se guardan en el arreglo.

Weitzenfeld: Captulo 5

Esto se hace principalmente para ofrecer mayor flexibilidad en la creacin del arreglo, como permitir al programador hacer las llamadas deseadas a los constructores. Por lo tanto, si se quiere crear, por ejemplo un arreglo de 20 objetos de tipo Persona: Persona p[] = new Persona[20]; for (int i = 0; i < i.length; i++) p = new Persona(); Ntese que la primera declaracin e instanciacin del arreglo genera el arreglo de 20 elementos de tipo persona, aunque cada elemento est vaco. Dentro del ciclo for se instancia cada elemento, en este caso con los valores de omisin de la clase. Algunos de los detalles utilizados en este ejemplo quedaran ms claros ms adelante en el captulo. Cadenas Como en la mayora de los lenguajes, se pueden definir cadenas como arreglos de caracteres. En otras palabras se puede definir una cadena de la siguiente manera: char s[] = Prueba; La problemtica con esta manera de definir cadenas es que su manipulacin se vuelve complicada, por ejemplo comparar o concatenar cadenas. Para lograr un mejor manejo, Java define la cadena como una clase con todos los beneficios que esto significa. Aunque el tema de clases y objetos ser tratado ms adelante, vale la pena mencionar algunos aspectos del manejo de las cadenas en Java. Los objetos tipo cadenas son instancias de la clase java.lang.String. Por ejemplo, una cadena se puede instanciar cadenas de la siguiente forma: String s = Prueba; Un aspecto que resalta en Java en relacin al manejo de cadenas es el operador + que corresponde a una concatenacin. Por ejemplo, la siguiente expresin es vlida y resultara en las dos cadenas concatenadas: String s1 = Hola; String s2 = Mundo; String s3 = s1 + s2; Esta operacin tiene efectos profundos para el compilador. Por ejemplo, la siguiente funcin de impresin en C es muy problemtica para el compilador ya que involucra un nmero de argumentos variables (al igual que muchas otros funciones similares): printf(%s%s,s1,s2); Esto se resuelve en Java mediante el operador de concatenacin: print(s1 + s2); (En realidad la funcin print requiere del prefijo System.out para accesarse correctamente. Este prefijo ser explicado ms adelante.) Este es slo un ejemplo de las facilidades para el manejo de cadenas en Java (al igual que de muchos otros aspectos). La nica restriccin importante en los objetos de tipo String es que estos son inmutables, no pueden cambiarse una vez asignados. Por ejemplo, para poder manejar cadenas modificables se debe instanciar objetos de la clase StringBuffer a partir de un objeto String, algo que va ms all del alcance introductorio de este captulo. Existen ciertas funciones que se pueden aplicar a las cadenas para manipularlas, como son: length(), charAt(), equals(), compareTo(), indexOf(), lastIndexOf(), substring(). Estas tipo de funciones hacen de Java un lenguaje muy poderoso. Expresiones Bsicas Una vez que se haya declarado variables y posiblemente asignado un valor inicial, estas variables pueden ser manipuladas mediante diversos tipos de expresiones. En esta seccin describiremos las expresiones ms importantes que pueden ser aplicadas a variables de tipos primitivos. Ms adelante describiremos las expresiones que se pueden aplicar a objetos. Asignacin Las variables de tipos primitivos son utilizadas para guardar valores de sus respectivos tipos. Por lo tanto, la expresin ms importante que hay es la de asignacin de valores. Por ejemplo, para asignarle un valor a una variable x de tipo entero se hara lo siguiente: x = 10; Obviamente tuvo que haberse hecho antes la declaracin correspondiente. Incluso puede hacerse la asignacin al mismo momento de la declaracin. int x = 10;

Weitzenfeld: Captulo 5

10

La asignacin es similar para todos los dems tipos primitivos. Operadores Java apoya todos los operadores estndares de C, con la misma precedencia. La Tabla 5.5 muestra todos los operadores que se pueden aplicar a tipos primitivos (incluyendo aritmticos, integrales y booleanos) en orden de precedencia. Operador Tipo de Operando(s) Descripcin de la Operacin ++, -aritmtico incremento, decremento (unario) (pre o post) +, aritmtico ms, menos (unario) integral complemento de bit (unario) ? booleano complemento lgico (unario) ! cualquiera cast (tipo) *, /, % aritmtico multiplicacin, divisin, resto +, aritmtico suma, resta + cadena concatenacin de cadenas << integral desplazamiento hacia la izquierda >> integral desplazamiento hacia la derecha con signo >>> integral desplazamiento hacia la derecha con extensin de cero <, <= aritmtico menor que, menor o igual que >, >= aritmtico mayor que, mayor o igual que == primitivo igual (tienen valores idnticos) != primitivo no igual (tienen valores diferentes) & integral AND para bits & booleano AND booleano ^ integral XOR para bits ^ booleano XOR booleano | integral OR para bits | booleano OR booleano && booleano AND condicional || booleano OR condicional ?: boolean, cualquiera, cualquiera operador condicional (ternario) = variable, cualquiera asignacin *=, /=, %=, variable, cualquiera asignacin con operacin +=, -=, <<=, >>=, >>>=, &=, ^=, | = Tabla 5.5 Operadores para tipos primitivos predefinidos en Java. Por ejemplo, la siguiente es una expresin de multiplicacin, int x; x = 23*54; Aunque no es el objetivo mostrar ejemplos de todos los posibles operadores, vale la pena resaltar algunas diferencias de Java con C y C++: ? ? Java no apoya los operadores de apuntadores *,& o sizeof. ? ? Java no considera a . (acceso a campo) y [] (acceso a arreglo) como operadores. ? ? Java no apoya la sobrecarga de operadores. Como comentarios adicional sobre los operadores en Java, dado que todos los tipos en Java son valores con signo, el operador >> se define como un corrimiento a la derecha con extensin de signo, mientras que el operador >>> trata el valor de corrimiento lgico como un valor sin signo y lo corre a la derecha con extensin de cero. Control Aparte de los operadores, existen un nmero de expresiones de control que son utilizadas por los lenguajes para controlar el flujo de la lgica del programa. Estas expresiones son bastante estandarizadas en los lenguajes modernos aunque varan en ciertos detalles. La tabla 5.6 muestra las expresiones de control.

Weitzenfeld: Captulo 5

11

Expresin if (condicin-1) bloque-1 else if (condicin-i) bloque-i else bloque-n

while (condicin) bloque do bloque while (condicin)

switch (variable) case valor-i: bloque-i default: bloque-n

for (expr-1; condicin-2; expr-3) bloque

break label;

continue label;

label: expr

return expr; Tabla 5.6 Expresiones de control en Java. Si los bloques en la tabla involucran ms de una oracin, estos deben incluir llaves para especificar el inicio y fin del bloque. Todas las condiciones deben ser expresiones que devuelvan un valor booleano. Nuevamente, hacemos nfasis en que un valor numrico no puede utilizarse como uno booleano en Java, ni siquiera haciendo un cast. Los valores false y 0 no son equivalentes. En el caso de la expresin de for, en Java no se permite el uso de la coma para separar mltiples expresiones dentro de la condicin, aunque si es permitido dentro de las dos secciones, expr-1 y expr-3. El resto de las expresiones, con excepcin de label, son similares en su uso a las de C. 5.2.3 Objetos y Clases Todo programa de Java debe incluir clases. Consideremos los diversos aspectos de las clases como se describi inicialmente en el Captulo 4. Utilizando la notacin UML, una clase se representa como se muestra en la Figura 5.2.

Descripcin de la Expresin Si condicin-1 es verdadera se ejecuta el bloque-1. De lo contrario se prosigue con condicin-i de manera similar para ejecutar el bloque-i. Puede haber un nmero infinito de estas condiciones. Si ninguna condicin es verdadera se ejecuta el bloque-n. Mientras condicin sea verdadera se ejecuta el bloque. Mientras la condicin sea verdadera se ejecuta el bloque. A diferencia de la expresin anterior, primero se ejecuta el bloque y luego se revisa la condicin para la siguiente ejecucin. Se verifica el valor de la variable (tipo integral). Se compara a los valores especificados para los diversos casos, valor-i, hasta encontrar uno igual. En ese momento se ejecuta bloque-i. Si no se encuentra ninguno igual, se ejecuta bloque-n. Se ejecuta expr-1 al inicio de esta expresin. Si condicin-2 es verdadera se ejecuta el bloque. A continuacin se ejecuta expr-3 y se prueba condicin-2. Si esta es verdadera nuevamente se ejecuta el bloque. Se sigue ejecutando el bloque, precedido de la ejecucin de expr-3, mientras condicin-2 sea verdadera. Esta expresin permite interrumpir el flujo de una estructura de control con la opcin de saltar fuera de la seccin etiqueta por label:, o en su ausencia, saltar fuera de la estructura de control actual. Esta expresin permite interrumpir el ciclo actual de una estructura de control con la opcin de saltar a la ltima lnea de la seccin etiquetada por label:, o en su ausencia, saltar a la ltima lnea de la estructura de control actual. Etiqueta asignada a una expresin, utilizada en conjuncin con break y continue. Esta expresin devuelve el valor generado por expr.

NombreClase
Figura 5.2 Notacin de UML para una clase. En Java, el cdigo correspondiente a una clase se muestra continuacin: class NombreClase { } Ntese que el nombre de la clase siempre comienza con mayscula. Si el nombre es compuesto, como en este caso, para facilitar su lectura, la siguiente palabra debe iniciarse tambin con maysculas. No deben haber espacios dentro del nombre de la clase.

Weitzenfeld: Captulo 5

12

La anterior es probablemente la definicin ms sencilla que puede asignarse a una clase. La primera palabra class, sirve de prefijo para indicar el inicio de una clase. Por ejemplo, consideremos la clase Persona como se muestra en la Figura 5.3.
Persona

Figura 5.3 Notacin de UML para una clase llamada Persona. La clase Persona se define de la siguiente manera. class Persona { } En las siguientes secciones mostramos de manera incremental el resto de las definiciones relacionadas con la clase. Atributos El siguiente paso en la definicin de una clase es indicar sus atributos, estos se muestran nuevamente en la Figura 5.4.
NombreClase ListaAtributos

Figura 5.4 Notacin de UML para una clase con atributos. En Java, el cdigo correspondiente a una clase con atributos se muestra continuacin: class NombreClase { // atributos tipoAtributo1 nombreAtributo1; ... tipoAtributoi nombreAtributoi; ... tipoAtributoN nombreAtributoN; } La lista de atributos corresponde a declaraciones de tipos primitivos, compuestos de un tipo, tipoAtributoi, seguido de un nombre, nombreAtributoi, (los ... son nicamente para resaltar que es una lista de atributos, y la lnea // atributos representa un comentario nicamente). Ntese que los atributos comienzan siempre con una letra minscula, aunque las siguientes palabras en el caso de nombres compuestos, pueden comenzar con maysculas. Como con los nombres de clases, no deben haber espacios dentro del nombre y en especial no deben haber nombres repetidos. Por ejemplo, consideremos la clase Persona con varios atributos como se muestra en la Figura 5.5.
Persona nombre : Cadena edad : Entero seguroSocial : Entero licenciaConducir : Cadena

Figura 5.5 Notacin de UML para una clase llamada Persona, que contiene atributos. La clase Persona y sus atributos se definen de la siguiente manera. class Persona { // atributos String nombre; int edad; int seguroSocial; String licenciaConducir; } El orden de los atributos no tiene ninguna importancia dentro de la clase. Ntese que los tipos de los atributos no necesariamente tienen que ser tipos primitivos, como es el caso de String. Operaciones El siguiente paso en la definicin de una clase es indicar sus operaciones, estos, junto con los atributos se muestran en la Figura 5.6.

Weitzenfeld: Captulo 5

13

NombreClase ListaAtributos ListaOperaciones

Figura 5.6 Notacin de UML para una clase con atributos y operaciones. En Java, el cdigo correspondiente a una clase con atributos se muestra continuacin: class NombreClase { // atributos tipoAtributo1 nombreAtributo1; ... tipoAtributoi nombreAtributoi; ... tipoAtributoN nombreAtributoN; // operaciones tipoRetorno1 nombreMtodo1 ( listaParmetrosMtodo1 ) { cuerpoMtodo1 } ... tipoRetornoj nombreMtodoj ( listaParmetrosMtodoj ) { cuerpoMtodoj } ... tipoRetornoM nombreMtodoM ( listaParmetrosMtodoM ) { cuerpoMtodoM } } Aunque conceptualmente se habla de operaciones, en los lenguajes de programacin es ms preciso hablar de mtodos. La relacin entre estos dos trminos es que mltiples mtodos pueden corresponder a una misma operacin. La lista de mtodos anterior esta compuesta por el tipo de valor de retorno, tipoRetornoj, el nombre del mtodo, nombreMtodoj, los parmetros que recibe el mtodo, listaParmetrosj, y finalmente el cuerpo del mtodo, nombreCuerpoj. (Nuevamente, los ... son nicamente para resaltar que es una lista de mtodos.) Ntese que los nombres de los mtodos comienzan siempre con una letra minscula, aunque las siguientes palabras en el caso de nombres compuestos, pueden comenzar con maysculas. Como con los nombres de clases y atributos, no deben haber espacios dentro del nombre. En particular, listaParmetros, tiene el siguiente formato: tipoRetorno nombreMtodo ( tipo1 par1, tipo2 par2,...,tipoN parN ) { cuerpoMtodo } Por otro lado, cuerpoMtodo, es una lista de expresiones similares a las descritos en la seccin correspondiente adems de llamadas a otros mtodos. A diferencia de los atributos, pueden haber nombres repetidos para los mtodos. A esto se le conoce como sobrecarga de mtodos. Por ejemplo, consideremos la clase Persona con varios mtodos, adems de los atributos anteriores, como se muestra en la Figura 5.7.
Persona nombre : Cadena edad : Entero seguroSocial : Entero licenciaConducir : Cadena setNombre(String nombre) : Entero setEdad(int edad) : Entero set(String nombre, int edad) set(int edad, String nombre)

Figura 5.7 Notacin de UML para una clase Persona que contiene atributos y mtodos. La clase Persona, con sus atributos y mtodos, se define de la siguiente manera. class Persona { String nombre; int edad; int seguroSocial; String licenciaConducir;

Weitzenfeld: Captulo 5

14

int setNombre(String nom) { nombre = nom; return 1; } int setEdad(int ed) { edad = ed; return 1; } void set(String nom, int ed) { setNombre(nom); setEdad(ed); } void set(int ed, String nom) { setNombre(nom); setEdad(ed); } } El orden de los mtodos no tiene ninguna importancia dentro de la clase. Ntese que para evitar posibles conflictos, el nombre de un parmetro debe ser diferente del de un atributo. Si los dos nombre fueran iguales, la variable a ser utilizada se resuelve segn su alcance (scope). (Se utiliza la variable cuya definicin sea la ms cercana a su lugar de utilizacin, en este caso el parmetro del mtodo tendra precedencia.) Otro aspecto a notar son el uso del return en el caso de mtodos que devuelven algn tipo que no sea void. Adicionalmente, los ltimos dos mtodos tienen nombre similar, por lo cual realmente corresponden a una misma operacin que es asignar el valor al nombre y edad sin importar el orden de los parmetros. Este uso de la sobrescritura de mtodos es muy comn. Por ltimo vale la pena resaltar el manejo de parmetros. Todos los parmetros relacionados a tipos primitivos son pasados por valor. Esto significa que si el valor del parmetro es cambiado dentro del mtodo, esto no afectara de ninguna manera su valor original. Por ejemplo, consideremos la siguiente versin de los mtodos anteriores: int setEdad(int ed) { edad = ed; ed = 0; return 1; } void set(String nom, int ed) { setEdad(ed); setEdad(ed); } En el primer mtodo, se asigna el valor de ed a edad y luego se asigna 0 a ed. En el segundo mtodo, se llama dos veces al mtodo setEdad. Dado que ed fue pasado por valor, el 0 nunca fue devuelto al llamado original y el segundo setEdad vuelve asignar la edad correcta. Sin embargo, este no es el caso con los objetos, ya que estos son pasados por referencia. En otras palabras, aunque las variables no sean globales, los objetos a los que las variables se refieren s lo son, como es el caso de un objeto de tipo String. Consideremos ahora la siguiente modificacin a los mtodos originales: int setNombre(String nom) { nombre = nom; nom = null; return 1; } void set(String nom, int ed) { setNombre(nom); setNombre(nom); } En el primer mtodo, setNombre, se asigna la referencia que guarda la variable nom a nombre. A continuacin se asigna el valor null a nom, o sea una referencia nula. En el segundo mtodo, set, existen dos llamadas al primer mtodo , setNombre. La primera llamada asigna el valor original del parmetro nom. En la segunda llamada a la funcin setNombre, se vuelve a enviar la referencia guardada por nom, aunque se debe considerar si su valor ya ha cambiado. Dado que nom fue pasado por referencia, el null fue reasignado a la variable de nom dentro del mtodo set. Por lo tanto la segunda llamada a la funcin setNombre asigna un nom nulo, proveniente de esta reasignacin, a la variable nombre dentro del mtodo setNombre. Encapsulamiento En Java, como en la mayora de los lenguajes orientados a objetos, es muy importante considerar el encapsulamiento de los atributos y mtodos definidos en la clase. Aunque todos los campos de una clase son accesibles dentro de esa clase. Para ello, Java define tres modificadores bsicos para el manejo del encapsulamiento y que puede ser aplicados a los campos o miembros (atributos y mtodos) de una clase y a la propia clase completa: public, private y protected, como se muestra a continuacin: ? ? public - se agrega a los campos de la clase que pueden ser accesados fuera de la clase. En general, deben ser pblicos los mtodos de la clase, aunque no necesariamente todos sus mtodos. ? ? private - se agrega a los campos de la clase que son accesados nicamente desde dentro de la clase, o sea, dentro de sus propios mtodos. En general, deben ser privados los atributos de la clase, y posiblemente algunos mtodos de uso interno. ? ? protected - se agrega a los campos de la clase que son accesados nicamente desde dentro de la clase o dentro de una subclase que hereda de la actual, o sea, dentro de sus propios mtodos o mtodos de alguna de sus

Weitzenfeld: Captulo 5

15

subclase. En general, deben ser protegidos los atributos de la clase, y posiblemente algunos mtodos de uso interno. La distincin entre estos modificadores de encapsulamiento puede volverse un poco confusa dado que adems de afectar el encapsulamiento de los campos entre clases, tambin afecta la el acceso dependiendo si las clase son, o no, campos del mismo paquete. Por lo tanto, Java define dos maneras generales de aplicar estos modificadores, como se muestra a continuacin: ? ? Modificador de encapsulamiento para campo de una clase se aplica nicamente a un atributo o mtodo de una clase y puede consistir de cualquiera de los tres modificadores: public, private y protected. Este modificador se aade al inicio de una declaracin, sea atributo o mtodo, como se muestra a continuacin: class Persona { private String nombre; protected int edad; public int seguroSocial; public String licenciaConducir; private int setNombre(String nom) { nombre = nom; return 1; } protected int setEdad(int ed) { edad = ed; return 1; } public void set(String nom, int ed) { setNombre(nom); setEdad(ed); } public void set(int ed, String nom) { setNombre(nom); setEdad(ed); } ?? } Modificador de encapsulamiento para una clase se aplica a toda la clase como tal y puede consistir nicamente del modificador: public y afecta la visibilidad de la clase entre paquetes. Este modificador se aade al inicio de la especificacin de la clase, como se muestra a continuacin: public class Persona { private String nombre; protected int edad; public int seguroSocial; public String licenciaConducir; private int setNombre(String nom) { nombre = nom; return 1; } protected int setEdad(int ed) { edad = ed; return 1; } public void set(String nom, int ed) { setNombre(nom); setEdad(ed); } public void set(int ed, String nom) { setNombre(nom); setEdad(ed); } } En general, una vez la clase es pblica en otra paquete, entra en rigor la visibilidad de sus campos. La tabla 5.7 muestra los diferentes efectos de estos modificadores dependiendo de cuatro formas de accesar campos de una clase: dentro de la misma clase, dentro de una clase en el mismo paquete, dentro de una subclase en otro paquete, o dentro de una clase en otro paquete pero que no es una subclase de la actual. Se consideran cuatros niveles de encapsulamiento: public, protected y private para campos de clase y paquete, correspondiente a la visibilidad existente si se omite el modificador de sus campos. Esto ltimo resalta que no es obligatorio utilizar los modificadores de encapsulamiento. Sin embrago, su efecto no corresponde a ninguno de los tres casos como a menudo ocurre con otros lenguajes. Esto es debido principalmente a la existencia de paquetes. Encapsulamiento Es accesible por: public protected paquete private Misma clase s s s s Clase en el mismo paquete s s s no Subclase en un paquete diferente s s no no No-subclase en un paquete diferente s no no no Tabla 5.7 Modificadores de encapsulamiento y su efecto sobre las diversas estructuras.

Weitzenfeld: Captulo 5

16

La explicacin de la Tabla 5.7 es la siguiente: ? ? Todos los campos o miembros de una clase son siempre accesibles dentro de una misma clase, sin importar el modificador de sus campos. ? ? Todos los campos de una clase son siempre accesibles por cualquier otra clase, incluyendo subclases, dentro del mismo paquete, siempre y cuando el campo no sea private. ? ? Una subclase en un paquete distinto, slo puede accesar campos public o protected. Ntese que la clase debe ser public para poder ser vista en otro paquete. ? ? Una clase, que no sea subclase, en un paquete distinto, slo puede accesar campos public. Nuevamente la clase debe ser public para poder ser vista en otro paquete. Constructores Para completar los aspectos fundamentales de una clase se debe considerar sus constructores. Estos son mtodos especiales que pueden ser llamados nicamente durante la instanciacin de un nuevo objeto (esto ltimo lo veremos en la siguiente seccin.) El constructor lleva el mismo nombre de la clase y puede incluir parmetros. A diferencia del resto de los mtodos, un constructor no especifica ningn tipo de retorno, ya que de por s, el objeto recin creado es lo que se devuelve. Su formato es como se muestra a continuacin: class NombreClase { // atributos ...listaAtributos... // contructor NombreClase ( listaParmetrosConstructor1 ) { cuerpoConstructor1 } ... NombreClase ( listaParmetrosConstructori ) { cuerpoConstructori } ... NombreClase ( listaParmetrosConstructorN ) { cuerpoConstructorN } // operaciones ...listaMtodos... Pueden existir mltiples constructores, donde todos deben tener el mismo nombre que es idntico al nombre de la clase. Este es otro ejemplo de sobrecarga, en este caso del constructor de la clase. Como con los mtodos, no puede existir dos constructores con una lista de parmetros exactamente iguales. Como los mtodos, la lista de parmetros puede estar vaca. El constructor no es obligatorio en Java, ya que por omisin se generara uno con lista de parmetros vaca y un cuerpo vaco. A continuacin se muestra un ejemplo del uso de los constructores: class Persona { private String nombre; private int edad; private int seguroSocial; private String licenciaConducir; public Persona(String nom, int ed, int seg, String lic) { set(nom, ed); seguroSocial = seg; licenciaConducir = lic; } public int setNombre(String nom) { nombre = nom; return 1; } public int setEdad(int ed) { edad = ed; return 1; } public void set(String nom, int ed) { setNombre(nom); setEdad(ed); } public void set(int ed, String nom) { setNombre(nom); setEdad(ed); } } Ntese que cambiamos los modificadores de encapsulamiento de los atributos y mtodos para volverlos privados y pblicos, respectivamente. Ntese adems que los constructores tambin aceptan los modificadores de encapsulamiento de manera similar a los mtodos. Un constructor private nunca puede ser llamado (un ejemplo

Weitzenfeld: Captulo 5

17

de una clase que nunca podr ser instanciada) y un constructor protected slo puede ser instanciado por una subclase. En el ejemplo anterior, el constructor acepta valores de inicializacin para todos los atributos de la clase. A diferencia de los lenguajes como C++, Java no requiere un destructor, aunque si existen la funcin especial finalize que permite manejo avanzado de recoleccin de basura. Instanciacin Una vez definidos los aspectos esenciales de la clase, el siguiente paso es poder instanciar objetos. Java, para crear un nuevo objeto, se debe utilizar el operador new seguido por la clase a la que pertenece el objeto. Adems de la clase, puede haber una lista de argumentos opcionales entre parntesis, que son asignados y deben corresponder a la lista de parmetros de algn constructor de la clase. Si la clase no tiene un constructor, la lista deber estar vaca. Debe quedar muy claro que este operador permite instanciar un nuevo objeto, pero si no existe una variable que guarde la referencia al nuevo objeto, el objeto prcticamente ser perdido por ser imposible su acceso. Por lo tanto, antes de proceder con la instanciacin debe declararse una variable que guarde la referencia al nuevo objeto, como se muestra a continuacin: Persona p1 = new Persona(Juan,35,1234567,x254f); Esta instanciacin asigna los valores especificados a cada una de los atributos. En el caso de no haber especificado ningn constructor, Java permite instanciar un nuevo objeto utilizando la llamada a un constructor vaci generado implcitamente, como se muestra a continuacin: Persona p2 = new Persona(); Esta instanciacin crea un objeto tipo Persona donde los atributos toman como valor aquellos asignados por Java por omisin. Esta generacin implcita por parte de Java no ocurre si ya se ha definido al menos otro constructor para esa clase. En este ltimo caso, de no haber un constructor que no tome argumentos, la llamada anterior hubiese ocasionado un error. Como nota adicional, si se utilizara una sola variable para guardar la referencia a ambos objetos, la referencia del primera se perdera ya que la variable siempre guarda el ltimo valor asignado. Ms an, no es esencial que una variable explcitamente guarde la referencia a un objeto. Siempre cuando esa referencia est guardada y sea accesible, por ejemplo dentro de alguna lista o como parmetro de un mtodo, el objeto no ser eliminado por el recolector de basura. En cambio, si no existe ninguna forma de accesar al objeto, este ser automticamente borrado. Acceso a Campos Una vez instanciado un objeto, lo ms importante es poder accesar los campos de la clase los cuales ya han sido definidos previamente. Atributos Los atributos (tipos primitivos) son manipulados como se explic en la seccin correspondiente. Estas manipulaciones se hacen mediante expresiones tales como asignacin o flujos de control. Lo particular a considerar en los objetos es el acceso mediante la variable que guarda la referencia al objeto seguido por un . y el nombre del atributo. Por ejemplo, para asignar el nmero del seguroSocial del objeto p1 al valor 8888888, donde el objeto es de tipo Persona se hace lo siguiente: p1.seguroSocial = 8888888; Ntese que esta asignacin puede ser hecha si el atributo no es privado, ya que de lo contrario el encapsulamiento no lo permitira. Si esto ocurriese, que debiera ser la norma, el acceso se hara a travs de un acceso a un mtodo no privado del objeto, como veremos a continuacin. Mtodos Los mtodos son llamados a partir de la variable que guarda la referencia al objeto seguido por un . y el nombre del mtodo. Por ejemplo, para copiar el nmero del edad del objeto p1 al valor 25, donde el objeto es de tipo Persona se hace lo siguiente: p1.setEdad(25); Ntese que esta llamada al mtodo para la asignacin puede ser hecha si el mtodo no es privado, ya que de lo contrario el encapsulamiento no lo permitira. Referencia Propia Existe una palabra reservada, this, que es muy importante para referirse al objeto actual. Se utiliza de dos maneras distintas: como referencia a algn campo del objeto o cmo llamada a un constructor. Veamos los dos casos:

Weitzenfeld: Captulo 5

18

??

??

Como ejemplo de referencia a un campo de un objeto, el atributo edad puede ser accesado dentro del mtodo setEdad mediante el siguiente cdigo: protected int setEdad(int edad) { this.edad = edad; return 1; } Ntese como el this no cambia en absoluto la lgica original del mtodo, aunque evita un posible conflicto cuando un argumento del mtodo tiene el mismo nombre que el atributo de la clase. Obviamente, este posible conflicto se resuelve utilizando nombres diferentes. (Para Java esto no es un conflicto, ms bien pudiera ser base de confusin para el programador.) Sin embargo, el uso ms importante para esta referencia es como referencia a ser devuelta por un mtodo. Por ejemplo, modifiquemos el mtodo anterior, en particular el tipo devuelto, de la siguiente manera: protected Persona setEdad(int ed) { edad = ed; return this; } En este ejemplo, el this juega un papel primordial ya que permite que el mtodo devuelva la referencia del propio objeto para ser usado por otras variables. Obviamente, la referencia debe ser de tipo Persona para que el cdigo sea correcto. Como ejemplo de llamada a un constructor de un objeto, consideremos el siguiente constructor adicional para la clase Persona: public Persona() { this(null, 0, 0, null); } Este segundo constructor no tiene argumentos y se aprovecha del primer constructor para redirigir la llamada utilizando this(), en este caso con parmetros de omisin. En este ejemplo particular no es necesario hacer esta ltima llamada por asignar valores similares a los que asigna Java por omisin a las variables, sin embargo, esta es una buena prctica. Por otro lado, sera necesario incluir este llamada si quisiramos asignar valores de omisin diferentes a los que asigna Java. La llamada a this() debe utilizarse dentro de un constructor y debe aparecer como su primera lnea.

Expresiones para Objetos Las expresiones que se aplican a los objetos son ms bien limitadas en el sentido de que las manipulaciones principales en el control de un programa son sobre los tipos primitivos. Los objetos como tales se usan ms bien como encapsuladores de estos tipos primitivos y no tanto como la base de expresiones. Sin embargo existe algunos operadores que vale la pena mencionar aqu y que se muestra en la Tabla 5.8. Operador Descripcin de la Operacin (tipo) cast instanceof comparacin de tipo == igual (se refieren al mismo objeto) != no igual (se refieren a distintos objetos) Tabla 5.8 Operadores que pueden ser aplicados a objetos. Ntese la lista reducida de operadores en relacin a lista extensa de operadores aplicables a tipos primitivos. De esta lista vale la pena resaltar los siguientes aspectos: ? ? Los operadores == y != comparan referencias. Para comparar los propios valores a donde apuntan las referencias, se debe utilizar el mtodo equals(). ? ? El operador instanceof devuelve true si el objeto a la izquierda es una instancia de la clase especificada a la derecha, de lo contrario devuelve falso. Tiene la misma precedencia que los operadores de comparacin. Adems de esto, los objetos como tales son utilizados muy comnmente en expresiones que involucran funciones, donde las referencias a los objetos son sus argumentos. 5.2.4 Ligas, Asociaciones y Composicin Hasta ahora hemos mostrado como se definen las clases y como se crean los objetos. Para poder generar una aplicacin completa es necesario poder relacionar clases, o sea objetos, entre si. Esto corresponde a los conceptos de ligas y asociaciones entre objetos y clases, respectivamente. En la gran mayora de los lenguajes orientados a objetos no existe ninguno de estos dos conceptos. Por lo tantos estos deben ser implementados por algn mecanismo existente en el lenguaje. Tpicamente se describen asociaciones mediante la especificacin de referencias a otras clases, donde las referencias son guardadas como atributos de la clase. En general asociaciones de grados mayores a

Weitzenfeld: Captulo 5

19

dos se implementan mediante asociaciones binarias, por lo cual analizaremos stas ltimas. Consideremos la relacin entre las dos clases mostradas en el diagrama de la Figura 5.8.
Nombre de la Clase 1 Nombre de la Asociacin Nombre de la Clase 2

Figura 5.8 Asociacin entre clases. Una asociacin binaria es implementada mediante un atributo correspondiente a cada clase de la asociacin, como se muestra a continuacin: class Clase1 { Clase2 ref; } class Clase2 { Clase1 ref; } El mayor problema que existe con este tipo de implementacin para las asociaciones es mantener la consistencia entre las referencias. En otras palabras, si la asociacin, o liga, deja de existir, es importante que las referencias sean actualizadas de la manera correspondiente. Es importante que estos atributos de referencia no sean accesibles externamente para evitar actualizaciones de forma independiente. Por otro lado, los mtodos accesibles externamente para actualizar los atributos no deberan ser aadidos a una de las clases de la asociacin sin accesar la implementacin del otro objeto, ya que los atributos estn mutuamente restringidos. Cuando una nueva liga se aade a la asociacin, ambos apuntadores deben ser actualizados, y cuando la liga es removida, ambos apuntadores tambin deben ser tambin removidos. Este es un ejemplo de la complejidad que le agrega a un programa por la falta de un mecanismo que implemente asociaciones y ligas de manera natural. Rol En el cdigo de Java anterior no hay ningn indicio al concepto de la asociacin ms que las dos referencias mencionadas. Por lo tanto, aunque la asociacin tuviera un nombre, este nombre sera asignado a ninguno de las dos clases ya que el concepto como tal de la asociacin se ha perdido. Sin embargo, el nombre de rol, es ms fcil de asignar. Consideremos el diagrama de la Figura 5.9.
Nombre de la Clase 1 rol1 rol2 Nombre de la Clase 2

Figura 5.9 Asociacin entre clases con nombres de rol. Los nombres de rol pueden ser aprovechados para nombrar a los de las dos referencias, como se muestra a continuacin: class Clase1 { Clase2 rol2; } class Clase2 { Clase1 rol1; } Ntese que se utilizan los nombres de rol opuestos a la ubicacin del atributo de referencia. Acceso Analicemos ahora que ocurre si integramos el concepto del acceso o navegacin para las asociaciones apoyado por UML. El diagrama de la Figura 5.10 muestra una asociacin con navegacin bidireccional, que es equivalente al cdigo anterior. Ntese que se agrego el nombre de la asociacin, aunque esto no afecta al cdigo.
Nombre de la Clase 1 rol1 Nombre de la Asociacin rol2 Nombre de la Clase 2

Figura 5.10 Asociacin entre clases con nombres de rol y navegacin bidireccional. Simplifiquemos un poco la asociacin mediante la navegacin de una sola direccin, como se muestra en la Figura 5.11.

Weitzenfeld: Captulo 5

20

Nombre de la Clase 1

rol1

Nombre de la Asociacin

rol2

Nombre de la Clase 2

Figura 5.11 Asociacin entre clases con nombres de rol y navegacin en una sola direccin. Con este ltimo diagrama la navegacin es de la clase 2 a la clase 1 pero no viceversa. Por lo tanto la relacin puede implementarse mediante el siguiente cdigo simplificado: class Clase1 { } class Clase2 { Clase1 rol1; } Multiplicidad En todos los ejemplos anteriores la multiplicidad de la relacin fue de uno-uno. La multiplicidad de mucho agrega cierta complicacin ya que requiere de estructuras adicionales en lugar de la referencia directa. Consideremos el diagrama de la Figura 5.12.
Nombre de la Clase 1 rol1
1

rol2
*

Nombre de la Clase 2

Figura 5.12 Asociacin entre clases con nombres de rol y multiplicidad uno-muchos. El cdigo para el lado "muchos" requieren un conjunto de objetos, o un arreglo de referencias, como se muestra a continuacin: class Clase1 { Clase2 rol2[]; } class Clase2 { Clase1 rol1; } Obviamente, eventualmente se requiere instanciar los propios objetos, por lo cual, en el caso de un arreglo, el nmero mximo de posibles ligas debe ser conocido con anterioridad. Una opcin ms eficaz es utilizar estructuras de datos ms avanzadas, como un objeto contenedor Vector o algn otro ofrecido por Java o escrito por el programador que evite predefinir el nmero mximo de relaciones que pueden haber para una clase particular. El caso de multiplicidad muchos-muchos es simplemente una extensin del caso anterior. Consideremos el diagrama de la Figura 5.13.
Nombre de la Clase 1 rol1
*

rol2
*

Nombre de la Clase 2

Figura 5.13 Asociacin entre clases con nombres de rol y multiplicidad muchos-muchos. El cdigo para ambos lados de la asociacin requieren un conjunto de objetos, o un arreglo de referencias, como se muestra a continuacin: class Clase1 { Clase2 rol2[]; } class Clase2 { Clase1 rol1[]; } Asociacin Reflexiva Una asociacin reflexiva se implementa como caso especial de una asociacin entre clases distintas. Consideremos el diagrama de la Figura 5.14.

Weitzenfeld: Captulo 5

21

rol1 0..1

Nombre de la Clase * rol2

Figura 5.14 Asociacin reflexiva con nombres de rol y multiplicidad. El cdigo para ambos lados de la asociacin se muestra a continuacin: class Clase { Clase rol1; Clase rol2[]; } Ntese que las referencias son ahora a la misma clase. Por otro lado, la multiplicidad 0..1 se implementa como la de uno (realmente la multiplicidad es cierta forma de restriccin que debe ser asegurada mediante lgica adicional). Asociacin como Clase Como se describi en el Captulo 4, se pueden modelar las asociaciones como clases. Esto en cierta manera puede simplificar la implementacin de las asociaciones en especial el manejo de la consistencia entre las referencia de las clases. Aunque estos objetos no son difciles de implementar, siempre ayuda que la biblioteca de clases las contenga o al menos que contenga clases que ayuden a la implementacin final. El enfoque ms sencillo es implementar un objeto de asociacin como un objeto diccionario que hace un mapa entre la direccin hacia delante y la direccin hacia atrs de la asociacin. El diccionario debe ser actualizado cuando la asociacin es actualizada. Consideremos el diagrama de la Figura 5.15.
Nombre de la Clase 1 Nombre de la Clase 2

Nombre de la Asociacin

Figura 5.15 Asociacin como clase. El cdigo para ambos lados de la asociacin se muestra a continuacin: class Clase1 { Asociacion ref; } class Clase2 { Asociacion ref; } class Asociacion { Clase1 ref1[]; Clase2 ref2[]; } Ntese que las clases se refieren a la asociacin (diccionario), mientras que la asociacin es responsable de la consistencia en la informacin. Cualquier modificacin en la multiplicidad de la asociacin slo afecta a la clase asociacin. Adems la clase asociacin puede guardar atributos y operaciones particulares de la relacin que a su vez es especializada de una clase diccionario genrico. De tal manera, no hay necesidad de aadir atributos a las clases originales en la asociacin que realmente dependen de la asociacin. Si una pequea fraccin de los objetos participan en la asociacin, entonces objetos de asociacin separados aprovechan mejor el espacio que clases que incluyen todos los atributos relacionados con la asociacin y que de manera poco frecuente son utilizados. Composicin La composicin es bsicamente una extensin del concepto de asociacin. Dado que la asociacin no tiene ningn mecanismo que la soporte en Java, la composicin tampoco. Consideremos el diagrama de la Figura 5.16.
Nombre de la Clase 1 Nombre de la Composicin Nombre de la Clase 2

Figura 5.16 Composicin entre clases.

Weitzenfeld: Captulo 5

22

El cdigo para la composicin se muestra a continuacin: class Clase1 { Clase2 ref; } class Clase2 { Clase1 ref; } Como se puede ver, no hay diferencia de implementacin con la asociacin, y todas las consideraciones descritas en la seccin de ligas y asociaciones se aplica. Clases Contenedoras Las clases contenedoras son un buen ejemplo de clases que contienen a otras clases y que utilizan asociaciones y composicin como base. Dos de los ejemplos ms importantes de estas clases son la lista o lista ligada (LinkedList) y la pila (stack). Lista El siguiente diagrama muestra un diseo genrico para una lista que puede contener cualquier tipo de objeto, como se muestra en la Figura 5.17.
primero Lista Insertar Eliminar Nodo elemento Objeto

actual

prximo

0..1

Figura 5.17 Diagrama para una Lista Ligada. Se utilizan tres clases: ? ? Lista que agrupa las operaciones de insertar y eliminar los objetos contenidos a travs de un nmero indefinido de nodos. Se guarda la referencia al primero y al actual (corresponde al ltimo elemento). Se utiliza una relacin de composicin para resaltar que la lista contiene nodos. ? ? Nodo que son los contenedores para cada uno de los objetos. Cada nodo tiene una referencia al prximo o siguiente nodo (que puede ser nula), adems de una referencia al propio objeto. Es muy importante esta clase ya que ofrece la funcionalidad de liga entre nodos. ? ? Objeto que corresponde a la propia informacin que la lista guarda. Es importante separarla de los nodos para no requerir ninguna funcionalidad que no sea exclusiva al objeto, a diferencia del nodo que guarda funcionalidad propia de la lista. Aunque pudiesen utilizarse menos clases (tambin pudieran ser ms), este diseo es muy compacto evitando cualquier mezcal de la informacin con la lista, un requisito importante de una clase contenedora. Comenzamos la descripcin del cdigo a partir de la clase Nodo ya que la clase Objeto la representamos por la clase Object, la superclase de todas las clases en Java, como describiremos en mayor detalle en la seccin de herencia ms adelante. Esto ltimo facilita mucho el diseo y el manejo de las clases contenedoras. Ntese la correspondencia entre atributos y mtodos con el diagrama. Obviamente el cdigo tiene el detalle completo. class Nodo { private Nodo proximo; private Object elemento; public Nodo(Object elem) { setElemento(elem); } public void setElemento(Object elem) { elemento = elem; } public Object getElemento() { return elemento; } public void setProximo(Nodo prox) { proximo = prox; } public Nodo getProximo() { return proximo; } }

Weitzenfeld: Captulo 5

23

En el cdigo anterior, todos los atributos son privados, por lo cual se agregan mtodos get y set para consultar y modificar sus valores. Se tiene un slo constructor para inicializar el nodo con el elemento respectivo. Como debe ocurrir con cualquier clase contenedora, la lgica del modelo debe guardarse en el agregado, o sea la clase Lista: public class Lista { private Nodo primero; private Nodo actual; private Nodo getPrimero() { return primero; } private Nodo getActual() { return actual; } private Object getElemento() { if (actual != null) return actual.getElemento(); else return null; } public void insertar(Object elem) { Nodo tmp = new Nodo(elem); if (actual != null) { tmp.setProximo(actual.getProximo()); actual.setProximo(tmp); } if (primero == null) primero = tmp; actual = tmp; } public Object eliminar() { Nodo tmp = null; Object elem = null; if (primero != null) { tmp = primero.getProximo(); elem = primero.getElemento(); primero = tmp; } return elem; } } Nuevamente, ntese la correspondencia con el diagrama. Vale la pena resaltar ciertos aspectos del cdigo. No hubo necesidad de agregar un constructor ya que los atributos son inicializados por omisin a un valor nulo. Los tres mtodos get son privados, mientras que los nicos mtodos pblicos para la manipulacin de la lista son insertar y eliminar. Esto es importante para un buen manejo del encapsulamiento de la lista. Ms an, slo la clase Lista es pblica, mientras que Nodo es privada si se accesa desde otro paquete. En el ejemplo, se inserta elementos al final de la lista y se elimina del inicio de la lista. Un comentario adicional, es que esta lista slo inserta y elimina elementos. Su funcionalidad puede ser fcilmente extendida mediante operaciones, por ejemplo, para revisar o imprimir los elementos de la lista. Pila El siguiente diagrama muestra un diseo genrico para una pila que puede contener cualquier tipo de objeto, como se muestra en la Figura 5.18.
Pila Push Pop prximo 0..1 primero Nodo elemento Objeto

Figura 5.18 Diagrama para una Lista Ligada. Ntese la similitud con el diagrama de la Figura 5.17 para la lista. Se utilizan nuevamente tres clase:

Weitzenfeld: Captulo 5

24

??

Pila que agrupa las operaciones de push (meter) y pop (sacar) los objetos contenidos a travs de un nmero indefinido de nodos. Se guarda la referencia al primero nicamente. Se utiliza una relacin de composicin para resaltar que la pila contiene nodos. ? ? Nodo que son los contenedores para cada uno de los objetos. Cada nodo tiene una referencia al prximo o siguiente nodo (que puede ser nula), adems de una referencia al propio objeto. Es similar al nodo de la lista. ? ? Objeto que corresponde a la propia informacin que la pila guarda. En nuestro ejemplo de la pila reutilizaremos el diseo de la clase Nodo como se ver a continuacin. La clase Objeto es nuevamente implementada por la clase Object, la superclase a todas las clases en Java. class Nodo { private Nodo proximo; private Object elemento; public Nodo(Object elem) { setElemento(elem); } public void setElemento(Object elem) { elemento = elem; } public Object getElemento() { return elemento; } public void setProximo(Nodo prox) { proximo = prox; } public Nodo getProximo() { return proximo; } } En cdigo anterior es exactamente igual al Nodo para el ejemplo de la lista. Todos los atributos son privados, por lo cual se agregan mtodos get y set para consultar y modificar sus valores. Se tiene un slo constructor para inicializar el nodo con el elemento respectivo. Como debe ocurrir con cualquier clase contenedora, la lgica del modelo debe guardarse en el agregado, o sea la clase Pila: public class Pila { private Nodo primero; public void push(Object elem) { Nodo tmp = new Nodo(elem); if (primero != null) tmp.setProximo(primero); primero = tmp; } public Object pop() { Nodo tmp; Object elem; if (primero != null) { elem = primero.getElemento(); tmp = primero; primero = tmp.getProximo(); return elem; } return null; } } Nuevamente, ntese la correspondencia con el diagrama. Vale la pena resaltar ciertos aspectos del cdigo. No hubo necesidad de agregar un constructor ya que los atributos son inicializados por omisin a un valor nulo. El cdigo de la clase Pila es ms sencillo que el de la clase Lista. Se omitieron los mtodos get, mientras que los nicos mtodos pblicos para la manipulacin de la lista son push y pop. Esto es importante para un buen manejo del encapsulamiento de la pila. Y de manera similar al ejemplo de la lista, slo la clase Pila es pblica, mientras que Nodo es privada si se accesa desde otro paquete.

Weitzenfeld: Captulo 5

25

5.2.6 Generalizacin y Herencia La herencia es un aspecto fundamental de Java y de los lenguajes orientados a objetos. Tomemos el diagrama de herencia (sencilla) que se muestra en la Figura 5.19.
Superclase

Subclase1

Subclase2

Figura 5.19 Herencia de clases. En la figura se muestra una superclase de la cual heredan dos subclase. La herencia es codificada utilizando la palabra extends como se muestra a continuacin: class Superclase { } class Subclase1 extends Superclase { } class Subclase2 extends Superclase { } Un comentario general sobre el esquema de herencia en Java es que de no ser especificada una superclase, Java genera implcitamente una herencia a la clase Object. De tal manera Object es la superclase, directa o indirectamente, de todo el resto de las clase en una aplicacin. De tal forma, la clase Object es la nica que no tiene una superclase. Consideremos el siguiente ejemplo particular de uso de herencia como se muestra en el diagrama de la Figura 5.20.
Persona nombre : Cadena edad : Entero seguroSocial : Entero licenciaConducir : Cadena setNombre(String nombre) : Entero setEdad(int edad) : Entero set(String nombre, int edad) set(int edad, String nombre)

Trabajador empresa : Cadena salario : Entero setEmpresa(String empresa) : Entero setSalario(int salario) : Entero set(String empresa, int salario) set(int salario, String empresa)

Figura 5.20 Herencia de Persona a Trabajador. El cdigo para la herencia entre Persona y Trabajador se muestra a continuacin. El cdigo para la clase Persona es ligeramente modificado para que sus atributos sean protected en lugar de private, de tal manera que la clase Trabajador pueda luego utilizarlos: class Persona { protected String nombre; protected int edad; protected int seguroSocial; protected String licenciaConducir; public Persona(String nom, int ed, int seg, String lic) { set(nom, ed); seguroSocial = seg; licenciaConducir = lic; }

Weitzenfeld: Captulo 5

26

public Persona() { Persona(null, 0, 0, null); } public int setNombre(String nom) { nombre = nom; return 1; } public int setEdad(int ed) { edad = ed; return 1; } public void set(String nom, int ed) { setNombre(nom); setEdad(ed); } public void set(int ed, String nom) { setNombre(nom); setEdad(ed); } } El cdigo para la clase Trabajador se muestra a continuacin: class Trabajador extends Persona { private String empresa; private int salario; public Trabajador(String emp, int sal) { empresa = emp; salario = sal; } public Trabajador() { this(null,0); } public int setEmpresa String emp) { empresa = emp; return 1; } public int setSalario(int sal) { salario = sal; return 1; } public void set(String emp, int sal) setEmpresa(emp); setSalario(sal); public void set(int sal, String emp) setEmpresa(emp); setSalario(sal);

{ } { }

} Ntese la similitud entre ambas clases, aunque Trabajador en este caso hereda de Persona. La instanciacin de un objeto de tipo Trabajador es similar a la que se hizo anteriormente para Persona, aunque obviamente cambiando el nombre de la clase. A continuacin hacemos dos instanciaciones como ejemplo: Trabajador t1 = new Trabajador (); Trabajador t2 = new Trabajador (IBM,35000); Hay un pequeo detalle que vamos a remediar en la siguiente seccin: no se est asignando ningn valor a los atributos de Persona cuando se instancia un nuevo objeto. En otras palabras, se le asigna valores a los atributos de Trabajador pero no a los de su superclase Persona. Existe un modificador especial, final, que si se agrega de prefijo en la primera lnea de la definicin de una clase, hace que la clase no pueda ser heredada por otras. Referencia a la Superclase Existe en Java una palabra reservada llamada super que es algo similar en su uso al this descrito anteriormente. La palabra super se utiliza de dos maneras distintas: como referencia a algn campo de la superclase del objeto o cmo llamada a un constructor de la superclase. Veamos los dos casos: ? ? Como ejemplo de referencia a un campo de la superclase, consideremos que se define un segundo atributo edad dentro de la clase Trabajador: class Trabajador extends Persona { ... private int edad; ... } Para poder accesar el atributo de la superclase agregamos un nuevo mtodo setSuperEdad dentro de la clase Trabajador de la siguiente forma: private int setSuperEdad(int edad) { super.edad = edad; return 1; }

Weitzenfeld: Captulo 5

27

??

Ntese que el mtodo setEdad de la clase Persona modificara el atributo edad de la clase Trabajador. Este es un ejemplo del gran cuidado que se debe tener cuando se usa herencia. Ntese que es ilegal especificar super.super.edad. Como ejemplo de llamada a un constructor de la superclase, consideremos el siguiente constructor adicional para la clase Trabajador que incluye parmetros para inicializar valores en los atributos heredados de Persona: public Trabajador (String emp, int sal, String nom, int ed, int seg, String lic) { super(nom, ed, seg, lic); set(emp, sal); } Un nuevo objeto de tipo Trabajador utilizando el constructor anterior sera el siguiente:. Trabajador t3 = new Trabajador (IBM,35000,Juan,35,1234567,x254f); Este segundo constructor agrega argumentos para los atributos de ambas clase y se aprovecha del constructor de la superclase para redirigir la llamada utilizando super(). De manera anloga a this(), existe la restriccin de que super() slo puede utilizarse dentro de un constructor y debe aparecer como su primera lnea. Dada la restriccin de ambas llamados, no es posible combinarlas dentro de un mismo constructor. Por omisin, Java siempre llama al constructor vaco de la superclase, por lo cual este debe existir de manera explcita si existen otros constructores en la superclase, o en el caso de no haber constructores, Java genera uno de manera implcita para la superclase. La nica excepcin que hace Java de no llamar a super() de manera implcita es cuando ya existe una llamada a this() en el constructor.

Sobrescritura y Polimorfismo En los ejemplos de las secciones anteriores ya se han mostrado algunos casos de sobrescritura de atributos y mtodos. A continuacin describimos estos casos con mayor detalle. Atributos La sobrescritura de atributos (shadowed) corresponde a dos atributos, uno definido en la superclase y otro en la subclase, ambos con el mismo nombre. Esto es til si desea utilizar en la subclase la misma variable definida con un tipo diferente y tambin es til cuando stas son inicializadas con valores distintos. En nuestros ejemplos anteriores se dio el caso de la sobrescritura del atributo edad en la clase Trabajador con respecto a la ya definida en la clase Persona. En este caso no hay distincin ni de tipo ni de valor de inicializacin entre ambas. Para distinguir entre ambos atributos es necesario utilizar this.edad o super.edad para referirse a la edad definida en Trabajador o en Persona, respectivamente. Esto se aplica nicamente si el objeto donde se encuentra las llamadas fue instanciado como Trabajador (realmente no importa si las llamadas estn dentro de un mtodo que pertenece a la superclase o a la subclase). Por ejemplo, el siguiente cdigo para un objeto de tipo Trabajador corresponde al caso this.edad donde se accesa la edad del Trabajador a pesar de que el mtodo seEdad est definido dentro de la clase Persona: private int setEdad(int ed) { edad = ed; return 1; } Si el objeto fue instanciado de la clase Persona, la situacin de sobrescritura ya no existe. Otra forma de distinguir entre los dos atributos es mediante un cast utilizando this: ((Trabajador)this).edad o ((Persona)this).edad, donde el atributo se refiere a la clase correspondiente al cast. Mtodos La sobrescritura de es la base del polimorfismo es los lenguajes orientados a objetos. La sobrescritura se base en definir mtodos con la misma firma exacta en la superclase al igual que la subclase (anloga al uso de virtual en C++). En los ejemplos de la clase Trabajador y la clase Persona se sobrescribi el mtodo set como se puede ver a continuacin. La clase Persona inclua los dos siguiente mtodos set: class Persona { ... public void set(String nom, int ed) { setNombre(nom); setEdad(ed); } public void set(int ed, String nom) { setNombre(nom); setEdad(ed); } } La clase Trabajador inclua los dos siguiente mtodos set:

Weitzenfeld: Captulo 5

28

class Trabajador extends Persona { ... public void set(String emp, int sal) { setEmpresa(emp); setSalario(sal); } public void set(int sal, String emp) { setEmpresa(emp); setSalario(sal); } } La sobrescritura de los mtodos anteriores se puede apreciar mejor con el siguiente ejemplo: Trabajador t4 = new Trabajador (); t4.set(Perez,50); A cul mtodo set se llama, al de Persona o al de Trabajador? La respuesta es que se llama al mtodo set que sobrescribe al de su superclase, por lo tanto es el de Trabajador. El que los argumentos tengan nombres diferentes no afecta, nicamente afectan sus tipos. (Cmo comentario adicional, es un error tener dos mtodos con firmas similares, sea en la misma o en la superclase, pero con tipos de retorno diferente.) El ejemplo anterior no es demasiado descriptivo para poder apreciar el poder de la sobrescritura y del polimorfismo. Consideremos el siguiente ejemplo que consiste de las clases que se muestran en el diagrama de la Figura 5.21.
FormaGrfica Desplegar()

Texto Desplegar()

Lnea Desplegar()

Figura 5.21 Ejemplo de polimorfismo. A continuacin definimos los aspectos esenciales de estas clases. public class FormaGrafica { ... public void desplegar(int x, int y) { } ... } public class Texto extends FormaGrafica { ... public void desplegar(int x, int y) { desplegarTexto(); } ... } public class Linea extends FormaGrafica { ... public void desplegar(int x, int y) { desplegarLinea(); } ... } Sin entrar en detalles y omitiendo otros, las tres clases definen el mtodo desplegar con exactamente la misma firma, aunque la superclase la tiene vaca mientras que las dos subclases, Texto y Lnea, solicitan desplegarTexto y desplegarLinea, respectivamente. Ahora, aprovechemos la lista que definimos anteriormente y escribamos el siguiente cdigo un mtodo desplegarVentana de alguna otra clase: public void desplegarVentana (Lista l) { ... FormaGrafica fg; while ((fg = (FormaGrafica)l.eliminar()) != null) { fg.desplegar(); }

Weitzenfeld: Captulo 5

29

El mtodo desplegarVentana tiene como argumento una Lista l que para nuestro ejemplo suponemos que esta llena, donde anteriormente se la insertado un nmero de objetos de tipo Texto o Lnea. Como simple ejercicio, iremos eliminando cada uno de estos objetos de la lista (dentro del while) y si el objeto resultante no es nulo, lo desplegaremos. Lo interesante del ejercicio es que la variable fg fue declarada del tipo de la superclase que tiene el mtodo desplegar a ser sobrescrito, sin en ningn momento mencionar en este mtodo el tipo de las dos subclases, Texto y Linea. Sin embargo, el despliegue es correcto ya que Java reconoce dinmicamente el tipo verdadero (no el declarado por fg que simplemente guarda la referencia al objeto) del objeto en la lista y hace el llamado de acuerdo a la sobrescritura correspondiente. Esto significa que si en un futuro definimos nuevas subclases de FormaGrafica y sobrescribimos de manera adecuada el mtodo desplegar, el mtodo desplegarVentana no tendr que ser modificado para el manejo adecuado de la nueva clase. Esto es extensibilidad al mximo, el cdigo nuevo no afecta en absoluto al cdigo viejo. Cuando se logra manejar y aprovechar adecuadamente el polimorfismo, se puede uno considerar que domina la programacin orientada a objetos. Como ejercicio mental, consideremos que ocurrira si el lenguaje no apoyara el polimorfismo, o sea, la sobrescritura de mtodos. Dentro del mtodo desplegarVentana tendramos que revisar el tipo verdadero de cada objeto al que se refiere fg, posiblemente mediante mltiples expresiones if else que permitan conocer su tipo y hacer la llamada adecuada de manera explcita. Esto sera muy tedioso y requerira de modificaciones constantes para adecuarse a nuevas subclases. Vale la pena destacar, como se vio en los ejercicios de las secciones anteriores, que se puede invocar un mtodo sobrescrito por medio de la referencia super seguido por el nombre del mtodo. Como comentario final a esta seccin, mtodos que tengan el modificador final en su definicin en la superclase, no pueden ser sobrescritos. Ms an, todos los mtodos de una clase con el prefijo final tambin se consideran final. Adems de no poder ser sobrescritos, los mtodos final son ms eficientes ya que no participan en la sobrescritura que es un proceso dinmico de bsqueda en Java como en la mayora de los dems lenguajes orientados a objetos. Clases Abstractas Las clases abstractas son un aspecto bsico de la generalizacin dado que definen clases que requieren subclases para poder utilizarse. De manera bsica, se puede definir una clase como abstracta mediante el modificador abstract. Una clase definida de esta manera no puede ser instanciada, requiriendo una subclase para poder ser utilizada. Una clase abstracta se define de la siguiente manera: abstract class NombreClase Por ejemplo, podramos modificar la definicin de la clase FormaGrafica para volverla una clase abstracta que no pudiera instanciarse. public abstract class FormaGrafica { ... public void desplegar(int x, int y) { } ... } Fuera de esta restriccin de no poder ser instanciada directamente, una clase abstracta puede contener atributos y mtodos como cualquier otra clase normal (concreta). Mtodos Abstractos La utilizacin del modificador abstract, como se mostr en la seccin anterior, define una clase como abstracta. Adems de esto, se pueden definir mtodos abstractos, utilizando el modificador abstract en los propios. El uso sera por ejemplo el siguiente: public abstract class FormaGrafica { ... public abstract void desplegar(int x, int y); ... } Si el mtodo desplegar de la clase FormaGrafica de los ejemplos anteriores fuera definido de esta forma, cualquier clase que herede de FormaGrafica debera forzosamente sobrescribir el mtodo desplegar. Efectivamente, cualquier clase con un mtodo abstracto, automticamente se vuelve una clase abstracta, la cual no puede ser instanciada. Ntese que es obligatorio que la clase se defina como abstracta si esta incluye algn mtodo

Weitzenfeld: Captulo 5

30

abstracto. El opuesto no es obligatorio. Tambin ntese que al volverse el mtodo abstracta, se elimina su implementacin (que anteriormente estaba vaca). Como se puede apreciar del ejemplo anterior, un mtodo abstracto no tiene cuerpo, solo una firma. Todas las subclases que hereden de esta clase tienen que sobrescribir los mtodos abstractos definidos en la superclase, si no la subclase se considerara tambin abstracta. (Esto es similar a una funcin en C++ igualada a 0 en su definicin, por ejemplo, void func()=0.) Interfaces Como alternativa a la definicin de clases y mtodos abstractos, Java ofrece otra estructura que la interface. Las interfaces son similares a clases abstractas, excepto que se utiliza la palabra interface en lugar de abstract y class. Una interface se define de la siguiente manera: public interface NombreInterface { ...listaMtodos... } Una interface slo permite definir mtodos pero no atributos. Estos mtodos son implcitamente abstractos y no pueden contener una implementacin dentro de la interface. (Al igual que una clase, una interface puede incluso estar completamente vaca.) La nica otra estructura que puede definirse dentro de la interface es una constante esttica (static final) un tema que trataremos en la siguiente seccin. Consideremos la modificacin de la clase FormaGrafica para volverse una interface: public interface FormaGrafica { ... public void desplegar(int x, int y); ... } Ntese que ya no se utiliza el modificador abstract dentro de la declaracin del mtodo desplegar. Como habra que modificar a las clases Texto y Linea para poder utilizar FormaGrafica si esta se vuelve una interface? La respuesta es que en lugar de utilizar la palabra extends ahora se debe usar la palabra implements. Por lo tanto, la nueva definicin de Texto y Linea sera la siguiente: public class Texto implements FormaGrafica { ... public void desplegar(int x, int y) { desplegarTexto(); } ... } public class Linea implements FormaGrafica { ... public void desplegar(int x, int y) { desplegarLinea(); } ... } A diferencia de que se permite un slo extends para la herencia de clases en Java (o sea herencia sencilla), Java permite utilizar mltiples implements dentro de una clase. Por ejemplo, consideremos la siguiente interface: public interface FormaEscalable { ... public void escalar(double s); ... } Esta interface define el mtodo escalar que permite a un objeto grfico cambiar su tamao. Las clases Texto y Linea se podran modificar de la siguiente forma: public class Texto implements FormaGrafica, FormaEscalable { ... public void desplegar(int x, int y) { desplegarTexto(); } public void escalar(double s) { ... } ... } public class Linea implements FormaGrafica, FormaEscalable { ... public void desplegar(int x, int y) {

Weitzenfeld: Captulo 5

31

desplegarLinea(); } public void escalar(double s) { ... } ... } De tal forma, una clase puede implementar cualquier nmero de interfaces. Tambin es posible que una clase herede de su superclase mediante el extends y a la vez implemente a su interface mediante el implements, donde el nmero de interfaces implementadas no tiene lmite. Por ejemplo, volvamos a la definicin original de la clase FormaGrafica: public class FormaGrafica { ... public void desplegar(int x, int y); ... } Las clases Texto y Linea se podran modificar de la siguiente forma: public class Texto extends FormaGrafica implements FormaEscalable { ... public void desplegar(int x, int y) { desplegarTexto(); } public void escalar(double s) { ... } ... } public class Linea extends FormaGrafica implements FormaEscalable { ... public void desplegar(int x, int y) { desplegarLinea(); } public void escalar(double s) { ... } ... } Las clases Texto y Linea pueden efectivamente considerarse una instancia de ambos tipos FormaGrafica y FormaEscalable. De manera anloga a que las clases pueden extenderse de manera jerrquica a travs de subclases, las interfaces pueden extenderse en subinterfaces. Una subinterface hereda todos los mtodos abstractos y constantes estticas de la superinterface, y puede definir nuevos mtodos abstractos y constantes estticas. Una interface puede extender ms de una interface a la vez. Por ejemplo consideremos la siguiente interface que permite rotar objetos grficos: public interface FormaRotable { ... public void rotar(double r); ... } Ahora definamos una nueva interface FormaTransformable que extiende a FormaEscalable y FormaRotable: public interface FormaTransformable extends FormaEscalable, FormaRotable {} Las clases Texto y Linea se podran modificar de la siguiente forma: public class Texto extends FormaGrafica implements FormaTransformable { ... public void desplegar(int x, int y) { desplegarTexto(); } public void escalar(double s) { ... } public void rotar(double r) { ... } ... } public class Linea extends FormaGrafica implements FormaTransformable { ... public void desplegar(int x, int y) { desplegarLinea(); } public void escalar(double s) { ... } public void rotar(double r) { ... } ... }

Weitzenfeld: Captulo 5

32

Este manejo de jerarquas de interfaces permite consolidar mltiples interfaces en una para ser luego implementadas a travs de una sola interface. Herencia Mltiple El tema de la herencia mltiple es uno de los aspectos ms complejos en los lenguajes de programacin orientados a objetos. Esta complejidad radica en las dificultades de implementacin por parte de los compiladores de estos lenguajes. Los distintos lenguajes toman diferentes enfoques con respecto a la herencia mltiple. Como se discuti inicialmente en el captulo 4, existe una problemtica de heredar atributos y mtodos similares de distintas superclases, ocasionando el problema de resolver cuales de estos se va a utilizar. Por ejemplo, consideremos el diagrama de la Figura 5.22 donde las Transformable, Escalable y Rotable se vuelven clases en lugar de interfaces por lo cual aceptan atributos e implementacin de mtodos.
Escalable inicio : int desplegar() escalar() Rotable inicio : double desplegar() rotar()

Transformable transformar()

Figura 5.22 Ejemplo de herencia mltiple. Ahora definamos el mtodo transformar para la clase Transformable: public void transformar() { inicio = 4.5; desplegar(); } A cual atributo se refiere inicio, al de la clase Escalable que es un int, o al de la clase Rotable que es un double. Adems, a cual desplegar se llama, al definido en la clase Escalable o al definido en la clase Rotable. Esta es la base de la complejidad que ocasiona la herencia mltiple y que requiere de mecanismos adicionales, que pueden ser bastante complejos, para ser resueltos por un lenguaje de programacin. Por lo tanto, los distintos lenguajes toman diversos enfoques. Por ejemplo, C++ apoya la herencia mltiple aunque con ciertas dificultes para el usuario (tales como conflictos con el manejo de apuntadores y referencias especiales para resolver la herencia de atributos y mtodos), mientras que Smalltalk directamente no apoya la herencia mltiple. Por otro lado, Java toma un enfoque muy original de herencia mltiple restringida. Java, como hemos visto, permite herencia sencilla de clases pero implementacin de mltiple interfaces. Si nos olvidamos de la nomenclatura especial por un momento, o sea, interface e implements, estas estructuras son simplemente clases sin atributos ni implementacin de mtodos. Lo que estas estructuras ofrecen es una solucin a la herencia mltiple pero sin los conflictos de herencia de mltiples atributos e implementacin de mtodos de mltiples superclases. En otras palabras, Java elimina la complejidad de herencia mltiple pero an ofreciendo un mecanismo similar. En general, como muchos lenguajes de programacin orientados a objetos, tales como Java, 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

Weitzenfeld: Captulo 5

33

??

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.

5.2.7 Entidades Estticas Existe en Java el concepto de estructuras estticas de clases. A diferencia de los atributos (atributos de instancia o atributo de objeto) y mtodos (mtodos de instancia o mtodo de objeto) descritos anteriormente, los cuales requieren de un objeto instanciado de la clase que los define para poder ser utilizados, los atributos estticos (atributos de clase) y mtodos estticos (mtodos de clases) no requieren de la existencia de los objetos y pueden ser utilizados directamente a partir de las clases que los definen. Ntese que un objeto siempre puede accesar a sus campos de clase (estticos), mientras que los campos estticos no pueden accesar los campo del objeto. Los campos estticos pueden recibir todos los modificadores aplicables a los no estticos, incluso se aplican las mismas operaciones. Para ello se utiliza la palabra static que convierte un atributo o un mtodo en esttico, como veremos a continuacin. Ntese, que ni los atributos ni los mtodos estticos pueden ser sobrescritos. Atributos Los atributos estticos o atributos de clase se distinguen del atributos de objeto en que se tiene una sola copia para todos los objetos de una clase. Por ejemplo, consideremos el siguiente atributo esttico: class Persona { public static String nacionalidad; ... } Definamos el siguiente mtodo (fuera de la clase Persona) que muestra el manejo de los atributos estticos: public void print () { Persona.nacionalidad = mexicano; ... } Como se puede ver, el acceso de la variable nacionalidad es por medio de la clase y no por medio de un objeto. Es importante resaltar que todos los objetos instanciados de la clase Persona tienen acceso a una sola copia de nacionalidad, por lo cual cualquier cambio a su valor afectara a todos estos objetos. Los atributos de clase se inicializan cuando la clase se carga por primera vez, a diferencia de las variables de instancia que se inicializan solo cuando se instancian nuevos objetos. Como se mencion antes, los atributos estticos aceptan todos los modificadores que los atributos normales. Por lo tanto, se pueden definir atributos estticos constantes utilizando el static final. Este tipo de constantes, que como todos los atributos, es declarado dentro de la definicin de clase, es equivalente al ? define en C y C++. El compilador de Java utiliza el valor asignado a la constante para calcular inicialmente otras constantes de tiempo de compilacin, algo que no se puede hacer con constantes no estticas. Adems, el static final, tambin puede ser utilizado en el caso de compilacin condicional. Por ejemplo: public static final boolean DEBUG = false; puede ser utilizado en secciones if para que se compilen o no. Mtodos Los mtodos de clase se declaran tambin con static y se invocan con el nombre de la clase de manera similar a los atributos de clase. (Estos mtodos no pueden pasar el this como referencia ya que pueden existir sin que se hayan instanciado objetos. Por ejemplo, la siguiente es una declaracin de un mtodo esttico: class Persona { public static String nacionalidad; public static String getNacionalidad() { return nacionalidad; ... }

Weitzenfeld: Captulo 5

34

Ntese que los mtodos estticos tienen acceso a los atributos estticos dentro de una misma clase. Modifiquemos el mtodo print descrito en la seccin anterior que muestra el manejo de los mtodos estticos: public void print () { Persona.getNacionalidad(); ... } Nuevamente, el acceso es mediante el nombre de la clase. Muchas de las bibliotecas de Java aprovechan los mtodos estticos para definir funciones que no requieren instanciacin de objetos para utilizarse. Por ejemplo, todos los mtodos de la clase System son mtodos de clase, tales como System.out.print(), al igual que los mtodos de la clase Math, que funciona como una biblioteca de funciones ms que como instancias de objetos. Existe un mtodo esttico extremadamente importante, main, que indica el inicio de la aplicacin, como explicaremos en la seccin de aplicaciones y applets. Inicializador Para mantener el mximo posible de similitud con el manejo de clases normales, existe un inicializador, anlogo al constructor, que permite inicializar los aspectos estticos de la clase (no de las instancias). No tiene argumentos ya que automticamente se carga cuando la clase se carga. Un inicializador esttico de clase tiene el siguiente formato: static { ... } A diferencia de los constructores, no tiene nombre ni se pasan argumentos. Java permite mltiples bloques estticos como el anterior, los cuales se llaman todos al cargar la clase. Una de las aplicaciones es cargar mtodos nativos de la mquina virtual, tpicamente en C. 5.2.8 Meta Clases Existe en Java el concepto de meta clases, o sea clases de clases. Si un objeto es la instancia de una clase, entonces la propia clase es la instancia de una meta clase. Este concepto se muestra en el diagrama de la Figura 5.23.
Meta Clase <<instanceOf>> Clase <<instanceOf>> Objeto

Figura 5.23 Concepto de meta clase. El concepto de meta clase es extremadamente til, en particular el hecho de poder tratar a una clase como si fuera un objeto. Por ejemplo, la Figura 5.24 muestra las relaciones anteriores adaptadas por Java, donde Class corresponde a la meta clase y la relacin est dada con cualquier Clase y Objeto definido por el programador.
Class <<instanceOf>> Clase <<instanceOf>> Objeto

Figura 5.24 Concepto de meta clase en Java. Por ejemplo, veamos el siguiente cdigo: Class miclase = Class.forName(nombre_clase); Object miobjeto = miclase.newInstance(); En la primera lnea se traduce el nombre_clase (definido como String) a una clase miclase. Ntese que esta variable se refiere a una clase manipulada como objeto! En la segunda lnea se instancia miobjeto a partir de miclase. Ntese que este proceso se puede aplicar a cualquier clase en Java dada que la instanciacin es efectuada de manera totalmente annima, todo gracias a la manipulacin de la clase como si fuese un objeto. De hecho este es un ejemplo tambin de polimorfismo (a travs del mtodo newInstance). 5.2.9 Aspectos Adicionales En esta seccin describimos algunos aspectos adicionales que se pueden considerar bsicos en el lenguaje de Java. Archivos En Java es relativamente sencillo accesar archivos. Veamos el siguiente cdigo en Java: File file = new File(dir,archivo); BufferedReader is = new BufferedReader(new FileReader(file)); String s = is.readLine(); ... is.close();

Weitzenfeld: Captulo 5

35

Se instancia un archivo file de tipo File especificando su ubicacin en el sistema, dir, y su nombre, archivo. A continuacin se instancia un objeto de tipo FileReader el cual se conecta al archivo file y luego, en la misma lnea, se instancia el objeto is de tipo BufferedReader que permite conectarse a travs de un bfer de lectura. La llamada is.readLine() hace una lectura de una lnea completa y la guarda en una variable s de tipo String. Luego de terminar de leer la informacin deseada del archivo, ste se cierra mediante la llamada is.close(). La escritura es anloga a la lectura, como se muestra a continuacin: BufferedWriter os = new BufferedWriter(new FileWriter(file)); os.write(s); ... os.close(); Se instancia un archivo file, como se mostr anteriormente. A continuacin se instancia un objeto de tipo FileWriter el cual se conecta al archivo file y luego, en la misma lnea, se instancia el objeto os de tipo BufferedWriter que permite conectarse a travs de un bfer de escritura. La llamada os.write(s) hace una escritura de una cadena referida por la variable s de tipo String. Luego de terminar de escribir la informacin deseada en el archivo, ste se cierra mediante la llamada os.close(). Bases de Datos Mostramos a continuacin el manejo bsico para acceder una base de datos en Java. Lo primero que generalmente se hace es checar que exista el paquete de Java que permite administrar la conexin a las bases de datos, como se muestra a continuacin: Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver"); La propia conexin a la base de datos se hace a travs de una llamada similar a la siguiente: Connection con = DriverManager.getConnection("jdbc:odbc:nombre",log,pass); Lo anterior genera una conexin a una base de datos llamada nombre que puede accesarse opcionalmente a travs de un nombre de usuario log y una contrasea pass. Esta conexin queda abierta hasta que se cierre mediante la siguiente llamada: con.close(); Luego de esto se debe instanciar una variable de tipo Statement la cual es utilizada como contenedor de la llamada en SQL: Statement stmt = con.createStatement(); Por ejemplo, si se quisiera hacer una consulta a una tabla con un nombre de usuario log, se generara inicialmente una cadena query para guardar la llamada de SQL para luego ejecutarse mediante la llamada stmt.executeQuery(query) como se muestra a continuacin: String query = "SELECT * FROM tabla WHERE (login = 'log')"; ResultSet rs = stmt.executeQuery(query); Esta llamada regresa un resultado rs de tipo ResultSet. De este resultado se obtiene la estructura de la tabla, o sea su meta dato, incluyendo el nmero de columnas, para luego poder leer de manera correcta sus propios datos, como se muestra a continuacin: ResultSetMetaData rsmd = rs.getMetaData(); int numCols = rsmd.getColumnCount(); while (rs.next()) { for (int i = 1; i <= numCols; i++) String str = rs.getString(i); ... } La propia lectura, en el caso de una cadena, se hace mediante la llamada rs.getString(i), donde i identifica la columna de la tabla a partir del valor 1. Mientras rs.next() no sea nulo esto significa que existen resultados adicionales para seguir leyndose. A diferencia de la consulta, las inserciones o actualizaciones de las tablas se hacen utilizando la llamada stmt.executeUpdate(update) como se muestra a continuacin: String update = "INSERT INTO tabla ..."; int n = stmt.executeUpdate(update); Ntese que la llamada stmt.executeUpdate(update) regresa ahora un entero correspondiente al nmero de rcords que fueron insertados o modificados exitosamente. El formato de las inserciones y actualizaciones corresponden a las especificaciones de SQL y no sern tratadas aqu en ms detalle.

Weitzenfeld: Captulo 5

36

Manejo de excepciones Un aspecto de suma importancia y que es integral en los lenguajes como en Java, es el manejo de excepciones. Cuando un error ocurre en un programa, el sistema lanza una excepcin que puede ser atrapada por el programa. Considerando que los errores se generan por diversas razones, incluso por razones externas a una aplicacin, como al accesar el sistema operativo, es esencial que el programador tenga un manejo efectivo. Esto se hace en Java a travs de las tres palabras reservadas: ? ? try define un bloque de cdigo donde pudieran ocurrir excepciones. ? ? catch define una seccin para el manejo de las excepciones (a travs de la clase Throwable o alguna de sus subclases). Este bloque es opcional. ? ? finally - cdigo a ejecutarse como finalizacin del bloque, ocurran o no excepciones. Este bloque es opcional. Por ejemplo, veamos el siguiente caso para la lectura de un archivo: try { BufferedReader is = new BufferedReader(new FileReader(file)); leerArchivo(is); is.close(); } catch(IOException e) { System.out.print("Error Lectura Registro: " + e); System.exit(1); } finally { System.out.print("Lectura Archivo: " + file); } El bloque try abre la conexin al archivo de lectura file, como se describi anteriormente. En este bloque agregamos una llamada al mtodo que hace la lectura, leerArchivo (este mtodo se muestra ms adelante). El bloque catch hace el manejo de la posible excepcin, IOException, la cual debe ser pasada como argumento nico dentro del bloque. En este ejemplo, se imprime el tipo de excepcin y se sale del programa. El bloque finally siempre se ejecuta al finalizar los anteriores (a menos que se salga de la aplicacin). En este ejemplo se imprime la informacin general del archivo del cual se est leyendo. Java requiere que las excepciones que no son normales (tpicamente las que provienen de la interaccin con el sistema operativo) deben ser manejadas mediante la palabra throws en la definicin del mtodo afectado. Por ejemplo, el acceso a archivos puede ocasionar una excepcin de entrada/salida que no es considerada normal por Java. Tal error se da cuando, por ejemplo, el archivo no existe o se trata de leer de un archivo vaco. Ntese como se debe definir un mtodo como leerArchivo: public void leerRegistros(BufferedReader is) throws IOException { String s = is.readLine(); ... } Por suerte Java sabe cuales excepciones no son normales avisando al programador que debe incluirlas en la definicin del mtodo afectado. La excepcin IOException que se incluye con el throws debe tambin aparecer en el catch del try correspondiente, sino un error de compilacin ocurrira. El manejo de excepciones es requerido para cualquier cdigo que trate de acceder situaciones peligrosas, en particular es obligatorio cuando se trate de acceder elementos externos al programa, como son los archivos y las bases de datos. Modificadores Adicionales Existen algunos modificadores adicionales que vale la pena mencionar: ? ? native es un modificador que se puede aplicar a las declaraciones de los mtodos y que significa que el mtodo est implementado de manera nativa en C o alguna otra plataforma pero no en Java. Como un mtodo abstracto, se agrega un punto y coma al final de su declaracin. ? ? synchronized es un modificador que especifica una seccin critica que no puede ser interrumpida en aplicaciones que usan mltiples hilos (threads) de control. Puede ser utilizado para mtodos de instancia (objetos) o mtodos de clase.

Weitzenfeld: Captulo 5

37

?? ??

transient es un modificador que puede ser aplicado a campos de instancia de una clase que indica que un campo no es parte del estado persistente del objeto y por lo tanto no tiene que ser serializado con el objeto en tales situaciones. volatile es un modificador que se puede aplicar a todos los campos y especifica que el campo es usado por hilos sincronizados y que por lo tanto el compilador no lo optimizar en su manejo, al contrario del resto de los campos.

Finalizador Finalmente describimos un mtodo de finalizacin de clase llamado finalize. Anlogo al constructor que inicializa el objeto, el finalizador lo finaliza. Esto no est relacionado con la recoleccin de basura, sino con otros aspectos, como cerrar archivos o sockets abiertos. Un finalizador se vera de la siguiente forma: protected void finalize() throws IOException { if (fd != null) close(); } Java nunca llama a un finalizador ms de una vez para un mismo objeto. El mtodo finalizador se llama por lo general antes de la recoleccin de basura. Sin embargo, Java no garantiza el orden en que ocurran estos, por lo cual puede que no se llame la recoleccin de basura o el finalizador. Cualquier recurso adicional an no recolectado sera liberado al terminar el programa. Inclusive, los objetos pueden resucitarse guardando una referencia al propio objeto (this) desde el finalizador. 5.2.10 Aplicaciones y Applets Existen dos maneras de estructurar un programa en Java: aplicaciones o applets. Ambos siguen el mismo proceso de desarrollo con Java incluyendo la gran mayora de las facilidades que Java ofrece. La diferencia es que las aplicaciones se ejecutan como cualquier programa normal mientras que los applets estn especficamente diseados para correr en el Web a travs de un browser. Aplicaciones Las aplicaciones utilizan un mtodo especial para iniciar el programa: el mtodo main. La aplicacin ms sencilla es la famosa Hola Mundo la cual se programara de la siguiente manera como una aplicacin en Java:. class ej { public static void main(String args[]) { System.out.println(Hola Mundo!); } } Al ejecutar el programa escribira Hola Mundo. El mtodo main debe aparecer en toda aplicacin y realmente no afecta a que clase se le asigne el mtodo, ya que este no tiene acceso a las estructuras internas de la clase, adems de ser accesado slo internamente por Java. Por ejemplo, public class Persona { public static void main(String args[]) { for (int i = 0; i < args.length; i++) System.out.print(args[i] + ); System.out.print(\n); System.exit(0); } } Ntese el argumento args de main que recuerdan cierta similitud a argc y argv, slo que integrndolos en un slo. Applets Tomamos ahora el programa anterior de Hola Mundo el cual se programara de la siguiente manera como un applet en Java:. public class ej extends Applet { public void paint(Graphics g){ g.drawString(Hola Mundo!,25,25); } }

Weitzenfeld: Captulo 5

38

En lugar del mtodo main, un applet requiere una clase que herede de Applet y que sobrescriba el mtodo paint para poder desplegar textos o grficas en la pantalla. (En la siguiente seccin extenderemos ms sobre el tema de interfaces grficas.) Todo applet requiere de una pgina html para su ejecucin. La pgina html, por ejemplo ej.html, que va a desplegar el applet requerira de la siguiente lnea para poder ejecutarse correctamente: <applet code=ej.class width=200 height=200></applet> El archivo html puede ejecutarse en un browser o mediante la aplicacin appletviewer de la siguiente forma: appletviewer ej.html A diferencia del mtodo main, el paso de argumentos iniciales es a travs de parmetros del archivo html. 5.3 Interfaces Grficas de Usuario Programar en Java sin utilizar Interfaces Grficas de Usuario (GUI por sus siglas en ingls) es no aprovechar uno de los aspectos ms importantes que ofrece la programacin y en particular Java. Comenzamos describiendo despliegues grficos sencillos para luego explicar el manejo de ventanas, textos, botones y paneles en Java a travs de la biblioteca AWT. 5.3.1 Despliegues Grficos Antes (GUI por sus siglas en ingls) es no aprovechar uno de los aspectos ms importantes que ofrece la programacin y en particular Java. Ocho Reinas El siguiente ejercicio se conoce como el juego de las ocho reinas y es muy interesante porque es un ejemplo de lo compacto que puede ser un programa, en especial aquellos que utilizan mucho la recursividad, como es el caso con este ejercicio. El problema tiene origen en el ajedrez, donde una reina puede atacar a cualquier otra pieza que quede en la misma fila, en la misma columna o en una diagonal. El problema de las ocho reinas consiste simplemente en colocar ocho reinas en un tablero de ajedrez, en forma tal que ninguna reina pueda atacar a ninguna otra reina. En la Figura 5.25 se muestra un ejemplo de como se vera un tablero de tal manera. La solucin no es la nica y depende de las condiciones de inicio.
Q Q Q Q Q Q Q Q

Figure 5.25 Problema de las Ocho Reinas. La esencia de la solucin orientada a objetos, propuesta aqu, consiste en crear las reinas y otorgarles ciertos poderes para que ellas mismas puedan descubrir la solucin. Para lograr esta solucin, la primera observacin que hay que hacer es que en ninguna de las soluciones pueden quedar dos reinas en la misma columna y, en consecuencia, ninguna columna puede estar vaca. Por lo tanto, se puede asignar inicialmente una columna para cada reina, y reducir as el problema para dar a cada reina la tarea de encontrar una fila apropiada. Se tiene una solucin al acertijo de las ocho reinas cuando todas las reinas guardan cierta relacin entre s. De esta manera, est claro que las reinas necesitan comunicarse. Dado esto, se puede hacer una segunda observacin. Cada reina necesita enviar mensajes slo a una de sus vecinas. En forma ms precisa, cada reina necesita saber slo acerca de la reina que est inmediatamente a su izquierda. As, los datos para cada reina constan de tres valores: un valor de columna, que es inmutable (se establece una vez y nunca se altera); un valor de fila, que se altera en la bsqueda de la solucin, y la reina vecina a su izquierda inmediata. Se define una solucin aceptable para una columna i como la configuracin de las columnas 1 hasta i-1 en la cual ninguna reina puede atacar a otra reina en tales columnas. A cada reina se le encargar que encuentre soluciones aceptables entre ella y su vecina a la izquierda. Se encuentra una solucin al acertijo en su conjunto pidiendo a la reina del extremo derecho que descubra una solucin aceptable. El diagrama de clases para la clase Reina se muestra en la Figura 5.26.

Weitzenfeld: Captulo 5

39

Reina fila columna vecina primero siguiente puedeAtacar pruebaOAvanza

Figure 5.26 Clase Reina para el problema de las Ocho Reinas. Los atributos y mtodos son los siguientes: ? ? fila - nmero de fila actual (cambia) ? ? columna - nmero de columna (fija) ? ? vecina - vecina de la izquierda (fija) ? ? primera - inicia fila, luego encuentra la primera solucin aceptable para s misma y vecinas ? ? siguiente - avanza fila y encuentra la siguiente solucin aceptable ? ? puedeAtacar - ve si una posicin puede ser atacada por s misma o por vecinas ? ? pruebaOAvanza - comparte cdigo comn para la verificacin de posicin. La estructura del cdigo en Java es la siguiente (sin especificar ni los argumentos ni la implementacin de los mtodos): class Reina { private int columna, fila; private Reina vecina; public Reina () { public boolean primera() { ... } private boolean puedeAtacar() { ... } private boolean pruebaOAvanza() { ... } private boolean siguiente() { ... } } Empecemos por lo ms general hasta terminar con lo ms detallado tratando de seguir la lgica lo ms ordenado posible, algo que se complica dada la recursividad. Para ello definimos un mtodo main: public static void main (String args[]){ Reina ultimaReina = null; for (int i=1; i<= 8; i++) ultimaReina = new Reina(i, ultimaReina); if ((ultimaReina != null) && ultimaReina.primera()) ultimaReina.imprime(); } Se tiene un ciclo for donde se instancia una nueva reina y se la asigna a una columna particular junto con la referencia de su vecina a la izquierda correspondiente a la ltima reina instanciada. Una vez se hayan ubicado las ocho reinas en sus columnas correspondientes, con sus referencias entre si, se inicializa el algoritmo mediante ultimaReina.primera(). La ltima lnea del main imprime el resultado final. En cuestin de mtodos, el primero que se requiere es el constructor que ubica a las reinas en su columna particular, aunque fuera del tablero (fila 0), junto a sus referencias, como se puede ver a continuacin: public Reina (int c, Reina r ) { columna=c; fila=0; vecina=r; } Luego se ejecuta primera el cual inicializa a todas las reinas a la fila 1 de manera recursiva comenzando desde la ltima instanciada. Gracias a la recursin, llegamos de ida hacia la izquierda hasta la primera reina, la de la columna 1, donde paramos ya que esta no tiene vecina a la izquierda. Una vez que se llega al extremos izquierdo comenzamos a avanzar de regreso hacia la derecha, una reina a la vez, haciendo la prueba, pruebaOAvanza, para cada reina para ver si esta tiene conflictos con el resto de sus vecinas a la izquierda. Este mtodo se muestra a continuacin: public boolean primera() { fila = 1; if (vecina != null) {

Weitzenfeld: Captulo 5

40

if (vecina.primera()) return pruebaOAvanza(); } return true; } El siguiente mtodo en la lgica es pruebaOAvanza el cual verifica si una reina puede atacar a su vecina a la izquierda, mediante el mtodo puedeAtacar. En caso de que si la pueda atacar, la reina debe avanzar a la siguiente fila donde la prueba se volver a realizar. Este mtodo se describe a continuacin: private boolean pruebaOAvanza() { if (vecina != null) { if (vecina.puedeAtacar(fila,columna)) return siguiente(); } return true; } El procedimiento puedeAtacar compara la posicin de la fila de la reina actual con su vecina a la izquierda, empleando el hecho de que, para un movimiento en diagonal, las diferencias en las filas deben ser iguales a las diferencias en las columnas. Como el algoritmo es recursivo, cada reina debe compararse tambin con todo el resto de las reinas hasta el extremo izquierdo, algo que se hace mediante el puedeAtacar interno. El mtodo se describe a continuacin: private boolean puedeAtacar(int f, int c) { int dc; dc=columna-c; if (f==fila) return true; if ( (fila+dc==f) || (fila-dc==f)) return true; if (vecina !=null) return vecina.puedeAtacar(f,c); return false; } Tras encontrar una solucin para las primeras columnas, la reina trata cada fila en orden, empezando con la fila 1, por medio del procedimiento puedeAtacar. Resulta una de dos cosas: se encuentra una solucin aceptable o la reina intenta todas las posiciones sin encontrar una solucin. En el ltimo caso, la reina pide a su vecina que encuentre otra solucin aceptable, y la reina empieza de nuevo a probar valores de fila potenciales. Cuando se pide a una reina que encuentre otra solucin, esta simplemente incrementa su nmero de fila y verifica con sus vecinas, suponiendo que no se encuentre ya en la ltima fila. Si ya est en la ltima fila, la reina no tiene ms remedio que pedir a su vecina una nueva solucin y empezar la bsqueda una vez ms desde la primera fila. Esto se implementa mediante el mtodo siguiente: private boolean siguiente() { if (fila==8) { if (vecina != null) { if (! vecina.siguiente()) return false; fila=0; } } fila++; return pruebaOAvanza(); } Aunque no lo crea el algoritmo ha sido resuelto. Slo nos falta imprimir el resultado, lo cual se hace con el siguiente mtodo: public void imprime() { if (vecina != null) vecina.imprime(); System.out.println("Reina: "+ columna + " "+ fila); } La impresin del resultado final sera:

Weitzenfeld: Captulo 5

41

Reina: 1 1 Reina: 2 5 Reina: 3 8 Reina: 4 6 Reina: 5 3 Reina: 6 7 Reina: 7 2 Reina: 8 4 Esta salida no es demasiado amigable por lo cual agreguemos un pequeo despliegue grfico y corramos el programa como una Applet. Para tal objetivo, definimos un mtodo despliega, similar en lgica a imprime: public void despliega (Graphics g){ if (vecina != null) vecina.despliega (g); g.setColor(Color.gray); g.fillOval(((fila - 1) * 50)+10, ((columna - 1) * 50)+10, 25, 25); } Definimos una nueva clase ReinaApplet que herede del Applet (no queremos mltiples applets). A esta clase le asignamos un mtodo init anlogo al main, y otro mtodo paint que despliegue el resultado final, el tablero ms las reinas. Esto se hace de la siguiente manera: public class ReinaApplet extends Applet { private Reina ultimaReina; public void init (){ ultimaReina = null; for (int i = 1; i <= 8; i++) ultimaReina = new Reina (i, ultimaReina); } public void paint (Graphics g) { for (int i = 0; i < 8; i+=2) for (int j = 0; j < 8; j+=2) { g.fillRect(50 * (j+1), 50 * i, 50, 50); g.fillRect(50 * j, 50 * (i+1), 50, 50); } if ((ultimaReina != null) && ultimaReina.primera ()) ultimaReina.despliega (g); } } El resultado final grfico es el que se muestra en la Figura 5.27.

Weitzenfeld: Captulo 5

42

Figura 5.27 Applet con despliegue final para el problema de las ocho reinas. Domin Presentamos en esta seccin un ejemplo de juego del domin. Este juego consiste de 28 fichas de las cuales 7 son entregadas inicialmente a cada jugador. Cada jugador tratar de ubicar una de sus fichas en el tablero de manera que uno de sus valores coincida con alguno de los dos valores en los extremos del tablero. El turno pasa de jugador en jugador hasta que alguno de los dos jugadores agote sus fichas o que ninguno de los dos pueda continuar. El ganador ser aquel que termine sus fichas o que tenga un menor puntaje al finaliza el juego. En el caso de no poder ubicar ninguna de sus fichas, el jugador en turno deber obtener una nueva ficha del montn de fichas sobrantes. Si an no es posible ubicar esta nueva ficha se deber obtener otra adicional hasta poder ubicarla en el tablero, o hasta agotar el montn (la sopa) en cuyo caso pasar el turno al siguiente jugador. El objetivo de este ejercicio es implementar en Java un programa que simule el juego de Domin entre 2 jugadores. El programa deber contener de manera general las clases, atributos y mtodos, descritos en la Figura 5.28.
Domino tablero : ListaFicha monton : ListaFicha todas : ListaFicha jugador1 : Jugador jugador2 : Jugador repartirFichas() inicializarJuego() finalizarJuego() imprimirTablero()

monton

todas *

tablero

Ficha valor1 : int valor2 : int

Jugador nombre : String puntajeFinal : int fichas : ListaFicha ponerFicha() obtenerFicha() imprimirPuntaje()

Figura 5.28 Diagrama de clase para el juego del Domin. Los detalles de este ejercicio lo dejamos al lector que los desarrolle. Sin embargo mostramos grficamente la salida del programa durante su ejecucin. La obtencin e inicializacin de fichas deber ser aleatoria. El inicio, con las piezas repartidas, se muestra en la Figura 5.29.

Weitzenfeld: Captulo 5

43

Figura 5.29 Pantalla del juego del Domin durante el inicio. Cada jugador puede ubicar de manera arbitraria sus fichas en el caso de tener mltiples opciones para hacerlo, como se muestra en la Figura 5.30.

Figura 5.30 Pantalla del juego del Domin durante su desarrollo. El juego se acaba cuando ya no hay ms fichas para ubicar, como se muestra en la Figura 5.31.

Weitzenfeld: Captulo 5

44

Figura 5.31 Pantalla del juego del Domin al final. 5.3.2 Ventanas, Textos, Botones y Paneles En esta seccin introducimos rpidamente el diseo de GUIs en Java mediante la biblioteca AWT, la primera biblioteca grfica de Java como parte de Java 1, y que tiene la gran ventaja de que, a diferencia de la biblioteca Swing y en general Java 2, esta biblioteca corre en la actualidad en todos los browsers, incluso los de Microsoft, sin necesidad de un plug-in especial. El ejemplo a desarrollarse en esta seccin es muy importante ya que servir de base para prototipos posteriores en el libro. Todo sistema de ventanas requiere alguna ventana donde desplegar la informacin. Existen dos filosofa separadas aunque relacionadas en Java que afectarn el diseo como ya hemos mencionado anteriormente: aplicaciones y applets. Las aplicaciones requieren de un Frame (marco) donde desplegar y permitir la interaccin con el usuario, mientras que un applet puede directamente hacer esto en la pantalla del browser o mediante nuevos marcos de manera similar a las aplicaciones. Empecemos por lo ms bsico y mostremos el uso de los marcos a travs de la siguiente clase InterfaceUsuario: class InterfaceUsuario extends Frame Esta clase heredar todas las caractersticas de un marco para manejarse como una ventana. Antes de proseguir, es necesario comprender que toda aplicacin con ventanas requiere un manejo de eventos de entradas y salidas. Esto significa que la aplicacin antes de hacer nada debe de alguna manera especificar como controlar eventos generados por el teclado y en especial el ratn. Java define dos interfaces muy importantes en AWT que son WindowListener y ActionListener, donde WindowListener define los mtodos relacionados con el manejo de eventos para una ventana, como abrir y cerrar, mientras que ActionListener define los mtodos para manejar eventos dentro de la ventana, como apretar un botn. De tal manera, es necesario que la clase InterfaceUsuario implemente estas dos interfaces si se tiene planeado manejar estos tipos de eventos. Por lo tanto, extendemos la definicin de la clase InterfaceUsuario de la siguiente manera: class InterfaceUsuario extends Frame implements WindowListener, ActionListener Dado que las interfaces deben tener su mtodos sobrescritos, hagamos esto con los siguiente mtodos de WindowListener inicialmente: public void windowClosed(WindowEvent event) {} public void windowDeiconified(WindowEvent event) {} public void windowIconified(WindowEvent event) {} public void windowActivated(WindowEvent event) {} public void windowDeactivated(WindowEvent event) {} public void windowOpened(WindowEvent event) {} public void windowClosing(WindowEvent event) {

Weitzenfeld: Captulo 5

45

System.exit(0); } Estos son todos los mtodos definidos por la interface WindowListener: ? ? windowClosed para el manejo de eventos a partir de una ventana cerrada. ? ? windowDeiconified para el manejo de eventos a partir de una ventana no iconificada. ? ? windowIconified para el manejo de eventos a partir de una ventana iconificada. ? ? windowActivated para el manejo de eventos a partir de una ventana activada. ? ? windowDeactivated para el manejo de eventos a partir de una ventana desactivada. ? ? windowOpened para el manejo de eventos a partir de una ventana abierta. ? ? windowClosing para el manejo de eventos en el momento que se cierra una ventana. Todos estos mtodos deben sobrescribirse aunque queden vacos, como es el caso con la mayora de los anteriores para nuestro ejemplo. El nico que realmente hemos sobrescrito es windowClosing para permitir salir de la aplicacin cuando este evento ocurra.. (Existen alternativas para sobrescribir nicamente los mtodos deseados utilizando adaptadores en lugar de interfaces, algo que no mostraremos en este libro.) La sobrescritura de la interface ActionListener es mucho ms importante para las ventanas, ya que a travs del mtodo actionPerformed se debe especificar que hacer cuando, por ejemplo, se presiona algn botn dentro de la ventana. El siguiente mtodo muestra la sobrescritura de actionPerformed, imprimiendo el evento ocurrido public void actionPerformed(ActionEvent event) { System.out.println("Action: "+event.getActionCommand()); } Esta es la lgica bsica del manejo de eventos para un marco. Para completar la funcionalidad necesitamos inicializar la clase InterfaceUsuario y definir alguna pantalla para desplegar. Para ello definimos el siguiente constructor: public InterfaceUsuario() { setSize(800,600); setBackground(Color.lightGray); addWindowListener(this); pantalla = new PantallaPrincipal(this); desplegarPantalla(pantalla); } Describamos las llamadas dentro de este constructor, las cuales son la mayora opcionales: ? ? setSize define el tamao del marco. ? ? setBackground asigna un color de fondo de manera opcional. ? ? addWindowListener registra el marco (this) con el administrador de ventanas de Java para que podamos manejar los eventos. Este mtodo es necesario. ? ? PantallaPrincipal instancia la pantalla a ser desplegada, algo que veremos a continuacin. Ntese que la variable pantalla la definimos como un atributo de la clase InterfaceUsuario, private Pantalla pantalla;, algo que explicaremos tambin ms adelante junto con la clase Pantalla. ? ? desplegarPantalla despliega la pantalla recin instanciada. Antes de mostrar los detalles de PantallaPrincipal, veamos como desplegaramos una pantalla mediante el mtodo show definido por la clase Frame: protected void desplegarPantalla(Pantalla p) { show(); } Ntese que no estamos utilizando el argumento de tipo Pantalla an. Esto lo remediaremos en un momento para cuando dejemos ms clara la lgica que utilizaremos mediante la explicacin de la clase PantallaPrincipal. Antes de hacer eso mostremos el mtodo main para instanciar la clase InterfaceUsuario: public static void main(String[] args) { System.out.println("Starting System..."); InterfaceUsuario iu = new InterfaceUsuario(); } Si quisiramos instanciar el marco bajo control de un applet, algo que tambin es aceptable, definiramos la siguiente clase InterfaceUsuarioApplet que hereda de la clase Applet y sobrescribiendo el mtodo init, en lugar del mtodo main: public class InterfaceUsuarioApplet extends Applet {

Weitzenfeld: Captulo 5

46

public void init() { showStatus("Starting System..."); InterfaceUsuario iu = new InterfaceUsuario(); } } Otro comentario es que definiremos las gran mayora de los mtodos como protected dado que son accesados dentro de un mismo paquete. Slo los mtodos sobrescritos de las interfaces deben definirse como pblicos. Tambin definiremos los constructores como pblicos aunque algunos pudieran tambin definirse como protected si son los objetos instanciados dentro del mismo paquete. y los constructores deben Como ejemplo vamos a crear un PantallaPrincipal que genere el despliegue que se muestra en la Figura 5.32.

Figura 5.32 Ejemplo de marco desplegando PantallaPrincipal. Para simplificar el diseo de una de estas pantallas, es posible dividirlas en secciones lgicas llamadas paneles que visualmente no afectan la presentacin de la pantalla, pero son una buena gua para el diseador. En nuestro caso dividiremos la pantalla en paneles horizontales que contengan los diversos elementos de la pantalla, o sea, textos y botones. Dado que por lo general se desean desplegar mltiples pantallas, definamos una superclase Pantalla, como algunos de los lectores ya se habrn imaginado, de la siguiente manera: class Pantalla { protected InterfaceUsuario interfaceUsuario; protected Panel panel; protected Button boton; protected Vector paneles,botones; } Lo primero que haremos dentro de esta clase es definir un atributo de tipo InterfaceUsuario, el cual guardar la informacin sobre el la clase encargada de administrar el despliegue. Los tributos de tipo Panel y Button para que sirvan para referencias en cualquiera de las subclases de Pantalla. El aspecto ms importante para esta clase es que definiremos dos arreglos de tamao dinmico, mediante la clase Vector, para guardar la lista de todos los paneles y botones que sean instanciados en las diversas pantallas, ya que estos requieren un manejo especial, y los arreglos facilitarn su manipulacin como veremos ms adelante. Definimos el contructor para la clase Pantalla de manera que reciba una referencia a guardarse de la clase InterfaceUsuario. public Pantalla (InterfaceUsuario ui) { interfaceUsuario ui;

Weitzenfeld: Captulo 5

47

inicializarPantalla(); crearPantalla(); } Adicionalmente, este constructor inicializar la pantalla mediante la llamada crearPantalla, la cual est sobrescrita por las pantallas particulares. En la superclase, el mtodo se puede definir como abstracto y protegido. protected abstract void crearPantalla (); Este mtodo es el corazn de la lgica de despliegue. Antes de ello se reinicializan los vectores para los paneles y botones que estn definidos por el mtodo inicializarPantalla. protected void inicializarPantalla() { paneles = new Vector(); botones = new Vector(); } Definamos ahora la clase PantallaPrincipal como subclase de Pantalla: class PantallaPrincipal extends Pantalla El constructor de PantallaPrincipal llamar al constructor de la superclase mediante la llamada super, a la cual pasar el parmetro ui de tipo InterfaceUsuario. public PantallaPrincipal (InterfaceUsuario ui) { super(ui); } El diseo de las pantallas ser utilizando paneles, o sea secciones de la pantalla. Esto se guardara dentro del mtodo crearPantalla, en este caso de la clase PantallaPrincipal, correspondiente a la Figura 5.30. Esta clase no tiene que ser pblica ya que se llama dentro del constructor de la superclase. Dado que existe una sobrescritura del mtodo, este debe definirse como protegido. protected void crearPantalla () El primer panel contiene el ttulo de la pantalla, como se muestra a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(2,1)); panel.add(new Label("SISTEMA DE RESERVACIONES DE VUELO", Label.CENTER)); panel.add(new Label("Pantalla Principal (P-1)", Label.CENTER)); paneles.addElement(panel); Luego de instanciar el objeto de tipo Panel, se le asigna a este un administrador para lo organizacin interna del panel, por ejemplo GridLayout que define en este caso una cuadrcula de 2x1. Luego aadimos los elementos del panel, en este caso un ttulo (Label) que corresponde a un texto que no es modificable el cual es centrado dentro de la cuadrcula. Una vez completado el panel, lo agregamos a la lista de paneles. El siguiente panel contiene 4 filas y una sola columna, donde vamos a insertar cuatro lenas de texto como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(4,1)); panel.add(new Label("Servicios Ofrecidos:", Label.CENTER)); panel.add(new Label("* Consulta de Vuelos, Tarifas y Horarios", Label.CENTER)); panel.add(new Label("* Reserva de Vuelos", Label.CENTER)); panel.add(new Label("* Compra de Boletos", Label.CENTER)); paneles.addElement(panel); Nuevamente agregamos el panel a la lista de paneles. El siguiente panel es similar al primero y agrega una etiqueta, como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(1,1)); panel.add(new Label("Para registrarse por primera vez oprima:", Label.CENTER)); paneles.addElement(panel); En el siguiente panel hacemos algo diferente. Instanciamos un botn (Button), al cual le ponemos como etiqueta "Registrarse por Primera Vez", como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(1,1)); boton = new Button ("Registrarse por Primera Vez"); botones.addElement(boton);

Weitzenfeld: Captulo 5

48

panel.add(boton); paneles.addElement(panel); Adems de agregar el panel a la lista de paneles, agregamos el botn a la lista de botones. El siguiente panel es similar al primero y agrega una etiqueta, como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(1,1)); panel.add(new Label("Para accesar todos los servicios de vuelo (consulta, reserva, compra) o modificar su registro, oprima:", Label.CENTER)); paneles.addElement(panel); En el siguiente panel tambin hace algo diferente. Instanciamos un campo de texto (TextField), adems de agregarle una etiqueta Login:, como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(1,1)); panel.add(new Label("Login:", Label.LEFT)); panel.add(new TextField (20)); paneles.addElement(panel); En el siguiente panel instanciamos un campo de texto adicional (TextField), que adems de agregarle una etiqueta Password:, como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(1,1)); panel.add(new Label("Password:")); panel.add(new TextField(20)); paneles.addElement(panel); En el ltimo panel instanciamos dos botones adicionales, OK y Salir, como se ve a continuacin: panel = new Panel(); panel.setLayout(new GridLayout(1,1)); boton = new Button("OK"); botones.addElement(boton); panel.add(boton); boton = new Button("Salir"); botones.addElement(boton); panel.add(boton); paneles.addElement(panel); Ahora viene la gran pregunta: cmo hacemos para desplegar todo esto y manejar de manera adecuada los eventos relacioandos? Para ello regresamos al mtodo desplegarPantalla inicialmente definido para la clase InterfaceUsuario y le agregamos algunas lneas adicionales antes del show, como se ve a continuacin: protected void desplegarPantalla(Pantalla p) { if (pantalla != null) pantalla.borrarPantalla(); if (p != null) pantalla = p; if (pantalla != null) pantalla.desplegarPantalla(); show(); } Dado que estamos en proceso de desplegar una nueva pantalla, lo primero que tenemos que hacer es borrar la anterior, tanto paneles como registro de botones. Ntese que se guarda en p la nueva ventana mientras que debemos borrar la pantalla anterior. Eso lo hacemos a travs del mtodo borrarPantalla dentro de la clase Pantalla, algo que describiremos en un momento. Utilizamos siempre un if para asegurar que no existan valores nulos. Luego de borrar la pantalla actual, cambiamos el valor del atributo pantalla al de la nueva pantalla la cual ser desplegada mediante el mtodo desplegarPantalla. El mtodo borrarPantalla se muestra a continuacin, el cual puede definirse como protegido por ser llamado dentro del mismo paquete: protected void borrarPantalla() { interfaceUsuario.removeAll(); int bs = botones.size(); for (int i = 0; i < bs; i++) if ((boton = (Button)botones.elementAt(i)) != null) boton.removeActionListener(interfaceUsuario);

Weitzenfeld: Captulo 5

49

} El mtodo removeAll borra todo lo que hay en la pantalla, mientras que removeActionListener borra el registro para manejo de eventos de los botones de la pantalla anterior. El despliegue de la pantalla se hace mediante el mtodo desplegarPantalla perteneciente a la clase Pantalla, como se ve a continuacin: protected void desplegarPantalla() { System.out.println("Desplegando: "+ this); int ps = paneles.size(); interfaceUsuario.setLayout(new GridLayout(ps,1)); for (int i = 0; i < ps; i++) interfaceUsuario.add((Panel)paneles.elementAt(i)); int bs = botones.size(); for (int i = 0; i < bs; i++) if ((boton = (Button)botones.elementAt(i)) != null) boton.addActionListener(interfaceUsuario); } Se obtiene el nmero de paneles, ps, de la lista de paneles, para el cual se le solicita a la interfaceUsuario que organice la pantalla en una cuadrcula mediante GridLayout, que conste en un nmero de filas ps y una sola columna. De tal manera se agrega a la interfaceUsuario, cada uno de los paneles mediante la llamada interfaceUsuario.add. Con esto es suficiente para desplegar los paneles junto con todos los campos definidos para cada uno de ellos anteriormente, en el momento se ejecuta la llamada show. Sin embargo, falta algo importante, registrar los botones con el manejador de eventos. Para hacer esto obtenemos el nmero de botones bs. Luego, obtenemos cada uno de ellos de la lista y lo registramos con el sistema mediante la llamada boton.addActionListener. De tal manera ya podemos desplegar la PantallaPrincipal con todos sus elementos, incluyendo botones registrados para luego saber cual de ellos fue oprimido. Ahora viene el siguiente paso luego de desplegar la pantalla anterior. El usuario puede llenar los campos de texto, que no generan ningn evento, y desplegar alguno de los tres botones. Qu hace el sistema en el momento que se oprima alguno de estos botones? Recordemos el mtodo actionPerformed de la calse InterfaceUsuario definida precisamente para ello, para la cual agregamos una nueva lnea que ser la encargada de manejar el evento llamando a manejarEventos a partir de cada pantalla desplegada: public void actionPerformed(ActionEvent event) { System.out.println("Action: "+event.getActionCommand()); pantalla.manejarEvento(event.getActionCommand()); } Para que esto funcione primero debemos definir el mtodo manejarEvento dentro de la clase Pantalla (recuerden la explicacin de polimorfimo) y lo hacemos de manera abstracta: protected abstract Pantalla manejarEvento(String str); Luego sobrescribimos el mtodo manejarEvento dentro de la clase PantallaPrincipal de manera que segn se oprima un botn la pantalla instanciar la siguiente a desplegarse. Esto se hace comparando el nombre del botn presionado contra las distintas posibilidades que se destacan en los siguientes if: protected Pantalla manejarEvento(String str) { if (str.equals("Registrarse por Primera Vez")) { if (pantallaCrearRegUsuario == null) pantallaCrearRegUsuario = new PantallaCrearRegUsuario(this); return pantallaCrearRegUsuario; } else if (str.equals("OK")) { if (pantallaServicio == null) pantallaServicio = new PantallaServicio(this); return pantallaServicio; } else if (str.equals("Salir")) { System.exit(0); } else System.out.println("Error en PantallaPrincipal: "+str); return this; }

Weitzenfeld: Captulo 5

50

Por ejemplo, si el usuario presiona el botn "Registrarse por Primera Vez" (ntese que la comparacin de cadenas se hace mediante el mtodo equals) entonces se instancia un pantalla de tipo PantallaCrearRegUsuario, que explicaremos en un momento. Si es un OK se solicita la pantalla PantallaServicio y si es Salir simplemente se sale del programa. Antes de definir nuestra siguiente pantalla, veamos que ocurre con la lgica principal. La llamada manejarEvento fue hecha desde actionPerformed en la clase InterfaceUsuario. Extendamos este mtodo con una nueva versin de la siguiente manera: public void actionPerformed(ActionEvent event) { System.out.println("Action: "+event.getActionCommand()); Pantalla p = pantalla.manejarEvento(event.getActionCommand()); desplegarPantalla(p); } La siguiente llamada es desplegarPantalla y el ciclo se completa. En otras palabras volvimos al inicio de nuestra lgica. La pantalla PantallaCrearRegUsuario se muestra en la Figura 5.33.

Figura 5.33. Ejemplo de marco desplegando PantallaCrearRegUsuario. En la Figura 5.34 se muestran las clases principales, junto con sus atributos y mtodos principales, para el ejemplo de las pantallas mostrado aqu. Ntese que en el diagrama se muestra la notacin de implementar para las interfaces como una herencia punteada a partir de clases abstractas.

Weitzenfeld: Captulo 5

51

Frame

WindowListener

ActionListener

InterfaceUsuario pantalla Pantalla : actionPerformed() windowClosed() windowDeiconified () windowIconified() windowActivated() windowDeactivated() windowOpened() windowClosing() desplegarPantalla()

Pantalla boton : Button texto : TextField panel : Panel paneles : Vector botones : Vector createPantalla() desplegarPantalla() resetPantalla() manejarEvento()

PantallaPrincipal

createPantalla() manejarEvento()

Figura 5.34 Diagrama de clases para el ejemplo de las pantallas. Como veremos en el siguiente captulo, estas pantallas y esta lgica nos servir para crear el prototipo inicial del sistema de reservaciones de vuelos que utilizaremos a lo largo del libro.

Lenguajes

Weitzenfeld: Captulo 6

Parte III Desarrollo de Software Orientado a Objetos

En esta tercera parte del libro describiremos las actividades ms importantes relacionadas con el desarrollo de software: Requisitos (Captulo 6), Anlisis (Captulo 7), Diseo (Captulo 8), Implementacin (Captulo 9) y Pruebas (Captulo 10).

6 Modelo de Requisitos
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea segn la percepcin del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo. El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formacin de todos los dems modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es ms fcil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodologa Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso. Actualmente esta metodologa es parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los dems modelos, como se describi anteriormente en el Captulo 3 y se resume aqu: ? ? Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver ms adelante. ? ? Anlisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de anlisis, que es estable con respecto a cambios, siendo un modelo lgico independiente del ambiente de implementacin. ? ? Diseo: La funcionalidad de los casos de uso ya estructurada por el anlisis es realizada por el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms. ? ? Implementacin: Los casos de uso son implementados mediante el cdigo fuente en el modelo de implementacin. ? ? Pruebas: Los casos de uso son probados a travs de las pruebas de componentes y pruebas de integracin. ? ? Documentacin: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administracin, etc. El diagrama de la Figura 6.1 ilustra los distintos modelos. Describiremos los detalles y la notacin ms adelante.
OK OK falla

class...

El caso..

Modelo de Requisitos

Modelo de Anlisis

Modelo de Modelo de Modelo de Modelo de Diseo Implementacin Pruebas Documentacin

Figura 6.1 Dependencia de los distintos modelos del proceso de software del modelo de casos de uso. El propsito del modelo de requisitos es comprender completamente el problema y sus implicaciones. Todos los modelos no solamente se verifican contra el modelo de requisitos, sino que tambin se desarrollan directamente de l. El modelo de requisitos sirve tambin como base para el desarrollo de las instrucciones operacionales y los manuales ya que todo lo que el sistema deba hacer se describe aqu desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecnico, el analista debe interactuar constantemente con el cliente para completar la informacin faltante, y as clarificar ambigedades e inconsistencias. El analista debe separar entre los requisitos verdaderos y las decisiones relacionadas con el diseo e implementacin. Se debe indicar cuales aspectos son obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la implementacin. Durante el diseo se debe extender el modelo de requisitos con especificaciones de rendimiento y protocolos de interaccin con sistemas externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseo, como el uso de lenguajes de programacin particulares. En la metodologa de Objectory, el modelo de requisitos consiste de tres modelos principales, visualmente representado por un diagrama de tres dimensiones como se muestra en la Figura 6.2.

Weitzenfeld: Captulo 6

Comportamiento (casos de uso)

Informacin (dominio del problema)

Presentacin (interfaces/borde)

Figura 6.2 Los tres ejes de modelado del modelo de requisitos. ?? El modelo de comportamiento, basado directamente en el modelo de casos de uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos claves: actores para representar los distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso para representar qu pueden hacer los actores con respecto al sistema ? ? El modelo de presentacin o modelo de interfaces o borde especifica cmo interacta el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de informacin ricos en interaccin con el usuario, especifica cmo se vern visualmente las interfaces grficas y que funcionalidad ofrecer cada una de ellas. ? ? El modelo de informacin o modelo del dominio del problema especifica los aspectos estructurales del sistema. Este modelo conceptualiza el sistema segn los objetos que representan las entidades bsicas de la aplicacin. Aunque en muchas metodologas se permite especificar la funcionalidad completa del sistema utilizando el modelo del dominio del problema, incluyendo operaciones formales sobre los objetos correspondientes a un modelo de requisitos expresado sin casos de uso, el modelo del dominio del problema ser de mucha ms ayuda como apoyo al modelo de casos de uso y no como una entidad totalmente independiente. Es importante resaltar que esta separacin en tres ejes de modelado independientes es la base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos. Para ilustrar el modelo de requisitos y el desarrollo de los modelos posteriores, utilizaremos el ejemplo del Sistema de Reservaciones de Vuelo como se mencion anteriormente. Para tal meta, mostraremos inicialmente una descripcin del problema. A partir de esta descripcin inicial se describirn los tres modelos bsicos del modelo de requisitos.

6.1 Descripcin del Problema

La descripcin del problema es una descripcin muy preliminar de necesidades que sirve nicamente como punto de inicio para comprender los requisitos del sistema. Se trata aqu de simular una descripcin preparada por un cliente la cual debe evolucionar por medio del modelo de requisitos para lograr la especificacin final del sistema a desarrollarse. La descripcin del problema debe ser una descripcin de necesidades y no una propuesta para una solucin. La descripcin inicial puede ser incompleta e informal. No hay razn para esperar que la descripcin inicial del problema, preparada sin un anlisis completo, sea correcta. Utilizaremos como ejemplo un Sistema de Reservaciones de Vuelos con acceso va Internet. Este es un sistema que permite al usuario hacer consultas y reservas de vuelos, adems de poder comprar los boletos areos de forma remota, sin la necesidad de recurrir a un agente de viajes humano. Se desea que el sistema de reservaciones sea accesible a travs del Internet (World Wide Web). Como base para estos sistemas, existen en la actualidad mltiples bases de datos de reservaciones de vuelos que utilizan las agencias de viajes para dar servicio a los clientes, por ejemplo, Sabre, Apollo, Worldspan, Amadeus, Sahara, Panorama, Gemini, Galileo, Axess, etc. Muchos de estas bases de datos y sistemas correspondientes son la base para los sistemas de reservaciones de vuelos de acceso por Internet, como por ejemplo, Travelocity, Expedia, Viajando, DeViaje, etc. La descripcin del problema para nuestro sistema de reservaciones de vuelos es la siguiente: El Sistema de Reservaciones de Vuelos es un sistema que permite al usuario hacer consultas y reservas de vuelos, adems de poder comprar los boletos areos de forma remota, sin la necesidad de recurrir a un agente de viajes humano. Se desea que el sistema de reservaciones sea accesible a travs del Internet (World Wide Web).

Weitzenfeld: Captulo 6

El sistema presenta en su pantalla principal un mensaje de bienvenida describiendo los servicios ofrecidos junto con la opcin para registrarse por primera vez, o si ya se est registrado, poder utilizar el sistema de reservaciones de vuelos. Este acceso se da por medio de la insercin de un login previamente especificado y un password previamente escogido y que debe validarse. Una vez registrado el usuario, y despus de haberse validado el registro y contrasea del usuario, se pueden seleccionar las siguientes actividades: Consulta de vuelos Reserva de vuelos Pago de boletos La consulta de vuelos se puede hacer de tres maneras diferentes: Horarios de Vuelos Tarifas de Vuelos Estado de Vuelo La consulta segn horario muestra los horarios de las diferentes aerolneas dando servicio entre dos ciudades. La consulta segn tarifas muestra los diferentes vuelos entre dos ciudades dando prioridad a su costo. El estado de vuelo se utiliza principalmente para consultar el estado de algn vuelo, incluyendo informacin de disponibilidad de asientos y, en el caso de un vuelo para el mismo da, si est en hora. Se puede incluir preferencias en las bsquedas, como fecha y horario deseado, categora de asiento, aerolnea deseada y si se desea slo vuelos directos. La reservacin de vuelo permite al cliente hacer una reserva para un vuelo particular, especificando la fecha y horario, bajo una tarifa establecida. Es posible reservar un itinerario compuesto de mltiples vuelos, para uno o ms pasajeros, adems de poder reservar asientos. El pago permite al cliente, dada una reserva de vuelo previa y una tarjeta de crdito vlida, adquirir los boletos areos. Los boletos sern posteriormente enviados al cliente, o estarn listos para ser recogidos en el mostrador del aeropuerto previo a la salida del primer vuelo. Es necesario estar previamente registrados con un nmero de tarjeta de crdito vlida para poder hacer compras de boletos, o de lo contrario proveerla en el momento de la compra. Adems de los servicios de vuelo, el usuario podr en cualquier momento accesar, modificar o cancelar su propio registro, todo esto despus de haber sido el usuario validado en el sistema. Ntese lo informal y limitado de esta descripcin, la cual estaremos refinando a lo largo del captulo. Dado que el modelo de casos de uso es el principal de todo el sistema, pues comenzaremos con l.

6.2 Modelo de Casos de Uso

El modelo de casos de uso describe un sistema en trmino de sus distintas formas de utilizacin, cada uno de estas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, cambios en los requisitos significarn cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automvil sera la secuencia de eventos desde que el conductor entra en el coche encendiendo el motor hasta llegar a su destino final. Por lo tanto, para comprender los casos de uso de un sistema primero es necesario saber quienes son sus usuarios. Por ejemplo, conducir un automvil es distinto a arreglarlo, donde los usuarios tambin son distintos, el dueo del automvil y el mecnico, respectivamente. Para ello se define el concepto de actor, correspondiente al tipo de usuario que est involucrado en la utilizacin de un sistema, siendo el actor una entidad externa al propio sistema. Juntos, el actor y el caso de uso representan los dos elementos bsicos de este modelo lo cual se muestran de manera grfica en la Figura 6.3 de acuerdo a la notacin UML.

Weitzenfeld: Captulo 6

actor

caso de uso

Figura 6.3 El actor y el caso de uso son las entidades bsicas del modelo de casos de uso. Los casos de uso son una idea simple y prctica que no requieren muchas habilidades tecnolgicas para ser utilizadas (a diferencia de las dems actividades del desarrollo). Por el contrario, si se volvieran muy complejas se perdera un poco la importancia de los casos de uso. Dado que el modelo de requisitos es la primera actividad del desarrollo del sistema, nos podemos dar el lujo de muchos cambios en su especificacin sin afectar al resto del sistema. Ms an, considerando que siempre habr cambios, no debe hacerse demasiado trabajo muy temprano, ya que solo sera descartado. Cuando se identifican y describe los casos de uso, habr ciertas imprecisiones que se irn resolviendo ms adelante. Para ello, un enfoque incremental es lo indicado. De esta manera se puede desarrollar de forma independiente los distintos casos de uso y luego integrarlos para formar el modelo de requisitos completo. Esta habilidad para tomar parte de la funcionalidad permite un desarrollo ms flexible e incluso concurrente. Actores Los actores son entidades distintas a los usuarios, en el sentido que los usuarios son las personas reales que utilizan el sistema, mientras que los actores representan un cierto papel que una persona real puede jugar. Utilizando terminologa orientada a objetos, se considera al actor como una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Incluso, una misma persona puede aparecer como diferentes instancias de diferentes actores. Los actores modelan cualquier entidad externa que necesite intercambiar informacin con el sistema. Los actores no estn restringidos a ser personas fsicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Adems, cada uno de estos actores podr ejecutar una o ms tareas del sistema. Antes de identificar los casos de uso se identifican los actores del sistema. La razn para comenzar con la identificacin de los actores es para que ellos sean la herramienta principal para luego encontrar los casos de uso. Cada actor ejecuta un nmero especfico de casos de uso en el sistema. Al definir todos los actores y casos de uso en el sistema, se define la funcionalidad completa del sistema. Encontrar actores puede tomar trabajo y raramente se encuentran todos los actores de una vez. Por ejemplo, un sistema de computacin puede tener diferentes tipos de usuarios: programadores, operadores, administradores, o usuarios generales. Cada uno de estos tipos de usuario corresponde a un actor diferente y como mencionamos anteriormente, una misma persona puede jugar, por ejemplo, el papel de programador u operador. Para especificar los actores de un sistema, se dibuja un diagrama correspondiente a la delimitacin del sistema, la cual representa al sistema como una caja negra y a los diferentes actores como entidades externas a sta, como se muestra en la Figura 6.4.

Programador

Sistema de Computacin

Operador

Usuario

Administrador

Figura 6.4 Delimitacin de un sistema segn los actores. En general, no se describen los actores con demasiado detalle por ser estos externos al sistema adems de que sus acciones no son deterministas, en otras palabras, un actor a diferencia del propio sistema, en cada momento puede decidir entre mltiples opciones. Por otro lado, el sistema y los casos de uso correspondientes deben ser deterministas, de lo contrario el sistema har lo que le plazca, lo cual no es aceptable. Sin embargo, para poder identificar los casos de uso, es necesario primero identificar los actores del sistema, comenzando por aquellos que son la razn principal del sistema, conocidos como actores primarios. Estos actores tpicamente rigen la secuencia lgica de ejecucin del sistema. Adems de los actores primarios existen actores supervisando y manteniendo el

Weitzenfeld: Captulo 6

sistema. Estos actores secundarios existen primordialmente como complemento a los actores primarios, siendo esta distincin importante para dedicarle el esfuerzo principal a las necesidades de los actores primarios. Al contrario de los actores primarios que tpicamente corresponden a personas fsicas, los actores secundarios corresponden por lo general a mquinas o sistemas externos, siendo estos ltimos ms difciles de identificar. Los actores secundarios tienden a responder a secuencias lgicas del sistema y no tanto a inicializarlas de manera propia. En particular, existe siempre la duda, por ejemplo, de si el sistema operativo o una base de datos seran actores. La decisin depende del papel que jueguen con respecto al sistema en desarrollo, si juegan un papel activo entonces deben modelarse como actores. Volviendo al ejemplo del Sistema de Reservaciones de Vuelos, se pueden identificar de la descripcin del problema que se tiene al menos un actor, el Usuario, encargado de hacer las consultas y reservas con el sistema. Si se analiza un poco ms, de puede identificar que las bases de datos de los sistemas externos de reservaciones juegan un papel muy activo con respecto al sistema en desarrollo. A este actor lo llamaremos la Base de Datos de Reservas, el cual mantiene la informacin sobre los vuelos y reservas. Ms an, podemos identificar un actor adicional representando una segunda base de datos, sta involucrada en la informacin de los usuarios ms que de las reservaciones. A este actor lo llamaremos la Base de Datos de Registros, encargado de mantener la informacin de los usuarios sobre la utilizacin del sistema. El diagrama de Delimitacin del Sistema con los actores correspondientes se muestra en la Figura 6.5.

Sistema de Reservaciones de Vuelos Usuario

Base de Datos Reservas

Base de Datos Registros

Figura 6.5 Delimitacin del sistema de reservaciones de vuelo. Volviendo a la distincin entre actor y persona, una misma persona puede jugar el papel del actor Usuario cuando hace reservas y adems puede trabajar para el sistema de reservaciones, por ejemplo como Operador, correspondiente a otro actor no mostrado en nuestro ejemplo. El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de Datos de Reservas y Base de Datos de Registro son ambos actores secundarios, ya que si no existieran usuarios no habra necesidad del sistema. Cuando diferentes actores juegan roles similares ellos pueden heredar de un actor abstracto comn, como se muestra mediante el actor abstracto Base de Datos en el ejemplo de la Figura 6.6. El resto de los actores se conoce como actores concretos, utilizando terminologa similar a aquella de herencia, como se vio en el Captulo 4.

Weitzenfeld: Captulo 6

Sistema de Reservaciones de Vuelos Usuario Base de Datos

Base de Datos Registros

Base de Datos Reservas

Figura 6.6 Delimitacin del sistema de reservaciones de vuelo con ejemplo de herencia entre actores. La ventaja de modelar actores abstractos es que expresa similitudes entre caso de uso. Si el mismo o parte del mismo caso de uso se puede ejecutar por varios actores diferentes, el caso de uso necesita ser especificado solo con respecto a un actor en lugar de varios. Por otro lado, los actores abstractos tambin pueden ser utilizados para especificar privilegios comunes a mltiples actores en un sistema. Casos de Uso Despus de haber definido los actores del sistema, se define la funcionalidad propia del sistema por medio de los casos de uso. Utilizando terminologa orientada a objetos, cada caso de uso define una clase o forma particular de usar el sistema mientras que cada ejecucin del caso de uso se puede ver como una instancia del caso de uso, o sea, un objeto, con estado y comportamiento. Cada caso de uso constituye un flujo completo de eventos especificando la interaccin que toma lugar entre el actor y el sistema. El actor primario es encargado de dar inicio a esta interaccin, mientras que los casos de uso son instanciados como respuesta al evento anterior. Una instancia de un actor puede ejecutar varias de estas secuencias, consistiendo de diferentes acciones que a su vez deben llevarse a cabo. La instancia del caso de uso existe mientras el caso de uso siga ejecutando. La ejecucin del caso de uso termina cuando el actor genere un evento que requiera un caso de uso nuevo. Las diferentes instancias de los casos de uso se conocen como escenarios. Como varios casos de uso pueden comenzar de una misma forma, no es siempre posible decidir que caso de uso se ha instanciado hasta que ste se haya completado. La descripcin de los casos de uso es mediante diagramas similares a los de transicin de estados. Se puede ver a cada caso de uso como representando un estado en el sistema, donde un estmulo enviado entre un actor y el sistema ocasiona una transicin entre estados. En la Figura 6.7 se muestra un ejemplo de casos de uso, donde un programador escribe y depura un programa, mientras que otro usuario lo ejecuta.

Programador

Escribir Programa

Ejecutar Programa

Usuario

Depurar Programa

Figura 6.7 Ejemplo de casos de uso mostrando la relacin con los actores.

Para identificar los casos de uso, se puede leer la descripcin del problema y discutirlo con aquellos que actuarn como actores, haciendo preguntas como: ? ? Cuales son las tareas principales de cada actor? ? ? Tendr el actor que consultar y modificar informacin del sistema? ? ? Tendr el actor que informar al sistema sobre cambios externos?

Weitzenfeld: Captulo 6

? ? Desea el actor ser informado sobre cambios inesperados? Por ejemplo, en un sistema de conmutacin telefnica, un actor podra ser un subscriptor, y un caso de uso tpico sera hacer una llamada local. El caso de uso comienza cuando el subscriptor levanta el telfono. Otro caso de uso es ordenar una llamada de despertar. Ambos casos de uso comienzan cuando el subscriptor levanta el telfono. Pero cuando el subscriptor levanta el telfono no sabemos cual caso de uso desea ejecutar. Por lo tanto, los casos de uso pueden comenzar de forma similar y no podemos saber cual se est instanciando hasta que se termine. En otras palabras, el actor no requiere que un caso de uso se ejecute, slo que inicie una secuencia de eventos que finalmente resulte en la terminacin de algn casos de uso. En el sistema de reservaciones de vuelos utilizamos los actores ya identificados como punto de partida. Dado que el Usuario es el actor primario se comienza con l. El sistema tiene que poder dar ciertos servicios al usuario, como consultas y reservas. De aqu podemos definir nuestros casos de uso principales, Consultar Informacin y Hacer Reservacin. Ntese que los nombres de los casos de uso deben corresponder a acciones y no tanto a sustantivos. La Figura 6.8 muestra el sistema con los dos casos de uso, adems de un caso de uso adicional, Mantener el Sistema, correspondiente a un actor secundario Operador. Sin embargo, para lograr una mejor especificacin de requisitos y evitar complejidad adicional, no veremos ninguna funcionalidad de mantenimiento en nuestro desarrollo, un ejemplo adicional de como podemos concentrarnos en ciertos aspectos de los requisitos durante diversas etapas.

Usuario Consultar Informacin

Mantener el Sistema

Operador

Hacer Reservacin

Figura 6.8 Ejemplo de casos de uso para un sistema de reservaciones de vuelo. En la descripcin del problema se menciona que para poder utilizar el sistema el usuario debe estar registrado, por lo cual agregamos un caso de uso Registrar Usuario. Por otro lado, se debe incluir la Base de Datos de Reservas, y la Base de Datos de Registro ya que son actores secundarios necesarios. Estos tres casos de uso se muestran en la Figura 6.9.

Registrar Usuario

Base de Datos Registros

Usuario Cons ult ar Informacin

Base de Datos Reservas Hacer Reservacin

Figura 6.9 Casos de uso principales para el sistema de reservaciones de vuelo. Se elimin en el diagrama la delimitacin del sistema. Aunque la idea del modelo de casos de uso es mantener lo ms sencillo posible la complejidad en los diagramas dada la etapa en que nos encontramos del desarrollo, existen ciertas extensiones al concepto bsico de caso de uso que permiten subdividirlos de manera limitada. Para ello se permite la asignacin de secciones del flujo completo de

Weitzenfeld: Captulo 6

un caso de uso en casos de uso separados. Las razones para esto son aprovechar distintas variantes en los casos de uso que se repiten en la lgica del sistema de manera anloga al concepto de herencia. Lamentablemente, no es siempre obvio la funcionalidad que debe ser puesta en casos de uso separados, y qu situacin es slo una pequea variante de un mismo caso de uso que no amerita tal divisin. La complejidad de los casos de uso es un factor importante para tal decisin. Existen dos enfoques distintos para expresar variantes: 1. Si las diferencias entre los casos de uso son pequeas, estos se pueden describir como variantes de un mismo caso de uso, y se pueden definir subflujos separados dentro de un mismo caso de uso, dando lugar al concepto de flujos bsicos y subflujos alternos. Por ejemplo, en el caso de uso registrar un usuario, crear por primera vez el registro y actualizarlo se pueden considerar como dos secuencias de eventos lgicamente similares por lo cual se tratan como subflujos alternos. En general, primero se describe el flujo bsico, el cual es el flujo ms importante dentro del caso de uso. Este flujo corresponde a la secuencia de eventos ms comn o tpica de casos de uso. Posteriormente se describen las variantes o flujos alternos que incluyen flujos para el manejo de variantes en la lgica. Normalmente un caso de uso tiene slo un curso bsico, pero varios cursos alternos. 2. Si las diferencias entre los casos de uso son grandes, se deben describir como casos de uso separados. Cuando los casos de uso se dividen en casos de uso separados se utiliza principalmente las relaciones de extensin, inclusin y generalizacin como se describe a continuacin. La identificacin de casos de uso y de los aspectos anteriores, es a menudo un proceso muy iterativo donde varios intentos se hacen hasta llegar a una solucin final estable. Cuando esto ocurre, cada caso de uso debe ser descrito con ms detalle. Extensin Un concepto importante que se utiliza para estructurar y relacionar casos de uso es la extensin. La extensin especifica cmo un caso de uso puede insertarse en otro para extender la funcionalidad del anterior. El caso de uso donde se va a insertar la nueva funcionalidad debe ser un flujo completo, por lo cual ste es independiente del caso de uso a ser insertado. De esta manera, el caso de uso inicial no requiere consideraciones adicionales al caso de uso a ser insertado, nicamente especificando su punto de insercin. Tomando como ejemplo el Sistema de Reservaciones de Vuelos, se muestra en la Figura 6.10 la notacin para extensin, utilizando la etiqueta extiende (extend), donde el caso de uso de Hacer Reservacin es extendido mediante el caso de uso Pagar Reservacin.

Base de Datos Reservas

<<extend>> Usuario Hacer Res ervacin Pagar Reservacin

Figura 6.10 Casos de uso Hacer Reservacin con extensin de Pagar Reservacin. En general la extensin se utiliza para modelar secuencias de eventos opcionales de casos de uso que al manejarse de manera independiente pueden ser agregados o eliminados del sistema de manera modular. Se puede considerar a la asociacin de extensin como una interrupcin en el caso de uso original que ocurre donde el nuevo caso de uso se va a insertar. Para cada caso de uso que vaya a insertarse en otro caso de uso, se especifica la posicin en el caso de uso original donde el caso de uso de extensin debe insertarse. El caso de uso original se ejecuta de forma normal hasta el punto donde el caso de uso nuevo se inserta. En este punto, se contina con la ejecucin del nuevo curso. Despus que la extensin se ha terminado, el curso original contina como si nada hubiera ocurrido. Por regla general, se describe primeros los casos de uso bsicos totalmente independientes de cualquier extensin de funcionalidad y luego aquellos de extensin. Inclusin Una relacin adicional entre casos de uso es la inclusin. A diferencia de una extensin, la inclusin se define como una seccin de un caso de uso que es parte obligatoria del caso de uso bsico. El caso de uso donde se va a insertar

Weitzenfeld: Captulo 6

la funcionalidad depende del caso de uso a ser insertado. Se etiqueta la relacin con incluye (include). Por ejemplo, en el Sistema de Reservaciones de Vuelos, el caso de uso de Consultar Informacin incluye el caso de uso Validar Usuario como se muestra en la Figura 6.11.

Validar Usuario

Base de Datos Registros

<<include>> Usuario

Consultar Informacin Base de Datos Reservas

Figura 6.11 Casos de uso Consultar Informacin con inclusin de Validar Usuario. Generalizacin Una relacin adicional entre casos de uso es la generalizacin la cual apoya la reutilizacin de los casos de uso. Mediante la relacin de generalizacin es necesario describir las partes similares una sola vez en lugar de repetirlas para todos los casos de uso con comportamiento comn. Se conoce a los casos de uso que se extraen como casos de uso abstractos, ya que no sern instanciados independientemente, sirviendo slo para describir partes que son comunes a otros casos de uso. Se conoce a los casos de uso que realmente sern instanciados como casos de uso concretos. Las descripciones de los casos de uso abstractos se incluyen en las descripciones de los casos de uso concretos. Esto significa que, cuando una instancia de un caso de uso sigue la descripcin de un caso de uso concreto, en cierto punto contina la descripcin del caso de uso abstracto en su lugar. Los casos de uso abstractos tambin pueden ser usados por otros casos de uso abstractos. Es difcil saber cuando ya no tiene sentido seguir extrayendo ms casos de uso abstractos. Una tcnica para extraer casos de uso abstractos es identificar actores abstractos. Normalmente, no hay razn para crear casos de uso abstractos que se usan en un solo caso de uso. Por lo general, comportamientos similares entre casos de uso se identifica despus que se han descrito los casos de uso. Sin embargo, en algunos casos es posible identificarlos antes. De forma intuitiva, esto es un herencia de secuencias(en lugar de operaciones en el caso normal de herencia). Por ejemplo, en el Sistema de Reservaciones de Vuelos, el caso de uso de Consultar Informacin incluye el caso de uso Validar Usuario como se muestra en la Figura 6.12.

Base de Datos Reservas

<<extend>> Usuario Hacer Reservaci n Pagar Reservaci n

Pagar con Tarjeta

Pagar con Transferencia

Figura 6.12 Casos de uso Pagar Reservacin con generalizacin de pagos: Pagar con Tarjeta y Pagar con Transferencia.

Weitzenfeld: Captulo 6

10

Las relaciones de extensin e inclusin entre casos de uso son ambas asociaciones de clases, a diferencia de la generalizacin. En la mayora de los casos, la seleccin es bastante obvia, sin embargo el criterio importante es ver qu tanto se acoplan las funcionalidades de los casos de uso. Si el caso de uso a ser extendido es til por si mismo, la relacin debe ser descrita utilizando extensin. Si los casos de uso son fuertemente acoplados, y la insercin debe tomar lugar para obtener un curso completo, la relacin debe ser descrita utilizando inclusin. Por otro lado, la generalizacin es utilizada cuando dos o ms casos de uso comparte funcionalidad comn la cual es extendida por cada uno al estilo de la generalizacin entre clases. Tambin hay una diferencia en cmo se encuentran. Las extensiones se encuentran en un caso de uso existente que el usuario desea ramificar en secuencias adicionales, mientras que las inclusiones se encuentran de la extraccin de secuencias comunes entre varios casos de uso diferentes. Las generalizaciones se encuentran al tratar de especializar de diferente manera un mismo caso de uso. Finalmente, se desean diagramas con baja complejidad que no sean "telaraas" pero que muestren de manera esquemtica las posibles secuencias de interacciones entre los actores y el sistema. Mostramos en la Figura 6.13 el diagrama completo de casos de uso para el Sistema de Reservaciones de Vuelos. Los casos de uso adicionales en este diagrama son la extensin de Registrar Tarjeta y Pagar Reservacin. Este ltimo caso de uso es interesante por que extiende Hacer Reservacin e incluye Registrar Tarjeta, ambos requisitos para poder comprar un boleto con el sistema. Adems de la inclusin anterior, tambin se incluyen los casos de uso de Validar Usuario y Ofrecer Servicios en los casos de uso bsicos: Registrar Usuario, Consultar Informacin y Hacer Reservacin.

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

<<incl ude>>

Registrar Tarjeta <<include>>

<<include>> <<include>> Usuario Hacer Reservacin

<<extend>>

Pagar Reservacin

<<include>>

<<incl ude>> Ofrecer Servicios Consultar Informacin Base de Datos Reservas

Figura 6.13 Casos de uso completos para el sistema de reservaciones de vuelo. Documentacin Parte fundamental del modelo de casos de uso es una descripcin textual detallada de cada uno de los actores y casos de uso identificados. Estos documento son sumamente crticos ya que a partir de ellos se desarrollar el sistema completo. El formato de documentacin es el siguiente: Actor: Casos de Uso: Tipo: Descripcin: Nombre del actor Nombre de los casos de uso en los cuales participa Primario o Secundario Breve descripcin del actor

Weitzenfeld: Captulo 6

11

Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema para los eventos enviados o recibidos por los actores. En esta etapa no se incluyen eventos internos al propio sistema ya que esto ser tratado durante el anlisis y nicamente agregara complejidad innecesaria en esta etapa. El formato de documentacin es el siguiente: Caso de Uso: Actores: Tipo: Propsito: Resumen: Precondiciones: Flujo Principal: Subflujos: Excepciones: Nombre del caso de uso Actores primarios y secundarios que interaccionan con el caso de uso. Tipo de flujo: Bsico, Inclusin, Extensin, Generalizacin, o algn otro. Razn de ser del caso de uso. Resumen del caso de uso. Condiciones que deben satisfacerse para poder ejecutar el caso de uso. El flujo de eventos ms importante del caso de uso, donde dependiendo de las acciones de los actores se continuar con alguno de los subflujos. Los flujos secundarios del caso de uso, numerados como (S-1), (S-2), etc. Excepciones que pueden ocurrir durante el caso de uso, numerados como (E-1), (E-2), etc.

Dado que el modelo de casos de uso est motivado y enfocado principalmente hacia los sistemas de informacin donde los usuarios juegan un papel primordial, es importante ya relacionarse con las interfaces a ser diseadas en el sistema. Estas interfaces sirven para apoyar de mejor manera la descripcin de los casos de uso adems de servir de base para prototipos iniciales. Un comentario importante sobre la especificacin de estos documentos es que se sigue un proceso iterativo para definir cada uno de ellos, pudindose modificar o refinar posteriormente. Obviamente, cuanto ms tarde ocurran estos cambios ms costoso ser implementarlos. Ntese que en las siguientes descripciones ya se hace referencia a pantallas de interaccin con el usuario, las cuales sern mostradas en un diseo preliminar en la siguiente seccin. Los actores y casos de uso del sistema de reservaciones de vuelo son descritos en la seccin 6.4.

6.3 Modelo de Interfaces

El modelo de interfaces describe la presentacin de informacin entre los actores y el sistema. Se especifica en detalle como se vern las interfaces de usuario al ejecutar cada uno de los casos de uso. Si se trata de Interfaz Humano Computadora (HCI - Human Computer Interface) se puede usar esquemas de cmo vera el usuario las pantallas cuando se ejecuta cada caso de uso. Tambin se puede generar una simulacin ms sofisticada usando un Sistema Manejador de Interfaces de Usuario (UIMS - User Interface Management System). Normalmente, un prototipo funcional de requisitos mostrando las interfaces de usuario es una estrategia importante. Esto ayuda al usuario a visualizar los casos de uso segn sern mostrados por el sistema a ser construido. Tal enfoque elimina muchas posibilidades de malos entendimientos. Cuando se disean las interfaces de usuario, es esencial tener a los usuarios involucrados, siendo esencial que las interfaces reflejen la visin lgica del sistema. Esto es realmente uno de los principios fundamentales del diseo de interfaces humanas, donde debe existir consistencia entre la imagen conceptual del usuario y el comportamiento real del sistema. Si las interfaces son protocolos de hardware, se puede referir a los diferentes estndares, como protocolos de comunicacin. Estas descripciones de interfaces son por lo tanto partes esenciales de las descripciones de los casos de uso y las deben acompaar. En estas etapas iniciales del desarrollo el diseo de las pantallas no es tan importante como el manejo de informacin que se ofrece el cual debe corresponder a las necesidades de cada caso de uso, algo que se mostrar a continuacin para el Sistema de Reservaciones de Vuelos.

6.4 Actores y Casos de Uso para el Sistema de Reservaciones de Vuelos

Tomando como ejemplo el sistema de reservaciones de vuelo mostraremos la documentacin de los actores y casos de uso junto con el diseo de las interfaces que sern usadas como prototipo del sistema. Estos diseos pueden hacerse en papel o aprovechar una herramienta que simplifique la tarea del diseo de pantallas. El objetivo primordial es la lgica de navegacin la cual debe basarse en el modelo de casos de uso ms que la sofisticacin del diseo grfico.

Weitzenfeld: Captulo 6

12

Actores Se describen en total tres actores en el sistema de reservaciones de vuelos. El Usuario interacta con todos los casos de uso, aunque todas las asociaciones no fueron diagramadas de manera explcita en la Figura 6.13. Actor: Casos de Uso: Tipo: Descripcin: Usuario Validar Usuario, Registrar Usuario, Registrar Tarjeta, Consultar Informacin, Hacer Reservacin, Pagar Reservacin, Ofrecer Servicios Primario Es el actor principal y representa a cualquier persona que desee utilizar del sistema de reservaciones.

La Base de Datos de Registro interacta con los casos de uso relacionados exclusivamente con registro. Actor: Casos de Uso: Tipo: Descripcin: Base de Datos de Registro Validar Usuario, Registrar Usuario, Registrar Tarjeta Secundario Es un actor secundario y representa a la base de datos donde se guarda toda la informacin relacionada con los usuarios pero independiente de las reservaciones.

La Base de Datos de Reservaciones interacta con los casos de uso relacionados exclusivamente con reservaciones. Actor: Casos de Uso: Tipo: Descripcin: Base de Datos de Reservaciones Consultar Informacin, Hacer Reservacin, Pagar Reservacin Secundario Es un actor secundario y representa a la base de datos donde se guarda toda la informacin relacionada con las reservaciones pero independiente de los propios usuarios del sistema.

Casos de Uso Como apoyo en la descripcin de los casos de uso mostraremos las diversas pantallas diseadas, comenzando con la pantalla inicial. Dado que el requisito de uso del sistema es que todo usuario deba haberse registrado, la pantalla principal debe dar dos opciones: (i) registrarse por primera vez y (ii) validar un registro existente como se muestra en la Figura 6.14.

Weitzenfeld: Captulo 6

13

Figura 6.14. Pantalla Principal del Sistema (P-1). Ntese que el caso de uso Registrar Usuario, como lo describiremos en nuestro ejemplo, agrupa la lgica relacionada con un usuario ya registrado junto con otro que se registra por primera vez. Dado que la opcin para registrarse por primera vez debe aparecer en la pantalla inicial (P-1), la opcin en la pantalla de servicios (P-2) permite nicamente obtener el registro de un usuario ya registrado. Y aunque se podra haber definido dos casos de uso separados para la lgica de registro, por ejemplo, Crear Registro Usuario y Obtener Registro Usuario, consideramos que estos dos son ms bien subflujos de un mismo caso de uso. Vale la pena un comentario adicional. Existen muchas maneras de describir un sistema similar, donde por lo general una forma no es necesariamente ms correcta que la otra, siendo ms bien una cuestin de estilo o creencias del analista. En nuestro caso buscamos soluciones compactas reduciendo el nmero total de casos de uso, siempre y cuando la lgica est muy relacionada. Se incluyen adems varios subflujos para permitir llamar secciones del flujo desde distintos lugares ya que no se puede comenzar un flujo o subflujo en la mitad. A continuacin describimos los distintos casos de uso con las pantallas correspondientes. Se excluyen pantallas menores como aquellas con mensajes de error o confirmacin del xito de la operacin. Comenzamos describiendo los flujos Validar Usuario y Ofrecer Servicios que son incluidos por los diversos casos de uso. Posteriormente describimos cada uno de los casos bsicos y de extensin. Validar Usuario El caso de uso Validar Usuario est vinculado con la pantalla principal (P-1) y es llamada a partir de los casos de uso Registrar Usuario, Consultar Informacin y Hacer Reservacin como se mostr en el diagrama de la Figura 6.13. Dado que este caso de uso es insertado en los anteriormente mencionados, depende de estos insertarlo y llamarlo apropiadamente. Caso de Uso Actores Tipo Propsito Validar Usuario Usuario, Base de Datos Registros Inclusin Validar a un usuario ya registrado para el uso del sistema de reservaciones de vuelo.

Weitzenfeld: Captulo 6

14

Resumen Precondiciones Flujo Principal

Subflujos Excepciones

Este caso de uso es iniciado por el Usuario. Valida al usuario mediante un login y password a ser validado con su respectivo registro de usuario para as poder utilizar el sistema de reservaciones. Se requieren haber ejecutado anteriormente el caso de uso Registrar Usuario subflujo Crear Registro Usuario. Se presenta al usuario la Pantalla Principal (P-1). El Usuario puede seleccionar entre las siguientes opciones: "Registrarse por Primera Vez", "OK" y "Salir". Si la actividad seleccionada es "Registrarse por Primera Vez", se ejecuta el caso de uso Registrar Usuario, subflujo Crear Registro Usuario (S-1). Si la actividad seleccionada es "OK", se valida el registro de usuario mediante un login y un password insertados por el usuario en la Pantalla Principal (P-1). Una vez validado el usuario (E-1), se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema. Ninguno. E-1 no hubo validacin: El login/password no se valid correctamente. Se solicita al usuario volver a registrarse. Despus tres intentos se saldr del sistema.

Ofrecer Servicios Si nos referimos al diagrama de casos de uso de la Figura 6.13 vemos que existen tres casos de uso bsicos que el usuario puede instanciar, Registrar Usuario, Hacer Reservacin y Consultar Informacin. El caso de uso Ofrecer Servicio es incluido por estos tres casos de uso bsicos para delegar de manera adecuada a ellos segn las opciones seleccionadas por el usuario. Tambin es incluido por el caso de uso Validar Usuario luego de la validacin de un usuario. Caso de Uso Actores Tipo Propsito Resumen Precondiciones Flujo Principal Ofrecer Servicios Usuario Inclusin Ofrecer los diversos servicios a un usuario ya registrado para el uso del sistema de reservaciones de vuelo. Este caso de uso es iniciado por el Usuario. Tiene opciones para utilizar las diversas opciones del sistema de reservaciones. Se requieren haber la validacin correcta del usuario. Se presenta al usuario la Pantalla Servicios (P-2). El usuario puede seleccionar entre las siguientes actividades: Consultar Informacin, Hacer Reservacin, "Obtener Registro" y "Salir". Si la actividad seleccionada es "Consultar Informacin", se continua con el caso de uso Consultar Informacin, subflujo Consultar (S-1). Si la actividad seleccionada es "Hacer Reservacin", se continua con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es "Obtener Registro", se contina con el caso de uso Registrar Usuario, subflujo Obtener Registro Usuario (S-2). Si la actividad seleccionada es "Salir" se saldr del sistema. Ninguno. Ninguno.

Subflujos Excepciones

Por tal motivo la siguiente pantalla del sistema debe permitir al usuario seleccionar las opciones correspondientes, como se muestra en la Figura 6.15.

Weitzenfeld: Captulo 6

15

Figura 6.15. Pantalla de Men de Servicios (P-2). Registrar Usuario El caso de uso Registrar Usuario est vinculado con el registro inicial del usuario y la modificacin de la informacin de registro. Adems, deben ya incluirse los puntos de inclusin y extensin para los casos de uso Validar Usuario, Ofrecer Servicios y Registrar Tarjeta, respectivamente. Se describe a continuacin las secciones iniciales del caso de uso, con las secciones restantes, subflujos y excepciones, ms adelante. Caso de Uso Actores Tipo Propsito Resumen Precondiciones Flujo Principal Registrar Usuario Usuario, Base de Datos Registros Bsico Permitir a un usuario registrarse con el sistema de reservaciones de vuelo para su uso posterior. Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, modificar y eliminar el registro de usuario con el sistema de reservaciones. Todos los subflujos, con excepcin de Crear Registro Usuario (S-1), requieren ejecutar inicialmente el caso de uso Validar Usuario. Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuar con los diversos subflujos de este caso de uso.

El diseo de la pantalla de registrarse por primera vez se muestra en la Figura 6.16.

Weitzenfeld: Captulo 6

16

Figura 6.16. Pantalla de Registro de Usuario por Primera Vez (P-3). El subflujo Crear Registro Usuario (S-1) es instanciado al presionar el botn correspondiente de la pantalla principal (P-1) descrito a continuacin. Subflujos S-1 Crear Registro Usuario Se presenta al usuario la Pantalla Crear Registro Usuario (P-3). Esta pantalla contiene informacin de registro que debe ser llenada por el usuario, lo cual incluye nombre, apellido, calle, colonia, ciudad, pas, cdigo postal, telfonos de la casa y oficina, nmero de fax, login, email, password y una entrada adicional de repetir password para asegurarse de su correccin. El login y el password sern utilizados por el sistema para validar al usuario. El usuario puede seleccionar entre las siguientes actividades: "Registrar " y "Salir". Si el usuario selecciona Registrar, el sistema genera un nuevo registro de usuario (E-1, E-2, E-3, E-4). Se contina con el subflujo Administrar Registro Usuario (S-3). Si la actividad seleccionada es "Salir" se saldr del sistema (si an no se ha presionado "Registrar", la informacin ser perdida).

En la Figura 6.17 se muestra el diseo de la pantalla para la modificacin de un registro existente. Ntese que la informacin que ofrece es exactamente igual a la anterior. La nica diferencia son las opciones que se ofrecen, eliminar y actualizar en lugar de registrar.

Weitzenfeld: Captulo 6

17

Figura 6.17. Pantalla de Obtener Registro (P-4). El resto de los subflujos se describen a continuacin. El subflujo Obtener Registro Usuario (S-2) es instanciado al presionar el botn correspondiente de la pantalla de servicios (P-2). El subflujo Administrar Registro Usuario (S-3) es instanciado una vez se presente la informacin correspondiente en la pantalla de registro (P-4). El subflujo Actualizar Registro Usuario (S-4) es instanciado al presionar el botn correspondiente de la pantalla de registro (P4). El subflujo Eliminar Registro Usuario (S-5) es instanciado al presionar el botn correspondiente de la pantalla de registro (P-4). Subflujos (cont) S-2 Obtener Registro Usuario El sistema obtiene el registro de usuario de la base de datos de registro. Se contina con el subflujo Administrar Registro Usuario (S-3). S-3 Administrar Registro Usuario Se presenta al usuario la Pantalla Obtener Registro Usuario (P-4) con la informacin de registro de usuario. El usuario podr seleccionar entra las siguientes actividades: "Eliminar", "Actualizar", "Registrar Tarjeta", "Servicios" y "Salir". Si el usuario presiona "Actualizar" se ejecuta el subflujo Actualizar Registro Usuario (S-4). Si el usuario selecciona "Eliminar" se ejecuta el subflujo Eliminar Registro Usuario (S-5). Si el usuario presiona "Registrar Tarjeta" se contina con el caso de uso Registrar Tarjeta. Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema (si an no se ha presionado "Actualizar", la nueva informacin ser perdida). S-4 Actualizar Registro Usuario Se actualiza el registro de usuario con la informacin modificada (E-1, E-3, E-4). Se contina con el subflujo Administrar Registro Usuario (S-3). S-5 Eliminar Registro Usuario Se elimina el registro de usuario y se contina con el subflujo Crear Registro Usuario (S-1).

Weitzenfeld: Captulo 6

18

Las excepciones del caso de uso son las siguientes. Excepciones E-1 informacin incompleta: Falta llenar informacin en el registro de usuario. Se vuelve a solicitar al usuario que complete el registro. E-2 registro ya existe: Si ya existe un registro bajo ese login, se solicitar al usuario que lo cambie o que termine el caso de uso. E-3 login incorrecto: El login no es vlido. Se le solicita al usuario que corrija el registro. E-4 contrasea incorrecta: La contrasea escogida es muy sencilla o no se valid correctamente. Se solicita al usuario que corrija el registro.

Registrar Tarjeta El caso de uso Registrar Tarjeta es una extensin del caso de uso Registrar Usuario. De manera similar a Registrar Usuario, el caso de uso Registrar Tarjeta est compuesto por un registro inicial y por la modificacin de la informacin ya registrada. Se describe a continuacin las secciones iniciales del caso de uso, con las secciones restantes, subflujos y excepciones, ms adelante. Ntese que el flujo principal es llamado al presionar Registrar Tarjeta en las pantallas de obtener registro de usuario (P-4). Caso de Uso Actores Tipo Propsito Resumen Registrar Tarjeta Usuario, Base de Datos Registros Extensin Permitir a un usuario registrar una tarjeta de crditos con el sistema de reservaciones de vuelo para poder pagar boletos. Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, modificar y eliminar el registro de tarjeta usuario para poder pagar las reservaciones directamente con el sistema de reservaciones. El usuario ya se debe haberse registrado mediante la activacin del caso de uso Registrar Usuario. Se contina con el subflujo Obtener Registro Tarjeta (S-2). Si no existe un registro de tarjeta vlido se contina con el subflujo Crear Registro Tarjeta (S-1). De lo contrario, si ya existe uno, se contina con el subflujo Administrar Registro Tarjeta (S-3).

Precondiciones Flujo Principal

El diseo de la pantalla para registrar la tarjeta por primera vez se muestra en la Figura 6.18.

Weitzenfeld: Captulo 6

19

Figura 6.18. Pantalla de Registro de Tarjeta por Primera Vez (P-5). El subflujo Registrar Tarjeta (S-1) es instanciado al presionar el botn correspondiente de la pantalla servicios (P-5) descrito a continuacin. Subflujos S-1 Crear Registro Tarjeta Se presenta la Pantalla Crear Registro Tarjeta (P-5). La pantalla incluye el nombre como aparece en la tarjeta, nmero de tarjeta, el tipo de tarjeta, y la fecha de vencimiento. El usuario puede seleccionar entre las actividades "Registrar", "Servicios", "Salir". Si el usuario presiona "Registrar", el sistema verifica la informacin (E-1), se contina con el sublflujo Administrar Registro Tarjeta (S-3). Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema (si an no se ha presionado "Registrar", la nueva informacin ser perdida).

En la Figura 6.19 se muestra el diseo de la pantalla para la modificacin de un registro de tarjeta existente. Ntese que la informacin que ofrece es exactamente igual a la anterior. La nica diferencia son las opciones que se ofrecen, eliminar y actualizar en lugar de registrar.

Weitzenfeld: Captulo 6

20

Figura 6.19. Pantalla de Registro de Tarjeta (P-6). El resto de los subflujos se describen a continuacin. Los subflujos Obtener Registro Tarjeta (S-2) y Administrar Registro Tarjeta (S-3) son utilizados para leer y manipular el registro de tarjeta, respectivamente. El subflujo Actualizar Registro Tarjeta (S-4) es instanciado presionando el botn correspondiente de la pantalla de registro (P6). El subflujo Eliminar Registro Tarjeta (S-5) es instanciado presionando el botn correspondiente de la pantalla de registro (P-6). Subflujos (cont) S-2 Obtener Registro Tarjeta El sistema obtiene el registro de tarjeta de la base de datos de registro. Se regresa al flujo anterior. S-3 Administrar Registro Tarjeta Se presenta la Pantalla Obtener Registro Tarjeta (P-6). La pantalla incluye el nombre como aparece en la tarjeta, nmero de tarjeta, el tipo de tarjeta, y la fecha de vencimiento. El usuario podr seleccionar entre las actividades "Eliminar", "Actualizar", Servicios y Salir. Si el usuario presiona Actualizar se ejecuta el subflujo Actualizar Registro Tarjeta (S-4). Si el usuario presiona Eliminar se ejecuta el subflujo Eliminar Registro Tarjeta (S-5). Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema. S-4 Actualizar Registro Tarjeta Se actualiza el registro de tarjeta con la informacin modificada (E-1). Se contina con el subflujo Administrar Registro Tarjeta (S-2). S-5 Eliminar Registro Tarjeta Se elimina el registro de tarjeta y se contina con el subflujo Crear Registro Tarjeta (S-1).

Las excepciones del caso de uso son las siguientes.

Weitzenfeld: Captulo 6

21

Excepciones

E-1 informacin incompleta: Falta llenar informacin indispensable para completar el registro de tarjeta. Se le vuelve a pedir al usuario que complete el registro de tarjeta.

Consultar Informacin El caso de uso Consultar Informacin es instanciado a partir de la pantalla de servicios (P-2) una vez se haya validado el usuario y haya seleccionado el botn correspondiente. Este caso de uso es el ms complejo de todos los del sistema ya que incluye tres tipos de consultas distintas: consulta de vuelos, consulta de tarifas y consulta de estado de un vuelo. El caso de uso se describe a continuacin, excluyendo los subflujos y excepciones que se describen ms adelante. Caso de Uso Actores Tipo Propsito Resumen Precondiciones Flujo Principal Consultar Informacin Usuario, Base de Datos Reservas Bsico Permitir a un usuario consultar informacin con el sistema de reservaciones de vuelo. Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para consultar informacin de horarios, tarifas y estado de vuelos con el sistema de reservaciones. Se requieren haber ejecutado anteriormente el caso de uso Validar Usuario. Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuar con los diversos subflujos de este caso de uso.

Antes de proseguir con la descripcin del caso de uso, mostramos la pantalla que permite tomar esta decisin, como se muestra en la Figura 6.20.

Figura 6.20. Pantalla de Seleccin de Tipo de Consulta (P-7). Dado que el usuario puede iniciar una consulta de varias pginas distintas, como se ver posteriormente, se incluye un primer subflujo para iniciar estas consultas llamado Consultar (S-1), como se muestra a continuacin.

Weitzenfeld: Captulo 6

22

Subflujos

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

En la Figura 6.21 se muestra el diseo de la pantalla para la consulta de horarios de vuelos, correspondiente al subflujo Consultar Horarios (S-2).

Figura 6.21. Pantalla de Consulta de Horarios de Vuelos (P-8). En la Figura 6.22 se muestra el diseo de la pantalla para el resultado de la consulta de horarios de vuelos, correspondiente al subflujo Devolver Horarios (S-3).

Weitzenfeld: Captulo 6

23

Figura 6.22. Pantalla de Resultado de Consulta de Horarios de Vuelos (P-9). Los subflujos Consultar Horarios (S-2) y Devolver Horarios (S-3) se muestran a continuacin. Subflujos S-2 Consultar Horarios Se presenta al usuario la Pantalla Consulta Horarios (P-8). Esta pantalla debe ser llenada con informacin de ciudad de origen y destino, y preferencias opcionales de: aerolnea, horario y una opcin de vuelo slo directo. El usuario puede seleccionar de las siguientes actividades: "Consultar", "Servicios" y "Salir". Si el usuario presiona Consultar, el sistema recibe la informacin (E-1,E-2), se contina con el subflujo Devolver Horarios (S-3). Si el usuario presiona Servicios, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir" se sale del sistema. S-3 Devolver Horarios Se presenta la Pantalla Resultado Horarios (P-9) conteniendo informacin sobre los diferentes vuelos encontrados. La informacin incluye la aerolnea, vuelo, das, horario, y restricciones, tales como fecha de inicializacin o terminacin del vuelo. Al principio de cada fila se encuentra una opcin de seleccin para obtener informacin adicional sobre el vuelo. El usuario puede seleccionar entre las siguientes opciones: +, "-", Nueva Consulta, "Servicios" y "Salir". Si el usuario presiona "+" se muestran resultados adicionales de horarios. Se contina al inicio de este subflujo. Si el usuario presiona "-" se muestran resultados anteriores de horarios. Se contina al inicio de este subflujo. Si el usuario presiona Nueva Consulta, se contina con el subflujo Consultar Horarios (S-2). Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir" se sale del sistema.

Weitzenfeld: Captulo 6

24

En la Figura 6.23 se muestra el diseo de la pantalla para la consulta de tarifas de vuelos, correspondiente al subflujo Consultar Tarifas (S-4).

Figura 6.23. Pantalla de Consulta de Tarifas de Vuelos (P-10). En la Figura 6.24 se muestra el diseo de la pantalla para el resultado de la consulta de tarifas de vuelos, correspondiente al subflujo Devolver Tarifas (S-5).

Weitzenfeld: Captulo 6

25

Figura 6.24. Pantalla de Resultado de Consulta de Tarifas de Vuelos (P-11). Los subflujos Consultar Tarifas (S-4) y Devolver Tarifas (S-5) se muestran a continuacin. Subflujos (cont) S-4 Consultar Tarifas Se presenta al usuario la Pantalla Consultar Tarifas (P-10). Esta pantalla debe ser llenada con informacin de ciudad de origen y destino, y preferencias opcionales: fecha de salida, fecha de regreso, aerolnea, clase, y las opciones de organizar la informacin por menor tarifa, una opcin de vuelo slo directo, y si la tarifa se basa en viaje redondo. El usuario puede seleccionar de las siguientes actividades: "Consultar", "Servicios" y "Salir". Si el usuario presiona Consultar, el sistema recibe la informacin (E-1,E-2), se contina con el subflujo Devolver Tarifas (S-5). Si el usuario presiona Servicios, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir" se sale del sistema. S-5 Devolver Tarifas Se presenta la Pantalla Resultado Tarifas (P-11) conteniendo informacin sobre los diferentes vuelos encontrados. La informacin incluye la aerolnea, vuelo, das, horario, tarifa ida e ida y vuelta y restricciones correspondientes. Al principio de cada fila se encuentra una opcin para seleccionar en caso de hacer consultas o reservas sobre los vuelos obtenidos. El usuario puede seleccionar entre las siguientes opciones: +, "-", "Nueva Consulta", "Servicios" y "Salir". Si el usuario presiona "+" se muestran resultados adicionales de horarios. Se contina al inicio de este subflujo. Si el usuario presiona "-" se muestran resultados anteriores de horarios. Se contina al inicio de este subflujo. Si el usuario presiona "Nueva Consulta" se continua con el subflujo Consultar Tarifas (S-4). Si el usuario presiona Servicios, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir" se sale del sistema.

Weitzenfeld: Captulo 6

26

En la Figura 6.25 se muestra el diseo de la pantalla para la consulta de estado de vuelo, correspondiente al subflujo Consultar Estado (S-6).

Figura 6.25. Pantalla de Consulta de Estado de Vuelo (P-12). En la Figura 6.26 se muestra el diseo de la pantalla para el resultado de la consulta de estado de vuelo, correspondiente al subflujo Devolver Estado (S-7).

Weitzenfeld: Captulo 6

27

Figura 6.26. Pantalla de Resultado de Consulta de Estado de Vuelo (P-13). Los subflujos de Consultar Estado (S-6) y Devolver Estado (S-7) se muestran a continuacin. Subflujos (cont) S-6 Consultar Estado Se presenta al usuario la Pantalla Consultar Estado (P-12). Esta pantalla debe ser llenada con informacin de ciudad de origen y destino, la aerolnea, el nmero de vuelo, y la opcin de vuelo de hoy. El usuario puede seleccionar de las siguientes actividades: "Consultar", "Servicios" y "Salir". Si el usuario presiona Consultar, el sistema recibe la informacin (E-1,E-2) y se contina con el subflujo Devolver Estado (S-7). Si el usuario presiona Servicios, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir" se sale del sistema. S-7 Devolver Estado Se presenta la Pantalla Resultado Estado (P-13) conteniendo informacin sobre los diferentes vuelos encontrados. La pantalla contiene informacin sobre el vuelo, incluyendo su estado, por ejemplo, confirmado, retrasado, cancelado. Al principio de cada fila se encuentra una opcin para seleccionar en caso de hacer consultas o reservas sobre los vuelos obtenidos. El usuario puede seleccionar entre las siguientes opciones: "Nueva Consulta", "Servicios" y "Salir". Si el usuario presiona Nueva Consulta, se contina con el subflujo Consultar Estado (S-6). Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir" se sale del sistema.

Las excepciones del caso de uso son las siguientes.

Weitzenfeld: Captulo 6

28

Excepciones

E-1 informacin incompleta: Falta llenar informacin indispensable, ciudad de origen o de destino. Se le vuelve a pedir al usuario la informacin. E-2 informacin invlida: Una de las entradas de la solicitud es incorrecta.

Hacer Reservacin El caso de uso Hacer Reservacin es instanciado a partir de la pantalla de servicios (P-2) una vez se haya validado el usuario y haya seleccionado el botn correspondiente. El caso de uso se describe a continuacin, excluyendo los subflujos y excepciones que se describen ms adelante. Caso de Uso Actores Tipo Propsito Resumen Precondiciones Flujo Principal Hacer Reservacin Usuario, Base de Datos Reservas Bsico Permitir a un usuario hacer reservaciones con el sistema de reservaciones de vuelo. Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, obtener, modificar y eliminar reservaciones de vuelos con el sistema de reservaciones. Se debe haber ejecutado anteriormente el caso de uso Validar Usuario. Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuar con los diversos subflujos de este caso de uso.

En la Figura 6.27 se muestra el diseo de la pantalla para crear u obtener una reservacin si se cuenta con una clave.

Figura 6.27. Pantalla de Insercin Clave de Reserva (P-14). El subflujo Solicitar Clave Reservacin (S-1) se muestra a continuacin.

Weitzenfeld: Captulo 6

29

Subflujos

S-1 Solicitar Clave Reservacin Se presenta al usuario la Pantalla Clave Reserva (P-14). El usuario puede seleccionar entre las siguientes actividades: "Crear", "Obtener", Servicios" y "Salir". Si el usuario presiona Crear se ejecutar el subflujo Crear Reservacin (S-2). Si el usuario presiona Obtener (E-1) se ejecuta el subflujo Obtener Reservacin (S-3). Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema.

En la Figura 6.28 se muestra el diseo de la pantalla para la solicitud de reserva de vuelos, utilizado por los distintos subflujos.

Figura 6.28. Pantalla de Solicitud de Reserva de Vuelos (P-15). En la Figura 6.29 se muestra el diseo de la pantalla para el rcord de reserva de vuelos, utilizado por los distintos subflujos.

Weitzenfeld: Captulo 6

30

Figura 6.29. Pantalla de Rcord de Reserva de Vuelos (P-16). Los dems subflujos se muestra a continuacin. Subflujos (cont) S-2 Crear Reservacin Se presenta la Pantalla Crear Reserva (P-15). Esta pantalla debe ser llenada con informacin de apellido y nombre del pasajero, un nmero de viajero frecuente opcional, aerolnea, nmero de vuelo, ciudad de origen y destino, fecha, clase, una opcin de solicitar asiento y si desea ventana o pasillo, y opcionalmente comida vegetal o carne. El usuario puede seleccionar entre las siguientes actividades: "Agregar", "Borrar", "+", "-, "Reservar", "Servicios" y "Salir". Si el usuario selecciona Agregar, el sistema agrega una nueva Pantalla Crear Reserva (P-15) para ser llenada por el usuario. Si el usuario selecciona Borrar, el sistema borra los datos recin insertados y se contina con la creacin de reservas. Si el usuario selecciona +, el sistema avanza a la siguiente pantalla de reservacin. Si el usuario selecciona -, el sistema retrocede a la pantalla anterior de reservacin. Si el usuario selecciona Reservar, el sistema acepta la solicitud (E-2,E-3), envindola a la base de datos del sistema de reservaciones (E-5), se continua con el subflujo Administrar Reservacin (S-3). Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema. S-3 Obtener Reservacin El sistema obtiene el rcord de reservacin de la base de datos de registro. Se contina con el subflujo Administrar Reservacin (S-4).

Weitzenfeld: Captulo 6

31

S-4 Administrar Reservacin Se presenta la Pantalla Record Reserva (P-16) con la opcin a modificar la informacin (E-1). El usuario puede seleccionar entre las siguientes selecciones: "Eliminar", "Actualizar", "+", "-", "Nueva Reserva", "Pagar", "Reembolsar", "Servicios" y "Salir". Si el usuario presiona Actualizar se ejecuta el subflujo Actualizar Reservacin (S-5). Si el usuario presiona Eliminar se ejecuta el subflujo Elimnar Reservacin (S-6). Si el usuario selecciona +, el sistema avanza a la siguiente pantalla de reservacin. Si el usuario selecciona -, el sistema retrocede a la pantalla anterior de reservacin. Si el usuario selecciona Nueva Reserva, se continua con el subflujo Crear Reservacin (S-2). Si el usuario selecciona Pagar, el sistema se contina con el caso de uso Pagar Reservacin. Si el usuario selecciona Reembolsar, el sistema se contina con el caso de uso Pagar Reservacin. Si la actividad seleccionada es "Servicios", se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se saldr del sistema. S-5 Actualizar Reservacin Se actualiza el rcord de reserva (E-2,E-3, E-4). Se continua con el subflujo Administrar Reservacin (S-3). S-6 Eliminar Reservacin Se elimina el rcord de reserva (E-5). Se continua con el subflujo Crear Reservacin (S-2). Las excepciones del caso de uso son las siguientes. Excepciones E-1 rcord invlido: No existe el rcord especificado. E-2 informacin incompleta: Falta llenar informacin indispensable, ciudad de origen o de destino. Se le vuelve a pedir al usuario la informacin. E-3 informacin invlida: Una de las entradas de la solicitud es incorrecta. E-4 reserva sin xito: No se logr obtener una reserva. E-5 eliminacin reserva sin xito: No se logr eliminar la reserva.

Pagar Reservacin El caso de uso Pagar Reservacin es instanciado a partir de la pantalla de reservaciones (P-14) una vez se haya seleccionado el botn correspondiente. El caso de uso se describe a continuacin, excluyendo los subflujos y excepciones que se describen ms adelante. Caso de Uso Actores Tipo Propsito Resumen Pagar Reservacin Usuario, Base de Datos Reservas Extensin Permitir a un usuario pagar reservaciones con el sistema de reservaciones de vuelo. Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para pagar y reembolsar pagos de reservaciones de vuelos con el sistema de reservaciones mediante tarjetas de crdito registradas con el sistema. Se requieren haber ejecutado anteriormente el caso de uso Validar Usuario y tener ya hecha una reserva mediante el caso de uso Hacer Reservacin. Se obtiene el registro de tarjeta ejecutando el caso de uso Registrar Tarjeta, subflujo Obtener Registro Tarjeta (S-2). Dependiendo si la solicitud original fue pagar, se contina con el subflujo Pagar Reservacin (S1), si fue reembolsar se contina con el subflujo Reembolsar Pago (S-2).

Precondiciones Flujo Principal

En la Figura 6.30 se muestra el diseo de la pantalla para el pago de reserva de vuelos, utilizado el subflujo Pagar Reservacin (S-1).

Weitzenfeld: Captulo 6

32

Figura 6.30. Pantalla de Pago de Reserva de Vuelos (P-17). El subflujo Pagar Reservacin (S-1) se muestra a continuacin. Subflujos S-1 Pagar Reservacin Se presenta al usuario la Pantalla Pagar Registro Tarjeta (P-17), la cual incluye informacin de nombre como aparece en la tarjeta, nmero de tarjeta, el tipo de tarjeta, la fecha de vencimiento y la cantidad a pagar (E-1). El Usuario podr seleccionar entre las siguientes actividades: "Pagar", "Servicios" y "Salir". Si la actividad seleccionada es "Pagar", el sistema utiliza los datos de la tarjeta registrada por el usuario y enva una pantalla de confirmacin al usuario (E-2). Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es Servicios, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se sale del sistema.

En la Figura 6.31 se muestra el diseo de la pantalla para el pago de reserva de vuelos, utilizado el subflujo Reembolsar Pago (S-2).

Weitzenfeld: Captulo 6

33

Figura 6.31. Pantalla de Reembolso de Reserva de Vuelos (P-18). El subflujo Reembolsar Pago (S-2) se muestra a continuacin. Subflujos (cont) S-2 Reembolsar Pago Se presenta al usuario la Pantalla Reembolsar Registro Tarjeta (P-18), la cual incluye informacin de nombre como aparece en la tarjeta, nmero de tarjeta, el tipo de tarjeta, la fecha de vencimiento y la cantidad a reembolsar (E-1). El Usuario podr seleccionar entre las siguientes actividades: "Reembolsar", "Servicios" y "Salir". Si la actividad seleccionada es "Reembolsar", el sistema utiliza los datos de la tarjeta registrada por el usuario y enva una pantalla de confirmacin al usuario (E-3, E-4). Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es Servicios, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir" se sale del sistema.

Las excepciones del caso de uso son las siguientes. Excepciones E-1 rcord invlido: No existe el rcord especificado. El usuario deber insertar los datos de la tarjeta. E-2 pago invlido: El pago no tuvo xito o la informacin de pago est incompleta. E-3 pago inexistente: La reserva no ha sido an pagada. E-4 reembolso invlido: No se pudo hacer el reembolso del pago.

6.5 Modelo del Dominio del Problema

El modelo del dominio del problema define un modelo de clases comn para todos los involucrados en el modelo de requisitos, analistas al igual que clientes. Este modelo de clases consiste de los objetos del dominio del problema, o

Weitzenfeld: Captulo 6

34

sea objetos que tienen una correspondencia directa en el rea de la aplicacin. Como los usuarios y clientes deberan reconocer todos los conceptos, se puede desarrollar una terminologa comn al razonar sobre los casos de uso, y por lo tanto disminuyendo la probabilidad de malos entendimientos entre el analista y el usuario. Al discutirlo, se evolucionar el modelo del dominio del problema. Una tcnica utilizada cuando se trabaja con tal modelo es darle al cliente un papel y un lpiz y pedirle que dibuje su visin del sistema. Histricamente, el modelo del dominio del problema se utilizaba como el modelo de requisitos fundamental en ciertas metodologas, tales como Coad y Yourdon (1991), Booch (1991), y Rumbaugh (1991). Sin embargo, dadas sus limitaciones que impeda obtener los requisitos funcionales de un sistema, el modelo del dominio del problema dej de ser la base nica para el desarrollo completo del sistema y pas a ser un elemento adicional en la especificacin de los sistemas, como en el modelo de casos de uso. El propsito principal del dominio del problema en el modelo de requisitos de nuestra metodologa es formar una base comn de entendimiento del desarrollo y no para definir el sistema completo. Por lo tanto, se pueden aprovechar algunas de las heursticas de los mtodos anteriores para la identificacin de los objetos en el dominio del problema, logrando un glosario o diccionario de clases que sirve como comn denominador a todos los componentes del sistema, incluyendo a las diversas personas involucradas a lo largo del desarrollo. A diferencia de los mtodos anteriores, el modelo del dominio del problema no debe ser demasiado extenso, ya que varios grados de refinamiento sern hechos posteriormente. Y aunque es suficiente describir el dominio del problema en trmino de objetos o clases, es posible refinar ms an mediante la inclusin de asociaciones, atributos, herencia y operaciones, siempre y cuando esto ayude a comprender mejor el problema y no se vuelva un esfuerzo demasiado grande durante esta etapa. Se debe tener cuidado con hacer demasiado trabajo temprano ya que esto puede incluso dificultar su modificacin posterior durante el modelo de anlisis. La experiencia muestra que muchos (si no todos) los objetos del dominio podrn aparecer durante el modelo de anlisis. Sin embargo, pueden haber cambios durante el modelo de anlisis, incluyendo la eliminacin de clase identificadas durante esta etapa, o incluso la incorporacin de clases adicionales. En esta seccin describiremos cmo identificar las clases del dominio del problema junto con aspectos adicionales, cmo asociaciones y atributos. Lo que definitivamente no se har aqu, y que era parte esencial de las metodologas anteriores, es identificar herencia y las operaciones durante esta etapa. La herencia y en especial las operaciones de un sistema son los aspectos de mayor complejidad, algo que nosotros elaboraremos de manera muy cuidadosa durante el diseo del sistema. Identificacin de Clases La identificacin de clases del dominio del problema se obtiene principalmente de algn documento textual que describa el sistema. Aunque pudiramos tomar como punto de partida los documentos desarrollados para el modelo de casos de uso, a menudo la descripcin original del problema es suficiente. Se comienza este proceso mediante la identificacin de las clases candidatas, explcitas o implcitas, a las que se refiera la descripcin del problema. Para ello se extraen todos los sustantivos de la descripcin del problema o de algn otro documento similar, de acuerdo a las siguientes consideraciones. ? ? Los sustantivos en la descripcin del problema son los posibles candidatos a clases de objetos. Por ejemplo en "Un sistema de reservaciones que vende boletos para funciones a varios teatros", las clases candidatas seran, Sistema de Reservaciones, Boletos, Funcin y Teatro. ? ? Durante esta etapa, se debe identificar entidades fsicas al igual que entidades conceptuales. ? ? No se debe tratar de diferenciar entre clases y atributos durante sta etapa. ? ? Dado que no todas las clases se describen de manera explcita, siendo algunas implcitas en la aplicacin, ser necesario aadir clases que pueden ser identificadas por nuestro conocimiento del rea. ? ? Se debe revisar los pronombres en la descripcin del problema para asegurar que no se haya perdido ningn sustantivo descrito de forma implcita. ? ? Para facilitar la identificacin de clases, se subrayan todos los sustantivos de la descripcin del problema. En el caso del sistema de reservaciones de vuelos, partimos de la descripcin del problema y subrayamos todos los sustantivos, como se ve a continuacin:

Weitzenfeld: Captulo 6

35

El Sistema de Reservaciones de Vuelos es un sistema que permite al usuario hacer consultas y reservas de vuelos, adems de poder comprar los boletos areos de forma remota, sin la necesidad de recurrir a un agente de viajes humano. Se desea que el sistema de reservaciones sea accesible a travs del Internet (World Wide Web). El sistema presenta en su pantalla principal un mensaje de bienvenida describiendo los servicios ofrecidos junto con la opcin para registrarse por primera vez, o si ya se est registrado, poder utilizar el sistema de reservaciones de vuelos. Este acceso se da por medio de la insercin de un login previamente especificado y un password previamente escogida y que debe validarse. Una vez registrado el usuario, y despus de haberse validado el registro y contrasea del usuario, se pueden seleccionar de las siguientes actividades: Consulta de vuelos Reserva de vuelos Compra de boletos La consulta de vuelos se puede hacer de tres maneras diferentes: Horarios de Vuelos Tarifas de Vuelos Estado de Vuelo La consulta segn horario muestra los horarios de las diferentes aerolneas dando servicio entre dos ciudades. La consulta segn tarifas muestra los diferentes vuelos entre dos ciudades dando prioridad a su costo. La informacin de vuelo se utiliza principalmente para consultar el estado de algn vuelo, incluyendo informacin de si existen asientos disponibles y de si, en el caso de un vuelo para el mismo da, si ste est en hora. Se puede incluir preferencias en las bsquedas, como fecha y horario deseado, categora de asiento, aerolnea deseada y si se desea slo vuelos directos. La reservacin de vuelo permite al cliente hacer una reserva para un vuelo particular, especificando la fecha y horario, bajo una tarifa establecida. Es posible reservar un itinerario compuesto de mltiples vuelos, para uno o ms pasajeros, adems de poder reservar asientos. El pago permite al cliente, dada una reserva de vuelo previa y una tarjeta de crdito vlida, adquirir los boletos areos. Los boletos sern posteriormente enviados al cliente, o estarn listos para ser recogidos en el mostrador del aeropuerto previo a la salida del primer vuelo. Es necesario estar previamente registrados con un nmero de tarjeta de crdito vlida para poder hacer compras de boletos, o de lo contrario proveerla en el momento de la compra. Adems de los servicios de vuelo, el usuario podr en cualquier momento accesar, modificar o cancelar su propio registro, todo esto despus de haber sido el usuario validado en el sistema. A partir de estos sustantivos se prepara una lista inicial de clases candidatas, como se muestra en la Tabla 6.1. Se debe excluir clases repetidas, manteniendo todos los nombres en singular. Clases Candidatas Login Email Password Registro Actividad Consulta de Vuelos Reserva de Vuelos Compra de Boletos

Sistema de Reservaciones de Vuelo Sistema Usuario Consulta Reserva Vuelo Boleto Areo Agente de Viajes Humano

Informacin Asiento Da Hora Preferencia Bsqueda Fecha Categora de Asiento

Weitzenfeld: Captulo 6

36

Vuelo Directo Horario de Vuelos Sistema de Reservaciones Cliente Tarifa de Vuelos Internet Itinerario Informacin de Vuelo World Wide Web Pasajero Horario Pantalla Principal Pago Aerolnea Mensaje de Bienvenida Tarjeta de Crdito Ciudad Servicios Boleto Tarifa Opcin Mostrador del Aeropuerto Costo Reservaciones de Vuelos Nmero de Tarjeta de Crdito Estado Acceso Tabla 6.1. Clases Candidatas para el sistema de reservaciones de vuelo identificadas de la descripcin del problema. Seleccin de Clases A partir de las clases candidatas, se debe seleccionar las clases relevantes tomando en cuenta los siguientes consideraciones: ? ? Todas las clases deben tener sentido en el rea de la aplicacin, la relevancia al problema debe ser el nico criterio para la seleccin. ? ? Como regla general, se debe escoger los nombres para las clases con cuidado, que no sean ambiguos y que mejor se apliquen al problema. Este es uno de los procesos ms difciles. Los nombres deben ser establecidos con un formato consistente (e.g. nombres en singular). ? ? No hay que preocuparse durante esta etapa sobre asociacin, agregacin, o herencia. Primero hay que tener las clases especficas correctas para no suprimir detalles en el intento de ajustarse a estructuras preconcebidas. ? ? Ante la duda, se deben conservar las clases, ya que posteriormente siempre habr oportunidad para eliminarlas. ? ? Se deben eliminar clases redundantes, si estas expresan la misma informacin. La clase ms descriptiva debe ser guardada. ? ? Se deben eliminar clases irrelevantes, que tienen poco o nada que ver con el problema. Esto requiere juicio porque en un contexto una clase puede ser importante mientras que en otro contexto la clase podra no serlo. ? ? Se deben clarificar las clases imprecisas. Algunas clases pueden tener bordes mal definidos o demasiado generales. ? ? Se deben eliminar las clases que debieran ser atributos ms que clases, cuando los nombres corresponden a propiedades ms que entidades independientes. ? ? Se deben eliminar las clases que debieran ser roles ms que clases, cuando los nombres corresponden al papel que juegan las clases ms que entidades independientes. ? ? Se deben eliminar las clases que debieran ser operaciones ms que clases, si las entidades representan operaciones que son aplicadas a los objetos y no entidades manipuladas por si mismas. ? ? Se deben eliminar las clases que corresponden a construcciones de implementacin si estn alejadas del mundo real, por lo cual deben ser eliminadas del anlisis. No se necesita una clase para representar una entidad fsica. Por ejemplo: subrutinas, listas, y arreglos, son clases tpicas de implementacin; Internet y World Wide Web son el medio de implementacin del sistema ? ? Se debe eliminar clases que correspondan aspectos de interfaces de usuario y no de la aplicacin. ? ? Se debe eliminar clases que correspondan a todo un sistema completo. ? ? Se debe eliminar clases que correspondan a actores del sistema. ? ? Se deben agregar clases implcitas que no aparezcan en la descripcin del problema. Tomaremos algunas de las clases candidatas del sistema de reservaciones de vuelo identificadas anteriormente y seleccionamos las que mejor se apliquen a nuestro problema, como se ve a continuacin: ?? ?? ?? Clases redundantes: Cliente y Usuario. Esta decisin puede ir para ambos lados de igual manera. En el caso del Sistema de Reservaciones, consideramos que Usuario es ms descriptivo por ser la persona que utilice el sistema y se guarda. Clases irrelevantes: Mostrador del Aeropuerto, Agente de Viajes Humano y Boleto Areo. Si el sistema generara o se refiriera a un boleto areo, esta clase se mantendra. Clases imprecisas: Sistema, Servicios, Actividad, Preferencia, Bsqueda, Informacin, Estado, Opcin, Acceso, Itinerario, son clases imprecisas. Durante la introduccin de herencia puede que sea necesario una clase para compartir aspectos comunes a ambas clases.

Weitzenfeld: Captulo 6

37

?? ?? ?? ?? ?? ??

Nombres de clases: Aeropuerto en lugar de Ciudad Clases que son atributos: Nmero de Tarjeta de Crdito es un atributo de Tarjeta de Crdito, Categora de Asiento (Asiento), Informacin de Vuelo (Vuelo), y Horario de Vuelo (Vuelo) Clases que son operaciones: Consulta, Pago, Reserva. Clases de interfaces de usuario: Mensaje de Bienvenida, Pantalla Principal. Clases del sistema completo: Sistema de Reservaciones. Clases actores: Cliente.

La Tabla 6.2 muestra las modificaciones a las clases candidatas originales.

Weitzenfeld: Captulo 6

38

Clases Candidatas Modificacin Eliminada (sistema completo) Sistema de Reservaciones de Vuelo Eliminada (imprecisa) Sistema Eliminada (actor) Usuario Eliminada (operacin) Consulta Eliminada (operacin) Reserva Vuelo Eliminada (irrelevante) Boleto Areo Eliminada (irrelevante) Agente de Viajes Humano Eliminada (sistema completo) Sistema de Reservaciones Eliminada (implementacin) Internet Eliminada (implementacin) World Wide Web Eliminada (interface) Hoja Principal Eliminada (interface) Mensaje de Bienvenida Eliminada (imprecisa) Servicios Eliminada (imprecisa) Opcin Renombrada: Reservacin Reservaciones de Vuelos Eliminada (imprecisa) Acceso Eliminada (atributo) Login Eliminada (atributo) Email Eliminada (atributo) Password Renombrada: RegistroUsuario Registro Eliminada (imprecisa) Actividad Eliminada (operacin) Consulta de Vuelos Eliminada (operacin) Reserva de Vuelos Eliminada (operacin) Pago de Boletos Eliminada (duplicada con Horario) Horario de Vuelos Eliminada (duplicada con Tarifa) Tarifa de Vuelos Eliminada (atributo) Informacin de Vuelo Horario Aerolnea Renombrada: Aeropuerto Ciudad Tarifa Eliminada (redundante) Costo Eliminada (imprecisa) Estado Eliminada (imprecisa) Informacin Asiento Eliminada (atributo) Da Eliminada (atributo) Hora Eliminada (imprecisa) Preferencia Eliminada (operacin) Bsqueda Eliminada (atributo) Fecha Eliminada (atributo) Categora de Asiento Eliminada (atributo) Vuelo Directo Eliminada (redundante y actor) Cliente Eliminada (imprecisa) Itinerario Pasajero Eliminada (operacin) Compra Renombrada: RegistroTarjeta Tarjeta de Crdito Eliminada (irrelevante) Boleto Eliminada (irrelevante) Mostrador del Aeropuerto Eliminada (atributo) Nmero de Tarjeta de Crdito Tabla 6.2. Clases Candidatas para el sistema de reservaciones de vuelo identificadas de la descripcin del problema. Las clases identificadas se muestran en la Tabla 6.3. Ntese que se agregaron dos nuevas clases, Avin y ViajeroFrecuente, que no aparecan en la descripcin del problema. Esto se hizo para lograr un dominio ms

Weitzenfeld: Captulo 6

39

completo. En general, distintos analistas identificarn listas similares de clases, aunque siempre con alguna variacin. Clases Identificadas Tarifa Asiento Pasajero RegistroTarjeta Avin ViajeroFrecuente Tabla 6.3 Clases identificadas para el sistema de reservaciones de vuelo.

Vuelo Reservacin RegistroUsuario Horario Aerolnea Aeropuerto

Diagrama de Clases Despus de haber identificado y seleccionado las clases, se debe construir el diagrama de clases para el dominio del problema. Este diagrama se muestra en la Figura 6.32 y puede ayudar a identificar clases adicionales, y servir de base para encontrar las atributos y asociaciones entre ellas.
Avin Tarifa Aeropuerto

Asiento Reservacin

Aerolnea

Vuelo

RegistroTarjeta

Horario

ViajeroFrecuente

Pasajero

RegistroUsuario Pasajero

Figura 6.32. Diagrama de clases identificadas para el sistema de reservaciones de vuelo. Aunque se puede parar aqu el proceso de desarrollo del dominio del problema, continuaremos con la identificacin de asociaciones y atributos para el sistema de reservaciones de vuelo. Identificacin de Asociaciones El proceso de identificacin de asociaciones es bastante similar al de identificacin de clases, slo que en lugar de sustantivos buscamos frases que relacionen sustantivos correspondientes a clases ya identificadas. Lamentablemente, hasta all llega la similitud, que se vuelve bastante difcil esta identificacin por lo restringido de la descripcin del problema. El documento de casos de uso tiende a ser mucho ms importante para la identificacin de estas frases. Dado que en nuestra metodologa las asociaciones y operaciones del sistema sern identificadas durante el modelo de diseo, aqu nos limitaremos a dar un pequeo ejemplo de la identificacin de asociaciones en base a nuestro conocimiento del dominio del problema. (En cierta manera escogimos como ejemplo el desarrollo de un sistema de reservaciones de vuelos por ser un dominio al cual la mayora de los lectores podrn fcilmente relacionarse.)

Weitzenfeld: Captulo 6

40

Diagrama de Clases con Asociaciones En lugar de tomar como punto de partida la descripcin del problema o los documentos de casos de uso, simplemente identificamos nuestras propias frases correspondientes al dominio del problema del sistema de reservaciones, como se muestran en la Tabla 6.4. Este proceso de identificacin es sencillo cuando el problema es muy limitado y el dominio es fcil de analizar. De lo contrario se requiere un proceso de identificacin mucho ms extenso como veremos en la etapa de diseo. Asociaciones Identificadas Un vuelo contiene reservaciones Un vuelo se dirige a un aeropuerto Un vuelo contiene tarifas Un vuelo se efecta en un avin Un vuelo contiene asientos Un vuelo pertenece a una aerolnea Un vuelo tiene un horario Un pasajero puede acumular millas como viajero frecuente Un pasajero efecta reservaciones Una reservacin requiere de un registro de tarjeta de crdito Un registro de tarjeta pertenece a un registro de usuario Tabla 6.4 Asociaciones identificadas para relacionar clases en el dominio del problema. Despus de haber identificado las asociaciones, se debe construir una versin del diagrama de clases que incluya estas asociaciones, como se muestra en la Figura 6.33.
Avin Tarifa Aeropuerto

Asiento Reservacin

Aerolnea

Vuelo RegistroTarjeta

Horario

ViajeroFrecuente

Pasajero

RegistroUsuario Pasajero

Figura 6.33. Diagrama de clases con asociaciones entre clases identificadas. Se omiten los nombres de las asociaciones. Diagrama de Clases con Roles Despus de haber hecho el diagrama de clases con asociaciones, se puede construir una versin del diagrama de clases incluyendo roles. Como se explic en el captulo 4, el nombre del rol describe el papel que juega una clase en la asociacin desde el punto de vista de la otra clase. Si hay una sola asociacin entre un par de clases, y el nombre de la clase describe adecuadamente su rol, se puede omitir los nombres de rol.

Weitzenfeld: Captulo 6

41

Para tal propsito, modificamos levemente las asociaciones identificadas anteriormente, como se muestran en la Tabla 6.5. Asociaciones Identificadas con Roles Un vuelo contiene reservaciones Un vuelo tiene un aeropuerto de destino Un vuelo tiene un aeropuerto de origen Un vuelo puede hacer en escalas en otros aeropuertos Un vuelo contiene tarifas de ida y vuelta Un vuelo contiene tarifas solamente de ida Un vuelo se efecta en un avin Un vuelo contiene asientos Un vuelo pertenece a una aerolnea Un vuelo tiene un horario de llegada Un vuelo tiene un horario de salida Un pasajero puede acumular millas como viajero frecuente Un pasajero efecta reservaciones Una reservacin requiere de un registro de tarjeta de crdito Un registro de tarjeta pertenece a un registro de usuario Un vuelo puede tener mltiples conexiones Tabla 6.5 Asociaciones identificadas con roles para relacionar clases en el dominio del problema. Se extiende el diagrama de clases con asociaciones para incluir roles, como se muestra en la Figura 6.34.
Avin Tarifa O/W Escalas Aeropuerto Origen

R/T

Destino

Asiento Reservacin

Aerolnea

Vuelo Conexin

RegistroTarjeta

Llegada Horario Salida

ViajeroFrecuente

Pasajero

RegistroUsuario Pasajero

Figura 6.34 Diagrama de clases con asociaciones y roles entre clases identificadas. Se omiten los nombres de las asociaciones. (O/W representa one way o solamente ida, mientras que R/T representa round trip o viaje redondo.) Diagrama de Clases con Multiplicidad Despus de haber hecho el diagrama de clases con asociaciones y roles, se puede construir una versin del diagrama de clases incluyendo multiplicidad. Se determina la multiplicidad para cada asociacin. Para tal propsito, modificamos levemente las asociaciones identificadas anteriormente, como se muestran en la Tabla 6.6. Ntese que la multiplicidad, al igual que las relaciones entre las clases, son bastante subjetivas pudiendo variar entre analistas. Dentro de esa subjetividad todas deben transmitir un dominio del problema similar.

Weitzenfeld: Captulo 6

42

Asociaciones Identificadas con Roles y Multiplicidad Un vuelo contiene mltiples reservaciones Una reservacin se relaciona con mltiples vuelos Un vuelo tiene un aeropuerto de destino Un vuelo tiene un aeropuerto de origen Un vuelo puede hacer escalas en mltiples aeropuertos Un vuelo contiene mltiples tarifas de ida y vuelta Un vuelo contiene mltiples tarifas solamente de ida Un vuelo se efecta en mltiples aviones (dependiendo del da) Mltiples vuelos se efectan en un mismo avin (en diferente momento) Un vuelo contiene mltiples asientos Un vuelo pertenece a una aerolnea Un vuelo tiene mltiples horarios de llegada (correspondiendo a diferentes destinos) Un vuelo tiene mltiples horarios de salida (correspondiendo a diferentes destinos) Un pasajero puede acumular millas en mltiples cuentas de viajero frecuente Un pasajero efecta mltiples reservaciones Mltiples pasajeros pueden pertenecer a una misma reservacin Mltiples reservaciones pueden requerir de un mismo registro de tarjeta de crdito Un registro de tarjeta pertenece a un registro de usuario Un vuelo puede tener mltiples conexiones Tabla 6.6 Asociaciones identificadas con roles y multiplicidad para relacionar clases en el dominio del problema. Se extiende el diagrama de clases con asociaciones y roles, para incluir multiplicidad, como se muestra en la Figura 6.35.
Avin * R/T Tarifa * ** O/W Escalas * 1* Aeropuerto Origen 1 1 Destino

Asiento * 1 * Aerolnea 1 Llegada * Horario * Salida * 1 1 Pasajero * 1 RegistroUsuario Pasajero 1 * 1 1 1 1 1 * Vuelo * 1 Conexin 1 1 1 1 1 * Reservacin * * 1 1 RegistroTarjeta 1

ViajeroFrecuente

Figura 6.35 Diagrama de clases con asociaciones, roles y multiplicidad entre clases identificadas. Se omiten los nombres de las asociaciones. Identificacin de Atributos De manera similar a asociaciones se puede determinar los atributos del dominio del problema. Este proceso tiene una complejidad similar al de identificacin de las asociaciones. Sin embargo, identificar atributos puede resultar hasta ms difcil de lograrlo a travs de un proceso de bsqueda a partir de la descripcin del problema e incluso del documento de casos de uso. En lugar de esto, simplemente identificamos nuestros propios atributos para las distintas clases identificadas para el dominio del problema del sistema de reservaciones, como se muestran en la Tabla 6.7.

Weitzenfeld: Captulo 6

43

Atributos Nmero Clave Nombre, Direccin, Colonia, Ciudad, Pas, Cdigo Postal, Telfono Casa, Telfono Oficina, Fax, Email, Login, Password Da, Hora Horario Nombre Aerolnea Nombre, Ciudad, Pas Aeropuerto Clase, Precio, Impuestos Tarifa Fila, Letra Asiento Nombre Pasajero Nombre, Nmero, Expedidor, Vencimiento RegistroTarjeta Fabricante, Modelo Avin Nmero, Aerolnea ViajeroFrecuente Tabla 6.7 Atributos identificados para las clases identificadas en el sistema de reservaciones de vuelo. Nuevamente, este proceso de identificacin es sencillo cuando el problema es muy limitado y el dominio es fcil de analizar. De lo contrario se requiere un proceso de identificacin mucho ms extenso como veremos en la etapa de diseo. No es necesario listar todos los atributos, solamente los atributos ms relevantes, omitiendo atributos menores. Diagrama de Clases con Atributos Se extiende el diagrama de clases con asociaciones, roles y multiplicidad, para incluir los atributos principales, como se muestra en la Figura 6.36.

Clases Vuelo Reservacin RegistroUsuario

Weitzenfeld: Captulo 6

44

Avin Fabricante Modelo * R/T Asiento Fila Letra * * 1 1 Aerolnea Nombre Vuelo * 1 Nmero 1 1 1 *

Tarifa Clase Precio Impuestos * O/W

Escalas

Aeropuerto Nombre * Ciudad * Pas 1 1 Origen Destino

1 1 1 * * Conexin

Reservacin * Clave * *

Llegada * Horario Da Hora Salida

1 RegistroTarjeta Nombre Nmero Expedidor Vencimiento Pasajero Nombre * 1

ViajeroFrecuente Nmero Aerolnea

1 RegistroUsuario Nombre Direccin Colonia Ciudad Pas Cdigo Postal Telfono Casa Telfono Oficina Fax Email Login Password

Figura 6.36 Diagrama de clases con asociaciones, roles, multiplicidad y atributos para clases identificadas. Se omiten los nombres de las asociaciones y slo se muestran los atributos ms relevantes. Diccionario de Clases El diccionario de clases o diccionario de datos describe textualmente las clases identificadas durante el modelo del dominio del problema. Este diccionario sirve como un glosario de trminos y se muestra a continuacin. ? ? Vuelo - Se denomina por medio de un nmero. El vuelo tiene como origen un aeropuerto en una ciudad y tiene como destino un aeropuerto de otra ciudad. Un vuelo puede tener mltiples escalas y mltiples vuelos se relacionan por medio de conexiones. El vuelo pertenece a una aerolnea y puede operar varios das a la semana teniendo un horario de salida y otro de llegada. ? ? Reservacin - Para poder tomar un vuelo es necesario contar con una reservacin previa, la cual debe pagarse antes de una fecha lmite, que puede ser el propio da del vuelo. Una reservacin puede hacerse para mltiples vuelos y mltiples pasajeros. La reservacin cuenta con una clave identificando un rcord de reservacin particular. ? ? RegistroUsuario - 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. ? ? Horario - El horario de un vuelo se determina por su hora de salida y hora de llegada durante los das que opera. ? ? Aerolnea - La aerolnea provee servicio de mltiples vuelos entre diferentes ciudades bajo diferentes horarios. La aerolnea se identifica por un nombre.

Weitzenfeld: Captulo 6

45

?? ?? ?? ?? ?? ?? ??

Aeropuerto - El aeropuerto sirve como origen, destino y escalas de un vuelo. El aeropuerto se encuentra en una ciudad de un pas determinado. Tarifa - Los diferentes vuelos tienen mltiples tarifas para compra de boleto, variando segn la clase de boleto, si son de ida o de ida y vuelta, y dependiendo de las diversas restricciones y ofertas existentes. Asiento - Una reservacin de vuelo puede incluir la asignacin de asiento, especificada mediante una fila y un nmero. El nmero de asientos disponibles en un vuelo particular dependen del tipo de avin que opere ese da. Pasajero - Para poder hacer una reservacin se requiere dar el nombre del pasajero. Varios pasajeros pueden aparecer bajo una sola reservacin. RegistroTarjeta - 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. Avin - Un vuelo en una fecha determinada se hace en un tipo de avin particular. El tipo de avin define la cantidad mxima de pasajeros que pueden viajar en ese vuelo para esa fecha. ViajeroFrecuente - El pasajero tiene la opcin de acumular millas para un vuelo particular si cuenta con una tarjeta de viajero frecuente para la aerolnea correspondiente.

6.6 Dominio del Problema para el Sistema de Reservaciones de Vuelos

El modelo del dominio del problema puede hacerse bastante complejo en el caso de sistema de gran tamao, para lo cual es necesario separar las clases en mdulos. De tal manera, el modelo completo se dividira en una coleccin de mdulos, donde cada mdulo es una agrupacin lgica de clases y sus asociaciones correspondientes. Para el sistema de reservaciones de vuelo podemos identificar dos mdulos principales para el dominio del problema de acuerdo a la relacin lgica entre las clases. Estos mdulo son Registro, conteniendo las clases que guardan informacin sobre el usuario del sistema y Servicios conteniendo las clases que guardan informacin sobre los vuelos, pasajeros y reservaciones. En otras palabras, las clases para el mdulo de registro se relacionan con la utilizacin del sistema ligados al actor Base de Datos de Registro, mientras que las clases para el mdulo de servicios se relacionan con el propio sistema de reservaciones ligados al actor Base de Datos de Reservaciones. La razn de separar en dos mdulos va muy de la mano con la existencia de estos dos actores secundarios, ya que al corresponder cada actor secundario a una base de datos, los mdulos afianzan esta correspondencia. Sin embargo, esto no tiene por qu ser realmente as, pudiendo existir un slo mdulo para una sistema con mltiples actores secundarios o incluso mltiples mdulos por cada actor secundario. A continuacin describimos los mdulos para el sistema de reservaciones de vuelo. Servicios En la Figura 6.37 se muestra las clases pertenecientes al mdulo de Servicios del sistema de reservaciones.

Weitzenfeld: Captulo 6

46

Avin Fabricante Modelo * R/T Asiento Fila Letra * * 1 1 Aerolnea Nombre Vuelo * 1 Nmero 1 1 1 *

Tarifa Clase Precio Impuestos * O/W

Escalas

Aeropuerto Nombre * Ciudad * Pas 1 1 Origen Destino

1 1 1 * * Conexin

Reservacin * Clave *

Llegada * Horario Da Hora Salida

ViajeroFrecuente Nmero Aerolnea

Pasajero Nombre

Figura 6.37 Diagrama de clases para el mdulo de Servicios del sistema de reservaciones de vuelo.

Registro En la Figura 6.38 se muestra las clases pertenecientes al mdulo de Registro del sistema de reservaciones.
RegistroTarjeta Nombre Nmero Expedidor Vencimiento 1

1 RegistroUsuario Nombre Direccin Colonia Ciudad Pas Cdigo Postal Telfono Casa Telfono Oficina Fax Email Login Password

Figura 6.38 Diagrama de clases para el mdulo de Registro del sistema de reservaciones de vuelo.

Weitzenfeld:Requisitos

10/11/2002

47

Weitzenfeld: Captulo 7

7 Modelo de Anlisis
Cuando ya se ha desarrollado y aceptado el modelo de requisitos se comienza el desarrollo del modelo de anlisis. El objetivo del modelo de anlisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos. Durante esta etapa no se considera el ambiente de implementacin, lo cual incluye al lenguaje de programacin, manejador de base de datos, distribucin o configuracin de hardware, etc. En otras palabras el anlisis pretende modelar el sistema bajo condiciones ideales, garantizando que la arquitectura de software resultante se suficientemente robusta y extensible para servir de base a la estructura lgica de la aplicacin pero sin consideraciones relativas al entorno de implementacin que es posible que cambien incluso radicalmente. Tarde o temprano el sistema tendr que ser adaptado a las condiciones de implementacin deseadas, algo que se har durante el diseo, cuando todas las consideraciones que han sido descartadas durante el anlisis sean consideradas. Es importante enfatizar que el modelo de anlisis no es una reflexin del dominio del problema sino una representacin de sta adaptada a la aplicacin particular. El modelo de anlisis genera una representacin conceptual del sistema, consistiendo de clases de objetos. Cada una de las clases de objetos contribuye de manera especial para lograr la robustez de la arquitectura, como se muestra conceptualmente en la Figura 7.1.

Descripcin del Problema Modelo de Interfaces

Modelo de Modelo del Casos de Uso Dominio del Problema Usuario Arquitectura General

Modelo de Requisitos Modelo de Anlisis Figura 7.1 El diagrama muestra conceptualmente el modelo de anlisis junto con la arquitectura general de objetos en relacin al modelo de requisitos anteriormente desarrollado.
Una cualidad importante entre los diferentes modelos es el de la rastreabilidad (traceability) entre un modelo y otro, el cual relacin sus distintos aspectos, tales como los objetos, sin importar el orden en que fueron desarrollados. Dado que la mayora de los sistemas sern modificados a lo largo de su vida, si estos cambios emanan de cambios en los requisitos o respuestas a problemas, es necesario saber qu efectos tendrn estos sobre etapas posteriores incluyendo el cdigo final. 7.1 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 bordes de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura. En trmino de las propias arquitecturas, stas se distinguen segn la organizacin de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensin de los objetos. Esta dimensin corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de bordes y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una sla dimensin.

Weitzenfeld: Captulo 7

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 bordes 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 le caso de los sistemas de informacin, uno de las tipos de arquitecturas mas importantes es la arquitectua MVC Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de desarrollo de de Smalltalk. Esta arquitectura se basa en tres dimensiones principales: Modelo (informacin), Vista (presentacin) y Control (comportamiento) como se muestra en la Figura 7.2.
Control (comportamiento)

Modelo (informacin)

Vista (presentacin)

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 bordes que se le presentan al usuario para el manejo de la informacin, donde por lo general pueden existir mltiples vistas sobre un mismo modelo. Tpicamente la informacin representa el dominio del problema y es almacenada en una base de datos. Por otro lado el control corresponde a la manipulacin de la informacin a travs de sus diversas presentaciones. Y aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la informacin es independiente de la propia informacin y de cmo esta se controla. Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el ms propenso a ser modificado, seguido de la vista y finalmente el modelo. En el modelo de anlisis descrito aqu utilizaremos como base la arquitectura MVC para capturar estos tres aspectos de la funcionalidad, como se muestra en la Figura 7.3. Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de requisitos. La razn de ser de las tres dimensiones del modelo de requisitos realmente se deriva para lograr una rastreabilidad con la arquitectura que se desarrollar en el modelo de anlisis.

Weitzenfeld: Captulo 7

Control (comportamiento)

Abstraccin (informacin)

Presentacin (bordes o interfaces)

Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de anlisis basado en el modelo de casos de uso. La arquitectura para el modelo de anlisis ser implementada mediante tres tipos o estereotipos de objetos como elementos bsicos de desarrollo como veremos a continuacin. Clases con Estereotipos El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos: ? ? El estereotipo entidad (entity en ingls)para objetos que guarden informacin sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta informacin tambin se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados. ? ? El estereotipo interface o borde (boundary en ingls) para objetos que implementen la presentacin o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no slo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar informacin sobre el registro de usuario. ? ? El estereotipo control (control en ingls) para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningn otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computacin y luego devolver el resultado a un objeto borde. 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 borde especfico. Ntese que no hay ninguna restriccin a los diferentes estereotipos que puedan utilizarse, no solamente las tres anteriores. La notacin de UML para un estereotipo se muestra en la Figura 7.4.
<<Estereotipo>> Nombre de la Clase

Figura 7.4 Diagrama de clase con estereotipo. Los tres estereotipos correspondientes a las tres dimensiones para la arquitectura del modelo de anlisis se muestra en la Figura 7.5.
<<Entidad>> Nombre de la Clase 1 <<Borde>> Nombre de la Clase 2 <<Control>> Nombre de la Clase 3

Figura 7.5 Diagrama de clase para los tres estereotipo. Los tres estereotipos se muestran como conos en la Figura 7.6. (Ntese que los estereotipos deben insertarse en ingls para que las herramientas CASE los reconozcan de tal manera.)

Weitzenfeld: Captulo 7

Nombre de la Clase 1

Nombre de la Clase 2

Nombre de la Clase 3

Figura 7.6 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.7.

Comportamiento

Informacin

Presentacin
Figura 7.7 Diagrama mostrando traslape en los estereotipos de los objetos. Clases para Casos de Uso Cuando se trabaja en el desarrollo del modelo de anlisis, normalmente se trabaja con un caso de uso a la vez. Para cada caso de uso se identifican los objetos necesarios para su implementacin. Se identifican estos objetos segn sus estereotipos para corresponder a la funcionalidad ofrecida en cada caso de uso. Se define explcitamente qu objeto es responsable de cual comportamiento dentro del caso de uso. Tpicamente se toma un caso de uso y se comienza identificando los objetos borde 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.8.

Weitzenfeld: Captulo 7

objeto borde

objeto entidad

objeto control

Figura 7.8 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 borde. ? ? 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 borde 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. En las siguientes secciones identificamos las clases segn sus estereotipos. El desafo para principal en dicho proceso es decidir cuantas y cuales clases deben deben asignarse por caso de uso. 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 borde, 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 borde 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 bordes. Cambios a las bordes deben afectar tpicamente solo los objetos borde. 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. Borde Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema se ubica en los objetos de borde. Es a travs de estos objetos que se comunican los actores con el sistema. La tarea de un clase borde 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 borde, en otras palabras, describen comunicacin bidireccional entre el sistema y los actores. Las clases borde son bastante fciles de identificar, donde se cuenta con al menos tres estrategias: 1. Se pueden identificar en base a los actores.

Weitzenfeld: Captulo 7

Se pueden identificar en base a las descripciones de las borde 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 los bordes. Comenzaremos utilizando la primera estrategia correspondiente a de actores. Cada actor concreto necesita su propia clase borde para su comunicacin con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno ya que deben saber de la existencia de los dems para poder resolver ciertas tareas. Por ejemplo para Reservar un Asiento en un Vuelo el usuario debe interactuar con las clases borde que a su vez se comunican con las clases borde que se comunican con la base de datos del sistema de reservaciones. Una vez identificado los objetos borde es ms fcil modificar posteriormente las clases borde de un sistema. Al tener todo lo relacionado a una clase borde en un objeto, cada cambio a la borde ser local a ese objeto. Como los cambios a las bordes son muy comunes, es vital que estos sean extensibles. Existen dos tipos diferentes de bordes a modelar, bordes a otros sistemas e bordes a los usuarios humanos. ? ? En el caso de objetos borde que se comunican con otros sistemas, es muy comn que la comunicacin se describa mediante protocolos de comunicacin. Los objetos borde 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 borde. Un mayor problema ocurre cuando existen seales continuas del mundo externo, como en los sistemas de medicin o control. Entonces los objetos borde 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 borde deben entonces traducir la informacin continua a informacin discreta. Problemas de cuantificacin pueden aparecer y deben ser resueltos. ? ? En el caso de los objetos borde que se comunican con usuarios humanos, los objetos borde pueden ser complejos para modelar. Existen muchas tcnicas diferentes para un buen diseo de bordes, 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 borde 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 borde tienen como propsito principal las presentaciones. Sin embargo, tambin pueden manejar informacin y tener comportamiento. Cunta informacin y comportamiento debe ligarse a un objeto borde debe decidirse de manera individual. En un extremo, el objeto borde 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 borde es muy complejo donde la informacin se integra en el objeto borde 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 borde particular. Cualquier cambio en la funcionalidad directamente ligada a la borde debe ser local al objeto borde, 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 borde, 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 borde particular. En el ejemplo del sistema de reservaciones de vuelo, cada uno de los actores concretos, Cliente, Base de Datos de Registro y Base de Datos de Reserva, necesita su propio objeto borde al sistema, como se muestra en la Figura 7.9. El Usuario necesita de las pantallas de presentacin, mientras que la Base de Datos de Registro y Base de Datos de Reservas necesitan sus propias bordes para poder intercambiar informacin con el sistema.

2.

Weitzenfeld: Captulo 7

Interface BaseDatos Registro Interface Usuario Usuario

Base de Datos Registros

Interface BaseDatos Reserva

Base de Datos Reservas

Figura 7.9 Clases borde para el sistema de reservaciones de vuelo identificados directamente de los actores. Aunque estas tres clases borde son suficiente para interactuar con los actores, necesitamos incluir un nmero de clases borde 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 bordes adicionales necesarias para manejos ms especializados de las bases de datos, algo que postergaremos hasta el diseo. A continuacin describimos las clases borde 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 con las cuales los casos de uso se relacionan. Ntese que a pesar de que existen mltiples ligas entres pantallas 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. ? ? Validar Usuario: Se interacta con los actores Usuario y Base de Datos Registros a travs de las clases borde InterfaceUsuario e InterfaceBaseDatosRegistro, respectivamente. Se utiliza nicamente la pantalla principal del sistema (P-1) para la validacin de usuario. Por lo tanto se incluye nicamente la clase borde PantallaPrincipal adems de las dos anteriores. Recurdese que pantallas adicionales como las de mensajes o error no las estamos considerando an para nuestro prototipo. En la Figura 7.12 se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario

InterfaceBaseDatosRegistro

PantallaPrincipal

??

Figura 7.12 Clases borde identificadas del caso uso Validar Usuario. Ofrecer Servicios: Este caso de uso utiliza nicamente la pantalla de servicios del sistema (P-2). Por lo tanto se incluye nicamente la clase borde PantallaServicio. Dado que se interacta con el actor Usuario se incluye tambin la clase borde InterfaceUsuario. En la Figura 7.13 se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario

PantallaServicio

??

Figura 7.13 Clases borde identificadas del caso uso Ofrecer Servicios. Registrar Usuario: Se interacta con los actores Usuario y Base de Datos Registros a travs de las clases borde InterfaceUsuario e InterfaceBaseDatosRegistro, respectivamente. Adicionalmente se deben incluir clases borde 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 borde correspondientes las llamaremos

Weitzenfeld: Captulo 7

PantallaCrearRegUsuario y PantallaObtenerRegUsuario, respectivamente. Aunque la funcionalidad comienza en la pantalla principal del sistema (P-1) durante la validacin de un usuario, esta validacin se hace a travs del caso de uso Validar Usuario, por lo cual esta funcionalidad no es incluida como parte de este caso de uso. En la Figura 7.14 se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario

InterfaceBaseDatosRegistro

PantallaCrearRegUsuario

PantallaObtenerRegUsuario

??

Figura 7.14 Clases borde identificadas del caso uso Registrar Usuario. Registrar Tarjeta: Se interacta con los actores Usuario y Base de Datos Registros a travs de las clases borde 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 borde correspondientes las llamaremos PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta, respectivamente. En la Figura 7.15 se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario 1

InterfaceBaseDatosRegistro

PantallaCrearRegTarjeta

PantallaObtenerRegTarjeta

??

Figura 7.15 Clases borde identificadas del caso uso Registrar Tarjeta. Consultar Informacin: Se interacta con los actores Usuario y Base de Datos Reservas a travs de las clases borde InterfaceUsuario e InterfaceBaseDatosReserva, respectivamente. Adicionalmente se deben incluir clases borde 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 borde correspondientes las llamaremos PantallaConsultas, PantallaConsultaHorarios, PantallaResultadoHorarios, PantallaConsultaTarifas, PantallaResultadoTarifas, PantallaConsultaEstado y PantallaResultadoEstado, respectivamente. En la Figura 7.16 se muestran las clases borde identificadas en este caso de uso.

Weitzenfeld: Captulo 7

InterfaceUsuario

PantallaConsultas

InterfaceBaseDatosReservas

PantallaConsultaHorarios

PantallaResultadoHorarios

PantallaConsultaTarifas

PantallaResultadoTarifas

PantallaConsultaEstado

PantallaResultadoEstado

??

Figura 7.16 Clases borde identificadas del caso uso Consultar Informacin. Hacer Reservacin: Se interacta con los actores Usuario y Base de Datos Reservas a travs de las clases borde InterfaceUsuario e InterfaceBaseDatosReserva, respectivamente. Adicionalmente se deben incluir clases borde 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 borde correspondientes las llamaremos PantallaClaveReservas, PantallaCrearReservaVuelos y PantallaRecordReservaVuelos, respectivamente. En la Figura 7.17 se muestran las clases borde identificadas en este caso de uso.

InterfaceUsuario

InterfaceBaseDatosReservas

PantallaCrearReservaVuelos

PantallaClaveReservas

PantallaRecordReservaVuelos

??

Figura 7.16 Clases borde identificadas del caso uso Hacer Reservacin. Pagar Reservacin: Se interacta con los actores Usuario y Base de Datos Reservas a travs de las clases borde InterfaceUsuario e InterfaceBaseDatosReservas, respectivamente. Se utilizan las pantallas de pago de reserva de vuelos (P-17) y reembolso de reserva de vuelos (P-18). A las dos clases borde correspondientes las llamaremos PantallaPagarRegTarjeta y PantallaReembolsarRegTarjeta, respectivamente. En la Figura 7.18 se muestran las clases borde identificadas en este caso de uso.

Weitzenfeld: Captulo 7

10

InterfaceUsuario 1

InterfaceBaseDatosReservas

PantallaPagarRegTarjeta

PantallaReembolsarRegTarjeta

Figura 7.18 Clases borde 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 borde correspondientes. Caso de Uso Validar Usuario Ofrecer Servicios Registrar Usuario Registrar Tarjeta Consultar Informacin Actores Usuario, Base de Datos Registros Usuario Usuario, Base de Datos Registros Usuario, Base de Datos Registros Usuario, Base de Datos Reservas Clases Borde InterfaceUsuario, PantallaPrincipal, InterfaceBaseDatosRegistro InterfaceUsuario, PantallaServicio

InterfaceUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, InterfaceBaseDatosRegistro InterfaceUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta, InterfaceBaseDatosRegistro InterfaceUsuario, PantallaConsultas, PantallaConsultaHorarios, PantallaResultadoHorarios, PantallaConsultaTarifas, PantallaResultadoTarifas, PantallaConsultaEstado, PantallaResultadoEstado, InterfaceBaseDatosReserva Hacer Usuario, Base de Datos InterfaceUsuario, PantallaClaveReservas, Reservacin Reservas PantallaCrearReservaVuelos, PantallaRecordReservaVuelos, InterfaceBaseDatosReserva Pagar Usuario, Base de Datos InterfaceUsuario, PantallaPagarRegTarjeta, Reservacin Reservas PantallaReembolsarRegTarjeta, InterfaceBaseDatosReserva Tabla 7.1 Relacin entre casos de uso, actores y clases borde para el sistema de reservaciones de vuelo. Entidad Se utilizan objetos entidad para modelar la informacin que el sistema debe manejar a corto y largo plazo. La informacin a corto plazo existe por lo general durante la ejecucin del caso de uso, mientras que la informacin a largo plazo sobrevive a los casos de uso, por lo cual es necesario guardar esta informacin en alguna base de datos. Adicionalmente, se debe incluir comportamiento para manejar la propia informacin local al objeto entidad. Los objetos entidad se identifican en los casos de uso, donde la mayora se identifican del modelo del dominio del problema en el modelo de requisitos. Objetos entidad adicionales pueden ser mas difciles de encontrar. Es muy comn que se identifiquen muchos objetos entidad, aunque se debe limitar estos objetos a los realmente necesarios para la aplicacin, siendo esto lo ms difcil del proceso de identificacin. Es por lo tanto esencial trabajar de forma organizada cuando se modelan los objetos entidad. Las necesidades de los casos de uso deben ser las guas y solamente aquellos objetos entidad que puedan justificarse de la descripcin del caso de uso deben ser incluidos. No es siempre fcil decidir cuando cierta informacin debe ser modelada como un objeto entidad o como un atributo. Esto depende de cmo se usar la informacin, si sta se maneja de forma separada, debe modelarse como un objeto entidad, mientras que la informacin que esta acoplada fuertemente a alguna otra informacin y nunca se usa por si misma debe modelarse como un atributo de un objeto entidad. Todo depende de cmo los casos de uso manejen la informacin. Cierta informacin puede modelarse como objeto entidad en un sistema, mientras que en otro sistema puede ser un atributo. Es tambin difcil identificar qu operaciones y cuales atributos sern incluidos dentro de los objetos entidad. Dado que la nica forma para manipular un objeto entidad es por medio de sus operaciones, las operaciones identificadas deben ser suficientes para manipular completamente al objeto entidad. La descripcin detallada de los casos de uso es de nuevo un medio extremadamente valioso para encontrar las operaciones deseadas. El flujo

Weitzenfeld: Captulo 7

11

completo de eventos que se describe en los casos de uso, permite extraer las operaciones que conciernen a los objetos entidad. Las operaciones asignadas a los objetos entidad pueden ser ms o menos complejas. En el caso menos complejo un objeto entidad consta slo de operaciones de acceso a los valores de los atributos. En el caso ms complejo un objeto entidad puede tener flujos de eventos ms all de simples accesos a los valores de los atributos. Sea cual sea la complejidad de estas operaciones, el objetivo es que stas slo dependan y afecten informacin local. La siguiente es una lista de las operaciones tpicas que deben ser ofrecidas por un objeto entidad: ? ? Guardar y traer informacin ? ? Comportamiento que debe modificarse si el objeto entidad cambia ? ? Crear y remover el objeto entidad Dada la complejidad de obtener operaciones, esto es un aspecto que se deja para la etapa de diseo, como se mencion anteriormente. Durante la identificacin de objetos entidad, se encontrar que objetos similares aparecen en varios casos de uso. En tales circunstancias se debe verificar si deben ser los mismos objetos entidad o si deben haber objetos entidad separados. Incluso si los casos de uso no interactuan de la misma manera sobre los objetos, el objeto entidad puede ofrecer operaciones que satisfagan las necesidades de diversos casos de uso. Si se considera que dos objetos entidad representan un mismo objeto, las operaciones, atributos y asociaciones tambin tienen que integrarse. De manera similar, se puede hacer una identificacin preliminar de los atributos, sin embargo estos se desarrollarn ms ampliamente durante el modelo de diseo. A continuacin describimos las clases entidad necesarias para cada caso de uso de acuerdo a la documentacin generada durante el modelo de requisitos del captulo anterior. Ntese que las clases son obtenidas del dominio del problema generado en el modelo de requisitos. Si fueran necesarias nuevas clases entidad habra que modificar el dominio del problema anterior. ? ? Validar Usuario: Este caso de uso requiere validar informacin exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad RegistroUsuario, utilizada tambin por el caso de uso RegistrarUsuario. En la Figura 7.19 se muestran las clases entidad identificadas en este caso de uso.

RegistroUsuario

?? ??

Figura 7.19 Clases entidad identificadas del caso uso Validar Usuario. Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad. Registrar Usuario: Este caso de uso requiere guardar informacin exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario. En la Figura 7.20 se muestran las clases entidad identificadas en este caso de uso.

RegistroUsuario

??

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

RegistroTarjeta

??

Figura 7.21 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

Weitzenfeld: Captulo 7

12

manera tenemos las clases entidad Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo y Horario. En la Figura 7.22 se muestran las clases entidad identificadas en este caso de uso.

Asiento

Avin

Tarifa

Aeropuerto

Aerolnea

Vuelo

Horario

??

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

Asiento

Avin

Tarifa

Aeropuerto

Aerolnea

Vuelo

Horario

ViajeroFrecuente

Pasajero

Reservacin

??

Figura 7.23 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 entidad Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero, Reservacin y RegistroTarjeta. En la Figura 7.24 se muestran las clases entidad identificadas en este caso de uso.

Weitzenfeld: Captulo 7

13

Asiento

Avin

Tarifa

Aeropuerto

Aerolnea

Vuelo

Horario

ViajeroFrecuente

Pasajero

Reservacin

RegistroTarjeta

Figura 7.24 Clases entidad identificadas del caso uso Pagar Reservacin. En la Tabla 7.2 se muestran el resumen de los casos de uso identificados durante el modelo de requisitos junto con clases entidad correspondientes. Caso de Uso Validar Usuario Ofrecer Servicios Registrar Usuario Registrar Tarjeta Consultar Informacin Hacer Reservacin Clases Entidad RegistroUsuario

RegistroUsuario RegistroTarjeta Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero, Reservacin Pagar Reservacin Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero, Reservacin, RegistroTarjeta Tabla 7.2 Relacin entre casos de uso y clases entidad para el sistema de reservaciones de vuelo. Control Hasta ahora se han identificado partido objetos borde y entidad a partir de cada caso de uso. En algunas situaciones todo un caso de uso pudiera implementarse exclusivamente mediante estos dos tipos de objetos. De tal manera no se necesitara ningn objeto control para el respectivo caso de uso. Sin embargo, en la mayora de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos, ya que realmente no pertenece de manera natural a ninguno de ellos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, como lo sugieren algunos mtodos, pero la solucin no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podra afectar varios objetos dificultando la su modificacin. Por lo tanto, para evitar estos problemas tal comportamiento se asigna en objetos control. Sin embargo, es difcil lograr un buen balance en la asignacin del comportamiento entre los objetos entidad, borde 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 borde y entidad para cada caso de uso, el comportamiento restante se asigna a los objetos control. A menudo un

Weitzenfeld: Captulo 7

14

manera de asignar el comportamiento es modelar inicialmente el caso de uso sin ningn objeto control, o sea slo utilizar objetos borde 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 borde, 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 borde 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. ? ? Validar Usuario: Este caso de uso requiere un controlador para manejar 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 utilizamo la clase control ManejadorRegistroUsuario. En la Figura 7.25 se muestra la clase control para este caso de uso.

ManejadorRegistroUsuario

??

Figura 7.25 Clase control para el caso uso Validar Usuario. Ofrecer Servicios: Este caso de uso requiere un controlador para administrar los aspectos generales de los sevicios. Como enfoque inicial utilizar utilizaremos una clase general de control que llamaremos ManejadorServicio. En la Figura 7.26 se muestra la clase control para este caso de uso.

ManejadorServicio

??

Figura 7.26 Clase control para el caso uso Ofrecer Servicios. Registrar Usuario: Este caso de uso requiere de un controlador para manejar la informacin, lo que haremos mediante la clase control ManejadorRegistroUsuario. En la Figura 7.27 se muestra la clase control para este caso de uso.

ManejadorRegistroUsuario

??

Figura 7.27 Clase control para el caso uso Registrar Usuario. Registrar Tarjeta: Este caso de uso requiere una clase controladora para administrar el registro de la tarjeta del usuario, lo que haremos mediante la clase control ManejadorRegistroTarjeta. En la Figura 7.28 se muestra la clase control para este caso de uso.

ManejadorRegistroTarjeta

??

Figura 7.28 Clase control para el caso uso Registrar Tarjeta. Consultar Informacin: Este caso de uso requiere de un controlador para manejar la informacin y las bordes relacionadas con las consultas, lo que se hace en la clase control ManejadorConsultas. Dado que se tiene tres tipos de consultas distintas, podemos incluir tres controladores especializados, ManejadorConsultaHorarios,

Weitzenfeld: Captulo 7

15

ManejadorConsultaTarifas y ManejadorConsultaEstado, para las consultas respectivas. En la Figura 7.29 se muestran las clases control identificadas en este caso de uso.

ManejadorConsultas

ManejadorConsultaHorario ManejadorConsultaTarifas

ManejadorConsultaEstado

??

Figura 7.29 Clases control para el caso uso Consultar Informacin. Hacer Reservacin: Este caso de uso requiere de un controlador para manejar lo relacionado con las reservas, lo que se hace mediante la clase control ManejadorReservas. En la Figura 7.30 se muestra la clase control para este caso de uso.

ManejadorReservas

??

Figura 7.30 Clase control para el caso uso Hacer Reservacin. Pagar Reservacin: Este caso de uso requiere administrar lo relacionado con los pagos, lo que se haremos mediante la clase control ManejadorPagos. En la Figura 7.31 se muestran la clase control para en este caso de uso.

ManejadorPagos

Figura 7.31 Clase control para el caso uso Pagar Reservacin. Adicionalmente, por lo general es siempre bueno incluir un controlador principal para administrar los aspectos generales del sistema, incluyendo la pantalla principal. A esta clase la llamaremos ManejadorPrincipal, la cual se muestra en la Figura 7.32.

ManejadorPrincipal

Figura 7.32 Clase control para el sistema completo. En la Tabla 7.3 se muestran el resumen de los casos de uso identificados durante el modelo de requisitos junto con clases control correspondientes. Caso de Uso Validar Usuario Ofrecer Servicios Registrar Usuario Registrar Tarjeta Consultar Informacin Clases Control ManejadorRegistroUsuario ManejadorServicio ManejadorRegistroUsuario ManejadorRegistroTarjeta ManejadorConsultas, ManejadorConsultaHorarios, ManejadorConsultaTarifas, ManejadorConsultaEstado Hacer Reservacin ManejadorReservas Pagar Reservacin ManejadorPagos ManejadorPrincipal Tabla 7.3 Relacin entre casos de uso y clases control para el sistema de reservaciones de vuelo. 7.3 Clases segn Casos de Uso En esta seccin mostramos un diagrama de clases para cada caso de uso de acuerdo a las clases identificadas en la seccin anterior. En estos diagramas incluiremos de manera preliminar asociaciones y multiplicidad. Para simplificar este proceso de asignacin de asociaciones y para ser consistentes entre diagramas, asignaremos a la clase control de cada caso de uso como el centro de las comunicaciones para todas las clases borde y entidad

Weitzenfeld: Captulo 7

16

pertenecientes al mismo caso de uso. Estas clases borde y entidad no estarn asociadas entre si por el momento. Asimismo asociaremos entre si a las clases control utilizadas en el caso de uso. Y finalmente se asociarn todas las clases borde correspondiente a pantallas con la clase InterfaceUsuario. Ntese que slo se incluyen las clases borde correspondientes a pantallas que se consideren esenciales para el caso de uso, en otras palabras aquellas que implementan los flujos principales pero no tanto ligas adicionales de navegacin entre pantallas. En relacin a la multiplicidad, asignaremos todas las asociaciones como de uno-uno con excepcin de las relaciones entre clases entidades que se mantendrn de acuerdo al dominio del problema y entre clases control y clases entidad donde por lo general ser uno-muchos. La razn para esto es que tpicamente slo se requiere una instancia de cada clase control e borde para implementar el caso de uso, mientras que las clases entidad se instancian mltiples veces ya que corresponden a diversas instancias de informacin, como por ejemplo, mltiples usuarios. Como veremos en la seccin de diagramas de interaccin ms adelante en el captulo, a partir de estas relaciones estamos forjando la lgica de control del caso de uso. En las siguientes secciones veremos estos casos con mayor detalle. Validar Usuario El caso de uso Validar Usuario involucra una clase control ManejadorRegistroUsuario que es encargada de controlar la informacin de RegistroUsuario y las clases borde InterfaceUsuario e InterfaceBaseDatosRegistro. Agregamos tambin la clase PantallaPrincipal por recibir la informacin de registro a ser validada y al ManejadorPrincipal por ser el controlador de la pantalla anterior. En la Figura 7.33 se muestran las clases identificadas en este caso de uso.

InterfaceUsuario

PantallaPrincipal

ManejadorPrincipal

InterfaceBaseDatosRegistro

ManejadorRegistroUsuario

RegistroUsuario

Figura 7.33 Clases identificadas para el caso uso Validar Usuario. Ofrecer Servicios El caso de uso Ofrecer Servicios involucra una clase control ManejadorServicio que es encargada de controlar la pantalla PantallaServicio. Agregamos tambin la clase borde InterfaceUsuario. En la Figura 7.34 se muestran las clases identificadas en este caso de uso.

InterfaceUsuario

PantallaServicio

ManejadorServicio

Figura 7.34 Clases identificadas para el caso uso Ofrecer Servicios. Registrar Usuario El caso de uso Registrar Usuario involucra una clase control ManejadorRegistroUsuario que es encargada de controlar la informacin de RegistroUsuario y las clases borde correspondiente a las pantallas PantallaCrearRegUsuario y PantallaObtenerRegistroUsuario, adems de las clases borde InterfaceUsuario e InterfaceBaseDatosRegistro. En la Figura 7.35 se muestran las clases identificadas en este caso de uso.

Weitzenfeld: Captulo 7

17

InterfaceUsuario

PantallaCrearRegUsuario

PantallaObtenerRegUsuario

InterfaceBaseDatosRegistro

ManejadorRegistroUsuario

RegistroUsuario

Figura 7.35 Clases identificadas para el caso uso Registrar Usuario. Registrar Tarjeta El caso de uso Registrar Tarjeta involucra una clase control ManejadorRegistroTarjeta que es encargada de controlar la informacin de RegistroTarjeta y las clases borde correspondiente a las pantallas PantallaCrearRegTarjeta y PantallaObtenerRegistroTarjeta adems de las clases borde InterfaceUsuario e InterfaceBaseDatosRegistro. En la Figura 7.36 se muestran las clases identificadas en este caso de uso.

InterfaceUsuario

PantallaCrearRegTarjeta PantallaObtenerRegTarjeta

InterfaceBaseDatosRegistro

ManejadorRegistroTarjeta

RegistroTarjeta

Figura 7.36 Clases identificadas para el caso uso Registrar Tarjeta. Consultar Informacin El caso de uso Consultar Informacin involucra una clase control ManejadorConsultas que es encargada de controlar toda los diferentes tipos de consultas junto con la clase borde correspondiente a la pantalla PantallaConsultas, adems de las clases borde InterfaceUsuario e InterfaceBaseDatosRegistro. Dado que este caso de uso tiene tres subflujos importantes, en lugar de describirlos en un slo diagrama, lo haremos en tres diagramas separados como veremos ms adelante. En la Figura 7.37 se muestran las clases principales identificadas en este caso de uso.

InterfaceUsuario

InterfaceBaseDatosReservas

ManejadorConsultas

PantallaConsultas

Figura 7.37 Clases identificadas para el caso uso Consultar Informacin. Consultar Horarios El subflujo Consultar Horarios del caso de uso Consultar Informacin involucra a todas las clases del diagrama de la Figura 7.37, las cuales no volvemos a incluir en el diagrama. Se incluyen en el nuevo diagrama las clases borde correspondiente a las pantallas PantallaConsultaHorarios y PantallaResultadoHorarios adems de las clases entidad Vuelo, Aeropuerto, Horario y Aerolnea junto con la clase control ManejadorConsultaHorarios. El resto de

Weitzenfeld: Captulo 7

18

las clases entidad del dominio del problema no son necesarias para este subflujo. En la Figura 7.38 se muestran las clases identificadas en este subflujo.

PantallaConsultaHorarios PantallaResultadoHorarios

ManejadorConsultaHorarios

Vuelo

Aeropuerto

Horario

Aerolnea

Figura 7.38 Clases identificadas para el subflujo Consultar Horarios del caso uso Consultar Informacin. Consultar Tarifas El subflujo Consultar Tarifas del caso de uso Consultar Informacin involucra a todas las clases del diagrama de la Figura 7.37, las cuales no volvemos a incluir en el diagrama. Se incluyen en el nuevo diagrama las clases borde correspondiente a las pantallas PantallaConsultaTarifas y PantallaResultadoTarifas adems de las clases entidad Vuelo, Aeropuerto, Horario, Aerolnea y Tarifa junto con la clase control ManejadorConsultaTarifas. El resto de las clases entidad del dominio del problema no son necesarias para este subflujo. En la Figura 7.39 se muestran las clases identificadas en este caso de uso.

PantallaConsultaTarifas

PantallaResultadoTarifas

ManejadorConsultaTarifas

Horario

Aerolnea

Vuelo

Tarifa

Aeropuerto

Figura 7.39 Clases identificadas para el subflujo Consultar Tarifas del caso uso Consultar Informacin. Consultar Estado El subflujo Consultar Estado del caso de uso Consultar Informacin involucra a todas las clases del diagrama de la Figura 7.37, las cuales no volvemos a incluir en el diagrama. Se incluyen en el nuevo diagrama las clases borde correspondiente a las pantallas PantallaConsultaEstado y PantallaResultadoEstado adems de las clases entidad Vuelo, Aeropuerto, Horario, Aerolnea y Avin junto con la clase control ManejadorConsultaEstado. El resto de las clases entidad del dominio del problema no son necesarias para este subflujo. En la Figura 7.40 se muestran las clases identificadas en este caso de uso.

PantallaConsultaEstado

PantallaResultadoEstado

ManejadorConsultaEstado

Horario

Aerolnea

Vuelo

Aeropuerto

Avin

Figura 7.40 Clases identificadas para el subflujo Consultar Estado del caso uso Consultar Informacin.

Weitzenfeld: Captulo 7

19

Hacer Reservacin El caso de uso Hacer Reservacin involucra una clase control ManejadorReservas que es encargada de controlar las reservaciones junto con las clases bordes correspondiente a la pantalla PantallaClaveReservas, PantallaCrearReservaVuelos y PantallaRecordReservaVuelos adems de las clases borde InterfaceUsuario e InterfaceBaseDatosReserva. Se incluyen en el diagrama todas las clases entidad necesarias, que son Vuelo, Asiento, Avin, Tarifa, Horario, Aerolnea, Aeropuerto, Reservacin, Pasajero y ViajeroFrecuente. En la Figura 7.41 se muestran las clases identificadas en este caso de uso.

ManejadorReservas

InterfaceUsuario InterfaceBaseDatosReservas

PantallaCrearReservaVuelos

PantallaClaveReservas

PantallaRecordReservaVuelos

Tarifa

Aeropuerto

Vuelo

ViajeroFrecuente

Reservacin

Horario

Asiento Aerolnea

Avin

Pasajero

Figura 7.41 Clases identificadas para el caso uso Hacer Reservacin. Pagar Reservacin El caso de uso Pagar Reservacin involucra una clase control ManejadorPagos que es encargada de controlar la informacin de pagos y las clases borde correspondiente a las pantallas PantallaPagarRegTarjeta y PantallaReembolsarRegTarjeta adems de las clases borde InterfaceUsuario e InterfaceBaseDatosReserva. Se incluye tambin la clase RegistroTarjeta dado que es necesaria para obtener la informacin de la tarjeta de crdito. En la Figura 7.42 se muestran las clases identificadas en este caso de uso.

ManejadorPagos

InterfaceUsuario

InterfaceBaseDatosReservas

RegistroTarjeta

PantallaPagarRegTarjeta PantallaReembolsarRegTarjeta

Figura 7.42 Clases identificadas para el caso uso Pagar Reservacin. 7.4 Diagramas de Secuencias Una vez identificadas las clases anteriores, proseguimos describiendo los casos de uso del modelo de requisitos segn la lgica que debern presentar estas clases para lograr la funcionalidad descrita en los diversos casos de uso. Este es un paso muy importante ya que en base a la lgica propuesta para esta descripcin, definiremos la arquitectura de anlisis tanto estructural como funcional. Dada la complejidad y la importancia de estas descripciones, es importante probar las secuencias funcionales de los casos de uso flujos revisar qu tan bien nuestra lgica y arquitectura de clase resuelve la funcionalidad establecida. Para eso introducimos el concepto de diagramas de secuencias, interaccin o eventos, los cuales describen como los

Weitzenfeld: Captulo 7

20

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

: Actor1

: Clase1

: Clase2

: Clase3

: Clase4

: Actor2

Figura 7.43 Diagrama de secuencia. Cada clase participante se representa por una barra, dibujadas como lneas verticales en el diagrama. El orden entre las barras es insignificante y debe elegirse para dar la mayor claridad. Si hubieran varias instancias de las clases que interactan entre si, se dibujaran las instancias como barras diferentes. Adems de los objetos, es importante representar entidades externas al sistema en los diagramas de secuencia. De lo contrario este tipo de diagrama no sera demasiado til en el modelo de anlisis. En nuestro caso, estas entidades externas que se incluyen como barras adicionales en el diagrama representando instancias de los actores. El eje de tiempo en el diagrama de secuencia es vertical (paralelo a las barras) y avanzando hacia abajo. El comienzo del diagrama de secuencia corresponde al inicio del caso de uso. El avance en el tiempo en el diagrama es controlado por los eventos, mientras que la distancia entre dos eventos en el diagrama no tiene relacin con el tiempo real entre estos eventos. Ms an el tiempo no es necesariamente lineal en el diagrama, pudiendo existir concurrencia. El diagrama de secuencia de la Figura 7.44 muestra un ejemplo de estos eventos.

: Actor1 1:e1

: Clase1

: Clase2

: Clase3

: Clase4

: Actor2

2:e2 3:e3 a2 a1 8:e8 a8 4:e4 5:e5 a3 a5 6:e6 7:e7

Figura 7.44 Diagrama de secuencia con eventos.

Weitzenfeld: Captulo 7

21

En el diagrama de la figura 7.44, las barras gruesas corresponden a actividades dentro del objeto, denominadas por a, mientras que las flechas corresponden a eventos, denominadas por e. Un evento se dibuja como una flecha horizontal que comienza en la barra correspondiente al objeto que lo enva y termina en la barra correspondiente al objeto que lo recibe. En este ejemplo los eventos son numerados sucesivamente utilizando el formato n:. Las actividades son iniciadas por el arribo de eventos y el tiempo que duran es slo relevante en relacin a eventos originados durante esa actividad, como en el caso de el objeto de la Clase1 que recibe un evento e1, el cual inicia una actividad que consiste en primero generar un evento e2 y posteriormente otro evento e6. Un aspecto importante que los diagramas de secuencia deben considerar es que las secuencias de eventos sean continuas y no all interrupciones. Por otro lado la gran mayora de los diagramas de secuencia, y por lo tanto los casos de uso, deben comenzar con un evento externo que se genera a partir de una de las instancias de los actores del sistema. Por ejemplo, consideremos la secuencia que comienza con el Actor1 a travs del evento e1. Este evento da lugar al evento e2 el cual a su vez da lugar al evento e3 y as sucesivamente hasta llegar el evento e7. Sin embargo se interrumpe la continuidad entre el evento e7 y el evento e8. Esta situacin es muy delicada y peligrosa ya que al no haber una dependencia directa entre ambos eventos y si consideramos que no existe una relacin de tiempo real entre ningn evento, pues e8 pudiera generarse en cualquier momento lo cual pudiera ocasionar inconsistencias en la aplicacin. Esto se debe evitar a toda costa, cada nuevo evento debe generarse a partir de uno que se recibe con la nica excepcin de eventos iniciales que son generados por el sistema o tpicamente por un actor. Ntese que los actores principales son los que tpicamente deciden que casos de uso sern instanciados, a diferencia de los propios objetos y casos de uso secundarios que ms bien responden a eventos que son recibidos. Durante el modelo de anlisis y como veremos en las siguientes secciones, utilizaremos los diagramas de secuencia para describir los flujos principales y subflujos para cada caso de uso. Esto ayudar a revisar si nuestra lgica es correcta y consistente al relacionar las casos de uso del modelo de requisitos con la arquitectura de clases del modelo de anlisis. Dado que existen mltiples posibles flujos de secuencia, nos concentraremos nicamente en los principales que definan flujos completos y que incluyen subflujos intermedios, incluyendo casos de uso de inclusin. Por lo tanto, describiremos los casos de uso de mayor inters. Ntese que los incicios de muchos de estos casos se repiten, lo cual incluiremos en los diversos casos de uso para no perder el flujo de eventos en el desarrollo de las diversas secuencias. Registrar Usuario En el caso de uso Registrar Usuario existen diversas secuencias 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 particular mostraremos diagramas de secuencias para Crear Registro Usuario, Actualizar Registro Usuario y Eliminar Registro Usuario. Ntese que estas secuencias incluirn obviamente a los subflujos Crear Registro Usuario (S-1), Actualizar Registro Usuario (S-4) y Eliminar Registro Usuario (S-5), de manera correspondiente, junto con los casos de uso, Validar Usuario y Ofrecer Servicios, adems de los los subflujos Obtener Registro Usuario (S-2) y Administrar Registro Usuario (S-3). Crear Registro Usuario El diagrama de secuencia para Crear Registro Usuario se muestra en el diagrama 7.45. Esta secuencia inicia en el flujo principal de Registrar Usuario que deber incluir ciertas opciones definidas en Validar Usuario seguidos por el subflujo Crear Registro Usuario (S-1) y Administrar Registro Usuario (S-3). ? ? Validar Usuario. Aunque la secuencia se inicia en el flujo princial de Registrar Usuario, se contina inmediatamente con la insercin del caso de uso Validar Usuario, donde podemos iniciar con el ManejadorPrincipal solicitando el desplegado de la PantallaPrincipal mediante el evento desplegarPantallaPrincipal. Para continuar este secuencia, el usuario deber seleccionar la opcin de Registrar Por Primera Vez oprimiendo el botn correspondiente en la pantalla. La InterfaceUsuario por ser la controladora de las interfaces de usuario, recibe el evento y lo enva como un nuevo evento Registrar Por Primera Vez al ManejadorPrincipal. El ManejadorPrincipal que es el encargado de controlar la lgica general del sistema, reconoce que este evento corresponde a una actividad de registro y se lo enva como crearRegUsuario al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Crear Registro Usuario (S-1). En este momento el ManejadorRegistroUsuario reconoce el tipo de evento particular y solicita a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaCrearRegUsuario. La InterfaceUsuario despliega esta pantalla,

Weitzenfeld: Captulo 7

22

algo que no se muestra en el diagrama por ser un evento interno. Para continuar con la lgica principal de este subflujo, el usuario debe llenar sus datos, que no se muestran aqu, y oprime el botn Registrar para que esta informacin sea enviada a la clase InterfaceUsuario. Es importante resaltar que los datos como tales no generan eventos ni son de importancia en estos diagramas. Lo que genera eventos son los botones en las pantallas. Siguiendo con nuestra lgica, la InterfaceUsuario enva el evento Registrar al ManejadorRegistroUsuario. Este controlador es responsable de guardar la informacin de registro del usuario, por lo cual enva el evento crearRegUsuario a la InterfaceBaseDatosRegistro. Ntese que como en el caso de los datos, los objetos entidad como la clase RegistroUsuario, tampoco son mostrados en el diagrama, dado que no agregan eventos interesantes para la lgica del sistema. Incluso se omiten del diagrama todas las clases correspondientes a pantallas ya que sus eventos importantes son manejados por la InterfaceUsuario. Prosiguiendo con nuestra lgica, la InterfaceBaseDatosRegistro enva el evento crearRegUsuario al actor Base de Datos Registros. Este actor debe responder de alguna manera, y lo hace mediante un OK el cual es luego enviado de manera sucesiva hasta llegar al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin pasamos al subflujo Administrar Registro Usuario (S-3) donde el El ManejadorRegistroUsuario enva el evento desplegarPantallaObtenerRegUsuario a la InterfaceUsuario. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido de los subflujos Crear Registro Usuario (S-1) y Administrar Registro Usuario (S-3) del caso de uso Registrar Usuario.

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsu... 1: desplegarPantallaPrincipal

: ManejadorPrincipal

: InterfaceBaseDatosRegistro : Base de Datos Registros

2: "Registrarse Por Primera Vez" 3: Registrarse Por Primera Vez" 4: crearRegistroUsuario 5: desplegarPantallaCrearRegUsuario 6: "Registrar" 7: "Registrar" 8: crearRegistroUsuario 9: crearRegistroUsuario 11: OK 12: desplegarPantallaObtenerRegUsuario 13: "S alir" 10: OK

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

Weitzenfeld: Captulo 7

23

Actualizar Registro Usuario El diagrama de secuencia Actualizar Registro Usuario se muestra en el diagrama 7.46. Esta secuencia inicia en el flujo principal de Registrar Usuario que incluye las opciones de validacin definidas en Validar Usuario, seguidos por parte de Ofrecer Servicios, para luego proseguir con el subflujo Obtener Registro Usuario (S-2), Administrar Registro Usuario (S-3) y obviamente Actualizar Registro Usuario (S-4), para completar la secuencia de la actualizacin. ? ? Validar Usuario. Nuevamente, aunque la secuencia se inicia en el flujo princial de Registrar Usuario, se contina inmediatamente con la insercin del caso de uso Validar Usuario, donde podemos iniciar con el ManejadorPrincipal enviando el evento desplegarPantallaPrincipal a la InterfaceUsuario, el cual despliega la PantallaPrincipal. En este momento el usuario debe validarse, insertando su login y contrasea. Al ser datos, estos no generan ningn evento. Una vez el usuario genere el evento OK oprimiendo el botn correspondiente, se instancia la validacin. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal reconoce que este evento corresponde a una actividad de registro y enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. Este controlador reconoce el tipo de evento particular y solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante un evento adicional con el mismo nombre. La InterfaceBaseDatosRegistro enva a su vez un evento similar al actor Base de Datos Registros, el cual contesta con un OK si la validacin es buena. Dado que slo consideramos una secuencia de eventos, una validacin incorrecta se mostrara en otro diagrama. El OK es sucesivamente enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Obtener Registro. Este evento es enviado de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento obtenerRegistroUsuario al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Obtener Registro Usuario (S-2). A continuacin regresamos al caso de uso Registrar Usuario subflujo Obtener Registro Usuario (S-2) donde el ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que obtenga el registro correspondiente mediante obtenerRegistroUsuario. Nuevamente, la InterfaceBaseDatosRegistro le pasa un evento similar al actor Base de Datos Registros, el cual contesta con un OK. Junto a este OK deben enviarse los propios datos, los cuales no son mostrados en el diagrama de secuencia por no generar eventos. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario solicita a la InterfaceUsuario desplegar la pantalla de informacin de registro mediante el evento desplegarPantallaObtenerRegUsuario. En este momento el usuario actualiza sus datos, que no se muestran aqu y oprime el botn Actualizar. ? ? Registrar Usuario subflujo Actualizar Registro Usuario (S-4). Siguiendo con la lgica, la InterfaceUsuario enva el mismo evento al ManejadorRegistroUsuario, el cual es responsable de actualizar el registro, por lo cual enva el evento actualizarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el evento actualizarRegistroUsuario al actor Base de Datos Registros. Este actor responde mediante un OK el cual es luego enviado de manera sucesiva hasta llegar al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario enva el evento desplegarPantallaObtenerRegUsuario a la InterfaceUsuario. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Registrar Usuario con los subflujos Obtener Registro Usuario (S2), Administrar Registro Usuario (S-3) y Actualizar Registro Usuario (S-4).

Weitzenfeld: Captulo 7

24

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsu.. .

: ManejadorServicio : ManejadorPrincipal

: InterfaceBaseDatosRegistro : Base de Datos Registros

1: desplegarPantallaPrincipal 2: "OK" 3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 11: desplegarPantallaServicios 12: "Obtener Registro" 13: "Obtener Registro" 14: obtenerRegist roUsuario 15: obtenerRegistroUsuario 16: obtenerRegistroUsuario 17: OK 18: OK 19: desplegarPantallaObtenerRegUsuario 20: "Actualizar" 21: "Actualizar" 22: actualizarRegistroUsuario 23: actualizarRegistroUsuario 24: OK 25: OK 26: desplegarPantallaObtenerRegUsuario 27: "Salir" 10: ofrecerServicios

Figura 7.46 Diagrama de secuencia Actualizar Registro Usuario del caso de uso Registrar Usuario. Eliminar Registro Usuario El diagrama de secuencia para el subflujo Eliminar Registro Usuario se muestra en el diagrama 7.47. Esta secuencia es bastante similar a la de Actualizar Registro Usuario ya que inicia en el flujo principal de Registrar Usuario que incluye las opciones de validacin definidas en Validar Usuario, seguidos por ciertos aspectos de Ofrecer Servicios, para luego proseguir con el subflujo Obtener Registro Usuario (S-2), Administrar Registro Usuario (S-3) y obviamente Eliminar Registro Usuario (S-5), para completar la secuencia de la eliminacin. Ntese que solamente cambia el ltimo subflujo. ? ? Validar Usuario. Nuevamente, se comienza en Validar Usuario con la secuencia con el evento desplegarPantallaPrincipal de la clase ManejadorPrincipal al InterfaceUsuario. El Usuario se valida enviando el evento OK. La InterfaceUsuario enva el evento OK al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Obtener Registro. Este evento es enviado de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento obtenerRegistroUsuario al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Obtener Registro Usuario (S-2). A continuacin regresamos al caso de uso Registrar Usuario subflujo Obtener Registro Usuario (S-2) donde el ManejadorRegistroUsuario solicita a la

Weitzenfeld: Captulo 7

25

InterfaceBaseDatosRegistro que obtenga el registro correspondiente mediante obtenerRegistroUsuario. Nuevamente, la InterfaceBaseDatosRegistro le pasa un evento similar al actor Base de Datos Registros, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario solicita a la InterfaceUsuario desplegar la pantalla de informacin de registro mediante el evento desplegarPantallaObtenerRegUsuario. Hasta aqu la secuencia es similar a Actualizar Registro Usuario. En este momento el usuario oprime el botn Eliminar. ? ? Registrar Usuario subflujo Eliminar Registro Usuario (S-3). Siguiendo con la lgica, La InterfaceUsuario enva el mismo evento al ManejadorRegistroUsuario, el cual es responsable de eliminar el registro, por lo cual enva el evento eliminarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el evento eliminarRegistroUsuario al actor Base de Datos Registros. Este actor responde mediante un OK el cual es luego enviado de manera sucesiva hasta llegar al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario enva el evento desplegarPantallaCreaeRegUsuario a la InterfaceUsuario. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Registrar Usuario con los subflujos Obtener Registro Usuario (S2), Administrar Registro Usuario (S-3) y Eliminar Registro Usuario (S-4).

: Usuario

: InterfaceUsuario

: : ManejadorServicio ManejadorRegistroUsu... 1: desplegarPantallaPrincipal 3: "OK" 4: validarRegistroUsuario

: ManejadorPrincipal

: InterfaceBaseDatosRegistro : Base de Datos Registros

2: "OK"

5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 11: desplegarPantallaServicios 12: "Obtener Registro" 13: "Obtener Registro" 14: obtenerRegistroUsuario 15: obtenerRegistroUsuario 16: obtenerRegistroUsuario 17: OK 19: desplegarPantallaObtenerRegUsuario 20: "Eliminar" 21: "Eliminar" 22: eliminarRegistroUsuario 23: eliminarRegistroUsuario 24: OK 26: desplegarPantallaCrearRegUsuario 27: "Salir" 25: OK 18: OK 10: ofrecerServicios

Figura 7.47 Diagrama de secuencia Eliminar Registro Usuario del caso de uso Registrar Usuario. Registrar Tarjeta En el caso de uso Registrar Tarjeta existen diversas secuencias que pueden ser instanciados por un usuario. En particular mostraremos diagramas de secuencias para Crear Registro Tarjeta, Actualizar Registro Tarjeta y Eliminar Registro Tarjeta. Ntese que estas secuencias incluirn obviamente a los subflujos Crear Registro Tarjeta (S-1), Actualizar Registro Tarjeta (S-4) y Eliminar Registro Tarjeta (S-5), de manera correspondiente, junto con los casos de uso Validar Usuario y Ofrecer Servicios, adems de los los subflujos Obtener Registro Usuario (S-2) y Administrar Registro Usuario (S-3) de Registrar Usuario dado que Registrar Tarjeta es una extensin de este.

Weitzenfeld: Captulo 7

26

Crear Registro Tarjeta El diagrama de secuencia para el subflujo Crear Registro Tarjeta se muestra en el diagrama 7.48. Esta secuencia inicia de manera similar a la secuencia Actualizar Registro Usuario con la excepcin de que en lugar de hacer una actualizacin, se crea un registro de tarjeta siguiendo el flujo principal de Registrar Tarjeta en lugar del subflujo Crear Registro Tarjeta (S-1) en lugar de Actualizar Registro Usuario (S-4) en Registrar Usuario. Dentro del caso de uso Registrar Tarjeta se continuar con los subflujos Crear Registro Tarjeta (S-1), Obtener Registro Tarjeta (S-2) y Administrar Registro Tarjeta (S-3). ? ? Validar Usuario. La secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all al ManejadorRegistroUsuario y luego al ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Obtener Registro. Este evento es enviado de la InterfaceUsuario al ManejadorServicio mediante el mismo evento. El evento obtenerRegistroUsuario es luego enviado por el ManejadorServicio al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Obtener Registro Usuario (S-2). A continuacin regresamos al caso de uso Registrar Usuario subflujo Obtener Registro Usuario (S-2) donde el ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que obtenga el registro correspondiente mediante el mismo evento. Nuevamente, la InterfaceBaseDatosRegistro le pasa un evento similar al actor Base de Datos Registros, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario solicita a la InterfaceUsuario desplegar la pantalla de informacin de registro mediante el evento desplegarPantallaObtenerRegUsuario. Hasta aqu la secuencia es similar al subflujo Actualizar Registro Usuario. En este momento el usuario oprime el botn Registrar Tarjeta. ? ? Registrar Tarjeta subflujo principal. Siguiendo con la lgica, la InterfaceUsuario enva el mismo evento al ManejadorRegistroUsuario, el cual solicita obtenerRegistroTarjeta al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Obtener Registro Tarjeta (S-2). El ManejadorRegistroTarjeta que es responsable de todo lo relacionado con el registro de tarjeta, solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el mismo evento al actor Base de Datos Registros. Este actor responde mediante un NULL correspondiente a un registro de tarjeta inexistente. Este evento es enviado de regreso al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Crear Registro Tarjeta (S-1). A continuacin, el ManejadorRegistroTarjeta solicita desplegarPantallaCrearRegistroTarjeta a InterfaceUsuario. El usuario registra sus datos de tarjeta y presiona el botn de Registrar generando el evento Registrar. Como consecuencia de esto, InterfaceUsuario enva el mismo evento al ManejadorRegistroTarjeta el cual enva el evento crearRegistroTarjeta a InterfaceBaseDatosRegistro. Este ltimo enva el mismo evento al actor Base de Datos Registros, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro para ser luego enviado al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Adminsitrar Registro Tarjeta (S-3). A continuacin, el ManejadorRegistroTarjeta enva el evento desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Registrar Usuario con los subflujos Obtener Registro Usuario (S2), Administrar Registro Usuario (S-3) y finalmente el flujo principal de Registrar Tarjeta seguido por los subflujos Crear Registro Tarjeta (S-1), Obtener Registro Tarjeta (S-2) y Administrar Registro Tarjeta (S-3).

Weitzenfeld: Captulo 7

27

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsu...

: ManejadorRegistroTarjeta

: ManejadorServicio

: ManejadorPrincipal : InterfaceBaseDatosRegistro : Base de Datos Registros

1: desplegarPaginaPrincipal 2: "OK" 3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios 12: "Obtener Registro" 13: "Obtener Registro" 14: obtenerRegistroUsuario 15: obtenerRegistroUsuario 16: obtenerRegistroUsuario 17: OK 19: desplegarPantallaObtenerRegUsuario 20: "Registrar Tarjet a" 21: "Registrar Tarjeta" 18: OK

22: registrarTarjeta

23: obtenerRegistroTarjeta 24: obtenerRegistroTarjeta 25: NULL 26: NULL

27: desplegarPantallaCrearRegTarjet a 28: "Registrar" 29: "Registrar" 30: crearRegistroTarjeta 31: crearRegistroTarjeta 33: OK 34: desplegarPantallaObtenerRegTarjeta 35: "Salir" 32: OK

Figura 7.48 Diagrama de secuencia Crear Registro Tarjeta del caso de uso Registrar Tarjeta. Actualizar Registro Tarjeta El diagrama de secuencia Actualizar Registro Tarjeta se muestra en el diagrama 7.49. Esta secuencia es muy similar a Crear Registro Tarjeta aunque en lugar de seguir al subflujo Crear Registro Tarjeta (S-1), seguir los subflujos Obtener Registro Tarjeta (S-2), Administrar Registro Tarjeta (S-3) y obviamente Actualizar Registro Tarjeta (S-4). ? ? Validar Usuario. La secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Obtener Registro. Este mismo evento es enviado de la InterfaceUsuario al ManejadorServicio. El evento obtenerRegistroUsuario es luego enviado por el ManejadorServicio al ManejadorRegistroUsuario.

Weitzenfeld: Captulo 7

28

??

Registrar Usuario subflujo Obtener Registro Usuario (S-2). A continuacin regresamos al caso de uso Registrar Usuario subflujo Obtener Registro Usuario (S-2) donde el ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que obtenga el registro correspondiente mediante el mismo evento. Nuevamente, la InterfaceBaseDatosRegistro le pasa un evento similar al actor Base de Datos Registros, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario solicita a la InterfaceUsuario desplegar la pantalla de informacin de registro mediante el evento desplegarPantallaObtenerRegUsuario. En este momento el usuario oprime el botn Registrar Tarjeta. ? ? Registrar Tarjeta subflujo principal. Siguiendo con la lgica, la InterfaceUsuario enva el mismo evento al ManejadorRegistroUsuario, el cual solicita registrarTarjeta al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Obtener Registro Tarjeta (S-2). El ManejadorRegistroTarjeta solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el mismo evento al actor Base de Datos Registros. El actor Base de Datos Registros responde mediante un OK, correspondiente a un registro de tarjeta existente. Este evento es enviado de regreso al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Adminsitrar Registro Tarjeta (S-3). A continuacin, el ManejadorRegistroTarjeta enva el evento desplegarPantallaObtenerRegistroTarjeta a InterfaceUsuario. El usuario actualiza sus datos de tarjeta y presiona el botn de Actualizar generando el evento Actualizar. ? ? Registrar Tarjeta subflujo Actualizar Registro Tarjeta (S-4). A continuacin, a InterfaceUsuario enva el mismo evento al ManejadorRegistroTarjeta el cual solicita actualizarRegistroTarjeta a InterfaceBaseDatosRegistro. Este ltimo enva el mismo evento al actor Base de Datos Registros, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro y luego al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Adminsitrar Registro Tarjeta (S-3). A continuacin, el ManejadorRegistroTarjeta enva el evento desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Registrar Usuario con los subflujos Obtener Registro Usuario (S2), Administrar Registro Usuario (S-3) y finalmente el flujo principal de Registrar Tarjeta seguido por los subflujos Obtener Registro Tarjeta (S-2), Administrar Registro Tarjeta (S-3) y Actualizar Registro Tarjeta (S-4).

Weitzenfeld: Captulo 7

29

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsu...

: ManejadorRegistroTarjeta

: ManejadorServicio

: ManejadorPrincipal : InterfaceBaseDatosRegistro

: Base de Datos Registros

1: desplegarPantallaPrincipal 2: "OK" 3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios 12: "Obtener Registro" 13: "Obtener Registro" 14: obtenerRegistroUsuario 15: obtenerRegistroUsuario 16: obtenerRegist roUsuario 17: OK 19: desplegarPantallaObtenerRegUsuario 20: "Registrar Tarjeta" 21: "Registrar Tarjeta" 18: OK

22: registrarTarjeta

23: obtenerRegistroTarjeta 24: obtenerRegistroTarjeta 25: OK 26: OK

27: desplegarPantallaObtenerRegTarjeta 28: "Actualizar" 29: "Actualizar" 30: actualizarRegistroTarjeta 31: actualizarRegistroTarjeta 33: OK 34: desplegarPantallaObtenerRegTarjeta 35: "Salir" 32: OK

Figura 7.49 Diagrama de secuencia Actualizar Registro Tarjeta del caso de uso Registrar Tarjeta. Eliminar Registro Tarjeta El diagrama de secuencia Eliminar Registro Tarjeta se muestra en el diagrama 7.50. Esta secuencia es muy similar a Actualizar Registro Tarjeta aunque en lugar de seguir al subflujo Crear Registro Tarjeta (S-1), seguir los subflujos Obtener Registro Tarjeta (S-2), Administrar Registro Tarjeta (S-3) y obviamente Eliminar Registro Tarjeta (S-5). ? ? Validar Usuario. La secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal al InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Obtener Registro. Este mismo evento es enviado de la InterfaceUsuario al ManejadorServicio. El evento obtenerRegistroUsuario es luego enviado por el ManejadorServicio al ManejadorRegistroUsuario. ? ? Registrar Usuario subflujo Obtener Registro Usuario (S-2). A continuacin regresamos al caso de uso Registrar Usuario subflujo Obtener Registro Usuario (S-2) donde el ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que obtenga el registro correspondiente mediante el mismo evento. Nuevamente, la InterfaceBaseDatosRegistro le pasa un evento similar al actor Base de Datos Registros, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorRegistroUsuario.

Weitzenfeld: Captulo 7

30

Registrar Usuario subflujo Administrar Registro Usuario (S-3). A continuacin podemos pasar al subflujo Administrar Registro Usuario (S-3) donde el ManejadorRegistroUsuario solicita a la InterfaceUsuario desplegar la pantalla de informacin de registro mediante el evento desplegarPantallaObtenerRegUsuario. En este momento el usuario oprime el botn Registrar Tarjeta. ? ? Registrar Tarjeta subflujo principal. Siguiendo con la lgica, la InterfaceUsuario enva el mismo evento al ManejadorRegistroUsuario, el cual enva el evento registrarTarjeta al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Obtener Registro Tarjeta (S-2). El ManejadorRegistroTarjeta solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el mismo evento al actor Base de Datos Registros. El actor Base de Datos Registros responde mediante un OK correspondiente a un registro de tarjeta existente. Este evento es enviado de regreso al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Adminsitrar Registro Tarjeta (S-3). A continuacin, el ManejadorRegistroTarjeta enva el evento desplegarPantallaObtenerRegistroTarjeta a InterfaceUsuario. Hasta aqu la secuencia es similar al subflujo Actualizar Registro Tarjeta, ya que el usuario presiona el botn de Eliminar generando el evento Eliminar. ? ? Registrar Tarjeta subflujo Eliminar Registro Tarjeta (S-5). Como consecuencia del evento Eliminar, la InterfaceUsuario mismo evento al ManejadorRegistroTarjeta el cual solicita registrarTarjeta al ManejadorRegistroTarjeta el cual enva el evento eliminarRegistroTarjeta a InterfaceBaseDatosRegistro. Este ltimo enva el mismo evento al actor Base de Datos Registros, el cual contesta con un OK que es sucesivamente enviado de regreso a la InterfaceBaseDatosRegistro y luego al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Adminsitrar Registro Tarjeta (S-3). A continuacin, el ManejadorRegistroTarjeta enva el evento desplegarPantallaCrearRegTarjeta a la InterfaceUsuario. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Registrar Usuario con los subflujos Obtener Registro Usuario (S2), Administrar Registro Usuario (S-3) y finalmente el flujo principal de Registrar Tarjeta seguido por los subflujos Obtener Registro Tarjeta (S-2), Administrar Registro Tarjeta (S-3) y Eliminar Registro Tarjeta (S-5).

??

Weitzenfeld: Captulo 7

31

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsu...

: ManejadorRegistroTarjeta

: ManejadorServicio

: ManejadorPrincipal

: InterfaceBaseDatosRegist ro: Base de Datos Registros

1: desplegarPantallaPrincipal 2: "OK" 3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios 12: "Obtener Registro" 13: "Obtener Registro" 14: obtenerRegistroUsuario 15: obtenerRegistroUsuario 16: obtenerRegistroUsuario 17: OK 19: desplegarPantallaObtenerRegUsuario 20: "Registrar Tarjet a" 21: "Registrar Tarjeta" 18: OK

22: registrarTarjeta

23: obtenerRegistroTarjeta 24: obtenerRegistroTarjeta 25: OK 26: OK

27: desplegarPantallaObtenerRegTarjeta 28: "Eliminar" 29: "Eliminar" 30: eliminarRegistroTarjet a 31: elim inarRegistroTarjeta 33: OK 34: desplegarPantallaCrearRegTarjet a 32: OK

35: "Salir"

Figura 7.50 Diagrama de secuencia Eliminar Registro Tarjeta del caso de uso Registrar Tarjeta. Consultar Informacin En el caso de uso Consultar Informacin existen diversos subflujos que pueden ser instanciados por un usuario. En particular mostraremos diagramas de secuencias para Consultar Horarios, Consultar Tarifas y Consultar Estado. Ntese que estas secuencias incluirn obviamente a los subflujos Consultar Horarios (S-2), Consultar Tarifas (S-3) y Consultar Estado (S-4), respectivamente. Adems se incluir parte de los casos de uso de inclusin Validar Usuario y Ofrecer Servicios, adems de subflujos adicionales dentro del caso de uso Consultar Informacin. Consultar Horarios El diagrama de secuencia Consultar Horarios se muestra en el diagrama 7.51. Esta secuencia inicia en el flujo principal de Consultar Informacin que incluye la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios y los subflujos Consultar (S-1), Consultar Horarios (S-2) y Devolver Horarios (S-3). ? ? Validar Usuario. Esta secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como

Weitzenfeld: Captulo 7

32

respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Consultar Informacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El evento consultarInformacin es luego enviado por el ManejadorServicio al ManejadorConsultas. ? ? Consultar Informacin subflujo Consultar (S-1). A continuacin el ManejadorConsultas enva el evento desplegarPantallaConsultas a InterfaceUsuario. El usuario presiona Horarios lo cual genera que la InterfaceUsuario enve este evento de regreso a ManejadorConsultas el cual enva el evento consultarHorarios al ManejadorConsultaHorarios. ? ? Consultar Informacin subflujo Consultar Horarios (S-2). A continuacin el ManejadorConsultaHorarios enva el evento desplegarPantallaConsultaHorarios a InterfaceUsuario. El usuario llena la informacin de la consulta y oprime el botn Consultar el cual genera el mismo evento de InterfaceUsuario al ManejadorConsultaHorarios. Este ltimo enva el evento consultarHorarios a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorConsultaHorarios. ? ? Consultar Informacin subflujo Devolver Horarios (S-3). A continuacin el ManejadorConsultaHorarios enva el evento desplegarPantallaResultadoHorarios a la InterfaceUsuario para desplegar los resultados de la bsqueda. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Consultar Informacin con los subflujos Consultar (S-1), Consultar Horarios (S-2) y Devolver Horarios (S-3).

: Usuario

: InterfaceUsuario

: : ManejadorConsultas : : ManejadorServicio : ManejadorPrincipal : InterfaceBaseDatosRegistro ManejadorConsultaHorarios ManejadorRegistroUsuario 1: desplegarPantallaPrincipal

: InterfaceBaseDatosReservas : Base de Datos Registros

: Base de Datos Reservas

2: "OK"

3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios

12: "Consultar Informacin" 13: "Consultar Informacin" 14: consultarInformacin 15: desplegarPantallaConsultas 16: "Horarios" 17: "Horarios"

18: consultarHorarios 19: desplegarPantallaConsultaHorarios 20: "Consultar" 21: "Consultar" 22: consultarHorarios 23: consultarHorarios 24: OK 26: desplegarPantallaResultadoHorarios 27: "Salir" 25: OK

Figura 7.51 Diagrama de secuencia Consultar Horarios del caso de uso Consultar Informacin. Consultar Tarifas El diagrama de secuencia Consultar Tarifas se muestra en el diagrama 7.52. Esta secuencia inicia en el flujo principal de Consultar Informacin que incluye la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios y los subflujos Consultar (S-1), Consultar Tarifas (S-4) y Devolver Tarifas (S-5). ? ? Validar Usuario. Esta secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos

Weitzenfeld: Captulo 7

33

Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Consultar Informacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El evento consultarInformacin es luego enviado por el ManejadorServicio al ManejadorConsultas. ? ? Consultar Informacin subflujo Consultar (S-1). A continuacin el ManejadorConsultas enva el evento desplegarPantallaConsultas a la InterfaceUsuario. Hasta aqu la secuencia es similar a la secuencia Consultar Horarios. En esta nueva secuencia, el usuario presiona Tarifas lo cual genera que la InterfaceUsuario enve este evento de regreso a ManejadorConsultas el cual enva el evento consultarTarifas al ManejadorConsultaTarifas. ? ? Consultar Informacin subflujo Consultar Tarifas (S-4). A continuacin el ManejadorConsultaTarifas enva el evento desplegarPantallaConsultaTarifas a InterfaceUsuario. El usuario llena la informacin de la consulta y oprime el botn Consultar el cual genera el mismo evento de InterfaceUsuario al ManejadorConsultaTarifas. Este ltimo enva el evento consultarTarifas a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorConsultaTarifas. ? ? Consultar Informacin subflujo Devolver Tarifas (S-5). A continuacin el ManejadorConsultaTarifas enva el evento desplegarPantallaResultadoTarifas a la InterfaceUsuario para desplegar los resultados de la bsqueda. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Consultar Informacin con los subflujos Consultar (S-1), Consultar Tarifas (S-4) y Devolver Tarifas (S-5).

: Usuario

: InterfaceUsuario

: ManejadorConsultaTarifas

: ManejadorConsultas : : ManejadorServicio ManejadorRegistroUsuario 1: desplegarPantallaPrincipal

: ManejadorPrincipal

: InterfaceBaseDatosRegistro : InterfaceBaseDatosReservas

: Base de Datos : Base de Datos Registros Reservas

2: "OK"

3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios

12: "Consultar Informacin" 13: "Consultar Informacin" 15: desplegarPantallaConsultas 16: "Tarifas" 17: "Tarifas" 18: consultarTarifas 19: desplegarPantallaConsultaTarifas 20: "Consultar" 21: "Consultar" 22: consultarTarifas 23: consultarTarifas 24: OK 25: OK 26: desplegarPantallaResultadoTarifa 27: "Salir" 14: consultarInformacin

Figura 7.52 Diagrama de secuencia Consultar Tarifas del caso de uso Consultar Informacin. Consultar Estado El diagrama de secuencia Consultar Estado se muestra en el diagrama 7.53. Esta secuencia inicia en el flujo principal de Consultar Informacin que incluye la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios y los subflujos Consultar (S-1), Consultar Estado (S-6) y Devolver Estado (S-7). ? ? Validar Usuario. Esta secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El

Weitzenfeld: Captulo 7

34

ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Consultar Informacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El evento consultarInformacin es luego enviado por el ManejadorServicio al ManejadorConsultas. ? ? Consultar Informacin subflujo Consultar (S-1). A continuacin el ManejadorConsultas enva el evento desplegarPantallaConsultas a la InterfaceUsuario. Hasta aqu la secuencia es similar a la secuencia Consultar Horarios y Consultar Tarifas. En esta nueva secuencia, el usuario presiona Estado lo cual genera que la InterfaceUsuario enve este evento de regreso a ManejadorConsultas el cual enva el evento consultarEstado al ManejadorConsultaEstado. ? ? Consultar Informacin subflujo Consultar Estado (S-6). A continuacin el ManejadorConsultaEstado enva el evento desplegarPantallaConsultaEstado a InterfaceUsuario. El usuario llena la informacin de la consulta y oprime el botn Consultar el cual genera el mismo evento de InterfaceUsuario al ManejadorConsultaEstado. Este ltimo enva el evento consultarEstados a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorConsultaEstado. ? ? Consultar Informacin subflujo Devolver Estado (S-7). A continuacin el ManejadorConsultaEstado enva el evento desplegarPantallaResultadoEstado a la InterfaceUsuario para desplegar los resultados de la bsqueda. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Consultar Informacin con los subflujos Consultar (S-1), Consultar Estado (S-4) y Devolver Estado (S-7).

: Usuario

: InterfaceUsuario

: ManejadorConsultaEstado

: ManejadorConsultas : : ManejadorServicio ManejadorRegistroUsuario 1: desplegarPantallaPrincipal

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: InterfaceBaseDatosReservas : Base de Datos Registros

: Base de Datos Reservas

2: "OK"

3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios

12: "Consultar Informacin" 13: "Consultar Informacin" 15: desplegarPantallaConsultas 16: "Estado" 17: "Estado" 18: consultarEstado 19: desplegarPantallaConsultaEstado 20: "Consultar" 21: "Consultar" 14: consultarInformacin

22: consultarEstado

23: consultarEstado 24: OK

25: OK 26: desplegarPantallaResultadoEstado 27: "Salir"

Figura 7.53 Diagrama de secuencia Consultar Estado del caso de uso Consultar Informacin. Hacer Reservacin En el caso de uso Hacer Reservacin existen diversos subflujos que pueden ser instanciados por un usuario. En particular mostraremos diagramas de secuencias para Crear Reservacin, Actualizar Reservacin y Eliminar Reservacin. Ntese que estas secuencias incluirn obviamente a los subflujos Crear Reservacin (S-2), Actualizar Reservacin (S-5) y Eliminar Reservacin (S-6), respectivamente. Adems se incluir parte de los casos de uso de

Weitzenfeld: Captulo 7

35

inclusin Validar Usuario y Ofrecer Servicios, adems de subflujos adicionales dentro del caso de uso Hacer Reservacin. Crear Reservacin El diagrama de secuencia Crear Reservacin se muestra en el diagrama 7.54. Esta secuencia inicia en el flujo principal de Hacer Reservacin que incluye la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios y los subflujos Solicitar Clave Reservacin (S-1), Crear Reservacin (S-2) y Administrar Reservacin (S4). ? ? Validar Usuario. Esta secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Hacer Reservacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento reservar al ManejadorReservas. ? ? Hacer Reservacin subflujo Solicitar Clave Reservacin (S-1). A continuacin el ManejadorReservas enva el evento desplegarPantallaClaveReservas a InterfaceUsuario. El usuario presiona el botn Crear. La InterfaceUsuario enva el mismo evento a ManejadorReservas. ? ? Hacer Reservacin subflujo Crear Reservacin (S-2). A continuacin el ManejadorReservas enva el evento desplegarPantallaCrearReservaVuelos a InterfaceUsuario. El usuario presiona Reservar. La InterfaceUsuario enva el mismo evento a ManejadorReservas el cual enva el evento crearReserva a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a la InterfaceUsuario para desplegar los resultados de la creacin. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Hacer Reservacin con los subflujos Solicitar Clave Reservacin (S-1) Crear Reservacin (S-2) y Administrar Reservacin (S-4).

Weitzenfeld: Captulo 7

36

: Usuario

: InterfaceUsuario

: ManejadorReservas : : ManejadorServicio ManejadorRegistroUsuario

: ManejadorPrincipal

: InterfaceBaseDatosRegistro : InterfaceBaseDatosReservas

: Base de Datos Registros

: Base de Datos Reservas

1: desplegarPantallaPrincipal 2: "OK" 3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios 6: validarRegistroUsuario 7: OK

12: "Hacer Reservacion" 13: "Hacer Reservacin" 14: reservar 15: desplegarPantallaClaveReservas 16: "Crear" 17: "Crear" 18: desplegarPantallaCrearReservaVuelos 19: "Reservar" 20: "Reservar"

21: crearReserva 22: crearReserva

23: OK 24: OK 25: desplegarPantallaRecordReservaVuelos 26: "Salir"

Figura 7.54 Diagrama de secuencia Crear Reservacin del caso de uso Hacer Reservacin. Actualizar Reservacin El diagrama de secuencia Actualizar Reservacin se muestra en el diagrama 7.55. Esta secuencia inicia en el flujo principal de Hacer Reservacin que incluye la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios y los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3), Administrar Reservacin (S4) y Actualizar Reservacin (S-5). ? ? Validar Usuario. Esta secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Hacer Reservacin. Se genera el mismo evento que es enviado de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento reservar al ManejadorReservas. ? ? Hacer Reservacin subflujo Solicitar Clave Reservacin (S-1). A continuacin el ManejadorReservas enva el evento desplegarPantallaClaveReservas a InterfaceUsuario. El usuario presiona el botn Obtener, junto con la insercin de la clave de rcord de reservas. La InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas. ? ? Hacer Reservacin subflujo Obtener Reservacin (S-3). A continuacin el ManejadorReservas enva el evento obtenerReserva a la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de regreso a InterfaceBaseDatosReservas, la cual luego lo enva a ManejadorReservas.

Weitzenfeld: Captulo 7

37

Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a InterfaceUsuario. El usuario actualiza los datos de su reservacin y presiona Actualizar. ? ? Hacer Reservacin subflujo Actualizar Reservacin (S-5). A continuacin la InterfaceUsuario enva el evento Actualizar de regreso a ManejadorReservas. El ManejadorReservas solicita actualizarReserva a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a la InterfaceUsuario para desplegar los resultados de la actualizacin. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Hacer Reservacin con los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3), Administrar Reservacin (S-4) y Actualizar Reservacin (S-5).

??

: Usuario

: InterfaceUsuario

: ManejadorReservas : : ManejadorServicio: ManejadorPrincipal: InterfaceBaseDatosRegistro : InterfaceBaseDatosReservas : Base de Datos ManejadorRegistroUsuario Registros 1: desplegarPantallaPrincipal

: Base de Datos Reservas

2: "OK"

3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios

12: "Hacer Reservacin" 13: "Hacer Reservacin" 14: reservar 15: desplegarPantallaClaveReservas 16: "Obtener" 17: "Obtener" 18: obtenerReserva 19: obtenerReserva 20: OK 21: OK 22: desplegarPantallaRecordReservaVuelos 23: "Actualizar" 24: "Actualizar" 25: actualizarReserva 26: actualizarReserva 27: OK 28: OK 29: desplegarPantallaRecordReservaVuelos 30: "Salir"

Figura 7.55 Diagrama de secuencia Actualizar Reservacin del caso de uso Hacer Reservacin. Eliminar Reservacin El diagrama de secuencia Eliminar Reservacin se muestra en el diagrama 7.56. Esta secuencia inicia en el flujo principal de Hacer Reservacin que incluye la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios y los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3), Administrar Reservacin (S4) y Eliminar Reservacin (S-6). ? ? Validar Usuario. Esta secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como

Weitzenfeld: Captulo 7

38

respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Hacer Reservacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento reservar al ManejadorReservas. ? ? Hacer Reservacin subflujo Solicitar Clave Reservacin (S-1). A continuacin el ManejadorReservas enva el evento desplegarPantallaClaveReservas a InterfaceUsuario. El usuario presiona el botn Obtener, junto con la insercin de la clave de rcord de reservas. La InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas. ? ? Hacer Reservacin subflujo Obtener Reservacin (S-3). A continuacin el ManejadorReservas enva el evento obtenerReserva a la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de regreso a InterfaceBaseDatosReservas, la cual luego lo enva a ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a InterfaceUsuario. Hasta aqu la secuencia es similar a Actualizar Reservacin. En este momento el usuario presiona Eliminar. ? ? Hacer Reservacin subflujo Eliminar Reservacin (S-6). A continuacin la InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas el cual enva el evento eliminarReserva a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorReservas ? ? Hacer Reservacin subflujo Crear Reservacin (S-2). A continuacin el ManejadorReservas enva el evento desplegarPantallaCrearReservaVuelos a la InterfaceUsuario para desplegar una nueva pantalla de creacin de reservas. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Hacer Reservacin con los subflujos Solicitar Clave Reservacin (S-1), Crear Reservacin (S-2), Obtener Reservacin (S-3), Administrar Reservacin (S-4) y Eliminar Reservacin (S-6).

: Usuario

: InterfaceUsuario

: ManejadorReservas : : ManejadorServicio : ManejadorPrincipal : InterfaceBaseDatosRegistro : InterfaceBaseDatosReservas : Base de Datos : Base de Datos ManejadorRegistroUsuario Registros Reservas 1: desplegarPantallaPrincipal

2: "OK"

3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 11: desplegarPantallaServicios

12: "Hacer Reservacin" 13: "Hacer Reservacin" 14: reservar 15: desplegarPantallaClaveReservas 16: "Obtener" 17: "Obtener" 18: obtenerReserva 19: obtenerReserva 20: OK 21: OK 22: desplegarPantallaRecordReservaVuelos 23: "Eliminar" 24: "Eliminar" 25: eliminarReserva 26: eliminarReserva 27: OK 28: OK 29: desplegarPantallaRecordReservaVuelos

30: "Salir"

Figura 7.56 Diagrama de secuencia Eliminar Reservacin del caso de uso Hacer Reservacin.

Weitzenfeld: Captulo 7

39

Pagar Reservacin En el caso de uso Pagar Reservacin existen diversos subflujos que pueden ser instanciados por un usuario. En particular mostraremos diagramas de secuencias para Pagar Reservacin y Reembolsar Pago. Ntese que estas secuencias incluirn obviamente a los subflujos Pagar Reservacin (S-1) y Reembolsar Pago (S-2), respectivamente. Adems se incluir parte de los casos de uso de inclusin Validar Usuario y Ofrecer Servicios, los subflujos, Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3) y Administrar Reservacin (S-4), necesarios por extensin de Hacer Reservacin, adems de subflujos adicionales dentro del caso de uso Pagar Reservacin. Pagar Reservacin El diagrama de secuencia Pagar Reservacin se muestra en el diagrama 7.57. Esta secuencia inicia en el flujo principal de Pagar Reservacin que incluye, por ser una extensin, la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios, los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3) y Administrar Reservacin (S-4), del caso de uso Hacer Reservacin. Posteriormente se ejecuta el flujo principal de Pagar Reservacin junto con el subflujo Pagar Reservacin (S-1). Adems de esto, se ejecuta el subflujo Obtener Registro Tarjeta (S-2) del caso de uso Registrar Tarjeta. ? ? Validar Usuario. Esta secuencia comienza comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios. ? ? Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Hacer Reservacin y debe incluir un nmero correspondiente a la clave de reservacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento reservar al ManejadorReservas. ? ? Hacer Reservacin subflujo Solicitar Clave Reservacin (S-1). A continuacin el ManejadorReservas enva el evento desplegarPantallaClaveReservas a InterfaceUsuario. El usuario presiona el botn Obtener, junto con la insercin de la clave de rcord de reservas. La InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas. ? ? Hacer Reservacin subflujo Obtener Reservacin (S-3). A continuacin el ManejadorReservas enva el evento obtenerReserva a la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de regreso a InterfaceBaseDatosReservas, la cual luego lo enva a ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a InterfaceUsuario. Hasta aqu la secuencia es similar a Actualizar Reservacin y Eliminar Reservacin del caso de uso Hacer Reservacin. En este momento el usuario presiona Pagar. La InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas el cual enva el evento pagarReserva al ManejadorPagos. ? ? Pagar Reservacin flujo principal. A continuacin el ManejadorPagos enva el evento obtenerRegistroTarjeta al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Obtener Registro Tarjeta (S-2). A continuacin el ManejadorRegistroTarjeta enva el evento obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro la cual enva el mismo evento al actor Base de Datos Registros. Este actor regresa un OK a la InterfaceBaseDatosRegistro la cual a su vez lo enva de regreso a ManejadorRegistroTarjeta. ? ? Pagar Reservacin flujo principal (continuacin anterior). A continuacin el ManejadorRegistroTarjeta enva el OK a ManejadorPagos. ? ? Pagar Reservacin subflujo Pagar Reservacin (S-1). A continuacin el ManejadorPagos enva el evento desplegarPantallaPagarRegTarjeta a la InterfaceUsuario. El usuario genera el evento Pagar. La InterfaceUsuario recibe la peticin y enva el mismo evento al ManejadorPagos. Este a su vez enva el evento

Weitzenfeld: Captulo 7

40

pagarReserva a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorPagos el cual enva el OK al ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a la InterfaceUsuario para desplegar los resultados del pago de reserva. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Hacer Reservacin con los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3) y Administrar Reservacin (S-4), y finalizar en el caso de uso Pagar Reservacin con el flujo principal y el subflujo Pagar Reservacin (S-1). Se incluye tambin el caso de uso Registrar TArjeta subflujo Obtener Registro Tarjeta (S-2).

: Usuario

: InterfaceUsuario

: ManejadorPagos : ManejadorReservas : : : ManejadorServicio : ManejadorPrincipal : InterfaceBaseDatosRegistro : InterfaceBaseDatosReservas : Base de Datos ManejadorRegistroUsuario ManejadorRegistroTarjeta Registros 1: desplegarPantallaPrincipal

: Base de Datos Reservas

2: "OK"

3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios

12: "Hacer Reservacin"

11: desplegarPantallaServicios 13: "Hacer Reservacin" 14: reservar 15: obtenerReserva 16: obtenerReserva 17: OK 18: OK

19: desplegarPantallaRecordReservaVuelos 20: "Pagar" 21: "Pagar" 22: pagarReservacin 23: obtenerRegistroTarjeta 24: obtenerRegistroTarjeta 25: obtenerRegistroTarjeta 27: OK 28: OK 29: desplegarPantallaPagarRegTarjeta 30: "Pagar" 31: "Pagar" 32: pagarReserva 33: pagarReserva 34: OK 35: OK 36: OK 37: desplegarPantallaRecordReservaVuelos 38: "Salir" 26: OK

Figura 7.57 Diagrama de secuencia Pagar Reservacin del caso de uso Pagar Reservacin. Reembolsar Pago El diagrama de secuencia Reembolsar Pago se muestra en el diagrama 7.58. Esta secuencia es muy similar a Pagar Reservacin, iniciando en el flujo principal de Pagar Reservacin que incluye, por ser una extensin, la validacin del usuario en Validar Usuario seguidos por Ofrecer Servicios, los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3) y Administrar Reservacin (S-4), del caso de uso Hacer Reservacin. Posteriormente se ejecuta el flujo principal de Pagar Reservacin junto con el subflujo Reembolsar Pago (S-2). Adems de esto, se ejecuta el subflujo Obtener Registro Tarjeta (S-2) del caso de uso Registrar Tarjeta. ? ? Validar Usuario. La secuencia comienza con la validacin del usuario a partir del evento desplegarPantallaPrincipal de la clase ManejadorPrincipal a la InterfaceUsuario. El usuario se valida enviando el evento OK. La InterfaceUsuario enva el mismo evento al ManejadorPrincipal. El ManejadorPrincipal enva el evento validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita a la InterfaceBaseDatosRegistro que haga una validacin del usuario mediante el mismo evento. La InterfaceBaseDatosRegistro enva a su vez el evento a la Base de Datos Registros, el cual contesta con un OK si la validacin es buena. El OK es enviado a la InterfaceBaseDatosRegistro, de all a ManejadorRegistroUsuario y luego a ManejadorPrincipal como respuesta a las secuencias de validacin. Una vez el ManejadorPrincipal recibi este ltimo OK, solicita al ManejadorServicio que entre en accin mediante el evento ofrecerServicios.

Weitzenfeld: Captulo 7

41

??

Ofrecer Servicios. A continuacin podemos pasar al caso de uso Ofrecer Servicios donde el ManejadorServicio solicita entonces a la InterfaceUsuario el desplegado de la pantalla correspondiente mediante desplegarPantallaServicio. La InterfaceUsuario despliega esta pantalla. Para continuar con la lgica principal de este subflujo, el usuario debe presionar Hacer Reservacin y debe incluir un nmero correspondiente a la clave de reservacin. Se enva el mismo evento de la InterfaceUsuario al ManejadorServicio. El ManejadorServicio enva el evento reservar al ManejadorReservas. ? ? Hacer Reservacin subflujo Solicitar Clave Reservacin (S-1). A continuacin el ManejadorReservas enva el evento desplegarPantallaClaveReservas a InterfaceUsuario. El usuario presiona el botn Obtener, junto con la insercin de la clave de rcord de reservas. La InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas. ? ? Hacer Reservacin subflujo Obtener Reservacin (S-3). A continuacin el ManejadorReservas enva el evento obtenerReserva a la InterfaceBaseDatosReservas, la cual a su vez enva este evento al actor Base de Datos Reservas. El actor genera un OK si todo es correcto y se lo enva de regreso a InterfaceBaseDatosReservas, la cual luego lo enva a ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a InterfaceUsuario. Hasta aqu la secuencia es similar a la secuencia Pagar Reservacin. En este momento el usuario presiona Reembolsar. La InterfaceUsuario enva el mismo evento de regreso a ManejadorReservas el cual enva el evento reembolsarReservacin al ManejadorPagos. ? ? Pagar Reservacin flujo principal. A continuacin el ManejadorPagos enva el evento obtenerRegistroTarjeta al ManejadorRegistroTarjeta. ? ? Registrar Tarjeta subflujo Obtener Registro Tarjeta (S-2). A continuacin el ManejadorRegistroTarjeta enva el evento obtenerRegTarjeta a la InterfaceBaseDatosRegistro la cual enva el mismo evento al actor Base de Datos Registros. Este actor regresa un OK a la InterfaceBaseDatosRegistro la cual a su vez lo enva de regreso a ManejadorRegistroTarjeta. ? ? Pagar Reservacin flujo principal (continuacin anterior). A continuacin el ManejadorRegistroTarjeta enva el OK a ManejadorPagos. ? ? Pagar Reservacin subflujo Reembolsar Pagos (S-2). A continuacin el ManejadorPagos enva el evento desplegarPantallaReembolsarRegTarjetas a la InterfaceUsuario. El usuario genera el evento Reembolsar. La InterfaceUsuario recibe la peticin y enva el mismo evento al ManejadorPagos. Este a su vez enva el evento reembolsarReserva a la InterfaceBaseDatosReservas para que haga la peticin correspondiente al actor Base de Datos Reservas, el cual contesta con un OK. El OK es luego enviado por la InterfaceBaseDatosRegistro al ManejadorPagos el cual enva el OK al ManejadorReservas. ? ? Hacer Reservacin subflujo Administrar Reservacin (S-4). A continuacin el ManejadorReservas enva el evento desplegarPantallaRecordReservaVuelos a la InterfaceUsuario para desplegar los resultados del reembolso de reserva. En ese momento el Usuario presiona Salir, dando por concluida la secuencia. En resumen, la secuencia podr iniciar con el caso de uso Validar Usuario seguido por el caso de uso Ofrecer Servicios, para luego continuar en el caso de uso Hacer Reservacin con los subflujos Solicitar Clave Reservacin (S-1), Obtener Reservacin (S-3) y Administrar Reservacin (S-4), y finalizar en el caso de uso Pagar Reservacin con el flujo principal y el subflujo Reembolsar Pago (S-2). Se incluye tambin el caso de uso Registrar TArjeta subflujo Obtener Registro Tarjeta (S-2).

Weitzenfeld: Captulo 7

42

: Usuario

: : : ManejadorServicio : ManejadorPrincipal : InterfaceBaseDatosRegistro : InterfaceBaseDatosReservas : Base de Datos : Base de Datos : InterfaceUsuario : ManejadorPagos : ManejadorReservas ManejadorRegistroUsuario ManejadorRegistroTarjeta Registros Reservas

1: desplegarPantallaPrincipal 2: "OK" 3: "OK" 4: validarRegistroUsuario 5: validarRegistroUsuario 6: validarRegistroUsuario 7: OK 8: OK 9: OK 10: ofrecerServicios 12: "Hacer Reservacin" 11: desplegarPantallaServicios 13: "Hacer Reservacin" 14: obtenerReserva 15: obtenerReserva 16: obtenerReserva 17: OK 18: OK 19: desplegarPantallaRecordReservaVuelos 20: "Reembolsar" 21: "Reembolsar" 22: reembolsarReservacin 23: obtenerRegistroTarjeta 24: obtenerRegistroTarjeta 25: obtenerRegistroTarjeta 27: OK 28: OK 29: desplegarPantallaReembolsoReservas 30: "Reembolsar" 31: "Reembolsar" 32: reembolsarReserva 33: reembolsarReserva 34: OK 35: OK 36: OK 37: desplegarPantallaRecordReservaVuelos 38: "Salir" 26: OK

Figura 7.58 Diagrama de secuencia Reembolsar Pago del caso de uso Pagar Reservacin. 7.5 Documento de Casos de Uso A partir de las diversas secuencias analizadas y descritas en los diagramas de secuencias, podemos generar una descripcin casi completa de los casos de uso del sistema de reservaciones de vuelo a nivel de anlisis. Para lograr este paso, tomamos todas las descripciones y las insertamos en los flujos o subflujos correspondientes de los diversos casos de uso. Dado que las secuencias no mencionan todos los posibles eventos sino los principales, podemos en este momento completar los que sean necesarios. En particular deberemos asegurarnos que no existan discontinuidades entre las secuencias de eventos. Sin embargo, debe siempre mantenerse una buena consistencia entre los casos de uso de anlisis y las secuencias anteriores que en el fondo son instanciaciones a partir de los casos de uso. Cualquier cambio en la lgica en las secuencias o casos de usuo deber reflejarse tambin en los diagramas de secuencia. En las descripciones de los casos de uso, estaremos subrayando las clases y escribiendo en letras cursivas los nombres de los eventos entre clases. Es muy importante que las frases sean claras y concisas, ya que esto facilitar posteriormente el diseo. Validar Usuario El flujo principal del caso de uso Validar Usuario se muestra a continuacin.

Weitzenfeld: Captulo 7

43

Caso de Uso Actores Tipo Propsito Resumen Precondiciones Flujo Principal

Subflujos Excepciones

Validar Usuario Usuario, Base de Datos Registro Inclusin Validar a un usuario ya registrado para el uso del sistema de reservaciones de vuelo. Este caso de uso es iniciado por el Usuario. Valida al usuario mediante un login y password a ser validado con su respectivo registro de usuario para asi poder utilizar el sistema de reservaciones. Si el Usuario an no se ha registrado, requerir ejecutar el caso de uso Registrar Usuario subflujo Crear Registro Usuario. El ManejadorPrincipal solicita desplegarPantallaPrincipal a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaPrincipal. La PantallaPrincipal se despliega. El Usuario puede seleccionar entre las siguientes opciones: "Registrarse por Primera Vez", "OK" y "Salir". Si la actividad seleccionada es "Registrarse por Primera Vez", la PantallaPrincipal enva el evento Registrarse por Primera Vez a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrarse por Primera Vez al ManejadorPrincipal. El ManejadorPrincipal solicita crearRegistroUsuario al ManejadorRegistroUsuario. Se ejecuta el caso de uso Registrar Usuario, subflujo Crear Registro Usuario (S-1). Si la actividad seleccionada es "OK", se valida el registro de usuario mediante un login y un password insertados por el Usuario en la PantallaPrincipal. La PantallaPrincipal enva el evento OK a la InterfaceUsuario. La InterfaceUsuario enva el evento OK al ManejadorPrincipal. El ManejadorPrincipal solicita validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita validarRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro valida al usuario y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. El ManejadorRegistroUsuario devuelve el OK al ManejadorPrincipal. Una vez validado el usuario (E-1), el ManejadorPrincipal solicita ofrecerServicio al ManejadorServicio. Se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaPrincipal enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorPrincipal. El ManejadorPrincipal sale del sistema. Ninguno E-1 no hubo validacin: El login/password no se valid correctamente. Se le pide al usuario que vuelva a intentar hasta tres veces despus de lo cual se saldr del sistema.

Ofrecer Servicios El flujo principal del caso de uso Ofrecer Servicios se muestra a continuacin.

Weitzenfeld: Captulo 7

44

Caso de Uso Actores Tipo Propsito Resumen Precondiciones Flujo Principal

Subflujos Excepciones

Ofrecer Servicios Usuario Inclusin Ofrecer los diversos servicios a un usuario ya registrado para el uso del sistema de reservaciones de vuelo. Este caso de uso es iniciado por el Usuario. Tiene opciones para utilizar las diversos servicios del sistema de reservaciones. Se requiere la validacin correcta del usuario. El ManejadorServicio solicita desplegarPantallaServicio a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaServicio. La PantallaServicio se despliega. El Usuario puede seleccionar entre las siguientes actividades: Consultar Informacin, Hacer Reservacin, "Obtener Registro" y "Salir". Si la actividad seleccionada es "Consultar Informacin", la PantallaServicio enva el evento Consultar Informacin a la InterfaceUsuario. La InterfaceUsuario enva el evento Consultar Informacin al ManejadorServicio. El ManejadorServicio solicita consultar al ManejadorConsultas. Se contina con el caso de uso Consultar Informacin, subflujo Consultar (S-1). Si la actividad seleccionada es "Hacer Reservacin", la PantallaServicio enva el evento Hacer Reservacin a la InterfaceUsuario. La InterfaceUsuario enva el evento Hacer Reservacin al ManejadorServicio. El ManejadorServicio solicita reservar al ManejadorReservas. Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es "Obtener Registro", la PantallaServicio enva el evento Obtener Registro a la InterfaceUsuario. La InterfaceUsuario enva el evento Obtener Registro al ManejadorServicio. El ManejadorServicio solicita registrar al ManejadorRegistroUsuario. Se contina con el caso de uso Registrar Usuario, subflujo Obtener Registro Usuario (S-2). Si la actividad seleccionada es "Salir", la PantallaServicio enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorServicio. El ManejadorServicio sale del sistema. Ninguno. Ninguno.

Registrar Usuario El flujo principal del caso de uso Registrar Usuario se muestra a continuacin. Registrar Usuario Caso de Uso Usuario, Base de Datos Registros Actores Bsico Tipo Permitir a un usuario registrarse con el sistema de reservaciones de vuelo para su uso posterior. Propsito Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, modificar y eliminar Resumen el registro de usuario con el sistema de reservaciones. Precondiciones Todos los subflujos, con excepcin de Registrarse Por Primera Vez, requieren ejecutar inicialmente el caso de uso Validar Usuario. Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Flujo Principal Usuario, se continuar con los diversos subflujos de este caso de uso. El subflujo Crear Registro Usuario (S-1) se muestra a continuacin.

Weitzenfeld: Captulo 7

45

S-1 Crear Registro Usuario El ManejadorRegistroUsuario solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaCrearRegUsuario. La PantallaCrearRegUsuario se despliega. Esta pantalla contiene informacin de registro que debe ser llenada por el Usuario, lo cual incluye nombre, apellido, calle, colonia, ciudad, pas, cdigo postal, telfonos de la casa y oficina, nmero de fax, login, email, password y una entrada adicional de repetir password para asegurarse de su correccin. El login y la password sern utilizados por el sistema para validar al usuario. El Usuario puede seleccionar entre las siguientes actividades: "Registrar" y "Salir". Si el Usuario selecciona Registrar, la PantallaCrearRegUsuario enva el evento Registrar a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrar al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita crearRegistroUsuario a la Base de Datos Registro (E-1, E-2, E-3, E-4). La Base de Datos Registro devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Se contina con el subflujo Administrar Registro Usuario (S-3). Si la actividad seleccionada es "Salir", la PantallaCrearRegUsuario enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroUsuario. El ManejadorRegistroUsuario sale del sistema. (Si an no se ha presionado "Registrar", la informacin ser perdida). El subflujo Obtener Registro Usuario (S-2) se muestra a continuacin. S-2 Obtener Registro Usuario Subflujos El ManejadorRegistroUsuario solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro. (cont) La InterfaceBaseDatosRegistro solicita obtenerRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro devuelve el OK y el RegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK y el RegistroUsuario al ManejadorRegistroUsuario. Se contina con el subflujo Administrar Registro Usuario (S-3). El subflujo Administrar Registro Usuario (S-3) se muestra a continuacin. S-3 Administrar Registro Usuario Subflujos El ManejadorRegistroUsuario solicita desplegarPantallaObtenerRegUsuario a la (cont) InterfaceUsuario. La InterfaceUsuario despliega la PantallaObtenerRegUsuario. La PantallaObtenerRegUsuario se despliega. El Usuario puede seleccionar entra las siguientes actividades: "Eliminar", "Actualizar", "Registrar Tarjeta", "Servicios" y "Salir". Si el usuario presiona "Actualizar" se ejecuta el subflujo Actualizar Registro Usuario (S-4). Si el usuario selecciona "Eliminar" se ejecuta el subflujo Eliminar Registro Usuario (S-5). Si el usuario presiona "Registrar Tarjeta", la PantallaObtenerRegUsuario enva el evento Registrar Tarjeta a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrar Tarjeta al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita registrarTarjeta al ManejadorRegistroTarjeta, se contina con el caso de uso Registrar Tarjeta. Si la actividad seleccionada es "Servicios", la PantallaObtenerRegUsuario enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaObtenerRegUsuario enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroUsuario. El ManejadorRegistroUsuario sale del sistema. (Si an no se ha presionado "Actualizar", la nueva informacin ser perdida). El subflujo Actualizar Registro Usuario (S-4) se muestra a continuacin. Subflujos

Weitzenfeld: Captulo 7

46

S-4 Actualizar Registro Usuario La PantallaObtenerRegUsuario enva el evento Actualizar a la InterfaceUsuario. La InterfaceUsuario enva el evento Actualizar" al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita actualizarRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro actualiza el RegistroUsuario (E-1, E-3, E-4) y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Se continua con el subflujo Administrar Registro Usuario (S-3). El subflujo Eliminar Registro Usuario (S-5) se muestra a continuacin. S-5 Eliminar Registro Usuario Subflujos La PantallaObtenerRegUsuario enva el evento Eliminar a la InterfaceUsuario. La (cont) InterfaceUsuario enva el evento Eliminar al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita eliminarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el evento eliminarRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro elimina el RegistroUsuario y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Se contina con el subflujo Crear Registro Usuario (S-1). Las excepciones del caso de uso se muestran a continuacin. E-1 informacin incompleta: Falta llenar informacin en el registro de usuario. Se le vuelve a Excepciones pedir al usuario que complete el registro. E-2 registro ya existe: Si ya existe un registro bajo ese login, se le pedir al usuario que lo cambie o que termine el caso de uso. E-3 login incorrecto: El login no es vlido. Se le vuelve a pedir al usuario que complete el registro. E-4 contrasea incorrecta: La contrasea escogida es muy sencilla o no se valid correctamente. Se le vuelve a pedir al usuario que complete el registro. Subflujos (cont) Registrar Tarjeta El flujo principal del caso de uso Registrar Tarjeta se muestra a continuacin. Registrar Tarjeta Caso de Uso Usuario, Base de Datos Registros Actores Extensin Tipo Permitir a un usuario registrar una tarjeta de crditos con el sistema de reservaciones de vuelo Propsito para poder pagar boletos. Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para para crear, modificar y Resumen eliminar el registro de tarjeta usuario para poder pagar las reservaciones directamente con el sistema de reservaciones. Precondiciones El usuario ya se debe haberse registrado mediante la activacin del caso de uso Registrar Usuario. Flujo Principal Se contina con el subflujo Obtener Registro Tarjeta (S-2). Si no existe un RegistroTarjeta vlido se contina con el subflujo Crear Registro Tarjeta (S-1). De lo contrario, si ya existe un RegistroTarjeta vlido, se contina con el subflujo Administrar Registro Tarjeta (S-3). El subflujo Crear Registro Tarjeta (S-1) se muestra a continuacin.

Weitzenfeld: Captulo 7

47

S-1 Crear Registro Tarjeta El ManejadorRegistroTarjeta solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaCrearRegTarjeta. La PantallaCrearRegTarjeta se despliega. Esta pantalla contiene informacin que debe ser llenada por el Usuario, lo cual incluye el nombre como aparece el la tarjeta, nmero de tarjeta, el tipo de tarjeta, y la fecha de vencimiento. El Usuario puede seleccionar entre las siguientes actividades: "Registrar", "Servicios" y "Salir". Si el Usuario selecciona Registrar, la PantallaCrearRegTarjeta enva el evento Registrar a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrar al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita crearRegistroTarjeta a la Base de Datos Registro (E-1). La Base de Datos Registro devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Se contina con el subflujo Administrar Registro Tarjeta (S-3). Si la actividad seleccionada es "Servicios", la PantallaCrearRegTarjeta enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaCrearRegTarjeta enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta sale del sistema. (Si an no se ha presionado "Registrar", la informacin sta ser perdida). El subflujo Obtener Registro Tarjeta (S-2) se muestra a continuacin. S-2 Obtener Registro Tarjeta Subflujos El ManejadorRegistroTarjeta solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro. La (cont) InterfaceBaseDatosRegistro solicita obtenerRegistroTarjeta a la Base de Datos Registro. La Base de Datos Registro devuelve el OK y el RegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK y el RegistroTarjeta al ManejadorRegistroTarjeta. Se regresa al flujo anterior. El subflujo Administrar Registro Tarjeta (S-3) se muestra a continuacin. S-3 Administrar Registro Tarjeta Subflujos El ManejadorRegistroTarjeta solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario. (cont) La InterfaceUsuario despliega la PantallaObtenerRegTarjeta. La PantallaObtenerRegTarjeta se despliega. El Usuario puede seleccionar entre las siguientes actividades: "Actualizar", "Eliminar", "Servicios" y "Salir". Si el usuario presiona Actualizar se ejecuta el subflujo Actualizar Registro Tarjeta (S-4). Si el usuario presiona Eliminar se ejecuta el subflujo Eliminar Registro Tarjeta (S-5). Si la actividad seleccionada es "Servicios", la PantallaObtenerRegTarjeta enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaObtenerRegTarjeta enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta sale del sistema. (Si an no se ha presionado "Actualizar", la nueva informacin sta ser perdida). El subflujo Actualizar Registro Tarjeta (S-4) se muestra a continuacin. Subflujos

Weitzenfeld: Captulo 7

48

S-4 Actualizar Registro Tarjeta La PantallaObtenerRegTarjeta enva el evento Actualizar a la InterfaceUsuario. La InterfaceUsuario enva el evento Actualizar" al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita actualizarRegistroTarjeta a la Base de Datos Registro (E-1). La Base de Datos Registro actualiza el RegistroTarjeta y devuelve el evento OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Se continua con el subflujo Administrar Registro Tarjeta (S-3). El subflujo Eliminar Registro Tarjeta (S-5) se muestra a continuacin. S-5 Eliminar Registro Tarjeta Subflujos La PantallaObtenerRegTarjeta enva el evento Eliminar a la InterfaceUsuario. La (cont) InterfaceUsuario enva el evento Eliminar" al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita eliminarRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita eliminarRegistroTarjeta a la Base de Datos Registro. La Base de Datos Registro elimina el RegistroTarjeta (E-1) y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Se continua con el subflujo Crear Registro Tarjeta (S-1). Las excepciones del caso de uso se muestran a continuacin. E-1 informacin incompleta: Falta llenar informacin indispensable para completar el registro de Excepciones tarjeta. Se le vuelve a pedir al usuario que complete el registro de tarjeta. Subflujos (cont) Consultar Informacin El flujo principal del caso de uso Consultar Informacin se muestra a continuacin. Consultar Informacin Caso de Uso Usuario, Base de Datos Reservas Actores Bsico Tipo Permitir a un usuario consultar informacin con el sistema de reservaciones de vuelo. Propsito Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para consultar informacin de Resumen horarios, tarifas y estado de vuelos con el sistema de reservaciones. Precondiciones Se requieren haber ejecutado anteriormente el caso de uso Validar Usuario. Flujo Principal Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuar con los diversos subflujos de este caso de uso. El subflujo Consultar (S-1) se muestra a continuacin.

Weitzenfeld: Captulo 7

49

S-1 Consultar El ManejadorConsultas solicita desplegarPantallaConsultas a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaConsultas. La PantallaConsultas se despliega. El Usuario puede seleccionar de las siguientes actividades: "Horarios", "Tarifas", "Estado", Servicios y Salir. Si la actividad seleccionada es Horarios, la PantallaConsultas enva el evento Horarios a la InterfaceUsuario. La InterfaceUsuario enva el evento Horarios al ManejadorConsultas. El ManejadorConsultas solicita consultarHorarios al ManejadorConsultasHorarios. Se contina con el subflujo Consultar Horarios (S-2). Si el usuario presiona Tarifas, la PantallaConsultas enva el evento Tarifas a la InterfaceUsuario. La InterfaceUsuario enva el evento Tarifas al ManejadorConsultas. El ManejadorConsultas solicita consultarTarifas al ManejadorConsultasTarifas. Se contina con el subflujo Consultar Tarifas (S-4). Si el usuario presiona Estado, la PantallaConsultas enva el evento Estado a la InterfaceUsuario. La InterfaceUsuario enva el evento Estado al ManejadorConsultas. El ManejadorConsultas solicita consultarEstado al ManejadorConsultasEstado. Se contina con el subflujo Consultar Estado (S-6). Si el usuario presiona Servicios, la PantallaConsultas enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultas. El ManejadorConsultas solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir", la PantallaConsultas enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultas. El ManejadorConsultas sale del sistema. El subflujo Consultar Horarios (S-2) se muestra a continuacin. S-2 Consultar Horarios Subflujos El ManejadorConsultaHorarios solicita desplegarPantallaConsultaHorarios a la InterfaceUsuario. (cont) La InterfaceUsuario despliega la PantallaConsultaHorarios. La PantallaConsultaHorarios se despliega. Esta pantalla debe ser llenada con informacin de ciudad de origen y destino, y preferencias opcionales de: aerolnea, horario y una opcin de vuelo slo directo. El Usuario puede seleccionar de las siguientes actividades: "Consultar", "Servicios" y "Salir". Si el usuario presiona Consultar, la PantallaConsultaHorarios enva el evento Consultar a la InterfaceUsuario. La InterfaceUsuario enva el evento Consultar al ManejadorConsultaHorarios. El ManejadorConsultaHorarios solicita consultarHorarios a la InterfaceBaseDatosReservas (E-1, E-2). La InterfaceBaseDatosReservas solicita consultarHorarios a la Base de Datos Reservas. La Base de Datos Reservas devuelve los Vuelos a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve los Vuelos al ManejadorConsultaHorarios. Se contina con el subflujo Devolver Horarios (S-3). Si el usuario presiona Servicios, la PantallaConsultaHorarios enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultaHorarios. El ManejadorConsultaHorarios solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir", la PantallaConsultaHorarios enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultaHorarios. El ManejadorConsultaHorarios sale del sistema.. El subflujo Devolver Horarios (S-3) se muestra a continuacin. Subflujos

Weitzenfeld: Captulo 7

50

S-3 Devolver Horarios El ManejadorConsultaHorarios solicita desplegarPantallaResultadoHorarios a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaResultadoHorarios. La PantallaResultadoHorarios despliega informacin de Vuelo, Aerolnea, Horarios de Salida y Llegada y Aeropuertos de Origen, Destino y Escalas con posibles conexiones. El usuario puede seleccionar entre las siguientes opciones: +, "-", Nueva Consulta, "Servicios" y "Salir". Si el usuario presiona "+", la PantallaResultadoHorarios enva el evento + a la InterfaceUsuario. La InterfaceUsuario enva el evento + al ManejadorConsultaHorarios. Se contina al inicio de este subflujo (presentando resultados adicionales). Si el usuario presiona "-", la PantallaResultadoHorarios enva el evento - a la InterfaceUsuario. La InterfaceUsuario enva el evento - al ManejadorConsultaHorarios. Se contina al inicio de este subflujo (presentando resultados anteriores). Si el usuario presiona Nueva Consulta, la PantallaResultadoHorarios enva el evento Nueva Consulta a la InterfaceUsuario. La InterfaceUsuario enva el evento Nueva Consulta al ManejadorConsultaHorarios. Se contina con el subflujo Consultar Horarios (S-2). Si la actividad seleccionada es "Servicios", la PantallaResultadoHorarios enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultaHorarios. El ManejadorConsultaHorarios solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir, la PantallaResultadoHorarios enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultaHorarios. El ManejadorConsultaHorarios sale del sistema. El subflujo Consultar Tarifas (S-4) se muestra a continuacin. S-4 Consultar Tarifas Subflujos El ManejadorConsultaTarifas solicita desplegarPantallaConsultaTarifas a la InterfaceUsuario. (cont) La InterfaceUsuario despliega la PantallaConsultaTarifas. La PantallaConsultaTarifas se despliega. Esta pantalla debe ser llenada con informacin de ciudad de origen y destino, y preferencias opcionales: fecha de salida, fecha de regreso, aerolnea, clase, y las opciones de organizar la informacin por menor tarifa, una opcin de vuelo si slo directo, y si la tarifa se basa en viaje redondo. El Usuario puede seleccionar de las siguientes actividades: "Consultar", "Servicios" y "Salir". Si el usuario presiona Consultar, la PantallaConsultaTarifas enva el evento Consultar a la InterfaceUsuario. La InterfaceUsuario enva el evento Consultar al ManejadorConsultaTarifas. El ManejadorConsultaTarifas solicita consultarTarifas a la InterfaceBaseDatosReservas (E-1,E2). La InterfaceBaseDatosReservas solicita consultarTarifas a la Base de Datos Reservas. La Base de Datos Reservas devuelve los Vuelos a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve los Vuelos al ManejadorConsultaTarifas. Se contina con el subflujo Devolver Tarifas (S-5). Si el usuario presiona Servicios, la PantallaConsultaTarifas enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultaTarifas. El ManejadorConsultaTarifas solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir", la PantallaConsultaTarifas enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultaTarifas. El ManejadorConsultaTarifas sale del sistema. El subflujo Devolver Tarifas (S-5) se muestra a continuacin. Subflujos (cont)

Weitzenfeld: Captulo 7

51

S-5 Devolver Tarifas El ManejadorConsultaTarifas solicita desplegarPantallaResultadoTarifas a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaResultadoTarifas. La PantallaResultadoTarifas despliega informacin de Vuelo, Aerolnea, Horarios de Salida y Llegada, Aeropuertos de Origen, Destino y Escalas con posibles conexiones y Tarifas de ida y vuelta. El usuario puede seleccionar entre las siguientes opciones: +, "-", "Nueva Consulta", "Servicios" y "Salir". Si el usuario presiona "+", la PantallaResultadoTarifas enva el evento + a la InterfaceUsuario. La InterfaceUsuario enva el evento + al ManejadorConsultaTarifas. Se contina al inicio de este subflujo (presentando resultados adicionales). Si el usuario presiona "-", la PantallaResultadoTarifas enva el evento - a la InterfaceUsuario. La InterfaceUsuario enva el evento - al ManejadorConsultaTarifas. Se contina al inicio de este subflujo (presentando resultados anteriores). Si el usuario presiona Nueva Consulta, la PantallaResultadoTarifas enva el evento Nueva Consulta a la InterfaceUsuario. La InterfaceUsuario enva el evento Nueva Consulta al ManejadorConsultaTarifas. Se contina con el subflujo Consultar Tarifas (S-4). Si la actividad seleccionada es "Servicios", la PantallaResultadoTarifas enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultaTarifas. El ManejadorConsultaTarifas solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir, la PantallaResultadoTarifas enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultaTarifas. El ManejadorConsultaTarifas sale del sistema. El subflujo Consultar Estado (S-6) se muestra a continuacin. S-6 Consultar Estado Subflujos El ManejadorConsultaEstado solicita desplegarPantallaConsultaEstado a la InterfaceUsuario. (cont) La InterfaceUsuario despliega la PantallaConsultaEstado. La PantallaConsultaEstado se despliega. Esta pantalla debe ser llenada con informacin de ciudad de origen y destino, la aerolnea, el nmero de vuelo, y la opcin de vuelo de hoy. El Usuario puede seleccionar de las siguientes actividades: "Consultar", "Regresar" y "Salir". Si el usuario presiona Consultar, la PantallaConsultaEstado enva el evento Consultar a la InterfaceUsuario. La InterfaceUsuario enva el evento Consultar al ManejadorConsultaEstado. El ManejadorConsultaEstado solicita consultarEstado a la InterfaceBaseDatosReservas (E-1,E2). La InterfaceBaseDatosReservas solicita consultarEstado a la Base de Datos Reservas. La Base de Datos Reservas devuelve el Vuelo a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve el Vuelo al ManejadorConsultaEstado. Se contina con el subflujo Devolver Estado (S-7). Si el usuario presiona Servicios, la PantallaConsultaEstado enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultaEstado. El ManejadorConsultaEstado solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir", la PantallaConsultaEstado enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultaEstado. El ManejadorConsultaEstado sale del sistema. El subflujo Devolver Estado (S-7) se muestra a continuacin. Subflujos (cont)

Weitzenfeld: Captulo 7

52

S-7 Devolver Estado El ManejadorConsultaEstado solicita desplegarPantallaResultadoEstado a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaResultadoEstado. La PantallaResultadoEstado despliega la informacin de Vuelo, Aerolnea, Horarios de Salida y Llegada, Aeropuertos de Origen, Destino y Escalas con posibles conexiones y Avin utilizado. El usuario puede seleccionar entre las siguientes opciones: "Nueva Consulta", "Servicios" y "Salir". Si el usuario presiona Nueva Consulta, la PantallaResultadoEstado enva el evento Nueva Consulta a la InterfaceUsuario. La InterfaceUsuario enva el evento Nueva Consulta al ManejadorConsultaEstado. Se contina con el subflujo Consultar Estado (S-6). Si la actividad seleccionada es "Servicios", la PantallaResultadoEstado enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorConsultaEstado. El ManejadorConsultaEstado solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir, la PantallaResultadoEstado enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorConsultaEstado. El ManejadorConsultaEstado sale del sistema.. Las excepciones del caso de uso se muestran a continuacin. E-1 informacin incompleta: Falta llenar informacin indispensable, ciudad de origen o de Excepciones destino. Se le vuelve a pedir al usuario la informacin. E-2 informacin invlida: Una de las entradas de la solicitud es incorrecta. Subflujos (cont) Hacer Reservacin El flujo principal del caso de uso Hacer Reservacin se muestra a continuacin. Hacer Reservacin Caso de Uso Usuario, Base de Datos Reservas Actores Bsico Tipo Permitir a un usuario hacer reservaciones con el sistema de reservaciones de vuelo. Propsito Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para crear, obtener, modificar y Resumen eliminar reservaciones de vuelos con el sistema de reservaciones. Precondiciones Se debe haber ejecutado anteriormente el caso de uso Validar Usuario. Flujo Principal Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuar con los diversos subflujos de este caso de uso. El subflujo Solicitar Clave Reservacin (S-1) se muestra a continuacin. S-1 Solicitar Clave Reservacin Subflujos El ManejadorReservas solicita desplegarPantallaClaveReservas a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaClaveReservas. La PantallaClaveReservas se despliega. El Usuario puede seleccionar entre las siguientes opciones: Crear, Obtener, Servicios y Salir. Si el Usuario selecciona "Crear", la PantallaClaveReservas enva el evento Crear a la InterfaceUsuario. La InterfaceUsuario enva el evento Crear al ManejadorReservas. Se contina con el subflujo Crear Reservacin (S-2). Si el Usuario selecciona "Obtener", la PantallaClaveReservas enva el evento Obtener a la InterfaceUsuario. La InterfaceUsuario enva el evento Obtener al ManejadorReservas. Se contina con el subflujo Obtener Reservacin (S-3) (E-1). Si el usuario presiona Servicios, la PantallaClaveReservas enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorReservas. El ManejadorReservas solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si el usuario presiona "Salir", la PantallaClaveReservas enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorReservas. El ManejadorReservas sale del sistema. El subflujo Crear Reservacin (S-2) se muestra a continuacin.

Weitzenfeld: Captulo 7

53

S-2 Crear Reservacin El ManejadorReservas solicita desplegarPantallaCrearReservaVuelos a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaCrearReservaVuelos. La PantallaCrearReservaVuelos se despliega. Esta pantalla debe ser llenada con informacin de apellido y nombre del pasajero, un nmero de viajero frecuente opcional, aerolnea, nmero de vuelo, ciudad de origen y destino, fecha, clase, una opcin de solicitar asiento y si desea ventana o pasillo, y opcionalmente comida vegetal o carne. El Usuario puede seleccionar entre las siguientes actividades: "Agregar", Borrar, "+", "-, "Reservar", "Servicios" y "Salir". Si el usuario presiona Agregar, la PantallaCrearReservaVuelos enva el evento Agregar a la InterfaceUsuario. La InterfaceUsuario enva el evento Agregar al ManejadorReservas. Se contina al inicio de este subflujo (solicitando reservaciones adicionales). Si el usuario presiona Borrar, la PantallaCrearReservaVuelos enva el evento Borrar a la InterfaceUsuario. La InterfaceUsuario enva el evento Borrar al ManejadorReservas. Se borran los datos recin insertados y se contina al inicio de este subflujo (solicitando reservaciones adicionales). Si el usuario presiona "+", la PantallaCrearReservaVuelos enva el evento + a la InterfaceUsuario. La InterfaceUsuario enva el evento + al ManejadorReservas. Se contina al inicio de este subflujo (presentando solicitudes adicionales). Si el usuario presiona "-", la PantallaCrearReservaVuelos enva el evento - a la InterfaceUsuario. La InterfaceUsuario enva el evento - al ManejadorReservas. Se contina al inicio de este subflujo (presentando solicitudes anteriores). Si el usuario selecciona Reservar, la PantallaCrearReservaVuelos enva el evento Reservara la InterfaceUsuario. La InterfaceUsuario enva el evento Reservaral ManejadorReservas (E2,E-3). El ManejadorReservas solicita crearReserva a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas solicita crearReserva a la Base de Datos Reservas. La Base de Datos Reservas devuelve la Reservacin a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve la Reservacin al ManejadorReservas (E-4). Se continua con el subflujo Administrar Reservacin (S-4). Si la actividad seleccionada es "Servicios", la PantallaCrearReservaVuelos enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorReservas. El ManejadorReservas solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaCrearReservaVuelos enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorReservas. El ManejadorReservas sale del sistema. El subflujo Obtener Reservacin (S-3) se muestra a continuacin. S-3 Obtener Reservacin Subflujos El ManejadorReservas solicita obtenerReserva a la InterfaceBaseDatosReservas. La (cont) InterfaceBaseDatosReservas solicita obtenerReserva a la Base de Datos Reservas (E-1). La Base de Datos Reservas devuelve la Reservacin a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve la Reservacin al ManejadorReserva. Se contina con el subflujo Administrar Reservacin (S-4). El subflujo Administrar Reservacin (S-4) se muestra a continuacin. Subflujos (cont)

Weitzenfeld: Captulo 7

54

S-4 Administrar Reservacin El ManejadorReserva solicita desplegarPantallaRecordReservaVuelos a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaRecordReservaVuelos. La PantallaRecordReservaVuelos despliega informacin de Reservacin, Vuelo, Aerolnea, Horarios de Salida y Llegada, Aeropuertos de Origen, Destino y Escalas con posibles conexiones y Tarifas de ida y vuelta. El Usuario pueden escoger las siguientes opciones: "Actualizar", "Eliminar", "+", "-", "Nueva Reserva", "Pagar", "Reembolsar", "Servicios" y "Salir". Si el usuario presiona Actualizar se ejecuta el subflujo Actualizar Reservacin (S-5). Si el usuario presiona Eliminar se ejecuta el subflujo Eliminar Reservacin (S-6). Si el usuario presiona "+", la PantallaRecordReservaVuelos enva el evento + a la InterfaceUsuario. La InterfaceUsuario enva el evento + al ManejadorReservas. Se contina al inicio de este subflujo (presentando resultados adicionales). Si el usuario presiona "-", la PantallaRecordReservaVuelos enva el evento - a la InterfaceUsuario. La InterfaceUsuario enva el evento - al ManejadorReservas. Se contina al inicio de este subflujo (presentando resultados anteriores). Si el usuario selecciona Nueva Reserva, la PantallaRecordReservaVuelos enva el evento Nueva Reserva a la InterfaceUsuario. La InterfaceUsuario enva el evento Nueva Reserva al ManejadorReservas. Se contina con el subflujo Crear Reservacin (S-2). Si la actividad seleccionada es Pagar, la PantallaRecordReservaVuelos enva el evento Pagar a la InterfaceUsuario. La InterfaceUsuario enva el evento Pagar al ManejadorReservas. El ManejadorReservas solicita pagarReservacin al ManejadorPagos, se contina con el caso de uso Pagar Reservacin. Si la actividad seleccionada es Reembolsar, la PantallaRecordReservaVuelos enva el evento Reembolsar a la InterfaceUsuario. La InterfaceUsuario enva el evento Reembolsar al ManejadorReservas. El ManejadorReservas solicita reembolsarReservacin al ManejadorPagos, se contina con el caso de uso Pagar Reservacin Si la actividad seleccionada es "Servicios", la PantallaRecordReservaVuelos enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorReservas. El ManejadorReservas solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaRecordReservaVuelos enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorReservas. El ManejadorReservas sale del sistema. El subflujo Actualizar Reservacin (S-5) se muestra a continuacin. S-5 Actualizar Reservacin Subflujos La PantallaRecordReservaVuelos enva el evento Actualizar a la InterfaceUsuario. La (cont) InterfaceUsuario enva el evento Actualizar al ManejadorReservas. El ManejadorReservas solicita actualizarReserva a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas solicita actualizarReserva a la Base de Datos Reservas (E-2,E-3). La Base de Datos Reservas devuelve la Reservacin a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve la Reservacin al ManejadorReserva (E-4). Se continua con el subflujo Adminsitrar Reservacin (S-4). El subflujo Eliminar Reservacin (S-6) se muestra a continuacin. S-6 Eliminar Reservacin Subflujos La PantallaRecordReservaVuelos enva el evento Eliminar a la InterfaceUsuario. La (cont) InterfaceUsuario enva el evento Eliminar al ManejadorReservas. El ManejadorReservas solicita eliminarReserva a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas solicita eliminarReserva a la Base de Datos Reservas (E-5). La Base de Datos Reservas devuelve el OK a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve el OK al ManejadorReserva. Se continua con el subflujo Crear Reservacin (S-2). Las excepciones del caso de uso se muestran a continuacin. Subflujos (cont)

Weitzenfeld: Captulo 7

55

Excepciones

E-1 rcord invlido: No existe el rcord especificado. E-2 informacin incompleta: Falta llenar informacin indispensable, ciudad de origen o de destino. Se le vuelve a pedir al usuario la informacin. E-3 informacin invlida: Una de las entradas de la solicitud es incorrecta. E-4 reserva sin xito: No se logr obtener una reserva. E-5 eliminacin reserva sin xito: No se logr eliminar la reserva.

Pagar Reservacin El flujo principal del caso de uso Pagar Reservacin se muestra a continuacin. Pagar Reservacin Caso de Uso Usuario, Base de Datos Reservas Actores Extensin Tipo Permitir a un usuario pagar reservaciones con el sistema de reservaciones de vuelo. Propsito Este caso de uso es iniciado por el Usuario. Ofrece funcionalidad para pagar y reembolsar pagos Resumen de reservaciones de vuelos con el sistema de reservaciones mediante tarjetas de crdito registradas con el sistema. Precondiciones Se requieren haber ejecutado anteriormente el caso de uso Validar Usuario y tener una Reserva ya hecha mediante el caso de uso Hacer Reservacin subflujo Crear Reservacin (S-2) Flujo Principal El ManejadorPagos solicita obtenerRegistroTarjeta al ManejadorRegistroTarjeta. Se contina con el caso de uso Registrar Tarjeta, subflujo Obtener Registro Tarjeta (S-2). El ManejadorRegistroTarjeta devuelve el OK y el RegistroTarjeta al ManejadorPagos. Dependiendo si la solicitud original del ManejadorReservas al ManejadorPagos fue pagarReservacin, se contina el subflujo Pagar Reservacin (S-1); si fue reembolsarReservacin, se contina con el subflujo Reembolsar Pago (S-2). El subflujo Pagar Reservacin (S-1) se muestra a continuacin. S-1 Pagar Reservacin Subflujos El ManejadorPagos solicita desplegarPantallaPagarRegistroTarjeta a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaPagarRegistroTarjeta. La PantallaPagarRegistroTarjeta despliega el RegistroTarjeta la cual incluye informacin de nombre como aparece en la tarjeta, nmero de tarjeta, el tipo de tarjeta, la fecha de vencimiento y la cantidad a pagar (E-1). El Usuario podr seleccionar entre las siguientes actividades: "Pagar", "Servicios" y "Salir". Si la actividad seleccionada es Pagar, la PantallaRecordReservaVuelos enva el evento "Pagar" a la InterfaceUsuario. La InterfaceUsuario enva el evento "Pagar" al ManejadorPagos. El ManejadorPagos solicita pagarReserva a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas solicita pagarReserva a la Base de Datos Reservas. La Base de Datos Reservas devuelve la Reservacin a la InterfaceBaseDatosReservas (E-2). La InterfaceBaseDatosReservas devuelve la Reservacin al ManejadorPagos. El ManejadorPagos devuelve la Reservacin al ManejadorReservas. Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es "Servicios", la PantallaPagarRegistroTarjeta enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorPagos. El ManejadorPagos solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaPagarRegistroTarjeta enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorPagos. El ManejadorPagos sale del sistema. El subflujo Reembolsar Pago (S-2) se muestra a continuacin.

Weitzenfeld: Captulo 7

56

S-2 Reembolsar Pago El ManejadorPagos solicita desplegarPantallaReembolsarRegistroTarjeta a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaReembolsarRegistroTarjeta. La PantallaReembolsarRegistroTarjeta despliega la informacin, lo cual incluye el nombre como aparece en la tarjeta, nmero de tarjeta, el tipo de tarjeta, la fecha de vencimiento y la cantidad a reembolsar (E-1). El Usuario podr seleccionar entre las siguientes actividades: "Reembolsar", "Servicios" y "Salir". Si la actividad seleccionada es Reembolsar, la PantallaRecordReservaVuelos enva el evento "Reembolsar" a la InterfaceUsuario. La InterfaceUsuario enva el evento "Reembolsar" al ManejadorPagos. El ManejadorPagos solicita reembolsarReserva a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas solicita reembolsarReserva a la Base de Datos Reservas (E-3, E-4). La Base de Datos Reservas devuelve la Reservacin a la InterfaceBaseDatosReservas. La InterfaceBaseDatosReservas devuelve la Reservacin al ManejadorPagos. El ManejadorPagos devuelve la Reservacin al ManejadorReservas. Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es "Servicios", la PantallaReembolsarRegistroTarjeta enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorPagos. El ManejadorPagos solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaReembolsarRegistroTarjeta enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorPagos. El ManejadorPagos sale del sistema. Las excepciones del caso de uso se muestran a continuacin. E-1 rcord invlido: No existe el rcord especificado. El usuario deber insertar los datos de la Excepciones tarjeta. E-2 pago invlido: El pago no tuvo xito o la informacin de pago est incompleta. E-3 pago inexistente: La reserva no ha sido an pagada. E-4 devolucin invlido: No se pudo hacer la devolucin del pago. Subflujos (cont) 7.6 Diccionario de Clases Como ltima etapa del modelo de anlisis, se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir todas las clases identificadas durante el modelo de anlisis. Aunque no es obigatorio, aprovechamos para separar estas clases en diferentes mdulos para lograr una mejor organizacin y correspondencia entre clases y casos de uso. Aquellas clases que participan en varios casos de uso se pueden asignar a mdulos adicionales, como veremos a continuacin para el sistema de reservaciones de vuelo. Comenzamos con cuatro mdulos o paquetes principales: InterfaceUsuario, Principal, Registro y Sevicios, como se muestra en la Figura 7.59.
InterfaceUsuario Principal

Registro

Servicios

Figura 7.59 Mdulos principales del sistema de reservaciones de vuelo. InterfaceUsuario El mdulo InterfaceUsuario est compuesto por una sla clase: ? ? InterfaceUsuario Clase Borde. Toda la interaccin con el usuario se hace por medio de la borde de usuario.

Weitzenfeld: Captulo 7

57

Principal El mdulo Principal est compuesto por dos clases: ? ? PantallaPrincipal - Clase Borde. Pantalla principal (P-1). ? ? ManejadorPrincipal - Clase Control. El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Registro El mdulo Registro se divide en los siguientes mdulos: RegistroPrincipal, Usuario y Tarjeta, como se muestra en la Figura 7.60.
RegistroPrincipal

Usuario

Tarjeta

Figura 7.60 Mdulos adicionales del mdulo Registro. RegistroPrincipal El mdulo RegistroPrincipal est compuesto por una sla clase: ? ? InterfaceBaseDatosRegistro - Clase Borde. La informacin de cada usuario se almacena en la base de datos de registro la cual se accesa mediante la borde de la base de datos de registro. Esto permite validar a los distintos usuarios adems de guardar informacin sobre la tarjeta de crdito para pagos en lnea. Usuario El mdulo Usuario est compuesto por las clases: ? ? PantallaCrearRegUsuario - Clase Borde. Pantalla de solicitud de registro de usuario (P-3). ? ? PantallaObtenerRegUsuario - Clase Borde. Pantalla de devolucin con informacin de registro de usuario (P4). ? ? RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de reservaciones, el usuario debe estar registrado con el sistema. El registro contiene informacin acerca del usuario que incluye nombre, direccin, colonia, ciudad, pas, cdigo postal, telfono de casa, telfono de oficina, fax, email, login y password. ? ? ManejadorRegistroUsuario - Clase Control. El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Tarjeta El mdulo Tarjeta est compuesto por las clases: ? ? PantallaCrearRegTarjeta - Clase Borde. Pantalla de solicitud de registro de tarjeta (P-5). ? ? PantallaObtenerRegTarjeta - Clase Borde. Pantalla de devolucin con informacin de registro de tarjeta (P6). ? ? RegistroTarjeta - Clase Entidad. Para poder hacer un pago con una tarjeta de crdito, se debe tener un registro de tarjeta. El registro contiene informacin acerca de la tarjeta incluyendo nombre, nmero, expedidor y vencimiento. LA tarjeta est ligada a un registro de usuario. ? ? ManejadorRegistroTarjeta - Clase Control. El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Servicios El mdulo Servicio se divide en los siguientes mdulos: ServicioPrincipal, Dominio, Consultas, Reservas, y Pagos, como se muestra en la Figura 7.61.

Weitzenfeld: Captulo 7

58

Servicio Principal

Dominio

Consultas

Reservas

Pagos

Figura 7.61 Mdulos adicionales del mdulo Servicios. ServicioPrincipal El mdulo ServicioPrincipal est compuesto por las clases: ? ? InterfaceBaseDatosReserva - Clase Borde. La informacin del sistema de reservaciones de vuelo se almacena en la base de datos de reservas la cual se accesa mediante la borde de la base de datos de reservas. Esto permite generar consultas, reservas y pago de reservas de manera dinmica. ? ? PantallaServicio - Clase Borde. Pantalla de servicios (P-2). ? ? ManejadorServicio - Clase Control. El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Dominio El mdulo Dominio est compuesto por las clases: ? ? Vuelo - Clase Entidad. Se denomina por medio de un nmero. El vuelo tiene como origen un aeropuerto en una ciudad y tiene como destino un aeropuerto de otra ciudad. Un vuelo puede tener mltiples escalas y mltiples vuelos se relacionan por medio de conexiones. El vuelo pertenece a una aerolnea y puede operar varios das a la semana teniendo un horario de salida y otro de llegada. ? ? Reservacin - Clase Entidad. Para poder tomar un vuelo es necesario contar con una reservacin previa, la cual debe pagarse antes de una fecha lmite, que puede ser el propio da del vuelo. Una reservacin puede hacerse para mltiples vuelos y mltiples pasajeros. La reservacin cuenta con una clave identificando un rcord de reservacin particular. ? ? Horario - Clase Entidad. El horario de un vuelo se determina por su hora de salida y hora de llegada durante los das que opera. ? ? Aerolnea - Clase Entidad. La aerolnea provee servicio de mltiples vuelos entre diferentes ciudades bajo diferentes horarios. La aerolnea se identifica por un nombre. ? ? Aeropuerto - Clase Entidad. El aeropuerto sirve como origen, destino y escalas de un vuelo. El aeropuerto se encuentra en una ciudad de un pas determinado. ? ? Tarifa - Clase Entidad. Los diferentes vuelos tienen mltiples tarifas para compra de boleto, variando segn la clase de boleto, si son de ida o de ida y vuelta, y dependiendo de las diversas restricciones y ofertas existentes. ? ? Asiento - Clase Entidad. Una reservacin de vuelo puede incluir la asignacin de asiento, especificada mediante una fila y un nmero. El nmero de asientos disponibles en un vuelo particular dependen del tipo de avin que opere ese da. ? ? Pasajero - Clase Entidad. Para poder hacer una reservacin se requiere dar el nombre del pasajero. Varios pasajeros pueden aparecer bajo una sola reservacin. ? ? Avin - Clase Entidad. Un vuelo en una fecha determinada se hace en un tipo de avin particular. El tipo de avin define la cantidad mxima de pasajeros que pueden viajar en ese vuelo para esa fecha. ? ? ViajeroFrecuente - Clase Entidad. El pasajero tiene la opcin de acumular millas para un vuelo particular si cuenta con una tarjeta de viajero frecuente para la aerolnea correspondiente. Consultas El mdulo Consultas se divide en los siguientes mdulos: ConsultasPrincipal, Horarios, Tarifas y Estado, como se muestra en la Figura 7.62.

Weitzenfeld: Captulo 7

59

Consultas Principal

Horarios

Tarifas

E stado

Figura 7.62 Mdulos adicionales del mdulo Consultas. ConsultasPrincipal El mdulo ConsutlasPrincipal est compuesto por las clases: ? ? PantallaConsultas - Clase Borde. Pantalla de presentacin de consultas (P-7). ? ? ManejadorConsultas - Clase Control. El manejador de consulta se encarga de enviar las peticiones de consulta particular a los manejadores de consulta especializados. Horarios El mdulo Horarios est compuesto por las clases: ? ? PantallaConsultaHorarios - Clase Borde. Pantalla de presentacin de consulta de horarios (P-8). ? ? PantallaResultadoHorarios - Clase Borde. Pantalla de devolucin de consulta de horarios (P-9). ? ? ManejadorConsultaHorarios - Clase Control. El manejador de consulta de horarios se encarga de controlar las peticiones de consulta de horarios. Tarifas El mdulo Tarifas est compuesto por las clases: ? ? PantallaConsultaTarifas - Clase Borde. Pantalla de presentacin de consulta de tarifas (P-10). ? ? PantallaResultadoTarifas - Clase Borde. Pantalla de devolucin de consulta de tarifas (P-11). ? ? ManejadorConsultaTarifas - Clase Control. El manejador de consulta de tarifas se encarga de controlar las peticiones de consulta de tarifas. Estado El mdulo Estado est compuesto por las clases: ? ? PantallaConsultaEstado - Clase Borde. Pantalla de presentacin de consulta de estado (P-12). ? ? PantallaResultadoEstado - Clase Borde. Pantalla de devolucin de consulta de estado (P-13). ? ? ManejadorConsultaEstado - Clase Control. El manejador de consulta de estado se encarga de controlar las peticiones de consulta de estado. Reservas El mdulo Reservas est compuesto por las clases: ? ? PantallaClaveReservas - Clase Borde. Pantalla de solicitud de clave de reservas (P-14). ? ? PantallaCrearReservaVuelos - Clase Borde. Pantalla de solicitud de reservas (P-15). ? ? PantallaRecordReservaVuelos - Clase Borde. Pantalla de devolucin de reservas (P-16). ? ? ManejadorReservas - Clase Control. El manejador de reserva se encarga de enviar las solicitudes de reserva a la base de datos del sistema de reservaciones. Pagos El mdulo Pagos est compuesto por las clases: ? ? PantallaPagarRegTarjeta - Clase Borde. Pantalla de solicitud de pago de reservas (P-17). ? ? PantallaReembolsarRegTarjeta - Clase Borde. Pantalla de solicitud de reembolso de pago (P-18).

Weitzenfeld: Captulo 7

60

??

ManejadorPagos - Clase Control. El manejador de compra se encarga de enviar las solicitudes de compra de boleto a la base de datos del sistema de reservaciones.

Weitzenfeld: Anlisis

10/11/2002

61

Weitzenfeld: Captulo 8

8 Modelo de Diseo El modelo de diseo es un refinamiento y formalizacin adicional del modelo de anlisis donde se toman en cuenta las consecuencias del ambiente de implementacin. El resultado del modelo de diseo son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se requiere un modelo de diseo ya que el modelo de anlisis no es lo suficientemente formal para poder llegar al cdigo fuente. Por tal motivo se debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la comunicacin entre los diferentes objetos, los eventos que los objetos envan entre si, etc. El sistema real debe adaptarse al ambiente de implementacin. En el anlisis se asume un mundo ideal para el sistema, en la realidad se debe adaptar el sistema al ambiente de implementacin, algo que puede cambiar durante el ciclo de vida del sistema. Se busca adems aspectos como, los requisitos de rendimiento, necesidades de tiempo real, concurrencia, el lenguaje de programacin, el sistema de manejo de base de datos, etc. Se desea tambin validar los resultados del anlisis. Segn el sistema crece y se formaliza, se ver qu tan bien los modelos de requisitos y anlisis describen al sistema. Durante el diseo, se puede ver si los resultados del anlisis son apropiados para su implementacin. Si se descubre aspectos que no estn claros en alguno de los modelos anteriores, estos deben ser clarificados, quizs regresando a etapas anteriores. Aunque esto pudiera verse como deficiencias del resultado de las fases anteriores que deben ser clarificadas aqu, esto sera una visin incorrecta de las diferentes etapas del desarrollo, ya que el propsito de los modelos de requisitos y anlisis es comprender el sistema y darle una buena estructura. Tambin es importante comprender que las consideraciones tomadas en cuenta durante el diseo deben influir en la estructura del sistema lo menos posible. Es la propia aplicacin la que controla la estructura, no las circunstancias de su implementacin. Se considera el modelo de diseo como una formalizacin del espacio de anlisis, extendindolo para incluir una dimensin adicional correspondiente al ambiente de implementacin, como se puede ver en el diagrama de la Figura 8.1.
comportamiento ambiente de implementacin

informacin

presentacin

Figura 8.1 El diseo aade el ambiente de implementacin como un nuevo eje de desarrollo. Esta nueva dimensin correspondiente al ambiente de implementacin debe considerarse al mismo tiempo que el propio modelo es refinado. La meta es refinarlo hasta que sea fcil escribir cdigo fuente. Como el modelo de anlisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del modelo de diseo, de manera que haya una continuidad de refinamiento entre los dos modelos, como se puede ver en el diagrama de la Figura 8.2. En particular se puede apreciar el cambio en los modelos a partir de la introduccin del ambiente de implementacin
modelo de anlisis modelo de diseo refinamiento introduccin del ambiente de implementacin

Figura 8.2 El modelo de diseo es una continuacin del modelo de anlisis. La transicin de anlisis a diseo debe decidirse por separado para cada aplicacin particular. Aunque es posible continuar trabajando sobre el modelo de anlisis, incluso durante la incorporacin del ambiente de implementacin, esto no es recomendable, ya que aumenta su complejidad. Por lo tanto, es deseable tener un modelo de anlisis ideal del sistema durante el ciclo de vida completo del sistema, dado que muchos de los cambios del sistema provienen de cambios en el ambiente de implementacin. Tales cambios son entonces fcilmente incorporados, ya que el mismo modelo de anlisis sirve de base para el nuevo modelo de diseo. De esta manera se puede ver el modelo de diseo como una especializacin del modelo de anlisis segn un ambiente de implementacin especfico.

Weitzenfeld: Captulo 8

Si un cambio en el modelo de diseo proviene de un cambio en la lgica del sistema, entonces tales cambios deben hacerse en el modelo de anlisis. Sin embargo, si el cambio es una consecuencia de la implementacin, entonces tales cambios no deben ser incorporados en el modelo de anlisis. Las estructuras con las cuales se trabaja en el modelo de diseo son bsicamente las mismas que en el modelo de anlisis. Sin embargo, el punto de vista cambia, ya que se toma un paso hacia la implementacin. El modelo de anlisis debe se visto como un modelo conceptual y lgico del sistema, mientras que el modelo de diseo debe acercarse al cdigo fuente. Esto significa que se cambia el punto del vista del modelo de diseo a una abstraccin del cdigo fuente final. Por lo tanto el modelo de diseo debe ser una descripcin de cmo el cdigo fuente debe ser estructurado, administrado y escrito. En cierta manera este enfoque es una extensin del concepto de la separacin de la poltica de la implementacin, donde la poltica fue definida durante el modelo de anlisis y el diseo tiene la responsabilidad mantener esta separacin durante el diseo de mtodos, aquellos que sirven para tomar decisiones (control) y aquellos que no (interface y entidad). En general, cambios en la arquitectura del sistema para mejorar el rendimiento del sistema deben ser pospuestos hasta que el sistema est (parcialmente) construido. La experiencia muestra que en los sistemas grandes y complejos, uno frecuentemente adivina incorrectamente cuales son los cuellos de botella crticos al rendimiento. Para hacer una evaluacin ms adecuada es necesario evaluar parte del rendimiento del sistema construido, algo que tambin se puede ir adelantando a nivel de prototipos. Para llevar a cabo estos objetivos, se considera por separado los dos aspectos principales del modelo de diseo: el diseo de objetos y el diseo de sistema: ? ? Diseo de Objetos. Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se describe cmo interaccionan los objetos en cada caso de uso especfico, especificando qu debe hacer cada operacin en cada objeto. Este paso genera las interfaces de los objetos, las cuales deben ser luego implementadas mediante mtodos. ? ? Diseo de Sistema. Se adapta el modelo al ambiente de implementacin. Este paso incluye identificar e investigar las consecuencias del ambiente de implementacin sobre el diseo. Aqu deben ser tomadas las decisiones de implementacin estratgicas: (i) cmo se incorporar una base de datos en el sistema, (ii) qu bibliotecas de componentes se usarn y cmo, (iii) qu lenguajes de programacin se utilizarn, (iv) cmo se manejarn los procesos, incluyendo comunicacin y requisitos de rendimiento, (v) cmo se disear el manejo de excepciones y recoleccin de basura, etc. Por ejemplo, como se mencion en el Captulo 5, la mayora de los lenguajes de programacin no tienen forma de implementar directamente una asociacin. Durante el diseo se debe decidir cmo mecanismos abstractos como la asociacin, sern implementados. Similarmente, si el lenguaje de programacin no ofrece ninguna tcnica para apoyar herencia, se debe especificar cmo sta ser implementada. En resumen, se debe especificar cmo las circunstancias del ambiente de implementacin deben ser manejadas en el sistema. En general, si el ambiente de implementacin tiene pocas consecuencias en el sistema, el diseo se basar casi exclusivamente en el diseo de objetos, o sea, en una extensin directa y detallada del modelo de anlisis describiendo los atributos y operaciones del sistema. Por el contrario, si el ambiente de implementacin afecta de manera importante al sistema, el diseo se basar en una combinacin de diseo de objetos y diseo de sistema, o sea, en un modelo de anlisis que dirije el resultado final del sistema aunque este ser adaptado de manera importante al ambiente de implementacin. En nuestro caso minimizaremos el efecto del ambiente de implementacin sobre el sistema, razn por la cual comenzaremos con la descripcin del diseo de objetos. Posteriormente describiremos los aspectos particulares relacionados con el diseo de sistema. A continuacin describimos algunas estrategias generales de diseo antes de proseguir con los aspectos especficos del diseo. 8.1 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 extensibilidad del sistema. Arquitectura El 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,

Weitzenfeld: Captulo 8

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, colecciones de objetos tales como listas o arreglos, 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 clases 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. Robustez La 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,

Weitzenfeld: Captulo 8

?? ??

??

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 encapsulamiento 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. nicamente la interface delos mtodos afecta a las dems clases.

Reuso El 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 llegando 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 encapsulamiento es muy efectivo para lograr el reuso, pudindose aplicar tanto al nivel de los objetos como de componentes desarrollados en otras aplicaciones. Estos componentes pueden ser reutilizables como fueron diseados a simplemente agregando nuevas interfaces. Extensibilidad La 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 (case) 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 de casos. 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 Objetos El diseo de objetos es un proceso de aadir detalles al anlisis y tomar decisiones junto con diseo de sistema, o sea al ambiente de implementacin, de manera que podamos lograr una especificacin detallada antes de comenzar la implementacin final. Algunos de los aspectos a ser resueltos diseo de objetos son determinar cmo las clases, atributos y asociaciones del modelo de anlisis deben implementarse en estructuras de datos especificas. Tambin es necesario determinar si se requiere introducir nuevas clases en el modelo de diseo para los cuales no se tiene

Weitzenfeld: Captulo 8

ninguna representacin en el modelo de anlisis o si se requiere modificar o eliminar clases identificadas durante el modelo de anlisis. Se debe agregar herencia para incrementar el reuso del sistema. Tambin es necesario determinar los algoritmos para implementar las operaciones, as como todos los aspectos de optimizaciones. Para el diseo de objeto se seguir el diseo por responsabilidades (RDD - Responsibility-Driven Design). Este diseo est basado en un modelo cliente-servidor donde las clases son vistas como clientes cuando generan alguna peticin hacia otra clase y como servidores cuando reciben peticiones de alguna otra clase. De tal manera, una misma clase puede ser vista en distintos momentos como cliente o servidor. La funcionalidad ofrecida por las clases servidores se define en trmino de sus responsabilidades, las cuales deben ser satisfechas por lograr sus servicios con las dems clases. Los servicios y responsabilidades correspondern finalmente a los mtodos de la clase. A su vez, las clases servidores a su vez pueden tener colaboraciones con otras clases para lograr la satisfaccin de responsabilidades que por si solas no pueden lograr. Como consecuencia de esto, se integran las responsabilidades y colaboraciones entre clases para definir contratos los cuales definen la naturaleza y alcance de las interacciones cliente-servidor. Los contratos y colaboraciones representan los requisitos de servicios entre los objetos. En resumen, se buscar identificar los contratos entre los objetos cliente y servidor diseando su distribucin entre los distintos objetos del sistema. En la siguientes secciones describiremos estos conceptos y todo lo relacionado con el diseo por responsabilidades. En las siguientes secciones especificaremos los aspectos mencionados a continuacin con mayor detalle: ? ? Especificacin de las tarjetas de clases. ? ? Identificacin de las responsabilidades del sistema. ? ? Identificacin de las colaboraciones del sistema. ? ? Identificacin de las jerarquas de herencia del sistema. ? ? Identificacin de los contratos de servicio del sistema. ? ? Identificacin de los subsistemas del sistema. ? ? Identificacin de los protocolos del sistema. ? ? Identificacin de los atributos del sistema. ? ? Especificacin de los algoritmos del sistema. Tarjetas de Clase Las tarjetas de clases (tambin conocidas como tarjetas CRC: Clase-Responsabilidad-Colaboracin) permiten al diseador visualizar las diferentes clases de manera independiente y detallada. El esquema para una tarjeta de clase se muestra en la Tabla 8.1. Clase: Descripcin: Mdulo: Estereotipo: Propiedades: Superclases: Subclases: Atributos:

Tabla 8.1. Diagrama para la tarjeta de clase. La tarjeta se divide en tres secciones: ? ? Encabezado consistiendo del nombre de la clase, una descripcin de la clase (similar a la descrita en el diccionario de clases de anlisis), el mdulo al que pertenece la clase, el estereotipo de la clase (entidad, interface o control), las propiedades de la clase (abstracta o concreta), una lista de superclases, una lista de subclases y una lista de atributos. ? ? Dos columnas debajo del encabezado, correspondientes a las responsabilidades (a la izquierda) y colaboraciones (a la derecha) de la clase. Eventualmente en la columna izquierda se incluir informacin sobre los contratos. El nmero de filas en estas dos columnas es extensible y no est limitado al nmero que aparece en el diagrama de la Tabla 8.1.

Weitzenfeld: Captulo 8

Originalmente, detrs de cada tarjeta se agregaba una descripcin corta del propsito de cada clase, algo que haremos a travs del diccionario de clases. Adems, incluimos algunos datos adicionales al esquema original CRC. Como ejemplo consideremos la clase InterfaceUsuario, una de las clases identificadas durante el modelo de anlisis para el ejemplo del sistema de reservaciones de vuelo. La tarjeta de clase sera la que se muestra en la Tabla 8.2. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos:

Tabla 8.2. Diagrama para la tarjeta de clase de InterfaceUsuario De tal manera se debe especificar una tarjeta para cada clase en el sistema, donde inicialmente las tarjetas incluirn nicamente entradas para el nombre de la clase, mdulo al que pertenecen y estereotipo correspondiente. Dado que an no se ha identificado herencia, no habrn entradas para propiedades, superclase o subclase. Como se puede apreciar, inicialmente las tarjetas de clase tendrn informacin muy limitada, algo que a lo largo del diseo ser extendido hasta alcanzar los mtodos y atributos detallados. Una vez creadas estas tarjetas procedemos a identificar las responsabilidades de cada clase como veremos a continuacin. Responsabilidades Uno de los esfuerzos ms grandes del desarrollo y que involucra mayor complejidad es la especificacin del comportamiento de cada una de las clases del sistema. A diferencia de la estructura interna de una clase, representada mediante sus atributos, los comportamientos corresponden a las operaciones y mtodos de las clases. Dado que por lo general el nmero resultante de mtodos en un sistema es mucho mayor que el de clases, el proceso de diseo involucra mayor complejidad que el de anlisis. Si consideramos tambin la existencia de los atributos y las propias implementaciones de los mtodos dentro de cada clase, la complejidad aumenta drsticamente. Sin embargo, esta complejidad no radica exclusivamente en el nmero de mtodos, sino en el hecho que potencialmente todos los mtodos de un objeto pueden ser llamados por todos los objetos del sistema. Esta es la verdadera fuente de la complejidad en la arquitectura del sistema, ya que cualquier cambio en uno de estos mtodos afectar potencialmente a todo el resto del sistema. Por lo tanto, es necesario llevar a cabo un proceso muy cuidadoso para la identificacin del comportamiento de las diversas clases. En general, el comportamiento de las clases no debe descomponerse directamente en operaciones, sino seguir un procedimiento ms natural comenzando con una descripcin verbal de las responsabilidades o roles que tiene cada clase dentro del sistema. Obviamente, cada objeto instanciado de una misma clase tendr responsabilidades similares a las descritas por la clase. Las responsabilidades ofrecidas por un objeto corresponden a los servicios apoyados por ste. A partir de estas responsabilidades se podr eventualmente determinar las operaciones que cada objeto debe tener e incluso el conocimiento que el objeto posee. Las responsabilidades se identifican a partir de los casos de uso generados durante el modelo de anlisis. Para ello, se revisa el modelo de casos de uso, haciendo una lista o subrayando todos las frases descritas para determinar cuales de stas representan acciones que algn objeto dentro del sistema deba ejecutar. Una de las decisiones ms importantes durante la identificacin de responsabilidades es a qu clase o clases se les debe asignar. Para ello se debe examinar el contexto en el cual se identificaron las responsabilidades. Se debe asignar responsabilidades a las clases que almacenen la informacin ms relacionada con la responsabilidad. En otras palabras, si un objeto requiere cierta informacin, es lgico asignarle la responsabilidad de mantener esa informacin. Si la informacin cambia, no ser necesario enviar mensajes de actualizacin a otros objetos. Esto tambin significa que la responsabilidad de mantener la informacin no debe se compartida. Compartir informacin implica una duplicacin que puede dar lugar a inconsistencias. Si ms de un objeto tiene responsabilidad sobre la misma informacin se debera reasignar la responsabilidad a un slo objeto. Tambin puede ocurrir que cierta responsabilidad agrupe varias responsabilidades juntas. En tal caso se puede dividir o compartir la responsabilidad entre dos o ms objetos. Si se vuelve difcil decidir a quien se debe asignar una responsabilidad, se

Weitzenfeld: Captulo 8

puede experimentar con diversas alternativas, con la ventaja de que durante las primeras etapas del diseo, este proceso no es muy costoso. Ser mucho ms difcil y tomar ms tiempo hacerlo despus de haber implementado el sistema completo. En cuanto a la especificacin de las responsabilidades, se debe describir las responsabilidades en trminos generales, para poder luego encontrar ms fcilmente responsabilidades compartidas entre clases. Por lo tanto, no es necesario considerar aspectos especficos de las responsabilidades, como nombres particulares o incluso parmetros. Otra consideracin es asegurarse que los ciclos de responsabilidades y colaboraciones entre clases no sean interrumpidos y mantengan siempre una correspondencia con la arquitectura establecida durante el anlisis. Consideremos el sistema de reservaciones de vuelos. Dado que la complejidad de un sistema se incrementa radicalmente durante el diseo en relacin a la arquitectura desarrollada durante el anlisis, procederemos con la descripcin de solamente una parte del sistema, mientras que el resto del diseo se mostrar en los apndices. Para ello nos concentraremos inicialmente en los casos de uso relacionados con registro: Registrar Usuario, Validar Usuario y Registrar Tarjeta. Validar Usuario A continuacin mostramos el flujo principal del caso de uso Validar Usuario como se present al final del captulo de anlisis. Flujo Principal El ManejadorPrincipal solicita desplegarPantallaPrincipal a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaPrincipal. La PantallaPrincipal se despliega. El Usuario puede seleccionar entre las siguientes opciones: "Registrarse por Primera Vez", "OK" y "Salir". Si la actividad seleccionada es "Registrarse por Primera Vez", la PantallaPrincipal enva el evento Registrarse por Primera Vez a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrarse por Primera Vez al ManejadorPrincipal. El ManejadorPrincipal solicita crearRegistroUsuario al ManejadorRegistroUsuario. Se ejecuta el caso de uso Registrar Usuario, subflujo Crear Registro Usuario (S-1). Si la actividad seleccionada es "OK", se valida el registro de usuario mediante un login y un password insertados por el Usuario en la PantallaPrincipal. La PantallaPrincipal enva el evento OK a la InterfaceUsuario. La InterfaceUsuario enva el evento OK al ManejadorPrincipal. El ManejadorPrincipal solicita validarRegistroUsuario al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita validarRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro valida al usuario y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. El ManejadorRegistroUsuario devuelve el OK al ManejadorPrincipal. Una vez validado el usuario (E-1), el ManejadorPrincipal solicita ofrecerServicio al ManejadorServicio. Se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaPrincipal enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorPrincipal. El ManejadorPrincipal sale del sistema. Tomamos cada una de las frases que describen el flujo y las analizaremos para decidir que responsabilidad representan y a que clase se le asignan: 1. El ManejadorPrincipal solicita desplegarPantallaPrincipal a la InterfaceUsuario. La primera pregunta es cul es la responsabilidad. La responsabilidad que podemos identificar aqu es solicita desplegarPantallaPrincipal. La siguiente pregunta es a quin se le asigna la responsabilidad. Existen dos opciones, asignar solicita desplegarPantallaPrincipal al ManejadorPrincipal o asignar desplegarPantallaPrincipal a la InterfaceUsuario. Para simplificar nuestra decisin y asegurarnos al menos en esta etapa de no perder ninguna informacin, tomaremos una de cisin salomnica, asignaremos dos responsabilidades, una a cada clase. Esto es muy importante, ya que nos aseguramos de comenzar con un buen nmero de responsabilidades que podremos luego reorganizar durante el transcurso del diseo. Es importante resaltar que dado que muchas responsabilidades pudieran darse de manera duplicada, trataremos de evitar esto revisando las frases que pudiesen generar tales duplicaciones. Por lo tanto, asignaremos la responsabilidad inicial de solicta desplegarPantallaPrincipal al ManejadorPrincipal, definiendo la responsabilidad de manera completa como solicta desplegarPantallaPrincipal a la InterfaceUsuario. Como veremos con la segunda frase, la responsabilidad de desplegarPantallaPrincipal ser asignada de manera adecuada a la InterfaceUsuario por lo cual no ser necesario hacerlo en este momento. Sin embargo, siempre revisamos que exista la

Weitzenfeld: Captulo 8

2.

3.

4.

5.

6.

7.

8. 9.

10. 11.

12. 13.

14.

15. 16. 17.

responsabilidad complementaria para la segunda clase en la frase. El objetivo esencial es asegurarse de asignar responsabilidades a las diferentes clases de manera que no se rompa con el flujo de colaboraciones, algo que debe tratarse con sumo cuidado para resolver cuanto antes el problema general de asignacin de servicios. Se debe tambin recordar que habrn varias etapas dentro de la actividad de diseo donde se podr afinar la asignacin de responsabilidades. La InterfaceUsuario despliega la PantallaPrincipal. De manera anloga a la oracin anterior, la responsabilidad que identificamos es despliega la PantallaPrincipal y la asignamos a InterfaceUsuario utilizando la misma lgica anterior. Ntese que esta responsabilidad corresponde al servicio solicitado por ManejadorPrincipal en la oracin anterior. Esto resalta el hecho de que las responsabilidades se estn asignando de manera correcta y sin romper el flujo de colaboraciones. La PantallaPrincipal se despliega. Esta responsabilidad se asigna a la nica clase involucrada que es PantallaPrincipal. Ntese tambin, que esta responsabilidad, despliega, corresponde al servicio de despliegue de la PantallaPrincipal referido en la oracin anterior. El Usuario puede seleccionar entre las siguientes opciones: "Registrarse por Primera Vez", "OK" y "Salir". En general los actores no son parte de la arquitectura del sistema por lo cual no se les asigna ninguna responsabilidad. Adems, los actores son bastante irresponsables (en particular los usuarios)! Si la actividad seleccionada es Registrarse por Primera Vez, la PantallaPrincipal enva el evento Registrarse por Primera Vez a la InterfaceUsuario. De manera anloga a las asignaciones anteriores, se asigna la responsabilidad enva el evento Registrarse por Primera Vez a la InterfaceUsuario a la PantallaPrincipal. Dado que en la siguiente frase la InterfaceUsuario enva a su vez el evento a otra clase, no agregamos ninguna responsabilidad adicional a esta ltima clase. La InterfaceUsuario enva el evento Registrarse por Primera Vez al ManejadorPrincipal. De manera similar, se asigna la responsabilidad enva el evento Registrarse por Primera Vez al ManejadorPrincipal a la InterfaceUsuario. Regresando a la discusin original de la asignacin de responsabilidades a ambas clase, podemos notar que la siguiente frase no asigna una responsabilidad de recibir el evento a la clase ManejadorPrincipal. Por tal motivo, haremos una segunda asignacin de responsabilidad, la cual llamaremos maneja el evento Registrarse por Primera Vez y la asignaremos al ManejadorPrincipal. El ManejadorPrincipal solicita crearRegistroUsuario al ManejadorRegistroUsuario. Se asigna la responsabilidad solicita crearRegistroUsuario al ManejadorRegistroUsuario al ManejadorPrincipal. Adicionalmente, asignamos la responsabilidad crearRegistroUsuario al ManejadorRegistroUsuario, ya que si nos fijamos ms adelante, en el caso de uso Registrar Usuario, subflujo Crear Registro Usuario (S-1), no se continua con una frase que defina la misma responsabilidad complementaria. Se ejecuta el caso de uso Registrar Usuario, subflujo Crear Registro Usuario (S-1). Esta frase no genera ninguna responsabilidad, slo una ramificacin en el flujo del caso de uso. Si la actividad seleccionada es "OK", se valida el registro de usuario mediante un login y un password insertados por el Usuario en la PantallaPrincipal. Oraciones que describen responsabilidades para actores no son incluidas ya que no agregan responsabilidades. La PantallaPrincipal enva el evento OK a la InterfaceUsuario. La responsabilidad es enva el evento OK a la InterfaceUsuario y se asigna a PantallaPrincipal. La InterfaceUsuario enva el evento OK al ManejadorPrincipal. La responsabilidad es enva el evento OK al ManejadorPrincipal y se asigna a InterfaceUsuario. Adicionalmente, se asigna la responsabilidad maneja el evento OK y se asigna al ManejadorPrincipal. El ManejadorPrincipal solicita validarRegistroUsuario al ManejadorRegistroUsuario. La responsabilidad es solicita validarRegistroUsuario al ManejadorRegistroUsuario y se asigna a ManejadorPrincipal. El ManejadorRegistroUsuario solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro. La responsabilidad es solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro y se asigna a ManejadorRegistroUsuario. La InterfaceBaseDatosRegistro solicita validarRegistroUsuario a la Base de Datos Registro. La responsabilidad es solicita validarRegistroUsuario a la Base de Datos Registro y se asigna a InterfaceBaseDatosRegistro. La Base de Datos Registro valida al usuario y devuelve el OK a la InterfaceBaseDatosRegistro. Esta frase no agrega responsabilidades ya que involucra un actor externo al sistema junto con un evento de devolucin. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Esta frase no agrega responsabilidades ya que describe un evento de devolucin. El ManejadorRegistroUsuario devuelve el OK al ManejadorPrincipal. Nuevamente, esta frase no agrega responsabilidades ya que describe un evento de devolucin.

Weitzenfeld: Captulo 8

18. Una vez validado el usuario (E-1), el ManejadorPrincipal solicita ofrecerServicio al ManejadorServicio. La responsabilidad es solicita ofrecerServicio al ManejadorServicio la cual se asigna a ManejadorPrincipal. Adicionalmente asignamos la responsabilidad ofrecerServicio a la clase ManejadorServicio para asegurarse que exista una responsabilidad complementaria en esta ltima clase. 19. Se contina con el caso de uso Ofrecer Servicios. Esta es una frase que describe continuacin entre casos de uso y no agrega ninguna responsabilidad. 20. Si la actividad seleccionada es Salir, la PantallaPrincipal enva el evento Salir a la InterfaceUsuario. Se asigna la responsabilidad enva el evento Salir a la InterfaceUsuario a la PantallaPrincipal. 21. La InterfaceUsuario enva el evento Salir al ManejadorPrincipal. Se asigna la responsabilidad enva el evento Salir al ManejadorPrincipal a la InterfaceUsuario. Se asigna adicionalmente la responsabilidad maneja el evento Salir al ManejadorPrincipal. 22. El ManejadorPrincipal sale del sistema. Se asigna la responsabilidad sale del sistema al ManejadorPrincipal. A partir de estas frases obtenemos nuestras primeras responsabilidades y las insertamos en las tarjetas de clase correspondientes, logrando una versin preliminar de las tarjetas de clase. En general, las tarjetas tienen la ventaja de forzar a uno a ser breve, de tal manera que las responsabilidades se listan lo ms compacto posible. En la Tabla 8.3 se muestra las responsabilidades identificadas hasta el momento para la clase ManejadorPrincipal. Ntese, que agregamos entre parntesis el ndice de la frase de la cual provienen en la descripcin del caso de uso. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: solicita desplegarPantallaPrincipal a la InterfaceUsuario (1) maneja el evento Registrarse por Primera Vez (6) solicita crearRegistroUsuario al ManejadorRegistroUsuario (7) maneja el evento OK (11) solicita validarRegistroUsuario al ManejadorRegistroUsuario (12) solicita ofrecerServicio al ManejadorServicio (18) maneja el evento Salir (21) sale del sistema (22) Tabla 8.3. Tarjeta para la clase ManejadorPrincipal con responsabilidades identificadas hasta el momento. La Tabla 8.5 muestra las responsabilidades identificadas hasta el momento para la clase PantallaPrincipal. Clase: PantallaPrincipal Descripcin: Pantalla principal (P-1). Mdulo: Principal Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (3) enva el evento Registrarse por Primera Vez a la InterfaceUsuario (5) enva el evento OK a la InterfaceUsuario (10) enva el evento Salir a la InterfaceUsuario (20) Tabla 8.5. Tarjeta para la clase PantallaPrincipal con responsabilidades identificadas hasta el momento. La Tabla 8.6 muestra las responsabilidades identificadas hasta el momento para la clase ManejadorRegistroUsuario. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para

Weitzenfeld: Captulo 8

10

poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario (7) solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro (13) Tabla 8.6. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento. La Tabla 8.7 muestra las responsabilidades identificadas hasta el momento para la clase InterfaceBaseDatosRegistro. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) Tabla 8.7. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. La Tabla 8.8 muestra las responsabilidades identificadas hasta el momento para la clase ManejadorServicio. Clase: ManejadorServicio Descripcin: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Mdulo: Servicios Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: ofrecerServicio (18) Tabla 8.8. Tarjeta para la clase ManejadorServicio con responsabilidades identificadas hasta el momento. Es posible tambin obtener responsabilidades a partir de las frase descritas en el manejo de excepciones, como se muestra a continuacin. E-1 no hubo validacin: El login/password no se valid correctamente. Se le pide al usuario que Excepciones vuelva a intentar hasta tres veces despus de lo cual se saldr del sistema. Sin embargo, nos concentraremos nicamente en los flujos bsicos y no los alternos. En general, los flujos alternos, como los de excepcin, son los menos comunes y son importantes de disear pero no en una primera etapa. Ofrecer Servicios A continuacin mostramos el flujo principal del caso de uso Validar Usuario como se present al final del captulo de anlisis.

Weitzenfeld: Captulo 8

11

El ManejadorServicio solicita desplegarPantallaServicio a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaServicio. La PantallaServicio se despliega. El Usuario puede seleccionar entre las siguientes actividades: Consultar Informacin, Hacer Reservacin, "Obtener Registro" y "Salir". Si la actividad seleccionada es "Consultar Informacin", la PantallaServicio enva el evento Consultar Informacin a la InterfaceUsuario. La InterfaceUsuario enva el evento Consultar Informacin al ManejadorServicio. El ManejadorServicio solicita consultar al ManejadorConsultas. Se contina con el caso de uso Consultar Informacin, subflujo Consultar (S-1). Si la actividad seleccionada es "Hacer Reservacin", la PantallaServicio enva el evento Hacer Reservacin a la InterfaceUsuario. La InterfaceUsuario enva el evento Hacer Reservacin al ManejadorServicio. El ManejadorServicio solicita reservar al ManejadorReservas. Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Si la actividad seleccionada es "Obtener Registro", la PantallaServicio enva el evento Obtener Registro a la InterfaceUsuario. La InterfaceUsuario enva el evento Obtener Registro al ManejadorServicio. El ManejadorServicio solicita registrar al ManejadorRegistroUsuario. Se contina con el caso de uso Registrar Usuario, subflujo Obtener Registro Usuario (S-2). Si la actividad seleccionada es "Salir", la PantallaServicio enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorServicio. El ManejadorServicio sale del sistema. Nuevamente, tomamos cada una de las frases que describen el flujo y las analizaremos para decidir que responsabilidad representan y a que clase se le asignan: 23. El ManejadorServicio solicita desplegarPantallaServicio a la InterfaceUsuario. La responsabilidad es solicita desplegarPantallaServicio a la InterfaceUsuario y se asigna a ManejadorServicio. 24. La InterfaceUsuario despliega la PantallaServicio. La responsabilidad despliega la PantallaServicio se asigna a InterfaceUsuario. 25. La PantallaServicio se despliega. La responsabilidad es despliega y se asigna a PantallaServicio. 26. El Usuario puede seleccionar entre las siguientes actividades: Consultar Informacin, Hacer Reservacin, "Obtener Registro" y "Salir". Esta frase es informativa describiendo opciones del Usuario, por lo cual no se agregan responsabilidades adicionales. Las siguientes frases permiten identificar responsabilidades relaciondas con los casos de uso Consultar Informacin y Hacer Reservacin. Sin embargo, no desarrollaremos por el momento el diseo relacionado a estos casos de usos. Esto afecta a las frase 27-34. 27. Si la actividad seleccionada es "Consultar Informacin", la PantallaServicio enva el evento Consultar Informacin a la InterfaceUsuario. 28. La InterfaceUsuario enva el evento Consultar Informacin al ManejadorServicio. 29. El ManejadorServicio solicita consultar al ManejadorConsultas. 30. Se contina con el caso de uso Consultar Informacin, subflujo Consultar (S-1). 31. Si la actividad seleccionada es "Hacer Reservacin", la PantallaServicio enva el evento Hacer Reservacin a la InterfaceUsuario. 32. La InterfaceUsuario enva el evento Hacer Reservacin al ManejadorServicio. 33. El ManejadorServicio solicita reservar al ManejadorReservas. 34. Se contina con el caso de uso Hacer Reservacin, subflujo Solicitar Clave Reservacin (S-1). Retomamos el proceso de identificacin de responsabilidades a partir de la siguiente frase, correspondiente a lgica relacionada con el caso de uso de Registrar Usuario. 35. Si la actividad seleccionada es "Obtener Registro", la PantallaServicio enva el evento Obtener Registro a la InterfaceUsuario. La responsabilidad es enva el evento Obtener Registro a la InterfaceUsuario y se asigna a PantallaServicio. 36. La InterfaceUsuario enva el evento Obtener Registro al ManejadorServicio. La responsabilidad es enva el evento Obtener Registro al ManejadorServicio y se asigna a la InterfaceUsuario. Asignamos de manera similar, la responsabilidad maneja el evento Obtener Registro al ManejadorServicio. 37. El ManejadorServicio solicita registrar al ManejadorRegistroUsuario. La responsabilidad es solicita registrar al ManejadorRegistroUsuario y se asigna al ManejadorServicio. Aunque deberamos asignar al responsabilidad complementaria al ManejadorRegistroUsuario, si continuamos con el sublujo correspondiente podremos observar que la responsabilidad obtenerRegistroUsuario se asigna ms adelante. Flujo Principal

Weitzenfeld: Captulo 8

12

38. Se contina con el caso de uso Registrar Usuario, en el subflujo Obtener Registro Usuario (S-2). Esta oracin no involucra ninguna responsabilidad. 39. Si la actividad seleccionada es "Salir", la PantallaServicio enva el evento Salir a la InterfaceUsuario. Se asigna la responsabilidad enva el evento Salir a la InterfaceUsuario a la clase PantallaServicio. 40. La InterfaceUsuario enva el evento Salir al ManejadorServicio. Se asigna la responsabilidad enva el evento Salir a la ManejadorServicio a la clase InterfaceUsuario. Adicionalmanete, se asigna maneja el evento Salir al ManejadorServicio. 41. El ManejadorServicio sale del sistema. Se asigna la responsabilidad sale del sistema al ManejadorServicio. A partir de estas frases obtenemos nuevas responsabilidades y las insertamos en las tarjetas de clase correspondientes. Dado que no todas las clases agregan nuevas responsabilidades, iremos mostrando slo aquellas que s lo hacen. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. De manera similar, las responsabilidades identificadas para las clases ManejadorRegistroUsuario y InterfaceBaseDatosRegistro no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.6 y en la Tabla 8.7, respectivamente. La Tabla 8.9 muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.4 junto con las nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) Tabla 8.9. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. La Tabla 8.10 muestra las responsabilidades para la clase ManejadorServicio anteriormente identificadas en la Tabla 8.8 junto con las nuevas responsabilidades. Clase: ManejadorServicio Descripcin: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Mdulo: Servicios Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: ofrecerServicio (18) solicita desplegarPantallaServicio a la InterfaceUsuario (23) maneja el evento Obtener Registro (36) solicita registrar al ManejadorRegistroUsuario (37) maneja el evento Salir (40) sale del sistema (41) Tabla 8.10. Tarjeta para la clase ManejadorServicio con responsabilidades identificadas hasta el momento. La Tabla 8.11 muestra las responsabilidades identificadas hasta el momento para la clase PantallaServicio. Clase: PantallaServicio

Weitzenfeld: Captulo 8

13

Descripcin: Pantalla de servicios (P-2). Mdulo: Servicios Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (25) enva el evento Obtener Registro a la InterfaceUsuario (35) enva el evento Salir a la InterfaceUsuario (39) Tabla 8.11. Tarjeta para la clase PantallaServicio con responsabilidades identificadas hasta el momento. Este caso de uso no escpecifica responsabilidades adicionales a las mencionadas anteriormente, incluyendo responsabilidades por razones de manejo de excepciones. Registrar Usuario Continuamos con el flujo principal del caso de uso Registrar Usuario como se muestra a continuacin, Flujo Principal Se ejecuta el caso de uso Validar Usuario. Dependiendo de las opciones seleccionadas por el Usuario, se continuar con los diversos subflujos de este caso de uso. Podemos observar, que el flujo principal no agrega responsabilidades. Continuamos con el subflujo Crear Registro Usuario (S-1) del caso de uso Registrar Usuario como se muestra a continuacin, S-1 Crear Registro Usuario Subflujos El ManejadorRegistroUsuario solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaCrearRegUsuario. La PantallaCrearRegUsuario se despliega. Esta pantalla contiene informacin de registro que debe ser llenada por el Usuario, lo cual incluye nombre, apellido, calle, colonia, ciudad, pas, cdigo postal, telfonos de la casa y oficina, nmero de fax, login, email, password y una entrada adicional de repetir password para asegurarse de su correccin. El login y la password sern utilizados por el sistema para validar al usuario. El Usuario puede seleccionar entre las siguientes actividades: "Registrar" y "Salir". Si el Usuario selecciona Registrar, la PantallaCrearRegUsuario enva el evento Registrar a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrar al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita crearRegistroUsuario a la Base de Datos Registro (E-1, E-2, E-3, E-4). La Base de Datos Registro devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Se contina con el subflujo Administrar Registro Usuario (S-3). Si la actividad seleccionada es "Salir", la PantallaCrearRegUsuario enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroUsuario. El ManejadorRegistroUsuario sale del sistema. (Si an no se ha presionado "Registrar", la informacin ser perdida). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 42. El ManejadorRegistroUsuario solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario. La responsabilidad es solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario y se asigna a ManejadorRegistroUsuario. 43. El InterfaceUsuario despliega la PantallaCrearRegUsuario. La responsabilidad es despliega la PantallaCrearRegUsuario y se asigna a InterfaceUsuario. 44. El PantallaCrearRegUsuario se despliega. La responsabilidad es despliega y se asigna a PantallaCrearRegUsuario. 45. Esta pantalla contiene informacin de registro que debe ser llenada por el Usuario, lo cual incluye nombre, apellido, calle, colonia, ciudad, pas, cdigo postal, telfonos de la casa y oficina, nmero de fax, login, email, password y una entrada adicional de repetir password para asegurarse de su correccin. El login y la password sern utilizados por el sistema para validar al usuario. Estas frases son informativas y no desriben ninguna responsabilidad particular de inters en este momento.

Weitzenfeld: Captulo 8

14

46. El Usuario puede seleccionar entre las siguientes actividades: "Registrar" y "Salir". Esta es nuevamente una frase informativa sobre las opciones del Usuario y no agrega responsabilidades. 47. Si el Usuario selecciona Registrar, la PantallaCrearRegUsuario enva el evento Registrar a la InterfaceUsuario. Se identifica la responsabilidad enva el evento Registrar a la InterfaceUsuario y se asigna a la PantallaCrearRegUsuario. 48. La InterfaceUsuario enva el evento Registrar al ManejadorRegistroUsuario. Se identifica la responsabilidad enva el evento Registrar al ManejadorRegistroUsuario y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad maneja el evento Registrar al ManejadorRegistroUsuario. 49. El ManejadorRegistroUsuario solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro. Se identifica la responsabilidad solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro y se asigna al ManejadorRegistroUsuario. 50. La InterfaceBaseDatosRegistro solicita crearRegistroUsuario a la Base de Datos Registro (E-1, E-2, E-3, E-4). Se identifica la responsabilidad solicita crearRegistroUsuario a la Base de Datos Registro y se asigna a la InterfaceBaseDatosRegistro. Obviamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Registro dado que los actores son externos al sistema. 51. La Base de Datos Registro devuelve el OK a la InterfaceBaseDatosRegistro. Nuevamente, no se asigna ninguna responsabilidad a la Base de Datos Registro por ser externa al sistema. Por otro lado, y vale la pena resaltar, las frases de tipo devolucin de informacin no resultan en la asignacin de responsabilidades ya que son nicamente respuestas a solicitudes anteriores. Slo las propias solicitudes son registradas ya que corresponden a servicios del sistema. 52. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. No se asigna responsabilidades dado que la frase describe una devolucin de informacin. 53. Se contina con el subflujo Administrar Registro Usuario (S-3). Nuevamente, esta es una frase informativa de la continuacin interna del caso de uso por lo cual no se asignan responsabilidades. 54. Si la actividad seleccionada es "Salir", la PantallaCrearRegUsuario enva el evento Salir a la InterfaceUsuario. Se asigna la responsabilidad enva el evento Salir a la InterfaceUsuario a la PantallaCrearRegUsuario. 55. La InterfaceUsuario enva el evento Salir al ManejadorRegistroUsuario. Se asigna la responsabilidad enva el evento Salir al ManejadorRegistroUsuario a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad maneja el evento Salir al ManejadorRegistroUsuario. 56. El ManejadorRegistroUsuario sale del sistema. Se asigna la responsabilidad sale del sistema al ManejadorRegistroUsuario. 57. (Si an no se ha presionado "Registrar", la informacin ser perdida). Nuevamente, esta es una frase informativa por lo cual no se asignan nuevas responsabilidades. A partir de estas frases obtenemos nuevas responsabilidades y las insertamos en las tarjetas de clase correspondientes. Dado que no todas las clases agregan nuevas responsabilidades, iremos mostrando slo aquellas que s lo hacen. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. De manera similar, las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. En la Tabla 8.12 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.9 junto con las nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21)

Weitzenfeld: Captulo 8

15

despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) Tabla 8.12. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.13 se muestra las responsabilidades para la clase ManejadorRegistroUsuario anteriormente identificadas en la Tabla 8.6 junto con las nuevas responsabilidades. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario (7) solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro (13) solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario (42) maneja el evento Registrar (48) solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro (49) maneja el evento Salir (55) sale del sistema (56) Tabla 8.13. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento. Agregamos una nueva tarjeta de clase describiendo las responsabilidades para la clase PantallaCrearRegUsuario, como se muestra en la Tabla 8.14. Clase: PantallaCrearRegUsuario Descripcin: Pantalla de solicitud de registro de usuario (P-3). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (44) enva el evento Registrar a la InterfaceUsuario (47) enva el evento Salir a la InterfaceUsuario (54) Tabla 8.14. Tarjeta para la clase PantallaCrearRegUsuario con nuevas responsabilidades identificadas hasta el momento. En la Tabla 8.15 se muestra las responsabilidades para la clase InterfaceBaseDatosRegistro anteriormente identificadas en la Tabla 8.7 junto con las nuevas responsabilidades. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases:

Weitzenfeld: Captulo 8

16

Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) Tabla 8.15. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Obtener Registro Usuario (S-2) del caso de uso Registrar Usuario como se muestra a continuacin, S-2 Obtener Registro Usuario Subflujos El ManejadorRegistroUsuario solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita obtenerRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro devuelve el OK y el RegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK y el RegistroUsuario al ManejadorRegistroUsuario. Se contina con el subflujo Administrar Registro Usuario (S-3). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 58. El ManejadorRegistroUsuario solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro. La responsabilidad es solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro y se asigna a ManejadorRegistroUsuario. 59. La InterfaceBaseDatosRegistro solicita obtenerRegistroUsuario a la Base de Datos Registro. La responsabilidad es solicita obtenerRegistroUsuario a la Base de Datos Registro y se asigna a InterfaceBaseDatosRegistro. 60. La Base de Datos Registro devuelve el OK y el RegistroUsuario a la InterfaceBaseDatosRegistro. Nuevamente, eventos de devolucin de informacin no significan responsabilidades adicionales, por lo cual esta frase no agrega ninguna. 61. La InterfaceBaseDatosRegistro devuelve el OK y el RegistroUsuario al ManejadorRegistroUsuario. Esta frase tampoco agrega ninguna responsabilidad. 62. Se contina con el subflujo Administrar Registro Usuario (S-3). Esta es una frase exclusivamente informativa de la continuacin interna del caso de uso y no agrega nuevas responsabilidades. En total se agregaron dos nuevas responsabilidades. La primera responsabilidad (58) se agrega a la clase ManejadorRegistroUsuario como se muestra en la Tabla 8.16 la cual incluye las responsabilidades anteriormente identificadas en la Tabla 8.13. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario (7) solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro (13) solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario (42) maneja el evento Registrar (48) solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro (49) maneja el evento Salir (55) sale del sistema (56) solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro (58) Tabla 8.16. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento. La segunda responsabilidad (59) se agrega a la clase InterfaceBaseDatosRegistro como se muestra en la Tabla 8.17 la cual incluye las responsabilidades anteriormente identificadas en la Tabla 8.13. Clase: InterfaceBaseDatosRegistro Descripcin: 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

Weitzenfeld: Captulo 8

17

guardar informacin sobre la tarjeta de crdito para pagos en lnea. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59) Tabla 8.14. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Administrar Registro Usuario (S-3) del caso de uso Registrar Usuario como se muestra a continuacin, S-3 Administrar Registro Usuario Subflujos El ManejadorRegistroUsuario solicita desplegarPantallaObtenerRegUsuario a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaObtenerRegUsuario. La PantallaObtenerRegUsuario se despliega. El Usuario puede seleccionar entra las siguientes actividades: "Eliminar", "Actualizar", "Registrar Tarjeta", "Servicios" y "Salir". Si el usuario presiona "Actualizar" se ejecuta el subflujo Actualizar Registro Usuario (S-4). Si el usuario selecciona "Eliminar" se ejecuta el subflujo Eliminar Registro Usuario (S-5). Si el usuario presiona "Registrar Tarjeta", la PantallaObtenerRegUsuario enva el evento Registrar Tarjeta a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrar Tarjeta al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita registrarTarjeta al ManejadorRegistroTarjeta, se contina con el caso de uso Registrar Tarjeta. Si la actividad seleccionada es "Servicios", la PantallaObtenerRegUsuario enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaObtenerRegUsuario enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroUsuario. El ManejadorRegistroUsuario sale del sistema. (Si an no se ha presionado "Actualizar", la nueva informacin ser perdida). Nuevamente, tomamos cada una de las frase y las analizamos para identificar nuevas responsabilidades. 63. El ManejadorRegistroUsuario solicita desplegarPantallaObtenerRegUsuario a la InterfaceUsuario. La responsabilidad es solicita desplegarPantallaObtenerRegUsuario a la InterfaceUsuario y se asigna a la ManejadorRegistroUsuario. 64. La InterfaceUsuario despliega la PantallaObtenerRegUsuario. La responsabilidad es despliega la PantallaObtenerRegUsuario y se asigna a la InterfaceUsuario. 65. La PantallaObtenerRegUsuario se despliega. La responsabilidad es despliega y se asigna a la PantallaObtenerRegUsuario. 66. El Usuario puede seleccionar entra las siguientes actividades: "Eliminar", "Actualizar", "Registrar Tarjeta", "Servicios" y "Salir". Esta frase es informativa describiendo las diversas opciones del Usuario y no agrega responsabilidades. 67. Si el usuario presiona "Actualizar" se ejecuta el subflujo Actualizar Registro Usuario (S-4). Esta frase es informativa describiendo una continuacin interna del flujo del caso de uso y no agrega responsabilidades. 68. Si el usuario selecciona "Eliminar" se ejecuta el subflujo Eliminar Registro Usuario (S-5). De manera similar a la frase anterior, esta frase es informativa describiendo una continuacin interna del flujo del caso de uso y no agrega responsabilidades. 69. Si el usuario presiona "Registrar Tarjeta", la PantallaObtenerRegUsuario enva el evento Registrar Tarjeta a la InterfaceUsuario. La responsabilidad es enva el evento Registrar Tarjeta a la InterfaceUsuario y se asigna a la PantallaObtenerRegUsuario. 70. La InterfaceUsuario enva el evento Registrar Tarjeta al ManejadorRegistroUsuario. La responsabilidad es enva el evento Registrar Tarjeta al ManejadorRegistroUsuario y se asigna a la

Weitzenfeld: Captulo 8

18

InterfaceUsuario. De manera adicional, se asigna la nueva responsabilidad maneja el evento Registrar Tarjeta al ManejadorRegistroUsuario. 71. El ManejadorRegistroUsuario solicita registrarTarjeta al ManejadorRegistroTarjeta, se contina con el caso de uso Registrar Tarjeta. La responsabilidad es solicita registrarTarjeta al ManejadorRegistroTarjeta y se asigna al ManejadorRegistroUsuario. Adicionalmente, asignamos la responsabilidad registrarTarjeta al ManejadorRegistroTarjeta. La ltima seccin de la frase describe una continuacin de lgica entre casos de uso y no agrega responsabilidades. 72. Si la actividad seleccionada es "Servicios", la PantallaObtenerRegUsuario enva el evento Servicios a la InterfaceUsuario. La responsabilidad es enva el evento Servicios a la InterfaceUsuario y se asigna a PantallaObtenerRegUsuario. 73. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroUsuario. La responsabilidad es enva el evento Servicios al ManejadorRegistroUsuario y se asigna a InterfaceUsuario. Adicionalmente se agrega la responsabilidad maneja el evento Servicios al ManejadorRegistroUsuario. 74. El ManejadorRegistroUsuario solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. La responsabilidad es solicita ofrecerServicio al ManejadorServicio y se asigna al ManejadorRegistroUsuario. No es necesario volver a asignar la responsabilidad ofrecerServicio a ManejadorServicio, ya que esto ha sido hecho anteriormente. La ltima seccin de la frase describe continuacin del flujo interno del caso de uso y no agrega nuevas responsabilidades. 75. Si la actividad seleccionada es "Salir", la PantallaObtenerRegUsuario enva el evento Salir a la InterfaceUsuario. La responsabilidad es enva el evento Salir a la InterfaceUsuario y se asigna a PantallaObtenerRegUsuario. 76. La InterfaceUsuario enva el evento Salir al ManejadorRegistroUsuario. La responsabilidad es enva el evento Salir al ManejadorRegistroUsuario y se asigna a InterfaceUsuario. Adicionalmente se debe asignar la responsabilidad maneja el evento Salir a ManejadorRegistroUsuario. Sin embargo, esta responsabilidad ya ha sido asignada anteriormente, por lo cual no es necesario duplicarla. 77. El ManejadorRegistroUsuario sale del sistema. La responsabilidad es sale del sistema y se debe asignar a ManejadorRegistroUsuario. Sin embargo, esta es una responsabilidad duplicada por lo cual no la volvemos a asignar. 78. (Si an no se ha presionado "Actualizar", la nueva informacin ser perdida). Esta frase es informativa y no agrega responsabilidades adicionales. A partir de estas frases obtenemos responsabilidades adicionales y las insertamos en las tarjetas de clase correspondientes. Nuevamente, no todas las clases agregan nuevas responsabilidades. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. De manera similar, las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, se mantienen iguales las clases PantallaCrearRegUsuario correspondiente a la Tabla 8.14, junto con la InterfaceBaseDatosRegistro correspondiente a la Tabla 8.17. En la Tabla 8.18 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.12 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40)

Weitzenfeld: Captulo 8

19

despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) Tabla 8.18. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.19 se muestra las responsabilidades para la clase ManejadorRegistroUsuario anteriormente identificadas en la Tabla 8.13 junto con las nuevas responsabilidades. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario (7) solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro (13) solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario (42) maneja el evento Registrar (48) solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro (49) maneja el evento Salir (55) sale del sistema (56) solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro (58) solicita desplegarPantallaObtenerRegistroUsuario a la InterfaceUsuario (63) maneja el evento Registrar Tarjeta (70) solicita registrarTarjeta al ManejadorRegistroTarjeta (71) maneja el evento Servicios (73) solicita ofrecerServicios al ManejadorServicio (74) Tabla 8.19. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento. Agregamos una nueva tarjeta de clase describiendo las responsabilidades para la clase PantallaObtenerRegUsuario, como se muestra en la Tabla 8.20. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (65) enva el evento Registrar Tarjeta a la InterfaceUsuario (69) enva el evento Servicios a la InterfaceUsuario (72) enva el evento Salir a la InterfaceUsuario (75) Tabla 8.20. Tarjeta para la clase PantallaObtenerRegUsuario con nuevas responsabilidades identificadas hasta el momento. La Tabla 8.21 muestra las responsabilidades identificadas hasta el momento para la clase ManejadorRegistroTarjeta. Clase: ManejadorRegistroTarjeta

Weitzenfeld: Captulo 8

20

Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta (71) Tabla 8.21. Tarjeta para la clase ManejadorRegistroTarjeta con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Actualizar Registro Usuario (S-4) del caso de uso Registrar Usuario como se muestra a continuacin, S-4 Actualizar Registro Usuario Subflujos La PantallaObtenerRegUsuario enva el evento Actualizar a la InterfaceUsuario. La InterfaceUsuario enva el evento Actualizar" al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita actualizarRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro actualiza el RegistroUsuario (E-1, E-2, E-4) y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Se continua con el subflujo Administrar Registro Usuario (S-3). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 79. La PantallaObtenerRegUsuario enva el evento Actualizar a la InterfaceUsuario. La responsabilidad es enva el evento Actualizar a la InterfaceUsuario y se asigna a PantallaObtenerRegUsuario. 80. La InterfaceUsuario enva el evento Actualizar" al ManejadorRegistroUsuario. La responsabilidad es enva el evento Actualizar" al ManejadorRegistroUsuario y se asigna a InterfaceUsuario. Adicionalmente, se agrega la responsabilidad maneja el evento Actualizar y se asigna al ManejadorRegistroUsuario. 81. El ManejadorRegistroUsuario solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro. La responsabilidad es solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro y se asigna al ManejadorRegistroUsuario. 82. La InterfaceBaseDatosRegistro solicita actualizarRegistroUsuario a la Base de Datos Registro. La responsabilidad es solicita actualizarRegistroUsuario a la Base de Datos Registro y se asigna a la InterfaceBaseDatosRegistro. 83. La Base de Datos Registro actualiza el RegistroUsuario (E-1, E-2, E-4) y devuelve el OK a la InterfaceBaseDatosRegistro. Esta frase se refiere a Base de Datos Registro, un actor externo al sistema, por lo cual no se agregan nuevas responsabilidades. La segunda parte de la frase describe una devolucin por lo cual tampoco se agrega ninguna responsabilidad. 84. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Nuevamente, se describe una devolucin por lo cual no se agrega ninguna responsabilidad. 85. Se continua con el subflujo Administrar Registro Usuario (S-3). Esta es una frase que describe flujo interno de continuacin del caso de uso, por lo cual no agrega responsabilidades. A partir de estas frases obtenemos nuevas responsabilidades y las insertamos en las tarjetas de clase correspondientes. Dado que no todas las clases agregan nuevas responsabilidades, iremos mostrando slo aquellas que s lo hacen. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. De manera similar, las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, se mantiene igual la clase PantallaCrearRegUsuario correspondiente a la Tabla 8.14. En la Tabla 8.22 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.18 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario

Weitzenfeld: Captulo 8

21

Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) enva el evento Actualizar al ManejadorRegistroUsuario (80) Tabla 8.22. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.23 se muestra las responsabilidades para la clase ManejadorRegistroUsuario anteriormente identificadas en la Tabla 8.19 junto con las nuevas responsabilidades. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario (7) solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro (13) solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario (42) maneja el evento Registrar (48) solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro (49) maneja el evento Salir (55) sale del sistema (56) solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro (58) solicita desplegarPantallaObtenerRegistroUsuario a la InterfaceUsuario (63) maneja el evento Registrar Tarjeta (70) solicita registrarTarjeta al ManejadorRegistroTarjeta (71) maneja el evento Servicios (73) solicita ofrecerServicios al ManejadorServicio (74) maneja el evento Actualizar (80) solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro (81) Tabla 8.23. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.24 se muestra las responsabilidades para la clase PantallaObtenerRegUsuario anteriormente identificadas en la Tabla 8.20 junto con las nuevas responsabilidades. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4).

Weitzenfeld: Captulo 8

22

Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (65) enva el evento Registrar Tarjeta a la InterfaceUsuario (69) enva el evento Servicios a la InterfaceUsuario (72) enva el evento Salir a la InterfaceUsuario (75) enva el evento Actualizar a la InterfaceUsuario (79) Tabla 8.24. Tarjeta para la clase PantallaObtenerRegUsuario con nuevas responsabilidades identificadas hasta el momento. En la Tabla 8.25 se muestra las responsabilidades para la clase InterfaceBaseDatosRegistro anteriormente identificadas en la Tabla 8.14 junto con las nuevas responsabilidades. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59) solicita actualizarRegistroUsuario a la BaseDatosRegistro (82) Tabla 8.25. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Eliminar Registro Usuario (S-5) del caso de uso Registrar Usuario como se muestra a continuacin, S-5 Eliminar Registro Usuario Subflujos La PantallaObtenerRegUsuario enva el evento Eliminar a la InterfaceUsuario. La InterfaceUsuario enva el evento Eliminar al ManejadorRegistroUsuario. El ManejadorRegistroUsuario solicita eliminarRegistroUsuario a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro enva el evento eliminarRegistroUsuario a la Base de Datos Registro. La Base de Datos Registro elimina el RegistroUsuario y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Se contina con el subflujo Crear Registro Usuario (S-1). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 86. La PantallaObtenerRegUsuario enva el evento Eliminar a la InterfaceUsuario. La responsabilidad es enva el evento Eliminar a la InterfaceUsuario y se asigna a PantallaObtenerRegUsuario. 87. La InterfaceUsuario enva el evento Eliminar al ManejadorRegistroUsuario. La responsabilidad es enva el evento Eliminar" al ManejadorRegistroUsuario y se asigna a InterfaceUsuario. Adicionalmente, se agrega la responsabilidad maneja el evento Eliminar y se asigna al ManejadorRegistroUsuario. 88. El ManejadorRegistroUsuario solicita eliminarRegistroUsuario a la InterfaceBaseDatosRegistro. La responsabilidad es solicita eliminarRegistroUsuario a la InterfaceBaseDatosRegistro y se asigna al ManejadorRegistroUsuario. 89. La InterfaceBaseDatosRegistro enva el evento eliminarRegistroUsuario a la Base de Datos Registro. La responsabilidad es solicita eliminarRegistroUsuario a la Base de Datos Registro y se asigna a la InterfaceBaseDatosRegistro.

Weitzenfeld: Captulo 8

23

90. La Base de Datos Registro elimina el RegistroUsuario y devuelve el OK a la InterfaceBaseDatosRegistro. Esta frase se refiere a Base de Datos Registro, un actor externo al sistema, por lo cual no se agregan nuevas responsabilidades. La segunda parte de la frase describe una devolucin por lo cual tampoco se agrega ninguna responsabilidad. 91. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroUsuario. Nuevamente, se describe una devolucin por lo cual no se agrega ninguna responsabilidad. 92. Se contina con el subflujo Crear Registro Usuario (S-1). Esta es una frase que describe flujo interno de continuacin del caso de uso, por lo cual no agrega responsabilidades. A partir de estas frases obtenemos nuevas responsabilidades y las insertamos en las tarjetas de clase correspondientes. Dado que no todas las clases agregan nuevas responsabilidades, iremos mostrando slo aquellas que s lo hacen. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. De manera similar, las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, se mantiene igual la clase PantallaCrearRegUsuario correspondiente a la Tabla 8.14. En la Tabla 8.26 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.22 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) enva el evento Actualizar al ManejadorRegistroUsuario (80) enva el evento Eliminar al ManejadorRegistroUsuario (87) Tabla 8.26. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.27 se muestra las responsabilidades para la clase ManejadorRegistroUsuario anteriormente identificadas en la Tabla 8.23 junto con las nuevas responsabilidades. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos:

Weitzenfeld: Captulo 8

24

crearRegistroUsuario (7) solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro (13) solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario (42) maneja el evento Registrar (48) solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro (49) maneja el evento Salir (55) sale del sistema (56) solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro (58) solicita desplegarPantallaObtenerRegistroUsuario a la InterfaceUsuario (63) maneja el evento Registrar Tarjeta (70) solicita registrarTarjeta al ManejadorRegistroTarjeta (71) maneja el evento Servicios (73) solicita ofrecerServicios al ManejadorServicio (74) maneja el evento Actualizar (80) solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro (81) maneja el evento Eliminar (87) solicita eliminarRegistroUsuario a la InterfaceBaseDatosRegistro (88) Tabla 8.27. Tarjeta para la clase ManejadorRegistroUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.28 se muestra las responsabilidades para la clase PantallaObtenerRegUsuario anteriormente identificadas en la Tabla 8.24 junto con las nuevas responsabilidades. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (65) enva el evento Registrar Tarjeta a la InterfaceUsuario (69) enva el evento Servicios a la InterfaceUsuario (72) enva el evento Salir a la InterfaceUsuario (75) enva el evento Actualizar a la InterfaceUsuario (79) enva el evento Eliminar a la InterfaceUsuario (86) Tabla 8.28. Tarjeta para la clase PantallaObtenerRegUsuario con nuevas responsabilidades identificadas hasta el momento. En la Tabla 8.29 se muestra las responsabilidades para la clase InterfaceBaseDatosRegistro anteriormente identificadas en la Tabla 8.25 junto con las nuevas responsabilidades. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59)

Weitzenfeld: Captulo 8

25

solicita actualizarRegistroUsuario a la BaseDatosRegistro (82) solicita eliminarRegistroUsuario a la BaseDatosRegistro (89) Tabla 8.29. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. De manera general, se puede tambin obtener responsabilidades a partir del manejajo de excepciones, como se muestra a continuacin, E-1 informacin incompleta: Falta llenar informacin en el registro de usuario. Se le vuelve a Excepciones pedir al usuario que complete el registro. E-2 registro ya existe: Si ya existe un registro bajo ese login, se le pedir al usuario que lo cambie o que termine el caso de uso. E-3 login incorrecto: El login no es vlido. Se le vuelve a pedir al usuario que complete el registro. E-4 contrasea incorrecta: La contrasea escogida es muy sencilla o no se valid correctamente. Se le vuelve a pedir al usuario que complete el registro. Sin embargo, nos concentraremos nicamente en los flujos bsicos y no los alternos. En general, los alternos que son los menos comunes, son importantes de disear pero no en una primera etapa. Registrar Tarjeta A continuacin mostramos el flujo principal del caso de uso Registrar Tarjeta como se present al final del captulo de anlisis. Flujo Principal Se contina con el subflujo Obtener Registro Tarjeta (S-2). Si no existe un RegistroTarjeta vlido se contina con el subflujo Crear Registro Tarjeta (S-1). De lo contrario, si ya existe un RegistroTarjeta vlido, se contina con el subflujo Administrar Registro Tarjeta (S-3). Tomamos cada una de las frases que describen el flujo y las analizaremos para decidir que responsabilidad representan y a que clase se le asignan: 93. Se contina con el subflujo Obtener Registro Tarjeta (S-2). Esta frase describe flujo interno del caso de uso y no agrega responsabilidades. 94. Si no existe un RegistroTarjeta vlido se contina con el subflujo Crear Registro Tarjeta (S-1). Esta frase es informativa y no agrega responsabilidades a las clases. 95. De lo contrario, si ya existe un RegistroTarjeta vlido, se contina con el subflujo Administrar Registro Tarjeta (S-3). Nuevamente, esta frase es informativa y no agrega responsabilidades a las clases. Como podemos apreciar, el flujo anterior no agrega responsabilidades adicionales. Continuamos con el subflujo Crear Registro Tarjeta (S-1) del caso de uso Registrar Tarjeta como se muestra a continuacin, S-1 Crear Registro Tarjeta Subflujos El ManejadorRegistroTarjeta solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario. La InterfaceUsuario despliega a la PantallaCrearRegTarjeta. La PantallaCrearRegTarjeta se despliega. Esta pantalla contiene informacin que debe ser llenada por el Usuario, lo cual incluye el nombre como aparece el la tarjeta, nmero de tarjeta, el tipo de tarjeta, y la fecha de vencimiento. El Usuario puede seleccionar entre las siguientes actividades: "Registrar", "Servicios" y "Salir". Si el Usuario selecciona Registrar, la PantallaCrearRegTarjeta enva el evento Registrar a la InterfaceUsuario. La InterfaceUsuario enva el evento Registrar al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita crearRegistroTarjeta a la Base de Datos Registro (E-1). La Base de Datos Registro devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Se contina con el subflujo Administrar Registro Tarjeta (S-3). Si la actividad seleccionada es "Servicios", la PantallaCrearRegTarjeta enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaCrearRegTarjeta enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta sale del sistema. (Si an no se ha presionado "Registrar", la informacin sta ser perdida).

Weitzenfeld: Captulo 8

26

Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 96. El ManejadorRegistroTarjeta solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario. La responsabilidad es solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario y se asigna a ManejadorRegistroTarjeta. 97. La InterfaceUsuario despliega a la PantallaCrearRegTarjeta. La responsabilidad es despliega la PantallaCrearRegTarjeta y se asigna a InterfaceUsuario. 98. La PantallaCrearRegTarjeta se despliega. La responsabilidad es despliega y se asigna a PantallaCrearRegTarjeta. 99. Esta pantalla contiene informacin que debe ser llenada por el Usuario, lo cual incluye el nombre como aparece el la tarjeta, nmero de tarjeta, el tipo de tarjeta, y la fecha de vencimiento. Esta es una frase totalmente informativa por lo cual no agrega responsabilidades. 100. El Usuario puede seleccionar entre las siguientes actividades: "Registrar", "Servicios" y "Salir". Esta es nuevamente una frase informativa sobre las opciones del Usuario y no agrega responsabilidades. 101. Si el Usuario selecciona Registrar, la PantallaCrearRegTarjeta enva el evento Registrar a la InterfaceUsuario. Se identifica la responsabilidad enva el evento Registrar a la InterfaceUsuario y se asigna a la PantallaCrearRegTarjeta. 102. La InterfaceUsuario enva el evento Registrar al ManejadorRegistroTarjeta. Se identifica la responsabilidad enva el evento Registrar al ManejadorRegistroTarjeta y se asigna a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad maneja el evento Registrar al ManejadorRegistroTarjeta. 103. El ManejadorRegistroTarjeta solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro. Se identifica la responsabilidad solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro y se asigna al ManejadorRegistroTarjeta. 104. La InterfaceBaseDatosRegistro solicita crearRegistroTarjeta a la Base de Datos Registro (E-1). Se identifica la responsabilidad solicita crearRegistroTarjeta a la Base de Datos Registro y se asigna a la InterfaceBaseDatosRegistro. Nuevamente, no tiene mucho sentido asignar responsabilidades a la Base de Datos Registro dado que los actores son externos al sistema. 105. La Base de Datos Registro devuelve el OK a la InterfaceBaseDatosRegistro. No se asigna ninguna responsabilidad a la Base de Datos Registro por ser externa al sistema. Tampoco se agregan responsabilidades por razones de devolucin de informacin. 106. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. No se asigna responsabilidades dado que la frase describe una devolucin de informacin. 107. Se contina con el subflujo Administrar Registro Tarjeta (S-3). Esta es una frase informativa de la continuacin interna del caso de uso por lo cual no se asignan responsabilidades. 108. Si la actividad seleccionada es "Servicios", la PantallaCrearRegTarjeta enva el evento Servicios a la InterfaceUsuario. Se asigna la responsabilidad enva el evento Servicios a la InterfaceUsuario a la PantallaCrearRegTarjeta. 109. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroTarjeta. Se asigna la responsabilidad enva el evento Servicios a la InterfaceUsuario. De manera adicional se asigna la rsponsabilidad maneja el evento Servicios al ManejadorRegistroTarjeta. 110. El ManejadorRegistroTarjeta solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Se identifica la responsabilidad solicita ofrecerServicio al ManejadorServicio y se asigna al ManejadorRegistroTarjeta. La ltima seccin no agrega responsabilidades por describir un flujo entre casos de uso. 111. Si la actividad seleccionada es "Salir", la PantallaCrearRegTarjeta enva el evento Salir a la InterfaceUsuario. Se asigna la responsabilidad enva el evento Salir a la InterfaceUsuario a la PantallaCrearRegTarjeta. 112. La InterfaceUsuario enva el evento Salir al ManejadorRegistroTarjeta. Se asigna la responsabilidad enva el evento Salir al ManejadorRegistroTarjeta a la InterfaceUsuario. Adicionalmente, asignamos la responsabilidad maneja el evento Salir al ManejadorRegistroTarjeta. 113. El ManejadorRegistroTarjeta sale del sistema. Se asigna la responsabilidad sale del sistema al ManejadorRegistroTarjeta. 114. (Si an no se ha presionado "Registrar", la informacin sta ser perdida). Nuevamente, esta es una frase informativa por lo cual no se asignan nuevas responsabilidades. A partir de estas frases obtenemos nuevas responsabilidades y las insertamos en las tarjetas de clase correspondientes. Dado que no todas las clases agregan nuevas responsabilidades, iremos mostrando slo aquellas que s lo hacen. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y

Weitzenfeld: Captulo 8

27

PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. Las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, las responsabilidades identificadas para las clases ManejadorRegistroUsuario, PantallaCrearRegUsuario y PantallaObtenerRegUsuario tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.27, Tabla 8.14 y Tabla 8.28, respectivamente. En la Tabla 8.30 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.26 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) enva el evento Actualizar al ManejadorRegistroUsuario (80) enva el evento Eliminar al ManejadorRegistroUsuario (87) despliega la PantallaCrearRegTarjeta (97) enva el evento Registrar al ManejadorRegistroTarjeta (102) enva el evento Servicios al ManejadorRegistroTarjeta (109) enva el evento Salir al ManejadorRegistroTarjeta (112) Tabla 8.30. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.31 se muestra las responsabilidades para la clase ManejadorRegistroTarjeta anteriormente identificadas en la Tabla 8.21 junto con las nuevas responsabilidades. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta (71) solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario (96) maneja el evento Registrar (102) solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro (103) maneja el evento Servicios (109) solicita ofrecerServicio al ManejadorServicio (110)

Weitzenfeld: Captulo 8

28

maneja el evento Salir (112) sale del sistema (113) Tabla 8.31. Tarjeta para la clase ManejadorRegistroTarjeta con responsabilidades identificadas hasta el momento. Agregamos una nueva tarjeta de clase describiendo las responsabilidades para la clase PantallaCrearRegTarjeta, como se muestra en la Tabla 8.32. Clase: PantallaCrearRegTarjeta Descripcin: Pantalla de solicitud de registro de tarjeta (P-5). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (98) enva el evento Registrar a la InterfaceUsuario (101) enva el evento Servicios a la InterfaceUsuario (108) enva el evento Salir a la InterfaceUsuario (111) Tabla 8.32. Tarjeta para la clase PantallaCrearRegTarjeta con nuevas responsabilidades identificadas hasta el momento. En la Tabla 8.33 se muestra las responsabilidades para la clase InterfaceBaseDatosRegistro anteriormente identificadas en la Tabla 8.29 junto con las nuevas responsabilidades. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59) solicita actualizarRegistroUsuario a la BaseDatosRegistro (82) solicita eliminarRegistroUsuario a la BaseDatosRegistro (89) solicita crearRegistroTarjeta a la BaseDatosRegistro (104) Tabla 8.33. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Obtener Registro Tarjeta (S-2) del caso de uso Registrar Tarjeta como se muestra a continuacin, S-2 Obtener Registro Tarjeta Subflujos El ManejadorRegistroTarjeta solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita obtenerRegistroTarjeta a la Base de Datos Registro. La Base de Datos Registro devuelve el OK y el RegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK y el RegistroTarjeta al ManejadorRegistroTarjeta. Se regresa al flujo anterior. Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 115. El ManejadorRegistroTarjeta solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro. La responsabilidad es solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro y se asigna a ManejadorRegistroTarjeta.

Weitzenfeld: Captulo 8

29

116. La InterfaceBaseDatosRegistro solicita obtenerRegistroTarjeta a la Base de Datos Registro. La responsabilidad es solicita obtenerRegistroTarjeta a la Base de Datos Registro y se asigna a InterfaceBaseDatosRegistro. 117. La Base de Datos Registro devuelve el OK y el RegistroTarjeta a la InterfaceBaseDatosRegistro. Nuevamente, eventos de devolucin de informacin no significan responsabilidades adicionales, por lo cual esta frase no agrega ninguna. 118. La InterfaceBaseDatosRegistro devuelve el OK y el RegistroTarjeta al ManejadorRegistroTarjeta. Esta frase tampoco agrega ninguna responsabilidad. 119. Se regresa al flujo anterior. Esta es una frase exclusivamente informativa de la continuacin del caso de uso y no agrega nuevas responsabilidades. En total se agregaron dos nuevas responsabilidades. La primera responsabilidad (115) se agrega a la clase ManejadorRegistroTarjeta como se muestra en la Tabla 8.34 la cual incluye las responsabilidades anteriormente identificadas en la Tabla 8.31. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta (71) solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario (96) maneja el evento Registrar (102) solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro (103) maneja el evento Servicios (109) solicita ofrecerServicio al ManejadorServicio (110) maneja el evento Salir (112) sale del sistema (113) solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro (115) Tabla 8.34. Tarjeta para la clase ManejadorRegistroTarjeta con responsabilidades identificadas hasta el momento. La segunda responsabilidad se agrega a la clase InterfaceBaseDatosRegistro como se muestra en la Tabla 8.35 la cual incluye las responsabilidades anteriormente identificadas en la Tabla 8.33. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59) solicita actualizarRegistroUsuario a la BaseDatosRegistro (82) solicita eliminarRegistroUsuario a la BaseDatosRegistro (89) solicita crearRegistroTarjeta a la BaseDatosRegistro (104) solicita obtenerRegistroTarjeta a la BaseDatosRegistro (116)

Weitzenfeld: Captulo 8

30

Tabla 8.35. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Administrar Registro Tarjeta (S-3) del caso de uso Registrar Tarjeta como se muestra a continuacin, S-3 Administrar Registro Tarjeta Subflujos El ManejadorRegistroTarjeta solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario. La InterfaceUsuario despliega la PantallaObtenerRegTarjeta. La PantallaObtenerRegTarjeta se despliega. El Usuario puede seleccionar entre las siguientes actividades: "Actualizar", "Eliminar", "Servicios" y "Salir". Si el usuario presiona Actualizar se ejecuta el subflujo Actualizar Registro Tarjeta (S-4). Si el usuario presiona Eliminar se ejecuta el subflujo Eliminar Registro Tarjeta (S-5). Si la actividad seleccionada es "Servicios", la PantallaObtenerRegTarjeta enva el evento Servicios a la InterfaceUsuario. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. Si la actividad seleccionada es "Salir", la PantallaObtenerRegTarjeta enva el evento Salir a la InterfaceUsuario. La InterfaceUsuario enva el evento Salir al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta sale del sistema. (Si an no se ha presionado "Actualizar", la nueva informacin sta ser perdida). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 120. El ManejadorRegistroTarjeta solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario. La responsabilidad es solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario y se asigna a la ManejadorRegistroTarjeta. 121. La InterfaceUsuario despliega la PantallaObtenerRegTarjeta. La responsabilidad es despliega la PantallaObtenerRegTarjeta y se asigna a la InterfaceUsuario. 122. La PantallaObtenerRegTarjeta se despliega. La responsabilidad es despliega y se asigna a la PantallaObtenerRegTarjeta. 123. El Usuario puede seleccionar entre las siguientes actividades: "Actualizar", "Eliminar", "Servicios" y "Salir". Esta frase es informativa describiendo las diversas opciones del Usuario y no agrega responsabilidades. 124. Si el usuario presiona Actualizar se ejecuta el subflujo Actualizar Registro Tarjeta (S-4). Esta frase es informativa describiendo una continuacin interna del flujo del caso de uso y no agrega responsabilidades. 125. Si el usuario presiona Eliminar se ejecuta el subflujo Eliminar Registro Tarjeta (S-5). De manera similar a la frase anterior, esta frase es informativa describiendo una continuacin interna del flujo del caso de uso y no agrega responsabilidades. 126. Si la actividad seleccionada es "Servicios", la PantallaObtenerRegTarjeta enva el evento Servicios a la InterfaceUsuario. La responsabilidad es enva el evento Servicios a la InterfaceUsuario y se asigna a PantallaObtenerRegTarjeta. 127. La InterfaceUsuario enva el evento Servicios al ManejadorRegistroTarjeta. La responsabilidad es enva el evento Servicios al ManejadorRegistroTarjeta y se debe asignar a InterfaceUsuario. Esta responsabilidad est duplicada y no es necesario volverla a agregar. Adicionalmente, tampoco es necesario agregar la responsabilidad maneja el evento Servicios al ManejadorRegistroTarjeta, ya que tambin est duplicada. 128. El ManejadorRegistroTarjeta solicita ofrecerServicio al ManejadorServicio, se contina con el caso de uso Ofrecer Servicios. La responsabilidad es solicita ofrecerServicio al ManejadorServicio y se debe asignar al ManejadorRegistroTarjeta. Nuevamente, esta es una responsabilidad duplicada. La ltima seccin de la frase describe continuacin del flujo interno del caso de uso y no agrega nuevas responsabilidades. 129. Si la actividad seleccionada es "Salir", la PantallaObtenerRegTarjeta enva el evento Salir a la InterfaceUsuario. La responsabilidad es enva el evento Salir a la InterfaceUsuario y se asigna a PantallaObtenerRegTarjeta. 130. La InterfaceUsuario enva el evento Salir al ManejadorRegistroTarjeta. La responsabilidad es enva el evento Salir al ManejadorRegistroTarjeta y se asigna a InterfaceUsuario. Adicionalmente se debe asignar la responsabilidad maneja el evento Salir a ManejadorRegistroTarjeta. Sin embargo, esta responsabilidad ya ha sido asignada anteriormente, por lo cual no es necesario duplicarla.

Weitzenfeld: Captulo 8

31

131. El ManejadorRegistroTarjeta sale del sistema. La responsabilidad es sale del sistema y se debe asignar a ManejadorRegistroTarjeta. Nuevamente, esta es una responsabilidad duplicada por lo cual no la volvemos a asignar. 132. (Si an no se ha presionado "Actualizar", la nueva informacin sta ser perdida). Esta frase es informativa y no agrega responsabilidades adicionales. A partir de estas frases obtenemos responsabilidades adicionales y las insertamos en las tarjetas de clase correspondientes. Nuevamente, no todas las clases agregan nuevas responsabilidades. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. Las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, las responsabilidades identificadas para las clases ManejadorRegistroUsuario, PantallaCrearRegUsuario y PantallaObtenerRegUsuario tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.27, Tabla 8.14 y Tabla 8.28, respectivamente. Tampoco se modifican las responsabilidades de PantallaCrearRegTarjeta mantenindose iguales a las descritas en la Tabla 8.32. En la Tabla 8.36 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.26 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) enva el evento Actualizar al ManejadorRegistroUsuario (80) enva el evento Eliminar al ManejadorRegistroUsuario (87) despliega la PantallaCrearRegTarjeta (97) enva el evento Registrar al ManejadorRegistroTarjeta (102) enva el evento Servicios al ManejadorRegistroTarjeta (109) enva el evento Salir al ManejadorRegistroTarjeta (112) despliega la PantallaObtenerRegTarjeta (121) Tabla 8.36. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.37 se muestra las responsabilidades para la clase ManejadorRegistroTarjeta anteriormente identificadas en la Tabla 8.31 junto con las nuevas responsabilidades. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control

Weitzenfeld: Captulo 8

32

Propiedades: Superclases: Subclases: Atributos: registrarTarjeta (71) solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario (96) maneja el evento Registrar (102) solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro (103) maneja el evento Servicios (109) solicita ofrecerServicio al ManejadorServicio (110) maneja el evento Salir (112) sale del sistema (113) solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro (115) solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario (120) Tabla 8.37. Tarjeta para la clase ManejadorRegistroTarjeta con responsabilidades identificadas hasta el momento. Agregamos una nueva tarjeta de clase describiendo las responsabilidades para la clase PantallaObtenerRegTarjeta, como se muestra en la Tabla 8.38. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (122) enva el evento Servicios a la InterfaceUsuario (126) enva el evento Salir a la InterfaceUsuario (129) Tabla 8.38. Tarjeta para la clase PantallaObtenerRegTarjeta con nuevas responsabilidades identificadas hasta el momento. Continuamos con el subflujo Actualizar Registro Tarjeta (S-4) del caso de uso Registrar Tarjeta como se muestra a continuacin, S-4 Actualizar Registro Tarjeta Subflujos La PantallaObtenerRegTarjeta enva el evento Actualizar a la InterfaceUsuario. La InterfaceUsuario enva el evento Actualizar" al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita actualizarRegistroTarjeta a la Base de Datos Registro (E-1). La Base de Datos Registro actualiza el RegistroTarjeta y devuelve el evento OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Se continua con el subflujo Administrar Registro Tarjeta (S-3). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 133. La PantallaObtenerRegTarjeta enva el evento Actualizar a la InterfaceUsuario. La responsabilidad es enva el evento Actualizar a la InterfaceUsuario y se asigna a PantallaObtenerRegTarjeta. 134. La InterfaceUsuario enva el evento Actualizar" al ManejadorRegistroTarjeta. La responsabilidad es enva el evento Actualizar" al ManejadorRegistroTarjeta y se asigna a InterfaceUsuario. Adicionalmente, se agrega la responsabilidad maneja el evento Actualizar y se asigna al ManejadorRegistroTarjeta. 135. El ManejadorRegistroTarjeta solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro. La responsabilidad es solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro y se asigna al ManejadorRegistroTarjeta. 136. La InterfaceBaseDatosRegistro solicita actualizarRegistroTarjeta a la Base de Datos Registro (E-1). La responsabilidad es solicita actualizarRegistroTarjeta a la Base de Datos Registro y se asigna a la InterfaceBaseDatosRegistro.

Weitzenfeld: Captulo 8

33

137. La Base de Datos Registro actualiza el RegistroTarjeta y devuelve el evento OK a la InterfaceBaseDatosRegistro. Esta frase se refiere a Base de Datos Registro, un actor externo al sistema, por lo cual no se agregan nuevas responsabilidades. La segunda parte de la frase describe una devolucin por lo cual tampoco se agrega ninguna responsabilidad. 138. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Nuevamente, se describe una devolucin por lo cual no se agrega ninguna responsabilidad. 139. Se continua con el subflujo Administrar Registro Tarjeta (S-3). Esta es una frase que describe flujo interno de continuacin del caso de uso, por lo cual no agrega responsabilidades. A partir de estas frases obtenemos responsabilidades adicionales y las insertamos en las tarjetas de clase correspondientes. Nuevamente, no todas las clases agregan nuevas responsabilidades. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. Las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, las responsabilidades identificadas para las clases ManejadorRegistroUsuario, PantallaCrearRegUsuario y PantallaObtenerRegUsuario tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.27, Tabla 8.14 y Tabla 8.28, respectivamente. Tampoco se modifican las responsabilidades de PantallaCrearRegTarjeta mantenindose iguales a las descritas en la Tabla 8.32. En la Tabla 8.39 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.36 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) enva el evento Actualizar al ManejadorRegistroUsuario (80) enva el evento Eliminar al ManejadorRegistroUsuario (87) despliega la PantallaCrearRegTarjeta (97) enva el evento Registrar al ManejadorRegistroTarjeta (102) enva el evento Servicios al ManejadorRegistroTarjeta (109) enva el evento Salir al ManejadorRegistroTarjeta (112) despliega la PantallaObtenerRegTarjeta (121) enva el evento Actualizar al ManejadorRegistroTarjeta (134) Tabla 8.39. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.40 se muestra las responsabilidades para la clase ManejadorRegistroTarjeta anteriormente identificadas en la Tabla 8.37 junto con las nuevas responsabilidades. Clase: ManejadorRegistroTarjeta

Weitzenfeld: Captulo 8

34

Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta (71) solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario (96) maneja el evento Registrar (102) solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro (103) maneja el evento Servicios (109) solicita ofrecerServicio al ManejadorServicio (110) maneja el evento Salir (112) sale del sistema (113) solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro (115) solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario (120) maneja el evento Actualizar (134) solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro (135) Tabla 8.40. Tarjeta para la clase ManejadorRegistroTarjeta con responsabilidades identificadas hasta el momento. En la Tabla 8.41 se muestra las responsabilidades para la clase PantallaObtenerRegTarjeta anteriormente identificadas en la Tabla 8.38 junto con sus nuevas responsabilidades. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (122) enva el evento Servicios a la InterfaceUsuario (126) enva el evento Salir a la InterfaceUsuario (129) enva el evento Actualizar a la InterfaceUsuario (133) Tabla 8.41. Tarjeta para la clase PantallaObtenerRegTarjeta con nuevas responsabilidades identificadas hasta el momento. En la Tabla 8.42 se muestra las responsabilidades para la clase InterfaceBaseDatosRegistro anteriormente identificadas en la Tabla 8.35 junto con sus nuevas responsabilidades. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59)

Weitzenfeld: Captulo 8

35

solicita actualizarRegistroUsuario a la BaseDatosRegistro (82) solicita eliminarRegistroUsuario a la BaseDatosRegistro (89) solicita crearRegistroTarjeta a la BaseDatosRegistro (104) solicita obtenerRegistroTarjeta a la BaseDatosRegistro (116) solicita actualizarRegistroTarjeta a la BaseDatosRegistro (136) Tabla 8.42. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Continuamos con el subflujo Eliminar Registro Tarjeta (S-5) del caso de uso Registrar Tarjeta como se muestra a continuacin, S-5 Eliminar Registro Tarjeta Subflujos La PantallaObtenerRegTarjeta enva el evento Eliminar a la InterfaceUsuario. La InterfaceUsuario enva el evento Eliminar" al ManejadorRegistroTarjeta. El ManejadorRegistroTarjeta solicita eliminarRegistroTarjeta a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro solicita eliminarRegistroTarjeta a la Base de Datos Registro. La Base de Datos Registro elimina el RegistroTarjeta (E-1) y devuelve el OK a la InterfaceBaseDatosRegistro. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Se continua con el subflujo Crear Registro Tarjeta (S-1). Nuevamente, tomamos cada una de las frases y las analizamos para identificar nuevas responsabilidades. 140. La PantallaObtenerRegTarjeta enva el evento Eliminar a la InterfaceUsuario. La responsabilidad es enva el evento Eliminar a la InterfaceUsuario y se asigna a PantallaObtenerRegTarjeta. 141. La InterfaceUsuario enva el evento Eliminar" al ManejadorRegistroTarjeta. La responsabilidad es enva el evento Eliminar" al ManejadorRegistroTarjeta y se asigna a InterfaceUsuario. Adicionalmente, se agrega la responsabilidad maneja el evento Eliminar y se asigna al ManejadorRegistroTarjeta. 142. El ManejadorRegistroTarjeta solicita eliminarRegistroTarjeta a la InterfaceBaseDatosRegistro. La responsabilidad es solicita eliminarRegistroTarjeta a la InterfaceBaseDatosRegistro y se asigna al ManejadorRegistroTarjeta. 143. La InterfaceBaseDatosRegistro solicita eliminarRegistroTarjeta a la Base de Datos Registro. La responsabilidad es solicita eliminarRegistroTarjeta a la Base de Datos Registro y se asigna a la InterfaceBaseDatosRegistro. 144. La Base de Datos Registro elimina el RegistroTarjeta (E-1) y devuelve el OK a la InterfaceBaseDatosRegistro. Esta frase se refiere a Base de Datos Registro, un actor externo al sistema, por lo cual no se agregan nuevas responsabilidades. La segunda parte de la frase describe una devolucin por lo cual tampoco se agrega ninguna responsabilidad. 145. La InterfaceBaseDatosRegistro devuelve el OK al ManejadorRegistroTarjeta. Nuevamente, se describe una devolucin por lo cual no se agrega ninguna responsabilidad. 146. Se continua con el subflujo Crear Registro Tarjeta (S-1). Esta es una frase que describe flujo interno de continuacin del caso de uso, por lo cual no agrega responsabilidades. A partir de estas frases obtenemos responsabilidades adicionales y las insertamos en las tarjetas de clase correspondientes. Nuevamente, no todas las clases agregan nuevas responsabilidades. En particular, las responsabilidades identificadas para las clases ManejadorPrincipal y PantallaPrincipal no han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.3 y en la Tabla 8.5, respectivamente. Las responsabilidades identificadas para las clases ManejadorServicio y PantallaServicio tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.10 y en la Tabla 8.11, respectivamente. Adicionalmente, las responsabilidades identificadas para las clases ManejadorRegistroUsuario, PantallaCrearRegUsuario y PantallaObtenerRegUsuario tampoco han sido modificadas y se mantienen iguales a las descritas en la Tabla 8.27, Tabla 8.14 y Tabla 8.28, respectivamente. Tampoco se modifican las responsabilidades de PantallaCrearRegTarjeta mantenindose iguales a las descritas en la Tabla 8.32. En la Tabla 8.43 se muestra las responsabilidades para la clase InterfaceUsuario anteriormente identificadas en la Tabla 8.39 junto con sus nuevas responsabilidades. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades:

Weitzenfeld: Captulo 8

36

Superclases: Subclases: Atributos: despliega la PantallaPrincipal (2) enva el evento Registrarse por Primera Vez al ManejadorPrincipal (6) enva el evento OK al ManejadorPrincipal (11) enva el evento Salir al ManejadorPrincipal (21) despliega la PantallaServicio (24) enva el evento Obtener Registro al ManejadorServicio (36) enva el evento Salir al ManejadorPrincipal (40) despliega la PantallaCrearRegUsuario (43) enva el evento Registrar al ManejadorRegistroUsuario (48) enva el evento Salir al ManejadorRegistroUsuario (55) despliega la PantallaObtenerRegistroUsuario (64) enva el evento Registrar Tarjeta al ManejadorRegistroUsuario (70) enva el evento Servicios al ManejadorRegistroUsuario (73) enva el evento Actualizar al ManejadorRegistroUsuario (80) enva el evento Eliminar al ManejadorRegistroUsuario (87) despliega la PantallaCrearRegTarjeta (97) enva el evento Registrar al ManejadorRegistroTarjeta (102) enva el evento Servicios al ManejadorRegistroTarjeta (109) enva el evento Salir al ManejadorRegistroTarjeta (112) despliega la PantallaObtenerRegTarjeta (121) enva el evento Actualizar al ManejadorRegistroTarjeta (134) enva el evento Eliminar al ManejadorRegistroTarjeta (141) Tabla 8.43. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento. En la Tabla 8.44 se muestra las responsabilidades para la clase ManejadorRegistroTarjeta anteriormente identificadas en la Tabla 8.40 junto con las nuevas responsabilidades. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta (71) solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario (96) maneja el evento Registrar (102) solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro (103) maneja el evento Servicios (109) solicita ofrecerServicio al ManejadorServicio (110) maneja el evento Salir (112) sale del sistema (113) solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro (115) solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario (120) maneja el evento Actualizar (134) solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro (135) maneja el evento Eliminar (141) solicita eliminarRegistroTarjeta a la InterfaceBaseDatosRegistro (142)

Weitzenfeld: Captulo 8

37

Tabla 8.44. Tarjeta para la clase ManejadorRegistroTarjeta con responsabilidades identificadas hasta el momento. En la Tabla 8.45 se muestra las responsabilidades para la clase PantallaObtenerRegTarjeta anteriormente identificadas en la Tabla 8.41 junto con sus nuevas responsabilidades. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega (122) enva el evento Servicios a la InterfaceUsuario (126) enva el evento Salir a la InterfaceUsuario (129) enva el evento Actualizar a la InterfaceUsuario (133) enva el evento Eliminar a la InterfaceUsuario (140) Tabla 8.45. Tarjeta para la clase PantallaObtenerRegTarjeta con nuevas responsabilidades identificadas hasta el momento. En la Tabla 8.46 se muestra las responsabilidades para la clase InterfaceBaseDatosRegistro anteriormente identificadas en la Tabla 8.42 junto con sus nuevas responsabilidades. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita validarRegistroUsuario a la BaseDatosRegistro (14) solicita crearRegistroUsuario a la BaseDatosRegistro (50) solicita obtenerRegistroUsuario a la BaseDatosRegistro (59) solicita actualizarRegistroUsuario a la BaseDatosRegistro (82) solicita eliminarRegistroUsuario a la BaseDatosRegistro (89) solicita crearRegistroTarjeta a la BaseDatosRegistro (104) solicita obtenerRegistroTarjeta a la BaseDatosRegistro (116) solicita actualizarRegistroTarjeta a la BaseDatosRegistro (136) solicita eliminarRegistroTarjeta a la BaseDatosRegistro (143) Tabla 8.46. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades identificadas hasta el momento. Se puede tambin obtener responsabilidades a partir del manejajo de excepciones, como se muestra a continuacin. E-1 informacin incompleta: Falta llenar informacin indispensable para completar el registro de Excepciones tarjeta. Se le vuelve a pedir al usuario que complete el registro de tarjeta. Nuevamente, dejaremos esto por el momento siguiendo las mismas consideraciones anteriores. De manera similar a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta, se tendr que definir las responsabilidades por clase para el sistema completo, algo que presentaremos en los apndices y bajo un alcance limitado. En las siguientes secciones mostramos las tarjetas clases relevantes hasta el momento junto con sus responsabilidades aignadas. Las clases completas se pueden ver en el apndice. InterfaceUsuario La clase InterfaceUsuario recibe y enva eventos a un gran nmero de clases, algo que es resaltado por la lista extensa de responsabilidades identificadas, como se muestra en la Tabla 8.9.

Weitzenfeld: Captulo 8

38

Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega la PantallaPrincipal enva el evento OK al ManejadorPrincipal enva el evento Salir al ManejadorPrincipal enva el evento Registrarse por Primera Vez al ManejadorPrincipal despliega la PantallaServicio enva el evento Obtener Registro al ManejadorServicio despliega la PantallaCrearRegUsuario enva el evento Registrar al ManejadorRegistroUsuario enva el evento Salir al ManejadorRegistroUsuario despliega la PantallaObtenerRegUsuario enva el evento Actualizar" al ManejadorRegistroUsuario enva el evento Eliminar al ManejadorRegistroUsuario enva el evento Registrar Tarjeta al ManejadorRegistroUsuario enva el evento Servicios al ManejadorRegistroUsuario despliega la PantallaCrearRegTarjeta despliega la PantallaObtenerRegTarjeta enva el evento Registrar al ManejadorRegistroTarjeta enva el evento Servicios al ManejadorRegistroTarjeta enva el evento Salir al ManejadorRegistroTarjeta enva el evento Actualizar al ManejadorRegistroTarjeta enva el evento Eliminar al ManejadorRegistroTarjeta Tabla 8.9. Tarjeta para la clase InterfaceUusario con responsabilidades identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Principal Esta seccin incluye las clases principales de la arquitectura que son el ManejadorPrincipal y la PntallaPrincipal. La clase ManejadorPrincipal recibe y enva eventos entre manejadores y la InterfaceUsuario, como se muestra en la Tabla 8.10. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: solicita desplegarPantallaPrincipal a la InterfaceUsuario maneja el evento Registrarse por Primera Vez solicita crearRegistroUsuario al ManejadorRegistroUsuario maneja el evento OK solicita ofrecerServicio al ManejadorServicio solicita validarRegistroUsuario al ManejadorRegistroUsuario maneja el evento Salir sale del sistema

Weitzenfeld: Captulo 8

39

Tabla 8.10. Tarjeta para la clase ManejadorPrincipal con responsabilidades identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase PantallaPrincipal es la encarga de presentar las opciones de inicio del sistema, como se muestra en la Tabla 8.11. Clase: PantallaPrincipal Descripcin: Pantalla principal (P-1). Mdulo: Principal Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Registrarse por Primera Vez a la InterfaceUsuario enva el evento OK a la InterfaceUsuario enva el evento Salir a la InterfaceUsuario Tabla 8.11. Tarjeta para la clase PantallaPrincipal con responsabilidades de interface identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Registro Este mdulo se compone de los mdulos de Usuario, Tarjeta e InterfaceBD. Usuario Esta seccin involucra las clases de registro de usuario que son ManejadoRegistroUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario y RegistroUsuario. La clase ManejadoRegistroUsuario administra todo lo relacionado con registro de usuario, lo cual incluye recibir y enviar eventos entre el ManejadorPrincipal, la InterfaceUsuario, y la InterfaceBaseDatosRegistro, como se muestra en la Tabla 8.12. Ntese que eliminamos las frases de tipo devuelve el OK.... Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario solicita desplegarPantallaCrearRegUsuario a la InterfaceUsuario maneja el evento Registrar solicita crearRegistroUsuario a la InterfaceBaseDatosRegistro solicita validarRegistroUsuario a la InterfaceBaseDatosRegistro solicita desplegarPantallaObtenerRegUsuario a la InterfaceUsuario solicita obtenerRegistroUsuario a la InterfaceBaseDatosRegistro maneja el evento Actualizar solicita actualizarRegistroUsuario a la InterfaceBaseDatosRegistro maneja el evento Eliminar solicita eliminarRegistroUsuario a la InterfaceBaseDatosRegistro maneja el evento Registrar Tarjeta solicita registrarTarjeta al ManejadorRegistroTarjeta maneja el evento Servicios solicita ofrecerServicio al ManejadorServicio maneja el evento Salir sale del sistema

Weitzenfeld: Captulo 8

40

Tabla 8.12. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades identificadas de los casos de uso RegistrarUsuario y ValidarUsuario. La clase PantallaCrearRegUsuario administra la pantalla relacionada con la creacin de registro de usuario, como se muestra en la Tabla 8.13. Clase: PantallaCrearRegUsuario Descripcin: Pantalla de solicitud de registro de usuario (P-3). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Registrar a la InterfaceUsuario enva el evento Salir a la InterfaceUsuario Tabla 8.13. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades de interface identificadas del caso de uso RegistrarUsuario. La clase PantallaObtenerRegUsuario administra la pantalla relacionada con la modificacin y eliminacin de registro de usuario, como se muestra en la Tabla 8.14. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Actualizar" al InterfaceUsuario enva el evento Eliminar a la InterfaceUsuario enva el evento Registrar Tarjeta a la InterfaceUsuario enva el evento Servicios a la InterfaceUsuario enva el evento Salir a la InterfaceUsuario Tabla 8.14. Tarjeta para la clase PantallaObtenerRegUsuario con responsabilidades de interface identificadas del caso de uso RegistrarUsuario. La clase RegistroUsuario guarda la informacin de registro de usuario, como se muestra en la Tabla 8.15. Ntese que hasta el momento no se han asignado responsabilidades a esta clase. Esto no debe preocuparnos por el momento ya que por ser clases entidad sus responsabilidades son bastante limitadas y localizadas. En otras palabras, cambios en ellas no afectarn en mayor manera la lgica de la aplicacin. Clase: RegistroUsuario Descripcin: 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. Mdulo: Registro.Usuario Estereotipo: Entidad Propiedades: Superclases: Subclases: Atributos:

Tabla 8.15. Tarjeta para la clase RegistroUsuario sin responsabilidades iniciales de registro para el caso de uso RegistrarUsuario.

Weitzenfeld: Captulo 8

41

Tarjeta Esta seccin involucra las clases de registro tarjeta que son ManejadoRegistroTarjeta, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta y RegistroTarjeta. La clase ManejadoRegistroTarjeta administra todo lo relacionado con registro de tarjeta, lo cual incluye recibir y enviar eventos entre el ManejadorRegistroUsuario, la InterfaceUsuario, y la InterfaceBaseDatosRegistro, como se muestra en la Tabla 8.16. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta crearRegistroTarjeta solicita desplegarPantallaCrearRegTarjeta a la InterfaceUsuario solicita obtenerRegistroTarjeta a la InterfaceBaseDatosRegistro solicita desplegarPantallaObtenerRegTarjeta a la InterfaceUsuario manejar el evento Registrar solicita crearRegistroTarjeta a la InterfaceBaseDatosRegistro manejar el evento Actualizar solicita actualizarRegistroTarjeta a la InterfaceBaseDatosRegistro manejar el evento Eliminar solicita eliminarRegistroTarjeta a la InterfaceBaseDatosRegistro manejar el evento Servicios solicita ofrecerServicio al ManejadorServicio manejar el evento Salir sale del sistema Tabla 8.16. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades identificadas del caso de uso RegistrarTarjeta. La clase PantallaCrearRegTarjeta administra la pantalla relacionada con la creacin de registro de tarjeta, como se muestra en la Tabla 8.17. Clase: PantallaCrearRegTarjeta Descripcin: Pantalla de solicitud de registro de tarjeta (P-5). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Registrar a la InterfaceUsuario enva el evento Servicios a la InterfaceUsuario enva el evento Salir a la InterfaceUsuario Tabla 8.17. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades de interface identificadas del caso de uso RegistrarTarjeta. La clase PantallaObtenerRegTarjeta administra la pantalla relacionada con la modificacin y eliminacin de registro de tarjeta, como se muestra en la Tabla 8.18. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta

Weitzenfeld: Captulo 8

42

Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Actualizar a la InterfaceUsuario enva el evento Eliminar a la InterfaceUsuario enva el evento Servicios a la InterfaceUsuario enva el evento Salir a la InterfaceUsuario Tabla 8.18. Tarjeta para la clase PantallaObtenerRegTarjeta con responsabilidades de interface identificadas del caso de uso RegistrarTarjeta. La clase RegistroTarjeta guarda la informacin de registro de tarjeta, como se muestra en la Tabla 8.19. Nuevamente, an no se incluyen responsabilidades por ser una clase entidad. Clase: RegistroTarjeta Descripcin: 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. Mdulo: Registro.Tarjeta Estereotipo: Entidad Propiedades: Superclases: Subclases: Atributos:

Tabla 8.19. Tarjeta para la clase RegistroTarjeta sin responsabilidades de registro para el caso de uso RegistrarTarjeta. Interface Base de Datos La clase InterfaceBaseDatosRegistro es la encargada de interactuar con el actor BaseDatosRegistro para escribir y leer la informacin all guardada, tanto de registro de usuario como de registro de tarjeta, como se muestra en la Tabla 8.20. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Interface Propiedades: Superclases: Subclases: Atributos: solicita crearRegistroUsuario a la BaseDatosRegistro solicita validarRegistroUsuario a la BaseDatosRegistro solicita obtenerRegistroUsuario a la BaseDatosRegistro solicita actualizarRegistroUsuario a la BaseDatosRegistro solicita eliminarRegistroUsuario a la BaseDatosRegistro solicita crearRegistroTarjeta a la BaseDatosRegistro solicita obtenerRegistroTarjeta a la BaseDatosRegistro solicita actualizarRegistroTarjeta a la BaseDatosRegistro solicita eliminarRegistroTarjeta a la BaseDatosRegistro

Weitzenfeld: Captulo 8

43

Tabla 8.20. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Servicios La clase ManejadorServicio es la encargada de todo lo relacionado con consultas, reservaciones y pagos. Adems de esto, es responsable de permitir al usuario accesar la informacin de registro, como se muestra en la Tabla 8.21. Clase: ManejadorServicio Descripcin: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Mdulo: Servicios Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: ofrecerServicio solicita desplegarPantallaServicio a la InterfaceUsuario maneja el evento Obtener Registro solicita registrar al ManejadorRegistroUsuario maneja el evento Salir sale del sistema Tabla 8.21. Tarjeta para la clase ManejadorServicio con responsabilidades a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. La clase PantallaServicio es la encarga de presentar las opciones de servicio del sistema, como se muestra en la Tabla 8.22. Clase: PantallaServicio Descripcin: Pantalla de servicios (P-2). Mdulo: Servicios Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Obtener Registro a la InterfaceUsuario Tabla 8.22. Tarjeta para la clase PantallaServicio con responsabilidades a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. Colaboraciones Es indispensable que los objetos dentro de un programa colaboren entre si o de lo contrario el programa consistir de mltiples mini-programas independientes. Las colaboraciones entre objetos se dan en base a las relaciones entre las responsabilidades de las distintas clases. Dado la infinidad de posibles relaciones entre clase, las colaboraciones son la fuente principal de complejidad en el diseo de objetos. Las colaboraciones representan solicitudes de un objeto cliente a un objeto servidor. Los objetos pueden jugar el papel de clientes o servidores dependiendo de su actividad en ese momento. Un objeto juega el papel de servidor cuando satisface una solicitud hecha por un objeto cliente. Desde el punto de vista del cliente, cada una de sus solicitudes de servicio o colaboracin se asocia con una responsabilidad implementada por algn servidor. A su vez, la clase que ofrece el servicio puede solicitar una colaboracin con alguna otra clase servidor. Esta cadena de solicitudes y servicios puede extenderse segn sea necesario. El proceso de identificacin de colaboraciones se basa en la funcionalidad de la aplicacin y de la arquitectura de clases propuesta, algo que fue hecho durante la etapa de anlisis. Para identificar colaboraciones se analiza las responsabilidades de cada clase, decidiendo si cada una de estas clases es capaz de satisfacer sus responsabilidades por si misma o si requiere de otra clase para lograrlo. Se analiza qu tanto sabe cada clase y qu otras clases

Weitzenfeld: Captulo 8

44

necesitan su conocimiento o funcionalidad. El patrn de colaboraciones revela el flujo de control e informacin dentro del sistema. Analizando los patrones de comunicacin entre objetos puede revelar cuando una responsabilidad se ha asignado de forma incorrecta., incluso puede revelar responsabilidades ausentes. Se analizan las colaboraciones estudiando qu objetos dentro del sistema tienen el conocimiento que se busca. Se busca aquellas clases que colaboran y las que no colaboran con las dems, qu grupos de clases parecen trabajar juntas y donde existen cuellos de botella. A travs de las colaboraciones se analizan las dependencias entre clases. Si una clase no tiene colaboraciones con otras clases, en otras palabras, nadie colabora con ella y ella no colabora con nadie, esta clase debe descartarse. Sin embargo, antes de hacerlo es bueno revisar el diseo completo verificando todas las clases y colaboraciones. Es importante recordar que las colaboraciones son en una sola direccin, y que ciertos tipos de clases son tpicamente clientes o servidores, ubicndose las clase en uno u otro extremo de la colaboracin. En la mayora de los casos, las clases correspondientes al estereotipo de borde y entidad no son clientes de otros objetos en el sistema, si no que existen para ser servidores, donde otras clases colaboran con ellas, tpicamente las clases de control. Durante el proceso de identificacin de las colaboraciones se toma la tarjeta de clase que juega el papel de cliente, escribiendo en la columna derecha el nombre de la clase que juega el papel de servidor o sea la clase que colabora para la responsabilidad particular. Se escribe ese nombre directamente a la derecha de la responsabilidad a la cual la colaboracin ayuda a satisfacer. Aunque una responsabilidad pudiera requerir de varias colaboraciones, se escribe el nombre de la clase principal como servidor de la colaboracin. Las dems clases tpicamente pasan a ser parmetros dentro de las llamadas de mtodos al momento de implementarse, por lo cual se pueden mantener como parte de la responsabilidad general. Por otro lado, si varias responsabilidades requieren una misma clase para colaborar, se graban varias colaboraciones, una para cada responsabilidad. Se debe asegurar que la responsabilidad correspondiente exista para cada colaboracin que se grabe. Se debe grabar la colaboracin aunque sta corresponda a otras instancias de la misma clase. Se debe omitir si la colaboracin corresponde al mismo objeto ya que se busca identificar relaciones entre objetos o clases pero no llamadas dentro del mismo objeto. En esta seccin se describen las colaboraciones para el Sistema de Reservaciones en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Ntese que se omiten actores primarios, como Usuario, en las colaboraciones, aunque se incluyen los actores secundarios como BaseDatosRegistro. InterfaceUsuario A partir de la Tabla 8.9 se generan las colaboraciones para la clase InterfaceUsuario, como se muestra en la Tabla 8.23. Ntese que simplemente se pasa la clase subrayada en la columna izquierda a la columna derecha. Este procedimiento se mantiene lo ms mecnico posible durante esta etapa. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega PantallaPrincipal enva el evento OK ManejadorPrincipal enva el evento Salir ManejadorPrincipal enva el evento Registrarse por Primera Vez ManejadorPrincipal despliega PantallaServicio enva el evento Obtener Registro ManejadorServicio despliega PantallaCrearRegUsuario enva el evento Registrar ManejadorRegistroUsuario enva el evento Salir ManejadorRegistroUsuario despliega PantallaObtenerRegUsuario enva el evento Actualizar" ManejadorRegistroUsuario enva el evento Eliminar ManejadorRegistroUsuario enva el evento Registrar Tarjeta ManejadorRegistroUsuario enva el evento Servicios ManejadorRegistroUsuario despliega PantallaCrearRegTarjeta

Weitzenfeld: Captulo 8

45

despliega PantallaObtenerRegTarjeta enva el evento Registrar ManejadorRegistroTarjeta enva el evento Servicios ManejadorRegistroTarjeta enva el evento Salir ManejadorRegistroTarjeta enva el evento Actualizar ManejadorRegistroTarjeta enva el evento Eliminar ManejadorRegistroTarjeta Tabla 8.23. Tarjeta para la clase InterfaceUusario con responsabilidades y colaboraciones identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Principal A partir de la Tabla 8.10 se generan las colaboraciones para la clase ManejadorPrincipal, como se muestra en la Tabla 8.24. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: solicita desplegarPantallaPrincipal InterfaceUsuario maneja el evento Registrarse por Primera Vez solicita crearRegistroUsuario ManejadorRegistroUsuario maneja el evento OK solicita ofrecerServicio ManejadorServicio solicita validarRegistroUsuario ManejadorRegistroUsuario maneja el evento Salir sale del sistema Tabla 8.24. Tarjeta para la clase ManejadorPrincipal con responsabilidades y colaboraciones identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. A partir de la Tabla 8.11 se generan las colaboraciones para la clase PantallaPrincipal, como se muestra en la Tabla 8.25. Clase: PantallaPrincipal Descripcin: Pantalla principal (P-1). Mdulo: Principal Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Registrarse por Primera Vez InterfaceUsuario enva el evento OK InterfaceUsuario enva el evento Salir InterfaceUsuario Tabla 8.25. Tarjeta para la clase PantallaPrincipal con responsabilidades y colaboraciones identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Registro Este mdulo se compone de los mdulos de Usuario, Tarjeta e InterfaceBD. Usuario Esta seccin involucra las clases de registro de usuario que son ManejadoRegistroUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario y RegistroUsuario.

Weitzenfeld: Captulo 8

46

A partir de la Tabla 8.12 se generan las colaboraciones para la clase ManejadoRegistroUsuario, como se muestra en la Tabla 8.26. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: crearRegistroUsuario solicita desplegarPantallaCrearRegUsuario InterfaceUsuario manejar el evento Registrar solicita crearRegistroUsuario InterfaceBaseDatosRegistro solicita validarRegistroUsuario InterfaceBaseDatosRegistro solicita obtenerRegistroUsuario InterfaceBaseDatosRegistro solicita desplegarPantallaObtenerRegUsuario InterfaceUsuario manejar el evento Actualizar solicita actualizarRegistroUsuario InterfaceBaseDatosRegistro manejar el evento Eliminar solicita eliminarRegistroUsuario InterfaceBaseDatosRegistro manejar el evento Registrar Tarjeta solicita registrarTarjeta ManejadorRegistroTarjeta manejar el evento Servicios solicita ofrecerServicio ManejadorServicio manejar el evento Salir sale del sistema Tabla 8.26. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades y colaboraciones identificadas de los casos de uso RegistrarUsuario y ValidarUsuario. A partir de la Tabla 8.12 se generan las colaboraciones para la clase PantallaCrearRegUsuario, como se muestra en la Tabla 8.27. Clase: PantallaCrearRegUsuario Descripcin: Pantalla de solicitud de registro de usuario (P-3). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Registrar InterfaceUsuario enva el evento Salir InterfaceUsuario Tabla 8.27. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades y colaboraciones identificadas del caso de uso RegistrarUsuario. A partir de la Tabla 8.13 se generan las colaboraciones para la clase PantallaObtenerRegUsuario, como se muestra en la Tabla 8.28. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Superclases:

Weitzenfeld: Captulo 8

47

Subclases: Atributos: despliega enva el evento Actualizar" InterfaceUsuario enva el evento Eliminar InterfaceUsuario enva el evento Registrar Tarjeta InterfaceUsuario enva el evento Servicios InterfaceUsuario enva el evento Salir InterfaceUsuario Tabla 8.28. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades y colaboraciones identificadas del caso de uso RegistrarUsuario. A partir de la Tabla 8.14 se generan las colaboraciones para la clase RegistroUsuario, como se muestra en la Tabla 8.29. Dado que RegistroUsuario es una clase entidad, sus responsabilidades por lo general no involucran colaboraciones. En este caso an no se han asignado dichas responsabilidades.. Clase: RegistroUsuario Descripcin: 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. Mdulo: Registro.Usuario Estereotipo: Entidad Propiedades: Superclases: Subclases: Atributos:

Tabla 8.29. Tarjeta para la clase RegistroUsuario sin responsabilidades ni colaboraciones de registro para el caso de uso RegistrarUsuario. Tarjeta Esta seccin involucra las clases de registro de tarjeta que son ManejadoRegistroTarjeta, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta y RegistroTarjeta. A partir de la Tabla 8.15 se generan las colaboraciones para la clase ManejadoRegistroTarjeta, como se muestra en la Tabla 8.30. Revisando las diferentes asignaciones de responsabilidades podemos observar que la colaboracin de solicita registrarTarjeta descrita en la Tabla 8.26 y en colaboracin con el ManejadorRegistroTarjeta no est definida en este ltimo. Por lo tanto podemos agregar ya en esta etapa una responsabilidad registrarTarjeta a la propia clase ManejadorRegistroTarjeta. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: registrarTarjeta crearRegistroTarjeta solicita desplegarPantallaCrearRegTarjeta InterfaceUsuario solicita obtenerRegistroTarjeta InterfaceBaseDatosRegistro solicita desplegarPantallaObtenerRegTarjeta InterfaceUsuario manejar el evento Registrar solicita crearRegistroTarjeta InterfaceBaseDatosRegistro manejar el evento Actualizar

Weitzenfeld: Captulo 8

48

solicita actualizarRegistroTarjeta InterfaceBaseDatosRegistro manejar el evento Eliminar solicita eliminarRegistroTarjeta InterfaceBaseDatosRegistro manejar el evento Servicios solicita ofrecerServicio ManejadorServicio manejar el evento Salir sale del sistema Tabla 8.30. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades y colaboraciones identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.16 se generan las colaboraciones para la clase PantallaCrearRegTarjeta, como se muestra en la Tabla 8.31. Clase: PantallaCrearRegTarjeta Descripcin: Pantalla de solicitud de registro de tarjeta (P-5). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Registrar InterfaceUsuario enva el evento Servicios InterfaceUsuario enva el evento Salir InterfaceUsuario Tabla 8.31. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades y colaboraciones identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.17 se generan las colaboraciones para la clase PantallaObtenerRegTarjeta, como se muestra en la Tabla 8.32. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Actualizar InterfaceUsuario enva el evento Eliminar InterfaceUsuario enva el evento Servicios InterfaceUsuario enva el evento Salir InterfaceUsuario Tabla 8.32. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades y colaboraciones identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.18 se generan las colaboraciones para la clase RegistroTarjeta, como se muestra en la Tabla 8.33. Dado que RegistroTarjeta es una clase entidad, como en el caso de RegistroUsuario, an no se agregan responsabilidades por lo cual no existen colaboraciones. Clase: RegistroTarjeta Descripcin: 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. Mdulo: Registro.Tarjeta Estereotipo: Entidad Propiedades: Superclases:

Weitzenfeld: Captulo 8

49

Subclases: Atributos:

Tabla 8.33. Tarjeta para la clase RegistroTarjeta sin responsabilidades ni colaboraciones de registro para el caso de uso RegistrarTarjeta. Interface Base Datos A partir de la Tabla 8.19 se generan las colaboraciones para la clase InterfaceBaseDatosRegistro, como se muestra en la Tabla 8.34. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceBD Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: solicita crearRegistroUsuario BaseDatosRegistro solicita validarRegistroUsuario BaseDatosRegistro solicita obtenerRegistroUsuario BaseDatosRegistro solicita actualizar RegistroUsuario BaseDatosRegistro solicita eliminarRegistroUsuario BaseDatosRegistro solicita crearRegistroTarjeta BaseDatosRegistro solicita obtenerRegistroTarjeta BaseDatosRegistro solicita actualizarRegistroTarjeta BaseDatosRegistro solicita eliminarRegistroTarjeta BaseDatosRegistro Tabla 8.34. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades y colaboraciones de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Servicios A partir de la Tabla 8.20 se generan las colaboraciones para la clase ManejadorServicio, como se muestra en la Tabla 8.35. Clase: ManejadorServicio Descripcin: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Mdulo: Servicio Estereotipo: Control Propiedades: Superclases: Subclases: Atributos: ofrecerServicio solicita desplegarPantallaServicio InterfaceUsuario maneja el evento Obtener Registro solicita registrar ManejadorRegistroUsuario maneja el evento Salir sale del sistema Tabla 8.35. Tarjeta para la clase ManejadorServicio con responsabilidades y colaboraciones a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.

Weitzenfeld: Captulo 8

50

A partir de la Tabla 8.21 se generan las colaboraciones para la clase PantallaServicio, como se muestra en la Tabla 8.36. Clase: PantallaServicio Descripcin: Pantalla de servicios (P-2). Mdulo: Servicio Estereotipo: Borde Propiedades: Superclases: Subclases: Atributos: despliega enva el evento Obtener Registro InterfaceUsuario Tabla 8.36. Tarjeta para la clase PantallaServicio con responsabilidades y colaboraciones a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. Jerarquas El diseo de las jerarquas de herencia es uno de los aspectos de programacin ms importantes de la orientacin a objetos. Mediante la herencia se puede lograr una buena reutilizacin del cdigo del sistema, logrando arquitecturas de clases ms compactas lo cual puede reducir radicalmente el tamao del sistema final. La herencia se identifica a partir de las responsabilidades y colaboraciones obtenidas anteriormente. De manera general, existen dos formas de aprovechar la herencia. La forma ms comn es la creacin de superclases que guarden responsabilidades comunes a mltiples clases. La forma adicional y ms avanzada est relacionada con el polimorfismo y busca aprovechar no slo responsabilidades comunes sino tambin colaboraciones comunes entre clases. Estos dos enfoques tambin sirven de base para la extensibilidad de la arquitectura de clases. Por ejemplo, si varias clases definen una responsabilidad similar, se puede introducir una superclase de la cual estas clases hereden la responsabilidad comn. Las nuevas superclases tpicamente son clases abstractas. Cuanto mayor sea el nmero de clases concretas que puedan extenderse a partir de una funcionalidad abstracta, mayor ser la probabilidad de que la abstraccin sobreviva las pruebas del tiempo y mejoras del software. Se necesita solo una responsabilidad para definir una superclase abstracta, pero se necesita por lo menos dos subclases antes de esperar disear una abstraccin general til. Si no se tiene o no se prev por lo menos dos casos, no se debe perder tiempo en construir la abstraccin. Probablemente no se pueda disear funcionalidad apropiada general sin varios ejemplos concretos que sirvan de gua. En este etapa se debe revisar las tarjetas de clases y clasificar cada clase segn si es concreta o abstracta. Se debe adems agregar tarjetas para las superclases (abstractas o concretas) segn sea necesario y reasignar responsabilidades para corresponder al nuevo diseo. Mediante la reasignacin de responsabilidades se busca producir jerarquas de clases que puedan reutilizarse y extenderse mas fcilmente. Aunque llevaremos a cabo una sola etapa de diseo de jerarquas, la herencia debe aplicarse continuamente a lo largo del diseo de objetos. Se listan en la tarjeta de clase las responsabilidades propias no heredadas y aquellas responsabilidades que se sobrescriben. No es necesario volver a escribir las responsabilidades que se heredan de las superclases. Ntese en las siguientes secciones que estaremos agregando nuevas superclases, para lo cual agregaremos las correspondientes tarjetas de clases, y estaremos agregando informacin en las secciones de subclases y superclases, adems de la especificacin de si la clase es concreta o abstracta. A continuacin se describen las jerarquas de herencia para el Sistema de Reservaciones en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. InterfaceUsuario Para comenzar analizamos las diversas responsabilidades y colaboraciones asignadas a la clase InterfaceUsuario en la Tabla 8.23 las cuales se muestran nuevamente en la tabla 8.37. despliega PantallaPrincipal enva el evento OK ManejadorPrincipal enva el evento Salir ManejadorPrincipal enva el evento Registrarse por Primera Vez ManejadorPrincipal despliega PantallaServicio enva el evento Obtener Registro ManejadorServicio despliega PantallaCrearRegUsuario

Weitzenfeld: Captulo 8

51

enva el evento Registrar ManejadorRegistroUsuario enva el evento Salir ManejadorRegistroUsuario despliega PantallaObtenerRegUsuario enva el evento Actualizar" ManejadorRegistroUsuario enva el evento Eliminar ManejadorRegistroUsuario enva el evento Registrar Tarjeta ManejadorRegistroUsuario enva el evento Servicios ManejadorRegistroUsuario despliega PantallaCrearRegTarjeta despliega PantallaObtenerRegTarjeta enva el evento Registrar ManejadorRegistroTarjeta enva el evento Servicios ManejadorRegistroTarjeta enva el evento Salir ManejadorRegistroTarjeta enva el evento Actualizar ManejadorRegistroTarjeta enva el evento Eliminar ManejadorRegistroTarjeta Tabla 8.37. Responsabilidades y colaboraciones para la clase InterfaceUusario. Si analizamos estas responsabilidades y colaboraciones con ms detalle podemos apreciar que hay dos grupos de responsabilidades, aquellos correspondientes a despliega y las correspondientes a enva el evento..., como se muestra de manera condensada en la Tabla 8.38. Es importante apreciar que estamos generalizando las diversas responsabilidades enva el evento ... en una comn en donde el evento particular OK, Registrar, etc., son abstraidos de la responsabilidad. despliega PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta enva el evento ... ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Tabla 8.38. Grupos de responsabilidades y colaboraciones para la clase InterfaceUusario. En el caso de la responsabilidad despliega la responsabilidad se llama tambin despliega para todas las clases colaboradoras PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta, como se muestra en la Tabla 8.39. Esto es sumamente importante si deseamos aprovechar el polimorfismo. despliega Tabla 8.39. Grupos de responsabilidades despliega para las distintas pantallas, correspondientes a las clases PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta. En el caso de los manejadores vemos que ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario y ManjeadorRegistroTarjeta todos tienen una resposabilidad comun manejarEvento correspondiente a la responsabilidad inicial enva el evento ..., como se muestra en la Tabla 8.40. manejarEvento Tabla 8.40. Grupos de responsabilidades manejarEvento para los distintos manejadores, correspondientes a las clases ManejadorPrincipal, MnajeadorServicio, ManejadorRegistroUsuario y ManjeadorRegistroTarjeta. Estos dos grupos de responsabilidades se muestran en la Figura 8.3. Ntese que la direccin de la flecha representa la direccin de la llamada de servicio, o sea en direccin de la clase colaboradora. Para el nombre de la asociacin utilizamos la responsabilidad definida en la clase colaboradora correspondiente.

Weitzenfeld: Captulo 8

52

PantallaPrincipal
(from Principal)

despliega despliega despliega

InterfaceUsuario
(from Interfac eUsuario)

manejarEvento manejarEvento manejarEvento

ManejadorPrincipal
(from Principal)

ManejadorServicio
(from Servicios)

PantallaServicio
(from Servicios)

manejarEvento despliega ManejadorRegistroUsuario

(from Registro.Usuario)

PantallaCrearRegUsuario
(from Registro.Usuario)

despliega despliega ManejadorRegistroTarjeta

(from Registro.Tarjeta)

PantallaObtenerRegUsuario
(from Registro.Usuario)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

Figura 8.3 El diagrama muestra las colaboraciones descritas hasta el momento para la clase InterfaceUsuario. En este momento nos preguntamos cmo podemos simplificar estas responsabilidades y colaboraciones. Analicemos las dos situaciones. En el caso de despliega, las colaboraciones estn relacionadas con diferentes pantallas, mientras que en el caso de enva el evento ..., la colaboraciones estn relacionadas con diferentes manejadores. Esta es una tpica situacin de polimorfismo, donde una misma responsabilidad es aprovechada por diversas clases colaboradoras que funcionalmente son similares. La solucin es crear una nueva superclase Pantalla y otra Manejador de manera que las relaciones anteriores descritas en la Tablas 8.38 se conviertan segn se describen en la Tabla 8.41. Ntese que aunque la relacin de colaboracin se simplifica, an incluimos la lista de clases colaboradoras para no perder esta informacin a nivel descriptiva. Esto se denota utilizando la notacin de superclase seguida por : y finalmente por la lista de clases colaboradoras. Sin embargo, el objetivo de diseo es que la InterfaceUsuario deja de conocer explcitamente a todas las clases colaboradoras y que nicamente conozca a la clase general que luego ser sobrecargada. despliega Pantalla : PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta enva el evento ... Manejador : ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Tabla 8.41. Grupos de responsabilidades y colaboraciones para la clase InterfaceUusario revisados segn la creacin de dos nuevas superclases: Pantalla y Manejador. En la Figura 8.4 se muestra la nueva jerarqua de herencia.

Weitzenfeld: Captulo 8

53

Pantalla
(from InterfaceUsuario)

despliega InterfaceUsuario
(from InterfaceUsuario)

manejarEvento

Manejador
(from Principal)

ManejadorServicio PantallaPrincipal
(from Princ ipal ) (from Servicios )

PantallaServicio
(from Servicios)

ManejadorPrincipal
(from Principal)

PantallaCrearRegUsuario
(from Registro.Usuario)

PantallaObtenerRegUsuario
(from Registro.Usuario)

ManejadorRegistroUsuario
(from Regi stro.Us uario)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

Figura 8.4 El diagrama muestra las colaboraciones descritas hasta el momento para la clase InterfaceUsuario luego de la introduccin de las superclases Pantalla y Manejador. Es importante resaltar que se tendr que agregar dos nuevas tarjetas de clases correspondientes a las nuevas clases Pantalla y Manejador recin introducidas. Dichas tarjetas debern incluir responsabilidades correspondientes a despliega y manejarEvento que sern sobrescritas por las diversas pantallas y manejadores en la jerarqua de herencia. La tarjeta de clase modificada para la clase InterfaceUsuario se muestra en la Tabla 8.42. Como parte del proceso de afinacin de nombres cambiamos despliega por desplegarPantalla, el cual es ms descriptivo, y enva el evento ... por enviarEvento lo cual es ms compacto. De tal manera, se reducen de manera radical el nmero de responsabilidades y colaboraciones de la clase InterfaceUsuario. Ntese como los diversos enva el evento ... son abstrados o generalizados por una sola responsabilidad ms genrica llamada enviarEvento. Vale la pena resaltar la gran reduccin en el nmero de responsabilidades y colaboraciones definidas para la clase InterfaceUsuario. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: desplegarPantalla Pantalla : PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta enviarEvento Manejador : ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Tabla 8.42 Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones y jerarquas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Antes de especificar la tarjeta de clase para la nueva superclase Pantalla veamos otra fuente de generalizacin a partir de las diversas pantallas. En la Tabla 8.43 se muestra de manera compacta las responsabilidades y colaboraciones para las diversas pantallas descritas en la seccin de colaboraciones. Las diversas pantallas contienen una responsabilidad despliega y otra enva el evento ..., la cual colabora con InterfaceUsuario. Nuevamente abstraemos las diversas responsabilidades enviar el evento ... en una sola. despliega enva el evento ... InterfaceUsuario Tabla 8.43. Grupos de responsabilidades y colaboraciones para las diversas pantallas. Estas responsabilidades con sus colaboraciones se muestran en la Figura 8.5. Ntese que la direccin de la flecha va ahora en direccin de la InterfaceUsuario. Para el nombre de la asociacin utilizamos la responsabilidad reescrita enviarEvento definida en la clase InterfaceUsuario, la clase colaboradora.

Weitzenfeld: Captulo 8

54

PantallaPrincipal
(from Principal)

enviarEvento InterfaceUsuario
(from InterfaceUsuario)

enviarEvento enviarEvento

enviarEvento PantallaServicio
(from Servicios)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

enviarEvento enviarEvento

PantallaCrearRegUsuario
(from Registro.Usuario)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

PantallaObtenerRegUsuario
(from Registro.Usuario)

Figura 8.5 El diagrama muestra las colaboraciones descritas a partir de las diversas pantallas y en direccin a la InterfaceUsuario. Esta es nuevamente una fuente de polimorfismo donde podemos aprovechar la clase Pantalla antes agregada. En la Figura 8.6 se muestra el diagrama de herencia correspondiente a la Figura 8.5 incluyendo la nueva superclase Pantalla en base al polimorfismo enviarEvento a partir de las diversas pantallas.
InterfaceUsuario
(from InterfaceUsuario)

enviarEvento

Pantalla
(from InterfaceUsuario)

PantallaPrincipal
(from Princ ipal)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

PantallaServicio
(from Servicios)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

PantallaCrearRegUsuario
(from Registro.Usuario)

PantallaObtenerRegUsuario
(from Registro.Usuario)

Figura 8.6 El diagrama muestra las colaboraciones descritas a partir de las diversas pantallas conteniendo la superclase Pantalla y en direccin a la InterfaceUsuario. La responsabilidad enva el evento ... es rescrita como enviarEvento y junto con desplegarPantalla definen las responsabilidades para la clase Pantalla, como se muestra en la Tabla 8.44. La clase Pantalla es definida como Abstracta ya que es una superclase. Adicionalmente, en la seccin de subclases se describen las diversas clases que heredan de ella. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario

Weitzenfeld: Captulo 8

55

Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta Atributos: desplegarPantalla enviarEvento InterfaceUsuario Tabla 8.44. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones y jerarquas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Antes de continuar con la superclase Manejador aprovecharemos para agregar dos nuevas superclases de tipo pantalla agregadas exclusivamente por razones de herencia y no polimorfismo. Estas clases son PantallaRegUsuario la cual define elementos comunes a las pantallas PantallaCrearRegUsuario y PantallaObtenerRegUsuario, y PantallaRegTarjeta la cual define elementos comunes a las pantallas PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta. Los elementos comunes para estas pantallas son bsicamente todos los campos de textos que se repiten entre ellas, difiriendo nicamente en los botones. En la Figura 8.7 se muestra la jerarqua de herencia a partir de la clase Pantalla y conteniendo las clases PantallaRegUsuario y PantallaRegTarjeta.
PantallaPrincipal
(from Principal)

Pantalla
(from InterfaceUsuario)

PantallaServicio
(from Servicios )

PantallaRegUsuario
(from Registro.Us uario)

PantallaRegTarjeta
(from Registro.Tarjeta)

PantallaCrearRegUsuario
(from Registro.Us uario)

PantallaObtenerRegUsuario
(from Registro.Us uario)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

Figura 8.7 El diagrama muestra la jerarqua de clases para el mdulo de registro a partir de la clase Pantalla incluyendo las clases PantallaRegUsuario y PantallaRegTarjeta. En la Tabla 8.45 se describe la clase Pantalla redefinida de acuerdo a las modificaciones con las clases PantallaRegUsuario y PantallaRegTarjeta correspondiente a la Figura 8.7. El cambio se da nicamente en la seccin de subclases. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: desplegarPantalla enviarEvento InterfaceUsuario Tabla 8.45. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones y jerarquas revisadas. Principal A continuacin llevaremos un proceso de generalizacin para la clase Manejador similar al proceso llevado a cabo para la clase Pantalla. En la Tabla 8.46 se muestra de manera compacta las responsabilidades y colaboraciones

Weitzenfeld: Captulo 8

56

comunes para los diversos manejadores descritos en la seccin de colaboraciones. Los diversos manejadores contienen una responsabilidad manejarEvento que es sobrescrita por cada uno de ellos, una responsabilidad solicita desplegarPantalla... en colaboracin con la InterfaceUsuario y que puede ser generalizada de manera similar a enva el evento ..., una responsabilidad solicita ofrecerServicio en colaboracin con ManejadorServicio que es comn a los diversos manejadores y otra responsabilidad comn salir. Los diversos manejadores contienen otras responsabilidades pero estas ya no son comunes entre ellos. manejarEvento solicita desplegarPantalla... InterfaceUsuario solicita ofrecerServicio ManejadorServicio salir Tabla 8.46. Grupos de responsabilidades y colaboraciones para los diversos manejadores. La responsabilidad solicita desplegarPantalla... puede ser reescrita simplemente como desplegarPantalla mientras que solicita ofrecerServicio puede ser reescrita como ofrecerServicio. Estas responsabilidades junto con sus colaboraciones correspondientes se muestran en la Figura 8.8. Nuevamente, la responsabilidad desplegarPantalla debe existir en la clase InterfaceUsuario y ofrecerServicio en la clase ManejadorServicio para que el diagrama sea correcto.
InterfaceUsuario
(from InterfaceUsuario)

desplegarPantalla ManejadorRegistroUsuario
(from Registro.Usuario)

desplegarPantalla desplegarPantalla desplegarPantalla ManejadorPrincipal

(from Princ ipal)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

ofrecerServicio ofrecerServicio

ofrecerServicio ManejadorServicio
(from Serv icios )

Figura 8.8 El diagrama muestra las colaboraciones descritas a partir de los diversos manejadores y en direccin a la InterfaceUsuario y ManejadorServicio. Con la introduccin de la clase Manejador se puede generalizar estas relaciones y aprovechar el polimorfismo correspondiente. En la Figura 8.9 se muestra el diagrama de herencia correspondiente a la Figura 8.8 con la inclusin de la nueva superclase Manejador.

Weitzenfeld: Captulo 8

57

ofrecerServicio InterfaceUsuario
(from InterfaceUsuario)

desplegarPantalla

Manejador
(from Principal)

ManejadorServicio
(from Servicios )

ManejadorRegistroUsuario
(from Registro.Usuario)

ManejadorPrincipal
(from Principal)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

Figura 8.9 El diagrama muestra las colaboraciones descritas a partir de los diversos manejadores conteniendo la superclase Manejador y en direccin a la InterfaceUsuario y ManejadorServicio. Las responsabilidades anteriores para los diversos manejadores son ahora descritos en la superclase Manejador, como se muestra en la Tabla 8.47. La clase Manejador es definida como Abstracta ya que es una superclase. En la seccin de subclases se agregan las diversas clases que heredan de ella. Clase: Manejador Descripcin: Superclase heredada por todos los manejadores del sistema. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclases: Subclases: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: manejarEvento desplegarPantalla InterfaceUsuario ofrecerServicio ManejadorServicio salir Tabla 8.47. Tarjeta para la clase Manejador con responsabilidades, colaboraciones y jerarquas identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En la Figura 8.10 se muestra la jerarqua de herencia a partir de la superclase Manejador.
Manejador
(from Principal)

ManejadorPrincipal
(from Principal)

ManejadorRegistroUsuario
(from Registro.Usuario)

ManejadorServicio
(from Servicios)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

Figura 8.10 El diagrama muestra la jerarqua de clases a partir de la clase Manejador. Ahora veamos como se describen las dems clases a partir de estas modificaciones de herencia. A partir de la Tabla 8.24 se generan las jerarquas para la clase ManejadorPrincipal, como se muestra en la Tabla 8.48. La clase se

Weitzenfeld: Captulo 8

58

define como concreta y se especifica su superclase. La nica responsabilidad sobrescrita de las definidas en la superclase Manejador es manejarEvento ya que el polimorfismo va en direccin de la clase InterfaceUsuario a los diversos manejadores. Las dems responsabilidades descritas en Manejador son nicamente heredadas por los diversos manejadores. Adicionalmente la clase ManejadorPrincipal defina las responsabilidades solicita crearRegistroUsuario y solicita validarRegistroUsuario que son reescritas como crearRegistroUsuario y validarRegistroUsuario, respectivamente. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: manejarEvento crearRegistroUsuario ManejadorRegistroUsuario validarRegistroUsuario ManejadorRegistroUsuario Tabla 8.48. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones y jerarquas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En el caso de las pantallas, todas las responsabilidades se especifican en la superclase Pantalla por lo cual ya no hay necesidad de incluir las responsabilidades descritas anteriormente. Por lo tanto, la clase PantallaPrincipal descrita anteriormente en la Tabla 8.25 se describir de acuerdo a las modificaciones en las jerarquas de herencia, como se muestra en la Tabla 8.49. Se eliminan las responsabilidades y se especifica la clase como concreta y se agrega su superclase. Clase: PantallaPrincipal Descripcin: Pantalla principal (P-1). Mdulo: Principal Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Tabla 8.49. Tarjeta para la clase PantallaPrincipal con responsabilidades, colaboraciones y jerarquas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Dominio Si consideramos que hemos agregado una nueva superclase para las diversas pantallas correspondientes a las clases borde al igual para los diversos manejadores correspondientes a las clases de control, resulta que sera tambin una buena idea agregar una superclase para las diversas clases entidad. Estos no es obvio en este momento ya que nuestras clases entidad, RegistroUsuario y RegistroTarjeta, no tienen responsabilidades asignadas an. Sin embargo, agregar una superclase a grupos de clases con estereotipo comn es siempre una buena idea. En la Figura 8.11 se muestra la jerarqua de herencia a partir de una superclase general llamada Datos.

Weitzenfeld: Captulo 8

59

Datos
(from Dominio)

RegistroUsuario
(from Registro.Usuario)

RegistroTarjeta
(from Registro.Tarjeta)

Figura 8.11 El diagrama muestra la jerarqua de clases para el mdulo de registro a partir de la clase Datos. La superclase Datos que generaliza a las diferentes clases entidad, en este caso RegistroUsuario y RegistroTarjeta, se muestra en la Tabla 8.50. Clase: Datos Descripcin: Superclase para todas las clases entidad. Mdulo: Dominio Estereotipo: Entidad Propiedades: Abstracta Superclases: Subclases: RegistroUsuario, RegistroTarjeta Atributos:

Tabla 8.50. 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. Registro Este mdulo se compone de los mdulos de Usuario, Tarjeta e InterfaceBD. Usuario Esta seccin involucra las clases de registro de usuario que son ManejadoRegistroUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario y RegistroUsuario. Correspondiente a la Tabla 8.26 se describe la clase ManejadoRegistroUsuario, como se muestra en la Tabla 8.51. Con excepcin de manejarEvento sobrescrita por todos los manejadores, las responsabilidades desplegarPantalla, ofrecerServicio y salir son descritas nicamente en la superclase Manejador. Las dems responsabilidades descritas en la Tabla 8.26 son reescritas nicamente eliminando la palabra solicita para volver las responsabilidades ms compactas. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: manejarEvento validarRegistroUsuario InterfaceBaseDatosRegistro crearRegistroUsuario InterfaceBaseDatosRegistro obtenerRegistroUsuario InterfaceBaseDatosRegistro actualizarRegistroUsuario InterfaceBaseDatosRegistro eliminarRegistroUsuario InterfaceBaseDatosRegistro registrarTarjeta ManejadorRegistroTarjeta Tabla 8.51. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones y jerarquas identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.

Weitzenfeld: Captulo 8

60

Se agrega la superclase PantallaRegUsuario antes mencionada, la cual se muestra en la Tabla 8.52. Clase: PantallaRegUsuario Descripcin: Superclase con diseo grfico comn para las pantallas de registro de usuario. Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Abstracta Superclases: Pantalla Subclases: PantallaCrearRegUsuario, PantallaObtenerRegUsuario Atributos:

Tabla 8.52. Tarjeta para la clase PantallaRegUsuario con la jerarqua identificadas de las pantallas de registro de usuario para el caso de uso RegistrarUsuario. A partir de la Tabla 8.27 se generan las jerarquas para la clase PantallaCrearRegUsuario, como se muestra en la Tabla 8.53. De manera similar a la clase PantallaPrincipal, se eliminaron las responsabilidades en esta clase al ser descritas en la superclase Pantalla. Clase: PantallaCrearRegUsuario Descripcin: Pantalla de solicitud de registro de usuario (P-3). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Concreta Superclases: PantallaRegUsuario Subclases: Atributos:

Tabla 8.53. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades, colaboraciones y jerarquas identificadas del caso de uso RegistrarUsuario. A partir de la Tabla 8.28 se generan las jerarquas para la clase PantallaObtenerRegUsuario, como se muestra en la Tabla 8.54. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Concreta Superclases: PantallaRegUsuario Subclases: Atributos:

Tabla 8.54. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades, colaboraciones y jerarquas identificadas del caso de uso RegistrarUsuario. A partir de la Tabla 8.29 se generan las jerarquas para la clase RegistroUsuario, como se muestra en la Tabla 8.55. Ntese que RegistroUsuario es una subclase de la recin introducida clase Datos. Clase: RegistroUsuario Descripcin: 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. Mdulo: Registro.Usuario Estereotipo: Entidad Propiedades: Concreta Superclases: Datos Subclases:

Weitzenfeld: Captulo 8

61

Atributos:

Tabla 8.55. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones y jerarquas de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario. Tarjeta Esta seccin involucra las clases de registro de tarjeta que son ManejadoRegistroTarjeta, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta y RegistroTarjeta. De manera similar a los manejadores anteriores, se describe a partir de la Tabla 8.30 la clase ManejadoRegistroTarjeta, como se muestra en la Tabla 8.56. Se sobrescribe la responsabilidad manejarEvento y se eliminan de esta tarjeta las responsabilidades descritas en la superclase Pantalla, o sea, desplegarPantalla, ofrecerServicio y Salir. Se mantienen las dems responsabilidades reescribindolas sin la palabra solicita. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: manejarEvento registrarTarjeta crearRegistroTarjeta InterfaceBaseDatosRegistro obtenerRegistroTarjeta InterfaceBaseDatosRegistro actualizarRegistroTarjeta InterfaceBaseDatosRegistro eliminarRegistroTarjeta InterfaceBaseDatosRegistro Tabla 8.56. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones y jerarquas identificadas del caso de uso RegistrarTarjeta. Se agrega la superclase PantallaRegTarjeta antes mencionada, la cual se muestra en la Tabla 8.57. Clase: PantallaRegTarjeta Descripcin: Superclase con diseo grfico comn para las pantallas de registro de tarjeta. Mdulo: Registro. Tarjeta Estereotipo: Borde Propiedades: Abstracta Superclases: Pantalla Subclases: PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta Atributos:

Tabla 8.57. Tarjeta para la clase PantallaRegTarjeta con la jerarqua identificadas de las pantallas de registro de tarjeta para el caso de uso RegistrarTarjeta. A partir de la Tabla 8.30 se generan las jerarquas para la clase PantallaCrearRegTarjeta, como se muestra en la Tabla 8.58. Clase: PantallaCrearRegTarjeta Descripcin: Pantalla de solicitud de registro de tarjeta (P-5). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Concreta Superclases: PantallaRegTarjeta Subclases: Atributos:

Weitzenfeld: Captulo 8

62

Tabla 8.58. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades, colaboraciones y jerarquas identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.32 se generan las jerarquas para la clase PantallaObtenerRegTarjeta, como se muestra en la Tabla 8.59. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Concreta Superclases: PantallaRegTarjeta Subclases: Atributos:

Tabla 8.59. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades, colaboraciones y jerarquas identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.33 se generan las jerarquas para la clase RegistroTarjeta, como se muestra en la Tabla 8.60. Ntese que RegistroTarjeta es una subclase de la recin introducida clase Datos. Clase: RegistroTarjeta Descripcin: 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. Mdulo: Registro.Tarjeta Propiedades: Concreta Estereotipo: Entidad Superclases: Datos Subclases: Atributos:

Tabla 8.60. Tarjeta para la clase RegistroTarjeta con responsabilidades, colaboraciones y jerarquas de actualizar y consultar informacin de registro para el caso de uso RegistrarTarjeta. Interface Base Datos A partir de la Tabla 8.34 se generan las jerarquas para la clase InterfaceBaseDatosRegistro, como se muestra en la Tabla 8.61. Se reescriben las responsabilidades eliminando la palabra solicita. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: validarRegistroUsuario BaseDatosRegistro obtenerRegistroUsuario BaseDatosRegistro crearRegistroUsuario BaseDatosRegistro actualizarRegistroUsuario BaseDatosRegistro eliminarRegistroUsuario BaseDatosRegistro

Weitzenfeld: Captulo 8

63

obtenerRegistroTarjeta BaseDatosRegistro crearRegistroTarjeta BaseDatosRegistro actualizarRegistroTarjeta BaseDatosRegistro eliminarRegistroTarjeta BaseDatosRegistro Tabla 8.61. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones y jerarquas de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Servicios A partir de la Tabla 8.35 se generan las jerarquas para la clase ManejadorServicio, como se muestra en la Tabla 8.62. Los cambios son similares a los dems manejadores. Clase: ManejadorServicio Descripcin: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Mdulo: Servicios Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: manejarEvento ofrecerServicio registrar ManejadorRegistroUsuario Tabla 8.62. 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.36 se generan las jerarquas para la clase PantallaServicio, como se muestra en la Tabla 8.63. Clase: PantallaServicio Descripcin: Pantalla de servicios (P-2). Mdulo: Servicios Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Tabla 8.63. Tarjeta para la clase PantallaServicio con responsabilidades, colaboraciones y jerarquas a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. Contratos Un contrato es una mecanismo de diseo para agrupar las distintas responsabilidades de una clase que estn relacionadas lgicamente entre si. Los contratos sirven como indicadores de los diversos servicios provistos por cada clase. El objetivo final del contrato es ser un elemento de abstraccin adicional en el manejo de la complejidad del sistema, dado que la funcionalidad completa del sistema dada a bajo nivel por las responsabilidades, puede ser vista a alto nivel como un grupo de servicios o contratos. El contrato no es simplemente otro nombre para la 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 puede 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

Weitzenfeld: Captulo 8

64

lo tanto, para un mejor manejo de la complejidad del sistema, se debe posponer la definicin de los aspecto privados de una clase y concentrarse 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 hace la solicitud y el servidor respondiendo de manera correspondiente. 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, los marcos (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, lo cual minimizar el nmero de contratos apoyados por cada clase. Esto es algo deseable, ya que cuanto menos contratos existan, ms fcil ser comprender el sistema. 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, junto a 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 formas 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 el Sistema de Reservaciones, en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. InterfaceUsuario Consideremos las dos responsabilidades desplegarPantalla y enviarEvento asignadas a la clase InterfaceUsuario en la seccin anterior de jerarquas las cuales se muestran en la Tabla 8.64. desplegarPantalla Pantalla : PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta enviarEvento Manejador : ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Tabla 8.64 Responsabilidades asignadas a la clase InterfaceUusario luego de la etapa de jerarquas. Si investigamos con mayor detalle estas responsabilidades podemos ver que desplegarPantalla es llamada por los diversos manejadores mientras que enviarEvento es llamada por las diversas pantallas, algo que se muestra en la Figura 8.12. Ntese que las colaboraciones que aparecen en la Tabla 8.64 se dan ms adelante en la colaboracin,

Weitzenfeld: Captulo 8

65

mientras que aqu mostramos las clases que solicitan servicio a las responsabilidades descritas en la clase InterfaceUsuario.
PantallaPrincipal
(from Principal)

Pantalla
(from InterfaceUsuario)

enviarEvento

InterfaceUsuario
(from Interfac eUsuario)

desplegarPantalla

Manejador
(from Principal)

ManejadorServicio
(from Serv icios )

PantallaServicio
(from Servicios)

PantallaRegUsuario
(from Registro.Usuario)

PantallaRegTarjeta
(from Registro.Tarjeta)

ManejadorPrincipal
(from Principal)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

PantallaCrearRegUsuario
(from Registro.Usuario)

PantallaObtenerRegUsuario
(from Registro.Usuario)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

ManejadorRegistroUsuario
(from Registro.Usuario)

Figura 8.12 El diagrama muestra a las diversas clases manejadores y pantallas solicitando servicios de la clase InterfaceUsuario a travs de desplegarPantalla y enviarEvento, respectivamente.. Estos dos grupos de relaciones realmente estn definiendo dos contratos teniendo como servidor a la clase InterfaceUsuario. El primer contrato lo llamaremos desplegarPantalla, al igual que la responsabilidad correspondiente, teniendo como cliente a los diversos manejadores y como servidor a la InterfaceUsuario. Lo identificaremos como el contrato nmero 1 de la clase InterfaceUsuario. El segundo contrato lo llamaremos enviarEvento, al igual que la responsabilidad correspondiente, teniendo como cliente a las diversas pantallas y como servidor a la clase InterfaceUsuario. Lo identificaremos como el contrato nmero 2 de la clase InterfaceUsuario. Histricamente se describan tarjetas de contratos describiendo cada uno de los contratos en trmino de los clientes y servidor involucrado. Nosotros omitiremos esta descripcin ya que la informacin est implcita aunque distribuida en la diversas tarjetas. En general, toda documentacin adicional tiene un precio no slo en su generacin sino ms importante en su mantenimiento. En este caso decidimos reducir esta documentacin adicional. En otras situaciones donde lo documentacin an no exista, ser necesario agregarla. De tal manera y a partir de la Tabla 8.42 se generan los contratos para la clase InterfaceUsuario, como se muestra en la Tabla 8.65. Se asignan nuevas entradas por contratos mientras que las responsabilidades se mantienen igual nicamente asignndolas a los diferentes contratos identificados. Del lado derecho se mantienen las mismas colaboraciones originales para cada contrato. Los nombres de los contratos pueden ser distintos al de las responsabilidades y en general deben ser ms descriptivos. Para resaltar el hecho de que son descripciones generales les asignaremos el nombre Desplegar Pantalla al primer contrato y Enviar Evento al segundo. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla Pantalla : PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta 2. Envar Evento envarEvento Manejador : ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Tabla 8.65. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. De manera similar podemos identificar dos grupos de responsabilidades lgicamente separadas para las diversas pantallas, desplegarPantalla y enviarEvento, ambas definidas en la superclase Pantalla, como se muestra en la Tabla 8.66 a partir de las responsabilidades definidas para la clase Pantalla en la Tabla 8.44. Dio la casualidad que

Weitzenfeld: Captulo 8

66

dichas responsabilidades corresponden a los mismos nombres en la clase InterfaceUsuario, sin embargo representan responsabilidades separados. desplegarPantalla enviarEvento InterfaceUsuario Tabla 8.66. Responsabilidades para la superclase clase Pantalla definidas en la Tabla 8.44 en la seccin de jerarquas. Si analizamos estas responsabilidades podemos observar que desplegarPantalla tiene como cliente a la InterfaceUsuario. Sin embargo enviarEvento no tiene ningn cliente identificado por lo cual la convertiremos en una responsabilidad privada. Ntese que esta responsabilidad colabora con los diversos manejadores a travs de la superclase Manejador. En general, tanto las responsabilidades privadas como las pblicas, a travs de sus contratos, pueden tener ambas colaboradores. En la Figura 8.13. se muestra la clase InterfaceUsuario que solicita servicio a las responsabilidades de las diversas pantallas a travs de las responsabilidades descritas en la clase Pantalla.
PantallaPrincipal
(from Principal)

Pantalla
(from InterfaceUs uario)

desplegarPantalla

InterfaceUsuario
(from InterfaceUsuario)

PantallaServicio
(from Servicios )

PantallaRegUsuario
(from Registro.Usuario)

PantallaRegTarjeta
(from Registro.Tarjeta)

PantallaCrearRegUsuario
(from Registro.Us uario)

PantallaObtenerRegUsuario
(from Registro.Us uario)

PantallaCrearRegTarjeta
(from Registro.Tarjeta)

PantallaObtenerRegTarjeta
(from Registro.Tarjeta)

Figura 8.13 El diagrama muestra la clase InterfaceUsuario como cliente de las diversas pantallas a travs de la responsabilidad desplegarPantalla de la clase Pantalla. Asignaremos como contrato nmero 1 a desplegarPantalla, mientras que enviarEvento ser una responsabilidad privada. En base a estas consideraciones y a partir de la Tabla 8.44 se genera la descripcin para la clase Pantalla, como se muestra en la Tabla 8.67. Ntese en la columna derecha como InterfaceUsuario aparece como colaborador de la responsabilidad enviarEvento a pesar de que sta es privada. Adicionalmente, se agreg un 2 entre parntesis a la derecha de la clase colaboradora InterfaceUsuario. Este 2 corresponde al contrato nmero 2 definido en la clase InterfaceUsuario, en otras palabras el contrato Enviar Evento. Agregando este nmero tenemos informacin adicional sobre la colaboracin entre clases pero a nivel de contratos. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla Responsabilidades Privadas enviarEvento InterfaceUsuario (2) Tabla 8.67. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.

Weitzenfeld: Captulo 8

67

Principal De manera similar a Pantalla podemos identificar cuatro grupos de responsabilidades lgicamente separadas para los diversos manejadores, manejarEvento, desplegarPantalla, ofrecerServicio y salir, todos definidos en la superclase Manejador, como se muestra en la Tabla 8.68 a partir de las responsabilidades definidas para la clase Manejador en la Tabla 8.47. manejarEvento desplegarPantalla InterfaceUsuario ofrecerServicio ManejadorServicio salir Tabla 8.68. Responsabilidades para la superclase clase Manejador definidas en la Tabla 8.45 en la seccin de jerarquas. Si analizamos estas responsabilidades podemos observar que manejarEvento tiene como cliente a la InterfaceUsuario. Sin embargo, las otras tres responsabilidades, desplegarPantalla, ofrecerServicio y salir, no tiene ningn cliente externo a la clase por lo cual la convertiremos en responsabilidades privadas. Ntese nuevamente que dos de estas responsabilidades colaboran con otras clases a pesar de ser privadas. En la Figura 8.15. se muestra la clase InterfaceUsuario que solicita servicio a las responsabilidades de los diversos manejadores a travs de la responsabilidad manejarEvento descrita en la clase Manejador.
InterfaceUsuario
(from InterfaceUsuario)

manejarEvento

Manejador
(from Principal)

ManejadorServicio
(from Serv icios )

ManejadorRegistroUsuario
(from Registro.Usuario)

ManejadorPrincipal
(from Principal)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

Figura 8.15 El diagrama muestra la clase InterfaceUsuario como cliente de los diversos manejadores a travs de la responsabilidad manejarEvento de la clase Manejador. Asignaremos como contrato nmero 1 a manejarEvento, mientras que desplegarPantalla, ofrecerServicio y salir, sern responsabilidades privadas. En base a estas consideraciones y a partir de la Tabla 8.47 se genera la descripcin para la clase Manejador, como se muestra en la Tabla 8.69. Ntese en la columna derecha como InterfaceUsuario aparece como colaborador de la responsabilidad desplegarPantalla a pesar de que sta es privada. Adicionalmente, se agreg un 1 entre parntesis a la derecha de la clase colaboradora InterfaceUsuario. Este 1 corresponde al contrato nmero 1 definido en la clase InterfaceUsuario, en otras palabras el contrato Desplegar Pantalla. Adicionalmente se agreg el nmero 2 entre parntesis a la derecha de la clase colaboradora ManjeadorServicio para la responsabilidad ofrecerServicio, correspondiente al contrato 2 (an no definido) para la clase ManejadorServicio. Los contratos para la clase Manejador se muestran en la Tabla 8.69. Clase: Manejador Descripcin: Superclase heredada por todos los manejadores del sistema. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclases: Subclases: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: Contratos

Weitzenfeld: Captulo 8

68

1. Manejar Evento manejarEvento Responsablidades Privadas desplegarPantalla InterfaceUsuario (1) ofrecerServicio ManejadorServicio (2) salir Tabla 8.69. 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. Dado que ya hemos explicado los nmeros entre parntesis agregados a las clases colaboradoras en la columna derecha, volveremos a definir la tarjeta para la clase InterfaceUsuario correspondiente a la Tabla 8.65. Esto se muestra en la Tabla 8.70 agregando la colaboracin con el contrato 1, Desplegar Pantalla, definido en la clase Pantalla y el contrato 2, Manejar Evento, definido en la clase Manejador. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla Pantalla (1) : PantallaPrincipal (1), PantallaServicio (1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1) 2. Enviar Evento enviarEvento Manejador (1) : ManejadorPrincipal (1), ManejadorServicio (1), ManejadorRegistroUsuario (1), ManejadorRegistroTarjeta (1) Tabla 8.70. Tarjeta para la clase InterfaceUsuario revisada con nmeros de contratos para las colaboraciones. A continuacin consideramos las responsabilidades definidas para la clase ManejadorPrincipal descritas en la Tabla 8.48. La responsabilidad manejarEvento sobreescribe la responsabilidad con el mismo nombre en la clase Manejador por lo cual generaremos un contrato 1 que sobrescribe al contrato general definida en la superclase. Las responsabilidades crearRegsitroUsuario y validarRegistroUsuario son privadas ya que son llamadas por la propia clase, en realidad como consecuencia del contrato Manejar Evento. La clase ManejadorPrincipal con los contratos respectivos, se muestra en la Tabla 8.71. Ntese que se agrega el contrato 2 a la clase colaboradora ManejadorRegistroUsuario, algo que an no se ha definido, pero lo haremos ms adelante. Bsicamente los contratos 1 corresponden en todos los manejadores al contrato Manejar Evento mientras que los contratos a partir del nmero 2 representan los contratos adicionales de los manejadores y se van dando segn una numeracin local incremental. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos

Weitzenfeld: Captulo 8

69

1. Manejar Evento manejarEvento Responsablidades Privadas crearRegistroUsuario ManejadorRegistroUsuario (2) validarRegistroUsuario ManejadorRegistroUsuario (2) Tabla 8.71. 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.49 se generan los contratos para la clase PantallaPrincipal, como se muestra en la Tabla 8.72. Dado que los contratos como las responsabilidades fueron todas definidas en la superclase Pantalla, esta clase se mantiene igual en su descripcin. Clase: PantallaPrincipal Descripcin: Pantalla principal (P-1). Mdulo: Principal Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Tabla 8.72. Tarjeta para la clase PantallaPrincipal con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Dominio A partir de la Tabla 8.50 se generan los contratos para la clase Datos, como se muestra en la Tabla 8.73. Dado que an no se han definido responsabilidades para las clases entidad, esta clase se mantiene igual a la anterior. Clase: Datos Descripcin: Superclase para todas las clases entidad. Mdulo: Dominio Estereotipo: Entidad Propiedades: Abstracta Superclases: Subclases: RegistroUsuario, RegistroTarjeta Atributos:

Tabla 8.73. 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. Registro Este mdulo se compone de los mdulos de Usuario, Tarjeta e InterfaceBD. Usuario Esta seccin involucra las clases de registro de usuario que son ManejadoRegistroUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario y RegistroUsuario. Las responsabilidades de la clase ManejadoRegistroUsuario fueron descritas en la Tabla 8.51, las cuales se vuelven a describir en la Tabla 8.74. manejarEvento validarRegistroUsuario InterfaceBaseDatosRegistro crearRegistroUsuario InterfaceBaseDatosRegistro obtenerRegistroUsuario InterfaceBaseDatosRegistro actualizarRegistroUsuario InterfaceBaseDatosRegistro eliminarRegistroUsuario InterfaceBaseDatosRegistro registrarTarjeta ManejadorRegistroTarjeta

Weitzenfeld: Captulo 8

70

Tabla 8.74. Responsabilidades definidas para la clase ManejadoRegistroUsuario segn las Tabla 8.51. De manera similar a ManejadorPrincipal, la responsabilidad manejarEvento ser asignada al contrato 1, Manejar Evento, por sobrescribir el contrato con el mismo nmero en la superclase Manejador. Del resto de las responsabildiades slo tres son accesadas externamente, crearRegistroUsuario, validarRegistroUsuario y obtenerRegistroUsuario, las dos primeras por ManejadorPrincipal, mientras que la tercera por ManejadorServicio, como se muestra en la Figura 8.16.
ManejadorRegistroUsuario
(from Registro.Usuario)

crearRegistroUsuario validarRegistroUsuario ManejadorPrincipal

(from Principal)

obtenerRegistroUsuario

ManejadorServicio
(from Serv icios )

Figura 8.16 El diagrama muestra las clases ManejadorPrincipal y ManejadorServicio como clientes de las diversas responsabilidades de la clase ManejadoRegistroUsuario. En general los diagramas de colaboracin, como se muestran en la Figura 8.16, son extremadamente tiles para comprender las diversas colaboraciones que ocurren dentro del sistema. Sin embargo, mostrar llamadas a nivel de responsabilidades puede resultar en diagramas extremadamente densos, por lo cual se busca ms bien describir las colaboraciones a nivel de los contratos los cuales son ms reducidos en su nmero que las llamadas por responsabilidad. El mismo diagrama pero a nivel de contratos se muestra en la Figura 8.17. En este caso introducimos un solo contrato llamado Registrar Usuario, el contrato nmero 2, el cual incluye las tres responsabilidades llamadas externamente y que manipulan el registro del usuario, sea a nivel de creacin, validacin u obtencin. Existe siempre la alternativa de definir mltiples contratos, sin embargo, esto nicamente aumentara la complejidad en este caso ya que la funcionalidad puede ser considerada como lgicamente similar.
ManejadorRegistroUsuario
(from Registro.Usuario)

Registrar Usuario

Registrar Usuario

ManejadorPrincipal
(from Principal)

ManejadorServicio
(from Serv icios )

Figura 8.17 El diagrama muestra las clases ManejadorPrincipal y ManejadorServicio como clientes del contrato Registrar Usuario, contrato nmero 2, de la clase ManejadoRegistroUsuario. En la Tabla 8.75 se describe la tarjeta para la clase ManejadorRegistroUsuario. La responsabilidad manejarEvento se asigna al contrato nmero 1, Manejar Evento, mientras que las responsabilidades crearRegistroUsuario, validarRegistroUsuario y obtenerRegistroUsuario, son asignadas al contrato nmero 2, Registrar Usuario. El resto de las responsabilidades, actualizarRegistroUsuario, eliminarRegistroUsuario y registrarTarjeta, se mantienen como responsabilidades privadas ya que son llamadas localmente dentro de la clase ManejadorRegistroUsuario. Ntese que nuevamente se agregaron nmeros de contratos a las diferentes clases colaboradoras. Estos contratos estn an por definirse, sin embargo, mantenemos la numeracin lgica anteriormente mencionada. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Concreta Superclases: Manejador

Weitzenfeld: Captulo 8

71

Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento 2. Registrar Usuario crearRegistroUsuario InterfaceBaseDatosRegistro (1) validarRegistroUsuario InterfaceBaseDatosRegistro (1) obtenerRegistroUsuario InterfaceBaseDatosRegistro (1) Responsabilidades Privadas actualizarRegistroUsuario InterfaceBaseDatosRegistro (1) eliminarRegistroUsuario InterfaceBaseDatosRegistro (1) registrarTarjeta ManejadorRegistroTarjeta (2) Tabla 8.75. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario. De manera similar a las dems pantallas, la clase PantallaRegUsuario se describe igual a como se describi originalmente en la Tabla 8.50, como se muestra en la Tabla 8.76. Clase: PantallaRegUsuario Descripcin: Superclase con diseo grfico comn para las pantallas de registro de usuario. Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Abstracta Superclases: Pantalla Subclases: PantallaCrearRegUsuario, PantallaObtenerRegUsuario Atributos:

Tabla 8.76. Tarjeta para la clase PantallaRegUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarUsuario. A partir de la Tabla 8.53 se genera la clase PantallaCrearRegUsuario, como se muestra en la Tabla 8.77. Clase: PantallaCrearRegUsuario Descripcin: Pantalla de solicitud de registro de usuario (P-3). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Tabla 8.77. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarUsuario. A partir de la Tabla 8.54 se genera la clase PantallaObtenerRegUsuario, como se muestra en la Tabla 8.78. Clase: PantallaObtenerRegUsuario Descripcin: Pantalla de devolucin con informacin de registro de usuario (P-4). Mdulo: Registro.Usuario Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Weitzenfeld: Captulo 8

72

Tabla 8.78. Tarjeta para la clase PantallaCrearRegUsuario con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarUsuario. La clase RegistroUsuario se mantiene igual a como se describi anteriormente en la Tabla 8.55, como se muestra en la Tabla 8.79. Clase: RegistroUsuario Descripcin: 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. Mdulo: Registro.Usuario Estereotipo: Entidad Propiedades: Concreta Superclases: Datos Subclases: Atributos:

Tabla 8.79. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas y contratos de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario. Tarjeta Esta seccin involucra las clases de registro de tarjeta que son ManejadoRegistroTarjeta, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta y RegistroTarjeta. Las responsabilidades de la clase ManejadoRegistroTarjeta fueron descritas en la Tabla 8.56, las cuales se vuelven a describir en la Tabla 8.80. manejarEvento registrarTarjeta crearRegistroTarjeta InterfaceBaseDatosRegistro obtenerRegistroTarjeta InterfaceBaseDatosRegistro actualizarRegistroTarjeta InterfaceBaseDatosRegistro eliminarRegistroTarjeta InterfaceBaseDatosRegistro Tabla 8.80. Responsabilidades definidas para la clase ManejadoRegistroTarjeta segn las Tabla 8.56. De manera similar a ManejadorPrincipal y ManejadorRegistroUsuario, la responsabilidad manejarEvento ser asignada al contrato 1, Manejar Evento, por sobrescribir el contrato con el mismo nmero en la superclase Manejador. La nica otra responsabilidad accesada externamente es registrarTarjeta, la cual es llamada por el ManejadorRegistroUsuario, como se muestra en la Figura 8.18.
ManejadorRegistroTarjeta
(from Registro.Tarjeta)

registrarTarjeta

ManejadorRegistroUsuario
(from Registro.Usuario)

Figura 8.18 El diagrama muestra la clase ManejadoRegistroUsuario como cliente de la responsabilidad registrarTarjeta de la clase ManejadoRegistroTarjeta. En la Tabla 8.81 se describe la tarjeta para la clase ManejadorRegistroTarjeta. La responsabilidad manejarEvento se asigna al contrato nmero 1, Manejar Evento, mientras que la responsabilidad registrarTarjeta es asignada al contrato nmero 2, Registrar Tarjeta. El resto de las responsabildiades, crearRegistroTarjeta, obtenerRegistroTarjeta, actualizarRegistroTarjeta y eliminarRegistroTarjeta, se mantienen como responsabilidades privadas ya que son llamadas localmente dentro de la clase ManejadorRegistroTarjeta. Ntese que nuevamente se agregaron nmeros de contratos a las diferentes clases colaboradoras. Estos contratos estn an por definirse, sin embargo, mantenemos la numeracin lgica anteriormente mencionada. A partir de la Tabla 8.56 se generan los contratos para la clase ManejadoRegistroTarjeta, como se muestra en la Tabla 8.81. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones.

Weitzenfeld: Captulo 8

73

Propiedades: Concreta Mdulo: Registro.Tarjeta Estereotipo: Control Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento 2. Registrar Tarjeta registrarTarjeta Responsabilidades Privadas crearRegistroTarjeta InterfaceBaseDatosRegistro (2) obtenerRegistroTarjeta InterfaceBaseDatosRegistro (2) actualizarRegistroTarjeta InterfaceBaseDatosRegistro (2) eliminarRegistroTarjeta InterfaceBaseDatosRegistro (2) Tabla 8.81. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta. Las pantallas se describen nuevamente de manera similar a las anteriores. A partir de la Tabla 8.57 se vuelve a describir la clase PantallaRegTarjeta, como se muestra en la Tabla 8.82. Clase: PantallaRegTarjeta Descripcin: Superclase con diseo grfico comn para las pantallas de registro de tarjeta. Mdulo: Registro. Tarjeta Estereotipo: Borde Propiedades: Abstracta Superclases: Pantalla Subclases: PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta Atributos:

Tabla 8.82. Tarjeta para la clase PantallaRegTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.58 se describe la clase PantallaCrearRegTarjeta, como se muestra en la Tabla 8.83. Clase: PantallaCrearRegTarjeta Descripcin: Pantalla de solicitud de registro de tarjeta (P-5). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Tabla 8.83. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta. A partir de la Tabla 8.59 se describe la clase PantallaObtenerRegTarjeta, como se muestra en la Tabla 8.84. Clase: PantallaObtenerRegTarjeta Descripcin: Pantalla de devolucin con informacin de registro de tarjeta (P-6). Mdulo: Registro.Tarjeta Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla

Weitzenfeld: Captulo 8

74

Subclases: Atributos:

Tabla 8.84. Tarjeta para la clase PantallaCrearRegTarjeta con responsabilidades, colaboraciones, jerarquas y contratos identificadas del caso de uso RegistrarTarjeta. El RegistroTarjeta se mantiene igual a la descripcin anterior, de manera anloga a RegistroUsuario. A partir de la Tabla 8.60 se describe la clase RegistroTarjeta, como se muestra en la Tabla 8.85. Clase: RegistroTarjeta Descripcin: 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. Mdulo: Registro.Tarjeta Estereotipo: Entidad Propiedades: Concreta Superclases: Datos Subclases: Atributos:

Tabla 8.85. 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 Datos Las responsabilidades de la clase InterfaceBaseDatosRegistro fueron descritas en la Tabla 8.61, las cuales se vuelven a describir en la Tabla 8.86. validarRegistroUsuario BaseDatosRegistro obtenerRegistroUsuario BaseDatosRegistro crearRegistroUsuario BaseDatosRegistro actualizarRegistroUsuario BaseDatosRegistro eliminarRegistroUsuario BaseDatosRegistro obtenerRegistroTarjeta BaseDatosRegistro crearRegistroTarjeta BaseDatosRegistro actualizarRegistroTarjeta BaseDatosRegistro eliminarRegistroTarjeta BaseDatosRegistro Tabla 8.86. Responsabilidades definidas para la clase InterfaceBaseDatosRegistro segn las Tabla 8.61. Se pueden apreciar dos grupos de responsabilidades para la clase InterfaceBaseDatosRegistro, aquellas responsabilidades relacionadas con el registro de usuario y aquellas relacionadas con el registro de tarjeta. En la Figura 8.19 podemos apreciar esto en mayor detalle.

Weitzenfeld: Captulo 8

75

InterfaceBaseDatosRegistro
(from RegistroInterfac eBD)

obtenerRegistroTarjeta crearRegistroTarjeta actualizarRegistroTarjeta eliminarRegistroTarjeta

validarRegistroUsuario obtenerRegistroUsuario crearRegistroUsuario actualizarRegistroUsuario eliminarRegistroUsuario

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

ManejadorRegistroUsuario
(from Registro.Usuario)

Figura 8.19 El diagrama muestra las clases ManejadoRegistroUsuario y ManejadoRegistroTarjeta como clientes de la clase InterfaceBaseDatosRegistro. En la Figura 8.19 podemos nuevamente apreciar la complejidad de diagramar las relaciones entre clases a nivel de responsabilidades, sera menos complejo hacerlo a nivel de contratos siempre cuando estos agrupen a las responsabilidades. Si consideramos que existen dos grupos de responsabilidades, organizadas de acuerdo a las dos clases clientes, ManejadoRegistroUsuario y ManejadoRegistroTarjeta, podemos de manera natural definir dos contratos, el nmero 1 correspondiente a Registrar Usuario y el nmero 2 correspondiente a Registrar Tarjeta. Esta agrupacin simplifica la visualizacin de los contratos como podemos apreciar en la Figura 8.20.
InterfaceBaseDatosRegistro
(from RegistroInterfac eBD)

Registrar Tarjeta

Registrar Usuario

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

ManejadorRegistroUsuario
(from Registro.Usuario)

Figura 8.20 El diagrama muestra las clases ManejadoRegistroUsuario y ManejadoRegistroTarjeta como clientes de la clase InterfaceBaseDatosRegistro describiendo las relaciones a nivel de contratos. En la Tabla 8.87 se describe la tarjeta para la clase InterfaceBaseDatosRegistro. Se definen dos contratos correspondientes a Registrar Usuario y Registrar Tarjeta. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario crearRegistroUsuario BaseDatosRegistro

Weitzenfeld: Captulo 8

76

obtenerRegistroUsuario BaseDatosRegistro actualizarRegistroUsuario BaseDatosRegistro eliminarRegistroUsuario BaseDatosRegistro validarRegistroUsuario BaseDatosRegistro 2. Registrar Tarjeta crearRegistroTarjeta BaseDatosRegistro obtenerRegistroTarjeta BaseDatosRegistro actualizarRegistroTarjeta BaseDatosRegistro eliminarRegistroTarjeta BaseDatosRegistro Tabla 8.87. 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. Servicios La descripcin del ManejadorServicio es similar a los dems manejadores. Se genera un contrato Manejar Evento similar a los dems manejadores y otro propio a esta clase, Ofrecer Servicio el cual tiene como cliente a los dems manejadores, como se muestra en la Figura 8.21.
ofrecerServicio Manejador
(from Principal)

ManejadorServicio
(from Servicios)

ManejadorRegistroUsuario
(from Registro.Usuario)

ManejadorPrincipal
(from Principal)

ManejadorRegistroTarjeta
(from Registro.Tarjeta)

Figura 8.21 El diagrama muestra a las diversas clases de manejadores como clientes de de la clase ManejadorServicio. A partir de la Tabla 8.62 se describe la clase ManejadorServicio, como se muestra en la Tabla 8.88. Adems de los dos contratos antes mencionados, se agrega una responsabilidad privada llamada registrar. Clase: ManejadorServicio Descripcin: El manejador de servicios se encarga de enviar las peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra. Mdulo: Servicios Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento 2. Ofrecer Servicio ofrecerServicio Responsablidades Privadas registrar ManejadorRegistroUsuario (2)

Weitzenfeld: Captulo 8

77

Tabla 8.88. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas y contratos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. De manera similar a las dems pantallas y a partir de la Tabla 8.63 se describe la clase PantallaServicio, como se muestra en la Tabla 8.89. Clase: PantallaServicio Descripcin: Pantalla de servicios (P-2). Mdulo: Servicios Estereotipo: Borde Propiedades: Concreta Superclases: Pantalla Subclases: Atributos:

Tabla 8.89. Tarjeta para la clase PantallaServicio con responsabilidades, colaboraciones, jerarquas y contratos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. Subsistemas Como se ha podido apreciar hasta el momento, la complejidad del sistema aumenta a medida que se incorporan nuevos detalles en el diseo, algo que por lo general es inevitable. Para lograr un mejor manejo de esta complejidad introducimos el concepto de subsistemas, el cual permite dividir el sistema completo en diversas partes, inspirado en la idea de divide y conquista. Los subsistemas permiten agrupar objetos relacionados para lograr cierta funcionalidad en mini-sistemas. El sistema completo se compone de estos mini-sistemas o subsistemas y cada subsistema puede ser subdividido en subsistemas adicionales o ser definido en trminos de los objetos finales. Los subsistemas tambin permiten trabajar en diferentes partes del sistema en paralelo mediante su asignacin a mltiples diseadores. La organizacin en subsistemas se logra a partir de los contratos identificadas anteriormente entre los objetos. 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 pueden tener estructuras complejas, con clases colaborando entre si para satisfacer sus distintas responsabilidades contribuyendo al objetivo general del subsistema, o sea, satisfacer sus responsabilidades. Se busca tener un fuerte acoplamiento funcional dentro de cada subsistema y un dbil acoplamiento entre subsistemas, en otras palabras, se busca tener la mnima 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 y subsistemas internos. Es importante distinguir entre el concepto de mdulo y subsistema. Un mdulo agrupa clases, correspondiente a bibliotecas, o sea, organizaciones estticas definidas para almacenar y facilitar el acceso a las clases. Esto es similar al concepto de directorios en una computadora. Son estructuras puramente organizacionales sin ningn efecto sobre los propios procesos. Por otro lado, el subsistema agrupa objetos, siendo una abstraccin dinmica correspondiente a la funcionalidad del proceso. En general, los objetos pertenecientes a un subsistema son instancias de clases que deben existir forzosamente en algn mdulo. Mientras que las clases no deben duplicarse entre mdulos, se permite instanciar objetos de la misma clase en mltiples subsistemas, siendo esto parte de la reutilizacin de cdigo. 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. Tpicamente, los objetos de las clases entidad son reutilizados en los diversos subsistemas, mientras que los objetos de control y por lo general las de borde son propias a cierto subsistema. Los subsistemas son una pieza fundamental en el manejo de la modularidad y extensibilidad del sistema. Por tal motivo, los subsistemas deben 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. Cabe resaltar que los subsistemas no existen durante la ejecucin de la aplicacin, son puramente abstracciones del sistema. Si consideramos que la mayor fuente de complejidad en el sistema 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

Weitzenfeld: Captulo 8

78

organizadas en grupos (clusters). Si se observan que cierto grupo de objetos estn muy relacionados entre si pero no tanto con otro grupo de objetos, esto deben asignarse a subsistemas comunes. Como parte del proceso de identificacin de subsistemas, se define un protocolo de comunicacin para cada subsistema, el cual especifica las posibles interacciones entre subsistemas. Esto se logra exportando o haciendo pblicos ciertos contratos pertenecientes a ciertos objetos del subsistema. La interface de estos objetos, sus servicios, definen la interface del subsistema completo. Para determinar los contratos apoyados por un subsistema, se tiene que encontrar todas los objetos o clases que proveen servicios a clientes fuera del subsistema. Al igual que las clases, se debe describir los contratos ofrecidos por cada subsistema. Esto se hace introduciendo el concepto de tarjeta de subsistemas de manera anloga al de clases. 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. Los 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.90. Subsistema: Nombre del Subsistema Descripcin: Descripcin del Subsistema Clases: Grupo de clases (instanciadas) que participan en este subsistema.

Tabla 8.90. Tarjeta para subsistemas. En la columna izquierda se muestran los contratos ofrecidos de manera externa 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. Es importante notar que las clases abstractas no se asignan a ningn subsistema ya que no podran ser instanciados directamente. En su lugar asignamos nicamente clases concretas. Por ejemplo, en la Tabla 8.91 se muestra un ejemplo para un subsistema InterfaceUsuario, donde el contrato externo al subsistema sera Manejar Evento mientras que la clase servidora para este contrato sera InterfaceUsuario a travs de su contrato 1. Subsistema: SubsistemaInterfaceUsuario Descripcin: Este subsistema agrupa todos los objetos involucrados con el manejo general de las interfaces de usuario. Clases: InterfaceUsuario. 1. Manejar Evento InterfaceUsuario (1)

Tabla 8.91. Tarjeta para el subsistema InterfaceUsuario. Antes de definir los diferentes subsistemas para el sistema de reservaciones, describiremos los diagramas de colaboracin a nivel de subsistemas. Una de las maneras de hacerlo, y como la haremos aqu, es describir el subsistema como un rectngulo y cada uno de los contratos del subsistema como crculos. Estos contratos son asociados grficamente con la clase servidor que implementa el contrato real mediante una relacin de realizacin, como se muestra en la Figura 8.22.

Clase Servidor Contrato Subsistema

Figura 8.22 Diagrama de subsistema con un contrato asociado con la clase servidor que lo implementa. Lamentablemente, muchas de las herramientas CASE no apoyan de manera completa la diagramacin de los subsistemas. Por ejemplo, el subsistema descrito en la Tabla 8.91 se describira como se muestra en la Figura 8.23.

Weitzenfeld: Captulo 8

79

InterfaceUsuario 1. Desplegar Pantalla SubsistemaInterfaceUsuario

Figura 8.23 Diagrama de subsistema para el ejemplo del subsistema InterfaceUsuario. Dado que los subsistemas son puramente abstracciones, los contratos se dan entre clases clientes solicitando servicios a los subsistemas a travs de sus respectivas clases servidores utilizando una flecha del cliente al servidor, como se muestra en la Figura 8.24 (la flecha de la derecha proveniente de Clase Cliente).

Clase Servidor Contrato Subsistema

Clase Cliente

Figura 8.24 Diagrama de colaboracin donde Clase Cliente llama al Contrato del Subsistema implementado por la Clase Servidor. Si dos clases hacen solicitudes a un mismo contrato, se dibuja mltiples flechas al mismo crculo. Por ejemplo, en la Figura 8.25 se muestra dos manejadores llamando al contrato Desplegar Pantalla del subsistema InterfaceUsuario.
ManejadorPrincipal

InterfaceUsuario 1. Desplegar Pantalla SubsistemaInterfaceUsuario ManejadorServicio

Figura 8.25 Diagrama de subsistema para el ejemplo del subsistema InterfaceUsuario con dos clientes para el contrato Desplegar Pantalla, ManejadorPrincipal y ManejadorServicio. 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, algo que luego se traduce en simplificacin en los diagramas de colaboracin. A continuacin identificaremos los subsistemas para el Sistema de Reservaciones. Dado que el enfoque del desarrollo del sistema ha sido a travs de casos de uso, ser natural inicialmente identificar subsistemas a partir de ellos. Sin embargo, el criterio principal para la asignacin de clase a los subsistemas es minimizar al interaccin entre clases en distintos subsistemas. Por otro lado, se debe mantener cierta relacin con la lgica introducida en la arquitectura de clase. No debemos olvidarnos que estamos diseando. Recordemos tambin que los subsistemas pueden definirse de manera jerrquica, a diferencia de los casos de uso. Entonces, comencemos a analizar estas consideraciones en relacin a nuestro sistema para poder identificar los subsistemas relevantes. Viendo el sistema a un alto nivel pudiramos definir dos grupos de clases generales: aquellos relacionados con lo relacionado con registros y todo lo relacionado con consultas, reservaciones y pagos, o sea, los propios servicios del sistema. Por lo tanto, a un primer nivel podemos definir un SubsistemaRegistro y otro SubsistemaServicio. Estos subsistemas puede dividirse en subsistemas adicionales si as se deseara. Sin embargo, antes de definir subsistema ms detallados veamos que ocurre con los niveles superiores. Aunque quedara bastante clara la asignacin de la mayora de clases a estos dos subsistemas, como en el caso del ManejadorRegistroUsuario, ManejadorReservas, etc., hay ciertas clases que requieren un anlisis ms detallado. Por ejemplo, a que subsistema asignamos la InterfaceUsuario y el ManejajadorPrincipal? Tanto la InterfaceUsuario como el ManejadorPrincipal son clases que no pertenecen de manera natural a ninguno de los dos subsistemas anteriores. Pudiramos definir un nuevo subsistema para ambos o si lgicamente son

Weitzenfeld: Captulo 8

80

independientes, definir dos nuevos subsistemas, uno para cada uno. Esto lo haremos, dado que la InterfaceUsuario es genrica en relacin a la lgica interna y bastante independiente de la aplicacin en si, a diferencia del ManejadorPrincipal que tiene cierto conocimiento sobre el registro y servicios de la aplicacin. Otra manera de conceptuar la creacin de estos dos nuevos subsistemas es que inicialmente se defini el sistema en base a su funcionalidad en trmino de los casos de uso, o sea sus servicios externos. Sin embargo, tambin podemos considerar el sistema en trmino a sus servicios internos. Por ejemplo, la InterfaceUsuario ofrece servicios internos al sistema para que se pueda desplegar las diferentes pantallas y se pueda obtener eventos del Usuario. De igual manera, el ManejadorPrincipal ofrece funcionalidad para inicializar la aplicacin, nuevamente un servicio interno que coordina entre funcionalidades externas. Por lo tanto, pudiramos definir el sistema completo en trmino de cuatro subsistemas, SubsistemaInterfaceUsuario, SubsistemaPrincipal, SubsistemaRegistro y SusbsistemaServicio, como se muestra en la Figura 8.26.
<<subsystem>> SubsistemaInterfaceUsuario (from Logical View)

<<subsystem>> SubsistemaRegistro (from Logical View)

<<subsystem>> SubsistemaPrincipal (from Logical View)

<<subsystem>> SubsistemaServicios (from Logical View)

Figura 8.26 Subsistemas de alto nivel para el sistema de reservaciones de vuelos. Estos subsistemas sern descritos con mayor detalle a continuacin, aunque limitndonos a los subsistemas relevantes para la funcionalidad descrita en los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. SubsistemaInterfaceUsuario El SubsistemaInterfaceUsuario fue descrito de manera preliminar en la Tabla 8.91. Este subsistema consiste principalmente de la clase InterfaceUsuario. Podemos apreciar que en la Tabla 8.70 se definieron dos contratos para la clase InterfaceUsuario, Desplegar Pantalla y Enviar Evento. Estos contratos tienen como clientes a los diversos manejadores y a las diversas pantallas. El contrato Desplegar Pantalla se define como externo ya que los manejadores sern parte de otros subsistemas. En el caso de las pantallas debemos preguntarnos si stas debern asignarse al SubsistemaInterfaceUsuario por ser todas clases borde o distribuirse entre los diversos subsistemas segn su funcionalidad. La decisin depende de hacer un balance entre la relacin de esta clase con las dems clases a nivel de comunicaciones y funcionalmente a cual de los subsistemas debieran pertenecer. A nivel de comunicaciones, las diversas pantallas tienen los contratos Desplegar Pantalla definidos en la superclase Pantalla, llamado por la InterfaceUsuario, y a su vez llaman al contrato Enviar Evento definido por la clase InterfaceUsuario. En otras palabras, a nivel de comunicaciones, lo lgico sera asignar todas las pantallas a este subsistema. A nivel lgico, las pantallas se deberan asignar a los subsistemas que definan la funcionalidad correspondiente. Sin embargo, nuestro enfoque ser el primero, asignar todas las pantallas al SubsistemaInterfaceUsuario. Esto nos evita tener que definir todos os contratos Enviar Evento de las diversas pantallas como externos a cada uno de los subsistemas. Se pudiera hacer un anlisis similar para los manejadores, donde terminaramos asignando todos ellos a un solo subsistema, lo cual sera contraproducente. La gran diferencia entre las pantallas y los manejadores es que los manejadores representan la funcionalidad del sistema mientras que las pantallas representan nicamente aspectos de presentacin los cuales son hasta cierto punto independientes de la funcionalidad. Si la lgica de la aplicacin cambia, todo el sistema debe cambiar, pero si la presentacin cambia, no necesariamente debe cambiar toda la aplicacin. Este es el caso, por ejemplo, de pasar este ejemplo de reservaciones al Internet donde la lgica se mantiene pero todo el diseo de pantallas (no el diseo grfico) es completamente distinto. Por lo tanto, la decisin de asignar las pantallas a este subsistema es ms justificable que el caso de asignar a los manejadores. La tarjeta para el SubsistemaInterfaceUsuario se muestra en la Tabla 8.92. Subsistema: SubsistemaInterfaceUsuario Descripcin: Este subsistema agrupa todos los objetos involucrados con el manejo general de las interfaces de usuario. Clases: InterfaceUsuario, PantallaPrincipal, PantallaServicio, PantallaCrearRegUsuario, PantallaObtenerRegUsuario, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta Contratos Servidor

Weitzenfeld: Captulo 8

81

InterfaceUsuario (1) 1. Desplegar Pantalla Tabla 8.92. Tarjeta de subsistema para SubsistemaInterfaceUsuario mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. El SubsistemaInterfaceUsuario se muestra grficamente en la Figura 8.27. Se muestra nicamente la clase InterfaceUsuario por ser el servidor del subsistema.

InterfaceUsuario 1. Desplegar Pantalla

SubsistemaInterfaceUsuario

Figura 8.27 Diagrama de subsistemas para el SubsistemaInterfaceUsuario mostrando nicamente a InterfaceUsuario, la clase servidor. SubsistemaPrincipal El SubsistemaPrincipal consiste principalmente de la clase ManejadorPrincipal. Podemos apreciar que en la Tabla 8.70 se defini un slo contrato, Manejar Evento, el cual tiene como cliente a la clase InterfaceUsuario. Dado que la clase InterfaceUsuario pertence al SubsistemaInterfaceUsuario, el contrato Manejar Evento debe definirse como externo al subsistema. La tarjeta para el SubsistemaPrincipal se muestra en la Tabla 8.93. Subsistema: SubsistemaPrincipal Descripcin: Este subsistema agrupa todos los objetos involucrados con el manejo general del sistema. Clases: ManejadorPrincipal Contratos Servidor ManejadorPrincipal (1) 1. Manejar Evento Tabla 8.93. Tarjeta de subsistema para SubsistemaPrincipal mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. El SubsistemaPrincipal se muestra grficamente en la Figura 8.28. No se incluye en el diagrama la clase PantallaPrincipal ya que sta no ofrece servicios externos.

ManejadorPrincipal 1. Manejar Evento SubsistemaPrincipal

Figura 8.28 Diagrama de subsistemas para el SubsistemaPrincipal. SubsistemaRegistro El SubsistemaRegistro consiste de todas las clases relacionadas con el registro con excepcin de las pantallas que fueron asignadas al subsistema SubsistemaInterfaceUsuario. Las clases incluidas son ManejadorRegistroUsuario, RegistroUsuario, ManejadorRegistroTarjeta, RegistroTarjeta y InterfaceBaseDatosRegistro. Se incluyeron las clases entidad junto con los manejadores y la clase de borde con la base de datos. En trmino de contratos, podemos observar que los dos contratos Manejar Evento pertenecientes a los dos manejadores, deben ser externos al subsistema ya que son llamados por la InterfaceUsuario. Adicionalmente, existe otro contrato que puede ser llamados externamente, Registrar Usuario (el contrato Registrar Tarjeta aunque no es llamado por clases pertenecientes a otros subsistemas para los casos de uso analizados hasta el momento, eventualmente deber ser agregado al subsistema como apoyo al caso de uso de Pagar Reservacin). Por otro lado las clases entidad, RegistroUsuario y RegistroTarjeta, an no definen contratos, mientras que la clase InterfaceBaseDatosRegistro contiene contratos nicamente para los manejadores internos de este subsistema. La tarjeta para el SubsistemaRegistro se muestra en la Tabla 8.94. Ntese que existen dos servidores para el primer contrato. Esto no es un error, ya que los servidores pueden estar activos en diferentes momentos durante la ejecucin del sistema.

Weitzenfeld: Captulo 8

82

Adicionalemente, pudiramos definir sub-subsistemas, o sea subsistemas a un nivel inferior en la jerarqua, sin embargo, consideramos que dado el nmero limitado de clases en este subsistema, esto no ser necesario. Subsistema: SubsistemaRegistro Descripcin: Este subsistema agrupa todos los objetos involucrados con el manejo de registro de usuario, incluyendo registro de tarjeta. Clases: ManejadorRegistroUsuario, RegistroUsuario, ManejadorRegistroTarjeta, RegistroTarjeta, InterfaceBaseDatosRegistro Contratos Servidor ManejadorRegistroUsuario (1), 1. Manejar Evento ManejadorRegistroTarjeta (1) ManejadorRegistroUsuario (2) 2. Registrar Usuario Tabla 8.94. Tarjeta de subsistema para SubsistemaRegistro mostrando sus contratos y servidores a partir de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. El SubsistemaRegistro se muestra grficamente en la Figura 8.29. Ntese nuevamente que el subsistema ofrece dos contratos externos ligados a los servidores internos correspondientes.
1. Manejar Evento ManejadorRegistroTarjeta

ManejadorRegistroUsuario 2. Registrar Usuario

SubsistemaRegistro

Figura 8.29 Diagrama de subsistemas para el SubsistemaRegistro. SubsistemaServicios El SubsistemaServicios consiste principalmente de la clase ManejadorServicio. Eventualemente, este subsistema incluir clases y subsistemas internos adicionales como parte de la funcionalidad apoyada para los dems casos de uso, algo que se muestra en los apndices. En la Tabla 8.95 se muestran los dos contratos definidos para este subsistema, Manejar Evento, similar a los dems subsistema que contienen manejadores, y Ofrecer Servicio, contrato que permite seleccionar la funcionalidad del sistema deseado. Ambos contratos son implementados por la clase ManejadorServicio. Subsistema: SubsistemaServicios Descripcin: Este subsistema agrupa los objetos generales para el manejo de los servicios de reservaciones. Clases: ManejadorServicio Contratos Servidor ManejadorServicio (1) 1. Manejar Evento ManejadorServicio (2) 2. Ofrecer Servicio Tabla 8.95. Tarjeta de subsistema para SubsistemaServicios mostrando sus contratos y servidores a partir del caso de uso RegistrarUsuario. El SubsistemaServicio se muestra grficamente en la Figura 8.30. Ambos contratos son ofrecidos por el ManjeadorServicio.

Weitzenfeld: Captulo 8

83

1. Manejar Evento

ManejadorServicios

SubsistemaServicios

2. Ofrecer Servicio

Figura 8.30 Diagrama de subsistemas para el SubsistemaServicios. Sistema Una de las ventajas de definir subsistemas es la posibilidad de visualizar el sistema completo a partir de estas. En la Figura 8.31 se integran los subsistemas anteriores mostrando los contratos entre subsistemas. Se pueden apreciar seis contratos los cuales son llamados por las clases manejadoras en los subsistemas de Registro, Servicios y Principal y la InterfaceUsuario en el subsistema correspondiente.

SubsistemaInterfaceUsuario

1. Desplegar Pantalla

1. Manejar Evento 1. Manejar Evento

SubsistemaServicios SubsistemaRegistro

2. Ofrecer Servicio 2. Registrar Usuario

1. Manejar Evento

SubsistemaPrincipal

Figura 8.31 Subsistemas del sistema de reservaciones de vuelo. 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 y no directamente con la clase. Por lo tanto, no modificaremos las tarjetas de clase con excepcin a aquellas donde las colaboraciones sean con clases en otros subsistemas. Mdulo InterfaceUsuario La clase InterfaceUsuario, tal como se describi en la Tabla 8.70, define dos responsabilidades desplegarPantalla y enviarEvento. Las colaboraciones a partir de desplegarPantalla son con pantallas las cuales residen dentro del SubsistemaInterfaceUsuario, por lo cual ningn cambio en la descripcin de las colaboraciones es necesario. La segunda responsabilidad, enviarEvento, requiere colaboraciones con los manejadores a travs de los contratos de

Weitzenfeld: Captulo 8

84

Manejar Evento, los cuales estn definidos a partir de la superclase Manejador y sobrescritos por los diversos manejadores. Aunque la clase InterfaceUsuario colabora con todos sin saber su verdadera identidad , estas clases residen en diversos subsistemas, por lo cual se debe modificar los nombres de clases y en su lugar poner los nombres de los subsistemas correspondientes a los cuales pertenecen las diversas clases manejadores. La tarjeta de clase modificada para la clase InterfaceUsuario se muestra en la Tabla 8.96. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla Pantalla (1) : PantallaPrincipal (1), PantallaServicio (1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1) 2. Enviar Evento enviarEvento Manejador (1) : SubsistemaPrincipal (1), SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.96. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase Pantalla, como se defini en la Tabla 8.67, y todas sus subclases correspondientes a las distintas pantallas no son modificadas ya que la colaboracin de la clase es con la clase InterfaceUsuario que pertenece al mismo subsistema. Mdulo Principal La clase ManejadorPrincipal debe modificarse ya que sus colaborador es la clase ManejadorRegistroUsuario como se puede apreciar en la Tabla 8.71. Por lo tanto, se actualizan los contratos para la clase ManejadorPrincipal, en este caso l contrato 2 del SubsistemaRegistro, como se muestra en la Tabla 8.97. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento Responsablidades Privadas crearRegUsuario SubsistemaRegistro (2) validarRegUsuario SubsistemaRegistro (2) Tabla 8.97. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase Manejador, como se mostr en la Tabla 8.66 llama a los contratos 1 de la InterfaceUsuario y el contrato 2 del ManejadorServicio. Por lo tanto se actualizan los contratos al contrato 1 del SubsistemaInterfaceUsuario y el contrato 2 del SubsistemaServicio para la clase Manejador, como se muestra en la Tabla 8.98. Clase: Manejador

Weitzenfeld: Captulo 8

85

Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclases: Subclases: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: Contratos 1. Manejar Evento manejarEvento Responsablidades Privadas desplegarPantalla SubsistemaInterfaceUsuario (1) ofrecerServicio SubsistemaServicio (2) salir Tabla 8.98. 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. Mdulo Dominio La descripcin de la clase Datos se mantiene igual. Mdulo Registro En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, no hay tampoco necesidad de modificar las clases. Mdulo Servicios La clase ManejadorServicio, como se muestra en la Tabla 8.88, hace llamadas al contrato 2 de la clase ManejadorRegistroUsuario el cual pertenece al SubsistemaRegistro. La colaboracin debe por lo tanto modificarse de manera correspondiente. Los cambios para la clase ManejadorServicio se muestran en la Tabla 8.99. Clase: ManejadorServicio Descripcin: 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. Mdulo: Servicios Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento 2. Ofrecer Servicio ofrecerServicio Responsablidades Privadas registrar SubsistemaRegistro (2) Tabla 8.99. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas, contratos y subsistemas a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. Protocolos Una vez completadas las etapas anteriores, se debe detallar la especificacin de cada clase hasta llegar a mtodos y atributos finales. Aunque pudiramos generar una especificacin completa a nivel de pseudo-cdigo o incluso cdigo en un lenguaje particular, esto sera sobrespecificar el diseo ya que el diseo debe definir los aspectos ms relevantes de la solucin pero sin ser el cdigo final. El diseo debe dar cierta libertad al programador o implementador siempre y cuando se mantenga dentro del marco de la arquitectura de objetos generada hasta el

Weitzenfeld: Captulo 8

86

momento. Entonces, hasta donde debe llegar el diseo?. Nuevamente, la respuesta est relacionada con aspectos en el manejo de la complejidad. Si el diseo desarrollado ya resuelve los aspectos ms importantes de la arquitectura, en particular todo lo relacionado con la asignacin de responsabilidades, entonces ya hemos resuelto gran parte del problema. Sin embargo, existen otros aspectos que son fuente de complejidad ms all de las responsabilidades, estos incluyen los aspectos algortmicos, estructuras de datos, entre otros junto con la adecuacin a los dems aspectos consideramos dentro del diseo de sistema como se mencion al inicio del captulo. Cuando ya no existen decisiones importantes que pudieran afectar de manera importante la arquitectura del sistema entonces ya se puede continuar con la implementacin. Nosotros continuaremos hasta donde se considera que la arquitectura del sistema de reservaciones ya resuelve los aspectos que ms afectan a toda la arquitectura. Esto incluye de manera importante la definicin precisa de las responsabilidades pblicas, ya que cualquier cambio en ellas afectar a todos los respectivos clientes. Para ello se define el concepto de protocolo, donde un protocolo corresponde al conjunto de firmas correspondientes a las distintas responsabilidades de una clase. El objetivo de los protocolos es refinar las responsabilidades hasta llegar a mtodos precisos dando especial nfasis a las responsabilidades agrupadas en los contratos ofrecidos por las clases. En general, las responsabilidades privadas representan notas de implementacin para 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. Se busca tambin incrementar la reutilizacin en el sistema si logramos que los protocolos contenga 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. Durante esta etapa es comn descubrir sitios en el diseo donde el modelo fue impreciso, incorrecto, o pobremente comprendido. 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. A continuacin se describen las clases principales incorporando protocolos en el Sistema de Reservaciones y en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. InterfaceUsuario La clase InterfaceUsuario define dos responsabilidades pblicas, correspondientes a dos contratos, como se especific anteriormente en la Tabla 8.96 y como se muestra en la Tabla 8.100. 1. Desplegar Pantalla desplegarPantalla Pantalla (1) : PantallaPrincipal (1), PantallaServicio (1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1) 2. Enviar Evento enviarEvento Manejador (1) : SubsistemaPrincipal (1), SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.100. Responsabilidades pblicas para la clase InterfaceUsuario especificada en la Tabla 8.93. El mtodo desplegarPantalla es llamado por los diversos manejadores como parte del contrato Desplegar Pantalla. Dado que esta responsabilidad es cliente del contrato 1, con el mismo nombre, de la clase Pantalla y es sobrecargada por las diversas pantallas, entonces es necesario definir como parte del protocolo un parmetro correspondiente a la pantalla a ser desplegada. Este parmetro de tipo Pantalla corresponde a un objeto ya instanciado por parte del manejador controlador de dicha Pantalla. Tenemos tambin que definir algn tipo de resultado, de manera sencilla podemos simplemente devolver un tipo nulo (void). Todo esto se muestra en la Tabla 8.101. Debe resaltarse que el parmetro corresponde a la superclase en lugar de incluir alguna pantalla particular, siendo esto esencial para lograr el polimorfismo. 1. Desplegar Pantalla desplegarPantalla(Pantalla) Pantalla (1) : PantallaPrincipal (1), PantallaServicio (1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1)

Weitzenfeld: Captulo 8

87

Tabla 8.101. Responsabilidad desplegarPantalla con protocolo para la clase InterfaceUsuario especificada en la Tabla 8.100. En el caso de la otra responsabilidad, enviarEvento, la situacin es la opuesta. En este caso las diversas pantallas solicitan a la InterfaceUsuario enviar los eventos generados por el Usuario. Posteriormente, la InterfaceUsuario llama al contrato 1, correspondiente a Manejar Evento, definido en la clase Manejador y sobrecargado por los diferentes manejadores. En principio, deberamos definir dos parmetros, el evento generado y otro correspondiente a la clase Manejador a quien se le enviar posteriormente el evento. El evento puede corresponder a una clase tipo Evento que deber corresponder a algn tipo definido posteriormente y de acuerdo al lenguaje de implementacin. El tipo de devolucin puede ser nuevamente un void. Esto se muestra en la Tabla 8.102. 2. Enviar Evento enviarEvento(Evento, Manejador) devuelve void Manejador (1) : SubsistemaPrincipal (1), SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.102. Responsabilidad enviarEvento con protocolo para la clase InterfaceUsuario especificada en la Tabla 8.99. La tarjeta de clase modificada para la clase InterfaceUsuario se muestra en la Tabla 8.103. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla(Pantalla) devuelve void Pantalla (1) : PantallaPrincipal (1), PantallaServicio (1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1) 2. Enviar Evento enviarEvento(Evento, Manejador) devuelve void Manejador (1) : SubsistemaPrincipal (1), SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.103. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En la Tabla 8.67 se definieron las responsabilidades, asignadas a contratos y privadas, para la clase Pantalla, como se muestra en la Tabla 8.104. 1. Desplegar Pantalla desplegarPantalla Responsabilidades Privadas enviarEvento InterfaceUsuario (2) Tabla 8.104. Tarjeta para la superclase clase Pantalla con responsabilidades asignadas a contratos y privadas. El contrato desplegarPantalla es llamado por la clase InterfaceUsuario solicitando a las diversas pantallas que sobrescriben la responsabilidad que se desplieguen. Dado que el contenido de la pantalla es conocida por las diversas pantallas, en principio, no es necesario agregar ningn parmetro. Adicionalmente, se puede devolver un tipo void. Esto se muestra en la Tabla 8.105. 1. Desplegar Pantalla desplegarPantalla() devuelve void Tabla 8.105. Tarjeta para la superclase clase Pantalla con protocolo para la responsabilidad desplegarPantalla. En el caso de la responsabilidad privada enviarEvento, sta es llamada localmente por lo cual se puede dejar el parmetro sin asignar y se puede devolver un tipo void. Esto se muestra en la Tabla 8.106.

Weitzenfeld: Captulo 8

88

Responsabilidades Privadas enviarEvento() devuelve void InterfaceUsuario (2) Tabla 8.106. Tarjeta para la superclase clase Pantalla con protocolo para la responsabilidad enviarEvento. La tarjeta de clase modificada para la clase Pantalla se muestra en la Tabla 8.107. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla() devuelve void Responsabilidades Privadas enviarEvento() devuelve void InterfaceUsuario (2) Tabla 8.107. Tarjeta para la superclase clase Pantalla con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Principal A partir de la Tabla 8.98 se muestran las diversas responsabilidades para la clase Manejador, como se muestra en la Tabla 8.108. 1. Manejar Evento manejarEvento Responsablidades Privadas desplegarPantalla SubsistemaInterfaceUsuario (1) ofrecerServicio SubsistemaServicio (2) salir Tabla 8.108. Tarjeta para la clase Manejador segn se describi en la Tabla 8.95. El contrato Manejar Evento es llamado por la clase InterfaceUsuario la cual debe enviar el evento generada por el usuario y enviada luego por las diversas pantallas. Por lo tanto debe incluirse un parmetro de tipo Evento y nuevamente podemos asignar un tipo void de devolucin. Las dems responsabilidades son privadas y podemos dejar de asignar parmetros y definir un tipo void de devolucin. Esto se muestra en la Tabla 8.109. Clase: Manejador Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclases: Subclases: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Responsablidades Privadas desplegarPantalla() devuelve void SubsistemaInterfaceUsuario (1) ofrecerServicio() devuelve void SubsistemaServicio (2) salir() devuelve void Tabla 8.109. 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.

Weitzenfeld: Captulo 8

89

A partir de la Tabla 8.97 podemos definir los protocolos para la clase ManejadorPrincipal a partir del contrato Manejar Evento y dos responsabilidades privadas. El contrato Manejar Evento contiene la responsabilidad manejarEvento la cual se debe definir de manera similar a la responsabilidad que es sobrescrita de la superclase Manjeador. Las dos responsabilidades privadas se pueden dejar sin parmetros y devolviendo un tipo void, como se muestra en la Tabla 8.110. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Responsablidades Privadas crearRegistroUsuario() devuelve void SubsistemaRegistro (2) validarRegistroUsuario() devuelve void SubsistemaRegistro (2) Tabla 8.110. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La descripcin de la clase PantallaPrincipal se mantiene igual ya que no incluye responsabilidades al igual que las dems pantallas. Dominio La descripcin de la clase Datos se mantiene igual, ya que no incluye hasta el momento responsabilidades. Registro En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, slo se modifican las clases de control pero no las de interface o entidad, como se ver a continuacin. Usuario En la Tabla 8.75 se definieron las diferentes responsabilidades para la clase ManejadoRegistroUsuario, como se muestra en la Tabla 8.111. Contratos 1. Manejar Evento manejarEvento 2. Registrar Usuario crearRegistroUsuario InterfaceBaseDatosRegistro (1) validarRegistroUsuario InterfaceBaseDatosRegistro (1) obtenerRegistroUsuario InterfaceBaseDatosRegistro (1) Responsabilidades Privadas actualizarRegistroUsuario InterfaceBaseDatosRegistro (1) eliminarRegistroUsuario InterfaceBaseDatosRegistro (1) registrarTarjeta ManejadorRegistroTarjeta (2) Tabla 8.111. Tarjeta para la clase ManejadoRegistroUsuario como se defini en la Tabla 8.75. En el caso del contrato Manejar Evento debemos definir un protocolo para la responsabilidad manejarEvento similar a la de la clase Manejador, como se hizo con el ManejadorPrincipal. En relacin al contrato Registrar Usuario tenemos tres responsabilidades, crearRegistroUsuario, validarRegistroUsuario y obtenerRegistroUsuario. Las dos primeras responsabilidades son llamadas por el ManejadorPrincipal para iniciar transacciones de registro. En el caso de crearRegistroUsuario, el ManejadorPrincipal solicita al ManejadoRegistroUsuario que cree un nuevo registro de usuario, algo que ser

Weitzenfeld: Captulo 8

90

controlado completamente por este ltimo. Dado que todo el control de la transaccin est a cargo del ManejadoRegistroUsuario, no hay necesidad de agregar ningn parmetro y se puede devolver un tipo void. En el caso de validarRegistroUsuario, el ManejadorPrincipal solicita al ManejadoRegistroUsuario que valide los datos del usuario los cuales son insertados en la PantallaPrincipal, la cual est a cargo del ManejadorPrincipal. El ManejadorPrincipal debe hacerle llegar los datos del usuario al ManejadoRegistroUsuario, algo que podemos incluir como dos parmetros de tipo String (cadenas de caracteres), correspondientes al nombre del usuario y su contrasea. Dado que el ManejadorPrincipal debe decidir en base al resultado si proceder con los servicios, tambin ser necesario devolver algn tipo de valor que nos comunique si la solicitud fue aceptada, por lo tanto agregaremos un tipo bolean como resultado. En el caso de la responsabilidad obtenerRegistroUsuario, el ManejadorServicio solicita al ManejadoRegistroUsuario que obtenga el registro de usuario y contine el procesamiento. En tal caso no se enva ningn parmetro y no es necesario esperar ninguna respuesta por lo cual la devolucin la podemos dejar de tipo void. En el caso de las responsabilidades privadas, las podemos dejar sin ningn parmetro y devolviendo tipos void. Todos estos protocolos con la tarjeta de clase completa se muestran en la Tabla 8.112. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Registrar Usuario crearRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) validarRegistroUsuario(String,String) devuelve boolean InterfaceBaseDatosRegistro (1) obtenerRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) Responsabilidades Privadas actualizarRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) eliminarRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) registrarTarjeta() devuelve void ManejadorRegistroTarjeta (2) Tabla 8.112. 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 clases PantallaRegUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario y RegistroUsuario se mantienen igual. Tarjeta En la Tabla 8.80 se definieron las diferentes responsabilidades para la clase ManejadoRegistroTarjeta, como se muestra en la Tabla 8.113. 1. Manejar Evento manejarEvento 2. Registrar Tarjeta registrarTarjeta Responsabilidades Privadas crearRegistroTarjeta InterfaceBaseDatosRegistro (2) obtenerRegistroTarjeta InterfaceBaseDatosRegistro (2) actualizarRegistroTarjeta InterfaceBaseDatosRegistro (2) eliminarRegistroTarjeta InterfaceBaseDatosRegistro (2) Tabla 8.113. Tarjeta para la clase ManejadoRegistroTarjeta como se defini en la Tabla 8.80.

Weitzenfeld: Captulo 8

91

En el caso del contrato Manejar Evento debemos definir un protocolo para la responsabilidad manejarEvento similar a la de la clase Manejador, como se hizo con el ManejadorPrincipal y tambin con el ManejadorRegistroUsuario. En relacin al contrato Registrar Tarjeta, la responsabilidad registrarTarjeta es llamada por el ManejadorRegistroUsuario. Dado que debe haber alguna manera de relacionar el registro de usuario con el registro de tarjeta, podemos enviar como parmetro algn identificador, por ejemplo de tipo String. El control del contrato contina en el ManejadoRegistroTarjeta por lo cual el tipo a devolver puede ser void. Las responsabilidades privadas nuevamente se definen sin argumentos y con devolucin de tipo void. Todos estos protocolos con la tarjeta de clase completa se muestran en la Tabla 8.114. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Registrar Tarjeta registrarTarjeta(String) devuelve void Responsabilidades Privadas crearRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) obtenerRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) actualizarRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) eliminarRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) Tabla 8.114. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas del caso de uso RegistrarTarjeta. La descripcin de las clases PantallaRegTarjeta, PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta se actualizan de manera similar a la PantallaPrincipal. Por otro lado, RegistroTarjeta se actualiza de manera similar a RegistroUsuario. Interface Base Datos Registro En la Tabla 8.87 se definieron las diferentes responsabilidades para la clase InterfaceBaseDatosRegistro, como se muestra en la Tabla 8.115. 1. Registrar Usuario crearRegistroUsuario BaseDatosRegistro obtenerRegistroUsuario BaseDatosRegistro actualizarRegistroUsuario BaseDatosRegistro eliminarRegistroUsuario BaseDatosRegistro validarRegistroUsuario BaseDatosRegistro 2. Registrar Tarjeta crearRegistroTarjeta BaseDatosRegistro obtenerRegistroTarjeta BaseDatosRegistro actualizarRegistroTarjeta BaseDatosRegistro eliminarRegistroTarjeta BaseDatosRegistro Tabla 8.115. Tarjeta para la clase InterfaceBaseDatosRegistro como se defini en la Tabla 8.87. Se definen dos contratos, Registrar Usuario y Registrar Tarjeta, los cuales son encargados de interactuar con al base de datos para el almacenamiento de los registros de usuario y registros de tarjeta, respectivamente. Todas las responsabilidades deben enviar parmetros correspondientes a los registros a ser guardados en la base de datos o incluso a ser devueltos, ya que podemos hacer esto ltimo a travs de los parmetros.

Weitzenfeld: Captulo 8

92

En el caso del contrato Registrar Usuario tendramos como parmetro a la clase RegistroUsuario para las diversas responsabilidades con excepcin de la validacin. En el caso de obtenerRegistroUsuario es necesario tambin enviar algn identificador que especifique el registro particular que buscamos. En el caso de validarRegistroUsuario, se tiene que enviar dos parmetros de tipo String correspondientes al nombre del usuario y su contrasea. En el caso del contrato Registrar Tarjeta se hara algo similar con las responsabilidades, con la excepcin que el parmetro sera de tipo RegistroTarjeta. En general podemos devolver un tipo void con excepcin de la validacin que debe devolver un boolean. Todos estos protocolos con la tarjeta de clase completa se muestran en la Tabla 8.116. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario crearRegistro(RegistroUsuario) devuelve void BaseDatosRegistro obtenerRegistro(RegistroUsuario) devuelve void BaseDatosRegistro actualizarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro eliminarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro validarRegistro(String, String) devuelve boolean BaseDatosRegistro 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro obtenerRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro actualizarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Tabla 8.116. 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. Servicios En la Tabla 8.99 se definieron las diferentes responsabilidades para la clase ManejadorServicio, como se muestra en la Tabla 8.117. 1. Manejar Evento manejarEvento 2. Ofrecer Servicio ofrecerServicio Responsablidades Privadas registrar SubsistemaRegistro (2) Tabla 8.117. Tarjeta para la clase ManejadorServicio como se defini en la Tabla 8.99. En el caso del contrato Manejar Evento debemos definir un protocolo para la responsabilidad manejarEvento similar a la de la clase Manejador, como se hizo con los dems manejadores. En relacin al contrato Ofrecer Servicio, la responsabilidad ofrecerServicio es llamada por el los dems manejadores, algo que inicia un servicio controlado totalmente por esta clase, por lo tanto no hay necesidad de incluir ningn parmetro e incluso se puede devolver un tipo void. La responsabilidad privada nuevamente se define sin argumentos y con devolucin de tipo void. Todos estos protocolos con la tarjeta de clase completa se muestran en la Tabla 8.118. Clase: ManejadorServicio Descripcin: La informacin de cada usuario se almacena en la base de datos de registro la cual se accesa

Weitzenfeld: Captulo 8

93

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. Mdulo: Servicios Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Ofrecer Servicio ofrecerServicio() devuelve void Responsablidades Privadas registrar() devuelve void SubsistemaRegistro (2) Tabla 8.118. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. La descripcin de la clase PantallaServicio se mantiene de manera similar a las dems pantallas. Atributos En 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. Es difcil decidir en que momento termina el diseo y comienza la implementacin. El objetivo general es lograr un diseo robusto que le de cierta flexibilidad al programador pero sin modificar de manera importante la arquitectura de diseo. Lo que haremos a continuacin, es detallar un poco ms nuestro diseo especificando atributos correspondientes a estructuras de datos y algoritmos que especifiquen la menara de implementar las diversas responsabilidades correspondientes a los mltiples contratos de la aplicacin. En general, los atributos corresponden a los aspectos estructurales de las clases, como son los valores (nmeros y textos), junto con las referencias a otros objetos. Estos conceptos vara de gran manera entre lenguajes. Por ejemplo, en el caso de Java y C++ la distincin entre valores y referencias es clara. En el caso de lenguajes como Smalltalk, no hay distincin alguna dado que todos los atributos corresponden a referencias entre objetos. Los atributos correspondientes a referencias deben agregarse de acuerdo a las colaboraciones establecidas durante el diseo. Los atributos que guardan valores son lo ltimo que se especifica en el diseo de objetos. A continuacin se describen los atributos esenciales para las clases del Sistema de Reservaciones y en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. InterfaceUsuario Como se pudo observar anteriormente, la clase InterfaceUsuario se relaciona primordialmente y a travs de polimorfismo con las diversas pantallas y manejadores. Dado que slo se desplegar una pantalla a la vez y se comunicar con un solo manejador en un momento especfico, es suficiente definir dos tipos de referencias, Manejador para poder comunicarse con los diversos manejadores y Pantalla para comunicarse con las diversas pantallas. Por lo tanto, modificamos la tarjeta de clase correspondiente a la InterfaceUsuario como se muestra en la Tabla 8.119. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Manejador, Pantalla Contratos 1. Desplegar Pantalla desplegarPantalla(Pantalla) devuelve void Pantalla (1) : PantallaPrincipal (1), PantallaServicio

Weitzenfeld: Captulo 8

94

(1), PantallaCrearRegUsuario (1), PantallaObtenerRegUsuario (1), PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1) Manejador (1) : SubsistemaPrincipal (1), SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.119. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. De manera similar a la InterfaceUsuario, las diversas pantallas deben tener conocimiento de la InterfaceUsuario y de los manejadores que las controlan. Aunque se pudiera especificar el tipo particular de manejador que administra una pantalla en particular, podemos aprovechar y definir una referencia de tipo genrica a Manejador ya que cada pantalla es administrada por un solo manejador. Este conocimiento se implementa mediante atributos correspondientes a las clases anteriores, como se muestra en la Tabla 8.120. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: InterfaceUsuario, Manejador Contratos 1. Desplegar Pantalla desplegarPantalla() devuelve void Responsabilidades Privadas enviarEvento() devuelve void InterfaceUsuario (2) Tabla 8.120. Tarjeta para la superclase Pantalla con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Principal De manera similar a la InterfaceUsuario y las pantallas, los manejadores deben poder accesar a la propia InterfaceUsuario y tambin a sus diferentes pantallas. Por tal motivo definimos dos atributos, uno de tipo InterfaceUsuario y otro de tipo Pantalla correspondiente a la pantalla actualmente siendo desplegada. Si revisamos un poco ms, podemos apreciar que la gran mayora de los menajadores requieren comuincarse con el SubsistemaServicio para ofrecer algn servicio. Por lo tanto, tambin se requiere un atributo de referencia de tipo ManejadorServicio el cual puede ser definido a este nivel en la superclase Manejador. Adicionalmente, vamos a agregar una referencia genrica para el manejador padre el cual reside a un nivel administrativo superior, en otras palabras, el manejador encargado de instanciar al siguiente nivel de manejadores y as sucesivamente. Dado que el manejador padre puede tener cualquier tipo dentro de la jerarqua de manejadores, lo agregaremos bajo el tipo genrico Manejador. Esta referencia es simpre buena tener, ya que un manejador particular puede tener acceso a cualquier otro manejador siempre y cuando no pierda la referencia a su superior. La clase Manejador se muestra en la Tabla 8.121. Clase: Manejador Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclases: Subclases: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: InterfaceUsuario, Pantalla, ManejadorServicio, Manejador Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Enviar Evento enviarEvento(Evento, Manejador) devuelve void

Weitzenfeld: Captulo 8

95

Responsablidades Privadas desplegarPantalla() devuelve void SubsistemaInterfaceUsuario (1) ofrecerServicio() devuelve void SubsistemaServicio (2) salir() devuelve void Tabla 8.121. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos identificados de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En el caso de la clase ManejadorPrincipal es necesario agegar una referencia particular a cada pantalla y manejador que pueda ser accesado desde este clase, tomando en cuenta los ya definidos a nivel de la superclase Manejador. Por lo tanto, defnimos un atributo de tipo PantallaPrincipal, un ManejadorServicio y otro ManejadorRegistroUsuario, como se muestra en la Tabla 8.122. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: PantallaPrincipal, ManejadorServicio, ManejadorRegistroUsuario Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Responsablidades Privadas crearRegistroUsuario() devuelve void SubsistemaRegistro (2) validarRegistroUsuario() devuelve void SubsistemaRegistro (2) Tabla 8.122. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase PantallaPrincipal no agrega atributos ms all de aquellos definidos en la superclase Pantalla por lo cual no volvemos a repetir la descripcin. Dominio La clase Datos es una superclase con estereotipo entidad. Tpicamente, estas clases se mantienen lo ms limitadas posible en trmino de sus relaciones con otras clases por lo cual no agregamos atributos hasta el momento. Registro En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, slo se modifican las clases de control pero no las de interface o entidad, como se ver a continuacin. Usuario En el caso de la clase ManejadoRegistroUsuario, definimos referencias a las diversas pantallas bajo control de esta clase, PantallaCrearRegUsuario y PantallaObtenerRegUsuario, a la clase entidad donde se guardar la informacin manipulada por esta clase, RegistroUsuario, al ManejadorRegistrTarjeta el cual es instanciado por el ManejadorRegistroUsuario y a la clase InterfaceBaseDatosRegistro correspondiente a la clase borde que accesar la base de datos de registro. El resto de los atributos son heredados de la clase Manejador. La tarjeta de clase para ManejadorRegistroUsuario se muestra en la Tabla 8.123. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Concreta Superclase: Manejador Subclases:

Weitzenfeld: Captulo 8

96

Atributos: PantallaCrearRegUsuario, PantallaObtenerRegUsuario, RegistroUsuario, ManejadorRegistrTarjeta, InterfaceBaseDatosRegistro Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Registrar Usuario crearRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) validarRegistroUsuario(String,String) devuelve boolean InterfaceBaseDatosRegistro (1) obtenerRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) Responsabilidades Privadas actualizarRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) eliminarRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) registrarTarjeta() devuelve void ManejadorRegistroTarjeta (2) Tabla 8.123. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos identificados de los casos de uso RegistrarUsuario y ValidarUsuario. La descripcin de las clases PantallaRegUsuario, PantallaCrearRegUsuario y PantallaObtenerRegUsuario se mantienen igual. La clase RegistroUsuario incluye los atributos asignados durante la identificacin del dominio del problema y descrita en los casos de uso, como se muestra en la Tabla 8.124. Clase: RegistroUsuario Descripcin: 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. Mdulo: Registro.Usuario Estereotipo: Entidad Propiedades: Concreta Superclases: Datos Subclases: Atributos: login, password, nombre, apellido, direccin, colonia, ciudad, pas, CP, telCasa, telOficina, fax, email

Tabla 8.124. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos para el caso de uso RegistrarUsuario. Tarjeta Los atributos para la clase ManejadoRegistroTarjeta sern considerados de manera similar al ManejadorRegistroUsuario. Incluiremos referencias a sus dos pantallas, PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta, al RegistroTarjeta donde se guardar la informacin manipulada por el manejador, y a la InterfaceBaseDatosRegistro encargada de aaccesar a la base de datos. La tarjeta con atributos se muestra en la Tabla 8.125. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta, RegistroTarjeta, InterfaceBaseDatosRegistro Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Registrar Tarjeta

Weitzenfeld: Captulo 8

97

registrarTarjeta(String) devuelve void Responsabilidades Privadas crearRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) obtenerRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) actualizarRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) eliminarRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) Tabla 8.125. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos identificados del caso de uso RegistrarTarjeta. La descripcin de las clases PantallaRegTarjeta, PantallaCrearRegTarjeta y PantallaObtenerRegTarjeta son similares a las anteriores. La clase RegistroTarjeta incluye atributos tambin identificados durante la especificacin del dominio del problema y descritos nuevamente en los casos de uso. Estos atributos se mueatran en la Tabla 8.126. Clase: RegistroTarjeta Descripcin: 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. Mdulo: Registro.Tarjeta Estereotipo: Entidad Propiedades: Concreta Superclases: Datos Subclases: Atributos: login, nombre, nmero, tipo, fecha

Tabla 8.126. Tarjeta para la clase RegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos para el caso de uso RegistrarTarjeta. Interface Base Datos Registro La clase InterfaceBaseDatosRegistro no requiere atributos por el momento. Servicios La clase ManejadorServicio requiere nicamente una referencia a la clase ManejadorRegistroUsuario para poder referirle solicitudes relacionadas con registro, como se muestra en la Tabla 8.127. Clase: ManejadorServicio Descripcin: 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. Mdulo: Servicios Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void 2. Ofrecer Servicio ofrecerServicio() devuelve void Responsablidades Privadas registrar() devuelve void SubsistemaRegistro (2) Tabla 8.127. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas, contratos, protocolos y atributos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. La descripcin de la clase PantallaServicio se mantiene igual, como se hizo con las dems pantallas.

Weitzenfeld: Captulo 8

98

Algoritmos Los algoritmos definen la lgica utilizada por cada operacin para resolver la responsabilidad a la cual corresponden. En general, muchas responsabilidades son suficientemente simples que no requieren de algoritmos, como son las responsabilidades de delegar entre los objetos para consultar o modificar los valores de los atributos. Este es mayormente el caso en nuestro ejemplo del sistema de reservaciones vuelos. Sin embargo, es especialmente importante especificar los algoritmos para implementar funciones de lgica ms compleja, como ordenar un conjunto de nmeros o cadenas, o hacer clculos de intereses sobre cuentas bancarias. Los algoritmos pueden especificarse de manera declarativa o procedural dependiendo de su complejidad. Cuando se especifica el aloritmo de manera procedural, esto tpicamente se hace mediante un diagrama de flujo. Por el contrario, un algoritmo especificado de manera declarativa, tpicamente se hace mediante una especificacin textual en cuyo 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 un sistema. A continuacin especificamos nuestros algoritmos de manera declarativa, principalmente coo un comentario sencillo. InterfaceUsuario La clase InterfaceUsuario se muestra en la Tabla 8.128. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Manejador, Pantalla Contratos 1. Desplegar Pantalla Pantalla (1) : PantallaPrincipal (1), PantallaServicio desplegarPantalla(Pantalla) devuelve void (1), PantallaCrearRegUsuario (1), Mtodo encargado de desplegar las pantallas enviadas PantallaObtenerRegUsuario (1), como parmetros. Se delega el despliegue PantallaCrearRegTarjeta (1), particular a cada pantalla. PantallaObtenerRegTarjeta (1) 2. Enviar Evento Manejador (1) : SubsistemaPrincipal (1), enviarEvento(Evento, Manejador) devuelve void SubsistemaServicio (1), SubsistemaRegistro (1) Mtodo encargado de recibir eventos del sistema de ventanas a travs de las diversas pantallas. Se enva el evento recibido a los distintos manejadores. Tabla 8.128. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase Pantalla se muestra en la Tabla 8.129. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: InterfaceUsuario, Manejador Contratos 1. Desplegar Pantalla desplegarPantalla() devuelve void Mtodo encargado de desplegar la pantalla actual. Responsabilidades Privadas

Weitzenfeld: Captulo 8

99

enviarEvento() devuelve void InterfaceUsuario (2) Mtodo encargado de recibir eventos del sistema de ventanas. Se enva el evento recibido a la InterfaceUsuario. Tabla 8.129. Tarjeta para la superclase Pantalla con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Principal La clase Manejador se muestra en la Tabla 8.130. Clase: Manejador Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclases: Subclases: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: InterfaceUsuario, Pantalla, ManejadorServicio, Manejador Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. Responsablidades Privadas SubsistemaInterfaceUsuario (1) desplegarPantalla() devuelve void Mtodo encargado de desplegar las pantallas administradas por los manejadores. Se solicita al SubsistemaInterfaceUsuario que las despliegue. SubsistemaServicio (2) ofrecerServicio() devuelve void Mtodo encargado de solicitar al SubsistemaServicio que ofrezca los servicios correspondientes. salir() devuelve void Mtodo encargado de salir del sistema. Tabla 8.130. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase ManejadorPrincipal se muestra en la Tabla 8.131. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. Responsablidades Privadas crearRegistroUsuario() devuelve void SubsistemaRegistro (2)

Weitzenfeld: Captulo 8

100

Mtodo encargado de solicitar al SubsistemaRegistro que de servicio al contrato de Registrar Usuario. validarRegistroUsuario() devuelve void SubsistemaRegistro (2) Mtodo encargado de solicitar al SubsistemaServicio que de servicio al contrato de Ofrecer Servicio. Tabla 8.131. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La descripcin de la clase PantallaPrincipal se mantiene igual ya que no incluye responsabilidades al igual que las dems pantallas. Dominio La descripcin de la clase Datos se mantiene igual, ya que no incluye hasta el momento responsabilidades. Registro En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, slo se agregan especificaciones algortmicas a las clases de control pero no las de interface o entidad, como se ver a continuacin. Usuario La clase ManejadoRegistroUsuario se muestra en la Tabla 8.132. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: PantallaCrearRegUsuario, PantallaObtenerRegUsuario, RegistroUsuario, ManejadorRegistrTarjeta, InterfaceBaseDatosRegistro Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. 2. Registrar Usuario InterfaceBaseDatosRegistro (1) crearRegistroUsuario() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la creacin de un nuevo RegistroUsuario a travs del contrato de Registrar Usuario validarRegistroUsuario(String,String) devuelve Boolean InterfaceBaseDatosRegistro (1) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la validacin de un usuario a travs del contrato de Registrar Usuario obtenerRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la obtencin de un RegistroUsuario a travs del contrato de Registrar Usuario Responsabilidades Privadas actualizarRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la actualizacin de un RegistroUsuario a travs del contrato de Registrar Usuario eliminarRegistroUsuario() devuelve void InterfaceBaseDatosRegistro (1) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la eliminacin de un RegistroUsuario a travs del contrato de Registrar Usuario registrarTarjeta() devuelve void ManejadorRegistroTarjeta (2)

Weitzenfeld: Captulo 8

101

Mtodo encargado de solicitar a la ManejadorRegistroTarjeta que procese el contrato Registrar Tarjeta Tabla 8.132. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados de los casos de uso RegistrarUsuario y ValidarUsuario. La descripcin de las clases PantallaRegUsuario, PantallaCrearRegUsuario, PantallaObtenerRegUsuario y RegistroUsuario se mantienen igual. Tarjeta La clase ManejadoRegistroTarjeta se muestra en la Tabla 8.133. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Concreta Superclases: Manejador Subclases: Atributos: PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta, RegistroTarjeta, InterfaceRegistro Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. 2. Registrar Tarjeta registrarTarjeta(String) devuelve void Mtodo encargado de crear u obtener un RegistroTarjeta Responsabilidades Privadas InterfaceBaseDatosRegistro (2) crearRegistroTarjeta() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la creacin de un nuevo RegistroTarjeta a travs del contrato de Registrar Tarjeta InterfaceBaseDatosRegistro (2) obtenerRegistroTarjeta() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la obtencin de un RegistroTarjeta a travs del contrato de Registrar Tarjeta actualizarRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la actualizacin de un RegistroTarjeta a travs del contrato de Registrar Tarjeta eliminarRegistroTarjeta() devuelve void InterfaceBaseDatosRegistro (2) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la eliminacin de un RegistroTarjeta a travs del contrato de Registrar Tarjeta Tabla 8.133. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados del caso de uso RegistrarTarjeta. La descripcin de las clases PantallaRegTarjeta, PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta y RegistroTarjeta se mantienen igual.

Weitzenfeld: Captulo 8

102

Interface Base Datos Registro La clase InterfaceBaseDatosRegistro se muestra en la Tabla 8.134. Clase: InterfaceBaseDatosRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario crearRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario BaseDatosRegistro obtenerRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario BaseDatosRegistro actualizarRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario BaseDatosRegistro eliminarRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario BaseDatosRegistro validarRegistro(String, String) devuelve bolean Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta BaseDatosRegistro crearRegistro(RegistroTarjeta) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta BaseDatosRegistro obtenerRegistro(RegistroTarjeta) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta BaseDatosRegistro actualizarRegistro(RegistroTarjeta) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 8.134. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Servicios La clase ManejadorServicio se muestra en la Tabla 8.135. Clase: ManejadorServicio Descripcin: 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. Mdulo: Servicios Estereotipo: Control

Weitzenfeld: Captulo 8

103

Propiedades: Concreta Superclases: Manejador Subclases: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. 2. Ofrecer Servicio ofrecerServicio() devuelve void Mtodo encargado de hacer solicitudes de consultar, reservar y administracin de registros Responsablidades Privadas registrar() devuelve void SubsistemaRegistro (2) Mtodo encargado de hacer la solicitud de administracin de registros al SubsistemaRegistro Tabla 8.135. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y especificacin de algoritmos identificados a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. La descripcin de la clase PantallaServicio se mantiene de manera similar a las dems pantallas. 8.3 Diseo de Sistema Hasta aqu, durante el diseo de objetos, hemos desarrollado un diseo detalaldo en base a la arquitectura de anlisis especificada anteriormente. Estos aspectos del diseo fueron especificados de manera independiente al ambiente de implementacin. Aunque no entraremos en detalles de implementacin en este captulo, es importante ya considerar dicho ambiente ya que este afectar la implementacin final. En general, el diseo de sistema incluye diversos aspectos como: ? ? Seleccin del lenguaje de programacin a utilizarse, tpicamente estructurados u orientados a objetos; ? ? Incorporacin de bibliotecas, como por ejemplo, interfaces grficas (GUI), bibliotecas numricas y de estructuras de datos; ? ? Incorporacin de una base de datos, tpicamente relacionales, relacionales extendidos u orientados a objetos; ? ? Incorporacin de archivos, en sus diferentes formatos; ? ? Consideraciones de procesamiento, como concurrencia, paralelismo, distribucin y tiempo real; Estos aspectos pueden variar radicalmente entre uno y otro sistema y tambin pueden afectar de manera importante la arquitectura final del sistema. En general existen diversos enfoques para la incorporacin del ambiente de implementacin a la arquitectura del sistema: (i) agregando clases abstractas o interfaces que luego sern especializadas segn el ambiente de implementacin particular; (ii) instanciando objetos especializados que administren los aspectos particulares del ambiente de implementacin particular; y (iii) 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. 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 sencillas escritas en Java. Tambin mostraremos cmo integrar el sistema con bases de datos y archivos externos. Lenguajes de Programacin Aunque no es obligatorio implementar un desarrollo orientado a objetos mediante lenguajes de programacin orientada a objetos, es obviamente ms natural hacerlo de tal modo. En el caso de los lenguajes orientados a objetos, existe un apoyo directo a los conceptos y mecanismos fundamentales del anlisis orientado a objetos: encapsulamiento, clasificacin, generalizacin y polimorfismo. Sin embargo, se puede generalmente traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con otros tipos de lenguajes no es su poder de computacin, si no en su expresibilidad, conveniencia, proteccin contra errores, y mantenimiento. Un lenguaje orientado a objetos hace que la escritura, mantenimiento, y

Weitzenfeld: Captulo 8

104

extensin de los programas sea ms fcil y segura, ya que ejecuta tareas que un programador de un lenguaje no orientado a objetos tendra que hacer manualmente. Aunque esta decisin se ha simiplificado hoy en da gracias a lenguajes como Java, no todos los lenguajes de programacin orientados a objetos implementan de la misma forma los diferentes conceptos de la orientacin a objetos. Existen aspectos, como el manejo del encapsulamiento, referencias, herencia mltiple, y otros aspectos que varan de manera importante entre lenguajes. Como parte de la implementacin de las clases en Java definiremos los siguientes aspectos: ? ? Encapsulamiento o visibilidad de los mtodos tanto como los atributos mediante modificadores de tipo public en el caso de contratos y responsabilidades pblicas, private en el caso de responsabilidades y atributos privados, y protected en el caso de responsabilidades y atributos privados definidos a nivel de una superclase y que sean necesarios de acceder a nivel de sus subclase. ? ? Protocolos correspondientes a tipos primitivos existentes en Java, como int, float, boolean, y objetos con tipos predefinidos en Java, como String, Vector. De manera general, la implementacin se basar en definiciones y manejos estndares de Java. Interfaces Grficas Las interfaces grficas tienen como objetivo esencial administrar la interaccin con el usuario mediante elementos grficos, como lo son los botones, mens y textos. En general, aplicaciones interactivas donde el control del ratn y el teclado juegan un papel primordial de control, son conocidos como sistemas controlados o dirigidos por eventos. Estos eventos corresponden al movimiento del ratn, como oprimir o soltar uno de sus botones, oprimir una tecla, junto con eventos que no son directamente iniciados por el usuario, como los eventos de desplegar una pantalla o interrumpir un programa. 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 o Swing, para luego utilizar el manejo apropiado a travs de clases como Frame, Canvas, Panel, Button, Event, etc. Ms all de los elementos o clase particuales de estas bibliotecas, tambin se 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. Para evitar mayor complejidad, nos limitaremos a ventanas relativamente sencillas, tanto a nivel de diseo grfico como del tipo de elementos internos que incorporaremos. El diseo se basar en el prototipo grfico descrito anteriormente en el Captulo 5, donde creamos un solo marco de ventana (frame) el cual muestra las diferentes pantallas en diferentes momentos, todas dentro del mismo marco. Dada esta decisin, que obviamente no es la nica alternativa, tendremos bsicamente una clase controladora nica de la ventana, la clase InterfaceUsuario anteriormente definida. Si hubieran mltiples ventanas independientes (en el desktop) entonces deberamos definir a cada marco como una clase controladora, correspondiente a cada pantalla, para luego tener una clase controladora para los mltiples marcos. Dada nuestra decisin, las pantallas se vuelven elementos internos de la ventana nica y bajo el control de la InterfaceUsuario. Cmo afecta esto a diseo de objetos? Se afecta de la siguiente manera. En lugar de que cada pantalla reciba un evento por parte del usuario (administrado a travs el sistema de ventanas del sistema operativo), podemos hacer que todos los eventos sean recibidos directamente por la InterfaceUsuario, volviendo a las pantallas ms pasivas, con menor conocimiento de su entorno y ms sencillas de manipular. En otras palabras convertimos las pantallas en elementos exclusivamente visuales quitndole todo el conocimiento necesario para manipular eventos generados externamente. Esto directamente afecta las responsabilidades de la clase InterfaceUsuario y de las las pantallas. Los cambios principales sern en relacin al cliente del contrato 2 el cual ser el manejador de ventanas del sistema en lugar de las distintas pantallas. Esto significa que el protocolo de la responsabilidad enviarEvento correspondiente al contrato 2 de la clase InterfaceUsuario deber modificarse, tomado de su estado anterior definido en la Tabla 8.103 y mostrado nuevamente en la Tabla 8.136. 2. Enviar Evento enviarEvento(Evento, Manejador) devuelve void Manejador (1) : SubsistemaPrincipal (1), SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.136. Contrato enviarEvento para la clase InterfaceUsuario definido en la Tabla 8.103. Dado que la llamada al contrato 2 es externa a nuestro sistema, no habr conocimiento sobre el manejador que controla la pantalla actual. Por lo tanto omitiremos el parmetro Manejador en el protocolo, como se muestra en la Tabla 8.137. 2. Enviar Evento enviarEvento(Evento) devuelve void Manejador (1) : SubsistemaPrincipal (1),

Weitzenfeld: Captulo 8

105

SubsistemaServicio (1), SubsistemaRegistro (1) Tabla 8.137. Contrato enviarEvento con protocolo revisado para la clase InterfaceUsuario definido en la Tabla 8.103. La clase InterfaceUsuario modificada se muestra en la Tabla 8.138. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Manejador manejador, Pantalla pantalla Contratos 1. Desplegar Pantalla Pantalla (1) : PantallaPrincipal (1), PantallaServicio desplegarPantalla(Pantalla) devuelve void (1), PantallaCrearRegUsuario (1), Mtodo encargado de desplegar las pantallas enviadas PantallaObtenerRegUsuario (1), como parmetros. Se delega el despliegue PantallaCrearRegTarjeta (1), particular a cada pantalla. PantallaObtenerRegTarjeta (1) 2. Enviar Evento Manejador (1) : SubsistemaPrincipal (1), enviarEvento(Evento) devuelve void SubsistemaServicio (1), SubsistemaRegistro (1) Mtodo encargado de recibir eventos del sistema de ventanas a travs de las diversas pantallas. Se enva el evento recibido a los distintos manejadores. Tabla 8.138. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y algoritmos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase Pantalla inclua una responsabilidad privada enviarEvento, la cual colaboraba con el contrato 2, con el mismo nombre, perteneciente a la clase InterfaceUsuario. Dado nuestras ltimas modificaciones en el diseo grfico, esta responsabilidad privada ya no ser necesaria y la clase InterfaceUsuario recibir directamente la llamada al contrato 2 por parte del manejador de ventanas de la mquina. (De por si, la responsabilidad privada enviarEvento definida en la clase Pantalla, tendra que ser pblica para que el manejador de ventanas pueda enviar los eventos.) En resumen, se eliminar la responsabilidad enviarEvento en la clase Pantalla, como se muestra en la Tabla 8.139. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: Contratos 1. Desplegar Pantalla desplegarPantalla() devuelve void Mtodo encargado de desplegar la pantalla actual. Tabla 8.139. Tarjeta para la superclase clase Pantalla modificada de acuerdo al diseo grfico. Se elimin la responsabilidad privada enviarEvento. Bases de Datos Las bases de datos siempre juegan un papel fundamental en los sistemas de informacin. Una decisin estratgica importante en tal contexto es si utilizar bases de datos relacionales u orientadas a objetos. Dado su amplia

Weitzenfeld: Captulo 8

106

utilizacin, seleccionaremos para nuestro desarrollo una base de datos relacional, utilizando el lenguaje SQL para su interaccin. En general, se consideran tres los modelos de bases de datos principales: ? ? Modelo Relacional definiendo una coleccin de tablas donde cada tabla tiene un nmero especfico de columnas y un nmero arbitrario de filas. Cada elemento de la tabla guarda un valor de tipo primitivo, como enteros o cadenas. De tal manera, cada objeto se representa como una fila en una tabla y donde cada columna corresponde a un atributo distinto en el objeto. El lenguaje de consultas se basa en operaciones simples, donde la simplicidad del modelo es un beneficio pero tambin es una limitacin. ? ? Modelo Relacional Extendido extendiendo el modelo relacional mediante procedimientos, objetos, versiones, y otras nuevas capabilidades. No hay un solo modelo relacional extendido, hay ms bien una variedad de ellos, aunque todos comparten las tablas y consultas bsicas del modelo relacional. Todos incorporan algo de "objetos" y todos tienen la habilidad de guardar procedimientos al igual que datos en la base de datos. ? ? Modelo Orientado a Objetos definiendo un modelo orientado a objetos donde vara el tipo de encapsulamiento de los datos y los procedimientos en el objeto. El termino "orientado a objetos" vara tambin segn los autores. En el caso del modelo orientado a objetos, los objetos pasan a tener persistencia ms all de su existencia durante la ejecucin del programa. En general, el diseo de bases de datos es un aspecto crucial en los sistemas de informacin. Las base de datos son repositorios de datos guardados en uno o ms archivos. Existen sistemas de manejo de bases de datos (DBMS, OODBMS en el caso de objetos) para la administrancin de los repositorios de datos permanentes, lo cual da un apoyo importante en los siguientes aspectos: ? ? recuperacin de cada: proteccin ante fallas de hardware y errores de usuarios. ? ? mltiples usuarios: acceso concurrente para diversos usuarios. ? ? mltiples aplicaciones: acceso concurrente de lectura y escritura de datos, facilitando la comunicacin entre las diferentes aplicaciones. ? ? seguridad: proteccin contra acceso no autorizados de lectura o escritura. ? ? integridad: reglas que deben ser satisfechas para controlar la calidad de los datos ms all del control particular de la aplicacin. ? ? extensibilidad: mecanismos que permitan extender la arquitectura de la base de datos sin interrumpir su ejecucin. ? ? distribucin de datos: distribucin de los datos en diferentes lugares, organizaciones y plataformas de hardware. Durante el diseo de la base de datos se debe traducir el modelo del dominio del problema a un modelos de tablas. Existen diversos enfoques de diseo, incluyendo aspectos relacionados con las correspondencia de asociaciones y generalizacin a tablas. Cada tabla derivada de una clase debe incluir un identificador para la llave primaria, y uno o ms identificadores para la llave primaria de la tabla derivada de las asociaciones. La estrategia es compatible con la orientacin a objetos, donde los objetos tienen una identidad aparte de sus propiedades. Existen beneficios en el uso de identificadors, ya que stos son inmutables y completamente independientes a cambios en los valores de los datos y su lugar fsico. Aunque cada clase puede corresponder a una o ms tablas, por lo general se disean tablas correspondientes a un objeto completo. Simplificaremos la tarea de diseo, creando una tabla correspondiente a cada clase entidad del dominio del problema y manteniendo las asociaciones entre clases. Obviamente, el diseo de tablas puede optimizarse para un acceso ms eficiente, algo que no trataremos aqu. Dado que nuestra descripcin se ha concentrado hasta el momento a lo referente a registro de usuario y tarjeta, nos limitaremos a mostrar el diseo de dichas tablas. Por ejemplo, en la Tabla 8.140, se muestra el diseo de la tabla para el RegistroUsuario, donde login es definida como la llave primaria de la tabla. La primera fila representa los nombres de los campos, mientras que la segunda muestra un ejemplo de datos.
login alfredo password awr nombre apellido Alfredo Weitzenfeld direccin Ro Hondo ciudad pas CP Mxico Mxico 01000 DF telCasa 1234 telOf fax email 5678 9012 alfredo@ itam.mx

Tabla 8.140. Diseo de la base de datos para la tabla correspondiente a la clase RegistroUsuario. En la Tabla 8.141, se muestra el diseo de la tabla para el RegistroTarjeta, donde se incluye login como referencia a la llave primaria de la tabla de RegistroUsuario.
login alfredo nombre Alfredo Weitzenfeld nmero 1234-5678-9012 tipo Visa fecha 120205

Tabla 8.141. Diseo de la base de datos para la tabla correspondiente a la clase RegistroTarjeta. En la Figura 8.32 se muestra de manera esquemtica la relacin entre las tablas RegistroUsuario y RegistroTarjeta.

Weitzenfeld: Captulo 8

107

Figura 8.32. Diagrama mostrando la relacin esquemtica entre las tablas RegistroUsuario y RegistroTarjeta. Archivos Aunque es siempre mas efectivo trabajar con bases de datos, siempre es posible utilizar archivos, en particular cuando la especificacin del sistema as lo requiera. De tal forma, aprovecharemos para extender el manejo de base de datos y mostrar como se puede lograr un objetivo similar a travs de archivos. Este ejemplo tambin servir para mostrar el poder de la extensibilidad definiendo una jerarqua de herencia a nivel de las clases borde para accesar tanto bases de datos como archivos de manera casi transparente. Para ello crearemos una nueva superclase InterfaceRegistro, de la cual heredar la clase InterfaceBaseDatosRegistro y nuestra nueva clase InterfaceArchivoRegistro. La superclase la definiremos como abstracta y deber tener contratos y responsabilidades pblicas similares a las ya definidas en la clase InterfaceBaseDatosRegistro. Esta clase se muestra en la Tabla 8.142. Clase: InterfaceRegistro Descripcin: Superclase para las interfaces a base de datos de registro y archivos. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Abstracta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario BaseDatosRegistro crearRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario obtenerRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario actualizarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario eliminarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario validarRegistro(String, String) devuelve bolean BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta

Weitzenfeld: Captulo 8

108

obtenerRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta actualizarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 8.142. Tarjeta para la clase InterfaceRegistro con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En el caso de la base de datos, la clase InterfaceBaseDatosRegistro se comunica con el DBMS (manejador del sistema de la base de datos) para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe y ser necesario hacerlo de manera manual. Por tal motivo, de manera adicional a la clase InterfaceArchivoRegistro, crearemos otra nueva clase ArchivoRegistro la cual se encargar de adminsitrar los diferentes archivos, instanciando una por archivo manipulado. De tal manera modificaremos las colaboraciones en la InterfaceArchivoRegistro para hacerlas con la clase ArchivoRegistro en lugar de BaseDatosRegistro, como se muestra en la Tabla 8.143. Ntese que todos los contratos deben ser identicos a los de la superclase InterfaceRegistro al igual que InterfaceBaseDatosRegistro para poder lograr la sobrescritura y aprovechar el polimorfismo. Clase: InterfaceArchivoRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario ArchivoRegistro crearRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario ArchivoRegistro obtenerRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario actualizarRegistro(RegistroUsuario) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario eliminarRegistro(RegistroUsuario) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario validarRegistro(String, String) devuelve bolean ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta obtenerRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta

Weitzenfeld: Captulo 8

109

actualizarRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 8.143. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase ArchivoRegistro de se muestra en la Tabla 8.144. Clase: ArchivoRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario BaseDatosRegistro crearRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario BaseDatosRegistro obtenerRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario BaseDatosRegistro actualizarRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario BaseDatosRegistro eliminarRegistro(RegistroUsuario) devuelve void Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario BaseDatosRegistro validarRegistro(String, String) devuelve bolean Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta obtenerRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta actualizarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 8.144. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.

Weitzenfeld: Captulo 8

110

A continuacin mostramos un ejemplo de cmo se vera un archivo correspondiente al RegistroUsuario. La primera lnea especifica el nmero de registros guardado en el archivo, en este caso 2. Los diversos valores de cada registro pueden guardarse como texto, en este caso delimitado mediante una lena vertical |.
2 alfredo|awr |Alfredo|Weitzenfeld|Rio Hondo #1|San Tizapan|Mexico|MEXICO|01000|6284000|6284000 x3614|6162211|alfredo@itam.mx| reservas|awr |Sistema|Reservaciones|Rio Hondo #1|San Tizapan|Mexico|MEXICO|01000|6284000|6284000 x3614|6162211|alfredo@itam.mx| Angel Angel

De manera similar, el archivo correspondiente al RegistroTarjeta se muestra a continuacin,

2 alfredo|Alfredo Weitzenfeld|123456789|MasterCard|01/05| reservas|Alfredo Weitzenfeld|987654321|Visa|02/4|

Ntese que la asociacin entre ambos archivos es mediante el campo de login, el primer campo en ambos archivos. 8.4 Revisin Final del Diseo Como parte de la revisin final, decidimos hacer ciertas optimizaciones menores en el diseo. Una de estas optimizaciones es a nivel de acceso a la base de datos de registro. En lugar de hacer primero una validacin de usuario y luego obtener el registro de la base de datos, podemos incroporar ambas responsabildiades en una sola. Por lo tanto, al momento de validar un registro, obtenemos los datos completos registrados para el usuario de manera inmediata. 8.5 Diagramas de Secuencias del Diseo Una vez completado tanto el diseo de objetos como el del sistema, es posible describir los casos de uso del anlisis en base a los protocolos de clases anteriormente definidos. Esto es muy importante ya que permita revisar que el diseo est lgicamente completo. Para ello se describen los casos de uso mediante diagramas de secuencia, los cuales se pueden referir directamente a las 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. Normalmente, los eventos en el diagrama corresponden a los protocolos antriromente diseados y se especifican exactamente como se veran en el cdigo final. A continuacin se muestran los diagramas de secuencia para el sistema de reservaciones de vuelo para los casos de uso Registrar Usuario y 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 Usuario El diagrama de secuencia para el caso de uso Registrar Usuario, subflujo Registrarse por Primera Vez se muestra en la Figura 8.33.

Weitzenfeld: Captulo 8

111

: Usuario

: Interfac eUsuario

: ManejadorRegistroUsuario 1: desplegarPantalla(PantallaPrincipal)

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: Base de Datos Registros

2: "Registrar Por Primera Vez" 3: manejarEvento("Registrar Por Primera Vez") 4: crearRegis troUsuario() 5: despl egarPantalla(PantallaCrearRegUsuario) 6: "Registrar" 7: manejarEvento("Registrar") 8: c rearRegistro(Regist roUsuari o) 9: executeUpdate(SQL) 10: OK 12: desplegarPantalla(PantallaObtenerRegUsuario) 11: OK

13: "Salir"

Figura 8.33. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Registrarse por Primera Vez. Registrar Usuario: Actualizar Registro Usuario El diagrama de secuencia para el caso de uso Registrar Usuario, subflujo Actualizar Registro Usuario se muestra en la Figura 8.34.

Weitzenfeld: Captulo 8

112

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsuario

: ManejadorServicio

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: Base de Datos Registros

1: desplegarPantalla(PantallaPrincipal) 2: "OK"

3: manejarEvento("OK") 4: validarRegistroUsuario(String,String) 5: validarRegistro(String,String) 6: executeQuery(SQL) 7: OK 8: OK 9: OK 10: ofrecerServicios() 11: desplegarPantalla(PantallaServicio)

12: "Obtener Registro" 13: manejarEvento("Obtener Registro") 14: obtenerRegi stroUsuario() 15: despl egarPantalla(PantallaObt enerRegUsuario) 16: "Actualizar" 17: manejarEv o(" Actualizar") ent 18: actualizarRegistro(RegistroUsuario) 19: executeUpdate(SQL) 20: OK 21: OK 22: despl egarPantalla(PantallaObt enerRegUsuario) 23: "Salir"

Figura 8.34. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Actualizar Registro Usuario. Registrar Usuario: Eliminar Registro Usuario El diagrama de secuencia para el caso de uso Registrar Usuario, subflujo Eliminar Registro Usuario se muestra en la Figura 8.35.

Weitzenfeld: Captulo 8

113

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsuario

: ManejadorServicio

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: Base de Datos Registros

1: desplegarPantalla(PantallaPrincipal) 2: "OK" 3: manejarEvento("OK") 4: validarRegistroUsuario(String,String) 5: validarRegistro(String,String) 6: executeQuery(SQL)

7: OK 8: OK 9: OK 10: ofrecerServicios() 11: desplegarPantalla(PantallaServicio) 12: "Obtener Registro" 13: manejarEvento("Obtener Registro") 14: obtenerRegistroUsuario() 15: desplegarPantalla(PantallaObtenerRegUsuario) 16: "Eliminar" 17: manejarEvento("Eliminar") 18: eliminarRegistro(RegistroUsuario) 19: executeUpdate(SQL)

20: OK 21: OK 22: desplegarPantalla(PantallaCrearRegUsuario) 23: "Salir"

Figura 8.35. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Eliminar Registro Usuario. Validar Usuario El diagrama de secuencia para el caso de uso Validar Usuario, se muestra en la Figura 8.36.

Weitzenfeld: Captulo 8

114

: Usuario

: InterfaceUsuario

: ManejadorRegistroUsuario

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: Base de Datos Registros

1: desplegarPantalla(PantallaPrincipal) 2: "OK" 3: manejarEvento("OK") 4: validarRegis troUsuario(String,String) 5: validarRegistro(String,String) 6: executeQuery(SQL)

7: OK 8: OK 9: OK

Figura 8.36. Diagrama de secuencias para el caso de uso Validar Usuario. Registrar Tarjeta: Crear Registro Tarjeta El diagrama de secuencia para el caso de uso Registrar Tarjeta, subflujo Crear Registro Tarjeta se muestra en la Figura 8.37.

Weitzenfeld: Captulo 8

115

: Usuario

: InterfaceUsuario

: ManejadorRegistroTarjeta

: ManejadorRegistroUsuario

: ManejadorServicio

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: Base de Dat os Registros

1: desplegarPantalla(PantallaPrincipal) 2: "OK" 3: manejarEvento("OK") 4: validarRegistroUsuario(String,String) 5: validarRegistro(String,String) 6: executeQuery(SQL) 7: OK 8: OK 9: OK 10: ofrecerServicios() 11: desplegarPantalla(PantallaServicio)

12: "Obtener Registro" 13: manejarEvento("Obtener Registro") 14: obtenerRegistroUsuario() 15: desplegarPantalla(PantallaObtenerRegUsuario) 16: "Registrar Tarjeta" 17: manejarEvento("Registrar Tarjeta") 18: registrarTarjeta(String) 19: obtenerRegistro(RegistroTarjeta) 22: NULL 20: executeQuery(SQL) 21: NULL

23: desplegarPantalla(PantallaCrearRegTarjeta) 24: "Registrar" 25: manejarEvento("Registrar") 26: escribirRegistro(registroTarjeta) 27: executeUpdate(SQL) 29: OK 30: desplegarPantalla(PantallaObtenerRegTarjeta) 31: "S alir" 28: OK

Figura 8.37. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Crear Registro Tarjeta. Registrar Tarjeta: Actualizar Registro Tarjeta El diagrama de secuencia para el caso de uso Registrar Tarjeta, subflujo Actualizar Registro Tarjeta se muestra en la Figura 8.38.

Weitzenfeld: Captulo 8

116

: Usuario

: InterfaceUsuario

: ManejadorRegistroTarjeta

: ManejadorRegistroUsuario

: ManejadorServicio

: ManejadorPrincipal

: InterfaceBaseDatosRegistro

: Base de Datos Registros

1: desplegarPantalla(PantallaPrincipal) 2: "OK" 3: manejarEvento("OK") 4: validarRegistroUsuario(String,String) 5: validarRegistro(String,String) 6: executeQuery(SQL) 8: OK 9: OK 10: ofrecerServicios() 11: desplegarPantalla(PantallaServicio) 7: OK

12: "Obtener Registro"

13: manejarEvento("Obtener Registro") 14: obtenerRegistroUsuario() 15: desplegarPantalla(PantallaObtenerRegUsuario)

16: "Registrar Tarjeta" 17: manejarEvento("Registrar Tarjeta") 18: registrarTarjeta(String) 19: obtenerRegistro(RegistroTarjeta) 20: executeQuery(SQL) 21: OK 22: OK 23: desplegarPantalla(PantallaObtenerRegTarjeta) 24: "Actualizar" 25: manejarEvento("Actualizar") 26: actualizarRegistro(RegistroTarjeta) 27: executeUpdate(SQL) 28: OK 29: OK 30: desplegarPantalla(PantallaObtenerRegTarjeta) 31: "Salir"

Figura 8.38. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Actualizar Registro Tarjeta. Registrar Tarjeta: Eliminar Registro Tarjeta El diagrama de secuencia para el caso de uso Registrar Tarjeta, subflujo Eliminar Registro Tarjeta se muestra en la Figura 8.39.

Weitzenfeld: Captulo 8

117

: Usuario

: InterfaceUsuario

: ManejadorRegistroTarjeta

: ManejadorRegistroUsuario

: ManejadorServicio

: ManejadorPrincipal

: InterfaceBaseDatosRegist ro

: Base de Dat os Registros

1: desplegarPantalla 2: "OK" 3: manejarEvento("OK") 4: validarRegistroUsuario(String,String) 5: validarRegistro(String,String) 6: executeQuery(SQL) 7: OK 8: OK 9: OK 10: ofrecerServicios() 11: desplegarPantalla(PantallaServicio)

12: "Obtener Registro" 13: manejarEvento("Obtener Registro") 14: obtenerRegistroUsuario() 15: desplegarPantalla(PantallaObtenerRegUsuario) 16: "Registrar Tarjeta" 17: manejarEvento("Registrar Tarjeta") 18: registrarTarjeta(String) 19: obtenerRegistr(RegistroTarjeta) 20: executeQuery(SQL)

21: OK 22: OK 23: desplegarPantalla(PantallaObtenerRegTarjeta) 24: "Eliminar" 25: manejarEvento("Eliminar") 26: eliminarRegistro(Regist roTarjeta) 27: executeUpdate(SQL) 28: OK 29: OK 30: desplegarPantalla(P antallaCrearRegTarjeta) 31: "Salir"

Figura 8.39. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Eliminar Registro Tarjeta.

Weitzenfeld: Captulo 9

9 Implementacin
El modelo de implementacin toma el resultado del modelo de diseo para generar el cdigo final. Esta traduccin debe ser relativamente sencilla y directa, ya que las decisiones mayores han sido tomadas durante las etapas previas. Durante el modelo de implementacin se hace una adaptacin al lenguaje de programacin y/o la base de datos de acuerdo a la especificacin del diseo y segn las propiedades del lenguaje de implementacin y base de datos. Aunque el diseo de objetos es bastante independeniente del lenguaje actual, todos los lenguajes tendrn sus particularidades, las cuales debern adecuarse durante la implementacin final. La eleccin del lenguaje influye en el diseo, pero el diseo no debe depender de los detalles del lenguaje. Si se cambia de lenguaje de programacin no debe requerirse el re-diseo del sistema. En general, no se debe comenzar prematuramente a programar, es importante primero completar el proceso de planeacin del sistema final desarrollado durante el diseo. Se debe usar guas de programacin existentes en la organizacin. Si no existen, el equipo de software deben crear sus propias guas para decidir aspectos, como formatos para la asignacin de nombres a las variables, estilo de programacin, mtodos de documentacin, y documentacin en lnea. Vale la pena resaltar que aunque existe cierta automatizacin en el proceso de generacin del cdigo final, en su gran mayora los prgramadores hacen de manera manual la transicin final a cdigo fuente. 9.1 Programacin en Java En esta seccin tomamos la especificacin del diseo hecho en el Captulo 8 y generamos la programacin, en este caso en Java. InterfaceUsuario Comenzamos la implementacin de la clase InterfaceUsuario tomando su descripcin definida en la tarjeta de clase correspondiente, como se muestra en la Tabla 9.1. Clase: InterfaceUsuario Descripcin: Toda la interaccin con el usuario se hace por medio de la interface de usuario. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Concreta Superclase: Subclase: Atributos: Manejador, Pantalla Contratos 1. Desplegar Pantalla desplegarPantalla(Pantalla) devuelve void Pantalla (1) : PantallaPrincipal (1), PantallaServicio Mtodo encargado de desplegar las pantallas enviadas (1), PantallaCrearRegUsuario (1), como parmetros. Se delega el despliegue PantallaObtenerRegUsuario (1), particular a cada pantalla. PantallaCrearRegTarjeta (1), PantallaObtenerRegTarjeta (1) 2. Enviar Evento enviarEvento(Evento) devuelve void Manejador (1) : SubsistemaPrincipal (1), Mtodo encargado de recibir eventos del sistema de SubsistemaServicio (1), SubsistemaRegistro (1) ventanas. Se enva el evento recibido a los distintos manejadores. Tabla 9.1. Tarjeta para la clase InterfaceUsuario con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La implementacin de la clase InterfaceUsuario se har a partir de la biblioteca AWT (java.awt) de Java y se basa en la descripcin de de manejo de ventanas hecha anteriormente en el Captulo 5. En nuestro manejo de ventanas heredamos la clase InterfaceUsuario de la clase Frame de Java para generar una sola ventana la cual mostrar diferentes pantallas dentro del marco de la misma ventana pero en diferentes momentos. Esta clase implementa los

Weitzenfeld: Captulo 9

manejadores de eventos de ventana y acciones como se describi anteriormente y se vuelve a describir a continuacin.
public class InterfaceUsuario extends Frame implements WindowListener, ActionListener

Los atributos de la clase son de tipo Manejador y Pantalla, como se defini anteriormente. Asignamos como nombre de las variables los mismos tipos pero en minscula y privados por ser atributos.
private Manejador manejador; private Pantalla pantalla;

Los mtodos a sobrescribir de estos manejadores de eventos fueron tambin descritos anteriormente. En el caso de eventos de ventanas se sobrescriben (implements) los mtodos descritos en la interface llamada WindowListener.
public void windowClosed(WindowEvent event) {} public void windowDeiconified(WindowEvent event) {} public void windowIconified(WindowEvent event) {} public void windowActivated(WindowEvent event) {} public void windowDeactivated(WindowEvent event) {} public void windowOpened(WindowEvent event) {} public void windowClosing(WindowEvent event) { System.exit(0); }

En el caso de eventos relacionados con acciones (botones) se debe sobrescribir un solo mtodo de la interface llamada actionListener, el mtodo actionPerformed. Este mtodo es el punto de entrada de los eventos administrados por el manejador de ventanas del sistema y provenientes del Usuario. Recordemos que la clase InterfaceUsuario define un contrato 2 llamado enviarEvento, el cual debe recibir los eventos relacionados con los botones para luego envirselos a los distintos manejadores. Este mtodo enviarEvento corresponde a actionPerformed y debe rescribirse con dicho nombre, como se muestra a continuacin. El parmetro, definido originalmente como Evento corresponde ahora a ActionEvent de Java.
// Contrato 2: Enviar Evento (ActionListener) public void actionPerformed(ActionEvent event)

Aprovechando que ya estamos definiendo el mtodo correspondiente al contrato 2, veamos como debe implementarse. El mtodo, como se especific anteriormente, tiene como responsabilidad renviar el evento a los diversos manejadores. Aunque pudiramos renviar el mismo tipo de evento ActionEvent a los menjadores, esteramos algo limitados en la extensiblidad del sistema, ya este tipo pudiera cambiar en un futuro dependiendo de las bibliotecas particular utilizadas. En su lugar, pudiramos definir nuestro propio tipo de evento para comunicacin interna del sistema, o en el caso de eventos sencillos, como los que manejaremos aqu, simplemente enviar una String correspondiente al nombre del botn presionado. El nombre del botn lo podemos obtener mediante la llamada event.getActionCommand(). La llamada a los manejadores ser a travs del contrato 1 de estos, Manejar Evento, especficamente la responsabilidad manejarEvento la cual fue definida para recibir un parmetro de tipo String. Este mtodo es sobrescrito por todos los manejadores, donde la llamada se hace a partir de la referencia genrica de manejador. La implementacin del mtodo se muestra a continuacin. La llamada se hace dentro de un if-else para asegurar que no exista una referencia nula.
System.out.println("Action: "+event.getActionCommand()); if (manejador != null) manejador.manejarEvento(event.getActionCommand()); else System.out.println("Manejador nulo");

Ya definido el manejo de evento, tanto de ventana como de acciones (contrato 2), continuamos con el despliegue de pantallas, correspondiente al contrato 1 Desplegar Pantallas, el cual tiene un solo mtodo definido, desplegarPantalla, el cual tiene como parmetro el tipo general Pantalla, como se muestra a continuacin.
// Contrato 1: Desplegar Pantalla public void desplegarPantalla(Pantalla p)

De manera similar al contrato 1 de Manejar Evento, este contrato tiene como responsabilidad solicitar a las diversas pantallas que se desplieguen. Sin embargo, antes de desplegar la siguiente pantalla, debemos borrar la actual. Esto se hace mediante un nuevo mtodo que definiremos en la clase Pantalla, la cual se encargar de borrar los elementos particulares de las pantalla. Aunque pudiramos hacerlo a nivel general de la InterfaceUsuario, existen elementos conocidos por cada pantalla, como los botones, que en el case de la biblioteca AWT sera importante deshabilitar antes de proseguir con la aadicin de nuevos botones a una misma ventana. El nuevo mtodo lo

Weitzenfeld: Captulo 9

llamaremos borrarPantalla y lo llamaremos a partir de la referencia genrica de pantalla, siempre revisando que la referencia no sea nula, como se muestra a continuacin.
if (pantalla != null) pantalla.borrarPantalla();

A continuacin, estamos listo para desplegar nuestra nueva pantalla. Como paso preliminar asignamos el valor de la referencia de p enviada como parmetro a la referencia local pantalla.
if (p != null) pantalla = p;

Hecho esto estamos listos para desplegar las nuevas pantallas mediante la solicitud al contrato 1 de las diversas pantallas, correspondiente a la responsabilidad desplegarPantalla. Como hicimos anteriomente checamos que el valor de pantalla no sea nulo y hacemos la llamada de despliegue.
if (pantalla != null) pantalla.desplegarPantalla();

Finalmente, lo nico que queda es pedir al manejador de ventanas que muestre la nueva pantalla, algo que sea hace con la llamada de show definida en la clase Frame, superclase de InterfaceUsuario.
show();

Finalmente, debemos definir el constructor para la clase. La definicin es bastante similar a la descrita en el Captulo 5, la diferencia principal radica en que el constructor es llamado por la clase ManejadorPrincipal como parte del proceso de inicializacin, por lo cual se debe agregar el parmetro correspondiente en el constructor, como se muestra a continuacin.
public InterfaceUsuario(Manejador m)

El cuerpo del cosntructor es similar a como se describin en el Captulo 5, donde simplemente asignamos el parmetro m a la referencia local manejador.
setSize(800,600); setBackground(Color.lightGray); addWindowListener(this); manejador = m;

Como podemos observar, la definicin de InterfaceUsuario se basa en el diseo del Captulo 5, adaptando los contratos definidos durante el diseo. La clase Pantalla tomando su descripcin definida en la tarjeta de clase correspondiente, como se muestra en la Tabla 9.2. Clase: Pantalla Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: InterfaceUsuario Estereotipo: Borde Propiedades: Abstracta Superclase: Subclase: PantallaPrincipal, PantallaServicio, PantallaRegUsuario, PantallaRegTarjeta Atributos: InterfaceUsuario, Manejador Contratos 1. Desplegar Pantalla desplegarPantalla() devuelve void Mtodo encargado de desplegar la pantalla actual. Tabla 9.2. Tarjeta para la superclase Pantalla. La clase Pantalla se define como una clase abstracta. Dado que la pantalla existe dentro de un marco (InterfaceUsuario hereda de Frame), no es necesario agregar ninguna herencia a esta clase.
public abstract class Pantalla

Los atributos de la clase son de tipo InterfaceUsuario y Manejador, como se defini anteriormente. Asignamos como nombre de las variables los mismos tipos pero en minscula y privados ya que minimizaremos su efecto a la superclase Pantalla y no a cada una de ellas por separado. Si esto no funciona, cambiaramos la visibilidad a protected.

Weitzenfeld: Captulo 9

private InterfaceUsuario interfaceUsuario; private Manejador manejador;

Como parte de la implementacin agregamos tambin el diseo interno de las ventanas siguiendo el ejemplo desarrollado en el Captulo 5. Definimos cuatro vectores correspondientes a todos los elementos que queremos administrar dentro de cada pantalla: paneles, botones, textos y etiquetas. Para cada uno de ellos definimos una variable temporal, las cuales utilizaremos como referencias temporales a los objetos instanciados.
protected protected protected protected protected Vector paneles,botones,textos,etiquetas; Panel panel; Button boton; TextField texto; Label etiqueta;

El constructor de la pantalla debe recibir las referencias de la InterfaceUsuario y del manejador que acaba de instanciar la pantalla, y debe permitir inicializar y crear los elementos internos de la ventana, algo que hacemos con los mtodos inicializarPantalla y crearPantalla, respectivamente.
public Pantalla(InterfaceUsuario ui,Manejador m) { interfaceUsuario = ui; manejador = m; inicializarPantalla(); crearPantalla(); }

El mtodo inicializarPantalla y se encarga de inicializar los vectores como se muestra continuacin. Definimos tanto los mtodos locales a las pantallas como aquellos que son llamados por la clase InterfaceUsuario como protegidos, como se mostr anteriormente en el Captulo 5.
protected void inicializarPantalla() { paneles = new Vector(); botones = new Vector(); textos = new Vector(); etiquetas = new Vector(); }

El mtodo crearPantalla se define como abstracto y copmo protegido.

protected abstract void crearPantalla();

Otro mtodo que ha sido mencionado anteriormente y que se define tambin como protegido es borrarPantalla, el cual est encargado de borrar los elementos de una pantalla en el momento de desplegar una nueva.
protected void borrarPantalla() { interfaceUsuario.removeAll(); int bs = botones.size(); for (int i = 0; i < bs; i++) if ((boton = (Button)botones.elementAt(i)) != null) boton.removeActionListener(interfaceUsuario); }

Otros dos mtodos an no mencionados que aprovecharemos dado que muchas clases agregan botones de Salir y de Servicios son los siguientes. Definimos dos ya que hay pantallas que slo requieren Salir, mientras que otras requieren ambas.

Weitzenfeld: Captulo 9

protected void agregarBotonesSalir(Panel panel){ boton = new Button ("Salir"); panel.add(boton); botones.addElement(boton); paneles.addElement(panel); } protected void agregarBotonesServiciosSalir(Panel panel){ boton = new Button ("Servicios"); botones.addElement(boton); panel.add(boton); agregarBotonesSalir(panel); }

El contrato 1, Desplegar Pantalla, consiste de la responsabilidad desplegarPantalla la cual tambin fue definida y explicada en el Captulo 5. La volvemos a mostrar, esta vez como parte del contrato. Tambin la definimos como protegida ya que es llamada por la InterfaceUsuario, la cual est definida como parte del mismo paquete.
// Contrato 1: Desplegar Pantalla protected void desplegarPantalla() { System.out.println("Desplegando: "+ this); int ps = paneles.size(); interfaceUsuario.setLayout(new GridLayout(ps,1)); for (int i = 0; i < ps; i++) interfaceUsuario.add((Panel)paneles.elementAt(i)); int bs = botones.size(); for (int i = 0; i < bs; i++) if ((boton = (Button)botones.elementAt(i)) != null) boton.addActionListener(interfaceUsuario); }

Principal A continuacin se describe la clase Manejador, como se muestra en la Tabla 9.3. Clase: Manejador Descripcin: Pantalla heredada por las dems clases de tipo pantalla. Mdulo: Principal Estereotipo: Control Propiedades: Abstracta Superclase: Subclase: ManejadorPrincipal, ManejadorServicio, ManejadorRegistroUsuario, ManejadorRegistroTarjeta Atributos: InterfaceUsuario, Pantalla, ManejadorServicio, Manejador Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. Responsablidades Privadas SubsistemaInterfaceUsuario (1) desplegarPantalla() devuelve void Mtodo encargado de desplegar las pantallas administradas por los manejadores. Se solicita al SubsistemaInterfaceUsuario que las despliegue. manejarEventoOfrecerServicio() devuelve void SubsistemaServicio (2) Mtodo encargado de solicitar al SubsistemaServicio que ofrezca los servicios correspondientes. manejarEventoSalir() devuelve void Mtodo encargado de salir del sistema. Tabla 9.3. 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. La clase Manejador es la superclase de todos los manejadores y se define como abstracta.

Weitzenfeld: Captulo 9

public abstract class Manejador

Los atributos principales para la clase son de tipo InterfaceUsuario, Pantalla y ManejadorServicio.
protected InterfaceUsuario interfaceUsuario; protected Pantalla pantalla; protected ManejadorServicio ms;

El constructor de la clase Manejador guarda la referencia a la interfaceUsuario y a mPadre, donde este ltimo se refiere a la clase manejador encargada de instanciar a la actual.
public Manejador(Manejador m,InterfaceUsuario ui) { interfaceUsuario = ui; mPadre = m; }

El contrato 1, Manejar Evento, define la responsabilidad manejarEvento. Aunque se especific originalmente un parmetro de tipo Evento en el protocolo, lo modificaremos a un String segn explicamos anteriormente en la implementacin del mtodo actionPerformed de la clase IntefaceUsuario.
// Contrato 1: Manejar Evento public abstract void manejarEvento(String str);

La responsabilidad desplegarPantalla es un buen ejemplo de una responsabilidad cuya definicin de su protocolo dejamos pendiente por ser privada. Dado que esta responsabilidad ser llamada por los diversos manejadores para desplegar alguna pantalla, podemos modificar su protocolo para ser protegida su visibilidad, de manera que pueda ser llamada por las subclase, adems de agregar un parmetro de tipo Pantalla correspondiente a la pantalla a ser desplegada. El cuerpo del mtodo debe solictar a la clase InterfaceUsuario proceder con el nuevo despliegue. Adicionalmente se debe actualizar la referencia local a cual pantalla se est desplegando y tambin actualizar la referencia del manejador registrado con la InterfaceUsuario.
protected void desplegarPantalla(Pantalla p) { pantalla = p; if (pantalla != null) { interfaceUsuario.setManejador(this); interfaceUsuario.desplegarPantalla(p); } else System.out.print("Pantalla Nula"); }

Debemos tambin agregar un mtodo manejarEventoOfrecerServicio el cual solicita a la clase ManejadorServicio que ejecute su contrato de Ofrecer Servicio.
protected void manejarEventoOfrecerServicio () { if (ms != null) ms.ofrecerServicio(); else System.out.println("No se ha inicializado el ManejadorServicios"); }

Ntese que es necesario instanciar la clase ManejadorServicio a travs de su referencia ms. Para ello agregamos las siguientes dos lneas en el constructor de todos los manejadores de manera que siempre obtengan la referencia del ManejadorServicio del manejador padre. Es necesario que algn manejador haga la isntanciacin apropiada de este objeto, algo que haremos en el constructor del ManejadorPrincipal.
if (mPadre != null) ms = mPadre.getManejadorServicio();

El mtodo manejarEventoSalir lo definimos de la siguiente manera.

protected void manejarEventoSalir() { System.exit(0); }

Agregamos un mtodo adicional para llamar a los dos mtodos anteriores, manejarEventoOfrecerServicio y manejarEventoSalir, correspondiente a los botones presionados en las diferentes pantallas. Este mtodo, manejarEventosAdicionales, puede ser llamado por los diversos mtodos manejarEvento de cada manejador sin tener que duplicar el cdigo de manera local.

Weitzenfeld: Captulo 9

protected void manejarEventosAdicionales(String str) { if (str.equals("Servicios")) manejarEventoOfrecerServicio(); else if (str.equals("Salir")) manejarEventoSalir(); else System.out.println("Error en pantalla: "+this+", Evento: "+str); }

La clase ManejadorPrincipal se describe en la Tabla 9.4. Clase: ManejadorPrincipal Descripcin: El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Mdulo: Principal Estereotipo: Control Propiedades: Concreta Superclase: Manejador Subclase: Atributos: PantallaPrincipal, ManejadorServicio, ManejadorRegistroUsuario Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. Responsablidades Privadas manejarEventoRegistrar() devuelve void SubsistemaRegistro (2) Mtodo encargado de solicitar al SubsistemaRegistro que de servicio al contrato de Registrar Usuario. manejarEventoValidar() devuelve void SubsistemaRegistro (2) Mtodo encargado de solicitar al SubsistemaServicio que de servicio al contrato de Ofrecer Servicio. Tabla 9.4. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase ManejadorPrincipal es una subclase de Manejador, por lo cual debe definir la extensin correspondiente.
public class ManejadorPrincipal extends Manejador

Los atributos de la clase ManejadorPrincipal son PantallaPrincipal, ManejadorServicio y ManejadorRegistroRegistro. Como veremos ms adelante, los diversos manejadores hacen referencia a estos ltimos dos manejadores por lo cual aprovechamos para definirlos en la superclase Manejador en lugar de estar redefinindolos en cada subclase especializada. De tal manera aprovechamos el reuso de cdigo a travs de la herencia.
private Pantalla pantallaPrincipal; private ManejadorServicio ms; private ManejadorRegistroUsuario mru;

Dado que el ManejadorPrincipal es el encargado de inicializar la aplicacin, definimos el mtodo esttico main como parte de la definicn de esta clase.
public static void main(String[] args) { ManejadorPrincipal m = new ManejadorPrincipal(); }

El constructor de la clase debe instanciar a la InterfaceUsuario y tambin a los manejadores con los cuales se comunicara, el ManejadorServicio y el ManejadorRegistroUsuario. Al objeto referido por interfaceUsuario, definido en la clase Manejador, le pasamos una referencia local del ManejadorPrincipal, mediante un this. Al objeto referido por ms, correspondiente a un objeto de tipo ManejadorServicio y tambin definido en la superclase Manejador, se le pasa la referencia local this y

Weitzenfeld: Captulo 9

tambin una referencia interfaceUsuario, para que pueda luego comunicarse al momento de desplegar pantallas. Hacemos algo similar con el ManejadorRegistroUsuario a travs de la referencia, mru. Esta referencia, que an no ha sido declarada, pudiera agregarse a esta clase o directamente a la superclase Manejador. Dado que tambin el ManejadorSevicio necesitar una referencia al ManejadorRegistroUsuario, aprovechamos para agregarla a la superclase Manejador. Como paso adicional, enviamos esta referencia a la clase ManejadorServicio mediante un nuevo mtodo pblico setManejadorRegistroUsuario que deber ser definido, en este caso lo haremos a nivel de la superclase Manejador. Finalmente, la lgica de la inicializacin de la aplicacin contina con el despliegue de la PantallaPrincipal mediante el mtodo local desplegarPantallaPrincipal.
public ManejadorPrincipal() { interfaceUsuario = new InterfaceUsuario(this); ms = new ManejadorServicio(this,interfaceUsuario); mru = new ManejadorRegistroUsuario(this,interfaceUsuario); ms.setManejadorRegistroUsuario(mru); desplegarPantallaPrincipal(); }

El mtodo local, aadido durante la implementacin, hace una llamada al mtodo desplegarPantalla definido en la superclase Manejador, agregando como parmetro la refencia a la nueva pantalla recin instanciada. En general, estas instanciaciones pueden hacerse de manera dinmica, como en este ejemplo, o durante la incializacin del manejador. Cual enfoque tomar depende de las consideraciones de rendimiento en relacin a uso de memoria. Instanciaciones dinmicas son hechas nicamente cuando se necesitan, a diferencia de las hechas durante una inicializacin. Sin embargo, esto tiene el costo de tiempo adicional durante la ejecucin del programa, a diferencia de lo que se hace inicialmente de manera nica, que es notado slo al principio, pero no durante el transcurso del programa. Ntese de manera adicional que la instanciacin de la clase PantallaPrincipal requiere de un parmetro interfaceUsuario y otro de tipo Manejador, a travs del this.
private void desplegarPantallaPrincipal() { if (pantallaPrincipal == null) pantallaPrincipal = new PantallaPrincipal(interfaceUsuario,this); desplegarPantalla(new PantallaPrincipal(interfaceUsuario,this)); }

Pasamos al contrato 1 de la clase ManejadorPrincipal, Manejar Evento, el cual sobrescribe al contrato definido en la superclase Manejador. Este contrato, definido mediante el mtodo manejarEvento requiere la misma firma (protocolo) que el definido en la superclase, en otras palabras, debe ser de tipo String. Aqu se hace el manejo de las diferentes opciones presentes en la PantallaPrincipal, bsicamente, los botones Registrarse por Primera Vez, OK y Salir. Cada uno de estos botones aparece como una opcin adicional dentro del ifelse. En el caso de Registrarse por Primera Vez se llama al mtodo manejarEventoRegistrar, en el caso OK se llama al mtodo manejarEventoValidar, y en el caso de Salir se hace el manejo a travs de la superclase Manejador mediante la llamada manejarEventosAdicionales con el nombre del String correspondiente al evento.
// Contrato 1: Manejar Evento public void manejarEvento(String str) { if (str.equals("Registrarse por Primera Vez")) manejarEventoRegistrar(); else if (str.equals("OK")) { manejarEventoValidar(); } else manejarEventosAdicionales(str); }

El mtodo manejarEventoRegistrar hace una llamada a la responsabilidad con nombre similar dentro de la clase ManejadorRegistroUsuario, representada por la referencia mru y correspondiente al contrato Registrar Usuario de esta ltima.

Weitzenfeld: Captulo 9

private void manejarEventoRegistrar() { if (mru != null) mru.crearRegistroUsuario(); else System.out.println("No se ha inicializado el ManejadorRegistroUsuario"); }

De manera similar, el mtodo manejarEventoValidar hace una llamada a la responsabilidad con nombre similar dentro de la clase ManejadorRegistroUsuario, representada por la referencia mru y correspondiente al cotnrato Registrar Usuario de esta ltima. A diferencia de la creacin de un nuevo, registro, la validacin requiere del login y contrasea, ambos obtenido de la PantallaPrincipal mediante la llamada leerTexto, algo que ser explicado ms adelante. Una vez validado el usuario (if interno), se contina con ofrecerServicio o con el despliegue de alguna pantalla de mensaje de error. En nuestro caso, volvemos a desplegar la misma pantalla para mantener limitado el cdigo de nuestro ejemplo.
private void manejarEventoValidar() { String log = pantalla.leerTexto("login"); String pass = pantalla.leerTexto("password"); if (mru != null) { if (mru.validarRegistroUsuario(log,pass) == true) manejarEventoOfrecerServicio(); else desplegarPantalla(pantalla); } else System.out.println("No se ha inicializado el ManejadorRegistroUsuario"); }

La descripcin de la clase PantallaPrincipal es bastante limitada ya que no incluye responsabilidades. Sin embargo, vale la pena describirla como ejemplo a seguir para las dems pantallas. La tarjeta de clase se muestra en la Tabla 9.5. Clase: PantallaPrincipal Descripcin: Pantalla principal (P-1). Mdulo: Principal Estereotipo: Borde Propiedades: Concreta Superclase: Pantalla Subclase: Atributos:

Tabla 9.5. Tarjeta para la clase PantallaPrincipal con responsabilidades, colaboraciones, jerarquas y contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase PantallaPrincipal hereda de la superclase Pantalla.
public class PantallaPrincipal extends Pantalla

El constructor de la clase pasa los parmetros de instanciacin, ui y m, a la superclase, mediante el mtodo super. Los parmetros corresponden a las referencias que debe mantener toda pantalla, una a la InterfaceUsuario y otra al Manejador que administra la pantalla.
public PantallaPrincipal (InterfaceUsuario ui,Manejador m) { super(ui,m); }

Aunque pudiramos haber creado los elementos internos de la pantalla dentro del constructor, preferimos hacerlo en un mtodo adicional, crearPantalla, lo cual nos da ms flexibilidad en el cdigo, ya que podemos generar los eventos en el momento que deseemos y no necesariamente durante la instanciacin del objeto. Slo mostramos parte del cogi interno del mtodo, ya que el detalle fue explicado en el Captulo 5.

Weitzenfeld: Captulo 9

10

protected void crearPantalla() { panel = new Panel(); panel.setLayout(new GridLayout(3,1)); panel.add(new Label("SISTEMA DE RESERVACIONES DE VUELO", Label.CENTER)); panel.add(new Label("Pantalla Principal (P-1)", Label.CENTER)); paneles.addElement(panel); ... panel = new Panel(); panel.add(new Label("Login:", Label.LEFT)); texto = new TextField(20); texto.setName("login"); textos.addElement(texto); panel.add(texto); paneles.addElement(panel); panel = new Panel(); panel.add(new Label("Password:")); texto = new TextField(20); texto.setName("password"); texto.setEchoChar('#'); textos.addElement(texto); panel.add(texto); paneles.addElement(panel); ... }

Vale la pena resaltar ciertos cambios en el manejo de lementos grficos que an no han sido comentados. Estos cambios tienen que ver principalmente con el manejo de los campos de texto, ya que de all obtendremos informacin insertada por el usuario. Para lograr un manejo generalizado de esta informacin, agregamos un nombre particular a cada campo de texto. En el caso de login, sera
texto.setName("login");

Una vez creado el texto, lo agregamos a la lista de textos, de manera similar a los paneles y botones:
textos.addElement(texto);

En el caso de password, agregamos la opcin de cambiar el carcter de despliegue a un #, mediante:

texto.setEchoChar('#');

Entre lso cambios anteriores, el ms importante para nuestro diseo es el hecho que se agreg un nombre para cada campo de texto. Este nombre luego lo utilizaremos para identificar campos en las pantallas y as obtener de manera generalizada su informacin o escribir en ella, algo que veremos ms adelante. Dominio Aunque pudiramos definir los diversos atributos de cada clase entidad en las clases correspondientes, haremos un pequeo rediseo mediante generalizando un poco la especificacin de estos atributos a partir de la clase Datos. Para ello definiremos dos colecciones de objetos, una correspondiente al nombre del atributo y otro al valor que guarda. En el caso de los nombres, la coleccin debe guardar tipos String, mientras que en el caso de los valores, pueden corresponder a cualquier tipo de objeto. Para nuestro ejemplo utilizaremos valores tambin de tipo cadenas, aunque esto en general restringe un poco el manejo de los datos. En todo caso, es sencillo extender este diseo a los dems tipos, como Integer, etc. Por lo tanto la descripcin de la clase Datos se muestra en la Tabla 9.6. Clase: Datos Descripcin: Superclase para todas las clases entidad. Mdulo: Dominio Estereotipo: Entidad Propiedades: Abstracta Superclase: Subclase: RegistroUsuario, RegistroTarjeta Atributos: Coleccin nombres, Coleccin valores

Tabla 9.6 Superclase entidad Datos para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La definicin de la clase es la siguiente.

Weitzenfeld: Captulo 9

11

public class Datos

Podemos escoger cualquier tipo de coleccin como base para nuestros atributos. Para no complicarnos demasiado escogeremos el tipo Vector de Java, y dado que son dos los vectores que necesitaremos, pus haremos un arreglo de dos vectores. Esto se declara de la siguiente manera.
protected Vector campos[];

El constructor de la clase Datos debe inicializar el arreglo de dos vectores junto con los propios vectores.
public Datos() { campos = new Vector[2]; for (int i = 0; i < 2; i++) campos[i] = new Vector(); }

Luego necesitamos agregar un grupo de mtodos para manipular la informacin. El primero ser agregarAtributo, el cual sera llamado por las subclases cuando deseen incluir atributos en su definicin. Para ello, se pasa el nombre del atributo como primer parmetro, el cual se agrega al primer vector, y un segundo parmetro correspondiente a su valor, el cual se agrega al segundo vector. En este caso pasamos un valor de inicialziacin vaco de tipo String. En el caso de otros tipos valores, se sobrecargara el mtodo de manera correspondiente. Tambin sera necesario agregar mtodos adicionales para obtencin o cambios en los valores.
protected void agregarAtributo(String nombre, String valor) { campos[0].addElement(nombre); campos[1].addElement(valor); }

Para leer los nombres o valores guardados en los vectores, definimos los siguiente dos mtodos, leerNombre y leerValor, de manera correspondiente. Dado que los vectores se accesan como arreglos, el parmetro que se pasa es el ndice del atributo.
public String leerNombre(int i) { return (String) campos[0].elementAt(i); } public String leerValor(int i) { return (String) campos[1].elementAt(i); }

De manera anloga, definimos un mtodo escribirValor para escribir valores a los atributos.
public void escribirValor(int i, String str) { campos[1].setElementAt(str,i); }

Finalmente, podemos definir un mtodo que simplemente obtenga el nmero de atributos definidos, lo cual corresponde al tamao del vector.
public int numeroAtributos() { return campos[0].size(); }

Registro En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, slo se modifican las clases de control pero no las de interface o entidad, como se ver a continuacin. Usuario En la Tabla 9.7 se muestra la clase ManejadoRegistroUsuario. Clase: ManejadorRegistroUsuario Descripcin: El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema. Mdulo: Registro.Usuario Estereotipo: Control Propiedades: Concreta Superclase: Manejador Subclase: Atributos: PantallaCrearRegUsuario, PantallaObtenerRegUsuario, RegistroUsuario, ManejadorRegistrTarjeta, InterfaceBaseDatosRegistro Contratos 1. Manejar Evento

Weitzenfeld: Captulo 9

12

manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. 2. Registrar Usuario crearRegistroUsuario() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la creacin de un nuevo RegistroUsuario a travs del contrato de Registrar Usuario validarRegistroUsuario(String,String) devuelve Boolean InterfaceBaseDatosRegistro (1) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la validacin de un usuario a travs del contrato de Registrar Usuario obtenerRegistroUsuario() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la obtencin de un RegistroUsuario a travs del contrato de Registrar Usuario Responsabilidades Privadas manejarEventoRegistrar() devuelve void InterfaceBaseDatosRegistro (1) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la creacin de un nuevo RegistroUsuario a travs del contrato de Registrar Usuario InterfaceBaseDatosRegistro (1) manejarEventoActualizar() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la actualizacin de un RegistroUsuario a travs del contrato de Registrar Usuario InterfaceBaseDatosRegistro (1) manejarEventoEliminar() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la eliminacin de un RegistroUsuario a travs del contrato de Registrar Usuario manejarEventoRegistrarTarjeta() devuelve void ManejadorRegistroTarjeta (2) Mtodo encargado de solicitar a la ManejadorRegistroTarjeta que procese el contrato Registrar Tarjeta Tabla 9.7. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario. La clase ManejadoRegistroUsuario hereda de la superclase Manejador y se define de la siguiente manera.
public class ManejadorRegistroUsuario extends Manejador

Los atributos que definiremos para la clase son los siguientes.

private private private private private Pantalla pantallaCrearRegUsuario; Pantalla pantallaObtenerRegUsuario; RegistroUsuario registroUsuario; ManejadorRegistroTarjeta mrt; InterfaceBaseDatosRegistro interfaceRegistro;

El constructor se encarga de instanciar los diversos objetos. Las dos pantallas se instanciarn de manera dinmica, mal igual que el ManejadorRegistroTarjeta.
public ManejadorRegistroUsuario(Manejador m,InterfaceUsuario ui) { super(m,ui); registroUsuario = new RegistroUsuario(); interfaceRegistro = new InterfaceBaseDatosRegistro(); }

El contrato 1 Manejar Evento debe contemplar los diversos botones que aprecen en las pantallas administradas por este manejador. En el caso de Registrar, se llama al mtodo manejarEventoRegistrar, Actualizar llamada al mtodo manejarEventoActualizar, Eliminar llama al mtodo manejarEventoEliminar, Registrar Tarjeta llama al mtodo manejarEventoRegistrarTarjeta, mientras que los botones Servicio y Salir son administrados por la superclase Manejador a travs del mtodo manejarEventosAdicionales. Estos mtodos los describiremos con mayor detalles en breve.

Weitzenfeld: Captulo 9

13

// Contrato 1: Manejar Evento public void manejarEvento(String str) { if (str.equals("Registrar")) manejarEventoRegistrar(); else if (str.equals("Actualizar")) manejarEventoActualizar(); else if (str.equals("Eliminar")) manejarEventoEliminar(); else if (str.equals("Registrar Tarjeta")) manejarEventoRegistrarTarjeta(); else manejarEventosAdicionales(str); }

El contrato 2 Registrar Usuario consta de tres responsabilidades, crearRegistroUsuario, validarRegistroUsuario y obtenerRegistroUsuario. El mtodo crearRegistroUsuario se encarga de desplegar la pantalla pantallaCrearRegUsuario. Antes de solicitar su despliegue se verifica que la pantalla exista.
// Contrato 2: Registrar Usuario public void crearRegistroUsuario() { if (pantallaCrearRegUsuario == null) pantallaCrearRegUsuario = new PantallaCrearRegUsuario(interfaceUsuario,this); desplegarPantalla(pantallaCrearRegUsuario); }

El mtodo validarRegistroUsuario recibe dos parmetros del usuario, login y contrasea, y se encarga de solicitar a la clase InterfaceBaseDatosRegistro, a travs ed la referencia interfaceRegistro, que valide al usuario. El resultado debe ser un verdadero o falso (true o false). Ntese, que estamos enviando un objeto de tipo RegistroUsuario como parte de la llamada a la clase InterfaceBaseDatosRegistro. Esto realmente no es necesario, pero lo hacemos para aprovechar la llamada de validacin a la base de datos, y obtener junto con la validacin la informacin del usuario. De esta manera evitamos tener que hacer una segunda llamada para obtener los propios datos del usuario.
public boolean validarRegistroUsuario(String log, String pass) { if (registroUsuario == null) registroUsuario = new RegistroUsuario(); return interfaceRegistro.validarRegistro(registroUsuario,log,pass); }

El mtodo obtenerRegistroUsuario se encarga de desplegar la pantalla pantallaObtenerRegUsuario. Antes de solicitar su despliegue se verifica que la pantalla exista, y que tambin exista un RegistroUsuario que contenga la informacin solicitada. Si ambos existen, se contina escribiendo los datos del RegistroUsuario en la pantalla, mediante el mtodo escribirElementos definido en la superclase Manejador. Continuaremos con el resto de los mtodos de la clase ManejadorRegistroUsuario antes de explicar como escribir y leer datos de las pantallas.
public void obtenerRegistroUsuario() { if (registroUsuario == null) System.out.println("Registro Invalido"); else { if (pantallaObtenerRegUsuario == null) pantallaObtenerRegUsuario = new PantallaObtenerRegUsuario(interfaceUsuario,this); escribirElementos(pantallaObtenerRegUsuario,registroUsuario); desplegarPantalla(pantallaObtenerRegUsuario); } }

El mtodo escribirElementos lo definimos en la clase Manejador (aunque mostrado recin aqu), el cual se encarga de solicitar a la pantalla que actualice sus campos de textos de acuerdo a los datos enviados. Ms adelante explicaremos los detalles de esta escritura.
protected void escribirElementos(Pantalla p,Datos datos) { p.escribirElementos(datos); }

El mtodo manejarEventoRegistrar verifica que se haya instanciado un RegistroUsuario para luego guardar all los datos insertados por el usuario en le pantalla, mediante el mtodo leerElementos, definido en la

Weitzenfeld: Captulo 9

14

superclase Manejador (anlogo a escribirElementos). Una vez obtenidos los datos y guardados en el RegistroUsuario, estos son enviados a la InterfaceBaseDatosRegistro, a travs del mtodo crearRegistro, para ser guardados en la base de datos. Finalemente, aprovechamos el mtodo obtenerRegistroUsuario ya existente para desplegar la PantallaObtenerRegUsuario con los nuevos datos.
private void manejarEventoRegistrar() { if (registroUsuario == null) registroUsuario = new RegistroUsuario(); leerElementos(pantalla,registroUsuario); interfaceRegistro.crearRegistro(registroUsuario); obtenerRegistroUsuario(); }

El mtodo leerElementos lo definimos en la clase Manejador (aunque mostrado tambin aqu), el cual se encarga de solicitar a la pantalla que lea sus campos en el objeto de tipo datos enviados. Ms adelante explicaremos los detalles de esta lectura.
protected void leerElementos(Pantalla p,Datos datos) { p.leerElementos(datos); }

El mtodo manejarEventoActualizar se comporta de manera similar a registrarUsuario en el sentido que se leen los elementos de la pantalla para luego actualizar la base de datos mediante el mtodo actualizarRegistro (antes se creaba el registro). Se pudiera agregar la llamada obtenerRegistroUsuario al final, pero dado que ya se est en la pantalla PantallaObtenerRegUsuario no hay necesidad de hacerlo.
private void manejarEventoActualizar() { if (registroUsuario == null) registroUsuario = new RegistroUsuario(); leerElementos(pantalla,registroUsuario); interfaceRegistro.actualizarRegistro(registroUsuario); }

El mtodo manejarEventoEliminar toma un RegistroUsuario ya existente, actualmente desplegado en la pantalla, y solicita a la InterfaceBaseDatosRegistro su eliminacin mediante el mtodo eliminarRegistro. Una vez eliminado el registro se regresa al flujo correspondiente a la creacin de un nuevo registro, mediante la llamada crearRegistroUsuario.
private void manejarEventoEliminar() { if (registroUsuario == null) System.out.println("Registro Invalido"); else { interfaceRegistro.eliminarRegistro(registroUsuario); crearRegistroUsuario(); } }

Finalmente, el mtodo manejarEventoRegistrarTarjeta se encarga de solicitar al ManejadorRegistroTarjeta que procese el contrato Registrar Tarjeta, correspondiente al mtodo registrarTarjeta de ste ltimo. Como parte de este mtodo, primero se instancia el nuevo manejador para luego obtener un identificador correspondiente al usuario actual. Esto se hace mediante la llamada leerValor(0) del RegistroUsuario. El 0 corresponde al primer atributo del registro, en otras palabras el login.
private void manejarEventoRegistrarTarjeta() { if (registroUsuario == null) System.out.println("Registro Invalido"); else { if (mrt == null) mrt = new ManejadorRegistroTarjeta(this,interfaceUsuario); String id = registroUsuario.leerValor(0); mrt.registrarTarjeta(id); } }

La descripcin de las clases PantallaRegUsuario, PantallaCrearRegUsuario PantallaObtenerRegUsuario es muy similar a la PantallaPrincipal anteriormente descrita.

Weitzenfeld: Captulo 9

15

Antes de proseguir, es importante aadir los mtodos faltantes para la clase Pantalla (descrita antes de manera parcial). Los mtodos un pendientes de describir son leerTexto, leerElementos y escribirElementos. El mtodo leerTexto se muestra a continuacin.
public String leerTexto(String name0) { String name = null, str = null; for (int j = 0; name0.equals(name) == false && j < textos.size(); j++) { name = ((Component) textos.elementAt(j)).getName(); if (name0.equals(name) == true) str = ((TextField) textos.elementAt(j)).getText(); } return str; }

El mtodo recibe un nombre, name0, correspondiente al campo que se desea leer de la pantalla. Recordemos que cada campo de texto en la pantalla fue asignado con un nombre. El ciclo del for compara este nombre contra la variable name mediante la llamada name0.equals(name) == false. Cuando estas dos variables son iguales el ciclo termina. Tambin puede terminar, cuando se acaba de revisar todos los campos de texto en la pantalla, especificado mediante textos.size(). La variable name lee los diferentes nombres asignados a los campos de la pantalla, algo que se hace mediante la llamada:
name = ((Component) textos.elementAt(j)).getName();

Se vuelve a hacer la comparacin de nombres:

if (name0.equals(name) == true)

Si los nombres son iguales, se prosigue leyendo el dato insertado por el usuario:
str = ((TextField) textos.elementAt(j)).getText();

Dado que los campos coinciden, el ciclo del for se termina y se sale del mtodo regresando el valor de str correspondiente al dato insetado pro el usuario en el campo correspondiente. El mtodo anterior fue diseado para leer el dato correspondiente a un solo campo de la pantalla. Este mtodo se extiende en el mtodo leerElementos para leer todos los campos de manera automtica, y guardarlos en un objeto de tipo Datos, en lugar de un String, en el caso anterior. Para ello, se pasa como parmetro, un objeto ya instanciado que defina atributos con nombres similares a aquellos que definen campos de texto en la pantalla. Esto es muy importante, dado que si no coinciden, no lograremos obtender ningn valor. Por otro lado, al ya estar instanciado el objeto, simplemente nos hara faltar rellenar los valores para los atributos correspondientes. El mtodo leerElementos se describe a continuacin.
public void leerElementos(Datos datos) { String name0,str,name; for (int i = 0; i < datos.numeroAtributos(); i++) { name0 = (String)datos.leerNombre(i); str = null; name = null; for (int j = 0; name0.equals(name) == false && j < textos.size(); j++) { name = ((Component) textos.elementAt(j)).getName(); if (name0.equals(name) == true) { str = ((TextField) textos.elementAt(j)).getText(); datos.escribirValor(i,str); } } } }

El ciclo interno del for (el segundo ciclo) es exactamente igual al definido en el mtodo leerValor. El cambio en este mtodo radica en el for externo (el primer ciclo), donde se cicla por todos los atributos del objeto de tipo Datos hasta haber ledo el nombre de todos los atributos mediante datos.numeroAtributos(). Durante este ciclo se lee el nombre de cada atributo:
name0 = (String)datos.leerNombre(i);

Este nombre, name0, corresponde al nombre originalmente enviado como parmetro en leerValor. A diferencia del mtodo anterior, aqu se cicla por todos los atributos, y en lugar de devolver el valor encontrado cunado exista una correspondencia entre campos, lo que hacemos es copiar el valor al objeto de tipo datos:

Weitzenfeld: Captulo 9

16

datos.escribirValor(i,str);

El mtodo escribirValor est definido en la clase Datos y ya fue descrito anteriormente. El siguiente mtodo escribirElementos, se encarga de hacer el opuesto al mtodo anterior. El mtodo escribirElementos recibe un objeto de tipo Datos y copia los valores de sus atributos a los campos correspondientes en la pantalla. Este mtodo se muestra a continuacin.
public void escribirElementos(Datos datos) { String name0,str,name; for (int i = 0; i < datos.numeroAtributos(); i++) { name0 = (String)datos.leerNombre(i); str = (String)datos.leerValor(i); name = null; for (int j = 0; name0.equals(name) == false && j < textos.size(); j++) { name = ((Component) textos.elementAt(j)).getName(); if (name0.equals(name) == true) ((TextField) textos.elementAt(j)).setText(str); } } }

Ambos ciclos son similares, existiendo nicamente dos modificaciones en la lgica. La primera, es que el valor de str se obtiene del atributo en lugar del campo de la pantalla:
str = (String)datos.leerValor(i);

El segundo cambio es que se escribe del atributo a la pantalla en lugar de cmo se haca antes:
((TextField) textos.elementAt(j)).setText(str);

Recurdese que estos tres mtodos anteriores son parte de la definicin de la clase Pantalla. Ahora continuamos con las clase de registro de usuario. La clase RegistroUsuario se mantiene igual a como se describi anteriormente en la Tabla 8.53, como se muestra en la Tabla 9.8. Clase: RegistroUsuario Descripcin: 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. Mdulo: Registro.Usuario Estereotipo: Entidad Propiedades: Concreta Superclase: Datos Subclase: Atributos: login, password, nombre, apellido, direccin, colonia, ciudad, pas, CP, telCasa, telOficina, fax, email

Tabla 9.8. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas y contratos de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario. La clase RegistroUsuario hereda de la superclase Datos.
public class RegistroUsuario extends Datos

Dentro del constructor de la clase inicializamos los atributos mediante llamadas a agregarAtributo definidos en la superclase Datos. El primer parmetro es el nombre del atributo, mientras que en el segundo inicializamos su valor, en este caso con cadenas vacas.

Weitzenfeld: Captulo 9

17

public RegistroUsuario() { agregarAtributo("login",""); agregarAtributo("password",""); agregarAtributo("nombre",""); agregarAtributo("apellido",""); agregarAtributo("direccion",""); agregarAtributo("colonia",""); agregarAtributo("ciudad",""); agregarAtributo("pais",""); agregarAtributo("CP",""); agregarAtributo("telCasa",""); agregarAtributo("telOficina",""); agregarAtributo("fax",""); agregarAtributo("email",""); }

No se define ningn mtodo adicional para la clase RegistroUsuario. Tarjeta La clase ManejadoRegistroTarjeta se muestra en la Tabla 9.9. Clase: ManejadorRegistroTarjeta Descripcin: El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones. Mdulo: Registro.Tarjeta Estereotipo: Control Propiedades: Concreta Superclase: Manejador Subclase: Atributos: PantallaCrearRegTarjeta, PantallaObtenerRegTarjeta, RegistroTarjeta, InterfaceRegistro Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. 2. Registrar Tarjeta registrarTarjeta(String) devuelve void Mtodo encargado de crear u obtener un RegistroTarjeta Responsabilidades Privadas crearRegistroTarjeta() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la creacin de un nuevo RegistroTarjeta a travs del contrato de Registrar Tarjeta InterfaceBaseDatosRegistro (2) obtenerRegistroTarjeta() devuelve void Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la obtencin de un RegistroTarjeta a travs del contrato de Registrar Tarjeta manejarEventoRegistrar() devuelve void InterfaceBaseDatosRegistro (2) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la creacin de un nuevo RegistroTarjeta a travs del contrato de Registrar Tarjeta manejarEventoActualizar() devuelve void InterfaceBaseDatosRegistro (2) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la actualizacin de un

Weitzenfeld: Captulo 9

18

RegistroTarjeta a travs del contrato de Registrar Tarjeta manejarEventoEliminar() devuelve void InterfaceBaseDatosRegistro (2) Mtodo encargado de solicitar a la InterfaceBaseDatosRegistro la eliminacin de un RegistroTarjeta a travs del contrato de Registrar Tarjeta Tabla 9.9. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos identificadas del caso de uso RegistrarTarjeta. La clase ManejadorRegistroTarjeta hereda de la superclase Manejador.
public class ManejadorRegistroTarjeta extends Manejador

Se definen los atributos especificados anteriormente, y tambin agregamos un nuevo atributo idRegistro de tipo String para guardar la referencia al login del usuario dueo del registro de tarjeta actualmente manipulado. Este nuevo atributo facilitar el manejo local de la informacin.
private private private private private Pantalla pantallaCrearRegTarjeta; Pantalla pantallaObtenerRegTarjeta; RegistroTarjeta registroTarjeta; InterfaceRegistro interfaceRegistro; String idRegistro;

El constructor de la clase instancia un objeto de tipo RegistroTarjeta y recibe la referencia a la clase InterfaceBaseDatosRegistro. En caso de que la referencia sea nula, se instancia un nuevo objeto. Las pantallas son inicializadas durante la ejecucin del programa.
public ManejadorRegistroTarjeta(Manejador m,InterfaceUsuario ui) { super(m,ui); registroTarjeta = new RegistroTarjeta(); interfaceRegistro = ((ManejadorRegistroUsuario) m).getInterfaceRegistro(); if (interfaceRegistro == null) interfaceRegistro = new InterfaceBaseDatosRegistro(); }

El contrato 1 Manejar Evento se encarga de administrar el comportamiento del registro de tarjeta dependiendo del botn que oprima el usuario. En el caso de Registrar se llama al mtodo manejarEventoRegistrar, en el caso de Actualizar se llama al mtodo manejarEventoActualizar, en el caso de Eliminar se llama al mtodo manejarEventoEliminar, y en el caso de Servicio y Salir se llama al mtodo manejarEventosAdicionales, el cual se encarga de darle manejo a estas dos opciones.
// Contrato 1 public void manejarEvento(String str) { if (str.equals("Registrar")) manejarEventoRegistrar(); else if (str.equals("Actualizar")) manejarEventoActualizar(); else if (str.equals("Eliminar")) manejarEventoEliminar(); else manejarEventosAdicionales(str); }

El contrato 2 RegistrarTarjeta define un mtodo registrarTarjeta el cual se describe a continuacin.

// Contrato 2 public void registrarTarjeta(String log) { idRegistro = log; if (registroTarjeta == null) registroTarjeta = new RegistroTarjeta(); boolean fg = interfaceRegistro.obtenerRegistro(registroTarjeta,log); if (fg == false) crearRegistroTarjeta(); else obtenerRegistroTarjeta(); }

El mtodo recibe un parmetro, log, de tipo String correspondiente al usuario actualmente validado. Se verifica si ya existe un registro de tarjeta para el usuario mediante una llamada a la InterfaceBaseDatosRegistro:

Weitzenfeld: Captulo 9

19

boolean fg = interfaceRegistro.obtenerRegistro(registroTarjeta,log);

Si an no existe un registro de terjeta se solicita la creacin de uno nuevo mediante el mtodo crearRegistroTarjeta, de lo contrario se contina con su despliegue mediante el mtodo obtenerRegistroTarjeta. El mtodo crearRegistroTarjeta est encargado de desplegar la PantallaCrearRegTarjeta.
private void crearRegistroTarjeta() { if (pantallaCrearRegTarjeta == null) pantallaCrearRegTarjeta = new PantallaCrearRegTarjeta(interfaceUsuario,this); desplegarPantalla(pantallaCrearRegTarjeta); }

El mtodo obtenerRegistroTarjeta est encargado de escribir los datos registroTarjeta en la PantallaObtenerRegTarjeta para luego ser desplegados.

obtenidos

en

el

private void obtenerRegistroTarjeta() { if (registroTarjeta == null) System.out.println("Registro Invalido"); else { if (pantallaObtenerRegTarjeta == null) pantallaObtenerRegTarjeta = new PantallaObtenerRegTarjeta(interfaceUsuario,this); escribirElementos(pantallaObtenerRegTarjeta,registroTarjeta); desplegarPantalla(pantallaObtenerRegTarjeta); } }

El mtodo manejarEventoRegistrar se encarga de leer los elementos de la pantalla y escribirlos en la base de datos. Al finalizar, se contina con su despliegue en la pantallaObtenerRegTarjeta mediante la llamada obtenerRegistroTarjeta.
private void manejarEventoRegistrar() { if (registroTarjeta == null) registroTarjeta = new RegistroTarjeta(); registroTarjeta.escribirValor(0,idRegistro); leerElementos(pantalla,registroTarjeta); interfaceRegistro.crearRegistro(registroTarjeta); obtenerRegistroTarjeta(); }

El mtodo manejarEventoActualizar se encarga de leer los datos de la pantalla al registroTarjeta y actualizar la base de datos.
private void manejarEventoActualizar() { if (registroTarjeta == null) registroTarjeta = new RegistroTarjeta(); leerElementos(pantalla,registroTarjeta); interfaceRegistro.actualizarRegistro(registroTarjeta); }

El mtodo manejarEventoEliminar se encarga de eliminar los datos actuales del registroTarjeta y solicitar su eliminacin de la base de datos.
private void manejarEventoEliminar() { if (registroTarjeta == null) System.out.println("Registro Invalido"); else { interfaceRegistro.eliminarRegistro(registroTarjeta); crearRegistroTarjeta(); } }

La descripcin de las clases PantallaRegUsuario, PantallaCrearRegUsuario y PantallaObtenerRegUsuario es muy similar a la PantallaPrincipal anteriormente descrita. La clase RegistroTarjeta se mantiene igual a como se describi anteriormente en la Tabla 8.53, como se muestra en la Tabla 9.7. La tarjeta de clase para RegistroTarjeta se muestra en la Tabla 9.10. Clase: RegistroTarjeta Descripcin: Para poder hacer un pago con una tarjeta de crdito, se debe tener un registro de tarjeta. El registro

Weitzenfeld: Captulo 9

20

contiene informacin acerca de la tarjeta incluyendo nombre, nmero, expedidor y vencimiento. La tarjeta est ligada a un registro de usuario. Mdulo: Registro.Tarjeta Estereotipo: Entidad Propiedades: Concreta Superclase: Datos Subclase: Atributos: login, nombre, nmero, tipo, fecha

Tabla 9.10. Tarjeta para la clase RegistroTarjeta con responsabilidades, colaboraciones, jerarquas y contratos de actualizar y consultar informacin de registro para el caso de uso RegistrarTarjeta. La clase RegistroTarjeta hereda de la superclase Datos.
public class RegistroTarjeta extends Datos

Dentro del constructor de la clase inicializamos los atributos mediante llamadas a agregarAtributo definidos en la superclase Datos. El primer parmetro es el nombre del atributo, mientras que en el segundo inicializamos su valor, en este caso con cadenas vacas.
public RegistroTarjeta() { agregarAtributo("login",""); agregarAtributo("nombre",""); agregarAtributo("numero",""); agregarAtributo("tipo",""); agregarAtributo("fecha",""); }

No se define ningn mtodo adicional para la clase RegistroTarjeta. Interface Registro La clase InterfaceRegistro se muestra en la Tabla 9.11. Clase: InterfaceRegistro Descripcin: Superclase para las interfaces a base de datos de registro y archivos. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Abstracta Superclase: Subclase: Atributos: Contratos 1. Registrar Usuario crearRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario obtenerRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario actualizarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario eliminarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario validarRegistro(String, String) devuelve bolean BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta

Weitzenfeld: Captulo 9

21

crearRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta obtenerRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta actualizarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 9.11. Tarjeta para la clase InterfaceRegistro 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. Definimos la superclase InterfaceRegistro de la siguiente manera.
public abstract class InterfaceRegistro

Definimos un solo grupo de mtodos para ambos contratos, generalizando el parmetro a Datos y especificando todos los mtodos para que devuelvan un tipo booleano,
// Contrato 1: Registrar Usuario // Contrato 2: Registrar Tarjeta public abstract boolean crearRegistro(Datos reg); public abstract boolean actualizarRegistro(Datos reg); public abstract boolean eliminarRegistro(Datos reg); public abstract boolean validarRegistro(Datos reg,String log,String pass); public abstract boolean obtenerRegistro(Datos reg,String log);

Agregamos un mtodo que necesitaremos para lograr un manejo genrico de los diferentes objetos entidad. Este mtodo se encargar de recibir como parmetro un objeto especializado devolviendo el nombre como String de su clase. Este nombre luego lo utilizaremos para instanciar nuevos objetos de esta clase de manera annima, algo que en Java se facilita mucho.
public String getClassName(Datos reg){ String regname; Class regclass = reg.getClass(); String fullname = regclass.getName(); int index = fullname.lastIndexOf('.'); if (index > 0) regname = fullname.substring(index+1); else regname = fullname; return regname; }

Se obtiene la clase de un objeto mediante la siguiente llamada:

Class regclass = reg.getClass();

Luego obtenemos el nombre como cadena de esta clase,

String fullname = regclass.getName();

Sin embargo, este nombre incluye el prefijo de todos los paquetes. Si deseamos nicamente obtener el nombre propio de la clase sin informacin sobre sus paquetes, lo que haramos es obtener la posicin del limo . En el nombre,
int index = fullname.lastIndexOf('.');

Finalmente buscamos el nombre a partir del ltimo .,

regname = fullname.substring(index+1);

En el caso de que no incluya el nombre ningn paquete, lo devolveramos completo,

regname = fullname;

La clase InterfaceBaseDatosRegistro se muestra en la Tabla 9.12. Clase: InterfaceBaseDatosRegistro Descripcin: La informacin de cada usuario se almacena en la base de datos de registro la cual se accesa mediante

Weitzenfeld: Captulo 9

22

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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclase: Subclase: Atributos: Contratos 1. Registrar Usuario crearRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario obtenerRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario actualizarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario eliminarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario validarRegistro(String, String) devuelve bolean BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta obtenerRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta actualizarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 9.12. 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. La clase InterfaceBaseDatosRegistro se define a continuacin:
public class InterfaceBaseDatosRegistro extends InterfaceRegistro

Se declaran tres atributos, como se explic en el captulo 5. La variable de tipo Connection se utiliza para hacer la conexin a la base dedatos, la variable de tipo Statement se utiliza para enviar la llamada de SQL a la base de datos, y la variable de tipo ResultSet para obtener los resultadas de la llamada a la base de datos.
private Connection con; private Statement stmt; private ResultSet rs;

El constructor de la clase revisa mediante revisarDriverSun que exista la biblioteca con los drivers necesarios. Si estos existen se solicita abrir la conexin mediante la llamada abrirConexion. Los parmetros enviados a esta ltima llamada, en nuestro caso, son el nombre de la base de datos para poder identificarla en el

Weitzenfeld: Captulo 9

23

sistema (ver Apndice con ejemplo de cmo configurar este nombre externamente), el login y password si es que estos han sido habilitados. Para una aplicacin de un slo usuario se puede abrir la conexin a la base de datos al inicio de la aplicacin, como lo estamos haciendo en nuestro ejemplo, para luego cerrarla al finalizar la aplicacin. En el caso de aplicaciones con mltiples usuarios donde pueden existir accesos concurrentes a la base de datos, estas conexiones deben hacerse de manera dinmica, abriendo y cerrando las conexiones cada vez que sea haga una solicitud a la base de datos, de lo contrario se saturaran rpidamente las posibles conexiones a la base de datos.
public InterfaceBaseDatosRegistro() { if (checkDriverSun() == 0) abrirConexion("jdbc:odbc:reservaciones", "alfredo", "ITAM"); }

El mtodo revisarDriverSun revisa que existan las bibliotecas adecuadas.

private int revisarDriverSun() { try { Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver"); } catch (ClassNotFoundException ex) { return -1; } return 0; }

El mtodo abrirConexion hace la conexin a la base de datos, algo que fue explicado anteriormente en el Captulo 5.
private void abrirConexion(String url,String log,String pass) { try { con = DriverManager.getConnection (url, log, pass); stmt = con.createStatement(); } catch (SQLException ex) { ... } }

Como parte de los contratos 1 y 2, Registrar Usuario y Registrar Tarjeta, respectivamente, definimos un solo conjunto de mtodos tomando como parmetro la superclase Datos, en lugar de los tipos especializados. El mtodo crearRegistro se encarga de insertar nuevos registros a la base de datos, el cual se muestra a continuacin.
public boolean crearRegistro(Datos reg) { String regname = getClassName(reg); String textsql = reg.serializarSQLinsert(); String querysql = "INSERT INTO " + regname + " " + textsql; return actualizarRecordSetRegistro(querysql); }

El mtodo recibe un registro, reg, del cual obtiene el nombre de su clase, cuyo nombre deber corresponder al nombre de la tabla correspondiente en la base de datos.
String regname = getClassName(reg);

Dado que la llamada a la base de datos se hace mediante una llamada en SQL, es necesario generar esta llamada como cadena. Aprovechamos que todas las clases entidad heredan de Datos para especificar un mtodo serializarSQLinsert a nivel de la superclase, que se encargue de generar el formato de texto deseado por SQL. La llamada es la siguiente,
String textsql = reg.serializarSQLinsert();

Por ejemplo, el texto devuelto por serializarSQLinsert a partir de un nuevo registro de usuario sera similar al siguiente:

Weitzenfeld: Captulo 9

24

(login, password, rpassword, nombre, apellido, direccion, colonia, ciudad, pais, CP, telCasa, telOficina, fax, email) VALUES ('alfredo', 'awr', 'awr', 'Alfredo', 'Weitzenfeld', 'Ro Hondo #1', 'San Angel Tizapn', 'Mxico DF', 'Mxico', '01000', '56284000', '56284000 x3614', '56162211', 'alfredo@itam.mx')

Una vez obtenido el texto con los datos de la llamada, se prosigue a componer la llamada completa,
String querysql = "INSERT INTO " + regname + " " + textsql;

En este caso el nombre de la tabla ser RegistroUsuario, similar al de la clase, y se formara la llamada de SQL completa,
INSERT INTO RegistroUsuario (login, password, rpassword, nombre, apellido, direccion, colonia, ciudad, pais, CP, telCasa, telOficina, fax, email) VALUES ('alfredo', 'awr', 'awr', 'Alfredo', 'Weitzenfeld', 'Ro Hondo #1', 'San Angel Tizapn', 'Mxico DF', 'Mxico', '01000', '56284000', '56284000 x3614', '56162211', 'alfredo@itam.mx')

El mtodo serializarSQLinsert se define en la clase Datos y no es complicado, simplemente toma los nombres y valores de los atributos para generar la lista de textos, como se muestra a continuacin,
public String serializarSQLinsert() { String serializa0 = ""; String serializa1 = ""; for (int i = 0; i < campos[1].size(); i++) { if (i > 0) { serializa0 = serializa0 + ", "; serializa1 = serializa1 + ", "; } serializa0 = serializa0 + campos[0].elementAt(i); serializa1 = serializa1 + "'" + campos[1].elementAt(i) + "'"; } return "(" + serializa0 + ") VALUES (" + serializa1 + ")"; }

El mtodo genera una cadena de texto serializa0 con los nombres de los atributos divididos por comas, y otra cadena de texto, serializa1, con los valores para lso atributos, tambin separados por comas. En el caso de valores de texto, como en nuestro ejemplo, estos valores son limitados por comillas sencillas. Finalmente, la llamada actualizarRecordSetRegistro hace la propia llamada a la base de datos.
private boolean actualizarRecordSetRegistro(String query) { try { int n = stmt.executeUpdate (query); return true; } catch (SQLException ex) { ... } return false; }

Este mtodo consiste principalmente de la llamada stmt.executeUpdate la cual recibe el query en forma de String y devuelve un entero correspondiente al nmero de rcords que fueron insertados o actualizados correctamente. El mtodo para actualizar informacin actualizarRegistro de cierta tabla es muy similar al anterior, con la diferencia que se basa en un dato existente.
public boolean actualizarRegistro(Datos reg) { String log = reg.leerValor(0); String regname = getClassName(reg); String textsql = reg.serializarSQL(); String str = "UPDATE " + regname + " SET " + textsql + " WHERE Login = '" + log + "';"; return actualizarRecordSetRegistro(str); }

El mtodo recibe un registro, reg, del cual obtiene el nombre de su clase, cuyo nombre deber corresponder nuevamente al nombre de la tabla correspondiente en la base de datos. Se generar nuevamente una llamada en SQL, slo que algo diferente de la anterior. Nuevamente aprovechamos que todas las clases entidad heredan de Datos

Weitzenfeld: Captulo 9

25

para especificar un mtodo serializarSQL a nivel de la superclase, que se encargue de generar el formato de texto deseado por SQL. La llamada es la siguiente,
String textsql = reg.serializarSQL ();

Por ejemplo, el texto devuelto por serializarSQL a partir de un nuevo registro de usuario sera similar al siguiente:
login = 'alfredo', password = 'awr', nombre = 'Alfredo', apellido = 'Weitzenfeld', direccion = 'Ro Hondo #1', colonia = 'San Angel Tizapn', ciudad = 'Mxico DF', pais = 'Mxico', CP = '01000', telCasa = '56284000', telOficina = '56284000 x3614', fax = '56162211', email = 'alfredo@itam.mx'

Una vez obtenido el texto con los datos de la llamada, se prosigue a componer la llamada completa,
String str = "UPDATE " + regname + " SET " + textsql + " WHERE Login = '" + log + "';";

En este caso el nombre de la tabla ser RegistroUsuario, similar al de la clase, y se formara la llamada de SQL completa,
UPDATE RegistroUsuario SET login = 'alfredo', password = 'awr', nombre = 'Alfredo', apellido = 'Weitzenfeld', direccion = 'Ro Hondo #1', colonia = 'San Angel Tizapn', ciudad = 'Mxico DF', pais = 'Mxico', CP = '01000', telCasa = '56284000', telOficina = '56284000 x3614', fax = '56162211', email = 'alfredo@itam.mx' WHERE login = 'alfredo'

El mtodo serializarSQL se implementa en la clase Datos de manera muy similar al mtodo serializarSQLinsert.
public String serializarSQL() { String serializa = ""; for (int i = 0; i < campos[1].size(); i++) { if (i > 0) serializa = serializa + ", "; serializa = serializa + campos[0].elementAt(i) + " = " + "'" + campos[1].elementAt(i) + "'"; } return serializa; }

A diferencia de serializarSQLinsertar, mostramos un formato distinto donde los nombres de los atributos van inmediatamente seguidos por sus valores, por lo cual una sola cadena de texto ser suficiente. La llamada final es al mtodo actualizarRecordSetRegistro de manera similar al mtodo anterior de crearRegistro. El mtodo eliminarRegistro es ms sencillo que los anteriores, ya que no requiere de ninguna serializacin de datos.
public boolean eliminarRegistro(Datos reg) { String log = reg.leerValor(0); String regname = getClassName(reg); String str = "DELETE FROM " + regname + " WHERE Login = '" + log + "';"; return actualizarRecordSetRegistro(str); }

Se obtiene el login del usuario mediante reg.leerValor(0), el cual es luego utilizado para generar la eliminacin del registro.
String str = "DELETE FROM " + regname + " WHERE Login = '" + log + "';";

Un ejemplo de la cadena para SQL sera,

DELETE FROM RegistroUsuario WHERE Login = 'alfredo'

La llamada a actualizarRecordSetRegistro es similar a los mtodos anteriores. El mtodo validarRegistro se encarga de validar al usuario y al mismo tiempo obtener un registro.

Weitzenfeld: Captulo 9

26

public boolean validarRegistro(Datos reg,String log, String pass) { String regname = getClassName(reg); String querysql = "SELECT * FROM " + regname + " WHERE (login = '" + log + "') AND (password = '" + pass + "')"; return leerRecordSetRegistro(querysql,reg); }

Se obtiene el nombre de la clase correspondiente a la tabla deseada para luego generar la llamada con un query, como por ejemplo,
SELECT * FROM RegistroUsuario WHERE (login = 'alfredo' AND password = 'awr')

Una vez generada la llamada de SQL, el resultado se se llama al mtodo leerRecordSetRegistro, el cual se muestra a continuacin,
private boolean leerRecordSetRegistro(String query,Datos datos) { ResultSetMetaData rsmd; String str; try { rs = stmt.executeQuery(query); rsmd = rs.getMetaData(); if (rs != null && rs.next()) { for (int i = 1; i <= rsmd.getColumnCount(); i++) { str = rs.getString(i); datos.escribirValor(i-1,str); } return true; } } catch (SQLException ex) { ... } return false; }

A diferencia de las dems llamadas anteriroes, que utilizan un executeUpdate, la consulta utiliza un executeQuery, la cual devuelve una lista de objetos, referida por rs y de tipo ResultSet. Si el valor al cual se refiere rs fuese nulo, esto significara que no se encontr ningn objeto correspondiente a la bsqueda recin hecha. La informacin meta del objeto rs puede obtenerse mediante la llamada rs.getMetaData() para obtener, por ejemplo, el nmero de columnas definidas en la tabla correspondiente a rs y a su vez correspondiente a los atributos del objeto de tipo Datos. Los propios datos son obtenidos a travs de la llamada rs.next(), la cual obtiene el siguiente dato en la lista de datos. Si se contina haciendo llamadas similares se obtendra datos adicionales en la lista, si estos existen. Por lo tanto, la llamada puede ponerse dentro de un while en lugar de un if, en el caso de mltiples datos. Dentro del ciclo for se obtiene cada atributo delo objeto mediante,
str = rs.getString(i);

Este valor, en nuestro caso una cadena, es luego escrita al propio objeto de tipo Datos mediante,
datos.escribirValor(i-1,str);

En el caso de mltiples objetos que se obtuvieran de la consulta, ser necesario tener acceso o instanciar mltiples objetos de tipo Datos, en lugar del actualmente nico objeto llamado datos. El mtodo para obtener informacin obtenerRegistro de cierta tabla es similar al anterior aunque ms sencillo ya que no incluye la validacin de la contrasea pero s la informacin sobre el usuario, como se muestra a continuacin.
public boolean obtenerRegistro(Datos reg,String log) { String regname = getClassName(reg); String querysql = "SELECT * FROM " + regname + " WHERE (login = '" + log + "')"; return leerRecordSetRegistro(querysql,reg); }

A continuacin describimos la clase InterfaceArchivoRegistro, como se muestra en la Tabla 9.13. Clase: InterfaceArchivoRegistro

Weitzenfeld: Captulo 9

27

Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclase: Subclase: Atributos: Contratos 1. Registrar Usuario crearRegistro(RegistroUsuario) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario obtenerRegistro(RegistroUsuario) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario actualizarRegistro(RegistroUsuario) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario eliminarRegistro(RegistroUsuario) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario validarRegistro(String, String) devuelve bolean ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta obtenerRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta actualizarRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void ArchivoRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 9.13. Tarjeta para la clase InterfaceArchivoRegistro 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. La clase InterfaceArchivoRegistro hereda de la superclase InterfaceRegistro.
public class InterfaceArchivoRegistro extends InterfaceRegistro

Definimos un nmero de atributos privados, como son la direccin de la ubicacin de los archivos, junto con varaibles temporales que sern descritas ms adelante.
private private private private private private String path = "reservaciones/baseDatos"; Datos reg; String regname; File freg, ftar; Vector archivoRegistro; ArchivoRegistro ar;

El constructor se sencarga de inicializar la leda de los archivos. Aqu haremos elgo que no es muy eficiente, pero en el caso de archivos pequeos no significa gran costo. Nos referimso al hecho de leer todos los archivos completos a

Weitzenfeld: Captulo 9

28

memoria para administrar la informacin ms fcilmente. Recurdese que esto sera prohibitivo en el caso de grandes archivos, lo cual habra que leer en secciones limitadas segn las necesidades particulares del momento. En este caso, dado que se trata de dos archivos relacionados con registro, RegistroUsuario.dat y RegistroTarjeta.dat, correspondiente a las dos tablas anterioremente descritas, lo que haremos ser leerlos inicialmente a memoria, como se describe continuacin.
public InterfaceArchivoRegistro() { archivoRegistro = new Vector(); reg = new RegistroUsuario(); regname = getClassName(reg); ar = new ArchivoRegistro(path,reg,regname); archivoRegistro.addElement(ar); reg = new RegistroTarjeta(); regname = getClassName(reg); ar = new ArchivoRegistro(path,reg,regname); archivoRegistro.addElement(ar); }

Al prinicpio, instanciamos un objeto archivoRegistro de tipo Vector, donde guardaremos objetos de tipo ArchivoRegistro, cada uno de ellos correspondiente a un tipo de datos de registro. A continuacin instanciamos un objeto de tipo RegistroUsuario y obtenemos el nombre de la clase, como le hicimos anteriormente. Hecho esto, instanciamos el propio objeto ArchivoRegistro, donde en el caso de un RegistroUsuario, los datos se veran como a continuacin,
ar = new ArchivoRegistro("reservaciones/baseDatos",reg,"RegistroUsuario");

Este mtodo lee del archivo y carga sus contenidos a memoria como veremos ms adelante cuando describamos esta clase. Por cada archivo que se lee, agregamos una referencia al vector archivoRegistro. Hacemos lo mismo para el archivo que guarda informacin de RegistroTarjeta. El mtodo obtenerRegistro es el encargado de obtener datos sobre un usuario. Esto se hace obteniendo primero el nombre de la clase, como se hizo enteriormente.
public boolean obtenerRegistro(Datos reg, String log) { String regname = getClassName(reg); for (int i = 0; i < archivoRegistro.size(); i++) { ar = (ArchivoRegistro) archivoRegistro.elementAt(i); if (ar != null && regname.equals(ar.getName()) == true) return ar.leerRegistro(reg, log); } return false; }

Se hace una bsqueda de los diferentes archivos leidos en memoria dependiendo del tipo de informacin que se busca. El ciclo del for pasa por todos estos objetos, dos en nuestro caso (RegistroUsuario y RegistroTarjeta) y compara su nombre con el tipo deseado,
if (ar != null && regname.equals(ar.getName()) == true)

Una vez que concuerdan el nombre de la clase con el nombre del tipo de archivo en memoria, se copia los datos del archivo en memoria a los del registro meidante la llamada al mtodo leerRegistro el cual ser descrito ms adelante, el cual es llamado de la siguiente forma,
return ar.leerRegistro(reg, log);

El mtodo crearRegistro, es similar al anterior, encargndose de primero buscar el archivo correcto para luego hacer la llamada al archivoRegistro correcto.
public void crearRegistro(Datos reg) { String regname = getClassName(reg); for (int i = 0; i < archivoRegistro.size(); i++) { ar = (ArchivoRegistro) archivoRegistro.elementAt(i); if (ar != null && regname.equals(ar.getName()) == true) ar.crearRegistro(reg); } }

El mtodo crearRegistro hace una llamada interna al mtodo crearRegistro de la clase ArchivoRegistro.

Weitzenfeld: Captulo 9

29

De manera similar , el mtodo actualizarRegistro hace una llamada al mtodo actualizarRegistro del ArchivoRegistro correspondiente.
public void actualizarRegistro(Datos reg) { String regname = getClassName(reg); for (int i = 0; i < archivoRegistro.size(); i++) { ar = (ArchivoRegistro) archivoRegistro.elementAt(i); if (ar != null && regname.equals(ar.getName()) == true) ar.actualizarRegistro(reg); } }

De manera similar eliminarRegistro se encarga de hacer la llamada adecuada al ArchivoRegistro.

public void eliminarRegistro(Datos reg) { String regname = getClassName(reg); for (int i = 0; i < archivoRegistro.size(); i++) { ar = (ArchivoRegistro) archivoRegistro.elementAt(i); if (ar != null && regname.equals(ar.getName()) == true) ar.eliminarRegistro(reg); } }

Finalmente, el mtodo validarRegistro compara los valores del usuario a travs del mtodo del mismo nombre en la clase ArchivoRegistro.
public boolean validarRegistro(Datos reg, String log, String pass) { String regname = getClassName(reg); for (int i = 0; i < archivoRegistro.size(); i++) { ar = (ArchivoRegistro) archivoRegistro.elementAt(i); if (ar != null && regname.equals(ar.getName()) == true) return ar.validarRegistro(reg, log, pass); } return false; }

La clase ArchivoRegistro de se muestra en la Tabla 9.14. Clase: ArchivoRegistro Descripcin: 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. Mdulo: Registro.InterfaceDB Estereotipo: Borde Propiedades: Concreta Superclases: Subclases: Atributos: Contratos 1. Registrar Usuario crearRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroUsuario obtenerRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroUsuario actualizarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroUsuario eliminarRegistro(RegistroUsuario) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroUsuario

Weitzenfeld: Captulo 9

30

validarRegistro(String, String) devuelve bolean BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la validacin de un usuario 2. Registrar Tarjeta crearRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la creacin de un nuevo RegistroTarjeta obtenerRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la obtencin de un RegistroTarjeta actualizarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la actualizacin de un RegistroTarjeta eliminarRegistro(RegistroTarjeta) devuelve void BaseDatosRegistro Mtodo encargado de solicitar a la BaseDatosRegistro la eliminacin de un RegistroTarjeta Tabla 9.14. Tarjeta para la clase InterfaceArchivoRegistro con responsabilidades, colaboraciones, jerarquas, contratos, protocolos, atributos y algoritmos para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. La clase ArchivoRegistro se muestra a continuacin,
public class ArchivoRegistro

Definimos un nmero de atributos privados, entre los cuales la listaRegistro guarda la lista de todos los rcords del archivo leido, uan referencia al archivo, incluyendo su nombre, junto con otras variables temporales.
private private private private private private Vector listaRegistro; File freg; Datos registro; Class creg; String name; String filename;

Dado que cada ArchivoRegistro se encarga de un solo archivo, aprovechamos esta clase para hacer la inicialziacin correspondiente. Leemos el nombre de la clase classname para obtener el nombre del archivo, al cual agregaremos la terminacin dat. Se inicializa la listaRegistro, la referencia al archivo mediante freg, el cual se obtiene a travs del dirname y filename. Finalmente hacemos la propia lectura de los archivos mediante la llamada inicializarRegistrosArchivo.
public ArchivoRegistro(String dirname, Datos reg, String classname) { creg = reg.getClass(); name = classname; filename = classname + ".dat"; listaRegistro = new Vector(); freg = new File(dirname,filename); inicializarRegistrosArchivo(); }

En el mtodo inicializarRegistrosArchivo hacemos la lectura de los registros mediante la obtencin de un BufferedReader a partir de la referencia del archivo freq. La variable is junto con la listaRegistro, hasta el momento vaca, son enviados como parmetros al mtodo leerRegistrosArchivo. Una vez ledos los registro se cierra el archivo.

Weitzenfeld: Captulo 9

31

private void inicializarRegistrosArchivo() { try { BufferedReader is = new BufferedReader(new FileReader(freg)); leerRegistrosArchivo(listaRegistro,is); is.close(); } catch(IOException e) { ... } }

El mtodo leerRegistrosArchivo se encarga de hacer la propia lectura, algo que se explic anteriormente en el Captulo 5.
private void leerRegistrosArchivo(Vector vectorDatos, BufferedReader is) throws IOException { String s = is.readLine(); Integer ns = Integer.valueOf(s); int n = ns.intValue(); for (int i = 0; i < n; i++) { try { registro = (Datos) creg.newInstance(); } catch (Exception ex){ ... } s = is.readLine(); StringTokenizer t = new StringTokenizer(s, "|"); for (int j = 0; j < registro.numeroAtributos(); j++) { String val = t.nextToken(); registro.escribirValor(j,val); } vectorDatos.addElement(registro); } }

Antes de explicar la lectura, mostramos un ejemplo del archivo correspondiente al RegistroUsuario,

2 alfredo|awr |Alfredo|Weitzenfeld|Rio Hondo #1|San Tizapan|Mexico|MEXICO|01000|6284000|6284000 x3614|6162211|alfredo@itam.mx| reservas|awr |Sistema|Reservaciones|Rio Hondo #1|San Tizapan|Mexico|MEXICO|01000|6284000|6284000 x3614|6162211|alfredo@itam.mx| Angel Angel

La primera lnea del archivo especifica el nmero de registros guardados en el archivo. De manera similar, se muestra un ejemplo de archivo correspondiente al RegistroTarjeta.
2 alfredo|Alfredo Weitzenfeld|123456789|MasterCard|01/05| reservas|Alfredo Weitzenfeld|987654321|Visa|02/4|

En este caso, cada registro de usuario cuenta con un registro de tarjeta correspondiente. Ambos tipos de archivos son procesados de la siguiente forma,
String s = is.readLine(); Integer ns = Integer.valueOf(s); int n = ns.intValue();

Las ltimas dos lneas convierten la cadena 2 referida por s a un nmero entrero. Posteriormente se hace un ciclo for que ejecutar por el nmero de registros que hayan, y en cada ciclo instanciar un nuevo registro donde guardar los datos,
registro = (Datos) creg.newInstance();

Hecho esto, se continuar con la lectura de cada registro mediante,

Weitzenfeld: Captulo 9

32

s = is.readLine();

Como se puede notar, en el archivo se separan los diversos campos mediante | (lneas verticales). Para ello definimos un string tokenizer en Java de la siguiente forma,
StringTokenizer t = new StringTokenizer(s, "|");

Dentro del ciclo for se van leyendo las diversas especificadas entre las lneas verticales mediante,
String val = t.nextToken();

El valor obtenido, val, es luego copiado al registro mediante,

registro.escribirValor(j,val);

Dado que pueden haber mltiples registros (en nuestro caso ejemplo haban dos), se prosigue guardando el registro obtenido en el vector de datos,
vectorDatos.addElement(registro);

A continuacin escribimos los mtodos que dan servicio a los contratos con nombre similar en la clase InterfaceArchivoRegistro. Comenzamos con leerRegistro encargado de leer a un registro temporal reg los datos guardados en memoria correspondiente al usuario especificado por log, como se muestra a continuacin,
public boolean leerRegistro(Datos reg, String log) { for (int i = 0; i < listaRegistro.size(); i++) { Datos datos = (Datos) listaRegistro.elementAt(i); if (log.equals(datos.leerValor(0))) { for (int j = 0; j < datos.numeroAtributos(); j++) reg.escribirValor(j,datos.leerValor(j)); return true; } } return false; }

El mtodo revisa todos los elementos de la listaRegistro hasta obtener un registro cuyo nombre corresponda al especificado en log. Una vez encontrado el registro, los datos de este son copiados al registro, especificado por reg, mediante la llamada escribirValor. El mtodo actualizarRegistro se encarga de recibir un dato recin modificado y cambiarlo primero en la lista de registros en memoria para luego hacer la modificacin correspondiente del archivo de registro.
public void actualizarRegistro(Datos reg) { int indice = leerIndiceRegistro(reg.leerValor(0)); if (indice != -1) { listaRegistro.setElementAt(reg,indice); actualizarArchivoRegistro(); } }

El mtodo primero revisa que exista el registro correspondiente en memoria mediante la llamada,
int indice = leerIndiceRegistro(reg.leerValor(0));

Una vez revisado que exista el registro mediante un ndice correspondiente, la listaRegistro se actualzia con el nuevo registro,
listaRegistro.setElementAt(reg,indice);

Finalmente, se actualiza el archivo correspondiente mediante,

actualizarArchivoRegistro();

El mtodo leerIndiceRegistro obtiene un registro por nombre, regname, y devuelve el registro cuyo nombre corresponda al solicitado. Una vez encontrado el registro se devuelve su ndice.

Weitzenfeld: Captulo 9

33

private int leerIndiceRegistro(String regname) { for (int i = 0; i < listaRegistro.size(); i++) { registro = (Datos) listaRegistro.elementAt(i); if (regname.equals(registro.leerValor(0)) == true) return i; } return -1; }

El mtodo actualizarArchivoRegistro es el opuesto a leerArchivoRegistro. En lugar de leer un archivo, el archivo se sobrescribe. Esto se hace cada vez que exista una modificacin en algn registro en memoria. Este mtodo llama al mtodo escribirDatos.
private void actualizarArchivoRegistro() { try { BufferedWriter os = new BufferedWriter(new FileWriter(freg)); escribirDatos(listaRegistro, os); os.close(); } catch(IOException e) { ... } }

El mtodo escribirDatos es el contrario de leerDatos anteriormente descrito.

private void escribirDatos(Vector vectorDatos, BufferedWriter os) throws IOException { int num = vectorDatos.size(); String numStr = String.valueOf(num); os.write(numStr); os.newLine(); for (int i = 0; i < num; i++) { Datos datos = (Datos) vectorDatos.elementAt(i); for (int j = 0; j < datos.numeroAtributos(); j++) { String str = datos.leerValor(j); os.write(str+"|"); } os.newLine(); } }

Se lee el tamao del vector de registros,

int num = vectorDatos.size();

Este nmero se convierte a una cadena,

String numStr = String.valueOf(num);

La cadena se escribe como una lnea completa en el archivo,

os.write(numStr); os.newLine();

A continuacin se obitenen los datos del registro,

Datos datos = (Datos) vectorDatos.elementAt(i);

Estos datos se copian uno por uno al archivo separndolos con una lnea vertical,
String str = datos.leerValor(j); os.write(str+"|");

Finalmente se pasa a la siguiente lnea para continuar con otro registro como parte del ciclo for,
os.newLine();

El mtodo eliminarRegistro es muy similar a actualizarRegistro, con la diferencia de eliminar primero el registro de la lista para luego actualziar el archivo correspondiente, como se muestra a continuacin.

Weitzenfeld: Captulo 9

34

public void eliminarRegistro(Datos reg) { int indice = leerIndiceRegistro(reg.leerValor(0)); if (indice != -1) { listaRegistro.removeElementAt(indice); actualizarArchivoRegistro(); } }

El mtodo validarRegistro se encarga de leer el registro de la memoria segn el log especificado, mediante la llamada leerRegistro, para luego comparar si el pass corresponde, como se muestra a continuacin.
public boolean validarRegistro(Datos reg, String log, String pass) { if (leerRegistro(reg,log) != false && reg != null) { String preg = reg.leerValor(1); if (pass.equals(preg)) return true; } return false; }

Servicios La tarjeta de clase para la clase ManejadorServicio se muestra en la Tabla 9.15. Clase: ManejadorServicio Descripcin: 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. Mdulo: Servicios Estereotipo: Control Propiedades: Concreta Superclase: Manejador Subclase: Contratos 1. Manejar Evento manejarEvento(Evento) devuelve void Mtodo sobrescrito de la clase Manejador, encargado de recibir eventos del sistema de ventanas a travs de la InterfaceUsuario. 2. Ofrecer Servicio ofrecerServicio() devuelve void Mtodo encargado de hacer solicitudes de consultar, reservar y administracin de registros Responsablidades Privadas registrar() devuelve void SubsistemaRegistro (2) Mtodo encargado de hacer la solicitud de administracin de registros al SubsistemaRegistro Tabla 9.15. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas y protocolos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta. La clase ManejadorServicio se define de la siguiente manera,
public class ManejadorServicio extends Manejador

De manera similar a los dems manejadores, la clase ManejadorServicio debe manejar los siguientes eventos de usuario correspondientes al contrato 1 de Manejar Evento,

Weitzenfeld: Captulo 9

35

// Contrato 1: Manejar Evento public void manejarEvento(String str) { if (str.equals("Consultar Informacion")) consultar(); else if (str.equals("Hacer Reservacion")) reservar(); else if (str.equals("Obtener Registro")) registrar(); else manejarEventosAdicionales(str); }

No describiremos aqu el manejo de consultar ni reservar, aunque si el de registrar, como se puede ver a continuacin,
private void registrar() { if (mru == null) mru = new ManejadorRegistroUsuario(this,interfaceUsuario); mru.obtenerRegistroUsuario(); }

El mtodo registrar() se encarga de llamar al mtodo obtenerRegistroUsuario() perteneciente al contrato 2 de la clase RegistroUsuario. El contrato 2 Ofrecer Servicio se encarga de desplegar la PantallaServicio, como se muestra a continuacin,
// Contrato 2: Ofrecer Servicio public void ofrecerServicio() { desplegarPantalla(new PantallaServicio(interfaceUsuario,this)); }

La descripcin de la clase PantallaServicio se mantiene de manera similar a las dems pantallas. 9.2 Diagrama de Clases Una vez finalizada la especificacin de la programacin se procede a generar los diagramas de clase para el sistema completo. Este diagrama servir como parte del apoyo visual al proceso de programacin. A continuacin se muestran estos diagramas para el sistema de reservaciones de vuelo. InterfaceUsuario El diagrama de clases para las clases del mdulo InterfaceUsuario se muestran en la Figura 9.1.

Weitzenfeld: Captulo 9

36

InterfaceUsuario InterfaceUsuario() desplegarPantalla() actionPerformed() setManejador() windowClosed() windowDeiconified() windowIconified() windowActivated() windowDeactivated() windowOpened() windowClosing()

Pantalla Pantalla() desplegarPantalla() inicializarPantalla() borrarPantalla() agregarBotonesSalir() agregarBotonesServiciosSalir() crearPantalla() getManejador() leerTexto() leerElementos() escribirElementos() #pantalla

-pantalla

-interfaceUsuario

#interfaceUsuario

-manejador

-manejador Manejador
(f ro m pri nci pal)

db_flag : boolean Manejador() Manejador(m : M anej ador, ui : reservac iones .interfaceUsuario. Int erfaceUsuario) manejarEvento(st r : St ring) : void getM anej adorServicio() : reservaciones.s ervicios.ManejadorServicio getM anej adorRegist roUsuario() : reservaciones.registro.us uario.Manej adorRegist roUs uario setM anej adorServicio(m : reservaciones.servicios.ManejadorServicio) : void setM anej adorRegist roUsuario(m : reservaciones. registro.usuario.ManejadorRegis troUsuario) : void setPant alla(p : reservaciones. int erfaceUsuario.Pant alla) : void getPant alla() : reservaciones. interfac eUs uario.Pant alla manejarEventosAdicionales(str : S tring) : void ofrecerServicio() : void salir() : void desplegarPant alla(p : reservaciones.int erfaceUsuario.Pant alla) : void escribirE lement os(p : reservaciones. int erfaceUsuario.P ant alla, dat os : reservaciones.dominio.Dat os) : void leerElem ent os(p : res ervaciones.interfaceUsuario.Pantalla, datos : reservaciones.dominio.Datos) : void print(list a : j ava. util.V ector) : void

Figura 9.1. Diagrama de clases para las clases del mdulo InterfaceUsuario. Principal El diagrama de clases para las clases del mdulo Principal se muestran en la Figura 9.2.

Weitzenfeld: Captulo 9

37

Pantalla
(f rom interfaceUsuario )

-manejador Pantalla() des plegarPant alla() inicializarPantalla() borrarPant alla() agregarB otonesSalir() agregarB otonesServiciosSalir() crearPantalla() getM anejador() leerTexto() leerElementos() esc ribirElementos()

Manejador

#pantalla

-pantallaPrincipal

ManejadorPrincipal PantallaPrincipal PantallaPrincipal() crearPantalla() ManejadorPrincipal() manejarEvento(st r : String) : void desplegarPant allaPrincipal() : void crearRegistroUs uario() : void validarRegis troUsuario() : void main(args : String[ ]) : void

Figura 9.2. Diagrama de clases para las clases del mdulo Principal. Registro El mdulo de Registro se compone de los mdulos de Usuario, Tarjeta y InterfaceBD, como se muestran en las siguientes secciones. Usuario El diagrama de clases para las clases del mdulo Usuario se muestran en la Figura 9.3.
Pantalla
(from interfaceUsuario)

Manejador
(f rom pri ncipal)

Pantalla() desplegarPantalla() inicializarPantalla() borrarPantalla() agregarBotonesSalir() agregarBotonesServiciosSalir() crearPantalla() getManejador() leerTexto() leerElementos() escribirElementos()

#pantalla

-manejador

-pantallaCrearRegUsuario ManejadorRegistroUsuario ManejadorRegistroUsuario(m : reservaciones.principal.Manejador, ui : reserv aciones.interfaceUsuario.InterfaceUsuario) getInterfaceRegistro() : reserv aciones.registro.interfaceBD.InterfaceRegistro manejarEvento(str : String) : void crearRegistroUsuario() : void validarRegistroUsuario(log : String, pass : String) : boolean obtenerRegistroUsuario() : void insertarRegistroUsuario() : void actualizarRegistroUs uario() : void eliminarRegistroUsuario() : v oid registrarTarjeta() : void

-pantallaObtenerRegUsuario

PantallaRegUsuario PantallaRegUsuario() crearPantalla()

Datos
(from dominio)

PantallaCrearRegUsuario PantallaCrearRegUsuario() crearPantalla()

PantallaObtenerRegUsuario PantallaObtenerRegUsuario() crearPantalla() -registroUsuario RegistroUsuario RegistroUsuario()

Figura 9.3. Diagrama de clases para las clases del mdulo Usuario. Tarjeta El diagrama de clases para las clases del mdulo Tarjeta se muestran en la Figura 9.4.

Weitzenfeld: Captulo 9

38

Pantalla
(from interfaceUsuario)

-manejador

Manejador
(from principal)

Pantalla() #pantalla desplegarPantalla() inicializarPantalla() borrarPantalla() agregarBotonesSalir() -pantallaCrearRegTarjeta agregarBotonesServiciosSalir() crearPantalla() getManejador() leerTexto() leerElementos() escribirElementos() -pantallaObtenerRegTarjeta idRegistro : String

ManejadorRegistroTarjeta

PantallaRegTarjet a PantallaRegTarjeta() crearPantalla()

ManejadorRegistroTarjet a(m : reservaciones.principal.Manejador, ui : res ervaciones.interfaceUsuario. Interfac eUsuario) manejarEvent o(str : String) : void registrarTarj eta(log : St ring) : void crearRegistroTarjeta() : void obtenerRegistroTarjeta() : void ins ertarRegistroTarjeta() : void actualizarRegist roTarjeta() : void eliminarRegistroTarjeta() : void

Datos
(from dominio)

-registroTarjeta RegistroTarjeta PantallaCrearRegTarjeta PantallaCrearRegTarjeta() crearPantalla() PantallaObtenerRegTarjeta PantallaObtenerRegTarjeta() crearPantalla() RegistroTarjeta()

Figura 9.4. Diagrama de clases para las clases del mdulo Tarjeta. InterfaceBD El diagrama de clases para las clases del mdulo InterfaceBD se muestran en la Figura 9.5.
InterfaceRegistro fg : boolean obtenerRegistro(reg : reservaciones.dominio.Datos, log : String) : boolean crearRegistro(reg : reservaciones.dominio.Datos) : boolean actualizarRegistro(reg : reservaciones.dominio.Datos) : boolean eliminarRegistro(reg : reservaciones.dominio.Datos) : boolean validarRegistro(reg : reservaciones.dominio.Datos, log : String, pass : String) : boolean getClassName(reg : reservaciones.dominio.Datos) : String ArchivoRegistro() leerRegistro() crearRegistro() actualizarRegistro() eliminarRegistro() validarRegistro() inicializarRegistrosArchivo() leerRegistrosArchivo() actualizarArchivoRegistro() escribirDatos() leerIndiceRegistro() getName() -ar ArchivoRegistro name : String filename : String

InterfaceBaseDatosRegistro InterfaceBaseDatosRegistro() crearRegistro(reg : reservaciones.dominio.Datos) : boolean obtenerRegistro(reg : reservaciones.dominio.Datos, log : String) : boolean actualizarRegistro(reg : reservaciones.dominio.Datos) : boolean eliminarRegistro(reg : reservaciones.dominio.Datos) : boolean validarRegistro(reg : reservaciones.dominio.Datos, log : String, pass : String) : boolean leerRecordSetRegistro(query : String, datos : reservaciones.dominio.Datos) : boolean actualizarRecordSetRegistro(query : String) : boolean displayAllDataRegistro() : void displayAllDataTarjeta() : void displayRecordSet(query : String) : void dispResultSet(rs : java.sql.ResultSet) : void revisarDriverSun() : int revisarDriverMS() : int abrirConexion(url : String, log : String, pass : String) : void checkForWarning(warn : java.sql.SQLWarning) : boolean

InterfaceArchivoRegistro path : String = " reservac iones/baseDatos" regname : String InterfaceArc hivoRegis tro() obtenerRegistro(reg : reservaciones.dominio.Datos, log : S tring) : boolean crearRegistro(reg : reservaciones. dom inio. Datos) : boolean actualiz arRegistro(reg : res ervaciones.dominio.Dat os) : boolean eliminarRegistro(reg : reservaciones. dom inio.Datos) : boolean validarRegis tro(reg : reservaciones.dom inio. Datos, log : String, pass : St ring) : boolean

Figura 9.5. Diagrama de clases para las clases del mdulo InterfaceBD.

Implementacin

Weitzenfeld: Captulo 10

10 Modelo de Pruebas
Probar un producto es relativamente independiente de la metodologa de desarrollo utilizada para construirlo. Existen diversos tipos de pruebas aplicados durante las diferentes actividades del proceso de desarrollo. Estas pruebas requieren de tiempo y presupuesto adicional, pudiendo llegar a significar entre un 30% y un 50% del costo total de desarrollo. Por tal motivo, el modelo de pruebas debe ser planificado con anticipacin y de manera integral junto con el propio desarrollo del sistema. Es un error pensar que las pruebas son la ltima actividad del desarrollo ya que no se puede lograr software de alta calidad slo mediante pruebas finales y depuraciones. Las pruebas deben hacerse en paralelo al desarrollo del sistema, teniendo pruebas finales nicamente como certificacin final de la calidad del producto y no como la oportunidad para encontrar errores. Encontrar errores al final del desarrollo es bastante problemtico dado que requerir regresar a etapas anteriores para resolverlos. Se considera que "evitar defectos" es ms poderoso que "remover defectos". 10.1 Definicin de Conceptos Las siguiente definiciones de IEEE (1983) pueden utilizarse para definir ciertos conceptos conocidos de manera informal como bugs: ? ? Una falla (failure) ocurre cuando un programa no se comporta bien, siendo la falla una propiedad (estadstica) de un sistema en ejecucin. ? ? Una falta (fault) existe en el cdigo del programa, el cual si se presenta, puede ocasionar una falla (failure). No puede haber una falta si el programa no puede fallar (fail). ? ? Un error es una accin humana que resulta en que un software contenga una falta, por lo cual un error puede significar la inclusin de una falta en el programa, haciendo que el sistema falle. Un aspecto importante con los conceptos anteriores es que no se puede garantizar ni probar que un sistema jams falle, solo se puede demostrar que contiene faltas. En otras palabras, no encontrar faltas no significa que la prueba haya sido exitosa. Se debe considerar una prueba como exitosa slo si esta ha encontrado faltas. Sin embargo, pruebas exitosas significarn que no se ha desarrollado un buen sistema. Dada la dificultad de probar un sistema y de encontrar faltas, el encargado de encontrar las faltas en el cdigo es generalmente una persona distinta al desarrollador del sistema. Esto tambin significa un costo adicional en el desarrollo del sistema, por lo cual a veces slo se prueban las partes principales del sistema. Es un fenmeno muy conocido que cuando se corrigen las faltas detectadas, se introducen nuevas faltas en el sistema, requiriendo probar nuevamente todo el sistema completo, esperando que el nmero de faltas introducidas sea menor que el nmero anterior. Segn Levendel (1990), generalmente se introduce una nueva falta por cada tercera falta corregida. 10.2 Tipos de Pruebas Los tipos de pruebas se dividen de manera general en pruebas de verificacin y validacin. En el caso de la verificacin se revisa si el resultado corresponde a la especificacin del sistema, en otras palabras, si se est construyendo el sistema correctamente, algo por si slo no garantiza la satisfaccin de los clientes. En el caso de la validacin se revisa si el resultado es realmente lo que el cliente quera, en otras palabras, si se est construyendo el sistema correcto de manera que tanto la especificacin como el resultado sean los correctos. En este captulo nos concentraremos principalmente en la verificacin del sistema. La validacin del sistema debiera hacerse durante la especificacin inicial del sistema a travs de prototipos que deben ser aprobados por el cliente y que correspondan a la funcionalidad deseada. El sistema debe validarse continuamente durante el proceso de desarrollo del sistema de manera siempre corresponda con lo especificado. La validacin se basa en el modelo de casos de uso. Existen tambin diferentes tcnicas y niveles de pruebas que pueden aplicarse. Estas se describen en las siguientes secciones. Tcnicas de Pruebas Las tcnicas utilizadas para las pruebas son muy variadas incluyendo las siguientes: ? ? Prueba de Regresin tiene como propsito verificar el sistema luego de haber hecho cambios, por ejemplo despus de corregir una falta, de manera que se mantenga la funcionalidad especificada originalmente. ? ? Prueba de Operacin tiene como propsito verificar el sistema en operacin por un perodo largo de tiempo bajo condiciones normales de uso. Este tipo de prueba mide la confiabilidad (reliability) del sistema. ? ? Prueba de Escala Completa tiene como propsito verificar el sistema en su carga mxima asignando los parmetros a su valor lmite, interconectando el sistema con un mximo de equipos y usuarios simultneos. Un

Weitzenfeld: Captulo 10

?? ??

??

??

??

??

??

extremo de esto es la prueba de estrs (stressing) que significa que se prueba el sistema en los lmites extremos para ver que tanto aguanta y si ocurre algn tipo de falla. Prueba de Rendimiento (performance) o Prueba de Capacidad tiene como propsito medir la capacidad de procesamiento del sistema bajo diferentes cargas, incluyendo espacio de almacenamiento y utilizacin del CPU. Los valores medidos se comparan con los valores requeridos. Prueba de Sobrecarga tiene como propsito ver cmo se comporta el sistema cuando se le aplica una sobrecarga, ms all que de las pruebas de escala completa y rendimiento. Aunque no se puede esperar que el sistema soporte estas pruebas, este debiera ejecutar correctamente, sobrevivir a picos de carga, evitando que ocurra una catstrofe. Es siempre importante saber en que momento y de que manera cae el rendimiento del sistema. Prueba Negativa tiene como propsito medir el estrs del sistema en situaciones inesperadas, como casos de uso que normalmente no seran invocados simultneamente. El sistema se usa intencionalmente y sistemticamente de manera incorrecta. Este maltrato debe ser cuidadosamente planeado para probar aspectos especialmente crticos. Prueba Basada en Requisitos o Prueba de Casos de Uso tiene como propsito hacer pruebas basadas directamente en la especificacin de requisitos. Pueden utilizarse los mismos casos de uso originales como casos de prueba. Tambin pueden hacerse pruebas para verificar las especificaciones de rendimiento o de escala completa. Se busca verificar que el sistema final cumple con las especificaciones funcionales descritas por los casos de uso originales. Pruebas Ergonmicas tiene como propsito probar los aspectos ergonmicos del sistema, en otras palabras, las interfaces hombre-mquina en el caso de que estas existan. Por ejemplo, se prueba si las interfaces son consistentes con los casos de uso a los cuales corresponden o entre diferentes casos de uso, si los mens son lgicos y legibles, si los mensajes del sistema son visibles, si se puede entender los mensajes de falla, etc. Prueba de Documentacin de Usuario tiene como propsito probar la documentacin de usuario, incluyendo el manual de usuario y documentacin de mantenimiento y servicio. Se prueba que los manuales y comportamiento del sistema sean consistentes entre si, que los manuales sean legibles, que tengan una buena redaccin y en general que sean comprensibles. Prueba de Aceptacin o Prueba de Validacin tiene como propsito lograr una revisin final por parte de la organizacin que solicit el sistema, siendo esto a menudo la validacin del sistema. El sistema se prueba en su ambiente real por un perodo largo de tiempo. Cuando se termina la prueba, se toma la decisin si se acepta o no el producto. Este tipo de prueba es a veces conocida como prueba alfa. Si no existe un cliente particular que haya solicitado el sistema, por ejemplo en el caso de un producto de software de venta al pblico, a menudo se hace una prueba beta. Esto significa que antes de enviarlo al pblico en general, el producto es probado por clientes seleccionados que utilizan el sistema y reportan fallas experimentadas.

Nivel de Pruebas Existen principalmente tres niveles para la aplicacin de las diversas tcnicas de pruebas: ? ? Prueba de Unidad donde solamente una unidad es probada como tal, tpicamente una clase, paquete de servicio, o subsistema. ? ? Prueba de Integracin donde se verifica que las unidades trabajen juntas correctamente. Pruebas de unidad e integracin pueden ser hechas mediante casos de uso de pruebas, los cuales pueden ser aplicados a clases, paquetes de servicio, subsistemas y el sistema completo. ? ? Prueba de Sistema donde se prueba el sistema completo o la aplicacin como tal. Se toma el punto de vista del usuario final y los casos de uso de pruebas ejecutan acciones tpicas del usuario. Prueba de Unidad Una prueba de unidad es la prueba de ms bajo nivel. En un sistema tradicional una prueba de unidad es a menudo una prueba de procedimientos o subrutinas. En un sistema orientado a objetos, las pruebas de unidad se hacen a un nivel ms alto, a partir de las clases. Por lo tanto, una prueba de unidad en un sistema orientado a objetos es ms complejo que en sistemas estructurados, dado que los objetos involucran estados encapsulados que puede afectar el comportamiento y correccin de la unidad. Adems, aspectos como herencia y polimorfismo agregan complejidad adicional a las pruebas. Tradicionalmente una prueba de unidad consiste en una prueba estructural (o prueba de caja blanca), lo cual requiere conocer cmo la unidad est diseada internamente, y una prueba de especificacin (prueba de caja negra), basada slo en la especificacin del comportamiento externamente visible de la unidad. Normalmente ambas

Weitzenfeld: Captulo 10

pruebas son necesarias y se complementan entre si. Los sistemas orientados a objetos pueden utilizar estas pruebas y adems requerir pruebas basadas en estado, correspondiente al estado encapsulado del objeto y la interaccin de las operaciones. Como las pruebas estructurales dependen de la estructura del sistema, mientras que la prueba basada en estado y de especificacin puede afectar la estructura del sistema, es preferible hacer la prueba estructural al final. Si se encuentra una falta en cualquiera de las pruebas anteriores, se necesitara modificar de manera correspondiente el sistema, afectando la prueba estructural. Las pruebas son descritas con mayor detalle a continuacin y pudiendo seguirse en el orden descrito: ? ? Prueba de especificacin, o de caja negra, tiene como propsito verificar las relaciones de entrada y salida de una unidad. El objetivo es verificar qu hace la unidad, pero sin saber cmo lo hace. Se envan estmulos con diferentes parmetros como entrada y se comparan con las salidas esperadas. Se revisa que estos sean correctos, como en el caso de operaciones matemticas. Dado que las unidades se comunican mediante interfaces bien definidas, la prueba de especificacin es bastante directa. ? ? Prueba basada en estado verifica las interacciones entre operaciones de una clase segn cambios en los atributos de un objeto. No se puede ver a las operaciones de un objeto como aisladas e independientes de los valores de los atributos. Se debe hacer pruebas del objeto de acuerdo a su ciclo de vida. Esto es especialmente importante para objetos controlados por estado, descritos usando diagramas de transicin de estados. En la realidad es imposible revisar todas las posibles combinaciones de valores de atributos en combinacin con todos los posibles estmulos. Es suficiente revisar los estados identificados en los diagramas de transicin de estados de los objetos. Adicionalmente, algunas combinaciones particulares de atributos pueden ser de mayor inters que otras. Otras combinaciones se pueden considerar conjuntos de equivalencia (equivalence set) de comportamiento evitando revisiones adicionales. Por lo tanto, es deseable revisar valores particulares significativos para luego asignar un conjunto de equivalencias para cada grupo de valores relacionados. Por otro lado, algunas operaciones no afectan el estado, como son las operaciones puramente de lectura, por lo cual no necesitan ser consideradas en la prueba basada en estados. Las dems operaciones debern ejecutarse para todos los posibles estados iniciales. ? ? Prueba estructural tiene como propsito verificar que la estructura interna de la unidad sea correcta. Esta prueba se conoce tambin como prueba basada en programa o de caja blanca, dado que debe conocerse cmo est implementada internamente la unidad. Es deseable cubrir todas las posibles combinaciones de parmetros, valores de variables y flujos en el cdigo, de manera que todas las instrucciones se ejecuten. Para examinar la efectividad de los casos de prueba se debe medir la cobertura de prueba (coverage test) donde cada ruta en el cdigo sea cubierta o probada al menos una vez. La mayora de los problemas provienen de combinaciones de rutas inusuales como aquellas que involucran ciclos. Los casos de prueba se ilustran mediante diagramas de flujo (flowcharts). Prueba de Integracin Despus de haber probado todas las unidades, stas deben ser integradas en unidades ms grandes hasta generar el sistema completo. El propsito de la prueba de integracin es probar que las diferentes unidades estn trabajando juntas de manera apropiada. En la prueba de integracin se incluye la prueba de paquetes de servicio, casos de uso, subsistemas y el sistema completo. Durante las pruebas de combinacin de unidades, algo que se incrementa exponencialmente, se podr detectar fallas imposibles de detectar durante las pruebas de una sola unidad. No se debe comenzar la prueba de integracin hasta que las pruebas de unidad estn listas. La prueba de integracin se basa principalmente en la prueba de casos de uso, partiendo de los diagramas de interaccin, donde se pueden identificar los estmulos enviados entre el usuario y el sistema, y entre los objetos en el sistema. La prueba de casos de uso se divide en pruebas de curso bsico, cursos alterno y documentacin de usuario. Se prueba primero los flujos bsicos, los esenciales del sistema, probando luego los flujos alternos, correspondientes a flujos que ocurren de manera inusual como en el caso de manejo de excepciones. Los casos de uso que extienden o son incluidos en otros casos de uso se prueban despus de probar los casos de uso bsicos donde estos se insertan. Prueba de Sistema Las pruebas de casos de uso se hacen inicialmente de manera independiente, basadas en el modelo de requisitos. Despus de probar todos los casos de uso aislados, se prueba el sistema entero como uno solo. Se ejecutan varios casos de uso en paralelo y se somete el sistema a diferentes cargas. Las pruebas de sistema pueden involucrar pruebas de operacin, pruebas de escala completa, pruebas negativas, pruebas basadas en requisitos o casos de uso, y pruebas de documentacin de usuario.

Weitzenfeld: Captulo 10

10.3 Proceso de Pruebas El proceso de prueba involucra consideraciones similares al del propio proceso de desarrollo de software, incluyendo estrategias, actividades y mtodos los cuales deber ser aplicados de manera concurrente al proceso de desarrollo de software. En particular, las actividades de prueba abarcan los siguientes aspectos: planeacin, construccin y ejecucin. Por lo general, se mantiene una bitcora de prueba (test log) durante todo el proceso de prueba. Estrategia de Prueba Existen diversas estrategias para el proceso de pruebas, incluyendo el orden en que se van a hacer, la particin de equivalencias de pruebas que se van a aplicar y la posibilidad de automatizarlas. ? ? Orden de Pruebas tiene como propsito definir en qu momento y en qu orden se aplicarn las pruebas. Aunque las pruebas deben ser planeadas con anterioridad, las verificaciones tpicamente se aplican durante el diseo, implementacin y operacin del sistema. Existen dos enfoques generales para el orden en que se llevarn a cabo las pruebas: de arriba hacia abajo y de abajo hacia arriba. Este orden depende de gran manera de la estrategia de diseo ya que debe lograr una buena correspondencia con el proceso de desarrollo utilizado. Si se hace pruebas correspondientes a un diseo de arriba hacia abajo, entonces se desarrolla inicialmente las interfaces entre subsistemas, donde se busca probar los protocolos a alto nivel antes de ir a los niveles ms bajos. Si se hace un diseo de abajo hacia arriba se puede certificar primero las unidades de bajo nivel y luego las interfaces entre estas. Esta tcnica se aprovecha que una vez probadas las unidades se elimina la necesidad de crear servidores especializados para pruebas. En el de pruebas de arriba hacia a bajo, se necesitan servidores de pruebas especiales que simulen el ambiente alrededor de la unidad que se prueba. En el caso extremo se debe construir una estructura completa para simular todos los objetos del sistema que an no existen. Normalmente, es suficiente tener una base de pruebas que sea una magnitud de orden menor que lo que se est probando, como una clase de prueba por cada paquete de servicio (contratos), un contrato para cada subsistema, etc. ? ? Alcance de Pruebas tiene como propsito identificar el tipo, nmero y casos de pruebas que se aplicarn para revisar el sistema en sus diferentes aspectos. Si se considera que los tipos de pruebas son bastante amplios y bastante extensos, el objetivo es seleccionar un nmero pequeo pero razonable de casos de prueba dentro de un gran nmero de posibles pruebas donde la probabilidad de encontrar faltas sea alto. Se define la particin de equivalencias segn conjuntos equivalentes (equivalent set) de pruebas definiendo un grupo de condiciones donde el sistema o algn componente se comportar de manera similar para diferentes pruebas. La idea es escribir casos de prueba que cubran todos los conjuntos de equivalencia, teniendo un caso de prueba para cada conjunto de equivalencia. ? ? Automatizacin de Pruebas tiene como propsito reducir el esfuerzo y costo de las pruebas mediante la automatizacin del proceso o aspectos de l. Esto puede hacerse mediante programas de pruebas especiales asociados a un conjunto de datos de pruebas. El programa de prueba debe tomar conjuntos de datos de entrada y observar la respuesta del sistema, la cual puede guardarse directamente en un archivo de salida o comparado con alguna respuesta esperada. El objetivo es tener un programa de prueba los mas general e independiente posible de los datos de prueba, los cuales a su vez pudieran generarse automticamente. Para probar el sistema completo son necesarios diferentes programas de prueba. Cuando se desarrollan los programas y datos de prueba se deben utilizar las mismas tcnicas usadas para el desarrollo del sistema y deben desarrollarse en paralelo con el propio sistema. Los programas de prueba se consideran parte del sistema, pudindose usar para el mantenimiento del sistema, simplificando la tarea de buscar fallas y faltas cuando se haya instalado el sistema. Planeacin de la Prueba La planeacin de la prueba inicia con el establecimiento de las estrategias de pruebas, incluyendo consideraciones si la prueba se har automticamente o manualmente y si existen programas y datos de prueba que puedan ser usados o posiblemente modificados o desarrollados nuevamente. Se determina el alcance de las pruebas mediante conjuntos de equivalencia y se identifican los tipos de pruebas necesarios. Por lo general la planeacin se hace durante el modelo de anlisis luego de finalizar el modelo de requisitos. La prueba en si se disea hasta durante la propia etapa de diseo del sistema. Esta etapa de planeacin permite estimar los recursos requeridos, sirviendo como gua para la especificacin y ejecucin de la prueba. Cuando los recursos de prueba estn restringidos, cada caso de prueba debe maximizar la probabilidad estadstica para detectar fallas buscando primero las fallas mayores.

Weitzenfeld: Captulo 10

Construccin de la Prueba Una vez planificadas las pruebas, stas se deben construir disendolas a un nivel funcional donde se describa cada prueba y su propsito de manera general y detallada. Se describe exactamente cmo se deber ejecutar el caso de prueba de manera que personas no familiarizadas con la aplicacin, o incluso el sistema, puedan ejecutar el caso de prueba. En el caso ideal, las especificaciones del diseo de las pruebas deben servir tambin como las propias especificaciones de la prueba. Cada caso de prueba, con excepcin de las pruebas de unidad de ms bajo nivel, debe ser documentado. Las condiciones para la prueba deben ser especificadas, por ejemplo, si la prueba debe ser hecha en un ambiente de desarrollo o real, con qu software, hardware y equipo de prueba, y bajo qu versin del sistema. Se debe tambin describir cmo debe ejecutarse la prueba, en qu orden, cual es el resultado esperado y cules son los criterios para aprobar la prueba. Tambin se debe describen cmo preparar los reportes de prueba requeridos para documentar los resultados de la prueba. Si la documentacin del diseo del sistema est descrita como especificaciones, stas pueden ser usadas tambin como especificaciones de prueba. Una especificacin de prueba es tambin a menudo una especificacin de diseo. La etapa de diseo de pruebas tambin ayuda a encontrar problemas en el diseo del sistema e incluso faltas. En tal caso, stas deben ser comunicadas al diseador el cual debe corregir de manera adecuada para luego volver a aplicar las pruebas anteriores nuevamente. Por ejemplo, se puede tener como objetivo general detectar el mximo posible de faltas presentes en el sistema, por lo cual se puede tener como objetivo particular del diseo de pruebas minimizar el nmero de faltas por cada 1,000 lneas de cdigo, o algo similar. Ejecucin de la Prueba Se utiliza la especificacin del diseo de prueba y los reportes de prueba durante la ejecucin de las pruebas. La estrategia es probar en paralelo el mayor caso de pruebas posible. Se ejecutan las pruebas automticas y manuales de manera correspondiente, e indicando los resultados esperados. Si alguna prueba particular fallara, se interrumpe la prueba y se anota el resultado para luego analizar el defecto y corregirlo si es posible. Una vez corregido, se ejecuta la prueba nuevamente. Todas las pruebas son ponderadas segn su importancia, y se puede determinar si la prueba completa ha sido aprobada o no segn su resultado. Se analizan los resultados de la prueba completa y si se anota en los reportes de prueba, el resumen de la prueba, los recursos utilizados, los resultados individuales y si los resultados fueron aprobados o no. El reporte de la prueba debe tambin mostrar el resultado de cada prueba individual, recursos utilizadas y acciones tomadas. Si al ejecutar las pruebas se detectan fallas, el resultado de la prueba debe ser analizado y la razn para la falta identificada. La falta no tiene que ser por culpa del sistema, puede ser por otras causas, incluyendo si se hizo la prueba correctamente, si existe una falta en los datos de prueba o en el programa de prueba, si existe una falla causada por la base de prueba, o si el software del sistema se comporta de manera incorrecta. Si la falla no fue por causa del objeto en prueba, entonces se debe corregir y hacer la prueba nuevamente. Si la falla fue por causa del sistema, se busca identificar qu clases o paquetes de servicios deficientes deben ser devueltos al diseador. Se puede facilitar el proceso de deteccin de faltas si las unidades probadas ofrecen facilidades apropiadas, por ejemplo, contadores o bitcoras de faltas. 10.4 Pruebas para el Sistema de Reservaciones de Vuelos En lo que respecta al Sistema de Reservaciones de Vuelos desarrollado a lo largo del libro, nos limitaremos a verificar el sistema de acuerdo a la prueba de requisitos o casos de uso. Como objetivo de la prueba revisaremos que la funcionalidad implementada corresponda a los casos de uso correspondientes especificados durante el modelo de requisitos. A continuacin revisaremos los casos de uso principales, bsicos y de extensin, los cuales fueron descritos durante el diseo: Registrar Usuario y Registrar Tarjeta. Ntese que los casos de uso Validar Usuario y Ofrecer Servicios no los describimos de manera independiente ya que son inclusiones de los dems. Registrar Usuario Se prueban la secuencia ms importante del casos de uso Registrar Usuario: Crear Registro Usuario, Actualizar Registro Usuario y Eliminar Registro Usuario. Crear Registro Usuario La secuencia Crear Registro Usuario, se muestra a nivel funcional en la Figura 10.1.

Weitzenfeld: Captulo 10

: Usuario

: Sistema

: Base de Dat os Registros

1: "Registrar Por Primera Vez" 2: despl egarPantallaCrearRegUsuario 3: "Registrar" 4: crearRegis troUsuario 5: OK 6: desplegarPantallaObtenerRegUsuario 7: "Salir"

Figura 10.1 Diagrama de secuencia Crear Registro Usuario del caso de uso Registrar Usuario. La secuencia comienza con el usuario presionando el botn Registrarse por Primera Vez en la PantallaPrincipal (P-1), como se muestra en la Figura 10.2.

Weitzenfeld: Captulo 10

Figura 10.2 La secuencia Crear Registro Usuario comienza con el usuario oprimiendo el botn Registrarse por Primera Vez en la PantallaPrincipal (P-1). A continuacin el sistema presenta la PantallaCrearRegistroUsuario (P-3) la cual debe ser llenada por el usuario con datos de registro. Al finalizar la insercin de los datos el usuario debe presionar el botn Registrar, como se muestra en la Figura 10.3.

Weitzenfeld: Captulo 10

Figura 10.3. La secuencia Crear Registro Usuario contina con el usuario oprimiendo el botn Registrar en la PantallaCrearRegUsuario (P-3) una vez llenado los campos correspondientes. Se puede revisar en la Base de Datos Registro que los valores han sido creados e insertados correctamente a la base de datos, como se puede observar en la Figura 10.4.

Figura 10.4. Imagen de la Base de Datos de Registro mostrando el registro de usuario recin insertado. A continuacin el sistema despliega la PantallaObtenerRegUsuario (P-4), como se muestra en la Figura 10.5.

Weitzenfeld: Captulo 10

Figura 10.5. La secuencia Crear Registro Usuario contina con el despliegue de la PantallaObtenerRegUsuario (P4). Una vez desplegada esta pantalla, el usuario puede finalizar el caso de uso presionando del botn Salir. El usuario puede finalizar el caso de uso presionando el botn Salir en la PantallaObtenerRegUsuario (P-4). Actualizar Registro Usuario La secuencia Actualizar Registro Usuario, se muestra a nivel funcional en la Figura 10.6.

Weitzenfeld: Captulo 10

10

: Usuario

: Sistema

: Base de Datos Registros

1: "OK" 2: validarRegistroUsuario 3: OK 4: desplegarPantallaServicios

5: "Obtener Registro" 6: obtenerRegist roUsuario 7: OK 8: desplegarPantallaObtenerRegUsuario 9: "Actualizar" 10: actualizarRegistroUsuario 11: OK 12: desplegarPantallaObtenerRegUsuario 13: "S alir"

Figura 10.6 Diagrama de secuencias para Actualizar Registro Usuario del caso de uso Registrar Usuario. La secuencia comienza con el usuario presionando el botn OK en la PantallaPrincipal (P-1), como se muestra en la Figura 10.7.

Weitzenfeld: Captulo 10

11

Figura 10.7. La secuencia Actualziar Registro Usuario comienza con el usuario oprimiendo el botn OK en la PantallaPrincipal (P-1) luego de haber insertado los datos de login y password, weitzenfeld y alfredo respectivamente. Ntese que se despliega el password en la pantalla mediante caracteres de tipo . # A continuacin el sistema presenta la PantallaServicio (P-2). Para este caso de uso, la opcin de Obtener Registro es la apropiada, como se muestra en la Figura 10.8.

Weitzenfeld: Captulo 10

12

Figura 10.8. La secuencia Actualizar Registro Usuario contina con el usuario oprimiendo el botn Obtener Registro en la PantallaServicio (P-2). A continuacin el sistema despliega la PantallaObtenerRegUsuario (P-4). El usuario puede hacer las modificaciones deseadas, como cambios en el nmero de telfono de la oficina, para luego presionar el botn Actualizar, como se muestra en la Figura 10.9.

Weitzenfeld: Captulo 10

13

Figura 10.9. La secuencia Actualizar Registro Usuario contina con el usuario oprimiendo el botn Actualizar en la PantallaObtenerRegUsuario (P-4) una vez modificados los campos deseados, como el telfono de la oficina. El sistema vuelve a desplegar la PantallaObtenerRegUsuario (P-4) luego de proceder con la actualizacin anterior. Se puede revisar en la Base de Datos Registro que los valores han sido actualziados correctamente a la base de datos, como se puede observar en la Figura 10.10.

Figura 10.10. Imagen de la Base de Datos de Registro mostrando el registro de usuario modificados. El usuario puede finalizar el caso de uso presionando el botn Salir en esa misma pantalla, como se mostr anteriormente en la Figura 10.5. Eliminar Registro Usuario La secuencia Eliminar Registro Usuario, se muestra a nivel funcional en la Figura 10.11.

Weitzenfeld: Captulo 10

14

: Usuario

: Sistema

: Base de Datos Registros

1: "OK" 2: validarRegistroUsuario 3: OK 4: desplegarPantallaServicios

5: "Obtener Registro" 6: obtenerRegist roUsuario 7: OK 8: desplegarPantallaObtenerRegUsuario 9: "Eliminar" 10: eliminarRegistroUsuario 11: OK 12: desplegarPantallaCrearRegUsuario 13: "S alir"

Figura 10.11 Diagrama de secuencias Eliminar Registro Usuario del caso de uso Registrar Usuario. La secuencia comienza de manera similar a Actualizar Registro Usuario, como se mostr anteriormente en la Figura 10.7, con el usuario insertando sus datos de login y password para luego presionar el botn OK en la PantallaPrincipal (P-1). Se contina con el usuario presionando el botn Obtener Registro en la PantallaServicio (P-2), como se mostr anteriormente en la Figura 10.8. A continuacin el sistema presenta la pantalla PantallaObtenerRegUsuario (P-4). Para eliminar el registro, el usuario deber presionar el botn Eliminar, como se muestra en la Figura 10.12.

Weitzenfeld: Captulo 10

15

Figura 10.12. La secuencia Eliminar Registro Usuario contina con el usuario oprimiendo el botn Eliminar en la PantallaObtenerRegUsuario (P-4). El sistema despliega la PantallaCrearRegistroUsuario (P-3), dando la posibilidad de crear un nuevo registro de usuario. Se puede revisar en la Base de Datos Registro que los valores han sido eliminados correctamente a la base de datos, como se puede observar en la Figura 10.13.

Figura 10.13. Imagen de la Base de Datos de Registro mostrando el registro de usuario eliminados. El usuario puede finalizar el caso de uso presionando el botn Salir en la PantallaCrearRegistroUsuario (P-3), como se muestra en la Figura 10.14.

Weitzenfeld: Captulo 10

16

Figura 10.14. La secuencia Eliminar Registro Usuario termina con el usuario oprimiendo el botn Salir en la PantallaCrearRegUsuario (P-3). Registrar Tarjeta Se prueban las secuencia ms importante del caso de uso Registrar Tarjeta: Crear Registro Tarjeta, Actualizar Registro Tarjeta y Eliminar Registro Tarjeta. Crear Registro Tarjeta El caso de uso Registrar Tarjeta es una extensin al caso de uso Registrar Usuario. La secuencia Crear Registro Tarjeta depende de que no exista un registro anterior de tarjeta para el usuario actual. El diagrama de secuencia de alto nivel se muestra en la Figura 10.15.

Weitzenfeld: Captulo 10

17

: Usuario

: Sistema

: Base de Datos Registros

1: "OK" 2: validarRegistroUsuario 3: OK 4: desplegarPantallaServicios

5: "Obtener Registro" 6: obtenerRegist roUsuario 7: OK 8: desplegarPantallaObtenerRegUsuario 9: " Registrar Tarjet a" 10: obtenerRegistroTarjeta 11: NULL 12: desplegarPantallaCrearRegTarjeta 13: "Registrar" 14: crearRegistroTarjeta 15: OK 16: desplegarPantallaObtenerRegTarjet a 17: "S alir"

Figura 10.15 Diagrama de secuencias Crear Registro Tarjeta del caso de uso Registrar Tarjeta. La secuencia comienza con de manera similar a Actualizar Registro Usuario. En lugar de hacer una actualizacin de registro de usuario, se presiona el botn Registrar Tarjeta en la PantallaObtenerRegUsuario (P-4), como se muestra en la Figura 10.16.

Weitzenfeld: Captulo 10

18

Figura 10.16. La secuencia Crear Registro Tarjeta comienza con el usuario oprimiendo el botn Registrar Tarjeta en la PantallaObtenerRegUsuario (P-4). El caso de uso contina con el sistema presentando la PantallaCrearRegTarjeta (P-5) la cual deber ser llenada con los datos de tarjeta de crdito solicitados. Ntese, que en este subflujo an no existe una tarjeta de registro para el usuario. El usuario deber presionar el botn Registrar, como se muestra en la Figura 10.17.

Weitzenfeld: Captulo 10

19

Figura 10.17. La secuencia Crear Registro Tarjeta contina con el usuario insertando los datos de tarjeta de crdito solicitados para luego presionar el botn Registrar en la PantallaCrearRegTarjeta (P-5). Se puede revisar en la Base de Datos Registro que los valores han sido creados e insertados correctamente a la base de datos, como se puede observar en la Figura 10.18.

Figura 10.18. Imagen de la Base de Datos de Registro mostrando el registro de tarjeta recin insertado. A continuacin el sistema despliega la PantallaObtenerRegTarjeta (P-6), como se muestra en la Figura 10.19.

Weitzenfeld: Captulo 10

20

Figura 10.19. La secuencia Crear Registro Tarjeta termina con el usuario presionando el botn Salir en la PantallaObtenerRegTarjeta (P-6). El usuario puede finalizar el caso de uso presionando el botn Salir en la PantallaObtenerRegTarjeta (P-6). Actualizar Registro Tarjeta La secuencia Actualizar Registro Tarjeta depende de que ya exista un registro anterior de tarjeta para el usuario actual. El diagrama de secuencia a nivel funcional se muestra en la Figura 10.20.

Weitzenfeld: Captulo 10

21

: Usuario

: Sistema

: Base de Datos Registros

1: "OK" 2: validarRegistroUsuario 3: OK 4: desplegarPantallaServicios

5: "Obtener Registro" 6: obtenerRegist roUsuario 7: OK 8: desplegarPantallaObtenerRegUsuario 9: " Registrar Tarjet a" 10: obtenerRegistroTarjeta 11: OK 12: desplegarPantallaObtenerRegTarjeta 13: "Actualizar" 14: actualizarRegistroTarjeta 15: OK 16: desplegarPantallaObtenerRegTarjet a 17: "S alir"

Figura 10.20 Diagrama de secuencias Actualizar Registro Tarjeta del caso de uso Registrar Tarjeta. La secuencia inicia de manera similar a Actualizar Registro Usuario, donde en la PantallaObtenerRegUsuario (P-4) se presiona el botn Registrar Tarjeta, como se mostr anteriormente en la Figura 10.16. El caso de uso contina con el sistema presentando la PantallaObtenerRegTarjeta (P-6) donde el usuario podr modificar los datos deseados de la tarjeta de crdito, tal como la fecha de vencimiento. El usuario deber presionar el botn Actualizar, como se muestra en la Figura 10.21.

Weitzenfeld: Captulo 10

22

Figura 10.21. La secuencia Actualizar Registro Tarjeta permite al usuario modificar los datos de registro de la tarjeta, tales como la fecha de vencimiento. El usuario deber presionar el botn Actualizar en la PantallaObtenerRegTarjeta (P-6). Se puede revisar en la Base de Datos Registro que los valores han sido actualizados correctamente a la base de datos, como se puede observar en la Figura 10.22.

Figura 10.22. Imagen de la Base de Datos de Registro mostrando el registro de tarjeta recin actualizada. El usuario puede finalizar el caso de uso presionando el botn Salir en la PantallaObtenerRegTarjeta (P-6), como se mostr anteriormente en la Figura 10.19. Eliminar Registro Tarjeta La secuenciaflujo Eliminar Registro Tarjeta se muestra a nivel funcional en la Figura 10.23.

Weitzenfeld: Captulo 10

23

: Usuario

: Sistema

: Base de Datos Registros

1: "OK" 2: validarRegistroUsuario 3: OK 4: desplegarPantallaServicios

5: "Obtener Registro" 6: obtenerRegist roUsuario 7: OK 8: desplegarPantallaObtenerRegUsuario 9: " Registrar Tarjet a" 10: obtenerRegistroTarjeta 11: OK 12: desplegarPantallaObtenerRegTarjeta 13: "Eliminar" 14: eliminarRegistroTarjeta 15: OK 16: desplegarPantallaCrearRegTarjeta 17: "S alir"

Figura 10.23 Diagrama de secuencias Eliminar Registro Tarjeta del caso de uso Registrar Tarjeta. La secuencia comienza de manera similar a Actualizar Registro Tarjeta, presionando el botn Registrar Tarjeta en la PantallaObtenerRegUsuario (P-4), como se mostr anteriormente en la Figura 10.16. A continuacin el sistema presenta la pantalla PantallaObtenerRegTarjeta (P-6). Para eliminar el registro de tarjeta, el usuario deber presionar el botn Eliminar, como se muestra en la Figura 10.24.

Weitzenfeld: Captulo 10

24

Figura 10.24. La secuencia Eliminar Registro Tarjeta contina con el usuario presionando el botn Eliminar en la PantallaObtenerRegTarjeta (P-6). El sistema presenta la PantallaCrearRegTarjeta (P-5), dando la posibilidad de crear un nuevo registro de tarjeta. Se puede revisar en la Base de Datos Registro que los valores han sido eliminados correctamente a la base de datos, como se puede observar en la Figura 10.25.

Figura 10.25. Imagen de la Base de Datos de Registro mostrando el registro de tarjeta eliminados. El usuario puede finalizar el caso de uso presionando el botn Salir, como se muestra en la Figura 10.26.

Weitzenfeld: Captulo 10

25

Figura 10.26. La secuencia Eliminar Registro Tarjeta termina con el usuario presionando el botn Salir en la PantallaCrearRegTarjeta (P-5).

Pruebas

26