Sistema Manejador de Versiones para Esquemas Entidad-Relación

Transcripción

1 Sistema Manejaor e Versiones para Esquemas Entia-Relación Carla Demarchi, Valeria Irazabal, Alicia Revello, Raul Ruggia Instituto e Computación - Faculta e Ingenieria - Uruguay fing.eu.uy La moelarización conceptual e bases e atos no es un proceso lineal. Su naturaleza e prueba y error genera múltiples versiones antes e llegar a la solución efinitiva el Esquema Conceptual. Un Manejaor e Versiones es un sistema que permite organizar los conjuntos e versiones intermeios urante el esarrollo el proucto. En otras áreas tales como CAD (Compute-Aie Design) y SE (Software Engeneering) la aministración e versiones ha sio ampliamente aplicaa. No así en Base e Datos. Por lo tanto la motivación para construir un Manejaor e Versiones para esquemas Entia-Relación (ER) surge e esta carencia así como el interés por eplotar propieaes e los esquemas ER que no se cumplen en el software general, por ejemplo las que permiten integrar y comparar esquemas ER. Este artículo escribe un sistema Manejaor e Versiones para esquemas ER esarrollao en el conteto e un proyecto e grao. El sistema propuesto aplica los conceptos básicos el manejo e versiones (versión, erivación) e introuce otros, nuevos, orientaos a los esquemas ER. Un ejemplo e éstos es la relación e inclusión entre esquemas, la cual organiza los conjuntos e versiones e acuero a las características e su estructura. Dentro e un ambiente CASE, el Manejaor e Versiones eporta primitivas para el manejo e versiones. Por lo tanto, centraliza la organización e los esquemas ER y unifica el esarrollo e los prouctos, inclusive con aquellos que fueron esarrollaos con otras metoologías. 1. INTRODUCCION La Moelización Conceptual e Bases e Datos no es un proceso lineal sino e naturaleza eploratoria, el cual a origen a múltiples versiones e trabajo antes e alcanzar el esquema conceptual final e una base e atos. Cuano esarrolla un esquema conceptual, el iseñaor eplora iferentes alternativas e iseño y retiene algunas en estao intermeio. Esto le permite fijar puntos e iseño significativos así como retornar a estaos anteriores si los subsiguientes no conujeron a un iseño mejor. Más aun, el iseñaor habitualmente esea mantener la traza e las ecisiones que tomó a lo largo el proceso e iseño, esta traza constituye información valiosa acerca el conocimiento aplicao en la resolución el problema. Los Manejaores e Versiones son sistemas que permiten organizar el conjunto e versiones intermeias que se obtienen en el esarrollo e un proucto. En la Moelización e Bases e Datos, el proucto a ser esarrollao es un esquema conceptual, y las versiones intermeias serán esquemas que resultan e iferentes opciones e iseño y iferentes estaos en su historia e iseño.

