Descripcin: Es el principal workflow del proceso unificado.

Se le da ste nombre a todos los diagramas utilizados para capturar toda la funcionalidad de el futuro sistema El modelo de requisitos tiene como objetivo delimitar el sistema y mostrar los servicios que el usuario requiere que cumpla el sistema

Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o el usuario del sistema, y por lo tanto proyecta lo que el cliente desea segn la percepcin del desarrollador. Es importante que el usuario lo entienda.

Es la base de todos los dems modelos. Requiere de la comprensin total del problema y sus implicaciones. Sirve de base para el desarrollo de las instrucciones operacionales y los manuales. Debe de separar los requisitos verdaderos de las decisiones del diseo e implementacin. Debe dejar claro aspectos obligatorios y opcionales.

Componentes bsicos Modelo de comportamiento: Especfica la funcionalidad que ofrece el sistema desde el punto de vista del usuario: Diagrama de casos de uso, diagramas de secuencias. Modelo de presentacin o modelo de interfaces: Especifica como interacta el sistema con actores externos al ejecutar los casos de uso. Modelo de informacin o del dominio del problema: Especifica aspectos estructurales en trminos de objetos: Diagrama de clases y diccionarios de clases.

Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver ms adelante. Anlisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de anlisis, que es estable con respecto a cambios, siendo un modelo lgico independiente del ambiente de implementacin. Diseo: La funcionalidad de los casos de uso ya estructurada por el anlisis es realizada por el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms. Implementacin: Los casos de uso son implementados mediante el cdigo fuente en el modelo de implementacin. Pruebas: Los casos de uso son probados a travs de las pruebas de componentes y pruebas de integracin. Documentacin: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administracin, etc.

Descripcin del problema: El Sistema de Reservaciones de Vuelos es un sistema que permite al usuario hacer consultas y reservas de vuelos, adems de poder comprar los boletos areos de forma remota, sin la necesidad de recurrir a un agente de viajes humano. Se desea que el sistema de reservaciones sea accesible a travs del Internet (World Wide Web).

El sistema presenta en su pantalla principal un mensaje de bienvenida describiendo los servicios ofrecidos junto con la opcin para registrarse por primera vez, o si ya esta registrado, poder utilizar el sistema de reservaciones de vuelos. Este acceso se da por medio de la insercin de un login previamente especificado y un password previamente escogido y que debe validarse.

Una vez registrado el usuario, y despus de haberse validado el registro y contrasea del usuario, se pueden seleccionar las siguientes actividades:
Consulta de vuelos Reserva de vuelos Pago de boletos

La consulta de vuelos se puede hacer de tres maneras diferentes:

Horarios de Vuelos Tarifas de Vuelos Estado de Vuelo

En la consulta se puede incluir preferencias en las bsquedas, como fecha y horario deseado, categora de asiento, aerolnea deseada y si se desea slo vuelos directos.
anterior

La reservacin de vuelo permite al cliente hacer una reserva para un vuelo particular, especificando la fecha y horario, bajo una tarifa establecida. Es posible reservar un itinerario compuesto de mltiples vuelos, para uno o ms pasajeros, adems de poder reservar asientos.
anterior

El pago permite al cliente, dada una reserva de vuelo previa y una tarjeta de crdito vlida, adquirir los boletos areos.
anterior

La consulta segn horario muestra los horarios de las diferentes aerolneas dando servicio entre dos ciudades.
anterior

La consulta segn tarifas muestra los diferentes vuelos entre dos ciudades dando prioridad a su costo.
anterior

El estado de vuelo se utiliza principalmente para consultar el estado de algn vuelo, incluyendo informacin de disponibilidad de asientos y, en el caso de un vuelo para el mismo da, si est en hora.
anterior

Los boletos sern posteriormente enviados al cliente, o estarn listos para ser recogidos en el mostrador del aeropuerto previo a la salida del primer vuelo. Es necesario estar previamente registrados con un nmero de tarjeta de crdito vlida para poder hacer compras de boletos, o de lo contrario proveerla en el momento de la compra. Adems de los servicios de vuelo, el usuario podr en cualquier momento accesar, modificar o cancelar su propio registro, todo esto despus de haber sido el usuario validado en el sistema.

III. El Paradigma OO: Requisitos

Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado

III. El Paradigma OO: Requisitos

Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitos Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo El usuario debera poder entenderlos para realizar su validacin

III. El Paradigma OO: Requisitos

Ejemplo:

Actor A

Caso de Uso A

Caso de Uso B

Actor B

III. El Paradigma OO: Requisitos

Actores: Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema Material externo: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin y deben ser utilizados Otros sistemas: sistemas con los que el sistema interacta La misma persona fsica puede interpretar varios papeles como actores distintos
El nombre del actor describe el papel desempeado

