ES2692120T3 - Procedimiento y aparato de generación de interfaces de usuario a base de automatización con flexibilidad total - Google Patents

Abstract

Un procedimiento implementado por ordenador de generación de una interfaz de usuario de formulario controlada por modelo para representar un modelo de aplicación, comprendiendo el procedimiento: recibir una entrada de selección para seleccionar cuál de una pluralidad de diferentes tipos de formulario lógico usar para generar una interfaz de usuario de formulario para representar un modelo de aplicación; proporcionar un primer mapa declarativo; generar un formulario lógico independiente del objetivo de visualización usando el modelo de aplicación, el tipo de formulario lógico seleccionado y el primer mapa declarativo, en el que generar el formulario lógico independiente del objetivo de visualización usando el primer mapa declarativo comprende además correlacionar tipos de propiedades de dato del modelo de aplicación con controles lógicos independientes del objetivo visualización en el formulario lógico independiente del objetivo de visualización; correlacionar el formulario lógico independiente del objetivo de visualización con un formulario físico usando un segundo mapa declarativo, en el que el formulario físico tiene una pluralidad de controles físicos disponibles para su uso en la presentación del formulario lógico en un objetivo de visualización, comprendiendo el uso del segundo mapa declarativo correlacionar cada uno de los controles lógicos en el formulario lógico con uno de la pluralidad de controles físicos disponibles; y presentar la interfaz de usuario de formulario en tiempo de ejecución usando el formulario lógico generado de tal forma que el modelo de aplicación está accionado en un tiempo de ejecución, comprendiendo la presentación del formulario lógico como el formulario físico en el objetivo de visualización, en el que el formulario lógico se genera en tiempo de ejecución usando tanto el tipo de formulario lógico seleccionado como metadatos del modelo de aplicación.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Procedimiento y aparato de generacion de interfaces de usuario a base de automatizacion con flexibilidad total Antecedentes de la invencion

La presente invencion se refiere a la generacion de formularios. Mas particularmente, la presente invencion se refiere a procedimientos y aparato de generacion de interfaces de usuario (UI) de formulario.

En productos de software tipicos y aplicaciones, tal como sistemas de planificacion de recursos empresariales (ERP) y sistemas de gestion de relaciones con clientes (CRM), se usan un gran numero de formularios o interfaces de usuario de formulario. Un formulario es una ventana, un dialogo, una pagina u otro elemento de UI de visualizacion y/o entrada de datos. No es comun que el numero de formularios que se usan en conjuncion con una aplicacion de software de negocio exceda de varios miles. Desarrollar un gran numero de formularios ha sido tradicionalmente una tarea de mucho trabajo para los desarrolladores de software.

Ademas, esta creciendo la complejidad en aplicacion de negocio tal como sistemas ERP, sistemas CRM y otras aplicaciones basadas en formularios. Esto esta provocado por un numero de factores que incluyen: (1) un numero creciente de formularios en cada sistema que se debe a funcionalidad aumentada; (2) un foco creciente sobre la usabilidad que se origina desde usuarios finales que se han acostumbrado a usabilidad de pagina web; (3) numero creciente de diferentes plataformas, dispositivos y tecnologfas; (4) un foco creciente en seguridad que puede resultar en diferentes formularios dependiendo de derechos de usuario; y (5) una demanda creciente de flexibilidad, eficiencia y personalizacion. Al mismo tiempo existe un empuje para desarrollar sistemas mas rapidos con mayor calidad.

Como un ejemplo de una aplicacion de negocio real, considerese Microsoft Business Solutions-Axapta®, que tiene cerca de 3.000 tablas, resultando en cerca de 2.000 formularios. Cada formulario tiene que alinearse con la disposicion de cada tabla desde la que se vinculan los datos de tiempo de ejecucion. Los formularios y logica de formularios relacionados tienen que alinearse siempre que cambia la disposicion de tabla y cuando cambia la logica de negocio. Se anade a la complejidad el numero creciente de diferentes tecnologfas de plataformas cliente. La UI de Windows clasica se acompana ahora con el explorador web. En el futuro cercano, asistente digital personal (PDA), telefono celular y otras tecnologfas de UI se anadiran a la complejidad.

La Internet ha ensenado a los usuarios finales que no necesitan un curso de 14 dfas para aprender como usar una aplicacion. Los usuarios finales esperan que las aplicaciones les grnen a traves de tareas y esperan que la aplicacion tenga un aspecto atrayente. Porque mas roles de usuarios se exponen a la tecnologfa de la informacion presentada a traves de aplicaciones de negocio, existe una demanda creciente para que formularios reflejen la informacion que necesita cada usuario y las tareas que cada rol tiene que conseguir. En general estan aumentando las demandas de experiencia de usuario.

Tfpicamente, la experiencia de usuario y experiencia de desarrollador se mueven en direcciones opuestas. Un desarrollador de aplicacion tarda mas en crear y mantener una buena experiencia de usuario. La vision de que tiene una excelente experiencia de usuario y al mismo tiempo soporta productividad de desarrollador alta, puede verse contradictorio. Esto es particularmente cierto en el area de generacion formularios para aplicaciones de negocio.

Aplicaciones que presentan informacion deben proporcionar a sus usuarios con una experiencia tan rica como sea posible en plataformas de muy varias capacidades (oscilando desde clientes enriquecidos que ejecutan en el escritorio del usuario, a clientes Web que se ejecutan en el navegador del usuario, a Asistentes Digitales de Bolsillo, dispositivos basados en telefoma e incluso interfaces de voz). Un arquitecto de negocio usa su conocimiento en ingeniena de negocios para resolver problemas al cliente. Esta persona no es un desarrollador de programa informatico y debena protegerse de las particularidades del desarrollo de programas.

La presente invencion proporciona soluciones a uno o mas de los problemas anteriormente mencionados y/o proporciona otras ventajas sobre la tecnica anterior.

El documento US 2003/025693 se refiere a un procedimiento para proporcionar una pantalla de interfaz de usuario. Se genera un formulario electronico independiente de una imagen de visualizacion objetivo. Informacion de control de presentacion comprende sentencias declarativas para su uso en la generacion de formulario de interfaz de usuario electronico. La informacion de control de presentacion especifica ubicaciones relativas de elementos de visualizacion de interfaz y elementos de aviso. Se determina la disposicion general de formulario electronico y los datos visualizados dentro del formulario. Se usa un motor de generador de codigos separado para la generacion de codigo a partir la informacion de control de presentacion y otros datos en un formato de codigo deseado. Se genera codigo de provision de un formulario electronico a base de la informacion de control de presentacion y elementos adicionales mantenidos de forma separada. Se genera codigo DHTML que representa un formulario deseado a base de datos de entrada proporcionados por el constructor de interfaz de usuario que incluye informacion de control de presentacion y artfculos de datos de entrada auxiliares. Se usa informacion de control de presentacion para dirigir la generacion de codigo DHTML que representa una forma deseada. Informacion de control a su vez usa estructura de formato de datos de informacion formulario que contiene datos presentados en la forma deseada. Informacion de

5

10

15

20

25

30

35

40

45

50

55

control tambien emplea objetos que comprenden procedimientos a ejecutar en respuesta a una seleccion de usuario de elementos de visualizacion. Informacion de control de presentacion comprende sentencias declarativas que determinan los elementos de visualizacion de presentacion que contiene el formulario deseado. De este modo, un formulario se adapta facilmente para diferentes tamanos de imagen de visualizacion y para su uso por diferentes arquitecturas de sistema.

El documento US 2003/025732 se refiere a una interfaz grafica de usuario personalizable. Se usan ficheros de texto de XML para describir una o mas interfaces de usuario. La informacion en el fichero de XML se usa para generar la interfaz de usuario. Actualizaciones dinamicas permiten cambios en los ficheros y la adicion/eliminacion de ficheros incluso en tiempo de ejecucion. La disposicion general de la interfaz de usuario se define en una plantilla basada en HTML. Se generan detalles de la interfaz de usuario recuperando un fichero de texto de plantilla de XML seleccionado, rellenando el texto de XML con datos de sistema actuales, convirtiendo los datos de XML a HTML y rellenando la plantilla HTML para producir un texto basado en HTML para su visualizacion. La interfaz de usuario se genera a continuacion a partir del texto visualizado basado en HTML mediante el explorador web.

Es el objeto de la presente invencion proporcionar una tecnica de generacion de una interfaz de usuario de formulario controlada por modelo con flexibilidad y extensibilidad mejoradas.

Este objeto se resuelve mediante el objeto de las reivindicaciones independientes.

Se definen realizaciones preferidas en las reivindicaciones dependientes.

Sumario

Se proporcionan un procedimiento, medio legible por ordenador y sistema que generan una interfaz de usuario de formulario controlada por modelo para representar una aplicacion/modelo de negocio (tambien denominado como un modelo de datos o un modelo de dominio del problema). El procedimiento incluye seleccionar cual de multiples diferentes tipos de formulario logico aplicar a un formulario logico para generar la interfaz de usuario de formulario para representar el modelo de aplicacion. El procedimiento tambien incluye proporcionar un primer mapa. Se genera un formulario logico independiente del objetivo de visualizacion usando el modelo de aplicacion, el tipo de formulario seleccionado y el primer mapa. En realizaciones de la presente invencion, el primer mapa es un mapa declarativo, aunque puede tener funciones o aspectos imperativamente definidos en algunas realizaciones.

La generacion del formulario logico independiente del objetivo de visualizacion usando el primer mapa incluye correlacionar tipos de propiedades de dato del modelo de aplicacion con controles logicos independientes del objetivo visualizacion en el formulario logico independiente del objetivo de visualizacion. En algunas realizaciones, el primer mapa es externo a un motor de correlacion usado para generar el formulario logico independiente del objetivo de visualizacion.

En algunas realizaciones, comportamientos aplicados declarativamente anaden funcionalidad al formulario logico independiente del objetivo de visualizacion. Los comportamientos aplicados declarativamente se adjuntan al formulario logico independiente del objetivo de visualizacion y se activan mediante eventos en el formulario. Los comportamientos declarativos pueden ser patrones de logica que, dependiendo de valores y propiedades de los controles logicos, establecen propiedades en otros controles.

