Intro

Notas del editor

• #3: Nuestra tarea como profesionales de la informática es desarrollar y mantener aplicaciones para apoyar al usuario en su activida d . Para realizar esta tarea se han instrumentado diferentes herramientas y metodologías. Con GeneXus se desarrollan aplicaciones sobre bases de datos, empleando una metodología que tiene un enfoque muy diferente al de las metodologías más comúnmente utilizadas. Aprender a utilizar GeneXus adecuadamente va más allá de conocer el lenguaje de especificación: lo más importante es el aprendizaje de una nueva metodología de desarrollo . ?
• #4: El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtención del conocimiento de la realidad. ¿ Cómo obtener el conocimiento de la realidad en una forma lo suficientemente objetiva y detallada al mismo tiempo, que nos permita construir un modelo corporativo? Ya que los usuarios conocen los objetos con los que trabajan cotidianamente, conocen la información que se maneja en ellos, las reglas que deben seguirse, los cálculos que deben realizarse, entonces, ¿por qué no utilizar esas visiones de los objetos de su realidad como fuente de información? Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la síntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemático , ya que si conseguimos describir adecuadamente estas visiones podremos obtener mediante Ingenier í a Inversa el modelo de datos. Este método se conoce como síntesis de visiones canónicas . Este es el punto de partida de la metodología de GeneXus : d escribir las visiones de los usuarios para modelar el sistema . A partir de este modelo se construye el soporte computacional (base de datos y programas ) para soportarlo.
• #5: Para fijar ideas, compararemos la metodología utilizada por GeneXus , conocida como Metodología Incremental , con las metodologías tradicionales más utilizadas actualmente. Algunos ejemplos de estas metodologías: Análisis Estructurado Ingeniería de la Información Análisis Esencial Las metodologías tradicionales difieren entre sí en varios aspectos, pero tienen una característica común a todas: separan el análisis de los datos del de los procesos . A continuación veremos un esquema general que podría aplicarse a cualquiera de e stas metodologías y estudiaremos sus problemas.
• #7: La primer tarea, generalmente, es el análisis de datos. Suponiendo que estemos queriendo desarrollar aplicaciones para una empresa, entonces comenzamos por analizar la empresa desde el punto de vista de los objetos existentes y sus relaciones, obteniendo como resultado un modelo de datos con las Entidades y Relaciones encontradas (Modelo ER). Construir un sistema integrado, que requiere un modelo de datos Corporativo de la empresa , no es una tarea simple , ya que el número de objetos y relaciones tiende a ser muy grande. Debido a la complejidad en la construcción de un sistema integrado, lo que se hace normalmente es dividirlo en módulos, donde cada uno soluciona los problemas operativos de un área en particular de la empresa. Con esto s implificamos notablemente la tarea de modelado. Pero los módulos operan sin una real integración, lo que hace que exista información redundante y como consecuencia, todo intento de buscar información fuera del entorno de cada aplicación result a imposible o por lo menos peligroso. En caso de que posteriormente deseemos realizar la integración de esos módulos, tendremos que realizar modificaciones sobre los modelos de datos, lo que a pesar de la complejidad podemos calificar como posible. Sin embargo, las modificaciones que deberemos realizar sobre los programas tienen un costo tan elevado que hacen inviable la integración.
• #8: Los fundadores de ARTech han desarrollado una amplia actividad de consultoría internacional en diseño de grandes bases de datos. Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen cientos de tablas, les quedó claro que no debía perderse más tiempo buscando algo que no existe: las bases de datos estables. Luego de importantes investigaciones, desarrollaron una teoría, organizaron una metodología e implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia con las bases de datos reales (inestables), a costo mínimo.
• #9: Utilizando GeneXus , la tarea básica del analista es la descripción de la realidad. Sólo el hombre podría desarrollar esta tarea, ya que sólo él puede entender el problema del usuario. Desde luego que esto modifica la actividad del analista e incluso su perfil óptimo, ya que lo transforma en un “Business Analyst”. Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con él las especificaciones a nivel de prototipo, en vez de desarrollar su actividad a través de tareas de bajo nivel como: diseñar archivos, normalizar, diseñar programas, programar, buscar y eliminar los errores de los programas.
• #10: Una vez creada la Base de Conocimiento, el siguiente paso es empezar a describir los objetos de la realidad mediante objetos GeneXus . A partir de los objetos definidos en la Base de Conocimiento, GeneXus genera automáticamente tanto los programas de creación / reorganización de la base de datos como los programas de la aplicación. El término Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automática el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permitan obtener más conocimiento. Si un objeto de la realidad cambia su estructura o comportamiento, o si simplemente se encuentran nuevos objetos aún no modelados, el analista GeneXus deberá realizar las modificaciones del caso en el objeto GeneXus correspondiente, o crear los nuevos objetos y GeneXus se encargará automáticamente de actualizar la base de datos y los programas. La metodología GeneXus es una metodología incremental, pues parte de la base que la construcción de un sistema se realiza mediante aproximaciones sucesivas. Las características de GeneXus que lo colocan en esta categoría de metodologías son su capacidad de inferir conocimiento a partir de los objetos existentes en la B ase de C onocimiento, y de realizar automáticamente los cambios necesarios en la base de datos y en los programas. D e no ser por estas características el desarrollo incremental sería inviable.
• #11: Como se ha visto, existen varios caminos para la implementación de aplicaciones: 1. Programación utilizando lenguaje de 3era. generación. 2. Programación utilizando lenguajes de 4ta. generación 3. Generación / interpretación automática de la especificación funcional. 4. Desarrollo incremental. La productividad en el desarrollo de aplicaciones aumenta de arriba a abajo. Disminuir en gran forma el mantenimiento de las aplicaciones (datos y programas), sólo se consigue con el desarrollo incremental.
• #12: Como dijimos antes, una vez creada la B ase de C onocimiento, la siguiente tarea a realizar es empezar a describir los objetos de la realidad, mediante objetos GeneXus . Existen 5 objetos básicos: TRANSACCIONES Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones pueden ser identificadas prestando atención a las entidades que el usuario menciona (por ej. Clientes, Proveedores, Artículos). A partir de las transacciones GeneXus infiere el diseño de la base de datos. REPORTES Recuperan información a partir de los datos almacenados y no los alteran. Los reportes son lo que conocemos habitualmente como listados. PROCEDIMIENTOS Procesos no interactivos de actualización de la base de datos (procesos batch). PANELES DE TRABAJO Permiten definir consultas interactivas a la base de datos. Es un objeto muy flexible que se presta para múltiples usos. MENUES Objetos organizadores del resto.
• #13: Veamos ahora con más detalle el proceso de desarrollo de una aplicación con GeneXus . GeneXus captura el conocimiento que reside en los objetos descriptos y lo sistematiza en una B ase de C onocimiento. GeneXus funciona basado en su capacidad de inferencia. Así infiere, por ejemplo: En el modelo de datos: las tablas, las restricciones de integridad y los índices necesarios. Los programas de creación y/o de reorganización de la base de datos. Los programas de la aplicación. Los análisis de impacto de los cambios.
• #14: A partir del conocimiento especificado a través de las transacciones, GeneXus diseña el modelo de datos normalizado (en 3era. forma normal). No obstante, muchas veces para obtener los tiempos de respuesta necesarios, deben admitirse desvíos a la 3era. Forma normal. Genexus permite hacerlo mediante la definición de “redundancias”, que luego mantiene automáticamente.
• #15: GeneXus genera automáticamente los programas necesarios para crear la base de datos, y la crea mediante ellos (es decir, ejecuta los programas que él mismo creó para crear / reorganizar la base de da to s ).
• #16: GeneXus genera automáticamente, a partir de la Base de Conocimiento, los programas de la aplicación.
• #17: En este estado , la aplicación está pronta.
• #18: Como se ha dicho, durante el ciclo de vida de la aplicación, existen muchas modificaciones. Ante cambios en las visiones de usuarios, GeneXus diseña la nueva base de datos.
• #19: Algunas veces, la nueva base de datos coincide con la anterior . Otras veces, existen cambios en la base de datos. El análisis de impacto de los cambios nos informa si debe reorganizarse la base de datos, cómo debe ser hecha esa reorganización y, los eventuales problemas que esa reorganización podría ocasionar. Una vez analizado el análisis de impacto , el analista resolverá efectuar la reorganización o renunciar a ella volviendo a la situación anterior.
• #20: Si el analista ha dado el visto bueno a la reorganización, GeneXus genera automáticamente los programas necesarios para realizar esa reorganización. La reorganización consiste entonces, en ejecutar esos programas. En realidad es de esperar que hay an muchas tablas comunes, que no se modificarán en la reorganización.
• #21: GeneXus , considerando l as nuevas definiciones efectuadas, estudia el impacto de los cambios sobre los programas actuales y produce un informe sobre el tema.
• #22: GeneXus genera /regenera automáticamente los programas de aplicación necesarios.
• #23: Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento está completo.
• #24: La construcción automática de la Base de Datos y programas a partir de una única fuente de especificación permit e a GeneXus aplicar una metodología de desarrollo que l lama mos “Metodología Incremental”, ya que el proceso se realiza mediante aproximaciones sucesivas. En cada momento desarrollamos la aplicación con el conocimiento que tenemos y luego cuando pasamos a tener más (o simplemente diferente) conocimiento, GeneXus se ocupará de hacer automáticamente todas las adaptaciones en la base de datos y programas. El incrementar una aplicación implica cambios en la base de datos y programas. Los cambios en la base de datos pueden tener un costo aceptable, pero el alto costo de las adaptaciones de los programas harían inviable la aplicación de este método si no fueran resueltos automáticamente.
• #25: GeneXus cuenta con tres ambientes de trabajo: Diseño, Prototipo y Producción, que tienen distintos fines y características, como iremos viendo en la práctica. El trabajo se desarrolla en dos ciclos: el Ciclo de Prototipación y el Ciclo de Producción. Ciclo de Prototipación : El diseñador recorrerá repetidamente el bucle Diseño-Prototipo durante la fase de diseño, construyendo y probando sucesivos prototipos del modelo. Ciclo de Producción : Por el contrario, pasará menos frecuentemente al bucle de Diseño-Producción, ya que la generación del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o luego de haber instrumentado y probado algún cambio.
• #26: Al crear una nueva Base de Conocimiento GeneXus , automáticamente se crea el modelo de Diseño, que queda abierto para que empecemos a crear los primeros objetos GeneXus de la aplicación. GeneXus extrae el conocimiento de los objetos que definimos en Diseño, y a partir de este conocimiento diseña el modelo de datos normalizado. El modelo de Diseño no tiene asociada base de datos ni programas de aplicación algunos. Aquí simplemente se definen los objetos GeneXus que estarán contenidos en la Base de Conocimiento. Luego todos los objetos definidos en el modelo de Diseño serán “copiados” a los demás modelos que se creen, tanto de Prototipo como de Producción. Es al pasar al entorno de Prototipo (o Producción) cuando le decimos a GeneXus en qué plataforma deseamos generar y correr la aplicación que estamos desarrollando. Para ello se debe crear un modelo particular, asignarle un nombre y definir algunas propiedades que deseamos que tenga (“preferences”, etc.), así como la plataforma en la que deseamos generar la aplicación. Cuando pasamos a Prototipo por primera vez, no existe ningún modelo de Prototipo creado, por lo cual debemos crear uno, asignarle un nombre, el generador y DBMS que queramos utilizar para este modelo de Prototipo (por ejemplo Visual Basic con Access). Por lo tanto, cada modelo de Prototipo (o Producción) tendrá una base de datos física asociada, y programas de aplicación, generados utilizando el generador seleccionado. Solo en Diseño pueden realizarse cambios que afecten la estructura física de la base de datos (por ejemplo, un cambio que provoque que se agregue un atributo a una tabla). Solo en Prototipo (o Producción) tiene sentido generar programas, pues es en estos modelos en los que hay generadores asociados. Por lo tanto, en el desarrollo incremental de una aplicación, pasaremos repetidamente de Diseño a Prototipo y de Prototipo a Diseño. Con menor frecuen cia se pasará a l modelo de Producción .
• #27: La construcción automática del soporte computacional nos da la gran posiblidad de crear prototipos. Verdaderos prototipos!, ya que estos tendrán un funcionamiento equivalente al del sistema en producción real, permitiendo que se pruebe hasta el último detalle de la aplicación. Los resultados que todos quieren ver, están en forma de programas ejecutando, lo que no es posible sin la utilización de prototipos.
• #28: Toda comunicación es suceptible de errores: El usuario olvida ciertos detalles. El analista no toma nota de algunos elementos. El usuario se equivoca en algunas apreciaciones. El analista interpreta mal algunas explicaciones del usuario. Pero, además, la implementación de sistemas es, habitualmente,una tarea que insume bastante tiempo. Como muchos de estos problemas sólo son detectados en las pruebas finales del sistema, el costo (tiempo y dinero) de solucionarlos es muy grande y la realidad cambia, por lo que no es razonable pensar que se pueden mantener las especificaciones mientras se implementa el sistema. La consecuencia de mantener las especificaciones, es que se acaba implementando una solución relativamente insatisfactoria. El impacto de estos problemas disminuiría mucho si se consiguiera probar cada especificación, inmediatamente, y saber cuál es la repercusión de cada cambio sobre el resto del sistema.Una primera aproximación a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes, etc., animados por menúes. Esto permite ayudar al usuario a tener una idea de qué sistema se le construirá pero, al final, siempre se presentan sorpresas.