FLCD algorithm

Nuevo

Paradigma:

Describir

en

vez

de

Programar

[Gonda2007]

Se pretende "describir" en vez de "programar". Se pretende maximizar las descripciones declarativas y minimizar las especificaciones procedurales. [Gonda2010]

Según Gonda Breogán y Jodal Nicolás, hasta el 2006 la complejidad de los sistemas había aumentado en un 2000% (datos al 2006) la productividad aunque los lenguajes de programación solo aumentaron un 150%. Esta situación hace que los costos crezcan de una manera desmesurada, considerando los costos como una composición de tiempo y dinero. En la actualidad muchas empresas internacionales contratan personal para el desarrollo y mantenimiento de sus sistemas en países de bajos salarios, así influyen en la variable dinero. Pero, en realidad, el esfuerzo de realización de las tareas sigue siendo el mismo ya que el trabajo involucrado sigue siendo el mismo. Se podría considerar que simplemente se cambió la unidad de medida, en estas circunstancias el precio de la hora-hombre es mucho menor. Por lo tanto si se mide el costo en función del dinero, se produce una disminución. Pero, si se considera la dimensión tiempo, ésta no se modifica.

El tiempo es crucial a la hora de desarrollar sistemas y mantenerlos. Por otro lado, los sistemas de software necesitan responder a nuevas necesidades: nuevos dispositivos, nuevos usuarios, nuevas modalidades de uso, nuevas posibilidades de integración y, por todo esto, se hacen cada día más y más complejos y los negocios están sujetos a un “time to market” cada vez más crítico y que no pueden cambiar. Como consecuencia, cada día más negocios se están perjudicando por los tiempos inadecuados de desarrollo de las nuevas soluciones y de mantenimiento de las actuales. Por todo esto es evidente que es necesario un aumento de la productividad a través de tecnologías de muy alto nivel.

La solución no está relacionada tanto en mejorar más todavía los lenguajes de programación sino en la programación en sí. Hoy la enorme mayoría de los sistemas se desarrollan y mantienen con programación manual. Si se "describe" en vez de "programar", se pueden maximizar las descripciones declarativas y minimizar las especificaciones procedurales, haciendo desarrollo basado en conocimiento y no en programación. Esta pretensión constituye un cambio esencial de paradigma e implica un choque cultural.

Metodologías tradicionales de desarrollo y problemas asociados [Artech2008]

La forma tradicional de desarrollar aplicaciones parte de una premisa básica: es posible construir un modelo de datos estable de la empresa. Basándose en esa premisa, la primera tarea que se encara es el análisis de datos, donde se estudia la realidad en forma abstracta y se obtiene como producto el modelo de datos de la empresa. La segunda tarea es diseñar la base de datos. Es muy sencillo diseñar la base de datos partiendo del modelo de datos ya conocido. Una vez que se ha estudiado la realidad desde el punto de vista de los datos, se hace lo propio desde el punto de vista de las funciones (análisis funcional). Sería deseable que el estudio de la realidad tuviera como producto una especificación funcional que dependiera sólo de dicha realidad. Lo que se hace en las metodologías más usadas, sin embargo, es obtener una especificación funcional que se refiere a los archivos de la base de datos (o bien a las entidades del modelo de datos, lo que es esencialmente equivalente). Una vez que se tiene la base de datos y la especificación funcional, se pasa a la implementación de las funciones, existiendo tradicionalmente para ello varias opciones (lenguajes de 3ª. o 4ª generación, generadores, interpretadores). Sin embargo, todas las formas de implementación vistas tienen un problema común: parten de la enunciada premisa: es posible construir un modelo de datos estable de la empresa, y esta premisa es falsa.

Especialidad en Ingeniería de software

Figura 10.1: Metodología Tradicional [Genexus]

