02.texto Completo

FACULTAD DE
INGENIERA DE SISTEMAS

UNIVERSIDAD DE MEDELLN
MEDELLN
2005

IMPLEMENTACIN DE UN PROTOTIPO PARA LA GESTIN
ADMINISTRATIVA DEL PARQUE DE DIVERSION DEL CENTRO COMERCIAL
SANDIEGO, CON UN LECTOR Y TARJETAS MAGNETICAS.

FABIAN ELI GOMEZ MURILLO

FACULTAD DE INGENIERA DE SISTEMAS
MEDELLN
2005

IMPLEMENTACIN DE UN PROTOTIPO PARA LA GESTIN
ADMINISTRATIVA DEL PARQUE DE DIVERSION DEL CENTRO COMERCIAL
SANDIEGO, CON UN LECTOR Y TARJETAS MAGNETICAS.

FABIAN ELI GOMEZ MURILLO

Trabajo para optar al ttulo de Ingeniero de Sistemas

ASESORES
DIANA MARIA MONTOYA

FACULTAD DE INGENIERA DE SISTEMAS
MEDELLN
2005

NOTA DE ACEPTACIN

_____________________________________
_____________________________________
_____________________________________

_____________________________________
ASESOR TEMTICO

_____________________________________
_____________________________________
_____________________________________
JURADO

A mi madre, que ha sabido apoyarme como le ha sido
posible, de una manera incondicional y que con el
ejemplo y educacin que me ha dado me ha permitido
lograr mis metas.
Fabin El Gmez

AGRADECIMIENTOS

Expreso mis agradecimientos a:

La asesora Diana Mara Montoya, por sus orientaciones en el transcurso del
proyecto

La universidad de Medelln, por brindarme un espacio acogedor durante mi vida
universitaria, donde no slo aprend de la ingeniera de sistemas, sino que tambin
a formarme como un ser ntegro.

A mi madre Lucia, a mi esposa Bibiana y a mis hijos Juan Pablo y Danna Leandra.
Que supieron entender todo el tiempo que invert en mi estudio, me apoyaron
incondicionalmente y se convirtieron en mi mayor motivacin.

A los Gerentes de Divertrnica Medelln S.A.: Lus Guillermo Hoyos y Julin
Hoyos, por facilitarme todo el tiempo que me tuve que ausentar de la empresa
para fines de estudio, durante la carrera y el trabajo de grado.

VII

TABLA DE CONTENIDO

Pg.
INTRODUCCIN ...............................................................................................................15
RESUMEN EJECUTIVO ...................................................................................................16
ABSTRACT .........................................................................................................................17

1. PLANTEAMIENTO Y JUSTIFICACIN .................................................................18
1.1. ANTECEDENTES HISTRICOS DE LA EMPRESA...................................18
1.1.1 Historia de DIVERTRONICA MEDELLN S.A. ......................................18
1.1.2 Funcionamiento de la empresa ...............................................................19
1.1.3 Direccionamiento estratgico ...................................................................19
1.1.4 Organigrama ...............................................................................................21
1.2. FORMULACIN DEL PROBLEMA.................................................................21
1.3. JUSTIFICACIN ................................................................................................22

2. MARCO TERICO ....................................................................................................24
2.1. ESTADO DEL ARTE .........................................................................................24
2.2. TARJETAS MAGNTICAS ..............................................................................25
2.3. LECTORES .........................................................................................................28
2.4. UML ......................................................................................................................31
2.4.1 Una breve historia ......................................................................................31

3. PLANEACIN Y ELABORACIN DEL SISTEMA ...............................................67
3.1. Sistema Actual (DIVERTRONICA MEDELLIN S.A.) ....................................67
3.2. Ciclo de Vida .......................................................................................................68

VIII
3.3. mbito del Software...........................................................................................70
3.3.1 Descomposicin .........................................................................................70
3.4. OBJETIVOS ........................................................................................................71
3.4.1 Objetivo General ........................................................................................71
3.4.2 Objetivos especficos.................................................................................71
3.5 DISEO METODOLOGICO .............................................................................72
3.5.1 METODOLOGA DE DESARROLLO .....................................................72
3.5.2 INSTRUMENTOS Y TCNICAS DE RECOLECCIN DE DATOS...72
3.6. ALCANCES DEL SISTEMA .............................................................................73
3.6.1 Mdulo Lectores .........................................................................................73
3.6.2 Mdulo Atracciones ...................................................................................73
3.6.3 Mdulo Pos .................................................................................................74
3.6.4 Mdulo Administrativo ...............................................................................74
3.7. RESULTADOS ESPERADOS .........................................................................74
3.8. BENEFICIOS DEL SISTEMA...........................................................................76
3.8.1 Beneficios Econmicos .............................................................................76
3.8.2 Beneficios Administrativos........................................................................76
3.9. RESTRICCIONES DEL SISTEMA ..................................................................76
3.10. ESTUDIO DE FACTIBILIDAD Y VIABILIDAD ...........................................77
3.10.1 RECURSOS ECONOMICOS ...................................................................77
3.10.2 Presupuesto ................................................................................................78
3.10.3 Recursos Informticos...............................................................................79
3.11. REQUERIMIENTOS DEL SISTEMA ..........................................................81
3.11.1 Documentacin de los Casos de Uso. ...................................................81
3.11.2 Requerimientos no Funcionales ..............................................................95
3.11.3 Requerimientos de Prestaciones.............................................................95
3.11.4 Requerimientos de Interfaz ......................................................................95
3.11.5 Requerimientos de Operaciones .............................................................96
3.11.6 Requerimientos de Entorno de Desarrollo.............................................96
3.11.7 Requerimientos de Verificacin ...............................................................96

IX
3.11.8 Requerimientos de Pruebas de Aceptacin ..........................................96
3.11.9 Requerimientos de Documentacin ........................................................96
3.12. RESTRICCIONES DE DISEO ..................................................................96
3.13. ATRIBUTOS DE CALIDAD ..........................................................................97
3.13.1 Seguridad ....................................................................................................97
3.13.2 Portabilidad .................................................................................................97
3.13.3 Revisiones de Calidad...............................................................................97
3.13.4 Confiabilidad ...............................................................................................97
3.13.5 Mantenibilidad.............................................................................................97

4. MODULO LECTORES ..............................................................................................98
4.1. OBJETIVOS ........................................................................................................98
4.2. Casos de uso ......................................................................................................98
4.2.1 Caso de uso: MATRICULA DE LECTORES .........................................98
4.2.2 Caso de uso: CONSULTA DE LECTORES...........................................99
4.2.3 Caso de uso: MODIFICAR LECTORES.............................................. 100
4.2.4 Caso de uso: CONFIGURACIN DE LECTORES ........................... 100
4.2.5 Caso de uso: CONSULTA DE CONFIGURACION DE LECTORES
101
4.2.6 Caso de uso: MODIFICACIN DE LA CONFIGURACIN DE
LECTORES .............................................................................................................. 102
4.3. DIAGRAMA DE CASOS DE USO ................................................................ 103
4.4. DICCIONARIO DE DATOS ........................................................................... 104
4.4.1 Tabla: LECTOR ....................................................................................... 104
4.4.2 Tabla: CF_LECTOR: .............................................................................. 105
4.5. RELACIONES.................................................................................................. 106
4.6. REPORTES GENERADOS........................................................................... 107

5. MODULO ATRACCIONES .................................................................................... 108
5.1. OBJETIVOS ..................................................................................................... 108

X
5.2. CASOS DE USO ............................................................................................. 108
5.2.1 Caso de uso: MATRICULA DE ATRACCIONES ............................... 108
5.2.2 Caso de uso: CONSULTA DE ATRACCIONES ................................ 109
5.2.3 Caso de uso: MODIFICACIN DE ATRACCIONES ............................ 109
4.4. DIAGRAMA DE ESTADOS ........................................................................... 111
4.6. RELACIONES.................................................................................................. 113

6. MODULO POS (PUNTO DE VENTA) ................................................................. 115
6.1. OBJETIVOS ..................................................................................................... 115
6.2. CASOS DE USO ............................................................................................. 115
6.2.1 Caso de uso: MATRICULA DE POS (PUNTO DE VENTA) ............ 115
6.2.2 Caso de uso: CONSULTAR POS (PUNTO DE VENTA).................. 116
6.2.3 Caso de uso: MODIFICAR POS (PUNTO DE VENTA) .................... 116
6.2.4 Caso de uso: APERTURA DE CAJA ................................................... 117
6.2.5 Caso de uso: CORTE DE CAJA........................................................... 117
6.2.6 Caso de uso: EXPULSAR TARJETA DEL LECTOR ........................ 118
6.2.7 Caso de uso: VENTA DE TARJETAS ................................................. 118
6.2.8 Caso de uso: CONSULTA DE VENTAS ............................................. 119
6.2.9 Caso de uso: DEVOLUCIN DE VENTAS ........................................ 120
6.2.10 Caso de uso: CONSULTA DE CARGA DE TARJETAS................... 120
6.4.1 Tabla: POS............................................................................................... 123
6.4.2 Tabla: FACTURA: ................................................................................... 123
6.4.3 Tabla: TURNO: ........................................................................................ 124
6.5. RELACIONES.................................................................................................. 126

XI

7. MODULO USUARIOS ............................................................................................ 128
7.1. OBJETIVOS ..................................................................................................... 128
7.2. CASOS DE USO ............................................................................................. 128
7.2.1 Caso de uso: CREAR USUARIO ......................................................... 128
7.2.2 Caso de uso: MODIFICAR USUARIO ................................................. 129
7.4.1 Tabla: Usuario: ........................................................................................ 130
7.5. RELACIONES.................................................................................................. 132

8. MODULO ADMINISTRATIVO............................................................................... 133
8.1. OBJETIVOS ..................................................................................................... 133
8.2. CASOS DE USO ............................................................................................. 133
8.2.1 Caso de Uso: Registro de la Empresa ................................................ 133
8.2.2 Caso de Uso: Matrcula de Lneas ....................................................... 134
8.2.3 Caso de Uso: Modificacin de Lneas ................................................. 135
8.2.4 Caso de Uso: Ventas de Atraccin ...................................................... 136
8.4.1 Tabla: EMPRESA.................................................................................... 137
8.4.2 Tabla: VENTASXATRACCION: ............................................................ 138
8.5. RELACIONES.................................................................................................. 140

9. DISEO GENERAL ................................................................................................ 143
9.1. OBJETIVOS ..................................................................................................... 143
9.2. CASOS DE USO ............................................................................................. 143
9.2.1 Caso de Uso: Conectar base de datos................................................ 143

XII
3.7. DIAGRAMA DE ACTIVIDADES.................................................................... 145
9.4. DIAGRAMA DE COMPONENTES ............................................................... 146

ANEXO II .......................................................................................................................... 148
ANEXO II .......................................................................................................................... 149
ANEXO III ......................................................................................................................... 150
MANUAL DEL USUARIO .............................................................................................. 151
CONCLUSIONES ........................................................................................................... 181
BIBLIOGRAFA................................................................................................................ 182
GLOSARIO ...................................................................................................................... 185

XIII

LISTA DE ILUSTRACIONES

Pg.
Ilustracin 1 - Organigrama ..............................................................................................21
Ilustracin 2 - Actores y Casos de uso. ..........................................................................53
Ilustracin 3 - Nombres simples y de camino................................................................54
Ilustracin 4 - Ejemplo de Diagrama de Casos de uso................................................58
Ilustracin 5 - Ejemplo de Diagrama de Actividades....................................................60
Ilustracin 6 - Lectores Diagrama de Casos de Uso ............................................. 103
Ilustracin 7 - Lectores Relaciones........................................................................... 106
Ilustracin 8 - Lectores Listado de Lectores............................................................ 107
Ilustracin 9 - Lectores Listado de Lectores por Atraccin ................................... 107
Ilustracin 10 - Atracciones Diagrama de Casos de Uso ..................................... 110
Ilustracin 11 - Uso de una atraccin por un cliente Diagrama de Estados ...... 111
Ilustracin 12 - Atracciones - Relaciones .................................................................... 113
Ilustracin 13 - Atracciones Listado de Atracciones .............................................. 114
Ilustracin 14 - Atracciones Listado de Atraccin por Lector ............................... 114
Ilustracin 15 - Pos (Punto de Venta) Diagrama de Casos de Uso .................... 122
Ilustracin 16 - Pos - Relaciones .............................................................................. 126
Ilustracin 17 Pos Ventas de Pos.......................................................................... 127
Ilustracin 18 - Usuarios Diagrama de Casos de Uso ....................................... 130
Ilustracin 19 - Usuarios - Relaciones ......................................................................... 132
Ilustracin 20 - Administrativo Diagrama de Casos de Uso ................................. 137
Ilustracin 21 - Administrativo - Relaciones................................................................ 140
Ilustracin 22 - Administrativo Ventas por Atraccin ............................................. 141
Ilustracin 23 Administrativo Ventas por Lnea ................................................... 142
Ilustracin 24 - Principal Diagrama de Casos de Uso ........................................... 144

XIV

LISTA DE TABLAS

Pg.

Tabla 1 - Presupuesto .......................................................................................................79
Tabla 2 - Lectores Lectores del Parque ................................................................... 104
Tabla 3 - Lectores Configuracin de Lectores ........................................................ 105
Tabla 4 - Atracciones Informacin Bsica de Atracciones ................................... 112
Tabla 5 - Pos - Punto de Venta ................................................................................... 123
Tabla 6 - Pos Factura . ................................................................................................ 124
Tabla 7 - Pos - Corte. ..................................................................................................... 125
Tabla 8 - Usuario Usuarios de la Aplicacin ........................................................... 131
Tabla 9 - Administrativo Empresa. ............................................................................ 138
Tabla 10 - Administrativo Ventas por Atraccin. .................................................... 139
Tabla 11 - Administrativo Lnea................................................................................. 139

15

INTRODUCCIN

En el transcurso de ste proyecto, se desarroll un prototipo de software que
apoya la gestin administrativa del parque de recreacin del Centro Comercial
Sandiego de la empresa DIVERTRONICA MEDELLN S.A.

Con base en los requerimientos de gestin administrativa del parque de recreacin
Sandiego, se proporciona un prototipo del sistema, en el cual su parte fundamental
es el manejo de del lector y las tarjetas de banda magntica. Estos dos elementos
estn ocupando un lugar muy importante en el comercio alrededor del mundo,
conocindosele a este como la filosofa del dinero plstico.

El proyecto consisti en elaborar un prototipo que agilizar la gestin del parque
de diversin Sandiego en los siguientes aspectos: Venta de tarjetas magnticas
cargadas con dinero, uso de las atracciones a travs de un lector de tarjetas (claro
que para esto se tendra que tener todo el parque en red, que podra
implementarse en un futuro), liquidacin de las atracciones para ver sus ventas
individuales, tener un inventario de atracciones y lectores instalados en el parque.

Para el desarrollo de proyectos con un alto grado de complejidad, requieren de un
diagnstico y una gestin previa para garantizar que la herramienta a disear e
implementar, cumpla con los objetivos propuestos, y tambin satisfaga la
necesidad planteada. Esto se logra con la recoleccin de datos relacionados con
el sistema y definiendo un objetivo claro para llegar al feliz trmino del trabajo.

16

RESUMEN EJECUTIVO

El presente trabajo de grado tiene como objetivo el estudio de la sistematizacin
de la gestin administrativa del parque de diversin de DIVERTRONICA
MEDELLIN S.A., con proyeccin a los otros parques de la empresa.

La necesidad de un sistema eficaz que ayude a la gestin administrativa de
parques de recreacin, requiere el uso de tcnicas y principios de desarrollo de
software y hardware. Es por esto, que en este trabajo se hizo un anlisis, diseo y
evaluacin de un programa para este fin.

Con base en los objetivos trazados y los requerimientos deseados por la empresa,
se propone un sistema apropiado para llevar a cabo los procesos administrativos
beneficiando a la empresa en un alto grado, a travs de una sencilla interfase, en
ambiente grafico. Finalmente, se presenta un prototipo gil y amigable para el
usuario.
Para facilitar el entendimiento del sistema se ha dividido por mdulos, que he
desarrollado usando la notacin UML. Estos mdulos son: Lectores, Atracciones,
Pos y Administrativo.

17

ABSTRACT
The present graduation work has as goal the study of the systematizing of the
management of entertain parks of DIVERTRONICA MEDELLIN S.A., with
projection to the others parks of the enterprise.

The need of a system effective that may help the management of entertain parks,
requires the use of techniques and principles of software development and
hardware. This is the reason why an analisys was made carefuly, design and
evaluation of a program for this work.

According to the objectives design and the requirements needs for enterprise, it is
proposed a system able to take the administrative processes benefit to enterprise
in grade high, through a simple interface, in graphic atmosphere. Finally, a present
prototype, agile and friendly for the user.
For further system understanding it has been divided by modules that i have
developed using the UML notacin. These modules are: Readers, attractions, Pos
and administrative.

18

1. PLANTEAMIENTO Y JUSTIFICACIN

1.1. ANTECEDENTES HISTRICOS DE LA EMPRESA

Historia de DIVERTRONICA MEDELLN S.A.

DIVERTRONICA MEDELLIN S.A. fue creada en 1982 con el objetivo de operar
vdeo juegos de habilidad y destreza, en las principales ciudades del pas. Durante
los primeros 7 aos se dedic exclusivamente a manejar y prestar servicio de
mantenimiento y reparacin a sus propios video juegos.
En los aos siguientes empez a diversificar su negocio y fue as como incursion
en la industria de la recreacin infantil y familiar fabricando e importando sus
propios equipos y operndolos en almacenes de cadena, puntos especializados,
centros comerciales, entre otros.
La empresa pertenece desde 1985 a la IAAPA (asociacin internacional de
Parques y Atracciones de Recreacin). Agrupa los fabricantes y operadores de
parques y atracciones de recreacin ms importantes del mundo.
Desde 1985 cuenta con unas instalaciones fsicas y un equipo tcnico y humano
aptos para el diseo, fabricacin, importacin, exportacin, operacin y
mantenimiento de una gran cantidad y variedad de atracciones que conforman lo
que hoy es DIVERTRONICA MEDELLN S.A. LA GRAN DIVERSIN S.A.

19
Las instalaciones donde se realizan todas las operaciones de fabricacin y
comercializacin de DIVERTRONICA LA GRAN DIVERSIN se encuentra
localizada en el municipio de itagu (calle 51 N. 46 11).

Funcionamiento de la empresa

DIVERTRONICA MEDELLN S.A. es una empresa moderna, la cual
constantemente se encuentra investigando acerca de la variedad en la fabricacin
de atracciones electromecnicas, para poder ofrecer a sus clientes una gran
diversidad para satisfacer la demanda del mercado.
La empresa cuenta con ms de 40 puntos de venta en Antioquia, como tambin
con representantes a nivel nacional localizados en las principales ciudades de
Colombia (Bogot, Cali, Barranquilla, Bucaramanga, Pereira, Cartagena, Neiva)
Dispuestos a brindar el mejor servicio de recreacin familiar que se ofrece en el
pas con sus 2.500 equipos, ubicados en los diferentes centros de recreacin
familiar, en los principales centros comerciales y los ms importantes almacenes
de cadena del pas.
En todos estos puntos de venta se cuenta con un gran nmero de colaboradores
que conforman un equipo tcnico y administrativo capacitado para prestar un
excelente servicio.

Direccionamiento estratgico

a. Misin
Somos una empresa dedicada a la promocin y comercializacin de servicios de
recreacin infantil y familiar, orientada a satisfacer las necesidades de nuestros

20
clientes, mediante actividades de diversin en parques recreativos, centros
comerciales, almacenes de cadena, sector oficial, entre otros; a travs del
entreteni miento, recreacin e innovacin de los equipos utilizados.
Convencidos de la calidad humana de las personas con que contamos,
trabajamos con orgullo buscando siempre la excelencia de nuestra gente y de
nuestros servicios.

b. Visin
Ser la empresa lder en Colombia en la operacin de atracciones para
entretenimiento familiar e infantil, mediante la creacin de alternativas que
representen satisfacciones y beneficios sociales y econmicos para socios,
clientes y empleados.

c. Valores
DIVERTRONICA MEDELLIN S.A. cimienta todas sus decisiones y actuaciones en
la tica, honestidad, respeto, cumplimiento, profesionalismo en la prestacin de
sus servicios a sus clientes y todas aquellas personas involucradas directa o
indirectamente con la empresa.

21
Organigrama

Ilustracin 1 - Organigrama

1.2. FORMULACIN DEL PROBLEMA
En los procesos administrativos de los puntos de Venta de DIVERTRONICA
MEDELLIN S.A. y en especial el Centro Comercial Sandiego, se ha observado la
necesidad de un sistema de gestin para ellos entre los cuales estn: Recaudos e
informes de ventas en periodos determinados, y la facilitacin prctica de utilizar
las atracciones por parte de los clientes(desde el momento en que se compra la
boletera de los mismos), han hecho notar una falta de informacin gil, oportuna y
confiable en la gestin de procesos administrativos dentro del establecimiento,
generando a la empresa prdidas de tiempo para el recurso humano involucrado,
produciendo as un aumento en los costos de nmina. Cuando se necesita
conocer las ventas hechas por cada atraccin en algn momento determinado, no
es posible saberlo de una manera gil y confiable, ya que se tendra que pasar por
cada una de ellas y tomar las fichas depositadas en sus respectivas alcancas y a
su vez confrontar el nmero contado con el contador que tiene cada atraccin que
ASAMBLEADEACCIONISTAS
JUNTADIRECTIVA
GERENTEGENERAL
COMERCIAL MANTENIMIENTOSY
OFICIOSVARIOS
CONTABILIDADY
TESORERIA
RECURSOSHUMANOS SALUDOCUPACIONAL
ASISTENTES
RECEPCIONISTA
REVISORFISCAL
REPRESENTANTES
DE OTRAS
CIUDADES
ASISTENTECOMERCIAL
PROMOTRES