El procedimiento puede incluir tambien la etapa adicional de correlacion del formulario logico con un formulario ffsico usando un segundo mapa. Mientras el formulario logico contiene una pluralidad de controles logicos, el formulario ffsico tiene una pluralidad de controles ffsicos disponibles para su uso en la presentacion del formulario logico en un objetivo de visualizacion. La correlacion del formulario logico al formulario ffsico usando el segundo mapa incluye correlacionar cada uno de los controles logicos en el formulario logico con uno de la pluralidad de controles ffsicos disponibles. Habitualmente tambien incluye la correlacion con una disposicion espedfica para el tipo de formulario particular en el objetivo de visualizacion particular.

Otras caractensticas y beneficios que caracterizan las realizaciones de la presente invencion seran evidentes tras la lectura de la siguiente descripcion detallada y revision de los dibujos asociados.

Breve descripcion de los dibujos

La Figura 1 es un diagrama de bloques de un entorno ilustrativo en el que puede usarse la presente invencion.

La Figura 2 es un diagrama de bloques de un entorno informatico movil general en el que puede implementarse la presente invencion.

La Figura 3-1 es una ilustracion diagramatica del uso de tipos de formulario de la presente invencion para generar formularios logicos y formularios ffsicos.

La Figura 3-2 es una ilustracion diagramatica del uso de tipos de formulario como se muestra en la Figura 3-1, y que ilustra adicionalmente la relacion entre tipos de formulario y la generacion de formularios logicos y formularios ffsicos.

La Figura 4-1 es un diagrama de bloques que ilustra un modelo de negocio de ejemplo.

La Figura 4-2 es un diagrama de bloques que ilustra un modelo de negocio de entidad correlacionado con un

5

10

15

20

25

30

35

40

45

50

55

60

formulario.

La Figura 5-1 es un diagrama de bloques que ilustra un proceso de generacion de modelos usando mapas y otros modelos.

La Figura 5-2 es un diagrama de bloques que ilustra un proceso de generacion de un modelo espedfico de objetivo de visualizacion a partir de una aplicacion inicial o modelo de negocio a traves de una serie de correlaciones.

La Figura 5-3 es un diagrama de bloques que ilustra un proceso del tipo mostrado en las Figuras 4-1 y 4-2 para una realizacion de ejemplo.

La Figura 5-4 es un diagrama de bloques que ilustra un procedimiento de correlacion de ejemplo en el que una entidad de modelo de negocio se correlaciona primero con un formulario independiente del objetivo de visualizacion, con las propiedades de entidad correlacionadas con controles para crear un formulario logico independiente del objetivo de visualizacion, y a continuacion el formulario logico se correlaciona con el objetivo u objetivos de visualizacion

La Figura 6 es un diagrama de bloques que ilustra aspectos de tiempo de diseno y tiempo de ejecucion de la presente invencion y que ilustra que la capa logica es el puente entre la logica de negocio y el objetivo de visualizacion.

La Figura 7 es un diagrama de bloques que ilustra formularios logicos correlacionados con tecnologfas de presentacion espedficas del objetivo de visualizacion.

La Figura 8 es una ilustracion diagramatica de conceptos de la presente invencion.

Descripcion detallada de realizaciones ilustrativas

Con la creciente complejidad en las aplicaciones de negocios y otras aplicaciones de software administrativas o basadas en formularios, la demanda de automatizacion esta aumentando. La presente invencion proporciona un procedimiento de facilitacion y mejora de tal automatizacion. La presente invencion utiliza un enfoque declarativo y automatizado de desarrollo de interfaces de usuario sin poner en peligro la libertad de innovacion.

Usando los sistemas y procedimientos de la presente invencion, los desarrolladores de aplicaciones pueden centrarse en el desarrollo de un modelo de negocio. El modelo de negocio (UML, diagrama de ER, clase, etc.) se correlaciona despues con un formato intermedio independiente de la tecnologfa que de nuevo - en una o mas etapas - se correlaciona con la tecnologfa espedfica del objetivo de visualizacion y disposicion (Windows, Navegador Web, PDA, telefono, etc.). Los desarrolladores de marcos pueden entonces, independientemente de los desarrolladores de aplicaciones, enriquecer la tecnologfa espedfica del objetivo de visualizacion, y hacer que se aplique a toda la aplicacion desarrollada. El formato intermedio se crea una vez por formulario y usa a traves de varios objetivos de visualizacion. La correlacion es inherentemente flexible debido a mapas abiertos y modificables usados por los motores de correlacion. Los modelos de UI intermedios y los formatos de objetivo de visualizacion finales son tambien abiertos y modificables permitiendo un nivel de flexibilidad unico. Las siguientes descripciones ilustran adicionalmente los conceptos inventivos.

La Figura 1 ilustra un ejemplo de un entorno 100 de sistema informatico adecuado en el que puede implementarse la invencion. El entorno 100 de sistema informatico es unicamente un ejemplo de un entorno informatico adecuado y no pretende sugerir ninguna limitacion al alcance de uso o funcionalidad de la invencion. Ni debena interpretarse el entorno 100 informatico como que tiene alguna dependencia o requisito en relacion con uno cualquiera o combinacion de componentes ilustrados en el entorno 100 de operacion ilustrativo.

La invencion es operacional con numerosos otros entornos de sistema informatico o configuraciones de fin general o fin especial. Ejemplos de sistemas informaticos bien conocidos, entornos y/o configuraciones que pueden ser adecuados para su uso con la invencion incluyen, pero sin limitacion, ordenadores personales, ordenadores de servidor, dispositivos de mano o portatiles, sistemas multiprocesador, sistemas basados en microprocesadores, decodificadores de salon, electronica de consumo programable, PC de red, miniordenadores, ordenadores centrales, entornos informaticos distribuidos que incluyen cualquiera de los sistemas o dispositivos anteriores y similares.

La invencion puede describirse en el contexto general de instrucciones ejecutables por ordenador, tal como modulos de programa, que se ejecutan mediante un ordenador. En general, modulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan tareas particulares o implementan tipos de datos abstractos particulares. La invencion tambien puede practicarse en entornos informaticos distribuidos en los que se realizan tareas mediante dispositivos de procesamiento remotos que estan enlazados a traves de una red de comunicaciones. En un entorno informatico distribuido, pueden ubicarse modulos de programa tanto en medio de almacenamiento informatico local como remoto incluyendo dispositivos de almacenamiento de memoria.

Con referencia a la Figura 1, un sistema ilustrativo de implementacion de la invencion incluye un dispositivo informatico de fin general en forma de un ordenador 110. Componentes del ordenador 110 pueden incluir, pero sin limitacion, una unidad 120 de procesamiento, una memoria 130 de sistema y un bus 121 de sistema que acopla diversos componentes de sistema incluyendo la memoria de sistema a la unidad 120 de procesamiento. El bus 121 de sistema puede ser cualquiera de varios tipos de estructuras de bus incluyendo un bus de memoria o controlador de memoria, un bus periferico y un bus local usando cualquiera de una diversidad de arquitecturas de bus. A modo de ejemplo, y no como limitacion, tales arquitecturas incluyen bus de Arquitectura Estandar de la Industria (ISA), bus

5

10

15

20

25

30

35

40

45

50

55

60

de Arquitectura Micro Canal (MCA), bus de ISA mejorada (EISA), bus local de Asociacion de Normalizacion en la Electronica de Video (VESA) y bus de Interconexion de Componentes Perifericos (PCI) tambien conocido como bus de Mezzanine.

El ordenador 110 habitualmente incluye una diversidad de medios legibles por ordenador. El medio legible por ordenador puede ser cualquier medio disponible que puede accederse mediante el ordenador 110 e incluye tanto medio volatil como no volatil, memoria extrafble y no extrafole. A modo de ejemplo, y no como limitacion, el medio legible por ordenador puede comprender medio de almacenamiento informatico y medio de comunicacion. El medio de almacenamiento informatico incluye memoria tanto volatil como no volatil, extrafble como no extrafble implementada en cualquier procedimiento o tecnologfa para almacenamiento de informacion tal como instrucciones legibles por ordenador, estructuras de datos, modulos de programa u otros datos. El medio de almacenamiento informatico incluye, pero sin limitacion, RAM, ROM, EEPROm, memoria flash u otra tecnologfa de memoria, CD- ROM, discos versatiles digitales (DVD) u otro almacenamiento de disco optico, cintas magneticas, cinta magnetica, almacenamiento de disco magnetico u otros dispositivos de almacenamiento magnetico, o cualquier otro medio que puede usarse para almacenar la informacion deseada y que puede accederse mediante el ordenador 110. El medio de comunicacion habitualmente incorpora instrucciones legibles por ordenador, estructuras de datos, modulos de programa u otros datos en una senal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluye cualquier medio de distribucion de informacion. La expresion "senal de datos modulada" significa una senal que tiene una o mas de sus caractensticas establecidas o cambiadas de tal manera que codifica informacion en la senal. A modo de ejemplo, y no como limitacion, el medio de comunicacion incluye medio por cable tal como una red por cable o conexion por cable directo, y medio inalambrico tal como acustico, RF, infrarrojos y otro medio inalambrico. Combinaciones de cualquiera de los anteriores tambien debena incluirse dentro del alcance de medio legible por ordenador.

La memoria 130 de sistema incluye medio de almacenamiento informatico en forma de memoria volatil y/o no volatil tal como memoria 131 de solo lectura (ROM) y memoria 132 de acceso aleatorio (RAM). Un sistema 133 basico de entrada/salida (BIOS), que contiene las rutinas basicas que ayudan a transferir informacion entre elementos dentro del ordenador 110, tal como durante el inicio, se almacena habitualmente en la ROM 131. La RAM 132 habitualmente contiene datos y/o modulos de programa que son accesibles inmediatamente a y/o en los que se operan actualmente mediante la unidad 120 de procesamiento. A modo de ejemplo, y no como limitacion, la Figura 1 ilustra el sistema 134 operativo, programas 135 de aplicacion, otros modulos 136 de programa y datos 137 de programa. Un grupo particular de programas de aplicacion se llaman aplicaciones de negocio. Estas se dirigen a la gestion de empresas incluyendo - pero sin limitacion - tratar el libro de contabilidad general, inventario, salarios, clientes, ventas, compras, informes financieros y cualquier otro dato relevante para un negocio.