Realmente es imposible hacer, de una forma abstracta, un modelo de datos detallado de la empresa y con el suficiente nivel de detalle y objetividad, porque nadie la conoce como un todo. Por ello es necesario recurrir a múltiples interlocutores, y cada uno de ellos proyecta sobre el modelo, su propia subjetividad. Una consecuencia de esto es que, durante todo el ciclo de vida de la aplicación, se producen cambios en el modelo. Pero aún si se considerara la situación ideal, donde se conocen exactamente las necesidades y, entonces, es posible definir la base de datos óptima, el modelo no podrá permanecer estático porque deberá acompañar la evolución de la empresa. Todo esto sería poco importante, si la especificación funcional y la base de datos fueran independientes. Sin embargo, dado que la especificación funcional se refiere a la base de datos, las inevitables modificaciones en ésta implican la necesidad de modificaciones (manuales) en aquella.

La mayor consecuencia de lo anterior está constituida por los muy altos costos de mantenimiento: en la mayoría de las empresas que trabajan de una manera convencional se admite que el 80% de los recursos que teóricamente están destinados al desarrollo, realmente se utilizan para hacer mantenimiento de las aplicaciones ya implementadas. Cuando se trata de aplicaciones grandes la situación es aún peor: este mantenimiento comienza mucho antes de la implementación, lo que hace que los costos de desarrollo crezcan en forma hiperlineal con respecto al tamaño del proyecto.

Dado que es muy difícil, en este contexto, determinar y propagar las consecuencias de los cambios de la base de datos sobre los procesos, es habitual que, en vez de efectuarse los cambios necesarios, se opte por introducir nuevos archivos redundantes, con la consiguiente degradación de la calidad de los sistemas y el incremento de los costos de mantenimiento.

¿Paradigma orientado al conocimiento? [Gonda2003]

En los últimos años se han solidificado los sistemas de gerencia de base de datos relacionales: hoy es impensable hablar de otro tipo de Sistema de Gerencia de Base de Datos. Se han configurado estándares robustos que, utilizados estrictamente, permiten la portabilidad de las

Especialidad en Ingeniería de software

Es previsible, en cambio, que se siga dando cada vez más solidez: disponibilidad, seguridad, eficiencia, escalabilidad, optimización de recursos y que se neutralicen las nuevas amenazas como las representadas por virus innovadores.

Paralelamente se ha generalizado la programación orientada a objetos (en particular fuertemente impulsada por el previsible auge de las plataformas Java y .net) y es vital que se resuelva rápidamente el problema de la vinculación natural de los programas con la base de datos (Object Relational Mapping).

Hay grupos de informáticos que creen en “bases de datos inteligentes” que permitan alimentar en forma declarativa todo el conocimiento necesario (fundamentalmente “reglas del negocio”, “reglas de precedencia y/o de flujo” y “reglas de autorización” con toda la generalidad que esos conceptos representan) de manera que cualquier usuario sin la necesidad de conocimiento técnico alguno, de una manera simple, pueda hacer en cualquier momento todo aquello que quiera y esté autorizado a hacer, sin necesidad de programar. Este es un nuevo paradigma.

Nuevo Paradigma: desarrollo basado en conocimiento [Gonda2010]

En los últimos años se ha hablado mucho en la industria de la administración del conocimiento (Knowledge Management) y, dentro de este rótulo se han colocado muchas cosas que están bien distantes del Desarrollo Basado en Conocimiento a que se pretende referir en este trabajo Generalmente la industria se ha referido a maneras de organizar y/o acceder el conocimiento para ser utilizado de una forma tradicional por los seres humanos. Provee los medios para la recolección, organización y recuperación computarizada de conocimiento Se trata de una versión actualizada, utilizando la tecnología actualmente disponible, de los libros (y que es de enorme utilidad para toda la humanidad): se accede a un cierto conocimiento leyendo un libro y, en nuestra mente, se hacen razonamientos sobre ese conocimiento lo que, eventualmente, determina acciones. Los buscadores de texto inteligentes que están disponibles desde hace pocos años hacen que este conocimiento sea cada vez más accesible a los seres humanos. Como característica general, este conocimiento no es “entendible” por una máquina y, en consecuencia, no es operable. Adicionalmente, como el razonamiento de los seres humanos puede lidiar razonablemente (dentro de ciertos límites) con la ambigüedad y, aún, con la inconsistencia, este conocimiento muchas veces no es riguroso. [Artech2008].

