De MorfeoWiki

Tabla de contenidos 1 Resumen 2 Informe Científico-Técnico del Entorno de desarrollo 2.1 Introducción y alcance del informe 2.2 Definición del modelo conceptual 2.3 Entornos de desarrollo 2.3.1 Entornos de desarrollo visuales 2.3.2 Otros entornos de desarrollo 2.3.3 Resumen de características 2.4 Identificación de requisitos específicos 2.5 Conclusiones 3 Diseño y Especificaciones abiertas del Entorno de Desarrollo 3.1 Desarrollo de contenidos y servicios 3.2 Desarrollo de gadgets 3.3 Entorno de desarrollo de recursos 3.3.1 Herramientas de desarrollo 3.3.2 Integración con entornos de desarrollo 3.3.3 Diseño visual 3.3.3.1 Descripción de la plataforma de desarrollo visual 3.3.3.2 Fuente de recursos 3.3.3.3 Área de diseño 3.3.3.3.1 Código 3.3.3.3.2 Depuración 3.3.4 Otras funcionalidades 3.3.4.1 Asistentes 3.3.4.2 Ciclo de vida 3.3.5 Diseño de las herramientas 3.3.6 Notas 4 Referencias

Resumen

El objetivo de este documento es analizar requisitos de un entorno visual de desarrollo de recursos y abordar las soluciones ya existentes contrastando algunas de sus ventajas e inconvenientes. Además, se extraen los requisitos que debe cumplir la plataforma que se implemente, se hace un boceto de alto nivel de la misma y se dan algunas guías y referencias que podrán ser utilizadas en fases posteriores.

Este paquete se compone de los siguientes entregables:

• D 3.5.1 Informe Científico-Técnico del Entorno de desarrollo
• D 3.5.2 Diseño y Especificaciones abiertas del Entorno de Desarrollo

Informe Científico-Técnico del Entorno de desarrollo

Introducción y alcance del informe

Cabe destacar que este documento es de muy alto nivel, y su función principal es profundizar en los requisitos que debe cumplir el entorno de desarrollo. Se busca imponer el menor número de restricciones posible, y que se ciñan sólo al entorno de mash-up. Para aquellas decisiones que no sean exclusivamente del mismo, que deban ser tomadas en otros documentos y que tengan una alta repercusión se analizarán distintas posibilidades y se darán variantes de diseño adaptadas a cada una de ellas.

Se supone que el lector está familiarizado con los conceptos de gadget^[1] (también denominados widgets^[2] en algunas plataformas), signal^[3], slot^[3], recurso^[4] y entorno operacional.

Definición del modelo conceptual

El modelo conceptual que se define en la tarea T 3.5.1 de la memoria del proyecto, no puede ser descrito hasta que no se tenga una formalización previa de los recursos, lo cual debe cubrirse en el paquete de trabajo PT 2.2.

Entornos de desarrollo

Entornos de desarrollo visuales

Existen decenas de entornos de desarrollo visuales, pero la mayoría están dirigidos a desarrolladores que en algún momento esperan tener que introducir código en algún lenguaje de programación. En el caso del entorno de desarrollo EzWeb debe permitirse que se introduzca código para los recursos, sobre todo para crear aquellos más básicos que luego se puedan usar para crear otros más complejos por composición. Sin embargo es primordial proporcionar un entorno de desarrollo lo más visual posible, por lo que inicialmente centraremos nuestra atención en algunos de los que buscan o han alcanzado ese objetivo. Aunque existen muchos otros entornos de desarrollo visuales (sean o no de gadgets), los siguientes cuatro incluyen gran parte de los requisitos que más tarde se deducirán para EzWeb.

• Yahoo Pipes^[5] es sin duda el entorno de diseño de gadgets más amigable e intuitivo. Permite diseñar recursos por mash-up sin necesidad de escribir código, simplemente a base de conectar otros más elementales. La idea principal es soltar gadgets en un panel de diseño para luego encadenar entradas de unos con salidas de otros. El sistema se encarga de no permitir al usuario conectar entradas y salidas incompatibles.

• Automator^[6]. Entorno de desarrollo de macros de Apple, basado en acciones predefinidas asociadas a cada programa en las que se enlaza la salida de uno con la entrada del siguiente. De la referencia en Wikipedia^[7] se lee "[...] Automator [...] requires no expertise in these (programming) languages whatsoever". Gran parte de la aportación de Automator viene de proporcionar un conjunto de acciones utilizables muy extenso y potente. Un claro ejemplo sería en sólo tres pasos encadenar las acciones pedir una dirección a un usuario, descargar una web y leer un texto en voz alta para crear una macro que lee la web de una dirección en voz alta. Entre otros aspectos destacables, que muestra qué parte del gadget se está ejecutando en cada momento de forma visual, con lo que es mucho más fácil detectar errores y comprender (sobre todo para un usuario sin conocimientos de programación) la causa de los mismos.

