JGoodies nos ofrece más pequeños regalos

JGoodies, un portal que se garantiza por ofrecer aplicaciones comerciales con un aspecto gráfico muy cuidado, nos sorprende de nuevo ofreciendonos varias librerías que permiten su uso no comercial gratuitamente.
JGoodies Animation, es una librería que permite la creación de animaciones en tiempo real.
JGoodies Plastic L&F Family es un look&feel muy elegante y que funciona en múltiples plataformas.
JGoodies Forms es una librería para el diseño de formularios en interfaces gráficas. Introduce un nuevo layout manager, el FormLayout, que permite la creación rápida y sencilla de formularios en aplicaciones.
En todos los enlaces podéis encontrar capturas de pantalla que muestran la calidad de los productos.
Que los disfrutéis.

Procesos de desarrollo

Procesos de desarrollo: RUP, XP y FDD

Fecha de creación: 15.12.2002

Revisión 1.0 (15.2.2003)

Alberto Molpeceres
al AT javahispano DOT org

Copyright (c) 2002, Alberto Molpeceres. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).

Introducción

El mundo de la informática no para de hablar de procesos de desarrollo, el modo de trabajar eficientemente para evitar catastrofes que llevan a que un gran porcentaje de proyectos se terminen sin éxito.

El objetivo de un proceso de desarrollo es subir la calidad del software (en todas las fases por las que pasa) a través de una mayor transparencia y control sobre el proceso. Da igual si es algo casero o para un cliente, hay que producir lo esperado en el tiempo esperado y con el coste esperado. Es labor del proceso de desarrollo hacer que esas medidas para aumentar la calidad sean reproducibles en cada desarrollo.

La implantación de un proceso de desarrollo es una labor más a medio-largo plazo que una labor de resultados inmediatos. Cuesta tiempo que los trabajadores se adapten al proceso, pero una vez superado la inversión se recupera con creces. Es por ello que no tiene sentido ajustarse a un proceso al pie de la letra, sino que hay que adaptarlo a las necesidades y caracteristicas de cada empresa, equipo de trabajo o casi a cada proyecto.

Es labor del jefe de desarrollo decidir cual es el que mejor se adapta a la situación concreta a la que se enfrenta para minimizar la inversión requerida y obtener los resultados esperados. Por ejemplo, ¿tenemos el conocimiento necesario?, ¿es el equipo abierto a posibles cambios?. Esta labor es difícil de llevar a cabo si no conocemos las exigencias de los procesos existentes. Para facilitar esa decisión, en este artículo describiremos y compareramos tres de los más famosos y conocidos procesos de desarrollo: Proceso Unificado de Rational, Rational Unified Process
(RUP desde ahora), Programación Extrema, eXtreme Programming (XP desde ahora)
y Desarrollo Guiado por la Funcionalidad Feature Driven Development (FDD desde ahora).

Lo que en ningún caso será este artículo es una guía exhaustiva de aplicación de ninguno de ellos, dejando para el lector interesado la profundización en cualquiera de ellos y su aplicacicación donde lo estime oportuno.

Procesos de desarrollo

En los últimos tiempos la cantidad y variedad de los procesos de desarrollo ha aumentado de forma impresionante, sobre todo teniendo en cuenta el tiempo que estuvo en vigor como ley única el famoso desarrollo en cascada. Se podría decir que en estos últimos años se han desarrollado dos corrientes en lo referente a los procesos de desarrollo, los llamados métodos pesados y los métodos ligeros. La diferencia fundamental entre ambos es que mientras lo métodos pesados intentan conseguir el objetivo común por medio de orden y documentación, los métodos ligeros (también llamados métodos ágiles) tratan de mejorar la calidad del software por medio de una comunicación directa e inmediata entre las personas que intervienen el el proceso.

En este artículo, como ya hemos dicho, hablaremos de RUP, un proceso pesado, de XP, un proceso ligero, y de FDD, un proceso cuya catalogación depende de los gustos, siendo ligero para la gente que considera más acertados los pesados, y pesado para los seguidores de los ligeros.

RUP

RUP es uno de los procesos más generales del los existentes actualmente, ya que en realidad esta pensado para adaptarse a cualquier proyecto, y no tan solo de software.

Un proyecto realizado siguiendo RUP se divide en cuatro fases:

1. Intercepción (puesta en marcha)
2. Elaboración (definición, análisis, diseño)
3. Construcción (implementación)
4. Transición (fin del proyecto y puesta en producción)

Lista 1: Fases de RUP

En cada fase se ejecutarán una o varias iteraciones (de tamaño variable según el proyecto), y dentro de cada una de ellas seguirá un modelo de cascada o waterfal para los flujos de trabajo que requieren las nueva actividades anteriormente citadas.

Figura 1: Vista general de RUP

RUP define nueve actividades a realizar en cada fase del proyecto

1. Modelado del negocio
2. Análisis de requisitos
3. Análisis y diseño
4. Implementación
5. Test
6. Distribución
7. Gestión de configuración y cambios
8. Gestión del proyecto
9. Gestión del entorno

Lista 2: Actividades de RUP

y el flujo de trabajo (workflow) entre ellas en base a los llamados
diagramas de actividad. El proceso define una serie de roles que se
distribuyen entre los miembros del proyecto y que definen las tareas de
cada uno y el resultado (artefactos en la jerga de RUP) que se espera de ellos.

Figura 2: Flujos de trabajo de RUP

RUP se basa en casos de uso para describir lo que se espera del software
y esta muy orientado a la arquitectura del sistema,
documentándose lo mejor posible, basándose en UML (Unified Modeling Language) como herramienta principal.

RUP es un proceso muy general y muy grande, por lo que antes de usarlo habrá que adaptarlo a las características de la empresa. Por suerte ya hay muchos procesos descritos en internet que son versiones reducidas del RUP.

XP

Mientras que el RUP intenta reducir la complejidad del software por medio de estructura y la preparación de las tareas pendientes en función de los objetivos de la fase y actividad actual, XP, como toda metodología ágil, lo intenta por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reacción.

XP intenta minimizar el riesgo de fallo del proceso por medio de la disposición permanente de un representante competente del cliente a disposición del equipo de desarrollo. Este representante debería estar en condiciones de contestar rápida y correctamente a cualquier pregunta del equipo de desarrollo de forma que no se retrase la tomar de decisiones, de ahí lo de competente.

XP define UserStories como base del software a desarrollar. Estas historias las escribe el cliente y describen escenarios sobre el funcionamiento del software, que no solo se limitan a la GUI si no también pueden describir el modelo, dominio, etc. A partir de las UserStories y de la arquitectura perseguida se crea un plan de releases (dejaré el término en inglés, pues las habituales traducciones al castellano, liberación o entrega del software, no son de mi agrado, supongo que son cosas de vivir en el extranjero) entre el equipo de desarrollo y el cliente.

Para cada release se discutirán los objetivos de la misma con el representante del cliente y se definirán las iteraciones (de pocas semanas de duración) necesarias para cumplir con los objetivos de la release. El resultado de cada iteración es un programa que se transmite al cliente para que lo juzgue. En base a su opinión se definen las siguientes iteraciones del proyecto y si el cliente no esta contento se adaptará el plan de releases e iteraciones hasta que el cliente de su aprobación y el software este a su gusto.

Junto a los UserStories estan los escenarios de pruebas que describen el escenario contra el que se comprueba la realización de las UserStories. UserStories y casos de pruebas son la base sobre la que se asienta el trabajo del desarrollador.

Como primer paso de cada iteracion se escribirán las pruebas, de tal forma que puedan ser ejecutadas automáticamente, de manera que pueda comprobarse la correción del software antes de cada release. Esto es de vital importancia en XP debido a su apuesta por las iteraciones cortas que generan software que el cliente puede ver y por la refactorización para mejorar el código constantemente, que hacen más que deseable una cantidad considerables de test lo más automatizables posible. Asi pués, la funcionalidad concreta del software solo se escribe cuando las pruebas para su corrección esten preparadas.

Figura 3: Vista general de XP

La codificación del software en XP se produce siempre en parejas (dos programadores, un ordenador), por lo que se espera que la calidad del mismo suba en el mismo momento de escribirlo. Al contrario que muchos otros métodos, el código pertenece al equipo en completo, no a un programador o pareja, de forma que cada programador puede cambiar cualquier parte del codigo en cualquier momento si así lo necesita, dejándose en todo caso las mejoras orientadas al rendimiento para el final. Las parejas no se mantienen para todo el proyecto si no que rotan ciclicamente a lo largo del mismo, tanto en cuanto a los componentes de la misma como en las partes del software que desarrollan, asi cada componente del equipo aprende como trabaja el resto. El objetivo ideal sería que cada compontente del equipo trabaje al menos una vez con cada uno de los demás integrantes y con cada componente software, de forma que el conocimiento de la aplicación completa lo posea el equipo entero y no unos pocos miembros.