El ordenador 110 tambien puede incluir otro medio de almacenamiento informatico extrafble/no extrafble y volatil/no volatil. A modo de ejemplo unicamente, la Figura 1 ilustra una unidad 141 de disco duro que lee de o escribe a medio magnetico no extrafble y no volatil, una unidad 151 de disco magnetico que lee de o escribe a un disco 152 magnetico extrafble y no volatil, y una unidad 155 de disco optico que lee de o escribe a un disco 156 optico extrafble y no volatil tal como un CD ROM u otro medio optico. Otro medio de almacenamiento informatico extrafble/no extrafble y volatil/no volatil que puede usarse en el entorno de operacion ilustrativo incluye, pero sin limitacion, casetes de cinta magnetica, tarjetas de memoria flash, discos versatiles digitales, cinta de video digital, RAM de estado solido, ROM de estado solido y similares. La unidad 141 de disco duro se conecta habitualmente al bus 121 de sistema a traves de a interfaz de memoria no extrafble tal como la interfaz 140, y la unidad 151 de disco magnetico y unidad 155 de disco optico se conectan habitualmente al bus 121 de sistema mediante una interfaz de memoria eXtrafble, tal como la interfaz 150.

Las unidades de disco y sus medios de almacenamiento informatico asociados analizados anteriormente e ilustrados en la Figura 1, proporcionan almacenamiento de instrucciones legibles por ordenador, estructuras de datos, modulos de programa y otros datos para el ordenador 110. En la Figura 1, por ejemplo, la unidad 141 de disco duro se ilustra como que almacena el sistema 144 operativo, programas 145 de aplicacion, otros modulos 146 de programa y datos 147 de programa. Observese que estos componentes pueden o bien ser los mismos que o diferentes del sistema 134 operativo, programas 135 de aplicacion, otros modulos 136 de programa y datos 137 de programa. Se proporcionan diferentes numeros al sistema 144 operativo, programas 145 de aplicacion, otros modulos 146 de programa y datos 147 de programa en este punto para ilustrar que, como mmimo, son copias diferentes.

Un usuario puede introducir ordenes e informacion en el ordenador 110 a traves de dispositivos de entrada tal como un teclado 162, un microfono 163 y un dispositivo 161 apuntador, tal como un raton, bola de mando o panel tactil. Otros dispositivos de entrada (no mostrados) pueden incluir una palanca de mandos, control de juegos, antena parabolica, escaner o similar. Estos y otros dispositivos de entrada se conectan a menudo a la unidad 120 de procesamiento a traves de una interfaz 160 de entrada de usuario que se acopla al bus de sistema, pero pueden conectarse mediante otra interfaz y estructuras de bus, tal como un puerto paralelo, puerto de juegos o un bus serial universal (USB). Los dispositivos de entrada se usan para la creacion, modificacion y borrado de datos. Dispositivos de entrada tambien pueden usarse para el control (inicio y parada) de los programas de aplicacion y funciones particulares en el presente documento. Las funciones incluyen formularios de apertura (muestra) y cierre de los formularios. Un monitor 191 u otro tipo de dispositivo de visualizacion tambien se conecta al bus 121 de sistema a traves de una interfaz, tal como una interfaz 190 de video. Ademas del monitor, los ordenadores tambien pueden

5

10

15

20

25

30

35

40

45

50

55

incluir otros dispositivos de salida perifericos tal como altavoces 197 e impresora 196, que puede conectarse a traves de una interfaz 195 periferica de salida. El monitor u otro dispositivo de visualizacion se usa para mostrar (presentar) formularios.

El ordenador 110 puede operar en un entorno en red usando conexiones logicas a uno o mas ordenadores remotos, tal como un ordenador 180 remoto. El ordenador 180 remoto puede ser un ordenador personal, un dispositivo de mano, un servidor, un encaminador, un PC de red, un dispositivo de par u otro nodo de red comun, y habitualmente incluye muchos o todos los elementos descritos anteriormente en relacion al ordenador 110. Las conexiones logicas representadas en la Figura 1 incluyen una red 171 de area local (LAN) y una red 173 de area extensa (WAN), pero tambien pueden incluir otras redes. Tales entornos de red son comunes en oficinas, redes informaticas de empresas, intranets y la Internet.

Cuando se usa en un entorno de interconexion de red LAN, el ordenador 110 se conecta a la LAN 171 a traves de una interfaz de red o adaptador 170. Cuando se usa en un entorno de interconexion de red WAN, el ordenador 110 habitualmente incluye un modem 172 u otro medio de establecimiento de comunicaciones a traves de la WAN 173, tal como internet. El modem 172, que puede ser interno o externo, puede conectarse al bus 121 de sistema a traves de la interfaz 160 de entrada de usuario, u otro mecanismo apropiado. En un entorno en red, modulos de programa representados con relacion al ordenador 110, o porciones de los mismos, pueden almacenarse en el dispositivo de almacenamiento de memoria remoto. A modo de ejemplo, y no como limitacion, la Figura 1 ilustra programas 185 de aplicacion remotos como que residen en el ordenador 180 remoto. Se apreciara que las conexiones de red mostradas son ilustrativas y pueden usarse otros medios de establecimiento de un enlace de comunicaciones entre los ordenadores.

La Figura 2 es un diagrama de bloques de un dispositivo 200 movil, que es un entorno informatico ilustrativo alternativo. El dispositivo 200 movil incluye un microprocesador 202, memoria 204, componentes 206 de entrada/salida (I/O) y una interfaz 208 de comunicacion de comunicacion con ordenadores remotos u otros dispositivos moviles. En una realizacion, los componentes anteriormente mencionados se acoplan para comunicacion entre sf a traves de un bus 210 adecuado.

La memoria 204 se implementa como memoria electronica no volatil tal como memoria de acceso aleatorio (RAM) con un modulo de respaldo de batena (no mostrado) de tal forma que la informacion almacenada en la memoria 204 no se pierde cuando se corta la potencia general al dispositivo 200 movil. Una porcion de la memoria 204 se asigna preferentemente como memoria direccionable para ejecucion de programa, mientras otra porcion de la memoria 204 se usa preferentemente para almacenamiento, tal como para simular almacenamiento en una unidad de disco.

La memoria 204 incluye un sistema 212 operativo, programas 214 de aplicacion asf como un almacen 216 de objetos. Durante operacion, el sistema 212 operativo se ejecuta preferentemente mediante el procesador 202 de la memoria 204. El sistema 212 operativo, en una realizacion preferida, es un sistema operativo de la marca WINDOWS ® CE comercialmente disponible en Microsoft Corporation. El sistema 212 operativo se disena preferentemente para dispositivos moviles e implementa caractensticas de base de datos que pueden utilizarse mediante las aplicaciones 214 a traves de un conjunto de interfaces de programacion de aplicacion y procedimientos expuestos. Los objetos en el almacen 216 de objetos se mantienen mediante las aplicaciones 214 y sistema 212 operativo, al menos parcialmente en respuesta a llamadas a las interfaces de programacion de aplicacion y procedimientos expuestos.

La interfaz 208 de comunicacion representa numerosos dispositivos y tecnologfas que permiten que el dispositivo 200 movil envfe y reciba informacion. Los dispositivos incluyen modems por cable e inalambricos, receptores por satelite y sintonizadores de radiodifusion por nombrar algunos. El dispositivo 200 movil tambien puede conectarse directamente a un ordenador para intercambiar datos con el mismo. En tales casos, la interfaz 208 de comunicacion puede ser un transceptor de infrarrojos o una conexion de comunicacion en serie o paralelo, todas las cuales son capaces de transmitir informacion de difusion en continuo.

Los componentes 206 de entrada/salida incluyen una diversidad de dispositivos de entrada tal como una pantalla tactil, botones, ruedas y un microfono asf como una diversidad de dispositivos de salida que incluyen un generador de audio, un dispositivo de vibracion y una pantalla. Los dispositivos listados anteriormente son a modo de ejemplo y no necesitan estar todos presentes en el dispositivo 200 movil. Ademas, pueden adjuntarse otros dispositivos de entrada/salida a o encontrarse con el dispositivo 200 movil.

ARQUITECTURA DE UI CORRELACIONADA Y POR CAPAS Y PROCEDIMIENTO

Como se ha descrito anteriormente, aplicaciones que presentan informacion deben proporcionar a usuarios con una experiencia tan rica como sea posible en plataformas (por ejemplo objetivos de visualizacion) de muchas varias capacidades. Estas plataformas abarcan desde clientes enriquecidos que se ejecutan en el escritorio del usuario, a clientes Web que se ejecutan en el navegador del usuario, a PDA, a dispositivos basados en telefoma e incluso interfaces de voz. Tambien son posibles otras plataformas. De acuerdo con realizaciones de la presente invencion, se emplea un esquema que define perceptivamente como los tipos de datos se correlacionan con controles nativos en la plataforma en cuestion.

5

10

15

20

25

30

35

40

45

50

55

Un arquitecto de negocio usa su conocimiento en ingeniena de negocios para resolver problemas a sus clientes. Sin embargo, esta persona habitualmente no es un desarrollador de programa informatico e idealmente se protege de las particularidades del desarrollo de programas. La presente invencion proporciona procedimientos y aparato que permiten que un arquitecto de negocio (usuario) se centre en la logica de negocio de una aplicacion y no en como se presentan los datos en una plataforma dada. La invencion presentada permite que los desarrolladores de aplicaciones, a base de un modelo del negocio, obtengan la interfaz de usuario que se dirige a multiples objetivos de visualizacion y que explota las capacidades tecnologicas de cada objetivo de visualizacion.

Esto se consigue mediante una definicion de UI por capas que permite que el desarrollador centre el esfuerzo intelectual a la capa que tiene el nivel de abstraccion "correcto". Se captura y reutilizan patrones en cada nivel de abstraccion. Mapas - desde niveles superiores de abstraccion a niveles mas espedficos - capturan patrones en el procedimiento de correlacion, pero tambien permiten al desarrollador de aplicacion afinar los resultados. La presente invencion usa estos mapas, junto con controles, tipos de formularios logicos y comportamientos, para correlacionar el modelo de negocio con modelos ffsicos espedficos de objetivo de visualizacion.

