ES2936090T3 - Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño - Google Patents

Abstract

El presente invento es un sistema y un método que, a partir de la entrada de estructuras lógicas de información en un dispositivo electrónico compuesto por memoria y procesador, produce de manera automática salidas en dispositivos visuales, que pueden ser operados para crear información de procesos de negocio, reemplazando a las aplicaciones de software que normalmente son desarrolladas mediante la programación tradicional conocida en la industria del software. Dada la información correspondiente a la estructura lógica de un diseño de software, esta información se ingresa en la máquina, que la almacena en una memoria en forma de modelos. Dichos modelos son interpretados por el sistema 100 que produce de manera automática estructuras en dispositivos visuales que permiten reemplazar a un software. El invento es el proceso que utiliza el sistema 100 para ingresar, almacenar, interpretar y producir las estructuras visuales y de lógica estructural que reemplazan a un software.

Description

DESCRIPCIÓN

Método implementado por computador que expone aplicaciones tipo software a partir de especificaciones de diseño

Referencia cruzada a solicitudes relacionadas

Esta solicitud reivindica los beneficios de la fecha de presentación de la solicitud de patente provisional U.S. N° 62/161,216 titulada “Método implementado por computador que expone aplicaciones tipo software a partir de especificación de diseño”, que fue presentada el 13 de mayo de 2015, por los mismos inventores de esta solicitud.

Campo de la invención

El presente invento es un sistema y un método implementado por computador para producir automáticamente aplicaciones de tipo software completamente operables a partir de especificaciones de diseño de software.

Este sistema le permite al usuario ingresar diseños de clases y diseños de pantallas (especificaciones de diseño de software) a través de un dispositivo de entrada/salida. El procesador aplica dos protocolos para crear automáticamente modelos funcionales y visuales que se almacenan en una memoria de base de datos. Luego, combina estos modelos con componentes gráficos, e instancia automáticamente aplicaciones de tipo software, sin generación de código compilable, que se presentan al usuario para ser operadas y producir información como resultado.

Descripción del estado del arte

La industria del software propone como mecanismo de construcción de soluciones una serie de actividades entre las cuales se encuentran, la construcción de una base de datos y la codificación de un programa de computadora, que funcionan en el marco de una arquitectura que permitirá al software resultante operar en entornos de múltiples usuarios. Estas actividades funcionan en el marco de una arquitectura que le permitirá al software resultante operar en múltiples entornos de usuario. Dichas tareas son realizadas por personas capacitadas para comprender el diseño de un software y a partir de allí desarrollar el programa. La naturaleza de las tareas determina que la construcción de un software sea llevada a cabo por un equipo de trabajo donde se destacan los siguientes perfiles especializados:

- Arquitecto: define la arquitectura de capas de la aplicación teniendo en cuenta el entorno en el que operarán los usuarios. Ejemplos de arquitecturas son SOA (services oriented arquitectura), Cliente Servidor, etc. - Programador de la base de datos: construye las estructuras donde serán almacenados los datos que el usuario genere con el uso de la aplicación. Existen herramientas llamadas motores de bases de datos de diferentes tecnologías pero que actualmente trabajan con estándares comunes ya establecidos.

