Memoria-SilviaBelda Caso de Uso PDF

Modelado conceptual
e
Implementación de un
Sistema
de
Venta de Entradas
Silvia Belda Jañez

silbelja@inf.upv.es
Director del proyecto:

Emilio Insfrán Pelozo
2
Í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
3
4
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.
5
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.
6
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
7
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.
8
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.
9
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
10
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
11
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.
Mantenimiento Compra Reserva

info abonos telefonica
Venta Usuarios
entradas
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.
12
Datos Datos sala Datos zona
melomano
Datos Datos obra Datos

interprete concierto
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
Taquillero
Actualizar melomano
Eliminar melomano
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.
13
<<include>>
Crear sala Crear zonas

(from Datos zona)
<<include>>
Modificar sala Modificar zonas

Administrador
(from Datos zona)
<<include>>
Eliminar sala Eliminar zonas

(from Datos zona)
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
Administrador
Modificar zonas
Eliminar zonas
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.
14
Crear interprete
Administrador
Modificar interprete
Eliminar interprete
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
Administrador
Modificar obra
Eliminar obra
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:
15
Crear concierto
Administrador
Modificar concierto
Eliminar concierto
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.
Crear cesta abono
Recoger abono internet

Taquillero
Confirmar Cesta Abono
Internauta
Administrador Eliminar Cesta Abono

Borrar linea abono
Figura 9: Compra abonos
16
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.
Modificar linea reserva Crear reserva
Taquillero
Borrar linea reserva
Recoger reserva Cancelar reserva
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.
17
Crear cesta
venta
Recoger entradas
Taquillero
internet
Confirmar cesta venta
Modificar linea
Internauta venta
Borrar linea
venta
Eliminar cesta
Administrador
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
Administrador
Modificar usuario
Eliminar usuario
Figura 12: Usuarios
18
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.
19
: Sistem a : Melom ano
: T aquillero
Solicitar crear m elom ano

<<signal>>
Solicitar DNI m elom ano

<<signal>>
Introducir DNI m elom ano

<<signal>>
existe?
<<query>>
Solicitar datos
<<signal>>
Introducir datos
<<signal>>
Crear m elom ano( )
<<service>>new
Figura 13: DS Crear melomano
: S istem a : M elom ano
: T aquillero
Solicitar actualizar m elom ano
Lista=listar m elom anos
<<signal>>
<<query>>
M ostrar lista m elom anos(Lista)
<<signal>>
S eleccione m elom ano

<<signal>>
S eleccionar m elom ano

<<signal>>
D atos=m ostrar datos(dni)
M ostrar datos(Datos) <<query>>
<<signal>>
M odifique m elom ano
<<signal>>
M odificar m elom ano

Actualizar m elom ano
<<signal>> (String, S tring, S tring)
<<service>>update
Figura 14: DS Actualizar melomano
20
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:
: Sistema : Melomano
: Taquillero
Solicitar eliminar melomano
<<signal>>
Lista=listar melomanos
Mostrar lista melomanos(Lista) <<query>>
<<signal>>
Seleccione melomano
<<signal>>
Seleccionar melomano
<<signal>> Eliminar( )
<<service>>destroy
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:
21
: S is te m a : S a la
: A d m in is tr a d o r
S o lic ita r c r e a r s a la
< < s ig n a l> >
S o lic ita r d a to s
< < s ig n a l> >
In tr o d u c ir d a to s
< < s ig n a l> >
U C _C rea r zo n a s
C r e a r _ s a la ( )
< < s e r v ic e > > n e w
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.
: S is t e m a : S a la
: A d m in is t r a d o r
S o lic ita r m o d ific a r s a la
L is ta = lis t a r s a la s
< < s ig n a l> >
M o s tr a r lis ta s a la s ( L is t a ) <<query>>
< < s ig n a l> >
S e le c c io n e s a la
< < s ig n a l> >

S e le c c io n a r s a la
< < s ig n a l> >

D a to s = m o s tr a r d a to s (id )
M o s tr a r d a to s (D a to s ) <<q uery>>
< < s ig n a l> >

M o d ifiq u e s a la
< < s ig n a l> >
M o d ific a r s a la
< < s ig n a l> > U C _ M o d ific a r z o n a s
M o d ific a r _ s a la ( S tr in g )
< < s e r v ic e > > u p d a te
Figura 17: DS Modificar sala
22
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):
: Sistema : Sala
: Administrador
Solicitar eliminar sala
<<signal>> Lista=listar salas
Mostrar lista salas(Lista) <<query>>

