Actividad 1: Conocimiento de Conceptos y Principios Con el grupo de trabajo del proyecto de formacin realice un documento que resuma los

siguientes conceptos, pueden apoyarse del material suministrado por el instructor a travs de la plataforma o de consultas en internet. 1. Que son los casos de Uso? 2. Definir cul es la Importancia de los casos de uso. 3. Cules son los smbolos o la notacin utilizados en UML, para la construccin de los casos de uso? Dar ejemplos. 4. Cmo se da Inicio a un anlisis de un caso de uso. 5. Como se simboliza un mensaje en los casos de uso, De un ejemplo.

1. Un Caso de Uso describe un servicio provisto por un sistema, es decir un modo especfico de usarlo. El conjunto completo de Casos de Uso especifica todas las posibles maneras en las que el sistema puede ser usado, sin revelar cmo esto es implementado por el sistema. Esto hace a los Casos de Uso apropiados para definir requerimientos funcionales en etapas tempranas del desarrollo del sistema, donde la estructura interna de ste an no fue definida. Debido a que los Casos de Uso no se manejan con elementos dentro del sistema sino que se centran en cmo el sistema es percibido desde el exterior, son tiles en discusiones con usuarios finales para asegurar que hay concordancia con los requerimientos realizados sobre el sistema, sobre sus limitaciones, etc. Ms precisamente, un Caso de Uso especifica un conjunto de secuencias completas de acciones que el sistema puede realizar. Cada secuencia es iniciada por un usuario del sistema. Esto incluye la interaccin entre el sistema y su entorno como tambin la respuesta del sistema a estas interacciones. 2. En mayor o menor medida, todos conocemos lo que es un caso de uso y para que se utiliza. Muchos profesionales ven la tarea de definir casos de uso como algo tedioso y aburrido que al final, no vale para nada. No voy a entrar a valorar la magnitud del error que creo que comete ese tipo de profesional con ese tipo de aseveracin. Definir un documento de especificacin funcional es tarea fundamental a la hora de defender nuestros proyectos y legitimar los cambios facturables a los mismos. 3.

4. Anlisis de casos de uso.

Otra de las herramientas esenciales para obtener una mayor comprensin del problema son los digramas de casos de uso. A continuacin se da una definicin y se muestra tambin como fueron empleados para la realizacin de la aplicacin. 4.1 Introduccin. Los casos de uso como los describe Karl E. Wiegers son "escenarios en los cuales el usuario interacta con el sistema que se est definiendo para lograr cierto objetivo especfico o realizar alguna tarea en particular". El mtodo que seguimos en nuestro desarrollo es el siguiente: a partir de entrevistas con los futuros usuarios del sistema, se intentan descubrir las diversas situaciones que se puedan presentar durante la utilizacin del sistema. Por ejemplo, si el cliente menciona la necesidad de cargar archivos desde el disco, entonces una de las situaciones de uso potenciales del sistema ser: "El usuario carga un archivo de datos". Ntese que los escenarios se describen como enunciados en el lenguaje del cliente. Una vez que se obtienen la mayor parte de las situaciones (recordemos que la naturaleza cclica del proceso implica que posteriormente podran aparecer nuevas situaciones que no hubiesen sido contempladas durante la primera aproximacin, y que por ello se deben realizar varias entrevistas con el cliente), debemos intentar reagruparlas y encontrar casos de uso generales que abarquen varias de las situaciones antes encontradas. As, el escenario de caso de uso es una instancia del caso de uso general. Hemos visto como los casos de uso son escenarios que se pueden presentar durante la utilizacin del sistema, pero tambin debemos tomar en cuenta a los actores. Un actor, de acuerdo con la definicin que encontramos en el tutorial de UML

(www.rational.com), es "alguien o algo que debe interactuar con el sistema en desarrollo". As, podemos pensar por ejemplo en que un doctor es un actor en un sistema mdico. Estos dos componentes, actores y casos de uso sern entonces representados en diagramas llamados diagramas de casos de uso. En estos diagramas se muestran los actores y los casos de uso, as como las relaciones que existan entre ellos, pues no todos los actores estn relacionados con todos los casos de uso. Tambin existen relaciones entre los casos de uso, destacan dos tipos distintos, aquellas de <<uso>> y las de <<extensin>>. Las relaciones de <<uso>> muestran comportamientos que son comunes a uno o ms casos de uso, las relaciones de <<extensin>> muestran comportamientos opcionales.

4.1.2- Descripcin de los casos de uso.

Enseguida veremos cmo se aplic lo antes mencionado dentro del proyecto. Para comenzar, retomamos las situaciones potenciales de utilizacin del sistema, pero detallndolas ms, primero se muestra el nombre del caso de uso y enseguida sus instancias:

Caso de uso: Transferencia de Datos - El usuario introduce un stack de imgenes. - El usuario guarda un stack de imgenes (procesadas o no). - El usuario guarda los datos de la reconstruccin (volumen). - El usuario carga una reconstruccin.