En XP se programará solo la funcionalidad que es requerida para la release actual. Es decir, una gran flexibilidad y capacidad de configuración solo será implementada cuando sea necesaria para cumplir los requerimientos de la release. Se sigue un diseño evolutivo con la siguiente premisa: conseguir la funcionalidad deseada de la forma más sencilla posible. De ahí una variación educada del famoso KISS (Keep It Simple Stupid), Keep things as simple as possible (manten las cosas tan sencillas como sea posible). Este diseño evolutivo hace que no se le de apenas importancia al análisis como fase independiente, puesto que se trabaja exclusivamente en función de las necesidades del momento.

FDD

FDD es un proceso diseñado por Peter Coad, Erich Lefebvre y Jeff De Luca y se podría considerar a medio camino entre RUP y XP, aunque al seguir siendo un proceso ligero (en mi opinión, si tenemos que distinguir entre pesado/ligero) es más similar a este último.

FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un año). Se basa en un proceso iterativo con iteraciones cortas (~2 semanas) que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar.

Las iteraciones se deciden en base a features
(de ahí el nombre del proceso)
o funcionalidades, que son pequeñas partes del software con significado
para el cliente. Así, contruir el sistema de ventas
es algo que requiere
mucho tiempo, y contruir el sistema de persistencia
no tiene significado
para el cliente, pero si lo tiene enviar pedido por email.

Un proyecto que sigue FDD se divide en 5 fases:

1. Desarrollo de un modelo general
2. Contrucción de la lista de funcionalidades
3. Plan de releases en base a las funcionalidades a implementar
4. Diseñar en base a las funcionalidades
5. Implementar en base a las funcionalidades

Lista 3: Fases de FDD

Figura 4: Vista general de FDD

Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.

El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque siempre habrá un responsable último (arquitecto jefe o jefe de programadores en función de la fase en que nos encontremos), con mayor experiencia, que tendrá la última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue que todos formen parte del proyecto y que los menos inexpertos aprendan de las discusiones de los mas experimentados, y al tener un responsable último, se asignan las responsabilidades que todas las empresas exigen.

Las funcionalidades a implementar en una release se dividen entre los distintos subgrupos del equipo, y se procede a implementarlas. Las clases escritas tienen propietario (es decir, solo quién las crea puede cambiarlas), es por ello que en el equipo que implementa una funcionalidad dada deberán estar todos los dueños de las clases implicadas, pudiendo encontrarse un programador en varios grupos, implementando distintas funcionalidades. Habrá también un programador jefe (normalmente el más experimentado) que hará las funciones de lider del grupo que implementa esa funcionalidad.

En el proceso de implementar la funcionalidad también se contemplan como partes del mismo (en otros métodos se describen como actividades independientes) la preparación y ejecución de pruebas, así como revisiones del código (para distribuir el conocimiento y aumentar la calidad) e integración de las partes que componen el software.

FDD también define métricas para seguir el proceso de desarrollo de la aplicación, útiles para el cliente y la dirección de la empresa, y que pueden ayudar, además de para conocer el estado actual del desarrollo, a realizar mejores estimaciones en proyectos futuros.

La comparación

Podríamos pensar que no es posible comparar los distintos métodos de desarrollo, y que todo depende de nuestros gustos personales, pero puesto que todos los procesos se centran en la producción de software (orientado a objetos mayormente) y que el proceso se implantará para aumentar la calidad del software producido y la eficiencia de los desarrolladores, es deseable una comparación, pero no en su conjunto, sino según los medios que emplean y sus resultados.

RUP, XP y FDD tienen pocas similitudes entre si, aunque XP y FDD poseen algunas más al ser ambos ligeros, orientados al cliente y de iteraciones cortas y rápidas. También hay que decir que debido al carácter general de RUP, algunos autores consideran todos los demás procesos de desarrollo como casos particulares de este.

Tamaño de los equipos

RUP esta pensado para proyectos y equipos grandes, en cuanto a tamaño y duración. FDD y XP se implementan mejor para proyectos cortos y equipos más pequeños, siendo quizás FDD más escalable que XP, ya que a mayor tamaño de código y/o equipo mayor es la necesidad de cierta organización.

Obtención de requisitos

RUP y XP crean como base UseCases y UserStories, ambos describen los requerimientos de la aplicación desde el punto de vista del usuario. Ambos definen los requisitos técnicos sin meterse con detalles de implementación. FDD por el contrario no define explícitamente esa parte del proyecto sobre la adquisición de requisitos, y solo define el proceder a partir del momento en que ya se han recogido dichos requisitos, de la forma que queramos, dividiendo los requisitos (de forma similar a las UserStories) en las tres primeras fases del proyecto.

Carga de trabajo

XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los desarrolladores (como modelado, generación de documentación externa, etc), cuyo efecto se minimiza por medio de la presencia de un representante del cliente. En el desarrollo de un projecto con XP es más importante la entrega al cliente del software que necesita (lo que muy a menudo no es lo mismo que lo descrito en el documento de especificación de requisitos) que las funcionalidades que quedan por implementar. Cuando durante el desarrollo se descubre que se deben cambiar las funcionalidades, se acuerda directamente con el representante del cliente. Con esos cambios se ajustará el plan de iteraciones y el de releases y se tomará la nueva dirección en el desarrollo.

RUP es un proceso pesado, basado mucho en la documentación, en la que no son deseables todos esos cambios volátiles. Existen diferentes elementos de planificación (plan de desarrollo, plan de iteración, plan de calidad, etc.) con los que se controla el desarrollo del software. A través de un predefinido esquema de escalabilidad y gestión de riesgos, se pueden reconocer previamente problemas y fallos de forma temprana y prevenirlos/corregirlos. RUP define en cada momento del ciclo de vida del proyecto, que artefactos, con que nivel de detalle, y por qué rol, se deben crear. Se definirán que artefactos son necesarios para poder realizar una actividad y que artefactos se deberán crear durante dicha actividad.

FDD es por su parte un proceso intermedio, en el sentido de que genera más documentación que XP (donde apenas existe fuera del código fuente) pero menos que RUP (que intenta documentar todo). Se entrega bastante libertad a los desarrolladores, pero siempre bajo cierto orden marcado por una jerarquía (arquitecto, programador jefe, etc), que representa también en nivel de responsabilidad existente en cada caso.

Relación con el cliente

Con RUP se presentarán al cliente los artefactos del final de una fase y se valorarán las precondiciones para la siguiente (definición de riesgos, aceptación del plan de iteracion, prototipos, etc) y solo después de que el cliente acepte los artefactos generados se pasará a la siguiente fase. La calidad de los artefactos generados será probada durante la totalidad del ciclo de vida del proyecto a través de distintas medidas de calidad, como convenciones, revisiones y auditorías periódicas, pruebas, etc.

En contrapartida, la aseguración de la calidad en XP y FDD no se basa en formalismos en la documentación, si no en controles propios y una comunicación fluida con el cliente. Tanto en XP como en FDD, el cliente recibe después de cada iteración un pedazo funcional del programa. A través de un ciclo de iteración corto (pocas semanas) el cliente está informado constantemente sobre la situación del proyecto y puede intervenir rápidamente si el desarrollo se aleja de sus necesidades.

En XP el desarrollo ve en que dirección debe ir gracias al feedback del cliente, sin ningún tipo de restricción previa. En FDD sin embargo existe el modelo general desarrollado en la primera fase, que si bien evoluciona a lo largo del proyecto, provee un marco general dentro del cual evoluciona el proyecto (mientras no sea necesario cambiarlo).

Desarrollo

Todos ellos se basan en un proceso iterativo. Esto permite acercarse poco a poco a la solucion sin entrar demasiado rápido en detalles, aunque las iteraciones de XP y FDD tienen por lo general una duración menor que en RUP, puesto que la carga a llevar por los programadores a parte del desarrollo del propio software es menor.

XP esta diseñado con los programadores en mente, con facilitar su trabajo y es por ello que define casí todo el proceso de desarrollo al completo, incluido el de pruebas y integración. RUP y FDD se centran más en la organización global, y muchas de esas actividades, como ejecución de pruebas, las asumen como obligatorias aunque sin definirlas completamente, dejando libertad a las distintas subunidades del proyecto para implementarlas a su manera (por ejemplo usar la programación por parejas en partes complejas), aunque las directrices de la empresa suelen marcar el camino a seguir.