• Entorno de desarrollo de QT - QT Designer^[8]. QT Designer es un entorno de desarrollo de aplicaciones. Aunque existen bindings para varios lenguajes de programación, QT utiliza C++ con macros del preprocesador. En este entorno no todo se puede hacer gráficamente, es necesario incluir código fuente para manejar los eventos. El motivo principal por el que parece reseñable es que se pueden combinar los controles encadenando slots y signals de unos con otros, un concepto que en otros entornos no se maneja explícitamente o no de forma gráfica.

• Dashcode^[9]. Herramienta de desarrollo de widgets de Apple para Dashboard. Orientado a gráfico y a código, con depuración visual y una amplia librería de componentes básicos y plantillas. La única aportación nueva que hace es que ayuda al usuario mediante una guía de pasos a seguir en el desarrollo del widget.

Otros entornos de desarrollo

Existen otras plataformas que también permiten diseñar gadgets, sin embargo no en todas se realizan de forma visual. Entre ellas podemos destacar las siguientes, no por su facilidad de uso, sino basándonos más en el éxito de la plataforma completa:

• Google Gadgets^[10]. La propia empresa lo define como "una forma sencilla de crear pequeñas aplicaciones que se pueden ejecutar en múltiples sitios, incluyendo iGoogle, Google Desktop, Google Page Creator, y ... Google Gadgets for Your Webpage". Para crear estos gadgets sí es necesario ser un programador (aunque los más sencillos se pueden crear usando asistentes^[11]). Los usuarios pueden usar cualquier editor para el desarrollo, Google permite usar su propio editor^[12], que incluye vista previa del gadget, pero sigue siendo necesario escribir código en un lenguaje de programación. Para la construcción de gadgets complejos está desarrollando Google Mashup Editor ^[13].

• Netvibes^[2]. Esta plataforma está diseñada para crecer de forma ágil en número de gadgets disponibles: cada gadget diseñado es obligatoriamente compartido con todos. Su programación también tiene que ser realizada de forma no visual. Tiene como ventaja que el recurso resultante está disponible para varias plataformas, no sólo netvibes.

Además de estos, existen otros entornos que han sido referenciados por partners del proyecto, que incluyen muchas de las funcionalidades ya vistas y de los que, en el futuro, también se podrían extraer funcionalidades a incorporar a EzWeb:

• Widgetarium^[14]. Incluye edición dependiente del contexto, gestión de proyectos, emulación del dashboard, inspección de widgets, depuración de código javascript, herramientas gráficas, documentación accesible desde la herramienta, plantillas rápidas y extensiones especiales.
• Spket IDE^[15] (plugin de Eclipse, orientado a desarrollo de widgets para Yahoo!). No es software libre, por lo que las funcionalidades que tiene deberían ser reimplementadas en caso de que se considerase oportuno incorporarlas a EzWeb. Entre sus características destaca compleción de código, resaltado de sintaxis e índice de contenidos.
• Aptana^[16]. Plug-in para Eclipse. Las características de la edición profesional (existe una versión más limitada que es software libre), están: desarrollo de HTML/CSS/JavaScript, librerías Ajax incluidas, editor de JSON (JavaScript Object Notation), desarrollo de Adobe AIR (via Plugin), desarrollo para iPhone (via Plugin), desarrollo de Ruby on Rails (RadRails), (via Plugin), desarrollo de PHP (via Plugin), FTP, FTPS, SFTP, Asistente de importación de proyectos remotos, depuración de JavaScript para Firefox e Internet Explorer, Automatización de JavaScript/Ruby del entorno de desarrollo y Motor de informe de proyecto.
• Widgetryworkshop^[17]. Destaca Asistente de widgets, scripting inteligente y explorador de widgets.
• AJAX Toolkit Framework^[18]. Notablemente más avanzado que los demás, incluye una amplia lista de funcionalidades en ^[19].
• Open Kapow^[20]. Incluye creación de feeds RSS, servicios REST o clips desde casi cualquier sitio web, manejo y ejecución avanzados de javascript, maneja logins para proteger sitios usando cookies, autenticación HTTP, mediante formulario y HTTPS, extracción potente de datos e interacción con HTML usando expresiones regulares, conversores y patrones, depuración y manejo de errores flexible, Entrono de desarrollo gráfico point-and-click con despliegue en un click, control total del flujo de proceso en un robot, incluyendo condiciones y bucles, consumo de servicios web, envío de emails, manejo de marcos, salida en XML, XHTML, HTML, JSON y CSV.
• QEDWiki^[21]. Entorno de mashup de IBM basado en PHP y AJAX. Tiene un módulo de wiring (conceptualmente simiar al que incorporará EzWeb) que permite comunicar widgets entre sí.

Resumen de características

La siguiente tabla resume algunos aspectos analizados de los distintos entornos, incluyendo características destacables de algunos de ellos. Los aspectos que se analizan de cada entorno son los siguientes:

• Interfaz web: entorno al que se puede acceder mediante una interfaz web (con un navegador).
• Interfaz standalone: entorno que incluye herramientas de compilación, depuración, etc. que podemos utilizar en nuestro equipo sin necesidad de conexión por web.
• Depuración visual: permite depurar la aplicación en busca de fallos sin tener que analizar el código, marcando el punto de ejecución y los errores en la representación visual del recurso que se diseña.
• Nivel mínimo del usuario: nivel mínimo de conocimientos de programación que debe tener el usuario del entorno de desarrollo.
• Indicación de puntos de anclaje: indicación de compatibilidad de entradas y salidas de forma automática entre distintos recursos en una composición. Nótese que para hablar de compatibilidad hace falta que las salidas y entradas estén tipadas de alguna forma.
• Mashup basado en componentes: posibilidad de construir un recurso ó gadget a base de construir sus componentes por separado e independientemente, para luego juntarlos.
• Código: soporte para analizar el código asociado al recurso en construicción y para modificarlo, depurarlo, etc.
• Test en plataforma: posibilidad de ejecutar el recurso directamente desde la plataforma de desarrollo sin tener que copiarlo manualmente a un entorno específico para su ejecución.
• Control de versiones: capacidad de etiquetar versiones del recurso, marcarlas y volver atrás en ellas (con persistencia).
• Asistentes: asistentes que guían al usuario en la construcción de gadgets (o al menos en algunos tipos de ellos).

	Yahoo! Pipes	QT Designer	Automator	Netvibes	Google Gadgets
Interfaz Web	Sí	No	No	Sí	Sí
Interfaz Standalone	No	Sí	Sí	Sí	Sí
Depuración visual	No	No	Sí	No	No
Nivel mínimo del usuario	Medio	Experto	Básico	Experto	Experto
Indicación de puntos de anclaje	Sí	No	No	No	No
Mashup basado en componentes	Sí	Sí	Sí	No	No
Código	No	Sí	No	Sí	Sí
Test en plataforma	Sí	Sí	Sí	Sí	Sí
Control de versiones	No	No	No	No	No
Asistentes	No	No	No	No	Sí

Identificación de requisitos específicos

Los requisitos que se esperan que cumpla entorno de desarrollo, tal y como se describen en la memoria del singular, son los siguientes:

• Permitir la construcción de recursos complejos a expertos de dominio y personal cualificado.
• Proporcionar un conjunto de herramientas de desarrollo que guíen a los usuarios en la creación de sus propios contenidos compatibles con la plataforma EzWeb.
• Permitir la creación de recursos desde cero o por composición de otros existentes (vía mashup avanzados).
• Posibilitar el desarrollo de recursos a personas con conocimiento limitado: minimizar la programación y los algoritmos y favorecer las especificaciones de alto nivel basados en elementos semánticos.
• Permitir el desarrollo visual en un alto porcentaje, minimizando programas.
• Facilidad de uso.
• Altamente basado en reutilización de entornos y componentes similares.
• Integrable con otras herramientas (Eclipse, forjas, verificadores, etc.)
• Permitir su uso en varias etapas del ciclo de vida (validación, verificación, versiones, etc.)

En los requisitos anteriores existen algunos puntos que son ambiguos, por lo que aquí se detallan las suposiciones o interpretaciones que se han hecho de los mismos.

• Se entiende por personal cualificado a programadores de gadgets o usuarios que están habituados a utilizar plataformas de desarrollo similares.

• La información semántica que se incluye debe ser lo suficientemente potente y precisa como para distinguir compatibilidad de tipos más allá de los tipos básicos que nos solemos encontrar en un lenguaje de programación. Piénsese, por ejemplo, en un caso de datos en millas y en kilómetros. Existe una forma de hacerlos compatibles, pero si ambos se almacenan como enteros y no se dice nada más, la plataforma no tiene conocimiento de las unidades. No parece razonable que caiga como responsabilidad del usuario comprobar la concordancia de unidades cuando esa información se puede añadir de una forma que permita a EzWeb hacer razonamiento, transformación y cálculo con esos datos, siendo capaz de sumar millas y kilómetros, transformar uno al otro sin tener que advertir al usuario, etc.

• En la lista se muestra implícitamente que el público objetivo de esta parte de la plataforma son dos tipos de usuario diferentes: por un lado, aquel usuario experto en un dominio pero no necesariamente tiene conocimientos de programación (se asume que no los tiene), y por otro lado aquel usuario habituado a usar herramientas de desarrollo (Eclipse, forjas, verificadores, etc.).

• Uno de los puntos clave para el éxito de la plataforma es un desarrollo ágil. Esto no sólo incluye que el entorno de mash-up sea ágil, sino que, como se indica en los requisitos, se pueda integrar con otros entornos ya existentes facilitando el trabajo a desarrolladores más experimentados que podrán implementar recursos extremadamente complejos.

Partiendo de la lista de requisitos inicial y analizando la tabla de la sección anterior, se extrae la siguiente lista de características deseables en el entorno de desarrollo de EzWeb:

	EzWeb
Interfaz Web	Sí
Interfaz Standalone	Sí
Depuración visual	Sí
Nivel mínimo del usuario	Básico
Indicación de puntos de anclaje	Sí
Mashup basado en componentes	Sí
Código	Sí
Test en plataforma	Sí
Control de versiones	Sí
Asistentes	Sí

