Está en la página 1de 30

DEPARTAMENTO DE INGENIERA DE SOFTWARE Y SISTEMAS INFORMTICOS

GRADO EN INGENIERA INFORMTICA


71013035 DISEO DEL SOFTWARE

CURSO 2016 - 2017

ACTIVIDAD EVALUABLE Y CALIFICABLE

1. Portada con:

Asignatura: 71013035 Diseo de Software


Ao de la prctica:
Centro Asociado al que pertenece:
Tutor que le da asistencia:
(o grupo de tutora Intercampus al que est adscrito)

Datos personales: Nombre y apellidos:

DNI o nmero de expediente:

Contacto (telfono o correo electrnico):

Localidad de residencia:

Datos de coste: Horas de dedicacin al estudio de los


contenidos:
N de actividades no evaluables realizadas y
horas de dedicacin:
Horas de dedicacin para realizar esta
actividad:

Juan del Rosal, 16


28040, Madrid

Tel: 91 398 89 10
Fax: 91 398 89 09

swdesign@issi.uned.es
2. El enunciado y planteamiento del caso de estudio.

El dominio del problema es un sistema de gestin para la venta de billetes


de avin en una agencia de viajes (e-Vuela).

El caso de estudio es similar al punto de venta (PdV) del libro de la asignatura y,


como ah, el trabajo se centrar, exclusivamente, en la lgica del negocio y en los
servicios tcnicos mnimos necesarios para implementar esa lgica en la
aplicacin. Es decir, aunque exista una capa de presentacin, no debe tener en
cuenta la interfaz de usuario, la presentacin o cmo se capturan los eventos.
Cntrese en la lgica de la interaccin entre el usuario-agencia y su
funcionamiento.

Se pretende que la aplicacin tenga flexibilidad para ser utilizada tanto por un
operador en un terminal de la propia agencia de viajes, por un cliente desde un
dispositivo mvil o por un administrador, para realizar labores de supervisin y
mantenimiento. Cada uno de estos perfiles determina las funcionalidades
disponibles para un usuario concreto. Por tanto, la utilizacin de esta aplicacin
se restringe a usuarios registrados, con sus datos de acceso, personales y, en el
caso de clientes, de facturacin, almacenados en el sistema. En cualquier
momento se puede registrar o dar de baja un nuevo cliente y cualquier usuario
puede editar sus propios datos.

A parte de la interaccin debida al mantenimiento de una cuenta (alta, baja,


modificacin de los datos del usuario, etc.), los servicios de la aplicacin se
originan cuando un usuario solicita o consulta un viaje en avin, con un nmero
de plazas (pasajeros), entre un origen y un destino, para una fecha y condiciones
de uso determinadas (necesidades especiales del viajero, facturacin de equipaje,
equipajes especiales, etc.). Con esos datos, la aplicacin obtiene una lista de
itinerarios mediante un sistema (externo) de planificacin que, a su vez, consulta
a las compaas areas que operen en cada punto de los itinerarios. Un itinerario
consiste en una secuencia de uno o ms vuelos entre el origen, las escalas
intermedias (si las hay) y el lugar de destino. Cada itinerario contiene (referido a
un nico pasajero):

Los datos de cada vuelo, con la siguiente informacin:


1. Nmero de vuelo.
2. Fecha y hora de salida (local del origen).
3. Fecha y hora de llegada (local del destino).
4. Aerolnea.
5. Lugar de origen del vuelo.
6. Lugar de destino del vuelo.
7. Duracin del vuelo.
Duracin total del viaje.
Nmero de plazas (pasajeros).
Coste total del viaje por pasajero. En el coste se incluyen los precios de cada
vuelo as como las tasas (de aeropuerto, etc.) que correspondan.

Pgina 2 de 30
Condiciones de uso: facturacin de equipaje incluido en el precio y otra
informacin pertinente al respecto.

El resultado de la consulta (lista de itinerarios), se puede almacenar en su perfil,


recuperar, actualizar y ordenar segn la duracin del viaje o su precio total. Con
una lista de itinerarios, el usuario tambin puede seleccionar uno o ms itinerarios
y reservarlos. Al hacer la reserva se bloquean, durante un tiempo (24 h), las
plazas solicitadas para los vuelos de ese itinerario (An no se compran!!). Cada
reserva queda reflejada en la lista de itinerarios y, transcurrida su vigencia,
desaparece (se libera) al recuperar o actualizar la lista de itinerarios.

Tras hacer una reserva, si est vigente, un usuario puede comprar los billetes
del viaje de la siguiente manera:

1. Registrando al cliente, especialmente sus datos de facturacin; o editndolos


o confirmndolos si ya estaba registrado.
2. Introduciendo los datos, necesarios para los vuelos, de cada viajero.
3. El cliente realiza el pago del importe completo: de todos los vuelos, de todas
las tasas, de todos los viajeros...
4. La aplicacin emite los billetes de todos los vuelos del itinerario, nominales
para cada viajero.
Los detalles y simplificaciones admitidas son:

Un usuario slo puede manejar su propia informacin. Un operador, adems,


