documento del proyecto de grado
TRANSCRIPT
UNIVERSIDAD DE LOS ANDES
Documento del Proyecto de Grado
Recolección de Información en Proyectos de Arquitectura Empresarial
Bernardo Mohnblatt Linsker – 200722680 – [email protected]
24/06/2013
2
Contenido 1. Introducción .................................................................................................................................... 3
1.1. Contexto .............................................................................................................................. 3
1.2. Problemática ....................................................................................................................... 4
1.3. Motivación .......................................................................................................................... 5
1.4. Solución (Alto Nivel) ............................................................................................................ 5
1.5. Resumen de la operación de la solución ............................................................................. 7
2. Tecnologías Involucradas ............................................................................................................ 7
2.1. XTEXT ................................................................................................................................... 7
2.2. EMF (PlugIn para Eclipse) .................................................................................................... 8
2.3. Eclipse .................................................................................................................................. 8
2.4. Java SWING ......................................................................................................................... 9
2.5. MySQL ................................................................................................................................. 9
2.6. Java JSF ................................................................................................................................ 9
2.7. NetBeans ............................................................................................................................. 9
2.8. PrimeFaces ........................................................................................................................ 10
2.9. HTML, JavaScript y XML Files ............................................................................................ 10
3. Estado del Arte .......................................................................................................................... 11
3.1. Oracle Forms 11g .............................................................................................................. 11
3.2. WinForms .......................................................................................................................... 11
3.3. WebForm ........................................................................................................................... 12
3.4. JOOMLA ............................................................................................................................. 12
3.5. Magento Web Forms Community Edition ........................................................................ 12
4. Arquitectura .............................................................................................................................. 13
4.1. Arquitectura de Solución ................................................................................................... 13
4.2. Casos de Uso ..................................................................................................................... 15
4.3. Arquitectura de Información ............................................................................................. 16
5. Lenguaje de Dominio específico para Formularios ................................................................... 18
6. Conclusiones.............................................................................................................................. 22
7. Referencias ................................................................................................................................ 24
8. Anexos ....................................................................................................................................... 25
8.1. Gramática .......................................................................................................................... 25
3
1. Introducción
En esta sección se establecerá el contexto del proyecto de grado para poder
entrar a describirlo detalladamente en todas sus perspectivas, después se hablará
de la problemática que se quiere solucionar explicando por qué el proyecto es útil
para un contexto genérico y puede manejar casos específicos. En la motivación se
introducirá una breve descripción de cómo encaja el proyecto dentro de los
procesos que se llevan a cabo en las empresas de hoy y la solución mirada desde
una perspectiva de alto nivel introducirá abstractamente el funcionamiento del
proyecto y la operación de la herramienta propuesta.
1.1. Contexto
Se pretende apoyar la solución de un problema que tienen las empresas de hoy
en día cuando se trata de recolectar información de diferentes áreas/personas con
el fin de usarla en pro de un proyecto (interno o externo). En este caso específico
se utilizará para apoyar la recolección de información a través del uso de
formularios digitales con la diferencia que usando esta herramienta podrán definir
y estructurar estos formularios desde la base por un área que administre el
sistema (ej. IT), adicionalmente los entrevistadores (Personas que recolectan la
información) podrán proveer retroalimentación al diseño de los mismos.
La situación actual del problema a abordar esta centrada en un mercado que
cobra montos bastante altos por herramientas similares y un acceso limitado a
estas por parte de comunidades abiertas y/o estudiantiles que las obliga a acudir a
métodos rústicos para llevar a cabo tareas de recolección de información a través
de formularios.
Una vez terminado el proyecto, se pretende fundar una base sólida para dejar
funcionando una herramienta que permita la creación flexible de formularios y la
ejecución de proyectos de recolección de información haciendo uso de estos y que
de tal manera los segmentos ya señalados estén en capacidad de hacer uso de
ella.
4
1.2. Problemática
Como ya fue descrito anteriormente, la problemática radica en la falta de
herramientas flexibles de creación de formularios para recolección de información
utilizada en proyectos tanto empresariales como académicos y que las existentes
(similares) no son accesibles para segmentos de comunidades abiertas y
estudiantiles entre otras.
Es común ver en los contextos de los segmentos señalados, que cuando se hace
la recolección de información para proyectos y se utilizan formularios, se dan
varios tipos de informalidades cuando se trata de manejar la información:
Se utilizan herramientas rústicas que no dan ningún tipo de estructura a la
información recolectada y por lo tanto lo valioso que se puede encontrar en
ella tiene una probabilidad alta de ser desechado.
No hay control desde niveles altos del proyecto sobre la recolección de la
información, pues para grandes volúmenes de datos la administración de
los mismos se complica de una manera exponencial.
No hay espacio para la proactividad en la recolección de información por
parte de las personas que la recolectan, pues el acceso a la estructura del
formulario está limitado para retroalimentaciones.
No existe una entidad centralizadora de la información recolectada en el
proyecto, lo que puede llevar a que la calidad de los datos y la información
sea bastante baja.
Realmente la problemática radica en que el planteamiento de los formularios para
recolectar información es complicado, la calidad de los datos recolectados puede
verse afectada por la falta de centralización de la información y la administración
del proyecto se puede ver drásticamente dañada por las complicaciones que
implican los procesos de recolección de información utilizando metodologías
rústicas.
5
1.3. Motivación
La motivación parte de lograr que un proyecto que comience en la Universidad de
los Andes, pueda fundar una base para la creación de una herramienta que
permita hacer más eficiente y estructurado el proceso de recolección de
información en diferentes tipos de instituciones con diferentes tipos de proyectos.
La idea es lograr esto a través de una herramienta que por sus características
genéricas permita un diseño flexible y una ejecución eficiente de este tipo de
procesos.
1.4. Solución (Alto Nivel)
1. Aplicativo de Administración de la Herramienta: Aplicativo Desarrollado
en Java que permite al administrador del sistema plantear la estructura de
usuarios y proyectos que se usará para la institución y asimismo validará
los formatos que se plantean (validará los Lenguajes de Dominio específico
con lo definido en EMF) para estructurar el plan de entrevistas basado en
formularios que ejecutarán posteriormente los entrevistador en las
empresas.
2. Modelos y Lenguaje de Dominio Específico: Desarrollo de la definición
de lo modelos que soportarán la estructura de los formularios con una
1
2
3
4
5
6
herramienta desarrollada por Estudiantes de Maestria de los Andes que
permite editar los modelos base y los metamodelos paralelamente y de tal
manera hacer que logren autovalidarsen uno con el otro. Definición de la
estructura soportada usando un lenguaje de dominio específico que hace
referencia a una gramática construida con un desarrollado en XTEXT.
3. Lenguajes Resultantes y formatos .xmi: Formatos .xmi y lenguajes de
dominio resultantes de la etapa de diseño de los formularios que serán
validados y almacenados en una base de datos que centralizará la
información y apoyará la interpretación del diseño y de los resultados.
4. Base de Datos Centralizadora: Base de Datos que centralizará los
resultados de la ejecución de las entrevistas basándose en el diseño
previamente realizado por el administrador y que de tal manera apoyará la
interpretación de los formularios. Todo esto se logra con la definición de un
modelo de datos genérico que permite el almacenamiento de las diferentes
definiciones de formularios resultantes del diseño por parte del
administrador así como las instancias de los mismos, resultado de las
entrevistas.
5. Aplicativo de Entrevistas: Aplicativo web que permite a los
entrevistadores (Personas que recolectan la información en el proyecto)
realizar las entrevistas de una forma estructurada y de navegación flexible
por los diferentes formularios asignados a los proyectos que están siendo
llevados a cabo. Adicionalmente permite contribuir con retroalimentación a
la estructura de los formularios y llevar registro (en formatos .xml) de las
sesiones que se han llevado a cabo con cada una de las personas a
entrevistar.
7
1.5. Resumen de la operación de la solución
2. Tecnologías Involucradas
Esta sección describirá las herramientas involucradas en el proyecto, explicará de
qué forma se están utilizando en el mismo y cuál fue la metodología de desarrollo
utilizada en el proyecto con dicha herramienta.
2.1. XTEXT
XTEXT es una herramienta que permite y facilita la construcción de lenguajes de
dominio específico propios de una situación con los beneficios de ajustar una
gramática a necesidades específicas y tener un parser de la misma trabajando en
pro de los desarrollos con este leguaje. Adicionalmente está soportada para
trabajar sobre eclipse. XTEXT cubre todos los aspectos de la infraestructura
completa de un lenguaje de domino específico desde los parsers hasta los
enlazadores, pasando por compiladores e interpretadores que se integran con el
IDE (Eclipse). (XTEXT, 2013)
En el proyecto, XTEXT es utilizado como la herramienta que se usó para definir la
gramática del lenguaje de dominio específico que se utiliza para definir la
8
estructura de los formularios en los proyectos de recolección de información.
Gracias a su integración con Eclipse se facilitó la generación de compiladores y
los administradores (IT) en las empresas solo requerirán de este para desarrollar
la definición de la estructura de sus formularios.
2.2. EMF (PlugIn para Eclipse)
El proyecto EMF es un framework de modelado y generación de código para la
construcción de herramientas y otras aplicaciones basadas en un modelo de datos
estructurado. A partir de la especificación de un modelo descrito en XMI. EMF
proporciona herramientas y soporte de tiempo de ejecución para producir un
conjunto de clases Java para el modelo, junto con un conjunto de clases de
adaptadores que permiten la visualización y comando de edición basada en el
modelo, y un editor básico para el mismo. (Eclipse)
En este proyecto específico se utilizará un PlugIn desarrollado dentro de la
Universidad de los Andes para la edición de modelos y metamodelos
paralelamente en EMF.
2.3. Eclipse
Además de ser utilizado como IDE para lograr el desarrollo de algunos de los
componentes, Eclipse sirvió como plataforma de despliegue para:
La instalación de XTEXT y posterior plataforma de desarrollo de la
gramática que dio lugar a la definición del lenguaje de dominio específico
que se creó para los formularios.
El compilador del lenguaje de dominio específico definido para la creación
de los formularios. Esto significa que Eclipse es parte de la interfaz que
maneja el administrador del sistema (en IT) para su gestión con la
herramienta.
El PlugIn desarrollado por Estudiantes de Maestría de los Andes para la
edición paralela de modelos y metamodelos es también en PlugIn para
Eclipse, lo que significa que en este segundo caso el administrador del
sistema estará usándolo.
Visto lo anterior y para la implantación de la herramienta en una empresa, se
necesita que la máquina del administrador del sistema tenga Eclipse con los dos
PlugIns instalado.
9
2.4. Java SWING
Java SWING es en la herramienta la encargada de hacer el papel de interfaz
gráfica para el aplicativo del administrador del sistema. La decisión fue tomada por
que en una primera etapa del ciclo de vida de la herramienta, este aplicativo será
local. Aún así está planteado que en un futuro la interfaz de este aplicativo sea
también WEB.
2.5. MySQL
MySQL es la base de datos elegida para soportar la persistencia de los datos en la
herramienta. La elección se hace por en es una base de datos que conoce la
gente que trabaja y trabajará en el proyecto y tiene los suficientes atributos para
soportar la operación de una herramienta como la planteada.
2.6. Java JSF
Un conjunto de APIs para representar componentes de interfaz de usuario y la
gestión de su estado, de sus eventos y la validación de entrada, así como la
definición de la navegación de sus páginas y el apoyo a la internacionalización y
accesibilidad. Una biblioteca de etiquetas (tags) personalizadas para JavaServer
Pages (JSP) en donde se puede expresar una interfaz JavaServer Faces dentro
de una página JSP. (OTN)
JSF es la librería utilizada para el desarrollo web de la herramienta del aplicativo
para los entrevistadores.
2.7. NetBeans
Netbeans es el IDE que se utilizó para desarrollar todo lo involucrado con el
aplicativo web que utilizan los entrevistadores dentro de la herramienta.
Esencialmente se elige por su facilidad para desarrollar aplicaciones WEB java y
su apoyo en el uso de librerías y herramientas internas usadas para desarrollar
herramientas como la planteada.
10
2.8. PrimeFaces
PrimeFaces es la librería gráfica utilizada para soportar las exigencias de interfaz
necesitadas en el aplicativo web que usa el entrevistador. Primefaces hace
armonía con JSF y fue elegida por permitir que los elementos gráficos de una
aplicación sean flexibles y fáciles de implementar.
2.9. HTML, JavaScript y XML Files
Estas son algunas tecnologías adicionales necesarias para soportar la operación
de las herramientas web utilizadas para el desarrollo del aplicativo del
entrevistador.
11
3. Estado del Arte
3.1. Oracle Forms 11g
Oracle Forms, un componente de Oracle Fusion Middleware, es la tecnología de
larga data de Oracle para diseñar y construir aplicaciones empresariales de forma
rápida y eficiente. Oracle mantiene su compromiso con el desarrollo de esta
tecnología, y para la liberación continua como un componente de la plataforma
Oracle. Este continuo compromiso con la tecnología de formularios le permite
aprovechar su inversión existente al permitir el perfeccionamiento y la integración
de aplicaciones Oracle Forms existentes para aprovechar las tecnologías web y
las arquitecturas orientadas a servicios (SOA). (OTN)
Oracle Forms es el componente actual de lo que venía siendo anteriormente
Oracle Forms & Reports. Esta tecnología es bastante costosa y poco accesible
para comunidades abiertas/estudiantiles. Si bien Forms permite la integración de
los formularios con aplicaciones construidas con SOA, es complicado el gobierno
de la misma y además poco flexible.
3.2. WinForms
WinForms o Widows Forms es un API Perteneciente al Framework de .NET de
Microsoft. WinForms es el componente de .NET que permite diseñar formularios
con facilidad como parte de las aplicaciones web que se construyen con el mismo.
La integración con el resto del Framework hace que la funcionalidad de WinForms
sea extendida a una arquitectura completa de una solución. (Microsoft) Con
WinForms es posible que un proyecto dedicado únicamente a la recolección de
información sea complicado, dado que su diseño está hecho para interactuar
como componente complementario a otras partes del Framework que serían en
dado caso el Core de un aplicativo.
12
3.3. WebForm
WebForm es el módulo para ejecutar encuestas basadas en formularios que
ofrece Drupal. Está basada en una metodología de encuestas “Self-Serviice” que
solo requiere de la presencia de quien la contesta. Una vez acabada la encuesta,
el usuario enviará vía mail una notificación a los administradores (con copia a
quien quiera) informando que ya acabó y claro está, el contenido de la misma. Los
resultados finales serán exportados a Excel por parte del Administrador y los
usuarios. Esta aplicación es sugerida para ser usada en ocasiones como:
Concursos, recolección de información personal en organizaciones, pedidos
OnLine, entre otras de carácter sencillo. Requiere de PHP 5 o adelante, Drupal
6.16 o 7 y puede correr sobre MySQL 4.1 y mayor o PostGres SQL. (Drupal)
Existen extensiones de Drupal teles como EntityForms que tienen resultados
similares bajo metodologías similares.
3.4. JOOMLA
Joomla es una de las plataformas de administración de contenido más populares
en el mundo, adicionalmente dentro de sus funcionalidades permite la creación de
formularios para recolección de información. Es orientado a la comunidad de
Software Abierto y estructura sus desarrollos y nuevos Releases de acuerdo a
ella. Los estándares de definición de formularios de Joomla están estructurados
con programación orientada a objetos y diseñado con el patrón MVC (Modelo
Vista Controlador). Soporta más de 60 idiomas y tiene más de 9400 extensiones
basadas en los desarrollos de la comunidad. (JOOMLA)
3.5. Magento Web Forms Community Edition
Esta es una aplicación web de código abierto basada en desarrollos WEB. Es un
módulo de Magento que permite crear formularios a la medida para las
necesidades del desarrollador. Tiene múltiples componentes para la creación de
formularios como: Diseñador de Formularios, Validación automática de campos,
Administración simple de contenido, Google ReCaptcha, Notificaciones por correo
electrónico, entrevistas interactivas y desarrollo declarativo. (Magento)
13
4. Arquitectura
En esta sección serán ilustradas las arquitecturas de solución e información de la
herramienta y adicionalmente se mostrarán los principales casos de uso de
interacción con el sistema.
4.1. Arquitectura de Solución
Esta es la arquitectura planteada para la herramienta y tiene las siguientes
características:
El aplicativo del administrador es únicamente accesible por el mismo
administrador (Generalmente relacionado con IT o administración del proyecto),
está instalado únicamente en su/s máquina/s e interactúa a través de dos tres
tipos de interfaz:
Para acceder al aplicativo propio de administración del sistema que actúa como
componente global, el administrador ejecuta un aplicativo SWING que le permite
administrar roles, usuarios, permisos y proyectos de la institución y que además le
da la opción de hacer un “preview” de las HTML pages que generaría el lenguaje
de dominio específico y como este se valida con el modelo base (Soportado por el
metamodelo).
14
Para definir el lenguaje de dominio específico el administrador debe ejecutar una
instancia de eclipse generada por XTEXT que contiene el compilador y parser de
la gramática definida para esta función.
Para crear el modelo base/metamodelo también interactuará a través de eclipse,
pues el editor es un plugIn desarrollado para este IDE.
Entendiendo el funcionamiento del aplicativo del administrador, su output son los
dos archivos de los modelos generados con el plugIn(Modelo base y metamodelo)
y el resultado del desarrollo del lenguaje de creación de los formularios.
Adicionalmente el administrador tiene un output que son los HTML files del
preview que le genera su aplicativo.
Estos mismos outputs sirven también como inputs de los aplicativos para
entrevistadores:
El lenguaje de dominio específico es importado por un componente en el aplicativo
del entrevistador y almacena el resultado en la base de datos centralizadora.
Posteriormente el aplicativo usará la información almacenada para generar los
formularios de entrevistas.
Adicionalmente el aplicativo del entrevistador tiene una arquitectura sencilla que
contiene:
Un componente de control de la base de datos que se encarga de hacer todas las
operaciones relacionadas a ella.
Un componente manejador de la lógica en donde se encuentran las clases .java
con operaciones de apoyo y los beans que manejan las páginas JSF.
Un componente de fachada o “WEB” que tiene todo el contenido de las librerías de
JSF y PrimeFaces sobre páginas .xhtml en donde se construye la interfaz y se
define la navegación (Nota: Solamente en una de las páginas .xhtml se usa Java
Script).
15
4.2. Casos de Uso
Caso de Uso Permiso Descripción
Administración de Roles e identidades de usuarios.
Administrador El administrador es el encargado de agregar, eliminar y modificar el los usuarios (Entrevistadores) del sistema y administra su información personal.
Administración de Proyectos
Administrador Para la institución, el administrador tiene la potestad de agregar y definir nuevos proyectos de recolección de información a través de formularios que utilizaran la herramienta.
Administración de Permisos
Administrador El administrador puede definir que usuarios podrán tener acceso a los formularios definidos para diferentes proyectos.
Creación de formularios con LDE
Administrador El administrador ( o su representación en IT) es quien usa la instancia de compilación de la gramática definida para el lenguaje de dominio específico de los formularios y de esta forma define la estructura de los mismos
Creación del Modelo base y Metamodelo
Administrador El administrador ( o su representación en IT) es quien define el modelo base para los formularios y paralelamente su metamodelo
Verificación de páginas HTML
Administrador El administrador podrá validar como quedan las páginas HTML con su aplicativo que puede leer el resultado de la definición de los formularios.
Validación de LDE con Administrador Teniendo la definición de los
16
Modelo Base formularios con el lenguaje de dominio específico, el administrador podrá preguntarle a su aplicativo si su modelo base es coherente con el mismo (Tema que se tiene que fijar mientras lo construye), en caso contrario el aplicativo le sugiere modificarlo.
Ejecución de Entrevistas
Entrevistador Con toda la base lista, el entrevistador puede ejecutar la entrevista (partida por sesiones) con la herramienta de entrevistas.
FeedBack Entrevistador El Entrevistador puede dar feedback sobre los formularios y recibirlo inmediatamente en instancias propias de los formularios.
4.3. Arquitectura de Información
A continuación será ilustrada la arquitectura de información que se utiliza en la
base de datos centralizadora. El modelo de datos está diseñado para:
Ser genérico y lograr administrar la información de diferentes definiciones
de recolección de información.
Ser independiente de la definición de los modelos (una vez su información
sea almacenada) para lograr apoyar la creación de diferentes instancias de
entrevistas.
Permitir la administración y gobierno de los proyectos y usuarios del
sistema.
17
Nota: Existen algunos cambios del modelo de datos a medida que se lleva a cabo el desarrollo.
18
5. Lenguaje de Dominio específico para Formularios
El lenguaje de dominio específico para la definición de formularios está construido
en XTEXT y tiene las siguientes características para su uso:
Las entidades de información tienen varios formularios.
Cada formulario tiene un conjunto de atributos.
El atributo puede ser de diferentes tipos:
o Cadena: Campo de texto a llenar
o Número: Campo para ingresar un valor numérico
o Decimales: Campo para ingresar un valor de un número con
decimales
o Boleano: Campo para elegir una opción binaria representada por
VERDARERO y FALSO
o Referencia: Campo para elegir como referencia una instancia
existente de algún formulario
o Lista Cadena: Campo para elegir una opción entre varias
o Lista referencia: Campo para elegir varias instancias de algún
formulario existente
o CajaCheck: CheckBox
o RadioBotones: Listado de Radiobotones
o Archivo: Dialogo de búsqueda de un archivo adjunto
o URL: Ingreso de alguna URL útil para la recolección de la
información
La definición de los formularios será validada con constraints que permitirán
brindar una calidad de formularios acorde a los procesos planteados para la
recolección de la información.
A continuación un ejemplo de una página (.miFormulario) que servirá de guía
básica para aquellos que comenzarán a utilizar el compilador. Después del
ejemplo ( ya habiéndolo entendido) se realizarán comentarios sobre el mismo.
Ejemplo de la definición de formularios para un proyecto de AE:
/**
* formulario aplicaciones
19
*/
formulario aplicaciones ?
"APPS" ! {
atributo nombre_aplicacion -- cadena "AppDefault default
nombre" --
atributo numero_lineas_codigo -- numero 12 --
atributo vesrion_aplicativo -- decimal 15,65 --
atributo compatible_windows -- boleano verdadero --
atributo proceso_1 -- referencia procesos ! "Ninguno" --
atributo identificadores_externos -- listaCadena (
cadena "Identificador 1"
cadena "Identificador 2"
cadena "Identificador 3"
cadena "nombre varios"
cadena "que se puedan poner"
cadena "Identificador 4"
) --
atributo sistemas_operativos_validos -- listaReferencia
SOs ! "Ninguno" --
}
?
// Procesos
formulario procesos ?
"PROC" ! {
atributo nombre_proceso -- cadena "AppDefault default
proccc" --
atributo actividades -- listaCadena (
cadena "Inicio"
20
cadena "registro"
cadena "vender"
cadena "añadir"
cadena "adquirir"
cadena "Entregar"
) --
atributo maximo_personas_accesibles -- numero 15 --
atributo radioBotones_Terminacion_proceso -- radios (
cadena "Múltiple"
cadena "Única"
cadena "Opcional"
cadena "Custom Made"
) --
atributo archivo_imagen_diagrama_X -- archivo
"ElijaRuta" --
atributo URL_Website_Interno_aplicativo -- URL "Escriba su
URL Disponible" --
}
?
//SOs
formulario SOs?
"SOS" ! {
atributo nombre_Sistema_Operativo -- cadena "Escriba el
Nombre de su SO" --
atributo decimal_Cualquiera -- decimal 2345,7643 --
atributo vendible -- boleano verdadero --
atributo versiones_disponibles -- cajas (
cadena "12.34jjd"
21
cadena "jjjjj"
cadena "15"
) --
}
?
Comentarios:
Nota: las variables en los ejemplos serán encerradas con [Variable].
El cuerpo de la definición de formularios estará delimitado por la
instanciación del formularios apoyado por signos de interrogación(“?”)
representando el principio y el fin del cuerpo:
o formulario [NOMBRE DEL FORMULARIO] ? [CUERPO DE LA DEFINICIÓN
DEL FORMULARIO] ?
Antes de comenzar a listar los atributos (Pero ya dentro del cuerpo de la
definición de dicho formulario) y con fines de asegurar la calidad de la
información, quien define el formulario deberá darle un ID único al mismo.
Una vez planteado el ID, se procederá a definir los campos de los
formularios encerrados por los corchetes (“{ }”). Para simbolizar la
terminación de la definición del ID del formulario se debe poner un signo de
admiración (“!”). El ID único del formulario será encerrado en comillas
dobles (“ ” ” ”):
o "[ID ÚNICO DEL FORMULARIO QUE ESTÁ SIENDO DEFINIDO]" ! { [ESPACIO
PARA DEFINIR LOS ATRIBUTOS DEL FROMULARIO QUE SE VERÁN
REFLEJADOS COMO CAMPOS DEL MISMO] }
Para la definición de un atributo (Campo), se maneja una estructura sencilla
que aplica para todos los tipos de campo de un formulario (véanse en
anexos en la definición de la gramática). Primero, para definir cada atributo
se comienza escribiendo la palabra “atributo”, a continuación se escribe el
nombre del atributo y para terminar se define el atributo según su tipo. La
definición del atributo será delimitada por doble guión medio al comienzo y
al final (“ -- ”):
22
o atributo [NOMBRE DEL ATRIBUTO/CAMPO] – [TIPO DEL ATRIBUTO +
DEFINICIÓN DEL ATRIBUTO DEPENDIENDO DE SU TIPO] --
6. Conclusiones
Los beneficios que tiene una empresa/institución al usar esta herramienta
van desde la simplicidad y flexibilidad de la misma para ejecutar entrevistas,
pasan por la facilidad de definición, administración y gobierno de un
proyecto de este tipo y llegan hasta la posibilidad de tener la información
centralizada de una forma genérica para poder llevar a cabo múltiples
proyectos sin modificaciones a un modelo de datos único.
El gobierno de un proyecto de recolección de información a través de
formularios se ve facilitado por la posibilidad de ejecutar la administración
del proyecto de una forma desligada de la ejecución de las entrevistas. Lo
anterior permite al administrador un planteamiento independiente de
proyectos sin necesidad de afectar los que están siendo ejecutados.
Los entrevistadores que hacen uso del aplicativo WEB, podrán ejecutar sus
entrevistas partidas en diferentes sesiones y ofreciendo retroalimentación
sobre los formularios que usan. Dicha retroalimentación podrá ser reflejada
inmediatamente y anunciada en administración.
Definir un lenguaje de dominio específico para ser usado en la definición de
la estructura de los formularios trae consigo la ventaja de formalizar las
metodologías que se llevarán a cabo en los proyectos que usen dichos
formularios y de tal manera permitir que exista una buena calidad en la
23
información resultante del proyecto así como la ejecución cómoda y
estructurada del mismo.
Tener una base de datos que centralice la información a través de una
estructura genérica, permite al proyecto asegurar consistencia en los
procesos de recolección de información así como diversidad para
plantearlos.
La posibilidad de los entrevistadores para brindar retroalimentación sobre
los formularios que están usando para recolectar la información, perite a los
mismos lograr una recolección de información completa así como permite a
los administradores una visión gerencial de los proyectos a través de estas
sugerencias.
Una herramienta construida con diferentes tecnologías permite apalancar
los beneficios de cada una de ellas para el proceso de desarrollo de la
misma.
Con la culminación de este proyecto, se podrá ofrecer al mercado una
herramienta abierta con características óptimas que en este momento es
complicada de encontrar.
Las etapas del desarrollo de la herramienta permitieron brindar una visión
más amplia de la problemática en proyectos de recolección de información
(Problema a solucionar) a través de metodologías que involucraban
pruebas sobre ejemplos variados.
24
7. Referencias
Drupal. (s.f.). Drupal Projects. Obtenido de Drupal WebForms: https://drupal.org/project/webform
Eclipse. (s.f.). Eclipse for EMF. Recuperado el 02 de 06 de 2013, de Eclipse Modelig Framework:
http://www.eclipse.org/modeling/emf/
JOOMLA. (s.f.). JOOMLA. Obtenido de JOOMLA ORG: http://extensions.joomla.org/
Magento. (s.f.). Magento WebForms Connect. Obtenido de Magento Web Forms Com E:
http://www.magentocommerce.com/magento-connect/rebimol/extension/7232/webforms
Microsoft. (s.f.). MSDN. Obtenido de Microsoft for WnForms / Windows Forms - .NET Framework:
http://www.microsoft.com/events/series/windowsforms.mspx
Oracle. (s.f.). OTN. Recuperado el 28 de 05 de 2013, de Oracle Technology Network - Forms 11g
Section: http://www.oracle.com/technetwork/developer-tools/forms/overview/index.html
OTN. (s.f.). Oracle Technology Network. Recuperado el 04 de 06 de 2013, de Oracle:
http://www.oracle.com/technetwork/java/javaee/overview-140548.html
XTEXT. (06 de 04 de 2013). Eclipse Org for XTEXT. Obtenido de XTEXT:
http://www.eclipse.org/Xtext/
25
8. Anexos
8.1. Gramática
Ahora señalada con amarillo será visualizada la definición de la gramática del
lenguaje de dominio específico:
grammar org.xtext.example.formulario.MiFormulario with
org.eclipse.xtext.xbase.Xbase
generate miFormulario
"http://www.xtext.org/example/formulario/MiFormulario"
// Define el Modelo para empezar y dice que puede tener varios
formularios
// Siempre '!' Separa y '?' Finaliza
ModeloFormulario:
metaentidades += Formulario*;
// Da un nombre a un formulario y da el listado (En ese orden) de
sus atributos
// Ej:
// El valotID sera el titulo del formulario y su valor a referir
// formulario aplicaciones App1(Default "SE USA A MODO DE
REFERENCIA") ! {nombreAplicacion , version , instaladoEn}?
Formulario:
'formulario' name=ID '?' valorID=STRING '!' '{'atributos +=
Atributo*'}' '?'
;
// Define un atributo dando su :
// 1) Nombre : nombre del atributo y texto de visualización
// 2)Valor : Tipo de Valor que tendrá este atributo definido por
TipoValor que delega varias posibilidades
26
// Ej:
//
Atributo:
'atributo' name=ID '--' valor=TipoValor '--'
;
//----------------------------------------------
// START CONTENIDO DEL ATRIBUTO
//----------------------------------------------
// Define el Tipo de Valor que delega a Cualquiera de los Tipos
de Valor Posibles
// El tipo valor contiene para cada tipo establecido lo
siguiente:
// 'Valor' ! {ReglasAplicables} ?
TipoValor:
Cadena | Numero | Decimales | Boleano | Referencia |
ListaCadena |
ListaReferencia | CajaCheck | RadioBotones | Archivo | URL
;
//----------------------------------------------
// START TIPOS DE VALOR
//----------------------------------------------
// Para el Tipo "Cadena" especifica si definición
// Ej:
Cadena:
'cadena' valorCadena=STRING
;
// Para el Tipo "Numero" especifica su definición
27
// Ej:
// numero DEFAULT_VALUE
Numero:
'numero' valorNumero=INT
;
Decimales:
'decimal' valorDecimal=DOUBLE
;
terminal DOUBLE : INT','INT;
Boleano:
'boleano' valorBoleano=BINARIO
;
terminal BINARIO : 'verdadero' | 'falso' ;
Referencia:
'referencia' superType = [Formulario] '!' valorIDRef=STRING
;
ListaCadena:
'listaCadena'
'(' cadenas += Cadena* ')'
;
ListaReferencia:
'listaReferencia' superType = [Formulario] '!'
valorIDRef=STRING
;
CajaCheck:
'cajas' '('Cajas += Cadena*')'
;
28
//terminal CADENA_CAJA : STRING 'seleccionada' BINARIO ;
RadioBotones:
'radios' '('Radios += Cadena*')'
;
Archivo:
'archivo' valorRuta=STRING
;
URL:
'URL' valorLink=STRING
;
//----------------------------------------------
// END TIPOS DE VALOR
//----------------------------------------------
//----------------------------------------------
// END CONTENIDO DEL ATRIBUTO
//----------------------------------------------
29