<<signal>>
Seleccione sala
<<signal>>
Seleccionar sala UC_Eliminar zonas

<<signal>>
Eliminar_sala( )
<<service>>destroy
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.
: Sistema : Sala : Zona
: Administrador
Solicitar crear zona

<<signal>>
Introducir id sala
<<signal>> existe?
<<query>>
Solicitar tipo
ona
<<signal>>
Introducir tipo
ona
<<signal>>
Solicitar datos
<<signal>>
Introducir datos
<<signal>> Crear_zona( )
<<service>>new
Figura 19: DS Crear zonas
23
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
Solicitar modificar zona
<<signal>>
Introducir id sala
<<signal>> existe?
<<query>>
Lista=listar zonas
Mostrar lista zonas(Lista) <<query>>
<<signal>>
Seleccione zona
<<signal>>
Seleccionar zona
<<signal>> Datos=mostrar datos(tipo)
Mostrar datos(Datos) <<query>>
<<signal>>
Modifique zona
<<signal>>
Modificar zona
Modificar_zona(Integer, String)
<<signal>>
<<service>>update
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:
24
: Administrador
Solicitar eliminar zona

<<signal>>
Introducir id sala
<<signal>> existe?
<<query>>
Lista=listar zonas
<<query>>
Mostrar lista zonas(Lista)
<<signal>>
Seleccione zona
<<signal>>
Selecionar zona
<<signal>>
Eliminar_zona( )
<<service>>destroy
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.
: Sistema : Interprete
: Administrador
Solicitar crear interprete

<<signal>>
Solicitar datos
<<signal>>
Introducir datos
<<signal>>
Crear_interprete( )
<<service>>new
Figura 22: DS Crear interprete
25
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
Solicitar modificar interprete
<<signal>> Lista=listar interpretes
<<query>>
Mostrar lista interpretes(Lista)
<<signal>>
Seleccione interprete
<<signal>>
Seleccionar interprete
<<signal>>
Datos=mostrar datos(id)
<<query>>
Mostrar datos(Datos)
<<signal>>
Modifique interprete
<<signal>>
Modificar interprete
<<signal>> Modificar_interprete(String, String)
<<service>>update
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:
26
: Administrador
Solicitar eliminar interprete

<<signal>>
Lista=listar interpretes
Mostrar lista interpretes(Lista) <<query>>
<<signal>>
Seleccione interprete
<<signal>>
<<signal>>
Eliminar_interprete( )
<<service>>destroy
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:
: Sistema : Obra
: Administrador
Solicitar crear obra

<<signal>>
Solicitar datos
<<signal>>
Introducir datos
<<signal>>
Crear_obra( )
<<service>>new
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:
27
: S iste m a : O bra
: Adm inistra dor

S olic ita r m o d ific a r o b ra
< < s ig n a l>> L is ta = lis ta r o b ras
<<query >>
M os tra r lista o b ra s (L is ta )
<<signal>>
S e le c c io ne o b ra
<<s ig n a l>>
S e le cc ionar obra
<<signal>>
D a tos =m ostra r da tos (id)
M os tra r da tos(D a tos ) <<query >>

<<signal>>
M odifique obra
<<signal>>
M odificar obra
< < s ig n a l>> M odifica r obra (S tring)
< < s e rv ice > > u p d a te
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:
: Sistema : Obra
: Administrador
Solicitar eliminar obra
<<signal>>
Lista=listar obras
Mostrar lista obras(Lista) <<query>>

<<signal>>
Seleccione obra
<<signal>>
Seleccionar obra
<<signal>>
Eliminar obra( )
<<service>>destroy
Figura 27: DS Eliminar obra
28
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:
: Sistema : Concierto : Obra : Interprete : Sala

: Administrador
Solicitar crear concierto

<<signal>>
Solicitar datos
<<signal>>
Introducir datos
<<signal>>
Seleccionar obra
<<select>>
<<select>>
Seleccionar sala
<<select>>
Crear concierto( )
<<service>>new
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:
29
: Sistema : Concierto
: Administrador
Solicitar modificar concierto
<<signal>> Lista=listar conciertos
<<query>>
Mostrar lista conciertos(Lista)
<<signal>>
Seleccione concierto
<<signal>>
Seleccionar concierto
<<signal>>
Mostrar datos(Datos) <<query>>