2 Este artículo propone un Manejaor e Versiones para esquemas conceptuales Entia-Relación (ER). Este sistema se inserta en un ambiente CASE para iseño e bases e atos, permitieno que las iferentes herramientas hagan uso el mecanismo e versiones. Panorama el estao el arte. A pesar e las motivaciones eistentes, los ambientes para Diseño e Bases e Datos carecen e mecanismos e manejo e versiones. Este problema ha sio ampliamente reconocio en la literatura [Jark 92][Roll 92] pero ha sio parcialmente resuelto a través e propuestas que se focalizan en aspectos e traceao mas eque en la organización e las versiones [Jark 92]. Por otro lao, en otras áreas como CAD (Compute-Aie Design) e Ingeniería e Software, el manejo e versiones ha sio consierao a través e Moelos e Versiones (Version Moels) y e Sistemas [Katz 90][Tych 82][Estu 94]. Brevemente, un Moelo e Versiones efine que es una versión en un conteto e trabajo, como se organizan y qué operaciones son aplicables sobre ellas. Estos aspectos son fuertemente epenientes el tipo e proucto a ser esarrollao (p. Ej., circuitos VLSI, software, esquemas conceptuales). Un Mecanismo Manejaor e Versiones implementa un Moelo e Versiones. Los mecanismos e manejo e versiones también ha sio aplicaos con otros objetivos iferentes e la organización e prouctos e iseño. Otros os son: la optmización e espacio e almacenamiento a través e objetos elta, y mecanismos para asegurar la coherencia e una base e atos frente a operaciones e evolución. En Ingeniería e Software los estuios realizaos inican que el 30 % el tiempo e iseño es utilizao para esarrollar nuevo software y la mayor parte el tiempo moificar cóigo eistente. En este conteto, la mayoría e los sistemas aplican conceptos introucios en los mecanismos SCCS y RCS. En SCCS [Rock 75], un objeto (archivo) es una secuencia e revisiones, na para caa cambio en objeto. El sistema RCS [Tych 82] es una etensión e SCCS y consiera que la evolución no es una simple secuencia e revisiones sino un árbol one caa rama (variante) sigue su propia evolución como una sucesión e revisiones. Casi toos los prouctos comerciales siguen la solución propuesta por SCCS y RCS. Estos pueen clasificarse en generaciones. 1ª generación: Basaa en Archivos La primera generación e herramientas proveía lo que comúnmente se conoce como Control e Versiones. Estas eran herramientas que estaban basaas en archivos (meta archivos), en los que almacenaban los cambios realizaos en archivos iniviuales. Los meta archivos guaraban los contenios y los meta atos (nombre e usuario, etiquetas, etc.) por caa versión e archivo. Los prouctos que se incluyen en esta primera generación son: SUN Microsystem Team Ware, Intersolv PVCS, MKS Source Integrity Los os últimos, agregaron sobre los meta archivos una capa e meta atos e proyectos y funcionaliaes aicionales. 2ª generación: Basaa en Repositorios e Proyectos Son fáciles e ientificar porque almacenan too el proyecto y el archivo e metaatos en una base e atos (repositorio) que esta separaa e los meta archivos. Esta arquitectura traslaa el foco el nivel e archivos al nivel el proyecto. Esto resulta en una mejora en el soporte el esarrollo en paralelo, la coorinación el equipo y provee la infraestructura necesaria para llevar a cabo el manejo e procesos. Algunos e los prouctos involucraos: Microsft Visual SourceSafe, IBM CMVC, TrueSoftware, Aie-e-Camp/Pro, Platinum CCC, SQL Software PCMS 3ª generación: Basaa en la transparencia e archivos Una restricción e las herramientas que pertenecen a la seguna generación es que los archivos que controlan no pueen ser acceios ese otras herramientas, a menos e ser copiaas ese el repositorio. Esto puee traer como consecuencia la proliferación e copias locales y el riesgo e sobrescribir el repositorio. La tercera generación e herramientas precisamente agrega la "transparencia e archivos".

