Materia:

Fundamentos de Ingeniera de Software.

Profesor:
Carlos Hernndez Salas.

Unidad 3:
Modelo de anlisis.

Nombre:
Daniela Lpez Paz. Irene Jaqueline Lpez Glvez. Clara Isabel Hernndez Ramrez. Keyla Jael Garca Ramos.

5to. semestre. Ing. Sistemas computacionales.

Tapachula Chiapas de Crdova y Ordoez.

Unidad 3.- MODELO DEL ANALISIS

El modelo de anlisis, realmente un conjunto de modelos, es la primera representacin tcnica de un sistema. Anlisis estructurado, es un mtodo de modelado clsico, es una actividad de construccin de modelos. Mediante una notacin que satisfaga los principios de anlisis. El objetivo del modelo de anlisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos. Durante esta etapa no se considera el ambiente de implementacin, lo cual incluye al lenguaje de programacin, manejador de base de datos, distribucin o configuracin de hardware, etc.

El modelo de anlisis genera una representacin conceptual del sistema, consistiendo de clases de objetos. Cada una de las clases de objetos contribuye de manera especial para lograr la robustez de la arquitectura. ELEMENTOS DEL MODELO DE ANALISIS El modelo de anlisis debe lograr 3 objetivos primarios: 1.- Describir lo que requiere el cliente. 2.- Establecer una base para la creacin de un diseo de software. 3.- Definir un conjunto de requisitos. Diagrama de entidad relacin: representa las relaciones entre los objetos de datos. El DER es la notacin que se usa para realizar la actividad del modelo de datos. Diagrama de flujo de datos: sirve para dos propsitos (1) Proporcionar una indicacin de como se transforman los datos a medida que se avanza en el sistema. (2) Representar las funciones (y subsunciones) que transforman el flujo de datos. Diagrama de transicin de estados (DTE): Indica cmo se comporta el sistema como consecuencia de sucesos externos. 3.1.- ARQUITECTURA DE CLASE El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseo posterior del sistema. Existen diversas arquitecturas que se pueden utilizar, siendo de nuestro inters aquellas arquitecturas especialmente diseadas para el manejo de los sistemas de

informacin, las cuales involucran ricas bordes de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura. En trmino de las propias arquitecturas, stas se distinguen segn la organizacin de la funcionalidad que ofrecerlos objetos dentro de ellas o la dimensin de los objetos. Esta dimensin corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de bordes y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una slo dimensin.

La vista o presentacin de la informacin corresponde a las bordes que se le presentan al usuario para el manejo de la informacin, donde por lo general pueden existir mltiples vistas sobre un mismo modelo. Tpicamente la informacin representa el dominio del problema y es almacenada en una base de datos. Por otro lado el control corresponde a la manipulacin de la informacin a travs de sus diversas presentaciones. Y aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la informacin es independiente de la propia informacin y de cmo esta se controla. Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el ms propenso a ser modificado, seguido de la vista y finalmente el modelo. 3.2 Identificacin de Clases segn Estereotipos Para llevar a cabo la transicin del modelo de requisitos al modelo de anlisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos como se discuti anteriormente. Para lograr esto se debe identificar primero las clases borde, luego las entidad y finalmente las de control. .

3.3 Clases segn Casos de Uso En esta seccin mostramos un diagrama de clases para cada caso de uso de acuerdo a las clases identificadas. En estos diagramas incluiremos de manera preliminar asociaciones y multiplicidad. Para simplificar este proceso de asignacin de asociaciones y para ser consistentes entre diagramas, asignaremos a la clase control de cada caso de uso como el centro de las comunicaciones para todas las clases borde y entidad pertenecientes al mismo caso de uso. Validar Usuario El caso de uso Validar Usuario involucra una clase control Manejador Registro Usuario que es encargada de controlar la informacin de Registro Usuario y las clases borde Interface Usuario e Interface Base Datos Registro. Agregamos tambin la clase Pantalla Principal por recibir la informacin de registro a ser validada y al Manejador Principal por ser el controlador de la pantalla anterior. En la figura se muestran las clases identificadas en este caso de uso.

Ofrecer Servicios El caso de uso Ofrecer Servicios involucra una clase control Manejador Servicio que es encargada de controlar la Pantalla Servicio. Agregamos tambin la clase borde Interface Usuario. En la Figura se muestran las clases identificadas en este caso de uso.