<<signal>>
Modifique datos
<<signal>>
Modificar datos
<<signal>> Modificar concierto( )
<<service>>update
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:
: Sistema : Concierto
: Administrador
Solicitar eliminar concierto
<<signal>>
Lista=listar conciertos
<<query>>
Mostrar lista conciertos(Lista)
<<signal>>
Seleccione concierto
<<signal>>
<<signal>> Eliminar concierto( )
<<service>>destroy
Figura 30: DS Eliminar concierto
30
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:
: Sistema : Cesta : Melomano : Linea : Concierto : Zona

Abono Abono
: Internauta : Taquillero
si (actor =
Solicitar crear abono
internauta)
Crear cesta abono( )
<<signal>>
<<service>>new
Solicitar datos cliente
<<signal>>
Introducir datos cliente Seleccionar
<<signal>> melomano
Loop
<<select>>
Crear linea abono( ) End Loop

<<service>>new
<<select>>
Seleccionar zona
<<select>>
PrecioUnitario=obtener
i <<query>>
Precio=obtener
<<query>
Precio final
Mostrar Precio
<<signal
Figura 31: DS Crear cesta abono
31
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:
: Sistema : Abono
: Cesta : Concierto
Abono internet
: Entidad : Taquillero
: Internauta financiera
Solicitar confirmar abono
<<signal>
Seleccione abono
<<signal>
Seleccionar abono
<<signal>
Obtener info abono
<<query>>
Comprobar si existe disponibilidad
<<query>
Realice pago
<<signal>
Mostrar Precio SI (pago con tarjeta
<<signal> de credito)
(actor=internauta)
Introducir num_tarjeta
<<signal>
Enviar pago(num_tarjeta,Precio)
<<signal>
SI pago en
Transaccion correcta efectivo
<<signal>
Realizar pago efectivo

<<signal>
Modif atrib vendidos( )

<<service>>update
[if actor=internauta]Incrementar
Abono Internet( )
<<service>>update
Aceptar cesta abono( )
<<service>>update
Figura 32: DS Confirmar cesta abono
32
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:
: Sistema : Cesta : Linea

Ab Ab
Solicitar borrar linea abono

<<signal>> Lista=listar abonos
<<query>>
Mostrar lista abonos(Lista)
<<signal>>
Seleccione abono
<<signal>>
Seleccionar linea abono

<<signal>>
Seleccionar linea abono

<<signal>>
Borrar linea abono( )
<<service>>destroy
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.
: Sistema : Cesta
Abono
: Administrador
Solicitar eliminar abono

<<signal>>
Lista=listar abonos
Mostrar lista abonos(Lista) <<query>>
<<signal>>
Seleccione abono
<<signal>>
Seleccionar abono
<<signal>>
Eliminar cesta abono( )
<<service>>destroy
Figura 34: DS Eliminar cesta abono
33
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:
: Sistema : Melomano : Abono

internet
: Taquillero
Solicitar recoger abono

<<signal>>
Introduzca DNI melomano

<<signal>>
Introducir DNI melomano

<<signal>>
existe?
<<query>>
[if Recogido=false]seleccionar abono

Mostrar abono
<<select>>
<<signal>>
Recoger abono( )
<<service>>update
Figura 35: DS Recoger abono internet

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:
34
: Linea
: Sistema : Reserva : Melomano reserva : Concierto : Zona
: Taquillero
Solicitar crear venta

<<signal> Crear reserva( )
<<service>>new

<<signal>
Introducir datos cliente
<<signal>
Seleccionar melomano
Loop
<<select>
Crear linea reserva( )

<<service>>new
<<select>
Seleccionar zona
<<select>
PrecioUnitario=obtener precio
<<query>
Introducir cantidad
<<signal> End
Calcular PrecioTotal linea Loop
<<query>
PrecioReserva
Mostrar PrecioReserva
<<signal>
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.
35
: Sistema : Reserva : Linea
reserva
: Taquillero
Solicitar modificar linea reserva

<<signal>>
Lista=listar reservas
<<query>>
Mostrar lista reservas(Lista)
<<signal>>
Seleccione reserva
<<signal>>
Seleccionar linea reserva

<<signal>>