3 Los prouctos son: Aria ClearCase, Continuus Continuus/CM ClearCase implementa la transparencia e archivos con un sistema e archivos (MVFS) que intercepta las llamaas e acceso a los archivos (abrir(), leer(), etc.) y las re irige al repositorio. Continuus/CM provee un acceso irecto a los archivos creano uniones ese el área e trabajo el usuario a sus irectorios ocultos. En los sistemas e CAD, el énfasis se pone sobre la estructura e los objetos compuestos y en su versionamiento ese una perspectiva e base e atos. Un objeto e iseño es un agrupamiento coherente e componentes manejao como una unia. Un survey sobre estos sistemas puee encontrarse en [Katz 90]. Aemás [Katz 90] propone tres aspectos hoy por hoy clásicos: la historia e versiones, configuraciones y equivalencia entre versiones. Más recientemente, [Ahme 91] propone un mecanismo e manejo e versiones para bases e atos CAD. Las principales características son: (i) la istinción entre objetos genéricos, versionaos y no versionaos, one los objetos genéricos tienen asociaos un conjunto e versiones; (ii) la clasificación e los atributos e los objetos en invariantes, significativos y no significativos. Esta clasificación es la base para la creación automática e versiones: la moificación e un atributo invariante lleva a la creación e un nuevo objeto, mientras que la moificación e un atributo significativo lleva a crear una versión. En [Tale 93] se sigue un encare similar pero efinieno atributos sensibles, cuya moificación lleva a la erivación e una nueva versión. Resumieno, el manejo e versiones en Ingeniería e Software y CAD ifiere por la naturaleza e los objetos moelaos. En Ingeniería e Software, la granularia más pequeña es la e archivo o proceimiento, y en general no hay una semántica real asociaa a estos. Mientras que en CAD se trabaja con objetos estructuraos que tienen una clara semántica asociaa. Cuales e estás técnicas pueen ser aplicaas para Manejo e Versiones en la Moelización Conceptual e Bases e Datos? A pesar que varios conceptos generales y moelos pueen ser tomaos e las técnicas eistetes, algunos no pueen ser aplicaos sobre esquemas conceptuales (p. Ej., la noción e objeto compuesto). Por otro lao, interesa poer aplicar técnicas específicas al manejo e esquemas conceptuales como ser mecanismos e comparación e integración e esquemas. El Sistema Manejaor e Versiones propuesto en este artículo incluye un Moelo e Versiones y su implementación. El Moelo e Versiones aopta varios conceptos clásicos como ser las nociones e erivación e versiones, y alternativas, e introuce otros nuevos que son específicos a esquemas ER: una relación e inclusión para organizar las versiones según las características e las estructuras ER que permite efinir criterios automáticas para erivación automática e versiones, y la aplicación e operaciones e integración e esquemas para resolver la fusión e versiones. El Moelo e Versiones subyacente al sistema, se basa en os conceptos: Conjunto e Versiones y Relaciones entre ellas. Una versión es un esquema ER. Las relaciones son os, erivación e inclusión. Caa relación efine un grafo entro el conjunto e versiones. Eisten operaciones sobre el conjunto e versiones, sobre los grafos y sobre las versiones. Por ejemplo: crear un conjunto e versiones, erivar una versión, borrar un subgrafo, crear una nueva versión, etc. El sistema Manejaor e Versiones esta implementao en C++ y su arquitectura es C/S/S (Servior e Versiones y Servior e operaciones sobre esquemas Entia Relación). El Servior e Versiones provee e las primitivas para la creación, inserción y borrao e versiones. El mismo ofrece estas primitivas a través e una interface Remote Proceure Call (RPC). Se construyó una herramienta para manejo interactivo e versiones, la cual es un cliente el Servior e Versiones. La misma se conecta al Servior e Versiones como un cliente especializao. La comunicación RPC entre los clientes y los os serviores se realizó e forma e separar caa proceso e inepenizar e la herramienta con que se conecte.

4 Finalmente, el sistema Manejaor e Versiones formará parte e un ambiente CASE esarrollao en un ambiente universitario, para el iseño e sistemas e información. El resto el artículo se estructura e la forma siguiente. La sección 2 presenta el Moelo e Versiones. La Sección 3 presenta el iseño e implementación el sistema. La Sección 4 presenta algunas conclusiones y perspectivas e trabajo futuro. 2. EL MODELO DE VERSIONES El problema e aministración el iseño es que los objetos compuestos pueen tener muchas alternativas si las componentes también tienen versiones. Traicionalmente los sistemas e atos aministran una estructura regular e atos sin versiones e sus objetos componentes. A pesar que la relación e composición es importante no es aecuaa para moelar esquemas ER en un ambiente inámico e esarrollo. Los objetos en el Moelo Un Moelo e Versiones esta basao en os conceptos principales: Proyecto e Moelación Conceptual (CMP), y versiones pertenecientes al CMP. Mientras que las versiones moelan un objeto ao (esquema entia relación, fuente, etc.) en un eterminao paso el proceso e iseño, el CMP moela el conjunto e versiones cuyos elementos representan una aplicación el Sistema e Información. Este Moelo e Versiones efine que es una versión en el proceso e iseño, como se relacionan y organizan las mismas y que operaciones poemos aplicar sobre una versión o sobre el conjunto e versiones. Una versión consiste e un ientificaor e versiones (entro e un CMP), un nombre, el tipo e la versión, un estao e esarrollo y una referencia al ambiente e trabajo al que pertenece. Definición: VERSION Una versión es una quíntupla: <i, nombre, tipo, estao, ambiente> one: i: ientifica a la versión en el conjunto e versiones nombre: es una etiqueta que nombra a la versión tipo: establece el tipo e la versión (ej: esquemas ER, biblioteca, fuente, etc.) estao: es el estao e la versión y puee ser {borraor, analizao, completo, valiao}. El mismo inica si la versión es un borraor, si ha pasao un análisis sintáctico, si incluye toas las eclaraciones requerias para la integria ó si ha sio valiaa e acuero a un conjunto e criterios e calia. ambiente: pertenece a {público} U Nombre_Usuarios. La referencia al ambiente e trabajo establece si la versión pertenece a un ambiente privao o a uno público. Relación e erivación Una versión v eriva e otra vs si ha sio creaa como un proucto e iseño subsecuente e vs. En un conjunto e versiones, caa versión se relaciona con las emás a través e esta relación. La relación e erivación representa si una versión moela una nueva solución o si eriva e una ya eistente, aemás e mantener la evolución histórica e los objetos iseñaos. La relación e erivación efine un árbol, llamao ARBOL DE DERIVACION, one los noos son las versiones el CMP. El árbol e erivación también es enominao ARBOL HISTORICO DE VERSIONES porque mantiene un histórico e la evolución e las versiones.

