Entorno de Desarrollo

Personal asignado

• Responsable del módulo:
  • Iván Pérez (IMDEA Software), iperez@babel.ls.fi.upm.es
• Desarrolladores
  • No definido todavía

Resumen

El objetivo de este documento es analizar requisitos de un entorno visual de desarrollo de recursos, abordar las soluciones ya existentes, contrastando algunas de sus ventajas e inconvenientes. Además, se estraen 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.

1. 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 sin llegar a tomar decisiones de diseño o de implementación. 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 entorno de desarrollo 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 ([2], también denominados widgets [9] en algunas plataformas), signal ([1]), slot ([1]), recurso ([3]) y entorno operacional.

En la siguiente sección se enumeran los requisitos iniciales y se hace una primera profundización en los mismos. En la tercera sección analizan varios entornos de desarrollo que se han considerado destacados, contrastando aquellas características que destacables.

NOTA: ¿Qué más?

2. Requisitos

Los requisitos que se esperan que cumpla entorno de desarrollo son los siguientes:

• Permitir la construcción de Recursos complejos a expertos de dominio y personal cualificado.
• Proporcionan 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.
• Creación de recursos desde cero o por composición de otros existentes (vía mashup avanzados).
• Para un gran número de personas con conocimiento limitado: supone minimizar la programación y los algoritmos y favorecer las especificaciones de alto nivel basados en elementos semánticos.
• 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.)
• Cubriendo etapas del ciclo de vida (validación, verificación, versiones, etc.)

2.1 Suposiciones realizadas en este documento

En la lista de requisitos 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 que es experto en un dominio pero no necesariamente tiene conocimientos de programación (se asume que no los tiene), y por otro lado aquel usuario que sí está 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.

Por ello, parece adecuado tener dos interfaces de desarrollo. Una de ellas será accesible a través de la plataforma EzWeb (sin necesidad de ningún programa adicional), la otra estará integrada con otros editores ya existentes (por ejemplo, Eclipse) o en forma de utilidades de línea de comandos. Ambas deben tener las mismas funcionalidades, si bien tiene sentido que algunas facilidades (asistentes,...) sólo estén disponibles en la plataforma orientada al usuario no experto.

Así, la división que se debe realizar es la siguiente:

• Entorno de desarrollo de la plataforma EzWeb.
• Herramientas integradas en otros entornos de desarrollo ya existentes.

NOTA: Esta decisión se puede y debe justificar con referencias.

3. Entornos de desarrollo

3.1 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 nuestro caso debe permitirse que se introduzca código para los recursos, sobre todo para crear aquellos más básicos. Sin embargo es primordial permitir que el entorno de desarrollo sea lo más visual posible, por lo que inicialmente centraremos nuestra atención en aquellos que buscan o han alcanzado ese objetivo.

• Yahoo Pipes ([6]) es sin duda el entorno más (user-friendly). Permite diseñar gadgets sin necesidad de escribir código, simplemente a base de conectar otros gadgets más elementales. Un ejemplo claro de potencia y simplicidad que ofrece se muestra en la siguiente imagen.
  
  ^{Captura de pantalla de Yahoo! Pipes}

• Automator ([4], [5]). 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 se lee "[...] Automator [...] requires no expertise in these (programming) languages whatsoever".
  
  ^{Captura de pantalla de Automator}

• Entorno de desarrollo de QT - QT Designer ([7]). Aunque sí se incluye código para manejar los eventos, se pueden combinar los controles encadenando slots y signals de unos con otros.
  
  ^{Captura de pantalla de QT Designer}

3.2 Otros entornos de desarrollo

Existen otras plataformas similares a la que se intenta implementar aquí que también permiten diseñar gadgets, sin embargo no se realizan de forma visual. Entre ellas encontramos:

• Google Gadgets ([8]). 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, [17]). Los usuarios pueden usar cualquier editor para el desarrollo, Google permite usar su propio editor ([10]), que incluye vista previa del gadget, pero no sigue siendo necesario escribir código en un lenguaje de programación. Para la construcción de gadgets complejos está desarrollando Google Mashup Editor ([11]).

• Netvibes ([9]). 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.

3.3 Resumen de características