En los procedimientos de la presente invencion, el modelo de negocio es el maestro. El trabajo intelectual puesto en el modelo de negocio se preserva y usa como base de generacion de la interfaz de usuario. El modelo puede describirse en Lenguaje de Modelizacion Unificado (UML), diagrama de recursos de empresa (ER) o cualquier otro lenguaje de modelizacion grafico o no grafico. Modelos de negocio tambien pueden encontrarse en programas orientados a objeto clasicos, en bases de datos relacionales o en otros formatos. Como se describe a continuacion, en algunas realizaciones ilustrativas de la presente invencion, el modelo de negocio es una jerarqrna de clases de entidades con propiedades.

En realizaciones de la presente invencion, el modelo de negocio se correlaciona con un modelo intermedio de la interfaz de usuario que es independiente del objetivo de visualizacion. El modelo de UI se describe en un alto nivel de abstraccion que permite al desarrollador de aplicacion ver y modificar la misma sin la necesidad de ningun conocimiento tecnico del objetivo de visualizacion final. Puede anadirse codigo al modelo de UI que trabajara para todos los objetivos de visualizacion. Patrones en los modelos de UI se capturan y pueden reutilizarse, resultando en una UI homogenea. Los componentes basicos usados para describir el modelo de UI tambien pueden extenderse.

Como se describiran a continuacion en mayor detalle, en algunas realizaciones de la invencion las entidades se correlacionan con un modelo de UI llamado "la UI logica" que incluye un formulario logico con controles logicos. Las entidades y propiedades se correlacionan con formularios logicos y controles logicos respectivamente en tiempo de diseno. En tiempo de ejecucion los formularios logicos y datos de controles logicos se unen a las entidades y propiedades. Los patrones en los formularios se llaman tipos de formulario. Los formularios y controles se usan mediante, pero no son una a parte de, el motor de correlacion de cliente principal. El cliente principal es la parte independiente del objetivo de visualizacion del cliente de UI. En realizaciones de la invencion, la lista de controles logicos y tipos de formulario puede extenderse. A continuacion tambien se proporciona una descripcion adicional de estos aspectos de la invencion.

En algunas realizaciones de la invencion, el modelo de UI se correlaciona con un lenguaje de marcas espedfico de objetivo de visualizacion tal como el lenguaje de paginas de servidor activo (ASP.NET), el lenguaje de marcas inalambrico (WML), el lenguaje de marcas de hipertexto (HTML), etc. El modelo de UI tambien puede correlacionarse con otras tecnologfas de visualizacion (por ejemplo, Win32, WinForms, PocketPC). En un ejemplo de realizacion particular de la invencion, los formularios logicos se correlacionan con un objetivo de visualizacion de Cliente Web, un objetivo de visualizacion de Cliente de WinForms, etc., y pueden anadirse nuevos objetivos de visualizacion dinamicamente.

De acuerdo con realizaciones de la invencion, las correlaciones se basan en mapas declarativos que son abiertos y modificables. Patrones en la UI se capturan en los mapas. Los mapas pueden hacerse a base de varias condiciones lo que resulta en un nivel alto de flexibilidad. Los diferentes modelos pueden modificarse manualmente (incluyendo a traves de codigo) despues de que se han correlacionado. Esto proporciona al desarrollador el nivel final de flexibilidad. La naturaleza dinamica de los mapas permite el desarrollo y uso de nuevos elementos de UI tal como controles. Los nuevos controles simplemente se habilitan en un formulario, correlacionando propiedades a los nuevos controles. Los nuevos controles deben cumplir con un cierto contrato - en esta realizacion los nuevos controles deben heredar de una clase base especificada. En tiempo de ejecucion, el formulario logico se une a las entidades y el objetivo de visualizacion se une a la capa logica. Esto permite que toda funcionalidad que es comun entre los objetivos de visualizacion (seguridad, personalizacion, logica dentro de formularios) se implemente una vez en la capa logica y use en muchos casos.

TIPOS DE FORMULARIO

La presente invencion utiliza los conceptos de formularios logicos y tipos de formulario logico para proporcionar un nuevo procedimiento de construccion de interfaces de usuario de formulario (formularios) para negocios y otras aplicaciones. Mientras en realizaciones ilustrativas o implementaciones de la invencion se usan formularios logicos y tipos de formulario logico, no se requiere el uso de la capa logica en todas las realizaciones. Por lo tanto, la presente invencion se aplica al uso de tipos de formulario para crear formularios en general. Aplicaciones de negocio de hoy

5

10

15

20

25

30

35

40

45

50

55

habitualmente que consiste en un gran numero de formularios que a menudo se encuadran dentro de unas pocas categonas o siguen un patron similar. El numero de categonas es habitualmente entre dos y veinte, pero pueden definirse mas. Los tipos de formulario de la presente invencion facilitan interfaces de usuario controladas por modelos preservando y actuando en el modelo de negocio o de aplicacion o ambos en tiempo de diseno y en tiempo de ejecucion. Esto proporciona un nivel alto de abstraccion a un desarrollador de software. Ademas, el uso de tipos de formulario de acuerdo con la presente invencion garantiza la reutilizacion (una disposicion se usa muchas veces), un conjunto mucho mas homogeneo de interfaces de usuario de formulario ya que todos los formularios se encuadran dentro de unos pocos tipos distintos y formularios que son mas faciles de mantener (la disposicion del tipo puede cambiarse sin cambiar el formulario y puede aplicarse un tipo diferente sin cambiar el formulario). La invencion garantiza que desarrolladores de aplicaciones tienen control completo, a traves de multiples objetivos de visualizacion, del aspecto y comportamiento de la aplicacion y como se efectua la navegacion dentro de la aplicacion. Ejemplos de objetivos de visualizacion incluyen cada uno de los multiples tipos de sistemas operativos actuales y futuros, asf como cada uno de los muchos dispositivos moviles disponibles o futuros. Como otro ejemplo, cada tecnologfa de presentacion en un sistema operativo particular tambien puede ser un objetivo de visualizacion.

Usando lo conceptos de la presente invencion, un formulario logico contiene controles logicos independientes de objetivo de visualizacion, que hace el formulario logico independiente de los propios objetivos de visualizacion. Un formulario logico se refiere a un tipo de formulario logico que define el patron que el formulario logico debe seguir. El tipo de formulario logico al que se hace referencia mediante un formulario logico puede seleccionarse desde multiples diferentes tipos de formulario logico para establecer rapidamente el aspecto y contendidos del formulario logico. En realizaciones de la presente invencion, el tipo de formulario logico son modelos que, cuando se combinan con un negocio u otro modelo de aplicacion, resulta en la generacion de un formulario logico.

El tipo de formulario logico expone el esquema (que describe la estructura del formulario, que elementos puede contener, etc.) al que el formulario debe ajustarse, los Mapas (o Reglas) que correlacionan (automatica o manualmente a traves de un desarrollador de aplicacion) el modelo de negocio con el modelo logico y desde este con el modelo ffsico. Ademas, el tipo de formulario puede contener codigo que modifica el comportamiento dinamico del formulario (logico). Por lo tanto, tipos de formulario exponen informacion de estilo y disposicion, y otros tipos de informacion espedfica a un objetivo de visualizacion. Sin embargo, ya que tambien especifican reglas para el formulario logico y sus contenidos tienen un rol mucho mayor. Ciertos aspectos de los tipos de formulario de la presente invencion se introducen como se indica a continuacion:

Diferentes Tipos de formulario

Como se ha mencionado, en un uso tfpico de la presente invencion, se proporcionan multiples tipos de formulario diferentes para su uso por un desarrollador de aplicacion en la creacion de formularios. Por ejemplo, en una realizacion de ejemplo, tipos de formulario podnan incluir un tipo de formulario de dialogo, un tipo de formulario de Tarjeta o Vista de Tarjeta, un tipo de formulario de Vista de Lista, un tipo de formulario de Vista General de Entidad y un tipo de formulario de Centro de Actividad. Estos tipos de formulario corresponden a diferentes categonas de formularios tfpicas usadas en una aplicacion de negocio en un ejemplo. Por lo tanto, proporcionar los multiples tipos de formulario permite a desarrolladores de aplicaciones construir todos los formularios que forman una aplicacion de negocio de estado de la tecnica. Como entenderan los expertos en la materia, estos tipos de formulario particulares son simplemente un ejemplo y la presente invencion no se limita a ningun tipo de formulario particular o a ningun numero particular de tipos de formulario.

Disposicion de tipo de formulario

Los contenidos y estructura de la informacion de disposicion pueden ser diferentes para cada tipo de formulario. Ademas, la informacion de disposicion puede ser espedfica del objetivo de visualizacion. Por ejemplo, la informacion de disposicion para el tipo de formulario de Centro de Actividad podna tener soporte para Temas/Apariencias/Estilos y Paginas Maestras que se usaran en el objetivo de visualizacion HTML (es decir, red informatica mundial o Internet) para la visualizacion del formulario en una plataforma de sistema operativo particular. Esto proporciona al desarrollador de negocio la libertar para innovar en diferentes objetivos de visualizacion y retocar la interfaz de usuario de formulario tanto como sea necesario.

Conectable y Extensible

Tipos de formulario ofrecen flexibilidad total y extensibilidad ya que un vendedor de software independiente (ISV) puede modificar o extender los mismos y crear nuevos tipos de formulario, cambiando de este modo el aspecto y comportamiento de toda la aplicacion.

Haciendo referencia ahora a las Figuras 3-1 y 3-2, se muestran ilustraciones diagramaticas de un formulario logico de Orden de Ventas creado usando un tipo de formulario de Tarjeta de acuerdo con una realizacion de ejemplo de la presente invencion. En este ejemplo, el formulario logico de Orden de Ventas contiene un conjunto de controles logicos agrupados en tres diferentes grupos de controles logicos. Como se describira adicionalmente a continuacion, el tipo de formulario de Tarjeta define como y donde apareceran los controles en los formularios ffsicos en diferentes objetivos de visualizacion. Las Figuras 3-1 y 3-2 ilustran la misma informacion, incluyendo la Figura 3-2 flechas que

5

10

15

20

25

30

35

40

45

50

55

ilustran relaciones y ongenes de informacion entre el tipo de formulario logico y el formulario logico, y la generacion de un formulario ffsico a partir del formulario logico.