5 Es importante remarcar que la relación e erivación no implica que eista alguna relación semántica entre las versiones. Si v eriva e vs significa que: 1. Ambas pertenecen al mismo conjunto e versiones (CMP) 2. La versión erivaa v ha sio construia luego e su origen vs. 3. El iseñaor ha eciio unir v como el siguiente a vs en la secuencia e iseño en el moelo conceptual. Definición: relación e erivación La relación e erivación en un conjunto e versiones, se efine e la siguiente manera: o Ž ( V V) v1 o v2 œ v2 es erivaa a partir e v1 La relación o satisface las siguientes propieaes: - ( v1, v2 V) ( v1ov2 Ÿ v2 ov1 ) Anti-Simétrica y Anti-Refleiva - ( v1, v2, v3 V) ( v1 ov2 š v3 ov2 Ÿ v3 = v1 ) Único Ancestro La relación e erivación efine un árbol one el conjunto e noos es V (el conjunto e versiones) y los arcos corresponen a los pares e versiones relacionaas a través e la relación o. Relación e Inclusión Diremos que v incluye a v si las entiaes y relaciones efinias en v tiene un corresponiente en v Para eterminar la corresponencia entre os versiones efinimos la función M. Sea los esquemas ER S, S que tienen asociaos un conjunto e entiaes E y un conjunto e relaciones R La relación e inclusión entre los os esquemas ER se efine: S S œ ( ( E ) ( E ) (M (E,E )) š ( R R ) ( R R) (M (R,R )) ) De esta forma la función M quea efinia a partir e los nombres e las entiaes y relaciones e los esquemas ER.

6 ¾ Conocimiento Eistente ¾ Sistem a ¾ Im pl em en ta ció n ¾ Conclusiones Para lo cual eberíamos seguir un parón e nomenclatura para los objetos que pertenezcan al mismo, e forma e que esta función puea eterminar las relaciones eistentes Definición: relación e inclusión Dao un esquema ER la relación e inclusión en un conjunto e versiones se efine: one: o Ž ( ) v 2o v1 œ (v2.esquema v 1.esquema š v1.i z v 2.i š ( v ) (v.i zv 1.i š v.i zv2.i š v2 ov š vov1 ) ) La o relación efine un grafo irigio <,A> one es el conjunto e noos y A es el conjunto e noos relacionaos a través e o. La relación e inclusión efine un grafo enominao GRAFO DE INCLUSION. Dicho grafo nos brina una visión acerca e las características e los esquemas ER incluios en las versiones. Permite al iseñaor ientificar las versiones cuyos esquemas tienen características en común. La relación e inclusión se calcula caa vez que el conjunto e versiones (CMP) es moificao. Eample: A CMP an its Inclusion Graph. The figure shows the Professor CMP (cf. Section 5.2). Its version set is viewe in the Derivation Tree form. The erivation relations that hol are: {Profs_Teachers Profs_Department, Profs_Projects_Emps Profs_Projects, Profs_Projects_Emps Profs_Projects } Contenio ¾ Introucción o Figure 7.2. The inclusion relationship in Professor CMP. Causas e la elección e la tecnología JSP Las páginas JSP correctamente sobre un servior web Apache con Tomcat, ambos e ominio público. Escribir una vez, ejecutar en cualquier lugar. JSP soporta la separación e roles: iseñaores gráficos y programaores. Acceso web para arquitectura e aplicaciones e N capas. Otra Opción: S Páginas ASP (Microsoft, IIS) Relación e Construcción Moela como las versiones han sio construias a partir e otras versiones. Una relación e construcción entre os versiones v1 y v2 a través e una epresión e tipo <ep> significa que la versión v2 ha sio construia a partir e v1 aplicano <ep>. Esta relación se aplica en la reutilizacion e componentes. Definición: relación e construcción