- Programador de la aplicación: escribe el código de programa en un lenguaje definido (Java, C#, Vbnet, etc) que luego es compilado para obtener el código objeto que la computadora va a ejecutar, proporcionando la aplicación final de acceso al usuario.

- Diseñador de la interfaz de usuario: diseña pantallas, componentes visuales y plantillas de estilos gráficos que permiten al programa de computación presentarse ante el usuario de manera más amigable y fácil de usar.

Para llevar a cabo la construcción de un software, es necesario contar con un equipo profesional como el mencionado, ya que normalmente quien necesita hacer un software no tiene esta formación que demanda de varios años de estudio.

El problema que se presenta en la industria del software tiene varias aristas, a saber:

i. La demanda de soluciones crece a nivel mundial con una velocidad mayor a la velocidad de formación de profesionales para esta disciplina. Así se puede observar una gran demanda de desarrollo no abastecida.

ii. El proceso de construcción del software es costoso en tiempo y dinero, lo cual implica a los sectores demandantes no poder cubrir en su totalidad las necesidades de manera oportuna y conveniente.

iii. La multiplicidad de tecnologías (bases de datos, lenguajes de programación, arquitecturas, interfaces de usuario) que evolucionan a gran velocidad, generan en las aplicaciones ya desarrolladas un problema de obsolescencia tecnológica. Esto significa que cuando un software se encuentra operativo, normalmente aparecen nuevas tecnologías que los profesionales de la industria adoptan y la conversión de dicho software demanda un esfuerzo de re-ingeniería tan importante como su primera construcción.

iv. El cambio constante en las reglas de funcionamiento de los negocios en una economía global de interacción vertiginosa, demanda de adaptaciones y mejoras en las aplicaciones de software, que se vuelven inviables en muchas oportunidades debido la conjugación de los factores costo en tiempo/dinero y obsolescencia tecnológica. Por esta razón las aplicaciones de software no ofrecen evolución flexible y oportuna.

El arte previo divulga una pluralidad de sistemas y métodos para la generación automática de aplicaciones de software para reducir en tiempo y costos los ciclos de desarrollo de aplicaciones de software. El documento US2006/0015839 divulga un sistema y un método genera código fuente J2EE compilable, a partir de dos posibles fuentes, una base de datos en donde se especifican en detalle todos los parámetros, tablas y arquitectura del sistema a ser desarrollado, es decir que requiere como input el conocimiento detallado del diseño técnico. A partir de esta definición detallada construye un archivo XML que puede ser intervenido por el usuario para ajustar el diseño. El documento XML final es procesado por una herramienta marco (framework) que automáticamente genera el código J2EE y la arquitectura del sistema. Una herramienta de formas genera automáticamente las formas de interfaz de usuario, también basado en las estructuras definidas en el documento fuente de XML. Una herramienta de despliegue (deployment) del sistema integra la base de datos fuente y el código del programa en una estructura compilable logrando así la aplicación de software resultante.

A diferencia del presente invento, el documento US2006/00115839 genera código J2EE compilable y requiere de un conocimiento previo de la arquitectura informática detallada del sistema a ser desarrollado y de la estructura de la base de datos, parámetros objeto y de campo de tablas. También requiere de un conocimiento detallado de XML y en algunos casos de la introducción de código directamente, para ejecutar algunas acciones no realizadas por los programas de configuración y edición presentados.

Así mismo, el documento US2002/0077823 divulga un método y un sistema para crear aplicaciones de software que puedan operar en múltiples plataformas cliente, particularmente incluyendo plataformas interactuadas mediante voz, lo que implica un método para reconocer voz e interpretarlo como datos de entrada. Por ejemplo, un usuario de un dispositivo móvil con limitaciones de pantalla o teclado puede recibir información de una página web en formato de audio, y de forma recíproca puede interactuar con la página web utilizando palabras y frases habladas en lugar de escritas. Dicho documento se limita a analizar el lenguaje hablado para transformarlo en texto, el cual es posteriormente analizado como cualquier dato de entrada de una aplicación. A diferencia de la presente invención, dicho documento no pretende construir un modelo de software, ni sus documentos de arquitectura y especificación, automáticamente. Dicho documento se apoya en VoiceXML, el lenguaje estándar de especificación de componentes de voz. Para interpretar los comandos recibidos, utiliza plantillas de conversación de voz modificables manualmente, que son guiones manuales con los cuales el programador debe caracterizar el flujo de los comandos recibidos y las respuestas que debe brindar la aplicación. Para definir aquellos comandos o frases orales que la aplicación puede reconocer cuando son hablados por el usuario, el desarrollador debe crear una 'gramática' que es una caracterización explícita de los comandos hablados esperados y sirve para restringir las entradas a esos comandos, a un número pequeño de secuencias permitidas de palabras.

El sistema planteado en esta patente también incluye un mecanismo para que el programador defina “gramáticas en lenguaje natural”, que constituyen una facilidad más para entrenar la aplicación con el tipo de respuestas esperadas, apoyado en plantillas, con sus propias frases. Luego es necesario que el programador manualmente vincule los componentes hablados identificados con variables de la aplicación para ser subsiguientemente procesados. Finalmente, para asegurar que dichos componentes hablados son correctamente identificados, es necesario contar con una base de datos de patrones acústicos y pronunciaciones. Dicho documento proporciona un mecanismo para recibir comandos de voz y transformarlos en variables de entrada de una aplicación, y de una manera equivalente extrapolar el caso inverso para exponer variables de salida como comandos de voz autogenerados. Para ello, se apoya en la especificación de “gramáticas de lenguaje natural” y “modelos de lenguaje”, pero, a diferencia del presente invento, no divulga la capacidad de analizar directamente el lenguaje natural de entrada, de manera libre y exhaustiva, para inferir automáticamente modelos de software, componentes funcionales o de diseño de una aplicación.

Así mismo, el documento US2012/0210296 divulga un método para crear aplicaciones de software tipo BPM (Business Process Management). Utiliza módulos de software pre-creados, que representan diferentes funcionalidades relacionadas a procesos. Estos se ensamblan para lograr la aplicación de software resultante, a partir de la selección que un usuario hace, utilizando palabras del lenguaje natural predefinidas y asociadas a los módulos en una metadata. El usuario puede escoger los procesos de una lista de términos que es expuesta y manejada por el sistema vinculada a los módulos existentes y disponibles. El usuario puede también implementar funciones que no estén en principio disponibles en la lista, pero que define como combinación de módulos existentes y se agregan a la lista de términos.

El presente invento, a diferencia de la patente US2012/0210296, no utiliza funcionalidades de procesos pre-creadas, permite el uso del lenguaje natural libre y a partir de él construye la funcionalidad creando modelos que son instanciables como aplicación de software, no solo para soluciones BPM, sino para todo tipo de solución que pueda describirse en lenguaje natural. El presente invento no implica un método de generación de código compilable, ni limita los resultados a una lista finita de funcionalidades. La patente US2012/0210296 no opera sobre la estructura del lenguaje, sino que utiliza el lenguaje para facilitar al usuario la selección de componentes técnicos de programas funcionales.

En cuanto a la patente US2003/0167455 A1, se proporciona un sistema de producción de software automatizado, en el que los requerimientos del sistema se capturan, se convierten en una especificación formal y se valida su exactitud e integridad. Además, se proporciona un traductor para generar automáticamente una aplicación de software robusta y completa basada en la especificación formal validada, incluido el código de interfaz de usuario y el código de manejo de errores.

De acuerdo con lo anterior, y a pesar de que existe arte previo que automatiza actividades de desarrollo, aún existe la necesidad de la intervención de profesionales expertos en el ciclo de desarrollo, en especial en la depuración de errores. De esta manera, el presente invento reemplaza el proceso de programación por una máquina que produce software de manera automática a partir de un diseño de clases y pantallas que representan un caso de aplicación tipo software a construir, dado como input del proceso. La presente invención resuelve las aristas centrales del problema de la industria de la siguiente manera:

- permite crear aplicaciones de software sin la necesidad de realizar las tareas tradicionales de la industria, es decir, la construcción de una base de datos, programación del código compilable, construcción de una arquitectura específica, que actualmente se realizan de manera manual o automatizada en aquellas herramientas que generan código de programa a partir de especificaciones. El presente invento produce el resultado de manera automática sin generar código de programa, a partir de los modelos funcionales y visuales almacenados en una memoria de base de datos, logrados aplicando los protocolos del presente invento a los diseños de clases y pantallas provistos como input por un usuario.

- reduce el alto costo en tiempo y dinero, obsolescencia tecnológica, desabastecimiento de la demanda, permite que el producto evolucione de manera flexible y oportuna.

En el estado del arte se reportan invenciones que son intérpretes. En la industria del software, los intérpretes se diferencian de los compiladores o de los ensambladores en que mientras estos traducen un programa desde su descripción en un lenguaje de programación al código de máquina del sistema, los intérpretes sólo realizan la traducción a medida que sea necesaria, típicamente, instrucción por instrucción, y normalmente no guardan el resultado de dicha traducción como código. La presente invención es un instanciador de modelos porque no resuelve el software a partir de la compilación en tiempo real de cada una de las instrucciones de un programa. En la presente invención no existe la necesidad de programar las instrucciones del programa, ya que son reemplazadas por modelos almacenados en una base de datos que, al ser invocados por un motor instanciador de modelos, mediante la ejecución de múltiples instrucciones de programa compiladas como parte del motor, crean en memoria las funcionalidades representadas por los modelos. El flujo del programa está bajo el control del usuario y la invocación recurrente de unos modelos con otros, que se materializa a partir de las instrucciones compiladas en el motor.

Dado que el motor instanciador de modelos del presente invento no es limitativo a la resolución de algún caso en particular, éste es capaz de instanciar a partir de cualquier conjunto de modelos referidos a cualquier funcionalidad, la modificación de dicha funcionalidad se realiza agregando o quitando modelos de la base datos, sin necesidad de modificar un programa compilado. Esto es más fácil y más rápido que crear nuevos programas para nuevas funcionalidades y no requiere de testing de programa. Al utilizar intérpretes o compiladores para resolver la funcionalidad se hace necesario realizar testing de programa con el impacto que esta actividad genera en las iteraciones hasta lograr un software de calidad.

Glosario

Con el ánimo de facilitar la interpretación de los conceptos divulgados en esta patente, a continuación, se lista una serie de expresiones que indicarán el alcance de algunos conceptos utilizados en la presente invención.

Usuario Final: Es el actor que utilizará finalmente la solución a través de la interfaz de usuario proporcionada.

Interfaz de usuario: La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, un equipo o una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo.

Aplicación de software; se compone de dos partes: el conjunto de modelos conceptuales que describen el negocio y determinan las reglas de comportamiento funcional de la solución, y el conjunto de modelos de visualización que harán posible que esta funcionalidad se materialice en una interfaz de usuario, con la que un usuario interactúe.

Programación: La programación informática, se deberá entender como el proceso de codificar, depurar y mantener el código fuente de programas computacionales. El código fuente es escrito en un lenguaje de programación. El propósito de la programación es crear programas que exhiban un comportamiento deseado. El proceso de escribir código requiere frecuentemente conocimientos en varias áreas distintas, además del dominio del lenguaje a utilizar, algoritmos especializados y lógica formal. Programar no involucra necesariamente otras tareas tales como el análisis y diseño de la aplicación (pero sí el diseño del código), aunque sí suelen estar fusionadas en el desarrollo de pequeñas aplicaciones.

Paradigma de Programación Orientado a Objetos (OO): Es el paradigma de programación actualmente más usado. El núcleo central de este paradigma es la unión de datos y procesamiento en una entidad llamada "objeto", relacionable a su vez con otras entidades "objeto". Tradicionalmente datos y procesamiento se han separado en áreas diferente del diseño y la implementación de software. Esto provocó que grandes desarrollos tuvieran problemas de fiabilidad, mantenimiento, adaptación a los cambios y escalabilidad. Con la orientación a objetos y características como el encapsulado, polimorfismo o la herencia se permitió un avance significativo en el desarrollo de software a cualquier escala de producción.

Metaclases: En el paradigma de OO una metaclase es una clase cuyas instancias son clases.

Este concepto se aplica en el protocolo de especificación funcional de la presente invención con algunas particularidades.

Código de programa: es el conjunto de instrucciones y datos a ser procesados por un computador, escrito en un lenguaje que el computador puede interpretar y ejecutar. El código en computación puede ser binario o código fuente escrito en un lenguaje de nivel superior.

Código procedural: se llama así al código de programa generado en el estilo de programación estructurada. Este estilo está basado en estructurar el código de un programa en componentes, que reciben el nombre de procedimientos, subrutinas o funciones.

Intérprete: En ciencias de la computación, intérprete es un programa informático capaz de analizar y ejecutar otros programas. Los intérpretes se diferencian de los compiladores o de los ensambladores en que mientras estos traducen un programa desde su descripción en un lenguaje de programación al código de máquina del sistema, los intérpretes sólo realizan la traducción a medida que sea necesaria, típicamente, instrucción por instrucción, y normalmente no guardan el resultado de dicha traducción.

Compilador: Un compilador es un programa informático que traduce un programa escrito en un lenguaje de programación a lenguaje de máquina. Este proceso de traducción se conoce como compilación.

Sistema: en el presente invento se debe entender como un conjunto de elementos electrónicos u opto-electrónicos que interactúan entre sí para exponer en un dispositivo visual, aplicaciones tipo software a partir de especificaciones de diseño.

Componente de UI: son porciones de código (HTML u otro) que se utilizan para dar forma visual a la exposición de información en un dispositivo de tipo monitor o similar. A estos componentes se los conoce como sets de componentes de terceros y son utilizados en la industria del software como complementos en el desarrollo de aplicaciones de software.

Breve descripción del invento

El presente invento divulga un sistema y un método que a partir de la entrada de estructuras lógicas de información en un dispositivo electrónico compuesto por memoria y procesador, produce de manera automática salidas en dispositivos visuales, que pueden ser operados para crear información de procesos de negocio, reemplazando a las aplicaciones de software que normalmente son desarrolladas mediante la programación tradicional conocida en la industria del software.

La invención está definida por las reivindicaciones independientes adjuntas. Las reivindicaciones dependientes definen modalidades preferidas.

Breve descripción de las figuras

La FIG. 1. m

La FIG. 1A. muestra el protocolo de especificación funcional PEF.

La FIG. 1B. muestra el protocolo de especificación visual PEV.

La FIG. 1C. muestra la estructura lógica de la memoria de base de datos Modelos MF.

La FIG. 1D. muestra la estructura lógica de la memoria de base de datos Modelos MV.

La FIG. 1E. muestra la estructura lógica de la memoria de base de datos Objetos.

La FIG. 2. m íuestra las etapas del método del presente invento.

La FIG. 2A. muestra el detalle de subetapas de la Etapa A.

La FIG. 2B. muestra el detalle de subetapas de la Etapa B.

La FIG. 2B1. muestra un ejemplo de identificación de componentes funcionales y tipos OO.

La FIG. 2C. muestra el detalle de subetapas de la Etapa C.

La FIG. 2C1 muestra un ejemplo de aplicación del protocolo PEF sobre un diagrama de clases

La FIG. 2C2 muestra un ejemplo de aplicación del protocolo PEV sobre un diagrama de pantallas

La FIG. 2D. muestra el detalle de subetapas de la Etapa D

La FIG. 3A. muestra una modalidad adicional de las etapas del método del presente invento.

La FIG. 3B. muestra una modalidad adicional de las etapas del método del presente invento.

Descripción detallada de la invención

El presente invento corresponde a un sistema y método implementado por computador que permiten almacenar modelos de clases, que representan el diseño detallado de una aplicación de software en una memoria de base de datos, y exponen las aplicaciones de tipo software resultantes, a través de un proceso de instanciación de dichos modelos. Como se describe en la Figura 2, el proceso comienza con el almacenamiento de los diseños de software en la memoria de base de datos, y luego identifica los componentes de dicho diseño, utilizando las definiciones de protocolos pre-cargados en el sistema para resolver la instanciación de los modelos, que finalmente constituyen la aplicación tipo software. En el presente invento, un modelo es la representación de un componente de diseño funcional o visual, materializada en una memoria de base de datos.

Para ejecutar el método, se utiliza un sistema como el descripto en la Figura 1, para ingresar los diseños de clases y pantallas en un Dispositivo de Entrada/Salida 120. Los diseños ingresados se transfieren a la memoria general para luego ser procesados por el Procesador 150. El procesador se configura para validar, compaginar e instanciar los modelos existentes en las memorias de Base de Datos 134 y 135. Los resultados de cada función de procesamiento se exponen a pantallas en un Dispositivo de Entrada/Salida 120.

A continuación, se describen los componentes del sistema 100 de la Figura 1:

1. Dispositivo de Entrada/Salida 120: es el dispositivo mediante el cual se ingresan los diseños de software.

Permite a un procesador presentar en medios de visualización (pantallas, proyectores, televisores, impresoras, monitores, dispositivos móviles, entre otros) estructuras donde el usuario puede ingresar los diseños de clases y de pantallas (como los que se muestran en la Figura 2B), y visualizar las aplicaciones de tipo software resultantes, utilizando las siguientes configuraciones:

a. Interfaz de CDF 121: es una estructura visual que permite al usuario ingresar los componentes de diseño funcional de una aplicación de software a partir de un diagrama de clases, los cuales se almacenan en la Memoria de Base de Datos 130, en la configuración lógica Modelos MF 135. b. Interfaz de CDV 122: es una estructura visual que permite al usuario cargar los componentes de diseño visual de una aplicación de software a partir de un diagrama de pantallas asociado a un diagrama de clases, que serán almacenados en la Memoria de Base de Datos 130, en la configuración lógica Modelos MV 134.

c. Interfaz de Aplicación 123: esta interfaz presenta al usuario las estructuras visuales de la aplicación de software resultante, una vez que el Procesador 150 instanció los modelos funcionales y visuales disponibles en la Memoria de Base de Datos 130.

2. CPU 110: es el dispositivo de procesamiento del sistema 100. Este dispositivo está estructurado para realizar las funciones de validación de los modelos funcionales y visuales contra el respectivo protocolo, la compaginación de recursos de UI y la instanciación de la aplicación de tipo software a partir de los pasos previos. Contiene la memoria general que permite el intercambio entre las funciones y el resto de los componentes del sistema.

a. Memoria General 140: es un almacenamiento volátil que se utiliza como dispositivo de intercambio entre el dispositivo de entrada/salida, la memoria de base de datos y el procesador. Realiza las siguientes funciones según su configuración:

i. Matriz de MF 142: es la configuración de la Memoria General que posibilita el procesamiento los Modelos Funcionales residentes en la Memoria de Base de Datos 135 mediante el Procesador 150 configurado como Instanciador de Modelos 153, en correlación con los protocolos almacenados en las memorias de base de datos 131 y 132.

ii. Matriz de MV 143: es la configuración de la Memoria General que posibilita el procesamiento los Modelos Visuales residentes en la Memoria de Base de Datos 134 mediante el Procesador 150 configurado como Instanciador de Modelos 153, alineados con los protocolos almacenados en las memorias de base de datos 131 y 132.

b. Procesador 150: es el dispositivo en el cual se llevan a cabo las tareas de procesamiento e intercambio. Realiza las siguientes funciones según su configuración:

i. Validador de Modelos 151: es la configuración del Procesador que se encarga principalmente de validar los modelos funcionales ingresados por el usuario contra los protocolos residentes en las memorias de base de datos 131 y 132, para una vez validados almacenarlos en las memorias de base de datos 134 y 135 respectivamente.

ii. Compaginador de UI 152: es la configuración del Procesador que se encarga principalmente de compaginar los recursos UI residentes en la memoria de base de datos 133 con los modelos visuales almacenados en la memoria de base de datos 130, previo al proceso de instanciación.

iii. Instanciador de Modelos 153: es la configuración del Procesador que se encarga principalmente de instanciar los modelos funcionales y modelos visuales ya compaginados con los recursos de UI, residentes en las configuraciones lógicas de la memoria general 142 y 143, para exponer automáticamente la aplicación tipo software resultante en la Interfaz de Aplicación 123.

3. Memoria de Base de Datos 130: es una memoria permanente que alberga los datos cargados por el usuario y generados por el Procesador 150 en sus diferentes configuraciones. Esta memoria contiene dos configuraciones de almacenamiento, una configuración estática y una configuración dinámica. La configuración estática almacena aquellos datos fijos necesarios que se cargan por única vez para el procesamiento que no son propios de “el caso”. La configuración dinámica almacena los datos propios de “el caso” que se cargan por cada caso.

a. Memoria Estática:

i. PEF 131: configuración de la Memoria de Base de Datos 130 que contiene las reglas que utiliza el Procesador 150 para validar e instanciar los modelos funcionales, definidas y cargadas en esta memoria a partir del Protocolo de Especificación Visual (PEV).

ii. PEV 132: configuración de la Memoria de Base de Datos 130 que contiene las reglas que utiliza el Procesador 150 para validar e instanciar los modelos funcionales, definidas y cargadas en esta memoria a partir del Protocolo de Especificación Funcional (PEF). iii. Recursos UI 133: configuración de la Memoria de Base de Datos 130 que contiene componentes de software que permiten al Procesador 150 exponer de los modelos visuales en la Interfaz de Aplicación 123, mediante pantallas controladas por el usuario. b. Memoria Dinámica:

i. Modelos MV 134: configuración de la Memoria de Base de Datos 130 que contiene los modelos funcionales cargados por el usuario mediante la Interfaz de CDV 122 y validados por el Procesador 150 contra el protocolo de Especificación Visual (PEV). Esta memoria, consta de las siguientes estructuras lógicas asociadas a los conceptos del Protocolo de Especificación Visual que se muestra en la Figura 1B:

1. Configuraciones asociadas al concepto ActionLink

a. Estructura lógica RenderAction

b. Estructura lógica RenderActionEditor

c. Estructura lógica RenderAttributeBaseAction d. Estructura lógica RenderBaseViewAction

2. Configuraciones asociadas al concepto Application

a. Estructura lógica Application

3. Configuraciones asociadas al concepto AttributeRenderInfo

a. Estructura lógica RenderAttribute

b. Estructura lógica RenderAttributeBase

c. Estructura lógica RenderDiagramView

d. Estructura lógica RenderMapView

e. Estructura lógica RenderNavBarView

f. Estructura lógica RenderObjectReferenceAttribute

g. Estructura lógica RenderPivotView

h. Estructura lógica RenderReportView

i. Estructura lógica RenderWidgetAttribute

4. Configuraciones asociadas al concepto ColumnViewModel

a. Estructura lógica RenderColumn

5. Configuraciones asociadas al concepto Container

a. Estructura lógica RenderContainer

6. Configuraciones asociadas al concepto ListViewModel

a. Estructura lógica RenderFindView

b. Estructura lógica RenderGridAggregateColumn c. Estructura lógica RenderGridAttribute

d. Estructura lógica RenderGridColumn

e. Estructura lógica RenderGridColumnAction

f. Estructura lógica RenderGridView

7. Configuraciones asociadas al concepto Menu

a. Estructura lógica Menu

8. Configuraciones asociadas al concepto MenuGroup

a. Estructura lógica MenuGroup

9. Configuraciones asociadas al concepto TreeViewModel

a. Estructura lógica RenderRelationView

b. Estructura lógica RenderRelationViewAction c. Estructura lógica RenderTreeView

10. Configuraciones asociadas al concepto ViewModel

a. Estructura lógica PopUpEditor

b. Estructura lógica PrintConfiguration

c. Estructura lógica RenderBaseView

d. Estructura lógica RenderBaseViewInheritance ii. Modelos MF 135: configuración de la Memoria de Base de Datos 130 que contiene los modelos funcionales cargados por el usuario mediante la Interfaz de CDF 121 y validados por el Procesador 150 contra el protocolo de Especificación Funcional (PEF). Esta memoria, consta de las siguientes estructuras lógicas asociadas a los conceptos del Protocolo de Especificación Funcional, cuadrante More-Class, que se muestra en la Figura 1A:

1. Configuraciones asociadas al concepto Dominio

a. Estructura lógica Domain

2. Configuraciones asociadas al concepto Formula

a. Estructura lógica Fx

b. Estructura lógica MatchAttribute

c. Estructura lógica MatchFieldStrategy

d. Estructura lógica MatchInfo

e. Estructura lógica MatchValue

f. Estructura lógica MatchValueStrategy

3. Configuraciones asociadas al concepto FxCall Argument

a. Estructura lógica FxCall

4. Configuraciones asociadas al concepto ModelAttribute

a. Estructura lógica MoreClassAttribute

5. Configuraciones asociadas al concepto ModelClass

a. Estructura lógica MoreClass

b. Estructura lógica MoreClassInheritance

6. Configuraciones asociadas al concepto ModelRelationClass

a. Estructura lógica MoreRelationClass

iii. Objetos 136: configuración de la Memoria de Base de Datos 130 que contiene los objetos que el usuario genera, basados en los modelos instanciados a través de la aplicación tipo software, por Procesador 150 configurado como Instanciador de Modelos 153. Esta memoria, consta de las siguientes estructuras lógicas asociadas a los conceptos del Protocolo de Especificación Funcional, cuadrante Object-Class, que se muestra en la Figura 1A:

1. Configuraciones asociadas al concepto AttributeValue

a. Estructura lógica MoreObjectAttributeValue

b. Estructura lógica MoreObjectAttributeValueFileExtended

c. Estructura lógica MoreRelationObjectMoreObjectAttributeRelation 2. Configuraciones asociadas al concepto Object

a. Estructura lógica MoreObject

3. Configuraciones asociadas al concepto RelationObject

a. Estructura lógica MoreRelationObject

La presente invención corresponde al sistema descripto y un método implementado en computador que interpreta y expone aplicaciones tipo software a partir de especificaciones de diseño. Haciendo referencia a la Figura 2, el método de la presente invención comprende las siguientes etapas:

Etapa A. Cargar a través del Dispositivo de Entrada/Salida 120 el Protocolo de especificación funcional (PEF) en la estructura lógica PEF 132 y el Protocolo de especificación visual (PEV) con sus correspondientes recursos UI en las estructuras lógicas PEV 131 y Recursos UI 133 de la Memoria de Base de Datos 130.

Etapa B. A partir de un diseño de clases, identificar y cargar los componentes de diseño funcional detallados en el diagrama de clases a través de la Interfaz CDF 121 y almacenarlos temporalmente en la Memoria General 140, en la estructura lógica Matriz de MF 142. A partir del diseño de pantallas, asociado al diseño de clases, identificar y cargar los componentes de diseño visual detallados a través de la Interfaz CDV 122 y almacenarlos temporalmente en la Memoria General 140, en la estructura lógica Matriz de MV 143.

Etapa C. Validar los modelos funcionales y visuales creados en la Etapa B, utilizando el Procesador 150 en su configuración de Validador de Modelos 151 para crear a partir de cada modelo cargado en la Memoria General 140, un modelo compatible con los protocolos PEF y PEV residentes en la Memoria de Base de Datos 130 almacenados en la Etapa A. Almacenar los modelos funcionales y resultantes, en la Memoria de Base de Datos 130, en sus configuraciones lógicas Modelos MF 134 y Modelos MV 133 respectivamente.

Etapa D. Recuperar de la Memoria de Base de Datos 130 los Modelos Funcionales y los Modelos Visuales creados en la Etapa C, los Recursos UI cargados en la Etapa A y almacenarlos en la Memoria General 140 utilizando el Procesador 150 configurado como Compaginador de UI 152. Compaginar los Recursos UI con los componentes funcionales y visuales almacenados en la Memoria General 140 e instanciar los modelos compaginados y exponer las pantallas de una aplicación tipo software en el Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123, utilizando el Procesador 150 configurado como Instanciador de modelos 153. Recibir a través de la Interfaz de Aplicación 123 las peticiones de los usuarios y almacenar los objetos resultantes de la respuesta del Procesador 150 a la operación de la aplicación, en la Memoria de Base de Datos 140, estructura lógica Objetos 136.

A continuación, se describen en detalle las etapas del proceso:

Etapa A.Cargar los protocolos en la memoria

En esta etapa, como se expone en la Figura 2A, se definen dos normas, llamadas protocolos, que se cargan en la Memoria de Base de Datos 130, por única vez. El Procesador 150 utiliza estos protocolos, en sus diferentes configuraciones, a lo largo del proceso: i) Protocolo de especificación funcional (PEF); y ii) Protocolo de especificación visual (PEV)