Las Figuras 3-1 y 3-2 en forma de diagrama ilustran una instancia 305 de formulario generada usando un tipo 300 de formulario. En un cliente 310 principal, la instancia 305 de formulario es el formulario 306 logico (mostrado como un modelo conceptual de un formulario) y el tipo 300 de formulario es un tipo 301 de formulario logico. En un objetivo 320 de visualizacion, el formulario 305 es un formulario 370 presentado creado usando el formulario 306 logico, y finalmente a partir del tipo 301 de formulario logico. El formulario 370 presentado es una implementacion particular, pero pueden conseguirse muchas otras implementaciones o presentaciones. El formulario 370 presentado tambien puede denominarse como un formulario ffsico.

El tipo 300 de formulario incluye dos partes, un esquema 330 que define que tiene que incluirse en formularios particulares usando el tipo de formulario, y una disposicion 331 que incluye controles que especifican como debena presentarse o dibujarse el formulario en un objetivo de visualizacion espedfico. Un tipo de formulario tambien puede incluir una clase detras de codigo. Teniendo diferentes disposiciones que pueden usarse por un tipo de formulario, los formularios creados usando el tipo de formulario pueden personalizarse a diferentes objetivos de visualizacion (por ejemplo, pantallas de telefonos moviles, pantallas de asistentes digitales personales, monitores de ordenadores personales, etc.). Con el tipo 300 de formulario representando un patron capturado a usar en multiples formularios, pueden generarse multiples instancias 305 de formularios usando el tipo 300 de formulario.

Considerese para este ejemplo un procedimiento a traves del cual puede ir un desarrollador para crear un formulario para una entidad de Orden de Ventas o modelo de objeto (es decir, el modelo de negocio o aplicacion). En primer lugar, el desarrollador podna mirar para ver entre que clases de formularios puede elegir. Seleccionar el tipo de formulario "Tarjeta", como se muestra en 325 en las Figuras 3-1 y 3-2, llama o designa el Esquema 330 de Tarjeta como se representa mediante la flecha 326 en la Figura 3-2.

Cuando el desarrollador especifica un tipo de formulario particular y esquema asociado, en algunas realizaciones esta eligiendo incluir en el formulario la informacion o campos impuestos por el esquema, con metadatos del negocio del usuario u otro modelo que rellena los valores de campos. Por ejemplo, seleccionado el tipo 301 de formulario de Tarjeta (y Esquema 330 de Tarjeta asociado), el formulario 306 logico incluira un Area 336 de Contenido que corresponde al Area 335 de Contenido definida en el esquema 330. El origen del Area 336 de Contenido que corresponde al Area 335 de Contenido se representa mediante la flecha 337 en la Figura 3-2. Analogamente, porque el esquema 330 del tipo de formulario de Tarjeta incluye un Area 340 de Parte de UI, un Area 345 de Parte de UI de Entidad Relacionada y un Area 350 de Accion, el formulario 306 logico incluye estas areas o campos tambien como se muestra en 341, 346 y 351. De nuevo, los ongenes de estos campos se representan en forma de diagrama mediante las flechas 342, 347 y 352.

Como se ha mencionado anteriormente, cada tipo de formulario tambien incluye al menos una disposicion 331 (normalmente una por objetivo de visualizacion) que incluye controles que especifican como debena presentarse o dibujarse el formulario en un objetivo de visualizacion espedfico. Como se muestra en forma de diagrama en las Figuras 3-1 y 3-2, la disposicion para el tipo de formulario de Tarjeta incluye controles que provocan que un objetivo 320 de visualizacion incluya un Area 339 de Contenido, un Area 344 de Parte de UI, un Area 349 de parte de UI de Entidad Relacionada y una Area 354 de Accion. Las flechas 338, 343, 348 y 353 ilustran la correlacion de estas areas en la disposicion de tarjeta con sus correspondientes areas en el esquema de Tarjeta. El formulario 306 logico, que se genera usando el tipo de formulario logico seleccionado y metadatos del modelo de aplicacion (en este ejemplo una entidad de Orden de Ventas), se presenta como un formulario ffsico 370 en el objetivo 320 de visualizacion. Este procedimiento se ilustra en la Figura 3-2 usando las flechas 361 y 362.

MODELOS Y MAPAS

Muchos sistemas de informacion usan modelos. Ejemplos de modelos son: diagramas de objeto, esquemas de Lenguaje de Marcas Extensible (XML), definiciones de bases de datos y definiciones de formularios. Un modelo a menudo se define como un conjunto de objetos, cada uno de los cuales tiene propiedades, composiciones y asociaciones. En UI de negocios, las jerarqrnas de control usadas para presentar los formularios pueden considerarse como modelos, tal como arboles de control de Windows y modelos de objetos de Lenguaje de Marcas de Hipertexto (HTML). Tambien, puede usarse sintaxis tal como Lenguaje de Modelizacion Unificado (UML) para definir un modelo (por ejemplo, las definiciones de clases). En un marco de ejemplo usado para ilustrar los procedimientos de la presente invencion, las aplicaciones se modelan usando entidades de negocio. Por lo tanto, el modelo de negocio que consiste en estos objetos de negocio llamados entidades, relaciones entre entidades y propiedades en las entidades. Vease para un ejemplo de un modelo 380 simple las entidades 381, 382, 383 y 384 mostradas en la Figura 4-1. Las entidades tienen propiedades (veasen por ejemplo las propiedades 385 de la entidad 381) y relaciones con otras entidades (vease por ejemplo la relacion 386 entre las entidades 381 y 384).

Cuando un modelo se transforma en otro modelo, se usa un mapa explfcitamente o en ocasiones implfcitamente. Los mapas describen las relaciones entre modelos. Algunos ejemplos incluyen: Transformacion de Lenguaje de Hojas de Estilo Extensible (XSLT) que se concibe para correlacionar XML con XML; controles que se usan para presentar un modelo de objeto en una superficie de dispositivo espedfico; correlaciones de ordenes desde una

5

10

15

20

25

30

35

40

45

50

55

60

aplicacion a otra (porque ordenes en diferentes aplicaciones pueden tener formatos diferentes); y herramientas de Ingeniena de Software Asistida por Ordenador (CASE) que correlacionan UML con definiciones de clases.

En aplicaciones de negocio actuales, los mapas se programan en su mayona usando correlaciones de un objeto a la vez, significando que las correlaciones se codifican como declaraciones de "conmutacion" en codigo, que toman un objeto particular como entrada y devuelven otro objeto. Por lo tanto, aplicaciones de negocio convencionales habitualmente usan mapas imperativos, mapas escritos en el codigo de un lenguaje de programacion ffpico. Usando modelo a la vez de acuerdo con la presente invencion, se presenta que la productividad puede mejorarse por un orden de magnitud. Ademas de la ganancia de productividad, existe una ganancia mental en la percepcion del problema de generacion de UI como una correlacion de modelos con otros modelos mapas de uso. Ademas, otro beneficio es el mayor nivel de abstraccion encontrado en los mapas definidos declarativamente de la presente invencion. La presente invencion permite que los mapas sean expffcitos y declarativos. En la presente invencion, los mapas pueden ser o bien declarativos o bien imperativos (debido al hecho de que uno puede invalidar la correlacion en codigo).

La naturaleza expffcita de los mapas significa que los mapas son externos al motor de generacion usado para hacer la correlacion o presentacion, y que los mapas son en sf mismos modelos. Dicho de otra forma, la naturaleza expffcita de los mapas significa que se definen de forma separada de los controles y los formularios. Convencionalmente, esta correlacion se ha hecho impffcitamente dentro del codigo de controles o codigo de formularios.

La naturaleza declarativa de los mapas significa que los mapas no son imperativos (codificados en un lenguaje de programacion ffpico). Como se usa en el presente documento, la frase "definido declarativamente" significa que los mapas no solo se definen en codigo como ha sido el caso convencionalmente, sino que se definen en un formato que permite que los mapas se cambien facilmente. Ejemplos de un formato definido declarativamente incluyen, pero no se limitan a, documentos XML, ficheros separados por comas, Mapas de BizTalk (correlacionando un esquema de datos con otro) y Mapas de Entidad de MBF (correlacionando un modelo de objeto con un esquema de una base de datos). Pueden usarse una amplia variedad de formatos de correlacion declarativos de acuerdo con la presente invencion, y que formato se elige no es de particular importancia. Es importante que el mapa declarativo tenga un conjunto limitado de posibilidades, haciendo por lo tanto mas facil proporcionar una herramienta de diseno intuitiva para definir el mapa. En contraste, un mapa imperativo (usando codigo) tiene casi ilimitadas posibilidades a traves del lenguaje de programacion y por lo tanto es extremadamente diffcil crear una herramienta de diseno intuitiva. En su lugar, se requieren conocimientos de programacion para crear la misma.

Debe observarse que en realizaciones de la presente invencion que usan mapas declarativos, los mapas no necesitan ser unicamente declarativos. En instancias en las que es necesario crear un mapa que es demasiado complejo definir declarativamente, pueden incluirse aspectos de correlacion imperativa en el de otra manera mapa declarativo. Por ejemplo, pueden crearse funciones complejas e incluirse en el mapa. Un ejemplo podna ser que si una Direccion de Facturacion y Direccion de Envfo son casi la misma, entonces unicamente se muestra la Direccion de Facturacion en el Formulario. El algoritmo de determinacion de si dos direcciones son casi la misma podna ser una funcion definida impffcitamente usada en el Mapa.

La presente invencion proporciona abstracciones de programacion y una arquitectura de perspectiva adecuada para el desarrollo y despliegue de aplicaciones de negocio a base de una arquitectura distribuida y orientada a servicio. El marco afsla la logica de negocio escrita a estas abstracciones de cambios a tecnologfas subyacentes, preservando el activo cntico de un equipo de desarrollo de aplicacion de negocio. La presente invencion extiende enfoques a desarrollo controlado por modelo, moviendose de un modelo de tiempo de diseno con generacion de codigo a tener "servicios de aplicacion conocedor de modelo" verdaderos, que pueden interpretar el modelo de negocio en tiempo de ejecucion.

UI CONTROLADA POR MODELO A BASE DE MAPAS