22
ste se incrementa cada vez que se haga uso de ella. Hacer este proceso resulta
ser muy lento puesto que el tiempo que se invierte en ello es muy largo, a parte de
eso no lo puede hacer una sola persona y el parque no puede estar en
funcionamiento, como mnimo son dos personas las que lo hacen. Con relacin a
la utilizacin por parte del cliente de la atraccin, ste lo hace a travs de fichas o
boletas, dependiendo de la atraccin que decida utilizar. Este resulta ser un
proceso poco amigable desde el momento en que se compran los crditos en el
punto de venta, a parte de esto se le pueden perder al cliente con ms facilidad.

1.3. JUSTIFICACIN
DIVERTRONICA MEDELLN S.A. ha tomado la decisin de prestar un mejor
servicio en sus puntos de venta a todos sus clientes, teniendo como punto de
partida el parque de diversin del C.C. Sandiego. Optimizando paralelamente la
gestin administrativa de cada uno de ellos. Para este fin eligi adquirir
primeramente un prototipo de software que pueda permitir llevar a cabo ste
proceso.
Actualmente la empresa lleva la gestin de los parques de una forma muy manual,
vendiendo boletas o fichas para el funcionamiento de las atracciones y contando
manualmente las mismas. Este es un proceso bastante lento y poco fiable para
dar respuesta a las ventas diarias, al igual que su proceso de ganancias despus
de liquidar el da de las ventas en el parque.
La empresa tiene como objetivo expandir sus puntos de venta, para lo cual se
hace cada vez ms necesaria la computarizacin de las gestiones administrativas,
ofreciendo a los clientes una mejor atencin y comodidad en sus servicios, como
tambin dando a su recurso humano involucrado en la gestin, una mayor
satisfaccin personal en el desempeo de sus labores.
DIVERTRONICA MEDELLN S.A., requiere de un sistema que est en capacidad
de manejar la gestin de consumo por parte de los clientes en sus puntos de

23
venta, como es el uso de las atracciones y los recaudos e informes de ventas, de
una manera eficiente, eficaz y confiable. Para ello se propone un prototipo que
permita dar solucin a las falencias mencionadas anteriormente.

24

2. MARCO TERICO

2.1. ESTADO DEL ARTE

En la actualidad a nivel local el Parque de Diversin del Centro Comercial el
Tesoro, cuenta con un sistema de manejo de tarjetas magnticas y lectores para
hacer uso de sus atracciones. Este sistema lo tiene para un gran nmero de
mquinas del parque, an que no todas se encuentran en esta red.
A nivel nacional est Bogot, hay dos empresas en donde cuentan con un sistema
similar a ste: Carrusel y Multijuego, donde esta ltima tiene dos parques (Rodeo
Landia y Play Time). El sistema que manejan se llama SACOA, es un sistema
argentino. Mientras que en Medelln en el Centro Comercial El Tesoro se maneja
uno llamado Arcade Management Software Suite, de la empresa Intercard Inc.
Norteamericana.
Esto sistemas cuentan con las siguientes caractersticas:
Configuracin de Lectores
Recopilacin de Informacin de ventas de los lectores
Reportes grficos acerca de informacin leda en los lectores

Arcade Management Software Suite
Es una herramienta desarrollada por Intercard (USA), la cual maneja el
funcionamiento de un parque de recreacin por medio de tarjetas de banda
magntica con las cuales se hace uso de las atracciones.

25
Esta herramienta cuenta con las siguientes funciones:
Permite configurar los lectores para determinar con qu costo va a funcionar la
atraccin en la que se encuentre instalado y as poder descontar del saldo que
tenga la tarjeta.
Permite hacer recoleccin de la informacin guardada en cada lector del
parque de recreacin a travs de una red de datos.
Entrega reportes acerca de los registros capturados de los lectores, como:
ventas, horas en las que se hizo uso de las mquinas, entre otros.

Tams 2000 (FESCO)
Este Tams2000 es el Pos y en l tambin se manejan los cumpleaos, que son
eventos de nios que se celebran en el parque. En este mdulo se hace la
reservacin de la fiesta y el respectivo abono si lo hay. Por el lado de las
promociones el Tams permite el manejo de bonos para cancelar en los puntos de
venta. Actualmente se manejan 2 bonos que vienen en los combos Familiar y Kids
y que sirven para recargar tarjetas.

2.2. TARJETAS MAGNTICAS
Las tarjetas de plstico con una franja magntica ya forman parte de la vida de
todos, simplificando las operaciones bancarias, compras, controlando el acceso a
lugares restringidos, etc. Por lo tanto, no es necesaria la explicacin sobre las
posibilidades actuales y futuras de dichas tarjetas.

26
Aspectos fsicos:
Las dimensiones fsicas de las tarjetas estn estandarizadas por ANSI
(American Nacional Standard Institute: Instituto Nacional Americano de
Patrones) y fueron definidas para facilitar la manipulacin y almacenamiento de
las mismas. La franja magntica existente en estas tarjetas posee tres pistas
con usos y formatos independientes entre s.

Caractersticas de la pista 1:
La pista 1 tiene densidad de 210bpi (bists por pulgada) con palabras de 6 bits
ms 1, para paridad impar. La codificacin de 6 bits es un subconjunto del
cdigo ASCII. Teniendo la tarjeta 3.375, y siendo reservadas 0.293 al
comienzo y 0.273 al final para sincrona, puede contener 84 palabras de
informacin: ((3.375 0.293 0.273) x 210bits/pulgada) 7 bits/palabra =
84.27 palabras.

La pista 2 tiene densidad de 75bpi con palabras de 4 bits ms 1 para paridad
impar. La codificacin de 4 bits permite la formacin de solamente 10
caracteres numricos ms 6 de cdigos. El nmero mximo de palabras es de
42 en una tarjeta: ((3.375 0.293 0.273) x 75 bits/pulgada) 5 bits/palabra
= 42.13 palabras.
El comienzo y el final de la pista tambin son reservados para sincrona.

La pista 3 tiene densidad de 210bpi como la pista 1 y palabras de 4 bits ms 1
para paridad impar como la pista 2. En este caso, el nmero mximo de

27
palabras posibles de almacenar en una tarjeta es de 117: ((3.375 0.293
0.273) x 210 bits/pulgada) 5 bits/palabra).
Otros tipos de tarjetas:
Existen otros tipos de tarjetas con franja magntica con fines especficos, que
no tienen las dimensiones o densidades descriptas anteriormente, pero con
mtodos de escritura y lectura semejantes. Citamos como ejemplo los boletos
magnticos usados en trenes y subterrneos.
(Ver Anexo III)

Tcnicas de codificacin:
La tcnica de codificacin fue desarrollada por Airen en 1954 y es conocida
como Two-Frequency, coherent Phase Recording grabacin de fase
coherente y dos frecuencias). Este mtodo permite la grabacin de datos en
forma seriada sin necesidad de pulsos de sincrona en canal separado y con
velocidad de lectura variable.
En la pista tenemos, a espacios fijos, transiciones de flujo magntico (la franja
magntica no es ms que una cinta de material ferromagntico semejante al
usado en las cintas de audio). Estas transiciones a espacios fijos son usadas
como clock.
Entre una transicin y otra puede o no existir una transicin intermedia. Si
existe, el bit grabado es 1; si no existe la transicin intermedia, el bit grabado
es 0.
La figura 2(del documento) muestra una seal digital obtenida de la lectura de
una tarjeta magntica.
Note que a cada espacio regular existe una transicin de nivel lgico alto (H) a
nivel lgico bajo (L) o de nivel lgico L a nivel lgico H (no importa el sentido de

28
transicin y s solamente la existencia de sta). Cada transicin es un pulso de
clock.
La permanencia del nivel en H o L de un clock gasta el prximo clock significa
que el dato es 0 (cero). Si hubiera una transicin de H a L o de L a H entre un
clock y otro, indica un bit de dato 1 (uno).
Las palabras son grabadas en la tarjeta de forma tal que el bit menos
significativo quede a la derecha y el bit de paridad quede a la izquierda si se
mira la tarjeta como en la figura 1. Como la tarjeta se lee de derecha a
izquierda, el bit menos significativo es el primero en ser ledo.

La grabacin magntica:
Bsicamente, la grabacin magntica de una tarjeta se hace a travs de una
cabeza magntica, en la cual provoca una inversin en el sentido de la
corriente que circula por su bobinado a cada transicin de flujo magntico
deseada. La franja magntica se desplaza longitudinalmente a la cabeza,
recibiendo las lneas de flujo, y es magnetizada. A cada inversin en el sentido
de la corriente, corresponde una inversin en el sentido de magnetizacin. En
la franja magntica aparecen imanes con polos invertidos correspondiendo
cada inversin a una transicin de clock o de dato 1.

2.3. LECTORES
Cuando hice el estudio sobre el estado del arte, enfatic en el Centro Comercial el
Tesoro.

OPERACIN DE LECTORES DE ATRACCIONES
Las dificultades ms frecuentes y la forma de resolverlas son las siguientes:

29
Si al introducir una tarjeta el lector no la expulsa y la deja en su interior, se
debe probar primero apagando el lector por unos instantes y volverlo a prender
para que expulse la tarjeta por si solo, si luego de varios intentos con este
procedimiento no se obtiene resultado, se debe apagar el lector y abrirlo con su
respectiva llave; luego de abrir el lector, se extrae la tarjeta sujetndola con los
dedos pero poniendo atencin de no doblarla o hacerle algn dao, luego se
cierra el lector y se prende de nuevo. Esta situacin se puede presentar por
suciedad en el lector o porque la tarjeta estaba doblada o quebrada antes de
introducirla.
Si al introducir la tarjeta al lector esta se queda entrando y saliendo de manera
sucesiva, hay que procurar sujetarla con los dedos en el momento que sale y
antes de que se introduzca de nuevo, luego halarla hacia fuera, esto puede
generar un mensaje de error 31; aunque la mayora de las veces, en muy
pocas no, la tarjeta queda mala despus de este procedimiento, es decir, si se
introduce de nuevo a un lector produce error 4.
Nunca se debe halar la tarjeta en el momento que el lector la esta
reconociendo, es necesario esperar a que el lector la expulse por si solo, de lo
contrario la tarjeta sufrir el mismo dao que se menciona en el tem anterior.
Es indispensable que el operario este atento a la informacin que el lector
despliega en su pantalla, ya sea para que le informe al visitante el saldo de la
tarjeta, o para que en caso de tener que reponer la tarjeta al cliente porque
sufri dao en el lector, pueda informar el monto de dinero a grabar en la
nueva tarjeta para hacerle la reposicin.
Nunca se debe de introducir en los lectores tarjetas dobladas, mordidas,
quebradas o deterioradas, porque es muy probable que se atasquen en el
interior del lector y puedan ocasionar daos fsicos en ste.
Cuando un lector reporta en su pantalla error 4 mientras lee una tarjeta, puede
ser que la tarjeta esta realmente mala, o muy sucia y la cabeza lectora no

30
reconoce la informacin en la tarjeta, o la cabeza lectora est sucia y no
identifica la informacin en la tarjeta.
Cuando un lector muestra en su pantalla de forma permanente la palabra
CARD, quiere decir que hay una tarjeta atascada en su interior, en este caso
se debe proceder de acuerdo a las instrucciones explicadas en el primer tem
de esta lista.
Cuando el lector despliega en su pantalla error 43 mientras lee una tarjeta,
quiere decir que la tarjeta ha sufrido dao parcial en su informacin y no puede
ser reconocida enteramente, por lo tanto es necesario reponerle esta tarjeta al
cliente con una nueva, esta reposicin se hace con el personal de la seccin
de sistemas.
Solo se reponen tarjetas a los clientes cuando hay evidencia de que fueron
compradas, recargadas o usadas exitosamente, momentos antes de que algn
lector reportara error 4, 30 43 al intentar leerlas. No se debe hacer
reposicin cuando la tarjeta es vieja, ya que el dao que presente pudo ser
causado por maltra to o descuido del cliente antes de regresar al parque a
usarla.

El prototipo de software que propongo desarrollar estar en capacidad de manejar
un pos bsico, en el cual solo se vendern tarjetas de banda magntica, cargadas
con el valor de dinero escogido por un cliente. Una vez se haga esta venta, se
confirmar la carga exitosa en la tarjeta a travs de una consulta, luego se podr
hacer uso de la tarjeta en una atraccin que tendr un lector. Este ltimo proceso
se har a travs de una simulacin en el prototipo de una forma local y en un
futuro como propuesta de proyecto para Divertrnica Medelln S.A., sera hacerlo
en red con todas las atracciones de un parque de diversin pero para el prototipo
se har localmente con el mismo software.

31
En este prototipo se podrn ingresar todas las atracciones de un parque de
diversin con sus caractersticas respectivas, como por ejemplo el valor del turno
en la atraccin para poder saber cunto se descontar de la tarjeta en el momento
de hacer uso de ella. Tambin permitir registrar los lectores y sacar reportes
bsicos de atracciones, lectores y ventas.
Para el desarrollo de este prototipo lo fundamento en el uso de la metodologa del
Lenguaje Unificado de Modelado (UML), ya que este me permite hacer el diseo y
modelado del mismo. Y como UML, es efectivo tambin para aplicaciones con
grandes cantidades de software, sera ideal para mi propuesta a Divertrnica
Medelln S.A. de hacer la aplicacin completa en red.

2.4. UML

2.4.1 Una breve historia
Los lenguajes de modelado orientados a objetos aparecieron, en algn momento,
entre la mitad de los setenta y finales de los ochenta cuando os metodologistas,
enfrentados a los nuevos lenguajes de programacin orientados a objetos y a
unas aplicaciones cada vez ms complejas, empezaron a experimentar con
enfoques alternativos al anlisis y al diseo. El nmero de mtodos orientados a
objetos se increment de menos de 10 a ms de 50 durante el perodo entre 1989
y 1994. muchos usuarios de estos mtodos tenan problemas al intentar encontrar
un lenguaje de modelado que cubriera sus necesidades completamente,
alimentado de esta forma la llamada guerra de mtodos. Aprendiendo de estas
experiencias comenzaron a aparecer nuevas generaciones de mtodos,, entre los
que destacaron de manera muy clara unos pocos mtdoso, en especial el mtodo
de Booch, el mtodo OOSE (Object-Oriented Software Engineering, Ingeniera del
Software Orientada a Objetos) de Jacobson y el mtodo OMT (Object Modeling

32
Technique, Tcnica e Modelado de Ojetos) de Rumbaugh. Cada uno de estos era
un mtodo completo, aunque todos tenan sus puntos fuertes y sus debilidades.
En pocas palabras, el mtodo de Booch era particularmente expresivo durante las
fases de diseo y construccin de los proyectos, OOSE proporcionaba un soporte
excelente para los casos de uso como forma de dirigir la captura de requisitos, el
anlisis y el diseo de alto nivel, y OMT-2 era principalmente til para el anlisis y
para los sistemas de informacin con gran cantidad de datos.
En la primera mitad de los noventa, empezaron a adoptar ideas de cada uno de
los dos mtodos, los cuales haban sido reconocidos en conjunto como los tres
principales mtodos orientados a objetos a nivel mundial. Como creadores
principales de los mtodos de Booch, OOSE y OMT, nos sentimos motivados para
crear un lenguaje unificado de modelado por tres razones. En primer lugar, cada
uno de nuestros mtodos ya estaba evolucionando independientemente hacia los
otros dos. Tena sentido hacer continuar esa evolucin de forma conjunta en vez
de hacerlo por separado, eliminando la posibilidad de cualquier diferencia gratuita
e innecesaria que confundira an ms a los usuarios. En segundo lugar, al
unificar nuestros mtodos, podramos proporcionar cierta estabilidad al mercado
orientado a objetos, perdimiento que los proyectos se pusieran de acuerdo en un
lenguaje de modelado madura y permitiendo a los Constructores de herramientas
que se centraran en proporcionar ms caractersticas tiles. En tercer lugar,
esperbamos que nuestra colaboracin introducira mejoras en los tres mtodos
anteriores, ayudndonos a capturar lecciones aprendidas y a cubrir problemas que
ninguno de nuestros mtodos haba manejado bien anteriormente.
Cuando comenzamos con la unificacin, establecimos tres metas para nuestro
trabajo:
1. modelar sistemas, desde el concepto hasta los artefactos ejecutables,
utilizando tcnicas orientadas a objetos.
2. cubrir las cuestiones relacionadas con el tamao inherente a los sistemas
complejos crticos.

33
3. crear un lenguaje de modelado utilizable tanto para las personas como por las
mquinas.

El esfuerzo de UML comenz en octubre de 1994, cuando Rumbaugh se uni a
Booch en Rational. El objetivo inicial de nuestro proyecto fue la unificacin de los
mtodos de Booch y OMT.

Por qu modelamos
Una empresa de software con xito es aqulla que produce de una manera
consistente software de calidad que satisface las necesidades de sus usuarios.
Una empresa que puede desarrollar este software de forma predecible y puntual,
con un uso eficiente y efectivo de recursos, tanto humanos como materiales, tiene
un negocio sostenible.
El modelado es una parte central de todas las actividades que conducen a la
produccin de buen software. Construimos modelos para comunicar la estructura
deseada y el comportamiento de nuestro sistema. Construimos modelos para
visualizar y controlar la arquitectura del sistema. Construimos modelos para
comprender mejor el sistema que estamos construyendo, muchas veces
descubriendo oportunidades para la simplificacin y la reutilizacin. Construimos
modelos para controlar el riesgo.

La importancia de modelar
Los proyectos software que fracasan lo hacen por circunstancias propias, pero
todos los proyectos con xito se parecen en muchos aspectos. Hay muchos
elementos que contribuyen a una empresa de software con xito; uno en comn
es el uso del modelado.

34
El modelado es una tcnica de ingeniera probada y bien aceptada. Construimos
modelos arquitectnicos de casas y rascacielos para ayudar a sus usuarios a
visualizar el producto final. Incluso podemos construir modelos matemticos para
analizar los efectos de vientos o terremotos sobre nuestros edificios.
Un modelo es una simplificacin de la realidad.

QUE ES
El Lenguaje Unificado de Modelado (Unified Modeling Language, UML) es un
lenguaje estndar para escribir planos de software. UML puede utilizarse para
visualizar, especificar, construir y documentar los artefactos de un sistema que
involucra una gran cantidad de software.
UML es apropiado para modelar desde sistemas de informacin en empresas
hasta aplicaciones distribuidas basadas en la Web, e incluso para sistemas
empotrados de tiempo real muy exigentes. Es un lenguaje muy expresivo, que
cubre todas las vistas necesarias para desarrollar y luego desplegar tales
sistemas. Aunque sea expresivo, UML no es difcil de aprender ni de utilizar.
Aprender a aplicar UML de modo eficaz comienza por crear un modelo conceptual
del lenguaje, lo cual requiere aprender tres elementos principales: los bloques
bsicos de construccin de UML, las reglas que dictan cmo pueden combinarse
esos bloques y algunos mecanismos comunes que se aplican a lo largo del
lenguaje.
UML es slo un lenguajes y por tanto es tan slo una parte de un mtodo de
desarrollo de software. UML es independiente del proceso, aunque para utilizarlo
ptimamente se debera usar en un proceso que fuese dirigido por los casos de
uso, centrado en la arquitectura, iterativo e incremental.

35
UML es un lenguaje
Un lenguaje proporciona un vocabulario y las reglas para combinar palabras de
ese vocabulario con el objetivo de posibilitar la comunicacin. Un lenguaje de
modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representacin conceptual y fsica de un sistema. Un lenguaje de modelado como
UML es por tanto un lenguaje estndar para los planos del software.
El modelado proporciona una comprensin de un sistema. Nunca es suficiente un
nico modelo. Ms bien, para comprender cualquier cosa, a menudo se necesitan
mltiples modelos conectados entre s, excepto en los sistemas ms triviales. Para
sistemas con gran cantidad de software, se requiere un lenguaje que cubra las
diferentes vistas de la arquitectura de un sistema mientras evoluciona a travs del
ciclo de vida del desarrollo de software.
El vocabulario las reglas de un lenguaje como UML indican cmo crear y leer
modelos bien formados, pero no dicen qu modelos se deben crear ni cundo se
deberan crear. Esta es la tarea del proceso de desarrollo de software. Un proceso
bien definido guiar a sus usuarios al decidir qu artefactos producir, qu
actividades y qu personal se emplea para crearlos y gestionarlos, y cmo usar
esos artefactos para medir y controlar el proyecto de forma global.

