DBCASE 4.0

TÍTULO DBCASE 4.0 TRABAJO FIN DE GRADO CURSO 2023-2024 AUTOR IVÁN PISONERO DÍAZ JAVIER DE VICENTE VÁZQUEZ DIRECTOR FERNANDO SÁENZ PÉREZ GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID DEDICATORIA A odas las pe sonas que nos hemos c uzado du an e es e iaje AGRADECIMIENTOS Quie o ag adece a mi amilia y a mis amigos po su apoyo, en especial a mi mad e. I án Quie o ag adece a mis pad es, a odos mis amigos y amigas y sob e odo a Vic o ia po es a siemp e ahí aguan ándome y sopo ando mis quejas. Ja ie También que emos ag adece a Fe nando po su iempo in e ido en es e p oyec o y po habe espondido siemp e al momen o odas las dudas que nos han ido su giendo. Resumen DBCASE 4.0 El p oyec o de allado a con inuación co esponde con el T abajo de Fin de G ado de los alumnos I án Pisone o Díaz y Ja ie de Vicen e Vázquez du an e el cu so 2023/2024, bajo la u ela del p o eso Fe nando Sáenz Pé ez. DBCASE 4.0 es la úl ima i e ación de un p oyec o comenzado en 2008 y que es una aplicación de esc i o io basada en Ja a que pe mi e el diseño y la implemen ación de bases de da os elacionales SQL. Tiene una in e az g á ica in ui i a que pe mi e el diseño de diag amas concep uales y la gene ación pos e io de un modelo lógico y un modelo ísico el cual se puede implemen a en una BBDD median e el conec o que iene in eg ada la aplicación. En es a memo ia se explica de alladamen e odo el abajo ealizado pa a mejo a la aplicación, así como mul i ud de diag amas UML incluidos en o ma de anexo, que jun o a la documen ación gene ada en e siones an e io es se i án pa a ayuda a u u os alumnos a segui e olucionando y mejo ando es a aplicación. Palab as cla e Ja a, Bases de da os elacionales, SQL, Modelo En idad-Relación, Modelo Vis a- Con olado , Comando, Re ac o ización, Ma en, Pa ones de diseño. 5 ABSTRACT DBCASE 4.0 The p ojec de ailed below co esponds o he Bachelo Thesis o s uden s I án Pisone o Díaz and Ja ie de Vicen e Vázquez du ing he academic yea 2023/2024, unde he supe ision o P o esso Fe nando Sáenz Pé ez. DBCASE 4.0 is he la es i e a ion o a p ojec s a ed in 2008, which is a Ja a-based desk op applica ion ha allows o he design and implemen a ion o ela ional SQL da abases. I ea u es an in ui i e g aphical in e ace o designing concep ual diag ams and subsequen ly gene a ing a logical model and a physical model ha can be implemen ed in a da abase using he in eg a ed connec o . This epo explains in de ail all he wo k done o imp o e he applica ion, as well as nume ous UML diag ams included as annexes, which along wi h he documen a ion gene a ed in p e ious e sions will help u u e s uden s con inue o e ol e and enhance his applica ion. Keywo ds Ja a, ela ional da abases, SQL, En i y-Rela ionship Model, Model View-Con olle , Command, Re ac o ing, Ma en, Design Pa e ns 6 Índice de con enidos Dedica o ia ............................................................................................................................... II Ag adecimien os ..................................................................................................................... III Resumen .................................................................................................................................. IV Abs ac .................................................................................................................................... 5 Índice de con enidos .............................................................................................................. 6 Capí ulo 1 - In oducción .......................................................................................................11 1.1 Mo i ación ....................................................................................................................12 1.2 Obje i os ........................................................................................................................13 1.3 Plan de abajo .............................................................................................................16 1.4 Es uc u a de la memo ia .............................................................................................17 Capí ulo 2 - Modelo y diag amas UML .................................................................................18 Capí ulo 3 - Ma en y eo ganización de ecu sos...............................................................20 Capí ulo 4 - Re ac o ización del código ..............................................................................22 4.1 He encia pa a las is as ...............................................................................................22 4.2 Fac o iaGUI ...................................................................................................................23 4.3 Fac o iaTCC l ...............................................................................................................25 4.4 Re e encias a lis as .......................................................................................................27 4.5 Comandos.....................................................................................................................28 4.6 Fac o ía de se icios .....................................................................................................31 4.7 Relación con olado - se icios ..................................................................................33 4.8 Con ex o ........................................................................................................................34 7 4.9 T a a Con ex o ..............................................................................................................35 4.10 Fac o iaMsj ..................................................................................................................38 4.11 Con ig ..........................................................................................................................39 4.12 T ans e a ibu o ..........................................................................................................39 4.13 A qui ec u a ................................................................................................................39 4.14 Sepa ación del Main ..................................................................................................42 4.15 Sepa ación de algunas unciones del con olado a U ilsFunc ..............................42 4.16 Relación en e alidado BD y Gene ado Esquema ................................................43 4.17 C eación de almacén pe sis en e ............................................................................45 4.18 Cons uc o es y unciones de ca ga y gua da documen os en DAOs ...............45 4.19 Mé odo mensaje en con olado ..............................................................................46 4.20 Comandos pa a en idades débiles ..........................................................................47 4.21 Recu sión en eliminación de suba ibu os ................................................................48 4.22 En idadYA idad y NodoEn idad ................................................................................49 Capí ulo 5 - Nue as uncionalidades ...................................................................................51 5.1 Flechas al ca ga p oyec os ........................................................................................51 5.2 Rende izado de elaciones ecu si as ........................................................................52 5.3 Renomb amien o de a ibu os unique .......................................................................54 5.4 Gua da como XML modelo lógico y ísico ................................................................54 5.5 Co ecciones en aducción a modelo lógico y ísico ..............................................55 5.6 Ven ana de edi a ca dinalidad y pa icipación ......................................................57 5.7 O as uncionalidades ..................................................................................................58 Capí ulo 6 - P uebas ...............................................................................................................61 8 Capí ulo 7 - Cambios en a chi os de ejemplo ....................................................................65 Capí ulo 8 - Conclusiones y abajo u u o ...........................................................................66 8.1 Obje i os cumplidos .....................................................................................................70 Con ibuciones Pe sonales ....................................................................................................87 Apéndices ...............................................................................................................................93 9 Índice de igu as Ilus ación 1: Diag ama de Gan del p oyec o ..................................................................17 Ilus ación 2: Diag ama de clase paque e is a. ames .....................................................24 Ilus ación 3: Diag ama de clase paque e con olado .....................................................26 Ilus ación 4: Diag ama de clase paque e comando ........................................................30 Ilus ación 5: Diag ama de secuencia ejecu a comando ................................................30 Ilus ación 6: Diag ama de clase paque e se icios (pa cial) ............................................32 Ilus ación 7: Diag ama de secuencia de a a Con ex o ..................................................37 Ilus ación 8: Diag ama de clase Gene ado Esquema .......................................................44 Ilus ación 9: Diag ama de clase paque e pe sis encia .....................................................46 Ilus ación 10: Rende izado de elación ecu si a en DBCASE 3.0 .....................................52 Ilus ación 11: Rende izado de elación ecu si a en DBCASE 4.0 .....................................53 Ilus ación 12: T aducción e ónea en Ejemplo 5 .................................................................55 Ilus ación 13: T aducción de elaciones ac ual de Ejemplo 5 ...........................................57 Ilus ación 14: Diag ama de clase paque e is a ................................................................94 Ilus ación 15: Diag ama de clase paque e is a.componen es .......................................95 Ilus ación 16: Diag ama de clase paque e is a.componen es.GUIPanels .....................95 Ilus ación 17: Diag ama de clase paque e is a.diag ama ..............................................96 Ilus ación 18: Diag ama de clase paque e is a.diag ama.geome ia ...........................97 Ilus ación 19: Diag ama de clase paque e is a.diag ama.lineas ...................................97 Ilus ación 20: Diag ama de clase paque e is a.iconos ....................................................98 Ilus ación 21: Diag ama de clase paque e is a.iconos.pe spec i a ..............................99 16 Al momen o de esc ibi es a memo ia se comple ó muy sa is ac o iamen e el obje i o p io i a io de la e ac o ización. Se ha conseguido que el código sea mucho más legible pe o lo más impo an e, mucho más man enible y ac ualizable, agmen ando clases que enían más de cinco mil líneas a unas mucho más manejables, se han c eado ac o ías, con ex os, comandos, e c. Po o o lado se ha hecho una eo ganización de la es uc u a de ca pe as, se ha mig ado el p oyec o a Ma en pa a pode añadi nue as lib e ías de una mane a mucho más ácil y se ha abajado en algunos de los obje i os ma cados po nues o u o consiguiendo algunos y dejando o os comen ados debido a que no se log ó comple a los. En la sección 8.1 exponemos una lis a comple a de los obje i os cumplidos. 1.3 Plan de abajo En es a sección se expone el plan de abajo a segui pa a la consecución de los obje i os indicados an e io men e. Lo p ime o ue con ac a con Fe nando Sáenz Pé ez pa a ene una p ime a oma de con ac o con él, du an e es a eunión nos explicó las bases del p oyec o y como eníamos que con inua . Una ez eníamos el código empezamos a analiza lo y comp ende lo y p opusimos lo desc i o en la sección 1.2. Lo p ime o que se hico ue mig a el p oyec o a Ma en pa a acili a la impo ación de lib e ías y pode ac ualiza las, lo siguien e ue la es anda ización de los nomb es de las clases, la o denación de los ecu sos g á icos y de los paque es de idiomas. Una ez e minadas es as a eas comenzó e ac o ización del código, explicada en de alle el Capí ulo 4. Mien as sucedía es a e ac o ización ambién se ue a anzando con la lis a de obje i os explicada an e io men e y con la esc i u a de es a memo ia, aunque como es á esc i o más adelan e, es e abajo ue muy len o y cos oso. Exponemos en la ilus ación 1 un diag ama de Gan de nues o p oyec o. 17 Ilus ación 1: Diag ama de Gan del p oyec o 1.4 Es uc u a de la memo ia A lo la go de es a memo ia desc ibimos odas las a eas acome idas. Exponemos p ime o, en el Capí ulo 2, la ealización de diag amas UML, cuya exposición o al se pueden e en los anexos de es e documen o. Desc ibimos a con inuación, en el Capí ulo 3, odo lo ela i o a la mig ación a Ma en y a la eo ganización de los ecu sos. El capí ulo más ex enso de es a memo ia es el Capí ulo 4 en el que se explica en ein idós apa ados odo el p oceso de e ac o ización del código. A con inuación, siguen es capí ulos, Capí ulo 5, Capí ulo 6 y Capí ulo 7, desc ibiendo o as a eas que se hicie on pa a e mina con las conclusiones, Capí ulo 8, en las que damos nues a opinión sob e el esul ado ob enido y explicamos posibles cambios de ca a al u u o que mejo a ían la aplicación. 18 Capí ulo 2 - Modelo y diag amas UML Usando odo lo que ap endimos ace ca de la aplicación (y ambién descub iendo muchas cosas nue as sob e ella), c eamos diag amas de clases UML pa a odos los paque es y sub-paque es de la aplicación, de es a o ma do amos al p oyec o de una buena he amien a pa a acili a la comp ensión del código y del uncionamien o in e no de la aplicación, así como pa a apoya u u as ampliaciones y u u os desa ollos, dada la impo ancia bien conocida de la documen ación en es os ámbi os. Cabe des aca que es os diag amas o man pa e de un p oyec o de modelado UML en la he amien a IBM RSAD, que pe mi e la modi icación / ampliación de cualquie a de los diag amas ácilmen e, así como la c eación de nue os elemen os (diag amas, clases UML…). Usamos la ans o mación Ja a a UML que o ece IBM RSAD pa a ans o ma las clases Ja a a clases UML, que además nos gene ó las elaciones de pe enencia-a-paque e y gene alización. Pa a la mayo ía de los paque es hay un único diag ama de clase, pe o en algunos casos, como los se icios, hay a ios po que en un diag ama se consolidaba demasiada in o mación y eso lo hacía más di ícil de in e p e a . En los diag amas no apa ecen los pa áme os ni los ipos de e o nos de las unciones, y en ocasiones ampoco los a ibu os de la clase, po que hacía el diag ama demasiado g ande, pe o eso se puede cambia ácilmen e en IBM RSAD, po que la in o mación sí que es á con enida en las clases UML. Pa a las clases que no pe enecen al paque e al que co esponde el diag ama, pe o que apa ecen en el diag ama, las hemos ep esen ado únicamen e con el nomb e, y es en el diag ama co espondien e al paque e al que pe enecen donde apa ecen con oda la in o mación. Además, conside amos que e a una buena idea usa diag amas de secuencia pa a mos a cómo in e ac úan las clases y las capas de la aplicación en un caso de 19 uso especí ico, con el obje i o de mos a con odo de alle y con la máxima cla idad posible qué es lo que hace la aplicación en esa ope ación. Elegimos el caso de uso co espondien e a edi a el campo ‘No null’ de un a ibu o. C eamos en onces los diag amas de secuencia que ep esen an las in e acciones en e las clases, di ididos po capas. Cabe des aca que el diag ama de secuencia de a a Con ex o ambién in e iene en es e caso de uso. Exponemos a lo la go del ex o los diag amas ealizados, in oduciendo algunos a lo la go de los capí ulos y exponiendo el es o en los apéndices de es e documen o. Y espe amos que es a documen ación gene ada, jun o con la apo ada po nues os compañe os de años an e io es, ayude y acili e lo máximo posible la ampliación de la aplicación, así como su man enimien o. 20 Capí ulo 3 - Ma en y eo ganización de ecu sos Ma en es una he amien a de ges ión de p oyec os de so wa e desa ollada po Apache So wa e Founda ion. Su p incipal unción es ayuda en la cons ucción y adminis ación de p oyec os Ja a, U iliza un a chi o de con igu ación llamado POM (P ojec Objec Model) que desc ibe cómo se o ganiza el p oyec o, sus dependencias, con igu aciones de compilación, p uebas y dis ibución. A pa i de es e a chi o POM, Ma en au oma iza a eas comunes en el ciclo de ida de desa ollo del so wa e, como la compilación del código uen e, la ges ión de dependencias, la ejecución de p uebas, la gene ación de documen ación y la dis ibución del so wa e. En el ámbi o de es e p oyec o cada lib e ía usada ue añadida al POM ac ualizado a la úl ima e sión compa ible exis en e. Es o ue una a ea que lle ó más o menos has a el mes de no iemb e. Es o se debió p incipalmen e a que al se un p oyec o i e a i o que comenzó en el año 2008, el co e de las lib e ías de ende izado usa e siones Alpha que cuen an con muchas ulne abilidades. Se in en ó ac ualiza las pe o no ue posible ya que las nue as e siones cambian la sin axis de los mé odos po lo que obligaba a hace una eingenie ía comple a del ende izado del esquema concep ual. Lo que sí se hizo ue ac ualiza el es o de las lib e ías y deja comen ado en el POM las lib e ías que ienen ulne abilidades pa a que si es necesa io en el u u o ealiza la eingenie ía p e iamen e comen ada. A la go de odo el desa ollo del p oyec o hemos man enido ac ualizadas odas las lib e ías que e an posibles, pa a ello en Gi Hub ac i amos una uncionalidad llamada “Dependabo ale s” que una ez po semana escanea odas las dependencias del eposi o io y manda po co eo elec ónico un in o me con las ulne abilidades encon adas, su código de e e encia, una pun uación del uno al diez sob e la g a edad y si es posible, la e sión a la que ac ualiza la. Po o o lado Ma en pe mi e la 21 ins alación y c eación de ejecu ables de o ma au omá ica simplemen e ejecu ando el p oyec o con el comando “ins all”. En es e ejecu able se encuen as embebidas odas las dependencias del p oyec o. La mig ación a Ma en se hizo con la idea de que cuando el p oyec o siga e olucionando sea mucho más ácil busca y añadi nue as lib e ías, ya que de la o ma en la que es aba e a necesa io desca ga e impo a manualmen e las 23 lib e ías con las que cuen a DBCASE 4.0. A la pa que se mig aba a Ma en ambién se ealizó una o ganización de las clases del p oyec o, eo ganizando los ecu sos en o ma de imágenes, aducciones, e c. P e iamen e se encon aban “despe digados” y no había unidad en cuan o a los nomb es de es os. En es a e apa ambién se cambió la o ma de impo ación de las imágenes c eando una clase llamada ImagesPa h con odos los S ings que con enían las ubicaciones pa a pode impo a las más ácilmen e en ez de ene que in oduci el S ing con la u a manualmen e que ez que uese necesa io. Es o mismo se hizo pa a los paque es de idiomas, los paque es de emas y o os ecu sos gené icos pa a los cuales se c ea on las clases LanguagesPa h, ThemesPa h y O os, espec i amen e. Una ez comple ada es a p ime a e ac o ización nos pusimos con lo que se ía la pa e más impo an e de es e p oyec o: la e ac o ización comple a del código. 22 Capí ulo 4 - Re ac o ización del código Con el obje i o de acili a lo máximo posible que la aplicación DBCASE pueda segui c eciendo du an e muchos años, decidimos e ac o iza a ias pa es del código de la aplicación. Buscamos con ello simpli ica y p omo e la ampliación de DBCASE, así como su man enimien o. Nos gus a ía des aca que u imos siemp e como una de nues as p io idades que el código desa ollado du an e an os años po nues os compañe os uese pe ec amen e compa ible con es os cambios. Nos es o zamos mucho po comp ende su código a ondo y po espe a e impulsa el g an esul ado de su abajo. 4.1 He encia pa a las is as La he encia en las is as había sido implemen ada po nues os compañe os de años an e io es. Había una clase Pa en _GUI que es aba des inada a se la clase de la que odas las is as he edaban. No obs an e, analizando el código, obse amos que no se es aba ap o echando odo el po encial de la he encia en la ges ión de las is as, debido a las azones que exponemos a con inuación: • El con olado no a aba con la clase pad e, sino que enía una e e encia di ec a pa a cada ipo de is a u ilizada. Es o lle aba a que el con olado es u iese demasiado acoplado con las is as especí icas, de o ma que llamaba a mé odos que no es aban especi icados en Pa en _GUI. • Las is as enían, en e ellas, modos dis in os de unciona y de comunica se, que en la mayo ía de los casos podían se adap ados a un pa ón único en e odas ellas. • Muchas is as no he edaban de Pa en _GUI. 23 Cabe hace una mención especial a GUIP incipal, clase que ep esen a a la is a p incipal de la que nacen odo el es o de ellas, en es a clase había mucha uncionalidad desa ollada en el con olado . Es a clase e a capi al pa a la aplicación y adap a la al nue o modo de abaja con is as se ía una a ea muy cos oso y complejo. Po lo que decidimos deja que el con olado siguiese pudiendo impo a la clase GUIP incipal y ob ene una e e encia di ec a a ella a a és de Fac o iaGUI (que an es ob enía el con olado de sí mismo po que e a él el que c eaba la ins ancia y enía la e e encia a ella). Además, no imos p oblema en deja la e e encia a las is as Abou , Manual y Gale ía, ya que son is as muy especí icas que di ie en en buena medida del es o. 4.2 Fac o iaGUI An e io men e, el con olado gua daba una e e encia di ec a pa a cada is a de la aplicación. E a el con olado el enca gado de ins ancia cada is a, pa a lo cual usaba en el cons uc o una llamada al mé odo iniciaF ames() y e a ambién el enca gado de gua da una e e encia a cada is a. Es o p o ocaba un ue e acoplamien o en e las is as y el con olado , de o ma que és e úl imo enía que “conoce ” cada is a en especí ico y, como comen amos en el apa ado 4.1 en muchas ocasiones se llamaban a mé odos de los ames que no igu aban en la clase Pa en _GUI, y en ocasiones algún ame no he edaba de es a clase. Las ampliaciones se ol ían así más complicadas, así como el man enimien o del código, que eque ía de mucho análisis pa a de e mina qué se debía hace . Pensamos que, usando el pa ón Fac o ía, pod íamos e e i has a cie o pun o es a si uación y do a a la aplicación de una o ma más sólida de ges iona las is as. El esul ado de es o ue la Fac o iaGUI, una nue a clase que se enca ga de la ins anciación y ges ión de las e e encias a las is as. Es a nue a clase o ece un mé odo ge GUI, que de uel e un obje o de ipo Pa en GUI. Es e mé odo ecibe es pa áme os, 24 el p ime o de ellos es el enum TC cuya is a asociada se quie e ob ene ; el segundo es un pa áme o de ipo Objec que con iene los da os que se quie an pasa a la is a a la ho a de la c eación / ac i ación; y po úl imo un ipo boolean que, si es cie o, ue za la des ucción del ame almacenado (si exis iese) y c ea uno nue o desde ce o. Pa a la ges ión de las e e encias, la clase Fac o iaGUI usa un obje o de ipo Map<TC, Pa en _GUI>, que asocia un TC con, como máximo, una is a. Ilus ación 2: Diag ama de clase paque e is a. ames 25 Cabe des aca que su gió un p oblema complicado a la ho a de de e mina qué mensajes debe ían se asociados a is as en la implemen ación del mé odo ge GUI. El p oblema su gía po que, a la ho a de ob ene una e e encia a una is a, an e io men e se usaba el mé odo del con olado especí ico pa a esa is a. Aho a bien, aho a es o no e a así, y pa a ello lo más adecuado se ía u iliza el mensaje asociado a la si uación que se es u iese a ando, que pod ía se , en gene al, de es ipos según nues os compañe os lo de inie on: Con olado _, GUI_ o Se icios_. Es o que ía deci que, o bien asociábamos en gene al a es mensajes dis in os una misma is a, o bien elegíamos algún c i e io pa a “ aduci ” de alguna o ma es os mensajes en e sí, de o ma que en la Fac o íaGUI solo hubiese cie os mensajes. Op amos po la segunda opción po dos azones: la p ime a opción hacía que la Fac o íaGUI c eciese de amaño y oscu ecía has a cie o pun o la unción pa a la que es a clase había sido diseñada; y, po o a pa e, aduci es os mensajes a uno uni icado e a un buen paso pa a que se pudiese di idi en un u u o el enume ado TC en a ios, unos u ilizados po los se icios, o os po las is as y o os po el con olado . Es o posibili a ía además el uso de cons uc o es pa a enume ados, po que al es a di ididos odos los enume ados de una clase end ían los mismos a ibu os (ej. un alo booleano de éxi o en el caso de los se icios). Siguiendo es a solución, decidimos que la Fac o iaGUI se enca gase de los mensajes Con olado _, con la única excepción de las is as dedicadas a la ges ión del wo kspace que no enían mensajes de es e ipo asociados. 4.3 Fac o iaTCC l Pa a lle a a cabo ese p oceso de aducción que e a necesa io al y como comen amos en la sección an e io , c eamos una nue a clase Fac o iaTCC l que se enca ga ía de esa asociación en e mensajes. Más a de, a la ho a de diseña la unción 32 se puede e en la ilus ación 8 la elación en e ac o ía de se icios y la clase Gene ado Esquema. También se puede consul a la ilus ación 3 pa a e la elación en e el con olado y es a ac o ía. Ilus ación 6: Diag ama de clase paque e se icios (pa cial) 33 4.7 Relación con olado - se icios Ya hemos comen ado en el pun o dedicado a la ac o ía de se icios que decidimos hace algunos cambios en cuan o a la o ma que enía el con olado de accede y comunica se con los se icios. Po o a pa e, en cuan o a los se icios, obse amos que odos ellos enían una e e encia a un obje o de ipo Con olado . Se usaba es a e e encia pa a en ia mensajes a es e con olado usando los mé odos mensaje_DesdeSE, mensaje_DesdeSA, mensaje_DesdeSR, mensaje_DesdeSAG, mensaje_DesdeSD y mensaje desdeSS. Es os mé odos del con olado enían como obje i o ecibi mensajes desde un se icio en especí ico (mensaje_DesdeSE es aba dedicado a mensajes p o enien es del se icio de en idades e c.…), y esponde de o ma especí ica a cada mensaje. Analizando el código y alo ando es a elación en e los se icios y el con olado , concluimos que podíamos hace algunos cambios pa a log a e e i o subsana es as si uaciones que se es aban p esen ando con o me la aplicación c ecía (y se segui ían p esen ando con o me la aplicación c eciese): • Man ene es a o ma de comunicación se icios - con olado e a di ícil. La can idad de código que eque ía en el con olado e a muy g ande. • Las ampliaciones de código se complicaban, al ene que analiza el código de o os casos especí icos pa a e qué se enía que hace y qué no pa a la uncionalidad nue a que se implemen aba. • El con olado enía un amaño muy g ande. • Muchas de las uncionalidades que se implemen aban en los mé odos mensajeDesde… pa a cada mensaje e an muy pa ecidas en e sí, y en la mayo ía de los casos se llamaban a los mismos mé odos. En consecuencia, 34 había código epe ido que ambién complicaba la man enibilidad y la escalabilidad. • Los se icios e an dependien es del con olado que se le asignaba y de los mé odos que él o eciese. En consecuencia, decidimos usa los pa ones de diseño y las uncionalidades que desc ibimos a con inuación en las secciones 4.8, 4.9 y 4.10 pa a a a de e e i es as si uaciones 4.8 Con ex o A la ho a de diseña soluciones pa a es as si uaciones, pensamos di ec amen e en el pa ón de diseño de la a qui ec u a mul icapa “Con ex o”. Los se icios no enían po qué usa los mé odos del con olado pa a de ol e mensajes y da os, podían de ol e un obje o de ipo Con ex o como e o no de sus mé odos, que con u iese la in o mación necesa ia. De es a o ma, y jun o a la clase Con ig que desc ibimos a con inuación, los se icios ya no necesi aban pa a nada ene una e e encia al con olado . Así, son comple amen e independien es del con olado (y, en gene al, de cualquie obje o que llame a sus mé odos). En cuan o a la clase con ex o, ha sido diseñada e implemen ada con es a ibu os. El p ime o de ellos es un ipo boolean que indica si la ope ación que se p e endía lle a a cabo ha sido exi osa o no; en segundo luga , un enume ado de ipo TC (el mensaje que p e iamen e en iaban los se icios di ec amen e al con olado ); y en e ce luga un obje o de ipo Objec donde se almacenan da os. Se han implemen ado mé odos ge e s y se e s pa a odos es os a ibu os. 35 4.9 T a a Con ex o Al es udia el código, después de analiza muchos casos de uso imos que las acciones que lle aba a cabo el con olado cuando ecibía un mensaje de los se icios podían co esponde a un pa ón especí ico: que en el caso de ope aciones allidas se mos aba un mensaje de e o y que en el caso de ope aciones exi osas se hacían una se ie de ope aciones que, en la g an mayo ía de casos, siemp e e an las mismas. Con es o su gió la idea de a a de c ea una unción que se dedicase a a a es as si uaciones en las que se ha llamado a la capa de negocio y se iene una in o mación que se quie e a a . Es o p odujo la necesidad de ene un pa ón, una no ma común que enían que cumpli los da os de uel os po la mayo ía de las ope aciones de los se icios (ano ación) pa a que su a amien o pudiese se lo más uni o me y gene al posible. De ca a al diseño de es a unción, iden i icamos esos p ocedimien os que se hacían en casos de éxi o y que exponemos a con inuación: • Llama a gua da Deshace () y asignación de la a iable del con olado auxDeshace a ue. Apa ecían comen adas asignaciones de las a iables ul imoMensaje (de ipo TC) y ul imosDa os (de ipo Objec ) al mensaje ecibido po el con olado y los da os ecibidos. Además, se hacían unas comp obaciones pa a ac ualiza los componen es de la in e az g á ica dedicados a la uncionalidad Deshace / Rehace . Todas es as unciones es án dedicadas a la uncionalidad Deshace / Rehace . • Cas ing del obje o de ipo Objec ecibido po el con olado a un obje o de un ipo especí ico dependiendo del caso. Po ejemplo, al ecibi SE_Anadi A ibu oAEn idad_HECHO se hacía un cas ing a Vec o <T ans e > mien as que al ecibi SE_Renomb a En idad_HECHO se hacía un cas ing a T ans e En idad. 36 • En ia un mensaje especí ico, y dis in o del ecibido, a GUIP incipal con los da os ecibidos. • Desac i a el ame especí ico de la acción si lo hay. • LLama al mé odo Ac ualizaA bol (que llama al mé odo de mismo nomb e de GUIP incipal) con un obje o de ipo T ans e . Haciendo uso del pa ón Con ex o, de es a in o mación, y de la Fac o iaTCC l pa a pode aduci mensajes con los que comunica nos con las is as, implemen amos una unción a a Con ex o que es á des inada a euni odas es as acciones y cuyo diag ama de secuencia UML exponemos en la ilus ación 7. Como comen a emos en el apa ado 4.21, ue necesa io añadi una o ma de a a subcon ex os de i ados de una ope ación o con ex o p incipal, explicamos es o con más de alle en dicho apa ado. 37 Ilus ación 7: Diag ama de secuencia de a a Con ex o Nos gus a ía des aca que u imos especial cuidado pa a que es a unción a a Con ex o y es e cambio en la o ma de a a y es uc u a la in o mación de uel a po los se icios uese compa ible con la uncionalidad Deshace / Rehace que había sido desa ollada po nues os compañe os. Al basa se pa e de es a uncionalidad en el úl imo mensaje ecibido y los da os asociados, se consigue el mismo compo amien o al almacena los da os de la misma o ma, y al pode se es os analizados de igual o ma 38 po el mé odo del con olado des inado a es a uncionalidad. Es o, cla o, en el caso de que se decida segui desa ollando dicha uncionalidad como es á implemen ada en el mé odo dedicado a ella en el con olado , que no es la o ma en la que la aplicación ac ualmen e lle a a cabo es a unción. La o ma en la que la aplicación lle a a cabo es a unción ac ualmen e ambién es o almen e compa ible con los cambios, dado que se basa en el gua dado de los documen os in e medios según se an p oduciendo cambios, uncionalidad en la que no se ha cambiado nada y pa a la que los cambios no a ec an. 4.10 Fac o iaMsj An e io men e, a la ho a de mos a un mensaje de e o , se p ocedía de la siguien e o ma: el con olado ecibía un mensaje que indicaba que una acción en especí ico había acabado en e o , y en onces, el con olado decidía qué mensaje de e o mos a , de los es ablecidos en la clase Lenguaje del paque e is a. Pa a di idi la esponsabilidad en es as acciones, decidimos hace una ac o ía de mensajes, que se enca gase de la asociación mensaje ecibido po el con olado - cadena in o ma i a. Es a nue a ac o ía se encuen a en el subpaque e ' ac o ias' del paque e 'con olado . Cabe des aca que es a ac o ía ambién se enca ga de llama al mé odo ex () de la clase Lenguaje, de o ma que lo que de uel e no es un en e o con el cual ob ene la cadena haciendo Lenguaje. ex () sino que di ec amen e de uel e la cadena, encapsulando es as especi icidades de implemen ación pa a que no se enga que lidia con ellas desde ue a. Con es a nue a o ma de a a los mensajes de e o , se ha conseguido elimina g an can idad de código epe ido. 39 4.11 Con ig En ocasiones, desde algún pun o de la aplicación e a necesa io ob ene la a iable pa h y la a iable isNullA s, ambas p esen es en el con olado . Decidimos mo e es os a ibu os a una nue a clase Con ig, pa a que, si alguna clase necesi aba esa in o mación, no u iese que se dependien e de odo el con olado sino solo de es a clase Con ig que con iene esa in o mación ele an e ela i a a la con igu ación de la aplicación. 4.12 T ans e a ibu o An e io men e, T ans e a ibu o enía una e e encia al con olado . La azón po la que se es aba usando es a e e encia e a que, a la ho a de de e mina si un a ibu o es nullable o no, se enía en cuen a el alo de isNullA s, un a ibu o que an e io men e se encon aba en el con olado y que indica si se pe mi en a ibu os nullables. Conside amos que, debido a la p opia na u aleza del pa ón ans e , y a que había una o ma de cambia es a si uación pa a es ablece una di isión de esponsabilidades más cla a, lo mejo e a cambia es o. Decidimos usa la ya mencionada clase Con ig del paque e con olado , desplazando es e a ibu o a dicha clase. También decidimos hace que es e a ibu o pasase a se es á ico, siguiendo lo ya comen ado en el apa ado 4.11. De es a o ma, el ans e ya no necesi a la e e encia al con olado (que ha sido eliminada). 4.13 A qui ec u a Una de las p ime as cosas que imos a la ho a de analiza el código es que la a qui ec u a de la aplicación e a una a qui ec u a mul icapa. La di isión p incipal de los iche os uen es e an los paque es is a, con olado , se icios... Nues os compañe os 40 de años an e io es desa olla on la aplicación siguiendo es a a qui ec u a, y queda cla o, iendo el código, que oda la aplicación es á desa ollada desde es a pe spec i a mul icapa. No obs an e, encon amos algunos si ios en los que se había o o la a qui ec u a. Los analizamos de o ma especí ica y alo amos po qué se había o o la a qui ec u a. En algunos casos, se daba la si uación en la que desde un pun o de la aplicación que no pe enecía a la capa de negocio ni a la de pe sis encia, se c eaban obje os DAO pa a ob ene lis as de elemen os, que e an usadas pa a alguna uncionalidad en especí ico. Fue ú il pa a es os casos lo que desa ollamos en la sección 4.4, y usamos es a o ma de ob ene lis as pa a qui a es as comunicaciones con la capa de pe sis encia. Es o ocu ía en los siguien es casos: • Mensaje modi ica en idad ecibido po el con olado (código aho a p esen e en el comando ComandoModi ica En idad) • Ac ion lis ene del submenú añadi a ibu o en la clase MyMenu (paque e is a.componen es) • Mé odo ge Lis aT ans e s en la clase AddT ans e sPanel (paque e is a.componen es.GUIPanels) • Mensaje edi a elemen o ecibido po el con olado (código aho a p esen e en el comando ComandoEdi a Elemen o) • Mé odo modi ica a ibu o ecibido po el con olado (código aho a p esen e en el comando ComandoModi ica A ibu o) Po o a pa e, en los obje os DAO, a la ho a de accede al almacén pe sis en e en la unción dameDoc, se podían p oduci a ias excepciones, que se cap u aban en un ca ch y se manejaban usando la clase JOp ionPane pa a mos a un diálogo in o mando del e o . Pa a cambia es o, dado que la capa de pe sis encia no debe ía enca ga se de mos a el e o en la is a, decidimos hace uso de las excepciones de 41 Ja a. C eamos una nue a clase Excep ionAp, que he eda de Excep ion. El DAO aho a lanza es a excepción con un enume ado asociado a ella (en el p opio cons uc o de Excep ionAp), y es a excepción es cap u ada po el con olado (después de se elanzada po los se icios al se ano ados con h ows Excep ionAp y no maneja la excepción), donde se aduce el enume ado al lenguaje ac ual de la aplicación haciendo uso de Fac o iaMsj, y po úl imo desde el con olado se delega en la GUIP incipal el ac o de mos a ese mensaje de e o . Pa a ello, odos los mé odos del con olado y de los comandos que se comunican con los se icios aho a es án equipados con un y-ca ch, capaz de cap u a la excepción y llama a un nue o mé odo, mos a E o , que llama al mé odo que se enca ga de ello en GUIP incipal. Es e cambio pe mi ió además implemen a ácilmen e una o ma de no i ica e o es no solo en dameDoc sino en gua daDoc, donde an es no se no i icaba di ec amen e po medio de la in e az de usua io, sino que se llamaba al mé odo p in S ackT ace de la excepción. Aho a, al cap a una excepción, lanza una Excep ionAp de la misma o ma que en el caso an e io , que se mos a á ambién, en la in e az g á ica, de la misma o ma. Po úl imo, en la clase Gene ado Esquema pe enecien e a la capa de modelo, se hacía uso ambién de la clase JOp ionPane pa a no i ica di e en es si uaciones, que en ocasiones se co espondían con e o es y en o as e an mensajes in o ma i os. Usamos la ya mencionada clase Excep ionAp pa a cambia es a si uación en cuan o a los e o es. No obs an e, pa a que siguiesen apa eciendo los mensajes in o ma i os, dado que siemp e se p oducían al inal de la ope ación, mo imos la uncionalidad pa a que se mandase la o den desde el con olado , a la uel a de la llamada a la capa de negocio, si se ha con i mado que la ope ación ha sido exi osa. Se c eó una unción en 48 4.21 Recu sión en eliminación de suba ibu os Con los cambios desc i os su gió un p oblema a la ho a de elimina suba ibu os. En la aplicación se eliminan ecu si amen e odos los suba ibu os del a ibu o que se quie e elimina , y po an o en cada llamada ecu si a an es había un mensaje en iado al con olado , pa a el a ibu o que se es aba eliminando. Aho a los se icios no ienen e e encia al con olado , luego había que adap a es a si uación. Se di idió en onces el p ocedimien o de la capa de negocio pa a elimina un a ibu o en dos unciones, elimina A ibu o, la unción que se es aba usando odo es e iempo y se sigue usando y elimina A ibu o_imp, una unción p i ada a la que se ha mo ido la uncionalidad que habían implemen ado nues os compañe os de años an e io es y que es aba en la unción mencionada p e iamen e, y sob e la que hemos hecho algunas adap aciones. La unción elimina A ibu o hace la p ime a llamada ecu si a llamando a la unción elimina A ibu o_imp, que gene a la ecu sión y que aho a de uel e una doble cola de con ex os, esul ado de odas las eliminaciones de a ibu os. La ecu sión es de la o ma: elimina A ibu o_imp(a ibu o): si compues o = doble cola que con iene el con ex o de elimina a ibu o y odos los con ex os de uel os po llama a elimina A ibu o_imp() con cada suba ibu o suyo. si simple = doble cola que con iene el con ex o de elimina a ibu o. Es a ope ación sugi ió una modi icación en la clase Con ex o, que aho a necesi aba una o ma de almacena sub-con ex os de i ados de la ope ación p incipal. Se añadió así a la clase con ex o, as alo a di e en es soluciones, un ec o de sub- con ex os, des inado a almacena los. Es o pe mi e almacena co ec amen e oda la in o mación del esul ado de una ope ación de los se icios, incluso si supone el uso de 49 o os mé odos de o os se icios o del mismo, y siemp e de ol iendo un único con ex o con el esul ado de la acción que se ha pedido hace . Pa a pode a a es e ipo de con ex os se añadió una nue a uncionalidad a a a Con ex o, que comp ueba si el ec o de sub-con ex os del con ex o exis e y no es á acío, y en ese caso llama a a a Con ex o con cada uno de ellos, abs ayendo además comple amen e al con olado de si la ope ación ha gene ado sub-con ex os o no. Usando es o, la unción elimina A ibu o oma el con ex o p incipal, es deci el co espondien e a elimina el a ibu o sob e el que se hizo la llamada en un p incipio, y me e en su ec o de sub-con ex os el es o de los con ex os que es aban en la doble cola, desde el p ime o has a el úl imo. Como el con ex o que hemos llamado p incipal es el úl imo en añadi se, y como necesi ábamos accede an o al p incipio de la cola (a la ho a de ex ae p ime o los con ex os de los a ibu os que p ime o se han eliminado) como al inal (pa a oma el con ex o p incipal, co espondien e al úl imo a ibu o que se elimina), decidimos usa una doble cola. Po úl imo, de uel e el con ex o. Po úl imo, des acamos que los con ex os se a an en el o den en que se p oduje on, es deci , p ime o se a an los con ex os de los sub-a ibu os en o den, po que se eliminan an es que el a ibu o pad e, y luego el con ex o del pad e, pa a que las is as puedan ac ualiza co ec amen e su con enido, log ando así el mismo compo amien o que enía an es la aplicación a la ho a de hace es a ope ación, en la que se a aban los mensajes ecibidos po el con olado en es e mismo o den debido a la ecu sión. 4.22 En idadYA idad y NodoEn idad En idadYA idad y NodoEn idad son dos clases impo an es en la aplicación. Es án des inadas a euni la in o mación ace ca de una asociación elación – en idad, en el caso de En idadYA idad, y ace ca de un obje o En idadYA idad y su en idad asociada, 50 en el caso de NodoEn idad. Analizando es as clases imos que, aunque es aban en el paque e pe sis encia, no in e enían en la in e acción con el almacén pe sis en e, y no e an usadas po las clases del paque e de pe sis encia más que lo e an po los se icios o po o os componen es de la aplicación. Concluimos que, dada su unción, e an más bien clases que pe enecían al paque e de ans e s (paque e den o de la es uc u a de la aplicación en el que se encuen an odos los obje os “ ans e ”, que encapsulan la in o mación sob e los obje os de la aplicación como ag egaciones, a ibu os, e c.), po que e an usados po a ias capas y es aban enca gados de euni in o mación, y en ocasiones de alguna unción dedicada a ep esen a esa in o mación, como el es o de ans e s que u iliza la aplicación. 51 Capí ulo 5 - Nue as uncionalidades Es e capí ulo es á dedicado odas las uncionalidades añadidas a la aplicación una ez e minada la e ac o ización, es o incluye ambién aquellas que se empeza on pe o no se e mina on cuyos a ances es án comen ados en el código. 5.1 Flechas al ca ga p oyec os Nues os compañe os del año pasado comen a on en la memo ia de su p oyec o, en la sección ela i a al abajo u u o, que habían de ec ado un e o : al ealiza cualquie acción que eque ía ca ga un nue o p oyec o con DBCASE, se pe dían odas las es icciones de ca dinalidad 1. T as bas an e análisis, imos cómo lo que ocu ía no e a que se pe diesen las es icciones de ca dinalidad 1 sino que, aunque es as siguiesen p esen es, no se ep esen aban co ec amen e en el diag ama. Lo que ocu ía e a que, a la ho a de de e mina si una unión elación – en idad, es deci , una línea, enía una lecha, se enía en cuen a una a iable ma cadaConCa dinalidad, pe enecien e a la clase En idadYA idad que ep esen aba esa unión en idad – elación. Es a a iable ma cadaConCa dinalidad, de ipo boolean, se ma ca a ue cuando se asocia una en idad a una elación, pe o únicamen e se usa a la ho a de edi a esa asociación pa a de e mina si en el diálogo de edición debe ía apa ece el bo ón de ca dinalidad ma cado o no (si no se ma ca el bo ón se asocia ca dinalidad p incipio ango: 0, inal de ango: N a la en idad). Lo que ocu ía e a que, dado que es a a iable únicamen e es u ilizada pa a una is a, su alo no e a almacenado en pe sis encia, y e a inicializado a alse. Así, cuando se de e minaba si se debía pin a una lecha, se eía que ese alo e a also y se decidía en consecuencia que no se debía pin a una lecha. Pa a soluciona lo, decidimos qui a es a comp obación dado que la que hacía al a e a la que se hacía después de la p ime a: de e mina si el inal del ango de la ca dinalidad e a igual a 1. 52 5.2 Rende izado de elaciones ecu si as A la ho a de ende iza las elaciones en las que apa ece una misma en idad dos o más eces, ocu ía un p oblema que ya había sido ad e ido en buena medida po nues os compañe os del año an e io , que habían indicado que ocu ían algunos compo amien os a os. Además, se puede e en el pun o 7 de la lis a que se p esen a en la sección 1.2, cómo se hace una obse ación ace ca de la o ma en que se ende izan los oles en elaciones ecu si as. Vimos cómo, si la en idad es aba asociada en una apa ición con una ca dinalidad dis in a a o a, únicamen e apa ecía una de ellas, como si ambas asociaciones ue an de la misma ca dinalidad. Comp obamos que es o ocu ía debido a cómo se ecolec aban las clases En idadyA idad asociadas a una elación a la ho a de ende iza la. Lo que ocu ía e a que se usaba una unción ge En idadYA idad(T ans e En idad) que, siemp e, de ol ía la p ime a apa ición de un obje o En idadyA idad cuya en idad e a la en idad pasada como pa áme o (ambos T ans e En idad enían el mismo id de en idad almacenado), de o ma que siemp e se de ol ía el mismo obje o En idadYA idad, aunque hubiese a ios asociadas a dicha en idad. El ol se ende iza desde o a unción, luego no es aba a ec ado po es e e ec o. Se puede e es a si uación en el ejemplo núme o 4, en la ilus ación 10. Ilus ación 10: Rende izado de elación ecu si a en DBCASE 3.0 53 Pa a soluciona lo, implemen amos una nue a unción en la clase En idadYA idad que pe mi e ob ene la apa ición núme o x de un obje o En idadYA idad en el que la en idad es la indicada (y que, si no hay al apa ición, de uel e null). Aho a, desde el p oceso de ende izado, en la clase C eaLineas, se llama a es a nue a unción, usando como núme o de apa ición una a iable que ya es aba siendo u ilizada po o as pa es de esa misma unción y que e a jus o lo que se necesi aba. De es a o ma, dicho p oblema en el ende izado se sol en ó, como se puede e en la ilus ación 11, solucionando además el pun o 7 de la lis a que comen ábamos al inicio de es a sección. Aunque, no obs an e, iden i icamos un p oblema en el ende izado de los oles. Ilus ación 11: Rende izado de elación ecu si a en DBCASE 4.0 En ocasiones, conc e amen e cuando la en idad en la elación ecu si a es á po debajo de la elación, el ol de las asociaciones se desplaza de una o ma que hace pa ece que es el ol de o a apa ición (aunque sigue es ando co ec amen e iden i icado en la aplicación). En o as ocasiones, aunque son más in ecuen es, ocu e al e és. C eemos que es o se puede debe a que el o den en el que se asocian las apa iciones in e iene en el epa o del espacio. Hicimos algunos in en os de soluciona es e p oblema modi icando las unciones de la clase E ique aSob eLinea.ja a (paque e is a.diag ama.lineas), que consis ían p incipalmen e en in e i el alo de una a iable 54 pa allelO se en cie as ocasiones, pe o obse amos inalmen e que no se llegaba a un compo amien o uni o me. 5.3 Renomb amien o de a ibu os unique A la ho a de enomb a un a ibu o que había sido ma cado como unique, sal aba una excepción, que se debía a un p oblema a la ho a de edi a la abla de uniques de la elación / en idad a la que pe enece el a ibu o enomb ado. Es e p oblema p o ocaba que no se ac ualizase co ec amen e dicha abla de uniques. La excepción indicaba que se había a ado de hace un cas ing que no e a álido. Desde la aplicación se a aba de hace un cas ing a T ans e A ibu o de cada elemen o de la lis a de uniques que enía la en idad / elación a la que pe enecía el a ibu o. Comp obamos que, en ealidad, dicha lis a no es á compues a po obje os de los que se pueda hace un cas ing a T ans e A ibu o, sino que es aba compues a po cadenas, obje os de ipo S ing, que indican el nomb e del a ibu o p esen e en la abla unique. Se solucionó es e p oblema usando el mé odo oS ing y eliminando dicho cas ing, con lo cual la abla de uniques ya se ac ualiza co ec amen e y no sal a la excepción. Es e p oblema p o ocaba que, en la cons ucción de algunos ejemplos, la lis a de uniques en el a chi o .xml del p oyec o apa eciese desac ualizada. Debido a ello y a o a si uación que comen amos en el Capí ulo 7, in odujimos algunas modi icaciones en los a chi os de ejemplo que es aban en DBCASE. 5.4 Gua da como XML modelo lógico y ísico Se ag egó una uncionalidad pa a gua da los modelos lógico y ísico en o ma o XML. An e io men e, el menú de gua da pe mi ía gua da los modelos en o ma o de 55 ex o plano (. x ), y el modelo ísico ambién se podía gua da en o ma o SQL (.sql). Sin emba go, pa a mejo a la lexibilidad y la in e ope abilidad, se implemen ó la capacidad de gua da ambos modelos como a chi os XML. Pa a log a es o, se ag egó una nue a opción al menú de gua da y se c eó un nue o mé odo pa a o ma ea la in o mación de los modelos y esc ibi los en a chi os XML. Es o implicó abaja en la es uc u a y el o ma o de los da os pa a ga an iza una ep esen ación cohe en e y legible en el a chi o XML esul an e, lo que pod ía inclui la se ialización de obje os o la con e sión de da os es uc u ados en un o ma o XML álido. La segunda pa e de la a ea consis ía en pode ca ga es os modelos en o ma o XML, pe o no se comple ó. 5.5 Co ecciones en aducción a modelo lógico y ísico Nues o u o nos llamó la a ención sob e el hecho de que, en el ejemplo núme o cinco, algunas elaciones no se es aban aduciendo al modelo lógico con odos los a ibu os que debe ía, como se puede e en la Ilus ación 12. Ilus ación 12: T aducción e ónea en Ejemplo 5 56 T as analiza po qué es aba ocu iendo, imos que se debía a lo siguien e. En la lis a de las elaciones que hay en el p oyec o que se enga abie o, es án incluidas las elaciones IsA, las que iden i ican a una en idad débil, y las de ipo no mal. Los dos p ime os ipos de elaciones ienen una in luencia sob e los a ibu os que se le asocian a una en idad en la aducción. A la ho a de aduci las elaciones, se eco ía la lis a de elaciones y se aducían dichas elaciones en el o den que es u iesen. Es o podía p o oca que una en idad apa eciese en una elación con menos a ibu os de los que al inal acaba eniendo, cuando ya sí que se ha a ado una elación IsA / de iden i icación a la que pe enece. Resol imos es e p oblema haciendo que se a asen p ime o las elaciones IsA / de iden i icación, y po úl imo las elaciones de ipo no mal, ya con las en idades en un es ado es able. No obs an e, había una elación que se seguía aduciendo mal. T as depu a el código imos que, a la ho a de ealiza la aducción al modelo lógico, es aba in e iniendo de una o ma no espe ada una unción llamada il a , p esen e en la clase Tabla. Es a unción se u iliza desde la aducción con el obje i o de sepa a los a ibu os que son cla e p ima ia y los que no lo son. Pa a ello, se le dan dos ec o es, uno con odos los a ibu os y o o con los que son cla e p ima ia, y la unción de uel e un ec o con los elemen os que es án en el p ime o y no en el segundo. El p oblema que ocu ía e a que se podía da el caso de que hubiese dos a ibu os de mismo nomb e y dominio, y la unción no enía en cuen a ese caso, de o ma que eliminaba del ec o esul ado odas las apa iciones, en ez del núme o de apa iciones co espondien e. Pa a soluciona lo, usamos un mapa, que asocia una cadena nomb e-dominio-poseedo con un núme o de apa iciones. De es a o ma, consul ando el mapa y es ando uno en la en ada co espondien e cada ez que se il a un a ibu o, solo se il a á el núme o de eces que apa ezca en el ec o de cla es p ima ias, dejando el es o de las apa iciones en el ec o o iginal. 57 Podemos e en la ilus ación 13 cómo as es os cambios, las elaciones que enían e o es en la aducción ( elaciones en las que in e enían en idades hijas o en idades débiles) se aducen de o ma co ec a. Debido a una si uación que comen amos en el Capí ulo 8, si hay a ibu os de mismo nomb e y dominio en una upla, en ocasiones la imp esión de cla es o áneas y la aducción al modelo ísico gene a esul ados e óneos po que no se desambiguan co ec amen e dichos a ibu os, como ocu e en el ejemplo núme o cinco. Como comen amos en dicho capí ulo, p oponemos in oduci un cambio en el p oceso de desambiguación pa a sol en a es os p oblemas. Ilus ación 13: T aducción de elaciones ac ual de Ejemplo 5 5.6 Ven ana de edi a ca dinalidad y pa icipación In odujimos algunos cambios en el ame dedicado a edi a la ca dinalidad y pa icipación de una en idad en una elación (paque e is a. ames, clase 65 Capí ulo 7 - Cambios en a chi os de ejemplo Como comen amos en la sección 5.3, en ocasiones la abla de uniques no es aba ac ualizada co ec amen e en los a chi os que gene aba la aplicación. Vimos, po o a pa e, que al pa i de un a chi o de ejemplo e in en a hace una nue a asociación en e una en idad y una elación, sal aba una excepción. Es o, sin emba go, no ocu ía con el ejemplo núme o 6. La excepción indicaba que se había a ado de inse a un nodo donde no es aba pe mi ido, y más conc e amen e que no se había encon ado el pad e del nodo a inse a en la en idad, cuyo nomb e e a Rela nLis . C eemos que es o se pudo debe a que los p ime os ejemplos ue on gene ados cuando la aplicación, po alguna azón, no gene aba bien es e nodo. Pensamos que se ía una buena opo unidad pa a oma los ejemplos y gene a los desde ce o, po que se ía una a ea ú il pa a ealiza p uebas sob e nues a aplicación y, además, po que podíamos comp oba si es os p oblemas que habían ocu ido eapa ecían. De es a o ma, podíamos cambia en la ca pe a de ejemplos los a chi os an e io es po los nue os que había gene ado DBCASE. Además, decidimos in oduci algunos cambios en los dominios de algunos a ibu os, en los ejemplos 1 y 4. Hicimos es o con el obje i o de mos a nue os dominios en los ejemplos. 66 Capí ulo 8 - Conclusiones y abajo u u o Desde el p incipio es e p oyec o ha sido muy complejo y un e o pa a noso os ya que nos encon amos con un código muy di ícil de en ende debido a las di e en es i e aciones que ha su ido en las cuales los dis in os g upos de alumnos añadie on di e en es uncionalidades sin a ende a la unicidad del código. A lo la go de los años es o se ua ag a ando has a el pun o en que algunas clases enían el nomb e es español, o as en inglés y lo mismo pasó con los mé odos y a iables. Nues os compañe os del año pasado en es e mismo capí ulo dije on lo siguien e: “El hecho de que el p oyec o se haya ido desa ollando a lo la go de di e sos años supone dos cosas. La p ime a es que ha ido e olucionando de mane a inc emen al, es deci , las uncionalidades se han ido añadiendo una as o a eniendo en cuen a siemp e el es ado del p oyec o en el pasado. La segunda es que han sido muchas las pe sonas que han colabo ado a la implemen ación de DBCASE. Po es os mo i os apa ecen complicaciones a la ho a de la comp ensión del código habi uales en es e ipo de p oyec os. Es ecomendable adap a se a la mane a en que es á implemen ada la aplicación, u iliza una nomencla u a simila en el nomb e de mé odos o a iables, que acla en de un simple is azo cuál es su unción, pa a una mayo legibilidad po pa e de u u os p og amado es” (Ibáñez Ma ínez & De echo P ie o, 2022-2023) Te minamos muy sa is echos con el esul ado inal, ya que la a ea más compleja que ue la e ac o ización del código se log ó. La di icul ad de es o no esidía en hace ehace la lógica de la aplicación sino en hace lo bloque po bloque y asegu a se que seguía uncionando pe ec amen e. En el mes de oc ub e nos encon amos con que la clase p incipal “Con olle ” enía más de 5000 líneas de código, no exis ían ac o ías, ni comandos y el único pa ón de diseño implemen ado e a el Modelo Vis a-Con olado . Al acaba la e ac o ización el p oyec o cons a de una clase “Main” mucho más 67 pequeña, ac o ías abs ac as, ac o ías, comando, e c. Lo que pe mi i á a u u os alumnos pode e oluciona la aplicación de una o ma mucho más ápida. Además, mien as abajábamos en es a e ac o ización uimos capaces de encon a e o es no iden i icados y co egi los. Es e p oceso comenzó en oc ub e con la mig ación a Ma en y la o denación de ecu sos y culminó en el mes de mayo cuando las ul imas alidaciones de la e ac o ización e mina on. A lo la go de es os meses el abajo ha sido i egula con momen os en los que é amos capaces de a anza ápidamen e y o os en los que es ábamos semanas e incluso meses sin e a ances lo cual en cie os momen os llegó a se us an e pe o poco a poco uimos iendo a luz al inal del únel. El p oceso de desa ollo del p oyec o ha sido un iaje lleno de desa íos y ap endizaje. Desde sus inicios, hemos en en ado nume osos ensayos y e o es, así como la ealización de ex ensas p uebas an o del código como de la p opia aplicación. La cu a de ap endizaje, inicialmen e len a, ha ido inc emen ándose g adualmen e a medida que nos sume gíamos más en el p oyec o. Una de las di icul ades que hemos en en ado ha sido la iden i icación de e o es, un p oceso que ha esul ado se cos oso y a menudo con uso. F ecuen emen e nos encon ábamos deba iendo si los p oblemas que encon ábamos e an o iginados po allos en el código ecien emen e c eado o si se a aba de e o es a as ados desde e siones an e io es del so wa e. Es a ince idumb e añadía una capa adicional de complejidad a la esolución de p oblemas, haciendo que cada co ección ue a un desa ío único. Sin emba go, a pesa de los obs áculos, cada hi o alcanzado ha sido mo i o de g an sa is acción. Ve la e olución eal del p oyec o, con la inco po ación de nue as uncionalidades y la educción de e o es co espondien e, nos ha llenado de mo i ación y o gullo po el abajo ealizado. DBCASE, nues a aplicación des inada a la UCM pa a su uso en la asigna u a de Bases de Da os ha sido el cen o de nues o es ue zo y dedicación a lo la go de es e cu so. 68 Al p incipio, nos en en amos a di icul ades y u imos que econs ui el eposi o io dos eces en el mes de sep iemb e. Sin emba go, con el iempo, hemos ap endido a u iliza lo de mane a más e ec i a y hemos descubie o odas las unciones que o ece, como el "Dependabo ale " o los in o mes que p opo ciona pa a e alua la calidad del código gene ado du an e la e ac o ización. De ca a al u u o de DBCASE al an po comple a la mayo ía de los obje i os p opues os pa a es a e sión pe o que debido a la e ac o ización explicada con de alle an e io men e no hemos podido implemen a . A des aca : • Ac ualización de lib e ías - El cambio más impo an e en nues a opinión en la eingenie ía del ende izado del diag ama y la consecuen e ac ualización de las e siones de las lib e ías y e i a así una ulne abilidad de 9,8/10 que pe mi e la ejecución de código emo o. • Añadi Pos g eSQL, SQL Se e y DB2 a los posibles SGBD – Es o ha ía a la aplicación mucho más e sá il ya los es son BBDD elacionales muy u ilizadas a ni el p o esional • Reingenie ía de bases de da os - Consis e en la capacidad de diseña una base de da os a pa i del esquema lógico o ísico, inco po ando las ablas o consul as necesa ias. Pos e io men e, se puede p esen a el esquema concep ual co espondien e. Pa a abo da es a a ea, es esencial codi ica un p oceso sin ác ico que in e p e e los da os in oducidos en los paneles lógico o ísico y gene e los mensajes necesa ios pa a la inse ción de los elemen os en el esquema concep ual. Además, es undamen al inco po a mensajes de e o es o a isos pa a in o ma al usua io sob e posibles p oblemas o inconsis encias en el p oceso de diseño de la base de da os. 69 • Conside amos con enien e el cambio de e sión de Ja a a una supe io como Ja a 11 o Ja a 17, cualquie a de las dos e siones supond ía un cambio de calidad de ida ya que incluyen unciones de o ma na i a que en Ja a 1.8 necesi a de lib e ías ex e nas. El mo i o po el que no se hizo es que el p oyec o iene nume osas dependencias con clases in e nas de Ja a que quedan obsole as en Ja a 9 y no dispusimos de iempo su icien e pa a hace lo. • Desde el p oceso de aducción al modelo lógico, se lle a a cabo un p oceso de desambiguación pa a esol e posibles casos en los que dos a ibu os engan el mismo nomb e, dominio y poseedo en una misma upla. No obs an e, es e p oceso no modi ica el nomb e almacenado del a ibu o en la clase Tabla, sino que se lle a a cabo de ca a a la imp esión en el panel del modelo lógico. Po o a pa e, a la ho a de imp imi las es icciones de cla e o ánea, y a la ho a de gene a el modelo ísico, se lle an a cabo o os p ocesos de desambiguación que son dis in os. Si hay a ibu os de mismo nomb e, dominio y poseedo en una upla, en ocasiones la aducción al modelo ísico gene a esul ados e óneos po que no desambigua co ec amen e dichos a ibu os, y no la hace de la misma o ma que en el modelo lógico. Nos gus a ía p opone un cambio en es e aspec o, pa a log a un p oceso de desambiguación uni o me que modi ique los nomb es de los a ibu os en la clase Tabla al p incipio de la aducción al modelo lógico, y que de esa o ma el modelo lógico, la unción de imp imi es icciones de cla e o ánea, y el modelo ísico accedan a los mismos nomb es en un es ado no ambiguo. A ni el pe sonal, conside amos que es e p oyec o ha sido una opo unidad in aluable pa a el c ecimien o y el desa ollo p o esional. Se ha asemejado mucho a la 70 expe iencia de abaja en un p oyec o en una emp esa, desde la plani icación y dis ibución de a eas has a la comp ensión y adap ación de código ajeno. Además, hemos adqui ido habilidades impo an es en el uso de he amien as como Gi /Gi Hub y Eclipse, así como descubie o nue as posibilidades en el lenguaje de p og amación Ja a. Además, lo la go de es e p oyec o, hemos obse ado cómo nues as habilidades han ido mejo ando p og esi amen e, especialmen e a medida que hemos ecu ido con mayo ecuencia a las opciones de búsqueda de Eclipse e In elliJ. Sin es as he amien as, hab ía sido p ác icamen e imposible abaja en un p oyec o con an as líneas de código. Además, hemos expe imen ado un no able c ecimien o en el uso y dominio de Ja a. 8.1 Obje i os cumplidos Exponemos a con inuación una lis a con los obje i os cumplidos a lo la go del desa ollo del p oyec o. 1. P oyec o cambiado a Ma en pa a acili a la impo ación, la ges ión de las lib e ías de ca a al u u o y la ges ión de ulne abilidades. 2. Rehace la es uc u a de paque es y ehace la impo ación desde una ca pe a RESOURCES. 3. Se ha solucionado el siguien e p oblema: No apa ece la lecha en una elación ecu si a con ca dinalidad 1. 4. C eación de comandos pa a encapsula las uncionalidades más complejas que hace el con olado , y c eación de una ac o ía pa a su uso. 5. Reo ganización de la o ma en que se ob ienen lis as de elemen os desde is as y con olado . 6. Resolución de up u as de a qui ec u a. 7. Es anda ización de los ames de la aplicación usando Pa en _GUI. 8. C eación de una ac o ía pa a la ges ión de los ames que usa la aplicación. 9. Se ha solucionado el siguien e p oblema: Al lle a a cabo cualquie acción que equie a ape u a de iche os, se pie den las es icciones de ca dinalidad 1. 10. Se ha solucionado el siguien e p oblema: En una elación ecu si a con una en idad, la en idad apa ece siemp e con la misma ca dinalidad y pa icipación en el diag ama. 71 11. Encapsulación de la ges ión de los se icios en una ac o ía. 12. Implemen ación de una o ma de aduci algunos enume ados en o os (Fac o iaTCC l). 13. Uso del pa ón Con exo pa a elimina la e e encia que los se icios man enían hacia el con olado . Se elimina on odos los mé odos que es aban en el con olado , que enían la unción de esponde a los mensajes que les en iaban los se icios di ec amen e. C eación de una unción ( a a Con ex o) des inada a euni y gene aliza odas las uncionalidades que lle aban a cabo es os mé odos del con olado . 14. C eación de una ac o ía pa a mensajes de e o . 15. C eación de clase Con ig pa a qui a al con olado la esponsabilidad de almacena algunas a iables de con igu ación, y eliminación de las e e encias que algunas clases man enían del con olado con es e obje i o (po ejemplo, DAOA ibu os). 16. Sepa ación a la clase Main y adap ación del código dedicado a inicializa la aplicación. 17. Sepa ación de algunas unciones de uso gene al (o denación de lis as, pa ición de ec o es...) a una clase especí ica pa a ellas. 18. Cambio y adap ación en la elación de las clases Gene ado Esquema y Validado BD. 19. C eación de una clase abs ac a que implemen a uncionalidad que usan odos los obje os DAO. 20. T aslado de la unción dedicada a la c eación del almacén pe sis en e a la capa de pe sis encia. 21. Ac ualización de muchas lib e ías (pom.xml). 22. Gua da como XML modelo lógico y ísico. 23. Implemen ación de excepciones y manejo de ellas. 24. T aslado a comandos, adap ación y gene alización de código dedicado a la c eación de en idades débiles. 25. Rediseño e implemen ación de con ex o y a a Con ex o pa a que pe mi an a a sub-con ex os de i ados de una ope ación p incipal. 26. T aslado de las clases NodoEn idad y En idadYA idad al paque e de ans e s. 27. Rec eación de a chi os de ejemplos pa a soluciona p oblemas en su es uc u a. 28. Resolución de e o que ocu ía al enomb a un a ibu o unique. 29. C eación de diag amas de clase UML pa a odos los paque es y sub-paque es de la aplicación. 72 30. C eación de diag amas de secuencia pa a un caso de uso comple o de la aplicación (edi a el campo no -null de un a ibu o). 31. C eación de diag amas de secuencia pa a algunas nue as in e acciones (ejecu a un comando, ac i ación de ame usando Fac o iaGUI, a a con ex o). 32. Resolución de p oblemas en la aducción de cie as elaciones al modelo lógico / ísico ( e sección 5.5). 33. Ac ualización de la en ana dedicada a edi a ca dinalidad y pa icipación pa a que mues e los alo es que se ienen almacenados según la en idad y ol que se elija. 73 In oduc ion DBCASE 4.0 is a desk op applica ion ocused on he design and implemen a ion o SQL ela ional da abases. By designing a concep ual model, i gene a es he logical and physical models, also allowing o he implemen a ion o he la e . A ela ional da abase is a ype o da abase ha o ganizes in o ma ion in o ela ed ables. I is based on he ela ional model p oposed by Edga F. Codd in he 1970s. In his model, da a is s o ed in ables wi h ows and columns. Each ow ep esen s a speci ic en i y, and each column ep esen s an a ibu e o ha en i y. Rela ionships be ween en i ies a e es ablished by ma ching alues in speci ic columns (p ima y keys and o eign keys). In a ela ional da abase, da a in eg i y is main ained h ough cons ain s such as p ima y and o eign keys, which ensu e he cohe ence and consis ency o he da a. Addi ionally, i uses a s uc u ed que y language (SQL) o pe o m ope a ions such as inse ing, upda ing, dele ing, and que ying da a. A he Facul y o In o ma ics, in he di e en deg ee p og ams i o e s, ela ional da abases a e used in a mul i ude o subjec s such as Da abases, Ad anced Da abases, So wa e Enginee ing, e c. Howe e , his wo k will be especially use ul o Da abase s uden s since i is in he subjec whe e he undamen als o da abase design a e p esen ed and whe e s uden s begin o design hei i s En i y-Rela ionship diag ams and lea n he basic syn ax o SQL and MySQL. 80 alida ions o he e ac o ing we e comple ed. Th oughou hese mon hs, he wo k has been i egula , wi h momen s whe e we we e able o p og ess apidly and o he s whe e we wen weeks o e en mon hs wi hou seeing p og ess, which a imes was us a ing, bu g adually we saw he ligh a he end o he unnel. The p ojec de elopmen p ocess has been a jou ney ull o challenges and lea ning. F om he beginning, we aced nume ous ials and e o s, as well as ex ensi e es ing o bo h he code and he applica ion i sel . The lea ning cu e, ini ially slow, g adually inc eased as we del ed deepe in o he p ojec . One o he di icul ies we aced was iden i ying e o s, a p ocess ha p o ed o be cos ly and o en con using. We equen ly deba ed whe he he p oblems we encoun e ed o igina ed om laws in he newly c ea ed code o i hey we e issues inhe i ed om p e ious e sions o he so wa e. This unce ain y added an addi ional laye o complexi y o p oblem-sol ing, making each co ec ion a unique challenge. Howe e , despi e he obs acles, each miles one achie ed has been a sou ce o g ea sa is ac ion. Seeing he eal e olu ion o he p ojec , wi h he inco po a ion o new unc ionali ies and he co esponding educ ion o e o s, has illed us wi h mo i a ion and p ide o he wo k done. DBCASE, ou applica ion des ined o use a UCM in he Da abases subjec , has been he ocus o ou e o and dedica ion h oughou his cou se. Ini ially, we aced di icul ies and had o ebuild he eposi o y wice in Sep embe . Howe e , o e ime, we lea ned o use i mo e e ec i ely and disco e ed all he ea u es i o e s, such as he "Dependabo ale " o he epo s i p o ides o assess he quali y o he code gene a ed du ing he e ac o ing. 81 Looking ahead o he u u e o DBCase, mos o he p oposed objec i es o his e sion emain o be comple ed, bu due o he de ailed e ac o ing explained ea lie , we ha e no been able o implemen hem. Key highligh s include: • Upda ing lib a ies: The mos impo an change in ou opinion is he eenginee ing o he ende ing o he diag am and he consequen upda e o he e sions o he lib a ies o a oid a ulne abili y a ing o 9.8/10 ha allows emo e code execu ion. • Adding Pos g eSQL, SQL Se e , and DB2 o possible DBMS: This would make he applica ion much mo e e sa ile as all h ee a e widely used ela ional da abases in p o essional se ings. • Da abase eenginee ing: This in ol es he abili y o design a da abase om he logical o physical schema, inco po a ing he necessa y ables o que ies. Subsequen ly, he co esponding concep ual schema can be p esen ed. To add ess his ask, i is essen ial o code a syn ac ic p ocess ha in e p e s he da a en e ed in he logical o physical panels and gene a es he necessa y messages o he inse ion o elemen s in o he concep ual schema. Addi ionally, i is c ucial o inco po a e e o o wa ning messages o in o m he use abou possible p oblems o inconsis encies in he da abase design p ocess. • We conside i con enien o upg ade he Ja a e sion o a highe one such as Ja a 11 o Ja a 17. Ei he o hese e sions would esul in a be e quali y o li e as hey include na i e unc ions ha in Ja a 1.8 equi e ex e nal lib a ies. The eason we didn' do so is ha he p ojec has nume ous dependencies wi h in e nal Ja a classes ha become obsole e in Ja a 9, and we didn' ha e enough ime o do i . • F om he ansla ion p ocess o he logical model, a disambigua ion p ocess is ca ied ou o esol e possible cases in which wo a ibu es ha e he same name, 82 domain, and holde in he same uple. Howe e , his p ocess does no modi y he s o ed name o he a ibu e in he able class bu is ca ied ou o p in ing in he logical model panel. On he o he hand, when p in ing o eign key cons ain s, and when gene a ing he physical model, o he disambigua ion p ocesses a e ca ied ou which a e di e en . I he e a e a ibu es o he same name, domain, and holde in a uple, some imes he ansla ion o he physical model gene a es e oneous esul s because i does no disambigua e hese a ibu es co ec ly and does no do i in he same way as in he logical model. We would like o p opose a change in his aspec , o achie e a uni o m disambigua ion p ocess ha modi ies he a ibu e names in he able class a he beginning o he ansla ion o he logical model, so ha he logical model, he o eign key cons ain p in ing unc ion, and he physical model access he same names in an unambiguous s a e. On a pe sonal le el, we conside his p ojec o ha e been an in aluable oppo uni y o g ow h and p o essional de elopmen . I closely esembled he expe ience o wo king on a p ojec in a company, om planning and ask dis ibu ion o unde s anding and adap ing o o he s' code. Addi ionally, we ha e acqui ed impo an skills in using ools such as Gi /Gi Hub and Eclipse, as well as disco e ing new possibili ies in he Ja a p og amming language. Th oughou his p ojec , we ha e obse ed how ou skills ha e p og essi ely imp o ed, especially as we ha e u ned mo e equen ly o he sea ch op ions in Eclipse and In elliJ. Wi hou hese ools, i would ha e been p ac ically impossible o wo k on a p ojec wi h so many lines o code. Addi ionally, we ha e expe ienced a no able g ow h in he use and mas e y o Ja a. Lis o achie ed goals The ollowing is a lis o he objec i es achie ed du ing he de elopmen o he p ojec . 83 1. P ojec changed o Ma en o acili a e he impo , he managemen o lib a ies o he u u e and he managemen o ulne abili ies. 2. Redo he package s uc u e and edo he impo om a RESOURCES olde . 3. Fixed he ollowing p oblem: The a ow does no appea in a ecu si e ela ion wi h ca dinali y 1. 4. C ea ed commands o encapsula e he mo e complex unc ionali ies ha he con olle does and c ea ed a ac o y o hei use. 5. Reo ganiza ion o he o m in which lis s o elemen s a e ob ained om iews and con olle . 6. Resol ing a chi ec u e b eaks. 7. S anda diza ion o applica ion ames using Pa en _GUI. 8. C ea ion o a ac o y o he managemen o he ames used by he applica ion. 9. The ollowing p oblem has been sol ed: When ca ying ou any ac ion ha equi es opening iles, he ca dinali y 1 es ic ions a e los . 10. The ollowing p oblem has been sol ed: In a ecu si e ela ionship wi h an en i y, he en i y always appea s wi h he same ca dinali y and pa icipa ion in he diag am. 11. Encapsula ion o he managemen o se ices in a ac o y. 12. Implemen a ion o a way o ansla e some enume a ed elemen s in o o he s (Fac o iaTCC l). 13. Use o he Con ex pa e n o elimina e he e e ence ha he se ices main ained owa ds he con olle . All he me hods in he con olle , which had he unc ion o esponding o he messages sen o hem di ec ly by he se ices, we e elimina ed. C ea ion o a unc ion ( a a Con ex o) o ga he and gene alize all he unc ionali ies ca ied ou by hese con olle me hods. 84 14. C ea ion o an e o message ac o y. 15. C ea ion o a Con ig class o emo e om he con olle he esponsibili y o s o ing some con igu a ion a iables, and elimina ion o he e e ences ha some classes main ained om he con olle o his pu pose ( o example, DAOA ibu os). 16. Sepa a ion o he Main class and adap a ion o he code dedica ed o ini ializing he applica ion. 17. Sepa a ion o some gene al use unc ions (lis so ing, ec o pa i ioning...) o a speci ic class o hem. 18. Change and adap a ion o he ela ionship be ween he classes Gene ado Esquema and Validado BD. 19. C ea ion o an abs ac class ha implemen s unc ionali y used by all he DAO objec s. 20. T ans e o he unc ion dedica ed o he c ea ion o he pe sis en s o e o he pe sis ence laye . 21. Upda ing o many lib a ies (pom.xml). 22. Sa ing as XML logical and physical model. 23. Implemen a ion o excep ions and excep ion handling. 24. T ans e o commands, adap a ion and gene aliza ion o code dedica ed o he c ea ion o weak en i ies. 25. Redesign and implemen a ion o Con ex o and a a Con ex o o allow he ea men o sub-con ex s de i ed om a main ope a ion. 26. T ans e o he classes NodeEn i y and En i yYA i y o he ans e s package. 27. Rec ea ion o example iles o sol e p oblems in hei s uc u e. 28. Resolu ion o an e o ha occu ed when enaming a unique a ibu e. 85 29. C ea ion o UML class diag ams o all packages and sub-packages o he applica ion. 30. C ea ion o sequence diag ams o a comple e use case o he applica ion (edi ing he no -null ield o an a ibu e). 31. C ea ion o sequence diag ams o some new in e ac ions (execu e a command, ame ac i a ion using Fac o iaGUI, a a Con ex o). 32. Resolu ion o some p oblems in he ansla ion o ce ain ela ions o logical physical model (see sec ion 5.5). 33. Upda ing o he ame dedica ed o modi ying ca dinali y and pa icipa ion o i o show he s o ed alues gi en a ce ain en i y and ole. 87 CONTRIBUCIONES PERSONALES I án Pisone o Díaz Como se comen a a lo la go de es a memo ia, ambos es udian es p opusie on ealiza una e ac o ización del código. T as conclui ambos en que se ía bueno a a de disminui el amaño del con olado y empeza a encapsula algunas de las uncionalidades más complejas en comandos, I án comenzó a desa olla la es uc u a que aho a iene la aplicación en cuan o a los comandos. Después, con o me se ue comp endiendo mejo la aplicación, I án p opuso e implemen ó el es o de los cambios que se desc iben en el capí ulo dedicado a la e ac o ización. El p oceso de la iden i icación de posibles cambios a ealiza y su implemen ación ue un p oceso g adual: nue as ideas su gían con o me se a anzaba, y ambién con o me se a anzaba iban su giendo p oblemas que no se habían enido en cuen a y que e a p eciso soluciona y e alua , es o e a pues o en común y discu ido po ambos en nume osas euniones. En línea con es o, y en gene al pa a consegui un so wa e de la mayo calidad posible, I án ealizó pa e de las p uebas desc i as en el capí ulo 6, con o me se iba a anzando en los cambios p opues os y ambién una ez concluidos. I án se enca gó de ealiza los diag amas que se pueden e a lo la go de es e documen o y en el modelo IBM RSAD. Además, jun o con Ja ie , e aluó con de alle el p oblema del ende izado de elaciones e implemen ó las soluciones desc i as en las secciones 5.1 y 5.2. Es o lle ó 88 bas an e iempo debido a que el ende izado, como se puede e los diag amas de las ilus aciones 17 y 39, es un p oceso bas an e complejo que hace uso de lib e ías que no conocíamos y de una g an can idad de clases. Familia iza se con es e p oceso ue un e o, pa a el que ambién la ealización de diag amas p o isionales esul ó de g an ayuda. Den o ambién del ámbi o de la ende ización, I án ealizó algunas en a i as pa a soluciona el p oblema con las e ique as de los oles en las elaciones ecu si as que comen amos en la sección 5.2. Como comen amos, no se llegó a una solución sa is ac o ia. I án ealizó los cambios desc i os en las secciones 5.5 y 5.6. Ambos es udian es compa a on ambién casos de uso y soluciones pa a llega a lo desc i o en la sección 5.3 y en el capí ulo 7. En es a memo ia, I án ha con ibuido en los capí ulos: • Capí ulo 2 - Modelo y diag amas UML • Capí ulo 4 - Re ac o ización del código • Capí ulo 5 – Nue as uncionalidades • Capí ulo 6 - P uebas • Capí ulo 7- Cambios en a chi os de ejemplo • Apéndices A y B. • Maque ación y e isión 89 Ja ie de Vicen e Vázquez Una ez c eado el eposi o io de Gi Hub y habe analizado la lis a de obje i os y el código, decidió en e ambos es udian es que lo óp imo se ía hace una e ac o ización de la mayo ía del código. Es á ue la p ime a y más impo an e decisión omada nada más comenza el p oyec o y ocupa ía la mayo pa e del iempo. La p ime a a ea eal ue la mig ación del p oyec o a Ma en explicada en el Capí ulo 3, e impo a odas las lib e ías e i icando compa ibilidades e in en o ac ualiza las en la medida de lo posible. Pos e io men e hizo ees uc u ación de ca pe as y de ecu sos es anda izando nomb es y c eando las clases con los S ings pa a acili a la impo ación de es os y se p obó en de alle que es os cambios no ompían nada. Una ez e minada es a mig ación jun o con I án empeza on a e cómo p ocede a la e ac o ización, aquí uno de los p incipales p oblemas ue que la es imación hecha in a alo ó mucho el iempo que se oma ía el hace la, ya que los planes o iginales e an e mina la en ene o, du an e ese iempo I án se dedica ía al 100% a la mig ación y Ja ie a la lis a de obje i os. Has a el mes de diciemb e in en ó a anza con la lis a de obje i os ma cados po el u o (Capí ulo 5). Desde el p incipio a anza con los obje i os e a muy di ícil po a ios mo i os, el p ime o el código e a muy di ícil de segui y hace cualquie cambio lle aba semanas, y el segundo, I án abajaba simul áneamen e en la e ac o ización, po lo que cada cambio p o ocaba in inidad de con lic os en Gi Hub ya que mien as en una ama se abajaba en los obje i os, en la o a se cambiaban las mismas clases y mé odos con inuamen e. 96 Diag ama Ilus ación 17: Diag ama de clase paque e is a.diag ama 97 Geome ía Ilus ación 18: Diag ama de clase paque e is a.diag ama.geome ia Líneas Ilus ación 19: Diag ama de clase paque e is a.diag ama.lineas F ames Ve ilus ación 2. 98 Iconos Ilus ación 20: Diag ama de clase paque e is a.iconos 99 Pe spec i a Ilus ación 21: Diag ama de clase paque e is a.iconos.pe spec i a 100 Tema Ilus ación 22: Diag ama de clase paque e is a. ema 101 U ils Ilus ación 23: Diag ama de clase is a.u ils Con olado Ve ilus ación 3. Comandos Ve ilus ación 4. 102 Ag egación Ilus ación 24: Diag ama de clase paque e con olado .comandos.ag egacion 103 A ibu o Ilus ación 25: Diag ama de clase paque e con olado .comandos.a ibu o Dominio Ilus ación 26: Diag ama de clase paque e con olado .comandos.dominio 104 En idad Ilus ación 27: Diag ama de clase paque e con olado .comandos.en idad Relación Ilus ación 28: Diag ama de clase paque e con olado .comandos. elacion 105 Vis as Ilus ación 29: Diag ama de clase paque e con olado .comandos. is as Modelo Se icios Decidimos ealiza a ios diag amas de clase pa a es e paque e, dado que en uno solo se condensaba demasiada in o mación que hacía que el diag ama uese menos ú il. En el diag ama que exponemos en la ilus ación 6 mos amos la es uc u a del paque e a excepción de la clase Gene ado Esquema y o as clases ela i as a la ges ión del esquema. 112 Ilus ación 37: Diag ama de secuencia negocio edi a no -null a ibu o 113 Ilus ación 38: Diag ama de secuencia pe sis encia modi ica a ibu o 114 Pa a e el diag ama de secuencia de a a Con ex o, e ilus ación 7. Ilus ación 39: Diag ama de secuencia Modi ica Valo In e no (clase PanelG a o, paque e is a.diag ama) Pa a e el diag ama de secuencia de ejecu a comando, e ilus ación 5. 115 Ilus ación 40: Diag ama de secuencia comunicación GUIP incipal – Con olado Ilus ación 41: Diag ama de secuencia ac i ación de ame po con olado