Estos protocolos establecen el modo en que el Procesador 150 compaginará los componentes funcionales de un diagrama de diseño de clases de software (OO) y un diagrama de diseño de pantallas, para lograr una aplicación tipo software operativa de manera automática.

En el presente invento, un diagrama de clases con su respectivo diagrama de diseño de pantallas se denomina “el caso”. El diagrama de diseño de clases representa la funcionalidad de la aplicación de software (conformada por un conjunto de componentes funcionales) y el diagrama de pantallas representa la estructura visual (conformada por un conjunto de componentes visuales) que presenta la aplicación tipo software a sus usuarios. A continuación, se describen ambos protocolos:

Subetapa A1. Cargar Protocolo de especificación funcional (PEF)

Este protocolo es la norma que define el comportamiento que el Procesador 150 dará a los componentes funcionales que el usuario cargue a partir de un diagrama de diseño de clases, de ahora en adelante componentes PEF, que determinan la estructuración lógica para la operación del Sistema 100. La Arquitectura que define la funcionalidad de este Protocolo se puede observar en la Figura 1A.

El protocolo PEF define Metaclases que se refieren a clases cuyas instancias son clases, según OO. En este protocolo, las clases que son instancias de una Metaclase se conocen como Modelos (cuadrante Instance-Class de la Figura 1A).

Con el uso de este protocolo PEF, la funcionalidad de la aplicación tipo software resultante se logra instanciando el significado del lenguaje implícito en un diseño de clases, por un lado y la lógica matemática por otro lado. En la parte semántica de “el caso”, los métodos (OO) identificados en el diagrama de clases, a través del protocolo se convierten en clases, y en la matemática los métodos (OO) que denotan una funcionalidad matemática se convierten en fórmulas. En el protocolo de Especificación Funcional PEF, como se observa en la Figura 1A cuadrante Model-Class, existen tres componentes para resolver la semántica (ModelClass, ModelRelationClass y ModelAttribute) y cuatro componentes para resolver la matemática (Dominio, Dominio externo, Fórmula y FxCall).

El protocolo también define clases de Objetos (cuadrante Object-Class de la Figura 1A). Estas clases de objetos ModelObject y ModelAttributeValue son los componentes que utiliza el sistema 100 para almacenar las instancias de los Modelos del cuadrante Instance-Object.

