Capitulo1
•Download as PPS, PDF•
0 likes•175 views
El documento describe una metodología de desarrollo de software basada en el conocimiento que utiliza una base de conocimiento para modelar la realidad. Esta metodología permite el desarrollo automático de aplicaciones, bases de datos y programas a partir de la base de conocimiento. También permite la modificación y actualización automática de las aplicaciones cuando cambian los requisitos de los usuarios, analizando y generando automáticamente los cambios necesarios.
![Herramientas y Metodologías ,[object Object],BASE DE DATOS PROGRAMAS REALIDAD](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Capitulo1
Similar to Capitulo1 (20)
Recently uploaded
Recently uploaded (20)
Capitulo1
- 3. Modelado de la realidad a partir de las visiones de los usuarios BASE DE DATOS PROGRAMAS VISIONES DE USUARIOS Satisface MODELO DE LA REALIDAD Ingenieria Inversa
- 6. REALIDAD ANALISIS DE DATOS BASE DE DATOS ANALISIS FUNCIONAL PROGRAMACION PROGRAMAS GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL
- 7. REALIDAD ANALISIS DE DATOS BASE DE DATOS ANALISIS FUNCIONAL PROGRAMACION PROGRAMAS GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL
- 8. REALIDAD ANALISIS DE DATOS BASE DE DATOS ANALISIS FUNCIONAL PROGRAMACION PROGRAMAS GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL
- 9. REALIDAD ANALISIS DE DATOS BASE DE DATOS ANALISIS FUNCIONAL PROGRAMACION PROGRAMAS GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL
- 10. Metodología
- 11. Desarrollo con REALIDAD DESCRIPCION DE OBJETOS
- 12. Desarrollo con REALIDAD DESCRIPCION DE OBJETOS BASE DE CONOCIMIENTO BASE DE DATOS PROGRAMAS
- 13. Comparación de Metodologías REALIDAD DESCRIPCION DE OBJETOS BASE DE CONOCIMIENTO BASE DE DATOS PROGRAMAS ANALISIS DE DATOS ANALISIS FUNCIONAL PROGRAMACION GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL
- 14. Descripción de Objetos Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)
- 15. Sistematización del conocimiento Base de Conocimiento Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)
- 16. Inferencia de la Base de Datos Base de Conocimiento Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Datos
- 17. Creación de la Base de Datos Base de Conocimiento Base de Datos Programas Generación BD Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)
- 18. Generación de los Programas de la Aplicación Base de Conocimiento Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Datos
- 19. Resultado final en la Etapa de Desarrollo Base de Conocimiento Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Aplicaciones Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Datos
- 20. Las visiones de los usuarios cambian Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Base de Conocimiento Nueva Base de Datos Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues Base de Datos
- 21. Análisis de Impacto Totalmente Automático Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Nueva Base de Datos Análisis de impacto Base de Conocimiento Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues Base de Datos
- 22. Generación de Programas de Reorganización de la Base de Datos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Nueva Base de Datos Programas de Reorganiz. Base de Conocimiento Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues Base de Datos
- 23. Análisis automático del impacto de los cambios sobre los programas Nueva Base de Datos Base de Conocimiento Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Análisis de impacto Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues
- 24. Generación automática de nuevos Programas Nueva Base de Datos Base de Conocimiento Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Generación de nuevos Programas Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues
- 25. Nueva realidad, con los cambios en la aplicación Aplicaciones Nueva Base de Datos Base de Conocimiento Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues
- 26. Metodología Incremental Consiste en construir una aplicación mediante aproximaciones sucesivas. DEFINICION INICIAL
- 27. Ciclos Diseño-Prototipo y Diseño-Producción Diseño Prototipo Producción
- 29. Prototipación Integral en PC BASE DE DATOS PROGRAMAS MODELO DE LA REALIDAD Construcción Automática Usuario probando todos los detalles de la aplicación
Editor's Notes
- 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 . ?
- 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.
- 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.
- 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.
- Con la división del sistema en módulos, la empresa tendrá resueltos sus problemas operativos, pero aparecerán indefectiblemente problemas de carencia de información que permita orientar la gestión y la toma de decisiones de alto nivel, ya que a este nivel, la información que se necesita es principalmente de naturaleza corporativa. En este sentido necesitamos orientarnos cada vez más a las bases de datos corporativas, pero en la medida en que lo hacemos, la cantidad de objetos que integran la base de datos y sus relaciones se hacen más complejas. Esto lleva a que el diseño de una base de datos corporativa sea una tarea muy complicada y en la que son muchos los errores que pueden cometerse. GeneXus apunta a la creación de sistemas corporativos , brindando herramientas y una metodología que hagan posible la realización de esta tarea. Continuando con el proceso de desarrollo en una metodología tradicional, luego de obtener el modelo de datos se pasa a diseñar la base de datos. Podemos ver que entre un buen modelo de datos, y el diseño de la base de datos necesaria para soportarlo, existe una transformación trivial. Por ello, para mayor claridad del dibujo, eliminaremos la etapa intermedia y colocaremos directamente la base de datos. Pero el modelo de datos no es suficiente para desarrollar los programas de aplicación, porque describe los datos pero no los comportamientos. Se recurre, pues, a una tarea generalmente llamada Análisis Funcional , donde se estudia la empresa desde el punto de vista de las funciones existentes. Su resultado es una Especificación Funcional . Sería deseable que esta Especificación Funcional fuera independiente de la Especificación de Datos. Pero esto no es lo común en las metodologías estudiadas. Las especificaciones producidas son “file dependents“ y, en consecuencia, modificaciones en el diseño de la base de datos, implican la necesidad de revisar las especificaciones funcionales. Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportar las empresas. Luego de que tenemos la especificación funcional, estamos prontos para crear los programas de las aplicaciones. Para ello contamos con varias alternativas, entre las que se destacan la programación en lenguajes de 3era. y 4ta. Generación: Lenguajes de 3a. Generación Lenguajes de bajo nivel como pueden ser COBOL, RPG, C, PASCAL, ADA, FORTRAN. Lenguajes de 4a. Generación Lenguajes de programación de alto nivel como pueden ser CA IDEAL, INFORMIX 4GL, NATURAL 2, PROGRESS, etc.. Desde un punto de vista conceptual, ambos casos son idénticos. En ambos el analista debe estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en el lenguaje de programación.
- Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generación se escribe mucho menos (probablemente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el número de errores cometidos es mucho menor. Podría argumentarse en contrario, que se pierde flexibilidad con estas herramientas, lo que es cierto en términos teóricos, pero es irrelevante en términos prácticos, dado que hoy estas herramientas están dotadas de primitivas que permiten complementar su código, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta a ambos por igual. Como consecuencia, los lenguajes de 4a. generación permiten aumentos de productividad muy grandes sobre los de 3a. en la tarea de desarrollo, pero ayudan bastante poco en la etapa de mantenimiento . Otra alternativa es la utilización de un “generador” que es una herramienta que puede interpretar la especificación funcional, (que obviamente debe ser totalmente rigurosa), y producir automáticamente los programas. Aquí existe una diferencia conceptual muy grande con el caso anterior. En este caso el analista describe el problema de una forma declarativa (no existe algoritmo ni codificación procedural alguna). Algunos ejemplos son: ADELIA, AS/SET, LANSA, SYNON, TELON, etc. Existe otra categoría de herramientas conceptualmente idéntica: la de aquellas que simplemente interpretan la especificación, como por ejemplo: MAGIC y SAPIENS. La programación en ambos casos es totalmente automática, por lo que el aumento de productividad sobre las herramientas de 3era. Y 4ta. generación es muy grande. Podría argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4a. generación, que se pierde flexibilidad con estas herramientas, lo que otra vez es cierto en términos teóricos, pero es irrelevante en términos prácticos, ya que hoy en día estas herramientas están dotadas de Lenguajes de Diagramas de Acción (en la práctica lenguajes de 4a. generación), que permiten complementar su código, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta también a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los Generadores y los Intérpretes (como los lenguajes de 4a. generación) ayudan bastante poco en la tarea de mantenimiento.
- Resumiendo aquí las tres opciones vistas: Lenguajes de 3a. Generación Baja productividad en el desarrollo Lenguajes de 4a. Generación Buen aumento de productividad en el desarrollo sobre L3G. Generadores/Intérpretes Buen aumento de productividad en el desarrollo sobre L3G y L4G. Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho, dado que en todas ellas se utilizan descripciones de procesos que pueden perder su validez cuando existen modificaciones de archivos y que, por ello, deben ser revisadas y mantenidas manualmente. Por supuesto, el costo de mantenimiento difiere mucho entre las distintas alternativas vistas, ya que por ejemplo, en el caso de la utilización de Generadores o Intérpretes, una vez modificadas las especificaciones funcionales, la generación de los programas es automática. Existe, sin embargo, un postulado cuyo cumplimiento minimizaría estos problemas hasta el punto de hacerlos irrelevantes: PUEDE OBTENERSE UNA BASE DE DATOS ESTABLE. Lamentablemente, este postulado es falso, y sobran los contraejemplos que lo demuestran.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 ).
- GeneXus genera automáticamente, a partir de la Base de Conocimiento, los programas de la aplicación.
- En este estado , la aplicación está pronta.
- 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.
- 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.
- 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.
- GeneXus , considerando l as nuevas definiciones efectuadas, estudia el impacto de los cambios sobre los programas actuales y produce un informe sobre el tema.
- GeneXus genera /regenera automáticamente los programas de aplicación necesarios.
- Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento está completo.
- 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.
- 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.
- 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 .
- 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.
- 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.
- Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución, inmediatamente, una aplicación funcionalmente equivalente a la deseada, hasta en los mínimos detalles. Esto es lo que hace GeneXus : un prototipo GeneXus es una aplicación pronta, funcionalmente equivalente a la aplicación de producción. La diferencia entre prototipación y producción consiste en que la primera se hace en un ambiente de microcomputador, mientras que la de producción se realiza en el ambiente objeto del usuario (computador IBM AS/400, microcomputadores o redes de microcomputadores). El prototipo permite que la aplicación sea totalmente probada antes de pasar a producción. Durante estas pruebas, el usuario final puede trabajar con datos reales, o sea que prueba, de una forma natural, no solamente formatos de pantallas, informes, etc., sino también fórmulas, reglas del negocio, estructuras de datos, etc.