UML es un lenguaje para visualizar
Para muchos programadores, la distancia entre pensar en una implementacin y
transformarla en cdigo es casi cero. Lo piensas, lo codificas. De hecho, algunas
cosas se modelan mejor directamente en cdigo. El texto es un medio maravilloso
para escribir expresiones y algoritmos de forma concisa y directa.
En tales casos, el programador todava est haciendo algo de modelado, si bien lo
hace de forma completamente mental. Incluso puede bosquejar algunas ideas
sobre una pizarra blanca o sobre una servilleta. Sin embargo, esto plantea algunos
problemas.

36
Primero, la comunicacin de esos modelos conceptuales a otros est sujeta a
errores a menos que cualquier persona implicada hable el mismo lenguaje.
Normalmente, los proyectos y las organizaciones desarrollan su propio lenguaje, y
es difcil comprender lo que est pasando para alguien nuevo o ajeno al grupo.
Segundo, hay algunas cuestiones sobre un sistema software que no se pueden
entender a menos que se construyan modelos que trasciendan el leguaje de
programacin textual. Por ejemplo, el significado de una jerarqua de clases puede
inferirse, pero no capturarse completamente, inspeccionando el cdigo de todas
las clases en la jerarqua. De forma parecida, la distribucin fsica y posible
migracin de los objetos en un sistema basado en la Web puede inferirse, pero no
capturarse completamente, estudiando el cdigo fuente del sistema. Tercero, si el
desarrollador que escribi el cdigo no dej documentacin escrita sobre los
modelos que haba en su cabeza, esa informacin se perder para siempre o,
como mucho, ser slo parcialmente reproducible a partir de la implementacin
una vez que el desarrollador se haya marchado.
Al escribir modelos en UML se afronta el tercer problema: un modelo explicito
facilita la comunicacin.

UML es un lenguaje para especificar
En este contexto, especificar significa construir modelos precisos, no ambiguos y
completos. En particular, UML cubre la especificacin de todas las decisiones de
anlisis, diseo e implementacin que deben realizarse al desarrollar y desplegar
un sistema con gran cantidad de software.

UML es un lenguaje para construir
UML no es un lenguaje de programacin visual, pero sus modelos pueden
conectarse de forma directa a una gran variedad de lenguajes de programacin.
Esto significa que es posible establecer correspondencias desde un modelo UML

37
a un lenguaje de programacin como Java, C++ o Visual Basic, o incluso a tablas
en una base de datos relacional o al almacenamiento persistente en una base de
datos orientada a objetos. Las cosas que se expresan mejor grficamente
tambin se representan grficamente en UML, mientras que las cosas que se
expresan mejor textualmente se plasman con el lenguaje de programacin.
Esta correspondencia permite ingeniera directa: la generacin de cdigo a partir
de un modelo UML es un lenguaje de programacin. Lo contrario tambin es
posible: se puede reconstruir un modelo en UML a partir de una implementacin.
La ingeniera inversa no es magia. A menos que se codifique esa informacin en
la implementacin, la informacin se pierde cuando se pasa de los modelos al
cdigo. La ingeniera inversa requiere, por lo tanto, herramientas que la soporten e
intervencin humana. La combinacin de estas dos vas de generacin de cdigo
y de ingeniera inversa produce una ingeniera de ida y vuelta, entendiendo por
esto la posibilidad de trabajar en una vista grfica o textual, mientras las
herramientas mantiene la consistencia entre las dos vistas.

UML es un lenguaje para documentar
Una organizacin de software que trabaje bien produce toda clase de artefactos
adems de cdigo ejecutable. Estos artefactos incluyen (aunque no se limitan a:):
Requisitos.
Arquitectura.
Diseo.
Cdigo fuente.
Planificacin de proyectos.
Pruebas.

38
Prototipos.
Versiones.

Dependiendo de la cultura de desarrollo, algunos de estos artefactos no son slo
los entregables de un proyecto, tambin son crticos en el control, la medicin y
comunicacin que requiere un sistema durante su desarrollo y despus de su
despliegue.
UML cubre la documentacin de la arquitectura de un sistema y todos sus
detalles. UML tambin proporciona un lenguaje para expresar requisitos y
pruebas. Finalmente, UML proporciona un lenguaje para modelar las actividades
de planificacin de proyectos y gestin de versiones.

Dnde puede utilizarse UML?
UML est pensado principalmente para sistemas con gran cantidad de software.
Ha sido utilizado de forma efectiva en dominios tales como:
Sistemas de informacin de empresa.
Bancos y servicios financieros.
Telecomunicaciones.
Transporte.
Defensa/industria aeroespacial.
Comercio
Electrnica mdica.
Ambito cientfico.
Servicios distribuidos basados en la Web.

39

UML no est limitado al modelado de software. De hecho, es lo suficientemente
expresivo para modelar sistemas que no son software, como flujos de trabajo
(workflows) en el sistema jurdico, estructura y comportamiento de un sistema de
vigilancia mdica de un enfermo, y el diseo de hardware.

Un modelo conceptual de UML
Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y
esto requiere aprender tres elementos principales: los bloques bsicos de
construccin de UML, las reglas que dictan cmo se pueden combinar estos
bloques bsicos y algunos mecanismos comunes que se aplican a travs de UML.
Una vez comprendidas estas ideas, se pueden leer modelos UML y crear algunos
modelos bsicos. Conforme se gana ms experiencia en la aplicacin de UML, se
puede edificar sobre este modelo conceptual, utilizando caractersticas ms
avanzadas del lenguaje.

Bloques de construccin de UML
El vocabulario de UNL incluye tres clases de bloques de construccin:
1. Elementos.
2. Relaciones.
3. Diagramas.

Los elemento son abstracciones que son ciudadanos de primera clase en un
modelo; las relaciones ligan estos elementos entre s; los diagramas agrupan
colecciones interesantes de elementos.

40
Elementos en UML
Hay cuatro tipos de elementos en UML:
1. Elementos estructurales.
2. Elementos de comportamiento.
3. Elementos de agrupacin.
4. Elementos de anotacin.

Estos elementos son los bloques bsicos de construccin orientados a objetos de
UML. Se utilizan para escribir modelos bien formados.

Elementos estructurales. Los elementos estructurales son los nombres de los
modelos UML. En su mayora son las partes estticas de un modelo, y
representan cosas que son conceptuales o materiales. En total, hay siete tipos de
elementos estructurales.
Primero, una clase es una descripcin de un conjunto de objetos que comparten
los mismos atributos, operaciones, relaciones y semntica. Una clase implementa
una o ms interfaces. Grficamente, una clase se representa como un rectngulo,
que normalmente incluye su nombre, atributos y operaciones.
Segundo, una interfaz es una coleccin de operaciones que especifican un
servicio de una clase o componente. Por lo tanto, una interfaz describe el
comportamiento visible externamente de ese elemento. Una interfaz puede
representar el comportamiento completo de una clase o componente o slo una
parte de ese comportamiento. Una interfaz define un conjunto de especificaciones
de operacin (o sea, sus signaturas), pero nunca un conjunto de
implementaciones de operaciones. Grficamente, una interfaz se representa como
un crculo junto con su nombre. Una interfaz raramente se encuentra aislada ms
bien, suele estar conectada a la clase o componente que la realiza.

41
Tercero, una colaboracin define una interaccin y es una sociedad de roles y
otros elementos que colabora para proporcionar un comportamiento cooperativa
mayor que la suma de los comportamientos de sus elementos. Por lo tanto, las
colaboraciones tiene dimensin tanto estructural como de comportamiento. Una
clase dada puede participar en varias colaboraciones. Estas colaboraciones
representan, pues, la implementacin de patrones que forman un sistema.
Grficamente, una colaboracin se representa como una elipse de borde
discontinuo, incluyendo normalmente slo su nombre.
Cuarto, un caso de uso es una descripcin de un conjunto de secuencias de
acciones que un sistema ejecuta y que produce un resultado observable de inters
para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de
comportamiento en un modelo. Un caso de uso es realizado por una colaboracin.
Grficamente, un caso de uso se representa como una elipse de borde continuo,
incluyendo normalmente slo su nombre.
Los tres elementos restantes (clases activas, componentes y nodos) son todos
similares a las clases, en cuanto que tambin describen un conjunto de objetos
que comparten los mismos atributos, operaciones, relaciones y semntica. Sin
embargo, estos tres son suficientes diferentes y son necesarios para modelar
ciertos aspectos de un sistema orientado a objetos, as que est justificando un
tratamiento especial.
Quinto, una clase activa es una clase cuyos objetos tienen uno o ms procesos o
hilos de ejecucin y por lo tanto pueden dar origen a actividades de control. Una
clase activa es igual que una clase, excepto en que sus objetos representan
elementos cuyo comportamiento es concurrente con otros elementos.
Grficamente, una clase activa se representa como una clase, pero con lneas
ms gruesas, incluyendo normalmente su nombre, atributos y operaciones.
Los dos elementos restantes (componentes y nodos) tambin son diferentes.
Representan elementos fsicos, mientras los cinco elementos anteriores
representan cosas conceptuales o lgicas.

42
Sexto, un componente es una parte fsica y reemplazable de un sistema que
conforma con un conjunto de interfaces y proporciona la implementacin de dicho
conjunto. En un sistema, se podrn encontrar diferentes ti pos de componentes de
despliegue, tales como componentes COM+ o JavaBeans, as como componentes
que sean artefactos del proceso de desarrollo, tales como archivos de cdigo
fuente. Un componente representa tpicamente el empaquetamiento fsico de
diferentes elementos lgicos, como clases, interfaces y colaboraciones.
Grficamente, un componente se representa como un rectngulo con pestaas,
incluyendo normalmente slo su nombre.
Sptimo, un nodo es un elemento fsico que existe en tiempo de ejecucin y
representa un recurso computacional, que por lo general dispone de algo de
memoria y, con frecuencia, capacidad de procesamiento. Un conjunto de
componentes puede residir en un nodo y puede tambin migrar de un nodo a otro.
Grficamente, un nodo se representa como un cubo, incluyendo normalmente slo
su nombre.
Estos siete elementos (clases, interfaces, colaboraciones casos de uso, clases
activas, componentes y nodos) son los elementos estructurales bsicos que se
pueden incluir en un modelo UML. Tambin existen variaciones de estos siete
elementos, tales como actores, seales, utilidades (tipos de clases), proceso e
hilos (tipos de clases activas), y aplicaciones, documentos, archivos, bibliotecas,
pginas y tablas (tipos de componentes).

Elementos de comportamiento. Los elementos de comportamiento son las
partes dinmicas de los modelos UML. Estos son los verbos de un modelo, y
representan comportamiento en el tiempo y el espacio. En total hay do tipos
principales de elementos de comportamiento:
Primero, una interaccin es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos, dentro de un contexto