Registrar Usuario El caso de uso Registrar Usuario involucra una clase control Manejador Registro Usuario que es encargada de controlar la informacin de Registro Usuario y las clases borde correspondiente a las pantallas Pantalla Crear Reg Usuario y Pantalla Obtener Registro Usuario, adems de las clases borde Interface Usuario e Interface Base Datos Registro. En la Figura se muestran las clases identificadas en este caso de uso.

Registrar Tarjeta El caso de uso Registrar Tarjeta involucra una clase control Manejador Registro Tarjeta que es encargada de controlar la informacin de Registro Tarjeta y las clases borde correspondiente a las pantallas Pantalla Crear Reg Tarjeta y Pantalla Obtener Registro Tarjeta adems de las clases borde Interface Usuario e Interface Base Datos Registro. En la Figura se muestran las clases identificadas en este caso de uso.

Consultar Informacin El caso de uso Consultar Informacin involucra una clase control Manejador Consultas que es encargada de controlar todos los diferentes tipos de consultas junto con la clase borde correspondiente a la pantalla Pantalla Consultas, adems de las clases borde Interface Usuario e Interface Base Datos Registro. Dado que este caso de uso tiene tres subflujos importantes, en lugar de describirlos en un slo diagrama, lo haremos en tres diagramas separados como veremos ms adelante. En la Figura se muestran las clases principales identificadas en este caso de uso.

Consultar Horarios El subflujo Consultar Horarios del caso de uso Consultar Informacin involucra a todas las clases del diagrama de la Figura anterior, las cuales no volvemos a incluir en el diagrama. Se incluyen en el nuevo diagrama las clases borde correspondiente a las pantallas Pantalla Consulta Horarios y Pantalla Resultado Horarios adems de las clases entidad Vuelo, Aeropuerto, Horario y Aerolnea junto con la clase control Manejador Consulta Horarios. El resto de las clases entidad del dominio del problema no son necesarias para este subflujo. En la Figura se muestran las clases identificadas en este subflujo.

3.4 Diagrama secuencial En un diagrama de secuencia se indicarn los mdulos o clases que forman parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada. Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la aplicacin en cuestin. As, en el caso de una aplicacin para jugar al ajedrez, se podran realizar diagramas de secuencia para jugar una partida o bien para ms especficas como mover pieza. El detalle que se muestre en el diagrama de secuencia debe estar en consonancia con lo que se intenta mostrar o bien con la fase de desarrollo en la que est el proyecto, no es lo mismo un diagrama de secuencia que muestre la accin de mover pieza a otro que sea mover caballo, o bien no es lo mismo un diagrama de secuencia mover pieza que verifique ciertos parmetros antes de mover como la viabilidad del

movimiento con respecto a una estrategia marcada a una diagrama que no muestre este nivel de detalle por estar en una fase inicial de diseo del sistema. Si estamos en una fase avanzada, estamos diseando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases o mdulos que participan, entonces debemos posiblemente ir al nivel de clase real de codificacin y mtodo, con parmetros y todo, de forma que los programadores tengan claro que mtodos van a implementar, qu deben llamar de la clase o mdulo del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que slo salga el actor "jugador" y una nica clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qu datos y en qu orden los tiene que meter en el programa y vea qu salidas y resultados le va a dar el programa. El siguiente puede ser un diagrama de secuencia del ejemplo del ajedrez a un nivel de diseo muy preliminar

. Aqu ya se ha decidido que se van a desarrollar tres libreras/paquetes/mdulos, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos vlidos y dems) y otra para el algoritmo de juego del ordenador. En el ejemplo se ha utilizado una clase representando cada uno de los paquetes y se ha representado el caso de uso "mover pieza". En el diagrama de secuencia no se ponen situaciones errneas (movimientos invlidos, jaques, etc.) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difcil de leer. El diagrama puede acompaarse con un texto en el que se detallen todas estas situaciones errneas y particularidades. 3.5 Diccionario de Clases segn mdulos Como ltima etapa del modelo de anlisis, se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir todas las clases identificadas durante el modelo de anlisis. Aunque no es obligatorio, aprovechamos para separar estas clases en diferentes mdulos para lograr una mejor organizacin y correspondencia entre clases y casos de uso. Aquellas clases que participan en varios casos de uso se pueden asignar a mdulos adicionales, como veremos a continuacin para el sistema de reservaciones de vuelo. Comenzamos con cuatro mdulos o paquetes principales: Interface Usuario, Principal, Registro y Servicios.

