Proyecto “Lotario”
Universidad ORT Uruguay
Integrantes del Grupo
 Veronica Piria
 Celina Gayoso
 Carolina Maltese
 Andres Levin
 Tutor: Gastón Mousqués
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.).
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.
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.
Funcionamiento
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
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 (A PRolog 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.
Requerimientos no funcionales
 Características de calidad




Interoperabilidad
Facilidad de prueba
Eficiencia
Modificabilidad
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
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
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 (A PRolog 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
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
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.
¿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.
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
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
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.
Interoperabilidad con Prolog
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.
¡¡Muchas gracias!!
¿Preguntas?
Descargar

Document