<<signal>>
Datos=mostrar datos(id_LineaReserva)
<<query>>
<<signal>>
Modifique cantidad
<<signal>>
Modificar cantidad
<<signal>> Modificar linea reserva( )
<<service>>update
Figura 37: DS Modificar linea reserva
: Sistema : Reserva : Linea

reserva
: Taquillero
Solicitar borrar linea
<<signal>> Lista=listar reservas
<<query>>
Mostrar lista reservas(Lista)
<<signal>>
Seleccione reserva
<<signal>>
<<signal>>
<<signal>>
Borrar linea reserva( )
<<service>>destroy
Figura 38: DS Borrar linea reserva
36
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:
: Sistema : Reserva
: Taquillero
Solicitar cancelar reserva
<<signal>>
Introduzca DNI cliente
<<signal>>
Introducir DNI
li<<signal>>
t
Mostrar lista reservas

<<signal>>
Seleccione una reserva
<<signal>>
Seleccionar una reserva
<<signal>>
Cancelar reserva( )
<<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:
37
: Sistema : Melomano : Reserva
: Entidad financiera : Taquillero
Solicitar recoger reserva

<<signal>>
<<signal>>

<<signal>>
existe?
<<query>>
[if recogida=false]seleccionar reserva
<<select>>
SI pago con
Muestra reservas
tarjeta
<<signal>>
Elegir reserva
<<signal>>
SI pago en
Realice pago efectivo
<<signal>>
Mostrar precio venta

<<signal>>
<<signal>>
Enviar pago(num_tarjeta,Precio_venta)
<<signal>>
Transaccion correcta
<<signal>>

<<signal>>
Recoger reserva( )
<<service>>update
Figura 40: DS Recoger reserva

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
38
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:
: Sistema : Cesta : Melomano : Linea : Concierto : Zona

venta venta
Solicitar crear venta si (actor =
internauta)
<<signal Crear cesta venta( )
<<service>>new

<<signal>>
Introducir datos cliente
<<signal>> Seleccionar melomano
<<select> Loop
Crear linea venta( )

<<service>>new
<<select>>
Seleccionar zona
<<select>
PrecioUnitario=obtener precio
<<query
Introducir cantidad
<<signal Calcular PrecioTotal End

linea Loop
<<query
PrecioVenta
Mostrar PrecioVenta
<<signal>>
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:
39
: Sistema : Cesta : Linea venta
Venta
: Taquillero
Solicitar modificar linea venta

<<signal>>
Lista=listar ventas
<<query>>
Mostrar lista ventas(Lista)
<<signal>>
Seleccione venta
<<signal>>
Seleccionar linea venta

<<signal>>

<<signal>>
Datos=mostrar datos(id_LineaVenta)
<<query>>
<<signal>>
Modifique cantidad
<<signal>>
Modificar cantidad
<<signal>> Modificar linea venta( )
<<service>>update
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.
40
A continuación se presenta el diagrama de secuencia:
: Sistema : Venta
: Cesta : Concierto
Venta internet
: Entidad : Taquillero
: Internauta financiera
Solicitar confirmar venta
<<signal>
Seleccione venta
<<signal>
Seleccionar venta
<<signal>
Obtener info venta
<<query>>
Comprobar si existe disponibilidad
<<query>
Realice pago
<<signal>
Mostrar PrecioVenta SI (pago con tarjeta
<<signal> de credito)
(actor=internauta)
<<signal>
Enviar pago(num_tarjeta,Precio)
<<signal> SI pago en
Transaccion correcta efectivo
<<signal>

<<signal>
Modif atrib vendidos( )

<<service>>update
[if actor=internauta]Incrementar
V Internet( )
<<service>>update
Aceptar venta( )
<<service>>update
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:
41
: Sistema : Cesta : Linea
Venta Venta
Solicitar borrar linea venta

<<signal>> Lista=listar ventas
<<query>>
Mostrar lista ventas(Lista)
<<signal>>
Seleccione venta
<<signal>>

<<signal>>

<<signal>>
Borrar linea venta( )
<<service>>destroy
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:
: Sistema : Cesta venta
: Administrador
Solicitar eliminar
t
<<signal>>
Lista=listar ventas
Mostrar lista ventas(Lista) <<query>>

<<signal>>
Seleccione venta
<<signal>>
Seleccionar venta
<<signal>>
Eliminar cesta venta( )
<<service>>destroy
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
42
Internet. Tras obtener su identificación comprueba la existencia de las entradas
y le proporciona las mismas. El diagrama queda de la siguiente manera:
: Sistema : Melomano : Venta internet
: Taquillero
Solicitar recoger entradas