Los Componentes PEF son los pertenecientes a los cuadrantes Model-Class y Object-Class. Dentro del cuadrante Model-Class, se encuentran: ModelClass, ModelRelationClass, ModelAttribute, Fórmula, Dominio y FxCall. Son un conjunto de Metaclases que dan origen a los Modelos funcionales que se almacenan en la Memoria de Base de Datos 130, en la estructura lógica Modelos MF 135. Dentro del cuadrante Object-Class se encuentran: ModelObject y ModelAttributeValue. Son un conjunto de Clases que dan origen a los Objetos del Sistema que se almacenan en la Memoria de Base de Datos 130, estructura lógica Objetos 136. Estos componentes PEF se describen a continuación: i. Metaclases que dan Origen a los Modelos funcionales de la aplicación de software (cuadrante Model-Class) ■ ModelClass

Es un componente metaclase porque sus instancias son modelos. Este componente modela estructuras de diseño que en el diagrama de diseño ^{O o} son clases. Un ModelClass puede ser resultado de otro ModelClass.

Ejemplo: Podemos crear una metaclase Entidad Humana (ModelClass), otra metaclase Persona (ModelClass que hereda del ModelClass Entidad Humana). Las instancias de Persona pueden ser Personas Físicas o Personas Jurídicas. Tanto Persona Física como Persona Jurídica son Modelos que constituyen instancias de la Metaclase Persona.

■ ModelRelationClass

Es un componente metaclase que hereda de ModelClass. La funcionalidad que extiende al ModelClass, da a esta metaclase la capacidad de relacionar dos ModelClass, que puede ser de dos tipos: asociación o composición, según se define en OO.

Ejemplo: Si tomamos el ModelClass Persona Física y el ModelClass Persona Jurídica, podríamos pensar que una instancia de Persona Física (Juan Pérez) puede ser empleado de una instancia de Persona Jurídica (Empresa Google). Este caso, existe un ModelRelationClass que se llama “se relaciona con” que vincula al ModelClass Persona consigo mismo a nivel de metamodelo. Esta relación podría utilizarse para representar la relación de empleado que existe entre persona Física y Persona Jurídica, o también podría especializar el ModelClass Persona en ModelClass Persona Física y Persona Jurídica, para luego crear la especialidad de ModelRelationClass “es empleado de” que heredaría del ModelRelationClass “se relaciona con”.

■ ModelAttribute

Es un componente metaclase que compone a ModelClass. Un ModelClass tiene una lista de ModelAttributes. ModelAttribute es la representación de los atributos que contendrán los modelos creados como instancias de ModelClass.

Un ModelAttribute define, entre otras cosas, el tipo de dato del atributo al cual está dando origen.

El protocolo define tres clasificaciones de tipos de dato para ModelAttribute.

o ModelAttribute Simple: los tipos simples son aquellos cuya instancia de valor no involucra instancias de ModelObject. Ejemplo: dato número, dato texto, dato imagen.

o ModelAttribute RelationObject: son atributos que existen en un ModelClass producto de que éste participe en un ModelRelationClass. Este tipo de atributo en su instancia de valor, dependiendo de la relación, puede tener una o más instancias de objetos de relación. Esto determina la cardinalidad de la relación. Ejemplo: Si tenemos un ModelRelationClass entre el ModelClass “Persona” y el ModelClass “Artículo”, existe en el ModelClass Persona un ModelAttribute de tipo RelationObject que tendrá como instancia las Personas que se relacionen con Artículo. Y en la inversa, el ModelClass Persona tiene un ModelAttribute de tipo RelationObject que tendrá como instancias a los artículos que se relacionen con Persona.

o ModelAttribute ObjectReference: este tipo de datos es similar al anterior, solo que no surge producto de que el ModelClass al que pertenece participa en una relación. El atributo propiamente dicho es quien conoce la naturaleza de los objetos que oportunamente compondrán la instancia de valor para el mismo. Ejemplo: al crear un ModelAttribute como parte de un ModelClass lo declaro ObjectReference.

■ Fórmula

Una fórmula es un modelo independiente que cuenta con una expresión y un conjunto de parámetros para recibir información del Modelo que la invoca. La fórmula, cuando se ejecuta, siempre retorna un valor al Modelo que la llama. El valor resultante puede ser una única instancia o múltiples instancias como parte de arreglos y arreglos multidimensionales.

El protocolo de especificación funcional define al componente fórmula que se utiliza para resolver aquella lógica que funcionalmente requiere de la ejecución de operaciones matemáticas que utilizan como argumentos instancias de modelos. La fórmula provee todos los operadores matemáticos para operaciones algebraicas, matriciales o de conjuntos y permite definir la expresión haciendo uso de los argumentos existentes como instancias de modelos del cuadrante Model-Instance de la Figura 1A. La funcionalidad que implica una resolución matemática se implementa mediante una Metaclase Fórmula. A diferencia del diseño tradicional de software, donde este tipo de funcionalidades se implementa como un método en una clase del modelo OO. Ejemplo: una fórmula que calcula el valor total de una venta, cuenta con la expresión algebraica que suma los importes vendidos y devuelve un único valor resultante en una instancia de ModelAttribute, siendo los importes vendidos una colección de instancias de ModelAtrribute.

■ Dominio

El dominio es un componente que declara condiciones que permiten seleccionar un subconjunto de instancias de modelos (operaciones entre conjuntos).

Una instancia de modelo se puede encontrar en la memoria de Base de Datos 130, en la estructura lógica Objetos 136, ya validada y estructurada por el Procesador 150 en base al protocolo PEF, o en una memoria externa no estructurada en base al protocolo. En consecuencia, los Dominios se clasifican de la siguiente manera:

Dominios Internos

Son los dominios que se resuelven sobre la memoria de Base de Datos 130, en la estructura lógica Objetos 136 obteniendo colecciones de instancias que luego podrán ser procesadas por otros modelos a través de fórmulas. Ejemplo: si existe un ModelClass Cliente, para recuperar sus instancias almacenadas en la base de datos se debe utilizar un Dominio Interno, donde solo se invoca el nombre del ModelClass y la condición que deben cumplir las instancias a recuperar.

Dominios Externos

Son los dominios que se resuelven sobre una memoria NO estructurada en base al protocolo PEF (datos en archivos externos). En estos casos el componente dominio externo accede a las instancias de objetos y el Procesador 150 las estructura en base al protocolo para que formen parte del espacio accesible por dominios internos. Ejemplo: Si existe un archivo externo que tiene 3 columnas de datos: nombre, edad y empresa, para recuperarlos se debe crear un dominio externo donde se indica que dichos datos son datos de un cliente y la correspondencia de columnas con los ModelAttribute (columna Nombre: ModelAttribute Nombre, columna edad: ModelAttribute edad, columna empresa: ModelAttribute Empresa). El ModelAttribute empresa es de tipo RelationObject donde Cliente se relaciona con empresa.

■ FxCall

Este componente es el responsable de asociar cualquier instancia de ModelAttribute con las instancias de Fórmula, cuando el valor de la instancia de ModelAttribute proviene de una Fórmula. Es un modelo que resuelve la evaluación de una expresión de fórmula y retorna un resultado al modelo que la invoca, enviando al Procesador 150 los operadores matemáticos y los argumentos que serán operados. FxCall hidrata los valores de argumentos obtenidos de las instancias, para que la Fórmula invocada solicite resolución al Procesador 150.

ii. Clases que dan Origen a los Objetos de la aplicación de software (cuadrante Object-Class)

■ ModelObject

Las instancias de las clases instanciadas a partir de ModelClass, se conocen como ModelObjects. ModelObject es la clase concreta que materializa las instancias de objetos modelados con ModelClass. Ejemplo: El modelo Artículo que es instancia de ModelClass posee una instancia concreta de ModelObject “leche”. Este objeto es a su vez la materialización de una instancia de ModelObject.

■ ModelAttributeValue

Las instancias de los modelos modelados con ModelAttribute se conocen como ModelAttributeValues. ModelAttributeValue es la clase concreta cuyas instancias representan el valor de los atributos de una instancia de ModelObject. Ejemplo: El modelo Artículo que es instancia de ModelClass posee una instancia concreta de ModelObject “leche”, cuyo ModelAttributeValue para el ModelAttribute nombre es “leche”.

Subetapa A2. Cargar Protocolo de especificación visual (PEV)

Este protocolo define, como se muestra en la Figura 1B, el comportamiento que el Procesador 150 dará a los componentes visuales que el usuario cargue a partir de un diagrama de diseño de pantallas, de ahora en adelante componentes PEV. Estos componentes determinan la estructuración visual que se presentará en el Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123 para la operación del Sistema 100. La Arquitectura que define la presentación visual de este Protocolo se puede observar en la Figura 1B.

El protocolo de Especificación Visual PEV define el modo en que se vinculan los componentes PEF y los componentes PEV. Un componente PEV expone la funcionalidad de uno o más componentes PEF a través del Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123.

Esta definición del protocolo determina que es posible producir salidas en dispositivos visuales, que pueden ser operados para crear información de procesos de negocio sin hacer diseño de arquitectura de capas particular para cada caso, porque la arquitectura está embebida en los componentes PEF.

En otra modalidad del presente invento se crean componentes PEV no vinculados a componentes PEF, por ejemplo: un modelo visual que contiene un link a una página web.

Los Componentes PEV son: Application, ActionLink, AbmViewModel, ListViewModel, TreeViewModel, ReportViewModel.

■ Application

El componente Application estructura visualmente una aplicación de software.

El protocolo define el componente Application como un Modelo para especificar una aplicación. Una aplicación define como aspecto más importante el Menu mediante el cual el usuario tendrá acceso a la funcionalidad expuesta. Un Menu es una colección de modelos MenuGroup y modelos MenuItem arborizada, donde los MenuGroup pueden contener a su vez otros MenuGroup o MenuItem. Los MenuItem son los que vinculan la acción que se llevará a cabo cuando el usuario haga click sobre el mismo. Un ítem tiene asociado alguno de los siguientes modelos de visualización (ViewModel): AbmViewModel, ListViewModel, TreeViewModel. Cuando el usuario ejecuta un MenuItem, el Procesador 150 del sistema 100 recibe dicha petición a través de la Interfaz de Aplicación 123 y devuelve una estructura en la misma Interfaz que permite al usuario ejecutar funcionalidad del componente PEF invocado por el componente PEV asociado al MenuItem.

■ ViewModel

El componente ViewModel es el que permite exponer instancias de ModelObject, en dispositivos visuales. Un componente ViewModel está compuesto por componentes ActionLink que permiten al ViewModel ejecutar acciones según el modelo ModelClass del cual es instancia y la clase de ViewModel a la que hace referencia.

Un componente PEV define un layout (estructura de disposición visual o plantilla) que será expuesta en el Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123, a partir de ViewModel y sus características.

Para exponer instancias de modelos, existen tres clases de ViewModel: AbmViewModel, ListViewModel y TreeViewModel con diferentes características y especificaciones de layout.

(1) AbmViewModel

El protocolo define el componente AbmViewModel como un Modelo para especificar el renderizado de una pantalla que permite dar de Alta, Baja o Modificar un Objeto ModelObject. El renderizado de una pantalla, expone todos o algunos de los ModelAttributeValues de una instancia de ModelObject, según el modelo ModelClass correspondiente.

El componente AbmViewModel, está compuesto por componentes ActionLink por ser un ViewModel_y extiende su funcionalidad a través de los componentes ControlViewType y las características especiales del AbmViewModel.