Conclusiones

En este documento se han analizado concisamente distintos entornos de desarrollo, contrastando las ventajas que cada uno aporta respecto de los otros. También se ha hecho una extracción de características esperables en la plataforma, tomando aquellas que se han encontrado en cada uno de esos entornos. Por último, se ha hecho una partición de dos tipos de usuario diferentes que se han identificado, para los que se deberían proporcionar distintas herramientas:

• Usuario básico: su entorno de desarrollo debe ser simple siendo Automator^[6] una referencia digna de analizar. El entorno de usuario básico sería completamente visual, con un uso masivo del ratón.
• Usuario avanzado: El usuario podrá seleccionar un modo avanzado de interfaz de usuario en el cual la interfaz se parecerá más a un entorno de desarrollo tradicional permitiendo en última instancia la edición de código. El entorno de usuario avanzado es visual pero el usuario tendrá la posibilidad de acceder a los lenguajes internos para la composición de recursos. Además, requiere el uso de herramientas que pueda integrar con otros entornos de desarrollo.

Es interesante reseñar, sobre todo de cara a decisiones que se deban tomar en fases posteriores, que los usuarios no necesariamente caerán en una u otra categoría, sinó que un usuario puede no ser básico ni avanzado, querer usar código pero no herramientas avanzadas ni integrarlo en su propio entorno de desarrollo, etc. Para ajustarse a los usuarios y a sus conocimientos (e incluso a su contexto), la interfaz podría hacerse adaptativa, tanto siguiendo un modelo simple^[22] como uno más complejo^[23].

Diseño y Especificaciones abiertas del Entorno de Desarrollo

En este documento se analizan los requisitos de desarrollo que se derivan de cada tipo de recursos. En función de eso, se extraerán una serie de funcionalidades que se deben proporcionar, y se dará un primer diseño de las herramientas que compondrán el entorno.

Desarrollo de contenidos y servicios

Los contenidos son fuentes de datos, que se supone actúan como enlace entre el mundo exterior y la plataforma EzWeb. Un recurso sin vista que tiene entradas es un servicio, si sólo tiene salidas es un contenido. El desarrollo de ambos tipos de recursos es muy similar, tanto que las dudas y necesidades que surgirán serán las mismas. Tanto los contenidos como los servicios se pueden crear o bien en código (para aquellos más básicos), o bien como composición (mash-up) de otros.

Para fases posteriores se deberían analizar los siguientes aspectos:

• Introducción de elementos de control de flujo de datos. El control de flujo podría ser utilizado para generar contenidos por composición, pero no está claro si forzaría a la introducción manual de código o si otros recursos (por ejemplo, servicios) podrían actuar como dichos elementos de control.
• Si el sistema hace la distinción entre contenidos y servicios, puede que sea necesario avisar al usuario (e incluso impedirle utilizar el gadget) en caso de que genere un contenido que no se comporta como tal.
• Debería existir alguna forma de indicar si una salida o entrada de un componente interno se convierte en salida o entrada del componente completo o si por el contario se puede ignorar. Para el caso de las salidas, podría asumirse que cualquier salida no conectada a nada se convierte en salida del recurso creado por composición, y se puede anular conectándola a un servicio sumidero (con una entrada y sin salidas).
• No está claro cómo se podría hacer depuración de un contenido o de un servicio sin instanciarlo en un entorno operacional o como parte de un gadget. En el caso de los contenidos, una opción sería que al ejecutarlo en el entorno de desarrollo se puedan examinar todas sus salidas. En el caso del servicio, para poder depurarlo sería necesario poder proporcionar entradas, bien en forma de recursos que caen fuera de aquel que se está diseñando (y por tanto no son incluidos al final), bien asignando específicamente valores a entradas. En cualquier caso el sistema necesita un mecanismo artificial para depurar contenidos y servicios.

Desarrollo de gadgets

Los gadgets se diferencian de contenidos y servicios en que estos últimos no tienen una vista. Los gadgets también pueden actuar como transformadores y fuentes de datos, y pueden ser avisados de eventos o generarlos. Nótese que en este aspecto las decisiones tomadas en otros puntos son especialmente relevantes, en concreto, el hecho de que los gadgets tengan entradas, salidas, signals, slots, o los mecanismos de comunicación que se consideren oportunos.

En este caso se asumirá que se tendrán los cuatro tipos, que entradas y salidas llevan datos, y que signals y slots no los llevan (sólo llevan información de eventos sin parámetros). Bajo esta suposición, el desarrollo de gadgets no introduce, a nivel de plataforma, ninguna complicación añadida. El encadenado de entradas y salidas ya era necesario en fases anteriores. El encadenado de signals con slots debe seguir el mismo esquema (si bien es cierto que el encadenado de entradas y salidas podría ser automático en algunos casos y el de signals y slots, de no estar tipados, no lo sería).

En caso de que no haya diferencia entre signals/slots y entradas/salidas, todo se simplifica, ya que un gadget se caracteriza simplemente por ser un recurso con vista.