III. El Paradigma OO: Requisitos

Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo unificado estar dirigido por los casos de uso

III. El Paradigma OO: Requisitos

UML define cuatro tipos de relacin en los Diagramas de Casos de Uso:

Comunicacin

Actor

Caso de Uso

III. El Paradigma OO: Requisitos

Inclusin : una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino
<<include>>

Caso de Uso Origen

Caso de Uso Destino

<<include>> reemplaz al denominado <<uses>>

La inclusin es una seccin de un caso de uso que es parte obligatoria del caso de uso bsico. Para identificarlos en un caso de uso existente, las inclusiones se encuentran de la extraccin de secuencias comunes ya existente entre varios casos de usos.

III. El Paradigma OO: Requisitos

Ejemplo

<<include>>:

Reintegro Cuenta Corriente

<<include>>

Cliente

Verificar Operacin <<include>>

Reintegro Cuenta de Crdito

III. El Paradigma OO: Requisitos

Extensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

<<extend>>

Caso de Uso Origen

Caso de Uso Destino

Se establece para extender la funcionalidad de un caso de uso dado. Se utiliza para modelar secuencias de eventos opcionales de casos de uso, que al manejarse de manera independiente pueden agregarse o eliminarse del sistema de manera modular

III. El Paradigma OO: Requisitos

Ejemplo

<<extend>>:

Cliente

Solicitar Prstamo

[Tarjeta Caducada] <<extend>>

Solicitar Nueva Tarjeta

III. El Paradigma OO: Requisitos

Ejemplo <<include>> y <<extend>>:

<<include>>

Identificacin

Cliente

Transferencia

<<extend>>

Transferencia en Internet

III. El Paradigma OO: Requisitos

Otro ejemplo <<include>> y <<extend>>:

Supply Customer Data

Order Product Arrange Payment

<<include>>

<<include>>

<<include>>

the salesperson asks for the catalog

1 Salesperson

* Place Order

<<extend>>

Request Catalog

III. El Paradigma OO: Requisitos

Herencia : el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla

Caso de Uso Hijo

Caso de Uso Padre

Apoya la reutilizacin de los casos de uso. Sirve para describir las partes similares una sola vez, en lugar de repetirlas para todos los casos de uso con comportamiento comn

III. El Paradigma OO: Requisitos

Un caso de uso debe ser simple, inteligible, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave: cules son las tareas del actor? qu informacin crea, guarda, modifica, destruye o lee el actor? debe el actor notificar al sistema los cambios externos? debe el sistema informar al actor de los cambios internos?

III. El Paradigma OO: Requisitos

La descripcin del Caso de Uso comprende:

el inicio: cundo y qu actor lo produce? el fin: cundo se produce y qu valor devuelve? la interaccin actor-caso de uso: qu mensajes intercambian ambos? objetivo del caso de uso: qu lleva a cabo o intenta? cronologa y origen de las interacciones repeticiones de comportamiento: qu operaciones son iteradas? situaciones opcionales: qu ejecuciones alternativas se presentan en el caso de uso?

Prctica 7

III. El Paradigma OO: Requisitos

Identificador Nombre Descripcin CU-<id-requisito> <nombre del requisito funcional> El sistema deber comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activacin> , abstracto durante la realizacin de los casos de uso <lista de casos de uso>} <precondicin del caso de uso> Paso 1
Accin {El <actor> , El sistema} <accin realizada por el actor o sistema>, se realiza el caso de uso < caso de uso CU-x> Si <condicin>, {el <actor> , el sistema} <accin realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x>

Precondicin Secuencia Normal

2 Postcondicin Excepciones

<postcondicin del caso de uso> Paso 1

Accin Si <condicin de excepcin>,{el <actor> , el sistema} }<accin realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x>, a continuacin este caso de uso {continua, aborta} Cota de tiempo n segundos

Rendimiento Paso 1 Frecuencia esperada Importancia Urgencia Comentarios

<n de veces> veces / <unidad de tiempo> {sin importancia, importante, vital} {puede esperar, hay presin, inmediatamente} <comentarios adicionales>

III. El Paradigma OO: Requisitos

En mtodos OO que carecen de una tcnica de captura de requisitos se comienza inmediatamente con la construccin del modelo de anlisis/diseo Los Casos de Uso son una idea maravillosa que ha sido

generalmente complicada. El verdadero truco para los Casos de Uso es mantenerlos simples. Recordad, maana van a cambiar. Rober C. Martin

Los requisitos NO funcionales tambin son importantes. Desempeo, cumplimiento de estndares o leyes, atributos de calidad (confiabilidad, disponibilidad, seguridad, mantenibilidad, portabilidad), etc.

II. Breve Tour por UML

Ejemplo:

Retirar dinero

Cliente

Consultar Extracto

Realizar transferencia
Prctica 2

Describe la presentacin de informacin entre los actores y el sistema. Se especifica en detalle cmo se vern las interfaces del usuario al ejecutar cada uno de los casos de uso Viene a ser un prototipo funcional de requisitos que muestra las interfaces del usuario. Esto ayuda al usuario a visualizar los casos de uso segn se mostrarn en el sistema a construirse.

Ayuda a eliminar posibilidades de malos entendidos. Las interfaces reflejarn la visin lgica del sistema. Debe de haber consistencia entre la imagen conceptual del usuario y el comportamiento real del sistema. Se resalta las necesidades de informacin para cada caso de uso

Principal---Registrar usuario ServiciosConsultar Informacin , Hacer reservacion, Obtener Registro Crear Registro de Tarjeta Consultar Informacin Horarios, Tarifas, Estado. Hacer ReservacionPantalla de pago, Pantalla de reembolso

El modelo del dominio del problema. Se conforma con la finalidad de que todos los usuarios involucrados con el mismo manejen una terminologa comn, puede utilizarse el diagrama de clases y el diccionario de clases.

En UML el diagrama de clases consiste de los objetos del dominio del problema, o sea objetos que tienen una correspondencia directa en el rea de la aplicacin
Es suficiente describir el dominio del problema en trmino de objetos o clases, es posible refinar ms an mediante la inclusin de asociaciones, atributos, herencia y operaciones aunque esta informacin se incluya posteriormente en el diseo

La identificacin de clases del dominio del problema se obtiene principalmente de algn documento textual que describa el sistema.
Se comienza este proceso mediante la identificacin de las clases candidatas, explcitas o implcitas, a las que se refiera la descripcin del problema.

Elaboracin de un diagrama de Clases

o

Identificacin de Clases

Se extraen todos los sustantivos de la descripcin del problema o de algn otro documento similar, de acuerdo a las siguientes consideraciones: Los sustantivos en la descripcin del problema son los posibles candidatos a clases de objetos. Se debe identificar entidades fsicas al igual que entidades conceptuales. No se debe tratar de diferenciar entre clases y atributos durante sta etapa.

Dado que no todas las clases se describen de manera explcita, siendo algunas implcitas en la aplicacin, ser necesario aadir clases que pueden ser identificadas por nuestro conocimiento del rea.
Se debe revisar los pronombres en la descripcin del problema para asegurar que no se haya perdido ningn sustantivo descrito de forma implcita. Para facilitar la identificacin de clases, se subrayan todos los sustantivos de la descripcin del problema

SELECCIN DE CLASES. Criterios a tomar en cuenta para identificar las clases:

Todas las clases deben tener sentido en el rea de la aplicacin, la relevancia al problema debe ser el nico criterio para la seleccin. Como regla general, se debe escoger los nombres para las clases con cuidado, que no sean ambiguos y que mejor se apliquen al problema. Este es uno de los procesos ms difciles. Los nombres deben ser establecidos con un formato consistente (e.g. nombres en singular). No hay que preocuparse durante esta etapa sobre asociacin, agregacin, o herencia. Primero hay que tener las clases especficas correctas para no suprimir detalles en el intento de ajustarse a estructuras preconcebidas. Ante la duda, se deben conservar las clases, ya que posteriormente siempre habr oportunidad para eliminarlas. Se deben eliminar clases redundantes, si estas expresan la misma informacin. La clase ms descriptiva debe ser guardada.

SELECCIN DE CLASES. Criterios a tomar en cuenta para identificar las clases:

Se deben eliminar clases irrelevantes, que tienen poco o nada que ver con el problema. Esto requiere juicio porque en un contexto una clase puede ser importante mientras que en otro contexto la clase podra no serlo. Se deben clarificar las clases imprecisas. Algunas clases pueden tener bordes mal definidos o demasiado generales. Se deben eliminar las clases que debieran ser atributos ms que clases, cuando los nombres corresponden a propiedades ms que entidades independientes. Se deben eliminar las clases que debieran ser roles ms que clases, cuando los nombres corresponden al papel que juegan las clases ms que entidades independientes. Se debe eliminar clases que correspondan aspectos de interfaces de usuario y no de la aplicacin. Se deben eliminar las clases que debieran ser operaciones ms que clases, si las entidades representan operaciones que son aplicadas a los objetos y no entidades manipuladas por si mismas.

 Se deben eliminar las clases que corresponden a

construcciones de implementacin si estn alejadas del mundo real, por lo cual deben ser eliminadas del anlisis. No se necesita una clase para representar una entidad fsica. Por ejemplo: subrutinas, listas, y arreglos, son clases tpicas de implementacin; Internet y World Wide Web; son el medio de implementacin del sistema