Tener el modelo de aplicacion es una caractenstica importante cuando se genera la UI para una aplicacion de negocio construida en realizaciones de la presente invencion. Una gran mayona de la UI puede generarse solamente a base del modelo de la logica de negocio y mapas. Cuando un desarrollador de aplicacion ha modelado una nueva entidad, la UI se obtiene a partir de esta. Esto se ilustra en forma de diagrama en la Figura 4-2 que ilustra el modelo de negocio 380 que se correlaciona (como se muestra en 388) con un modelo de UI 390. La flecha 388 representa el procedimiento de correlacion, asf como un motor de correlacion configurado adecuadamente que usa un mapa para llevar a cabo el procedimiento de correlacion.

Aunque esta correlacion puede conseguirse usando tecnicas de codificacion tradicionales, la correlacion no es tan sencilla si deben cumplirse ciertos desaffos. El desaffo es que cuando se crean y usan nuevos tipos de propiedades en una entidad, la transformacion codificada podna no saber como tratar el nuevo tipo y la transformacion por lo tanto tiene que modificarse y recompilarse. Otro desaffo es tratar controles desarrollados recientemente que unicamente seran de valor si se incluyen en la transformacion - de nuevo esto resulta en la preprogramacion de la transformacion. Las tecnicas de correlacion de la presente invencion son capaces de cumplir estos desaffos. Observese que cualquier modificacion de la UI en tiempo de ejecucion (a traves de codigo) tambien puede considerarse una correlacion. La plataforma usada en la presente invencion expone un modelo de UI por capas y

5

10

15

20

25

30

35

40

45

50

55

usa mapas para transformar modelos desde una capa a otra. Esto se describe a continuacion en mayor detalle.

Los procedimientos y aparato de la presente invencion proporcionan una forma de calcular como presentar informacion de negocio al usuario en una plataforma dada. La invencion se construye sobre la correlacion de modelos con otros modelos, trabajando desde un modelo abstracto (describiendo las entidades de negocio con las que interactuar) hasta un modelo concreto (especificando exactamente que control espedfico del dispositivo debena usarse para presentar la informacion de negocio). En general, esta correlacion puede implicar cualquier numero de etapas.

Por ejemplo, considerese el diagrama 400 de bloques mostrado en la Figura 5-1 que ilustra un proceso de correlacion desde un modelo 405 maestro a un modelo 425 especializado usando dos etapas de correlacion expffcitas y declarativas. El modelo 405 maestro (es decir, "modelo A") puede ser, por ejemplo, una base de datos, tabla, entidad, objeto u otros tipos de modelos en un dominio de problema espedfico a un usuario. El modelo 405 maestro se correlaciona con un modelo 415 intermedio (es decir, "modelo B") con la etapa de correlacion ilustrada en 411 usando un mapa 410 (es decir, "mapa A-B"). El modelo 415 intermedio puede ser un modelo independiente del objetivo de visualizacion que tiene controles logicos, como se describiran a continuacion en mayor detalle. El modelo 415 intermedio se correlaciona a continuacion con un modelo 425 especializado (es decir, "modelo C") con la etapa de correlacion ilustrada en 421 usando un segundo mapa 420 (es decir, "mapa B-C"). El modelo 425 especializado puede ser un modelo espedfico de objetivo de visualizacion que tiene controles ffsicos, como tambien se describira a continuacion en mayor detalle. Las flechas usadas para representar las etapas 411 y 421 de correlacion tambien representan motores de correlacion que se configuran para utilizar los mapas 410 y 420 para implementar las etapas de correlacion.

De acuerdo con algunas realizaciones de la presente invencion, el esquema de correlacion implicado en la determinacion de como permitir que el usuario interactue con informacion de negocio en la plataforma cliente implica al menos tres etapas, como se describe a continuacion y como se muestra en forma de diagrama en el diagrama 450 de bloques de la Figura 5-2. El modelo 455 inicial (vease tambien el modelo 405 maestro mostrado en la Figura 5-1) contiene informacion acerca de las entidades de negocio con las que el usuario debe interactuar. Cada dato de este modelo de aplicacion es de un tipo particular. La primera etapa implica la determinacion de que control logico emplear para un tipo dado (cadena, numero entero, tipo decimal que representa valores monetarios, direcciones que contienen otros valores, etc.) del dato a presentar.

El control logico a usar para el tipo dado se determina usando una correlacion desde tipo de datos en el modelo 455 con control logico en el modelo 465. El procedimiento de correlacion se ilustra en 461, y utiliza un mapa 460 (es decir, el "mapa de tipo de dato a control logico"). Controles logicos tienen varias propiedades utiles. No tienen ninguna dependencia de ningun objetivo de visualizacion espedfico, pero mantienen propiedades que gobiernan el comportamiento de controles ffsicos espedficos de dispositivo. La consulta del control logico se realiza teniendo en cuenta el tipo jerarqrna. Si ningun control logico es espedficamente adecuado para el encapsulado de las propiedades de un tipo espedfico, la busqueda continua con un tipo base, hasta que se encuentra un control logico para tratar el tipo.

Una vez que se ha identificado un control logico a partir del tipo de datos a representar, debe encontrarse el control ffsico usado para realizar realmente la presentacion en la plataforma dada. Estos controles ffsicos se denominan en ocasiones como "adaptadores". Esto se hace usando otra correlacion, produciendo el control ffsico del control logico y el objetivo de visualizacion. El procedimiento de correlacion se ilustra en 471 y usa el mapa 470 (es decir, el "mapa de control de control logico a control ffsico ") para generar el modelo 475 de control ffsico a partir del modelo 465 de control logico.

Cuando el cliente se ejecuta en el objetivo de visualizacion del usuario, el control ffsico se usara para crear instancias de los controles nativos usados para interactuar con el usuario. Esto se hace mediante una tercera correlacion, produciendo un conjunto de controles nativos a partir del control ffsico. Por ejemplo, si el control ffsico fuera un control de direccion, el control ffsico correlacionana con controles nativos para calle, ciudad, pafs. El procedimiento de correlacion se ilustra en 481 y usa el mapa 480 (es decir, el "mapa de control ffsico a control nativo") para generar el modelo 485 de control nativo a partir del modelo 475 de control ffsico. En algunas realizaciones, esto es un mapa imperativo - pero no tiene por que serlo. De nuevo, las flechas 461, 471 y 481 tambien representan el motor o motores de correlacion usados para implementar las funciones de correlacion como se especifica mediante los mapas 460, 470 y 480.

La correlacion descrita anteriormente puede aumentarse con otras correlaciones para conseguir el resultado deseado. Otros factores incluyen el tipo de formulario presentado (tarjeta o vista de lista), el rol de usuario (posiblemente limitando la informacion ofrecida al usuario). El procedimiento de llegada desde el modelo abstracto al modelo concreto es puramente prescriptivo (describiendo las correlaciones implicadas) y se permite flexibilidad siendo capaz de cambiar estas correlaciones.

Como otro ejemplo, la Figura 5-3 ilustra un diagrama 500 de bloques que muestra un procedimiento de correlacion para conseguir desde un nombre del usuario y numero de identificacion (ID) hasta el HTML usado para presentar esta informacion en un navegador. El modelo 505 de negocio maestro inicial es una entidad (u objeto) o clase de

5

10

15

20

25

30

35

40

45

50

55

entidades (o clase de objetos) que tiene el nombre del cliente e ID como propiedades. Las propiedades de "Nombre" e "ID" del modelo 505 son de tipos "Cadena" y "Numero", respectivamente. El modelo 505 se correlaciona con una capa de control logico del modelo 515 usando un mapa 510 prescriptivo. El procedimiento de correlacion se representa en 511. En este ejemplo, los datos tipo "Cadena" se correlacionan con un control logico de "Caja de Texto", mientras los datos tipo "Numero" se correlaciona con un control logico de "Caja de Numeros".

A continuacion, el modelo 515 de control logico se correlaciona con un modelo 525 HTML usando el mapa 520. El procedimiento de correlacion se representa en 521. En este ejemplo, el modelo 525 es un modelo de control ffsico en forma de un modelo de HTML. Por lo tanto, el mapa 520 correlaciona los controles logicos del modelo 515 con etiquetas de HTML o elementos en el modelo 525. El modelo 525 de HTML se usa continuacion para presentar la informacion desde el modelo 505 en un navegador. De nuevo, las flechas usadas para representar las etapas 511 y 521 de correlacion tambien representan motores de correlacion configurados adecuadamente que utilizan los mapas 510 y 520 para implementar el procedimiento de correlacion.

La Figura 5-4 ilustra un aspecto adicional de realizaciones de la presente invencion en el que pueden relacionarse varios tipos de propiedades diferentes con los mismos controles finales, asf que el numero de controles requeridos no aumenta necesariamente cuando el numero de tipos de propiedades aumenta. Como se muestra en el diagrama 550 de bloques de la Figura 5, un modelo 560 de negocio que tiene propiedades 561 de diferentes tipos se correlaciona con un modelo 580 de objetivo de visualizacion usando los mapas 555. Similar a ejemplos anteriormente analizados, el modelo 560 se correlaciona con un modelo 570 de capa logica que tiene controles 571 logicos. El motor de correlacion y procedimiento de correlacion, que usan el mapa 565, se ilustran en 566. El mapa 565 correlaciona los tipos de dato ("Tipo de ID", "Cadena" y "Flotante") de las propiedades 561 del modelo 560 con controles logicos ("Numero" y "Cadena"). En este caso, tanto los tipos de dato "Tipo de ID" como "Flotante" se correlacionan con el tipo de control logico de "Numero", mientras el tipo de dato de "Cadena" se correlaciona con el tipo de control logico de "Cadena".

A continuacion, modelo 570 de capa logica se correlaciona con modelo 580 de objetivo de visualizacion que tiene controles 581 ffsicos espedficos para un objetivo de visualizacion particular. El modelo 570 se correlaciona con el modelo 580 usando el mapa 575, con el procedimiento y motor de correlacion representado en 576. El mapa 575 correlaciona los tipos de control logico "Numero" y "Cadena" del modelo 570 con el tipo de control ffsico "Caja de Texto" del modelo 580, ilustrando de nuevo que varios tipos diferentes de un modelo particular pueden relacionarse con un unico tipo en otro modelo. Por extension, varios tipos diferentes de propiedades de un modelo de negocio pueden relacionarse con el mismo control final (por ejemplo "ffsico").