puede compartir las listas de itinerarios con cualquier cliente o emitir billetes.
Un administrador, adems, puede realizar cualquier operacin y manejar la
informacin de cualquier usuario con los otros dos perfiles.
Se obviar la relacin entre las compaas areas y la agencia de viajes, que
capacita a esta ltima para bloquear un determinado nmero de pasajes
(reserva) en un vuelo. No obstante, dichas compaas areas son las nicas
que manejan cualquier elemento relacionado con los vuelos. Es decir, si bien
el planificador (externo) ser el encargado de obtener, por parte de las
compaas, la informacin de los vuelos, sern ellas las nicas que emitan los
billetes de sus vuelos, previo pago y nominales para cada viajero, cuando lo
reclame la agencia.
Las fechas y horarios son siempre locales. En el cmputo temporal se
ignorarn desfases por usos horarios, cambio de ao, etc.
En la reserva y compra, no se contempla la opcin de seleccionar asiento.
Los precios se presentan y manejan en la divisa local de la geolocalizacin en
la que opera el usuario. Aunque se ignorarn los procedimientos de conversin
de divisa, la aplicacin se debe poder usar en cualquier pas.
En el coste de los vuelos, se considerar el precio por la facturacin de nica
maleta estndar por viajero estndar. Es decir, no se considerarn los
sobrecostes por exceso de equipaje o condiciones especiales que queden fuera
de la tarifa establecida en el itinerario. As mismo, la comisin por los servicios
(segn las polticas de precios y descuentos de la agencia de viajes) estar
incluida en el precio final del viaje.
Pgina 3 de 30
En la compra, el pago se realiza a la agencia de viajes. En la emisin de los
billetes, se ignorar el procedimiento por el que la agencia, a su vez, reparte
el pago de los distintos vuelos y tasas entre las compaas areas incluidas en
el itinerario.
Si la compra se realiza a travs de un operador, el pago (del cliente a la
agencia) podra ser en cualquiera de las modalidades (efectivo, tarjeta, etc.).
Sin embargo, si es el cliente el que opera a travs de un dispositivo mvil, slo
se considera el pago por medios electrnicos (tarjeta, portales de pago
seguro, etc.)

3. El enunciado de cada cuestin y las respuestas. Para cada cuestin,


incluir los desarrollos, listados, diagramas y las argumentaciones que estime
necesarios.

RECOMENDACIONES: Despus de tratar de entender el


planteamiento anterior del caso de estudio, lase todos los enunciados
de las cuestiones siguientes, hasta el final. Est atento a algunos
indicios que le pueden ayudar para el enfoque de sus respuestas. Es
posible que se le pida que describa o relacione algn elemento; lo cual
podra hacerle sospechar que debera contar con l.

PREGUNTAS GUA: Estas preguntas no forman parte del ejercicio. Su


objetivo es ayudar a que dirija sus conclusiones adecuadamente.

Qu hace, exactamente, este software?

De dnde provienen los estmulos? Es decir quines son los actores


y cul debe ser su comportamiento (estmulos), frente al que debe
reaccionar el software?

Pgina 4 de 30
Una vez aislado el software y comprendido el objetivo primordial de
su funcionamiento qu secuencia de operaciones debe realizar, como
reaccin a los estmulos, para que el funcionamiento sea el deseado
(Caso de Uso)?

En el comportamiento del software, la situacin es parecida: un objeto


reacciona ante un estmulo que proviene de otro objeto o del exterior
(un actor). Esa es, precisamente, la tarea de asignar
responsabilidades. Por tanto, la pregunta es: qu objeto atiende un
estmulo y cmo reacciona ante l? Nunca hay que perder de vista que,
en definitiva, estamos hablando de cdigo y que, esos estmulos, se
traducen en llamadas a mtodos. Por consiguiente, es inaceptable una
invocacin a un mtodo inexistente o aquellas llamadas en las que se
solicita una reaccin que es imposible realizar porque no se dispone
de la informacin necesaria (falta de parmetros, etc.) o sta es
inaccesible.

Seccin 1. Evaluacin de Casos de Uso

1. (05 puntos) En relacin al software de e-Vuela considerado en el caso de


estudio, identifique al menos 4 casos de uso primarios y sus actores
correspondientes. Represente los resultados en un diagrama de casos de uso de
UML.

