MXPA06010977A - Una plataforma de desarrollo de formularios. - Google Patents

Abstract

Una plataforma de desarrollo de formularios (10) para desarrollar formularios, la plataforma comprende: un modulo de diseno de propiedades (22) para disenar graficamente propiedades (81) de formularios reutilizables, a partir de una seleccion de campos predeterminados, las propiedades (81) tienen una logica de negocios integrada; un modulo de diseno de formularios (23) para disenar graficamente formularios reutilizables (84) usando las propiedades (81) de los formularios; los formularios (84) tienen una logica de negocios integrada; y un modulo de diseno de proyectos (21) para disenar proyectos reutilizables (86) mediante el arreglo grafico de los formularios (84) de acuerdo con un flujo de proceso predeterminado; en donde los modulos de diseno (21, 22, 23) operan independientemente uno del otro de manera que el diseno de las propiedades (81), los formularos (84) y los proyectos (86) son funciones separadas, y las propiedades disenadas (81), los formularios (84) y los proyectos (86) se almacenan como entidades separadas.

Description

UNA PLATAFORMA DE DESARROLLO DE FORMULARIOS CAMPO TÉCNICO La presente invención se refiere a una plataforma de desarrollo de formularios para desarrollar los mismos.

ANTECEDENTES DE IA INVENCIÓN En casi todas las aplicaciones de red comercial existen formularios para permitir la interacción del usuario con el sistema. El proceso para crear formularios incluye cuatro tareas principales: el manejo, contenido, estilo y lógica. Como parte de la tarea de manejo, los requerimientos generales de formularios se recopilan y dan a conocer a un equipo del proyecto para realizar el prototipo inicial y después el subsiguiente trabajo de desarrollo. Normalmente, un operador de software de negocios cumple con esta parte, siendo necesario para ello que el operador entienda y aclare las necesidades del usuario en un contrato de alto nivel y lo entregue a un equipo de proyectos para su desarrollo. El director del equipo de proyectos recibe el contrato de alto nivel y traduce los requerimientos en módulos o contenidos lógicos, y además especifica el estilo de presentación y lógica funcional para cada módulo. Una vez que se cuenta con todas las especificaciones, se le dan a conocer a un diseñador de sitios de red para la implementación de estilo y a un desarrollador de sitios de red para la implementación lógica. Este proceso implica algunos problemas, incluyendo la falta de seguridad, frecuente necesidad de mantenimiento, lento desarrollo, reutilización limitada, falta de control y que no es posible separar deberes.

SUMARIO DE LA INVENCIÓN En un primer aspecto preferido, se proporciona una plataforma de desarrollo de formularios para desarrollar formularios, que comprende: Un módulo de diseño de propiedades para el diseño gráfico de las propiedades reutilizables de formularios a partir de una selección de campos predeterminados, las propiedades tienen una lógica de negocios integrada; un módulo de diseño de formularios para diseñar gráficamente los formularios reutilizables usando las propiedades de formularios, los formularios tienen lógica de negocios integrada; y un módulo de diseño de proyectos para diseñar proyectos reutilizables mediante el arreglo gráfico de los formularios, de acuerdo con un flujo de proceso predeterminado; en donde los módulos de diseño operan, cada uno, de forma independiente uno de otro, de manera que el diseño de las propiedades, formularios y proyectos son funciones separadas y las propiedades, formularios y proyectos diseñados se almacenan como entidades separadas. La lógica de negocios contenida dentro de las propiedades y formularios diseñados puede incluir reglas de validación para introducir formularios mientras se están capturando los datos, salida de formularios, campos calculados y dependencias u otros campos en el formulario. La plataforma puede además comprender una biblioteca de propiedades para almacenar propiedades diseñadas, una biblioteca de formularios para almacenar formularios diseñados o una biblioteca de proyectos para almacenar proyectos designados. Ventajosamente, los módulos de diseño permiten la recuperación de propiedades, formularios o proyectos ya diseñados para volverlos a utilizar como plantillas. Además, la plataforma puede comprender un motor de validación para validar un formulario. El formulario se puede validar contra normas abiertas, por ejemplo, la norma W3C para XForms 1.0, o validarse contra políticas internas de un negocio. Las políticas internas de validación pueden incluir revisiones alfanuméricas o de longitud para campos de texto. Las políticas internas de validación pueden almacenarse en un depósito de políticas de validación para facilitar su reutilización. La plataforma se puede basar en una plataforma Edición Java 2 Enterprise (J2EE) . La plataforma puede presentarse a un desarrollador a través de una aplicación de escritorio para permitir un desarrollo de interfaz gráfica del lado del cliente. La plataforma puede tener un servidor como base. Se puede tener acceso a la plataforma usando un buscador de red, por ejemplo, Microsoft Internet Explorer o Netscape Navigator. Si tiene un servidor como base, los archivos de definición de formularios se almacenan directamente en el lado del servidor y eliminan la necesidad de transferencias frecuentes de archivos entre el servidor y el cliente, lo que se espera durante las etapas de desarrollo y pruebas. Además, la plataforma puede comprender un sistema de aprobación para permitir que los formularios se sometan a aprobación antes de su publicación. El sistema de aprobación puede ser un sistema centralizado. De manera ventajosa, los usuarios de negocios pueden probar y evaluar los formularios para asegurar su conformidad con los objetivos del negocio en contraste con los objetivos técnicos . El sistema de aprobación puede comprender: una bandeja de entrada para permitir el acceso a formularios individuales asociados con determinados usuarios; un Mecanismo para cuando se está Fuera de Oficinas para permitir que los usuarios indiquen un estado de Fuera de Oficinas y que especifiquen un redireccionamiento de ruta o acciones alternas; un Archivo de Formularios para permitir que se puedan buscar y filtrar los formularios; módulo de Impresión para permitir que se puedan imprimir los formularios en un formato que una impresora reconozca fácilmente; módulo de exportación para permitir que los usuarios exporten datos del formulario en XML u otros formatos; o un módulo de Administración para permitir la configuración y monitoreo remotos de todos los formularios y sus procesos de direccionamiento asociados. Se puede interpretar que el formulario diseñado genera un formulario o serie de formularios relacionados en HTML, Lenguaje de Marcación Inalámbrica (WML) u otro lenguaje para presentación en un dispositivo o sistema operativo específico. Los campos predeterminados pueden incluir campos de entrada tales como campos de texto, campos de contraseñas o campos de imágenes. El módulo de diseño de propiedades puede especificar la validación, mensaje de error y dependencias para controlar formularios dentro de una propiedad.