43
particular, para alcanzar un propsito especfico. El comportamiento de una
sociedad de objetos o una operacin individual puede especificarse con una
interaccin. Una interaccin involucra muchos otros elementos, incluyendo
mensajes, secuencias de accin (el comportamiento invocado por un mensaje) y
enlaces (conexiones entre objetos). Grficamente, un mensaje se muestra como
una lnea dirigida, incluyendo casi siempre el nombre de su operacin.
Segundo, una mquina de estados es un comportamiento que especifica las
secuencias de estados por las que pasa un objeto o una interaccin durante su
vida en respuesta a eventos, junto con sus reacciones a esto eventos. El
comportamiento de una clase individual o una colaboracin de clases pueden
especificarse con una mquina de estados. Una mquina de estados involucra a
otros elementos, incluyendo estados, transiciones (el flujo de un estado a otro),
eventos (que disparan una transicin) y actividades (la respuesta a una transicin.
Grficamente, un estado se representa como un rectngulo de esquinas
redondeadas, incluyendo normalmente su nombre y sus subastados, si los tiene.
Estos dos elementos (interacciones y mquinas de estados) son los elementos
bsicos de comportamiento que se pueden incluir en un modelo UML.
Semnticamente, estos elementos estn conectados normalmente a diversos
elementos estructurales, principalmente clases, colaboraciones y objetos.

Elementos de agrupacin. Los elementos de agrupacin son las partes
organizativas de los modelos UML. Estos son las cajas en las que puede
descomponerse un modelo.
En total, hay un elemento de agrupacin principal, los paquetes.
Un paquete es un mecanismo de propsito general para organizar elementos en
grupos. Los elementos estructurales, los elementos de comportamiento, e incluso
otros elementos de agrupacin pueden incluirse en un paquete. Al contrario que
los componentes (que existen en tiempo de ejecucin), un paquete es puramente

44
conceptual (slo existe en tiempo de desarrollo). Grficamente, un paquete se
visualiza como una carpeta, incluyendo normalmente slo su nombre y, a veces,
su contenido.
Los paquetes son los elementos de agrupacin bsicos con los cuales se puede
organizar un modelo UML. Tambin hay variaciones, tales como los frameworks,
los modelos y los subsistemas (tipos de paquetes).

Elementos de anotacin. Los elementos de anotacin son las partes explicativas
de los modelos UML. Son comentarios que se pueden aplicar para describir,
clarificar y hacer observaciones sobre cualquier elemento de un modelo. Hay un
tipo principal de elementos de entonacin llamado nota. Una nota es simplemente
un smbolo para mostrar restricciones y comentarios junto a un elemento o una
coleccin de elementos. Grficamente, una nota se representa como un
rectngulo con una esquina doblada, junto con un comentario textual o grfico.
Este elemento es el objeto bsico de anotacin que se puede incluir en un modelo
UML. Tpicamente, las notas se utilizarn para adornar los diagramas con
restricciones o comentarios que se expresen mejor en texto informal o formal.
Tambin hay variaciones sobre este elemento, tales como los requisitos (que
especifican algn comportamiento deseado desde la perspectiva externa del
modelo).

Relaciones en UML.
Hay cuatro tipos de relaciones en UML:
1. Dependencia.
2. Asociacin.
3. Generalizacin.
4. Realizacin.

45
Estas relaciones son los bloques bsicos de construccin para relaciones de UML.
Se utilizan para escribir modelos bien formados:
Primero, una dependencia es una relacin semntica entre dos elementos, en la
cual un cambio a un elemento (elemento independiente) puede afectar a la
semntica del otro elemento (elemento dependiente). Grficamente, una
dependencia se representa como una lnea discontinua, posiblemente dirigida, que
incluye a veces una etiqueta.
Segundo, una asociacin es una relacin estructural que describe un conjunto de
enlaces, los cuales son conexiones entre objetos. La agregacin es un tipo
especial de asociacin, que representa una relacin estructural entre un todo y sus
partes. Grficamente, una asociacin se representa como una lnea continua,
posiblemente dirigida, que a veces incluye una etiqueta, y a menudo incluye otros
adornos, como la multiplicidad y los nombres de rol.
Tercero, una generalizacin es una relacin de especializacin/generalizacin en
la cual los objetos del elemento especializado (el hijo) pueden sustituir a los
objetos del elemento general (el padre). De esta forma, el hijo comparte la
estructura y el comportamiento del padre. Grficamente, una relacin e
generalizacin se representa como una lnea conti nua con una punta de flecha
vaca apuntando al padre.
Cuarto, una realizacin es una relacin semntica entre clasificadores, en donde
un clasificador especifica un contrato de otro clasificador garantiza que cumplir.
Se pueden encontrar relaciones de realizacin en dos sitio: entre interfaces y las
clases y componentes que las realiza, y entre los casos de uso y las
colaboraciones que los realizan. Grficamente, una relacin de realizacin se
representa como una mezcla entre una generalizacin y una relacin de
dependencia.

46
Estos cuatro elementos son los elementos bsicos relacionales que se pueden
incluir en un modelo UML. Tambin existen variaciones de estos cuatro, tales
como el refinamiento, la traza, la inclusin y la extensin (para las dependencias).

Diagramas en UML.
Un diagrama es la representacin grfica de un conjunto de elementos,
visualizado la mayora de las veces como un grafo conexo de nodos (elementos) y
arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde
diferentes perspectivas, de forma que un diagrama es una proyeccin de un
sistema. Para todos los sistemas, excepto los ms triviales, un diagrama
representa una vista resumida de los elementos que constituyen un sistema. El
mismo elemento puede aparecer en todos los diagramas, slo en unos pocos
diagramas (el caso ms comn), o en ningn diagrama (un caso muy raro). En
teora, un diagrama puede contener cualquier combinacin de elementos y
relaciones. En la prctica, sin embargo, slo surge un pequeo nmero de
combinaciones, las cuales son consistentes con las cinco vistas ms tiles que
comprenden la arquitectura de un sistema con gran cantidad de software. Por esta
razn, UML incluye nueve de estos diagramas:
1. Diagrama de clases.
2. Diagrama de objetos.
3. Diagrama de casos de uso.
4. Diagrama de secuencia.
5. Diagrama de colaboracin.
6. Diagrama de estados (statechart)
7. Diagrama de actividades.
8. Diagrama de componentes.

47
9. Diagrama de despliegue.

Un diagrama de clases muestra un conjunto de clases, interfaces y
colaboraciones, as como sus relaciones. Estos diagramas son los diagramas ms
comunes en el modelado de sistemas orientados a objetos los diagramas de
calases cubren la vista de diseo esttica de un sistema. Los diagramas de clases
que incluyen clases activas cubren la vista de procesos esttica de un sistema.

Un diagrama de objetos muestra un conjunto de objetos y sus relaciones. Los
diagramas de objetos representan instantneas de instancias de los elementos
encontrados en los diagramas de clases. Estos diagramas cubren la vista de
diseo esttica o la vista de procesos esttica de un sistema como lo hacen los
diagramas de clases, pero desde la perspectiva de casos reales o prototpicos.

Un diagrama de casos de uso muestra un conjunto de casos de uso y actores
(un tipo especial de clases) y sus relaciones. Los diagramas de casos de uso
cubren la vista de casos de uso esttica de un sistema. Estos diagramas son
especialmente importantes en el modelado y organizacin del comportamiento de
un sistema.

Tanto los diagramas de secuencia como los diagramas de colaboracin son
un tipo de diagramas de interaccin. Un diagrama de interaccin muestra una
interaccin, que consta de un conjunto de objetos y sus relaciones, incluyendo los
mensajes que pueden ser enviados entre ellos. Los diagramas de interaccin
cubren la vista dinmica de un sistema. Un diagrama de secuencia es un
diagrama de interaccin que resalta la ordenacin temporal de los mensajes; un
diagrama de colaboracin es un diagrama de interaccin que resalta la
organizacin estructural de los objetos que envan y reciben mensajes. Los

48
diagramas de secuencia y los diagramas de colaboracin son isomorfo, es decir,
que se puede tomar uno y transformarlo en el otro.

Un diagrama de estados muestra una mquina de estados, que consta de
estados, transiciones, eventos y actividades. Los diagramas de estados cubren la
vista dinmica de un sistema. Son especialmente importantes en el modelado del
comportamiento de una interfaz, una clase o una colaboracin y resaltan el
comportamiento dirigido por eventos de un objeto, lo cual es especialmente til
ene. Modelado de sistemas reactivos.

Un diagrama de actividades es un tipo especial de diagrama de estados que
muestra el flujo de actividades dentro de un sistema. Los diagramas de
actividades cubren la vista dinmica de un sistema. Son especialmente
importantes al modelar el funcionamiento de un sistema y resaltan el flujo de
control entre objetos.

Un diagrama de componentes muestra la organizacin y las dependencias entre
un conjunto de componentes. Los diagramas de componentes cubre la vista de
implementacin esttica de un sistema. Se relacionan con los diagramas de de
clases en que un componente se corresponde, por lo comn, con una o ms
clases, interfaces o colaboraciones.

Un diagrama de despliegue muestra la configuracin de nodos de procesamiento
en tiempo de ejecucin y los componentes que reside en ellos. Los diagramas de
despliegue cubren la vista de despliegue esttica de una arquitectura. Se
relacionan con los diagramas de componentes en que un nodo incluye, por lo
comn, uno o ms componentes.

49

Esta no es una lista cerrada de diagramas. Las herramientas pueden utilizar UML
para proporcionar otros tipos de diagramas, aunque estos nueve son, con mucho,
los que con mayor frecuencia aparecern en la prctica.

Reglas de UML
Los bloques de construccin de UML no pueden simplemente combinarse de
cualquier manera. Como cualquier lenguaje, UML tiene un nmero de reglas que
especifican a qu debe parecerse un modelo bien formado. Un modelo bien
formado es aqul que es semnticamente auto-consistente y est en armona con
todos sus modelos relacionados.

UML tiene reglas semnticas para:
Nombres, Cmo llamar a los elementos, relaciones y diagramas.
Alcance, El contexto que da un significado especfico a un nombre.
Visibilidad, Cmo se pueden ver y utilizar esos nombres por otros.
Integridad, Cmo se relacionan apropiada y consistentemente unos elementos
con otros.
Ejecucin , Qu significa ejecutar o simular un modelo dinmico.

Los modelos construidos durante el desarrollo de un sistema con gran cantidad de
software tienden a evolucionar y pueden ser vistos por diferentes usuarios de
formas diferentes y en momentos diferentes. Por esta razn, es comn en el
equipo de desarrollo no slo construir modelos bien formados, sino tambin
construir modelos que sean:
Abreviados, Ciertos elementos se ocultan para simplificar la vista.

50
Incompletos, Pueden estar ausentes ciertos elementos.
Inconsistentes, No se garantiza la integridad del modelo.

Estos modelos que no llegan a ser bien formados son inevitables conforme los
detalles de un sistema van apareciendo y mezclndose durante el proceso de
desarrollo de software. Las reglas de UML estimulan (pero no obligan) a
considerar las cuestiones ms importantes de anlisis, diseo e implementacin
que llevan a tales sistemas a convertirse en bien formados con el paso del tiempo.

Mecanismos comunes en UML
Un edificio se hace ms simple y ms simple y ms armonioso al ajustarse a un
patrn de caractersticas comunes. Una casa puede construirse, en su mayor
parte, de estilo victoriano o francs utilizando ciertos patrones arquitectnicos que
definen esos estilos. Lo mismo es cierto para UML. Este se simplifica mediante la
presencia de cuatro mecanismos comunes que se aplican de forma consistente a
travs de todo el lenguaje:
1. Especificaciones.
2. Adornos.
3. Divisiones comunes.
4. Mecanismos de extensibilidad.

Especificaciones. UML es algo ms que un lenguaje grfico. Ms bien, detrs de
cada elemento de su notacin grfica hay una especificacin que proporciona una
explicacin textual de la sintaxis y semntica de ese bloque de construccin. Por
ejemplo, detrs de un icono de clase hay una especificacin que proporciona el
conjunto completo de atributos, operaciones (incluyendo sus signaturas

51
completas) y comportamiento que incluye la clase; visualmente, ese icono de
clase puede mostrar slo una pequea parte de especificacin.
Las especificaciones de UML proporcionan una base semntica que incluy a todos
los elementos de todos los modelos de un sistema, y cada elemento est
relacionado con otros de manera consistente. Los diagramas de UML son as
simples proyecciones visuales de esa base, y cada diagrama revela un aspecto
especfico interesante del sistema.

Adornos. La mayora de los elementos de UML tienen una nica y clara notacin
grfica que proporciona una representacin visual de los aspectos ms
importantes del elemento. Por ejemplo, la notacin para una clase se ha diseado
intencionadamente de forma que sea fcil de dibujar, porque las clases son los
elementos que aparecen con ms frecuencia al modelar sistemas orientados a
objetos. La notacin de la clase tambin revela los aspectos ms importantes de
una clase, a saber: su nombre, atributos y operaciones.

Divisiones comunes. Al modelar sistemas orientados a objetos, el mundo puede
dividirse, al menos, en un par de formas.
En primer lugar, esta la divisin entre clase y objeto. Una clase es una
abstraccin; un objeto es una manifestacin concreta de esa abstraccin.
En segundo lugar, tenemos la separacin entre interfaz e implementacin. Una
interfaz declara un contrato, y una implementacin representa una realizacin
concreta de ese contrato, responsable de hacer efectiva de forma fidedigna la
semntica completa de la interfaz.

Mecanismos de extensibilidad. UML proporciona un lenguaje estndar para
escribir planos software, pero no es posible que un lenguaje cerrado sea siempre

52
suficiente para expresar todos los matices posibles de todos los modelos en todos
los dominios y en todos los momentos. Por esta razn, UML es abierto-cerrado,
siendo posible extender el lenguaje de manera controlada. Los mecanismos de
extensin de UML incluyen:
Estereotipos.
Valores etiquetados.
Restricciones.

CASOS DE USO

Ningn sistema se encuentra aislado. Cualquier sistema interesante interacta con
actores humanos o mecnicos que lo utilizan con algn objetivo y que esperan
que el sistema funcione de forma predecible. Un caso de uso especifica el
comportamiento de un sistema o de una parte del mismo, y es una descripcin de
un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un
sistema para producir un resultado observable de valor para un actor.
Los casos de uso se emplean para capturar el comportamiento deseado del
sistema en desarrollo, sin tener que especificar cmo se implementa ese
comportamiento. Los casos de uso proporcionan un medio para que los
desarrolladores, los usuario finales del sistema y los expertos del dominio lleguen
a una comprensin comn del sistema. Adems, los casos de uso ayudan a
validar la arquitectura y a verificar el sistema mientras evoluciona a lo largo del
desarrollo. Conforme se desarrolla el sistema, los casos de uso son realizados por
colaboraciones, cuyos elementos cooperan para llevar a cabo cada caso de uso.

53
Los casos de uso bien estructurados denotan slo comportamientos esenciales
del sistema o de un subsistema, y nunca debe ser excesivamente genricos ni
demasiados especficos.
Un caso de uso es una descripcin de un conjunto de secuencias de acciones,
incluyendo variantes, que ejecuta un sistema para producir un resultado
observable, de valor para un actor. Hay arias partes importantes en esta
definicin.
Un caso de uso describe un conjunto de secuencias, donde cada secuencia
representa la interaccin de los elementos externos al sistema (sus actores) con el
propio sistema (y con sus abstracciones claves). En realidad, estos
comportamientos son funciones a nivel del sistema que se utilizan durante la
captura de requisitos y el anlisis para visualizar, especificar, construir y
documentar el comportamiento esperado del sistema. Un caso de uso representa
un requisito funcional del sistema. Por ejemplo, un caso de uso fundamental en un
banco es el procesamiento de prstamos. Como se muestra en la figura 1.
5HVSRQVDEOH3UHVWDPRV
3URFHVDU3UpVWDP R
&DVRGHXVR
$FWRU

Ilustracin 2 - Actores y Casos de uso.

Trminos y conceptos
Un caso de uso es una descripcin de un conjunto de secuencias de acciones,
incluyendo variantes, que ejecuta un sistema para producir un resultado

54
observable de valor para un actor. Grficamente, un caso de uso se representa
como una elipse.

Nombres
Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso. Un
nombre es una cadena de texto. Ese nombre solo se llama nombre simple; un
nombre de cami no consta del nombre del caso de uso precedido del nombre del
paquete en el que se encuentra. Normalmente, un caso de uso se dibuja
mostrando slo su nombre, como se muestra en la figura 2.

Ilustracin 3 - Nombres simples y de camino

Casos de uso y actores
Un actor representa un conjunto coherente de roles que los usuario de los casos
de uso juegan al interactuar con stos. Normalmente, un actor representa un rol
que es jugado por una persona, un dispositivo hardware o incluso otro sistema al
interactuar con nuestro sistema.

Casos de uso y flujo de eventos
Un caso de uso describe qu hace un sistema (o un subsistema, una clase o una
interfaz), pero no especifica cmo lo hace. Cuando se modela, es importante tener
clara la separacin de objetivos entre las vistas externa e interna.

55
El comportamiento de un caso de uso se puede especificar describiendo un flujo
de eventos de forma textual, lo suficientemente claro para que alguien ajeno al
sistema lo entienda fcilmente. Cuando se escribe este flujo de eventos se debe
incluir cmo y cundo empieza y acaba el caso de uso, cundo interacta con los
actores y qu objetos se intercambian, el flujo bsico y los flujos alternativos del
comportamiento.

Casos de uso y escenarios
Normalmente, primero se describe el flujo de eventos de un caso de uso mediante
texto. Sin embargo, conforme se mejora la comprensin de los requisitos del
sistema estos flujos se pueden especificar grficamente mediante diagramas de
interaccin. Normalmente, se usa un diagrama de secuencia para especificar el
flujo principal de un caso de uso, y se usan variaciones de ese diagrama para
especificar los flujos excepcionales del caso de uso.
Conviene separar el flujo principal de los flujos alternativos, parque un caso de uso
describe un conjunto se secuencias, no una nica secuencia, y sera imposible
expresar todos los detalles de un caso de uso no trivial en una nica secuencia.

Casos de uso y colaboraciones
Un caso de uso captura el comportamiento esperado del sistema (o subsistema,
clase o interfaz) que se est desarrollando, sin tener que especificar cmo se
implementa ese comportamiento. Esta separacin es importante porque el anlisis
de un sistema (que especifica un comportamiento) no debera estar influenciado,
mientras sea posible, por cuestiones de implementacin (que especifican cmo se
lleva a cabo el comportamiento). No obstante un caso de uso debe implementarse
al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos
que colaborarn para llevar a cabo el comportamiento del caso de uso. Esta

56
sociedad de elementos, incluyendo tanto su estructura esttica como la dinmica,
se modela en UML como una colaboracin.

DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso son uno de los cinco tipo de diagramas de UML
que se utilizan para el modelado de los aspectos dinmicos de un sistema (los
otros cuatro tipos son los diagramas de actividades, de estados, de secuencia y de
colaboracin). Los diagramas de casos de uso son importantes para modelar el
comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un
conjunto de casos de uso, actores y sus relaciones.
Los diagramas de casos de uso se emplean para modelar la vista de casos de uso
de un sistema. La mayora de las veces, esto implica modelar el contexto del
sistema, subsistema o clase, o el modelado de los requisitos de comportamiento
de esos elementos.
Los diagramas de casos de uso son importantes para visualizar, especificar y
documentar el comportamiento de un elemento. Estos diagramas facilitan que los
sistemas, subsistemas y clases sean abordables y comprensibles, al presentar
una vista externa de cmo pueden utilizarse estos elementos en un contexto dado.
Los diagramas de casos de uso tambin son importantes, para probar sistemas
ejecutables a travs de ingeniera directa y para comprender sistemas ejecutables
a travs de ingeniera inversa.

Trminos y conceptos
Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos
de uso, actores y sus relaciones.

57

Propiedades comunes
Un diagrama de casos de uso es un tipo especial de diagrama y comparte las
propiedades comunes al resto de los diagramas (un nombre y un contenido grfico
que es una proyeccin de un modelo). Lo que distingue a un diagrama de casos
de uso de los otros tipos de diagramas es su contenido particular.

Contenidos
Normalmente, un diagrama de casos de uso contiene:
Casos de uso.
Actores.
Relaciones de dependencia, generalizacin y asociacin.

Al igual que los dems diagramas, los diagramas de casos de uso pueden
contener notas y restricciones.

Usos comunes
Los diagramas de casos de uso se emplean para modelar la vista de casos de uso
esttica de un sistema. Esta vista cubre principalmente el comportamiento del
sistema (los servicios visibles externamente que proporciona el sistema en el
contexto de su entorno).
Cuando se modela la vista de casos de uso esttica de un sistema, normalmente
se emplearn los diagramas de casos de uso de una de las dos formas siguientes:

1. para modelar el contexto de un sistema.

58
Modelar el contexto de un sistema implica dibujar una lnea alrededor de todo
el sistema y asegurar qu actores quedan fuera del sistema e interactan con
l. Aqu, se emplearn los diagramas de casos de uso para especificar los
actores y el significado de sus roles.
2. para modelar los requisitos de un sistema.
El modelado de los requisitos de un sistema implica especificar qu debera
hacer el sistema (desde un punto de vista externo), independientemente de
cmo se haga. Aqu se emplearn los diagramas de casos de uso, para
especificar el comportamiento deseado del sistema. De esta forma, un
diagrama de casos de uso permite ver el sistema entero como una caja negra;
se puede ver qu hay fuera del sistema ycmo reacciona a los elementos
externos, pero no se puede ver cmo funciona por dentro. Ver figura 3.

Ilustracin 4 - Ejemplo de Diagrama de Casos de uso

59
DIAGRAMA DE ACTIVIDADES

Los diagramas de actividades son uno de los cinco tipo de diagramas de UML que
se utilizan para el modelado de los aspectos dinmicos de los sistemas. Un
diagrama de actividades es fundamentalmente un diagrama de flujo que muestra
el flujo de control entre actividades.
Los diagramas de actividades se utilizan para modelar los aspectos dinmicos de
un sistema. La mayora de las veces, esto implica modelar los pasos secuenciales
(y posiblemente concurrentes) de un proceso computacional. Con un diagrama de
actividades tambin se puede modelar el flujo de un objeto conforme pasa de
estado a estado en diferentes puntos del flujo de control. Los diagramas de
actividades pueden utilizarse para visualizar, especificar, construir y documentar la
dinmica de una sociedad de objetos, o pueden emplearse para modelar el flujo
de control de una operacin. Mientras que los diagramas de interaccin destacan
el fuljo de control entre objetos, los diagramas de actividades destacan el flujo de
control entre actividades. Una actividad es una ejecucin atmica en curso, dentro
de una mquina de estados. Las actividades producen alguna accin, compuesta
de computaciones atmicas ejecutables que producen un cambio en el estado del
sistema o el retorno de un valor.

Trminos y conceptos
Un diagrama de actividades muestra el flujo de actividades. Una actividad es una
ejecucin no atmica en curso, dentro de una mquina de estados. Las
actividades producen finalmente alguna accin, que est compuesta de
computaciones atmicas ejecutables que producen un cambio en el estado del
sistema o la devolucin de un valor. Las acciones incluyen llamadas a otras
operaciones, envo de seales, creacin de destruccin de objetos o simples

60
clculo, como la evaluacin de una expresin. Grficamente, un diagrama de
actividades es una coleccin de nodos y arcos.

Ilustracin 5 - Ejemplo de Diagrama de Actividades

Propiedades comunes
Un diagrama de actividades es un tipo especial de diagrama y comparte las
que es una proyeccin de un modelo). Lo que distingue a un diagrama de
actividades de los otros tipos de diagramas es su contenido.

61
Contenidos
Normalmente, los diagramas de actividades contienen:
Estados de actividad y estados de accin.
Transiciones.
Objetos.

Al igual que los dems diagramas, los diagramas de actividades pueden contener
restricciones.

Usos comunes
Los diagramas de actividades se utilizan para modelar los aspectos dinmicos de
un sistema. Estos aspectos dinmicos pueden involucrar la actividad de cualquier
tipo de abstraccin en cualquier vista de la arquitectura de un sistema, incluyendo
clases (las cuales pueden ser clases activas), interfaces, componentes y nodos.
Cuando se modelan los aspectos dinmicos de un sistema, normalmente se
utilizan los diagramas de actividades de dos formas.
1. Para modelar un flujo de trabajo.
Para ello se hace hincapi en las actividades, tal y como son vistas por los
actores que colaboran con el sistema. A menudo, en el entorno de los sistemas
con gran cantidad de software, existen flujos de trabajo y se utilizan para
visualizar, especificar, construir y documentar procesos de negocio que
implican al sistema que se est desarrollando. En este uso de los diagramas
de actividades, es particularmente importante el modelado de los flujos de
objetos.
2. Para modelar una operacin.

62
Para ello se utilizan los diagramas de actividades como diagramas de flujo,
para modelar los detalles de una computacin. En este uso de los diagramas
de actividades, es particularmente importante el modelado de la bifurcacin, la
divisin y la unin. El contexto de un diagrama de actividades utilizado con esta
finalidad incluye los parmetros de la operacin, as como sus objetos locales.

DIAGRAMAS DE ESTADOS

Los diagramas de estados (statechart) son uno de los cinco tipo de diagramas de
UML que se utilizan para el modelado de los aspectos dinmicos de un sistema.
Un diagrama de estados muestra una mquina de estados. Un diagrama de
actividades es un caso especial de diagrama de estados en el cual todos o la
mayora de los estados son estados de actividad y todas o la mayora de las
transiciones se disparan por la terminacin de las actividades en el estado origen.
As, tanto los diagramas de actividades como los diagramas de estados son tiles
para modelar la vida de un objeto. Sin embargo, mientras un diagrama de
actividades muestra el flujo de control entre actividades, un diagrama de estados
muestra el flujo de control entre estados.

Trminos y conceptos
Un diagrama de estados muestra una mquina de estados, destacando el flujo de
control entre estados. Una mquina de estados es un comportamiento que
especifica las secuencias de estados por las que pasa un objeto a lo largo de su
vida en respuesta a eventos, con sus respuestas a esos eventos. Un estado es
una condicin o situacin en la vida de un objeto durante la cual satisface alguna
condicin, realiza alguna actividad o espera algn evento. Un evento es la
especificacin de un acontecimiento significativo que ocupa un lugar en el tiempo

63
y en el espacio. En el contexto de las mquinas de estados, un evento es la
aparicin de un estmulo que puede activar una transicin de estado. Una
transicin es una relacin entre dos estados que indica que un objeto que est en
el primer estado realizar ciertas acciones y entrar en el segundo estado cuando
ocurra un evento especificado y se satisfagan unas condiciones especificadas.
Una actividad es una ejecucin no atmica en curso, dentro de una mquina de
estados. Una accin es una computacin atmica ejecutable que produce un
cambio en el estado del modelo o la devolucin de un valor. Grficamente, un
diagrama de estados es una coleccin de nodos y arcos.

Propiedades comunes
Un diagrama de estados es un tipo especial de diagrama y comparte las
que es una proyeccin de un modelo). Lo que distingue a un diagrama de estados
de los otros tipos de diagramas es su contenido particular.

Contenidos
Normalmente, los diagramas de estados contienen:
Estados simples y compuestos.
Transiciones, incluyendo eventos y acciones.

Al igual que los dems diagramas, los diagramas de estados pueden contener
notas y restricciones.

64
DIAGRAMAS DE INTERACCIN

Los diagramas de secuencia y los diagramas de colaboracin (ambos llamados
diagramas de interaccin) son dos de los cinco tipos de diagramas de UML que se
utilizan para modelar los aspectos dinmicos de los sistemas. Un diagrama de
interaccin muestra una interaccin, que consiste en un conjunto de objetos y sus
relaciones, incluyendo los mensajes que se pueden enviar entre ellos. Un
diagrama de secuencia es un diagrama de interaccin que destaca la ordenacin
temporal de los mensajes; un diagrama de colaboracin es un diagrama de
interaccin que destaca la organizacin estructural de los objetos que envan y
reciben mensajes.
Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de
un sistema. La mayora de las veces, esto implica modelar instancias concretas o
prototpicas de clases, interfaces, componente y nodos, junto con los mensajes
enviados entre ellos, todo en el contexto de un escenario que ilustra un
comportamiento. Los diagramas de interaccin pueden utilizarse para visualizar,
especificar, construir y documentar la dinmica de una sociedad particular de
objetos, o se pueden utilizar para modelar un flujo de control particular de un caso
de uso.

Trminos y conceptos
Un diagrama de interaccin muestra una interaccin, que consta de un conjunto
de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre
ellos. Un diagrama de secuencia es un diagrama de interaccin que destaca la
ordenacin temporal de los mensajes. Grficamente, un diagrama de secuencia es
una tabla que representa objetos, dispuestos a lo largo del eje X, y mensajes,
ordenados segn se suceden en el tiempo, a lo largo del eje Y. Un diagrama de
colaboracin es un diagrama de interaccin que destaca la organizacin

65
estructural de los objetos que envan y reciben mensajes. Grficamente, un
diagrama de colaboracin es una coleccin de nodos y arcos.

Propiedades comunes
Un diagrama de interaccin es un tipo especial de diagrama y comparte las
que es una proyeccin de un modelo).

Contenidos
Normalmente, los diagramas de interaccin contienen:
Objetos.
Enlaces.
Mensajes.

Diagramas de secuencia
Un diagrama de secuencia destaca la ordenacin temporal de los mensajes. Un
diagrama se secuencia se forma colocando en primer lugar los objetos que
participan en la interaccin en la parte superior del diagrama, a lo largo del eje X.
normalmente, se coloca a la izquierda del objeto que inicia la interaccin, y los
objetos subordinados a la derecha. A continuacin, se colocan los mensajes que
estos objetos envan y reciben a lo largo del eje Y, en orden de sucesin en el
tiempo, desde arriba hasta abajo. Esto ofrece al lector una seal visual clara del
flujo de control a lo largo del tiempo.

66
Diagramas de colaboracin
Un diagrama de colaboracin destaca la organizacin de los objetos que
participan en una interaccin. Un diagrama de colaboracin se construye
colocando en primer lugar los objetos que participan en la colaboracin como
nodos del grafo. A continuacin se representan los enlaces que conectan esos
objetos como arcos del grafo. Por ltimo, estos enlaces se adornan con los
mensajes que envan y reciben los objetos. Esto da al lector una seal visual clara
del flujo de control en el contexto de la organizacin estructural de los objetos que
colaboran.

Usos comunes
Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de
un sistema. Estos aspectos dinmicos pueden involucrar la interaccin de
cualquier tipo de instancia en cualquier vista de la arquitectura de un sistema,
incluyendo instancias de clases (incluso clases activas), interfaces, componentes y
nodos.
[sacado del libro El Lenguaje Unificado de Modelado, de Grady Booch, Ivar
Jacobson y James Rumbaugh]

67

3. PLANEACIN Y ELABORACIN DEL SISTEMA

3.1. Sistema Actual (DIVERTRONICA MEDELLIN S.A.)
La empresa cuenta con una serie de mquinas instaladas en el parque de
diversin del centro comercial Sandiego. Estas pueden trabajar con fichas (tokens)
que en el momento en que se le introducen empieza su funcionamiento, como
tambin hay otras que son operadas directamente por los promotores de venta y a
stos les entregan boletas y ponen en funcionamiento la atraccin.
Las fichas o boletas con las que funcionan las atracciones son vendidas en una
taquilla y una vez sean compradas por el cliente ste las puede utilizar en ese
momento o llevrselas y volver luego para hacer uso de ellas. En ocasiones el
cliente cambia fichas compradas por boletera o viceversa, esto en el caso de que
cambie de decisin sobre en cual atraccin utilizar. En las mquinas que
funcionan con fichas estas tienen un contador que aumenta en el momento que
pasan por el monedero que tiene las atracciones, entonces para saber cuanto a
vendido una mquina en especial, deben de destapar la alcanca donde han cado
las fichas y contarlas una a una y confrontar el conteo con el consecutivo que se
registra en ese momento en el contador de fichas de la mquina. De esta manera
se sabr cuales han sido las ventas de la atraccin. De forma similar se liquidan
las ventas de las atracciones que funcionan con boletera, solo que en stas el
promotor anota las boletas que recibe por parte de los clientes en el momento que
pone en funcionamiento la atraccin.
Para recaudar las ventas hechas por las atracciones durante un perodo de tiempo
cualquiera, es necesario que el parque no est en funcionamiento y se necesitan
por lo general ms de una persona para el proceso.

