Upload
ngegs
View
46
Download
0
Embed Size (px)
Citation preview
FACULTAD DE
INGENIERA DE SISTEM AS
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
UNIVERSIDAD DE MEDELLN
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
UNIVERSIDAD DE MEDELLN
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
5.3. DIAGRAMA DE CASOS DE USO ................................................................ 110
4.4. DIAGRAMA DE ESTADOS ........................................................................... 111
4.5. DICCIONARIO DE DATOS ........................................................................... 111
4.6. RELACIONES.................................................................................................. 113
4.7. REPORTES GENERADOS........................................................................... 114
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.3. DIAGRAMA DE CASOS DE USO ................................................................ 122
6.4. DICCIONARIO DE DATOS ........................................................................... 123
6.4.1 Tabla: POS............................................................................................... 123
6.4.2 Tabla: FACTURA: ................................................................................... 123
6.4.3 Tabla: TURNO: ........................................................................................ 124
6.5. RELACIONES.................................................................................................. 126
6.6. REPORTES GENERADOS........................................................................... 127
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.3. DIAGRAMA DE CASOS DE USO ................................................................ 130
7.4. DICCIONARIO DE DATOS ........................................................................... 130
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.3. DIAGRAMA DE CASOS DE USO ................................................................ 137
8.4. DICCIONARIO DE DATOS ........................................................................... 137
8.4.1 Tabla: EMPRESA.................................................................................... 137
8.4.2 Tabla: VENTASXATRACCION: ............................................................ 138
8.5. RELACIONES.................................................................................................. 140
8.6. REPORTES GENERADOS........................................................................... 141
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
9.3. DIAGRAMA DE CASOS DE USO ................................................................ 144
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
entretenimiento, 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
ASAMBLEA DE ACCIONISTAS
JUNTA DIRECTIVA
GERENTE GENERAL
COMERCIAL MANTENIMIENTOS Y OFICIOS VARIOS
CONTABILIDAD Y TESORERIA
RECURSOS HUMANOS SALUD OCUPACIONAL
ASISTENTES
RECEPCIONISTA
REVISOR FISCAL
REPRESENTANTES DE OTRAS CIUDADES
ASISTENTE COMERCIAL
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.
Caractersticas de la pista 2:
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.
Caractersticas de la pista 3:
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 proto tipo 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 continua 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 no tacin
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 camino 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