El módulo de diseño de formularios puede especificar la validación, mensajes de error y dependencias para propiedades, secciones y páginas dentro de un formulario. El módulo de diseño de formularios también puede especificar entidades de listas, tipos de acción, mecanismo de paginación, procesamiento antes y después de un formulario y persistencia de formularios. El módulo de diseño de formularios puede diseñar formularios con secciones y páginas . El módulo de diseño de proyectos puede especificar validación, mensajes de error y dependencias para formularios y sus entidades abarcadas. El módulo de diseño de proyecto también puede especificar entidades de listas, control de accesos, configuraciones y mecanismos de publicación. En un segundo aspecto, se proporciona un método para desarrollar formularios, el cual comprende los pasos de : diseñar gráficamente propiedades de formularios reutilizables a partir de una selección de campos predeterminados, las propiedades tienen una lógica de negocios integrada; diseñar gráficamente formularios reutilizables utilizando las propiedades de formularios, los formularios tienen una lógica de negocios integrada; y diseñar proyectos reutilizables mediante el arreglo gráfico de los formularios de acuerdo con un flujo de procesos predeterminado; en donde el diseño de las propiedades, formularios y proyectos son funciones separadas, y las propiedades, los formularios y los proyectos diseñados se almacenan como entidades separadas. En un tercer aspecto, se proporciona un formulario cuando se desarrolla utilizando el método descrito.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Ahora se describirá un ejemplo de la invención con referencia a los dibujos anexos en los que: La Figura 1 es un diagrama de bloques de la plataforma; La Figura 2 es un diagrama de interacción del sistema de la plataforma; La Figura 3A es una visualización de pantalla de una representación visual del formulario dentro de un buscador de Red; La Figura 3B es una visualización de pantalla de una representación visual del formulario dentro de un buscador WAP; La Figura 4 es una primera visualización de pantalla del Diseñador de Propiedades; La Figura 5 es una segunda visualización de pantalla del Diseñador de Propiedades; La Figura 6 es una primera visualización de pantalla del Diseñador de Formularios; La Figura 7 es una segunda visualización de pantalla del Diseñador de Formularios; La Figura 8 es una tercera visualización de pantalla del Diseñador de Formularios; La Figura 9 es una primera visualización de pantalla del Diseñador de Proyectos; La Figura 10 es una segunda visualización de pantalla del Diseñador de proyectos; La Figura 11 es una tercera visualización de pantalla del Diseñador de Proyectos; La Figura 12 es un diagrama jerárquico de un proyecto; La Figura 13 es un diagrama de configuración del sistema de la plataforma; La Figura 14 es un diagrama de modelo de validación; La Figura 15 es un diagrama de flujo del proceso para desarrollar un formulario; La Figura 16 es una visualización de pantalla de una aplicación de red; y 52-403 La Figura 17 es una visualización de pantalla de un formulario.