La depuración de gadgets no es más compleja que la depuración de servicios y contenidos, y a menudo será más simple por poder ejecutar el gadget sin tener que proporcionar fuentes artificiales de datos. En cualquier caso, pueden tener entradas y salidas y se debe permitir el testeo proporcionando parámetros al igual que para otros recursos.

Entorno de desarrollo de recursos

Herramientas de desarrollo

La plataforma proporciona un conjunto de herramientas de desarrollo que se pueden utilizar para analizar, compilar y depurar el código de los gadgets. El objetivo de estas herramientas es que la mayor parte de los desarrolladores están habituados a utilizar un entorno de desarrollo concreto, por lo que generaría rechazo forzarles a utilizar otro entorno de desarrollo nuevo (y que no esté adaptado a sus necesidades).

Todas estas herramientas standalone deben ser, en la medida de lo posible, manejables por línea de comandos, de forma que se puedan integrar con el mayor número de plataformas.

El conjunto de herramientas que se debe proporcionar es el siguiente:

• Compilador ó Analizador de código/recurso. Se encarga de hacer el análisis sintáctico y semántico del código (hasta donde sea posible).
  • Si el análisis resulta correcto, podría no generarse nada o bien generarse ficheros intermedios u objeto, en función del formato final que se decida para los recursos o de si cierta información de compilación podría ser útil en fases de depuración o de ejecución.
• Cargador. Se encarga de ejecutar un recurso con unas entradas dadas y de informar acerca de los valores de las salidas. Aunque debería analizarse en profundidad, a priori parece que sólo sería aplicable a contenidos y servicios (por no tener vista).
• Depurador. Similar a cualquier depurador, permite ejecutar un recurso pausando la ejecución, examinando el valor de una variable intermedia, etc. Nótese que esto no es un depurador de Javascript o del cualquier otro posible lenguaje objeto, sinó un depurador del recurso. Por tanto, aunque se podría utilizar un depurador de otro lenguaje por debajo, debería haber una capa que relaciona las variables en lenguaje objeto con las del recurso tal como fueron especificadas por el desarrollador.
• Empaquetador. Se encarga de tomar todos los ficheros del gadget (si es que existen más de uno, lo cual es previsible que pase en algún momento) y almacenarlos en un único fichero. Este debería ser el fichero que toman los depuradores, cargadores, y la plataforma online para cargar el gadget. Sería similar a un fichero jar en Java que incluye un Manifest, está firmado (opcionalmente), etc.
• Sincronizador. Toma un fichero de recurso y lo envía a un servidor. La idea es que el usuario pueda enviar el nuevo recurso a su paleta sin tener que usar una aplicación gráfica para ello. Nótese que el servidor no será necesariamente uno de Ezweb, ya que según los requisitos de la plataforma Lite, los gadgets podrían estar instalados en una máquina sin acceso a internet.

Integración con entornos de desarrollo

Otro de los requisitos (derivado de un target de la herramienta) es su integración con entornos de desarrollo existentes. Deberían generarse al menos facilidades para las siguientes herramientas:

• Emacs: modo de edición adaptado (scripts de coloreado de código, scripts de marcado de sintaxis incorrecta, y menúes y acciones asociadas a las herramientas descritas en el apartado anterior).
• Vim: scripts de coloreado de código, scripts de marcado de sintaxis incorrecta.
• Eclipse^[24]: Además de lo descrito anteriormente, para Eclipse se podría proporcionar un plugin que incluya toda la funcionalidad existente en la plataforma web. Esto incluiría frontends para las funcionalidades proporcionadas por las herramientas descritas en el apartado anterior, posibilidad de composición visual de recursos, depuración, etc. (ver siguiente sección para una descripción detallada).

Diseño visual

Descripción de la plataforma de desarrollo visual

El entorno de desarrollo visual tendrá dos partes principales (ver figura), la fuente de recursos, que permite selecionar aquellos recursos que se desean utilizar al crear otros por composición, y el área de diseño, en la que se componen visualmente, se escribe el código y se depura.

Partes principales de la interfaz

Fuente de recursos

La fuente de recursos se encarga de proporcionar al usuario recursos que puede utilizar para su diseño. Estos pueden provenir de su paleta o del propio universo (universo de gadgets es una terminología habitual en Netvibes para referirse a conjuntos o categorías de los mismos, en este caso nos referimos a el conjunto completo de gadgets disponibles en la plataforma). Aunque se pudiese argumentar que debe añadirlos a su propia paleta antes de poder trabajar con ellos, parece que desde el punto de vista de la usabilidad no sería conveniente, al menos no que deba hacerlo conscientemente. Sí podría tener sentido que todo recurso que se usa quede añadido a la paleta, aunque la contaminaría con elementos básicos que nunca llegaría a usar como tales en el entorno operacional, sinó sólo como partes de otros más complejos. Por ello se recomienda que los recursos no deban estar incluidos en la paleta y que, cuando se construya uno por unión de otros complejos, no se añada cada parte por separado a la misma, sino el recurso final como un todo.

