Modelo, decisiones, inteligencia artificial y AjGenesis

En el recientemente creado grupo de Google AltNet-Argentina, el bueno de Fabio Maulo planteó una pregunta en el thead:

ORuM

donde escribía

Quien me conoce un poco, o me ha leido en algún lado, conoce ya la acronimo
ORuM.La realida es que nunca tuve la ocasión de una buena confrontación
sobre el tema.

Para titular la mesa sería:
Object Relational unMapping
Mas allá del ORM.

Quisiera compartir, confrontar, ampliar algunas ideas y verificar la
factibilidad.

La idea es tener en claro, cómo se toman algunas decisiones, en el caso de tener un dominio de clases, y llegar al mapeo de en una base de datos, no preexistente. Es un caso tipo, como escribía el propio Maulo:

Yo quisiera llegar a : “che, yo tengo este dominio que tendría que persistir en ORACLE, fijate vos! a mi lo que me interesa es que persista.”

El DSL sería:

Che.Tengo(“MiDominio.dll”).Que.TieneQuePersistirEn(“ORACLE”).FijateVos();

Para mí, esto es parecido a lo que trato muchas veces de resolver con AjGenesis:

“Tengo X quiero resolverlo con Y”, donde X puede ser un dominio de entidades, un dominio más tipo DDD, una lista de servicios, lo que sea, e Y sería JSP, Struts2, JSF, ASP.NET MVC, NHibernate, Hibernate, MySql, SQL Server, y demás. Es lo mismo que hace un programador: toma decisiones, ante lo que tiene que hacer.

Es por eso que en AjGenesis tomé algunas decisiones tempranas, para poder ir avanzando en un camino, que menciono en:

Sobre la generación de código

… el modelo a usar … PUEDE SER GENERADO por el propio sistema, más un sistema experto. No imagino una aplicación más inmediata de la “inteligencia artificial”. Imagino agentes inteligentes, que colaboren en una red compartida, cada uno generando parte del modelo, cada uno consumiendo algo que otro produce, y colaborando, para generar un sistema… Sí, ya sé, tengo que tomar la píldora verde, en lugar de la roja… ;-)

Esa es una de las razones de tener en AjGenesis:

- un modelo
- más que sólo un lenguaje de templates
- aplicar el lenguaje en tasks, que modifican y completan el modelo

Si sólo tuviera templates, sólo haría transformaciones X -> Z, de una forma, digamos, lineal, desde, para poner un ejemplo, una clase o un modelo que describe una clase, a un código o archivo de configuración de persistencia.

A lo que voy, es que el camino que quiero para AjGenesis, en algún momento (no para que todos lo usen así), es que sea un sistema experto, que tome decisiones. De ahí que, desde el principio:

- tenga un lenguaje completo, con toma de decisiones, que pueden ser complejas
- tiene acceso al framework de .NET, para poder ser extendido de cualquier manera.
- invoque a tareas, no simplemente a transformar el modelo X usando el template T

Eso explica también, algunos caminos que estoy explorando, como AjLisp, y AjProlog (aunque son más para entrenarme, que para aplicarlos directamente en AjGenesis). Habrá que investigar si este camino es posible, pero me parece que está relacionado con el tema planteado en el grupo. Veamos, volvamos al problema inicial.

De clases a persistencia

Las opciones de mapeo que podemos considerar, son las mostradas por el bueno de Martin Fowler:

Single Table Inheritance

Class Table Inheritance

Concrete Table Inheritance

En una situación ideal (no costo en tiempo de queries o de update, sin limite de memoria en disco), todo seria igual.

Como la situación no es ideal, me imagino que los costos de cada decisión se mediran en:

- Rendimiento de actualización y consulta

- Espacio de almacenamiento

A primera vista, me imagino que el primer punto es el mas peliagudo.

Para concretar, tomemos un modelo sencillo. Sea clase Empresa, subclases Cliente, Proveedor.