DESCRIPCIÓN DETALLADA DE LOS DIBUJOS Se pretende que la Figura 1 y la siguiente discusión proporcionen una breve descripción general de un ambiente de cómputo adecuado en el cual pueda implementarse la presente invención. Aunque no se requiere, la invención será descrita en el contexto general de instrucciones ejecutables por una computadora, tales como módulos de programas, que son ejecutados por una computadora personal. En general, los módulos de programas incluyen rutinas, programas, caracteres, componentes, estructuras de datos, que realizan tareas específicas o implementan tipos de datos abstractos particulares. Como lo apreciarán los expertos en la técnica, la invención se puede poner en práctica con otras configuraciones del sistema de cómputo, incluyendo dispositivos manuales, sistemas de multiprocesadores, electrónicos consumibles ya sean programables o con base en microprocesadores, computadoras personales en redes, mini computadoras, computadoras utilizadas como ordenador principal y similares. La invención además puede ponerse en práctica en ambientes de cómputo distribuidos en donde se realizan tareas mediante los dispositivos de procesamiento remotos que están 52-403 enlazados a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programas pueden ubicarse en dispositivos de almacenamiento de memoria tanto locales como remotos. Haciendo referencia a las Figuras 1 y 2, la plataforma 10 comprende tres aplicaciones funcionalmente diferentes, Studio 20, Office 30 y Server 40. Studio 20 es una aplicación interactiva con el cliente de Interfaz Gráfica de Usuario (IGU) para permitir que los usuarios ensamblen y unan visualmente los formularios con base en redes . Studio 20 incluye tres módulos de diseño: Diseñador de Proyectos 21, Diseñador de Propiedades 22 y Diseñador de Formularios 23. Studio 20 permite que los usuarios diseñen gráficamente propiedades, páginas, formularios, políticas de validación para las propiedades y formularios, flujos de páginas, flujos de formularios y flujos de procesos. La validación es importante para mantener la integridad de información dentro de una aplicación de redes, así como para proteger las aplicaciones del comportamiento impredecible que resulta de la introducción no restringida de datos por el usuario. Existen dos tipos principales de validación: validación básica y validación de políticas. La validación básica proporciona revisiones de niveles de datos, tales como 52-403 revisiones de tipo de datos y revisiones de longitud. La validación básica también incluye revisiones de seguridad contra SQL o la inserción de un conjunto de comandos ( script) . La validación de políticas implica revisiones contra políticas de negocios predefinidas o reglas establecidas por la aplicación. La plataforma 10 proporciona un enfoque intuitivo, flexible y reutilizable para especificar la validación de formularios. En la Figura 14 se describe un ejemplo de una propiedad simple que acepta el número de NRIC/FIN de los usuarios en un formulario de registro. La validación 90 de entrada requerida por esta propiedad incluye: verificar que la entrada contenga una combinación de alfabetos y números 91, la longitud de entrada puede ser tanto de nueve caracteres (NRIC) como de doce caracteres (FIN) 92, el dígito introducido deberá ser validado y revisado contra alfabetos basados en un algoritmo seleccionado 93, y el número de NRIC/FIN introducido deberá existir en una lista de existencias de registrados seleccionables 94. Las revisiones alfanu éricas y de longitud 92 son ejemplos de validación básica que puede especificarse declarativamente o seleccionarse de un depósito común de funciones de validación implementadas. Por otro lado, la revisión de la existencia de registros en la lista de usuarios constituye una validación de políticas dado que contiene semánticas 52-403 específicas de aplicaciones que incluyen operaciones de candado de bases de datos. Para apoyar la integración de la validación de políticas específicas para aplicaciones, la plataforma 10 permite que las políticas de propietarios se conecten a través de objetos Java comunes llamados validadores. Estos validadores implementan la interfaz de validadores de la plataforma 10 y amplían la funcionalidad de validadores de bases. Los validadores comunes conectados se almacenan automáticamente en un depósito específico para proyectos y se pueden reutilizar para otras propiedades de formularios . Otras políticas de validación incluyen validación de datos de salida. Las políticas de validación se diseñan y configuran gráficamente. La Definición de Esquema XML (XSD) es una declaración gramatical con base en XML para especificar restricciones de datos, relaciones jerárquicas y espacios para nombres de elementos en XML. Su utilización principal es para especificar de manera declarativa un conjunto de reglas para regular la validez de las revisiones de multiplicidad de XML y revisiones relativas a datos. La XSD soporta el manejo de conflictos de los espacios para nombres y la reutilización restringida de datos (heredable) , lo cual permite que se definan las estructuras y relaciones complejas de datos entre documentos y elementos. El sistema utiliza XSD para validar 52-403 y verificar la validez de datos de XML dentro de documentos de formularios así como interfaces del sistema para asegurar que los datos intercambiados estén en el formato correcto. Studio 20 facilita la creación de formularios seguros a nivel de empresas para aplicaciones de red trazando simplemente gráficas de flujo. Cada uno de estos artículos puede configurarse gráficamente dentro de Studio 20 para permitir que se adapten fácilmente los comportamientos específicos. Studio 20 protege a los usuarios y les evita la complejidad subyacente y el código de lenguaje de programación. Haciendo referencia a las Figuras 4 y 5, el Diseñador de Propiedades 22 se usa por un desarrollador para crear propiedades reutilizables de negocios a partir de una selección de controladores de formularios básicos. El diseñador de Propiedades 22 también permite que se especifiquen la validación, mensajes de error y dependencias para los controles de formularios dentro de una propiedad. La interfaz de usuario del Diseñador de Propiedades 22 incluye un panel de navegación 51, el panel de trabajo 52, el panel de biblioteca 53 y el panel de propiedades 54. El panel de navegación 51 presenta una vista jerárquica de un proyecto para permitir el fácil acceso a las entidades abarcadas. Para cada entidad 52-403 seleccionada dentro del panel de navegación 51, el panel de trabajo 52 proporciona la interfaz de usuario asociado y flujo de validación. Los usuarios también pueden arrastrar y soltar controles de formularios y elementos de validación de las paletas del panel de trabajo 52 en la hoja de trabajo contenedora. Los detalles de entidades seleccionadas en la navegación 51 y paneles de trabajo 52 se exhiben en el panel de propiedades 54, los cuales puede editar el usuario. Opcionalmente, los usuarios pueden importar o exportar propiedades desde o hacia un depósito común mediante el arrastre y soltado entre el panel de navegación 51 y el panel de biblioteca 53. Haciendo referencia a las Figuras 6 a 8, el Diseñador de Formularios 23 se usa por un desarrollador para crear formularios a partir de una selección de propiedades de negocios, junto con las secciones y páginas que los abarcan. El Diseñador de Formularios 23 permite que se especifiquen la validación, mensajes de error y dependencias para atributos, secciones y páginas dentro de un formulario. Otras opciones incluyen repetidores de listas (tablas dinámicas de listas) , tipos de acción (botón) , un mecanismo de paginación, procesamiento previo y posterior de formularios y persistencia de formularios. Haciendo referencia a las Figura 9 a 11, un desarrollador utiliza el Diseñador de Proyectos 21 para 52-403 crear proyectos, específicamente paquetes de formularios, opcionalmente con conexiones, flujo de formularios y un mecanismo de direccionamiento. El Diseñador de Proyectos 21 permite la especificación de validación, mensajes de error y dependencias entre los formularios y sus entidades abarcadas. Otras opciones incluyen repetidor de listas, control de acceso, configuraciones y mecanismo de publicación. El Diseñador de Proyectos 21 también proporciona revelaciones del manejo con una interfaz central para administrar todos los recursos reutilizables, los cuales incluyen conexiones, mensajes y estilos. El Diseñador de Propiedades 22, Diseñador de Formularios 23 y Diseñador de Proyectos 21 se articulan dentro de Studio 20, sujeto a los derechos de control de acceso del usuario. Esto asegura una interfaz de usuario consistente y reduce la confusión eliminando múltiples espacios de trabajo. Las conexiones (no mostradas) se registran y configuran gráficamente mediante Studio 20 para extender la funcionalidad de negocios requerida por un proyecto particular. Las conexiones incluyen validadores externos y procesadores. Todas las conexiones registradas tienen todos sus parámetros asociados y propiedades configuradas gráficamente en una forma exacta, de la misma manera. Las conexiones pueden interactuar y funcionar libremente en 52-403 Studio 20 una vez que están conectadas. Los contactos registrados se manejan por el Servidor 40. La plataforma 10 utiliza una capa adicional de abstracción para proteger a los usuarios de las construcciones técnicas del nivel inferior subyacente. Las anclas de abstracción en entidades de negocios, tales como propiedades, secciones, páginas y formularios en niveles crecientes de granulación. Estas entidades de negocios se infiltran a través del sistema y fomentan la reutilización dentro de un solo proyecto, entre diferentes proyectos y a través de toda la empresa. La plataforma 10 incluye bibliotecas 24, 25 y 26 para recopilar y almacenar entidades de negocios de manera que los usuarios pueden compartir y reutilizar estas ventajas en proyectos subsecuentes. Las entidades de negocios, propiedades y formularios de negocios se pueden compartir a niveles de proyectos, dominios y empresas. La plataforma 10 recurre a usuarios de negocios dado que pueden relacionarse mejor con las entidades de negocios en lugar de con construcciones técnicas encontradas en herramientas típicas que existen actualmente en el mercado. La plataforma 10 se centra en negocios, es decir, permite que los usuarios se enfoquen a entidades de negocios tales como propiedades, secciones, formularios y políticas de validación en lugar de que sea en códigos de 52-403 lenguaje de programación en un nivel inferior. La plataforma 10 permite realizar un rápido prototipo dado que es un esfuerzo coordinado tanto de usuarios de negocios como técnicos sin comprometer la seguridad, integridad y consistencia. .El control de concurrencia permite que múltiples miembros del equipo trabajen simultáneamente en un mismo proyecto. La plataforma 10 es responsable de fomentar un enfoque disciplinado para realizar mejores prácticas y consistencia para desarrollar formularios para aplicaciones de red. En la plataforma 10 está construido el control de permisos de manera que se asignan permisos específicos a los miembros del equipo de un proyecto sobre una base de requerimiento, lo cual también modela la estructura del equipo y las responsabilidades de los miembros del equipo. Un formulario producido por la plataforma 10 es compatible con XFor s 1.0 y conceptualmente está compuesto de tres partes principales: el Modelo, Instancia e Interfaz de Usuario (IU) . Los elementos de unión interconectan estas partes principales. Enseguida se proporciona un sencillo formulario de registro en sintaxis de XForms: 52-403 <?xml versíon^TO" epcoding=,,is?"S859-1"?> <enveJope mlns:pßrfo?pla ="htt : / erfq^ma.Grimsonlo9ic,Gom 003 04 xfarms,, xm lns:xforms- 'hüp://www.w3. o?g 2002/08/xforms/c?"' xmlns:xlÍnk=, p:/ .w3.org/1999/xlink"> <xforms:model> <xforrtts: submission xforms; id-'bíll-customer1' xfomr?s:replace:="aiir xforjn^action-'billing/bill-custome^ xfomns:metJ?od- hpost" /> <xforms;Ín$íar?ce> <name/> </xfornr?s:mstance> <xforms:bínd xfsrmsfid- 'narrie1' xforrns:nodeset» name'7> </xforms:model> <performa:form id~ 'fO" pame="testfsrrn" desc- 'Regrstration Form"> <perfor a:attr Section"> <xfomns:group> <xfor s: !abe!> Heí lo </xforrns:!abel> <xfomns:?nput xforms.id- "name-input" xformsibind-'name'^ <xfonms:label>Your ñame: </xfarms;label> </xforms:in?ut> <xfo?p?s:írigger xfomr?s:íd-"ser tti:,l> <xfopns:tabe[ Send </xfsrms:label> <xforme:ac ?on>. <xforms:send xformsrid- 'submif <xforms:submission=" bil!-customer7> </xforms:action> </xfcrms:trigger> <xforp?s:trigger xforms: ¡d="reset-btn"> 52-403 <xforms:tabeI>Reset</xfornns:labet> <xforms:acíion> <xforms:reseíipstan e xforms:id="reset17> </xforms:actlop> </xfsrms:trigger> </xforms:group> </performa:attr </perforp?a:form> </ßnvelope> Con base en la anterior definición de formulario, la visualización de formulario dentro de un buscador de Red aparece como en la Figura 3A. Alternativamente, la misma definición de formulario convertida dentro de un buscador WAP manual móvil aparece como en la Figura 3B. Para permitir la independencia del dispositivo blanco, se define la forma genérica del formulario y la separación inherente de la interfaz de usuario, datos ilustrativos y lógica, lo que se realiza para adaptarlo a XForms. Un formulario genérico se interpreta en la sintaxis de XForms . La definición de formulario que antecede muestra dos elementos de producto encontrados dentro del elemento de raíz, "envelope" ("envoltura") o cualquier nombre válido de XML en algún espacio para nombre: <xforms :model> - dentro de este elemento se abarca todo lo conocido acerca del formulario, con excepción de la forma en que aparece o la manera en que se 52-403 presenta. El modelo describe los datos de ejemplo iniciales, un documento de esqueleto de XML que contiene la estructura completa del documento final deseado del formulario dentro del elemento "instance" ("ejemplo") así como su modelo asociado, por ejemplo, tipos de datos con base en el Esquema de XML, restricciones de validación y valores calculados, usando una combinación de elementos "bind" ("enlace") y expresiones de XPath. Las acciones tales como almacenar en disco o enviar a sistemas finales también se definen en la presente como elementos de "submission" ("envío") . <perforna: form> - esta sección contiene los detalles de interfaz del formulario, que dice que se muestren o presenten los controles de IU de la plataforma. El elemento de "form" ("formulario") superior en el espacio para nombre de "performa" identifica el documento como una definición de formulario familiar para la plataforma, mientras que el elemento de producto de "attr" constituye una propiedad reutilizable de negocios que abarca un grupo de controles de formularios. A partir del ejemplo, los controles de formularios tales como "input" ("entrada") y "trigger" ("disparador") se correlacionan directamente con la casilla de textos y los elementos de botones en la presentación de HTML respectivamente, siempre que la elección de la visualización de pantalla sea HTML. 52-403 Dentro de los elementos de "trigger" están las acciones de XForms (elementos de "action" ("acción")) los cuales permiten que la lógica de formularios sea autorizada de manera declaratoria. Ejemplos de acciones apoyadas podrían incluir valor de ajustes de nodos en el ejemplo modelo, insertar o suprimir entradas en recopilaciones, intercambiar entre diferentes versiones de IU entre otros. Durante el tiempo de operación, se utiliza el elemento xforms: odel para ejemplificar el modelo de formulario mientras que se interpreta el contenido de performa : form por constituir el IU del formulario y se inicia con datos del modelo de ejemplo. Al usuario se le presenta el formulario exhibido y puede cambiar los valores y presentar los datos oprimiendo el botón "Send" ("Enviar") . Al ser presentado, la plataforma inserta los datos del formulario en el modelo de ejemplo y exhibe una página de HTML la cual visualiza los datos presentados mediante "billing/Hill-customer" especificado dentro del elemento "submission". Haciendo referencia a la Figura 12, una aplicación de red desarrollada por la plataforma 10 adopta un modelo lógico y conceptual jerárquico. Este modelo distingue las entidades constituyentes de la aplicación de red extendiéndose por cinco niveles: Proyecto, Conjunto, Formulario, Página, Sección y Propiedad o Lista. Para que 52-403 sea válida una aplicación de red, cada nivel lógico deberá implementarse e introducirse dentro del siguiente nivel superior en la secuencia exacta según se describe. Por ejemplo, la implementación más sencilla podría consistir de un ejemplo de Proyecto, el cual abarca un ejemplo de Conjunto, el cual abarca un ejemplo de Formulario, seguido por un ejemplo de Página, ejemplo de Sección y por último un ejemplo de Propiedad o Lista. Esta organización jerárquica asegura la consistencia en implementación, confiabilidad y escalonamiento para adaptar entidades adicionales de formularios. La Figura 12 describe una implementación de formulario de gastos en el extranjero 80. En el nivel básico de la jerarquía están las entidades de propiedades y listas 81, que son los bloques de construcción fundamentales del formulario. Una propiedad 81 puede definirse como una unidad de formulario de negocios que consiste de una o más propiedades 81 de formularios o controla el propósito principal para reunir la entrada de usuarios. Incluyen campos de entrada de textos, listas descendentes, selección de casillas de revisión o para introducir botones de elección. Cada control de formulario dentro de una propiedad 81 está asociado con revisiones de tipo de datos y validación específicos para reflejar las restricciones de uso de negocios. También se pueden 52-403 especificar las funciones aritméticas del estilo de hoja de cálculo para que los controles de formularios importantes realicen cálculos sencillos. Similares a las propiedades 81, los repetidores de listas también son entidades a nivel básico, pero son diferentes en términos de su propósito principal. Las listas exhiben datos en lugar de recopilarlos. Un artículo de lista se utiliza comúnmente en aplicaciones para presentar datos existentes en una forma tabular para proporcionar una muestra de resumen o índice. Con frecuencia, los datos dentro de una lista se organizan en columnas de tablas, las cuales pueden elegirse en orden ascendente o descendente. En la plataforma 10, las listas pueden soportar datos recuperados directamente de una base de datos o a los que se hace referencia en ejemplos de datos de formularios en la memoria dentro del mismo espacio de los paquetes. Las secciones 82 son bloques lógicos que permiten la agrupación de propiedades 81 principalmente con el fin de crear categorías. Con base en esta agrupación, es posible realizar tareas colectivas como un todo, tales como marcaciones de grupos, operaciones de superposición y aplicación de temas de estilo. Las páginas 83 abarcan las secciones, las cuales se utilizan comúnmente para dividir longitudinalmente un 52-403 formulario en una serie de uniones de páginas de tamaño de pantalla para reducir al mínimo el desplazamiento en una pantalla de video. Las páginas incluyen normalmente una variedad de mecanismos de paginación para aumentar al máximo la facilidad de navegación y cada página es parecida a un formulario auto contenido en términos de revisión y exhibición de error. Los errores introducidos se notifican inmediatamente a los usuarios. El error introducido en una página puede hacer que otras entradas en páginas subsecuentes sean erróneas y se requiere que vuelvan a capturarse los datos. Los formularios 84 con entidades completas y auto-contenidas y son capaces de circular productivamente. Los formularios 84 participan en el direccionamiento de aprobación de naturaleza adecuada o estructurada. Durante el proceso de direccionamiento de aprobación, las aprobaciones pueden conectar documentos de soporte o cualquier otro recurso electrónico como referencia. Como tal, un formulario particular 84 puede ligarse opcionalmente a conexiones, y puede conocerse colectivamente como un paquete 85. Los paquetes 85 pueden referirse también a un grupo de formularios o conexiones relacionados con referencia entre sí. Por ejemplo, el paquete 85 de "Gastos en el Extranjero" abarca el formulario de "Subsistencia de Viaje" 84 y el formulario de "Gastos de Transporte" 84. El formulario de "Gastos de Transporte" 84 es un formulario secundario del formulario de "Subsistencia de Viaje" 84. El modelo jerárquico converge en la entidad del proyecto 86 situada en el nivel de raíz. En el nivel de raíz, los formularios 84 y paquetes 85 diferentes se pueden unir a los módulos de flujo de trabajo específicos o integrarse con aplicaciones externas mediante el redireccionamiento URL. En la presente, se establecen configuraciones específicas de proyectos para efectuar cambios que se propagan a través del modelo al nivel de propiedades. Un ejemplo es especificar un conjunto de estilos normales que promueven la consistencia de apariencia y sensación a todos los niveles. Es posible que haya otras configuraciones tales como control de acceso, control de versión, mecanismo de publicación de formularios y filtro de depósitos de entidades.

