moviles
DESCRIPTION
Tesis de MovilesTRANSCRIPT
-
ESCUELA SUPERIOR POLITCNICA DEL LITORAL
Facultad de Ingeniera en Electricidad y Computacin
Pago Electrnico a Travs de Telfonos Mviles
TESIS DE GRADO
Previo a la obtencin del Ttulo de:
INGENIERO EN COMPUTACION ESPECIALIZACIN
SISTEMAS DE INFORMACIN Y SISTEMAS
TECNOLGICOS
Presentada por:
Fernando Pal Espinosa Peaherrera
Angel Fernando Soto Sarango
GUAYAQUIL - ECUADOR
AO 2009
-
A G R A D E C I M I E N T O
Ing. Bismar Salamea, por su gua en la
elaboracin de la tesis, al Ing. Francisco
Novillo por ser nuestro director en la
presente tesis.
-
DEDICATORIA
En primer lugar a Dios y la Virgen del Cisne, por haberme dado salud y ser mi gua en mi vida, a mis Padres, hermanos y sobrinos que con sus consejos, amor, comprensin han sabido ganarse mi cario, respeto y admiracin, a mis amigos lojanos que siempre estuvieron para apoyarme en los buenos y malos momentos.
De manera especial a dos seres queridos que en este momento no estn fsicamente conmigo, Mi madre +Mara Sarango y mi hermana +Elsa Maria Soto Sarango, que fueron los pilares fundamentales para que lleve a feliz culminacin mi carrera.
Angel Fernando Soto Sarango
Dios por el camino recorrido, a mi familia por su apoyo durante mis aos de estudio
Fernando Pal Espinosa Peaherrera.
-
TRIBUNAL DE GRADO
________________ Ing. Holger Cevallos
SUBDECANO DE LA FIEC
________________ Francisco Novillo P.
DIRECTOR DEL TOPICO
________________ Ing. Washington Medina M.
VOCAL PRINCIPAL
________________ Dr. Boris Ramos S.VOCAL PRINCIPAL
-
DECLARACION EXPRESA
La responsabilidad del contenido de esta Tesis de Grado, nos corresponde
exclusivamente: y el patrimonio intelectual de la misma a la ESCUELA
SUPERIOR POLITECNICA DEL LITORAL.
---------------------------------------------------- -----------------------------------------Fernando Pal Espinosa Peaherrera Angel Fernando Soto Sarango
-
RESUMEN
El objetivo del presente proyecto es ofrecer un mecanismo de pago
electrnico a las personas desde cualquier lugar geogrfico con cobertura
celular.
El presente proyecto sea dividido en cinco captulos, en el primer captulo se
habla de los antecedentes del negocio, posteriormente hablamos sobre la
situacin actual del negocio, la forma de procesar las transacciones,
proseguimos con la posible tecnologa a utilizar para resolver nuestro
problema planteado, continuamos con nuestras limitaciones operacionales
que tendremos de nuestro proyecto, las justificaciones para el cambio de la
forma de realizar las transacciones, la lgica del negocio, y finalmente
planteamos nuestros objetivos para el pretendemos alcanzar con nuestro
proyecto.
En el captulo dos, se describe toda la investigacin terica del proyecto
iniciando con las descripciones de J2ME, sus principales ventajas y
caractersticas para trabajar en dispositivos con poca capacidad de
procesamiento, seguidamente se habla de las caractersticas de GPRS,
mencionado que nuestra comunicacin entre el mvil y el servidor de control
-
ser a travs de GPRS, continuamos con mencionando caractersticas y
ventajas de utilizar el protocolo HTTPS, continuamos con el protocolo
TCP/IP, para finalizar hablando sobre las tarjetas de crdito, emisores de las
mismas, tipos de procesadores en el mercado.
En el captulo tres, se describe al proyecto como se lleg a la solucin del
mismo, inicialmente con la solucin que planteamos, luego con la descripcin
del software que desarrollamos para resolver el mismo, describiendo el
software desarrollado en el dispositivo mvil o aplicacin cliente,
posteriormente se describe la aplicacin Servidor y la Aplicacin Switch,
finalmente continuamos con las seguridades de nuestra aplicacin, para ello
mencionamos los tipos de estndares que se utilizaron en el desarrollo de
nuestras aplicaciones, la criptografa, y finalmente el tipo de seguridad que se
utiliza en cada una de las aplicaciones que se desarrollo como son la
aplicacin Cliente, la aplicacin Servidor, las seguridades en la comunicacin
del mvil con el servidor de control, posteriormente la seguridad entre el
servidor de control y el Sistema de Switch de Autorizaciones.
En el capitulo cuatro, se describe como se implement las aplicaciones,
iniciando con los Mdulos de Aplicacin, siguiendo con los Modelos de
-
Clases, los Modelos de Datos, y finalmente con los resultados obtenidos en
el desarrollo de nuestra aplicacin.
En el captulo final realizamos un plan de negocios, para ello iniciamos con el
anlisis de mercado, en donde realizamos encuestas a nuestros posibles
clientes, seguidamente se realizo un anlisis FODA (Fortalezas,
Oportunidades, Debilidades y Oportunidades), seguidamente se segmento
nuestro mercado para obtener un mercado potencial donde ser incluido
nuestro proyecto o puesto en funcionamiento nuestra aplicacin,
seguidamente continuamos con la descripcin de los costos de diseo e
implementacin, recursos necesarios para iniciar nuestro proyecto, y
finalmente con un anlisis financiero a tres aos de nuestro proyecto, en el
cual a travs del VAN podemos ver que es muy beneficio la realizacin del
mismo al obtener 8,63 de VAN por cada dlar invertido.
-
IINDICE GENERAL
INDICE GENERAL___________________________________________________I
INDICE DE FIGURAS_________________________________________ III
INDICE DE TABLAS____________________________________________V
INTRODUCCION_______________________________________________1
CAPITULO I
Antecedentes ________________________________________________3
1.1.Situacin Actual ____________________________________ 4
1.2.Tecnologa a Utilizar _________________________________7
1.3.Limitaciones Operacionales ___________________________8
1.4.Justificacin para los Cambios _______________________ 10
1.5.Lgica del Negocio _________________________________ 11
1.6.Objetivo General ___________________________________15
1.7.Objetivos Especficos _______________________________ 16
1.8.Conclusiones ______________________________________19
CAPITULO II
Teora ______________________________________________________20
2.1. Caractersticas Principales de Java 2 Micro Edition (J2ME) _ 27
2.2. Caractersticas Principales de General Packet Radio Service 29
2.3. Hiper Text Transfer Protocol Secure (HTTPS) ____________33
2.4. Protocolo de Comunicacin TCP/IP ____________________34
-
II
2.5. Las Tarjetas de Crdito ______________________________37
CAPITULO III
Descripcin del Proyecto _____________________________________40
3.1. Solucin Planteada ________________________________ 41
3.2. Descripcin del Software ____________________________ 44
3.2.1. Descripcin de la Aplicacin J2ME _______________ 45
3.2.2. Descripcin del Switch_________________________ 51
3.3. Seguridad
3.3.1 Estndares de Seguridad _______________________ 58
3.3.2 Criptografa __________________________________ 59
3.3.3 Descripcin de la Arquitectura de Seguridad ________ 61
CAPITULO 4
Implementacin del Proyecto __________________________________69
4.1. Mdulos de Aplicacin ______________________________ 70
4.2. Modelo de Clases __________________________________ 73
4.3. Modelo de Datos __________________________________ 88
4.4 Resultados Obtenidos ______________________________ 89
-
III
CAPITULO 5
Plan de Negocios ___________________________________________107
5.1. Anlisis de Mercado _______________________________108
5.2. Competidores ____________________________________110
5.3. Mercado Potencial ________________________________ 113
5.4. Costo de Diseo __________________________________115
5.5. Costos de Implementacin __________________________116
5.6. Recursos Necesarios ______________________________ 118
5.7. Anlisis Financiero a 3 aos _________________________119
CONCLUSIONES Y RECOMENDACIONES
ANEXOS
BIBLIOGRAFIA
-
III
INDICE DE FIGURAS
Pag.
Figura 1.1. Tecnologas a Utilizar en Nuestro Proyecto ..8
Figura 1.2. Diagrama de la Lgica del Negocio ..15
Figura 2.1. Campo de texto para el ingreso de un nmero de tarjeta de crdito 23
Figura 2.2. Aquitectura TCP/IP ..35
Figura 2.3. Encapsulacin de Datos .....36
Figura 2.4. Estructura de Datos .36
Figura 3.1. Diagrama de la Arquitectura del Sistema 42
Figura 3.2. Pantalla de configuracin de la aplicacin cliente .46
Figura 3.3. Secuencia de pantallas para realizar una transaccin con la aplicacin cliente ..49
Figura 3.4. Diagrama de flujo de autenticacin de aplicaciones cliente .68
Figura 4.1. Mdulos de Aplicacin... .71
Figura 4.2. Diagrama de clases de la aplicacin cliente. Parte 1 76
Figura 4.3. Diagrama de clases de la aplicacin cliente. Parte 2 77
Figura 4.4. Diagrama de clases de la aplicacin Servidor . ..80
Figura 4.5. Diagrama de Secuencia para el caso de uso 2.... ..87
Figura 4.6. Diagrama entidad-relacin de la base de datos del servidor de control.88
Figura 4.7. Formulario de Solicitud de Autorizacin de Cobro .95
Figura 4.8. Respuestas de Transaccin Exitosa 95
Figura 4.9. Contenido de la ventana de Log del emulador del Nokia SDK para el caso de una peticin de autorizacin ..96
Figura 4.10. Datos de autorizacin exitosa de cobro en la aplicacin Local.exe ...97
-
IV
Pag.
Figura 4.11. Realizacin de una autorizacin de cobro en el sistema Emisor.exe ....98
Figura 4.12. Mensaje de datos ingresados no vlidos 99
Figura 4.13. Baja de un usuario del servicio en el administrador de la base de datos100
Figura 4.14. Mensaje indicando que los datos no pasaron el proceso de autenticacin en el servidor 101
Figura 4.15. Aplicacin Local.exe. Nmero de tarjeta para el que se solicita autorizacin no corresponde al rango de bines del emisor 102
Figura 4.16. Mensaje mostrado al usuario en caso de que el nmero de tarjeta para el que se solicita autorizacin no corresponde al
rango de bines del emisor 102
Figura 5.1. Mercado Potencial: Parque de los Jipis (Cuenca)114
Figura 5.2. Cotizacin del Servidor Dedicado para el Primer Ao117
Figura 5.3. Cotizacin de Servidores Dedicado para el segundo y tercer ao118
-
VINDICE DE TABLAS
Pag.
Tabla 2.1. Cuadro comparativo del anlisis de J2ME, WAP y SMS como alternativas para la implementacin de la solucin propuesta .27
Tabla 2.2. Tarjetas de Crdito y Bancos que la Poseen ..38
Tabla 2.3. Procesadores de Tarjetas de Crdito ...39
Tabla 5.1. Fortalezas y Debilidades de Nuestra Empresa 112
Tabla 5.2. Oportunidades y Amenazas de Agentes Externos ..112
Tabla 5.3. Costos de Diseo ..116
Tabla 5.4. Anlisis Financiero a tres aos del Proyecto 120
Tabla 5.5. Costos y Beneficios por Transaccin .121
Tabla 5.6. Calculo del TIR y VAN de Nuestro Proyecto .122
-
INTRODUCCIN
Muchas cosas han cambiado en el mundo, especialmente con la tecnologa de
las telecomunicaciones y en las empresas en los ltimos aos.
El mundo se ha globalizado, la competencia est en todos lados, estos nuevos
desafos han llevado a una transformacin profunda de la manera de realizar las
transacciones comerciales. La aparicin de nuevas tecnologas (nuevas
arquitectura y dispositivos) y la consolidacin de otras anteriores (por ejemplo
las redes IP) ha facilitando la evolucin natural desde la voz hacia los datos,
hecho que se conoce mejor con el trmino de multimedia. Esto ha permitido la
creacin de medios ms potentes y novedosos y de nuevos canales de relacin
entre personas o entre personas y sistemas.
En vista de la evolucin de las comunicaciones surgi la idea de crear un
sistema de pago a travs del telfono mvil, el cual solicita la autorizacin para
realizar el cobro a la tarjeta de crdito, mediante un software instalado en el
telfono mvil.
-
2Nuestro objetivo es ofrecer un mecanismo de pago electrnico a las empresas y
personas desde cualquier lugar geogrfico con cobertura celular y as extender
el uso de la infraestructura de pagos electrnicos en los negocios de gran y
menor tamao (PYMES), tales como: comercio al menudeo, tiendas de
abarrotes, locales de comida, islas, papeleras, farmacias y hasta taxis.
-
CAPITULO I
1. ANTECEDENTES
Hoy en da los telfonos celulares constituyen un recurso al alcance de
prcticamente toda persona en nuestro pas, existen 10.981.455 abonados
que corresponde aproximadamente al 84,48% de la poblacin [1]. El uso
masivo de este dispositivo ha permitido que las operadoras de telefona
celular expongan sus servicios para tener la posibilidad de ofrecer una
variedad de soluciones que permitan satisfacer las necesidades de los
usuarios. Es por esto que en el mercado podemos encontrar una gran
variedad de modelos cada vez con mejores capacidades de procesamiento.
-
4Toda la tecnologa aplicada en estos dispositivos permite ampliar aun ms el
campo de servicios que ofrece la telefona celular.
Al igual que los telfonos celulares, el uso de las tarjetas de crdito se
incrementa cada ao [2] y la facilidad de obtenerla en muchos pases motiva
la idea de tener un sistema de pago a travs de un telfono celular.
El objetivo principal de nuestro trabajo es ofrecer un mecanismo de pago
electrnico a empresas y personas que desde cualquier lugar geogrfico con
cobertura celular permita extender el uso de la infraestructura de pagos
electrnicos a los negocios de gran y menor tamao.
1.1 Situacin Actual.
Al investigar la situacin actual de los pequeos y medianos negocios
(PYMES), muchos de estos o la gran mayora no disponen de la
infraestructura de comunicacin a travs de una red de telefona
convencional, o de un medio para realizar cobros con tarjeta de crdito.
Uno de los principales problemas a los que se enfrentan las empresas
-
5para proceder con una transaccin de pago es la obtencin de la
autorizacin necesaria para el inicio de su operacin.
Si consideramos el uso de plataformas de pago electrnico que en la
actualidad existen, podemos mencionar los portales de pago electrnico
utilizados para transacciones comerciales o mobile commerce (m-
commerce)1[3] a travs del Internet, entre los ms populares tenemos
PayPal [4], ALIGNET [5].
Estas soluciones resultan muy tiles para los modelos de negocios en
Internet, si consideramos por el contrario negocios ms pequeos en los
cuales no se disponen de los medios econmicos para sustentar la
implementacin y mantenimiento de una solucin de este tipo, surge la
idea de proveer de un mecanismo muy similar pero menos costoso
utilizando dispositivos mviles, de esta forma podemos aprovechar la
infraestructura que ofrecen las operadoras de telefona mvil, para
1 m-commerce (mobile commerce) el comercio electrnico mvil. Esto es, la posibilidad de realizar transacciones comerciales a travs de un dispositivo mvil. En este proceso de comercio mvil estn o pueden estar incluidos todos los pasos de una transaccin comercial. 2001, Havet Interactive S.A., GPRS: La Nueva Generacin de telefona mvil
-
6brindar a los pequeos y medianos negocios un servicio adicional para el
cobro por sus ventas.
Si consideramos adems que hoy en da la mayora de las personas
disponen de un telfono celular, gracias a la constante expansin en la
cobertura de las redes de telefona mvil y al marketing que basado en
sus mejores capacidades y funcionalidades se le ha dado a estos
dispositivos, convierte a estos aparatos en un vehculo muy atractivo
como sistema de pago electrnico [6].
Esto permite plantearnos el diseo de un sistema de pago electrnico a
travs de telfonos mviles, el cual establecer una conexin con la red
de entidades financieras y solicitar autorizacin al emisor de la tarjeta
de crdito del cliente para realizar el cobro a travs de la misma
mediante el desarrollo de una aplicacin instalada en el telfono celular.
Nuestro objetivo principal por lo tanto es ofrecer un mecanismo de pago
electrnico a las empresas y personas desde cualquier lugar geogrfico
-
7con cobertura celular que permita extender el uso de la infraestructura de
pago electrnico en los PYMES tales como: comercio al menudeo,
tiendas de abarrotes, locales de comida, islas, papeleras, farmacias,
taxis, entre otros.
1.2.Tecnologa a utilizar
Para la realizacin de este proyecto de tesis se ha efectuado un
anlisis de las principales tecnologas y aspectos tcnicos
involucrados en su desarrollo como son: lenguajes de programacin,
mecanismos de seguridad, protocolos de comunicacin entre otros y
sobre todo tomando muy en cuenta las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI) [7]. Estos aspectos
poseen las caractersticas que nos permitirn solucionar la
problemtica planteada en el enunciado anterior.
-
8Las siguientes son las tecnologas disponibles que hemos calificado
las ms indicadas para ser aprovechadas en el desarrollo de nuestra
solucin, las mismas que en el captulo siguiente sern descritas con
mayor profundidad y daremos nuestras razones para usarlas, en la
figura 1.1 presentamos las tecnologas a utilizar en nuestro proyecto:
Figura 1.1 Tecnologas a Utilizar en Nuestro Proyecto
1.3.Limitaciones operacionales
En el presente subcaptulo hacemos referencia a las posibles barreras
que se podran presentar previa la implementacin de un sistema de esta
ndole.
-
9Una de las principales es la negativa de las entidades financieras,
pasarelas de pago y dems componentes principalmente los switch2 de
autorizaciones [8] o Procesadores de Tarjetas de Crdito3 para
transacciones electrnicas que tienen un dominio del mercado, las
mismas que no brindan ninguna informacin tcnica del proceso,
informacin que sera muy til para el desarrollo de la solucin
propuesta, siendo este ltimo nuestro principal limitacin operacional.
Puede resultar desventajoso para nuestra propuesta que frente a los
medios tradicionales de cobro con tarjeta de crdito los usuarios
encuentren dificultades al adaptarse al nuevo sistema, que es
bsicamente la reaccin de los usuarios al cambio o al uso de nueva
tecnologa (el proceso de cobro a travs del telfono mvil) o
simplemente puede ser que los clientes de los establecimientos
asociados a nuestra aplicacin no confen en la seguridad de las
transacciones por este medio.
2 Software de Autorizaciones de Tarjetas de Crdito en Lnea, utilizando la ISO 8583, SuSistema Cia. Ltda., 2002, SWITCH DE AUTORIZACIONES3 Los Principales Procesadores o Emisores de Tarjetas de Crdito son: DATAFAST, MEDIANET, UNIBANCO, AUSTRO Y SERVITRANSEL.
-
10
1.4.Justificacin para los cambios
Una vez realizado un breve anlisis de la situacin actual de las posibles
transacciones electrnicas que pueden realizarse en nuestro pas y
considerando nuestra alternativa como la solucin que permita incorporar
a ms pequeos y medianos negocios en el Ecuador, el Tpico de
Desarrollo de Aplicaciones para Telfonos Mviles y el Grupo de
Investigacin GICOM de la Escuela Superior Politcnica del Litoral
(ESPOL), a travs del presente proyecto Pago Electrnico a travs del
Telfono Mvil, pretender ofrecer a los PYMES una solucin que
permita incrementar sus ventas, agregando a su grupo de clientes a un
mercado de 1.691.885 millones de tarjeta habientes[9] en nuestro
mercado local.
Entre los principales beneficios que podr obtenerse del desarrollo de la
solucin podemos mencionar los siguientes:
Realizar transacciones en cualquier momento y lugar incluso en
lugares a donde no lleguen los medios de comunicacin
tradicionales o no se disponga de la infraestructura necesaria para
la aceptacin de pagos con tarjeta de crdito. Esto beneficiara
-
11
enormemente a los comerciantes contribuyendo especialmente al
desarrollo de la pequea y mediana empresa.
El incremento en las ganancias de los comerciantes, al ofrecer
otra posibilidad de pago lo que a su vez se refleja en la prestacin
de un mejor servicio.
La simplicidad en el proceso de toma de la informacin sobre la
transaccin.
1.5.Lgica del negocio
El objetivo de describir la lgica del negocio para nuestro caso, es
ofrecer un modelo que permita entender de manera general el
funcionamiento de esta solucin una vez que est implementada.
Para el caso de la solucin propuesta, el procedimiento a llevar a cabo
consistir en efectuar pagos por el celular mediante una aplicacin que
permitir al usuario para establecer un enlace con nuestro servidor Web,
-
12
este a su vez se conectar a otro servidor que har la conexin con el
banco emisor.
El usuario, contrasea y nmero identificador del equipo son los datos
que se utilizan para la autenticacin en la base de datos a la que se
conecta la aplicacin servidor.
Para minimizar los riesgos en caso de que un equipo se extrave o sea
robado, cada usuario del sistema poseer un usuario, contrasea y
nmero de identificador del equipo, en la base de datos a la que se
conecta la aplicacin servidor. Por razones principalmente de seguridad
se ha decidido que estos datos de autenticacin no estn al alcance del
comerciante que utilizar la aplicacin, si no que se mantengan
almacenados internamente en el equipo celular. Adems, los celulares
no guardarn informacin alguna respecto a las transacciones
realizadas, debemos dejar claro que el telfono celular solo ser utilizado
como una herramienta que permita realizar una conexin con los
procesadores de tarjetas de crdito y entidades bancarias, estos son los
que tienen un sinnmero de seguridades y sistemas anti fraud, los
mismos que detallaremos en el captulo tres.
-
13
El comerciante que desee realizar un cobro, deber ingresar los datos de
la transaccin junto con el detalle de la tarjeta en un formulario que le
proveer la aplicacin instalada en el telfono mvil. Los datos de cada
transaccin junto con los datos de usuario del comerciante debern viajar
cifrados hasta el servidor de control. Esta tarea la realizar la misma
aplicacin instalada en el telfono mvil de tal manera que se impida
posibles fraudes.
El servidor de control contendr los detalles de las cuentas de
vendedores y por tanto se encargar de realizar su respectiva
verificacin. De aqu en adelante el proceso a seguir es similar al
proceso que se sigue al efectuar transacciones electrnicas con tarjeta
de crdito en un sitio Web, es decir el servidor de control enva la
informacin de la transaccin a una entidad de procesamiento de pagos
va Internet que es el equivalente a un Terminal de punto de venta con
tarjetas de crdito en un almacn, est a su vez enva la informacin de
la transaccin, va conexin segura a la entidad verificadora de tarjetas
de crdito del banco del vendedor, la cual reenva la informacin de la
transaccin a una red de procesamiento de transacciones en donde una
entidad financiera autorizada encamina los datos al respectivo banco
emisor (el banco que le emiti la tarjeta de crdito al cliente) para
-
14
autorizacin. La respuesta ser recibida en el servidor de control, el cual
enviar al usuario solicitante un mensaje de aceptacin o rechazo del
petitorio realizado.
Para visualizar mejor la interaccin de los procesos se realiz el
diagrama de la lgica del negocio como podemos observar en la figura
1.2.
Figura 1.2 Diagrama de la lgica del negocio
-
15
1.6.Objetivo General
El objetivo principal que aspiramos en el desarrollo de la presente tesis
es ofrecer un mecanismo alternativo de pago electrnico con dbito a la
tarjetas de crdito de un cliente a travs de telfonos mviles (telfonos
mviles que se encuentren dentro del rea de cobertura de las
operadoras de telefona), enfocando la solucin especialmente en los
pequeos y medianos negocios.
1.7 Objetivos Especficos
Reduccin de Costos
Por el lado de los comerciantes, este proyecto pretende minimizar
significativamente los costos de transacciones aprovechando el hecho de
que las comisiones por utilizar el telfono celular como un Terminal de
Punto de Venta sern mucho ms reducidas. Sumado a esto est el
hecho de que con esta alternativa los comerciantes no debern disponer
de equipos o de ningn infraestructura para efectuar cobros con tarjeta de
crdito si no que solamente bastar que dispongan de un telfono mvil.
Esto resultar un gran atractivo para los negocios interesados en aceptar
-
16
pago electrnico en transacciones, sin que les represente un gasto
exagerado.
Aprovechamiento del uso masivo de los telfonos celulares
Hoy en da la telefona mvil se ha vuelto ampliamente popular entre la
poblacin, principalmente debido a que los costos cada vez ms
reducidos de los equipos, los cuales presentan cada vez mejores
caractersticas y funcionalidades hacen a estos alcanzables para un
nmero cada vez mayor de usuarios. Sumado a esto tenemos el hecho
de la constante expansin de las redes de telefona mvil, las cuales
llegan cada vez a ms lugares y por lo tanto a una mayor parte de la
poblacin. Estos motivos le representan una gran ventaja a los
telfonos celulares como medio de comercio electrnico con respecto a
los medios tradicionales de cobro con tarjetas de crdito. Por lo tanto
aprovechar esta ventaja es uno de los objetivos a alcanzar con el
desarrollo de esta solucin.
Fomentar el crecimiento de los pequeos y medianos negocios
Otro de los importantes objetivos que se pretende alcanzar con este
proyecto y que representar grandes beneficios para la sociedad y el
-
17
sistema financiero en general es el de ayudar al crecimiento de la
pequea y mediana empresa, puesto que al agregar a la arraigada
cultura del uso de dinero en efectivo para el comercio un medio
alternativo de comercio electrnico, los pequeos y medianos
empresarios podran ver incrementado su nmero de potenciales
clientes, lo cual se traducira en mejores utilidades para los mismos.
Facilitar las transacciones a compradores y vendedores
Este es uno de los principales objetivos a alcanzar, debido a que
pretendemos que esta herramienta facilite la realizacin de transacciones
con tarjeta de crdito tanto para consumidores como para comerciantes,
ya que se trata de un medio de fcil uso y que adems puede ser
empleado en cualquier lugar donde exista cobertura de telefona celular.
Incentivar la inversin en el desarrollo de este tipo de soluciones
Lograr que las instituciones involucradas con pagos inviertan en
investigacin y desarrollo de este tipo de soluciones es otro de los
objetivos que se pretende alcanzar, ya que hoy en da se debe
aprovechar al mximo el crecimiento de usuarios de telefona mvil como
se expuso en uno de los anteriores objetivos y de este modo lograr que
-
18
en nuestro pas se brinden servicios cada vez ms variados y de mejor
calidad para estar a la par con los pases desarrollados, en un mundo
globalizado.
1.8 Conclusiones
La presente solucin otorga a los telfonos celulares la funcionalidad de
potenciales terminales de punto de venta, con lo cual estos ya no solo
sern usados para comunicacin y entretenimiento solamente si no que
se convertirn tambin en poderosas herramientas de comercio
electrnico, extendiendo el uso de la infraestructura de pagos con tarjeta
de crdito en negocios tales como: comercio al menudeo, tiendas de
abarrotes, locales de comida, islas, papeleras, farmacias, taxis entre
otros.
-
CAPITULO II
2. TEORIA
En el presente captulo describiremos de manera detallada las principales
caractersticas referentes a los aspectos tecnolgicos que consideramos
primordiales para cumplir con los objetivos propuestos en nuestro proyecto,
los mismos que hemos seleccionado para la implementacin de nuestra
solucin y que fueron mencionados en el captulo anterior, como se muestra
en la figura 1.1 del Captulo 1.
-
21
Inicialmente detallaremos las principales caractersticas de Java 2 Micro
Edition (J2ME), la herramienta de desarrollo seleccionada para la creacin de
la interfaz de usuario, la cual se instalar en el telfono mvil y guiar al
usuario para la introduccin de los datos de una transaccin de cobro con
tarjeta de crdito y establecimiento de una conexin con un servidor de
control.
Posteriormente detallaremos las principales caractersticas de la tecnologa
General Packet Radio Service (GPRS), caractersticas que a nuestro criterio
hacen de esta tecnologa de comunicacin la ms adecuada para nuestros
fines y que por tanto ha sido seleccionada para la realizacin del intercambio
de datos de transacciones y mensajes entre el telfono mvil y el servidor de
control.
Como plataforma de desarrollo utilizaremos J2ME por las prestaciones que
presenta a la hora de programar aplicaciones para dispositivos mviles.
-
22
A continuacin vamos a explicar porque J2ME fue considerada la primera
opcin para el desarrollo de nuestra solucin, habiendo estudiado adems
las alternativas de utilizar Short Message System (SMS) [10] o Wireless
Application Protocol (WAP) [10].
Java se ha convertido en una de las tecnologas ms reconocidas
y utilizadas para desarrollo de software de redes, desde su
surgimiento en el ao de 1995, adems la configuracin
Connected Limited Device Configuration (CLDC) 1.0 [11] ha tenido
una masiva acogida desde su lanzamiento en el ao 2000, lo que
ha resultado en que J2ME se convierta en una atractiva tecnologa
para el desarrollo de aplicaciones mviles.
J2ME brinda la posibilidad de crear interfaces grficas que
permitirn una mejor experiencia del usuario en el uso de la
aplicacin, caracterstica de la que no se dispone por ejemplo en
el caso de usar un SMS para el envo de la informacin de una
transaccin
En contraste con el uso de SMS o WAP, mediante el uso de un
Midlet [11] se puede ser mucho ms especfico con el usuario en
cuanto al tipo de informacin que de este se requiere. Por
-
23
ejemplo, mediante la propiedad Textfield.NUMERIC de un control
Textfield [11] se puede lograr la restriccin de que solamente
dgitos puedan ser ingresados en el control. De este modo no
ser necesario cambiar el modo de escritura en el telfono celular
o presionar varias veces una tecla para obtener un determinado
carcter. Esto resulta muy til por ejemplo en el caso del ingreso
de un nmero de tarjeta de crdito por parte del usuario, como se
indica en la Figura 2.1.
Figura 2.1 Campo de texto para el ingreso de un nmero de tarjeta de crdito.
Adems de contar con un entorno de ejecucin propio, J2ME
mediante su sistema Record Management System (RMS) [11], nos
provee de un medio para almacenamiento de informacin en el
equipo, caracterstica que veremos ms adelante es un requisito
-
24
indispensable para el caso de nuestra solucin y de la cual no se
dispone en el caso de una aplicacin WAP en donde en ocasiones
solo se dispone de una capacidad limitada de almacenamiento a
travs de cookies.
Existen ciertos aspectos de dependencia en cuanto al Hardware,
los cuales varan de acuerdo a los modelos y fabricantes de
equipos, como por ejemplo: los diferentes tamaos de las
pantallas. Esto podra afectar al desarrollo de ciertos tipos de
aplicaciones como en el caso de juegos, pero no resulta muy
relevante en el caso del desarrollo de aplicaciones de pagos
mviles ya que para el desarrollo de este tipo de aplicaciones el
requerimiento mnimo es disponer de los componentes estndar
para interaccin con el usuario. En J2ME la API [10] de interface
de usuario de alto nivel a travs de la clase Screen [11] provee de
las interfaces comunes o estndar para la interaccin con el
usuario, como son: formularios, cuadros de texto, mensajes de
alerta, listas, etc.
A diferencia de WAP en donde los contenidos se despliegan en un
micro navegador que se encargar de interpretarlos, en las
aplicaciones desarrolladas con J2ME no se dispone de esta
-
25
capacidad, sin embargo, a travs de las diferentes clases
heredadas de Java se tiene la facilidad de analizar e interpretar
cualquier tipo de contenido como puede ser el caso de
documentos en formato Hyper Text Markup Language (HTML) o
Extensible Markup Language (XML) [12].
Debido a las capacidades de trabajar en un entorno multihilo que
posee Java, en un Midlet se puede realizar la interaccin con el
usuario sin inconvenientes inclusive mientras algunos otros
procesos importantes estn siendo ejecutados.
La tabla 2.1 resume los aspectos del anlisis comparativo de las 3
tecnologas como alternativas para el desarrollo del proyecto que
resultaron los justificativos principales para la eleccin de J2ME como
plataforma de desarrollo en el caso de nuestro proyecto
J2ME WAP/WML SMS
-
26
Costos de uso
de la red
Solo se utiliza la
red cuando es
necesario lo
cual se traduce
en bajos costos.
Al residir por
completo la
lgica del
negocio en el
servidor, se
incrementa el uso
de la red.
Costo de envo
de mensajes
de texto son
mayores al
costo de envo
de datos va
HTTP.
Capacidad de
almacenamiento
Provee de un
sistema de
almacenamiento
persistente
especialmente
destinado para
este fin.
Muy limitada,
mediante el uso
ocasional de
cookies en
algunos
navegadores.
No se dispone
de esta
caracterstica.
-
27
interface grfica
de usuario
Se dispone de
la API de
interface de
usuario de alto
nivel que provee
de los controles
comunes o
estndar para la
interaccin con
el usuario
Limitada en
cuanto se refiere
a validaciones y
manejo de
eventos
No se cuenta
con la
posibilidad de
brindar esta
caracterstica
Tabla 2.1 Cuadro comparativo del anlisis de J2ME, WAP y SMS como alternativas para la implementacin de la solucin propuesta
2.1.Caractersticas principales de Java 2 Micro Edition (J2ME)
La plataforma de Desarrollo Java 2, Micro Edition (J2ME), fue pensado
para trabajar sobre equipos con ciertas limitaciones: en
procesamiento, pantalla, energa basada en bateras y de alguna
forma poseen servicios de red para comunicarse con el exterior.
-
28
Java 2 Plataform, Micro Edition (J2ME): Esta versin del lenguaje Java
est enfocada a la aplicacin de la tecnologa Java en dispositivos
electrnicos con capacidades computacionales y grficas muy
reducidas, tales como telfonos mviles, Personal Digital Asistente
(PDAs) o electrodomsticos inteligentes. Esta edicin tiene unos
componentes bsicos que la diferencian de las otras versiones, como
el uso de una mquina virtual denominada Kilo Virtual Machina (KVM),
debido a que requiere slo unos pocos Kilobytes de memoria para
funcionar en vez del uso de la Java Virtual Machina clsica[11].
Dentro de las principales caractersticas tenemos:
Es un lenguaje totalmente orientado a objetos.
La portabilidad y compatibilidad entre plataformas.
Una aplicacin desarrollada en J2ME podr ser ejecutada en
cualquier equipo celular o PDA que tenga una Mquina Virtual
Java instalada y, en esta categora encontramos la mayora de los
dispositivos mviles que se ofrecen en el mercado actualmente
-
29
Es la integracin transparente con otras Tecnologas JAVA.
La posibilidad de ejecutar aplicaciones altamente dinmicas en el
dispositivo inalmbrico, en este sentido, es posible ejecutar,
guardar programas altamente grficos, video a travs de la
conexin en Internet, caso no posible con Wireless Application
Protocol (WAP)/ Wireless Markup Language (WML) [10].
La interface Grfica en general se ve ampliamente superada a
diferencia de aplicaciones WAP/WML.
Para poder tener un entorno de ejecucin JAVA para J2ME que
cumpla los requisitos de un rango amplio de dispositivos y mercados
objetos es necesario que se disponga de Configuracin, Perfiles y
Paquetes opcionales. J2ME se basa en los conceptos de
configuracin y perfil.
2.2.Caractersticas principales de General Packet Radio Service(GSM)
La tecnologa GPRS, o generacin 2.5, representa un paso hacia los
sistemas inalmbricos de Tercera Generacin o Universal Mobile
Telecommunications System (UMTS). Su principal caractersticas
-
30
radica en la posibilidad de disponer de un terminal permanentemente
conectado, tarifando nicamente por el volumen de datos transferidos
(enviados y recibidos) y no por el tiempo de conexin. Proporciona
altas velocidades de transferencias de datos (especialmente til para
conectar a Internet) y se utiliza en las redes GSM y Code Division
Mltiple Access (CDMA)[13] .
La tecnologa GPRS permite proporcionar servicios de datos de una
forma ms eficiente a como se vena haciendo hasta el momento
especialmente consiste en modificar la forma de transmitir datos,
pasando de la conmutacin de circuitos en GSM (donde el circuito
est permanentemente reservado mientras dure la comunicacin
aunque no se enve informacin en un momento dado) a la
conmutacin de paquetes [14].
Algunas de las caractersticas principales de GPRS son [13]:
Velocidad de transferencia hasta 144kbps (170kps terico
mximo).
-
31
Pago por volumen de datos transmitidos y no por tiempo de
conexin.
Mejora sustancialmente el sistema de mensajera, permitiendo
Multimedia Messaging System (MMS) con mensajes de voz, texto,
imgenes y video.
Acceso GPRS a aplicaciones Wireless Application Protocol (WAP)
GPRS es bsicamente una comunicacin basada en paquetes de
datos.
Conexin permanente.
Cada elemento de la red sabe como encaminar cada paquete.
Cuatro niveles de codificacin radio.
Los Telfonos celulares existentes en el mercado con soporte para GPRS
presentan las siguientes caractersticas comunes [14]:
-
32
Capacidad Dual: Estn adaptados para aprovechar la cobertura
existente tanto en GSM para la voz como en GPRS para los
datos.
Velocidad de transferencia: Se utiliza varios canales
simultneos. El nmero de canales depende de cada equipo,
variando de 1 a 4 para la recepcin de datos y de 1 a 2 para el
envo.
Tarjeta Subscriber Identity Module (SIM): Utilizan la tarjeta SIM
GSM.
El enlace que utilizamos entre el mvil y el servidor de control ser a
travs de GPRS que por lo antes expuesto resulta ser la mejor opcin.
Dentro de los servicios soportados tenemos: World Wide Web
(WWW), File Transfer Protocol (FTP), Telnet, Chat, E-mail, Imagen,
Audio, Video[14].
-
33
Esta tecnologa consiste en otra forma de transmisin de datos en
donde se pasa de la conmutacin de circuitos comnmente utilizada
en GSM (En donde el circuito est permanentemente reservado
mientras dure la comunicacin) a la conmutacin de paquetes.
2.3.Hyper Text Transfer Protocol Secure (HTTPS).
El protocolo HTTPS la versin segura del protocolo HTTP. HTTPS
utiliza un cifrado basado en el protocolo Secure Socket Layers (SSL).
Este es un protocolo que se sita entre el protocolo de capa de red
(Ej.: TCP) y el protocolo de la capa de aplicacin (Ej.: HTTP). SSL
proporciona mecanismos para establecer una comunicacin fiable
entre un cliente y un servidor, por medio de mecanismos como:
autenticacin, uso de firmas digitales para validar integridad,
certificados y uso de encriptacin para privacidad [16].
La encriptacin consiste en transformar un mensaje inteligible en
otro que no lo sea en absoluto, para despus devolverlo a su forma
original, sin que nadie que vea el mensaje cifrado sea capaz de
entenderlo [17].
-
34
SSL utiliza el esquema de encriptacin de clave publica/privada, el
cual utiliza 2 claves, si una clave se utiliza para encriptar el mensaje, la
otra servir para desencriptarlo, como el nombre lo indica, la clave
publica es una clave cuyo acceso es permitido a cualquier persona, de
esta manera es posible recibir mensajes encriptados de personas que
tengan acceso a nuestra clave pblica, siendo nosotros los nicos que
podemos leerla con nuestra clave privada [16].
El mecanismo en SSL que permite garantizar la integridad del mensaje
se llama de mensaje abreviado y consiste en crear un pequeo
resumen de el mensaje usando una funcin de hash, el receptor
crear su propio mensaje abreviado y lo comparar con el recibido, si
ambos coinciden significa que el mensaje fue recibido intacto.
Si cada parte tiene un certificado que valide la identidad del otro,
confirme la llave pblica y est firmado por una agencia creble
(trusted agency), entonces ellos estarn seguros de que realmente se
estn comunicando con quienes ellos creen, este protocolo fue
escogido por seguir con los PCI mencionados en nuestro capitulo
anterior.
-
35
2.4. Protocolo de Comunicacin TCP/IP.
Proviene del nombre de los dos protocolos que lo forman: Transmisin
Control Protocol (TCP) y el Internet Protocol (IP). Es totalmente
independiente del medio de transmisin fsico, tiene un esquema de
direccionamiento amplio y comn [18].
Arquitectura de TCP/IP
La figura 2.2 muestra la arquitectura:
Aplicacin
TransporteInternet
Acceso de Red
Aplicaciones y procesos que usan la red
Servicios de entrega de datos entre nodosDefine el datagrama y maneja el enrutamiento
Rutinas para acceder el medio fsico
Figura 2.2 Arquitectura de TCP/IP [19]
Encapsulacin de Datos
Cada capa de la pila TCP/IP adiciona informacin de control
para asegurar la entrega correcta de los datos.
Cuando se recibe, la informacin de control se retira.
En la figura 2.3 se puede observar la forma de cmo estn
encapsulados los datos.
-
36
Capa de Acceso de Red
Capa Internet
Capa de transporte
Capa de aplicacin
DATOSHeader
DATOSHeaderHeader
Header DATOSHeaderHeader
DATOS
Figura 2.3 Encapsulacin de Datos [19].
Estructura de Datos
En la siguiente figura 2.4 podemos ver la descripcin de la
estructura de datos y las capas donde se desarrolla cada una
de ellas.
Capa de Acceso de Red
Capa Internet
Capa de transporte
Capa de aplicacin UDPMessage
Packet
Datagram
Frame
TCPStream
Segment
Datagram
Frame
Figura 2.4 Estructura de Datos [19].
-
37
Protocolo Internet (IP)
El protocolo IP tiene a su cargo las siguientes funciones [18]:
Define el datagrama, que es la unidad bsica de transmisin en
Internet.
Define el esquema de direccionamiento de Internet. Mueve
datos entre capa de acceso de red y la capa de transporte host
to host
Caractersticas:
Es un protocolo connectionless (no intercambia informacin de
control handshake, para establecer una conexin nodo a nodo
antes de transmitir).
No corrige ni detecta errores en la informacin.
Otros protocolos hacen estas tareas.
2.5.Las Tarjetas de Crdito.
Primeramente vamos a hablar un poco de los emisores o procesadores
de las tarjetas de crdito actualmente en nuestro pas, existen diversas
marcas de tarjetas de crdito con las que cuentan los diferentes bancos
-
38
para ello vamos a detallar en la presente tabla 2.2 la marca de tarjeta con
su respectiva institucin que la emiten [2]:
TARJETA DE CREDITO INSTITUCION EMISORAMASTERCARD Banco Bolivariano, Banco Guayaquil,
Banco del Austro, Banco Pacfico, Banco Pichincha, Banco Internacional, Banco Produbanco, Mutualista Pichincha y Pacificard
DINERS Sociedad Financiera Diners ClubVISA Banco Amazonas, Banco Bolivariano,
Banco Comercial de Manab, Banco Guayaquil, Banco de Loja, Banco de Machala, Banco del Austro, Banco Pacfico, Banco Pichincha, Banco Rumiahui, Banco Guayaquil Bank Trust, Banco Internacional, Banco MM Jaramillo Arteaga, Banco Produbanco y Mutualista Azuay
AMERICAN EXPRESS Banco GuayaquilCUOTA FACIL Banco UnibancoTARJETA CREDITO SI Banco TerritorialMI SOCIA Banco SolidarioCREDITO SI Banco TerritorialROSE Banco Internacional
Tabla 2.2 Tarjetas de Crdito y Bancos que la Poseen.
Ahora vamos a mencionar a los procesadores de las tarjetas de crdito y con
qu bancos trabajan, en la tabla 2.3 siguiente los detallamos:
PROCESADOR DE TARJETAS INSTITUCIONESDATAFAST Banco Guayaquil, Banco Pichincha,
Banco Pacfico, Banco de Loja,
Pacificard, Sociedad Financiera
Diners Club, Banco Guayaquil Bank
-
39
Trust, Banco Amazonas, Banco MM
Jaramillo ArteagaMEDIANET Banco Bolivariano, Banco
Produbanco, Banco InternacionalUNIBANCO Banco UnibancoAUSTRO Banco del AustroSERVITRANSEL Cooperativas
Tabla 2.3 Procesadores de Tarjetas de Crdito.
La cobertura provincial del nmero de tarjetas de crdito lo podemos ver en
el anexo 1, y tambin presentamos en el anexo 2 la poblacin que poseen
tarjetas de crdito por clase.
-
CAPTULO III
3. DESCRIPCION DEL PROYECTO
En el presente captulo el objetivo es explicar de manera detallada el
desarrollo de las aplicaciones que nos ayudaron a resolver la problemtica
planteada en el captulo I, con las diversas tecnologas utilizadas para
resolver el mismo.
-
41
Finalmente y por ser un factor crtico en el desarrollo de sistemas de este
tipo, se le dedicar especial atencin al tema de las seguridades las cuales
sern mencionadas en la seccin 3.3 de una manera detallada.
3.1. Solucin Planteada.
Nuestra solucin consiste en un sistema en el cual los comerciantes
dispondrn de una aplicacin instalada en un telfono celular, que les
permitir realizar cobros con tarjeta de crdito a sus clientes mediante
un enlace directo a un servidor Web el cual previa autenticacin del
comerciante en una base de datos, se enlazar a su vez con una
entidad de procesamiento de transacciones con tarjeta de crdito
(switch)4[8] para solicitar la autorizacin del cobro.
En la figura 3.1 se muestra un diagrama que esquematiza la
arquitectura del sistema en general.
4 Software de Autorizaciones de Tarjetas de Crdito en Lnea, utilizando la ISO 8583, SuSistema Cia. Ltda., 2002, SWITCH DE AUTORIZACIONES.
-
42
Figura 3.1 Diagrama de la arquitectura del sistema.
La arquitectura del sistema utiliza dos servidores: un servidor Web y
un servidor de base de datos. En el servidor Web, se alojar un sitio
Web desarrollado en ASP.NET que se ejecutar sobre Internet
Information Server. Este sitio Web se comunicar con el servidor de
base de datos a travs de TCP/IP, este servidor almacenar en una
base de datos SQL Server los datos de los comerciantes que harn
uso del sistema y las transacciones que estos realicen.
-
43
Acogindonos a las normas PCI, estos servidores estarn protegidos
por un firewall [20] adecuadamente configurado.
Para el acceso al sistema a travs de un telfono mvil, ste debe
tener correctamente configurados los siguientes parmetros: La
direccin Uniform Resource Locator (URL) [21] del servidor y los datos
para autenticacin del comerciante y equipo. Para la realizacin de la
conexin con el servidor, el telfono mvil debe iniciar el
establecimiento de una conexin segura, para lo cual recibir el
certificado del servidor Web el cual estar firmado por una reconocida
entidad emisora de certificados electrnicos [22] y una vez reconocido,
validado dicho certificado se establecer una conexin segura SSL
entre el telfono mvil y el servidor Web. Una vez realizado esto, los
datos de autenticacin son recibidos por un script en ASP.NET. Este
script permitir la comunicacin con el servidor de base de datos para
la comprobacin de los datos de autenticacin, y posterior realizacin
de la transaccin solicitada por medio de la conexin va TCP/IP a un
sistema Switch de procesamiento de transacciones con tarjeta de
crdito de una reconocida entidad en nuestro medio.
-
44
Para realizar la conexin del telfono mvil al servidor Web se utilizan
dos redes, en primer lugar se debe conectar a la red del operador de
telefona mvil que provee este servicio el cual a su vez le permitir
enviar los datos a travs de la red de Internet.
A continuacin describiremos con lujo de detalle todos los aspectos
tcnicos relacionados tanto al flujo de informacin como a su
procesamiento en las diferentes partes del sistema.
3.2 Descripcin del Software.
En esta seccin realizaremos un anlisis de las aplicaciones
requeridas para el desarrollo del proyecto que son las siguientes:
La aplicacin a instalar en el telfono celular del comerciante
desarrollado en J2ME, a la cual de ahora en adelante llamaremos
Aplicacin Cliente.
-
45
El servidor de control de usuarios del sistema al cual llamaremos
Aplicacin Servidor.
3.2.1 Descripcin de la Aplicacin Cliente en J2ME
Para la implementacin de esta aplicacin se ha elegido la
plataforma J2ME.
Funcionamiento de la aplicacin cliente
Una vez instalada la aplicacin cliente en el telfono celular, al
ser ejecutada, lo primero que se le muestra al usuario es la
pantalla de configuracin del sistema (Figura 3.2). Esta ser de
uso exclusivo de un tcnico o ejecutivo encargado de instalar la
aplicacin y permitir ingresar los siguientes datos: el nombre
de usuario del comerciante que utilizar la aplicacin, la
contrasea para el usuario, nmero identificador para equipo en
el cual se instala la aplicacin y la direccin URL de la
aplicacin servidor. El manejo de estos datos se lo realiza por
medio de dos niveles de abstraccin:
-
46
En el nivel ms alto mediante una instancia de la clase que
hemos denominado ConfigInfo [11], que permite el
almacenamiento y posterior recuperacin de cualquiera de
los parmetros mencionados.
La clase ConfigInfo la cual a su vez hace uso de otra clase
denominada RecordManager [11] que cumple la funcin de
un administrador generalizado del RMS del sistema.
Figura 3.2 Pantalla de configuracin de la aplicacin cliente.
El usuario, contrasea y nmero identificador del equipo son los
datos que se utilizan para la autenticacin en la base de datos a
la que se conecta la aplicacin servidor. Por razones
-
47
principalmente de seguridad se ha decidido que estos datos de
autenticacin no estn al alcance del comerciante que utilizar
la aplicacin, si no que se mantengan almacenados
internamente en el equipo. Es por esto que la pantalla de
configuracin solo se mostrar la primera vez que se ejecute la
aplicacin, esto significa que si hubo algn error en el ingreso
de estos datos, la nica forma de corregirlo ser volviendo a
instalar la aplicacin.
Una vez instalada y configurada la aplicacin cliente, est lista
para permitir al comerciante efectuar cobros con tarjeta de
crdito a sus clientes. Para realizar una transaccin el
comerciante deber ingresar a la aplicacin cliente instalada en
el telfono celular y seleccionar la opcin Transaccin, una vez
hecho esto, ser creada una instancia de la clase Transaccin.
Esta clase tiene como atributos todos los parmetros
necesarios a ser ingresados por el comerciante para efectuar
una transaccin y su funcin es ir registrando todos estos datos
a lo largo de la secuencia de pantallas en donde stos se le
solicitan al comerciante (Figura 3.3). Estos parmetros son los
siguientes:
-
48
Tarjeta de crdito
Tipo de diferido.
Nmero de la tarjeta de crdito.
Nmero de verificacin de la tarjeta (CVV2/CVC2/CID)
Fecha de caducidad de la tarjeta de crdito
Nmero de celular del cliente
Monto de la transaccin.
Nmero de meses en el caso de diferido.
-
49
Figura 3.3 Secuencia de pantallas para realizar una transaccin con la aplicacin cliente.
En la ltima pantalla y una vez verificado que todos los datos
hayan sido ingresados correctamente, se crea una instancia de
la clase DataTranSender, la cual es la encargada de realizar la
conexin con la aplicacin servidor. El constructor de esta
clase recibe como parmetros los parmetros recogidos por la
clase Transaccin y hace uso de la clase ConfigInfo para
recuperar la informacin de configuracin de la aplicacin. El
siguiente fragmento de cdigo muestra la instanciacin de la
clase DataTranSender. Una vez instanciada esta clase, se
-
50
realiza la comunicacin en un nuevo hilo de ejecucin mediante
el mtodo start () de la clase.
DataTranSender tr = new
DataTranSender(midlet,this,username,password,
midlet.tran.getTarjeta(),midlet.tran.getNumeroTarjeta(),midlet.tra
n.getNumeroCid(),
midlet.tran.getFechaCaducidad(),midlet.tran.getFonoCliente(),mi
dlet.tran.getValor(), midlet.tran.getTipoDiferido(),
midlet.tran.getNumeroMeses()); tr.start();.
Posteriormente todos estos datos se pasan como parmetros al
constructor de la clase Trama, que es la encargada a su vez de
generar como su nombre lo indica, una trama de longitud
variable conteniendo los datos de la transaccin y que ser
enviada al servidor. La composicin de esta trama se muestra
en el anexo 3.
-
51
3.2.2 Descripcin de la aplicacin Switch y servidor
Funcionamiento de la aplicacin servidor
La clase Default es la clase principal de la aplicacin y de
acuerdo al modelo code-behind[23] de ASP.NET contiene el
cdigo de script detrs del archivo Default.aspx que es la
pgina a la cual las aplicaciones cliente realizarn las
peticiones.
El primer proceso que se realiza en esta clase es el de
autenticacin, para esto es necesario obtener los tres datos de
autenticacin recibidos en la trama enviada desde la aplicacin
cliente, y esto se obtiene mediante el mtodo GetLogin(). El
proceso de autenticacin consta de tres niveles: El primero en
el que se realizar la autenticacin de la aplicacin cliente
propiamente dicha a travs del agente de usuario, El segundo
en donde se autenticarn los datos del comerciante y finalmente
la autenticacin mediante el nmero identificador del equipo.
Estos niveles de autenticacin sern descritos en ms detalle
en la seccin siguiente donde nos referimos al tema de
seguridades.
-
52
Una vez generada la trama, el siguiente paso es realizar el
envo de sta hacia la aplicacin servidor, esta ser la primera
parte de la comunicacin entre componentes en la arquitectura
del sistema. Para el envo de datos, la clase DataTranSender a
travs de su mtodo sendData() hace uso de una instancia de
la clase HttpsConnection la cual se encuentra contenida en el
paquete javax.microedition.io de J2ME que define los mtodos
y propiedades necesarios para establecer una conexin de red
segura. El establecimiento de una conexin por medio de este
mtodo en J2ME es necesario realizarlo en un hilo
independiente de ejecucin, esto se logra por medio de los
mtodos start() y run() tambin definidos en la clase
DataTranSender. Estos mtodos permiten crear y ejecutar el
mtodo sendData() en un nuevo hilo.
Antes de hacer uso del objeto de la clase HttpsConnection para
el envo de los datos, es necesario especificar otros dos
parmetros. Primero debemos definir el mtodo envo de
informacin al servidor Web. En nuestro caso utilizaremos el
mtodo GET. Este mtodo solicita informacin al servidor Web,
en nuestro caso a un script desarrollado en ASP.NET que se
-
53
ejecuta en la aplicacin servidor. Luego, es muy importante en
el caso de nuestra aplicacin, definir antes del envo la
propiedad User-Agent ya que como veremos ms adelante,
est nos provee de un nivel adicional de autenticacin adems
de los anteriormente descritos.
En el siguiente fragmento de cdigo se muestran los pasos
principales que se realizan en el mtodo sendData() para el
establecimiento de la conexin con el servidor:
http = (HttpsConnection) Connector.open(URL);
// fijar el mtodo de envo de datos como GET
http.setRequestMethod(HttpConnection.GET);
//Especificar el User Agent
http.setRequestProperty("User-Agent","Profile/MIDP-2.0 Configuration/CLDC-1.1 (Cobro Electronico Celular 197997492)");
if (http.getResponseCode() == HttpsConnection.HTTP_OK){
// Si la respuesta del servidor es la esperada, recibir los datos
-
54
sb = new StringBuffer();
int ch;
recibir = http.openInputStream();
while ((ch = recibir.read()) != -1)
sb.append((char) ch);}
else{
// Si la respuesta del servidor no es la esperada, se obtiene el cdigo y mensaje de error
respuesta_error = "Error, Codigo respuesta http: " +
http.getResponseCode() + " " +
http.getResponseMessage(); }
Una vez que se ha pasado por el proceso de autenticacin
anteriormente descrito, la aplicacin est lista para procesar la
parte de la trama recibida que contiene los datos de la
transaccin. Para esto se hace uso de la clase Trama. Esta
clase al igual que la clase del mismo nombre implementada en
la aplicacin cliente, se encargar de generar una nueva trama,
ahora con el formato requerido por un nuevo receptor que en
-
55
este caso ser el sistema Switch de autorizaciones que nos
proveer del servicio de procesamiento de las transacciones.
En el Anexo 4, detallamos el formato que debe tener esta nueva
trama.
Una vez que se obtiene la trama en el formato descrito, lo cual
se logra mediante el mtodo GetTrama() de la clase Trama, se
puede proceder a enviar la misma hacia el sistema Switch de
Autorizaciones, el cual responder con la respectiva
autorizacin o negacin del cobro. La clase encargada de
implementar la comunicacin con el Switch la hemos
denominado Gateway.
Bsicamente, esta clase provee los mtodos necesarios para
lectura y escritura en dos archivos Entraxxx.dat y Rxxxyyy.dat
que a su vez sern utilizados por una aplicacin provista para
conexin con el Switch de autorizaciones y de esta manera
solicitar la autorizacin de los pagos.
-
56
Cabe mencionar que previo al envo de una trama al Switch de
autorizaciones, se realiza una validacin del nmero de tarjeta
de crdito para comprobar si este cumple con la especificacin
ISO 2894, el anexo 5 tenemos una grfica detallada del
funcionamiento del mismo con el formato ISO 8583 el mismo
que es utilizado por el SWICTH. Esta especificacin provee de
un algoritmo que permite comprobar la validez de la estructura
del nmero de tarjeta de crdito, el siguiente paso es grabar en
la tabla locales de donde provino el mensaje de que celular y
local, en la base de datos Mensajes.MDB graba y ve a que
procesador pertenece la tarjeta para poder establecer conexin,
y crear el archivo de acuerdo a lo solicitado por dicho
procesador, este a su vez vuelve a establecer una conexin de
respuesta con el programa Switch, pasa a travs de la tabla
Local para ver a que local corresponde la respuesta, va al
subprograma SWITCH2 Distribuidor y pasa a grabar en la base
Mensajes.MDB si respuesta de la peticin, pasa Tabla Locales
para ver a que celular debe devolver la respuesta, graba en el
archivo RXXXYYY.DAT si no tiene asterisco en la primera
posicin, sino tiene que esperar a que el Servidor Web a travs
de su clase gateway coloque dicho asterisco, porque si no lo
-
57
tiene entonces esta listo para que el Servidor Web lea la
respuesta y coloque el asterisco en la primera posicin.
Debemos tomar en cuenta que el programa Switch, considera
un tiempo de Time-Out (de 40 a 60 segundos), si en ese tiempo
no recibe respuesta, enviar una transaccin 3 (Reversa
Automtica) y luego solicitar nuevamente la Autorizacin, este
paso suele hacerse de 2 a tres veces.
Esta aplicacin SWITCH est desarrollada en Visual Basic, es
una aplicacin distribuida, la misma que esta en funcionamiento
en algunos establecimientos como son: Lloyds Bank, Banco
Pichincha, Marathon Sports, Fybeca, etc., trabaja en algunas
plataformas como son: Windows (95,98, Milenium, Xp, Nt,
Server 2.00x), 4690, Novell y Linux. En el anexo 6 presentamos
informacin adicional a este SWITCH.
-
58
3.3 Seguridades
3.3.1 Estndares de Seguridad.
Dentro de los estndares de seguridad que seguimos en nuestro
proyecto tenemos: ISO 2894, ISO 8583 que utiliza el Switch, y los
estndares PCI [7].
Cabe mencionar que previo al envo de una trama al Switch de
autorizaciones, se realiza una validacin del nmero de tarjeta de
crdito para comprobar si este cumple con la especificacin ISO
2894. Esta especificacin provee de un algoritmo que permite
comprobar la validez de la estructura del nmero de tarjeta de
crdito.
El algoritmo ISO 2894 es el siguiente:
1. Calcular el peso para el primer dgito: si el nmero de dgitos
es par el primer peso es 2 de lo contrario es 1. Despus los
pesos alternan entre 1, 2, 1, 2, 1
2. Multiplicar cada dgito por su peso.
-
59
3. Si el resultado del 2 paso es mayor que 9, restar 9.
4. Sumar todos los dgitos.
5. Comprobar que el resultado es divisible por 10.
3.3.2 Criptografa.
La tcnica en donde se utiliza la misma llave tanto para encriptar
como para desencriptar la informacin enviada se denomina
criptografa simtrica, mientras que la tcnica en donde se utiliza
una clave pblica para encriptacin y una privada para
desencriptacin se denomina criptografa asimtrica. En nuestro
proyecto se trabaja con el protocolo de seguridad 128-bit Secure
Socket Layer (SSL) 3.0. [27]
Este nos asegura una conexin encriptada a travs de un esquema
mixto. Este usa tanto el sistema simtrico como el asimtrico de la
siguiente forma: La clave simtrica es cifrada con la clave pblica, y
el mensaje saliente es cifrado con la clave simtrica, todo
combinado automticamente en un slo paquete. El destinatario
usa su clave privada para descifrar la clave simtrica y acto seguido
-
60
usa la clave simtrica para descifrar el mensaje. Adems mediante
el uso de un certificado digital proveniente de una autoridad
certificadora se garantiza que la clave pblica que estar en los
telfonos celulares corresponde a la clave privada del servidor. Los
algoritmos comnmente usados en este esquema son: RSA o DSA
para cifrado asimtrico y RC4, IDEA o 3DES para cifrado simtrico
[28].
Como ya se haba mencionado el perfil MIDP 2.0 que es el perfil
que utilizamos para el desarrollo de la aplicacin cliente, brinda
mediante la interface javax.microedition.io.HttpsConnection, soporte
tanto para trabajar con el protocolo SSL 3.0 o con su versin
actualizada denominada TLS 1.0 y entre las funcionalidades ms
interesantes que ofrece est la de proveer informacin detallada
sobre la conexin segura que se est utilizando. Para esto se
cuenta con el mtodo getSecurityInfo () en cual retorna una
instancia de otra interface denominada SecurityInfo. Es a travs del
mtodo getCypherSuite () de esta interface que se pudo obtener la
informacin sobre el paquete de cifrado utilizado por nuestra
conexin segura realizada mediante un certificado digital instalado
-
61
en el servidor y proveniente de VeriSign [22]. La ejecucin de este
mtodo arroj en nuestro caso el resultado siguiente:
TLS_RSA_WITH_RC4_128_MD5
Esto significa que se est usando el algoritmo asimtrico RSA [24]
para el intercambio de claves, mientras que para la encriptacin de
la informacin a enviar se est usando el algoritmo simtrico RC4
con una clave de 128 bits, adems del uso de MD5 como funcin
de hash[28].
3.3.3 Descripcin de la Arquitectura de Seguridad
Seguridades en el telfono celular
En lo que se refiere a la aplicacin instalada en el telfono celular
uno de los principales desafos existentes es el hecho de que en el
dispositivo estarn guardados datos confidenciales del comerciante
como son su nombre de usuario, contrasea e identificador de
equipo.
Como ya lo habamos mencionado anteriormente la especificacin
original MIDP define un mtodo de almacenamiento a travs del
-
62
Sistema de almacenamiento de registros o Record Management
Store (RMS)[11]. Al ser este el mtodo usado para guardar de los
datos de autenticacin en el dispositivo, fue necesario investigar el
nivel de seguridad que ofrece esta forma de almacenamiento.
Sobre esto se pudo averiguar que un Midlet puede compartir su
almacn de registros con otros, pero es posible declararlo como
privado al momento de su creacin. De este modo se elimina
cualquier posibilidad de acceso no autorizado al RMS de la
aplicacin cliente.
Lo anteriormente descrito no garantiza la seguridad de la aplicacin
cliente, debido a que en caso de caer el paquete generado para
instalacin en malas manos, este fcilmente puede ser
descompilado por un usuario experto a travs de diversas
herramientas que permitiran obtener su cdigo fuente. Esto puede
ser usado para procesos de ingeniera reversa y acceso a los datos
de autenticacin guardados en el RMS de la aplicacin. La manera
ms extendida entre los desarrolladores para enfrentar este
problema es la denominada ofuscacin de cdigo. Este proceso
consiste en una modificacin deliberada del cdigo de forma tal que
resulte prcticamente imposible descompilarlo e incluso
interpretarlo correctamente aun si se obtiene el cdigo fuente por el
-
63
procedimiento que fuera. Esta ofuscacin se consigue en la prctica
por medio de la inclusin de bucles irrelevantes, clculos
innecesarios, comprobaciones absurdas, nombres de funciones y
de variables que no tienen nada que ver con su cometido, funciones
extensas que no sirven para nada, interacciones inverosmiles entre
variables y funciones, etc. Existen varias aplicaciones gratuitas que
permiten realizar este proceso denominadas ofuscadores. En
nuestro caso, el IDE Netbeans 5.0 [26], incluye la posibilidad de ser
configurado para realizar este proceso de forma automtica al
momento de empaquetar la aplicacin para distribucin.
Seguridades en la comunicacin con la aplicacin servidor.
Como ya se haba mencionado para la transmisin de los datos
hacia la aplicacin servidor se utilizar una conexin a Internet a
travs de la red GPRS del operador de telefona mvil. Una vez
que la informacin se encuentra en Internet, esta viaja a travs de
una variedad de equipos de red como servidores, routers, entre
otros, esto significa que en cualquier punto de la red la informacin
es susceptible de ser interceptada usando los conocimientos y
herramientas adecuadas.
-
64
Al estar utilizando una red pblica para la transmisin de datos
confidenciales, es necesario de acuerdo a las normas PCI, usar una
tecnologa especializada de comunicacin segura. En nuestro caso
hemos decidido usar el medio ms estandarizado para la
transmisin de datos sobre Internet sobre todo en lo referente a
aplicaciones o sitios de comercio electrnico. Se trata de SSL, en
donde se reemplaza una conexin va HTTP por otra HTTPS o
HTTP seguro.
Para la conexin de las aplicaciones cliente y servidor se utiliza dos
tipos de autenticacin:
La autenticacin de servidor se refiere al proceso por medio del
cual la aplicacin servidor se identifica ante la aplicacin cliente.
La autenticacin del cliente se refiere al proceso mediante el
cual la aplicacin cliente se identifica ante la aplicacin servidor.
-
65
Autenticacin del servidor
El procedimiento consiste de los siguientes pasos
Importar el Test CA Root proveniente de la entidad de donde se
obtuvo el certificado de prueba en un keystore o almacn de
claves de Java, lo cual se lo hizo mediante el comando keytool
de Java. A continuacin mostramos un ejemplo del uso de este
comando:
Keytool -import -keystore keystore -storepass password -file
ca_cert.txt -alias httpsca
En donde keystore es el nombre del almacn de claves al cual
se va a agregar, password la contrasea del almacn de
claves, ca_cert.txt el archivo que contiene el Test CA Root y
httpsca el nombre que se le asignar a dicha clave pblica en
ese almacn de claves.
Posteriormente una vez incluido el certificado en el keystore,
est adquiere el formato adecuado y queda listo para ser
importado al almacn de claves del emulador. Esta importacin
se la hizo usando la herramienta MEKeytool que es el
-
66
equivalente en el perfil MIDP del comando keytool.
Presentamos a continuacin un ejemplo de su uso:
Java -jar bin/MEKeyTool.jar -import -keystore keystore -alias
httpsca -storepass password
Opcionalmente se puede chequear la lista de claves pblicas
contenidas en el almacn de claves mediante la siguiente
sentencia:
Java -jar bin/MEKeyTool.jar -list
Una vez realizado este proceso de manera correcta el dispositivo
que en nuestro caso fue el emulador, puede autenticar al servidor.
A continuacin mostramos un ejemplo de una conexin segura en
J2ME:
String URL = https://unhost/unarchivo.aspx;
HttpsConnection c = (HttpsConnection)Conector.open(URL);
-
67
Autenticacin del cliente
Para incrementar las seguridades en el caso de la autenticacin
del cliente en el servidor, se ha implementado una arquitectura de
autenticacin de clientes de tres niveles en la aplicacin servidor.
En el primer nivel se obtiene el Agente de usuario mediante la
propiedad UserAgent de la clase Request que es la que en una
aplicacin Web de ASP.NET se encarga del acceso a los detalles
de las peticiones del cliente. Este nivel permite validar el acceso,
de manera que solo puedan acceder los tipos de aplicaciones
autorizadas al siguiente nivel.
Una vez que se ha comprobado que el tipo de aplicacin que
intenta acceder es vlido, se pasa al siguiente nivel de
autenticacin, en donde se realizar la consulta a la base de datos
para comprobar mediante el usuario y contrasea que
efectivamente se trata de un cliente autorizado.
Una vez comprobados los datos del cliente, el tercer nivel consiste
en autenticar la aplicacin instalada en el equipo y determinar si
esta pertenece al usuario que se autentic en el nivel anterior por
medio del nmero identificador de equipo
-
68
En la figura 3.4 se muestra un diagrama de la arquitectura
implementada para la autenticacin de aplicaciones cliente:
Figura 3.4 Diagrama de flujo de autenticacin de aplicaciones cliente.
-
CAPTULO IV
4. IMPLEMENTACION DEL PROYECTO.
En el presente captulo explicaremos de manera detallada la implementacin
del proyecto a travs de sus modelos de clase, de datos, y los diferentes
mdulos que conforman nuestra aplicacin.
-
70
4.1. Mdulos de Aplicacin.
En nuestra aplicacin hemos considerado el desarrollo de algunos
mdulos que forman parte del modelo principal propuesto en la Figura
1.1, estos son:
Mdulo de Aplicacin Cliente (MAC).
Mdulo de Aplicacin Servidor (MAS).
Mdulo del sistema Switch de Autorizaciones (MSSA).
En la Figura 4.1 se puede observar el modelo de nuestro proyecto
separado en los mdulos de aplicacin que se enunciaron
anteriormente.
-
71
Figura 4.1 MODULOS DE APLICACIN
El primer mdulo hace referencia a la aplicacin cliente mencionada
en el captulo anterior y consiste del software que debe instalarse en el
telfono celular, que cumple la funcin de brindar la interface de
usuario que permita establecer de una manera sencilla y segura la
comunicacin con la aplicacin servidor para la realizacin de una
transaccin.
El segundo mdulo se refiere a la aplicacin servidor descrita en el
captulo anterior y est compuesta por 3 subcomponentes principales
que son:
La aplicacin Web desarrollada en el lenguaje ASP.NET que
cumple la funcin de implementar la lgica del negocio.
-
72
El servidor de bases de datos que se ejecuta sobre el sistema
de gestin de bases de datos SQL Server y que almacena los
datos de los usuarios del servicio as como los registros de
todas las transacciones realizadas por estos.
El sistema administrador de la base de datos de control de
usuarios desarrollado en lenguaje ASP.Net que permite
administrar de manera sencilla la base de datos de usuarios.
Finalmente tenemos el MSSA. Lo ms lgico es considerar a este
sistema como un mdulo a parte ya que se trata de una entidad
externa que cumple con la funcin de brindar a nuestro proyecto de
una manera transparente y segura el servicio de conexin con las
diferentes entidades emisoras de tarjetas de crdito para la realizacin
de las transacciones.
Cabe indicar que en el captulo 3 se realiz una descripcin detallada
del funcionamiento de los principales componentes de cada uno de
estos mdulos, as como de los aspectos tcnicos involucrados en los
mismos.
-
73
4.2. Modelo de Clases.
A continuacin describiremos la estructura de las clases principales
que se utilizan en el proyecto. Se utiliza un diagrama de clases que es
una notacin del Lenguaje de Modelamiento Unificado (UML) [29] que
se realiza en la etapa de diseo.
A continuacin se muestra el diagrama de clases para la aplicacin en
J2ME que se ejecuta en el telfono celular, la cual correspondiente al
primer mdulo. En la figura 4.2 mostramos la primera parte del
diagrama de clases de esta aplicacin. Esta primera parte consta de
las clases que implementan la funcionalidad principal de la aplicacin,
la cual se mencion previamente en este captulo en la descripcin del
MAC. Estas clases son las siguientes:
MidletPagoElectronico: Es la clase principal del midlet y es en la
implementacin de esta clase donde se instancian y se
inicializan todos los objetos necesarios para el funcionamiento
de la aplicacin en J2ME que se ejecuta en el telfono mvil.
-
74
Transaccin: Esta clase tiene la funcin de almacenar y permitir
el acceso y modificacin de todos los datos de una transaccin
que son ingresados por el usuario mediante la interface grfica
de la aplicacin.
DataTranSender: Es una de las clases ms importantes de la
implementacin debido a que permite el establecimiento de la
comunicacin con el MAS. El funcionamiento de esta clase fue
descrito de forma detallada en el captulo 3 seccin 3.2.1
pagina 43.
Trama: Se encarga de convertir los datos de la transaccin al
formato de trama requerido para su envo al MAS. En el anexo
3 se muestra en detalle este formato.
En la figura 4.3 se muestra la segunda parte del diagrama de clases
de la aplicacin cliente. El objetivo principal en esta segunda parte del
diagrama de clases es mostrar la relacin de las clases principales con
otras clases adicionales que sirven de apoyo para lograr el correcto
funcionamiento de la aplicacin. Estas clases son las siguientes:
-
75
FormDataTran: Es una de las clases que tienen la funcin de
implementar la interface grfica que permite el ingreso de los
datos de una transaccin a ser enviados al servidor por medio
del telfono celular. Hemos seleccionado a esta clase para ser
mostrada en este diagrama debido a que es la que implementa
la interface para el ingreso de los datos ms relevantes en una
transaccin de solicitud de autorizacin de cobro.
ConfigInfo: Esta es una clase importante ya que cumple con la
funcin de hacer transparente a la aplicacin el acceso al
sistema administrador de registros o RMS del midlet para el
ingreso, modificacin y consulta de los datos de configuracin
de un terminal en el mismo.
TranParser: Esta clase interviene al momento de recibir las
respuestas de la aplicacin servidor a las peticiones realizadas
y se encarga de interpretar el cdigo HTML recibido para
mostrar al usuario los mensajes de respuesta de una manera
clara.
-
76
Figura 4.2 Diagrama de clases de la aplicacin cliente. Parte 1.
-
77
Figura 4.3 Diagrama de clases de la aplicacin cliente. Parte 2.
-
78
En la figura 4.4 se muestra el diagrama de clases de la aplicacin Web
en ASP.NET que se encuentra en el modulo de aplicacin servidor. Se
detalla las principales clases de la implementacin de la misma que
son las siguientes:
Default: Esta clase contiene el cdigo del script detrs del
archivo Default.aspx que es la pgina a la cual las aplicaciones
cliente realizarn las peticiones. Es la clase principal de la
aplicacin y desde esta se instancian todas las dems clases
necesarias para el funcionamiento de la misma.
Trama: Esta clase al igual que la clase del mismo nombre
implementada en el MAC, se encargar de generar una nueva
trama, ahora con el formato requerido por el MSSA que nos
proveer del servicio de procesamiento de las transacciones.
En el Anexo 4, se muestra en detalle el formato de esta trama.
Transaccin: Esta clase tiene la funcin de realizar el acceso a
la base de datos de control de usuarios para la realizacin de
insercin y consulta de datos de las transacciones realizadas
-
79
por los usuarios del servicio a travs de las aplicaciones cliente
instaladas en los telfonos celulares.
Gateway: Esta clase provee los mtodos necesarios para la
comunicacin con el MSSA, dicha comunicacin consiste en
realizar lecturas y escrituras de las tramas de datos en los
archivos Entraxxx.dat y Rxxxyyy.dat que a su vez son utilizados
por una aplicacin provista por SuSistema Ltda. para conexin
con el MSSA denominada Local.exe, la cual tiene la funcin de
realizar el envo y recepcin de tramas de datos al MSSA.
-
80
Figura4.4 Diagrama de clases de la aplicacin servidor.
Especificacin de casos de usos
A continuacin mostramos una lista de los casos de usos que se han
considerado como los ms importantes en el sistema:
-
81
1. Ejecutivo de servicio tcnico configura un terminal.
2. Usuario solicita autorizacin de cobro.
3. Administrador accede al sistema de administracin de la base de
datos de control de usuarios del MAS.
4. Administrador crea un nuevo usuario.
5. Administrador modifica datos de un usuario existente.
6. Administrador agrega un nuevo terminal a un usuario.
7. Administrador modifica datos de un terminal existente.
A continuacin se detallar los casos de uso mencionados:
CASO 1: Ejecutivo de servicio tcnico configura un terminal.
Descripcin: Un ejecutivo encargado de soporte ingresa los datos de
autenticacin asignados al comerciante dueo del celular y la direccin
URL del servidor de control.
Notas:
- La contrasea es asignada por el administrador en el registro del
usuario en el servidor de control.
- Una vez instalado el sistema cliente en el telfono celular de un
usuario, la primera pantalla que se muestra es la de configuracin.
Valor medible: El acceso al men principal es otorgado o no.
Escenarios:
-
82
1.1.1 Los datos fueron ingresados correctamente y se muestra
el men principal del sistema.
1.1.2 Faltan datos por ingresar, en cuyo caso se muestra un
mensaje de notificacin y posteriormente se muestra
nuevamente la pantalla de configuracin.
1.1.3 Alguno o algunos de los datos no son vlidos en cuyo
caso se muestra un mensaje de notificacin y
posteriormente se muestra nuevamente la pantalla de
configuracin.
CASO 2: Usuario solicita autorizacin de cobro.
Descripcin: Un usuario solicita autorizacin para realizar un cobro a
un cliente.
Notas:
- Los datos que se solicitan para realizar la peticin de autorizacin
son: Nombre de tarjeta, tipo de diferido, nmero de tarjeta de crdito
del cliente, cdigo de verificacin de la tarjeta, fecha de caducidad de
la tarjeta, monto de transaccin y telfono del cliente.
Valor medible: El cobro es autorizado o no.
Escenarios:
2.1 Todos los datos estn correctos en cuyo caso se muestra la
pantalla que indica que la transaccin se realiz de manera exitosa y
-
83
adems muestra el nmero de autorizacin asignado por el emisor
para la transaccin.
2.2 Faltan datos por ingresar, en cuyo caso se muestra un mensaje de
notificacin y posteriormente se muestra nuevamente la pantalla de
ingreso de datos de la transaccin.
2.3 Alguno o algunos de los datos de autenticacin