Código

Y por fin llego el día... ya ha empezado el trabajo duro y de darse de palos con las librerías, el entorno (Eclipse), la forja con su SVN y todo lo demás pero es fácil si se intenta y hoy por fin a partir del diagrama de clases creado con Umbrello he autogenerado código, lo he editado un poco y ya se encuentra la estructura del programa en la forja.

Diagrama de clases

Por fin de vuelta tras el parón examenil, una pequeña mudanza y un merecido descanso es hora de volver a continuar con el proyecto. A partir del análisis de requisitos y del díagrama de casos de uso ya se puede empezar a definir las diferentes clases que foromaran la aplicacion. Así, por ejemplo, a partir del diagrama de casos de uso se observa que se pueden definir tres clases de interfaz de usuario. Una de ellas y la principal de la aplicación sera (como en casí cualquier aplicación) la ventana principal y en la cual se realizará presentación de los intrumentos disponibles y se visualizará el hecho de que el usuario toca algún intrumento para lo cual se controlará los eventos de teclado y ratón (dsWinMain).

Por otro lado también se necesitarán interfaces que permitan al usuario tener la posibilidad de añadir un nuevo instrumento y la configuración de cada uno de los ya existentes para lo que serán necesarias otras dos clases adicioneles (dsWinAddIntrumento y dsWinConfigIntrumento). Por último también y por relacionar los posibles elementos de interfaz que puedan presentarse para ilustrar undeterminado instrumento será necesario definir un control (dsCrlIntrumento). Estas clases de interfaz heredarán todas de sus clases bases dentro de la librería FLTK por lo que las ventanas heredern de la clase Fl_Window y el control dsCrlIntrumento de la clase Fl_Control. Por otro lado en cuanto a las clases que no pertenecen al interfaz es obvio que será necesario definir una clase que describa a cada intrumento y en la cual se guardarán los diferentes datos sobre este (fuente de sonido, intensidad, ...) y efectuar todas las operaciones que ya se han mencionado en la especificación de requisitos (cargar sonido, tocar sonido, subir y bajar la intensidad, ...) para lo que se define la clase dsIntrumento.

Además y como ya se ha dicho se pretende que los intumentos no se reproduzcan de forma idividual sino que lo hagan mezclandose entre ellos de forma que compongan una determinado ritmo (que será una clase futura para cuando interese guardad los sonidos), de modo que se define otra clase adicional (dsMixer) en la que se realizara dicha composición y que es la que se encargará finalmente de reporoducir los diferentes intrumentos que se vallan tocando. Con todo ello ya se puede definir el siguiente diagrama UML de clases en el que se detalla (más o menos) cada una de las clases descritas:

Interfaz de usuario

Va siendo hora de decidirse por alguna de las GUI existentes para crear el interfaz de usuario de DrumSim. En este caso y como se ha definido en los requisitos debe ser compatible con X11 (es decir cualquier escritorio Linux y tambén Mac) y con Windows. Además como en la aplicación se requiere el procesamiento en tiempo real de sonido cuanto menos ocupe y necesite el interfaz mejor. Ah! Y claro está tiene que ser libre.

En este caso y sobre todo por que es una de las GUI más eficientes he optado por Fast Light Toolkit (FLTK) que es compatible con sistemas Linux\UNIX con X11, Microsoft Windows, Mac OS X, etc. por lo que se adapta perfectamente a la especificación propuesta. Es si, tiene un pero, y es que debido a que en su desarrollo se ha enfocado a la eficiencia y al ahorro de recursos, se ha dejado a un lado el aspecto visual por lo que las aplicaciones quizas no sean tan resultonas como con otras GUI.

Casos de uso

A paritr de lo expuesto a lo largo del Análisis de requisitos se puede resumir la interacción entre el usuario y el sistema así como las funcionalidades principales a desarrollar de la siguiente forma mediante el diagrama de casos de uso:

Análisis de requisitos

Ahora que ya están definidos los requisitos, es un buen momento para empezar a definir de forma más formal que es lo que hará o mejor dicho que es lo que queremos que haga la aplicación a partir de esos requisitos informales de modo que lo siguiente que hay que hacer es tomar cada uno de los requisitos y explicarlos de un modo más técnico y teniendo en cuenta con que arquitectura se va ha contar.

En este primer punto ya sabemos que se necesita un PC que cuente por lo menos con un ratón (con rueda como ya se verá después) y un teclado (aunque esto parezca una obviedad es importante comentarlo). Pero ahora bien, como debe ser ese equipo, ya que otro de los requisitos ya descritos es que se hará una reproducción de varios sonidos en tiempo real por lo que sin duda esos sonidos tendrán que estar cargados en memoria y además habrá que contar con un procesador que sea capaz de mezclar estos sonidos casi a la vez que se reproducen. Sin duda es algo difícil de calcular ya que en este caso dependerá del SO, de las librerías que usemos, del interfaz que se cree, etc. por lo que en un primer lugar lo mejor sería ver que requisitos tienen algunas aplicaciones similares y establecer este como el requisito para un equipo en el que funcionará la aplicación. En este caso se utilizará como modelo la aplicación Linux MultiMedia Studio cuyos requisitos son un procesador a 1GHz y al menos 512 MB de RAM siendo estos valores los que límiten los recursos de los que se dispone para hacer funcionar la aplicación.