<<signal>>

<<signal>>

<<signal>>
existe?
<<query>>
Mostrar venta [if Recogida=false]seleccionar venta
<<select>>
<<signal>>
Recoger entradas( )
<<service>>update
Figura 46: DS Recoger entradas internet

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.
: Sistema : Usuario
: Administrador
Solicitar crear usuario

<<signal>>
Solicitar datos
<<signal>>
Introducir datos
<<signal>>
Crear_ usuario( )
<<service>>new
Figura 47: DS Crear usuario
43
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:
: Sistema : Usuario
: Administrador
Solicitar modificar usuario
<<signal>> Lista=listar usuarios
<<query>>
Mostrar lista usuarios(Lista)
<<signal>>
Seleccione usuario
<<signal>>
Seleccionar usuario
<<signal>>
<<query>>
<<signal>>
Modifique usuario
<<signal>>
Modificar usuario
<<signal>> Modificar_usuario(String)
<<service>>update
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:
: Sistema : Usuario
: Administrador
Solicitar eliminar usuario

<<signal>>
Lista=listar usuarios
Mostrar lista usuarios(Lista) <<query>>

<<signal>>
Seleccione usuario
<<signal>>
Seleccionar usuario
<<signal>>
Eliminar_ usuario( )
<<service>>destroy
Figura 49: DS Eliminar usuario
44
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
45
• 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
46
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.
47
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
ReservadoZ1, ReservadoZ2, ReservadoZ3: es el número de

plazas reservadas de cada zona de la sala en la que se
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)
TotalZ1 Sala.Zona1.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
48
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
49
• 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 clase Cesta_Abono:
50
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:

PrecioUnit Zona.Tipo=”Anfiteatro” Concierto.PrecioZ1
PrecioUnit Zona.Tipo=”Coro” Concierto.PrecioZ2
PrecioUnit Zona.Tipo=”Palco” Concierto.PrecioZ3
PrecioTotal Cantidad*PrecioUnitario
51
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:
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)
52
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:

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
53
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:
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 clase Cesta_venta:
54
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
55
• 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.
56
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
57
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

• 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

• 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:
58
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
59
• Cesta_Abono: el DTE correspondiente a las cestas de abonos se
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
60
• Linea_Reserva: No tiene comportamiento especial
• Reserva: No tiene comportamiento especial
• Linea_venta: el DTE correspondiente a las líneas de venta se

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

Cesta_0: Cesta no aceptada.
Aceptada: Cesta aceptada
61
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.
62
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
De Estado Modificar =nuevoApellido
o Telefono
De Estado Modificar =nuevoTelefono
o Direccion
De Estado Modificar =nuevaDireccion
• Sala
o Nombre
o Descripcion
De Estado Modificar =nuevaDesc
• Zona
o Descripcion
De Estado Modificar =Desc
o NumPlazas
De Estado Modificar =Plazas
• Interprete
o Nombre
63
o Descripcion
• Obra
o Titulo
De Estado Modificar =nuevoTitulo
o Descripcion
• Concierto
o Celebrado
De Situación Celebrar =true false
o Menos2Horas
De Estado DosHoras =true false
o PrecioZ1, PrecioZ2, PrecioZ3
De Estado Modificar =nuevoPrecio
o ReservadoZ1, ReservadoZ2, ReservadoZ3

Cardinal CancelarReserva - Cantidad
Cardinal RecogerReserva - Cantidad
Cardinal CrearReserva + Cantidad
o VendidosZ1, VendidosZ2, VendidosZ3
Cardinal ConfirLineVenta + Cantidad
Cardinal ConfirLineAbono +1
Cardinal RecogerReserva + Cantidad
• Cesta_Abono
o Aceptada
oCategoría Evento Efecto Condición Valor Actual
De Situación Aceptar =True False
TipoInternet
De Situación AceptaInt =True False
64
• Abono_internet
o Recogido
De Situación Recoger_abono =True False
• Linea_reserva
o Cantidad
De Estado Mod_cantidad =cant
• Reserva
o Recogida
De Situación RecogerReserva =true false
• Linea_venta
o Cantidad
De Estado Mod_cantidad =cant
• Cesta_venta
o Aceptada
De Situación Aceptar =True False
o TipoInternet
De Situación AceptaInt =True False
• Venta_internet
o Recogida
De Situación Recoger =True False
• Administrador
o dni
De Estado Modificar =nuevoDNI
o Nombre
De Estado Modificar =nuevoNomb
65
• Taquillero
o dni_taq
De Estado Modificar =nuevoDNI
o Nombre_taq
De Estado Modificar =nuevoNomb
66
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.
67
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
68
• 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:
69
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:
70
• 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:
71
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:
72
• 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
73
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
74
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.
75
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
76
• 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
77
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
78
• 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
79
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
80
• 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
81
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.
82
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
83
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:
84
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.
85
Figura 111: Ventana Datos Abono
Figura 112: Ventana Confirmación Abono
86
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.
87
88
Í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
89
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
90
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
91
92
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
93