Debido a que las releases se producen a menudo, XP afirma la necesidad de que se puedan realizar pruebas automáticas. La implementación de las pruebas antes que la propia funcionalidad hace que el desarrollador tenga que pensar pronto sobre lo que tiene que hacer y como probarlo correctamente. A través de pruebas automáticas se conseguirá que la funcionalidad se ajuste a los esperado por cada release, de modo que es importante que solo se envie al cliente código que pase al 100% las pruebas. Este es en todo caso un punto deseable en cualquier proceso de desarrollo.

RUP genera también releases basados en los artefactos después de cada fase, pero en su caso no se limitan solo al código, si no que las releases viene acompañada de todo lo que traería el producto final, es decir, notas de la versión, instrucciones de instalación, ayuda de uso, etc.

Código fuente

XP es el único que presenta la compartición del código, mayormente debido a que esta pensado para equipos pequeños que trabajan conjuntamente y con comunicación constante e inmediata, mientras que los otros dos procesos optan por la propiedad del código, aunque definen grupos y sesiones de trabajo conjuntos de forma que los propietarios de clases relacionadas trabajan juntos, y la comunicación es directa.

Conocimiento sobre la arquitectura

En XP se conseguirá a través de la programación a pares que ya en la creación del código se puedan evitar errores y malos diseños ya que se controlará cada línea de código y decisión de diseño instantaneamente. Se espera que la buena conexión entre ambos desarrolladores genere discusiones que lleven a mejores estructuras y algoritmos y que este proceso aumente la calidad del software de tal manera que compense el coste de la programación por parejas. También se intentará aumentar el conocimiento sobre el conjunto de la aplicación a través de la rotación de los miembros del equipo sobre los componentes y emparejamientos.

En RUP se intentará reducir la complejidad del software a producir a través de una planificación intensiva. Así se intentará evitar que por la desaparación de alguna pieza clave del equipo se pierda el conocimiento sobre la aplicación.

En FDD sin embargo se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una arquitectura sencilla y sin errores y las revisiones de código guiadas por algún programador con más experiencia. Estas sesiones, habituales en cada equipo e iteración, estan más enfocadas al trabajo en conjunto que al intercambio de impresiones y/o estado, como podría ser el caso de las daily meetups de XP.

En todo caso, como no podría ser de otra forma, todos los métodos de desarrollo modernos ponderan la utilización frecuente de reuniones entre los miembros del equipo, que pueden ir desde diarias, como propone XP, a semanales o mensuales, de duración de minutos o de horas, según los objetivos de la reunión.

Evaluación del estado del proyecto

FDD es posiblemente el proceso más adecuado para definir métricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeñas es bastante sencillo hacer un seguimienmto de las mismas. XP también define esos componentes pequeños, pero la tarea del reporting recae solo en los jefes de proyecto, mientras que en FDD esta más distribuida en la jerarquia. RUP por su parte, es tan grande y complejo en este sentido como en el resto, por lo que manejar el volumen de información que puede generar requiere mucho tiempo.

Puntos flacos.

Por desgracia ninguno de estos procesos puede ser considerado perfecto, ni ser aplicado en su totalidad en en la mayoría de los casos, por lo que también es necesario saber donde estan sus puntos débiles para corregirlos, si es necesario.

XP es un proceso muy orientado a la implementación. Debido al bajo número de documentos a generar, se ofrece al desarrollador un escenario ideal para participar en el proyecto. Este proceso es aceptado con el mejor grado por desarrolladores menos experimentados ya que pueden sacar provecho directo de los compañeros más experimentados.

También el cliente esta contento porque recibe un software que se adapta a sus deseos exactamente, mientras disponga de tiempo y dinero, pero ya que la funcionalidad exacta del software final nunca se definió formal y contractualmente (definirlo sería un contrasentido para XP, puesto que impediría el transcurso normal del proyecto guiado por el feedback del cliente), este método de desarrollo es quizás más aplicable para desarrollos internos, ya que para proyectos externos existe el problema concreto de que se debe realizar muy pronto una oferta concreta que defina que funcionalidad se va a implementar y en que periodo de tiempo, lo que también es importante para el cliente, ya que debe estar en la posición de comprobar tanto el rendimiento como la calidad y el contenido del software y estar seguro de recibirlo cuando lo espera.

Se debe, en todo caso, tener una gran confianza entre el cliente y el equipo de desarrollo (o su empresa) para usar el XP para escribir el software. Se podría considerar que la solución (teórica) a este problema es la presencia del representante del cliente junto al equipo de desarrollo, pero es también poco probable que el cliente pueda prescindir de los empleados que reunen las características requeridas, puesto que suelen ser poco menos que imprescindibles, y la solución habitual de que un miembro del equipo tome el rol de representante del cliente no siempre puede ser acertada, ya que aunque la empresa desarrolladora tenga un experto en el dominio del problema, puede desconocer gran parte de las particularidades de la empresa del cliente, como políticas internas o particularidades remarcables.

La programación por parejas es un interesante punto a favor de XP, hasta el punto de que quizás debería ser utilizado por cualquier otro método en determinadas ocasiones (algoritmos complejos, nuevos miembros del equipo con poca experiencia o malos hábitos, etc.), pero esta por ver hasta que punto el coste que supone es asumible por una empresa, y hasta que punto se puede producir el ambiente que presupone XP (a fín de cuentas a nadie le gusta estar mirando mientras otro esta delante de su ordenador). En todo caso, como ya se ha dicho en repetidas ocasiones, en muchos momentos del proceso de desarrollo, el trabajo en equipo solo puede ser beneficioso. Miembros del equipo con menos experiencia pueden aprender a partir de discusiones sobre una arquitectura más que cuando ya la reciben definida y solo la tienen que implementar y/o completar. Si se debe seguir este modo de trabajo en todas las fases del desarrollo del software depende en gran medida del problema concreto en cuestión y del propio equipo.

Lo que es muy poco deseable en XP es el hecho de evitar cualquier tipo de documentación fuera del código fuente (UML juega un papel prácticamente nulo, por ejemplo). Es asumible y aceptable que solo el propio código contenga la documentación actualizada, pero esto supone carencias que debemos tener en cuenta ya que puede no representar todo lo que debería (dependencias entre componentes, por ejemplo) y hace difícil utilizar la experiencia ganada en otros desarrollos (con otros equipos o por otras parejas), ya que no se ha anotado o archivado nada y se debe generar todo desde cero.

FDD presenta su talón de Aquiles en la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el principio, con la elaboración del modelo global, puesto que no es tan ágil como podría serlo XP. Es en todo caso este requisito una necesidad en cualquier proyecto si queremos llevarlo a buen puerto con éxito. Su punto intermedio entre la libertad de XP y la rigurosidad de RUP lo hacen sin duda un proceso interesante, pero a pesar de cambiar la forma de afrontar el problema, la jerarquía existente puede hacer que las dependencias de esa gente experimentada sean grandes.

El problema de usar RUP esta en otro campo completamente distinto. Para el desarrollo de software por medio de equipos pequeños (hasta unas diez personas) es RUP definitivamente muy grande y practicamente inalcanzable. Se deben repartir 31 roles y generar más de 100 artefactos distintos. Esto supone que antes de implentar RUP se debe adaptar hasta el punto de hacerlo parecer otro proceso, lo que también requiere su tiempo y tiene su coste.

Si el proyecto es suficientemente grande como para compensar la adaptación a RUP, entonces es una buena base para el proceso, para conseguir una mayor y mejor estructura y disciplina del proceso de desarrollo. Una buena posibilidad de reducir el trabajo a realizar es la reutilización de modelos, procesos, etc. ya definidos en utilizaciones previas de RUP en distintos ámbitos.

Resumen de puntos clave

RUP

• Pesado
• Dividido en cuatro fases
• La fase se dividen en iteraciones
• El discurrir del proyecto se define en Workflows
• Los artefactos son el objetivo de cada actividad
• Se basa en roles
• UML
• Muy organizativo
• Mucha documentación

Lista 5: Claves de RUP

XP

• Ligero
• Cercano al desarrollo
• Se basa en UserStories
• Fuerte comunicación con el cliente
• El codigo fuente pertenece a todos
• Programación por parejas
• Tests como base de la funcionalidad
• Solo el mínimo de organización
• Pobre en cuanto a documentación

Lista 6: Claves de XP

FDD

• Ligero
• A medio camino entre el desarrollo y la organización
• Existe un jerarquia dentro del equipo
• El codigo fuente tiene propietario
• Los equipos varían en función de la funcionalidad a implementar
• El conocimiento de la aplicación se reparte a través de trabajo en equipo y revisiones
• Documentación aceptable

Lista 7: Claves de FDD

Conclusión