Caso de uso: Seleccionar Parmetros - El usuario introduce los datos del stack de imgenes. - El usuario selecciona un tipo de procesamiento y los parmetros especficos al proceso. - El usuario selecciona parmetros diversos del despliegue.

Caso de uso: Procesar Datos - El usuario realiza una segmentacin. - El usuario realiza una reconstruccin.

Caso de uso: Interactuar con Datos - El usuario interacta con la imagen 3D (rotacin...). - El usuario interacta con la imagen 2D (seleccin...) - El usuario interacta con el histograma.

Caso de uso: Desplegar Datos

- El sistema despliega datos en forma de montaje (2D). - El sistema muestra datos en forma de imagen 3D. - El sistema muestra datos en forma de histograma.

En lo que concierne a los actores, para nuestro proyecto solo tenemos un actor que es el usuario. El diagrama a continuacin muestra los casos de uso ,sus relaciones as como al actor antes mencionado.

2- Prototipo de la interfaz de usuario. Es importante presentar al futuro cliente/usuario un prototipo de la interfaz que tendr la aplicacin. Para ello se puede hacer uso de los digramas de flujo de la interfase, que muestran que interfases irn apareciendo dependiendo de las acciones que tome el usuario. En este caso, el requerimiento para la interfaz de usuario es sencillo, bsicamente se trata de una ventana con un rea grfica en donde se vern las imgenes con las que se esta trabajando y un men a partir del cual se pueden realizar las acciones tales como cargar/guardar, seleccionar procesos y ayuda.

Posteriormente se tendrn que agregar nuevas ventanas ya que cada proceso necesita ser configurado de manera distinta.

Para realizar un prototipo simplemente se debe de dar al usuario una idea de la apariencia de la aplicacin, esto es como un 'esqueleto' no funcional, para facilitar esto es recomendable hacer uso de alguna herramienta de construccion de interfases de usuario, tal como Visual C++, o en nuestro caso "form design", de xforms. 3. Anlisis de clases. Otro paso fundamental dentro de la etapa de anlisis del sistema es la de la realizacin de un diagrma de clases 'inicial', en realidad este diagrama retoma las tarjetas CRC que se realizaron anteriormente, tomando en cuenta su disposicin, as como el estudio de los casos de uso y finalmente el estudio a nivel generalizado del comportamiento en el tiempo de los objetos instanciados a partir de las clases, como veremos adelante. 3.1 Determinacin de las clases. Lo que se hace para pasar de las tarjetas a clases, es tomar cada tarjeta, y crear una clase para ella. Los atributos y responsabilidades de la clase se encuentran a partir de las responsabilidades de la tarjeta CRC. Las relaciones entre clases aparecen a partir de los colaboradores. En este momento tambin pueden descubrirse atributos comunes entre abstracciones y en ese caso es conveniente pensar en alguna abstraccin a nivel superior de la cual hereden las clases que compartan atributos. En nuestro caso podemos pensar que el Volumen 3D, el Stack de Imgenes y el Histograma son todos colecciones de datos, que comparten responsabilidades tales

cmo el desplegarse, cargar datos y almacenarlos. Por ello desde un principio decidimos reagruparlos al hacerlos heredar de una clase abstracta llamada Coleccion de Datos. Esto permitir posteriormente simplificar el estudio de las instancias de esta clase, por ejemplo al realizar el digrama de secuencia de cargado de datos, pues todas las clases hijas lo realizarn de la misma manera. A continuacin se mencionan las clases propuestas con detalle. 3.2 Diccionario de datos de las clases. El diccionario de datos de las clases simplemente detalla cada una de las clases que se han descubierto, se muestra el nombre de la clase (que por convencin se hace con un 'C_' y el nombre con mayusculas en sus letras iniciales y sin espacios), sus atributos y sus operaciones. No se da an un tipo de dato para los atributos pues esto es parte del diseo. (Esto se hizo siguiendo un ejemplo de la Universidad de Munich.) Nota: Dentro de las operaciones no se muestran aquellas que permiten tener acceso a los atributos, se supondr que para cada atributo hay operaciones que realizan dicha tarea. Otra cosa importante es que C_Punto y C_Color no habian sido descubiertas como abstracciones originalmente, pero dado que el volmen y el histograma son clases instanciadas a partir de C_ColeccionDeDatos, necesitan hacer uso de otra clase para su instancia, por ello se incluyen en el diccionario. La aplicacin es una abstraccin general del sistema y es conveniente representarla desde el inicio.

Nombre: C_ColeccionDeDatos Una coleccin de datos (es una clase abstracta de donde se derivan otras). Atributos: Datos Un arreglo de datos de tipos variados. Operaciones: CargaDatos Carga los datos a partir del disco. GuardaDatos Guarda los datos en el disco. CambiaDatos Cambia los datos. DespliegaDatos Despliega los datos. Configura Configura la coleccin si es necesario.

