[clubSmalltalk] Re: Fwd: Seminarios Athena - Programac ión Orientada a Prototipos

Wed, 18 Oct 2006 14:31:51 -0700

Pancho, tarde pero seguro respondo...
 
En InfOil tenemos desde hace unos años un Fw de Aspectos. Estos aspectos son una especie de AspectAdaptors (luego de implementarlos descubrimos que eran parecidos a los de VW) y forman una capa que seria la interfaz publica de un objeto modelo de negocios (publica a nivel de Usuario). Es decir con los aspectos podemos programar en forma gestual utilizando otro Fw de formulas que le permite al usuario armar de a pedacitos comportamiento que luego sera evaluado usando instancias de la base de datos como argumentos. El fw de formulas permite todo tipo de operaciones matematicas y logicas sobre los objetos. Nos estaria faltando operaciones a nivel de programacion sintactica y no gestual, es decir como comentabas vos, usar un lenguaje similar a Smalltalk pero interpretado. La tentacion de permitir Smalltalk puro es grande pero se dificulta al momento de limitar el Environment de evaluacion...
Actualmente la evaluacion de las formulas se lleva a cabo mediante traduccion de cada elemento de la formula (seria cada nodo) en una expresion Smalltalk que luego es evaluada mediante mecanismos de evaluacion tradicional.

Los aspectos a su vez estan enganchados con Fw de unidades por lo tanto un usuario siempre ve los valores segun la configuracion de unidades que tenga.
Para presentar los aspectos estamos desarrollando un Fw de GUI dinamica, usando Seaside y un port no oficial y privado de Magritte (de Squeak). Esto nos permite generar la GUI on the fly. El codigo de un editor tiene 3 lineas, el resto lo hace el Fw.
 
Por otro lado tenemos un Fw de mapeo a base de datos relacional diseñado teniendo en mente perfomance para instanciar muchos objetos (por eso no quisimos utilizar nada que haya en el mercado y luego nos limitara para hacer ajustes especificos ademas de tener que adaptarse a las bases de datos actuales)
 
Todos estos Fw tienen tools para que el desarrollador genere rapida y comodamente todas las definiciones necesarias, las cuales actualmente se guardan en metodos, pero esta pensado como para guardarlo en XML.
 
Finalizando y para redondear el desafio que tenemos ahora es unir todo esto y enganchar algo para que al menos gran parte de un sistema sea definible por el usuario usando Adaptative Object Model! Creo que gracias a St estamos muy cerca a lograrlo.
 
Resumiendo, parece que las implementaciones se repiten en varios lados, son como patrones. Quizas podriamos ver de hacer un Fw open source para St. no? Logicamente enganchando lo open source que ya hay...
 
Saludos
  GallegO
 
2006/10/15, Francisco Garau <[EMAIL PROTECTED]>:
En la empresa de seguros donde trabajaba antes, usabamos algo parecido a esto:
 
 
Se podian identificar los siguientes patterns:
1) Type Object
2) Variable State
3) Interpreter
 
El sistema se utiliza para generar polizas de seguros validas. Una poliza puede ser vista como una instancia de un producto de seguro. Pero a su vez, el productoDeSeguro es un objeto que cumple el papel de clase (TypeObject).
 
Ejemplos de productos son MobiCasa, MobiCar o MobiTour (seguro de viajero). Cada uno de estos productos son representados como un arbol de 5 niveles (porque asi lo define un estandar de la industria). En el caso de MobiCar, en el segundo nivel tenes dos bloques mutuamente excluyentes: Todo Riesgo o Responsabilidad Civil. Cada uno de estos bloques (Specification) tiene "aspectos", que no es otra cosa que un metodo o variable de instancia. Un aspecto posible seria "precio" y la implementacion seria "self car model * 2". La implementacion estaba escrita en algo parecido a Smalltalk y por eso necesitamos un interprete.
 
Si te interesa, podria seguir expandiendome. Pero en realidad, las similitudes con el UDP no eran percibidas ni apreciadas. Y el sistema tenia muchas complicaciones innecesarias. 
 
Si vas a armar un framework dinamico para que el usuario pueda modelar o programar, no te olvides de una cosa: las facilidades de debugging.
 
Si los usuarios pueden modelar, puede ser que sus modelos tengan errores. Y ante un error, quien se encarga de corregirlo? Dudo que sean los usuarios. Dudo tambien que tengas que hacerlo vos. Seguramente sea algun programador Smalltalk que conozca las ideas del framework, pero no lo conozca a fondo. Para este programador es muy importante saber distinguir entre el codigo del interprete y el codigo que esta siendo interpretado.
 
Imaginate que pasaria si en el debugger de Smalltalk vieras todo lo que pasa a nivel de la maquina virtual. Seria una pesadilla.
 
Esta es la presentacion que hizo el autor de este framework hace un par de anios. Mira las paginas 43, 46, 52, 55
 
Saludos,
Pancho
 
----- Original Message -----
From: GallegO
Sent: Saturday, October 14, 2006 10:45 PM
Subject: [clubSmalltalk] Re: Fwd: Seminarios Athena - Programación Orientada a Prototipos

 
2006/10/14, Francisco Garau <[EMAIL PROTECTED]>:

Adaptative Object Model es el nombre que se maneja en la academia.

http://www-poleia.lip6.fr/~razavi/aom/papers/


Muy bueno el ultimo link y tambien la parte de expert-programmable software a la que llegas desde http://www-poleia.lip6.fr/~razavi/ .
Muchas gracias, no tenia idea que existia algo como para leer sobre eso, me viene muy bien.
Vos usaste alguna técnica especifica de las descriptas en Adaptative Object Model, papers especificos que deba tener muy en cuenta para armarme un framework con el usuario pueda modelar un sistema dinamicamente?
Gracias nuevamente.

Saludos
  GallegO



--~--~---------~--~----~------------~-------~--~----~
Ha recibido este mensaje porque está suscrito a Grupo "clubSmalltalk" de Grupos de Google.
 Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a [email protected]
 Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED]
 Para obtener más opciones, visita este grupo en http://groups-beta.google.com/group/clubSmalltalk.
-~----------~----~----~----~------~----~------~--~---

Responder a