EJEMPLO Haciendo referencia a la Figura 15, en un escenario típico, un desarrollador lanza 101 el Studio 20 desde el escritorio para empezar a crear una nueva aplicación de red. El desarrollador crea 102 las propiedades de formularios necesarias usando el Diseñador de Propiedades 22 con base en una selección de propiedades de biblioteca. En un ejemplo de un formulario de registro, el desarrollador alinea varias propiedades atómicas tales como "Calle", "No. Unitario" y Código Postal" las agrupa como una propiedad mixta de "Dirección", junto con propiedades de "ID del Usuario", "Contraseña" y "Correo Electrónico". Para cada campo, se especifican los estilos de presentación preconfigurados y asignan las reglas y políticas de validación apropiadas. Las propiedades creadas se guardan 103 en un depósito específico del proyecto, las cuales pueden ser recuperadas y reutilizadas para nuevos formularios subsecuentes. En seguida, el desarrollador y otro miembro del equipo invocan al Diseñador de Formularios 23 y diseña visualmente 104 el formulario arrastrando y soltando las propiedades creadas previamente en el formato del plan deseado. La configuración también tendrá disponibles los controles adicionales tales como paginación, procesamiento previo y posterior, redirección de salida, formato de exhibición de error y opciones de direccionamiento. Después de terminar el diseño del formulario, el desarrollador puede operar y ver previamente el formulario en el Diseñador de Proyectos 21 de manera inmediata. Subsecuentemente, el formulario se direcciona automáticamente a través de un proceso de aprobación 106 antes de que se publique (107) el acceso real. Con la segregación de deberes, en situaciones normales, no se les otorga el acceso a un desarrollador a los tres diseñadores 21, 22, 23. Haciendo referencia a la Figura 17, una vez que es real el formulario, los usuarios de negocios pueden realizar presentaciones de formularios y rastrear la ruta de aprobación asociada de la Oficina 30 centralizada. La Oficina 30 incluye un mecanismo de "bandeja de entrada" para que los aprobadores manejen y aprueben los formularios diseccionados en una forma organizada y conveniente. La bandeja de entrada permite el acceso a formularios individuales en donde solo se observan en su bandeja de entrada aquellos formularios o conexiones asociadas actualmente con un usuario particular. Los usuarios pueden ver previamente el contenido de los formularios, rastrear información de rutas, aprobar formularios, rechazar formularios, conectar documentos, insertar comentarios, así como especificar destinos de rutas de su bandeja de entrada. Para los presentadores de formularios, se proporciona una instalación para enmendar y volver a presentar formularios rechazados o recuperar formularios llenados parcialmente para resumir la entrada de datos. Es posible que el desarrollador realice mejoras en formularios futuros realizando sencillamente unas cuantas operaciones con el ratón para efectuar cambios en tipos de campos, 52-403 disposiciones de propiedades o aún en todo el formato de la presentación. Office 30 también incluye un Mecanismo de Fuera de la Oficina para permitir que los usuarios indiquen que no están en la oficina y consecuentemente especifiquen la redirección de ruta o acciones alternas. Otras características incluidas en Office 30 son módulos de Archivo de Formularios, Impresión y Exportación así como funciones de Administración. Alternativamente, los formularios publicados también pueden integrarse con las aplicaciones de red existentes mediante el redireccionamiento de URL. Esto se ilustra en la Figura 16. Haciendo referencia a la Figura 13, la configuración del Servidor 40 comprende tres capas funcionales, a saber, procesadores 11, conectores 12 y publicadores 13. La capa de procesadores 11 constituye el comando de núcleo y operaciones de control de la plataforma 10 y abarca procesadores especializados 11 que son funcionalmente distintos y se acoplan holgadamente unos a otros. Estos procesadores 11 incluyen Manejo de Solicitud y Respuesta, Procesamiento de Formularios Previos y Posteriores, Validación, Flujo de Trabajo de Direccionamiento y Persistencia. En una solicitud de red normal de un cliente a la plataforma 10, se genera y proceso en paralelo y dependiendo de los ajustes de 52-403 configuración en paralelo, se pueden intercambiar o combinar varios procesadores 11 para responder la solicitud. Los procesadores 11 interactúan con la capa de conectores 12 para la conectividad a sistemas externos, tales como bases de datos 15, máquinas reguladoras 16 y otras aplicaciones de negocios 17. Las capas de conectores 12 encapsula la integración del sistema específica a través de agentes de conexión robustos, que contienen la capacidad de interconectarse con sistemas externos mientras que mantiene una interfaz de acceso de aplicación consistente. La capa de publicación 13 proporciona capacidades de presentación con múltiples blancos para el marco de trabajo transformando casos de formularios de XML en varias sintaxis de marcación que pueden entenderse y convertirse por el dispositivo blanco. Cada componente de la capa de publicación 13 mantiene una hoja de estilo de transformación para mapear elementos de formularios intrínsecos creados por el sistema en tipos de elementos blanco pretendidos. Los formatos de publicación proporcionados por los componentes de publicación incluyen, HTML, Macromedia Flash, PDF, WML, VRML e XML. Las tareas de desarrollo de estructuras de la plataforma 10 implicadas en el desarrollo de formularios para una aplicación con base en la red de acuerdo con el 52-403 papel que juega un miembro del equipo. La segregación de deberes permite que el desarrollo de tareas se ajuste de acuerdo con las responsabilidades y capacidades del miembro del equipo respectivo. Esto asegura que cada miembro del equipo solo pueda realizar las funciones que les son asignadas. Los desarrolladores individuales que trabajan en el mismo proyecto son coordinados y sincronizados. Esto permite que el desarrollo del equipo progrese y permite que se logre el surgimiento del desarrollo del trabajo sin sacrificar el control. Los expertos en la materia apreciarán que se pueden hacer numerosas variaciones y/o modificaciones de la invención como se muestra en las modalidades específicas sin alejarse del alcance o espíritu de la invención como se describió ampliamente. Por lo tanto, las modalidades presentes se consideran ilustrativas y no restrictivas en todos los aspectos. 52-403