Nombre: C_StackDeImagenes Una coleccin de imgenes. Hereda de C_ColeccionDeDatos. Atributos: NumeroDeImagenes El nmero total de imgenes del stack. TamanoDeImagen El tamao de la imagen (en puntos). DistanciaEntreImagenes La distancia entre dos cortes (en mm). DatosDelPaciente Pequeo texto para datos tiles. TamanoDelPixel Tamao de un pixel (en mm). TamanoDelDato Formato de imgen (bytes/pixel).

Nombre: Atributos: stack. Operaciones:

C_Imagen Una imagen. DatosDeImagen Informacin que define la imgen NumeroDeImagen Un nmero que identifica la imgen dentro del Copia copia los datos de la imagen a otra o desde otra.

Nombre: Atributos: volmen.

C_volumen3D Una coleccin de puntos en el espacio 3D. NumeroDePuntos El nmero de puntos del que se compone el

Orientacin La orientacin del volmen en el espacio. Normales Las normales a los puntos. Operaciones: CambiaOrientacin cambia la orientacin del volumen3D

Nombre: Atributos:

C_Punto Un punto en el espacio tridimensional. CoordX La coordenada X CoordY La coordenada Y CoordZ La coordenada Z

Nombre: C_Histograma La informacin de una imagen representada como histograma. Atributos: ImagenFuente La imagen a la cual se le calcula el histograma. Operaciones: Calcula Calcula el histograma para la imagen dada.

Nombre: Atributos:

C_Color Un color definido como tres niveles, R, G y B. NivelR La componente roja del color. NivelG La componente verde del color. NivelB La componente azul del color.

Nombre: C_ProcesadorDeImagenes Se encarga de aplicar procesos sobre colecciones de datos. Atributos: TipoDeProceso Identifica el tipo de proceso que se va a aplicar. Operaciones: AplicaProceso Aplica un algoritmo o proceso determinado. SeleccionaProceso Selecciona uno de los posibles procesos a aplicar. Configura Asigna los parmetros necesarios al proceso.

Nombre: C_VistaGrafica Se encarga de toda la interaccion visual. Atributos: TipoDeDespliegue Define el tipo de interfase a presentar. Operaciones: AbreVentana Abre una ventana. EsperaInteraccion Recibe la interaccion. EnviaDatosAVentanaGrafica Despliega datos de la coleccion. Nombre: C_Aplicacion Operaciones: Inicia Inicia la aplicacin.

3.3 Diagramas de secuencia. Hemos definido las abstracciones iniciales para la aplicacin, pero debemos encontrar cual ser el tipo de relacin que existe entre estas abstracciones. Una herramienta til para aclarar este punto son los diagramas de secuencia. Estos diagramas muestran los mensajes que se intercambian las instancias de las clases durante el tiempo. Desde un principio intentamos aclarar qu tipo de relacin existe entre las abstracciones. (Vanse algunos consejos).

Una aproximacin util es de realizar un diagrama de secuencia por cada caso de uso o que sea representativo de cada uno de estos. En nuestro caso vamos a escojer los siguientes:

Cargar o Guardar una coleccin de datos (de Transferencia de Datos). Interaccin y despliegue de los datos . Aplicar un proceso (involucra Seleccionar Parametros y Procesar Datos).

Normalmente los mensajes que se ven en los diagramas de secuencia deben corresponder estrechamente con las operaciones disponibles para cada clase, pero en esta etapa en la que an se est buscando comprender bien el problema, pueden aparecer mensajes textuales que posteriormente sern refinados y corresponderan a funciones concretas de cada clase. Se presenta primeramente un diagrama 'general' de la aplicacin que muestra de manera global la interaccin entre el actor y la aplicacin y enseguida se muestran los dems.

Los diagramas de secuencia son los siguientes: Diagrama de secuencia Cargar/Guardar Datos.

Diagrama de secuencia: Interactuar y desplegar datos.

Diagrama de secuencia: Procesar Datos.

3.4- Diagrama de Clases Terminamos la etapa de anlisis con un diagrama de clases que muestra las abstracciones mnimas propuestas para la resolucin del problema, as como las relaciones que existen entre ellas. El diagrama es el siguiente.

4-Conclusin del anlisis. El anlisis es una etapa fundamental dentro de la realizacin de una aplicacin, esta etapa se puede resumir en una sola frase: Entender el problema. Cuando terminamos el anlisis tenemos ya una comprensin mayor del problema, sabemos cuales son las abstracciones claves, y empezamos a estudiar como se desenvuelve la aplicacin en el tiempo. Es aconsejable documentar esta etapa incluyendo en la documentacin los varios resultados como los que obtuvimos aqu. La etapa siguiente es la del diseo, cuyo objetivo principal es de construir un diagrama de clases mas detallado, refinado y orientado a la implementacin partiendo del diagrama de clases de anlisis, y es la que se ver a continuacin.

5.