NOTA: Ampliar y revisar la siguiente tabla.

La siguiente tabla resume algunos aspectos analizados de los distintos entornos, incluyendo características destacables de algunos de ellos:

	Yahoo Pipes	QT Designer	Automator	Netvibes	Google Gadgets
Interfaz Web	Sí	No	No	Sí	Sí
Plataforma 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í

4. Identificación de requisitos específicos

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:

	Yahoo Pipes
Interfaz Web	Sí
Plataforma Standalone	Sí (integrada)
Depuración visual	Sí
Nivel mínimo del usuario	Bajo
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í

Las partes principales del entorno serán, como se desglosa en la figura, las siguientes:

• Entorno operacional de desarrollo (dividido en 3 paneles: visual, código y test). Zona de mensajes, donde el usuario recibe mensajes de depuración, de errores, etc. Podría evitarse si la depuración es completamente visual.
• Listado de Gadgets (dividido en categorías, gadgets y descripción). Tiene tres secciones principales: "Mis gadgets, Mi paleta, y Universo".

^{Partes principales de la interfaz}

Además, tenemos dos tipos de usuarios posibles que requieren herramientas diferentes: * Usuario básico: El entorno de desarrollo de usuario debe ser lo más simplista posible. De hecho, debería tender a parecerse a Automator. El entorno de usuario básico se maneja casi completamente con el ratón. * Usuario avanzado: El usuario podrá seleccionar un modo avanzado de interfaz de usuario ([17]) en el cual la interfaz se parecerá más a un entorno de desarrollo tradicional, mostrando la opción de código. El entorno de usuario avanzado se puede manejar casi completamente con el ratón, pero permite el uso de teclas y combinaciones de teclas para realizar las acciones más rápidamente.

5. Diseño visual

5.1 Descripción de la plataforma

En este apartado se detallan aspectos de la plataforma de diseño visual. En concreto, la plataforma se dividirá en dos partes:

• Fuente de recursos.
• Area de diseño.

5.1.1 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). 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, sin embargo, 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ó 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 fuente de recursos se divide en tres secciones: 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).

Listado de Recursos La zona de listado tendrá como objetivo ofrecer al usuario listados de recursos que puede utilizar para el desarrollo. Estará dividida en tres partes (al igual que otras plataformas (dar referencias)):

• Listado de categorías: aquí es donde se tiene en cuenta la información de contexto para sugerir recursos. Existen categorías "Inteligentes" y un universo total de gadgets.
• Recursos de categoría: listado de recursos pertenecientes a la categoría actual.
• Descripción de recursos: información del recurso seleccionado actualmente, entre la que se puede incluir información del recurso general, información de cómo usarlo, de recursos relacionados, etc.

NOTA: Juntar con el apartado actual.

5.1.2 Á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 en un entorno operacional real). 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.

La creación de recursos que requieran algoritmia se podrá hacer siguiendo un estilo similar al de Mindscript ([18]), que se muestra en la 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.

^{Captura de pantalla de Mindscript}

Los recursos, tal y como se ha indicado en

NOTA: referencia a la fuente.

tienen sus entradas y salidas tipadas. Esto hace que se pueda comprobar qué tipos son compatibles y cuales no (independientemente de que la comparación sea por nombre o estructural). Por ello, el sistema sólo dejará que se comuniquen entradas y salidas compatibles entre recursos. Cuando el usuario indique una comunicación incompatible, el sistema deberá 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, nótese que tanto en la parte visual como en la de código se debe "perdonar" al usuario (Pág. 219, [12]), en el sentido de que un error no debe suponer que se sienta penalizado. Por tanto, las zonas visual y de código marcarán los errores, pero en ningún caso mostrarán mensajes al usuario que bloqueen la edición o que le fuercen a solucionar un problema inmediatamente.

5.2 Código

La zona de código está sincronizada con la zona de desarrollo visual en tiempo real, y permite al usuario no sólo crear aplicaciones más complejas sinó aprender con ejemplos. 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 ([20]).
• Resaltado de errores (Pág. 219, [12]; [20]).
• Alineación, tabulación, comentar zonas de código, folding ([21]).

El documento [21] es una referencia completa de funcionalidades que incluyen distintos editores.