Los componentes ControlViewType exponen los ModelAttributeValues según el tipo de dato del atributo. En una modalidad del invento se expone la siguiente lista de tipos de atributos:

- TextEditor: expone ModelAttributeValues de tipo texto.

- NumericEditor: expone ModelAttributeValues de tipo número.

- DateTimeEditor: expone ModelAttributeValues de tipo fecha.

- ObjectReferenceComboEditor: expone ModelAttributeValues de tipo selector de ModelObjects.

- ObjectReferenceListEditor: expone ModelAttributeValues de tipo selector de ModelObjects.

Los componentes ActionLink que componen al AbmViewModel son:

- Guardar: guarda la instancia de ModelObject en la base de datos Transaccional.

- Cancelar: cierra la estructura visual expuesta por el AbmViewModel y descarta los cambios realizados por el usuario en la instancia de ModelObject.

- Guardar y Nuevo: guarda la instancia de ModelObject y crea una nueva instancia para que el usuario complete los valores de sus atributos, exponiéndola en la estructura visual del AbmViewModel.

- Imprimir: Imprime los valores de los atributos de la instancia que se está modificando.

- En alguna modalidad de la invención se agregan acciones que invocan a otros ViewModel.

Características especiales de un AbmViewModel:

• AttributeRenderInfo: este modelo se utiliza para indicar las particularidades de renderizado de un control que representa el valor de determinado atributo de una instancia de ModelObject.

• ControlTemplate: selector de control para renderizar un ModelAttribute. Dependiendo del tipo de dato del atributo, éste podrá ser representado de diversas formas acordes con la naturaleza del tipo. ControlTemplate es el concepto que permite indicar con cuál de todas esas posibles opciones será efectivamente renderizado el atributo.

• Container: dentro de AbmViewModel existe una estructura de contenedores a los efectos de poder organizar los controles en dispositivo visual. Se conoce como controles a cada uno de los componentes que expone visualmente un atributo. Esta estructura de contenedores es arborizada, es decir, puede un contenedor incluir a otros.

• ColumnViewModel: dentro de los contenedores, los controles se organizan en columnas y éstas internamente tienen un orden para los controles que contienen.

(2) ListViewModel

El protocolo define el componente ListViewModel como un Modelo para especificar el renderizado de una pantalla que permite listar colecciones de instancias de ModelObject. El renderizado de esta pantalla, expone los ModelAttributeValues que dicho ModelObject posee según el modelo ModelClass del cual es instancia, para una colección de instancias del ModelObject que se muestran en una tabla donde cada ModelAttributeValue ocupa una celda, donde la fila corresponde a la instancia y la columna al ModelAttribute.

El componente ListViewModel, está compuesto por componentes ActionLink por ser un ViewModel_y extiende su funcionalidad a través de los componentes SearchViewModel, ColumnViewModel, ObjectReferenceListGridEditor y las características especiales del ListViewModel.

Los componentes ActionLink que componen al ListViewModel son: Nuevo; Eliminar; Editar; Imprimir; Ejecutar Fórmula

Adicionalmente, para listas de RelationObjects surgen las siguientes acciones:

• NuevoMDestino: invoca la creación de un nuevo ModelObject del modelo relacionado como destino de la relación.

• NuevoMDestinoYAsociar: invoca la creación de un nuevo ModelObject del modelo relacionado como destino de la relación, y materializa la relación con el ModelObject propietario del atributo de relación.

• EliminarMDestino: en una instancia de relación, elimina el ModelObject relacionado, como así también la instancia de relación.

• EditarMdestino: invoca la pantalla de edición del ModelObject relacionado.

Características especiales de un ListViewModel:

• Herarchical view: se refiere a la representación con estructura jerárquica del grafo de objetos relacionados mediante modelos ModelRelationClass.

• InLine Edition: soporte para la modificación de los atributos de un objeto sobre la misma línea de la lista.

(3) TreeViewModel

El protocolo define el componente TreeViewModel como un Modelo para especificar el renderizado de un árbol de ModelObjects relacionados mediante RelationObjects. El renderizado de esta pantalla, consiste en la exposición de todos o algunos de los ModelAttributeValues que dicho RelationObjects invoca a partir de los ModelClass que relaciona.

Un nodo de un árbol, representado en un componente TreeNodeModel, representa entonces una instancia de ModelObject y una instancia de RelationObject, que es la relación que existe entre el nodo en cuestión y su nodo padre. Por lo tanto, los nodos del primer nivel del árbol no tendrán representación de ninguna instancia de RelationObject ya que no se relacionan con ningún nodo padre.

El componente TreeViewModel, está compuesto componentes ActionLink por ser un ViewModel y extiende su funcionalidad a través de las características especiales del TreeViewModel.

Los componentes ActionLink que componen al TreeViewModel son:

- Nuevo: crea una nueva instancia de RelationObject basada en el ModelRelationClass correspondiente según el modelo de visualización de árbol para el nodo donde se está invocando la acción.

- Eliminar: Elimina la instancia de RelationObject que vincula al nodo actual con su nodo padre.

- Editar: edita la instancia de RelationObject que vincula al nodo actual con su nodo padre.

- NuevoMDestino: invoca la creación de una nueva instancia de ModelObject que se corresponde con el destino de la relación para el modelo de ModelRelationClass correspondiente según el modelo de visualización de árbol para el nodo donde se está invocando la acción.

- NuevoMDestinoYAsociar: ídem NuevoMDestino, solo que luego crea la instancia de RelationObject para vincular el nuevo ModelObject con el ModelObject representado por el nodo sobre el que se invocó la acción. - EliminarMDestino: elimina la instancia de ModelObject representada por el nodo actual.

- EditarMdestino: edita la instancia de ModelObject representada por el nodo actual.

Características especiales de un TreeViewModel:

• LoadOnDemand: indica si el árbol debe ir descubriendo y cargando sus nodos a medida que el usuario interactúa expandiendo el árbol.

• ShowExpanded: indica que, al mostrarse el árbol, éste debe visualizarse con todos sus nodos expandidos. • EditOnClick: indica que debe invocarse la edición del objeto representado por un nodo cuando el usuario hace click sobre el mismo.

(4) ActionLink

Los componentes ActionLink definen las acciones que están disponibles en el ViewModel para ejecutar sobre las instancias de ModelObject.

Cada subclase de ViewModel posee una lista de ActionLinks distinta, en relación con la funcionalidad que expone en el dispositivo visual.

(5) ReportViewModel

Un ReportViewModel contiene la especificación necesaria para que el Procesador 150 configurado como Instanciador de Modelos 153, pueda interactuar con cualquier servicio de entrega de reportes, como por ejemplo Reporting Services.

Esto es posible ya que el repositorio de instancias de ModelObject es compatible con los métodos de consulta q estos servicios implementan, de forma que haciendo uso de los componentes de visualización que acompañan a estas tecnologías, se pueden generar e integrar reportes de una forma simple y con todas las características de reporting necesarias.

Subetapa A3. Cargar recursos de UI

El Protocolo de Especificación Visual PEV está diseñado de forma que el Procesador 150 pueda compaginar los componentes visuales con recursos de UI. El objetivo de esta compaginación es que el Procesador pueda rápidamente poner estos componentes a disposición para el modelado de la interfaz de Usuario. Esto se logra mediante el concepto de ControlViewType del Protocolo PEV cargado en la Subetapa A2, el cual se vincula directamente con un recurso de UI y permite desde un ViewModel indicar con qué recurso UI será presentada determinada porción de la interfaz de usuario en el Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123.

Los Recursos UI son porciones parciales declaradas en algún lenguaje de UI (ejemplo, HTML5) y cuya apariencia puede ajustarse con hojas de estilo en cascada (css). Estos recursos, se almacenan en la Memoria de Base de Datos 130, estructura lógica Recursos UI 133. Luego, cuando el Procesador 150, configurado como Compaginador de UI 152 ejecuta sus funciones, vincula estos Recursos UI con una instancia de la estructura lógica ControlViewType, residente en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134, dejando estos modelos conjugados disponibles para ser utilizados en la exposición de la aplicación tipo software.

Etapa B. Identificar y Almacenar componentes de Diseño

El diseño se describe porque resulta necesario como entrada al proceso abarcado por el invento.

Los documentos de diseño, como se muestran en la Figura 2B, se refieren particularmente a dos tipos de diagramas conocidos para definir la funcionalidad y las estructuras visuales que definen una aplicación de tipo software:

- los diagramas de clases (220) que representan el diseño funcional. Estos diseños serán utilizados para la creación de los modelos funcionales.

- los diagramas de pantallas (221) que representan el diseño visual requerido. Estos diseños serán utilizados para la creación de los modelos visuales.

En esta etapa se parte del diseño funcional y el diseño de pantallas, y se llevan a cabo las siguientes subetapas:

Subetapa B1. Identificar los componentes del diseño funcional

A partir de un diseño de clases (220) que representa la lógica que se desea resolver, listar las clases que figuran en el diagrama. A partir del diagrama de clases identificar sus componentes teniendo en cuenta que el tipo de componente se define en base al paradigma OO y hacerle corresponder un componente ModelClass, según establece el protocolo PEF cargado en la Subetapa A1. Identificar el nombre de cada componente identificado como se muestra en el Ejemplo de la Figura 2B1, y determinar el componente PEF que le corresponde, tal como se puede observar en el ejemplo de la Figura 2C1, así:

- Si el diagrama expone una clase, identificar un componente funcional tipo OO Clase y determinar que le corresponde un componente PEF ModelClass.

- Si el diagrama expone dentro de una clase un atributo, identificar un componente funcional tipo OO Atributo y determinar que le corresponde un componente PEF ModelAttribute.

- Si el diagrama expone una relación, identificar un componente funcional tipo OO, Relación y determinar que le corresponde un componente PEF ModelRelationClass.

- Si el diagrama expone un método dentro de una clase, identificar un componente funcional Tipo OO Método y determinar:

o Si el método refiere a un cálculo matemático algebraico, que le corresponde un componente PEF Fórmula.

o Si el método refiere a una función matemática equivalente a la lógica de conjuntos, que le corresponde un componente PEF Dominio, pudiendo ser externo en caso de referir a datos externos al sistema.

- Si el diagrama expone una herencia, identificar un componente funcional tipo OO, herencia y determinar que le corresponde una relación de herencia entre dos ModelClass, como lo define el protocolo PEF en el cuadrante Model-Class.

El usuario, a través del Dispositivo de Entrada/Salida 120, Interfaz de CD 121, carga los componentes PEF identificados y el Procesador 150, configurado como Validador de Modelos 151, los almacena en la Memoria General 140, estructura lógica Matriz de MF 142.

Subetapa B2. Identificar los componentes del diseño visual

Tomando como referencia el diseño de pantallas que representa el modo en que se desea ver e interactuar con la aplicación tipo software que construirá automáticamente el Procesador 150 configurado como Instanciador de Modelos 153, se describen a continuación los pasos a ejecutar para determinar los modelos visuales que se deben crear para exponer la aplicación tipo software para “el caso”.

A partir de la lista de componentes PEF, se aplica el protocolo de Especificación Visual cargado en la Etapa A, para identificar los conceptos de tipo ModelClass y crear los modelos visuales que define el protocolo PEV (Application, AbmViewModel, ListViewModel, TreeViewModel), así:

a. Por cada ModelClass, se determina que se deberán crear los siguientes ViewModel:

AbmViewModel, ListViewModel.