Claims (1)

1. REIVINDICACIONES 1. Una plataforma de desarrollo de formularios para desarrollar formularios, que comprende: un módulo de diseño de propiedades para diseñar gráficamente propiedades de formularios reutilizables a partir de una selección de campos predeterminados, las propiedades tienen lógica de negocios integrada; un módulo de diseño de formularios para diseñar gráficamente formularios reutilizables mediante el uso de las propiedades de formularios, los formularios tienen lógica de negocios integrada; y un módulo de diseño de proyectos para diseñar proyectos reutilizables mediante el arreglo gráfico de los formularios de acuerdo con un flujo de proceso predeterminado; en donde los módulos de diseño operan independientemente entre sí, de manera que el diseño de las propiedades, los formularios y los proyectos son funciones separadas y las propiedades, los formularios y los proyectos diseñados se almacenan como entidades separadas. 2. La plataforma según la reivindicación 1, que comprende además una biblioteca de propiedades para almacenar propiedades diseñadas, una biblioteca de formularios para almacenar formularios diseñados y una biblioteca de proyectos para almacenar proyectos diseñados. 52-403 3. La plataforma según la reivindicación 1 ó 2, que comprende además un motor de validación para validar un formulario. 4. La plataforma según la reivindicación 3, en donde el formulario se valida contra una norma abierta o se valida contra una política de negocio interna de un negocio. 5. La plataforma según la reivindicación 3 ó 4, en donde el formulario se valida para cumplir con una política de seguridad tal como la revisión para SQL o la inserción de un conjunto de comandos ( script) . 6. La plataforma según la reivindicación 4, en donde la política de negocios interna se almacena en un depósito de políticas de validación para facilitar su reutilización. 7. La plataforma según cualquiera de las reivindicaciones anteriores, que además comprende un sistema de aprobación para permitir que se sometan a aprobación los formularios antes de publicarse. 8. La plataforma según la reivindicación 7, en donde el sistema de aprobación es un sistema centralizado. 9. La plataforma según con la reivindicación 7 u 8, en donde el sistema de aprobación incluye: una bandeja de entrada para permitir el acceso a formularios individuales asociados con ciertos usuarios; un 52-403 Mecanismo de Fuera de Oficina para permitir que los usuarios indiquen un estado fuera de oficina y especifiquen el redireccionamiento de ruta o acciones alternas; un Archivo de Formularios para permitir que los formularios se puedan buscar y filtrar; módulo de Impresión para permitir que se puedan imprimir los formularios en un formato de fácil uso por la impresora; módulo de exportación para permitir que los usuarios exporten datos del formulario en XML u otros formatos; o un módulo de Administración para permitir la configuración y monitoreo remotos de todos los formularios y sus procesos de direccionamiento asociados. 10. La plataforma según cualquiera de las reivindicaciones anteriores, en donde se interpreta el formulario para generar un formulario o serie de formularios relacionados en HTML, Lenguaje de Marcación Inalámbrica ( WML) u otro idioma para la presentación en un dispositivo o sistema operativo específico. 11. La plataforma según cualquiera de las reivindicaciones anteriores, en donde los campos predeterminados incluyen campos de entrada tales como campos de texto, campos de contraseñas o campos de imágenes. 52-403 12. La plataforma de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de propiedades especifica la validación, el mensaje de error y dependencias para controles de formularios dentro de una propiedad. 13. La plataforma según cualquiera de las reivindicaciones precedentes, en donde las propiedades se diseñan jerárquicamente. 14. La plataforma según la reivindicación 13, en donde la validación de un formulario se mantiene dentro de niveles predeterminados. 15. La plataforma según cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de formularios diseña flujos de páginas. 16. La plataforma de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de formularios especifica la validación, los mensajes de error y dependencias para propiedades, secciones y páginas dentro de un formulario. 17. La plataforma según cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de formularios especifica repetidores de listas, tipos de acción, mecanismo de paginación, procesamiento de formularios previos y formularios posteriores y persistencia de formularios. 52-403 18. La plataforma según cualquiera de las reivindicaciones anteriores, en donde se ligan servicios de negocios finales con el flujo de procesos predeterminados. 19. La plataforma según cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de formularios también diseña formularios con secciones y páginas. 20. La plataforma según cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de proyectos maneja centralmente estilos, mensajes y conexiones para un proyecto. 21. La plataforma según cualquiera de las reivindicaciones anteriores, en donde el módulo de diseñador de proyectos especifica repetidores de listas, control de acceso, configuraciones y un mecanismo de publicación. 22. La plataforma según cualquiera de las reivindicaciones anteriores, en donde la lógica de negocios contenida dentro de propiedades y formularios diseñados incluye reglas de validación para introducir formularios mientras se están capturando los datos. 23. La plataforma según cualquiera de las reivindicaciones anteriores, en donde la lógica de negocios contenida dentro de las propiedades y formularios diseñados incluye ecuaciones o calculadores para generar un resultado 52-403 útil. 24. Un método para desarrollar formularios, que comprende los pasos de: diseñar gráficamente propiedades de formularios reutilizables a partir de una selección de campos predeterminados, las propiedades tienen lógica de negocios integrada; diseñar gráficamente formularios reutilizables usando las propiedades de formularios, los formularios tienen lógica de negocios integrada; y diseñar proyectos reutilizables mediante el arreglo gráfico de los formularios de acuerdo con un flujo de proceso predeterminado; en donde el diseño de las propiedades, los formularios y los proyectos son funciones separadas, y las propiedades, los formularios y los proyectos diseñados se almacenan como entidades separadas. 25. Un formulario mediante el método según la reivindicación 24. 26. El método según la reivindicación 24, que comprende además el paso de proporcionar una interfaz de usuario gráfica para permitir que un usuario realice los pasos de diseñar gráficamente propiedades de formularios reutilizables, diseñar gráficamente formularios reutilizables y diseñar proyectos reutilizables. 52-403 27. Un producto de programa de cómputo que comprende un medio legible en una computadora para portar instrucciones que pueden ejecutarse por una computadora para: diseñar gráficamente propiedades de formularios reutilizables a partir de una selección de campos predeterminados, las propiedades tienen lógica de negocios integrada; diseñar gráficamente formularios reutilizables usando las propiedades de formularios, los formularios tienen lógica de negocios integrada; y diseñar proyectos reutilizables mediante el arreglo gráfico de los formularios de acuerdo con un flujo de proceso predeterminado; en donde el diseño de las propiedades, los formularios y los proyectos son funciones separadas, y las propiedades, los formularios y los proyectos diseñados se almacenan como entidades separadas. 52-403