Facultad de Matemática, Física y Computación
Carrera: Ingeniería Informática
Título:
Uso de La Plataforma de Cliente Enriquecido en el entorno de desarrollo Eclipse
Autores:
Yoel López Burgos
Frank Bermúdez Peña
Tutor:
Dr. C. Carlos E. García González
Lo importante no es cuanto hacemos, sino cuanto amor, cuanta
honestidad y cuanta fe
ponemos en lo que hacemos.
Madre Teresa de Calcuta.
DEDICATORIA
A mi madre, porque sin ella nada de esto hubiese sido posible. Es ella la
razón por la que vivo y por la que me esfuerzo cada día más.
A mi padre, pues a pesar de todo no puedo olvidar los buenos recuerdos
de mi infancia junto a él… y sin su ayuda hoy no tendría nada.
A mi hermanita, que ha estado todo el tiempo a mi lado apoyándome en
cada paso que doy y haciéndome saber que no estoy solo…
A mi sobrinito Brayan, el más pequeñito de casa, por quien todos
vivimos y que tanto nos hace reír…
A mis dos abuelos, Ramón y Ange, que aunque ya no estén aquí junto a
mí, viven en mi memoria.
A mis abuelitas, a mis tías y tíos, a mis primos, que más que familia, son
mi vida y sin ellos nada sería asi de maravilloso…
A todos mis amigos, que para mencionarlos necesitaría una tesis
completa para ellos y siempre han estado apoyándome.
Yoel
A mi hermano por quererme y apoyarme siempre incondicionalmente y
por ser mi faro guía.
A mi madre que con tanto amor me ha apoyado y por ser tan insistente
y comprensible conmigo.
A mi padre por darme fuerzas para seguir adelante y siempre guiarme
por el buen camino.
A mi abuela Edith por quererme tanto y bendecirme en todo momento.
A Betsy por estar a mi lado a lo largo del camino y brindarme todo su
amor y comprensión.
A mi familia y la de Betsy por estar a mi lado y ser tan especiales.
Frank
AGRADECIMIENTOS
A todos nuestros compañeros de aula, con quienes compartimos
muchísimos momentos...
A todos aquellos profesores que nos dieron clase o de alguna manera
han contribuido a nuestra formación.
A nuestras familias, pues sin su apoyo nada hubiese sido posible... sobre
todo por las dificultades por la que atravesamos...
A Abelito, por su comprensión y ayuda en todo momento.
Frank y Yoel
Síntesis
SÍNTESIS
En el presente trabajo se describe el procedimiento para desarrollar una
aplicación de cliente enriquecido, que tenga incorporado un editor gráfico de diagramas
Entidad-Relación generado con GMF, escrita con una sintaxis basada en XML, además
proporciona múltiples funcionalidades. En el mismo se realiza un estudio profundo de las
características que tiene una aplicación de este tipo y de sus principales componentes y
se realiza una selección de estos basado en su uso dentro del editor gráfico de esquemas
Entidad-Relación. Esta aplicación se desarrolla en un entorno de desarrollo flexible,
extensible e integrado como lo es la plataforma Eclipse y se basa en un modelo de
módulos o plug-ins dinámicos. La plataforma tecnológica RCP que se va a desarrollar
permite crear aplicaciones Java con una interfaz de usuario muy diferente a las demás
esto se debe a que se utiliza el estándar de Eclipse SWT (Standard Widget Toolkit). Por
otra parte se hace uso de JFace que es un conjunto de herramientas GUI de ventanas
independiente del sistema. JFace está diseñado para trabajar con SWT sin ocultarlo e
implementa un modelo-vista-controlador (MVC). Además, para fomentar las bases de la
interfaz de usuario de la aplicación, se hace uso del workbench o banco de trabajo, que es
el ambiente de desarrollo de Eclipse, el mismo hace que la aplicación sea fácil de escribir,
de escalar, de usar y que sea extensible.
Abstract
ABSTRACT
This paper describes the procedure for developing a rich client application, which has a
built-in graphics editor Entity-Relationship diagrams generated with GMF, written with a
syntax based on XML, and provides multiple features. This work also proposes a thorough
study of the features that an application of this type has and its main components .It is also
carried out a selection of such components based on their use within the graphic editor of
Entity-Relationship diagrams. This application is developed in a flexible development
environment, extensible and integrated platform such as Eclipse; and it is based on a model
of modules or dynamic plug-ins. The RCP technology platform that will be developed allow to
create Java applications with an unlike user interface. This is possible due to the use of the
standard Eclipse SWT (Standard Widget Toolkit). On the other hand, it makes use of JFace
which is a GUI toolkit of independent window system. JFace is designed to work with SWT
without hiding it and it implements a model-view-controller (MVC). In addition, it promotes the
basics of user interface of the application. It uses the workbench, which is the Eclipse
development environment, it makes the application easy to write, to scale, to use and to be
extensible.
Tabla de contenidos
TABLA DE CONTENIDOS
INTRODUCCIÓN .................................................................................................................................................................. 1
CAPÍTULO 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO
ECLIPSE” ............................................................................................................................................................................... 4
1. LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE. ....... 5
1.1 Introducción al entorno de desarrollo Eclipse ............................................................................................................ 5 1.1.1 Arquitectura de Eclipse .......................................................................................................................................... 6 1.1.2 Características de la herramienta Eclipse Galileo 3.5 .......................................................................................... 10 1.1.3 Otros componentes de Eclipse ............................................................................................................................. 11 1.2 La Plataforma de Cliente Enriquecido de Eclipse..................................................................................................... 12 1.2.1 Evolución de RCP en Eclipse .............................................................................................................................. 13 1.2.2 Conceptos básicos ................................................................................................................................................ 13 1.2.2.1 ¿Qué es plug-in? .............................................................................................................................................. 14 1.2.2.2 ¿Qué es SDK? ................................................................................................................................................. 17 1.2.2.3 Widget ............................................................................................................................................................. 17 1.2.2.4 Equinox OSGi ................................................................................................................................................. 18 1.2.2.5 La plataforma en tiempo de ejecución............................................................................................................. 19 1.2.2.6 Herramientas de SWT. .................................................................................................................................... 20 1.2.2.7 JFace................................................................................................................................................................ 21 1.2.2.8 El Workspace .................................................................................................................................................. 21 1.2.2.9 El Workbench.................................................................................................................................................. 22 1.2.2.10 Diferencias entre RCP y el Workbench de Eclipse ......................................................................................... 24 1.2.2.11 GMF ................................................................................................................................................................ 25 Conclusiones parciales ....................................................................................................................................................... 27
CAPÍTULO 2. “DESARROLLO DE APLICACIONES EN ECLIPSE UTILIZANDO RCP” ................................ 28
2. DESARROLLO DE APLICACIONES EN ECLIPSE UTILIZANDO RCP .................................................... 29
2.1 Selección de una plantilla RCP. .................................................................................................................................. 29 2.2 Comenzando una aplicación RCP. .............................................................................................................................. 31 2.3 Descripción de aspectos fundamentales del código generado por la plantilla. ............................................................ 36 2.3.1 La clase Application. ................................................................................................................................................. 37 2.3.2 La clase WorkbenchAdvisor. .................................................................................................................................... 38 2.3.3 La clase Perspective. ................................................................................................................................................. 38 2.3.4 La clase WorkbenchWindowAdvisor. ....................................................................................................................... 39 2.3.5 La clase ActionBarAdvisor. ...................................................................................................................................... 40 2.4 Descripción del proceso de ejecución de una aplicación en Eclipse RCP. .................................................................. 41 2.4.1 Configuraciones de ejecución.................................................................................................................................... 41 2.5 Incorporación del editor gráfico generado con GMF a la aplicación EditorgmfRCP................................................... 43 2.5.1 Incorporación de los plug-ins del editor gráfico a la lista de dependencias del proyecto. ......................................... 43 2.5.2 El editor “Modelo Diagram Editing”......................................................................................................................... 44 2.5.3 Las vistas “Outline” y “Properties”. .......................................................................................................................... 45 2.5.4 Personalización de la posición en la ventana de los elementos de la interfaz de usuario. ......................................... 46 2.5.5 El asistente “Modelo Diagram”. ................................................................................................................................ 46 2.5.6 Adicionando una acción a la barra de menú de la aplicación. ................................................................................... 47 2.5.7 Descripción del proceso de “Branding” de EditorgmfRCP. ...................................................................................... 48 2.5.8 Descripción de la definición del producto EditorgmfRCP. ....................................................................................... 48 2.5.9 Window Images. ........................................................................................................................................................ 51 2.5.10 Descripción de la personalización del ejecutable para la aplicación. ...................................................................... 51 2.5.11 Descripción del “Splash Screen”. ............................................................................................................................ 52 2.5.12 Descripción de “About Information”. ..................................................................................................................... 53 2.5.12.1Definición del contenido del diálogo “About”. ..................................................................................................... 53 2.5.13 Descripción del proceso de “Packaging” de EditorgmfRCP. .................................................................................. 54 2.5.14 Exportando EditorgmfRCP. .................................................................................................................................... 54 Conclusiones parciales ....................................................................................................................................................... 58
CONCLUSIONES ................................................................................................................................................................. 59
RECOMENDACIONES ....................................................................................................................................................... 60
REFERENCIAS BIBLIOGRÁFICAS ................................................................................................................................ 61
ANEXOS ................................................................................................................................................................................ 62
Introducción
1
INTRODUCCIÓN
El desarrollo de aplicaciones cliente ha pasado por un proceso de evolución
caracterizado por diversos tipos de aplicaciones como son: cliente pesado, cliente liviano y
cliente enriquecido.
El término "cliente pesado", se utiliza para una aplicación gráfica que se ejecuta en un
sistema operativo del usuario. Un cliente pesado suele tener una mayor capacidad de
procesamiento y es posible que tenga una interfaz gráfica sofisticada. Sin embargo, esto
conlleva un desarrollo adicional y suele ser una mezcla de la lógica de presentación
(interfaz gráfica) con la lógica de la aplicación (potencia de procesamiento). Este tipo de
aplicación suele instalarse en el sistema operativo del usuario y se debe instalar una
nueva versión cuando se realiza una actualización. Para solucionar esto, los
programadores de aplicaciones pesadas, por lo general, incorporan una funcionalidad que
se ejecuta al iniciar la aplicación y verifica un servidor remoto para saber si está disponible
alguna versión más nueva. De ser así, le indica al usuario que descargue e instale la
actualización.
El término "cliente liviano" (a veces llamado "cliente delgado"), en comparación con un
cliente pesado, se refiere a una aplicación a la que se puede acceder por una interfaz
Web, que se puede visualizar con un navegador en donde toda la lógica de la aplicación
se realiza en el lado del servidor. Por eso, al navegador a veces se le denomina cliente
universal. El hecho de que todo el procesamiento fundamental ocurra en el lado del
servidor, con la interfaz gráfica siendo enviada al navegador a cada solicitud, significa que
es muy flexible cuando realiza las tareas de actualización. Sin embargo, la aplicación debe
poder leer las diferencias a la hora de interpretar el código HTML por los diferentes
navegadores. También la ergonomía de la aplicación es limitada.
Los avances recientes en el desarrollo de herramientas de software han hecho posible
reducir la brecha mediante el desarrollo de aplicaciones que son más fáciles de
implementar y actualizar, y los navegadores que proporcionan una interfaz de usuario más
sofisticada con una mejor experiencia de usuario. Producto de este desarrollo ha surgido
un nuevo tipo de aplicación llamada cliente enriquecido (RCP, del inglés Rich Client
Platform).
Introducción
2
Un "cliente enriquecido" es un término medio entre el cliente liviano y el cliente pesado.
El objetivo del cliente enriquecido consiste en proporcionar una interfaz gráfica, escrita con
una sintaxis basada en XML, que proporciona funcionalidades similares a las del cliente
pesado (arrastrar y soltar, pestañas, ventanas múltiples, menús desplegables). Los
clientes enriquecidos también pueden realizar un procesamiento fundamental en el lado
del servidor. Seguidamente, los datos se envían con un formato de intercambio estándar,
al utilizar la sintaxis de XML (SOAP, XML-RPC), que después el cliente enriquecido
interpreta.
Existen varios entornos de desarrollo que le permiten a los usuarios crear aplicaciones
de cliente enriquecido, entre los cuales se pueden citar a Visual Basic, Borland Delphi,
Microsoft Visual Studio, NetBeans y Eclipse.
En el laboratorio de Bases de Datos del Centro de Estudio de Informática se ha
comenzado un proyecto para desarrollar un editor gráfico para el diseño de Bases de
Datos utilizando el modelo Entidad-Relación. Esta herramienta se está desarrollando en
Eclipse, por lo que resulta de interés que la misma exhiba facilidades de RCP sobre
Eclipse. El procedimiento para desarrollar una aplicación de cliente enriquecido en Eclipse
constituye la problemática a resolver en esta tesis.
El problema se puede concretar en las siguientes preguntas de investigación:
1. ¿Qué características tiene una aplicación de cliente enriquecido en Eclipse?
2. ¿Cuáles son las funcionalidades que ofrece una aplicación de cliente enriquecido?
3. ¿Cómo se incorporan estas características a una aplicación en Eclipse?
El objetivo general de la tesis consiste en establecer el procedimiento para desarrollar
aplicaciones de cliente enriquecido en el entorno de desarrollo Eclipse.
Para su cumplimiento el objetivo general se desglosa en los siguientes objetivos
específicos:
1. Hacer un estudio sobre las características que distinguen a una aplicación de
cliente enriquecido sobre Eclipse.
2. Implementar una aplicación de cliente enriquecido como caso de estudio.
Introducción
3
Para lograr los objetivos trazados se acometieron las siguientes tareas de investigación:
1. Estudio de las características de una aplicación de cliente enriquecido en Eclipse.
2. Desarrollar un caso de estudio como aplicación de cliente enriquecido.
3. Definir una plantilla para el desarrollo de la aplicación RCP.
4. Incorporar el editor generado con GMF a la aplicación RCP.
Justificación:
Este trabajo sienta las bases para el desarrollo de aplicaciones de cliente enriquecido
sobre el entorno de desarrollo Eclipse. En este sentido en el laboratorio de Bases de
Datos existe un proyecto de desarrollo de un editor gráfico de diagramas Entidad-
Relación, que una vez concluido se le desean agregar características de una aplicación de
cliente enriquecido. De esta manera los resultados de este trabajo serán de mucha utilidad
en la conclusión de ese proyecto.
4
CAPÍTULO 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
5
1. LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE
DESARROLLO ECLIPSE.
En este capítulo se exponen las principales características que distinguen a una
aplicación de cliente enriquecido sobre Eclipse y se destacan algunas de las ventajas que
ofrece el uso de esta tecnología. Se lleva a cabo una descripción de la arquitectura de
este entorno de desarrollo. Se realiza además un análisis de los principales componentes,
herramientas y tendencias tecnológicas de aplicaciones RCP.
1.1 Introducción al entorno de desarrollo Eclipse
Eclipse comenzó como un proyecto de IBM Canadá. Fue desarrollado por OTI
(Object Technology International) como reemplazo de VisualAge también desarrollado por
OTI. En noviembre del 2001, se formó un consorcio para el desarrollo futuro de Eclipse
como código abierto. En 2003, fue creada la Fundación Eclipse, una organización
independiente, sin ánimo de lucro, que fomenta una comunidad de código abierto y un
conjunto de productos complementarios, capacidades y servicios.
El entorno de desarrollo integrado (IDE, Integrated Development Enviroment) de
Eclipse emplea módulos (en inglés plug-ins 1) para proporcionar toda su funcionalidad, a
diferencia de otros entornos monolíticos donde las funcionalidades están todas incluidas,
las necesite el usuario o no. Este mecanismo de módulos es una plataforma ligera para
componentes de software. Adicionalmente Eclipse puede extenderse usando otros
lenguajes de programación como son C/C++ y Python, y trabajar con lenguajes para
procesadores de texto como LaTeX, aplicaciones en red como Telnet y Sistema de gestión
de base de datos. La arquitectura plug-in permite escribir cualquier extensión deseada en
el ambiente, como por ejemplo la Gestión de la configuración.
Para algunas personas, Elipse es un IDE con los rasgos característicos que se
esperan de un entorno de desarrollo como: editor, monitor de puesta a punto y el manejo
de proyectos con amplias posibilidades de personalización. Para otras personas, Elipse es
un marco de trabajo genérico para la integración de herramientas, proporcionando un
1 En el resto del informe se utilizará su aserción en inglés para hacer referencia a los módulos que extienden
la funcionalidad de una aplicación sin necesidad de recompilar de nuevo su código fuente.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
6
modelo extensible y flexible basado en plug-ins (Carlson, 2005). Ambas perspectivas son
válidas. Mientras la comunidad de Eclipse continúa su rápida expansión, otros usuarios la
verán en esta herramienta de modelación, aplicaciones para el manejo de reglas de
negocio, diseñadores de procesos de negocio, un entorno de desarrollo para sistemas
escritos en C++, entre otros tipos de aplicaciones.
1.1.1 Arquitectura de Eclipse
Debido al amplio rango de interpretaciones de Eclipse, resulta difícil presentar un
breve sumario sobre su arquitectura. La descripción más general es una vista abstracta
del entorno de desarrollo y ejecución para la creación y despliegue de plug-ins.
Alternativamente, se puede tener una vista funcional que describe a Eclipse como entorno
flexible, extensible e integrado (Gallardo et al., 2003).
El IDE de Eclipse es:
• Multi-plataforma: Los sistemas operativos que soporta Eclipse 3.0 son compatibles con
Windows, Linux (motif y GTK), Solaris, AIX, HP-UX, y Mac OSX.
• Multi-Lenguaje: Eclipse esta desarrollado utilizando el lenguaje Java, pero apoya la
creación de aplicaciones en Java, C/C++ y COBOL, se están desarrollando soportes
de lenguajes adicionales para Python, Perl, PHP y otros. Los plug-ins para Eclipse
deben ser escritos en Java.
• Multi-función: Además de las actividades de programación, Eclipse soporta modelado,
pruebas, creación de web, y muchas otras funciones.
En la Figura 1.1 se muestra los bloques funcionales de Eclipse. Cada bloque añadido
a la estructura se construye en base a los bloques que están debajo. La naturaleza
modular de la plataforma Eclipse es la que ha permitido un crecimiento sin precedente.
Toda la plataforma es abierta y libre para productos comerciales que pueden adicionar
nuevos bloques.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
7
Figura 1.1. Bloques funcionales de la plataforma Eclipse (tomado de (Carlson, 2005)).
A continuación se dará una breve descripción de algunos de los bloques funcionales cuya
relevancia es de interés en este trabajo.
Eclipse Runtime Platform
El núcleo de la plataforma de tiempo de ejecución provee servicios básicos como:
Registro de plug-in: Carga de plug-in y la administración del registro de los plug-ins
disponibles.
Recursos: Administración de una vista independiente de la plataforma del sistema
de archivos y carpetas.
Componentes de la interfaz de usuario: Los componentes de la interfaz de usuario
de Eclipse están basado en las bibliotecas SWT y JFase.
Facilidad de actualización: Las aplicaciones de Eclipse tienen incorporado el
soporte, la instalación y actualización de plug-ins a partir de localizaciones en
Internet.
Facilidad de ayuda: La facilidad de ayuda es compartida por todos los plug-ins.
Estos servicios básicos son implementados como plug-ins en un núcleo muy pequeño. El
diseño de Eclipse hace que todo sea un plug-in.
Integrated Development Environment
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
8
El IDE de Eclipse proporciona una experiencia común para usuarios a través
actividades de múltiples lenguajes y roles. Las características más significativas del IDE
son:
Vistas compartidas: Diversas facilidades de Eclipse comparten el uso de vistas
comunes para mostrar y editar propiedades y para mostrar errores de sintaxis
encontrados en el código fuente.
Perspectivas: Una perspectiva reúne grupos relacionados de vistas en una suite
para tareas específicas, tales como desarrollo en Java, puesta a punto y control de
versiones.
Preferencias: Un diálogo centralizado reúne páginas de características de
preferencia para todos los plug-ins instalados en el banco de trabajo.
Motor de búsqueda: Proporciona las capacidades generales para la búsqueda de
recursos y la presentación de resultados.
Puesta a punto: Define un modelo para puesta a punto independiente del lenguaje
para construir monitores de puesta a punto.
Orientación a equipos: Eclipse provee de APIs genéricas para la integración con
repositorios de control de versiones. Se incluye soporte para CVS (Control Version
System).
Java Development Tools (JDT)
Las herramientas de desarrollo en Java son los únicos plug-ins de lenguaje de
programación incluidos con Eclipse SDK (Software Development Kit). Sin embargo, otras
herramientas para lenguaje están disponibles o en desarrollo por subproyectos de Eclipse.
Las capacidades fundamentales proporcionadas por estas herramientas de Java son:
Editor, asistente de contenido, plantillas y formatos.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
9
Vistas de java, proporcionadas para la navegación y el manejo de proyectos en
Java.
Configuración de proyectos para la configuración de los caminos de las clases en
un proyecto, bibliotecas, opciones de compilación y otras características.
Monitor de puesta a punto. Provee de un entorno avanzado para la puesta a punto
de aplicaciones, que incluye establecer puntos de ruptura, ejecución paso a paso,
inspeccionar variables y modificar sus valores, etc.
Plug-in Development Environment
El entorno de desarrollo de plug-ins (PDE) ofrece herramientas que automatizan su
creación, manipulación, puesta a punto y despliegue. En sintonía con la filosofía general
de Eclipse, el PDE proporciona una amplia variedad de contribuciones (vistas, editores,
asistentes, instaladores, etc) que se combinan de forma transparente con el resto del
banco de trabajo de Eclipse y ayuda al desarrollador en cada una de las etapas del
desarrollo del plug-in mientras se encuentra trabajando dentro del banco de trabajo.
Rich Client Platform
Aunque la plataforma de Eclipse está diseñada para servir como una plataforma
abierta, está estructurada en la arquitectura de forma tal que sus componentes pueden ser
utilizados para construir prácticamente cualquier aplicación cliente. El conjunto mínimo de
componentes a nivel de plug-ins necesarios para construir una aplicación enriquecida se
conoce como Plataforma de Cliente Enriquecido (Silva, 2009).
Las aplicaciones enriquecidas se basan en un modelo de módulos o plug-in
dinámicos, y la interfaz de usuario se construye usando los mismos juegos de
herramientas y proposiciones de la extensión. Al contribuir al IDE, los plug-ins están
construidos en el banco de trabajo (workbench) de la plataforma SDK. Alternativamente,
en una aplicación enriquecida, los desarrolladores son responsables de definir la
presentación del banco de trabajo de la aplicación.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
10
En el epígrafe 1.2 se abordarán aspectos relacionados con los componentes de RCP.
1.1.2 Características de la herramienta Eclipse Galileo 3.5
La versión de Eclipse que se utiliza en el desarrollo de este trabajo es Eclipse Galileo
3.5, el mismo posee diversas ventajas sobre las demás versiones, por ejemplo en la
personalización de menú y barra de herramientas se ve que las personalizaciones de los
cuadros de diálogo de la perspectiva han sido mejorados y se han añadido nuevas
funcionalidades, ahora se puede usar para mostrar u ocultar elementos individuales del
menú o la barra de herramientas. Por otra parte ahora se puede crear nuevas instancias
de una vista de propiedades existente, esto permite observar las propiedades de una
selección en particular mientras se selecciona libremente otros elementos. Se puede
observar en esta versión mejoras al editor de comparación en el cual se han agregado
nuevas características tales como la acción Go to Line al menú contextual, lo que permite
una rápida navegación, las preferencias de color de fondo y de primer plano ahora se
resaltan y se ha agregado la acción Set Encoding al menú contextual, esto permite
cambiar el encoding de cada lado de la comparación. También se ve que tanto Solaris x86
Cocoa de 86 y 64 bit se han sumado a la línea de configuraciones soportadas para las
cuales generalmente se construye SWT y Eclipse. Ahora el cuadro de diálogo permite
abrir archivos con la opción de elegir el editor. Se puede elegir el editor con la opción
Open With del menú contextual o usando la opción del menú desplegable del botón Open.
Y por ultimo una nueva sección de preferencias permite administrar el cuadro de diálogo
del arranque de Eclipse para seleccionar el Workspace. Esta se encuentra siguiendo la
siguiente ruta: General > Startup and Shutdown > Workspaces. Se puede habilitar y
deshabilitar el cuadro de diálogo completamente (esta opción está en General > Startup
and Shutdown) y especificar el número máximo a recordar de los Workspaces
recientemente utilizados.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
11
1.1.3 Otros componentes de Eclipse
Los componentes que se muestran en la Figura 1.2 pueden ser utilizados para crear
nuevos plug-ins en Eclipse, que pueden ser también ejecutados fuera del banco de trabajo
de Eclipse. Las capacidades del IDE de Java que son utilizadas para la creación de
aplicaciones son estos componentes. Los componentes para cada uno de los proyectos
son empaquetados como un conjunto de plug-ins de Eclipse que son adicionados a un
banco de trabajo utilizando las facilidades de actualización de Eclipse.
La dependencia entre estos componentes y otros en la familia de Eclipse pueden ser
mejor representados como un grafo de relaciones en lugar de utilizar una arquitectura por
capas o niveles, sin embargo la Figura 1.2 ofrece un breve visión de los componentes a
nivel de bloques.
Figura 1.2. Otros componentes de la plataforma Eclipse (tomado de (Carlson, 2005).
Algunos componentes de interés en este trabajo son:
Graphical Editor Framework (GEF). Permite a los desarrolladores crear editores
gráficos. El desarrollador puede beneficiarse de muchas las operaciones comunes
proporcionadas en GEF, el cual emplea la arquitectura de modelo-vista-controlador
(Moore et al., 2004).
Eclipse Modeling Framework (EMF). Es un marco de trabajo de modelación y
generación de código para construir herramientas y otras aplicaciones basadas en
modelos de datos estructurados. EMF provee herramientas y soporte de ejecución para
producir un conjunto de clases en Java para el modelo, un conjunto de clases adaptadoras
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
12
que permiten establecer vistas y edición del modelo, y un editor básico (Steinberg et al.,
2008).
Visual Editor (VE). Un marco de trabajo para crear constructores de interfaces gráficas de
usuario para Eclipse.
1.2 La Plataforma de Cliente Enriquecido de Eclipse
Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para
desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido" (McAffer et al.,
2010a), en contraposición a las aplicaciones "Cliente-liviano" basadas en navegadores.
El término cliente enriquecido fue acuñado en la década de 1990 con el afán de crear
aplicaciones cliente con la apariencia de las generadas con Visual Basic y Delphi
(Boudreau et al., 2007). El aumento en número y popularidad de estas aplicaciones se
debió en parte al deseo de una experiencia "enriquecida" de usuario. RCP (por sus siglas
en inglés Rich Client Platform) es una plataforma tecnológica que permite crear
aplicaciones Java con una interfaz de usuario muy diferente a las basadas en Swing. Esto
es posible debido a que se utiliza el estándar de Eclipse SWT (Standard Widget Toolkit)
que usa los componentes propios del sistema operativo. El mejor ejemplo es el mismo
entorno de desarrollo de Eclipse que es en sí una aplicación basada en RCP.
Al desarrollar una herramienta o aplicación en la plataforma Eclipse, posibilita que
estas herramientas y aplicaciones se integren con otras aplicaciones que utilizan la
plataforma Eclipse. La integración se extiende también en el espacio de cliente
enriquecido. Una organización puede dividir el desarrollo de componentes de aplicaciones
a través de los equipos de desarrollo y luego integrar los resultados utilizando RCP. Esto
no trivializa el proceso de desarrollo de aplicaciones a gran escala, pero hace que la
integración sea más fácil.
Quizás la característica más obvia que la Plataforma Eclipse proporciona es un sistema de
administración de ventanas. Los componentes de interfaz de usuario forman parte de este
(incluyendo campos de entrada, botones, tablas y árboles de estructura), pero hay más. La
plataforma ofrece la gestión del ciclo de vida de las ventanas, soporte para vistas y
editores, la capacidad de contribuir elementos de menú y barras de herramientas, y las
acciones arrastrar y soltar.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
13
Con RCP los desarrolladores pueden construir sus aplicaciones basado en la existencia
de plataformas. En lugar de tener que escribir una aplicación completa desde la nada,
pueden aprovecharse de características probadas en los marcos de trabajo previstos por
la plataforma. Trabajar en una plataforma, facilita integración y desarrollo rápido de la
aplicación.
1.2.1 Evolución de RCP en Eclipse
El proyecto Eclipse no comenzó con la intención de construir un RCP. En lugar de
eso, su meta fue crear una plataforma para herramientas integrantes de desarrollo. Eclipse
como un RCP empezó con Eclipse 2.1 y la versión 3.0 fue un paso importante. Se
eliminaron prácticamente todas las interdependencias con el IDE, y muchas partes de la
interfaz de usuario se abrieron a la personalización. Con la introducción de OSGi se
establecieron las bases para la instalación, desinstalación y actualización de módulos
dinámicos. Estos dos elementos de trabajo equivalen a una refactorización masiva de los
aspectos principales de la plataforma. Con estas mejoras, creció el interés en RCP y
comenzaron a emerger las aplicaciones comerciales. La NASA comenzó a usar a RCP
para manejar, modelar, y analizar misiones del espacio y RCP apareció inadvertido en
aplicaciones de diversos dominios. Actualmente RCP es utilizado como la base de
plataformas del software para los bancos y el seguro, para los sistemas de información de
cuidado de la salud y geográficos. Eclipse 3.5 contiene mejoras incontables, refinamientos,
y saltos significativos en el soporte de diversos panoramas aplicativos.
1.2.2 Conceptos básicos
RCP emplea un framework de componentes de software ligero basado en plug-ins.
Esta arquitectura proporciona la extensibilidad y la integración sin fisuras. Todo en RCP y
también en Eclipse, con la excepción del “runtime kernel” o núcleo en tiempo de ejecución,
es un plug-in (Clayberg et al., 2008). Se podría decir que todas las características son
iguales, ya que cada plug-in se integra con Eclipse exactamente de la misma manera. Un
plug-in puede ser cualquier cosa: un diálogo, una vista, un navegador web, un explorador
de base de datos, un explorador del proyecto, y así sucesivamente. RCP está diseñada
para que sus componentes puedan unirse para construir casi cualquier aplicación del
cliente mediante un modelo de plug-ins dinámico, herramientas y puntos de extensión. El
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
14
diseño y el funcionamiento del workbench están bajo el control detallado del desarrollo de
plug-ins.
Los siguientes componentes constituyen la Plataforma de Cliente Enriquecido (RCP):
Equinox
Core platform
Standard Widget Toolkit
JFace
Eclipse IDE workbench
1.2.2.1 ¿Qué es plug-in?
Un plug-in es la unidad más pequeña de la Plataforma Eclipse que puede ser
desarrollado y entregado por separado (Clayberg et al., 2008). Por lo general, una
herramienta simple se escribe como un único plug-in, mientras que una herramienta
compleja divide su funcionalidad a través de varios plug-ins. A excepción de un pequeño
“kernel” o núcleo, conocido como “Platform Runtime” o plataforma de tiempo de ejecución,
toda la funcionalidad de la plataforma de Eclipse se encuentra en los plug-ins.
Un plug-in típico consiste en código Java almacenado en una librería JAR, algunos
archivos de sólo lectura, y otros recursos como imágenes, plantillas web, catálogos de
mensajes, las librerías de código nativo, etc (Carlson, 2005). Las librerías de código de un
plug-in y el contenido de sólo lectura se encuentran juntos en un directorio del sistema de
archivos, o en una dirección URL base en un servidor. También hay un mecanismo que
permite que un plug-in se sintetice a partir de varios fragmentos separados, cada uno en
su propio directorio o URL. Este es el mecanismo utilizado para entregar los paquetes de
idioma separados para un plug-in internacionalizado.
Cada plug-in tiene un archivo de manifiesto declarando sus interconexiones con otros
plug-ins. El modelo de interconexión es simple: un plug-in declara cualquier número de
puntos de extensión con nombre, y cualquier número de extensiones a uno o más puntos
de extensión en otros plug-ins. Un punto de extensión de un plug-in puede ser extendido
por otros plug-ins. Por ejemplo, el plug-in “workbench” declara un punto de extensión para
las preferencias del usuario. Cualquier plug-in puede aportar sus propias preferencias del
usuario mediante la definición de las extensiones a este punto de extensión. Un punto de
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
15
extensión puede tener una interfaz API correspondiente. Otros plug-ins contribuyen a la
implementación de esta interfaz a través de extensiones a este punto de extensión.
Cualquier plug-in puede definir nuevos puntos de extensión y crear nuevas API para
otros plug-ins. Al iniciar, la “Plataforma en Tiempo de ejecución” descubre el conjunto de
plug-ins disponibles, lee sus archivos de manifiesto, y construye un registro de estos en la
memoria. La Plataforma busca por su nombre las declaraciones de extensión con sus
declaraciones correspondientes de sus puntos de extensión. El registro de plug-ins
resultante está disponible a través de la API de la Plataforma. Los plug-ins no se pueden
añadir después de la puesta en marcha.
El archivo de manifiesto de un plug-in es un archivo XML. Un punto de extensión
puede declarar más tipos de elementos XML especializados para su uso en las
extensiones. Esto permite que el plug-in suministre la “extensión” para comunicar
información arbitraria para el plug-in que declara el “punto de extensión” correspondiente.
Hasta que un código de plug-in se carga, es insignificante su presencia en la memoria y
su impacto sobre el tiempo de arranque. El uso del manifiesto de un plug-in basado en
XML también hace que sea más fácil escribir las herramientas que soporten la creación de
plug-in.
El “Plug-in Development Environment (PDE)” o “Entorno de Desarrollo de Plug-ins”,
que se incluye en el SDK de Eclipse y funciona como una herramienta. Un plug-in se
activa cuando su código en realidad necesita ser ejecutado. Una vez activado, un plug-in
utiliza el registro de plug-ins para descubrir y acceder a las extensiones contribuidas a sus
puntos de extensión. Por ejemplo, el plug-in en el que se declara el “punto de extensión”
referente a las preferencias de los usuarios puede descubrir todas las preferencias de
usuarios contribuidas y acceder a sus nombres para la construcción de un diálogo de
preferencias. Esto se puede hacer utilizando sólo la información del registro, sin tener que
activar cualquiera de los plug-ins de contribución. Los plug-in de contribución se activarán
cuando el usuario selecciona una preferencia de una lista. La activación de los plug-ins de
esta manera no se produce automáticamente, hay un pequeño número de métodos de la
API para la activación explícita de los plug-ins. Una vez activado, un plug-in se mantiene
activado hasta que la Plataforma se cierra. La Plataforma de tiempo de ejecución declara
un punto de extensión para aplicaciones especiales.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
16
Cuando una instancia de la Plataforma inicia, el nombre de una aplicación se
especifica a través de las líneas de comandos, el único plug-in que se activa inicialmente
es el que declara la aplicación. Al determinar el conjunto de plug-ins disponibles en la
delantera, y mediante el apoyo a un importante intercambio de información entre los plug-
ins, sin tener que activar cualquiera de ellos, la Plataforma puede proporcionar a cada
plug-in con una rica fuente de información pertinente sobre el contexto en la que está en
funcionamiento. Este contexto no puede cambiar mientras que la plataforma se está
ejecutando, lo que no hay necesidad de eventos complejos del ciclo de vida para informar
a los plug-ins cuando cambia el contexto. Cada plug-in se le asigna su propio cargador de
clases Java que es el único responsable de cargar sus clases (y los paquetes de Java de
recursos). Cada plug-in declara explícitamente su dependencia de otros plug-ins de la que
espera para acceder directamente a las clases. Un plug-in controla la visibilidad de las
clases públicas y las interfaces de sus bibliotecas. Esta información se declara en el
manifiesto del plug-in, las normas de visibilidad se aplican en tiempo de ejecución por el
plug-in de cargadores de clases. El plug-in mecanismo se utiliza para dividir la plataforma
Eclipse.
La plataforma de Eclipse en tiempo de ejecución proporciona un mecanismo para
extender los objetos de forma dinámica. Una clase que implementa una interfaz
"adaptable" declara sus instancias abiertas al comportamiento de las extensiones de
terceras partes. Una instancia adaptable puede ser consultada por el objeto adaptador que
implementa una interfaz o clase. Por ejemplo, los recursos del “workspace” son objetos
adaptables, el “workbench” añade adaptadores que proporcionan un icono apropiado y
etiquetas de texto para un recurso. Cualquiera de las partes puede agregar
comportamiento a los tipos existentes (tanto las clases como las interfaces) de los objetos
adaptables al registrar un adaptador. Varias partes, de forma independiente, pueden
extender los mismos objetos adaptables, cada uno para un propósito diferente.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
17
1.2.2.2 ¿Qué es SDK?
Cuando se trabaja en un proyecto grande en un ambiente de equipo, a menudo es
deseable para cada desarrollador revisar todo el proyecto de control de código fuente.
Muchos desarrolladores trabajan en áreas relacionadas del sistema y sólo hay que "usar"
o ampliar la funcionalidad actual, sin ninguna intención de cambiarla. Mientras que se
puede hacer uso de un sistema binario del paquete de plug-in, a menudo con el código
fuente disponible hace que el desarrollo sea mucho más fácil. Para apoyar esto, se puede
crear e implementar características de SDK, es decir, las características que contienen los
paquetes binarios y el código fuente. Al enviar una característica SDK se puede estar
seguro de que el código fuente que envió se sincroniza con los artefactos binarios de sus
clientes.
1.2.2.3 Widget
Un widget 2 es una pequeña aplicación o programa, usualmente presentado en
archivos pequeños que son ejecutados por un motor de widgets o Widget Engine. Entre
sus objetivos están: dar fácil acceso a funciones frecuentemente usadas y proveer de
información visual. Sin embargo, los widgets pueden hacer todo lo que la imaginación
desee e interactuar con servicios e información distribuida en Internet; pueden ser vistosos
relojes en pantalla, notas, calculadoras, calendarios, agendas, juegos, ventanas con
información del tiempo en su ciudad, etcétera.
En el contexto de la programación de aplicaciones visuales, los widgets tienen un
significado más amplio como componente o control visual que el programador reutiliza y
tienen un gran valor para el usuario. Los programadores los usan para construir interfaces
gráficas de usuario (GUI, del inglés Graphic User Interface).
2 La palabra widget proviene de la combinación de las palabras window-gadget (que se interpretaría como
aparato, artilugio o dispositivo de ventana).
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
18
1.2.2.4 Equinox OSGi
El modelo de componentes de plug-ins de Eclipse se basa en la implementación de
Equinox del framework OSGi (Open System Gateway Initiative) especificación R4.2. La
especificación OSGi constituye un framework para la definición, composición, y ejecución
de los componentes o paquetes (McAffer et al., 2010b). No hay diferencias fundamentales
o funcionales entre plug-ins y paquetes de Eclipse. Ambos son mecanismos de
agrupación, de entrega y de gestión de código. Como tal, se utilizan indistintamente los
términos teniendo en cuenta que: "Un plug-in es un paquete y un paquete es un plug-in.
Ellos son la misma cosa.” Es conveniente pensar en el framework OSGi como el
suministro de un modelo de componentes a Java, es decir, como una facilidad en el
mismo nivel que el JRE (Java Runtime Enviroment). La ruta de clases de un paquete se
construye dinámicamente basándose en las dependencias declaradas en su manifiesto. El
manifiesto define lo que es un plug-in y de lo que depende. Todos los plug-ins son auto
descriptivos. El archivo MANIFEST.MF le brinda al plug-in org.eclipse.ui un identificador
(ID, por sus siglas en inglés) de plug-in, o un nombre simbólico de paquete, y una versión.
El ID y la versión se emparejan para identificar el plug-in y además se utilizan para
expresar relaciones de dependencia. En el contexto de Eclipse, el papel principal de OSGi
es unir los plug-ins instalados permitiéndoles interactuar y colaborar entre ellos. La gestión
rigurosa de las dependencias y rutas de clases permite un control estricto y explícito sobre
las interacciones entre paquetes y por lo tanto la creación de sistemas que son más
flexibles y realizados con mayor facilidad. OSGi fue diseñada como una tecnología para
hacer frente a la complejidad del software creada por los productos de software
monolíticos. Su objetivo es el desarrollo de nuevos software, así como la integración de
aplicaciones existentes en los nuevos sistemas. Al proporcionar normas para la
integración de software, el framework OSGi mejora la reutilización, la fiabilidad y reduce
los costes de desarrollo.
En su esencia, OSGi proporciona un marco de software que permite que las
aplicaciones puedan ser construidas a partir de pequeños componentes, reutilizables y de
colaboración. Estos componentes, a su vez, pueden ser incluidos en una aplicación más
compleja. Este modelo de componentes dinámicos no se encuentra en los entornos
estándar Java Virtual Machine (JVM). OSGi proporciona un poderoso modelo de
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
19
componentes dinámico, que es la razón por la cual la Fundación Eclipse lo ha
seleccionado como el runtime base para Eclipse RCP y el IDE.
1.2.2.5 La plataforma en tiempo de ejecución.
La plataforma central incluye un motor en tiempo de ejecución que inicia la plataforma
base y de forma dinámica descubre y ejecuta plug-ins. La plataforma central es
responsable de lo siguiente:
• Definición de una estructura para los plug-ins y los detalles de implementación: Los
paquetes y cargadores de clases.
• Encontrar y ejecutar la aplicación principal, y el mantenimiento de un registro de plug-
ins, sus extensiones y puntos de extensión.
• Proporcionar varios servicios, tales como el registro, seguimiento de opciones de
depuración, adaptadores, un almacén de preferencias, y una infraestructura de
concurrencia.
El tiempo de ejecución es definido por la org.eclipse.osgi plug-ins y
org.eclipse.core.runtime en el cual todos los otros plug-ins dependen. La filosofía general
de la plataforma central gira en torno a la idea de creación de plug-ins para extender el
sistema. Por ejemplo, el Eclipse Software Development Kit (SDK) incluye la plataforma
base, así como dos herramientas principales: las herramientas de Java con todas las
funciones de desarrollo (JDT) y un Plug-in de entorno de desarrollo (PDE) para facilitar el
desarrollo de plug-ins y extensiones. Estas herramientas proporcionan un ejemplo de
cómo las nuevas herramientas se pueden componer mediante la creación de plug-ins que
extienden el sistema. El plug-in modelo esta estructurado en torno a los siguientes
conceptos:
Puntos Extensión: Un punto de extensión es un lugar bien definido en donde otros plug-
ins pueden aumentar la funcionalidad. Los plug-ins pueden añadir extensiones a la
plataforma mediante la implementación de un punto de extensión. Definir un punto de
extensión se puede considerar como la definición de una API, con la diferencia de que el
punto de extensión se declara en Lenguaje de Marcado Extensible (XML) en lugar de
código.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
20
OSGi manifiesto y plug-in de manifiesto: Estos manifiestos permiten que el plug-in se
describa en el sistema. Las extensiones y puntos de extensión se declaran en el plug-in de
archivos manifiesto, que se llama plugin.xml. La plataforma mantiene un registro de plug-
ins instalados y las funciones que proporcionan en el archivo MANIFEST.MF.
Carga dinámica: En el modelo de servicios OSGi, los paquetes de software no incurren
en penalización en cuanto a la memoria o rendimiento si estos no son utilizados. Un plug-
in puede ser instalado y se agrega al registro, pero no se activará a menos que una
función ofrezca una solicitud en tiempo de ejecución.
Gestión de recursos: Los recursos dentro del área de trabajo del usuario son
gestionados por el plug-in org.eclipse.core.resources. Este plug-in provee servicios para
acceder a los proyectos, carpetas y archivos almacenados en los sistemas de archivos del
usuario o área de trabajo alternativos, como los sistemas de archivos de red o una base
de datos. Este plug-in es muy útil para aplicaciones Eclipse IDE.
1.2.2.6 Herramientas de SWT.
SWT es una biblioteca gráfica de bajo nivel que proporciona los controles estándar
de interfaz de usuario, tales como listas, menús, fuentes y colores, es decir, una biblioteca
que expone lo que el sistema de ventanas subyacente tiene que ofrecer. Las aplicaciones
que utilizan SWT son portables entre todas las plataformas soportadas. Como resultado,
los sistemas basados en SWT son portátiles y nativos. Ténganse en cuenta que SWT no
depende de Equinox u OSGi, sino que es una colección independiente, que se puede
utilizar tanto en Eclipse como en RCP.
SWT que fue creado para superar las limitaciones de la interfaz gráfica de usuario de
Swing, y aplica una capa común de dispositivos con acceso rápido en plataformas
múltiples. En SWT se aborda esta cuestión mediante la definición de un API común que
está disponible a través de una serie de sistemas de ventanas compatibles. Para cada
sistema de ventanas, la aplicación SWT utiliza los widgets siempre que sea posible, donde
no hay dispositivo disponible, la aplicación SWT proporciona una emulación adecuada.
Esta estrategia permite a SWT mantener un modelo de programación coherente en todos
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
21
los entornos. Internamente, la aplicación SWT proporciona implementaciones separadas y
distintas en Java para cada sistema de ventanas.
1.2.2.7 JFace
JFace es un conjunto de herramientas GUI de ventanas independientes del sistema
para el manejo de la mayoría de las tareas de programación. JFace está diseñado para
trabajar con SWT sin ocultarlo e implementa un modelo-vista-controlador (MVC).
Los siguientes son algunos de los componentes de interfaz de usuario en JFace:
Imagen y registros de la fuente.
Texto, de diálogo, de preferencia, y los marcos de asistente.
Visualizadores.
Acciones.
Espectadores.
Una acción representa un comando que puede ser activado por el usuario a través de
un botón, elemento de menú o elemento de una barra de herramientas. Cada acción sabe
sus propias propiedades clave de la interfaz de usuario (etiqueta, un icono, la herramienta
de punta, etc) que se utilizan para construir los dispositivos apropiados para la
presentación de la acción.
Los espectadores son los adaptadores basados en modelos para los dispositivos
determinados de SWT. Los espectadores manejan el comportamiento común y
proporcionan la semántica de alto nivel que está disponible en los dispositivos de SWT. La
aplicación espectador se encarga de la asignación entre los elementos del dominio y
dispositivos de SWT, el ajuste para una vista filtrada de los elementos, y re-clasificación
cuando sea necesario.
1.2.2.8 El Workspace
Un área de trabajo es la carpeta del disco donde el trabajo real se guardará. Las
diversas herramientas conectadas a la plataforma Eclipse operan en archivos regulares en
el área de trabajo del usuario. El área de trabajo consta de uno o más proyectos de nivel
superior. Todos los archivos en el área de trabajo son directamente accesibles a los
programas y herramientas estándar del sistema operativo subyacente. Para minimizar el
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
22
riesgo de perder accidentalmente los archivos, un mecanismo de espacio de trabajo de la
historia de bajo nivel no pierde de vista el contenido anterior de los archivos que han sido
modificados o suprimidos por las herramientas integradas.
El espacio de trabajo proporciona un mecanismo marcador para anotar los recursos.
Los marcadores se utilizan para registrar las diversas anotaciones, tales como mensajes
de error del compilador a elementos de tareas, marcadores, resultados de búsqueda, y los
puntos de interrupción del depurador. El mecanismo de marcador está abierto. Los
Plug-ins pueden declarar nuevos subtipos del marcador y el control de si se debe guardar
entre ejecuciones. La plataforma proporciona un mecanismo general que permite una
herramienta para rastrear los cambios a los recursos del área de trabajo. Al registrar un
oyente de cambio de recursos, una herramienta garantiza la recepción de notificaciones
después de los hechos de todas las creaciones de los recursos, eliminaciones y cambios
en el contenido de los archivos. La plataforma aplaza la notificación de eventos hasta el
final de un lote de operaciones de manipulación de los recursos.
Además, desde una serie de herramientas semi-independientes puede estar
operando en los recursos de un proyecto al mismo tiempo, este mecanismo es un
instrumento para detectar la actividad de otro en las cercanías de archivos específicos, o
tipos de archivo, en la que tiene un interés.
1.2.2.9 El Workbench
El workbench de Eclipse es el ambiente de desarrollo básico en Eclipse, y
proporciona los cimientos para que las aplicaciones de interfaz de usuario de Eclipse sean
fáciles de escribir, fácil de usar, sean escalables y extensibles. Una de las principales
ventajas de usar RCP es el beneficio que se obtiene de la reutilización de los
componentes básicos de interfaz de usuario, que le permite centrarse en su dominio sin
tener que rediseñar. El workbench se compone de los siguientes conceptos:
Las perspectivas: Una perspectiva define el trazado y la parte inicial de los puntos
de vista en su ventana del banco de trabajo. Las perspectivas están enfocadas a
una tarea específica de desarrollo, algo semejante como Java EE, Java, plug-in,
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
23
etcétera. Una ventana de banco de trabajo puede tener varias perspectivas
distintas, las cuales sólo una es visible en cualquier momento dado. El usuario
puede cambiar la perspectiva de trabajar en una tarea diferente, y puede
reorganizar fácilmente y personalizar el punto de vista para adaptarse mejor a una
tarea concreta. La plataforma ofrece perspectivas para la exploración de recursos
en general, ayuda en línea, y las tareas del equipo de apoyo. Perspectivas
adicionales son suministrados por otros plug-ins.
Vistas: Las vistas son las ventanas pequeñas y los recuadros complementarios
alrededor de los bordes del banco de trabajo. Las vistas se usan para navegar el
banco de trabajo y presenta información de diferentes maneras. Proporciona
información acerca de algún objeto que el usuario está trabajando en la mesa de
trabajo. Una vista puede ayudar a un editor que facilita información sobre el
documento que se está editando. Los puntos de vista tienen un ciclo de vida más
simple que los editores: las modificaciones realizadas en una vista (como el cambio
de un valor de propiedad) son por lo general guardadas inmediatamente, y los
cambios se reflejan inmediatamente en otras partes relacionadas de la interfaz de
usuario. La plataforma ofrece varias vistas estándar, las vistas adicionales son
suministradas por otros plug-ins.
Editores: Permite al usuario abrir, editar y guardar objetos. Cuando un editor está
activo puede contribuir a las acciones de los menús y barra de herramientas del
banco de trabajo. La plataforma proporciona un editor de texto estándar para los
recursos y los demás editores específicos son suministrados por otros plug-ins. Los
editores son usados para hacer la codificación real. Por ejemplo, usted podría usar
a los editores para codificar en Java, JavaScript, Hypertext Markup Language (el
HTML), o Cascading Style Sheets (CSS).
Los proyectos: Un proyecto es un envase usado por el banco de trabajo para
agrupar archivos y carpetas asociadas.
Tal como el JFace añade estructura para SWT, el Workbench añade presentación y
coordinación para JFace. Para el usuario, el Workbench consta de algunas vistas y
editores. Sino que también, el Workbench:
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
24
Define un paradigma poderoso de la interfaz de usuario con ventanas, perspectivas,
vistas, editores, y acciones.
Provee extensibilidad basada en contribuciones de la interfaz de usuario.
El Workbench se aparece ante el usuario como una colección de ventanas (Ver Figura
1.3). Dentro de cada ventana el Workbench da al usuario permiso de organizar su trabajo.
Workbench provee puntos de extensión que permiten definir plug-in como elementos
de la interfaz de usuario. Sin embargo, el uso de extensiones para construir una interfaz
de usuario tiene un impacto fundamental en la dimensionalidad de la interfaz de usuario en
términos de la complejidad y la actuación.
Figura 1.3 Diferentes componentes que integran al workbench.
1.2.2.10 Diferencias entre RCP y el Workbench de Eclipse
Existen pocas diferencias entre el workbench de Eclipse y RCP. Ambos se basan en
un modelo de plug-in dinámico, y la interfaz de usuario para el banco de trabajo y RCP se
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
25
crea usando las mismas herramientas y puntos de extensión. Sin embargo, RCP tiene las
siguientes características:
En RCP, el trazado y función del banco de trabajo del Entorno de Desarrollo
Integrado, Eclipse, están bajo el control del plug-in desarrollado. De hecho, el
workbench del IDE Eclipse, es una aplicación RCP para el desarrollo del software.
En RCP, el desarrollador es responsable de definir la aplicación y hacer a la medida
la forma y materia del workbench para acomodar las necesidades de la aplicación.
En RCP, la aplicación de la plataforma necesita que sólo los plug-ins org.eclipse.ui
y org.eclipse.core runtime corran. Sin embargo, las aplicaciones RCP son libres de
usar cualquier plug-in de la plataforma que necesiten proveer.
1.2.2.11 GMF
Eclipse tiene muchas bondades, una de ellas y que es muy importante para el
desarrollo de este trabajo es GMF (Graphical Modeling Framework) que se emplea para
la generación de editores gráficos manteniendo una arquitectura MDA (Arquitectura
Dirigida por Modelos). Esta tecnología establece un puente entre Eclipse Modeling
Framework (EMF) y el Graphical Editing Framework (GEF). GMF permite crear editores
propios para el modelado de diagramas UML. El resultado de la creación de un proyecto
GMF, es la obtención de un plug-in que instalado en un proyecto basado en la arquitectura
de Eclipse, es capaz de editar gráficamente un modelo que se ajusta a un meta modelo
previamente especificado. GMF ofrece otras funcionalidades aparte de la creación de
editores gráficos, también establece la validación de los modelos mediante el uso de las
restricciones en OCL (Object Constraint Language). Con GMF, se disminuye la cantidad
de código escrito por el desarrollador, todo el código de la aplicación es generado en su
totalidad por GMF, permitiendo el desarrollo de editores visuales bastante complejos y
completos sin necesidad de conocer muchos aspectos de EMF y GEF. La utilización de
editores gráficos basados en GMF brinda algunos beneficios sobre cómo sus
características están bien diseñadas, codificadas, probadas y desplegadas. También
proporciona una apariencia y comportamiento común y permite que los editores puedan
ser creados desde cero o partiendo de elementos previamente creados como parte del
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
26
SDK (Software Developement Kit) de GMF. Por otra parte gestiona el diagrama de
persistencia permitiendo al desarrollador centrarse en la lógica de negocio del sistema.
Capítulo 1. “LA PLATAFORMA DE CLIENTE ENRIQUECIDO EN EL ENTORNO DE DESARROLLO ECLIPSE”
27
Conclusiones parciales
En este capítulo se llevó a cabo un análisis profundo de las principales características,
componentes y herramientas que distinguen a una aplicación RCP sobre el Entorno de
Desarrollo Integrado Eclipse. Para ello se realizó una descripción de cada uno de los
elementos fundamentales que integran una aplicación de este tipo y se destacaron
algunas de las ventajas que ofrece la Plataforma de Cliente Enriquecido. Se hizo una
breve explicación de la tecnología GMF basado en la importancia que tiene, para este
trabajo, el plug-in que genera este framework.
28
CAPÍTULO 2. “DESARROLLO DE APLICACIONES EN ECLIPSE UTILIZANDO RCP”
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
29
2. DESARROLLO DE APLICACIONES EN ECLIPSE UTILIZANDO RCP
Eclipse, entre muchas otras de sus bondades, ofrece un plug-in denominado
GMF (Graphical Modeling Framework), orientado a la creación de editores gráficos
haciendo uso de la Arquitectura Dirigida por Modelos (MDA). El propósito de este
capítulo es describir la obtención de una plataforma independiente de Eclipse que
tenga incorporado un editor gráfico generado con GMF, basado en las ventajas que
brinda RCP (Plataforma de Cliente Enriquecido). Se reflejan detalles del proceso de
creación de una aplicación de cliente enriquecido con el fin de destacar las
facilidades de uso de este tipo de cliente y su utilidad para la integración con GMF a
partir de un prototipo de editor de diagramas Entidad-Relación, generado
previamente usando esta tecnología.
2.1 Selección de una plantilla RCP.
El proceso de construcción de una aplicación de cliente enriquecido requiere de
la selección de una plantilla RCP básica. Hasta el momento existen solo cuatro de
ellas, pero son suficientes para llevar a cabo cualquier aplicación:
Hello RCP.
RCP application with a view.
RCP application with an intro.
RCP Mail Template.
“Hello RCP” es la más simple y general de todas las plantillas. Consiste
únicamente en una ventana de aplicación con un título y solo hace uso de las
extensiones:
org.eclipse.core.runtime.applications
org.eclipse.ui.perspectives
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
30
“RCP application with a view” es muy similar a la anterior e incluye además una
simple vista por lo que posee entre sus extensiones: “org.eclipse.ui.views”. “RCP
application with an intro” constituye una aplicación básica que consta de un ejemplo
de ventana de bienvenida o intro, que contiene tres páginas estáticas y
opcionalmente tiene una con contenido creado dinámicamente. Las extensiones que
usa esta plantilla son:
org.eclipse.core.runtime.products
org.eclipse.ui.intro
org.eclipse.ui.intro.config
org.eclipse.core.runtime.applications
org.eclipse.ui.perspectives
org.eclipse.ui.intro.configExtension (si el contenido dinámico es seleccionado)
“RCP Mail Template” es mucho más completa, muestra cómo incorporar un
menú principal a una aplicación, así como barras de herramientas y cómo crear
acciones para ambos. Indica además cómo crear asistencia de teclado para dichas
acciones, cómo crear vistas que pueden ser cerradas y creadas múltiples instancias
de una misma. Ofrece también cómo crear perspectivas con espacios reservados
para nuevas vistas, cómo usar el diálogo “About” por defecto y cómo crear una
definición del producto. Las extensiones que usa esta plantilla RCP básica son las
siguientes:
org.eclipse.core.runtime.applications
org.eclipse.core.runtime.products
org.eclipse.ui.commands
org.eclipse.ui.perspectives
org.eclipse.ui.views
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
31
org.eclipse.ui.bindings
Debido al nivel de complejidad de esta plantilla RCP y por la similitud de su
estructura a los requerimientos de la interfaz de usuario de la aplicación que se
desea diseñar, “RCP Mail Template” se toma en este capítulo como punto de partida
para comenzar el desarrollo de un prototipo de plataforma de cliente enriquecido que
de soporte al editor gráfico generado con GMF.
2.2 Comenzando una aplicación RCP.
Al llevar a cabo el desarrollo de una aplicación basada en RCP lo primero que se
necesita es crear un proyecto de plug-in para situar el código. Esto se puede hacer
dirigiéndose al menú File >New > Project… para iniciar el asistente “New Project”. A
continuación se selecciona la opción Plug-in Project y en esta página que aparece
se proporciona el nombre del proyecto, en este caso: “uclv.cei.editorgmfrcp”. Luego
se debe dar click en Next para levantar el asistente "New Plug-in Project” que
muestra una página similar a la de la Figura 2.0. En este asistente es donde se
especifica la información sobre el propio plug-in, su ID o identificador, versión,
nombre, proveedor y entorno de ejecución. Para que nuestro proyecto sea RCP hay
que seleccionar el botón de opciones Yes en área “Rich Client Application” de esta
página. Al escoger esta opción le indicamos al asistente que muestre las plantillas
RCP estándares en la próxima página.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
32
Figura 2.0 Creación de un proyecto de plug-in.
Al avanzar, el asistente se mueve hacia la página de las plantillas RCP (Ver
Anexos Figura 2.1) donde seleccionamos, en nuestro caso, “Mail RCP Template” por
las características mencionadas anteriormente que la hacen apropiada para esta
aplicación.
Una vez determinada la plantilla, se continúa avanzando el asistente hacia la
próxima página en la que se puede identificar la aplicación EditorgmfRCP, ponerle un
título a la ventana, nombre de perspectiva y otros atributos. A continuación se debe
dar click en Finish para concluir con estos primeros pasos elementales en este
proceso de desarrollo y crear la aplicación RCP básica inicial. Como resultado en el
workspace se podrá visualizar el contenido de un simple proyecto con el nombre
“uclv.cei.editorgmfrcp”, tal y como muestra la Figura 2.2, que contiene una carpeta
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
33
nombrada “src” que almacena los archivos fuentes Java generados por esta plantilla
en el asistente “New Proyect.”
Figura 2.2 Estructura del proyecto.
De manera automática Eclipse propone hacer un cambio hacia la perspectiva de
desarrollo de plug-ins (Plug-in Development perspective), que está compuesta por
un conjunto de vistas en el ambiente de desarrollo de Eclipse que son
particularmente útil en el desarrollo de estos componentes. Aunque la selección de
esta opción no es obligatoria, es recomendable su uso debido a las facilidades que
brinda. Al aceptar esta propuesta, el nuevo plug-in será abierto en un editor que
provee una vista comprensiva de las diferentes partes de la definición del plug-in
capturada en distintos archivos tales como “plugin.xml”, “MANIFEST.MF”, y
“build.properties”. Este trabaja con todos a la vez y mediante su uso se pueden editar
todos los aspectos deseados de un plug-in en un mismo lugar. La Figura 2.3 de los
Anexos, muestra la página inicial de este editor.
Para realizar una prueba inicial de cómo se muestra esta aplicación básica en
pantalla simplemente se pueden usar los links que aparecen en la sección “Testing”
en la página “Overview”. Al dar click en el link “Launch an Eclipse application” se
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
34
ejecuta EditorgmfRCP como una aplicación Eclipse RCP separada, en su propia JVM
(Máquina Virtual de Java) que contiene solamente las funcionalidades
implementadas en la plantilla “Mail RCP Template” que constituyen únicamente un
punto de partida para la aplicación que se propone desarrollar. En la Figura 2.4 de
los Anexos se puede apreciar la apariencia que tiene este prototipo inicial.
A lo largo de toda el área del editor de plug-ins se encuentran etiquetas para
los diferentes aspectos de estos. Si nos dirigimos hacia la página “Dependencies” se
puede notar que el plug-in “uclv.cei.editorgmfrcp” depende de otros plug-ins:
“org.eclipse.core.runtime” y “org.eclipse.ui”; lo cual significa que nuestro plug-in
puede hacer uso de clases localizadas en ellos e indica además qué clases en otros
plug-ins no están disponibles para EditorgmfRCP. Este control sobre la visibilidad de
las clases es fundamental para la noción de Eclipse de la modularidad y su habilidad
para construir sistemas basados en plug-ins usando este ambiente de desarrollo.
Herramientas muy útiles de análisis de dependencias se pueden encontrar en esta
sección y ayudan a la navegación de dependencias entre plug-ins, facilitan la
búsqueda de aquellas que no están siendo usadas pero que se encuentran como
necesarias, simplifican la búsqueda de ciclos en los gráfos de dependencias y otras
tareas como mostrar la jerarquía de dependencia del plug-in que para este caso tiene
una estructura similar a la mostrada en la Figura 2.5.
Figura 2.5: Jerarquía de dependencia de plug-ins de EditorgmfRCP.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
35
En esta estructura se puede notar que algunos de los plug-ins bajo Runtime y UI
presentan una pequeña flecha decorada a su lado y esta simbolización es empleada
para identificar a aquellos plug-ins que son reexportados por sus padres en el árbol,
por ejemplo, cualquiera que dependa de UI automáticamente depende del SWT
reexportado y similar a esto, UI reexporta JFace y “org.eclipse.ui.workbench”, y
Runtime reexporta OSGi. Este mecanismo de encadenamiento de dependencias es
usado dondequiera que un plug-in exponga la API de otro plug-in como parte de la
suya. Una mejor manera de comprender esta idea puede ser a través del siguiente
ejemplo. La API de UI contiene clases y métodos que nombran tipos encontrados en
SWT. Para asegurar que un plug-in que requiera de UI tenga una cadena de
dependencias coherente, UI reexporta SWT; pero no a todos de sus prerrequisitos,
solo aquellos que se exponen como parte de su API.
Cuando el PDE (Entorno de Desarrollo de Plug-ins) genera la estructura o
esqueleto inicial de la aplicación, en la página “Extensions” se puede notar que son
adicionadas seis extensiones, como muestra la Figura 2.6. En la sección
correspondiente a los detalles de los elementos de las extensiones aparecen algunos
valores, como nombres de varias clases, que fueron generados por la plantilla.
Figura 2.6: Extensiones generadas por la platilla Mail RCP
Estas extensiones son un mecanismo para enlazar clases dentro de la
infraestructura de Eclipse, tal es el caso que aparece en la Figura 2.6, donde se ve
como la nueva clase perspectiva nombrada
“uclv.cei.editorgmfrcp.DiagramEditorPerspective” se enlaza al punto de extensión
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
36
“org.eclipse.ui.perspectives”. Esta operación genera de manera automática, en el
cuerpo de la página “plugin.xml”, las siguientes líneas en formato “xml”:
<extension
point="org.eclipse.ui.perspectives">
<perspective
name="DiagramEditorPerspective"
class="uclv.cei.editorgmfrcp.DiagramEditorPerspective"
id="uclv.cei.editorgmfrcp.DiagramEditorPerspective">
</perspective>
</extension>
La estructura de este archivo contiene de manera general la descripción de todo el
contenido del plug-in: extensiones, puntos de extensión, clases y otros parámetros
que son específicos para cada uno de estos contenidos.
2.3 Descripción de aspectos fundamentales del código generado por la
plantilla.
El proceso de generación del código inicial para una aplicación de cliente
enriquecido es realizado automáticamente por la plantilla seleccionada. En realidad
se tiene una mínima participación en esta primera tarea pues simplemente se es
responsable de suministrar algunos atributos como el nombre del proyecto,
configuración, identificador, proveedor, entorno de ejecución, la plataforma objetivo
en que está diseñado para ejecutar; los nombres de: la clase aplicación, el producto,
y del paquete que va a contener el código generado; que es responsabilidad de RCP,
una vez que se le haya indicado mediante los asistentes cuando efectuar esta
operación. De este proceso resultan, entre otras, cinco clases que son
fundamentales y siempre están presentes en la estructura de cualquier proyecto RCP
independientemente de la plantilla que haya sido escogida. A continuación se ofrece
una breve descripción de cada una de ellas.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
37
2.3.1 La clase Application.
Es necesario conocer que la plataforma SDK RCP que se emplea en la creación
de esta aplicación contiene únicamente librerías de componentes que incluso no
podemos ejecutar. Es como tener un JRE instalado, grandes cantidades de código,
pero que aún necesitan que se les diga qué hacer. La manera en que se hace esto
en la mayoría de los sistemas Java es escribiendo una clase que contiene un método
“main()”, pero en Eclipse se lleva a cabo de una forma diferente, se crea un punto de
extensión denominado: "org.eclipse.core.runtime.applications" cuya estructura xml es
la siguiente:
<extension id="application" point="org.eclipse.core.runtime.applications"> <application> <run class="uclv.cei.editorgmfrcp.application.ModeloApplication"> </run> </application> </extension>
La parte fundamental de este mecanismo se centra en la creación de lo que en
Eclipse RCP se denomina “application”, que consiste en un punto de entrada a un
programa o producto y que debe implementar la interfaz “IApplication” y así un
método llamado “start()”. El asistente PDE usa la plantilla “Mail RCP Template” para
generar el código que aparece a continuación y que corresponde a la
implementación de este mecanismo.
public class ModeloApplication implements IApplication { public Object start(IApplicationContext context) { Display display = PlatformUI.createDisplay(); try {
int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
if (returnCode == PlatformUI.RETURN_RESTART) { return IApplication.EXIT_RESTART; } return IApplication.EXIT_OK; } finally { display.dispose();
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
38
} }
}
Su funcionamiento se basa en crear una instancia de la clase “Display” y luego
iniciar un “Workbench” de Eclipse a través de la sentencia
“PlatformUI.createAndRunWorkbench(Display, WorkbenchWindowAdvisor)”. Esto
abre una ventana con soporte para la manipulación de eventos generados por
usuarios. El ciclo de eventos retorna finalmente cuando se cierra la última ventana o
cuando se le indica explícitamente que termine y antes de que retorne, el “Display”
creado debe liberar cualquier recurso del sistema que se le haya asignado.
2.3.2 La clase WorkbenchAdvisor.
En el código mostrado en la sección anterior se puede ver cómo la clase
“DiagramEditorWorkbenchAdvisor” es instanciada y pasada como parámetro dentro
de “PlatformUI.createAndRunWorkbench()”. La función de un “WorkbenchAdvisor” es
indicarle al “Workbench” cómo debe actuar, o sea, cómo dibujar, qué dibujar, entre
otras cosas. En el siguiente código correspondiente a nuestra aplicación se reflejan
dos indicaciones fundamentales: la perspectiva inicial que se debe mostrar y el
“WorkbenchAdvisor” que va a ser usado.
public class DiagramEditorWorkbenchAdvisor extends WorkbenchAdvisor { public WorkbenchWindowAdvisor createWorkbenchWindowAdvisor(IWorkbenchWindowConfigurer configurer) { return new DiagramEditorWorkbenchWindowAdvisor(configurer); } public String getInitialWindowPerspectiveId() { return DiagramEditorPerspective.ID; } }
2.3.3 La clase Perspective.
La perspectiva inicial es identificada por su identificador de extensión. Este
último le ofrece un nombre comprensible y especifica una clase que define, en
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
39
términos de posición, su disposición en la ventana. La clase especificada debe
implementar la interfaz “IPerspectiveFactory” y el método
“createInitialLayout(IPageLayout)”. El código generado por la plantilla en este sentido
es el siguiente:
public class DiagramEditorPerspective implements IPerspectiveFactory { public static final String ID = "uclv.cei.editorgmfrcp.application.DiagramEditorPerspective"; public void createInitialLayout(IPageLayout layout) { String editorArea = layout.getEditorArea(); layout.setEditorAreaVisible(false); layout.addStandaloneView(NavigationView.ID, false, IPageLayout.LEFT, 0.25f, editorArea); IFolderLayout folder = layout.createFolder("messages", IPageLayout.TOP, 0.5f, editorArea); folder.addPlaceholder(View.ID + ":*"); folder.addView(View.ID); layout.getViewLayout(NavigationView.ID).setCloseable(false); } }
2.3.4 La clase WorkbenchWindowAdvisor.
En cualquier aplicación, cada ventana posee un “WorkbenchWindowAdvisor” que
tiene la función de guiar la interfaz de usuario, en el ofrecimiento de las ventanas.
Estos asesores son consultados en varios momentos del ciclo de vida de una
ventana como por ejemplo en los eventos “preWindowOpen()” y
“postWindowCreate()” y tienen, además, la oportunidad de controlar la creación de
ventanas de contenido. En el caso particular de la aplicación EditorgmfRCP que se
desarrolla, es la clase “DiagramEditorWorkbenchWindowAdvisor” la encargada de
personalizar sus ventanas. A continuación se refleja el código generado para este
mecanismo:
public class DiagramEditorWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor { public DiagramEditorWorkbenchWindowAdvisor(IWorkbenchWindowConfigurer configurer) { super(configurer); }
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
40
public ActionBarAdvisor createActionBarAdvisor(IActionBarConfigurer configurer) { return new DiagramEditorActionBarAdvisor(configurer); } public void preWindowOpen() { IWorkbenchWindowConfigurer configurer = getWindowConfigurer(); configurer.setInitialSize(new Point(600, 400)); configurer.setShowCoolBar(true); configurer.setShowStatusLine(false); configurer.setTitle("EditorgmfRCP"); } }
En el método “preWindowOpen()” se establece el tamaño inicial y el título que va
a tener la ventana, así como las propiedades de otros componentes como: barras de
herramientas y de estado.
2.3.5 La clase ActionBarAdvisor.
Los componentes de la interfaz de usuario necesitan que se les diga qué hacer
una vez que se ha decidido usar cada uno de ellos. La idea en RCP del uso de los
llamados “ActionBarAdvisor” es para crear las acciones necesitadas por una ventana
y ubicarlas dentro de ella. La forma en que son instanciados es a través del método
“createActionBarAdvisor()” en la clase “DiagramEditorWorkbenchWindowAdvisor”. El
siguiente código ofrece la forma en que se implementa inicialmente esta propuesta
en la construcción de una aplicación de cliente enriquecido:
public class DiagramEditorActionBarAdvisor extends ActionBarAdvisor { public DiagramEditorActionBarAdvisor(IActionBarConfigurer configurer) { super(configurer); }
protected void makeActions(final IWorkbenchWindow window) {
}
protected void fillMenuBar(IMenuManager menuBar) {
}
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
41
protected void fillCoolBar(ICoolBarManager coolBar) {
}
}
2.4 Descripción del proceso de ejecución de una aplicación en Eclipse RCP.
La Figura 2.7 refleja de manera general el proceso de ejecución de la aplicación
EditorgmfRCP mediante la presentación de la relación que existe entre el IDE
instalado, el workspace sobre el cual se esta llevando a cabo su desarrollo y la
ubicación de los plug-ins propios que necesita, que en Eclipse se define como
“target”. Los plug-ins del Ambiente de Desarrollo Integrado están ubicados en la
propia instalación de la plataforma y constituyen el SDK de Eclipse. Al ejecutarlos se
inicia Eclipse, o sea, el IDE, que es usado para trabajar en el proyecto situado en el
área de trabajo. Sucede entonces que cuando se intenta ejecutar EditorgmfRCP el
entorno de desarrollo de plug-ins crea y lanza una configuración que se encarga de
recopilar los componentes que la aplicación requiere desde la ubicación que tengan
estos.
Figura 2.7 Relación entre IDE, “target” y “workspace”.
2.4.1 Configuraciones de ejecución.
A las opciones de configuración de ejecución se accede por esta vía: Run >Run
Configurations o también: Run >Run Debug Configurations. Ambas muestran
inmediatamente una ventana similar a la de la Figura 2.8.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
42
Figura 2.8 Ventana de configuraciones de ejecución.
El apartado titulado:”Main” es fundamental y se emplea para establecer los
siguientes parámetros de configuración:
El nombre de la configuración, que para esta aplicación es
“uclv.cei.editorgmfrcp.ModeloApplication”.
En la sección denominada: “Workspace Data” se define en qué ubicación
Eclipse pone su workspace o sus datos para el desarrollo. Es aquí donde
Eclipse almacena algunas preferencias e informaciones específicas de los
plug-ins y además, donde se guarda el archivo de registro si ocurre algún
error.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
43
También existe una sección destinada a identificar la “aplicación” de
EditorgmfRCP que se va a ejecutar. En este caso se especifica:
“uclv.cei.editorgmfrcp.ModeloApplication”.
La sección “Java Runtime Enviroment” está referida a la especificación de un
JRE para ser usado.
2.5 Incorporación del editor gráfico generado con GMF a la aplicación
EditorgmfRCP.
Como resultado del trabajo con GMF en Eclipse Galileo 3.5, se obtienen un
conjunto de plug-ins y clases java que se encargan de construir todo el editor gráfico
a partir de la definición ,que se haya realizado, del modelo de dominio que es donde
se especifican sus partes y la relación que existe entre cada una de ellas. De lo que
se trata es de “no reinventar la rueda”, o sea, de no volver a hacer algo que ya está
hecho, y mucho menos si se trata de la creación de un editor gráfico generado con
GMF pues las ventajas de esta tecnología en cuanto a tiempo de desarrollo,
reutilización, facilidad de uso y calidad del producto final, no son pocas.
2.5.1 Incorporación de los plug-ins del editor gráfico a la lista de dependencias
del proyecto.
Para que el proyecto de plug-in: “uclv.cei.editorgmfrcp” pueda hacer uso del
editor gráfico generado, se tienen que incluir, a su lista de requerimientos, cada uno
de los plug-ins generados. En la sección “Required Plug-ins” de la página
“Dependencies” del editor del plug-in, haciendo uso del botón “Add”, se pueden
adicionar estos como muestra la Figura 2.9.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
44
Figura 2.9. Adicionando los plug-ins de GMF al proyecto
Sin su incorporación al proyecto, no se pueden usar la mayoría de las clases
java generadas con GMF. Se ha incluido además, al directorio “src”, que contiene los
códigos fuentes de EditorgmfRCP, estas clases java agrupadas en varios paquetes,
que dan soporte a la estructura del editor. Al hacer estas operaciones, en el
explorador de paquetes del entorno de desarrollo de Eclipse se puede observar
como queda estructurado el proyecto. (Ver Figura 2.10 de los Anexos)
2.5.2 El editor “Modelo Diagram Editing”.
La Plataforma de cliente enriquecido de Eclipse, permite el desarrollo de
manera rápida de los elementos de la interfaz de usuario de una aplicación de este
tipo, pero GMF, como parte también de su infraestructura, se encarga de hacer todas
las funcionalidades del editor gráfico, el cual ahora puede ser simplemente reutilizado
en la aplicación EditorgmfRCP.
En la página “Extensions”, del editor de plug-ins se adiciona, primeramente, un
nuevo punto de extensión: “org.eclipse.ui.editors” como muestra la Figura 2.11. Al
hacer click derecho sobre el nuevo punto de extensión creado, se selecciona el menú
New> editor para crear el “editor” que va a dar soporte al editor gráfico. En la
sección que se refiere a los detalles de los elementos de las extensiones se llenan
los campos necesarios.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
45
Figura 2.11. Adicionado el punto de extensión “org.eclipse.ui.editors”
Como identificador o “ID” de esta extensión se ha especificado
“ModeloEntidadRelacion.ModeloEntidadRelacion.diagram.part.ModeloDiagramEditorI
D”, la clase que implementa “org.eclipse.ui.IEditorPart”, que es una interfaz
especializada en la estructura y funcionalidad de los editores, es
“ModeloEntidadRelacion.ModeloEntidadRelacion.diagram.part.ModeloDiagramEditor”
. Esta última es quien contiene el código para incorporar la paleta de herramientas
del editor gráfico, que en realidad solo hace una llamada al método “fillPalette()” de la
clase “ModeloPaletteFactory”; donde realmente se crea toda la estructura de la
paleta. La clase contribuyente para este “editor” es:
“ModeloDiagramActionBarContributor” la cual contiene elementos genéricos que son
aplicados a todos los editores.
2.5.3 Las vistas “Outline” y “Properties”.
La estructura de ambas vistas está contenida dentro del plug-in
“org.eclipse.ui.views” situado en la lista de dependencias de nuestro proyecto y se
puede acceder a su contenido abriendo este componente desde la página de
dependencias. Una vez que se muestre en el editor de plug-ins, solo resta echar una
mirada a sus extensiones que tienen un aspecto muy parecido al que se presenta en
la Figura 2.12 de los Anexos.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
46
2.5.4 Personalización de la posición en la ventana de los elementos de la
interfaz de usuario.
Al inicio del desarrollo de la aplicación EditorgmfRCP, cuando se tomó, como
base, la plantilla “Mail RCP Template” se creó una perspectiva, pero el contenido de
esta es simplemente un ejemplo que ofrece Eclipse RCP sobre su uso. Con el
objetivo de lograr la estructura deseada de los distintos elementos de la interfaz de
usuario, propios de esta aplicación, se debe sobrescribir el método
“createInitialLayout()” incorporándole las siguientes líneas de código:
public void createInitialLayout(IPageLayout layout) { layout.setEditorAreaVisible(true); layout .addPerspectiveShortcut( uclv.cei.editorgmfrcp.application.DiagramEditorWorkbenchAdvisor.PERSPECTIVE_ID); IFolderLayout right = layout.createFolder( "right", IPageLayout.RIGHT, 0.6f, layout.getEditorArea()); right.addView(IPageLayout.ID_OUTLINE); IFolderLayout bottomRight = layout.createFolder( "bottomRight", IPageLayout.BOTTOM, 0.6f, "right"); bottomRight.addView(IPageLayout.ID_PROP_SHEET); }
El resultado es la ubicación en la ventana de EditorgmfRCP, de estos elementos
de la manera siguiente: la vista “Outline”, en la parte superior derecha, la vista
“Properties”, ubicada en la parte inferior derecha, y a la izquierda de ambas,
ocupando todo el área restante, es el espacio reservado para el editor y todo su
contenido.
2.5.5 El asistente “Modelo Diagram”.
En Eclipse RCP, la creación de un “wizard” o asistente, es muy simple. En la
página de las extensiones del plug-in que se esta desarrollando, se adiciona el punto
de extensión: “org.eclipse.ui.newWizards”, y a continuación se agrega dentro de este,
un nuevo “wizard” con el nombre: “Modelo Diagram” y se especifica la clase que va a
contener su código que es:
“ModeloEntidadRelacion.ModeloEntidadRelacion.diagram.part.ModeloCreationWizard”.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
47
Esta clase se encarga de crear todo el contenido del asistente que va a ser mostrado a
los usuarios finales en el momento en que se indique a la aplicación la creación de un
nuevo diagrama de modelos y es la encargada además de mostrar el editor con su
paleta de herramientas una vez que el nuevo diagrama haya sido creado.
2.5.6 Adicionando una acción a la barra de menú de la aplicación.
El término “Actions” o acciones, en Eclipse, es usado para describir un
elemento visible en una aplicación que permite a los usuarios iniciar una unidad de
trabajo. Cuando se hace uso de los elementos de un menú, una barra de
herramientas, o cuando se invoca una secuencia de teclas, se ejecuta una acción.
Ha sido necesario sobrescribir varios elementos de la clase
“DiagramEditorActionBarAdvisor” creada por la plantilla pues su código muestra
simplemente cómo puede ser utilizada y EditorgmfRCP requiere de características
propias.
Con el propósito de crear el menú File> New> Modelo Diagram, se
sobrescribe el método “fillMenuBar()” de esta clase, adicionándole las líneas de
código siguiente:
{ IMenuManager menuX = new MenuManager( ModeloEntidadRelacion.ModeloEntidadRelacion.diagram.part.Messages.ApplicationMenuName_File, IWorkbenchActionConstants.M_FILE); menuX.add(new GroupMarker(IWorkbenchActionConstants.FILE_START)); { IMenuManager menuXX = new MenuManager( ModeloEntidadRelacion.ModeloEntidadRelacion.diagram.part.Messages.ApplicationMenuName_New, "new"); menuXX.add(new GroupMarker( IWorkbenchActionConstants.MB_ADDITIONS));
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
48
menuX.add(menuXX); }
Una vez creado el menú se procede a adicionar una acción para el mismo. En
la página de las extensiones se agrega a la lista un nuevo punto de extensión del tipo
“org.eclipse.ui.actionSets” y dentro de este se crea el “actionSet” o contenedor de
acciones con nombre “<Modelo Actions”, cuyo objetivo es simplemente agrupar
varias acciones. Como parte de este contenedor, se adiciona una nueva acción que
ha sido denominada “Modelo Diagram” que es implementada en la clase estática
“NewDiagramAction” y su tarea es iniciar el asistente “Modelo Diagram”. Por último,
en la sección que se refiere a los detalles de los elementos de la extensión, (Ver
Figura 2.13 de los Anexos), en el campo: “menubarPath:” se indica la ruta:
“file/new/additions” que lo que hace es adicionar esta acción creada al menú del
grupo indicado, en este caso hace referencia al menú New.
2.5.7 Descripción del proceso de “Branding” de EditorgmfRCP.
Para que EditorgmfRCP tenga la apariencia de una aplicación normal aun le
faltan algunos elementos como: imágenes en la barra de título de las ventanas, un
icono para su ejecutable y una imagen para mostrar al inicio conteniendo información
general del producto mientras se ejecuta (en Eclipse definido como: “splash screen”
o pantalla de bienvenida), entre otros componentes que la identifiquen de otras
aplicaciones. Este proceso de creación e incorporación de estos elementos es
denominado en Eclipse como “branding”.
2.5.8 Descripción de la definición del producto EditorgmfRCP.
Antes de realizar cualquier proceso, tanto de “branding” como de
“empaquetado”, de la aplicación, hay que definir una configuración del producto. Es
en esta configuración donde se recoge toda la información sobre el icono del
ejecutable, el “splash screen”, las imágenes de las ventanas, el texto del diálogo
“About”, la lista de plug-ins y otros componentes.
Para iniciar el asistente de configuración del nuevo producto (“New Product
Configuration”) presentado en la Figura 2.14 de los Anexos, primeramente se debe
seleccionar el proyecto “uclv.cei.editorgmfrcp” y en la perspectiva de desarrollo de
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
49
plug-ins se hace uso del menú File > New > Product Configuration. En este
asistente se debe seleccionar una localización para el archivo de configuración, se le
define además un nombre, que tiene que terminar en “.product” y por último, en la
sección destinada a la inicialización de su contenido se elige la opción referida a usar
una configuración de ejecución existente y se selecciona a continuación la que se
emplea en esta aplicación: “uclv.cei.editorgmfrcp.ModeloApplication”.
Al indicarle al asistente que finalice, este procede a leer la configuración de
ejecución y la utiliza para construir una definición del producto. Lo que hace es
obtener una lista de plug-ins e identificadores de las extensiones usadas en la
aplicación. La Figura 2.15, muestra la página principal del editor de configuración
para el nuevo producto creado.
En esta página del editor es donde se especifica el identificador (ID) del
producto, la versión y su nombre. Además, en la sección “Product Definition” se
especifican los identificadores de las extensiones del “producto” y de la “aplicación”.
Se necesita una definición del producto y un ID para guiar a Eclipse en el proceso de
identificación de EditorgmfRCP por lo que se debe dar click en el botón “New” para
visualizar el diálogo “New Product Definition” (ver Figura 2.16 de Anexos).
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
50
Figura 2.15 Página principal del editor de configuración para el nuevo producto
creado.
Una extensión “products” es contribuida mediante extensiones. Posee un ID e
identifica la “aplicación” que se va a ejecutar cuando se haya ejecutado el producto.
Se selecciona el plug-in EditorgmfRCP y en el campo “Product ID” se le asigna la
cadena de caracteres: “product”. Seguidamente se finaliza este “diálogo” para
retornar al editor donde esta nueva información se hará visible.
Para ofrecerle un nombre al producto simplemente nos dirigimos, en la página
principal de este editor, a la sección relacionada con la información general y en el
campo “Name” escribimos “EditorgmfRCP”. Ahora se debe ir a la clase
“DiagramEditorWorkbenchWindowAdvisor” y eliminar la llamada al método
“setTitle()”. Una vez realizado esto, al ejecutar la aplicación, se podrá ver el resultado
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
51
deseado en la etiqueta de la barra de título de la ventana de este prototipo de cliente
enriquecido.
2.5.9 Window Images.
Una vez que la aplicación tenga una configuración del producto y el título de las
ventanas configuradas correctamente, se puede proceder entonces a adicionarle
elementos denominados en Eclipse RCP: “graphical branding”, como el “splash
screen”, imágenes e iconos. Las imágenes de ventanas son aquellas que
normalmente se muestran ubicadas en la parte superior izquierda de las ventanas,
en las barras de tareas, y en otras localizaciones. En la página “Branding” del editor
del producto, en la sección “Window Images” se han identificado dos imágenes en
formato GIF para esta aplicación (Ver Anexos, Figura 2.17). Las imágenes se deben
incluir en una carpeta nombrada “icons” dentro del proyecto situado en el área de
trabajo sobre la cual se lleva a cabo el desarrollo.
2.5.10 Descripción de la personalización del ejecutable para la aplicación.
Un ejecutable es el programa que los usuarios finales ejecutan cuando desean
iniciar EditorgmfRCP, En este caso se ha definido como “editorgmfrcp” y esto se
realiza desde la sección “Program Launcher” de la página titulada “Launching” del
editor del producto, como muestra la Figura 2.18.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
52
Figura 2.18 Sección de configuración del ejecutable de la aplicación
Desde esta sección se puede definir además un icono para el ejecutable de
EditorgmfRCP que ha sido colocado en un directorio nombrado “branding” en el
workspace.
2.5.11 Descripción del “Splash Screen”.
Un “splash screen” es la primera parte visible de una aplicación y además de
contener una descripción muy general como el nombre y la versión tiene, además,
otra funcionalidad importante pues en caso de que el proceso de inicio de
EditorgmfRCP tome algún tiempo los usuarios finales podrán visualizar aun que se
está ejecutando la aplicación a pesar de la demora, ya que este cuenta también con
una barra de progreso que como su nombre indica, refleja el avance del proceso de
inicio. La Figura 2.19 muestra la sección “Location” de la página “Splash” del editor.
Eclipse determina que el “splash screen” para una aplicación RCP sea llamado
“splash.bmp” y lo único que se necesita hacer es identificar el plug-in que contiene el
archivo y hacer además un diseño propio para EditorgmfRCP. Al iniciar la aplicación
este diseño propio se hace visible en pantalla mostrando su contenido.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
53
Figura 2.19 Sección “Location” de la página “Splash” del editor.
2.5.12 Descripción de “About Information”.
En la mayoría de las aplicaciones, el diálogo “About” está presente. Este
contiene información para los usuarios acerca de la versión del producto, la licencia,
y los derechos de autor. Eclipse ofrece una propuesta de un diálogo estándar que
incluye toda esta información y ha sido seleccionado para formar parte de
EditorgmfRCP.
2.5.12.1Definición del contenido del diálogo “About”.
El diálogo “About” añadido anteriormente a esta aplicación aun está vacío y
necesita ser actualizado. El contenido que se desea agregar a este diálogo es
simplemente una imagen en formato GIF y un texto que va a estar situado en el
archivo “plugin.properties” con la información siguiente:
uclv.cei.editorgmfrcp/plugin.properties
aboutText=\n\nEditorgmfRCP (Workbench)\n\
Version: 1.0.0\n\n\
EditorgmfRCP is an RCP application developed in Eclipse Galileo 3.5\n\
(c) Copyright CEI. \
All Rights Reserved.\n
En la sección “About Dialog” de la página “Branding” del editor del producto,
como muestra la Figura 2.20, se definen tanto la imagen como el texto a mostrar,
donde este último se indica en el campo “Text”, por la cadena de caracteres
“%aboutText” que es la manera en que se hace referencia al valor de la variable
“aboutText” ubicada en el archivo “plugin.properties”.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
54
Figura 2.20 Definición de la imagen y el texto para el diálogo “About.”
Es necesario conocer que si la imagen es tan pequeña como de 250x330 pixels,
este texto será visualizado a su derecha en el diálogo; pero si es superior a los
500x330 pixels ocuparía toda la región del diálogo y en ese caso no sería posible
mostrar el texto.
2.5.13 Descripción del proceso de “Packaging” de EditorgmfRCP.
La aplicación EditorgmfRCP ya cuenta con una configuración del producto
realizada correctamente. Ya posee todos los elementos que constituyen la marca del
producto, como imágenes de ventanas, icono y nombre del ejecutable, una pantalla
de bienvenida y un dialogo “About” personalizado; pero aun vive solamente en el
área de trabajo del proyecto de plug-in por lo que necesita ser empaquetado y
exportado para que pueda funcionar fuera del workspace.
2.5.14 Exportando EditorgmfRCP.
Antes de exportar la aplicación EditorgmfRCP, se tienen que identificar qué
partes del proyecto “uclv.cei.editorgmfrcp” van a ir dentro del plug-in
“uclv.cei.editorgmfrcp”. Se debe abrir el editor de plug-ins para esta aplicación e ir a
la página “Build”. La sección “Binary Build” de esta página, mostrada en la Figura
2.21, presenta una lista del conjunto de archivos de tiempo de desarrollo y carpetas
que forman parte también de la estructura del tiempo de ejecución del plug-in.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
55
Figura 2.21 Sección “Binary Build” de la página “Build”.
El entorno de desarrollo de plug-ins se encarga de adicionar las clases Java
compiladas a la salida de compilación, pero se debe tener en cuenta que es
necesario administrar los otros archivos pues han sido incorporados en diferentes
etapas del desarrollo y hay que incluirlos también en la salida. Cada uno de los
recursos que necesita la aplicación se tiene que seleccionar en la lista para evitar
que al exportar, varios elementos tales como imágenes y mensajes de texto no
resulten faltantes.
Para iniciar el proceso de exportación de la aplicación EditorgmfRCP, en el
Explorador de Paquetes o en el Navegador, se localiza y se selecciona el archivo
“editorgmfrcp.product”, se hace click derecho sobre él y se escoge el menú:
Export…>Eclipse product. Alternativamente se puede abrir el editor del producto e
ir a la página principal y dar click en el enlace “Product Export wizard”. A través de
cualquiera de estas vías, se inicia el asistente “Product Export” que tiene un aspecto
similar al de la Figura 2.22.
La configuración del producto, de EditorgmfRCP, tiene que estar seleccionada en la
lista desplegable que aparece en el campo que hace referencia a la “configuración”.
En este asistente se especifica además el nombre del directorio raíz que va a
contener el producto exportado y en este caso se ha usado “EditorgmfRCP 1.0”.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
56
Figura 2.23 Asistente de exportación del producto.
Se recomienda marcar la opción encargada de sincronizar esta configuración
antes de exportar el producto, ya que esto reduce el riego de presentar problemas
durante la ejecución de este proceso. Posteriormente se indica una localización
conveniente para ubicar la salida, por ejemplo: “C:\”, se seleccionan las opciones
deseadas en el apartado referido a las opciones de exportación y al dar click en el
botón “Finish”, el entorno de desarrollo de plug-ins inicia la exportación de
EditorgmfRCP.
Una vez finalizado el proceso, en la ubicación: “C:\EditorgmfRCP 1.0” estará
situado el contenido del producto final que ya está listo para ser ejecutado fuera del
workspace. En el directorio raíz de los elementos que han sido exportados se puede
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
57
notar que el ejecutable tiene un icono como resultado del proceso de personalización
del mismo. Si se ejecuta el archivo “editorgmfrcp.exe” se puede utilizar este producto
RCP completamente configurado con cada uno de sus componentes definidos, asi
como sus funcionalidades.
Capítulo 2. Desarrollo de aplicaciones en Eclipse utilizando RCP
58
Conclusiones parciales
En este Capítulo se realizó una descripción del proceso de creación de una
aplicación de cliente enriquecido destacándose además algunas de las facilidades de
uso que posee este tipo de cliente y resaltándose su utilidad para la integración con
GMF. Se llevó a cabo la selección de una plantilla básica como parte de este proceso
de desarrollo de aplicaciones de cliente enriquecido y se hizo una breve explicación
de los aspectos fundamentales del código generado por la plantilla seleccionada. Se
estableció el procedimiento para incorporar el editor gráfico generado con GMF a la
aplicación EditorgmfRCP.
Conclusiones
59
CONCLUSIONES
Como resultado de esta investigación, se ha arribado a las conclusiones siguientes:
1. Se realizó un profundo análisis de las principales características y
herramientas que tiene una aplicación de cliente enriquecido sobre el Entorno
de Desarrollo Integrado Eclipse y para apoyar esta idea se hizo una
descripción de cada uno de los elementos principales que integran una
aplicación de este tipo y se destacaron algunas de las ventajas que
proporciona la Plataforma de Cliente Enriquecido. Se llevó a cabo una breve
explicación de la tecnología GMF teniendo en cuenta la importancia que
representa para este trabajo el plug-in que se obtiene de este framework.
2. Se desarrolló la aplicación EditorgmfRCP basada en la tecnología RCP
como caso de estudio y se realizó una descripción paso a paso del proceso de
creación de una aplicación de cliente enriquecido, a partir de de este prototipo.
Además, se dio a conocer su utilidad para la integración con GMF.
3. Se efectuó una comparación entre las plantillas básicas para el desarrollo
de aplicaciones RCP y se realizó la selección de una de ellas, “Mail RCP
Template”, como punto de partida del proceso de creación de una aplicación
de este tipo, además, se hizo una breve explicación de los aspectos
fundamentales del código generado por la plantilla seleccionada.
4. Se estableció el procedimiento para incorporar el editor gráfico generado
con GMF a la aplicación EditorgmfRCP.
Recomendaciones
60
RECOMENDACIONES
Derivadas de la investigación realizada, así como de las conclusiones generales
emanadas de la misma, se recomienda:
1. Realizar un estudio y análisis detallados de la estructura de objetos con que
trabaja el editor gráfico de diagramas Entidad-Relación generado con GMF y
de ser necesario se cree una estructura propia con el propósito de incorporar a
la aplicación los algoritmos de validación que forman parte de los
requerimientos del proyecto ERECASE que se desarrolla en el grupo de
Bases de Dato del Centro de Estudios de Informática.
Referencias bibliográficas
61
REFERENCIAS BIBLIOGRÁFICAS
Boudreau, T., Tulach, J. & Wielenga, G. (2007): Rich Client Programming: Plugging
into the NetBeans™ Platform, 1st. ed., Prentice Hall. p 640.
Carlson, D. (2005): Eclipse Distilled, 1st. ed., Addison Wesley Professional. p 312.
Clayberg, E. & Rubel, D. (2008): Eclipse Plug-ins, 3rd. ed., Addison-Wesley
Professional. p 928.
Gallardo, D., Burnette, E. & McGovern, R. (2003): Eclipse in Action: A Guide for the
Java Developer, 7th. ed., Manning Publications. p 380.
McAffer, J., Lemieux, J.-M. & Aniszczyk, C. (2010a): Eclipse Rich Client Platform,
2nd. ed., Addison-Wesley. p 518.
McAffer, J., VanderLei, P. & Archer, S. (2010b): OSGi and Equinox: Creating Highly
Modular Java Systems, 1st. ed., Addison-Wesley Professiona. p 460.
Moore, W., Dean, D., Gerber, A., Wagenknecht, G. & Vanderheyden, P. (2004):
Eclipse Development using the Graphical Editing Framework and the Eclipse
Modeling Framework, 1st. ed., Redbooks. p 238.
Silva, V. (2009): Practical Eclipse Rich Client Platform Projects, 1st. ed., Apress. p
335.
Steinberg, D., Budinsky, F., Paternostro, M. & Merks, E. (2008): EMF: Eclipse
Modeling Framework 2nd. ed., Addison-Wesley Professional. p 744.
Anexos
62
ANEXOS
Figura 2.1 Página de las plantillas RCP.
Anexos
63
Figura 2.3 Página principal del editor de plugins.
Anexos
64
Figura 2.4 Apariencia inicial del prototipo creado por la plantilla “Mail RCP Template”
Figura 2.10. Estructura del proyecto en el Explorador de Paquetes de Eclipse.
Anexos
65
Figura 2.12 Página de extensiones del plug-in “org.eclipse.ui.views”.
Figura 2.13 Detalles de los elementos de la acción “Modelo Diagram”.
Anexos
66
Figura 2.14 Asistente de configuración del producto.
Anexos
67
Figura 2.16 Diálogo “New Product Definition.”
Figura 2.17 Sección “Window Images” de la página “Branding”.