DESARROLLO DE PROYECTOS DE SOFTWARE

EQUIPO

Luis Augusto Martnez Cuevas

Cristian Aguilera Prez Geiely Crdova de Dios. Erick Gutirrez Ramrez.

Humberto Sarabia Gutirrez.

MODELO DE ANLISIS.

A) Arquitectura de Clase. B) Identificacin de las Clases Segn Estereotipos. C) Clases. D) Diagramas de Secuencias. E) Demostracin de Uso de una Herramienta CASE para el Anlisis.

Conceptos Bsicos.
El modelo de anlisis es la primera representacin tcnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se

hace mucho ms fcil de comprender dicha representacin, ya que es

posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

Conceptos Bsicos.
Es una representacin conceptual, correspondiente al problema y modelo de requisitos, en trmino de clase de objetos.

Una cualidad importante de la metodologa es la rastreabilidad de los

modelos, que permite evaluar el impacto de cambios durante el desarrollo. Dado que la mayora de los sistemas sern modificados a lo largo de su vida,

es necesario evaluar los efectos que estos cambios podran tener.

Objetivos Generales.
El modelo de anlisis debe cumplir tres objetivos generales:
1.

Describir lo que requiere el cliente. Establecer una base para la creacin de un diseo de software. Definir un conjunto de requisitos que puedan validarse una vez construido el software.

2.

3.

ARQUITECTURA DE CLASE.
El objetivo principal del modelo de anlisis es generar una arquitectura de objetos que sirva como base para el diseo del sistema. Dependiendo del tipo de aplicacin existen diferentes arquitecturas que se pueden utilizar. Las arquitecturas se distinguen segn la organizacin de los objetos de a cuerdo a su funcionalidad. Esto es tambin conocido como dimensin de la arquitectura. En general, una arquitectura puede incluir cualquier nmero de dimensiones, algo que depende del tipo de aplicacin que se desea desarrollar.

EJEMPLO.
Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de anlisis basado en el modelo de casos de uso.

IDENTIFICACIN DE LAS 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. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de control. En general, los cambios mas comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo a los objetos borde. Los cambios a la funcionalidad son ms difciles de administrar, ya que sta puede abarcar todos los tipos de objetos.

<<Estereotipo>> Nombre de la capa.

EJEMPLO.
Diagrama de clase con estereotipo.

IDENTIFICACIN DE LAS CLASES SEGN ESTEREOTIPOS.

La funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos: Entidad. Interface. Control.

1. 2. 3.

ENTIDAD.
Se utilizan objetos entidad para modelar la informacin que el sistema debe manejar a corto y largo plazo. La informacin a corto plazo existe por lo general durante la ejecucin del caso de uso, mientras que la informacin a largo plazo sobrevive a los casos de uso, por lo cual es necesario guardar esta informacin en alguna base de datos.

Los objetos entidad se identifican en los casos de uso, donde la mayora se identifican del modelo del dominio del problema en el modelo de requisitos.
Es muy comn que se identifiquen muchos objetos entidad, aunque se debe limitar estos objetos a los realmente necesarios para la aplicacin, siendo esto lo ms difcil del proceso de identificacin.

ENTIDAD.
Las operaciones asignadas a los objetos entidad pueden ser ms o menos complejas. En el caso menos complejo un objeto entidad consta slo de operaciones de acceso a los valores de los atributos. Sea cual sea la complejidad de estas operaciones, el objetivo es que stas slo dependan y afecten informacin local.

La siguiente es una lista de las operaciones tpicas que deben ser ofrecidas por un objeto entidad:

Guardar y traer informacin Comportamiento que debe modificarse si el objeto entidad cambia

Crear y remover el objeto entidad

SISTEMA DE RESERVACIN DE VUELO.

Validar Usuario: Este casi de uso requiere validar informacin exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad RegistroUsuario, utiliza tambin por el caso de uso RegistroUsuario. Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad. Registrar Usuario: Este caso de uso requiere guardar informacin exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.

Registrar Tarjeta: Este caso de uso requiere guardar informacin exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.

CLASES ENTIDAD.
Consultar Informacin: Este casi de uso requiere de toda la informacin relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones. Hacer reservacin: Este caso de uso requiere de la informacin relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros. Pagar Reservacin: Este caso de uso requiere de la informacin relacionada con reservaciones. Dado que es una extensin al caso de uso Hacer Reservacin, no es necesario volver a repetir todas las clases entidad, sino ms bien especificar cualquier clase adicional.