A continuación hay que centrarse en los requisitos más funcionales de la aplicación si bien ya se explican casi por ellos mismos a partirde la especificación de requisitos hay que redefinirlos de forma más precisa de cada uno de los puntos:

• El principal objetivo que se quiere desarrollar es la reproducción y mezcla de varios sonidos (intrumentos) así como la aplicaciṕon de efectos sobre estos (en principio solo el cambio de intensidad) al detectarse la pulsación del teclado (de aquí ya se podrían sacar esquemas pero me estoy conteniendo :P).

• El control de la intensidad debe realizarse en tiempo real al combinar controles de ratón y teclado. Es decir, al girar la rueda del ratón hacia un lado mientras se mantiene pulsada una tecla se bajará la intensidad del sonido asociado y si se gira al lado contrario pues al contrario.

• La relación entre cada tecla y su sonido debe ser configurable por el usuario.

• Además el usuario puede añadir nuevas fuentes de sonido y asociarlo a una determinado caracter de teclado para su reproducción así como eliminar los que ya han sido cargados previamente o editarlos cambiando su fuente de sonido por ejemplo.

• Los instrumentos que debe ser capaz de reporducir la aplicación por defecto (es decir propios de la aplicación) son los de bombo, caja (redoble, claqueta, caja), toms, tom suelo, platillos, hit hat y ride. Este requisito por suerte ya está cubierto.

• Y, aunque esto ya se debería haber comentado con anterioridad, el interfaz de la aplicación debe ser capaz de ejecutarse en Windows, y en los diferentes entornos de escritorio de Linux, por lo que tendrá que ser compatible con X11.

En resumen, para que la aplicación sea válida a los objetivos iniciales que se han propuesto anteriormente, el desarrollo debe cumplir tanto los aspectos funcionales mencionados como ser capaz de cumplir estos aspectos en la arquitectura indicada por lo que se deberá realizar el resto de las decisiones teniendo todos estos puntos en cuenta.

Especificación de requisitos

De las opciones ya propuestas en el braistorimng he decido que para una primera versión de la aplicación que más o menos además ya será utilizable cuente con los siguientes puntos ya desarrollados:

• Reproducción de los sonidos de bombo, caja (redoble, claqueta, caja), toms, tom suelo, platillos, hit hat y ride. Es decir, desarrollar la principal funcionalidad de DrumSim que es la sintesis de instrumentos de percusión en tiempo real en coordinación con las pulsaciones del teclado.

• Control individual de intensidad de cada uno de los instrumentos cargados en tiempo real a través de la combinación de ratón y teclado.

• Adición de nuevos instrumentos lo que permitirá aumentar la capacidad de la aplicación a través de nuevas funtes de sonidos de instrumentos de percusión u otros efectos de sonido.

• Configuración y manejo de los instrumentos cargados que permitirá borrar y editar sus características.

Con todo esto ya se debe de tener una pequeña idea de que es lo que se quiere conseguir pero queda mucho trabajo por hacer en los que habrá que definir los detalles de la aplicación.

Metodología

La idea del desarrollo de la aplicación es que avance poco a poco, es decir incluyendo tan solo unas cuantas funcionalidades en cada versión de las que se han propuesto en el brainstorming (asignando a cada tarea su prioridad) por lo que el proceso de desarrollo de la aplicación se basará en la selección de las funcionalidades a desarrollar o lo que es lo mismo una especificación de requisitos, seguido del análisis de cada una de estas funcionalidades, su diseño, su integración en la aplicación ya desarrollada o con las librerías disponibles y finalmente su codificación y publicación.

Una de las metodologías que permite desarrollar de una forma ciclica y ágil es Extreme Programing, una metodología que permite justamente lo que se pretenede que es realizar el proceso completo de análisis-diseño, codificación, etc. a partir de la epecificación de requisitos (que además en cualquier momento pueden cambiar) para cada fase del desarrollo. Finalemente una vez se hayan abordado los aspectos formales de cada una de las versiónes se procederá su codificación, si bién XP tiene un gran enfásis en el desarrollo de un código de calidad gracias a métodos como la Programación por parejas, pruebas unitarias y otras recomendaciones a seguir al escribir que se tratarán de seguir en esta fase.

Aquí os dejo un par de enlasces por si quereís más información:

• Página oficial de XP.

• Página wikipedia.

• Página en castellano.

Forja

Ya está lista la forja del proyecto en RedIRIS dónde se irá publicando la documentación, el código y los paquetes de instalación de la aplicación. Para acceder a la página con el resumen del proyecto os dejo este enlace aquí. Además desde allí podeis acceder a los foros, la lista de correo, repositorio de código y otros servicios que serán muy utiles a la hora de trabjar.

Empezamos

Y ahora en serio ya que ya por fin el proyecto DrumSim ha sido aceptado en el VI Concurso de Software Libre Universitario.
Podeís ver la ficha del proyecto aquí y el resto de proyectos presentados para esta edición aquí (es decir la competencia :P) y que en total suman 100 proyectos con 141 participantes. Desde aquí solo decir, que gane el mejor!

Otro aplazamiento más

Tras volver a aplazar del 7 al 14 de noviembre se vuelve a prorrogar el plazo ahora hasta el 20 de noviembre para la presentación de proyectos. Solo queda esperar y decir lo que siempre se dice en estos casos: Espain is different.