6.5. Modelo Del Dominio Del Problem

6.5 Modelo del dominio del problemaEl modelo del dominio del problema define un modelo de clases comunpara todos los involucrados en el modelo de requisites, tanto analistas comoclientes. Este modelo de clases consiste en los objetos del dominio del proble-ma, o sea objetos que tienen una correspondencia directa en el area de la apli-cacion. Como los usuarios y clientes deben reconocer todos los conceptos, sepuede desarrollar una terminologia comun al razonar sobre los casos de uso y,por lo tanto, disminuir la probabilidad de malos entendidos entre el analista yel usuario. Al discutirlo, se evolucionara el modelo del dominio del problema.Una tecnica utilizada cuando se trabaja con tal modelo, es darle al cliente unpapel y un lapiz, y pedirle que dibuje su vision del sistema.

Historicamente, el modelo del dominio del problema se utilizaba como el mo-delo fundamental para la especificacion de requisites en muchas de las meto-dologias de ingenieria de software orientada a objetos de primera generacion(ver capitulo 3). Sin embargo, dadas sus limitaciones que impedian obtener losrequisites funcionales de un sistema, el modelo del dominio del problema dejode ser la base unica para el desarrollo completo del sistema y paso a ser unelemento adicional en la especificacion de este, como en el modelo de casosde uso. El proposito principal del dominio del problema en el modelo de re-quisites de nuestra metodologia es formar una base comun de entendimientodel desarrollo y no definir el sistema completo. Por tanto, se pueden aprove-char algunas heuristicas de los metodos anteriores para identificar los objetosen el dominio del problema, con lo que se lograra un glosario o diccionariode clases que sirva como comun denominador a todos los componentes delsistema, incluyendo a las personas involucradas a lo largo del desarrollo. A di-ferencia de los metodos anteriores, el modelo del dominio del problema nodebe ser demasiado extenso, ya que se realizaran varios grados de refinamien-to despues. Y aunque es suficiente describir el dominio del problema en termi-nos de objetos o clases, es posible refinar todavia mas mediante la inclusion deasociaciones, atributos, herencia y operaciones, siempre y cuando esto ayude acomprender mejor el problema, y que no se vuelva un esfuerzo demasiado gran-de durante esta etapa. Se debe tener cuidado con hacer demasiado trabajo alinicio, ya que esto puede dificultar su modificacion posterior durante el mode-lo de analisis. La experiencia muestra que muchos, si no todos, de los objetosdel dominio podran aparecer durante este. Sin embargo, pueden haber cambiosdurante este, incluyendo la eliminacion de clases identificadas en esta etapa, oincluso, la incorporacion de clases adicionales.

En esta seccion describiremos como identificar las clases del dominio del pro-blema junto con aspectos adicionales, como asociaciones y atributos. Lo quedefinitivamente no se hara aqui, y que era parte esencial de las metodologiasanteriores, es identificar la herencia y las operaciones en esta etapa. La heren-cia y, en especial, las operaciones de un sistema son los aspectos de mayorcomplejidad, algo que nosotros elaboraremos de manera muy cuidadosa duran-te el diseno del sistema.

6.5.1 Identification de clasesLa identification de clases del dominio del problema, se obtiene principal-mente de algun documento textual que describa el sistema. Aunque se pudie-

MODELO DEL DOMINIO DEL PROBLEMA 235

ra tomar como punto de partida los documentos desarrollados para el modelode casos de uso, a menudo la descripcion original del problema es suficiente.Se comienza este proceso a partir de la identificacion de las clases candidatas,explicitas o implicitas, a las que se reflera la descripcion del problema. Paraello, se extraen todos los sustantivos de la descripcion del problema o de algunotro documento similar, de acuerdo con las siguientes consideraciones:

os sustantivos en la descripcion del problema son los posibles candidatesa clases de objetos. For ejemplo en "un sistema de reservaciones que vendeboletos para funciones a varios teatros", las clases candidatas serian, siste-ma de reservaciones, boletos, funcion y teatro.^ Se deben identificar las entidades fisicas al igual que las conceptuales.'p* No se debe tratar de diferenciar entre las clases y los atributos.|* Dado que no todas las clases se describen de manera explicita, siendo al-gunas implicitas en la aplicacion, sera necesario anadir clases que puedanser identificadas por nuestro conocimiento del area.^ Se deben revisar los pronombres en la descripcion del problema, para ase-gurar que no se haya perdido ningun sustantivo descrito de forma impli-cita.>*• Para facilitar la identificacion de clases, se subrayan todos los sustantivosde la descripcion del problema.

En el caso del sistema de reservaciones de vuelos, partimos de la descrip-cion del problema y subrayamos todos los sustantivos, con sus complementosadjetivos, como se ve a continuation:

El Sistema de reservaciones de vuelos es un sistema que permite al usuariohacer consultas y reservaciones de vuelos. ademas de poder comprar losboletos aereos en forma remota, sin la necesidad de recurrir a un agentede viajes. Se desea que el sistema de reservaciones sea accesible a travesde Internet (World Wide Web).

El sistema presenta en su pantalla principal un mensaje de bienvenidaque describe los servicios ofrecidos junto con la opcion para registrarsepor primera vez, o si ya se esta registrado, poder utilizar el sistema dereservaciones de vuelos.

Este acceso se da por medio de la insertion de un login previamente es-pecificado y un password previamente escogido y que debe validarse.

Una vez registrado el usuario. y despues de haberse validado el registroy la contrasefia del usuario. se pueden seleccionar de las siguientesactividades:

Consulta de vuelosReservacion de vuelosCompra de boletos

(continua)

236 CAP. 6 — MODELO DE REQUISITOS

(continuation)

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

Horarios de vuelosTarifas de vuelosEstado de vuelo

La consulta segun horario muestra losde las diferentes aerolmeasque dan servicio entre dos ciudades.

La consulta segun tarifas muestra los diferentes vuelos entre dos ciudadesdando prioridad a su costo.

La informacion de vuelo se utiliza principalmente para consultar el estadode algun vuelo. incluyendo informacion de disponibilidad de asientos y,en el caso de un vuelo para el mismo dia, si el vuelo esta a tiempo.

Se puede incluir preferencias en las busquedas. como fecha y horario de-seado, categoria de asiento. aerolmea y si se desea solo vuelos directos.

La reservacion de vuelo permite al cliente hacer una reservacion para unvuelo particular, especificando la fecha y horario, bajo una tarifa estable-cida. Es posible reservar un itinerario compuesto de multiples vuelos, parauno o mas pasajeros, ademas de poder reservar asientos.

El pago permite al cliente. dada una reservacion de vuelo previa y unatarjeta de credito valida, adquirir los boletos aereos.

Los boletos seran posteriormente enviados al cliente. o estaran listos paraser recogidos en el mostrador del aeropuerto antes de la salida del pri-mer vuelo.

Es necesario estar previamente registrados con un numero de tarjeta decredito valida para poder hacer compras de boletos. o de lo contrario,proveerla en el momento de la compra.

Ademas de los servicios de vuelo. el usuario podra en cualquier momen-to accesar, modificar o cancelar su propio registro. todo esto despues dehaber sido el usuario validado en el sistema.

A partir de estos sustantivos se prepara una lista inicial de clases candidatas,como se muestra en la tabla 6.1. Se deben/excluir clases repetidas, mantenien-do todos los nombres en singular.

SELECCION DE CLASES

A partir de las clases candidatas, se deben seleccionar las clases relevantes, to-mando en cuenta las siguientes consideraciones:


Tabla 6.1 Clasesidentificadas en la.'dff{$i

Sistema de reservacionesde vuelo

Sistema

Usuarjo

Consulta

Reservacion

Vuelo

Boleto aereo

Agente de viajes

Sistema de reservaciones

Internet

World Wide Web

Pantalla principal

Mensaje de bienvenida

Servicios

Opcion

Reservaciones de vuelos