Pgina 5 de 30
El inters principal del diagrama anterior es:
1. Identificar las primeras operaciones y funciones principales de la aplicacin
(o el mdulo que se est estudiando).
2. Identificar los actores principales: aquellos actores cuyo objetivo principal,
al utilizar la aplicacin, nos dar su funcionalidad esencial, los casos de
uso principales. Aunque un usuario genrico est especializado en 3 tipos,
el sentido del funcionamiento de la aplicacin (el negocio) es satisfacer los
objetivos fundamentales del Cliente:
a. Hacer una consulta para buscar un viaje.
b. Comprar un viaje.
Las otras especializaciones de Usuario tendrn, adems de las anteriores,
otros objetivos fundamentales que, seguramente, darn lugar a casos de
uso principales.
En cualquier caso los actores principales sern los que generan los
estmulos necesarios (o eventos, deben ser capaces de ello) para que la
aplicacin responda con el comportamiento esperado (el contenido del caso
de uso).
3. El anlisis del enunciado puede llevar a detectar otras operaciones
completas que, aunque no justifiquen en s el funcionamiento de la
aplicacin, pueden responder a otros objetivos importantes para los actores
principales:
a. Registrar un usuario o mantener los datos de una cuenta.
Normalmente esta informacin (datos de identificacin, preferencias,
medios de pago, etc.) se asimila con el trmino Perfil de la cuenta.
Pero, en el enunciado, el almacn de consultas de viajes aparece
asociado a l, por lo que se asumir que dicho almacn es un
componente del perfil.
b. Guardar o recuperar una consulta en el perfil de usuario (Mantener
o Gestionar Perfil).
c. Reservar un itinerario.
d. Que un Operador obtenga el itinerario de un cliente, o suplante su
identidad, para realizar otras operaciones en su nombre.
e. Mantenimiento de los sistemas de informacin (B.B. de D.D.) precios,
paquetes promocionales y de la aplicacin en general.
Sin perder de vista los dos casos de uso detectados en el punto 2, se puede
discutir si estas operaciones son completas, independientes, casos de uso
secundarios o primarios.
En este enlace se pueden encontrar unas anotaciones sobre las relaciones de
inclusin y extensin entre los casos de uso: UML use case EXTEND vs
INCLUDE relationships.pdf (obtenido de http://www.uml-diagrams.org)

Pgina 6 de 30
4. Las conclusiones anteriores facilitan analizar qu tipo de informacin
(datos) se va a manejar en cada una de las operaciones identificadas, qu
informacin es razonable que se maneje dentro de la aplicacin (o de la
sesin correspondiente a los casos de uso o las operaciones que se estn
manejando), cul va a provenir de servidores de informacin externos o,
enfocado desde otra perspectiva, qu actores secundarios o de apoyo sern
necesarios para que colaboren con los casos de uso identificados y provean
dicha informacin.
Con todo lo anterior se tiene un mapa bastante aproximado del sistema estudiado,
de sus operaciones principales, de los actores principales, que generan los
estmulos para que se realicen, y de los secundarios y los de apoyo, que colaboran
con el sistema para aportar la informacin adicional necesaria para completar
dichas operaciones principales.

2. (1 punto) Escriba el caso de uso <<ProcesarCompra>> en un formato completo


(se recomienda la variante en dos columnas) y estilo esencial. Incluya tanto el
escenario principal de xito como 2 extensiones o flujos alternativos que
pudieran ser frecuentes. Suponga que el escenario de partida para este caso de
uso es el de un usuario registrado que ya est identificado en el sistema, que ya
haba realizado varias consultas para un viaje, para un mnimo de 2 viajeros, y las
haba almacenado en su perfil. Dicho usuario decide realizar la compra
correspondiente a un itinerario, que ya haba reservado, de una de las listas de
itinerarios que ha recuperado de su perfil (el flujo bsico de acciones comienza con
la orden de compra del itinerario reservado y termina con la obtencin de los
billetes). En este flujo principal, considere slo el pago por medios electrnicos, sin
tener en cuenta las polticas de precios, descuentos o promociones de la agencia
de viajes. No escriba un encabezamiento demasiado elaborado del caso de uso
(es decir, omita propsito, resumen); en su lugar, afronte directamente el
transcurso tpico de los acontecimientos.

Caso de uso: ProcesarCompra

Formato completo (variante a dos columnas), estilo esencial.

Evolucin tpica de los acontecimientos

Acciones del actor (normalmente el


Respuesta del sistema
Cliente)
1. El caso de uso comienza cuando el cliente 2. El sistema comprueba la vigencia de la
selecciona la operacin Comprar sobre reserva y solicita los datos de cada
un itinerario reservado. viajero (necesarios para la emisin de
los billetes).
3. Para cada viajero, el cliente facilita los 4. El sistema recoge la informacin de
datos pedidos (por ejemplo, rellenando un cada viajero, necesaria para que las
formulario). aerolneas emitan los billetes.

Pgina 7 de 30
Se repiten los pasos 3 a 4 hasta que el 5. El sistema presenta un resumen con la
usuario finalice la entrada. informacin de los usuarios,
descripcin de los vuelos y el precio
total con los impuestos calculados.
6. El cliente paga, aportando la informacin 7. El sistema da opcin a que el cliente
de su tarjeta de crdito. modifique la informacin de pago de
su perfil.
8. El sistema enva la peticin de
autorizacin del pago al sistema
externo del Servicio de Autorizacin
de pagos y solicita la autorizacin del
pago.
9. El sistema recibe la aprobacin del
pago y lo notifica al cliente.
10. El sistema registra el pago a crdito,
que incluye la aprobacin del pago.
11. El sistema presenta el mecanismo de
entrada para la firma del pago a crdito.
12. El cliente introduce la firma del pago. 13. El sistema se pone en contacto con
cada aerolnea del itinerario, paga la
cantidad que corresponda a los vuelos
de esa compaa, para todos los
viajeros, y solicita la emisin de los
billetes.
14. El sistema registra la venta completa
(incluido el pago a las aerolneas) y
enva la informacin de la venta y el
pago al sistema de Contabilidad
externo.
15. El sistema transfiere todos los billetes
al cliente y presenta un recibo.
16. El cliente recoge los billetes, el recibo y
termina la operacin.

Alternativas

3 a 5 El cliente desea modificar de algn viajero. Se da opcin de rectificar la entrada deseada, comenzar
desde el 1er viajero o cancelar la compra.
8 El sistema detecta un fallo en el dilogo con el sistema de autorizacin. El sistema solicita un modo
de pago alternativo al cliente. De otro modo, se cancela la operacin.
9 El sistema recibe una denegacin de la autorizacin del pago. El sistema solicita un modo de pago
alternativo al cliente. De otro modo, se cancela la operacin.
13 El sistema detecta un fallo en el dilogo con la aerolnea. Si no se puede obtener algn billete, se
cancelan los billetes ya emitidos (para restitucin del importe), se hace una devolucin del pago al cliente,
se registra el error en la operacin y se cancela toda la venta.

Pgina 8 de 30
Este apartado est orientado a pensar:
QU tiene que hacer la aplicacin (el negocio).
Qu pasos fundamentales debe dar (el software) para hacerlo.
En este proceso ya se empieza a identificar la informacin que se puede
necesitar para que la aplicacin realice las operaciones de cada paso, si los
datos concretos se pueden obtener o deducir de la informacin que maneja el
sistema o, por el contrario, requiere la intervencin de algn actor.

Otra vez, cuando se piensa en cmo se va a realizar esto, se concluye que el


software de la aplicacin slo debe manejar la informacin que aporte el cliente
y la estrictamente necesaria para realizar las operaciones requeridas (slo las
del caso de uso). Algunas de ellas deben ser verstiles o s necesitan un volumen
de informacin importante; por lo que no parece razonable que se procese
localmente en la sesin. Por ejemplo, la conexin al Servicio externo de
Autorizacin de Pagos o a las Aerolneas requiere un adaptador que sirva de
interfaz para adecuar los formatos de representacin de la informacin y el
protocolo de comunicacin con cada una. No parece viable que dicha coleccin
de adaptadores (polimorfismo) residan en la sesin. Parece ms lgico que la
conexin se establezca desde la Agencia de Viajes (equivalente a Tienda en
PdV). De igual forma, parece que se va a utilizar cierta informacin del cliente
que, en principio, se asocia como depositada en su perfil: el itinerario, los datos
de pago Tpicamente, esa informacin reside en una base de datos (la de
usuarios) que es externa a la lgica del negocio que se est modelando.
Tras lo anterior, un primer refinamiento del diagrama de casos de uso podra ser
ste:

Pgina 9 de 30
Seccin 2. Evaluacin del Modelado Conceptual

3. (2 puntos) En relacin al caso de uso anterior <<ProcesarCompra>>, construya


un Modelo de Dominio y represntelo en notacin UML. Represente los objetos
conceptuales, las asociaciones y los atributos.

Esta seccin es importante porque el Modelo es el antecedente del Diagrama de


Clases, casi el objetivo final.
Se trata de asignar, las operaciones identificadas en la escritura del caso de uso,
a determinados elementos u objetos. Como quiera que los principios GRASP
(especialmente los 5 primeros) estn orientados a mantener una privacidad en
las operaciones, de forma que slo manejan la informacin local (la del objeto en
el que estn), hay que colocar, la informacin que se ha identificado como
necesaria para una operacin, en el mismo objeto en el que est dicha operacin.
Es la nica manera de obtener independencia funcional y, con ello, la flexibilidad
que se busca para el funcionamiento del software.

Siguiendo con la idea central de lo anterior, se podra poner el ejemplo PdV del
texto de la asignatura. En la escritura del caso de uso de Procesar Venta, se
llega a conclusin de que una operacin fundamental es registrar los datos de
una venta. Por tanto, a la hora de construir el Modelo (y, luego, el diseo de
clases) hay que considerar un elemento Registro, que recoja el registro de las
ventas, y otro, Venta, con los datos de la venta. Y cmo Registro captura o
registra los datos de una venta? Pues acta de controlador, recogiendo la
informacin del actor y buscando el resto, y se la provee a Venta para que realice
su labor.
Este caso podra ser similar: es necesario registrar los datos de la venta de n
viajes, operacin que consiste en obtener los billetes de los vuelos de
cada viajero y pagar por ello. Esta es la primera conclusin importante del
caso de uso.
Con poco que se profundice en un ejercicio, se tiende hacia un planteamiento
complicado. Siempre es necesaria una labor de sntesis y abstraccin que puede
ser difcil al principio. As, en este caso, aunque el caso de uso est restringido
a una situacin irrealmente reducida, la aplicacin del procedimiento enunciado
anteriormente de seguir el hilo de dnde proviene la informacin que se
necesita lleva a otra conclusin importante: si el objeto de las ventas son los
viajes (de cada viajero), stos consisten, a su vez, en un conjunto de vuelos.
Es decir, siguiendo con la analoga con PdV, hay un desdoblamiento anidado en
el equivalente a la lnea de venta (cada viaje).
Para comprender mejor la estructura de lo que se est manejando, puede ser
til pensar en cmo se generan los itinerarios: las consultas. Una aproximacin
superficial al modelo de dominio de ese caso de uso, podra dar este resultado:

Pgina 10 de 30
A partir de aqu, de la escritura del caso de uso, las analogas con PdV y la
comprensin de los catlogos como mecanismo importante para restringir el
manejo de la informacin a la estrictamente necesaria en cada operacin, se
puede aventurar el siguiente diagrama para el caso de uso de la pregunta:

Pgina 11 de 30
Para los siguientes pasos, se ve que hay ms complejidad. La compra del viaje
significa la compra de los billetes y, su emisin, se hace tras comprar los vuelos
a las aerolneas. Todo apunta a que, en el proceso de venta, tambin hay que
considerar una especie de pago a los proveedores.

Seccin 3. Evaluacin de los Eventos del Caso de Uso

Antes de comenzar a asignar responsabilidades (diseo), se


suele complementar la comprensin del comportamiento
deseado para el sistema (como en el Modelo de Dominio que se
acaba de elaborar) con la evaluacin de los Eventos del
Sistema. Para ello se construye un Diagrama de Secuencia del
Sistema (DSS) en el que se analizan los eventos o estmulos
que se originan en los actores y cmo reacciona el sistema. Es
decir, cul es el comportamiento del sistema software
(tomndolo como un nico objeto o elemento), en cuanto a su
salida (la reaccin externa hacia el actor), cuando recibe un
evento (estmulo) de algn actor.

Podra ser ste:

Pgina 12 de 30
4. (15 puntos) Circunscrito al caso de uso anterior <<ProcesarCompra>>, construya
un Diagrama de Secuencia (diagrama de interaccin DS) en UML. Represente
los actores y los eventos de los componentes del sistema para este caso de uso.
NOTA: se pide un diagrama de secuencia en el que represente el paso de mensajes
entre los actores y los objetos, NO del Sistema (DSS). Por tanto, represente las
lneas de tiempo de los objetos identificados en el modelo en lugar de la del sistema
global.

A continuacin se desglosa el DS anterior en cada una de las operaciones. Se


podra dar por correcto un diagrama de secuencia similar al anterior (si induce
a que la escritura de los contratos de las operaciones elegidas sea coherente y
adecuada para los diagramas de colaboracin posteriores) o similar a una unin
simplificada de los siguientes:

IniciarCompra

Ntese:
Un actor humano no puede procesar datos. Slo puede invocar una accin
(en el software) o aportar una informacin que, en general, no puede ser
utilizada directamente por el software. Por ejemplo, un cliente no conoce el
cdigo con el que se maneja, internamente, un itinerario.
Las flechas entrantes en una clase son invocaciones a una operacin.
Significa que esa clase tiene esa operacin, conoce y maneja la informacin
de los tipos de los argumentos que acompaan a la invocacin, as como del
valor que devuelve.
Se sigue el criterio de agrupar la informacin, crear las estructuras de datos
y los objetos en cuanto se disponga de los datos necesarios para ello y se
necesiten, intentando minimizar las acciones necesarias para la realizacin
de las operaciones principales.

Pgina 13 de 30
En este sentido, a partir de la seleccin del ID del itinerario y la comprobacin
de la vigencia de su reserva, se puede crear la Venta (v) y la coleccin vaca del
equivalente en PdV a las lneas de venta: Viaje. Sin embargo, en este caso, la
informacin distintiva de cada viaje es la informacin del viajero (necesaria para
producir sus billetes) y lo que se vende es una lista de vuelos (comn para
todos los viajeros). Por tanto es mucho ms eficiente y desacoplado crear una
coleccin para la informacin de los viajeros y otra para la informacin de los
vuelos.
Ms adelante, cuando se elabora la operacin de la obtencin de billetes, se cae
en la cuenta de que stos son los artculos que se obtienen en la compra y que
quin los provee son las compaas areas. Por ello, si se piensa que la obtencin
de los billetes significa una conexin a la aerolnea y la transmisin de la
informacin de sus vuelos, convendr reordenarlos por compaas areas:

Ntese que la emisin de los billetes requiere la informacin del vuelo, no su


ID de uso interno, por lo que es esa la informacin que se agrega en la lista de
vuelos de la compaa.

Pgina 14 de 30
Para esta reordenacin, se ha hecho uso de otro catlogo, el de compaas con
las que trabaja la agencia de viajes. Habra que actualizar el modelo de dominio
con estos nuevos objetos.
AgregarViajero:

Pgina 15 de 30
RealizarPago e ImprimirBilletes:

Se puede mejorar mucho la eficiencia de la obtencin de los billetes anidando


los bucles de forma inversa: a cada compaa se le enva la informacin de todos
los viajeros, la lista con la informacin de todos sus vuelos y se le paga esa
cantidad de una vez.
La escritura de los contratos de las operaciones principales consiste en
transcribir los DS anteriores mediante una sintaxis especfica (de
pseudocdigo) para las precondiciones y postcondiciones:
Precondiciones (situacin previa a la ejecucin de la operacin):
Existencia de instancias y asociaciones.
Postcondiciones (situacin posterior a la ejecucin de la operacin):
Creacin de instancias (nombre) o asociaciones.
Modificacin en el valor de los atributos o en el estado de los objetos.
A partir de los anteriores DS, con la ayuda de los contratos escritos para las
operaciones, la obtencin de los diagramas de colaboracin correspondientes es
inmediata (preguntas 5 y 6).
A partir de aqu, con un refinamiento previo del modelo de dominio, extrayendo
de l los objetos implicados en el registro de la compra y obtencin de los
billetes, con sus relaciones, agregando a cada clase los mtodos, obtenidos como
mensajes en los diagramas anteriores, y estableciendo las asociaciones

Pgina 16 de 30
adicionales que se deducen de la escritura de los contratos de las operaciones,
se obtendra el diagrama de clases del diseo (DCD) pedido.

En general, los resultados as obtenidos podran ser aceptables. Sin embargo


hay determinados conceptos, fundamentales en esta asignatura, que no se han
tratado con una profundidad definitiva. Debido a la persistencia de experiencias
anteriores en los resultados, merece la pena tratarlos y reflejarlo en este
ejemplo. Explicado de una manera gruesa y poco rigurosa:
1. El primer objetivo en el desarrollo de una aplicacin es que funcione como
lo plantea el cliente (satisfaccin de la lgica del negocio solicitada por el
cliente en este caso, el enunciado).
2. El objetivo de esta asignatura, supeditado al anterior, es que dicha
aplicacin sea, adems, flexible y fcilmente mantenible. Es decir, que
facilite los cambios en su comportamiento (algunos, los que puedan ser de
inters para el negocio del cliente). Es evidente que el comportamiento de
la aplicacin est definido por el cdigo y, a su vez, el diseo es la
especificacin para el funcionamiento del cdigo; por lo que el objetivo se
alcanza a travs del diseo.
3. La principal manera de obtener flexibilidad y mantenibilidad es exigiendo
independencia funcional en los diseos. Esto significa que las
responsabilidades (funciones) que desempea un elemento de un diseo
sean independientes de las de otro. Un diseo tambin es una
representacin del trabajo colaborativo de sus elementos. Por tanto, aqu,
el diseo consiste en asignar convenientemente roles de comportamiento
organizativo (Controlador, Experto-Creador, Polimorfismo, etc fachada,
factora, adaptador, observador, proveedor de servicios) y
responsabilidades (funciones) que se conjuguen correctamente con la
ocultacin (privacidad), el encapsulamiento, la cohesin alta, la
generalizacin-especializacin y, sobre todo, el acoplamiento bajo; para
conseguir la colaboracin independiente de los elementos (objetos) de la
aplicacin.
Adems hay otros conceptos importantes que, aunque se insiste en ellos de
manera destacada en toda la asignatura, parecen ser ignorados
persistentemente:
El Controlador. Es un rol de comportamiento que consiste en aceptar las
peticiones de accin, los eventos o estmulos y los dirige hacia el objeto
capacitado para reaccionar con el comportamiento adecuado (respuesta)
a la operacin solicitada. Siempre debe haber uno de cara a la fuente de
los estmulos principales (en principio, para atender al actor principal) del
caso de uso. Puede no ser nico, puede repartirse ese comportamiento
con otros, o puede asumir, adems, otros roles o funciones (por ejemplo,
registro en PdV); pero debe existir desde el primer momento en el que se
representa en funcionamiento del software (diseo).
El Registro. Hay una gran cantidad de operaciones, realizadas con
software, que representan una transaccin. En general, una transaccin

Pgina 17 de 30
es una accin en la que se involucran al menos dos partes y en la que se
intercambia algo entre ellas. La imagen ms obvia es la de la transaccin
comercial; en la se intercambia un producto o servicio generalmente por
dinero. Tambin en la mayora de los casos, hay un inters muy alto, de
todas las partes implicadas, porque quede constancia fiable de lo que se
intercambia y en qu circunstancias. La figura encargada de esto (dejar
constancia fiable del intercambio) es el registro.
A la hora de modelar un escenario (modelo de dominio o de la lgica del
negocio) puede haber innumerables situaciones (no slo en las
transacciones) en las que exista ese inters por dejar constancia de algn
hecho; y debe existir el registro que lo haga o el objeto que haga esa
funcin, se llame como se llame. Esta argumentacin nos vuelve a dirigir
hacia la reflexin ms importante del anlisis:
Cul es la operacin principal que define el caso de uso?
En el caso de PdV es una transaccin comercial en la que se intercambian
unos artculos por dinero.
Y cul es en el caso de uso de e-Vuela? Parece ser, tambin, una
transaccin comercial en la que se intercambian viajes por dinero.
Seguro? En qu consiste el objeto que se intercambia y cules son las
circunstancias del cambio? Los viajes, en realidad, son vuelos en avin;
representados por unos billetes. El Cliente obtiene sus billetes pero la
Agencia de Viajes, a su vez, los compra a las Aerolneas con las que trabaja
y le cobra, al Cliente, una cuanta adicional por sus gestiones. Se trata de
una transaccin comercial con intermediario (la agencia de viajes), o una
doble transaccin, que vara notablemente el planteamiento del modelo
del dominio y, por consiguiente, cmo se resuelve el diseo.
Lo anterior se podra enunciar como un corolario de algn principio del
anlisis:
Al modelar un caso de uso definido principalmente por una transaccin,
es muy recomendable hallar los objetos finales del intercambio, las partes
implicadas y las circunstancias en las que se produce.

Bromas aparte, si se da esta situacin, como ocurre en un nmero muy


elevado de casos, el registro (o un objeto que cumpla esas funciones) debe
existir y reflejarse desde el primer momento en el que se representa la
lgica del negocio (modelo de dominio).
El par Catlogo-InformacinDeObjeto. Se asume que la privacidad,
ocultacin y encapsulamiento de los objetos consiste en que slo pueden
manejar su propia informacin (son Expertos) y viceversa: la informacin
de sus atributos es la estrictamente necesaria para que realicen las
operaciones que se les encomienda. Por otro lado, se busca la cohesin y
el acoplamiento bajo (independencia funcional) que consiste en que las
operaciones que realiza un objeto sean independientes de las que realizan
otros. Es decir, que no requieran la informacin de otro objeto. Pero, para

Pgina 18 de 30
que haya colaboracin entre las operaciones, es muy frecuente que stas
utilicen alguna informacin de otro objeto. La respuesta inmediata, y
errnea, es incluir al objeto como componente. Si slo es necesario un
atributo del objeto qu sentido tiene incluir todo el objeto? Especialmente
cuando existen varias alternativas para usar un objeto u otro (listas,
colecciones o multiobjetos), esto lleva a diseos monolticos, inconexos y
fuertemente acoplados en los que todos los objetos estn unos dentro de
otros, como las muecas rusas.
La solucin a esto puede ser el uso de un grado de indireccin y el
catlogo es un ejemplo, como mecanismo de desacoplo, similar. De
ah su gran importancia.
La idea consiste en utilizar una referencia al objeto, un identificador
(articuloID), no todo l en la coleccin. Adems, es necesario un
mecanismo por el que, cuando sea necesario y a partir de esa referencia,
d acceso (Catlogo) a la informacin que, estrictamente, se requiera del
objeto de la lista (EspecificacionDelProducto).
El catlogo es una especie de ndice, de directorio, que contiene una
coleccin de parejas {clave-de-bsqueda, informacin-requerida}. Hay
que resaltar que informacin-requerida se mantiene en otra clase
(EspecificacionDelProducto) y no se corresponde con todo el contenido del
objeto (Articulo), slo con la que se va a usar en ese otro objeto.
En nuestro escenario, una consulta contiene los datos de bsqueda y un
listado de los itinerarios encontrados. Pero en este listado no est la
informacin de cada itinerario, slo su identificador; al contrario que en la
base de datos de usuarios, que s estar, junto con otra abundante
informacin adscrita al perfil del usuario. En el caso de uso, un itinerario
contiene una lista de vuelos pero, en cada uno de los elementos de esa
lista, no estn los datos del vuelo (necesarios para emitir los billetes), slo
su identificador. Un vuelo tiene informacin sobre la aerolnea pero no toda
la que se pueda usar en el caso de uso, slo su identificador.
La excepcin est en Billetes, cuya cardinalidad es numViajeros X
numVuelos, y en el hecho de que cada aerolnea emite los billetes de sus
vuelos. Para empezar, ser conveniente agrupar los vuelos (comunes a
todos los viajeros) por compaas areas. Adems, para evitar la
multiplicidad de todos los viajeros con todos los vuelos, sera ms
econmico no desplegar el producto cartesiano y mantener separadas las
dos listas (numViajeros + numVuelos). Como la informacin que necesitan
las aerolneas para emitir los billetes es, precisamente, la especificacin
de los elementos de cada una de esas listas (informacin del viajero y
datos del vuelo), es el nico caso en el que los mencionados elementos
no sern los identificadores (referencias a) de los objetos sino,
directamente, su contenido.
Con estas conclusiones, se vuelve a hacer un refinamiento desde el inicio del
anlisis del caso de uso.

Pgina 19 de 30
La aproximacin al modelo de la consulta quedara:

Adems de reflejar la informacin que se maneja en un itinerario, se ha querido


expresar la lgica del inicio del caso de uso. Cada consulta tiene asociada una
lista de itinerarios cuya informacin se guarda, asociada al perfil del usuario, en
la base de datos de usuario. GestorPerfil es el experto en esta informacin y
quien tiene la responsabilidad de manejarla. Ser el controlador principal de la
sesin del usuario quien, al seleccionar ste un itinerario para su compra,
invocar a GestorPerfil que, a su vez, consultar a la base de datos de usuarios
(mediante un adaptador), extraer la informacin DescrItinerario de los
itinerarios de esa consulta y construir el catlogo de itinerarios de esa consulta;
con el que podr obtener la informacin de ese itinerario. De igual forma
construir el catlogo con las especificaciones de todos los vuelos del
mencionado itinerario. Tras esto, pasar el control al controlador del caso de uso
(como se ver en el DS de la operacin de inicio de la compra).

Pgina 20 de 30
El modelo de dominio de trabajo inicial del caso de uso quedara:

Para el DS global, se obvia la etapa de inicio y paso del control al registro de


ventas:

Pgina 21 de 30
La descomposicin en las operaciones principales producira estos DS parciales:
IniciarCompra

Pgina 22 de 30
AgregarViajeros y Finalizar:

Pgina 23 de 30
RealizarPago:

ObtenerBilletes:

En el ltimo, se ha omitido la interaccin para la comprobacin de la firma en la


tarjeta del cliente. Tambin se ha obviado otro proceso de pago repetitivo,
anlogo al del cliente, pero que ocurre entre la agencia de viajes y cada una de
las aerolneas a las que se les contrata algn vuelo para este viaje.
Para entender la operacin de pago, quizs convenga revisar el modelo de
dominio en el que se despliegan los paquetes de Pagos y Transacciones de
Autorizacin:

Pgina 24 de 30
Pgina 25 de 30
A partir de este DS, especifique los contratos de dos de las siguientes
operaciones: IniciarCompra (inicio de la compra del itinerario reservado),
AgregarViajero (agregar la informacin de cada viajero para poder emitir los
billetes), RealizarPago (pago con tarjeta de todo el viaje, con todos los billetes)
o ImprimirBilletes (emisin e impresin de todos los billetes, de todos los vuelos
y de todos los viajeros, tras comprobar el pago).

Contrato CO1: iniciarCompra


Operacin: comprar(itinerarioID)
Referencias cruzadas: Caso de Uso: ProcesarCompra.
Precondiciones: Hay una sesin activa, registroVentas, con una instancia de
gestorPerfilUsuario, descViaje, catalogoListaVuelos y
catalogoCompaias.
Se ha comprobado la vigencia de la reserva en virtud del atributo
reservaLoc de descViaje.
Postcondiciones: Se cre una instancia de Venta v.
v se asoci con registroVentas.
Se cre una coleccin vaca (multiobjeto) de Billetes, billetesList y
se asoci con v.
Se cre una coleccin vaca (multiobjeto) de Viajero, viajeros y se
asoci con v.
Se cre una coleccin de DescrCompaia, airCompsViaje, se
asign valor a su atributo listaDescVuelos-Comp en funcin de los
valores obtenidos de catalogoListaVuelos y de
catalogoCompaias y se asoci con v.

Contrato CO2: agregarViajeros y finalizar


Operacin: agregarViajero(viajeroInfo)
Referencias cruzadas: Caso de Uso: ProcesarCompra.
Precondiciones: Hay una Venta, v, en curso.
Hay una coleccin vaca (multiobjeto) de Viajero, viajeros.
Postcondiciones: Se cre una instancia de Viajero, viajero.
viajero.viajeroInfo pas a ser viajeroInfo.
viajero se asoci con viajeros.
v.esCompleta pas a ser verdad.

Contrato CO3: realizarPago


Operacin: realizarPagoACredito(tarjeta)
Referencias cruzadas: Caso de Uso: ProcesarCompra.
Precondiciones: Hay una Venta, v, en curso.
Postcondiciones: Se cre una instancia de PagoData, pagoData y se inicializaron sus
atributos en funcin de los datos obtenidos por
gestroPerfilUruario.
Se cre una instancia de PagoACredito, pago.
pago se asoci con la venta actual v.
Se cre una instancia de TarjetaDeCredito, tarjeta; y se
inicializaron sus atributos con los valores de pagoData.
tarjeta se asoci con pago.
Se cre una SolicitudPagoACredito, solicitud-pago.
pago se asoci a solicitud-pago.
Se cre una instancia de CuentasPorCobrar, pendiente.
pendiente se asoci con el servicio externo de Contabilidad.

Pgina 26 de 30
Contrato CO4: obtenerBilletes
Operacin: obtenerBilletes()
Referencias cruzadas: Caso de Uso: ProcesarCompra.
Precondiciones: Hay una Venta, v, en curso.
Postcondiciones: Se cre una instancia de Pago, pagoAirComp.
pagoAirComp se asoci con la venta actual v.
Se cre una SolicitudPago, solicitud-pagoAirComp.
solicitud-pagoAirComp se asoci con pagoAirComp.
Se cre una instancia de CuentasPagadas, pagada.
pagada se asoci con el servicio externo de Contabilidad.
Se cre una instancia de Billete, billete.
billete se asoci con la venta actual, v.
Se cre una SolicitudEmision, solicitud-billete.
solicitud-billete se asoci a billete.
v se asoci con AgenciaViajes como una venta completa.

Seccin 4. Evaluacin de la Asignacin de Responsabilidades y Diseo de


Colaboraciones

5. (2 puntos) A partir del contrato de la operacin <<se omite la operacin A>>


que haya indicado en el punto 4, complete el diagrama de colaboracin en UML.
Consigne cada mensaje con los patrones GRASP (Experto, Creador, etc.) o
cualquier otro que lo justifique. Si aade responsabilidades no explicitadas en el
contrato (porque crea que es importante sealarlas), explquelas brevemente.
IniciarCompra()

Pgina 27 de 30
6. (2 puntos) A partir del contrato de la operacin <<se omite la operacin B>>
que haya indicado en el punto 4, complete el diagrama de colaboracin en UML.
Consigne cada mensaje con los patrones GRASP (Experto, Creador, etc.) o
cualquier otro que lo justifique. Si aade responsabilidades no explicitadas en el
contrato (porque crea que es importante sealarlas), explquelas brevemente.
De igual forma se hara para el resto. agregarViajeros() y finalizar():
realizarPago():
obtenerBilletes():

Pgina 28 de 30
Seccin 5. Evaluacin de los Diagramas de Clases de diseo

7. (05 puntos) Elabore un diagrama de clases para el caso de uso que se est
tratando <<ProcesarCompra>> (DCD), centrado en la clase cuya responsabilidad
es el registro de la compra de la reserva seleccionada y de la emisin de billetes,
segn se ha descrito en el caso de uso. Represente los nombres de todos sus
atributos, asociaciones (con la navegabilidad) y mtodos.

Pgina 29 de 30
Seccin 6. Evaluacin de la Transformacin del Diseo en Cdigo

8. (05 puntos) A partir de los anteriores diagramas de clases y colaboraciones,


elabore y defina la clase que haya definido, en el desarrollo anterior, como
responsable de la compra de la reserva seleccionada y de la emisin de billetes
en el caso de uso <<ProcesarCompra>>. Incluya las definiciones de todas las
variables que la componen (miembros), pero escriba solamente la definicin
completa del cuerpo para el mtodo (o mtodos) principal/es o ms
significativo/s: <<se omite el mtodo>>. Ignore los pequeos detalles de
sintaxis -el objetivo es evaluar la capacidad fundamental para transformar el
diseo en cdigo-. Utilice la sintaxis de Java.

Pgina 30 de 30