7 Consieramos un conjunto e CMP y un conjunto e componentes reusables RSC. o Ž (( is RSCis ) Esq_ep is ) o o v œ (v.esquema =eec(ep) Ÿ o ref_schema (ep) ) one: ies es la union el CMP-name y version_i que ientifican e forma única a una versión en el conjunto e CMP. RSCis es el conjunto e ientificaores e los esquemas reusables. ref_schema (ep) es una función que evuelve el conjunto e esquemas referenciaos por ep. Dao un conjunto e CMP una restricción e construcción es un preicao e la siguiente forma: construcction_constraint(o,ep,v) Ÿ (Para too e Vi ) o o v La relación e construcción se eclara sobre versiones por lo que toas las versiones que se eriven a partir e esta no herean esta relación e construcción. Por lo que la creación y la erivación e nuevas versiones no afecta esta relación. Las tres relaciones efinen un espacio e visualización y organización e las versiones: la relación e erivación representa las ramas e iseño y la evolución histórica e las versiones la relación e construcción representa como las versiones han sio construias. la relación e inclusión relaciona versiones con esquemas ER. CMP Un CMP es el resultao e moelar una situación el muno real a través e un moelo conceptual e esquemas ER CMP = <nombre,v,vc,o,ÿ) Done nombre:etiqueta que lo ientifica V: conjunto e versiones el CMP que moelan la situacion. Vc: versión corriente el conjunto.

8 o: relación e erivación entre las versiones e V. Ÿ:relación e inclusión entre las versiones e V. Operaciones Las operaciones en el Moelo e Versiones permiten manipular versiones y conjuntos e versiones. A continuación presentamos las posibles operaciones que se porían aplicar a un Moelo Conceptual Genérico e Versiones. Las agrupamos en tres categorías: operaciones sobre un CMP, operaciones sobre versiones y operaciones sobre grafos e versiones. Operaciones sobre un CMP create_cmp ( string nombre_cmp): Un CMP es creao a través el operaor create_cmp, el cual crea el conjunto e versiones como un conjunto vacío. elete_cmp (string nombre_cmp) Elimina un Moelo Conceptual Genérico incluyeno su conjunto e versiones. open_cmp Se utiliza para abrir un CMP save_cmp (string nombre_cmp) Salva un CMP close_cmp (string nombre_cmp) Cierra un moelo conceptual generico. Operaciones sobre versiones create_version (CMP c, tipo_version t, string nombre) o i_versión La creación e una versión en un conjunto e versiones se logra por meio el operaor create_version. La nueva versión será la raíz e un nuevo árbol e erivación. El operaor retorna el ientificaor asignao a la nueva versión. erive (CMP c, tipo_version t, string nombre) o i_versión La creación e una nueva versión erivaa e una ya eistente se realiza a través el operaor erive. El operaor retorna el ientificaor asignao a la nueva versión. elete_version (CMP c, Version v) El operaor elete_version borra versiones iniviuales. Las versiones erivaas e la misma se "cuelgan" e la fuente e erivación e la versión borraa. rename_version (string nombre, Version v) Para renombrar la versión corriente se utiliza la función rename_version. rea_version () o atos_versión Para leer atos e la versión corriente se utiliza la función rea_version.