¿Qué debemos esperar entonces de un proceso de desarrollo?. ¿Qué criterios debe cumplir para que aporte algo a la empresa?. Básicamente el proceso de desarrollo tiene que ayudarnos a escribir software, tiene que poner las reglas necesarias para alcanzar el éxito en nuestro proyecto pero dejando la libertad suficiente para no sentirnos agobiados.

Esto no nos lo va a ofrecer ningún proceso estándar, y como dice el refrán (aunque no se cumple exactamente en el mundo de la informática) todos los caminos conducen a Roma, de forma que es tarea de cada empresa, casi para cada proyecto, decidir cual es el mejor modo de llegar a nuestra meta. Desde este artículo solo hemos intentado mostrar algunos de los caminos más frecuentados, más bien tomados como origen, para que vosotros decidais, y lo adapteis.

Recursos

[1]
Web oficial de RUP
,
http://www.rational.com/products/rup/

[2]
Web oficial de UML
,
http://www.omg.org/uml/

[3]
The Rational Unified Proccess: An introduction,
Philippe Kruchten
,
Addison Wesley, 2000

[4]
Extreme Programming,
Kent Beck
,
Addison Wesley, 2000

[5]
ExtremeProgramming.org
,
http://www.extremeprogramming.org

[6]
www.xprogramming.com
,
http://www.xprogramming.com

[7]
XP Roadmap
,
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

[8]
Descarga del PDF descriptivo
,
http://thecoadletter.com/download/#fddguide

[9]
Últimos avances de FDD
,
http://www.nebulon.com/articles/fdd/latestfdd.html

[10]
FeatureDrivenDevelopment.com
,
http://www.featuredrivendevelopment.com/

[11]
A Practical Guide to Feature-Driven Development,
Steve Palmer, Mac Felsing
,
Prentice Hall 2002

[12]
Angewandte Prozessmodelle,
Andreas Lux

[13]
Enlaces sobre metodologías ágiles
,
http://www.agileprogramming.com

[14]
Grupo de trabajo sobre metodologías ágiles en España,
http://www.agile-spain.com

Acerca del autor

Alberto Molpeceres
Alberto es ahora mismo desarrollador de aplicaciones en ámbito cliente/servidor para la empresa T-Systems ITS GmbH en Dresden (Alemania). Cuando no está trabajando o "metiendo caña" al resto de los integrantes de javaHispano intenta pasear con su novia, buscar la desaparecida lógica del idioma alemán o intenta disfrutar del buen ambiente de la Neustadt.

BEA Weblogic 8.1 ya disponible

BEA esta celebrando estos días su BEA eWorld 2003 en Orlando (USA), y ha sido el marco escogido para presentar la versión 8.1 de su servidor de aplicaciones J2EE, uno de los más importantes del mercado.
Esta nueva versión incluye bastantes novedades, entre las que estan las mejoras en la adminsitración, mejoras de los workshops disponibles, herramientas gráficas para determinar el workflow de las apliaciones web (basado en Struts), servicios web y el empleo de la última versión de su máquina virtual de alto rendimiento jRockit
Aquí el anuncio oficial. Y más detalles de gente viviendo la eWorld en directo los podeis encontrar en The Server Side
Al hilo de esto, BEA también ha anunciado la disponibilidad de nuevas subscripciones a su programa para desarrolladores, dev2dev, que entre otras cosas permite tener acceso a licencias de sus productos por un año para desarrollo.

Munki, un lenguaje de scripts hispano

De mano de uno de nuestros usuarios he llegado a la web de Munki, un lenguaje de scripts escrito en Java desarrollado por Raúl García. Munki es un lenguaje orientado a objetos, con soporte para concurrencia, excepciones, y... patrones de diseño (?).
En la web del lenguaje no viene mucha información sobre licencia y el lenguaje en si mismo, pero al descargarlo aparece una guía de programador bastante aceptable.
Espero que el autor se apse por aquí y nos comente un poco más. Quizás este buscando colboración, y quizás esta sea una buena forma de aprender cosas nuevas.

El archipielago Eclipse

EL ARCHIPIÉLAGO ECLIPSE (PARTE 1 DE 4)

Fecha de creación: 24.02.2003

Miguel Ángel Abián
mabian AT aidima DOT es

Copyright (c) 2003, Miguel Ángel Abián. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).

ECLIPSE. (Del lat. eclipsis, y éste del gr. ékleipsis, de ekleípein, abandonar.). m. Astron.
Oscurecimiento del sol o de un cuerpo celeste por interposición de otro astro que le oculta
directamente o que infiere la luz que le ilumina. [Diccionario Enciclopédico SALVAT
Universal]

1. Introducción

El artículo El
archipiélago Eclipse pretende exponer qué es Eclipse, cuál es su
estructura, en qué se diferencia o se asemeja a otros productos ya existentes,
cuáles son sus ventajas e inconvenientes, cuál podría ser su utilidad para los
desarrolladores (centrándose en la comunidad Java), qué estrategias
empresariales subyacen bajo el proyecto Eclipse y cuál podría ser su futuro. Debido a su
extensión, unas diecisiete mil palabras, se publicará dividido en cuatro
partes.

En este
artículo no se explica cómo utilizar Eclipse o cómo desarrollar aplicaciones
Java con él, pues existe una amplia documentación acerca de estos temas en la
ayuda del producto y en http://www.eclipse.org. Sin embargo, existe poca
información -y toda en inglés- acerca de algunos de los puntos señalados
arriba; además, mucha de esta escasa información está claramente sesgada, por
motivos de estrategia comercial y empresarial, a favor o en contra del
producto. Para obtener una valoración imparcial de Eclipse es obligatorio leer
a menudo entre líneas, comprobar y contrastar cada afirmación, prestar atención
a lo sobreentendido -que suele ser lo importante- y probar muchos productos.

El
archipiélago Eclipse trata de cubrir este hueco informativo, de
una manera independiente e imparcial. Hueco absoluto, por lo que sé, en nuestro
idioma. Quizá no lo consiga, pero al menos mostrará la punta del iceberg, y
espero sinceramente que anime a algunos desarrolladores a contarnos sus
experiencias con Eclipse y sus opiniones.

Aclarado el
objetivo del artículo, es el momento de comenzar el recorrido por los islotes
que pueblan el archipiélago Eclipse.

height=454 src="/articulos/eclipse/EclipseParte1/Fig1.png" width=602>

Fig. 1. Eclipse como pentagrama. La figura muestra distintas facetas de Eclipse, que se abordarán a lo largo del artículo.

2. Los
entornos de desarrollo integrado (IDEs)

Los
desarrolladores de software se dividen en dos tipos: los que usan entornos de
desarrollo integrado o IDEs (Integrated Development Environments) y los
que no. Estos últimos prefieren un editor de texto (como Emacs o el Bloc de
notas), un compilador y un depurador. Los pertenecientes al primer tipo, sin
embargo, prefieren usar IDEs para ayudarles a la generación del código y a la
construcción de proyectos. Tarde o temprano, independientemente del grupo al
cual pertenezcan, todos se enfrentan a sus propios problemas.

No hace mucho
(cronológicamente hablando, que no tecnológicamente), la única manera de
desarrollar aplicaciones en C, COBOL o Fortran era recurrir a un editor de
texto, un compilador y un depurador. Con la llegada de los lenguajes de cuarta
generación, comenzaron a aparecer las primeras herramientas de desarrollo
integrado, muy primitivas comparadas con las que podemos encontrar ahora (ya
sea gratuita o comercialmente).

Cualquier
entorno actual de desarrollo integrado ofrece, al menos, el control del
editor de código, del compilador y del depurador desde una única interfaz de
usuario. Su misión consiste en evitar tareas repetitivas, facilitar la escritura
de código correcto, disminuir el tiempo de depuración e incrementar la
productividad del desarrollador. Estas tareas pueden realizarse de muchas
maneras distintas: mediante la inclusión de asistentes para las tareas más
habituales y mecánicas, de editores que completen automáticamente el código y
señalen los errores sintácticos, de gestores de archivos fuente, etc.

En teoría, un
entorno de desarrollo integrado o IDE debería aportar funcionalidades al
desarrollador durante todas las etapas del ciclo de vida del desarrollo de
software (desde el análisis y diseño a la distribución del producto y su
mantenimiento), de ahí la palabra "integrado". En la práctica,
solamente los IDEs más modernos cumplen esta condición y, a menudo, de forma
incompleta.

Después del
impresionante éxito de Visual Basic, ha sido frecuente asumir que los IDEs
necesitan incluir herramientas visuales de generación de
interfaces de usuario (GUI builders),
pero esta premisa resulta inexacta. Algunos IDEs carecen de diseñadores
gráficos visuales y no por ello dejan de ser excelentes.
En el caso específico de Java, la mayor parte de las aplicaciones actuales se
ejecutan en el lado del servidor y no precisan interfaz gráfico. Muchas veces
resulta más conveniente disponer de un buen editor JSP/HTML que de un vistoso
diseñador gráfico.

