Embed Size (px)
Citation preview
Modelado conceptual e Implementación de un Sistema de Venta de Entradas
Silvia Belda Jañez [email protected]
Director del proyecto: Emilio Insfrán Pelozo
2
3
Índice
ÍNDICE............................................................................................................................ 3
1. INTRODUCCIÓN................................................................................................. 5
1.1. Objetivos ......................................................................................................... 5 1.2. Estructura del proyecto ................................................................................... 6 1.3. Descripción del caso de estudio ..................................................................... 7
2. MODELO DE REQUISITOS................................................................................. 10
2.1. Árbol de refinamiento de funciones .............................................................. 10 2.2. Diagramas de casos de uso ......................................................................... 12 2.3. Diagramas de secuencia .............................................................................. 19
3. MODELO CONCEPTUAL .................................................................................. 45
3.1. Modelo de objetos......................................................................................... 45 3.2. Modelo dinámico........................................................................................... 58 3.3. Modelo funcional........................................................................................... 63
4. DISEÑO DE LA BASE DE DATOS RELACIONAL ................................................ 67
5. DESCRIPCIÓN DE LA IMPLEMENTACIÓN........................................................ 74
6. CONCLUSIONES .............................................................................................. 87
ÍNDICE DE FIGURAS..................................................................................................... 89
BIBLIOGRAFÍA.............................................................................................................. 93
4
5
1. Introducción
El proyecto propuesto se sitúa en el ámbito de la Ingeniería de Requisitos
para el desarrollo de Sistemas de Información, y tiene como objetivo
fundamental generar la tecnología necesaria para la construcción del modelo
conceptual a partir de los modelos de requisitos y finalmente el diseño de una
aplicación. Esta tecnología hará confluir los esfuerzos y resultados de iniciativas
académicas anteriores, aplicándose a la resolución de un caso real de
suficiente complejidad. El proceso de construcción se iniciará con la
elaboración de un Modelo de Requisitos que estará guiado por el
comportamiento deseado del sistema (propiedades externas), y que será el
origen para la construcción de modelos conceptuales (propiedades internas)
y del diseño del software.
1.1. Objetivos
Los objetivos a cumplir por el presente proyecto se estructuran en los
siguientes puntos:
• Validar el modelo de requisitos a través de la elaboración de un caso
de estudio.
• Capturar todas las propiedades del sistema (estáticas y dinámicas)
mediante un modelado conceptual.
• Realizar la aplicación del caso de estudio analizado.
6
1.2. Estructura del proyecto
Después de la Introducción, el documento está organizado de la
siguiente forma:
• El capítulo 2 está dedicado al modelo de requisitos. Se
capturarán los requisitos del sistema para poder generar, en
primer lugar, el árbol de refinamiento de funciones donde se
establece la misión del sistema. En segundo lugar se mostrarán los
diagramas de casos de uso generados y por último se presentan
los diagramas de secuencia como una herramienta para
identificar y asignar responsabilidades.
• En el capítulo 3 se presenta el modelado conceptual del sistema
mediante OO-Method. OO-Method utiliza el modelo de objetos,
el dinámico y funcional. Estos tres modelos describen la sociedad
de objetos desde tres puntos de vista complementarios y definen
la arquitectura del modelo Conceptual.
• El capítulo 4 se centra en la creación y diseño de la base de
datos relacional que se utilizará en la aplicación del sistema. El
diseño de la base de datos consiste en mapear un modelo de
objetos obtenido en fase de análisis con sus correspondientes
tablas relacionales.
• El capítulo 5 muestra la interfaz que se ha creado para la
aplicación. Se realiza una descripción de forma detallada de la
implementación realizada.
• En el capítulo 6 se comentan las conclusiones a las que se ha
llegado en la realización de este proyecto.
7
1.3. Descripción del caso de estudio
Se desea desarrollar una aplicación que permita la venta de entradas
de conciertos del Palau de la Música de Valencia en las taquillas del Palau y a
través de Internet.
Se debe distinguir entre tres tipos de usuarios de la aplicación:
administradores, taquilleros e internautas. Los primeros se encargarán de las
labores de mantenimiento de la información disponible, los taquilleros podrán
realizar las ventas de las entradas en las taquillas del Palau y de la recepción
de reservas y los internautas serán los usuarios que se conecten a la página
web del Palau y que podrán realizar sus compras de entradas desde casa y
recogerlas en las taquillas antes de que empiece el concierto.
El Palau está dividido en diversas salas de audición, donde se realizan los
conciertos. Se pueden realizar varios conciertos el mismo día a la misma hora
en distintas salas.
Dentro de cada sala existen varios tipos de entradas o localidades,
variando el precio y el número de plazas. Las plazas no están numeradas y el
precio de las localidades es distinto para cada concierto.
Un comité artístico se encarga de planificar y contratar los conciertos
para cada temporada, abarcando esta desde octubre hasta junio. A principio
de septiembre se introduce todas la información sobre los conciertos de la
próxima temporada, pudiéndose desde ese momento adquirir entradas para
cualquiera de ellos.
Desde que los conciertos salen a la venta, se conocen para cada uno
de los tipos de entradas los precios y el número de localidades disponibles.
Venta de entradas
A la hora de realizar una venta por taquilla, el comprador indica al
personal de las taquillas el concierto deseado (sala, fecha y hora), el número
de entradas y el tipo de localidad elegido (palco, anfiteatro, coro). Cuando el
comprador ha pedido entradas para todos los conciertos que quiere, se
8
acepta la compra y se descuentan las entradas de las disponibles, siempre
que haya suficientes entradas disponibles. Esta compra se debe pagar en el
acto utilizando efectivo o tarjeta de crédito.
Para realizar una compra por Internet el procedimiento es el mismo, la
única diferencia es que el pago debe realizarse por medio de una transacción
segura utilizando tarjeta de crédito. El Palau no debe tomar parte en la
transacción electrónica, que debe ser realizada por el cliente y una entidad
financiera independiente (manteniendo la confidencialidad de sus datos
financieros) que notificará al Palau el éxito de la transacción antes de que sea
confirmada la venta. El usuario deberá identificarse (DNI, nombre, dirección y
teléfono) para poder recoger las entradas en las taquillas del Palau antes del
concierto.
Abonos de temporada
Otra posibilidad que el Palau ofrece a sus clientes es la compra de
abonos. Un abono consiste en la compra de entradas para tres conciertos en
una misma temporada. Los conciertos del abono los elige el cliente con una
única restricción, que todas las entradas del abono deberán ser para el mismo
tipo de localidad (será un abono de palco, de coro, de anfiteatro,...). La
ventaja que suponen frente a la compra de entradas sueltas, es un descuento
del 10% sobre el precio fijado para esa localidad.
El mecanismo para comprar un abono tanto en taquilla como a través
de Internet es el mismo: se van eligiendo los conciertos que se incluirán en el
abono y cuando se confirma el abono, se elige el tipo de localidad deseada
para todos los conciertos. Si quedan localidades libres de ese tipo para todos
los conciertos seleccionados, se da de alta el abono, si no se indica el
concierto para el que no existe localidad. El proceso de pago, tanto para
ventas en taquilla como para ventas por Internet, será el mismo que se utiliza
en la venta de entradas.
9
Reservas de localidades
Desde la temporada pasada se ha puesto en marcha un sistema de
reserva de localidades que permite a los clientes hacer reservas telefónicas de
entradas para conciertos. Cuando un cliente llama, se solicitan sus datos
personales (DNI, nombre, dirección y teléfono), así como el concierto, el tipo
de localidad y el número de entradas que quiere reservar. Si hubiera
suficientes entradas libres, se aceptará la reserva.
Las entradas reservadas se pueden recoger hasta 2 horas antes del
concierto en las taquillas del Palau mostrando el DNI, no pudiendo recoger
más entradas de las reservadas. Cuando se recogen, las entradas reservadas
se consideran vendidas y se marcan las reservas como recogidas.
Un cliente no puede reservar más de ocho entradas por tipo de
localidad para un concierto. Todas las reservas que no se hayan recogido dos
horas antes del concierto serán canceladas y las entradas reservadas pasarán
a estar disponibles.
Siempre existe la posibilidad de cancelar una reserva, incluso
telefónicamente, si el cliente se identifica adecuadamente. En ese caso todas
las entradas que se habían reservado pasan a estar disponibles.
Decisiones técnicas
La dirección del Palau ha tomado las siguientes decisiones técnicas:
No es posible anular una venta ni un abono bajo ningún concepto.
Cuando se esté trabajando a través de Internet, en la misma sesión,
debe ser posible realizar todas las compras y todos los abonos que el usuario
desee.
Las reservas únicamente podrán realizarse telefónicamente, nunca en
taquillas directamente ni por Internet, pero sólo podrán ser atendidas por
personal de taquillas.
10
2. Modelo de requisitos
El modelo de requisitos contiene una descripción de los objetivos y del
comportamiento externo del sistema, es decir, qué debe hacer el sistema sin
describir cómo debe hacerlo. En este modelo se consideran los aspectos
funcionales, de comunicación y comportamiento a alto nivel.
2.1. Árbol de refinamiento de funciones
El árbol de refinamiento de funciones está asociado con los objetivos
que el sistema pretende alcanzar. Particiona la funcionalidad del sistema en
interacciones externas y lo muestra de forma jerárquica como el resultado de
un refinamiento del objetivo del sistema. No especifica las interacciones
internas o las relaciones que se establecen entre las distintas funciones.
La raíz es la misión del sistema. Los nodos intermedios son grupos de
funciones elementales y normalmente representan un tipo de actividad o un
área de negocio y las hojas son las funciones elementales del sistema.
Con la lista de funcionalidades hemos elaborado un Árbol de
Refinamiento de Funciones (ARF). Para mayor claridad, el A.R.F. ha sido
organizado en forma indexada, quedando tal y como se muestra a
continuación:
Nodo raíz: Sistema de ventas
1. Mantenimiento información 1.1. Datos melómano
1.1.1. Crear melómano 1.1.2. Actualizar melómano 1.1.3. Eliminar melómano
1.2. Datos Sala 1.2.1. Crear sala 1.2.2. Modificar sala 1.2.3. Eliminar sala
1.3. Datos Zona (partes de una sala) 1.3.1. Crear zona 1.3.2. Modificar zona 1.3.3. Eliminar zona
11
1.4. Datos Intérprete 1.4.1. Crear intérprete 1.4.2. Modificar intérprete 1.4.3. Eliminar intérprete
1.5. Datos obra 1.5.1. Crear obra 1.5.2. Modificar obra 1.5.3. Eliminar obra
1.6. Datos concierto 1.6.1. Crear concierto 1.6.2. Modificar concierto 1.6.3. Eliminar concierto
2. Compra Abonos
2.1. Crear cesta abono 2.2. Confirmar cesta abono 2.3. Borrar línea abono 2.4. Eliminar cesta abono 2.5. Recoger abono internet
3. Reserva telefónicas
3.1. Crear reserva 3.2. Modificar línea reserva 3.3. Borrar línea reserva 3.4. Cancelar reserva 3.5. Recoger reserva
4. Venta entradas
4.1. Crear cesta venta 4.2. Modificar línea venta 4.3. Confimar cesta venta 4.4. Borrar linea venta 4.5. Eliminar cesta venta 4.6. Recoger entradas internet
5. Usuarios
5.1. Crear usuario 5.2. Modificar usuario 5.3. Eliminar usuario
12
2.2. Diagramas de casos de uso
El siguiente paso, consiste en transformar las funciones contenidas en el
ARF en casos de uso (C.U.), agrupándolos según la organización de los
paquetes y construyendo diagramas de casos de uso (D.C.U.), en los cuales
surgen relaciones entre los casos de uso, actores, relaciones entre actores,
relaciones entre casos de uso y actores, etc.
Los diagramas de casos de uso muestran las funciones del sistema y las
comunicaciones externas. Representan una interacción entre el sistema y el
entorno(entidad externa).
A continuación mostramos los diagramas de casos de uso
correspondientes a cada uno de los paquetes anteriores:
Vista del caso de uso general: vemos representados los cinco paquetes
principales en los que se han distribuido las funciones, como son:
Mantenimiento info, Compra abonos, Reserva telefónica, Venta entradas, y
Usuarios.
Compraabonos
Reserva telefonica
Ventaentradas
Usuarios
Mantenimiento info
Figura 1: Vista del caso de uso general
1. Mantenimiento info: aquí están incluídos los paquetes relacionados
con el mantenimiento de la información del sistema: Datos melomano, Datos
sala, Datos zona, Datos interprete, Datos obra y Datos concierto.
13
Datos sala Datos zona
Datos interprete
Datos obra
Datos melomano
Datosconcierto
Figura 2: Mantenimiento info
1.1. Datos melómano: como su propio nombre indica es la gestión de los
melómanos. Los melómanos son los usuarios que compran abonos por Internet
o entradas por Internet y realizan reservas.
El taquillero, encargado de realizar la gestión de los melómanos, es el
que directamente pondrá en funcionamiento los casos de uso que se
observan en el diagrama de casos de uso.
Crear melomano
Actualizar melomano Eliminar melomano
Taquillero
Figura 3: Datos melomano
1.2. Datos sala: en este caso nos referimos a la gestión de las salas. Las
salas es el lugar donde se realizan las representaciones de los conciertos que
se contratan en el Palau de la Música.
Los casos de uso Crear sala, Modificar sala y Eliminar sala incluyen los
casos de uso Crear zonas, Modificar zonas y Eliminar zonas respectivamente.
Vuelve a ser el administrador el actor encargado de realizar estas gestiones.
14
<<include>>
<<include>>
Crear zonas(from Datos zona)
Modificar zonas (from Datos zona)
Crear sala
Modificar salaAdministrador
Eliminar zonas
(from Datos zona)
Eliminar sala
<<include>>
Figura 4: Datos sala
1.3. Datos zona: en este caso nos referimos a la gestión de las zonas, que
son las partes en las que se divide una sala. El administrador el actor
encargado de realizar estas gestiones.
Crear zonas
Modificar zonas
Eliminar zonas
Administrador
Figura 5: Datos zona
1.4. Datos interprete: es el administrador el encargado de realizar el
mantenimiento de los datos de los intérpretes. Los intérpretes son las orquestas,
directores y solistas que intervienen en los conciertos.
Como podemos ver podremos tanto crear un intérprete, como
modificarlo o eliminarlo.
15
Crear interprete
Modificar interprete
Eliminar interprete
Administrador
Figura 6: Datos interprete
1.5. Datos obra: gestiona el mantenimiento de los datos relacionados
con una obra. El actor encargado de realizar esta gestión es, nuevamente, el
administrador del sistema.
Crear obra
Modificar obra
Eliminar obra
Administrador
Figura 7: Datos obra
1.6. Datos concierto: gestión de los datos relacionados con la
representación de un concierto. Los conciertos son las representaciones que se
realizan en el Palau de la Música.
El administrador podrá crear las representaciones de los conciertos y
asignarles la obra, los intérpretes y la sala, modificar los datos de los que ya
existen o eliminarlos. A continuación mostramos el diagrama de casos de uso
correspondiente a la gestión de conciertos:
16
Crear concierto
Modificar concierto
Eliminar concierto
Administrador
Figura 8: Datos concierto
2. Compra abonos: en este paquete se realizan todas las operaciones
relacionadas con la compra de un abono. Un abono consiste en la compra de
entradas para tres conciertos en una misma temporada.
El taquillero podrá crear una cesta de abono con sus líneas
correspondientes, confirmar la cesta de abono realizando el cobro de la
misma o borrar una línea de abono. El internauta realizará las mismas
operaciones desde su conexión a Internet con la diferencia que el pago debe
realizarse mediante tarjeta de crédito. La operación de recoger el abono
comprado a través de Internet se realizará únicamente a través del taquillero
del Palau.
El administrador será el encargado de eliminar las cestas de los abonos.
Eliminar Cesta Abono Administrador
Recoger abono internet Taquillero
Crear cesta abono
Confirmar Cesta Abono
Internauta
Borrar linea abono
Figura 9: Compra abonos
17
3. Reserva telefónica: todas las funciones relacionadas con la reserva
telefónica de entradas las realiza el taquillero. La reserva telefónica es un
sistema que permite a los clientes hacer reservas telefónicas de entradas para
los conciertos que se van a celebrar.
El taquillero es el encargado de crear una reserva con sus
correspondientes líneas de reserva, modificar o eliminar una línea de reserva,
cancelar una reserva mediante la identificación del cliente y atender la
recogida de las reservas en taquilla y realizar el cobro de las mismas.
Cancelar reservaRecoger reserva
Crear reserva
Borrar linea reserva
Modificar linea reserva
Taquillero
Figura 10: Reserva telefónica
4. Venta entradas: en este paquete se realizan todas las operaciones
relacionadas con la compra de entradas.
El taquillero podrá crear una cesta de venta con sus líneas
correspondientes, confirmar la cesta de venta realizando el cobro de la
misma, modificar o borrar una línea de venta. El internauta realizará las mismas
operaciones desde su conexión a Internet con la diferencia que el pago debe
realizarse mediante tarjeta de crédito. La operación de recoger las entradas
compradas por Internet se realizará únicamente a través del taquillero del
Palau.
El administrador será el encargado de eliminar las cestas de ventas de
entradas.
18
Eliminar cesta venta Administrador
Recoger entradas internet Taquillero
Crear cesta venta
Confirmar cesta venta
Modificar linea venta Internauta
Borrar linea venta
Figura 11: Venta entradas
5. Usuarios: gestión de los datos relacionados con los usuarios de la
aplicación. Estos usuarios son los administradores, taquilleros e internautas que
son los actores del sistema.
El administrador podrá crear un nuevo usuario (un taquillero o
administrador), modificar los datos de los que ya existen o eliminarlos. A
continuación mostramos el diagrama de casos de uso correspondiente a la
gestión de usuarios:
Crear usuario
Modificar usuario
Eliminar usuario
Administrador
Figura 12: Usuarios
19
2.3. Diagramas de secuencia
Si nos paramos a observar cualquiera de los diagramas de casos de uso,
observaremos que continuamos teniendo funcionalidades que tan sólo
conocemos a un nivel de abstracción alto. Es el caso de los casos de uso, los
cuales no están especificados. Para ello haremos uso de los diagramas de
secuencia, en donde ya podremos observar en que consiste cada uno de los
casos de uso incluidos en los diagramas anteriores. Así utilizaremos los
diagramas de secuencia como una herramienta para identificar y asignar
responsabilidades.
Los diagramas de secuencia (D.S.), los vamos a presentar en el mismo
orden en el que se presentaron los diagramas de casos de uso. En primer lugar
se muestran los diagramas de secuencia incluidos en los subpaquetes de
Mantenimiento info que están relacionados con el mantenimiento de la
información del sistema. Básicamente son altas, bajas y modificaciones de
melómanos, salas, zonas, interpretes, obras y conciertos. Y son los siguientes:
1.1.1. DS Crear melómano: creación de nuevos objetos de la clase
Melómano de acuerdo a unos valores que el actor proporciona. Supone el
alta de un nuevo melómano que podrá comprar entradas, abonos o realizar
reservas telefónicas(Figura 13).
1.1.2. DS Actualizar melómano: función dedicada a la actualización de
los datos de los melómanos. Utiliza como parámetros el nombre, los apellidos,
la dirección y el teléfono. En la figura 14 podemos ver el diagrama de
secuencia correspondiente a la actualización.
20
: Taquillero : Sistema : Melomano
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>new
Solicitar crear melomano
Solicitar DNI melomano
Introducir DNI melomano
Solicitar datos
Introducir datos
existe?
Crear melomano( )
Figura 13: DS Crear melomano
: Taquillero
: Sistema : Melom ano
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<query>>
<<service>>update
Solicitar actualizar melomano
Mostrar lista m elom anos(Lista)
Seleccione melom ano
Seleccionar m elom ano
Mostrar datos(Datos)
Modifique melomano
Modificar melomano
Lista=listar m elom anos
Datos=m ostrar datos(dni)
Actualizar m elom ano(String, String, String)
Figura 14: DS Actualizar melomano
21
1.1.3. DS Eliminar melómano: supone la eliminación de un objeto de la
clase melómano. Su diagrama de secuencia es el que se muestra en la
siguiente figura:
: Taquillero
: Sistema : Melomano
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Solicitar eliminar melomano
Mostrar lista melomanos(Lista)
Seleccione melomano
Seleccionar melomano
Lista=listar melomanos
Eliminar( )
Figura 15: DS Eliminar melomano
1.2.1. DS Crear sala: en el siguiente diagrama de secuencia se puede
observar como se produce la creación de un objeto de la clase Sala. Al
crearse una sala se crean también sus zonas correspondientes como puede
verse a continuación:
22
: A d m in is tra d o r : S is te m a : S a la
< < s ig n a l> >
< < s ig n a l> >
< < s ig n a l> >
< < s e rv ic e > > n e w
S o lic ita r c re a r s a la
S o lic ita r d a to s
In tro d u c ir d a to s
C re a r_ s a la ( )
U C _ C re a r zo n a s
Figura 16: DS Crear sala
1.2.2. DS Modificar sala: modifica la descripción de una sala y la de sus
zonas, mediante UC_Modificar zonas. Utiliza como parámetro los atributos
nombre y descripción.
: A d m in is tra d o r
: S is te m a : S a la
< < s ig n a l> >
< < s ig n a l> >
< < s ig n a l> >
< < s ig n a l> >
< < s ig n a l> >
< < s ig n a l> >
< < s ig n a l> >
< < q u e ry > >
< < q u e ry > >
< < s e rv ic e > > u p d a te
S o lic ita r m o d ific a r s a laL is ta = lis ta r s a la s
M o s tra r lis ta s a la s (L is ta )
S e le c c io n e s a la
S e le c c io n a r s a la
D a to s = m o s tra r d a to s (id )
M o s tra r d a to s (D a to s )
M o d ifiq u e s a la
M o d ific a r s a la
M o d ific a r_ s a la (S tr in g )
U C _ M o d ific a r zo n a s
Figura 17: DS Modificar sala
23
1.2.3. DS Eliminar sala: se trata de la eliminación de los objetos de la
clase Sala, así como de las zonas asociadas a dicha sala(UC_Eliminar zonas):
: Administrador
: Sistema : Sala
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Solicitar eliminar salaLista=listar salas
Mostrar lista salas(Lista)
Seleccione sala
Seleccionar sala
Eliminar_sala( )
UC_Eliminar zonas
Figura 18: DS Eliminar sala
1.3.1. DS Crear zonas: se trata de la creación de objetos de la clase
Zona correspondientes a una sala, por eso, como vemos en el diagrama de
secuencia, es necesario especificar el identificador de la sala.
: Zona : Administrador
: Sistema : Sala
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>new
Solicitar crear zona
Solicitar tipo ona
Introducir tipo ona
Solicitar datos
Introducir datos
Crear_zona( )
Introducir id sala<<signal>> existe?
Figura 19: DS Crear zonas
24
1.3.2. DS Modificar zonas: modifica los datos de las zonas de una sala.
Utiliza como parámetros los atributos Num_plazas y descripción. El diagrama
de secuencia es el siguiente:
: Administrador
: Sistema : Zona : Sala
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<query>>
<<service>>update
Solicitar modificar zona
Mostrar lista zonas(Lista)
Seleccione zona
Seleccionar zona
Mostrar datos(Datos)
Modifique zona
Modificar zona
Lista=listar zonas
Datos=mostrar datos(tipo)
Modificar_zona(Integer, String)
Introducir id sala
existe?
<<query>>
<<signal>>
Figura 20: DS Modificar zonas
1.3.3. DS Eliminar zonas: mediante este diagrama de secuencia se
eliminan las zonas de la sala facilitada mediante su identificador:
25
: Administrador
: Sistema : Zona : Sala
Solicitar eliminar zona
Lista=listar zonas
Mostrar lista zonas(Lista)
Seleccione zona
Selecionar zona
Eliminar_zona( )
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Introducir id sala<<signal>> existe?
<<query>>
Figura 21: DS Eliminar zonas
1.4.1. DS Crear interprete: creación de nuevos objetos de la clase
Interprete de acuerdo a unos valores que el administrador proporciona.
Supone el alta de un nuevo interprete del que se solicitan datos como el
nombre y la descripción del mismo.
: Interprete : Administrador
: Sistema
<<signal>>
<<signal>>
<<signal>>
<<service>>new
Solicitar crear interprete
Solicitar datos
Introducir datos
Crear_interprete( )
Figura 22: DS Crear interprete
26
1.4.2. DS Modificar interprete: función dedicada a la modificación de los
datos de los intérpretes. El administrador es el encargado de iniciar la
operación. El sistema recuperará los intérpretes existentes y devolverá un
listado al administrador, quien elegirá cual desea modificar. Los datos que
pueden modificarse son el nombre y la descripción. A continuación podemos
ver el diagrama de secuencia correspondiente a la modificación:
: Administrador
: Sistema : Interprete
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<query>>
<<service>>update
Solicitar modificar interprete
Mostrar lista interpretes(Lista)
Seleccione interprete
Seleccionar interprete
Mostrar datos(Datos)
Modifique interprete
Modificar interprete
Lista=listar interpretes
Datos=mostrar datos(id)
Modificar_interprete(String, String)
Figura 23: DS Modificar interprete
1.4.3. DS Eliminar interprete: en la siguiente figura se muestra el diagrama
de secuencia correspondiente a la eliminación de un objeto de la clase
Interpréte. En primer lugar se solicita al sistema la acción de eliminar intérprete.
Éste devolverá una lista de los intérpretes que posee y se elegirá cual es el que
se desea eliminar. Finalmente el intérprete será eliminado. Todo este proceso
puede verse en la figura que se muestra a continuación:
27
: Administrador
: Sistema : Interprete
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Solicitar eliminar interprete
Mostrar lista interpretes(Lista)
Seleccione interprete
Seleccionar interprete
Lista=listar interpretes
Eliminar_interprete( )
Figura 24: DS Eliminar interprete
1.5.1. DS Crear obra: en el siguiente diagrama de secuencia se puede
observar como se produce la creación de una nueva Obra. Los atributos que
se solicitan son el título y la descripción de la misma:
: Obra : Administrador
: Sistema
<<signal>>
<<signal>>
<<signal>>
<<service>>new
Solicitar crear obra
Solicitar datos
Introducir datos
Crear_obra( )
Figura 25: DS Crear obra
1.5.2. DS Modificar obra: el administrador modifica los datos de una
obra. Utiliza como parámetros los atributos nombre y descripción. El diagrama
de secuencia es el siguiente:
28
: Adm inistrador
: S istem a : O bra
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<query>>
<<service>>update
Solicitar m odificar obra
Mostrar lista obras(Lista)
Seleccione obra
Seleccionar obra
Mostrar datos(Datos)
M odifique obra
M odificar obra
Lista=listar obras
Datos=m ostrar datos(id)
M odificar obra(String)
Figura 26: DS Modificar obra
1.5.3. DS Eliminar obra: en el siguiente diagrama de secuencia se
observa la función de eliminar una obra. El administrador elimina la obra
facilitada mediante su identificador:
: Administrador
: Sistema : Obra
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Solicitar eliminar obra
Mostrar lista obras(Lista)
Seleccione obra
Seleccionar obra
Lista=listar obras
Eliminar obra( )
Figura 27: DS Eliminar obra
29
1.6.1. DS Crear concierto: creación de una nueva representación de un
concierto de acuerdo a unos valores que el actor proporciona.
El administrador es el encargado de iniciar el proceso de creación de
un nuevo concierto. Se elegirá cual es la obra que se interprete, el intérprete
que interviene en ella y la sala donde se celebrará el evento. A continuación
se introducirán los datos relacionados con un concierto como son la fecha, la
hora y el precio para cada zona. La siguiente figura muestra como lo
explicado anteriormente:
: Administrador
: Sistema : Concierto : Obra : Interprete : Sala
<<signal>>
<<signal>>
<<signal>>
<<service>>new
Solicitar crear concierto
Solicitar datos
Introducir datos
Crear concierto( )
Seleccionar obra
<<select>>
Seleccionar interprete
Seleccionar sala <<select>>
<<select>>
Figura 28: DS Crear concierto
1.6.2. DS Modificar concierto: función dedicada a la modificación de los
datos de los conciertos. El administrador es el actor encargado de esta labor.
Se pide al sistema el listado de conciertos y se elige el concierto que se desea
modificar. Una vez modificados los datos necesarios se registran los cambios en
la base de datos.
A continuación podemos el diagrama de secuencia correspondiente a
la modificación:
30
: Administrador
: Sistema : Concierto
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<query>>
<<service>>update
Solicitar modificar concierto
Mostrar lista conciertos(Lista)
Seleccione concierto
Seleccionar concierto
Mostrar datos(Datos)
Modifique datos
Modificar datos
Lista=listar conciertos
Datos=mostrar datos(id)
Modificar concierto( )
Figura 29: DS Modificar concierto
1.6.3. DS Eliminar concierto: en la siguiente figura se muestra el diagrama
de secuencia correspondiente a la eliminación de la representación de un
concierto:
: Administrador
: Sistema : Concierto
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Solicitar eliminar concierto
Mostrar lista conciertos(Lista)
Seleccione concierto
Seleccionar concierto
Lista=listar conciertos
Eliminar concierto( )
Figura 30: DS Eliminar concierto
31
Los siguientes diagramas de secuencia corresponden al paquete de
Compra abonos, en este paquete se realizan todas las operaciones
relacionadas con la compra de un abono.
2.1. DS Crear cesta abono: El siguiente diagrama de secuencia muestra
la creación de una cesta de abono. El abono puede comprarse en taquilla o
por Internet. Si la compra se realiza en taquilla el taquillero será el que realice
las acciones de crear la cesta junto con sus líneas de abono de manera que se
irán seleccionando los conciertos que se incluirán en el abono y por último la
zona para todos ellos. Para finalmente comunicar al usuario el precio del
mismo.
Si la compra es por Internet es el internauta el actor que se encarga de
realizar las acciones citadas anteriormente, y además deberá registrarse y
facilitar sus datos personales para posteriormente poder recoger su abono en
taquilla.
El diagrama es el siguiente:
: Taquillero
: Sistema : Melomano : Linea Abono
: Concierto : Zona : Cesta Abono : Internauta
si (actor = internauta)
<<select>> Loop
<<select>>
End Loop
<<signal>>
<<signal>>
<<signal>>
<<service>>new
<<service>>new
<<query>
Solicitar crear abono
Introducir datos cliente
Solicitar datos cliente
Mostrar Precio
Seleccionar concierto
Crear cesta abono( )
Seleccionar melomano
Crear linea abono( )
Seleccionar zona <<select>>
PrecioUnitario=obtener i <<query>> Precio=obtener
Precio final
<<signal
Figura 31: DS Crear cesta abono
32
2.2. DS Confirmar cesta abono: para la confirmación de la cesta de un
abono el taquillero comprueba si quedan localidades libres de ese tipo para
todos los conciertos seleccionados, en caso afirmativo se efectúa el cobro del
abono, ya sea en efectivo o mediante una transacción electrónica. Por último
se da de alta dicho abono.
En el caso que el abono se esté comprando por Internet, el actor del
sistema será el internauta y el pago del abono se realizará solamente
mediante una transacción electrónica, que debe ser realizada por el cliente y
una entidad financiera independiente (manteniendo la confidencialidad de
sus datos financieros) que notificará al Palau el éxito de la transacción antes
de que sea confirmada la venta.
A continuación se presenta el diagrama de secuencia:
: Taquillero
: Sistema : Cesta Abono
: Concierto : Abono internet
: Internauta : Entidad financiera
SI (pago con tarjeta de credito) (actor=internauta)
SI pago en efectivo
<<signal>
<<signal>
<<signal>
<<query>>
<<query>
<<signal>
<<signal>
<<signal>
<<signal>
<<signal>
<<signal>
<<service>>update
<<service>>update
<<service>>update
Solicitar confirmar abono
Realice pago
Mostrar Precio
Introducir num_tarjeta
Realizar pago efectivo
Seleccione abono
Seleccionar abono
Aceptar cesta abono( )
Obtener info abono
Comprobar si existe disponibilidad
Modif atrib vendidos( )
[if actor=internauta]Incrementar Abono Internet( )
Enviar pago(num_tarjeta,Precio)
Transaccion correcta
Figura 32: DS Confirmar cesta abono
33
2.3. DS Borrar línea abono: Permite borrar la línea de un abono. En el
caso de que el abono haya sido comprado en taquilla el actor del diagrama
será el taquillero, si es un abono de Internet el actor será el internauta. Primero
se selecciona el abono y después la línea del abono que se quiere eliminar. El
diagrama es el que se muestra a continuación:
: Linea Ab
: Taquillero
: Sistema
: Internauta
: Cesta Ab
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
<<signal>>
Solicitar borrar linea abono
Mostrar lista abonos(Lista)
Seleccione abono
Seleccionar linea abono
Seleccionar linea abono
Borrar linea abono( )
Lista=listar abonos
Figura 33: DS Borrar linea abono
2.4. DS Eliminar cesta abono: función dedicada a la eliminación de una
cesta de abono, ya sea comprada en taquilla o por Internet. El actor
encargado de realizarlo es el administrador del sistema.
<<signal>>
: Administrador
: Sistema : Cesta Abono
<<signal>>
<<signal>>
<<signal>>
<<service>>destroy
<<query>>
Solicitar eliminar abono
Mostrar lista abonos(Lista)
Seleccione abono
Seleccionar abono
Lista=listar abonos
Eliminar cesta abono( )
Figura 34: DS Eliminar cesta abono
34
2.5. DS Recoger abono Internet: el taquillero solicita los datos al
melómano que acude a taquilla para retirar el abono comprado por Internet.
Tras obtener su identificación comprueba la existencia del abono y le
proporciona el mismo. El diagrama queda de la siguiente manera:
: Taquillero
: Sistema : Melomano : Abono internet
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<select>><<signal>>
<<service>>update
Solicitar recoger abono
Introduzca DNI melomano
Introducir DNI melomano
Mostrar abono
existe?
[if Recogido=false]seleccionar abono
Recoger abono( )
Figura 35: DS Recoger abono internet
Los siguientes diagramas de secuencia corresponden al paquete de
Reserva telefónica, en este paquete se realizan todas las operaciones
relacionadas con la reserva de entradas.
3.1. DS Crear reserva: Cuando un melómano llama, se solicitan sus datos
personales (DNI, nombre, dirección y teléfono), así como el concierto, la zona
de la sala que desea y el número de entradas que quiere reservar. Todas estas
acciones son realizadas por el taquillero quien también se encarga de informar
al cliente del precio total de la reserva. El diagrama de secuencia se muestra a
continuación:
35
: Taquillero
: Sistema : Melomano : Linea reserva : Concierto : Zona : Reserva
<<select> Loop
<<select>
<<select>
End Loop
<<signal>
<<signal>
<<signal>
<<signal>
<<signal>
<<service>>new
<<service>>new
<<query>
<<query>
Solicitar crear venta
Introducir datos cliente
Solicitar datos cliente
Introducir cantidad
Mostrar PrecioReserva
Seleccionar concierto
PrecioUnitario=obtener precio
Seleccionar zona
Crear reserva( )
Seleccionar melomano
Crear linea reserva( )
Calcular PrecioTotal linea
PrecioReserva
Figura 36: DS Crear reserva
3.2. DS Modificar línea reserva: función dedicada a la modificación de
los datos de una línea de una reserva. El taquillero pedirá un lista de las
reservas existentes en el sistema, y después elegirá cual es la línea de reserva
que quiere modificar. En la figura 37 puede verse el diagrama de secuencia
para modificar una línea de reserva.
3.3. DS Borrar línea reserva: Permite borrar la línea de una reserva.
Primero se selecciona la reserva y después la línea de la reserva que se quiere
eliminar. El diagrama es el que se muestra en la figura 38.
36
: Taquillero
: Sistema : Linea reserva
: Reserva
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>update
<<signal>>
<<signal>>
<<signal>> <<query>>
<<signal>>
Solicitar modificar linea reserva
Mostrar lista reservas(Lista)
Seleccione reserva
Seleccionar linea reserva
Seleccionar linea reserva
Mostrar datos(Datos)
Modifique cantidad
Modificar cantidad
Datos=mostrar datos(id_LineaReserva)
Modificar linea reserva( )
Lista=listar reservas
Figura 37: DS Modificar linea reserva
: Taquillero
: Sistema : Linea reserva
: Reserva
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
<<signal>>
Solicitar borrar linea
Mostrar lista reservas(Lista)
Seleccione reserva
Seleccionar linea reserva
Seleccionar linea reserva
Borrar linea reserva( )
Lista=listar reservas
Figura 38: DS Borrar linea reserva
37
3.4. DS Cancelar reserva: Siempre existe la posibilidad de cancelar una
reserva, incluso telefónicamente, si el cliente se identifica adecuadamente. En
ese caso todas las entradas que se habían reservado pasan a estar
disponibles. El actor en este diagrama de secuencia vuelve a ser el taquillero
que se encargará de todas estas gestiones:
: Taquillero
: Sistema : Reserva
Solicitar cancelar reserva
Introduzca DNI cliente
Introducir DNI li t
Cancelar reserva( )
Mostrar lista reservas
Seleccione una reserva
Seleccionar una reserva
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<service>>destroy
Figura 39: DS cancelar reserva
3.5. DS Recoger reserva: el taquillero solicita los datos al melómano que
acude a taquilla para retirar la reserva realizada por teléfono. Tras obtener su
identificación comprueba la existencia de la reserva y le proporciona las
entradas, una vez el cliente haya realizado el pago de las mismas, ya sea en
efectivo o con tarjeta de crédito. El diagrama queda de la siguiente manera:
38
: Taquillero
: Sistema : Melomano : Reserva
: Entidad financiera
Solicitar recoger reserva
Introduzca DNI melomano
Introducir DNI melomano
existe?
[if recogida=false]seleccionar reserva
Elegir reserva
Muestra reservas
Recoger reserva( )
Realice pago
Mostrar precio venta
Introducir num_tarjeta
Enviar pago(num_tarjeta,Precio_venta)
Transaccion correcta
Realizar pago efectivo
SI pago con tarjeta
SI pago en efectivo
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>><<query>>
<<select>>
<<service>>update
Figura 40: DS Recoger reserva
Los siguientes diagramas de secuencia corresponden al paquete de
Venta de entradas, en este paquete se realizan todas las operaciones
relacionadas con la compra de entradas para las distintas representaciones
que se ofrecen en el Palau de la Música.
4.1. DS Crear cesta venta: El siguiente diagrama de secuencia muestra
la creación de una cesta de venta de entradas. Las entradas pueden
39
comprarse en taquilla o por Internet. Si la compra se realiza en taquilla el
taquillero será el que realice las acciones de crear la cesta junto con sus líneas
de venta de manera que se irán seleccionando los conciertos que se incluirán
en la cesta, el número de entradas así como la zona que se prefiere.
Finalmente el taquillero comunicará al usuario el precio de las mismas.
Si la compra es por Internet es el internauta el actor que se encarga de
realizar las acciones citadas anteriormente, y además deberá registrarse y
facilitar sus datos personales para posteriormente poder recoger sus entradas
en taquilla.
El diagrama es el siguiente:
: Taquillero : Sistema : Melomano : Linea
venta : Concierto : Zona : Cesta
venta : Internauta
si (actor = internauta)
Solicitar crear venta
Introducir datos cliente
Solicitar datos cliente
Crear cesta venta( )
Seleccionar melomano <<select>
Crear linea venta( )
Loop
Seleccionar concierto <<select>>
Seleccionar zona <<select>
Introducir cantidad
Calcular PrecioTotal linea
PrecioVenta
End Loop
Mostrar PrecioVenta
<<signal
<<signal>>
<<signal>>
<<signal
<<signal>>
<<service>>new
<<service>>new
PrecioUnitario=obtener precio <<query
<<query
Figura 41: DS Crear cesta venta
4.2. DS Modificar línea venta: función dedicada a la modificación de los
datos de una línea de venta. El taquillero pedirá una lista de las ventas
existentes en el sistema, y después elegirá cual es la línea de venta que quiere
modificar. A continuación podemos el diagrama de secuencia
correspondiente a la modificación:
40
: Taquillero
: Sistema : Linea venta : Cesta Venta
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>update
<<signal>>
<<signal>>
<<signal>> <<query>>
<<signal>>
Solicitar modificar linea venta
Mostrar lista ventas(Lista)
Seleccione venta
Seleccionar linea venta
Seleccionar linea venta
Mostrar datos(Datos)
Modifique cantidad
Modificar cantidad
Datos=mostrar datos(id_LineaVenta)
Modificar linea venta( )
Lista=listar ventas
Figura 42: DS Modificar linea venta
4.3. DS Confirmar cesta venta: para la confirmación de la cesta de una
venta el taquillero comprueba si quedan localidades libres de ese tipo para
todas las entradas seleccionadas, en caso afirmativo se efectúa el cobro de
las entradas, ya sea en efectivo o mediante una transacción electrónica. Por
último se da de alta dicho cesta de venta.
En el caso que las entradas se estén comprando por Internet, el actor
del sistema será el internauta y el pago de las mismas se realizará solamente
mediante una transacción electrónica, que debe ser realizada por el cliente y
una entidad financiera independiente (manteniendo la confidencialidad de
sus datos financieros) que notificará al Palau el éxito de la transacción antes
de que sea confirmada la venta.
41
A continuación se presenta el diagrama de secuencia:
: Taquillero
: Sistema : Cesta Venta
: Concierto : Venta internet
: Internauta : Entidad financiera
SI (pago con tarjeta de credito) (actor=internauta)
SI pago en efectivo
<<signal>
<<signal>
<<signal>
<<query>>
<<query>
<<signal>
<<signal>
<<signal>
<<signal>
<<signal>
<<signal>
<<service>>update
<<service>>update
<<service>>update
Solicitar confirmar venta
Realice pago
Mostrar PrecioVenta
Introducir num_tarjeta
Realizar pago efectivo
Seleccione venta
Seleccionar venta
Aceptar venta( )
Obtener info venta
Comprobar si existe disponibilidad
Modif atrib vendidos( )
[if actor=internauta]IncrementarV Internet( )
Enviar pago(num_tarjeta,Precio)
Transaccion correcta
Figura 43: DS Confirmar cesta venta
4.4. DS Borrar línea venta: Permite borrar la línea de una venta. En el
caso de que la venta haya sido realizada en taquilla el actor del diagrama
será el taquillero, si es una venta de Internet el actor será el internauta. Primero
se selecciona la venta y después la línea de venta que se quiere eliminar. El
diagrama es el que se muestra a continuación:
42
: Linea Venta
: Taquillero
: Sistema
: Internauta
: CestaVenta
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
<<signal>>
Solicitar borrar linea venta
Mostrar lista ventas(Lista)
Seleccione venta
Seleccionar linea venta
Seleccionar linea venta
Borrar linea venta( )
Lista=listar ventas
Figura 44: DS Borrar linea venta
4.5. DS Eliminar cesta venta: función dedicada a la eliminación de una
cesta de venta, ya sea comprada en taquilla o por Internet. El actor
encargado de realizarlo es el administrador del sistema. El diagrama de
secuencia es el que aparece en la siguiente figura:
: Administrador
: Sistema : Cesta venta
Solicitar eliminar t
Lista=listar ventas
Mostrar lista ventas(Lista)
Seleccione venta
Seleccionar venta
Eliminar cesta venta( )
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<service>>destroy
<<query>>
Figura 45: DS Eliminar cesta venta
4.6. DS Recoger entradas Internet: el taquillero solicita los datos al
melómano que acude a taquilla para retirar las entradas comprado por
43
Internet. Tras obtener su identificación comprueba la existencia de las entradas
y le proporciona las mismas. El diagrama queda de la siguiente manera:
: Taquillero
: Sistema : Melomano : Venta internet
Solicitar recoger entradas
Introduzca DNI melomano
Introducir DNI melomano
existe?
[if Recogida=false]seleccionar venta
Recoger entradas( )
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<select>>Mostrar venta
<<signal>>
<<service>>update
Figura 46: DS Recoger entradas internet
Los siguientes diagramas de secuencia corresponden al paquete de
Usuarios, en este paquete se realizan todas las operaciones relacionadas con
la gestión de los datos relacionados con los usuarios de la aplicación.
5.1. DS Crear usuario: creación de nuevos objetos de la clase Usuario de
acuerdo a unos valores que el administrador proporciona. Supone el alta de
un nuevo usuario del que se solicitan datos como el nombre y el DNI.
: Usuario : Administrador
: Sistema
<<signal>>
<<signal>>
<<signal>>
<<service>>new
Solicitar crear usuario
Solicitar datos
Introducir datos
Crear_ usuario( )
Figura 47: DS Crear usuario
44
5.2. DS Modificar usuario: función dedicada a la modificación de los
datos de los usuarios. A continuación podemos el diagrama de secuencia
correspondiente a la modificación:
: Administrador
: Sistema : Usuario
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<query>>
<<service>>update
Solicitar modificar usuario
Mostrar lista usuarios(Lista)
Seleccione usuario
Seleccionar usuario
Mostrar datos(Datos)
Modifique usuario
Modificar usuario
Lista=listar usuarios
Datos=mostrar datos(id)
Modificar_usuario(String)
Figura 48: DS Modificar usuario
5.3. DS Eliminar usuario: en la siguiente figura se muestra el diagrama de
secuencia correspondiente a la eliminación de un objeto de la clase Usuario:
: Administrador
: Sistema : Usuario
<<signal>>
<<signal>>
<<signal>>
<<signal>>
<<query>>
<<service>>destroy
Solicitar eliminar usuario
Mostrar lista usuarios(Lista)
Seleccione usuario
Seleccionar usuario
Lista=listar usuarios
Eliminar_ usuario( )
Figura 49: DS Eliminar usuario
45
3. Modelo conceptual
En el modelo Conceptual se describen los componentes de la sociedad de
objetos sin detenerse en los aspectos de implementación. El modelo
conceptual del sistema debe capturar todas las propiedades del sistema
(estáticas y dinámicas) y no debe contener más detalles de implementación
que los encontrados en los requisitos.
OO-Method utiliza el modelo de objetos, el dinámico y funcional para
representar el Esquema Conceptual, estos tres modelos describen la sociedad
de objetos desde tres puntos de vista complementarios y definen la
arquitectura del modelo Conceptual.
3.1. Modelo de objetos
El modelo de objetos define la estructura y relaciones estáticas de las
clases identificadas en el dominio del problema.
• Melómano: datos de los usuarios que compran abonos por Internet o
entradas por Internet y realizan reservas. La clase Melómano tiene
como atributos el dni, nombre, apellidos, dirección y teléfono.
Figura 50: Clase Melomano
46
• Sala: salas de las que dispone el Palau para las representaciones. La
clase Sala tiene como atributos el número de sala(atributo de tipo
autonumérico), el nombre y la descripción.
Figura 51: Clase Sala
• Zona: cada una de las zonas en las que puede dividirse una sala. Sus
atributos son el identificador de zona que es un atributo de tipo
autonumérico, el tipo de zona(anfiteatro, palco y coro), el número
de plazas de que dispone y la descripción que es un atributo que
puede tomar valor nulo.
Figura 52: Clase Zona
• Interprete: son las orquestas, directores y solistas que intervienen en
los conciertos. Sus atributos son el identificador de tipo
autonumérico, el nombre completo y la descripción del mismo. Los
47
servicios que pueden ejecutarse son los de mantenimiento de
intérprete (crear, eliminar y modificar).
Figura 53: Clase Interprete
• Obra: cada obra tiene un identificador de tipo autonumérico, un
título y una descripción que puede tomar valor nulo. Sobre esta clase
se pueden realizar las acciones de crear, eliminar y modificar.
Figura 54: Clase Obra
• Concierto: cada una de las representaciones que se celebran en el
Palau de la Música.
Sus atributos son:
Código: de tipo autonumérico.
Fecha y hora en que se celebra.
Menos2horas: de tipo boleano indica si faltan menos de 2
horas para que comience el concierto.
Celebrado: de tipo boleano indica si ya ha sido celebrado
el concierto.
48
PrecioZ1, PrecioZ2, PrecioZ3: es el precio de cada zona de
la sala en la que se celebra el concierto.
TotalZ1, TotalZ2, TotalZ3: es el número de plazas de cada
zona de la sala en la que se celebra el concierto.
DisponibleZ1, DisponibleZ2, DisponibleZ3: es el número de
plazas disponibles de cada zona de la sala en la que se
celebra el concierto.
VendidosZ1, VendidosZ2, VendidosZ3: es el número de
plazas vendidas de cada zona de la sala en la que se
celebra el concierto.
ReservadoZ1, ReservadoZ2, ReservadoZ3: es el número de
plazas reservadas de cada zona de la sala en la que se
celebra el concierto.
Algunos de estos atributos son derivados, es decir, su valor se
calcula en función del valor de otros atributos. A continuación se
muestran estos atributos y la forma en que se calculan:
Atributo Fórmula DisponibleZ1 TotalZ1-(VendidosZ1+ReservadoZ1) DisponibleZ2 TotalZ2-(VendidosZ2+ReservadoZ2) DisponibleZ3 TotalZ3-(VendidosZ3+ReservadoZ3) TotalZ1 Sala.Zona1.Num_plazas TotalZ2 Sala.Zona2.Num_plazas TotalZ3 Sala.Zona3.Num_plazas
También es necesario tener en cuenta una serie de restricciones
que deben cumplir algunos de los atributos:
Restricción VendidosZ1+ReservadoZ1<=TotalZ1 VendidosZ2+ReservadoZ2<=TotalZ2 VendidosZ3+ReservadoZ3<=TotalZ3
49
La siguiente figura muestra los atributos, servicios y relaciones de
la clase Concierto:
Figura 55: Clase Concierto
• Linea_Abono: Clase en la que se almacenan los conciertos a los que
se ha abonado un usuario. Tiene un identificador de tipo
autonumérico. En la siguiente figura se muestra dicho atributo junto
con los servicios y relaciones que establece:
Figura 56: Clase Linea_Abono
50
• Cesta_Abono: Clase que agrupa las líneas de abono de un usuario.
Sus atributos son:
Id de tipo autonumérico.
Num_lineas: son el número de líneas de abono que forman
ese abono.
Precio: es el precio del abono antes de haberle aplicado el
descuento.
PrecioFinal: es el precio del abono tras haberle aplicado el
descuento.
Aceptada: indica si la cesta ha sido aceptada.
TipoInternet: indica que el abono se especializa en
Abono_internet.
Algunos de estos atributos son derivados, es decir, su valor se
calcula en función del valor de otros atributos. A continuación se
muestran estos atributos y la forma en que se calculan:
Atributo Condición Fórmula Num_lineas COUNT(Linea_Abono) Precio Zona.Tipo=”Anfiteatro” SUM(Linea_Abono.Concierto.PrecioZ1)Precio Zona.Tipo=”Coro” SUM(Linea_Abono.Concierto.PrecioZ2)Precio Zona.Tipo=”Palco” SUM(Linea_Abono.Concierto.PrecioZ3)PrecioFinal Precio*0.9
La única restricción que deberá tenerse en cuenta es la siguiente:
Restricción Num_lineas = 3
La siguiente figura muestra los atributos, servicios y relaciones de
la clase Cesta_Abono:
51
Figura 57: Clase Cesta_Abono
• Abono_internet: Cesta de una venta de un abono a través de
Internet que ha sido aceptada. El atributo recogido indica si el
abono ya ha sido retirado en taquilla.
Figura 58: Clase Abono_internet
• Linea_reserva: Clase en la que se almacenan las localidades que se
han reservado telefónicamente por el usuario. Los atributos son:
Un identificador de tipo autonumérico.
Cantidad que indica el número de entradas reservadas.
PrecioUnitario que es el precio de una localidad.
PrecioTotal que es el precio de todas las localidades
reservadas.
La siguiente tabla muestra la fórmula para los atributos derivados
de la clase Linea_reserva:
Atributo Condición Fórmula PrecioUnit Zona.Tipo=”Anfiteatro” Concierto.PrecioZ1 PrecioUnit Zona.Tipo=”Coro” Concierto.PrecioZ2 PrecioUnit Zona.Tipo=”Palco” Concierto.PrecioZ3 PrecioTotal Cantidad*PrecioUnitario
52
También es necesario tener en cuenta una restricción que debe
cumplirse:
Restricción Cantidad >= 1 and Cantidad<=8
En la siguiente figura se muestran los atributos junto con los
servicios y relaciones que establece:
Figura 59: Clase Linea_reserva
• Reserva: Clase que agrupa las líneas de reserva de un usuario. Sus
atributos son:
Id de tipo autonumérico.
Precio: es el precio total de la reserva.
Recogida: indica si las entradas reservadas han sido
recogidas en taquilla.
Total_entradas: indica el número total de entradas que han
sido reservadas.
El atributo Precio es derivado y se calcula de la siguiente manera:
Atributo Fórmula Precio SUM(Linea_reserva.PrecioTotal) Total_entrads SUM(Linea_reserva.Cantidad)
53
La siguiente figura muestra los atributos, servicios y relaciones de
la clase Reserva:
Figura 60: Clase Reserva
• Linea_venta: Clase en la que se almacenan las localidades
compradas por el usuario. Los atributos son:
Un identificador de tipo autonumérico.
Cantidad que indica el número de entradas compradas.
PrecioUnitario que es el precio de una localidad.
PrecioTotal que es el precio de todas las localidades
pedidas.
La siguiente tabla muestra la fórmula para los atributos derivados
de la clase Linea_venta:
Atributo Condición Fórmula PrecioUnit Zona.Tipo=”Anfiteatro” Concierto.PrecioZ1 PrecioUnit Zona.Tipo=”Coro” Concierto.PrecioZ2 PrecioUnit Zona.Tipo=”Palco” Concierto.PrecioZ3 PrecioTotal Cantidad*PrecioUnitario
También es necesario tener en cuenta una restricción que debe
cumplirse:
Restricción Cantidad >= 1
54
En la siguiente figura se muestran los atributos junto con los
servicios y relaciones que establece la clase Linea_venta con el resto
de clses del sistema:
Figura 61: Clase Linea_venta
• Cesta_venta: Clase que agrupa las líneas de venta de un usuario. Sus
atributos son:
Id de tipo autonumérico.
Precio: es el precio total de la venta realizada.
Aceptada: indica si la cesta ha sido aceptada.
TipoInternet: indica que la venta se especializa en
Venta_internet.
El atributo Precio es derivado y se calcula de la siguiente manera:
Atributo Fórmula Precio SUM(Linea_venta.PrecioTotal)
La siguiente figura muestra los atributos, servicios y relaciones de
la clase Cesta_venta:
55
Figura 62: Clase Cesta_venta
• Venta_internet: Cesta de una venta a través de Internet que ha sido
aceptada. El atributo recogida indica, si su valor es true, que la
venta ha sido retirada en taquilla.
Figura 63: Clase Venta_internet
• Usuario: clase genérica que representa a cualquier usuario de la
aplicación. Los atributos, servicios y relaciones de esta clase se
muestran a continuación:
Figura 64: Clase Usuario
56
• Administrador: usuario que puede desempeñar tareas de
administración del Palau (crear modificar y eliminar conciertos, salas,
usuarios, etc.). En la siguiente figura se muestra la clase
Administrador:
Figura 65: Clase Administrador
• Internauta: es el usuario que accede desde Internet a la aplicación
para poder realizar la compra de entradas o de abonos a través de
la red.
Figura 66: Clase Internauta
• Taquillero: usuario que desde las taquillas del Palau realizará las
ventas personalmente a los clientes que se acerquen hasta allí y se
encargará de las reservas telefónicas.
Figura 67: Clase Taquillero
La siguiente figura muestra la relación existente entre las clases Usuario,
Administrador, Internauta y Taquillero. La clase Usuario se especializa y da lugar
a las clases hijas Administrador, Internauta y Taquillero que heredan los
atributos y servicios de la clase padre.
57
Figura 68: Especialización Usuario
Por último, en la siguiente figura se puede ver el diagrama de clases. Se
puede apreciar la relación que existe entre ellas, así como la cardinalidad de
las mismas:
Figura 69: Diagrama de clases
58
3.2. Modelo dinámico
El modelo dinámico define las secuencias posibles de servicios (vidas
posibles) y los aspectos relacionados con la interacción entre objetos.
En este apartado únicamente se va a incluir el Diagrama de Transición
de Estados(DTE) de las clases que tengan un comportamiento dinámico
especial. No se mostrarán los DTE de las clases que no tengan un
comportamiento especial y que, por lo tanto, mantengan el DTE básico que
OO-Method genera automáticamente.
• Melómano: No tiene comportamiento especial. El DTE es el
generado de manera automática por OO-Method.
• Sala: No tiene comportamiento especial. El DTE es el generado
de manera automática por OO-Method.
• Zona: No tiene comportamiento especial. El DTE es el generado
de manera automática por OO-Method.
• Intérprete: No tiene comportamiento especial. El DTE es el
generado de manera automática por OO-Method.
• Obra: No tiene comportamiento especial. El DTE es el generado
de manera automática por OO-Method.
• Concierto: el DTE de concierto se compone de los siguientes
estados:
Mas2Hora: Faltan más de dos horas para que comience la
representación del concierto.
Menos2Ho:Faltan menos de dos horas para que comience
la representación del concierto.
Celebrad: Ya se ha celebrado el concierto.
En la siguiente figura se puede ver el DTE generado:
59
Figura 70: DTE Clase Concierto
• Linea_Abono: el DTE correspondiente a las líneas de abono se
compone de los siguientes estados:
Linea_0: Línea no confirmada.
Confirma: Línea confirmada.
Los servicios que deben cumplir alguna precondición son:
ConfirLineAbono: Cesta.Aceptada= True
Figura 71: DTE Linea_Abono
60
• Cesta_Abono: el DTE correspondiente a las cestas de abonos se
compone de los siguientes estados:
Cesta_0: Cesta no aceptada.
Aceptada: Cesta aceptada
Figura 72: DTE Cesta_Abono
• Abono_internet: el DTE correspondiente al abono comprado por
Internet se compone de los siguientes estados:
Cesta_0: Cesta de Internet no aceptada.
Aceptada: Cesta de Internet aceptada pero no recogida.
Recogida: Cesta aceptada y recogida.
Figura 73: DTE Abono_internet
61
• Linea_Reserva: No tiene comportamiento especial
• Reserva: No tiene comportamiento especial
• Linea_venta: el DTE correspondiente a las líneas de venta se
compone de los siguientes estados:
Linea_0: Línea no confirmada.
Confirma: Línea confirmada.
Los servicios que deben cumplir alguna precondición son:
Mod_cantidad: Cesta.Aceptada =False
ConfirLineVenta:Cesta.Aceptada= True
En la siguiente figura se puede observar el DTE de Linea_venta
con los estados descritos anteriormente:
Figura 74: DTE Linea_venta
• Cesta_venta: el DTE correspondiente a las cestas de venta se
compone de los siguientes estados:
Cesta_0: Cesta no aceptada.
Aceptada: Cesta aceptada
62
Figura 75: DTE Cesta_venta
• Venta_internet: el DTE correspondiente a la venta de entradas
realizada por Internet se compone de los siguientes estados:
Cesta_0: Cesta de Internet no aceptada.
Aceptada: Cesta de Internet aceptada pero no recogida.
Recogida: Cesta aceptada y recogida.
A continuación se muestra el DTE de Venta_internet:
Figura 76: DTE Venta_internet
• Usuario: No tiene comportamiento especial.
• Administrador: No tiene comportamiento especial.
• Taquillero: No tiene comportamiento especial.
• Internauta: No tiene comportamiento especial.
63
3.3. Modelo funcional
El modelo funcional captura la semántica asociada a los cambios de
estado de los objetos por la ocurrencia de eventos.
A continuación veremos el modelo funcional del caso de estudio para
la venta de entradas:
• Melómano o Nombre Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoNombre
o Apellidos Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoApellido
o Telefono Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoTelefono
o Direccion Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevaDireccion
• Sala o Nombre Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoNombre
o Descripcion Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevaDesc
• Zona
o Descripcion Categoría Evento Efecto Condición Valor Actual De Estado Modificar =Desc
o NumPlazas Categoría Evento Efecto Condición Valor Actual De Estado Modificar =Plazas
• Interprete
o Nombre Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoNombre
64
o Descripcion Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevaDesc
• Obra
o Titulo Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoTitulo
o Descripcion Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevaDesc
• Concierto
o Celebrado Categoría Evento Efecto Condición Valor Actual De Situación Celebrar =true false
o Menos2Horas Categoría Evento Efecto Condición Valor Actual De Estado DosHoras =true false
o PrecioZ1, PrecioZ2, PrecioZ3 Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoPrecio
o ReservadoZ1, ReservadoZ2, ReservadoZ3 Categoría Evento Efecto Condición Valor Actual Cardinal CancelarReserva - Cantidad Cardinal RecogerReserva - Cantidad Cardinal CrearReserva + Cantidad
o VendidosZ1, VendidosZ2, VendidosZ3 Categoría Evento Efecto Condición Valor Actual Cardinal ConfirLineVenta + Cantidad Cardinal ConfirLineAbono + 1 Cardinal RecogerReserva + Cantidad
• Cesta_Abono
o Aceptada o
TipoInternet Categoría Evento Efecto Condición Valor Actual De Situación AceptaInt =True False
Categoría Evento Efecto Condición Valor Actual De Situación Aceptar =True False
65
• Abono_internet o Recogido Categoría Evento Efecto Condición Valor Actual De Situación Recoger_abono =True False
• Linea_reserva
o Cantidad Categoría Evento Efecto Condición Valor Actual De Estado Mod_cantidad =cant
• Reserva
o Recogida Categoría Evento Efecto Condición Valor Actual De Situación RecogerReserva =true false
• Linea_venta
o Cantidad Categoría Evento Efecto Condición Valor Actual De Estado Mod_cantidad =cant
• Cesta_venta
o Aceptada Categoría Evento Efecto Condición Valor Actual De Situación Aceptar =True False
o TipoInternet Categoría Evento Efecto Condición Valor Actual De Situación AceptaInt =True False
• Venta_internet
o Recogida Categoría Evento Efecto Condición Valor Actual De Situación Recoger =True False
• Administrador
o dni Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoDNI
o Nombre Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoNomb
66
• Taquillero o dni_taq Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoDNI
o Nombre_taq Categoría Evento Efecto Condición Valor Actual De Estado Modificar =nuevoNomb
67
4. Diseño de la base de datos relacional
La siguiente fase es la de diseño. A partir de la recopilación de los
requisitos y con la ayuda del modelado conceptual es posible comenzar la
creación de una aplicación para modelar el sistema. En este proceso será
fundamental la creación de una base de datos relacional.
El diseño de las bases de datos relacionales consiste en mapear un
modelo de objetos obtenido en fase de análisis con sus correspondientes
tablas relacionales. Para establecer la correspondencia entre clases y tablas
existen una serie de técnicas que facilitan esta labor.
A) Correspondencia entre clases y tablas La correspondencia más eficiente es el mapeo directo en el que se
hace corresponder una clase con una tabla relacional.
B) Correspondencia entre relaciones binarias y tablas. En general, una relación puede o no corresponderse con una tabla.
Depende del tipo y multiplicidad de la relación, y de las preferencias de quien
diseña la base de datos en lo que respecta a la extensibilidad, número de
tablas, y criterios de rendimiento. Los desarrolladores poseen diversas opciones
para mapear relaciones (asociaciones y agregaciones) a tablas relacionales:
Utilizar una tabla diferente: En esta aproximación la relación se
representa mediante una tabla diferente a la de las clases relacionadas. Esta
aproximación proporciona una gran flexibilidad pero un rendimiento más bajo
si se ha de recorrer muy a menudo. Es la opción más utilizada para mapear
relaciones muchos-a-muchos.
Introducir una clave ajena: Es la aproximación más común para mapear
relaciones uno-a-uno y uno-a-muchos. En esta ocasión se incluye la clave
primaria de la que posee multiplicidad uno en la tabla de la clase de uno (en
el primer caso) o muchos (en el segundo caso). Esta solución mejora el
rendimiento de la anterior propuesta.
68
Embeber las clases en una sola tabla: En esta aproximación las dos
clases relacionadas se mezclan en una sola tabla. Esta aproximación mejora el
rendimiento pero viola la normalización. Suele utilizarse a veces en relaciones
uno-a-uno.
La opción elegida para la representación de las relaciones binarias ha
sido la de introducir una clave ajena.
C) Correspondencia entre relaciones de rerencia y tablas.
Existen muchos enfoques para resolver la correspondencia entre
relaciones de herencia y tablas, aunque nosotros vamos a utilizar el enfoque
normal que consiste en que las subclases y superclases se corresponden cada
una con una tabla. La identidad del objeto a través de una relación de
herencia se mantiene mediante un identificador compartido (es decir todos las
clases y subclases poseen el mismo identificador (clave)). Este enfoque es
limpio y extensible.
A continuación se muestran cada una de las tablas creadas con el
Microsoft Access siguiendo las pautas explicadas anteriormente:
• Tabla de Melómano: en la siguiente figura se muestran sus atributos
así como el dominio de los mismos. La clave primaria es dni:
Figura 77: Tabla Melomano
• Tabla de Sala: la tabla de Sala se compone de una clave primaria
de tipo autonumérico, del nombre y la descripción de la misma:
Figura 78: Tabla Sala
69
• Tabla de Zona: la clase Sala establece una relación de uno a
muchos con la clase Zona. Por eso en la tabla de Zona se introduce
la clave ajena Número_sala que hace referencia a la tabla Sala. El
atributo Tipo diferencia la zona de la sala a la que estamos haciendo
referencia( anfiteatro, coro, palco):
Figura 79: Tabla Zona
• Tabla de Interprete: sus atributos y el tipo de los mismos se pueden
ver en la siguiente tabla:
Figura 80: Tabla Interprete
• Tabla de Obra: cada obra tiene un título y una descripción, además
de un identificador autonumérico que es la clave primaria:
Figura 81: Tabla Obra
• Tabla de Concierto: en la siguiente figura se muestran los atributos de
un concierto así como el dominio de los mismos. Los atributos Obra,
Intérprete y Sala son claves ajenas a las tablas del mismo nombre. La
clave primaria es Código:
70
Figura 82: Tabla Concierto
• Tabla de Linea Abono: las líneas de abono tienen como clave
primaria un identificador autonumérico y como claves ajenas
IdConcierto que hace referencia a la tabla Concierto e IdAbono
que se refiere a la relación uno a muchos que se establece con la
tabla de Cesta Abono.
Figura 83: Tabla Linea Abono
Entre las clases Cesta Abono y Abono Internet existe una relación
de herencia, de tal manera que Cesta Abono es la clase padre y
Abono Internet la clase hija. Como se comentó anteriormente vamos a
utilizar el enfoque normal que consiste en que la subclase y la
superclase se corresponden cada una con una tabla y poseen el mismo
identificador(Id).
A continuación se detallan estas dos clases y sus respectivas
tablas con los atributos de cada una de ellas:
71
• Tabla de Cesta Abono: en la siguiente figura se puede ver de forma
detallada los atributos de una Cesta de Abono. Id(atributo
compartido) es la clave primaria de la tabla, Num_lineas es el
número de líneas del abono, Precio y PrecioFinal son el precio sin y
con descuento respectivamente, Aceptada indica si la cesta ha sido
aceptada y TipoInternet inicialmente tiene el valor “No” que
cambiará al especializar la cesta en un abono de Internet.
En la siguiente figura pueden verse los atributos que forman parte de
la tabla Cesta Abono:
Figura 84: Tabla Cesta Abono
• Tabla de Abono Internet: esta tabla posee el mismo identificador que
Cesta Abono, el atributo Recogido de tipo boleano y la clave ajena
dni_melomano que hace referencia a la relación que establece con
la clase Melomano:
Figura 85: Tabla Abono Internet
• Tabla de Linea Reserva: entre los atributos de esta tabla cabe
destacar la clave primaria que es Id, y las claves ajenas IdConcierto
e IdReserva que representan la relación de uno a muchos que se
establece con las clases Concierto y Reserva respectivamente:
72
Figura 86: Tabla Linea Reserva
• Tabla de Reserva: la clase Reserva se compone de una clave
primaria de tipo autonumérico, el Precio de la misma, la cantidad de
entradas reservadas (TotalEntradas), un atributo para indicar si ha
sido recogida en taquilla y de una clave ajena que hace referencia
a la tabla de Melómano.
La tabla de Reserva y los atributos que forman la misma son lo que se
muestran en la siguiente figura:
Figura 87: Tabla Reserva
• Tabla de Linea Venta: la siguiente tabla muestra los atributos de la
clase Linea Venta. Su clave primaria es Id y sus claves ajenas
IdConcierto e IdVenta que se refieren a las tablas Concierto y Cesta
Venta respectivamente:
Figura 88: Tabla Linea Venta
Nuevamente vuelve a producirse una relación de herencia entre clases,
esta vez entre Cesta Venta y Venta Internet. Así pues, cada clase se
corresponderá con una tabla y tendrán el mismo identificador(Id). Las tablas
de ambas se muestran a continuación:
73
• Tabla de Cesta Venta: en la siguiente figura se puede ver de forma
detallada los atributos de una Cesta de Venta. Id(atributo
compartido) es la clave primaria de la tabla, Precio es el precio de la
cesta, Aceptada indica si la cesta ha sido aceptada y TipoInternet
inicialmente tiene el valor “No” que cambiará al especializar la cesta
en una venta en Internet.
Figura 89: Tabla Cesta Venta
• Tabla de Venta Internet: esta tabla posee el mismo identificador que
Cesta Venta, el atributo Recogida de tipo boleano y la clave ajena
dni_melomano que hace referencia a la relación que se establece
con la clase Melómano:
Figura 90: Tabla Venta Internet
74
5. Descripción de la implementación
Después de realizar el análisis de requisitos, capturar todas las
propiedades del sistema mediante un modelado conceptual y obtener el
diseño de la base de datos, el siguiente paso es el diseño de la aplicación.
Es importante crear una interfaz sencillo y fácil de utilizar por el usuario y
para ello se ha empleado el programa Microsoft Visual Basic. Mediante Visual
Basic se ha creado una aplicación para la venta de entradas del Palau de la
Música gracias a la cual es posible adquirir entradas y abonos de temporada.
Además se ha incluido la parte correspondiente al mantenimiento de la
información del sistema como son las salas, intérpretes, conciertos, etc.
Al ejecutarse la aplicación aparece una ventana de presentación que
dará paso a la ventana principal del programa:
• Pantalla principal: desde esta ventana es posible acceder a todas
las funciones de la aplicación. En la barra de menú se ha hecho una
distribución sencilla. Para acceder a la venta de entradas o abonos
se utilizará el menú Venta y para realizar el mantenimiento de los
datos del sistema se hará uso de Mantenimiento que contiene los
mantenimientos de melómano, sala, zona, intérprete, obra y
concierto. En Ayuda están los datos acerca de la aplicación y por
último a través de Archivo se cerrará la aplicación.
Figura 91: Ventana principal
75
A continuación se muestra la parte de mantenimiento junto con una
breve explicación de cada pantalla.
• Mantenimiento de Melómano: en primer lugar se presenta una tabla
que contiene la información que la base de datos tiene sobre los
melómanos. Además muestra por pantalla tres opciones
relacionadas con el mantenimiento de un melómano, como son
alta, modificar y baja. El botón Baja elimina el melómano señalado
en la tabla. Los botones de Alta y Modificar abren una nueva
ventana para poder realizar estas operaciones. El botón Cerrar cierra
la ventana.
Figura 92: Ventana Mantenimiento Melomano
• Alta Melómano: se muestran todos los campos que forman parte de
la definición de un melómano. Para poder dar de alta un melómano
es necesario rellenar todos los datos, así pues se introduce la
información y a continuación se da de alta. Si no se han rellenado
todos los campos o los datos son erróneos aparecerá un mensaje de
error con información acerca del mismo. Al crear un melómano el
sistema comprobará que ese melómano no existía en la base de
datos, en caso contrario mostrará un mensa je de error.
76
Figura 93: Ventana Alta Melomano
• Modificar Melómano: es similar a la pantalla anterior. La ventana
muestra los datos del melómano que se quiere modificar. El dni es el
único atributo al que no se puede acceder. Si no se rellenan todos
los campos o el teléfono no es un número aparecerá un mensaje de
error. El botón Modificar guardará los datos modificados en la base
de datos del Palau de la Música. La siguiente figura muestra la
ventana obtenida y como se puede observar muestra un error al
dejar el campo teléfono vacío:
Figura 94: Ventana Modificar Melomano
77
• Mantenimiento de Sala: la tabla muestra toda la información acerca
de las salas guardada en la base de datos. En esta ventana es
posible crear, modificar o eliminar una sala. Al dar de alta o
modificar una sala se deben crear o modificar las zonas asociadas.
Asímismo, al dar de baja una sala se eliminarán sus zonas.
Figura 95: Ventana Mantenimiento Sala
• Alta Sala: se introducen los datos de la zona y tras comprobar que el
campo nombre no está vacío se muestra la ventana de Alta
Zonas(Figura 97). Se introducirá la información para cada una de las
zonas y al dar de alta se comprobará que el campo Nºplazas no
está vacío. Finalmente se introducirán los datos de la sala y sus
respectivas zonas en la base de datos del sistema.
La siguiente figura muestra la interfaz para Alta Sala:
Figura 96: Ventana Alta Sala
78
La ventana creada para dar de alta las zonas de una sala es la
siguiente:
Figura 97: Ventana Alta Zonas
• Modificar Sala: la ventanas para la modificación de las salas y sus
zonas son muy similares a las mostradas anteriormente.
Figura 98: Ventana Modificar Sala
La ventana que se muestra a continuación es la correspondiente a
la modificación de las zonas de una sala:
Figura 99: Ventana Modificar Zonas
79
• Mantenimiento de Intérprete: por pantalla aparece la tabla con
todos los intérpretes existentes. Las posibles acciones son alta,
modificar y baja. Se seleccionará de la tabla qué intérprete se
desea. Los botones Alta y Modificar mostrarán una nueva ventana.
El botón Baja eliminará de la base de datos el intérprete
seleccionado en la tabla. En la siguiente figura se muestra la
ventana para el mantenimiento de intérprete :
Figura 100: Ventana Mantenimiento Interprete
• Modificar Intérprete: en esta pantalla se muestran los datos del
intérprete seleccionado en la pantalla anterior (Figura 100). Es
posible modificar el nombre y la descripción del intérprete pero
antes se comprueba que el campo Nombre no esté vacío.
Figura 101: Ventana Modificar Interprete
80
La ventana de Alta Intérprete es muy parecida a la mostrada para
Modificar Intérprete.
• Mantenimiento de Obra: muestra por pantalla tres opciones
relacionadas con el mantenimiento de una obra, como son alta,
modificar y baja. El botón Baja elimina la obra seleccionada en la
tabla. El botón Cerrar cierra la ventana.
Figura 102: Ventana Mantenimiento Obra
• Alta Obra: se introduce la información de una obra y a continuación
se da de alta. Si no se ha rellenado el campo Titulo aparecerá un
mensaje de error con información acerca del mismo. Si todo está
correcto la obra pasará a formar parte de la base de datos del
Palau de la Música.
Figura 103: Ventana Alta Obra
81
• Mantenimiento de Concierto: las operaciones para el mantenimiento
de la clase Concierto son alta, baja y modificar. El evento de baja
eliminará el registro seleccionado de la base de datos del Palau.
Figura 104: Ventana Mantenimiento Concierto
• Modificar Concierto: para poder modificar un concierto deben
rellenarse todos los campos, de lo contrario se muestra un mensaje
de error por pantalla. En la siguiente figura se puede observar que en
el campo fecha se despliega un calendario que facilita su elección.
Figura 105: Ventana Modificar Concierto
82
La ventana para dar de alta un Concierto no se muestra ya que es
muy similar a la de modificación.
A continuación se muestran las ventanas que han sido creadas para la
venta de entradas y de abonos.
• Venta de entradas:
1. Información de concierto: el primer paso para la venta de
entradas es la elección de la obra que se quiere adquirir. Ésta se
selecciona de una lista desplegable. Al elegir la obra, en la tabla
que aparece en pantalla se cargarán todos los conciertos del
Palau que representan dicha obra. A continuación se elegirá la
sesión que se desea (hora y fecha).
Figura 106: Ventana Información Concierto
2. Datos del concierto seleccionado: en esta ventana se muestran
los datos del concierto seleccionado. A continuación se pide que
se elija la zona que se prefiere y el número de localidades y se
calcula el precio. En el caso de que no quedaran suficientes
entradas disponibles se comunicará mediante un mensaje de
aviso. Por último es necesario indicar si el pago de las entradas se
realizará en efectivo o mediante tarjeta de crédito.
83
Figura 107: Ventana Datos Concierto
3. Datos del cliente: si el modo de pago elegido es en efectivo se
mostrará la ventana Confirmación Venta(figura 107). Si el pago
es con tarjeta se mostrará la ventana de Datos del cliente, en la
cual se seleccionará el DNI del cliente de una lista desplegable
que mostrará los datos del melómano elegido. Finalmente se
introducirán los datos de la tarjeta que serán verificados.
Figura 108: Ventana Datos Cliente
84
4. Confirmación de la venta: la última pantalla para la venta de
entradas muestra toda la información de las localidades
elegidas, así como la zona deseada, la cantidad de entradas
pedidas y el precio de las mismas. Se ofrece la posibilidad de
confirmar la venta o cancelar la operación. Si la venta es
confirmada las entradas dejarán de estar disponibles y se
anotarán como vendidas. Si se cancela la venta se cerrará la
pantalla.
Figura 109: Ventana Confirmación Venta
• Venta de abonos:
1. Información de concierto para un abono: un abono consiste en la
compra de entradas para tres conciertos. Para crear el abono
elegiremos los conciertos mediante las flechas que aparecen en la
ventana. Una vez elegidas las tres localidades podremos pasar a la
siguiente pantalla y elegir la zona para el abono. El botón Ver detalle
permite acceder a toda la información referente al concierto. Esta
ventana puede verse en la figura 110:
85
Figura 110: Ventana Información Concierto Abono
2. Datos del abono seleccionado(figura 111): se muestra por pantalla
los conciertos que forman parte del abono. El usuario debe introducir
la zona deseada para poder calcular el precio del mismo. Si no
quedarán entradas disponibles para todos los conciertos se
comunicará mediante un mensaje del sistema, indicando que
entradas están agotadas. El modo de pago puede ser en efectivo o
con tarjeta de crédito en cuyo caso la ventana es la mima que la
mostrada en la figura 106.
3. Confirmación del abono: para poder realizar la confirmación de la
venta de un abono se muestra toda la información acerca de los
conciertos que forman parte del mismo, la zona deseada y el
precio. Una vez aceptado el abono se descuentan las entradas de
las disponibles y se anotan como vendidas. La ventana para la
confirmación de la venta de un abono se muestra en la figura 112.
86
Figura 111: Ventana Datos Abono
Figura 112: Ventana Confirmación Abono
87
6. Conclusiones
En un primer momento se ha hecho una descripción del caso de estudio
a analizar.
A continuación se ha realizado la captura de los requisitos del sistema,
de acuerdo a la descripción proporcionada del mismo y de esta forma
clarificar el proceso de construcción del modelo de requisitos.
Una vez construido el modelo de requisitos, se abordó el proceso de
análisis de requisitos, tras la aplicación del cual al caso de estudio, se generó
un conjunto de diagramas de secuencia.
Estos diagramas de secuencia y el modelo de requisitos son los puntos
de entrada para la generación del modelo de objetos, del modelo dinámico y
funcional.
Tras haber realizado los pasos anteriores es posible comenzar la
creación de una aplicación para modelar el sistema y su correspondiente
base de datos.
Todo el proceso que precede al diseño de la aplicación es de vital
importancia puesto que en él deben capturarse los requisitos que el usuario
desea y será determinante para que el software resultante satisfaga las
necesidades reales del usuario.
88
89
Índice de figuras
Figura 1: Vista del caso de uso general .......................................................................... 12 Figura 2: Mantenimiento info......................................................................................... 13 Figura 3: Datos melomano ............................................................................................. 13 Figura 4: Datos sala ........................................................................................................ 14 Figura 5: Datos zona....................................................................................................... 14 Figura 6: Datos interprete ............................................................................................... 15 Figura 7: Datos obra ....................................................................................................... 15 Figura 8: Datos concierto ............................................................................................... 16 Figura 9: Compra abonos ............................................................................................... 16 Figura 10: Reserva telefónica ......................................................................................... 17 Figura 11: Venta entradas............................................................................................... 18 Figura 12: Usuarios ........................................................................................................ 18 Figura 13: DS Crear melomano...................................................................................... 20 Figura 14: DS Actualizar melomano .............................................................................. 20 Figura 15: DS Eliminar melomano................................................................................. 21 Figura 16: DS Crear sala ................................................................................................ 22 Figura 17: DS Modificar sala ......................................................................................... 22 Figura 18: DS Eliminar sala ........................................................................................... 23 Figura 19: DS Crear zonas ............................................................................................. 23 Figura 20: DS Modificar zonas ...................................................................................... 24 Figura 21: DS Eliminar zonas ........................................................................................ 25 Figura 22: DS Crear interprete ....................................................................................... 25 Figura 23: DS Modificar interprete ................................................................................ 26 Figura 24: DS Eliminar interprete .................................................................................. 27 Figura 25: DS Crear obra ............................................................................................... 27 Figura 26: DS Modificar obra ........................................................................................ 28 Figura 27: DS Eliminar obra .......................................................................................... 28 Figura 28: DS Crear concierto........................................................................................ 29 Figura 29: DS Modificar concierto................................................................................. 30 Figura 30: DS Eliminar concierto................................................................................... 30 Figura 31: DS Crear cesta abono.................................................................................... 31 Figura 32: DS Confirmar cesta abono ............................................................................ 32 Figura 33: DS Borrar linea abono................................................................................... 33 Figura 34: DS Eliminar cesta abono............................................................................... 33 Figura 35: DS Recoger abono internet ........................................................................... 34 Figura 36: DS Crear reserva ........................................................................................... 35 Figura 37: DS Modificar linea reserva ........................................................................... 36 Figura 38: DS Borrar linea reserva................................................................................. 36 Figura 39: DS cancelar reserva....................................................................................... 37
90
Figura 40: DS Recoger reserva....................................................................................... 38 Figura 41: DS Crear cesta venta ..................................................................................... 39 Figura 42: DS Modificar linea venta .............................................................................. 40 Figura 43: DS Confirmar cesta venta ............................................................................. 41 Figura 44: DS Borrar linea venta.................................................................................... 42 Figura 45: DS Eliminar cesta venta................................................................................ 42 Figura 46: DS Recoger entradas internet........................................................................ 43 Figura 47: DS Crear usuario........................................................................................... 43 Figura 48: DS Modificar usuario.................................................................................... 44 Figura 49: DS Eliminar usuario...................................................................................... 44 Figura 50: Clase Melomano ........................................................................................... 45 Figura 51: Clase Sala...................................................................................................... 46 Figura 52: Clase Zona .................................................................................................... 46 Figura 53: Clase Interprete ............................................................................................. 47 Figura 54: Clase Obra..................................................................................................... 47 Figura 55: Clase Concierto ............................................................................................. 49 Figura 56: Clase Linea_Abono....................................................................................... 49 Figura 57: Clase Cesta_Abono....................................................................................... 51 Figura 58: Clase Abono_internet.................................................................................... 51 Figura 59: Clase Linea_reserva ...................................................................................... 52 Figura 60: Clase Reserva................................................................................................ 53 Figura 61: Clase Linea_venta ......................................................................................... 54 Figura 62: Clase Cesta_venta ......................................................................................... 55 Figura 63: Clase Venta_internet ..................................................................................... 55 Figura 64: Clase Usuario ................................................................................................ 55 Figura 65: Clase Administrador ..................................................................................... 56 Figura 66: Clase Internauta............................................................................................. 56 Figura 67: Clase Taquillero ............................................................................................ 56 Figura 68: Especialización Usuario................................................................................ 57 Figura 69: Diagrama de clases ....................................................................................... 57 Figura 70: DTE Clase Concierto .................................................................................... 59 Figura 71: DTE Linea_Abono........................................................................................ 59 Figura 72: DTE Cesta_Abono ........................................................................................ 60 Figura 73: DTE Abono_internet..................................................................................... 60 Figura 74: DTE Linea_venta .......................................................................................... 61 Figura 75: DTE Cesta_venta .......................................................................................... 62 Figura 76: DTE Venta_internet ...................................................................................... 62 Figura 77: Tabla Melomano ........................................................................................... 68 Figura 78: Tabla Sala...................................................................................................... 68 Figura 79: Tabla Zona .................................................................................................... 69 Figura 80: Tabla Interprete ............................................................................................. 69
91
Figura 81: Tabla Obra .................................................................................................... 69 Figura 82: Tabla Concierto............................................................................................. 70 Figura 83: Tabla Linea Abono........................................................................................ 70 Figura 84: Tabla Cesta Abono........................................................................................ 71 Figura 85: Tabla Abono Internet .................................................................................... 71 Figura 86: Tabla Linea Reserva ..................................................................................... 72 Figura 87: Tabla Reserva................................................................................................ 72 Figura 88: Tabla Linea Venta......................................................................................... 72 Figura 89: Tabla Cesta Venta ......................................................................................... 73 Figura 90: Tabla Venta Internet...................................................................................... 73 Figura 91: Ventana principal .......................................................................................... 74 Figura 92: Ventana Mantenimiento Melomano.............................................................. 75 Figura 93: Ventana Alta Melomano ............................................................................... 76 Figura 94: Ventana Modificar Melomano...................................................................... 76 Figura 95: Ventana Mantenimiento Sala ........................................................................ 77 Figura 96: Ventana Alta Sala.......................................................................................... 77 Figura 97: Ventana Alta Zonas....................................................................................... 78 Figura 98: Ventana Modificar Sala ................................................................................ 78 Figura 99: Ventana Modificar Zonas.............................................................................. 78 Figura 100: Ventana Mantenimiento Interprete ............................................................. 79 Figura 101: Ventana Modificar Interprete...................................................................... 79 Figura 102: Ventana Mantenimiento Obra..................................................................... 80 Figura 103: Ventana Alta Obra ...................................................................................... 80 Figura 104: Ventana Mantenimiento Concierto ............................................................. 81 Figura 105: Ventana Modificar Concierto...................................................................... 81 Figura 106: Ventana Información Concierto.................................................................. 82 Figura 107: Ventana Datos Concierto ............................................................................ 83 Figura 108: Ventana Datos Cliente ................................................................................ 83 Figura 109: Ventana Confirmación Venta ..................................................................... 84 Figura 110: Ventana Información Concierto Abono...................................................... 85 Figura 111: Ventana Datos Abono ................................................................................. 86 Figura 112: Ventana Confirmación Abono .................................................................... 86
92
93
Bibliografía
[1] Insfrán E., Pelechano V., Pastor O. Conceptual Modeling in the
Extreme.
[2] Insfrán E., , Pastor O., Wieringa R. Requirements Engineering-Based
Conceptual Modeling.
[3] Insfrán E., Molina P.J. , Martí S., Pelechano V. Ingeniería de Requisitos
aplicada al modelado conceptual de interfaz de usuario.
[4]Pastor O., Ramos I. OASIS versión 2 (2.2): A Class-Definition Language
to Model Information System. Servicio de Publicaciones Universidad
Politécnica de Valencia, Valencia, España, 1995. SPUPV-95.788