Por un anlisis previo vemos que:

Clases redundantes: Cliente y Usuario. Esta decisin puede ir para ambos lados de igual manera. En el caso del Sistema de Reservaciones, consideramos que Usuario es ms descriptivo por ser la persona que utilice el sistema y se guarda.
Clases irrelevantes: Mostrador del Aeropuerto, Agente de Viajes Humano y Boleto Areo. Si el sistema generara o se refiriera a un boleto areo, esta clase se mantendra. Clases imprecisas: Sistema, Servicios, Actividad, Preferencia, Bsqueda, Informacin, Estado, Opcin, Acceso, Itinerario, son clases imprecisas. Durante la introduccin de herencia puede que sea necesario una clase para compartir aspectos comunes a ambas clases.

Nombres de clases: Aeropuerto en lugar de Ciudad Clases que son atributos: Nmero de Tarjeta de Crdito es un atributo de Tarjeta de Crdito, Categora de Asiento (Asiento), Informacin de Vuelo (Vuelo), y Horario de Vuelo (Vuelo) Clases que son operaciones: Consulta, Pago, Reserva. Clases de interfaces de usuario: Mensaje de Bienvenida, Pantalla Principal. Clases del sistema completo: Sistema deReservaciones. Clases actores: Cliente.

Ntese que se agregaron dos nuevas clases, Avin y ViajeroFrecuente, que no aparecan en la descripcin del problema. Esto se hizo para lograr un dominio ms completo.

Despus de haber identificado y seleccionado las clases, se debe construir el diagrama de clases para el dominio del problema. Este diagrama se muestra en la Figura siguiente y puede ayudar a identificar clases adicionales, servir de base para encontrar las atributos y asociaciones entre ellas.

En lugar de tomar como punto de partida la descripcin del problema o los documentos de casos de uso, simplemente identificamos nuestras propias frases correspondientes al dominio del problema del sistema de reservaciones, como se muestran en la siguiente diapositiva Este proceso de identificacin es sencillo cuando el problema es muy limitado y el dominio es fcil de analizar. De lo contrario se requiere un proceso de identificacin mucho ms extenso como veremos en la etapa de diseo

El diccionario de clases o diccionario de datos describe textualmente las clases identificadas durante el modelo del dominio del problema. Este diccionario sirve como un glosario de trminos y se muestra a continuacin.

Vuelo - Se denomina por medio de un nmero. El vuelo tiene como origen un aeropuerto en una ciudad y tiene como destino un aeropuerto de otra ciudad. Un vuelo puede tener mltiples escalas y mltiples vuelos se relacionan por medio de conexiones. El vuelo pertenece a una aerolnea y puede operar varios das a la semana teniendo un horario de salida y otro de llegada. Reservacin - Para poder tomar un vuelo es necesario contar con una reservacin previa, la cual debe pagarse antes de una fecha lmite, que puede ser el propio da del vuelo. Una reservacin puede hacerse para mltiples vuelos y mltiples pasajeros. La reservacin cuenta con una clave identificando un rcord de reservacin particular.

RegistroUsuario - Para poder utilizar el sistema de reservaciones, el usuario debe estar registrado con el sistema. El registro contiene informacin acerca del usuario que incluye nombre, direccin, colonia, ciudad, pas, cdigo postal, telfono de casa, telfono de oficina, fax, email, login y password.
Horario - El horario de un vuelo se determina por su hora de salida y hora de llegada durante los das que opera. Aerolnea - La aerolnea provee servicio de mltiples vuelos entre diferentes ciudades bajo diferentes horarios. La aerolnea se identifica por un nombre.

Aeropuerto - El aeropuerto sirve como origen, destino y escalas de un vuelo. El aeropuerto se encuentra en una ciudad de un pas determinado.
Tarifa - Los diferentes vuelos tienen mltiples tarifas para compra de boleto, variando segn la clase de boleto, si son de ida o de ida y vuelta, y dependiendo de las diversas restricciones y ofertas existentes. Asiento - Una reservacin de vuelo puede incluir la asignacin de asiento, especificada mediante una fila y un nmero. El nmero de asientos disponibles en un vuelo particular dependen del tipo de avin que opere ese da. Pasajero - Para poder hacer una reservacin se requiere dar el nombre del pasajero. Varios pasajeros pueden aparecer bajo una sola reservacin.

RegistroTarjeta - 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.
Avin - Un vuelo en una fecha determinada se hace en un tipo de avin particular. El tipo de avin define la cantidad mxima de pasajeros que pueden viajar en ese vuelo para esa fecha. ViajeroFrecuente - El pasajero tiene la opcin de acumular millas para un vuelo particular si cuenta con una tarjeta de viajero frecuente para la aerolnea correspondiente.