Los IDEs, por
supuesto, también tienen sus desventajas: en comparación con el clásico
triunvirato editor de texto-compilador-depurador consumen muchísimos más
recursos, tienden a ser lentos (particularmente los escritos en Java) y su
manejo requiere un cierto aprendizaje que se tira a la papelera cuando se pasa
a otro IDE, debido a la heterogeneidad de los IDEs que proliferan en el
mercado. Algunos IDEs son sumamente complejos de manejar, incluso para llevar a
cabo las tareas aparentemente más sencillas; en otros los manuales demuestran
al indefenso lector el odio, desinterés y ausencia de motivación pedagógica que
deben de sentir aquellos que los escriben. En ocasiones, cuando generan código,
es mejor mirar hacia otra parte o empezar de cero.

Todavía no
existe un IDE universal o perfecto, capaz de reunir todas las características
que un desarrollador puede necesitar. Por lo general, los puntos débiles de un
IDE coinciden con los puntos fuertes de otro. Un buen ejemplo lo proporciona la
comparación entre WebSphere Studio Application Developer (de IBM) y JBuilder
(de Borland). JBuilder posee un excelente diseñador de interfaces gráficas para
el usuario y proporciona una vista de la estructura jerárquica de los formularios
que muestra todos los componentes visuales (botones, cuadros de texto,...)
organizados por contenedores. WebSphere Studio Application Developer
proporciona, en comparación, un diseñador gráfico mucho más simple, pero ofrece
un editor JSP/HTML magnífico (uno de los mejores, si no el mejor, del mercado),
que permite insertar componentes visuales, componentes ActiveX o imágenes, y
ver la vista previa de las páginas web, entre otras muchas características. El
editor HTML de JBuilder se limita, en cambio, a poco más que colorear las
palabras reservadas.

Como puede
extrapolarse a partir del ejemplo anterior, el desarrollador que trabaje en
varios campos simultáneamente (desarrollo de servicios Web, creación de
Enterprise JavaBeans, diseño de páginas web, edición de XML) necesitará usar
varios IDEs o herramientas para trabajar de forma óptima.

En algunas
ocasiones, la elección del IDE por parte de los desarrolladores no es libre,
sino que está condicionada por decisiones previas (sistemas de gestión de bases
de datos, servidores de aplicaciones). Por ejemplo, resulta muy fácil y cómodo
construir aplicaciones Java capaces de trabajar con Oracle usando el JDeveloper
de Oracle, por supuesto. Existen empresas que suministran componentes o módulos,
añadidos ya a sus herramientas o por separado, con el fin de proporcionar soporte
para las plataformas J2EE más populares pero, qué casualidad, son las que no
comercializan sus propios servidores de aplicaciones o apenas obtienen ingresos
de ello. Borland proporciona, por ejemplo, módulos en su JBuilder para WebLogic,
Tomcat, iPlanet (Sun ONE) y Websphere (la cuota de Borland en el mercado de
servidores de aplicaciones no llega al 1%), pero Websphere y WebLogic (de IBM y
BEA, respectivamente) no suministran directamente módulos para JBuilder,
continuando con el ejemplo, porque son los líderes en servidores de
aplicaciones y prefieren dirigir a los desarrolladores hacia sus propios
productos.

Una regla a
menudo cierta para los IDEs comerciales es la del "80-20%": El
ochenta por ciento de las características incorporadas sólo son útiles para el
20 por ciento de los usuarios. ¿Cuántas veces nos hemos encontrado con IDEs
poco considerados que exprimen nuestras máquinas como si fueran limones, hasta
la última gota? Muchas veces el abuso de los recursos del sistema se origina
por la instalación con el IDE de muchas características poco o nada utilizadas.
Esta inclusión de utilidades no solicitadas ni necesitadas también redunda en
el precio del producto. Algunas compañías aprovechan la adición de unas pocas
características nuevas, no siempre útiles, para lanzar nuevas versiones de sus
IDEs.

Pese a todos
estos inconvenientes, los IDEs suelen proporcionar una importante ayuda a la
hora de conservar un registro de las versiones, generar y mantener la
documentación de cada etapa del proyecto, y evitar tareas monótonas y
repetitivas, dada la magnitud y complejidad de los proyectos empresariales que
se afrontan actualmente, inabordables en solitario. El lector interesado en
adquirir una panorámica rápida de las
herramientas e IDEs open source o free software para Java puede consultar el
excelente artículo Arquitectura empresarial y open source, J2EE de
Martín Pérez y Alberto Molpeceres, publicado en javaHispano y llamado
a convertirse en un clásico.

La irrupción
de Eclipse, un nuevo jugador en el mercado de IDEs para Java apadrinado
por IBM y respaldado por un poderoso consorcio de empresas, supone un firme
intento de homogeneizar el mercado de IDEs (no sólo de Java) y de establecer un
estándar para las herramientas de desarrollo de software. Eclipse no es un IDE
más a añadir a la lista: el objetivo de IBM es crear una plataforma de
desarrollo modular que cualquier herramienta de desarrollo pueda usar con
cualquier lenguaje de programación. Eclipse anhela ser, no estar.

3. Terminología oficial de Eclipse.