Experiencia de Desarrollador

Cuando un desarrollador crea una nueva entidad, que se construye unicamente a partir de tipos existentes, tambien se construye una UI por defecto a traves de los mapas. Si la UI por defecto no ofrece la experiencia de usuario deseada, el desarrollador puede elegir:

• Modificar el modelo de negocio para reflejar los requisitos. Por ejemplo, en algunas realizaciones si la ordenacion de una secuencia de propiedades esta mal, digamos que el ID debeffa visualizarse antes del Nombre, entonces la entidad podffa editarse. En otras realizaciones, la ordenacion de propiedades reside en un "comportamiento" externo. Sin embargo, una agrupacion ordenada de propiedades puede "anadirse" a la entidad - y esto puede usarse para hacerlo. Por lo tanto, en estas realizaciones, el mejor enfoque podffa ser cambiar el orden en el agrupamiento.

• Modificar el modelo de formulario logico generado. Conmutar el Nombre y ID tambien podffa hacerse en el formulario. Esto potencialmente presenta algunos desaffos de mantenimiento posteriormente si se cambia la logica de negocio, tal como hace el cambio en la logica de negocio que sobrescribe cambios en el formulario. Tambien, puede ser necesario cambiar la logica de negocio en cada formulario.

• Modificar el mapa. Si el ID se correlaciona con un control de Numero pero es mas adecuado un control de Cadena, el mapa es el lugar correcto para hacer el cambio.

Existe un numero de beneficios al cambio del mapa en lugar de la mas tradicional modificacion de modelos. En primer lugar, los cambios pueden tener un ambito mas amplio. Si se cambiase la entrada de mapa usada en el ejemplo anterior, todas las entidades que usan el "Tipo de ID" automaticamente obtendffan la actualizacion. Esto resultaffa en una UI muy consistente, de la que podffa beneficiarse el usuario final.

Otro beneficio se vuelve evidente cuando se mira al mantenimiento y versiones futuras de una aplicacion. Cambiando la forma en que se generan modelos, pero sin cambiar los modelos generados, el modelo maestro puede actualizarse, y en lo sucesivo los modelos dependientes pueden generarse sin ningun riesgo de conflicto. No regenerar en absoluto los formularios podffa resultar en inconsistencias entre entidades y los formularios usados para ver y editar las mismas. Los mapas tambien descomponen la gran tarea de generacion en varias entradas de mapa declarativas pequenas.

Si el desarrollador crea un nuevo tipo de propiedad, tal como "Dinero", esto puede usarse de forma instantanea porque la UI se generara eficientemente si unicamente se anade una unica entrada de mapa. En este ejemplo la

5

10

15

20

25

30

35

40

45

50

55

nueva propiedad "Dinero" podna correlacionarse a un control de "Numero". El desarrollador podna tambien elegir explotar la informacion de metadatas anadida, y crea un control de "Dinero", y tiene la propiedad correlacionada al nuevo control. La tecnologfa de correlacion hace que ambos escenarios sean validos.

El Lenguaje de Correlacion

La correlacion usa un lenguaje de correlacion declarativo simple que es extensible. La correlacion toma uno o mas testigos como entrada y devuelve uno o mas testigos como salida. Dado un tipo de propiedad como entrada, uno o mas controles logicos pueden especificarse como salida. Tambien debe ser posible especificar la salida como nula. Por ejemplo, el "Tipo de ID" podna ser un campo generado por ordenador, que el usuario no puede editar o ver, en cuyo caso el tipo se correlaciona a nada. Tambien, la correlacion puede controlar parametros en la salida. Por ejemplo, la propiedad "Cadena" podna resultar en una Caja de Texto mas ancha en comparacion con las otras Cajas de Texto en el formulario.

Para tratar el problema de alcance abordado antes, se necesita una condicion de ambito - en el formulario de ejemplo anteriormente analizado, "Tipos de ID" se correlacionan con "Controles de ID", pero en todos los demas formularios se usa un control "Numero". Tambien pueden usarse otros parametros como ambito, incluyendo la entidad de negocio, el estereotipo de entidad, el tipo de formulario, etc. Existen otras condiciones que senan beneficiosas tener en consideracion cuando debe realizarse una correlacion. Un ejemplo es el control padre. Si el control padre es una lista, una propiedad de enumerador podna elegir correlacionarse a una lista desplegable y no un boton de radio. Otra condicion podna ser el numero de posibles selecciones en el enumerador; podnan usarse botones de radio si hay dos o tres, pero mas elecciones podnan resultar en una lista. Siguiendo este camino, el lenguaje de correlacion terminara siendo muy complejo en comparacion al requisito inicial, y se necesita otro nivel de abstraccion encima del mapa para que los desarrolladores entiendan los mapas. Este patron se ha visto con Transformacion de Lenguaje de Hojas de Estilo Extensibles (XSLT), en la que varias herramientas se han implementado para ocultar la complejidad.

FORMULARIOS LOGICOS - UN MODELO DE UI

Cuando se correlaciona desde el modelo de la logica de negocio al modelo de UI, se inserta una capa independiente de la disposicion, tambien llamada una capa logica. Si se cree que el modelo de la logica de negocio puede relacionarse con la UI final independientemente del objetivo de visualizacion, la capa logica es una abstraccion sencilla. Algunos metadatos seran comunes para todos los objetivos de visualizacion tal como la propia entidad de negocio, y algunas partes seran espedficas para el objetivo de visualizacion espedfico. La capa logica es la parte comun.

La Figura 6 es una ilustracion diagramatica de las actividades de tiempo de diseno y actividades de tiempo de ejecucion usadas para crear formularios. En tiempo de diseno, se usan las herramientas 605 de modelado para crear modelos o definiciones de formulario y mapas tal como los analizados anteriormente. Estas definiciones de formulario y mapas pueden almacenarse en una base 610 de datos de metadatos.

En tiempo de ejecucion, los modelos o formularios se correlacionan con el modelo 625 de capa logica. El modelo 625 de capa logica tambien se genera usando datos de tiempo de ejecucion almacenados en la base 615 de datos aplicados a la logica 620 de negocio. Tambien en tiempo de ejecucion, el modelo 625 de capa logica se correlaciona con un modelo 630 de objetivo de visualizacion como se describe anteriormente.

Los formularios que incluyen capas logicas y controles es el puente entre la logica 620 de negocio y los objetivos 630 de visualizacion. Tiene conocimiento limitado de disposicion y conocimiento limitado de la logica de negocio. La capa logica define el contenido de un formulario a base de las entidades de negocio y trata cuestiones de tiempo de ejecucion comunes tal como formularios de vinculacion de datos a la instancia de tiempo de ejecucion de las entidades de negocio. Adicionalmente, la capa logica trata la seguridad comun a todos los objetivos de visualizacion; proporciona metadatos a cada objetivo de visualizacion y la capa logica puede tratar validacion de entradas.

Un arquitecto de negocio o desarrollador puede centrarse en logica de negocio espedfica de dominio y datos. Cuando el foco se cambia a la UI, los detalles de disposicion, cuestiones de vinculacion de datos, codigo de establecimiento, validacion de entrada, ocultacion de propiedades no legibles, tratamiento de errores, etc., se ocultan todos en el nivel superior de abstraccion encontrado en la capa logica. El especialista de dominio puede centrarse en los contenidos de la UI - que tiene sentido que vea el usuario - y no necesita tener un conocimiento profundo acerca de objetivos de visualizacion espedficos y sus diferentes tecnologfas de presentacion.

Como se ha analizado, los formularios logicos o modelos de capas logicas se construyen usando controles logicos. Pueden anadirse facilmente nuevos controles, haciendo la capa logica muy flexible y extensible. Cuando se desarrolla un nuevo control, simplemente se anade a formularios existentes cambiando los mapas usados. Cada objetivo de visualizacion se beneficiara de la nueva funcionalidad sin tener que implementar nuevos controles, pero si tiene sentido, puede introducirse un nuevo control.

5

10

15

20

25

30

35

40

45

50

55

OBJETIVOS DE VISUALIZACION

Los formularios logicos y controles se correlacionan con tecnologfas de presentacion espedficas usadas por los objetivos de visualizacion. Como en otras Figuras, esto se ilustra en la Figura 7 en la que el modelo de capa logica o formulario 705 se correlaciona con varios objetivos de visualizacion espedficos. En este ejemplo particular, el objetivo 710 de visualizacion usa tecnologfa de presentacion de Windows, mientras el objetivo 715 de visualizacion usa una tecnologfa de presentacion Web. Los objetivos de visualizacion son responsables del tratamiento de todas las interacciones de usuario, incluyendo la presentacion de los formularios y controles y tratamiento de la entrada de usuario. Cada objetivo de visualizacion necesita un numero de controles de modo que los controles en la capa logica se correlacionan con algo valido. Es decir, la propiedad tiene que ser compatible con los tipos de valor que puede tratar el control y el control debena presentar ese valor de una forma razonable. En otras palabras, no existe un numero espedfico de controles que necesiten estar disponibles en cada objetivo de visualizacion, ya que la tecnologfa de correlacion tiene un significativo impacto en esto.

Los objetivos de visualizacion controlan la interaccion de usuario y esencialmente tambien el paradigma de interaccion. Una pagina web y una ventana de Formularios de Windows podnan generarse a base del mismo formulario logico, pero si usan una pofftica de interaccion de comunicacion o una pofftica de envffo posterior solida se determina naturalmente mediante el objetivo de visualizacion. Cada objetivo de visualizacion elige cuanto se muestra de un formulario al usuario. Un formulario de Windows puede ocultar informacion en paginas de pestanas, mientras una pagina web puede elegir mostrar toda la informacion a la vez. Estas decisiones se toman a base del formulario logico y por lo tanto tambien el tipo de formulario, que obtienen los objetivos de visualizacion. Diferentes objetivos de visualizacion necesitan informacion adicional para tomar tales decisiones de paginacion y de forma similar los formularios logicos y controles pueden anotarse con informacion de objetivo de visualizacion espedfica.

COMPORTAMIENTOS - LOGICA DE FORMULARIO DECLARATIVA

