Proyecto “Lotario”

1. Proyecto “Lotario” Universidad ORT Uruguay

2. Integrantes del Grupo • Veronica Piria • Celina Gayoso • Carolina Maltese • Andres Levin • Tutor: Gastón Mousqués

3. Descripción del Producto • Cliente: • ARTech • Representantes: Andres Aguiar y Daniel Mendez • Producto: • Esta herramienta permite aplicar ingeniería inversa sobre bases de datos existentes. A partir de la definición de las tablas, índices, etc. de una base de datos, se generan los objetos GeneXus (Data Views y/o transacciones, atributos, tablas, índices, etc.).

4. Descripción del Producto • Esta aplicación puede ser utilizada desde GeneXus (en el modelo de Diseño) o independientemente del mismo. En este caso, se generan los archivos de distribución del conocimiento (archivos xpz) que luego pueden ser consolidados en una KB GeneXus. También puede ser utilizado por GXQuery. • Tiene también un módulo de resolución de conflictos que permite que una aplicación GeneXus trabaje con una BD externa.

5. Ejemplos de uso • Desde un sistema hecho en GeneXus, poder acceder a diferentes BD de distintas aplicaciones, hechas en GeneXus o no • El caso mas típico de uso del DVG es cuando un cliente tiene uno o mas sistemas, cada uno con su base de datos; y se desea que una aplicación GeneXus ; nueva o existente, acceda a dichas bases de datos. En este caso se crearán todos los objetos necesarios para satisfacer ese requerimiento. • Transferencia de datos entre distintas BDs.

6. Funcionamiento

7. Características del proyecto • Comunicación con el cliente • Hacemos prototipos para mostrarles • Tenemos acceso al Wiki de ARTech • Dos de nosotros trabajamos en ARTech • Gestión Ágil • Usamos prácticas de las metodologías Ágiles • Usamos XPlanner para la planificación del proyecto • Grupo distribuido • El arquitecto esta trabajando en China • Nos vemos sólo los fines de semana

8. Requerimientos no funcionales • Requerimientos técnicos • El sistema debe escribirse en C# • El módulo de resolución de conflictos debe escribirse en prolog • Se debe usar April (APRolog compILer for the .net platform) es un proyecto de U de la R • Utiliza los mecanismos de conexión ODBC y ADO.Net • Se conecta a los DBMS más conocidos del mercado.

9. Requerimientos no funcionales • Características de calidad • Interoperabilidad • Facilidad de prueba • Eficiencia • Modificabilidad

10. Eficiencia • Estudiamos los algoritmos que recorren la estructura de la BD • Para esos algoritmos: • Primero calculamos el orden de ejecución • Si no es aceptable se vuelve a escribir optimizándolo • Luego le hacemos una prueba de estrés para ver si el tiempo que demora es aceptable • Validamos los tiempos con el cliente

11. Testing • Testing Automático (NUnit) • Si bien nos lleva mucho tiempo hacerlo, nos asegura que todo sigue funcionando bien cuando agregamos nuevas funcionalidades • Testing de Estrés • Nos asegura que los tiempos máximos del sistema son aceptables • Testing de Integración • Diseñamos casos de prueba con BD con conflictos

12. Prolog • Es un lenguaje de programación lógica, en el cual se definen reglas (relaciones lógicas entre datos) y hechos (“Datos”) • Tuvimos que aprender Prolog porque ninguno lo había usado nunca • Usamos April (APRolog compILer for the .net platform) que es un proyecto reciente de la U de la R • Versión beta (nos encontramos con algunos problemas) • La respuesta del desarrollador de April es MUY rápida y eso es muy importante para nosotros

13. Prolog • Usamos P# otra versión de Prolog • Para confirmar que si algo no funcionaba no fuera por problemas de sintaxis • El costo de integrar P# con C# es alto, por lo que no lo integramos; pero lo usamos externamente para hacer pruebas que nos permiten verificar nuestro código

14. Prolog • El DVG carga la metadata de la BD y al mismo tiempo escribe código prolog (hechos), que luego son cargados en runtime. • Hechos + Reglas de usuario + Reglas implicitas en el DVG = Knowledge Base Prolog. • Dicha Knowledge Base es consultada mediante “Queries”; en nuestro caso nos interesa consultarla para saber si tenemos situaciones de conflictos.

15. ¿Por qué prolog? • Lo que se puede hacer con una sentencia de prolog se hace con muchísimas líneas de código C#, y por sobre todo con algoritmos que serían sumamente complejos. • Es mucho más performante que C# para éste tipo de problemas.

16. Conflictos • Mismo nombre significa misma cosa, es decir, si en 2 transacciones diferentes tengo atributos que se llaman igual, para GeneXus son lo mismo. • En las BD no creadas por GeneXus ésto generalmente no sucede. • Esto provoca diferentes conflictos a la hora de mapear de la estructura de la BD a la estructura GeneXus. • Los tipos de conflictos que se dan son: • De nombre y tipo • De subtipos

17. Conflictos • TCuenta(NroCuenta, Cliente, Capital) • Cliente -> TCliente.Nombre • Capital -> $$$ • TCliente(Nombre, Apellido, País) • País -> TPais.Nombre • TPaís(Nombre, Capital) • Capital -> TCiudad.Nombre • TCiudad(Nombre) • TCliente.Nombre <> TPaís.Nombre <> TCiudad.Nombre • TCuenta.Capital <> TPaís.Capital (conflicto de nombre y tipo) • TCliente.País = TPaís.Nombre

18. Conflictos • Ejemplo de regla Prolog para detectar el conflicto de 2 atributos con diferente nombre pero con relación de integridad. • Regla1(Tabla1,Tabla2,Atributo1,Atributo2) :- tableFK(Tabla1,Atributo1,Tabla2,Atributo2), not(tableFK(Tabla1,Atributo1,Tabla2,Atributo1)). • Estamos haciendo al mismo tiempo archivos de texto con sentencias prolog “Hechos” para testear estas reglas.

19. Interoperabilidad con Prolog

20. Resumen • El DVG analiza la metadata de una BD y la convierte en metadata GeneXus permitiendo que una aplicación GeneXus acceda a una BD externa. • Como punto a destacar se interopera con Prolog para resolver los conflictos que pueden surgir en dicha conversión. • Es posible acceder a los DBMs más conocidos del mercado y utiliza los mecanismos de conexión ADO.Net y ODBC.

21. ¡¡Muchas gracias!! ¿Preguntas?