Según la
documentación oficial de Eclipse (http://www.eclipse.org), Eclipse es un
proyecto de desarrollo de software de código fuente abierto (open source)
cuyo objetivo es la construcción de herramientas integradas para el desarrollo
de aplicaciones. La palabra "Eclipse" se utiliza en dicha
documentación para referirse al proyecto en conjunto de creación
de herramientas integradas para desarrollar aplicaciones. Este proyecto global
se compone de tres subproyectos (véase http://www.eclipse/projects):

• 
  

  Proyecto Eclipse

  
  
• 
  

  Proyecto Herramientas de Eclipse

  
  
• 
  

  Proyecto Tecnología Eclipse

  
  

El proyecto
Eclipse es el subproyecto de Eclipse dedicado a proporcionar una plataforma
base común para el desarrollo de herramientas integradas. Este proyecto, a su
vez, se subdivide en otros tres, dedicados al desarrollo y mejora de la
plataforma Eclipse (núcleo básico o kernel de Eclipse), del JDT (Java
Development Tools) y del PDE (Plug-in Development Kit). El término
"Eclipse SDK (Standard Development Kit)" alude al conjunto de
la plataforma Eclipse, el JDT y el PDE; por tanto, puede afirmarse que el
proyecto Eclipse se dedica, en conjunto, al desarrollo y mejora del SDK de
Eclipse. Todos estos acrónimos se irán explicando a lo largo del artículo.

height=430 src="/articulos/eclipse/EclipseParte1/Fig2.png" width=572>

Fig. 2. Jerarquía de proyectos en Eclipse.

Aunque
entiendo la preocupación de Eclipse (como proyecto global) por definir
correctamente los términos desde un principio para conseguir una documentación
precisa y sin ambigüedades, como este artículo pretende ser informativo, de propósito
general y no acabar sumergido en un enredo de siglas, usaré "Eclipse"
para designar tanto al kit SDK de Eclipse (el producto o herramienta) como al
proyecto global. Dependiendo del contexto podrá deducirse el significado. Por
ejemplo, en este artículo, términos como "la programación de Eclipse"
o "la licencia de Eclipse" hacen referencia al SDK de Eclipse,
mientras que "las metas de Eclipse" se refiere al proyecto global. No
usaré el término "proyecto Eclipse" (aunque sería lo lógico) para
referirme al proyecto global, pues estrictamente hablando constituye un
subproyecto de Eclipse, de acuerdo con la terminología oficial.

En resumen, en
lo que sigue:

• 
  

  Se usa "Eclipse" para designar tanto al SDK de Eclipse como al proyecto
  global.

  
  
• 
  

  Se utiliza "proyecto Eclipse", por coherencia con la terminología oficial, para
  designar a un subproyecto del proyecto global, encargado del desarrollo y
  mejora del SDK.

  
  
• 
  

  Se utiliza
  "plataforma Eclipse" o "plataforma" sólo para designar el
  núcleo o kernel del SDK de Eclipse (o, equivalentemente, del proyecto Eclipse).
  Como la palabra "plataforma" se utiliza también para designar una
  combinación de hardware, sistema operativo y entorno gráfico, en caso de
  ambigüedad se usará "plataforma Eclipse".

  
  

4. ¿Qué es
la plataforma Eclipse?

En la antigua
Grecia, al pie del monte Parnaso, existió un oráculo muy famoso: el oráculo de
Delfos. Éste se expresaba en distintas lenguas y sus respuestas solían ser muy
crípticas y ambiguas. Una vez pronosticó: "Si el rey Creso cruza el río Halys
con su ejército, destruirá un poderoso imperio". Y así ocurrió, pero
resultó ser el suyo. Cuando se lee en la documentación de IBM que "Eclipse
es un IDE abierto y extensible para todo y, sin embargo, para nada en
particular", puede surgir esta razonable pregunta: ¿Habrá aprendido inglés
el oráculo de Delfos y se dedica a redactar la documentación de Eclipse para
IBM? Si no ha sido así, la definición no desentonaría, por su ambigüedad y
laconismo, con las respuestas habituales del oráculo. Además, tal y como se irá
mostrando, resulta tan cierta como muchas de las enigmáticas respuestas que
daba el oráculo.

Una definición
un poco más concreta se puede resumir así: "[es] una plataforma universal
para integrar herramientas de desarrollo" con una "arquitectura
abierta, basada en plug-ins". Plataforma universal, pues emplea una
estructura abierta de plug-ins (extensiones; to plug in significa
conectar y plug, enchufe o conector) que permite expandir las
capacidades de la plataforma base hasta el infinito. Arquitectura abierta, en
definitiva, porque es un producto de código fuente abierto u open source.

Desde el punto
de vista del usuario que le eche un vistazo por vez primera, la plataforma
Eclipse resulta ser un IDE (entorno de desarrollo integrado) de código fuente
abierto, la mayor parte del cual ha sido escrito en Java. En cuanto al
nombre, no puedo evitar pensar que es una referencia poco amistosa a Sun
Microsystems. Una interpretación quizá maliciosa, pero cuando a uno le dan un
cuchillo es inevitable no acabar cortando algo: ¿Cuántos críticos literarios
resistieron la tentación de asociar a Sauron el Señor Oscuro de El señor de
los Anillos con Hitler?, ¿Cuántos lectores no identificaron al cerdo
Napoleón de Rebelión en la granja con Stalin cuando se publicó el libro?

5. Historia de Eclipse

Gran parte de
la programación de Eclipse fue realizada por IBM antes de que se creara el
proyecto Eclipse como tal. Las distintas versiones de VisualAge se construyeron
usando Smalltalk (un lenguaje OO no excesivamente amigable) en un entorno de
desarrollo llamado Envy. Con la aparición de Java en la década de los 90, IBM desarrolló una
maquina virtual válida tanto para Smalltalk y Java. La rápida expansión de Java
y sus ventajas con miras a una Internet en plena expansión obligaron a IBM a
plantearse el abandono de esta maquina virtual dual y la construcción de una
nueva plataforma basada en Java desde el principio. El producto final
resultante es Eclipse, que ya había costado unos 40 millones de dólares a IBM
en el año 2001.

A finales de
2001 IBM puso el proyecto Eclipse en manos de un consorcio (Eclipse.org) de
empresas fabricantes de herramientas de software. Originalmente la junta
directiva del consorcio incluía a Borland, MERANT, IBM, QNX Software Systems,
Rational Software, Red Hat, SuSE, TogetherSoft y Webgain; en junio de 2002 se
agregaron Hitachi, Instantiations, MontaVista, Scapa Technologies,
Telelogic,Trans-Enterprise Integration y Serena; en septiembre de 2002 se
sumaron ETRI, HP, MKS, SlickEdit y se aprobó la entrada de Oracle; en diciembre
de 2002 entraron como miembros AltoWeb, Catalyst Systems, Flashline, Parasoft,
SAP, teamstudio y TimeSys. El grupo OMG (Object Management Group)
también forma parte de la junta directiva.

La última
versión estable de Eclipse (Eclipse 2.0.2, lanzada en noviembre de 2002) se
encuentra disponible para los sistemas operativos Solaris 8, HP-UX, AIX,
Windows 98/ME/2000/XP, Linux SuSE 7.1, Linux Red Hat 7.1 y QNX. Todas las
versiones de Eclipse necesitan tener instalado en el sistema el JRE o JDK
versión 1.3 o superior.

Existe ya una
versión 2.1 de Eclipse, pero no está tan probada, por ahora, como la versión
2.0.2 y todavía no ha sido marcada por Eclipse.org con la "R" de Released
(lanzada). Esta última versión se encuentra disponible para los sistemas
operativos anteriores y para Mac OS X. Las nuevas características que ofrece
con respecto a la versión oficial 2.0.2 aún necesitan pulirse y
depurarse, pero probablemente se lanzará como la última versión estable de
Eclipse antes de junio de 2003.

6. Eclipse y el software open
source. Un matrimonio de conveniencia bien avenido.

Eclipse se distribuye
actualmente bajo la licencia CPL (Common Public License o Licencia) versión 1.0 de
IBM, aprobada por la organización Open Source Initiative (OSI). A diferencia de
otros proyectos open source (o, más exactamente, free software) que no
permiten que se deriven de ellos trabajos propietarios o cerrados, Eclipse
puede extenderse -al estar bajo esta licencia CPL- mediante la inclusión de
plug-ins propietarios o ser usado como base para la creación de nuevas
herramientas y, tras reempaquetarse y compilarse el código resultante, el
producto final puede venderse de forma comercial, manteniéndose público el
código de Eclipse utilizado o modificado, pero sin la obligación de poner a
disposición del público el nuevo código añadido (éste último puede ir bajo la
licencia que se desee).
Como es bien sabido, el software propietario o cerrado se
caracteriza porque su redistribución y modificación está prohibida o requiere
autorización previa; la mayor parte del software comercial es propietario, pero no cabe
identificar ambos tipos de software: se pueden obtener beneficios económicos de
Eclipse (al igual que de cualquier otro proyecto de código fuente abierto o de software libre).

Al igual que cualquier licencia autorizada o
admitida por la OSI, la licencia CPL exige el cumplimiento de una serie de
requisitos, algunos de los cuales figuran a continuación (el resto pueden
consultarse en http://www.opensource.org):

• 
  

  Distribución gratuita: Cualquier software bajo
  licencia CPL puede distribuirse libremente, permitiéndose la venta sin que se
  requiera el pago de royalties o compensaciones de cualquier tipo.

  
  
• 
  

  Cualquier programa bajo licencia CPL debe permitir
  la distribución en forma de código fuente y en forma compilada. Si el producto
  no incluye el código fuente, deberá incluirse en él la manera de conseguirlo.

  
  
• 
  

  Cualquier programa bajo licencia CPL debe permitir
  la producción de trabajos derivados a partir de él y la introducción de
  modificaciones en el programa original.

  
  

Un programa difundido bajo licencia CPL puede ser
distribuido por cualquiera en forma compilada o de código fuente. En el primer
caso, el programa puede ser distribuido bajo la licencia que determine el
distribuidor, siempre que se cumplan los puntos expuestos en el apartado 3 de
la CPL v 1.0 (Requisitos); entre otras condiciones, deberá establecerse que el
código fuente está disponible por parte de las personas o empresas que hayan
contribuido. En el segundo caso, cuando un programa bajo licencia CPL se distribuya en forma de código fuente,
quedará automáticamente bajo la "sombrilla" de la licencia CPL y no
podrá utilizarse ninguna otra licencia. IBM distribuye una versión comercial de
Eclipse, en forma compilada, llamada WebSphere Studio Workbench.

En consecuencia, cualquier programa bajo licencia
CPL puede compilarse (aunque no se haya efectuado ninguna modificación sobre el
código original) y venderse el resultado de modo comercial sin requerir el pago
de royalties u otras formas de compensación, de acuerdo con los términos de
CPL; lo cual implica, aparte de otras obligaciones, poner a disposición del
público el código fuente. Si una aplicación tiene una parte licenciada bajo CPL
y el resto no (propietaria), la parte bajo CPL debe cumplir con esta licencia
y, en consecuencia, el código de esa parte debe estar a disposición del
público. El código fuente de la parte propietaria no tiene por qué licenciarse
bajo CPL ni estar disponible al público. En contraposición, licencias como la
GNU GPL (GNU General Public License, bajo la cual se distribuye Linux)
exigen que, si se incorpora código bajo GPL a un programa, aunque éste sea
propietario, el programa completo se licencie bajo GPL (poniéndose, por
tanto, a disposición del público todo el código fuente, tanto GPL como no GPL).
Desde el punto de vista de una empresa interesada en mantener la propiedad de
su software, el código propietario que se incorporara a un programa bajo
licencia GPL o similar sería infectado o contaminado por el
código GPL y perdería su carácter propietario.

Con la
licencia CPL, el concepto de copyright sigue vigente: el copyright de los
programas, el código, etc. pertenece a sus legítimos autores (u a otras
personas o entidades a las que hayan cedido su copyright). Cuando un programa
se distribuye bajo la licencia CPL, el creador del programa y poseedor de su
copyright o de sus derechos de autor concede a cualquiera una licencia de
copyright que proporciona derechos de autor para usar, modificar, redistribuir,
comercializar el programa y/o las modificaciones efectuadas sobre éste (sujeta
a ciertos términos y restricciones; véase la licencia completa en http://www-124.ibm.com/developerworks/oss/CPLv1.0.htm).
El autor transfiere estos derechos de propiedad intelectual, pero no renuncia a
su titularidad.

Por este
motivo, no es extraño ver el copyright de IBM en la documentación de Eclipse y
en el propio producto, pues desarrolló inicialmente la mayor parte de éste.
Cualquier desarrollador puede modificar el código open source de
Eclipse, redistribuirlo, comercializarlo crear trabajos derivados, etcétera sin
pagar royalties a IBM, pero no puede eliminar o modificar el copyright de IBM.
En el supuesto de que modificara el código o añadiera nuevos módulos y
redistribuyera comercialmente el resultado (ya fuera bajo licencia CPL o no),
el desarrollador poseería el copyright de su trabajo, pero IBM seguiría siendo
el titular del copyright de las partes que creó, aunque no podría exigir
royalties o compensaciones por el uso comercial o lucrativo de su código
original.

Cualquiera puede distribuir de forma comercial, con la licencia que estime oportuna,
plug-ins para Eclipse no derivados de él, aunque hayan sido desarrollados para la plataforma
Eclipse y se haya consultado el código fuente de ésta para crearlos. En este caso no se necesita
poner a disposición de otros el código fuente, pues estos plug-ins quedan fuera del
alcance de la licencia CPL.

height=459 src="/articulos/eclipse/EclipseParte1/Fig3.png" width=603>

Fig. 3. Voces desde el software libre y el software open source.

Algunas
personas aplauden el mecenazgo de IBM sobre proyectos open source, que comenzó
con su apoyo incondicional a Linux en 1997 y continúa hasta hoy. IBM ha
invertido unos mil millones de dólares en Linux y productos relacionados, y se
calcula que cuenta con unas cinco mil personas (entre empleados y
colaboradores) dedicadas a temas relacionados con este sistema operativo. En
una conversación, hace ya varios años, una responsable de marketing de IBM me
dijo: "Linux es más que alguien de la familia". Frase un tanto
intrigante por su ambigüedad: ¿Quería mucho a Linux o poco a su familia? Esta
opinión, como supe poco después, no era el fruto de una concienzuda reflexión
sobre el tema ni una muestra de cariño desmedido y un tanto fetichista por un
sistema operativo (en realidad, ella nunca había llegado a usar Linux:
trabajaba con Windows 95), sino una cuestión de estrategia comercial y de
marketing.

Al leer las
declaraciones de algunos responsables de IBM, uno se da cuenta de que la frase
"obsesión por el software open source" refleja a la perfección el
sentir de la empresa. Pero casi se debe mirar hacia otro lado para no
justificar lúcidamente esta obsesión tan racional; qué mejor estrategia para
IBM que apoyar un producto gratuito, serio competidor de Windows NT, Windows
2000 Server y Windows .Net Server, y recomendar desinteresadamente a los
clientes del sistema operativo Solaris de Sun la migración a un entorno Linux
sobre plataformas eServer de IBM, argumentando reducciones sustanciales en el coste
total de la propiedad y mejoras considerables del rendimiento de los sistemas.
¿Obsesión por el software open source? Más bien obsesión por matar dos pájaros
de un tiro. ¿Casualidad?... Sí, claro; por eso los directivos de IBM cobran sus
abultados sueldos, por casualidad... En el fondo, todos conocemos el nombre del
juego.

Linux y
Eclipse, pese a su carácter open source y su calidad indudable, son
herramientas utilizadas por IBM (como podría ser cualquier otra empresa; ¿por
qué engañarse?, las empresas son depredadores en el amplio ecosistema del libre
mercado) para obtener ventajas competitivas frente a sus competidores (Sun,
Microsoft, HP, BEA, etc.), ventajas que favorecerán -directa o indirectamente-
el retorno a sus arcas de las inversiones efectuadas. Ahora bien, el carácter
open source de Eclipse también repite un mensaje constante a lo largo de la red de redes:
Aquí no hay privilegios exclusivos. Cualquiera puede colaborar y
ganar algo con ello. Los desarrolladores open source puede ganar prestigio
y ostentar su copyright; las empresas pueden sacar rentabilidad a sus
inversiones en Eclipse y conseguir productos que ellas solas jamás hubieran
podido crear.

Un elevado porcentaje del éxito de Eclipse y de las
mejoras continuas que experimenta se debe a la naturaleza de su licencia: la
licencia CPL de IBM supone ventajas comerciales frente a licencias como la GNU
GPL, las cuales impiden que se deriven o incorporen trabajos propietarios -como
es bien sabido, los objetivos de las empresas con ánimo de lucro, aunque a
algunas les cause sarpullidos reconocerlo públicamente, se fundamentan en dos
reglas: 1) Gane dinero y mantenga su propiedad; 2) Nunca olvide la primera
regla (eso sí, cada una las implementa como puede)-. Muchas empresas (grandes,
PYMEs) pueden desarrollar plug-ins propietarios o sus propias herramientas
derivadas de Eclipse y obtener beneficios de su trabajo sin ver mermadas sus
ganancias por el pago de royalties, y los desarrolladores pueden planear con
rapidez sus propias extensiones, modificaciones o mejoras, a la vista del
código fuente de Eclipse y de los productos derivados bajo licencia CPL.
Individuos y empresas pueden trabajar en simbiosis, lograr sus objetivos,
contribuir a la mejora continua de Eclipse y ofrecer mejores productos (más competitivos
en prestaciones y precio) a los consumidores finales. Al usuario final poco le
importa que el gato sea blanco, negro, pardo o el pedigrí de sus progenitores:
lo importante es que cace ratones. Y que los cace bien.

Aparte de las
distintas licencias de Linux y Eclipse, hay también otro rasgo diferenciador
entre ambos proyectos que contribuye a la vertiginosa expansión de Eclipse:
poca gente (comparativamente hablando) tiene conocimientos de programación de
sistemas operativos; sin embargo, cualquier desarrollador usuario de Eclipse -y
hay muchos más desarrolladores que expertos en sistemas operativos- es un
potencial colaborador del proyecto Eclipse.

7. Pero
¿era necesario añadir un IDE más a la larga lista de los ya existentes?

El lector
escéptico podría pensar que Eclipse no deja de ser otra herramienta de
desarrollo para Java, similar a herramientas como JBuilder (Borland),
JDeveloper (Oracle) ó NetBeans (Sun), y que el uso de la palabra
"plataforma" forma parte de una estrategia comercial de IBM, no muy
innovadora. Sin embargo, no es así: Eclipse presenta cuatro características
conjuntas muy importantes, ya esbozadas en apartados anteriores, que
justifican el uso de "plataforma":

• 
  

  Eclipse se
  beneficia de la capacidad de aceptar plug-ins open source o propietarios,
  escritos por los propios desarrolladores Java, que pueden extender la
  plataforma y, a su vez, otros plug-ins. Esta arquitectura abierta puede
  concebirse figuradamente como una península (la plataforma Eclipse) rodeada de
  un archipiélago de plug-ins que expanden sus capacidades hasta donde llegue la
  imaginación y la destreza de los desarrolladores.

  
  
• 
  

  Eclipse
  cuenta con el respaldo de un consorcio de empresas muy importantes, ya
  detalladas.

  
  
• 
  

  Eclipse es
  neutral con respecto a la plataforma y el lenguaje (aunque en su mayor parte esté
  escrito en Java).

  
  
  
• 
  

  Eclipse
  permite realizar íntegramente el proceso de desarrollo de software tal y como
  se entiende en la actualidad, desde el análisis inicial de requerimientos hasta
  la distribución final y el mantenimiento. Casi con toda seguridad, Rational
  Software, con su metodología RUP (Rational Unified Process), y
  TogetherSoft (adquirida por Borland hace unos meses) han influido mucho en esta
  característica.

  
  
  

La primera
característica no es del todo nueva, pues la plataforma NetBeans de Java
(también una iniciativa open source) sigue una estrategia similar, pero no
cuenta con el respaldo de empresas tan importantes como las citadas. En
relación con la última característica, casi todas las herramientas de
desarrollo en Java proporcionan algún tipo de asistencia para el modelado y el
diseño, pero no de forma tan detallada y continua, de principio a fin, como
el que puede proporcionar Eclipse mediante plug-ins.

Eclipse puede
considerarse, en justicia, como un IDE para Java, una plataforma de integración
de herramientas de desarrollo y un framework de aplicaciones.

8. La
arquitectura del SDK de Eclipse: una vista aérea.

El Standard
Development Kit (Kit de desarrollo estándar) de Eclipse se compone de tres
elementos:

• 
  

  La
  Plataforma Eclipse (cuya arquitectura interna se describirá más adelante)

  
  
• 
  

  El JDT (Java
  Development Tooling, las herramientas de desarrollo Java).

  
  
• 
  

  El PDE (Plug-in
  Development Environment, el entorno de desarrollo de plug-ins).

  
  
  

Tal y como ya
se explicó, su desarrollo y mejora está en manos del proyecto Eclipse
(subproyecto de Eclipse).

height=395 src="/articulos/eclipse/EclipseParte1/Fig4.png" width=588>

Fig. 4. Estructura general de Eclipse. Extraído de la documentación oficial de Eclipse.

En esencia, la
plataforma Eclipse es una plataforma para el desarrollo general de
herramientas (recordemos: "un IDE para cualquier cosa y para nada en
particular"). Por sí sola, la plataforma resulta de escasa utilidad para
el usuario último pues se halla capacitada para trabajar con cualquier tipo de
fichero (no necesariamente con ficheros asociados a lenguajes de programación,
sino también con ficheros generados por aplicaciones como Word, ficheros de
vídeo, de gráficos, etcétera), pero carece del conocimiento específico
de cómo tratarlos. Es decir, Eclipse puede mostrar un fichero C, por ejemplo,
pero desconoce la gramática y sintaxis de C (palabras reservadas, bloques,
etc.). La palabra main no significa más que la palabra vino para
la plataforma aislada, pues no proporciona facilidades específicas para la
depuración, edición, etc. La utilidad real de la plataforma por sí sola para el
programador de C -o de cualquier otro lenguaje, incluido Java- no es mayor que
la de un editor de texto plano (aunque con un extraordinario entorno gráfico
alrededor).

Para el desarrollador de plug-ins y de IDEs, sin embargo, la situación adquiere un aspecto
muy distinto: la plataforma por sí sola le proporciona un conjunto de frameworks,
un conjunto de reglas de integración con la plataforma, una interfaz gráfica
francamente espléndida, soporte para el control de versiones, infraestructura
para la depuración independiente del lenguaje usado y el control de las bibliotecas
gráficas, entre otras muchas
características. Los desarrolladores de plug-ins e IDEs pueden usar todas estas
funcionalidades ya incorporadas para desarrollar sus propias herramientas que expandan la
plataforma.

Cuando se usa
la plataforma Eclipse con plug-ins, empieza a vislumbrarse la potencia que
ofrece a los usuarios no desarrolladores de plug-ins o IDEs. Los plug-ins explican
a la plataforma cómo se deben tratar y gestionar los distintos tipos de
archivos, y aumentan la funcionalidad del sistema resultante (o, dicho de
otro modo, extienden o amplían la plataforma).

Para añadir
nuevas capacidades o funcionalidades a la plataforma Eclipse se usan los puntos
de extensión. Los puntos de extensión son, según la documentación oficial
de Eclipse, "lugares bien definidos del sistema donde otras herramientas
(llamadas plug-ins) pueden añadir funcionalidad". De conformidad con la terminología orientada
a objetos, un punto de extensión no deja de ser una interfaz que deberá ser implementada
por cualquier desarrollador interesado en extender la plataforma. Conviene destacar un aspecto
importante: el mecanismo de los puntos de extensión define el único
modo de añadir nuevas funcionalidades a la plataforma.

Los plug-ins
no sólo extienden o amplían la plataforma base, también pueden extender, a su
vez, otros plug-ins que hayan definido sus propios puntos de extensión. Un
plug-in puede hacer públicos interfaces que otros plug-ins pueden implementar.
Las implementaciones de los interfaces (llamadas extensiones) mostrados
por los puntos de extensión se realizan típicamente en Java, aunque algunos
puntos de extensión pueden acomodar extensiones proporcionadas por ficheros
ejecutables nativos o componentes ActiveX; incluso pueden programarse en lenguajes de
script. El principal obstáculo con el cual se enfrentan las extensiones no
realizadas en Java es la falta de acceso a la funcionalidad completa de la
plataforma Eclipse. Por otro lado, los plug-ins sólo se cargan cuando son
necesarios; así se evita disminuir innecesariamente el rendimiento de Eclipse.
Tal y como se detalló en el Apdo. 2, esta propiedad traza una clara separación,
en cuanto a consumo de recursos, entre los IDEs comerciales y Eclipse. A
diferencia de estos, Eclipse solo carga en memoria los plug-ins cuando
los necesita.

Por ejemplo,
el JDT agrupa un conjunto de plug-ins que extienden la plataforma al proporcionar
características para la edición, compilación, depuración y ejecución de código
Java (explica a la plataforma cómo entender los ficheros Java, en
definitiva). El JDT viene incluido en el SDK de Eclipse, pero resulta factible
desarrollar otros plug-ins que permitan a la plataforma trabajar con otros
lenguajes. Se encuentran ya disponibles plug-ins del consorcio Eclipse.org que
proporcionan IDEs para C/C++ y COBOL.

height=419 src="/articulos/eclipse/EclipseParte1/Fig5.png" width=558>

Fig. 5. Arquitectura de los plug-ins de Eclipse. Traducido de la documentación oficial de Eclipse.

El Java
Development Tooling (JDT) es, tal y como ya se ha escrito arriba, un
conjunto de plug-ins que extienden la plataforma al proporcionar
características para la edición, compilación, depuración y ejecución de código
Java.

El Plug-in
Development Environment (PDE) proporciona herramientas y asistentes que
automatizan y facilitan considerablemente la creación, desarrollo, depuración y
distribución de plug-ins.

src="/articulos/eclipse/EclipseParte1/Fig6.jpg">

Fig. 6. Vista del PDE. Extraído de la documentación oficial de Eclipse.

La imagen
mental que me viene a la cabeza cuando pienso en la arquitectura de Eclipse,
que tal vez sea útil al lector, es la de una península (la plataforma) rodeada
de un archipiélago (los plug-ins), pudiendo cada islote del archipiélago tener su propio
archipiélago (plug-ins extendidos por otros plug-ins).
Si acercáramos una lupa a
Eclipse, nos daríamos cuenta de su geometría fragmentaria, discontinua e incompleta; conforme
fuéramos aproximando la lupa, podríamos observar cómo todos sus componentes, salvo uno, se
descomponen en plug-ins compuestos, a su vez, por otros plug-ins más simples, y así
sucesivamente. Veríamos, acercando mucho la lupa, los puntos de extensión de
los plug-ins, algunos ocupados (es decir, implementados), pero la mayoría no.
Los puntos de extensión libres estarían disponibles para futuras ampliaciones de
Eclipse, ampliables también. Esta geometría recursiva me recuerda, superficialmente, a
las figuras fractales de Mandelbrot.

src="/articulos/eclipse/EclipseParte1/Fig7.png" width=628 height=468>

Fig. 7. Eclipse como archipiélago

[Fin de la primera parte]

Acerca del autor

Miguel Ángel Abián
Miguel Ángel Abián nació en Soria (1972). Se licenció
en Ciencias Físicas en 1995 por la U. de Valencia y consiguió la suficiencia investigadora
en 1997 dentro del Dpto. Física Aplicada de la U.V. Además ha realizado diversos
cursos de Postgrado sobre bases de datos, lenguajes de programación Web, sistemas
Unix, UML y Java. Ha participado en diversos programas de investigación TIC relacionados
con el estudio de fibras ópticas y cristales fotónicos, y ha publicado diversos
artículos en el IEEE Transactions on Microwave Theory and Techniques relacionados
con el análisis de guías de onda inhomogeneas y guías de onda elípticas.

Laboralmente ha trabajado como gestor de carteras y asesor fiscal
para una agencia de bolsa y ahora trabaja en el Laboratorio del
Mueble Acabado de AIDIMA (Instituto Tecnológico del Mueble y Afines), ubicado en Paterna (Valencia), en
tareas de normalización y certificación. En dicho centro se están desarrollando proyectos europeos
de comercio electrónico B2B para la industria del mueble basados en Java y XML (más información en www.aidima.es).

Sus intereses actuales son: el diseño asistido por ordenador de guías
de ondas y cristales fotónicos, la evolución de la programación orientada
a objetos, Java, el surrealismo y París, siempre París.