b. Por cada ModelRelationClass, se determina que se deberán crear los siguientes ViewModel:

ListViewModel, TreeViewModel

c. Para exponer la totalidad de los componentes PEF se determina que se deberá crear un Modelo Application, un modelo MenuViewModel,un modelo MenuGroup y un modelo ItemGroup por cada ViewModel creado en los pasos previos.

En otra modalidad del presente invento el sistema 100 permite editar los modelos visuales creados para lograr la mayor similitud con los diseños de pantallas correspondientes a “el caso” disponibles como input del proceso.

El usuario, a través del Dispositivo de Entrada/Salida 120, Interfaz de CDV 122, carga los componentes PEV identificados y el Procesador 150, configurado como Validador de Modelos 151 los almacena en la Memoria General 140, estructura lógica Matriz de MV 143.

Etapa B'. Generar CF y CD a partir de lenguaje natural.

En una modalidad de la invención, esta Etapa B' es sustitivva de la Etapa B, como se muestra en la Figura 3A.

En esta etapa, el usuario Genera CF y CD a partir de lenguaje natural, por ejemplo, utilizando como se describe en la solicitud de patente No. 15/141,748, titulada “PROCESO Y SISTEMA PARA GENERAR DOCUMENTOS DE ARQUITECTURA FUNCIONAL Y DOCUMENTOS DE ESPECIFICACIÓN DE ANÁLISIS Y DE DISEÑO DE SOFTWARE DE MANERA AUTOMÁTICA A PARTIR DE LENGUAJE NATURAL”, incorporada como referencia en su totalidad.

En esta modalidad, se ejecutan las siguientes subetapas:

Subetapa B'1. Obtener componentes funcionales

El Procesador 150 se conecta a la Memoria de Base de Datos, estructura lógica 172 identificada en la solicitud de patente No. 15/141,748, obtiene los componentes funcionales de “el caso” y los almacena en la Matriz de MF 142.

Subetapa B'2. Identificar componentes visuales

El Procesador 150, recorre la lista de componentes funcionales obtenidos en la Subetapa B'1 y aplica el Protocolo de Especificación Visual PEV definido en la Subetapa A2. Obtiene de cada componente funcional uno o más componentes visuales, tal como se muestra en la Fig 2C2 y los almacena en la Matriz de MV 143.

Etapa C.Crear modelos funcionales y visuales

En esta etapa, el Procesador 150 toma de la Memoria General 140, estructura lógica Matriz de MF 142 los componentes PEF creados en la Subetapa B1 y ejecuta las siguientes subetapas:

Subetapa C1. Identificar los componentes PEF y crear los Modelos Funcionales

En esta subetapa, como se muestra en la Figura 2C, el Procesador 150 identifica los componentes PEF disponibles en la Memoria General 140, creados en la Subetapa B1 y realiza la especificación de conceptos PEF según el protocolo cargado en la Subetapa A1. Luego crea los Modelos Funcionales, los cuales especifican la funcionalidad que utilizará el Procesador 150 para instanciar la aplicación tipo software para “el caso”. El Procesador 150 lleva a cabo los siguientes pasos:

1. Recorre la lista para identificar qué Concepto PEF corresponde crear en base al Protocolo de Especificación para cada Tipo OO de los componentes del diseño según se determinó en la Subetapa B1.

2. Para aquellos componentes del diseño cuyo Concepto PEF asociado es una fórmula, crea los siguientes componentes PEF adicionales:

a. Crea un Componente PEF de tipo FxCall y lo vincula con el ModelAttribute que hace uso de la Fórmula dentro de la misma Clase.

b. Si la lógica de la fórmula implica el uso de atributos que no pertenecen al componente de diseño dueño del método, crea un Concepto PEF de tipo Dominio para localizar los datos que actuarán como argumentos de la Fórmula.

El Procesador 150 almacena los Modelos Funcionales creados en la Memoria de Base de Datos 130, estructura lógica Modelos MF 135.

La conversión del diseño de clases input del proceso, al aplicar el protocolo de especificación funcional PEF, derivan en el conjunto de modelos que luego son interpretados por el Procesador 150, configurado como Instanciador de Modelos 153.

Subetapa C2. Identificar los componentes PEV y crear los Modelos Visuales

En esta subetapa, como se muestra en la Figura 2C2, el Procesador 150 identifica los componentes PEV disponibles en la Memoria General 140, creados en la Subetapa B2 y realiza la especificación de conceptos PEV según el protocolo cargado en la Subetapa A2. Luego crea los Modelos Visuales, los cuales especifican la funcionalidad que utilizará el Procesador 150 para exponer la aplicación tipo software para “el caso” presentando estructuras de información en el Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123. El Procesador 150 lleva a cabo los siguientes pasos:

1. Recorre la lista de Concepto PEF creados en la Subetapa B2 en base a lo determinado en el protocolo de especificación visual (PEV).

2. Para cada Concepto PEV identificado en el paso anterior, crea los modelos Visuales según se establece en el protocolo PEV.

3. Crear un modelo visual de tipo Aplication con un nombre representativo de “el caso”.

4. Crear un modelo visual de tipo Menú con un nombre representativo y un Grupo de Menú por cada uno de los componentes de diseño, asignando al grupo el nombre del componente de diseño.

5. Crear dentro de cada grupo de Menú, dos Menú ítem, uno para cada modelo visual creado por componente de diseño. Ejemplo: para el componente clase 1, crear un grupo de Menú llamado “Clase” y luego dos Menú Item: uno llamado “ABM

Clase1” y otro llamado “List Clase 1”. Asociar a cada Menu Item el modelo visual correspondiente con su nombre.

Los modelos visuales se editan sin modificar el vínculo entre el modelo visual y el modelo funcional. Al editar un modelo visual se cambian dimensiones y ubicaciones de los componentes en el layout del dispositivo de Entrada/Salida 120 sin alterar el vínculo que existe entre el Modelo visual y el modelo funcional respectivo, según lo establecen los protocolos cargados en la Etapa A.

El Procesador 150 almacena los modelos visuales en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134.

Etapa C'. Incorporar modelos funcionales y visuales.

En una modalidad de la invención, esta Etapa C' es sustitutiva de la Etapa C, como se muestra en la Figura 3B.

En esta etapa, se incorporan modelos funcionales y visuales, creados por un usuario, aplicando manualmente los criterios de los Protocolos definidos en las Subetapas A1 y A2.

A través del dispositivo de Entrada/Salida 120, un usuario carga en la Memoria de Base de Datos 130, estructura lógica Modelos M^f 135, los modelos funcionales creados manualmente.

A través del dispositivo de Entrada/Salida 120, un usuario carga en la Memoria de Base de Datos 130, estructura lógica Modelos M^v 134, los modelos visuales creados manualmente.

Etapa D.Leer e instanciar los modelos funcionales y visuales como una aplicación de tipo software operable

En esta etapa, el Procesador 150, configurado como Instanciador de Modelos 153 accede a la Memoria de Base de Datos 130 con el objetivo de construir modelos conjugados que aloja en la Memoria General 140. Un modelo conjugado, es un modelo que combina un modelo Funcional m F (definido en base al protocolo PEF) con un modelo Visual MV (definido en base al protocolo PEV), por lo tanto, representa la funcionalidad y la definición de los modelos visuales asociados con algún Recurso UI 133, conjugados en un único modelo que se presenta en la Interfaz de Aplicación 123, como una aplicación tipo software accesible y operable por un usuario.

El resultado producido por el Procesador 150 configurado como Instanciador de Modelos 153, se expone mediante un servicio de interpretación y entrega de aplicaciones de tipo software. Cuando un usuario se autentica en este servicio, lo primero que recibe es una interfaz de aplicación con la cual podrá comenzar a interactuar.

La interpretación, en el presente invento, es un proceso que se ejecuta como servicio y mediante la lectura de modelos conjugados (Modelos MF Modelos MV Recursos UI), resuelve frente a la interacción del usuario, las acciones que éste vaya ejecutando sobre una aplicación de tipo software expuesta en el Dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123.

Como resultado principal de la ejecución del sistema 100 se obtiene:

- Una aplicación tipo software expuesta en la Interfaz de Aplicación 123.

- Un set de información generada por el usuario, en interacción con la aplicación tipo software, comúnmente llamado “datos del usuario”, que el Procesador 150 almacena en la Memoria de Base de Datos 130, estructura lógica Objetos 136.

Para lograr este resultado, el Procesador 150, configurado como Instanciador de Modelos 153, lleva a cabo las siguientes subetapas:

Subetapa D1. Leer e interpretar los modelos visuales MV

Los modelos (tanto funcionales como visuales) son estructuras que respetan los protocolos cargados en la Etapa A, almacenadas en la Memoria de Base de Datos 130, estructuras lógicas PEF 132 y PEV 131 respectivamente.

En esta subetapa, el Procesador 150, configurado como Instanciador de Modelos 153, lee los modelos visuales de la Memoria de Base de Datos 130, estructura lógica Modelos MV 134 que se encuentran almacenados y validados según las definiciones del protocolo PEV cargado en la Subetapa A2.

Una vez leído el modelo visual, el sistema 100 construye una estructura tipo layout que organiza la disposición de las instancias de ModelObject y ActionLinks sobre el layout y almacena dicha estructura en la Memoria General 140, estructura lógica Matriz de Componentes UI 141.

Subetapa D2. Leer e interpretar los modelos funcionales MF

En esta subetapa, el Procesador 150, en su función de Instanciador de Modelos 153, lee los modelos funcionales de la Memoria de Base de Datos 130, estructura lógica Modelos MF 135 que se encuentran almacenados y validados según las definiciones del protocolo PEF cargado en la Subetapa A1.

El Procesador 150 del sistema 100 procesa tres tipos de modelos funcionales: modelos de cálculo, modelos de datos persistidos y modelos de datos interactivos:

Modelos de cálculo: procesa las expresiones de las clases fórmula que se encuentran en el repositorio MF transportando la expresión al servicio que la resuelve devolviendo el resultado como una instancia de ModelAttribute a través de FxCall.

Modelos de datos persistidos: procesa la expresión de acceso a la Memoria de Base de Datos 130 que proveen las clases Dominio, las cuales actúan sobre el repositorio de Objetos 136, ejecutando la que se encuentran en el repositorio MF.

Modelos de datos interactivos: procesa los datos que el usuario ingresa en la Interfaz de Aplicación 123, de manera interactiva a través de los ActionLinks de cada ViewModel con el cual interactúa el usuario.

Una vez leído el modelo funcional, el Procesador 150 del sistema 100 interpreta e instancia una estructura tipo business y la almacena en la Memoria General 140, estructura lógica Matriz de Componentes UI, asociada a la estructura visual creada en la Subetapa D1, donde los vínculos entre los modelos visuales y modelos funcionales instanciados responden a la lógica de los protocolos cargados en la Etapa A.

Subetapa D3. Seleccionar y Compaginar los Recursos UI

Los Recursos UI son los componentes de software pre-alojados en la Memoria de Base de Datos 130, estructura lógica Recursos UI, que al ejecutarse asociados a un modelo visual permiten la generación del dibujo de la pantalla en la Interfaz de Aplicación 123. Son las definiciones de procesamiento de los modelos visuales. En la industria del Software se comercializan distintos sets de recursos de ^{U i ,} que pueden ser incorporados al sistema como se indica en la Subetapa A3, para ofrecer diferentes modos de visualización para las aplicaciones tipo software resultantes. Para completar cada modelo conjugado, el sistema 100 selecciona un componente de la Matriz MF 142, su correspondiente componente de la Matriz MV 143 y un Recurso UI 133 compatible con el tipo de MV seleccionado. El Procesador 150, configurado como Compaginador de UI 152, compagina los componentes seleccionados entregando como argumento de las funciones del Recurso UI, las partes del modelo conjugado (Modelo MF Modelo MV asociado) que el componente requiere para funcionar.