Interface Usuario El modulo de interfaceUsuario esta compuesto por una clase utilizada para el manejo general de las interface de usuario. El mdulo Interface Usuario est compuesto por una sla clase: Interface Usuario Clase Borde. Toda la interaccin con el usuario se hace por medio de la borde de usuario. Principal El modulo principal esta compuesto por clases comunes a la funcionalidad general del sistema. El mdulo Principal est compuesto por dos clases: 1.- Pantalla Principal - Clase Borde. Pantalla principal (P-1). 2.- Manejador Principal - Clase Control. El manejador principal es el encargado de desplegar la pantalla principal de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados. Registro El mdulo Registro se divide en los siguientes mdulos: Usuario, tarjeta, interfaceBD, donde corresponde a la base de datos. Usuario : El mdulo Usuario est compuesto por las clases. Pantalla Crear Reg. Usuario: Clase Borde. Pantalla de solicitud de registro de usuario. Pantalla Obtener Reg. Usuario: Clase Borde. Pantalla de devolucin con informacin de registro de usuario . Registro usuario: Clase entidad. Para utilizar el sistema de reservaciones, el usuario debe de estar registrado con el sistema. Manejador Registro Usuario: clase control. El manejador de usuario se encarga de todo lo relacionado con el registro del usuario para poder utilizar el sistema. Tarjeta Modulo de tarjetas esta compuesto por clases. Pantalla Crear Reg Tarjeta. Clase Borde. Pantalla de solicitud registro de tarjeta. Pantalla Obtener Reg. Tarjeta - Clase Borde. Pantalla de devolucin con informacin de registro de tarjeta. Registro Tarjeta- Clase Entidad. Para poder hacer un pago con una tarjeta de crdito, se debe tener un registro de tarjeta. El registro contiene informacin acerca de la tarjeta incluyendo nombre, nmero, expedidor y vencimiento. LA tarjeta est ligada a un registro de usuario. Manejador Registro Tarjeta- Clase Control. El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones InterfaceBD.

Este modulo interfaceBD, corresponde a la interface para la base de datos, esta compuesto pos la clase encargada de interactuar con la base de datos. interfaceBaseDatosRegistro. Clase Borde. La informacin de cada usuario se almacena en la base de datos de registro, la cual se accesa mediante la interface de la base de datos de registro. Esto permite validar a los distintos usuarios, adems de guardar informacin sobre la tarjeta de crditos para pagos en lnea. Servicios El modulo servicios se divide en: Dominio, interfaceBD, consulta, reserva y pagos.

interfaceBD. El modulo interfaceBD, parte del modulo de servicios, incluye una clase para el acceso a la base de datos. InterfaceBaseDatosReserva- Clase Borde. La informacin del sistema de reservaciones de vuelo se almacena en la base de datos de reservacin, la cual se accesa mediante la interface de la base de datos de reserva. Esto permite generar consultas, reserva y pagos de reserva de manera dinmica. Consulta. PantallaConsulta- Clase Borde. Pantalla de consultas. ManejadorConsulta- Clase Control. El manejador de consulta se encarga de enviar las peticiones de consulta particular a los manejadores de consulta especificados. Horarios Pantalla Consulta Horarios - Clase Borde. Pantalla de presentacin de consulta de horarios. Pantalla Resultado Horarios - Clase Borde. Pantalla de devolucin de consulta de horarios. Manejador Consulta Horarios - Clase Control. El manejador de consulta de horarios se encarga de controlar las peticiones de consulta de horarios. Tarifas Pantalla Consulta Tarifas - Clase Borde. Pantalla de presentacin de consulta de tarifas Pantalla Resultado Tarifas - Clase Borde. Pantalla de devolucin de consulta de tarifas. Manejador Consulta Tarifas - Clase Control. El manejador de consulta de tarifas se encarga de controlar las peticiones de consulta de tarifas. Estado Este modulo esta compuesto por clases. Pantalla Consulta Estado - Clase Borde. Pantalla de presentacin de consulta de estado. Pantalla Resultado Estado - Clase Borde. Pantalla de devolucin de consulta de estado.

 Manejador Consulta Estado - Clase Control. El manejador de consulta de estado se encarga de controlar las peticiones de consulta de estado. 3.6 Herramientas CASE para el anlisis Las herramientas de anlisis y diseo capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representacin de los datos, de la funcin y del comportamiento (en el nivel de anlisis), as como caracterizaciones del diseo de datos, arquitectura, procedimientos e interfaz. Al efectuar una comprobacin de la consistencia y validez del modelo, las herramientas de anlisis y diseo proporcionan al ingeniero del software un cierto grado de visin en lo tocante a la representacin del anlisis, y le ayudan a eliminar errores antes de que se propaguen al diseo, o lo que es peor, a la propia implementacin.