Propuestas para la reutilizacion en el desarrollo de interfaces de usuario basado en modelos

Departamento de Lenguajes y Sistemas Inform´aticos Universidad de Sevilla Propuestas para la reutilizaci´on en el Desarrollo de Interfaces de Usuario Basado en Modelos Antonio Luis Delgado Gonz´alez Dirigida por los doctores D. Jos´e A. Troyano y D. Antonio J. Estepa Universidad de Sevilla Memoria de Tesis Doctoral Esta tesis est´a dedicada a mi familia: a mis hijas Ma´ Angeles, Trinidad y Mercedes, a mi esposa Ma´ Angeles, a mis hermanas Ana, MaJes´us y Roc´ıo y a mis padres Antonio y Trinidad. Sin la ayuda, dedicaci´on y amor de todos ellos nunca habr´ıa llegado hasta aqu´ı y este trabajo no habr´ıa sido posible. Agradecimientos A mis tutores de tesis: A Jos´e Antonio Troyano. Por tus indicaciones siempre certeras y por tu ayuda en la revisi´on y correcci´on de documentos. Gracias por allanarme un camino que para mi no era f´acil. A Antonio Estepa, adem´as de tutor, amigo. Gracias por tu ayuda indispensable en la redacci´on de art´ıculos, por tu paciencia, por tu talante y buen humor. Sin tu apoyo, seguramente habr´ıa abandonado esta empresa. Gracias a los dos. Resumen Esta tesis versa sobre la reutilizaci´on en el desarrollo de interfaces de usuario basado en modelos. La baja reusabilidad de las especificaciones de Modelos de la IU ha sido identificada como un posible obst´aculo para la adopci´on del desarrollo de interfaces de usuario basado en modelos por parte de la industria. El objetivo de esta investigaci´on es aportar conocimiento sobre la reutilizaci´on en este ´ambito para mejorar la situaci´on actual de esta tecnolog´ıa. En este trabajo se propone el uso de ciertas t´ecnicas de reutilizaci´on empleadas habitualmente en la ingenier´ıa del software para aplicarlas al desarrollo de interfaces de usuario basado en modelos y ´estas son implementadas sobre un entorno de desarrollo concreto. Este entorno de desarrollo de interfaces de usuario basado en modelos con caracter´ısticas de reutilizaci´on potenciadas es utilizado para construir varias aplicaciones que poseen aspectos comunes. A trav´es de este caso pr´actico y siguiendo un m´etodo emp´ırico, se analiza el impacto que las t´ecnicas de reutilizaci´on han tenido en el desarrollo de las interfaces de usuario. Los resultados son importantes: adem´as del alto grado de reutilizaci´on general (entorno al 46,2 %) se alcanzan picos de reutilizaci´on del 56,9 % para algunos casos particulares y se obtiene un ahorro en el tama˜no de las especificaciones del 71 %. Aunque los resultados obtenidos est´an condicionados por el contexto (entorno de desarrollo, proyectos desarrollados, etc.) se extraen algunas conclusiones aplicables a la generalidad del desarrollo de interfaces de usuario basado en modelos. ´ Indice general ´ Indice de listados 1 1. Introducci´on 1 1.1. Hip´otesis y metodolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Resumen de las aportaciones de la tesis . . . . . . . . . . . . . . . . . . 3 1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Estado del arte 5 2.1. Introducci´on al MB-UID . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Modelos de la interfaz de usuario . . . . . . . . . . . . . . . . . 6 2.1.2. Lenguajes de descripci´on de la interfaz de usuario . . . . . . . . 8 2.1.3. Evoluci´on hist´orica . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Framework de Referencia Cameleon . . . . . . . . . . . . . . . . 12 2.2. Reutilizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1. Soporte para la reutilizaci´on en los UIDLs . . . . . . . . . . . . 22 2.2.2. Desarrollo de interfaces de usuario multi-dispositivo basado en modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.3. M´etodos de reutilizaci´on basados en patrones . . . . . . . . . . 26 2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3. T´ecnicas de reutilizaci´on en el MB-UID 31 3.1. T´ecnicas de reutilizaci´on en especificaciones . . . . . . . . . . . . . . . 32 3.1.1. T´ecnicas soportadas por el lenguaje de especificaci´on . . . . . . 32 3.1.2. Inclusi´on (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.3. Paquetes (P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.4. Bibliotecas de reutilizaci´on (B) . . . . . . . . . . . . . . . . . . 35 3.2. T´ecnicas de reutilizaci´on en repositorios de modelos . . . . . . . . . . . 36 3.2.1. Paquetes (P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.2. Repositorios centralizados (C) . . . . . . . . . . . . . . . . . . . 36 3.2.3. Repositorios federados (F) . . . . . . . . . . . . . . . . . . . . . 37 3.3. Factores a considerar en la selecci´on y aplicaci´on de las t´ecnicas propuestas 39 3.3.1. Arquitectura del MB-UIDE . . . . . . . . . . . . . . . . . . . . 39 3.3.2. Estructura de los recursos reutilizables . . . . . . . . . . . . . . 41 3.3.3. Dominio de reutilizaci´on y otros aspectos . . . . . . . . . . . . . 43 3.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 i 4. WAINE 47 4.1. Introducci´on a WAINE . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.1. Modelos de la interfaz de usuario . . . . . . . . . . . . . . . . . 48 4.1.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.3. Lenguaje de descripci´on de la interfaz de usuario . . . . . . . . 53 4.1.4. Proceso de desarrollo y generaci´on de la interfaz de usuario . . . 55 4.1.5. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . 63 4.2. T´ecnicas de reutilizaci´on soportadas por WAINE . . . . . . . . . . . . . 64 4.2.1. Subespecificaci´on y adaptaci´on (S,A) . . . . . . . . . . . . . . . 64 4.2.2. Herencia (H) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2.3. Inclusi´on y Bibliotecas de reutilizaci´on (I,B) . . . . . . . . . . . 68 4.2.4. Paquetes (P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2.5. Repositorios compartidos: centralizaci´on y federaci´on (C,F) . . . 73 4.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5. Experiencia de reutilizaci´on en el MB-UID 77 5.1. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2. Experiencia cualitativa en la reutilizaci´on . . . . . . . . . . . . . . . . . 81 5.2.1. Subespecificaci´on y adaptaci´on (S,A) . . . . . . . . . . . . . . . 81 5.2.2. Herencia (H) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.3. XInclude y Bibliotecas (I,B) . . . . . . . . . . . . . . . . . . . . 83 5.2.4. Paquetes (P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2.5. Repositorios compartidos (C,F) . . . . . . . . . . . . . . . . . . 85 5.3. Resultados cuantitativos de la reutilizaci´on . . . . . . . . . . . . . . . . 90 5.3.1. Recursos de la interfaz de usuario y cantidad de reutilizaci´on . . 90 5.3.2. Reutilizaci´on en el modelo de presentaci´on . . . . . . . . . . . . 92 5.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6. Conclusiones y trabajos futuros 101 6.1. Lecciones aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.1.1. Sobre la reusabilidad de los modelos y la subespecicaci´on . . . . 102 6.1.2. Sobre el tama˜no y adaptabilidad de los recursos . . . . . . . . . 103 6.1.3. Sobre las t´ecnicas empleadas . . . . . . . . . . . . . . . . . . . . 103 6.2. L´ıneas de investigaci´on abiertas . . . . . . . . . . . . . . . . . . . . . . 104 6.3. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 A. DTD del lenguaje ASL 117 B. Desarrollo de una aplicaci´on 125 C. Componente ASL 135 D. L´ıneas de c´odigo por aplicaci´on 137 E. Obtenci´on de los datos de la tabla 5.2 141 F. Actuaciones de mantenimiento realizadas 145 Cap´ıtulo 1 Introducci´on En el ´ambito industrial y empresarial existe una necesidad continua de incrementar la competitividad para lograr un mejor posicionamiento en el mercado. La productividad es un factor clave de la competitividad y puede ser definida como la relaci´on entre los resultados y los recursos utilizados para obtenerlos [97, 85]. La industria del software est´a obligada a mejorar su productividad constantemente [52] y para conseguirlo emplea diversos m´etodos que permiten reducir el tiempo empleado en las distintas fases de construcci´on de un producto software (an´alisis, dise˜no e implementaci´on). Estos m´etodos tratan, con mayor o menor ´exito, de reutilizar recursos existentes [49, 57] o de generar autom´aticamente productos completos [41, 53, 64] (o al menos partes de los mismos). Hoy en d´ıa, gracias a las aportaciones en distintos campos de la inform´atica, podemos considerar recursos reutilizables requisitos, dise˜nos, modelos o conocimien- to [55, 109, 73] y se generan de forma autom´atica documentaci´on o c´odigo entre otros productos [33, 86]. Como es conocido desde hace d´ecadas, la construcci´on de la interfaz de usuario (IU) de un proyecto software representa entorno al 48 % del c´odigo de la aplicaci´on y cerca del 50 % del tiempo dedicado al desarrollo [82]. Posiblemente en la actualidad la situaci´on sea a´un peor por el n´umero de tecnolog´ıas involucradas en el desarrollo de la interfaz de usuario y la eclosi´on de dispositivos y modalidades de uso (p.ej. gr´aficas, t´actiles o vocales). Es l´ogico, por lo tanto, que diversas aportaciones en el ´ambito del desarrollo de la interfaz de usuario se hayan orientado a conseguir que el desarrollo sea m´as productivo [81, 72]. De entre estas t´ecnicas, el desarrollo de interfaces de usuario basado en modelos (Model-based User Interface Development,MB-UID) [95, 42, 70, 69] describe la interfaz de usuario usando un conjunto de modelos abstractos que constituyen la base del proceso de desarrollo. Al igual que en el paradigma de la ingenier´ıa dirigida por modelos (Model-Driven Engineering, MDE [112]), en el MB-UID los modelos son utilizados para la generaci´on (semi)autom´atica de diversos productos software, entre ellos el c´odigo de la interfaz de usuario. Esto redunda en un proceso de desarrollo de la interfaz de usuario m´as productivo, reduciendo el esfuerzo necesario para su desarrollo y mejorando la calidad del c´odigo generado [95, 125, 69]. Durante las pasadas d´ecadas han proliferado los entornos de desarrollo de la interfaz de usuario basados en modelos [95, 70] (MB-UID environments,MB-UIDEs), dando 1 2 CAP´ ITULO 1. INTRODUCCI´ ON lugar a diferentes herramientas y lenguajes de especificaci´on [45, 70]. Sin embargo, a pesar del n´umero de propuestas disponibles, ning´un MB-UIDE ha experimentado una adopci´on amplia por parte de la industria del software [119, 74]. Algunos autores [95, 4] argumentan que la pobre reusabilidad de las especificaciones de Modelos de la IU puede ser un factor que explique parcialmente esta falta de inter´es por parte de la industria. M´as recientemente, Meixner et al. [70] han apoyado esta idea, apuntando tambi´en a la falta de armonizaci´on entre la MDE y el MB-UID, a la ausencia de referencias de aplicaci´on con ´exito en el mundo industrial y a la escasez de casos de estudio, como retos que deben ser afrontados por los sistemas de MB-UID en el futuro. Entre esos aspectos, esta tesis se enfoca hacia la reutilizaci´on. La comunidad del MB-UID ha realizado avances en la reutilizaci´on de la interfaz de usuario. Algunos lenguajes de especificaci´on han contemplado mecanismos para la reutilizaci´on [50, 18, 19, 2]; existen MB-UIDEs que generan c´odigo para varias plataformas partiendo de una ´unica especificaci´on [7, 100, 125] y tambi´en pueden encontrarse propuestas para la reutilizaci´on basadas en patrones de dise˜no [4, 29, 113]. Sin embargo, no hay literatura espec´ıficamente orientada a analizar la experiencia de reutilizar elementos de la interfaz de usuario, ya sea de forma interna en un proyecto o entre proyectos distintos. Los m´etodos y problemas relacionados con la reutilizaci´on de los componentes de la interfaz de usuario y su coste/beneficio asociado, no han sido tratados por la comunidad del MB-UID. Una posible raz´on de ello puede ser la complejidad del asunto que implica varias cuestiones relacionadas como: (a) qu´e fragmentos de la interfaz de usuario o qu´e modelos pueden ser objeto de reutilizaci´on, (b) qu´e t´ecnicas son apropiadas para la reutilizaci´on, (c) c´omo evaluar los beneficios de la reutilizaci´on en la interfaz de usuario. La respuesta a esas cuestiones se vuelve incluso m´as complicada en la situaci´on actual, ya que como se pone de manifiesto en [70], ciertos est´andares emergentes del W3C sobre determinados Modelos de la IU [91, 122] no han sido a´un ampliamente adoptados y no hay casos de estudio suficientes para permitir analizar los potenciales beneficios de la reutilizaci´on con cierto rigor. 1.1. Hip´otesis y metodolog´ıa Teniendo en consideraci´on la situaci´on actual en el desarrollo de la interfaz de usuario y la necesidad constante de incrementar la productividad y la competitividad, esta investigaci´on se ha centrado en la reutilizaci´on en el MB-UID. Las hip´otesis de este trabajo son las siguientes: Algunas de las t´ecnicas de reutilizaci´on usadas frecuentemente en la ingenier´ıa del software pueden ser aplicadas con ´exito en el MB-UID. Recordemos que la pobre reusabilidad de las especificaciones de Modelos de la IU es uno de los factores que puede explicar la falta de adopci´on del MB-UID por parte de la industria, como ha sido expuesto por algunos autores [95, 4]. Existe por lo tanto un inter´es por parte de la comunidad del MB-UID en incrementar el conocimiento sobre c´omo reutilizar los elementos de los Modelos de la IU y sobre cu´ales son las implicaciones de las t´ecnicas empleadas. 2 1.2. RESUMEN DE LAS APORTACIONES DE LA TESIS 3 Las t´ecnicas de reutilizaci´on anteriores aplicadas al MB-UID reducir´an considerablemente el esfuerzo del desarrollo de la interfaz de usuario. En general, la reutilizaci´on incrementa la productividad en el desarrollo y la calidad de los productos generados como ha quedado de manifiesto en varios estudios [73]. Estos beneficios deber´ıan estar presentes tambi´en en el contexto del MB-UID. Pensamos tambi´en que las t´ecnicas propuestas pueden aportar nuevas v´ıas para la reutilizaci´on de los elementos de la interfaz de usuario a distintos niveles de abstracci´on. Las t´ecnicas permiten reutilizar, desde elementos simples y concretos, a grandes entidades abstractas de una interfaz ofreciendo a los desarrolladores nuevas posibilidades a la hora de construir las interfaces de usuario. En esta tesis se emplea el m´etodo emp´ırico para demostrar las hip´otesis de partida. Se desarrolla un nuevo MB-UIDE, WAINE [20, 21], que implementa las t´ecnicas de reutilizaci´on propuestas. Este MB-UIDE potenciado para la reutilizaci´on ser´a empleado en el desarrollo de varias aplicaciones relacionadas. Finalmente se mide el impacto que las t´ecnicas de reutilizaci´on han tenido en el desarrollo de estas aplicaciones. Aunque los resultado obtenidos est´an condicionados por el entorno (MB-UIDE, proyectos, etc.) se extrer´an algunas ideas aplicables a la generalidad del MB-UID. 1.2. Resumen de las aportaciones de la tesis Son resultados de la investigaci´on descrita en esta tesis las siguientes aportaciones: 1. Una relaci´on de t´ecnicas de reutilizaci´on potencialmente aplicables al MB-UID. La aplicaci´on de algunas de las t´ecnicas propuestas es in´edita y nunca hab´ıan sido empleadas en este ´ambito [22]. 2. Un MB-UIDE con Lenguaje de Descripci´on de la IU propio [20]. Se trata de un sistema que pretende simplificar y acelerar el desarrollo de la interfaz de usuario a estudiantes y programadores sin experiencia. El MB-UIDE implementa las t´ecnicas de reutilizaci´on propuestas en la tesis. Esta implementaci´on sirve como validaci´on a la aplicabilidad de las t´ecnicas de reutilizaci´on en este ´ambito. 3. Un caso de estudio en el que el MB-UID es aplicado con ´exito al desarrollo de varias aplicaciones actualmente en producci´on y que son usadas por cientos de usuarios. Al tratarse de aplicaciones que manejan aspectos comunes, diversas t´ecnicas de reutilizaci´on han sido puestas en pr´actica en la construcci´on de las mismas. Tengamos en cuenta que en [70] se pone de manifiesto que existen pocas referencias a sistemas en funcionamiento y que hay una carencia importante de casos de estudio. En nuestro caso pr´actico, adem´as, se valoran los beneficios obtenidos midiendo el impacto de la reutilizaci´on en el desarrollo de las interfaces de usuario de las distintas aplicaciones. Tambi´en se analizan consecuencias no cuantitativas de la reutilizaci´on, estudiando las distintas posibilidades que ha generado la aplicaci´on de las t´ecnicas propuestas en el desarrollo de la interfaz de usuario. 3 4 CAP´ ITULO 1. INTRODUCCI´ ON 4. Un an´alisis cuantitativo de la reutilizaci´on en la interfaz de usuario en sistemas de MB-UID. Hasta el momento no se ha publicado ning´un an´alisis similar al presentado en este estudio. Se han aplicado m´etricas empleadas de forma usual a la reutilizaci´on en la ingenier´ıa del software a los Modelos de la IU . El an´alisis presentado en este documento puede servir como gu´ıa o modelo para futuros trabajos de reutilizaci´on en la interfaz de usuario. Es necesario tener en cuenta que no todas las conclusiones de esta tesis pueden ser extendidas a la generalidad del MB-UID. Sin embargo, sirven al prop´osito de ilustrar los potenciales beneficios de la reutilizaci´on de los elementos de la interfaz de usuario en ´ambitos internos (en el mismo proyecto) y externos (entre distintos proyectos), aportando indicios para la construcci´on de futuros Lenguajes de Descripci´on de la IU yMB-UIDEs con caracter´ısticas de reutilizaci´on potenciadas. 1.3. Estructura del documento Este apartado presenta la estructura del documento con el fin de facilitar al lector la comprensi´on de este trabajo. La tesis sigue la siguiente estructura. Cap´ıtulo 1. Estado del arte. Se tratan en este apartado las principales propuestas sobre el MB-UID, se comenta su evoluci´on hist´orica y se citan algunos de los sistemas m´as relevantes. Posteriormente, se enumeran las propuestas relacionadas m´as directamente con la reutilizaci´on de la interfaz de usuario en el MB-UID. Cap´ıtulo 2. Presentaci´on de una colecci´on de t´ecnicas de reutilizaci´on potencialmente aplicables al MB-UID. Para cada t´ecnica se nombran experiencias de uso en otros campos y se propone una aplicaci´on determinada en el MB-UID. Cap´ıtulo 3. Explicaci´on detallada de WAINE, el MB-UIDE empleado en las experiencias de esta tesis. Se describe su arquitectura, Lenguaje de Descripci´on de la IU , proceso de desarrollo, etc. Posteriormente se presenta la implementaci´on de las t´ecnicas de reutilizaci´on propuestas en el cap´ıtulo anterior sobre este sistema. Cap´ıtulo 4. Descripci´on de un caso real en el que nuestro MB-UIDE y las t´ecnicas de reutilizaci´on propuestas han sido aplicados al desarrollo de seis aplicaciones. En primer lugar se transmite la experiencia en la aplicaci´on de cada una de las t´ecnicas para posteriormente presentar un an´alisis cuantitativo de la reutilizaci´on. Cap´ıtulo 5. Para finalizar el documento se enumeran las conclusiones de la tesis, se exponen algunas ideas que pueden ser aplicables a la generalidad del MB-UID y se proponen ciertas l´ıneas de investigaci´on como continuaci´on de este trabajo. 4 Cap´ıtulo 2 Estado del arte En este cap´ıtulo se describen los trabajos que guardan relaci´on con los aspectos tratados en esta tesis. Se ha considerado dividir el cap´ıtulo en dos secciones. La primera est´a dedicada al MB-UID y en ella se presenta una panor´amica sobre esta tecnolog´ıa. En la segunda nos centramos en la reutilizaci´on y m´as espec´ıficamente en aquellas aportaciones dentro del MB-UID relacionadas con la reutilizaci´on de Modelos de la IU . 2.1. Introducci´on al MB-UID El MB-UID ofrece un entorno en el que los desarrolladores pueden dise˜nar e implementar interfaces de usuario de una forma profesional, consistente y sistem´atica [95, 42, 70, 69]. Est´a basado en la idea de que la interfaz de usuario puede ser completamente definida por un conjunto de modelos declarativos, cada uno de los cuales trata facetas particulares de la interfaz de usuario como las tareas, la presentaci´on, etc. La especificaci´on de cada modelo consiste en una descripci´on abstracta de los aspectos pertenecientes a su dominio a trav´es de un Lenguaje Descriptivo. Estas especificaciones gu´ıan el ciclo de vida del desarrollo de la interfaz de usuario y son la base para la generaci´on autom´atica de diversos productos software, entre ellos, el c´odigo fuente de la interfaz de usuario. En la figura 2.1 se puede apreciar como en el MB-UID los Modelos de la IU son el n´ucleo del desarrollo de la interfaz de usuario. Los desarrolladores trabajan sobre esos modelos realizando distintas transformaciones directamente con un editor o bien empleando herramientas software especializadas. Finalmente de los Modelos de la IU se extraen de forma autom´atica (o semiautom´atica) diversos productos como el c´odigo de la interfaz de usuario, documentaci´on o diagramas. Los MB-UIDEs son suites de herramientas software que soportan el dise˜no y desarrollo de interfaces de usuario empleando Modelos de la IU [42]. De acuerdo con Schlungbaum [111], existen dos criterios b´asicos para que una herramienta pueda ser considerada un MB-UIDE: 1. Un MB-UIDE debe incluir un modelo abstracto de alto nivel y declarativo sobre el sistema interactivo a desarrollar (p.ej. un Modelo de Tareas, un Modelo de Dominio o ambos). 5 6 CAP´ ITULO 2. ESTADO DEL ARTE MP MU Desarrollador Documentacion Otros Codigo MDO Herramienta Desarrollador especializada MT MD Modelos de la IU []>> Diagramas Productos del desarrollo de la IU Figura 2.1: Desarrollo de la interfaz de usuario basado en modelos 2. El MB-UIDE debe explotar una relaci´on clara y soportada por un proceso computacional desde (1) hasta la interfaz de usuario ejecutable. 2.1.1. Modelos de la interfaz de usuario Puerta [99] define los Modelos de la IU como una representaci´on computacional de los aspectos relevantes de una interfaz de usuario. Szekely [117] define un Modelo de la IU como una especificaci´on declarativa de alto nivel de alg´un aspecto determinado de la interfaz de usuario, como su apariencia, estructura o comportamiento din´amico. Hist´oricamente no ha existido consenso sobre el conjunto de lenguajes y modelos necesarios para describir la interfaz de usuario, por lo tanto, la mayor´ıa de sistemas han definido sus propios lenguajes [115, 45] y modelos [95, 70]. Sin embargo, algunos modelos usados recurrentemente en el MB-UID (ver figura 2.1) fueron identificados sobre la primera d´ecada del 2000 [95, 120]: El Modelo de Usuario (MU) recoge las caracter´ısticas de los usuarios finales clasific´andolos de acuerdo a sus habilidades, su conocimiento de la aplicaci´on o la informaci´on que deben procesar. Algunos sistemas como ADEPT [128], MECANO [102] y TADEUS [25] han utilizado este modelo. El User Modeling Markup Language (UserML) [48] ha representado la propuesta m´as avanzada sobre este modelo. El Modelo de Dominio (MDO) se usa para definir los objetos que son accesibles a los usuarios a trav´es de la interfaz de usuario. Seg´un Silva [95] son constructores usuales de este modelo: clases, atributos, relaciones y operaciones. Para especificar el Modelo de Dominio, se han empleado diversas notaciones: diagramas de clases (OVID [108], WISDOM [83], IDEAS [94], TEALLACH [27], etc.), Diagramas Entidad-Relaci´on (TRIDENT [10], GENIUS [51]), especificaciones algebraicas (ITS), etc. 6 2.1. INTRODUCCI´ ON AL MB-UID 7 El Modelo de Tareas (MT) describe el conjunto de tareas que los usuarios pueden realizar, su descomposici´on en subtareas y sus relaciones temporales y condiciones. Se trata de un modelo de naturaleza jer´arquica, donde se describen diferentes tipos de tareas y las acciones involucradas en su desarrollo. Son elementos frecuentes de este modelo [95]: tareas, objetivos, acciones, precondiciones y postcondiciones. El Modelo de Tareas ha ido adquiriendo gran importancia en la descripci´on de la interfaz de usuario al m´as alto nivel de abstracci´on [91]. En esta evoluci´on se han empleado varias notaciones en la especificaci´on del modelo (HTA, GOMS, TKS, UAN, etc.) [24]. Hoy en d´ıa la notaci´on Concurrent Task Trees (CTT [87, 88, 91]) es ampliamente adoptada. El Modelo de Presentaci´on (MP), est´a dedicado a aspectos de presentaci´on de la interfaz de usuario. Puede ser descompuesto en dos submodelos: •Modelo de Presentaci´on Abstracta (MPA) que trata, a un nivel de descripci´on abstracto la estructura y comportamiento de los objetos de la interfaz de usuario. Son elementos de este modelo los Objetos de Interacci´on Abstracta [123] (Abstract Interaction Objects) que son objetos sin representaci´on gr´afica e independientes de cualquier entorno y las unidades de interacci´on (o espacios de trabajo), una colecci´on de Objetos Abstractos de Interacci´on agrupados de forma l´ogica para tratar con las entradas/salidas de una tarea. •Modelo de Presentaci´on Concreta (MPC) que describe en detalle partes de la interfaz de usuario empleando Objetos de Interacci´on Concreta [123] (Concrete Interaction Objects), elementos ”manipulables” de una interfaz de usuario que pueden ser empleados para mostrar o introducir informaci´on relativa a las tareas del usuario, ventanas (windows), una representaci´on manejable y visible de una vista y layouts, un algoritmo que distribuye los Objetos Concretos de Interacci´on en una ventana. El Modelo de Di´alogo (MD) [68] captura aspectos din´amicos de la interacci´on del usuario con el sistema, incluyendo una especificaci´on de la relaci´on entre unidades de presentaci´on (p.ej. entre ventanas) as´ı como entre elementos de la interfaz de usuario (p.ej. activar/desactivar objetos de interacci´on). Tambi´en soporta la integraci´on con el n´ucleo funcional de la aplicaci´on, lo que requiere un mapeo entre eventos y acciones de acuerdo a restricciones predefinidas [62]. Incluye el conjunto de acciones que el usuario puede llevar a cabo en los distintos estados del sistema y las transiciones entre esos estados. El Modelo de Di´alogo enlaza tareas con elementos de interacci´on formando un puente entre el Modelo de Tareas y el de Presentaci´on [70]. Entre los modelos anteriores, los de Tareas,Presentaci´on yDi´alogo, pueden ser considerados los principales seg´un Meixner [70] ya que son los que tienen una influencia directa en el contenido y apariencia de la interfaz de usuario. 7 8 CAP´ ITULO 2. ESTADO DEL ARTE 2.1.2. Lenguajes de descripci´on de la interfaz de usuario Los Lenguajes de Descripci´on de la IU (User Interface Description Languages, UIDLs [115, 45]) son lenguajes de alto nivel empleados en algunas etapas del desarrollo de la interfaz de usuario para describir las caracter´ısticas interesantes de la interfaz con respecto al resto de la aplicaci´on interactiva. A lo largo de los a˜nos han surgido varias propuestas. Por un lado aquellas destinadas a cubrir la mera descripci´on de interfaces de usuario, como es el caso de UIML, XUL, XAML, Xforms, o AUIML. Por otro, aquellas desarrolladas para dar soporte al MB-UID y que por lo tanto, no se limitan a describir la interfaz sino que facilitan mecanismos para describir, dependiendo de los casos, al usuario, las tareas, el dominio, etc. como XIML, UsiXML o Teresa-XML. En la figura 2.2 se resumen las caracter´ısticas principales de los Lenguajes de Descripci´on de la IU que han tenido mayor difusi´on. En dicha figura aparece en el eje vertical el n´umero de modelos soportados por el lenguaje un indicador de su completitud y en el eje horizontal su a˜no de aparici´on. El radio de la burbuja representa el impacto del lenguaje1. 1 2 3 4 5 6 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 UIML AUIML XUL XIML TeresaXML UsiXML DISL XICL MARIA Figura 2.2: UIDLs: modelos soportados, a˜no de aparici´on e impacto A continuaci´on, pasamos a resumir las propuestas que han tenido mayor difusi´on por orden cronol´ogico: 1Para estimar el impacto de cada lenguaje se utilizado el n´umero de citas seg´un Google Acad´emico. Se ha buscado el art´ıculo con mayor n´umero de referencias que contiene en su t´ıtulo el nombre del lenguaje en cuesti´on. Si no hay art´ıculos que en su t´ıtulo contengan el nombre del lenguaje, se ha empleado el art´ıculo de mayor n´umero de referencias para ese lenguaje en la bibliograf´ıa de esta tesis. 8 2.1. INTRODUCCI´ ON AL MB-UID 9 UIML (User Interface Markup Language) [3, 2, 6] es un lenguaje XML que ofrece un m´etodo para describir una interfaz de usuario independiente del dispositivo, la modalidad y el lenguaje de implementaci´on. Tambi´en permite describir la apariencia, la interacci´on y la conexi´on de la interfaz de usuario con la l´ogica de la aplicaci´on. Aunque UIML es ostensiblemente independiente del dispositivo y del medio utilizado en la presentaci´on, no parece que se tuviera en cuenta en su dise˜no los trabajos de investigaci´on previos sobre interfaces de usuario basados en modelos. Por ejemplo, el lenguaje no provee la noci´on de tarea y principalmente intenta definir una estructura abstracta asociada a la presentaci´on que ofrecer´a la interfaz de usuario. AUIML (Abstract User Interface Markup Language) [7] es un lenguaje que separa la presentaci´on de la sem´antica de la interacci´on, es decir, permite definir el prop´osito de la interacci´on con el usuario en lugar de centrarse en la presentaci´on. Ha sido utilizado en OVID [108] y WISDOM [83] para proporcionar la especificaci´on abstracta de una interfaz de usuario. XUL (XML User Interface Language) [50, 103] es la tecnolog´ıa para interfaces de usuario multiplataforma basada en XML de Mozilla. Esta tecnolog´ıa permite a los desarrolladores definir una interfaz gr´afica multiplataforma para el usuario utilizando una mezcla de XML, HTML, CSS y JavaScript. Un usuario puede modificar cualquier aspecto en la interfaz de usuario de una aplicaci´on Mozilla basada en XUL, simplemente modificando archivos que utilizan la sintaxis est´andar de una p´agina web. En Java existen gran cantidad de APIs para la generaci´on de interfaces de usuario gr´aficas basadas en XUL, por ejemplo: Luxor XUL, XWT, Thinlets o SwingML. XIML (eXtensible Interface Markup Language) [100, 101] es un lenguaje extensible basado en XML para soportar m´ultiples modelos de especificaci´on de interfaces de usuario. Una especificaci´on XIML puede conducir a una interpretaci´on en tiempo de ejecuci´on o a una fase de generaci´on de c´odigo en tiempo de dise˜no. XIML surgi´o como evoluci´on de una propuesta anterior MIMIC [102]. El objetivo de este lenguaje es describir la interfaz de usuario de forma abstracta y posteriormente, obtener una especificaci´on concreta a partir de ella. El desarrollo basado en modelos propuesto por XIML define la interfaz de usuario mediante cinco modelos dedicados a las tareas, dominio, usuario, di´alogo y presentaci´on. TeresaXML [90] es un Lenguaje de Descripci´on de la IU que permite producir interfaces de usuario para diferentes plataformas en tiempo de dise˜no. Es un lenguaje basado en XML die˜nado por F.Patern`o para la especificaci´on de interfaces que adem´as, enlaza con su propuesta anterior para el modelado de tareas CTT [87]. Actualmente se centra en aplicaciones Web. Este lenguaje especifica c´omo se organizan varios Objetos Abstractos de Interacci´on que componen una interfaz de usuario, junto con la especificaci´on del di´alogo de la propia interfaz. UsiXML (User Interface eXtensible Markup Language) [58] propone un lenguaje de descripci´on de interfaces de usuario con el que se asegura poder trabajar 9 16 CAP´ ITULO 2. ESTADO DEL ARTE usuario cuando la aplicaci´on est´a ejecut´andose. La propia aplicaci´on en la primera propuesta (figura 2.4a) y los Run-times de las arquitecturas Mixta eInterpretativa (figuras 2.4b y 2.4c) son Run-times de la IU . Como colof´on de este apartado, en la figura 2.5, extra´ıda en parte de [70], se muestra una comparativa de varias propuestas actuales que siguen el Modelo de Referencia Cameleon, entre ellas la del MB-UIDE empleado en esta tesis. Final User Interface useML DER CAMELEON RF CTT XHTML, VoiceXML... MARIA XML USIXML−CTT USIXML−AUI USIXML−CUI DISL UIML−CUI Java, C++ Concepts & task Model Concrete Interface HTML, CSS, HTML5, Java, GWT... Abstract Interface JavaScript ASL Figura 2.5: Comparativa de propuestas en el framework de referencia Cameleon La primera propuesta utiliza CTT y MARIA. MARIA cubre dos niveles de abstracci´on el nivel de la IU Abstracta y el de la IU Concreta y dispone de una herramienta propia para realizar especificaciones: MARIAE [93]. En segundo lugar UsiXML se estructura de acuerdo a los cuatro niveles de abstracci´on definidos por el framework Cameleon, incluyendo adem´as modelos de contexto y de calidad. La tercera propuesta (de Meixner et al. [71]), est´a basada en tres lenguajes a diferentes niveles de abstracci´on: useML, DISL y UIML. useML [80, 105] fue dise˜nado para soportar el proceso de desarrollo centrado en el usuario (ISO 9241-210) y permite representar los resultados del an´alisis inicial de tareas. DISL se emplea para especificar el Modelo de Di´alogo derivado del Modelo de Tareas expresado en useML. Por ´ultimo, UIML define el Modelo de Presentaci´on. En ´ultimo lugar aparecen los lenguajes utilizados por WAINE. El Modelo de Dominio, expresado mediante un Diagrama Entidad-Relaci´on, comprende el nivel de Conceptos y Tareas. Del Modelo de Dominio se derivan el Modelo de Di´alogo y el Modelo de Presentaci´on que son descritos en un lenguaje denominado ASL [20, 21]. A partir del documento ASL y mediante diversas transformaciones se genera la IU Final compuesta por HTML, CSS y JavaScript. 2.2. Reutilizaci´on En esta segunda secci´on se trata la reutilizaci´on software como disciplina cient´ıfica y posteriormente, se profundiza en aquellos trabajos que tienen una relaci´on m´as estrecha 16 2.2. REUTILIZACI´ ON 17 con el estudio presentado en esta tesis: la reutilizaci´on de la interfaz de usuario en el MB-UID. Una de las bases del proceso de dise˜no en la mayor´ıa de las disciplinas de ingenier´ıa es la reutilizaci´on de sistemas o componentes existentes [114]. En la ingenier´ıa del software, las propuestas para la reutilizaci´on fomentan el desarrollo de sistemas usando elementos preexistentes en lugar de crearlos de nuevo [55, 49]. Desde sus or´ıgenes, la reutilizaci´on ha sido valorada como una v´ıa para superar la crisis del software y se ha propugnado como mecanismo para reducir el tiempo de desarrollo, incrementar la productividad de los desarrolladores y reducir la densidad de errores [49, 11, 73]. La reutilizaci´on del software se puede aplicar a cualquier producto del ciclo de vida del desarrollo, no s´olo al c´odigo fuente. Esto significa que los desarrolladores pueden reutilizar requisitos, especificaciones, dise˜nos y cualquier otro elemento del ciclo de desarrollo. Se han identificado diez aspectos potencialmente reutilizables de los proyectos software [34] (ver tabla 2.2). En otras fuentes [55, 84, 59, 86] tambi´en se hace referencia a la reutilizaci´on de otros elementos como dise˜nos, m´odulos, especificaciones, etc. 1. Arquitecturas 6. Templates 2. C´odigo fuente 7. Interfaces de usuario 3. Datos 8. Planes 4. Dise˜nos 9. Requisistos 5. Documentaci´on 10. Pruebas Tabla 2.2: Elementos potencialmente reutilizables Una ventaja obvia de la reutilizaci´on de software es que los costes totales de desarrollo deber´ıan reducirse. Se necesitan especificar, dise˜nar, implementar y validar menos componentes software [114]. Asimismo, la reutilizaci´on hace los desarrollos m´as confiables ya que los posibles fallos que existieran en las implementaciones y/o dise˜nos han debido ser detectados y reparados con anterioridad. Tambi´en, en algunas ocasiones sacar al mercado un producto tan pronto como sea posible es m´as importante que los costes totales de desarrollo. En este caso, la reutilizaci´on es una herramienta ´util ya que puede reducir los tiempos de desarrollo y validaci´on del software. Por otra parte, la reutilizaci´on presenta costes y problemas asociados que deben ser se˜nalados [114]. Los ingenieros deben localizar los componentes software dentro de una colecci´on de elementos reutilizables, comprender su funcionamiento, analizar si el componente es adecuado para la situaci´on concreta y en algunos casos adaptarlos para su uso en un entorno nuevo. Tambi´en ocurre que cuando el c´odigo fuente de un elemento reutilizado no est´a disponible los costes de mantenimiento pueden incrementarse debido a que los componentes reutilizados son cada vez m´as incompatibles con las versiones sucesivas del sistema. Por ´ultimo, aunque la mayor´ıa de los desarrolladores (un 72 % seg´un Frakes [35]) prefiere reutilizar componentes antes que construir su software por completo, algunos ingenieros siguen prefiriendo reescribir componentes por que opinan que as´ı pueden mejorarlos versi´on tras versi´on. Existen al menos seis dimensiones (ver tabla 2.3) desde las que analizar la reutilizaci´on de software [98, 34]: 17 18 CAP´ ITULO 2. ESTADO DEL ARTE El ´ambito de la reutilizaci´on puede ser interno (tambi´en privado) o externo (tambi´en p´ublico) en funci´on del origen de los elementos reutilizados. As´ı, cuando los elementos no provienen de un repositorio externo al sistema en construcci´on se habla de reutilizaci´on interna y cuando la situaci´on es la contraria la llamamos reutilizaci´on externa. El dominio indica la forma y alcance de la reutilizaci´on. Puede ser horizontal cuando el objetivo es reutilizar elementos entre diferentes aplicaciones o vertical cuando se realiza dentro del mismo dominio/aplicaci´on. La intenci´on expresa c´omo ser´an reutilizados los recursos. La reutilizaci´on de caja negra (black-box reuse overbatim reuse) es la reutilizaci´on de recursos software sin modificaci´on. Por contra la reutilizaci´on de caja blanca (white-box reuse) requiere la modificaci´on/adaptaci´on de los elementos que se desea reutilizar. Por ´ultimo, la reutilizaci´on adaptativa (adaptative reuse), est´a identificada como una t´ecnica que mantiene grandes estructuras de software invariantes y restringe las variaciones a localizaciones aisladas de bajo nivel. La t´ecnica define los m´etodos empleados para reutilizar. Adem´as de t´ecnicas concretas que trataremos con mayor profundidad m´as adelante, en esta categor´ıa se han analizado otros aspectos que citamos a continuaci´on. Se entiende por reutilizaci´on indirecta aquella que emplea entidades intermedias entre el elemento que reutiliza y el reutilizado, por contra, la reutilizaci´on directa no emplea elementos intermedios. Tambi´en se emplean los t´erminos carried-over reuse cuando un componente software empleado en una versi´on determinada del proyecto es empleado en las siguientes versiones y leveraged reuse cuando esa reutilizaci´on requiere modificaciones. Por ´ultimo, la reutilizaci´on in-the-large emplea grandes paquetes autocontenidos (p.ej. hojas de c´alculo), mientras la reutilizaci´on in-the-small usa componentes dependientes del entorno de la aplicaci´on. La gesti´on indica c´omo se dirige la reutilizaci´on. Puede ser sistem´atica o pragm´atica. La reutilizaci´on sistem´atica o planificada [33] utiliza gu´ıas, procedimientos formales y m´etricas para evaluar el rendimiento de la reutilizaci´on, mientras que ´ Ambito Dominio Intenci´on T´ecnica Gesti´on Entidad Interna Vertical Caja blanca Composicional Sistem´atica c´odigo Externo Horizontal Caja negra Generativa Pragm´atica arquitectura Adaptativa Directa dise˜nos Indirecta pruebas carried-over etc. leveraged in-the-large in-the-small Tabla 2.3: Dimensiones de la reutilizaci´on 18 2.2. REUTILIZACI´ ON 19 la reutilizaci´on pragm´atica [49] (tambi´en oportun´ıstica o ad-hoc) emplea componentes que no han sido dise˜nados para ser reutilizados. La mayor parte de la investigaci´on en reutilizaci´on software se ha enfocado en propuestas de reutilizaci´on planificadas [56, 107], sin embargo, la situaci´on muchas veces es la opuesta, donde los desarrolladores deben crear alg´un elemento nuevo similar a alguno creado con antelaci´on pero que no ha sido dise˜nado para ser reutilizado [49]. La entidad reutilizada indica el tipo de producto reutilizado: codigo fuente, dise˜nos, especificaciones, objetos, arquitecturas, etc. Debido al especial inter´es que tienen en esta tesis las t´ecnicas para la implementaci´on de la reutilizaci´on, se ha considerado interesante profundizar un poco m´as en las propuestas existentes en este sentido. Mohagheghi et al. [73] identifican las siguientes clases de t´ecnicas: La reutilizaci´on por composici´on o composicional (Compositional Reuse) utiliza componentes (de grano fino) existentes en colecciones o bibliotecas como bloques constructivos de nuevos sistemas. Implica que el sistema software (sistema de mayor entidad) es construido por un desarrollador a partir de elementos o componentes (elementos de menor entidad). Por ejemplo, el empleo de funciones o subrutinas se considera reutilizaci´on por composici´on. Reutilizaci´on de m´odulos o componentes software. Los m´odulos o componentes son elementos de mayor entidad que las funciones o subrutinas. Proveen servicios a otros m´odulos o componentes del sistema, pero si se les analiza por separado, no pueden llegar a considerarse un sistema completo. Algunas de las aproximaciones para la modularizaci´on incluyen la Programaci´on Orientada Objetos o los paquetes de Ada. Reutilizaci´on de templates o meta-componentes. Un template es un esqueleto de un artefacto, descrito a diferentes niveles de abstracci´on. Normalmente se almacenan en repositorios y est´an compuestos de una parte fija, independiente de la aplicaci´on y una parte que debe ser definida por el desarrollador y especializada para el producto software final en el que se desea incluir. As´ı, el esfuerzo requerido para la reutilizaci´on consiste en especializar el contenido del template para el contexto concreto. En la literatura se distinguen varios tipos de templates: de arquitectura: que especifican un artefacto desde el punto de vista de la arquitectura; de documentaci´on: que definen la documentaci´on relacionada con el artefacto; y de pruebas: que definen el conjunto de casos de pruebas para el artefacto. Los templates son ´utiles para la adopci´on de est´andares en la codificaci´on y documentaci´on de proyectos software. La ingenier´ıa de dominio (domain engineering) para familias o l´ıneas de productos, consiste en agrupar, organizar y almacenar la experiencia obtenida en la construcci´on de sistemas (o partes de los mismos) sobre un dominio particular 19 20 CAP´ ITULO 2. ESTADO DEL ARTE en forma de recursos reutilizables, ofreciendo m´etodos adecuados para reutilizar esos recursos en la construcci´on de nuevos sistemas. Es un concepto clave en la reutilizaci´on sistem´atica. Frameworks orientados a objetos. Los frameworks son aplicaciones semicompletas, generalmente implementadas como una jerarqu´ıa de clases. Una vez que el framework ha sido desarrollado pueden derivarse de ´el m´ultiples aplicaciones. Los frameworks son una t´ecnica de reutilizaci´on que soporta las l´ıneas de productos. La reutilizaci´on generativa es una propuesta para la reutilizaci´on asociada a la ingenier´ıa del dominio. El proceso consiste en la codificaci´on de conocimiento sobre el dominio y sobre la construcci´on de sistemas en ese dominio en un generador de aplicaciones espec´ıfico. Los nuevos sistemas son creados escribiendo especificaciones en un lenguaje propio del dominio. El generador traduce las especificaciones en c´odigo para el nuevo sistema en un lenguaje objetivo. Este proceso puede ser completamente autom´atico o requerir la intervenci´on manual de los desarrolladores. Por ejemplo, los tradicionales analizadores lex y yacc son generadores de c´odigo. Reutilizaci´on basada en componentes ligada a modelos como CORBA/CCM/EJB. El t´ermino componente aparece en muchas propuestas de reutilizaci´on cuando los sistemas son ensamblados a partir de unidades independientes de producci´on. Los componentes reutilizables pueden ser recuperados de un repositorio, compartidos entre productos en una familia de productos o pueden ser obtenidos como componentes OSS (Open Source Software) o COSTS (Commodity off-the-shelf ) [23]. Sin embargo, en esta categor´ıa, debemos entender la reutilizaci´on de componentes adherida a un modelo de componentes particular y dirigida a una plataforma de componentes concreta en oposici´on a otros modelos sin restricciones sobre la conformidad con una arquitectura. Los repositorios o bibliotecas de reutilizaci´on (reuse repository or library), constan de almacenes de recursos reutilizables, herramientas para la b´usqueda de recursos en el almac´en, un m´etodo para la representaci´on de los recursos y utilidades para la gesti´on del cambio y el aseguramiento de la calidad. Los repositorios de reutilizaci´on, pueden ser gen´ericos o espec´ıficos de un dominio y pueden ser combinados con otras propuestas para la reutilizaci´on. El tratamiento cient´ıfico de la reutilizaci´on del software exige que se le considere una disciplina emp´ırica [33]. La profundizaci´on en conceptos como reutilizaci´on y reusabilidad5nos llevan a cuestiones sobre c´omo medirlos adecuadamente [30] y c´omo realizar experimentos que permitan establecer su impacto sobre la calidad y la productividad. Para ello se han definido m´etricas en varias ´areas de la reutilizaci´on software [34]. Las m´etricas son indicadores cuantitativos de un atributo de un producto o proceso software. La experimentaci´on es el proceso de establecer el efecto de unas variables sobre otras. Los modelos y m´etricas sobre reutilizaci´on y reusabilidad se clasifican en seis categor´ıas [34]: 5La reusabilidad es la probabilidad de que un elemento sea reutilizado. 20 2.2. REUTILIZACI´ ON 21 Los modelos coste-beneficio incluyen el an´alisis econ´omico coste-beneficio as´ı como el an´alisis de la mejora de la calidad y de la productividad. En las organizaciones que contemplan la reutilizaci´on de software sistem´atica seguramente las primeras preguntas que aflorar´an estar´an relacionadas con los costes y los beneficios. La justificaci´on de la inversi´on en estos casos se convierte en una necesidad. Los modelos de estimaci´on de la madurez clasifican los programas de reutilizaci´on seg´un su nivel de progresi´on en la implementaci´on de la reutilizaci´on sistem´atica. Los modelos de madurez son el centro de la reutilizaci´on planificada, ayudando a las organizaciones a entender sus pasados, presentes y futuros objetivos para las actividades de reutilizaci´on. La cantidad de reutilizaci´on es usada para evaluar y monitorizar la reutilizaci´on de los elementos de desarrollo a lo largo del ciclo vida de un proyecto. Este tipo de m´etricas suele incluir factores como el nivel de abstracci´on del objeto reutilizado, as´ı como definiciones formales sobre reutilizaci´on interna y externa. El an´alisis modal de fallos se emplea para identificar y clasificar los obst´aculos para la reutilizaci´on en un determinado organismo. Ofrece una aproximaci´on para medir y mejorar un proceso de reutilizaci´on bas´andose en un modelo de las formas en las que dicho proceso puede fallar. Las m´etricas de reusabilidad indican la probabilidad de que un elemento sea reutilizado. Estas m´etricas son potencialmente ´utiles en dos ´areas clave de la reutilizaci´on: el dise˜no de la reutilizaci´on y la reingenier´ıa para la reutilizaci´on. Las m´etricas para bibliotecas de reutilizaci´on 6se usan para gestionar y seguir el uso de un repositorio de reutilizaci´on. Los recursos de las bibliotecas pueden ser obtenidos de sistemas existentes a trav´es de la reingenier´ıa, dise˜nados y construidos desde cero o pueden ser adquiridos. Silva [95] indica que el uso de Modelos de la IU en el MB-UID ofrece la capacidad de reutilizar especificaciones de la interfaz de usuario. De hecho, el MB-UID en si puede ser considerado una propuesta para la reutilizaci´on generativa ya que reutiliza las especificaciones de la interfaz de usuario mediante generadores de c´odigo [121]. A continuaci´on nos centraremos en las propuestas que tienen una relaci´on m´as estrecha con el campo de trabajo de esta tesis: la reutilizaci´on de la interfaz de usuario en el MB-UID. Las propuestas existentes se pueden clasificar en los siguientes grupos: 1. Soporte para la reutilizaci´on en los Lenguajes de Descripci´on de la IU . 2. Desarrollo de interfaces de usuario multi-dispositivo/multi-contexto basado en modelos. 3. M´etodos de reutilizaci´on basados en patrones. 6Una biblioteca de reutilizaci´on es un repositorio para almacenar recursos reutilizables junto con una interfaz que permite realizar b´usquedas en el repositorio. 21 22 CAP´ ITULO 2. ESTADO DEL ARTE 2.2.1. Soporte para la reutilizaci´on en los UIDLs Los Modelos de la IU usados en el MB-UID se expresan a trav´es de lenguajes gr´aficos o textuales. Hoy existen un gran n´umero de Lenguajes de Descripci´on de la IU [115, 45] que son usados con este prop´osito. Los Lenguajes de Descripci´on de la IU son lenguajes de alto nivel que se emplean para describir las caracter´ısticas de la interfaz de usuario que son de inter´es en las aplicaciones interactivas. Al tratarse en la mayor´ıa de los casos de lenguajes textuales, una tentaci´on habitual es copiar y pegar las porciones de c´odigo que se necesita reutilizar. Esta acci´on est´a identificada como una mala pr´actica en el desarrollo (cut&paste programming [14]) ya que deriva en un c´odigo engrosado e inmantenible. Una opci´on mucho m´as correcta ser´ıa encapsular el fragmento reutilizable de una forma apropiada, sin embargo, pocos Lenguajes de Descripci´on de la IU han tenido en cuenta esta necesidad: XUL [50] es el Lenguaje de Descripci´on de la IU desarrollado por el Mozilla project para sus desarrollos multi-plataforma como por ejemplo el navegador web Firefox. XUL dispone de XUL Ovelays, un mecanismo que permite: a˜nadir componentes adicionales a una interfaz de usuario existente, sustituir peque˜nos trozos de c´odigo en un fichero XUL sin necesidad de suministrar la interfaz de usuario completa y reutilizar trozos espec´ıficos de la interfaz de usuario. En este ´ultimo caso, el mecanismo permite definir elementos de la interfaz de usuario en archivos de overlay e incluirlos en documentos que necesiten utilizarlos. Luego, empleando el atributo id en un nodo vac´ıo del documento que realiza la inclusi´on, se referencia al sub´arbol definido en el overlay all´ı donde sea necesario. Por ejemplo, los botones Aceptar yCancelar que aparecen en la parte m´as baja de multitud de di´alogos pueden definirse en un archivo y ser empleados en todos los di´alogos que los necesiten. Para ello, los di´alogos que quieran reutilizar esa definici´on deben primero ”declarar” (incluir) el overlay: <? xul−overla y href=” chrome: // gl ob al / content / dialogOverlay . xul ”?> Y posteriormente incluir una ”caja” vac´ıa referenciando al elemento reutilizado (en este caso con identificador okCancelButtons) en la definici´on de la interfaz de usuario: <box a li g n=” ho ri zo nt al ” id=”bx1” f l e x=”100 %” s t y l e=”margin−bottom: 1em; width: 100 %;”> <html:input type=”checkbox” id=” di alog . newWindow”/> <html:label f o r=” d i a lo g . newWindow”>&openWin . l a b e l ;</html:label> <spring f l e x=”100 %”/> </box> <box id=” okCancelButtons ”/> Los overlays de XUL se pueden cargar de forma expl´ıcita usando la instrucci´on especial de procesamiento XML (<?xul-overlay?>). No hay l´ımite al n´umero de overlays que se pueden cargar desde un documento XUL. A su vez un overlay puede cargar otros overlays. 22 2.2. REUTILIZACI´ ON 23 XICL [18, 19] es un lenguaje extensible basado en XML para definir interfaces de usuario y componentes de la interfaz de usuario. Est´a orientado especialmente a aplicaciones web. Los componentes de XICL se desarrollan empleando elementos de HTML y otros elementos (etiquetas) propios del lenguaje XICL: <COMPONENT name=”SUBMIT”> <STRUCTURE> <span>\$ l a b e l</span><input type=”submit ” maxlength=”\$ length ” name=”subBnt”> </STRUCTURE> <EVENTS> <EVENT name=” onc li ck ” t r i g g e r=”subBtn . o nc l ic k ” funct ion=”\$ o nc l ic k ” > </EVENTS> </COMPONENT> Los componentes quedan descritos a trav´es de su estructura, propiedades, eventos, m´etodos y su modelo de interacci´on (ver figura 2.6). component eventsscriptstructurepropertiesinteractionModel eventproperty Figura 2.6: Componente XICL Una interfaz de usuario en XICL puede construirse empleando componentes reutilizables almacenados en una biblioteca (mediante la instrucci´on import). Los componentes se pueden definir extendiendo un componente existente (usando el atributo extends de la etiqueta <component>) y modificando alguna de sus propiedades. Una vez que el desarrollador ha especificado la interfaz de usuario y/o sus componentes el int´erprete de XICL enlaza el c´odigo fuente de los componentes con la interfaz de usuario y lo traduce en c´odigo HTML din´amico. UIML permite empaquetar partes de la definici´on de una interfaz de usuario en templates [2]. Los templates pueden ser reutilizados posteriormente en nuevos dise˜nos de interfaces de usuario de una manera flexible. Para su funcionamiento se emplean dos piezas fundamentales en UIML: el placeholder y el propio template. El placeholder indica qu´e template se debe aplicar y c´omo. El atributo source identifica el template que se desea incluir. Su valor se corresponde con una URI (Unified Resource Identifier) que referencia la localizaci´on del template seguida del caracter ’#’ y el identificador del mismo. El atributo how indica la estrategia a seguir para el fusionado del template en el documento. En su valor pueden aparecer los m´etodos replace,union ycascade. 23 24 CAP´ ITULO 2. ESTADO DEL ARTE Por ejemplo, muchas aplicaciones de comercio electr´onico incluyen un di´alogo para el pago mediante tarjeta de cr´edito. Ese di´alogo puede describirse como un template UIML y ser incluido varias veces en la misma interfaz de usuario o entre distintas interfaces de usuario. <template id=”DialogBox”> <part id=”TopLevel”> <part id=”CompanyLogo” c l a s s=” ImageContainer ”/> <part id=”Message” c l a s s=”Text”/> <part id=”Accept” c l a s s=”Button”/> </part> </template> ... <interface> <structure> <part id=”FileNotFoundBox” c l a s s=”TopContainer ” source=”#DialogBox” how=” r e p l a c e ”> <!−− Default implementation −−> </part> </structure> </interface> UIML tambi´en admite la parametrizaci´on de los templates. La parametrizaci´on permite pasar datos a un template. Para su uso se emplean los elementos: dtemplate-param (un par´ametro que ser´a recibido por el template), d-template- parameters (un contenedor de d-template-param), template-param (un par´ametro que se pasa a un template), template-parameters (un contenedor de templateparam). Para obtener el valor de un par´ametro se antepone el caracter ’$’a su identificador. <uiml> <interface> <structure> <part id=” id1 ” source=”#t pl ” how=” replace ”> <template−parameters> <template−param name=” button id ”>btn copy</template−param> <template−param name=” button label ”>Click to copy</template−param> <template−param name=” e n t r y id ”>entry copy</template−param> </template−parameters> </part> </structure> </interface> <template id=” tpl ”> <d−template−parameters> <d−template−param name=” button id ”/> <d−template−param name=” b u t t o n l a b e l ”/> <d−template−param name=” e nt r y id ”/> </d−template−parameters> 24 2.2. REUTILIZACI´ ON 25 <part> <part id=”$ e ntry i d ” c l a s s=”Entry”/> <part id=”$ button id ” c l a s s=”Button”> <style> <property name=” l a b e l ”> <template−param id=” butto n l a b e l ”/> </property> </style> </part> </part> </template> </uiml> Hemos visto que distintos Lenguajes de Descripci´on de la IU han desarrollado sus propios mecanismos para la reutilizaci´on. Ser´ıa deseable que un mecanismo de reutilizaci´on pudiera ser empleado en cualquier Lenguaje de Descripci´on de la IU , siendo lo m´as est´andar posible y minimizando las modificaciones a realizar en la sintaxis del lenguaje. UIML, XICL y XUL usan diferentes m´etodos para reutilizar fragmentos de especificaciones de Modelos de la IU y ´estos no podr´ıan ser empleados directamente en otros Lenguajes de Descripci´on de la IU , ya que tienen comportamientos muy caracter´ısticos, definen sus propias etiquetas XML o usan instrucciones especiales de procesamiento de XML. 2.2.2. Desarrollo de interfaces de usuario multi-dispositivo basado en modelos Como se ha comentado con anterioridad todo un grupo de propuestas (tercera y cuarta generaci´on de MB-UIDEs, secci´on 2.1.3) se han orientado a tratar la problem´atica del gran n´umero de plataformas de interacci´on disponibles y del desarrollo sensible al contexto. El propio Framework de Referencia Cameleon [13] representa un marco en el que clasificar sistemas de MB-UID que soportan m´ultiples plataformas o m´ultiples contextos de uso. Existen por lo tanto varios MB-UIDEs (TERESA [77], Dygimes [124], XMobile [125], etc.) y Lenguajes de Descripci´on de la IU (e.g. AUIML [7], UIML [3, 6], XIML [100] , etc.) cuyo objetivo es la generaci´on de interfaces de usuario para diferentes plataformas o dispositivos partiendo de una especificaci´on ´unica de Modelos de la IU : TERESA (Transformation Environment for inteRactivE Systems representAtions) [89, 78] es una herramienta que soporta el MB-UID para m´ultiples plataformas. Algunas de las plataformas para las que genera interfaces de usuario son HTML, WML y VoiceXML. La herramienta parte de un Modelo de Tareas (en notaci´on CTT) que es transformado de forma semi-autom´atica para producir las interfaces de usuario multiplataforma. Mediante el filtrado de este modelo inicial, se crean Modelos de Tareas espec´ıficos para cada plataforma particular. En este proceso de filtrado se pueden a˜nadir nuevas tareas para ciertas plataformas as´ı como reestructurar los ´arboles de tareas. Luego se generan Conjuntos de Tareas Habilitadas (Enabled Task Sets) partiendo del modelo de tareas del sistema. Estos 25 32 CAP´ ITULO 3. T´ ECNICAS DE REUTILIZACI´ ON EN EL MB-UID 3.1. T´ecnicas de reutilizaci´on en especificaciones A lo largo de esta secci´on se describen m´etodos que permiten reutilizar especificaciones completas o fragmentos de las mismas. Algunos de los m´etodos propuestos tratar´an de solventar algunas de las limitaciones comentadas en la secci´on 2.2. 3.1.1. T´ecnicas soportadas por el lenguaje de especificaci´on Los lenguajes de programaci´on han evolucionado para permitir a los desarrolladores emplear herramientas de reutilizaci´on cada vez m´as refinadas [33]; desde las subrutinas en lenguajes ensambladores, hasta m´odulos, clases, frameworks, etc. Herramientas similares deben estar presentes en los Lenguajes de Descripci´on de la IU . Su uso permitir´ıa reducir el tama˜no y la complejidad de las especificaciones, redundando en soluciones m´as compactas y menos susceptibles de provocar errores (i.e. de m´as calidad). Se proponen a continuaci´on t´ecnicas que pueden ser aplicadas en estos lenguajes en el momento de construir las especificaciones: 3.1.1.1. Subespecificaci´on (S) Al igual que en los lenguajes procedurales ocurre con los procedimientos o funciones, fragmentos que aparezcan repetidamente en una especificaci´on deben ser definidos de forma ”aislada” e invocados o referenciados posteriormente en otras partes de la especificaci´on. A este m´etodo que permitir´ıa crear nuevos elementos por composici´on de fragmentos de la especificaci´on lo denominamos ”subespecificaci´on”. Por ejemplo, si en el Modelo de Tareas, una tarea se repite varias veces, se podr´ıa definir como una subespecificaci´on y ser referenciada cuantas veces sea necesario. Recordemos que algunos de los lenguajes presentados en la secci´on 2.2.1 (como XUL y UIML) permiten definir fragmentos de una especificaci´on (p.ej. templates) y referenciarlos posteriormente cuando sea necesario. 3.1.1.2. Templates (T) Un template (o plantilla) se puede definir como una subespecificaci´on en la que adem´as, ciertas partes de la misma pueden ser sustituidas por ciertos valores mediante el empleo de par´ametros. Hemos visto en el estado del arte (secci´on 2.2.1) que UIML permite la definici´on de templates y que admite que determinados valores sean trasladados al template empleando par´ametros. Recordemos que la reutilizaci´on basada en templates est´a identificada como uno de los m´etodos de reutilizaci´on para diversos elementos [73] (c´odigo, documentaci´on, etc.) y que ha sido empleada en otros ´ambitos y lenguajes [46, 16]. 3.1.1.3. Adaptaci´on (A) La adaptaci´on permite transformar un elemento contenido en una subespecificaci´on en otro distinto tras aplicarle una configuraci´on determinada. La diferencia respecto al m´etodo anterior consiste en que mientras que el c´odigo de los templates es est´atico 32 3.1. T´ ECNICAS DE REUTILIZACI´ ON EN ESPECIFICACIONES 33 y los valores de los par´ametros, podr´ıamos decir que son simplemente sustituidos en ese c´odigo, la adaptaci´on pemitir´ıa, mediante la parametrizaci´on del elemento origen, una reutilizaci´on m´as flexible del elemento reutilizado (m´as adaptativa) modificando su composici´on, estructura y/o comportamiento. La figura 3.1 muestra c´omo una ventana (IU Concreta) se obtiene por adaptaci´on de una existente (sample). Observe que la ventana original ha sido adaptada habilitando o deshabilitando los elementos que la componen utilizando los par´ametros fieldiyactioni. Action 1 Field 2 Action 2 Field 1 Window sample <window id="sample" action1="on" field2="off"/> field1="on" action2="off" Figura 3.1: Nueva ventana obtenida por adaptaci´on 3.1.1.4. Herencia (H) Algunos Modelos de la IU se definen empleando clases y objetos. Parece l´ogico en estos casos, que los mecanismos de reutilizaci´on b´asicos de la Programaci´on Orientada a Objetos, como la herencia [40], puedan ser empleados en la definici´on de los modelos de forma natural. Por ejemplo, en la secci´on 2.2.1, hemos visto, que XICL permite emplear el mecanismo de herencia en la definici´on de nuevos componentes de la interfaz de usuario (atributo extends en la etiqueta <component>). Tambi´en es habitual que los widgets sean definidos como clases en toolkits o bibliotecas gr´aficas, permitiendo definir nuevos widgets de manera sencilla empleando el mecanismo de herencia. Por ´ultimo, se ha de mencionar que existen lenguajes como CSS que definen relaciones ”no ortodoxas” de herencia en este caso en combinaci´on con HTML (CSS Inheritance [37]). Naturalmente, la aplicabilidad de los m´etodos anteriores (S, T, A y H) depender´a del soporte de los Lenguajes de Descripci´on de la IU empleados por el MB-UID. Aquellos lenguajes que ofrezcan estas t´ecnicas, obtendr´an de forma inmediata ventajas como la reducci´on de tama˜no de las especificaciones, el decremento de la complejidad de las mismas y la simplificaci´on de su mantenimiento. Hay que tener en cuenta que a˜nadir estos mecanismos a un lenguaje existente puede ser enormemente costoso, por no decir imposible de llevar a cabo sin realizar una reestructuraci´on profunda del lenguaje, por lo tanto, recomendamos que estos m´etodos sean tenidos en cuenta en el dise˜no de los futuros Lenguajes de Descripci´on de la IU . Por ´ultimo, hay que destacar que estos m´etodos por s´ı mismos no permiten la reutilizaci´on horizontal (Inter-proyecto) ya que en principio, referencian o emplean elementos que forman parte de la misma especificaci´on. 33 34 CAP´ ITULO 3. T´ ECNICAS DE REUTILIZACI´ ON EN EL MB-UID 3.1.2. Inclusi´on (I) Muchos lenguajes de programaci´on poseen una directiva, denominada de forma habitual include [116] (tambi´en copy,require, etc.) que causa que el contenido de un segundo archivo sea insertado en el archivo original. Este mecanismo en algunos casos se apoya en elementos externos (p.ej. un preprocesador) y se ha usado para definir estructuras de datos comunes, realizar declaraciones adelantadas, encapsular y reutilizar c´odigo, etc. En lenguajes m´as modernos la inclusi´on ha evolucionado hacia sistemas m´as avanzados (p.ej. paquetes en Ada [118] o Java [43]) que resuelven el problema de la compilaci´on separada y manejan conceptos avanzados como los espacios de nombres o la visibilidad/ocultaci´on de definiciones. En la secci´on 2.2.1, hemos visto que algunos Lenguajes de Descripci´on de la IU como XUL y XICL poseen directivas (xul-overlay eimport respectivamente) con un uso similar. Por su parte, UIML permite referenciar templates tanto internos como externos a trav´es de la URI indicada en el atributo source, pero en cualquier caso, si el recurso a reutilizar es externo, ´este debe ser recuperado y a˜nadido a la especificaci´on actual de alguna forma. El mecanismo de inclusi´on permite en primer lugar que especificaciones de gran tama˜no puedan ser modularizadas en fragmentos m´as sencillos de manejar, mantener y comprender. Tambi´en posibilita que cualquier componente reutilizable de una especificaci´on pueda ser definido en su propio fichero y que ´este sea incluido en cualquier otra especificaci´on que requiera usarlo, facilitando la reutilizaci´on horizontal. Recordemos que las t´ecnicas de la secci´on 3.1.1 (S, T, A y H), no permiten por s´ı mismas la reutilizaci´on Inter-proyecto, por lo tanto, pueden ser combinadas con alguna forma de inclusi´on para resolver esta limitaci´on. Es necesario tener en cuenta que la inclusi´on presenta un problema que podemos denominar ”fusi´on”. Cada vez que un elemento reutilizable sea incluido en un nuevo proyecto, ese elemento ser´a ”fusionado” en la nueva especificaci´on, dificultando las posteriores tareas de mantenimiento y actualizaci´on del componente que deben ser realizadas en cada proyecto donde el componente ha sido incluido. De hecho, en la mayor´ıa de los casos ser´a necesario volver a regenerar modelos, refinarlos o volver a generar el c´odigo de la interfaz de usuario. 3.1.3. Paquetes (P) De forma general, podemos decir que un Sistema de Gesti´on de Paquetes (Package Management System) es un m´etodo de distribuir, instalar y gestionar componentes en un sistema inform´atico. Los paquetes son utilizados hoy d´ıa con m´ultiples prop´ositos como por ejemplo el archivado de ficheros con o sin compresi´on (p.ej. TAR, ZIP, CAB), la distribuci´on de software ejecutable (p.ej. MSI, RPM, DEB), o la distribuci´on de clases y unidades en diversos lenguajes de programaci´on (p.ej. JAR, WAR, EAR, PPM). En la secci´on 2.1 hemos visto que en el MB-UID se pueden emplear varios Lenguajes de Descripci´on de la IU tanto en el mismo nivel de abstracci´on como a distintos niveles. Es m´as, cuando se trabaja con varios lenguajes podr´ıa ocurrir que la definici´on de un componente complejo est´e compuesta por fragmentos pertenecientes a distintos modelos 34 3.1. T´ ECNICAS DE REUTILIZACI´ ON EN ESPECIFICACIONES 35 que a su vez han sido definidos en distintos lenguajes. Los paquetes permitir´ıan unificar todos los fragmentos necesarios en una ´unica entidad. Tambi´en ayudar´ıan a encapsular y distribuir el c´odigo de los componentes reutilizables en escenarios Inter-proyecto de forma c´omoda y segura (i.e. cifrados y/o firmados). Adem´as, un paquete puede contener cualquier informaci´on adicional sobre el componente reutilizable de la interfaz de usuario. Se puede incluir en el paquete documentaci´on, diagramas explicativos, ejemplos de uso o cualquier otra informaci´on relevante para la explotaci´on del componente. Esto permitir´ıa realizar asset-based development1[57] en la interfaz de usuario. Hay que destacar que para poder emplear paquetes es necesario implementar un Sistema de Gesti´on de Paquetes. En absoluto es un asunto trivial, ya que se deben abordar problemas complejos como las dependencias de paquetes [47], conflictos de versiones entre los mismos o aspectos relativos a la seguridad [63]. Adem´as, al igual que en la inclusi´on, los recursos reutilizados ser´an ”fusionados” en las nuevas especificaciones y los cambios realizados en los recursos originales no se trasladar´an a los sistemas que hacen uso de ellos. Finalmente, se ha de tener en cuenta que las potenciales implementaciones que se pudieran realizar de un Sistema de Gesti´on de Paquetes, muy probablemente, ser´ıan dependientes de la plataforma/MB-UIDE y por lo tanto dif´ıcilmente aplicables a entornos diferentes. 3.1.4. Bibliotecas de reutilizaci´on (B) Las bibliotecas de reutilizaci´on est´an formadas por un almac´en de recursos y alg´un m´etodo para la b´usqueda en el almac´en junto a otras utilidades y herramientas. En el ´ambito de este trabajo, los recursos reutilizables ser´ıan especificaciones de Modelos de la IU . En los apartados anteriores hemos visto dos t´ecnicas que pueden servir de base para la creaci´on de bibliotecas de recursos reutilizables de la interfaz de usuario: la inclusi´on y los paquetes. Ambos m´etodos permitir´ıan emplear elementos de la interfaz de usuario desarrollados con anterioridad en nuevos proyectos. Las bibliotecas de reutilizaci´on mantendr´ıan un repositorio organizado (directorio, servidor web, etc.) de elementos reutilizables de la interfaz de usuario (contenidos en archivos o paquetes). El empleo de bibliotecas de reutilizaci´on implica un compromiso (al menos una concienciaci´on) de la organizaci´on en la gesti´on de la reutilizaci´on. Se incluye la reutilizaci´on como un proceso b´asico dentro del desarrollo, indagando sobre qu´e elementos pueden ser reutilizados en el futuro y manteni´endolos organizados en un repositorio. 1El desarrollo basado en recursos (asset-based development) organiza las ”inversiones” (investments) relativas al software, requisitos, modelos, c´odigo, pruebas y scripts de despliegue para ser usadas en futuros proyectos software. 35 36 CAP´ ITULO 3. T´ ECNICAS DE REUTILIZACI´ ON EN EL MB-UID 3.2. T´ecnicas de reutilizaci´on en repositorios de modelos En los MB-UIDEs con arquitectura de tipo Run-time (arquitecturas Mixta eInterpretativa, ver figuras 2.4b y 2.4c) los modelos involucrados en la generaci´on de la interfaz de usuario (o al menos algunos de ellos) pueden residir en ficheros o alg´un tipo de base de datos (para nosotros a partir de ahora repositorios de Modelos de la IU ). Estos repositorios pueden convertirse en un espacio en el que compartir/reutilizar elementos de la interfaz de usuario en escenarios Inter-proyecto, utilizando t´ecnicas habitualmente empleadas en otros tipos de almacenes como bases de datos, directorios de usuarios, etc. Para que esta propuesta sea factible, los repositorios deben permitir el acceso simult´aneo de varios Run-times de la IU y estos ´ultimos deben ser capaces de acceder a varios repositorios. Evidentemente como cada objeto residir´a en un ´unico repositorio, se elimina el problema de la fusi´on presente en la inclusi´on y en los paquetes (ver secciones 3.1.2 y 3.1.3). Una restricci´on para la posible aplicaci´on de los siguientes m´etodos es que el acceso a los repositorios compartidos debe ser suficientemente r´apido para no afectar al tiempo de respuesta de la interfaz de usuario. 3.2.1. Paquetes (P) En la secci´on anterior se ha propuesto el uso de paquetes para reutilizar fragmentos de especificaciones (subsecci´on 3.1.3). Sin embargo, los paquetes tambi´en podr´ıan funcionar sobre repositorios. Recordemos que un Sistema de Gesti´on de Paquetes es un software complejo capaz de realizar muchas funciones. En este caso particular, el Sistema de Gesti´on de Paquetes podr´ıa encargarse de realizar las transformaciones necesarias sobre los fragmentos de las especificaciones contenidos en el paquete para prepararlos y dejarlos operativos en los repositorios empleados por el MB-UIDE. En las arquitecturas Interpretativas las especificaciones contenidas en el paquete pr´acticamente s´olo necesitar´ıan ser ”vertidas” al repositorio de especificaciones. En las arquitecturas Mixtas las especificaciones ser´ıan trasformadas al formato empleado por el Run-time y a˜nadidas al repositorio. 3.2.2. Repositorios centralizados (C) Centralizar puede definirse como el acto de consolidar recursos bajo un control central. Los sistemas centralizados han sido aplicados en la inform´atica en multitud de ´ambitos como las comunicaciones, las bases de datos o los servicios en general. En el ´ambito del MB-UID se pueden consolidar en un repositorio central los elementos de los Modelos de la IU comunes a un conjunto de sistemas. ´ Este podr´ıa ser un caso frecuente en las aplicaciones corporativas de grandes organizaciones donde el aspecto de las aplicaciones y otros elementos como tareas, unidades de interacci´on, etc. pueden ser comunes a varios sistemas. Como se puede apreciar en la figura 3.2 un repositorio puede almacenar los elementos comunes a varias aplicaciones y adem´as, cada sistema puede emplear su repositorio local para almacenar los elementos particulares de su interfaz de usuario. 36 3.2. T´ ECNICAS DE REUTILIZACI´ ON EN REPOSITORIOS DE MODELOS 37 Aplicacion 3 Aplicacion 2 compartido Repositorio apl 2 apl 3 IU run−time run−time IU IU Aplicacion 1 apl 1 run−time objetos de la IU comunes objetos Apl1 de la IU objetos Apl2 de la IU objetos Apl3 de la IU Figura 3.2: Arquitectura centralizada para compartir objetos de la interfaz de usuario Las ventajas que presenta la centralizaci´on son muy interesantes. Se simplifica el mantenimiento de las interfaces de usuario siendo ´unicamente necesario realizar modificaciones en el repositorio com´un para mantener los recursos actualizados. Asimismo, la centralizaci´on de los Modelos de la IU , puede permitir implementar ciertos mecanismos de seguridad para el control de acceso y de cambios. Por contra, el tiempo de respuesta de este tipo de sistemas podr´ıa verse sustancialmente degradado y de hecho, ser´a totalmente dependiente de la comunicaci´on con el repositorio central. Es m´as, los fallos o errores en los repositorios centralizados afectar´an a cada sistema que haga uso de los mismos. Adem´as, los desarrolladores que realicen actualizaciones sobre modelos compartidos podr´ıan encontrar dificultades debidas a bloqueos de acceso sobre componentes que se encuentren en uso por otros usuarios o desarrolladores. 3.2.3. Repositorios federados (F) Se entiende por federaci´on un m´etodo que permite enlazar objetos de dos o m´as localizaciones diferentes, haciendo que el acceso/enlace sea transparente, como si los objetos estuvieran localizados en el mismo lugar. La federaci´on se ha aplicado con ´exito en campos como los directorios de usuarios [96] o las bases de datos [28]. As´ı, las bases de datos federadas son un tipo de ”meta-basededatos” que integra m´ultiples bases de datos aut´onomas en una ´unica base de datos, permaneciendo las bases de datos que constituyen la federaci´on independientes y aut´onomas. De manera an´aloga, un nuevo Modelo de la IU puede ser construido por federaci´on de elementos de modelos existentes, dejando el control y la gesti´on de los elementos que forman la federaci´on en manos de sus respectivos administradores. La figura 3.3 muestra c´omo el Run-time de la IU de la aplicaci´on 4 toma objetos 37 38 CAP´ ITULO 3. T´ ECNICAS DE REUTILIZACI´ ON EN EL MB-UID de los repositorios de varias aplicaciones. Aplicacion 4 Aplicacion 3Aplicacion 2Aplicacion 1 apl 1 apl 2 apl 3 apl 4 run−time run−time run−time IU IU IU run−time IU Objetos Apl 1 de la IU Objetos Apl 2 de la IU Objetos Apl 3 de la IU Figura 3.3: Arquitectura federada para compartir objetos de la interfaz de usuario En los sistemas federados tambi´en se elimina el problema de la ”fusi´on”. Las actualizaciones sobre componentes compartidos s´olo se realizar´an sobre el repositorio que contiene el elemento y los cambios se trasladar´an a todos los sistemas que hacen uso de ´el. La federaci´on ser´a aconsejable cuando los Modelos de la IU o sus componentes reutilizables est´an distribuidos en diferentes dominios de responsabilidad. Los objetos federados de la interfaz de usuario permanecer´an en su localizaci´on original, mante- ni´endose una vista uniforme de acceso para los usuarios, que no tienen consciencia de la existencia de m´ultiples sistemas independientes. Por ´ultimo, destaquemos que las arquitecturas federadas suelen ser m´as escalables que las centralizadas y distribuyen la carga de trabajo de manera eficiente. Los sistemas federados tambi´en presentan limitaciones. La detecci´on de cambios en los sistemas origen puede ser costosa, adem´as, a priori no existe consistencia ni integridad referencial entre los objetos de los repositorios. Al igual que en sistemas centralizados, otro aspecto a tener en cuenta es la seguridad; para cada sistema ser´a necesario determinar qu´e elementos son accesibles para el modelo federado y en qu´e condiciones. La implementaci´on de sistemas centralizados y federados puede llegar a ser extremadamente compleja. De forma general, los MB-UIDEs que formen parte de un sistema centralizado o federado pueden ser de distinto tipo, es decir, sistemas con estructuras, lenguajes y elementos constituyentes totalmente distintos. En este caso habr´ıa que tratar problemas como la homogeneizaci´on de los distintos Modelos de la IU , la realizaci´on de capas intermedias de adaptaci´on/conversi´on de modelos, etc. 38 3.3. FACTORES A CONSIDERAR EN LA SELECCI ´ ON Y APLICACI´ ON DE LAS T´ ECNICAS PROPUESTAS 39 3.3. Factores a considerar en la selecci´on y aplicaci´on de las t´ecnicas propuestas En esta secci´on se analizan algunos factores que pueden influir a la hora de seleccionar o aplicar las t´ecnicas de reutilizaci´on propuestas. 3.3.1. Arquitectura del MB-UIDE La arquitectura empleada por el MB-UIDE para la generaci´on de la IU Final, determinar´a cu´al de las t´ecnicas es aplicable. Los MB-UIDEs que siguen la arquitectura Generativa de la figura 2.4a, producen el c´odigo fuente de la interfaz de usuario utilizando un generador de c´odigo. No poseen un Run-time de la IU ni emplean ning´un tipo de almac´en para los Modelos de la IU en tiempo de ejecuci´on. El resultado del trabajo realizado sobre los modelos durante el desarrollo se ha enlazado con el resto de la aplicaci´on y forma parte de un archivo ejecutable. En este tipo de arquitectura, las t´ecnicas de reutilizaci´on para repositorios de Modelos de la IU (C y F) no son aplicables. Por el contrario, las arquitecturas Mixtas eInterpretativas de la figura 2.4, emplean repositorios: el archivo o base de datos que soporta los Modelos de la IU pretratados de la figura 2.4b o directamente el conjunto de especificaciones de la figura 2.4c. En ambos casos el Run-time de la IU transforma en tiempo de ejecuci´on las especificaciones (pretratadas o no) en la IU Final y por lo tanto se pueden aplicar las t´ecnicas C y F. Un aspecto a analizar es en qu´e momento se lleva a cabo la reutilizaci´on de los elementos de los Modelos de la IU en funci´on de la arquitectura del MB-UIDE. En la tabla 3.1 se muestra un resumen indicando para cada aquitectura y cada t´ecnica propuesta cu´ando se puede llevar a cabo la reutilizaci´on del recurso: en tiempo de desarrollo (D) o en tiempo de ejecuci´on (E). T´ecnica Generativa (a) Mixta (b) Interpretativa (c) Subespecificaci´on D/E D/E E Templates D/E D/E E Adaptaci´on D/E D/E E Herencia D/E D/E E Inclusi´on D D E Paquetes D D D Bibliotecas D D D Centralizaci´on - E E Federaci´on - E E Tabla 3.1: Resoluci´on de la reutilizaci´on por arquitectura y t´ecnica Seg´un la arquitectura del MB-UIDE existir´an las siguientes opciones: En las arquitecturas de tipo Interpretativa (figura 2.4c), las especificaciones, definidas en sus lenguajes correspondientes, se interpretan en tiempo de ejecuci´on. 39 40 CAP´ ITULO 3. T´ ECNICAS DE REUTILIZACI´ ON EN EL MB-UID •Los m´etodos de reutilizaci´on soportados por los lenguajes de especificaci´on (S, T, A y H, secci´on 3.1) deben resolverse por lo tanto en tiempo de ejecuci´on. Por ejemplo, los templates deben expandirse (sustituci´on de par´ametros) y la herencia debe materializarse en tiempo de ejecuci´on. Como no existe ninguna herramienta que realice un tratamiento previo de las especificaciones antes de que ´estas sean utilizadas por el Run-time de la IU , las t´ecnicas de reutilizaci´on para las especificaciones deben ser resueltas por el int´erprete. Igualmente ocurre con la inclusi´on (I), debe ser resuelta en tiempo de ejecuci´on dado que no existe otra forma de que sea tratada. Recordemos que XICL [18, 19] sigue una arquitectura de este tipo, un Run-time interpreta el lenguaje en tiempo de ejecuci´on resolviendo la herencia y la inclusi´on. •El despliegue de un paquete (P) o la utilizaci´on de bibliotecas de especificaciones (B) s´olo tiene sentido en tiempo de desarrollo. Obviamente los desarrolladores seleccionar´an qu´e componentes de la biblioteca o qu´e paquetes van a emplear durante el desarrollo de la interfaz de usuario, ya que en tiempo de ejecuci´on esos elementos tienen que formar parte del repositorio de Modelos de la IU . •Por ´ultimo, los elementos que residan en repositorios compartidos (t´ecnicas C y F) deben ser recuperados en tiempo de ejecuci´on. Todas las transformaciones posteriores que se deban realizar sobre estos objetos hasta generar la IU Final ser´an desempe˜nadas por el Run-time de la IU en tiempo de ejecuci´on. En arquitecturas Mixtas (figura 2.4b), el Run-time del sistema utiliza una forma pretratada de las especificaciones de los Modelos de la IU . •El nivel de las transformaciones realizadas en el pretratamiento de los modelos, har´a que la reutilizaci´on en las t´ecnicas S, T, A y H (secci´on 3.1) se resuelva en tiempo de desarrollo o en tiempo de ejecuci´on. Un proceso pesado, puede resolver cuestiones como la expansi´on de templates dejando los elementos preparados en el repositorio. En el extremo opuesto, un proceso m´as ligero, puede trasladar im´agenes levemente transformadas de los objetos originales al repositorio, dejando para el Run-time la resoluci´on de todos los aspectos relacionados con la reutilizaci´on. •Sin embargo, la inclusi´on debe ser resuelta en tiempo de desarrollo, antes de que los Modelos de la IU sean pretratados. Igualmente ocurrir´a con el empleo de paquetes y bibliotecas de reutilizaci´on. Los componentes deben ser seleccionados por los desarrolladores y a˜nadidos a las especificaciones en tiempo de desarrollo, antes de que se realice el pretratamiento de las especificaciones. •Por ´ultimo, en estos sistemas, los archivos que contienen las especificaciones transformadas pueden ser considerados un repositorio de Modelos de la IU . En estos repositorios ser´ıa posible reutilizar elementos de interfaz de usuario mediante las t´enicas C y F en tiempo de ejecuci´on. El Run-time de la IU ser´ıa 40 3.3. FACTORES A CONSIDERAR EN LA SELECCI ´ ON Y APLICACI´ ON DE LAS T´ ECNICAS PROPUESTAS 41 el responsable de localizar elementos en los repositorios remotos, recuperarlos y transformarlos. Para finalizar, en las arquitecturas Generativas (figura 2.4a), un generador de c´odigo crea el c´odigo fuente de la interfaz de usuario partiendo de las especificaciones. El c´odigo de la interfaz de usuario es combinado posteriormente con el c´odigo principal de la aplicaci´on y es compilado a˜nadiendo entre otras la biblioteca del toolkit para el que se ha generado la interfaz de usuario. •Al igual que en el caso anterior, la reutilizaci´on en las t´ecnicas S, T, A y H puede resolverse durante el proceso de generaci´on de c´odigo o puede dejarse esta tarea para que se realice en tiempo de ejecuci´on con ayuda del toolkit gr´afico. •Tambi´en los procesos relacionados con la reutilizaci´on mediante las t´ecnicas I, P y B deben ser aplicados en tiempo de desarrollo. Antes de concluir este apartado, hemos de tener en cuenta que las decisiones que se tomen sobre d´onde realizar la reutilizaci´on pueden tener impacto en la flexibilidad y prestaciones del MB-UIDE: En las arquitecturas Generativas, resolver ciertas t´ecnicas de reutilizaci´on en tiempo de desarrollo o de ejecuci´on puede estar determinado por el toolkit seleccionado para el desarrollo de la interfaz de usuario. En las Mixtas, aplicar la reutilizaci´on en tiempo de desarrollo en ciertas t´ecnicas permitir´a simplificar la construcci´on del Run-time del MB-UIDE y seguramente se obtendr´an mejores rendimientos en la generaci´on de la IU Final. Sin embargo, esta decisi´on puede perjudicar al empleo de las t´ecnicas C y F en estos sistemas, ya que los elementos en los repositorios estar´an pretratados para su uso en una situaci´on espec´ıfica, menos ´utiles para un uso general y menos reutilizables por lo tanto. 3.3.2. Estructura de los recursos reutilizables Un recurso reutilizable de la interfaz de usuario puede estar definido en el dominio de un ´unico modelo (p.ej. una unidad de interacci´on de la IU Abstracta) o puede estar compuesto por un conjunto de elementos de varios modelos (p.ej. la interfaz de usuario de un peque˜no sistema de mensajer´ıa formado por elementos del Modelo de Di´alogo, del Modelo de Presentaci´on y del Modelo de Dominio). Seg´un su composici´on, podemos denominar a estos componentes Recursos Mono-modelo yRecursos Multimodelo respectivamente (ver figura 3.4). La aplicabilidad de las t´ecnicas de reutilizaci´on propuestas en este documento estar´a limitada por la estructura y composici´on del recurso reutilizable (ver tabla 3.2): Las T´ecnicas de reutilizaci´on en especificaciones (S, T, A y H, secci´on 3.1), por definici´on funcionan referenciando a un fragmento de especificaci´on o a un template o extendiendo una clase padre, es decir s´olo son aplicables sobre Recursos Mono-modelo. 41 48 CAP´ ITULO 4. WAINE debe contemplar distintos m´etodos de autenticaci´on de usuarios y garantizar que ´estos acceden ´unicamente a los objetos a los cuales se les ha dado acceso y en el modo asignado. Flexibilidad. El sistema debe ser f´acilmente extensible y adaptable a modificaciones del entorno: nuevos or´ıgenes de datos, widgets, sistemas de autenticaci´on, etc. Eficiencia. La eficiencia es una caracter´ıstica siempre deseable, pero en este caso particular el sistema debe ser capaz de ejecutarse en equipos de prestaciones reducidas o en sistemas empotrados. En el resto de la secci´on se presentan los componentes del MB-UIDE: el conjunto de Modelos de la IU empleados, los lenguajes en los que se define cada modelo, los repositorios de modelos, el Run-time de la IU y finalmente el proceso y las herramientas de desarrollo. 4.1.1. Modelos de la interfaz de usuario WAINE trata de simplificar al m´aximo el modelo de una aplicaci´on de gesti´on. En la figura 4.1 se puede observar un esquema del tipo aplicaci´on soportada por el MBUIDE. En este diagrama informal, se puede apreciar que existen usuarios organizados en grupos. Cada uno de ellos accede a las funcionalidades que ofrece la aplicaci´on a trav´es de las opciones de un men´u. Las opciones del men´u pueden lanzar acciones o mostrar un espacio de trabajo (construido con formularios) que tambi´en puede invocar a acciones a trav´es de botones o eventos. Menu 1 Menu 2 opcion N opcion 2 opcion 1 opcion 2 opcion 1 Menu 1 usuario 1 usuario 2 usuario N grupo de usuarios campo 2 campo 1 campo 1 campo 1cam.1 cam.2 campo 1 campo 2 campo 3 EVENTO ! ACCION ! EVENTO ! ACCION ! ACCION ! ACCION ! aplicacion 1 aplicacion 2 tras eliminar al salir Figura 4.1: Diagrama informal del tipo de aplicaci´on soportada por WAINE La interfaz de usuario de una aplicaci´on es definida por un conjunto reducido de modelos. La figura 4.2(b), muestra los modelos empleados por WAINE y su relaci´on con el framework de referencia Cameleon (a). El Modelo de Dominio de WAINE describe los datos que los usuarios manejan empleando la interfaz de usuario y es especificado a trav´es de un Diagrama Entidad- Relaci´on (ver la figura 4.2c). Sus componentes principales son entidades y relaciones. 48 4.1. INTRODUCCI´ ON A WAINE 49 Conceptos y tareas IU Abstracta IU Concreta IU Final IU Final Usuario Platforma Usuario Entorno DER ASL CSS JavaScript HTML Presentacion y dialogo Dominio Contexto Contexto (a) Framework de referencia Cameleon (c) Lenguajes de WAINE(b) Modelos de WAINE Figura 4.2: Modelos y lenguajes de WAINE relacionados con el framework Cameleon A un nivel de abstracci´on inferior de acuerdo con el CRF, los siguientes modelos (cuyos componentes y estructuras aparecen ilustrados en la figura 4.3) determinan m´as directamente el contenido y apariencia de la interfaz de usuario. El Modelo de Presentaci´on. Describe principalmente la IU Abstracta a trav´es de la definici´on de espacios de trabajo mediante Objetos Abstractos de Interacci´on. El Modelo de Presentaci´on posee dos constructores principales: los formularios y los contenedores. 1. Un formulario con sus campos, muestra y manipula una entidad del Modelo de Dominio (o parte de ella) y permite la ejecuci´on de acciones 1a trav´es de eventos (disparadas por el sistema ante una interacci´on del usuario) o de lanzadores de acciones (disparadas de forma directa por los usuarios). Los campos de un formulario (Objetos Abstractos de Interacci´on) se caracterizan por su tipo y por su origen de datos. El tipo define el dominio del campo, es decir el conjunto de valores que el campo admite. El origen del campo es el atributo de la entidad vinculado al campo. Algunas veces el origen de un campo puede ser una expresi´on en la que intervienen valores de otros campos, en este caso les llamamos ”campos calculados”. 2. Los contenedores agregan formularios y/o contenedores para definir la estructura, contenido y comportamiento b´asico de una unidad de interacci´on [122] (i.e. un espacio de trabajo tal como se muestra en la figura 4.11). As´ı, una unidad de interacci´on es definida como una estructura jer´arquica de contenedores y formularios y es identificada por el conenedor de m´as alto nivel (contenedor ra´ız). Los contenedores pueden ser de tipo form (para definir una unidad de interacci´on compuesta por un ´unico formulario), split (para crear una divisi´on del espacio en varias areas), o relation (para crear una divisi´on en dos ´areas que manejan datos interrelacionados). Los contenedores usan determinados par´ametros para especificar c´omo se realiza la divisi´on 1El MB-UIDE soporta por defecto el conjunto de acciones del modelo CRUD (i.e. Create,Retrieve, Update yDelete) para manipular los datos asociados a un formulario. 49 50 CAP´ ITULO 4. WAINE Form ACE FormEvent Field Main ActionLauncher Menu Option User UserEvent Action Group Container Parameter 1..* 1 1..* 1 source type 0..2 type id 1 value name 1..*uses source id type type source caption id caption caption 0..1 1 1 1 0..1 0..1 1 1 0..1 triggers contains name uid type name gid 1 1..* 1 has 0..1 1 1 0..1 references 11 0..* 1 1 triggers triggers 0..1 0..1 0..1 has 0..* references contains triggers contains contains Modelo de Usuario Modelo de Dialogo Modelo de Presentacion 1..* contains 1 0..1 0..1 1 1 1 1 0..1 0..1 involves involves involves Modelo de Seguridad involves Figura 4.3: Modelos de la interfaz de usuario en WAINE espacial (p.ej. filas o columnas) y el contenido de cada zona (p.ej. un formulario u otro contenedor). Se tratar´a a los formularios y contenedores con mayor profundidad en la secci´on 4.1.4. El Modelo de Usuario. Los usuarios se organizan en grupos que tienen roles comunes para la aplicaci´on. Son componentes del modelo grupos, usuarios y sus eventos asociados: 1. Los grupos tienen como atributos principales un gid (identificador de grupo), un nombre y una descripci´on. Tambi´en pueden incluir informaci´on relativa al envejecimiento de las cuentas de usuarios del grupo y datos relativos al perfil (que permiten personalizar la interfaz de usuario a las necesidades de los integrantes del grupo). Estas propiedades son comunes a todos los usuarios que pertenecen al grupo. 2. Los usuarios pertenecen a un ´unico grupo. Adem´as de los mismos atributos del grupo (que en caso de ser definidos ”sobrescriben” los valores definidos para el grupo) disponen de un uid (identificador de usuario), de alg´un tipo de informaci´on para su autenticaci´on y de campos de datos personalizables por los desarrolladores. Tanto para grupos como para usuarios es posible definir vistas espec´ıficas del Modelo de Di´alogo (lo que se traducir´a en la IU Final como el men´u principal de 50 4.1. INTRODUCCI´ ON A WAINE 51 su aplicaci´on como ya veremos) as´ı como eventos que son disparados cuando el usuario accede a la aplicaci´on o la abandona. El Modelo de Di´alogo. Simplemente incluye un conjunto de opciones de men´u accesibles a los usuarios de acuerdo con su grupo. Cada opci´on est´a asociada a una funcionalidad: una unidad de interacci´on a mostrar (identificada por su contenedor de m´as alto nivel), una acci´on a ser ejecutada (disparada por el usuario) o simplemente un enlace con otro recurso de internet a trav´es de una URL. Son elementos del Modelo de Di´alogo: men´us, opciones y acciones. Adem´as de las acciones predefinidas para los formularios (aquellas del modelo CRUD), WAINE permite a los desarrolladores definir sus propias acciones. Modelo de Seguridad: Aunque no nos consta la existencia de trabajos en los que se defina un modelo de seguridad en el MB-UID, creemos que es necesario dotar a estos sistemas de mecanismos que garanticen su seguridad. El principal elemento de este modelo es la Entrada de Control de Acceso que define el acceso de los usuarios o grupos a las funcionalides del sistema: acciones o formularios. Tambi´en forman parte de este modelo los m´etodos de autenticaci´on de usuarios. 4.1.2. Arquitectura WAINE tiene una arquitectura de Run-time (figura 4.4) que es la base para generar la IU Final en tiempo de ejecuci´on. Los dos pilares b´asicos de la arquitectura de WAINE son los repositorios y el motor. Javascript CSS HTML (Base de datos) configuraciones acciones, etc.) BD seguridad, dialogo y presentacion) (Modelos usuario, RIU MOTOR WAINE (IU Final) RC (IU concreta, (Run−Time de la IU) Figura 4.4: Arquitectura de WAINE Las aplicaciones desarrolladas con WAINE emplean tres repositorios: Repositorio de la IU (RIU), almacena las instancias de los modelos de la interfaz de usuario de la figura 4.3. Base de Datos (BD), soporta los elementos manejados por la interfaz de usuario (i.e. los objetos del Modelo de Dominio). El motor de WAINE usa una capa de abstracci´on de acceso a datos (ver figura 4.6) que permite la conexi´on a distintos or´ıgenes de datos, proporcionando independencia en este sentido (se detalla en la siguiente subsecci´on). 51 52 CAP´ ITULO 4. WAINE _group_menu _option _ace _field _user _action _userevent _formevent _actionlauncher _main _form _parameter_container 1:N 1:N 0:N 0:1 0:2 1:1 0:N 0:N 1:1 1:1 1:N 0:N 0:N 0:1 0:N 0:1 1:N 0:N 0:N Figura 4.5: Modelo conceptual del repositorio de la interfaz de usuario Repositorio de Configuraciones (RC), almacena elementos de distinta naturaleza: 1. Configuraciones de diversos aspectos de la aplicaci´on: m´etodo de autenticaci´on de usuarios a emplear, accesos a bases de datos, idioma por defecto para la interfaz de usuario, etc. 2. Definiciones de la presentaci´on concreta de la interfaz de usuario: estilos, fuentes, colores, etc. Estas definiciones pueden ser asignadas a la aplicaci´on completa o un determinado formulario, men´u, usuario o grupo. 3. Acciones definidas por los desarrolladores: WAINE permite a los desarrolladores definir sus propias acciones en cualquier lenguaje de programaci´on (aunque normalmente se emplea para ello PHP). Las acciones son almacenadas en un directorio espec´ıfico del Repositorio de Configuraciones. 4. Clases/objetos definidos por los desarrolladores: uno de los objetivos de WAINE es ser flexible y extensible. Para ello consta de varios pools de objetos que permiten a los desarrolladores extender las capacidades del motor, a˜nadiendo nuevos m´etodos de autenticaci´on, drivers de acceso a datos, widgets 2y 2Un widget (Objeto Concreto de Interacci´on en WAINE) define el aspecto y comportamiento concre- to de un campo. El dominio de un campo asigna un widget por defecto al mismo, pero los desarrolladores pueden asignar uno de los widgets soportados por WAINE o definir sus propios widgets. 52 4.1. INTRODUCCI´ ON A WAINE 53 layouts3. Al crear una instancia para una nueva aplicaci´on, WAINE genera un Repositorio de Configuraciones con valores por defecto. Esto dota a la aplicaci´on de una configuraci´on y presentaci´on concreta (colores, fuentes, etc.) que los desarrolladores pueden modificar. Para poner la aplicaci´on en funcionamiento s´olo ser´a necesario configurar en el Repositorio de Configuraciones el m´etodo de autenticaci´on de los usuarios y el acceso a la Base de Datos. El motor de WAINE o Run-time de la IU , lee los repositorios anteriores para generar en tiempo de ejecuci´on la IU Final, formada por HTML, CSS y Javascript. Teniendo en cuenta los tipos de arquitecturas de MB-UIDEs identificadas por Silva [95] (ver secci´on 2.1) podemos apreciar que WAINE sigue una arquitectura Mixta, en la que las especificaciones son pretratadas y almacenadas en un soporte (Repositorio de la IU ) que posteriormente es empleado por el Run-time del sistema. En la figura 4.6, se muestra la arquitectura interna del Run-time. Podemos observar que el motor est´a compuesto por un conjunto de m´odulos o subsistemas (Men´us, Forms, Exports, etc.) que emplean los servicios ofrecidos por dos capas de abstracci´on: la de acceso a datos y la de renderizado. Estas capas de software permiten acceder a distintos or´ıgenes de datos y generar todos los objetos de la interfaz de usuario. De forma adicional, el m´odulo de usuarios y seguridad ofrece control de acceso y servicios de autenticaci´on al resto de m´odulos. Las capas de acceso a datos, renderizado y seguridad pueden ser extendidas por los desarrolladores para dotar al motor de nuevas capacidades. 4.1.3. Lenguaje de descripci´on de la interfaz de usuario WAINE emplea varios lenguajes durante el proceso de desarrollo de la interfaz de usuario. En la figura 4.2, se pueden apreciar los principales lenguajes utilizados (c), su relaci´on con los modelos de WAINE (b) y con el framework de referencia Cameleon (a). Los Diagramas Entidad-Relaci´on son empleados como lenguaje gr´afico para expresar el Modelo de Dominio (nivel de Conceptos y Tareas). Los modelos de Presentaci´on yDi´alogo (IU Abstracta en WAINE), el Modelo de Usuario (Contexto), as´ı como el Modelo de Seguridad se definen en ASL [20]. ASL (Application Specification Language) es un Lenguaje de Descripci´on de la IU propio de WAINE basado en XML. La IU Final es generada de forma autom´atica y se define empleando HTML, CSS y JavaScript. Se ha de tener en cuenta que en el proceso de desarrollo tambi´en se emplea PHP para definir widgets,layouts, etc. y para implementar acciones definidas por los desarrolladores (para esto ´ultimo tambi´en es posible emplear otros lenguajes de programaci´on). Emplear varios lenguajes en WAINE fue una decisi´on de dise˜no para intentar facilitar el aprendizaje del sistema: se decidi´o utilizar, siempre que fuera posible, un lenguaje bien conocido (CSS, PHP, etc.) y si este requisito no se pudiera cumplir, definir un 3Las plantillas y los layouts se emplean para describir c´omo deben distribuirse los campos dentro de un formulario, pero mientras que la plantilla es una definici´on est´atica para un formulario particular, los layouts se ajustan din´amicamente a las necesidades de cualquier formulario. Existen varios layouts predefinidos (p.ej. tabla, ficha, rejilla, etc.). 53 54 CAP´ ITULO 4. WAINE Menus Forms Report Exports Capa de acceso a datos Capa de renderizado BD RIU RC OTROSPSXMLHTML seguridad Usuarios y Run−time de la IU PDF Figura 4.6: Arquitectura del run-time lenguaje de especificaci´on sencillo (ASL). Se realiz´o un an´alisis simple de los Lenguajes de Descripci´on de la IU candidatos. La tabla 4.1 muestra un resumen de los lenguajes estudiados. Para cada lenguaje se muestran los modelos que soporta y el n´umero de etiquetas que utiliza (como indicador b´asico de su complejidad). Todos los lenguajes de la relaci´on ofrecen caracter´ısticas interesantes [45, 115], pero finalmente se decidi´o definir un Lenguaje de Descripci´on de la IU propio para WAINE por las siguientes razones: No todos los lenguajes est´an disponibles de forma libre (p.ej. XIML). Algunos lenguajes presentan demasiada complejidad (p.ej. UsiXML, ver columna tags de la tabla 4.1). Algunos lenguajes est´an orientados a la soluci´on de problemas espec´ıficos (p.ej. XUL). Otros no soportaban el conjunto de modelos necesario para cumplir con los requisitos de dise˜no (p.ej. AUIML, UIML, XUL, XICL). En general, los Lenguajes de Descripci´on de la IU presentan una larga curva de aprendizaje, ya que manejan conceptos propios de la Interfaz Hombre-M´aquina, a los que nuestros ”potenciales clientes” (estudiantes y programadores noveles) no est´an habituados. En ASL se ha intentado obtener un equilibrio entre el n´umero de modelos soportados y la complejidad del lenguaje (n´umero de etiquetas), as´ı como utilizar un ”vocabulario” conocido por los desarrolladores (i.e. usuario, grupo, men´u, formulario, etc.). Obs´ervese, que disponer de un Lenguaje de Descripci´on de la IU , independiza al sistema de las herramientas de especificaci´on (uno de los criterios iniciales de dise˜no, secci´on 4.1), ya 54 4.1. INTRODUCCI´ ON A WAINE 55 Lenguaje MDO MU MT MP MD tags UIML X X X 50 AUIML X X m´as de 55 XUL X X m´as de 60 XIML X X X X 32 Teresa XML X X X 19 UsiXML X X X X m´as de 100 XICL X X 13 IMML X X X 52 ASL X X X 50 Tabla 4.1: Comparativa de UIDLs: modelos soportados y etiquetas empleadas que se pueden emplear simples editores de texto, editores especializados, herramientas gr´aficas, etc. para generar las especificaciones. Un documento ASL tiene las siguientes secciones: La cabecera: suele contener meta-informaci´on del documento (p.ej. autor, fecha de creaci´on, etc.). Grupos y usuarios: descripci´on de usuarios, grupos y sus propiedades (Modelo de Usuario). Men´us: conjunto de men´us a los que acceden los usuarios (Modelo de Di´alogo). Formularios y contenedores: formularios con sus campos y contenedores de formularios (Modelo de Presentaci´on). Entradas de control de acceso implicando a usuarios/grupos con formularios/acciones (Modelo de Seguridad). La sintaxis completa del lenguaje ASL en formato DTD se muestra en el ap´endice A. 4.1.4. Proceso de desarrollo y generaci´on de la interfaz de usuario En este apartado se presenta el proceso de desarrollo de aplicaciones con WAINE y su relaci´on con la generaci´on autom´atica de la interfaz de usuario. Analizaremos c´omo los anteriores elementos: modelos, lenguajes y repositorios est´an relacionados con ambos procesos (desarrollo y generaci´on de la interfaz de usuario). WAINE define un proceso sistem´atico de desarrollo de aplicaciones. Esta caracter´ıstica del MB-UIDE, permite guiar el desarrollo de la interfaz de usuario ofreciendo a los desarrolladores un m´etodo para la construcci´on de aplicaciones. Este proceso tiene cinco fases. La figura 4.7 muestra las fases de desarrollo y los productos resultantes de cada una de ellas. 55 56 CAP´ ITULO 4. WAINE ASL <ASL> <HEAD> <GROUP GID=0 NA </HEAD> <META CLASS=" ASL <ASL> <HEAD> <GROUP GID=0 NA </HEAD> <META CLASS=" ERD DER y tabla Conjunto de RepositoriosDocumento de analisis DERs anotadosrol/funcionalidad Especificacion ASL 4 53 2 1 Roles and functionalities ERD−UI 1 Roles and functionalities ERD−UI 2 ERD−UI 1 Analysis document ERD Figura 4.7: Proceso de desarrollo de una aplicaci´on con WAINE 1. La redacci´on de un breve documento de an´alisis. 2. El dise˜no conceptual de la BD y la especificaci´on de funcionalidades del sistema. 3. La definici´on del Modelo de Presentaci´on a trav´es de la anotaci´on del modelo conceptual. 4. La descripci´on de los modelos de Usuario,Di´alogo,Presentaci´on ySeguridad en el lenguaje ASL. 5. La generaci´on de los repositorios: Repositorio de la IU ,Base de Datos yRepositorio de Configuraciones. En la figura 4.8 se muestran las cinco fases del proceso de desarrollo de la interfaz de usuario, los productos resultantes de cada una de ellas y todo ello se relaciona con los niveles del framework de referencia Cameleon. Pasamos a describir en profundidad cada una de las etapas. 1. An´alisis. El proceso de desarrollo comienza realizando entrevistas a usuarios expertos. En estas entrevistas se capturan los requisitos de la aplicaci´on a desarrollar y con la informaci´on obtenida se redacta un peque˜no documento de an´alisis en el que se incluyen las funcionalidades, los roles de los usuarios y bocetos de las principales interfaces de usuario e informes empleados por cada rol. 2. Modelado de conceptos. El documento de an´alisis es la base para la elaboraci´on de dos documentos: (a) la tabla de roles/funcionalidades (ver tabla 4.2) que indica las acciones e interfaces de usuario necesarias para cada rol y (b) el modelo conceptual de la base de datos que se plasma en un Diagrama Entidad-Relaci´on. Este diagrama que representa el Modelo de Dominio de la aplicaci´on, recoge los conceptos que son manejados por la misma y es el modelo de partida para el desarrollo de la interfaz de usuario. 3. Anotaci´on del Diagrama Entidad-Relaci´on. En la tercera fase se especifica cada espacio de trabajo (ver figura 4.11) de la interfaz de usuario mediante un proceso de refinamiento que parte del Diagrama Entidad-Relaci´on obtenido en el paso 2. Para ello se toma la porci´on de Diagrama Entidad-Relaci´on que afecta a la unidad 56 4.1. INTRODUCCI´ ON A WAINE 57 BD RC RIU Usuario Presentacion DialogoTabla rol / funcionalidad 1 DER SQL R R R Interfaz de usuario Abstracta ASL Conceptos y Tareas Contexto Tiempo de desarrollo de la IU Doc. Analisis requisitos DER−IU Refinamiento Operacion Uso en run−time 25 34 Figura 4.8: Proceso de desarrollo de la interfaz de usuario de interacci´on que se est´a definiendo y se enriquece anotando sobre ´el las partes que lo forman: formularios y contendores. Vamos a ilustrar y profundizar en la especificaci´on de la unidad de interacci´on a trav´es de un ejemplo. Desarrollaremos una aplicaci´on que administre citas de pacientes a trav´es de un ´unico espacio de trabajo. La estructura visual de la unidad de interacci´on de nuestro ejemplo est´a compuesta de dos zonas horizontalmente divididas que sostiene una relaci´on uno-muchos. Esto es definido a trav´es de un contenedor de tipo relaci´on identificado como csample. La figura 4.9(a) muestra c´omo el contendor se anota sobre el Diagrama Entidad-Relaci´on a trav´es de una l´ınea punteada alrededor de las entidades implicadas y etiquetada con el tipo del contenedor y su identificador. El ´area superior contendr´a un formulario que maneja las tuplas de la entidad Patient. El identificador del formulario (fpatient) se anota en la esquina superior izquierda de la propia entidad. Para cada formulario tambi´en se anota su layout en la esquina inferior derecha. Recordemos que el layout expresa la forma en la que los campos se distribuyen dentro del formulario (p.ej. table,grid,list, etc.). En la zona inferior del contenedor csample se divide IU1 IU2 .. IUN A1 A2 .. AN ROL1 X X X X X ROL2 X X :X ROLN X X X X Tabla 4.2: Tabla Rol/funcionalidad 57 64 CAP´ ITULO 4. WAINE aslmod: Valida un fragmento de especificaci´on ASL para que pueda ser incluida posteriormente desde otra especificaci´on. Se trata con mayor profundidad en la secci´on 4.2.3. wpkg: Es la herramienta para gesti´on de paquetes de WAINE. Hablaremos de ella con m´as profundidad en la secci´on 4.2.4. Las dos ´ultimas herramientas, est´an relacionadas con t´ecnicas de reutilizaci´on implementadas en WAINE y se tratar´an con mayor profundidad en las siguientes secciones. 4.2. T´ecnicas de reutilizaci´on soportadas por WAINE Uno de los objetivos principales de WAINE es el desarrollo r´apido de aplicaciones. Ello nos ha conducido a soportar de forma proactiva la reutilizaci´on. En esta secci´on se presentan las t´ecnicas de reutilizaci´on presentes en WAINE; implementaciones de algunos de los m´etodos que de forma m´as general hemos presentado en las secciones 3.1 y 3.2. RC RIU BD 00 00 00 11 11 11 000 000 000 111 111 111 0000 0000 0000 1111 1111 1111 00 00 00 11 11 11 0 0 0 1 1 1 000 000 000 111 111 111 0000 0000 0000 1111 1111 1111 0000 0000 0000 1111 1111 1111 Presentation Dialogs Doc. Analisis requisitos DER Tabla rol / funcionalidad Motor WAINE ERD−UI SQL HI Adaptacion Inclusion FederacionCentralizacion Subespecificacion Adaptacion Herencia Paquetes Users ASL R R Conceptos y Tareas Interfaz de usuario abstracta Contexto BibliotecasHerencia A Paquetes No sobre especificaciones de Modelos de la IU A I FC S A PH B I H P 000 000 111 111 00 00 11 11 FC S I A FC B FC P P P Figura 4.12: Contexto de uso de las t´ecnicas de reutilizaci´on implementadas 4.2.1. Subespecificaci´on y adaptaci´on (S,A) WAINE utiliza varios lenguajes durante el proceso de desarrollo de la interfaz de usuario. De todos ellos ASL es el lenguaje principal y ha sido desarrollado para permitir el uso de la subespecificaci´on y de la adaptaci´on. 64 4.2. T´ ECNICAS DE REUTILIZACI´ ON SOPORTADAS POR WAINE 65 Respecto a la subespecificaci´on, hay varios elementos que pueden ser ”subespecificados” (fragmentos de c´odigo referenciados desde otros puntos de la especificaci´on). En la figura 4.13, se muestra la jerarqu´ıa de las etiquetas principales de ASL y sus relaciones. Las flechas punteadas entre etiquetas indican subespecificaci´on. Podemos ver que desde la definici´on de usuarios o grupos se puede referenciar a un mismo men´u. Tambi´en que desde varias opciones de distintos men´us se puede referenciar a la misma unidad de interacci´on (identificada por el contenedor de m´as alto nivel). Observe tambi´en en la figura 4.13 que objetos de otros modelos (que residen en el Repositorio de Configuraciones o en la Base de Datos) tambi´en pueden ser ”subespecificados” y por lo tanto reutilizados, como por ejemplo tablas, acciones o estilos. PROP? USER* PROP? PARAM* EVENTS? FIELD* MENU* OPTION* ACTION? ACTION LAUNCHER? opcional MAIN* INCLUDE* HEAD? FALLBACK* META* ASL GROUP* CONTAINER* USARIO MODELO DIALOGO MODELO MODELO PRESENTACION referencias a elementos en el repositorio de configuraciones o la base de datos ?: cardinalidad 0..1 *: cardinalidad 0..N FORM* Figura 4.13: Subespecificaci´on y adaptaci´on en ASL. La adaptaci´on en ASL se emplea sobre todo en el Modelo de Presentaci´on. Los formularios pueden ser adaptados en muchos aspectos a trav´es de la etiqueta del lenguaje <param>(ver figura 4.13). Pr´acticamente cualquier atributo o componente de un formulario puede ser modificado, lo que dota de una enorme flexibilidad al Modelo de Presentaci´on en cuanto a reutilizaci´on se refiere. A modo ilustrativo veamos un par de ejemplos de adaptaci´on de un formulario. En la figura 4.14(a) vemos el formulario frm sample utilizando un layout de tipo tabla, mostrando su apariencia por defecto. En la figura 4.14(b), podemos observar, c´omo por medio de la adaptaci´on, el formulario ha perdido el campo Sex (tercer campo) y c´omo los campos Name yAge (primer y segundo campo) pasan a estar en modo lectura. Por ´ultimo, en la figura 4.14(c), se modifica el tercer campo (Sex) para que emplee el widget radio en lugar del que se estaba usando por defecto. La adaptaci´on en el Modelo de Presentaci´on es una herramienta potente, que permite que un mismo formulario pueda reutilizarse para circunstancias y usos distintos. Como ya se ha comentado en la secciones anteriores, la arquitectura de WAINE es de tipo Mixta, empleando un Repositorio de la IU que contiene versiones pretratadas de las especificaciones. En este tipo de sistemas, la t´ecnicas de reutilizaci´on en especificaciones (S, T, A, H) pueden ser resueltas en tiempo de desarrollo o en tiempo de ejecuci´on 65 66 CAP´ ITULO 4. WAINE <param name="formid" value="frm_sample"/> <param name="form_layout" value="table"/> <param name="formid" value="frm_sample"/> <param name="form_layout" value="table"/> <param name="formid" value="frm_sample"/> <param name="form_layout" value="table"/> value="widget#radio#3"/> <param name=" "fields_modify[0] <param name=" " value="3"/>fields_remove <param name=" " value="1−2"/>fields_readonly (a) (b) (c) <container id=" " type="form">sample </container> </container> <container id=" " type="form">sample_p1 </container> <container id=" " type="form">sample_p2 Figura 4.14: Ejemplo de adaptaci´on en ASL (secci´on 3.3.1). El pretratamiento ligero de las especificaciones realizado en WAINE (herramienta asl2mdb) hace que las t´ecnicas de subespecificaci´on y adaptaci´on se resuelvan en tiempo de ejecuci´on por el motor. ASL no es el ´unico lenguaje implicado en el desarrollo de la interfaz de usuario con 66 4.2. T´ ECNICAS DE REUTILIZACI´ ON SOPORTADAS POR WAINE 67 WAINE. La adaptaci´on tambi´en es aplicable en la implementaci´on de widgets en PHP. El comportamiento y c´odigo final de cada campo de un formulario se corresponde en WAINE con un objeto de las clases widget omwidget4codificados en PHP (ver figura 4.15). Existen multitud de widgets predefinidos, pero los desarrolladores pueden crear nuevos widgets adaptando las clases existentes (con el m´etodo setCode) o extendiendo las clases b´asicas (se ver´a con m´as detalle en el siguiente apartado). En el listado 4.6, se muestra un nuevo widget (passwordbox) que es creado adaptando la clase base widget. En el ejemplo vemos c´omo se redefine el c´odigo HTML que debe generarse cuando el objeto se muestra en modo escritura (W). Obs´ervese que en este caso, la adaptaci´on tambien es resuelta en tiempo de ejecuci´on (aunque propiamente no se trate de una especificaci´on de la interfaz de usuario). // Se crea un nuevo widget $newwdg=new widget ( ) ; // El widget es adaptado indicando e l codigo f i n a l a // generar cuando es presentado en modo e s c r i t u r a ’W’ $newwdg−>setCode( ’W’ , ”<INPUT type =’password ’ name=’ %name %’ value=’ %value %’ s i z e=’ %len %’ maxlength=’ %maxlen %’ s t y le=’ %s t y l e %’/>” ) ; // El nuevo o bj et o se int roduce en e l pool de widgets $WDGPOOL−>add ( ’ passwordbox ’ , $newwdg) ; Listado 4.6: Ejemplo de nuevo widget creado por adaptaci´on 4.2.2. Herencia (H) ASL no define ning´un mecanismo de herencia. Sin embargo, como se ha comentado en el punto anterior, la herencia es empleada como mecanismo para permitir la implementaci´on de nuevos widgets. A modo de ejemplo, podemos ver en la figura 4.15 la relaci´on de herencia de algunos de los widgets de WAINE. textbox combonull listbox widget mwidget Figura 4.15: Relaci´on de herencia de algunos widgets 4La clase widget es la clase de la que heredan todos los widgets del sistema. La clase mwidget tambi´en deriva de la clase widget, pero es la clase base para aquellos widgets cuyo valor proviene de la selecci´on de un valor dentro de una lista de valores posibles (p.ej. un combobox). 67 68 CAP´ ITULO 4. WAINE En el c´odigo que se presenta en el listado 4.7 se puede apreciar c´omo la clase combonull5hereda de la clase mwidget y c´omo la nueva clase redefine el m´etodo RenderW 6 reutilizando el resto del c´odigo de la clase padre. class combonull extends mwidget { function RenderW( $IN name , $IN value , $IN f ld , $ I N l s t v a l ) { // se i nc lu ye e l valor nulo en l a l i s t a de v alo re s s e l e c c i o n a b l e s $ l s t v a l=array (array ( ’ ’ , $IN fld −>wdgparam) ) ; // se invoca a l metodo RenderW de l a c l a s e padre con $l s t v a l return ( parent : : RenderW( $IN name , $IN value , $IN fld , array merge ( $ l s t v a l , $ I N l s t v a l ) ) ) ; } } $newwdg=new combonull ( ) ; // El nuevo o bj et o se int roduce en e l pool de widgets $WDGPOOL−>add ( ’ combonull ’ , $newwdg ) ; Listado 4.7: Ejemplo de nuevo widget definido por herencia La herencia de las clases widget es resuelta por el int´erprete de PHP en tiempo de ejecuci´on. Por ´ultimo, entendiendo el t´ermino de forma flexible, podr´ıamos decir que la relaci´on existente entre usuarios y grupos en ASL es tambi´en una relaci´on de herencia. En el ap´endice A.1, podemos observar c´omo los atributos de las etiquetas <user>y <group>son comunes en un alto porcentaje. En la secci´on 4.1.1, se ha comentado que los atributos del grupo son aplicados a todos los usuarios que forman parte del mismo, pero que cuando los usuarios definen alguno de los atributos comunes con los del grupo, los valores del atributo del usuario ocultan o sobrescriben los del atributo del grupo. Este funcionamiento del Modelo de Usuario es an´alogo a una relaci´on de herencia como la mostrada en la figura 4.16. El Run-time de WAINE es el encargado de recrear esta relaci´on en tiempo de ejecuci´on. 4.2.3. Inclusi´on y Bibliotecas de reutilizaci´on (I,B) ASL es el lenguaje principal de modelado en WAINE. Es el lenguaje que define los modelos de Usuario,Di´alogo,Presentaci´on ySeguridad. Tambi´en es el lenguaje que suele emplear mayor n´umero de l´ıneas de c´odigo en el desarrollo de la interfaz de usuario (como se ver´a m´as adelante). Debido al tama˜no que llegan a alcanzar algunas especificaciones se hace necesario disponer de un mecanismo para la modularizaci´on 5El widget combonull es un elemento de interacci´on que permite la selecci´on de una ´unica opci´on de una lista de valores dentro de la que se admite el valor nulo. 6M´etodo encargado de generar el c´odigo del widget cuando se encuentra en modo escritura (W). 68 4.2. T´ ECNICAS DE REUTILIZACI´ ON SOPORTADAS POR WAINE 69 − gid − name − descr + mainid + ufields[] + account.validto Group + account.changeat + account.lock + mainid + ufields[] + account.validto User + account.changeat + account.lock − name − descr − uid Figura 4.16: Relaci´on de herencia entre grupos y usuarios de las mismas. Al tratarse de un lenguaje XML, existe una soluci´on inmediata para el mecanismo de inclusi´on: XInclude. XInclude [65] es un est´andar muy extendido del W3C que define un modelo de procesamiento y una sintaxis de prop´osito general para la inclusi´on o fusionado de documentos XML. Es ampliamente aceptado por la comunidad de desarrolladores, se emplea en multitud de ´ambitos, entornos y plataformas y existen gran n´umero de herramientas y utilidades que lo soportan. Sin embargo, XInclude, adem´as de los problemas generales de los m´etodos de inclusi´on (fusi´on), presenta algunas limitaciones. El est´andar no define ninguna relaci´on con los procesos de validaci´on y transformaci´on del documen- to. XInclude describe una transformaci´on infoset-to-infoset [65] pero no especifica el comportamiento respecto al an´alisis del documento XML. As´ı, un documento puede ser validado antes o despu´es de realizar la inclusi´on, en ambos casos o en ninguno. Queda en manos del desarrollador decidir cu´ando los documentos XML deben ser validados y/o transformados en este proceso. Respecto a su implementaci´on en ASL, el lenguaje en sus primeras versiones no soportaba XInclude, as´ı que fue necesario modificar el DTD original (a˜nadiendo el c´odigo mostrado en el listado 4.8) para soportar las etiquetas definidas por el est´andar [65]. <!ELEMENT x i : i n c l u d e ( x i : f a l l b a c k ?)> <!ATTLIST x i : i n c l u d e xmlns:xi CDATA #FIXED ” ht tp : //www. w3 . org /2001/ XInclude ” href CDATA #IMPLIED parse (xml|text ) ”xml” xpointer CDATA #IMPLIED encoding CDATA #IMPLIED accept CDATA #IMPLIED 69 70 CAP´ ITULO 4. WAINE accept−language CDATA #IMPLIED > <!ELEMENT x i : f a l l b a c k ANY> <!ATTLIST x i : f a l l b a c k xmlns:xi CDATA #FIXED ” ht tp : //www. w3 . org /2001/ XInclude ” > Listado 4.8: DTD para las etiquetas definidas por el est´andar XInclude S´olo con realizar esta modificaci´on al lenguaje, es posible modularizar las especificaciones de gran tama˜no en fragmentos m´as manejables que posteriormente son fusionados en una ´unica especificaci´on mediante la inclusi´on (ver listado 4.9). <ASL> <XI:INCLUDE HREF=” cabecera . a s l ”/> <XI:INCLUDE HREF=” u suari o . a s l ”/> <XI:INCLUDE HREF=” di alog o . a s l ”/> <XI:INCLUDE HREF=” pr ese nta cion . a s l ”/> </ASL> Listado 4.9: Modularizando una especificaci´on con XInclude Sin embargo, esta soluci´on no es suficiente para la distribuci´on de componentes reutilizables. Recordemos que XInclude presenta una limitaci´on importante: el est´andar no define ninguna relaci´on con la validaci´on ni con la transformaci´on del documento. Obviamente un recurso reutilizable que puede ser distribuido para su uso en distintos proyectos (o incluso ser incluido en una biblioteca de reutilizaci´on) debe ser validado antes de su distribuci´on, por lo tanto, es necesario disponer de herramientas para validar estos recursos. Esto que en principio puede parecer trivial no lo es, ya que los fragmentos reutilizables no son documentos ASL ”bien formados” (son trozos de una especificaci´on ASL) y por lo tanto requieren de una validaci´on propia. Para resolver este problema se han introducido dos nuevos elementos en ASL: La etiqueta <aslmod>es empleada para definir un componente reutilizable (un fragmento de c´odigo ASL) que debe ser especificado en su propio documento y encerrado entre las etiquetas <aslmod>y</aslmod>. Por otra parte, la herramienta aslmod que valida los componentes reutilizables y los deja preparados para ser incluidos en futuras especificaciones (incluyendo valores por defecto para atributos, etc.). En el ap´endice C se muestra el c´odigo correspondiente a un componente ASL: la unidad de interacci´on meta.container.appinfo empleada de forma frecuente en las aplicaciones desarrolladas con WAINE para mostrar informaci´on sobre la propia aplicaci´on (al estilo del t´ıpico di´alogo ”Acerca de” o ”Sobre este programa”). Recordemos (ver tabla 3.1), que la t´ecnica de inclusi´on en arquitecturas de tipo Mixta como la de WAINE debe ser resuelta en tiempo de desarrollo. En la figura 4.17, se muestra el proceso completo de validaci´on →inclusi´on → transformaci´on de una especificaci´on ASL. Como se ha comentado en este apartado, los 70 4.2. T´ ECNICAS DE REUTILIZACI´ ON SOPORTADAS POR WAINE 71 componentes ASL deben ser previamente validados y preparados con la herramienta aslmod (1). Las especificaciones son validadas antes de la inclusi´on de los componentes (2) y posteriormente se incluyen ´estos para obtener la especificaci´on completa (3). Finalmente se efect´ua el proceso de transformaci´on de la especificaci´on final al formato que soporta el Repositorio de la IU con la herramienta asl2mdb (4). XIncludeEspecificacion Validacion 1 Transformacion Especificacion Completa Formato Final Componente Validacion Componente Componente Validada Validado Especificacion 23 4 Figura 4.17: Validaci´on, inclusi´on y transformaci´on de una especificaci´on ASL Respecto a la inclusi´on, tambi´en es necesario mencionar que fuera de las especificaciones, en el Repositorio de Configuraciones, tambi´en es utilizada. En este caso, suele emplearse cuando se est´an definiendo en lenguaje PHP nuevas acciones, widgets,layouts, etc. Esta inclusi´on que afecta a la implementaci´on de ciertos artefactos, es resuelta en tiempo de desarrollo al contrario que inclusi´on en especificaciones (secci´on 3.3) que es resuelta en tiempo de desarrollo. Para finalizar, se ha de destacar que en cada distribuci´on de WAINE existe un directorio denominado include que contiene la ”biblioteca est´andar” de especificaciones ASL. Como se coment´o en la secci´on 3.1.4, agrupar diversos componentes en un directorio junto con la t´ecnica de inclusi´on permite crear bibliotecas de componentes de especificaciones. La biliblioteca est´andar de WAINE, aunque a´un muy reducida y en estado incipiente, contiene una serie de unidades de interacci´on de uso com´un: chpasswd.asl: Formularios para el cambio de claves de usuario. motd.asl: Visualizaci´on/edici´on del mensaje del d´ıa de la aplicaci´on (mensaje al estilo motd,Message of the Day de los sistemas Unix). todo.asl: Lista de tareas personales para cada usuario. useradm.asl: Espacios de trabajo para la administraci´on de usuarios. meta.asl: Visualizaci´on de metainformaci´on de la aplicaci´on. 4.2.4. Paquetes (P) WAINE no s´olo utiliza ASL para crear una interfaz de usuario funcional, sino que se emplean otros ficheros y lenguajes (SQL, PHP, ficheros de configuraci´on, etc.). Esto 71 72 CAP´ ITULO 4. WAINE dificulta la reutilizaci´on de una interfaz de usuario con todos los elementos que pueden llegar a constituirla (formularios, colores, widgets, acciones, etc.). La idea de emplear paquetes surgi´o para resolver el problema que representa la distribuci´on y reutilizaci´on de este tipo de componentes. Para WAINE se ha desarrollado un peque˜no Sistema de Gesti´on de Paquetes con el objetivo de reutilizar recursos de cualquier complejidad y composici´on [22]. Sus principales componentes son los archivos wpk y la herramienta wpkg: Los archivos wpk (ver figura 4.18), contienen fragmentos en cualquiera de los lenguajes que emplea el MB-UIDE (ver secci´on 4.1.3), un archivo meta.xml conteniendo metainformaci´on sobre el paquete y un par de scripts preins.sh ypostins.sh que son ejecutados antes y despu´es de la instalaci´on del componente respectivamente. Todo el contenido se comprime en un archivo con formato tgz (tar+gzip) al que se le da extensi´on .wpk. UIM.asl file 1 file 2 file N meta.xml postins.sh preins.sh ASL FILES META WPK Figura 4.18: Contenido de un fichero wpk El archivo meta.xml contiene informaci´on sobre el propio paquete: nombre del paquete, versi´on, autor, etc. Esta informaci´on es utilizada para alimentar la base de datos de paquetes instalados, resolver dependencias y detectar posibles conflictos. En el listado 4.10 se muestra el contenido del archivo meta.xml para el paquete Percon. Este paquete contiene una unidad de interacci´on para gestionar datos de contacto de personas. Como podemos ver en el archivo aparece informaci´on como el nombre y versi´on del paquete, el nombre del autor y la fecha de creaci´on, as´ı como una descripci´on del mismo. Tambi´en podemos ver que aparece una relaci´on de funcionalidades ofrecidas por el paquete (etiqueta <provides>), entendiendo por funcionalidad el nombre de los elementos contenidos en el paquete (formularios, widgets, acciones, etc.). Asimismo, aparece una relaci´on de paquetes de los que depende la instalaci´on del paquete actual (etiqueta <depends>). <wpkg> <package> <name>Percon</name> <ver>0.2</ver> <author>A. L . Delgado</author> <date>27−11−2006</date> 72 4.2. T´ ECNICAS DE REUTILIZACI´ ON SOPORTADAS POR WAINE 73 <description> A component to manage personal contact info r m a t ion: addresses , telephons , emails , . . . </description> </package> <provides> <func>percon . contain er . main</func> <func>percon . form . people</func> <func>percon . form . address</func> <func>percon . form . telephon</func> <func>percon . form . email</func> <func>percon . form . notes</func> </provides> <depends> </depends> </wpkg> Listado 4.10: Archivo meta.xml del paquete Percon La herramienta wpkg se emplea para gestionar los paquetes. Permite listar los componentes instalados, a˜nadir, modificar y eliminar paquetes a una instancia de aplicaci´on. Los paquetes pueden ser aplicados tanto en sistemas en desarrollo como en sistemas en producci´on (en este caso sobre un reposiorio). En caso de ser aplicados en sistemas en desarrollo, el paquete contendr´a diversos fragmentos de c´odigo que el desarrollador a˜nadir´a a su proyecto. Si por el contrario el paquete es aplicado sobre un sistema en producci´on, el script postins.sh se encargar´a de procesar y a˜nadir cada uno de los elementos a su repositorio correspondiente. Los paquetes son utilizados en tiempo de desarrollo. Su empleo sobre sistemas en producci´on resulta de utilidad en las fases de mantenimiento. 4.2.5. Repositorios compartidos: centralizaci´on y federaci´on (C,F) La arquitectura Mixta de WAINE posibilita que la centralizaci´on y la federaci´on de repositorios sean implementadas en este sistema. Para que estas t´ecnicas sean aplicables, los repositorios compartidos deben soportar el acceso concurrente de varios de Runtimes y estos ´ultimos deben ser capaces de acceder a varios repositorios 7. Tambi´en hay otros asuntos que es necesario tratar. En primer lugar es necesario resolver el problema de la localizaci´on de objetos, es decir, hay que determinar en qu´e repositorio se encuentran los elementos que deseamos utilizar. En segundo lugar, es necesario controlar el acceso a los Modelos de la IU centralizados, teniendo en cuenta qu´e Run-times pueden hacer uso de los modelos centralizados y cu´ales no. En realidad el control de acceso en estos sistemas debe ser m´as exhaustivo, siendo necesario tomar en consideraci´on a los usuarios, determinando cu´ales son los objetos del modelado a 7Al menos dos para el caso de la centralizaci´on: el local y el centralizado. 73 80CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID para cada aplicaci´on los datos relativos a la segunda etapa del proceso de desarrollo: n´umero de grupos de usuarios (roles como profesor, estudiante, etc.), n´umero de funcionalidades, n´umero de unidades de interacci´on y n´umero de tablas y vistas de la base de datos. Las columnas 6ay 7amuestran la duraci´on del proyecto en semanas (una semana es equivalente a 40 horas de trabajo) y el tama˜no de las especificaciones ASL en l´ıneas de c´odigo (etapa 4 en el proceso de desarrollo, secci´on 4.1.4). La ´ultima columna resume el objeto de cada aplicaci´on. En el anexo D se detallan las l´ıneas de c´odigo empleadas en cada modelo y lenguaje as´ı como los m´etodos empleados para su obtencion. Aplicacion Roles Funciona UIs Tablas Duracion ASL Uso lidades Vistas (semanas) (LDC) (A1) Reservas 11 204 188 98 15 5.696 reserva de salas (A2) Inventario 2 24 23 40 4 578 inventario TIC (A3) Tabl´on 5 26 22 10 5 768 tabl´on de anuncios (A4) Pr´acticas 1 20 18 20 4 521 pr´acticas en empresa (A5) RelExteriores 1 11 10 16 4 239 relaciones exteriores (A6) InfoPanel 2 13 11 24 6 904 informaci´on en pantallas Tabla 5.1: Lista de aplicaciones desarrolladas Las aplicaciones listadas en la tabla 5.1 muestran caracter´ısticas comunes como roles, aspecto, formularios y datos. Nuestra motivaci´on inicial no era realizar un experimento exhaustivo sobre reutilizaci´on, sino realizar el desarrollo de la forma m´as r´apida posible. Ello nos llev´o a explotar los aspectos comunes entre las aplicaciones para reducir el esfuerzo de desarrollo a trav´es de la reutilizaci´on de componentes de la interfaz de usuario con las t´ecnicas ofrecidas por WAINE. Los nuevos recursos de la interfaz de usuario fueron generalmente desarrollados cuando eran necesarios en cada proyecto, sin un dise˜no espec´ıfico orientado a la reutilizaci´on, o sea, no se desarrollaron recursos para ser reutilizados [73]. Se ha realizado una reutilizaci´on ad-hoc sobre recursos creados previamente. As´ı, el repertorio de recursos disponibles para reutilizar fue mayormente construido con la primera aplicaci´on (obs´ervese que A1 es sustancialmente mayor que A2-A6) y creci´o ligeramente con cada aplicaci´on desarrollada. El primer proyecto (A1) fue desarrollado por un equipo de gran experiencia compuesto por el autor y un profesor ayudante (con una experiencia media de 5 a˜nos). El resto de proyectos (A2-A6) fueron desarrollados por equipos compuestos por un ´unico estudiante de nivel de grado (de baja experiencia) tutorizado por el autor. Cada estudiante desarroll´o una aplicaci´on. Todos los estudiantes mostraron habilidades similares y recibieron una formaci´on de tres d´ıas sobre WAINE para familiarizarse con el proceso de desarrollo, la codificaci´on ASL y las t´ecnicas de reutilizaci´on a trav´es del desarrollo de una aplicaci´on de ejemplo. Todas las t´ecnicas para reutilizaci´on soportadas por WAINE fueron practicadas en las sesiones de entrenamiento. El tutor, guiaba los pasos de desarrollo del 1 al 3 (secci´on 4.1.4: requisitos, Diagrama Entidad-Relaci´on, tabla rol/funcionalidades). Los estudiantes colaboraban en estas etapas, pero su principal responsabilidad era escribir las especificaciones ASL (secci´on 4.1.4: paso 4) para 80 5.2. EXPERIENCIA CUALITATIVA EN LA REUTILIZACI´ ON 81 su proyecto. Los recursos desarrollados en proyectos anteriores eran conocidos por el tutor que realizaba la b´usqueda, selecci´on y evaluaci´on ad-hoc de los recursos a reutilizar. Los estudiantes reutilizaban estos componentes siguiendo indicaciones del tutor y realizaban reutilizaci´on interna sobre recursos que ellos mismos hab´ıan desarrollado previamente. Cada estudiante era supervisado por el tutor un par de veces por semana. Las aplicaciones se alojan en servidores del Centro de Proceso de Datos de la Escuela T´ecnica Superior de Ingenier´ıa, cuyo personal se encarga de su administraci´on y mantenimiento. La infraestructura sobre la que se ejecutan las aplicaciones se detalla en el Diagrama de Despliegue que aparece en la figura 5.3. Todas las aplicaciones est´an instaladas sobre dos servidores: un servidor de aplicaciones y uno de base de datos. El servidor de aplicaciones ejecuta Apache 2.2.3, PHP 5.2.0 y el run-time de WAINE versi´on 0.2.2. Las instancias de cada aplicaci´on est´an vinculadas a este Run-time y el Repositorio de Configuraciones de cada una de ellas reside en el sistema de ficheros de este servidor. Por su parte, el servidor de base de datos ejecuta PostgreSQL 8.1.11. Este Sistema de Gesti´on de Base de Datos, soporta la Base de Datos y el Repositorio de la IU de cada aplicaci´on. Cliente Navegador web apl1.RIU apl1.BD aplN.RIU aplN.BD apl1.RC aplN.RC Sistema ficheros : Instancia apl1 Instancia aplN WAINE 0.2.2 : Sv. Base de datos : Sv. Aplicaciones PostgreSQL 8.1.11 PHP 5.2.0 Apache 2.2.3 Figura 5.3: Infraestructura para las aplicaciones desarrolladas 5.2. Experiencia cualitativa en la reutilizaci´on En la secci´on 4.2 se han descrito las t´ecnicas de reutilizaci´on implementadas en WAINE tanto para especificaciones como para repositorios. En esta secci´on se describe nuestra experiencia no cuantitativa con cada t´ecnica en este caso de estudio particular y de la que extraeremos algunas ideas que pueden ser aplicables a otros MB-UIDEs. 5.2.1. Subespecificaci´on y adaptaci´on (S,A) Estas t´ecnicas han sido claves en la reutilizaci´on de contenedores y formularios, adem´as, el proyecto A1 las ha usado de forma intensiva debido a su gran tama˜no y al hecho de que ha sido el primero en ser desarrollado. 81 82CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID La reusabilidad de los recursos con estas t´ecnicas composicionales depende de su estructura y complejidad. Por ejemplo, no se han podido subespecificar fragmentos del Modelo de Di´alogo debido a su estructura sint´actica jer´arquica y monol´ıtica (ver figura 4.13). ´ Esta s´olo permite la reutilizaci´on del conjunto completo de men´us asociados a un rol espec´ıfico y por su definici´on en WAINE, roles distintos no pueden tener el mismo conjunto de funcionalidades. Por el contrario, recursos de grano fino como formularios y contenedores (etiquetas form ycontainer) han sido frecuentemente reutilizados en el Modelo de Presentaci´on (p.ej. un contenedor o formulario referenciado desde otros contenedores) as´ı como desde el Modelo de Di´alogo (p.ej. una unidad de interacci´on identificada por su contenedor de m´as alto nivel referenciada desde varias opciones de distintos men´us). La adaptaci´on ha jugado un papel fundamental para incrementar la reusabilidad de los formularios definidos en el Modelo de Presentaci´on, haciendo la reutilizaci´on m´as atractiva. Un conjunto de formularios similares pueden ser derivados de uno original sobreescribiendo/modificando sus propiedades. Por ejemplo, en Reservas (A1), una definici´on de formulario (form asignatura con 10 campos para manejar la informaci´on de las asignaturas) fue referenciada 12 veces desde diferentes contenedores usando par´ametros para obtener distintas variantes. Hay que tener en cuenta que el n´umero de par´ametros usados para la adaptaci´on de un formulario puede ser considerado como un factor de coste cuando se utiliza esta t´ecnica. En nuestro caso de estudio nunca se ha dado el caso en el que reutilizar y adaptar un formulario tuviera un coste de implementaci´on mayor que el de escribir un nuevo formulario. <container id="cparam_sample" type="form"> </container> <param name="formid" value="fpeople"/> <param name="form_type" value="table"/> <param name="fields_readonly" value="1:3"/> <param name="fields_remove" value="4"/> Figura 5.4: Ejemplo de reutilizaci´on por adaptaci´on En la implementaci´on de nuevos widgets tambi´en se ha empleado la adaptaci´on (ver secci´on 4.2). Del total de cinco widgets definidos en esta experiencia, dos han empleado la adaptaci´on. WAINE es un MB-UIDE, centrado en los modelos de Dominio,Di´alogo yPresentaci´on, pero otros sistemas que usen modelos distintos tambi´en podr´ıan beneficiarse de estas t´ecnicas para flexibilizar la reutilizaci´on de elementos de las especificaciones. Las caracter´ısticas de los modelos y lenguajes empleados determinar´an la aplicabilidad de las t´ecnicas propuestas, as´ı como su potencial para reutilizar. La expresividad y sintaxis de cada lenguaje, as´ı como la sem´antica de cada Modelo de la IU , puede tener 82 5.2. EXPERIENCIA CUALITATIVA EN LA REUTILIZACI´ ON 83 un impacto decisivo para determinar qu´e recursos de la interfaz de usuario pueden ser reutilizados y en qu´e grado. Por lo tanto, a la hora de dise˜nar un Lenguaje de Descripci´on de la IU es importante tener en cuenta estos aspectos, analizando qu´e elementos se desea reutilizar y d´andoles las caracter´ısticas necesarias para que su reutilizaci´on sea posible. 5.2.2. Herencia (H) Como se coment´o en la secci´on 4.2.2, entendiendo el t´ermino de forma flexible, entre usuarios y grupos en ASL existe una relaci´on de herencia. Los atributos del usuario (clase hija) ocultan o sobrescriben los atributos del grupo (clase padre) y los atributos del grupo quedan definidos para el usuario si ´este no los han definido (ver figura 4.16). En esta relaci´on caracter´ıstica se reutilizan no ya las clases propias del modelo2, sino los atributos definidos por cada grupo, que no es necesario volver a asignar para cada usuario que pertenece al mismo. Por esta raz´on, la reutilizaci´on que haya existido por esta relaci´on particular no ha sido tenida en cuenta en el resto del documento. Sin embargo, en la implementaci´on de algunos widgets empleados por el conjunto de aplicaciones se ha empleado la herencia. De los cinco widgets definidos en el caso de estudio, tres han utilizado la herencia como mecanismo de reutilizaci´on. Aunque ASL no utiliza la herencia en la definici´on de elementos de los Modelos de la IU , en la secci´on 2.2.1 hemos visto que otros lenguajes si han empleado este m´etodo con ´exito (p.ej XICL [18, 19]). La herencia debe ser considerada como m´etodo de reutilizaci´on en el dise˜no de nuevos Lenguajes de Descripci´on de la IU . 5.2.3. XInclude y Bibliotecas (I,B) En nuestro caso de estudio, este m´etodo est´andar de inclusi´on ha sido empleado para modularizar documentos ASL de gran tama˜no mejorando su claridad y mantenimiento. Sin embargo, si excluimos los elementos tomados de la ”biblioteca est´andar”, XInclude no se ha usado para reutilizar componentes de la interfaz de usuario entre las distintas aplicaciones desarrolladas. Esto se debe a que la infraestructura com´un (ver figura 5.3) sobre la que se han implantado los distintos proyectos hac´ıa m´as interesantes los m´etodos de centralizaci´on y federaci´on para la reutilizaci´on horizontal. Como ASL, la mayor´ıa de Lenguajes de Descripci´on de la IU est´an basados en XML [45] independientemente de su nivel de abstracci´on, por lo tanto son apropiados para usar este mecanismo est´andar con cambios m´ınimos. Sin embargo, en la secci´on 2.2.1 hemos visto que varios lenguajes como XUL [50] o XICL [18, 19] definen sus propias etiquetas para la inclusi´on de documentos externos (xul-overlay eimport respectivamente). Desde nuestro punto de vista, no est´a justificado el empleo de etiquetas espec´ıficas, al existir un est´andar asentado del W3C como es XInclude. Por lo tanto se recomienda la aplicaci´on de XInclude en los Lenguajes de Descripci´on de la IU basados en XML como mecanismo de inclusi´on. 2En la secci´on 3.1.1.4 la herencia se presenta como mecanismo de reutilizaci´on en la definici´on de nuevos elementos de los Modelos de la IU . 83 84CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID Por otra parte, es necesario tener en cuenta que muchos Lenguajes de Descripci´on de la IU , s´olo soportan la definicion de algunos modelos [45, 115] (UIML, XUL, etc.). El desarrollo de un componente de la interfaz de usuario puede conllevar el uso de modelos no incluidos en el lenguaje de partida, lo que implicar´ıa el empleo de varios Lenguajes de Descripci´on de la IU para realizar el modelado del componente. En este caso, en el que el recurso reutilizable est´a constituido por elementos de varios modelos y especificados en distintos lenguajes (que incluso pueden no seguir el est´andar XML) XInclude no es una buena opci´on para la reutilizaci´on y distribuci´on del componente de la interfaz de usuario. Los paquetes pueden ser una mejor elecci´on en este caso. Recordemos que XInclude presenta ciertas limitaciones: (a) la t´ecnica est´a restringida a especificaciones basadas en XML, (b) es aconsejable el uso de herramientas de validaci´on de fragmentos reutilizables ya que XInclude no trata el proceso de validaci´on y (c) las modificaciones en los componentes de la interfaz de usuario reutilizados no se har´an presentes en aquellas especificaciones que han hecho uso de ellos. Estas restricciones deben ser tenidas en cuenta a la hora de implementar este m´etodo en nuestros sistemas. Por ´ultimo, se ha de mencionar que algunos de los elementos de la ’biblioteca est´andar’ de WAINE s´ı han sido reutilizados en nuestro escenario. Por ejemplo, interfaces de usuario presentes en cada aplicaci´on (como el usado para cambio de contrase˜na) han sido incluidas en todos los proyectos. Esto conlleva que el recurso ha sido fusionado en cada proyecto y por lo tanto aparece repetido en el Repositorio de la IU de cada aplicaci´on. Aunque no ha sido necesario realizar un mantenimiento de estos componentes, pensamos que no ha sido la mejor forma de reutilizarlos en el escenario planteado. 5.2.4. Paquetes (P) En el MB-UID se pueden emplear varios Lenguajes de Descripci´on de la IU al mismo nivel de abstracci´on o en diferentes niveles: El empleo de paquetes con lenguajes que pertenecen al mismo nivel de abstracci´on permite la reutilizaci´on y distribuci´on de Recursos Multi-modelo como se ha comentado con anterioridad. En WAINE, los paquetes se emplean con los productos finales del proceso de desarrollo: fragmentos de ASL, de SQL o de otros elementos residentes en el Repositorio de Configuraciones. Pero los paquetes tambi´en podr´ıan emplearse durante el proceso de desarrollo con lenguajes en diferentes niveles de abstracci´on, as´ı un paquete permitir´ıa realizar un snapshot de un instante determinado en el proceso de desarrollo. Los paquetes no han sido empleados en nuestro caso de estudio. Los repositorios compartidos han resultado m´as c´omodos para la reutilizaci´on Inter-proyecto en este entorno. Sin embargo, de algunos de los proyectos desarrollados se han extra´ıdo ciertos componentes complejos de la interfaz de usuario que han sido empaquetados para su uso futuro. En los paquetes se ha incluido informaci´on adicional sobre el componente reutilizable: documentaci´on, diagramas, ejemplos, etc. Esta informaci´on permite a los desarro- 84 5.2. EXPERIENCIA CUALITATIVA EN LA REUTILIZACI´ ON 85 lladores reutilizar el recurso de forma ´optima y ayuda a realizar asset-based development [57] en el desarrollo de la interfaz de usuario. 5.2.5. Repositorios compartidos (C,F) Los repositorios compartidos han sido la t´ecnica m´as frecuentemente usada para la reutilizaci´on horizontal en nuestro caso de estudio. Se ha compartido no s´olo el Modelo de Presentaci´on (en el Repositorio de la IU ) y los datos manejados por los formularios (Base de Datos), sino tambi´en algunos de los elementos definidos en el Repositorio de Configuraciones (presentaci´on concreta, widgets, etc.) y cierta informaci´on relativa a los usuarios. En el Modelo de Presentaci´on, las unidades de interacci´on y los formularios usados frecuentemente (para la selecci´on de asignaturas, salas, departamentos, etc.) se han almacenado en repositorios centrales y se han compartido entre varias aplicaciones como se muestra muestra en la figura 5.5. Aplicacion Board Aplicacion Reservas Form centralizado Figura 5.5: Ejemplo de formulario compartido por dos aplicaciones Del mismo modo que en las Bases de Datos se extraen entidades u objetos comunes a distintos sistemas y se centralizan, en nuestro conjunto de aplicaciones se han extra´ıdo los componentes del Modelo de Presentaci´on empleados para manipular esos objetos comunes del Modelo de Dominio y tambi´en han sido centralizados. Las ventajas de la centralizaci´on (secci´on 3.1.3) se aplican de este modo tanto al Modelo de Dominio como al Modelo de Presentaci´on. Las modificaciones en los elementos del Modelo de Dominio centralizado que han repercutido en los elementos del Modelo de Presentaci´on 85 86CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID que manipulan esos objetos modificados, s´olo han requerido la actualizaci´on de los componentes del repositorio centralizado encargados de su manipulaci´on en lugar de tener que actualizar cada una de las aplicaciones afectadas. A este modelo en el que tanto los elementos del Modelo de Dominio como los elementos del Modelo de Presentaci´on que los manipulan est´an centralizados, lo hemos denominado PC-DOC (Presentaci´on centralizada - Dominio centralizado). En la figura 5.6, tres sistemas distintos, cada uno con sus Repositorios de la IU ”locales” (RIU AP.1, RIU AP.2, RIU AP.3), utilizan un formulario com´un almacenado en un repositorio centralizado (RC-MP). Esta unidad de interacci´on presenta para todos los sistemas los mismos elementos del Modelo de Dominio, ya que el Modelo de Dominio tambi´en est´a centralizado (RC-DOM). RC−DOM RC−MP RIU AP.3RIU AP.2RIU AP.1 field 2 field 1 field 3 option 2 option 1 option N Menu 1 Menu 2 option N option 2 option 1 Menu 1 Menu 2 Menu 1 Menu 2 option 2 option 1 Figura 5.6: Presentaci´on centralizada - Dominio centralizado Tambi´en es posible, que un mismo formulario residente en un repositorio centralizado, sea empleado para manejar elementos de distintos Modelos de Dominio que tienen una estructura similar pero que pueden residir en repositorios distintos. As´ı, un mismo formulario puede servir para manipular objetos del tipo ”persona” que poseen una misma estructura pero que pertenecen a sistemas distintos. Incluso en el caso en el que los objetos del Modelo de Dominio no tuvieran exactamente la misma estructura, combinando la centralizaci´on con la adaptaci´on, los formularios pueden ser aplicados f´acilmente a esa estructura distinta. A este modelo lo hemos denominado PC-DOD (Presentaci´on centralizada - Dominio distribuido). En la figura 5.7, se puede apreciar c´omo dos sistemas independientes, cada uno con su Repositorio de la IU particular (RIU AP.1, RIU AP.2), utilizan un mismo formula- 86 5.2. EXPERIENCIA CUALITATIVA EN LA REUTILIZACI´ ON 87 rio almacenado en un repositorio compartido (RC-MP). Sin embargo, en este caso, el formulario accede a Modelos de Dominio distintos en funci´on del sistema que lo invoca (el sistema 1 R-DOM1 y sistema 2 R-DOM2), y por lo tanto los elementos del Modelo de Dominio manejados desde los dos sistemas no son los mismos. R−DOM 2 RC−MP R−DOM 1 RIU AP.2RIU AP.1 field 2 field 1 field 3 Menu 1 Menu 2 option N option 2 option 1 option 2 option 1 option N Menu 1 Menu 2 option 2 option 1 Figura 5.7: Presentaci´on centralizada - Dominio distribuido Otra posibilidad ha sido la reutilizaci´on elementos del Modelo de Presentaci´on a trav´es de la federaci´on de repositorios. Algunas interfaces de usuario empleadas por una aplicaci´on son mantenidas y residen en repositorios de otras aplicaciones. Por ejemplo, Pr´acticas (A4), mostraba unidades de interacci´on sobre destinos (p.ej. regiones, provincias, etc.) gestionadas por la aplicaci´on RelExteriores (A5) as´ı como interfaces relativos a profesores y departamentos que eran administrados directamente por Reservas (A1). As´ı, el Modelo de Presentaci´on se ha compuesto desde sistemas externos como se muestra en la figura 5.8. En esta figura podemos apreciar c´omo en el Modelo de Presentaci´on de un nuevo sistema, cuyo Repositorio de la IU principal es RIU AP.1, se est´an utilizando formularios que residen en otros repositorios (R-MP 1 y R-MP 2). Sin embargo, esta t´ecnica combinada con la estructura del Modelo de Presentaci´on de WAINE se puede llevar hasta el extremo, de manera que una unidad de interacci´on se cree por composici´on de componentes de sistemas externos, es decir, podemos crear una ”unidad de interacci´on federada” compuesta por formularios y/o contenedores de otras interfaces de usuario. Naturalmente, para que esto se pueda llevar a la pr´actica, el sistema empleado debe permitirnos definir una unidad de interacci´on a ese nivel de descomposici´on jer´arquica [20] (ver secci´on 4.1.1). Esta t´ecnica podr´ıa catalogarse, 87 88CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID RIU AP.1 R−DOM 1 R−MP 2 R−DOM 2 R−MP 1 Menu 1 Menu 2 option N option 2 option 1 option 2 option 1 option N field 2 field 1 field 3 fld 2fld 1 field 1 Figura 5.8: Modelo de presentaci´on federado dentro del ´ambito de la UI Integration [17] 3como un tipo o forma de mash-up. En la figura 5.9, se puede apreciar c´omo una unidad de interacci´on se construye por integraci´on de formularios que residen en distintos repositorios (RIU AP.1, R-MP 1 y R-MP 2). Cada uno de estos fragmentos, puede acceder a un repositorio del Modelo de Dominio distinto (en el ejemplo R-DOM 1 y R-DOM 2). En este caso los elementos del Modelo de Presentaci´on y los del Modelo de Dominio a los que se accede, provienen de varios repositorios federados, pero no tendr´ıa que ser forzosamente as´ı, pudiendo emplear los distintos elementos del Modelo de Presentaci´on federado un mismo repositorio de Modelo de Dominio. La centralizaci´on de las definiciones de la presentaci´on concreta en el Repositorio de Configuraciones nos ha permitido conseguir una presentaci´on consistente de la interfaz de usuario tan importante en empresas y organizaciones donde los sistemas deben ofrecer una imagen corporativa. Al residir la presentaci´on concreta en el Repositorio de Configuraciones centralizado, las modificaciones realizadas sobre ella han sido inmediatas y transversales a todos los sistemas desarrollados. La federaci´on se ha aplicado tambi´en de forma espor´adica sobre algunos elementos residentes en el Repositorio de Configuraciones. Por ´ultimo, la informaci´on relativa a la autenticaci´on de los usuarios (contrase˜na en este caso particular), ha sido almacenada en un repositorio centralizado (directorio 3La integraci´on de la interfaz de usuario (UI Integration) es una disciplina que trata la problem´atica relativa a la integraci´on de componentes, cuando se combina su presentaci´on m´as que la l´ogica de negocio o los datos de los mismos. 88 5.2. EXPERIENCIA CUALITATIVA EN LA REUTILIZACI´ ON 89 RIU AP.1 R−MP 2 R−DOM 1 R−DOM 2 R−MP 1 fld 2fld 1 field 2 field 1 field 1 Menu 1 Menu 2 option 2 option 1 Figura 5.9: Unidad de interacci´on federada X.500 accedido mediante LDAP) con el objetivo de implementar un sistema sencillo de Single Sign-On. Asimismo, otros datos relativos al usuario como su nombre completo y su informaci´on de contacto (tel´efono, direcci´on, etc.) residen en el mencionado directorio. Con esta configuraci´on, podr´ıamos decir que el Modelo de Usuario de cada aplicaci´on ha sido construido mediante la uni´on de su Repositorio de la IU local y la informaci´on contenida en el directorio X.500. En este caso ser´ıa una centralizaci´on a nivel de atributos o propiedades. El uso de directorios es habitual en las organizaciones ya que simplifican la gesti´on de la informaci´on relativa a los usuarios. Tambi´en permiten emplear una ´unica clave para acceder a los sistemas corporativos (evitando que los usuarios tengan que recordar una clave por cada aplicaci´on) y garantizan que los usuarios no tengan acceso a ninguna aplicaci´on una vez que estos causan baja (bloqueando su informaci´on o inutilizando su clave en el directorio). La centralizaci´on total del Modelo de Usuario, cuando fuera posible, podr´ıa tener implicaciones interesantes sobre la administraci´on de identidades y permitir´ıa mantener perfiles homog´eneos de los usuarios en todo el parque de aplicaciones. Hemos de destacar que la centralizaci´on del Modelo de Di´alogo podr´ıa permitir que la estructura jer´arquica completa de determinadas actividades, o bien determinados sub´arboles de ´estas, fueran compartidos entre un conjunto de aplicaciones (siempre que el lenguaje lo permita). Esto puede resultar interesante en grandes organizaciones, ya que los cambios en los di´alogos centralizados (asociados a los workflows de la organizaci´on) ser´ıan inmediatos para los sistemas que hacen uso de ellos, asegur´andose de este 89 96CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID Para observar este aspecto usaremos la m´etrica nivel de reutilizaci´on, definida como la relaci´on entre el n´umero de objetos reutilizados en un sistema frente al n´umero total de objetos empleados en el mismo, pero observando el origen de esos objetos. La m´etrica tiene en cuenta que un sistema est´a compuesto por elementos a distintos niveles de abstracci´on. Por ejemplo, un programa escrito en lenguaje C est´a compuesto por m´odulos (archivos .c) que contienen funciones y funciones que contienen l´ıneas de c´odigo, por lo tanto, el nivel de reutilizaci´on de un sistema codificado en C puede ser expresado en t´erminos de m´odulos, funciones o l´ıneas de c´odigo [34]. Sean: L = el n´umero total de objetos de bajo nivel en el elemento de alto nivel E = el n´umero total de objetos de bajo nivel de un repositorio externo en el elemento de alto nivel M = el n´umero total de objetos de bajo nivel no provenientes de un repositorio externo usados m´as de una vez Se definen: Nivel de reutilizaci´on externo = E L(5.3) Nivel de reutilizaci´on interno = M L(5.4) Nivel de reutilizaci´on total = Nivel de reutilizaci´on externo+Nivel de reutilizaci´on interno (5.5) Para este an´alisis se considerar´an formularios y contenedores como objetos de bajo nivel y el Modelo de Presentaci´on como elemento de alto nivel. Quedar´an definidos entonces: L = n´umero total de formularios y contenedores en el Modelo de Presentaci´on de una aplicaci´on. E = n´umero total de formularios y contenedores que provienen de un repositorio externo en el Modelo de Presentaci´on de una aplicaci´on. M = n´umero total de formularios y contenedores que no provienen de un repositorio externo y son usados m´as de una vez en el Modelo de Presentaci´on de una aplicaci´on. La tabla 5.6 detalla para cada aplicaci´on: el n´umero de diferentes recursos del Modelo de Presentaci´on (contenedores o formularios) usados (L), el n´umero de elementos que se han reutilizado internamente (i.e. definidos y reutilizados en el mismo proyecto) (M), el n´umero de elementos no definidos por la aplicaci´on pero importados de otras aplicaciones (E), el nivel de reutilizaci´on interna (NR interno), el nivel de reutilizaci´on externa (NR externo) y el nivel de reutilizaci´on total (NR total). 96 5.3. RESULTADOS CUANTITATIVOS DE LA REUTILIZACI ´ ON 97 L M E NR NR NR Aplicaci´on Interno Externo Total (A1) Reservas 350 197 4 56,3 1,1 57,4 (A2) Inventario 54 12 2 22,2 3,7 25,9 (A3) Tabl´on 64 9 14 14,1 21,9 35,9 (A4) Pr´acticas 44 6 19 13,6 43,2 56,8 (A5) RelExteriores 29 4 10 13,8 34,5 48,3 (A6) InfoPanel 58 14 4 24,1 6,9 31,0 Tabla 5.6: Nivel de reutilizaci´on del modelo de presentaci´on de cada aplicaci´on Como pod´ıa esperarse, la tabla 5.6 muestra que la reutilizaci´on interna es claramente dominante en A1 (Reservas) donde se han utilizado de forma intensiva la subespecificaci´on y la adaptaci´on para reutilizar el 56,3 % de sus 350 recursos. Otros proyectos como A4 o A5 se han beneficiado de forma significativa de la reutilizaci´on Inter-proyecto (principalmente de A1). La reutilizaci´on Intra-proyecto tambi´en es dominante en aquellas aplicaciones que est´an menos integradas con el resto como la de avisos en pantalla (A6) o la de inventario (A2). Finalmente, la reutilizaci´on total ha alcanzado rangos entre el 26 % (A2 es una aplicaci´on peque˜na y de reutilizaci´on interna) y el 57 % (A1 reutiliza internamente pero es una aplicaci´on grande, A4 es peque˜na pero reutiliza externamente). Esto confirma los resultados ya apuntados por Mohagheghi et al. [73] respecto a que el ´ambito de la reutilizaci´on en grandes proyectos software tiende a ser interno, mientras que en proyectos peque˜nos puede ser interno o externo. Los resultados tambi´en sugieren que puede obtenerse un alto nivel de reutilizaci´on total a trav´es de la reutilizaci´on externa cuando las interfaces de usuario de aplicaciones peque˜nas (como A4 y A5) tienen un porcentaje elevado de elementos comunes con una aplicaci´on de gran tama˜no o por reutilizaci´on interna como en el caso de A1. Es interesante analizar estos resultados junto con los de la sobrecarga de adaptaci´on presentados anteriormente (ver tabla 5.5). Se puede apreciar que aquellos proyectos en los que la reutilizaci´on es predominantemente interna (A1, A2, A6) tienen una sobrecarga de adaptaci´on menor que all´ı donde la reutilizaci´on es predominantemente externa (A3, A4, A5). Estos resultados indican que adaptar los recursos propios conlleva una menor sobrecarga que adaptar los recursos definidos por otros proyectos. La reutilizaci´on de un elemento no s´olo conlleva el uso de l´ıneas de c´odigo para su reutilizaci´on. Otros factores como el tiempo empleado en buscar, examinar y evaluar los elementos seleccionados para ser reutilizados [54] deben ser tenidos en cuenta. En nuestro caso particular, hemos asumido que esos factores son despreciables, ya que como se indic´o en la secci´on 5.1, el autor ha desarrollado A1 y dise˜nado y tutorizado A2-A6, por lo que los recursos han sido identificados sin mucho esfuerzo. Sin embargo, en un entorno industrial, estos factores deben ser considerados. 97 98CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID 5.3.2.5. Beneficio de la reutilizaci´on El an´alisis coste-beneficio afirma que el beneficio derivado de la reutilizaci´on puede expresarse por la ecuaci´on [39]: R= [Cno reu −Creu]/Cno reu (5.6) Donde Cno reu es el coste de desarrollar una aplicaci´on sin reutilizar recursos y Creu es el coste de desarrollar la aplicaci´on reutilizando recursos. Esta misma f´ormula puede ser aplicada para estimar el ahorro en l´ıneas de c´odigo (RLDC ) debido a la reutilizaci´on. As´ı: RLDC = [LDCno reu −LDCreu]/LDCno reu (5.7) Podemos realizar ingenier´ıa inversa y estimar LDCno reu recalculando cu´antas l´ıneas de c´odigo deber´ıan haberse escrito si no se hubiera realizado la reutilizaci´on. Esto puede hacerse f´acilmente examinando los documentos ASL y actualizando el contador de l´ıneas de c´odigo cada vez que un contenedor o formulario es reutilizado acumulando su tama˜no en l´ıneas de c´odigo y restando las l´ıneas codificadas para su reutilizaci´on, que asumimos como coste de la reutilizaci´on. La tabla 5.7 muestra para cada aplicaci´on el n´umero de l´ıneas codificadas (LDCreuse), las l´ıneas que habr´ıa sido necesario escribir sin reutilizar formularios y contenedores (LDCno reu) y el beneficio en l´ıneas de c´odigo que ha supuesto la reutilizaci´on (RLDC ) seg´un se define en la ecuaci´on 5.7. Como conocemos el tiempo que se ha empleado en el desarrollo de cada proyecto, se puede estimar cu´al hubiera sido su duraci´on si no hubiera existido reutilizaci´on. LDCreu LDCno reu RLDC T. codificaci´on T. codificaci´on ASL ASL (semanas) estimado SIN reu- Aplicaci´on tilizaci´on (semanas) (A1) Reservas 5.335 22.225 0,76 10,5 43,7 (A2) Inventario 532 812 0,34 2,5 3,8 (A3) Tabl´on 689 1.636 0,58 2,8 6,6 (A4) Pr´acticas 483 1250 0,61 2,1 5,4 (A5) RelExteriores 219 525 0,58 2,7 6,5 (A6) InfoPanel 865 1.463 0,41 4,3 7,3 Total 8.123 27.911 0,71 24,9 73,4 Media 1.354 4.652 0,55 4,1 12,2 Tabla 5.7: Beneficio de la reutilizaci´on por aplicaci´on En la tabla 5.7 podemos observar que reutilizar recursos de la interfaz de usuario ha supuesto un ahorro de codificaci´on en el Modelo de Presentaci´on del 55 % en media, alcanzando un pico del 76 % para la mayor aplicaci´on: Reservas. Si se tienen en cuenta los valores agrupados para todas las aplicaciones (fila total), se ha alcanzado un beneficio del 71 % en t´erminos de l´ıneas de c´odigo. Podemos estimar el tiempo de desarrollo si 98 5.4. CONCLUSIONES 99 no hubiera existido reutilizaci´on (columna 6) en funci´on del tiempo real de codificaci´on de ASL (columna 5). En este caso la reducci´on hubiera sido casi de un 66 %. 5.3.2.6. Otras consideraciones Los beneficios de la reutilizaci´on del software incluyen mejoras en la productividad, la calidad y el mantenimiento como se ha destacado en numerosos estudios [73]. La tabla 5.7 s´olo trata la productividad. Durante los cuatro ´ultimos a˜nos manteniendo las seis aplicaciones, se han realizado cinco modificaciones sobre formularios o contenedores existentes, cuatro de ellas afectaron a recursos que eran reutilizados internamente y que tambi´en se beneficiaron de la actualizaci´on; doce nuevos recursos fueron a˜nadidos de los cuales un tercio fueron construidos reutilizando recursos existentes. En el anexo F se muestra la relaci´on de actuaciones realizadas sobre las aplicaciones del caso de estudio. 5.4. Conclusiones En este cap´ıtulo se ha presentado un caso de estudio en el que WAINE se ha empleado para desarrollar varias aplicaciones que tienen ciertos elementos en com´un. Las t´ecnicas de reutilizaci´on soportadas por el MB-UIDE han sido puestas en pr´actica durante la construcci´on de las aplicaciones para posterioremente valorar las consecuencias cualitativas y cuantitativas de su uso. Para cada t´ecnica aplicada en nuestro caso de estudio (subespecificaci´on, adaptaci´on, herencia, inclusi´on, centralizaci´on y federaci´on) se ha analizado a qu´e elementos de los Modelos de la IU se han aplicado y con qu´e objetivo. Tambi´en se ha puesto de manifiesto cu´al ha sido la nuestra experiencia en el empleo de cada t´ecnica de reutilizaci´on. Destacamos los siguientes aspectos: La adaptaci´on ha sido una t´ecnica muy interesante en el Modelo de Presentaci´on para reutilizar formularios. Esta t´ecnica ha permitido que formularios similares hayan sido obtenidos ”moldeando” uno original por medio de par´ametros. Las t´ecnicas de reutilizaci´on en repositorios (centralizaci´on y federaci´on) han desplazado casi totalmente a otras t´ecnicas de reutilizaci´on Inter-proyecto (inclusi´on, bibliotecas y paquetes). La centralizaci´on y la federaci´on, junto a las posibilidades constructivas que ofrece el Modelo de Presentaci´on en WAINE han posibilitado una reutilizaci´on rica y flexible de este modelo. Centralizaci´on de la Presentaci´on, centralizaci´on de la Presentaci´on y del Modelo de Dominio,Modelo de Presentaci´on federado y unidades de interacci´on federadas, han sido distitas formas de reutilizaci´on del Modelo de Presentaci´on en el caso de estudio. Por ´ultimo se ha realizado un an´alisis cuantitativo de la reutilizaci´on. Se han obtenido resultados interesantes. Adem´as del alto grado de reutilizaci´on general (entorno 99 100CAP´ ITULO 5. EXPERIENCIA DE REUTILIZACI´ ON EN EL MB-UID al 46,2 % de todos los elementos definidos) y la reutilizaci´on casi total de aspectos de presentaci´on concreta (que ha dotado a las aplicaciones de un aspecto corporativo), el Modelo de Presentaci´on ha alcanzado una reutilizaci´on media del 44,3 %, alcanzando picos del 56,9 % (aplicaci´on A1). Adem´as, queremos destacar los siguientes resultados: El nivel de reutilizaci´on total ha sido muy elevado en algunos casos (por encima del 45 % en A1, A4 y A5). Estos niveles pueden alcanzarse mediante la reutilizaci´on interna en las aplicaciones de gran tama˜no (A1) o por reutilizaci´on externa en aplicaciones m´as peque˜nas (A4, A5) pero que tienen muchos elementos en com´un con una gran aplicaci´on (A1). Aquellos proyectos en los que la reutilizaci´on es predominantemente interna tienen menor sobrecarga de adaptaci´on que aquellos en los que la reutilizaci´on es mayoritariamente externa. Adaptar recursos propios es menos costoso que adaptar recursos externos. Adem´as, la sobrecarga de adapataci´on media siempre ha sido menor que el tama˜no medio del recurso reutilizado. El beneficio obtenido por el empleo de la reutilizaci´on en relaci´on al ahorro en el tama˜no de las especificaciones ronda el 71 % y se estima que el tiempo de desarrollo de los proyectos se ha reducido en un 66 %. 100 Cap´ıtulo 6 Conclusiones y trabajos futuros En esta tesis se han realizado diversas propuestas relacionadas con la reutilizaci´on de Modelos de la IU en el MB-UID. Para comenzar este trabajo se ha expuesto una panor´amica sobre el MB-UID profundizando en las distintas propuestas sobre reutilizaci´on en este ´ambito. A modo de resumen se ha elaborado una clasificaci´on de las propuestas existentes identificando el tipo de t´ecnica de reutilizaci´on soportada de acuerdo con los tipos de reutilizaci´on identificados por Mohagheghi et al. [73]. A continuaci´on, se han presentado una serie de t´ecnicas para la reutilizaci´on en el MB-UID. Algunas de ellas son generalizaciones de las presentadas en el estado del arte, otras han sido aplicadas en distintos ´ambitos de la inform´atica pero nunca en este tipo de entornos [22]. Sin embargo, nunca se hab´ıa realizado un compendio de t´ecnicas de reutilizaci´on aplicables al MB-UID, ni un an´alisis de las consecuencias de su aplicaci´on. Para validar las t´ecnicas propuestas, se hac´ıa necesario implementarlas sobre un MB-UID real y verificar su utilidad. En esta tesis hemos presentado WAINE [20, 21], un MB-UIDE sobre el que se han implementado diversas t´ecnicas para la reutilizaci´on de elementos de los Modelos de la IU . WAINE dispone de su propio Lenguaje de Descripci´on de la IU (ASL) y tiene entre sus objetivos principales simplificar y acelerar el desarrollo de la interfaz de usuario a estudiantes y programadores sin experiencia. Por ´ultimo, WAINE ha sido empleado en desarrollo de varias aplicaciones que tienen ciertos elementos en com´un. Las t´ecnicas de reutilizaci´on implementadas en el MB-UIDE se han puesto en pr´actica durante la construcci´on de las aplicaciones y posterioremente se han valorado las consecuencias cualitativas y cuantitativas de su uso. Son destacables los siguientes resultados: Las t´ecnicas de reutilizaci´on propuestas junto a las posibilidades constructivas del Modelo de Presentaci´on de WAINE han aportado una enorme flexibilidad a la implementaci´on de la interfaz de usuario. La cantidad de reutilizaci´on total en este caso de estudio ha alcanzado un 46,2 %. Se ha conseguido un ahorro del 71 % en LDC y se estima que la reducci´on del tiempo de desarrollo ha alcanzado el 66 %. Podemos concluir que la reutilizaci´on de los objetos del modelado de la interfaz de usuario con WAINE ha aportado resultados excelentes en nuestro caso de estudio. 101 102 CAP´ ITULO 6. CONCLUSIONES Y TRABAJOS FUTUROS 6.1. Lecciones aprendidas Aunque los resultados obtenidos est´an influenciados por el contexto del caso de estudio (i.e. proyectos, proceso de reutilizaci´on y MB-UIDE) algunas ideas generales pueden ser empleadas por la comunidad del MB-UID a la hora de dise˜nar nuevos sistemas o modelos con caracter´ısticas de reusabilidad reforzadas. 6.1.1. Sobre la reusabilidad de los modelos y la subespecicaci´on Los Modelos de la IU definen elementos (asociados a etiquetas XML de alto nivel en los Lenguajes de Descripci´on de la IU ) que pueden ser potencialmente reutilizados a trav´es de la subespecificaci´on. Esos elementos pueden ser referenciados desde otros objetos que pertenecen al mismo modelo (referencia intra-modelo) o desde objetos que pertenecen a otros modelos relacionados (referencia inter-modelo). De acuerdo a nuestra experiencia, la subespecificaci´on intra-modelo mejora significativamente la reusabilidad de un modelo, especialmente si los recursos tambi´en pueden ser adaptados. Para profundizar en este asunto, estudiaremos el Modelo de Di´alogo de WAINE y analizaremos brevemente las consecuencias de modificar la estructura de sus recursos reutilizables. main1 caption2 caption2 main2 caption1 UserGroup1 UserGroup2 UserGroup3UserGroup1 UserGroup2 UserGroup3 option caption1 menu option main2 menu option (a) Menos granular (monolitico) (b) Mas granular (menos monolitico) Recurso A Recurso B Recurso C Recurso A Recurso B Sub−componentes (partes) Sub−componentes (partes) main1 menu Figura 6.1: Fragmentaci´on en un modelo de la interfaz de usuario La figura 6.1(a) ilustra la situaci´on actual del Modelo de Di´alogo en WAINE. Permite definir un ´unico elemento monol´ıtico (i.e. una ´unica etiqueta de alto nivel que incluye una definici´on anidada de sus componentes, ver figura 4.13) que s´olo puede ser referenciado desde el Modelo de Usuario. En la figura, una diferencia en s´olo una caracter´ıstica del elemento <main>(el atributo caption) fuerza a especificar dos recursos completos. Sin embargo, si los recursos del modelo no fueran monol´ıticos, sino compuestos por partes referenciables como aparece en la figura 6.1(b), podr´ıa realizarse reutilizaci´on intra-modelo. Desde luego, ello requiere cambios en la sintaxis del lenguaje. Por ejemplo, para hacer posible el caso (b), ASL deber´ıa definir <main>y<menu> como etiquetas de alto nivel y permitir que estas ´ultimas sean referenciadas por las primeras, de forma an´aloga a como se hace con contenedores y formularios. La reutilizaci´on intra-modelo, junto con la adaptaci´on han sido clave en la alta reusabilidad del 102 6.1. LECCIONES APRENDIDAS 103 Modelo de Presentaci´on. Se puede argumentar que una alta fragmentaci´on (p.ej. tres niveles de partes referenciadas en el ejemplo previo, main →menu →option) tambi´en complica el proceso de reutilizaci´on y a˜nade sobrecarga al m´etodo. El coste de reutilizar est´a tambi´en influenciado por factores como el tiempo dedicado a buscar, revisar y evaluar los elementos seleccionados para ser reutilizados [54] no medidos en nuestro caso particular. Sin embargo, en entornos industriales con grandes proyectos, esos factores deben ser tenidos en cuenta. Por lo tanto, es necesario encontrar un balance entre la fragmentaci´on del modelo y los costes asociados al proceso de reutilizaci´on. 6.1.2. Sobre el tama˜no y adaptabilidad de los recursos De forma general, podr´ıamos decir que cuanto mayor es un recurso, m´as beneficiosa es su reutilizaci´on. Sin embargo, los grandes recursos de grano grueso son menos reutilizables si no son adaptables. La adaptaci´on incrementa notablemente la reusabilidad de cualquier recurso de acuerdo a nuestra experiencia, pero requiere que los recursos sean parametrizados y conocer su estructura. Los resultados muestran que la mayor´ıa de los formularios reutilizados han sido adaptados en alg´un grado. Por el contrario, cuanto m´as peque˜no es un recurso menos beneficiosa es su reutilizaci´on. En general, un modelo menos fragmentado tiende a usar recursos mayores y viceversa. As´ı, podemos concluir que existe una compensaci´on entre el nivel de composici´on de un Modelo de la IU , el tama˜no de sus recursos y el beneficio de reutilizarlos. 6.1.3. Sobre las t´ecnicas empleadas Diferentes t´ecnicas se aplican a recursos de diferente naturaleza: XInclude permite reutilizar fragmentos de XML de cualquier tipo (incluso una l´ınea aislada); la subespecificaci´on requiere reutilizar un recurso de la interfaz de usuario bien formado; los repositorios permiten la reutilizaci´on de cualquier elemento (p.ej. ficheros, tablas de una Base de Datos, etc.). Ello ofrece flexibilidad en cuanto a lo que se puede considerar un recurso reutilizable de la interfaz de usuario. XInclude es un buen mecanismo para modularizar grandes especificaciones. Tambi´en es recomendable si el proceso est´a basado en bibliotecas de especificaciones de modelos. Sin embargo, si un recurso es modificado, aquellas especificaciones que lo incluyeron deben ser actualizadas tambi´en (problema de la fusi´on). Esto que es un problema com´un con otros entornos (p.ej. lenguajes de programaci´on) tiene mayor relevancia en el ´ambito del MB-UID, ya que si la inclusi´on se hace en modelos de muy alto nivel (seg´un el Framework de referencia Cameleon) las distintas transformaciones (i.e. refinamiento, reflexi´on, etc.) deben volver a realizarse en los niveles inferiores. Las arquitecturas de MB-UIDE basadas en Run-time facilitan la reutilizaci´on externa. En particular, compartir los repositorios e implementar un m´etodo de localizaci´on de objetos transparente al desarrollador en el Run-time nos ha brindado los siguientes beneficios: (a) se elimina el problema de la fusi´on, (b) ofrece flexibilidad sobre qu´e reutilizar y cu´ando (las especificaciones pueden reutilizarse en tiempo de desarrollo, pero los objetos de la interfaz de usuario pueden reutilizarse en tiempo de ejecuci´on), (c) la 103 104 CAP´ ITULO 6. CONCLUSIONES Y TRABAJOS FUTUROS localizaci´on de los recursos es m´as sencilla ya que los desarrolladores no necesitan conocer la ”ruta” completa al objeto que desean reutilizar. Un buen contexto para utilizar esta t´ecnica podr´ıa ser el desarrollo de la interfaz de usuario en l´ıneas de productos software. En relaci´on a la gesti´on de la reutilizaci´on entre aplicaciones, una propuesta centralizada es aconsejable cuando varias aplicaciones tienen muchos elementos en com´un y existe un ´unico dominio de gesti´on. Una propuesta federada es aconsejable cuando una aplicaci´on est´a constituida por elementos distribuidos entre varios dominios de gesti´on (p.ej. por modelo u otro criterio). 6.2. L´ıneas de investigaci´on abiertas Este trabajo ha pretendido ser un primer paso en el campo del an´alisis de la reutilizaci´on en el MB-UID. Consecuentemente existen algunos aspectos que pueden ser tratados en investigaciones futuras. Son destacables los siguientes: Incrementar el conocimiento sobre reutilizaci´on en el contexto del MB-UID a trav´es de: (a) explorar la reusabilidad de modelos clave en este ´ambito como el Modelo de Tareas o el Modelo de Di´alogo; (b) analizar las repercusiones de otras t´ecnicas de reutilizaci´on como las citadas en la tabla 2.4 (O.O., patrones, etc.). Analizar casos industriales donde se realice un proceso de reutilizaci´on sistem´atico y en los que los costes deben ser mejor medidos, evaluando no s´olo la productividad, sino tambi´en la mejora en calidad y mantenimiento. Analizar la reusabilidad de los est´andares del W3C para la IU Abstracta [122] y el Modelo de Tareas [91]. Se espera que estos est´andares tengan un impacto sustancial en la comunidad del MB-UID. Ello afectar´a de manera positiva a la reutilizaci´on, ya que se generar´an m´as recursos comunes a diferentes entornos por: (a) una mayor adopci´on de modelos est´andar en los sistemas futuros; (b) la posibilidad de usar los meta-modelos propuestos y su sintaxis de intercambio para transformar recursos de la interfaz de usuario entre diferentes entornos de desarrollo. 6.3. Publicaciones A continuaci´on se enumeran por orden cronol´ogico las publicaciones del autor que guardan relaci´on con este trabajo: Aportaciones en congresos: 1. WAINE: Automatic generator of web based applications.Third international conference on web information systems and technologies, p´ag. 226–233, marzo de 2007. 104 6.3. PUBLICACIONES 105 En la conferencia internacional WEBIST 2007, se present´o WAINE como un sistema apropiado para el desarrollo r´apido de aplicaciones web. De las caracter´ısticas del MB-UIDE fueron destacadas el bajo nivel de programaci´on necesario, su sistema de seguridad y sus capacidades de personalizaci´on. 2. Un sistema de desarrollo de interfaces web basado en modelos para aplicaciones de gesti´on. IX Congreso Internacional de Interacci´on Persona-Ordenador, p´ag. 313–318, junio de 2008. Durante el congreso internacional INTERACCI´ ON 2008 se present´o WAINE como un MB-UIDE orientado al dominio de las aplicaciones de gesti´on. En la aportaci´on al congreso, se describe el modelado de la interfaz de usuario, los lenguajes empleados, su arquitectura y sus posibilidades de reutilizaci´on. Se describen tambi´en diversas aplicaciones desarrolladas con este sistema (m3m, conferences, dbbibtex, etc.). 3. On the reusability of user interface declarative models.Computer- Aided Design of User Interfaces VI, p´ag. 313–318, LNCS, Springer Londres, 2009. Esta aportaci´on analiza la aplicaci´on de dos t´ecnicas bien conocidas como XInclude y los sistemas de paquetes a la reutilizaci´on de especificaciones en el ´ambito del MB-UID. Art´ıculos en revistas: 1. Reusing UI elements with Model-Based User Interface Development.International Journal of Human-Computer Studies. Aceptado en julio de 2015. Pendiente de publicaci´on. Este art´ıculo presenta el potencial de la reutilizaci´on de elementos de la interfaz de usuario en el contexto del MB-UID y ofrece algunas indicaciones para crear MB-UIDEs con caracter´ısticas de reutilizaci´on mejoradas. El estudio realizado est´a basado en el desarrollo de aplicaciones para la Escuela de Ingenier´ıa de Sevilla con WAINE. Se analiza la experiencia y se discuten los beneficios y limitaciones de varias t´ecnicas de reutilizaci´on. 105 112 BIBLIOGRAF´ IA [64] Krikor Maroukian, Kevin Lano, and Mohammad Yamin. Towards automatic generation of project-based solutions. In Information and Knowledge Management in Complex Systems, pages 123–134. Springer, 2015. [65] Jonathan Marsh, David Orchard, and Daniel Veillard. Xml inclusions (xinclude). W3C, version, 1.1, 2015. [66] C. M¨artin. Software life cycle automation for interactive applications: The ame design environment. Computer-Aided Design of User Interfaces, 1996. [67] Jorge Cl´audio Cordeiro Pires Mascena, Eduardo Santana de Almeida, and S´ılvio Romero de Lemos Meira. A comparative study on software reuse metrics and economic models from a traceability perspective. In Information Reuse and Integration, Conf, 2005. IRI-2005 IEEE International Conference on., pages 72–77. IEEE, 2005. [68] Efrem Mbaki, Jean Vanderdonckt, and Marco Winckler. Model-driven engineering of dialogues for multi-platform graphical user interfaces. UsiXML 2011, page 169. [69] Gerrit Meixner, Ga¨elle Calvary, and J. Vanderdonckt. Introduction to modelbased user interfaces. Technical report, MBUI working gropup, 5 2010. [70] Gerrit Meixner, Fabio Patern`o, and Jean Vanderdonckt. Past, present, and future of model-based user interface development. i-com, 10(3):2–11, 2011. [71] Gerrit Meixner, Marc Seissler, and Kai Breiner. Model-driven useware engineering. In Model-Driven Development of Advanced User Interfaces, pages 1–26. Springer, 2011. [72] Zarko Mijailovic and Dragan Milicev. A retrospective on user interface development technology. Software, IEEE, 30(6):76–83, 2013. [73] Parastoo Mohagheghi and Reidar Conradi. Quality, productivity and economic benefits of software reuse: a review of industrial studies. Empirical Software Engineering, 12(5):471–516, 2007. [74] Pedro J. Molina. A review to model-based user interface development technology. In MBUI, 2004. [75] ´ Alvaro Freitas Moreira. Gera¸c˜ao Autom´atica e Assistida de Interfaces de Usu´ario. PhD thesis, Universidade Federal do Rio Grande do Sul, 2008. [76] Diego Moreira and Marcelo Mrack. Sistemas dinˆamicos baseados em metamodelos. In II Workshop de Computa¸c˜ao e Gest˜ao da Informa¸c˜ao (WCOMPI), Lajeado, 2003. [77] Giulio Mori, Fabio Patern`o, and Carmen Santoro. Tool support for designing nomadic applications. In Proceedings of the 8th International Conference on Intelligent User Interfaces, IUI ’03, pages 141–148, New York, NY, USA, 2003. ACM. 112 BIBLIOGRAF´ IA 113 [78] Giulio Mori, Fabio Paterno, and Carmen Santoro. Design and development of multidevice user interfaces through multiple logical descriptions. Software Engineering, IEEE Transactions on, 30(8):507–520, 2004. [79] Marcelo Mrack, ´ Alvaro Freitas Moreira, and Marcelo Pimienta. Merlin: Interfaces crud em tempo de execu¸c˜ao. [80] K Mukasa and A Reuther. The useware markup language (useml)–development of user-centered interfaces using xml. In Proc. of the 9th IFAC Symposium on Analysis, Design and Evaluation of Human-Machine-Systems, Atlanta, USA, 2004. [81] Brad Myers, Scott E Hudson, and Randy Pausch. Past, present, and future of user interface software tools. ACM Transactions on Computer-Human Interaction (TOCHI), 7(1):3–28, 2000. [82] Brad A. Myers and Mary Beth Rosson. Survey on user interface programming. In Proceedings of the SIGCHI conference on Human factors in computing systems, CHI ’92, pages 195–202. ACM, 1992. [83] Duarte Nuno Jardim Nunes. Object modeling for user-centered development and user interface design: the wisdom approach. PhD thesis, Universidade da Madeira, 2001. [84] E Nwelih and IF Amadin. Modeling software reuse in traditional productivity model. Asian Journal of Information Technology, 7(11):484–488, 2008. [85] Muhittin Oral, Unver Cinar, and Habib Chabchoub. Linking industrial competitiveness and productivity at the firm level. European Journal of Operational Research, 118(2):271–277, 1999. [86] Cristina Palomares, Xavier Franch, and Carme Quer. Requirements reuse and patterns: a survey. In Requirements Engineering: Foundation for Software Quality, pages 301–308. Springer, 2014. [87] Fabio Paterno. Model-based design and evaluation of interactive applications. Springer Science & Business Media, 2000. [88] Fabio Patern`o. Concurtasktrees: an engineered approach to model-based design of interactive systems. The handbook of analysis for human-computer interaction, pages 483–500, 2002. [89] Fabio Paterno and Carmen Santoro. One model, many interfaces. In Computer- Aided Design of User interfaces III, pages 143–154. Springer, 2002. [90] Fabio Patern`o and Carmen Santoro. A unified method for designing interactive systems adaptable to mobile and stationary platforms. Interacting with Computers, 15(3):349–366, 2003. [91] Fabio Patern`o, Carmen Santoro, Lucio Davide Spano, and Dave Raggett. Mbui - task models. Technical report, World Wide Web Consortium (W3C), 2014. 113 114 BIBLIOGRAF´ IA [92] Fabio Patern`o, Carmen Santoro, and Lucio Davide Spano. Maria: A universal, declarative, multiple abstraction-level language for service-oriented applications in ubiquitous environments. ACM Trans. Comput.-Hum. Interact., 16(4):19:1– 19:30, November 2009. [93] Fabio Patern`o, Carmen Santoro, and Lucio Davide Spano. Engineering the authoring of usable service front ends. Journal of Systems and Software, 84(10):1806– 1822, 2011. [94] M Dolores Lozano P´erez. Entorno metodol´ogico orientado a objetos para la especificaci´on y desarrollo de interfaces de usuario. PhD thesis, Universitat Polit`ecnica de Val`encia, 2001. [95] Paulo Pinheiro da Silva. User interface declarative models and development environments: A survey. In Interactive Systems Design, Specification, and Verification, volume 1946 of Lecture Notes in Computer Science, pages 207–226. Springer Berlin / Heidelberg, 2001. [96] Remco Poortinga-van Wijnen, Martijn Oostdijk, Bob Hulsebosch, Niels van Dijk, Roland van Rijswijk, and Hans Zandbelt. Provisioning scenarios in identity federations. 2010. [97] Michael E Porter and Rafael Aparicio Mart´ın. La ventaja competitiva de las naciones, volume 1025. Vergara, 1991. [98] Rub´en Prieto-D´ıaz. Status report: Software reusability. software, IEEE, 10(3):61– 66, 1993. [99] A. Puerta, E. Cheng, T. Ou, and J. Min. Mobile: User-centered interface building. SIGCHI conf. on Human factors in computing systems: the CHI is the limit, May 1999. [100] Angel Puerta and Jacob Eisenstein. Ximl: A universal language for user interfaces. White paper, 2001. [101] Angel Puerta and Jacob Eisenstein. Ximl: a common representation for interaction data. In Proceedings of the 7th international conference on Intelligent user interfaces, IUI ’02, pages 214–215, New York, NY, USA, 2002. ACM. [102] Angel R Puerta. The mecano project: Comprehensive and integrated support for model-based interface development. In CADUI, volume 96, pages 19–36, 1996. [103] Juan C Quiroz, Sushil J Louis, and Sergiu M Dascalu. Interactive evolution of xul user interfaces. In Proceedings of the 9th annual conference on Genetic and evolutionary computation, pages 2151–2158. ACM, 2007. [104] Frank Radeke, Peter Forbrig, Ahmed Seffah, and Daniel Sinnig. Pim tool: Support for pattern-driven and model-based ui development. In Karin Coninx, Kris 114 BIBLIOGRAF´ IA 115 Luyten, and KevinA. Schneider, editors, Task Models and Diagrams for Users Interface Design, volume 4385 of Lecture Notes in Computer Science, pages 82–96. Springer Berlin Heidelberg, 2007. [105] David Raneburger, Gerrit Meixner, and Marco Brambilla. Platform-independence in model-driven development of graphical user interfaces for multiple devices. In Software Technologies, pages 180–195. Springer, 2014. [106] David Raneburger, Roman Popp, and Jean Vanderdonckt. An automated layout approach for model-driven wimp-ui generation. In Proceedings of the 4th ACM SIGCHI symposium on Engineering interactive computing systems, pages 91–100. ACM, 2012. [107] Thiagarajan Ravichandran and Marcus A Rothenberger. Software reuse strategies and component markets. Communications of the ACM, 46(8):109–114, 2003. [108] Dave Roberts, Dick Berry, Scott Isensee, and John Mullaly. Designing for the user with ovid: Bridging the gap between software engineering and user interface design. 1998. [109] Marcus A Rothenberger, Kevin J Dooley, Uday R Kulkarni, and Nader Nada. Strategies for software reuse: A principal component analysis of reuse practices. Software Engineering, IEEE Transactions on, 29(9):825–837, 2003. [110] R Schaefer, B Steffen, and M Wolfgang. Task models and diagrams for user interface design. In Proceedings of 5th International Workshop, TAMODIA’2006, pages 39–53, 2006. [111] Egbert Schlungbaum. Model-based user interface software tools current state of declarative models. Graphics, Visualization & Usability Center, Georgia Institute of Technology, 1996. [112] Douglas C Schmidt. Guest editor’s introduction: Model-driven engineering. Computer, 39(2):0025–31, 2006. [113] Daniel Sinnig, Homa Javahery, Peter Forbrig, and Ahmed Seffah. Patterns and components for enhancing reusability and systematic ui development. Proceedings of HCI International, Las Vegas, USA, 9, 2005. [114] Ian Sommerville. Ingenier´ıa del software. Pearson Educaci´on, 2005. [115] Nathalie Souchon and Jean Vanderdonckt. A review of xml-compliant user interface description languages. In Interactive Systems. Design, Specification, and Verification, volume 2844 of Lecture Notes in Computer Science, pages 391–401. Springer Berlin / Heidelberg, 2003. [116] Richard M Stallman and Zachary Weinberg. The c preprocessor. Free Software Foundation, 1987. 115 116 BIBLIOGRAF´ IA [117] P Szekely, P Sukaviriya, P Castells, J. Muthukumarasamy, and E. Salcher. Declarative interface models for user interface construction tools: the mastermind approach. Engineering for Human-Computer Interaction, pages 120–150, 1996. [118] S Tucker Taft. Consolidated Ada Reference Manual: Language and Standard Libraries: International Standard ISO/IEC 8652/1995 (E) with Technical Corrigendum 1, volume 2219. Springer, 2000. [119] Hallvard Trætteberg. Integrating dialog modeling and domain modeling - the case of diamodl and the eclipse modeling framework. J. UCS, 14(19):3265–3278, 2008. [120] Jean Vanderdonckt, Elizabeth Furtado, V Furtado, Quentin Limbourg, W Silva, D Rodrigues, and L Taddeo. Multi-model and multi-level development of user interfaces. Multiple User Interfaces, Cross-Platform Applications and Context- Aware Interfaces, pages 193–216, 2003. [121] Jean Vanderdonckt and Francisco Montero Simarro. Generative pattern-based design of user interfaces. In Proceedings of the 1st International Workshop on Pattern-Driven Engineering of Interactive Computing Systems, PEICS ’10, pages 12–19, New York, NY, USA, 2010. ACM. [122] Jean Vanderdonckt, Ricardo Tesoriero, Nesrine Mezhoudi, Vivian Motti, Fra¸cois Beuvens, and J´er´emie Melchior. Mbui - abstract user interface models. Technical report, World Wide Web Consortium (W3C), 2014. [123] Jean M Vanderdonckt and Fran¸cois Bodart. Encapsulating knowledge for intelligent automatic interaction objects selection. In Proceedings of the INTERACT’93 and CHI’93 Conference on Human Factors in Computing Systems, pages 424–429. ACM, 1993. [124] Chris Vandervelpen and Karin Coninx. Towards model-based design support for distributed user interfaces. In Proceedings of the third Nordic conference on Human-computer interaction, pages 61–70. ACM, 2004. [125] Windson Viana and Rossana M.C. Andrade. Xmobile: A mb-uid environment for semi-automatic generation of adaptive applications for mobile devices. Journal of Systems and Software, 81(3):382 – 394, 2008. [126] Karel Vredenburg, Ji-Ye Mao, Paul W Smith, and Tom Carey. A survey of usercentered design practice. In Proceedings of the SIGCHI conference on Human factors in computing systems, pages 471–478. ACM, 2002. [127] Norman Walsh and Richard L Hamilton. DocBook 5: The definitive guide. .O’Reilly Media, Inc.”, 2010. [128] Stephanie Wilson and Peter Johnson. Empowering users in a task-based approach to design. In Proceedings of the 1st conference on Designing interactive systems: processes, practices, methods, & techniques, pages 25–31. ACM, 1995. 116 Ap´endice A DTD del lenguaje ASL <!ELEMENT a s l ( x i : i n c l u d e ∗, head ? , ( group |main |form |c ontainer |workflow ) ∗)> <!ELEMENT x i : i n c l u d e ( x i : f a l l b a c k ?)> <!ATTLIST x i : i n c l u d e xmlns:xi CDATA #FIXED ” ht tp : //www. w3 . org /2001/ XInclude ” href CDATA #IMPLIED parse (xml|text ) ”xml” xpointer CDATA #IMPLIED encoding CDATA #IMPLIED accept CDATA #IMPLIED accept−language CDATA #IMPLIED > <!ELEMENT x i : f a l l b a c k ANY> <!ATTLIST x i : f a l l b a c k xmlns:xi CDATA #FIXED ” ht tp : //www. w3 . org /2001/ XInclude ” > <!ELEMENT head ( meta ∗)> <!−− Head t a g : Contains meta−data about the −−> <!ELEMENT meta EMPTY> <!ATTLIST meta c l a s s CDATA #REQUIRED name CDATA #REQUIRED value CDATA #REQUIRED ord CDATA ’ ’ > <!ELEMENT doc (#PCDATA)> < !−− Used for documentation porpouses −−> <!ELEMENT prop ( vars ? , u f i e l d s ? , uevents ? , account ?)> <!ELEMENT vars (#PCDATA)> < !−− P r o f i l e v a rs : any v a r i a b l e in the system can be rede f i ned here −−> <!ELEMENT u f i e l d s ( uval+)> <!ELEMENT uval (#PCDATA)> < !−− Up to ten user valu e s can be defined −−> <!ELEMENT uevents ( onlogin ? , onlogout ?)> 117 118 AP´ ENDICE A. DTD DEL LENGUAJE ASL <!ELEMENT onlogin ( action )> < !−− onlogin event −−> <!ELEMENT onlogout ( act ion )> < !−− onlogout event −−> <!ELEMENT account EMPTY> <!−− v a l i d t o : Date format YYYY−MM−DD −−> <!−− changeat: A number f o ll o we d by day , week or year −−> <!−− l o c k : Y|N−−> <!ATTLIST account v a li d to CDATA ’ ’ changeat CDATA ’ ’ lock CDATA ’ ’ > <!ELEMENT group ( doc ? , user ∗, prop ?)> <!−− g i d : group i d e n t i f i e r , a number −−> <!−− name: group name −−> <!−− grou pid: main menu f or users in t h i s group −−> <!ATTLIST group gid CDATA #REQUIRED name CDATA #REQUIRED descr CDATA ’ ’ mainid CDATA ’ ’> <!ELEMENT user ( doc ? , prop ?)> <!−− u id : user i d e n t i f i e r , a number −−> <!−− username −−> <!−− p la in t e x t passwd −−> <!−− main menu f or t h i s user −−> <!−− user d e s c r i p t i o n −−> <!ATTLIST user uid CDATA #REQUIRED name CDATA #REQUIRED passwd CDATA #REQUIRED mainid IDREF #IMPLIED descr CDATA ’ ’> <!ELEMENT main ( doc ? , menu+)> <!ATTLIST main id ID #REQUIRED caption CDATA #REQUIRED t o o l t i p CDATA ’ ’> <!ELEMENT menu ( doc ? , option +, a c l ?)> <!ATTLIST menu caption CDATA #REQUIRED t o o l t i p CDATA ’ ’ img CDATA ’ ’> <!ELEMENT option ( doc ? , action ? , param ∗, a c l ?)> <!ATTLIST option caption CDATA #REQUIRED c a l l CDATA ’ ’ action CDATA ’ ’ 118 119 type ( form |conta iner |r e l a t i o n |s p l i t |tab | tab−buttons |workflow ) ’ form ’ url CDATA ’ ’ t o o l t i p CDATA ’ ’ img CDATA ’ ’> <!ELEMENT c ontai ner ( doc ? , param ∗)> <!ATTLIST container id ID #REQUIRED type ( form |r e l a t i o n |s p l i t |tab |tab−buttons | workflow ) ’ form ’ > <!ELEMENT param EMPTY> <!ATTLIST param name CDATA #REQUIRED ord CDATA ’ 1 ’ value CDATA #REQUIRED> <!ELEMENT workflow ( doc ? , msg? , prev ? , a l t ? , next ?)> <!ATTLIST workflow id ID #REQUIRED containerid IDREF #IMPLIED url CDATA ’ ’> <!ELEMENT prev EMPTY> <!ATTLIST prev id IDREF #REQUIRED msg CDATA ’ ’ button CDATA ’ ’> <!ELEMENT next EMPTY> <!ATTLIST next id IDREF #REQUIRED msg CDATA ’ ’ button CDATA ’ ’> <!ELEMENT a l t EMPTY> <!ATTLIST a l t id IDREF #REQUIRED msg CDATA ’ ’ button CDATA ’ ’> <!ELEMENT form ( doc ? , datasource ? , f i l t e r ? , orderby ? , theme ? , help ? , f i e l d s , events ? , buttons ? , a cl ?)> <!ATTLIST form id ID #REQUIRED source CDATA ’ ’ caption CDATA #REQUIRED t o o l t i p CDATA ’ ’ > <!ELEMENT datasource (#PCDATA)> <!ELEMENT f i l t e r (#PCDATA)> <!ELEMENT orderby (#PCDATA)> <!ELEMENT theme (#PCDATA)> <!ELEMENT help (#PCDATA)> <!ELEMENT events ( onload ? , onunload ? , b e f o r e r e t r i e v e ? , a f t e r r e t r i e v e ? , b e f o r e i n s e r t ? , a f t e r i n s e r t ? , beforeupdate ? , a fterupdate ? , b e f o r e d e l e t e ? , a f t e r d e l e t e ?)> 119 120 AP´ ENDICE A. DTD DEL LENGUAJE ASL <!ELEMENT onload ( action )> <!ELEMENT onunload ( acti on )> <!ELEMENT b e f o r e r e t r i e v e ( actio n )> <!ELEMENT a f t e r r e t r i e v e ( ac tion )> <!ELEMENT b e f o r e i n s e r t ( a ction )> <!ELEMENT a f t e r i n s e r t ( action )> <!ELEMENT beforeupdate ( action )> <!ELEMENT afterupdate ( action )> <!ELEMENT b e f o r e d e l e t e ( ac tio n )> <!ELEMENT a f t e r d e l e t e ( action )> <!ELEMENT buttons ( action +)> <!ELEMENT action ( doc ? , t o ol t i p ? , code ? , actparam ? , msg? , acl ?)> <!ATTLIST action type CDATA #REQUIRED caption CDATA ’ ’ datareq CDATA ’ ’ autoparam CDATA ’ ’ btn CDATA ’ ’> <!ELEMENT t o o l t i p (#PCDATA)> <!ELEMENT code (#PCDATA)> <!ELEMENT actparam (#PCDATA)> <!ELEMENT msg (#PCDATA)> <!ELEMENT a c l ( doc ? , ace+)> <!ELEMENT ace EMPTY> <!ATTLIST ace gid CDATA #REQUIRED read CDATA ’ 0 ’ i n s e r t CDATA ’ 0 ’ update CDATA ’ 0 ’ de l et e CDATA ’ 0 ’ action CDATA ’ 0 ’> <!ELEMENT f i e l d s ( key ? , ( fkey |f i e l d |justc ode |s t r i n g |text |int | f l o a t |date |time |timestamp |blob−f i l e |image−f i l e )+)> <!ELEMENT f i e l d ( defvalue ? , chkvalue ? , search ? , s e a r c h f i e l d ? , browsearch ? , s t yl e ? , widget ? , wdgparam? , width ? , height ? , rowfunc ? , col f u nc ? , tag ?)> <!ATTLIST f i e l d source CDATA ’ ’ type CDATA ’ s t r i n g ’ caption CDATA ’ ’ len CDATA ’ 0 ’ maxlen CDATA ’ 0 ’ att r CDATA ’−’ msg CDATA ’ ’ canbenull CDATA ’N’ format CDATA ’ %s ’ picture CDATA ’ . ’ t o o l t i p CDATA ’ ’ > 120 121 <!ELEMENT search (#PCDATA)> <!ELEMENT s e a r c h f i e l d (#PCDATA)> <!ELEMENT browsearch (#PCDATA)> <!ELEMENT defvalue (#PCDATA)> <!ELEMENT chkvalue (#PCDATA)> <!ELEMENT s t y l e (#PCDATA)> <!ELEMENT widget (#PCDATA)> <!ELEMENT wdgparam (#PCDATA)> <!ELEMENT width (#PCDATA)> <!ELEMENT height (#PCDATA)> <!ELEMENT rowfunc (#PCDATA)> <!ELEMENT c o l func (#PCDATA)> <!ELEMENT tag (#PCDATA)> <!ELEMENT key ( defvalue ? , chkvalue ? , search ? , s e a r c h f i e l d ? , browsearch ? , s ty l e ? , widget ? , wdgparam? , width ? , height ? , rowfunc ? , c o lfunc ? , tag ?)> <!ATTLIST key source CDATA #REQUIRED type CDATA ’ s t r i n g ’ caption CDATA ’ ’ len CDATA ’ 0 ’ maxlen CDATA ’ 0 ’ att r CDATA ’H’ msg CDATA ’ ’ canbenull CDATA ’Y’ format CDATA ’ %s ’ picture CDATA ’ ’ t o o l t i p CDATA ’ ’ > <!ELEMENT fkey ( defvalue ? , chkvalue ? , search ? , s e a r c h f i e l d ? , browsearch ? , s t yl e ? , widget ? , wdgparam? , width ? , height ? , rowfunc ? , col f u nc ? , tag ?)> <!ATTLIST fkey source CDATA #REQUIRED type CDATA ’ s t r i n g ’ caption CDATA ’ ’ len CDATA ’ 0 ’ maxlen CDATA ’ 0 ’ att r CDATA ’H’ msg CDATA ’ Unset value in f o r e i g n key ’ canbenull CDATA ’N’ format CDATA ’ %s ’ picture CDATA ’ ’ t o o l t i p CDATA ’ ’ > <!ELEMENT j ustcode ( defvalue ? , chkvalue ? , search ? , s e a r c h f i e l d ? , browsearch ? , s t yl e ? , widget ? , wdgparam? , width ? , height ? , rowfunc ? , col f u nc ? , tag ?)> <!ATTLIST justcode source CDATA ’ ’ type CDATA ’ code ’ caption CDATA ’ ’ len CDATA ’ 20 ’ 121 128 AP´ ENDICE B. DESARROLLO DE UNA APLICACI´ ON que manipula. En este caso ser´a necesario describir tres unidades de interacci´on: ctype, c category y c suggestion. No es necesario definir la unidad de interacci´on meta.container.appinfo que ser´a incluida desde la biblioteca de Modelos de la IU de WAINE. People Suggestion Category Category Type 1:N form f_people table f_suggestion 1:N f_category combo f_category table f_type table Relation: c_suggestion Form: c_category Form: c_type Relation: c_suggestion_aux Figura B.4: Diagrama entidad-relaci´on anotado 4. Especificaci´on ASL. Partiendo de los Diagrama Entidad-Relaci´on anotados y de la tabla rol/funcionalidad se genera la especificaci´on de los modelos en lenguaje ASL. Un editor espec´ıfico para documentos XML o un simple editor de textos puede ser usado para generar el archivo con la especificaci´on. A continuaci´on se muestra el c´odigo ASL para la aplicaci´on de ejemplo: <?xml version=’ 1.0 ’ ?> <!DOCTYPE asl PUBLIC ”−//ITI //DTD XWF 0 .6 //EN” ”/ usr / l o c a l / l i b /waine −2.2/ l i b / a s l . dtd”> <asl> <xi:include hr ef=”/usr / l o c a l / l i b /waine −2.2/ i nc lud e /meta . a s l ”/> <head> <meta c l a s s=”AppInfo” name=”appname” value=”sample”/> <meta c l a s s=”AppInfo” name=” ver ” value=” 0.1 ”/> <meta c l a s s=” AppInfo” name=” date ” value=”2006−09−21”/> <meta c l a s s=” AppInfo ” name=” author ” value=”A. L . Delgado ”/> <meta c l a s s=”AppInfo” name=” email ” value=” aldelgado@us . es ”/> </head> <group gid=”0” name=” su p e r v i s o r ”> <user uid=”0” name=” sarah ” passwd=” sarahkey ” mainid=” main supervisor ” descr=”Sarah Smith”/> 128 129 </group> <group gid=”1” name=” s e c re t ar y ”> <user uid=”1” name=” joe ” passwd=” joekey ” mainid=” main secretary ” descr=”Joe Janus”/> </group> <main id=” main supervisor ” caption=”en=Supervisor menu |es=Menu del s u p e r v i s o r ”> <menu caption=”en=Management |es=Gestion ”> <option caption=”en=People Category |es=Categoria para personas ” c a l l=” c cat egory ”/> <option caption=”en=Suggestion type |es=Tipo de sugerencia s ” c a l l=” c type ”/> </menu> <menu caption=”en=Misc |es=Otros ”> <option caption=”en=Waine page |es=Web de Waine” url=” http: // waine . us . es ”/> <option caption=”en=Author |es=Autor” c a l l=”meta . contai ner . appinfo ”/> <option caption=”en=Logout |es=S a l i r ” u rl=” logout . php”/> </menu> </main> <main id=” main secretary ” caption=”en=Default user menu |es=Menu del usuario por def e c to ”> <menu caption=”en=Management |es=Gestion ”> <option caption=”en=Suggestions |es=Sugerencias ” c a l l=” c sugg e s t i o n ”/> </menu> <menu caption=”en=Misc |es=Otros ”> <option caption=”en=Waine page |es=Web de Waine” url=” http: // waine . us . es ”/> <option caption=”en=Author |es=Autor” c a l l=”meta . contai ner . appinfo ”/> <option caption=”en=Logout |es=S a l i r ” u rl=” logout . php”/> </menu> </main> <form id=” f t y p e ” source=” type” caption=”Type”> <fields> <key source=”pk”/> <string source=” descr ” caption=” Descr iption ” len=”40” maxlen=”80”/> </fi e l d s> </form> <container id=” c type ” type=”form”> <param name=” formid ” value=” f t y pe ”/> <param name=” form type ” value=” tab le ”/> <param name=” b ut t on in s e rt ” value=”1”/> <param name=” button update ” value=”1”/> 129 130 AP´ ENDICE B. DESARROLLO DE UNA APLICACI´ ON </container> <form id=” f c a t e g o r y ” s ource=” category ” c aption=” Category”> <orderby>name</orderby> <fields> <key source=”pk”/> <string source=”name” caption=”Name” len=”40” maxlen=”80”/> </fi e l d s> <events> <beforedelete> <action type=”php”> <code>return event BeforeDelete ($pk) ;</code> <msg>You can not d e l et e t h i s category because t h i s i s the d e f a t u l t category or some people belongs to i t . </msg> </action> </beforedelete> </events> </form> <container id=” c category ” type=”form”> <param name=” formid ” value=” f c a t e g o r y ”/> <param name=” form type ” value=” tab le ”/> <param name=” button data ” value=”1”/> </container> <form id=” f p e o p l e ” 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>f c a t e g o r y</search> <s e a r c h f i e l d>name</ s e a r c h f i e l d> </int> </fi e l d s> <events> <beforedelete> <action type=” source ”> <code>DELETE FROM sugges tion WHERE fkpeople= %pk</code> <msg>All s ug e st i on s from t h i s person d elet ed</msg> </action> </beforedelete> </events> </form> 130 131 <form id=” f s u g g e s t i o n ” so urce=” s ug ges ti on ” caption=” Suggestion ”> <fields> <key source=”pk”/> <text sourc e=” d e s c r i p t i o n ” caption=” D esc ri pt ion ”> <width>40</width> <height>3</height> </text> <int source=” fktype ” caption=”Type”> <search>f t y p e</search> <s e a r c h f i e l d>descr</ s e a r c h f i e l d> </int> <date source=” creat i ondat e ” caption=”Date” len=”10” att r=”R”> <defvalue>=date ( ”m−d−Y” )</ defvalue> </date> <int source=” fkpeople ” a t t r=”H” msg=” S e le ct person f i r s t ”/> </fi e l d s> </form> <container id=” c s ug ge st io n ” type=” r e l a t i o n ”> <param name=” f o r m s p l i t ” value=”rows =80,∗”/> <param name=” formid ” value=” f c a t e g o r y ”/> <param name=” form type ” value=”combo”/> <param ord=”2” name=” containerid ” value=” c su gges tion a ux ”/> </container> <container id=” c s ugg estio n a ux ” type=” r e l a t i o n ”> <param name=” f o r m s p l i t ” value=”rows =240,∗”/> <param name=” formid ” value=” f p e o p l e ”/> <param name=” form type ” value=”form”/> <param name=” button data ” value=”1”/> <param name=” s o u r c e f i l t e r f i e l d ” value=” fkcategor y ”/> <param name=” n a v i g a t o r f i e l d s ” value=”name”/> <param name=” n a v i g a t o r p o s i t i o n ” value=”W”/> <param name=” navigator width ” value=”20”/> <param ord=”2” name=” formid ” value=” f s u g g e s t i o n ”/> <param ord=”2” name=” form type ” value=” t ab le ”/> <param ord=”2” name=” button data ” value=”1”/> <param ord=”2” name=” s o u r c e f i l t e r f i e l d ” value=” fkpeople ”/> </container> </asl> Listado B.1: C´odigo ASL de la aplicaci´on 5. Generar y completar los repositorios. El primer paso ser´a crear una nueva instancia de aplicaci´on. Usando la utilidad mkapp se genera una nueva instancia de 131 132 AP´ ENDICE B. DESARROLLO DE UNA APLICACI´ ON aplicaci´on enlazada a una determinada versi´on del motor. mkapp tambi´en genera un Repositorio de Configuraciones con valores por defecto para un funcionamiento b´asico de la aplicaci´on y que posteriormente puede ser modificado para personalizar la instancia de aplicaci´on. Una vez hecho esto podemos generar y completar los repositorios. Se genera la Base de Datos de la aplicaci´on, utilizando para ello el c´odigo SQL obtenido a partir del Diagrama Entidad-Relaci´on. Se crea el Repositorio de la IU a partir de la descripci´on en ASL. Para ello se emplea la utilidad asl2mdb.asl2mdb es un shellscript que utiliza xmlstarlet un toolkit XML que funciona en la l´ınea de comandos [44]. asl2mdb permite generar el Repositorio de la IU sobre distintos tipos de soporte: varias bases de datos relacionales (sqlite, MariaDB, PostgreSQL, etc.), ficheros CSV, ficheros DBF, etc. Se completa el Repositorio de Configuraciones. La configuraci´on consiste en la edici´on de diferentes archivos en este repositorio. Al menos dos archivos (db.cfg ymdb.cfg) deber´an ser modificados para configurar los or´ıgenes de datos empleados como Base de Datos yRepositorio de la IU . Por ejemplo, en el listado B.2, podemos ver el c´odigo necesario para configurar el acceso al Repositorio de la IU . <?php $DBDRIVER=” d s s q l i t e . inc ” ; $DBFILE=” ./MDB” ; ?> Listado B.2: Configuraci´on del origen de datos del repositorio de la interfaz de usuario Otros archivos pueden ser editados para modificar aspectos de la presentaci´on concreta, definir nuestros propios widgets, funciones, eventos, etc. En el listado B.3 podemos ver la codificaci´on en PHP del evento event BeforeDelete del formulario fcategory. funct ion event BeforeDelete ( $IN pk ) { i f ( $IN pk >0) { $conn=s q l i t e o p e n ( ” . /DB” ) ; $ r e s ul t=s q l i t e q u e r y ( $conn , ”SELECT count (pk ) ” . ”FROM” . ” people WHERE ” . fkcategory=$IN pk” ) ; i f ( s q l i t e f e t c h s i n g l e ( $ r e s u l t )==”0” ) return 1; } 132 133 return 0; } Listado B.3: C´odigo del evento event BeforeDelete Para finalizar este anexo, en la figura B.5 podemos ver la unidad de interacci´on (c sugestion) en su forma final en tiempo de ejecuci´on. Suggestion Category People 1:N table f_suggestion f_category combo 1:N form f_people Relation: c_suggestion Relation: c_suggestion_aux Figura B.5: Formulario para el secretario. 133 134 AP´ ENDICE B. DESARROLLO DE UNA APLICACI´ ON 134 Ap´endice C Componente ASL <!−− aslmod: meta v e r : 0.1 author: Antonio Luis Delgado Gonzalez da t e : 2006−12−28 o b j e c t s : meta . container . a p p i n f o : generic ’ about ’ d i al og meta . form . meta: show data st ored in meta (RIU) −−> <aslmod> <form id=”meta . form . meta” source=” meta” caption=” In fo ”> <datasource>mdb. cfg</datasource> <fields> <key source=”metaid”/> <string source=”name” caption=”Name” len=”36” att r=”R”/> <string source=” value ” caption=”Value” len=”36” att r=”R”/> </fi e l d s> </form> <container id=”meta . container . appinfo ” type=”form” > <param name=” formid ” value=”meta . form . meta”/> <param name=” form type ” value=” t ab le ”/> <param name=” button data ” value=”0”/> <param name=” button misc ” value=”0”/> <param name=” s o u r c e f i l t e r f i e l d ” value=” c l a s s ”/> <param name=” s o u r c e f i l t e r v a l u e ” value=”AppInfo”/> </container> </aslmod> Listado C.1: C´odigo de un componente ASL 135 136 AP´ ENDICE C. COMPONENTE ASL 136 Ap´endice D L´ıneas de c´odigo por aplicaci´on La siguiente tabla detalla las l´ıneas de c´odigo de cada modelo y lenguaje empleado en las aplicaciones del caso de estudio. DOM (SQL) %UM %DM %PM %RC %TOTAL (A1) Reservas 2.019 24,2 33 0,4 328 3,9 5.335 64,0 618 7,4 8.333 (A2) Inventario 137 17,7 6 0,8 40 5,2 532 68,6 60 7,7 775 (A3) Tabl´on 208 19,8 15 1,4 64 6,1 689 65,7 73 7,0 1049 (A4) Pr´acticas 199 25,5 3 0,4 35 4,5 483 61,9 60 7,7 780 (A5) RelExteriores 128 30,0 3 0,7 17 4,0 219 51,3 60 14,1 427 (A6) InfoPanel 480 30,7 6 0,4 33 2,1 865 55,4 177 11,3 1.561 Media 529 24,7 11 0,7 86 4,3 1.354 61,2 175 9,2 2.154 Tabla D.1: L´ıneas de c´odigo por aplicaci´on Para la obtenci´on de los datos de la tabla D.1, es necesario contar l´ıneas de c´odigo de diversos documentos. Modelo de Dominio: En el Modelo de Dominio se han contabilizado l´ıneas de c´odigo SQL para cada aplicaci´on. Utilizando el shell y algunos comandos habituales de UNIX, se han eliminado l´ıneas vac´ıas y se han contabilizado las ´utiles con wc. $ f o r i in ∗. s q l ; do echo −n ” $i ” ; egrep −v ” ˆ [ [ : space : ] ] ∗$” $i | wc −l ; done board . s q l 208 inveq . s q l 137 pracemp . s q l 199 r e l e x t . s q l 128 r e s er v a s . s q l 2019 s cr pl an . s q l 480 Listado D.1: Cuenta de las l´ıneas de c´odigo de archivos SQL Modelos soportados por ASL: En ASL se definen el Modelo de Usuario, el Modelo de Di´alogo y el Modelo de Presentaci´on. Para contar las l´ıneas de c´odigo de cada 137