Ya en el año 1983 Blazer y sus colegas [Barler] habían propuesto un modelo operacional que soporte la implementación automática a través de un CASE (asistente de desarrollo de software computarizado). La especificación de software operacional es obviamente una parte integral de la base de conocimiento de ingeniería de software. Crear este tipo de base de conocimiento, según los mencionados autores, requiere que:

• Exista un modelo de representación de base del conocimiento y tenga asociado un mecanismo de almacenamiento.

• La representación de la base del conocimiento esté embebida en un entorno de sistema de conocimiento que pueda ser accedido, modificado y ejecutado.

• La base del conocimiento está configurada con la versión inicial de un modelo operacional del ciclo de vida

Un sistema basado en conocimiento útil debe ser capaz de almacenar conocimiento de una manera persistente, una que pueda ser administrada y mantenida como se mantiene una base de datos. Una base de conocimiento persistente puede construirse acoplando sistemas de conocimiento y un administrador de base de datos relacional. [IEEE]

Entonces, es bueno restringir el concepto de conocimiento que se utilizará al mencionar el término Desarrollo Basado en Conocimiento adhiriendo a lo especificado por Artech [Artech2008]. Se trata de conocimiento que cumple las siguientes condiciones:

• Riguroso

• Representable en forma objetiva • Operable

Especialidad en Ingeniería de software

Una nueva manera de resolver el problema del desarrollo de sistemas pasa por la sustitución de la premisa básica enunciada anteriormente: asumir que no es posible construir un modelo de datos estable de la empresa y, en cambio, utilizar una filosofía incremental y hacer un Desarrollo Basado en Conocimiento. Un esquema incremental parece muy natural: no se encaran grandes problemas, sino que se van resolviendo los pequeños problemas a medida que se presentan. [Artech2008].

Este paradigma de desarrollo basado en conocimiento es completamente diferente a los usuales paradigmas de desarrollo de sistemas: no parte de un modelo de datos pre-existente ni de concepciones abstractas sobre lo que es importante para la empresa y lo que no lo es. [Gonda2010]

En todas las organizaciones hay múltiples usuarios (desde el Gerente General al cargo más bajo en el escalafón de la empresa). Pero, difícilmente exista alguien entre todos ellos que tenga el conocimiento suficiente sobre los datos de la organización. Tampoco es muy probable que alguno de ellos conozca estos datos con la adecuada objetividad y el suficiente detalle. Y este no es un problema que afecte exclusivamente a las grandes empresas, ocurre en empresas de todo tamaño. Por ello se debe privilegiar lo concreto sobre lo abstracto, porque los usuarios, que serán múltiples y tendrán los perfiles y roles más diversos en la empresa, se manejan bien con elementos concretos de su ambiente y mal con conceptos abstractos: la representación del conocimiento debe ser simple, detallada y objetiva.

La idea de este paradigma es partir de las diferentes visiones de sus usuarios. Cada usuario, perteneciente a cualquier nivel de la empresa, conoce bien la visión de los datos con los que trabaja a diario. Así, tomando como base este conjunto de visiones de datos, se encuentra el modelo de datos ideal derivado de ellas (puede probarse rigurosamente que, dado un número de visiones de usuarios, existe solo un modelo relacional mínimo que las satisface [Gonda2007]).

Figura 10.2: Proceso de Ingeniería Inversa [Gonda2007]

Se puede pensar entonces en un proceso de ingeniería inversa que, a partir de una serie de visiones de datos de diferentes usuarios, desarrolla el modelo ideal y la base de datos relacional correspondiente. Todo este conocimiento se puede sistematizar todo este conocimiento es lo que Gonda denomina una Base de Conocimiento. Además, como