Memoria-SilviaBelda Caso de Uso PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria-SilviaBelda Caso de Uso PDF

Cargado por

Copyright:

Formatos disponibles

Modelado conceptual

Silvia Belda Jañez

Director del proyecto:

1.1. Objetivos ......................................................................................................... 5

2.1. Árbol de refinamiento de funciones .............................................................. 10

3. MODELO CONCEPTUAL .................................................................................. 45

3.1. Modelo de objetos......................................................................................... 45

4. DISEÑO DE LA BASE DE DATOS RELACIONAL ................................................ 67

El proyecto propuesto se sitúa en el ámbito de la Ingeniería de Requisitos

Los objetivos a cumplir por el presente proyecto se estructuran en los

• Validar el modelo de requisitos a través de la elaboración de un caso

• Capturar todas las propiedades del sistema (estáticas y dinámicas)

• Realizar la aplicación del caso de estudio analizado.

Después de la Introducción, el documento está organizado de la

• El capítulo 2 está dedicado al modelo de requisitos. Se

• En el capítulo 3 se presenta el modelado conceptual del sistema

• El capítulo 4 se centra en la creación y diseño de la base de

• El capítulo 5 muestra la interfaz que se ha creado para la

• En el capítulo 6 se comentan las conclusiones a las que se ha

Se desea desarrollar una aplicación que permita la venta de entradas

Se debe distinguir entre tres tipos de usuarios de la aplicación:

El Palau está dividido en diversas salas de audición, donde se realizan los

Dentro de cada sala existen varios tipos de entradas o localidades,

Un comité artístico se encarga de planificar y contratar los conciertos

A la hora de realizar una venta por taquilla, el comprador indica al

Para realizar una compra por Internet el procedimiento es el mismo, la

Otra posibilidad que el Palau ofrece a sus clientes es la compra de

El mecanismo para comprar un abono tanto en taquilla como a través

Desde la temporada pasada se ha puesto en marcha un sistema de

Las entradas reservadas se pueden recoger hasta 2 horas antes del

Un cliente no puede reservar más de ocho entradas por tipo de

Siempre existe la posibilidad de cancelar una reserva, incluso

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,

Las reservas únicamente podrán realizarse telefónicamente, nunca en

El modelo de requisitos contiene una descripción de los objetivos y del

2.1. Árbol de refinamiento de funciones

El árbol de refinamiento de funciones está asociado con los objetivos

La raíz es la misión del sistema. Los nodos intermedios son grupos de

Con la lista de funcionalidades hemos elaborado un Árbol de

Nodo raíz: Sistema de ventas

El siguiente paso, consiste en transformar las funciones contenidas en el

A continuación mostramos los diagramas de casos de uso

Mantenimiento Compra Reserva

Figura 1: Vista del caso de uso general

1. Mantenimiento info: aquí están incluídos los paquetes relacionados

Datos Datos obra Datos

Figura 2: Mantenimiento info

1.1. Datos melómano: como su propio nombre indica es la gestión de los

El taquillero, encargado de realizar la gestión de los melómanos, es el

Figura 3: Datos melomano

Crear sala Crear zonas

Modificar sala Modificar zonas

Eliminar sala Eliminar zonas

Figura 4: Datos sala

Figura 5: Datos zona

1.4. Datos interprete: es el administrador el encargado de realizar el

Como podemos ver podremos tanto crear un intérprete, como

Figura 6: Datos interprete

1.5. Datos obra: gestiona el mantenimiento de los datos relacionados

Figura 7: Datos obra

1.6. Datos concierto: gestión de los datos relacionados con la