3ª semana de desarrollo: comenzando a implementar

Otra vez estoy aquí escribiendo unas líneas, y lo primero que quería decir es que muchas gracias a todos, sois gente de p$%& madre :-). No me esperaba que entrara tanta gente y que me diérais tantos ánimos, gracias!!!! Todos me han hecho mucha ilu, pero sobre todo los de Ramón y Miguelillo, que están ambos en Inglaterra (uno en Londres y otro en Cranfield); muchas gracias gambiteros por sacar un ratillo y hacerme una visita :-)

Bueno, al turrón. Perdón por saltarme el post que había prometido los dos domingos pasados, pero he estado pringando al máximo para ir sacando esto adelante, y el comienzo se está haciendo un poco durillo. Voy a intentar comentar brevemente qué he estado haciendo estas dos semanas de atrás.

Metodología y planificación

La metodología de desarrollo que estoy siguiendo es RUP, que junto con UML constituyen la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Es un proceso iterativo, de tal forma que en cada iteración, y según el estado del proyecto, hay una serie de tareas que se deben de realizar como pueden ser definición de requisitos, realizar análisis y diseño... etc. Una de las ventajas que tiene RUP es que es adaptable a la realidad de cada proyecto, y como en este tengo tan poquito tiempo haré más hincapié en las fases de diseño y de implementación.

Dicho esto, he planteado que voy a realizar 5 iteraciones, y he marcado unos objetivos para cada una de ellas. Y sobre estas iteraciones y sus objetivo, he planteado una planificación de lo que debería ser mi trabajo en estos 6 meses de desarrollo. Está realizada con un programa que se llama Planner que bueno, no es perfecto pero es bastante usable.

Configuración del repositorio

Una de las razones por las que tenía muchas ganicas de que comenzara el CUSL (aparte de porque estoy motivado) era porque quería contar lo antes posible con un control de versiones para ir subiendo cosillas e ir organizándome mejor; llevo usando regularmente SVN desde hace un par de años, y estoy más que contento con él. El caso es que después de que me abrieran un proyecto en la forja de Molinux, ya pude comenzar a meter mano al repositorio, que es lo que quería.

Un proyecto software produce muchos artefactos o productos: documentación, especificación de requisitos, diagramas UML, código... etc., y la mayoría es posible que vayan evolucionando según vaya avanzando el proyecto. Es interesante entonces meterlos en el control de versiones, y para ser mínimamente organizado es necesario definir un layout del repositorio. Si le echáis un ojo al repositorio de eOPSOA veréis la siguiente configuración:

• code: en este directorio iré subiendo el código fuente de la aplicación. Dentro hay otros tres directorios trunk, branches y tags. No es obligatorio pero es una práctica común dentro del mundo de Subversion; muy brevemente se podría decir que en el directorio trunk se realizaría el desarrollo de la rama estable del producto, en el directorio branches se podrían crear ramas paralelas de desarrollo, sobre todo para añadir características nuevas que no podrían ser muy estables, hasta que maduran lo suficiente como para volver a trunk. Y en el directorio tags se podrían ir creando puntos interesantes, como por ejemplo la revisión que marca la versión 1.0 del software.
• management: aquí iré subiendo los artefactos que se vayan generando, como por ejemplo el subdirectorio analysis_design que contendrá el modelo de Rational Rose de diseño, planning donde irá la planificación del proyecto, requirements el modelo de requisitos de Rational RequisitePro... etc.
• y por último, proof-of-concept, que será algo parecido aun cajón de sastre, donde iré subiendo ejemplillos o pruebas que crea que puedan ser útiles.

Estado actual, y trabajo para esta semana...

Teniendo una planificación, y un repositorio, tenía las herramientas que me hacían falta para empezar a trabajar y crear cosas útiles. Por algo habré hecho ¿no?, aparte de no escribir en el blog... :-P. A estas alturas puedo decir que he finalizado la primera iteración ¡bien!, y tengo lo siguiente:

• Tengo especificados los requisitos funcionales (casos de uso) para la primera y la segunda iteración. Me falta generar documentación, UML sobre todo, para describir la activación de los plugins en Eclipse, estructuras de datos y demás.
• He creado el esqueleto/armazón/stub de los dos módulos que voy a desarrollar por ahora. Por ahora hacen algo muy básico: básicamente se limitan a registrarse en Eclipse, definen una perspectiva, una naturaleza y crean proyectos (vacíos), pero es un comienzo. Sobre estos dos plugins iré construyendo el resto de funcionalidades.
• ¿He dicho que estoy aprendiendo un huevo sobre Eclipse? ;-)

El trabajo que se plantea para esta semana que entra es el siguiente:

1. Especificar los modelos EMF para el asunto de la gestión de los documentos que necesita OPSOA para caracterizar el software a certificar: el documento de visión , el glosario y un checklist.
2. Crear una serie de formularios para dar soporte a la edición y posterior persistencia en XML de los modelos anteriores.
   

Las tareas no parecen tampoco muy complicadas, y el asunto de la persistencia en XML no es complicada porque aunque lleva más trabajo definir los modelos de los documentos con EMF, merece la pena porque se encarga el mismo EMF en serializar y deserializar el modelo en XML.

El principal problema con el que me enfrento ahora es el siguiente... que Eclipse es muy grande, y muchas cosas dependen de otras para realizarlas. Por poner un ejemplo, para hacer el formulario que he comentado antes, debo implementar la interfaz IFormEditor del API de Eclipse, porque realmente estoy realizando un editor. Bueno, pues para comprender el asunto de los editores, antes debo estudiar también las views, y para las views necesito conocer anteriormente el tema de las JFace Viewers... ahí es na. El API es enorme, hay muchas cosas que dependen de otras, y a diferencia del API de Sun (que es la que conocía hasta ahora) que es más restrictiva en cierto modo, y te "guía" a la hora de realizar las cosas, esta es mucho más flexible. Puedes hacer lo que quieras a tu aire... pero lo primero, posiblemente tardes más, y no se integre bien con la plataforma, o directamente no te funcione. O lo haces a la Eclipse way, para ello debes estudiar y mirar código de los demás, y eso también lleva tiempo y por desgracia no es algo de lo que me sobre actualmente.

Me está ayudando un montón un libro que compré en eBay hace un par de semanas, se llama The Java Developer's Guide to Eclipse. Es un libro muy muy bueno, yo diría que fundamental si se está comenzando con el asunto de la creación de plugins/RCP para la plataforma Eclipse. Es un mostrenco de más de 1000 páginas, escrito por ingenieros de IBM que estuvieron/están trabajando en Eclipse. Entre historias de cambio euro/dolar, y gastos de envío me costó algo más de 40€, pero sinceramente creo que vale cada uno de esos euros :-)

Bueno, nada más por esta semana, un abrazo muy grande a todos :-)

Happy hacking!!