Caso de Uso Registrar Usuario Validar usuario Registrar Tarjeta Consultar Informacin

Clases Entidad RegistroUsuario RegistroUsuario RegistroTarjeta Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario

Hacer Reservacin
Pagar Reservacin

Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero, Reservacin
Asiento, Avin, Tarifa, Aeropuerto, Aerolnea, Vuelo, Horario, ViajeroFrecuente, Pasajero, Reservacin, RegistroTarjeta

EJEMPLO.
Relacin entre casos de uso y clases entidad para el sistema de reservaciones de vuelo.

BORDE/INTERFACE.
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema se ubica en los objetos de interfaces. Es a travs de estos objetos que se comunican los actores con el sistema. La tarea de un clase interface es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema a una presentacin comprensible por el actor.

BORDE/INTERFACE.
Las clases interface, en otras palabras, describen comunicacin bidireccional entre el sistema y los actores. Las clases interface son bastante fciles de identificar, donde se cuenta con al menos tres estrategias:
1. 2. 3.

Se pueden identificar en base a los actores. Se pueden identificar en base a las descripciones de las interfaces del sistema que acompaan al modelo de requisitos. Se pueden identificar en base a las descripciones de los casos de uso y extraer la funcionalidad que es especfica a las interfaces.

BORDE/INTERFACE.
Una vez identificado los objetos interfaces, es ms fcil modificar posteriormente las interfaces de un sistema. Al tener todo lo relacionado a una interface en un objeto, cada cambio a la interface ser local a ese objeto. Como los cambios a las interfaces son muy comunes, es vital que estos sean extensibles. Existen dos tipos diferentes de interfaces a modelar, interfaces a otros sistemas e interfaces a los usuarios humanos.

EJEMPLO.
Clases interface para el sistema de reservaciones de vuelo identificados directamente de los actores.

CONTROL.
En algunas situaciones todo un caso de uso pudiera implementarse exclusivamente mediante estos dos tipos de objetos. De tal manera no se necesitara ningn objeto control para el respectivo caso de uso. Sin embargo, en la mayora de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos, ya que realmente no pertenece de manera natural a ninguno de ellos. Para evitar estos problemas tal comportamiento se asigna en objetos control. Sin embargo, es difcil lograr un buen balance en la asignacin del comportamiento entre los objetos entidad, interface y control.

CONTROL.
Los objetos de control tpicamente actan como pegamento entre los otros tipos de objetos y proveen la comunicacin entre los dems tipos de objetos. Los objetos de control normalmente proveen la administracin de los dems tipos de objetos.

Caso de Uso Registrar Usuario Validar usuario Registrar Tarjeta Consultar Informacin

Clases Control ManejadorPrincipal, ManejadorServicios, ManejadorRegistroUsuario ManejadorPrincipal, ManejadorRegistroUsuario ManejadorRegistroUsuario, ManejadorRegistroTarjeta ManejadorPrincipal, ManejadorServicios, ManejadorConsultas, ManejadorConsultaHorarios, ManejadorConsultaTarifas, ManejadorConsultaEstado ManejadorPrincipal, ManejadorServicios, ManejadorReservas ManejadorReservas, ManejadorPagos, ManejadorRegistroTarjeta

Hacer Reservacin Pagar Reservacin

EJEMPLO.
Relacin entre casos de uso y clases control para el sistema de reservaciones de vuelo.

DIAGRAMAS DE SECUENCIA.
Dada la complejidad y la importancia de los casos de uso, antes de proseguir a describirlos de manera textual en trmino de las clases que hemos identificado, es bueno probar algunas secuencias de sus flujos para revisar que tan bien nuestra arquitectura se adapta a ellos. 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.

DIAGRAMAS DE SECUENCIA.
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 acciones ms especficas como mover pieza. Para describir la comunicacin entre objetos se utilizan estmulos o eventos, los cuales se envan de un objeto a otro para activar una ejecucin en ese objeto, que adems puede enviar nuevos estmulos a otros objetos.

EJEMPLO.
Diagrama de secuencia con eventos.

HTTP://WWW.SITES.UPIICSA.IPN.MX

BIBLIOGRAFA

INGENIERA DE SOFTWARE ORIENTADA A OBJETOS CON UML, JAVA E INTERNET. - PGINA 253