68
3.2. Ciclo de Vida
El proceso inicia cuando un cliente se acerca a una taquilla de venta del parque de
diversin Sandiego, a comprar fichas o boletas, para hacer uso de los juegos (hay
mquinas que trabajan con boletera y otras con fichas). Una vez el cliente hace
su compra se dirige a las atracciones, solo las que funcionan con boletas son
atendidas por promotores de ventas, en ste caso el promotor recibe la boleta del
cliente y la registra en su planilla de control de boletera, en la que anota la hora y
la cantidad, rompe la boleta y la deposita en una bolsa, posteriormente el promotor
pone en funcionamiento la atraccin, cuando termina el turno el cliente se retira, o
puede entregar otra boleta y continuar con otro turno.
En las atracciones que funcionan con fichas, el cliente simplemente inserta el
nmero de fichas en el monedero, segn lo indique un sticker que tiene ste, por
si funciona con 1 2 fichas, el cliente puede hacer uso de esta atraccin cuantas
veces lo desee. Si al cliente se le acaban las fichas o las boletas, las puede
comprar nuevamente en la taquilla.
Las taquillas tienen fichas suficientes para vender en toda una jornada de servicio,
pero si se presentara el caso de que se les acaban las fichas, proceden a liquidar
algunas mquinas, para sacar las fichas que stas tengan y colocan all el
equivalente al dinero sacado o un papel en el que quede escrito cuntas fichas
sacaron, en este proceso toman el contador final encontrado en la atraccin, para
cuando llegue el periodo de liquidacin esto quede muy bien entendido.
Los clientes se pueden llevar las fichas o las boletas y luego volver al parque a
hacer uso de ellas o incluso pueden ir a otro de los parques que la empresa posee
y utilizarlas.
Semanal, decadal o quincenal mente se hace la l iquidacin de todo el local, se
llega ms temprano en la maana y antes de que se abra el parque al pblico se
hace ste procedimiento. Para la liquidacin, pasan por todas las mquinas (las
que funcionan con fichas) abriendo sus alcancas, se cuentan las fichas

69
encontradas y las registran en un formato de liquidacin de planillas que se
imprimen para ste fin. Este formato de liquidacin que se maneja tiene los
siguientes campos a llenar: (Ver Anexo I)
Planilla de Corte No.
Como encabezado: datos de la empresa y del local a liquidar
Fecha
Cantidad de fichas
Valor Oficina
Valor Local
Total
Serie
Lnea
Moneda
Contador final
Contador inicial
Fichas
Porcentaje propio
Redencin
Mantenimiento
Operario
Cdula No.
Recib
Firma y Sello

70
En las atracciones que funcionan con boletera, diariamente se contabilizan las
boletas encontradas y se anotan en un cuaderno para cuando se liquide en un
periodo dado se registran estos datos en la planilla de corte. (Ver anexo II)
Una vez se hace la liquidacin y su respectivo asiento, se da inicio a otro periodo y
los datos quedan registrados en el programa. Al finalizar el mes se cierra ste
sacando un informe de producidos por local y por mquinas a parte de otras
funciones que tiene.

3.3. mbito del Software
Se desarrollar un prototipo de software que permita registrar en el parque de
diversin todas las mquinas estn instaladas, esto se har con las caractersticas
tcnicas que tiene cada una, es decir, como una hoja de vida por atraccin, este
prototipo permitir hacer el registro de los lectores que estn instalados por cada
atraccin y tambin manejar una ficha tcnica, similar a las atracciones. El
prototipo funcionar localmente y permitir hacer una simulacin de ventas por
atraccin, en el cual se seleccionar la atraccin en la cual se desea hacer uso
con la tarjeta de banda magntica que se vender en un pos bsico, donde solo
se vendern tarjetas cargadas con dinero compradas por el cliente, al hacer uso
de las tarjetas en el lector conectado localmente al computador, el software
descontar automticamente sobre el saldo que tenga la tarjeta el costo del turno
en la atraccin seleccionada. Una vez esto suceda se registrar una venta por
atraccin con sus datos respectivos, para mostrar en el momento que se desee las
ventas realizadas por el parque por cada atraccin instalada.

3.3.1 Descomposicin
Las funciones ms importantes del software:

71
* Lectura-escritura en las tarjetas.
* Capturar datos de un lector de tarjetas.
* Validar informacin capturada.
* Hacer operaciones con los datos ledos.

3.4. OBJETIVOS

3.4.1 Objetivo General
Desarrollar e implementar un prototipo para dar solucin a la gestin
administrativa del parque de recreacin San Diego validado con un lector de
tarjeta de banda magntica.

3.4.2 Objetivos especficos

a. Adquirir los requerimientos necesarios por parte del cliente (Divertrnica
Medelln S.A.)

b. Analizar los requerimientos obtenidos del usuario y del hardware necesario para
modelar el sistema.

c. Modelar el diseo de implementacin del prototipo utilizando el Lenguaje
Unificado de Modelado haciendo los Diagramas necesarios.

72
d. Crear la base de datos que manejar la informacin del prototipo.

e. Implementar un prototipo en conjunto con la base de datos, la tarjeta magntica
y la captura de datos del lector.

f. Probar el prototipo implementado donde se verificara que la informacin
grabada en la tarjeta de banda magntica sea leda correctamente por el lector.

3.5 DISEO METODOLOGICO

3.5.1 METODOLOGA DE DESARROLLO
En vista de que este aplicativo de un alto grado de complejidad y como en un
futuro se implementara para trabajar en red, se utilizar la notacin UML
(Lenguaje Unificado de Modelado) para desarrollar el prototipo, ya que es la ms
apropiada para este fin, en los procesos de anlisis y diseo.

3.5.2 INSTRUMENTOS Y TCNICAS DE RECOLECCIN DE DATOS
La tcnica utilizada para la recoleccin de la informacin es la entrevista a los
involucrados en el proceso, como son:
Gerente General.
Administradores y Supervisores del punto de venta.
Promotores de las atracciones.
Tambin para la recoleccin de datos se ir al parque recreativo como cliente para
mirar desde ese punto de vista cmo funcionan las cosas.

73

3.6. ALCANCES DEL SISTEMA
Este sistema est conformado por varios mdulos, los cuales son:
Lectores.
Atracciones.
Pos.
Administrativo.

3.6.1 Mdulo Lectores
Se encarga de manejar todo lo referente a los lectores, cuando son comprados por
la empresa y llevados al parque.
Matrcula de Lectores.
Estado de las atracciones (activa o inactiva).
Configuracin de Lectores. (en un futuro cuando estn en red)
Polticas de comunicacin. (en un futuro cuando estn en red)

3.6.2 Mdulo Atracciones
Se encarga de manejar todo lo referente a las atracciones, cuando son instaladas
por la empresa en el parque de diversin, se les registrar toda la informacin
respectiva.
Matrcula de Atracciones.
Asignacin de lectores de atracciones.

74
3.6.3 Mdulo Pos
Se encarga de manejar todo lo referente al Punto de Venta, dentro del parque de
diversin.
Venta de tarjetas magnticas.
Devolucin.
Consulta de ventas.
Consulta de saldo en tarjetas.

3.6.4 Mdulo Administrativo
Se encarga de manejar la administracin de la aplicacin, esta ser hecha por el
administrador o supervisor del parque.
Ingresar informacin de la empresa.
Creacin del archivo maestro de lneas.
Informacin sobre reportes.
Informacin sobre la red. (en un futuro cuando se implemente)
Captura de datos del lector. (en un futuro cuando se trabaje en red)

3.7. RESULTADOS ESPERADOS
El prototipo a desarrollar permitir grabar en una tarjeta de banda magntica un
valor (cash) que fue decidido comprar por el cliente en el Pos, con sta l podr
hacer uso de las atracciones a travs de un lector de tarjetas, sin necesidad de
insertar fichas o monedas en las atracciones o entregar a un operario una boleta
(se simular esto en el mismo software localmente). Permitir generar reportes del
parque para conocer cules han sido las ventas de las atracciones, conociendo un

75
informe general. Permitir hacer la lectura de tarjetas a travs del lector en el
momento que se desee. Permitir sacar una serie de informes que generan a la
administracin del parque conocimiento sobre la gestin.

76
3.8. BENEFICIOS DEL SISTEMA

3.8.1 Beneficios Econmicos
Los beneficios econmicos que puede obtener DIVERTRONICA MEDELLIN S.A.
con un sistema de estos son:
Disminucin del tiempo del personal encargado en la liquidacin de las ventas
del parque.
Mayor agilidad en la utilizacin de las mquinas por parte de los clientes
generando as mayor nmero de utilizacin de las atracciones.

3.8.2 Beneficios Administrativos
Mayor agilidad en la toma de decisiones con respecto a la entrega de informes
de gestin del parque.
Mayor agilidad y facilidad para los clientes en la compra de tarjetas con dinero,
generando mayor calidad y comodidad en el servicio.
Mayor seguridad y control en el uso de las atracciones.
Mayor satisfaccin del personal involucrado en el proceso de gestin del
parque por la eficiencia y eficacia de la administracin del mismo.

3.9. RESTRICCIONES DEL SISTEMA
El sistema no controlar el buen uso de las atracciones en las que hay
operarios, ya que no habra forma de controlar si el operario inserta o no la
tarjeta en el lector.

77
La configuracin de los lectores solo estar a cargo del administrador del
aplicativo.
Los controles para los posibles errores, fraudes o alguna situacin relacionada,
solo se llevar a cabo manualmente ya que el sistema no puede verificar que
los procesos se lleven a cabo correctamente.

3.10. ESTUDIO DE FACTIBILIDAD Y VIABILIDAD

3.10.1 RECURSOS ECONOMICOS
La empresa dispondr de un presupuesto para los gastos de instalacin o
mantenimiento de la aplicacin, como tambin en el tiempo del anlisis, diseo y
desarrollo de las personas involucradas para llevar a cabo estas tareas.

78
3.10.2 Presupuesto
CONCEPTO PRESUPUESTO
APORTA DIVERTRONICA S.A. APORTE OTROS
Personal
Investigador Principal 10.740.000
Investigador Auxiliar -
Asesor (s) 500.000
Otros Auxiliares -
Total Parcial 11.240.000

Materiales
Infraestructura Fsica 100.000
Equipo de Oficina 1.160.000
Libros y Revistas 200.000
Otros (detalle) -
Lector de tarjetas 822.500
Tarjetas magnticas 5.000
Total Parcial 827.500 1.460.000

Gastos de Consumo
Utiles de Escritorio y Papeles 100.000
Fotocopias 100.000

79
Materiales Imprenta 80.000
Otros (detalle) -
Total Parcial 280.000

Gastos Varios
Pasajes 960.000
Viticos 360.000
Gastos Publicacin 200.000
Gastos Computacin 200.000
Gastos Instalacin -
Otros (detallar)
Total Parcial 1.720.000

Gran Total 13.207.500
Tabla 1 - Presupuesto

3.10.3 Recursos Informticos

a. Hardware
DIVERTRONICA MEDELLIN S.A. cuenta con:
Computadores
o Ninguno en el parque de diversin Sandiego

80
b. Software
DIVERTRONICA MEDELLIN S.A. cuenta con:
Windows NT 4.0 (Oficina sede principal)
Windows Workstation (Oficina sede principal)
Como paquete de ofimtica OpenOffice y Office xp (Oficina sede principal)

c. Recursos Humanos
En el proyecto se encuentra el recurso humano apropiado para llevar a cabo todas
las actividades para el feliz trmino del proyecto, como es el personal de
desarrollo y de soporte.
Personal de desarrollo:
Estudiante Fabin El Gmez Murillo
Personal que asesora el proceso de sistematizacin:
Master Diana Mara Montoya.
Adems, por el personal administrativo de la empresa DIVERTRONICA
MEDELLIN S.A.:
Gerente: Luis Guillermo Hoyos Hoyos
Directora Comercial: Mara Ismenia Restrepo
Administradora: Diana Marcela Zuluaga Murillo
Supervisor: Luis Fernando Tangarife Rojas.

81
3.11. REQUERIMIENTOS DEL SISTEMA

3.11.1 Documentacin de los Casos de Uso.
RF-01 MATRICULA DE LECTORES
VERSION 1.0
ACTORES Usuario limitado, Administrador, Lector.
DESCRIPCION El sistema permitir ingresar un nuevo Lector a la base de
datos.
IMPORTANCIA Alta.
COMENTARIOS Los lectores que se encuentren en funcionamiento tendrn
un estado de activos y lo que estn malos o en reparacin,
tendrn un estado inactivo.

RF-02 CONSULTA DE LECTORES
VERSION 1.0
ACTORES Usuario limitado, Administrador.
DESCRIPCION El sistema permitir consultar la informacin que se
registr de un Lector en la base de datos.
IMPORTANCIA Media.
COMENTARIOS

82

RF-03 MODIFICACION DE LECTORES
VERSION 1.0
DESCRIPCION El sistema permitir modificar la informacin que se
registr de un Lector en la base de datos.
IMPORTANCIA Media.
COMENTARIOS Se podrn modificar todos los excepto el nmero serial.

RF-04 CONFIGURACION DEL LECTOR
VERSION 1.0
DESCRIPCION En un futuro cuando el sistema trabaje en red se podr
configurar la base de datos con la que va a trabajar el
lector. Se le indica si va a recibir tarjetas con dinero o
freeplay (cortesas) y en ste ltimo caso se le indicar las
fechas y las horas en las que funcionara.
IMPORTANCIA Ninguna para el prototipo.
COMENTARIOS La pantalla de captura est diseada pero no funciona ya
que no tendra ningn uso en el prototipo.

83

RF-05 CONSULTA DE CONFIGURACION
DEL LECTOR
VERSION 1.0
DESCRIPCION El sistema permitir consultar la configuracin del lector.
En este proceso se podrn visualizar todas las
caractersticas de l.
IMPORTANCIA Ninguna para el prototipo
COMENTARIOS Esto funcionar en red.

RF-06 MODIFICACION DE LA
CONFIGURACION DEL LECTOR
VERSION 1.0
ACTORES Usuario limitado, Administrado, Lector.
DESCRIPCION En un futuro cuando el sistema trabaje en red se podr en
el sistema modificar la configuracin de la base de datos y
la memoria del lector una vez se haya ingresado las
correcciones.
IMPORTANCIA Ninguna para el prototipo
COMENTARIOS

84

RF-07 DETECTAR LECTOR EN RED
VERSION 1.0
detectar si el Lector est conectado a su puerto serial o en
red.
IMPORTANCIA Baja

RF-08 CAPTURA DE LA MEMORIA DEL LECTOR
VERSION 1.0
DESCRIPCION En un futuro cuando el sistema t rabaje en red permitir
escoger la mquina de la que se desea leer la informacin,
esto puede ser en cualquier momento y a todas o alguna
atraccin en especial.

85

RF-09 LIMPIAR LA MEMORIA DEL LECTOR
VERSION 1.0
limpiar la informacin de la memoria, para poder dar inicio
a otro periodo de liquidacin de mquinas.

RF-10 MATRICULA DE ATRACCIONES
VERSION 1.0
ACTORES Usuario limitado y Administrador.
DESCRIPCION El sistema permitir ingresar las mquinas que se
encuentran instaladas en el parque de recreacin, con
todas sus caractersticas. Como son: referencia, lnea,
nombre, entre otras.
IMPORTANCIA Alta.
COMENTARIOS

86

RF-11 CONSULTA DE ATRACCIONES
VERSION 1.0
DESCRIPCION El sistema permitir consultar la informacin que se
ingres de las mquinas, con todas sus caractersticas.
IMPORTANCIA Media.
COMENTARIOS

RF-12 MODIFICACION DE ATRACCIONES
VERSION 1.0
DESCRIPCION El sistema permitir modificar la informacin que se
ingres de las mquinas, con todas sus caractersticas.
IMPORTANCIA Media.
COMENTARIOS Se podrn modificar todos lo campos excepto el nmero
serial de la atraccin.

87

RF-13 MATRICULA DEL POS
VERSION 1.0
DESCRIPCION El sistema permitir matricular la informacin de un nuevo
POS, con todas sus caractersticas.
IMPORTANCIA Baja para el prototipo.
COMENTARIOS En el prototipo no se hace la matrcula de pos y que solo
se manejar uno, se podra hacer en un futuro para un
parque con muchos POS.

RF-14 CONSULTAR POS
VERSION 1.0
DESCRIPCION El sistema permitir consultar la informacin bsica de un
COMENTARIOS Se implementara en un parque que tuviera varios POS.

88

RF-15 MODIFICAR POS
VERSION 1.0
DESCRIPCION El sistema permitir modificar la informacin bsica de un
COMENTARIOS Se implementara en un parque que tuviera varios POS.

RF-16 APERTURA DE CAJA
VERSION 1.0
DESCRIPCION El sistema permitir hacer una apertura de caja, cada vez
que se ingrese a la opcin del punto de venta.
IMPORTANCIA Alta.
COMENTARIOS Este procedimiento servir de control para cuadrar el turno
de un cajero al hacer el corte X, del pos.

89

RF-17 CORTE DE CAJA
VERSION 1.0
DESCRIPCION El sistema permitir hacer corte de caja, cuando un
promotor del punto de venta va a terminar su turno.
IMPORTANCIA Alta.
COMENTARIOS Este procedimiento servir el control del cierre de turno del
pos.

RF-18 EXPULSAR TARJETA DEL LECTOR
VERSION 1.0
DESCRIPCION El sistema permitir hacer una expulsin de la tarjeta del
lector, esto en el caso de que la tarjeta quede en el lector
mientras este la lee.
IMPORTANCIA Alta.
COMENTARIOS

90

RF-19 VENTA DE TARJETAS
VERSION 1.0
ACTORES Usuario limitado, Administrador, Lector del pos, Tarjeta.
DESCRIPCION El sistema permitir vender: tarjetas magnticas.
IMPORTANCIA Alta.
COMENTARIOS Esta es una de las partes esenciales del prototipo.

RF-20 CONSULTA DE VENTAS
VERSION 1.0
ACTORES Usuario limitado, administrador.
DESCRIPCION El sistema permitir consultar las ventas realizadas en un
turno.
IMPORTANCIA Alta.
COMENTARIOS Estas ventas se refieren al punto de venta, es decir,
facturas de ventas.

91

RF-21 DEVOLUCION DE VENTAS
VERSION 1.0
DESCRIPCION El sistema permitir en un futuro hacer devoluciones de
ventas realizadas.
COMENTARIOS Esto estara activo si se fuera a implantar un punto de
venta completo ya que para fines del prototipo ser muy
bsico.

RF-22 CONSULTA DE CARGA DE TARJETA
VERSION 1.0
ACTORES Usuario limitado, Administrador, Lector de pos, Tarjeta.
DESCRIPCION El sistema permitir leer la informacin contenida en la
memoria de las tarjetas y determinar el estado en que se
encuentra con respecto a: saldo en pesos que tiene la
misma.
IMPORTANCIA Alta.
COMENTARIOS

92

RF-23 CREAR USUARIO
VERSION 1.0
ACTORES Administrador.
DESCRIPCION El sistema permitir crear usuarios que deseen acceder a
la aplicacin, con sus contraseas.
IMPORTANCIA Alta.
COMENTARIOS Pero en el prototipo no hay pantalla de captura para crear
usuarios ya que se enfatiz fue en el uso del lector y
tarjetas.

RF-24 MODIFICAR USUARIO
VERSION 1.0
DESCRIPCION El sistema permitir modificar los usuarios que se hayan
creado en el programa, con sus contraseas.
IMPORTANCIA Media.
COMENTARIOS Pero en el prototipo no hay pantalla de captura para crear
usuarios ya que se enfatiz fue en el uso del lector y
tarjetas.

93

RF-25 REGISTRO DE LA EMPRESA
VERSION 1.0
ACTORES Administrador.
DESCRIPCION El sistema permitir ingresar toda la informacin
correspondiente a la empresa, en cuanto a: su nit, razn
social, ubicacin y otros campos.
IMPORTANCIA Alta.
COMENTARIOS

RF-26 MATRICULA DE LINEAS
VERSION 1.0
ACTORES Usuario Limitado, Administrador.
DESCRIPCION El sistema permitir ingresar la informacin
correspondiente a las lneas en las que clasifican las
atracciones de la empresa, las cuales tienen: Cdigo de
lnea y Descripcin.
IMPORTANCIA Alta.
COMENTARIOS

94

RF-27 MODIFICACION DE LINEAS
VERSION 1.0
ACTORES Usuario Limitado, Administrador.
DESCRIPCION El sistema permitir modificar la informacin
correspondiente a las lneas en las que clasifican las
atracciones de la empresa.
IMPORTANCIA Alta.
COMENTARIOS Solo se podr modificar la descripcin.