Acceso

Clases candidates

Login

Email

Password

Registro

Actividad

Consulta de vuelos

Reservacion de vuelos

Compra de boletos

Horario de vuelos

Tarifa de vuelos

Informacion de vuelo

Horario

Aerolmea

Ciudad

Tarifa

Costo

Estado

Disponibilidad

Informacion

Asiento

Dfa

Hora

Preferencia

Busqueda

Fecha

Categoria de asiento

Vuelo directo

Cliente

Itinerario

Pasajero

Pago

Tarjeta de credito

Boleto

Mostrador del aeropuerto

Numero de tarjeta decredito

Todas las clases deben tener sentido en el area de la aplicacion, la relevan-cia del problema debe ser el unico criterio para la seleccion.Como regla general, se deben escoger los nombres de las clases con cui-dado, que no sean ambiguos y que mejor describan el problema. Este esuno de los procesos mas dificiles. Los nombres deben establecerse con unformato consistente (e.g., nombres en singular).Durante esta etapa, no hay que preocuparse por la asociacion, agregaciono herencia. Primero hay que tener las clases especificas correctas para nosuprimir detalles en el intento de ajustarse a estructuras preconcebidas.Ante la duda, se deben conservar las clases, ya que posteriormente siem-pre habra oportunidad de eliminarlas.Eliminar clases redundantes, si expresan la misma informacion. La clase masdescriptiva debe ser guardada.Eliminar clases irrelevantes, que tienen poco o nada que ver con el proble-ma. Esto requiere de juicio, porque en un contexto, una clase puede serimportante, mientras que en otro, la clase podria no serlo.Se deben clarificar las clases imprecisas. Algunas pueden tener bordes maldefinidos o demasiado generales.