La disposición de la parte de fuentes de recursos que se puede ver en Automator^[6] parece la más apropiada y por tanto se sugiere utilizar una esencialmente igual, que se constituye de:

• Listado de categorías. Incluye tres categorías principales: paleta (gadgets que el usuario ha añadido manualmente a su paleta), universo (listado completo de recursos disponibles en la plataforma) y listas inteligentes (recursos organizados jerárquicamente que contiene controles básicos, de flujo, complejos y gadgets, y que pueden ser creadas en función del contexto del usuario). Cada una de estas categorías principales podrá tener varias subcategorías. Nótese que un mismo recurso puede aparecer en más de una categoría. Estas categorías y sus subcategorías son simplemente una forma de organizar los gadgets del catálogo. Todos los gadgets que existen en él deberían aparecer en el universo. Las listas inteligentes deben facilitar la navegación por el mismo en función del contexto de desarrollo, por ejemplo, para permitir encontrar un gadget dependiendo de sus tipos, de otros gadgets usados en el recurso actualmente desarrollado, etc.
• Recursos de categoría: listado de recursos existentes en la categoría actual.
• Descripción de recursos: información del recurso seleccionado actualmente, que pueda ser relevante para el usuario a la hora de decidir si se ajusta a lo que está buscando.

Área de diseño

El área de diseño es la zona donde el usuario instancia los recursos para construir el suyo propio. Se divide en tres paneles: diseño visual (zona en la que puede diseñar visualmente arrastrando y soltando recursos), código (zona en la que puede ver el código actual del recurso, por si decide modificarlo a mano, o crear un recurso básico), y pruebas (en la que puede ver el recurso en funcionamiento, lo que sería un previo del recurso, bien en un entorno de ejecución aislado, bien en un clon del entorno operacional del usuario). Los tres paneles deberán estar sincronizados, de forma que una modificación en uno de ellos se refleje en los demás.

Además de los paneles, la zona de diseño contendrá secciones para proporcionar y obtener otro tipo de información sobre el recurso que se está creando, como los errores actuales, una descripción del mismo, etc, control de versiones, etc.

La creación de recursos que requieran algoritmia se podrá hacer siguiendo un estilo similar al de Mindscript^[25], (ver imagen a continuación). Para ello, la lista de recursos que se proporcione al usuario debe incluir algunos que implementen las acciones más básicas con las que se pueda conseguir este efecto de programación visual.

Si finalmente las entradas y salidas de los recursos están tipadas, se podría comprobar qué entradas son compatibles con qué salidas (independientemente de que la comparación sea por nombre o estructural). De esta forma, el sistema indicaría al usuario qué entradas son compatibles con la salida que intenta enlazar. Si éste seleccionase una comunicación incompatible, el sistema debería indicar la situación anómala detectada y proponer soluciones (que podrían ser filtros de conversión o simplemente la eliminación de dicho canal).

Sin embargo, algunos autores sigieren que se aplique una tendencia a "perdonar" al usuario (Pág. 219, ^[26]). En esta plataforma se traduciría en que, tanto en la parte visual como en la de código, los errores sean marcados, pero en ningún caso mostrarán mensajes al usuario que bloqueen la edición o que le fuercen a solucionar de manera inmediata.

Código

La zona de código está sincronizada con la zona de desarrollo visual en tiempo real (desde el punto de vista del usuario), y permite al usuario modificar el código final del recurso al más bajo nivel. Esta zona incluye un editor en el que se muestra el código del recurso completo, e incluye ciertas funcionalidades habituales en los entornos de programación, como:

• Coloreado de código de acuerdo con la sintaxis^[27].
• Resaltado de errores^[26][27].
• Alineación, tabulación, comentar zonas de código, folding^[28], etc.

El documento ^[28] es una referencia completa de funcionalidades que incluyen distintos editores, y se recomienda a la hora de decidir cuáles se deben incluir finalmente.

Además, el sistema debe permitir navegar por las distintas partes del proyecto, lo cual se puede hacer por ficheros (en caso de haber varios) y en unidades significativas (recursos, funciones,...). Si se busca que la plataforma web sea realmente utilizada para creación de recursos complejos, es esencial que la navegación sea potente y no se base sólo en una división del recurso por archivos.

Depuración

Como parte del área de desarrollo se encuentra la depuración del recurso implementado. El propio entorno debe permitir probar el recurso sin tener que incluirlo en la paleta de usuario e integrarlo en su entorno operacional. La depuración podría ser completamente visual, marcando en cada momento qué parte del recurso se está ejecutando. Además, la detección de errores (tanto en tiempo de diseño como de ejecución) debe no detener la fase en curso, sinó que se dará la opción a continuar mientras sea posible.

Además, también sería interesante que se pueda consultar el estado de un canal de comunicación, o de una fuente de datos, tanto en la parte de código como en la visual, y también (similar a la marca de línea actual en una ejecución paso a paso) se restaltan los recursos que actualmente están siendo ejecutados (al igual que Automator^[6]).

Otras funcionalidades

Asistentes