9 ancestors (i_version) o lista_versiones Para obtener los ancestros e una versión, en el árbol e erivación, se utiliza el operaor ancestors. Operaciones sobre grafos e versiones path (i_version) o lista_versiones Para obtener el camino que hay ese la raíz a una versión aa se utiliza el operaor path. sub_tree (i_version) o lista_versiones El operaor sub_tree permite ver la sub_rama que "cuelga" e una eterminaa versión. sub_branch (i_version_from, i_version_to) o lista_versiones Para obtener la sub_rama que hay entre os versiones eiste el operaor sub_branch. el_sub_tree () El operaor el_sub_tree borra las versiones en el árbol e erivación con raíz la versión corriente. La versión corriente no es borraa. el_path () El operaor el_path borra los ancestros e la versión corriente en el árbol e erivación. La versión corriente no es borraa. Eisten os problemas concernientes a las operaciones e moificación: la estrategia para la erivación automática y la preservación e las restricciones e construcción. La estrategia para la erivación automática e versiones establece que hacer cuano el esquema esquemas ER e una versión es moificao: si la versión es actualizaa o si una nueva versión es erivaa. La elección e la estrategia se basa en os criterios funamentales: Evitar la péria e información. La moificación e esquemas ER en una versión poría implicar el borrao e estructuras e esquemas ER. Para evitar la péria e información una nueva versión ebería ser erivaa incluyeno el nuevo esquema. Evitar la proliferación e versiones. Derivar una nueva versión por caa operación conuciría a una proliferación e versiones no eseaa. En nuestro Moelo e Versiones aplicamos la siguiente estrategia: si el esquema moificao no incluye al esquema original, entonces se eriva una nueva versión. Con esta estrategia si se borra una estructura e esquemas ER entonces se eriva una nueva versión, y el esquema inicial que incluye la estructura borraa se preserva en el ambiente. Controlar la proliferación e versiones implica el borrao e versiones que no son más esenciales en el conjunto e versiones. En el conteto e esquemas ER es posible efinir un criterio para implementar este control: borrar las versiones que están incluias en alguna otra. 3. DISEÑO E IMPLEMENTACION

10 1. Arquitectura La coneión se realiza e la siguiente forma: Figura... La herramienta cliente es el móulo one se implementa toa la interface gráfica. Toas las operaciones invocaas acceen al servior e grafos. La implementación realizaa es la siguiente: primeramente al comenzar el Cliente se comunica vía RPC al Servior e Grafos y este se conecta al Servior e esquemas ER. Una vez establecia la comunicación con el Servior e Esquemas esta no finaliza y permanece abierta para optimizar las llamaas futuras a cualquier otra operación eportaa por el mismo. Cuano el cliente finaliza el Servior e Grafos cierra la coneión con el Servior e esquemas ER. 2. Los Serviores Servior e Grafos El Servior e Grafos esta implementao en C++. Fue implementao a través e la clase CMProjects que mantiene información e las versiones. La estructura y las relaciones entre las versiones se implemento utilizano una biblioteca para Tipos Abstractos e Datos LEDA la cual nos permitió efinir grafos paramétricos. Las versiones son los noos e ichos grafos y las relaciones e Derivación e Inclusión son los arcos. El conjunto e noos se encuentra almacenao una sola vez, mientras que el tipo e aristas se instancia en os: erivación e inclusión. Las operaciones e aministración e los istintos grafos están implementaas en C++, las operaciones aplicaas a la estructura e caa noo (operaciones especificas e los esquemas ER) y la relación e inclusión están implementaas en Eclipse- Prolog. La clase CMProjects se encarga e toas las operaciones e aministración e los grafos y se comunica con las rutinas e manejo e Esquemas Entia Relación a través e la función Oper vía el mecanismo e comunicación RPC. Caa versión se representa por meio e la clase Version la cual permite la creación y moificación e los noos. La información almacenaa e caa versión es: estao, ientificaor, nombre, valor. El significao e caa uno e ellos fue eplicao anteriormente.

