Facultad de Matemática, Física y Computación Carrera ...

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.


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.


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


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.


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.


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.


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


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.


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


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


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.


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.


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).


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


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.


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


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


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,


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:


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


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


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.


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


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.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.products

org.eclipse.ui.commands


org.eclipse.ui.views


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.


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


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


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.


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


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.


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();


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


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); }


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) {

}


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.


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.


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.


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.


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.


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”.


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));


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


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).


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


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.


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.


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”.


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.


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”.


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


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.


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”.

Facultad de Matemática, Física y Computación Carrera ...

Documents

Transcript of Facultad de Matemática, Física y Computación Carrera ...