Modelos de datos, repositorios y aplicaciones
El mismo autor, tiene dos libros anteriores de referencia donde en el primero muestra modelos de datos que se adaptan y combinan para diferentes problemas, y en el volumen 2, adapta los mismos para diferentes industrias.
Son libros pesados pero que sirven para referencias cuando hay que modelar alguna realidad no demasiado conocida.
En este tercer libro, intenta explicar los patrones generales que aparecen en el modelado de datos y también cuando conviene aplicarlos. Muestra además diversas opciones de implementación y niveles de detalle. Parecen ideales para la implementación de GeneXus Patterns con los mismos. Algunos de los patrones que están descritos en el libro son las Jerarquías, Categorías, Clarificación, Estado, etc. Aun no lo terminé de leer, por lo que no es de esto que quiero escribir.
Mientras leia este libro, mirá que linda la rueda que inventé.
Hoy me levanté con la sensación que el desarrollo de software se podía hacer mas rápido, si aplicábamos patrones ya probados por otros. Mi idea (que no es mía) es que podríamos aplicar patrones a muchas mas cosas que las que hoy hacemos, o que ya hacemos sin que yo lo tenga tan claro.
Cuales serian los pasos para el desarrollo de una aplicación?
1) Elegir las entidades que participan en mi aplicación.
2) Elegir que atributos forman parte de cada entidad
3) Elegir patrones de categorías, jerarquías, etc
3) Elegir/ajustar los dominios que existen
4) Elegir los patrones de diseño que hay que aplicar
- WorkWith
- SummBy
- ExportToExcel
- ReportesPDF
- CrossTable
- .... muchos mas..
5) Elegir el patrón de diseño gráfico (Theme)
6) Cargar datos (programa que genera datos de prueba)
7) Programar los objetos que falten
8) Borrar todo lo no utilizado (KBDoctor!)
9) Prototipar y ajustes de parametros de los patrones
10) Declarar seguridad y Auditoría
11) Testeo funcional de la aplicación
12) Testeo de aceptación y carga
13) Instalación de la aplicación (Deployment)
14) Ajustes a la aplicación y a la base de datos.
Que nos falta
a) Repositorio de Entidades.
Es necesario tener un repositorio donde yo pueda bajarme "estructuras" de CLIENTES, PAISES, EMPRESAS, etc. Lo que me imagino seria que tener un Wizard donde se elige el nombre de la entidad de primer nivel, mostrándome ahi las entidades que se relacionan con las mismas.
Ahi muestra los atributos de cada una de las entidades. Se eligen los que se necesitan y con esto se "crean" las transacciones necesarias y también los objetos necesarios para que estas entidades funcionen correctamente. Se marcarían como público los objetos que puedan usarse desde afuera y los demás quedarian marcados como privados (esto necesita el manejo de módulos).
b) Generación de datos de pruebas.
Todos las Entidades deberían tener los programas para la generación de datos en forma automática.
c) Repositorio de Themes.
Seria bueno tener varios temas para poder elegir y una forma fácil de ver nuestra aplicación funcionando con diferentes themes.
d) Seguridad y Auditoría declarativa en las aplicaciones.
e) Herramientas de Testeo Unitario
f) Herramientas de Testeo Funcional y Carga
g) Herramientas de Ayuda de Deployment
h) Herramientas de Tunning de Aplicaciones y Base de datos.
i) Ayuda para la integración entre diferentes patrones.
Por ejemplo el WorkWith debería poder comunicarle al patrón de diseño gráfico (Theme) que le falta determinada class.
Los patrones deberian poder comunicarse bien entre ellos, de forma que cada uno de ellos tengan una API, de forma que todos otros patrones puedan comunicarse.
Creo que deberiamos empezar por tener un repositorio de entidades, dominios y atributos. Con esto ya seria un paso muy importante, para poder desarrollar mas rapido.
El repositorio de dominios y atributos es algo que venimos pensando y parece super util, con el que yo me he trancado es con el de entidades.
ResponderBorrarEl problema es que una entidad cualquier, por ejemplo Cliente, depende de la aplicacion en la que se va a utilizar su grado de complejidad. Por ejemplo en una aplicacion puede alcanzar que tenga solo un atributo para el Telefono y en otra necesita tener una lista de Telefonos y contactos electronicos.
Por lo tanto el repositorio de entidades deberia ser 'inteligente', en el sentido que dependiendo de para que se vaya a usar la entidad, que complejidad para la misma va a entregar va a entregar.
Ahi es donde me tranque yo.
Nicolas Jodal
Pd: acabo de comprar el libro!
Como siempre Enrique, excelente que expongas este tipo de cosas en tu Blog, me imagino que muchos como yo vemos reflejadas "nuestras necesidades" (o lo que nos gustaría que nos facilitara la vida) en los mismos.
ResponderBorrarComparto con lo que menciona Enrique, más que nada con la necesidad de un Repositorio de Entidades.
Va un comentario Largo, Sorry para aquellos que no quieren leer mucho.
Trabajé hace años en la integración de decenas de sistemas a un único Modelo de Datos, lo cual obligó a crear diferentes Entidades que cumplieran con las especificaciones de todos los sistemas (Los cuales fueron implementados por diferentes personas en diferentes épocas y diferentes versiones de GeneXus).
Cada base de conocimiento integraba las entidades base que requerían para su sistema y se migraba la lógica para utilizar la nueva "entidad" (Tablas GeneXus).
El único problema era la sincronización de la Entidad en cada Base de Conocimiento en la cual se estuviera utilizando.
Una KB Centralizada era la que tenía todas las entidades y las mismas cada tanto se actualizaban con nuevos conceptos (Porque nuevos sistemas se implementaban y necesitaban de mayor información)
La única forma de sincronizar era hacer un Export y Consolidarlas, previamente se tenía que ver el impacto y ver si en el sistema no se tenía que cambiar alguna lógica si la estructura de la tabla difería en partes con la original.
Se tenía que hacer todo esto porque se quería usar una base de datos centralizada con la información de las Entidades compartida, o sea, la entidad Personas era la misma que veían todos los Sistemas, pero sin embargo, "Clientes" no, ya que si bien la entidad estaba compartida entre los sistemas, existía un atributo en la misma el cual definía el cliente a cual sistema se encontraba asociado.
Ahora bien, si lo que se quiere como Entidad en una nueva KB es tomar una de Base y hacer una Clonación en la cual sea posible Recortar la Estructura, creo que no sería muy complicado la implementación de una Extensión que lo permita.
Con respecto al ejemplo que menciona Nicolás, si en la importación se elimina el atributo clave del nivel que hace que los teléfonos sean uno o varios se podría cumplir el objetivo de seleccionar si se desea uno o varios. El problema es que para esos casos el modelo de Dato creado sería particular, no se podría utilizar un sistema Centralizado con una única estructura de Tablas, pero en una de esas lo que se desea son tener referencias de entidades y crear nuevas en base a las importadas.
De todas formas lo ideal sería crear entidades Desconectadas (o no) y "Unirlas" en base a las necesidades, o sea, Unir Teléfonos a Personas e Indicar que pueden ser una o varias, con lo que la importación lo que haría sería unir 2 transacciones GeneXus en una sola haciendo que en el caso de que quieran que sea un solo Teléfono el mismo forme parte del primer nivel de la TRN o en el caso de que se quiera varios se crea el segundo nivel en donde se encuentre integrado por el concepto Teléfono.
Enrique menciona el caso de "Quiero que me importes la entidad y sus dependencias", eso podría ser una opción valida si ya se tiene Entidades de más alto Nivel ya definidas.
Yo me lo imagino como una herramienta Visual en donde importo Entidades y defino luego las relaciones entre las mismas, luego GX me crea las Transacciones necesarias para las mismas (Digamos que sería similar al DBRET pero avanzado, orientado a Entidades).
Espero se haya entendido algo. Soy del tipo de persona que le gusta hacer dibujitos para ejemplificar, el Blog aún no me lo permite. :)
Con respecto al resto de las herramientas que menciona Enrique, ya lo veo un poco más complicado de visualizar.
El punto de elegir los patrones de Diseño que hay que aplicar ya hoy en día es "visible".
La selección del Patrón de Diseño sería una tarea Simple de implementar (Una herramienta que permita seleccionar el resultado de los Patrones y cambie el Theme asociado de cada uno de ellos).
Sería posible hacer lo mismo en Runtime, si el patrón implementado utiliza una lógica que permita setear los CSS de los diferentes temas a demanda (Excelente para prototipar sin tener que regenerar).
Ahora bien, caemos un poco en que los temas son dependientes de los patrones, por lo tanto, los patrones deberían mantener una estructura base en común (Algo como una definición UI base). De lo contrario no podría ser posible.
Si se podría implementar un validador como menciona Enrique, en la definición del formulario se tiene los Class utilizados, en el Objeto se tiene el Theme asociado, se podría incorporar una rutina que recorra y haga el Match de los mismos, si algo no cuadra tire un Warnig, con la versión en Runtime.. y bueno, se podría hacer algo pero ya sería mas complejo de implementar.
Con respecto a la seguridad y auditoria declarativa, sería bueno que los Patrones permitan generar "puntos de enganche", eventos en los cuales pueda colgarse de forma dinámica un determinado programa, y que ese programa permita controlar si el evento se cancela o no (Retornando uno o varios mensajes) o si se "Logea" la acción realizada.
De alguna forma algo centralizado manejaría la lógica de que pantallas se deben de Logear, cuales deben de controlar la seguridad (un motor de reglas? o colgar un programa?) y todo lo que se quiera hacer. En GXFlow existe algo similar con respecto a los Eventos, sería extrapolarlo hacia los eventos de las aplicaciones generadas por GX.
La lista de cosas que se pueden hacer son interminables, como dice Enrique, comenzar con un repositorio de entidades, dominios y atributos sería un paso importante.
¿Es cuestión de que alguien se anime a implementar una extensión? ;)
Disculpas por pecar en hacer un comentario tan largo. Solo quiero hacer un aporte en la discusión de este tema.
Saludos
David
Una de las caracteristicas del respositorio, deberia ser que fuera cargado y mantenido por la comunidad y que manejar niveles de detalle.
ResponderBorrarConcuerdo que es dificil (o imposible) encontrar una estructura que sirva en el 100% de los casos, pero si nos ahorra a cada uno algunas horas de pensar y digitar los atributos y dominios, la ganancia para toda la comunidad es enorme.
Lo que a mi se me ocurria era en primera instancia "pedir prestados" todos los modelos de datos de los libros de "The Data Model Resource Book: Universal Patterns for Data Modeling", Volumen 1 y 2 y publicarlos traducidos a GeneXus.
Con esos modelos ya tendriamos mucho para empezar.
El repositorio, podria tener despues varios grados de inteligencia. Necesitaria un wizard que me vaya mostrando primero MODULOS (Elijo un modulo = conjunto de entidades)
ENTIDADES (Elijo la entidad y el nivel de detalle)
ATRIBUTOS DE LAS ENTIDADES (elijo que atributos me sirven)
Con estas selecciones, se deberian armar las transacciones (solo la estructura) que luego se completarian con patterns.
Tambien estaria bueno que el repositorio pueda ir aprendiendo de lo que les sirve a los usuarios, registrando cuales son los att que mas eligen, o permitiendo que se puedan subir modelos de datos de los usuarios, para aprender que atributos se usan que esten faltando.
En fin, es un lindo proyecto de 6 meses, para algun grupo de estudiantes que quiera recibirse.
David:
ResponderBorrarEstamos hablando de cosas muy parecidas y es bueno cuando se alinean las ideas.
Con el repositorio, hay que empezar a hacerlo y se verá que es lo que es mas util, y evolucionarlo con el tiempo.
Con la aplicacion de Themes, las herramientas que hoy tenemos son bastante limitadas. Es dificil saber si me estan faltando clases, es imposible copiar clases de un Theme a otro y la herramienta de visualizacion es bastante primitiva.
Si bien hay herramientas de terceros que permiten cambiar el CSS y ver como cambia la cara de mi aplicacion, creo que al tener GX el conocimiento de la aplicacion que tiene, podriamos hacer algo mejor.
Gracias por el comentario.
Me parece excelente la idea de un repositorio público.. o por lo menos que se permita manejar como un Servidor de Proyectos en donde se bajan la versión del Modelo y se proponen cambios, y un comité de selectos de la comunidad aprueban o no los cambios propuestos por otros.
ResponderBorrarEl tomar los patrones del libro me parece buena idea ¿Existe una sección en el libro de Recursos en donde diga si existe algún lugar público de donde tomar modelos?
Hago algunos aportes más por si alguien quiere investigar un poco más sobre el modelado de Entidades (MDA,DDD o MDD).
Librería de Modelos de Industrias de IBM
IBM en conjunto con varias empresas de Software en base la experiencia de años en varios sectores se dedicó a crear Librerías de Modelos de Datos basados en diferentes industrias.
Muchas empresas de gran porte (Empresas de Software Grandes) implementan su modelo de Datos en base a los mencionados por IBM, lo cual les permite interactuar entre si (o ser migrados entre si :P ).
Paso Link con info, hace unos meses tengo pendiente leer un poco más al respecto.
http://www-01.ibm.com/software/data/ips/products/industrymodels/library/
Microsoft tiene un Framework para manejar modelos de Entidades, puede dar algunas ideas sobre el "concepto superior" aunque GeneXus ya tiene resuelto con las Transacciones muchas cosas que ellos utilizan.
Un buen resumen en la Wikipedia
http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework
Microsoft Oslo
Si quieren conocer un poco más de como Oslo maneja el repositorio de Modelos
http://msdn.microsoft.com/en-us/library/dd129586.aspx
No encontré hasta el momento lista de modelos en internet, si alguien conoce algún que lo pase.
Tengo entendido que en el PDC entregaban modelos realizados por Microsoft en el repositorio de ejemplos de Quadrant. ¿Alguien los tiene?
OMG Modeling and Metadata Specifications
Son especificaciones estándares de Modelado
http://www.omg.org/mda/
Eclipse Modeling Project
Tiene muchos adeptos y tiene más KnowHow que Oslo por haber comenzado hace ya años.
http://www.eclipse.org/modeling/
Ya que puse a Oslo, paso uno que viene de del projecto de Eclipse el cual utiliza por detrás EMF y otros estándares de Modelado
http://www.openarchitectureware.org/
Ojalá llegue el día en que existan repositorios y se puedan compartir los mismos entre diferentes herramientas y aplicaciones.
Saludos.
Muy interesante, gracias por compartirlo,
ResponderBorrarLo veo y si me surge dejo un comentario menos intrascendente.
Saludos,
gab