ecesario eliminar las clases que debieran ser atributos mas que clases,cuando los nombres corresponden a propiedades mas que a entidades in-dependientes.(fc» Eliminar las clases que debieran ser roles mas que clases, cuando los nom-bres corresponden a la funcion que tienen las clases mas que a las entida-des independientes.^ Suprimir las clases que debieran ser operaciones mas que clases, si las en-tidades representan operaciones que se aplican a los objetos y no a enti-dades manipuladas por si mismas.>* Hay que eliminar del analisis las clases que corresponden a construccionesde implementacion, si estan alejadas del mundo real. No se necesita unaclase para representar una entidad fisica. Por ejemplo: subrutinas, listas yarreglos, son clases tipicas de implementacion; Internet y World Wide Webson el medio de implementacion del sistema.| Se deben eliminar clases que correspondan a aspectos de interfaces de usua-rio y no de la aplicacion.I* Se deben eliminar clases que correspondan a todo un sistema complete.Jfr Suprimir clases que correspondan a actores del sistema.p* Se deben agregar clases implicitas que no aparezcan en la descripcion delproblema.

Se tomaran algunas clases candidatas del sistema de reservaciones de vueloidentificadas anteriormente y se seleccionaran las que mejor se apliquen a nues-tro problema, como se ve a continuacion:

^ Clases redundantes: Cliente y Usuario, ambos terminos pueden ser equiva-lentes, pero en el caso del sistema de reservaciones, consideramos queUsuario es mas descriptivo por ser la persona que utiliza el sistema.H^ Clases irrelevantes: Mostrador del Aeropuerto, Agente de Viajes y BoletoAereo. Si el sistema generara o se refiriera a un boleto aereo, esta clase semantendria.!*• Clases imprecisas: Sistema, Servicios, Actividad, Preferencia, Busqueda, In-

formacion, Estado, Disponibilidad, Opcion, Acceso e Itinerario son clasesimprecisas. Durante la introduccion de herencia puede que sea necesariouna clase para compartir aspectos comunes a ambas clases.i* Nombres de clases: Aeropuerto en lugar de Ciudad.& Clases que son atributos: Numero de tarjeta de credito es un atributo deTarjeta de credito, Categoria de asiento (Asiento), Informacion de vuelo(Vuelo) y Horario de vuelo (Vuelo).I* Clases que son operaciones: Consulta, Pago y Reservaciones.^ Clases de interfaces de usuario: Mensaje de cipal.IN Clases del sistema complete: Sistema de Reservaciones.^- Clases de actores: Cliente.

La tabla 6.2 muestra las modificaciones a las clases candidatas originales.


Tabla 6.2 Clases candidates setat<eTaireservaciones de vuelo, '•^••••^^reservaci

Clases candidatas

Sistema de reservaciones de vuelo

Sistema

Usuario

Consulta

Reserva

Vuelo

Boleto aereo

Agente de viajes

Sistema de reservaciones

Internet

World Wide Web

Hoja principal

Mensaje de bienvenida

Servicios

Opcion

Reservaciones de vuelos

Acceso

Login

Email

Password

Registro

Actividad

Consulta de vuelos

Reservacion de vuelos

Pago de boletos

Horario de vuelos

Tarifa de vuelos

Informacion de vuelo

Horario

Aerolinea

Ciudad

Modificacion

Eliminada (sistema completo)

Eliminada (imprecisa)

Eliminada (actor)

Eliminada (operacion)


Eliminada (irrelevante)


Eliminada (sistema completo)

Eliminada (implementacion)

Eliminada (implementacion)

Eliminada (interface)

Eliminada (interface)



Renombrada: Reservacion


Eliminada (atributo)



Renombrada: RegistroUsuario





Eliminada (duplicada con horario)

Eliminada (duplicada con tarifa)


Renombrada: Aeropuerto

(continua)


Tabla 6.2 Continuacion

Tarifa

Costo

Estado

Disponibilidad

Informacion

Asiento

Dia

Hora

Preferencia

Busqueda

Fecha

Categoria de asiento

Vuelo directo

Cliente

Itinerario

Pasajero

Compra

Tarjeta de credito

Boleto

Mostrador del aeropuerto

Numero de tarjeta de credito

Elimlnada (redundante)











Eliminada (redundante y actor)



Renombrada: RegistroTarjeta




Las clases identificadas se muestran en la tabla 6.3. Note que se agregan dosnuevas clases: Avion y ViajeroFrecuente, que no aparecian en la descripcion delproblema. Esto se hizo para lograr un dominio mas completo. En general, dis-tintos analistas identificaran listas similares de clases, aunque siempre con algu-na variacion.

Tabla 6.3adas para el sistema de reservaclones de vuaio.

Vuelo

Reservacion

RegistroUsuario

Horario

Aerolmea

Aeropuerto

Clases identificadas

Tarifa

Asiento

Pasajero

RegistroTarjeta

Avion

ViajeroFrecuente


DlAGRAMA DE CLASES

Despues de identificar y seleccionar las clases, se debe construir el diagramade clases para el dominio del problema. Este diagrama se muestra en la figu-ra 6.32 y puede ayudar a identificar clases adicionales, ademas servira de basepara encontrar las atributos y asociaciones entre ellas.

Figura 6.32 Diagrama de clases identificadas para el sistemade reservaciones de vuelo.

Aunque se puede parar aqui el proceso de desarrollo del dominio del proble-ma, continuaremos con la identificacion de asociaciones y atributos para el sis-tema de reservaciones de vuelo.

6.5.2 Identificacion de asociaciones

El proceso de identificacion de asociaciones es bastante similar al de identi-ficacion de clases, solo que en lugar de sustantivos buscamos frases que rela-cionen a los sustantivos de clases ya identificadas. En general, este proceso yano es necesario como parte del modelo de casos de uso, dado que las asocia-ciones y operaciones del sistema seran identificadas durante el modelo de di-seno. Sin embargo, aqui se dara un pequeno ejemplo de la identificacion deasociaciones con base en nuestro conocimiento del dominio del problema. (Encierta manera, se escogio como ejemplo el desarrollo de un sistema de reser-vaciones de vuelos, por ser un dominio con el cual la mayoria de los lectorespueden identificarse.)


DlAGRAMA DE CLASES CON ASOCIACIONES

En lugar de partir de la descripcion del problema o los documentos de casosde uso, simplemente identificamos nuestras propias frases correspondientes aldominio del problema del sistema de reservaciones, como se observa en la tabla6.4. Este proceso de identification es sencillo cuando el problema es muy limi-tado y el dominio es facil de analizar. De lo contrario, se requiere un procesode identiflcacion mucho mas extenso, como veremos en la etapa de diseno.

Tabla 6,4 identificadas para refacionar clasasTabla 6,4 identificdel problema.del problema.del

AsociscioriGS ictentificscids

Un vuelo requiere reservaciones.

Un vuelo se dirige a un aeropuerto.

Un vuelo contiene tarifas.

Un vuelo se efectua en un avion.

Un vuelo tiene asientos.

Un vuelo pertenece a una aerolmea.

Un vuelo tiene un horario.

Un pasajero puede acumular millas como viajero frecuente.

Un pasajero efectua reservaciones.

Una reservacion requiere de un registro de tarjeta de credito.

Un registro de tarjeta pertenece a un registro de usuario.

Despues de haber identificado las asociaciones, se debe construir una versiondel diagrama de clases que incluya estas asociaciones, como se muestra en lafigura 6.33.

Figura 6.33 Diagrama de clases con asociaciones entre clases identificadas.Se omiten los nombres de las asociaciones.


DlAGRAMA DE CLASES CON ROLES

Despues de haber hecho el diagrama de clases con asociaciones, se puede cons-truir una version del diagrama de clases incluyendo roles. Como se explico enel capitulo 4, el nombre del rol describe la funcion que desempenara una claseen la asociacion desde el punto de vista de la otra clase. Si hay una sola aso-ciacion entre un par de clases, y el nombre de la clase describe adecuadamen-te su rol, se pueden omitir los nombres del mismo.

Para tal proposito, modificamos levemente las asociaciones identificadas ante-riormente, como se muestran en la tabla 6.5.

Tabla 6.5 Asociaciones identificadas con roles para reiacionac clasesen el dominio del problema.

Asociaciones identificadas con roles

Un vuelo contiene reservaciones.

Un vuelo llega a un aeropuerto de destine.

Un vuelo tiene un aeropuerto de origen.

Un vuelo puede hacer escalas en otros aeropuertos.

Un vuelo contiene tarifas de ida y vuelta.

Un vuelo tiene tarifas solamente de ida.

Un vuelo se efectua en un avion.

Un vuelo tiene asientos.


Un vuelo tiene un horario de llegada.

Un vuelo tiene un horario de salida.

Un pasajero puede acumular millas como viajero frecuente.

Un pasajero efectua reservaciones.

Una reservacion requiere de un registro de tarjeta de credito.


Un vuelo puede tener multiples conexiones.

Se extiende el diagrama de clases con asociaciones para incluir roles, como semuestra en la figura 6.34.

DIAGRAMA DE CLASES CON MULTIPLICIDAD

Despues de haber hecho el diagrama de clases con asociaciones y roles, sepuede construir una version del diagrama de clases incluyendo multiplicidad,la cual se determina para cada asociacion.

Para tal proposito, modificamos levemente las asociaciones identificadas ante-riormente, como se muestran en la tabla 6.6. Note que la multiplicidad, al igualque las relaciones entre las clases, son bastante subjetivas, y pueden variar entreanalistas. Dentro de esa subjetividad, todas deben transmitir un dominio simi-lar del problema.


Figura 6.34 Diagrama de clases con asociaciones y roles entre clases identificadas.Se omiten los nombres de las asociaciones. (O/W significa viaje sencillo, vuelo de

ida o one way, mientras que R/T significa viaje redondo o round trip.)

Un vuelo contiene multiples reservaciones.

Una reservacion se relaciona con multiples vuelos.

Un vuelo tiene un aeropuerto de destine.

Un vuelo tiene un aeropuerto de origen.

Un vuelo puede hacer escalas en multiples aeropuertos.

Un vuelo contiene multiples tarifas de ida y vuelta.

Un vuelo contiene multiples tarifas solamente de ida.

Un vuelo se efectua en multiples aviones (dependiendo del dfa).

Multiples vuelos se efectuan en un mismo avion (en diferente memento).

Un vuelo tiene multiples asientos.


Un vuelo tiene multiples horarios de llegada (correspondiendo a diferentes destines).

Un vuelo tiene multiples horarios de salida (correspondiendo a diferentes escalas).

Un pasajero puede acumular millas en multiples cuentas de viajero frecuente.

Un pasajero efectua multiples reservaciones.

Multiples pasajeros pueden pertenecer a una misma reservacion.

Multiples reservaciones pueden requerir de un mismo registro de tarjeta de credito.


Un vuelo puede tener multiples conexiones.


T•r En el caso de los objetos borde que se comunican con usuarios humanos•r C•r En el caso de los objetos bord

A•r En el caso de los objetos borde que se comunican co

Se extiende el diagrama de clases con asociaciones y roles, para incluir multi-plicidad, como se muestra en la figura 6.35.

Figura 6.35 Diagrama de clases con asociaciones, roles y multiplicidad entre clasesidentificadas. Se omiten los nombres de las asociaciones.

6.5.3 Identification de atributosDe manera similar a las asociaciones, se pueden determinar los atributos deldominio del problema. Este proceso tiene una complejidad similar al de iden-tificacion de las asociaciones. Sin embargo, identificar atributos puede resultarmas dificil si se hace a traves de un proceso de busqueda a partir de la des-cripcion del problema, e incluso del documento de casos de uso. En lugar deesto, simplemente se identifican nuestros propios atributos para las distintas cla-ses identificadas en el dominio del problema del sistema de reservaciones, comose muestran en la tabla 6.7.

Nuevamente, este proceso de identificacion es sencillo cuando el problema eslimitado y el dominio es facil de analizar. De lo contrario, se requiere un pro-ceso de identificacion mucho mas extenso como veremos en la etapa de diseno.No es necesario listar todos los atributos, solamente los atributos mas relevan-tes, omitiendo atributos menores.


Tabla 6,7 Atributos identtficados para las clases ctei sisterrii dereservaciones de vuelo.

Clases

Vuelo

Reservation

Registroilsuario

Horario

Aerolinea

Aeropuerto

Tarifa

Asiento

Pasajero

RegistroTarjeta

Avion

ViajeroFrecuente

Atributos

Numero.

Clave.

Nombre, Direction, Co/on/a, Ciudad, Pais, Codigo Postal,Telefono casa, Telefono oficina, Fax, Email, Login,Password.

Dia, Hora.

Nombre.

Nombre, Ciudad, Pais.

Clase, Precio, Impuestos.

Fila, Letra.

Nombre.

Nombre, Numero, Expedidor, Vencimiento.

Fabricante, Modelo.

Numero, Aerolinea.

DlAGRAMA DE CLASES CON ATRIBUTOS

Se extiende el diagrama de clases con asociaciones, roles y multiplicidad, paraincluir los atributos principales, como se muestra en la figura 6.36.

6.5.4 Diccionario de clasesEl diccionario de clases o diccionario de datos, describe textualmente lasclases identificadas durante el modelo del dominio del problema. Este diccio-nario sirve como un glosario de terminos y se muestra a continuacion.

Vuelo: se denomina por medio de un numero. El vuelo tiene como origenun aeropuerto en una ciudad y tiene como destino un aeropuerto de otraciudad. Un vuelo puede tener multiples escalas, y diversos vuelos se rela-cionan por medio de conexiones. El vuelo pertenece a una aerolmea ypuede operar varios dias a la semana, con un horario de salida y otro dellegada.Reservacion: para poder tomar un vuelo, es necesario contar con una re-servacion previa, la cual debe pagarse antes de una fecha limite, incluso elmismo dia del vuelo. Una reservacion puede hacerse para multiples vuelosy distintos pasajeros. La reservacion cuenta con una clave que correspondea un record de reservacion particular.RegistroUsuario: para poder utilizar el sistema de reservaciones, el usua-rio debe estar registrado en el. El registro contiene informacion acerca delusuario como nombre, direccion, colonia, ciudad, pais, codigo postal, tele-fono de casa, telefono de oficina, fax, email, login y password.


Figura 6.36 Diagrama de clases con asociaciones, roles, multiplicidad y atributospara clases identificadas. Se omiten los nombres de las asociaciones y solo se

muestran los atributos mas relevantes.

Horario: el horario de un vuelo se determina por su hora de salida y dellegada durante los dias que opera.Aerolinea: la aerolinea provee varios vuelos entre diferentes ciudades bajodiversos horarios. La aerolinea 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 pais determinado.Tarifa: un mismo vuelo puede contar con diferentes tarifas, que varian se-gun la clase de boleto, si son de viaje sencillo o viaje redondo, y depen-diendo de las restricciones y ofertas existentes.


Asiento: una reservacion de vuelo puede incluir la asignacion de asiento,especiflcada mediante una fila y un numero. El numero de asientos dispo-nibles en un vuelo dependen del tipo de avion que opere ese dia.Pasajero: para hacer una reservacion, se requiere dar el nombre del pasa-jero. Varios pasajeros pueden aparecer bajo una sola reservacion.RegistroTarjeta: para pagar con una tarjeta de credito, se debe tener unregistro de tarjeta. El registro contiene informacion acerca de la tarjeta, in-cluyendo nombre, numero, expedidor y vencimiento. La tarjeta esta ligadaa un registro de usuario.Avion: un vuelo en una fecha determinada se hace en un tipo de avion enparticular. El tipo de avion define la cantidad maxima de pasajeros que pue-den viajar en ese vuelo para esa fecha.ViajeroFrecuente: el pasajero tiene la opcion de acumular millas para unvuelo, si cuenta con una tarjeta de viajero frecuente de la aerolinea corres-pondiente.

6.5.5 Identification de ModulesEl modelo del dominio del problema, puede hacerse bastante complejo en elcaso de un sistema de gran tamano, para lo cual es necesario separar las cla-ses en modules. De tal manera, el modelo completo se dividiria en una colec-cion de modulos, donde cada modulo es una agrupacion logica de clases y susasociaciones correspondientes. Para el sistema de reservaciones de vuelo, sepueden identificar dos modulos principales del dominio del problema, de acuer-do con la relacion logica entre las clases. Estos modulo son, Registro, que contie-ne las clases que guardan informacion sobre el usuario del sistema; y Servicios,que contiene las clases que guardan informacion sobre los vuelos, pasajeros yreservaciones. En otras palabras, las clases para el modulo de registro se rela-cionan con la utilizacion del sistema ligadas al actor Base de Datos de Registro,mientras que las clases para el modulo de servicios se relacionan con el pro-pio sistema de reservaciones, ligadas al actor Base de Datos de Reservaciones.La razon de separar en dos modulos, va muy de la mano con la existencia deestos dos actores secundarios, ya que al corresponder cada actor secundario auna base de datos, los modulos afianzan esta correspondencia. Sin embargo,esto no tiene por que ser realmente asi, pudiendo existir un solo modulo paraun sistema con multiples actores secundarios, o incluso varios modulos por cadaactor secundario. A continuacion describimos los modulos para el sistema dereservaciones de vuelo.

SERVICIOS

En la figura 6.37 se muestran las clases pertenecientes al modulo de Serviciosdel sistema de reservaciones.


Figura 6.37 Diagrama de clases para el mbdulo de Servicios del sistema dereservaciones de vuelo.

REGISTRO

En la figura 6.38 se muestra las clases pertenecientes al modulo de Registro delsistema de reservaciones.

Figura 6.38 Diagrama de clases para el modulo de Registro del sistema dereservaciones de vuelo.


Documents

6.5. Modelo Del Dominio Del Problem