El objetivo de los asistentes es guiar paso a paso al usuario (también se conocen como wizards^[29]). A pesar de la obvia ayuda que representa para el usuario de nivel básico, los asistentes pueden resultar incómodos para aquellos usuarios que saben cómo utilizar la plataforma sin ellos, les hacen sentirse limitados y perder la referencia de dónde se encuentran.

En cualquier caso, la interfaz debe ser lo suficientemente sencilla como para que no sean estrictamente necesarios, por lo que en esta etapa no se van a sugerir asistentes concretos. Sólo se introducirían si en el futuro se detectase que alguna tarea requiere conocimientos avanzados que el usuario objetivo probablemente no tenga, y siempre bajo el criterio de que la tarea sea lo suficientemente compleja como para que el usuario no necesariamente sea capaz de repetirla una vez aprendida.

Ciclo de vida

Existen plataformas que guían al usuario sobre los pasos que tiene que llevar a cabo en el desarrollo de los gadgets^[9]. Si se identifica un proceso a seguir para EzWeb, podría crearse una guía similar en esta plataforma. Si, además, se decidiese añadir asistentes al sistema, estos debería seguir los pasos marcados por el ciclo de vida de diseño del recurso.

Aunque el usuario siga una serie de pasos marcados, en algún punto modificará su recurso para añadir nuevas funcionalidades. Para que pueda volver atrás en esos cambios y recuperar diseños anteriores, se implementará un control de versiones básico.

El control de versiones que se pretende tener en esta plataforma es mucho más simple que el que podemos encontrar en plataformas de propósito más general como ^[30] ó ^[31].

La siguiente es una sugerencia de lista de requisitos del sistema de control de versiones y gestión del ciclo de vida:

• Todas las versiones de un recurso tienen un número que las identifica. La forma de crear este número no la puede elegir el usuario, sinó que es la plataforma la que fija el esquema de nombrado. Con esto se evita al usuario tener que prestar atención al esquema de nombrado de versiones, manteniendo la simplicidad que se exige en toda la plataforma.
• El sistema incrementa el número de versión siempre que se guarda el recurso y ha habido cambios respecto a un estado anterior, con lo que se mantiene la coherencia. Además, el hecho de no poder volver atrás en los números de versión hace que se tenga la garantía de que un mismo recurso con la misma versión se refiere exactamente a la misma implementación.
• El usuario puede decidir incrementar el número de versión de un recurso forzosamente, como forma de marcar una diferencia más importante.
• El sistema permite añadir ciertos sobrenombres a las versiones, como alfa, beta, o incluso un alias.
• En caso de que el usuario vuelva atrás en una versión y realice un cambio (abriendo una nueva rama en la evolución del recurso), el número de versión que se aplicará será mayor que cualquier de los números de versión asociadosal mismo recurso en cualquiera de sus ramas.

Diseño de las herramientas

Como se ha visto en los apartados anteriores, existen funcionalidades que se proporcionan tanto a través de la plataforma web como mediante herramientas stand-alone. Es por ello que se sugiere una implementación guiada por la siguiente jerarquía:

• Nivel de servidor. Funcionalidades implementadas directamente en servidores porque es donde debe residir el control.
• Librerías. Realizan las funcionalidades reales como análisis estático, compilación, depuración, empaquetación, etc. También son el puente de comunicación con el nivel de servidor.
• Frontends. Son capas de unión entre el nivel de usuario y las librerías. Existen tres frontends: el de las herramientas stand-alone, el frontend integrado con otros entornos de desarrollo (Eclipse, Emacs,...), en el gráfico denominado plugins, y el integrado en la plataforma web de desarrollo.

Nótese que el la mayor parte de las funcionalidades deberían estar a nivel de servidor o de librerías. Los frontends no deberían copar gran parte de los esfuerzos de desarrollo. Sin embargo, podría llegar a considerarse que los esfuerzos en un frontend específico podrían ayudar a educir nuevos requisitos no contemplados o en otras áreas del proyecto. En este aspecto, actualmente no habrá ningún desarrollador interno que utilice las herramientas proporcionadas en el entorno. Además, la interfaz del catálogo, la definición y la interfaz de gadgets y otras partes del proyecto aún no están fijadas y son susceptibles de ser modificadas en un futuro próximo. Por lo tanto, se debería centrar la atención en producir un frontend web de la herramienta, ya que los backends sufrirían muchos cambios en el futuro y los demás frontends no serían aprovechados. Este frontend debería ser, inicialmente, muy básico (de hecho, debido a la simplicidad de Automator, podría tomarse como una guía a seguir), pero teniendo en cuenta los puntos en los que se querrá ampliar la herramienta con las funcionalidades comentadas en el documento D 3.5.1 Informe Científico Técnico del Entorno de Desarrollo. Por ello, el paso inicial que deberá ser refinado en etapas sucesivas sería definir las capas que lo compondrán, de forma que los cambios en interfaces definidas en otros entregables afecten lo más mínimo al entorno de desarrollo en el futuro. También habrá que ser cuidadoso a la hora de definir las interfaces de los componentes de este entorno, no sobrepasándose en las operaciones permitidas pero sin olvidar que en algún momento se deberán proporcionar, por lo que las estructuras de datos utilizadas deben contemplar que los valores que se puedan necesitar en el futuro sean fácilmente computables.

