Hemos visto en el punto anterior como se ha ampliado la abstracción relacionada con la vista. Sin embargo, hay dos aspectos distintos en lo que concierne a las vistas, el primero son las ventanas a través de las cuales se recibe interacción por parte del usuario, pero dentro de estas puede encontrarse un área en donde se desplieguen gráficas. Puesto que desde un principio se penso aprovechar el hecho de que la plataforma en la que se deseaba implementar la aplicación posee hardware de aceleración de gráficas, y pensando también en aspectos de portabilidad a futuro, es conveniente separar todo lo relacionado a la graficación en una nueva abstracción. Esta abstracción encapsula todos los comandos que se encarguen de realizar gráficas. Otra ventaja de hacer esto es que se pueden cambiar las librerias de gráficas o de interacción sin que se afecten mutuamente. Es interesante notar que normalmente las librerias de interfases con el usuario no tienen la capacidad de dibujar gráficas de alto rendimiento.

    De ahí que hayamos decidido tener una clase llamada C_AreaGrafica. Esta clase se encarga de administrar todo lo que aparece dentro de las áreas de dibujo. Todas las ventanas que necesiten desplegar gráficas tendrán una instancia de esta clase (o varias si es necesario).

    La colección de datos también tendrá una referencia a esta clase, así cualquier objeto instanciado a partir de una de las clases derivadas de esta podrá pedir ser desplegado. El área gráfica deberá tener operaciones que permitan desplegar los diversos tipos de objetos, así, podrá desplegar un volúmen, una imagen, un histograma, etc... También tendrá posibilidades de realizar algunas 'primitivas' gráficas, cómo dibujo de lineas y puntos por ejemplo.

    A continuación se muestra un diagrama de clases donde se detalla lo descrito anteriormente.

4.4 Refinamientos de la colección de datos.

    En el punto anterior hemos hecho énfasis en el mejoramiento de las abstracciones concernientes al manejo de la interacción y de los procesos. Esto consituye dos de las partes principales dentro del diagrama de clases de análisis, sin embargo, también debemos refinar la parte de la colección de datos, que es en cierta forma el 'nucleo' de la aplicación.

    Veamos de nuevo cómo se definió esta parte en el diagrama de clases de análisis.

    En esta propuesta inicial se reagrupo el Stack, el Volumen y el Histograma, dado que todos son en el fondo un arreglo de distintos tipos de dato, se penso que podian ser todos instancias de la clase C_ColeccionDeDatos, sin embargo, durante la etapa de diseño se cuestiono nuevamente la necesidad de que el Histograma formase parte de las clases derivadas de la colección de datos. Varios puntos revelan que esto no es totalmente necesario. En particular se pueden mencionar:
 

• No es necesario cargar y guardar datos de un histograma ya que estos se calculan rápidamente y dependen de una imagen. El guardar el histograma y la imagen juntos no es algo muy práctico.
• No es necesario que las imagenes siempre tengan un histograma calculado, pues esto podría utilizar memoria inutilmente.
• Normalmente sólo se van a emplear histogramas para imágenes con tonos de gris, por lo que el tipo de dato que compone su arreglo será más probablemente alguno de los tipos 'nativos' (int, char), esto permite hacer objetos de un tamaño menor y no es tan necesario instanciar la clase abstracta con uno de estos tipos de datos, es más sencillo implementar un arreglo 'común y corriente'.

    Entonces el nuevo diagrama de clases de la colección de datos es el siguiente:

    En este detalle podemos ver como quedaron las diversas clases. Es importante notar que las clases C_Punto y C_Imagen heredan a partir de C_DatoDeColeccion. La razón por la cual sucede esto es por que la C_ColecciónDeDatos delega varias de las responsabilidades a los objetos que componen su arreglo y estas pueden no ser forzosamente necesarias. El heredar de C_DatoDeColeccion garantiza que al ser llamadas estas funciones por la clase instanciada no se producira un error debido a que no estan declaradas. Las operaciones que declara C_ColeccionDeDatos son las siguientes:
 

• ReservaMemoria()
• LiberaMemoria()
• CargaDatos()
• GuardaDatos()

4.4.1 El arreglo como lista ligada.

    En la parte de análisis de la aplicación se menciono que la Colección de datos era una clase que representaba un arreglo de datos de tipo diverso. No se menciono nada sobre la forma en que se almacenaban estos datos. Una solución al problema fue emplear una estructura de datos para almacenar los elementos. Así la colección recibe los mensajes tales como las peticiones de datos, y los pasa a la estructura de datos que se encarga de hacer la búsqueda. La ventaja de esto es que la estructura de datos queda encapsulada y puede ser cambiada sin repercusiones para el resto de la aplicación. Otra ventaja es que la estructura puede llevar el control sobre la memoria que se esta empleando y se evita perder memoria que no se libere.

    La estructura elegida fue una lista ligada pues la colección representa en cierta forma un arreglo 'linear' de datos. La colección tiene entonces una lista ligada agregada. A continuación se muestra la colección junto con la lista ligada.

  Regresar al indice.             Ir a página siguiente.