Ya que los formularios se hacen de controles logicos, que definen el contenido, existe aun una necesidad de anadir dinamicas a los formularios. Esto podna hacerse usando codigo. Pero no es facil correlacionar codigo en un formulario y por lo tanto se necesita un nivel de abstraccion declarativo. Al mismo tiempo, existen muchos patrones en el codigo, que se anaden a los formularios. Por ejemplo, en muchos formularios se encuentra codigo para deshabilitar un campo si se rellena otro campo. Si se selecciona "En efectivo" como un tipo de pago en un formulario, el "Numero de Tarjeta de Credito" se sombrea o incluso se oculta.

Estos patrones se capturan en un concepto llamado "comportamientos." Los comportamientos se anaden declarativamente a los formularios y se activan a traves de eventos en el formulario. Los comportamientos pueden, dependiendo de valores y propiedades de los controles, establecer propiedades en otros controles, pero los comportamientos no se limitan a este uso. Los comportamientos se correlacionan principalmente a base de limitaciones en las entidades o en otras propiedades de metadatos. Las entidades son responsables del tratamiento de la logica de negocio y los comportamientos son responsables de la logica de UI. En otras palabras, los comportamientos no debenan implementar ninguna logica de negocio ya que esto violana la separacion de asuntos.

SISTEMA POR CAPAS Y EJEMPLO DE PROCEDIMIENTO

Haciendo referencia ahora a la Figura 8, se muestra una ilustracion diagramatica de un sistema por capas y procedimiento que implementa los diversos conceptos descritos anteriormente (es decir, tipos de formulario logico, mapas de UI, controles, comportamientos, etc.) en combinacion. Como se muestra en la Figura 8, el sistema o procedimiento 900 se implementa usando un marco 905 de negocio que puede incluir aplicaciones de negocio y sistemas informaticos, un motor de correlacion de cliente principal o componente 910 y uno o mas objetivos 915 de visualizacion. Para fines de ilustracion, la Figura 8 se segmenta para mostrar los mapas 920 (incluyendo mapas 921 y 922), modelos 925 (incluyendo aplicacion o modelo 926 de negocio, modelo 927 de formulario logico y modelo 928 ffsico) y librenas 930.

Las librenas 930 incluyen librenas 931 de tipos de propiedades, en el marco 905 de negocio, que define los diversos tipos 923 de propiedades de dato en el modelo 926 de aplicacion. En el cliente 910 principal, las librenas 930 incluyen la librena 932 de controles logicos, librena 933 de comportamientos y librena 934 de tipos de formulario logico. Como se ha descrito anteriormente, la librena 932 de controles logicos define los diversos controles 924 logicos con los que pueden relacionarse el dato o tipos 923 de propiedades del modelo 926. Esta correlacion entre el modelo 926 de aplicacion y modelo 927 de formulario logico se realiza mediante el motor de correlacion de cliente principal usando el mapa 921.

La librena 933 de comportamientos y librena 934 de tipos de formulario logico se usan por el motor 910 de correlacion de cliente principal en el procedimiento de diseno y generacion de formularios como se ha descrito anteriormente. Las librenas 930 tambien incluyen librena 935 de estilos, librena 936 de controles ffsicos o nativos y librena 937 de tipos de formulario que se usan por el objetivo 900 de visualizacion para generar el modelo 928 de formulario ffsico y por lo tanto para presentar el formulario ffsico. La librena 936 de control define los diversos controles ffsicos 925 para un objetivo de visualizacion particular a los que pueden relacionarse los controles 924 logicos usando el mapa 922.

Claims (16)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   REIVINDICACIONES

   1. Un procedimiento implementado por ordenador de generacion de una interfaz de usuario de formulario controlada por modelo para representar un modelo de aplicacion, comprendiendo el procedimiento:

   recibir una entrada de seleccion para seleccionar cual de una pluralidad de diferentes tipos de formulario logico usar para generar una interfaz de usuario de formulario para representar un modelo de aplicacion; proporcionar un primer mapa declarativo;

   generar un formulario logico independiente del objetivo de visualizacion usando el modelo de aplicacion, el tipo de formulario logico seleccionado y el primer mapa declarativo, en el que generar el formulario logico independiente del objetivo de visualizacion usando el primer mapa declarativo comprende ademas correlacionar tipos de propiedades de dato del modelo de aplicacion con controles logicos independientes del objetivo visualizacion en el formulario logico independiente del objetivo de visualizacion;

   correlacionar el formulario logico independiente del objetivo de visualizacion con un formulario ffsico usando un segundo mapa declarativo, en el que el formulario ffsico tiene una pluralidad de controles ffsicos disponibles para su uso en la presentacion del formulario logico en un objetivo de visualizacion, comprendiendo el uso del segundo mapa declarativo correlacionar cada uno de los controles logicos en el formulario logico con uno de la pluralidad de controles ffsicos disponibles; y

   presentar la interfaz de usuario de formulario en tiempo de ejecucion usando el formulario logico generado de tal forma que el modelo de aplicacion esta accionado en un tiempo de ejecucion, comprendiendo la presentacion del formulario logico como el formulario ffsico en el objetivo de visualizacion, en el que el formulario logico se genera en tiempo de ejecucion usando tanto el tipo de formulario logico seleccionado como metadatos del modelo de aplicacion.
2. 2. El procedimiento de la reivindicacion 1, en el que generar el formulario logico independiente del objetivo de visualizacion comprende generar un modelo de formulario logico independiente del objetivo de visualizacion.
3. 3. El procedimiento de la reivindicacion 1, en el que generar el formulario logico independiente del objetivo de visualizacion usando el modelo de aplicacion, el tipo de formulario seleccionado y el primer mapa declarativo comprende ademas tambien adjuntar comportamientos aplicados declarativamente al formulario logico independiente del objetivo de visualizacion.
4. 4. El procedimiento de la reivindicacion 3, en el que los comportamientos aplicados declarativamente se activan mediante eventos en el formulario.
5. 5. El procedimiento de la reivindicacion 4, en el que los comportamientos aplicados declarativamente son patrones de logica que, dependiendo de valores y propiedades de los controles logicos, establece propiedades en otros controles.
6. 6. El procedimiento de la reivindicacion 1, en el que el primer mapa declarativo es externo a un motor de correlacion usado para generar el formulario logico independiente del objetivo de visualizacion.
7. 7. El procedimiento de la reivindicacion 6, en el que el primer mapa declarativo es un modelo usado por el motor de correlacion para generar el modelo de control logico.
8. 8. El procedimiento de la reivindicacion 1, en el que cada uno de la pluralidad de diferentes tipos de formulario logico tiene un esquema asociado que define datos de modelo de aplicacion a incluir en el formulario logico generado, y en el que generar el formulario logico en tiempo de ejecucion comprende ademas generar el formulario logico usando el esquema asociado.
9. 9. El procedimiento de la reivindicacion 8, en el que el esquema de cada uno de la pluralidad de diferentes tipos de formulario logico representa patrones capturados de una pluralidad de formularios.
10. 10. El procedimiento de la reivindicacion 8, en el que cada uno de la pluralidad de tipos de formulario logico tiene al menos una disposicion definida, comprendiendo el procedimiento ademas generar el formulario ffsico en tiempo de ejecucion usando la al menos una disposicion definida.
11. 11. Un medio legible por ordenador que tiene instrucciones ejecutables por ordenador de realizacion de etapas de generacion de interfaz de usuario de formulario que comprenden:

    recibir una entrada de seleccion para seleccionar cual de una pluralidad de diferentes tipos de formulario logico usar para generar una interfaz de usuario de formulario para representar un modelo de aplicacion; proporcionar un primer mapa declarativo;

    generar un formulario logico independiente del objetivo de visualizacion usando el modelo de aplicacion, el tipo de formulario logico seleccionado y el primer mapa declarativo que comprende correlacionar tipos de propiedades de dato del modelo de aplicacion con controles logicos independientes del objetivo visualizacion en el formulario logico independiente del objetivo de visualizacion;

    correlacionar el formulario logico independiente del objetivo de visualizacion con un formulario ffsico usando un

    5

    10

    15

    20

    25

    segundo mapa declarativo, en el que el formulario ffsico tiene una pluralidad de controles ffsicos disponibles para su uso en la presentacion del formulario logico en un objetivo de visualizacion, y en el que presentar el formulario logico al formulario ffsico usando el segundo mapa declarativo comprende ademas usar el segundo mapa declarativo para correlacionar cada uno de los controles logicos en el formulario logico con uno de la pluralidad de controles ffsicos disponibles; y

    presentar la interfaz de usuario de formulario en tiempo de ejecucion usando el formulario logico generado de tal forma que el modelo de aplicacion esta accionado en un tiempo de ejecucion, comprendiendo la presentacion del formulario logico como el formulario ffsico en el objetivo de visualizacion, en el que el formulario logico se genera en tiempo de ejecucion usando tanto el tipo de formulario logico seleccionado como metadatos del modelo de aplicacion.
12. 12. El medio legible por ordenador de la reivindicacion 11, en el que generar el formulario logico independiente del objetivo de visualizacion usando el modelo de aplicacion, el tipo de formulario seleccionado y el primer mapa declarativo comprende ademas adjuntar comportamientos aplicados declarativamente al formulario logico independiente del objetivo de visualizacion.
13. 13. El medio legible por ordenador de la reivindicacion 11, en el que el primer mapa declarativo es externo a un motor de correlacion usado para generar el formulario logico independiente del objetivo de visualizacion.
14. 14. El medio legible por ordenador de la reivindicacion 11, en el que cada uno de la pluralidad de diferentes tipos de formulario logico tiene un esquema asociado que define datos de modelo de aplicacion a incluir en el formulario logico generado, y en el que generar el formulario logico comprende ademas generar el formulario logico usando el esquema asociado.
15. 15. El medio legible por ordenador de la reivindicacion 14, en el que el esquema de cada uno de la pluralidad de diferentes tipos de formulario logico representa patrones capturados de una pluralidad de formularios.
16. 16. El medio legible por ordenador de la reivindicacion 14, en el que cada uno de la pluralidad de tipos de formulario logico tiene al menos una disposicion definida, teniendo el medio legible por ordenador adicionalmente instrucciones ejecutables por ordenador de realizacion de la etapa adicional de generacion del formulario ffsico en tiempo de ejecucion usando la al menos una disposicion definida.