11 La clase Arc permite la creación y aministración e las relaciones e los istintos Grafos (Derivación, Inclusión) Por eficiencia en los algoritmos e recorria el grafo tanto en la relación e Derivación como en la e Inclusión los arcos son irigios. La clase V_System es la clase que aministra el conjunto e grafos que son acceios por los istintos clientes. En esta clase se implementaron las funciones e carga e los grafos que serán enviaos en estructura e atos a los istintos clientes caa vez que estos lo soliciten para su posterior visualización. class V_SYSTEM (List(CMProjects)) class CMProjects {GRAPH(Version,Arc)} class Version (ientif,valor,name,status) class Arc (ientif,tipo) class Derivation_From,Derivation_to class Inclusion_from,Inclusion_to Servior e Manejo e esquemas ER La estructura e los esquemas ER se encuentran almacenaos en facts Prolog.Por lo que la comunicación entre los serviores se realiza a través e RPC. El servior e manejo e esquemas ER escribe las operaciones eportaas, que son el conjunto e operaciones que tiene que acceer el Servior e Grafos. El Servior se conecta con los esquemas a través e un pipe UNIX. De la especificación que se partió se tenía una comunicación a peio entre el Cliente y el móulo aministraor e los esquemas ER. Es ecir que caa vez que el cliente tenia que efectuar una operación sobre un esquema ER, llamaba a una función que ejecutaba el preicao (PROLOG). Para potencializar la moularia e la herramienta se ecie que la coneión ebe ser inepeniente el moulo que aministre un nivel inferior el grafo (esquemas ER) por lo que vía RPC se ecie la implementación e un Servior e esquemas ER. Aemás el Servior e grafos será un cliente e este servior por lo que tenríamos una comunicación Clientes Servior e Grafos Servior e Esquemas. Aemás esta comunicación ya no es mas a peio sino que el canal e comunicación esta siempre establecio por una eventual consulta y performance e la misma 3. El Cliente Una e las principales funciones el Cliente es la interface gráfica para los grafos e versiones, que permiten a los usuarios visualizar y manipular los noos e los grafos e erivación e inclusión e forma fácil y amigable. Se buscó una herramienta amigable, esto es e fácil manejo para el usuario y el programaor. Como ya se ijo anteriormente caa CMP efine os árboles: el árbol e erivación y el árbol e inclusión. Estos grafos son esplegaos por la interface gráfica e caa cliente el Manejaor e Versiones. Se pretenía una herramienta que permita moificar la estructura e los grafos

12 (aministrar la organización e los noos en la pantalla y grabar icha organización para una posterior utilización). Uno e los principales requerimientos e la aplicación fue que la organización e los noos e los iferentes grafos puiese ser aministraa por el usuario. Esto implica que los noos tengan la propiea e poer "arrastrarse" con el ratón hacia iferentes posiciones. Una vez elegia la istribución e los mismos, esta se almacena en un archivo e forma tal que la próima vez que se accea a ichos grafos la istribución sea la misma que la e la última vez que se trabajó con él. Esta istribución epene e caa cliente, o sea eiste un archivo con las posiciones e los noos e caa grafo por caa cliente que se conecte al Servior e Grafos. Las estructuras implementaas en sus istintas capas se comunican e la siguiente manera: Figura... Al tener uno o mas proceimientos en una máquina remota es necesario agregar cóigo entre la llamaa al proceimiento y el proceimiento remoto. Del lao el cliente, el nuevo cóigo eberá convertir los argumentos y traucirlos a la representación inepeniente e la máquina, crear el mensaje e llamaa, enviar el mensaje al proceimiento remoto, esperar los resultaos y traucir los valores resultantes a la representación nativa e la maquina el cliente. Del lao e los serviores, el nuevo cóigo eberá aceptar un peio RPC entrante, traucir los argumentos a la representación nativa el servior, realizar el espacho el mensaje al proceimiento aecuao, crear un mensaje e respuesta traucieno los valores a la representación inepeniente e la máquina y enviar el resultao al cliente. Para mantener la estructura el programa y aislar el cóigo e manejo e RPC se agregan os nuevos proceimientos que encapsulen completamente los etalles e comunicación. Estos proceimientos son llamaos stub proceures. Debio a la arquitectura e la aplicación el esarrollo fue moular y esto trajo como consecuencia un testeo moular. Luego e esto se realizaron pruebas e integración. Los cambios realizaos en caa móulo fueron los siguientes: Servior e Versiones: reiseñamos las clases y los miembros e las mismas, así como reprogramamos funciones que no estaban implementaas(up, Ancestors, Del_all_sp_links, Del_inclues, Del_inclue, etc.). Testeo e móulo. Servior e Esquemas: iseñamos e implementamos la coneión con el Servior e Versiones. Testeo e la misma.

