3.

2 IDENTIFICACION DE CLASES SEGUN ESTEREOTIPOS

Para llevar a cabo la transicion del modelo de requisitos al modelo de analisis 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 dificiles de administrar, ya que sta puede abarcar todos los tipos de objetos. bordes 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 borde, pues a traves de ellso se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentacion comperensible para el actor. Las clases borde en otras palabras , describen la comunicacin bidireccional entre el sistema y los actores. Las clases borde son bastante fciles de identificar, donde se cuenta con al menos tres estrategias: 1. Se pueden identificar con base a los actores.

2. Se pueden identificar con base en las descripciones de las interfaces del sistema que acompaan al modelo de requisitos. 3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad especfica a los objetos bordes.

Estrategia correspondiente a los actores.

Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los dems. 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 durante la ejecucin de un caso de uso, mientras que la informacin a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.

Durante la identificacin de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso. Clases entidad: 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. 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. Control 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 vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solucin no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podra afectar varios objetos, dificultando su modificacin. Para evitar estos problemas, tal comportamiento se asigna a objetos control. Es difcil lograr un buen balance en la distribucin del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administracin de los dems tipos de objetos.

3.3 CLASES

Los objetos se representan y agrupan en clases que son ptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la seccin de un curso almacenan informacin similar para cada estudiante. Se podra decir que los estudiantes constituyen una clase. Los valores podran ser diferentes para cada estudiante, pero el tipo de informacin es el mismo. Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El trmino instanciar se usa cuando un objeto se crea a partir de una clase. Por ejemplo, un programa podra instanciar a un estudiante llamado Peter Wellington como un objeto de la clase denominada estudiante.

Lo que hace a la programacin orientada a objetos, y por consiguiente al anlisis y diseo orientado a objetos, diferente de la programacin clsica, es la tcnica de poner todos los atributos y mtodos de un objeto en una estructura independiente, la propia clase. sta es una situacin comn en el mundo fsico. Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Un suter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a secar extendido. Cada clase debe tener un nombre que la distinga de todas las dems. Los nombres declase normalmente son sustantivos o frases cortas y empiezan con una letra mayscula. En la figura 18.1 la clase se llama RentaAuto. En el UML, una clase se representa como un rectngulo. El rectngulo contiene otras dos caractersticas importantes: una lista de atributos y una serie de mtodos. Estos elementos describen una clase, la unidad de anlisis que es una parte principal de lo que llamamos anlisis y diseo orientado a objetos.

Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase RentaAuto posee los atributos tamao, color, marca y modelo. Todos los automviles poseen estos atributos, pero los atributos de cada automvil tendrn diferentes valores. Por ejemplo, un automvil puede ser azul, blanco o de algn otro color. Ms adelante demostraremos que es posible serrns especfico acerca del rango de valores para estas propiedades. Al especificar atributos, normalmente la primera letra es minscula.

Un mtodo es una accin que se puede solicitar a cualquier objeto de la clase. Losmtodos son los procesos que una clase sabe cmo realizar. Los mtodos tambin se llaman operaciones. La clase

RentaAuto podra tener los siguientes mtodos: inicioRenta( ), entregaAutof ) y servicio( ). Al especificar mtodos, normalmente la primera letra es minscula.

3.4 DIAGRAMAS DE SECUENCIAS

El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar interaccin entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Tpicamente uno examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si tienes modelada la descripcin de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria.

Figura 5:: Diagrama de Secuencia para un escenario

Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la case instanciada por el objeto en la recepcin final del mensaje.

3.5 DICCIONARIO DE CLASES SEGUN MODULOS Esta es la ultima estapa del modelo de analisis, en esta etapa se actualiza el diccionario de clases segun modulos, originalmente descrito en el dominio del problema, aunque no es necesario ordenarlos por relevancia, a cada clase y caso de uso se le pueden asignar modulos adicionales, que estos a su vez pueden tener otros modulos o paquetes principales de importancia, estos ayudan a analisar de una mejor manera.

Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qu datos representan a la factura y al cheque. Los dos son trminos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripcin de flujos de datos, almacenes de datos o procesos.