RF-28 FREEPLAY
VERSION 1.0
ACTORES Administrador, Lector de pos, Tarjeta.
DESCRIPCION En un futuro cuando se implemente en red se podr activar
una tarjeta para que quede freeplay y pueda ser usada en
las mquinas individuales del parque, de manera gratuita.
COMENTARIOS Esto quedara en un reporte de ventas como cortesas.

95
3.11.2 Requerimientos no Funcionales

El sistema debe generar los siguientes reportes:
LECTORES
o Lectores.
o Lectores por atraccin.
ATRACCIONES
o Atracciones.
o Atracciones por lector.
VENTAS
o Ventas por atraccin.
o Ventas por lneas.
PUNTO DE VENTA
o Ventas de pos.

3.11.3 Requerimientos de Prestaciones
El acceso a la base de datos debe durar mximo 20 segundos para cualquier
ejecucin que se lleve a cabo.

3.11.4 Requerimientos de Interfaz
La interfaz ser a travs de ventanas tipo sistema operativo Windows con
todos sus controles.

96
3.11.5 Requerimientos de Operaciones
El sistema accesar la base de datos de forma directa ya que esta se
encontrar instalada en el equipo local.

3.11.6 Requerimientos de Entorno de Desarrollo
El sistema se desarrollar en Microsoft Access Xp y Microsoft Visual Basic 6.0

3.11.7 Requerimientos de Verificacin
El plan de pruebas que se aplicar al sistema, en la bsqueda de errores,
confrontando los requerimientos establecidos.

3.11.8 Requerimientos de Pruebas de Aceptacin
El cliente verificar el sistema probndolo y confrontando los requerimientos
que en un inicio se pactaron, l deber certificar si aprueba o no el sistema.

3.11.9 Requerimientos de Documentacin
Se entregar el manual de usuario de la aplicacin, donde estar la manera
cmo se debe de operar el sistema.

3.12. RESTRICCIONES DE DISEO
La aplicacin se desarrollar para trabajar con una resolucin mnima de 800 x
600 pxeles.

97
3.13. ATRIBUTOS DE CALIDAD

3.13.1 Seguridad
Cada usuario debe tener su identificacin y su contrasea, a dems del tipo de
usuario se le asignar ciertos permisos en el sistema.

3.13.2 Portabilidad
El sistema funcionar en Windows 98 o superior.

3.13.3 Revisiones de Calidad
El plan de calidad estar definido por las siguientes especificaciones:
o Inspeccionar el diseo y el cdigo fuente en bsqueda de posibles
errores como, bucles infinitos o cdigo redundante.
o Llevar a cabo un anlisis tcnico del producto o su documentacin para
encontrar diferencias o faltantes entre las especificaciones y la
herramienta de software.

3.13.4 Confiabilidad
El sistema debe ser estable y cumplir con las normas de compatibilidad entre el
software y hardware que posee la empresa.

3.13.5 Mantenibilidad
Se tendr la posibilidad de compactar la informacin.

98
4. MODULO LECTORES

4.1. OBJETIVOS
Matricular y configurar los lectores.
Definir las polticas de comunicacin.

4.2. Casos de uso

4.2.1 Caso de uso: MATRICULA DE LECTORES
Tipo: primario
Actor: Usuario limitado, Administrador, Lector.
Descripcin: proceso en el cual se ingresa a la base de datos la referencia
de un lector.

Flujo de eventos principal
el caso de uso inicia cuando el usuario da clic en la opcin Lectores del
men principal REGISTROS, una vez se abra la ventana y se le d clic
en el icono Nuevo , se podr entrar los siguientes datos:
Nro_serial, Descripcin, Marca, Modelo, Activo, Fecha de ingreso. Una
vez se hayan entrado todos los datos se podr grabar o cancelar el
registro ingresado, con un icono de guardar o Cancelar,
respectivamente.
El sistema indicar si al grabar el registro el nmero de serie ya existe o
no, y en caso de existir no permitir guardar la informacin ya que no

99
puede haber lectores con el mismo serial y permitir al usuario dar inicio
nuevamente al caso de uso.

Flujo de eventos alternativos
El usuario puede cancelar el proceso en cualquier momento con la
opcin cancelar.
En caso de que el usuario entre un dato errneo, lo podr corregir antes
de grabar el registro o despus.
No todos los campos que se piden en la pantalla de captura de
informacin, son obligatorios, si no se ingresan en el sistema,
posteriormente se podr hacer.

4.2.2 Caso de uso: CONSULTA DE LECTORES
Tipo: secundario.
Actor: Usuario limitado, Administrador.
Descripcin: proceso en el cual se consulta de la base de datos por medio
de la referencia del lector, todo su registro completo.

el caso de uso inicia cuando el usuario da clic en el icono Consulta de la
pantalla de captura de Lectores, en la que se muestran los mismos
campos de la matrcula de lectores, podr hacer otra consulta o salir si
as lo desea el usuario.

100
4.2.3 Caso de uso: MODIFICAR LECTORES
Tipo: primario
Descripcin: proceso en el cual se modifica la informacin ingresada para
la matrcula de lectores.

El caso de uso comienza cuando el usuario se encuentra en la ventana
de captura de la informacin bsica del los lectores, all da clic en el
icono modificar, e inmediatamente puede escribir en todos los campos
nuevamente, excepto en el campo nmero de serial del lector, ya que si
este se modifica es porque sera un nuevo lector.
Luego de digitar los datos a corregir, se contina con el proceso normal
de la matrcula del lector con relacin a grabar o no, la informacin.

4.2.4 Caso de uso: CONFIGURACIN DE LECTORES
Tipo: Primario.
Descripcin: Este proceso se encarga de configurar el lector para poder
trabajar con l, pero en red.

Este caso de uso comienza cuando el usuario da clic en la pestaa de
Configuracin de la pantalla de captura de informacin del Lector,

101
inmediatamente sale una ventana en la que se piden los siguientes
datos:
Direccin de Red, Puerto, Tasa de Transferencia, indicador de freeplay y
en este caso especificar el tiempo inicial (fecha y hora) y tiempo final
(fecha y hora) de este evento. Esto se graba directamente en la base de
datos y en la memoria del lector. Una vez se hayan entrado todos estos
datos se procede a grabar o no.

El usuario podr cancelar la digitacin de esta informacin en el
momento que desee, con la opcin cancelar.

4.2.5 Caso de uso: CONSULTA DE CONFIGURACION DE LECTORES
Tipo: Primario.
Descripcin: este proceso se encargar de consultar la informacin
registrada en la memoria del lector de la cual hay una copia en la base de
datos.

Este caso de uso inicia cuando se da clic en el icono Consulta de la
pantalla de captura de Configuracin de Lectores, traer toda la
informacin, una vez se haga esto se podr repetir el proceso cuantas
veces se desee.

102

4.2.6 Caso de uso: MODIFICACIN DE LA CONFIGURACIN DE LECTORES
Tipo: Primario.
Descripcin: este proceso se encargar de modificar la informacin
registrada en la memoria del lector y en la base de datos.

Este caso de uso inicia cuando se da clic en el icono Modificar de la
pantalla de captura de Configuracin de Lectores, una vez se haga esto
se podr entrar la informacin a corregir y se grabar nuevamente en la
memoria del lector y en la base de datos, si as se desea.

103
4.3. DIAGRAMA DE CASOS DE USO

Ilustracin 6 - Lectores Diagrama de Casos de Uso

104
4.4. DICCIONARIO DE DATOS

4.4.1 Tabla: LECTOR
Almacena la informacin bsica de los lectores que posee la empresa en el
parque de diversin. Como es el nmero serial, detalle, marca, modelo, si
est activo o no y la fecha de ingreso.

LECTOR
PK Nro_serial Alfanumrico(15)
Detalle Alfanumrico(50)
Marca Alfanumrico(50)
Modelo Alfanumrico(50)
Activo Booleano
Fecha_ingreso Fecha/Hora
Crear ( )
Consultar ( )
Modificar ( )

Tabla 2 - Lectores Lectores del Parque

105
4.4.2 Tabla: CF_LECTOR:
Almacena la informacin correspondiente a la configuracin de los lectores
que se encuentran instalados en cada atraccin. Como es Nro. Del serial,
direccin de la red, puerto por el que se comunicar, hora y fecha en que
se registra un turno.

CF_LECTOR
FK Nro_serial Alfanumrico(15)
Dir_red Nmero
Puerto Alfanumrico(15)
Tasa_transferencia Nmero
Freeplay Booleno
Hora_inicial Fecha/Hora
Hora_final Fecha/Hora
Fecha_inicial Fecha/Hora
Fecha_final Fecha/Hora
Crear ( )
Consultar ( )
Modificar ( )

Tabla 3 - Lectores Configuracin de Lectores

106
4.5. RELACIONES

Ilustracin 7 - Lectores Relaciones

107
4.6. REPORTES GENERADOS

Ilustracin 8 - Lectores Listado de Lectores

Ilustracin 9 - Lectores Listado de Lectores por Atraccin

108

5. MODULO ATRACCIONES

5.1. OBJETIVOS
Matricular atracciones.
Asignacin de lectores de atraccin

5.2. CASOS DE USO

5.2.1 Caso de uso: MATRICULA DE ATRACCIONES
Tipo: Primario
Descripcin: En este proceso se ingresarn las mquinas que lleguen
nuevas al parque de diversin.

Este caso de uso comienza cuando el usuario da clic en la opcin
Atracciones que aparece en el men principal REGISTROS, se muestra
una ventana de captura de informacin Y cuando se da clic en el icono
Nuevo, se piden los siguientes campos: nmero serial de la atraccin,
descripcin, Cdigo de lnea, nmero del serial del lector, Valor del
Turno, Ubicacin, Duracin del turno, Observaciones, Activo, Fecha de
ingreso. Se podrn guardar o cancelar cuando se desee.

109
5.2.2 Caso de uso: CONSULTA DE ATRACCIONES
Tipo: Secundario.
Descripcin: En este proceso se consultar la informacin que se registr
en el ingreso de las mquinas.

Este caso de uso comienza cuando el usuario da clic en el icono
Consulta que aparece en la pantalla de captura de la Matrcula de
Mquinas, aparecer toda la informacin correspondiente, Se podr
repetir este proceso cuantas veces se desee.

5.2.3 Caso de uso: MODIFICACIN DE ATRACCIONES
Tipo: Secundario
Descripcin: En este proceso se modificar la informacin que se registr
en el ingreso de las mquinas.

Modificar que aparece en la pantalla de captura de la Matrcula de
Mquinas, en la que se piden los mismos campos del ingreso inicial
excepto el nmero serial de la atraccin, Se podrn guardar o cancelar
los cambios realizados.

110

Ilustracin 10 - Atracciones Diagrama de Casos de Uso

111
4.4. DIAGRAMA DE ESTADOS

Ilustracin 11 - Uso de una atraccin por un cliente Diagrama de Estados


Tabla: ATRACCIN:
Almacena la informacin bsica de las atracciones, es su hoja de vida al
ingreso al parque de atraccin. Como es el nmero serial de la atraccin,
descripcin, el lector que tendr asignado, lnea a la que pertenece, fecha
de ingreso, si esta activa o no, entre otros.

112

ATRACCION
PK Nro_serial_atraccion Alfanumrico(15)
Descripcion Alfanumrico(50)
FK Cod_linea Alfanumrico(10)
Ubicacin Alfanumrico(50)
Observacion Memo
Imagen Archivo_adjunto
Fecha_ingreso Fecha/Hora
Activo Booleano
T_turno Nmero
Valor_Turno Nmero
Crear ( )
Consultar ( )
Modificar ( )

Tabla 4 - Atracciones Informacin Bsica de Atracciones

113
4.6. RELACIONES

Ilustracin 12 - Atracciones - Relaciones

114

Ilustracin 13 - Atracciones Listado de Atracciones

Ilustracin 14 - Atracciones Listado de Atraccin por Lector

115

6. MODULO POS (PUNTO DE VENTA)

6.1. OBJETIVOS
Matrcula del pos.
Venta de Tarjetas
Consulta de ventas.
Consulta de saldo de tarjetas.

6.2. CASOS DE USO

6.2.1 Caso de uso: MATRICULA DE POS (PUNTO DE VENTA)
Tipo: Primario
Actor: Usuario limitado, Admini strador.
Descripcin: En este proceso se ingresar la informacin correspondiente
a un POS.

Este caso de uso comienza cuando el usuario da clic en la opcin Pos
del men principal REGISTROS, en la que se piden los siguientes
campos: Cdigo del Pos, Descripcin, Ubicacin, nmero serial del
lector asignado, Activo. Se podrn guardar o no la informacin
ingresada.

116

6.2.2 Caso de uso: CONSULTAR POS (PUNTO DE VENTA)
Tipo: Secundario.
Descripcin: En este proceso se consultar la informacin correspondiente
a un POS.

Consulta de la pantalla de captura de Matrcula de Pos, en la que se
muestran todas las caractersticas de un punto de venta. Se podr hacer
esta consulta cuantas veces se desee.

6.2.3 Caso de uso: MODIFICAR POS (PUNTO DE VENTA)
Tipo: Secundario.
Descripcin: En este proceso se modificar la informacin correspondiente
a un POS.

Modificar de la pantalla de captura de Matrcula de Pos, en la que se
muestran todas las caractersticas de un punto de venta. Una vez se
haya ingresado la informacin a corregir se podr grabar o no, y esto se
podr hacer esta consulta cuantas veces se desee.

117
6.2.4 Caso de uso: APERTURA DE CAJA
Tipo: Primario.
Descripcin: En este proceso se ingresar al pos la base de dinero con la
que se va a iniciar el turno en el punto de venta.

Este caso de uso comienza cuando el usuario da clic en la opcin Punto
de Venta del men principal OPERACIONES, aparece una pantalla de
captura en la que se entra la base de dinero con la que se inicia el turno
en el punto de venta, luego se da aceptar y entra a la pantalla del punto
de venta.

El usuario podr dar clic en el botn cancelar para no iniciar el turno.

6.2.5 Caso de uso: CORTE DE CAJA
Tipo: Primario.
Descripcin: En este proceso se finalizar el turno en el punto de venta y
se cuadra la caja registradora.

Este caso de uso comienza cuando el usuario da clic en el icono Corte
x de la pantalla principal del punto de venta, aparece una pantalla de

118
captura de informacin en la que aparece valor de caja que hace el
sistema, es decir, muestra cuando dinero en efectivo debe de haber y
hay un campo para entrar el dato manual de lo que se cont fsicamente
en dinero efectivo y si hay o no diferencia en la pantalla aparecer este
valor, luego se podr aceptar o no, dicho corte.

El usuario podr dar clic en el botn cancelar para no finalizar el turno.

6.2.6 Caso de uso: EXPULSAR TARJETA DEL LECTOR
Tipo: Primario.
Descripcin: En este proceso se expulsa de una manera manual la tarjeta
del lector.

Expulsar de la pantalla principal del punto de venta, este procedimiento
se hace en el caso de que la tarjeta no sea devuelta por el lector
automticamente.

6.2.7 Caso de uso: VENTA DE TARJETAS
Tipo: Primario
Actor: Promotor de venta, Lector, Tarjeta.

119
Descripcin: Este proceso se encargar de vender los tarjetas para hacer
uso de las atracciones: cargar (cash) en las tarjetas que un cliente desee
comprar.

Este caso de uso comienza cuando el usuario ingresa a la opcin del
men principal OPERACIONES y da clic en la opcin Punto de Venta,
inmediatamente sale una ventana en la cual debe dar clic en el icono
Nuevo, una vez lo haga se podr entrar el valor de la tarjeta a cargar,
luego se finaliza la venta cuando el cliente haya cancelado la totalidad
de la misma. se podr hacer una nueva venta de tarjeta si se desea.

El usuario podr cancelar una factura de venta con el icono cancelar, o
tambin podr salir del pos.

6.2.8 Caso de uso: CONSULTA DE VENTAS
Tipo: Primario
Actor: Promotor de venta, Usuario Limitado, Administrador.
Descripcin: En este proceso se podr consultar las ventas realizadas por
el promotor del punto de venta hasta el momento en el que hizo la ultima
factura de venta.

consulta de la pantalla de captura del punto de venta, aparecer en

120
pantalla una ventana con la informacin del usuario que est en turno,
las facturas de venta realizadas, el nmero de tarjetas vendidas y el total
en dinero, para salirse de all dar un clic en el botn aceptar.


6.2.9 Caso de uso: DEVOLUCIN DE VENTAS
Tipo: Primario
Actor: Promotor de venta, Usuario Limitado, Administrador.
Descripcin: En este proceso se podr hacer la devolucin de una factura.

Este caso de uso comienza cuando la promotor de venta se da cuenta
de que cometi un error en la factura que acaba de diligenciar o porque
algn cliente hace esta devolucin por cualquier motivo, entonces da clic
en el icono Devolucin de la pantalla de captura de informacin de
ventas. Cuando esto termina se puede salir de la ventana con la opcin
cancelar, una vez haya hecho la devolucin.

El usuario podr salir de la ventana de ejecucin dando clic en la opcin
cancelar.

6.2.10 Caso de uso: CONSULTA DE CARGA DE TARJETAS
Tipo: Primario

121
Actor: Promotor de venta, Lector, Tarjeta.
Descripcin: En este proceso se podr consultar la carga realizada a las
tarjetas magnticas.

Este caso de uso comienza cuando el usuario da clid en el icono
Consultar, de la pantalla principal del punto de venta.

122

Ilustracin 15 - Pos (Punto de Venta) Diagrama de Casos de Uso

123

6.4.1 Tabla: POS
Almacena la informacin bsica de los puntos de venta (POS), que posee el
parque de atraccin. Como es su ubicacin, el lector que tiene instalado, si est
activo o no, entre otros.
POS
PK Cod_pos Alfanumrico(15)
Descripcion Alfanumrico(50)
Ubicacin Alfanumrico(50)
Activo Booleano
Crear ( )
Consultar ( )
Modificar ( )
Tabla 5 - Pos - Punto de Venta

6.4.2 Tabla: FACTURA:
Almacena la informacin correspondiente a las facturas de venta registradas en el
Pos. Guardar el nmero de factura, el pos donde se realiza, el usuario de venta
que la ejecuta.

124

FACTURA
PK Nro_factura Nmero
NroTurno Nmero
FK Cod_pos Alfanumrico(15)
Cod_usuario Alfanumrico(15)
Fecha_venta Fecha/Hora
Hora Hora
Serial_tarjeta Alfanumrico(15)
Valor_carga Nmero
Total_venta Nmero
Crear ( )
Consultar ( )
Tabla 6 - Pos Factura.

6.4.3 Tabla: TURNO:
Almacena la informacin correspondiente a los turno durante todo un da de
servicio en el pos, guardando el nmero de turno, el nombre del usuario, tambin
se guardan los datos de un corte en el queda registrado el cuadre de caja y el
monto contado en efectivo fsicamente, como tambin la fecha y hora de la
transaccin del corte de caja.

125

TURNO
PK NroTurno Nmero
Cajero Alfanumrico(50)
Fecha Fecha/Hora
Hora Fecha/Hora
HoraCorte Fecha/Hora
MontoApertura Nmero
MontoEfectivo Nmero
TotalCaja Nmero
Crear ( )
Consultar ( )
Tabla 7 - Pos - Corte.

126
6.5. RELACIONES

Ilustracin 16 - Pos - Relaciones

127

Ilustracin 17 Pos Ventas de Pos

128

7. MODULO USUARIOS

7.1. OBJETIVOS
Crear grupos de usuarios para autorizar entrar a los diferentes mdulos.
Crear los usuarios y asignar contraseas de seguridad.

7.2. CASOS DE USO

7.2.1 Caso de uso: CREAR USUARIO
Tipo: Primario.
Actor: Usuario Limitado, Administrador.
Descripcin: En este proceso se podr crear los diferentes usuarios del
sistema para garantizar seguridad en su uso.

Este caso de uso inicia cuando el usuario da clic en la opcin Usuarios
del men principal USUARIOS, se ejecuta una ventana en la que va a
pedir la siguiente informacin:
Usuario, clave, nombre, apellido, activo, fecha activacin, fecha
expiracin, descripcin y nombre de grupo, el supervisor una vez haga
esto podr guardar o no con las opciones icono respectivamente.

129

El usuario podr salir de esta ejecucin dando clic sobre la opcin
cancelar.
Si el campo clave y confirmacin de clave son diferentes el sistema no le
permitir grabar hasta que ingrese en ambos campos la misma clave.

7.2.2 Caso de uso: MODIFICAR USUARIO
Tipo: Primario
Actor: Usuario Limitado, Administrador.
Descripcin: En este proceso se podr modificar la informacin ingresada
en la ventana de creacin de usuarios.

Este caso de uso comienza cuando el usuario en la ventana principal de
la creacin de usuario da clic en el icono modificar, pudiendo entrar
nuevamente a todos los campos excepto el del nombre del usuario
porque de ser as sera un nuevo usuario el que ingresara, una vez
haya modificado los campos disponibles podr grabar o no con las
opciones respectivas.

El usuario podr salir de esta ejecucin cuando lo desee con la opcin
salir o cancelar que tendr la ventana.