Especialidad en Ingeniería de software

diferencia de los tradicionales diccionarios de datos, es su capacidad de inferencia: se pretende que, en cualquier momento, se puedan obtener de esta base de conocimiento, tanto elementos que se han colocado en ella, como cualquier otro que se pueda inferir a partir de ellos. Si este objetivo se logra, la base de datos y los programas de aplicación pasan a ser transformaciones determinísticas de dicha base de conocimiento y ello permite [Artech2008]:

• Generarlos automáticamente

• Ante cambios en las visiones de los usuarios determinar el impacto de dichos cambios sobre datos y procesos y propagar esos cambios generando:

o los programas necesarios para convertir los datos; o los programas de la aplicación afectados por los cambios;

o _{Aquellos programas de aplicación que no han sido afectados por los cambios} pero que, ahora, podrían ser sustituidos por otros más eficientes

Modelo Externo y Base de Conocimiento [Gonda2007]

Históricamente la comunidad informática comenzó trabajando sólo con un modelo físico, que tenía muchas rigideces. Luego fue introduciendo otros modelos a los efectos de tener más flexibilidad y obtener cierta permanencia de las descripciones. Por ejemplo ANSI SPARC [ANSI-SPARC] introduce tres modelos:

• Modelo Externo donde se representan las visiones externas.

• Modelo Lógico o Conceptual: Es otro modelo (generalmente un modelo E-R) que se pretendía obtener por abstracción de la realidad.

• Modelo Físico: Se refería fundamentalmente al esquema de la base de datos. La idea era desarrollar paralelamente los tres modelos para que los programas sólo interactuaran con el Modelo Externo y, a partir del Modelo Lógico se hiciera un mapeo entre esos programas y la base de datos (Modelo Físico) y que ello hiciera independientes a los programas de la base de datos.

El informe fue muy elogiado en su momento y, luego, casi olvidado. Más allá de todo esto, el informe ANSI SPARC sigue siendo válido hoy. La mayor diferencia es la tecnología disponible. En los años transcurridos, los cambios tecnológicos han sido muy importantes.

Analizando el asunto a la luz de la tecnología actual, los desarrolladores que trabajan con el nuevo paradigma de desarrollo basado en conocimiento, concluyen que pueden existir varios modelos, pero el modelo realmente importante para los usuarios y los desarrolladores, es el Modelo Externo: en él se recoge el conocimiento exterior y todo lo demás como, otros modelos auxiliares que pudieran ayudar, debe y puede inferirse automáticamente a partir de dicho Modelo Externo.

Ellos pone el énfasis en el Modelo Externo, porque es allí donde está el conocimiento genuino y donde reposa la esencia (el “qué”) y es el realmente importante para los usuarios y los desarrolladores. En él se recoge el conocimiento exterior y todo lo demás, como otros modelos auxiliares que pudieran ayudar, puede inferirse automáticamente a partir de ese Modelo Externo. Un “Modelo Externo” no puede contener ningún elemento físico o interno como: archivos, tablas, entidades, relaciones entre entidades, índices o cualquier otro que pueda deducirse automáticamente del mismo. Ante nuevas posibilidades de la tecnología y necesidades de los clientes, lo primero a hacer es ampliar dicho Modelo Externo.

El Modelo Relacional está orientado a obtener una buena representación de los datos en una Base de Datos, obedeciendo algunas condicionantes muy deseables: eliminar la redundancia e introducir un pequeño conjunto de reglas, de manera de evitar las mayores fuentes de inconsistencia de los datos e introducir un conjunto de operadores que permitan manipular los datos a buen nivel.

El Modelo Externo se utiliza, entonces, para obtener y almacenar el conocimiento. Este modelo pretende ser la representación más directa y objetiva posible de la realidad, por ello, tomamos las visiones de los diferentes usuarios. Estas visiones son almacenadas en el modelo. Luego, se captura todo el conocimiento contenido en ellas y se lo sistematiza para maximizar las