5.3 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 debe 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 intentará que continúe mientras se pueda.

El usuario tendrá un panel de depuración en el que podrá realizar las siguientes acciones: * Arrancar, pausar y detener la ejecución. * Consultar el estado de un canal de comunicación, o de una fuente de datos.

En caso de que el usuario ponga el foco en el panel de código o en el de diseño, se marcarán ([4]) los recursos que actualmente están siendo ejecutados.

5.4 Asistentes

El objetivo de los asistentes es guiar paso a paso al usuario (también se conocen como wizards [18]). Existen opiniones contrarias respecto a si se deben o no usar asistentes en las aplicaciones. A pesar de la obvia ayuda que representa para el usuario de nivel básico, los asistentes resultan incómodos para aquellos usuarios que saben cómo utilizar la plataforma sin ellos, le hacen sentirse limitado y perder la referencia de dónde se encuentra.

En cualquier caso, la interfaz debe ser lo suficientemente sencilla como para que no sean estrictamente necesarios, y sólo se introducirían asistentes si en el futuro se detectase que alguna tarea requiere conocimientos avanzados que el usuario objetivo probablemente no tenga.

5.5 Ciclo de vida - Control de versiones

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 [22] ó [23]. Los requisitos que debe cumplir el sistema de control de versiones y gestión del ciclo de vida es el siguiente.

• 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.
• El sistema incrementa el número de versión siempre que se guarda el recurso y ha habido cambios respecto a un estado anterior.
• El usuario puede decidir incrementar el número de versión de un recurso forzadamente.
• El sistema permite añadir ciertos sobrenombres a las versiones, como alfa, beta, o incluso un alias.
• En todo caso el usuario puede volver atrás para comprobar qué ha cambiado.

NOTA: Estas notas deben ser eliminadas, o bien porque se descarten, o bien porque se muevan a otra sección (en ambos casos se debe justificar).

A. Notas

• Puntuación del recurso.
• 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.

Referencias

1. Wikipedia - Signals and slots, http://en.wikipedia.org/wiki/Signals_and_slots.
2. Wikipedia - Google Gadgets, Gadgets and Plug-ins, http://en.wikipedia.org/wiki/Google_Gadgets#Gadgets_.26_Plug-ins.
3. Wikipedia - Resource (Web), http://en.wikipedia.org/wiki/Resource_%28Web%29
4. Automator, http://www.apple.com/macosx/features/300.html#automator
5. Wikipedia - Automator, http://en.wikipedia.org/wiki/Automator_(software)
6. Yahoo! Pipes - Editing Pipe http://pipes.yahoo.com/pipes/pipe.edit
7. QT Designer - Trolltech http://trolltech.com/products/qt/features/designer
8. Create Google Gadgets http://www.google.com/apis/gadgets/
9. Netvibes http://www.netvibes.com/
10. Google Gadgets Editor: Get Started Now http://www.google.com/apis/gadgets/gs.html#Scratchpad
11. Google Mashup Editor http://editor.googlemashups.com/
12. J. Tidwell. Designing Interfaces. O'Reilly & Associates, Inc, 2006.
13. Visual Programming http://en.wikipedia.org/wiki/Integrated_development_environment#Visual_programming
14. Visual Programming language http://en.wikipedia.org/wiki/Visual_programming_language
15. Microsoft Robotics Studio http://msdn2.microsoft.com/en-us/library/bb483024.aspx
16. Try xine-Based Video Players http://proquest.safaribooksonline.com/0596100760/linuxmmhks-CHP-3-SECT-10#snippet
17. Make your own Gadget. iGoogle http://www.google.com/ig/gmchoices?hl=en
18. Minscript Home Page http://mindscript.familjemarknaden.se/
19. Wikipedia - Wizard (software) http://en.wikipedia.org/wiki/Wizard_%28software%29
20. Wikipedia - Syntax highlighting http://en.wikipedia.org/wiki/Syntax_highlighting
21. Wikipedia - Comparison of text editors http://en.wikipedia.org/wiki/Comparison_of_text_editors
22. Subversion http://subversion.tigris.org/
23. Mercurial http://www.selenic.com/mercurial/