Un sistema de desarrollo de interfaces web basado en

Transcripción

Un sistema de desarrollo de interfaces web basado en
modelos para aplicaciones de gestión
Delgado A.1, Estepa A.1, Troyano J.A.2, Estepa R.1
1
Escuela Superior de Ingenieros. C/ Camino de los descubrimientos s/n. 41092
Sevilla, Spain {aldelgado, aestepa, rafa}@trajano.us.es
2
Escuela Técnica Superior de Informática. C/ Reina Mercedes s/n. 41012
Sevilla, Spain [email protected]
Resumen En este artículo se presenta WAINE (Web Application INterface
Engine), un entorno orientado al dominio de las aplicaciones de gestión para el
desarrollo de interfaces de usuario basado en modelos. WAINE permite un
desarrollo rápido, un alto grado de reutilización y ofrece flexibilidad en diversos
niveles, por ello es muy adecuado para la producción en entornos profesionales.
Para validar estas ventajas frente a otras alternativas de desarrollo, se han
construido un conjunto de aplicaciones de ejemplo, cuantificando el esfuerzo
invertido en el desarrollo.
1
Introducción
En las últimas dos décadas ha habido un importante esfuerzo de investigación dentro
del campo de la interacción humano-computadora (IHC). Fruto de ese esfuerzo han
emergido los sistemas de desarrollo de interfaces de usuarios basados en modelos
(Model-Based User Interface Development Environments, MB-UIDEs [1]) y los
lenguajes de definición de interfaces de usuario (User Interface Definition languages,
UIDLs [2]). Los MB-UIDEs permiten modelar formalmente los usuarios, las tareas y la
presentación de un interfaz de usuario y posteriormente emplear esos modelos para
guiar todo el proceso de construcción de la interfaz. Los UIDLs son lenguajes de alto
nivel para describir las características de interés del interfaz de usuario respecto al resto
de una aplicación interactiva. Así que los UIDLs potencialmente pueden ser empleados
para describir formalmente algunos de los modelos empleados por los MB-UIDEs.
Sin embargo, el mundo de la industria de las tecnologías de la información (TI) ha
sido incapaz de asimilar estos avances. Los investigadores aducen que aunque algunos
de los sistemas propuestos pueden generar interfaces de usuario de una manera
automática, en su mayoría estos sistemas están acotados a un dominio específico y su
aplicación no puede ser generalizada [3,4]. Por esta razón gran parte de la investigación
en este ámbito se ha enfocado a proponer MB-UIDES y UIDLs de propósito general y
que permiten generar interfaces de usuario (IUs) para múltiples dispositivos y para
aplicaciones de cualquier dominio (AUIML [5], UIML [6], XIML [7], etc...). Es
IX Congreso Internacional Interacción, Albacete 9-11 de Junio de 2008
Grupo LoUISE-Universidad de Castilla-La Mancha
414 A. Delgado, A. Estepa, J. A. Troyano, R. Estepa
posible que esta línea haya alejado aún más del mundo empresarial las propuestas
provenientes de la investigación.
Estamos convencidos de que la construcción de IUs empleando MB-UIDEs y
UIDLs será finalmente adoptada por las TIs, pero para ello, será necesario reducir la
complejidad que presentan los sistemas actuales así como cumplir algunos requisitos
demandados por la industria. En primer lugar, es necesario acotar el dominio de los
MB-UIDEs y el número de dispositivos para los que se generan IUs. Esto permitirá
reducir la complejidad de los generadores automáticos de IUs y la de la sintaxis de los
UIDLs empleados. Para acercar estos sistemas a la industria es importante utilizar
lenguajes de modelado conocidos por los desarrolladores siempre que sea posible.
Finalmente, es indispensable ofrecer herramientas para la reutilización de IUs
construidos con anterioridad (sólo unos pocos UIDLs lo permiten hoy día y de una
forma limitada: XICL [8], XUL [9]). Otros requisitos demandados por la industria son:
el desarrollo rápido de los IUs, la independencia a diversos niveles (S.O., BB.DD.,
etc...) y la seguridad (aspecto sobre el que hay pocas propuestas).
En este artículo se presenta WAINE, un MB-UIDE con el objetivo de ser empleado
en proyectos profesionales sobre un dominio reducido que comprende la problemática
de las aplicaciones de gestión. Este MB-UIDE utiliza un UIDL muy sencillo para la
descripción de varios modelos de la IU (MIUs), permitiendo emplear otros lenguajes
bien conocidos en algunos de ellos. También permite la reutilización de los modelos
existentes de manera flexible.
El resto del artículo tiene la siguiente estructura. La siguiente sección trata los
modelos empleados por el MB-UIDE. La sección 3 presenta el lenguaje desarrollado
para el modelado de la IU. La sección 4 describe brevemente la arquitectura del
sistema. Los aspectos relacionados con la reutilización del modelado se tratan en la
sección 5 y en la 6 se muestra un resumen de las aplicaciones desarrolladas con
WAINE. Finalmente, la sección 7 concluye el artículo.
2
Modelado de la IU en WAINE
Aunque no existe un acuerdo sobre cuál es el conjunto mínimo de modelos para
definir una IU, normalmente en los MB-UIDEs aparecen los siguientes modelos: de
dominio, de usuarios, de tareas-diálogos y de presentación [1]. En esta sección se va a
describir cada componente de los modelos que hemos elegido para describir una IU en
WAINE. Posteriormente se explicará la relación de dichos elementos empleando para
ello un diagrama entidad relación (DER).
2.1.
Particularización de los modelos para WAINE
WAINE utiliza un conjunto muy simplificado de modelos declarativos para
especificar los aspectos relevantes de la IU. Pensamos que es uno de los factores clave
para el éxito del MB-UIDE.
El modelo de dominio: En el caso particular de WAINE el dominio de las
aplicaciones está acotado a los sistemas típicos de gestión (p.e. sistemas de control
de stock, de acreditaciones, etc...). Generalmente se emplea un DER o un diagrama
Un sistema de desarrollo de interfaces web basado en modelos
415
de clases (DC) para especificar el modelo del dominio (MDO). Posteriormente, estos
diagramas pueden ser traducidos a un conjunto de tablas o clases empleando
herramientas para la generación automática de código.
El modelo de usuario: Los usuarios se clasifican en grupos que representan a los
diferentes roles. El acceso a las diferentes tareas que un usuario puede realizar desde
la IU está basado en asignar diferentes menús a grupos de usuarios o a usuarios
particulares. Un usuario tiene entre sus atributos un nombre, algún tipo de
información para su autentificación, un menú principal, su perfil (que permite
personalizar el sistema a sus preferencias).
El modelo de tareas: Como se ha comentado en el punto anterior, las actividades
que un usuario puede realizar en el sistema estarán restringidas a aquellas a las que
puede acceder a través de los menús a los que tiene acceso. Con ello se persigue una
simplificación del modelo de tareas (MT).
Fig. 1. (a) Relación de usuarios, menús y opciones. (b) Modelos de la IU.
Como se muestra en la figura 1.a los usuarios tienen asociado un menú principal,
que está compuesto por un conjunto de opciones. Cada opción permite lanzar un
formulario, una acción o simplemente enlazar con otro recurso empleando una URL.
Generalmente las acciones se invocan para ejecutar determinadas funcionalidades
del sistema y los formularios para presentar/manipular datos.
El modelo de presentación abstracta: En el modelo de presentación abstracta
(MPA) el elemento básico es el formulario. Se pueden definir dos tipos de
formularios:
1. Formularios simples: Los formularios simples se emplean para presentar y/o
manipular datos que provienen de una entidad del MDO (o sea, una tabla o un
objeto). Las principales propiedades de un formulario simple son su origen de
datos, un conjunto de campos, un conjunto de acciones y un conjunto de eventos.
Un campo se caracteriza por su tipo y origen. El tipo representa el dominio del
campo, es decir el conjunto de valores que el campo admite. El origen del campo
es un sólo elemento del origen de datos del formulario (por ejemplo una columna
de una tabla en una base de datos). Algunas veces el origen de un campo puede
ser una expresión en la que intervienen valores de otros campos, en este caso les
llamamos campos calculados. Finalmente hay que indicar que un campo dispone
de atributos como sólo-lectura/lectura-escritura o visible/oculto. Estos atributos
pueden ser modificados para obtener distintas vistas de un formulario.
2. Formularios compuestos: En muchos casos, un conjunto de elementos del MDO
están relacionados entre sí, y un formulario simple no es suficiente para construir
un IU usable. Los formularios compuestos (llamados structs en nuestro modelo)
son formularios cuyas componentes son otros formularios (simples o compuestos,
ver figura 3.b).
El modelo de presentación concreta: En el modelo de presentación concreta
(MPC) se especifican aspectos como colores, fuentes, widgets, plantillas para
formularios, etc... Estos parámetros pueden ser asignados a la aplicación completa o
un determinado formulario, menú, usuario o grupo.
Se pueden emplear distintos métodos para distribuir los campos en un formulario
(p.e. combo, tabla, ficha, rejilla, etc...). Pero un programador podría definir sus
propios métodos de distribución extendiendo clases existentes o creando algunas
nuevas. También es posible definir la distribución de campos para un formulario
concreto empleando plantillas de formularios.
Finalmente un widget define cómo un campo debe ser presentado y editado. Los
programadores pueden escribir sus propios widgets para mejorar la usabilidad de su
IU creando algunos nuevos o parametrizando los existentes.
Modelo de seguridad: Aunque no nos consta la existencia de trabajos en los que se
defina un modelo de seguridad en MB-UIDEs, creemos que es necesario desarrollar
este modelo para que estos sistemas sean aceptados por las TIs. El principal objeto
de este modelo es la lista de control de acceso (LCA) que controla el acceso de los
usuarios o grupos a las acciones del sistema o a las funcionalidades ofrecidas por los
formularios.
2.2.
Enlazando los modelos
Para enlazar los modelos de la IU al MDO se emplean acciones y eventos. Las
acciones son procedimientos disparados o por un botón de un formulario o por una
opción de un menú. Una acción puede también dispararse de forma automática antes o
después de un evento como la creación/destrucción de un formulario o el empleo de
acciones de manipulación de datos. En el conjunto de acciones potenciales que pueden
ser incluidas en un formulario, como mínimo deben aparecer las del modelo CRUD
(Create, Retrieve, Update and Delete), pero el sistema debe permitir a los usuarios
definir sus propias acciones y eventos.
2.3.
Relación entre objetos del modelo
Finalmente, como resumen de todo lo expuesto en esta sección, todos los
componentes de los modelos de la IU son representados en un DER (ver la figura 1.b).
417
De acuerdo con este diagrama, podemos potencialmente almacenar todos los
componentes de los modelos de la IU en una base de datos y generar a partir de ella las
IUs de forma automática. Esta es la idea en la que se basa la arquitectura que se
presenta en la sección 4.
3
El lenguaje de modelado
XML se ha convertido en un estándar de-facto en muchos campos de las tecnologías
de la información y la IHM no es una excepción. En la tabla 1 se muestra un breve
resumen de algunos UIDLs basados en XML. Para cada lenguaje se muestra los
modelos que soporta y el número de etiquetas que emplea (como un indicador básico
de su complejidad).
Lenguaje
AUIML
ASL
IMML
UsiXML
UIML
XICL
XIML
XUL
MDO
MU
X
X
X
X
X
X
MT
X
X
X
X
X
X
X
X
MPA
X
X
X
X
X
X
X
X
MPC
~
X
X
tags
Más de 55
50
52
1195
36
13
106
Más de 60
Tabla 1. Comparativa de UIDLs
Aunque estos lenguajes reúnen un conjunto de características bastante
interesantes [2], se ha optado por la definición de un UIDL propio para el MB-UIDE
por las siguientes razones:
1. No todos los lenguajes están disponibles de forma libre (e.g XIML).
2. Algunos lenguajes presentan demasiada complejidad para los objetivos que se
pretenden alcanzar (e.g UsiXML, ver columna tags de la tabla 1).
3. Algunos lenguajes están orientados a la solución de otros problemas (p.e. XUL,
XICL, etc...).
4. Otros no dan soporte suficiente para modelar la IU de un sistema completo (p.e.
AUIML, UIML, XUL, XICL).
5. En general, los UIDLs existentes son complejos y presentan una larga curva de
aprendizaje.
El UIDL que se propone es un lenguaje XML llamado ASL (Application interface
Specification Language). Se ha diseñado con los objetivos de obtener un equilibrio
entre en número de modelos soportado y su complejidad. De este modo, ASL sólo
soporta el MU, MT, MPA, y algunos aspectos del MPC. Otros aspectos del MPC como
colores, fuentes, etc... se pueden especificar en archivos de configuración o empleando
CSS. Las plantillas para los formularios se pueden especificar en HTML con
comentarios especiales. La estructura de un documento ASL tiene las siguientes
secciones:
La cabecera: Suele contener meta-información del documento (p.e. autor, fecha de
creación, etc...).
Grupos y usuarios: Descripción usuarios, grupos y sus propiedades.
Menús: Conjunto de los menús a los que pueden acceder los usuarios.
Formularios y structs: Formularios simples y compuestos de la IU.
LCAs: Listas de control de acceso implicando a usuarios/grupos con
formularios/acciones.
La sintaxis completa para el lenguaje ASL en formato dtd está disponible en
http://waine.us.es/DTD/WAINE/0.1/asl.dtd. En el Apéndice A se muestra parte del
código para una aplicación de ejemplo. El código completo, esquema de la base de
datos y acceso a dicha aplicación está disponible en http://waine.us.es/demo/sample.
4
Arquitectura del MB-UIDE
Esta sección presenta la arquitectura implementada, que está basada en cuatro
elementos principales como se ilustra en la figura 2:
Fig. 2. Arquitectura del sistema
El repositorio del MDO (RMDO). Mantiene los objetos de la capa de negocio. El
sistema usa una capa de abstracción de acceso a datos extensible que permite la
conexión a distintas fuentes de datos, lo que proporciona independencia en este
sentido.
El repositorio de los MIUs (RMIU). Como se ha comentado anteriormente, se puede
emplear una base de datos para almacenar los elementos de la IU (formularios,
usuarios, etc...). El modelo conceptual de esa base de datos se presenta en la figura
1.b. Como en el punto anterior el (RMIU) es accedido empleando la capa de
abstracción de acceso a datos, lo que permite mayor flexibilidad e independencia al
sistema.
El motor de la IU. El motor es un run-time que accede a la RMIU para obtener la
información necesaria para generar de forma automática los elementos de la IU y
accede al RMDO para realizar las operaciones y/o eventos básicos (create, update,
and delete). Para aquellas aplicaciones en las que existan reglas de negocio
complejas, los desarrolladores pueden definirlas empleando lenguajes de
419
programación. Actualmente es posible definir ese código en PHP, en el lenguaje
nativo del sistema que soporta el RMDO o invocar a procedimientos externos
escritos en cualquier lenguaje de programación. Esto dota de gran flexibilidad al
sistema.
El repositorio de configuraciones. El MPC y otras capacidades del sistema pueden
ser configuradas, personalizadas o extendidas de una forma sencilla asignando
algunos parámetros del repositorio de configuraciones.
5
Reutilización de los modelos
La reutilización de los modelados es un factor clave para que un MB-UIDE pueda
tener aceptación en la industria de las tecnologías de la información. WAINE permite
tres métodos para reutilizar modelados previos o componentes de los mismos.
Xinclude: En aquellos MB-UIDEs que usan UIDLs basados en XML, el empleo de
XInclude representa un método inmediato para reutilizar especificaciones previas o
fragmentos de las mismas, así como para modularizar especificaciones extensas.
Cualquier objeto de un modelado previo también puede ser extraído a un documento
XML e incluido en nuevas especificaciones que requieran de su funcionalidad.
Paquetes: Los paquetes son empleados ampliamente en informática, sin embargo su
uso para la reutilización de modelos de IUs no ha sido propuesta aún. Los paquetes
permiten reutilizar componentes de un modelado previo aunque el lenguaje de
modelado no esté basado en XML. De hecho, normalmente un componente
reutilizable de cierta complejidad en la IU necesitará de objetos pertenecientes a
distintos modelos y en cada uno de esos modelos pueden emplearse lenguajes
distintos.
Centralización y federación de repositorios de IUs: Como se ha comentado en la
sección 4 WAINE utiliza un repositorio para almacenar los objetos de los modelos
de la IU. Esto permite que objetos de modelado comunes a un grupo de aplicaciones
sea centralizado en un repositorio de uso compartido. También permite que un
nuevo modelado sea construido por federación de objetos de modelados existentes.
6
Aplicaciones desarrolladas
WAINE está siendo empleado desde hace tres años en el desarrollo de diversas
aplicaciones y proyectos de fin de carrera en la Escuela Superior de Ingenieros de la
Universidad de Sevilla (ver http://waine.us.es/demo). Estos proyectos han sido
realizados por alumnos del último curso de Ingeniería de Telecomunicaciones. El
periodo de aprendizaje de las herramientas no excedió un mes y el desarrollo de las
aplicaciones se realizó en un periodo de entre cuatro y seis semanas tras el periodo de
aprendizaje. Según la opinión de los estudiantes, podrían desarrollar una nueva
aplicación de una complejidad similar en menos de dos semanas.
En el año 2.007 WAINE fue seleccionado para desarrollar una serie de aplicaciones
para el centro de proceso de datos de la Escuela Superior de Ingenieros de la
Universidad de Sevilla. Dentro de este programa se han desarrollado hasta el momento
cinco aplicaciones, de las cuales la más importante es un sistema de reservas de
estancias de la escuela (aulas, laboratorios, salas, etc...) ver figura (figura 3.a).
Actualmente se trata de la aplicación de mayor tamaño desarrollada con WAINE,
conteniendo hasta el momento más de 48.000 reservas para el curso actual, siendo
usada por cientos de usuarios (alumnos, profesores y personal no docente) clasificados
en diez grupos.
Fig. 3. (a) Aplicación de reservas. (b) Aplicación de ejemplo (sample)
En la tabla 2 se presentan algunos indicadores de algunas de las aplicaciones
desarrolladas hasta el momento con WAINE. La columna etiquetada como NMOM
indica el número medio de opciones por menú de usuario, la etiquetada como T+V
contiene la suma del número de tablas y vistas de la aplicación. Finalmente la columna
etiquetada con #LC muestra el número de líneas de código ASL necesarias para cada
aplicación.
Aplicación
Dbbibtex
dbconferences
Inveq
m3m
Pracemp
Reservas
Sysbook
Grupos
Users
NMOM
3
3
2
3
1
10
3
3/*
3/*
2/*
3/*
1
10/*
3/*
20,33
15,00
24,00
20,33
20,00
25,67
6,67
Forms
.
27
29
26
42
23
89
9
Structs
46
38
23
62
18
153
22
Acc.
Tablas
Vistas
T+V
26
2
0
3
0
6
3
7
19
16
25
13
34
4
8
3
24
11
7
17
2
15
22
40
36
20
51
6
#LC
1152
1126
721
1721
224
4995
692
Tabla 6. Estadísticas de algunas aplicaciones.
7
Conclusiones
En este artículo se ha presentado WAINE, un MB-UIDE orientado a las aplicaciones
típicas de gestión. El MB-UIDE propuesto permite generar de forma automática los
interfaces web necesarios para una aplicación del dominio: desde el acceso a la
aplicación a los menús o formularios de manipulación de datos. La arquitectura del
sistema presenta independencia a distintos niveles y es flexible y personalizable. La
421
experiencia adquirida tras el desarrollo de varias aplicaciones nos permite concluir que
WAINE es una alternativa factible para el desarrollo de IUs de aplicaciones de mediana
complejidad ya que el sistema presenta una corta línea de aprendizaje, permite un
desarrollo rápido de IUs y la reutilización de modelados previos empleando varios
métodos.
Referencias
1. da Silva, P.P.: User interface declarative models and development environments: A survey.
Interactive Systems - Design, Specification, and Verification: 7th IWS (2001) 207±226
2. Souchon, N., Vanderdonckt, J.: A review of xml-compliant user interface description
languages. LNCS. Interactive Systems. Design, Specification, and Verification 2844 (2003)
377391
3. Ali, M.F., Perez-Quiones, M.A., Shell, E., Abrams, M.: Building multi-platform user
interfaces with uiml. 2002 International Workshop of Computer-Aided Design of User
Interfaces (2002)
4. Puerta, A., Eisenstein, J.: Ximl: A multiple user interface representation framework for
industry. Mutiple UIs: Cross-Platform Applications and Context-Aware Intefaces (2005) 119±
148
5. Azevedo, P., Merrick, R., Roberts, D.: Ovid to auiml - user-oriented interface modelling.
Technical report, UML2000 (2000)
6. Abrams, M., Phanouriou, C., Batongbacal, A.L.: Uiml: An appliance-independent xml user
interface language. (1999)
7. Puerta, A., Eisenstein, J.: Ximl: A universal language for user interfaces. international
conference on Intelligent user interfaces (2002)
8. de Sousa, L.G., Leite, J.C.: XICL An Extensible Mark-up Language for Developing User
Interface and Components. Springer Netherlands (2005)
9. Mozilla: Xul. Technical report
Apéndice A: Código de una aplicación de ejemplo
<asl>
<include href="/usr/local/lib/waine-0.1/include/meta.asl"/>
<head>
<meta class="AppInfo" name="appname" value="sample"/>
<meta class="AppInfo" name="ver" value="0.1"/>
<meta class="AppInfo" name="date" value="2006-09-21"/>
<meta class="AppInfo" name="author" value="A.L.Delgado"/>
</head>
<group gid="1" name="secretary">
<user uid="1" name="joe" passwd="joekey" mainid="main_secretary"/>
</group>
<main id="main_secretary" caption="en=Default user menu|es=Menu del usuario por
defecto">
<menu caption="en=Management|es=Gestion">
<option caption="en=Suggestions|es=Sugerencias" call="st_suggestion"/>
</menu>
<menu caption="en=Misc|es=Otros">
<option caption="en=Author|es=Autor" call="meta.struct.appinfo"/>
<option caption="en=Logout|es=Salir" url="_LOGOUT"/>
</menu>
</main>
...
<form id="frm_people" source="people" caption="People">
<orderby>name</orderby>
<fields>
<key source="pk"/>
<string source="name" caption="Name" len="40" maxlen="80"/>
<string source="address" caption="Address" len="40" maxlen="80"
canbenull="Y"/>
<string source="phone" caption="Phone" len="13" canbenull="Y"/>
<int source="fkcategory" caption="Category">
<search>frm_category</search>
<searchfield>name</searchfield>
</int>
</fields>
<events>...</events>
</form>
...
<struct id="st_suggestion" type="relation">
<param name="form_split" value="rows=80,*"/>
<param name="formid" value="frm_category"/>
<param name="form_type" value="combo"/>
<param ord="2" name="structid" value="st_suggestion_aux"/>
</struct>
<struct id="st_suggestion_aux" type="relation">
<param name="form_split" value="rows=240,*"/>
<param
<param
<param
<param
<param
<param
<param
<param
<param
<param
</struct>
</asl>
name="formid" value="frm_people"/>
name="form_type" value="form"/>
name="button_data" value="1"/>
name="source_filter_field" value="fkcategory"/>
name="navigator_fields" value="name"/>
name="navigator_position" value="W"/>
ord="2"
ord="2"
ord="2"
ord="2"
name="formid" value="frm_suggestion"/>
name="form_type" value="table"/>
name="button_data" value="1"/>
name="source_filter_field" value="fkpeople"/>

Un sistema de desarrollo de interfaces web basado en

Transcripción

Documentos relacionados

¿Sabes que... hacer y qué no en un accidente?

Book II

Request for Baptismal Certificate