13 Para aecuarnos a la especificación aa y a las moificaciones realizaas fue necesario la unificación e clases (C++) eistentes así como su renombre, efinición e nuevas funciones miembros etc. Debio a que primariamente estabamos trabajano en un ambiente C/S y era necesario probar las nuevas funcionaliaes implementaas, las etapas e testeo realizaas fueron las siguientes: 1. Debug el cóigo sin introucir problemas e re. 2. Agregamos transporte RPC para testear Cliente/Servior 3. Pruebas sobre la Re El propósito fue realizar un testeo incremental: 1. Se probaron funcionaliaes el servior en un ambiente sin coneión RPC. En un espacio e irecciones local, para lo cual compilamos el main() el cliente junto con el servior e grafos. 2. Una vez que se asegura que el cliente y el servior están correctos en un "moo" local, agregamos raw-functions e comunicación. Estas funciones ejecutan RPC en la máquina local en el espacio e irecciones asignao. 3. Finalmente se separa el cóigo, probano las funcionaliaes en un ambiente remoto. Estas etapas se volvieron a realizar una vez que se finalizó el servior e esquemas ER. Por último se testeo la comunicación C/S/S 4. CONCLUSIONES El Manejaor e Versiones propuesto provee un Moelo e Versiones basao en versiones e tipo esquemas ER, las cuales se agrupan en el Proyecto e Moelación Conceptual y se relacionan entre ellas a través e las relaciones e erivación, inclusión y construcción. Este Manejaor e Versiones permite organizar los esquemas ER y centralizar su organización inepenientemente e las técnicas que se utilicen para esarrollarlos. Su estructura consiste e un Servior e Versiones, el cual eporta primitivas el CMP y almacena la estructura e los grafos y los atos e las versiones, un Servior e Esquemas que eporta primitivas e aministración e esquemas ER y una Herramienta para el manejo e Versiones, la cual permite manejar los grafos e versiones entro e un ambiente gráfico amigable. El Manejaor ya se encontraba especificao así como sus principales funcionaliaes. Se realizaron varios cambios en caa uno e sus móulos. Dentro el Servior e Versiones se realizó un reiseñamiento e clases y miembros e las mismas, y se implementaron funciones que estaban especificaas pero no implementaas. En el móulo el Servior e Esquemas se iseñó e implementó la coneión con el Servior e Versiones. Para el manejo e las versiones se buscó una herramienta amigable tanto para el usuario como para el programaor, eligiénose la biblioteca Ilog Views. Con la misma se iseñó la interface gráfica en su totalia. Toos estos cambios fueron testeaos en forma moular. Dentro e un ambiente CASE el Manejaor e Versiones eporta primitivas para el manejo e versiones como por ej. creación, moificación, lectura, consultas, las cuales pueen ser llamaas

14 por las emás herramientas. Dentro e este ambiente se comunica con el resto e las herramientas por meio e llamaas remotas, utilizano RPC y archivos asccii. Las principales contribuciones e este proyecto son las aplicaciones e la comparación e esquemas ER y las técnicas e manejo para manipular versiones. La relación e inclusión se basa en la comparación entre esquemas ER al igual que el criterio para la erivación automática e versiones, la cual permite eciir cuano erivar una versión o cuano moificarla. Trabajo Futuro Concurrencia Las operaciones realizaas vía RPC son sincrónicas es ecir el proceso cliente esta bloqueao hasta que el proceso el servior halla finalizao. En alguno casos esto puee no ser aplicable por lo que seria necesario incluir procesos threas.un proceso normal puee incluir varios threas caa uno comportánose como un proceso normal ese el punto e vista e uso e CPU, toos los procesos threas el mismo proceso comparten el mismo espacio e memoria. Para implementar esta solución la aplicación cliente inicia las llamaas RPC en un proceso threas y luego continua su ejecución. Proliferación e Versiones La estrategia utilizaa en este Manejaor para la proliferación e versiones es erivar una nueva versión cuano el esquema moificao no incluye al inicial. Con esto evitamos la péria e información. Consieramos que se porían efinir nuevas estrategias para este problema y realizar un estuio e las mismas para poer eterminar cual es la mas aecuaa. Por ejemplo se poría consierar eterminaas características e las versiones como significantes, y si alguna e ellas es moificaa entonces se ebería erivar una nueva versión. Relación e Construcción La relación e construcción moela cómo las versiones han sio construias a partir e otras aplicano operaciones e esquema. En esta implementación el Manejaor e Versiones no se trabaja en el ambiente gráfico con el árbol e construcción, por lo cual en el futuro sería interesante poer implementarlo y que el usuario puea trabajar con el mismo e la misma manera que lo hace con el árbol e erivación y el árbol e inclusión.