Notas

Existen una serie de funcionalidades que se podrían incluir en el entorno de desarrollo. Aunque algunas parecen interesantes, no se ha encontrado justificación suficiente para aceptarlas o descartarlas, por lo que se incluyen aquí con el objetivo de que sean evaluadas más adelante.

• Puntuación del recurso por parte de otros usuarios, y poder recibir comentarios de él.
• Conocer los forks^[32] de un recurso, para saber si hay implementaciones mejores que la nuestra o saber qué han incluido otros.
• Conocer recursos que lo usan.
• Conocer recursos usados, actualizaciones de recursos usados y problemas encontrados con los recursos usados.
• Cómo poner un recurso a disposición de otros usuarios. Posibilidades:
  • La plataforma permite publicar.
  • El recurso se añade a la paleta del usuario y desde allí se puede publicar.
  • El recurso se añade a la paleta del usuario y desde allí se puede compartir.
• La configuración forma parte del recurso (la configuración por defecto), por lo que no debería haber interacción con el módulo de persistencia.
• Proporcionar instaladores para distintas distribuciones (utilizar la nativa de la distribución, y no forzar al usuario a usar un método ah-hoc para EzWeb).
• Estudiar la posibilidad de que la depuración se implemente mediante un plugin de Firefox^[33] de forma similar a la solución proporcionada en Aptana^[16].

Referencias

1. ↑ Wikipedia - Google Gadgets, Gadgets and Plug-ins, http://en.wikipedia.org/wiki/Google_Gadgets#Gadgets_.26_Plug-ins
2. ↑ ^{2,0 2,1} Netvibes, http://www.netvibes.com
3. ↑ ^{3,0 3,1} Wikipedia - Signals and slots, http://en.wikipedia.org/wiki/Signals_and_slots
4. ↑ Wikipedia - Resource (Web), http://en.wikipedia.org/wiki/Resource_%28Web%29
5. ↑ Yahoo! Pipes - Editing Pipe http://pipes.yahoo.com/pipes/pipe.edit
6. ↑ ^{6,0 6,1 6,2 6,3} Automator, http://www.apple.com/macosx/features/300.html#automator
7. ↑ Wikipedia - Automator, http://en.wikipedia.org/wiki/Automator_(software)
8. ↑ QT Designer - Trolltech http://trolltech.com/products/qt/features/designer
9. ↑ ^{9,0 9,1} Dashcode http://developer.apple.com/tools/dashcode/
10. ↑ Create Google Gadgets http://www.google.com/apis/gadgets/
11. ↑ Make your own Gadget. iGoogle http://www.google.com/ig/gmchoices?hl=en
12. ↑ Google Gadgets Editor: Get Started Now, http://www.google.com/apis/gadgets/gs.html#Scratchpad
13. ↑ Google Mashup Editor, http://editor.googlemashups.com/
14. ↑ Widgetarium http://projects.gandreas.com/widgetarium/
15. ↑ Spket IDE http://www.spket.com/
16. ↑ ^{16,0 16,1} Aptana IDE (Eclipse) http://www.aptana.com/
17. ↑ Widgetryworkshop (under production) http://widgetryworkshop.com/
18. ↑ AJAX Toolkit Framework (Eclipse) http://www.eclipse.org/atf/
19. ↑ ATF Features Overview http://www.eclipse.org/atf/features/index.php
20. ↑ Open Kapow http://openkapow.com/
21. ↑ QEDWiki http://services.alphaworks.ibm.com/qedwiki/
22. ↑ Try xine-Based Video Players http://proquest.safaribooksonline.com/0596100760/linuxmmhks-CHP-3-SECT-10#snippet
23. ↑ Adaptative User Modeling for Personalization of Web Contents. Alberto Díaz and Pablo Gervás. Adaptative Hypermedia and Adaptative Web-Based Systems
24. ↑ http://www.eclipse.org/ Eclipse.org Home
25. ↑ Minscript Home Page http://mindscript.familjemarknaden.se/
26. ↑ ^{26,0 26,1} J. Tidwell. Designing Interfaces. O'Reilly & Associates, Inc, 2006.
27. ↑ ^{27,0 27,1} Wikipedia - Syntax highlighting http://en.wikipedia.org/wiki/Syntax_highlighting
28. ↑ ^{28,0 28,1} Wikipedia - Comparison of text editors http://en.wikipedia.org/wiki/Comparison_of_text_editors
29. ↑ Wikipedia - Wizard (software) http://en.wikipedia.org/wiki/Wizard_%28software%29
30. ↑ Subversion http://subversion.tigris.org/
31. ↑ Mercurial, http://www.selenic.com/mercurial/
32. ↑ Fork (software development) http://en.wikipedia.org/wiki/Fork_(software_development)
33. ↑ Firefox web browser http://www.mozilla.com/firefox/