Habría que ver qué consecuencias tiene entonces, el tener una tabla empresas, con un campo discriminador de si es cliente o proveedor. ¿Qué pasa si hay muchos campos en comun? ¿O si hay muchos campos de diferencia? Pienso que mas va a influir el tema: ¿pero queda ahí el dominio? Si el día de mañana aparecen más subclases, ClienteExtranjero, ProveedorExterno, ¿no se complicará el haber adoptado una sola tabla?

Si ponemos tablas Empresa (con los datos comunes), Clientes (con los datos adicionales), Proveedor (con los datos adicionales), habrá que hilar fino en las consultas. No sólo está el tema del rendimiento de actualización y consulta. Tambien esta la frecuencia de algunas operaciones. Es decir, si una consulta determinada tarda X tiempo, habrá que ponderarla tambien por la frecuencia de esa consulta en la operación normal del sistema.

Con tablas Clientes, Proveedores, habra que comprobar que la actualizacion sea mas rapida que en el anterior caso. Y vigilar que pasa, y con cuanta frecuencia, se necesita una consulta sobre Empresas (que imagino debera implicar un UNION).

Entonces, no sólo es el modelo de clases, sino cómo se usa, lo que puede influir en cómo hagamos el mapeo.

ESTO ES LO QUE YO VEO EN MUCHOS MODELOS ya existentes, que no tienen todo LO QUE SE NECESITA DE UN MODELO. Un modelo de clases se queda corto, para tomar algunas decisiones. Lo mismo, si partimos desde una base ya diseñada. Partir de esos modelos, implica que en algún momento lo tenemos que enriquecer, con anotaciones en el modelo de clases, o agregando información en metadata o en algún momento, si partimos desde la base de datos.

Partir de un modelo de clases o de la base de datos, tiene la ventaja de partir de algo conocido. Pero para muchas de las operaciones que quisiéramos hacer (en este caso “simple”, mapeo a relacional, imaginen otros casos como servicios distribuidos, seguridad, cache en el cliente, etc.), hace falta más información de contexto.

De ahí, que yo esté a favor de un modelo distinto, más enriquecido.

De Aristóteles a Kant

En los noventa, en una revista Byte, leí una breve reseña, sobre gente que estaba armando algo que lo llamaban KANT. En honor a las categorías del filósofo alemán (yo diría que se referían más a categorías de Aristóteles), ellos planteaban que todo en, lo que hoy llamaríamos, modelo, está incluído en alguna categoría como:

- Persona
- Organización
- Bien Físico
- Lugar Físico
- Documento
- Suceso
- Lapso

y demás. Por ejemplo, un Empleado entraría en la categoría Persona, un Cliente o Proveedor, en la categoría Organización. El que un Empleado estuviera contratado por una Empresa, era un Lapso (un intervalo, posiblemente abierto, de tiempo) establecido entre una Persona y una Organización. A partir de las categorías, se podía inferir que toda Persona tiene fecha de nacimiento, y otros atributos, que un Lapso puede tener tiempo de inicio y tiempo de final. (Escribo sin tener la referencia, de memoria).

Esa reseña siempre influyó en lo que quiero hacer con un modelo rico, abstracto. Sirve para poner más semántica sobre lo que estamos describiendo, más de lo que daría un modelo de código o de base de datos. Sigo pensando que algo así debe ser el modelo del que partir, en la generación de código o en otras ideas.

Apenas una punta de eso (el tener categorías llamadas prototipos, que sirvan de base para generar un modelo simple), está desde hace tiempo en AjExamplesExamples3.zip, en el directorio Prototypes, y Seeds. Es una idea con implementación mínima, a explicar en detalle en otro post.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
En estos días, revival de los 80s en mi vida http://www.youtube.com/watch?v=dgwmErO_nlQ

This entry was posted in 2643, 3036, 3463, 6145. Bookmark the permalink.

One Response to Modelo, decisiones, inteligencia artificial y AjGenesis

  1. Luis says:

    “De ahí, que yo esté a favor de un modelo distinto, más enriquecido.”
    ¿Algo como ontologías tal vez?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>