Especialidad en Ingeniería de software

capacidades de inferencia. Con eso se logra la independencia de la implementación, porque se tiene una descripción del sistema en alto nivel, descripción que solo cambiará si cambian las visiones sobre el mismo. Por ello se toman las visiones de los diferentes usuarios. Visiones que son almacenadas en el modelo. Luego se captura todo el conocimiento contenido en ellas y se lo sistematiza para maximizar las capacidades de inferencia. El Modelo Relacional se utiliza para representar y manipular los datos: es el modelo interno o físico, pero será inferido por alguna herramienta que trabaje con este paradigma a través de un procedimiento de ingeniería inversa. [MárquezLisboa]

Para definir el Modelo Externo, de manera que pueda aplicarse ingeniería inversa sobre ellas se realiza una descripción formal y rigurosa para que no haya ambigüedades y que un programa pueda “inferir” todo eso que los programadores hacen todavía a mano.

La Base de Conocimiento (Knowledge Base) inicialmente tiene asociado un conjunto mecanismos de inferencia y contiene reglas generales [MárquezLisboa], como por ejemplo las que aseguran la consistencia, que son independientes de cualquier aplicación particular. Luego, el analista comienza a describir la realidad del usuario a través de objetos, estas descripciones (el Modelo Externo) son sistematizadas automáticamente y pasan a estar en la base de conocimiento. Además, sobre ese conocimiento, obtiene un conjunto de resultados que le ayudan a mejorar la eficiencia de las inferencias posteriores. Adicionalmente, sobre el conocimiento anterior, el sistema infiere lógicamente un conjunto de resultados que ayudan a mejorar la eficiencia de las inferencias posteriores.

Figura 10.3: Base de conocimiento [Gonda2007]

Todo el conocimiento de la Base de Conocimiento es equivalente al contenido en el Modelo Externo (subconjunto de ella), ya que consiste en el propio Modelo Externo más reglas y mecanismos de inferencia independientes de dicho Modelo Externo y un conjunto de otros elementos que son automáticamente inferidos a partir del mismo.

El desarrollador puede alterar, modificando objetos de la realidad del usuario, el Modelo Externo y las modificaciones se propagarán automáticamente a todos los elementos que lo necesiten: otros elementos de la Base de Conocimiento, Base de Datos y programas de la aplicación. De la misma manera, el desarrollador no puede alterar directamente ningún elemento que no pertenezca al Modelo Externo.

Especialidad en Ingeniería de software

manera totalmente diferente y el conocimiento de los clientes seguiría siendo utilizable sin problema alguno.

Se intenta, entonces, hacer un modelo que tenga las siguientes características:

• Conocimiento adecuado para su tratamiento automático. Modelo con el cual un software de computador pueda trabajar automáticamente. Esto implica que el conocimiento del modelo debe ser “entendible” y “operable” automáticamente.

• Consistencia. Modelo siempre consistente

• Ortogonalidad. Los objetos que en un determinado momento constituyen el modelo deben ser independientes entre sí. La adición de un nuevo objeto o su modificación o eliminación no implicarán la necesidad de modificar ningún otro objeto.

• Proyecto, generación y mantenimiento automáticos de la base de datos y los programas. Entre las cosas que un software de computador puede hacer automáticamente con el modelo, son esenciales el proyecto, generación y mantenimiento automáticos de la base de datos y los programas.

• Escalabilidad. Los ítems anteriores expresan las características cualitativas que debe tener el modelo. Pero se pretende resolver problemas grandes. Para ello se necesita que los mecanismos de almacenamiento, acceso e inferencia del modelo actúen eficientemente con independencia del tamaño del problema.

En resumen, la Base de Conocimiento y los mecanismos de inferencia asociados constituyen una gran “máquina de inferencia”. Un buen ejemplo de esto es: dada una visión de datos se puede inferir en forma totalmente automática el programa necesario para manipularla.