Capítulo 4. Diseño

A continuación, vamos a proceder a explicar el diseño realizado en el proyecto CAMX.

El desarrollo se ha llevado a cabo a través de un proceso iterativo en espiral, incrementando en cada iteración el desarrollo del mismo añadiendo nuevas funcionalidades a cada versión que se ha realizado.

El lenguaje de programación que se ha usado para crear la aplicación ha sido Python.

Figura 4-1. Ciclo de vida

Una vez explicado ésto continuaremos viendo un ligera descripción de las clases principales, así como de los aspectos más importantes a tener en cuenta del diseño.

4.1. Clases utilizadas

4.1.2. Clase mensaje

La clase mensaje es la encargada de crear y analizar todos los mensajes XML que nuestra aplicación utiliza.

Generará los mensajes que nuestra aplicación envíe a la matriz por medio del procedimiento XmlGenerator, que en su mayoría se basa en el creado por Mark Pilgrim y que podremos encontrar en las referencias bibliográficas. Éste utilizando un mensaje XML para generar XML (a primera vista parece complicado, pero no lo es) construye el mensaje a raíz de un axioma, dependiendo del tipo de mensaje que le pidamos, como si de una gramática se tratara.

La clase gestiona el envío de eventos, puesto que realiza la llamada al procedimiento de la clase conexión encargado de escribir en ésta. Una vez que se envía el primer mensaje (que será el de Login) a la matriz con los parámetros por defecto, se obtiene de ésta los parámetros que serán utilizados para los siguientes envíos; éstos se guardarán en el diccionario de dispositivos 'dev'. Además de los dispositivos, también tiene otros parámetros de vital importancia para nuestra aplicación como son el identificador de mensaje ('msgID') o el path del mensaje XML utilizado para la construcción de los mensajes ('origen.xml').

Por otro lado, al realizar el análisis de los mensajes recibidos, extraemos el tipo al que pertenecen y dependiendo de éste, guardaremos los parámetros cuya información no sea de utilidad, como puede ser el evento del que se nos confirmó su activación, el valor de cierto entrada de audio, etc..

Como es explicado en la clase conexión, si en el momento de querer enviar un evento a la matriz, ésta nos envió un mensaje, nuestro envío será bloqueado (mediante un objeto condición) por la hebra encargada de leer lo escrito por la matriz, el bloqueo acabará en el momento en que la matriz sea respondida.

Ahora bien, nuestro mensaje se pudo bloquear en dos sitios, justo antes de ser completamente generado o justo después. Si lo fue después, un mensaje de respuesta de la hebra a la matriz pudo ser enviado mientras nuestro mensaje permanecía bloqueado; es por eso, por lo que es necesario refrescar el mensaje bloqueado, cambiándole para eso su identificador de mensaje ('msgID') que habrá caducado al haber sido ya utilizado por otro mensaje.