Diseño

Esta fase esta compuesta de una serie de mejoras y retoques en el código de la aplicación, cuyo fin es aumentar la funcionalidad obtenida en la fase de implementación.

El principal logro que se obtiene con la introducción de mejoras es el cumplimiento de los requisitos temporales exigidos en cuanto a ejecución.

Aunque el sistema funcionaba correctamente el tiempo de respuesta era excesivo, lo que le hacía bastante incómodo y lento de manejar. Por eso se decidieron una serie de mejoras sobre el código original, las cuales se han detallado anteriormente en este capítulo como parte del prototipo anterior y ahora las pasamos a enumerar, ya que fueron diseñadas e implementadas en el prototipo de optimización.

• Uso de guardas y acciones propias de PFS. Al inicio, PFS funcionaba sólo programándolo con guardas y acciones que se apoyaban en scripts externos. Por lo tanto el tiempo de respuesta de cualquier acción por parte del usuario sobre nuestro sistema de ficheros programable era realmente considerable. Esto era así, dado que para responder al usuario, PFS tenía antes que terminar de comprobar y ejecutar las guardas y acciones, respectivamente, que la acción en cuestión implicaba. Estas acciones y guardas consistían en la ejecución de scripts externos a PFS, que en ocasiones se hacían demasiado costosos.

  La solución a esa tardanza de respuesta de PFS programado con scripts externos, pasaba por conseguir que el sistema de ficheros programable tuviese autonomía para entender y ejecutar las acciones y guardas más habituales, que cualquier usuario podría usar en su fichero de pautas de comportamiento. Por lo tanto, se tuvo que añadir más código al sistema desarrollado, para obtener dicha funcionalidad.

  Las guardas y acciones que PFS entiende después de esta optimización son tratadas internamente, por lo que el tiempo de ejecución se reduce de forma extraordinaria. Además, conseguimos que la programación del sistema sea más cercana al usuario, ya que muchas de las guardas y acciones para las que antes se tenía que hacer un scripts, ahora solo tiene que usarlas en su fichero de pautas con el que arrancará el sistema.

• Ajuste de las comprobaciones de las guardas. Después de la optimización anterior, tenemos un tiempo de respuesta razonable. A pesar de ello, ese tiempo podía ser mejorado, ya que se observó que no era necesario comprobar todas las guardas sobre los ficheros del sistema en cada interacción del usuario con PFS. Es decir, si una determinada guarda se encarga de comprobar una condición sobre el tamaño de los ficheros, después de una primera comprobación no tendrá que volver a comprobase a no ser que el fichero haya cambiado entre interacción e interacción del usuario con el sistema.

  Obtener esta mejora en nuestro sistema conlleva introducir un flag a los ficheros del sistema, que se encargue de indicar si ese fichero ha sido ya comprobado por cada una de las guardas existentes en el fichero de pautas de comportamiento. Si es así, el flag de ese fichero se activa, saltándose cualquier comprobación más en el sistema sobre él. Cuando el fichero sea modificado, su flag se desactivará, indicando que tiene que volver a ser comprobado por cada una de las guardas, ya que sus condiciones pueden haber cambiado.

  Al igual que respecto a las guardas, esta mejora es también aplicable a las acciones. Por tanto, con la introducción de dos flags en los ficheros, conseguimos reducir la carga de operaciones en nuestro sistema de ficheros programable.

• Operadores en guardas. La programación de PFS en un inicio, debía de hacerse usando sentencias de tipo if-condicion-then-accion/acciones, de manera que la condición de cada una de las sentencias debía de ser una única comprobación de guardas. Si se quería comprobar el cumplimiento de varias guardas para la consecuente ejecución de una o varias acciones, se debían encadenar varias sentencias con una comprobación de guarda cada una. Es decir, se debían de encadenar las sentencias.

  La incomodidad que estas sentencias nos daba, fue solucionada cambiando el lenguaje de programación de estas sentencias en PFS. Se paso a usar sentencias del tipo if-condicion/condiciones-then-accion/acciones. De esta forma, si se quieren comprobar varias guardas distintas, cuyo cumplimiento ejecuta una o varias acciones, no se tiene porque encadenar sentencias.

  Por parte del usuario, las condiciones de una determinada sentencia if, deben de ser expresadas en notación de operadores. Para ver su uso correcto, remitimos desde aquí al capítulo de Validación, en él que se pueden ver varios ejemplos.

En la siguiente figura, mostramos como quedaría el diseño del sistema de ficheros en este prototipo. Se muestran en una tonalidad gris los módulos o partes con las que ya contábamos en el prototipo anterior, los cuáles no han sido modificados, y se han marcado en negro los módulos que se han modificado para cumplir los requisitos de esta última fase de desarrollo.

Figura 4.9: Diseño PFS.

El compilador del sistema encargado de leer y analizar la sintaxis del fichero de configuración, se ha viso modificado, ya que ahora deberá dar por validas nuevas construcciones en las reglas como por ejemplo la precedencia de operadores en las guardas. Además nuevas de la precedencia de operadores, el incluir nuevas guardas también ha hecho que el compilador haya sido cambiado. La estructura que guarda las reglas interpretadas ha sido cambiado acorde con el compilador para poder almacenar los nuevos tipos de guardas que se han registrado en este prototipo.

En cuanto a las funciones de PFS, ahora deben de acceder de distinta manera a las reglas interpretadas, ya que su estructura, como hemos dicho, ha cambiado. Los ficheros almacenados en el sistema deberán ahora ver cambiada su estructura de almacenamiento, para poder contemplar la información necesaria para el ajuste de las comprobaciones de las guardas que antes se ha comentado ampliamente en este mismo apartado.