130

Ilustracin 18 - Usuarios Diagrama de Casos de Uso


7.4.1 Tabla: Usuario:
Almacena la informacin correspondiente a los usuarios que podrn usar la
aplicacin, como es su nombre de usuario, clave, fecha de activacin y
fecha de expiracin.

131

USUARIO
PK Usuario Alfanumrico (30)
Clave Alfanumrico (10)
Nombre Alfanumrico (30)
Apellido Alfanumrico (30)
Activo Booleano
Fecha_act Date
Fecha_exp Date
Descripcion Memo
NombreGrupo Alfanumrico (30)
Crear ( )
Consultar ( )
Modificar ( )
Tabla 8 - Usuario Usuarios de la Aplicacin

132
7.5. RELACIONES

Ilustracin 19 - Usuarios - Relaciones

133

8. MODULO ADMINISTRATIVO

8.1. OBJETIVOS
Ingresar informacin de la empresa.
Creacin de archivos maestros.
Informacin de tarjetas freeplay.
Informacin sobre reportes.
Informacin sobre la red.
Captura de datos del lector.

8.2. CASOS DE USO

8.2.1 Caso de Uso: Registro de la Empresa
Tipo: Primario.
Actor: Usuario limitado y administrador.
Descripcin: En este proceso se podr registrar la informacin
correspondiente a la empresa en cuanto a su nit, razn social, ubicacin,
entre otros.

134
Este caso de uso comienza cuando el usuario entra a la opcin del
men principal ARCHIVO y da clic en la opcin Empresa, una vez haga
esto aparece una pantalla de captura de informacin en la que se va a
pedir los siguientes datos: razn social, nit, direccin, telfono, fax. Una
vez haya entrado esta informacin podr grabar o cancelar con los
botones asignados para estas tareas respectivamente.

El usuario podr salir de esta ventana en el momento que lo desee
dando clic en la opcin asignada a esta tarea.

8.2.2 Caso de Uso: Matrcula de Lneas
Tipo: Primario.
Actor: Usuario limitado, administrador.
Descripcin: En este proceso se podrn registrar las lneas en las que la
empresa clasifica sus atracciones.

Este caso de uso comienza cuando el usuario entra a la opcin del
men principal ARCHIVO en Maestros y da clic en la opcin Lneas, se
ejecuta una ventana en la que pide la siguiente informacin: Cdigo de
Lnea y Descripcin. Luego podr guardar o no la informacin ingresada.

135
El usuario podr salir de la ventana de captura de informacin cuando lo
desee, dando clic en el icono cancelar.
Si el usuario ingresa un cdigo ya existente, el sistema no le permitir
grabar.

8.2.3 Caso de Uso: Modificacin de Lneas
Tipo: Primario.
Descripcin: En este proceso se podrn modificar la informacin de las
lneas registradas.

modificar de la pantalla principal de el registro de lneas, se ejecuta una
ventana en la que muestra la informacin registrada y la cual podr
cambiar o no, por medio de los iconos para guardar o cancelar.

El usuario podr salir de la ventana de modificacin de informacin
cuando lo desee, dando clic en el icono cancelar.
Si el usuario ingresa un cdigo no existente, el sistema le dar aviso de
este evento.

136
8.2.4 Caso de Uso: Ventas de Atraccin
Tipo: Primario.
Descripcin: En este proceso se podr simular la utilizacin de una tarjeta
magntica en una atraccin.

Este caso de uso comienza cuando el usuario da clic en la opcin Venta
de Atracciones, del men principal OPERACIONES, aparece una
pantalla en la cual se selecciona la atraccin en la cual quiere jugar y
hacer uso de ella como si fuera real. Una vez se haga esta operacin se
da clic en el botn juego y se introduce la tarjeta, en la cual se debitara
el valor de la atraccin que escogi. Luego podr volver a iniciar el caso
de uso jugando en otra atraccin si as se desea, sino podr salir con el
botn Salir.

El usuario podr salir de la ventana de modificacin de informacin
cuando lo desee, dando clic en el icono cancelar.
Si el usuario inserta una tarjeta que no tiene saldo suficiente para hacer
uso de la atraccin, el sistema le dar aviso y podr intentarlos
nuevamente, cambiando ya sea de atraccin o de tarjeta.

137

Ilustracin 20 - Administrativo Diagrama de Casos de Uso


8.4.1 Tabla: EMPRESA
Almacena la informacin bsica de la empresa, como es la razn social, nit,
direccin, departamento, municipio, ubicacin, telfono, fax, direccin, e-mail,
website.

138

EMPRESA
PK RazonSocial Alfanumerico(50)
Nit Alfanumerico(9)
Dv Alfanumerico(1)
Direccion Alfanumerico(50)
Departamento Alfanumerico(50)
Municipio Alfanumerico(50)
Telefono Alfanumerico(11)
Fax Alfanumerico(11)
Email Alfanumerico(50)
Website Alfanumerico(50)
Logotipo Imagen
Crear ( )
Consultar ( )
Modificar ( )
Tabla 9 - Administrativo Empresa.

8.4.2 Tabla: VENTASXATRACCION:
Almacena la informacin correspondiente a las ventas de las atracciones con su
respectiva fecha y hora.

139

VTAXATRACCION
PK Consecutivo Nmero
Cod_atraccion Alfanumrico(15)
Fecha_venta Fecha/Hora
Hora_venta Fecha/Hora
Valor_venta Nmero
Serial_tarjeta Alfanumrico(15)
Crear ( )
Consultar ( )
Tabla 10 - Administrativo Ventas por Atraccin.

8.4.3 Tabla: LNEA:
Almacena las diferentes lneas que tiene la empresa para clasificar a sus
atracciones.
LINEA
PK Cod_linea alfanumerico(10)
Descripcion alfanumerico(50)
Activo Booleano
Crear ( )
Consultar ( )
Modificar ( )
Tabla 11 - Administrativo Lnea.

140
8.5. RELACIONES

Ilustracin 21 - Administrativo - Relaciones

141

Ilustracin 22 - Administrativo Ventas por Atraccin

142

Ilustracin 23 Administrativo Ventas por Lnea

143

9. DISEO GENERAL

9.1. OBJETIVOS
Servir de interface para la conexin de la base de datos.
Acceder de manera segura a las utilidades del sistema.

9.2. CASOS DE USO

9.2.1 Caso de Uso: Conectar base de datos
Tipo: Primario
Actor: Administrador.
Descripcin: en este proceso se lleva a cabo la conexin del sistema a la
base de datos.

Flujo de Eventos Principal
el caso de uso comienza cuando el usuario abre la aplicacin de
Windows OBDC (Orgenes de Datos), el usuario debe agregar una
conexin al proveedor de datos a travs del botn agregar. El usuario
selecciona el controlador de la base de datos de Microsoft Acces
(*.mdb) y da clic en el botn finalizar. El usuario ingresa como nombre
del origen de datos Divertronica y da clic en el botn seleccionar. El
usuario busca en la red el origen de la base de datos la cual tiene por

144
nombre diveradmin.mdb y da clic en el botn aceptar. Se guarda en el
registro de Windows el DNS de la base de datos. El usuario cierra la
ventana de administrador de orgenes de datos ODBC.


Ilustracin 24 - Principal Diagrama de Casos de Uso

145
3.7. DIAGRAMA DE ACTIVIDADES

Ilustracin 25 Diagrama de Actividades

146
9.4. DIAGRAMA DE COMPONENTES

Ilustracin 26 Diagrama de Componentes

147

ANEXOS

148

ANEXO II

149

ANEXO II

150

ANEXO III

151

MANUAL DEL USUARIO

152
1. CONFIGURACIN INICIAL DEL SISTEMA

Ingresar la configuracin de la base de datos por el ODBC (orgenes de datos),
que se encuentra en: Panel de Control, Herramientas administrativas.

Cree una nueva conexin dando clic en el botn agregar de la etiqueta DSN de
usuario.

Seleccione como controlador de la base de datos a Microsoft Access Driver
(*.mdb) y de clic en el botn finalizar.

153

Como nombre del origen de datos Sistema y de clic en el botn seleccionar.

154

Busque en el origen de la base de datos la cual tiene por nombre sistema.mdb y
de clic en el botn aceptar.

De clic en el botn aceptar para guardar los cambios.
El regresa a la ventana de la lista de controladores deber aparecer la nueva
conexin.

155

Cierre la ventana dando clic en el botn aceptar.

2. REQUERIMIENTOS DEL SISTEMA

Los requerimientos mnimos del computador son:
Sistema operativo: Windows 9x, Windows Nt o superiores.
Procesador Pentium I o superior.
Memoria ram mnima 64 Mb.
Resolucin de la pantalla 800 x 600 o superior.

156
4. CARACTERSTICAS

La aplicacin est formada por un men principal de 5 opciones:

Archivo: en esta opcin se manejar los datos bsicos de la
empresa y los archivos maestros del sistema.
Registros: en esta opcin se manejar los datos bsicos de los
lectores, atracciones y pos. (esta ltima opcin de pos estar habilitada
en un futuro).
Operaciones: en esta opcin se manejar las operaciones del punto de
venta y las ventas de atracciones.
Usuarios: en esta opcin se registrarn los usuarios que tendrn
permisos para usar la aplicacin. (esta opcin estar habilitada en un
futuro).

157
Reportes: en esta opcin se manejarn lo diferentes reportes que
puede arrojar la aplicacin con respecto a Lectores, Atracciones, Ventas
y Punto de venta.

Definicin de algunos iconos que se utilizarn en algunas pantallas de
captura de informacin:
(NUEVO) Este icono se utilizar para ingresar nuevos registros, al dar clic
en l, se podr ingresar el registro con todos sus campos.
(MODIFICAR) Este icono se utilizar cuando en pantalla se tenga
informacin de un registro consultado y dando clic en l, se podr modificar la
informacin.
(GUARDAR) Este icono se utilizar para guardar la informacin del registro
que ya se haya ingresado, como nuevo o guardar la modificacin de uno.
(CANCELAR) Este icono se utilizar para cancelar cualquier accin de la
pantalla, como nuevo, consultar, modificar.
(CONSULTAR) Este icono se utilizar para buscar informacin que se
encuentre en la base de datos.
(SALIR) Este icono se utilizar para salir de la pantalla que en ese momento
se encuentre activa.

158
Men Archivo:

Esta opcin de men principal tendr las siguientes opciones:
Empresa: donde se podrn entrar los datos bsicos de la empresa.
Una vez se hayan entrado todos los datos el usuario podr grabar o
no, con los botones de aceptar o cancelar respectivamente.

Maestros: donde se podrn entrar los datos correspondientes a las
lneas que maneja la empresa para la clasificacin de las
atracciones.

159

Estando en esta pantalla de captura el usuario podr ingresar una nueva lnea
dando primero clic en el i cono Nuevo, el cursor se ubicar en el campo cdigo de
lnea donde se podr hacer la digitacin. Una vez haya entrado la informacin
podr grabar con el icono guardar, si el usuario desea guardar pero el cdigo de
lnea ya existe el sistema no le permitir hacerlo y le sacar el siguiente mensaje.

160
Dando clic en aceptar se ubicar el cursor inmediatamente en el campo cdigo de
lnea.

Si el usuario desea consultar un registro, lo podr hacer dando clic en el icono
Consultar, siempre y cuando primero haya entrado el cdigo de lnea de registro
que desea consultar. Si se digita un cdigo que no existe saldr el siguiente
mensaje.

Dando clic en aceptar el cursor se ubicar en el campo de cdigo de lnea para
que digite nuevamente.
Cuando el usuario este entrando un nuevo registro, consultando y modificando,
podr cancelar la tarea en el momento que lo desee dando clic en el icono
Cancelar.
Si el usuario desea salir de la pantalla de captura de informacin lo podr hacer
dando clic en el icono Salir.

Salir: donde se podr salir de la aplicacin.

161
Men Registros:

Esta opcin de men principal tendr las siguientes opciones:
Lectores: donde se podrn registrar los datos bsicos de los lectores
cuando llegan por primera vez al parque de diversin o para
consultar y modificar informacin de registros que ya se encuentren
en la base de datos.

162

Estando en esta pantalla de captura el usuario podr ingresar un nuevo lector
dando primero clic en el icono Nuevo, el cursor se ubicar en el campo Nro. Serial
donde se podr hacer la digitacin. Una vez haya entrado la informacin podr
grabar con el icono Guardar, si el usuario desea guardar pero el nmero serial ya
existe el sistema no le permitir hacerlo y le sacar el siguiente mensaje.

Dando clic en aceptar se ubicar el cursor inmediatamente en el campo nmero
de serial.

Consultar, siempre y cuando primero haya entrado el nmero serial del registro

163
que desea consultar. Si se digita un serial que no existe saldr el siguiente
mensaje.

Dando clic en aceptar el cursor se ubicar en el campo de nmero de serial para
Cancelar.
La informacin que aparece en la pestaa de Configuracin, no estar habilitada,
en un futuro cuando el sistema trabaje en red se habilitar.

Atracciones: donde se podrn registrar los datos bsicos de las
atracciones cuando llegan por primera vez al parque de diversin o
para consultar y modificar informacin de registros que ya se
encuentren en la base de datos.

164

Estando en esta pantalla de captura el usuario podr ingresar una nueva Atraccin
dando primero clic en el icono Nuevo, el cursor se ubicar en el campo Nro. Serial
donde se podr hacer la digitacin. Una vez haya entrado la informacin podr
grabar con el icono Guardar, si el usuario desea guardar pero el nmero serial ya
existe el sistema no le permitir hacerlo y le sacar el siguiente mensaje.

Dando clic en aceptar se ubicar el cursor inmediatamente en el campo nmero
de serial.

165

Consultar, siempre y cuando primero haya entrado el nmero serial del registro
que desea consultar. Si se digita un serial que no existe saldr el siguiente
mensaje.

Dando clic en aceptar el cursor se ubicar en el campo de nmero de serial para
Cancelar.

Pos: donde se podrn registrar los datos bsicos de los puntos de
ventas cuando se crean dentro del parque la primera vez o cuando
cambian de ubicacin. (esta opcin se habilitar en un futuro cuando
en el parque hayan varios puntos de venta.)

166
Men Operaciones:

Esta opcin del men principal tendr las siguientes opciones:
Punto de venta: donde se podr hacer ventas de tarjetas.

Definicin de los iconos que se utilizarn en esta pantalla de Punto de Venta:
Este icono del subgrupo de Operaciones, se utilizar para consultar
de una manera general las facturas de venta que se han hecho en el turno actual.

167
Este icono del subgrupo de Operaciones, se utilizar para hacer un
corte de caja cuando se va a finalizar un turno de algn promotor de venta.

Cuando aparece esta pantalla el sistema traer en total caja el valor del efectivo
que debe de haber en la caja registradora y el promotor de venta tendr que entrar
un dato en monto efectivo que corresponde al efectivo en dinero que l cont de la
caja registradora el cual debe de ser igual al dato que dio el tota caja, de no ser
as hay un descuadre a favor o en contra del promotor de venta.

Este icono del subgrupo de Tarjetas, se utilizar para hacer una venta de
tarjeta.

168

Con esta opcin el cursor se ubicar inmediatamente en el campo Valor, para
entrar el valor de la carga a la tarjeta que decidi comprar el cliente.

Este icono del subgrupo Tarjetas, se utilizar para consultar el valor
de carga que tiene una tarjeta.

169

Cuando se le da clic en el icono consultar aparece un botn debajo Cancelar, por
si se arrepiente de consultar el saldo de la tarjeta, de lo contrario aparecer en el
campo Serial, el nmero del cdigo de barras que trae la tarjeta magntica, y en el
campo Valor, aparecer la carga actual de la tarjeta. Despus de esto podr hacer
otra consulta si as se desea

Este icono del subgrupo Tarjetas, se utilizar para expulsar la tarjeta del
lector de una manera manual.
Este icono del subgrupo Pos, se utilizar para finalizar una factura de
venta.

170
Este icono del subgrupo Pos, se utilizar cuando se desea cancelar una
factura de venta, es decir, para no continuar con el proceso de finalizacin de una
venta, al darle clic se limpian los campos que aparecen en pantalla con alguna
informacin.
(ACEPTAR) Este botn se utilizar para terminar una factura de venta y cargar el
valor de la misma en la tarjeta de banda magntica y posteriormente guardar la
venta, cuando se de clic en este botn se debe de ingresar la tarjeta
inmediatamente para que se haga la grabacin en ella.

En esta opcin de punto de venta lo primero que se hace es una apertura de caja.

All se digita el monto efectivo con el que se va a iniciar el turno de venta y luego
se da clic en el botn Aceptar o en cancelar para no iniciar la sesin.
Luego aparece la pantalla del pos.

Ventas de Atraccin: donde se podr hacer un registro de ventas
en la atraccin que se seleccione

171

Cuando se active esta pantalla el usuario podr escoger la atraccin en
la cual desea hacer la simulacin del juego, una vez escoja la atraccin
aparecer el valor del turno de la atraccin en pantalla, y se activar el
botn Juego, luego de darle clic inmediatamente tendr que insertar la
tarjeta en el lector, para que el sistema verifique si tiene saldo suficiente
para hacer uso de la atraccin y en caso contrario saldr el siguientes
mensaje.

Al dar aceptar en este mensaje de alerta el cursor se ubicar en la
opcin de atracciones para escoger otra si lo desea.
Si se tiene en la tarjeta suficiente saldo para jugar en la atraccin, el
sistema debitar automticamente el valor de la atraccin en la tarjeta,
en panta lla hay un campo llamado saldo tarjeta, all aparecer el nuevo

172
valor con el que qued la tarjeta. Luego de esto tambin quedar el
registro de la venta de la atraccin con la fecha y hora.
Tambin en esta pantalla hay un botn expulsar para cuando la tarjeta
se quede en el lector siendo leda, con este botn se obliga al lector a
expulsarla.

Men Usuarios:

Esta opcin del men principal tendr la siguiente opcin:
Usuarios: tendr funcionamiento en un futuro.

Men reportes:
en esta opcin de reportes, todos funcionan de la misma forma: se escoge el
reporte que se desea visualizar y este aparece inmediatamente, todos estos son
informes bsicos del sistema. Estando en los informes en pantalla se podr pasar
de pgina en pgina, se le podr cambiar el tamao de visualizacin, cerrar el
informe con el botn cerrar que traen las pantallas tipo Windows.

173

Esta opcin del men principal tendr las siguientes opciones:
Lectores: donde se podrn ver los diferentes informes de esta
opcin y los cuales se pueden imprimir si as se desea.

o Lectores: en esta opcin podr mirar un listado de todos
lectores que hay registrados en el sistema. Como es el
nmero del serial, la descripcin, si est activo o no, entre
otros.

174

o Lectores por atraccin: en esta opcin podr mirar un listado
de todos los lectores con la atraccin que le corresponde.
mostrar el cdigo del lector, descripcin y el nombre de la
atraccin.

Atracciones: donde se podrn ver los diferentes informes de esta
opcin y los cuales se pueden imprimir si as se desea.

175

o Atracciones: en esta opcin se podr mirar un listado de las
atracciones que hay en el parque de diversin con sus
respectivos campo, como son: cdigo, descripcin, si est
activa o no, fecha de ingreso, entre otros.

o Atraccin por lector: en esta opcin se podr mirar un listado
de las atracciones con sus respectivos lectores asignados.
Mostrar el cdigo de la atraccin, nombre de la atraccin y el
cdigo del lector asignado.

176

Ventas: donde se podrn ver los diferentes informes de esta opcin
y los cuales se pueden imprimir si as se desea.

o Ventas por atraccin: en esta opcin se podr mirar las
ventas generales de ventas por atraccin.

177

o Ventas por lnea: en esta opcin se podr mirar las ventas
por lneas en un rango de fechas. Mostrar una fecha inicial y
final, cdigo de la lnea, descripcin y valor de venta.

178

Punto de Venta: donde se podrn ver los datos que puede ofrecer
un Pos en diferentes formas y los cuales se pueden imprimir si as se
desea.

179

o Ventas de Pos: en esta opcin se podr ver las ventas
hechas por cada punto de venta en un rango de fechas.
Mostrar cdigo del pos, descripcin y la venta.

5. INICIO DE SESION

Esta es la primera ventana que aparece al ejecutar la aplicacin.

180

Se debe de entrar los datos de un usuario ya registrado en el sistema, al ingresar
informacin correcta, esta sesin le permitir entrar a la aplicacin y quedar en la
ventana del men principal.

Si el usuario digita algn dato errneo, saldr el siguiente mensaje de error y le
permitir intentarlo de nuevo.

181

CONCLUSIONES

A travs del desarrollo del proyecto he realizado el anlisis del sistema, logrando
identificar los problemas de informacin en la gestin del parque de diversin
Sandiego y se ha determinado el mejor prototipo de software como primer paso
para solucin completa de todo el sistema.

El prototipo se ha desarrollado con el fin de que en un futuro se implemente
completamente el sistema y no solo en el parque de diversin Sandiego, sino en
muchos otros parques que posee la empresa DIVERTRONICA MEDELLIN S.A.
ya que de esta manera se veran muchos ahorros en costos respecto al recurso
humano involucrado.