De esta manera el Procesador 150 expone un componente conjugado en el Dispositivo de Entrada/Salida 120, repitiendo el procedimiento para cada uno de los componentes creados para “el caso”. Un componente expuesto constituye una pantalla operativa de una aplicación de tipo software que presenta botones de acción, casillas donde el usuario puede ingresar datos y otras funcionalidades que estén abarcadas por el modelo conjugado. Por ejemplo: Un ModelClass Artículo que tiene un ModelAttribute nombre, se expone en un AbmViewModel que define una pantalla con un TextEditor para editar la instancia del MOdelAttribute Nombre. Esta pantalla define una función por cada ActionLink del Model View.

El ViewModel especifica que utilizará el Componente UI llamado “control TextBox 3d” para mostrar el nombre, por lo cual el Procesador 150 compagina el componente mencionado que se encuentra almacenado en la Memoria Rcursos UI 133 para completr el modelo conjugado. Esta compaginación permite que la casilla de texto nombre se muestre en el dispositivo de Entrada/Salida 120 con una apariencia 3d coloreada, según las características del componente “control TextBox 3d”. El componente de tipo TextEditor, se conjuga con el Recurso UI textbox 3D y se asocia con la funcionalidad ModelAttribute para lograr que el Procesador 150 instancie en la Interfaz de Aplicación 123 un cuadro donde un usuario pueda ingresar un texto, que tenga una apariencia tridimensional y soporte la recepción del texto para luego persistir el dato en la Memoria de Base de Datos 130, estructura lógica Objetos 136.

Subetapa D4. Resolver las instancias de ModelClass invocadas

Una vez resuelta la compaginación en la Subetapa D3, se encuentran en la Memoria General 140, estructura lógica Matriz de Componentes UI 141, los modelos conjugados que formarán la aplicación de tipo software resultante. El Procesador 150, configurado como Instanciador de Modelos 153, obtiene las instancias del ModelObject asociado al modelo conjugado (ModelClass-ViewModel-Recurso UI) que se expone al usuario. Los AttributeValues correspondientes a la instancia seleccionada se envían al dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123 según el layout definido en el modelo conjugado y de este modo se presenta ante el usuario una pantalla de aplicación tipo software operable.

Subetapa D5. Recibir y resolver peticiones de usuario

Una vez expuesta la visualización en el dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123, el usuario acciona presionando algún botón, ingresando algún dato en alguna de las casillas, desplegando alguna lista de opciones, o accediendo a alguna de las estructuras visuales disponibles. Cuando esto sucede, el Procesador 150, configurado como Instanciador de Modelos 153, ejecuta la función correspondiente al modelo funcional que conforma el modelo conjugado sobre el cual está accionando el usuario, a través de un ActionLink o cualquiera de las funcionalidades existentes, según se define en el protocolo PEF cargado en la Subetapa A1.

Subetapa D6. Exponer Instancias de ModelClass actualizadas

Una vez resuelto el modelo conjugado, el Procesador 150, configurado como Instanciador de Modelos 153, se produce una actualización de instancia del modelo conjugado que está expuesto en el dispositivo de Entrada/Salida 120, Interfaz de Aplicación 123. El Procesador 150 toma la instancia nueva y actualiza el dispositivo de Entrada/Salida 120 con los cambios producidos.

Ejemplo de Aplicación del Método:

Dado un caso, que consta de un diagrama de clases como el que se expone en la Figura 2C1 y un diagrama de pantallas como el que se expone en la Figura 2D, se ejecutan las etapas del método, así:

■ Etapa A. Cargar los protocolos en la memoria

Esta etapa es considerada la inicialización del sistema, dado que por única vez se cargan los protocolos y eventualmente se agregan Recursos UI al sistema.

■ Etapa B. Identificar y Almacenar componentes de Diseño

[0136] En esta etapa se toman el diseño de clases y el diseño de pantallas de “el caso” y se realizan las siguientes subetapas:

(i) Subetapa B1. Identificar los componentes del diseño funcional

Por cada uno de los componentes del diagrama de clases, se identifican los correspondientes componentes PEF, aplicando el protocolo de especificación funcional PEF, cargado en la Subetapa A1, así:

Tabla 1

Componente

del diseño TipoOO Nombre Concepto PEF Nombre Modelo a crear Clase 1 Clase Clase 1 ModelClass ^Modelo1

Clase 1 Atributo Atributo1 ModelAttribute Modelo Atributo1

Clase 1 Atributo atributoClase2_Rel1 ModelAttribute Modelo atributoClase2_Rel1 Clase 2 Clase Clase 2 ModelClass Modelo Clase 2

Clase 2 Atributo Atributo6 ModelAttribute Modelo Atributo6 Clase 2 Atributo Atributo73 ModelAttribute Modelo Atributo7

Clase 2 Atributo atributoClase1_Rel1 ModelAttribute Modelo atributoClase1_Rel1 Clase 3 Clase Clase 3 ModelClass Modelo 3

Clase 3 Atributo Atributo1 ModelAttribute Modelo Atributo1

Clase 3 Atributo Atributo2 ModelAttribute Modelo Atributo2

Clase 3 Método Calcular Formula Calcular

Clase 3 Método Validar(Datos_Validar) Formula Validar(Datos_Validar) Clase 3 No existe Datos_Validar Dominio Datos_Validar

Clase 3 No existe FxCallCalcular FxCall FxCallCalcular

Clase 3 No existe FxCallValidar FxCall FxCallValidar

Clase 4 Clase Clase 4 ModelClass Modelo 4

Clase 4 Atributo Atributo3 ModelAttribute Modelo Atributo3

Clase 4 Método Buscar(Datos_Buscar) Formula Buscar(Datos_Buscar) Clase 4 No existe Datos_Buscar Dominio Datos_Buscar

Clase 4 No existe FxCallBuscar FxCall FxCallBuscar

Clase 5 Clase Clase 5 ModelClass Modelo 5

Clase 5 Atributo Atributo9 ModelAttribute Atributo9

Clase 5 Método Reportar Formula Reportar

Clase 5 No existe Datos_Reportar Dominio Datos_Reportar

Clase 5 No existe FxCallReportar:Datos_Reportar FxCall FxCallReportar:Datos_Reportar Relacion1 Atributo Atributo 8 ModelAttribute Modelo Atributo 8 Relacion1 Atributo RatributoClase1_Rel1 ModelAttribute Modelo RatributoClase1_Rel1 Relacion1 Atributo RatributoClase2_Rel1 ModelAttribute Modelo RatributoClase2_Rel1 Relacion1 Relacion Relacion1 ModelRelationClass Modelo Relacion1

El usuario ingresa esta lista, columnas 1, 2 y 3 (Componentes del diseño, Tipo OO y Nombre) de la Tabla 1, a través del Dispositivo de Entrada/Salida 120, interfaz de c Df 121 y el Procesador 150 la almacena en la Memoria General 140, estructura lógica Matriz de MF 142. Luego, el Procesador 150, configurado como Validador de Modelos 151, lee el protocolo de especificación funcional PEF cargado en la Subetapa A1, completa las columnas 3 y 4 (Concepto PEF y Nombre del modelo a crear) de la Tabla 1, y actualiza la Memoria General 140, estructura lógica Matriz de MF 142 con estos datos.

(ii) Subetapa B2. Identificar los componentes del diseño visual

Por cada uno de los componentes del diseño de pantallas, se identifican los correspondientes componentes PEV, aplicando el protocolo de especificación visual ^p E^v , cargado en la Subetapa A2, así:

Tabla 2

Componente funcional Concepto PEF Concepto PEV Modelo Visual a crear

Clase 1 ModelClass ABM Clase 1

ABM View Model List Clase 1

Clase 1 ModelAttribute _{____List View Model}

Clase 1 ModelAttribute

Clase 2 ModelClass

Clase 2 ModelAttribute ABM View Model ABM Clase 2

_{Clase 2 ModelAttribute} List View Model List Clase 2

Clase 2 ModelAttribute

Clase 3 ModelClass ABM View Model ABM Clase 3

_{Clase 3 ModelAttribute} List View Model List Clase 3

Clase 3 ModelAttribute

Clase 3 Formula

Clase 3 Formula

Clase 3 Dominio

Clase 3 FxCall

Clase 3 FxCall

Clase 4 ModelClass

Clase 4 ModelAttribute

ABM View Model ABM Clase 4

Clase 4 Formula List View Model List Clase 4

Clase 4 Dominio

Clase 4 FxCall

Clase 5 ModelClass

Clase 5 ModelAttribute ABM View Model ABM Clase 5

Clase 5 Formula List View Model List Clase 5

Clase 5 Dominio

Clase 5 FxCall

Relacion1 ModelAttribute

Relacion1 ModelAttribute List View Model List View Relacion 1

Relacion1 ModelAttribute Tree View Model Tree View Relacion1

Relacion1 ModelRelationClass

El Procesador 150, configurado como Validador de Modelos 151, toma la lisa de componentes funcionales residente en la Memoria General 140, estructura lógica Matriz de MF 142 y la expone en el dispositivo de Entrada/Salida 120, interfaz de CDV 122, tal como se muestra en la columna 1 y 2 (Componente funcional, Concepto PEF) de la Tabla 2. El Procesador 150, lee el protocolo de especificación visual PEV cargado en la Subetapa A2, y completa las columnas 3 y 4 (Concepto PEF, Modelo visual a crear) y actualiza la Memoria General 140, estructura lógica Matriz de MV 143 con estos datos.

■ Etapa C. Crear modelos funcionales y visuales

Para los componentes funcionales y visuales identificados en la Etapa B del presente ejemplo, se realizan las siguientes subetapas:

(iii) Subetapa C1. Identificar los componentes PEF y crear los Modelos Funcionales

El Procesador 150 identifica los componentes PEF disponibles en la Memoria General 140, Matriz de MF 142, correspondientes a las columnas 3 y 4 (Concepto PEF y Nombre del modelo a crear) de la Tabla 1, y realiza la especificación de conceptos PEF según el protocolo cargado en la Subetapa A1. Recorre la lista, identifica el concepto PEF, y crea los componentes definidos para la matemática en los métodos que así lo requieren según la definición del protocolo PEF. Esta especificación implica identificar el concepto PEF y sus correspondientes estructuras lógicas en la Memoria de Base de Datos 130, para crear los modelos funcionales y almacenarlos en la estructura lógica Modelos MF 135.

En el presente ejemplo, se obtiene como resultado de esta etapa la siguiente lista de modelos funcionales, almacenados en la Memoria de Base de Datos 130, estructura lógica Modelos MF 135:

Tabla 3

Concepto PEF Nombre Modelo MF

ModelClass Modelo1

ModelAttribute Modelo Atributo1

ModelAttribute Modelo atributoClase2_Rel1

ModelClass Modelo Clase 2

ModelAttribute Modelo Atributo6

ModelAttribute Modelo Atributo7

ModelAttribute Modelo atributoClase1_Rel1

ModelClass Modelo 3

ModelAttribute Modelo Atributol

ModelAttribute Modelo Atributo2

