¿Quieres Patrocinar?
Envíanos un correo a contacto EN concursosoftwarelibre PUNTO org
La base de datos actual a sufrido diversos cambios con respecto a la inicial, de todas formas aquí les mostramos como fue nuestro primer boceto y como nos enfrentamos al problema de lograr convertir esas ideas en tablas que nos fuesen útiles.
Para realizar la conexión con la base de datos a través de Mono usamos una de sus librería en conjunto con la librería de SQLite3, la librería de Mono es “Mono.Data.Sqlite.dll” y se encuentra en la carpeta donde se instalo Mono mas concretamente en esta ruta “Mono-2.2\lib\mono\2.0″ con añadir esta última librería a las referencias de nuestro y soltar la librería de SQLite3 en la carpeta donde estemos ejecutando nuestro programa podremos realizar la conexión la base de datos.
Al principio este blog iba a ser para comentar el desarrollo de eOPSOA y discutir decisiones de diseño, explicar como trabajo... etc. Sin embargo, y debido a que casi todo el tiempo que tengo lo dedico a diseñar y programar, apenas he escrito nada sobre el desarrollo. Eso de dejar que el código hable por uno mismo está bien, pero hay veces que uno usa herramientas o tiene truquillos que quizá sean interesantes, y que quizá sean interesantes para los demás.Como comenté antes, la metodología de trabajo que sigo es una adaptación de RUP. Tengo marcadas unas iteraciones, y en cada iteración hay una serie de tareas que tengo que realizar. Normalmente lo que suelo hacer al principio de cada iteración es modelar los requisitos funcionales y realizar el diseño para esa etapa usando Rational Rose y Rational Requisitepro. En los directorios /management/trunk/analysis_design y /management/trunk/requirements podrás encontrar los artefactos. Además, otra tarea que realizo es esbozar la UI, que es de lo que os quiero hablar. Luego le presento todo eso a los tutores del proyecto, y con las correcciones que me hacen refino todo y ya me pongo a programar. Hasta ahora no había subido al repositorio los esbozos de la UI, pero a partir de ahora los iré metiendo en /management/trunk/ui_sketches. Al principio usaba papel y boli, pero el problema que tiene es que al final siempre terminaba perdiendo los esbozos, y como que no tengo scanner difícilmente iba a poder enviarlos por correo. Estuve buscando herramientas de prototipado de interfaces, y la herramienta que más me gustó, y que vengo utilizando, se llama WireframeSketcher, y es otro plugin sobre Eclipse. Como nota friki decir que utiliza EMF y GMF, es curioso lo que se puede hacer con estas herramientas :-). La lástima es que es software propietario, pero el autor no tiene problemas en dar licencias a aquellos que se pongan en contacto con él y participen en un proyecto de Software Libre. Además ha comentado varias veces que en un futuro cercano tiene pensado sacar una versión gratuita más o menos funcional, y quién sabe, quizá hasta termine liberando algo. El ritmo de desarrollo es brutal, y poco a poco se van añadiendo funcionalidades que lo hacen un software muy útil.Las dos imágenes anteriores se corresponden al prototipo que hice, y a la pantalla final que resultó. Aunque quizá la paleta de controles de WireframeSketcher es un poco pequeña, al menos en mi caso es suficiente y se ajusta bastante bien a los controles que ofrece JFace/SWT. Y ya para dejar de hacer spam comentar que la ventaja principal que le veo respecto a otras herramientas de prototipado como Pencil es que es muy sencillo y rápido de usar, se integra con Eclipse, y que funciona realmente bien. Además que aunque sean en blanco y negro, salen los esbozos mu bonicos si O:-)Por último, he subido en el área de documentación de la forja una serie de PDFs que usé para estudiar los prototipos de interfaz de eOPSOA que he estado haciendo.
A pesar de que consideramos que esta fase ya la hemos superado veo de interés plantear aquí los problemas e inquietudes que nos fueron surgiendo a lo largo del desarrollo de Ideldes.
Para lograr encarrilar el proyecto decidimos realizar una serie de reuniones (no digitales) en las cuales planteamos diversos puntos de vista e intercambiamos opiniones, la verdad es que fueron de mucha utilidad, sobre todo para tener los objetivos y métodos más claros. Estas reuniones no fueron únicamente realizadas entre los miembros del proyecto sino que contamos con la ayuda y el apoyo de una Intérprete profesional de la Lengua de Signos, Tamara Corral para solventar aquellas dudas más complejas sobre el correcto uso e interpretación de la Lengua de Signos.
De momento llevamos 2 reuniones hechas y vamos a exponer aquí los resultados obtenidos de su realización:
Primera reunión: (Con Podcast)
Principales problemas:
Segunda reunión: (Sin Podcast)
PSD: “Ahora empieza lo complicado”, llevar todo esto a código
PSD2: Agradecer tanto a Tamara por su apoyo y profesionalidad como a Javier Azcuna por su aporte musical al podcast.
Enlaces | Tamara Corral | Javier Azcuna
planficiacon_pfc
Aquí os dejo la planificación que me he propuesto con cara al concurso y que cumpliré a raja tabla, debido a que he estado programando a la ligera y luego tiene consecuencias nefastas , y encima que uno hace su proyecto de fin de carrera y libre, tiene doble responsabilidad y no debo subir cualquier cosa, ya a partir de ahora me pondré serio con el proyecto
Reitero que a pesar de esto pondré una versión operativa del juego como una rama del proyecto (rama que mejor olvidar y que será un borrador de lo que quiero conseguir)
Me tengo que poner las pilas antes que me absorban los exámenes de Junio.
Un saludo a todos.
Si habéis echado un vistazo al SVN durante esta semana, habréis visto que ha tenido bastante movimiento y que ha sido debido al fruto de una nueva colaboración en el proyecto.El caso es que Estela me ha echado una mano para internacionalizar eOPSOA. Por ahora la interfaz está traducida al español y al inglés, y dentro de muy poco lo estará también en francés. Que lujazo ¿no? :-P¡Muchas gracias Estela! :-)
Después de alrededor de 4 meses de desarrollo, estoy orgulloso de publicar la versión 0.1.1 de eOPSOA. Esta release no se puede considerar para producción, porque carece de la mayoría de características que pueden hacer eOPSOA útil para el analista. Sin embargo la intención es que se testee, para corregir los pequeños fallos que pueda haber de los cuales no sea consciente.Para descargar eOPSOA tienes tres opciones:
Las características de la versión 0.1.1 son las siguientes:
Una característica que no se había planteado originalmente, y que creemos que puede ser interesante, es la forma en la que definimos los flujos básicos y alternativos de cada UC. Los flujos están compuestos por pasos, y estos a su vez pueden estar compuestos por pasos. Los pasos se pueden marcar como de entrada o de salida, y asignarles variables.Para la siguiente iteración se va a trabajar en el soporte de pruebas: definición de escenarios, integración con algunas herramientas de testeo funcional y de calidad de código... etc. Si alguna vez habéis trabajado testeando funcionalmente una aplicación, estaréis de acuerdo conmigo en que definir los escenarios y todas las combinaciones de variables es un auténtico rollo. Aquí entra lo que he comentado antes de la decisión de diseño que se ha tomado al implementar el soporte de UC. Vamos a intentar que hasta cierto punto la generación de escenarios sea automática, utilizando la información "extra" que hemos pedido al realizar la definición de los UC.De cómo se implemente el soporte para los Tests de Pruebas va a ser crucial para la utilidad (o inutilidad) de eOPSOA. Próximamente escribiré de cómo estoy realizando esta tarea y de los problemas que estaré encontrando :-)
Eclipse, además de un IDE para Java fantástico, es también una plataforma para el desarrollo de aplicaciones. Estas o bien pueden ser plugins (como el que estoy haciendo yo), o aplicaciones RCP como pueden ser Cool Imaging Project, de unos compañeros que también están compitiendo en el CUSL (saludos!!). El caso es que al ser Eclipse al 99% modular, se presta a ser extendido. La Wikipedia tiene un artículo muy interesante sobre Eclipse, en developer.com hablan de su arquitectura, y en el libro The Java Developer's Guide To Eclipse (muy muy recomendable) hay muchísima más información. Como a veces lo más sencillo es una imagen, he tomado prestada una imagen de ese libro que es representativa de la arquitectura de EclipseQuizá el componente más usado de Eclipse es JDT, porque de un modo u otro todos los que desarrollamos sobre Eclipse lo utilizamos. Pero con la tendencia actual de ver a Eclipse como un framework de desarrollo de aplicaciones han aparecido proyectos alrededor que son muy interesantes, como por ejemplo BIRT, Mylyn, DTP... si, todo son siglas ;-)Uno de estos componentes que me está siendo especialmente útil es EMF, que responde a Eclipse Modeling Framework Project. En plan rápido, EMF es un framework para el modelado y gemeración de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado. Desde la especificación de un modelo descrita en XMI, EMF proporciona herramientas y soporte para generar un conjunto de clases Java para el modelo, además de clases adapter para soportar la visualización y la edición del modelo. Como imagino que esta descripción tampoco es muy útil, y hay sitios donde pueden explicar con más criterio que yo en qué consiste EMF, voy a intentar explicar porqué es útil para mi proyecto.Imaginemos que estamos desarrollando una aplicación en la que hemos identificado un modelo de datos relativamente complejo, y que debemos ser capaces de serializar y deserializar desde XML. Por ejemplo este, descrito en UML, y que modela parte del soporte para Casos de Uso que tiene eOPSOA:Este modelo se podría implementar sin problemas en Java, pero sería una tarea cuanto menos dolorosa. Y si a esto añadimos el asunto de la serialización/deserialización en XML, listeners, adapters... etc., nos podemos dar cuenta que no es un asunto trivial.Si desarrollamos un plugin para Eclipse, una aplicación RCP, o simplemente una programa Java, nos puede resolver la vida. Entre otras muchas cosas, con EMF podemos hacer:
A mí al menos, me ha resuelto la vida. Si le echáis un ojo a mi SVN, el plugin org.uclm.eopsoa.core es prácticamente un modelo EMF un poquito grande, y todo el código Java que me genera automáticamente. Si queréis comenzar con esto hay bastante información disponible en Internet, pero lo suyo es comenzar mirando la documentación de EMF, leer la guía para programadores, e intentar hacer los tutoriales. Hay una chuleta de referencia que viene muy bien, y si sabes que te vas a pegar mucho han sacado hace poco la segunda versión del libro EMF: Eclipse Modeling Framework. No es barato pero cubre mucho mucho mucho más de lo que puedas encontrar en Internet, y es extremadamente útil.No sé si os habré convencido, pero para terminar voy a comentar algunas cosas que he aprendido durante estos meses usando EMF:
Espero que este post haya sido útil, si alguien quiere comentar lo que fuera es bienvenido :-)
No sé si alguno se acordará de algunos años como estaba el panorama en GNU/Linux. Yo comencé cuando la cosa iba más o menos bien, allá por el año 2002, y mi primera distribución fue una RedHat 7.3. Por aquel entonces estaba comenzando el tema de las conexiones de banda ancha (aunque realmente no eran tan anchas... ONO ofrecía por aquel entonces 64 kbps) y aunque poco a poco se iba haciendo hueco Internet en casa, no éramos tantos los afortunados internautas. Decía que mi primera distro fue una RedHat 7.3, y aún recuerdo cómo descubrí lo que por aquel entonces se llamaba dependency hell cuando intenté instalar algún que otro RPM suelto que encontré por ahí: el Compu's Messenger (el abuelo del AMSN actual), los infames drivers binarios de la NVIDIA, el JRE 1.4 de Sun, algún que otro juego... etc. Era una gracia eso de tener el modem de 56 kbps y ver como un paquete depende de otro, otro de otro, otro de otro... y después de descargar 60 megas de paquetes descubrir que has liado tal pisto, que no hay otra solución casi que reinstalar de 0 el sistema. Qué tiempos aquellos, luego descubrí Debian y su bendito apt-get; fue entonces cuando descubrí el cielo. Pero eso es otra historia.Todo lo anterior venía a cuento porque parece mentira, y en pleno año 2009 algunas cosas no han cambiado tanto, y si no andas con tiento te puedes encontrar con el mismo problema. No sé si lo habré comentado antes, pero Eclipse es modular 100%... en realidad todo está descompuesto en n-mil plugins. Eso tiene sus ventajas, y a la vez sus desventajas. Quizá su mayor desventaja es la instalación de plugins nuevos, que como no tengas cuidado te puedes encontrar con el problema que he comentado antes: un infierno de dependencias. A partir de la versión 3.2 (creo) Eclipse introdujo un componente muy interesante llamado Update Manager, donde se añadían Update Sites desde los cuales te puedes bajar plugins y features, y con un poco de buena suerte se calculaban las dependencias de tal forma que no tuvieras que sufrir la tortura de resolverlas a mano. Versión a versión ha ido mejorando la cosa y en la versión 3.4, aunque es lento como el infierno, es prácticamente usable.Aprovechando que el proyecto está avanzando poco a poco, y que ya hay algunas cosas que se pueden ver, pensé que quizá sería buena idea montar un Update Site para distribuir de forma rápida el proyecto, y que quien estuviera interesado probara el software no sufriera tortura. Quién sabe, a lo mejor así alguien se anima a rellenar algún que otro bug report... no sé. Hablé con la gente del Centro de Datos de la ESII (gracias Juan Carlos!!! :-)) y han sido tan majos de proporciarme un sitio donde poder ir colgando el Update Site. La URL es http://eopsoa.albacete.org, a que mola ¿verdad? ;-)Bueno, para ser sincero no he colgado todavía nada, pero por ahora he escrito un HTML guarro donde describo de forma somera el proyecto, y las instrucciones para descargar las fuentes y los binarios. Cuando termine un par de cosas que estoy implementando lo subo, palabra O:-)He estado pensando en el estado del blog y del proyecto, y creo que no he sido capaz de describir muy bien de qué va mi proyecto. En parte ha sido por desidia mía, pero por otra parte también es verdad que estoy que no me cojo el culo... por eso he pensado que lo mejor sería colgar la prememoria del proyecto que envié cuando inscribí el proyecto en el CUSL, y que aquel que esté interesado que le eche un ojo.Y nada más por ahora, dentro de poco escribiré otra entrada donde intentaré comentar el estado del proyecto, y de las ideas que tengo para el futuro, que creo que pueden ser interesantes.Happy hacking!!
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ónLa 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 repositorioUna 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:
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:
El trabajo que se plantea para esta semana que entra es el siguiente:
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!!
Parece que por fin han comenzado las actividades del II Concurso Universitario de Software Libre de Castilla-La Mancha, suscrito en el III Concurso Universitario de Software Libre Estatal en su modalidad local.Lo primero presentarme: me llamo David Castellanos Serrano, soy estudiante de Ingeniería Informática en la Universidad de Castilla-La Mancha, y durante este curso estaré ocupado con algunas asignaturas, y sobre todo con mi Proyecto Fin de Carrera. Mi PFC trata sobre el desarrollo de una herramienta que de soporte a un marco metodológico de certificación de calidad de Software Libre llamada OPSOA (OPen SOurce Assessment), y que han desarrollado dos profesores de aquí, y que dan la casualidad que son los tutores de mi proyecto.Mi participación en la III CUSL es presentando mi PFC, y el proyecto se llama eOPSOA. Así a grandes rasgos, y completando lo que he escrito antes, es implementar una serie de plugins para Eclipse para soportar el marco metodológico OPSOA. El año pasado también estuve apunto de participar junto con mi grupo de una asignatura en otro proyecto, pero nos quedamos fuera por el entorno que usábamos (VS C# puagh!).Comentando por encima algunas cosillas técnicas del proyecto, que a todos nos encantan: el lenguaje de programación será Java 6, estará licenciado con la licencia EPL, usaré la plataforma Eclipse y sus n-mil frameworks y librerías (SWT, JFace, EMF, GMF, CNF... etc.). ¿He dicho que me encantan las siglas?, pues lo digo ahora ;-)Desconozco quién será la audiencia de este blog, posiblemente se limite a mi novia, algunos amigos (hasta que se aburran) y algún que otro despistaillo incauto que pille. La idea que llevo yo es intentar al menos hacer una entrada semanal, posiblemente los domingos por la tarde. Intentaré comentar qué quiero hacer la semana siguiente, qué tal se me fue la anterior, y según cómo me vea de tiempo a lo mejor comento algunas decisiones de diseño y de implementación que voy tomando según avanza el tiempo, ya veré.Pues ahí queda todo, nos vemos este domingo ;-). Mi ocupación de esta semana es aprender un poquillo sobre cómo gestiona Eclipse el asunto de los proyectos: workspaces, natures, navigator...Happy hacking!