Este es un prototipo, de poco nivel de complejidad en su operacin y
administracin, orientado para que las personas encargadas de llevar el registro
de los datos del parque de diversin, no requieran conocimientos tcnicos en el
manejo de las bases de datos e informtica.

182

BIBLIOGRAFA

Libros
1. BOOCH, Grady. RUMBAUGH, James. El Lenguaje Unificado de
Modelado. Libro Introductorio, Editorial Pearson, 1 edicin, Espaa,
1999.
2. PRESSMAN, S. Roger. Ingeniera del Software, Editorial McGraw Hill,
4 Edicin, Espaa, 1998.
3. CEBALLOS, Fco. Javier. Enciclopedia de Visual Basic 4, Editorial Ra-
ma, 1 edicin, Espaa, 1996.
4. de MIGEL, Adoracin et al. Diseo de Bases de datos Relacionales,
RA-MA Editorial, Espaa, 2000.
5. Hernndez Sampieri, Roberto. Metodologa de la Investigacin,
Editorial McGraw Hill, 2. Edicin, Espaa, 1998.
6. SILER, Brian et al. Visual Basic 6 Edicin Especial, Editorial Prentice
Hall, Madrid, 1999.

Direcciones Web
7. La Web del programador.
www.lawebdelprogramador.com
8. Tutorial de Uml
http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html

183
9. Tarjetas de banda magntica.
http://www.fortunecity.es/arcoiris/tarot/572/tar_mag.html.
10. Tarjetas magnticas
http://kalysis.com/content/modules.php?op=modload&name=EasyConte
nt&file=index&menu=32&page_id=192
11. http://www.monografias.com/trabajos21/dispositivos-
almacenamiento/dispositivos-almacenamiento.shtml
12. Tarjeta magntica:
http://es.wikipedia.org/wiki/Tarjetas_magneticas
13. Banda magnetica:
http://es.wikipedia.org/wiki/Banda_magn%C3%A9tica
14. Tarjeta magnetica y chip:
http://www.kimaldi.com/index.php/kimaldi/tarjetas_y_transponders/tarjeta
_magn_tica_y_chip
15. Lectores:
http://www.kimaldi.com/index.php/kimaldi/lectores_de_tarjetas/banda_m
agn_tica/lectores_magn_ticos_de_inserci_n
16. Lectores y tarjetas magneticas
http://www.enttia.com/cast/bandamagnetica.htm
17. Experimentos con tarjetas magneticas:
http://www.fortunecity.es/arcoiris/tarot/572/tar_mag.html
18. Capacidad de las pistas magneticas:
http://www.a3m-esp.com/faq-tarjeta-banda-magnetica.html
19. Banda magnetica:
http://www.idensis.com/tecnologias_banda.html

184
20. Tarjeta magntica:
http://www.ecs.soton.ac.uk/~mv/talks/19990416.pdf
21. Bandas magnticas:
http://www.ent.ohiou.edu/~amable/autoid/tecnologia.html
22. Diseo de sistemas:
http://html.rincondelvago.com/diseno-de-sistemas.html

Tesis de Grado
23. OSPINA C., Oscar Dario et al, sistematizacin de los procesos para la
programacin de turnos de la empresa de seguridad privada vigitecol -
sede medelln, Facultad de Ingeniera de Sistemas, Universidad de
Medelln, 2002

185
GLOSARIO

A

ADO
(Data Access Object) Objeto de acceso a datos.
(ActiveX Data Objetc) Interface de acceso a datos usado para comunicar OLEDB
data souces, como MS SQL Server. Es una Interface a nivel aplicacin que usa
OLEDB, una libreria de Objetos COM que permite el acceso a diversas fuentes de
datos.

Almacenamiento
Bajo este trmino genrico se agrupan dispositivos y software dedicados al
archivo de datos e informacin. Existen diferentes tipos de dispositivos de
almacenamiento: discos, disquetes, discos pticos, cintas, cartuchos, etc. Cada
uno de ellos tiene ventajas e inconvenientes, y resultan ms o menos adecuados
para diferentes utilizaciones. En el caso de la microinformtica, los dispositivos de
almacenamiento ms habituales son los discos duros o fijos, los disquetes o
discos flexibles (de diferentes tamaos estandarizados) y los CDROM, que si bien
no permiten almacenar informacin desde un PC estndar, s facilitan el acceso a
ms de 600 MB de datos fcilmente.

API
(Application Program Interface). Conjunto de convenciones internacionales que
definen cmo debe invocarse una determinada funcin de un programa desde una

186
aplicacin. Cuando se intenta estandarizar una plataforma, se estipulan unos APIs
comunes a los que deben ajustarse todos los desarrolladores de aplicaciones.
Herramientas de programacin para rutinas, protocolos y software.

Aplicacin
Cada uno de los programas que, una vez ejecutados, permiten trabajar con el
computador. Son aplicaciones los procesadores de textos, hojas de clculo, bases
de datos, programas de dibujo, paquetes estadsticos, etc.

Archivar
Grabar en soporte magntico, o en forma digital en el disco duro o en disquetes,
archivos o aplicaciones determinadas.

Archivo
es un conjunto de registros relacionados entre si, guardado de una manera digital
en algn medio de almacenamiento, como es un disco duro, disquetes, entre
otros.

Archivo Ejecutable
Es el archivo que contiene las instrucciones necesarias para que un determinado
programa se ponga en marcha.

187
B

Base de datos
Conjunto de datos relacionados que se almacenan de forma que se pueda
acceder a ellos de manera sencilla, con la posibilidad de relacionarlos, ordenarlos
con base a diferentes criterios, etc. Las bases de datos son uno de los grupos de
aplicaciones de productividad personal ms extendidos. Entre las ms conocidas
pueden citarse dBase, Paradox, Access y Aproach, para entornos PC, y Oracle,
ADABAS, DB/2, Informix o Ingres, para sistemas medios y grandes.

Bit
Es la unidad mnima de informacin digitalmente, puede ser un 1 o un 0.

Byte
Es el conjunto de 8 bits, con los cuales se forman digitalmente las letras o
caracteres especiales.

C

Campo
Es llamado al lugar donde se digitan datos, y estos a su vez forman un registro.

Casos de uso
Un caso de uso es una secuencia de transacciones que son desarrolladas por un
sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los

188
diagramas de casos de uso sirven para especificar la funcionalidad y el
comportamiento de un sistema mediante su interaccin con los usuarios y/o otros
sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores
y los casos de uso en un sistema. Una relacin es una conexin entre los
elementos del modelo, por ejemplo la relacin y la generalizacin son relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del
sistema al mostrar como reacciona una respuesta a eventos que se producen en
el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un
actor es una entidad externa al sistema que se modela y que puede interactuar
con l; un ejemplo de actor podra ser un usuario o cualquier otro sistema.

Clave de Acceso
Una clave de acceso es una combinacin de letras, nmeros y signos que debe
teclearse para obtener acceso a un programa o partes de un programa
determinado, un terminal u computador personal, un punto en la red, etc. Muchas
veces se utiliza la terminologa inglesa (password) para referirse a la clave de
acceso. Entre las recomendaciones ms habituales a la hora de elegir una clave
de acceso, est el no utilizar nombres pertenecientes a familiares o amigos,
fechas concretas (nacimiento, aniversario), nombres de mascotas, o palabras con
significado (clave, acceso, etc.). Los expertos aconsejan utilizar una combinacin
de letras, nmeros y signos (h+gy7/6t, por ejemplo) que debe cambiarse con
relativa frecuencia.
Cliente
Cualquier persona que visita un parque de diversin de la empresa
para hacer uso de los servicios que esta ofrece.
Tambin se le llama a la persona o empresa que contrata un servicio
de desarrollo de software.

189
Compatibilidad
Caracterstica que presentan dos sistemas informticos que pueden funcionar
conjuntamente de manera correcta. El mejor ejemplo de la compatibilidad es la de
los PCs, que pueden conectarse perfectamente y que permiten el intercambio de
informacin a travs de las aplicaciones que corren en ellos sin problemas. La
compatibilidad es uno de los objetivos actuales de la mayora de los fabricantes de
computadores.

Configurar
Adaptar una aplicacin software o un elemento hardware al resto de los elementos
del entorno y a las necesidades especficas del usuario. Es una tarea esencial
antes de trabajar con cualquier nuevo elemento. La tendencia actual es a reducir
las necesidades de configuracin mediante sistemas que permiten al nuevo
elemento detectar en qu entorno se instala, configurndose automticamente sin
requerir la participacin del usuario. Cuando sta es necesaria, se intenta facilitar
al mximo el proceso de configuracin.

D

Datos
Los datos son hechos y cifras en bruto, tales como rdenes y pagos, los
cuales se procesan para obtener informacin, por ejemplo el saldo deudor y
el monto disponible. Sin embargo, en el uso comn, los trminos datos e
informacin se toman como sinnimos.
Es la unidad mnima de informacin, un dato por si solo no es nada.

190
Cualquier forma de informacin, ya sea en forma electrnica o sobre papel.
En forma electrnica, "datos" se refiere a archivos, bases de datos,
documentos de texto, imgenes y, voz y video codificados en forma digital.

Diagrama de flujo
Representacin grfica, mediante la utilizacin de signos convencionales,
del proceso que sigue la informacin en un programa determinado. Se
utilizan habitualmente en la fase de desarrollo de aplicaciones por los
programadores.

Diccionario de Datos
Almacn central de informacin utilizado por las empresas al que acceden todas
las aplicaciones operativas de la organizacin

Diseo
Proceso de esquematizacin de un proyecto de software. Es la primera fase en el
desarrollo de aplicaciones.

Documentacin
Bajo este trmino genrico se agrupan todos los manuales, guas de referencia,
libros de ayuda, etc., que suelen entregarse con cada programa, de manera que el
usuario pueda aprender su manejo y consultar cualquier duda ante un problema
desconocido.

191

E

Entorno
Es otra de las denominaciones que se utilizan para definir el sistema operativo en
el que se trabaja.
Los sistemas operativos DOS o UNIX son entornos basados en texto, mientras
que Windows, OS2 o MacOS son entornos grficos.
Linux es un entorno basado en texto, aunque en las distribuciones actuales
existen entornos grficos para el mismo.

F

Fiabilidad
Caracterstica de los sistemas informticos por la que se mide el tiempo de
funcionamiento sin fallos. En el caso del hardware, se han conseguido altsimos
grados de fiabilidad, mientras que en el software siguen existiendo bugs que
dificultan el buen funcionamiento de los programas. Cuando uno de estos bugs
aparece, es normal que el programa se quede colgado, impidiendo al operador
seguir trabajando con el sistema y obligando a reiniciar la mquina.

Funcin
En programacin, una rutina de software independiente que realiza una tarea para
el programa en que est escrita o para algn otro programa. La funcin ejecuta la
operacin y devuelve el control a la instruccin siguiente a la que la llam o al
programa que la llam. Los lenguajes de programacin proveen un conjunto de

192
funciones estndares y permiten a los programadores definir otras. Por ejemplo, el
lenguaje C est completamente construido alrededor de funciones.

H

Hardware
Conjunto de componentes materiales de un sistema informtico. Cada una
de las partes fsicas que forman un computador, incluidos sus perifricos.
Maquinaria y equipos (CPU, discos, cintas, modem, cables, etc.). En
operacin, un computador es tanto hardware como software. Uno es intil
sin el otro. El diseo del hardware especifica los comandos que puede
seguir, y las instrucciones le dicen qu hacer.
Los lectores de tarjetas magnticas y las mismas tarjetas son hardware.
I

Informacin
Elemento fundamental que manejan los computadores en forma de datos binarios.
Tras la revolucin industrial, se habla de la revolucin de la informacin, que se ha
convertido en el mayor valor de las empresas y de las personas. El auge,
proliferacin y universalizacin de sistemas de interconexin global como Internet,
ha llevado a hablar de la sociedad de la informacin como el nuevo paradigma del
mundo en que vivimos.

193

Integridad
Se refiere a las medidas de salvaguarda que se incluyen en un sistema de
informacin para evitar la prdida accidental de los datos,

Interface
Interfaz. Conexin e interaccin entre hardware, software y el usuario. El diseo y
construccin de interfaces constituye una parte principal del trabajo de los
ingenieros, programadores y consultores. Los usuarios "conversan" con el
software. El software "conversa" con el hardware y otro software. El hardware
"conversa" con otro hardware. Todo este "dilogo" no es ms que el uso de
interfaces. Las interfaces deben disearse, desarrollarse, probarse y redisearse;
y con cada encarnacin nace una nueva especificacin que puede convertirse en
un estndar ms, de hecho o regulado.

Interface de usuario
Engloba la forma en la que el operador interacta con el computador, los
mensajes que ste recibe en pantalla, las respuestas del computador a la
utilizacin de perifricos de entrada de datos, etc.

L

Lectores
Son dispositivos hardware en los cuales se pueden leer las tarjetas de banda
magntica, algunos son de pasada otros de insercin de tarjetas.

194

Lenguaje de programacin
Conjunto de normas lingsticas que permiten escribir un programa y que ste
sea entendido por el computador y pueda ser trasladado a computadores similares
para su funcionamiento en otros sistemas

Login
Entrada de identificacin, conexin.

M

Men
Es el catlogo o relacin de programas y procedimientos que aparece en pantalla
con el fin de que, usando un teclado, un dispositivo tctil, un lpiz ptico o un
ratn, el operador pueda elegir qu opcin desea ejecutar. Los denominados
desplegables son el tipo ms habitual en la actualidad: muestran un Men
Principal y, tras una sencilla operacin, sus diferentes opciones. Los sistemas
operativos basados en mens desplegables estn dejando paso a otros -ms
cmodos y fciles de utilizar- basados en ventanas.

Microsoft Access
DMBS para Windows de Microsoft que lee directamente archivos Paradox, dBASE
y Btrieve. Utilizando el ODBC, Access lee directamente del servidor Microsoft y
SYBASE SQL y datos de Oracle. Su lenguaje de programacin es Access BASIC,
y los "Asistentes" formulan preguntas para crear formatos, informes y grficos.

195

O

Organigrama
Se define como la presentacin de las diferentes etapas que es necesario seguir
para conseguir la resolucin del problema planteado. Estas diferentes etapas se
van representando mediante unos conjuntos de smbolos de uso convencional. El
organigrama se puede definir intermedio entre el algoritmo y el programa.

Orientacin a Objeto
En la programacin tradicional, se distingue entre los datos y los procedimientos.
En la tcnica de programacin orientada a objeto no es as, puesto que no existen
los procedimientos como tales. Los elementos de los programas se denominan
objetos y son considerados como entidades independientes que se relacionan e
interactan entre s.

P

Password
(Contrasea). Se denomina as al mtodo de seguridad que se utiliza para
identificar a un usuario. Es frecuente su uso en redes. Se utiliza para dar acceso a
personas con determinados permisos.

196
Plataforma
Es un trmino de carcter genrico que designa normalmente una arquitectura de
hardware, aunque tambin se usa a veces para sistemas operativos o para el
conjunto de ambos.

Portabilidad
Caracterstica de ciertos programas que les permite ser utilizados en distintos
computadores sin que precisen modificaciones de importancia.

Pos
Se le llaman a los puntos de ventas o a las taquillas donde los clientes hacen sus
compras.

Proceso
En informtica se manejan varias definiciones que aluden a diversos elementos:
puede ser simplemente una operacin o conjunto combinado de operaciones con
datos, o bien una secuencia de acontecimientos definida nica y delimitada, que
obedece a una intencin operacional en condiciones predeterminadas. Tambin
se denomina proceso a una funcin que se est ejecutando.

Programa
Redaccin de un algoritmo en un lenguaje de programacin.
Conjunto de instrucciones ordenadas correctamente que permiten realizar
una tarea o trabajo especfico.

197
Toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas,
directa o indirectamente, en un sistema informtico para realizar una
funcin o una tarea o para obtener un resultado determinado, cualquiera
que fuere su forma de expresin y fijacin.
Conjunto secuenciado de instrucciones que quedan escritas en un lenguaje
determinado con unos fines especficos. Aunque en el lenguaje comn con
frecuencia se denomina programa al sistema operativo, la diferencia
estriba, precisamente, en la especificidad de aqul frente al carcter de
gestin global de ste. La palabra software engloba ambos.

Programacin
Programar es automatizar y definir una serie de procesos para resolver un
problema y obtener un resultado final. Un programa es el conjunto de
instrucciones que se le dan al computador para resolver un problema o tarea
determinada. Consiste en proporcionar a un equipo un conjunto de instrucciones
(o sentencias) que deben ser ejecutadas en orden, y que proporcionan una salida.
Preparacion de los datos previos indispensables para obtener la solucion de un
problema mediante las instrucciones codificadas de un computador. Lenguaje de
Programacion Se utilizan para indicar al computador las acciones que ha de
realizar para resolver un determinado problema. Basicamente los lenguajes de
programacion se componen de ordenes (en adelante llamadas instrucciones) que
es lo que en si mismo le dice al computador lo que tiene que hacer. Un conjunto
de esas instrucciones forman el programa.

198
R

Registro
Es un conjunto de datos relacionados entre si, que a su vez forman un archivo.

Red
Se ha dicho muchas veces que el futuro de la informtica est en las
comunicaciones. Es una afirmacin bastante obvia que hoy tiene ya sentido pleno.
La intercomunicacin entre computadores permite no slo el intercambio de datos,
sino tambin compartir recursos de todo tipo, optimizando as elevadas
inversiones. Las redes son el soporte para estas conexiones y (aparte la
diferenciacin ms genrica entre redes pblicas y privadas), segn el objeto de
definicin, la terminologa es variada.

S

Servidor
Genricamente, dispositivo de un sistema que resuelve las peticiones de
otros elementos del sistema, denominados clientes. (Ver: Cliente/servidor).
Computadora conectada a una red que pone sus recursos a disposicin del
resto de los integrantes de la red. Suele utilizarse para mantener datos
centralizados o para gestionar recursos compartidos. Internet es en ltimo
trmino un conjunto de servidores que proporcionan servicios de
transferencia de archivos, correo electrnico o pginas WEB, entre otros.

199
Sistema Operativo
Conjunto de programas fundamentales sin los cuales no sera posible hacer
funcionar el computador con los programas de aplicacin que se desee
utilizar. Sin el sistema operativo, el computador no es ms que un elemento
fsico inerte.
Todo sistema operativo contiene un supervisor, una biblioteca de
programacin, un cargador de aplicaciones y un gestor de archivos. MS-
DOS y Windows 95 son los ms conocidos, pero hay muchos ms.

Software
El trmino ingls original define el concepto por oposicin a hardware: blando-
duro, en referencia a la intangibilidad de los programas y corporeidad de la
mquina. Software es un trmino genrico que designa al conjunto de programas
de distinto tipo (sistema operativo y aplicaciones diversas) que hacen posible
operar con el computador.

T

Tabla
Una o ms filas de celdas de una pgina que se utilizan para organizar el
diseo de una pgina Web o para ordenar datos sistemticamente.
Una tabla es un objeto, o una entidad que se identifica a travs de sus
atributos campos (columnas), y puede ser la abstraccin de algo real o
intangible.

200
Tarjetas Magnticas
Las tarjetas de plstico con una franja magntica ya forman parte de la vida de
todos, simplificando las operaciones bancarias, compras, controlando el
acceso a lugares restringidos, etc. Por lo tanto, no es necesaria la explicacin
sobre las posibilidades actuales y futuras de dichas tarjetas.

U

UML
(Unifed Modeling Languaje) El lenguaje para modelamiento unificado (UML), es un
lenguaje para la especificacin, visualizacin, construccin y documentacin de
los artefactos de un proceso de sistema intensivo. Fue originalmente concebido
por la Corporacin Rational Software y tres de los ms prominentes
mtodologistas en la industria de la tecnologa y sistemas de informacin: Grady
Booch, James Rumbaugh, y Ivar Jacobson ("The Three Amigos"). El lenguaje ha
ganado un significante soporte de la industria de varias organizaciones va el
consorcio de socios de UML y ha sido presentado al Object Management Group
(OMG) y aprobado por ste como un estndar (noviembre 17 de 1997).

Usuario
Un usuario puede ser definido como aquella persona que iteracta con la
computadora a nivel de aplicacin. En cambio, los programadores y todo
profesional tcnico no pueden ser considerados como usuarios cuando trabajan
con la computadora a nivel profesional.

201
V

Ventana
Sector de la imagen en la pantalla del monitor que muestra distintas posibilidades
de operar u opciones, el desarrollo de ciertos procesos, etc. Su uso permite
superponerlas para ver aquello que deseamos, manteniendo a la vez otras
ventanas en superposicin o en otros sectores de la pantalla. (Ver: Windows). El
sistema de ventanas ha proporcionado al usuario una mayor facilidad y rapidez de
uso al no tener que recurrir a comandos difciles de recordar, puesto que se
transmiten las rdenes a travs de iconos.

Visual Basic
Versin de BASIC de Microsoft utilizado para desarrollar aplicaciones de Windows,
que se ha vuelto popular. Es similar a QuickBASIC de Microsoft, pero no es 100%
compatible con ste. Las interfaces de usuario se desarrollan llevando objetos de
la caja de herramientas de Visual Basic hacia el formato de aplicacin.

02.texto Completo

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

02.texto Completo

Загружено:

Авторское право:

Доступные форматы

FACULTAD DE

Вам также может понравиться