Formula Calcular

Formula Validar(Datos_Validar)

Dominio Datos_Validar

FxCall FxCallCalcular

FxCall FxCallValidar

ModelClass Modelo 4

ModelAttribute Modelo Atributo3

Formula Buscar(Datos_Buscar)

Dominio Datos_Buscar

FxCall FxCallBuscar

ModelClass Modelo 5

ModelAttribute Atributo9

Formula Reportar

Dominio Datos_Reportar

FxCall FxCallReportar:Datos_Reportar

ModelAttribute Modelo Atributo 8

ModelAttribute Modelo RatributoClase1_Rel1

ModelAttribute Modelo RatributoClase2_Rel1

ModelRelationClass Modelo Relacion1

La estructura técnica de creación de los modelos funcionales se puede observar en la Figura 2C1, donde cada componente de la Tabla 3, se exhibe, relacionado con el concepto del Protocolo PEF que le corresponde.

(iv) Subetapa C2. Identificar los componentes PEV y crear los Modelos Visuales

El Procesador 150 identifica los componentes PEV disponibles en la Memoria General 140, Matriz de MV 142, correspondientes a las columnas 3 y 4 (Concepto PEF, Modelo visual a crear) de la Tabla 2, y realiza la especificación de conceptos PEV según el protocolo cargado en la Subetapa A2.

En el presente ejemplo, se obtiene como resultado de esta etapa la siguiente lista de modelos visuales, almacenados en la Memoria de Base de Datos 130, estructura lógica Modelos MV 134:

Tabla 4

■ Etapa D. Leer e instanciar los modelos funcionales y visuales como una aplicación de tipo software operable Subetapa D1. Leer e interpretar los modelos visuales MV

Se ejecuta el proceso indicado en la Subetapa D1 del invento, partiendo de la lista del ejemplo de la Tabla 4.

Subetapa D2. Leer e interpretar los modelos funcionales MF

Se ejecuta el proceso indicado en la Subetapa D2 del invento, partiendo de la lista del ejemplo de la Tabla 3.

Subetapa D3. Seleccionar y Compaginar los Recursos UI

Se compaginan los recursos UI seleccionados para mostrar las pantallas requeridas en el diseño de pantallas, hasta lograr un diseño visual como el que se muestra en la Figura 2D.

Subetapa D4. Resolver las instancias de ModelClass invocadas

A medida que el usuario opera sobre la Interfaz de Aplicación, es sistema responde, ejecutando las acciones enumeradas en la Subetapa D4 del presente invento.

Las siguientes subetapas se producen en la medida que el usuario interactúa con la aplicación resultante del ejemplo: Subetapa D5. Recibir y resolver peticiones de usuario

Subetapa D6. Exponer Instancias de ModelClass actualizadas

Se debe entender que la presente invención no se halla limitada a las modalidades descritas e ilustradas, pues como será evidente para una persona versada en el arte, existen variaciones y modificaciones posibles que no se apartan del espíritu de la invención, el cual solo se encuentra definido por las siguientes reivindicaciones.

Claims (8)

REIVINDICACIONES

1. Un método implementado por computador para instanciar y mostrar automáticamente aplicaciones de tipo software basadas en especificaciones de diseño de software, el método comprendiendo las siguientes etapas:

a. cargar, mediante un dispositivo de entrada/salida (120) que está conectado a una CPU, “unidad de procesamiento central” (110), un PEF, “protocolo de especificación funcional”, un PEV, “protocolo de especificación visual” y unos UI, recursos de “interfaz de usuario”, y almacenarlos en una memoria de base de datos (130) que está conectada a la CPU (110);

b. identificar, validar respecto a los protocolos de la etapa a y almacenar componentes de diseño funcional y visual a partir de especificaciones de diseño de software en una memoria general (140); donde el paso b comprende las siguientes subetapas:

identificar los componentes de diseño funcional a partir de un diseño de clases cargadas desde unas memorias o unos dispositivos de entrada/salida; y

identificar los componentes de diseño visual a partir de un diseño de pantalla cargados desde las memorias o los dispositivos de entrada/salida;

c. crear automáticamente modelos funcionales y visuales a partir de los componentes de diseño funcional y visual identificados en la etapa b, y almacenar dichos diseños funcionales y visuales en la memoria de base de datos (130) en unas estructuras lógicas de modelos funcionales MF (135), “modelos funcionales” y modelos MV (134), “modelos visuales”, respectivamente; donde el paso c comprende:

procesar, mediante la unidad de procesamiento central (110), el PEF para identificar sus componentes, y crear modelos funcionales; y

procesar mediante una unidad de procesamiento central (110) el PEV para identificar sus componentes, y crear modelos visuales para ser almacenados en la memoria de base de datos (130); y

d. leer e instanciar una interfaz de aplicación (123), junto con los modelos funcionales y visuales creados en la etapa c, combinados con los recursos de UI, siguiendo las normas de los protocolos almacenados en la etapa a, mediante un procesador (150) configurado como instanciador de modelos (153) y desplegar automáticamente la aplicación en el dispositivo de entrada/salida (120).

2. El método de la Reivindicación 1, en donde la etapa d comprende las subetapas:

a. leer y procesar, mediante la unidad de procesamiento central (110), los modelos visuales;

b. leer y procesar, mediante la unidad de procesamiento (110), los modelos funcionales;

c. procesar, mediante la unidad de procesamiento central (110), los modelos funcionales para seleccionarlos y compaginarlos con los componentes de la interfaz de usuario;

d. procesar, mediante la unidad de procesamiento central (110), los componentes de los modelos funcionales para resolver unas instancias de unas metaclases invocadas por un usuario mediante su interacción a través de los dispositivos de entrada/salida (120);

e. recibir y resolver unas peticiones del usuario realizadas a través de dispositivos de entrada/salida (120) y procesar las peticiones de usuario mediante la unidad de procesamiento central (110); y

f. mostrar las instancias de las metaclases actualizadas en los dispositivos de entrada/salida (120).

3. El método de la Reivindicación 1, en donde la etapa a, comprende los siguientes pasos secundarios:

a. procesar, mediante una unidad de procesamiento central (110), unos diagramas funcionales almacenados en la memoria para identificar las clases incluidas en dichos diagramas; e

b. identificar el nombre de cada clase de las clases y almacenarlo en la memoria de base de datos (130).

4. El método de la Reivindicación 1, en donde la etapa b comprende los siguientes pasos secundarios:

a. crear los modelos visuales a partir de las clases identificadas aplicando el PEV y almacenar el PEV en la memoria de base de datos (130); y

b. editar la apariencia de los modelos visuales creados y almacenarlos en la memoria de base de datos (130) utilizando los dispositivos de entrada/salida (120) en caso de ser requerido.

5. El método de la Reivindicación 1, en donde la etapa a comprende los siguientes pasos secundarios:

a. procesar, mediante la unidad de procesamiento central (110), una lista de modelos funcionales para crear objetos incluidos en dichos modelos funcionales siguiendo el PEF cargado en la memoria de base de datos (130) para cada uno de los componentes; y

b. procesar, mediante una unidad de procesamiento central (110), los componentes de los diagramas funcionales asociados a una fórmula matemática para crear componentes adicionales que permitan la ejecución de dicha fórmula y almacenarla en la memoria de base de datos (130).

6. El método de la Reivindicación 1, en donde la etapa c comprende los siguientes pasos secundarios:

a. procesar, a través de la unidad de procesamiento central (110), una lista de componentes PEF almacenada en la memoria general (140) para definir, para cada contenido funcional, un concepto del PEF;

b. crear los modelos visuales para cada concepto funcional y almacenarlo en la memoria de base de datos (130);

c. crear un modelo visual para la aplicación usando un nombre representativo del caso y almacenarlo en la memoria de base de datos (130); y

d. crear un modelo visual de tipo menú con un nombre representativo y un grupo de menú por cada uno de los componentes de diseño, asignando al grupo el nombre del componente de diseño y almacenarlo en la memoria de base de datos (130).

7. Un sistema para instanciar y exponer aplicaciones operativas de tipo software a partir de especificaciones de diseño, en donde el sistema comprende:

a. un dispositivo de entrada/salida (120) que incluye una CDF, interfaz de “componentes de diseño funcionales” (121), una CDV, interfaz de “componentes de diseño visuales” (122), y una interfaz de aplicación (123) para ingresar las especificaciones de diseño y mostrar las aplicaciones de tipo software resultantes;

b. una CPU (110) conectada al dispositivo de entrada/salida (120), y la cual contiene:

una memoria general (140) que está en comunicación con el dispositivo de entrada/salida (120), que interactúa con un procesador (150), configurada para almacenar de manera volátil los componentes de diseño funcionales, componentes de diseño visuales, así como componentes de UI; y

el procesador (150) configurado para recibir al menos una especificación de diseño del dispositivo de entrada/salida (120); dicho procesador (150) configurado como validador de modelos (151) para validar la al menos una especificación de diseño con respecto a protocolos que residen en una memoria de base de datos (130), e identificar modelos funcionales y visuales, el procesador (150) configurado como compaginador de UI (152), paga compaginar la aplicación de tipo software resultante, uniendo modelos funcionales y visuales, y recursos de UI y el procesador (150) configurado como instanciador de modelos (153) para mostrar la aplicación de tipo software resultante en la interfaz de la aplicación (123); y

c. una memoria de base de datos (130) conectada a la CPU (110), emparejada con el procesador (150), configurada para almacenar en forma estática un PEV en una estructura lógica PEV (131), almacenar en forma estática un PEF en una estructura lógica PEF (132) y los recursos de UI en una estructura lógica de recursos de UI (133), y también configurada para almacenar en forma dinámica, modelos visuales en una estructura lógica de modelos visuales MV (134), modelos funcionales en una estructura lógica de modelos funcionales MF (135) y unos objetos en una estructura lógica de objetos (136);

donde la unidad de procesamiento central (110) realiza:

identificar los componentes de diseño funcional con base en el diseño de clases almacenados en el dispositivo de entrada/salida (120) y hacer el procesamiento de validación de dichos componentes de diseño funcional con respecto a los PEF cargados en la memoria de base de datos (130);

identificar los componentes de diseño visual con base en un diseño de pantalla que fue cargado de memorias o dispositivos de entrada/salida (120) y hacer el procesamiento de validación de dichos componentes de diseño visual con respecto a los PEV cargados en la memoria de base de datos (130);

crear modelos funcionales con base en los componentes de diseño funcional y almacenarlos en la memoria de base de datos (130);

crear modelos visuales con base en los componentes de diseño visual y almacenarlos en la memoria de base de datos (130);

leer e instanciar una interfaz de aplicación (123), junto con los modelos funcionales y los modelos visuales almacenados en la memoria de base de datos (130) al llevar a cabo la compaginación y el procesamiento de la interacción entre los modelos funcionales y los modelos visuales, creando una interfaz de usuario, almacenando dichas interfaces de usuario en la memoria de base de datos (130) y desplegar automáticamente la aplicación de tipo software en los dispositivos de entrada/salida (120).

8. El sistema de la Reivindicación 7, en donde el dispositivo de entrada/salida se caracteriza por:

a. permitir el ingreso de diagramas funcionales a una memoria general (140) que serán recuperados por la unidad de procesamiento central (110) para crear modelos funcionales; y

b. permitir el ingreso de diseños de pantallas a una memoria general (140) que serán recuperados por la unidad de procesamiento central para crear modelos visuales.