DocumentacionDelProyecto

3.- Análisis del sistema.

Como hemos visto en la parte introductoria a este trabajo, el primer paso a seguir durante el desarrollo de una aplicación es, antes que sentarse a ‘teclear’, el comprender de la manera mas completa posible las peticiones del usuario respecto a las características del producto que desea. Es evidente que durante esta etapa de desarrollo, la interacción con el cliente es obligatoria, ya que él y las personas que harán uso futuro del producto son los que comprenden realmente las situaciones que pueden presentarse durante la utilización. Primeramente vamos a citar los requerimientos que se nos presentaron, para ello se realizó una pequeña entrevista con el futuro usuario que expuso de manera global cuales eran sus interéses.

3.1- Requerimientos iniciales.

La obtención de requerimientos se facilita si se tiene un pizarrón disponible, y es recomendable que el cliente realice diagramas y exprese sus ideas de forma 'natural' es decir intentando enunciar con frases sencillas sus necesidades.

Se nos pidió:

Un Sistema de visualización 3D ampliable, esto es que pueda ser adaptable a futuros procesos de calculo.
Que se pueda desplegar un stack de imágenes 2D, en su conjunto, ciertas características deben ser tomadas en cuenta, tales como la posibilidad de ver cierta imagen en detalle, o de variar el tamaño del montaje.
A la salida se desea obtener un conjunto de datos tridimensionales, o bien la posibilidad de generar una imagen 2D si no se realiza una reconstrucción.
El usuario debe pedir datos concernientes al conjunto de imágenes (la distancia, el tamaño...)
Que se pueda ver el montaje antes o después de ser procesado, así como la posibilidad de no perder la imagen original aun después de realizar el procesamiento.
Que se desplieguen histogramas de las imágenes.
Que se pueda interactuar con las imágenes en su conjunto.

En un principio no se ha especificado de manera concreta el tipo de procesamiento que se va a realizar sobre las imágenes, dado que esta herramienta se enfoca a la posibilidad de aplicar diversos tipos de algoritmos, y de poder agregar otros más posteriormente, una cuestión fundamental a tomar en cuenta es que el sistema sea extensible.

3.2 Situaciones potenciales.

Las situaciones potenciales, o principales que van a ocurrir al utilizar el sistema también se obtienen a partir de la entrevista con el cliente, simplemente se hace una 'recopilación de ideas', es decir, el cliente puede ir diciendo que cosas piensa que pueden suceder, estas se anotan, y posteriormente se reagruparán para el análisis de casos de uso.

Entre las situaciones más importantes que potencialmente se pueden presentar, encontramos:

Cargar datos en memoria. (Hay que introducir la información de los datos al cargarlos).
Guardar los datos.
Desplegar el stack. (Se debe poder modificar el despliegue para ver detalles u otras cosas).
Realizar segmentaciones (incluye configuración de parámetros del algoritmo).
Mostrar una imágen 3D. (Incluyendo la interacción con esta.)
Mostrar el histograma de una imagen.

Estas situaciones pueden parecer pocas pero involucran en realidad una gran cantidad de procesos para poder ser llevadas a cabo. Recordemos que se trata sólo de las situaciones principales.

Modelo CRC.

El paso siguiente en el análisis de requerimientos de una aplicación es la creación del modelo CRC. De acuerdo con Ambler, el modelo CRC es una colección de tarjetas CRC (Clase – Responsabilidad - Colaborador). Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, sus responsabilidades y sus colaboradores. A continuación se muestra cómo se distribuye esta información.

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realiza, sus atributos y métodos. Los colaboradores de una clase son las demás clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades.

En la práctica conviene tener pequeñas tarjetas de cartón por ejemplo, que se llenarán y que se mostrarán al cliente, de manera que se pueda llegar a un acuerdo sobre la válidez de las abstracciones propuestas.

Los pasos a seguir para llenar las tarjetas son los siguientes:

Encontrar clases
Encontrar responsabilidades
Definir colaboradores
Definir casos de uso (situaciones potenciales).
Disponer las tarjetas

Para encontrar las clases debemos pensar qué cosas interactuan con el sistema (en nuestro caso el usuario), y qué cosas son parte del sistema (en un principio se propuso un stack de imágenes, un volumen 3D, un montaje y un proceso de calculo), así como las pantallas útiles a la aplicación (un despliegue de montaje, una entrada de parámetros, un despliegue de volumen y una pantalla general). Una vez que las clases principales han sido encontradas se procede a buscar los atributos y las responsabilidades, para esto se puede formular la pregunta ¿Qué sabe la clase? y ¿Qué hace la clase?. Finalmente se buscan los colaboradores dentro de la lista de clases que se tenga.

Para el proyecto que estamos analizando, las tarjetas CRC que se propusieron inicialmente fueron las siguientes:

Esta colección de tarjetas representan un intento inicial de encontrar abstacciones útiles para la resolución del problema. Podemos ver que entre otras cosas se busco una abstracción a la Vista Gráfica, esto aparentemente podría no ser tán relevante desde un principio, pero es una buena costumbre separar las cuestiones dependientes de la plataforma (despues veremos esto con más detalle), aparte de que esta abstracción engloba la generalidad de las ventanas que podrán aparecer posteriormente.

La definición de casos de uso implica el estudiar qué tanta posibilidad hay de realizar las situaciones potenciales que el cliente propone mediante las responsabilidades definidas en las tarjetas. Por ejemplo, si una de las situaciones potenciales es la de cargar datos, podemos ver que la abstracción StackDeImagenes tiene prevista esa posibilidad. Esto se debe realizar para las diversas situaciones potenciales.

Se menciona que el último paso a seguir es el de la disposición de las tarjetas, efectivamente, ya que las tarjetas se pueden ordenar de diversas maneras, se debe de aprovechar esto para tratar de encontrar una estructura lógica. Por ejemplo, en el caso anterior nos podemos dar cuenta que el Stack de Imágenes ocupa una posición importante dentro del arreglo, mientras que el histograma no tanto. Esto nos ayudara posteriormente durante la representación del diagrama de clases para encontrar similitudes entre clases o relaciones entre ellas.

Regresar al indice. Ir a página siguiente.